מי זה DevOps ומתי אין בו צורך?

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

יש אנשים שמפרטים DevOps בקורות החיים שלהם, למרות שהם לא תמיד יודעים או מבינים את מהות המונח. יש אנשים שחושבים שאחרי שלמדתם את Ansible, GitLab, Jenkins, Terraform ודומיהם (ניתן להמשיך את הרשימה לפי טעמכם), מיד תהפכו ל-"devopsist". זה כמובן לא נכון.

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

מי זה DevOps

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

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

DevOps היא פילוסופיה ומתודולוגיה.

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

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

ניתן לתאר את המטרות של DevOps בשלוש נקודות:

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

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

וזה רק חלק מכלי DevOps

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

מניסיון ראיון, אני רואה את התמונה הבאה: למומחים הרואים ב-DevOps שם עבודה יש ​​בדרך כלל אי ​​הבנות עם עמיתים.

הייתה דוגמה בולטת. צעיר הגיע לראיון עם הרבה מילים חכמות ברזומה שלו. בשלוש העבודות האחרונות שלו, היו לו 5-6 חודשי ניסיון. עזבתי שני סטארט-אפים כי הם "לא המריאו". אבל לגבי החברה השלישית, הוא אמר שאף אחד לא מבין אותו שם: המפתחים כותבים קוד ב-Windows, והמנהל מאלץ את הקוד הזה "לעטוף" ב-Docker רגיל ולשלב אותו בצינור ה-CI/CD. הבחור אמר הרבה דברים שליליים על מקום העבודה הנוכחי שלו ועל הקולגות שלו - רק רציתי לענות: "אז אתה לא תמכור פיל."

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

- מה המשמעות של DevOps עבורך באופן אישי?
- באופן כללי או איך אני תופס את זה?

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

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

מתודולוגיה ופילוסופיה של DevOps

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

מתודולוגיית DevOps היא רק אמצעי להשגת יעדים.

עכשיו לגבי מהי הפילוסופיה של DevOps. וזו כנראה השאלה הקשה ביותר.

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

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

בעזרת הניסיון שלי, ניסיתי להמציא כמה מה"הנחות" של הפילוסופיה הזו. התוצאה היא הבאה:

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

אני חושב שה"הנחות" שלי הן נושא נפרד לדיון. אבל עכשיו יש על מה לבנות.

מה DevOps עושה

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

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

ברוסיה, DevOps הוא עדיין נושא צעיר מאוד, אבל כבר מגמתי. עד כמה שידוע לי, רק במוסקבה המחסור במומחים כאלה בשנת 2019 היה יותר מ-1000 איש. והמילה Kubernetes למעסיקים היא כמעט כמו סמרטוט אדום לשור. חסידי הכלי הזה מוכנים להשתמש בו גם היכן שהוא אינו הכרחי ומשתלם כלכלית. המעסיק לא תמיד מבין באילו מקרים מה יותר מתאים להשתמש, ועם פריסה נכונה תחזוקת אשכול Kubernetes עולה פי 2-3 מאשר פריסת אפליקציה באמצעות סכמת אשכולות קונבנציונלית. השתמש בו איפה שאתה באמת צריך את זה.

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

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

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

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

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

כאשר אין צורך ב-DevOps

ישנם מצבים שבהם אין צורך ב-DevOps. זו עובדה - צריך להבין ולקבל אותה.

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

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

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

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

• DevOops
• DevOpsConf
• HighLoad ++
• פלאנט
• MailRu Cloud Solution

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

אם החברה שלך מוכרת דגים בחנות קטנה ומוצר ה-IT היחיד הוא שתי 1C: תצורות ארגוניות (חשבונאות ו-UNF), אז בקושי הגיוני לדבר על DevOps.

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

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

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

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

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

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

הקריטריון העיקרי להבנה האם יש צורך ב-DevOps: איזה ערך יש למוצרי ה-IT שלך עבור החברה והלקוחות.

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

כל משחקים קיימים הודות למימון: ישיר או עקיף מהשחקנים. ב-Playgendary, אנו מפתחים משחקים ניידים בחינם עם למעלה מ-200 אנשים המעורבים ישירות ביצירתם. כיצד אנו משתמשים ב-DevOps?

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

כעת אנו משתמשים באופן פעיל ב-Jenkins ככלי CI/CD pipelines לביצוע כל צינורות ההרכבה עם Unity ופריסה שלאחר מכן ל-App Store ול-Play Market. עוד מתוך ערכת הכלים הקלאסית:

• אסאנה - לניהול פרויקטים. האינטגרציה עם Jenkins הוגדרה.
• Google Meet - לפגישות וידאו.
• Slack - לתקשורת ולהתראות שונות, כולל התראות מג'נקינס.
• Atlassian Confluence - לתיעוד ועבודה קבוצתית.

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

במקום מסקנה

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

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

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

מקור: www.habr.com