התקלה של Crowdstrike ומשהו שהכנתי

כמו שכבר כולם יודעים, עדכון של Falcon Sensor מבית Crowdstrike הצליח לגרום למכונות Windows שקיבלו את העדכון – לקרוס לחלוטין (BSOD). התיקון שהחברה מציעה – הוא למחוק איזה קובץ ולבצע Reboot

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

ממש "כיף"

ולכן, החלטתי להכין קובץ ISO לינוקס  מקוסטם קלות (מבוסס Debian Bookworm) שיעשה את העבודה, וכל מה שצריך לעשות זה לבצע את ההוראות הבאות:

  1. יש להוריד את קובץ ה-ISO מכאן (זה הגוגל דרייב שלי, אם גוגל מחליט לחסום עקב פופולריות יתר, צרו איתי קשר ואני אארח את הקובץ במקום אחר)
  2. מכיוון שמדובר בקובץ ISO, אפשר להתקין אותו על דיסק און קי (עם RUFUS לדוגמא ב-Windows או Media Writer בלינוקס), או להוסיף אותו לדיסק Ventoy
  3. ה-ISO תומך גם BIOS וגם UEFI, וניסיתי לתמוך גם ב-Secure Boot ולבדוק זאת, אך אין לי אפשרות לבדוק זאת על כל חומרה וכל פיפס של אבטחת Boot, כך שאם המערכת מתחילה לדבר על Secure Boot – תבטלו זמנית את ה-Secure Boot.
  4. ברוב המחשבים אין אפשרות להפעיל דיסק און קי מ-USB מיידית, ולכן יש להיכנס ל-BIOS/UEFI ולבחור את ה-USB כ-Boot Device ראשי
  5. אין תמיכה ב-Bit Locker. במכונות כאלו תצטרכו לעשות את הניקוי ידנית
  6. המערכת בנויה לסביבות וירטואליות ופיזיות שכוללות דיסק יחיד.

לאחר ששיניתם ב-BIOS וביצעתם BOOT – תקבלו מסך גרפי של DEBIAN. כל מה שצריך לעשות – זה ללחוץ Enter. מערכת הלינוקס תתחיל לעלות ובסיום אתם תהיו בתוך הלינוקס ללא הקשת שם משתמש וסיסמא

על מנת להפעיל את הניקוי, יש להריץ את הפקודה sudo cs-fix.sh

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

לאחר שהסקריפט רץ – הוא יוצא החוצה. מכאן, כל מה שיש לעשות זה לכבות את המחשב (לא עם פקודות Poweroff או Shutdown, אלא ממש כיבוי פיזי או ביצוע STOP אם מדובר במכונת VM), לנתק את הדיסק און קי ולבצע Boot. המערכת אמורה לעבוד בצורה נורמלית

כמה הערות:

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

תהנו 🙂

מעבדי דור 13 ו-14 (סידרת K) של אינטל – והתקלות

לפני מס' חודשים שחררתי קליפ לגבי הבעיות שיש עם מעבדי אינטל דור 13 ו-14, ספציפית בדגמים ה-Unlocked (דגמים K, KS, KF) ובעיות החומרה שיש איתם (אתם כמובן מוזמנים לעשות Subscribe לערוץ 🙂 ).

כפי שציינתי בקליפ, הבעיה תוארה כבעיה שנגרמה כתוצאה מהגדרות של יצרני לוחות האם, הגדרות שגרמו למעבד לקבל יותר מדי מתח ולפעילות מעבר למפרטים שאינטל אישרה רשמית (לאינטל כמובן לא היתה בעיה עם ההגדרות שהיצרנים הכניסו – עד שהחלו לצוץ הבעיות) – מה שגרם למה שנקרא בעגה המקצועית Silicon Degradation.

הפתרון המוצע היה פשוט: עדכנו את ה-BIOS של המערכת שלכם, ודאו שאינכם משתוללים עם Overclocking ושאתם רצים בהגדרות קרובות לברירת המחדל של ה-BIOS (כן, אתם תפסידו מהירות) – והכל יהיה בסדר…

אז זהו. שלא. הבעיה רק הלכה והחמירה וצצה גם מכיוון שונה.

למי שאינו יודע, חברות Hosting רבות משתמשות במעבדים אלו (שמיועדים במקור ל-Desktop ולתחנות עבודה בקצה התחתון) כמוצר להשכרה עבור חברות שמעוניינות להריץ שרתי משחקים, מכונות להשכרה אישית (לדוגמא: תחנות פיזיות לשימושים כמו עריכת וידאו והרצת ישומים אחרים ללא שימוש בוירטואליזציה). חברות אלו אינן משתמשות בלוחות אם רגילים אלא לוחות אם שמיועדות בראש ובראשונה לתחנות עבודה, והן כוללות Chipset מסוג W680 שנבנים בראש ובראשונה עבור מערכות יציבות שירוצו 24X7. אותן חברות Hosting רוכשות את הלוחות הללו מיצרנים כמו ASRock Rack, SuperMicro ו-ASUS. כל היצרנים הללו כוללים חלקים למערכת יציבה המאפשרת גם שליטה מרחוק.

