על אוטומציה, רובוטיקה ומשרות נוכחיות בשוק

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

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

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

לרובוט אין הפסקות סיגריה, אין כאבי גב, אין "עצבים" בגלל עובדים אחרים, אין עיצומים/שביתה, קל ללמד אותו דברים נוספים (זה לוקח בערך 2 דקות ואת זה ניתן לעשות בעת הטעינה שלו), והשאיפה היא ש-1-2 עובדים יוכלו לנהל צי של 50-100 רובוטים במקום גדול (רוב החברות בארץ שעובדות על רובוטים, עובדות על רובוטים שיתנהלו במרחבים ענקיים). גם מבחינת קופות ממוחשבות, הקופות שיש כיום בשרות עצמי מהוות (שוב, לא בארץ) מעין Stop Gap והשאיפה היא לעשות את הכל עוד בעגלה עם מחשב קטן וסורק, כשהתשלום ואריזה יבוצעו בעת החזרת העגלה, כך שסופר גדול בחו"ל מחזיק לדוגמא 30 קופאיות, הוא ירד ל-3-4.

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

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

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

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

אחד הדברים שבגללו אנשים רבים לא ניגשים ללמוד תחומי היי-טק הוא החשש עקב אי הכרת התחום מהעבר. איך אמר לי מישהו "חץ, לך יש יותר מ-20 שנה נסיון, לי יש אפס נסיון", והתשובה שלי אליו היא שברוב הדברים זה פשוט לא רלוונטי. יש דברים בסיסיים שצריך ללמוד, כמו מה-זה רשת תקשורת, מושגי מחשב בסיסיים וכו', עניין שיכול לקחת בין כמה שעות לכמה ימים, אבל אם יבוא מישהו כמו אותו בחור לעיל ללמוד לדוגמא Javascript ואני אבוא ללמוד Javascript, ההבדל בינינו יהיה מזערי – כי אני לא פיתחתי כלום בעבר ב-Javascript ולא למדתי את השפה. כשאני התחלתי לעבוד בתחום, מערכת הקבצים ברשתות היתה Novell Netware 2.11 ורשתות התקשורת היו מבוססות Token Ring. מבלי להיכנס להסברים על מה זה – נאמר שאף אחד כיום לא משתמש באף טכנולוגיה כזו.

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

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

אשמח אם תוכלו לשתף פוסט זה עם חברים שאתם חושבים שהיי-טק ופיתוח יכול להתאים להם.

יש לך גיבויים למכונות שלך בעננים?

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

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

"As part of using Amazon EC2, you agree that your Amazon EC2 resources may be terminated or replaced due to failure, retirement or other AWS requirement(s). We have no liability whatsoever for any damages, liabilities, losses (including any corruption, deletion, or destruction or loss of data, applications or profits), or any other consequences resulting from the foregoing. "

במילים אחרות: מכונות יכולות להיתקע או להתקלקל וברגע שתפעיל את ה-Instance מחדש, הוא אוטומטית יופעל על מכונה תקינה, אך יחד עם זאת, הדיסק הוירטואלי שלך שרץ על EBS – זה משהו אחר. EBS יכול להתקלקל (אמזון מתחייבים על Five Niners, כלומר 99.999%) ואמזון תעשה את המאמצים לשחזר, אך אם הם לא יצליחו, הם לא יהיו אחראים ל-DATA שאיבדת.

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

