فرایند عملیات خدمات فناوری اطلاعات

💬 سوال: فرایند عملیات خدمات فناوری اطلاعات

فرآیند عملیات خدمات فناوری اطلاعات (IT Operations) چرخه‌ای ساختاریافته و مداوم است که هدف آن تضمین تحویل، پشتیبانی و مدیریت کارآمد و باثبات خدمات فناوری اطلاعات به کاربران نهایی است. این فرآیند با نظارت مستمر (Monitoring) بر سلامت سامانه‌ها آغاز می‌شود تا مشکلات بالقوه قبل از وقوع شناسایی شوند. هنگامی که کاربری با اختلال روبرو می‌شود (مانند قطعی ایمیل)، فرآیند مدیریت حادثه (Incident Management) به‌طور واکنشی برای بازیابی سریع سرویس فعال می‌شود.

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

مراحل و فرآیندهای کلیدی عملیات IT 

فرآیندهای عملیات IT را می توان به چندین مرحله و چرخه حیات تقسیم کرد. در اینجا هر کدام را به طور مفصل توضیح می دهیم.

۱. مدیریت درخواست خدمات (Service Request Management)

این فرآیند به درخواستهای روتین و استاندارد کاربران میپردازد. این درخواستها معمولاً “حادثه” یا “مشکل” محسوب نمیشوند، بلکه درخواست برای دسترسی به یک سرویس از پیش تعریف شده هستند.

مراحل:

ثبت درخواست: کاربر از طریق پورتال سلف سرویس، ایمیل یا تلفن درخواست خود را ثبت می کند (مثلاً: “نیاز به نصب نرم افزار Adobe Photoshop دارم”).

تایید و طبقه بندی: تیم IT درخواست را بررسی کرده و آن را بر اساس نوع (دسترسی، نرم افزار، سخت افزار و غیره) طبقه بندی می کند.

تصویب: بسته به خط مشی شرکت، ممکن است نیاز به تایید مدیر درخواست کننده یا مدیر مالی باشد (مثلاً برای نرم افزارهای پولی).

اجرا: پس از تایید، یک تکنسین IT نرم افزار را از طریق سیستم مدیریت نصب کرده یا دسترسی لازم را فراهم می کند.

بستن درخواست: از کاربر تایید نهایی گرفته شده و پرونده درخواست بسته می شود.

مثال: سارا، طراح جدید شرکت، به نرم افزار “Figma” نیاز دارد. او به پورتال IT شرکت مراجعه کرده و درخواست “نصب Figma” را انتخاب می کند. سیستم به طور خودکار درخواست را برای تایید به مدیر سارا می فرستد. پس از تایید مدیر، ticket به طور خودکار به تیم “نرم افزارهای تخصصی” اختصاص می یابد. یک تکنسین از راه دور و به صورت خودکار نرم افزار را روی لپ تاپ سارا نصب می کند. سیستم برای سارا ایمیل می فرستد که درخواستش تکمیل شده است.

۲. مدیریت حوادث (Incident Management)

هدف این فرآیند بازگردانی سریع سرویس به حالت عادی پس از یک اختلال غیرمنتظره است. تمرکز بر روی “رفع Symptom” است، نه necessarily یافتن “علت ریشه ای”.

مراحل:

شناسایی و ثبت: شناسایی حادثه از طریق monitoring system، تماس کاربر، یا گزارش خودکار.

طبقه بندی: تعیین اولویت بر اساس تاثیر (تعداد کاربران affected) و فوریت (میزان اختلال در کسب و کار). مثلاً: قطعی کامل ایمیل شرکت (اولویت بالا)، خرابی چاپگر یک اتاق (اولویت متوسط).

اولویت بندی: حوادث با اولویت بالا باید فوراً رسیدگی شوند.

راه و حل: تکنسین ها راه حل های شناخته شده (از پایگاه دانش) را امتحان می کنند یا با روش های عیب یابی مشکل را برطرف می کنند.

بستن حادثه: پس از حل مشکل، با کاربر follow-up شده و ticket بسته می شود.

مثال: کاربران در بخش مالی نمی توانند به سرور اشتراکی فایل ها متصل شوند. monitoring system به طور خودکار یک حادثه با اولویت بالا ایجاد می کند. تیم IT بلافاصله بررسی می کند و متوجه می شود که سرویس “File and Printer Sharing” روی سرور crash کرده است. آنها سرویس را restart می کنند و connectivity برقرار می شود. حادثه بسته می شود. در این مرحله، چرا سرویس crash کرد بررسی نمی شود (این مربوط به مدیریت مشکل است).

