הגדרת בוט מסחר בענן (AWS, DigitalOcean, Hetzner)

הגדרת בוט מסחר: היכן נשברת התשתית

בוט מסחר על שרת הוא תהליך עם פוזיציות פתוחות בזמן אמת: עסקה שלא נסגרה חיה בדיוק עד לניתוק הרשת הבא. ניתוק הקשר עם הבורסה מגיע ברגע הכי פחות מתאים — בתנועה חדה, כשההזמנה כבר יצאה והאישור לא חזר, והבוט לא יודע אם ההזמנה קיימת או לא.

נקודת הכשל השנייה — הפעלה מחדש של התהליך. עדכון מתוכנן, שגיאת תצורה, מיצוי זיכרון: אם מצב הפוזיציות חי רק בזיכרון העבודה, אובדן הזמנה בזמן תקלה הוא כמעט בלתי נמנע. לאחר העלייה הבוט רואה את היתרה בחשבון אחרת מהבורסה, ובאותן דקות ראשונות סוחר לפי תמונה שגויה.

השלישית — מגבלות קצב הבקשות. כשהתנודתיות עולה גם זרם הבקשות גדל, הבורסה משיבה בסירובים, וחלק מההזמנות נדחות. זמן ההשבתה של הבוט נמדד לא לפי זמן הנפילה, אלא לפי זמן העבודה בעיוורון, כשהבוט חושב שהפוזיציה פתוחה בעוד שהסטופ כבר סגר אותה.

הרביעית — היעדר צומת גיבוי ותיעוד. שרת אחד, בלי עקבה של סירובים — וניתוח התקלה הופך להשערות. הגדרת בוט מסחר מתחילה בכך שכל אחת מנקודות אלה נסגרת לפני ההפעלה הראשונה: נפרק כיצד זה בנוי.

אפקט מדיד של הגדרה: תגובתיות, זמן השבתה, שחזור

זמן התגובה לאירוע שוק משתנה ראשון. על מכונה מקומית הטיק עובד בעיכוב של כמה שניות: ערוץ לא יציב, תהליכי רקע ותור הזמנות על ליבה אחת הפריעו. בענן, באזור AWS, התגובתיות נכנסת לשברירי שנייה — באימפולסים חדשותיים, כשהמחיר נע ב-2–3% בשניות, הבוט מספיק להציב ולבטל הזמנה בלי החלקה.

זמן ההשבתה של הבוט נמדד בנפרד. נפילה של ספק האינטרנט הביתי או הפסקת חשמל יצרו 6–8 שעות בלי מסחר בחודש — בדרך כלל בימים התנודתיים ביותר. הפעלה מחדש אוטומטית של התהליך לפי הכלל "אין סימני חיים N מחזורים — מעלים מחדש" מקצרת את זמן ההשבתה הבלתי מתוכנן ל-10–15 דקות בחודש.

זמן השחזור נקבע לא לפי מהירות ההפעלה מחדש, אלא לפי שלמות המצב. צילומי דיסק לפי לוח זמנים ויומן הזמנות מאפשרים להרכיב את הפוזיציות מחדש ולהצליב אותן עם הבורסה: 30–40 דקות של הצלבה ידנית עם סיכון להכפיל הזמנה הופכות ל-3–5 דקות של ריצה אוטומטית עם דוח אי-התאמות.

נסגר גם סוג התקלות שלא תועד קודם כלל: אי-סנכרון המצב עם הבורסה לאחר ביצוע חלקי, תהליך תקוע בלי הפעלה מחדש, נקודת כשל יחידה בדמות מכונה אחת וערוץ אחד. חלק ההזמנות שאבדו מסיבות טכניות בתקופות שנצפו שואף לאפס — התקלה או שאינה יוצרת זמן השבתה, או שהיא נראית ברגע התרחשותה.

מצבי פריסה: שרת, קונטיינר, קלאסטר

בחירת הפלטפורמה נקבעת לפי שלושה דברים: כמה אסטרטגיות פועלות במקביל, עד כמה קריטי העיכוב בין האות להזמנה, ומה קורה בנפילת צומת. לכן פריסת בוט מסחר היא לא "איפה זול יותר", אלא איזה סוג תקלות אתם מוכנים לקבל.

מעבר בין האפשרויות אינו דורש כתיבה מחדש של האסטרטגיה: לוגיקת האותות, בקרת הסיכון והעבודה עם ממשק התוכנה של הבורסה מוצאים לשכבה נפרדת, והפריסה הופכת לפרמטר מתחלף.