אז מה ניתן לעשות? להלן מספר אפשרויות:

  • כל ספק ציבורי מאפשר ליצור Snapshot לדיסקים שנמצאים ב-Instnace. השימוש ב-Snapshot יכול להיות הן לשחזור, והן להמרה ל-Image (אם אתם רוצים ליצור Image חדש ל-Instances חדשים). יצירת ה-Snapshot נעשית "מבחוץ" (בין אם דרך ממשק ה-Web, דרך ה-SDK/CLI, או דרך כלי אוטומציה שתבחרו) ואין צורך ב-Agent כלשהו. ההוראות לבצע זאת ב-AWS נמצאות כאן.
  • Immutable מול Mutable: רוב האנשים שמגיעים מעולם הוירטואליזציה שרצה On Prem ומתחילים להשתמש בעננים ציבוריים – עובדים בשיטה שנקראת Mutable: יש לנו VM, עליו רץ כמעט הכל: האפליקציה, שרת ה-Web, אולי גם שרת SQL וכו' וברוב המקרים ה-DATA נשמר מקומית. בשיטה הזו גם המתודה לשדרג לגרסאות חדשות ולשנות דברים היא די בעייתית (במקרים רבים אפליקציות מצריכות שינויי הגדרות בין גירסה לגירסה, לדוגמא), ואם לא מדובר ב-instance יחיד אלא כמה וכמה – זה נהיה יותר מורכב, והשדרוג לא תמיד מצליח.
    שיטת ה-Immutable היא שיטה הרבה יותר קלה לעבודה: אנחנו מכינים Image Master שאינו כולל DATA, אך כולל את כל ההגדרות שאנחנו צריכים, ובעת ה-Deploy של ה-Image אנחנו נריץ סקריפט שנמצא בתוך ה-Image שיבצע את השינויים וההגדרות האחרונים שאנחנו רוצים (אפשר לדוגמא לכתוב סקריפט קצר של 2-3 שורות שימשוך מ-GIT את הסקריפט שיבצע עדכון הגדרות, לא לעדכן/להתקין חבילות אחרת זה רק יאיט את הזמן עד שהמכונה תהיה זמינה – את זה תעדכנו ב-Master Image). ב-Instance החדש שום דבר לא נשמר מקומית: לוגים עוברים לשרתי עיבוד (Elastic וחבריו), SQL רץ במקום אחר (שרות מנוהל או ממכונה אחרת), קבצים שצריך להנגיש מגיעים מ-EFS או S3, כך שבשרת עצמו שום דבר מהותי לא יכתב, ואם צריך – נוכל למחוק מיידית את ה-Instance ללא נזקים. את ה-Image הזה נוכל לעשות Deploy בכל כמות שנרצה (לא לשכוח לחבר אותם ל-Load Balancer). בשיטה הזו אין צורך לגבות את המכונות, אבל כן כדאי לגבות את ה-DATA שנשמר במקומות אחרים מחוץ ל-Instance.
    למעוניינים, יש בלינק הזה קליפ שמסביר זאת בצורה יותר מוחשית.
  • קונטיינריזציה/אורקסטרציה: עם קונטיינרים, אין שמירה של הדברים, הואיל וכשקונטיינר מפסיק לעבוד, הוא "מת" ולכן עבודה עם קונטיינרים מחייבת עבודה מול אחסון חיצוני. חשוב: את ה-Volume של הקונטיינר (או PV/PVC במקרים של Kubernetes או OpenShift) למפות למקור חיצוני. Kubernetes/OpenShift יודעים לתמוך במגוון מקורות כמו NFS, וגם Docker יודע לדוגמא לתמוך ב-NFS (תמיכה ב-iSCSI ל-Docker – בדרך).

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

קצת על פוליגרף, גופים פיננסיים וגופי בטחון

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כשאין נסיון מספק בתחום

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

כפרילאנסר – החיים מאוד דינמיים ומאוד תובעניים. ככל שאתה מכוון ליותר "גבוה" לפרויקטים והזדמנויות רווחיות – אתה צריך "להשיל" תחומים מסויימים בגלל שהשוק באותם תחומים מוצף בעצמאים שיהיו מוכנים לתת מחיר תחרותי מאוד. לדוגמא: תחזוקת מכונות Windows Desktop או תחזוקת שרתי Windows – יש מספיק בשוק שיציעו מחירים של 70-150 לשעה. אם אני אבקש "מאות" שקלים לשעה, ההצעה תידחה ולכן בדברים כאלו צריך לוותר ולכוון לדברים היותר רווחיים – קונטיינריזציה, עננים ציבוריים, כלי CI/CD, אוטומציה, אינטגרציית לינוקס, מערכות  משובצות, HPC, Scale Out, אחסונים גדולים (מעל פטה) ועוד.

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

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

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

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

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

עוד נקודה לשכירים – להכיר תחומים או דברים מסויימים ברמת ה-Overview וברמת תפעול כלשהי: כשכיר, יש סיכוי שהולך וגודל כל הזמן שתצטרך לעבוד (בין אם ב-IT או ב-Devops) מול ענן ציבורי כלשהו, ורוב החברות עובדות מול ענן ציבורי אחד. יחד עם זאת, יש סיכוי לא קטן שבחברה אחרת שתעבוד, הם עובדים עם ענן ציבורי אחר, ולכן, בזמן שאתה עובד באותה חברה נוכחית, תתחיל להכיר את העננים Azure, GCP, AWS ואם אתה צריך הדרכה אונליין, הנה קישור Referral שיכול לעזור לך להכיר את העננים האחרים, כך שאם ישאלו אותך אם יש לך נסיון ב-AWS לדוגמא, תוכל לענות "כן".

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

פרויקט נימבוס – מחשוב הענן הממשלתי

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

