אלרט טוב, ואלרט רע

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

כמות ההתנהגויות של המערכת עולה

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

  1. כמות הפעולות בתוך המערכת עולה
  2. כמות המקורות עולה שמהם מגיעים המשתמשים: מערכות הפעלה, דפדפנים, שוני בחומרה של המשתמשים וכו׳ – נוסקת
  3. כמות ההתאמות השונות ללקוחות שונים עולה

מה זאת ״התנהגות חריגה״ במערכת?

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

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

ב. עוד לא ברור לנו אם זאת בכלל בעיה או לא

תכנון אלרט

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

  1. event על מעבר בין חלקים ב-flow
  2. מטריקות לגבי כמות המשאבים
  3. טרייסים בנוגע לאיכות המשאבים
  4. אקספשנים על שגיאות

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

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

    אבל יש דרך להפוך אלרט מספים לאלרט טוב: מתחילים בתהליך benchmark (עליו אכתוב בפעם אחרת), מגלים מתי האלרט הספים, ומתי האלרט היה נכון – וקובעים threshold ודגימה שונה עד שהאלרט טוב
  2. "ה-memory של 20 אחוז מהמשתמשים נמוך״ – זה אלרט רע: קודם כל כי אין לו action items שהמערכת יכולה לעשות, ודבר שני – לא ידוע מה ה-impact שלו. מצד שני – עולה השאלה מה קורה לאותם 20% מהמשתמשים? אם אליאקספרס היא מערכת מלאת תמונות, והתמונות לא הצליחו להיטען בשום איכות – אליאקספרס יצטרכו לחשוב איך הם מצמצמים למשתמשים עם איכות נמוכה את כמות התמונות או איכותם, בהתאם למבחני שימוש שהם יעשו
  3. ״אחוז נמוך במיוחד של גולשים מבצעים קנייה״ – זה אלרט טוב, שמכוון את ה-on-call להרבה בדיקות: אולי יש בעיה במערכת התשלומים? אולי אחד הכפתורים לא עובד? הוא חושב על בעיות במערכת, אבל אליאקספרס בהמשך מחדדת את האלרט ומפצלת אותו לשניים: ״אחוז העוברים בין דף החיפוש לדף הקנייה נמוך״, ״אחוז העוברים מדף הקנייה לתשלום נמוך״, וה-on-call בהמשך יודע ביותר דיוק היכן הבעיה

כלומר –

מאמרים נוספים

מהם תפקידי ה-on-call?

מה בעצם האחריות של on-call, ועל פי מה היא נקבעת? זאת בעיה שמתמודד אתה כל ארגון שנדרש לתת שירות מעבר לשעות העבודה. מה בעצם תפקיד הכונן בכלל? בעיקר לדאוג ליציבות המוצר או השירות בהתאם

עלויות מעבר מערכות לוגים ואלרטים

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

אחריות SRE

יש נטייה, בכל יצירה של תפקיד חדש – לשאול מאי נפקא מינה? בהקשר של SRE עולה השאלה האלמותית: מה ההבדל בין SRE ל-devops? גוגל הפיקו את הסרטון הנהדר הבא: אני חושב שזה קצת סמנטי,

יציבות בפרוייקטים? יאן ווגינפירר מסביר

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

לכתוב test-ים של js ב-python

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