פיתוח מערכת התראות לסוחרים מפתח-ביד

מדוע מערכת ההתראות לסוחרים קורסת בשיאי עומס

במצב רגוע, אירועים מליבת המסחר מגיעים אחד-אחד, ומערכת ההתראות לסוחרים מספיקה להפיץ אותם ללא השהיה. עומס שיא על ליבת המסחר שובר את התמונה הזו: בפתיחת השוק או בתנועה חדה נוצרים בתוך שניות מאות הפעלות של סטופים, שינויי מרווח ואישורי הזמנות. בין יצירת האירוע לבין מסירתו לסוחר נוצר פער, והוא גדל מהר יותר מהזרם עצמו.

השהיית מסירת האירוע גדלה באופן לא-ליניארי: כל עוד התור קצר, היא בלתי מורגשת, ובשעת הצפה המתקן מתחיל להשליך את הזנב. מכאן אובדן אירוע בחשבון — הסוחר לא יודע על סטופ שהופעל או על שינוי במרווח הביטחון, ומקבל החלטה על סמך תמונה מיושנת. התראה שנעלמה מסוכנת יותר מהתראה שהתעכבה: איש אינו מבחין בה.

הקצה ההפוך — כפילויות של התראות. אם המסירה אינה מאושרת, ניסיון חוזר נשלח שוב, ובלי מפתח אידמפוטנטיות הסוחר מקבל שלוש הודעות על אותה הפעלה. הערוץ מתחיל להיתפס כרעש, מכבים אותו — יחד עם האותות שבאמת חשובים.

שני הקצוות נובעים מאותו שורש: שכבת המסירה אינה יודעת את מצב האירוע. נפרק כיצד זה נסגר — ממחזור החיים של האירוע בליבה ועד לאישור המסירה אצל הסוחר.

מה נותן מעגל מסירה מנוהל של אירועים לסוחר

השהיית מסירה מקצה-לקצה נמדדת מרגע האירוע בצד הפלטפורמה ועד הגעת ההתראה למכשיר הסוחר, ולא מהכניסה לתור שלנו. הנתיב מתחלק למקטעים — קליטה, ניתוב, שליחה לערוץ התקשורת — וכל אחד נמדד בנפרד.

לכן רואים היכן בדיוק אובדות שברירי השנייה, וחלק ההתראות הקריטיות שמגיעות בתוך חלון היעד מפסיק לרדת בעומס שיא.

בנפרד נסגר סוג כשל שבו הסוחר מקבל שלוש התראות זהות על הפעלה אחת של תנאי. כל אירוע נושא מפתח אידמפוטנטיות, ניסיון חוזר בשליחה חוזרת מזוהה ואינו נכנס למסירה.

דה-דופליקציה של התראות פועלת ברמת המעגל, ולא באפליקציית הלקוח — זה מסיר הן את העצבנות מהכפילויות והן את הרושם המוטעה שכמה תנאים שונים הופעלו.

תיעדוף אירועים מפריד בין הזרמים: ביצוע, סטופים וסיכוני מרווח עוברים בנתיב נפרד ואינם נעמדים בתור מאחורי סיכומי שוק. תפוצה המונית לפי לוח זמנים אינה יכולה פיזית לדחוק אירוע קריטי בודד.

נראות התור מספקת מספרים לפני התלונות: עומק, גילו של ההודעה הוותיקה ביותר, שיעור שלא נמסרו, מספר כללי העדיפות שהופעלו. סף ההתראה לתורנות מוגדר כך שעליית ההשהיה תזוהה לפני שהסוחר יכתוב עליה.

מצבי מסירה: מיידי, קבוצתי ולפי לוח זמנים

מצב המסירה נקבע לא לפי נוחות הערוץ, אלא לפי כמה זמן האירוע שומר על ערכו. פריצת רמה, חיסול פוזיציה, ביצוע חלקי של פקודה גדולה מאבדים משמעות בתוך שניות — אירועים כאלה נשלחים מיד, בהודעה נפרדת לכל מנוי.

