مدیریت کامل حوادث در ITSM

مدیریت کامل حوادث در ITSM

مدیریت کامل حوادث در ITSM

مدیریت کامل حوادث در ITSM

بهترین تمرینات برای حل موثر حوادث مهم در فناوری اطلاعات و ارتباطات

اگر مدیر انفورماتیک سازمانی هستید تشخیص اینکه چه حادثه ای بزرگ است و چه حادثه ای کوچک؟ و یا کدام اتفاق مهم است و چه اتفاقی عادی!؟ نیازمند بررسی موردی و تحقیقات پیرامونی بسیاری است همین بررسی موردی و تحقیقات پیرامونی بی تردید زمانبر خواهد بود شما با شناسایی سرویس ها و خدمات موثر و کلیدی سازمان براحتی از روی تاثیر حوادث بر کسب و کار به اهمیت و بزرگی آن پی خواهید برد و نیازی به بررسی دقیق تر برای تشخیص بزرگی هر حادثه ای ندارید مثلا از کار افتادن ماوس یک کاربر تاثیر آنچنانی روی کسب و کار سازمان نمی گذارد اما اگر وب سایت یا تنها درگاه ارتباط با مشتری سازمان از کار بیافتد یعنی فاجعه! محسوب می شود پس بنابراین پرداختن به حوادث مهم امری کلیدی در مدیریت حوادث[۱] است.

حوادث مهم، تنش زا هستند. اکثر حوادث مهم ناشی از سلسله تغییرات ناآگاهانه قبلی است! و گاهی نیز برای بار نخست است که اتفاق می افتد. بنابراین بزرگی یا مهم بودن یک حادثه به تأثیر آن بر روی کسب و کار باز می گردد.

اگرچه هر حادثه ای کوچکی و گاهاً به ظاهر کم اهمیت هم می تواند به سرعت یک تنش بسیار بزرگی را به دنبال داشته باشد. در جهان فناوری نیز یک حادثه یا وقفه ای چند لحظه ای می تواند کل عملکرد یک سازمان را زیر سوال ببرد بنابراین تمامی حوادثی که در روز در سازمان رخ می دهند هر کدام می توانند فاجعه ای به بار آورند و تنش زا باشند بخصوص حوادثی که به مسائل فناوری اطلاعات مربوط هستند زیرا این دست از حوادث مستقیما بر روند عملیات و نتایج تجاری هر کسب و کاری تأثیر منفی می گذارد. ITIL 4 این دست از حوادث را به عنوان “حادثه ای با تاثیر قابل توجه در کسب و کار، که نیاز به یک راه حل فوری دارد” تعریف می کند.

خیلی از تأثیراتی که بر کسب و کار احساس می شوند علاوه بر بار حیثیتی، بار مالی بهمراه دارد بنابراین حوادث مهم نه تنها دارایی های سازمان را به خطر می اندازد بلکه سبب تحمیل هزینه های بسیاری نیز خواهد کرد که یا از جیب می رود یا از آبرو!

مثلا کسب و کار یک فروشگاه اینترنتی یک وب سایت است! در دسترس نبودن وب سایت، هک شدن، کندی و… حتی در کسری از ثانیه یک تنش بسیار بزرگ است و یا اینکه نرم افزار تولید یک کارخانه لحظه ای از کار بیفتد یعنی فاجعه در تولید… پس اهمیت رسیدگی به چنین حوادثی در این نوع بسیار ضروری است.

در یک نمونه ظاهری در یک شرکت، بدلیل نوسان برق و عدم اتصال سیستم های کاربران برق UPS در آن واحد بیش از ۱۰۰ دستگاه پاور کیس سوخت و کل فروش آن سازمان بطور کل مختل شد!

یا مثلا وجود یک نقص فنی در سیستم تعلیق خودرو در یک شرکت خودرویی منجر به فاجعه آتش سوزی خودروها در سرعت بالا می شد.

در این مبحث، شیوه ای برای مدیریت حوادث تنش زا به طور موثر ارایه خواهم کرد که در بردارنده چندین نکته کلیدی برای مدیریت بهتر اتفاقات بزرگ است.

شاید این مطلب را هم دوست داشته باشید:  همیشه حوادث تکراری، مشکل نیستند!

حقایق را بررسی کنید!

