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

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

ממפים אחריות במקום שמות מוצרים

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

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

מזהים את גבולות האחריות החדשים

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

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

בוחרים מסלול קטן מקצה לקצה

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

Local service -> repeatable deployment -> managed storage
             -> identity and secrets -> monitoring -> recovery test

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

לא מחליפים הכול במכה אחת

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

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

מציגים את הפער בכנות בראיון

אפשר לומר: ״לא ניהלתי את השירות הזה ב־Production. כן הייתי אחראי על גיבוי ושחזור במערכת הקודמת, ובפרויקט תרגול בדקתי את מנגנון השחזור בסביבה החדשה״. יש כאן הפרדה בין ניסיון, למידה ויכולת שעוד דורשת תרגול.

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

תכנית עבודה לשבועיים

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

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