פיתוח מערכת בינה מלאכותית לזיהוי אנומליות ברשת טלקום

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

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

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

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

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

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

מה נותן זיהוי מוקדם של הידרדרות ערוצים

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

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

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

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

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

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

דרכים לאיתור חריגות: השוואת גישות

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

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

איך מתבצעת הטמעת מערכת זיהוי

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

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

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

מה נשאר אצל הלקוח: ארטיפקטים ונהלים

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

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

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

מקרה בוחן: איך קיצרנו את זמן התגובה להידרדרות

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

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

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

תוצאת ההטמעה

הזמן עד לגילוי ירד מ-40 דקות ל-2–3 דקות, וכ-90% מהחריגות נסגרות אוטומטית לעומת 55% קודם. ניתוח האירוע הצטמצם ל-10–12 דקות: המשמרת מקבלת לא אות אלא השערה ממוקמת עם ציון הסגמנט, ושיעור המקרים שבהם הסיבה נראית מיד עלה ל-80%. התראות השווא פחתו פי ארבעה — המהנדסים לא מסננים רעש, אלא עוסקים בפיתוח הרשת.

מה לעשות אם ברשת כבר מוגדרות התראות סף?

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

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

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

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

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

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

ספקות טכניים נפוצים לפני תחילת הפרויקט

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

האם אפשר להסביר למה המודל סימן אנומליה?

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

איך זה ישתלב בניטור הקיים?

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

מה יקרה כשהטופולוגיה של הרשת משתנה?

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

איך מלווה הפתרון לאחר ההפעלה?

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

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

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

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

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

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