عاجلاً أم آجلاً ، في أي مشروع ، حان الوقت للعمل على استقرار / توفر خدمتك. بالنسبة لبعض الخدمات ، في المرحلة الأولية ، تكون سرعة تطوير الميزات أكثر أهمية ، في هذه اللحظة لم يتم تشكيل الفريق بالكامل ، ولم يتم اختيار التقنيات بعناية فائقة. بالنسبة للخدمات الأخرى (غالبًا ما يكون b2b التكنولوجي) ، من أجل كسب ثقة العملاء ، تنشأ الحاجة إلى وقت تشغيل عالٍ مع الإصدار العام الأول. ولكن لنفترض أن اللحظة التي وصلت فيها X مع ذلك بدأت في الاهتمام بوقت "خدمتك" في فترة التقرير. تحت هذا التخفيض ، أقترح النظر في كل ما يتعلق بوقت التوقف وأفضل السبل للعمل على تقليله.
المؤشرات
من الواضح أنه قبل تحسين شيء ما ، عليك أن تفهم الحالة الحالية. لذلك ، إذا بدأنا في تقليل وقت التوقف عن العمل ، فهذا أولاً وقبل كل شيء ومن الضروري البدء في قياسه.
لن نتحدث هنا بالتفصيل حول كيفية القيام بذلك على وجه التحديد ، إيجابيات وسلبيات المناهج المختلفة ، ولكن عملية الأطروحة تبدو مثل هذا:
- نعتمد على المقاييس القريبة من الأعمال (أخطاء في الخدمة ، ووقت استجابة الخدمة ، $ / second ، والاشتراكات / الثانية ، وما إلى ذلك)
- تحديد ما هو جيد وما هو سيئ
- الانتقال الجيد -> السيئ هو بداية الحادث
- انتقال سيئ -> جيد - نهاية الحادث
- الوقت من البداية إلى النهاية - مدة الحادث (الحد الأقصى معنا)
- مجموع مدة الحوادث للفترة (الشهر / الربع / السنة) - وقت التوقف
- (100 - <timetime> / <مدة الفترة> * 100) = النسبة المئوية لمدى توفر الفترة
عند الحديث عن وقت التشغيل / التوقف ، غالبًا ما يذكرون مؤشرًا آخر:
MTTR (متوسط وقت الإصلاح) - متوسط الوقت من بداية الحادث حتى نهايته.
تبدأ المشاكل معه من الكلمة الأولى في الاختصار. بالنظر إلى أن جميع الحوادث مختلفة ، فإن متوسط المدة لا يمكن أن يخبرنا بأي شيء عن النظام.
هذه المرة لن نحسب أي شيء ، ولكن فقط انظر ماذا يحدث أثناء الحادث.
تشريح الحادث
دعونا نرى ما هي الخطوات المهمة التي يمكن تمييزها أثناء الحادث:
- كشف - الفاصل الزمني بين الخطأ الأول الذي قدمناه للمستخدم قبل أن يستقبل المصاحب SMS
- رد فعل - من تلقي إشعار حول مشكلة إلى اللحظة التي بدأ فيها شخص ما في حل هذه المشكلة (عادة في تلك اللحظة يتم نقل حدث المراقبة إلى الحالة المعترف بها)
- تحقيق - من بداية العمل على مشكلة إلى اللحظة التي يُفهم فيها سبب الحادث ونعلم ما يجب القيام به لاستعادة العمل.
- القضاء - وقت الاسترداد ، على سبيل المثال ، الإفراج عن التراجع ، روجت جديدة
سيد خادم قاعدة البيانات الأساسي
ربما يكون نموذجنا غير مكتمل وهناك بعض المراحل الأخرى ، لكنني أقترح تقديمها فقط بعد إدراك كيف سيساعدنا ذلك في الممارسة. في غضون ذلك ، فكر في كل مرحلة بمزيد من التفصيل.
كشف
لماذا نقضي الوقت في إيجاد حالة الطوارئ؟ لماذا لا ترسل إشعارًا بشأن أول خطأ يتلقاه المستخدم؟ في الواقع ، أعرف العديد من الشركات التي حاولت القيام بذلك ، لكنها تخلت عن هذه الفكرة بعد بضع ساعات فقط ، والتي تلقت فيها عشرات الرسائل القصيرة. أعتقد أنه لا توجد خدمة واحدة أكبر أو أقل لا تحتوي على تدفق مستمر من "الخلفية" من الأخطاء. ليست جميعها علامة على أن شيئًا ما قد انكسر ، فهناك أيضًا أخطاء في البرامج وبيانات غير صالحة تم الحصول عليها من النموذج وعدم كفاية التحقق ، إلخ.
ونتيجة لذلك ، يتم استخدام مستوى الأخطاء (أو المقاييس الأخرى) التي تتجاوز التقلبات اليومية كمعيار لفتح حادثة. هذا هو بالضبط ما يؤدي إلى حقيقة أن إخطار الموظفين المسؤولين يحدث في وقت لاحق من بداية المشكلة الفعلية.
ولكن نعود إلى مهمتنا الأصلية - تقليل مدة الحوادث. كيف يمكننا تقصير وقت الكشف؟ أسرع للإخطار؟ الخروج بمنطق فائق لاكتشاف الحالات الشاذة؟
أقترح عدم القيام بأي شيء حتى الآن ، ولكن للنظر في المراحل التالية ، حيث أنها في الواقع مترابطة.
رد فعل
هنا لدينا عامل بشري محض. نفترض أن المراقبة تمكنت من الكشف عن المشكلة ونجحنا في إيقاظ المهندس في الخدمة (التصعيد بأكمله نجح أيضًا في المرحلة السابقة).
ضع في اعتبارك الحالة "الأسوأ" ، ليس لدينا خدمة مخصصة للخدمة ، ولفت التنبيه المشرف النائم بهدوء. أفعاله:
- الرد على الرسائل القصيرة: هنا الزوجة ذات الاذن الحساسة تساعد كثيرا تطبيقات مختلفة للهاتف تعزز تأثير استقبال الرسائل القصيرة (1-5 دقائق)
- اتخاذ قرار بأنه سيزحف مع ذلك من السرير: إذا لم يتم ضبط التنبيهات بشكل صحيح ، يمكن للشخص الانتظار لمدة دقيقتين "ماذا لو جاء الحل؟" وتغفو (1-15 دقيقة)
- الوصول إلى الكمبيوتر المحمول ، افتح عينيك ، استيقظ ، انتقل إلى المراقبة ، اضغط Ack: (1-15 دقيقة)
ونتيجة لذلك ، في أسوأ الأحوال ، نحصل على 35 دقيقة من رد الفعل. وفقا لملاحظاتي ، يبدو أن وقت رد الفعل هذا صحيح.
بما أننا نتعامل مع الناس في هذه المرحلة ، يجب علينا أن نتصرف بحذر وعناية. لا تحتاج بأي حال من الأحوال إلى كتابة لائحة يجب أن يتحرك بموجبها الشخص الذي استيقظ للتو! دعنا فقط نهيئ الظروف.
دعونا نتخلص من شكوك المهندس في أن المشكلة ستنتهي من تلقاء نفسها. يتم ذلك بكل بساطة: اجعل معيار التنبيه غير حساس للمشكلات الطفيفة وأخبره إذا استمر الحادث لفترة طويلة . نعم ، لقد قمنا فقط بزيادة مدة مرحلة "الكشف" ، ولكن دعونا نلقي نظرة على مثال:
- زيادة وقت الكشف بمقدار 5 دقائق
- يتم تقليل عدد الحوادث: عادة ما تقع جميع الأخطاء القصيرة في غضون دقيقة واحدة. يجب تسجيل هذه الحوادث القصيرة ، ولكن دون إخطار الناس. في كثير من الأحيان ، يمنحون فترة توقف كبيرة جدًا في المجموع ، ولكن يمكنك التعامل معهم خلال ساعات العمل. لهذه المهمة ، ستحتاج إلى دقة عالية في المراقبة ، نظرًا لأن المشكلة قد انتهت بالفعل ، ولا تحتفظ أدوات التشخيص في الغالب بالسجل.
- إذا أجبر الشخص على الرد على التنبيهات مرة واحدة في الشهر أو أقل من ذلك ، وليس كل يومين ، فسوف يرد عليه بشكل أكثر ملاءمة ولن يتعامل مع هذا على أنه روتين
- الإخطار المتأخر يسمح للشخص بعدم التفكير: إذا وصلت رسالة نصية قصيرة ، فإن كل شيء خطير ولن يتم تصحيحه بنفسه
من المحتمل أن يقلل هذا النهج من إجمالي وقت التفاعل بمقدار 15 دقيقة أو أكثر. إذا كان وقت رد الفعل هذا لا يناسبك ، فعليك التفكير في خدمة الواجب.
تحقيق
ربما تكون هذه أصعب مرحلة في الحادث عندما تحتاج إلى فهم ما يحدث وماذا تفعل. في الواقع ، غالبًا ما يتم الجمع بين هذه المرحلة ومرحلة اتخاذ التدابير ، نظرًا لأن العملية عادةً ما تكون على هذا النحو:
- ننظر إلى المراقبة ، والسجلات (إذا لم تكن المراقبة كافية) ، فإننا نطلق بعض أدوات التشخيص الأخرى
- طرح الفرضيات
- نختبر الفرضيات ، إما عن طريق المقاييس ، أو عن طريق تنفيذ بعض الإجراءات (أعد تشغيل كل شيء :)
- تقييم نتائج التغييرات
- التواصل مع الزملاء إذا كانت معرفتك بنظام فرعي معين غير كافية
وما إلى ذلك حتى التنوير أو نهاية الحادث.
عادة ما تكون هذه المرحلة هي الأكثر أهمية في إجمالي مدة الحادث. كيف تخفضه؟
كل شيء غير واضح هنا ، هناك عدة نواقل:
- تبسيط البنية التحتية الخاصة بك : تخيل مدى سرعة تعطل الأشخاص الذين لديهم قاعدة بيانات واحدة وخدمة واحدة
- نشر المعرفة في الفريق : مثالي إذا لم يتم التواصل بين الأشخاص أثناء الحادث ، ولكن أثناء العمل اليومي (يعد التواصل بين الأشخاص عملية طويلة جدًا بشكل عام)
- المراقبة : يعتقد الكثير من الناس أن المراقبة تعمل فقط في مرحلة "الكشف" ، ولكن في الواقع يمكن أن تكون بمثابة تحسين لعملية اختبار الفرضية ("هل تعمل قاعدة البيانات بشكل صحيح؟" ، "هل تعمل خدمتي في الموارد؟") وأيضًا كوسيلة نقل نشر المعرفة في الفريق. "Serge ، تحقق مما إذا كانت هناك أخطاء في سجل X حول الجمود؟" يمكن أن يتحول إلى مشغل ، وصفه سيكون رابطًا للويكي مع تعليمات .
القضاء
كما قلت أعلاه ، غالبًا ما تندمج هذه المرحلة مع المرحلة السابقة. لكن يحدث أن السبب واضح على الفور ، لكن التعافي سيكون طويلًا جدًا. على سبيل المثال ، لديك خادم ميت مع سيد أساسي (لن أتمكن من التعود عليها لفترة طويلة :) باستخدام قاعدة بيانات ، ولم تقم أبدًا بترويج نسخة متماثلة ، أي ستقرأ الوثائق ، وستطرح تكوين تطبيق جديد ، وما إلى ذلك.
بطبيعة الحال ، بعد كل حادثة مهمة ، تحتاج إلى معرفة كيفية منع حدوث ذلك مرة أخرى أو تسريع الشفاء بشكل كبير. لكن دعنا نرى ما هي الاتجاهات التي يمكننا محاولة العمل بها بشكل استباقي:
- أدوات إدارة البنية التحتية : إذا كان من أجل إصلاح كل شيء تحتاج إلى طرح تكوين جديد ، ولكن يتم ذلك في 20 دقيقة على الأقل - هذا هو الحد الخاص بك. حاول التوصل إلى سيناريوهات لما قد يحدث وطريقة لتسريع بعض العمليات بشكل عاجل. على سبيل المثال ، في ansible ، قمت بتعيين التسلسل (موازاة تنفيذ المهمة) = 3 ، ولكن إذا كنت لا تزال تكذب ، يمكنك التدحرج مع المسلسل = 30 ، تحتاج إلى تعليم الجميع كيفية إعادة تعريفه (على غرار استراتيجية التحديث المتداول في kubernetes).
- التدريبات : إذا كنت تعرف أن السيناريوهات المحتملة للفشل والاسترداد ليست تلقائية ، فيجب أن يكون لديك تعليمات يجب اختبارها . خطط وقت التوقف (إذا لزم الأمر) ، وقم بإجراء التمارين. في كثير من الأحيان ، في هذه المرحلة ، يتم أتمتة مثل هذه الحالات ، حيث يتم توضيح معظم المزالق حتى أكثر الإجراءات تعقيدًا للوهلة الأولى خلال التمارين.
- التفاعل مع المقاولين : يجب أن تعرف مقدمًا ما ستفعله إذا مرض مزود الاستضافة الخاص بك. في كثير من الأحيان ، يؤدي الوعي باحتمالية وجود مشكلة وتكلفة إغلاق المخاطر إلى الاستنتاج - "نحن فقط ننتظر التعافي". ولكن من ناحية أخرى ، سيكون المهندسون ورجال الأعمال جاهزين لمثل هذا السيناريو. على سبيل المثال ، يمكنك العمل من خلال مسألة تبديل حركة المرور إلى كعب مُعد مسبقًا ، وإبلاغ المستخدمين برسالة معدة مسبقًا ، وما إلى ذلك. أو العكس ، تقوم بعمل تعليمات نعطي المضيف 30 دقيقة لاستردادها ، ثم نبدأ في الانتقال إلى وحدة تحكم المجال DC أخرى ، حيث توجد بالفعل نسخة طبق الأصل من قاعدة البيانات ، ولكنك تحتاج إلى توسيع كل شيء آخر. وهنا مرة أخرى ، التعاليم ، نلاحظ وقت الانتقال ، إلخ.
MTBF (متوسط الوقت بين الفشل)
ذكر مقياس مشترك آخر في مناقشة وقت التشغيل. مرة أخرى ، أقترح ألا أتوسط أي شيء ، ولكن ببساطة للحديث عن عدد الحوادث التي تحدث على مدار فترة زمنية.
هنا يأتي السؤال الأول حول مدى اهتمامك بالتسامح مع الخطأ في خدمتك:
- هل هناك نقطة فشل واحدة (SPOF) في البنية التحتية ، ما هو احتمال الفشل؟
- ما مدى ثقتك في عدم وجود ملفات شخصية لا تعرفها؟ (هذه هي المشكلة التي يحلها قرد الفوضى )
- هل تعمل موازنات الحمل بشكل جيد؟ ( تقريري عن التوازن )
- ما مدى مرونة الشبكة؟
- ما مدى مصداقية مركز البيانات؟
في بعض الأحيان ، من أجل حساب / توقع كل هذا ، يقومون بعمل "خريطة مخاطر" ، حيث يكون لكل سيناريو (والذي يمكن افتراضه ، دائمًا ما لا نعرفه بعد) احتمال + تأثير (توقف قصير / طويل ، فقدان البيانات ، فقدان السمعة وما إلى ذلك). ثم ، يعملون بشكل منهجي على مثل هذه البطاقة ، ويغلقون أولاً وقبل كل شيء سيناريوهات محتملة وخطيرة للغاية من حيث التأثير.
تقنية أخرى يمكن استخدامها هي تصنيف الحوادث السابقة. هناك الكثير من الحديث الآن عن أنه من المفيد جدًا كتابة حوادث "ما بعد الوفاة" ، التي تحلل أسباب المشكلة ، وأفعال الناس ، وتحدد الإجراءات المستقبلية المحتملة. ولكن من أجل إلقاء نظرة سريعة على أسباب جميع الحوادث خلال الفترة الماضية ، من الملائم تلخيص مدتها بالتجمع بحسب "فئات المشاكل" وحيث يكون معظم فترات التوقف هي اتخاذ الإجراءات:
- الأخطاء البشرية : تقليل عدد الإجراءات اليدوية في الإنتاج ، حماية مختلفة ضد أخطاء المشغل
- الإصدارات غير الناجحة : يجدر تحسين الاختبار (بما في ذلك اختبار الحمل)
- أخطاء التطبيق : إصلاح التسربات والأعطال وغيرها من حالات التجمد
- الشبكة : شراء المعدات ، إنشاء ، استئجار الشبكات ، تغيير المقاول
- قواعد البيانات : استئجار DBA ، رعاية التسامح مع الخطأ ، شراء أجهزة أفضل
- العاصمة : فكر في النسخ الاحتياطي أو النقل
- التأثيرات الخارجية (ddos ، الحظر ، مراجعات الشهادات ، المجالات): اشترِ antiddos ، قم بتخزين الوكلاء ، راقب فترة صلاحية المجالات / الشهادات ، لديك العديد من الشهادات من CAs مختلفة.
أي أنه إذا لم تحاول حتى التنبؤ بسيناريوهات محتملة للمشكلات ، فمن الجدير بالتأكيد العمل مع الحوادث التي حدثت بالفعل.
المجموع
جميع الحوادث مختلفة:
خوارزمية العمل لزيادة وقت التشغيل تشبه إلى حد كبير أي تحسينات أخرى:
-> -> ->
من تجربتي الخاصة ، يمكنني القول أنه من أجل تحسين كبير في وقت التشغيل ، يكفي فقط البدء في متابعته وتحليل أسباب الحوادث. يحدث عادة أن أبسط التغييرات تجلب التأثير الأكثر أهمية.
لا تساعد خدمة المراقبة لدينا في مرحلة "الاكتشاف" فحسب ، بل تقلل أيضًا إلى حد كبير من "التحقيق" (سيؤكد العملاء)