קטגוריה: כללי

כמה מילים בעניין חוק המחשבים

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

קצת רקע לגביי: אינני מבצע בדיקות באתרים חיצוניים כביזנס וברוב המקרים הדיווחים שלי ל-SoC של בנקים מגיעים לאחר שאני או חבריי מקבלים הודעת Phishing, אני מבקש להעביר את ההודעה אליי, אני מנתח את האתר, כתובות IP, ספק ועוד דברים – ומעביר במייל ממני אל ה-SoC את כל הפרטים ללא בקשת תמורה כלשהי. השרות המסחרי שהעסק שלי מציע לחברות בכל הקשור לאבטחת מידע קשור להקשחת שרתים, כחלק משרותים אחרים שהעסק שלי מציע.

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

כשזה מגיע לאבטחת מידע, רוב החברות שבטוחות שהן מוגנות ב-95%+ הן טועות, מכיוון שברוב החברות רוכשים כל מיני פתרון כמו חומות אש, WAF, IPS/IDS וכו' ולפיכך הן סוברות שהן מוגנות. ההגנה שהציודים הללו נותנים היא חלקית בלבד. פורץ מתוחכם לא יחפש איך לתחמן את חומת האש או ה-WAF שלך, אלא יכנס לקוד שהדפדפן מוריד למחשב המקומי ולפרמטרים בשורת ה-URL. בחלקים הללו הוא ינסה למצוא את הכשלים והחורים. אחד הטיעונים המגוחכים ששמעתי ש"אין למשתמש שמריץ את ה-web service אפשרות shell". מדוע מגוכך? כי אפשר ליצור shell בכל שפה דרך הדפדפן. להלן דוגמא של shell ב-PHP שכל מה שהפורץ צריך לעשות זה למצוא מקום שההרשאות יותר מדי פתוחות כדי להעלות את הקובץ ומשם לחגוג (אם בשרת יש תמיכת PHP).

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

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

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

אותם אנשים יושבים לפעמים בבית, ולפעמים הם גולשים לאתרים מסויימים. נניח שהם גולשים לאתר להזמנת פיצה ומוצאים משהו חשוד: נתונים עוברים ללא הצפנה, או שניתן לשנות נתונים דרך הפרמטרים ב-URL כדי לקבל מחיר יותר נמוך לדוגמא. בכל המקרים שמפתח כזה מעוניין לדווח, הוא לא מעוניין לגנוב או לשבש דברים במערכת, אלא הוא מעוניין להביא לידיעת בעלי/מפתחי האתר שיש כשלון אבטחה קל/בינוני/חמור באתר המסחרי שלהם. אם הוא היה מעוניין להרוויח מהפירצה, כל מה שהוא היה אמור לעשות זה לתעד את הפריצה בקובץ Text ולמכור אותו ב-Dark Web מבלי לדווח לבעל האתר. סביר להניח שהוא היה מקבל סכום נאה שם.

בשביל לדווח על פריצה, יש צורך ב-3 דברים:

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

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

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

אם נסתכל על כל חברה גדולה בחו"ל, החל מ-eBay, אמזון, PayPal, מיקרוסופט, רד-האט, IBM ואלפי חברות גדולות נוספות – כשהם מקבלים פניה בקשר לכך שראובן מצא חור באבטחת מידע, אף אחד מהם לא פונה ל-FBI. אדרבא, מתייחסים באדיבות לפונה ובמקרים רבים שולחים לו כתודה גם איזה צ'ק נחמד (בד"כ של 4-5 ספרות בדולרים) ובמקרים רבים גם בודקים אם אפשר לשכור את שרותיו של ראובן או שיעבוד עבורם.

אז מהי ההחרגה בחוק שכדאי לדעתי להוסיף? החרגה שמנקה את ראובן מכל אשמה, כל עוד הוא עומד בדברים הבאים:

  • הבודק (ראובן) לא ניסה לשבש את פעילות השרתים בהתקפות כמו DDoS, Brute Force ואחרים
  • לראובן לא היתה כוונה מסחרית להרוויח מהפריצה.
  • ראובן שלח את כל הפרטים כולל פרטיו אל בעל האתר ומוכן לשתף פעולה עם בעל האתר על מנת לסגור את הפירצה.
  • ראובן לא ביקש ביקש ולא ניסה לסחוט את החברה (מסירת פרטי פריצה תמורת סכום כסף)

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

אשמח לשמוע את דעתכם.

בקשר למחירי שרתים

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

בסופו של דבר מישהו מאותה חברה יצר קשר עם עבדכם הנאמן. אני שאלתי רק שאלה אחת: האם במקרה המעבד הוא Xeon מהסידרה Silver, Gold או Platinum? התשובה היתה חיובית. הסברתי לבחור שלצערי ב-2 הדורות האחרונים של Xeon Scalable באינטל פשוט התעצלו לבנות מנגנון אחיזה (Retension) רציני למעבד והפעם צריך להסתדר עם ברגים בלבד, כאשר אם יש תנועה של אפילו חצי מילימטר – מקבלים את התופעות שהם מקבלים, ובקיצור – צריך לחזור לשולחן התכנונים, לחשוב על מעבד אחר ולשנות עוד כמה דברים.

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

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

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

בישראל לעומת זאת, ככל שזה מגיע לשרתים, מחשבים אישיים וכו' – אין חיה כזו. שום יבואן רשמי לא מוכן לפרסם את המחיר הרשמי ללקוח הסופי. אני יכול לפנות לדוגמא ל CData, One, CDLog, הראל ואחרים ולקבל עבור אותו מפרט הצעות מחיר שונות (וכמובן בדרך לחכות בין יומיים לחודש וחצי להצעת מחיר!) עם הבדלים של אלפי (או עשרות אלפי – תלוי במפרט) שקלים בין הצעה אחת לאחרת. במילים אחרות: אם לדוגמא שרת DELL עם מפרט משלי עולה בארה"ב 10,000 דולר ובארץ אותו שרת עם אותו מפרט היה עולה 17,000 דולר מחיר רשמי, לא תהיה לי בעיה עם זה (זה לא אני זה שמשלם את המחיר, זה הלקוח), אבל כשאני רואה שתי הצעות מחיר שונות עם הבדל של 6000 שקל לדוגמא, אני פשוט תוהה – על מה ההבדל? על זה שנציג מכירות הוציא כמה אימיילים וישב 5 דקות מול אקסל? (כי למעט המשלוח השרת ללקוח וההתקנה הסופר ראשונית – הכל נעשה ע"י היצרן בכלל).

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

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

