פיתוח מערכת לניהול מספר בוטים למסחר

מערכת ניהול בוטים: היכן נשברת התמיכה הידנית

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

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

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

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

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

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

מה נותן קו ניהול אחיד לאסטרטגיות

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

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

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

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

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

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

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

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

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

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

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

מה הלקוח מקבל לידיו לאחר ההטמעה

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

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

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

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

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

מה שינינו

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

מה זה נתן

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

במה שונה קו אחיד מקבוצה של סקריפטים נפרדים

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

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

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

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

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

ספקות טכניים לפני תחילת הפרויקט

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

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

מה יקרה לפוזיציות פתוחות בעת אתחול מחדש?

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

אילו הרשאות גישה נדרשות למערכת?

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

האם ניתן להשתמש בקוד הקיים?

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

נדון במשימה: מה להכין לשיחה

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

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

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