تمرینات مدیریت خدمات/ مدیریت حادثه

تمرینات مدیریت در ITIL4

تمرینات مدیریت خدمات/ مدیریت حادثه

تمرینات مدیریت خدمات شامل ۱۷ تمرین است که برای تمام خدمات بکار گرفته می‌شوند و دیدگاه‌هایی که در سراسر ارایه‌ی خدمات باید لحاظ شود را در بر می‌گیرد و بطور اخص به مدیریت خدمات و محصولات اشاره دارد. به عنوان مثال: مدیریت مشکل یکی از تمرینات این بخش است که بر شناسایی مشکلات و علت ریشه‌ای آنها در سراسر خدمات ارائه شده تمرکز دارد.

مقالات مرتبط را حتماً بخوانید:

• فوریت و ارتباط آن با موفقیت
• حادثه بزرگ چیست و فرایند آنرا چگونه پیاده کنیم؟
• مدیریت حادثه در Agile و ITIL
• ۷ گناه مرگبار در مدیریت حادثه
• فرق حادثه و رویداد در ITIL
• یک حادثه چقدر روی دست سازمان هزینه میگذارد؟
• تمرین مدیریت حادثه در ITIL4
• تفاوت بین درخواست حادثه با درخواست خدمت چیست؟
• همه چیز درباره مشکل و مدیریت مشکل
• همیشه حوادث تکراری مشکل نیستند!
• شناسایی حوادث تکراری
• راهکارهایی برای کاهش نرخ حوادث کاربران
• الگوریتم مدیریت خدمات و مولفه های آن
• علت اصلی افزایش حوادث خود واحد فناوری اطلاعات است!
• در فناوری اطلاعات آتشنشان نباشید!
• مدیریت کامل حوادث در ابزار ITSM

نوشته تمرینات مدیریت خدمات/ مدیریت حادثه اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

نقش کارکنان فناوری اطلاعات در افزایش نرخ حوادث کاربران

کارکنان پشتیبانی میزخدمت مدام درگیر حل و فصل خرابی‌ها و حوادث مطرح شده توسط مشتریان یا کاربران هستند و خیلی زود در انتهای یک روز، انرژی و توان و پاسخگویی به آنها را از دست می‌دهند و هرگونه پیگیری کاربران نیز به مثابه‌ی “گیر دادن” آنها تلقی می‌شود و با ترفندهایی نظیر بستن درخواست بدون اطلاع و تایید کاربر، ایجاد پروسه‌ی بیشتر برای رسیدگی، نادیده گرفتن درخواست‌های آنان، وعده دادن، پاسکاری درخواست به همدیگر و….سعی می‌کنند به نحوی از زیر بار فشار پیگیری و انجام وظایف شانه خالی کنند. تقصیری هم ندارند زیرا این دسته از افراد واسط بین سرویس‌دهنده و کاربران هستند. یک پل ارتباطی که اگر پایه‌های آن محکم و استوار ساخته نشده باشد اولین کامیونی که از روی آن رد شود باعث ریزش پل خواهد شد!

مشکل کجاست؟

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

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

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

تصور کنید جنگلی آتش گرفته، خاموش کردن آتش با ابزار و هر راهکاری نظیر: (چند نفر حافظ دلسوز طبیعت، هواپیمای آب‌پاش، کپسول آتش‌نشانی و بیل!) یک چیز است و وجود علف‌های خشک و بادهای موافق که سبب سرعت سرایت و تشدید دامنه‌ی شعله‌ها می‌شود یک چیز دیگر. در هر صورت آتش در حال نابودی تک‌تک درختان است، ذغال شدن تنه‌ی درختان و چهره‌ی سیاه و دلگیر جنگلِ سوخته ماحصل این آتش جهنمی است.

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

اگر فناوری اطلاعات را یک جنگل در نظر بگیریم پس هر سرویس یک درخت است! حافظان دلسوز طبیعت، کارکنان پشتیبانی لایه‌ی پیشخوان هستند و هواپیما و کپسول و بیل و خاک، راهکارهای حل مشکل‌اند. راهکارهای شناخته شده برای مشکلات شناخته شده! اما وجود علف خشک در سطح زمین و باد موافق آتش، مشکلات ناشناخته است و به واقع برخورد با آن چندان امکانپذیر نیست. خُب چکنیم با چند بیل و چند تشت آب برویم سراغ آتش!؟

پاسخ، بله چون آتش در حال پیشرفت است!

نتیجه: سوختن اکثر درختان، آسیب دیدن حافظان طبیعت

