שינויים תשתיתיים הם תמיד החלטה מורכבת: בין אם המערכת היא בחיתוליה והשינוי בפועל אפשרי, יש הרבה אי וודאות שאופפת בחירות אחרות. בין כל בחירה יש טריידאופים, ובמכפלות גבוהות – יש להם מחיר שמרגישים.
במאמר: Karsh, B. T. (2004). Beyond usability: designing effective technology implementation systems to promote patient safety. BMJ Quality & Safety, 13(5), 388-394, שסקר, להבדיל, נסיונות מעבר לטכנולוגיות התראה אחרות במערכות רפואיות.
נטען כי על אף ששינויים במערכות ממוחשבים עשויות להפחית את הסיכוי לפגיעה בחולה, ואולם – טכנולוגיות רבות נזנחו בגלל בעיות בתכנון שלהן, השפעתן על זרימת העבודה וחוסר שביעות רצון כללי מהן על ידי משתמשי הקצה.
שינוי של מערכות ניטור דורשות לקיחת סיכון ברור: אם המעבר לא יהיה חלק – העלות היא הסיוט הגדול של SRE: מערכת לא מנוטרת, ללא אלרטים או ללא אלרטים מספקים, אסקלציות לא נכונות או קישור בין סרביסים לא נכונים.
הגורמים לעמימות בנוגע להחלפת מערכת ניטור
הקושי של המתכנתים ללמוד את ה-flow החדש
הממשוק הראשוני של מערכת לוגים חדשה דורש דיזיין חדש לתהליך, או פיתוח אחר במקרים שהמערכת החדשה לא מאפשרת OOTB את ההסתכלות ״הישנה״ על התהליך; דוגמה לזה היא תפיסת העולם של pagerDuty על העולם הרחב של האלרטים:
הם רואים ארגון גדול, שבו יש צוותים, ולכל צוות האלרטים שלו. אם התראה לא מקבלת מענה תוך זמן מסויים – מתבצעת אסקלציה לראש הצוות, או לממונה בכיר יותר באותו צוות.
ואולם, יש ארגונים עם מבנה יותר מעורב: סטארטאפ בתחילת-אמצע דרכו, עם 30 מפתחים שכולם מכירים הרבה מהמערכת, ויש שיתוף בין המתכנתים גם על הקוד. אבל לחלקים מסויימים בארגון יש יותר ידע על דברים ספציפיים. אסקלציה לראש הצוות היא לא הדבר הנכון – כי כולם כאמור מקבלים את כל האלרטים ויכולים לתת לכל האלרטים מענה ראשוני. אבל את האסקלציה היה נכון להעביר למומחה לאדם ספצפי. את מנגנון האסקלציה שמאפשר את היכולת הזאת נדרש לפתח בדרך אחת; במעבר למערכת חדשה – גם במקרה שהמנגנון בה משרת את הארגון יותר – יש שוני ב-flow שהמתכנתים יצטרכו להתרגל אליו.
פתרונות לקושי של המתכנתים ללמוד את ה-flow של מערכת האלרטים החדשה
- מחקר SRE – יש ללמוד האם באמת המערכת תתן, ללא שינויים אקרובטייםֿ לצרכים של המערכת, ששווה לעשות את המעבר בשבילה? האם יש יותר מדי מעבר? צריך כמובן להתייעץ גם עם המתכנתים, לערוך הצבעות ולהיות בקשר רציף
- POC – חובה. לתת לקבוצת מתכנתים את הדרך החדשה, ולתת לזמן ולפידבקים לתת את שלהם
- יצירת כלי אדפטציה שנכנונים לארגון – מלמבדה שמשייכת את האלרט לקבוצה או האדם הנכון, עד שימוש בממשוקים OOTB של מערכות שיודעות לעשות את זה.
הקושי של המתכנתים בפורמט לוגים שונה
בלוגים יש מקום להמון יתרונות: יכולות למעקב על המטריקות הנכונות, יצירת קשרים למערכות שונות, הוספת metadata ועוד. אבל בכל מערכת לוגים יכולים להיות פורמטים שונים, ודברים שקל להעביר OOTB ומקומות שבהם יש תפיסה שונה.
פתרונות לקושי של המתכנתים בפורמט לוגים שונה
- מחקר SRE – מה היתרונות של פורמט הלוגים שנדרש במערכת החדשה? איזה פיצ׳רים אין בחדשה ויש בישנה? איך שומרים מטה דאטה שונה?
- יצירת כלי אדפטציה – מלוגר וממשוק נכון בכלים דוגמת Fluentd עד התאמה ברמת המערכת – אם יש
עלויות כספיות ״מוחבאות״
על-פניו, נעשתה בדיקה לפני המעבר – וההחלטה לעבור למערכת חדשה כנראה נבעה גם מהנקודה הכואבת: מערכת הלוגים הקיימת יקרה. זה יכול לנבוע מגדילה ניכרת של הארגון, או מארכיטקטורה לא נכונה של המערכת החדשה – או פשוט כי המערכת הקודמת צברה מוניטין והתייקרה. היא יכלה לנבוע מעלויות אחרות – המערכת הקודמת לא הייתה אמינה דיה, מטריקות נכתבו בדיליי משמעותי או לא נוסף מידע רלוונטי והמערכת מאד מסתמכת בזמן אמת עליהם.
אלא שיש עלויות מוחבאות – לפעמים הם נובעים מפיצ׳רים שאפילו לא ידענו שהם חלק מכל מערכת כי התרגלנו שיש אותה בקודמת. בזמן המחקר, אנחנו מגלים לכאורה שהיתרונות גדלים על החסרונות, אבל מביקוש רב של המפתחים אנחנו בוחרים להוסיף תשלום לפיצ׳ר נוסף שעוזר למפתח.
עלויות נוספות הם פיתוחים בלתי-צפויים להתאמה, ואפילו של revert למערכת הקודמת.
במאמר Reitzig, M., & Wagner, S. (2010). The hidden costs of outsourcing: Evidence from patent data. Strategic Management Journal, 31(11), 1183-1201. נכתב על עלויות של העברת פיתוחים ל-outsource – שם הגיעו למסקנה כי על אף הגמישות שמתאפשרת לארגון, לפעמים העלויות של שינוי האיכות פשוט לא שווים לארגון.
פתרונות לעלויות כספיות ״מוחבאות״
- מחקר SRE – לראות מה הפיצ׳רים הקיימים ומה לא. לא לחשוב שמשהו טריוואלי – כי כלום לא טריוויאלי. הדרך היחידה להגיע להחלטה נכונה היא להבין מה ה-tradoff – כולם.