מצב ה-DevOps ברוסיה 2020

איך להבין את המצב של משהו?

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

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

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

מחקר DevOps

השיחה נפתחה על ידי איגור קורוצ'קין.

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

כאן יש לנו את הבעיה הראשונה ואחריה עוד שתיים:

1. אין לנו נתונים לשנה שעברה. מצב ה-DevOps ברוסיה לא מעניין אף אחד;
2. מֵתוֹדוֹלוֹגִיָה. לא ברור איך לבדוק השערות, איך לבנות שאלות, איך לנתח, להשוות תוצאות, למצוא קשרים;
3. טרמינולוגיה. כל הדוחות הם באנגלית, נדרש תרגום, מסגרת DevOps משותפת עדיין לא הומצאה וכל אחד מגיע עם משלו.

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

היסטוריה

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

בשנת 2013 הופיעה IT Revolution, המוציאה לאור של כל הספרים הגדולים על DevOps. יחד עם Puppet, הם הכינו את הפרסום הראשון של State of DevOps, שבו הופיעו לראשונה 4 מדדי מפתח. בשנה שלאחר מכן, ThoughtWorks, חברת ייעוץ הידועה במכ"מים הטכנולוגיים הקבועים שלה על שיטות וכלים בתעשייה, השתלבה. ובשנת 2015 נוסף קטע עם מתודולוגיה, והתברר כיצד הם מבצעים את הניתוח.

בשנת 2016, מחברי המחקר, לאחר שיצרו את החברה שלהם DORA (DevOps Research and Assessment), פרסמו דו"ח שנתי. בשנה שלאחר מכן, DORA ובובה פרסמו את הדו"ח המשותף האחרון שלהם.

ואז התחיל משהו מעניין:

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

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

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

איך המצב ברוסיה?

לא עשינו מחקר DevOps. דיברנו בכנסים, סיפרנו מחדש על ממצאים של אנשים אחרים, ו-Raiffeisenbank תרגם את "State of DevOps" לשנת 2019 (תוכל למצוא את ההכרזה שלהם ב-Habré), הרבה בזכותם. וזה הכל.

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

תהליך מחקר

הדו"ח הוא רק החלק האחרון. כל תהליך המחקר מורכב מארבעה שלבים עיקריים:

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

משתתפים

כל הדיווחים הזרים מתחילים עם דיוקן של המשתתפים, ורובם אינם מרוסיה. אחוז המשיבים הרוסים נע בין 5 ל-1% משנה לשנה, וזה לא מאפשר להסיק מסקנות.

מפה מדוח ה-Accelerate State of DevOps 2019:

במחקר שלנו, הצלחנו לראיין 889 אנשים - זה די הרבה (דורה סוקרת כאלף איש מדי שנה בדוחות שלה) והנה השגנו את המטרה:

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

תעשיות ותפקידים

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

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

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

ניתוח והשוואה

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

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

מדדי מפתח

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

מדדי מפתח:

1. תדירות פריסה. באיזו תדירות נפרסת גרסה חדשה של האפליקציה בסביבת הייצור (שינויים מתוכננים, לא כולל תיקונים חמים ותגובה לאירועים)?
2. זמן משלוח. מהו הזמן הממוצע בין ביצוע שינוי (כתיבת פונקציונליות כקוד) לבין פריסת השינוי בסביבת הייצור?
3. זמן החלמה. כמה זמן לוקח בממוצע לשחזר אפליקציה לסביבת ייצור לאחר תקרית, פגיעה בשירות או גילוי של באג שמשפיע על משתמשי האפליקציה?
4. שינויים לא מוצלחים. איזה אחוז של פריסות בסביבת הייצור מובילים לפגיעה באפליקציה או לאירועים ודורשות תיקון (החזרת שינויים, פיתוח של תיקון חם או תיקון)?

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

אבל כדי לוודא שארבעת מדדי המפתח יכולים להשפיע על משהו, אתה צריך להבין - האם הם קשורים איכשהו זה לזה? DORA השיבה בחיוב עם הסתייגות אחת: הקשר בין שינויים לא מוצלחים (Change Failure Rate) לבין שלושה מדדים אחרים מעט חלש יותר. קיבלנו בערך את אותה תמונה. אם זמן אספקה, תדירות פריסה וזמן התאוששות נמצאים בקורלציה זה עם זה (קבענו את המתאם הזה באמצעות מתאם פירסון ודרך סולם Chaddock), אז אין מתאם חזק כל כך עם שינויים לא מוצלחים.

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

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

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

