מדוע בוט ההתראות ב-Telegram על עסקאות מאבד אירועים
ערוץ ההתראות נראה פשוט כל עוד השוק רגוע. בעת זינוק בתנודתיות, בכלי אחד עוברות עשרות עסקאות בשנייה, ובזרם מופיעים פספוסים, כפילויות ועיכובים של דקות. הסוחר לומד על הפוזיציה מהיסטוריית העסקאות ומפסיק לתת אמון בהתראות.
התראות שהוחמצו נולדות במפגש עם פיד הבורסה. אם זרם האירועים נקטע, וההתחברות מחדש מתרוממת מהרגע הנוכחי בלי להשלים את החלון שהוחמץ, הביצועים מתקופת הניתוק נעלמים בלי עקבות: בבוט אין לא רשומה ולא הודעה.
כפילויות של אירועים הן הצד השני של אותה עמידות בפני תקלות. מסירה חוזרת אחרי timeout בלי מפתח אידמפוטנטיות הופכת עסקה אחת לשניים-שלושה הודעות, וסוחר שהתרגל לרעש מפסיק להגיב להתראות.
הסוג השלישי של תקלות — מגבלות שליחת הודעות. Telegram מגביל גם את התדירות לצ'אט אחד וגם את הזרם הכולל של הבוט: כשמגיעים למגבלה ההודעה לא נכנסת לבאפר אלא נזרקת, ולכן retry נאיבי עם השהיה קבועה רק מאיץ את התור ומגדיל את עיכוב האות.
אנו מנתחים כיצד זה נסגר: יומן אירועים עם אישור מסירה, מפתחות אידמפוטנטיים לעסקאות, תורים בעדיפות ושליטה בזמן מהביצוע בבורסה ועד להודעה בצ'אט.
כיסוי אירועי הבורסה ומהירות התגובה
זרם אירועי הבורסה רחב ממה שנראה בממשק: הצבת פקודה, ביצוע חלקי, סגירה מלאה, ביטול עם סיבה, הפעלת פקודת סטופ, שינוי במרווח, חיסול פוזיציה. אם האירועים לא ממוינים לפי סוגים, התורן שוקע בהודעות ומפסיק לקרוא את הערוץ — יחד איתם הולך לאיבוד גם האות האמיתי.
ביצוע חלקי הוא מקור הרעש העיקרי ובו-זמנית הסיכון העיקרי. פקודה על עשרה לוטים מתאספת מכמה עסקאות במחירים שונים, והתראה על כל אחת מהן הופכת את הערוץ לפיד; ומצד שני להמתין לסגירה מלאה זה מסוכן — כשמחצית מהנפח בוצעה, הפוזיציה נשארת פתוחה בלי ששמים לב.
הסכמה העובדת: הביצוע החלקי הראשון יוצא מיד, השאר מתאגדים לפי הפקודה בחלון קצר, וסטטוס הפקודה מחושב מחדש לפי היתרה.
ביטול הוא סוג נפרד, והסיבה בו חשובה יותר מהעובדה עצמה. פג תוקף החיים, הוסר על ידי בקרת הסיכון של הבורסה, בוטל ידנית על ידי הסוחר, לא עבר בגלל הצלבה עצמית — התגובות של התורן שונות. לכן בהתראת הביטול אנו מוציאים את הקוד והטקסט של הסיבה, את יתרת הנפח ואת הקישור לבקשה המקורית.
מהירות התגובה נקבעת לפי אופן קבלת הנתונים. זרם אירועי המשתמש בחיבור מתמיד לבורסה (Binance) מעביר אירוע בשברירי שנייה, בעוד סקירה תקופתית של היומנים מפגרת בשניות ונתקלת במגבלות תדירות הבקשות. הערוץ העיקרי הוא החיבור המתמיד, והסקירה נשארת כגיבוי למקרה של ניתוק.
תאימות החשבונות נפתרת על ידי הבאה לסכמת אירוע אחת: חשבונות ספוט, מרווח וחוזים עתידיים מחזירים מערך שדות שונה, אבל בבוט הם הופכים לפורמט אחיד — עם מסננים משותפים, ספים ומסלולי מסירה לצ'אט אישי או לערוץ הצוות.
דרכי מסירת ההתראות: השוואת אפשרויות
הבורסה מוסרת נתונים בשתי דרכים שונות מהותית: דוחפת אירועים בחיבור מתמיד או עונה לבקשות לפי מודל בקשה-תגובה. מבחירה זו תלויים עיכוב ההתראה, התנהגות הבוט בעת ניתוק החיבור, צריכת המגבלות לכל מפתח, והדרך שבה המערכת שורדת גידול במספר הזוגות הנמעקבים.
להלן האפשרויות שביניהן באמת בוחרים בעת הרכבת ערוץ ההתראות. לכל אחת סוג מגבלות משלה: תדירות הסקירה, תקרה על מנויים במקביל, דרישות לכתובת ציבורית ולאימות המקור.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מנוי לאירועים בחיבור מתמיד | נדרשת תגובה לפי עובדת העסקה, יש הרבה כלים, העיכוב קריטי | יש להחזיק את החיבור ולשחזר אותו יחד עם המנויים; לפלטפורמה יש תקרה על מספר הזרמים |
| סקירה תקופתית לפי בקשה-תגובה | מעט כלים, עיכוב של מרווח אחד מותר | העיכוב שווה לצעד הסקירה, המגבלות נספרות לפי מפתח, העומס גדל באופן לינארי עם מספר הזוגות |
| קריאה חוזרת מהבורסה לכתובת שלנו | הפלטפורמה עצמה מודיעה על האירוע, נדרש מינימום של בקשות יוצאות | לא קיים בכל הבורסות; נדרשת כתובת ציבורית מאובטחת ואימות חתימה, חזרות בעת תקלה מגיעות שוב |
| אגרגטור ציטוטים צד שלישי | כמה בורסות בממשק אחד, נדרשת סכמת שדות אחידה | העיכוב והזמינות תלויים במתווך, חלק מהשדות הולכים לאיבוד, שחזור ההיסטוריה מוגבל |
בפועל משלבים בין הערוצים: חיבור מתמיד מכסה אירועים מהירים, וסקירה תקופתית פעם בדקה מאמתת את המצב ומשלימה את מה שאבד בעת הניתוק. היברידי כזה מסיר את סוג השגיאות "ההתראה הגיעה, אבל הפוזיציה כבר סגורה", שהיקר ביותר ברגע של תנועת שוק חדה.
שלבי פיתוח הבוט: מהביקורת ועד למסירה
השלבים בנויים כך שברגע חיבור המסחר האמיתי אף התראה לא תהיה תלויה במקטע לא מאומת. כל שלב מסתיים בארטיפקט — סכמה, קונפיגורציה או דוח בדיקה — שאפשר לפתוח ולערער עליו.
- ביקורת האינטגרציה. מנתחים אילו נתונים זמינים: הבורסות במערך, סוגי האירועים הנדרשים (ביצוע ומילוי חלקי של עסקה, הסרת פקודה, שינוי במרווח), מגבלות תדירות הבקשות, הרשאות המפתחות שהונפקו. התוצאה — מפת מקורות ורשימת מגבלות שיש להתחשב בהן בסכמה.
- סכמת הזרמים. מקבעים את מסלול האירוע: מקור → נרמול לפורמט אחיד → כללי סינון → ניתוב לפי נמענים → מסירה לצ'אט. בנפרד מפרטים דה-דופליקציה, סדר ההודעות והתנהגות בעת ניתוק הערוץ.
- הגדרת כללים וספים. מרכיבים תרחישי משתמש: לפי נפח, לפי כלי, לפי סוג פעולה, עם קיבוץ אירועים רועשים. אפשר להפעיל כלל, להשתיק אותו או להעביר אותו לתקציר בלי לערוך קוד.
- מערך בדיקות. ארגז חול של הבורסה בתוספת מחולל אירועים סינתטיים: מריצים מקרים נדירים — ביצוע חלקי, ביטול, פער זמנים — שעליהם בוטים בדרך כלל נופלים במסחר אמיתי.
- בדיקה תחת עומס. מזרימים זרם אירועים גבוה מהמתוכנן ובוחנים אם עיכוב המסירה גדל, אם ההתראות לא הולכות לאיבוד, ואם החיבור משתחזר אחרי ניתוק.
- מסירת הפתרון. מוסרים קוד מקור, סכמות זרמים, קונפיגורציות, הוראות להוספת כללים ותיאורי מצבי חירום. בהמשך אפשר להרחיב את מערך ההתראות בכוחות הצוות שלכם.
מה כלול באספקה: קונפיגורציות ותקנונים
באספקה כלול לא רק בוט עובד, אלא גם חומרים שאיתם צוות המזמין ממשיך לעבוד בעצמו: הגדרות, תקנונים, תיעוד והרשאות גישה מופרדות. להלן מה בדיוק נשאר אצלכם לאחר המסירה וכיצד להשתמש בכך בלי המעורבות שלנו.
- קונפיגורציית הבוט. קובץ הגדרות עם ספי הפעלה לכל זוג, רשימת כלים נמעקבים, תבניות הודעות ולוח שעות שקטות — הספים משתנים בלי לערוך קוד.
- סכמת עיבוד האירועים. המסלול ממקור הציטוטים ועד להודעה בצ'אט עם נקודות כשל, חזרות מסירה והתנהגות בעת ניתוק החיבור — רואים היכן האות עלול להתעכב.
- תקנון התגובה. מי מקבל את ההתראה, באיזה סדר, מה נחשב קריטי ומתי נדרשת הסלמה לתורן — עם ציון זמן התגובה היעד.
- הרשאות גישה. תפקידים בלוח הבקרה: מערך אחד יכול לשנות ספים, אחר — רק לצפות בהיסטוריה; מפתחות שירות מונפקים בנפרד וכפופים לרוטציה.
- תיעוד. הוראות מנהל, רשימת בדיקה להפעלה לאחר תקלה, סדר עדכון ההגדרות והוספת זוגות מסחר חדשים.
- יומנים ומטריקות. היסטוריית האותות שנמסרו, שיעור השליחות המוצלחות והעיכוב מהאירוע ועד ההודעה — לפיהם רואים אם המערך עובד כשורה.
- חומרים למסירה. קוד מקור, מניפסטים לפריסה וגיבויי הגדרות — לפי רצון ניתן לפרוס את המערך מחדש בתשתית שלכם.
תארו את המשימה — נחזור עם הערכה ותוכנית, ואת הרכב האספקה נקבע לפני תחילת העבודה.
מקרה בוחן: שחזור זרם האותות לאחר תקלה
היכן זה נשבר
הבוט שלח לסוחרים התראות על ביצוע עסקאות ועל הפעלת פקודות סטופ ב-Telegram. בשוק רגוע הכול עבד, אבל בעת זינוק בתנודתיות הגיעו למעבד מאות אירועים בשנייה: חלק מההודעות נזרקו בגלל מגבלות השליחה, חלק כופלו, והסוחר ראה את העסקה דקות לאחר שקרתה.
לפי היומנים, לפני הבנייה מחדש שיעור האירועים שהוחמצו הגיע ל-18%, וניתוח התקלה ארך שעות — אף אחד לא יכול היה להבין במהירות אם האות אבד או שמלכתחילה לא היה.
מה נבנה מחדש
את האירועים העבירו לתור עם עדיפויות: ביצוע עסקה והפעלת סטופ מעובדים לפני סיכומים אינפורמטיביים. אירועים זהים בכלי אחד מודבקים להודעה אחת עם עדכון במקום זרם רצוף, והשליחה מתבצעת עם השהיה גדלה בעת חזרה ועם אישור מסירה — ההודעה לא נחשבת נמסרה עד שהערוץ אישר את קבלתה.
מונה אירועים מקצה לקצה אפשר להבחין בניתוק הזרם ולהשלים את מה שהוחמץ, והעיכוב מהופעת האירוע ועד המסירה הפך למטריקה העיקרית: חריגה מעל הסף — התראה נשלחת למהנדס.
חודש לאחר הבנייה מחדש שיעור הפספוסים — 0.4% במקום 18%, עיכוב המסירה — 2-3 שניות במקום דקות, התגובה לתקלת ערוץ — 4 דקות במקום שעתיים של ניתוח ידני. הזרם עמד בכמה ימים של תנודתיות מוגברת בלי אובדנים: יציבות הערוץ נמדדת כעת במטריקה, ולא בתלונות של סוחרים.
במה מנוי לאירועים נבדל מסקירת החשבון
מנוי לאירועים וסקירת מצב החשבון — שתי מודלים של מסירה. במנוי הבוט מחזיק חיבור מתמיד, והבורסה עצמה שולחת הודעה ברגע השינוי במאזן, בפוזיציה או בסטטוס הבקשה. בסקירה הבוט מבקש לפי לוח זמנים תמונת מצב של החשבון ומחשב את השינויים בהשוואה לקודמת.
| סכמה | כיצד מגיעים הנתונים | מתי מתאימה | מגבלות |
|---|---|---|---|
| מנוי לאירועים | הודעה ברגע השינוי | התראות על עסקאות, סטופים, ביצועים חלקיים | נדרש פיקוח על חיוניות הערוץ והשלמה של חלונות שהוחמצו |
| סקירת מצב החשבון | תמונת מצב לפי לוח זמנים | אימות מאזן, דיווח, שינויים נדירים | שינוי בין בקשות אינו נראה, קיימת מגבלת תדירות הפניות |
| היברידי | מנוי בתוספת אימות תקופתי | התראות מסחר שבהן חשובה שלמות הנתונים | מורכב יותר לתמיכה: שתי סכמות וכללי אימות |
מגבלות המצב מתבטאות באופן שונה. אצל המנוי נקודת התורפה היא ניתוק החיבור: בזמן שהערוץ משתחזר, האירועים הולכים לאיבוד אם לא שומרים חלון השלמה. אצל הסקירה — צעד לוח הזמנים: עסקה שנפתחה ונסגרה בתוך מרווח אחד לא תיכנס להתראה כלל.
לכן הבחירה בסכמה להתראות מסחר היא כמעט תמיד היברידית: המנוי נותן שלמות נתונים לפי עובדות הביצוע, ואימות תמונת המצב מאשר את מצב החשבון הסופי לאחר הניתוקים. אנו מקבעים את סדר האירועים, זורקים כפילויות ומנהלים יומן מסירה — בעת אי-התאמה רואים באיזה שלב אבדה ההתראה.
מטריקת הקבלה — שיעור האירועים שהגיעו לנמען, והעיכוב מביצוע העסקה ועד להודעה ב-Telegram. את שני הגדלים בודקים בחשבון בדיקה לפני שמוציאים את הבוט למסחר אמיתי.
ספקות טכניים: מגבלות, עיכובים, אמינות
מגבלות הפלטפורמה ועיכובי המסירה — שני המקומות שבהם התראות המסחר נשברות לרוב. Telegram מגביל את תדירות השליחה לצ'אט אחד, ולכן אי אפשר לשדר את זרם העסקאות שורה-שורה: בעת זינוק בפעילות ההודעות נעמדות בתור, וחלקן הולך לאיבוד. להלן שלושה תרחישים שאנו סוגרים ברמת העיבוד, ולא "בעין".
תקלות בודקים בנפרד: אי-זמינות של זרם הבורסה, ניתוק החיבור לפלטפורמה, הפעלה מחדש של השירות. האירועים עוברים דרך תור עם אישור מסירה, ולכן לאחר השחזור העיבוד ממשיך מהפוזיציה המאושרת האחרונה, ולא מההתחלה.
מה יקרה אם יש יותר עסקאות ממה שהפלטפורמה מעבירה?
הזרם מתאגד: עסקאות סמוכות בזמן בכלי אחד מתאחדות להתראה אחת עם סיכום. את הסף מגדיר המשתמש עצמו — לפי נפח, לפי מחיר או לפי כלי מסוים. בשיא התור נפרק לפי עדיפות: הפעלות קריטיות יוצאות ראשונות, אינפורמטיביות — אחריהן.
בכמה ההתראה מפגרת אחרי העסקה האמיתית?
אנו מודדים שני מקטעים בנפרד — עיבוד האירוע בצד שלנו והמסירה דרך הפלטפורמה. הראשון נשלט ומסתכם בשברירי שנייה; השני תלוי ברשת של הנמען. לכן בהתראה מצוין זמן האירוע, ולא זמן השליחה: את העיכוב רואים, ולא צריך לנחש.
הודעה לא נמסרה — היא תאבד?
לא. ההתראה מקבלת מזהה, והשליחה נחשבת להסתיימה רק לאחר אישור. בעת שגיאה מתבצעת חזרה במרווח גדל, בעת אי-זמינות ממושכת — הצטברות בבאפר. אירוע שלא עבר נשאר ביומן ונכנס לדוח, ולכן אי-ההתאמה בין הבורסה להתראות מנותחת, ולא נשארת בלי ששמים לב.
נדון במשימה ונחזור עם הערכה ותוכנית
הדיון במשימה מתחיל בנתוני הקלט: בלעדיהם הערכת היקף העבודה הופכת לטווח, ותוכנית העבודה — לרשימת הנחות. להלן מה לשלוח, כדי שנחזור עם הערכה ותוכנית קונקרטיות, ולא עם שאלות הבהרה אחרי שבוע.
- בורסות ושווקים. היכן נדרשות ההתראות — ספוט, שוק הנגזרים, זוגות מסוימים או מדורים שלמים של הליסטינג. מכך תלויים היקף הזרם ואופן המנוי על הנתונים.
- אירועים-טריגרים. המחיר הגיע לרמה, הנפח גדל, המחיר השתנה בשיעור נתון במרווח, הפקודה בוצעה, סטטוס ההעברה השתנה. כל אחד מתארים באופן פורמלי, כדי שלא יהיו כפילויות והפעלות שווא.
- נמענים וערוצים. צ'אט אישי, קבוצה משותפת, מדור נפרד לאסטרטגיה מסוימת. מי מקבל את ההתראות והאם יש כאלה שזקוקים למערך מצומצם.
- פורמט ההודעה. מה צריך להיות בטקסט: הזוג, הכיוון, ערך ההפעלה, זמן האירוע, קישור לגרף. מיד מחליטים אם נדרשים כפתורים — לכבות את ההתראה, לדחות, לראות פרטים.
- כללי שקט. חלונות לילה, מגבלת הודעות בדקה, איחוד אירועים דומים לאחד. זה מה שלרוב שובר את האמון בבוט לאחר ההפעלה.
- הרשאות גישה. מפתחות עם הרשאת קריאה בלבד, מערך בדיקות של הבורסה, ערוץ בדיקה נפרד שאליו הבוט כותב לפני ההוצאה לפרודקשן.
- מצב הפעלה. כמה אנשים מקבלים את ההתראות, מספר האירועים הצפוי ביממה, האם נדרש יומן של הודעות שנמסרו וניתוח של אלה שהוחמצו.
לאחר מכן אנו מקבעים את הרכב העבודה, סדר השלבים והנקודה שבה אתם מקבלים את התוצאה במערך הבדיקות. תארו את המשימה — נחזור עם הערכה ותוכנית.