اولین کاری که هنگام برخورد با حوادث مهم باید انجام دهید این است که مطئمن شوید که همه حقایق را دارید بررسی می کنید برای این موضوع باید فهرستی از پرسشهای کلیدی را مطرح کنید و یافته های خود را در ارتباط با حادثه رخ داده شده مستند نمایید:

  • چه تاثیری بر روی کسب و کار می گذارد؟
  • چه خدماتی تحت تاثیر قرار می گیرد؟
  • چه گروهی از کاربران تحت تاثیر قرار می گیرند؟ آیا بخش یا مکان مشخصی است یا کل کاربران سازمان متاثر از این حادثه هستند؟
  • کدام گروه کارشناسان پشتیبانی متولی رسیدگی به این حادثه هستند؟ آیا ما افراد مناسب را درگیر کرده ایم؟
  • آیا همه در امنیت هستند؟ اول از همه، مراقب کاربران خود باشید و اطمینان حاصل کنید که همه از خطر احتمالی دور هستند. به ویژه اگر این حادثه مربوط به چیزی مانند سرقت اطلاعات ژنراتور، تعمیر و نگهداری UPS، و یا چاه ارت.
  • آیا باید تیم های پشتیبانی دیگر را آگاه کنیم؟
  • این حادثه ناشی از چه اتفاقی است آیا ناشی از یک یا مجموعه ای از فعالیت های تغییرات قبلی است؟
  • آیا پیش از این راهکار یا خطا شناخته شده و مستندی داشته ایم؟
  • آیا برای رسیدگی و رفع حادثه به پشتیبانی شخص ثالث (نظیر پیمانکاران) نیاز داریم؟
  • آیا باید به مشتریان پیشین نیز اطلاع دهیم؟
  • آیا این حادثه ناشی از نقص امنیتی است و باید سطح امنیتی را افزایش دهیم؟
  • آیا سرویس میز خدمت IT قادر به مقابله با حجم فعلی تماس های مرتبط است؟
  • مدت زمان بازگردانی وضعیت فعلی به حالت عادی چقدر است؟
  • زمان واقعی برای به روز رسانی چه هنگامی است؟
چک لیست اولیه حادثه هک شدن وب سایت سازمان
ارزیابی حقایق حادثه پاسخ
چه تاثیری بر روی کسب و کار می گذارد؟ بسیار زیاد
چه خدماتی تحت تاثیر قرار می گیرد؟ کلیه خدمات ارتباط با مشتری و فروش آنلاین
چه گروهی از کاربران تحت تاثیر قرار می گیرند؟ تمامی کاربران واحد فروش تمامی مشتریان سازمان
گروه کارشناسان مرتبط کارشناسان پشتیبانی
آیا همه در امنیت هستند؟ خیر اطلاعات و دیتاهای کاربران در معرض تهدید به سرقت است!  
اطلاع رسانی به سایر تیم های پشتیبانی؟ کارشناسان تولید کارشناس  زیرساخت
این حادثه ناشی از چه اتفاقی است آیا ناشی از یک یا مجموعه ای از فعالیت های تغییرات قبلی است؟ تغییر شرکت ارایه دهنده هاست
آیا پیش از این راهکار یا خطا شناخته شده و مستندی داشته ایم؟ خیر برای بار نخست است که اتفاق می افتد
آیا برای رسیدگی و رفع حادثه به پشتیبانی شخص ثالث (نظیر پیمانکاران) نیاز داریم؟ بله شرکت ارایه دهنده هاستینگ وب سایت
آیا باید به مشتریان پیشین نیز اطلاع دهیم؟ نیازی نیست.
آیا این حادثه ناشی از نقص امنیتی است و باید سطح امنیتی را افزایش دهیم؟ بله یک باگ امنیتی در سطوح دسترسی های هاستینگ شناسایی شده
آیا سرویس میز خدمت IT قادر به مقابله با حجم فعلی تماس های مرتبط است؟ باتوجه به سیستم اطلاع رسانی حجم درخواست های ورودی قابل کنترل است
مدت زمان تخمینی بازگردانی وضعیت فعلی به حالت عادی چقدر است؟ حداکثر ۲ ساعت
زمان واقعی برای به روز رسانی چه هنگامی است؟ ظرف یکماه آینده
شاید این مطلب را هم دوست داشته باشید:  آیا شما برای آینده ITSM آماده هستید؟

