وضعیت DevOps در روسیه 2020

چگونه می توان وضعیت چیزی را درک کرد؟

شما می توانید به نظر خود که از منابع مختلف اطلاعاتی، به عنوان مثال، انتشارات در وب سایت ها یا تجربه شکل گرفته است، تکیه کنید. می توانید از همکاران، آشنایان بپرسید. گزینه دیگر بررسی موضوعات کنفرانس است: کمیته برنامه نمایندگان فعال صنعت هستند، بنابراین ما در انتخاب موضوعات مرتبط به آنها اعتماد داریم. حوزه جداگانه تحقیق و گزارش است. اما یک مشکل وجود دارد. تحقیقات در مورد وضعیت DevOps سالانه در جهان انجام می شود، گزارش هایی توسط شرکت های خارجی منتشر می شود و تقریباً هیچ اطلاعاتی در مورد DevOps روسیه وجود ندارد.

اما روزی فرا رسیده است که چنین مطالعه ای انجام شد و امروز در مورد نتایج آن صحبت خواهیم کرد. وضعیت DevOps در روسیه به طور مشترک توسط شرکت ها مورد مطالعه قرار گرفت.اکسپرس 42"و"اونتیکو". Express 42 به شرکت های فناوری کمک می کند تا شیوه ها و ابزارهای DevOps را پیاده سازی و توسعه دهند و یکی از اولین کسانی بود که در مورد DevOps در روسیه صحبت کرد. نویسندگان این مطالعه، ایگور کوروچکین و ویتالی خاباروف، در حال انجام تحلیل و مشاوره در Express 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)، یک گزارش سالانه منتشر کردند. سال بعد، DORA و Puppet آخرین گزارش مشترک خود را منتشر کردند.

و بعد یه چیز جالب شروع شد:

در سال 2018، شرکت ها از هم جدا شدند و دو گزارش مستقل منتشر شد: یکی از Puppet، دومی از DORA همراه با گوگل. DORA به استفاده از روش‌شناسی خود با معیارهای کلیدی، نمایه‌های عملکرد و شیوه‌های مهندسی که بر معیارهای کلیدی و عملکرد کل شرکت تأثیر می‌گذارد، ادامه داده است. و Puppet رویکرد خود را با شرحی از فرآیند و تکامل DevOps ارائه کرد. اما این داستان ریشه نگرفت، در سال 2019 Puppet این متدولوژی را رها کرد و نسخه جدیدی از گزارش ها را منتشر کرد که اقدامات کلیدی و تأثیر آنها بر DevOps را از دیدگاه آنها فهرست می کرد. سپس اتفاق دیگری رخ داد: گوگل DORA را خرید و با هم گزارش دیگری منتشر کردند. شاید شما او را دیده باشید.

امسال همه چیز پیچیده شد. معروف است که Puppet نظرسنجی خود را راه اندازی کرده است. آنها یک هفته زودتر از ما این کار را کردند و قبلاً تمام شده است. ما در آن شرکت کردیم و بررسی کردیم که آنها به چه موضوعاتی علاقه دارند. اکنون Puppet در حال انجام تحلیل های خود و آماده سازی برای انتشار گزارش است.

اما هنوز هیچ اطلاعیه ای از سوی DORA و گوگل وجود ندارد. در ماه مه، زمانی که نظرسنجی معمولا شروع می شد، اطلاعاتی مبنی بر نقل مکان نیکول فورسگرن، یکی از بنیانگذاران DORA به شرکت دیگری منتشر شد. بنابراین، ما فرض کردیم که هیچ تحقیق و گزارشی از DORA در سال جاری وجود نخواهد داشت.

اوضاع در روسیه چگونه است؟

ما تحقیق DevOps را انجام نداده ایم. ما در کنفرانس‌ها صحبت کردیم، یافته‌های دیگران را بازگو کردیم، و Raiffeisenbank "وضعیت DevOps" را برای سال 2019 ترجمه کرد (می‌توانید اعلامیه آن‌ها را در Habré پیدا کنید)، با تشکر فراوان از آنها. و این همه است.

بنابراین، ما تحقیقات خود را در روسیه با استفاده از روش‌شناسی و یافته‌های DORA انجام دادیم. ما از گزارش همکاران از Raiffeisenbank برای تحقیقات خود از جمله برای همگام سازی اصطلاحات و ترجمه استفاده کردیم. و سوالات مربوط به صنعت از گزارش های DORA و پرسشنامه Puppet امسال گرفته شده است.

