حالة 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 ، أعدوا أول منشور عن حالة DevOps ، حيث ظهرت 4 مقاييس رئيسية لأول مرة. في العام التالي ، شاركت ThoughtWorks ، وهي شركة استشارية معروفة بتقنية الرادارات المنتظمة في ممارسات وأدوات الصناعة. وفي عام 2015 ، تمت إضافة قسم بالمنهجية ، وأصبح من الواضح كيفية إجراء التحليل.

في عام 2016 ، نشر مؤلفو الدراسة ، بعد أن أنشأوا شركتهم الخاصة DORA (أبحاث وتقييم DevOps) ، تقريرًا سنويًا. في العام التالي ، أصدرت DORA و Puppet تقريرهما المشترك الأخير.

ثم بدأ شيء مثير للاهتمام:

في عام 2018 ، انقسمت الشركتان وتم إصدار تقريرين مستقلين: الأول من Puppet ، والثاني من DORA بالاشتراك مع Google. واصلت DORA الاستفادة من منهجيتها من خلال المقاييس الرئيسية وملفات تعريف الأداء والممارسات الهندسية التي تؤثر على المقاييس الرئيسية والأداء على مستوى الشركة. وقدمت Puppet نهجها الخاص مع وصف العملية وتطور DevOps. لكن القصة لم تتجذر ، ففي عام 2019 تخلت شركة Puppet عن هذه المنهجية وأصدرت نسخة جديدة من التقارير ، والتي أدرجت الممارسات الرئيسية وكيف تؤثر على DevOps من وجهة نظرهم. ثم حدث حدث آخر: اشترت Google DORA ، وأصدرا معًا تقريرًا آخر. ربما تكون قد رأيته.

هذا العام ، تعقدت الأمور. من المعروف أن Puppet قد أطلقت مسحها الخاص. لقد فعلوا ذلك قبلنا بأسبوع ، وقد انتهى بالفعل. شاركنا فيه وبحثنا في الموضوعات التي يهتمون بها. الآن تقوم شركة Puppet بتحليلها وتستعد لنشر التقرير.

لكن لا يوجد حتى الآن إعلان من DORA و Google. في شهر مايو ، عندما بدأ الاستطلاع عادة ، وردت معلومات تفيد بأن نيكول فورسغرين ، أحد مؤسسي 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 حوالي ألف شخص سنويًا في تقاريرها) وهنا حققنا الهدف:

صحيح ، لم يصل جميع المشاركين إلى النهاية: تبين أن نسبة الإنجاز أقل بقليل من النصف. ولكن حتى هذا كان كافياً للحصول على عينة تمثيلية وإجراء تحليل. لا تكشف DORA عن نسب الملء في تقاريرها ، لذا لا توجد مقارنة هنا.

الصناعات والمناصب

يمثل المجيبون لدينا عشرات الصناعات. نصف العمل في تقنية المعلومات. ويلي ذلك الخدمات المالية ، والتجارة ، والاتصالات السلكية واللاسلكية وغيرها. من بين الوظائف المتخصصين (المطور ، المختبِر ، مهندس العمليات) وموظفو الإدارة (رؤساء الفرق ، المجموعات ، المناطق ، المديرين):

يعمل واحد من كل اثنين في شركة متوسطة الحجم. يعمل كل شخص ثالث في الشركات الكبيرة. يعمل معظمهم في فرق تصل إلى 9 أشخاص. بشكل منفصل ، سألنا عن الأنشطة الرئيسية ، والأغلبية مرتبطة بطريقة أو بأخرى بالعملية ، وحوالي 40٪ منخرطون في التطوير:

لذلك قمنا بجمع معلومات للمقارنة والتحليل لممثلي الصناعات والشركات والفرق المختلفة. سيتحدث زميلي فيتالي خاباروف عن التحليل.

التحليل والمقارنة

فيتالي خابروف: شكراً جزيلاً لجميع المشاركين الذين أكملوا الاستبيان ، وملأوا الاستبيانات وزودونا بالبيانات لمزيد من التحليل والاختبار لفرضياتنا. وبفضل عملائنا وعملائنا ، لدينا ثروة من الخبرة التي ساعدت في تحديد مخاوف الصناعة وصياغة الفرضيات التي اختبرناها في بحثنا.

