כשמערכת משקפת מבנה ארגוני

אחרי שדיברנו על Deploys, Rollouts, ותאימות לאחור, קל לחשוב שכל הבעיות הן טכניות.

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

האשליה: “המערכת נבנתה ככה כי זה הכי נכון”

כשמסתכלים על מערכת מורכבת, קל להסביר את המבנה שלה במונחים של:

• סקייל
• ביצועים
• והחלטות ארכיטקטוניות

אבל לעיתים קרובות, הסיבה האמיתית פשוטה יותר:

ככה הארגון בנוי.

מבנה הארגון נחרט בקוד

מערכת לא מתפתחת בוואקום. היא נבנית על ידי:

• צוותים
• גבולות אחריות
• תהליכי עבודה
• ויחסי גומלין

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

לא צריך להכיר תיאוריה כדי לראות את זה. מספיק להסתכל על:

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

שם עובר קו ארגוני.

גבולות שירותים כגבולות אחריות

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

• מי אחראי על מה
• מי יכול לשנות בלי לבקש אישור
• ומי “רק צורך”

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

והמערכת משלמת:

• ב-Latency
• ב-Retries
• ובתלות שקשה לנתק

דוגמה קטנה: למה יש שני כפתורי “אישור”

במערכת יש פעולה אחת פשוטה: אישור פעולה של משתמש.

יש כפתור “אישור” במסך אחד, וכפתור “אישור” במסך אחר.

שניהם עושים כמעט אותו דבר.

למה שניים?

לא כי זה נכון. לא כי זה יעיל.

אלא כי: מסך אחד נבנה על ידי צוות A המסך השני נבנה על ידי צוות B

כל צוות היה צריך “רק אישור קטן”. וכל אחד הוסיף את שלו.

בהתחלה זה נראה זניח.

ואז מתחילות השאלות: למה הכפתור הזה מתנהג אחרת? למה כאן יש בדיקה, ושם אין? למה באג תוקן במסך אחד - וחזר בשני?

וכששואלים: “למה זה בנוי ככה?”

אין תשובה טכנית טובה.

התשובה היא: “זה היה יותר קל לכל צוות לבד”.

זו לא החלטה הנדסית. זו חלוקת עבודה שהתקבעה בקוד.

למה ריפקטור ארגוני קשה יותר מטכני

קוד אפשר לשכתב. ארכיטקטורה אפשר לשנות. אבל מבנה ארגוני - קשה הרבה יותר להזיז.

לכן:

• שירותים נשארים “זמניים” שנים
• תלויות נשמרות “כי ככה זה עובד”
• ומורכבות הופכת לבלתי ניתנת לפירוק

המערכת אינה תקועה טכנית - היא תקועה ארגונית.

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

במערכת יש שלושה שירותים:

user-profile, customer-data, account-info

כולם: מחזיקים פרטים דומים, עושים ולידציות דומות, ומדברים עם אותם מקורות מידע.

למה שלושה?

לא בגלל סקייל. לא בגלל ביצועים. וגם לא בגלל design pattern.

הסיבה האמיתית:

צוות A אחראי על onboarding. צוות B אחראי על billing. צוות C אחראי על support.

כל צוות היה צריך “רק קצת מידע על המשתמש”. וכל צוות בנה שירות קטן “שלו”.

בהתחלה זה היה זמני. בהתחלה זה היה הגיוני. בהתחלה זה אפילו עבד.

ואז התחילו הבעיות:

• שינוי בשדה אחד דורש שלושה Deploys
• Bug מתוקן במקום אחד וחוזר במקום אחר
• Latency עולה כי כל פעולה עוברת דרך כמה שירותים
• ואף אחד לא באמת “בעלים” של התמונה המלאה

וכששואלים: “למה זה בנוי ככה?”

התשובה אינה: “כי זה הכי נכון ארכיטקטונית”.

התשובה היא: “ככה הצוותים מחולקים”.

איפה זה נחרט בקוד

• API boundaries חופפים לגבולות צוות
• קריאות רשת במקום קריאות פנימיות
• ושכבות תיאום שנולדו רק כדי שצוותים לא יצטרכו לדבר

המערכת לא מספרת סיפור טכני - היא מספרת מי היה צריך לעבוד עם מי, ומי העדיף לא.

המשל

אפשר לחשוב על עיר.

רחובות, גשרים ושכונות נראים כמו החלטות תכנוניות.

אבל בפועל, הם תוצאה של:

• חלוקות אדמה ישנות
• אינטרסים
• והיסטוריה שלא נמחקה

גם אם היום יש טכנולוגיה טובה יותר - קשה לשנות עיר בנויה.

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

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

מי שמנסה “לתקן את הקוד” בלי לגעת במבנה האנושי - מגלה שהבעיות חוזרות בצורות אחרות.

מערכות יציבות נבנות כשהארגון מוכן להסתכל על עצמו.

מבט קדימה

וכשמערכת כבר שוברת - הרגע החשוב ביותר אינו הכשל עצמו, אלא מה שקורה אחריו.

בפוסט הבא נעסוק בשאלה למה Incident response הוא עניין של תרבות - ולא של פרוצדורה.