فرض کنید سامانه فروش، ایمیل و بخشی از سرویس‌های شعب هم‌زمان دچار اختلال شده‌اند. ده‌ها Ticket مشابه ثبت می‌شود، مدیران در چند گروه پیام‌رسان وضعیت می‌پرسند، تیم شبکه یک علت را دنبال می‌کند و تیم Application علت دیگری را. اگر در این لحظه Incidentها فقط مثل Ticketهای عادی مدیریت شوند، زمان بازیابی بالا می‌رود و ارتباطات پراکنده می‌شوند.

Major Incident Management در ServiceDesk Plus باید برای چنین شرایطی طراحی شود: شناسایی سریع Incident بحرانی، تعیین Incident Commander، تجمیع ارتباطات، تخصیص نقش‌ها، ثبت Timeline، هماهنگی تیم‌های فنی و اجرای Post-Incident Review پس از بازگشت سرویس.

Major Incident چیست؟

Major Incident رویدادی با Impact و Urgency بالا است که اختلال قابل‌توجهی در سرویس‌های حیاتی ایجاد می‌کند و نیازمند پاسخ هماهنگ و سریع‌تر از Incident معمولی است. معیار باید بر اساس Business Impact تعریف شود، نه صرفاً تعداد تماس‌ها.

چرا Major Incident نباید فقط Priority=P1 باشد؟

اگر فقط Priority را بالا ببرید اما Role، Communication و Workflow تغییر نکند، تیم همچنان همان فرآیند Incident عادی را اجرا می‌کند. Major Incident نیازمند یک Operating Model جداگانه است.

اولین تصمیم: چه کسی Incident Commander است؟

Incident Commander نباید لزوماً فنی‌ترین فرد باشد. وظیفه او هماهنگی است: تعیین Workstreamها، حفظ Timeline، مدیریت Escalation، کنترل Communication و جلوگیری از تصمیم‌های متناقض.

نقش‌های پیشنهادی

• Incident Commander؛
• Technical Lead؛
• Communications Lead؛
• Service Owner؛
• Scribe یا Timeline Owner؛
• Vendor Coordinator در صورت نیاز.

ServiceDesk Plus چگونه مرکز هماهنگی می‌شود؟

ServiceDesk Plus می‌تواند Incident، SLA، Assignment، Task، Notification، Knowledge و Change را در یک جریان واحد نگه دارد. ارزش اصلی این است که «حقیقت عملیاتی» در Ticket و Timeline مرکزی ثبت شود، نه در چند کانال پراکنده.

تشخیص Major Incident باید تا حد ممکن Rule-based باشد

برای مثال می‌توان Ruleهایی بر اساس Service، Site، Impact، تعداد Incident مشابه یا Alert Monitoring تعریف کرد. هدف این است که تیم به‌جای تشخیص دستی دیرهنگام، Candidateهای Major Incident را سریع‌تر ببیند.

Link کردن Incidentهای مشابه

در یک Outage گسترده ممکن است صدها Ticket ثبت شود. به‌جای حل مستقل هر Ticket، بهتر است Incidentهای مشابه به Parent یا Major Incident مرتبط شوند تا Communication و Closure هماهنگ بماند.

Communication مهم‌تر از چیزی است که تیم فنی تصور می‌کند

در Incident بحرانی، Stakeholderها نیاز دارند بدانند چه اتفاقی افتاده، چه سرویس‌هایی تحت‌تأثیرند، تیم چه کاری انجام می‌دهد و Update بعدی چه زمانی است.

Alert-to-Incident را کنترل کنید

Monitoring ممکن است ده‌ها Alert برای یک Failure تولید کند. اگر هر Alert یک Ticket بسازد، Service Desk به‌جای کمک به Incident، Noise تولید می‌کند. Correlation، Deduplication و Parent Incident باید در Integration لحاظ شوند.

برای اتصال Monitoring به ITSM، مقاله SNMP Trap و Syslog در OpManager نمونه‌ای از طراحی Alert-to-Ticket را توضیح می‌دهد.

War Room یا Swarming چه نقشی دارد؟

در Major Incident، تیم‌های مختلف باید سریع کنار هم قرار گیرند. Swarming یعنی به‌جای Escalation خطی Tier 1→Tier 2→Tier 3، افراد لازم هم‌زمان وارد حل مسئله شوند. ServiceDesk Plus می‌تواند مرجع Incident و Taskها باشد و ابزار Collaboration نقش کانال گفت‌وگو را بازی کند.

