حالة الخدمة
كل الأنظمة تعمل بشكل طبيعي.
صفحة الحالة لا تساوي شيئاً ما لم تكن مستعدة لقول خبر سيئ. هذه الصفحة تُحدَّث أثناء العطل لا بعده، ما يعني أنك سترى أحياناً كلمة قيد التحقيق بجانب مكوّن بينما لا نعرف بعد السبب.
المكوّنات
| المكوّن | الحالة | الهدف | الآن |
|---|---|---|---|
| API | يعمل بشكل طبيعي | توافر بنسبة 99.9 بالمئة | لا أخطاء فوق الخط المرجعي خلال آخر 24 ساعة |
| التفعيل | يعمل بشكل طبيعي | وصول 99.5 بالمئة من الطلبات المدفوعة إلى ملف فعّال | الساعة المتحركة أعلى من الهدف، ووسيط التثبيت 41 ثانية |
| المدفوعات | يعمل بشكل طبيعي | الاعتماد والاسترداد التلقائي خلال 60 ثانية | مزود الدفع يبلّغ عن وضع طبيعي، والاستردادات تُنفَّذ في وقتها |
| بيانات التغطية | يعمل بشكل طبيعي | تحديث الأرقام المنشورة يومياً مع الالتزام بحد 25 عينة | آخر تحديث اكتمل، ولا يوجد بلد مخفي بسبب قِدَم البيانات |
| الدعم | يعمل بشكل طبيعي | أول رد خلال أقل من 60 ثانية، على مدار 24 ساعة | طابور الانتظار داخل الهدف في كل لغة لدينا فريق يغطيها |
يعمل بشكل طبيعي يعني أن المكوّن يحقق هدفه خلال الساعة المتحركة. وهذا ليس وعداً بشأن الساعة التالية.
99.5%
هدف نجاح التفعيل
60 ثانية
الاسترداد التلقائي عند فشل التفعيل
30 دقيقة
مدة العطل التي توجب تقرير مراجعة علنياً
72 ساعة
مهلة نشر ذلك التقرير
ماذا تعني كل حالة
| الحالة | ماذا تعني | ماذا نفعل |
|---|---|---|
| يعمل بشكل طبيعي | المكوّن يحقق هدفه خلال الساعة المتحركة | لا شيء. هذه هي الحالة العادية، وهي ليست وعداً بشأن المستقبل |
| أداء متدهور | يعمل، لكن أبطأ أو أقل ثباتاً من الهدف | نسميه على هذه الصفحة، ونتواصل مع العملاء المتأثرين، ونطبّق التعويض دون أن يطلبه أحد |
| انقطاع جزئي | يفشل لمجموعة يمكن تحديدها، مثل مشغّل واحد أو منطقة واحدة | نسمي المجموعة، ونمنع الشراء حيث سيفشل، وتُنفَّذ الاستردادات تلقائياً |
| انقطاع كبير | يفشل على نطاق واسع | يُعيَّن قائد استجابة، وينزل تحديث كل 30 دقيقة على الأقل حتى تُحل المشكلة |
| صيانة | عمل مخطط له بنافذة زمنية معروفة | يُعلن قبل 72 ساعة على الأقل، ويُجدول في أقل ساعات الاستخدام |
لا توجد حالة معناها على الأرجح كل شيء بخير. إما أن المكوّن يحقق هدفه، وإما أن اسمه مذكور على هذه الصفحة.
سياسة التعامل مع الأعطال
التزامان يحملان الأمر كله، وكلاهما مزعج عن قصد. الأول أننا نبلغ العملاء المتأثرين قبل أن يلاحظوا. والثاني أن كل عطل يتجاوز 30 دقيقة يحصل على تقرير مراجعة مكتوب يُنشر خلال 72 ساعة.
تقرير المراجعة يسمي الأنظمة والقرارات لا الموظفين، ويكتبه من كان في المناوبة نفسه، لا مدير يصف عمل شخص آخر.
وإن كنا سنتجاوز مهلة الـ 72 ساعة، ننشر التأخير وسببه داخل تلك الـ 72 ساعة، لأن مهلة فائتة يُعلن عنها متأخراً هي إخفاقان لا واحد.
- الاكتشاف آلي، من معدلات نجاح التفعيل ومن معدلات اعتماد المدفوعات، فيبدأ العطل حين تتحرك الأرقام لا حين يشتكي أحد
- حالة المكوّن على هذه الصفحة تتغير خلال خمس دقائق من الإعلان، قبل معرفة السبب
- قائد الاستجابة يدير المعالجة، وشخص آخر يتولى التواصل، حتى لا تلتهم إحدى المهمتين الأخرى
- نحدد العملاء المتأثرين ونتواصل معهم، ومعهم رصيد تعويض مُطبَّق فعلاً حيث تدهورت الخدمة، لا تعويض يُمنح عند الطلب
- نمنع الشراء في أي مسار نعرف أنه سيفشل، لأن أخذ مال سنضطر لرده أسوأ من خسارة عملية البيع
- أثناء أي انقطاع كبير ينزل تحديث كل 30 دقيقة على الأقل، حتى لو كان مضمون التحديث أننا ما زلنا لا نعرف
- خلال 72 ساعة من انتهاء العطل ننشر تقرير مراجعة يتضمن التسلسل الزمني، وأثر العطل على العملاء بالأرقام، والسبب، وكل إصلاح ومعه مسؤول وتاريخ
لماذا الهدف ليس مئة بالمئة
لأن هناك شبكة في المعادلة، ولأن مئة بالمئة ستكون كذبة. هدف تفعيل عند 99.5 بالمئة يقول بصوت عال إن نحو خمسة طلبات من كل ألف ستفشل في مكان ما بين الدفع والملف الفعّال.
المهم أن يكون مسار هذه الخمسة مصمماً سلفاً. الاسترداد ينفَّذ خلال 60 ثانية بلا تذكرة دعم، والرسالة تشرح ما حدث وما الذي يمكن تجربته بدلاً منه، ولا يحتاج أحد أن يقرر إن كان العميل يستحق ذلك.
المنطق نفسه ينطبق على التغطية. حين تزدحم شبكة شريكة في بلد نخدمه بأكثر من مشغّل، ننقلك بدل أن نسجل عطلاً، وتذكر الملاحظة أي نقل جرى.
وحين تكون هناك شبكة واحدة فقط ويكون يومها سيئاً، نقول ذلك في صفحة البلد. صفحات التغطية عندنا تنشر الوسيط وأبطأ عُشر وعدد العينات لهذا السبب بالضبط.
سجل الأعطال
لم يُعلن أي عطل يتجاوز 30 دقيقة في فترة التقرير الحالية.
قيمة هذه الجملة تساوي تماماً استعدادنا لتغييرها، ولهذا كُتبت السياسة أعلاه بهذا القدر من التفصيل. وكل تقرير مراجعة سابق يبقى منشوراً بشكل دائم بدل أن يختفي بعد تسعين يوماً.