فرآیند تحقیق

گزارش فقط قسمت پایانی است. کل فرآیند تحقیق شامل چهار مرحله اصلی است:

در مرحله آماده سازی، با کارشناسان صنعت مصاحبه کردیم و فهرستی از فرضیه ها را تهیه کردیم. بر اساس آنها سؤالات جمع آوری شد و نظرسنجی برای کل ماه اوت راه اندازی شد. سپس خود گزارش را تحلیل و تهیه کردیم. برای DORA، این روند 6 ماه طول می کشد. ما ظرف 3 ماه ملاقات کردیم و اکنون می‌دانیم که به سختی زمان کافی داشتیم: فقط با انجام تجزیه و تحلیل متوجه می‌شوید که چه سؤالاتی را باید بپرسید.

شرکت کنندگان

همه گزارش‌های خارجی با تصویری از شرکت‌کنندگان آغاز می‌شوند و بیشتر آنها اهل روسیه نیستند. درصد پاسخ دهندگان روسی سال به سال از 5 تا 1 درصد در نوسان است و این اجازه نمی دهد هیچ نتیجه ای گرفته شود.

نقشه از گزارش Accelerate State of DevOps 2019:

در مطالعه خود، ما موفق به مصاحبه با 889 نفر شدیم - این بسیار زیاد است (دورا سالانه حدود هزار نفر را در گزارش های خود نظرسنجی می کند) و در اینجا به هدف دست یافته ایم:

درست است، همه شرکت کنندگان ما به پایان نرسیدند: درصد تکمیل کمی کمتر از نصف بود. اما حتی این برای به دست آوردن یک نمونه معرف و انجام تجزیه و تحلیل کافی بود. DORA درصد پر شدن را در گزارش های خود فاش نمی کند، بنابراین در اینجا مقایسه ای وجود ندارد.

صنایع و موقعیت ها

پاسخ دهندگان ما نشان دهنده دوازده صنعت هستند. نیمه کاره در فناوری اطلاعات پس از آن خدمات مالی، تجارت، مخابرات و غیره دنبال می شود. در میان پست ها متخصصان (توسعه دهنده، آزمایش کننده، مهندس عملیات) و کارکنان مدیریت (سرپرست تیم ها، گروه ها، مناطق، مدیران) هستند:

از هر دو یکی برای یک شرکت متوسط ​​کار می کند. هر سوم نفر در شرکت های بزرگ کار می کنند. اکثراً در تیم های حداکثر 9 نفر کار می کنند. به طور جداگانه، ما در مورد فعالیت های اصلی سؤال کردیم و اکثریت به نحوی با عملیات مرتبط هستند و حدود 40٪ در حال توسعه هستند:

بنابراین ما اطلاعاتی را برای مقایسه و تجزیه و تحلیل نمایندگان صنایع، شرکت ها، تیم های مختلف جمع آوری کردیم. همکار من ویتالی خاباروف در مورد تجزیه و تحلیل خواهد گفت.

تجزیه و تحلیل و مقایسه

ویتالی خاباروف: با تشکر فراوان از همه شرکت کنندگانی که نظرسنجی ما را تکمیل کردند، پرسشنامه ها را پر کردند و داده هایی را برای تجزیه و تحلیل بیشتر و آزمون فرضیه های ما در اختیار ما قرار دادند. و به لطف مشتریان و مشتریان خود، ما تجربه زیادی داریم که به شناسایی نگرانی های صنعت و فرموله کردن فرضیه هایی که در تحقیق خود آزمایش کرده ایم کمک کرده است.

متأسفانه، شما نمی توانید از یک طرف لیستی از سؤالات و از طرف دیگر داده ها را انتخاب کنید، به نحوی آنها را مقایسه کنید، بگویید: "بله، همه چیز اینطور کار می کند، ما درست می گفتیم" و پراکنده شوید. خیر، ما به روش‌شناسی و روش‌های آماری نیاز داریم تا مطمئن شویم اشتباه نمی‌کنیم و نتایج ما قابل اعتماد است. سپس می توانیم کارهای بعدی خود را بر اساس این داده ها بسازیم:

