כשה-"Raspberry Pi" ינצח בקרב התודעה

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

לכאורה, צה"ל ניצח, אבל אפשר לאמר שזהו הנצחון הכי בזבזני שיש..

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

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

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

מה שלעניות דעתי צה"ל צריך להתעניין – הוא פתרונות המבוססים על COTS (כלומר Commercial off-the-shelf – חלקים שניתן לרכוש בשוק). כשמנסים להפיל מל"ט של חיבזאללה  – אין צורך בדרישות כמו "עבודה בכל מזג אוויר" (בכל זאת – אם יש ערפל, או חושך או תנאי ראיה גרועים, גם הצד השני לא יכול לראות כלום, אחרי הכל – לא מדובר במלט"ים של רפא"ל), צריך למצוא פתרון שיכול לשבת על מל"ט קטן ופשוט. לדוגמא: לירות תרסיס דבק פשוט על כנפי מל"ט אויב. עם ספריות פיתוח כמו OpenCV וארכיטקטורת NEON שנמצאת כמעט בכל מעבד ARM, הלוח הנוסף שיורכב למל"ט הישראלי יוכל למצוא את הזווית הנכונה ולרסס בעצמו (או לעשות כל פעילות אחרת שתיבחר) ללא צורך בכך שמישהו יכוון אותו במדויק מחדר בקרה, וישנם עוד מקרים רבים, בהם שילוב של AI שקיים במעבדים (גם מעבדים זולים!) יכול לעזור בהקמת פתרונות לחימה זולים ואמינים. בונוס: אפשר לקבל בחזרה את המל"ט הצהל"י ולהשתמש בו שוב ושוב.

השאלה היא – האם בצה"ל ירימו את הכפפה? בטוחני ששימוש ב-AI קיים כבר בצה"ל ובכלים שונים, השאלה אם יבינו בצה"ל שאפשר גם להשתמש ב-AI להוזיל בצורה משמעותית מאוד פתרונות שנועדו להילחם בכלים זולים כמו מלט"ים. הגיעו הזמן שמישהו בצה"ל יבין שבעלות שעה אחת של F16, אפשר לקנות 2 מכולות של מלט"ים מדגמים טובים של DJI לדוגמא (וזה לפני הנחת כמות), והגיע הזמן לפתרונות פרופורציונאליים.

האם NVIDIA פתחה את הקוד לדרייבר ה-GPU שלה?

החדשות שהופיעו באתרים שונים (לדוגמא: Phoronix) לפיו חברת NVIDIA החליטה לפתוח את קוד המקור של הדרייברים לכרטיסי ה-GPU שלהם – גרמו ללא מעט אנשים לחייך ואולי לאמר "ניצחנו", חברת NVIDIA נכנעה ופתחה את הקוד לדרייברים שלה!

אז זהו. שלא.

הדבר הראשון שכדאי להבין – זו הסיבה מדוע NVIDIA התעקשה להשאיר את הדרייברים כקוד סגור, והסיבה לכך קשורה להיסטוריה: NVIDIA קנתה חברות שונות והשתמשת בקניין הרוחני. בנוסף, NVIDIA חתמה על הסכמי רישוי שונים כולל השכרת פטנטים מחברות כמו S3, IBM וכו' הקשורים למימוש פונקציות שונות בדרייברים, והסכמים אלו אסרו על NVIDIA לפתוח את הקוד לחלקים אלו, כך של-NVIDIA לא נותרה ברירה ודרייברים ל-GPU ביתיים ומקצועיים – נשארו סגורים. לעומת זאת, בכל הקשור לציוד משובץ (Embedded) – ב-NVIDIA (עם דרייברים ל-Tegra, ה-GPU למערכות משובצות שלהם) התחילו הכל מאפס, כך שהם יכלו מהרגע הראשון לפתוח את הקוד לדרייברים, ואכן הדרייברים הללו נמצאים בחלקים השונים בלינוקס, כמו ב-Kernel, ב-Mesa ובמקומות אחרים.

אז מה בעצם השוני הגדול הפעם?

