לחשוב בחיוב על העסקת עצמאים

 

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

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

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

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

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

הבעיה בכל הסצנריו שתיארתי לעיל? המחיר. כמה יותר? בניגוד למצב שאני מוכר ללקוח לדוגמא הפצת לינוקס כלשהי ואני אקבל 10-20% מהמכירה הסופית, לחברות שמעסיקות אנשי מקצוע – הרווח הרבה יותר גדול. כמה יותר גדול? בסביבות 50-150%. בנוסף, לכם אין מושג ירוק כמה הבחור שהם שולחים באמת מכיר את התחום או פשוט "מתגלח על הזקן" שלכם.

סתם דוגמא מלפני מספר חודשים: ללקוח שלי ישנה מערכת שכתובה בשפה שאינני מכיר אותה מספיק טוב ויש בקוד מספר תקלות רציניות (הוא ידע על כך מראש והוא לא לקח אותי כדי לכתוב באותה שפה אלא לדברים אחרים לחלוטין). הצעתי לו שאחפש לו ללא תשלום מישהו אחר שיעשה ספציפית והוא ישלם לאותו לקוח בנפרד. הגיעו 2 הצעות מחברות, חברה אחת הציעה מחיר של 600 שקל לשעה עם מינימום 5 שעות עבודה, והחברה השניה הציעה 650 שקל לשעה (עם מינימום 4 שעות עבודה). סתם לשם השוואה, מאותו לקוח גביתי כ-300 ש"ח לשעה. בסופו של דבר מצאתי עצמאי שגבה מאותו לקוח 280 ש"ח לשעה עם מינימום 3 שעות עבודה (היו הרבה שעות עבודה בין כה). האם אותו לקוח חסך? בהחלט, בכך שהוא לקח את העצמאי לעשות את אותה עבודה (ואותו עצמאי בסופו של דבר קיבל מאותה חברה פרויקט גדול נוסף בעקבות עבודתו המעולה).

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

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

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

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

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

הנקודה הראשונה היא עניין הידע הטכני שקיים באותה חברה. בסטארטאפים לדוגמא, כל עניין ההקמה, תחזוקה, הגדרות, אוטומציה – נופל על איש (או צוות, בהתאם לגודל הסטארטאפ) ה-Devops. מכיוון שרוב מוחלט של הסטארטאפים מקימים את התשתית שלהם בגוגל או באמזון, קיימת חובה מצד איש ה-Devops לדעת היטב דברים כמו Bash, Python הבנה של פורמט קבצים כמו JSON, YAML וכמובן אוטומציה כמו Puppet או Chef, Ansible. בלי זה – איש ה-Devops לא יתקבל לעבוד ב-Startup. זה שמישהו מכיר סיסטם Windows או ניסה פעם אובונטו וגם אם הוא יודע PowerShell, ידע זה לא ירשים את המראיין והוא יפסול את המועמד.

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

