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

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

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

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

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 בהמשך יודע ביותר דיוק היכן הבעיה

כלומר –