איך מוצאים עבודה כ-devOps?

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

דבופס בחברת טיקל

אז “טיקל” קיימת כבר למעלה מעשרים שנה, לא מעט שנים אבל עיקר ההתמחות של “טיקל”. זה technical consulting ו-professional services במלא תחומים שונים – דבאופס, front end, בק אנד, machine learning, מובייל. כשאנחנו בדרך כלל עובדים עם סטרטאפ או מחלקות אינוביישן בחברות גדולות. ומגיעים בתור מומחים גם לייעץ, להוביל תחומים כאלה ואחרים, ואני שנתיים נמצא בקבוצה של דבאופס. אנחנו עובדים בעיקר בשיטה של פרויקטים.

לעבוד כ-devops בהייטק בחברת פרוייקטים

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

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

מה זה דבופס?

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

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

אחריות ה-devOps

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

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

איך אנחנו בונים את המוצר? איך אנחנו מנטרים אותו? אם משהו לא עובד – מה עושים? זה אומר שגם אם ממך נדרש הרבה דברים, חשוב איך בונים את ה-softwate. להבין ולדבר עם אנשים מכל הארגון באותה שפה. אלו יכולים להיות אנשי ביזנס, פרודקט מנג’ר, אנשי QA, פרונט אנד, בק אנד. אם יש מישהו בארגון שמתעסק עם DB אז DBAs. ה-support, ולתת לכולם כלים. אז אתה הופך להיות סוג של מרכז העניינים.

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

תרבות DevOps

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

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

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

נגיד אנחנו לוקחים איזשהו ארגון בינוני, יש בו חמישים אנשים ב R&D. בדרך כלל יש שניים-שלושה אנשי דבאופס. לשניים-שלושה אנשי דבאופס אין סיכוי בעולם להכיר לעומק כל software שהחברה מדלברת, מספקת. אבל יש לו סיכוי טוב לתת כלים למפתחים לקבל את הפידבק לופ: משהו לא עובד? מקבלים ההתראה. ואולי זה באג לא אצלך אצל מישהו אחר, ושזה הכל יהיה מחובר – מג’יק. כמו שאנחנו רואים בסרטים, זו עבודה קשה אבל אני ממש אוהב אותה. וכששואלים אותי “מה אתה עושה? מה היום יום שלך?”.

איך נראה היום-יום של איש DevOps?

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

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

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

איך מגיעים לתפקיד DevOps

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

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

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

קורסים מקצועיים ל-devOps

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

אנסיבל או שף או קוברנטיס – כל אלו כלים

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

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

דרישות משרות דבופס

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

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

לריאיון עבודה בדבופס – תבואו עם הבנה של המהות

וזו שאלה חשובה בעולם הדבאופס. כי כלים כמו שאמרתי הם באים ומתחלפים, לפעמים אני פוגש אנשים הם אומרים לי “תשמע, אני תותח ב-terraform”, אני שואל מה זה terraform והם אומרים לי “זה כלי שיכול בעזרת איזשהו DSL לבנות, לתאר ולנהל אסטייט ולהרים אינסטנסים בקליק אחד”, ואני אומר “חכו חכו חכו, איזו בעיה זה פותר?”, פה אנשים עוצרים ולא כל כך מבינים את זה, ופה הבעיה .

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

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

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

אני רוצה קצת להתייחס לעוד איזשהו נושא. קודם כל לעולם הגדל, שואלים אותי הרבה “נגיד אני למדתי איקס והאם בסטרטאפ זה שונה?”, זה שונה, בכל עולם מקום שונה, גם אם אתם תשאלו פרויקט מנג’ר או פרונט אנד או כל תפקיד כזה או אחר, כמובן שבמקום אחר הוא שונה, ואם לדוגמא רוב האנשים עושים פרויקט גמר בלימודים, ואם אפשר לעשות איזשהו פרויקט גמר בתחום הדבאופס זה קשה, זה לא אומר שאי אפשר. עד היום לא מצאתי איזושהי דוגמא טובה, אבל אני ממליץ לקרוא ספר של גוגל שנקרא “Site Reliability Engineering”.

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

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

אז הספר הזה, ויש ספר שני שהוא בכללי לא רק לאנשי דבאופס, אלא לכל האנשים שמגיעים להייטק יש ספר של “Soft skills versus software engineers”, זה ספר מעולה, אני ממליץ לקרוא אותו כל שנה וחצי. כי אחרי שנה וחצי במיוחד בתחילת קריירה אתם מתחילים להסתכל על כל הדברים שכתבו שם בזווית אחרת, וזה לא משנה האם אתם נמצאים באיזושהי חברת ענק כמו גוגל, אתם נמצאים בסטרטאפ ואתה עובד חמישי או עשירי או שאתם בגיוס מתקדם שהיום אתם שלוש מאות איש או אלף איש, ממליץ.