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

מישהו אתמול פתח בפורום 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 מלא להכל לפני שמריצים את פקודת השדרוג.

אז אתם רוצים ללמוד על לינוקס

אנחנו נמצאים בשנת 2018 וחדירת מערכת הלינוקס לחברות השונות נמצאת בעיצומה. כל סטארטאפ יודע מהיום הראשון שככל שמדובר בשרתים, הוא מהר מאוד יצטרך לעבוד על לינוקס. תחום מתודות ה-Devops והכלים שמשתמשים? סביר להניח שחלק גדול מהכלים יצטרכו שרת לינוקס לעבוד עליו. קונטיינרים? ב-Windows יש אבל זו בדיחה לא מצחיקה (שם זה בכלל VM) – אתם תצטרכו לינוקס להריץ את זה ואם אתם עובדים על עננים ציבוריים עם כלי אוטומציה, סביר להניח שהחיים יהיו יותר קלים עם טרמינל לינוקס (כן, מיקרוסופט משפרת את הקונסולות של ה-CMD וה-PowerShell אבל מספיק להריץ פקודת TOP ולהגדיל את החלון כדי לראות את הקונסולה Freak out ופתאום לא רואים כלום. במקרים כאלו פקודת reset תעזור, אגב).

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

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

אז קודם כל, הדבר הכי חשוב שצריך לזכור לגבי תחום הלינוקס – זה שהתחום מתפתח בקצב רצחני. אנשים לומדים עכשיו קונטיינרים על Docker ו-Kubernetes? הגיע הזמן שתכירו את ה"אח" שלו – cri-o. משתמשים בפתרונות של Docker ל-Enterprise? זה מת, תעברו ל-Kubernetes או OpenShift (תלוי בסביבה ובכל מיני פרמטרים).

בשביל להתחיל ללמוד לינוקס, מתחילים תמיד בבסיס, ומומלץ כמה שפחות להיות "תלוים" בממשק הגרפי, כי כשתגיעו לנהל שרתי לינוקס כלשהם, לא תמצא שם ממשק גרפי (ואם תתקין דבר כזה, בוא נאמר שצוות ה-IT לא יתפוס ממך כאיש לינוקס רציני), ולכן הדבר הראשון זה להכיר בצורה הכי קרובה את המסוף (Terminal). להכיר את מערכת הקבצים בלינוקס, להכיר הרשאות, פקודות, ואם אפשר – להכיר כמה הפצות לינוקס. אובונטו זה נחמד ודי פופולרי בענן, לא ממש פופולרי ב-Enterprise, שם RHEL (של רד-האט) או CentOS עדיין שולטים. הפצות לינוקס כמו Debian ו-Arch או Gentoo הן טובות – למי שרוצה להשקיע ממש לעומק בלינוקס.

אחרי שמכירים הרשאות קבצים ותיקיות, sudo, כדאי להכיר דברים כמו הפניות (redirection) כמו > | < שמאפשרות לקחת פלט מסוים ולהעביר אותו לפקודות/אפליקציות אחרות, כדאי להכיר גם פקודות המאפשרות לבצע מניפולציות לקבצים, פקודות כמו SED, AWK, GREP ועוד. יש כמובן לא מעט פקודות, ותמיד לכל פקודה ניתן למצוא את ה"מדריך" שלה עם פקודת man, כך שלדוגמא אם אין לי מושג ירקרק מה לכל הרוחות עושה awk, פקודת man awk תתן לך הסברים. חלק מה-manuals ארוכים מאוד ומפורטים מאוד (תסתכל על man awk כמה הוא ארוך!) וחלק מאוד קצרים וחיפוש בגוגל יוכל לעזור.

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

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

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

ברגע שאנחנו מכירים לא רע את שפת Python ו-BASH, מכירים פקודות פופולריות של לינוקס ואנחנו מרגישים די נוח עם הטרמינל, יהיה כדאי להכיר כלי אוטומציה, כלים אלו יעזרו לכם לבצע דברים שונים בשרתים אחרים כך שלא תצטרכו להמציא את הגלגל מחדש בכל פעם ולא תצטרכו להריץ פקודה 20 פעם רק כי יש לכם 20 שרתים שונים. כלי האוטומציה שאני ממליץ עליו הוא Ansible שמאפשר לעשות כמעט כל דבר תוך כתיבת Playbook (שזה בעצם ה"תסריט") בפורמט YAML ומודולים ב.. Python. יש גם כלים אחרים ואם אתם עובדים עם עננים ציבוריים, סביר להניח שימליצו לכם לעבוד על consul או עם terraform. כל חברה והעדפותיה, כך שאם אתם חושבים לעבוד בתפקיד "Devops", כדאי שתכירו גם את terraform ותלמדו איך להתחבר לעננים כמו AWS כדי לעשות דברים שונים דרך ה-API של אמזון לדוגמא. עוד תחום שכדאי ללמוד, הוא ניהול קוד (כן, גם לדברים הקטנים שלך) עם כלי כמו GIT. אתה יכול להרים לעצמך בבית לדוגמא את GOGS, מנהל GIT קטן וחמוד שיכול לעזור לך הרבה.