معیارهای کلیدی

ما متدولوژی DORA را به عنوان مبنایی در نظر گرفتیم که آنها به طور مفصل در کتاب "تسریع وضعیت DevOps" توضیح دادند. ما بررسی کردیم که آیا معیارهای کلیدی برای بازار روسیه مناسب هستند یا خیر، آیا می توان از آنها به همان روشی که DORA برای پاسخ به این سوال استفاده می کند استفاده کرد: "صنعت در روسیه چگونه با صنعت خارجی مطابقت دارد؟"

معیارهای کلیدی:

1. فرکانس استقرار هر چند وقت یکبار یک نسخه جدید از برنامه در محیط تولید (تغییرات برنامه ریزی شده، به استثنای رفع فوری و پاسخ حادثه) مستقر می شود؟
2. زمان تحویل. میانگین زمان بین انجام یک تغییر (نوشتن عملکرد به عنوان کد) و اعمال تغییر در محیط تولید چقدر است؟
3. زمان بهبودی به طور متوسط ​​چقدر طول می کشد تا یک برنامه کاربردی به محیط تولیدی پس از یک حادثه، تخریب سرویس یا کشف باگی که بر کاربران برنامه تأثیر می گذارد، بازگردانی شود؟
4. تغییرات ناموفق چند درصد از استقرارها در محیط تولید منجر به تخریب برنامه یا حوادث می شود و نیاز به اصلاح دارند (بازگشت تغییرات، ایجاد یک هات فیکس یا پچ)؟

DORA در تحقیقات خود ارتباطی بین این معیارها و عملکرد سازمانی یافته است. ما همچنین آن را در مطالعه خود آزمایش می کنیم.

اما برای اطمینان از اینکه چهار معیار کلیدی می توانند بر چیزی تأثیر بگذارند، باید درک کنید - آیا آنها به نوعی به یکدیگر مرتبط هستند؟ DORA با یک اخطار مثبت پاسخ داد: رابطه بین تغییرات ناموفق (Change Failure Rate) و سه معیار دیگر کمی ضعیف‌تر است. تقریباً همین عکس را گرفتیم. اگر زمان تحویل، فرکانس استقرار و زمان بازیابی با یکدیگر همبستگی داشته باشند (ما این همبستگی را از طریق همبستگی پیرسون و از طریق مقیاس چادوک ایجاد کردیم)، پس چنین همبستگی قوی با تغییرات ناموفق وجود ندارد.

در اصل، اکثر پاسخ دهندگان تمایل دارند پاسخ دهند که تعداد بسیار کمی از حوادث در تولید دارند. اگرچه بعداً خواهیم دید که هنوز تفاوت قابل توجهی بین گروه های پاسخ دهندگان از نظر تغییرات ناموفق وجود دارد، هنوز نمی توانیم از این معیار برای این تقسیم بندی استفاده کنیم.

ما این را به این دلیل نسبت می دهیم که (همانطور که در جریان تجزیه و تحلیل و ارتباط با برخی از مشتریان ما مشخص شد) تفاوت جزئی در درک آنچه که یک حادثه محسوب می شود وجود دارد. اگر در پنجره فنی توانستیم عملکرد سرویس خود را بازیابی کنیم، آیا این اتفاق می تواند رخ دهد؟ احتمالا نه، چون همه چیز را درست کردیم، عالی هستیم. آیا می‌توانیم آن را یک اتفاق در نظر بگیریم اگر مجبور شویم برنامه‌مان را 10 بار در یک حالت عادی و آشنا برای خودمان دوباره پخش کنیم؟ به نظر نمی رسد. بنابراین، مسئله رابطه تغییرات ناموفق با سایر معیارها همچنان باز است. ما آن را بیشتر اصلاح خواهیم کرد.

نکته مهم در اینجا این است که ما بین زمان تحویل، زمان بازیابی و فرکانس استقرار همبستگی قابل توجهی پیدا کردیم. بنابراین، ما این سه معیار را برای تقسیم بیشتر پاسخ‌دهندگان به گروه‌های عملکردی در نظر گرفتیم.

چقدر چرت زدن در گرم؟

ما از تحلیل خوشه سلسله مراتبی استفاده کردیم:

