מתכנתים, devops והחתולים של שרדינגר

המציאות של מהנדס רשת (עם אטריות ו...מלח?)

לאחרונה, תוך כדי דיון על אירועים שונים עם מהנדסים, הבחנתי בדפוס מעניין.

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

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

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

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

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

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

הנחה בסיסית של פיתוח תוכנה: אותם נתוני קלט מייצרים באופן אמין ודטרמיניסטי את אותו פלט.

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

בכל מקרה, דטרמיניזם הוא הנחה בסיסית, כמעט מובנת מאליה, לרוב העבודה שעושים מתכנתים.

אבל עבור כל בחור devops שבילה את היום בצבר חומרה או בפיתוח API של ענן, הרעיון של עולם דטרמיניסטי לחלוטין (כל עוד אפשר אפילו למפות את כל התשומות!) הוא מושג חולף במקרה הטוב. גם אם תשים את זה בצד בדיחות של BOHF על כתמי שמש, מהנדסים מנוסים ראו את הדברים המוזרים ביותר בעולם הזה. הם יודעים את זה אפילו צעקה אנושית יכולה להאט את השרת, שלא לדבר על מיליוני גורמים אחרים בסביבה.

אז קל יותר למהנדסים מנוסים להטיל ספק בכך שלכל התקריות יש גורם שורש אחד, וטכניקות כמו "חמשת הסיבות" יובילו בצורה נכונה (וחזרה!) לגורם השורש הזה. למעשה, זה סותר את הניסיון שלהם, שבו חלקי הפאזל לא משתלבים בצורה כל כך מסודרת בפועל. לכן, הם מקבלים את הרעיון הזה ביתר קלות.

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

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

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

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

מקור: www.habr.com