תקלות בפלאפון ומה כולם יכולים ללמוד מכך

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

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

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

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

וכאן מגיעה הבעיה שנמצאת אצל חברות רבות (שוב, לא מדבר ספציפית על פלאפון או על כל חברה אחרת): אין תכנון מספק ל-Roll Back. אני בערך 26 שנה בתחום, והיו לי מאות מקרים שבהם שדרוגים שברו מערכות פרודקשן, גם כשב-LAB הכל עבד פרפקט. מה לעשות, דברים כאלו מתרחשים גם כשעושים את כל המאמצים למנוע את התקלות.

בעבר הרחוק, אמצעי העזר שעמדו לרשותך היו קבצי TAR (בלינוקס, יוניקס) שהכנת לפני השדרוג (אם כמובן גיבית את הכל והתוכנה לא זורקת איזה קובץ so באיזה חור נידח והוא לא כלול בקובץ TAR) או גיבוי לקלטת. עם מערכות Solaris היה אפשר להשתמש ב-Veritas Volume Manager כדי ליצור Snapshot, בלינוקס בזמנו היה LVM אבל לא היה Snapshot וב-Windows (לפני שנות ה-2000) המצב לא היה טוב יותר.

עכשיו ב-2018 דברים השתנו. הרוב רץ על VM כיום אז אין בעיה ליצור Snapshot לכל המכונות המושפעות משדרוג ואם יש תקלה, אפשר לחזור אחורה. כל DB מאפשר לעשות dump שבמקרה הצורך ניתן לשחזרו, ובכל מערכת DR ניתן לעשות את הסינכרון הדו כיווני המתמשך כשעושים עבודת שדרוג.

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

לכן, שדרוגים לא צריכים רק להיבדק רק על המכונה (או על רפליקציה של המכונה ב-LAB) אלא גם על המכונות שמושפעות מכך, ויש צורך לעשות גיבוי או snapshot לכל דבר שמושפע, כך שאם רכיב מסויים דופק דברים, צריך לעשות rollback לא רק לרכיב, אלא גם למכונות שהושפעו מכך (אם הושפעו). Snapshot, אני מעוניין להזכיר, שומר רק את ה-Delta (שינויים) בין המצב של המערכת לפני ה-Snapshot ולמצב הנוכחי, כך שלא מדובר במקום רב בדיסק, כך שאין צורך לחשוש לגבי מקום בדיסק בגלל Snapshot (כמובן שמומלץ כמה ימים אחרי השדרוג לבטל את ה-Snapshot ואם צריך לשחזר – להשתמש בגיבוי).

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