דוחות וסיכומים לתקופה אינם דורשים דחיפות כזו: משתלם יותר לצבור אותם ולשלוח בקבוצה או לפי לוח זמנים. ערוצי המסירה — שכבה עצמאית מעל המצב: התראה באפליקציה, קריאה לטרמינל המסחר, מסנג'ר, דואר.

הערוץ משתנה ללא בנייה מחדש של לוגיקת האירועים, והמצב מכתיב את הדרישות לתור, לדה-דופליקציה ולסדר ההודעות.

השוואת המצבים

המצבים אינם שוללים זה את זה: במערכת התראות אחת הם מתקיימים במקביל, והניתוב נקבע על-ידי כללים — סוג האירוע, נזילות הכלי, עדיפות הנמען. אז הדחוף יוצא מיד, והרקע אינו מחשיך את הערוץ ואינו מפריע לסוחר לראות את העיקר.

שלבי ההטמעה: מפירוק האירועים ועד למסירה לתפעול

העבודה מתנהלת ברצף קפדני: ניתוב שלא נבדק על זרם אמיתי נשבר בגל התנודתיות הראשון. תחילה מתעדים אילו אירועים בכלל קיימים ובאיזו תדירות הם מגיעים, ורק אחר כך מתכננים את כללי המסירה. להלן הסדר שבו אנו מובילים את הפרויקט.

1. אבחון זרם האירועים. עורכים מלאי של המקורות: מחירים וספר פקודות, ביצוע הזמנות, הפעלת מגבלות סיכון, סטטוסי הפקדות ומשיכות כספים. עבור כל אחד מתעדים תדירות, השהיה ביחס לבורסה וקריטיות — מתקבלת מפה של מה שראוי להתראה ומה שיוצר רעש.
2. תרשים הניתוב. קובעים איזה אירוע מיועד לאיזה סוחר, דרך איזה ערוץ הוא נמסר ובאיזו עדיפות. כאן גם נכנסים אגרגציה של אותות מאותו סוג, חלונות שקט לעדיפויות נמוכות ודה-דופליקציה, כדי שתנועת שוק אחת לא תגיע בשלוש הודעות.
3. הרכבה והגדרה. מקימים תור, ניסיונות חוזרים בעת כשל ערוץ, מסירה מושהית והסגר להודעות שלא טופלו. מפתחות אידמפוטנטיות מונעים מעיבוד חוזר להפוך לכפילות אצל הלקוח.
4. בדיקת עומס. מריצים פרופיל של יום מסחר אמיתי עם שיאי התפרצות. בוחנים את ההשהיה מהופעת האירוע ועד המסירה, את שיעור ההודעות שאבדו ואת שמירת הסדר בעומס יתר.
5. עמידות בכשלים. בודקים את ההתנהגות בעת כשל ערוץ: מעבר לגיבוי, היעדר אובדנים, מדדים והתראות למשמרת התורנות.
6. תפעול ניסיוני. מפעילים על חלק מהקהל ומשווים עם הסוחרים מה קרה בשוק ומה הגיע אליהם — בשלב זה התיקונים בכללים עולים הכי פחות.
7. מסירה לתפעול. מוסרים את תרשים הניתוב, הקונפיגורציות, תקנון התורנות והאסקלציה, סדר הוספת אירועים חדשים; מלווים את המשמרת הראשונה ומתעדים את האחראים.

מה נשאר אצל הצוות: קונפיגורציות, תרשימים ותקנונים

הפרויקט נסגר לא בהצגת התראות עובדות, אלא בכך שצוות הלקוח בעצמו משנה את כללי המסירה, מוסיף ערוצים ומנתח תקלות. לכן יחד עם הקוד מוסרים קונפיגורציות ומסמכים שלפיהם המערכת פועלת בלעדינו. הערכה מתועדת בפרוטוקול הקבלה — להלן מה שנבדק שורה-שורה.

