תחליף ל-vSphere?

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

אז לפני שאענה על השאלה, חשוב למקד את הנושא: vSphere זו משפחה של מוצרים, לא כולם מתחילים עם "vSphere": כך לדוגמא יש את vSan, Orchestrator, vCenter, vRealize ועוד מוצרים רבים שמתחברים אל תשתית ה-vSphere.

האם יש כלי קוד פתוח שיכול להחליף את אלו ואחרים כ-Drop In Replacement ללא צורך בעבודת הקמה? התשובה, לצערי, היא לא. לא OpenStack ולא שום כלי אחר יכול להחליף בצורה של לקחת ערימת ברזלים, להתקין, להריץ איזה שהוא Coverter שימיר את הכל לתשתית החדשה ולאחר כמה שעות תוכלו להפעיל את הכל מאיזה מוצר אחר.

מה שכן, המוצרים שכן קיימים כיום הוא RHEV של רד-האט (בגירסה המסחרית) ו-oVirt שהוא כלי קוד פתוח שעליו מתבסס בעצם RHEV. עם הכלי הזה – יש אפשרות להמיר מערכת כמו vSphere Essentials (ללא כל האוטומוציה של Orchestrator, בלי דברים כמו vCloud Air ואחרים) למערכת כמו oVirt/RHEV.

אבל לפני שאתם יוצרים קשר עם חברה או פרילאנסר לתאם פיילוט להעביר את התשתית ESXI שלכם ל-oVirt/RHEV, אני ממליץ לקרוא את הדברים הבאים..

מבחינת ESXI, ב-VMWare עשו את הכל על מנת שחברה לא תצטרך להחזיק איש לינוקס (או איש עם ידע של לינוקס) בחברה בשביל לתפעל את המערכת. גם כשנכנסים ב-SSH לשרת ESXI, הידע שצריך בלינוקס/יוניקס הוא די מינימלי ולחברה שרוב מוחלט של התשתיות שלה מבוססות מיקרוסופט, VMWare יצרו את PowerCLI שעובד עם Power Shell כך שאפשר לעשות כמעט הכל מבלי לדעת לינוקס. גם הקורסים של VMWare לא ממש מתמקדים על לינוקס אלא מתמקדים במוצרים של VMWare עם נגיעות בדברים חיצוניים כמו רשת, סטורג' בצורה כללית, כך שמי שרוצה לדוגמא להרים את NSX, עדיף שידע רשתות בצורה רצינית (CCNA ומעלה), כי מהקמה של NSX בלי ידע רציני בתקשורת – לא מגיעים רחוק.

בעולם ה-RHEV/oVirt לעומת זאת, הצורך באיש לינוקס להקמה של הדברים הוא קריטי. עם הכלים הללו לדוגמא אין כלי אוטומציה יעודי כמו שיש ל-VMWare, מכיוון שברד-האט (לדוגמא) מבינים שאם אתה רוצה אוטומציה, אתה עושה את זה עם כלי אוטומציה כמו Chef או Puppet או לדוגמא אם אתה עובד עם Ansible אז יש לך מודול ל-oVirt כדי להקים, לעצור, להפעיל מכונות וישנם מודולים אחרים שעוזרים בדברים אחרים הקשורים לוירטואליזציה. השוני הגדול בין רד-האט ל-VMWare הוא שבזמן ש-VMWare משלבים עוד ועוד כלים כחלק אינטגרלי מ-vSphere/vCenter, ברד-האט עובדים הפוך: אתה יכול לעשות עם הפתרון החלופי שלהם ל-vCenter (מה שנקרא אצלם: Hosted Engine) והשאר יכולים להיות כלים שונים עם ממשק RESTful וכאלו שיש להם Plugins אל ה-Hosted Engine, כמו במקרים של Neutron, Cinder וכו'. אתה יכול לעבוד עם ה-GUI או עם virsh או להשתמש בספריית libvirt ולעשות את הכל בעצמך באיזו שפה שתרצה.

אז לקחת עכשיו כמה ברזלים ולהרים את oVirt? זה תלוי. באופן עקרוני ההמלצה של רד-האט היא להקים Nodes ועליהם להקים את Hosted-Engine ב-Clusters. ישנם 2 גרסאות של oVirt Node שההבדל המהותי ביניהם זה שגירסה אחת משתמשת בממשק "קלאסי" ובגירסה השניה התקנת ה-Node היא כבר עם ממשק שיותר מזכיר התקנת CentOS/RHEL ויש כבר ממשק גרפי שמשתמש בכלי Cockpit כדי לתת כלים מבוססי Web הן כדי לנהל את ה-Node והן כדי לתת ממשק אחר ויותר מודרני (בהמשך) לניהול ה-Engine.

מי שחושב להוריד את ה-ISO ולהתחיל מיד לעבוד, צפוי לכמה "הפתעות" לא כל כך נעימות כרגע.

ovirt-node-oldovirt-node-newנסיון התקנה של ה-ISO בגירסה ה"קלאסית" על מכונה אמיתית נותן את התמונה משמאל (לחצו להגדלה) ואילו נסיון התקנה של הגירסה החדשה נותן את התמונה מימין (לחצו להגדלה).

