قسمت چهارم
مقاله قبلی را می توانید از اینجا مطالعه فرمائید.
هر نوع مورد کاری (تیکت) اعم از رخداد و درخواست سرویس و تغییر شامل وضعیتهای مجزایی است که میتواند متأثر از فعالیتهای آن باشد. مواردی که در این مقاله بررسی میشوند به صورت پیشفرض در نرمافزار تعریفشده و قابل تغییر است. رخدادها به خاطر ماهیت آنها، در جهت کارایی بیشتر تیمها و سرعت بالاتر پاسخگویی همیشه به طرز خاصی مدیریت میشوند اما بقیه موارد کاری روندی تقریباً یکسان دارند.
رخداد دارای وضعیتهای فعال (Active)، حل شده (Resolved)، در انتظار (Hold)، و بسته شده (Closed) است. وضعیتهای حل شده و بسته شده وضعیتهای نهایی هستند. گراف انتقال وضعیت مجاز برای رخداد به شکل زیر است:
یکی از بهروشهای پیادهسازی رخداد برای دریافت بازخورد از کاربر ثبت کننده، امکان بستن رخداد توسط کاربر ثبت کننده پس از حل کردن آن توسط کارشناس است. این امر معمولاً با نظرسنجی همراه است و در صورت نیاز کاربر میتواند رخداد را مجدداً به جریان اندازد. پس از بسته شدن رخداد دیگر نباید تحت هیچ شرایطی آن را به وضعیت دیگری تغییر داد.
بهروشی دیگر قرارداد بستن خودکار رخداد پس از سپری شدن چند روز از حل آن است. برای مثال کاربر ثبتکننده تا ۳ روز مهلت دارد تا نظر خود را راجع به رخداد ثبت کنند و اقدام به بستن یا باز نمودن مجدد رخداد نماید. پس از گذشت ۳ روز، رخداد به طور خودکار به وضعیت بستهشده تغییر خواهد یافت.
از دیگر موارد متفاوت برای رخداد عدم وجود فعالیت بازبینی یا فعالیتهای کانتینر برای آن است. در واقع رخداد فقط میتواند شامل فعالیت اجرایی (مختص کارشناس) یا فعالیت اتوماتیک (Runbook) باشد. اینکه کارشناس برای حل رخداد دیگران از مدیر خود اجازه بگیرد یا منتظر سرپرست خود باشد امری نکوهیده است. همچنین در رخداد همه فعالیت ها در لحظه فعال میشوند و در واقع مانند اجرای همه فعالیتها به صورت موازی است تا با حداکثر سرعت پاسخگویی برسیم. تخصیص یک یا چند فعالیت در رخداد میتواند ناشی از مشارکت کارشناسان تیمهای مختلف یا پیمانکاران مختلف باشد. حال این پرسش مطرح است که چه کسی و با چه مکانیزمی بر کار این افراد (دارای فعالیت های مجزا) نظارت میکند، چرا که پیش از این گفتیم که همه فعالیتها با هم به حالت فعال خواهند بود و نیز فعالیت بازبینی در رخداد تعریف نمیشود. جواب این پرسش در تعریف شخصی در بدنه رخداد است که به آن کارشناس مسئول (Assigned to User / Assignee) گفته میشود این شخص مسئول بررسی صحت رسیدگی به رخداد است.
فعالیتهای تعریف شده در رخداد را میتوان به وضعیتهای کامل شده (Completed) یا ناموفق (Failed) تغییر وضعیت داد. هیچکدام از این وضعیتها باعث تغییر وضعیت در رخداد نمیشوند و این کارشناس مسئول است که وضعیت رخداد را به حل شده تغییر میدهد.
اما کنسل کردن رخداد هم امری غیر معمول نیست اما وضعیتی برای آن درنظر گرفته نشده است. از لحاظ فنی اعلام خرابی یا رخداد و سپس کنسل کردن آن از طریق «طبقهبندی حل» صورت میپذیرد، بدین صورت که وضعیت رخداد به «حل شده» تغییر میکند و طبقهبندی حل آن «کنسل شده» است. از دیگر مواردی که در طبقهبندی حل قابل به طور پیشفرض تعریف شده میتوان به «حلشده توسط کارشناس»، «حلشده توسط رده بالاتر»، «حل خودکار از طریق مشکل مرتبط» و نیز «حل خودکار توسط رخداد بالادستی» اشاره نمود.
پیشتر ذکر شده که میتوان از فعالیت اتوماتیک در رخداد استفاده نمود. این فعالیت میتواند شامل جریانهای کاری پیچیده یا بسیار ابتدایی باشد. استفاده از این نوع فعالیت معمولاً برای رخدادهای مانیتورینگ مرسوم است که از طریق ابزار مانیتورینگ و به صورت خودکار از طریق کانکتور بین دو ابزار ایجاد میشوند. هر رخداد مانیتورینگ بایستی شامل اطلاعات قلم پیکربندی[۱] مربوطه باشد. منظور از قلم پیکربندی نودهای شبکه، سرورها، یا هر دستگاه یا نرمافزاری است که در نرمافزار مانیتورینگ در حال پایش آن هستیم. برای روشن شدن موضوع مثالی را بررسی کنیم:
سرور A که سرویس SQL Server روی آن نصب شده است دچار مشکل میشود با این مضمون که سرویس SQL در دسترس نیست. این رخداد به صورت خودکار به ابزار SCSM منتقل میشود و در آن ثبت میشود. فعالیت خودکار تعریفشده روی رخداد با تشخیص اینکه قلم پیکربندی SQL Server دچار خرابی شده است روال معمول عیبیابی و بازیابی سرویس را آغاز میکند:
- پینگ کردن سرور مربوطه
- Telnet به پورت SQL Service
- اتصال به WMI سرور مربوطه و چک کردن وضعیت سرویسهای SQL Server
- اضافه نمودن اطلاعات سرور مقصی به فایل لاگ
- پیوست این لاگ به رخداد
- تغییر وضعیت فعالیت خودکار به کاملشده
در نتیجه این عملیات سرعت پاسخگویی به رخداد بالاتر رفته و ارائه راه حل تسریع میشود.
[۱] Configuration Item