اما پیش از این چه باید می‌کردیم که به این روز نیافتیم؟

باید ببینم چه کسی و چه چیزی این آتش را به راه انداخته و چرا!؟

چهار علت طبیعی اصلی برای آتش‌سوزی جنگل عبارتند از: آذرخش، فوران آتشفشانی، جرقه در اثر فروافتادن صخره‌ها و احتراق خودبخود اما دخالت و فعالیت‌های انسانی نظیر: روشن کردن آتش برای جوجه کباب و چایی ذغالی! جرقه‌های ماشین‌آلات و ته‌سیگارهای دورانداخته‌شده و آتش‌زدن بقایای محصولات کشاورزی بعنوان علل عمدی همیشه مطرح می‌شود!

خُب علل طبیعی در جنگل فناوری امری قابل درک است. ممکن است هر اتفاقی منجر به از کار افتادن سرویس شود. برخی از آنها بطور پیشگیرانه قابل حل‌اند و برخی منفعلانه. بحث مهم ITIL در زمینه‌ی مدیریت حادثه نیز برای همین دسته از خرابی‌های طبیعی است.

اما خرابی‌های عمدی نه! خرابی‌های عمدی توسط حافظان طبیعت اتفاق نمی‌افتند بلکه دقیقاً توسط مدیران و کارشناسان زیرساخت رخ می‌دهند که مهمترین علت آن انجام بسیاری از تغییرات ناآگاهانه و بدون مدیریت صحیح تغییر است که منجر به شعله‌ور شدن آتش و افزایش نرخ خرابی می‌شود.

مثال‌هایی از علل وقوع خرابی‌های طبیعی در فناوری اطلاعات می‌تواند مواردی نظیر: سوخته شدن پاور یک سیستم، کنده شدن سوکت کابل شبکه، هنگ کردن سرور، اتمام کارتریج پرینتر، عدم آموزش کاربر و … باشد

و علل عمدی می‌تواند شامل: تغییر پورت وب یک نرم‌افزار تحت وب، تغییر دسترسی به نرم‌افزار، انجام پالیسی‌های امنیتی جدید، تغییر منابع سخت‌افزاری یک سرور، تغییر روش ورود به فلان نرم‌افزار، تغییر سناریو پرینت سرور و….

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

در ITIL تمرین مدیریت حادثه یا Incident Management برای رفع رجوع همین موارد مطرح شده. هدف آن ثبت و رسیدگی به حوادث و به حالت نرمال درآوردن تغییر وضعیت یک سرویس معیوب به یک سرویس سالم است. اما باید دقت داشت که اگرچه این تمرین برای هر نوع علت خرابی اعم از عمدی یا طبیعی می‌تواند به کار گرفته شود اما ماهیت درست آن رسیدگی به علل طبیعی خرابی سرویس‌هاست.

پس شک نکنید اگر جلوی تغییرات ناآگاهانه، را نگیرید باعث و بانی تمام این خرابی‌ها و شعله‌ور شدن آتش به جان جنگل شمائید! پس بدون بررسی دقیق، بدون برنامه‌ی پشتیبان، بدون ارزیابی ریسک و خطرات آن و بدون اطلاع‌رسانی انجام هر تغییری یک امر غلط است و کسی که با نظر شخصی یا تصمیم فوری و بدون ملاحظه! مصّر به انجام آن است یعنی عمداً می‌خواهد آتشی برپا کند!  تردید نیست در اینصورت با صدها نیروی پشتیبان نیز از پس حجم خرابی‌ها برنخواهید آمد. بنابراین رویکرد مهم فناوری اطلاعات برای پرهیز از این موضوع استفاده از مدیریت تغییر صحیح است!

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

فراموش نکنید هیچ تغییری را کوچک نشمرید! یک تغییر به‌ظاهر کوچک می‌تواند منجر به فاجعه شود! همچنان که یک ته‌سیگار می‌تواند جنگلی را به آتش بکشد!

هادی احمدی

نوشته باعث بیشتر خرابی‌ها خودِ واحد فناوری اطلاعات است! اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

فرق رخداد و رویداد در ITIL

در ITIL با دو اصطلاح رویداد (Event) و رخداد (Incident) مواجه می‌شویم که هر کدام فرایندی مجزا در خود دارد. مفاهیم رویداد و رخداد (حادثه) در عین حال که خیلی ساده‌ هستند از برخی جهات شبیه همند و همین باعث‌شده درعین سادگی، همزمان “خیلی گیج‌کننده” هم به نظر برسند!