מה שקורה, הוא ש-NVIDIA פיתחה מיקרו מעבד חדש מבוסס RISC-V שנמצא בתוך ה-GPU (זה נקרא GSP) ואותו מעבד מבצע את מה שהדרייברים הקודמים עשו עם ה-CPU במחשב, במהלך איתחול ה-GPU כשה-OS עולה, רק שעכשיו הכל נעשה עם ה-GSP, באופן עקרוני:

  1. הדרייבר ב-Kernel מאתחל את ה-GPU ואת ה-GSP (ללא האיתחול, הדברים היחידים שאפשר לעשות עם ה-GPU זה בחירת מצב טקסטואלי ממה שנתמך דרך VESA, ומצב Frame Buffer mode, אם בא לך לשנן מחדש את קטלוג הקללות שאתה יודע..).
  2. הדרייבר מעלה קושחה סגורה ומוצפנת וה-GSP "לוקח פיקוד"
  3. בסיום, הכרטיס מודיע ל-Kernel לגבי מהות הציוד, כניסות, יציאות, פונקציות אפשריות, יכולות וכו'
  4. לאחר שהמודול הופעל בהצלחה, חלקים אחרים (User space) מתחילים לפעול מול המודול בזכרון

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

האם זה אומר שממחר בבוקר הדרייבר הפתוח הוא המענה החדש של NVIDIA? לא ממש. הדרייבר החדש הוא רק בראשית דרכו, יש לו עוד דרך חתחתים לעבור (והפעם כל יצרני הפצות לינוקס משתתפים בבניה ושילוב הדרייבר והכנת חבילות התקנה), כך שלבינתיים ממשיכים לעבוד עם הדרייברים הבינאריים הרגילים. בנוסף, ה-GSP בגירסה החדשה קיים רק בכרטיסים מבוססי Turing. שאר הכרטיסים הישנים יותר – ממשיכים לקבל תמיכה רק דרך הדרייברים הבינאריים הרגילים.

אז האם NVIDIA "ראתה את האור" בכך שהיא פותחת דרייבר חדש בקוד פתוח? רחוק מכך. אם תרצה לקודד וידאו, אם תרצה להעלות מהירות שעון של ה-GPU ואם תרצה להריץ קוד המצריך CUDA או OpenGL או דברים אחרים – תצטרך לעבוד מול החלקים האחרים (User Space) ש-NVIDIA משחררת כקוד סגור בלבד, ובשלב זה לא נראה ש-NVIDIA הולכת לפתוח את הקוד הזה.

ועוד משהו קטן לגבי המתחרה הגדולה של NVIDIA – חברת AMD. האם גרסאות הדרייברים בקוד פתוח שלהם נותנים בעצם יותר מעצם העובדה שהם פתוחים? לא תמיד. ב-AMD פשוט מחביאים את הפונקציות העיקריות והחשובות – בתוך קושחה בינארית מוצפנת. כמו ב-NVIDIA, רק שב-AMD החלקים הקשורים ל-User space – פתוחים. אגב, גם במקרה של אינטל, הדברים זהים למה ש-AMD מבצעים (אם כי גם שם יש חלקים סגורים, היי Intel Media SDK), ויש גם קוד חופף ל-AMD ואינטל בחלקים כמו Mesa וכו'.

לסיכום: NVIDIA מעולם לא חיפשה לעשות "דווקא" ולא היתה "אנטי קוד פתוח". אין שום כיף בכך שצריך לתחזק דרייבר משותף לכל מערכות ההפעלה, להכין קבצים בינאריים ולוודא שוב ושוב ששום דבר לא תוקע את ה-OS עקב באגים בדרייבר (ב-NVIDIA זוכרים את הלקח הכואב הזה בצורה חזקה מ-Windows Vista). אני מאמין שהם יפתחו לאט לאט גם את החלקים האחרים, אבל בכל מקרה, צריך לתת מחמאות ולעודד חברות שמחליטות לפתוח את הקוד לחלקים שונים (ולא מסתכלות על קוד פתוח כ"בית קברות" לפרויקטים שלא יתוחזקו לעולם).

על לאפטופים,חיישנים של אינטל – ולינוקס

שוק הלאפטופים בעולם נשלט על ידי אינטל ועל ידי מספר יצרנים שמכניסים בשמחה כל פיתוח חדש לתוך הלאפטופים על מנת לתת למשתמש חוויית שימושיות טובה. כך, לדוגמא, בלאפטופים שיצאו בשנה הקרובה תהיה חיבוריות Thunderbolt (המאפשרת חיבור ציוד חיצוני שדורש רוחב פס גבוה – כמו כרטיסי GPU, כרטיסי SSD NVME מהירים ועוד) הואיל ואינטל משלבת במעבדים החדשים שלה למחשבים ניידים (דור 10) את ה-Thunderbolt.

