نظرة عامة على مؤتمر DevOpsDays موسكو: رؤى من 6 تقارير

وعقد المؤتمر الثالث في 7 ديسمبر DevOpsDays موسكو، نظمه مجتمع DevOps في موسكو بدعم من Mail.ru Cloud Solutions. بالإضافة إلى العروض التقديمية التي يقدمها كبار ممارسي DevOps، يمكن للمشاركين حضور محادثات Lightning Talks وورش العمل القصيرة المحفزة والتواصل في أماكن مفتوحة.

لقد جمعنا رؤى مهمة من ستة خطابات وأجرينا مقابلات مع العديد من المتحدثين لمعرفة ما تبقى وراء التقارير.

داخل:

1. باروخ سادوغورسكي، JFrog: "دع البرنامج يتدفق من البائع إلى المستخدم مثل السائل"
2. بافيل سيليفانوف، Southbridge: "لدى Dev وOps مهمة واحدة مشتركة - وهي صنع منتج ناجح"
3. فلاديمير أوتراتينكو، X5 Retail Group: "DevOps in Enterprise هو تطوير بدون ألم أو حرائق"
4. سيرجي بوزيريف، فيسبوك: "يهتم مهندس الإنتاج بالخدمة ككل: بحيث يقضي كل من المستخدمين والمطورين وقتًا ممتعًا"
5. ميخائيل شينكوف، AMBOSS: "لا يمكن لقسم واحد اتباع مسار DevOps، يجب على الشركة بأكملها اتباعه"
6. عشاق DevOps في Rosbank: "1000 يوم لتنفيذ DevOps في مؤسسة دموية"

1. باروخ سادوغورسكي، JFrog: "دع البرنامج يتدفق من البائع إلى المستخدم مثل السائل"

تحدث حالات فشل تحديث البرامج كل ساعة ولكل شخص. إليكم قصة رعب واحدة فقط من الخطاب: خسرت شركة Knight Capital 440 مليون دولار في ساعة واحدة بعد التحديث غير الناجح.

تحدث باروخ عن أنماط DevOps للتحديثات المستمرة التي ستساعد في تجنب حالات الفشل وكراهية المستخدم:

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

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

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

النشر الآلي - استبدال الناس بالآلات، لأن الناس سيئون في أداء الأعمال الروتينية.

астые обновления - تساعدك على تطوير العادة والتخلص من الخوف. التحديثات النادرة تتحول إلى أحداث طارئة.

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

اصدارات الكناري - طرح التحديثات لعدد صغير من المستخدمين ومراقبتها. وهذا يقلل من الضرر إذا حدث خطأ ما.

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

تحدثنا مع Baruch Sadogursky حول كيفية اختلاف وجهة النظر حول DevOps في تكنولوجيا المعلومات الروسية والغربية، وما إذا كانت Cloud ستفعل كل شيء قريبًا وما إذا كانت جميع خدمات البرامج ستنزلق إلى مخطط aaS - شاهد المقابلة:

2. بافيل سيليفانوف، Southbridge: "لدى Dev وOps مهمة واحدة مشتركة - وهي صنع منتج ناجح"

لن يساعد تطبيق Kubernetes في تحقيق DevOps، بل على العكس من ذلك، يمكن أن يكسر كل شيء. أوضح بافيل لماذا لا تستطيع التكنولوجيا (حتى أروعها) حل جميع مشاكلك:

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

لا يريد المطورون إجراء تغييرات بعد تنفيذ DevOps. ونتيجة لذلك، لا يزال تدفق العمل مع Kubernetes يبدو وكأنه إلقاء المهام من Dev إلى Ops فوق الحائط، ولكن ليس بشكل مجازي - يصبح Git مثل هذا الجدار. يضع المطور الكود هناك ويعمل كما كان من قبل، والمسؤولون لديهم Kubernetes وCI/CD وكل شيء آخر.

ومع ذلك، يحتاج المطورون إلى قبول التغييرات. إن الموقف الذي لا يعرف فيه المطورون ما يفعله المسؤولون، ولا يعرف المسؤولون ما يحدث مع المطورين، يخلق مشاكل.

