תמריצים חזקים יותר מארכיטקטורה

יש אמונה עמוקה בהנדסה: שאם נארגן את הקוד נכון - המערכת תתנהג נכון.

אבל במערכות אמיתיות, הקוד הוא לא הכוח החזק ביותר שפועל.

אלא התמריצים.

האשליה: “אם הארכיטקטורה טובה, ההתנהגות תסתדר”

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

• איפה התכנון נכשל
• איזה abstraction חסר
• ואיפה צריך לעשות refactor

אבל לעיתים קרובות, המערכת עושה בדיוק את מה שגרמו לה לעשות.

לא דרך הקוד - אלא דרך מה שנמדד, מתוגמל ונענש.

KPI מול יציבות מערכתית

רוב הצוותים לא קמים בבוקר כדי לשבור מערכת. הם קמים כדי לעמוד ביעדים.

וכשיעדים מוגדרים כ:

• זמן תגובה ממוצע
• מספר פיצ’רים ברבעון
• עמידה ב-SLA נקודתי

המערכת מתחילה להתעוות סביבם.

לדוגמה:

צוות נמדד על latency של השירות שלו. הדרך הקלה לעמוד ביעד היא:

• לקצר timeouts
• להחזיר fallback אגרסיבי
• ולהעביר אחריות לשירות אחר

ה-KPI נראה טוב. המערכת הכוללת - פחות.

לא בגלל קוד גרוע. בגלל מדידה מקומית שמתגמלת נזק גלובלי.

למה צוותים “עושים את הדבר הלא נכון בצורה מושלמת”

כשהתמריץ ברור, אנשים נהיים יצירתיים.

לא ביצירת פתרונות - אלא ביצירת עמידה במדדים.

כך נוצרים דפוסים מוכרים:

• פתרונות שמסיטים עומס במקום לפתור אותו
• קאש שמסתיר בעיות במקום לטפל בהן
• קוד שמקשה על אחרים, אבל “זה לא הבעיה שלנו”

זו לא רשלנות. זו אופטימיזציה.

פשוט לא לאותו יעד שהמערכת צריכה.

מתי metric טוב הופך לנזק

כל metric הוא הנחה סמויה על מה שחשוב.

הוא הופך למסוכן כש:

• הוא נמדד בלי הקשר
• הוא שייך לצוות אחד אבל משפיע על אחרים
• והוא נשאר קבוע גם כשהמערכת משתנה

בשלב הזה, המדד כבר לא משקף מציאות - הוא מייצר אותה.

והארכיטקטורה תתכופף בהתאם.

השורה התחתונה

מערכות לא מתנהגות לפי הדיאגרמות. הן מתנהגות לפי התמריצים.

מי שמנסה “לתקן ארכיטקטורה” בלי לשאול:

• מה מתוגמל כאן
• מה נענש
• ומה פשוט לא נראה

יגלה שהקוד משתפר - והמערכת לא.

מבט קדימה

אם תמריצים מכתיבים התנהגות, מי בכלל אחראי על המערכת?

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

Ownership.