בפלטפורמת קונטיינרים זה נותן חזרה מהירה לגרסה קודמת, בקלאסטר — הפעלה מחדש אוטומטית של פוד על צומת אחר וצומת גיבוי בלי התערבות ידנית.

לשכירת שרת לבוט אנחנו מגדירים בנפרד health-check, העלאה אוטומטית של התהליך והוצאה של המצב לדיסק חיצוני, כדי שנפילת צומת לא ת� означаל אובדן פוזיציות.

סדר העבודות: ביקורת, תרשים, פריסה, בדיקה

פריסת בוט מסחר היא לא העתקת קבצים לשרת, אלא רצף של צעדים עם בדיקה בכל אחד: הלוגיקה עובדת עם הזמנות אמיתיות, וטעות ברמה הזו עולה יותר מהזמן שהושקע בהכנה. הסדר שלהלן זהה גם לבוט חדש וגם להעברה של בוט שכבר עובד.

1. ביקורת תרשים הבוט. נפרק מאין מגיעים נתוני השוק, כיצד נוצרות ונשלחות ההזמנות, היכן נשמרים מפתחות הגישה ומצב הפוזיציות. התוצאה — מפת נקודות כשל: ניתוק הקשר עם הבורסה, אי-סנכרון זמן, שליחה חוזרת של הזמנה לאחר הפעלה מחדש.
2. תוכנית פריסה. בוחרים פלטפורמה לפי העומס ודרישות העיכוב, מגדירים תרשים בידוד תהליכים, חלוקת הרשאות, סדר העבודה עם סודות וגיבוי המצב.
3. הגדרת הסביבה. מפתחות גישה מונפקים עם ההרשאות המינימליות הנדרשות ובלי משיכת כספים, מפרמטרים מוצאים למשתני סביבה, מסנכרנים את הזמן, מגדירים מגבלות משאבים כדי שהבוט לא ידחק שירותים שכנים.
4. מעגל בדיקה. מריצים את האסטרטגיה על נתונים היסטוריים ועל מעגל הבדיקה של הבורסה, ואחר כך — על נפחים מינימליים. בנפרד בודקים תרחישי תקלה: אובדן קשר, הזמנה שנדחתה, ביצוע חלקי.
5. בקרת מצב והגנה. מגדירים יומנים ומטריקות, התראות על אי-התאמת פוזיציה מול הבורסה ועצירת חירום לפי תנאים מוגדרים — היא פועלת בלי מעורבות אדם.
6. מסירה להפעלה. מוסרים תיעוד על הסביבה, נהל עדכונים והפעלה מחדש, תרשים גישה לצוות שלכם וסדר חזרה לתצורה עובדת קודמת.

ערכת מסירה: תצורות, תרשיםים, נהלים

את ערכת המסירה מרכיבים כך שהצוות שלכם יוכל להעלות ולתחזק את הבוט בלי ההשתתפות שלנו. כל מה שנכלל בהגדרת בוט מסחר בפלטפורמות ענן נכנס למאגר ולבסיס הידע, ולא להתכתבות ולא לראש של מהנדס מסוים. להלן מה בדיוק נשאר בידיכם.

• קובצי תצורה — פרמטרי הפעלה, זוגות מסחר, מגבלות על פוזיציה ומחזור יומי, כתובות ממשקי הבורסה; מנוהלים בגרסאות, וחזרה לסט קודם אורכת דקות.
• תרשים תשתית — הצמתים המעורבים, הקשרים ביניהם, נקודות כשל, מסלולי מטריקות ויומנים, סדר המעבר לצומת גיבוי.
• הרשאות גישה למפתחות — מטריצת תפקידים, מפתחות נפרדים לקריאה ולמסחר, הרשאת משיכת כספים מבוטלת, סדר רוטציה ומקום אחסון הסודות.
• נהל תורנות — מי ובאילו שעות עונה להתראה, זמן התגובה המרבי, סדר עצירת הבוט בחירום.
• תיעוד הבוט — הלוגיקה, המצבים הנתמכים, בדיקות לפני עלייה, פענוח שגיאות אופייניות לפי רשומות ביומנים.
• הוראות הפעלה ושחזור — פריסה מאפס, העלאה לאחר תקלת צומת, העברה לפלטפורמת ענן אחרת.
• רשימת תיוג לקבלה — תרחישים שלפיהם אתם בודקים את התפקוד במו ידיכם.

