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

סוף מעשה במחשבה תחילה

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

מה יש לנו לתכנן?

א.     תיקוני תקלות –

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

ב.     שלבי עליה לאוויר –

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

1. פעילויות מקדימות לתאריך היעד – ביצוע הסבות נתונים, ביצוע הדרכות, בדיקות משתמשים (כוללות או מדגמיות), ביצוע סימולציות פעולה במערכות ארגוניות ועוד…
2. הקפאת תצורה – קביעת תאריך להקפאת תצורת המערכת. מתאריך זה ועד לעליה לאוויר תבוצענה רק פעולות תיקון קריטיות.
3. תכנון חלון הזמן לביצוע – מתי תבוצע ההתקנה, כמה זמן יש לביצוע, כמה זמן יש לחזרה אחורה במקרה של כשלון. תכנון זה הוא קריטי מכיוון שחלון הזמן העומד להתקנה, בעיקר במקרים של שדרוגים, הינו קצר.
4. יום העליה לאוויר – ביצוע גיבויי מערכת (מערכות ונתונים), הפסקת פעילות ארגונית, ביצוע הסבות נתונים, ביצוע התקנות תשתיתיות נדרשות, ביצוע התקנות המערכת, בדיקות מדגמיות למערכת ושחרור המערכת לארגון.

ג.      תכנון נקודות בקרה ומיזעור סיכונים –

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

ד.      תכנון כח אדם ותחומי אחריות –

מיהם האנשים הנדרשים לביצוע התהליך – אנשי פיתוח, אנשי בדיקות, אנשי תשתיות, מנהלי מוצר, לקוחות וכו', מהם תחומי האחריות של כל אחת מהקבוצות המעורבות ומהו נוהל הדיווח על הצלחות וכשלונות.

ה.     תכנון היום שאחרי –

הקצאת משאבים למעקב, בקרה ותיקונים הנובעים מהעליה לאוויר.

ו.       ביצוע סימולצית התקנה –

בתהליך זה נעלה על נקודות שלא עלו בתהליך התכנון.

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

יום העליה לאוויר

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

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

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

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

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

סיום העלייה לאוויר

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

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

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