פיתוח מסוף מסחר: היכן נשברות מערכות עצמאיות
מסוף עצמאי כמעט תמיד מתחיל כעטיפה דקה מעל ממשקי הבורסה: מנוי לספר פקודות, שליחת הזמנות, רישום מקומי של פוזיציות ויתרות. ב-Binance ובפלטפורמות גדולות אחרות אב-טיפוס כזה נבנה תוך שבועות ספורים ועובד נאמנה בשוק רגוע. הוא נשבר כבר בסשן התנודתי הראשון — ולא בפרטים קטנים, אלא בשלושה-ארבעה מקומות צפויים.
חוסר סנכרון של שערים נוצר מפני שזרם העסקאות, ספר הפקודות ואירועים פרטיים עוברים בערוצים שונים עם השהיה שונה.
אם בעת ניתוק החיבור המסוף מתחבר מחדש בלי לבקש תמונת מצב מלאה של ספר הפקודות ובלי לבנות מחדש את המצב המקומי, בהיסטוריה נשאר "חור": בממשק מחיר אחד, והביצוע מתבצע לפי אחר. הסוחר מקבל החלטה לפי תמונה מיושנת, וזה כבר לא קוסמטיקה של תצוגה.
אובדן הזמנות — הקלאסיקה השנייה. הזמנה נשלחה לבורסה, החיבור נותק לפני התגובה, והמסוף לא יודע: הפקודה התקבלה או לא. בלי מפתח אידמפוטנטי שליחה חוזרת יוצרת כפילות, ובלי התאמה לפי יומן ביצועים במערכת נשארת פוזיציה "תלויה", שמבחינים בה כבר לפי המרווח.
עומס שיא מחסל את מה שנשאר. בתנועה חדה תדירות העדכונים עולה בסדר גודל, תור האירועים גדל מהר יותר ממה שהממשק מצליח לעכל, ובדיקות טרום-מסחר — מגבלה על נכס, גודל פוזיציה מקסימלי, בקרת החלקה — במערכת עצמאית בדרך כלל אין בכלל. פוזיציות מותאמות ידנית, אי-התאמות צפות למחרת. ננתח כיצד כל אחד מסוגי הכשלים הללו נסגר ארכיטקטונית.
מה נותן מסוף תעשייתי: מהירות, עמידות, שליטה
מהירות ביצוע ההזמנות נמדדת לא לפי תגובה ממוצעת, אלא לפי זנב ההתפלגות — שיעור ההזמנות שעמדו בסף היעד ברגע עומס שיא. במסוף מנוהל המסלול החם של הצבת וביטול הזמנה מופרד מאנליטיקה, היסטוריה ודיווח: גידול במספר הנכסים והמנויים לנתוני שוק כבר לא מטשטש את תגובת ליבת המסחר.
עמידות המסוף לתקלות נבדקת בתרחישים, לא בהבטחות: ניתוק מהבורסה, אתחול הליבה, אי-התאמה בין המצב המקומי למצב הבורסה.
לאחר תקלה המסוף מתאים פוזיציות והזמנות פעילות לפי יומן הפעולות, משלים את מה שנשאר במצב לא גמור, ומסנן כפילויות — סוג הכשלים "הזמנה כפולה" ו"פוזיציה אבודה" יוצא משימוש.
מגבלות ובקרת סיכונים פועלות לפני יציאת ההזמנה לבורסה: נבדקים נפח לנכס, חשיפה כוללת לפי כיוון, תדירות הצבות ועצירה אוטומטית לאחר סדרת עסקאות מפסידות. הכללים מנוהלים בגרסאות, שינוי עובר אישור ושוקע ביומן — רואים מי ומתי החליש או החמיר את המגבלה.
ניטור המסחר נשען על מדדי שגרה: שיעור הזמנות שבוצעו, זמן הצבה וביטול, עומק אי-ההתאמה עם מצב הבורסה, מספר סירובים לפי כללי סיכון. הספים נקבעים כך שהאות יגיע לפני שאי-ההתאמה תהפוך להפסד. יש לקבל מסוף לפי ארבעת הצירים הללו — במספרים מדידים, לא בפונקציונליות מוצהרת.
מצבי עבודה: מאפס, התאמה אישית של מוכן, תוכנית היברידית
שלושת המצבים נבדלים לא בנפח הקוד, אלא במי שמחזיק בליבה וכמה זמן עובר עד לפקודה אמיתית ראשונה. את המצב בוחרים לפי שני סימנים: האם יש כבר מוצר עובד עם משתמשים חיים וכמה לא שגרתית לוגיקת הביצוע וחשבונאות הכספים.
ציר בחירה נפרד — חיבור לפלטפורמות מסחר. כל בורסה חדשה משמעה סט משלה של מפתחות, מגבלות, פורמטי פקודות וכללי התאמת יתרות; דווקא כאן לרוב מערבבים מצבים, כדי לא לכתוב מחדש מודול שכבר עובד.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| פיתוח מאפס | דרושה לוגיקת ביצוע משלך, מבנה סיכון לא שגרתי או ממשק אחיד למספר פלטפורמות בבת אחת | זמן ארוך יותר עד למהדורה ראשונה: הליבה והמחברים נכתבים, נבדקים ומתוקנים תחת עומס מאפס |
| התאמה אישית של פלטפורמה מוכנה | הבסיס כבר עובד, המשימה — להוסיף פלטפורמות, נכסים, דיווח או לתקן התנהגות בשיאי עומס | יורשים ארכיטקטורה, סכימת נתונים והגבלות רישוי של הספק; חלק מהתיקונים נתקל בקוד סגור |
| תוכנית היברידית | מודול קריטי — התאמת פקודות, תיק, בקרת סיכונים — דרוש משלך, את השאר מהיר יותר לקחת מוכן | נדרש גבול ברור בין הליבה שלך למודולים חיצוניים; בלי פרוטוקול החלפה יציב, התחזוקה מסתבכת עם כל עדכון |
מצפן מעשי: כל עוד צוואר הבקבוק במודול אחד — די בהתאמה אישית; כשהמגבלות מתחילות להכתיב את המוצר ולא את המשימה — עוברים להיברידי או לליבה משלנו. בהמשך ננתח מה בדיוק בודקים בכל אחד מהמסלולים הללו.
סדר עבודה: מביקורת לוגיקת ההזמנות ועד העברה לתפעול
מסוף אינו ממשק מעל חיבורי בורסה. עיקר העבודה מתרחשת בלוגיקת ההזמנות: מחזור חיים של פקודה, ביצועים חלקיים, ביטולים, שליחות חוזרות בעת ניתוק. להלן המסלול שבו אנו מובילים פיתוח מסוף מסחר, כדי שעד ההשקה לא יישארו תרחישים לא בדוקים.
- ביקורת לוגיקת המסחר. מפרקים את המעגל הנוכחי: אילו סוגי הזמנות משמשים, כיצד מטופלים ביצועים חלקיים, היכן אובד המצב בעת ניתוק ערוץ. מתעדים אי-התאמות בין החשבונאות במסוף לבין הפוזיציות בפועל בפלטפורמה.
- תרשים אינטגרציות. מתארים חיבורים לפלטפורמות מסחר, זרמי שערים ועסקאות, אחסון מפתחות גישה, תפקידי משתמשים. את התרשים מאשרים לפני הקוד — שינוי שכבת ההחלפה עולה יותר מכל השאר.
- הגדרת הליבה. תור הזמנות, הגנה מכפילויות, מגבלות סיכון על חשבון ונכס, כללי התאמת פוזיציות ושחזור מצב לאחר חיבור מחדש.
- בדיקה תחת עומס. משחזרים זינוקי שערים, השהיות תגובת פלטפורמה וניתוקי ערוץ: עוקבים אחרי הופעת הזמנות כפולות ואי-התאמות יתרה.
- קבלת המסוף. מריצים תרחישים על נפחים אמיתיים אך מוגבלים, מתאימים דוחות, סוגרים הערות לפי יומנים וטיפול בשגיאות.
- העברה לתפעול. מוסרים תיעוד, גישות, ניטור עם התראות על תקלות והוראות לתמיכה; נשארים בקשר בימים הראשונים לעבודה.
ערכת מסירה: תצורות, תרשימי אינטגרציה, נהלים
מסירת מסוף אינה ארכיון קוד, אלא ערכה שלפיה הצוות שלך מקים מתקן בדיקה, מנתח אירוע ומוציא מהדורה בלעדינו. מקבלים את העבודה לפי רשימת תיוג.
- תצורות מעגלים. סביבת בדיקות וייצור: מגבלות, עמלות, זוגות מסחר, פרמטרים לחיבור לבורסות. לכל פרמטר — מטרה והשלכות טעות.
- תרשימי אינטגרציה. מסלול ההזמנה מהממשק ועד ליבת הבורסה: תורים, אישורים, שליחות חוזרות, נקודות כשל. לצד הקוד, כדי שתיקונים ילכו יחד עם המערכת.
- מטריצת הרשאות גישה. תפקידים מסוחר ועד מנהל ומבקר: פעולות מותרות, היכן נדרש אישור שני, מי רואה יתרות. בנפרד — משיכת כספים ושינוי מגבלות.
- נוהל תפעול. עדכונים, הפעלות מחדש, פעולות בעת אי-התאמות יתרות והזמנות תקועות. עם קריטריונים: מתי התורן עוצר את המסחר ומתי מתקן תוך כדי.
- הוראות לתמיכה. כשלים אופייניים — ניתוק הזרם, אי-זמינות ממשק הבורסה, גידול התור: מה לבדוק בלוגים, אילו מדדים לאסוף, למי להסלים.
- תיעוד המסוף. הרכב המודולים, חוזי ממשקים פנימיים, פורמטים של הודעות, מגבלות עומס — כדי שמהנדס חדש ייכנס לפרויקט בלי המחבר.
- פריסה ושחזור. מניפסטים, תרשימי רשת, משתני סביבה, סדר מיגרציות, גיבוי ונוהל שחזור מאומת על מעגל נקי.
כללים ותרשימים מנוהלים בגרסאות יחד עם הקוד, נהלים נבחנים מחדש לאחר מהדורות גדולות. אם בקבלה ארטיפקט לא תואם את המערכת או חסר — נשלים.
דוגמה מהפרקטיקה: איך הסרנו אובדן הזמנות בשיא העומס
מסוף עם הצגת הזמנות מיידית עבד עם מספר פלטפורמות, כולל Bybit. בשוק רגוע הכל הסתדר, אבל בשיאי תנודתיות עד 6% מההזמנות או לא הגיעו לבורסה, או נתקעו בסטטוס ביניים: הסוחר ראה "נשלח", אבל בספר הפקודות ההזמנה לא הופיעה.
את הסיבה פירקנו לשלושה חלקים. שליחה חוזרת בעת ניתוק יצרה כפילויות, החיבור שוחזר בלי השלמת אירועים שהוחמצו, ואי-התאמות נתפסו ידנית — 3-4 שעות התאמות ביום, ובכל זאת נשאר זנב של מקרים לא מטופלים.
מה שינינו
לכל הזמנה הוקצה מפתח אידמפוטנטי: חזרה על שגיאת רשת לא יוצרת הזמנה שנייה, אלא מחזירה את הסטטוס של הראשונה. יומן מצבים מקומי והתאמה עם הבורסה בעת חיבור מחדש סגרו את השלמת האירועים שהוחמצו, ותור נפרד עם עדיפות לביטול הזמנות הפסיק להיחסם על ידי זרם חדש.
| מדד | לפני | אחרי |
|---|---|---|
| הזמנות אבודות בשיא | 4-6% | 0.1-0.3% |
| שחזור לאחר ניתוק | 40-90 שניות, חלק ידנית | אוטומטית, 2-3 שניות |
| כפילויות בשליחה חוזרת | כמה במשמרת | 0 |
| התאמות ידניות | 3-4 שעות ביום | טיפול רק באי-התאמות |
כשלים בשיא הפסיקו להיות סוג נפרד של אירועים: ביטול הזמנה עובר גם בערוץ עמוס, ואחרי תקלה המסוף עצמו מיישר את המצב המקומי למצב הבורסה, בלי לדרוש התערבות תורן.
מה לעשות אם פתרון מוכן כבר פרוס ועובד?
מסוף פרוס אינו גזר דין לכתיבה מחדש. קודם כל מיפוי: אילו צמתים מבודדים, היכן נשמר המצב, האם יש חוזים בין מודולים ובדיקות עבורם. אם יש גבולות, האבולוציה מתבצעת נקודתית ובלי לעצור את המסחר.
הרחבה נקודתית — לצד הליבה מוקם מודול חדש: פקודות אלגוריתמיות, מקור נזילות שני, מעגל סיכון נפרד. החלפת צומת — כשקומפוננטה אחת לא עומדת בעומס, מוחלפת רק היא: שער לבורסה, נתב פקודות. מיגרציה מדורגת נדרשת כשהליבה עצמה משתנה — התאמת פקודות או תת-מערכת יתרות.
מיגרציה מתבצעת באמצעות כתיבה כפולה והרצה בצל: הצומת החדש מחשב במקביל לישן, אי-התאמות מנותחות לפני המיתוג. תעבורה מועברת בקנרית, לפי חלק מהמשתמשים, עם נסיגה לענף הישן בפקודה אחת.
החלפת ספק בתוכנית זו — לא פרויקט נפרד, אלא קבלה: בנייה משוחזרת, בדיקות חוזה, תרשים פריסה והרשאות. אם המודולים מבודדים, המבצע החדש נכנס למערכת בלי לעצור את המסחר, והרחבת המסוף הופכת לעבודה מתוכננת, לא לשחזור חירום.
שאלות טכניות: זרימת נתונים, פקודות, עמידות לתקלות
הספקות לפני התחלה הן בדרך כלל אותן: כמה מהר נתונים מגיעים למסוף, מה קורה לפקודה בעת ניתוק, האם המערכת תשרוד נפילת צומת, למי יש גישה למסחר וכמה זמן לוקחת ההטמעה. להלן תשובות ישירות לכל סעיף.
האם השערים מגיעים באיחור?
נתונים זורמים בזרם מתמיד, לא בסקר כל שנייה: עדכוני ספר פקודות ועסקאות המסוף מקבל בהתאם להופעתם בבורסה. בעת ניתוק הערוץ מתחבר מחדש ומשלים אירועים שהוחמצו לפי מספרים, לכן ספר הפקודות לא סוטה מהמציאות.
האם פקודה עלולה להתבצע פעמיים בעת תקלה?
כל הזמנה נשלחת עם מפתח ייחודי, ושליחה חוזרת לאחר ניתוק לא יוצרת כפילות. המצב נגזר מיומן אירועי הבורסה, לא מזיכרון האפליקציה, לכן ביצוע חלקי וביטול-החלפה משתקפים כראוי.
מה יקרה אם צומת ייפול?
האפליקציה והשערים לבורסות משוכפלים, התעבורה עוברת אוטומטית לצומת חי. הסשן של המשתמש והפוזיציות הפתוחות משוחזרים, כי המצב נשמר מחוץ לתהליך, ולא בזיכרון העבודה שלו.
מי יקבל גישה למסחר?
התפקידים מופרדים: סוחר, מנהל סיכונים, מנהל. מפתחות לבורסות מונפקים עם הרשאה למסחר בלבד, בלי משיכת כספים, וכל פעולה נרשמת ביומן ביקורת.
כמה זמן נמשכת ההטמעה?
המעגל העובד הראשון עם בורסה אחת וסוגי פקודות בסיסיים נבנה תוך מספר שבועות. כל בורסה נוספת — מחזור נפרד: מגבלות בקשות משלה, פורמטי תגובות ומאפייני ביצוע.
נדון במשימה ונחזור עם הערכה ותוכנית עבודה
כדי לדון במשימה באופן ענייני, והערכת הפרויקט תתבסס על עובדות, לשיחה הראשונה מספיק לשלוח נתונים ראשוניים על המוצר והתשתית. אין צורך במפרט פורמלי — די בתיאור תרחישי מסחר ופיתוחים קיימים, אם יש.
- רשימת בורסות ודרכי חיבור: שערים ציבוריים, פעולות פרטיות בחשבון, מספר זוגות מסחר.
- סוגי פקודות: שוק, לימיט, סטופ, הזמנות מקושרות, ביצוע חלקי, כללי ביטול.
- חשבונאות ודיווח: יתרות וחשבונות, עמלות, היסטוריית עסקאות, ייצוא להתאמה, תפקידי גישה.
- עבודה עם מפתחות: היכן נשמרים מפתחות לבורסות, האם נדרשת חתימה חומרתית, כיצד מוגבלת משיכת כספים.
- עומס והשהיות: כמה משתמשים בו-זמנית, באיזו תדירות מתעדכן ספר הפקודות ומופעלת הזמנה.
- ממשק ואינטגרציות: ווב, דסקטופ או אפליקציה ניידת, גרפים, התראות, שירותים חיצוניים.
השיחה הראשונה מתנהלת לפי היגיון הנדסי: מנתחים תרחישי מסחר ובנפרד — התנהגות המערכת בעת כשלים של פלטפורמות ושחזור מצב לאחר תקלה. לאחר מכן מגדירים הרכב צוות למשימה: מי מוביל אינטגרציות, מי חשבונאות וחישובים, מי ממשק.
בסיום שולחים הערכת פרויקט עם תוכנית עבודה — שלבים, תלויות, נקודות קבלה. תארו את המשימה — נחזור עם הערכה ותוכנית.