• קונפיגורציות נמסרות: תיאורי שירות המסירה, התורים, התבניות ולוחות הזמנים במאגר הקוד, עם הפרדת סביבות וללא תיקונים ידניים בשרת.
• מפת זרמי האירועים: הנתיב ממקור המחירים והפעלת כלל הסוחר ועד לערוץ מסוים, עם נקודות ניסיון חוזר, קטיעת כפילויות ועדיפויות בשיא עומס.
• מדיניות גישה: תפקידי מנהל, תמיכה וסוחר, הרשאות לתבניות ולמפתחות של ערוצים חיצוניים, יומן שינויים.
• תיעוד המסירה: פורמטי ההודעות, כללי הניסיונות החוזרים, מגבלות ספקי הערוצים והתנהגות המערכת בעת אי-מסירה.
• תקנון אירוע: סדר האבחון של הידרדרות ערוץ, מעבר לנתיב גיבוי, קריטריוני אסקלציה וניתוח לאחר השחזור.
• ניטור: מדדים ולוחות — שיעור הנמסרים, השהיה, אורך התור, שגיאות לפי ערוצים.

מוסרים הכול למאגר של הלקוח, עם הוראות פריסה והדרכת משמרת התורנות. לאחר חודש של ליווי ניכר אם הארטיפקטים עובדים: הכללים משתנים בלעדינו, והאירועים נסגרים לפי התקנון.

מקרה בוחן: כיצד צומצמו האובדנים בנפחי מסירה בשיא

אלינו הגיעה פלטפורמת ברוקראז' עם שירות התראות עובד: התראות מחיר, קריאות מרווח, שינוי סטטוס הזמנה. כל עוד השוק עמד, הכול נראה תקין, אך בהתפרצויות תנודתיות האירועים הצטברו בתור — הסוחר נודע על הפעלת פקודת הגנה לאחר העסקה.

הניתוח העלה שלוש סיבות. המסירה עברה בזרם אחד דרך וובהוקים ללא אישור עיבוד: חלק מהבקשות נפלו בפסק זמן ולא חזרו על עצמן. הניסיונות החוזרים עברו ללא מפתח אידמפוטנטיות, ולכן אותה התראה הגיעה פעמיים. הסיבה השלישית — תור משותף: קריאת המרווח חיכתה בו מאחורי תפוצה המונית.

מה הראו המדדים

הפרידו את הזרמים: קריאות מרווח ופקודות סטופ עברו לתור עדיפות, התפוצות — לתור נפרד, עם הגבלת קצב. כל אירוע קיבל מפתח אידמפוטנטיות, והנמען — דה-דופליקציה לפיו; מה שלא נמסר עובר לניסיון חוזר עם השהיה גדלה וליומן, שממנו אפשר לשלוח את ההתראה בנפרד. האפליקציה, הדואר ו-Telegram פועלים דרך מעגל מסירה אחד.

אפקט נפרד — התמיכה הפסיקה להיות ערוץ מסירה: פניות "לא הגיעה אליי התראה" בימי שיא פחתו בסדר גודל. סוגי אירועים חדשים נוספים ללא כתיבה מחדש — נושא חדש ותבנית, המסירה והניסיונות החוזרים משותפים.

במה זרם אירועים שונה מסקירה תקופתית של החשבון?

זרם אירועים מוסר התראה כאשר השינוי כבר תועד בבלוק וצבר אישורים. סקירה תקופתית פועלת להפך: השירות עצמו, במרווחי זמן קבועים, מבקש את מצב החשבון ומשווה את התצלום לקודם.

ההבדל ניכר בעומס. הסקירה יוצרת רקע קבוע של בקשות, גם כשהסוחר אינו מבצע עסקאות: נפגעים ליבת המסחר והצמתים שאליהם פונות הבקשות. ההשהיה כאן אינה קטנה ממרווח הסקירה — האות על הביצוע מגיע בפיגור, וחלק מהתרחישים (ביצועים חלקיים, סולם הזמנות) מתממשים כבר לאחר תנועת המחיר.

הבחירה בין הגישות אינה "או-או", אלא שאלה איזה ערוץ לראות כעיקרי. להלן כיצד הם מתייחסים זה לזה בפועל.

שלמות התמונה — הפיצול השני. הסקירה מציגה רק את המצב הסופי, והשלבים הביניים (ביצוע חלקי, ביטול, העברה פנימית) אינם נכללים בה. זרם אירועים מספק יומן רציף: לפיו משוחזרת כל היסטוריית החשבון, וזה גם סוגר את שאלת ניתוק הערוץ.

