لو كتبنا سيناريو سريع كده: الساعة ١٠ الصبح .. الـtechnical support team بيبعت على slack بيقول ان فيه issue ان مش كل الـorders القديمة بتظهر للمستخدمين .. دي هنعتبرها urgent severity issue والتيم المسؤول عن user profile management محتاج يشتغل عليها .. ياترى التيم هيبدأ إزاي؟ 🧵⬇️

في الأول هتبقى مسؤولية الـengineering manager انه يـacknowledge الإيشو، ويبتدي يشوف مين أنسب أفراد في التيم تقدر تشتغل عليها، وبعدها هيبقى مطلوب منه يبلّغ الـtech support أو أي stakeholders متأثرين بالمشكلة بالتطورات أول بأول، وممكن برضه يـdelegate ده بس لازم يكون فيه شخص مسؤول

بعدها التيم هيبتدي يتحرك، والمبدأ الأهم هنا للتعامل مع أي production issue هي stop the bleeding .. مش وقته خالص نفكّر في حل المشكلة عن طريق كتابة كود للـfix، ده ترتيبه ييجي متأخر .. الأول نشوف لو فيه release نزلت بالليل مثلاً، او تغيير في أي service أو upgrade of caching service

وقتها فكرة الـrollback بتكون مطروحة بشدة، وبعدها طبعًا الأوبشن الأشهر على الإطلاق وهو restarting services بس طبعًا ده لو بناءً على خبرات قديمة ان ده ساعات بيحل المشكلة .. لو الإيشو لسه موجودة؟ كده الحلول السريعة قربت تخلص ونبدأ ندخل لمنطقة أعمق شوية

الحلول دي صعب تتعمل من غير ما يبقى السيستم فيه مستوى كويس من الـmonitoring and observability يخليك تشوف الـhealth بتاع كل سيرفس وهل هي أصلاً online ولا لأ وهل فيه logs بتقول ان فيه errors or warnings مع أي connection مثلاً .. لو ده مش موجود هيبقى بنجرّب عمياني واحنا وحظنا

الحلول السريعة خلصت، التيم هيبتدي يفكّر بشكل منظم أكتر .. هيبتدوا يشوفوا على الـdatabase في حالة كويسة وهل الـdata موجودة ولا لأ، طب هل ممكن ياخدوا read access على الـcollections اللي ليها علاقة بالمشكلة، طب هل ينفع ياخدوا masked dump منها، هل فيه أداة زي bigquery تساعدهم؟

بعدها تيجي مدرستين لحل المشكلات، الأولى هي trial and error والتيم بناءً على خبرته بيبتدي يشوف أي service or component فيه احتمالية كبيرة انها تكون السبب، ونبتدي نحاول نشوف ايه اللي اتغير او فين المشكلة .. الميزة انه بيخلينا نجرب أسرع ولكن بيقلل فرص النجاح كل ما الوقت بيعدّي علشان المشاكل اللي التيم بيتوقعها الأول بيبقى واثق فيها، بعد كل محاولة مش بينجحوا فيها كل ما الخطوة اللي بعدها بتكون ثقتهم فيها أقل .. في سياق موازي المفروض يبقى فيه حد بيتأكد ان الـissue مش بتحصل على staging مثلاً، وبيبعت يسأل لو حد عارف أساليب أحسن for troubleshooting

المدرسة التانية وهي elimination of variables وهي العكس، وبتعمد على انك بتستبعد الاحتمالات الأقل او بتجرّب حاجات بسرعة جدًا تخليك متأكد ان service A مش السبب وهكذا .. يعني مثلاً هنا عاوزين نتأكد بـapi call ان النتايج بترجع من الـbackend غلط وبكده نستبعد ان فيه مشكلة في الـfrontend

مع كل خطوة سريعة بتلاقي نفسك بتستبعد حاجة، والطريقة دي نتايجها أبطأ للأسف لو معندكش tools تساعدك تستبعد الاحتمالات بسرعة، وفي نفس الوقت هي مُرهقة وبتزوّد الضغط على التيم لو الوقت عدّى ومفيش نتايج واضحة .. صعب نستخدم التكتيك ده في أول الـprocess بس مع قلة الحلول بنبتدي نلجأ له ..

أثناء كل الخطوات دي، دور الـengineering manager او الشخص اللي هنسميه incident manager انه يفضل يرد على تساؤلات التيمز التانية ويصد الضغط عن التيم اللي شغال ويساعدهم لو فيه blockers او محتاجين access او معلومات زيادة تساعدهم .. كمان هتبقى ميزة لو يقدر يدخل معاهم call ويقترح حلول

بعد حل المشكلة، التيم اللي شغال عليها سواء التيم بتاع الجزء ده من البرودكت او تيم oncall انه يكتب تقرير باللي حصل وتأثير المشكلة والحلول اللي اتجربت او اتعملت ونجحت، وده اسمه في معظم الشركات postmortem .. ونفضل مراقبين المشكلة علشان لو حصلت تاني، ونعلن بعدها issue is resolved

ولو هنستخدم المثال اللي قولته في الأول، الأيشو دي نعتبرها urgent وممكن تبقى high في products معينة، وضروري ان الكل يتفق سواء product, engineering, tech support على تصنيف الإيشوز علشان مينفعش التيم كل مرة يسيب اللي شغال عليه ويروح يحل مشكلة على production علشان تتسلم في نفس اليوم

المثال ده بيمثل مشكلة في السيستم بس هو مايتصنفش outage وبالتالي اه لازم التيم يتحرك يشتغل عليها لأنها ممكن تقلل ثقة المستخدمين أو تخليهم مش عارفين يوصلوا لمعلومة مهمة .. طيب لو مش عارفين يعملوا share product link on whatsapp؟ أولوية أقل، ولو مش عارف أ-sort reviews؟ ممكن تستنى

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