Internal Developer Platform: היכן נשברת אספקת השינויים
כל עוד יש עשרה שירותים, אספקת השינויים נשענת על אנשים: לכל צוות יש סקריפטים משלו, סדר בנייה משלו ודרך משלו להעלות ארטיפקט לסביבה. בסביבת העבודה מופיע Kubernetes — אבל לא כשכבה אחידה, אלא כעשר הסכמות שונות לגבי מי ומתי כותב אליו.
הוצאת מהדורה הופכת לפעולה ידנית עם חלון לילה: לבנות, לבדוק, להעלות, להמתין, לבצע החזרה לאחור במקרה של כישלון.
הפערים בין הסביבות מצטברים בלי לשים לב. סביבת הבדיקות שונה מסביבת הפרודקשן בכמה שינויים שאיש לא תיעד, קונפיגורציות מתוקנות ישירות בסביבה החיה, והתקלה משוחזרת פה ושם.
המחיר — לא רק שעות של מהנדסים: אספקת שינויים מקצה לקצה מתפרקת, ואיש לא יכול לומר בביטחון מה בדיוק עלה לפרודקשן ואיך להחזיר אותו לאחור.
כך נראית internal developer platform שנבנתה מחלקים במקום כמכלול אחד. בהמשך נפרט איך סוגרים את זה: מה מתוקנן, היכן עוברים גבולות האחריות של הצוותים ואיך בנויה הוצאה שבה העלאות ידניות הן חריג ולא הנורמה.
מה נותנת הפלטפורמה: השפעה על זמנים, השבתות ותקלות
ההשפעה של הפלטפורמה נמדדת בשלושה מספרים: הזמן משינוי בקוד ועד שירות עובד, זמן השחזור לאחר תקלה ושיעור הפעולות שהמהנדס סוגר בעצמו. לפני ההטמעה מהדורה טיפוסית עוברת דרך אישורים וצעדים ידניים, והשחזור אורך שעות — מצב הסביבות נשמר בראשים, לא בתיאור.
אחרי ההטמעה נתיב השינוי מתקצר לשעות, והחזרה לאחור הופכת לפקודה אחת: הסביבות מתוארות באופן דקלרטיבי, גרסאות קודמות והיסטוריית פריסות זמינות. זמן השחזור יורד לא בזכות תורן-גיבור, אלא מפני שסיבת התקלה נראית ביומני ההוצאה, והשירות חוזר למצב עבודה ידוע באופן צפוי.
מדד נפרד — שיעור הפעולות החוזרות שעברו לשירות עצמי: להקים סביבה למשימה, להנפיק גישה, להוסיף סוד, לשנות פרמטר קונפיגורציה. בעבר כל פעולה עברה דרך בקשה ואדם אחד, כעת היא מבוצעת באותה צורה אצל כל מהנדס, וצוות הפלטפורמה מפסיק להיות צוואר בקבוק.
נעלם גם סוג שלם של כשלים: פערים בין סביבות, drift של קונפיגורציות, «אצלי זה עובד», גישות של עובדים שפוטרו, סודות במאגר, מהדורה בלי דרך חזרה.
הבסיס — Kubernetes כסביבת הרצה אחידה: הצוותים מקבלים חוזה אספקה אחד, וצוות הפלטפורמה מפתח מודולים משותפים במקום תמיכה ידנית בכל שירות בנפרד.
גישות להטמעה: פתרון מוכן, בנייה, היברידי
בחירת המודל נקבעת לא לפי גודל החברה, אלא לפי בגרות התהליכים ומי יהיה הבעלים של הפלטפורמה לאחר ההשקה. אם קטלוג השירותים, תבניות המאגרים ומדיניות הגישה כבר מבוססים, הפלטפורמה מתארת אותם ומסירה מהצוותים את השגרה.
אם התהליכים משתנים כל שבוע, הפלטפורמה תקבע את סדר הדברים הנוכחי — יחד עם כל החריגים שיהיה צורך לתמוך בהם ידנית בהמשך.
כדאי להשוות את האפשרויות בשלושה צירים: זמן עד לתועלת הראשונה, הפיכות הפתרון והיקף עבודת התחזוקה של הפלטפורמה. להלן שלושה מודלים והגבולות שמעבר להם כל אחד מהם מתחיל להפריע.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| פתרון מוכן | התהליכים סטנדרטיים, הפורטל נדרש בזמן קצר, אין צוות פלטפורמה משלכם | ההרחבה נעשית דרך קונפיגורציה ומודולים מוכנים — תרחיש לא סטנדרטי יש להשלים בכתיבה |
| בנייה עצמית | קיים צוות פלטפורמה ודרישות משלכם לקטלוג השירותים, לתבניות ולמדיניות הגישה | זמן ארוך יותר עד לתוצאה הראשונה, יורש תלויות פנימיות, נדרש בעלים קבוע |
| היברידי | את הליבה לוקחים מוכנה, ואת קטלוג השירותים, התבניות והחיבור לבנייה משאירים משלכם | הגבול בין הליבה לתוספת דורש משמעת: עדכוני הליבה נבדקים יחד עם ההתאמות |
היברידי נבחר לרוב: הוא נותן התחלה מהירה ומשאיר מקום למה שבאמת מייחד את הפיתוח שלכם. כדאי להסכים מראש על מה שנשאר בליבה ואינו נכתב מחדש — אחרת תחזוקת הפלטפורמה הופכת לתמיכה נצחית בענף משלכם.
שלבי העבודה: מביקורת סביבות ועד מסירה לצוות
בנייה של internal developer platform לא מתחילה בהתקנת כלים — תחילה מתעדים את המצב בפועל: מה כבר פרוס, מי מחזיק בגישות, היכן הקונפיגורציות נבדלות בין הסביבות. כל צעד הבא נשען על התוצאה של הקודם, ולכן הפלטפורמה לא שוברת מהדורות עובדות.
- ביקורת סביבות — מלאי שירותים, סביבות ותלויות חיצוניות, פערי קונפיגורציה ופעולות ידניות שגוזלות זמן מהצוותים. בפלט — מפת עדיפויות.
- סכמת הפלטפורמה — שכבות: קטלוג שירותים, תבניות סביבה, מדיניות גישה, חיבורים לבנייה ולניטור; בנפרד מתעדים את הגבולות — מה הפלטפורמה לוקחת ומה נשאר לצוותים.
- הגדרת סביבות — קו ניהול, כניסה אחידה ותפקידים, מאגר סודות, מגבלות ומכסות, חיבור סביבות קיימות בלי לבנות אותן מחדש.
- צוותי פיילוט — מעבירים שניים-שלושה צוותים בעומסים שונים: התבניות נבדקות על מהדורות אמיתיות, לא על סביבת הדגמה.
- בדיקות קבלה — פריסה, החזרה לאחור, הנפקת גישות, שחזור סביבה לאחר תקלה; את זמן כל פעולה משווים למדידות המקוריות.
- מסירה לצוות — קונפיגורציות, סכמות, מדיניות והוראות, הדרכת תורנים; בהמשך הפלטפורמה חיה אצלכם, ואנחנו נשארים בתמיכה בשינויים.
מה נשאר אצלכם: קונפיגורציות, סכמות, נהלים
לאחר הטמעת פלטפורמת שירות עצמי (internal developer platform) כל התשתית נשארת אצלכם — במאגרים שלכם ובחשבונות שלכם, ולא בסביבה סגורה של הספק. אנחנו במכוון לא מחזיקים קונפיגורציות «אצלנו»: כל מהנדס בצוות יכול להקים סביבה, לשנות מדיניות ולהבין את סכמת השירותים בלי לפנות אלינו.
מה מעבירים לפי פרוטוקול מסירה:
- קונפיגורציות סביבה — פיתוח, קדם-פרודקשן ופרודקשן מתוארים דקלרטיבית, עולים בפקודה אחת, והפערים בין הסביבות נקראים בהשוואת קבצים, ולא משוחזרים מהזיכרון.
- סכמות שירותים ותלויות — מה קשור למה, היכן עובר גבול האחריות של הצוותים ואילו צמתים הופכים לנקודת כשל.
- מדיניות גישה — תפקידים, תחומי נראות, סדר הנפקת הרשאות לפי בקשה ויומן שינויים: מי ומתי שינה קונפיגורציה.
- נהלי תפעול — איך מוציאים מהדורה, איך מחזירים אותה לאחור תוך דקות, איך תורנים ומה עושים בעת תקלה.
- תיעוד — קטלוג שירותים, הוראות למהנדס חדש ותיאור של איך הפלטפורמה בנויה מבפנים.
- קטלוג תבניות שירות עצמי — תבניות שירות כדי שצוות חדש יקים פרויקט בעצמו, בלי להמתין לצוות התשתיות.
- סדר עדכון וגיבוי של הפלטפורמה עצמה — כדי שהיא לא תישאר במצב של קבלה.
- צ'ק-ליסט קבלה עם מדדי יעד — לפיו אתם מקבלים את העבודה ואחר כך בודקים שהפלטפורמה חיה.
מקרה בוחן: זמן הוצאת השינויים התקצר פי כמה
הלקוח — צוות מוצר של ארבעים מהנדסים שמתחזק שישה שירותים על Kubernetes. סביבות נפרסו ידנית לפי בקשה בתור של צוות התשתיות: סביבה לבדיקות עומס חיכו עד יומיים, והקונפיגורציות של סביבת הבדיקות וסביבת העבודה נבדלו — חלק מהפגמים צצו כבר בסביבת העבודה.
מהדורה הוצאה אחת לשבועיים בחלון לילה, החזרה לאחור ארכה כארבעים דקות ודרשה תיקונים ידניים. בניות ובדיקות הורצו על מכונות של מפתחים, ולכן אותו קומיט אצל שני מהנדסים נתן תוצאה שונה.
מה שינינו
פרסנו פלטפורמת מפתחים פנימית (internal developer platform): קטלוג שירותים, תבניות סביבה וקו אספקה משותף. תיאור התשתית הועבר לקוד עם תבניות ניתנות לירושה — סביבת בדיקות, ביניים ועבודה נבנות ממקור אחד ונבדלות רק בקבוצת פרמטרים. סביבה מקימים בעצמם מתוך הקטלוג, בלי בקשות והמתנה בתור.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| סביבה מוכנה | עד 2 ימים לפי בקשה | 12–15 דקות |
| הוצאת שינויים | אחת לשבועיים | 6–8 פעמים בשבוע |
| החזרה לגרסה קודמת | ~40 דקות ידנית | פקודה אחת, ~2 דקות |
| שינויים דרך בדיקות אוטומטיות | כשליש | 100% |
פניות טיפוסיות לצוות התשתיות פחתו בכ-70%: המהנדסים עברו מהנפקת סביבות לפיתוח הפלטפורמה. שיעור התקלות עקב פערים בין סביבות ירד כמעט לאפס — הקונפיגורציה כעת אחת לכל הסביבות, והפער נראה בשלב הבדיקה, לא אחרי ההוצאה.
מה לעשות אם הצוותים כבר חיים על הסקריפטים שלהם?
לא מכבים סקריפטים ביום השקת הפלטפורמה — בדיוק כך לרוב מכשילים מהדורות. אנחנו מקימים internal developer platform לצד הנתיבים הקיימים, ובשלב הראשון מעבירים אליה רק את הבנייה ואת סביבות הבדיקות, ומשאירים את סקריפטי העבודה של הצוותים ללא שינוי. מחזור הוצאת הגרסאות לא משתנה, והצוות בכל רגע יכול לחזור לדרך המוכרת אם החדשה תיכשל.
הדו-קיום של הכלים נשען על שכבת תאימות דקה: סקריפט ישן נקרא מתוך הקונפיגורציה החדשה כצעד נפרד, ולכן בדיקות, הרשאות ותיאורי סביבה לא משוכפלים, אלא חיים במקום אחד. ההטמעה ההדרגתית נעשית בגלים — קודם צוות מתנדב אחד, אחר כך אלה שמוציאים גרסאות בתדירות הגבוהה ביותר, ורק לאחר מכן השאר. קריטריון הבשלות של גל — בנייה והחזרה לאחור משוחזרות בלי פעולות ידניות.
מיגרציה של סקריפטים מתחילה במלאי, לא בכתיבה מחדש: אילו משימות באמת מריצים, אילו משכפלות זו את זו, מה נשען על אדם אחד וייעלם יחד איתו.
מעבירים משימה אחת בכל פעם, ורק כשהקונפיגורציה החדשה נותנת את אותה תוצאה בתוספת החזרה לאחור והיסטוריית הרצות; את הדרך הקודמת לאחר מכן לא מוחקים, אלא מקפיאים — למקרה שיצופו תלויות לא ברורות.
השלב נחשב להסתיים כשהצוות בונה ומוציא גרסה בלי צעדים ידניים ובלי לפנות למחבר הסקריפט. כך הפלטפורמה צוברת כיסוי בהדרגה, במקום להפוך למציאות מקבילה שכולם עוקפים.
ספקות טכניים נפוצים: סביבות, גישות, תמיכה
הפלטפורמה עומדת בין המפתח לתשתית, ולכן בשלב בחירת הספק השאלות חוזרות: איך זה יסתדר עם הסביבה הנוכחית, מי ומה יוכל לשנות, ומה יקרה כשהצוות החיצוני יעזוב את הפרויקט.
את הפלטפורמה מתכננים מעל הסטאק הקיים, לא במקומו: מניפסטים, תיאורי תשתית וקווים נשארים במאגרים שלכם. להלן תשובות קצרות למה שצף לרוב.
איך ייבנו הסביבות?
סביבות עולות דקלרטיבית מתבנית אחת: dev, stage ו-prod נבדלות רק בפרמטרים ובמגבלות. לענף אפשר ליצור סביבה חד-פעמית עם מחיקה אוטומטית לאחר מיזוג — מספר הסביבות גדל בלי עבודה ידנית.
איך מוגבלת הגישה?
תפקידים מונפקים דרך כניסה ארגונית, הרשאות מתוארות ברמת הצוות, השירות והפעולה הבודדת. סודות נשמרים בנפרד ומוזרקים בזמן ההוצאה, ולא מונחים במאגר: המפתח מקבל גישה לשירות, אבל לא לפרטי החשבון.
מי מתחזק את הפלטפורמה לאחר ההשקה?
מעבירים תיעוד, סכמות וכללי תורנות, כדי שאפשר יהיה להפעיל את הפלטפורמה בלעדינו. עדכונים והחזרות לאחור עוברים באותו קו כמו שירותים רגילים — הפלטפורמה לא הופכת לקופסה שחורה בלתי מתוחזקת.
עד כמה זה תואם למערכות הקיימות?
אין צורך במעבר: הפלטפורמה עוטפת מאגרים קיימים, רישום אימג'ים וניטור, ופונה אליהם דרך API. מקרה לא נתמך נסגר באמצעות אדפטר נפרד, ולא בהחלפת הכלי הרגיל.
נדון במשימה ונחזור עם הערכה ותוכנית
כדי שהערכת הזמנים תהיה מציאותית והתוכנית — עובדת, אנחנו צריכים נתוני קלט על הלандшафт שלכם. שום דבר אקזוטי: מה שכבר נמצא במאגרים, בטיקטים ובראשים של המהנדסים. ככל שהקלט מדויק יותר, כך פחות הנחות בהערכה ופחות הפתעות בשלב ההטמעה.
- רשימת שירותים וצוותים-בעלים: כמה מאגרים, מי אחראי על ההוצאה, היכן נשארו צעדים ידניים.
- סכמת סביבות: פיתוח, סביבת בדיקות, פרודקשן — במה נבדלות הקונפיגורציות והיכן נשמרים הסודות.
- קו הבנייה והאספקה הנוכחי: אילו שלבים כבר אוטומטיים, ובאיזה מהם ההוצאה נתקעת לרוב.
- גישות ומגבלות: ענן או שרתים משלכם, דרישות אבטחה, תפקידים בקלאסטר, מי מנפיק הרשאות.
- משוב מהמהנדסים: למה ממתינים הכי הרבה, אילו פעולות עושים ידנית, היכן הולך לאיבוד זמן בקליטת אדם חדש.
בתגובה נחזיר תוכנית: מפת הפלטפורמה — אילו שירותי שירות עצמי סוגרים ראשונים, שלבי הטמעה עם הערכת זמנים, סכמת תפקידים וגישות, דרישות לתשתית וקריטריוני מוכנות לכל שלב. ההערכה נעשית לפי שלבים, לא במספר אחד: כך רואים מה מוציאים ראשון, ואיפה נדרשות החלטות מצדכם.
תארו את המשימה — נחזור עם הערכה ותוכנית. אם חלק מנתוני הקלט עדיין לא זמין, נתחיל ממה שיש: פערים בדרך כלל נסגרים בשלב הסקר ולא מעכבים את העבודה.