ServiceDesk Plus
CMDB وقتی ارزش دارد که در زمان رخداد یا تغییر، جواب یک سؤال واقعی را بدهد؛ نه وقتی فقط نسخه شیک‌تری از فایل اکسل دارایی‌ها باشد.
بزرگ‌ترین اشتباه در شروع CMDB این است که تصور کنیم باید همه چیز را ثبت کنیم. نتیجه معمولاً هزاران رکورد ناقص، رابطه‌های نامشخص و تیمی است که بعد از چند هفته دیگر به داده‌ها اعتماد ندارد.
روش بهتر این است که از چند سرویس حیاتی شروع کنیم و فقط اقلام پیکربندی‌ای را ثبت کنیم که برای تحلیل اثر، رخداد، تغییر یا مالکیت اهمیت دارند.
سناریو: قطعی سامانه مالی و سؤال ساده‌ای که پاسخ ندارد
شرکت ۳۰۰ کاربر دارد. سامانه مالی روی دو ماشین مجازی اجرا می‌شود، به پایگاه داده، ذخیره‌ساز، Active Directory و یک لینک بین‌شهری وابسته است. روزی سامانه کند می‌شود و تیم پشتیبانی می‌داند «احتمالاً شبکه یا دیتابیس است»، اما هیچ تصویر مشترکی از وابستگی‌ها وجود ندارد.
در همین زمان تیم زیرساخت شب قبل یک تغییر روی Storage انجام داده و واحد شبکه هم Firmware سوییچ را ارتقا داده است. اگر CMDB فقط نام سرورها را داشته باشد، هنوز نمی‌تواند به تیم کمک کند. ارزش واقعی در رابطه بین سرویس، CI، تغییر و رخداد است.
مسئله را درست تعریف کنیم
برای شروع، CMDB باید به سه پرسش جواب دهد: این CI متعلق به کدام سرویس است؟ اگر تغییر کند چه چیزی ممکن است تحت‌تأثیر قرار گیرد؟ و چه کسی مسئول صحت اطلاعات آن است؟
هر فیلدی که به یکی از این پرسش‌ها کمک نمی‌کند، در فاز اول ضروری نیست.
| نوع CI | حداقل اطلاعات لازم | رابطه مهم |
|---|---|---|
| سرویس کسب‌وکار | نام، مالک، سطح اهمیت | وابسته به اپلیکیشن و زیرساخت |
| سرور یا VM | نام، IP، محیط، مالک فنی | میزبان اپلیکیشن یا دیتابیس |
| پایگاه داده | نام Instance، مالک، محیط | پشتیبان سرویس یا اپلیکیشن |
| تجهیز شبکه | مدل، IP مدیریت، سایت | مسیر ارتباطی سرویس |
| تغییر | زمان، ریسک، مجری، برنامه بازگشت | اثر روی یک یا چند CI |
مسیر اجرایی پیشنهادی
1. سه سرویس حیاتی را انتخاب کنید
شروع با همه سرویس‌ها باعث پراکندگی می‌شود. سه سرویس را انتخاب کنید که قطعی آن‌ها واقعاً برای کسب‌وکار هزینه دارد و تیم‌های مختلف در پشتیبانی‌شان درگیرند.
2. CIها را با دلیل وارد کنید
برای هر CI مشخص کنید چرا در CMDB است. اگر حذف این رکورد هیچ اثری بر تحلیل رخداد، تغییر، ریسک یا مالکیت ندارد، احتمالاً در فاز اول ضرورتی ندارد.
3. رابطه‌ها را ساده و قابل‌فهم نگه دارید
به جای ده‌ها نوع رابطه، از چند رابطه روشن مثل «میزبانی می‌کند»، «وابسته است به» و «متعلق است به» شروع کنید. رابطه باید برای کارشناس خط اول هم قابل‌فهم باشد.
4. مالک داده تعیین کنید
CMDB پروژه یک نفر نیست. مالک سرویس باید اطلاعات سرویس را تأیید کند، تیم زیرساخت مسئول داده‌های فنی خود باشد و یک نقش مرکزی کیفیت و ناسازگاری‌ها را پایش کند.
5. CMDB را وارد فرایند روزانه کنید
اگر رخداد و تغییر به CI وصل نشوند، داده بعد از مدتی بی‌مصرف می‌شود. کارشناس باید هنگام ثبت رخداد مهم یا درخواست تغییر، CI مرتبط را انتخاب کند تا CMDB به جریان واقعی کار متصل بماند.
از کجا بفهمیم مسیر درست است؟
شاخص خوب برای CMDB تعداد CI نیست. درصد CIهای دارای مالک، درصد تغییرات متصل به CI، تعداد رابطه‌های یتیم و تعداد رخدادهای مهمی که تحلیل اثر در آن‌ها استفاده شده، معیارهای بهتری هستند.
وقتی کارشناسان برای پیدا کردن اثر یک تغییر به CMDB مراجعه می‌کنند، یعنی پایگاه داده از «انبار اطلاعات» به ابزار عملیاتی تبدیل شده است.
خطاهای رایج
- واردکردن همه دارایی‌ها پیش از تعریف سرویس‌ها.
- رابطه‌سازی پیچیده‌ای که فقط طراح CMDB آن را می‌فهمد.
- نداشتن مالک داده و اتکا به یک واردسازی اولیه.
- جدا نگه‌داشتن CMDB از Incident و Change.
لینک‌های داخلی برای ادامه مطالعه
جمع‌بندی
CMDB خوب کوچک شروع می‌شود، ولی ارتباط‌های درست دارد. چند سرویس مهم با CIهای قابل‌اعتماد برای تیم بسیار مفیدتر از هزاران رکورد بدون رابطه است.
اگر طراحی CMDB را با سؤال‌های عملیاتی شروع کنید، به مرور می‌توانید دامنه را گسترش دهید بدون این‌که کیفیت قربانی حجم شود.
کلیدواژه‌های این راهنما: راه‌اندازی CMDB، ServiceDesk Plus، Configuration Item، مدیریت پیکربندی، مدیریت تغییر
