فرض کنید تیم Service Desk برای یک Incident بحرانی به CMDB مراجعه میکند و میبیند یک Server با سه نام مختلف ثبت شده، Owner آن مربوط به کارمند سابق است، Relationship آن با Application اصلی ناقص است و آخرین Discovery چند ماه قبل انجام شده است. در چنین شرایطی، CMDB بهجای کمک به تشخیص اثر اختلال، خودش به منبع ابهام تبدیل میشود.
CMDB Health در ServiceDesk Plus را باید بهعنوان یک برنامه عملی برای حفظ کیفیت Configuration Itemها و Relationshipها دید؛ نه صرفاً یک گزارش زیبا. هدف این است که CIها کامل، یکتا، بهروز، دارای Owner و دارای ارتباط قابل اعتماد با سرویسها، داراییها و سایر CIها باشند.
CMDB خوب فقط CMDB پر از داده نیست
افزایش تعداد CIها بهتنهایی نشانه بلوغ نیست. اگر CIهای Duplicate، Stale یا بدون Relationship زیاد باشند، حجم داده بیشتر میشود اما ارزش عملیاتی کاهش پیدا میکند. کیفیت CMDB را باید بر اساس قابلیت استفاده آن در Incident، Change، Problem، Impact Analysis و Audit سنجید.
| بعد کیفیت | پرسش اصلی | نمونه مشکل |
|---|---|---|
| Completeness | آیا فیلدهای حیاتی ثبت شدهاند؟ | Owner یا Site خالی |
| Accuracy | آیا اطلاعات با واقعیت تطابق دارد؟ | IP یا OS قدیمی |
| Currency | آیا CI بهروز است؟ | Last Scan قدیمی |
| Uniqueness | آیا هر CI فقط یک رکورد معتبر دارد؟ | Duplicate Server |
| Relationship Integrity | آیا وابستگیها ثبت شدهاند؟ | Application بدون Database Relationship |
Duplicate CI چگونه ایجاد میشود؟
CIهای تکراری معمولاً وقتی ایجاد میشوند که Discovery Sourceهای مختلف، نامگذاری متفاوت یا Import دستی بدون Matching Rule مناسب داشته باشند. برای نمونه، یک Server ممکن است یکبار با Hostname، یکبار با FQDN و یکبار با IP بهعنوان رکورد مستقل دیده شود.
قبل از Merge یا حذف، باید Identifierهای معتبر مشخص شوند. MAC Address، Serial Number، Hostname، Asset Tag یا ترکیبی از Attributeها میتواند بسته به نوع CI برای تطبیق استفاده شود. Rule انتخابی باید با معماری واقعی سازمان سازگار باشد.
Stale CI چیست و چرا خطرناک است؟
Stale CI رکوردی است که مدت قابل توجهی Update یا Discovery نشده و وضعیت واقعی آن نامطمئن است. ممکن است تجهیز Decommission شده باشد، از شبکه خارج شده باشد یا Owner تغییر کرده باشد. نگهداشتن این رکوردها بدون Flag یا Review باعث میشود Impact Analysis بر اساس داده قدیمی انجام شود.
برای Stale CI چه Policy تعریف کنیم؟
بهجای یک عدد ثابت برای همه CIها، Threshold را بر اساس Criticality و نوع دارایی تعیین کنید. Serverهای Production، Network Deviceها و Business Applicationها باید Review Cycle کوتاهتری از تجهیزات کماهمیت داشته باشند.
Relationship ناقص؛ خطر پنهان CMDB
ارزش اصلی CMDB زمانی ظاهر میشود که Relationshipها مشخص کنند چه چیزی به چه چیزی وابسته است. اگر Web Server، Database، Application، Network Device و Business Service بدون ارتباط ثبت شوند، تحلیل Impact ناقص میشود.
برای نمونه، Change روی Database ممکن است از دید Asset ساده به نظر برسد، اما Relationship Map میتواند نشان دهد چند Application و Business Service به آن وابستهاند.
سناریو: Incident روی یک Application حیاتی
فرض کنید سامانه مالی در دسترس نیست. یک CMDB سالم باید بتواند به تیم Incident پاسخ دهد:
- Business Service مربوط چیست؟
- Application روی کدام Serverها قرار دارد؟
- Database و Storage وابسته کداماند؟
- Owner فنی و Business Owner چه کسانی هستند؟
- آخرین Change روی CIهای مرتبط چه بوده است؟
- کدام Site یا User Group از اختلال متاثر است؟
اگر پاسخ این پرسشها در CMDB وجود نداشته باشد، زمان Incident صرف کشف معماری از ابتدا میشود.
Discovery را با Governance ترکیب کنید
Discovery خودکار کیفیت را افزایش میدهد اما همه Attributeها را نمیتواند از شبکه کشف کند. Business Owner، Criticality، Service Relationship و Lifecycle State اغلب به Governance نیاز دارند. بنابراین بهترین مدل ترکیب Automated Discovery با Data Stewardship است. برای اینکه این Governance فقط به Process محدود نشود، مرور اجزای نظام حاکمیت COBIT 2019 کمک میکند نقش Structure، Information، Culture و Skills نیز در کنترل کیفیت داده دیده شود.
برای نگاه گستردهتر به Inventory و داراییهای ناشناخته، مقاله مدیریت دارایی سایبری و AssetExplorer مکمل این بحث است.
CI Owner و Data Steward چه نقشی دارند؟
هر CI مهم باید Owner مشخص داشته باشد، اما Owner الزاماً مسئول پاکسازی همه Attributeها نیست. میتوان Data Steward یا Process Owner تعریف کرد که Quality Ruleها، Duplicate Review و Lifecycle Policy را مدیریت کند.
| نقش | مسئولیت نمونه | خروجی |
|---|---|---|
| CI Owner | تأیید وضعیت و اهمیت CI | Ownership معتبر |
| CMDB Manager | مدل CI و Relationship | ساختار استاندارد |
| Asset Team | Lifecycle و Inventory | دارایی بهروز |
| Service Owner | ارتباط CI با Business Service | Impact Mapping |
| Change Manager | استفاده از CMDB در Risk/Impact | Change دقیقتر |
CMDB و Change Management باید به هم متصل باشند
هر Change مهم باید CIهای متاثر را مشخص کند. در مقابل، Change اجراشده نیز باید Attribute یا Relationshipهای تغییرکرده را بهروز کند. اگر این چرخه قطع باشد، CMDB بهمرور از واقعیت فاصله میگیرد.
برای تحلیل ریسک Change در همین محصول، مقاله Risk Scoring در ServiceDesk Plus مسیر مکملی ارائه میدهد.
CMDB و Ticket Routing چه ارتباطی دارند؟
وقتی Request یا Incident به CI و Service مناسب متصل شود، Assignment و Priority میتواند دقیقتر شود. برای مثال، Incident مربوط به یک Application خاص میتواند به Group تخصصی همان سرویس Route شود. راهنمای Ticket Routing در ServiceDesk Plus نحوه ساخت این جریان را توضیح میدهد.
KPIهای مناسب برای CMDB Health
- درصد CIهای دارای Owner معتبر؛
- درصد CIهای Critical با Relationship کامل؛
- تعداد Duplicate Candidateها؛
- درصد CIهای Stale بر اساس Policy هر Class؛
- درصد CIهای دارای Lifecycle State معتبر؛
- تعداد Incident/Changeهای متصل به CI؛
- تعداد Relationshipهای بدون Endpoint معتبر.
Runbook پاکسازی CMDB
- Classهای حیاتی را اولویتبندی کنید؛ همه CMDB را همزمان پاکسازی نکنید.
- Mandatory Attributeهای هر Class را تعریف کنید.
- Identifier و Duplicate Matching Rule را مشخص کنید.
- CIهای بدون Discovery یا Update اخیر را Flag کنید.
- Ownerهای Inactive را شناسایی و جایگزین کنید.
- Relationshipهای Business Serviceهای حیاتی را بازبینی کنید.
- CIهای Retired و Decommissioned را طبق Policy از Active Scope خارج کنید.
- Quality KPI را ماهانه یا بر اساس Risk مرور کنید.
چه زمانی ServiceDesk Plus و AssetExplorer را کنار هم ببینیم؟
اگر سازمان Asset Discovery و ITAM گسترده دارد، AssetExplorer میتواند لایه تخصصی Asset Management را تقویت کند و ServiceDesk Plus فرآیندهای ITSM و CMDB را به Incident، Change و Service Management متصل کند. انتخاب معماری به Scope، Edition و نیاز Integration بستگی دارد.
صفحه AssetExplorer در مدانت برای بررسی Pillar ITAM در دسترس است؛ در پروژههای ServiceDesk Plus نیز servicedeskplus.ir منابع تخصصی مرتبط را پوشش میدهد.
نکات کلیدی
- CMDB پرحجم الزاماً CMDB سالم نیست.
- Duplicate، Stale و Relationship ناقص سه منبع اصلی کاهش اعتماد به CMDB هستند.
- Discovery باید با Ownership و Governance تکمیل شود.
- CMDB باید در Incident، Change و Problem استفاده شود تا ارزش عملیاتی داشته باشد.
- Quality KPI باید بر اساس Criticality و Class تعریف شود.
منابع
- ManageEngine ServiceDesk Plus — CMDB
- ManageEngine ServiceDesk Plus — CMDB Help
- ManageEngine ServiceDesk Plus — CI Relationships
سخن پایانی
CMDB زمانی قابل اتکاست که تیمها در لحظه Incident یا Change بتوانند به اطلاعات آن اعتماد کنند. این اعتماد از تعداد CIها نمیآید؛ از داده یکتا، Owner معتبر، Lifecycle روشن، Discovery منظم و Relationshipهای درست ایجاد میشود.
مدانت خدمات لایسنس و استقرار ServiceDesk Plus، طراحی CMDB و CI Model، Discovery، ITAM، پاکسازی داده، Integration، سفارشیسازی، آموزش و پشتیبانی ارائه میکند. برای بررسی راهکار میتوانید به ServiceDesk Plus در مدانت یا تماس با مدانت مراجعه کنید.
