لقد كان السؤال "كيفية تنفيذ عمليات التطوير" موجودًا منذ سنوات، ولكن لا يوجد الكثير من المواد الجيدة. في بعض الأحيان تقع ضحية لإعلانات المستشارين غير الأذكياء الذين يحتاجون إلى بيع وقتهم، مهما كانت الطريقة. في بعض الأحيان تكون هذه كلمات غامضة وعامة للغاية حول كيفية حرث سفن الشركات العملاقة مساحات الكون. السؤال الذي يطرح نفسه: ما الذي يهمنا في هذا؟ عزيزي الكاتب، هل يمكنك صياغة أفكارك بوضوح في قائمة؟
كل هذا ينبع من حقيقة أنه لم يتراكم الكثير من الممارسة الحقيقية وفهم نتائج التحولات في ثقافة الشركة. التغيرات في الثقافة هي أمور طويلة الأمد، لن تظهر نتائجها في أسبوع أو شهر. نحن بحاجة إلى شخص كبير بما يكفي ليرى كيف تم بناء الشركات وفشلها على مر السنين.
جون ويليس - أحد آباء DevOps. يتمتع جون بعقود من الخبرة في العمل مع عدد كبير من الشركات. في الآونة الأخيرة، بدأ جون في ملاحظة أنماط محددة تحدث عند العمل مع كل واحد منهم. باستخدام هذه النماذج الأولية، يرشد جون الشركات على المسار الحقيقي للتحول في DevOps. اقرأ المزيد عن هذه النماذج الأولية في ترجمة تقريره من مؤتمر DevOops 2018.
حول المتحدث:
أكثر من 35 عامًا في إدارة تكنولوجيا المعلومات، وشارك في إنشاء النسخة السابقة من OpenCloud في Canonical، وشارك في 10 شركات ناشئة، تم بيع اثنتين منها إلى Dell وDocker. يشغل حاليًا منصب نائب رئيس DevOps والممارسات الرقمية في SJ Technologies.
التالي هو القصة من وجهة نظر جون.
اسمي جون ويليس وأسهل مكان للعثور علي هو تويتر، . لدي نفس الاسم المستعار على Gmail وGitHub. أ يمكنك العثور على تسجيلات فيديو لتقاريري وعروضي التقديمية لهم.
لقد عقدت العديد من الاجتماعات مع مديري تكنولوجيا المعلومات في العديد من الشركات الكبرى. غالبًا ما يشكون من أنهم لا يفهمون ما هو DevOps، وكل من يحاول شرحه لهم يتحدث عن شيء مختلف. الشكوى الشائعة الأخرى هي أن DevOps لا يعمل، على الرغم من أنه يبدو أن المديرين يفعلون كل شيء كما هو موضح لهم. نحن نتحدث عن الشركات الكبيرة التي يزيد عمرها عن مائة عام. بعد التحدث معهم، توصلت إلى استنتاج مفاده أنه بالنسبة للعديد من المشكلات، ليست التكنولوجيا العالية هي الأنسب، بل الحلول ذات التقنية المنخفضة نسبيًا. لأسابيع تحدثت للتو مع أشخاص من أقسام مختلفة. ما تراه في الصورة الأولى في المنشور هو مشروعي الأخير، وهذا هو شكل الغرفة بعد ثلاثة أيام من العمل.
ما هو DevOps؟
في الواقع، إذا سألت 10 أشخاص مختلفين، فسوف يعطون 10 إجابات مختلفة. ولكن هذا هو الشيء المثير للاهتمام: جميع هذه الإجابات العشرة ستكون صحيحة. لا توجد إجابة خاطئة هنا. لقد كنت متعمقًا جدًا في DevOps، لمدة 10 سنوات تقريبًا، وكنت أول أمريكي في DevOpsDay الأول. لن أقول إنني أكثر ذكاءً من جميع المشاركين في DevOps، ولكن لا يكاد يوجد أي شخص بذل هذا القدر من الجهد في ذلك. أعتقد أن DevOps يحدث عندما يجتمع رأس المال البشري والتكنولوجيا معًا. كثيرا ما ننسى البعد الإنساني، رغم أننا نتحدث كثيرا عن الثقافات بمختلف أنواعها.
الآن لدينا الكثير من البيانات، خمس سنوات من البحث الأكاديمي، واختبار النظريات على نطاق صناعي. ما تخبرنا به هذه الدراسات هو أنه إذا قمت بدمج بعض الأنماط السلوكية في الثقافة التنظيمية، فيمكنك تحقيق سرعة تصل إلى 2000 مرة. ويقابل هذا التسارع تحسنًا متساويًا في الاستقرار. يعد هذا قياسًا كميًا للفوائد التي يمكن أن تقدمها DevOps لأي شركة. قبل عامين، كنت أتحدث عن DevOps إلى الرئيس التنفيذي لشركة Fortune 5000. عندما كنت أستعد للعرض التقديمي، كنت متوترًا للغاية لأنه كان علي تلخيص سنوات خبرتي في 5 دقائق.
وفي النهاية أعطيت ما يلي تعريف DevOps: هو مجموعة من الممارسات والأنماط التي تمكن من تحويل رأس المال البشري إلى رأسمال تنظيمي عالي الأداء. ومن الأمثلة على ذلك الطريقة التي عملت بها شركة تويوتا طوال الخمسين أو الستين سنة الماضية.
(فيما يلي، لا يتم توفير هذه المخططات كمواد مرجعية، ولكن كرسوم توضيحية. وسيختلف محتواها لكل شركة جديدة. ومع ذلك، يمكن عرض الصورة بشكل منفصل وتكبيرها
واحدة من أنجح هذه الممارسات هي رسم الخرائط تيار القيمة. تمت كتابة العديد من الكتب الجيدة حول هذا الموضوع، وأنجحها كارين مارتن. لكن خلال العام الماضي، توصلت إلى استنتاج مفاده أنه حتى هذا النهج يعتبر عالي التقنية للغاية. بالتأكيد له العديد من المزايا ولقد استخدمته كثيرًا. ولكن عندما يسألك الرئيس التنفيذي عن سبب عدم قدرة شركته على التحول إلى خطوط جديدة، فمن السابق لأوانه الحديث عن رسم خرائط تدفق القيمة. هناك العديد من الأسئلة الأساسية التي يجب الإجابة عليها أولاً.
أعتقد أن الخطأ الذي يرتكبه العديد من زملائي هو أنهم ببساطة يعطون الشركة دليلاً من خمس نقاط ثم يعودون بعد ستة أشهر ويرون ما حدث. حتى المخطط الجيد مثل رسم خرائط تدفق القيمة، على سبيل المثال، يحتوي على نقاط عمياء. بعد مئات المقابلات مع مديري الشركات المختلفة، قمت بتطوير نمط معين يسمح لنا بتقسيم المشكلة إلى مكوناتها، والآن سنناقش كل عنصر من هذه المكونات بالترتيب. قبل تطبيق أي حلول تكنولوجية، أستخدم هذا النمط، ونتيجة لذلك، يتم تغطية جميع جدراني بالرسوم البيانية. كنت أعمل مؤخرًا مع صندوق استثمار مشترك وانتهى بي الأمر بـ 100-150 من هذه المخططات.
الثقافة السيئة تأكل الأساليب الجيدة لتناول الإفطار
الفكرة الرئيسية هي كما يلي: لن يساعد أي قدر من الأساليب Lean وAgile وSAFE وDevOps إذا كانت ثقافة المنظمة نفسها سيئة. إنه مثل الغوص إلى الأعماق بدون معدات الغطس أو العمل بدون أشعة سينية. وبعبارة أخرى، لإعادة صياغة ما قاله دراكر وديمينج: إن الثقافة التنظيمية السيئة سوف تبتلع أي نظام جيد دون أن تخنقه.
لحل هذه المشكلة الرئيسية، عليك اتباع الخطوات التالية:
- اجعل كل العمل مرئيًا: تحتاج إلى جعل كل العمل مرئيًا. ليس بمعنى أنه يجب بالضرورة أن يتم عرضه على شاشة ما، ولكن بمعنى أنه يجب أن يكون قابلاً للملاحظة.
- أنظمة إدارة العمل الموحدة: يجب توحيد أنظمة الإدارة. وفي مشكلة المعرفة "القبلية" والمعرفة المؤسسية، في 9 حالات من أصل 10، يكون عنق الزجاجة هو الأشخاص. في هذا الكتاب كانت المشكلة مع شخص واحد، برنت، الذي تسبب في تأخير المشروع لمدة ثلاث سنوات عن الموعد المحدد. وأنا أواجه هؤلاء "البرينتس" في كل مكان. لحل هذه الاختناقات، أستخدم العنصرين التاليين في قائمتنا.
- نظرية منهجية القيود: نظرية القيود.
- هاكات التعاون: خارقة التعاون.
- تويوتا كاتا (): لن أتحدث كثيرًا عن تويوتا كاتا. إذا كنت مهتما، على جيثب الخاص بي في كل واحد من هذه المواضيع تقريبًا.
- منظمة موجهة نحو السوق: منظمة موجهة نحو السوق.
- مدققو التحول الأيسر: التدقيق في المراحل المبكرة من الدورة.
أبدأ العمل مع إحدى المنظمات بكل بساطة: أذهب إلى الشركة وأتحدث مع الموظفين. كما ترون، لا توجد تكنولوجيا عالية. كل ما تحتاجه هو شيء للكتابة عليه. أقوم بجمع عدة فرق في غرفة واحدة وتحليل ما يقولونه لي من منظور النماذج السبعة الخاصة بي. ثم أعطيهم علامة وأطلب منهم أن يكتبوا على السبورة كل ما قالوا بصوت عالٍ حتى الآن. عادة في هذا النوع من الاجتماعات يوجد شخص واحد يكتب كل شيء، وفي أحسن الأحوال يمكنه كتابة 7٪ من المناقشة. ومن خلال طريقتي، يمكن رفع هذا الرقم إلى حوالي 10%.
(يمكن مشاهدة هذا الرسم التوضيحي بشكل منفصل )
يعتمد نهجي على عمل ويليام شنايدر. ). يعتمد هذا النهج على فكرة أنه يمكن تقسيم أي منظمة إلى أربعة مربعات. هذا المخطط بالنسبة لي عادة ما يكون نتيجة العمل مع مئات المخططات الأخرى التي تنشأ عند تحليل المنظمة. لنفترض أن لدينا منظمة تتمتع بمستوى عالٍ من السيطرة، ولكن بكفاءة منخفضة. هذا خيار غير مرغوب فيه على الإطلاق: عندما يلتزم الجميع بالخط، لكن لا أحد يعرف ماذا يفعل.
الخيار الأفضل إلى حد ما هو الخيار الذي يتمتع بمستوى عالٍ من السيطرة والكفاءة. إذا كانت هذه الشركة مربحة، فربما لا تحتاج إلى DevOps. من المثير للاهتمام العمل مع شركة تتمتع بمستوى عالٍ من السيطرة، وكفاءة وتعاون منخفضين، ولكن في نفس الوقت تتمتع بمستوى عالٍ من الثقافة (الزراعة). وهذا يعني أن الشركة لديها الكثير من الأشخاص الذين يحبون العمل هناك وأن معدل دوران العمالة منخفض.
(يمكن مشاهدة هذا الرسم التوضيحي بشكل منفصل )
يبدو لي أن الأساليب ذات المبادئ التوجيهية الصارمة تنتهي في النهاية إلى إعاقة الوصول إلى الحقيقة. في رسم خرائط تدفق القيمة على وجه الخصوص، هناك العديد من القواعد المتعلقة بكيفية تنظيم المعلومات. في المراحل الأولى من العمل، والتي أتحدث عنها الآن، لا أحد يحتاج إلى هذه القواعد. إذا وصف شخص يحمل علامة في يديه الوضع الحقيقي في الشركة على السبورة، فهذه هي أفضل طريقة لفهم الوضع. مثل هذه المعلومات لا تصل إلى المديرين. في هذه اللحظة من الغباء مقاطعة الشخص والقول إنه رسم نوعًا من السهم بشكل غير صحيح. في هذه المرحلة، من الأفضل استخدام قواعد بسيطة، على سبيل المثال: يمكن إنشاء تجريد متعدد المستويات ببساطة باستخدام علامات متعددة الألوان.
وأكرر، لا توجد تكنولوجيا عالية. العلامة السوداء تصور الحقيقة الموضوعية لكيفية عمل كل شيء. باستخدام علامة حمراء، يحدد الأشخاص ما لا يعجبهم في الوضع الحالي. من المهم أن يكتبوا هذا، وليس أنا. عندما أذهب إلى مدير تكنولوجيا المعلومات بعد الاجتماع، لا أقدم قائمة بعشرة أشياء تحتاج إلى إصلاح. أسعى جاهداً لإيجاد روابط بين ما يقوله الأشخاص في الشركة والأنماط المثبتة الموجودة. وأخيرًا، تقترح العلامة الزرقاء الحلول الممكنة للمشكلة.
(يمكن مشاهدة هذا الرسم التوضيحي بشكل منفصل )
ويرد الآن مثال على هذا النهج أعلاه. في بداية هذا العام عملت مع أحد البنوك. كان رجال الأمن هناك مقتنعين بأنه لا ينبغي عليهم الحضور لمراجعة التصميم والمتطلبات.
(يمكن مشاهدة هذا الرسم التوضيحي بشكل منفصل )
وبعد ذلك تحدثنا إلى أشخاص من أقسام أخرى، واتضح أنه منذ حوالي 8 سنوات، قام مطورو البرمجيات بطرد العاملين في مجال الأمن لأنهم كانوا يبطئون العمل. ثم تحول الأمر إلى حظر، وهو أمر مفروغ منه. رغم أنه في الواقع لم يكن هناك حظر.
استمر اجتماعنا بطريقة مربكة للغاية: لمدة ثلاث ساعات تقريبًا، لم تتمكن خمسة فرق مختلفة من شرح ما كان يحدث بين الكود والتجميع. ويبدو أن هذا هو أبسط شيء. يفترض معظم مستشاري DevOps مقدمًا أن الجميع يعرف ذلك بالفعل.
ثم عاد فجأة الشخص المسؤول عن حوكمة تكنولوجيا المعلومات، الذي ظل صامتًا لمدة أربع ساعات، إلى الحياة عندما وصلنا إلى موضوعه، وشغلنا لفترة طويلة جدًا. وفي النهاية سألته عن رأيه في اللقاء، ولن أنسى إجابته أبدًا. وقال: "كنت أعتقد أن مصرفنا لديه طريقتان فقط لتقديم البرمجيات، لكنني الآن أعرف أن هناك خمسة منها، ولم أكن أعرف حتى عن ثلاث منها".
(يمكن مشاهدة هذا الرسم التوضيحي بشكل منفصل )
آخر اجتماع في هذا البنك كان مع فريق برامج الاستثمار. لقد اتضح معها أن كتابة المخططات باستخدام علامة على قطعة من الورق أفضل من الكتابة على السبورة، وحتى أفضل من السبورة الذكية.
الصور التي تراها هي ما كانت تبدو عليه قاعة المؤتمرات بالفندق في اليوم الرابع من اجتماعنا. واستخدمنا هذه المخططات للبحث عن الأنماط، أي النماذج الأولية.
لذلك، أطرح أسئلة على العمال، فيكتبون الإجابات بأقلام تحديد من ثلاثة ألوان (الأسود والأحمر والأزرق). أقوم بتحليل إجاباتهم بحثًا عن النماذج الأولية. الآن دعونا نناقش جميع النماذج الأولية بالترتيب.
1. اجعل كل العمل مرئيًا: اجعل العمل مرئيًا
معظم الشركات التي أعمل معها لديها نسبة عالية جدًا من الأعمال غير المعروفة. على سبيل المثال، يحدث هذا عندما يأتي موظف إلى موظف آخر ويطلب ببساطة القيام بشيء ما. في المنظمات الكبيرة، قد يكون هناك 60٪ من العمل غير المخطط له. وما يصل إلى 40٪ من العمل غير موثق بأي شكل من الأشكال. لو كانت شركة بوينج، فلن أركب طائرتهم مرة أخرى في حياتي. إذا تم توثيق نصف العمل فقط، فلا يُعرف ما إذا كان هذا العمل يتم بشكل صحيح أم لا. جميع الأساليب الأخرى غير مجدية - لا معنى لمحاولة أتمتة أي شيء، لأن 50٪ المعروفة قد تكون الجزء الأكثر تماسكا ووضوحا من العمل، والذي لن تعطي أتمتة نتائج رائعة، وكل الأسوأ الأشياء في النصف غير المرئي. في غياب التوثيق، من المستحيل العثور على جميع أنواع الاختراقات والأعمال المخفية، وعدم العثور على الاختناقات، تلك "Brents" التي تحدثت عنها بالفعل. هناك كتاب رائع من تأليف دومينيكا ديجرانديس . هي تكشف خمسة "تسريبات زمنية" مختلفة (لصوص الزمن):
- الكثير من العمل قيد المعالجة (WIP)
- تبعيات غير معروفة
- العمل غير المخطط له
- أولويات متضاربة
- العمل المهمل
هذا تحليل قيم للغاية والكتاب رائع، لكن كل هذه النصائح لا فائدة منها إذا كان 50% فقط من البيانات مرئية. يمكن استخدام الطرق التي تقترحها دومينيكا إذا تم تحقيق دقة تزيد عن 90%. أنا أتحدث عن المواقف التي يكلف فيها الرئيس مرؤوسه بمهمة مدتها 15 دقيقة، لكنها تستغرق منه ثلاثة أيام؛ لكن الرئيس لا يعرف حقًا أن هذا المرؤوس يعتمد على أربعة أو خمسة أشخاص آخرين.
مشروع فينيكس هو قصة رائعة عن مشروع تأخر ثلاث سنوات. وتواجه إحدى الشخصيات الطرد بسبب ذلك، ويلتقي بشخصية أخرى يتم تقديمها على أنها نوع من سقراط. إنه يساعد على معرفة الخطأ الذي حدث بالضبط. اتضح أن الشركة لديها مسؤول نظام واحد اسمه برنت، وكل العمل يمر عبره بطريقة أو بأخرى. في أحد الاجتماعات سُئل أحد المرؤوسين: لماذا تستغرق كل مهمة مدتها نصف ساعة أسبوعًا؟ الجواب هو عرض مبسط للغاية لنظرية الطوابير وقانون ليتل، وفي هذا العرض يتبين أنه عند نسبة الإشغال 90%، تستغرق كل ساعة عمل 9 ساعات. يجب إرسال كل مهمة إلى سبعة أشخاص آخرين، بحيث تصبح تلك الساعة 63 ساعة، 7 ضرب 9. ما أقوله هو أنه من أجل استخدام قانون ليتل أو أي نظرية انتظار معقدة، تحتاج على الأقل إلى الحصول على البيانات.
لذلك عندما أتحدث عن الرؤية، لا أقصد أن كل شيء موجود على الشاشة، ولكن على الأقل لديك بيانات. عندما يفعلون ذلك، غالبًا ما يتبين أن هناك قدرًا كبيرًا جدًا من العمل غير المخطط له يتم إرساله بطريقة ما إلى برنت عندما لا تكون هناك حاجة إليه. وبرنت رجل عظيم، لن يقول لا أبدًا، لكنه لا يخبر أحدًا كيف يؤدي وظيفته.
عندما يكون العمل مرئيًا، يمكن تصنيف البيانات بدقة (وهذا ما تفعله دومينيكا في الصورة)، ويمكن تطبيق تجريد التسريبات الزمنية الخمس، ويمكن تطبيق الأتمتة.
2. توحيد أنظمة إدارة العمل: إدارة المهام
النماذج الأولية التي أتحدث عنها هي نوع من الهرم. إذا تم تنفيذ الأول بشكل صحيح، فإن الثاني هو بالفعل نوع من الوظيفة الإضافية. العديد من هذه الأنظمة لا تناسب الشركات الناشئة، ويجب وضعها في الاعتبار بالنسبة للشركات الكبرى مثل Fortune 5000. آخر شركة عملت بها كان لديها 10 أنظمة للتذاكر. كان لدى أحد الفرق علاج، وآخر كتب نوعًا ما من نظامه الخاص، والثالث استخدم جيرا، والبعض الآخر اكتفى بالبريد الإلكتروني. تنشأ نفس المشكلة إذا كان لدى الشركة 30 خط أنابيب مختلف، لكن ليس لدي الوقت لمناقشة كل هذه الحالات.
أناقش مع الناس بالضبط كيفية إنشاء التذاكر، وماذا يحدث لهم بعد ذلك، وكيف يتم التحايل عليها. الشيء الأكثر إثارة للاهتمام هو أن الأشخاص في اجتماعاتنا يتحدثون بصدق تام. سألت عن عدد الأشخاص الذين وضعوا "تأثير بسيط/بدون تأثير" على التذاكر التي يجب أن يكون لها "تأثير كبير" بالفعل. اتضح أن الجميع تقريبًا يفعلون هذا. أنا لا أشارك في الإدانة وأحاول بكل طريقة ممكنة عدم تحديد هوية الأشخاص. عندما يعترفون لي بشيء ما بصدق، لا أفصح عن هذا الشخص. ولكن عندما يتجاوز الجميع النظام تقريبًا، فهذا يعني أن كل الإجراءات الأمنية هي في الأساس مجرد تزيين للنوافذ. ولذلك، لا يمكن استخلاص أي استنتاجات من بيانات هذا النظام.
لحل مشكلة التذاكر، عليك اختيار نظام رئيسي واحد. إذا كنت تستخدم جيرا، احتفظ به جيرا. إذا كان هناك أي بديل، فليكن هو الوحيد. خلاصة القول هي أنه ينبغي النظر إلى التذاكر كخطوة أخرى في عملية التطوير. يجب أن يكون لكل إجراء تذكرة، والتي يجب أن تتدفق عبر سير عمل التطوير. يتم إرسال التذاكر إلى الفريق، الذي يقوم بنشرها على لوحة العمل ومن ثم يتحمل المسؤولية عنها.
وينطبق هذا على جميع الإدارات، بما في ذلك البنية التحتية والعمليات. في هذه الحالة، من الممكن تكوين فكرة معقولة على الأقل عن الوضع. بمجرد إنشاء هذه العملية، يصبح من السهل فجأة تحديد المسؤول عن كل طلب. لأننا الآن لا نتلقى 50%، بل 98% من الخدمات الجديدة. إذا نجحت هذه العملية الأساسية، فستتحسن الدقة في جميع أنحاء النظام.
خط أنابيب الخدمات
وهذا مرة أخرى ينطبق فقط على الشركات الكبيرة. إذا كنت شركة جديدة في مجال جديد، فشمر عن سواعدك واعمل مع Travis CI أو CircleCI. عندما يتعلق الأمر بشركات فورتشن 5000، فقد حدث مثال على ذلك في البنك الذي كنت أعمل فيه. جاءت إليهم شركة Google وعرضت عليهم مخططات لأنظمة IBM القديمة. سأل الرجال من Google في حيرة من أمرهم - أين يوجد الكود المصدري لهذا؟ ولكن لا يوجد كود مصدر، ولا حتى واجهة المستخدم الرسومية. هذه هي الحقيقة التي يتعين على المؤسسات الكبيرة التعامل معها: سجلات مصرفية عمرها 40 عامًا على حاسوب مركزي قديم. يستخدم أحد عملائي حاويات Kubernetes مع أنماط Circuit Breaker، بالإضافة إلى Chaos Monkey، كل ذلك لتطبيق KeyBank. لكن هذه الحاويات تتصل في النهاية بتطبيق COBOL.
كان الرجال من Google واثقين تمامًا من أنهم سيحلون جميع مشاكل موكلي، ثم بدأوا في طرح الأسئلة: ما هو أنبوب بيانات IBM؟ فيقال لهم: هذا موصل. ما الذي يتصل به؟ لنظام سبيري. وما هذا؟ وما إلى ذلك وهلم جرا. للوهلة الأولى يبدو: ما هو نوع DevOps الذي يمكن أن يكون موجودًا؟ ولكن في الواقع، فمن الممكن. هناك أنظمة توصيل تسمح لك بتسليم سير العمل إلى فرق التسليم.
3. نظرية القيود: نظرية القيود
دعنا ننتقل إلى النموذج الأصلي الثالث: المعرفة المؤسسية/"القبلية". كقاعدة عامة، يوجد في أي منظمة العديد من الأشخاص الذين يعرفون كل شيء ويديرون كل شيء. هؤلاء هم الأشخاص الذين تواجدوا في المنظمة لفترة أطول والذين يعرفون كل الحلول.
عندما يظهر هذا في الرسم التخطيطي، أقوم على وجه التحديد بدائرة هؤلاء الأشخاص بعلامة: على سبيل المثال، اتضح أن بعض الاجتماعات موجودة في جميع الاجتماعات. والأمر واضح بالنسبة لي: هذا هو خام برنت المحلي. عندما يختار مدير تكنولوجيا المعلومات بيني الذي يرتدي قميصًا وحذاء رياضيًا والرجل من IBM الذي يرتدي بدلة، تم اختياري لأنني أستطيع أن أخبر المخرج بأشياء لن يخبرها الرجل الآخر والتي قد لا يرغب المخرج في سماعها . أخبرهم أن عنق الزجاجة في شركتهم هو شخص يُدعى فريد وشخص يُدعى لو. ويجب فك عنق الزجاجة هذا، ويجب الحصول على معارفهم منهم بطريقة أو بأخرى.
لحل هذا النوع من المشاكل، يمكنني، على سبيل المثال، أن أقترح استخدام Slack. سوف يسأل المخرج الذكي لماذا؟ عادة، في مثل هذه الحالات، يجيب مستشارو DevOps: لأن الجميع يفعلون ذلك. إذا كان المخرج ذكياً حقاً سيقول: وماذا في ذلك. وهنا ينتهي الحوار. وجوابي على ذلك هو: لأن هناك أربع اختناقات في الشركة، فريد، لو، سوزي وجين. لإضفاء الطابع المؤسسي على معرفتهم، يجب على المرء أولاً تقديم Slack. جميع مواقع الويكي الخاصة بك هي محض هراء لأنه لا أحد يعلم بوجودها. إذا كان الفريق الهندسي مشاركًا في تطوير الواجهة الأمامية والخلفية ويحتاج الجميع إلى معرفة أنه يمكنهم الاتصال بفريق تطوير الواجهة الأمامية أو فريق البنية التحتية لطرح الأسئلة. وذلك عندما يكون لدى Lou أو Fred الوقت الكافي للانضمام إلى الويكي. وبعد ذلك في Slack قد يتساءل شخص ما، على سبيل المثال، عن سبب عدم نجاح الخطوة 5. وبعد ذلك سيقوم Lou أو Fred بتصحيح التعليمات الموجودة على موقع wiki. إذا قمت بإنشاء هذه العملية، فسوف تقع الكثير من الأشياء في مكانها من تلقاء نفسها.
هذه هي نقطتي الرئيسية: من أجل التوصية بأي تقنيات عالية، يجب عليك أولاً ترتيب الأساس لها، ويمكن القيام بذلك باستخدام الحلول منخفضة التقنية التي تم وصفها للتو. إذا بدأت بالتقنيات العالية ولم تشرح سبب الحاجة إليها، كقاعدة عامة، فإن هذا لا ينتهي بشكل جيد. يستخدم أحد عملائنا Azure ML، وهو حل رخيص وبسيط للغاية. وتمت الإجابة على حوالي 30% من أسئلتهم بواسطة آلة التعلم الذاتي نفسها. وهذا الشيء كتبه مشغلون لم يكونوا منخرطين في علوم البيانات أو الإحصاء أو الرياضيات. هذا أمر مهم. تكلفة مثل هذا الحل ضئيلة.
4. الاختراقات التعاونية: الاختراقات التعاونية
النموذج الرابع هو الحاجة إلى مكافحة العزلة. معظم الناس يعرفون هذا بالفعل: العزلة تولد العداء. إذا كان كل قسم في طابق خاص به، ولا يتقاطع الأشخاص مع بعضهم البعض بأي شكل من الأشكال، إلا في المصعد، فإن العداء بينهم ينشأ بسهولة شديدة. ولكن، على العكس من ذلك، إذا كان الناس في نفس الغرفة مع بعضهم البعض، فإنها تغادر على الفور. عندما يوجه شخص ما بعض الاتهامات العامة، على سبيل المثال، واجهة كذا وكذا لا تعمل أبدًا، فليس هناك ما هو أسهل لتفكيك مثل هذا الاتهام. يحتاج المبرمجون الذين كتبوا الواجهة فقط إلى البدء في طرح أسئلة محددة، وسيصبح من الواضح قريبًا، على سبيل المثال، أن المستخدم كان ببساطة يستخدم الأداة بشكل غير صحيح.
هناك طرق عديدة للتغلب على العزلة. طُلب مني ذات مرة استشارة أحد البنوك في أستراليا، لكنني رفضت القيام بذلك لأن لدي طفلين وزوجة. كل ما يمكنني فعله لمساعدتهم هو التوصية بسرد القصص الرسومية. وهذا شيء ثبت نجاحه. طريقة أخرى مثيرة للاهتمام هي اجتماعات القهوة الخالية من الدهون. في مؤسسة كبيرة، يعد هذا خيارًا ممتازًا لنشر المعرفة. بالإضافة إلى ذلك، يمكنك إجراء أيام تطوير داخلية ومسابقات هاكاثون وما إلى ذلك.
5. تدريب الكاتا
وكما حذرت في البداية، لن أتحدث عن هذا اليوم. إذا كنت مهتما، يمكنك إلقاء نظرة .
هناك أيضًا حديث جيد حول هذا الموضوع من مايك روثر:
6. موجهة نحو السوق: منظمة موجهة نحو السوق
هناك مشاكل مختلفة هنا. على سبيل المثال، الأشخاص "أنا" والأشخاص "T" والأشخاص "E". الأشخاص "أنا" هم أولئك الذين يفعلون شيئًا واحدًا فقط. عادة ما تكون موجودة في المنظمات ذات الأقسام المعزولة. "T" هو عندما يكون الشخص جيدًا في شيء واحد ولكنه جيد أيضًا في بعض الأشياء الأخرى. "E" أو حتى "المشط" هو عندما يكون لدى الشخص العديد من المهارات.
قانون كونواي يعمل هنا ()، والتي يمكن ذكرها بشكل مبسط على النحو التالي: إذا عملت ثلاثة فرق على المترجم، فستكون النتيجة مترجمًا من ثلاثة أجزاء. لذلك، إذا كان هناك مستوى عالٍ من العزلة داخل المؤسسة، فسيتم ترتيب Kubernetes وقواطع الدائرة وقابلية توسيع واجهة برمجة التطبيقات والأشياء الفاخرة الأخرى في هذه المؤسسة بنفس طريقة ترتيب المنظمة نفسها. بدقة وفقًا لكونواي وبغض كل الشباب المهووسين.
لقد تم وصف حل هذه المشكلة عدة مرات. هناك، على سبيل المثال، النماذج التنظيمية التي وصفها فرناندو فرنانديز. تلك البنية الإشكالية التي تحدثت عنها للتو، مع العزلة، هي بنية موجهة نحو الوظيفة. النوع الثاني هو الأسوأ، وهو بنية المصفوفة، وهو عبارة عن فوضى من النوعين الآخرين. والثالث هو ما نراه في معظم الشركات الناشئة، كما تحاول الشركات الكبيرة مجاراة هذا النوع. إنها منظمة موجهة نحو السوق. نحن هنا نقوم بالتحسين لتحقيق أسرع استجابة لطلبات العملاء. ويسمى هذا أحيانًا بالتنظيم المسطح.
يصف الكثير من الناس هذا الهيكل بطرق مختلفة، وأنا أحب الصياغة بناء / تشغيل الفرق، في أمازون يسمونه فريقين بيتزا. في هذا الهيكل، يتم تجميع جميع الأشخاص من النوع "I" حول خدمة واحدة، ويصبحون تدريجيًا أقرب إلى النوع "T"، وإذا كانت الإدارة الصحيحة موجودة، فيمكنهم حتى أن يصبحوا "E". الحجة المضادة الأولى هنا هي أن مثل هذا الهيكل يحتوي على عناصر غير ضرورية. لماذا تحتاج إلى مختبر في كل قسم إذا كان بإمكانك الحصول على قسم خاص للمختبرين؟ وأجيب عليه: التكاليف الإضافية في هذه الحالة هي الثمن الذي ستدفع به المنظمة بأكملها لتصبح من النوع "E" في المستقبل. في هذا الهيكل، يتعلم المختبر تدريجيًا عن الشبكات والهندسة المعمارية والتصميم وما إلى ذلك. ونتيجة لذلك، فإن كل مشارك في المنظمة على علم تام بكل ما يحدث في المنظمة. إذا كنت تريد أن تعرف كيف يعمل هذا المخطط في الصناعة، اقرأ .
7. مدققو التحول الأيسر: التدقيق في وقت مبكر من الدورة. الالتزام بقواعد السلامة المعروضة
يحدث هذا عندما لا تجتاز أفعالك اختبار الرائحة، إذا جاز التعبير. الأشخاص الذين يعملون لديك ليسوا أغبياء. إذا، كما في المثال أعلاه، قاموا بوضع تأثير طفيف/بدون تأثير في كل مكان، واستمر هذا لمدة ثلاث سنوات، ولم يلاحظ أحد أي شيء، فالجميع يعلم جيدًا أن النظام لا يعمل. أو مثال آخر - مجلس استشاري للتغيير، حيث يجب تقديم التقارير كل يوم أربعاء على سبيل المثال. هناك مجموعة من الأشخاص الذين يعملون هناك (بالمناسبة، لا يحصلون على أجور جيدة جدًا) والذين، من الناحية النظرية، يجب أن يعرفوا كيف يعمل النظام ككل. وعلى مدى السنوات الخمس الماضية، ربما لاحظتم أن أنظمتنا معقدة بشكل لا يصدق. ويجب على خمسة أو ستة أشخاص أن يتخذوا قرارًا بشأن التغيير الذي لم يقوموا به والذي لا يعرفون عنه شيئًا.
وبطبيعة الحال، هذا النهج لا يعمل. لا بد لي من التخلص من مثل هذه الأشياء لأن هؤلاء الناس لا يحمون النظام. القرار يجب أن يتخذه الفريق نفسه، لأن الفريق يجب أن يكون مسؤولا عنه. خلاف ذلك، ينشأ موقف متناقض عندما يخبر المدير الذي لم يكتب التعليمات البرمجية مطلقًا في حياته المبرمج بالمدة التي يجب أن يستغرقها كتابة التعليمات البرمجية. إحدى الشركات التي عملت معها كان لديها 7 مجالس مختلفة تراجع كل تغيير، بما في ذلك لوحة التصميم، ولوحة المنتج، وما إلى ذلك. حتى أن هناك فترة انتظار إلزامية، على الرغم من أن أحد الموظفين أخبرني أنه خلال عشر سنوات من العمل، لم يرفض أحد على الإطلاق أي تغيير أجراه هذا الشخص خلال هذه الفترة الإلزامية.
يجب دعوة المدققين للانضمام إلينا، وليس التخلص منهم. أخبرهم أنك تكتب حاويات ثنائية غير قابلة للتغيير والتي، إذا نجحت في جميع الاختبارات، تظل غير قابلة للتغيير إلى الأبد. أخبرهم أن لديك مسارًا كرمز واشرح لهم ما يعنيه ذلك. أظهر لهم المخطط التالي: ثنائي غير قابل للقراءة فقط في حاوية تجتاز جميع اختبارات الثغرات الأمنية؛ وبعد ذلك لا يلمسه أحد فحسب، بل لا يلمسون حتى النظام الذي ينشئ خط الأنابيب، لأنه يتم إنشاؤه ديناميكيًا أيضًا. لدي عملاء، Capital One، الذين يستخدمون Vault لإنشاء شيء مثل blockchain. لا يحتاج المدقق إلى إظهار "الوصفات" من الشيف، بل يكفي إظهار blockchain، والذي يتضح من خلاله ما حدث لتذكرة Jira في الإنتاج ومن المسؤول عنها.
وفق ، التي أنشأتها شركة Sonatype في عام 2018، كان هناك 2017 مليار طلب تنزيل OSS في عام 87.
الخسائر المتكبدة بسبب نقاط الضعف باهظة. علاوة على ذلك، فإن الأرقام التي تراها الآن أعلاه لا تشمل تكاليف الفرصة البديلة. ما هو DevSecOps باختصار؟ اسمحوا لي أن أقول على الفور أنني لست مهتمًا بالحديث عن مدى نجاح هذا الاسم. النقطة المهمة هي أنه نظرًا لأن DevOps حقق نجاحًا كبيرًا، فيجب أن نحاول إضافة الأمان إلى هذا المسار.
مثال على هذا التسلسل:
هذه ليست توصية لمنتجات معينة، على الرغم من أنني أحبها جميعًا. لقد استشهدت بها كمثال لإظهار أن DevOps، الذي كان يعتمد في البداية على النموذج التنظيمي في الصناعة، يسمح لك بأتمتة كل مرحلة من مراحل العمل على المنتج.
وليس هناك سبب يمنعنا من اتباع نفس النهج فيما يتعلق بالأمن.
مجموع
في الختام، سأقدم بعض النصائح لـ DevSecOps. تحتاج إلى إشراك المدققين في عملية إنشاء أنظمتك وقضاء الوقت في تثقيفهم. تحتاج إلى التعاون مع المراجعين. بعد ذلك، عليك أن تخوض معركة شرسة ضد النتائج الإيجابية الكاذبة. حتى مع استخدام أداة فحص الثغرات الأكثر تكلفة، قد ينتهي بك الأمر إلى إنشاء عادات سيئة للغاية بين المطورين لديك إذا كنت لا تعرف نسبة الإشارة إلى الضوضاء لديك. سوف يصبح المطورون غارقين في الأحداث وسيقومون بحذفها ببساطة. إذا سمعت عن قصة إيكويفاكس، فهذا ما حدث هناك إلى حد كبير، حيث تم تجاهل أعلى مستوى من التنبيه. بالإضافة إلى ذلك، يجب شرح نقاط الضعف بطريقة توضح كيفية تأثيرها على الأعمال. على سبيل المثال، يمكنك القول أن هذه هي نفس الثغرة الأمنية الموجودة في قصة Equifax. يجب التعامل مع الثغرات الأمنية مثل مشكلات البرامج الأخرى، أي أنه يجب تضمينها في عملية DevOps الشاملة. تحتاج إلى العمل معهم من خلال Jira وKanban وما إلى ذلك. لا ينبغي للمطورين أن يعتقدوا أن شخصا آخر سيفعل ذلك - على العكس من ذلك، يجب على الجميع القيام بذلك. وأخيرا، تحتاج إلى إنفاق الطاقة على تدريب الناس.
وصلات مفيدة
فيما يلي بعض المحادثات من مؤتمر DevOops التي قد تجدها مفيدة:
- سيرجي بيردنيكوف، أرتيوم كاليتشكين - قصة نجاح، أو "Dev+DevOps+Ops" (, )
- باروخ سادوغورسكي، ليونيد إيغولنيك - DevOps على نطاق واسع: مأساة يونانية في ثلاثة أعمال (, )
- ألكسندر تيتوف، كيريل تولكاتشيف -
- تيموثي ليستر -
تفحص ديفوبس 2020 موسكو - هناك أيضًا الكثير من الأشياء المثيرة للاهتمام.
المصدر: www.habr.com