למה סגירת פוזיציות בחירום מתעכבת
סגירת פוזיציות בחירום מתעכבת לא בגלל לוגיקה חלשה, אלא בגלל תלות בערוץ חיצוני, שברגע של סטרס מתנהג אחרת מאשר בסביבת הבדיקות. ניתוק הקשר עם הבורסה — התרחיש הטיפוסי הראשון: החיבור פורמלית חי, אך אישורים על פקודות אינם מגיעים.
הכשל השני — פקודה תקועה. ההזמנה נשלחה לבורסה, אך לא בוצעה או בוצעה חלקית, והבוט כבר עבר לשלב הבא. בסופו של דבר לא כל הנפח נסגר, ובחשבון נשארת פוזיציה לא סגורה — בדיוק זו שמעגל החירום היה אמור לסגור ראשונה.
השלישי והמעצבן מכולם — חוסר סנכרון בין מצב הבוט לחשבון. היומן המקומי בטוח שהפוזיציה נסגרה, הבורסה מציגה את ההיפך, והפקודה החוזרת נשלחת אל הריק. הסיבה בדרך כלל היא שהמצב משוחזר לפי הלוג של עצמו, ולא נבדק מול הבורסה לאחר כל ניתוק.
המחיר של כל שלושת הכשלים זהה: סיכון לא סגור ממשיך לחיות במינוף עד לרגע שבו יטפל בו סגירה כפויה. הירידה בחשבון בקטע הזה גדלה מהר יותר ממה שההגנה מספיקה לפעול, ועומק ההפסדים נקבע לא על ידי האסטרטגיה, אלא על ידי הזמן שלקח למעגל להבחין באי-ההתאמה.
לכן לוגיקת החירום מתוכננת כבלתי תלויה בלוגיקת המסחר: הרשאות נפרדות, בדיקת מצב חשבון נפרדת, ערוץ התראות נפרד. נבחן כיצד זה נסגר ברמת הארכיטקטורה.
מה נותן עצירה מבוקרת של הבוט בעת כשלים
עצירת חירום נדרשת לא בגלל שהבוט «לפעמים טועה», אלא בגלל שהשוק ושער הבורסה מתנהגים באופן בלתי צפוי: Bybit עונה לאט מהרגיל, החתימה על ההזמנה לא עוברת בניסיון הראשון, והמחיר חוצה את הרמה שבה האסטרטגיה מאבדת את משמעותה.
עד שהתורן קורא את ההתראה ונזכר אילו פוזיציות פתוחות, הסיכון כבר התממש. המשימה היא לא לכתוב סקריפט «לסגור הכול», אלא להטמיע עצירה מבוקרת במעגל המסחר כך שהיא תפעל ללא אדם.
להלן — מה בדיוק משתנה בעבודה לאחר ההטמעה, בגדלים מדידים.
- זמן תגובה. המעבר מ«הבחנתי והתחלתי לסגור ביד» לפעולה אוטומטית לפי טריגר מקצר את התגובה מדקות לשניות, כולל הזמן לביטול פקודות פעילות.
- שיעור הפוזיציות הסגורות. ההליך עובר על כל התיק, ולא רק על המכשיר שבו זוהתה האנומליה: פקודות שבוצעו חלקית ופקודות לימיט «תקועות» נכנסות לאותה ריצה, ושיעור הפוזיציות הסגורות הופך למלא.
- סוג הכשלים שנעלם. ניתוק החיבור לבורסה, עלייה בזמן התגובה, שגיאת חתימה על ההזמנה, הפעלה מחדש ידנית של התהליך בעת פוזיציה פתוחה — תרחישים אלה מפסיקים להסתיים בסיכון לא סגור.
- יומן אירועים אחיד. כל הפעלה מתועדת: הטריגר, היוזם, רשימת ההזמנות, המחירים והתוצאה. ניתוח האירוע מתבצע לפי הרשומות, ולא לפי תשאול המשמרת התורנית.
- בקרת סיכון. גבולות הירידה והעומס נקבעים מראש — עם הגעה אליהם העצירה פועלת ללא מעורבות אדם, ולא לאחר אישור.
- עומס על התורנים. משמרות לילה מפסיקות להחזיק יד על הכפתור: התורנות עוברת לניתוח לוגים ולכוונון ספים, והצפייה המתמדת בגרף נעלמת.
- בדיקה סדירה. תרגולים לעצירה בסביבת בדיקות לפחות פעם ברבעון — התקנון נשאר עובד, ולא על הנייר.
מצבי עצירה: שוק, לימיט, מדורג
פקודת שוק סוגרת את הפוזיציה כולה ברגע הפעלת ההגנה — זה המצב היחיד עם הבטחת יציאה. המחיר של ההבטחה הוא החלקה במחיר: ככל שהפוזיציה גדולה יותר ביחס לעומק ספר ההזמנות, כך גרוע יותר מחיר הביצוע הממוצע. בנזילות נמוכה הפער בין הציטוט הראשון לעסקה בפועל אוכל חלק ניכר מהתנועה.
פקודת לימיט מחזיקה את המחיר בטווח מוגדר ואינה מפילה את הספר, אך אינה מבטיחה ביצוע: בתנועה חדה ההזמנה נשארת תלויה, והפוזיציה — פתוחה. סגירה מדורגת מסירה את הסתירה הזו — הנפח נחתך למנות, כל אחת נשלחת בנפרד, והמנה הראשונה יוצאת לפי השוק כביטוח.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| שוק | ספר דק, עדיפות — לצאת בכל מחיר | ההחלקה גדלה יחד עם גודל הפוזיציה |
| לימיט | ספר צפוף, המתנה לביצוע מקובלת | אין הבטחת עסקה, הפוזיציה עלולה להיתקע |
| מדורג | נפח גדול, הנזילות מפוזרת בצורה לא אחידה | דורש כוונון גודל המנות והשהיות ביניהן |
בחירת המצב אינה עניין של טעם, אלא פונקציה של עומק הספר, גודל הפוזיציה והתנודתיות הנוכחית. אנו מחשבים פרמטרים אלה לפי ההיסטוריה של המכשיר וקובעים ספי מעבר: כל עוד הספר צפוף — לימיט, בעת ירידה בעומק ההגנה עוברת אוטומטית למדורג או לשוק.
כיצד אנו מתכננים הגנה לבוט מפני כשלים
סדר העבודות זהה גם לבוט על ממשק הבורסה וגם לחיבור עם מודול סיכון חיצוני. תחילה קובעים אילו אירועים נחשבים לחירום, למי יש זכות ליזום סגירה ואיזו תוצאה נחשבת להצלחה — אחרת האוטומציה או שמופעלת על רעש, או ששותקת ברגע של כשל אמיתי.
- ביקורת החיבור. מנתחים כיצד הבוט מקבל נתוני שוק, שולח ומבטל פקודות, היכן הוא מאחסן את מצב הפוזיציות ואילו מפתחות גישה הוא משתמש. בודקים אם ישרוד ניתוק חיבור, שליחה חוזרת של בקשה וביצוע חלקי.
- מפת תרחישים. מתאמים מטריצת כשלים: היעלמות ערוץ התקשורת, כשל ממשק המסחר, אי-התאמה בין היתרה המקומית לזו שבבורסה, עלייה חדה בתנודתיות, עצירה ידנית על ידי המפעיל. לכל תרחיש — הסימן שלו, העדיפות וסדר הפעולות.
- כוונון טריגרים. קובעים ספים לירידה, זמני תגובה, מספר ניסיונות חוזרים, מגבלות בקשות וכללים החוסמים כפילויות של פקודות. סגירת פוזיציות בחירום מסומנת כהקטנה, כדי שהאוטומציה לא תפתח פוזיציה הפוכה.
- בדיקה על כשלים. מריצים את התרחישים בסביבת בדיקות: מנתקים את החיבור, מכניסים השהיות ותגובות שגויות, משחזרים ביצוע חלקי. בודקים אם הכול נסגר, כמה זמן זה לקח והאם נותר עקבות ביומן.
- הגנה מפני חזרות. מגדירים מה קורה לאחר ההפעלה: חסימת כניסות חדשות, ניסיונות חוזרים במרווח גדל, התראה לאחראי והרכב הנתונים לניתוח מאוחר יותר.
- מסירת תיעוד. מוסרים את מפת הטריגרים, תקנון ההתערבות הידנית, הוראות לבדיקה עצמאית ופרוטוקולי הרצות בדיקה — המהנדסים שלכם יוכלו לשחזר את הבדיקה בלעדינו.
הרכב האספקה: תצורות, מפות, תקנונים
המסירה אינה דוח, אלא ערכה עובדת: לפיה המהנדס שלכם יפעיל את מעגל הסגירה בחירום, יבדוק אותו וישחזר אותו לאחר כשל בלעדינו. הארטיפקטים מונחים לצד קוד הבוט ומנוהלים בגרסאות יחד איתו.
- תצורת טריגרים — ספים ותנאים: ירידת המרווח, אי-התאמת מחיר בין פלטפורמות, אי-זמינות מקור הציטוטים, פסק זמן בתגובת הפלטפורמה. לכל טריגר עדיפות משלו, השהיה משלו והתנהגות משלו בהפעלה חוזרת.
- מפת הזרימות — המסלול מההפעלה ועד האישור: ביטול ההזמנות הפתוחות, הבדיקות לפני הסגירה, הרישום ביומן. בנפרד מסומנים ענפי הכשל ונקודות ההתערבות הידנית.
- מדיניות גישה — תפקידי המפעיל, המהנדס והצופה, מטריצת הרשאות לעריכת ספים, הפעלה ידנית והסרת חסימה. בנוסף כללים לאחסון מפתחות וחתימות סף לפעולות קריטיות.
- תקנון המפעיל — מה לעשות שלב אחר שלב בעת הפעלה, עם קריטריונים ל«להתערב או לא» וגבול שמעבר לו האוטומציה נעצרת.
- הוראות שחזור — בדיקת התאמת הפוזיציות מול היומן, בדיקת היתרות, סדר ההפעלה מחדש ובקרת העסקאות הראשונות לאחר החזרה.
- תרחישי בדיקה — הרצות בסביבת בדיקות, כולל הדמיית ניתוק קשר עם הפלטפורמה והפעלה חוזרת של הטריגר.
לכל סעיף מצורף הסבר: לשם מה נדרש הארטיפקט ומה נשבר בלעדיו. בקבלה עוברים על הרשימה יחד עם הצוות שלכם.
מקרה בוחן: עצירת הבוט בשניות בעת ניתוק ערוץ
צוות הלקוח ניהל מסחר באמצעות בוט על Binance, והתקנון לניתוק ערוץ היה ידני: התורן קיבל התראה, התחבר, בדק את מצב החשבון וסגר פוזיציות במסוף. מניתוק הקשר ועד הפוזיציה הסגורה האחרונה חלפו 40 עד 90 שניות, וחלק מההזמנות ברמות הרחוקות נשארו תלויות — אותן ביטלו כבר בבוקר. משמרות הלילה התנהלו במחזוריות והביאו 5-6 התעוררויות בשבוע לכל מהנדס.
מה שינו
הרכיבו תרחיש אוטומטי לסגירה בחירום עם שלושה סימני הפעלה בלתי תלויים: היעלמות אות נוכחות מהערוץ, אי-התאמה בין היתרה בפועל לזו המחושבת, כשל ממשק המסחר.
לפני הסגירה התרחיש בודק את מצב הפוזיציות בפועל, ואחריה — בדיקת בקרה שלא נותרו נפחים פתוחים; ניסיונות חוזרים מתבצעים בהשהיה גדלה, כדי לא להפציץ את הבורסה בעת הידרדרות רשת.
אישור מוטמע גם בחריגים: אם נפח הפוזיציה גבוה מהסף שנקבע, התרחיש מעניק לתורן חלון להחלטה ידנית, ועם תום החלון סוגר לפי השוק. כל פעולה נרשמת ביומן שרשומות רק מתווספות אליו: הזמן, סיבת ההפעלה, התוצאה לכל פוזיציה. האירוע מנותח לפי עובדות, ולא לפי זיכרונות.
מה השתנה
זמן העצירה הצטמצם מ-40-90 שניות ל-3-5, שיעור הפוזיציות הסגורות עלה מכ-70% לכ-100%. התעוררויות לילה לא נותרו: התורן מקבל התראה ומנתח את המקרה בבוקר, כי התרחיש כבר פעל והשאיר יומן.
התרחיש עצמו נשלט על ידי דגל תצורה — אפשר לכבות אותו בזמן עבודות מתוכננות ולהחזיר אותו בתיקון אחד.
במה נבדלת עצירת חירום של הבוט מעצירה מתוכננת?
עצירה מתוכננת היא חלון ידוע מראש: עדכון אסטרטגיה, החלפת מפתחות, סוף סשן המסחר. הפוזיציות נסגרות בהדרגה, בפקודות לימיט, והעדיפות כאן היא מחיר הביצוע, ולא הזמן. המפעיל רואה את התוכנית, מאשר את השלבים ויכול לדחות את הסגירה אם השוק באותו רגע נותן מחיר גרוע.
עצירת חירום מופעלת על ידי טריגר: עלייה חדה בתנודתיות, אובדן הקשר עם הבורסה, ירידת המרווח מתחת לסף, אי-התאמה בין הפוזיציות בפועל לזו המחושבת. העדיפות מתהפכת — לסגור את הפוזיציות כמה שיותר מהר, ולכן הסגירה מתבצעת בפקודות שוק, וההחלקה מתקבלת במודע. ההיגיון פשוט: פוזיציה שממשיכה להפסיד כל עוד הבוט אינו זמין עולה יותר מאשר סטייה במחיר הכניסה.
ההבדל המרכזי הוא באישור. עצירה מתוכננת אינה מתחילה ללא הסכמת המפעיל. עצירת חירום פועלת לפי כלל מאושר מראש: אין לשאול רשות ברגע ההפעלה, כי בעוד המפעיל קורא את ההתראה ומשיב, הפוזיציה ממשיכה להעמיק. הספים ורשימת מה שנחשב לחירום מתאמים מראש — המפעיל משתתף בתכנון התרחיש, ולא בביצועו.
לאחר ההפעלה, מעורבותו של המפעיל אינה מסתיימת. הוא בודק שכל הפוזיציות סגורות, שלא נותרו פקודות תלויות ושהאסטרטגיה אכן נעצרה, ולא רק הפסיקה לפתוח חדשות. הניתוח לפי היומנים מראה איזה טריגר פעל ובאיזה סדר הלכו הפקודות. עצירה מתוכננת הפיכה: לאחריה הבוט מופעל כשורה. עצירת חירום דורשת לוודא שהסיבה טופלה והיתרה מתאזנת.
ספקות טכניים לפני תחילת הפרויקט
חלק מהשאלות חוזרות בכל הערכה, והן נוגעות לא לקוד, אלא לגבולות המערכת: מה בדיוק מפעיל את הטריגר, מה לעשות עם יתרה שלא בוצעה ומי אחראי לתוצאות. להלן — התשובות בצורה שבה אנו נותנים אותן לפני תחילת העבודות.
כיצד המערכת מבדילה בין כשל אמיתי להפעלה שגויה?
הטריגר מורכב ממספר תנאים בלתי תלויים: סטייה של המחיר מערך הייחוס, קריסת נזילות, אי-התאמה בין מקורות הציטוטים. האות חייב להחזיק לאורך פרק זמן מוגדר — פרץ בודד אינו מפעיל.
מה קורה אם נסגר רק חלק מהפוזיציה?
סוגרים את הנפח הזמין עם הגבלה על ההחלקה, את היתרה מסמנים כלא מסולקת ומסלים בהתראה. היומן שומר את שני החלקים, ולכן הפוזיציה אינה נשארת תלויה בלי ששמים לב.
היכן מסתיים אזור האחריות של הצוות שלכם?
אנו אחראים על לוגיקת הטריגר, תקינות הקריאות ושלמות היומן; הבורסה — על ביצוע הפקודות וזמינות הממשק שלה. ההתנהגות בעת אי-זמינות הפלטפורמה מוגדרת בנפרד, וההחלטה על עצירת המסחר נשארת בידי בעל המערכת.
האם אפשר להטמיע את המודול בבוט שכבר פועל?
המודול מתחבר כשכבה נפרדת עם ערוץ נתונים משלו ונוגע בלוגיקת המסחר באופן מזערי. ההרצה הראשונה היא בצל: הפעלות נספרות ומתועדות, פקודות אמיתיות אינן נשלחות, עד שההתנהגות תתאים למצופה.
מה עם המגבלות של הבורסה?
לפלטפורמות יש מגבלות משלהן על תדירות הפניות, מצבי הפחתת סיכון וכללי סגירה בנזילות נמוכה. אנו אוספים את המגבלות הללו עבור הבורסות שלכם בשלב הסקר ומכניסים אותן לתרחישים מראש.
נדון במשימה ונחזור עם הערכה ותוכנית
כדי להתחיל בלי לעשות שוב, אנחנו צריכים לא מסמך טכני מוכן, אלא תיאור של תרחישים: מה בדיוק במסחר שלכם נחשב לחירום ואיזו תוצאה נדרשת בסוף. להלן — מה אנחנו מבהירים בניתוח הראשון ובאיזה סדר אנו מתקדמים לעבר מעגל עובד.
- הצגת המשימה. אילו אירועים נחשבים לחירום: פריצת סטופ, חוסר סנכרון בין הפוזיציות לבורסה, ניתוק קשר, התקרבות למגבלת המרווח, פקודה ידנית של המפעיל.
- מטריצת עדיפויות. מה עושים בכשל חלקי — סוגרים את כל התיק או רק את המכשירים הבעייתיים, ומה נחשב לסיום מוצלח של ההפעלה.
- מלאי הסביבה. רשימת הבורסות וסוגי החשבונות, מפתחות גישה עם ההרשאות הנדרשות, מגבלות על תדירות הבקשות, סדר אחסון הסודות.
- מעגל האישור. כיצד הבוט מקבל את הפקודה, כיצד בודק את הפוזיציות בפועל לאחר הסגירה ומה עושה אם חלק מההזמנות לא בוצע.
- תפקידים והתראות. מי מקבל את ההתראה, מי מאשר הפעלה ידנית ולמי יש זכות לבטל הפעלה אוטומטית.
- הערכת לוחות זמנים. מפרקים את ההיקף לפי תרחישים ומציינים לוחות זמנים עם נקודות בדיקה: ההערכה קשורה לרשימה קונקרטית, ולא למשימה «ממוצעת».
- תוכנית הטמעה והרצת פיילוט. תחילה מעגל בדיקות עם הדמיית ניתוקים וכשלים, ולאחר מכן פיילוט על נפח מוגבל עם פוזיציות אמיתיות.
- תמיכה לאחר ההרצה. תורנות לתקופת הניטור, ניתוח יומני ההפעלות, כוונון משלים של הספים והתנאים.
אם אין עדיין תיאור תרחישים — נבנה אותו יחד בניתוח. תארו את המשימה, ונחזור עם הערכת לוחות זמנים ותוכנית עבודה.