۳. مدیریت مشکلات (Problem Management)

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

مراحل:

شناسایی مشکل: تحلیل داده های حوادث برای یافتن روندها یا الگوها (مثلاً: چندین حادثه گزارش “کندی سرور” در ساعات اوج کاری).

ثبت مشکل: ایجاد یک رکورد “مشکل” برای ردیابی تحلیل و فعالیت های مربوطه.

تحلیل علت ریشه ای (RCA): استفاده از تکنیک هایی مانند “5 Why” برای کاوش عمیق و یافتن منبع اصلی مشکل.

ایجاد Workaround: اگر حل دائم زمان بر است، یک راه حل موقت برای کاهش impact حوادث آینده تعریف می شود.

ایجاد Change Request: برای اجرای یک fix دائمی، یک درخواست تغییر به فرآیند مدیریت تغییر ارسال می شود.

بستن مشکل: پس از اعتبارسنجی که fix دائمی موثر بوده و حوادث مربوطه کاهش یافته اند، مشکل بسته می شود.

مثال: از مثال قبل، تیم Problem Management متوجه می شود که حوادث مربوط به crash کردن سرویس فایل هفته ای یکبار در سه هفته گذشته تکرار شده است. آنها تحلیل RCA انجام می دهند:

Why 1: چرا سرویس crash می کند؟ به دلیل مصرف 100% حافظه RAM.

Why 2: چرا RAM پر می شود؟ به دلیل یک memory leak در یک اسکریپت قدیمی پشتیبان گیری که همزمان با ساعات اوج کاری اجرا می شود.

Why 3: چرا این اسکریپت باعث memory leak می شود؟ به دلیل یک باگ در کد نویسی آن.
راه حل موقت (Workaround): زمان اجرای اسکریپت را به نیمه شب تغییر دهید.
راه حل دائمی: توسعه دهنده اسکریپت، باگ memory leak را برطرف کرده و یک نسخه جدید ارائه می دهد که از طریق فرآیند مدیریت Change می شود.

۴. مدیریت تغییر (Change Management)

هدف این فرآیند کنترل نحوه اجرای تغییرات در محیط IT به منظور به حداقل رساندن ریسک و اختلال در سرویس های موجود است.

مراحل:

درخواست تغییر (RFC): هر تغییری (نصب نرم افزار، آپدیت، پیکربندی جدید) باید به صورت یک RFC ثبت شود.

بررسی و ارزیابی: یک هیئت (CAB) یا مدیر تغییر، درخواست را از نظر risk, impact, benefit و back-out plan (طرح بازگشت به حالت قبلی در صورت شکست) بررسی می کند.

تصویب: تغییرات بر اساس risk آنها تصویب می شوند:

Standard: تغییرات کم risk و از پیش تایید شده (مثلاً reset کردن password).

Normal: نیاز به بررسی و تایید CAB دارد (مثلاً آپدیت firmware یک سوئیچ core).

Emergency: برای رفع یک fault critical که نیاز به تغییر فوری دارد (با فرآیندهای سریع و post-implementation review).

1. اجرا: پس از تصویب، تغییر در یک پنجره زمانی از پیش تعریف شده (مثلاً شب یا آخر هفته) توسط پرسنل مجاز اجرا می شود.
2. بررسی و بستن: پس از اجرا، نتیجه بررسی شده و در صورت موفقیت آمیز بودن، تغییر بسته می شود.

مثال: تیم زیرساخت می خواهد سیستم عامل سرور اصلی ایمیل را از Windows Server 2016 به 2022 ارتقا دهد. یک RFC ایجاد می شود که شامل impact analysis (دقایقی downtime برای ایمیل)، back-out plan (بازگردانی از snapshot گرفته شده قبل از ارتقا) و برنامه تست است. این RFC در جلسه هفتگی CAB مطرح شده و پس از بحث، تصویب می شود. ارتقا در ساعت 2 بامداد یکشنبه انجام می شود. پس از اجرا، تست های عملکردی انجام شده و همه چیز تایید می شود. تغییر بسته می شود.

۵. مدیریت دارایی های IT و پیکربندی (IT Asset & Configuration Management)