• ما پاسخ‌دهندگان را در یک فضای n بعدی توزیع می‌کنیم، جایی که مختصات هر پاسخ‌دهنده پاسخ‌های آنها به سؤالات است.
• هر پاسخ دهنده یک خوشه کوچک اعلام می شود.
• ما دو خوشه نزدیک به یکدیگر را در یک خوشه بزرگتر ترکیب می کنیم.
• ما جفت خوشه های بعدی را پیدا می کنیم و آنها را در یک خوشه بزرگتر ترکیب می کنیم.

به این ترتیب ما همه پاسخ دهندگان خود را به تعداد خوشه هایی که نیاز داریم گروه بندی می کنیم. با کمک یک دندروگرام (درختی از اتصالات بین خوشه ها) فاصله بین دو خوشه همسایه را مشاهده می کنیم. تنها چیزی که برای ما باقی می ماند این است که بین این خوشه ها حد فاصل مشخصی تعیین کنیم و بگوییم: "این دو گروه کاملاً از یکدیگر قابل تشخیص هستند زیرا فاصله بین آنها غول پیکر است."

اما یک مشکل پنهان در اینجا وجود دارد: ما هیچ محدودیتی در تعداد خوشه ها نداریم - می توانیم 2، 3، 4، 10 خوشه دریافت کنیم. و ایده اول این بود - چرا همه پاسخ دهندگان خود را به 4 گروه تقسیم نکنیم، همانطور که DORA انجام می دهد. اما متوجه شدیم که تفاوت‌های بین این گروه‌ها ناچیز می‌شود و نمی‌توان مطمئن بود که پاسخ‌دهنده واقعاً متعلق به گروه خود است و نه به گروه همسایه. ما هنوز نمی توانیم بازار روسیه را به چهار گروه تقسیم کنیم. بنابراین، ما بر روی سه پروفایل قرار گرفتیم که بین آنها تفاوت آماری معنی‌داری وجود دارد:

در مرحله بعد، نمایه را بر اساس خوشه ها تعیین کردیم: میانه را برای هر متریک برای هر گروه در نظر گرفتیم و جدولی از پروفایل های عملکرد را تهیه کردیم. در واقع، ما مشخصات عملکرد میانگین شرکت کنندگان در هر گروه را به دست آوردیم. ما سه نمایه کارایی را شناسایی کرده ایم: کم، متوسط، زیاد:

در اینجا ما فرضیه خود را تأیید کردیم که 4 معیار کلیدی برای تعیین مشخصات عملکرد مناسب هستند و آنها هم در بازارهای غربی و هم در روسیه کار می کنند. بین گروه ها تفاوت وجود دارد و از نظر آماری معنی دار است. تاکید می کنم که تفاوت معنی داری بین پروفایل های عملکرد از نظر معیار تغییرات ناموفق از نظر میانگین وجود دارد، حتی اگر در ابتدا پاسخ دهندگان را بر این پارامتر تقسیم نکردیم.

سپس این سوال مطرح می شود: چگونه از همه اینها استفاده کنیم؟

نحوه استفاده

اگر هر تیمی، 4 معیار کلیدی را در نظر بگیریم و آن را روی جدول اعمال کنیم، در 85٪ موارد یک مسابقه کامل نخواهیم داشت - این فقط یک شرکت کننده متوسط ​​است و نه آنچه در واقعیت است. همه ما (و هر تیم) کمی متفاوت هستیم.

بررسی کردیم: پاسخ‌دهندگان خود و نمایه عملکرد DORA را گرفتیم و به تعداد پاسخ‌دهندگان متناسب با این یا آن نمایه نگاه کردیم. ما متوجه شدیم که تنها 16٪ از پاسخ دهندگان به طور قطع در یکی از پروفایل ها قرار می گیرند. همه بقیه در جایی در این بین پراکنده هستند:

این بدان معناست که نمایه کارایی دامنه محدودی دارد. برای اینکه بفهمید در اولین تقریب در کجا هستید، می توانید از این جدول استفاده کنید: "اوه، به نظر می رسد ما به متوسط ​​یا بالا نزدیک تر هستیم!" اگر بفهمید که کجا می روید، این ممکن است کافی باشد. اما اگر هدف شما بهبود مستمر و مستمر است و می‌خواهید دقیقاً بدانید که کجا باید توسعه دهید و چه کاری انجام دهید، به بودجه بیشتری نیاز دارید. ما آنها را ماشین حساب می نامیم:

