في 7 ديسمبر ، تم تنظيم مؤتمر
DevOpsDays Moscow الثالث من قبل
مجتمع Moscow DevOps بدعم من Mail.ru Cloud Solutions. بالإضافة إلى تقارير كبار ممارسي DevOps ، يمكن للمشاركين حضور محادثات Lightning Talks قصيرة وورش العمل والدردشة في الأماكن المفتوحة.
جمعنا رؤى مهمة من ستة عروض ، وأجرينا مقابلات مع العديد من المتحدثين لمعرفة ما تبقى من التقارير.
داخل:
- Baruch Sadogursky ، JFrog: "دع البرنامج يتدفق من البائع إلى المستخدم ، مثل السائل"
- بافيل سيليفانوف ، ساوثبريدج: "لدي ديف وأوبس مهمة واحدة مشتركة - صنع منتج يعمل"
- Vladimir Utratenko ، مجموعة البيع بالتجزئة X5: "DevOps in Enterprise هي التنمية دون ألم وحرائق"
- سيرجي بوزيريف ، Facebook: "مهندس الإنتاج يهتم بالخدمة ككل: بحيث يشعر كل من المستخدمين والمطورين بالرضا"
- ميخائيل تشينكوف ، AMBOSS: "وحدة واحدة لا يمكن أن تتبع مسار DevOps ، يجب على الشركة بأكملها اتباعها"
- عشاق Rosbank DevOps: "1000 يوم لتنفيذ DevOps في المؤسسة الدموية"
1. Baruch Sadogursky ، JFrog: "دع البرنامج يتدفق من البائع إلى المستخدم ، مثل السائل"
يحدث فشل عند تحديث البرنامج كل ساعة وللجميع. إليكم مجرد قصة واحدة مخيفة من الخطاب: لقد فقدت نايت كابيتال 440 مليون دولار في الساعة بعد تحديث غير ناجح.
تحدث باروخ عن أنماط DevOps للتحديثات المستمرة التي ستساعد على تجنب فشل المستخدم والكراهية:
الاستعادة المحلية - احتفظ بالإصدار السابق من البرنامج على الجهاز للتراجع في حالة حدوث شيء ما. سيوفر لك هذا الحماية إذا كان كل شيء سيئًا للغاية بحيث لا يمكنك إرسال التصحيح عبر الهواء.
تحديثات الهواء هي أفضل المستمر. سيكون الأمر مختلفًا ، كما هو الحال مع مطوري Jaguar: نظرًا لوجود خطأ في نظام الفرامل لا يمكن تحديثه عن طريق الجو ، كان من الضروري استدعاء السيارات من البيع. كان مؤلما ومكلفا.
تحديثات مستمرة - تحديث البرنامج بشكل مستمر بمجرد أن تصبح الميزة الجديدة جاهزة. مع التحديثات النادرة ، يتم تجميع الميزات ، يمكن أن ينتظر التحديث الضروري التحديثات غير الهامة. كما هو الحال في تسلا ، كان التحديث الذي كان من المفترض أن يصلح الكبح العشوائي في انتظار تحديث لعبة الشطرنج.
النشر التلقائي - استبدال الأشخاص بالآلات ، لأن الأشخاص لا يعرفون كيفية تنفيذ الإجراءات الروتينية.
تحديثات متكررة - ساعد في تطوير عادة والتخلص من الخوف. التحديثات النادرة تتحول إلى حدث طارئ.
معرفة حالة الجهاز - تحديثات الاختبار ، وليس التثبيت من نقطة الصفر. هذا أمر مهم ، نظرًا لأن التحديثات يمكن أن تتصرف بشكل مختلف حسب حالة الجهاز.
إصدارات الكناري - نشر التحديثات على عدد صغير من المستخدمين ومشاهدتها. هذا يقلل من الضرر إذا حدث خطأ ما.
تحديثات دون إمكانية الوصول - دع العملاء يلاحظون ميزات جديدة فقط ، ولا يظلون بدون خدمة لعدة أسابيع حتى تقوم بنشر التحديث.
تحدثنا مع Baruch Sadogursky حول كيف تختلف النظرة المستقبلية على DevOps في تكنولوجيا المعلومات الروسية والغربية ، وما إذا كانت خدمة Cloud ستفعل كل شيء بالنسبة لنا قريبًا وما إذا كانت جميع خدمات البرامج ستنزلق إلى مخطط aaS - راجع المقابلة:
2. بافيل سيليفانوف ، ساوثبريدج: "لدي ديف وأوبس مهمة واحدة مشتركة - صنع منتج يعمل"
لن يساعد تطبيق Kubernetes على تحقيق DevOps ، بل والعكس صحيح - يمكن أن يكسر كل شيء. أخبر بافل لماذا لا تستطيع التقنيات (حتى الأروع) حل جميع مشاكلك:
تعقيد المشروع قد تجاوز الكود . في السابق ، كان هناك تطبيق معقد: التفاعل داخل المشروع والتطوير المعقد ، ولكن بنية بسيطة - نشر المسؤول ، كل شيء يعمل. لقد تحولنا إلى خدمات microservices: كل خدمة عبارة عن تطبيق بسيط ، التواصل باستخدام البروتوكولات القياسية والتطور السريع ، لكن هيكل المشروع أصبح أكثر تعقيدًا. لم يختف تعقيد المشروع بهندسة الخدمات الميكروية - فقد تجاوز الكود. الآن مهندس DevOps هو المسؤول عن ذلك.
لا يريد المطورون إجراء تغييرات بعد تنفيذ DevOps . نتيجة لذلك ، يظل سير العمل مع Kubernetes يبدو وكأنه يقوم بمهام الرمي من Dev إلى Ops من خلال الجدار ، ولكن لم يعد الاستعارة - Git يصبح مثل هذا الجدار. يضع المطور الشفرة هناك ويعمل كما كان من قبل ، ويكون لدى المشرفين Kubernetes و CI / CD وكل شيء آخر.
ومع ذلك ، يحتاج المطورون إلى قبول التغييرات . الموقف عندما لا يعرف المطورون ما يفعله المسؤولون ، ولا يعرف المسؤولون ما يحدث للمطورين ، يؤدي إلى حدوث مشاكل.
إذا لم يغير المطورون أي شيء ، فلن يدركوا أن عمل التطبيق هو مسؤوليتهم - لن تنجح الحيل الفنية المختلفة.
مع ظهور DevOps و Kubernetes ، سيتغير الكثير في التنمية. يجب أن يكون Dev مختصًا في العمليات ، والعكس صحيح. هؤلاء المتخصصون لديهم مهاراتهم الخاصة ، لكن يجب أن يكونوا على دراية بعمل بعضهم البعض. يجب أن يكون Dev and Ops أصدقاء قبل تطبيق Kubernetes ، وإلا فسوف تقطع ما هو عليه.
تحدث بافل سيليفانوف عن ما سيحدث لكوبنيتس في 5 سنوات وعن ما ينبغي بناء كومة تكنولوجية من أجل بدء تشغيل حديث - راجع المقابلة:
3. فلاديمير أوتراتنكو ، مجموعة البيع بالتجزئة X5: "DevOps in Enterprise هي التنمية دون ألم وحرائق"
تأتي الشركات إلى تحول DevOps عندما تدرك أن التنمية بطيئة للغاية ولا تفي بالواقع ، ولديها الرغبة في تطوير أفضل وطرح أسرع.
أخبر فلاديمير كيف يحدث هذا ، وما الفائدة:
- أولاً ، تقوم الشركات بتوظيف مهندس DevOps. هذا هو مسؤول نظام أقدم ، وهو يشارك في نشر الإصدار في الإنتاج ، وتوحيد بيئة التطوير ، وإنشاء البنية التحتية ، واكتشاف وإصلاح المشاكل المختلفة ، وأتمتة العمليات والمهام الفنية الأخرى.
- ثم لم يعد مهندس DevOps واحدًا كافيًا ، وتوظف الشركة فريق DevOps. هذا هو مركز الكفاءة ، الذي ينظم جهود المهندسين المختلفين ، ويسمح لك بتركيزهم في اتجاه واحد.
- في الواقع ، فإن مهندس DevOps وفرق DevOps هم المضادون لتحولات DevOps. نظرًا لأن DevOps يدور حول الممارسات والثقافة ، بالإضافة إلى ذلك ، هناك تطبيقات لـ DevOps في شركات التكنولوجيا (SRE ، هندسة الإنتاج).
ماذا تفعل؟ سيؤدي التعاقد مع فريق DevOps مؤقتًا للمساعدة في تنفيذ تحول DevOps إلى تنفيذ الممارسات وتنمية ثقافة التنمية والثقافة التكنولوجية.
عندما تدخل شركة ما اللعبة وتستثمر في DevOps ، تكون عدة سيناريوهات ممكنة: كل شيء سينهار عند الإقلاع ؛ ستبقى كما SRE / هندسة الإنتاج أو العمليات المدمجة ؛ سينتقل إلى BizOps عندما تعتمد العمليات على مقاييس العمل.
أخبرنا فلاديمير أوتراتينكو عن مدى تطور DevOps "الدامي" في المؤسسة وكيف يتم تنفيذ الممارسات داخل متاجر البيع بالتجزئة الكبيرة - راجع المقابلة:
4. سيرجي بوزيريف ، Facebook: "مهندس الإنتاج يهتم بالخدمة ككل: بحيث يشعر كل من المستخدمين والمطورين بالرضا"
Facebook هي شركة ضخمة بها العديد من المكونات والخوادم والأشخاص ومراكز البيانات. على الرغم من حجمها الضخم ، فهي سريعة للغاية - يمكن للمطورين طرح الخدمات عدة مرات في اليوم. ينمو Facebook أيضًا بسرعة ، ولا يتعلق الأمر فقط بزيادة عدد المستخدمين والخوادم ، بل إن عدد المطورين يزداد أيضًا ، مما يعقد العمليات.
أخبر سيرجي ما يفعله مهندس الإنتاج على Facebook:
- مهندس الإنتاج يقنن الكثير ، يجب أن يكون لديه معرفة بالنظام: أنظمة التشغيل ، أنظمة الملفات ، قواعد البيانات ، الشبكات وما شابه. يجب أن يكون لديك خبرة في الأنظمة الموزعة وهندسة الموثوقية ، أي في دعم موثوقية المنتج. يجب أن يكون عند الطلب ، وهذا متاح للاتصال في أي وقت.
- يختلف مهندس الإنتاج عن مهندس البرمجيات في المهارات المتقدمة في التشغيل ، ولكنه في الواقع نوع فرعي من مهندس البرمجيات. رمز مهندس البرمجيات أكثر ، قد يكون لديهم مهارات إضافية ذات صلة ، على سبيل المثال ، لمعالجة البيانات. على Facebook ، يجب أن يكون هؤلاء المتخصصون تحت الطلب ، وهو ما يعد بالنسبة للكثيرين مفاجأة غير سارة.
- يبدأ هرم احتياجات مهندس الإنتاج في الشركة بمراقبة الخوادم ودورة حياتها ، أي تلقي أجهزة جديدة ، وإعدادها ، وتشغيلها. المستوى التالي هو نفسه على مستوى الخدمة: خدمات المراقبة ودورة حياتها. ثم يأتي التحجيم السلس والمراقبة المتقدمة. أنها تتحول إلى autoscaling بعد أتمتة دورة حياة الخدمة. وفي النهاية ، عليك القيام بالموالفة بحيث يكون التدريج فعالًا ، حيث تقوم الشركة بتوفير الأموال والموارد.
5. ميخائيل تشينكوف ، AMBOSS: "وحدة واحدة لا يمكن أن تتبع مسار DevOps ، يجب على الشركة بأكملها اتباعها"
مايكل يعتقد أن DevOps هو تطور مستمر. لا يمكنك تقديم أي أدوات والتوقف عند هذا الحد. ما هي المشاكل التي تمنع الشركات من أن تصبح DevOps وكيفية تنفيذ الممارسات؟
الفرق في فهم DevOps . يرتكز المصلون الكنسيون ، كما يراها الإنجيليون ، على 5 أعمدة:
- الثقافة - التركيز على الناس والتعاون ؛
- الأتمتة - تفويض الروتين إلى سير العمل ؛
- العجاف - التركيز على تقديم القيمة للمستخدم.
- تقاسم - تبادل المعرفة المستمر.
- المقاييس والحصول على ردود الفعل مع مساعدتهم.
عادة ما تركز الشركات فقط على التشغيل الآلي وتقديم القيمة للمستخدم. لكن الثقافة ومشاركة المعرفة ومقاييس DevOps ، والتي يمكنك من خلالها تتبع التنمية ، تمضي على الطريق.
مشاكل توحيد DevOps . أهداف المنتج مختلفة بالنسبة لجميع الشركات ؛ ولا يمكن توحيدها. تعتمد حالة DevOps في الشركة على الشركة نفسها ، لكن الكثيرين لا يفهمون هذا ويعتقدون أنه يكفي لتوظيف مهندس DevOps.
لماذا نحن لسنا DevOps حتى الآن؟ هناك مسألتان رئيسيتان. في المؤسسة - التطور البطيء للمنظمة ، وصعوبة تغيير المتجه في رؤساء الآلاف من الموظفين. في الشركات الناشئة ، هناك نقص في مصادر المعرفة ، مشكلة في تخصيص الموارد للتحول.
مراحل تطوير DevOps في الشركة :
- الأول هو البنية التحتية في السحابة ، لكن لا أحد يعرف كيف يعمل ، باستثناء واحد أو اثنين من المشرفين ؛
- والثاني - البنية التحتية شفافة ومفهومة لجميع المهندسين ، ولكن العمليات لا يتم وضعها.
- الثالث - المهندسين بشكل مستقل إطلاق وإصلاح الخدمات الحية ؛
- الرابع - المهندسين ، إذا رغبوا في ذلك ، سوف تسهم في البنية التحتية الأساسية ، رمز شفاف في السحابة ، ونشر زر.
المخطط المثالي - يتمتع كل شخص بنفس إمكانية الوصول إلى البنية التحتية ، ويمكن لجميع المهندسين الوصول إلى المنتج وفهم ما يفعلونه.
عند إغلاق كل أشكال الجشطالت الثقافية والتقنية ، سيأخذ تحول DevOps للشركة في الاعتبار ملاحظات من مقاييس العمل ومقاييس المنصة.
6. عشاق DevOps من Rosbank: "1000 يوم لتنفيذ DevOps في المؤسسة الدموية"
أخبر يوري بوليتش ، دينا مالتسيفا ، يوجين بانكوف من روسبانك كيف أتوا إلى DevOps في ثلاث سنوات. كان هناك هدفين: حل مشاكل محددة في فرق محددة وتنفيذ الأدوات المركزية.
وهنا النتائج المحققة:
نتائج فرق المنتج : تجميع أسرع 30 مرة ، تثبيت أسرع 6 مرات ، توفير يصل إلى 30٪ على دورة كاملة. حصلنا على فرصة لزر الزر إلى الإنتاجية
نتائج فرق النظام الأساسي : التجميع والتثبيت أسرع 10 مرات ، زاد عدد التركيبات بنسبة 87٪ ، والتغطية مع الاختبارات التلقائية 46٪. توقف فريق التكامل كونه عنق الزجاجة
لذلك ، كيفية تنفيذ ممارسات DevOps في المؤسسة الدموية؟
أولاً ، قم بتقديم مشروع تجريبي : اختر فرقًا ، وحدد كيفية تنفيذ الهيكل واختيار الأدوات. اخترنا أدوات برخصة مفتوحة ، مع التثبيت في البنك والخبرة في العمل معهم. في Rosbank ، جنبا إلى جنب مع منصة DevOps ، تم نشر سحابة خاصة ، وهذا ساعد في البداية. في السحابة ، كان من الممكن الحصول على الموارد اللازمة عن طريق زر في 15 دقيقة ، وقد تستغرق هذه العملية من قبل أسبوعًا.
في البنوك والمؤسسات الأخرى ، يتعين عليك وضع القيود مع فريق أمان المعلومات مسبقًا وإيجاد حل يتيح لك تنفيذ التغييرات.
بعد الطيار ، يجب توسيع نطاق الحل الناجح .
- من المهم "تصويب" الناقل بأكبر قدر ممكن ، وإزالة الروابط غير الضرورية منه ، وتسليط الضوء على مزودي القيمة ، وإزالة المكونات المتبقية. الوسطيات هي مضادات. على سبيل المثال ، في Rosbank ، لم يكن لدى عدد من الفرق تطوير داخلي ، إلا أنه ظل خارجيًا. وأدى ذلك إلى ظهور فريق DevOps مخصص ، والذي قدم نقل الكود من المطورين الخارجيين إلى المطورين الداخليين. تم حل المشكلة من خلال دمج التطوير الخارجي في CI / CD بحيث لن يقوموا فقط بنقل الكود من أنفسهم إلى البنك ، ولكن أيضًا يكونون مسؤولين عن نجاحه.
- تم تضمين عناصر تطبيق DevOps في نموذج الاستحقاق ، وتم إدراج الأدوات ، وتم أخذ ميزات العمل مع الموردين الخارجيين في الاعتبار - وقد ساعد ذلك في المستقبل على تقليل تراكم المهام بسرعة عند تنفيذها في فرق جديدة.
- وهناك حاجة إلى الحكم في شكل سيطرة لينة والتوصيات. يعمل دليل DevOps بشكل جيد - فهو عبارة عن مجموعة من الخصائص التنظيمية والأدوات التي تساعد الفرق على استخدام النظام الأساسي بشكل صحيح.
- يجدر الانتباه على الفور إلى الثقافة ، ثم العديد من التغييرات ستكون أسرع وأسهل. تنمية المجتمع الداخلي ، وعقد الاجتماعات ، وورش العمل التقنية ، والتدريب ، والأنشطة الترفيهية. إنه يؤتي ثماره: يشارك الناس ممارساتهم ، ومعرفة من فعل ما ، ومعرفة إلى أين يتجه ، هناك ضجيج ومنافسة صحية داخل الشركة.
- لا معنى للعمل مع أولئك الذين لا يشاركون في العملية ، مع فرق غير ناضجة ، فمن الأفضل الاستثمار في فرق المهتمين والأشخاص المخلصين.
- يجب أن يكون الحل المحدد مناسبًا لهؤلاء المهندسين الذين يستخدمونه.
- التنمية الخارجية ليست مانعًا ، يمكنك أيضًا تنفيذ ممارسات هناك ، والشيء الرئيسي هو أن الفريق نفسه لديه رغبة.
أكثر قليلا جيدة
قائمة الكتب التي ينبغي قراءتها لأولئك الذين هم في DevOps ، من الكسندر Chistyakov ، vdsina.ru:
- إيرينا ياكوتينكو "الإرادة وضبط النفس".
- دانييل كانيمان "التفكير ، سريع وبطيء".
- باربرا أوكلي "عقل للأرقام".
- مكسيم دوروفيف "تقنيات جيدي".
- فيكتور فرانكل "بحث الرجل عن المعنى".
ترقبوا
نحن نحب DevOps أيضا. اتبع إعلانات سلسلةDevOps و @ Kubernetes ، وكذلك أحداث Mail.ru Cloud Solutions الأخرى ، في قناة Telegram لدينا:
t.me/k8s_mail