این فرآیند به دنبال نگهداری یک پایگاه داده دقیق از تمام دارایی های IT (سخت افزار، نرم افزار، licenses) و روابط بین آنها است. این پایگاه داده CMDB نام دارد.

• هدف: درک اینکه چه چیزهایی در محیط IT وجود دارد، چگونه پیکربندی شده اند و چگونه به هم مرتبط هستند.
• مثال: یک سرور مجازی (Asset) که نرم افزار پایگاه داده SQL Server (Asset) را اجرا می کند و به یک storage array خاص (Asset) متصل است. اگر آن storage array fail کند، CMDB بلافاصله نشان می دهد که کدام سرویس ها (و در نهایت کدام کاربران) تحت تاثیر قرار خواهند گرفت. این برای تحلیل impact در حوادث و تغییرات حیاتی است.

۶. مدیریت در دسترس بودن (Availability Management)

این فرآیند اطمینان می دهد که سرویس های IT به اندازه کافی در دسترس، reliable و maintainable هستند تا نیازهای کسب و کار را برآورده کنند. این شامل طراحی برای redundancy (مانند سرورهای خوشه ای)، fault tolerance و برنامه ریزی برای capacity است.

مثال: یک کسب و کار آنلاین به uptime 99.99% برای وب سایت خود نیاز دارد. تیم Availability Management تضمین می کند که وب سایت روی چندین سرور در یک load balancer اجرا می شود، از یک دیتاسنتر backup استفاده می کند و connection های internet redundant دارد. اگر یک سرور یا یک خط اینترنت fail کند، ترافیک به طور خودکار به components سالم هدایت شده و وب سایت online باقی می ماند.

۷. مدیریت ظرفیت و عملکرد (Capacity & Performance Management)

این فرآیند نظارت بر استفاده از منابع (پردازنده، حافظه, disk space, پهنای باند) برای اطمینان از اینکه سامانه ها performance مطلوب را دارند و قبل از اینکه به یک مشکل بحرانی تبدیل شوند، نیازهای آینده پیش بینی می شود.

مثال: monitoring tools نشان می دهند که استفاده از space دیسک سرورهای ذخیره سازی هر ماه 5% رشد می کند. تیم Capacity Management پیش بینی می کند که در 6 ماه آینده فضای آزاد تمام خواهد شد. آنها یک گزارش ارائه داده و یک درخواست خرید storage جدید را init می کنند تا قبل از وقوع بحران، فضای جدید تامین شود.

چرخه حیات یک درخواست ساده چگونه از چندین فرآیند عبور می کند؟

یک action ساده کاربر می تواند چندین فرآیند را فعال کند.

سناریو: کاربری گزارش می دهد که “کامپیوتر من بسیار کند است و freeze می کند.”

1. مدیریت حادثه: یک ticket حادثه ثبت می شود. تکنسین با راهنمایی کاربر، یک راه حل موقت پیدا می کند (مثلاً restart کردن کامپیوتر). مشکل به طور موقت برطرف می شود و ticket بسته می شود. (سرویس بازیابی شد).
2. مدیریت مشکل: اگر این حادثه برای چندین کاربر مختلف تکرار شود، تیم Problem Management یک رکورد “مشکل” ایجاد می کند تا علت ریشه ای کندی عمومی کامپیوترها را بررسی کند.
3. مدیریت: آنها CMDB را بررسی می کنند تا ببینند آیا همه affected کامپیوترها یک مدل خاص، یک نسخه خاص از درایور یا یک نرم افزار مشترک هستند.
4. تحلیل علت ریشه ای: آنها discover می کنند که یک آپدیت اخیر Windows باعث conflict با یک آنتی ویروس قدیمی شده و منجر به مصرف high CPU می شود.
5. مدیریت تغییر: آنها یک Change Request برای deploy کردن نسخه جدید آنتی ویروس به تمام کامپیوترها ایجاد می کنند. CAB این تغییر را تصویب می کند.
6. اجرا: تغییر از طریق سیستم deployment خودکار به همه کامپیوترها اعمال می شود.
7. بستن: پس از deployment، monitoring نشان می دهد که مصرف CPU به حالت عادی بازگشته و حوادث گزارش “کندی” به صفر رسیده است. مشکل اصلی بسته می شود.

این یکپارچگی و همکاری بین فرآیندها است که عملیات IT را از یک مجموعه فعالیت های واکنشی به یک رشته مدیریت خدمات حرفه ای و پیشگیرانه تبدیل می کند.