مرحبا يا هبر! ومرة أخرى أصبح أليكسي بريستافكو على اتصال.

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

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

في هذه المقالة سأحاول الإجابة على الأسئلة التالية:

• كيف تؤثر أساليب وعمليات التنمية على العمليات؟
• ما الذي يدفع كل جانب من جوانب الصراع؟
• ما هو السبب الجذري للخلاف؟

مرحبًا بك في القط!

ما هي التحديات التي تواجه الخدمات

سنتعرف على الأقسام بشكل أفضل ونبدأ بخدمة التشغيل (وهي أيضًا خدمة دعم). لماذا هذا الوحش الرهيب مطلوب ، ما هي المهمة التي يؤديها ، و "لمن" يعمل؟

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

هنا هو الحل لهذه المشكلة:

• إدارة الحوادث: استعادة وظيفة العمل أثناء وقوع حادث ؛
  
• إدارة المشكلات: معالجة الأسباب المحتملة للحوادث والحوادث ؛
  
• إدارة التكوين: جمع المعلومات وتحليل البرمجيات ومعلمات تشغيل البنية التحتية ؛
  
• إدارة التغيير: التقليل من مخاطر المشاكل والحوادث أثناء التغييرات.
  

كما أن دور خدمة التطوير أمر مفهوم - الإنشاء الأولي لخدمة تكنولوجيا المعلومات وإدخال وظائف جديدة فيها بناءً على طلب العميل.

بالتأكيد ، لديك بالفعل شكوك حول نقاط الاحتكاك للمطورين والدعم ، لأنه عندما تكون هناك تقاطعات بين المهام ، فهناك صراعات. ولكن لا تتسرع في الاستنتاجات. إن الجدل الأبدي بين المطورين والمدراء بعيد كل البعد عن مركز "المعارك".

أين تنمو الخلافات

إن "حرب" المبرمجين والإداريين ليست مواجهة للمصالح الإنسانية ، إنها مواجهة للخدمات.



تكمن المشكلة في أولويات ودوافع هذه الخدمات. يمكن وصف ذلك بشكله الأعم على النحو التالي:

• يريد فريق التطوير استخدام تقنية الحداثة الأولى (التطوير المهني ، الاهتمام) والقيام بالعمل بأسرع وقت ممكن (الدافع الخارجي).
  

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

في الوقت نفسه ، من المهم أن نفهم أنه ليس فقط المطورين "رأوا" وظائف جديدة وليس المسؤولون الحصريون دائمًا هم الذين يرفعون السقوط.

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

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

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

• تطوير → الترميز ؛
  
• دعم → إدارة خدمات التطبيقات.
  

يؤدي تحريف هيكل التبعية على أساس احترافي (وليس على أساس وظيفي) دائمًا إلى الصراعات. كقاعدة عامة ، يعمل المسؤولون والمبرمجون في فرق مختلفة تمامًا ، وأحيانًا أقسام ، ويتم تحفيزهم كعملية وتطوير ، على التوالي.

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

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

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



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

دعونا نلقي نظرة على جميع أطراف الصراع:



بالطبع ، هذا ليس سوى الجزء الأكثر شيوعًا من المتطلبات الوظيفية والتشغيلية.

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

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

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

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

عمليات التطوير

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

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

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

لنبدأ مع الكلاسيكيات: نماذج الشلال.

شلال

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

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

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

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

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

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

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

رشيقة

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

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

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

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

- فازيا ، هل تفهمني؟
- حسنا ، مثل نعم ، أخي.

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

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

سكروم

سكروم هي واحدة من المحاولات الأولى لتكييف الشلال مع إيديولوجية الظاهرة الرشيقة.
الملامح الرئيسية لل سكروم:

• اعمل في سباقات قصيرة. لا يتم تحرير تكوين العدو بعد بدايته ؛
  
• التخطيط بوضع قصص المستخدم الفردية في سجل رغبة العدو. على صاحب المشروع - اختيار من "سجل المشروع" ؛
  
• يتم تمثيل مصالح العميل من قبل صاحب المشروع (مالك المنتج) ؛
  
• يتكون فريق التطوير من متخصصين من مختلف الملفات الشخصية: المبرمجين والمطورين والمهندسين المعماريين والمحللين. الفريق مسؤول عن النتيجة ككل ؛
  
• نستبدل الوثائق والمراسلات بالمناقشات اليومية للمشروع من قبل الفريق بأكمله.
  

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

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

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

للتشغيل العادي ، يجب أن يكون التشغيل:

• المشاركة في اجتماعات SCRUM ؛
  
• إدراك مستمر لأوضاع عمل التطوير ؛
  
• معرفة خطط التطوير وحالات الإصدار.
  

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

كانبان

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

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

عادة ما تسير Kanban جنبًا إلى جنب مع عمليات CI / CD. لا توجد عدسات سريعة هنا ، يتم تسليم المهام باستمرار لأنها جاهزة ، وهناك قيود صارمة على حجم هذه المهام. وبسبب هذا ، لا يتم تسليم الوظائف المعقدة في شكل متكامل تقريبًا ، نظرًا لأنها لا تتناسب مع حجم المهمة.

في مثل هذه الظروف ، يصبح توثيق النظام قديمًا حقًا قبل كتابته ، ويفقد كل معنى ، لأنه من المستحيل إصلاح بعض حالات النظام المُنتَج (أي المُنتَج ، ولكن غير المطوّر) الذي سيكون صحيحًا فيه.

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

إن التنبؤات وضمان التشغيل المستمر هما أساس تنفيذ اتفاقية مستوى الخدمة.

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

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

ديفوبس

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

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

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

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

من الناحية العملية ، غالبًا ما صادفت عمليتي تنفيذ:

• يتم الحفاظ على فريق مدراء العمليات والمشاركة في الإنتاجية.
  

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

• الشيء نفسه ، ولكن يتم إلغاء فريق العمليات بروح مبدأ "لا يوجد رجل - لا توجد مشكلة".
  

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

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

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

بدلاً من الإخراج

إذن ماذا تفعل وكيف تكون؟

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

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

بالتأكيد شاركتم جميعًا بطريقة أو بأخرى في المواقف والعمليات المذكورة أعلاه. شارك تجربتك في التعليقات!