لسوء الحظ ، لا يمكنك فقط أخذ قائمة بالأسئلة من جهة والبيانات من جهة أخرى ، ومقارنتها بطريقة أو بأخرى ، وقل: "نعم ، كل شيء يسير على هذا النحو ، كنا على حق" ونتفرق. لا ، المنهجية والأساليب الإحصائية مطلوبة للتأكد من أننا لسنا مخطئين وأن استنتاجاتنا موثوقة. ثم يمكننا بناء عملنا الإضافي بناءً على هذه البيانات:

مقاييس رئيسية

اتخذنا منهجية DORA كأساس ، والتي وصفوها بالتفصيل في كتاب "Accelerate State of DevOps". لقد تحققنا مما إذا كانت المقاييس الرئيسية مناسبة للسوق الروسي ، وما إذا كان يمكن استخدامها بنفس الطريقة التي تستخدمها DORA للإجابة على السؤال: "كيف تتوافق الصناعة في روسيا مع الصناعة الأجنبية؟"

مقاييس رئيسية:

1. تردد النشر. كم مرة يتم نشر إصدار جديد من التطبيق في بيئة الإنتاج (التغييرات المخطط لها ، باستثناء الإصلاحات العاجلة والاستجابة للحوادث)؟
2. موعد التسليم. ما هو متوسط ​​الوقت بين إجراء تغيير (كتابة وظيفة كرمز) ونشر التغيير في بيئة الإنتاج؟
3. وقت الانتعاش. كم من الوقت يستغرق في المتوسط ​​لاستعادة تطبيق إلى بيئة إنتاج بعد وقوع حادث أو تدهور الخدمة أو اكتشاف خطأ يؤثر على مستخدمي التطبيق؟
4. تغييرات غير ناجحة. ما هي النسبة المئوية لعمليات النشر في بيئة الإنتاج التي تؤدي إلى تدهور التطبيق أو الحوادث وتتطلب العلاج (التراجع عن التغييرات أو تطوير إصلاح عاجل أو تصحيح)؟

وجدت DORA في بحثها علاقة بين هذه المقاييس والأداء التنظيمي. نقوم أيضًا باختباره في دراستنا.

ولكن للتأكد من أن المقاييس الرئيسية الأربعة يمكن أن تؤثر على شيء ما ، عليك أن تفهم - هل ترتبط ببعضها البعض بطريقة أو بأخرى؟ أجاب DORA بالإيجاب مع تحذير واحد: العلاقة بين التغييرات غير الناجحة (تغيير معدل الفشل) وثلاثة مقاييس أخرى أضعف قليلاً. لقد حصلنا على نفس الصورة تقريبا. إذا كان وقت التسليم وتكرار النشر ووقت الاسترداد مرتبطين ببعضهما البعض (لقد أنشأنا هذا الارتباط من خلال ارتباط بيرسون ومن خلال مقياس تشادوك) ، فلا توجد علاقة قوية كهذه مع التغييرات غير الناجحة.

من حيث المبدأ ، يميل معظم المستجيبين للإجابة بأن لديهم عددًا صغيرًا من الحوادث في الإنتاج. على الرغم من أننا سنرى لاحقًا أنه لا يزال هناك فرق كبير بين مجموعات المستجيبين من حيث التغييرات غير الناجحة ، لا يمكننا بعد استخدام هذا المقياس لهذا التقسيم.

نعزو هذا إلى حقيقة أنه (كما اتضح أثناء التحليل والتواصل مع بعض عملائنا) هناك اختلاف طفيف في تصور ما يعتبر حادثًا. إذا تمكنا من استعادة أداء خدمتنا أثناء النافذة الفنية ، فهل يمكن اعتبار ذلك حادثًا؟ ربما لا ، لأننا أصلحنا كل شيء ، نحن رائعون. هل يمكننا اعتبارها حادثة إذا اضطررنا لإعادة تطبيقنا 10 مرات في وضع عادي ومألوف بالنسبة لنا؟ لا يبدو الأمر كذلك. لذلك ، تظل مسألة علاقة التغييرات غير الناجحة بالمقاييس الأخرى مفتوحة. سنقوم بتنقيحها أكثر.

