אתם באמת צריכים איש Devops?

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

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

אני אקח ברשותכם את הדברים טיפה קדימה. אני יותר ממשיל "איש Devops" (המרכאות בכוונה) למשהו מהדת הנוצרית: לאוונגליסט. הוא האדם ש"מצעיד" את החברה ממצב עבודה "קלאסי" (כתיבת קוד, קימפול, הכנסה ל-source repository, הוצאת Build, העברה ל-QA, תיקונים, קימפול, הוצאת Beta, תיקוני באגים, עוד Beta, עוד תיקונים ושחרור גירסה – כל זה ב"מבט על" וקפיצה על כל מיני שלבים בדרך) למצב עבודה שונה וזריז בהרבה.

המצב הזה נקרא CI/CD, במצב הזה דוחפים את הקוד ל-GIT, ישנה מערכת כמו Jenkins ואחרות שבודקות את ה-GIT וברגע שיש תיוג – היא מושכת ומקמפלת. את ה-QA מחליפים ב-Unit Testing – שזהו קוד מצטבר שכותבים בחברה לבחון את הקוד הנכנס האם הוא עומד בבדיקות שונות שהמפתחים כותבים. הנה לדוגמא וידאו קליפ על Unit Testing:

בתוך Jenkins (וכלים אחרים שנותנים פחות או יותר אותו דבר) יש לנו גם "צינורות" שבהם אנחנו מתכננים את כל התהליך מרגע שהמערכת מושכת קוד מה-GIT, מקמפלת ועושה שורה של דברים (חלקם מותנים, כך שיש מעין "תתי צינורות")  עד לחלק האחרון שאנחנו רוצים שהמערכת תעשה וניתן יהיה לשלב זאת בפרודקשן או לבצע מהלכים כלשהם (בדיקה ידנית, Selenium ואחרים).

בקיצור – לא רק הכלים שונים, השיטה שונה.

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

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

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

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

כתיבת תגובה

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

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

Exit mobile version