נושא ה-DevOps הפך לפופולרי מאוד בשנים האחרונות. אנשים רבים חולמים להצטרף אליו, אך כפי שמראה בפועל, לעתים קרובות רק בגלל רמת השכר.
יש אנשים שמציינים בקורות החיים שלהם את המונח DevOps, למרות שהם לא תמיד יודעים או מבינים את מהות המונח. יש אנשים שחושבים שאחרי שלמדו את Ansible, GitLab, Jenkins, Terraform ודומיהם (ניתן להמשיך את הרשימה לפי טעמכם), הם יהפכו מיד ל"devops". זה כמובן לא נכון.
בשנים האחרונות עסקתי בעיקר ביישום DevOps בחברות שונות. לפני כן עבדתי למעלה מ-20 שנה בתפקידים, החל ממנהל מערכת ועד למנהל IT. כיום אני מהנדס DevOps ראשי ב-Playgendary.
מי זה DevOps
הרעיון לכתוב מאמר עלה בעקבות שאלה נוספת: "מי זה DevOps?" עדיין אין מונח מבוסס למה או מי זה. חלק מהתשובות כבר נמצאות כאן. ראשית, אדגיש את הנקודות העיקריות מתוכו, ולאחר מכן אשתף את תצפיותיי ומחשבותיי.
DevOps אינו מומחה שניתן לשכור, לא סט כלים, ולא מחלקה של מפתחים ומהנדסים.
DevOps היא פילוסופיה ומתודולוגיה.
במילים אחרות, זוהי מערכת של פרקטיקות המסייעות למפתחים לתקשר באופן פעיל עם מנהלי מערכת. כלומר, לחבר ולשלב תהליכי עבודה זה בזה.
עם הופעת ה-DevOps, המבנה והתפקידים של המומחים נותרו זהים (יש מפתחים, יש מהנדסים), אך כללי האינטראקציה השתנו. הגבולות בין המחלקות היטשטשו.
ניתן לתאר את מטרות ה-DevOps בשלוש נקודות:
- יש לעדכן את התוכנה באופן קבוע.
- יש לייצר תוכנה במהירות.
- יש לפרוס את התוכנה בצורה נוחה ובזמן קצר.
ל-DevOps אין כלי אחד. הקמה, התקנה ולימוד של מספר מוצרים לא אומר ש-DevOps הופיע בחברה. ישנם כלים רבים וכולם משמשים בשלבים שונים, אך הם משרתים מטרה משותפת אחת.
וזה רק חלק מכלי ה-DevOps
אני מראיין אנשים לתפקיד מהנדס DevOps כבר למעלה משנתיים והגעתי להבנה עד כמה חשוב להבין בבירור את מהות המונח. צברתי ניסיון, תצפיות ומחשבות ספציפיים שאני רוצה לשתף.
מניסיוני בראיונות אני רואה את התמונה הבאה: אנשי מקצוע הרואים ב-DevOps תפקיד בדרך כלל לא מבינים את עצמם עם עמיתיהם..
הייתה דוגמה בולטת. גבר צעיר עם חבורה של מילות מפתח בקורות החיים שלו הגיע לראיון. היו לו רק חמישה עד שישה חודשי ניסיון בשלושת עבודותיו האחרונות. הוא עזב שני סטארט-אפים כי הם "לא המריאו". אבל לגבי החברה השלישית, הוא אמר שאף אחד לא הבין אותו שם: המפתחים כתבו קוד ב... Windows, והבמאי מאלץ את הקוד הזה להיות עטוף ב-Docker רגיל ולשלב אותו בצינור ה-CI/CD. הבחור אמר הרבה דברים שליליים על מקום עבודתו הנוכחי ועל עמיתיו לעבודה - התפתיתי לענות, "אי אפשר למכור פיל ככה".
אחר כך שאלתי אותו שאלה שהיא אחת הראשונות ברשימה שלי עבור כל מועמד.
מה המשמעות של DevOps עבורך באופן אישי?
— באופן כללי או איך שאני תופס את זה?
התעניינתי בדעתו האישית. הוא הכיר את התיאוריה ואת מקור המונח, אך חלק עליהם בתוקף. הוא האמין ש-DevOps היא עמדה. כאן טמון שורש בעיותיו. כמו גם מומחים אחרים בעלי אותה דעה.
מעסיקים, ששמעו על "קסם ה-DevOps", רוצים למצוא אדם שיבוא וייצור את ה"קסם" הזה. ומועמדים מהקטגוריה "DevOps זה תפקיד" לא מבינים שעם גישה כזו הם לא יוכלו לעמוד בציפיות. ובכלל, הם כתבו DevOps בקורות החיים שלהם כי זה טרנד והם משלמים הרבה על זה.
מתודולוגיה ופילוסופיה של DevOps
מתודולוגיה יכולה להיות תיאורטית ומעשית. במקרה שלנו, מדובר באחרון. כפי שציינתי לעיל, DevOps היא אוסף של פרקטיקות ואסטרטגיות המשמשות להשגת מטרות מוצהרות. ובכל מקרה, בהתאם לתהליכים העסקיים של החברה, זה יכול להיות שונה באופן משמעותי. מה שלא הופך את זה לטובה או לרעה.
מתודולוגיית DevOps היא רק אמצעי להשגת המטרות שנקבעו.
עכשיו לגבי מהי הפילוסופיה של DevOps. וזו כנראה השאלה הקשה ביותר.
קשה למדי לנסח תשובה קצרה ותמציתית, משום שהיא עדיין לא גובשה באופן פורמלי. ומכיוון שחסידי פילוסופיית ה-DevOps עוסקים יותר בפועל, פשוט אין זמן להתפלספות. אף על פי כן, זהו תהליך חשוב מאוד. יתר על כן, הוא קשור ישירות לפעילויות הנדסיות. יש אפילו תחום ידע מיוחד - .
לא היה נושא כזה באוניברסיטה שלי, הייתי צריך ללמוד הכל לבד באמצעות החומרים שיכולתי למצוא בשנות ה-90. הנושא אינו חובה בחינוך הנדסי, ומכאן חוסר פורמליזציה של התשובה. אבל אותם אנשים ששקועים ברצינות ב-DevOps מתחילים להרגיש "רוח" מסוימת או "השלמה לא מודעת" של כל תהליכי החברה.
ניסיתי לנסח חלק מה"פוסטולטים" של פילוסופיה זו על סמך ניסיוני האישי. להלן התוצאות:
- DevOps אינו משהו עצמאי שניתן לייחד אותו כתחום ידע או פעילות נפרד.
- כל עובדי החברה צריכים להשתמש במתודולוגיית DevOps בעת תכנון פעילויותיהם.
- DevOps משפיע על כל התהליכים בתוך חברה.
- DevOps קיים כדי להפחית את עלויות הזמן של כל תהליך בתוך חברה על מנת להבטיח פיתוח שירותיה ונוחות מרבית ללקוחות.
- DevOps, בשפה מודרנית, היא עמדה פרואקטיבית של כל עובד בחברה, שמטרתה להפחית עלויות זמן ולשפר את איכות מוצרי ה-IT סביבנו.
אני חושב שה"פוסטולטים" שלי הם נושא נפרד לדיון. אבל עכשיו יש משהו להתחיל ממנו.
מה עושה DevOps?
מילת המפתח כאן היא תקשורת. יש הרבה תקשורת, שהיזם שלה צריך להיות אותו מהנדס DevOps עצמו. למה? כי זו פילוסופיה ומתודולוגיה, ורק אחר כך ידע הנדסי.
אני לא יכול לדבר בוודאות של 100% על שוק העבודה המערבי. אבל אני יודע לא מעט על שוק ה-DevOps ברוסיה. בנוסף למאות ראיונות, במהלך השנה וחצי האחרונות השתתפתי במאות מכירות טכניות מקדימות עבור שירות "DevOps Implementation" עבור חברות ובנקים רוסיים גדולים.
ברוסיה, DevOps הוא עדיין נושא צעיר מאוד, אך כבר טרנד. ככל הידוע לי, במוסקבה לבדה, המחסור במומחים כאלה בשנת 2019 עמד על יותר מ-1000 איש. והמילה Kubernetes עבור מעסיקים היא כמעט כמו סמרטוט אדום לשור. חסידי הכלי הזה מוכנים להשתמש בו גם במקומות בהם הוא אינו הכרחי ואינו משתלם מבחינה כלכלית. המעסיק לא תמיד מבין באילו מקרים, מה מתאים יותר להשתמש, ועם פריסה נכונה, תחזוקת אשכול Kubernetes עולה פי 2-3 יותר מפריסת אפליקציה באמצעות סכמת אשכול קונבנציונלית. יש להשתמש בו היכן שהוא באמת נחוץ.
יישום DevOps יקר מבחינת כסף. והוא מוצדק רק כאשר הוא מביא תועלת כלכלית בתחומים אחרים, ולא כשלעצמו.
מהנדסי DevOps הם, למעשה, חלוצים - הם הראשונים ליישם את המתודולוגיה הזו בחברה ולבנות תהליכים. כדי שזה יצליח, המומחה חייב לתקשר כל הזמן עם עובדים ועמיתים בכל הרמות. כפי שאני נוהג לומר, כל עובדי החברה צריכים להיות מעורבים בתהליך הטמעת DevOps: מהמנקה ועד למנכ"ל. וזה חובה. אם החבר הצעיר ביותר בצוות לא יודע ומבין מה זה DevOps ומדוע פעולות ארגוניות מסוימות מבוצעות, אז הטמעה מוצלחת לא תתרחש.
בנוסף, מהנדס DevOps צריך להשתמש במשאבים אדמיניסטרטיביים מעת לעת. לדוגמה, כדי להתגבר על "התנגדות סביבתית" - כאשר הצוות אינו מוכן לקבל את הכלים והמתודולוגיה של DevOps.
על המפתח לכתוב רק קוד ובדיקות. לשם כך, הוא אינו זקוק למחשב נייד עוצמתי עליו יפרוס ויתמוך באופן מקומי בכל תשתית הפרויקט. לדוגמה, מפתח Front-end שומר את כל רכיבי האפליקציה במחשב הנייד שלו, כולל מסד נתונים, אמולטור S3 (minio) וכו'. כלומר, הוא מבלה זמן רב בתחזוקת תשתית מקומית זו ונלחם בכל הבעיות של פתרון כזה לבד. במקום לפתח קוד עבור Front-end, אנשים כאלה יכולים להתנגד בתוקף לכל שינוי.
אבל יש צוותים שלהפך, שמחים ליישם כלים ושיטות חדשים, ולהשתתף באופן פעיל בתהליך הזה. למרות שגם במקרה הזה, התקשורת בין מהנדס ה-DevOps לצוות לא בוטלה.
כאשר אין צורך ב-DevOps
ישנם מצבים בהם DevOps אינו נחוץ. זוהי עובדה - יש להבין אותה ולקבל אותה.
ראשית, זה נוגע לכל חברה (במיוחד עסקים קטנים), כאשר הרווח שלה אינו תלוי ישירות בנוכחות או בהיעדר מוצרי IT המספקים שירותי מידע ללקוחות. וכאן אנחנו לא מדברים על אתר האינטרנט של החברה, בין אם זה "כרטיס ביקור" סטטי או עם בלוקי חדשות דינמיים וכו'.
DevOps נדרש כאשר שביעות רצון הלקוח ורצונו לחזור אליך שוב תלויים בזמינות שירותי המידע הללו לצורך אינטראקציה עם הלקוח, באיכותם ובמיקודם.
דוגמה בולטת לכך היא בנק ידוע אחד. לחברה אין את משרדי הלקוחות הרגילים, זרימת המסמכים מתבצעת באמצעות דואר או שליחים, ועובדים רבים עובדים מהבית. החברה חדלה להיות רק בנק, ולדעתי, הפכה לחברת IT עם טכנולוגיות DevOps מפותחות.
דוגמאות והרצאות רבות נוספות ניתן למצוא בהקלטות של מפגשים וכנסים נושאיים. השתתפתי בכמה מהם באופן אישי - זוהי חוויה שימושית מאוד עבור אלו שרוצים להתפתח בכיוון זה. הנה קישורים לערוצי יוטיוב עם הרצאות וחומרים טובים בנושא DevOps:
עכשיו תסתכלו על העסק שלכם ותחשבו על זה: עד כמה החברה שלכם והרווחים שלה תלויים במוצרי IT המספקים אינטראקציה עם הלקוחות?
אם החברה שלכם מוכרת דגים בחנות קטנה ומוצר ה-IT היחיד הוא שתי תצורות 1C: Enterprise (חשבונאות ו-UNF), אז בקושי הגיוני לדבר על DevOps.
אם אתם עובדים במפעל מסחר וייצור גדול (לדוגמה, אתם מייצרים רובי ציד), כדאי לכם לחשוב על זה. אתם יכולים לקחת יוזמה ולהעביר את סיכויי הטמעת DevOps להנהלה שלכם. ובכן, ובמקביל, להוביל את התהליך הזה. עמדה פרואקטיבית היא אחת ההנחות החשובות של פילוסופיית DevOps.
גודל והיקף המחזור הכספי השנתי אינם הקריטריון העיקרי לקביעת האם החברה שלך זקוקה ל-DevOps.
בואו נדמיין מיזם תעשייתי גדול שאינו מקיים אינטראקציה ישירה עם לקוחות. לדוגמה, כמה יצרניות רכב. אני לא בטוח עכשיו, אבל מניסיוני בעבר, במשך שנים רבות כל האינטראקציה עם לקוחות נעשתה באמצעות דואר אלקטרוני וטלפון.
הלקוחות שלהם הם רשימה מוגבלת של סוכנויות רכב. ולכל אחד מהם מוקצה מומחה מהיצרן. כל זרימת המסמכים הפנימית מתרחשת דרך ERP SAP. עובדים פנימיים, למעשה, הם לקוחות של מערכת המידע. אבל מערכת מידע זו מנוהלת באמצעים קלאסיים של ניהול מערכות אשכול. מה שאינו כולל את האפשרות להשתמש בשיטות DevOps.
מכאן המסקנה: עבור ארגונים כאלה, יישום של DevOps אינו דבר בעל חשיבות קריטית, אם נזכור את מטרות המתודולוגיה מתחילת המאמר. אבל אני לא שולל שכמה כלי DevOps נמצאים בשימוש על ידם כיום.
מצד שני, ישנן חברות קטנות רבות המפתחות תוכנה תוך שימוש במתודולוגיה, פילוסופיה, פרקטיקות וכלים של DevOps. והן רואות בעלויות הטמעת DevOps כהוצאה המאפשרת להן להתחרות ביעילות בשוק התוכנה. ניתן לראות דוגמאות לחברות כאלה .
הקריטריון העיקרי להבנת האם DevOps נחוץ הוא: מה הערך שיש למוצרי ה-IT שלכם עבור החברה והלקוחות.
אם המוצר העיקרי של החברה שמביא רווחים הוא תוכנה, אתם צריכים DevOps. ולא משנה אם אתם מרוויחים כסף אמיתי ממוצרים אחרים. זה כולל גם חנויות מקוונות או אפליקציות מובייל עם משחקים.
כל משחק קיים בזכות מימון: ישיר או עקיף מצד שחקנים. ב-Playgendary, אנו מפתחים משחקי מובייל בחינם, כאשר למעלה מ-200 איש מעורבים ישירות ביצירתם. כיצד אנו משתמשים ב-DevOps?
כן, בדיוק כפי שתואר לעיל. אני מתקשר באופן שוטף עם מפתחים ובודקים, עורך הדרכות פנימיות לעובדים על מתודולוגיית וכלים של DevOps.
אנו משתמשים כעת באופן פעיל ב-Jenkins ככלי CI/CD pipeline כדי להריץ את כל צינורות הבנייה עם Unity ולאחר מכן לפרוס אותם ב-App Store וב-Play Market. כלים קלאסיים נוספים כוללים:
- אסאנה - לניהול פרויקטים. אינטגרציה עם ג'נקינס מוגדרת.
- גוגל מיט - לפגישות וידאו.
- סלאק - לתקשורת והתראות שונות, כולל התראות מג'נקינס.
- Atlassian Confluence - לתיעוד ועבודה קבוצתית.
התוכניות המיידיות כוללות יישום ניתוח קוד סטטי באמצעות SonarQube וביצוע בדיקות ממשק משתמש אוטומטיות באמצעות Selenium בשלב האינטגרציה הרציפה.
במקום מסקנה
אני רוצה לסכם במחשבה הבאה: כדי להפוך למהנדס DevOps מוסמך ביותר, חיוני ללמוד כיצד לתקשר עם אנשים בחיים האמיתיים.
מהנדס DevOps הוא שחקן צוות. ושום דבר אחר. היוזמה בתקשורת עם עמיתים צריכה לבוא ממנו, ולא תחת השפעת נסיבות מסוימות. מומחה DevOps צריך לראות ולהציע את הפתרון הטוב ביותר עבור הצוות.
וכן, יישום כל פתרון ידרוש דיונים רבים, ובסוף הוא עשוי להשתנות לחלוטין. על ידי פיתוח עצמאי, הצעת רעיונות ויישום שלהם, אדם כזה הופך בעל ערך הולך וגובר הן עבור הצוות והן עבור המעסיק. דבר שבסופו של דבר בא לידי ביטוי בגודל התגמול החודשי שלהם או בצורה של בונוסים נוספים.
מקור: www.habr.com
