مبادئ وممارسات هندسة موثوقية الموقع (SRE) الرئيسية: الحلقات الفاضلة
إذا كان صحيحا حقا أنه بمعنى ما "أنت ما تفعله"، فقد وصلنا إلى قلب هذه الوحدة النمطية. في هذه الوحدة، سننظر في اثنتين من الممارسات التي غالبا ما تعتبر أساسية لممارسة SRE. كلاهما ينبع من مبدأ أنه من المهم إنشاء "دورات فاضلة". الدورات الفاضلة في هذا السياق هي الممارسات التي تبني حلقات الملاحظات في مؤسسة تساعد تلك المؤسسة على تحسينها باستمرار. لدينا وحدات متابعة كاملة على هاتين الممارسات بالضبط، لذلك سنقوم فقط بتصفح السطح مع نظرة عامة على كل منهما هنا.
الحلقة الفاضلة #1: SLIs وSLOs
في وقت سابق من هذه الوحدة، شددنا على وجهة نظرنا حول العمل نحو "المستوى المناسب من الموثوقية". وهذا القسم هو بالضبط المكان الذي يحمل فيه هذا المفهوم.
لنفترض أن لديك خدمة جديدة تخطط لتقديمها إلى الإنتاج (إما خدمة تم إنشاؤها أو خدمة لا تزال في عملية التخطيط). كجزء من هذه العملية، من المهم اتخاذ بعض القرارات حول الموثوقية المطلوبة. إذا كنت لا تكتب كل التعليمات البرمجية بنفسك، يتم اتخاذ هذه القرارات (وهذه النقطة حاسمة) بالتعاون مع المطورين الذين يقومون بهذا الشيء.
القرار الأول الذي يجب اتخاذه هو، ما الذي يجب أن نستخدمه كمؤشرات لصحة الخدمة (مؤشر مستوى الخدمة أو SLI)؟ هناك طريقة أخرى لطرح هذا السؤال وهي "كيف يمكنك معرفة الوقت الذي يعمل فيه بشكل جيد؟". هناك الكثير من الطرق لتتبع SLI ونستكشف بعضها بالتفصيل لاحقا. ولكن هذه المؤشرات عادة ما تكون:
- مقاييس النجاح مقابل الفشل. هل تكمل الخدمة عملية بنجاح بعض النسبة المئوية من الوقت؟
- مقاييس التوقيت. هل أرجعنا إجابة خلال فترة زمنية معينة؟
- مقاييس معدل النقل. هل عالجنا كمية معينة من البيانات؟
أو مزيج من كل هذه المقاييس.
على سبيل المثال البسيط، قد نقول إن SLI لخدمتنا هي عدد المرات التي عادت فيها بنجاح، يشار إليها عبر كود HTTP 200 (مقابل 500 أو بعض الأكواد الأخرى).
الآن بعد أن أصبح لدينا مؤشر واضح يخبرنا كيف تعمل الخدمة. نريد أن نقرر مستوى الموثوقية الذي نتوقعه أو نرغب فيه. على سبيل المثال، هل نتوقع على مدى فترة من اليوم أن نرى معدل فشل بنسبة 20٪ من الخدمة؟ نستخدم أعدادًا مستديرة وكبيرة هنا ليسهل التفكير فيها في البداية. في الوحدات اللاحقة، نزيد من تعقيد ودقة عبارات مثل هذه ("أي المستخدمين يرون معدل الخطأ هذا؟ البعض منهم؟ معظمهم؟" وهكذا). هذا التوقع، الذي تم إنشاؤه بالتعاون مع مطور الخدمة، هو هدف مستوى الخدمة (SLO).
يجب أن يكون SLO شيئًا يمكن قياسه بدقة وتمثيله في نظام المراقبة الخاص بك. من المفترض أن يكون هدفًا موضوعيًا ومفهومًا جيدًا لموثوقية الخدمة، إذًا فما هو الرقم الجيد بما فيه الكفاية؟ لا يصح القول هنا "حسنًا، أعتقد أن الخدمة كانت تعمل بشكل جيد خلال الأسبوع الماضي أو نحو ذلك، ولكن من الصعب تحديد ذلك". سواء كانت الخدمة تفي بـ SLO أو أنها ليست كذلك، يجب أن تكون البيانات واضحة. إذا لم تفِ بـ SLO الخاص به (خاصة بشكل متكرر على مدى فترة زمنية)، فحينئذٍ يكون هناك خطأ ما ويجب معالجته.
موازنات الخطأ
يمكننا أن نفهم أن المؤسسة قد تدخل حيز التنفيذ إذا لم تفي الخدمة ب SLO الخاص بها. ولكن، يأخذ SRE هذا المفهوم بأكمله خطوة أخرى إلى الأمام للحالات التي يتم فيها استيفاء SLO أو تجاوزه. وتستخدم بعض المؤسسات SLO لإنشاء ما يسمونه "ميزانيات الخطأ".
لإثبات هذه الفكرة، لنستخدم عينة الخدمة التي كنا نناقشها ونجاح SLO بنسبة 80٪ (فكر في الأمر على أنه "يجب أن يكون أعلى من نسبة 80٪ في غالبية الوقت"). مع SLO بنسبة 80٪ من وقت التشغيل، وقد أعلنا أن خدمتنا يجب أن تصل إلى 80٪ من الوقت. ولكن ماذا عن الـ 20٪ الأخرى؟ إذا انخفضت خدمتنا بنسبة 20٪، فإننا لا "نهتم" حقًا لأننا قررنا أن زيادة نسبة 20٪ إضافية ليست مهمة بالنسبة لنا كهدف خدمة.
لذا إذا لم نهتم بما يحدث خلال تلك الفترة، فماذا يمكننا أن نفعل بالخدمة؟ شيء واحد يمكننا القيام به بالتأكيد هو إرباك الخدمة قيد التشغيل عن طريق ترقيتها، ربما بإصدار جديد يضيف بعض الميزات. إذا ظل هذا الإصدار الجديد قيد التشغيل ولم يضف أي توقف، فهذا أمر رائع. إذا تسبب هذا الإصدار الجديد في أن تكون الخدمة أقل استقرارا وأرجع أخطاء بنسبة 10٪ أخرى من الوقت حيث يتم تصحيح الأخطاء، فلا يزال الأمر على ما يرام. نحن في حدود ميزانيتنا من عدم الموثوقية المسموح بها.
ميزانية الخطأ هي الفرق بين الموثوقية المثالية المحتملة للخدمة والموثوقية المرغوبة (100٪ - 80٪ = 20٪). في هذه الحالة، تمنحنا ميزانية الخطأ صندوقا بنسبة 20٪ من عدم إمكانية عدم الموثوقية بنسبة 20٪ حيث "لا نهتم بما إذا كان قد تم رفعه أم لا لأنه لا يزال في المواصفات". يمكننا الاعتماد على وقضاء هذا الوقت بنسبة 20٪ بأي طريقة نريدها (ربما مع المزيد من الإصدارات) حتى يتم استنفادها تماما مثل أي ميزانية أخرى.
وتُستخدم ميزانيات الأخطاء أيضًا في بعض المؤسسات للحالة الأقل سعادة، وهي الحالة التي لا تقوم فيها بعمل SLO الخاص بك. في هذه الحالة، قد تختار أن تفعل شيئا أكثر صرامة من مجرد "اتخاذ إجراء". لنفترض أن خدمتنا تواجه بعض المشكلات وقد ارتفعت بنسبة 60٪ فقط من الوقت كما هو موضح بواسطة SLI الذي اخترناه سابقًا. لم نحدد هدفنا (SLO). استنفدت خدمتنا ميزانية الخطأ الخاصة بها. قد تختار المؤسسة التراجع عن إصدار مخطط، لأنها تعلم أن اضطراب النظام بشكل أكبر في هذه المرحلة من المرجح أن يؤدي فقط إلى تفاقم حالة الموثوقية. عادة ما يتم حساب ميزانيات الخطأ لفترة زمنية محددة؛ شهر وربع وما إلى ذلك. على أساس متجدد، إذا تحسنت موثوقية الخدمة في النهاية، تعود تلك الميزانية إلي حالتها.
خلال هذا الوقت من الإصدارات المسورة، قد تختار المؤسسة محور بعض الموارد الهندسية بعيدا عن تطوير الميزات نحو عمل الموثوقية. بهدف المساعدة في الكشف عن مصدر المشكلات التي تسببت في نفخ الخدمة في SLO وتحسينها.
السبب الذي يجعلنا نقول "بعض المؤسسات" عندما يتعلق الأمر بميزانيات الأخطاء هو تنفيذها، خاصة في حالة استخدامها في عمليات النشر، يتطلب قبولًا مؤسسيًا معينًا. عند مواجهة قرار الإصدار، يجب أن تكون المؤسسة على استعداد لكبح الإصدار إذا لم تكن موثوقية الخدمة حتى الآن حتى الآن غير قابلة للتنقية. هذا القرار ليس قرارا ترغب جميع المنظمات في اتخاذه. هذا القرار ليس أيضا الاستجابة الوحيدة الممكنة لميزانية الخطأ المستنفدة، ولكنه الأكثر تحدثا عنه.
في وحدة منفصلة، نتحدث بمزيد من التفصيل عن SLIs وSLO وميزانيات الأخطاء. ولكن من المفيد هنا تسليط الضوء على جانب الدورة الفاضلة لهذه الممارسات. من الناحية النظرية، فإنه يوفر طريقة للمؤسسة لوصف موثوقية الخدمة والتواصل والعمل عليها. أثناء القيام بذلك بطريقة تجعل الجميع يعملون من أجل موثوقية أفضل. يمكن أن تكون حلقة التعليقات هذه مهمة للغاية.
الحلقة الفاضلة #2: تشريح الجثة بدون لوم
فكرة ما بعد الوفاة - التحليل الاستعادي لحدث مهم غير مأمول عادة - ليست خاصة حتى عن بعد بهندسة موثوقية الموقع. إنه أمر شائع في عالم العمليات. الشيء الوحيد الأقرب إلى أن يكون مميزًا هو إصرار هندسة موثوقية الموقع (SRE) على أن تشريح الجثة ينبغي أن يكون "بلا لوم". إنهم بحاجة إلى التركيز على فشل العملية أو التقنية أثناء الحادث، وليس على تصرفات أشخاص محددين. "ما هي العملية التي أجريناها والتي سمحت لـ X بفعل الشيء الذي أدى إلى الفشل؟ ما هي المعلومات التي لم تكن لدى هذا الشخص، أو حتى بارزة في الوقت الحالي والتي أدت به إلى الوصول إلى نتيجة خطأ؟ ما هي حواجز الحماية التي كان يجب أن تكون في مكانها بحيث لم يكن من الممكن أن يكون مثل هذا الفشل الكارثي؟" هذه الأسئلة هي الفرز الذي تم طرحه في تشريح الجثة بدون لوم.
إن فحوى هذه الأسئلة واتجاهها أمر بالغ الأهمية. نحن نبحث عن طرق لتحسين الأنظمة أو العمليات، وليس طرق لمعاقبة الأفراد الذين ساهم استخدامهم لتلك الأنظمة أو العمليات بحسن نية في الانقطاع. من المهم أن تتذكر "ليس من المنطقي أن تحرق طريقك في مسارك إلى الموثوقية". في تجربتنا، لا تتعلم المؤسسة التي تطلق النار على شخص في كل مرة يحدث فيها حادث إنتاج (مع استثناءات قليلة)، من تلك الحوادث. بدلا من ذلك، يتركون مع فرد واحد، يرتجف في الزاوية، ويخشى إجراء أي تغييرات على أي شيء على الإطلاق.
ولكن عملية ما بعد الوفاة التي تعمل بشكل جيد في منظمة تخلق حلقة فاضلة. فهو يتيح للمنظمة التعلم من انقطاعاتها وتحسين أنظمتها باستمرار (يتم توفير التحليل والمتابعة المناسبين).
هذه العلاقة بين الفشل والأخطاء التي تتبناها المؤسسة كفرص للتعلم والتحسين هي مبدأ أساسي لهندسة موثوقية الموقع. بناء حلقات فاضلة للاستفادة من هذه الفرص وتوجيه المؤسسة نحو مزيد من الموثوقية هو الشيء الأهم.
دعونا نستكشف بعض المبادئ والممارسات الأخرى، التي تركز على الجانب البشري من SRE، في وحدتنا التالية.