אבל לפעמים, עם כל שילובי הטכנולוגיה, יש בעיה בקשר לתמיכת הציוד במערכות הפעלה אלטרנטיביות כמו הפצות לינוקס שונות. אינטל, כיצרנית מעבד ו-Chipset עושה מאמצים כדי לתמוך בלינוקס ובדרך כלל מחשב נייד חדש ומודרני, כשיתקינו עליו הפצת לינוקס כמו גירסת Fedora או אובונטו אחרונים – רוב הציוד יתמך ישר מהקופסא. בדרך כלל הציוד שלא יתמך – הוא הציוד שיצרן הלאפטופ הוסיף ללוח האם של אותו מחשב נייד. כך לדוגמא יש בעייתיות תמיכה בחלק מקוראי טביעות אצבע או מצלמות אינפרה-אדום (מצלמות ה-Windows Hello). בדרך כלל יהיו כאלו מקהילת מפתחי הלינוקס שיוסיפו תמיכה, אבל לוקח זמן עד שזה נכנס להפצות הלינוקס בגרסאות השונות.

אחת הטכנולוגיות שאינטל הוסיפה בשנתיים פלוס האחרונות היא טכנולוגיות ה-Dynamic Power & Thermal Framework (או DPTF בקיצור). עם טכנולוגיה זו, אינטל משלבת חיישנים בתוך השבבים שלה שידעו לגלות באיזה מצב המחשב הנייד נמצא: האם הוא על השולחן (מצב Desk) או שהוא נמצא על הברכיים שלך (מצב Lap). אם אתה עובד על המחשב הנייד והוא נמצא על ברכיך, המחשב הנייד יוריד את ביצועי המעבד באופן משמעותי כך שבתקרת הביצועים צריכת החשמל של המעבד תהיה 15 וואט. אם הוא על השולחן, המעבד יוכל לרוץ עד מקסימום ביצועים ויצרוך מקסימלית 51 וואט (הכל כמובן בהתאם לקירור ולאיך שהיצרן בנה את הלאפטופ. בחלק מהלאפטופים אם המעבד יעבוד במקסימום מהירות – אתה תשמע רעש חזק מהמאווררים). הנה תמונה שאולי תעזור להבהיר את המצב:

הבעיה עם DPTF פשוטה: אינטל ישמה את הפתרון בלינוקס, אבל רק לכרומבוקים, וגם אז רק לחלק מהמעבדים הישנים (דור 7 וחלק מ-8). כיום בלינוקס – ה-DPTF כלל לא נתמך בלינוקס. בחלק מהמחשבים הניידים ניתן לבטל את פונקציית ה-DPTF, אבל במחשבים של לנובו לדוגמא – אי אפשר לבטל את המצב, כך שהמהירות המקסימלית שהמעבד במחשב ירוץ תהיה בסביבות ה-1.0-2.0 ג'יגהרץ, רחוק מאוד ממהירות ה-4.2-4.3 ג'יגהרץ (תלוי במחשב הנייד ובמעבד) שהמעבד יכול להגיע. לנובו הודיעה ש"בעתיד" היא תוציא קושחה ללינוקס שתאפשר ביטול DPTF, אבל בשלב זה, אם יש לך מחשב נייד מהסדרות כמו Yoga או Thinkpad, יש מצב שתקבל רק חצי או שליש מכח העיבוד אם אתה מריץ לינוקס על הלאפטופ. ב-Windows, אגב, הכל רץ בצורה תקינה.

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

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

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

על Windows ומעבדים מעל 16 ליבות

בשנים האחרונות אנחנו רואים יותר ויותר מעבדים חדשים מ-AMD עם יותר ויותר ליבות במחירים מאוד מפתיעים, הן לתחנות עבודה והן לשרתים. להלן 2 דוגמאות:

  • מעבד AMD Threadripper 2990WX עם 32 ליבות ו-64 נימים עולה 1700$ (מיועד לתחנות עבודה)
  • מעבד AMD EPYC 7551P עם 32 ליבות ו-64 נימים עולה $2700 (מיועד לשרתים בעלי תושבת מעבד יחידה)

לשם השוואה: המעבד לתחנות עבודה ושרתים הכי זול עם 16 ליבות מאינטל (Xeon SP Gold 6130) עולה נכון להיום $1932. ההצעה הזולה ביותר מעל 16 ליבות של אינטל היא מעבד Xeon Gold 6140 וכיום מחירה הוא $2500, כך שבמחיר של מעבד אחד מאינטל אפשר לקנות מעבד עם כמות כפולה של ליבות לתחנות עבודה, ובתוספת של 200$ אפשר לרכוש מעבד לשרת עם כמות כפולה של ליבות (בהשוואה ל-6140 של אינטל).

