Ownership כחרב פיפיות

Ownership נחשב לאבן יסוד בהנדסה יציבה. “שיהיה ברור מי אחראי” נתפס כמעט תמיד כפתרון.

אבל במערכות מורכבות, Ownership לא רק מגן - הוא גם יוצר גבולות מסוכנים.

האשליה: יותר Ownership = יותר אחריות

כשמשהו נשבר, השאלה הראשונה היא: “מי הבעלים?”

וכשיש תשובה ברורה - יש תחושת ביטחון.

אבל הביטחון הזה מטעה. כי Ownership מגדיר לא רק אחריות - הוא מגדיר גם מה לא באחריות.

מתי Ownership מונע שיפור

Ownership מתחיל להזיק כש:

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

במצב כזה, אף אחד לא פועל בזדון. כולם עושים את עבודתם היטב.

והמערכת כולה מדרדרת.

אזורי “לא שלי” כמקורות סיכון

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

שם שומעים משפטים כמו:

• “זה לא אצלנו”
• “אנחנו רק צרכנים”
• “ה-SLA שלנו בסדר”

כל אחד צודק מקומית. אבל אף אחד לא רואה את הסיכון המצטבר.

דוגמה פשוטה

שירות A אחראי על אימות. שירות B אחראי על נתונים. שירות C אחראי על חוויית משתמש.

כשיש latency חריג:

• A אומר: “האימות מהיר”
• B אומר: “ה-DB עומד ביעדים”
• C אומר: “אנחנו רק מציגים”

אין באג ברור. יש Ownership מושלם.

והמשתמש סובל.

למה יותר בעלות לא תמיד אומרת יותר אחריות

Ownership טוב עובד כשיש:

• גבולות חדים
• בעיות מקומיות
• והשפעה חד-כיוונית

אבל במערכות חיות:

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

בשלב הזה, Ownership חייב להשתנות מ “מי אחראי על הקוד” ל “מי אחראי על ההתנהגות”.

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

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

מערכות בוגרות לא מבטלות Ownership. הן מוסיפות מעליו שכבת אחריות מערכתית.

מבט קדימה

אם Ownership לבדו אינו מספיק, אולי הבעיה אינה באנשים - אלא בתהליכים שהם נדרשים לעבוד לפיהם.

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