نموذج الدعم

الدعم مُقسَّم إلى tiers، ويعمل ضمن ساعات العمل، ويقوده runbooks للمشاكل المعروفة — وليس on-call على مدار الساعة. بفريق من نحو ١٨ شخصًا، فإنّ وردية pager وعدٌ لا نقدر على الوفاء به، لذا لا نقطعه.

مستويات التصعيد

flowchart LR
  Client["Client<br/>primary contact"] --> L1["L1 — Technical Support<br/>Nidal Mohammad"]
  L1 --> L2["L2 — Team Lead"]
  L2 --> Dev["Original developer"]
  L1 -.expedite.-> Board["Bug on the board"]

الـ SLA

• ضمن ساعات العمل فقط. نستجيب ونعمل ضمن ساعات عملنا وفق الـ support retainer. لا on-call ليلي.
• جهة اتصال أساسية واحدة لكل عميل من طرفنا (غالبًا L1)، وجهة واحدة مُسمّاة من طرفهم. تصل الطلبات عبر هذه القناة، لا إلى الرسائل الخاصّة لأفراد المطوّرين.
• الـ severity هو ما يحدّد الاستجابة، لا ساعة لا نستطيع الالتزام بها. نظام production معطّل يُعالَج فورًا ضمن ساعات العمل؛ ومشكلة شكلية تُوضَع في الطابور.

ماذا يفعل كل tier

Tier	من	المهمة
L1	Technical Support (نضال)	triage، إعادة إنتاج المشكلة، مراجعة runbooks المشاكل المعروفة، الحل أو التوجيه.
L2	Team Lead	تشخيص أعمق، وامتلاك مسار الإصلاح، وإفادة الـ PM بحجم الجهد.
L3	Original developer	إصلاح على مستوى الكود حين يحتاج إلى من بناه.

من البلاغ إلى bug على الـ board

flowchart TD
  R["Something arrives<br/>client report, demo feedback, telemetry"] --> T{"L1 triage — impact first"}
  T -- production impact --> IC["Declare an incident<br/>set severity"]
  T -- known issue --> KB["Closed from the repo runbook"]
  T -- our defect, inside warranty --> BG["Bug — expedite lane, free"]
  T -- new or changed behaviour --> CR["Change request — priced"]
  IC --> MT["Mitigate, then resolve"]
  MT --> PMO["Blameless postmortem<br/>if severity requires it"]
  MT --> BG
  BG --> BD["Back into the build loop —<br/>failing test first, then the fix"]

الأثر يُقيَّم أولًا، والمسارات الأربعة متوازية لا متتابعة. لا ينتظر أحد جوابًا تجاريًا قبل إعلان حادثة: إن تأثّر الإنتاج انطلق ذلك المسار فورًا، وأي شخص يستطيع الإعلان. أمّا سؤال warranty مقابل billable فيُجاب في الاستقبال نفسه، لا قبله.

الشدّة (severity) تُحدَّد عند الاستقبال صراحةً. ولا تُستنتج لاحقًا من علوّ صوت الطلب — فتلك هي الطريقة التي تقفز بها مشكلة شكلية طابورًا لا تستحقّه.

يقوم L1 بعمل triage لكل بلاغ. المشكلة المعروفة تُغلَق من runbook الخاص بها. أمّا الـ defect الحقيقي فيصبح bug work item ويدخل الـ flow board عبر مسار الـ expedite — دون انتظار حدود الـ sprint. الطلب الجديد أو التغيير ليس bug؛ بل يُوجَّه كـ طلب تغيير — انظر حدّ الـ Warranty.

ملاحظة

سؤال «هل هذا علينا إصلاحه مجانًا أم أنّه billable؟» يُجاب عليه عند الـ triage، لا عند التسليم. يُشير إليه L1، والـ PM هو من يُقرّره — انظر من يملك ماذا. الخطأ فيه يُضعف إمّا الثقة وإمّا الهامش.