ב-2 המקרים, ניתן לתקן את תקלות ההתקנה בשימוש Kickstart חיצוני או באמצעות הקמת ISO חדש תוך שימוש בהגדרות מהפצות Fedora אחרות, אבל שוב – אלו דברים שמצריכים איש לינוקס מקצועי שיודע לטפל בדברים האלו ולהגדיר את כל השרותים שצריך ל-oVirt ושאר החלקים ב-Hosted Engine. לאחר הקמה של הדברים וערימת ההגדרות (שבהמשך תהיה כבר אוטומטית) המערכת די יציבה ואפשר להתחבר ל-vCenter ושרתי ESXI כדי להמיר מכונות VM אל המערכת החדשה (בזמן ההמרה המערכת משנה את הגדרות הדרייברים, כך ש-VM שעובר, מוכן לשימוש לאחר ההמרה) ואפשר להתחיל לעבוד עם המערכת החדשה.

מבחינת oVirt/RHEV – העתיד הוא דווקא עתיד טוב. המערכת עוברת ממצב של שימוש ב-JAVA ל-Node.JS, היא תהיה הרבה יותר אינטרקטיבית, היא תדע להתמודד עם רשתות מאוד מורכבות, כבר כרגע היא יודעת להתחבר ל-iSCSI, NFS וגם Infiniband (אם כי יש כמה Gotchas בנוגע ל-Infiniband). היא תומכת כבר עכשיו ב-Clusters, עם Live Migration, עם HA וכו'. יחד עם זאת, כדאי לזכור שחלק מהמושגים שונים כי הטכנולוגיה לגמרי שונה מ-VMWare ולכן אם אתם מחליטים לעשות פיילוט, ודאו כי הפרויקט כולל הדרכה, כי הדברים שונים, אפילו ברמה של ISO ל-VM השונים (לא ממש מסכים עם השיטה שרד-האט בחרו, אבל זו החלטה שלהם). האם לחכות לגירסה העתידית? אין ממש צורך בכך, גם הגירסה הנוכחית עובדת, ועובדת טוב (עבדכם הנאמן בדיוק ממיר מערכת מ-ESXI-6 ל-oVirt עם 75 מכונות VM פה בבית), רק קחו בחשבון שהקמה של מערכת כזו אינה עניין של שעתיים שלוש ויכולה לקחת מספר ימים ואם אין לכם אנשי לינוקס, מומלץ לסגור על בנק שעות לתמיכה ואולי הדרכה לאנשיכם.

כמה מילים על הקשחת שרתי לינוקס

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

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

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

ההמלצה הכי טובה להקשחה, במידה והמכונות הן VM, היא לא להקשיח מכונה קיימת, אלא להתחיל מאפס, עם kickstart (מכונות מבוססות RedHat/CentOS/Fedora9) או Kickstart/Preseed/FAI (מכונות מבוססות Debian/Ubuntu ונגזרות שלהן). גם בהתקנות פשוטות של CentOS/RedHat לדוגמא יש ערימה של חבילות שאין בהן צורך והן יכולות להיות בעייתיות מבחינת אבטחת מידע (CUPS, YP, ועוד. NMAP הוא כלי מעולה כדי לגלות שרותים שרצים בתוך המכונה ושאינכם זקוקים להן) כך שכדאי לבנות את קובץ האוטומציה ולהתקין דרכו את ה-VM כך שהמכונה תהיה נקיה, קטנה ומאובטחת.

אחד הדברים שכדאי וצריך לעשות על מנת להקשיח את המכונות (ואפשר להכניס את זה לתוך ה-kickstart) הוא שימוש ב-CIS Benchmarks. ה-Benchmark (שקיים למערכות הפעלה ואפליקציות שונות) נותן הדרכה כללית כיצד להקשיח את מערכת ההפעלה שלכם. השימוש ב-CIS נפוץ מאוד בבנקים, מוסדות גדולים ואחרים וניתן ליישם אותו על מערכות חדשות (דרך kickstart) או דרך מערכות אוטומציה כמו Puppet, Chef, Ansible וכו'. אפשר כמובן להשתמש ב-CIS כדי ליישם על מערכות קיימות, ומומלץ לרכוש את CIS-CAT כדי לבחון את ההקשחות.

שילוב של SELinux, חוקי חומת אש ומימוש CIS Benchmark יכול לסייע רבות בהקשחת מכונות (אם כי מימוש שלושת הדברים אינו מבטיח הקשחה מלאה).

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

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

קצת על מתקפות OpIsrael ומה ניתן לעשות – ובזול

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

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

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

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

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

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

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

מבחינת מחיר – ישנם מספר חבילות. ישנה חבילה חינמית שיכולה לסייע לאתרים פשוטים להימנע מהתקפות, אך מומלץ להשקיע בחבילת ה-Pro (שעולה 20$) שיכולה למנוע תקיפות נגד כל מיני תוספים שקיימים באתר. לאתרים רציניים יותר (שמכניסים כסף) אני ממליץ ללכת על חבילת ה-Business שיודעת למנוע DDoS ועוד כמה סוגי התקפות.

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