Emergency Change را از Incident جدا نگه دارید

اگر برای Recovery لازم است Firewall Rule، Configuration یا Application Deployment تغییر کند، آن Change باید ثبت شود. Incident توضیح می‌دهد «چه چیزی خراب است» و Change توضیح می‌دهد «چه تغییری برای اصلاح انجام شد».

مقاله Risk Scoring در ServiceDesk Plus برای طراحی Change Risk و تصمیم CAB مکمل این فرآیند است.

Timeline چرا حیاتی است؟

بعد از Incident، حافظه افراد قابل اعتماد نیست. Timeline باید شامل Alert اولیه، اولین گزارش کاربر، Escalation، تصمیم‌ها، Changeها، Recovery و Closure باشد.

Post-Incident Review چه چیزی باید تولید کند؟

• Impact واقعی؛
• Duration؛
• Root Cause یا Cause Chain؛
• چه چیزی خوب عمل کرد؛
• چه چیزی کند یا مبهم بود؛
• Action Item با Owner و Due Date؛
• Knowledge Article یا Runbook جدید؛
• Problem Record در صورت نیاز.

Major Incident و Problem Management

Recovery سریع پایان کار نیست. اگر Root Cause هنوز قطعی نیست یا احتمال تکرار وجود دارد، Problem Record باید ایجاد شود تا RCA خارج از فشار Incident ادامه پیدا کند.

KPIهای مفید

• MTTA؛
• MTTR؛
• زمان تا اعلام Major Incident؛
• زمان تا اولین Stakeholder Update؛
• تعداد Incidentهای تکراری مرتبط؛
• درصد Action Itemهای PIR بسته‌شده؛
• نرخ تکرار Major Incident مشابه.

سناریوی عملی

1. Monitoring و کاربران Outage را گزارش می‌کنند.
2. Incident به‌عنوان Major Incident طبقه‌بندی می‌شود.
3. Incident Commander و Technical Lead تعیین می‌شوند.
4. Ticketهای مشابه Link می‌شوند.
5. Initial Communication ارسال می‌شود.
6. Workstreamهای Network، App و Database ایجاد می‌شوند.
7. در صورت نیاز Emergency Change ثبت می‌شود.
8. سرویس بازیابی و Monitoring تأیید می‌شود.
9. Recovery Notice ارسال می‌شود.
10. PIR و Problem Record ایجاد می‌شوند.

چک‌لیست آمادگی

• تعریف Major Incident مستند است.
• Incident Commander مشخص است.
• Communication Template آماده است.
• Escalation Matrix به‌روز است.
• Integration Monitoring Deduplication دارد.
• Emergency Change Flow تعریف شده است.
• Stakeholder List مشخص است.
• PIR Template آماده است.
• Runbookهای سرویس‌های حیاتی وجود دارند.
• فرآیند دوره‌ای تمرین می‌شود.

نکات کلیدی

• Major Incident فقط Priority بالا نیست.
• Incident Commander نقش هماهنگ‌کننده دارد.
• Communication باید زمان‌بندی‌شده و مرکزی باشد.
• Ticketهای مشابه باید Link شوند.
• Emergency Change و Incident باید Traceability جدا داشته باشند.
• Recovery بدون PIR و Problem Management ناقص است.

منابع

• ManageEngine ServiceDesk Plus — Incident Management
• ManageEngine ServiceDesk Plus — Product Overview
• ManageEngine — Major Incident Management

سخن پایانی

در بحران، سرعت مهم است اما سرعت بدون هماهنگی می‌تواند Incident را طولانی‌تر کند. ServiceDesk Plus می‌تواند مرکز ثبت و هماهنگی Major Incident باشد؛ از Assignment و Timeline تا Communication، Change و PIR.

مدانت خدمات لایسنس ServiceDesk Plus، طراحی Major Incident Process، Workflow، Integration با Monitoring، سفارشی‌سازی، آموزش، استقرار و پشتیبانی ارائه می‌کند. برای بررسی راهکار به صفحه ServiceDesk Plus مدانت یا تماس با مدانت مراجعه کنید. همچنین منابع تخصصی Service Desk مدانت برای طراحی فرآیندهای ITSM در دسترس است.