נטר את הפונקציה הנראית למשתמש, הוסף מספיק ראיות משאבים ויישום כדי לאבחן אותה, והתרע רק על מצבים שדורשים פעולה אנושית בזמן. צמד כל התראה עם בעלים, צעד ראשון והסלמה. במהלך אירוע, תאם מיתון, הגן על ראיות ואמת שחזור דרך מסע המשתמש בפועל.
מתחילים בפונקציה שחשובה
שרת שמגיב לפינג לא מוכיח שהיישום שלו עובד. בחר מסע משתמש מייצג ובלתי מזיק, כגון שליפת עמוד ציבורי או גישה לנקודת קצה לבדיקה מבוקרת. הגדר איך נראית הצלחה והימנע מבדיקות סינתטיות שיוצרות הזמנות אמיתיות, מפרסמות תוכן או שולחות התראות ללקוחות בכל הרצה.
נטר מנקודת מבט חיצונית מתאימה וגם מתוך היישום. תצפית חיצונית יכולה לחשוף בעיות גישה או ניתוב שהשרת אינו רואה. מדידות פנימיות יכולות להסביר מדוע המסע נכשל. שמור על שתי נקודות המבט מחוברות לפונקציה במקום לאסוף לוח מחוונים גדול רק מפני שכל מדד זמין.
בוחרים אותות בעלי ערך אבחוני
הנחיית ה-SRE של Google מדגישה השהיה, תעבורה, שגיאות ורוויה כאותות שימושיים למערכות הפונות למשתמש. השתמש בהם כדי לתאר התנהגות: זמן תגובה, נפח בקשות, בקשות לא מוצלחות ולחץ על משאבים מוגבלים. בחר מדידות המתאימות ליישום במקום להניח שהגדרת מדד אחת מתאימה לאתר, לשירות העברה ולעובד רקע.
הפרד התנהגות בקשות מוצלחות מכאלה שנכשלו היכן שזה חשוב, ובחן תוצאות בזנב האיטי ולא רק ממוצעים. הוסף לחץ זיכרון, מקום בדיסק, עומק תור או מגבלות ספציפיות ליישום כשהם מסבירים את השירות. קריאת CPU גבוהה יכולה להיות תקינה במהלך עבודת אצווה שימושית; ההשפעה הנראית למשתמש קובעת אם נדרשת פעולה מיידית.
נותנים לכל התראה פעולה ובעלים
התראה צריכה לציין את הפונקציה המושפעת, המצב הנצפה ובדיקה ראשונה שימושית. הקצה בעלים ומסלול הסלמה לפני הפריסה שלה. הבחן בין מצבים הדורשים הפרעה מיידית לפריטים המתאימים לסקירה מתוזמנת. התראות חוזרות בעלות ערך נמוך מאמנות מפעילים להתעלם מהמערכת ומקשות לזהות אותות חשובים.
השתמש בסקירת התראות קטנה כדי להסיר עמימות. הטבלה הממחישה הזו מתארת החלטות ניטור אפשריות, לא כיסוי תמיכה של SwissOctet או התחייבות לזמינות. יש לבדוק ספים מול קו הבסיס של היישום בפועל. כלול תנאי שחזור כדי שהמפעיל ידע מתי ההתראה נסגרה ומה עדיין דורש אימות.
| מצב נצפה | תגובה שימושית | הקשר לכלול |
|---|---|---|
| מסע משתמש מייצג נכשל | הערך השפעה ומתן מיתון | נקודת קצה מושפעת, משך ושינוי אחרון |
| דיסק מתקרב למגבלה מתוכננת | סקור גידול ושמירה | נפח, קצב גידול ומרווח בטוח |
| אימות גיבוי נכשל | הגן על מסלול השחזור | משימה, נקודה שמישה אחרונה ושגיאה |
| השהיה עולה במהלך שחרור | בדוק או החזר את השינוי | קו בסיס, זמן שחרור ובקשות מושפעות |
מכינים מבנה אירוע קטן
תהליך תגובה צריך להיות מובן תחת לחץ. מנה מתאם, מישהו שמטפל בעבודה טכנית ומישהו שאחראי לעדכונים כשהאירוע גדול מספיק כדי לדרוש תפקידים נפרדים. פרויקט קטן עשוי לשלב תפקידים, אבל עדיין מרוויח מנקודת החלטה ברורה אחת. סכמו על ערוץ תקשורת לפני שהשירות נכשל.
חומר תגובת האירועים של Google מדגיש תיאום וגישה שמעדיפה מיתון. יישם זאת בקנה מידה שמתאים לפרויקט: קבע את ההשפעה, בחר פעולות בטוחות והימנע מכך שכמה מפעילים יבצעו שינויים סותרים. תעד ציר זמן והחלטות. חיפוש אחר הסבר מושלם לא אמור לעכב אמצעי בטוח שמשחזר את הפונקציה המושפעת.
עוברים דרך ירידת ביצועים קונקרטית
דמיין אתר שמאט לאחר שחרור. בדיקה חיצונית מראה זמן השלמה מוגבר, בעוד שמדידות פנימיות מראות שגיאות יישום ועבודת מסד נתונים גדלה. המתאם מכריז על אירוע תחום, מגן על הראיות ומקצה אדם אחד להשוות את השחרור לקו הבסיס. אחר מכין את מסלול החזרה הנבדק במקום לבצע שינויי תשתית לא קשורים.
אם החזרה בטוחה למצב הנתונים של היישום, השתמש בה וצפה בתוצאה. אם אינה בטוחה, בחר מיתון צר יותר הנתמך בתוכנית התפעול. תעד מה השתנה ומתי. ייתכן שכדאי להעריך מאוחר יותר VPS גדול יותר או יציאה אחרת, אבל ההחלטה המיידית צריכה להתייחס לראיות במקום להניח שגודל התשתית הוא הסיבה.
מגנים על ראיות ומאמתים שחזור
יומנים תפעוליים והערות אירוע עשויים להכיל כתובות, מזהים ומידע לקוחות. אסוף את מה שהחקירה צריכה, הגבל גישה והימנע מהכללת אישורים או אסימוני הזמנה פרטיים בדוחות משותפים. באירוע אבטחה חשוד, שמור ראיות מתאימות ופעל לפי מדיניות התגובה של הפרויקט במקום להשמיד מידע בניקוי נמהר.
הנחיית תגובת האירועים של NIST ממקמת את התגובה בתוך ניהול סיכוני סייבר רחב יותר. שחזור כולל בדיקת הפונקציה המיועדת ופתרון המצב שאיפשר את האירוע. בדוק את מסע המשתמש, סקור התנהגות משאבים ובדוק עבודת רקע לפני סגירת התגובה. התראה שנסגרה או תהליך שהופעל מחדש לבדם עשויים שלא להוכיח חזרה מלאה לשירות שימושי.
הופכים את האירוע לשיפור מדיד
כתוב סקירה קצרה של השפעה, ציר זמן, תנאים תורמים והפעולות שננקטו. התמקד בשינויים שניתן לאמת: שפר בדיקה, תקן הרשאה, תרגל החזרה או הוסף תלות שחזור חסרה. הקצה בעלים וקריטריוני השלמה. הימנע מרשימה ארוכה של כוונות מעורפלות שאיש לא יוכל לאשר מאוחר יותר שבוצעו.
בעת פריסה על SwissOctet, תכנן ניטור ותגובה כחלק מתפעול היישום, בנפרד מהחומרה הנבחרת ומכל הסדר ניהול מאושר. הקטלוג אינו קובע צוות אירועים מאויש או שעות תמיכה רצופות. החלט מי מקבל התראות, מי יכול לפעול ומה תנאי השירות בפועל מכסים לפני הסתמכות על סביבת ייצור.
רשימת הבדיקה המעשית שלך.
- נטר מסע משתמש מייצג ובלתי מזיק.
- בחר אותות שמסבירים התנהגות יישום.
- תן להתראות פעולה, בעלים ותנאי שחזור.
- סכם תיאום והסלמה לפני אירוע.
- הגן על ראיות ואמת את השחזור המלא.
- הקצה שיפורים ניתנים לבדיקה לאחר הסקירה.
הפרטים שחשובים.
האם ניטור זמינות שרת מספיק?+
לא. מכונה נגישה יכולה לארח יישום שבור. נטר את הפונקציה שהמשתמשים תלויים בה והוסף ראיות משאבים כדי לאבחן כשלים.
האם כל סף מדד צריך להתריע למישהו מיד?+
לא. שמור הפרעות דחופות למצבים שיש לפעול בהם בזמן. נתב עבודה בעדיפות נמוכה יותר לתהליך סקירה עם בעלים ברור.
מתי אירוע מסתיים?+
לאחר שהפונקציה המושפעת ועבודת הרקע הרלוונטית אומתו, הסיכונים המיידיים טופלו ופעולות ההמשך תועדו. הפעלה מחדש של תהליך לבדה אינה מספקת.
לך למקור.
הפניות אלה תומכות במושגים הטכניים במדריך זה. עקוב אחר התיעוד העדכני לפני שינוי מערכת ייצור.
- Google SRE: ניטור מערכות מבוזרות sre.google
- חוברת העבודה של Google SRE: תגובת אירועים sre.google
- NIST SP 800-61 Rev. 3: תגובת אירועים csrc.nist.gov
הדרכה עריכתית מאת SwissOctet. הדוגמאות להמחשה. יש לאמת בנפרד מפרטי שירות, אפשרויות זמינות ותנאים חוזיים.