הגדרת ניטור SLA לאפליקציית ווב כפתרון מלא

הגדרת ניטור SLA: היכן נכשל יישום האינטרנט

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

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

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

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

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

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

מה נותן השליטה: חלונות תחזוקה ומחלקות כשל

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

מה משתנה בתפעול

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

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

כיצד אנו מחשבים את האפקט

המדד העיקרי — זמן השחזור. לפני הסימון הוא נספר "משיחה לשיחה" וכלל אבחון: תקלה טיפוסית ארכה 40-60 דקות. אחרי כן נקודת הספירה עוברת להפעלה הראשונה של הסף, והנתיב לאחראי ידוע מראש — 8-15 דקות לרוב התרחישים.

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

פורמטים של שליטה: שירות חיצוני, שירות עצמי, היברידי

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

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

מתי הפורמט ההיברידי מוצדק

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

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

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

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

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

תפקידים ותחומי אחריות בכל שלב

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

בדיקה לפני מסירה

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

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

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

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

איך נראה סט התיעוד

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

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

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

מה היה לפני

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

זמינות השירות עמדה על 99.4%, זמן ההשבתה — כ-4 שעות בחודש, זמן השחזור — עד 50 דקות: האבחון בכל פעם התחיל מאפס.

מה קרה אחרי

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

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

במה שונה ניטור זמינות משליטה ברמת השירות?

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

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

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

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

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

ספקות טכניים: מה מבררים לפני ההתחלה

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

מה קורה בעומסי שיא?

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

היכן הגבול של תחומי האחריות?

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

איך נראית ההטמעה בשלבים?

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

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

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

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

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

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

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