שיטת CASE: ניטור אנושי

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

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

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

מה זה CASE?

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

• Cכבד בטקסט (מחובר להקשר)
• Aניתן לפעולה (ערך מעשי)
• Sמבוסס פונקציות (דגש על סימפטומים)
• Eמוֹעֳרָך (כיתה)

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

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

ולמה כל זה?

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

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

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

Context-Heavy - כריכת הקשר

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

לבעיות יש הרבה מקורות. במיוחד רוחות רפאים.

איך אני יכול לעזור לקצין התורן? הדבר הראשון שקצין התורן רואה הוא הודעה, ולכן הוא בונה את כל ההשערות על בסיסה. אחר כך הוא מסתכל על הוראות ודשבורדים, אבל האם תמיד יש נתונים על הודעה ספציפית, ולא רק מידע כללי? אלספאו מייעץ "לחשוב כיצד תוכל לפרש או להגיב להודעה" (שקף 29)1. הודעה טובה מתמקדת באדם התורן, לא רק מוגדרת לפי סף.

אז הנה כמה רעיונות כיצד לשפר את הקשר ההודעות:

• הראה למשתמש משהו שימושי ונוצר במיוחד, ולא רק הוראות רגילות או לוח מחוונים. בעבר, אני והחבר'ה השתמשנו במרכזי מחוונים חקירה שהוגדרו להודעות ספציפיות. זה יעזור אם הבעיה ידועה, אבל רק יבלבל אחרים. אנחנו צריכים למצוא כאן איזון.
• ספר לנו על ההיסטוריה של ההודעה: האם היא חדשה? האם זה עובד לעתים קרובות? האם זה עונתי?
• הצג שינויים אחרונים במצב המערכת. האם משהו השתנה לאחרונה? (לדוגמה, פריסה או הפעלה/השבתה של פונקציונליות.)
• הצג את הקשרים וספק מידע עבור המודל המנטלי: תלות במערכת צריכה להיות גלויה בבירור, רצוי עם אינדיקציה של פונקציונליות.
• חבר במהירות את המשתמש לצוות: האם הוא יכול לראות תקריות מתמשכות או האם הוא יכול לגלות מי עוד בחברה קיבל הודעה? תכנית ניהול אירועים מוּפעָל?

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

מעשי - ערך מעשי

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

צפה בפרסום ב- imgur.com

מה עלי לעשות? מה אתה רוצה?

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

כך נראית הודעה בעלת ערך מעשי:

• התראה דורשת פעולה במקום רק דיווח על חדשות.
• פעולה זו קשה או מסוכנת לאוטומציה. אם ניתן לבצע פעולה אוטומטית, אז הפוך אותה לאוטומטית, תפסיק להציק לאנשים!
• ההודעה מכילה המלצות דחופות בטופס הסכמי רמת שירות (SLA) או יעד זמן התאוששות (RTO). לאחר מכן, הקצין התורן יכול להפעיל את תוכנית ניהול האירועים של הארגון.

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

מבוסס סימפטומים - דגש על סימפטומים

בין אם תרצו או לא, אתם עובדים במערכת מבוזרת (Kavaj)2. כתוצאה מכך, אתה משתמש בטקטיקות שונות כדי לבודד שירותים ולהגן עליהם מפני כישלון (Trainor וחב')3. ולמרות שאיסוף אשפה מושהה או שאילתת מסד נתונים נתקעה מצביעים על בעיות, אין צורך למהר לתקן אותן אם למשתמשים לא יהיו בעיות בעתיד הקרוב.

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

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

התסמינים אינם משתנים באותה מידה

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

הימנע מהודעות לאחר תקרית

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

אל תלך שולל על ידי הודעות סיבה. עדיף לחשוב:

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

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

הודעות מבוססות סיבה נסבלות במידה

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

מוערך - הערכה

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

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

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

מסקנה

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

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

תהנה מהתראות משופרות!

מקור: www.habr.com