הזרם כשלעצמו אינו שורד ניתוק ערוץ: לאחר חיבור מחדש נדרשת השלמה לפי יומן האירועים, אחרת נותר פער בהיסטוריה והסוחר אינו רואה חלק מהעסקאות. יומן הלוגים של הבלוק ב-Ethereum שומר את כל שינויי המצב, ולכן המרווח שהוחמץ משוחזר ללא אובדנים. לכן בפועל המנוי נעשה לערוץ עיקרי, והסקירה נשארת כבקרת שלמות.

שאלות טכניות: אמינות המסירה וסדר האירועים

הסדר והאמינות של המסירה נקבעים ברמת התעבורה, ולא ברגע השליחה. כל אירוע מקבל מספר מונוטוני בתוך זרם הסוחר ומפתח אידמפוטנטיות: שליחה חוזרת אינה יוצרת כפילות, והחמצה משוחזרת לפי המספר של האירוע המאושר האחרון.

התור מחולק לפי עדיפויות: הפעלת פקודת סטופ וקריאת מרווח עוברים מחוץ לקו המשותף, אנליטיקה ודוחות — ברקע, כדי שעומס שיא לא ידחוק אותות דחופים. אירועים מושהים נשמרים עם חתימת הפעלה ועולים לתור ברגע שנקבע.

הסוחר נכנס מהטלפון ומהמחשב הנייד — האם הכול יגיע פעמיים?

לא. כל מכשיר הוא מנוי נפרד עם סט ערוצים משלו: אותות דחופים עוברים בכל מקום, דוחות ומבחרים — רק למכשיר הראשי. סדר האירועים במקרה זה משותף, והוא נקבע לפי מספרי הזרם.

האם אפשר לדחות התראה לזמן מסוים?

כן, האירוע מונח עם חתימת הפעלה ועולה לתור ברגע שנקבע. אם התנאי איבד את משמעותו עד אז — הפוזיציה סגורה, ההזמנה בוטלה — האירוע מוסר ואינו יוצא לסוחר.

נדון במשימה: מהיכן מתחילים ומה יידרש מכם

הניתוח הראשון של המשימה — שיחה אחת, שבה עוברים את השרשרת כולה: מהיכן מגיעים האירועים, אילו ערוצי מסירה נדרשים, מה נחשב קריטי ומה אפשר לדחות. לאחר מכן מתבררים היקף העבודה ואילו נתונים נדרשים מכם, כדי לחזור עם הערכה ותוכנית הטמעה, ולא עם מילים כלליות.

כדי שהערכת היקף העבודה תתבסס על עובדות ולא על "בעין", דרושים נתוני קלט:

• מקורות האירועים — זרמי בורסה, שירותים פנימיים, מערכות ברוקראז', מסדי נתונים — ובאיזה פורמט כל אחד מספק נתונים;
• הרכב ההתראות וערוצי המסירה: אילו אירועים לאן יוצאים והאם הנמען בוחר את הערוץ בעצמו;
• כללי תיעדוף — מה לעשות בסערת אירועים, מה לאחד, מה לדכא בניסיון חוזר;
• דרישות לאמינות: השהיית מסירה מותרת, התנהגות בעת אי-זמינות ערוץ, האם נדרש ניסיון חוזר לאחר כשל;
• גישה למעגל בדיקות — רפליקה של הזרמים או סביבה מבודדת, כדי לבדוק תרחישים על התנהגות חיה;
• דרישות לתיעוד ביומן: מי ואיך צריך לראות שההתראה יצאה או לא יצאה;
• אנשי קשר מצד העסק והתפעול, שאיתם מתאמים את הטקסטים והכללים.

את תוכנית ההטמעה מחלקים לשלבים — הרכבה וקליטת אירועים, ניתוב, מסירה, נראות — ובכל אחד מראים מה נבדק ובמה מאושרת המוכנות. הרכב הצוות נקבע לפי המשימה: מהנדס אינטגרציות, מפתח שירות, מומחה לעומס ואמינות. תארו את המשימה — נחזור עם הערכה ותוכנית עבודה.