المهم هنا أننا وجدنا ارتباطًا كبيرًا بين أوقات التسليم ووقت الاسترداد وتكرار النشر. لذلك ، أخذنا هذه المقاييس الثلاثة لتقسيم المستجيبين إلى مجموعات أداء.

كم لتعليق غرام؟

استخدمنا التحليل العنقودي الهرمي:

• نقوم بتوزيع المستجيبين على مساحة ذات أبعاد n ، حيث يكون تنسيق كل مستجيب هو إجاباتهم على الأسئلة.
• يتم الإعلان عن كل مجيب على أنه كتلة صغيرة.
• نقوم بدمج المجموعتين الأقرب لبعضهما البعض في مجموعة أكبر.
• نجد الزوج التالي من المجموعات ودمجها في كتلة أكبر.

هذه هي الطريقة التي نجمع بها جميع المشاركين في الاستطلاع في عدد المجموعات التي نحتاجها. بمساعدة مخطط dendrogram (شجرة من الوصلات بين المجموعات) ، نرى المسافة بين مجموعتين متجاورتين. كل ما تبقى لنا هو وضع حد معين للمسافة بين هذه المجموعات والقول: "هاتان المجموعتان مختلفتان تمامًا عن بعضهما البعض لأن المسافة بينهما هائلة."

ولكن هناك مشكلة خفية هنا: ليس لدينا قيود على عدد المجموعات - يمكننا الحصول على 2 ، 3 ، 4 ، 10 مجموعات. وكانت الفكرة الأولى - لماذا لا نقسم جميع المشاركين في الاستطلاع إلى 4 مجموعات ، كما تفعل DORA. لكننا وجدنا أن الفروق بين هذه المجموعات أصبحت ضئيلة ، ولا يمكننا التأكد من أن المستفتى ينتمي حقًا إلى مجموعته وليس إلى المجموعة المجاورة. لا يمكننا بعد تقسيم السوق الروسية إلى أربع مجموعات. لذلك ، استقرنا على ثلاثة ملفات تعريف يوجد بينها فرق ذو دلالة إحصائية:

بعد ذلك ، حددنا ملف التعريف حسب المجموعات: أخذنا الوسيط لكل مقياس لكل مجموعة وقمنا بتجميع جدول بملفات تعريف الأداء. في الواقع ، حصلنا على ملفات تعريف أداء المشارك العادي في كل مجموعة. لقد حددنا ثلاثة ملفات تعريف للكفاءة: منخفضة ، متوسطة ، عالية:

أكدنا هنا فرضيتنا القائلة بأن 4 مقاييس رئيسية مناسبة لتحديد ملف تعريف الأداء ، وتعمل في الأسواق الغربية والروسية. هناك فرق بين المجموعات وهو ذو دلالة إحصائية. أؤكد أن هناك فرقًا كبيرًا بين ملفات تعريف الأداء من حيث مقياس التغييرات غير الناجحة من حيث المتوسط ​​، على الرغم من أننا لم نقسم المستجيبين في البداية على هذه المعلمة.

ثم السؤال الذي يطرح نفسه: كيف تستخدم كل هذا؟

كيفية الاستخدام

إذا أخذنا أي فريق ، و 4 مقاييس رئيسية وقمنا بتطبيقها على الجدول ، فلن نحصل على تطابق كامل في 85٪ من الحالات - هذا مجرد مشارك متوسط ​​، وليس ما هو موجود في الواقع. نحن جميعًا (وكل فريق) مختلفون قليلاً.

تحققنا: لقد أخذنا المشاركين وملف أداء DORA ، ونظرنا في عدد المستجيبين المناسبين لهذا الملف الشخصي أو ذاك. وجدنا أن 16٪ فقط من المستجيبين وقعوا بالتأكيد في أحد الملفات الشخصية. كل ما تبقى مبعثر في مكان ما بين:

هذا يعني أن ملف تعريف الكفاءة له نطاق محدود. لفهم موقعك في التقدير التقريبي الأول ، يمكنك استخدام هذا الجدول: "أوه ، يبدو أننا أقرب إلى متوسط ​​أو مرتفع!" إذا فهمت إلى أين تتجه بعد ذلك ، فقد يكون هذا كافيًا. ولكن إذا كان هدفك هو التحسين المستمر والمستمر ، وتريد معرفة المزيد بالضبط أين تتطور وماذا تفعل ، فحينئذٍ ستكون هناك حاجة إلى أموال إضافية. أطلقنا عليهم اسم الآلات الحاسبة:

• آلة حاسبة DORA
• Calculator Express 42 * (قيد التطوير)
• التطوير الخاص (يمكنك إنشاء الآلة الحاسبة الداخلية الخاصة بك).

ما الذي يحتاجون إليه؟ لفهم:

• هل الفريق داخل مؤسستنا يصل إلى معاييرنا؟
• إذا لم يكن الأمر كذلك ، فهل يمكننا مساعدتها ، وتسريعها في إطار الخبرة التي تمتلكها شركتنا؟
• إذا كان الأمر كذلك ، فهل يمكننا أن نفعل ما هو أفضل؟

يمكنك أيضًا استخدامها لجمع الإحصائيات داخل الشركة:

• ما هي الفرق التي لدينا؟
• تقسيم الفرق إلى ملفات شخصية ؛
• انظر: أوه ، هذه الأوامر ضعيفة الأداء (لا تنسحب قليلاً) ، لكنها رائعة: يتم نشرها كل يوم ، دون أخطاء ، ولديها مهلة أقل من ساعة.

وبعد ذلك يمكنك معرفة أنه يوجد داخل شركتنا الخبرة والأدوات اللازمة لتلك الفرق التي لم تصل بعد إلى المستوى المطلوب.

أو ، إذا فهمت أنك تشعر بالرضا داخل الشركة ، فأنت أفضل من كثيرين ، ثم يمكنك أن تبدو أوسع قليلاً. هذه هي الصناعة الروسية فقط: هل يمكننا الحصول على الخبرة اللازمة في الصناعة الروسية لتسريع أنفسنا؟ ستساعدك الآلة الحاسبة Express 42 هنا (قيد التطوير). إذا تجاوزت السوق الروسية ، فابحث في ذلك آلة حاسبة DORA وإلى السوق العالمية.

بخير. وإذا كنت في مجموعة إليت على آلة حاسبة DORA ، فماذا يجب أن تفعل؟ لا يوجد حل جيد هنا. أنت على الأرجح في طليعة الصناعة ، ويمكن تحقيق المزيد من التسريع والموثوقية من خلال البحث والتطوير الداخلي وإنفاق المزيد من الموارد.

دعنا ننتقل إلى أحلى - المقارنة.

مقارنة

أردنا في البداية مقارنة الصناعة الروسية بالصناعة الغربية. إذا قارنا بشكل مباشر ، فسنلاحظ أن لدينا عددًا أقل من الملفات الشخصية ، وأنهم أكثر اختلاطًا ببعضهم البعض ، وتكون الحدود غير واضحة بدرجة أكبر:

يتم إخفاء نخبة الأداء لدينا بين أصحاب الأداء العالي ، لكنهم موجودون هناك - هؤلاء هم النخبة ، وحيدات القرن الذين وصلوا إلى ارتفاعات كبيرة. في روسيا ، لم يكن الاختلاف بين ملف تعريف النخبة والشخصية البارزة كبيرًا بما يكفي. نعتقد أن هذا الفصل سيحدث في المستقبل بسبب زيادة الثقافة الهندسية وجودة تنفيذ الممارسات الهندسية والخبرة داخل الشركات.

إذا انتقلنا إلى مقارنة مباشرة داخل الصناعة الروسية ، يمكننا أن نرى أن الفرق رفيعة المستوى أفضل من جميع النواحي. لقد أكدنا أيضًا فرضيتنا القائلة بوجود علاقة بين هذه المقاييس والأداء التنظيمي: من المرجح أن تحقق الفرق البارزة ليس فقط الأهداف ، ولكن أيضًا تجاوزها.
لنصبح فرقًا رفيعة المستوى ولن نتوقف عند هذا الحد:

لكن هذا العام خاص ، وقررنا التحقق من أداء الشركات في حالة حدوث جائحة: تعمل الفرق رفيعة المستوى بشكل أفضل بكثير وتشعر بأنها أفضل من متوسط ​​الصناعة:

• 1,5-2 مرات أكثر عرضة لإطلاق منتجات جديدة ،
• ضعف احتمال تحسين موثوقية و / أو أداء البنية التحتية للتطبيق.

أي أن الكفاءات التي ساعدتهم بالفعل على تطويرها بشكل أسرع ، وإطلاق منتجات جديدة ، وتعديل المنتجات الحالية ، وبالتالي غزو أسواق جديدة ومستخدمين جدد:

ما الذي ساعد فرقنا أيضًا؟

الممارسات الهندسية

سأخبرك عن النتائج المهمة لكل ممارسة اختبرناها. ربما ساعد شيء آخر الفرق ، لكننا نتحدث عن DevOps. وداخل DevOps ، نرى اختلافًا بين الفرق ذات الملفات الشخصية المختلفة.

المنصة كخدمة

لم نجد علاقة مهمة بين عمر النظام الأساسي والملف الشخصي للفريق: ظهرت المنصات في نفس الوقت تقريبًا لكل من الفرق المنخفضة والفرق العالية. ولكن بالنسبة لهذا الأخير ، يوفر النظام الأساسي ، في المتوسط ​​، المزيد من الخدمات والمزيد من واجهات البرمجة للتحكم من خلال رمز البرنامج. ومن المرجح أن تساعد فرق النظام الأساسي مطوريها وفرقها على استخدام النظام الأساسي ، وحل مشكلاتهم والحوادث المتعلقة بالمنصة في كثير من الأحيان ، وتثقيف الفرق الأخرى.

البنية التحتية كرمز

كل شيء قياسي هنا. وجدنا علاقة بين أتمتة عمل كود البنية التحتية وكمية المعلومات المخزنة داخل مستودع البنية التحتية. تخزن أوامر الملف الشخصي مزيدًا من المعلومات في المستودعات: هذا هو تكوين البنية التحتية وخط أنابيب CI / CD وإعدادات البيئة ومعلمات البناء. يقومون بتخزين هذه المعلومات في كثير من الأحيان ، ويعملون بشكل أفضل مع رمز البنية التحتية ، ويقومون بأتمتة المزيد من العمليات والمهام للعمل مع كود البنية التحتية.

ومن المثير للاهتمام أننا لم نلاحظ اختلافًا كبيرًا في اختبارات البنية التحتية. أعزو هذا إلى حقيقة أن الفرق عالية المستوى لديها المزيد من أتمتة الاختبار بشكل عام. ربما لا ينبغي تشتيت انتباههم بشكل منفصل عن طريق اختبارات البنية التحتية ، بل تلك الاختبارات التي يفحصون بها التطبيقات ، وبفضلهم يرون بالفعل ماذا وأين تعطّلوا.

التكامل والتسليم

القسم الأكثر مملًا ، لأننا أكدنا أنه كلما زادت الأتمتة لديك ، كلما عملت بشكل أفضل مع الكود ، زادت احتمالية حصولك على نتائج أفضل.

هندسة معمارية

أردنا أن نرى كيف تؤثر الخدمات المصغرة على الأداء. في الحقيقة ، لا يفعلون ذلك ، لأن استخدام الخدمات المصغرة لا يرتبط بزيادة في مؤشرات الأداء. يتم استخدام Microservices لكل من أوامر High Profile وأوامر Low Profile.

ولكن المهم هو أنه بالنسبة للفرق العليا ، فإن الانتقال إلى بنية الخدمات المصغرة يتيح لهم تطوير خدماتهم ونشرها بشكل مستقل. إذا كانت البنية تسمح للمطورين بالتصرف بشكل مستقل ، دون انتظار شخص خارج الفريق ، فهذه هي الكفاءة الرئيسية لزيادة السرعة. في هذه الحالة ، تساعد الخدمات المصغرة. وفقط تنفيذها لا يلعب دورًا كبيرًا.

كيف اكتشفنا كل هذا؟

