SRE (הנדסת אמינות אתרים) היא גישה להנגשת פרויקטים באינטרנט. זה נחשב למסגרת עבור DevOps ומספר כיצד להצליח ביישום שיטות DevOps. מאמר זה מתרגם ספרים מגוגל. הכנתי את התרגום הזה בעצמי והסתמכתי על הניסיון שלי בהבנת תהליכי ניטור. בערוץ הטלגרם и פרסמתי גם קישור לתרגום של פרק 4 של אותו ספר על יעדי רמת השירות.
תרגום על ידי חתול. קריאה מהנה!
לצוותי Google SRE יש עקרונות בסיסיים ושיטות עבודה מומלצות לבניית מערכות ניטור והודעות מוצלחות. פרק זה מספק המלצות באילו בעיות מבקר בדף אינטרנט עלול להיתקל וכיצד לפתור בעיות המקשות על הצגת דפי אינטרנט.
להגדיר
אין אוצר מילים אחד המשמש לדיון בנושאים הקשורים לניטור. אפילו בגוגל, המונחים שלהלן אינם בשימוש נפוץ, אך נפרט את הפירושים הנפוצים ביותר.
ניטור
איסוף, עיבוד, צבירה והצגת נתונים כמותיים על המערכת בזמן אמת: מספר בקשות וסוגי בקשות, מספר שגיאות וסוגי שגיאות, זמן עיבוד בקשות וזמן פעילות שרת.
ניטור קופסה לבנה
ניטור המבוסס על מדדים המוצגים על ידי גורמים פנימיים במערכת, כולל יומנים, מדדי פרופיל של JVM או מטפל ב-HTTP המייצרים סטטיסטיקות פנימיות.
ניטור קופסה שחורה
בדיקת התנהגות האפליקציה מנקודת מבטו של המשתמש.
לוח מחוונים (לוחות מחוונים)
ממשק (בדרך כלל ממשק אינטרנט) המספק סקירה של מדדי הבריאות המרכזיים של השירותים. בלוח המחוונים יכולים להיות מסננים, אפשרות לבחור אילו מדדים להציג וכדומה.הממשק נועד לזהות את המדדים החשובים ביותר עבור המשתמשים. לוח המחוונים יכול גם להציג מידע לצוות התמיכה הטכנית: תור בקשות, רשימה של שגיאות בעדיפות גבוהה, מהנדס שהוקצה לתחום אחריות נתון.
התראה (הודעה)
הודעות המיועדות להתקבל על ידי אדם בדואר אלקטרוני או בדרך אחרת, העלולות להופיע כתוצאה משגיאות או הגדלת תור הבקשות. הודעות מסווגות כ: כרטיסים, התראות דוא"ל והודעות מסנג'ר.
גורם שורש (גורם שורש)
פגם בתוכנה או טעות אנוש שכאשר תוקן, לא אמור להתרחש שוב. לבעיה יכולות להיות מספר סיבות עיקריות: אוטומציה לא מספקת של תהליכים, פגם בתוכנה, לימוד לא מספיק של הלוגיקה של האפליקציה. כל אחד מהגורמים הללו יכול להיות הגורם השורשי, ויש לבטל כל אחד מהם.
צומת ומכונה (צומת ומכונה)
מונחים הניתנים להחלפה להתייחסות למופע בודד של יישום פועל בשרת פיזי, מכונה וירטואלית או מיכל. יכולים להיות מספר שירותים במכונה אחת. השירותים יכולים להיות:
- קשורים זה לזה: למשל, שרת מטמון ושרת אינטרנט;
- שירותים לא קשורים על אותה חומרה: לדוגמה, מאגר קוד ואשף עבור מערכת תצורה, כגון או .
דחוף
כל שינוי בתצורת התוכנה.
מדוע יש צורך במעקב
ישנן מספר סיבות מדוע יש לנטר יישומים:
ניתוח מגמות ארוכות טווח
כמה גדול בסיס הנתונים וכמה מהר הוא גדל? כיצד משתנה מספר המשתמשים היומי?
השוואת ביצועים
האם שאילתות מהירות יותר ב-Acme Bucket of Bytes 2.72 מאשר Ajax DB 3.14? כמה טוב יותר בקשות מאוחסנות במטמון לאחר הופעת צומת נוסף? האם האתר נעשה איטי יותר משבוע שעבר?
התראה (התראות)
משהו נשבר ומישהו צריך לתקן אותו. או שמשהו ישבר בקרוב ומישהו צריך לבדוק את זה בקרוב.
יצירת לוחות מחוונים
לוחות מחוונים צריכים לענות על שאלות בסיסיות ולכלול משהו מתוך - עיכובים (שהייה), תעבורה (תנועה), שגיאות (שגיאות) וערך עומס (רוויה).
ביצוע ניתוח רטרוספקטיבי (ניפוי באגים)
זמן האחזור של עיבוד הבקשות גדל, מה עוד קרה בערך באותו זמן?
מערכות ניטור שימושיות כמקור נתונים למערכות בינה עסקית וכדי להקל על ניתוח אירועי אבטחה. מכיוון שספר זה מתמקד בתחומים הנדסיים שבהם יש ל-SREs מומחיות, לא נדון כאן בטכניקות ניטור.
ניטור והתראות מאפשרים למערכת לדעת מתי היא נשברה או עומדת להישבר. כאשר מערכת אינה יכולה לתקן את עצמה אוטומטית, אנו רוצים שאדם ינתח את ההתראה, יקבע אם הבעיה עדיין קיימת, יתקן אותה ויקבע את הסיבה העיקרית שלה. אם לא תבקר את רכיבי המערכת, לעולם לא תקבל התראה רק בגלל ש"משהו נראה קצת מוזר".
טעינת התראות אנושיות היא שימוש יקר למדי בזמנו של עובד. אם העובד עובד, ההתראה קוטעת את זרימת העבודה. אם העובד בבית, ההתראה קוטעת את הזמן האישי ואולי שינה. כאשר התראות מתרחשות בתדירות גבוהה מדי, עובדים גולשים, מעכבים או מתעלמים מהתראות נכנסות. מדי פעם הם מתעלמים מההתראה האמיתית, המוסווה על ידי אירועי רעש. הפסקות שירות יכולות להימשך זמן רב מכיוון שאירועי רעש מונעים אבחון ופתרון בעיות מהירים. למערכות כריזה יעילות יש יחס אות לרעש טוב.
קביעת ציפיות סבירות ממערכת הניטור
הגדרת ניטור עבור אפליקציה מורכבת היא משימה הנדסית מורכבת בפני עצמה. אפילו עם תשתית משמעותית של כלי איסוף, תצוגה והתראה, צוות Google SRE של 10-12 חברים כולל בדרך כלל אדם אחד או שניים שמטרתם העיקרית היא לבנות ולתחזק מערכות ניטור. מספר זה ירד עם הזמן ככל שאנו מכלילים ומרכזים את תשתית הניטור, אך לכל צוות SRE יש בדרך כלל לפחות איש צוות אחד לניטור בלבד. יש לומר שבעוד שזה די מעניין לצפות בלוחות המחוונים של מערכות הניטור, צוותי SRE נמנעים בזהירות ממצבים הדורשים מישהו להסתכל על המסך כדי לנטר בעיות.
באופן כללי, גוגל עברה למערכות ניטור פשוטות ומהירות עם כלי ניתוח אופטימליים לאחר מעשה. אנו נמנעים ממערכות "קסם" המנסות לחזות ספים או לגלות אוטומטית את הסיבה השורשית. חיישנים שמזהים תוכן לא מכוון בבקשות של משתמשי קצה הם הדוגמה הנגדית היחידה; כל עוד חיישנים אלה נשארים פשוטים, הם יכולים לזהות במהירות את הגורמים לחריגות חמורות. פורמטים אחרים לשימוש בנתוני ניטור, כגון תכנון קיבולת או חיזוי תנועה, מאתגרים יותר. תצפית לאורך זמן רב מאוד (חודשים או שנים) בקצב דגימה נמוך (שעות או ימים) תגלה מגמה ארוכת טווח.
צוות Google SRE עבד בדרגות שונות של הצלחה עם היררכיות תלות מורכבות. אנו ממעטים להשתמש בכללים כגון "אם אני מגלה שמסד הנתונים הפך איטי, אני מקבל התראה על האטה של מסד הנתונים, אחרת אני מקבל התראה באתר איטי". כללים מבוססי תלות מתייחסים בדרך כלל לחלקים הבלתי משתנים של המערכת שלנו, כגון המערכת לסינון תעבורת משתמשים למרכז הנתונים. לדוגמה, "אם מוגדר סינון תעבורת מרכז נתונים, אל תודיע לי על עיכובים בעיבוד בקשות משתמשים" הוא כלל נפוץ אחד להתראות מרכז נתונים. צוותים מעטים ב-Google תומכים בהיררכיות תלות מורכבות מכיוון שלתשתית שלנו יש קצב קבוע של עיבוד חוזר מתמשך.
חלק מהרעיונות המתוארים בפרק זה עדיין מתקיימים: תמיד יש דרך לעבור מהר יותר מסימפטום לגורם השורש, במיוחד במערכות המשתנות ללא הרף. לכן, בעוד פרק זה מתאר כמה יעדים למערכות הניטור וכיצד להשיג את המטרות הללו, חשוב שמערכות הניטור יהיו פשוטות ומובנות לכל אחד בצוות.
באופן דומה, כדי לשמור על רמת הרעש נמוכה ועל רמת האות גבוהה, גישות לניטור עצמים שמקבלים התראה חייבות להיות מאוד פשוטות ואמינות. כללים המייצרים אזהרות לבני אדם צריכים להיות קלים להבנה ולהציג בעיה ברורה.
תסמינים מול גורמים
מערכת הניטור שלך צריכה לענות על שתי שאלות: "מה מקולקל" ו"מדוע הוא מקולקל".
"מה נשבר" מתייחס לסימפטום, ו"למה נשבר" מתייחס לסיבה. הטבלה שלהלן מציגה דוגמאות לקישורים כאלה.
סימפטום
סיבה
קבלת שגיאת HTTP 500 או 404
שרתי מסד נתונים מסרבים להתחבר
תגובות שרת איטיות
ניצול מעבד גבוה או כבל Ethernet פגום
משתמשים באנטארקטיקה לא מקבלים GIF של חתולים
ה-CDN שלך שונא מדענים וחתולים, אז חלק מהכתובות IP נמצאות ברשימה השחורה
תוכן פרטי זמין בכל מקום
הפעלת מהדורת תוכנה חדשה גרמה לחומת האש לשכוח את כל ה-ACL ולהכניס את כולם
"מה" ו"למה" הם אחד מאבני הבניין החשובות ביותר ליצירת מערכת ניטור טובה עם מקסימום אות ומינימום רעש.
Black-box לעומת White-box
אנו משלבים ניטור מקיף של קופסה לבנה עם ניטור קופסה שחורה צנוע עבור מדדים קריטיים. הדרך הקלה ביותר להשוות את Black-box ל-White-box היא ש-Black-box מתמקדת בסימפטומים והיא תגובתית ולא ניטור פרואקטיבי: "המערכת לא עובדת נכון עכשיו." White-box תלוי ביכולות הבדיקה הפנימיות של מערכות: יומני אירועים או שרתי אינטרנט. כך, White-box מאפשרת לזהות בעיות מתקרבות, תקלות שנראות כמו שידור חוזר של בקשה וכו'.
שימו לב שבמערכת רב-שכבתית סימפטום בתחום אחריותו של מהנדס אחד הוא סימפטום בתחום אחריותו של מהנדס אחר. לדוגמה, ביצועי מסד הנתונים ירדו. קריאות איטיות של מסד נתונים הן סימפטום של מסד הנתונים SRE שמזהה אותם. עם זאת, עבור SRE חזיתי שצופה באתר אינטרנט איטי, הסיבה לאותה קריאת מסד נתונים איטית היא שמסד הנתונים איטי. לכן, ניטור הקופסה הלבנה מתמקד לעיתים בסימפטומים ולעיתים בסיבות, תלוי עד כמה הוא נרחב.
בעת איסוף טלמטריה לצורך איתור באגים, נדרש ניטור White-box. אם שרתי אינטרנט מגיבים איטיים לשאילתות מסד נתונים, עליך לדעת באיזו מהירות שרת האינטרנט מתקשר עם מסד הנתונים וכמה מהר הוא מגיב. אחרת, לא תוכל להבחין בין שרת מסד נתונים איטי לבין בעיית רשת בין שרת האינטרנט למסד הנתונים.
לניטור הקופסה השחורה יש יתרון מרכזי בעת שליחת התראות: אתה מפעיל הודעה לנמען כאשר הבעיה כבר גרמה לתסמינים ממשיים. מצד שני, לבעיית ה-Black-box שעדיין לא התעוררה, אבל הקרובה, הניטור חסר תועלת.
ארבעה אותות זהב
ארבעת אותות הניטור הזהובים הם חביון, תעבורה, שגיאות ורוויה. אם אתה יכול למדוד רק ארבעה מדדי מערכת משתמשים, התמקד בארבעה אלה.
העיכוב
הזמן הנדרש לטיפול בבקשה. חשוב להבחין בין השהיה של בקשות מוצלחות ובקשות שלא מוצלחות. לדוגמה, שגיאת HTTP 500 הנגרמת כתוצאה מאבדן חיבור למסד נתונים או קצה עורפי אחר ניתנת לאבחון מהר מאוד, עם זאת, שגיאת HTTP 500 יכולה להצביע על בקשה שנכשלה. מציאת ההשפעה של שגיאת 500 על השהיה הכוללת יכולה להוביל למסקנות שגויות. מצד שני, טעות איטית היא אפילו טעות מהירה! לכן, חשוב לעקוב אחר זמן השהיית שגיאות ולא רק לסנן שגיאות.
תנועה
מספר הבקשות למערכת שלך, נמדד במדדי מערכת ברמה גבוהה. עבור שירות אינטרנט, מדידה זו מייצגת בדרך כלל את מספר בקשות HTTP לשנייה חלקי אופי הבקשות (לדוגמה, תוכן סטטי או דינמי). עבור מערכת הזרמת אודיו, מדידה זו עשויה להתרכז בקצב הקלט/פלט ברשת או במספר הפעלות במקביל. עבור מערכת אחסון ערך מפתח, מדידה זו יכולה להיות עסקאות או חיפושים בשנייה.
שגיאות
זהו שיעור הבקשות שנכשלו, באופן מפורש (לדוגמה, HTTP 500), באופן מרומז (לדוגמה, HTTP 200 אך בשילוב עם תוכן שגוי), או לפי מדיניות (לדוגמה, "אם אתה לוכד תגובה בשנייה אחת, כל שנייה אחת היא שגיאה"). אם אין מספיק קודי תגובת HTTP כדי לבטא את כל תנאי הכשל, ייתכן שיידרשו פרוטוקולים משניים (פנימיים) כדי לזהות כשל חלקי. ניטור כל הבקשות השגויות הללו עשוי להיות חסר מידע, בעוד שבדיקות מערכת מקצה לקצה יכולות לעזור לך לגלות שאתה מעבד את התוכן הלא נכון.
רִוּוּי
המדד מראה עד כמה נעשה שימוש רב בשירות שלך. זהו מדד ניטור מערכת המזהה משאבים המוגבלים ביותר (לדוגמה, במערכת עם זיכרון מוגבל, מציג זיכרון, במערכת עם I/O מוגבל, מציג את מספר ה-I/O). שים לב שמערכות רבות מתקלקלות לפני שהן מגיעות ל-100% שימוש, ולכן יש צורך ביעד שימוש חיוני.
במערכות מורכבות, ניתן להשלים את הרוויה על ידי מדידת עומס ברמה גבוהה יותר: האם השירות שלך יכול להתמודד כראוי עם תעבורה כפולה, לטפל רק ב-10% יותר תעבורה, או לטפל אפילו בפחות תעבורה ממה שהוא יכול כרגע? עבור שירותים פשוטים שאין להם פרמטרים המשנים את המורכבות של הבקשה (למשל "תן לי כלום" או "אני צריך מספר שלם מונוטוני ייחודי אחד") שלעיתים רחוקות משנים תצורה, ערך בדיקת עומס סטטי עשוי להתאים. עם זאת, כפי שנדון בפסקה הקודמת, רוב השירותים צריכים להשתמש באותות עקיפים כגון ניצול מעבד או רוחב פס רשת שיש להם גבול עליון ידוע. חביון עולה הוא לעתים קרובות האינדיקטור העיקרי לרוויה. מדידת זמן התגובה של אחוזון 99 בחלון קטן (למשל דקה אחת) יכולה לתת אות רוויה מוקדם מאוד.
לבסוף, רוויה קשורה גם לתחזיות של רוויה מתקרבת, כגון: "נראה שבסיס הנתונים שלך ימלא את הכונן הקשיח שלך תוך 4 שעות."
אם אתה מודד את כל ארבעת אותות הזהב וכאשר יש בעיה באחד המדדים (או, במקרה של רוויה, כמעט בעיה), אתה מודיע לאדם, השירות שלך יהיה פחות או יותר מכוסה בניטור.
דאגה לגבי הזנב (או המכשור והביצועים)
כאשר בונים מערכת ניטור מאפס, מפתה לפתח מערכת המבוססת על ממוצעים: חביון ממוצע, ניצול ממוצע של מעבד צומת או תפוסה ממוצעת של מסד נתונים. הסכנה של שתי הדוגמאות האחרונות ברורה: מעבדים ומסדי נתונים נפטרים בצורה מאוד לא צפויה. כך גם לגבי עיכוב. אם אתה מפעיל שירות אינטרנט עם חביון ממוצע של 100 אלפיות השנייה ב-1000 בקשות לשנייה, 1% מהבקשות עשויות להימשך 5 שניות. אם משתמשים תלויים במספר שירותי אינטרנט כאלה, האחוזון ה-99 של קצה אחורי בודד יכול להפוך בקלות לזמן התגובה החציוני של הממשק.
הדרך הפשוטה ביותר להבחין בין ממוצע איטי לזנב איטי מאוד של בקשות היא לאסוף מדידות של בקשות המובעות בסטטיסטיקה (היסטוגרמות הן כלי מתאים לתצוגה), ולא עיכובים בפועל: כמה בקשות הוגשו על ידי השירות שלקח בין 0 ms ל-10ms, בין 10ms ל-30ms, בין 30ms ל-100ms, בין 100ms ל-300ms, וכו'. הרחבת גבולות ההיסטוגרמה בערך אקספוננציאלית (בערך של כ-3) היא לרוב דרך קלה לדמיין את התפלגות השאילתות.
בחירה בפירוט הנכון למדידות
יש למדוד אלמנטים שונים של המערכת ברמות שונות של פירוט. לדוגמה:
- צפייה בשימוש ב-CPU לאורך תקופה לא תציג עליות ארוכים שגורמות להשהיות גבוהות.
- מצד שני, עבור שירות אינטרנט המכוון לא יותר מ-9 שעות של השבתה בשנה (99,9% זמן פעילות שנתי), בדיקת תגובת HTTP 200 יותר מפעם או פעמיים בדקה כנראה תהיה תכופה מיותרת.
- באופן דומה, בדיקת מקום פנוי בכונן הקשיח עבור זמינות של 99,9% יותר מפעם אחת בכל 1-2 דקות כנראה מיותר.
שימו לב לאופן שבו אתם בונים את הפירוט של הממדים. קצב ניצול מעבד של 1 לשנייה יכול לספק נתונים מעניינים, אבל מדידות תכופות כאלה עשויות להיות יקרות מאוד לאיסוף, אחסון וניתוח. אם מטרת הניטור שלך דורשת פירוט גבוהה ואינה דורשת היענות גבוהה, תוכל להפחית עלויות אלו על ידי הגדרת איסוף מדדים בשרת ולאחר מכן הגדרת מערכת חיצונית לאיסוף ולצבור מדדים אלה. האם תוכל:
- מדוד את השימוש במעבד בכל שנייה.
- צמצום פירוט ל-5%.
- צברו מדדים כל דקה.
אסטרטגיה זו תאפשר לך לאסוף נתונים פרטניים ביותר מבלי לחוות תקורה גבוהה עבור ניתוח ואחסון.
הכי פשוט שאפשר, אבל לא קל יותר
הערמת דרישות שונות זו על גבי זו יכולה להוביל למערכת ניטור מורכבת מאוד. לדוגמה, המערכת שלך עשויה לכלול את הרכיבים המסבכים הבאים:
- התראות לפי ספים שונים להשהיית בקשה, באחוזונים שונים, על פני כל מיני מדדים שונים.
- כתיבת קוד נוסף לאיתור וזיהוי סיבות אפשריות.
- צור לוחות מחוונים קשורים לכל אחד מהגורמים האפשריים לבעיות.
מקורות הסיבוך הפוטנציאליים לעולם אינם מסתיימים. כמו כל מערכות התוכנה, הניטור יכול להפוך למורכב עד כדי כך שהוא הופך שביר, קשה לשינוי ולתחזוקה.
לכן, תכנן את מערכת הניטור שלך כדי לפשט אותה ככל האפשר. כשאתה בוחר אחרי מה לעקוב, זכור את הדברים הבאים:
- הכללים שתופסים לרוב תקריות אמיתיות צריכים להיות פשוטים, צפויים ואמינים ככל האפשר.
- יש להסיר את התצורה לאיסוף נתונים, צבירה והתראה המבוצעת לעתים רחוקות (לדוגמה, פחות מרבעון עבור חלק מהצוותים של SRE).
- מדדים שנאספים אך אינם מוצגים בלוח תצוגה מקדימה כלשהי או בשימוש על ידי התראה כלשהי הם מועמדים למחיקה.
בגוגל, איסוף וצבירה בסיסית של מדדים, בשילוב עם התראות ודשבורדים, עובד היטב כמערכת עצמאית יחסית (מערכת הניטור של גוגל למעשה מחולקת למספר תתי-מערכות, אך בדרך כלל אנשים מודעים לכל ההיבטים של תת-מערכות אלו). זה יכול להיות מפתה לשלב ניטור עם שיטות אחרות לבדיקת מערכות מורכבות: פרופיל מערכות מפורט, איתור באגים בתהליך, מעקב אחר פרטי חריג או כשל, בדיקת עומס, איסוף וניתוח יומנים, או בדיקת תעבורה. בעוד שלרוב הדברים הללו יש מאפיינים משותפים עם ניטור בסיסי, ערבוב ביניהם יגרום ליותר מדי תוצאות וליצור מערכת מורכבת ושבירה. כמו בהיבטים רבים אחרים של פיתוח תוכנה, תמיכה במערכות שונות עם נקודות אינטגרציה ברורות, פשוטות ומצוידות באופן רופף היא האסטרטגיה הטובה ביותר (לדוגמה, שימוש ב-API אינטרנט כדי לאחזר נתוני סיכום בפורמט שיכול להישאר קבוע לאורך תקופה ארוכה של זמן ).
קישור עקרונות יחד
ניתן לשלב את העקרונות הנדונים בפרק זה לתוך פילוסופיית ניטור והתראה שצוותי SRE של Google תומכים בהם. היצמדות לפילוסופיית הניטור הזו היא רצויה, היא נקודת פתיחה טובה ליצירה או תיקון של מתודולוגיית התראה, ויכולה לעזור לך לשאול את השאלות הנכונות לפעילות ללא קשר לגודל הארגון שלך או למורכבות השירות או המערכת.
בעת יצירת כללי ניטור והתראה, שאילת השאלות הבאות יכולה לעזור לך להימנע מהודעות חיוביות שגויות והתראות מיותרות:
- האם כלל זה מזהה מצב מערכת שאינו ניתן לזיהוי שהוא דחוף, קריאות לפעולה ומשפיע באופן בלתי נמנע על המשתמש?
- האם אוכל להתעלם מהאזהרה הזו בידיעה שהיא שפירה? מתי ולמה אוכל להתעלם מהאזהרה זו וכיצד אוכל להימנע מתרחיש זה?
- האם התראה זו אומרת שהמשתמשים מושפעים לרעה? האם ישנם מצבים שבהם המשתמשים אינם מושפעים לרעה, למשל, עקב סינון תעבורה או בעת שימוש במערכות בדיקה, שעליהן יש לסנן התראות?
- האם אוכל לנקוט פעולה בתגובה להתראה זו? האם אמצעים אלו דחופים או שהם יכולים לחכות עד הבוקר? האם זה בטוח להפוך את הפעולה לאוטומטית? האם פעולה זו תהיה פתרון לטווח ארוך או פתרון לטווח קצר?
- יש אנשים שמקבלים מספר התראות על בעיה זו, אז האם ניתן להפחית את המספר?
שאלות אלו משקפות את הפילוסופיה הבסיסית של התראות ומערכות התראה:
- בכל פעם שמגיעה התראה, אני צריך להגיב בדחיפות. אני יכול למהר כמה פעמים ביום לפני שאני מתעייף.
- כל התראה חייבת להיות מעודכנת.
- כל תגובה להתראה חייבת לדרוש התערבות אנושית. אם ניתן לעבד את ההודעה באופן אוטומטי, היא לא אמורה להגיע.
- התראות צריכות להתייחס לבעיה חדשה או אירוע שלא קרה קודם לכן.
גישה זו מטשטשת הבחנות מסוימות: אם התראה עומדת בארבעת התנאים הקודמים, אין זה משנה אם ההתראה נשלחת ממערכת ניטור White-box או Black-Box. גישה זו גם מחזקת הבדלים מסוימים: עדיף להשקיע הרבה יותר מאמץ בזיהוי תסמינים מאשר בגורמים; כשזה מגיע לסיבות, אתה רק צריך לדאוג לגבי הסיבות הבלתי נמנעות.
ניטור לטווח ארוך
בסביבות הייצור של היום, מערכות ניטור עוקבות אחר מערכת ייצור שמתפתחת ללא הרף עם ארכיטקטורת תוכנה משתנה, מאפייני עומס ויעדי ביצועים. התראות, שכרגע קשה לבצע אוטומציה, עשויות להפוך לנפוצות, אולי אפילו ראויות להתייחסות. בשלב זה, מישהו צריך למצוא ולתקן את הסיבות העיקריות לבעיה; אם פתרון כזה אינו אפשרי, התגובה להתראה דורשת אוטומציה מלאה.
חשוב שהחלטות הניטור יתקבלו מתוך מחשבה על מטרות ארוכות טווח. כל התראה שפועלת היום מרחיקה אדם משיפור המערכת מחר, ולכן יש לעיתים קרובות ירידה בזמינות או בביצועים של מערכת פרודוקטיבית במשך הזמן שלוקח לשפר את מערכת הניטור בטווח הארוך. הבה נסתכל על שתי דוגמאות הממחישות את התופעה.
Bigtable SRE: סיפור על התראה יתרה
התשתית הפנימית של Google מסופקת ונמדדת בדרך כלל במונחים של רמת שירות (SLO). לפני שנים, ה-SLO של שירות Bigtable התבסס על הביצועים הממוצעים של עסקה סינתטית המדמה לקוח פועל. עקב בעיות ב-Bigtable ורמות נמוכות יותר של ערימת האחסון, הביצועים הממוצעים הונעו על ידי זנב "גדול": 5% הגרועים ביותר מהשאילתות היו לרוב איטיים משמעותית מהשאר.
הודעות דוא"ל נשלחו עם התקרבות לסף ה-SLO, והתראות שליחים נשלחו כאשר ה-SLO חרג. שני סוגי ההתראות נשלחו בתדירות גבוהה למדי, תוך כדי צריכת כמויות בלתי מקובלות של זמן הנדסה: הצוות השקיע פרק זמן משמעותי בניתוח ההתראות כדי למצוא כמה שהיו רלוונטיות בפועל. לעתים קרובות החמצנו בעיה שהשפיעה למעשה על משתמשים מכיוון שרק חלק מההתראות היו עבור אותה בעיה ספציפית. רבות מההתראות לא היו דחופות בגלל בעיות תשתית מובנות וטופלו בצורה סטנדרטית, או לא טופלו כלל.
כדי לתקן את המצב, הצוות השתמש בגישה משולשת: תוך כדי עבודה קשה כדי לשפר את הביצועים של Bigtable, הגדרנו זמנית את האחוזון ה-75 לעיכוב בתגובה לשאילתות כיעד SLO שלנו. ביטלנו גם התראות באימייל, מכיוון שהיו כל כך הרבה כאלה שאי אפשר היה לבזבז זמן באבחון.
אסטרטגיה זו אפשרה לנו נשימה כדי להתחיל לתקן בעיות ארוכות טווח ב-Bigtable ובשכבות התחתונות של ערימת האחסון, במקום לתקן כל הזמן בעיות טקטיות. מהנדסים באמת יכלו לעשות את העבודה כשהם לא היו מופגזים בהתראות כל הזמן. בסופו של דבר, העיכוב הזמני בעיבוד ההתראות אפשר לנו לשפר את איכות השירות.
Gmail: תגובות אנושיות צפויות, אלגוריתמיות
בהתחלה, Gmail נבנה על מערכת בקרת תהליכים ששונתה Workqueue שנוצרה כדי לעבד נתחי אינדקס חיפוש באצווה. Workqueue הותאם לתהליכים ארוכים ולאחר מכן הוחל על Gmail, אבל כמה באגים בקוד המתזמן האטום התבררו שקשה מאוד לתקן.
בזמנו, ניטור Gmail היה מובנה כך שהתראות יופעלו כאשר משימות בודדות בוטלו באמצעות Workqueue. גישה זו לא הייתה אידיאלית, כי גם באותה תקופה Gmail ביצעה אלפים רבים של משימות, שכל אחת מהן ניתנה לשברירי אחוז מהמשתמשים שלנו. הקפדנו מאוד להבטיח שלמשתמשי Gmail תהיה חווית משתמש טובה, אך טיפול בהתראות רבות לא בא בחשבון.
כדי לפתור בעיה זו, Gmail SRE יצר כלי שיעזור לנפות באגים במתזמן בצורה הטובה ביותר כדי למזער את ההשפעה על המשתמשים. לצוות היו מספר דיונים האם פשוט לבצע אוטומציה של כל המחזור ממציאת הבעיה ועד לתיקון עד שנמצא פתרון ארוך טווח, אך חלקם חששו שפתרון כזה יעכב את תיקון הבעיה בפועל.
מתח כזה היה נפוץ בצוות ולעתים קרובות שיקף חוסר אמון במשמעת עצמית: בעוד שחלק מחברי הצוות רוצים לתת זמן לתיקון נכון, אחרים חוששים שהתיקון הסופי יישכח והתיקון הזמני ייקח לנצח. בעיה זו ראויה לתשומת לב, מכיוון שקל מדי לתקן בעיות באופן זמני, במקום לבצע תיקון קבוע. מנהלים וצוות טכני ממלאים תפקיד מפתח ביישום תיקונים ארוכי טווח על ידי תמיכה ותעדוף תיקונים ארוכי טווח אפשריים גם כאשר הכאב הראשוני שוכך.
התראות חוזרות ותגובות אלגוריתמיות צריכות להיות דגל אדום. חוסר הרצון של הצוות שלך להפוך את ההתראות האלה לאוטומטי אומר שהצוות חסר ביטחון שהוא יכול לסמוך על האלגוריתמים. זו בעיה רצינית שצריך לטפל בה.
טווח ארוך
נושא נפוץ מקשר בין הדוגמאות של Bigtable ו-Gmail: התחרות בין זמינות לטווח קצר לטווח ארוך. לעתים קרובות מאמץ חזק יכול לעזור למערכת שברירית להשיג זמינות גבוהה, אבל הדרך הזו היא בדרך כלל קצרת מועד, רצופת שחיקה של צוות ותלות במספר קטן של חברים מאותו צוות הרואי.
ירידה מבוקרת קצרת טווח בזמינות היא לרוב כואבת, אך חשובה מבחינה אסטרטגית ליציבות המערכת לטווח ארוך. חשוב לא להתייחס לכל התראה בנפרד, אלא לשקול האם השיעור הכולל של ההתראות מוביל למערכת בריאה, נגישה כהלכה עם צוות בר קיימא ותחזית חיובית. אנו מנתחים נתונים סטטיסטיים של שיעור ההתראות (בדרך כלל מתבטאים כאירועים למשמרת, כאשר אירוע יכול להיות מורכב ממספר אירועים קשורים) בדוחות רבעוניים עם ההנהלה, מה שמאפשר למקבלי החלטות להציג באופן רציף את עומס מערכת ההתראה ואת בריאות הצוות הכללי.
מסקנה
הדרך לניטור והתרעות בריאים היא פשוטה וישירה. הוא מתמקד בסימפטומים של הבעיה שלגביה נוצרות התראות, וניטור הגורם משמש כסיוע לבעיות באגים. ניטור סימפטומים קל יותר ככל שאתה נמצא גבוה יותר בערימה שבה אתה שולט, אם כי ניטור עומס מסד הנתונים וביצועים צריכים להיעשות ישירות על מסד הנתונים עצמו. הודעות דוא"ל הן בשימוש מוגבל מאוד ונוטות להסלים לרעש בקלות; במקום זאת, עליך להשתמש בלוח מחוונים שעוקב אחר כל הבעיות הנוכחיות המותרעות בדוא"ל. ניתן גם לשייך את לוח המחוונים ליומן אירועים כדי לנתח מתאמים היסטוריים.
בטווח הארוך, יש להגיע לחילופין מוצלח בין התרעות סימפטומים לבעיות אמיתיות קרובות, ולהתאים יעדים על מנת להבטיח שהניטור תומך באבחון מהיר.
תודה שקראת את התרגום עד הסוף. הירשם לערוץ הטלגרם שלי בנושא ניטור и .
מקור: www.habr.com