[Arabic] How to write a Software Incident Post-Mortem?
![[Arabic] How to write a Software Incident Post-Mortem?](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fstock%2Funsplash%2Fc8d11c51f8def4ee3424366713ad663c.jpeg&w=3840&q=75)
Head of Engineering @Thndr. Passionate about managing teams, growing leaders, and building products that matter. Husband. Father. Madridista. Opinions are my own.
Search for a command to run...
![[Arabic] How to write a Software Incident Post-Mortem?](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fstock%2Funsplash%2Fc8d11c51f8def4ee3424366713ad663c.jpeg&w=3840&q=75)
Head of Engineering @Thndr. Passionate about managing teams, growing leaders, and building products that matter. Husband. Father. Madridista. Opinions are my own.
No comments yet. Be the first to comment.
In this series, I will put down all the technical threads I used to publish on Twitter since 2021.
معظم الشركات بتعمل التقييم السنوي في الميعاد ده من السنة، وعامةً وقت التقييم أيًا كان هو امتى وبيحصل كل قد ايه بيبقى وقت مش لطيف والأجواء مكهربة والناس قلقانة او متضايقة لو الدنيا مشيت وحش.. لو عندك الميتينج ده او انت شخص مسؤول عن فريق محتاج تاخد بال...
How much money does your application need per month to give users the services they need at the right standards of performance and reliability? And what is the least amount of money your team would need when scaling the system down and just keeping t...

ازاي تقيس انتاجيتك وكفائتك في الشغل حتى لو شركتك/الفريق/مديرك مش مهتمين انهم يوضحوا ده أو مش مهتمين يعرفوا؟ الأرقام اللي من نوع "كام ticket خلصتها في أسبوع" وغيرها من الأرقام المشتقة من مبادئ الـagile بيتم استخدامها بشكل غلط طيب ازاي أحدد انا باشتغل ...
![[Arabic] Productivity and Performance Metrics that you should measure](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fstock%2Funsplash%2FJKUTrJ4vK00%2Fupload%2F9d80779c869f5b24eb0ca09c98243aae.jpeg&w=3840&q=75)
One of the great takeaways from Andrew S. Grove’s “High Output Management” book, which I read a couple of years ago and am reading again now, is that it sheds some light on the common similarities between production or assembly lines and software eng...

هاتكلم النهاردة عن The Cobra Effect, Parkinson's Law وحاجات تانية: في واحدة من الشركات اللي اشتغلت فيها، كانت فيه مشكلة كبيرة وهي إن معظم المشاريع اللي بنتفق اننا نسلمها في مواعيد محددة بتتأخر، وأسباب التأخير وقتها كانت متنوعة بين ضغط الشغل والوقت مش...
![[Arabic] How can good intentions to solve a problem cause bigger ones?](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fstock%2Funsplash%2FY0I5DEbx8ck%2Fupload%2Ff1423c237b01589581b68a42fb976116.jpeg&w=3840&q=75)
من الغلطات المعروفة اللي بيقع فيها أي حد بيروح شغل جديد انه يكون مستعجل على انه يعمل impact/تأثير على الجزء اللي بيشتغل فيه.. ده مش غلط في المطلق ولكن ممكن يسبب شوية مشاكل تحصل بدري ومن غير ما ياخد باله ولا يبقى مستعد، هاتكلم على كام نقطة شوفتها بتحص...
![[Arabic] Navigating the early days of a new Job: Mistakes to avoid and Details to pay attention to](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fstock%2Funsplash%2FwNz7_5EvUWU%2Fupload%2Fdb11679e01703020094ed6406d29777f.jpeg&w=3840&q=75)
ممكن تكون سمعت كلمة 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، شكرًا ..