הזמינות של שירותי אונליין ואפליקציות הפכה לקריטית בעולם של משתמשים חסרי סבלנות. מעבר לתהליך פיתוח מוכוון זמינות יכול להתבטא גם בחסכון בזמן וגם בהוצאות.
בשנים האחרונות יותר ויותר שירותים ויישומים מעדיפים להשקיע בפיתוח מהיר מאשר בשיפור הזמינות. השימוש בשירותי ענן מתקדמים וכלי ניטור משוכללים, יצר את הרושם שבעיית הזמינות שייכת לעבר, ושבכל רגע נתון ניתן פשוט “לזרוק עוד שרתים פנימה” בשביל לשפר את הזמינות. לא תמיד זה נכון.
בשירותים או אפליקציות בתשלום המיועדים לקהל עסקי, ספקי השירות מחויבים לזמני שירות מסוימים (SLA) והפרעה במתן השירות יכולה להוביל לאובדן הכנסות, או כמו במקרה של Slack “להזכיר” ללקוחות שהגיע הזמן לבדוק את המתחרים. גם במקרים של שירותים או אפליקציות חינמיים, בהן החברה מחויבת לנושא הזמינות, הפרעות בשירות יכולות לפגוע משמעותית באמינות ובמידת השימוש בו.
למרות החשיבות של זמינות תמידית, נדיר לפגוש חברות או סטרטאפים שמשלבים את הזמינות כחלק בלתי נפרד מתהליך הפיתוח וההפצה שלהם. פעמים רבות אני נתקל בחברות קטנות וגדולות בגישת ה”יהיה בסדר”, שכוללת הסתמכות על כוח אדם לא מיומן ב-NOC, שימוש בכלי ניטור שלא מוגדרים נכון, או האמונה שתמיד יהיה מישהו שיתעורר באמצע הלילה לתקן את הדברים. אבל הניסיון מוכיח שחוק מרפי עובד שעות נוספות, ובעיקר בשעות הקטנות של הלילה. כאשר תתרחש תקלה של מספר שעות בשירות שלכם והצוותים לא יתעוררו בזמן – את הנזק התדמיתי והכספי יהיה קשה מאוד לתקן לאחר מכן.
האמת נמצאת בנתונים
הדבר הראשון שעל חברה לעשות כדי לשפר את הראייה של זמינות כחלק מתהליך הפיתוח הוא לעקוב אחר הנתונים באופן תמידי. מעקב אחר נתונים של זמינות נעשה על ידי מחלקות -DevOps או במידה וקיים, על ידי מרכז הניהול הרשת (NOC). בחברות רבות נוהגים להציג מסכים עם לוחות מחוונים (דשבורדים) גם באזורים אחרים של המשרד, העוקבים אחר קצב הצטרפות לקוחות, אופן השימוש, מספר הפעולות שהתבצעו ועוד. זאת במטרה “להכניס לקצב” גם מחלקות שלא מעורבות באופן ישיר בפיתוח, כדי שיבינו את ההשפעות של ההחלטות שלהן בזמן אמת.
בחלק מהמסכים בסטרטאפים קטנים ניתן לפגוש גם נתון מעניין המוצג בזמן אמת – הכנסות מלקוחות משלמים. למרות זאת מעולם לא נתקלתי במסך שמציג נתוני הפסד במידה והשירות אינו זמין. את הנתון הזה קל יחסית לכמת – הכנסות חודשיות חלקי מספר הדקות בחודש (43,800 לעצלנים) יתנו לכם נתון מהיר שתוכלו להשתמש בו במידה שיש הפרעה בשירות. כאשר מציגים לצוותי הפיתוח וה-DevOps נתון כספי ברור צבוע באדום, עם סימן מינוס לידו שגדל בכל דקה, העובדים מפנימים בצורה ברורה את העלות האמיתית של זמן התקלה. זאת עוד לפני שנלקחה בחשבון העלות של זמן העבודה שמוקצית כרגע לתיקון תקלה במקום עבודה על משימות מתוכננות.
פיתוח מוכוון זמינות
החשיבות של הזמינות לא יכולה להסתכם בנתונים בלבד. למרות מתודות הפיתוח האג’יליות שבהן משתמשים בחברות רבות בצורה כזאת או אחרת, לא תמיד הזמינות זוכה להתקדם בסדר העדיפות. כחלק מהמעבר לפיתוח מוכוון זמינות, יש לכלול את כל צוותי המוצר בחברה – עיצוב, פיתוח, בדיקות, DevOps ואפילו תיעוד – כדי להעביר לכולם את החשיבות בזמינות.
אחת הדוגמאות הקלאסיות למהלך כזה, ניתן ליצור במיקרוסופט בתחילת שנות ה-2000. באותה התקופה מוצרי החברה סבלו מבעיות אבטחה רבות מה שפגע משמעותית בתדמית החברה. מהלך גדול מאוד שהוביל ביל גייטס באותן השנים, הביא לכך שכל הצוותים בחברה כללו חשיבה על אבטחה בכל שלב של המוצר, מה שהוביל לשיפור גדול מאוד מבחינת אבטחת המוצרים באותן שנים, והשריש בחברה את הפיתוח מוכוון האבטחה.
המהלך במיקרוסופט שיפר לא רק את האבטחה אלא את תהליך הפיתוח כולו. גם במקרה של חשיבה ממוקדת זמינות, ופיתוח מוכוון זמינות הארגון כולו יכול להרוויח. מהניסיון שלי, הרבה פעמים תהליך כזה מוביל לגילוי שאין נהלים בחברה לפיתוח והפצה בצורה מסודרת, לא תמיד יש חשיבה על שימוש נכון בכלי ניטור, ובחלק מהמקרים מגלים כי מידע קריטי נמצא אצל אדם בודד, דבר שיוצר תלות בעייתית לארגון כולו. התהליך מוביל גם לשיפור בחשיבה בכל הנושא של בדיקות (Tests) בזמן הפיתוח, וכאשר המפתחים יודעים כי המוכוונות היא לזמינות, חלה עלייה משמעותית גם בתחום הזה.
חשוב לזכור כי כמו בכל תהליך של שיפור עבודה, יש להיזהר מ”שיפור יתר”. שימת דגש על זמינות בלבד יכולה להוביל לכך שצוותי פיתוח מעדיפים להיות זהירים יתר על המידה מעדכונים ותוספות כדי להימנע מיצירת בעיות בזמינות. אפשרות אחרת היא מרדף בלתי פוסק של צוותי ה-DevOps בשיפור מהירות וזמינות, תוך השקעה במשאבים רק בשביל זמינות ולא ניסיון לאזן בין התקציב ודרישות הגיוניות. לכן לפני תהליך של שיפור הזמינות, כדאי לקבוע מדדים מקובלים על כל צוותי הארגון מראש לגבי יעדי הזמינות, קצב העדכונים, מגבלות התקציב וכו’.
הקצב של השינויים הטכנולוגיים והדרישות של הלקוחות לגבי זמינות רק עולים. שיפור פנימי של החברה, ויצירת תשתית טכנולוגית וניהולית לפיתוח שלוקח בחשבון את דרישות הזמינות של היום, יקצר את זמני הפיתוח ויחסוך בהוצאות החברה גם בעתיד.
