דשבורד וובי לבוט מסחר: צווארי בקבוק של שליטה ידנית
כל עוד החלטות של בוט המסחר נראות רק בלוגים על השרת ובהתכתבות עם המפתח, ניהול הפוזיציות מתבצע באיחור של שעות. המהנדס מתחבר ב-SSH, קורא את היומן, אוסף את המצב בחתיכות — בזמן הזה הבוט מספיק לפתוח ולסגור סדרת עסקאות, ואתה לומד על הסיכונים בדיעבד.
דראודאון בלי התראה מתפתח בשקט מכולם. עקומת היתרה מחליקה מטה כמה שעות, מגבלות הסיכון לא מופרות פורמלית, וההתראות מוגדרות לנפילת השירות ולא לשינוי בתשואה. עד שמישהו מייצא ידנית את היסטוריית העסקאות ובונה גרף, הרגע לצמצום החשיפה כבר הוחמץ.
השהיית קבלת הנתונים משלימה את אותה תמונה באסטרטגיות מהירות: אם המדדים מגיעים למסך בייצוא מרוכז פעם בכמה דקות, הספרד כבר התכווץ, והאות מיושן. ניטור של בוט מסחר הגיוני כאשר מצב הפוזיציות, ספר ההזמנות והתוצאה הכספית מתעדכנים ברציפות ולכל זירת מסחר בנפרד.
דוחות מפוזרים לפי זירות מוסיפים בעיה שלישית. שלוש בורסות נותנות שלושה פורמטי ייצוא, העמלות והסוואפים מחושבים לפי כללים שונים, ואפשר לאחד הכול לטבלה אחת רק ידנית. פער של כמה אחוזים בין החשבונאות הפנימית ליתרה בפועל מתגלה אחרי שבועות — ובדרך כלל במקרה.
נבחן כיצד זה נסגר: דשבורד וובי לבוט מסחר אוסף זרם עסקאות ומדדים למסך אחד, שבו לצד זה נראים דראודאון, רעננות הנתונים והתאמה לכל זירת מסחר.
מה נותן דשבורד וובי לבוט מסחר: שליטה ומהירות
כל עוד הבוט סוחר, את מצבו אוספים מיומנים בשרת, מייצואים מהבורסה והתכתבות בצ'אטים של העבודה — ההתאמה אורכת דקות, וכל הזמן הזה הפוזיציה חיה בלי השגחה. הדשבורד מרכז יתרה, פוזיציות פתוחות, הזמנות שלא בוצעו ומגבלות סיכון נוכחיות למסך אחד, שמתעדכן בזרימה ולא בבקשה ידנית.
תמונה אחודה מציגה מיד פער בין יומן העסקאות לפוזיציה בפועל — בעבר זה צף בהתאמת בוקר, עכשיו ברגע ההופעה. סטיות בהתנהגות האסטרטגיה נראות בגרף הביצועים ובפרופיל התשואה: שינוי בתדירות הכניסות או גידול בשיעור ההזמנות המבוטלות ניכרים לפני שהם הופכים לדראודאון.
זמן התגובה לתקלה מתקצר מדקות לעשרות שניות. הזמנה תקועה, נפילת ערוץ הציטוטים או שגיאה בחישוב גודל הפוזיציה התגלו בעבר רק לאחר הפסד; כעת חריגה מפעילה סף, הפאנל מדגיש את האנומליה ומציין איזה צומת יצר אותה.
בקרת סיכונים מפסיקה להיות הגדרה בקובץ: מגבלות נפח פוזיציה, תדירות עסקאות ודראודאון מקסימלי מוצגות כערך נוכחי מול הגבול. עצירת מסחר — כפתור אחד, וביומן נשאר מי לחץ עליו ובאיזה מצב היה הבוט.
עסקאות והזמנות מונחות על גרף המחיר עם סימוני כניסה, יציאה וסטופים — רואים אם הביצועים בפועל תואמים את לוגיקת האסטרטגיה ואיפה החלקה אכלה את התוצאה. זה אותו מערך נתונים שנדרש בניתוח תקלה, ולכן הדוח נבנה ישירות מהממשק ולא מייצואים.
שלוש אפשרויות לדשבורד: שירות מוכן, פיתוח עצמי, היברידי
דשבורד וובי לבוט מסחר — זה לא «לצייר גרפים», אלא חלון ראווה של מצב האסטרטגיה: פוזיציות פתוחות, דראודאון נוכחי, סטטוסים של הזמנות והשהיה בין האות לביצוע. את אפשרות המימוש בוחרים לא מתוך הרגל, אלא לפי מה בדיוק צריך לכוונן ידנית וכמה קריטי שהנתונים על המסך יתיישנו.
קו פרשת המים המרכזי — היכן חיה לוגיקת הניהול: אם הפאנל רק קורא מדדים, המשימה נפתרת מהר יותר; אם דרכו עוצרים אסטרטגיות, נדרשים הרשאות לפי תפקידים, יומן פעולות והגנה מפני לחיצה מקרית. להלן חלופות מעשיות והמגבלות שלהן.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| שירות ויזואליזציה מוכן | נדרשים גרפים, התראות על דראודאון ודוחות על עסקאות בלי לפתח לוגיקה | לא ניתן להציג מדדים לא סטנדרטיים, העדכון באיחור, הנתונים נמצאים בצד השירות |
| פיתוח עצמי של ממשק | מדדים משלכם, ניהול אסטרטגיות ישירות מהפאנל, גישה לפי תפקידים | זמן ארוך יותר לגרסה עובדת, התמיכה עליכם, בעדכון תכוף גדל העומס על הבקאנד |
| היברידי: מודול מוטמע בטרמינל | נדרש שליטה מסביבה מוכרת ופאנלים משלכם מעל נתונים מוכנים | מוגבל ליכולות הפלטפורמה, חלק מההגדרות לא זמינות, קצב העדכונים נקבע על ידי הפלטפורמה |
את הבחירה קובעות שלוש שאלות: כמה מדדים אינם טיפוסיים, מי לוחץ על «עצור» ואיזו גישה נדרשת לתפקידים שונים. תארו את המשימה — נחזור עם הערכה ותוכנית לפי האפשרות שנבחרה.
שלבי יישום: מביקורת נתוני הבוט ועד מסירה לעבודה
דשבורד וובי לבוט מסחר לא נבנה «מעל» הבוט: תחילה צריך להבין מה הבוט באמת מפרסם — אילו אירועים, באיזו תדירות, באיזו צורה ומה קורה להם בעת ניתוק התקשורת. ביקורת של מקורות נתונים בדרך כלל מסירה חלק מהרעיון הראשוני ומחדדת את השאר, ורק אחר כך מופיעה סכימת חילופי הנתונים.
- ביקורת מקורות נתונים. מיפוי הזירות והמכשירים, רשימת זרמים קבועים, בעלי המקורות, עומק היומנים. התוצאה — טבלה «מקור → שדות → תדירות → בעלים».
- סכימת חילופי נתונים. מגדירים מה הדשבורד קורא, מה הוא כותב בחזרה — השהיה, עריכת פרמטרים, עצירת חירום — היכן נשמרים צילומי מצב וכיצד מיושבים פערים בין יומן הבוט לתצוגה.
- חיבור לזירות מסחר. מפתחות עם ההרשאות המינימליות הנדרשות, מחוץ לקוד, ומסלול נפרד לבדיקות. תחילה קריאה בלבד, ניהול ידני — לאחר התאמת הנתונים.
- בניית הממשק. בלוקים: פוזיציות נוכחיות, תשואה, היסטוריית עסקאות, יומן אירועים. לכל אחד סף התיישנות משלו, כדי שהפאנל לא יציג מספרים מאתמול כעדכניים.
- בדיקה על נתונים היסטוריים. הרצה על תקופות קודמות עם התאמת כל מספר ליומני הבוט. בנפרד בודקים חסרים, אירועים כפולים ופערי שעות בין המקורות.
- מסירה להפעלה. נוהל עדכונים, סדר חזרה לגרסה עובדת קודמת, מדדי מצב הזרם, ניתוח תקלות טיפוסיות עם התורן.
העבודה מתקבלת לא לפי עצם מסירת הקבצים: הלקוח בעצמו מתאים את המספר בדשבורד הוובי ליומן ויודע מה לעשות כשהזרם נעצר.
מה מוסרים לידיים: סכימות, גישות, תיעוד, נהלים
את הדשבורד מוסרים לא כ«מסך עובד», אלא כערכה שלפיה הצוות שלכם עובד ביום הראשון בלי עזרתנו. לכן קבלה היא לא הדגמה, אלא בדיקה: המהנדס של הלקוח פורס בעצמו את הדשבורד בסביבה נקייה, המפעיל עובר משמרת לפי ההוראות, והתורן מוצא את סיבת התקלה לפי הסכימה בלי להתקשר אלינו.
- סכימת ארכיטקטורה של הדשבורד — זרימת נתונים ממחבר הבורסה ועד הווידג'ט: היכן מחושב האגרגט, היכן יש מטמון, היכן גבולות השירותים ומה הסוחר רואה בעת ניתוק התקשורת.
- מטריצת גישות — תפקידים (צופה, סוחר, מפעיל משמרת, מנהל), הפעולות המותרות לכל אחד, מקומות אחסון מפתחות API וסדר שלילתם בעת החלפת עובד.
- נוהל עדכון נתונים — תקופת התשאול והעדכונים בזרימה, התנהגות בעת ניתוק, שחזור חלון שהוחמץ, סדר דעיכה: מה נשאר על המסך כשהזרם מדלדל.
- תיעוד טכני — קונפיגורציה ומשתני סביבה, סכימת טבלאות, פריסה מאפס, סדר פעולות בתקלות טיפוסיות.
- הוראות למפעיל המשמרת — מה לבדוק בהתחלה, אילו אותות קריטיים, כיצד לעצור את הבוט, לתעד פוזיציות ולהעביר את המערכת למצב ידני.
- נוהל שחרורים וחזרה לאחור — אילו בדיקות עובר שינוי, כיצד מפרסמים בלי לעצור את המסחר, כיצד חוזרים לגרסה הקודמת.
- מערך מדדים וספי התראות — השהיית ציטוטים, שיעור הזמנות שנדחו, השהיית תצוגה — עם ציון למי ולאן מגיע האות.
- מסירת גישות — מאגר קוד, בנייה, פאנל ניטור ודומיינים נרשמים על חשבונות שלכם, כדי שהקבלן לא יישאר המחזיק היחיד במפתחות.
כל זה מפורט בפרוטוקול הקבלה שורה אחר שורה, ולכל סעיף יש תרחיש בדיקה. אם ארטיפקט כלשהו אינו בידיכם — סימן שהעבודה לא הושלמה, בלי קשר לאיך שהדשבורד נראה על המסך.
מקרה בוחן: דשבורד לבוט שפועל בכמה זירות
הבוט סחר במקביל בכמה זירות, ומצב הפוזיציות נאסף מדוחות ולוגים מפוזרים. המפעיל החזיק ארבעה חלונות פתוחים והשווה פערים ידנית: תקלה בזירה אחת התגלתה בממוצע אחרי שתים עשרה דקות, וחלק מהסטיות לא זוהה כלל. בלילה האפקט התגבר — עד הבוקר הצטברו פערים בנפח ובמחיר, שאותם ניתחו בדיעבד.
הניתוח הראה שהבעיה אינה בבוט, אלא בהיעדר תמונה אחודה. נרמלנו את האירועים מכל הזירות לסכימה אחת וריכזנו זרם של עסקאות, הזמנות וכשלים למאגר משותף, ומעליו בנינו דשבורד AlgoDesk: פוזיציות לפי כל זירה, תוצאה נוכחית ומצטברת, השהיות תגובה, סטטוסים של מפתחות גישה — על מסך אחד. את ההתראות כיווננו לסטייה מהתנהגות צפויה ולא לעובדת שגיאה, ולכן הרעש בערוץ כמעט לא נכנס.
מדדים לפני ואחרי
- זמן גילוי תקלה: 12 דקות → 35 שניות, כולל שעות הלילה.
- סטיות שלא זוהו בשבוע: 8 → 1, וגם זו התראת שווא על גבול המגבלה.
- אירועים ברבעון: 14 → 3, השאר נכבים לפני מעבר להפסד בפוזיציה.
- התאמות ידניות למפעיל במשמרת: כ-60 → 4–5, את השאר סוגרות בדיקות אוטומטיות.
- זמן אי-זמינות של הדשבורד: שעות בחודש → דקות, כשל של זירה אחת לא עוצר את הניטור של האחרות.
הרווח אינו רק במהירות התגובה. למפעיל יש נקודת אמת אחת וסדר פעולות צפוי בעת סטייה, ויומן האירועים משחזר את הכרונולוגיה בלי התכתבות בצ'אטים.
העברת נתונים בזרימה או תשאול תקופתי: מה לבחור
תשובה קצרה: אם החלטה על פוזיציה מתקבלת לפי מחיר, נדרשת העברת נתונים בזרימה מהזירה; אם הדשבורד מציג מצב תיק והיסטוריה — די בתשאול תקופתי של הזירה. הבחירה נקבעת לפי עמידה בזמנים של העדכון ומספר המכשירים שהבוט עוקב אחריהם.
זרימה — חיבור קבוע שאליו הזירה עצמה שולחת אירועים: עסקאות, שינויים בספר ההזמנות, ביטולי הזמנות. העמידה בזמנים — בשברי שנייה, אך התשתית צריכה להחזיק חיבורים רבים ולשרוד ניתוקים: אותות חיים, התחברות מחדש עם השהיה גדלה, חוצץ אירועים והתאמת מצב לאחר השחזור. בלי זה הפאנל מציג בשקט מחיר מיושן, וההחלטה מתקבלת בעיוורון.
תשאול של הזירה פשוט יותר: הבקשה עצמאית, ניתוק לא שובר את התמונה — המחזור הבא מביא נתונים רעננים. מנגד, העמידה בזמנים מוגבלת לתקופה, והעומס על התשתית גדל באופן לינארי: מספר המכשירים כפול התדירות נותן עשרות בקשות בשנייה, ובמגבלות של הזירה חלק מהן יחזרו עם סירוב.
סכימה עובדת לדשבורד וובי — היברידית: זרימה לפי מחירים, ספר הזמנות וביצוע, תשאול — לפי יתרות, היסטוריית עסקאות ונתוני אסמכתא, שבהם ההשהיה אינה קריטית. הפאנל מציג ביושר חתימת זמן של העדכון האחרון ומצב הערוץ, כדי שזרם שקפא לא ייראה כמו שוק שקט.
מערכי זרמים ומגבלות שונים מזירה לזירה — למשל, ל-Binance יש משלהם — ולכן את מצב קבלת הנתונים אנחנו מקבעים לפני פיתוח הממשק, ולא אחריו.
שאלות טכניות נפוצות על דשבורדים לבוטים
דשבורד לבוט הוא לא חלון ראווה עם גרף, אלא נקודה שדרכה משנים פרמטרים של אסטרטגיה ועוצרים מסחר. לכן לפני ההתחלה עולות אותן שאלות: היכן נמצאים המפתחות, מה רואה המפעיל, מה יקרה בעת ניתוק התקשורת. להלן תשובות לכל אחת.
כיצד לחבר זירה עם גישה פרוגרמטית סגורה?
אנחנו עובדים דרך הממשקים הרשמיים של מערכות המסחר, ולא באמצעות אמולציית דפדפן. אם אין גישה ציבורית, כותבים מודול מתאם נפרד לייצואים ולדוחות שלה — עבור שאר המערכת המקור נראה רגיל, והדשבורד לא משתנה.
היכן נשמרים מפתחות הגישה ומי רואה אותם?
המפתחות נשמרים בצורה מוצפנת במאגר נפרד, והאפליקציה מקבלת אותם רק ברגע הבקשה. הם לא מגיעים לממשק או ליומנים, והגישה מוגבלת ברשימת כתובות ובהיקף ההרשאות: קריאה ומסחר, בלי משיכת כספים.
מה קורה בעת ניתוק התקשורת עם הזירה?
הדשבורד מציג את המצב המאומת האחרון, ולא מצב משוער — המספרים לא «מצוירים» נוספים. בקשות חוזרות נשלחות באופן אידמפוטנטי, ההתחברות מחדש — עם השהיה גדלה, והתורן מקבל התראה. אם התקשורת לא חזרה, האסטרטגיה נעצרת בפקודה אחת.
האם אפשר להפריד הרשאות של עובדים?
כן, התפקידים מופרדים לפי רמות: צופה רואה מדדים, אנליסט בונה דוחות, מפעיל משנה פרמטרים, מנהל שולט בגישות. כל פעולה של המפעיל נכנסת ליומן עם שם המבצע והזמן — ניתוח אירוע לא הופך להתכתבות.
כמה מסובך להוסיף זירה חדשה?
המקור מתחבר כמתאם מאחורי ממשק משותף: ליבת הדשבורד, הדוחות וההתראות לא נכתבים מחדש. אם הזירה מספקת עסקאות, יתרה וסטטוסים של הזמנות, מדובר בימי עבודה, לא בפרויקט חדש.
נדבר על המשימה: אילו נתונים וגישות יידרשו
כדי לחזור עם הערכת עבודה, ולא עם ניסוח «תלוי במורכבות», בהתחלה נדרש מערך מוגדר של נתוני פתיחה. להלן מה שאנחנו מבקשים בשיחה הראשונה.
- זירות: היכן הבוט כבר סוחר והיכן המסחר רק מתוכנן, איזה סוג גישה משמש בכל אחת.
- אופן החיבור ומגבלות: ממשק פרוגרמטי או חילופי קבצים, תדירות עדכון הנתונים, הגבלות על מספר הפניות.
- אילו ישויות של הבוט צריך לראות: פוזיציות פתוחות, הזמנות, היסטוריית עסקאות, יתרה, מצב האסטרטגיה והפרמטרים שלה, יומני עבודה.
- כללי סיכון: מגבלות על עסקה ועל הפסד יומי, תנאי עצירה אוטומטית, «עצור» ידני — מה המפעיל חייב להיות מסוגל לעשות ישירות מהדשבורד.
- תפקידי משתמשים: סוחר, מנהל סיכונים, צופה — מזה נגזרים הרכב המסכים, פירוט הגרפים והפרדת ההרשאות.
- גישות ואבטחה: האם נדרשת הזדהות, יומן פעולות מפעיל, אינטגרציה עם כניסה ארגונית, לאילו נתונים הגישה חסומה.
- שמירת היסטוריה: משך החיים של עסקאות ומדדים, הצורך בייצוא, אילו דוחות נוצרים באופן קבוע ולמי נשלחים.
- מגבלות בצד הבוט: באיזו שפה נכתב, האם יש גישה לקוד ולקונפיגורציה, האם מוכנים להוסיף נקודות מסירת נתונים.
לאחר מכן מקבעים את היקף העבודה, הדרישות לנתונים וחוזרים עם הערכה לפי שלבים, תוכנית יישום והרכב צוות — עם לוחות זמנים ברורים ובלי הפתעות במהלך הדרך.