אם נרצה להקים מכונה כזו להריץ מכונות וירטואליות, לא חשוב איזה פתרון וירטואליזציה נבחר (למעט Hyper-V) – המעבדים של AMD יתנו תוצאות מצוינות וסקירות שונות הראו זאת. אם נרצה להשתמש במעבדים כאלו כתחנות עבודה מבוססות לינוקס, כל עוד יש לנו את העדכונים האחרונים להפצת הלינוקס שנבחר – הכל ירוץ מצוין.

אך מה יקרה אם נרצה לקנות מכונה כזו להריץ אותה כתחנת עבודה או כשרת Windows (לא וירטואלי)? צפו לביצועים נמוכים ב-30-50% בהשוואה ללינוקס עם אותם מעבדים.

כשאינטל שחררה את משפחת Xeon SP, אינטל הציגה בגאווה כמה המעבדים לשרתים (אז לא היה Threadripper) שלה הרבה יותר מהירים ממעבדי EPYC של AMD. סקירות עצמאיות הוכיחו שאינטל פחות או יותר צודקת (יש מספר מבחנים די תמוהים של אינטל ועל כך הופיע פוסט ב-Anandtech). רוב הסוקרים ציינו כי הבעיה של הביצועים קשורה לארכיטקטורת ה-NUMA של AMD.

שנתיים חלפו מאז ש-AMD הוציאה את משפחת מעבדי EPYC לשרתים. AMD הוציאה באותו זמן את משפחת ה-Threadripper דור ראשון (עד 16 ליבות) ואת משפחת ה-Threadripper דור שני (מבוסס על ארכיטקטורת +ZEN). עם הדור השני, AMD הוציאה את המעבדים 2970WX ואת 2990WX -האחד עם 24 ליבות והשני עם 32 ליבות. ההבדל בין מעבדים אלו לבין המעבדים ממשפחת EPYC – היא שמעבדי Threadripper משתמשים ב-4 ערוצי זכרון ולחלק מהליבות אין גישה ישירה לזכרון, בשעה שמעבדי EPYC מקבלים גישה ל-8 ערוצי זכרון.

המחיר הזול גרם ללא מעט אנשים להתעניין לראשונה במעבדים עם 24 ו-32 ליבות ולא מעט אנשים רכשו אותם. המעבדים עובדים מצוין אולם מי שבחן אותם על Windows קיבל "הפתעה" – גם כאן, Windows הציג ביצועים נמוכים ב-30-50% בהשוואה ללינוקס (הבעיה אינה קיימת בדגמים כמו 2950X שהם עם 16 ליבות).

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

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

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

אחד הדברים שוונדל מזכיר בוידאו זה אפליקציה בשם Coreprio שעוזרת למגר חלק מהבעיה. ב-Phoronix מנהל האתר בדק כמה זה עוזר. התוצאה: בחלק מהמקרים זה עוזר במעט, בחלק הרבה, אבל עדיין – ישנה בעיה שמצריכה שינוי קוד פנימי ב-Windows ע"י מיקרוסופט.

לכאורה ניתן להחליט משהו פשוט: לא רוכשים מעבדים של AMD אם מריצים Windows כמערכת הפעלה מרכזית "על הברזל", ואני יכול בהחלט להבין החלטה כזו, אולם הבעיה המרכזית אינה רק במעבדים של AMD. גם אינטל הולכים להוציא מעבדים חדשים עם אותה ארכיטקטורה כמו של AMD (הם יתחילו להופיע תחת משפחת Cascade Lake שתצא השנה). הבעיה היותר גדולה שקיימת בצד של מיקרוסופט היא תמיכה במעבדים מעל 16 ליבות ולא חשוב מי היצרן (גם אינטל). הסיבה שאף אחד לא התלונן עד כה? אף חברה שרוכשת שרת עם מעבדים מעל 16 ליבות לא מריצה ישירות Windows "על הברזל". עם Scheduler יותר טוב, גם מעבדים של אינטל ירוויחו מכך.

לסיכום: אין מנוס מלציין משהו פשוט. מיקרוסופט נרדמה בעמידה. מיקרוסופט עם Windows 2019 בהחלט מעוניינת שתריצו Kubernetes וקונטיינרים, אבל אם נסתכל לדוגמא במבחנים של Phoronix על מכונה עם 40 ליבות שמריצה Windows Server בגרסאות שונות ("על הברזל") מול הפצות לינוקס שונות – לינוקס ברוב המקרים פשוט "בועט" ב-Windows, גם כשלא מדובר כלל במעבדים של AMD. מישהו שם צריך להתעורר.

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

מישהו אתמול פתח בפורום 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.