DevOpsForum 2019. אתה לא יכול לחכות ליישם DevOps

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

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

קטע מהנאומים של Raiffeisenbank, Alfastrakhovanie, הניסיון של Mango Telecom ביישום אוטומציה ופרטים נוספים תחת החתך.

שמי יאנה, אני עובדת כטסטר, אני עושה אוטומציה, וגם DevOps, ואני אוהבת ללכת לכנסים ולמפגשים. במהלך השנתיים האחרונות, הייתי בכנסים של אולג בונין (HighLoad++, TeamLead Conf), אירועי כד (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.

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

אור בקצה הצינור בבנק Raiffeisenbank

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

מיכאיל ביזאן, מנהל אוטומציה בבנק Raiffeisenbank

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

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

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

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

אוטומציה של בדיקות במנגו טלקום

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

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

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

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

בין מצגת, הסתובבתי בדוכנים של שותפי הכנס וגנבתי/זכיתי בהרבה דברים. הו, אני אוהב את העזר!

בעיות שולחן עגול ו-DevOps עם מנהל הפיתוח ב-Alfastrakhovanie

הדובדבן בעוגת DevOpsForum 2019 עבורי היה מפגש המליאה בן שעה עם מומחי DevOps. ארבעה משתתפי הפגישה הוזמנו להסתכל על DevOps מזוויות שונות: אנטון איסנין (אלפסרחובאני, מנהל פיתוח), Nailya Zamashkina (מעבדת Fintech, מנהלת תפעולית), אולג אגורקין (Rostelecom, מאמן Agile) ואנטון מרטיאנוב (מומחה עצמאי, הסתכל על DevOps מנקודת מבט עסקית).

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

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

בואו נדמיין שכולם התאספו והחליטו ש-DevOps נחוץ הן על ידי המוצר והן על ידי העסק והצוות. בוא נלך ליישם את זה. הכל הסתדר. נשפנו. DevOps קירב אותנו ללקוח, כעת נוכל להגשים במהירות את כל משאלותיו. כתוצאה מכך, יש לנו מחלקת Ops גדולה עם תקנות ודרישות מחמירות, והיא כל הזמן מוצאת פגמים במוצר ויוצרת שלל בקשות. יתר על כן, כל הפגמים מקבלים מעמד "דחוף", גם אם הלקוח רצה באופן בלתי צפוי לצבוע את הכפתור בצהוב במקום בירוק. הפרויקט גדל, מספר ההפצות גדל ובהתאם לכך, מספר הפגמים ואי הבנות של פונקציונליות חדשה על ידי לקוחות. Ops שוכרים עוד 10 אנשים כדי להתעדכן בדיווח על ליקויים, ופיתוח שוכר 15 נוספים כדי לעמוד בקצב סגירתם. ובמקום להציג תכונות חדשות, הצוות עובד עם אינסוף SD's, מסביר את הפונקציונליות למשתמש ואת התמיכה בו זמנית. כתוצאה מכך, גם ה-Ops וגם הפיתוח עובדים, אך הלקוח והעסק אינם מרוצים: תכונות חדשות נתקעות. מסתבר שנראה ש-DevOps קיים, אבל נראה שהוא לא קיים.

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

מקור: www.habr.com