سد الثغرات: أهمية اتصالات DevOps

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

DevOps في كل مكان. وعلى الرغم من كونه اتجاهًا مثيرًا للاهتمام ، إلا أنه يجب أن يكون ملائمًا للمنتجات ، وليس العكس.

لكن بعض الناس لا يرون الأمر بهذه الطريقة. كثيرًا ما يُطرح علي أسئلة مثل ، "هل تعتقد أنه يجب علينا البدء في استخدام Docker ، أو الانتقال مباشرة إلى Kubernetes؟" مثل هذه الأسئلة لا معنى لها حتى دون معرفة ما هو المنتج.

كل هذه المصطلحات الفاخرة - السحابة ، Kubernetes ، الحاويات ، إدارة التكوين ، البنية التحتية ككود - تعد ببعض التحسين. لكنها تخص DevOps تمامًا مثل التلسكوبات بالنسبة لعلم الفلك. قد تكون مفيدة ، لكنها ليست ضرورية.

تهدف DevOps في جوهرها إلى سد الفجوة بين ما طلبه العميل وما قدمه فريق التطوير. هناك تركيز على دورات الإطلاق القصيرة ، والنهج التكراري للتصميم ، وأتمتة الخطوات المتكررة. ما رأيك هو الأهم لتحقيق ذلك؟

إذا قلت "اتصال رائع" ، فأنت على حق. الأدوات كلها جيدة. لكنهم لا يستحقون سوى الأموال المستثمرة فيها عندما يحسنون التواصل.

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

بمجرد تحديد هذه الخطوة الأولى ، والجميع يعرف ما يجب أن يحدث ، فهذا هو أفضل وقت لكتابتها. أين؟ حسنًا ، أنا من أشد المدافعين عن الحفاظ على README.md . يمكن لكل شخص في الفريق دائمًا إلقاء نظرة خاطفة عليه ومعرفة حالة المشروع ، وهو أمر طبيعي للوافدين الجدد على المشروع.

الأتمتة ، الخطوة التالية بعد كتابة التمهيدي ، اختيارية. ومع ذلك ، فهي نتيجة طبيعية لتوثيق العملية. ونعم ، الأتمتة هي ما يتبادر إلى الذهن غالبًا عند التفكير في DevOps.

انتظر لحظة ... الأتمتة اختيارية عندما يتعلق الأمر بـ DevOps؟ أليس DevOps هو قسم الشخص الذي يقوم بعمليات النشر؟

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

لذلك دعونا نلقي نظرة فاحصة على DevOps نفسه.

شرح DevOps

أولاً ، دعني أوضح لك ما لا يمثله DevOps:

1. إنها ليست مجرد بادئة مسمى وظيفي
2. إنه ليس فريقًا (لكن "Dev" و "Ops")
3. إنها ليست تقنية
4. لا يعني ذلك "مسؤول نظام يمكنه كتابة التعليمات البرمجية"
5. لا يعني ذلك "أتمتة الأشياء"
6. هذا لا يعني أنه "لا يوجد فريق عمليات الآن"

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

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

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

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

DevOps Automation هو توثيق

ربما لم تفكر في الأمر بهذه الطريقة. لكن معظم الأدوات المرتبطة بشكل شائع بـ DevOps هي أدوات توثيق :

• إنشاء نصوص مكتوبة لسهولة القراءة تعمل على توثيق عملية البناء
• توثق خطوط أنابيب التكامل المستمر عملية التكامل ، من بناء القطع الفردية إلى المنتج بأكمله
• تذهب خطوط أنابيب النشر المستمر إلى أبعد من ذلك من خلال توثيق كيفية نشر منتج يمكن لعميلك استخدامه
• توثق ملفات إدارة التكوين عملية التثبيت والتكوين
• توثق مواصفات البنية التحتية كرمز البنية التحتية اللازمة (رسميًا تمامًا ، في الواقع!)
• تأتي الحاويات مع Dockerfile الخاصة بها والتي توثق كيفية إنشاء وتكوين خدمة مصغرة معينة

كل هذه المفاهيم الخيالية تفعل شيئًا واحدًا في الأساس: إنها تساعد أعضاء الفريق على التواصل بشكل أفضل من خلال توثيق العمليات. يمكن بعد ذلك تشغيل هذه العمليات يدويًا أو أتمتة. المهم هو أن كل صاحب مصلحة في المشروع قادر على متابعتها.

توثيق العمليات الخاصة بك على شكل كود له ميزة كبيرة على كتيبات التعليمات المعتادة. يمكن التحقق من الرمز ويتصرف بشكل تنبؤي. بالنظر إلى نفس المدخلات ، فإنها تنتج نفس المخرجات.

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

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

اتصالات DevOps: الطريقة الوحيدة لسد الفجوة بين التطوير والعمليات

