תחזוקת תוכנה אחרי העלייה לאוויר: מי אחראי למה?

מגדירים איזו עבודה נכללת בתחזוקה

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

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

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

לכל אחריות מצמידים תוצאה שאפשר לבדוק

מענה, חזרה לעבודה ופתרון התקלה הם שלבים שונים

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

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

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

מתרגלים תקלה שבדיקת זמינות עלולה לפספס

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

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

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

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

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

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

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

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

האם צוות אחר יוכל לתפעל את המערכת?

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

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

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