למה סקרינר ליסטינגים חדשים נשבר בזרם נתונים
סקרינר ליסטינגים חדשים נשבר לא בחיפוש לפי מילות מפתח, אלא בזרם הנתונים. הפלטפורמה משנה בשקט את מבנה עמוד ההכרזות, מוסיפה בלוק עם צמדים מומלצים או מעבירה את הרשימה לטעינה מדורגת — וכלל הפירוק, שעד אתמול הצליח להוציא טיקר, היום מחזיר מחרוזת ריקה.
החמצת אירוע רישום לא מעלה שגיאה: האוסף באמת מביא את העמודים, והנרמול בשקט משליך כל מה שלא תאם לתבנית, ובלוגים זה נראה כמו יום שקט בלי חדשות.
צוואר הבקבוק השני הוא הזמן. ניטור רישומים של מטבעות קריפטו בנוי על סריקה תקופתית, והשהיית ההתראה מורכבת ממרווח הסקר, מהאיחור של מאגר הביניים ומהתור לשליחה.
ההכרזה מופיעה תחילה במדור ההכרזות ב-Binance, אחר כך משוכפלת בבלוג של הפלטפורמה וברשתות החברתיות; אם עוקבים אחרי מקור אחד בלבד, הדקות הראשונות של תנועת הצמד עוברות בלי פקודה, ושם בדיוק נוצרת עיקר המחיר.
השלישי — איחוד אירועים. אותו ליסטינג מגיע מכמה מקורות עם כותרות וזמני פרסום שונים, ובלי חיבור לפי הצמד «נכס — פלטפורמה» נוצרות כפילויות של אירועים, שהאות מאבד מהן מערכו.
גרוע מכך המקרה ההפוך: המערכת שותקת, והצוות לומד על הרישום מצ׳אט — כלומר חלק מהמקורות אינם מכוסים בסקר, והכשל לא נראה לא בלוגים ולא במדדים.
נפרק איך זה נסגר: אילו נקודות כשל בודקים ומה שמים על כל אחת, כדי שהחמצה וכפילות ייתפסו לפני שאדם מבחין בהן.
מה נותן גילוי מוקדם של ליסטינג: השפעות מדידות
אירוע ליסטינג חי בחלון קצר: מהפרסום של ההכרזה ועד פתיחת המסחר עוברות דקות, לעיתים רחוקות — שעות. כל מה שהצוות מספיק לעשות בתוך החלון הזה — להעריך את הפרויקט, לחשב נפח, לבדוק סיכונים — תלוי בפרמטר אחד: כמה מהר הגיעה ההודעה.
גילוי מוקדם של ליסטינג מקצר את הזמן מההכרזה ועד ההחלטה מעשרות דקות של סריקה ידנית של אתרי הבורסות והערוצים לכמה שניות, ומהירות התגובה לאירוע מפסיקה להיות תלויה במי מהתורנים יפתח ראשון את העמוד.
מתחת למכסה מדובר בכמה שכבות איסוף בלתי תלויות: מנויים לערוצי הכרזות ולעמודי בורסות, זרמי אירועים של ממשקי מסחר, סקר תקופתי של סטטוסי מסחר.
כל מקור מביא את הנתונים לסכימת אירוע אחודה — פלטפורמה, טיקר, סוג כלי, זמן הכרזה, זמן התחלה — ואחר כך פועלת הסרת כפילויות לפי מפתח מורכב ובקרת עדכניות. פלטפורמות גדולות כמו Binance מפרסמות אותה הכרזה בכמה ערוצים בפער של שניות, ובלי נרמול הצוות מקבל שלוש התראות על אירוע אחד.
הפחתת התראות שווא מגיעה מהשלב השני — ניקוד. תחילה כללי חיתוך קשיחים: הכרזות בדיקה, מחיקות מרישום, פרסומים חוזרים, כלים בלי נזילות ובלי צמד לבסיס נסחר. אחר כך ניקוד משוקלל לפי מאפיינים: סוג ההכרזה, наличие חוזה, היסטוריית הפלטפורמה, התנהגות מחיר מחוץ למסחר.
להתראות עוברים 20–30% מהזרם המקורי, ושיעור האותות הריקים יורד עד כדי כך שהתורן מפסיק לכבות את הערוץ.
בנפרד נעלם סוג כשל שהיה פעם היקר מכולם: החמצה מלאה של אירוע בנפילת מקור אחד. מקור גיבוי, תור עם הבטחת מסירה ומדד השהיה בכל שכבה הופכים את «לא שמנו לב» ל«עיבדנו תוך שניות» מדיד.
אפשרויות לניטור רישומים: השוואת גישות
פלטפורמות חושפות רישומים חדשים בדרכים שונות: אצל חלקן יש פיד הכרזות פתוח, אצל אחרות — רק עמוד מסחר, ואצל שלישיות ההכרזה יוצאת לניוזלטר או לצ׳אט של הקהילה. לכן השוואת הגישות מתחילה לא מ«איזו דרך טובה יותר», אלא מהשאלה היכן מופיע המקור הראשוני ואיזו השהיה נחשבת מקובלת.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| סקר לפי לוח זמנים | פלטפורמות בלי פיד אירועים פתוח | השהיה שווה למרווח הסקר, בקשות מיותרות, החמצת הכרזות שהוסרו |
| מנוי לזרם | הפלטפורמה עצמה מספקת אירועים, חשובות הדקות הראשונות | תלות ביציבות הערוץ, נדרש איסוף משלים של מה שהוחמץ |
| אגרגטור חיצוני לנתוני שוק | נדרש כיסוי רחב של פלטפורמות והצלפה | השהיה של מתווך, שדות חסרים, אי-התאמה למקור הראשוני |
| סריקה ידנית של ערוצים | הכרזות סגורות ופלטפורמות לא סטנדרטיות | לא מתרחב, תלוי באדם, אין הבטחת שלמות |
איך זה משתלב בפועל
זרם אירועים מול סקר — לא חלופה אלא חלוקת תפקידים: הזרם נותן מהירות, הסקר מכסה פלטפורמות בלי מנוי ומבטח מפני החמצות. אגרגטור חיצוני לנתוני שוק מוחזק כמעגל הצלפה עצמאי — אי-התאמה למקור הראשוני היא לעיתים קרובות האות המוקדם ביותר.
אירועים נכנסים עוברים הסרת כפילויות לפי מזהה הרישום וזמן ההכרזה הראשון, אחרת ליסטינג אחד מגיע להתראות שלוש פעמים.
איך אנחנו בונים את צינור הניטור: שלבי העבודה
הסקרינר נבנה בשלבים, והצעד הראשון אינו קוד אלא מיפוי: היכן הפלטפורמה מפרסמת הכרזות, באיזו השהיה הן מופיעות, באיזה פורמט מגיעות ומה קורה כשמפספסים.
לפני הטמעת הסקרינר אנו מקבעים את רשימת המקורות, תדירות האירועים וזמן התגובה המותר — אז צינור עיבוד האירועים מתוכנן לזרם האמיתי, לא לממוצע בשוק.
- פירוק המשימה ומיפוי מקורות. מגדירים את הפלטפורמות בהיקף, ערוצי הכרזות, השהיות אופייניות וכשלים בכל מקור.
- נרמול נתוני הפלטפורמות. ספרייה אחודה של טיקרים ושמות, התאמת סוגי צמדים, תאריכים וסטטוסים לסכימה אחת — האירועים נעשים ברי-השוואה ביניהם.
- הסרת כפילויות וחיבור. ליסטינג אחד מגיע מכמה ערוצים: משווים כפילויות ומקשרים את ההכרזה לכלי שכבר ידוע.
- הגדרת ספי ניקוד. משקלי המאפיינים וגבולות ההפעלה מוציאים לקונפיגורציה — ניתן לערוך אותם בלי לבנות מחדש ולהפעיל מחדש את השירות.
- בדיקה על היסטוריה. מריצים את הכללים על אירועים מצטברים, מחשבים שיעור אותות נכונים ושגויים, ומכווננים ספים עד ליציאה לפרודקשן.
- מסירת התראות. סדרי עדיפויות, קיבוץ והגנה מפני זרם של אותות מאותו סוג, כדי שהתורן יראה את ההודעה בערוץ שלו.
- מסירת נהלי תמיכה. הוראות לחיבור מקור, עריכת סף וטיפול באירועים, בתוספת מדדי בריאות הצינור.
מה הלקוח מקבל לידיים: ארטיפקטים ותיעוד
האספקה בנויה כך שאת המערכת ניתן להפעיל ולפתח בלעדינו. אנו מוסרים לא רק שירות עובד, אלא גם הגדרות, הוכחות לנכונותן ומסמכים שלפיהם מהנדס תורן או אנליסט מבצע שינויים בלי לפרק את הקוד כולו.
- קונפיגורציות סביבות. מניפסטים לפריסה, משתני סביבה, סודות במאגר מאובטח — הסביבה עולה מהמאגר בפקודה אחת, בלי עריכות ידניות בשרת.
- סכימת מקורות. רשימת בורסות ואגרגטורים, סדר הסקר, חלוקת מכסות בין תהליכים, התנהגות כשמקור אינו זמין: השהיה, ניסיון חוזר, מעבר לגיבוי.
- כללי ניקוד. משקלי מאפיינים, ספים, נוסחת צבירה, ניהול גרסאות של כללים ויומן עריכות — חזרה לגרסה קודמת בלי לבנות מחדש את השירות.
- מטריצת ניתוב התראות. סוג האות, נמען, ערוץ, עדיפות, חלון שקט ואסקלציה אם האות לא אושר. הטבלה נערכת על ידכם, ולא מוסתרת בקוד.
- נהלי הפעלה. הוראות צעד-אחר-צעד לתקלות טיפוסיות, סדר תורנויות, מגבילי קצב ומפסקים נגד מפולת של התראות שווא.
- תיעוד. תרשים ארכיטקטורה, מודל נתונים, תיאור אינטגרציות חיצוניות והוראות לאנליסט: איך להוסיף מקור או לשנות סף.
- תרחישי קבלה. סט ליסטינגים לדוגמה עם ציונים צפויים — בשינוי הכללים הבא רואים מיד מה בדיוק נשבר.
מקרה בוחן: התגובה לרישומים הצטמצמה משעות לדקות
מה היה לפני ההטמעה
משמרת תורנית עברה ידנית על פידים של בורסות, עמודי הכרזות וערוצי פרויקטים — סבב הבדיקות ארך 20–30 דקות, ולכן על הרישום נודע 40–90 דקות לאחר הפרסום. חלק מהאירועים הגיעו בשעות לא פעילות ואבדו, חלקם שוכפלו ממקורות שונים, וביחס לכלי חדש חסרו מאפיינים להחלטה מהירה. שיעור הרישומים שהוחמצו עמד על כ-15%, ובזמן דומה בערך הושקע בסינון רעש.
מה שינו
זרם האירועים נאסף מפידים של בורסות ומאגרגטורים ציבוריים — ציטוטים ומטא-נתונים נמשכו דרך CoinGecko — והובא לסכימה אחודה: כלי, פלטפורמה, זמן פרסום, קישור למקור הראשוני.
הסרת כפילויות לפי הצמד «כלי + פלטפורמה» הסירה התראות חוזרות, ותור עם סדרי עדיפויות לא נתן לאירוע ללכת לאיבוד בשיא העומס. הניקוד חישב מאפיינים בנפרד, ולכן הסף בכל ערוץ הוגדר בלי לכתוב מחדש את הלוגיקה.
מה התוצאה
- חציון גילוי האירוע: מ-47 דקות ל-1.5 דקות, כולל חלונות לילה.
- שיעור הרישומים שהוחמצו: כ-15% → פחות מ-2%, כל החמצה נראית ביומן.
- עבודה ידנית של המשמרת התורנית: מינוס כ-70% — המפעיל מאשר אירוע ולא מחפש אותו.
- התראות שווא לאחר כיול הספים: פחתו פי ארבעה.
במה ניטור זורם שונה מסקר לפי לוח זמנים?
זרם וסקר פותרים משימה אחת — לדעת על הליסטינג לפני השוק — אבל משלמים על כך אחרת. מנוי לזרם מוסר את האירוע ברגע הפרסום: חיבור קבוע שומר על השהיה בשניות ומשמר את סדר ההכרזות. סקר לפי לוח זמנים נותן עומס אחיד וצפוי, אבל הזמן בין מעברים הוא אזור עיוור, וגל ליסטינגים בתוכו הולך לאיבוד.
ההכרעה עוברת לפי תדירות האירועים ומחיר האיחור. היכן שהפלטפורמה מפרסמת ליסטינגים במקבצים, הזרם מנצח: סקר פעם בדקה יראה את העובדה, אבל יפספס את הסדר ואת הגל הראשון כשהמחיר כבר זז.
בבורסות נדירות עם כמה הכרזות ביום חיבור קבוע הוא מיותר — את הניתוקים שלו צריך לשחזר ולהשלים בנפרד את מה שהוחמץ.
לכן בפועל בונים סכימת איסוף אירועים היברידית: הזרם הוא ערוץ המסירה הראשי, והסקר הוא ביטוח. הוא מעת לעת מצליב את ספריית הליסטינגים כולה, סוגר חלונות לאחר ניתוק החיבור ותופס אירועים שלא היו במנוי. האיחוד מתבצע לפי מזהה הכלי ותווית הפרסום, ולכן הגעה חוזרת של אותו אירוע לא יוצרת התראה שנייה.
את המצב בוחרים לפי קריטריון אחד: כמה זמן האות נשאר בעל ערך. אם הוא חי דקות, סקר כמקור יחיד אינו מתאים — צריך זרם עם שחזור מהיר של המנוי. אם האירוע רלוונטי שעות, סקר מספיק, ואין טעם לסבך את הסכימה.
ההיברידי נותן תכונה נוספת — דעיכה בלי עיוורון: כשהזרם נכשל, האיסוף ממשיך בסקר, ואירועים כאלה מסומנים כפחות אופרטיביים.
ספקות טכניים בנוגע לניקוד ולהתראות
לרוב לפני ההתחלה שואלים על ספים, מכסות והתנהגות המערכת בתקלות. להלן חמישה תרחישים וכיצד הם נפתרים ברמת הקונפיגורציה; כל אחד ניתן לבדוק על סט מקורות פיילוט.
איך לכוונן רגישות ולא לטבוע בהתראות שווא?
הסף נבנה ממשקלי מאפיינים: גיל המאגר, נפח, פיזור המחזיקים. בשבועות הראשונים המערכת פועלת במצב תצפית — הסף מכויל לפי מדגם מצטבר, לא לפי אינטואיציה.
מה לעשות עם מכסות של מקורות?
הסקר עובר דרך מאגר מקורות ותור עם סדרי עדיפויות, ולוח הזמנים מפזר את העומס. כשמגיעים למכסה, הבדיקה עוברת למקור גיבוי, ונתונים קריטיים מוצלבים בשתי נקודות עצמאיות.
איך המערכת שורדת כשל של מקור או ערוץ?
אירועים נשמרים במאגר זמני ולא הולכים לאיבוד: מה שלא נמסר נשלח שוב, והסרת כפילויות לפי גיבוב חותכת כפילויות. היומן מראה מה בדיוק לא נמסר ובאיזה רגע.
איך מופרדות הרשאות הגישה?
התפקידים מופרדים: אנליסט עורך משקלי כללים, צופה רואה רק את הפלט, מנהל שולט במקורות ובמפתחות. שינוי סף עובר אישור ונכנס ליומן.
אפשר להוסיף ערוצי התראה משלכם?
התעבורה מופרדת מהלוגיקה של הניקוד: ערוץ חדש מתחבר באמצעות מתאם, והליבה לא משתנה. מסננים לפי סוגי אירועים מאפשרים לחלק מהצוות לקבל רק דברים קריטיים.
נדון במשימה: מה צריך כדי להתחיל בעבודה
כדי להתחיל פרויקט לא צריך מסמך של עשרות עמודים — די בנתוני פתיחה שלפיהם נבין את ההיקף ונחזור עם הערכה ותוכנית עבודה לסקרינר. להלן מה שכדאי להכין לשיחה; חלק מהסעיפים נחדד בשיחת וידאו.
- רשימת בורסות ורשתות והגדרת האירוע: מה נחשב לליסטינג חדש — הכרזה, פתיחת מסחר, הופעת צמד.
- מקורות: ערוצי הכרזות רשמיים, ממשקי תוכנה של בורסות, נתונים מבלוקצ׳יין — והאם יש אליהם גישות.
- כללי ניקוד: אילו מאפיינים חשובים (נזילות, נפח, גיל הפרויקט, פיזור המחזיקים) ומאיזה ניקוד אות נחשב למשמעותי.
- ערוצי התראות והעדיפות שלהם: מסנג׳ר, וובהוק למערכת שלכם, דואר — למי ובאיזה פורמט נשלחת ההודעה.
- דרישות להשהיה: כמה שניות מפרסום עד התראה מותרות ומה לעשות כשמפספסים מקור.
- היסטוריה ואנליטיקה: לאיזו תקופה לשמור אירועים והאם נדרש מדגם של ליסטינגים קודמים.
- סביבה וגישות: היכן פורסים, האם נדרש מעגל בדיקות, מי אחראי למפתחות לשירותים חיצוניים.
עם הסט הזה נחזור עם הערכה ותוכנית עבודה: סדר השלבים, מה נכלל במעגל העבודה הראשון, אילו בדיקות איכות ואיך תקבלו את התוצאה. תארו את המשימה — נתחיל מפירוק נתוני הפתיחה.