الحوادث تساعدك على التعلم

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

يعمل Alexey Kirpichnikov ( BeeVee ) في البرمجة في ياندكس منذ عام 2008. كانت الاختناقات المرورية ، التي عملت في مشاريع خاصة بالرياضات ، فريقًا رائدًا في خلفية Yandex.Taxi. منذ عام 2014 ، كان يعمل في DevOps والبنية التحتية في Kontur - لقد قام بتطوير الأدوات التي تجعل الحياة أسهل للمطورين من فرق المنتجات. ظهرت فكرة كتابة وتحليل موضوعات ما بعد الوفاة قبل خمس سنوات ، وخلال هذا الوقت كانت موضوعات ما بعد الوفاة مملوءة بالقوالب والمسرد والمذكرات واللقطات والتحليلات. ولكن هذا ليس بالأكثر صعوبة - لقد كان من الصعب التغلب على القصور الذاتي والخوف وسوء الفهم لمعنى تقارير الحوادث بين المهندسين . إن ما حدث في النهاية وما لا يمكن تعويضه يمكن لـ "تحليلات الأريكة" القيام به هو فك شفرة تقرير Alexey.


يرجى ملاحظة - تحت أرجل الطاولة بأطوال مختلفة ، توجد كتب "المقاييس" و "الاختبارات" و "النشر".


في كونتور ، بعد التوظيف ، يقدمون مجموعة من الهدايا التذكارية: قلم ، وكأس ، ودفتر. جئت إلى SKB Kontur في فريق جديد للبنية التحتية قبل 5 سنوات ، عندما بلغت الشركة 25 عامًا.



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

في ذلك الوقت ، قرأت أولاً "Project" "Phoenix" "" واستلهمت من الأفكار الجديدة الفتية لممارسات DevOps. بدأت أكتب أفكاري للتحسينات في دفتر ملاحظات ، والآن هي قطعة أثرية تحتوي على بقع القهوة والسجلات التاريخية.

• " المراقبة! دعونا نضع Grafana ، وجمع المقاييس وبناء الرسوم البيانية. سوف نفهم بشكل أفضل ما يحدث في الإنتاج. " بالنسبة لعام 2014 ، هذه فكرة جديدة إلى حد ما وممارسة DevOps صلبة. "
• " الانهيار التلقائي!" ما عدد ملفات zip التي يمكن تحميلها إلى المجلد المشترك ، وفك ضغطها على الخادم وتشغيل exe في برنامج جدولة المهام في Windows؟ "دعنا نقدم نظام نشر صناعي وإطلاقات من خلاله ، CI!"
• " بعد الوفاة ! إذا كان هناك نوع من الحوادث في الإنتاج ، فلنتعرف على ما كانت عليه ، ونعرف السبب ، ونكتب تقريرًا ونغير عمليات التطوير والاختبار وعمليات CI الخاصة بنا حتى لا تقع مثل هذه الحوادث في المستقبل "

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

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

ما هو الحادث؟

أي من هذه هي الحادثة؟

• مثال رقم 1. على منصة مدونة بها مليون مستخدم ، نتيجة لنوع من الخطأ ، تُفقد جميع إدخالات مستخدم واحد.
• مثال رقم 2. تعمل خدمة موظفي المكاتب في أيام الأسبوع من 9 إلى 6 ، وفي أوقات أخرى لا يوجد مستخدمون فيها. كانت الخدمة غير متوفرة في ليلة السبت إلى الأحد لمدة ساعتين متتاليتين ، ولم يلاحظ أحد ذلك.
• مثال رقم 3. انخفض غرافانا مع مقاييس الإنتاج 15 دقيقة. في الإنتاج ، لم يتم كسر أي شيء ، لكن الرسومات لم تكن متوفرة.

لفهم أي شيء من هذا fakapy ، ننتقل إلى تجربة المعلمون - Google و Atlassian و PagerDuty. يعرف المعلمون كيفية إعداد التحولات والمهندسين عند الطلب وكيفية كتابة التقارير لفهمها. أدلة على الإنترنت لها تعريفات الحادث.

التعريف من PagerDuty.

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

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

يحتوي كتاب هندسة موثوقية الموقع من Google على معايير واضحة:

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