• ماشین حساب DORA
• Calculator Express 42* (در حال توسعه)
• توسعه خود (شما می توانید ماشین حساب داخلی خود را ایجاد کنید).

آنها برای چه چیزی مورد نیاز هستند؟ فهمیدن:

• آیا تیم درون سازمان ما مطابق با استانداردهای ما است؟
• اگر نه، آیا می توانیم در چارچوب تخصصی که شرکت ما دارد، به آن کمک کنیم، سرعت آن را افزایش دهیم؟
• اگر چنین است، آیا می‌توانیم حتی بهتر عمل کنیم؟

همچنین می توانید از آنها برای جمع آوری آمار در داخل شرکت استفاده کنید:

• چه تیم هایی داریم؟
• تیم ها را به پروفایل ها تقسیم کنید.
• ببینید: اوه، این دستورات ضعیف عمل می‌کنند (کمی بیرون نمی‌آیند)، اما اینها جالب هستند: آنها هر روز بدون خطا مستقر می‌شوند، زمان تحویل آنها کمتر از یک ساعت است.

و سپس می توانید دریابید که در شرکت ما تخصص و ابزار لازم برای آن دسته از تیم هایی وجود دارد که هنوز هم سطح نیستند.

یا اگر می‌دانید که در شرکت احساس خوبی دارید، از خیلی‌ها بهتر هستید، می‌توانید کمی گسترده‌تر به نظر برسید. این فقط صنعت روسیه است: آیا می‌توانیم تخصص لازم را در صنعت روسیه به دست آوریم تا خودمان را شتاب دهیم؟ ماشین حساب Express 42 در اینجا کمک خواهد کرد (در حال توسعه است). اگر از بازار روسیه پیشی گرفته اید، نگاه کنید ماشین حساب DORA و به بازار جهانی.

خوب. و اگر در ماشین حساب DORA در گروه Elit هستید، چه کاری باید انجام دهید؟ هیچ راه حل خوبی در اینجا وجود ندارد. شما به احتمال زیاد در خط مقدم صنعت هستید و شتاب و اطمینان بیشتر از طریق تحقیق و توسعه داخلی و صرف منابع بیشتر امکان پذیر است.

بیایید به شیرین ترین - مقایسه برویم.

مقایسه

ما در ابتدا می خواستیم صنعت روسیه را با صنعت غرب مقایسه کنیم. اگر به طور مستقیم مقایسه کنیم، می بینیم که پروفایل های کمتری داریم، و آنها کمی بیشتر با یکدیگر مخلوط شده اند، مرزها کمی تارتر می شوند:

نوازندگان نخبه ما در میان هنرمندان برتر پنهان هستند، اما آنها آنجا هستند - این افراد نخبه و تک شاخ هستند که به ارتفاعات قابل توجهی رسیده اند. در روسیه، تفاوت بین پروفایل نخبگان و مشخصات بالا هنوز به اندازه کافی قابل توجه نیست. ما فکر می کنیم که در آینده این جدایی به دلیل افزایش فرهنگ مهندسی، کیفیت اجرای شیوه های مهندسی و تخصص در شرکت ها رخ خواهد داد.

اگر به مقایسه مستقیم در صنعت روسیه برویم، می بینیم که تیم های High Profile از همه لحاظ بهتر هستند. ما همچنین فرضیه خود را تأیید کردیم که بین این معیارها و عملکرد سازمانی رابطه وجود دارد: تیم‌های با سابقه بسیار بیشتر نه تنها به اهداف می‌رسند، بلکه از آنها نیز فراتر می‌روند.
بیایید به تیم های با مشخصات بالا تبدیل شویم و در اینجا متوقف نشویم:

اما امسال سال ویژه ای است و ما تصمیم گرفتیم بررسی کنیم که شرکت ها در یک بیماری همه گیر چگونه عمل می کنند: تیم های با سابقه بسیار بهتر از میانگین صنعت کار می کنند و احساس بهتری دارند:

• احتمال عرضه محصولات جدید 1,5 تا 2 برابر بیشتر است.
• احتمال بهبود قابلیت اطمینان و/یا عملکرد زیرساخت برنامه 2 برابر بیشتر است.

