AIOps עם Dynatrace Davis AI: הגדרה, כיול ואינטגרציה

הגדרת Dynatrace Davis AI: מדוע ספים לא תופסים תקלות

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

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

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

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

מה נותן הכיול: פחות רעש ומהיר יותר להגיע לשורש הבעיה

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

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

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

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

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

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

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

סדר ההגדרה: מביקורת ועד מסירה לתפעול

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

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

קונפיגורציות, מפות ונהלים בפלט

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

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

מקרה בוחן: איך הסרנו את רעש ההתראות במתאר מבוזר

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

מה שינינו

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

מה קרה בסוף

שיעור התראות השווא ירד מ-60–70% ל-10–15%: המודל משווה התנהגות לפרופיל של השירות עצמו, ולא לסף קבוע. הזמן עד לסיבת השורש התקצר מ-40–60 דקות של ניתוח ידני ל-5–10 — התורן רואה מיד את הצומת הבעייתי ואת האירועים הקשורים, במקום שרשרת "התראה → יומן → מדד → שירות שכן".

מספר ההשפלות שהוחמצו בחודש ירד מ-8–10 ל-1–2: ירידות חלשות שלא הגיעו לסף נרשמות עכשיו כאנומליה. הזמן שהתפנה מהתראות שווא — כשליש ממשמרת התורן.

מה לעשות אם הכללים והדשבורדים שלכם כבר פרוסים?

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

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

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

ספקות טכניים נפוצים לפני הטמעה

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

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

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

האם אפשר להחליף את רכיבי האיסוף בשלנו?

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

מה עם תמיכה אחרי המסירה?

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

בואו נדון במשימה: היקף העבודה, תוכנית ולוחות זמנים

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

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

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

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