لقد حضرت مؤخرًا DevOpsForum 2019، الذي استضافته Logrocon. وحاول المشاركون في هذا المؤتمر إيجاد حلول وأدوات جديدة للتفاعل الفعال بين قطاع الأعمال والمتخصصين في مجال التنمية وخدمات تكنولوجيا المعلومات.
كان المؤتمر ناجحاً: كان هناك بالفعل الكثير من التقارير المفيدة، وأشكال العروض التقديمية المثيرة للاهتمام، والكثير من التواصل مع المتحدثين. ومن المهم بشكل خاص ألا يحاول أحد أن يبيع لي أي شيء، وهو الأمر الذي ارتكبه المتحدثون في المؤتمرات الكبيرة مؤخرًا.
مقتطف من خطابات Raiffeisenbank وAlfastrakovani وتجربة Mango Telecom في تنفيذ الأتمتة وتفاصيل أخرى تحت الخفض.
اسمي يانا، أعمل كمختبرة، وأقوم بالأتمتة، بالإضافة إلى DevOps، وأحب الذهاب إلى المؤتمرات واللقاءات. على مدار العامين الماضيين، حضرت مؤتمرات Oleg Bunin (HighLoad++، TeamLead Conf)، وأحداث Jug (Heisenbug، JPoint)، وTestCon موسكو، وDevOps Pro موسكو، وBig Data موسكو.
بادئ ذي بدء، أود أن ألفت الانتباه إلى برنامج المؤتمر. إنني أنظر أقل إلى موضوع التقرير وأكثر إلى المتحدث. حتى لو تبين أن التقرير تكنولوجي ومثير للاهتمام للغاية، فليس من الواقع أنك ستتمكن من تطبيق بعض أفضل الممارسات الواردة في التقرير في شركتك. وبعد ذلك تحتاج إلى مكبر صوت.
ضوء في نهاية خط الأنابيب في Raiffeisenbank
عادة، أبحث عن متحدثين على الهامش يثيرون اهتمامي. في DevOpsForum 2019، أثار اهتمامي أحد المتحدثين من Raiffeisenbank، ميخائيل بيزان. خلال كلمته، تحدث عن كيفية جعل فرقهم مرتبطة تدريجيًا بـ DevOps، ولماذا يحتاجون إليها، وكيفية بيع فكرة تحول DevOps إلى الأعمال. حسنًا، بشكل عام، تحدثت عن كيفية رؤية الضوء في نهاية خط الأنابيب.
ميخائيل بيزان، مدير الأتمتة في Raiffeisenbank
الآن ليس لديهم "DevOps" في شركتهم. أي أنه يعمل ولكن ليس في كل الفرق. عند تنفيذ DevOps، يعتمدون على جاهزية الفرق، سواء من حيث المهندسين المحددين، أو من حيث الحاجة إلى المنتج ونضج المنصة التي بني عليها هذا المنتج. أخبر ميشا كيف يشرح للشركة سبب الحاجة إلى DevOps.
لدى القطاع المصرفي العديد من محركات النمو: تكلفة الخدمات وتوسيع قاعدة العملاء. إن زيادة تكلفة الخدمات ليست دافعاً جيداً، ولكن تنمية قاعدة العملاء هي العكس. إذا أطلق المنافسون منتجًا رائعًا بشكل موضوعي، فإن جميع العملاء يذهبون إلى هناك، ثم بمرور الوقت تنخفض مستويات السوق. ولذلك فإن طرح منتجات جديدة في السوق وسرعة طرحها هو الأمر الأساسي الذي تركز عليه البنوك. هذا هو بالضبط ما تهدف إليه DevOps، والشركات تفهم ذلك.
الملاحظة المهمة التالية: لا تعمل DevOps دائمًا على تقليل وقت الوصول إلى السوق. لا يمكن لـ DevOps العمل بمفرده، فهو مجرد جزء من عملية إنشاء منتج وتقديمه إلى السوق بدءًا من التطوير إلى الإنتاج (من التعليمات البرمجية إلى العميل). لكن كل شيء قبل الكود لا يرتبط مباشرة بـ DevOps. أي أنه يمكن للمسوقين دراسة السوق لسنوات وقضاء حياتهم بأكملها في اللحاق بالمنافسين. من الضروري أن نفهم بسرعة ما يحتاجه العميل وأن نخطط لتنفيذ هذه الميزة أو تلك - غالبًا ما يكون هذا ما لا يكفي لكي تعمل DevOps وتحقق الشركة هدفها. لذلك، أولاً وقبل كل شيء، اتفق Raiffeisenbank مع رجال الأعمال على ضرورة تعلم كيفية استخدام DevOps. لن تساعد الأتمتة من أجل الأتمتة كثيرًا في النضال من أجل جذب عملاء جدد.
بشكل عام، يعتقد ميشا أنه يجب تنفيذ DevOps، ولكن بحكمة. ويجب أن نكون مستعدين لحقيقة أنه في بداية التحول ستنخفض إنتاجية الفريق، وسوف يكسب أموالاً أقل، ولكن بعد ذلك سيكون له ما يبرره.
أتمتة الاختبار في شركة Mango Telecom
تقرير آخر مثير للاهتمام بالنسبة لي كمختبر قدمه إيجور ماسلوف من شركة Mango Telecom. كان العرض التقديمي يسمى "أتمتة دورة الاختبار الكاملة في فريق SCRUM". يعتقد Egor أن DevOps تم إنشاؤه خصيصًا لـ SCRUM، ولكن في الوقت نفسه، يمثل إدخال DevOps في فريق SCRUM مشكلة كبيرة. يحدث هذا لأن فريق SCRUM يعمل دائمًا في مكان ما، ولا يوجد وقت لتشتيت انتباهه بالابتكارات وإعادة بناء العملية. تكمن المشكلة أيضًا في حقيقة أن SCRUM لا يتضمن فصل الفرق الفرعية في الفريق (فريق الاختبار، فريق التطوير، وما إلى ذلك). حسنا، إلى جانب ذلك، لأتمتة العملية الحالية، هناك حاجة إلى وثائق، وفي SCRUM، في أغلب الأحيان لا توجد وثائق تماما - "المنتج أكثر أهمية من أي كتابة".
بعد التحول إلى SCRUM، بدأ المختبرون في التشاور مع المطورين حول كيفية اختبار الميزات. تدريجيًا، زاد حجم الوظائف، ولم يكن هناك توثيق، وبدأوا في اكتشاف الكثير من الأخطاء في الوظائف التي لم تغطيها الاختبارات، وبشكل عام لم يعد من الواضح من الذي اختبرها ومتى. باختصار - الارتباك والتذبذب. قررنا التحول إلى اختبار الأتمتة. ولكن حتى ذلك الحين كان هناك فشل كامل. لقد استأجروا متخصصين في الأتمتة من مصادر خارجية والذين كتبوا على مجموعة غير معروفة للمختبرين الداخليين. نجح إطار الاختبارات التلقائية بالطبع، ولكن بعد مغادرة المتعاقدين الخارجيين، استمر لمدة أسبوعين. بعد ذلك كانت محاولة تقديم الاختبار التلقائي رقم اثنين. بدأ الأمر بحقيقة أنه يجب بناء كل شيء داخل الشركة، بمفردك (الناقل الصحيح: بناء الخبرة داخليًا)، في إطار عمل SCRUM، وإنشاء الوثائق في هذه العملية. يجب أن تكون حزمة الأتمتة مساوية لمجموعة المنتج (أنا أقوم بإضافتها هنا، لا تختبر مشروع JavaScript الخاص بك مع أي شيء آخر). في نهاية السباق، قاموا بعمل عرض توضيحي لكيفية عمل الاختبار التلقائي مع الفريق بأكمله (مفيد). وبالتالي، زادت مشاركة جميع أعضاء الفريق في عملية الأتمتة، فضلاً عن الثقة في الاختبارات التلقائية وفرصة استخدام هذا الاختبار التلقائي بالتأكيد (ولن يتم التعليق عليه خلال شهر بسبب الأعطال المستمرة).
بالمناسبة، في DevOpsForum 2019، كان هناك ميكروفون مفتوح - وهو تنسيق خطب معروف منذ زمن طويل، وفي رأيي، مفيد. أنت تتجول بهذه الطريقة، وتستمع إلى التقارير، ثم تقرر أنه في المؤتمر يستحق مناقشة موضوع أو مشكلة معينة، وتبادل الخبرات ذات الصلة في حل المشكلة.
ولاحظت أيضًا أن المنظمين قدموا مجموعة من التقارير القصيرة. لا يستمر كل تقرير أكثر من 10 دقائق، تليها الأسئلة. بهذه الطريقة يمكنك تغطية العديد من المواضيع في وقت واحد وطرح الأسئلة على المتحدثين الذين يثيرون اهتمامك.
بين العروض التقديمية، كنت أتجول في أكشاك شركاء المؤتمر وسرقت/ربحت الكثير من الأشياء. أوه، أنا أحب النشرة!
مائدة مستديرة وقضايا DevOps مع مدير التطوير في Alfastrakovani
كان تتويج كعكة DevOpsForum 2019 بالنسبة لي هو الجلسة العامة التي استمرت لمدة ساعة مع خبراء DevOps. تمت دعوة أربعة مشاركين في الجلسة للنظر إلى DevOps من زوايا مختلفة: أنطون إيسانين (ألفاسترخوفاني، مدير التطوير)، ناليا زاماشكينا (Fintech Lab، مدير التشغيل)، أوليغ إيجوركين (Rostelecom، مدرب Agile) وأنتون مارتيانوف (خبير مستقل، نظر في DevOps من وجهة نظر تجارية).
جلس الخبراء بالقرب من الناس ثم بدأت الأمور تحدث: لمدة ساعة كاملة، طرح المشاركون من الجمهور أسئلتهم، وقام الخبراء بالغناء. في بعض الأحيان كانت هناك مناقشات حقيقية. كانت الأسئلة مختلفة تمامًا، على سبيل المثال: هل هناك حاجة لمهندسي DevOps على الإطلاق، ولماذا لا يمكن تدريبهم كمسؤولين عن النظام، وهل ينبغي تقديم DevOps للجميع، وما هي قيمته، وما إلى ذلك.
ثم تحدثت شخصيا مع أنطون إيسانين. ناقشنا الحاجة إلى جلب ثقافة DevOps إلى كل منزل وكشفنا عن الجانب المظلم من تحول DevOps.
لنتخيل أن الجميع اجتمعوا معًا وقرروا أن DevOps مطلوبة لكل من المنتج والعمل والفريق. فلنذهب لتنفيذه. كل شيء على ما يرام. زفيرنا. لقد جعلتنا DevOps أقرب إلى العميل، والآن يمكننا تلبية جميع رغباته بسرعة. ونتيجة لذلك، لدينا قسم كبير للعمليات لديه لوائح ومتطلبات صارمة، وهو يكتشف باستمرار عيوبًا في المنتج ويخلق مجموعة من الطلبات. علاوة على ذلك، يتم تعيين حالة "عاجلة" لجميع العيوب، حتى لو أراد العميل بشكل غير متوقع تلوين الزر باللون الأصفر بدلاً من اللون الأخضر. ينمو المشروع، ويتزايد عدد الإصدارات، وبالتالي، عدد العيوب وسوء الفهم للوظائف الجديدة من قبل العملاء. تقوم شركة Ops بتعيين 10 أشخاص إضافيين لمواكبة الإبلاغ عن العيوب، وتقوم شركة Development بتعيين 15 شخصًا إضافيًا لمواكبة عملية إغلاقها. وبدلاً من تقديم ميزات جديدة، يعمل الفريق مع عدد لا يحصى من بطاقات SD، ويشرح للمستخدم الوظائف والدعم في نفس الوقت. ونتيجة لذلك، تعمل كل من العمليات والتطوير، لكن العميل والشركات غير راضين: تتعطل الميزات الجديدة. اتضح أن DevOps يبدو موجودًا، لكنه لا يبدو موجودًا.
فيما يتعلق بالحاجة إلى تنفيذ DevOps، ذكر أنطون بوضوح أن هذا يعتمد بشكل مباشر على حجم العمل. إذا كانت خدمة عميل واحد سنويًا تجلب للشركة مليارًا، فلن تكون هناك حاجة إلى DevOps (شريطة ألا تحتاج إلى طرح تغييرات جديدة على هذا العميل بانتظام). كل شيء مغطى بالشوكولاتة. ولكن إذا نما العمل وظهر المزيد من العملاء، فأنت بحاجة إلى الامتثال. كقاعدة عامة، لا توجد عمليات رائعة في الشركة في البداية. أولاً نقوم بقطع المنتج، وعندها فقط ندرك أنه لكي يعمل المنتج، نحتاج إلى مراقبة الخوادم ومراقبة الإمدادات. وذلك عندما تأتي العمليات إلى حيز الوجود. يبقى أن نفهم أن العمليات، كقسم منفصل، ستبدأ في وضع مجموعة من العوائق أمام التطوير وستبدأ جميع عمليات التسليم في التوقف. وهذا هو، في هذه الحالة، ثقافة DevOps ذات صلة بالفعل، لكن يجب ألا ننسى جانبها المظلم.
المصدر: www.habr.com