كانت لدينا خطة طموحة لتكرار منهجية DORA بالكامل ، لكننا افتقرنا إلى الموارد. إذا استخدمت DORA الكثير من الرعاية واستغرقت أبحاثهم نصف عام ، فقد أجرينا بحثنا في وقت قصير. أردنا بناء نموذج DevOps مثل DORA ، وسنفعل ذلك في المستقبل. حتى الآن اقتصرنا على خرائط الحرارة:

نظرنا في توزيع الممارسات الهندسية عبر الفرق في كل ملف تعريف ووجدنا أن الفرق البارزة ، في المتوسط ​​، كانت أكثر عرضة لاستخدام الممارسات الهندسية. يمكنك قراءة المزيد عن كل هذا في موقعنا أبلغ عن.

من أجل التغيير ، دعنا ننتقل من الإحصائيات المعقدة إلى الإحصائيات البسيطة.

ماذا اكتشفنا أيضا؟

أدوات

نلاحظ أن معظم الأوامر يستخدمها نظام تشغيل عائلة Linux. لكن Windows لا يزال في الاتجاه - لاحظ ربع المستجيبين على الأقل استخدام واحد أو آخر من إصداراته. يبدو أن السوق لديه هذه الحاجة. لذلك ، يمكنك تطوير هذه الكفاءات وتقديم عروض تقديمية في المؤتمرات.

من بين الفنانين ، هذا ليس سرًا لأي شخص ، Kubernetes في المقدمة (52 ٪). المنسق التالي في الخط هو Docker Swarm (حوالي 12٪). أشهر أنظمة CI هي Jenkins و GitLab. أكثر أنظمة إدارة التهيئة شيوعًا هو Ansible ، تليها شركة Shell المحبوبة لدينا.

تعد أمازون حاليًا المزود الرائد لخدمات الاستضافة السحابية. حصة الغيوم الروسية تتزايد تدريجياً. سيكون من المثير للاهتمام في العام المقبل أن نرى كيف سيشعر مقدمو الخدمات السحابية الروس ، وما إذا كانت حصتهم في السوق ستزيد. يمكن استخدامها ، وهذا أمر جيد:

أعطي الكلمة إلى إيغور ، الذي سيقدم بعض الإحصائيات الأخرى.

نشر الممارسات

إيغور كوروشكين: بشكل منفصل ، طلبنا من المشاركين توضيح كيفية توزيع الممارسات الهندسية المدروسة في الشركة. في معظم الشركات ، هناك نهج مختلط ، يتكون من مجموعة مختلفة من الأنماط ، وتحظى المشاريع التجريبية بشعبية كبيرة. لقد رأينا أيضًا اختلافًا طفيفًا بين الملفات الشخصية. غالبًا ما يستخدم ممثلو الشخصيات البارزة نمط "المبادرة من الأسفل" ، عندما تقوم فرق صغيرة من المتخصصين بتغيير إجراءات العمل والأدوات ومشاركة الممارسات الناجحة مع الفرق الأخرى. في Medium ، هذه مبادرة من أعلى إلى أسفل تؤثر على الشركة بأكملها من خلال إنشاء مجتمعات ومراكز امتياز:

Agile و DevOps

غالبًا ما تتم مناقشة مسألة العلاقة بين Agile و DevOps في الصناعة. أثيرت هذه المشكلة أيضًا في تقرير حالة Agile لعام 2019/2020 ، لذلك قررنا مقارنة كيفية ارتباط أنشطة Agile و DevOps في الشركات. وجدنا أن DevOps بدون Agile أمر نادر الحدوث. بالنسبة لنصف المستجيبين ، بدأ انتشار Agile قبل ذلك بكثير ، ولاحظ حوالي 20٪ البداية المتزامنة ، وستكون إحدى علامات الانحدار المنخفض هي غياب ممارسات Agile و DevOps:

طبولوجيا القيادة

الكتاب في نهاية العام الماضي "طبولوجيا الفريق"، والذي يقترح إطار عمل لوصف طبولوجيا القيادة. أصبح من المثير للاهتمام بالنسبة لنا ما إذا كان ينطبق على الشركات الروسية. وسألنا السؤال: "ما هي الأنماط التي تجدها؟".