یعنی شایستگی‌هایی که قبلاً داشتند به آنها کمک کرد سریع‌تر توسعه دهند، محصولات جدید را عرضه کنند، محصولات موجود را اصلاح کنند و در نتیجه بازارهای جدید و کاربران جدید را فتح کنند:

چه چیز دیگری به تیم های ما کمک کرد؟

شیوه های مهندسی

من در مورد یافته های مهم برای هر تمرینی که آزمایش کردیم به شما خواهم گفت. شاید چیز دیگری به تیم ها کمک کند، اما ما در مورد DevOps صحبت می کنیم. و در DevOps، ما شاهد تفاوت بین تیم هایی با پروفایل های مختلف هستیم.

پلتفرم به عنوان یک سرویس

ما رابطه معناداری بین سن پلت فرم و مشخصات تیم پیدا نکردیم: پلتفرم‌ها تقریباً در یک زمان برای تیم‌های پایین و تیم‌های بالا ظاهر شدند. اما برای دومی، پلتفرم به طور متوسط ​​خدمات بیشتر و رابط های برنامه نویسی بیشتری را برای کنترل از طریق کد برنامه ارائه می دهد. و تیم‌های پلتفرم بیشتر به توسعه‌دهندگان و تیم‌های خود کمک می‌کنند تا از پلتفرم استفاده کنند، مشکلات و حوادث مرتبط با پلتفرم خود را بیشتر حل کنند و به تیم‌های دیگر آموزش دهند.

زیرساخت به عنوان کد

اینجا همه چیز کاملا استاندارد است. ما رابطه ای بین خودکار کردن کار کد زیرساخت و مقدار اطلاعات ذخیره شده در مخزن زیرساخت پیدا کرده ایم. دستورات High Profile اطلاعات بیشتری را در مخازن ذخیره می کنند: این پیکربندی زیرساخت، خط لوله CI / CD، تنظیمات محیط و پارامترهای ساخت است. آنها این اطلاعات را بیشتر ذخیره می کنند، با کد زیرساخت بهتر کار می کنند و فرآیندها و وظایف بیشتری را برای کار با کد زیرساخت خودکار می کنند.

جالب اینجاست که در تست های زیرساختی تفاوت معنی داری مشاهده نکردیم. من این را به این واقعیت نسبت می‌دهم که تیم‌های با مشخصات بالا به طور کلی اتوماسیون تست بیشتری دارند. شاید آنها نباید به طور جداگانه توسط آزمایش‌های زیرساخت منحرف شوند، بلکه باید آزمایش‌هایی که با آن برنامه‌ها را بررسی می‌کنند و به لطف آنها قبلاً می‌بینند چه چیزی و کجا شکسته‌اند.

یکپارچه سازی و تحویل

خسته کننده ترین بخش، زیرا ما تأیید کردیم که هرچه اتوماسیون بیشتری داشته باشید، بهتر با کد کار کنید، احتمال اینکه نتایج بهتری بگیرید بیشتر است.

معماری

ما می‌خواستیم ببینیم میکروسرویس‌ها چگونه بر عملکرد تأثیر می‌گذارند. در حقیقت، آنها اینطور نیستند، زیرا استفاده از میکروسرویس ها با افزایش شاخص های عملکرد همراه نیست. میکروسرویس ها هم برای دستورات High profile و هم برای دستورات Low Profile استفاده می شوند.

اما آنچه قابل توجه است این است که برای تیم های بالا، انتقال به معماری میکروسرویس به آنها اجازه می دهد تا به طور مستقل خدمات خود را توسعه داده و عرضه کنند. اگر معماری به توسعه‌دهندگان اجازه می‌دهد که مستقل عمل کنند، بدون اینکه منتظر کسی خارج از تیم باشند، این یک صلاحیت کلیدی برای افزایش سرعت است. در این مورد، میکروسرویس ها کمک می کنند. و فقط اجرای آنها نقش زیادی ندارد.

چگونه همه اینها را کشف کردیم؟

ما یک برنامه بلندپروازانه برای تکرار کامل روش DORA داشتیم، اما فاقد منابع بودیم. اگر DORA از حمایت مالی زیادی استفاده می کند و تحقیقات آنها نیم سال طول می کشد، ما تحقیقات خود را در مدت کوتاهی انجام دادیم. ما می خواستیم مانند DORA یک مدل DevOps بسازیم و در آینده این کار را انجام خواهیم داد. تا کنون خود را به نقشه های حرارتی محدود کرده ایم:

