מערכת התראות של בוט מסחר AI: היכן אותות הולכים לאיבוד
האות פעל באסטרטגיה, העסקה נפתחה — אבל אין הודעה ב-Telegram. שרשרת המסירה קצרה: הבוט יוצר אירוע, שם אותו בתור, ווורקר שולח לערוץ וממתין לאישור. היא נשברת בשלב האחרון: אצל לקוח Telegram מוגדר טיימאאוט לחיבור, השליחה נכשלת, חזרה לא מתוכננת — האירוע פשוט נעלם מהתור.
השהיית התראות בשיאי עומס הופכת לפספוס אות: בזמן שווורקר תקוע על ערוץ אחד קפוא, האירועים הבאים מצטברים ומתיישנים.
קטגוריה נפרדת של תקלות — מגבלות ערוץ המסירה. Telegram חותך את קצב ההודעות בזמן זינוק, שער דואר מקבל חבילת מכתבים ודוחה אותה בשקט, Discord מגביל את מספר הקריאות מכתובת אחת.
אם ניסיונות חוזרים נעשים «בכוח», בלי מפתח אידמפוטנטיות, ניסיון לשלוח שוב הודעה הופך לכפילויות התראות: הסוחר מקבל את אותו אות שלוש פעמים ומפסיק לסמוך על הערוץ.
התרחיש הכי לא נעים — הפעלה מחדש של הבוט. התור חי בזיכרון התהליך, וכל מה שלא נשלח בעת נפילה נמחק בלי עקבות. כשל בשליחה לעתים אפילו לא נרשם בלוג: על האובדן לומדים בבוקר, לפי אי-התאמה בין היסטוריית העסקאות למה שהגיע למסנג'ר.
בדיוק בשלוש הנקודות האלה — טיימאאוט, מגבלה, הפעלה מחדש — נשברת המסירה, והן מתוקנות יחד. בהמשך נבחן איך זה נסגר.
מה נותנת מסירת אותות עמידה לתקלות
ערוץ אחד והיעדר אישורי קבלה נותנים שיעור אותות נמסרים של כ-97%: חלק מההודעות נחנקות בגלל מגבלות הבוט, חלק בגלל טיימאאוטים ברשת, חלק בגלל חסימה בצד המקבל. עבור לוגיקת מסחר, אובדן של שלושה אחוזים הוא כניסה שהוחמצה שאיש לא ידע עליה.
אישור קבלה בכל ערוץ ממיר את המסירה לכמות מדידה: ביומן רואים לא «שלחנו», אלא «התקבל אצל המקבל». שליחה חוזרת מופעלת לפי טיימאאוט או תשובה שלילית, ומפתח לפי מזהה האות חוסם חזרות — אותה פוזיציה לא נפתחת פעמיים.
זמן מסירה נחשב לא כממוצע, אלא לפי אחוזונים: החציון נכנס לשברירי שנייה, והזנב הארוך מראה מיד היכן הערוץ מדרדר. ערוץ גיבוי קולט את האות אם הראשי לא אישר קבלה בחלון שהוקצה — נפילה של שירות אחד כבר לא עוצרת את התפוצה.
אין חובה לתת את תפקיד הביטוח למסנג'ר שני: דואר מכסה אותו לא פחות טוב, בזמן שהערוץ הראשי מתאושש, וסדר מעבר הערוצים מוגדר לפי הלוגיקה הספציפית של הבוט.
כך נסגרת מחלקה שלמה של כשלים: האות קיים ביומן אבל לא הגיע; הגיע פעמיים; הגיע שעה אחרי הכניסה. בדוח נשארים שלושה מדדי בקרה — שיעור האותות הנמסרים בכל ערוץ, התפלגות זמן המסירה ומספר השליחות החוזרות שהופעלו.
ערוצי מסירה: מסנג'ר, דואר, צ'אט ארגוני
ערוצים פותרים משימות שונות ואינם מחליפים זה את זה: מסנג'ר (בחיבור הבסיסי — Telegram) נותן מהירות תגובה לאות, דואר אלקטרוני — יומן עסקאות ודיווח, צ'אט ארגוני — סביבת עבודה למשמרת תורנית. הבחירה נקבעת לא לפי נוחות, אלא לפי מי ובתוך כמה זמן חייב להגיב לאירוע.
לכל אחד יש מגבלות משלו, והן בדיוק קובעות את סכימת המסירה: מגבלות על קצב ההודעות, הרשאות הבוט במתחם סגור, השהיות מסירה. להלן השוואה לפי התאמה למערכת מסחר.
| ערוץ | מתי מתאים | מגבלות |
|---|---|---|
| מסנג'ר (בוט) | אותות עם תגובה בתוך דקות: כניסה לפוזיציה, פקודת הגנה | מגבלה על קצב שליחה, ניתוק סשן קוטע מסירה, עובדת הקבלה לא מאושרת |
| דואר אלקטרוני | סיכומים, יומן עסקאות, ניתוח תקלות | השהיית מסירה, סיכון להיכנס למסנן ספאם, אין תגובה מיידית |
| צ'אט ארגוני | משמרת תורנית רואה אות בערוץ משותף, ההיסטוריה נשמרת | צריך הרשאות בסביבת העבודה ונקודת קליטת אירועים משלו |
| ערוץ גיבוי | אירועים קריטיים כשאין זמינות לערוצים הראשיים | אימות משלו, בקרת מכסות, תקורה גבוהה יותר לתחזוקה |
סכימת עבודה היא בדרך כלל היברידית: אירוע קריטי יוצא למסנג'ר, משוכפל לדואר לצורכי ביקורת, ואם אין אישור בתוך פרק זמן מוגדר הוא עולה לערוץ גיבוי. חיתוך חזרות לפי מזהה האירוע לא נותן לכפילויות להתרבות בשליחות חוזרות, ויומן המסירה מראה באיזה ערוץ ההודעה הגיעה. כשל של ערוץ אחד לא הופך לאות שהוחמץ.
שלבי הטמעה: מביקורת ערוצים ועד מסירה
התראה במערך מסחר היא לא הודעה בצ'אט, אלא אות שהעסקה תלויה בו. הגיע באיחור או לא הגיע — האסטרטגיה פעלה בעיוורון, וניתוח התקלה מתחיל מאפס. לכן העבודה מתנהלת ברצף קבוע, שבו כל שלב נסגר בתוצאה ניתנת לבדיקה.
- ביקורת מסירה. מפרקים את הערוצים המחוברים והאובדנים: מגבלות Telegram על קצב, מסנני ספאם של Email, מגבלות Discord. מחלקים אירועים לקריטיים ואלה שאפשר לאסוף לדייג'סט.
- סכימת ניתוב. מפרשים אירועים לפי עדיפויות — כניסה לפוזיציה, סטופ, שגיאת תקשורת עם הבורסה, דוח מתוכנן. לכל אחד מגדירים ערוץ ראשי, גיבוי וכלל שליחה חוזרת.
- הגדרת ערוצים. מפרידים בוטים, שולחים והרשאות, מכינים תבניות הודעות, מפצלים זרמים לפי אסטרטגיות וחשבונות, כדי שהרעש של אחת לא יטבע את האותות של אחרת.
- הרכבת שליחה. תור עם אישור מסירה וחזרות: ניתוק תקשורת לא אוכל את ההתראה, וכפילות לא מגיעה פעמיים. לכל הודעה — מזהה ועקבות ביומן.
- בדיקה בתקלות. מכבים ערוץ, מובילים תשובה לטיימאאוט, עוצרים את תהליך השליחה ובודקים מה עובר לגיבוי. בנפרד — מבול אירועים: עשרה הפעלות לא אמורות להפוך למאה הודעות.
- מסירה לתפעול. מוסרים מפת נתיבים, תבניות והוראה לתורן. התראות שמים על מצב המסירה עצמו: המערכת חייבת לדווח כשהפסיקה לדווח.
מכאן הסכימה חיה חיים משל עצמה: ערוץ או אסטרטגיה חדשים מתווספים לנתיב בצעד אחד, בלי להרכיב מחדש את כל המערך.
תצורות, סכימות ניתוב ותקנונים
אחרי ההטמעה נשאר לצוות הלקוח לא «קופסה שחורה», אלא סט ארטיפקטים שאפשר לקרוא, לשנות ולהעביר למהנדס אחר. בלי כל סעיף שלהלן המערכת עובדת, אבל מאבדת שליטה בשינוי הראשון — ערוץ חדש, החלפת תורן או ניתוח תקלה.
- תצורת מסירה — עדיפות ערוצים, ספי הפעלה, השהיה עד שליחה חוזרת, מגבלות קצב לערוץ ולמקבל. פרופילים נפרדים למערך בדיקות ולמערך עבודה.
- סכימת ניתוב — טבלת «אירוע → ערוץ → קבוצת מקבלים» לאותות, עסקאות, ירידה וניתוק בזרם הנתונים, וכן כללי דיכוי כפילויות ותקופת שקט.
- תבניות הודעות — סימון עבור Telegram ו-Discord, גרסת טקסט ו-HTML למכתב, שדות החלפה, כללי קיצור ערכים ארוכים.
- מדיניות גישה — מי עורך נתיבים, מי רק קורא יומן מסירה, מי מאשר שליחה לערוצים קריטיים; תפקידים משויכים לחשבונות.
- תקנון תורנות — חלונות כיסוי, סדר הסלמה, אירועים עם חובת תגובה ונקודת העברת משמרת.
- יומן מסירה — רשומות לכל הודעה שנשלחה, נדחתה או נזרקה עם סיבה; לפיו רואים באיזה שלב ההתראה אבדה.
- הוראות שחזור — איך להשתיק ערוץ רועש, להעביר זרם לנתיב גיבוי ומה לבדוק קודם אם הבוט השתתק.
הסט חי יחד עם המערכת: עריכות נתיבים ותבניות עוברות אותו סדר בדיקה כמו הקוד. תארו את המשימה — נחזור עם הערכה ותוכנית, כולל הרכב התיעוד.
מקרה בוחן: מסירת אותות בלי פספוסים ועיכובים
לפני ההטמעה אותות יצאו מהמודול המסחרי ישירות לכל ערוץ: השליחה התבצעה באופן סינכרוני בלולאת העיבוד, בזינוק בתנודתיות התור גדל, וחלק מההודעות נזרקו בגלל טיימאאוט. לא הייתה דה-דופליקציה — בהפעלה מחדש של התהליך חלק מהאותות יצאו שוב, חלק אבדו. ניתוח כל אי-התאמה בין אות להתראה בפועל גזל מהצוות כמה שעות בשבוע.
את המסירה הוציאו לשירות נפרד עם תור ומפתחות אידמפוטנטיים: לכל אירוע יש מזהה, חזרה בעת תקלה לא יוצרת כפילות, וניסיונות כושלים עוברים לחזרה עם השהיה גדלה. ערוצי Telegram, Email ו-Discord מחוברים כנתיבים עצמאיים עם כללים ועדיפויות משלהם.
על כל הודעה נכתבת רשומה ביומן מסירה עם סטטוסים מהכנסה לתור ועד אישור, וב-Grafana נבנה פאנל לפי שיעור הנמסרים והתפלגות השהיה לפי קוונטילים.
אם ערוץ אינו זמין, כלל המיתוג מוביל את האות לנתיב גיבוי, והאירוע נשאר בתור עד לשחזור התקשורת. אובדן אפשרי רק בכשל בו-זמני של כל הערוצים, ומקרה כזה מעלה התראה נפרדת לתורן.
מדדים אחרי: חציון מסירה — 1.5–2.5 שניות לעומת 40–90 שניות לפני השינוי, שיעור ההתראות האבודות ירד מ-6–8% ל-0.1%, ניתוחים ידניים הצטמצמו מ-15–20 בשבוע ל-1–2 בחודש. כל אי-התאמה עולה כעת מיומן המסירה תוך דקות: רואים באיזה שלב, באיזה ערוץ ומאיזו סיבה ההודעה לא הגיעה.
מה לעשות אם הבוט כבר שולח אותות ישירות
שליחה ישירה בתוך מחזור המסחר היא המקור השכיח ביותר לאובדנים. קריאה סינכרונית עומדת באותו תהליך שבו מחושב האות: הערוץ ענה במגבלת קצב או טיימאאוט — ההודעה הלכה לאיבוד, אין חזרות, והאות הבא כבר מוכן. אחרי שבוע איש לא ישחזר אם הייתה כניסה ולמה Telegram שתק.
הוצאת המסירה פותרת זאת על ידי הפרדת אחריות. לוגיקת הבוט כותבת את האות ליומן יוצא בטרנזקציה אחת עם אירוע המסחר, ותהליך נפרד קורא את היומן ומפיץ הודעות לערוצים. מפתח אידמפוטנטיות — מזהה האות בתוספת הערוץ — מבטיח שעיבוד חוזר לא ישכפל את ההתראה.
מעבר לסכימה כזו עדיף לעשות בהדרגה, בלי לשבור קוד עובד. תחילה מצב צל: הנתיב החדש משכפל את השליחה, הישן נשאר ראשי, והיומנים נבדקים שורה-שורה. אחר כך ערוצים עוברים אחד-אחד, ופונקציית השליחה הקודמת נשארת עטיפה מעל התור — תאימות לאחור נשמרת, אין צורך לתקן אסטרטגיות ומטפלים.
תיעוד ביומן סוגר את שאלת האמון במערכת. על כל ניסיון כותבים סטטוס, זמן, סיבת כשל ומספר חזרה; מה שלא נמסר עובר לתור נפרד עם השהיה גדלה בין ניסיונות. אם שיעור האובדנים עובר סף, התורן מקבל התראה — על בוט שותק לומדים ממדד, לא מהמשתמש.
שאלות טכניות נפוצות על מסירת אותות
מסירת אות היא לא «לשלוח טקסט לצ'אט», אלא תור עם אישור. מודול ההתראות עובד כתהליך נפרד: ליבת המסחר מפרסמת אירוע ולא ממתינה לתשובת שירות חיצוני, לכן אי-זמינות ערוץ לא מאיטה את לוגיקת האסטרטגיה.
לכל אות מוקצה מספר סידורי ומזהה אירוע — שליחה חוזרת לא הופכת לכפילות, המקבל משליך את מה שכבר ראה. הרשאות מוגדרות בנפרד: השולח יודע רק לפרסם, בלי לקרוא היסטוריה ובלי גישה לפוזיציות.
איך יודעים שהאות באמת הגיע?
ההודעה עוברת מצבים «נוצר → נשלח → נמסר», ולפיהם מנוהל יומן. אם זמן המסירה יצא מהמסדרון הרגיל, התורן מקבל אזהרה, והאות הקריטי עובר בערוץ משכפל.
האם התראה יכולה להפיל או להאט את הבוט?
לא: השליחה אסינכרונית ומוצאת מחוץ למחזור המסחר. בעת הצפת תור המודול מדרדר — כותב ליומן וחותך הודעות לא עדיפות, ולא חוסם את הליבה.
איך בודקים ערוץ לפני חיבור?
מריצים אות סינתטי בכל ערוץ: פורמט, זמן מסירה, התנהגות בניתוק תקשורת וחזרה לאחר שחזור. בפלט — דוח לפי השהיות ואובדנים, ולא «כאילו הגיע».
מי ומה רואה בערוצים?
גישה ניתנת לתפקידים: סוחרים מקבלים אותות, אנליטיקה — סיכומים, מנהל — יומן מסירה. מפתחות בוטים נשמרים בנפרד ממפתחות המסחר, נשללים בפקודה אחת ולא נותנים הרשאות לפעולות.
נדון בסכימת מסירת האותות שלכם
כדי שההערכה תהיה עניינית ולא «בעין», שלחו את סכימת מסירת האותות ורשימת סוגי ההודעות: מה הבוט שולח, באיזה ערוץ זה אמור להופיע ומה נחשב קריטי. לפי הסכימה הזו נרכיב את היקף העבודה, נעריך את הנפח ונחזור עם תוכנית הטמעה — עם שלבים, תלויות ונקודות בדיקה.
מה מפרקים בדיון על המשימה:
- מפת ערוצים: Telegram, Email, Discord — איזה סוג אות לאן הולך ואיזה ערוץ ראשי ואיזה גיבוי;
- מקורות אירועים: אותות מסחר, סטטוסי ביצוע פקודות, שגיאות, דוחות בסיום סשן;
- כללי מסירה: עדיפויות, חזרות בעת תקלה, הגנה מכפילויות, שעות שקט;
- תבניות התראות ושדות: מכשיר, כיוון, רמת כניסה ופקודות הגנה;
- גישות וסודות: איך מנפיקים בוטים, טוקנים ותיבות דואר, והיכן נשמרים מפתחות;
- ניטור מסירה: איך יודעים שההודעה לא נשלחה, ומי מגיב ראשון;
- סכימת חזרה לאחור: מה קורה כשאין זמינות לערוץ הראשי ואיך מתבצע המיתוג.
את הסכימה אפשר להעביר בטקסט, בטבלה או בצילומי המסך של הפאנל הנוכחי — לנו חשובה הלוגיקה, לא הפורמט. תארו את המשימה וצרפו את מה שכבר קיים: נחזור עם הערכת עבודה ותוכנית הטמעה.