🏏 👽 🏸 سبع نماذج التحول DevOps 💃🏼 🧔🏻 📞

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

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

جون ويليس- أحد آباء DevOps. خلف جون - عشرات السنين من العمل مع عدد كبير من الشركات. في الآونة الأخيرة ، بدأ جون يلاحظ لنفسه أنماطًا محددة تحدث في العمل مع كل منها. باستخدام هذه النماذج ، يوجه جون الشركات على المسار الحقيقي لتحويل DevOps. اقرأ المزيد عن هذه النماذج في ترجمة تقريره من مؤتمر DevOops 2018.

نبذة عن المتحدث:

على مدار 35 عامًا في إدارة تكنولوجيا المعلومات ، شارك في إنشاء سلف OpenCloud في Canonical ، وشارك في 10 شركات ناشئة ، تم بيع اثنتين منها من قبل Dell و Docker. يشغل حاليًا منصب نائب رئيس DevOps والممارسات الرقمية في SJ Technologies.

التالي هو السرد نيابة عن جون.

اسمي جون ويليس وأسهل طريقة للعثور علي على Twitter هي botchagalupe . لدي نفس الاسم المستعار على Gmail و GitHub. وعلى هذا الرابط يمكنك العثور على مقاطع فيديو لتقاريري وعروضي التقديمية لهم.

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

ما هو DevOps؟

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

الآن لدينا الكثير من البيانات ، خمس سنوات من البحث الأكاديمي ، تم التحقق من النظريات على نطاق صناعي. تخبرنا هذه الدراسات ما يلي: إذا قمت بدمج بعض الأنماط السلوكية في الثقافة التنظيمية ، يمكنك الحصول على تسارع 2000 مرة. يتوافق هذا التسارع مع نفس التحسن في الاستقرار. هذا قياس كمي للفوائد التي يمكن أن تجلبها DevOps لأي شركة. منذ عامين تحدثت عن DevOps إلى الرئيس التنفيذي لشركة Fortune 5000. عندما كنت أستعد للعرض التقديمي ، كنت متوترة للغاية لأنني كنت بحاجة إلى تحديد سنوات خبرتي العديدة في 5 دقائق.

انتهى بي الأمر بإعطاء التعريف التالي لـ DevOps: هذه مجموعة من الممارسات والأنماط التي تجعل من الممكن تحويل رأس المال البشري إلى رأس مال تنظيمي عالي الإنتاجية. مثال على ذلك ، كيف كانت تويوتا تعمل منذ 50 أو 60 عامًا الماضية.

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

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

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

ثقافة سيئة يأكل نهج الإفطار الجيد

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

لحل هذه المشكلة الرئيسية ، يجب عليك اتخاذ الخطوات التالية:

جعل كل العمل مرئيًا: اجعل كل الأعمال مرئية. ليس بمعنى أنه يجب عرضه على أي شاشة ، ولكن بمعنى أنه يجب ملاحظته.
Consolidate Work Management Systems: . «» 9 10 . «Phoenix Project» - , , - . «» . c .
Theory of Constraints Methodology: .
Collaboration hacks: .
Toyota Kata (Coaching Kata): Toyota Kata . , .
Market Oriented Organization: .
Shift-left auditors: .

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

(للحصول على توضيح منفصل ، انظر الرابط )

نهجي مبني على عمل وليام شنايدر ، بديل Reengineering البديل) يعتمد النهج على فكرة أن أي منظمة يمكن أن تتحلل إلى أربعة مربعات. هذا المخطط بالنسبة لي عادة ما يكون نتيجة للعمل مع تلك المئات من المخططات الأخرى التي تنشأ عند تحليل منظمة. لنفترض أن لدينا منظمة ذات مستوى عالٍ من التحكم ، ولكن بكفاءة منخفضة. هذا خيار غير مرغوب فيه للغاية: عندما يمشي الجميع على طول الخط ، ولكن لا أحد يعرف ماذا يفعل.

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

(يمكنك رؤية هذا الرسم التوضيحي بشكل منفصل عن الرابط )

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

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

(بشكل منفصل ، يمكن عرض هذا الرسم التوضيحي على الرابط )

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

(يمكنك مشاهدة هذا الرسم التوضيحي بشكل منفصل عن الرابط )

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

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

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

(بشكل منفصل ، يمكن عرض هذا الرسم التوضيحي على الرابط )

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

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

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

1. جعل العمل مرئيًا: اجعل العمل مرئيًا.

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

الكثير من العمل قيد المعالجة (WIP)
تبعيات غير معروفة
عمل غير مخطط له
تضارب الأولويات
العمل المهملة

هذا تحليل قيم للغاية ، والكتاب رائع ، لكن كل هذه النصائح عديمة الفائدة إذا كانت 50٪ فقط من البيانات مرئية. يمكنك تطبيق الأساليب التي اقترحتها دومينيكا إذا تم تحقيق الدقة فوق 90٪. أنا أتحدث عن المواقف التي يكلف فيها الرئيس المرؤوس مهمة تستغرق 15 دقيقة ، وتستغرقه ثلاثة أيام ؛ لكن الرئيس لا يعرف حقًا أن هذا المرؤوس يعتمد على أربعة أو خمسة أشخاص آخرين.

