הפעלה מחדש אוטומטית של בוט מסחר: systemd, Docker, התראות

מדוע בוט מסחר נופל ונשאר שוכב

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

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

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

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

מה נותנת הפעלה מחדש אוטומטית של בוט המסחר

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

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

בתצורת מכולות את אותו תפקיד ממלאות מדיניות ההפעלה מחדש, ובדיקת החיוּת של הלולאה מבדילה בין תהליך שעובד בפועל לבין תהליך שרק הופעל פורמלית.

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

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

אפשרויות ארגון ההפעלה מחדש ומגבלותיהן

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

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

מדיניות הפעלה מחדש, תלויות ומצב הבוט

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

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

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

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

שלבי הטמעת ההפעלה מחדש האוטומטית וההתראות

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

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

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

3. הגדרת ההפעלה מחדש. את השירות מתארים כיחידת systemd מנוהלת עם מדיניות הפעלה והגבלת תדירות של הפעלות מחדש; סדר עליית התלויות — מאגר המצב, התורים — מוגדר במפורש. עבור מכולה, אותם כללים חיים במדיניות ההפעלה מחדש.

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

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

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

מה נשאר אצל הלקוח לאחר ההטמעה

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

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

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

מקרה בוחן: הבוט הפסיק לדרוש תורנות לילה

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

כל כשל — קימה בלילה, הפעלה מחדש ידנית, התאמת פוזיציות: 40–50 דקות השבתה ושלושה-ארבעה לילות מקולקלים בשבוע.

מה שינינו

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

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

לאחר ההטמעה 5–6 נפילות בשבוע הפכו ל-1–2 בחודש, זמן השחזור הצטמצם מ-40–50 דקות ל-10–20 שניות, כ-90% מהכשלים נסגרים בלי אדם. קימות לילה — 1–2 פעמים ברבעון במקום שלוש-ארבע בשבוע, והתורנות הפסיקה להיות מסביב לשעון.

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

במה נבדלת הפעלה מחדש של התהליך משחזור המצב

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

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

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

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

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

ספקות טכניים לפני תחילת העבודה

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

האם יופיעו כפילויות של הזמנות לאחר הפעלה מחדש?

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

מה קורה בעת כשל של הבורסה?

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

היכן נשמרים מפתחות הגישה לבורסה?

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

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

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

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

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

• ניתוח נקודת הכשל הנוכחית — נפילת התהליך, תקיעת תהליכון, ניתוק התקשורת עם הבורסה או כשל במפתח ה-API;
• תרשים ההפעלה מחדש: מדיניות Restart ב-systemd, מדיניות הפעלה מחדש של המכולה או תהליך שומר משל עצמנו;
• בדיקות חיוּת המבדילות בין "התהליך עובד" ל"הבוט סוחר" — רעננות התגובה האחרונה מהבורסה, קיום מינויים פעילים, היעדר הזמנות תקועות;
• ניתוב התראות: התראה מיידית בעת נפילה, סיכום יומי של הפעלות מחדש, הסלמה בעת כשלים חוזרים;
• עצירה בטוחה ושחזור מצב — מה לעשות עם פוזיציות לא סגורות וכיצד לא לשכפל הזמנות לאחר העלייה;
• תיעוד יומנים ושמירת לוגים, כדי לנתח סיבות, ולא רק את עצם ההפעלה מחדש;
• הגנה על הגישות לשרת ולמפתחות הבורסה בעת ניהול אוטומטי.

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