ممكن تكون سمعت كلمة postmortem أو عدت عليك وأنت بتقرا حاجة متعلقة بالـSRE أو الـDevOps أو بالتعامل مع production issues - وهي باختصار معناها تسجيل وتحليل كل التفاصيل اللي حصلت وقت حدوث مشكلة على production environment وإتأثر بيها البيزنس أو مُستخدمي الخدمة اللي بتقدمها ..

سواء 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:

https://www.datadoghq.com/blog/incident-response-with-datadog/

https://sre.google/sre-book/postmortem-culture/

💡 تقدروا تلاقوا تفاصيل ومناقشات أكتر حول الموضوع ده في الـthread ده على twitter، شكرًا ..