لا يحتوي Contour على تعريف منشور لـ fakap ، لكننا قمنا بصياغة معاييرنا الخاصة لتحديد ما الذي يشكل حادثًا.

لاحظ المستخدمون الخارجيون أو الداخليون تدهور الخدمة . مثال رقم 3 مع Grafana ، الذي يكمن ، هو حادث واضح. لم ينقطع الإنتاج ولم يلاحظ المستخدمون الخارجيون هذا ، ولكن على الرغم من ذلك ، فإن كونتور هو fakap ، لأن الأدوات الداخلية لم تنجح.

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

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

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

مع تعريف وأنواع مختلفة من الضرر تسويتها. دعنا ننتقل إلى كيفية الاستفادة من الحوادث.

ما هو استخدام fakap؟

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

تعليمات الكلاسيكية

العثور على الجناة أولا. ثم قم بالعمل "التعليمي" مع المهندسين.

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

إذا أزعجتك التعليمات ، فهذه أخبار جيدة.

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

سأوضح هذا التحول في النموذج بتعليمات من جون Alspaw ، أحد قادة حركة DevOps ، الذي عمل سابقًا في CTO في Etsy. التعليمة مأخوذة من مقاله الكنسي لعام 2013 ، Blameless Post Mortem and Just Culture.

اسأل المهندسين:

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

يجب أن يُطلب من المهندسين دون تهديد بالعقاب.

هذا هو الشيء الرئيسي في توصية جون.

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

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

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

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



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

الاعتراض رقم 1: مرة واحدة

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

لحل المشكلة ، هناك خارقة للحياة ، وكيفية كتابة شيء صحيح أثناء وقوع حادث. شاعته أرتيمي ليبيديف:

"هناك طريقة بسيطة لتنظيم الوقت - طريقة jeepeg التقدمية". في أي لحظة ، يكون أي مشروع جاهزًا بنسبة 100٪ ، على الرغم من أنه قد يكون أكثر تطوراً بنسبة 4٪. بناءً على الوقت المتاح ، يمكن إعداد المشروع حتى بكسل ، أو يمكن تركه في مرحلة رسم المفاهيم ".

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



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

قم بإجراء بسيط - سجل التسلسل الزمني للأحداث.

التسلسل الزمني للأحداث

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

15.01.18 17:25 YEKT    PrefixSearch  50   . ,     . 

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

لقطات

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



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

الاعتراض رقم 2: الكسل

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

لهزيمة تماما المشكلة لن تنجح. ولكن يمكنك تسهيل عملك مقدما.

قالب

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

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

إنشاء مذكرة مع أمثلة

يحتوي نموذجنا على قسم "تلف" مع أقسام فرعية.

قسم "التقييم النوعي". يصف ما يراه المهندس أمامه عندما يملأ هذا الجزء من القالب:

• ما وظيفة لم تنجح ، متى ولمن.
• ما إذا كان هناك فقدان أو تلف البيانات.

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

قسم "القياس الكمي":

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

مجموعة من هذه الأسئلة هي النمط.

مثال على أحد القوالب المكتملة.

أضف مسرد

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

اكتب مسردًا صغيرًا يصف جميع المصطلحات المستخدمة في التقرير.

نسخ جميع القطع الأثرية

إذا قمت بإرفاق قطع أثرية بالتقرير: لقطات في Grafana ، فإن تاريخ الرسائل في الدردشة ، والذي تم فيه تحليل الحادث مع مهندسين آخرين ، قم بعمل نسخ. المقاييس لديها القدرة على "التعفن" ، وتغيير الدردشات. قبل عام ، كنت في Slack ، الآن في Telegram - رابط الدردشة قديم ولا يعمل ، وستنخفض قياسات الاحتفاظ - يتم تخزينها لمدة عام.

نسخ القطع الأثرية - يتيح لك اختراق الحياة هذا ملء التقارير.

الاعتراض رقم 3: لن يقرأ أحد

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

بعد الوفاة هو ردود الفعل في عملية التحسين المستمر لعمليات التنمية.

في أي كتاب للمعلمين ، على سبيل المثال ، في كتيب الحوادث الأطلسي ، تتم كتابة أنه وفقًا لنتائج كل حالة وفاة ، يلزم:

• صياغة المهام في التنمية ؛
• إنشاء المهام في bugtracker التي سيأخذ منها مطورو البرامج الخاصة بك ؛
• وضع روابط من الوفاة إلى هذه المهام.

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

هذا هو ما يتقارب فيه المعلمون. لا يوجد شيء للقول - الفوائد واضحة.

مثال على عناصر عناصر المهام من الوفاة الحقيقية.



لكننا في Kontur أضفنا محللاً إلى ذلك.

تحليلات أريكة

اعتدنا على تحليل الحادث في عزلة. حدث الفشل من تلقاء نفسه في فريق واحد ، في نظام استضافة واحد - حدث شيء ما ، تم إصلاحه.

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

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

ماذا نحلل في تحليلات أريكة؟

Fakap المدة

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

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

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

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

ضرر الجودة

ينقسم الضرر النوعي إلى عدة فئات. أعلى 3 يشمل:

• عدم إمكانية الوصول ، الأخطاء ؛
• الفرامل ، وزيادة الكمون.
• السلوك الخاطئ المرئي.

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

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

مشغلات

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



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

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

ما الذي يجب تحسينه - التنبيه أم النشر؟ ما يجب القيام به - استضافة أو جمال الرسوم البيانية؟

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

ممكن "حبوب"

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

• على عدد أخطاء HTTP من العميل - 10 ٪ ؛
• على ظهور أنواع جديدة من الأخطاء في السجلات: التثبيت ، إعدادات الإخطار - 8 ٪ ؛
• على موارد النظام: وحدة المعالجة المركزية والذاكرة والقرص ، المواضيع ، GC - 6 ٪.

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

هنا سأعلن مرة أخرى نظام التنبيه Moira ، الموجود في Open Source.



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

توصيات

التوصيات التنظيمية التي يمكن للفريق اتباعها ، وكذلك تقليل عدد الحوادث. لدينا أعلى 3.

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

أؤكد أن هذه ليست تعليمة ، ولكنها قصة عن كيفية جمعنا التحليلات. قد تكون تحليلاتك مختلفة.

كيف تكتب

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

نشر بعد الوفاة والمهام في تعقب علة واحد

في bugtracker ، على عكس مُحرر مستندات Google أو Wiki ، هناك حقول ثابتة يمكنك من خلالها تعيين مجموعة من القيم. هذا يسهل تحليل إحصاءات الرسوم البيانية في وقت لاحق.

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

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

إنشاء حقول خاصة

لقد تحدثت بالفعل عن مجالات خاصة. لدينا ما يلي.

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

تتيح لك جميع البيانات من الحقول الخاصة فهم كيفية عمل البنية الأساسية لديك.

مثال على تقرير الحادث المكتمل لدينا.



يتم ملء حقول العمود الأيمن فقط من خلال التحديد من القوائم المنسدلة.

جمع فريق من المهندسين الذين يهتمون بالجودة

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

يسمى فريقنا Q-team - من كلمة "الجودة". لديها 3 أشخاص - أحد المهندسين الموهوبين في الشركة الذين يعملون في البنية التحتية.

في المجموع

اقرأ المعلم - كتب مقالة John Allspaw وإدارة الحوادث: هندسة الوثوقية في الموقع ، عملية PagerDuty لما بعد الوفاة ، دليل حوادث الأطلسي .

وعندما تأتي إلى العمل غدًا ، فقط اتبع الخطوات الأولى :

• بدء مشروع لـ fakaps في bugtracker الذي تقوم فيه بالمهام ؛
• خذ أي قالب - لا تحاول أن تكتب نموذجك الخاص ، أو تأخذ قالبنا ، أو من Google في SRE ؛
• عندما ينفجر شيء ما ، اكتب فقط.

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

نأمل أن تتذكر وشكر أليكسي على قصة هذه التجربة. وسنحاول ، بدوره ، جمع تقارير مفيدة جديدة في برنامج DevOpsConf ، توصيات يمكنك من خلالها التقدم والتقديم. سيعقد المؤتمر في الفترة من 30 إلى 1 سبتمبر 2019 ، وحتى 20 أغسطس لا نزال ننتظر طلبات من أنصار DevOps ، ولكن تمت الموافقة على 12 بالفعل ، أي أن المنافسة ستكون أعلى من الموعد النهائي.

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