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

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

لقد جمعنا رؤى رئيسية من ست محادثات وأجرينا مقابلات مع العديد من المتحدثين لمعرفة المزيد حول ما تجاوز المحادثات.

داخل:

1. باروخ سادوجورسكي، JFrog: "دع البرنامج يتدفق من البائع إلى المستخدم مثل السائل"
2. بافيل سيليفانوف، ساوثبريدج: "يشترك فريق التطوير والعمليات في مهمة واحدة - وهي إنشاء منتج فعال"
3. فلاديمير أوتراتنكو، مجموعة X5 للتجزئة: "DevOps في المؤسسات هو تطوير بدون ألم أو حرائق"
4. سيرجي بوزيريف، فيسبوك: "مهندس الإنتاج يهتم بالخدمة ككل: حتى يشعر كل من المستخدمين والمطورين بالرضا"
5. ميخائيل تشينكوف، AMBOSS: "لا يمكن لقسم واحد أن يتبع مسار DevOps؛ بل يجب على الشركة بأكملها أن تتبعه"
6. عشاق DevOps في Rosbank: "1000 يوم لتطبيق DevOps في مؤسسة ضخمة"

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

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

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

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

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

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

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

تحديثات متكررة - المساعدة في تطوير العادة والتخلص من الخوف. تتحول التحديثات النادرة إلى حدث طارئ.

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

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

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

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

2. بافيل سيليفانوف، ساوثبريدج: "يشترك فريق التطوير والعمليات في مهمة واحدة - وهي صنع منتج فعال".

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

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

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

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

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

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

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

3. فلاديمير أوتراتنكو، مجموعة X5 للتجزئة: "DevOps في المؤسسات هو تطوير بدون ألم أو حرائق"

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

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

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

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

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

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

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

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

شرح سيرجي ما يفعله مهندس الإنتاج في الفيسبوك:

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% من خلال الاختبارات الآلية. لم يعد فريق التكامل يشكل عنق زجاجة

إذن كيف يمكنك تنفيذ ممارسات DevOps في مؤسسة ضخمة؟

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

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

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

1. من المهم "تقويم" الناقل قدر الإمكان، وإزالة الروابط غير الضرورية منه، وتحديد الموردين ذوي القيمة، وإزالة المكونات المتبقية. الروابط الوسيطة هي أنماط مضادة. على سبيل المثال، في شركة روس بنك، لم ينجح التطوير الداخلي في عدد من الفرق، ولم يتبق سوى التطوير الخارجي. وقد أدى هذا إلى إنشاء فريق 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