قمت مؤخرًا بزيارة DevOpsForum 2019 باستضافة Logrocon. في هذا المؤتمر ، حاول المشاركون إيجاد حلول وأدوات جديدة للتفاعل الفعال بين رجال الأعمال والمتخصصين في خدمات التطوير وتكنولوجيا المعلومات.
كان المؤتمر ناجحًا: كان هناك كثيرًا من التقارير المفيدة ، وأشكال العروض التقديمية المثيرة للاهتمام والكثير من التواصل مع المتحدثين. ومن المهم بشكل خاص ألا يحاول أحد أن يبيعني أي شيء ، إلا أن المتحدثين في المؤتمرات الكبيرة ألقوا باللوم عليهم مؤخرًا.
الضغط من خطب Raiffeisenbank ، Alfastrakhovanie ، تجربة Mango Telecom في تنفيذ الأتمتة وغيرها من التفاصيل تحت الخفض.
اسمي Yana ، أنا أعمل كاختبار ، وأنا منخرط في التشغيل الآلي ، وكذلك DevOps وأحب الذهاب إلى المؤتمرات والاجتماعات. على مدار العامين الماضيين ، كنت في مؤتمرات أوليغ بونين (HighLoad ++ ، TeamLead Conf) ، وأحداث Jug (Heisenbug ، JPoint) ، TestCon Moscow ، DevOps Pro Moscow ، Big Data Moscow.
بادئ ذي بدء ، أود الانتباه إلى برنامج المؤتمر. إلى حد أقل ، أنظر إلى ما سيكون عليه التقرير ، إلى حد كبير - للمتحدث. حتى لو كان التقرير تقنيًا وممتعًا للغاية ، فليس من الواقع أنك ستتمكن من تطبيق بعض أفضل الممارسات من التقرير في شركتك. وبعد ذلك تحتاج إلى المتكلم.
ضوء في نهاية خط الأنابيب في Raiffeisenbank
عادة ، أذهب للبحث عن متحدثين مثيرين للاهتمام على الهامش. في DevOpsForum 2019 ، دخل ميخائيل بيزان ، متحدث من Raiffeisenbank ، في مجال اهتمامي. خلال الخطاب ، أخبرهم كيف يزرعون فرقهم بثبات على DevOps ، ولماذا يحتاجون إليها وكيف يبيعون فكرة تحول DevOps إلى العمل. حسنًا ، بشكل عام ، تحدثت عن كيفية رؤية الضوء في نهاية خط الأنابيب.
ميخائيل بيزان ، مدير الأتمتة في Raiffeisenbankالآن ليس لشركتهم "DevOps". هذا صحيح ، لكن ليس في جميع الفرق. عند تطبيق DevOps ، يعتمدون على استعداد الفرق سواء من وجهة نظر المهندسين المعنيين ، أو من وجهة نظر احتياجات المنتج ونضج النظام الأساسي الذي تم بناء هذا المنتج عليه. أخبرت ميشا كيف تشرح لرجال الأعمال سبب حاجة DevOps.
للقطاع المصرفي العديد من محركات النمو: تكلفة الخدمات وتوسيع قاعدة العملاء. زيادة تكلفة الخدمات ليس محركًا جيدًا للغاية ، ولكن نمو قاعدة العملاء هو العكس. إذا أنتج المتنافسون منتجًا رائعًا وموضوعيًا ، فسيذهب جميع العملاء إلى هناك ، ومع مرور الوقت ، سوف يتساوى السوق. لذلك ، فإن إطلاق منتجات جديدة في السوق وسرعة طرحها هو الشيء الرئيسي الذي تسترشد به البنوك. هذا هو بالضبط ما هو DevOps ، والأعمال يفهم هذا.
الملاحظة المهمة التالية: لا تقلل DevOps دائمًا من الوقت للسوق. لا يمكن أن تعمل DevOps بمفردها ، فهي جزء فقط من عملية إنشاء وإطلاق منتج في السوق من التطوير إلى الإنتاج (من الكود إلى العميل). لكن كل شيء قبل الكود ليس له علاقة مباشرة بـ DevOps. وهذا هو ، يمكن للمسوقين دراسة السوق لسنوات واللحاق مع المنافسين طوال حياتهم. يجب أن تفهم بسرعة ما يحتاجه العميل وتخطط لتنفيذ ميزة معينة - غالبًا ما لا يكون ذلك كافياً لقيام DevOps بالعمل والشركة لتحقيق هذا الهدف. لذلك ، قبل كل شيء ، وافق Raiffeisenbank مع الشركة على أنه من الضروري معرفة كيفية استخدام DevOps. الأتمتة من أجل الأتمتة لن تساعد كثيرا في النضال من أجل عملاء جدد.
بشكل عام ، تعتقد Misha أنه يجب تنفيذ DevOps ، ولكن بحكمة. ويجب أن تكون مستعدًا لحقيقة أن الفريق في بداية عملية التغيير سوف يفقد الإنتاجية ، وسيكسب أموالًا أقل ، ولكن بعد ذلك سيتحقق ذلك.
أتمتة الاختبار في Mango Telecom
قدم ايجور ماسلوف من شركة مانجو تيليكوم تقريرًا آخر مثيرًا للاهتمام بالنسبة لي كاختبار. تم تسمية العرض التقديمي "أتمتة دورة الاختبار الكاملة في فريق SCRUM." يعتقد إيجور أنه تم إنشاء DevOps خصيصًا لـ SCRUM ، ولكن في الوقت نفسه ، يعد إدخال DevOps في فريق SCRUM مشكلة كبيرة. هذا لأن فريق SCRUM يعمل دائمًا في مكان ما ، فلا يوجد وقت لتشتت الانتباه عن طريق الابتكارات وإعادة بناء العملية. تكمن المشكلة أيضًا في حقيقة أن SCRUM لا تعني فرقًا فرعية (فريق اختبار أو فريق تطوير أو ما إلى ذلك). حسنًا ، بالإضافة إلى ذلك ، هناك حاجة إلى وثائق لأتمتة العملية الحالية ، وفي SCRUM غالبًا لا توجد وثائق على الإطلاق - "المنتج أهم من نوع من الخربشة".
بعد التبديل إلى SCRUM ، بدأ المختبرون في التشاور مع المطورين حول كيفية اختبار الميزات. تدريجيا ، زاد حجم الوظيفة ، وكانت الوثائق في عداد المفقودين ، وبدأوا في التقاط العديد من الأخطاء في الوظيفة التي لم يكن فيها تغطية اختبار وبشكل عام لم يعد واضحا من ومتى تم اختباره. باختصار - الارتباك والترنح. قررنا التبديل إلى اختبار الأتمتة. ولكن بعد ذلك كان هناك فشل كامل. لقد جذبوا المتخصصين في الاستعانة بمصادر خارجية للتشغيل الآلي الذين كتبوا على كومة غير معروفة للمختبرين العادية. لقد نجح إطار autotest بالتأكيد ، ولكن بعد مغادرة المتعهدين الخارجيين ، عاش لمدة أسبوعين. ثم كانت هناك محاولة لتقديم الاختبار الذاتي رقم اثنين. لقد بدأت مع حقيقة أن كل شيء يحتاج إلى بناء داخل الشركة ، من تلقاء نفسها (الموجه الصحيح: زيادة الخبرة من الداخل) ، في إطار SCRUM ، وفي عملية إنشاء الوثائق. يجب أن تكون رصة الأتمتة مساوية لمجموعة المنتجات (هنا سأقوم بالإضافة المباشرة ، حسناً ، لا تختبر مشروعك في JavaScript باستخدام أي شيء آخر). في نهاية سباق العدو ، رتبوا عرضًا تجريبيًا لكيفية عمل الاختبار التلقائي ، بمشاركة الفريق بأكمله (مفيد). وبالتالي ، زادت مشاركة جميع أعضاء الفريق في عملية الأتمتة ، وكذلك الثقة في الاختبارات الذاتية وفرصة استخدام هذا الاختبار التلقائي بدقة (ولن يتم التعليق عليه في شهر بسبب الإخفاقات المستمرة).
بالمناسبة ، عمل ميكروفون مفتوح في DevOpsForum 2019 - وهو تنسيق معروف ومفيد منذ أمد طويل. أنت تمشي على هذا النحو ، وتستمع إلى التقارير ، ثم تقرر أن الأمر يستحق مناقشة موضوع أو مشكلة في إطار المؤتمر ، وتبادل الخبرات ذات الصلة في حل المشكلة.
لاحظت أيضًا أن المنظمين قدموا مجموعة من التقارير القصيرة. لا يدوم كل تقرير أكثر من 10 دقائق ، ثم تأتي الأسئلة. وبالتالي ، يمكنك تغطية الكثير من الموضوعات في وقت واحد وتوجيه الأسئلة إلى المتحدثين المهتمين.
بين التقارير ، تجولت حول مواقف شركاء المؤتمر وسحبت / فزت بالكثير من الأشياء. إيه ، أنا أحب razdatku!أسئلة المائدة المستديرة و DevOps مع Alfastrah Development Director
كان الكرز على كعكة DevOpsForum 2019 بالنسبة لي جلسة عامة لمدة ساعة مع خبراء DevOps. تمت دعوة أربعة مشاركين لمشاهدة DevOps من زوايا مختلفة: أنطون إيسانين (Alfastrakhovanie ، مدير التطوير) ، نائلة Zamashkina (مختبر Fintech ، مدير العمليات) ، أوليغ Egorkin (Rostelecom ، مدرب Agile) وأنتون Martyanov (مستقل خبير ، نظرت إلى DevOps من منظور الأعمال).
جلس الخبراء بالقرب من الناس وبدأ الأمر: لمدة ساعة طرح المشاركون من الحضور أسئلتهم ، وانتفخ الخبراء. في بعض الأحيان خرج نقاش حقيقي. كانت الأسئلة مختلفة تمامًا ، على سبيل المثال: هل هناك حاجة لمهندسي DevOps على الإطلاق ، ولماذا لا يمكن أن ينمووا من مسؤولي النظام ، وإذا تم تقديم DevOps للجميع ، فما هي قيمتها وما إلى ذلك.
ثم ، تحدثت مع أنتون Isanin شخصيا. ناقشنا الحاجة إلى جلب ثقافة DevOps إلى كل منزل وكشفنا الجانب المظلم من تحول DevOps.
تخيل أن الجميع تجمعوا وقرروا أن DevOps مطلوبة لكل من المنتج وللأعمال وللأعضاء في الفريق. هرع لتقديم. كل شيء يعمل بها. الزفير. جعلنا DevOps أقرب إلى العميل ، والآن يمكننا تلبية جميع تمنياته بسرعة. نتيجة لذلك ، لدينا قسم كبير من العمليات Ops مع أنظمة ومتطلبات صارمة ، وهو يكتشف باستمرار عيوب المنتج ، ويخلق مجموعة من التطبيقات. علاوة على ذلك ، تأتي جميع العيوب بحالة "عاجل" ، حتى لو أراد العميل فجأة رسم الزر باللون الأصفر بدلاً من اللون الأخضر. المشروع ينمو ، وعدد الإصدارات ينمو ، وبالتالي عدد العيوب وسوء الفهم للوظائف الجديدة من قبل العملاء. تقوم شركة Ops بتعيين 10 أشخاص آخرين لمواكبة هذه العيوب ، بينما تقوم شركة التطوير بتعيين 15 شخصًا آخر لمواكبتهم. وبدلاً من تقديم ميزات جديدة ، يعمل الفريق مع بطاقات SD لا نهاية لها ، موضحًا الوظيفة للمستخدم ودعم أحدها. كنتيجة لذلك ، فإن كلا من Ops والتطوير في العمل ، لكن العميل والأعمال غير سعداء: تتعطل الميزات الجديدة. اتضح أن DevOps يبدو أنه موجود ، لكنه لا يبدو كذلك.
حول الحاجة إلى تنفيذ DevOps ، صرح Anton بشكل لا لبس فيه أن هذا يعتمد بشكل مباشر على نطاق العمل. إذا كانت خدمة عميل واحد في السنة تجلب للشركة مليار - فإن DevOps ليست ضرورية (شريطة ألا تحتاج إلى طرح تغييرات جديدة على هذا العميل بانتظام). كل شيء الشوكولاته جدا. ولكن إذا نمت الأعمال ، فظهر عدد أكبر من العملاء ، فعلينا الالتزام بذلك. وكقاعدة عامة ، فإن الشركة ليس لديها مكتب خدمات المشاريع بارد في البداية. أولاً شاهدنا المنتج ، وعندها فقط نفهم أن المنتج يجب أن يعمل ، تحتاج إلى إلقاء نظرة على الخوادم ، ومراقبة عمليات التسليم. ثم تنشأ العمليات. يبقى أن نفهم أن Ops ، كوحدة منفصلة ، ستبدأ في الكشف عن مجموعة من العوائق التي تحول دون التنمية وستبدأ جميع عمليات التسليم بالتوقف. هذا هو ، في هذه الحالة ، ثقافة DevOps وثيقة الصلة بالفعل ، لكن يجب ألا تنسى جانبها المظلم.