5 דברים שלמדתי משבירת מונוליט על טכנולוגיה… ועל אנשים

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

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

מאת ילנה לוי

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

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

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

מה זה מונוליט, ולמה בכלל צריך לפרק אותו?

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

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

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

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

1. המטריקה משכנעת, לא הסמכות

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

2. המחישו לצוות את המחיר של "לא"

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

3. חזרו לבסיס

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

4. הרגע שבו התחלנו לראות באמת

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

5. בנו ארכיטקטורה שמוכנה גם ל-AI וגם לניסויים מהירים

ארכיטקטורה גמישה מאפשרת לכל צוות להריץ A/B test אמיתי בבידוד, לטעות מהר ובזול, ולחזור אחורה בלי דרמה ובזמן פיתוח אפסי. זו הסיבה שכל הפרויקט שווה את המחיר. סיבה נוספת היא שסוכני AI לא יכולים לפעול היטב ובסקייל גדול בתוך קופסה שחורה מונוליטית – הם צריכים APIs נקיים וגרנולריים. התשתית שתבנו היום כדי לבצע ניסויים מהירים תאפשר לכם לבנות עם AI בהמשך.

ואיפה הלקוח בסיפור?

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