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

תחזוקה חזויה של רשת: מדוע התחזית מגיעה אחרי התקלה

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

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

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

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

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

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

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

זמן תגובה וחלון להיערכות

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

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

איזה סוג כשלים נעלם כליל

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

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

מצבי תחזוקה: מתגובת חירום למניעה

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

מתי תחזית אינה נחוצה ומספיק נוהל

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

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

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

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

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

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

בדיקה על תקלות עבר, ולא על גרפים יפים

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

מה הלקוח מקבל לידיו: תצורות ונהלים

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

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

נוהל תגובה: מי עושה מה לפי האות

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

תיעוד לצוות התפעול

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

מקרה בוחן: צמצמנו השבתות לא מתוכננות ברשת טלקום

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

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

מה הראה הפיילוט באזור אחד

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

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

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

במה נבדל מודל תחזית מכללי סף

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

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

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

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

שאלות על נתונים, אינטגרציות ודיוק התחזית

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

כיצד הפתרון ישתלב בניטור הקיים?

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

תקלות נדירות — על מה לאמן את המודל?

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

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

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

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

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

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

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

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

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

תארו את המשימה ואילו נתונים כבר יש — נחזור עם הערכה ותוכנית.