# [Arabic] Production issues and how engineering teams deal with them.

<section class="arabic-content">
<div class="arabic-content">لو كتبنا سيناريو سريع كده: الساعة ١٠ الصبح .. الـtechnical support team بيبعت على slack بيقول ان فيه issue ان مش
 كل الـorders القديمة بتظهر للمستخدمين .. دي هنعتبرها urgent severity issue والتيم المسؤول عن user profile management محتاج يشتغل عليها .. ياترى التيم هيبدأ إزاي؟ 🧵⬇️
</div><br/>
<div class="arabic-content">
في الأول هتبقى مسؤولية الـengineering manager انه يـacknowledge الإيشو، ويبتدي يشوف مين أنسب أفراد في التيم تقدر تشتغل عليها، وبعدها هيبقى مطلوب منه يبلّغ الـtech support أو أي stakeholders متأثرين بالمشكلة بالتطورات أول بأول، وممكن برضه يـdelegate ده بس لازم يكون فيه شخص مسؤول
</div><br/>
<div class="arabic-content">
بعدها التيم هيبتدي يتحرك، والمبدأ الأهم هنا للتعامل مع أي production issue هي stop the bleeding .. مش وقته خالص نفكّر في حل المشكلة عن طريق كتابة كود للـfix، ده ترتيبه ييجي متأخر .. الأول نشوف لو فيه release نزلت بالليل مثلاً، او تغيير في أي service أو upgrade of caching service
</div><br/>
<div class="arabic-content">
وقتها فكرة الـrollback بتكون مطروحة بشدة، وبعدها طبعًا الأوبشن الأشهر على الإطلاق وهو restarting services بس طبعًا ده لو بناءً على خبرات قديمة ان ده ساعات بيحل المشكلة .. لو الإيشو لسه موجودة؟ كده الحلول السريعة قربت تخلص ونبدأ ندخل لمنطقة أعمق شوية
</div><br/>
<div class="arabic-content">
الحلول دي صعب تتعمل من غير ما يبقى السيستم فيه مستوى كويس من الـmonitoring and observability يخليك تشوف الـhealth بتاع كل سيرفس وهل هي أصلاً online ولا لأ وهل فيه logs بتقول ان فيه errors or warnings مع أي connection مثلاً .. لو ده مش موجود هيبقى بنجرّب عمياني واحنا وحظنا
</div><br/>
<div class="arabic-content">
الحلول السريعة خلصت، التيم هيبتدي يفكّر بشكل منظم أكتر .. هيبتدوا يشوفوا على الـdatabase في حالة كويسة وهل الـdata موجودة ولا لأ، طب هل ممكن ياخدوا read access على الـcollections اللي ليها علاقة بالمشكلة، طب هل ينفع ياخدوا masked dump منها، هل فيه أداة زي bigquery تساعدهم؟
</div><br/>
<div class="arabic-content">
بعدها تيجي مدرستين لحل المشكلات، الأولى هي trial and error والتيم بناءً على خبرته بيبتدي يشوف أي service or component فيه احتمالية كبيرة انها تكون السبب، ونبتدي نحاول نشوف ايه اللي اتغير او فين المشكلة .. الميزة انه بيخلينا نجرب أسرع ولكن بيقلل فرص النجاح كل ما الوقت بيعدّي علشان المشاكل اللي التيم بيتوقعها الأول بيبقى واثق فيها، بعد كل محاولة مش بينجحوا فيها كل ما الخطوة اللي بعدها بتكون ثقتهم فيها أقل ..
*في سياق موازي* المفروض يبقى فيه حد بيتأكد ان الـissue مش بتحصل على staging مثلاً، وبيبعت يسأل لو حد عارف أساليب أحسن for troubleshooting 
</div><br/>
<div class="arabic-content">
المدرسة التانية وهي elimination of variables وهي العكس، وبتعمد على انك بتستبعد الاحتمالات الأقل او بتجرّب حاجات بسرعة جدًا تخليك متأكد ان service A مش السبب وهكذا .. يعني مثلاً هنا عاوزين نتأكد بـapi call ان النتايج بترجع من الـbackend غلط وبكده نستبعد ان فيه مشكلة في الـfrontend
</div><br/>
<div class="arabic-content">
مع كل خطوة سريعة بتلاقي نفسك بتستبعد حاجة، والطريقة دي نتايجها أبطأ للأسف لو معندكش tools تساعدك تستبعد الاحتمالات بسرعة، وفي نفس الوقت هي مُرهقة وبتزوّد الضغط على التيم لو الوقت عدّى ومفيش نتايج واضحة .. صعب نستخدم التكتيك ده في أول الـprocess بس مع قلة الحلول بنبتدي نلجأ له ..
</div><br/>
<div class="arabic-content">
أثناء كل الخطوات دي، دور الـengineering manager او الشخص اللي هنسميه incident manager انه يفضل يرد على تساؤلات التيمز التانية ويصد الضغط عن التيم اللي شغال ويساعدهم لو فيه blockers او محتاجين access او معلومات زيادة تساعدهم .. كمان هتبقى ميزة لو يقدر يدخل معاهم call ويقترح حلول
</div><br/>
<div class="arabic-content">
بعد حل المشكلة، التيم اللي شغال عليها سواء التيم بتاع الجزء ده من البرودكت او تيم oncall انه يكتب تقرير باللي حصل وتأثير المشكلة والحلول اللي اتجربت او اتعملت ونجحت، وده اسمه في معظم الشركات postmortem .. ونفضل مراقبين المشكلة علشان لو حصلت تاني، ونعلن بعدها issue is resolved
</div><br/>
<div class="arabic-content">
ولو هنستخدم المثال اللي قولته في الأول، الأيشو دي نعتبرها urgent وممكن تبقى high في products معينة، وضروري ان الكل يتفق سواء product, engineering, tech support على تصنيف الإيشوز علشان مينفعش التيم كل مرة يسيب اللي شغال عليه ويروح يحل مشكلة على production علشان تتسلم في نفس اليوم
</div><br/>
<div class="arabic-content">
المثال ده بيمثل مشكلة في السيستم بس هو مايتصنفش outage وبالتالي اه لازم التيم يتحرك يشتغل عليها لأنها ممكن تقلل ثقة المستخدمين أو تخليهم مش عارفين يوصلوا لمعلومة مهمة .. طيب لو مش عارفين يعملوا share product link on whatsapp؟ أولوية أقل، ولو مش عارف أ-sort reviews؟ ممكن تستنى
</div><br/>
<div class="arabic-content">
💡 تقدروا تلاقوا تفاصيل ومناقشات أكتر حول الموضوع ده في [الـthread](https://twitter.com/muhammadhani89/status/1578500056625258496?s=20&t=A929SlgRByaTUvCLQzKc3A) ده على twitter، شكرًا ..
</div><br/>
<div class="arabic-content">