anan

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

  1. אחד הדברים הבולטים לטובה במסמך הוא התייחסות למחשוב ענן כמו שספקי הענן הציבורי מציגים ומוכרים ולא כל מיני "ענני צעצוע" שכל מיני חברות בארץ מציעות/מוכרות. התנאים עצמם ישר פוסלים את אותם "ענני צעצוע" בכך שיש דרישות שלספקים בארץ אין אותם, הן מבחינת הכנסות והן מבחינת Availability Zones (שמשום מה במסמך הם נקראים "Domains"), מיקומים גיאוגרפים וכו' ואף אחד מהספקים בארץ גם לא מציע 500+ שרותים שונים באותו ענן.
  2. אני שמח לראות שבמשרד האוצר מחפשים שהזוכה יקים בעצם Region אחד ובתוכו Availability Zones אולם לעניות דעתי, חשוב שבמשרד יתעקשו על כך שה-AZ יהיו במרחק רב אחד מהשני.
  3. נקודה שלדעתי חסרה במסמך וחשוב שתצוין (ושהמשרד יעמוד על כך) – שה-AZ יהיה מחובר בחיבורי תקשורת מספקי אינטרנט שונים ולא מספק יחיד. רק לפני חודשים ספורים אלפי אתרים נותקו מהאינטרנט עקב "תקלת תקשורת" של ספק אינטרנט מרכזי. האם משרד האוצר רוצה לחוות חוויה כזו?
  4. אם המתמודדים הם בעצם ספקי הענן הציבורי, מומלץ לבקש לדעתי במסמכי המכרז כי הספק הזוכה ייבא וישתמש בציוד שלהם ולא בציוד COTS. הציוד של ספקי הענן שונה לחלוטין מציוד שחברות רוכשות החל ברמת המעבדים, זכרונות, לוחות, אחסון, תשתיות תקשורת וכו' ויש סיבה טובה לכך – ביצועים הרבה יותר גבוהים.
  5. בבקשה, בבקשה – בלי Azure Stack. כתבתי כאן מדוע לא.
  6. נקודה נוספת שאולי כדאי שמשרד האוצר יחשוב לגביה – שה-AZ יהיו מחוץ ל-Data Centers של ספקי האינטרנט שונים במיקומים כמו הגליל ובאר שבע לדוגמא. בחירה במקומות כאלו יכולה לייצר באופן ישיר מספר מקומות עבודה ובאופן עקיף לאורך זמן – יותר ויותר חברות שיעבדו במקומות אלו.

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

  • מיקרוסופט – Azure
  • אמזון – AWS
  • גוגל – GCP
  • אורקל – Oracle Cloud
  • IBM Cloud

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

יש משהו אחד שקצת לא מסתדר לי עם המכרז והפרויקט עצמו. כן, זה בהחלט דבר טוב שמשרד האוצר עושה צעדים להקים פה Region, אבל הבעיה הגדולה ביותר קשורה לשיטות העבודה והפיתוח במשרדי הממשלה השונים ושוחחתי בעבר עם לא מעט עובדים במשרדים הממשלתיים על כך: צריך לשנות מקצה לקצה את כל מתודות העבודה. להתחיל לעבוד מול GIT, לשלב CI/CD, אוטומציה, להוריד כמה שיותר את העבודה עם מכונות וירטואליות ולהתחיל לעבוד מול קונטיינרים ומול שרות/פלטפורמה כמו Kubernetes/OpenShift, לעבוד במתודה של Scale Out, להשתמש ב-Object Storage, להתחיל לעבוד במתודות Serverless אולי, ועוד ועוד – וכל אלו הם דברים שונים ממה שהמשרדים משתמשים כיום. אם משרד האוצר הולך לשלם על Region עם מספר AZ ושיטות העבודה ישארו השיטות הישנות, אז ניצול ה-Region יהיה אחוזים בודדים בלבד, ובכך יווצר בזבוז כספים משווע (ומה לעשות, לא מדובר פה בתשלום חד פעמי אלא חודשי), ולכן אני תוהה אם משרד האוצר מוכן כבר עכשיו לתכנן מהלך הדרגתי לעבור למתודות העבודה החדשות.

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

על שני פרויקטים מוצלחים – ולקחים

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