דבר נוסף שחשוב הם השרותים שנמצאים בלינוקס. תכירו את SystemD, תכירו כלי כמו TOP (למפונקים שביניכם – htop), תכירו איך לנהל דיסק עם Volume Management, ועוד ועוד. כל קורס טוב שמדריך לינוקס מסביר פחות או יותר על הדברים רק שחשוב לזכור: הקורסים מסבירים דברים בצורה בסיסית בלבד וה"חבר" הכי טוב שלך הם פקודת ה-man לפקודות השונות.

מכאן – הכל תלוי לאן אתם רוצים לקחת את ההכרות שלכם עם לינוקס. תכנות? תכירו את השפות והכלים, ויש מאלו המון. כך לדוגמא אם אתם רוצים ללמוד על Kernel, פיתוח דרייברים וכו', תצטרכו להכיר עמוק את ה-GNU Chaintools ואת GCC, את GDB כ-Debugger ואת ה-proc filesystem, ניהול זכרון, scheduling, ועוד ועוד. שפות כמו PHP? תכירו את השפה וערימות המודולים שלה ואת הדרך להטעין דינמית מודולים, וכו' וכו'.

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

מה קורה לתחום הסיסטם?

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

עד לפני מס' שנים, עוד לפני כניסת העננים לסצינה, תחום הסיסטם בחברות גדולות לדוגמא, היה די ברור: היו אנשי סיסטם מיקרוסופט, אנשי סיסטם לינוקס, אבטחת מידע היו אחראים על ה-Firewall ודברים אחרים שהיו קשורים לתחום, וצוות תקשורת שהיו אחראים על סוויצ'ים, כתובות IP, על VLAN וכל הדברים הקשורים לתקשורת, מרכזיות, WIFI וכו'.  אם היה צריך להתקין אפליקציות ושרתי אפליקציות (נניח Exchange, SharePoint ב-Windows, או MySQL/Oracle או שרת אפליקציות כמו Tomcat) – אז הצוות שאחראי על אותה מערכת הפעלה היה מתקין אותה והמשתמשים היו מוגדרים ברמת משתמש, לא ברמת Admin.

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

אם נסתכל בתחומים שאותו "איש Devops" צריך להכיר ולתפעל ולכתוב סקריפטים אליו (כן, הרבה פחות שימוש ב-GUI!) – אז הוא בעצם לוקח את תחום הסיסטם לינוקס הבסיסי, ומתרכז הרבה יותר בכלים שרצים על הלינוקס. זה מתחיל בניהול קוד, ממשיך לאוטומציה, סקריפטים, Python, JSON, YAML, ניהול חשבונות ומשאבים בענן כמובן, Jenkin/Travis/CircleCI וכו', והרשימה עוד ארוכה, תלוי בתחומים שהחברה עוסקת בהם, כלומר אם ניקח איש סיסטם לינוקס ממוצע שבחיים לא נגע ברוב הדברים שתיארתי לעיל חוץ מלינוקס, יש לו כיברת דרך ארוכה לעשות השלמות כדי להיות "איש Devops" מקצועי טוב. מה לגבי איש סיסטם מיקרוסופט? ובכן, רוב הכלים שתיארתי קיימים גם ל-Windows (היתרונות של קוד פתוח), אבל אחד הדברים הראשונים שהוא יצטרך להתרגל לרדת מהם, זה ה-GUI, לעבוד עם PowerShell באופן קבוע ומומלץ גם להכיר Python בדרך, ואז כמובן את הדברים שציינתי לעיל בתור התחלה.

אז מה, לכל אלו שההורים/סבתא/מענק שחרור מאפשר להם ללמוד סיסטם מיקרוסופט (MCSA) או לינוקס (RHCA, LPIC) – האם לוותר? בתחום מיקרוסופט לדעתי יש רוויה בשוק (ואשמח שהקוראים יתקנו אותי כי זה לא התחום שלי), בתחום הלינוקס לעומת זאת – יש דרישה, אבל בשתיהם מצפים שהמועמד ידע הרבה יותר ממה שהקורס מספק (ולא, קורס המשך כמו MCSE או RHCE לא יעזרו הרבה, מצפים יותר לידע שמגיע מתוך שימוש ונסיון, לא שתדקלם כמו תוכי). אם לדוגמא תפנה לסטארטאפים, אז הדבר האחרון שהם מחפשים – זה איש סיסטם (אני יודע כי אחרי 7 שנים של להיות פרילאנסר, קיבלתי סך הכל פעמיים בקשה לשרותי סיסטם או בקשות ל"שידוך" איש סיסטם שכיר ע"י חברות סטארטאפ).

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

  • איך אתה מתקן תקלה X ואיך אתה מבצע זאת להבא באופן אוטומטי?
  • איך אתה פותר בעיות ניהול קוד, קונפליקטים, branching, Stash ועוד ועוד דברים שלא לומדים בשום חלק באיזה קורס סיסטם?
  • איך אתה יוצר חבילות מוצר של החברה באופן אוטומטי? איך אתה בונה "צינורות" (Pipe lines) שכוללים לוגיקות שונות?
  • איך אתה מרים ומנהל קונטיינרים? סטורג' לקונטיינרים? Load balance שלהם? פותח כניסה "מבחוץ" ועוד דברים שקשורים לסביבות פיתוח וייצור?
  • והרשימה עוד ארוכה.

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