راقب الوظيفة الظاهرة للمستخدم، وضيف أدلة كافية من الموارد والتطبيق لتشخيصها، واعمل تنبيه بس للحالات اللي محتاجة تدخل بشري في وقت مناسب. اربط كل تنبيه بمسؤول وخطوة أولى وتصعيد. أثناء الحادثة، نسّق التخفيف واحمي الأدلة وتحقق من الاستعادة من خلال رحلة المستخدم الفعلية.
ابدأ بالوظيفة المهمة
سيرفر بيرد على ping مش معناه إن تطبيقه شغال. اختار رحلة مستخدم تمثيلية غير ضارة، زي استرجاع صفحة عامة أو الوصول لنقطة اختبار مضبوطة. حدد شكل النجاح وتجنب الفحوصات الاصطناعية اللي بتنشئ طلبات حقيقية أو بتنشر محتوى أو بتبعت إشعارات للعملاء في كل تشغيل.
راقب من منظور خارجي مناسب وكذلك من جوه التطبيق. المراقبة الخارجية ممكن تكشف مشاكل وصول أو توجيه السيرفر مش شايفها. القياسات الداخلية ممكن تفسر ليه الرحلة فشلت. خلي المنظورين مرتبطين بالوظيفة بدل ما تجمع لوحة كبيرة لمجرد إن كل مقياس متاح.
اختار إشارات ليها قيمة تشخيصية
إرشادات Google SRE بتبرز زمن الاستجابة والمرور والأخطاء والتشبع كإشارات مفيدة للأنظمة المواجهة للمستخدم. استخدمها لوصف السلوك: زمن الرد وحجم الطلبات والطلبات غير الناجحة والضغط على الموارد المقيدة. اختار قياسات مناسبة للتطبيق بدل ما تفترض إن تعريف مقياس واحد ينفع لموقع وخدمة نقل وعامل خلفي.
افصل سلوك الطلبات الناجحة عن الفاشلة حيث يهم، وافحص نتائج الذيل البطيء بدل المتوسطات لوحدها. ضيف ضغط الذاكرة أو مساحة القرص أو عمق الطابور أو حدود خاصة بالتطبيق لما تفسر الخدمة. قراءة CPU عالية ممكن تكون طبيعية أثناء شغل دفعي مفيد؛ التأثير الظاهر للمستخدم هو اللي يحدد لو محتاج إجراء فوري.
ادي كل تنبيه إجراء ومسؤول
التنبيه لازم يوضح الوظيفة المتأثرة والحالة الملاحظة والفحص الأول المفيد. حدد مسؤول ومسار تصعيد قبل ما تنشره. فرّق بين الحالات اللي محتاجة تدخل فوري والعناصر المناسبة لمراجعة مجدولة. التنبيهات المتكررة منخفضة القيمة بتدرب المشغلين على تجاهل النظام وبتخلي الإشارات المهمة أصعب في التعرف عليها.
استخدم مراجعة تنبيهات صغيرة عشان تشيل الغموض. الجدول التوضيحي ده بيوصف قرارات مراقبة محتملة، مش تغطية دعم SwissOctet ولا التزام توافر. العتبات محتاجة تتختبر مقابل الأساس الفعلي للتطبيق. ضيف شرط استعادة عشان المشغل يعرف امتى التنبيه اتشال وإيه اللي لسه محتاج تحقق.
| الحالة الملاحظة | الاستجابة المفيدة | السياق اللي يتضمن |
|---|---|---|
| رحلة مستخدم تمثيلية بتفشل | قيّم التأثير وخفف | نقطة النهاية المتأثرة والمدة والتغيير الأخير |
| القرص قرب من حد مخطط | راجع النمو والاحتفاظ | الحجم ومعدل النمو والهامش الآمن |
| التحقق من النسخة الاحتياطية بيفشل | احمي مسار الاستعادة | المهمة وآخر نقطة قابلة للاستخدام والخطأ |
| زمن الاستجابة بيرتفع أثناء إصدار | افحص أو ارجع التغيير | الأساس ووقت الإصدار والطلبات المتأثرة |
جهّز هيكل حوادث صغير
عملية الاستجابة لازم تكون مفهومة تحت الضغط. حدد منسق وحد بيتعامل مع الشغل التقني وحد مسؤول عن التحديثات لما الحادثة تكون كبيرة بما يكفي لاحتياج أدوار منفصلة. مشروع صغير ممكن يدمج الأدوار، لكنه لسه بيستفيد من نقطة قرار واحدة واضحة. اتفقوا على قناة تواصل قبل ما الخدمة تفشل.
مواد استجابة الحوادث بتاعة Google بتركز على التنسيق ونهج التخفيف أولاً. طبّق ده بمقياس يناسب المشروع: حدد التأثير، اختار إجراءات آمنة وتجنب إن كذا مشغل يعملوا تغييرات متعارضة. سجّل خط زمني وقرارات. البحث عن تفسير مثالي مش المفروض يأخر إجراء آمن يرجع الوظيفة المتأثرة.
امشي في تدهور ملموس خطوة بخطوة
تخيل موقع بقى بطيء بعد إصدار. فحص خارجي بيوضح زيادة وقت الإكمال، بينما القياسات الداخلية بتوضح أخطاء تطبيق وشغل قاعدة بيانات متزايد. المنسق بيعلن حادثة محدودة، بيحمي الأدلة وبيوكل شخص واحد يقارن الإصدار بالأساس. حد تاني بيجهز مسار الرجوع المختبر بدل ما يعمل تغييرات بنية تحتية غير مرتبطة.
لو الرجوع آمن لحالة بيانات التطبيق، استخدمه وراقب النتيجة. لو مش آمن، اختار تخفيف أضيق مدعوم بخطة التشغيل. وثّق إيه اللي اتغير وامتى. VPS أكبر أو منفذ ممكن يستحق التقييم لاحقًا، لكن القرار الفوري لازم يعالج الأدلة بدل ما يفترض إن حجم البنية التحتية هو السبب.
احمي الأدلة وتحقق من الاستعادة
سجلات التشغيل وملاحظات الحوادث ممكن تحتوي على عناوين ومعرفات ومعلومات عملاء. اجمع اللي التحقيق محتاجه، حدد الوصول وخلي بيانات الاعتماد أو رموز الطلبات الخاصة بره التقارير المشتركة. لحادثة أمنية مشتبه بها، احفظ الأدلة المناسبة واتبع سياسة استجابة المشروع بدل ما تدمر المعلومات بتنظيف متسرع.
إرشادات استجابة الحوادث بتاعة NIST بتحط الاستجابة جوه إدارة مخاطر الأمن السيبراني الأوسع. الاستعادة بتشمل فحص الوظيفة المقصودة وحل الحالة اللي خلت الحادثة ممكنة. اختبر رحلة المستخدم، راجع سلوك الموارد وافحص الشغل الخلفي قبل ما تقفل الاستجابة. تنبيه اتشال أو عملية اتعاد تشغيلها لوحدهم ممكن ميثبتوش رجوع كامل لخدمة مفيدة.
حوّل الحادثة لتحسين قابل للقياس
اكتب مراجعة قصيرة للتأثير والخط الزمني والظروف المساهمة والإجراءات اللي اتخذت. ركز على التغييرات اللي ممكن تتحقق: حسّن فحص، صحح صلاحية، اتدرب على الرجوع أو ضيف تبعية استعادة ناقصة. حدد مسؤولين ومعايير إكمال. تجنب قائمة طويلة من النوايا الغامضة اللي محدش يقدر يأكد لاحقًا إنها اتنفذت.
لما تنشر على SwissOctet، خطط للمراقبة والاستجابة كجزء من تشغيل التطبيق، منفصل عن الهاردوير المختار وأي ترتيب إداري مؤكد. الكتالوج مش بيثبت وجود فريق حوادث مجهز أو ساعات دعم مستمرة. حدد مين بيستقبل التنبيهات ومين يقدر يتصرف وإيه اللي شروط الخدمة الفعلية بتغطيه قبل ما تعتمد على بيئة إنتاج.
قائمتك العملية.
- راقب رحلة مستخدم تمثيلية غير ضارة.
- اختار إشارات تفسر سلوك التطبيق.
- ادي التنبيهات إجراء ومسؤول وشرط استعادة.
- اتفق على التنسيق والتصعيد قبل الحادثة.
- احمي الأدلة وتحقق من الاستعادة الكاملة.
- حدد تحسينات قابلة للاختبار بعد المراجعة.
التفاصيل اللي تفرق.
مراقبة وقت تشغيل السيرفر كافية؟+
لا. جهاز ممكن توصله ممكن يستضيف تطبيق مكسور. راقب الوظيفة اللي المستخدمين بيعتمدوا عليها وضيف أدلة الموارد لتشخيص الأعطال.
كل عتبة مقياس لازم تنبه حد فورًا؟+
لا. احتفظ بالتدخلات العاجلة للحالات القابلة للتنفيذ اللي محتاجة انتباه في وقت مناسب. وجّه الشغل الأقل أولوية لعملية مراجعة بمسؤول واضح.
امتى الحادثة تخلص؟+
بعد ما يتم التحقق من الوظيفة المتأثرة والشغل الخلفي المرتبط، ويتم التعامل مع المخاطر الفورية وتسجيل إجراءات المتابعة. إعادة تشغيل العملية لوحدها مش كافية.
اذهب إلى المصدر.
تدعم هذه المراجع المفاهيم التقنية في هذا الدليل. اتبع الوثائق الحالية قبل تغيير نظام إنتاجي.
- Google SRE: مراقبة الأنظمة الموزعة sre.google
- كتاب Google SRE: استجابة الحوادث sre.google
- NIST SP 800-61 Rev. 3: استجابة الحوادث csrc.nist.gov
إرشاد تحريري من SwissOctet. الأمثلة توضيحية. يجب التحقق من مواصفات الخدمة والخيارات المتاحة والشروط التعاقدية بشكل منفصل.