את הערכה אנחנו רואים כנמסרה כאשר המהנדס שלכם מעלה את הבוט לפי ההוראות מאפס ומשחזר את העבודה לאחר צומת שהושבת בכוונה — בלי לפנות אלינו.

מקרה: הבוט הפסיק לאבד הזמנות בתקלות

מה היה

הבוט סחר ממכונה וירטואלית אחת, ואת תור ההזמנות החזיק בזיכרון התהליך: צילום לדיסק נשמר אחת לכמה דקות. הפעלה מחדש או מעבר של המכונה למארח פיזי אחר מחקו כל מה שלא הספיק להישמר — בחודש הצטברו 12–15 תקלות, 6–8 מהן עם אובדן הזמנות.

השחזור נעשה ידנית: הצלבת פוזיציות עם הבורסה לפי יומנים, עד 40 דקות של זמן השבתה וחלק מהעסקאות במחיר גרוע מהמתוכנן.

מה שינו בתרשים

העברנו את הבוט לשני צמתים של Hetzner באזורי זמינות שונים: מצב התור נכתב ליומן באופן סינכרוני, לפני האישור מהבורסה, ועל כל הזמנה מוצב מזהה ייחודי — שליחה חוזרת בעת ניתוק קשר לא יוצרת כפילות.

המעבר לגיבוי אוטומטי, לפי בדיקת זמינות, כעשר שניות; חיבור תקוע לבורסה מפעיל מחדש תהליך שמירה, והניסיונות החוזרים נעשים עם הגבלת קצב כדי לא להיתפס בחסימה בגלל מגבלות הבקשות.

מה נהיה

הזמנות שאבדו — אפס: כל אחת או מאושרת, או מבוטלת בבטחה לפי המזהה. מספר התקלות ירד מ-12–15 ל-1–2 בחודש, זמן ההשבתה הצטמצם מ-40 דקות לשניות, ואי-התאמת הפוזיציות מול הבורסה, שנהגו לנקות ידנית, אינה נוצרת עוד. התקלות הפסיקו להיות שגרתיות: הגדרת הבוט מצטמצמת כעת לעדכונים מתוכננים, ולא לניתוחי תקלות בלילה.

ספקות טכניים: קשר, מפתחות, מגבלות, אמינות

ספקות הנדסיים בנוגע לבוט מצטמצמים לארבעה צמתים: היכן נמצאים מפתחות הבורסה, כיצד לא להיתקע במגבלות הבקשות, מה קורה בניתוק ערוץ הקשר עם הבורסה וכיצד לדעת על תקלה לפני שהיא הופכת להפסד. להלן תשובות קצרות, כיצד זה בנוי בתצורות שלנו.

מה יקרה אם הבוט ייתקע במגבלות הבקשות של הבורסה?

המגבלות נספרות גם לפי IP וגם לפי מפתח, ולכן תקציב הבקשות מתוכנן לאסטרטגיה מראש: ספרי עזר נשמרים במטמון, יתרה ופוזיציות נשאלות במקבצים, וזרם ההזמנות עובר דרך תור עם הגבלת קצב.

בתשובת הבורסה על הגבלה הבוט עובר להשהיה עם מרווח הולך וגדל, ולא חוזר על הבקשה — אחרת חסימה זמנית הופכת לחסימה ארוכה.

הערוץ לבורסה ניתק — הבוט יסחור ביותר?

זרם הציטוטים יכול לקפוא בשקט, ולכן מחזיקים heartbeat וחיבור מחדש עם שחזור המנוי, ואחרי ההתחברות מחדש מצליבים את המצב המקומי עם זה של הבורסה. הזמנות מסומנות במזהים משלהן, כך ששליחה חוזרת לא יוצרת כפילויות, והפעלה מחדש של התהליך ממשיכה מהמצב המאושר האחרון.

כיצד בנויים ניטור הבוט וההתראות?

אנחנו אוספים את עיכוב הזרם, חלק הסירובים, אי-התאמה בין פוזיציות מקומיות לפוזיציות הבורסה וזמן ההשבתה. הספים מוגדרים לפי האסטרטגיה: התראה מגיעה למסנג'ר העבודה, ואות שמירה נפרד תופס מצב שבו התהליך חי אך הנתונים אינם מתעדכנים. משם — למצב בטוח: עצירת פתיחת הזמנות חדשות או ביטול ההזמנות הפעילות, לפי בחירתכם.