פרילאנס: חשיבות הלבוש בראיונות

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

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

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

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

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

כשזה מגיע ל-Time-Machine, פאקטור הלבוש ברוב מוחלט של המקרים יהיה לא רלוונטי, פשוט תסתכלו על העובדים. כמה מתוכם לבושים מחויט? אולי ההנהלה. זה שתבוא בג'ינס מהוה וטי שירט, לא מגולח – פשוט לא ישנה. מה כן ישנה?

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

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

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

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

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

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

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

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

כמה מילים על WSL 2

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

מיקרוסופט בשנים האחרונות ביצעה כמה שינויים על מנת לכלול תאימות למערכות אחרות. כך לדוגמא ה-command prompt הישן קיבל מתיחת פנים הן ב-Power Shell ומאוחר יותר גם בתאימות להצגת טרמינלים מרחוק (בחיבור SSH או Telnet). זה לא היה מושלם – אבל זה היה צעד חשוב, במיוחד כשמיקרוסופט החלו לשלב גם SSH Client בתוך Windows 10 לגרסאותיו השונות.

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

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

מכאן נעבור לנושא הפוסט: WSL 2.

למי שאינו מכיר, WSL (ראשי תיבות Windows Subsystem for Linux) זו מערכת שמיקרוסופט פיתחה שמשתלבת עם ה-NT Kernel (כן, Windows 10 מבוסס על NT, כמו רוב גרסאות ה-Windows בשנות ה-2000). המערכת הזו משמשת כ"מתרגם" מה-API של ה-Linux Kernel (גירסה 4.4 של ה-Linux Kernel) ל-NT API. בנוסף, המערכת גם דאגה להרשאות מיוחדות של קבצים ותיקיות כך שלא היה צורך ליצור Partition של לינוקס מצד אחד, ומצד שני קבצים בינאריים של לינוקס לא יכלו לרוץ על Windows שלא מותקנת בה WSL. כל הקונסטרוקציה הזו נועדה לתת מספר דברים:

  • לאפשר לבנות הפצות לינוקס ידועות שירוצו ישירות עם ה-WSL ללא צורך במערכת לינוקס ב-VM
  • לאפשר להריץ אפליקציות לינוקס בהתאם להעדפות שלכם.
  • אין צורך בלשלב קוד GPL כמו ה-Kernel לתוך המערכת.

הדבר הזה עבד לא רע… אלא אם היית רוצה להתחיל להשתמש בזה ברצינות עם המערכת, כמו לקמפל קוד, להתקין NPM וכל דבר שהיה קשור לקבצים – שם ה-WSL היה גרוע. כמה גרוע? אם נניח פעולה של פתיחת קובץ דחוס היתה לוקחת דקה במערכת לינוקס טבעית, עם WSL זה היה תהליך איטי מאוד (אתם מוזמנים להסתכל במבחני השוואה כאן), כך שכל מי שרצה להשתמש ברצינות ב-WSL היה יורד מזה מהר מאוד לאחר שהיה חווה את הביצועים האיטיים. מי שחשב להשתמש בקונטיינרים עם WSL או עם דרייברים של לינוקס היה מגיע למסקנה המרה ש-WSL לא יכול להריץ דברים כאלו. מצד שני – זה היה אחלה דבר בשביל להריץ דברים מרחוק כמו Ansible, התחברות למערכות מרוחקות עם מפתחות וכו' וכו'.

מיקרוסופט היו בהחלט מודעים לעניין, והם הבינו שהטריקים של המרה ל-NT-API לא ממש יעזרו. דרוש פתרון אחר ועדיף פתרון "טבעי".

התוצאה: WSL 2.

השינוי המהותי עם WSL 2 שהפעם יש מעין "מיני VM" קטן שעושה Boot ומטעין גירסה מאוד מקוצרת של ה-Kernel, אך ללא ה-1001 דרייברים שמגיעים עם ה-Linux Kernel וכל הדרייברים הנחוצים שלינוקס צריך – הוא מקבל אותם דרך דרייברים Paravirtualized (קצת מזכיר את ה-VMWare Tools שמתקינים). כך, מצד אחד ה-Kernel רץ בצורה מבודדת כ-VM קטנטן, ומצד שני מיקרוסופט לא צריכה להסתבך עם ה-GPL: הם ישחררו את שינויי הקוד שהם צריכים לשחרר ואין נגיעה ישירה לקוד של Windows.

