ביי ביי סיסטם, שלום Devops

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

עד לפני שנים ספורות, תחום הסיסטם לינוקס היה די פשוט מבחינת הדרישות: הכרות עם הפצת לינוקס אחת או 2 (נניח Debian ו-CentOS או SuSE), הכרות טובה עם BASH ו-PERL, ידע בקונפיגורציית שרותים כמו Mail (אפליקציות כמו Postfix, Sendmail וכו'), WEB (אפאצ'י, Nginx), מוניטורינג, רשת, הכרות עם חומרה, והיית יכול למצוא עבודה יחסית די מהר (הסיבה לכך כמובן היא שלא היו הרבה אנשי לינוקס). את כל השאר היית יכול ללמוד תוך כדי עבודה. 

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

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

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

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

  • פעם היה צריך לדעת ממש טוב Perl. אני יכול לאמר לכם שמתוך כל ראיונות העבודה שעברתי, הדרישה לידיעת Perl היתה אפס. כל מי שמכיר Perl יכול לאמר לכם כמה השפה הזו חזקה ושניתן לעשות איתה אין ספור דברים מעניינים, אבל היום כמעט ואין לה דרישה. במקום זה יש דרישה ל-Bash כבסיס עם יתרון מובהק לידע ב-Python ו-Ruby. כך לדוגמא, אם החברה משתמשת ב-Chef כדי לבצע אוטומציה מלאה לשרתים ולתוכנות, אתה חייב לדעת Ruby. אם לעומת זאת הם משתמשים ב-Puppet אז סביר להניח שיבקשו ידע ב-Ruby אבל יהיו מקרים שיבקשו גם ידע ב-Python, תלוי באימפלנטציה.
  • קוד כתיבת סקריפטים: כבר הפסקתי לספור את כמות המקרים שבהם הייתי מקבל סקריפט שנכתב בשפה כלשהי ופשוט לא הצלחתי לקרוא אותו. לא בגלל שאינני יודע את השפה, אלא בגלל שמי שכתב אותו כתב בצורה שלומיאלית, בלי שום סדר, בלי הערות, בלי כלום, שזה פשוט נס שזה רץ! בחברות רבות כיום, קוד נקי וקריא זו חובה, כולל Commit עם הסבר מה אתה דוחף פנימה, כי יהיו אחרים שירצו להסתכל בקוד או לשנות אותו. שוב, בתחום הסיסטם בעבר, מי שהיה כותב לסיסטם את הקוד וקורא אותו היה רק איש הסיסטם, היום זה השתנה.
  • DB: פעם זה היה מעולה אם היית יודע MySQL ו/או Oracle. היום זה נחמד שאתה יודע לעבוד עם MySQL, אבל חברות אינטרנט רבות כבר עברו להשתמש בדברים כמו NoSQL, MongoDB, Redis ועוד, כלומר כדאי שתלמד דברים שהם לא RDBMS.
  • מאיצים למיניהם: לא, לא מאיץ גרפי, אלא פתרונות Caching כמו Varnish, Memcache שיודעים ליצור Cache חכם מאפליקציות דינמיות. חברות רבות רואות יתרון במועמד שמכיר את האפליקציות הללו.
  • ידע במחשוב ענן: על AWS שמעת, נכון? איך אתה בשימוש ה-API של אמזון? חברות רבות דורשות זאת (יש גם חברות שדורשות ידע על Azure מאחר ומיקרוסופט החלה להציע שרתים וירטואליים עם לינוקס, אבל זה נדיר), ובשביל זה כדאי שתכיר לא רק AWS אלא שוב .. Python. אפשר כמובן עם שפות אחרות, אבל ברוב המקרים שרואיינתי, כשהגיעו לדבר על AWS, דרשו Python.
  • ניהול זכרון, פרוססים, ושאר ירקות: בתחום הזה לא השתנה הרבה מבעבר, רק שהיום הסקאלה הרבה יותר גדולה. חברת אינטרנט שמקימה עשרות או מאות שרתים (בהתאם לעומס) תצטרך ניהול זכרון קפדני כי מכונות רבות הן רפליקציה, ואם יש בעיית זכרון בגלל אפליקציה שרצה על כולן, הצרות יגיעו מהר מאוד.

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

מאחל לחבריי המחפשים הצלחה.

אנשי הייטק: איך “למכור” את עצמך יותר טוב

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

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

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

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

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

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

לשיטה קוראים: השתלבות בקוד פתוח וברשותכם אסביר:

334px-Tux.svgבראיון מקצועי בד”כ נשאלים המון שאלות תאורתיות: איך עושים X, איך פותרים בעיה Y, מה עושים במצב Z, וכו’, ואם אתה יודע את הדברים ונותן פתרונות, זה מעלה את ערכך בראיון, אולם מה היה קורה אם למראיין היתה חשיפה לקוד שאתה כתבת או לדברים שאתה ביצעת בעבר? הרושם היה הרבה יותר חזק.

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

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

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

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

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

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

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

בהצלחה.