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

מדוע ניטור uptime של בוט מסחר נכשל בסביבת פרודקשן

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

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

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

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

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

האפקט מההטמעה: תגובה, השבתה וסוגי כשלים

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

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

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

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

דרכי ניטור uptime: סקר חיצוני, סוכן, ניתוח לוגים

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

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

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

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

סדר ההטמעה: מביקורת נקודות הכשל ועד למסירה

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

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

תוצרי הפלט: קונפיגורציות, סכמות, נהלים

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

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

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

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

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

מטריקות לפני ואחרי

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

במה שונה watchdog מהתראה רגילה לפי מטריקה?

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

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

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

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

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

שאלות טכניות: התראות שווא, חלונות, הרשאות

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

ניטור uptime בנוי כך שיפריד בין "שותק כי ממתין לאות" לבין "שותק כי קרס". בנפרד, לא ה-heartbeat ולא השהיות התגובה של הבורסה מראים זאת — רק התמונה המשותפת שלהם.

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

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

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

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

כיצד להסיר התראות שווא?

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

מי מטפל בהתראת לילה?

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

נדון במשימה: נבנה סכמת בדיקות וניתן תוכנית עבודה

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

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

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

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