ניראות ניטור והסקה סיבתית

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

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

הבה נבחין בין כמה סוגים שונים של ניטור ושל נראות וננסה להגיע להתבוננות (בעברית זה יפה כי יש בינה בהתבוננות):

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

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

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

מה שאני אומר כאן זה שיש הבדל בין ניטור שעושים כי זה נראה מגניב או מודרני וכי יש משימה לנטר שקיבל על עצמו ה head of bi או ה vp r&d, לבין ניטור שעשה מי שעשה כדי שהחיים של עובד כזה או אחר יהיו קלים יותר בעבודה שלו. הבעיה עם שני אלה שהם אינם מתמקדים בלקוחות ובחוויה שלהם ובמשמעויות ובהשלכות האם הלקוחות (בין אם משתמשי הקצה ובין אם מי שמשלם על השירות) מקבלים את השירות שהם רוצים והאם כשיש להם בעיות אז הכול נפתר בקלות ובזריזות ובנעימים או אפילו טוב יותר, הם בכלל לא מרגישים כי הכל נעשה מתוך הארגון שלנו ביוזמתינו כי טיפלנו בכל דבר לפני שקרה, או מייד כשקרה ואפילו הלקוחות לא שמו לב.

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

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

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

https://www.linkedin.com/pulse/observability-monitoring-excellence-eitan-schuler-lopqe/

ניראות ניטור והסקה סיבתית

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

שלמה יונה

מייסד ומדען ראשי, מתמטיקאי מחקר ופיתוח בע"מ

053-7326360

shlomo.yona@mathematic.ai 

https://mathematic.ai

פודקאסט על החברה ועליי, שלמה יונה, ואופן העבודה שלנו ואיתנו: A technical deep dive about Mathematic.ai