הדרישה לאנשי לינוקס בארץ ובעולם מרקיעה שחקים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7 תגובות על הדרישה לאנשי לינוקס בארץ ובעולם מרקיעה שחקים

  1. מאת מישהו‏:

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

    • מאת האח הגדול‏:

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

  2. מאת a‏:

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

    • מאת האח הגדול‏:

      לכאורה אתה צודק, אבל בפועל, המצב הרבה יותר מורכב. קיימות דוגמאות כגון בסיסי נתונים. כמה שהמערכות ישוכללו והממשקים יופשטו, עדיין, בסיס נתונים של אורקל (או פיציסופט) צריך ליווי צמוד. וכך גם על המפלצות של ibm. קיימים אומנם תחומים המפשטים את התחזוקה. כמו ממשק ה- cpanel ללינוקס, אבל עדיין מחייבים הבנה יותר מבסיסית במערכות ובמשמעות השינויים.
      אפילו תחומים שהפכו טכניים ומוגדרים, כמו גיבויים, איחסון ווירטואלויזציה, מחייבים הכשרה מעמיקה ורצופה של העוסקים בהם. במקרים הללו, השכר אומנם עלול לרדת משמעותית, אבל זה תהליך הלוקח עשרות שנים.
      ובכל מקרה, יקח עוד הרבה מאוד שנים, אם בכלל, שמערכות ה-big data יעברו תהליך שכזה. יש לכך סיבות רבות. המערכות מחייבות שימוש בכמויות גדולות של מחשבים, עשרות ולעיתים מאות. יש מערכות שנועדו לתחזוקה שכזו (chef וכאלו) אבל פשוט זה לא יכול להיות. גם אם פיתוחים שונים יקלו על מערכות הליבה, עדיין, יש המון מערות המתמשקות אליהן. החל מהמערכות המכניסות את הנתונים, ועד מערכות caching להפצתן. וכיום, כל הדברים הללו נמצאים ממש בחיתוליהם. המעניין שיש הרבה מאוד אירגונים ההולכים על מערכות שהן על טוהרות התוכנה החופשית.

  3. מאת ליאור בר-און‏:

    מעניין מאוד!
    תודה רבה.

  4. מאת דורון עיפרון‏:

    אתמול פורסם מחקר חדש שטוען שפסימיים חיים יותר מאופטימיים.

    כמה זרים אתה רוצה שאקנה לך ? והשיש, באיזה צבע אתה רוצה אותו ?

    :)

כתיבת תגובה

האימייל לא יוצג באתר. (*) שדות חובה מסומנים

תגי HTML מותרים: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>