در این مقاله می خوانید:
صبح روز شنبه است و همه‌چیز ظاهراً در میز خدمات سازمان شما کاملاً عادی است. ناگهان، شما یک تیکت هشدار دریافت میکنید که یک سرویس حیاتی از کار افتاده و در عرض ۱۵ دقیقه‌ی آینده شما مورد آماج هجوم تیکتهایی میشوید که همان موضوع را گزارش میدهند. این میتواند این باشد که وب‌سایت شما ازکارافتاده است، نرم‌افزار فروش متوقف‌شده است، یا چیزی حتی گسترده‌تر، مانند سقوط بورس اوراق بهادار یا سقوط هواپیما. هنگامی‌که کسب‌وکار شما به‌شدت تحت تأثیر قرار می‌گیرد یک مسئله فناوری اطلاعات باعث از دست دادن درآمد و یا شهرت سازمان میشود و این یعنی، شما یک حادثه بزرگ در دست خود دارید.
نحوه واکنش شما به یک حادثه بزرگ: تفاوت‌ها در به حداقل رساندن تأثیر حادثه و بازگرداندن خدمات است.
می‌گویند، زمان پول است اما در این مورد بحرانی بخصوص، این نمی‌تواند خیلی درست باشد. زمان در این حالت چیزی فراتر از پول است!
اگر سازمان شما یک فرایند مدیریت حوادث عمده (MIM) یاMajor Incident Management ندارد شما نمی‌توانید به‌سرعت به حوادث بزرگ پاسخ و آن را حل‌وفصل کنید. اگر چنین فرایندی را در محل ندارید، وقت آن است که یک برنامه واکنش اضطراری تهیه کنید، تا به‌عنوان یک فرایند پاسخ به حادثه بزرگ شناخته شود.
خطرات یک حادثه بزرگ بالاتر از هر چیزی است تصوور کنید صدها سرویس عالی ارایه میکنید اما یک حادثه بزرگ تمام زحماتتان را میسورد و میبرد.
طبق مطالعه‌ای که توسط مشاوره اطلاعات فناوری اطلاعات انجام‌شده، ۹۸ درصد از سازمان‌ها بطور میانگین حداقل ۵۰٫۰۰۰٫۰۰۰ تومان فقط در یک ساعت خرابی از دست میدهند. بنابراین میشود جلوی این ضرر هنگفت مالی را هم گرفت اگر اهمیت ایجاد یک فرایند MIM را به‌طور مؤثر و کارآمد برای مقابله با حوادث بزرگ درک کرده باشید.
هر سازمانی قصد دارد حوادث بزرگ را از بین ببرد، اما جلوگیری از حوادث بزرگ به‌طور کامل غیرممکن است و تنها کاری که می‌توانید انجام دهید این است که برای آن‌ها آماده باشید.
در این راهنما، ما به چگونگی راه‌اندازی یک فرایند MIM مؤثر، اشتباهات رایجی که میتواند بر MIM سازمان شما تأثیر بگذارد و بهترین تمرینات برای بهبود فرایند MIM نگاهی مفصل انداخته‌ایم.
یک حادثه بزرگ چه حادثه ای است؟
یک حادثه بزرگ یک مسئله فوری و با تأثیر بالا است که معمولاً کل سازمان یا بخش عمده‌ای از آن را تحت تأثیر قرار می‌دهد.
یک حادثه بزرگ تقریباً همیشه منجر به در دسترس رفتن خدمات سازمان میشود، که باعث میشود کسب‌وکار لطمه شدیدی بخورد و درنهایت بر جایگاه مالی و شهرت و شیوه ارایه خدمت آن تأثیر میگذارد.
حوادث بزرگ(عمده) دارای ۴ مرحله اصلی هستند، یعنی:
فرایند مدیریت حادثه بزرگ برای سازمان‌ها بسیار حیاتی و ضروری است، زیرا به آن‌ها کمک میکند تا تأثیر کسب‌وکار یک حادثه بزرگ را به حداقل برسانند. فرایند اصلی مدیریت حادثه در درجه اول شامل مراحل زیر است:
مرحله ۱: شناسایی
اعلام حادثه بزرگ:
اولین قدم، شناسایی حوادث احتمالی است. برای سازمان‌ها مهم است که روش‌های متعددی برای شناسایی تهدیدات داشته باشند. حوادث بزرگ را می‌توان توسط تکنسین‌ها پرچم گذاری کرد، زمانی که آن‌ها در سراسر شبکه مورد آماج تیکت های غیرمعمول قرار می‌گیرند، یا توسط کارشناسن NOC که ناظر ابزارهای نظارت بر شبکه هستند میتواند شناسایی شود یا به‌طور خودکار یک ابزار قاردست یک مسئله شبکه را پرچمگذاری کند و یک تیکت برای هشدار دادن به میز خدمات ارسال نماید. سازمان‌ها همچنین می‌توانند یک خط تلفن اختصاصی برای کارکنان میز خدمات ایجاد کنند برای نشان دادن حوادث بزرگ مشکوک.
اطلاع‌رسانی به ذینفعان:
هنگامی‌که یک حادثه بزرگ شناسایی‌شد، باید به تمام ذینفعان کلیدی اطلاع داده شود. چهار گروه اصلی وجود دارد که باید از حوادث مهم مطلع شوند:
مرحله ۲: مهار
جمع‌آوری تیم حادثه بزرگ
تیم مدیریت حادثه بزرگ MIT یا Major Incident Team باید فوراً گرد هم بیایند. این تیم به‌طور خلاصه شامل خود مدیر حادثه بزرگ، تکنسین‌ها، مدیران سطح خدمات و سایر ذینفعان کلیدی است. گاهی اوقات کارکنان خارجی بسیار ماهر برای مقابله با یک حادثه بزرگ آورده می‌شوند. MIT باهم آنان برای یافتن یک راه‌حل برای حادثه بزرگ و بازگرداندن عملیات به حالت عادی کار میکند و این نقش مهم برای اوست.
راه‌اندازی یک پل کنفرانس
یک پل کنفرانس، که بیشتر به‌عنوان یک کنفرانس تلفنی شناخته میشود، به عیب‌یابی مؤثر و ارتباطات متمرکز کمک میکند. این به‌عنوان یک کانال ارتباطی روشن و سریع بین اعضای MIT عمل میکند.
آماده‌سازی یک اتاق جنگ تعیین‌شده
داشتن یک اتاق جنگ تعیین‌شده به همه اعضای MIT اجازه می‌دهد تا این حادثه را جمع‌آوری و عیب‌یابی کنند. این امر تلاش‌های همکاری را افزایش می‌دهد و به MIT کمک میکند تا سریع‌تر راه‌حلی پیدا کند.
ایجاد یک تیکت مشکل برای شناسایی مسائل اساسی
یک تیکت مشکل میتواند برای کشف و درک علت اصلی حادثه بزرگ ایجاد شود. این میتواند به جلوگیری از حوادث بزرگ مشابه در آینده با پرداختن به علل حادثه بزرگ کمک کند.
مرحله ۳: Resolution
اجرای طرح Resolution به‌عنوان یک تغییر
این یک عمل خوب برای اجرای اصلاح حادثه بزرگ به‌عنوان یک تغییر است تا اطمینان حاصل شود که قطعنامه به‌درستی مستند و اجرا میشود. اجرای قطعنامه به‌عنوان یک تغییر، خطر اختلال در حل‌وفصل شکست‌خورده را به حداقل می‌رساند.
مرحله ۴: تعمیر و نگهداری
انجام یک بررسی پس از پیاده‌سازی
مهم است که این حادثه را در یک دوره زمانی ارزیابی کنید تا مطمئن شوید که واقعاً حل‌شده است. اگر مسائل اساسی حل‌نشده باقی بماند، میتواند منجر به یک حادثه بزرگ دیگری شود.
تولید مستندات روشن
مستندسازی کل فرایند حل‌وفصل حادثه بزرگ به سازمان کمک میکند تا برای حوادث مشابه در آینده آماده شود. با مستندسازی مناسب حوادث گذشته، سازمان میتواند راه‌حل آزمایش‌شده و آزمایش‌شده را اجرا کند. آن هم بلافاصله پس از مواجهه با یک حادثه بزرگ مشابه.
معیارهای اندازه‌گیری
اندازه‌گیری عملکرد میز خدمات به اندازه‌گیری اثربخشی آن و فرایند MIM کمک میکند. برخی از معیارهای مهم برای اندازه‌گیری عبارت‌اند از میانگین زمان برای تأیید (MTTA)، میانگین زمان برای حل‌وفصل (MTTR)، تعداد کل حوادث بزرگ و متوسط خرابی برای حوادث بزرگ.
نمودار جریان فرایند مدیریت حوادث ITIL®
نقشها و مسئولیت‌های مهم مدیریت حوادث
یک حادثه بزرگ خواستار یک گروه ویژه از کارکنان برای مقابله با این حادثه و حل آن است. نقش‌های MIM عبارت‌اند از:
تکنسین‌های میز خدمات
تکنسین‌های میز خدمات اولین خط مقدم در برابر حوادث بزرگ هستند. آن‌ها تیکت های حادثه را تجزیه‌وتحلیل میکنند و به مدیر حادثه ارجاع میدهند و یا تشدید میکنند. تکنسین‌های میز خدمات نیز در اجرای قطعنامه‌ها دخیل هستند.
مدیر حادثه بزرگ
مدیر حادثه بزرگ، مالک حادثه بزرگ است. نقش او شامل اعلام حادثه به‌عنوان یک حادثه بزرگ و اطمینان از اینکه فرایند MIM دنبال میشود و حادثه در اسرع وقت حل میشود. او به‌عنوان نقطه اصلی تماس برای هرگونه اطلاعات در مورد حادثه بزرگ، و مدیریت MIT نقش خود را ایفا میکند.
MIT
MIT یک تیم تخصصی است که مسئول تجزیه‌وتحلیل حادثه بزرگ و تدوین یک برنامه عملی برای مقابله با تهدید است. MIT ایدئال شامل تکنسین‌های میز خدمات، کارکنان مدیریت سطح خدمات، فنی است کارکنان، سایر ذینفعان مربوطه و مشاوران خارجی در صورت نیاز به آن.
کارکنان فنی
کارکنان تخصصی که مسئول نگهداری زیرساخت‌ها و عملیات هستند، ازجمله مدیران سیستم، مدیران شبکه و کارکنان امنیت اطلاعات، که کارکنان فنی سازمان را تشکیل میدهند. فنی کارکنان به عیب‌یابی حادثه اصلی کمک میکنند و در درجه اول مسئول اجرای قطعنامه اصلی حادثه هستند.
مدیر تغییر
مدیر تغییر مالک تغییری است که برای اجرای اصلاح حادثه بزرگ ایجادشده است. مدیر تغییر مالکیت کامل تیکت تغییر را به عهده می‌گیرد و مسئول آن است.
مدیر مشکل
اگر مشکلی در پاسخ به حادثه بزرگ ایجاد شود، مدیر مشکل صاحب تیکت مشکل است. مدیر مشکل سعی میکند علل ریشه‌ای حادثه را مشخص کند و اطمینان حاصل کند که دوباره اتفاق نمی‌افتد یا سازمان حداقل برای دفعه بعد که حادثه رخ می‌دهد آماده است.
مشاوران خارجی یا فروشندگان شخص ثالث
در برخی موارد، حادثه بزرگ ممکن است نیاز به کارکنان بسیار متخصص برای کمک به درک و عیب‌یابی حادثه داشته باشد. مدیر حادثه اصلی کارکنان موردنیاز را شناسایی میکند و آن‌ها را به MIT اضافه میکند تا به کاهش تأثیر کمک کند. از حادثه بزرگ
بعبارتی برای یک حادثه بزرگ شما درگیر ۳ تمرین از ITIL میشوید: تمرین مدیریت حادثه- تمرین مدیریت مشکل و تمرین مدیریت تغییر.
در ITIL یک ماتریس وجود دارد بنام ماتریس RACI . این ماتریس RACI مسئولیت‌های ذینفعان مختلف را در یک فرایند تعریف میکند. ماتریس RACI یک ابزار ساده و مؤثر برای تعریف نقشها و مسئولیت‌های پروژه است که یک نمودار یا جدول جامع از اینکه چه کسی مسئول responsible، پاسخگو: Accountable، مشاور: Consultedو مطلع: Informed در هر مرحله را ارائه می‌دهد.جدول زیر نقشها و مسئولیت‌های ذینفعان اصلی حادثه را در طول فرایند MIM تعریف میکند.
| فرایند / نقشها | تکنسین‌های میز خدمات | مدیر حادثه بزرگ | MIT | کارکنان فنی | مدیر تغییر | مدیر مشکل | مشاوران خارجی |
| شناسایی | |||||||
| اعلام حادثه بزرگ | C | A | R | C | I | I | I |
| اطلاع‌رسانی به ذینفعان | C | A | R | I | I | I | I |
| مهار | |||||||
| جمع‌آوری MIT | I | R / A | C | C | I | C | I |
| راه‌اندازی یک پل کنفرانس | I | A | R | C | I | C | I |
| آماده‌سازی یک اتاق جنگ تعیین‌شده | I | A | R | I | I | C | I |
| ایجاد یک مشکل برای شناسایی مسائل اساسی | I | A | R | C | I | I | I |
| وضوح | |||||||
| اجرای طرح Resolution به‌عنوان یک تغییر | I | I | I | R | A | C | C |
| نگهداری | |||||||
| انجام بررسی پس از پیاده‌سازی | I | C | I | R | A | C | I |
| تولید مستندات روشن | C | A | R | C | C | C | C |
| معیارهای اندازه‌گیری | I | A | R | I | I | I | C |
* R – مسئول، A – پاسخگو، C – مشاور، I – مطلع
در اینجا ۵ اشتباه رایج وجود دارد که میتواند مانع فرایند MIM شما شود:
بزرگ‌ترین چالش برای MIM ارتباطات است. در صورت وقوع یک حادثه بزرگ، ذینفعان مختلف باید از وضعیت حادثه، شدت آن و اینکه چه عیب‌یابی برای رفع آن انجام‌شده است، مطلع شوند. برقراری ارتباط با همه این‌ها یک کار دشوار است و میتواند منجر به ارتباطات متناقض شود که فقط اوضاع را بدتر میکند. با خودکار سازی فرایند، ذینفعان کلیدی در طول کل عمر تیکت مطلع می‌شوند و مدیر حادثه بزرگ میتواند تمام توجه خود را بر رفع مسئله متمرکز کند.
هر میز خدمتی روزانه ده ها یا حتی صدها تیکت دریافت میکند، از مسائل مربوط به لپ‌تاپ تا درخواست خدمات. در میان این کوه بزرگی از درخواست‌ها، ممکن است چند حادثه بزرگ بالقوه وجود داشته باشد. راه‌اندازی یک یا چند کانال جداگانه گزارش حوادث بزرگ، شناسایی حوادث بزرگ را به تأخیر نمی‌اندازد.
عدم واگذاری وظایف به شیوه‌ای سازمان‌یافته میتواند باعث تکرار تلاش‌ها در MIT شود. مهم است که وظایف را اختصاص دهید و MIT را ازآنچه هر عضوش باید با آن کار کند مطلع کنید.
فقدان مستندات مناسب، MIT را مجبور میکند تا هر بار که یک حادثه بزرگ مشابه رخ می‌دهد، چرخ را دوباره اختراع کند، که منجر به تأخیر در حل‌وفصل حوادث بزرگ و ایجاد خرابی غیرضروری میشود.
مشابه مدیریت حادثه، MIM میتواند در محدوده نزدیک‌بینی باشد، زیرا تمرکز اصلی آن این است که مشکل را حل کند و خدمات را در کوتاه‌ترین زمان ممکن اجرا کند. اگر با مدیریت مشکل برای شناسایی مسائل اساسی ترکیب نشود، علت اصلی یک حادثه بزرگ همچنان سازمان را در برابر حوادث بزرگ آسیب‌پذیر میکند. و این زخم کهنه بر بدن سازمان باقی میماند.
در اینجا بهترین راه برای نزدیک شدن به فرایند MIM وجود دارد
وقتی صحبت از رسیدگی به حوادث بزرگ میشود، زمان بسیار مهم است. برای سازمان‌ها بسیار اهمیت دارد که حوادث عمده را به‌محض شناسایی و طبقه‌بندی کنند. ارائه راه‌های متعدد به کاربران برای گزارش حوادث را کل فرایند سریع‌تر و قابل‌دسترس‌تر است. شما می‌توانید ایجاد تیکت را از طریق ایمیل یا پورتال وب فعال کنید یا حتی یک خط تلفن اختصاصی برای گزارش حوادث مشکوک ایجاد کنید. راه‌اندازی نرم‌افزار نظارت بر شبکه برای تشخیص ناهنجاری‌ها میتواند به شما کمک کند تا فعالانه با حوادث بزرگ مقابله کنید.
سرعت و کارایی، نقش مهمی در کنترل تأثیر یک حادثه بزرگ ایفا میکند و خودکارسازی فرایندهای مختلف میز خدمات با آزاد کردن تکنسین‌های خود از وظایف تکراری مانند اطلاع‌رسانی به ذینفعان به دستیابی به این هدف کمک میکند. خودکارسازی سیستم اطلاع‌رسانی و راه‌اندازی جریان‌های اصلی حادثه، راه‌های خوبی برای خودکارسازی فرایندهای میز خدمات برای بهبود زمان حل و ایجاد ساختار به فرایند MIM شما است.
مهم است که مدیریت سازمان و ذینفعان مهم خود را از هر حادثه مهم مطلع کنید. نگه‌داشتن مدیریت در حلقه ارتباط گرفتن تصمیمات فوری و یا تأییدیه‌های لازم و مجوز موردنیاز منجر به رفع سریع مشکل می شود.
حادثه بزرگ ارتباط سریع را تضمین میکند که تمام کارکنان حادثه اصلی در یک صفحه هستند و اجازه می‌دهد تا برای همکاری صاف و مؤثر آماده باشند و همچنین کاربران نهایی را از هرگونه خرابی احتمالی مطلع میکند.
مستندات روشن به مدیر حادثه اصلی کمک میکند تا تمام کارهای انجام‌شده برای رفع حادثه بزرگ، تأثیرش، خدمات آسیب‌دیده و سایر اطلاعات کلیدی در مورد حادثه بزرگ را ثبت کند. این مستندات مهم است برای نشان دادن مدیریت مزایای داشتن یک فرایند MIM، ازجمله ROI آن.
علاوه بر این اسناد روشن نیز با هر حادثه بزرگ مشابه در آینده کمک خواهد کرد.
ادغام قوی میزخدمت با نرم‌افزار ITOM بخش فناوری اطلاعات را قادر می‌سازد تا به‌طور فعال حوادث عمده را اداره کنند. شناسایی حادثه بزرگ واکنشی متکی به هجوم تیکت برای بالا بردن پرچم قرمز است که یک حادثه بزرگ در حال پیشرفت است. از سوی دیگر، یک فرایند MIM فعال که از ادغام ITOM استفاده میکند، سیستم‌هایی برای نظارت بر شبکه‌ها و خدمات دارد و میتواند به‌طور خودکار ناهنجاری‌هایی را که میتواند حوادث بالقوه بزرگ باشد، پرچم گذاری کند.
هنگامی‌که به MIM می‌آید، در زیر برخی از معیارهای مهم و KPI ها برای پیگیری وجود دارد.
| KPI | فرمول | نظرات |
| میانگین زمان برای حل‌وفصل (MTTR) | متوسط زمان از زمانی که یک حادثه بزرگ گزارش میشود تا زمانی که حل میشود. | این نشان می‌دهد که میز خدمات شما با چه سرعتی میتواند حوادث بزرگ را حل کند. MTTR کوتاه‌تر نشانه این است که MIT شما مؤثر و کارآمد است. |
| میانگین زمان برای تصدیق (MTTA) | متوسط زمان برای پاسخ به یک حادثه بزرگ | MTTA کوتاه‌تر نشانه این است که میز خدمات شما سریع به حوادث بزرگ پاسخ می‌دهد. |
| میانگین زمان بین شکست (MTBF) | متوسط زمان بین شکست‌ها این با تقسیم کل زمان اپ تایم بر تعداد کل شکست‌ها محاسبه میشود. | این نشان‌دهنده عملکرد زیرساخت IT شما است. MTBF بالاتر نشانه این است که زیرساخت IT شما به‌خوبی عمل میکند. |
| میانگین زمان تشخیص (MTTD) | متوسط زمان لازم برای شناسایی حوادث بزرگ یا ناهنجاری‌ها. | این شاخص نیز اندازه‌گیری میکند که چقدر سریع یک حادثه بزرگ شناسایی میشود. MTTD کوچک‌تر نشانه این است که میز خدمات برای شناسایی حوادث بزرگ سریع هستند. |
| درصد افزایش یا کاهش حوادث بزرگ | درصد افزایش مشکلات در ماه‌های بعد نسبت به ماه اول. | این به شما کمک میکند تا روند وقوع حوادث بزرگ را شناسایی کنید. |
دو سناریو زیر، حوادث بزرگی بودند که بر خدمات سازمان تأثیر عمیقی گذاشت:
مهم است که به یاد داشته باشید که همه حوادث با اولویت بالا حوادث بزرگ نیستند. ازآنجاکه فرایند MIM شامل تعهد قابل‌توجهی از منابع مانند اجرای MIT جداگانه است، مهم است که حوادث عمده را با دقت طبقه‌بندی کنیم.
قطع Cloudflare 2019 نمونه بسیار خوبی ازآنچه یک حادثه بزرگ را تعریف میکند. در این مورد، قطع برق منجر به کاهش ۸۰ درصد از ترافیک Cloudflare شد و میلیون‌ها کاربر اینترنت را در سراسر دنیا تحت تأثیر قرار داد.
تأثیر: بزرگ
قطع برق باعث شد مشتریان Cloudflare (و مشتریان آن‌ها) هنگام بازدید از هر دامنه Cloudflare یک صفحه خطای ۵۰۲ را مشاهده کنند. خطاهای ۵۰۲ توسط سرورهای وب Cloudflare که هنوز هسته CPU در دسترس داشتند، ایجاد شد. اما قادر به دسترسی به فرایندهایی که ترافیک HTTP / HTTPS را ارائه می‌داند، نبودند. تخمین زده میشود که حداقل نیمی از کل اینترنت برای بیست‌وهفت دقیقه خرابی غیرقابل‌دسترسی بود.
فوریت: بالا
تمام وب‌سایت‌های Cloudflare غیرقابل‌دسترس بودند و باعث اختلال در خدمات برای هزاران سازمان و میلیون‌ها کاربر شدند. قطع برق عملیات داخلی Cloudflare را نیز تحت تأثیر قرار داد و مانع از دسترسی کارکنان Cloudflare شد. خدمات مختلف مانند ابزار مدیریت تغییر شرکت و کنترل پنل داخلی. قطع برق باید برای ازسرگیری عملیات خدمات عادی انجام شود.
جدول زمانی رویدادها از تشخیص تا تفکیک:
ابزارهای عملیات شبکه Cloudflare شروع به پرچم گذاری کاهش ترافیک کردند، بسیاری از آزمایش‌های دیگر خدمات Cloudflare شروع به شکست کردند، کاربران نهایی متوجه شدند خطاهای ۵۰۲ و Cloudflare گزارش‌های بسیاری از خستگی CPU را از نقاط حضور خود در شهرهای سراسر جهان دریافت کرد.
تیم مهندسی قابلیت اطمینان دفتر مرکزی، تیم مهندسی لندن و سایر تیم‌های مربوطه برای عیب‌یابی و رفع مشکل گرد هم آمدند. و ظرف سه دقیقه و در ساعت ۱۴:۰۰، علت این حادثه شناسایی شد. و در ساعت ۱۴:۰۷ سرویس برای بازگرداندن سطح ترافیک به حالت عادی اجرا شد.
در ساعت ۱۴:۵۲، Cloudflare ۱۰۰ درصد راضی بود که علت قطع برق را درک کرده و یک تعمیر در محل داشته باشد، بنابراین سرویس WAF این شرکت دوباره در سطح جهانی فعال شد.
اضافه کردن، اصلاح یا حذف هر چیزی که میتواند تأثیر مستقیم یا غیرمستقیم بر خدمات داشته باشد.
فرایند انجام تغییرات در تکمیل با حداقل اختلالات و برخوردها.
عمل انتقال مالکیت یک تیکت بر اساس یک نیاز عملکردی یا سلسله مراتبی.
رخدادی که برای مدیریت یک سرویس یا دارایی اهمیت دارد.
رویدادی که در آن یک سرویس یا دارایی مطابق با SLA توافق شده عمل نمی‌کند.
عمل انتقال مالکیت به‌صورت عمودی به یک تکنسین میز خدمات سطح بالاتر یا مقامات مربوطه.
اندازه‌گیری شدت یک حادثه.
وقفه برنامه‌ریزی نشده در یک سرویس فناوری اطلاعات یا کاهش کیفیت خدمات فناوری اطلاعات. خرابی یک آیتم پیکربندی، حتی اگر هنوز یک سرویس را تحت تأثیر قرار نداده باشد، نیز یک حادثه است (به‌عنوان‌مثال خرابی یک دیسک از یک مجموعه Mirror).
فرایند مدیریت چرخه حیات همه حوادث برای بازگرداندن عملیات خدمات عادی در اسرع وقت و به حداقل رساندن تأثیر کسب‌وکار.
تعیین اولویت‌ها به حوادث و تعریف آنچه یک حادثه بزرگ را تشکیل می‌دهد.
حادثه‌ای که تأثیر و فوریت بالایی دارد و نیاز به یک فرایند جداگانه از مدیریت حادثه دارد.
شخصی که مسئول MIT و اجرای فرایند MIM است.
اندازه‌گیری سرعت یک حادثه توسط میز خدمات تأیید میشود.
اندازه‌گیری سرعت یک تهدید بالقوه برای یک سرویس یا پیکربندی مورد شناسایی میشود.
اندازه‌گیری اینکه چگونه اغلب یک سرویس یا دارایی شکست می‌خورد.
اندازه‌گیری اینکه چقدر سریع یک سرویس پس از شکست بازسازی میشود.
یک عملیات خدماتی که مطابق با توافقنامه سطح خدمات (SLA) است.
علت یا علت احتمالی یک یا چند حادثه.
این نقشها و مسئولیتها را در پروژه‌ها و فرایندهای متقابل یا اداری تعریف میکند.
نقطه ارتباط بین ارائه‌دهندگان خدمات و کاربران سازمان.
کسی که فعالیت‌های روزانه میز خدمات را نظارت میکند و مسئول عملکرد آن است.
این هدف ارائه‌دهندگان خدمات را تعریف میکند و وسیله‌ای برای اندازه‌گیری عملکرد آن‌ها است.
توافق بین ارائه‌دهنده خدمات و مشتری در مورد سطح مورد انتظار خدمات و زمان مورد انتظار که در آن تحویل داده میشود.
اندازه‌گیری اینکه چقدر سریع یک حادثه باید حل شود.
سؤالات متداول
یک حادثه بزرگ یک مسئله فوری و با تأثیر بالا است که معمولاً کل سازمان یا بخش عمده‌ای از آن را تحت تأثیر قرار می‌دهد. یک حادثه بزرگ تقریباً همیشه منجر به در دسترس نبودن خدمات سازمان میشود، که باعث میشود کسب‌وکار سازمان ضربه بخورد و درنهایت بر جایگاه مالی و اعتبار آن تأثیر میگذارد.
چهار مرحله از یک حادثه بزرگ عبارت‌اند از:
فرایند اصلی مدیریت حادثه بزرگ در درجه اول شامل مراحل زیر است:
مرحله ۱: شناسایی
مرحله ۲: مهار
مرحله ۳: Resolution
مرحله ۴: تعمیر و نگهداری
مدیریت حادثه فرایند مدیریت اختلالات خدمات فناوری اطلاعات و بازگرداندن خدمات در توافقنامه‌های سطح خدمات توافق شده (SlAs) است. دامنه مدیریت حادثه با گزارش کاربر نهایی شروع میشود یک مسئله و با یک عضو تیم Service Desk که این مسئله را حل میکند، به پایان می‌رسد.
درحالی‌که مدیریت حوادث عمده (MIM) فرایند مدیریت حوادث بزرگ است که مسائل فوری و با تأثیر بالا هستند که معمولاً بر کل سازمان یا بخش عمده‌ای از آن تأثیر میگذارد و باعث ایجاد سازمان میشود. کسب‌وکار ضربه می‌خورد و درنهایت بر جایگاه مالیان تأثیر میگذارد.
دامنه MIM با شناسایی حوادث عمده گزارش‌شده از منابع مختلف آغاز میشود و با بررسی حادثه بزرگ توسط میز خدمات به پایان می‌رسد. برای درک بهتر در مورد چگونگی رسیدگی و بهبود فرایند MIM بررسی لازم است.
چگونه می‌توان فرایند مدیریت حادثه بزرگ را بهبود بخشید؟
فرایند MIM را می‌توان با:
چه کسی باید حوادث بزرگ را اعلام کند؟
یک حادثه بزرگ معمولاً توسط مدیر حادثه بزرگ اعلام میشود. اگرچه، اتوماسیون سازی از طریق ابزارهای مانیتورینگ را نیز می‌توان برای شناسایی هر تیکت که به‌طور بالقوه میتواند منجر به حوادث بزرگ شور را تنظیم کرد و به‌سرعت مدیر حادثه بزرگ را مطلع کرد. اطلاعات بیشتر در مورد اینکه چه کسی حادثه بزرگ را اعلام میکند را اینجا بخوانید.
نقش یک مدیر حادثه بزرگ چیست؟
مدیر حادثه بزرگ, مالک حوادث بزرگ است. نقش او شامل اعلام یک حادثه به‌عنوان یک حادثه بزرگ، اطمینان از پیگیری فرایند MIM و حل‌وفصل حادثه در اسرع وقت است.
چه چیزی یک مدیر حادثه بزرگ خوب را می‌سازد؟
درحالی‌که هیچ لیست مطلقی از ویژگی‌هایی که یک مدیر حادثه بزرگ را خوب توصیف کند وجود ندارد، ولی این ویژگی‌ها قطعاً کمک میکند:
برخی از KPI های مهم برای پیگیری مدیریت حوادث بزرگ چیست؟
در اینجا برخی از KPI های مهم برای پیگیری مدیریت حوادث مهم وجود دارد:
سرویس دسک پلاس یک ابزار محبوب برای مدیریت حوادث بزرگ است امتحانش کنید!
مقالات مرتبط را حتماً بخوانید:
ممنون عالی
[…] حوادث بزرگ از حادثه و / یا به مدیریت […]