اصول اولیه را تحت پوشش قرار دهید تا از مسله بدقت آگاهی یابید و بتوانید به همه (یا حداقل) سؤالاتی که توسط مشتری (ها) و مدیریت ارشد از شما پرسیده خواهد شد، به درستی پاسخ دهید.

خیلی سریع و درست به کاربران اطلاع دهید.

در یک جهان ایده آل، شما باید یک لیست از افرادی که در صورت وقوع حادثه مهم باید مطلع شوند را همواره داشته باشید. موضوع اطلاع رسانی در ITIL یکی از سطرهای کلیدی در ماتریسRACI[2]  است و البته شناسایی مخاطبین و ذینفعان و کاربران مرتبط با حادثه مورد نظر از طریق روابط[۳] بین آیتم های پیکربندی[۴] امکانپذیراست. (بشرط آنکه روابط بین اقلام پیکربندی را از قبل در سرویس دسک تعریف کرده باشید) با این حال، واقعیت این است که اغلب اطلاع رسانی دقیق و سریع به افراد مرتبط بسیار سخت است. بنابراین اطمینان حاصل نمایید که برای اطلاع رسانی به افراد مناسب، اطلاعات درست را در زمان مناسب- زمانی که یک حادثه عمده رخ می دهد- به اطلاع افراد مرتبط می رسانید. در یک وضعیت حادثه مهم، ممکن است مجبور شوید با بعضی یا حتی همه موارد زیر ارتباط برقرار کنید:

  • مشتریان/کاربران عصبانی
  • ذینفعان کسب و کار فرعی و مدیران ارائه خدمات
  • تیم های فنی تحت فشار
  • نهادهای نظارتی

مطمئن شوید که افراد مناسب با ذینفعان مرتبط صحبت می کنند. به عنوان مثال، در ارتباط با تطابق و تیم های حقوقی، اگر طرف مقابل شما یک ارایه دهنده یا پیمانکار خارجی است.

هنگام برقراری ارتباطات لازم مطمین شوید که اطلاعات پایه به اندازه کافی روشن و آسان قابل فهم هستند. اگر هر گونه اطلاعاتی راجب یک راه حل خاص در اختیار دارید، برای پیشبرد آن کار اطلاعات را با افراد مرتبط به اشتراک بگذارید.

هنگام ارتباط حوادث مهم مطمئن شوید که شامل موارد ذیل است:

  • عنوان حادثه و مرجع رسیدگی
  • تاثیر آن بر کسب و کار
  • سرویس و پایگاه کاربری آسیب دیده
  • هر گونه راه حل و یا اطلاعاتی برای خود خدمتی[۵] کاربران
  • جزئیات تماس برای میز کار
  • زمان بروز رسانی بعدی.

یک طرح عملی ایجاد کنید.

پشت سر هم به تیم پشتیبانی خود سر بزنید شبیه یک فرمانده عملیات همه چیز را تحت نظارت و کنترل داشته باشد و شروع به جمع آوری یک برنامه عملی کنید. اطمینان حاصل کنید که تمام تیم های کلیدی را جمع آوری کرده اید تا چیزی از دست نرود و همه چیز به سرعت در حال انجام است. سریع، کارآمد و مهربان باشید. به خاطر داشته باشید که افراد تحت تأثیر فشار این حادثه به شدت در استرس بسیاری به سر می برند و تزریق استرس بیشتر کاری جز افزایش نرخ خطاهای انسانی و دوباره کاری و دوباره کاری نیست بنابراین زمان[۶] بخرید یک زمان توافق شده با مشتریان و طبق آن پیش بروید هرگز چیزی ایده آل پیش نمی رود بنابراین در برخورد با ذینفعان مختلف و کارشناسان فنی نهایت تمرکز و واقع بینی را داشته باشید.

به طور مرتب چک کنید.

به روز رسانی منظم با تیم های پشتیبانی و کسب و کار را مرتبا بررسی نمایید. اگر شما متعهد به رعایت زمان توافق شده SLAهستید با افراد فنی جهت به روز رسانی ها ملاقات و جلساتی را ترتیب دهید مرتبا افراد را برای به روزرسانی ها تعقیب نکنید – زیرا شما به آنها در دور زدن فرایند مدیریت رویداد مهم (بخشی از عملیات مدیریت حادثه در ITIL 4)  کمک می کنید و دخالت مستقیم  در عملکرد تیم های مربوطه باعث سرخوردگی بیشتر و تاخیر در نتیجه نهایی خواهد شد.

