التكنولوجيا
الهندسة
DevOps
إدارة المشاريع
تطوير البرمجيات
الأداء
خطأ
النشر
SRE
قضايا الإنتاج
عدم تطابق البيانات
سواء bug حصلت، deployment اتنفذت غلط، مشكلة performance أو data inconsistency أو أي مشكلة تانية .. الـpostmortem document ده بنكتب فيه تفاصيل عن المشكلة علشان الـstakeholders وباقي التيم اللي ماشتغلش على الحلول يقدر يقراها وياخدوا بالهم من أسبابها أو يفهموا الحلول ..
تفاصيل زي: وقت حدوث المشكلة، مين اكتشفها؟ التيم ولا جالنا شكاوي من اليوزرز، المشكلة فضلت موجودة قد ايه، الـimpact بتاعها على البيزنس، خسرنا data؟ مين اللي حل المشكلة وأيه الـservices اللي احتاجت تغيير، الـtimeline بتاع كل حاجة بدايةً من اكتشاف المشكلة لحد ما الحل يبقى deployed..
بعدها نكتب تحليل لسبب حدوث المشكلة.. ممكن كود كان بيتعامل على ان حجم الداتا مش كبير، deployment كانت معتمدة على service بس محدش عملها deploy وقتها .. وبنكتب action items او الحاجات اللي محتاجين نعملها علشان نمنع تكرار المشكلة، مثلاً تبقى حجم الداتا على staging مشابه للـproduction
الـdocument ده المفروض يكون blameless ومش غرضه توجيه اللوم لأشخاص بعينها، ولكنه وسيلة علشان نفهم تفاصيل المشكلة ونتعلم منها .. كمان يتعمله review ونقدر نبعته لأي حد من الـstakeholders يفهمه فا لازم معظم الكلام يكون مفهوم ومش تكنيكال وبس غير في أجزاء معينة إنما الباقي واضح..
مين اللي بيكتبه؟ أي حد شارك في حل المشكلة او متابعتها المفروض يحط الـactions اللي عملها ولازم يكون فيه incident commander بيتأكد ان الكلام منطقي .. دي مقالات فيها شرح أكتر للموضوع مع أمثلة ظريفة من google ومن datadog:
datadoghq.com
sre.google
datadoghq.com
sre.google
حاجة أخيرة - كلمة postmortem جاية من الطب ومعناها تقريبًا تشريح الجثة بعد الوفاة لمعرفة الأسباب 😀 (لو هتعمل سيرش على الكلمة متنساش تكتب devops/sre/software engineering علشان ميطلعش صور طبية تُخض 😀) .. بس فعلاً الكلمة تنطبق على اللي بيحصل بعد ما بتحصل issue ونحلها ..
شكرًا 🙏🏻
شكرًا 🙏🏻
جاري تحميل الاقتراحات...