cloudflare-dns

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

אם תסתכלו בתמונה לעיל, תוכלו לראות 2 חיצים אדומים שמצביעים על 2 עננים. הסימון הזה אומר שמבחינה חיצונית, כתובת ה-IP שלכם תוחבא ומה שיוצג החוצה זו כתובת IP של CloudFlare (שימו לב שיש ללחוץ על אייקון הענן שיהפך לכתום אחרת כתובת ה-IP שלכם האמיתית תוצג לעולם. כמובן שכדי לגשת לאתרכם דרך SSH או RDP, כדאי ליצור בנפרד רשומה נוספת עם שם לא צפוי או לרשום את זה אצלכם בחברה ב-DNS פנימי או קבצי hosts), כך שמי שינסה לתקוף ב-DDoS את .. CloudFlare, ו-CloudFlare יודעים היטב להתמודד עם DDoS (עד רמה מסויימת, תלוי בחבילה שלך. בחבילת ה-Business אתה לא תקבל DDoS – ויש ל-CloudFlare רוחב פס של כמה טרהבייט). אם נצרף את הגנת ה-DDoS להגנת ה-WAF (ר"ת Web Application Firewall) ועוד כמה הגנות שהם נותנים, אתרכם יהיה די מוגן.

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

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

מבחינת חברות גדולות (חברות ביטוח, בנקים וכו') שצריכות לתת ללקוחותיהם אתרי אינטרנט עם מידע – גם כאן CDN (ללא EDGE ישראלי או עם הגדרות שלא יגיע ל-Edge ישראלי, כך שאם יש התקפה היא לא מגיעה לישראל) יכול לסייע. נכון, הרגולטור לא מאפשר אחסון אתרים/שרתים בחו"ל לעסקים מסויימים, אבל התוכן שאינו מצריך Log In (מה שנקרא Pre Login Content) כבר זמין לכל והתוכן עצמו (והשרתים כמובן) נשאר בארץ ורק עובר דרך CDN, וההתקפות DDoS מבוצעות בד"כ על אתרים עם התוכן הזה, לא על התכנים לאחר Log in, כלומר מה שמגיע ל-CDN הוא תוכן די סטטי שכבר זמין, כך שגם חברות יכולות לקחת את אותו מסלול ובכך בעצם למנוע את הצורך לחסום תקשורת לחו"ל.

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

מערכות משובצות: ללכת באופן מסודר

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

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

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

הדבר הראשון שיש למצוא הוא "מה צריך כח?". לדוגמא – אם הקופסא תשמש כנתב, אז רכיבי הרשת צריכים יחס מיוחד ואסור לסמוך על מה שיצרן ה-SoC נותן בצ'יפ. צריכים לטפל בתעבורה של 1 ג'יגהביט לדוגמא? כדאי וצריך לצייד את הלוח בצ'יפ רשת יעודי (עם שאר החלקים). דוגמא אחרת: צריכים ראיה ממוחשבת שתדע למצוא עצמים במהירות פריימים גבוה? אז אתם צריכים GPU חזק שמגיע ברוב המקרים יחד עם CPU חזק (כדאי לשים לב: במקרים כמו של מעבדי אינטל, לדוגמא סידרת Atom X3/X5/X7 – אתם תקבלו מעבד בהחלט חזק בהשוואה למעבדי ARM בינוניים, אבל בכל מה שקשור ל-GPU, כל מעבד ARM בינוני עם Mali 500 ומעלה עוקף אותו). עוד דוגמא היא עניין המצלמות: מצלמות סיניות פשוטות לא יעשו את העבודה, ומצלמות שמוציאות YUV (ושאר פורמטים קרובים) רק יקטינו את כמות הפריימים שתוכלו לעבד עם תוכנות ראיה ממוחשבת.

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

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

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

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

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

גילוי נאות
כותב שורות אלו נותן שרותי אינטגרציה למערכות משובצות

כשמחפשים פרילאנסר לפרויקט

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

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

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

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

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

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

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

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

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

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

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

קישורים:

  1. XPLACE – אחד האתרים הגדולים בארץ למצוא פרילאנסרים ולפרסם פרויקטים (אגב, פרסום הפרויקט הוא בחינם) – מאוד פופולרי
  2. Freelancerim – עוד אתר בתחום בארץ
  3. vlancer
  4. Find a freelancer
  5. פורום "הייטק פרילאנסרים" בפייסבוק

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

על Ransomware והתגוננות מפניהם

cryptolockerעדכון 1: כשהכופרה מעיפה את VSS (בסוף הפוסט)

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

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

כל הדברים שכתבתי היו נכונים עד שלשום. מאז קרו 2 דברים חמורים:

  1. פריצה חמורה אירעה בשרתי צד ג' שנותנים שרותי פרסום לאתרים גדולים ודרך פירצה זו הופצו סקריפטים שרצים בדפדפן שמחפשים כל סוג פריצה שקיים לדפדפנים שונים, ל-Flash, ל-Java ו-JS ושאר דרכים – כדי להוריד אוטומטית Ransomware למשתמש וכדי לגרום לו להריץ אותו. כל מה שהמשתמש היה צריך לעשות זה פשוט לגלוש לאתרים הגדולים (כמו New York Times, BBC, AOL, MSN ועוד) והסקריפט שהיה נטען לדפדפן המשתמש היה כבר רץ ומחפש פירצה.
  2. עד כה רוב תוכנות ה-Ransomware היו משתמשות במפתח פרטי קבוע שהיה חלק מחבילת ה-Ransomware, ולאחר זמן מה יצרני האנטיוירוס ידעו לזהות את המפתח ולהציע ללקוחותיהם דרך לחילוץ הקבצים מבלי לשלם כופר. לאחרונה הדבר שונה ובחלק מתוכנות ה-Ransomware המפתח הפרטי נוצר כל פעם מחדש ומועלה מיד לשרת של התוקף ונמחק מהמחשב, כך שלא ניתן אם הותקן Ransomware כזה לחלץ את הקבצים משום שמדובר במפתח 256 ביט שכיום עדיין אף אחד לא פיצח (אולי ה-NSA הצליחו אבל הם לא מפרסמים כלום בנידון כמובן), כך שמחשב פרטי או מחשב בעסק שחוטף Ransomware כזה, הדרך היחידה לחלץ את המידע – היא לשלם את הכופר לתוקף..

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

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

ניתן לעומת זאת להשתמש בשיטה ותיקה שמיקרוסופט המציאה ממזמן (והורידה חלק מהפונקציונאליות בחלונות 8/8.1 אך החזירה ב-10) והיא ה-Volume Shadow Copy (בקיצור: VSS). בשיטה זו המערכת שומרת Snapshot על כל הקבצים המקומיים (לא ב-XP, שם יש שמירה על קבצי מערכת, לא על תכנים כמו מסמכים וכו')

במידה ובמחשבים מותקנים דיסקים קשיחים, ניתן ליצור Partition נוסף שעליו ישבו ה-snapshots (כדאי לעיין במאמר הזה כדי לבצע את הדברים) או שניתן לבצע Snapshot למערכת NAS (על כך בהמשך) וכך ניתן גם לשחזר קבצים את Snapshot של ה-Volume (עוד פרטים כיצד לבצע mount ל-snapshots ולחלץ מידע – ניתן לקרוא כאן).

אם התכנים נשמרים ב-SAN או NAS, כדאי להפעיל את תכונת ה-Snapshot ב-Storage עצמו (חפשו Volume shadow או VSS) ואז את השחזור ניתן לבצע ישירות מתחנת המשתמש (או ב-Storage, לפי הצרכים). יש לוודא ששרות ה-VSS נראה בתחנת המשתמש (בתחנות מבוססות חלונות 7 ובגרסאות חלונות 8 PRO וכו' אפשר להשתמש בכלי כמו Shadow Explorer לשם כך).

שרתי לינוקס שמשרתים תחנות Windows דרך SAMBA: אם הנכם משתמשים ב-LVM אז תוכלו לבצע Snapshots ולשקף אותם דרך smb.conf בשרת כך שניתן יהיה לשחזר קבצים. ניתן לראות איך לבצע זאת כאן. אם הינכם משתמשים בשרותי ZFS על לינוקס/BSD או סולאריס, אין שום בעיה להשתמש ב-Snapshots שמיוצרים ע"י ZFS ל-SAMBA ואפשר לקחת סקריפט מוכן עם הוראות בקישור כאן.

לסיכום: נזקי כופרה יכולים ליצור כאב ראש לא קטן, במיוחד שאין גיבוי עדכני, אז כמובן שצריך לוודא שגיבויים מבוצעים תדיר (ונבדקים תדיר – הדבר האחרון שאתם צריכים זה גיבוי לא קריא בעת חרום). מומלץ לבדוק ולהשתמש בשרות VSS. נכון, השרות די מוגבל (לא ניתן לבצע את גיבוי ה-VSS לרשת) אבל הוא יכול לשמש כפתרון זול על מנת למגר נזק מכופרות. אם אתם מציעים למשתמשים אחסון תוכן בכונני רשת, ודאו כי ל-storage יש snapshots שניתן לגשת אליהם דרך אפשרות ה-Restore to Previous Versions (אם אין, אפשר לתת למשתמשים Shadow Explorer או לכתוב סקריפט ב-PS שיאפשר שחזור).

כשהכופרה מעיפה את ה-VSS: כפי שציין הגולש גיא אדרי בפורום, רוב הכופרות עוצרות את שרות ה-VSS ומוחקות גיבויים (בהנחה וביטלתם את ה-UAC). במקרים כאלו מאוד מומלץ לחשוב לעבור לכונני רשת שיאחסנו את התכנים (לא את האפליקציות וכמובן לא את ה-SWAP). במידה ואין תקציב לסטורג' לדבר כזה, ניתן לבנות סטורג' זול שיארח כונני רשת (יש לדאוג ל-2 כונני SSD ב-RAID-1 שישמשו כ-Cache קריאה/כתיבה ל-RAID פנימי שיורכבי מדיסקים SATA או NL-SAS). אותו שרת יכול להריץ שרות SAMBA, להתחבר ל-AD ועל השרת הזה ניתן ליצור כונני רשת ולבצע Snapshots לכונני הרשת עם LVM או עם ZFS. במקרה התקפה של כופרה, היא לא יכולה למחוק את ה-Snapshots של כונני הרשת, ניתן גם לבצע Snapshots בתדירות גבוהה (עם ZFS בלינוקס או סולאריס או BSD אפשר גם כל 10-15 דקות וניתן להשאיר כמות גדולה של Snapshots מבלי לחשוש לבעיות ביצועים), כך שבסופו של דבר אם כופרה תוקפת, אפשר לשחזר את המחשב מ-IMAGE, למפות את כונן הרשת, ולשחזר מה-snapshot את כל התוכן אל ה-share של כונן הרשת.

טיפים לפרויקטים למערכות משובצות

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

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

נתחיל עם המעבדים: אם יש משהו אחד שאני רואה בחברות רבות בשימוש – זה לוחות מבוססים I.MX של NXP (לשעבר Freescale זכרונה לברכה). מעבד זה הוא מעבד כלל לא רע והוא מעולה בפתרונות לוידאו, אך כיום ישנם לא מעט פתרונות מחברות מתחרות שונות שלא רק נותנות את מה ש-I.MX (כולל דור אחרון) נותנים, הם נותנים גם ביצועים יותר טובים וגם מחיר יותר טוב (תלוי כמובן בכמות המוזמנת). מעבדים של סמסונג, קוואלקום, Rockchip, Texas Instruments, Amologic ואחרות מציעות מעבדי ARM שונים בין אם מדובר ב-32 או 64 ביט, עם תמיכה לציודים שונים, כולל התקנים חדשים (כמו פתרונות Wifi בסטנדרטים האחרונים).

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

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

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

אבל כיום ישנה דרך אחרת שכדאי לתת את הדעת עליה: אם אתם מכינים את המוצר שלכם, סביר להניח שניסיתם אותו בסביבת לינוקס על PC בשלב ה-PoC, וזה מעולה, אבל במקום להתחיל לעבוד על Yocto, אני ממליץ ללכת בדרך אחרת: לרוב המעבדים המודרניים (מבוססי ARM) יש היום גירסת לינוקס כמו אובונטו שקומפלה לאותו מעבד (אם אין, אפשר לבנות עבורכם. צרו קשר). קחו את ה-IMAGE הזה, התקינו אותו על כרטיס מיקרו SD (לפחות Class 10 או U1) והריצו את הלינוקס הזה על הלוח ואז התקינו את מוצרכם על אותו אובונטו שרץ על ה-ARM. זה יתן לכם מושג כללי איך המוצר שלכם רץ על מערכת משובצת. יכול להיות שזה יהיה קצת יותר איטי מבניה מצומצמת (עם Yocto ועל השאר תיכף ארחיב) – אבל זה יכול לתת לכם מושג אם זה רץ ואיך, ולמפתחים זה יכול לעשות את החיים יותר קלים אם הם אינם מכירים לינוקס לעומק בצורה מעולה – כי זה נראה בדיוק כמו דסקטופ לינוקס.

אחרי שהמוצר שלכם רץ על אובונטו מבוסס ARM – יגיע הזמן להתחיל לבנות את ה-IMAGE שאותו תתקינו על ה-eMMC שנמצא על הלוח. כאן מומלץ בשלב ראשון אם אתם עדיין משתמשים ב-LTIB – לצאת לגמרי מהכלי הזה (שוב, הוא מת). אם אתם משתמשים ב-Yocto לבנות Image (עם או בלי ה-BSP של היצרן) הגיע הזמן גם לבדוק חלק נוסף שנקרא Open Embedded – כיום שתיהם משולבים והיתרון הגדול של OE הוא כמות נוספת (ולעיתים נחוצה) של "מתכונים" המאפשרים הוספת חבילות חדשות בעת יצירת ה-Image, שלא לדבר על היתרון הגדול של הכלי smart שנמצא ב-Yocto שמאפשר לכם לבנות עדכונים חלקיים (הן כ-RPM או APT או IPK או OPKG) כך שכשמוצאים חור אבטחה באחת מהחבילות, סקריפט פשוט בתוך המערכת המשובצת שאתם בונים יכול להוריד מהשרתים שלכם עדכון חבילה ספציפית ושימוש ב-smart יכול להתקין את החבילה – וכך אין צורך להוציא IMAGE שלם בגלל חור אבטחה.

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

עוד כלי שכדאי להכיר (ולהפתעתי עוד לא פגשתי חברות שמשתמשות בו) זה Docker לבניית Images. מדוע? כשמריצים Yocto, אין אפשרות להריץ מספר סשנים של Bakebit. לעומת זאת, עם טכנולוגיית קונטיינרים כמו Docker אפשר בהחלט להקים כמה קונטיינרים ולהריץ בכל אחד מהם Bakebit, זה יכול מאוד לסייע אם מקמפלים קוד לכמה מעבדים או לכמה מטרות (Targets) שונות. יתרון נוסף של Docker זה שהכל רץ במהירות טבעית ויש אפשרות מובנית לשיתוף תיקיות (כמו תיקיית Cache ל-Yocto. אגב, טיפ קטן לאלו שצריכים לעבוד המון עם Yocto – להריץ bitbake world בפעם הראשונה, עדיף לעשות זאת בסופ"ש או בלילה לפני שיוצאים – וכך יהיה לכם Cache שיעזור "לאפות" דברים יותר מהר).

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

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

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

כמה מילים על פרסום בעיתון

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

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

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

pconתחקיר מס' 1271 שיוצא היום למנויי PCON ("הוירטואליזציה פורצת ומתפשטת"), מכיל את הטקסט שבתמונה משמאל.

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

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

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

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

מדוע? הסיבה מחולקת למספר נקודות:

  1. אף ספק ענן ציבורי עוד לא הקים "אזור" (Region) בישראל (ולמען האמת לא נראה לי שזה גם יקרה בקרוב – אנחנו פשוט קטנים מדי בשבילם) מה שאומר שהמיקום הכי קרוב גיאוגרפית לשרתים יהיה בבריטניה או באירופה (אמסטרדם, פרנקפורט) ובהתחשב ב-Latency הנודע לשמצה של הקווים מישראל לחו"ל, מדובר על תוספת LAG המוערכת בין 70-140 מילישניות. ספרו את זה למנמ"ר של Corporate ממוצע ותראו איך הוא מיד מבטל אפילו מחשבות על מעבר לענן ציבורי כזה.
  2. מחיר מטורף: אם ניקח Corporate ממוצע שיש בו כמה מאות VM וננסה איכשהו להעביר אותם כמו שהם לענן ציבורי, החשבונית הראשונה שתתקבל תגרום לצעקות היסטריות בחברה, ואת זה אני יכול להבטיח. שום ענן ציבורי אינו בנוי כעוד חברת Hosting שמוכרת לרוב שרתי VPS או משכירה שרתים. בשרותי ענן העניין הוא להשתמש בשרותים שאותו ספק ענן מציע – בין אם זה DNS, SQL, או עוד כמה מאות שרותים נוספים, וה-VM (או ה-Compute) הוא עוד אחד מהשירותים וכשמשתמשים בשרותים שהספק מציע, ואז אתה מגלה שבמקרים רבים אתה צריך VM יותר קטן או שאתה יכול לפזר בין כמה שרותי VM קטנים או שאתה יכול לוותר על חלק מה-VM, כך שבמציאות אי אפשר סתם כך להעביר כמה מאות VM ולמכור את השרתים הפיזיים שיש בחברה מבלי לשלם מחיר מאוד גבוה.
  3. פחדים ורגולציות: קשה מאוד לחברות לקבל שכל ה-DATA הקריטי (ובמקרים רבים כולל סודות מסחריים ותכנים שלא אמורים לצאת החוצה כמו מיילים, פרזנטציות, קוד וכו') יושב באיזה ענן ציבורי מעבר לים, כך שהם חוששים. בנוסף, מוסדות שונים אינם יכולים להוציא DATA מחוץ לישראל עקב הסכמים ואיסורים שונים, כך שמבחינתם כל עניין המעבר הוא No Go.

ישנה שמרנות ב-Corporate לאמץ טכנולוגיות שאינן בדיוק Mainstream. כך לדוגמא כמות החברות שאימצו את OpenStack בארץ אינה גדולה למרות שזו פלטפורמה שיכולה להיות "מתחרה" או משלימה עם פלטפורמת הוירטואליזציה שיש ב-Corporate. ל-OpenStack אין בעיה להציע שרות Compute לדוגמא משלו (KVM, XEN) אבל אין לו בעיה לעבוד עם VMWare או Hyper-V שנמצאים בחברה, הכל תלוי בתכנון ובמימוש שיעשה. אותו דבר בכל מה שקשור לרשתות התקשורת בחברה (עניין סופר רגיש ב-Corporate) – אפשר לשלב עם תשתית התקשורת ואפשר גם להתחיל לחשוב לעבור ל-NFV עם OpenStack.  (ואם חברה צריכה הפניות או יעוץ בנושא – אפשר ליצור קשר. יש לא מעט גורמים שנותנים שרותי יעוץ, הטמעה, תכנון וכו').

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

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

כמה מילים על מחירי פרילאנס בישראל

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

אז תרשו לי לאמר כמה מילים על כך…

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

בניגוד למה שרבים חושבים (שפרילאנסרים ישראליים יקרנים) – המצב אינו תמיד כך. הכל תלוי מה הלקוח מחפש. אם לדוגמא הלקוח מחפש שמישהו ינהל לו את שרת ה-Windows שלו ולא אכפת לו שאותו אחד שנותן לו את השרות אין לו שנות נסיון רבות – הוא יכול להשיג לעצמו פרילאנסר לשרות שוטף במחיר של 20-35$ לשעה פה בארץ. אותו דבר לגבי ניהול שרת לינוקס (שוב, כל עוד הלקוח אינו דורש נסיון עשיר) – הוא יכול להשיג פרילאנסר כזה במחיר של 30-45$ לערך, ומי שלא מאמין – מוזמן לפתוח פרויקט ב-XPLACE ולראות אלו הצעות זורמות אליו (כל עוד הוא מגדיר שהנסיון לא חשוב כל כך לו).

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

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

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

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

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

עבודה כ-Devops

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

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

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

שני הדברים שהכי קובעים בקבלת מועמד לעבודה הם ידע ונסיון. כשאדם לומד מ-ספר או קורס, יהיה עדיין חסר לו בין 50-90% מהידע שחברה צריכה. כך לדוגמא מבחינת Troubleshooting – רוב הקורסים בקושי נוגעים בנושא (וברוב עבודות הסיסטם הזמן שנשרף הוא על תקלות, בין אם זה AD שעושה צרות, SQL שעובד לאט, תקשורת איטית, תקלות ב-1001 שרותים ואפליקציות וכו' – ובלינוקס זה יכול להיות תקלות של ביצועי שרותים, שרת שלא עולה, הרשאות לא נכונות, Segfault של אפליקציות ועוד המון המון סוגי תקלות). בקורסים אולי מלמדים אותך איך להקים מערכות ושירותים – אבל בקושי נוגעים ב-Troubleshooting, ולכן חשוב לבדוק כמה שנות נסיון אמיתיות יש למועמד.

בתחום הסיסטם תמיד כדאי שיהיה לך נסיון בשפת סקריפטים כלשהי. בעולם המיקרוסופט כדאי מאוד שיהיה לך נסיון ב-Powershell וגם ב-Batch. בלינוקס – כדאי מאוד שיהיה לך נסיון לפחות ב-BASH ועדיף גם נסיון ב-Python או PHP, כלומר ידע ונסיון בשפת סקריפטים – חובה. ידע בשפת תכנות אחרות – זה פלוס.

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

כמה רחבה? בניגוד לאיש סיסטם, איש Devops הוא בעצם ה"מכתיב" בכל התחומים שקשורים החל משרתים ועד לפיתוח. כך לדוגמא אם איש סיסטם הכיר Puppet לאוטומציה, איש Devops טוב יצטרך להכיר גם Chef וגם Ansible. הוא לא חייב להכיר אותם עד רמת הבורג, אבל צריך שיהיה לו ידע בהרמה לדוגמא של 2 שרתים, "חיבור" למערכת אוטומציה והתקנת שרות כלשהו, לדוגמא. עניין אחר הוא בשינוי מתודת פיתוח אפליקציות של החברה (במיוחד של חברות שנותנות שרותי SaaS לדוגמא) – בעבר חברות היו מפתחות גירסה 1 ואחר כך היו מתחילים לעבוד על גירסה 1.1 או 2. כיום חברות רבות עוברות לשיטה שבה הפיתוח הוא מתמשך ו"נזרק" מיד לפרודקשן לאחר שהוא מתקמפל ועובר סט בדיקות אוטומטי (מה שנקרא CI או Continuous Integration) ובשביל זה קיימים כלים כמו Jenkins. מי שצריך להרים מערכת CI, לכתוב לה סקריפטים, לכתוב בדיקות וכו' – הוא איש ה-Devops.

עדכון: להלן כמה דברים שאנשי Devops כותבים לגבי הנושא:

יבגני זיסלס כותב: "בוא נתחיל מזה שדבאופס, כפי שהגו האנשים שהכניסו לנו את המושג, זה בכלל לא קשור לכלי כזה או אחר. וזה גם לא ״בן אדם״, ז״א אין דבר כזה ״מהנדס דבאופס״ או ״צוות דבאופס״. אבל כמו כשציינתי, ככה מסתכלים על זה האנשים שהגו את המושג. היום יש גם את כל החברות והציידי ראשים והמחפשי עבודה שכמובן רואים את זה אחרת לגמרי, אבל אני קופץ קדימה מדי.
דבאופס לפי ההגדרה הראשונית, זה עניין של תרבות חברה. וכל הכנסים והפרסומים שמבטיחים שדבאופס יתן כל מני אחוזים ענקיים בשיפור העסק, כל זה מסתמך על השוואה של חברות שיש בהן תרבות דבאופס, לבין אלו שאין. אני מזמין אותך לקרוא את סקר ה-״דבאופס״ שחברת פאפטלאבס הכינו ב-2015 ו-2014, וכאשר אתה קורא את התוצאות שים לב שמדובר בתרבות, לא כלים.
אבל בוא נחזור אל מחפש העבודה הממוצע שחושב לעשות תיקון קריירה ולקרוא לעצמו ״דבאופס״. תתחיל בזה שכנראה הוא, והחברה שרוצה לגייס אותו, לא יועץ או פרילנסר. לכן לא באמת יש סיבה למישהו שעובד בחברה שעושה שימוש בשף, שיהיה לו ידע בסיסי בדברים אחרים. וכמובן גם חברה שמחפשת אנשים עם ידע בשף, לא צריכה את אלה שלא מכירים אותו.
עניין הנסיון הוא באמת משחק תפקיד די גדול אצל מישהו כזה שקורא לעצמו ״דבאופס״, אחרי הכל הכלים שאותו אדם טוען לדעת לא טריוויאליים, ולרוב לא היו בשימוש בעבר בשום מקצוע אחר (לא סיסטם ולא מתכנת ולא הלפדסק ולא בדיקות). אז יש כלי חדש, צריך תווית חדשה, ולמזלנו בדיוק הגיע ה״דבאופס״ הזה, אז למה לא. אבל נסיון בשימוש בכלי הוא שום דבר ליד נסיון בהבנה של מערכות, ויותר חשוב, בהבנה של מערכות של אנשים.
אתה בטח מכיר ארגונים שבהם הפוליטיקה שולטת, אז דמיין בן אדם בארגון כזה שיודע להשיג דברים שהוא רוצה שיקרו כאילו אין שום פוליטיקה … זה מיומנות, גם כאן יש אנשים עם נסיון בזה וכאלה בלי נסיון, וגם זה דוגמא לכלי, לא פחות חשוב משף או ג'נקינס.
קיצור, העליתי כמה נקודות, אבל המאמר בא לחזק בדיוק את הדברים שאנשים בעולם ה״דבאופס״ מנסים להעלים." (יבגני גם ממליץ לקרוא את ה-Agile Manifesto וגם את הקישור הבא)

עמוס שפירא כותב: "…בכלל מזה "איש DevOps"? הרי DevOps זה צורת מבט על כל תהליך הפיתוח (Dev) והרצת שרתים (Ops) כשלבים מאד קשורים אחד לשני, לעומת המודלים הקודמים שבהם אנשי הפיתוח לא יודעים כלום ולא מעניין אותם איך הקוד שלהם רץ בשטח והתפקיד שלהם נגמר כשהם " זורקים את הקוד מעבר לגדר" ("chuck over the fence").
מבחינת אנשי סיסטם (ואני לא בטוח כמה זה קשור ספציפית ל-Devops), איש סיסטם עדכני צריך להבין את החלק שלו בכל התהליך מהגדרת המוצר וכתיבת התוכנה (ששם הוא יכול לתרום בהסבר מראש מה הוא צריך כדי לעשות את החלק שלו) וכן לממש "infrastructure as code", אוטומציה של תהליכים, תמיכה בשרשרת הבניה והבדיקות של התוכנה וכו'." (למעוניינים, ישנו שרשור של אנשי Devops המתייחסים לפוסט זה ואנשי Devops מסבירים מה הוא המקצוע)

איש ה-Devops ברמת המאקרו צריך להכיר המון טכנולוגיות חדשות ועדיף שיהיה לו מבחינת שפות ידע ב-Python, JAVA ואם אפשר – גם RUBY (ולאחרונה מה שנהיה פופולרי – שפת Go של גוגל), אך כאן זה לא נעצר – איש Devops חייב להמשיך להכיר טכנולוגיות חדשות בזמן  העבודה או מחוץ לעבודה. מכיר קונטיינרים? אם לא – תכיר. אתה צריך להרים מכונות VM בצורה אוטומטית? תכיר את Vagrant והרשימה ארוכה ומתארכת כמעט כל יום או כל שבוע. כך לדוגמא בעבר אם היה לך נסיון ב-RDBMS כלשהו (החל מ-MySQL או SQL server של מיקרוסופט או Oracle DB) – כיום חברות רבות מחפשות ידע בשרותי DB שמבוססים NoSQL (כמו MongoDB ואחרים).

ואחד הנושאים הכי חשובים שאיש Devops צריך להכיר ברמה מעולה – הם העננים הציבוריים. פחות ESXI/Xen ויותר אמזון AWS, מיקרוסופט Azure, או גוגל Cloud Computing. כל אחד מהעננים הציבוריים מציע עשרות (ובמקרה של אמזון מאות) שרותים שונים ורוב מוחלט של חברות שמציעים שרותים באינטרנט – מארחות בענן ואותם שרותים שמציעים העננים הציבוריים נגישים דרך API או SDK (ומי ש"בונה" על ממשק GUI של ספק הענן – שיקח בחשבון שבמקרים רבים ה-GUI מספק פונקציונאליות פחותה מה-API) ובשביל להשתמש ב-API או SDK – יש צורך בידע בשפות כמו Python או JAVA ובמקרים מסויימים Javascript וידע ב-JSON לדוגמא.

לסיכום: המקצוע של איש Devops שונה מתפקיד של איש System. הוא כולל את התפקיד של איש סיסטם ולוקח אותו כמה צעדים (די הרבה, למען האמת) קדימה. איש Devops להישאר במצב של לימוד X והלימודים הבאים שלו יהיו שנה הבאה אם בכלל. הוא חייב להשקיע המון בלימודים של דברים חדשים. אלו שהתרגלו לעולם של מיקרוסופט יצטרכו לבצע לעצמם הסבה ללינוקס (מה לעשות, אמזון שולטת בשוק הענן הציבורי), הכרת VI (או emacs, לא nano), הכרת רשת על לינוקס, שרותים, סקריפטים ועוד ועוד.

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

(גילוי נאות: כותב שרות אלו מציע שרותי Devops כפרילאנסר)