يمكنك الاعتماد على رأيك ، المكون من مصادر مختلفة للمعلومات ، على سبيل المثال ، المنشورات على المواقع أو الخبرة. يمكنك سؤال الزملاء والمعارف. خيار آخر هو النظر في مواضيع المؤتمر: لجنة البرنامج هي ممثلين نشطين للصناعة ، لذلك نحن نثق بهم في اختيار الموضوعات ذات الصلة. مجال منفصل هو البحث والتقارير. لكن هناك مشكلة. يتم إجراء الأبحاث حول حالة DevOps سنويًا في العالم ، ويتم نشر التقارير من قبل الشركات الأجنبية ولا توجد معلومات تقريبًا حول DevOps الروسية.
ولكن جاء اليوم الذي أجريت فيه هذه الدراسة ، وسنخبرك اليوم بالنتائج التي تم الحصول عليها. تم التحقيق في حالة DevOps في روسيا بالاشتراك مع Express 42 و Ontiko". تساعد Express 42 شركات التكنولوجيا في تنفيذ وتطوير ممارسات وأدوات DevOps وكانت من أوائل من تحدثوا عن DevOps في روسيا. يعمل مؤلفو الدراسة ، إيغور كوروشكين وفيتالي خاباروف ، في التحليل والاستشارات في Express 42 ، ولديهم خلفية تقنية من التشغيل والخبرة العملية في شركات مختلفة. لمدة 8 سنوات ، نظر الزملاء في عشرات الشركات والمشاريع - من الشركات الناشئة إلى المؤسسات - التي تعاني من مشاكل مختلفة ، فضلاً عن النضج الثقافي والهندسي المختلف.
أخبر إيغور وفيتالي في تقريرهما ما هي المشاكل التي كانت في عملية البحث ، وكيف تم حلها ، بالإضافة إلى كيفية إجراء بحث DevOps من حيث المبدأ ولماذا قرر Express 42 إجراء بحث خاص به. يمكن الاطلاع على تقريرهم هنا .
بحوث DevOps
بدأ إيغور كوروشكين المحادثة.
نطرح على الجمهور بانتظام سؤالاً في مؤتمرات DevOps: "هل قرأت تقرير حالة DevOps لهذا العام؟" قلة فقط رفعوا أيديهم ، وأظهرت دراستنا أن ثلثهم فقط يدرسهم. إذا لم تكن قد شاهدت مثل هذه التقارير من قبل ، فلنفترض على الفور أنها متشابهة جدًا. غالبًا ما توجد عبارات مثل: "مقارنة بالعام الماضي ..."
هنا لدينا المشكلة الأولى ، وبعدها توجد مشكلتان أخريان:
- ليس لدينا بيانات عن العام الماضي. لا تهم حالة DevOps في روسيا أحدًا ؛
- المنهجية. ليس من الواضح كيفية اختبار الفرضيات ، وكيفية تكوين الأسئلة ، وكيفية إجراء التحليل ، ومقارنة النتائج ، والعثور على الروابط ؛
- المصطلح. جميع التقارير باللغة الإنجليزية ، والترجمة مطلوبة ، ولم يتم حتى الآن اختراع إطار عمل 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 بالاشتراك مع 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 حوالي ألف شخص في تقاريرها سنويًا) وهنا حققنا الهدف:
صحيح ، لم يصل جميع المشاركين إلى النهاية: النسبة المئوية تبين أن الحشو أقل بقليل من النصف. ولكن حتى هذا كان كافياً للحصول على عينة تمثيلية وإجراء تحليل. درة لا تفصح عن نسبة ملء تقاريرها فلا يمكن مقارنتها هنا.
الصناعات والمناصب
يمثل المجيبون لدينا عشرات الصناعات. نصفهم يعملون في مجال تكنولوجيا المعلومات. ويلي ذلك الخدمات المالية والتجارة والاتصالات وغيرها. من بين الوظائف المتخصصون (مطور ، فاحص ، مهندس عمليات) وموظفو الإدارة (قادة الفرق ، الفرق ، التوجيهات ، المديرون):
تعمل كل ثانية في شركة متوسطة الحجم. يعمل كل شخص ثالث في الشركات الكبيرة. يعمل معظمهم في فرق تصل إلى 9 أشخاص. بشكل منفصل ، سألنا عن الأنشطة الرئيسية ، ومعظمها يتعلق بطريقة أو بأخرى بالتشغيل ، وحوالي 40٪ منهمكون في التنمية:
هذه هي الطريقة التي جمعنا بها المعلومات لمقارنة وتحليل ممثلي مختلف الصناعات والشركات والفرق. سيخبرك زميلي فيتالي خاباروف عن التحليل.
التحليل والمقارنة
فيتالي خابروف: شكراً جزيلاً لجميع المشاركين الذين أكملوا الاستبيان ، وملأوا الاستبيانات وقدموا لنا بيانات لمزيد من التحليل والاختبار لفرضياتنا. وبفضل عملائنا وعملائنا ، لدينا ثروة من الخبرة التي ساعدت في تحديد القضايا التي تهم الصناعة وصياغة الفرضيات التي اختبرناها في بحثنا.
لسوء الحظ ، لا يمكنك فقط أخذ قائمة بالأسئلة من جهة والبيانات من جهة أخرى ، ومقارنتها بطريقة أو بأخرى ، وقل: "نعم ، كل شيء يسير على هذا النحو ، لقد كنا على حق" ونتفرق. لا ، نحن بحاجة إلى منهجية وطرق إحصائية للتأكد من أننا لسنا مخطئين وأن استنتاجاتنا موثوقة. ثم يمكننا بناء عملنا الإضافي على أساس هذه البيانات:
مقاييس رئيسية
اتخذنا منهجية DORA كأساس ، والتي وصفوها بالتفصيل في كتاب "Accelerate State of DevOps". لقد تحققنا مما إذا كانت المقاييس الرئيسية مناسبة للسوق الروسي ، فهل يمكن استخدامها بنفس الطريقة التي تستخدمها DORA للإجابة على السؤال: "كيف تتوافق الصناعة في روسيا مع الصناعة الأجنبية؟"
مقاييس رئيسية:
- تردد النشر. كم مرة يتم نشر إصدار جديد من التطبيق في بيئة الإنتاج (التغييرات المخطط لها ، باستثناء الإصلاحات السريعة والاستجابة للحوادث)؟
- موعد التسليم. ما هو متوسط الوقت بين إجراء تغيير (كتابة وظيفة كرمز) ونشر التغيير في بيئة المنتج؟
- . , , ?
- . ( , )?
وجدت DORA علاقة بين هذه المقاييس والأداء التنظيمي في بحثها. نتحقق منه أيضًا في بحثنا.
ولكن للتأكد من أن المقاييس الأساسية الأربعة يمكن أن تؤثر على شيء ما ، عليك أن تفهم - هل ترتبط ببعضها البعض بطريقة ما؟ ردت DORA بالإيجاب مع تحذير واحد: العلاقة بين معدل فشل التغيير والمقاييس الثلاثة الأخرى أضعف قليلاً. حصلنا على نفس الصورة تقريبا. إذا كان وقت التسليم وتكرار النشر ووقت الاسترداد مرتبطين ببعضهما البعض (وجدنا هذا الارتباط من خلال ارتباط بيرسون ومن خلال مقياس تشادوك) ، فلا يوجد ارتباط قوي مع التغييرات غير الناجحة.
من حيث المبدأ ، يميل معظم المستجيبين للإجابة بأن لديهم عددًا صغيرًا نسبيًا من الحوادث التي تحدث في الإنتاج. على الرغم من أننا سنرى في المستقبل أنه لا يزال هناك فرق كبير بين مجموعات المستجيبين من حيث معدل التغييرات غير الناجحة ، بالنسبة لهذا التقسيم ، لا يمكننا استخدام هذا المقياس حتى الآن.
نربط هذا بحقيقة (كما اتضح أثناء التحليل والتواصل مع بعض عملائنا) أن هناك اختلافًا طفيفًا في تصور ما يعتبر حادثًا. إذا تمكنا من استعادة قابلية تشغيل خدمتنا أثناء النافذة الفنية ، فهل يمكن اعتبار ذلك حادثًا؟ ربما لا ، لأننا أصلحنا كل شيء ، نحن رائعون. هل يمكن اعتباره حادثة إذا اضطررنا إلى إعادة طرح تطبيقنا 10 مرات في الوضع العادي المعتاد بالنسبة لنا؟ لا يبدو ذلك. لذلك ، تظل مسألة علاقة التغييرات غير الناجحة بالمقاييس الأخرى مفتوحة. سنقوم بتنقيحها أكثر.
من المهم هنا أننا وجدنا ارتباطًا مهمًا بين أوقات التسليم وأوقات الاسترداد وتكرار النشر. لذلك ، أخذنا هذه المقاييس الثلاثة لتقسيم المستجيبين إلى مجموعات أداء.
كم تزن بالجرام؟
استخدمنا تحليل الكتلة الهرمي:
- نقوم بتوزيع المستجيبين في الفضاء ذي البعد n ، حيث يكون تنسيق كل مستجيب هو إجاباتهم على الأسئلة.
- نعلن أن كل مشارك يمثل كتلة صغيرة.
- نقوم بدمج المجموعتين الأقرب لبعضهما البعض في مجموعة أكبر.
- ابحث عن الزوج التالي من المجموعات واجمعهما في مجموعة أكبر.
هذه هي الطريقة التي نجمع بها جميع المجيبين لدينا في العدد المطلوب من المجموعات. بمساعدة مخطط dendrogram (شجرة من الوصلات بين المجموعات) نرى المسافة بين مجموعتين متجاورتين. كل ما تبقى لنا هو أن نضع حدًا معينًا للمسافة بين هذه المجموعات ونقول: "هاتان المجموعتان مختلفتان تمامًا عن بعضهما البعض لأن المسافة بينهما كبيرة".
ولكن هناك مشكلة خفية هنا: ليس لدينا قيود على عدد المجموعات - يمكننا الحصول على 2 ، 3 ، 4 ، 10 مجموعات. وكانت الفكرة الأولى - لماذا لا نقسم جميع المشاركين في الاستطلاع إلى 4 مجموعات ، كما تفعل DORA. لكننا اكتشفنا أن الاختلافات بين هذه المجموعات أصبحت غير ذات أهمية ، ولا يمكننا التأكد من أن المستفتى ينتمي حقًا إلى مجموعته الخاصة وليس إلى المجموعة المجاورة. ما زلنا لا نستطيع تقسيم السوق الروسية إلى أربع مجموعات. لذلك ، توقفنا عند ثلاثة ملفات تعريف بالضبط ، يوجد بينها فرق مهم إحصائيًا:
بعد ذلك ، حددنا الملف الشخصي حسب المجموعات: أخذنا متوسطات كل مقياس لكل مجموعة وقمنا بعمل جدول لملفات تعريف الأداء. في الواقع ، حصلنا على ملفات تعريف أداء المشارك العادي في كل مجموعة. لقد حددنا ثلاثة ملفات تعريف للكفاءة: منخفضة ، متوسطة ، عالية:
لقد أكدنا هنا فرضيتنا القائلة بأن المقاييس الأربعة الرئيسية مناسبة لتحديد ملف تعريف الأداء ، وهي تعمل في كل من الأسواق الغربية والروسية. يوجد فرق بين المجموعات وهو ذو دلالة إحصائية. أود أن أؤكد أن هناك فرقًا كبيرًا في المتوسط بين ملفات تعريف الأداء وفقًا لمقياس التغييرات غير الناجحة ، على الرغم من أننا في البداية لم نقسم المستجيبين وفقًا لهذه المعلمة.
ثم السؤال الذي يطرح نفسه: كيف تستخدم كل هذا؟
كيف تستعمل
إذا أخذت أي فريق ، و 4 مقاييس رئيسية وقمت بتطبيقه على الجدول ، فلن نحصل على تطابق كامل في 85٪ من الحالات - هذا مجرد مشارك عادي ، وليس ما هو موجود في الواقع. نحن جميعًا (وكل فريق) مختلفون بعض الشيء.
فحصنا: أخذنا المشاركين وملف أداء DORA ، ونظرنا إلى عدد المستجيبين المناسبين لملف تعريف معين. وجدنا أن 16٪ فقط من المستجيبين قاموا بضرب أحد الملفات الشخصية بدقة. كل الآخرين منتشرون في مكان ما بينهما:
هذا يعني أن ملف تعريف الأداء له نطاق محدود. لفهم موقعك في أول تقدير تقريبي ، يمكنك استخدام هذا الجدول: "يبدو أننا أقرب إلى متوسط أو مرتفع!" إذا فهمت إلى أين تذهب بعد ذلك ، فقد يكون هذا كافياً. ولكن إذا كان هدفك هو التحسين المستمر والمستمر ، وتريد أن تعرف بدقة أكبر مكان التطوير وماذا تفعل ، فأنت بحاجة إلى أموال إضافية. أطلقنا عليهم اسم الآلات الحاسبة:
- آلة حاسبة DORA
- Calculator Express 42 * (قيد التطوير)
- التطوير الخاص (يمكنك إنشاء الآلة الحاسبة الداخلية الخاصة بك).
لماذا هم بحاجة؟ لفهم:
- هل الفريق داخل منظمتنا يفي بمعاييرنا؟
- إذا لم يكن كذلك ، فهل يمكننا مساعدتها - الإسراع بها في إطار الخبرة التي تمتلكها شركتنا؟
- إذا كان الأمر كذلك ، فهل يمكننا أن نفعل ذلك بشكل أفضل؟
يمكنك أيضًا استخدامها لجمع الإحصائيات داخل الشركة:
- ما هي الفرق لدينا؟
- تقسيم الفرق إلى ملفات شخصية ؛
- انظر: أوه ، أداء هذه الفرق ضعيف (لا يسحبون قليلاً) ، وهذه رائعة: فهي تنشر كل يوم ، دون أخطاء ، ولديها مهلة أقل من ساعة.
وبعد ذلك يمكنك معرفة أنه يوجد داخل شركتنا الخبرة والأدوات اللازمة لتلك الفرق التي لا تزال غير صامدة.
أو ، إذا فهمت أنك داخل الشركة تشعر بالرضا ، وأنك أفضل من كثيرين ، فيمكنك إلقاء نظرة أوسع. هذه هي بالضبط الصناعة الروسية: هل يمكننا الحصول على الخبرة اللازمة في الصناعة الروسية لتسريع أنفسنا؟ سيساعدك Calculator Express 42 هنا (قيد التطوير). إذا تجاوزت السوق الروسية ، فقم بإلقاء نظرة على حاسبة DORA والسوق العالمية.
حسنا. وإذا كنت في مجموعة Elit الحاسبة DORA ، فماذا تفعل؟ لا يوجد حل جيد هنا. على الأرجح أنك في طليعة الصناعة ، ومن الممكن تحقيق المزيد من التسريع وتحسين الموثوقية بسبب البحث والتطوير الداخلي وإنفاق المزيد من الموارد.
دعنا ننتقل إلى أحلى - المقارنة.
مقارنة
أردنا في الأصل مقارنة الصناعة الروسية بالصناعة الغربية. إذا قارنا بشكل مباشر ، فإننا نرى أن لدينا عددًا أقل من الملفات الشخصية ، وأنهم مختلطون أكثر قليلاً مع بعضهم البعض ، والحدود أكثر وضوحًا:
يتم إخفاء نخبة الأداء لدينا بين كبار الأداء ، لكنهم موجودون - إنهم النخبة ، وحيدات القرن الذين وصلوا إلى ارتفاعات كبيرة. في روسيا ، لم يكن الاختلاف بين ملف تعريف النخبة والشخصية البارزة كبيرًا بما يكفي. نعتقد أن هذا الفصل سيحدث في المستقبل فيما يتعلق بتحسين الثقافة الهندسية وجودة تنفيذ الممارسات الهندسية والخبرة داخل الشركات.
بالانتقال إلى المقارنة المباشرة داخل الصناعة الروسية ، نرى أن الفرق رفيعة المستوى أفضل من جميع النواحي. لقد أكدنا أيضًا فرضيتنا القائلة بوجود صلة بين هذه المقاييس والأداء التنظيمي: من المرجح أن تحقق الفرق ذات المستوى الرفيع ليس فقط الأهداف ، بل تتجاوزها أيضًا.
لنصبح فرقًا رفيعة المستوى ولا نتوقف عند هذا الحد:
ولكن هذا العام خاص ، وقررنا التحقق من كيفية عيش الشركات في وباء: تعمل الفرق رفيعة المستوى بشكل أفضل وتشعر بتحسن من متوسط الصناعة:
- تم إصدار منتجات جديدة أكثر من 1.5 إلى 2 مرات
- ضعف احتمال تحسين موثوقية و / أو أداء البنية التحتية للتطبيق.
أي أن الكفاءات التي كانوا قد ساعدتهم بالفعل على تطويرها بشكل أسرع ، وتقديم منتجات جديدة ، وتعديل المنتجات الحالية ، وبالتالي غزو أسواق جديدة ومستخدمين جدد:
ما الذي ساعد فرقنا أيضًا؟
الممارسات الهندسية
سأخبرك عن النتائج المهمة من كل ممارسة فحصناها. ربما ساعد شيء آخر الفرق ، لكننا نتحدث عن DevOps. وداخل DevOps ، نرى اختلافًا بين الفرق عبر الملفات الشخصية المختلفة.
المنصة كخدمة
لم نعثر على صلة مهمة بين عمر النظام الأساسي والملف الشخصي للفريق: ظهرت المنصات في نفس الوقت تقريبًا لكل من الفرق المنخفضة والفرق العالية. ولكن بالنسبة لهذا الأخير ، يوفر النظام الأساسي ، في المتوسط ، المزيد من الخدمات والمزيد من واجهات البرمجة للتحكم من خلال رمز البرنامج. ومن المرجح أن تساعد فرق النظام الأساسي مطوريها وفرقها على استخدام النظام الأساسي ، وفي كثير من الأحيان لحل المشكلات والحوادث المتعلقة بالمنصة ، وتثقيف الفرق الأخرى.
البنية التحتية كرمز
كل شيء قياسي هنا. لقد وجدنا علاقة بين أتمتة كيفية عمل كود البنية التحتية وكمية المعلومات المخزنة داخل مستودع البنية التحتية. تخزن أوامر الملف الشخصي مزيدًا من المعلومات في المستودعات: هذا هو تكوين البنية التحتية وخط أنابيب CI / CD وإعدادات البيئة ومعلمات البناء. يقومون بتخزين هذه المعلومات في كثير من الأحيان ، ويعملون بشكل أفضل مع رمز البنية التحتية ، ولديهم المزيد من العمليات والمهام تلقائيًا للعمل مع كود البنية التحتية.
ومن المثير للاهتمام ، أننا لم نلاحظ فرقًا كبيرًا في اختبارات البنية التحتية. أقوم بربط هذا بحقيقة أن أوامر High Profile تتمتع عمومًا بمزيد من أتمتة الاختبار. ربما لا ينبغي تشتيت انتباههم بشكل منفصل عن طريق اختبارات البنية التحتية ، لكن الاختبارات التي يستخدمونها للتحقق من التطبيقات كافية ، وبفضلهم يمكنهم بالفعل رؤية ماذا وأين تعطلوا.
التكامل والتسليم
القسم الأكثر مملًا لأننا أكدنا أنه كلما زادت الأتمتة لديك ، كلما عملت بشكل أفضل مع الشفرة ، زادت احتمالية حصولك على أفضل المقاييس.
هندسة معمارية
أردنا أن نرى كيف تؤثر الخدمات المصغرة على الأداء. إذا كانت في الحقيقة ، فهي لا تفعل ذلك ، لأن استخدام الخدمات المصغرة لا يرتبط بزيادة في مؤشرات الأداء. يتم استخدام Microservices بواسطة أوامر High Profile وأوامر Low Profile.
ولكن المهم هو أنه بالنسبة للفرق العالية ، فإن الانتقال إلى بنية الخدمات المصغرة يتيح لهم تطوير خدماتهم بشكل مستقل ونشرها. إذا كانت البنية تسمح للمطورين بالتصرف بشكل مستقل ، وليس انتظار شخص خارج الفريق ، فهذه هي الكفاءة الرئيسية لزيادة السرعة. هذا هو المكان الذي تساعد فيه الخدمات المصغرة. وفقط تنفيذها لا يلعب دورًا كبيرًا.
كيف وجدنا كل هذا؟
كانت لدينا خطة طموحة لتكرار منهجية DORA بالكامل ، لكننا افتقرنا إلى الموارد. إذا استخدمت DORA الكثير من الرعاية واستغرق البحث نصف عام ، فقد أجرينا بحثنا في وقت قصير. أردنا بناء نموذج DevOps مثل DORA ، وسنفعل ذلك في المستقبل. حتى الآن ، اقتصرنا على الخرائط الحرارية:
نظرنا في توزيع الممارسات الهندسية بين فرق كل ملف تعريف ، ووجدنا أن الفرق في المستوى الرفيع ، في المتوسط ، تستخدم الممارسات الهندسية في كثير من الأحيان. يمكنك قراءة المزيد عن هذا الموضوع في التقرير .
من أجل التغيير ، دعنا ننتقل من الإحصائيات المعقدة إلى الإحصائيات البسيطة.
ماذا وجدنا أيضا؟
أدوات
نلاحظ أن معظم الفرق تستخدم نظام التشغيل Linux. لكن Windows لا يزال في الاتجاه - لاحظ ربع المستجيبين على الأقل استخدام إصدار أو آخر منه. يبدو أن السوق لديه هذه الحاجة. لذلك ، يمكنك تطوير هذه الكفاءات وتقديم عروض تقديمية في المؤتمرات.
Kubernetes هو الرائد بين المنسقين (52 ٪). المنسق التالي في الخط هو Docker Swarm (حوالي 12٪). أشهر أنظمة CI هي Jenkins و GitLab. نظام إدارة التهيئة الأكثر شيوعًا هو Ansible ، تليها شركة Shell المحبوبة لدينا.
بين الاستضافة السحابية ، لا تزال Amazon في الصدارة. تتزايد حصة السحب الروسية تدريجياً. في العام المقبل ، سيكون من المثير للاهتمام أن نرى كيف يشعر مقدمو الخدمات السحابية الروس وما إذا كانت حصتهم في السوق تنمو. إنها كذلك ، يمكنك استخدامها ، وهذا أمر جيد:
أعطي الكلمة لإيجور ، الذي سيقدم بعض الإحصائيات الإضافية.
نشر الممارسات
إيغور كوروشكين: بشكل منفصل ، طلبنا من المستجيبين الإشارة إلى كيفية نشر الممارسات الهندسية المدروسة في الشركة. تتبع معظم الشركات نهجًا مختلطًا مع مجموعة مختلفة من الأنماط ، وتحظى المشاريع التجريبية بشعبية كبيرة. رأينا أيضًا اختلافًا طفيفًا بين الملفات الشخصية. غالبًا ما يستخدم ممثلو الشخصيات البارزة نمط "المبادرة من الأسفل" ، عندما تقوم فرق صغيرة من المتخصصين بتغيير إجراءات العمل والأدوات ومشاركة التطورات الناجحة مع الفرق الأخرى. في Medium ، هذه مبادرة من الأعلى ، تؤثر على الشركة بأكملها من خلال إنشاء مجتمعات ومراكز امتياز:
Agile و DevOps
تعتبر العلاقة بين Agile و DevOps موضوعًا ساخنًا في الصناعة. أثيرت هذه المشكلة أيضًا في تقرير حالة Agile لعام 2019/2020 ، لذلك قررنا مقارنة كيفية ارتباط أنشطة Agile و DevOps في الشركات. لقد وجدنا أن غير Agile DevOps أمر نادر الحدوث. بالنسبة لنصف المستجيبين ، بدأ انتشار Agile في وقت مبكر جدًا ، ولاحظ حوالي 20٪ بداية متزامنة ، وستكون إحدى علامات الانحدار المنخفض هي عدم وجود ممارسات Agile و DevOps:
طبولوجيا القيادة
في نهاية العام الماضي ، تم نشر كتاب " طوبولوجيا الفريق " ، والذي اقترح إطارًا لوصف طبولوجيا الفريق. تساءلنا عما إذا كان ينطبق على الشركات الروسية. وسألنا السؤال: "ما هي الأنماط التي تجدها؟"
تتم مراقبة فرق البنية التحتية من قبل نصف المجيبين ، بالإضافة إلى فرق التطوير والاختبار والتشغيل المنفصلة. لوحظت فرق DevOps الفردية بنسبة 45٪ ، ومن بينها الممثلون الساميون أكثر شيوعًا. يتبع ذلك فرق متعددة الوظائف ، وهي أيضًا أكثر شيوعًا بالنسبة إلى المستوى العالي. تظهر أوامر SRE المنفصلة في ملفات التعريف العالية والمتوسطة ونادراً ما تظهر في ملف التعريف المنخفض:
نسبة DevQaOps
لقد رأينا هذا السؤال في FaceBook من قائد فريق منصة Skyeng - لقد كان مهتمًا بنسبة المطورين والمختبرين والمسؤولين في الشركات. لقد طلبنا ذلك ونظرنا في الردود بناءً على الملفات الشخصية: ممثلو High Profile لديهم عدد أقل من مهندسي الاختبار والعمليات لكل مطور:
خطط عام 2021
في خططهم للعام المقبل ، لاحظ المشاركون الأنشطة التالية:
هنا يمكنك رؤية التقاطع مع مؤتمر DevOps Live 2020. لقد راجعنا البرنامج بعناية:
- البنية التحتية كمنتج
- تحويل DevOps
- نشر ممارسات DevOps
- DevSecOps
- نوادي القضية والمناقشات
لكن خطابنا لن يكون وقتًا كافيًا للنظر في جميع الموضوعات. خلف الكواليس:
- المنصة كخدمة وكمنتج ؛
- البنية التحتية ككود وبيئات وسحاب ؛
- التكامل والتسليم المستمر ؛
- هندسة معمارية؛
- أنماط DevSecOps ؛
- منصة وفرق متعددة الوظائف.
تبين أن تقريرنا ضخم ، في 50 صفحة ، ويمكنك رؤيته بمزيد من التفصيل.
تلخيص لما سبق
نأمل أن يلهمك بحثنا وتقريرنا لتجربة مناهج جديدة للتطوير والاختبار والعمليات ، بالإضافة إلى مساعدتك على التنقل ومقارنة نفسك مع المشاركين الآخرين في البحث وتحديد المجالات التي يمكنك من خلالها تحسين مناهجك الخاصة.
نتائج المسح الأول لحالة DevOps في روسيا:
- مقاييس رئيسية. لقد وجدنا أن المقاييس الرئيسية (المهلة الزمنية ، وتكرار النشر ، ووقت الاسترداد ، والتغييرات غير الناجحة) مناسبة لتحليل فعالية التطوير والاختبار والعمليات.
- High, Medium, Low. High, Medium, Low , , . High , Low. .
- , 2021 . , . High , , .
- ممارسات وأدوات DevOps وتطورها. تشمل الخطط الرئيسية للشركات للعام المقبل تطوير ممارسات وأدوات DevOps ، وإدخال ممارسات DevSecOps ، وتغيير الهيكل التنظيمي. ويتم تنفيذ وتطوير ممارسات DevOps بشكل فعال بمساعدة المشاريع التجريبية ، وتشكيل المجتمعات ومراكز الكفاءة ، والمبادرات على المستويات العليا والدنيا للشركة.
سنكون سعداء لسماع ملاحظاتك وقصصك وتعليقاتك. شكرا لكل من شارك في الدراسة ونتطلع لمشاركتك العام المقبل.