באותם פרויקטים שהקמתי, היו מספר רב של שרתים שהריצו מערכת DB שהיא Scale Out ובחלק מהשרתים רצות אפליקציות שונות שמשתמשות ב-DB כדי להעביר פנימה והחוצה נתונים לשם ניתוח. בנוסף רצו מכונות VM שונות לתשתית שנתנו שרותים שונים על מערכות הפעלה שונות.

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

  • מיישם הפרויקט – צריך להשתתף בפרויקט עוד בשלבים המוקדמים: במקרים רבים מתבצעת התקשרות עם איש מקצוע להקמת תשתית/פתרון אחרי שנבחרה חומרה שתריץ את הדברים. ההחלטות לגבי החומרה מתקבלות ע"י האיש המקצועי בחברה או שמוגשות המלצות ע"י אנשי השיווק של יצרן החומרה ואז אחד הקודקודים בחברה מחליט אם לרכוש או לא ומה לשנות (פקטור של מחיר וכו'). אני מבין את התהליך, אולם לעיתים יש דברים שניתן לשנות מבלי להרים את תקרת המחיר – שנותנים ביצועים יותר גבוהים או שרידות גבוהה, ולכן כדאי לשכור את האיש מקצוע לפני קבלת ההחלטות לגבי הברזלים.
  • תוכנות בקוד פתוח מסחרי או רגיל: אחת הנקודות שחשוב לתת עליה את הדעת עוד בשלב החישובים הכספיים, היא ההחלטה אם במערכת החדשה יוטמע פתרון מבוסס קוד פתוח חינמי שמורידים מהאינטרנט, או שרוכשים פתרון קוד פתוח עם תמיכה מסחרית מיצרן התוכנה. דוגמאות לכך לא חסר: OpenStack, Ceph, GlusterFS, RHV ועוד ועוד. אפשר כמובן להוריד מהאינטרנט ולהתקין בלי לשלם שקל, אולם מה קורה כאשר המערכת הזו תהיה פרודקשן ויש תקלה באפליקציה המרכזית? במקרים כמו OpenStack או Ceph לדוגמא, כמות האנשים בארץ שיכולים "לחטט" בקוד ולתקן באגים מאוד קטנה וללא תמיכה מסחרית רשמית – מערכת פרודקשן כזו יכולה להיות מושבתת למשך ימים, ולכן אם מדובר במערכת פרודקשן שתיצור הכנסות – מומלץ לבחור בדרך המסחרית. זה יותר יקר מבחינה כספית – אבל זה נותן שקט ומענה לבעיות בטווח הארוך.
  • כמה שפחות תלויות: לא משנה מי הפרילאנסר או החברה שמקימה עבורכם את הפתרון, חשוב לכלול כמות שעות מסויימת שתוקדש לתיעוד והדרכה של הצוות בחברה, ובמיוחד Troubleshooting. אם לדוגמא המערכת מנותקת מהאינטרנט ויש תקלה, הצוות בחברה (בהינתן הידע) יכול לטפל בתקלה הרבה יותר מהר מאשר פתיחת טיקט, המתנה, ולאחר מכן עבודה בשיטה של copy/paste מהטיקט למכונות.
  • חיבור אינטרנט למערכת: לא מעט לקוחות מבקשים להקים מערכת שבמצב פרודקשן תהיה מנותקת לחלוטין מהאינטרנט. זהו דבר מובן ומקובל, אבל עדיין חשוב לבנות חיבור אינטרנט (ישיר או עקיף, ע"י הקמת Proxy או VPN לדוגמא) לעדכונים ותיקונים חשובים. ראיתי לא מעט מקרים בהם אנשים הורידו קבצי RPM וחשבו שהם יוכלו להתקין אותם ישירות בפרודקשן מדיסק און קי, ואז הם ראו דרישה מהמערכת לערימת קבצי RPM נוספים כתלויות. על מנת לאבטח את המערכת, חיבור כזה צריך להיות מופעל ידנית כמובן כך שלא ניתן להיכנס אוטומטית מרחוק.
  • דאגו ל-Gateway: נניח שיש לי 50 שרתים, כולם תחת אותו Class של כתובות (נניח 24/). מטבע הדברים יספיק שרת DNS פנימי פשוט כדי שהמכונות יכולות לשוחח בינן לבין עצמן ואין צורך בשום Gateway, אבל הבעיה מתחילה בכך שאם נניח מכונות 3,8,10,14,30 צריכות עכשיו להתחבר לאינטרנט להוריד דברים מסוימים (ואין Proxy), בלי Gateway זה יהיה בעייתי, ולכן מומלץ שאפילו ה-Switch המקומי ישמש כ-Gateway מקומי.
  • לוח זמנים – בחיים ניתן לשלוט על דברים רבים, אך יש דברים שאין עליהם שליטה. פרויקט אמור להימסר ללקוח בעוד חודשיים אך עדין לא מצאו איש מקצוע בתחום מסוים. יש צורך בהחלפת רכיב מסוים בכל השרתים. יש צורך בשינוי דחוף בארכיטקטורה. הלקוח לא מרוצה מהביצועים – קחו טווח זמן יותר ארוך ממה שאתם חושבים שתצטרכו.

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

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

לפני מס' ימים קראתי את הפוסט של ידידי רן-בר זיק על המכתב שנשלח ע"י עו"ד מטעם חברת 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 שלא ינטשו לכיוון מערכת אחרת. זה צעד מעניין ואני שמח שמיקרוסופט בוחרת להשקיע בפתרון במקום להתכחש לדברים שקורים בשטח.