تولّ مسؤولية الخدمة بعد النشر
مكتملحدّد مؤشرات خدمة مفيدة وقرارات الحوادث والاستعادة والصيانة. أبقِ المسؤولية التشغيلية ظاهرة بعد انتهاء توليد الشيفرة.
تحقّق من فهمكيعيد فحص توافر HTTP 200، لكن ملفات التصدير لا تحتوي سجلات بسبب خلل في التخويل. ماذا يوضح ذلك؟نفّذ التمرين
ما ستتعلّمه
- تحديد مؤشر خدمة من منظور المستخدم.
- فصل تنسيق الحادث عن البحث التقني.
- تخطيط الصيانة والاستعادة كمسؤوليتين مستمرتين.
عرّف الخدمة التي يعتمد عليها المستخدمون
يجعل النشر البرمجيات متاحة. ويحافظ التشغيل على فائدتها مع تغيّر المستخدمين والتبعيات وحركة المرور والمتطلبات. لا يزيل مولّد الشيفرة هذا العمل المستمر.
في تصدير بيانات عملاء خيالي، يحتاج المستخدمون إلى أكثر من صفحة يمكن الوصول إليها. يحتاجون إلى السجلات المسموح بها بالتنسيق المطلوب خلال وقت مقبول. ويحتاجون أيضاً إلى منع الخدمة الوصول إلى بيانات مؤسسة أخرى.
سمّ المسؤول قبل الإصدار. سجّل من يستجيب خارج ساعات العمل المعتادة إذا كان ذلك جزءاً من التزام الخدمة. يستطيع مورّد تنفيذ بعض العمل، لكن المؤسسة تظل محتاجة إلى مسار واضح للقرارات والتواصل.
اختر مؤشرات تدعم الإجراء
يقيس مؤشر مستوى الخدمة، أو SLI، خاصية محددة لسلوك الخدمة. ويضع هدف مستوى الخدمة، أو SLO، قيمة مستهدفة لذلك المؤشر خلال فترة معلنة. اختر الهدف من احتياجات المستخدمين والقدرات التشغيلية.
تشرح إرشادات SRE من Google هذا النهج واستخدام ميزانية أخطاء في قرارات الموثوقية. لا تنسخ هدف خدمة أخرى دون فحص معناه. إرشادات SLO، مثال سياسة ميزانية الأخطاء.
للتصدير، عرّف ما يُعد طلباً مؤهلاً ناجحاً. افصل الرفض المتوقع عن إخفاقات النظام. وثّق الاستثناءات حتى لا يتحسّن مقياس بمجرد إخفاء الطلبات الصعبة.
| المؤشر | ما يساعد على كشفه | حد مهم |
|---|---|---|
| فحص التوافر العام | تعذّر الوصول إلى الخدمة | لا يتحقق من سير عمل بعد تسجيل الدخول |
| إكمال التصدير وزمنه | فشل الطلبات المؤهلة أو استغراقها وقتاً طويلاً | يحتاج إلى تعريف دقيق للنجاح |
| فحوص رفض التخويل | تراجع حد حرج | تغطي الشروط المختبرة |
| مؤشرات الموارد والتبعيات | سبب داخلي مرجح | لا تصف الأثر على المستخدم بمفردها |
تجنّب تسجيل ملفات تصدير كاملة لتحسين الرؤية. اجمع أقل قدر من المعلومات اللازمة لتشخيص المشكلة، واحمِ الوصول إليها.
جهّز الاستجابة للحوادث
حدّد من ينسّق ومن يبحث ومن يتواصل. يمكن جمع الأدوار في فريق صغير، لكن يجب أن تبقى المسؤوليات واضحة. احتفظ بسجل للملاحظات والأفعال.
تؤكد إرشادات Google للاستجابة للحوادث التنسيق والتواصل إلى جانب التخفيف التقني. قد يترك إصلاح صحيح تقنياً المستخدمين دون معلومات، أو عدة مستجيبين يجرون تغييرات متعارضة. الاستجابة للحوادث.
يستطيع وكيل تلخيص السجلات أو مقارنة الفرضيات ضمن حدود بيانات معتمدة. ويجب ألا يكتسب صلاحيات إنتاج غير مقيّدة لأن الحادث عاجل. استخدم مسار تصعيد محدداً للوصول الاستثنائي.
تدرّب على الاستعادة وموّل الصيانة
اختبر إجراء الاستعادة ببيانات خيالية تمثّل الواقع. حدّد ما لا يستطيع التراجع عن الشيفرة استعادته أو إلغاء أثره، مثل السجلات المحذوفة أو الرسائل التي أُرسلت بالفعل. سجّل الوقت والمعلومات اللازمين لاستعادة الخدمة.
أسند العمل المستمر: تحديثات التبعيات ومراجعات الوصول وتجديد الشهادات حيث ينطبق وتغييرات السعة وتصحيحات التوثيق. تتراكم التزامات خدمة لا موارد مخصصة لصيانتها بعد انتهاء ميزانية إطلاقها.
بعد حادث، اختر تحسينات تعالج الأسباب الملاحظة. اربطها بالتنفيذ والتحقق. يغلق هذا دورة الحياة: تغيّر الأدلة التشغيلية ما يحدّده الفريق ويبنيه تالياً.
نفّذ التمرين
اكتب ملاحظة تشغيل من صفحة واحدة لتصدير بيانات العملاء الخيالي. أدرج مؤشراً واحداً يتعلق بتجربة المستخدم وقيمته المستهدفة ومتلقياً للتنبيه واستجابة أولى آمنة وحداً للاستعادة ومسؤول صيانة. بيّن ما لا تستطيع المراقبة كشفه.
تنزيل ورقة العمل (Markdown)يؤدي إلغاء هذا الاختيار إلى حذف كل التقدم المحفوظ في هذا المتصفح.
يبقى تقدمك في هذا المتصفح. دون حساب أو تتبّع.
المصادر وقراءات إضافية
- Google SRE: Implementing SLOs ↗
- Google SRE: Incident Response ↗
- Google SRE: Example Error Budget Policy ↗