כמה לתלות בגרמים?

השתמשנו בניתוח אשכולות היררכי:

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

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

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

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

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

ואז נשאלת השאלה: איך להשתמש בכל זה?

כיצד להשתמש

אם ניקח קבוצה כלשהי, 4 מדדי מפתח וניישם את זה על הטבלה, אז ב-85% מהמקרים לא נקבל התאמה מלאה - זה רק משתתף ממוצע, ולא מה שיש במציאות. כולנו (וכל קבוצה) מעט שונים.

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

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

• מחשבון DORA
• מחשבון אקספרס 42* (בפיתוח)
• פיתוח משלך (ניתן ליצור מחשבון פנימי משלך).

בשביל מה הם צריכים? להבין:

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

אתה יכול גם להשתמש בהם כדי לאסוף נתונים סטטיסטיים בתוך החברה:

• איזה קבוצות יש לנו?
• חלקו צוותים לפרופילים;
• ראה: הו, הפקודות האלה לא מתפקדות (הן לא נשלפות קצת), אבל הן מגניבות: הן פורסות כל יום, ללא שגיאות, יש להן זמן אספקה ​​של פחות משעה.

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

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

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

נעבור למתוק - השוואה.

השוואה

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

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

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

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

• סבירות גבוהה פי 1,5-2 לשחרר מוצרים חדשים,
• סבירות גבוהה פי 2 לשפר את האמינות ו/או הביצועים של תשתית האפליקציה.

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

מה עוד עזר לצוותים שלנו?

שיטות הנדסה

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

פלטפורמה כשירות

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

תשתית כקוד

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

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

אינטגרציה ואספקה

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

אדריכלות

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

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

איך גילינו את כל זה?

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

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

לשם שינוי, בואו נעבור מסטטיסטיקה מורכבת לפשוטה.

מה עוד גילינו?

כלי עבודה

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

בקרב המתזמרים, זה לא סוד לאף אחד, קוברטס בראש (52%). המתזמר הבא בתור הוא Docker Swarm (כ-12%). מערכות ה-CI הפופולריות ביותר הן Jenkins ו-GitLab. מערכת ניהול התצורה הפופולרית ביותר היא Ansible, ואחריה Shell האהובה שלנו.

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

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

הפצת שיטות עבודה

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

Agile ו-DevOps

שאלת הקשר בין Agile ל-DevOps נידונה לעתים קרובות בתעשייה. נושא זה מועלה גם בדוח מצב האג'יל לשנת 2019/2020, אז החלטנו להשוות את הקשר בין פעילויות Agile ו-DevOps בחברות. גילינו ש-DevOps ללא Agile הוא נדיר. עבור מחצית מהנשאלים, התפשטות ה-Agile החלה הרבה יותר מוקדם, וכ-20% צפו בהתחלה בו-זמנית, ואחד הסימנים לפרופיל נמוך יהיה היעדר שיטות Agile ו-DevOps:

טופולוגיות פקודות

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

צוותי תשתית נצפים במחצית מהנשאלים, וכן צוותים נפרדים לפיתוח, בדיקה ותפעול. צוותי DevOps נפרדים ציינו 45%, ביניהם נפוצים יותר נציגי High. לאחר מכן מגיעים צוותים צולבים, שגם הם נפוצים יותר ב-High. פקודות SRE נפרדות מופיעות בפרופילים הגבוהים והבינוניים ונראות רק לעתים רחוקות בפרופיל הנמוך:

יחס DevQaOps

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

תוכניות לשנת 2021

בתוכניות לשנה הבאה ציינו המשיבים את הפעילויות הבאות:

כאן תוכלו לראות את ההצטלבות עם כנס DevOps Live 2020. סקרנו בקפידה את התוכנית:

• תשתית כמוצר
• טרנספורמציה של DevOps
• הפצה של שיטות DevOps
• DevSecOps
• מועדוני מקרה ודיונים

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

• פלטפורמה כשירות וכמוצר;
• תשתית כקוד, סביבות ועננים;
• שילוב ואספקה ​​מתמשכים;
• ארכיטקטורה;
• דפוסי DevSecOps;
• צוותי פלטפורמה וצוותים מגוונים.

דווח יש לנו עמודים נרחבים, 50 עמודים, ותוכלו לראות אותו ביתר פירוט.

סכום

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

תוצאות המחקר הראשון על מצב ה-DevOps ברוסיה:

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

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

מקור: www.habr.com