إذا لم يتغير شيء بالنسبة للمطورين، فإنهم لا يدركون أن تشغيل التطبيق هو مسؤوليتهم - لن تعمل الحيل التقنية المختلفة.

مع ظهور DevOps وKubernetes، سيتغير الكثير في مجال التطوير. يجب أن يكون المطورون مختصين في العمليات والعكس صحيح. يتمتع هؤلاء المتخصصون بمهاراتهم الخاصة، ولكن يجب أن يكونوا على دراية بعمل بعضهم البعض. يجب أن يكون Dev وOps أصدقاء قبل تنفيذ Kubernetes، وإلا فسوف تكسر ما لديك.

تحدث بافيل سيليفانوف عما سيحدث لـ Kubernetes خلال 5 سنوات وما الذي يجب على الشركة الناشئة الحديثة أن تبني عليه مجموعة تكنولوجية - شاهد المقابلة:

3. فلاديمير أوتراتينكو، X5 Retail Group: "DevOps in Enterprise هو تطوير بدون ألم أو حرائق"

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

وأوضح فلاديمير كيف يحدث هذا وما هي المشكلة:

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

ما يجب القيام به؟ قم بتعيين فريق DevOps مؤقت سيساعد في تنفيذ تحول DevOps وتنفيذ الممارسات وتنمية ثقافة التطوير والثقافة التكنولوجية.

عندما تدخل شركة ما حيز التنفيذ وتستثمر في DevOps، تكون هناك عدة سيناريوهات ممكنة: كل شيء سوف ينهار عند الإقلاع؛ ستظل SRE/هندسة الإنتاج أو العمليات المدمجة؛ سيتم الانتقال إلى BizOps، عندما تعتمد العمليات على مقاييس الأعمال.

أخبرنا فلاديمير أوتراتينكو عن مدى "دموية" DevOps في المؤسسة وكيف يتم تنفيذ الممارسات داخل متاجر التجزئة الكبيرة - شاهد المقابلة:

4. سيرجي بوزيريف، فيسبوك: "مهندس الإنتاج يهتم بالخدمة ككل: بحيث يقضي كل من المستخدمين والمطورين وقتًا ممتعًا"

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

أخبر سيرجي ما يفعله مهندس الإنتاج على فيسبوك:

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

5. ميخائيل شينكوف، AMBOSS: "لا يمكن لقسم واحد أن يتبع مسار DevOps، يجب على الشركة بأكملها اتباعه"

يعتقد ميخائيل أن DevOps هو تطوير مستمر. لا يمكنك تقديم بعض الأدوات والتوقف عند هذا الحد. ما هي المشاكل التي تمنع الشركات من أن تصبح DevOps وكيفية تنفيذ الممارسات؟

الفرق في فهم DevOps. إن المبادئ القانونية، كما يراها الإنجيليون، ترتكز على خمس ركائز:

• الثقافة - التركيز على الناس والتعاون؛
• الأتمتة - تفويض الروتين لسير العمل؛
• العجاف - التركيز على تقديم القيمة للمستخدم؛
• المشاركة - التبادل المستمر للمعرفة؛
• المقاييس وتلقي ردود الفعل باستخدامها.

تركز الشركات عادة فقط على الأتمتة وتقديم القيمة للمستخدم. لكن الثقافة ومشاركة المعرفة ومقاييس DevOps لتتبع التطوير تتلاشى في الخلفية.

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

لماذا لم نصبح DevOps بعد؟ هناك مشكلتان رئيسيتان. في المؤسسة، هناك تطور بطيء للمنظمة، وصعوبات في تغيير المتجه في أذهان الآلاف من الموظفين. في الشركات الناشئة، هناك نقص في مصادر المعرفة ومشكلة في تخصيص الموارد للتحول.

مراحل تطوير DevOps في الشركة:

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

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

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

6. عشاق DevOps في Rosbank: "1000 يوم لتنفيذ DevOps في مؤسسة دموية"

أخبر يوري بوليتش ​​ودينا مالتسيفا وإيفجيني بانكوف من Rosbank كيف أتوا إلى DevOps في ثلاث سنوات. كان هناك هدفان: حل مشاكل محددة في فرق محددة وتنفيذ أدوات مركزية.

وإليكم النتائج التي تم التوصل إليها:

