פיתוח מערכת החלפה חמה של אסטרטגיות עבור בוטים למסחר

למה החלפה חמה (hot-swap) של אסטרטגיות נשברת במסחר חי

החלפה חמה (hot-swap) של אסטרטגיות נראית כמו פעולה פשוטה: לעצור לוגיקה אחת, להעלות אחרת, בלי לכבות את מעגל המסחר. בדיוק ברגע הזה הבוט מתפצל ממה שמצוי באמת בבורסה — ומחיר הטעות נמדד לא בשעות השבתה, אלא בפוזיציה פתוחה שאיש אינו מנהל.

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

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

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

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

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

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

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

מה משתנה לאחר הטמעת החלפה מנוהלת של הלוגיקה

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

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

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

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

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

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

מצבי החלפה: hot-swap של אסטרטגיות מול הפעלה מחדש מלאה

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

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

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

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

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

שלבי ההטמעה: מביקורת המעגל ועד מסירה לפעולה

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

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

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

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

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

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

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

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

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

מדדים לפני ואחרי

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

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

מה לעשות אם דיספצ'ר הקונפיגורציות כבר שלכם?

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

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

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

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

שאלות טכניות: בדיקה, החזרה, פוזיציות פתוחות

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

האם אפשר להחזיר גרסת אסטרטגיה?

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

היכן גבולות ההחלפה החלקית של החוקים?

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

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

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

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

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