פיתוח בוט מסחר: היכן נשברים פתרונות עצמאיים
בוט מסחר עצמאי בדרך כלל עובר בביטחון בדיקות בשוק רגוע ונשבר בדקות הראשונות של תנודתיות אמיתית. הסיבה אינה באסטרטגיה, אלא בתשתית ההנדסית: היא נכתבה עבור "המסלול המאושר", שבו הזמנה תמיד מתבצעת במלואה, תגובת הבורסה מגיעה באופן מיידי, והמפעיל מספיק להגיב ידנית.
הכשל הנפוץ ביותר — חוסר סנכרון בפוזיציה. הבוט מחזיק בתפיסה משלו לגבי היתרה והנפחים הפתוחים, אך נבדק מול הבורסה לעיתים רחוקות או לא נבדק כלל. הזמנה אחת שבוצעה חלקית, פקודה שנדחתה או ניתוק חיבור ברגע ההגשה — והמצב המקומי סוטה מהמצב האמיתי. לאחר מכן הבוט מחשב סיכון מבסיס שגוי ופותח נפח שאינו קיים בחשבון.
צוואר הבקבוק השני — תנאי מרוץ (race conditions) בהזמנות בו-זמניות. אותות מגיעים ממספר מקורות, המטפלים כותבים לאובייקט מצב משותף ללא נעילות, ובקשה חוזרת להגשה אינה מזוהה ככפילות. התוצאה — פוזיציות מוכפלות ופקודות סטופ שאף אחד לא הגיש. לרוב אין בקרת מגבלות: בדיקת הפוזיציה המקסימלית נמצאת במקום נפרד ואינה מיושמת על כל נתיב ביצוע.
השלישי — התערבות ידנית בדיוק כשהכי מסוכן. ללא יומן החלטות, מדדי השהיית תגובה והתראות, המפעיל לומד על הבעיה דרך ירידה (drawdown), ולא דרך אירוע.
בפיתוח תעשייתי של בוט מסחר, נקודות אלה נסגרות מראש: סנכרון תקופתי עם הבורסה כמקור אמת, מפתחות אידמפוטנטיים לכל הזמנה, מגבלות בתוך אותו מטפל ועצירה אוטומטית בעת אי-התאמה. כיצד זה בנוי במערכת שלנו — נפרט בהמשך.
מה נותן בוט מסחר בניהול חיצוני
הניהול של בוט המסחר מועבר למעגל חיצוני: פקודות, פרמטרים ודגלי עצירה מגיעים מהצד השרת, ולא מחלון הטרמינל. בגלל זה, התגובה לאירוע שוק מתבצעת בשברירי שנייה — באופן ידני הסוחר לא מספיק להעריך את ספר הפקודות או להגיש הזמנה. מהירות התגובה מפסיקה להיות תלויה במי שתורן ליד המסך.
בקרת סיכון מובנית לפני שליחת ההזמנה, ולא אחריה. מגבלת גודל פוזיציה, הפסד יומי ומספר עסקאות ליחידת זמן נבדקים בכל אות, ולכן פקודה שמפרה את הכללים אינה יוצאת לשוק. כך נסגר סוג שלם של כשלים: נפח מבולבל, הזמנה מיותרת, סטופ שהוסר ידנית.
יציבות הלוגיקה המסחרית נשענת על כך שהכללים והפרמטרים מועברים לקונפיגורציה ומנוהלים בגרסאות. החלפת אסטרטגיה היא גרסה נפרדת שניתן לחזור ממנה, ולא תיקון של קוד קרבי בשרת. לאחר תקלה, הבוט עולה ומשחזר מצב מיומן העסקאות ומהפוזיציות הפתוחות.
אוטומציה של ביצוע ניכרת בשיעור המצבים שהבוט מטפל בהם ללא אדם: כניסות ויציאות טיפוסיות, העברת סטופים, סגירה לפי זמן. המפעיל מתערב רק היכן שנדרשת החלטה — למשל, במקרה של אנומליה בנתונים או עצירה של הפלטפורמה.
זמן ההתאוששות נמדד בדקות: המצב אינו נאסף ידנית, אלא עולה מהיומן, וההזמנות נבדקות מול הפוזיציות בפועל. בהמשך נפרט כיצד מעגל כזה נבנה ומה נשאר בשליטת הצוות.
אפשרויות ביצוע: ענן, מעגל ייעודי, היברידי
מיקום הבוט קובע לא את המהירות של הזמנה בודדת, אלא כיצד המערכת שורדת תקלה: ניתוק ערוץ לבורסה, נפילת צומת, השהיית רשת ברגע התרחבות המרווח. הבחירה מצטמצמת לשלוש סכמות, והן נבדלות לא בעוצמת החומרה, אלא במי שאחראי על הזמינות ועל שמירת המפתחות.
גם התקנון קובע את מגבלות ההפעלה: היכן נשמר יומן העסקאות, למי יש גישה אליו, כמה זמן מותר להיות מחוץ לשוק. מכאן טבלת ההתאמה — לפיה בדרך כלל נפתר הוויכוח בתוך הצוות.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| ענן ציבורי | התחלת אסטרטגיה, סט קטן של כלים, היסטוריית עסקאות יכולה להישמר אצל הספק | שכנות לעומס זר, השהיית רשת לא יציבה, מגבלות בצד הספק |
| מעגל ייעודי | עבודה לפי תקנון פנימי: מפתחות ויומן עסקאות נשארים בתשתית שלך | תורנות, עדכונים וערוץ תקשורת גיבוי — הלקוח מכסה בכוחות עצמו |
| סכמה היברידית | ליבת מסחר דורשת השהיה מינימלית, ואילו חישובים ודיווח — סביבה מנוהלת | יש לקשר ולסנכרן שני מעגלים; הפער ביניהם הופך בעצמו לנקודת כשל |
עמידות המערכת בפני תקלות נבנית לפי לוגיקה אחת: העתק מצב, אתחול אוטומטי של התהליך, ערוץ גיבוי לבורסה. במעגל ייעודי, מתזמר כמו Kubernetes מעלה תהליך שנפל תוך שניות, בענן הספק עושה זאת, ובהיברידי — שני הצדדים, לכן גבולות האחריות מתוארים בתקנון מראש.
כיצד מתבצע היישום: מניתוח אסטרטגיה ועד מסירה
לפני כתיבת הקוד, המהנדסים מתארים את לוגיקת המסחר הנוכחית: אילו אותות, באיזה מחיר מוגשות הזמנות, מה קורה בביצוע חלקי ובניתוק חיבור. אחרת הבוט משחזר את טעויות המסחר הידני — רק מהר יותר.
סדר הפעולות ונקודות ביקורת
- ביקורת לוגיקה. מנתחים כניסה ויציאה, עבודה עם מינוף, מיצוע, פקודות סטופ. קובעים אילו החלטות נשארות בידי האדם ומה לעשות עם פוזיציה לא סגורה בסוף הסשן.
- סכמת אינטראקציה עם פלטפורמות. קובעים אילו נתונים זורמים בזרם ציטוטים, אילו — בבקשות נפרדות, וכיצד נשמרים מפתחות הגישה. מפרידים הרשאות: משיכת כספים אינה זמינה לבוט.
- ניהול ומגבלות. מעגל ניהול דרך ממשק תוכנה: הפעלה ועצירה, שינוי פרמטרים תוך כדי תנועה, הגבלות על נפח פוזיציה, מספר הזמנות והפסד יומי עם עצירה אוטומטית.
- בדיקה על היסטוריה. הרצה על נתונים היסטוריים תוך התחשבות בעמלות, החלקה (slippage) והשהיות, ואחר כך על מעגל בדיקות של הפלטפורמה. סטייה מהמסחר הידני — סיבה להרכיב מחדש את הלוגיקה, ולא לכוונן פרמטרים.
- מבחני קבלה. ניתוק חיבור, שליחה חוזרת של הזמנה, חוסר ביתרה, תנועת מחיר חדה. לכל תרחיש — התנהגות צפויה ורישום ביומן.
- מסירה לתפעול. הלוגיקה והקונפיגורציה מנוהלות בגרסאות ב-Git: חזרה למצב קודם אורכת דקות. מוסרים סכמה, הוראות, גישות; בהמשך — ליווי ושדרוג עם שינוי כללי הפלטפורמה.
קונפיגורציות, סכמות ותקנונים שאתם מקבלים
פיתוח בוט מסחר מסתיים לא בתהליך עובד, אלא בחבילה שלפיה ניתן להפעיל אותו, לתחזק אותו ולהעביר אותו לצוות אחר. להלן מה שנמסר לכם יחד עם הקוד: קונפיגורציות, סכמות, מדיניות ותקנונים.
- קבצי קונפיגורציה של בוט המסחר — פרמטרים של אסטרטגיה, זוגות מסחר, מגבלות נפח וסיכון, מתג בין מצב בדיקות למצב קרבי. הכל מוצא מהקוד: ההתנהגות משתנה בתיקון קונפיגורציה, ללא בנייה מחדש.
- סכמות אינטגרציה — כיצד הבוט מחובר לפלטפורמות דרך REST API לניהול, היכן נשמר מצב הפוזיציות והפקודות, מה קורה בניתוק חיבור ובשליחה חוזרת של בקשה.
- מדיניות גישה ותפקידים — מפתחות עם הרשאות מצומצמות, הפרדה בין קריאה, מסחר וניהול, נוהל רוטציה של סודות ומקום אחסונם.
- סכמת אחסון מצב — מבנה יומן העסקאות והאירועים, תקופת שמירה, נוהל העלאת מצב לאחר נפילת תהליך ללא כפילות פקודות.
- תקנוני תפעול — מה לעשות בעת חוסר סנכרון פוזיציות, אי-זמינות פלטפורמה או הפעלת מגבלת הפסדים: צעדים, אחראים, זמני תגובה.
- ניטור והתראות — רשימת מדדים, ספי הפעלה, ערוצי הודעה ונוהל בדיקה לפני יציאה למצב קרבי.
- תיעוד הבוט — תיאור האסטרטגיה, פירוט הקונפיגורציה, הפעלה מאפס וחזרה לגרסה קודמת.
מקרה בוחן: בוט לאסטרטגיית ארביטראז' בשלוש פלטפורמות
המשימה הגיעה מצוות שאיחד פוזיציות בשלוש פלטפורמות באופן ידני. פערים בין מה שהבוט חשב כפוזיציה שלו לבין מצב החשבון בפועל הצטברו לקראת סוף המשמרת, והתגובה לפער מחירים ארכה עשרות שניות — בזמן הזה חלון אסטרטגיית הארביטראז' הספיק להיסגר. חלק מהפערים נבעו מביצועים חלקיים והזמנות שנדחו בפלטפורמות כמו Bybit.
| מדד | לפני | אחרי |
|---|---|---|
| שיעור הפערים בין הפוזיציה למצב החשבון בפועל | 5–8% עסקאות למשמרת | פחות מ-0.2% |
| זמן תגובה לפער מחירים בין פלטפורמות | 40–90 שניות | 1–2 שניות |
| התערבויות ידניות למשמרת | 25–30 | 0–2 |
| התאוששות לאחר ניתוק חיבור | הפעלה מחדש וסנכרון ידניים | קליטה אוטומטית של המצב |
שינינו את שיטת הרישום: הפוזיציה נבנית מביצועים מאושרים, ולא מהזמנות שנשלחו, ונבדקת מול מצב החשבון לאחר כל אירוע. שליחה חוזרת מתבצעת עם מפתח ייחודי, ולכן כפילות אינה פותחת פוזיציה שנייה.
הוספנו תנאי עצירה: אם פער המחירים יוצא מגבול הנזילות או שהפלטפורמה מפסיקה להגיב, הבוט מסיר הזמנות וממתין, ולא משלים פוזיציה במחיר לא משתלם.
מבחינת תפעול: יומן של כל החלטה, התראות לערוץ הצוות וסט ברור של סיבות לעצירה. הניהול מועבר דרך ממשק תוכנה חיצוני, ולכן חיבור פלטפורמה נוספת הוא הגדרה, ולא כתיבה מחדש של ליבת האסטרטגיה.
במה שונה REST API לניהול מחיבורים ישירים לבורסה?
חיבור ישיר לפלטפורמה משמעו שהבוט עצמו מחזיק במפתחות המסחר, עצמו סוקר את השוק של הפלטפורמה הנדרשת ועצמו שולח הזמנות. כל עוד יש פלטפורמה אחת, זה מוצדק: צומת אחד, סט מפתחות אחד, מינימום שכבות בין האות להזמנה. הבעיה מתגלה עם הפלטפורמה השנייה ועם האדם הראשון בצוות שזקוק לגישה.
REST API לניהול מציב בין האסטרטגיה לפלטפורמות ממשק אחיד. פקודות יוצאות בפורמט אחד, מצב מגיע בפורמט אחד, וההבדלים בין הפלטפורמות — זוגות מטבע, סוגי הזמנות, עיגולים — מוסתרים על ידי מודולי מחברים (connectors). הוספת פלטפורמה חדשה מפסיקה להיות כתיבה מחדש של הבוט: נכתב מחבר אחד, ולוגיקת האסטרטגיה אינה נגעת.
הפרדת הרשאות — הדבר השני שמשתנה. בחיבורים ישירים, מפתחות המסחר מתפשטים לכל הצמתים, וכל סקריפט בשרשרת הזו יכול למשוך כספים. דרך ממשק הניהול ניתנות רק ההרשאות הנדרשות: לאסטרטגיה — להגיש ולהסיר הזמנות, למודול הסיכון — לסגור פוזיציות בכפייה, למפעיל — לקרוא מצב. מפתחות הפלטפורמה חיים במקום אחד, ואינם נמסרים החוצה.
ביקורת פעולות מופיעה כתוצר לוואי. הממשק האחיד כותב יומן: מי ומתי שינה פרמטרים, איזו פקודה יצאה לפלטפורמה, איזו תגובה חזרה. בחיבורים מפוזרים, יש לאסוף את העקבות מיומני כל תהליך, ולהשוות זמנים ידנית. עצירת הבוט גם היא הופכת לפקודה אחת, ולא לסבב בכל החיבורים.
חיבור ישיר נשאר הגיוני בפלטפורמה אחת עם אסטרטגיה אחת. ברגע שיש יותר פלטפורמות, יש תפקידים בצוות ודרישות לנתח תקלות בדיעבד — שכבת הניהול משתלמת, וקל יותר להוסיף אותה בהתחלה מאשר אחר כך.
ספקות טכניים שכדאי להסיר לפני ההתחלה
לפני הפעלת הבוט עולים אותן שאלות: מה יקרה לפוזיציות בעת ניתוק חיבור, מי מחזיק במפתחות הגישה, כיצד לבדוק את הלוגיקה לפני עבודה עם יתרה אמיתית. להלן תשובות שמסירות ספקות טכניים לפני ההתחלה.
מה יקרה אם הפלטפורמה תשנה את הכללים או את מגבלות הפעולות?
מגבלות על פעולות, צעד מחיר וגודל הזמנה מינימלי משתנים ללא התראה. אנו מוציאים אותם לקונפיגורציה, ולא לקוד, — התיקון אורך דקות. הזמנה שנדחתה אינה חוזרת שוב על ידי הבוט באופן עיוור: הוא מתעד את הסיבה ומפחית פעילות עד לאישור.
האם אפשר להעביר אסטרטגיה שכבר עובדת?
כן, אם לאסטרטגיה יש תנאי כניסה ויציאה פורמליים. אנו מתארים אותה כסט כללים ומריצים במעגל בדיקות על נתונים היסטוריים, תוך השוואת התוצאה למימוש הנוכחי. לוגיקה שנשענת על החלטות ידניות תדרוש פורמליזציה — נאמר זאת מראש.
מה קורה בעת ניתוק חיבור?
מצב העסקאות נשמר בנפרד מהחיבור, ולכן ניתוק אינו מאבד פוזיציות. לאחר השחזור, הבוט משווה את נתוניו עם אלה שבפועל בפלטפורמה וממשיך מהמצב המאושר. פעולות קריטיות ברגע אי-זמינות נחסמות: פספוס כניסה בטוח יותר מאשר פתיחת פוזיציה פעמיים.
מי אחראי על מפתחות הגישה וכיצד לבדוק עסקאות לפני ההפעלה?
מפתחות אינם נשמרים בקוד ואינם נמסרים בצורה גלויה. אנו מנפיקים הרשאות מוגבלות: משיכת כספים חסומה, רק סט הפעולות הנדרש זמין, והמפתח ניתן לביטול בכל רגע. הבדיקה מתבצעת במעגל בדיקות — אותו קוד ואותן בדיקות, אך ללא ביצוע על יתרה אמיתית.
נדון במשימה שלכם ונחזור עם תוכנית יישום
כדי שהערכת העבודה תתבסס על עובדות ולא על ניחושים, את השיחה הראשונה נבנה סביב מעגל המסחר הנוכחי שלכם. די לתאר את המשימה במילים: אילו פלטפורמות, מהי לוגיקת הכניסות והיציאות, מי וכיצד מנהל את הפוזיציות כעת ומה אתם רוצים לקבל מהבוט.
- פלטפורמות וכלים: שוק נכסי בסיס או נגזרים, מעגל בדיקות או חשבון פעיל;
- גישות: מפתחות API, הפרדת הרשאות לקריאה ולמסחר, מגבלות הפלטפורמה על תדירות בקשות;
- אסטרטגיה: מקורות אותות, טיימפריימים, כללי כניסה ויציאה, טיפול בביצוע חלקי;
- מגבלות סיכון: גודל פוזיציה מקסימלי, סטופ יומי, התנהגות בעת ניתוק חיבור וניסיונות חוזרים;
- מעגל ניהול דרך REST API: אילו פקודות מגיעות מבחוץ, כיצד מועבר מצב, יומן עסקאות ודיווח;
- תשתית: היכן ממקמים, כיצד מפעילים מחדש, כיצד משווים פוזיציות ויתרה מול הפלטפורמה.
לאחר השיחה נשלח תוכנית יישום: סכמת המעגל, היקף העבודה, שלבים עם תוצאה ניתנת לבדיקה, נוהל קבלה והערכת עבודה לכל שלב. הפעלה פיילוט נעשית בנפח מוגבל — הלוגיקה נבדקת על נתונים אמיתיים, מבלי לפגוע בחשבון הראשי.
תארו את המשימה בצורה חופשית: פלטפורמה, אסטרטגיה וסדר העבודה הנוכחי. נחזור עם הערכה ותוכנית יישום.