نتائج فرق المنتج: تجميع أسرع 30 مرة، وتركيب أسرع 6 مرات، وتوفير يصل إلى 30% في الدورة الكاملة. لدينا الآن القدرة على الضغط على زر للانتقال إلى الإنتاجية

نتائج لأوامر النظام الأساسي: تجميع وتركيب أسرع بـ 10 مرات، وزيادة عدد عمليات التثبيت بنسبة 87%، وتغطية الاختبار التلقائي بنسبة 46%. فريق التكامل لم يعد عنق الزجاجة

إذًا، كيف يمكن تنفيذ ممارسات DevOps في مؤسسة دموية؟

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

في البنوك والمؤسسات الأخرى، من الضروري وضع القيود مسبقًا مع فريق أمن المعلومات وإيجاد حل يسمح بتنفيذ التغييرات.

بعد التجربة، يجب توسيع نطاق الحل الناجح.

1. ومن المهم "تصويب" خط الأنابيب قدر الإمكان، وإزالة الروابط غير الضرورية منه، وتسليط الضوء على موفري القيمة، وإزالة المكونات المتبقية. الوسطاء هم أنماط مضادة. على سبيل المثال، في Rosbank، لم يقم عدد من الفرق بتطوير التطوير الداخلي، ولم يتبق سوى التطوير الخارجي. وأدى ذلك إلى ظهور فريق DevOps المخصص، والذي ضمن نقل التعليمات البرمجية من المطورين الخارجيين إلى المطورين الداخليين. تم حل المشكلة عن طريق دمج التطوير الخارجي في CI/CD، بحيث لا يقومون بنقل الكود من أنفسهم إلى البنك فحسب، بل سيكونون مسؤولين أيضًا عن نجاحه.
2. يتضمن نموذج النضج عناصر ممارسات DevOps، والأدوات المدرجة، ويأخذ في الاعتبار ميزات العمل مع الموردين الخارجيين - وقد ساعد ذلك في المستقبل على تقليل تراكم المهام بسرعة عند تنفيذها في فرق جديدة.
3. نحن بحاجة إلى الحوكمة في شكل رقابة ناعمة وتوصيات. كتيب DevOps الذي يعمل بشكل جيد هو عبارة عن مجموعة من الخصائص التنظيمية والأدوات التي تساعد الفرق على استخدام النظام الأساسي بشكل صحيح.
4. يجب عليك الانتباه على الفور إلى الثقافة، ثم ستحدث العديد من التغييرات بشكل أسرع وأسهل. قم بتنمية مجتمعك الداخلي، وقم بإجراء اللقاءات وورش العمل الفنية والدورات التدريبية والأنشطة الترفيهية. وهذا يؤتي ثماره: يتشارك الأشخاص الممارسات، ويرون من فعل ماذا، ويعرفون إلى أين يتجهون، وهناك ضجيج ومنافسة صحية داخل الشركة.
5. لا فائدة من العمل مع من لا يشارك في العملية، مع فرق لم تنضج، ومن الأفضل الاستثمار في فرق مهتمة وأشخاص مخلصين.
6. يجب أن يكون الحل المختار مناسبًا للمهندسين الذين يستخدمونه.
7. التطوير الخارجي ليس عائقًا، بل يمكن أيضًا تنفيذ الممارسات هناك، والشيء الرئيسي هو أن الفريق نفسه لديه الرغبة.

المزيد من الفائدة قليلا

قائمة الكتب التي تستحق القراءة للعاملين في DevOps، من ألكسندر تشيستياكوف، vdsina.ru:

1. إيرينا ياكوتينكو "الإرادة وضبط النفس".
2. دانييل كانيمان "التفكير السريع والبطيء".
3. باربرا أوكلي "عقل للأرقام".
4. مكسيم دوروفييف "تقنيات جدي".
5. فيكتور فرانكل "بحث الإنسان عن المعنى".

ترّقب

نحن نحب DevOps أيضًا. تابع اعلانات المسلسل @ديف أوبس و@Kubernetes، بالإضافة إلى أحداث Mail.ru Cloud Solutions الأخرى، في قناة Telegram الخاصة بنا: t.me/k8s_mail

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