شاید این مطلب را هم دوست داشته باشید:  چرا در سرویس دسک به مدیریت دارایی های انفورماتیک نیاز داریم!؟

تغییرات لازم را اعمال کنید.

هنگامی که یک حل و فصل شناسایی شده فردی را بگمارید تا آن را بررسی کند و برخی آزمایش اولیه انجام دهد. پس از اطمینان از بازخورد حل و فصل در فضای آزمایشگاهی یک تغییر اضطراری را مطرح و در صورت لزوم، درخواست را به یک هیئت مشاوره تغییر اضطراری (CAB) برای تایید اجرای تغییر ارسال نمایید. پیاده سازی تغییرات در هر سازمانی متفاوت است، بعضی از شرکت ها اجازه می دهند که یک تغییر به طور پیش فرض اجرا شود تا بلافاصله یک خرابی را تعمیر کند. برخی اوقات نیاز به یک نسخه فشرده از روند تغییر دارید – بنابراین هر کاری که برای صاف کردن راه تعمیرات می توانید انجام دهید ارایه نمایید.

به کاربران اطلاع دهید که حادثه را حل کرده اید.

بازهم اطلاع رسانی و این وزنه بسیار مهم در مدیریت حوادث …

اطلاع رسانی به کاربران در هنگام بستن درخواست! را فراموش نکنید.

هنگامی که تعمیراتی را برای حل حادثه انجام داده اید، دقت کنید که تیم مربوطه بررسی های مناسب را انجام داده باشند و سپس با برخی از کاربران آسیب دیده تماس بگیرید تا اطمینان حاصل شود که همه چیز به درستی انجام شده و بخوبی کار می کند. زمانیکه تأیید کردید که همه چیز همان است که باید باشد، اطلاعیه نهایی را در مورد این حادثه منتشر و اعلام کنید که مشکل به کلی مرتفع شده و همه چیز خوب است.

درسی که از تعمیر این حادثه آموخته اید را ثبت و مستند کنید.

هنگامی که یک حادثه حل شد، پنج یا ده دقیقه طول می کشد تا کارشناسان اقدامات کلیدی و درسهایی که از این حادثه به دست آورده اند را یاد بگیرند. اکنون فراغ بال بیشتری دارید با خیال آسوده می توانید بررسی جامعتری داشته باشید و دقیقا مشخص کنید که علت وقوع چنین حادثه ای چه بود!؟ پس باید همه چیز را به تصویر بکشید رعایت این مرحله برای مدیریت مشکل و بهبود مستمر و مدیریت پایگاه دانش الزامی است بنابراین هنگامی که همه درگیر روزمرگی هستند و با BAU[7] خود دست و پنجه نرم می کنند، یک جلسه بررسی کوتاه را برنامه ریزی کنید. این می تواند در رابطه با مدیریت مشکل و بهبود مستمر مثمر ثمر واقع شود، زیرا حوادث مهم به تجزیه و تحلیل علت اصلی نیاز دارند و هدف از درس های بالقوه آموخته شده برای جلوگیری از وقوع این مسئله در آینده است. در این حال، قوانین مستندسازی را وضع کنید و یک مستند شفاف از این حادثه، اطلاعات ریشه ای اضافی و هر چیزی که برای جلوگیری از عود مجدد آن باید انجام شود را در محلی ثبت و ضبط کنید سپس برای بهبود مستمر و رفع سرچشمه علت وقع و جلوگیری از وقوع دوباره مشکل را در فرصتی مناسب برای همیشه ریشه کن کنید.

هادی احمدی


[۱] Incident Management

[۲] Responsibility-Accountability-Consulted-Informed

[۳] Relationships

[۴] CI- Configuration Item

[۵] Self Service

[۶] SLA

[۷]  کسب و کارِ مرسوم» (Business as usual) به وضعیتی گفته می‌شود که یک سازمان مطابق رویه‌های بومی و مرسوم خود به فعالیت ادامه می‌دهد یعنی علیرغم وجود راهکار و یا حتی فراهم بودن بستر مورد نظر، باز نمی خواهد تن به تغییر وضعیت جدید بدهد!

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

حل معادله *

error: نیازی به کپی نیست همه چیز در دیدرس شماست