ما به توزیع شیوه‌های مهندسی در بین تیم‌ها در هر پروفایل نگاه کردیم و دریافتیم که تیم‌های با مشخصات بالا، به‌طور متوسط، احتمال بیشتری برای استفاده از شیوه‌های مهندسی دارند. شما می توانید در مورد همه اینها در ما بیشتر بخوانید گزارش.

برای تغییر، بیایید از آمارهای پیچیده به آمارهای ساده سوئیچ کنیم.

چه چیز دیگری کشف کرده ایم؟

ابزارهای

مشاهده می کنیم که بیشتر دستورات توسط سیستم عامل خانواده لینوکس استفاده می شود. اما ویندوز هنوز در روند است - حداقل یک چهارم پاسخ دهندگان ما به استفاده از یکی از نسخه های آن اشاره کردند. به نظر می رسد بازار این نیاز را دارد. بنابراین، می توانید این شایستگی ها را توسعه دهید و در کنفرانس ها ارائه دهید.

در میان ارکسترها، این برای هیچ کس پنهان نیست، Kubernetes پیشتاز است (52٪). ارکستراتور بعدی Docker Swarm (حدود 12٪) است. محبوب ترین سیستم های CI جنکینز و گیت لب هستند. محبوب ترین سیستم مدیریت پیکربندی Ansible است و پس از آن Shell محبوب ما قرار دارد.

آمازون در حال حاضر پیشروترین ارائه دهنده میزبانی ابری است. سهم ابرهای روسیه به تدریج در حال افزایش است. سال آینده جالب خواهد بود که ببینیم ارائه دهندگان ابری روسی چه احساسی خواهند داشت و آیا سهم بازار آنها افزایش می یابد یا خیر. آنها هستند، می توان از آنها استفاده کرد، و این خوب است:

من زمین را به ایگور می سپارم که آمار بیشتری ارائه می دهد.

اشاعه شیوه ها

ایگور کوروچکین: به طور جداگانه، از پاسخ دهندگان خواستیم که نحوه توزیع شیوه های مهندسی در نظر گرفته شده در شرکت را مشخص کنند. در اکثر شرکت ها، یک رویکرد ترکیبی، متشکل از مجموعه ای متفاوت از الگوها وجود دارد، و پروژه های آزمایشی بسیار محبوب هستند. همچنین تفاوت جزئی بین پروفایل ها مشاهده کردیم. هنگامی که تیم‌های کوچکی از متخصصان فرآیندهای کاری، ابزارها را تغییر می‌دهند و شیوه‌های موفقیت‌آمیز را با سایر تیم‌ها به اشتراک می‌گذارند، نمایندگان رده بالا اغلب از الگوی «ابتکار از پایین» استفاده می‌کنند. در Medium، این یک ابتکار از بالا به پایین است که از طریق ایجاد جوامع و مراکز برتر، کل شرکت را تحت تأثیر قرار می دهد:

Agile و DevOps

مسئله ارتباط میان Agile و DevOps اغلب در صنعت مورد بحث قرار می گیرد. این موضوع در گزارش وضعیت چابک برای سال 2019/2020 نیز مطرح شده است، بنابراین تصمیم گرفتیم نحوه ارتباط فعالیت های Agile و DevOps در شرکت ها را با هم مقایسه کنیم. ما متوجه شدیم که DevOps بدون Agile نادر است. برای نیمی از پاسخ دهندگان، گسترش Agile خیلی زودتر شروع شد و حدود 20٪ شروع همزمان را مشاهده کردند و یکی از نشانه های Low Profile عدم وجود روش های Agile و DevOps است:

توپولوژی های دستوری

در پایان سال گذشته، کتابتوپولوژی های تیم"، که چارچوبی را برای توصیف توپولوژی های فرمان پیشنهاد می کند. برای ما جالب شد که آیا برای شرکت های روسی قابل اجرا است یا خیر. و ما این سوال را پرسیدیم: "چه الگوهایی پیدا می کنید؟".