في كتاب The Phoenix Project نشهد مشاكل مدير تمت ترقيته مؤخرًا مكلف بنشر مشروع كبير. بما أنه لا أحد يعرف ما يحدث ، فإن الجميع يكافحون الحرائق دون إحراز تقدم كبير. يذكر العنوان الفرعي للكتاب أنها قصة DevOps. أنا أتفق مع ذلك.

لكن المثير للاهتمام هو أنه طوال فترة الكتاب ، لم يتم تقديم أداة واحدة جديدة. هل يمكنك تحقيق حالة DevOps من خلال تحسين الاتصال فقط؟ لقد فعلها أبطال الكتاب ، لذلك هناك أمل لك أيضًا!

على الرغم من أن نهج الأبطال يمكن اعتباره "مدرسة قديمة" (باستخدام بطاقات ورقية فعلية بدلاً من نظام تتبع أخطاء مناسب) ، إلا أن الأمور تبدأ في التغيير للأفضل فقط بمجرد أن تبدأ جميع الأطراف المعنية في التحدث مع بعضها البعض.

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

هيكل فريق DevOps: من في الفريق؟

من الناحية المثالية ، يجب أن يكون لكل منتج فريق واحد فقط: فريق المنتج.

كنت ذات مرة في فريق تطوير حيث كان الهدف المشترك مع الفرق الأخرى غائبًا. أراد فريق التطوير دفع أكبر عدد ممكن من التغييرات. تم تكليف فريق التحقق بمنع إدخال العيوب. كان لديهم مديرين مختلفين وتم تقييمهم بشكل فردي.

النتائج؟ لعبت التنمية والتحقق من الصحة تنس الطاولة مع تقارير العيوب. عندما وجد التحقق من الصحة اختبارًا لن ينجح ، كان التطوير مهتمًا بإيجاد العيوب في كود الاختبار نفسه أكثر من محاولة جعل الكود الخاص به خالٍ من الأخطاء.

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

محاربة الهدر جهد مشترك

كانت عقلية الإنتاج الهزيل التي ألهمت The Manifesto for Agile Software Development (والتي قدمت لنا بدورها إلى DevOps) تدور حول مكافحة الهدر. نعني بالمخلفات كل ما ليس له صلة مباشرة بما يطلبه العميل. العمل المتراكم قيد التنفيذ هو إهدار. كل خطوة في العملية التي لا تؤدي بوضوح إلى الإفراج تعتبر مضيعة.

لكن لا يمكن رؤية النفايات إلا من مستوى عالٍ. في نطاق فريق واحد ، قد تبدو بعض الإجراءات ضرورية. ومع ذلك ، فمن منظور المنتج ، قد تكون عديمة الفائدة.

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

هل تريد التأكد من أن تطوير منتج ما فعال بقدر الإمكان؟ ادعُ شخصًا خارجيًا ليرى كيف تعمل. سيتمكن الشخص الذي ليس جزءًا من فريقك من طرح أسئلة ثاقبة واكتشاف مجالات جديدة للتحسين.

مبادئ DevOps: Keep Your CALM (S)

CALMS هو وصف دقيق للغاية لكيفية ممارسة DevOps:

• ج ـ التور
• أتمتة
• ل
• التخفيف م
• S هارينج

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

الشيء نفسه ينطبق على المشاركة. لا تتطلب مشاركة شيء أساسي مثل الطعام التواصل. ومع ذلك ، يمكن أيضًا اعتبار الإيماءة نفسها فعل تواصل. "أنا أهتم بك ، لذلك أشاركك." لا نريد قصر النطاق على التواصل اللفظي فقط.

ومع ذلك ، فإن تبادل الأفكار والأدوات يتطلب التواصل. كيف يجب أن نشاركهم؟ أين نضعهم؟ هل هي مفيدة لكل شخص في فريق أم لمجموعة أصغر فقط؟

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

DevOps تجعل الأعمال أقرب إلى التنمية

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

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

أدوات DevOps أولاً؟ فكر مرة اخرى

بالطبع ، هناك حاجة إلى جميع الأدوات لجعل ذلك ممكنًا.

ولكن لا يمكن لأي قدر من الأدوات أن يكون بديلاً عن الاتصالات الجيدة والتعاطف داخل الشركة. لقد لاحظت ذات مرة منتجًا حيث كانت عملية الإنشاء مملوكة لفريق واحد ، بينما كان الكود المقدم مملوكًا لفريق آخر.

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

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

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

أسرع طريقة لإنشاء DevOps؟ تواصل أفضل!

في المقدمة ، ذكرت السؤال الذي كثيرًا ما يسألني عنه العملاء: "هل يجب أن أذهب مع Docker أم يجب أن أقفز مباشرة إلى Kubernetes؟" بعد قراءة هذا المقال ، يمكنك أن ترى أنه من الأفضل الإجابة على مثل هذا السؤال بعد القيام ببعض الأعمال التحضيرية - بعقلية DevOps.

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

بمجرد توثيق جميع المتطلبات ، يصبح اتخاذ خيارات التكنولوجيا أسهل بكثير.

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