בחודשים האחרונים, גם  החברות הללו החלו למצוא כי ישנן בעיות עם המעבדים הנ"ל, והן מצאו את עצמן מחליפות מעבדים ללקוחות על ימין ועל שמאל, עד שזה הגיע למצב שאם לקוח מעוניין לשכור שרת לתקופה והשרת כולל מעבדים מסידרת K/KS/KF מדור 13 או 14 – הן היו מוסיפות כ-1000 דולר (בערך) תוספת למחיר עבור כל המאמץ העתידי והבעיות שהן תצטרכנה להתמודד בעתיד. אותם 1000 דולר תוספת במחיר – לא מופיעה בהצעות עם מעבדים מהמתחרים של AMD – ה-Ryzen 7XXX. לקוחות שתהו מה ניתן לעשות בכדי לא לשלם ולא להיגרר לבעיות יציבות – קיבלו המלצה מהחברות לבחור מערכות מבוססות Ryzen.

אינטל הודיעה בעבר כי היא מכבדת את האחריות על המעבדים ולקוחות שחווים בעיות, יוכלו להחליף את המעבדים בתהליך RMA. הבעיה: לאחרונה צצות בעיות באותן מערכות (עם המעבדים הנ"ל) בהן המערכות לא מוכנות לעבוד עם SSD במצב PCIe Gen 5 והלקוח יאלץ לעבור ל-PCIe Gen 4 (גם אם ה-SSD הוא דור 5), ולקוחות שדיווחו על כך לאינטל וביקשו להחליף את המעבד בתהליך RMA – קיבלו הודעה מאינטל שבמקרים אלו ה-RMA יסורב.

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

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

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

אם אתם חושבים לרכוש מערכת חדשה, לא מומלץ לרכוש את אחד מהמעבדים הנ"ל ובהתאם להעדפותיכם, תוכלו לרכוש עתה לוחות מבוססות Ryzen או להמתין לסוף השנה למעבדי אינטל החדשים (סידרת Arrow Lake S).

על גניבת הרשאות ואותנטיקציות של מיקרוסופט

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

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

גופים רבים עדיין משתמשים בשיטות כמו 2FA שאמנם ימנעו (בחלק מהמקרים) את  העברת פרטי האותנטיקציה של שם משתמש/סיסמא, אולם הדבר אינו יעזור כשיש לגנב את ה-Session Cookies, כנ"ל במקרים משתמשים ב-Microsoft Authenticator בשיטת ה-Passworldless (שימו לב – Passworldless ו-Passkeys הם דברים שונים לחלוטין) שבהם הגנב עדיין מקבל, שוב, את ה-Session Cookies ויכול להתחזות בהצלחה למשתמש הלגיטימי ולגנוב או לגרום נזקים.

בן, מערוץ Syn/Ack Time הכין קליפ קצר (7 וחצי דקות) שמדגים בעזרת כלי כמו Evilginx על מנת להתחזות לאתר מיקרוסופט והוא מדגים שימוש בשיטות אותנטיקציה שונות, וכיצד הוא מצליח לקבל את פרטי כניסת המשתמש ואת ה-Session Cookies. להלן הקליפ:

אם צפיתם בקליפ, אתם יכולים להבין את הדברים הבאים:

  • שימוש ב-Yubikey (או פתרון חומרתי אחר שתומך ב-FIOD2) עדיין נותן את הפתרון הכי חזק, תוך תמיכה בכל פלטפורמה (Windows, Mac, Linux) ובכל דפדפן, ואם בארגון מחליטים להשתמש ב-Microsoft Authenticator – זהו הפתרון היחיד שהוא מספיק חזק ויכול לתמוך בכל המשתמשים, כולל אלו שאין ברשותם מכשירי טלפון חכמים.
  • תמיכה ב-Passkeys של מיקרוסופט היא בעייתית לארגונים גדולים, הואיל והיא דורשת את גירסת האנדרואיד האחרונה או גירסת IOS האחרונה (גירסה 17, נכון לרגעים אלו), דבר שלא קיים בטלפונים רבים ישנים יותר. Google passkey שבנוי לתוך הדפדפן והטלפונים, דורש אנדרואיד גירסה 9 או IOS גירסה 16, דבר שקיים בד"כ ברוב הטלפונים כיום.

אסכם את הדברים כך: הגיע הזמן להיפתר מ-2FA ולעבור לשימוש ב-passkey (או לפחות במפתחות חומרה כמו Yubikey). בשיטות אלו, טריקים של SMS ו"חטיפת" מכשיר הסלולר לאישור אותנטיקציה לא יעזרו (יש צורך בקירבה פיזית למחשב, passkey משתמש ב-Bluetooth ו-Yubikey מצריך חיבור USB), וגם אם הקורבן הכניס את שם המשתמש והסיסמא שלו, הפורץ לא יוכל "לדוג" אותם, ובמקרים של שימוש ב-passkey, יהיה אפשר לוותר על תוכנת Authenticator (הגירסה של גוגל מסתמכת אותנטיקציה לכניסה לטלפון ואינה מצריכה אותנטיקציה מחודשת על מנת ליצור מספרים חדשים, בניגוד לגירסה של Yubikey לדוגמא).

הטעות הגדולה של רד-האט

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

השינוי עצמו, אגב, אינו חל על גירסת ה-Upstream (מה שיהיה בעצם גירסת ה-RHEL החדשה בעתד), אך זה כמובן לא מסייע למי שיש מערכות RHEL או מבוססות חיקויי/fork של RHEL.

על מנת להבין מדוע השינוי הוא כה קריטי, צריך לזכור משהו אחד חשוב: רד-האט נחשבת הפצה יציבה ואיכותית, והיא משמשת אצל ארגונים רבים כ-Gold Standard (הרבה יותר מאשר כל הפצה אחרת, כולל אובונטו או סוזה). מכיוון ש-רד-האט שחררו את הקוד והשינויים המתמשכים לציבור, קמו להן מספר קהילות שהוציאו הפצות "תואמות RHEL" כמו Rocky Linux, AlmaLinux וכמובן – Oracle Linux שעמדו בתנאים של רד-האט (אפשר להשתמש בקוד, כל עוד השם Red Hat או לוגו או כל סימן רשום של רד-האט אינו נכלל) והן בנו את ההפצה מחדש, כאשר ישנה 100% תאימות בינארית ל-RHEL.

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

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

מה שאי אפשר להבין, מדוע הצעד ננקט בצורה כזו הזויה?

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

  • הכרזת העניין בצורה רשמית (ולא סיבובית/ספין) ופרסום מועד יותר מאוחר שבו ההחלטה תופעל. נניח – 6 חודשים.
  • הכנה ופרסום תוכנית שיווקית לארגונים שירצו לעבור להשתמש ב-RHEL באופן רשמי: מתן הנחות, פרסום הוראות הגירה, וכו' וכו'

כיום, רד-האט לא נוקטת אף אחד מהצעדים. החברה אמנם מציעה (ללא קשר להודעה) עד 16 רשיונות בחינם, אולם יש תנאי לכך: הרשיונות הם עבור מפתחים/פיתוח בלבד.

אז מה ניתן לעשות?

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

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

לקצר דרכים – ולסבול מאוחר יותר

כיועצת עצמאית, יוצא לי במקרים רבים לתת יעוץ לגבי תשתיות קיימות בענן או On Prem או במעבר מתשתיות מקומיות לעננים ציבוריים. לשמחתי אני יכולה לאמר ממה שראיתי – זה שחברות רבות נוהגות בתבונה ולא מעבירות בצורה מיידית את כל התשתיות שלהן מ-On Prem לענן אלא בצורה מדורגת, וגם אז – רק מה שצריך.

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

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

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

אחד הנזקים, לדוגמא, קשור לשדרוג. אם מישהו הקים מערכת Kubernetes והוא ינסה לשדרג אותה – סביר להניח שהוא יתקל במספר שגיאות, שאם הוא לא מבין בתחזוקה והקמת הפלטפורמה, יכולים פשוט להשבית לו את המערכת, וכנ"ל לגבי הרצה של כל מיני קונטיינרים חיצוניים תוך שימוש בקבצי YAML שאיש מהחברה לא עבר עליהם: צריך לזכור שקוברנטיס לא שואל יותר מדי שאלות לפני הטמעה של קבצים כאלו (kubectl apply -f something.yaml).

ולכן, ההמלצה שלי לכל איש IT – כשזה מגיע ללינוקס, כשזה מגיע לקוברנטיס או כל פלטפורמה אחרת – אם צריך להקים מערכת פרודקשן/טסטים/פיתוח, לא מומלץ להשתמש בסקריפטים האוטומטיים או קיצורי דרך אחרים להקים את הדברים (שוב, למעט POC) – אלא להשקיע וללמוד איך עובדת הקמת הפלטפורמה, התלויות והתשתיות הנצרכות. נכון, זה לוקח יותר זמן ואין תמיד חשק ללמוד כל פיפס, אך לימוד הזה זו השקעה שמחזירה את עצמה כשיש תקלה, או מאוחר יותר אם מחפשים מקום עבודה אחר – ובראיון (ובקורות החיים) ניתן לציין שאתם מכירים הכרות די עמוקה את פלטפורמה X או Y. זיכרו: הדבר האחרון שאתם רוצים זה מערכת שהקמתם במהירות, כולם בנו ובונים עליה ולפתע היא קורסת ואין איש שמכיר אותה. כולם יצפו ממך לפתור זאת ובמהירות.

חג שמח.

המעבר ל-DPU

(הערת Off topic: פוסט זה ופוסטים בעתיד יכתבו בלשון נקבה. מדוע? הפרטים נמצאים כאן)

עולם הוירטואליזציה קיים כבר יותר מ-20 שנה, והפתרונות עברו מספר "סבבים" של שינויים מהותיים בפתרונות, להלן פירוט (ברשותכם, אינני מתכוונת להיכנס לפרטים של רמת Hypervisor וכו' שגם הם השתנו, אך הדבר אינו רלוונטי לפוסט זה):

  • סיבוב ראשון – פתרונות כמו ESX/ESXI ופתרונות וירטואליזציה של מתחרים התמקדו בכך שישנם חלקים פיזיים שונים שמרכיבים את פתרון הוירטואליזציה: יש פתרון אחסון יעודי, יש מתגים ונתבים, יש חומת אש יעודית ועוד מספר "ברזלים" שנותנים שרותים משלימים – ויש את כל שרותי ה-Compute שמתקבלים מהשרתים. כל דבר – בנפרד.
  • סיבוב שני – קונסולידציה – פתרונות כמו vSAN של VMware ופתרונות מתחרים – מעבירים את השרותים המשלימים ל-Compute – אל תוך ה-Nodes עצמם. אחסון? הכנס דיסקים ונקים. רשת? יש NSX ופתרונות אחרים שייתרו פתרונות "ברזלים" יעודיים לטובת פתרון וירטואלי, כך שבסופו של יום, מערכת כזו תהיה בנויה משרתים עם דיסקים, כרטיסי רשת ומספר מתגים פשוטים ותו לא. הכל מוקם, מוגדר ומתוחזק בתוך פתרון הוירטואליזציה.

הסיבוב הנוסף הוא בעצם "חצי סיבוב". השינוי העיקרי הפעם הוא שאנחנו מוציאים החוצה מעבודת המעבד כל מה שקשור לאבטחה, תעבורת רשת, אחסון, הצפנה וכו' – ואנחנו מעבירים את הכל לדבר שנקרא SmartNIC (או כפי ש-NVIDIA ו-AMD ואחרים רוצים שתקראו לזה: DPU. אינטל רוצים שתקראו לזה: IPU).

להלן תרשים שיפשט את הדברים:

(קרדיט: The Next Platform)

כפי שאנו רואים, ה-DPU (מצד שמאל למטה בתרשים לעיל) הוא זה שיריץ את שרותי ה-ESXI וכל שרותי ה-Management (לשם כך ה-DPU מכיל מעבד ARM עם מספר ליבות וזכרון) והשרת עצמו יריץ מערכת מינימלית שמכילה Hypervisor או כל מערכת הפעלה יעודית "על הברזל" – והמערכת תתממשק  אל ה-DPU, כך שה-DPU בעצם ינהל את השרת והשרותים.

מדוע בעצם עושים זאת? הסיבה לכך די פשוטה: אין זה משנה איזה מעבד X86-64 קיים לך בשרת, בין אם מדובר ב-Xeon של אינטל או ב-EPYC של AMD, המעבדים הללו טובים בדברים מסויימים כמו Compute, אך פחות טובים בכל מה שקשור לתקשורת, הצפנות, תעבורת רשת גבוהה, אחסון ברמה ובביצועים של SAN וכו', ודברים אלו יכולים להתבצע ביעילות עם שבבים יעודיים (ASIC או FPGA, תלוי ביצרן, בפתרון וכו') ולשם גם VMWare וגם היצרניות האחרות (חוץ מ-AMD, אינטל ו-NVIDIA, גם חברות אחרות מתכוונות להציע DPU משלהן, כמו Marvell, ברודקום וכו') רוצות להיכנס, ובמילים אחרות – מה שהיה פרויקט Project Monterey בעבר, עכשיו זה חלק אינטגרלי מ-vSphere 8 שיוצא.

מאיפה בעצם הגיע הרעיון לכך? התשובה די פשוטה: ספקי ענן ציבורי, ובמיוחד AWS. רוב השרתים ב-AWS (הסתכלו לדוגמא על AWS Nitro) כוללים בעצם מערכת שמכילה KVM לינוקסי מינימלי שמריץ רק מכונות וירטואליות, וכל שאר השרותים מתקבלים דרך כרטיסי PCIe Express בעלי שבבים יעודיים (דוגמת Pensando של AMD) שנותנים שרותים יעודיים כמו אחסון, תקשורת, הצפנה ושרותים נוספים לפי הצורך, כך שבעצם המעבדים בשרת לא מריצים כמעט מאומה – זולת ה-Compute של הלקוחות וה-Hypervisor המינימלי. בשיטה זו רמת האבטחה היא הרבה יותר גבוהה, וגם אם מאן דהוא יצליח לפרוץ לשרת, אין שרות אחסון שרץ מקומית בשרת שניתן להתחבר אליו ולגנוב ממנו מידע (כל התחברות בין VM לאחסון  דרך הכרטיס היעודי מבוססת הצפנה עם מפתח יעודי פר VM ויש עוד מספר אלמנטים לאבטחה).

יש גם נקודת לינוקס בכל העניין: מכיוון ש-DPU מכיל במקרים רבים מעבדי ARM עם אחסון וזכרון עצמאיים נפרדים מהשרת, אפשר לתכנת אותם, ו-Linux Foundation, יחד עם יצרני חומרה נוספים הקימו פרויקט שנקרא Open Programmable Infrastracture Project (ובקיצור – OPI) כדי לעודד חברות תוכנה לכתוב אפליקציות ודברים נוספים עבור אותם DPU.

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

… שלא מתאים לכולם.

למען האמת – אפילו לא לרוב אלו שיש להם מספר קטן עד בינוני של שרתי ESXI.

אני חושבת שיש צורך לספר משהו אחד פשוט לגבי אותם IPU/DPU שהולכים להיות מוצעים: כל הפתרונות הללו נבנו בראש ובראשונה עבור ספקי ענן ציבורי (אז'ור, AWS, GCP, אני בספק אם אורקל משתמשת בכך), ואותן יצרניות החלו להוסיף ולשנות את הפתרונות כך שיוכלו לעבוד עם Project Monterey, כך שבסופו של יום – מדובר על פתרון שהוא מאוד חדש, ואינני בטוחה אם אפשר לקרוא לו "יציב", ובכל מקרה – מחירי כרטיסים כאלו – גבוהים מאוד, ויש צורך גם במתגים עם תמיכה במהירויות גבוהות (25 או 50 ג'יגהביט כמינימום!) – כך שגם אלו שרוצים פתרונות DPU כאלו, לא בטוח שזה יתאים להם.

לסיכום: DPU הוא פתרון מעולה, כאשר יש לארגון עשרות רבות, מאות או אלפי שרתי ESXi. לשאר הארגונים, מעבדי X86-64 כמו Xeon או EPYC – יתנו עבודה כלל לא רעה, ובמיוחד במעבדים העתידיים של שתי החברות ששואפות להכניס רכיבי האצה שונים לתוך מעבדיהן – ואת התוצאות לכך נוכל לראות בחודשים הקרובים.

שימוש ב-Wireguard כפתרון VPN מלא

יש לא מעט מקרים בהם VPN הוא דבר חיוני ונדרש, בין אם בחיבור בין 2 אתרים (Site to site), בין אם חיבור חיצוני לתשתית בענן ציבורי, בין אם חיבור מהבית לתשתית בעבודה וכמובן – כשרוצים להתחבר לתשתית בבית כדי לבדוק דברים או כדי להשתמש בשרותים שונים שרצים בבית – מבחוץ.

עד כה הפתרונות המוכרים ורצים במקומות שונים, היו פתרונות כמו IPsec, או OpenVPN או פתרונות קנייניים של יצרנים שונים (גם יצרני נתבים ביתיים כמו ASUS הוציאו פתרונות VPN כמו Instant Guard … שלא נתמך ב-Windows , Mac או לינוקס אלא רק למובייל) שעובדים בצורה מעולה. הבעיה בדרך כלל כשמדובר על גוף עם תקציב קטן (או ברצון לא להוציא כסף) – הפתרונות הנ"ל לא היו יכולים לבוא בחשבון, ומה שכן בא בחשבון סבל ממגבלות של רישוי (OpenVPN – מקסימום 2 משתמשים), ניצול גרוע של רוחב פס (במיוחד כשמתחברים לתשתית ביתית או upload בכמות מגהביט מזערית) והבעיה הגדולה מכולן – חוסר עדכונים לפתרונות הללו. בנוסף, פתרונות רבים מבוססי נתבים ביתיים מקבלים כמות קטנה מאוד של עדכוני תוכנה, כך שפתרון VPN מבוסס נתבים כאלו יכול להיות פתרון די מסוכן.

הפתרון שמקבל תאוצה בשנים האחרונות מגיע מכיוון אחר, מעולם הלינוקס, והוא פתרון ה-Wireguard. למי שלא מכיר, Wireguard מממש פתרון VPN, אולם הוא עושה זאת תוך שימוש בצופנים מודרניים שאינם "חונקי מעבד" ולא מצריכים פתרונות חומרה במעבדים. כך לדוגמא, Wireguard שרץ על Raspberry Pi 4 ויכול לתת תעבורה מוצפנת במהירות של 400 מגהביט, מספר הרבה יותר גבוה מ-OpenVPN (שנותן רבע או שליש מזה) ובחלק מהמקרים הוא עוקף פתרונות IPSec שונים מבחינת ביצועים ורוחב פס.

ל-Wireguard יש מספר יתרונות גדולים:

  1. ההגדרות עצמן די קלות, ולמי שמסתבך, יש כלי שנקרא PiVPN (שגם רץ על דביאן ואובונטו על מכונות X86-64) שעוזר להגדיר את ה"שרת" ואת ה-Clients בקלות.
  2. אין צורך בהגדרות משתמשים וסיסמאות. שרת ה-VPN צריך בסך הכל את המפתח הציבורי של ה-Client וה-Client צריך את המפתח הציבורי של השרת. השאר – הם הגדרות כתובת IP, DNS ומספר דברים נוספים לא ממש מורכבים.
  3. מבחינת שינויים בנתב – השינוי היחיד שצריך לבצע הוא הגדרת Port forward ב-UDP אל המכונה שמריצה את ה-Wireguard כשרת. אפילו הנתבים של בזק יכולים לתת זאת בלי בעיה. (הערה: בימים האחרונים פרסמתי כי יש לי בעיה בנתבים מסויימים עם הגדרות ל-Wireguard, מסתבר כי זו היתה בעיית הגדרה של firewalld במכונה)
  4. אתה יכול לנצל את מלוא רוחב הפס Upload שיש לך להנאתך. במקרים של חיבורים כמו DSL או כבלים, רוחב ה-Upload הוא מספר נמוך מאוד של Megabits (בד"כ עד 5) ופתרונות VPN מתחרים יוציאו מתוך זה אולי 1-2 מגהביט. עם Wireguard לפי נסיון שערכתי – מתוך 4 מגהביט Upload, קיבלתי רוחב פס של כ-3.5 מגהביט מוצפן החוצה (Upload).
  5. מבחינת Clients – כל מערכת הפעלה תומכת ב-Wireguard – כל הפצות הלינוקס, אנדרואיד, iOS, מק, Windows, כולל Tizen (אם יש לך את ה-SDK ואתה רשום כמפתח..).
  6. הגדרות Client די קלות במובייל – צור Tunnel, צלם תמונה (עקוב אחר ההוראות של PiVPN), שמור. נגמר. ההגדרות גם קלות ב-Windows ומק – העבר קובץ conf שיצרת עבור ה-client למערכת ההפעלה הנבחרת, הפעל Wireguard client, בצע יבוא (Import tunnel) והפעל.
  7. הקץ להעברת כל התעבורה דרך VPN – הגדרת AllowedIPs תאפשר להגדיל ניתוב VPN רק לתשתית מסויימת (Split DNS), וכל השאר יעבור בצורה רגילה דרך האינטרנט. הקץ לגלישה שעושה "טיול" בחו"ל – לאתרים מקומיים.
  8. כשמדברים על מערכות עם עדכוני אבטחה, כל הפצת לינוקס שתתקין (למעט Fedora) תגיע עם הבטחת עדכונים ל-5 שנים לפחות (גרסאות כמו Rocky/Alma/Oracle לינוקס – ל-10 שנים)

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

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

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

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

להלן הנקודות:

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

מטריקות זה דבר מאוד חשוב
יש POC? מעולה, אבל לפני שרצים לחפש חומרה תואמת, ODM וכו', כדאי למדוד ביצועים ולהכין כלי Benchmark כלשהו שימדוד ביצועים, ואת הכלי, יחד עם קוד ה-POC – נריץ על פתרונות חומרה שונים בדרך – כדי לראות אם מקבלים את הביצועים שרוצים. ראיתי לצערי לא מעט כאלו שהזדרזו לרכוש לוחות עם מעבדי ARM שונים ולאחר שהקוד עבר קימפול והרצה – הביצועים הגיעו ל-10-20% ממה שהמערכת במקור נותנת על PC.

חשוב לעבוד עם יצרן חומרה
אם האיש או החברה החליטו ללכת על פתרון משובץ עם מעבדים מסויימים ושרותי ODM לתכנון לוח וכו' – חשוב לקחת את המלצות יצרן המעבד או הלוח ואם אפשר – את ה-SDK של יצרן החומרה. אחת הטעויות הנפוצות ביותר לאלו שמתחילים בעולם המערכות המשובצות – היא המחשבה שעולם הלינוקס במערכות משובצות הוא כמו עולם הלינוקס בדסקטופ. הוא בשום פנים ואופן לא ובמקרים רבים החלטה כמו "נלך על Yocto", "נלך על Open Embedded" וכו' מבלי שהיצרן אכן ממליץ ותומך באותה הפצת לינוקס – תיגמר בכי רע, הואיל ויש המון חלקים בעולם הלינוקס המשובץ שניתנים כקוד סגור, או קוד שנמצא Out of tree בהשוואה לגירסאות לינוקס שונות (ואם אין איש לינוקס שמבין בפיתוח דרייברים/קרנל – תהיה בעיה בלשלב את הקוד), או שפשוט לא ניתן יהיה להפעיל חלקים שונים בחומרה כי פשוט אין דרייברים זמינים באופן חופשי לציבור, ולכן – גם אם אתם בונים פתרון משובץ שימכר בכמה עשרות דולרים לצרכן ולכן כל סנט שנחסך הוא חשוב – צרו קשר עם יצרן הלוח או יצרן המעבד וסכמו על תמיכה וקבלת SDK.

נקודות לגבי AI, וידאו ומדיה
כדאי לשים לב כי בתחומים שונים כמו הסקה ב-AI (כלומר Inference), קידוד/פריסת וידאו/אודיו וטיפול בתכני מדיה שונים – יש מרחק רב ממה שהחומר השיווקי מציין לבין מה שמקבלים "ביד" בפועל. בתחום ההסקה לדוגמא, ישנם כמה יצרנים המציינים כי יש ברשותם שבבים ל-"AI" עם ביצועים מרשימים לביצוע הסקה, אבל בפועל (ואני בכוונה לא רוצה להזכיר שמות) התמיכה במודלים ובמטריצות – אינה מספקת או איטית. בתחום הוידאו – יש לא מעט כאלו שתומכים ב-H.264/H.265 – חלקם בפריסה בלבד וחלקם בפריסה וקידוד, אולם כמות וסוג הפרופילים שהם תומכים – היא קטנה מאוד, וברוב המקרים גם אין תמיכה ל-DRM שלקוחות רבים בתחום המדיה (כבלים, STB, וכו') דורשים, ולכן עוד לפני שמתחייבים לרכישות גדולות, כדאי לרכוש/לקבל Sample של לוחות שונים ולנסות אותם. נכון, יש צורך בהשקעה כדי לבצע Porting אבל בדרך כלל ההשקעה אינה גדולה ודי קל להמיר/לקמפל קוד למערכת ARM או X86 אחרת.

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

חשוב לבנות את ה"מסביב"
יש לא מעט חברות שיצרן מוצרים מעניינים לשוק ובמחירים זולים מאוד, אבל כשזה מגיע לאבטחה ועדכונים – תשכחו מזה (נסו לדוגמא לחפש עדכונים למוצרי TP-LINK או DLINK שנמכרים בארץ, אולי תמצאו עדכון אחד או 2 במשך כל חיי המדף של המוצר). כיום, כל מוצר שיוצא לשוק ונמכר במחיר זול – נפרץ די מהר, והדרך מהפריצה ועד לבעיות אבטחה שכל מיני פורצים מנצלים את המוצר כדי "לגייס" את המכשיר על מנת לתקוף מטרות שהפורצים בוחרים ב-DDoS – קצרה, ולכן חשוב עוד לפני שהמוצר בכלל יוצא – לוודא שה-Image כולל תשתית מאובטחת לקבלת עדכונים, לחתום כל עדכון, לא לאפשר לכל דכפין לנצל פלטפורמה כמו U-Boot להתקנת Images עצמאיים של הפורצים.

חושבים להשתמש בפתרון עם אנדרואיד?
אם אתם בונים פתרון המבוסס על אנדרואיד, חשוב יהיה לבנות מחדש את האנדרואיד שיתקבל מיצרן החומרה, להוסיף את התוכנות שלכם (ללא שימוש ב-root! או sudo וכו'), להכין IMAGE, ולתת את ה-Image שבניתם ליצרן החומרה. אם אתם צריכים הגנה על תכני מדיה (DRM), בקשו מהיצרן תמיכה ב-Widevine כולל הטמעת מפתחות בזמן יצור המכשיר. והקפידו על שחרור גרסאות עדכון אחת לזמן מה.

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

בהצלחה.

הדברים החשובים בהטמעת פתרון קוד פתוח בארגון

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

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

להלן מספר נקודות:

  • תכיפות שינויי קוד: חברות כמו רד-האט מפתחות את מוצריהן בצורה פתוחה וזמינה לכולם ב-github, ומכיוון שהפיתוח נעשה בצורה פתוחה וציבורית, מבוצעים שינויי קוד רבים, במקרים רבים – שינויים יומיים, וברוב המקרים, גם אם מוכרזת גירסה של הפתרון/ספריה/פלטפורמה – הגירסה אינה כוללת עדכוני אבטחה, בדיקות יציבות ותיקונים אחרים שקיימים בגרסאות המסחריות. מעבר לכך – אם המוצר קורס או גיליתם באגים – תהיה לכם בעיה לקבל סיוע, והכל יהיה תלוי בליבם הטוב של מתנדבים או עובדים (וגם על זה לא מומלץ לבנות, הואיל וחברות כמו סוזה, רד-האט, קנוניקל ואחרים – מקבלים הוראה לתעדף תיקוני באגים לאלו שרכשו גרסאות מסחריות או לאלו שמשלמים על חוזי שרות ליצרן התוכנה).
  • גרסאות תכופות – פתרונות כמו OpenStack, Kubernetes, Ceph, Gluster ופתרונות רבים אחרים משוחררים בתדירות די תכופה ע"י הקבוצות המפתחות אותם עבור יצרניות הפצת לינוקס. הן לוקחות את הקוד, מבצעות שינויים ותיקונים, מוסיפות עדכוני אבטחה (שיחזרו לקוד ה-Upstream יותר מאוחר), כותבות תיעוד ספציפי ועוד ועוד – ואז משחררות אותו במסגרת Life Cycle רשמי עם תמיכה רשמית ועוד, ומוציאות זאת כמוצר מסחרי, ובמילים אחרות – אותם מוצרים שיוצאים כגרסאות תכופות אינם מיועדים לפרודקשן.
  • האם יש לך צוות לינוקס בחברה? אם יש לך צוות In House שמבין היטב בלינוקס ויכול "לשחות" בתוך קוד של אחרים במקרה של תקלה במוצר/ספריה/פלטפורמה – במקרים כאלו קל יותר להטמיע פתרונות בקוד פתוח שעדיין לא יציבים כפרודקשן, ולכן כדאי להסתכל על הנקודה הבאה…
  • אבטחה – פתרונות קוד פתוח שלא מגיעים מיצרן כלשהו, בחלק גדול מהמקרים לא כוללים עדכוני אבטחה, ולכן אם החלטתם בכל זאת להטמיע את הפתרון בחברה, מומלץ כי אחת לחודש הצוות הפנימי בארגון יבדוק את הפתרון המותקן מול הפתרון שנמצא ב-github לדוגמא, ובמיוחד יבדוק אם ישנם תיקוני/עדכוני אבטחה שפורסמו בנפרד (כ-PR או במקומות אחרים) או גרסאות minor בהשוואה למה שמותקן פנימית – ויבצע עדכון ידני. ארגונים שאין ברשותם אנשי לינוקס, מומלץ מאוד יהיה לעבוד עם הגירסה המסחרית ולקבל את העדכונים מהיצרן.

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

רד-האט: מפספסים שוב ושוב את הרכבת

כל מי שמסתכל על חברות טכנולוגיות שונות, יכול לראות לא מעט מקרים שחברות שונות "מפספסות את הרכבת" עם הפתרונות והמוצרים שהם מוכרים, תוך התעלמות מהשינויים בשוק. קחו לדוגמא את Qualcomm – לאחרונה התבשרנו שהחברה "נעקפה" מבחינת אחוזים בשוק על ידי המתחרה MediaTek, חברה שקטנה בהרבה מ-Qualcomm (ותחמנית לא קטנה). מבחינת ביצועים, אפל מצליחים להוכיח שוב ושוב בכל גירסת מעבדים שהחברה מוציאה – שהיא עוקפת בקלילות את המעבדים בקצה העליון ש-Qualcomm מוכרת, ובמבחנים שונים שנערכו לאחרונה, מעבד ה-M1 של אפל עוקף בקלילות את ה-Snapdragon 888 5G של Qualcomm. זה מזיז ל-Qualcomm? עד כה, לא ממש. אם קוואלקום לא רוצה להפיק לקחים, הם עלולים למצוא את עצמם מפסידים עוד ועוד אחוזים מהשוק וצניחה בהכנסות ורווחים. אגב, ל-AMD ולמיקרוסופט (כל חברה בנפרד) יש תוכניות במגירה למעבדי ARM חזקים – ולא רק לשרתים.

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

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

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

  • תוכנת oVirt לוירטואליזציה – אנחנו ב-2020 והמוצר הנ"ל של רד-האט עדיין מפגר בצורה משמעותית בהשוואה למתחרים. גרוע מכך: בשעה שכל יצרני פתרונות הוירטואליזציה עוברים ל-Hyperconverge, פתרון ה-oVirt "מעניש" אותך כשאתה משתמש בדיסקים מקומיים ומבטל לך פונקציות קריטיות! בנוסף, רד-האט עדיין לא הצליחו להוציא גירסה שהיא ידידותית למשתמש ושתגרום ללקוחות פוטנציאליים לחשוב על מעבר אליה. הדוגמא הכי פשוטה: מעוניין לדעת מה התכונות החדשות שקיימות בגירסה המסחרית (RHV)? קח, תתחיל להציץ ב-Bugzilla, אולי תבין משהו, כי ברד-האט מתקמצנים לקחת צוות מקצועי שיכתוב את הדברים בצורה קלה לאלו שאין להם מערכת RHV קיימת..
  • פלטפורמת Cloudforms – הנה פלטפורמה שיכולה לסייע המון לכל ארגון שמשתמש בוירטואליזציה ב-On Prem מצד אחד, ובעננים ציבוריים מצד שני. הפלטפורמה עצמה היא ניטרלית לחלוטין והיא יכולה לתת למנהלי המערכת לבצע פעולות שונות בתשתית המקומית ובענן, להרים מערכת אישורים על מנת להוסיף/לבטל תשתית וירטואלית ועוד ועוד. רד-האט רכשה את יצרנית התוכנה (ManageIQ) עוד ב-2012. אתם מכירים איזה ארגון שהקים את הפלטפורמה בתשתית הפנימית? סביר להניח שלא. זה בסדר, רד-האט הרגה את המוצר רשמית לפני שבועיים. מדוע? כי המוצר נהיה סלט שלם, הוא סבל משינויים רבים (כולל החלפת שפה) וחוסר כיוון כללי.

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

ה"קטילה" של CentOS היתה צעד נכון מבחינה עסקית (אם כי רד-האט עשתה זאת בצורה ממש גרועה. החברה היתה צריכה להודות ש-CentOS הורג הכנסות ולא להציע את גירסת ה-Stream, לא כולם מטומטמים!), אבל רד-האט צריכה במהירות לתת פתרון חלופי שאינו עולה 350$! רד-האט צריכה לדוגמא להציע משהו הרבה יותר זול עם תמיכה מאוד מוגבלת, מחיר זול לגירסת VM, מחיר זול לשימוש אישי (או בחינם תמורת רישום ב-RHN) ועוד, ומה שהכי חשוב – להפסיק לעשות את החיים קלים למתחרים! דוגמא פשוטה: רשיון כמו ה-GPL (לא חשוב איזו גירסה) מחייב אותי לדוגמא לשחרר שינויי קוד (לא ממש. הוא מחייב אותי למסור אותם למי שדורש, ואני יכול לדרוש על כך כסף, אגב, הכל מצוין ברשיון) – אבל השינויים לא חייבים להיות משוחררים כטלאים ידידותיים. אם לקחתי לדוגמא קובץ של 10000 שורות ושיניתי 4 שורות, אני יכול לשחרר/למסור את ה-4 שורות ששונו/התווספו, אך בפורמט שאינו מציין מאיזה מקום בקובץ הן שונו, ואלו שורות מחקתי/החלפתי. כך מקשים על מתחרים.

לסיכום: ברד-האט צריכים להחליט מה הם רוצים לעשות מבחינה עסקית. Openshift הוא אחלה פתרון עסקי, אבל צריך לדאוג לפתרון גמיש (מבחינת מחיר) לגבי ה-OS, וצריך להחליט מה עושים עם שאר המוצרים שיש לרד-האט (כמו .. לדאוג סוף סוף לא להבריח לקוחות מ-Gluster עם החלטות מטומטמות כמו לנטוש NFS Scale Out?) ואולי אפילו לפרסם מפת דרכים פר מוצר. אנשים תמיד יתלוננו על כך שלוקחים להם משהו חינמי (אם כי אותם אנשים צודקים לגבי ההחלטה המוזרה וחפוזה ללא פתרון חלופי, ו-CentOS Stream זה הדבר האחרון שהייתי ממליץ אי פעם לארגון להתקין ב-VM או בשרת!), אבל אנשים מעריכים שקיפות והגינות. אם החברה תתעלם, היא עלולה למצוא את עצמה בגורל כמו של חברת דיגיטל, אם מישהו זוכר..