تیم های زیرساخت در نیمی از پاسخ دهندگان و همچنین تیم های جداگانه برای توسعه، آزمایش و بهره برداری مشاهده می شوند. تیم‌های DevOps مجزا 45 درصد را به خود اختصاص دادند که در این میان نمایندگان High رایج‌تر هستند. در مرحله بعدی تیم های چند کاره می آیند که در High نیز رایج تر هستند. دستورات SRE جداگانه در پروفایل های High و Medium ظاهر می شوند و به ندرت در نمایه Low دیده می شوند:

نسبت DevQaOps

ما این سوال را در فیس بوک از رهبر تیم تیم پلت فرم Skyeng دیدیم - او به نسبت توسعه دهندگان، آزمایش کنندگان و مدیران در شرکت ها علاقه مند بود. ما آن را پرسیدیم و بر اساس نمایه‌ها به پاسخ‌ها نگاه کردیم: نمایندگان با مشخصات بالا، مهندسان تست و عملیات کمتری برای هر توسعه‌دهنده دارند:

برنامه سال 2021

در برنامه های سال آینده، پاسخ دهندگان به فعالیت های زیر اشاره کردند:

در اینجا می توانید تقاطع با کنفرانس DevOps Live 2020 را ببینید. ما برنامه را به دقت بررسی کردیم:

• زیرساخت به عنوان یک محصول
• تبدیل DevOps
• توزیع شیوه های DevOps
• DevSecOps
• باشگاه های مورد و بحث

اما زمان ارائه ما برای پوشش همه موضوعات کافی نیست. پشت صحنه:

• پلتفرم به عنوان یک خدمات و به عنوان یک محصول؛
• زیرساخت به عنوان کد، محیط ها و ابرها.
• ادغام و تحویل مستمر؛
• معماری؛
• الگوهای DevSecOps؛
• تیم های پلت فرم و چند کاره.

گزارش ما یک 50 صفحه حجیم دریافت کردیم و می توانید آن را با جزئیات بیشتر ببینید.

جمعبندی

امیدواریم که تحقیق و گزارش ما به شما انگیزه دهد تا رویکردهای جدید توسعه، آزمایش و عملیات را آزمایش کنید، و همچنین به شما کمک کند در مسیریابی، مقایسه خود با سایر شرکت کنندگان در مطالعه، و شناسایی زمینه هایی که می توانید رویکردهای خود را بهبود بخشید.

نتایج اولین مطالعه وضعیت DevOps در روسیه:

• معیارهای کلیدی ما دریافتیم که معیارهای کلیدی (زمان تحویل، فرکانس استقرار، زمان بازیابی و خرابی‌های تغییر) برای تحلیل اثربخشی فرآیندهای توسعه، آزمایش و عملیات مناسب هستند.
• پروفایل های بالا، متوسط، پایین. بر اساس داده‌های جمع‌آوری‌شده، می‌توانیم گروه‌های مختلف آماری بالا، متوسط، پایین را با ویژگی‌های متمایز از نظر معیارها، شیوه‌ها، فرآیندها و ابزار تشخیص دهیم. نمایندگان High profile نتایج بهتری نسبت به Low نشان می دهند. آنها بیشتر به اهداف خود دست می یابند و از آنها فراتر می روند.
• شاخص ها، بیماری همه گیر و برنامه های سال 2021. یک شاخص ویژه در سال جاری نحوه مقابله شرکت ها با همه گیری است. نمایندگان عالی عملکرد بهتری داشتند، افزایش تعامل کاربر را تجربه کردند و دلایل اصلی موفقیت فرآیندهای توسعه کارآمد و فرهنگ مهندسی قوی بود.
• شیوه ها، ابزارها و توسعه آنها DevOps. برنامه‌های اصلی شرکت‌ها برای سال آینده شامل توسعه روش‌ها و ابزارهای DevOps، معرفی شیوه‌های DevSecOps و تغییرات در ساختار سازمانی است. و پیاده سازی و توسعه موثر شیوه های DevOps با کمک پروژه های آزمایشی، تشکیل جوامع و مراکز برتر، ابتکارات در سطوح بالا و پایین شرکت انجام می شود.

ما دوست داریم نظرات، داستان ها، بازخوردهای شما را بشنویم. ما از همه کسانی که در مطالعه شرکت کردند تشکر می کنیم و منتظر مشارکت شما در سال آینده هستیم.

منبع: www.habr.com