נדון במשימה — נחזור עם הערכה ותוכנית עבודה

הגדרת בוט מסחר היא עבודה שבה טעות בתצורה נראית מיד לפי העסקאות: ניתוק קשר עם הבורסה בלילה, סטופ שאבד או הזמנה כפולה עולים יותר מהתשתית עצמה. כדי לחזור עם הערכת עבודות ותוכנית הטמעה, ולא עם מילים כלליות, אנחנו צריכים לראות את התרשים שלכם בשלמותו.

שלחו לפי המשימה:

• תיאור האסטרטגיה: לוגיקת כניסה ויציאה, מרווחי עבודה, סט הכלים, מגבלות על פוזיציה וסיכון לעסקה.
• תרשים ההפעלה הנוכחי: היכן הבוט עובד כעת, אילו סקריפטים וקבצי הגדרות קיימים, מה אתם עושים ידנית בעת הפעלה מחדש.
• רשימת הפלטפורמות וסוגי החשבונות: ספוט, חוזים עתידיים, מעגלי בדיקה של בורסות, וכן כיצד נשמרים מפתחות הגישה.
• דרישות לעמידות בתקלות: זמן השבתה מותר, האם נדרשת החלפה חמה של צומת, התנהגות הבוט בניתוק קשר עם הפלטפורמה.
• מצב תורנות: מי וכיצד מקבל התראות, האם נדרשת תגובה מסביב לשעון או שמספיקות שעות עבודה.
• מגבלות פריסה: דרישות לתחום שיפוט, לגיבוי המצב ולסדר הגישות למהנדסים שלנו.

עם הסט הזה אנחנו מרכיבים תוכנית הטמעה: מעבירים את הבוט למעגל ענן, מפרידים סודות ובנייה לפי סביבות, מגדירים ניטור והפעלה מחדש אוטומטית, מריצים על מעגל בדיקה ורק אחר כך מבצעים את הפעלת הבוט בעבודה. תארו את המשימה — נחזור עם הערכה ותוכנית עבודה.

בוט על שרת או על מכונה ביתית: מה לבחור?

אם הבוט סוחר באופן קבוע, בוט על מכונה ביתית הוא החוליה החלשה ביותר בתרשים. הפעלה מקומית של הבוט נוחה כל עוד אתם מנפים את הלוגיקה, אבל ברגע שהפוזיציות נפתחות בלי ההשתתפות שלכם, כל הפסקה הופכת לעסקה שלא נסגרה. לכן המכונה הביתית נשארת כלי פיתוח, ומעגל העבודה חי על פלטפורמה שרתית.

הסיכונים של פריסה ביתית מורכבים מזוטות יומיומיות. הפעלה מחדש לאחר עדכון מערכת, מצב שינה, הפסקות חשמל, ניתוק ערוץ אצל הספק, כתובת דינמית מאחורי הראוטר — כל אחד מהאירועים האלה עוצר את התהליך.

דיסק בלי גיבוי ובלי צילומי מצב פירושו שלאחר תקלה אתם משחזרים ידנית גם את הבוט עצמו וגם את היסטוריית ההזמנות.

בפלטפורמה ייעודית נקודות הכשל האלה נסגרות בנפרד: התהליך עולה אוטומטית לאחר הפעלה מחדש, צילום מחזיר את התצורה והמצב לנקודת העבודה האחרונה, ניטור חיצוני מדווח על נפילה, והגישה לפי מפתחות מגבילה את מעגל האנשים עם הרשאות לפעולות מסחר.

ההפעלה המקומית לא הופכת למיותרת. ריצת אסטרטגיה על נתונים היסטוריים, בדיקת לוגיקה על מעגל בדיקה, הכנת תצורה — את אלה מהיר יותר לעשות על המכונה שלכם, עם גישה ישירה ליומנים. מקרה נפרד הוא דרישות לאחסון מפתחות: אם המדיניות אוסרת להוציא אותם לפלטפורמה זרה, חלק מהמעגל נשאר מקומי.

ההבדל מתבטא לא במהירות העסקאות, אלא ביכולת החיזוי: מכונה ביתית נותנת נוחות ניפוי, פלטפורמה שרתית — רציפות. התרשים העובד הוא בדרך כלל היברידי — הלוגיקה מוכנה מקומית, חלק המסחר עובד בפלטפורמה, והעברת התצורה ביניהם מתוארת וניתנת לחזרה.