مشروع فينيكس هو قصة رائعة عن مشروع تأخر ثلاث سنوات. أحد الأبطال مهدد بالفصل بسبب هذا ، ويلتقي بشخصية أخرى يتم تقديمها على أنها نوع من سقراط. إنه يساعد على معرفة الخطأ الذي حدث بالضبط. اتضح أن الشركة لديها مسؤول نظام واحد ، واسمه برنت ، وكل العمل يمر بطريقة ما. في أحد الاجتماعات ، سُئل أحد المرؤوسين: لماذا تستغرق كل مهمة تستغرق نصف ساعة أسبوعًا؟ ورداً على ذلك ، يتبع عرض مبسط للغاية لنظرية الاصطفاف وقانون ليتل ، وفي هذا المعرض تبين أنه عند 90٪ من العمالة ، فإن كل ساعة عمل تستغرق 9 ساعات. يجب إرسال كل مهمة إلى سبعة أشخاص آخرين ، لذلك تتحول هذه الساعة إلى 63 ساعة ، 7 مرات 9. أقول هذا ،لاستخدام قانون Little أو أي نظرية قائمة انتظار معقدة ، يجب أن يكون لديك بيانات على الأقل.

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

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

2. توحيد نظم إدارة العمل: إدارة المهام

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

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

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

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

خدمات خطوط الأنابيب

ينطبق هذا مرة أخرى فقط على الشركات الكبيرة. إذا كنت شركة جديدة في مجال جديد ، فقم بتجميع أكمامك والعمل مع Travis CI أو CircleCI. أما بالنسبة لشركات Fortune 5000 ، فإن الحالة التي حدثت مع البنك الذي عملت فيه كانت إرشادية. لقد أتوا إليهم من Google ، وتم عرض مخططاتهم بأنظمة IBM القديمة. سأل الرجال من جوجل مع سوء فهم - أين هو مصدر شفرة لهذا؟ ولا يوجد رمز مصدر ، ولا حتى واجهة المستخدم الرسومية. هذه هي الحقيقة التي يجب على المنظمات الكبيرة العمل معها: السجلات المصرفية البالغة من العمر 40 عامًا على حاسب مركزي قديم. يستخدم أحد عملائي حاويات Kubernetes مع أنماط قواطع دوائر ، بالإضافة إلى قرد الفوضى ، وكلها لـ KeyBank. لكن هذه الحاويات تتصل في النهاية بتطبيق COBOL.

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

3. نظرية القيود: نظرية القيود

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

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

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

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

4. قرصنة التعاون: قرصنة التعاون

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

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

5. تدريب كاتا

كما حذرت بالفعل في البداية ، اليوم لن أتحدث عنه. إذا كنت مهتمًا ، يمكنك مشاهدة بعض عروضي التقديمية .

هناك أيضًا تقرير جيد حول هذا الموضوع من Mike Rother:

6. موجه نحو السوق: منظمة موجهة نحو السوق

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

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

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

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

7. المدققون من اليسار إلى اليسار: التدقيق في المراحل الأولى من الدورة. الامتثال لقواعد السلامة

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

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

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

بحسب التقريرتم إنشاؤها بواسطة Sonatype في 2018 ، كان هناك 87 مليار طلب تنزيل OSS في 2017.

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

مثال على مثل هذا التسلسل:

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

ولا يوجد سبب يمنعنا من اتباع نفس النهج تجاه الأمن.

مجموع

في الختام ، سأقدم بعض النصائح لـ DevSecOps. تحتاج إلى تضمين المراجعين في عملية إنشاء أنظمتك ، وقضاء الوقت في تعليمهم. نحن بحاجة للعمل مع مراجعي الحسابات. علاوة على ذلك ، من الضروري شن معركة قاسية للغاية ضد الإيجابيات الكاذبة. حتى مع أغلى أداة لفحص الثغرات الأمنية ، قد ينتهي بك الأمر إلى خلق عادات سيئة للغاية لمطوريك إذا كنت لا تعرف نسبة الإشارة إلى الضوضاء. سيتم تحميل المطورين مثقلة بالأحداث ، وسوف ببساطة حذفها. إذا سمعت عن القصة مع Equifax ، فهذا ما حدث هناك ، تم تجاهل إشارة أعلى مستوى خطر هناك. بالإضافة إلى ذلك ، يجب شرح نقاط الضعف بحيث يكون من الواضح كيف تؤثر على الأعمال. على سبيل المثال ، يمكننا القول أن هذه هي نفس نقطة الضعف في قصة Equifax. الثغرات الأمنيةتحتاج إلى مراعاة نفس المشاكل الأخرى مع البرنامج ، أي أنها تحتاج إلى تضمينها في عملية DevOps الشاملة. تحتاج للعمل معهم من خلال Jira ، Kanban ، إلخ. لا يجب على المطورين أن يعتقدوا أن شخصًا آخر سيفعل ذلك ؛ بل على العكس ، يجب على الجميع القيام بذلك. أخيرًا ، أنت بحاجة إلى إنفاق الطاقة على تعليم الناس.

روابط مفيدة

إليك بعض المحادثات من مؤتمر DevOops التي قد تجدها مفيدة:

سيرجي بيردنيكوف ، أرتيوم كاليتشكين - قصة نجاح ، أو "Dev + DevOps + Ops" ( فيديو ، نسخة من التقرير )
Baruch Sadogursky ، Leonid Igolnik - DevOps على مقياس: المأساة اليونانية في ثلاثة أعمال ( فيديو ، نسخة من التقرير )
ألكسندر تيتوف ، كيريل Tolkachev - DevOps ، المهندسين والمجتمع
Timothy Lister - الشخصيات والمجتمع والثقافة: عوامل مهمة للازدهار

ألق نظرة على برنامج DevOops 2020 موسكو - هناك أيضًا الكثير من الأشياء المثيرة للاهتمام هناك.

سبع نماذج التحول DevOps