تمت ملاحظة فرق البنية التحتية في نصف المجيبين ، بالإضافة إلى فرق منفصلة للتطوير والاختبار والتشغيل. لاحظت فرق DevOps المنفصلة أن 45٪ من بينهم ممثلو High أكثر شيوعًا. بعد ذلك تأتي الفرق متعددة الوظائف ، والتي تكون أيضًا أكثر شيوعًا في High. تظهر أوامر SRE المنفصلة في ملفات التعريف عالية ومتوسطة ونادرًا ما تظهر في ملف التعريف المنخفض:

نسبة DevQaOps

لقد رأينا هذا السؤال على FaceBook من قائد فريق فريق منصة Skyeng - كان مهتمًا بنسبة المطورين والمختبرين والمسؤولين في الشركات. لقد طلبنا ذلك ونظرنا في الردود بناءً على الملفات الشخصية: الممثلون البارزون لديهم عدد أقل من مهندسي الاختبار والعمليات لكل مطور:

خطط لعام 2021

في خطط العام المقبل ، لاحظ المستجيبون الأنشطة التالية:

هنا يمكنك رؤية التقاطع مع مؤتمر DevOps Live 2020. لقد راجعنا البرنامج بعناية:

• البنية التحتية كمنتج
• تحويل DevOps
• توزيع ممارسات DevOps
• DevSecOps
• نوادي القضية والمناقشات

لكن وقت عرضنا التقديمي لا يكفي لتغطية جميع المواضيع. خلف الكواليس:

• المنصة كخدمة وكمنتج ؛
• البنية التحتية ككود وبيئات وسحب ؛
• التكامل والتسليم المستمر.
• بنيان؛
• أنماط DevSecOps ؛
• منصة وفرق متعددة الوظائف.

تقرير لدينا 50 صفحة ضخمة ، ويمكنك رؤيتها بمزيد من التفصيل.

تلخيص

نأمل أن يلهمك بحثنا وتقريرنا لتجربة مناهج جديدة للتطوير والاختبار والعمليات ، بالإضافة إلى مساعدتك على التنقل ومقارنة نفسك بالمشاركين الآخرين في الدراسة وتحديد المجالات التي يمكنك من خلالها تحسين مناهجك الخاصة.

نتائج الدراسة الأولى لحالة DevOps في روسيا:

• مقاييس رئيسية. لقد وجدنا أن المقاييس الرئيسية (وقت التسليم ، وتكرار النشر ، ووقت الاسترداد ، وفشل التغيير) مناسبة لتحليل فعالية عمليات التطوير والاختبار والعمليات.
• الملامح عالية ومتوسطة ومنخفضة. بناءً على البيانات التي تم جمعها ، يمكننا التمييز بين مجموعات مختلفة إحصائيًا من عالية ومتوسطة ومنخفضة بسمات مميزة من حيث المقاييس والممارسات والعمليات والأدوات. ممثلو الملف الشخصي يظهرون نتائج أفضل من Low. هم أكثر عرضة لتحقيق أهدافهم وتجاوزها.
• مؤشرات وجائحة وخطط عام 2021. من المؤشرات الخاصة هذا العام كيف تعاملت الشركات مع الوباء. كان أداء الممثلين الساميين أفضل ، وشهدوا زيادة في مشاركة المستخدمين ، وكانت الأسباب الرئيسية للنجاح هي عمليات التطوير الفعالة والثقافة الهندسية القوية.
• ممارسات وأدوات DevOps وتطويرها. تشمل الخطط الرئيسية للشركات للعام المقبل تطوير ممارسات وأدوات DevOps ، وإدخال ممارسات DevSecOps ، والتغييرات في الهيكل التنظيمي. ويتم تنفيذ وتطوير ممارسات DevOps بشكل فعال بمساعدة المشاريع التجريبية ، وتشكيل المجتمعات ومراكز التميز ، والمبادرات على المستويين العلوي والسفلي للشركة.

يسعدنا سماع ملاحظاتك وقصصك وتعليقاتك. نشكر كل من شارك في الدراسة ونتطلع إلى مشاركتك العام المقبل.

المصدر: www.habr.com