در جلسات آموزشی همواره برخی از مدیران و کارشناسان فناوری، پرسش‌های زیادی را مطرح می‌کنند و بخوبی نمی‌توانند بین رویداد و رخداد تمایز قائل شوند و هر دو را یکی می‌پندارند و درک تفاوت آنها برایشان قدری دشوار است. اگرچه تاحدودی درست هم می‌گویند اما برای روشن شدن مطلب، درک تمایز بین رخداد و رویداد کمک می‌کند تا دید بهتری نسبت به این نوع فرایندها داشته باشیم. از آنجایی که ITIL اصالتاً انگلیسی است در ظاهر هر دو واژه یک معنی را می‌رساند و هر دو به چیزی مشترک اشاره می‌کنند که “اتفاق افتاده!” تشابه‌هات این دو در اینجا این معنی را می‌رساند که در هر دو یک “تغییر وضعیتی” انجام شده؛ با این تفاوت که “تغییر وضعیت” در رخداد لزوماً به معنای خرابی و حادثه است که سبب وقفه در خدمات و کاهش کیفیت سرویس است اما در رویداد این تغییر وضعیت می‌تواند خرابی در خود نداشته باشد و یک چیز کاملاً عادی باشد.

پیش از ادامه‌ی بحث به این موضوع دقت کنید که ماهیت یک رویداد شامل (اطلاع، هشدار و استثنا) است این یعنی پیام‌های مطرح شده(اطلاع) یک اطلاع‌رسانی عادی است، پیام‌های(هشدار) نزدیک شدن سرویس‌ها به آستانه‌های تحمل است و پیام‌های(استثنا) وقوع یک خطا است.

مقاله‌ی مرتبط درباره‌ی مدیریت رویداد را مفصل بخوانید.

بگذارید چند نمونه از وقایع در مدیریت خدمات را مرور کنیم:

1. اجرای یک سرویس خاص در سرور X آغاز شد.
2. استفاده از لینک اینترنتی از ۶۰٪ به ۷۰٪ افزایش یافته است.
3. ترافیک پهنای باند شبکه در حال پُر شدن است.
4. تهیه‌ی نسخه پشتیبان از سیستم Z با موفقیت انجام شد.
5. کاربری وارد سیستم A شد.
6. سرور X با موفقیت بالا آمد.
7. آپدیت سیستم‌عامل فایل سرور انجام شد.
8. سوئیچ شبکه از کار افتاد.
9. وب سایت یا سرور B از دسترس خارج شد.
10. برنامه پشتیبان‌گیری از دیتاها از کار افتاد.

از نمونه‌های لیست فوق روشن است که یک رویداد می‌تواند یک چیز معمول را نشان دهد، همه‌ی این وقایع از اهمیت خاصی برای مدیریت خدمات برخوردار هستند. برخی از رویدادها نیاز به اقدام دارند و برخی نه! درک این اهمیت و تصمیم‌گیری در مورد اینکه چه عملی (در صورت لزوم) باید انجام شود را فرایند مدیریت رویداد می‌نامند. از طرفی دیگر در تعریف رخداد، Incident قطع برنامه‌ریزی یک سرویس فناوری اطلاعات، کاهش کیفیت خدمات یا عدم موفقیت CI (مورد پیکربندی)” آمده که در اینجا مشخص است که Incident چیزی است که تأثیر (منفی) بر کیفیت خدمات یا خدمات ایجاد می‌کند.

با مراجعه به لیست اتفاقات فوق، می‌توان فهمید که همه‌ی آنها حادثه(رخداد) نیستند.

1. اجرای یک سرویس خاص در سرور X آغاز شد. (رویداد اطلاع)
2. استفاده از لینک اینترنتی از ۶۰٪ به ۷۰٪ افزایش یافته است. (رویداد هشدار)
3. ترافیک پهنای باند شبکه در حال پُر شدن است. (رویداد هشدار)
4. تهیه‌ی نسخه پشتیبان از سیستم Z با موفقیت انجام شد. (رویداد اطلاع)
5. کاربری وارد سیستم A شد. (رویداد اطلاع)
6. سرور X با موفقیت بالا آمد. (رویداد اطلاع)
7. آپدیت سیستم‌عامل فایل سرور انجام شد. (رویداد اطلاع)
8. سوئیچ شبکه از کار افتاد. (رویداد استثنا)
9. وب سایت یا سرور B از دسترس خارج شد. (رویداد استثنا)
10. برنامه پشتیبان‌گیری از دیتاها از کار افتاد. (رویداد استثنا)

ادامه مطلب در صفحه بعد…

نوشته فرق رخداد و رویداد در ITIL اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.