בשיטה הזו, ה-WSL 2 מקבל מספר דברים:

  • אפשרות להשתמש בגירסת Kernel מודרנית (אני מאמין שמיקרוסופט תוציא מסמך איך לקמפל קרנלים משלך לשימוש ב-WSL 2)
  • אפשר להשתמש בדברים כמו cgroups, להריץ קונטיינרים (docker, cri-o וכו')
  • כל גישת ה-File/Directory תעבור דרך דרייבר שמיקרוסופט תשחרר ש"ידבר" עם NTFS, ומיקרוסופט טוענים כי בדיקות שלהם מראות כי הביצועים משתפרים פי 20 בהשוואה ל-WSL 1.
  • יותר אפליקציות יוכלו לרוץ.

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

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

קצת על אחסון נתונים ונקודות חשובות לפני החלטה

[stextbox id='info' mode='css' direction='rtl' shadow="false"]הערה: בפוסט זה אני רוצה להתייחס לנקודות שלדעתי חשובות לפני שמחליטים לקנות או לבנות סטורג'. פוסט זה אינו בא להמליץ על יצרן מסוים, דיסקים מסויימים וכו'. הפוסט נכתב כחומר למחשבה בלבד.[/stextbox]

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

אחד הדברים המעניינים שניתן לראות קשור לגודל החברה המעוניינת בפתרון: ככל שהחברה יותר גדולה והיא יותר "Enterprise" – היא יותר ויותר "נצמדת לפרוטוקול" – הם ירצו פתרון של יצרן ברזלים מסוים ופחות יסכימו לפתרון SDS (כלומר Software Defined Stroage) עצמאי – אלא אם יצרן הברזלים ימליץ על הפתרון. הם יעדיפו תמיכה במקום אחד (שרתים, סטורג'), מקסימום 2 (שרתים של יצרן אחד, סטורג' של יצרן מאוד ידוע) אבל לא מעבר לכך. ככל שהעסק יותר קטן – הדברים יהיו הפוכים (בכל זאת, צריך לחסוך). החריגה מהכללים אצל החברות הגדולות, אגב, מגיעה כשצריך אחסון של מעל 1 פטהבייט – פתאום הח"מ מקבל טלפונים בדיוק מאותם אנשים שהתנגדו לתוכן שכתבתי על סטורג' בבלוג זה.

לפני שאמשיך – הערה קטנה: תודות לחברות שונות (CRG, ווסטרן-דיגיטל, סופר-מיקרו ואחרות) השאלתי ציוד כדי להעביד אותו בפרך (Stress Testing) למשך חודש או חודשיים, 24/7 עם תעבורה רציפה מקסימלית (תקשורת/דיסקים, מעבדים, מאווררים, תלוי בטסטים המתבקשים) בהתאם לסטנדרטים של IEEE וארגונים אחרים על מנת לבדוק לחברות וארגונים שונים אם המפרט שהם מבקשים יכול לעמוד בעומסים שונים. כך שהדברים שיכתבו כאן – נוסו.

(בתמונה למעלה: לקוח שרצה לבדוק LACP של 12 פורטים עם תעבורת נתונים של 16 פטהבייט. המבחן עלה לו יותר מסוויצ' 10 ג'יגהביט Low End, אבל – הלקוח דורש ומשלם, אני לא אומר "לא".)

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

הבה נתחיל.

אם אתם כעסק או חברה רוצים פתרון אחסון, חשוב לרכז את הנקודות הבאות שהן הכי חשובות:

  • כמה אחסון נטו אתם צריכים? עזבו חישובים של RAID כזה או אחר, דחיסה, dedup ושאר ירקות. 2 האחרונים הם נחמדים, אך לא תמיד יתנו לכם את מה שאתם מבקשים (זה תלוי בתכנים).
  • כמה לקוחות (clients) הולכים להשתמש בזה? יש הבדל ענק בין אחסון שמשמש לכמה עשרות/מאות מכונות וירטואליות, כמה אלפי משתמשים פיזיים שמשתמשים באחסון כ-File Server או עשרות/מאות אלפי משתמשים דרך האינטרנט.
  • האם החיבור בין האחסון למכונות אחרות ישתמש בתקשורת מהירה? (FC במהירות 8/16 ג'יגהביט, תקשורת 10 ג'יגהביט קואקסיאלית, TwinAX, סיב, Infiniband וכו') והאם אתה צריך ציוד חדש לחבר את הכל ביחד (גם בצד של השרתים, גם מתגים, חיבור לסטורג' עצמו וכו')
  • אחריות, SLA ושאר נושאים פרוצדורליים.
  • והכי חשוב – יחס הקריאה/כתיבה וסוג התוכן.
  • דיסקים SSD שישמשו כ-Cache, שימוש ב-Cache כ-Tiering וכו'.
  • פתרונות של Synology או QNAP.
  • הרחבת אחסון, זכרון.

להלן הנקודות בפירוט:

  • אחסון נטו: נניח ואתה צריך 40 טרהבייט אחסון נטו. אם נשתמש במחשבון הזה תוכלו לראות ש-5 דיסקים של 10 טרהבייט יתנו לנו 40 טרהבייט אחסון נטו עם שרידות של דיסק אחד (כלומר RAID-5). מצד אחד זה יכול "לסגור פינות" שיש לנו כמות אחסון מספקת, וגם שרידות. הבעיה המרכזית: מהירות כתיבת נתונים ושליפתם. אין לנו שום האצה בכתיבת הנתונים, יש לנו האצה בקריאת הנתונים (שזה אידיאלי אולי לארכיבאות לדוגמא). בשביל לקבל האצה פי 4 בכתיבה ופי 8 (בהשוואה לקריאה/כתיבה מדיסק בודד) נצטרך 8 דיסקים של 10 טרהבייט ב-RAID-10. אם אנחנו רוצים מהירות קריאה/כתיבה יותר גבוהה בהרבה (X10 בכתיבה, X20 בקריאה) נצטרך לעבור מדיסקים של 10 טרה לדיסקים של 4 טרה בייט ולרכוש 20 כאלו (תגידו "היי" למארזי 4U). ככל שנבחר דיסקים יותר גדולים, כמות ההאצה שהמערכת תתן – היא יותר קטנה (לדוגמא: 10 דיסקים של 8 טרהבייט יתנו X5 בכתיבה, X10 בקריאה – הדוגמאות הם ב-RAID-10). טעות נפוצה, אגב, היא שימוש ב-RAID-5: הגדרות RAID-5 נותנת אפס האצה בכתיבה לאחסון.
  • לקוחות שהולכים להשתמש בסטורג'. אם מדובר על שרת קבצים לדוגמא, עניין המהירות הוא יחסית די שולי כי כולם משתמשים בתקשורת 1 ג'יגהביט שברוב הזמן מנוצלת חלקית, ואם מישהו יחכה עוד חצי שניה לשמירת קובץ האקסל שלו, השמיים לא יפלו.
    לעומת זאת – מכונות וירטואליות זה סיפור אחר לגמרי. פרוטקול כמו iSCSI הוא פרוטוקול "מפונק" ומערכת כמו VMWare לדוגמא דורשת אישור מהסטורג' על כל קבוצת נתונים שנרשמת, כך שאם אין איזה מנגנון ש"יאמר" ל-VMWare "קיבלתי, מאשר" בכל פעם ובאופן מהיר – המכונות הוירטואליות פשוט יזחלו בכל כתיבה. כיום ברוב פתרונות הסטורג' (סגורים ופתוחים) יש מנגנון שמטפל בכך, אבל אם תרימו מכונת לינוקס עם MDADM ל-RAID, זה לא יתן פתרון (אפשר לעקוף זאת על ידי ביטול ה-sync ב-ZFS לדוגמא, אבל זה מסוכן, במיוחד אם אין UPS למכונה).
    לכן, כשמדובר בסטורג' שיטפל בכל הקשור לאחסון מכונות וירטואליות, חשוב לבדוק שהסטורג' תומך ב-Sync On write, reclaim space, תמיכה ב-VAAI, VVOL ואחרים.
  • חיבור בין הסטורג' למכונות אחרת. הנה נקודה שרבים יתווכחו עליה מתוך איזה נסיון שיש להם, מתוך אמונות, מתוך שמועות, אך כמו שכתבתי למעלה – הנקודות נוסו על ידי הח"מ בתנאי Extreme.
    חיבורי ה-FC היו מעולים לזמנים שהתקשורת נחושת היתה במהירות 1 ג'יגהביט וחיבורי 10 ג'יגהביט היו יקרים מאוד. כיום, לעומת זאת, ישנם 5 אפשרויות פופולריות:

    • CAT6/CAT-6E – חיבורי נחושת של 10 ג'יגהביט, עובדים מעולה ואם רוצים, אפשר לעבוד עם LACP (או Bridge) בצוותים של 2 חיבורים לדוגמא לקבל מהירות יותר גבוהה. היתרון: עלות זולה יותר של כבלים וסוויצ'ים.
    • +SFP עם TwinAx (נקרא גם DAC) – עובד מעולה למרחקים קצרים (עד 5 מטר). חשוב לשים לב שהחיבורים יהיו מאותו מותג של הסוויצ' (בסוויצ'ים 10 ג'יגהביט בקצה הנמוך זה לא רלוונטי, הם מתעלמים מה-Branding Tag).
    • +SFP עם סיבים אופטיים – את זה כולם ימליצו. לא חוכמה 🙂
    • +QSFP – כמו ה-+SFP רק למהירות 40 ג'יגהביט. מדובר בחיבור פיזי גדול יותר כך שהוא אינו תואם אחורה. קיים גם כגירסת DAC/TwinAX וגם כחיבור עצמאי שאליו מחברים סיב אופטי.
  • אחריות, SLA וכו' – כל יצרניות השרתים מוכרות כיום פתרונות סטורג' (ברזלים יעודיים או תוכנה לשימוש בשרתים עצמם) משלהם, אך יחד עם זאת הן גם "מכשירות" (Certified) תוכנות אחרות, ובדרך כלל ביקור באתר יצרן תוכנת הסטורג' יראה את הלוגואים של היצרנים שנתנו "הכשרה" לתוכנת הסטורג', כלומר אם תפנו לתמיכת יצרן השרתים, אף אחד לא יעקם את האף מדוע אתם משתמשים בתוכנת סטורג' X. בחלק מהמקרים (תלוי בחוזה התמיכה) אולי יסייעו לכם עם תוכנת הסטורג' צד ג' או יפנו את בקשת התמיכה ליצרן התוכנה (במקרים בהם יצרן השרתים [כמו HPE] מכר לכם חוזה תמיכה על כל הציוד והתוכנות שברשותכם).
  • SSD, Caching: בכל סטורג' המשלב דיסקים מכניים ודיסקים SSD – המערכת תורכב מ"שכבות" (או במושג המקצועי: Tiering), כאשר השכבה המהירה מורכבת מהדיסקים SSD והשכבה האיטית יותר מדיסקים מכניים (SAS או SATA). ישנם כמובן סוגי סטורג' שונים שבהם יש עוד שכבות כמו מדף זכרון מגובה סוללות, NVRAM, או שכבות של דיסקים מכניים מהירים ובשכבה מתחת דיסקים SATA במהירות 7200 RPM.
    בכל המקרים הללו, ה-SSD נועד "להחביא" את הדברים הקשורים לכתיבה. הוא מקבל את ה-DATA ולאחר מכן ה-DATA מופץ לשכבות היותר איטיות, והוא גם מאחסן נתונים שנקראים תדיר (נניח יש לך 10 מכונות לינוקס, כולן רפליקציות מלאות או משורשרות – רוב הסיכויים שה-DATA יקרא מה-SSD). ה-DATA עצמו לא נכתב ישר אל הדיסקים המכניים, אבל הסטורג' מציג את הדברים כאלו שהנתונים כן נכתבו למכניים, והסטורג' ברקע עושה זאת.
    במערכות יקרות יותר (מילת קסם: AFA או All Flash Array) ישנם גם שכבות אם כי טיפה שונות: רוב הדיסקים הם Read Intense וחלק קטן מהם Write Intense או Mixed Intense ולפעמים יש שימוש ב-NVRAM או בזכרון מגובה סוללה (נדיר). במערכות הסופר-סופר-יקרות, מכניסים גם Optane, גם כרטיסי FPGA ודברים נוספים כדי להאיץ את הכל (ועוברים בדרך לפרוטוקול ה-RDMA הוותיק) – כמו במערכות NVMEoF לדוגמא.
  • פתרונות של Synology או QNAP: אלו פתרונות שאני יכול להמליץ עליהם בלב שלם כפתרונות לשמירה/קריאה של מידע, פחות למכונות וירטואליות (אם כי ל-LAB קטן הם בהחלט יכולים להספיק). כיום בכל QNAP או Synology ניתן להוסיף דיסק SSD לקבלת Cache בסיסי, אבל אל תנסו להכניס לשם SSD מסוג Optane  לדוגמא (כמו שינוי QD) – בשביל זה יש צורך לשנות כמה וכמה דברים בלינוקס ואין במכשירים הללו לא את הספריות ולא את האפשרויות לשנות פרמטרים.
  • הרחבת אחסון, זכרון: בכל מה שקשור לזכרון, רוב הסטורג'ים שמבוססים לינוקס/BSD/סולאריס ו/או ZFS ישתמשו בזכרון כ"מאיץ ראשי" לקבלת הנתונים ולשחרר את צוואר הבקבוק, כך שאם אתם יכולים להשקיע ברכישת RAM – מה טוב.
    לגבי הרחבת האחסון עצמו: בסטורג' סגור הפתרון תמיד יגיע עם "מדפים" לאחסון הדיסקים. בסטורג' פתוח לעומת זאת, חשוב לבדוק שיש חיבור מאחורה המאפשר לחבר JBOD אחד או יותר על מנת להוסיף קופסת JBOD או יותר עם דיסקים ומומלץ לבדוק שהחיבור הוא SAS-3 (נקרא גם HD MINI-SAS או בשמו המקצועי: SFF-8644). לפני שנתיים שוחרר סטנדרט שנקרא SAS-24G אך אני לא ממליץ לרכוש אותו הואיל ודיסקים קשיחים עתידיים (כמו אלו עם 2 מנועים שאמורים לצאת בשנה הקרובה/שנה הבאה) עוברים להשתמש בחיבור NVME. ה-24G פיספס את הרכבת.

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

ההכרזה של אינטל על חומרה חדשה

אינטל לאחרונה הכריזה על שורת מוצרים חדשים – משפחת מעבדי ה-Xeon Cascade Lake שמהווים שדרוג למשפחה הנוכחית, Xeon Scalable. אלו שרוכשים שרתים מ-Dell יוכלו להתחיל לרכוש את הדור הבא של השרתים (סידרת ה-R650,750 וכו') בשבועיים הקרובים (לפחות בחו"ל). חברת HPE עוד לא הכריזה על תאריך השקה וגם לא לנובו. בסיסקו הולכים להוציא את המשפחה החדשה בערך בעוד חודש וחצי. בהשוואה למעבדים הנוכחיים, המעבדים החדשים יהיו קצת יותר מהירים אך באותו מחיר כמו הקיימים, וניתן יהיה (לאחר עדכון BIOS) להחליף את המעבדים הנוכחיים במעבדים החדשים. פוסט יותר מפורט על המעבדים החדשים (כולל רשימת המעבדים) – יופיע פה בבלוג בקרוב.

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

נתחיל בדיסק ה-SSD החדש של אינטל, ה-DC D4800X (תבדילו בינו ל-P4800X). ה-D בשם המוצר מסמן Dual Port. זהו SSD בחיבור NVME כפול. בשביל מה צריך כפול? כדי לקבל שרידות כמובן!…

אממה .. מישהו שכח או התעלם מכלל פשוט שקיים בכל PC, החל מלאפטופ ועד שרת עצבני עם 8 מעבדים: כשיש לך תקלה בחיבור PCIe, המערכת פשוט תקפא או תקרוס. לגמרי. נסיון לבצע כיבוי/הפעלה מחדש לא יצליח לעבור את ה-POST. (בעקרון, כשמפעילים את המכונה, לאחר שהמעבד הופעל וה-BIOS נכנס לשליטה, הוא מריץ את המיקרוקוד שבתוכו, הוא מתחיל לאפס את תושבות וציודי ה-PCIe. כשהוא לא מצליח – תופיע שגיאה שלא תאפשר המשך הפעלת המכנה). במילים אחרות – זה ציוד מעולה .. אם יש לכם Mainframe של IBM, שם אפשר להחליף כמעט את כל הציוד שהמכונה פעילה (וניתן להפעיל/לכבות תושבות PCIe בזמן ריצה) – אבל לא כל כך רלוונטי בשרתים.

מכאן – נעבור ל-Optane DC.

למי שלא מכיר – Optane DC זו גירסת SSD שאינה מתחברת לתושבת PCIe אלא יושבת בתוך תושבות הזכרון של השרת. בתמונה משמאל תוכלו לראות אותם כ"מקלות זכרון" (עם המדבקות, כלומר 3 מקלות Optane DC ו-3 מקלות זכרון DDR4 ECC). כל מקל Optane DC מגיע ב-3 גדלים – 128, 256 או 512 ג'יגהבייט אחסון! (המחירים, אגב, לאלו שרוצים לדעת – ואלו לא מחירים סופיים: 893, 2461 דולר וה-512 ג'יגהבייט עדיין לא יצא). אלו אינם מקלות זכרון, כך שאם יש לך מול מעבד כ-256 ג'יגה זכרון והכנסת מקל Optane DC של 256 ג'יגהבייט, לא יהיה לך זכרון של כחצי טרה, אלא 256 ג'יגה זכרון ו-256 ג'יגה של אחסון מהיר.

בכנס Ignite האחרון, מיקרוסופט הדגימה איך ה-Optane DC עוזר בסביבת HCI שמורכבת מ-Hyper-V, Storage spaces direct וכו'. להלן הוידאו:

שימו לב למשהו אחד חשוב שקצת פחות מודגש בוידאו: כל ה-Optane DC שבשרתים בהדגמה משומש ל-Cache בלבד ולא כ-Storage! במילים אחרות, גם אם תכניס טרהבייט של Optane DC בשרת, עדיין תצטרך Storage כלשהו, ולכן השימוש של Optane DC יותר מתאים כ-Cache ל-DB או למכונות וירטואליות. ניתן לראות את הדגש הזה גם במסמך הזה שהוציאה VMWare שמתייחסת ל-Optane DC ולגירסה עתידית של vSphere.

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

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

אחד המוצרים הנוספים שאינטל הכריזה עליו הוא Intel SSD D5-P4326 – כונן SSD בתצורת "סרגל" (שמו הטכני של הסטנדרט: EDSFF E1.L – שם שממש מתגלגל בפה). כל סרגל SSD כזה יכיל בדור הנוכחי עד 15.32 טרהבייט אחסון… רק לפני שמתלהבים, האחסון מורכב מ-QLC NAND, הווה אומר שבתא NAND אפשר לאחסן 4 ביטים, מה שמאפשר לאחסן יותר מידע פר תא, אך מצד שני, מהירות הכתיבה – איטית מאוד בהשוואה לכונני SSD מדור נוכחי מבוססי TLC (כלומר 3 ביטים בתא). אינטל ושותפיה ימכרו שרת 1U שבו יהיה ניתן להכניס 32 סרגלים כאלו ליצור אחסון עד כמעט חצי פטהבייט שמיועד יותר לאחסון מידע לקריאה, ובמילים אחרות – לא מאחסנים על זה מכונות וירטואליות, קונטיינרים ושאר דברים שמצריכים קריאה/כתיבה מהירה יותר ממה שאותם סרגלי SSD יכולים להציע.

הבעיה המרכזית במוצר היא התחרות שלו מול דיסקים קשיחים מכניים. נכון, SSD נותן מהירות קריאה הרבה יותר גבוהה מכל דיסק מכני, אבל דיסק מכני כמו Seagate Baracuda בגודל 14 טרהבייט ל-Enterprise עולה בסביבות ה-550$ ואילו סרגל של 15.3 טרהבייט של אינטל עולה פי 8. את עניין הבדלי הקריאה/כתיבה ניתן תמיד לפתור בעזרת מספר דיסקים SSD שישמשו ל-Cache כך שהפתרון של אינטל עדיין אינו שווה לדעתי מבחינה כלכלית.

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

על דיסקים מכניים גדולים ו-RAID

מי שעוקב אחרי חדשות טכנולוגיות יכול למצוא אחת לכמה חודשים הכרזות של יצרני דיסקים שונים על דיסקים חדשים, לפעמים על שיטת קריאה/כתיבה חדשה. כך לדוגמא, חברת Showa Denko K. K. הכריזה כי היא סיימה לפתח ראש MAMR חדש לדיסקים קשיחים עבור חברת טושיבה, וטושיבה תוציא דיסקים קשיחים בגודל 18 טרה המבוססים על טכנולוגיה זו במשך השנה. צפו להכרזות דומות מצד שאר היצרנים.

כיום, בין אם יש לך שרת שאתה מכניס בו דיסקים קשיחים ומחבר אותו לבקר RAID כלשהו, ובין אם יש לך סטורג' קנייני – כל היצרנים ישמחו למכור לך דיסקים קשיחים גדולים – בין אם ישירות מיבואן יצרן הדיסקים ובין אם דרך החברה שרכשת ממנה את השרת או הסטורג'. רוצה מדף עם 12 דיסקים של 10 טרהבייט? בשמחה! תחתום פה ופה, תעביר כרטיס אשראי או תשלח צ'ק וטכנאי בדרך אליך להתקין את המדף לסטורג' ולהגדיר אותו. אין צורך לדאוג, גם הדיסקים הגדולים שנמכרים כיום נמכרים עם SAS Dual Port לחבר ל-2 כרטיסי RAID (אם אתה רוצה להכניס את זה לשרת, בסטורג' זה אוטומטי).

אבל האם זה שווה לרכוש את הדיסקים הללו? בכל זאת, אם קנינו מדף של 12 דיסקים בגודל 10 טרה, אנחנו נקבל ברוטו 120 טרהבייט, זה שקט להרבה זמן מבחינת אחסון פנוי!

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

לשם פוסט זה, נניח ויש לנו את ה-12 דיסקים של 10 טרה, והם מורכבים בסטורג' או בשרת עצמאי עם 2 בקרי RAID (או אחד, זה לא ממש משנה מבחינת מהירות קבלת נתונים, ה-Dual Port ב-SAS הוא יותר לשרידות, אם כי במצב שהולך לך בקר, אני הייתי ממליץ לך להשבית את השרת עד שיגיע טכנאי עם חלק חלופי. אתה לא רוצה לסכן את ה-DATA שלך!). נניח שהגדרנו RAID, נניח 5 או 6 (במצב של 1 זה הרבה יותר מסוכן) או כל "RAID" בסטורג'.

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

וכאן… מתחילות הבעיות והסיכונים צצים…

  • אם הדיסקים נמצאים בשרת והם מחוברים לבקר RAID (וזה לא חשוב איזה RAID הגדרתם, למעט כמובן 0 שאז הלך ה-DATA) – השחזור לא רק שיהיה איטי ויקח מספר ימים, אלא שאתם תסבלו מביצועים נמוכים מאוד באותם ימים הואיל וכל מערך ה-RAID צריך לעבוד בעצם כפול: גם לשרת את הצרכים שלכם, וגם לקרוא מהחלקים השונים של הדיסקים על מנת לכתוב את ה-DATA מחדש על הדיסק החלופי.
  • מכיוון שאתם מאמצים את המערכת – יש סיכוי שדיסק נוסף יפסיק לעבוד, הואיל והמערכת עובדת נון סטופ.
  • במקרים של שרת ו-RAID מבוסס בקר חומרה, הכתיבה היא "הכל" – גם אם היה לכם ב-RAID חומר בגודל 10 ג'יגהבייט, הוא יבצע Rebuild של 10 טרהבייט, מכיוון שבקר RAID הוא דבר די טיפש.
  • במקרים של סטורג' (או Software defined Storage) – שיטת ה-Rebuild תהיה שונה, וכמות ה-DATA שתיכתב על הדיסק תהיה כמו שאר הדיסקים באותו "RAID", כך אם יש חומר של 10 ג'יגה, יכתב 10 ג'יגה. ההבדל הגדול בין סטורג' לבין שרת עם בקר RAID חומרה – זה שהסטורג' יודע "להסתיר" את האיטיות עם דיסקים SSD, עם Flash Cache וטריקים אחרים, אבל עדיין – תורגש איטיות.

לכן, אם אתם מעוניינים לרכוש כמות דיסקים קשיחים גדולים ולבנות לעצמם NAS לדוגמא, כדאי להסתכל על ההמלצות הבאות:

  • חברו את הדיסקים ל-HBA ולא לבקר RAID (אפשר לרכוש בקרי LSI עם IT MODE או להחליף להם קושחה).
  • השתמשו בתוכנה כדי לבצע RAID. יש הרבה פתרונות – החל מ-FreeNAS, ZFS, XPEnology, או Storage Spaces של מיקרוסופט. הכל תלוי בהעדפה שלכם.
  • השתמשו ב-SSD שהוא Mixed Intensed או SSD שמתאים ל-Enterprise אם המהירות חשובה לכם. ההמלצה שלי היא ללכת על Optane 900P או DC P4800X (אם יש לכם את התקציב) של אינטל על מנת לקבל Latency מאוד נמוך וביצועים גבוהים מאוד (שימו לב – אם השרת אינו חדש, אז ה-Optane לא יוכל לבצע Boot ואם בשרת אין תושבות PCIe 3.0 – אז הוא לא יעבוד).
  • אם אתם משתמשים ב-ZFS, אל תשכחו להגדיר תהליך "קרצוף" (scrub) של הדיסקים לפחות אחת לשבוע (התהליך עובר על כל ה-DATA והיכן שהוא מוצע בעיות, הוא משכתב את ה-DATA למקום פנוי אחר, כך שהעבודה תהיה חלקה).
  • גיבויים, גיבויים, גיבויים – תוכנות גיבוי זה טוב, אבל snapshots ברמת האחסון הם יותר טובים והשחזור הרבה יותר מהיר. דאגו שתהיה מכונה אחרת עם מקום פנוי לקבל את ה-Snapshots.

ככלל, לא חשוב אם האחסון שלכם הוא NAS שבניתם או סטורג' שקניתם, אם כמות האחסון שלכם נעה בין מאות טרהבייט לפטהבייט – עדיף לעבור לפתרון Scale Out (וכשאני מדבר על Scale Out אני מדבר על מספר מכונות [גם נקראות Nodes]) המכילים את הדיסקים או JBOD המחוברים לאותן מכונות. פתרונות כאלו יודעים להתמודד גם עם מצבים שמספר דיסקים קשיחים מתקלקלים במקביל ומענה לדרישה מוגברת של תעבורת נתונים הלוך ושוב לשרתים/מהשרתים.

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

עדכון ליבה בשרתי לינוקס – ללא Reboot

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

בלינוקס – ברוב המקרים אינך צריך לעשות Reboot לשרת גם לאחר שביצעת עדכונים. במקרה הכי גרוע אתה פשוט יכול להפעיל מחדש את השרותים שרצים על השרות – לאחר התקנת העדכונים. חברות כמו רד-האט ו-SuSE עושות את הכל כדי לשמור תאימות בינארית של 100% כך שקונפיגורציות ודברים אחרים פשוט אינם משתנים (ב-2 ההפצות, כשמתקינים גירסה חדשה של תוכנה על הגירסה הישנה, המערכת תייצר קבצי rpmsave באותה תיקיה שנשמרות בה ההגדרות של האפליקציה, כך שתוכל לראות מה השתנה).

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

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

לאחר זמן מה יצאה רד-האט עם kpatch וחברת SuSE יצאה עם Live patching. קנוניקל לא נשארה מאחור והם הכריזו על שרות שנקרא livepatch.

כל השרותים לעיל – הם בתשלום בלבד, כלומר העדכונים צריכים לעבור דרך מערכת עדכונים מורשית של ההפצה בלבד. לא מדובר באיזו חבילת RPM או DEB שאפשר להוריד ולהתקין חופשי על כל השרתים בחברה. ב-רד האט יש צורך לעשות זאת דרך שרות Satellite וב-SuSE דרך SuSE Manager. באובונטו נותנים בונוס למשתמשים – מי שנרשם, יכול לעדכן דרך שרות livepatch עד כ-3 מכונות דסקטופ בלבד (לא שרתים, זה כבר בתשלום).

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

ומה עם הפצה כמו CentOS? בכל זאת, יש לא מעט כאלו מותקנות. ובכן, התשובה לכך שזה בהחלט אפשרי אבל .. די מורכב. נאמר כך: זה יותר מתאים לאלו שבונים לעצמם Kernel.

לסיכום: אם יש לכם שרתי לינוקס בפרודקשן והם שרתים מבוססים על Red Hat או SuSE או אובונטו בתשלום – כדאי להשתמש בשרות ה-Live Patching ותחסכו לעצמכם דאגות על אבטחה וענייני Reboot.

פרילאנסרים: תמצאו את החתול

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

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

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

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

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

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

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

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

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

בהצלחה.

להתקדם בתחום

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

כל השואלים יודעים ורואים במקום עבודתם ושומעים גם מחברים – על השינויים המתרחשים. על שימוש בעננים ציבוריים במסגרת העבודה, על קונטיינרים, על Devops, CI/CD, Kubernetes, ויש גם עשרות תתי נושאים. כל מי שקורא את הפוסט הזה בוודאי שמע על המושגים אבל רבים אינם יודעים בעצם מה ללמוד, מה חשוב ומה לא ובקיצור – איך להיות רלוונטי בעולם ה-IT של היום.

בעבר, החיים היו הרבה יותר פשוטים. אם היית רוצה "להתמקצע" בתחום של מיקרוסופט, אז היית לוקח איזה קורס MCSE (או איך שזה נקרא כיום, סורי, אני לא עוקב אחר שינויי השמות), לומד כלים משלימים של מיקרוסופט כמו SCCM, אקסצ'יינג', אולי PowerShell, ועם זה היית הולך לחפש עבודה. אחרים הלכו לתחומים כמו לינוקס ושלל השרותים שנמצאים בלינוקס, יש כאלו שהיו הולכים ללמוד CCNA בשביל תקשורת מחשבים, ויש כאלו שלמדו קורס כלשהו על סטורג', אחרים למדו VCP בשביל וירטואליזציה. בחברות גדולות היו מחפשים יותר דברים ספציפיים כמו אחד מהנושאים שציינתי לעיל (לדוגמא – איש וירטואליזציה), ובמקומות יותר קטנים היו מצפים שתכיר את כל הנושאים שציינתי על מנת להתקבל למקום העבודה.

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

אז מה אתה יכול לעשות כדי לשפר את סיכוייך למצוא עבודה טובה בעתיד?

יש כמה דברים.

אם אתה רוצה להישאר בתחום ה-IT הקלאסי (לפני כניסת הענן) אז מה שמומלץ לך זה ללמוד את התחומים "השכנים": אתה איש סיסטם מיקרוסופט? תכיר יותר את תחום הסטורג' הרגיל, תכיר יותר נטוורק לעומק (אתה יכול להשתמש בכלי כמו GNS3 לבצע סימולציות), והכי חשוב – להכיר את מערכת ההפעלה ה"מתחרה" לינוקס במובן הטרמינל (לא במובן הגרפי. ברוב המקרים אתה לא תעבוד מול תצוגה גרפית במכונות לינוקס) – מה זה לינוקס, איך הוא בנוי, פקודות לינוקס בסיסיות, כתיבת סקריפטים בסיסיים ב-BASH, הגדרות ציודים שונים, ניתובים, ניהול חבילות תוכנה, ועוד. אם אתה רוצה, יש אתר בשם Linux Academy שמלמד את הדברים (יש מנוי חודשים שעולה 50$ לחודש, שבוע ראשון בחינם). אם אתה יותר טיפוס של ספרים – יש לא מעט ספרים שמלמדים על לינוקס ויש כמובן גם קורסים בבתי הספר המקצועיים השונים שמלמדים לינוקס. לגבי סטורג' ונטוורקינג – אני ממליץ ללמוד לבד.

במקומות גדולים החל לצוץ לו תפקיד חדש לאחרונה (לא באופן רשמי, לפחות ממה שאני יודע) והוא "Cloud Admin" – מה שאתה עושה מקומית, עכשיו בענן, רק שבענן לא יחכה לך איזה סטורג' של Netapp/EMC, אין לך סוויצ'ים, אין לך פיירוול (את זה אפשר להוסיף, כ-Appliance) והכל בעצם נעשה בתוכנה, בין אם דרך ממשק ווב, אבל יותר דרך ממשק CLI וכאן כבר צריך ללמוד איך להגדיר דברים, החל ממכונות VM, נטוורקינג, דיסקים קשיחים וירטואליים ועוד ועוד. בלינק שפירסמתי לעיל יש גם קורסים לכל ספקי הענן הגדולים, כך שאפשר ללמוד שם גם איך להשתמש בענן ואיך לנהל משאבים. העננים הפופולריים ביותר הם של אמזון (AWS) ו-Azure של מיקרוסופט. קצת פחות פופולרי (והרבה יותר טכני) הוא הענן של גוגל, לכן מומלץ ללמוד לפחות את הענן שבו החברה משתמשת ואולי את הענן השני הפופולרי.

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

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

איש ה-Devops טוב צריך לדעת כמה דברים חשובים:

  • הוא צריך להכיר טוב לינוקס, ברמה של כתיבת סקריפטים, הגדרות לינוקס, ניהול חבילות
  • הוא צריך להכיר את עולם הקונטיינרים – החל משימוש ב-Docker כדי לבנות Images, והוא צריך להכיר Kubernetes (או OpenShift או Caas) כדי לבצע אורקסטרציה בין הקונטיינרים השונים שירוצו, שרותים, רשתות, Scaling ועוד.
  • הוא צריך להכיר כלי CI/CD על מנת לאפשר ביצוע Build אוטומטי דרך כלים כמו Jenkins או Teamcity לדוגמא.
  • הוא צריך להכיר כלי ניהול קוד טוב. כל כלי שיודע לעבוד עם GIT זה טוב, בין אם מדובר ב-Bit Bucket או GitLab או כלי אחר, וכדאי להכיר את הדברים לא רק ברמת ממשק הווב אלא גם להכיר את GIT עצמו.
  • "קוד כתשתית" – אחד הדברים ש"רצים חזק" כיום הם כלים שכותבים איתם "קוד" לניהול תשתית כמו הענן הפנימי שלכם בענן הציבורי, כלי כמו Terraform או Ansible או SALT הם כלים מעולים לכך.
  • שפות – BASH מאוד יעזור לכתיבת סקריפטים פשוטים, מומלץ להכיר גם Python.
  • שרותים – כל ספק ענן ציבורי מספק מאות שרותים שונים. תצטרכו עם הכלים הנ"ל להגדיר ולהשתמש בשרותים הנ"ל ואצל כל ספק ענן זה שונה. כן. Not Fun.
  • ניטור באופן שונה – מכיוון שיש הרבה שרותים שספק הענן מציע ולך אין גישה לתשתית השרותים, תצטרך להשתמש בכלים שונים לניטור, סביר להניח דרך כלי הניטור של ספק הענן.

כמו שאתם רואים – ערימה לא קטנה של דברים. אגב, כמעט את כולם ניתן ללמוד ב-Linux Academy בלינק שנתתי לעיל.

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

לסיכום: לא לכל אחד מתאים להיות Devops, וזה בהחלט מובן. יחד עם זאת, חשוב לעדכן את הידע כדי להישאר רלוונטיים בשוק העבודה כשכירים. תמיד מומלץ לנסות ללמוד דברים חדשים ולהתנסות, וכיום לדוגמא רוב ספקי הענן יתנו לך איזו חבילה חינמית לכמה חודשים ואם אתם לומדים דרך ה-Linux Academy אז הם נותנים לכם 6 שרתים וירטואליים להתנסות (זמנית, השרתים נכבים אחרי שעה, אבל זה מספיק בשביל לבדוק פקודות או הגדרות מסויימות).

בהצלחה.