לסיכום נקודה זו: Azure יותר מתאים לחברות שיש להן תשתית בסיס שמורכבת מתשתיות מבוססות מיקרוסופט (AD וכו') וגם יש לאותה חברה שרתי Linux (סתם דוגמא: 70 VM של Windows ו-30 לינווקס) עם אנשים שרובם מבינים בתשתית של מיקרוסופט. אם המצב לעומת זאת הפוך, הפתרונות של גוגל ושל אמזון (לעניות דעתי) יתאימו הרבה יותר לעבודה.

הנקודה השניה החשובה לדעתי זו המחשבה של העברת מכונות אחת לאחת מה-DC שלכם לענן (לדוגמא: העברת 100 VM מה-DC שלכם לענן הציבורי). לא חשוב איך תסתכלו או איזה ספק ענן תבחרו, החשבוניות שתקבלו יהיו מבהילות מסיבה אחת פשוטה: שום ספק ענן ציבורי לא מחפש למשוך לקוחות רק כדי לארח את ה-VM שלהם כ"ספק טיפש" כמו אלפי ספקי VPS בעולם. כל הנקודה של ספקי הענן היא שתשתמשו בשירותים שלהם. אל תרימו Exchange לדוגמא, אלא תשתמשו בשרותי המייל שלהם. אל תרימו SQL משלכם אלא תשתמשו בפתרון ה-SQL שלהם ובכך תוכלו להתחיל בקטן ולגדול עד למימדים מפלצתיים, הכל בתשלום לפי שעה (חלקם לפי דקה) ובמקרים כמו אמזון (בחלק מהמקרים) – ההמלצות הם להשתמש בדברים כמו Serverless ללא צורך ב-VM יעודי, במקום להשתמש ב-Load Balancer הקלאסי שכולנו מכירים – להשתמש בשרות (החדש) ALB שעושה Load Balancing לאפליקציות במקום שכבות.

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

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

בהצלחה 🙂

על CI/CD ועל Jenkins

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

נתחיל בהסתכלות על המצב ה"קלאסי" של פיתוח, אצל חברות שמפתחות תוכנה המשווקת לציבור. בחברת הפיתוח יושבים כמה מפתחים וכל אחד (או קבוצה) אחראים לפיתוח חלק כלשהו. GUI, לוגיקה, ועוד ועוד. כל קבוצה (או יחידים) מפתחים בנפרד ובסוף יום (או כמה פעמים ביום) כל אחד מעלה את הקוד שלו למערכת SCM (ר"ת Source Code Management) ואחת לזמן מה מגיע החלק הקשה – איחוד הקוד של כל האינדיבידואלים או הקבוצות השונות לקוד אחיד למה שיהיה בהמשך גירסה חדשה של התוכנה. באיחוד כזה מתרחשים הרבה קונפליקטים מבחינת קוד – אחד שבר (בטעות) קוד ישן, השני הגדיר דברים בצורה שונה והקוד שלו בעייתי לאיחוד, ויש עוד שלל בעיות באיחוד קוד (שלא לדבר על ההערות שנזרקות…) שנכתב לאורך תקופה ללא איחוד. אלו כמובן בעיות שיש להן פתרון (במיוחד עם GIT..) ולכן עולה השאלה "בשביל מה אנחנו צריכים CI/CD אם אנחנו לא סטארט-אפ?"

ל-CI/CD (ר"ת של Continuous Integration ו-Continuous Deployment בהתאמה) יש (די בצדק) שם שמתאים לפיתוח בדרכים של ASD (ר"ת Agile Software Development) או בשם יותר ידוע – XP (ר"ת Extreme Programming), מה שדי מרתיע חברות פיתוח "קלאסיות" מאימוץ CI/CD, אבל יש יתרונות גדולים ל-CI/CD:

  • זמן פיתוח קצר בהרבה
  • שמירת תאימות לאורך זמן
  • תיקון באגים בזמן קצר בהרבה בהשוואה למצב הקלאסי
  • ה-Time To Market מתקצר משנים לימים או שבועות.
  • לקוחות מקבלים יותר פונקציונאליות ושרותים נוספים מבלי להמתין זמן רב עד שהחברה תכתוב את הקוד הכרוך בפונקציונאליות הנוספת.
  • קל למצוא באגים בקוד ולתקן במהירות.
  • כל המערכת רצה בצורה הרבה יותר יציבה
  • זמן ה-Downtime מתקצר לאחוזים בודדים

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

Image result for jenkins logoנכיר בקצרה את Jenkins. מערכת Jenkins נוצרה ב-2005 ע"י מפתח שעבד ב-Sun ו-Sun שחררה את הקוד לקהילה והמוצר עבר שינויים שונים במהלך חייו והיה נקרא Hudson. ב-2011 חברת אורקל (שרכשה את SUN) הצליחה להסתכסך עם קהילת המפתחים בקוד פתוח ולפיכך המפתחים החליטו לקחת את הקוד ולפצל (Fork) את המוצר ולתת לו שם חדש: Jenkins.

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

אחרי שהקמנו מערכת Jenkins, אנחנו מתחילים להשתמש בה והעבודה ב-CI/CD מתחילה עם המפתחים. אחרי שהמפתחים דחפו את השינויים מגיע תור ה-CI Server או במקרה שלנו – Jenkins לעשות את העבודה. ניצור JOB שבו בעצם אנחנו מגדירים ל-Jenkins מה לעשות. מהיכן לקחת את הקוד, מה לקמפל, ומה לעשות עם הקבצים (כמו לדוגמא האם להעביר אותם בדיקת סגנון קוד עם SonarQube לדוגמא) להעלות אותם ל-Artifactory, לשרת אחר וכו'.

מבחינת המפתחים, כשעובדים ב-Continuous Integration כל מפתח כותב את הקוד שלו, מוריד את הקוד של האחרים מה-SCM, משנה את הקוד שלו בהתאם על מנת לאחד אותו עם השאר, מריץ קוד בדיקות (Unite Testing), ולאחר שהקוד עבר בהצלחה בדיקות מקומיות, הוא מבצע Push ל-SCM. את התהליך עושים מספר פעמים ביום בכל פעם שכותבים חלק, לדוגמא – כותבים פונקציה חדשה, משפרים משהו קיים, מתקנים באגים וכו'. משם Jenkins ימשיך את תהליך ה-CI אם נגדיר לו מתי (אם לבדוק את ה-SCM אם מישהו ביצע commit לדוגמא, או לפי שעון).

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

מכאן אנו עוברים לחלק של ה-CD או ה-Continuous Deployment: קימפול והכנת קבצים בינאריים וחבילות זה טוב – אבל צריך לעשות עם זה משהו…

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

ci-cd-jenkins
כך נראית החלוקה בין CI ל-CD

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

בסופו של יום, לקוחות דורשים מיצרניות התוכנה והשירותים דברים רבים והם מעוניינים במענה מהיר ואם הם לא מקבלים, הם לא מתביישים להתחיל לבדוק את הפתרונות של המתחרים (תשאלו את Pay pal) ואף לעבור למתחרים, מה שעלול לגרום הפסדים כספיים. עבודה ב-CI/CD יכולה לעזור בקיצוץ הזמנים באופן ניכר.

מה לגבי מתחרים ל-Jenkins? ישנם לא מעט מתחרים ל-Jenkins בשוק (הנה לדוגמא טבלת השוואה קצרה בין ל-Jenkins ו-2 פתרונות אחרים מובילים, החלק של Open Source לא כל כך עדכני לגבי המתחרים), אך הבעיה הראשונה של רובם שהם פתרונות SAAS, כלומר שהמערכת אינה נמצאת אצלך בשרתים אלא אצל חברה אחרת ואתם משלמים לה. זה יכול להיות פתרון טוב אם הקוד כולו מהרגע הראשון הוא קוד פתוח, אולם מצד שני – אני לא מכיר הרבה חברות שיש להן קוד סגור שמעוניינות לבצע Build אצל חברות זרות. יחד עם זאת, כמובן – יש ויש.

מבחינת תאימות פלטפורמות – Jenkins הוא קוד פתוח מ-א' ועד ת' והוא רץ יפה מאוד על Windows (לא צריכים Windows Server), מק וכמובן לינוקס. הוא תומך בכל שפה, ויש לו יותר מ-1200 תוספים שונים שכוללים תמיכה בכל SCM, בכל קומפיילר, אותנטיקציה, אחסון וכו'. יחד עם זאת, כדאי לקחת בחשבון שלא כדאי "לערבב" – אם לדוגמא הקוד שלכם כתוב ב- #C, הקימו את Jenkins על Windows, אך אם אתם כותבים בשפות אחרות שרצות על לינוקס, עדיף להרים את ה-Jenkins על לינוקס הואיל ותחזוקת האבטחה הרבה יותר קלה.

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

הערת מפרסם
הח"מ פרילאנסר שמחפש עבודות בתחום לינוקס, Devops, ודברים הקשורים ל-Software Defined Storage, וירטואליזציה וכו'. מי שמעוניין בפרטים – אפשר למצוא אותם כאן.

טיפים בנושאי לימוד אונליין

כפרילאנסר שנותן שרות לדברים רבים הקשורים בלינוקס (אחרים ב-Windows או במערכות אחרות) אחד הדברים הראשונים שלמדתי – הוא שאתה לא יודע מה "יפול" עליך מחר מבחינת דרישות טכניות של לקוחות. כל לקוח והמערכות שלו, הגדרות שלו, אפליקציות ושרתים שלו וכל לקוח שונה מהשני. מחר אני יכול להרים ולתחזק שרת Jenkins עם Slaves וערימת סקריפטים הקשורים לכל מה שקשור ל-Build ו-Deploy, ומחרתיים אני אצטרך לכתוב מספר דברים ב-Python ועוד שבוע אני אצטרך לשבור את הראש מדוע אשכול (Cluster) של MySQL לא עובד טוב ואלו רק דוגמאות ספורות שכל פרילאנסר שנותן שרותים צריך להתמודד איתם, גם אם מדובר בכלים/פלטפורמות אחרות.

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

אחד הפתרונות ללימוד או רענון של שפת מחשבים, שרות או מערכת הפעלה – היא קורסים Online שחברות כמו Lynda.com, Oreily.com ואחרים נותנים הוא מנוי לספריה גדולה של קורסים שאתה יכול להיות מנוי, להתחבר, לבחור את הקורס ולעבור עליו בזריזות. זה טוב ונחמד, אבל הבעיה היא שהעלות של דבר כזה נעה בין 40-50$ לחודש. כלומר אם תעשה מנוי וגם אם תבטל אותו, הלכו 40-50$ כלומר שעת העבודה הראשונה שלך אצל הלקוח – תימחק מבחינת רווח. תוסיף עלויות של דלק, אוכל וכו' – ואם העבודה היא כולה שעתיים שלוש, תראה שבקושי יצאת עם משהו.

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

תרשו לי להכיר לכם את אתר Android Central Digital Offers. השם מרמז על דברים לאנדרואיד אבל אתר זה כמו עוד כמה אתרים – מציעים קטלוג של קורסים שכלל לא קשורים לאנדרואיד.

מה שמוצע באתר לעיל, הם קורסים שכרוכים בחבילות (Bundles) שקשורים בנושאים שונים כלליים. חלק מהחבילות לדוגמא מדבר על White Hackers, על VMWare, הסמכות MCSE ו-1001 דברים נוספים. הנה דוגמא:

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

vmware

כפי שאנחנו יכולים לראות בתמונה, אלו 3 החבילות, והן מוצעות במחירים זולים – 19$ ו-49$.

הבה נסתכל על ההצעה מימין. החבילה הזו בעצם מדברת על Complete White Hat Hacking & Penetration Testing Bundle. לא נשמע משהו שאנחנו צריכים אולם אם נסתכל מקרוב, הקוביה השניה משמאל מדברת על .. VMWare, כלומר אנחנו מקבלים את ה-VMWare בתוספת עוד כמה קורסים – והכל ב-19$. אם, אגב, נלך לאתר שמעביר את הקורס (כדי לדעת מי נותן את הקורס, נלחץ על הקוביה של ה-VMWare, נלחץ על ה-Instructor, שם יופיע לינק בכחול – לחצו עליו ותגיעו לאתר שנותן את הקורס) נראה שאותו קורס מוצע ב-202$. היי, חסכון לא רע בכלל! אבל מה שיותר יפה, הוא שבמקרה הזה עם נחזור להצעה ב-Digital Offers נראה משהו מעניין:

vmware2

הגישה שיש לנו לקורס זה היא לכל החיים מבלי לשלם סנט נוסף אחד.

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

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

טיפ חשוב – לחצו בדף של המוצר שבחרתם על Course Outline ותוודאו שהתכנים שאתם צריכים מופיעים שם. 19$ זה נשמע זול אבל אם התוכן שאתם מחפשים לא מופיע שם, אז חבל על הכסף.

עוד אפשרות נחמדה שיש באתר שמופיעה בחלק מהמקרים – זה Pay What You Want. נאמר שהחברה הכניסה לשימוש GIT ואתה צריך להכיר איך להשתמש בכלי הזה. חיפוש באתר של המילה GIT תתן לנו תוצאות והתוצאה לפני ה-Our Best Sellers תתן לנו את זה. אם נסתכל בחבילה, נראה שיש שם הרבה הרבה יותר מ-GIT, אבל בואו נסתכל על החבילה מקרוב (לחצו על התמונה להגדלה):

git-package

מספר 8 ברשימה זה מה שאנחנו צריכים – את GIT. השאר נחמדים ואם נרצה את כל החבילה, נשלם עליה 19$, אבל כרגע מה שמעניין אותנו זה GIT. ליד מספר 8 אין מנעול, ולכן אנחנו יכולים ללחוץ מימין על Pay What You Want ואנחנו יכולים להזין מספר מ-1 עד 19.36$, כלומר אתם יכולים לשלם דולר יחיד דרך Paypal ולקבל קישור Redeem שמאפשר לכם לצפות בקורס ובחלק מהמקרים גם להוריד את הוידאו שאינו מוגן ישירות למחשב שלכם, לשמור אצלכם על הדיסק הקשיח. מצד שני, אם אתה מפתח, אתה יכול לשלם את ה-19.36$ ולקבל שורה של קורסים שזמינים לך לכל החיים (ושוב, בחלק מהמקרים אתה פשוט יכול להוריד כל שיעור כקובץ MP4, יש שם קישורים להורדה בכל וידאו במקרה ואתה דואג שהאתר לא יהיה זמין בעתיד או שתרצה לצפות ב-Offline). עיסקה לא רעה, הייתי אומר.

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

אז האם כדאי לוותר על ההצעות של Lynda, Oreilly ואחרים למנוי? לא תמיד. אתרים אלו מציעים דברים עדכניים. אם לדוגמא בחברתכם יחליטו בהמשך לעבור ל-vSphere 6.5 לדוגמא, ב-Digital Offers לא תמצאו כלום. עדכונים להסמכות גם לא תמצאו באתר שהצעתי לעיל ובכלל קורסים של שפות תכנות, קורסים שמורכבים מעשרות שרות – עדיף את האתרים המקצועיים שמעבירים קורסים Online. האתר שהצעתי מתאים לרענון דברים שקיימים זמן רב ומאפשרים לאנשים לרענן את זכרונם במחיר זול.

הערת מפרסם
הח"מ פרילאנסר שמחפש עבודות בתחום לינוקס, Devops, ודברים הקשורים ל-Software Defined Storage, וירטואליזציה וכו'. מי שמעוניין בפרטים – אפשר למצוא אותם כאן.

עבודה כ-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 כפרילאנסר)