0

راهنمای عملی Configuration Drift در Network Configuration Manager؛ از Baseline و Real-time Change Tracking تا Diff، Approval، Running/Startup mismatch و Rollback امن.

شرکت مدانت
شرکت مدانت
[ مجری تخصصی پیاده‌سازی چارچوب ITIL و تحول دیجیتال ]
Configuration Drift در Network Configuration Manager؛ کشف تغییرات خارج از Baseline و Rollback امن

ساعت ۲ بامداد یک تغییر اضطراری روی Core Switch انجام می‌شود تا اختلال سرویس برطرف شود. ارتباط برمی‌گردد و Incident بسته می‌شود، اما یک Command موقت در Configuration باقی می‌ماند. چند هفته بعد همان تغییر فراموش‌شده باعث رفتار غیرمنتظره، مشکل Compliance یا حتی قطعی دیگری می‌شود. تیم شبکه Backup دارد، Change Ticket هم دارد، اما یک سؤال هنوز بی‌پاسخ است: Configuration فعلی دستگاه واقعاً با وضعیت تأییدشده سازمان یکسان است یا به‌مرور Drift کرده است؟

این دقیقاً مسئله Configuration Drift در Network Configuration Manager است. Drift زمانی رخ می‌دهد که Running یا Startup Configuration یک Router، Switch، Firewall یا سایر تجهیزات شبکه از Baseline یا وضعیت مورد انتظار فاصله بگیرد؛ خواه به‌دلیل تغییر دستی، Emergency Fix، Upgrade، Script ناقص یا تغییر خارج از فرآیند رسمی.

ManageEngine Network Configuration Manager یا NCM برای این مسئله مجموعه‌ای از کنترل‌ها ارائه می‌دهد: Configuration Backup، Versioning، Baseline، Real-time Change Tracking، Diff View، RBAC، Approval، Compliance Check و Rollback. هدف این مقاله این است که نشان دهد چگونه این قابلیت‌ها را به یک فرآیند عملی برای جلوگیری از Drift تبدیل کنیم، نه اینکه فقط Backup بیشتری جمع کنیم.

Configuration Drift چیست؟

Configuration Drift یعنی وضعیت واقعی Device به‌تدریج از وضعیت استاندارد، تأییدشده یا مورد انتظار فاصله بگیرد. این فاصله ممکن است فقط یک Command باشد یا مجموعه‌ای از تغییرات کوچک که در طول ماه‌ها انباشته شده‌اند.

چند نمونه رایج:

  • Telnet برای Troubleshooting موقت فعال شده و بعداً غیرفعال نشده است.
  • SNMP Community بعد از Firmware Upgrade به مقدار قبلی برگشته است.
  • یک ACL روی یک Firewall تغییر کرده اما روی دستگاه‌های مشابه اعمال نشده است.
  • Engineer در شعبه یک Static Route اضافه کرده و Change Ticket ثبت نشده است.
  • Running Configuration تغییر کرده ولی Startup Configuration Save نشده است.
  • یک Configlet روی بخشی از Device Group موفق و روی بخشی Fail شده است.
  • Vendor خارجی تغییری اعمال کرده که وارد Baseline رسمی نشده است.

Drift همیشه به معنی خرابکاری نیست. بسیاری از Driftها از تغییرهای کاملاً مشروع شروع می‌شوند؛ مشکل زمانی ایجاد می‌شود که تغییر ثبت، تأیید، همسان‌سازی یا بازگردانی نشود.

چرا Backup به‌تنهایی Configuration Drift را حل نمی‌کند؟

Backup پاسخ می‌دهد «Configuration در ساعت مشخص چه شکلی بود؟» اما Drift Management سؤال دیگری دارد: «Configuration فعلی هنوز همان چیزی است که باید باشد؟»

قابلیت Configuration Backup Drift Management
نسخه قبلی را نگه می‌دارد بله از Backup استفاده می‌کند
تغییر فعلی را با Baseline مقایسه می‌کند نه لزوماً بله
Drift را تشخیص می‌دهد نه بله
Change غیرمجاز را Alert می‌کند معمولاً نه بله
Rollback به Known-good فایل لازم را فراهم می‌کند می‌تواند فرآیند Recovery را کنترل کند
Baseline Enforcement ندارد جزء اصلی است

ManageEngine در مستندات فعلی NCM نیز صریحاً بین Backup و Drift Management تفاوت می‌گذارد: Backup برای Recovery ضروری است، اما بدون Continuous Validation ممکن است Device مدت‌ها از Configuration تأییدشده فاصله گرفته باشد و کسی متوجه نشود.

Baseline Configuration چیست؟

Baseline یک نسخه تأییدشده و قابل اعتماد از Configuration است که به‌عنوان مرجع مقایسه استفاده می‌شود. Baseline قرار نیست همیشه «آخرین نسخه» باشد؛ باید نسخه‌ای باشد که از نظر امنیت، عملکرد و عملیات مورد قبول سازمان است.

برای مثال روی یک Core Switch، Baseline می‌تواند شامل این موارد باشد:

  • AAA و Authentication استاندارد؛
  • SNMP امن؛
  • NTP صحیح؛
  • Logging/Syslog؛
  • Routing Protocol Configuration؛
  • Management ACL؛
  • SSH و غیرفعال بودن Protocolهای ناامن؛
  • VLAN و Trunkهای مورد انتظار؛
  • Banner و Security Settingهای سازمان.

در Network Configuration Manager می‌توان یک Configuration پایدار را Label یا به‌عنوان Baseline مشخص کرد و در صورت Drift یا Incident از آن برای مقایسه و Restore استفاده کرد.

Golden Configuration با Baseline چه تفاوتی دارد؟

این دو اصطلاح در بسیاری از تیم‌ها به‌جای هم استفاده می‌شوند، اما در طراحی عملی بهتر است تفاوت مفهومی داشته باشند:

  • Baseline: وضعیت تأییدشده یک Device مشخص.
  • Golden Configuration: الگوی استاندارد برای یک Class از Deviceها.

مثلاً Core-SW-01 می‌تواند Baseline مخصوص خودش را داشته باشد، اما تمام Access Switchهای یک Model از یک Golden Standard مشترک پیروی کنند.

این تفکیک کمک می‌کند هم Configuration خاص هر Device حفظ شود و هم استانداردهای مشترک سازمان کنترل شوند.

Drift Detection در NCM چگونه کار می‌کند؟

طبق مستندات ManageEngine، Network Configuration Manager می‌تواند Configurationهای Running و Startup را جمع‌آوری، Version و با Baseline یا نسخه‌های قبلی مقایسه کند. وقتی تغییر رخ دهد، Differenceها در سطح Command قابل مشاهده‌اند.

فرآیند منطقی چنین است:

  1. Device Discovery و Credential Configuration انجام می‌شود.
  2. Running و Startup Configuration Backup گرفته می‌شود.
  3. نسخه Stable به‌عنوان Baseline مشخص می‌شود.
  4. Change Detection فعال می‌شود.
  5. هر تغییر Configuration ثبت و Version می‌شود.
  6. Diff بین نسخه‌ها یا Baseline نمایش داده می‌شود.
  7. بر اساس Rule، Notification، Ticket یا Rollback اجرا می‌شود.

Real-time Change Detection چه مزیتی دارد؟

اگر Backup فقط شبانه انجام شود، تغییری که ساعت ۱۰ صبح رخ داده ممکن است تا چند ساعت دیده نشود. برای Deviceهای حساس، این فاصله زیاد است.

Network Configuration Manager قابلیت Real-time Change Tracking دارد و در سناریوهای پشتیبانی‌شده می‌تواند با Syslog یا Mechanismهای مربوط به Device تغییر را سریع‌تر تشخیص دهد. پس از تشخیص، Backup جدید گرفته می‌شود و نسخه تغییرکرده وارد History می‌شود.

این قابلیت مخصوصاً برای این Deviceها ارزش بالایی دارد:

  • Core Router/Switch؛
  • Internet Edge؛
  • Firewall؛
  • VPN Gateway؛
  • Load Balancer؛
  • WAN Router شعب حساس.

Diff View؛ «چه چیزی تغییر کرد؟» را دقیق ببینید

Alert با عنوان «Configuration changed» برای Troubleshooting کافی نیست. Engineer باید دقیقاً ببیند چه Commandی اضافه، حذف یا تغییر کرده است.

Diff View در NCM امکان Side-by-side Comparison بین دو Version را فراهم می‌کند. این مقایسه می‌تواند برای این موارد استفاده شود:

  • Baseline در برابر Running؛
  • قبل و بعد Change Window؛
  • دو نسخه از یک Device؛
  • Configuration دو Device مشابه؛
  • نسخه سالم در برابر نسخه زمان Incident.

در Incident Review، Diff معمولاً سریع‌تر از خواندن صدها خط Configuration به Root Cause نزدیک می‌شود.

سناریو: یک Command موقت بعد از Incident باقی مانده است

فرض کنید برای رفع مشکل دسترسی، Engineer موقتاً یک ACL را Relax می‌کند. Incident برطرف می‌شود اما Command جدید در Running Configuration باقی می‌ماند.

اگر Baseline و Change Tracking درست باشند:

  1. NCM تغییر را ثبت می‌کند.
  2. نسخه جدید ایجاد می‌شود.
  3. Diff نشان می‌دهد کدام ACL تغییر کرده است.
  4. Notification برای Owner ارسال می‌شود.
  5. Change با Ticket یا Emergency Change تطبیق داده می‌شود.
  6. پس از پایان Incident، Configuration به حالت تأییدشده برمی‌گردد یا Baseline جدید رسماً تصویب می‌شود.

این چرخه جلوی «Emergency Fix دائمی» را می‌گیرد.

Running و Startup Configuration؛ یک منبع پنهان Drift

یکی از Driftهای کلاسیک در تجهیزات شبکه زمانی است که Engineer Running Configuration را تغییر می‌دهد اما آن را در Startup Configuration ذخیره نمی‌کند.

تا زمانی که Device روشن است همه چیز درست به نظر می‌رسد. اما بعد از Reload یا Power Failure، دستگاه با Startup قدیمی بالا می‌آید و Configuration مورد انتظار از بین می‌رود.

NCM می‌تواند اختلاف Running و Startup را قابل مشاهده کند. این اختلاف باید برای Deviceهای Critical به‌عنوان Exception عملیاتی دیده شود.

چه تغییرهایی باید Critical تلقی شوند؟

نوع تغییر ریسک پیشنهادی اقدام
AAA / Authentication Critical Alert فوری + Review
Management ACL Critical Alert فوری
Routing Protocol Core Critical Change Validation
Firewall Rule حساس Critical Approval و Compliance Check
NTP/Syslog High Review و Remediation
SNMP High Security Review
Description Interface Low ثبت History
Banner Low/Medium Compliance Review

همه تغییرها نباید Critical Alert تولید کنند. Severity باید بر اساس Business Impact و Blast Radius تنظیم شود.

Change Window را چگونه وارد Drift Management کنیم؟

Configuration Management به‌تنهایی می‌گوید «چه چیزی تغییر کرد». Change Management Context اضافه می‌کند: آیا تغییر برنامه‌ریزی شده بود؟ چه کسی آن را تأیید کرده بود؟ آیا در Window مجاز انجام شد؟

برای طراحی عملی:

  1. Change Request در ITSM ثبت شود.
  2. Device Scope و Commands/Plan مشخص شوند.
  3. Approval انجام شود.
  4. Maintenance Window تعریف شود.
  5. قبل از اجرا Backup و Baseline Check انجام شود.
  6. Change اجرا شود.
  7. NCM Version جدید را ثبت کند.
  8. Diff با Plan تطبیق داده شود.
  9. Post-check انجام شود.
  10. در صورت موفقیت Baseline در صورت نیاز Update شود.

مقاله Standard، Normal یا Emergency Change؛ چه زمانی CAB لازم است؟ برای طراحی Governance تغییرات مکمل این بخش است.

Approval در Network Configuration Manager چه کمکی می‌کند؟

ManageEngine برای NCM قابلیت RBAC و Approval Mechanism ارائه می‌دهد. هدف این است که هر Operator نتواند بدون کنترل، Configuration حساس را روی Deviceهای Production Deploy کند.

یک مدل ساده:

  • Operator تغییر را آماده می‌کند.
  • Admin یا Reviewer آن را بررسی می‌کند.
  • پس از Approval، Upload/Execution انجام می‌شود.
  • Change در History ثبت می‌شود.

برای تیم‌هایی با چند شیفت، چند پیمانکار یا چند Site، این تفکیک وظایف اهمیت بیشتری دارد.

RBAC جلوی همه Driftها را نمی‌گیرد

حتی با RBAC، Engineer ممکن است مستقیماً از CLI یا ابزار دیگری به Device متصل شود. بنابراین RBAC باید همراه Real-time Change Detection استفاده شود.

ترکیب درست:

  • RBAC برای کنترل تغییر از داخل NCM؛
  • AAA/TACACS/RADIUS برای کنترل دسترسی Device؛
  • Change Tracking برای دیدن تغییر مستقیم CLI؛
  • Baseline برای تشخیص Drift؛
  • ITSM برای Authorization Context.

Automatic Rollback؛ مفید اما خطرناک اگر بدون طراحی باشد

NCM امکان Rollback به Version قبلی یا Baseline را دارد و در برخی Ruleها می‌توان واکنش خودکار تعریف کرد. اما Auto-Rollback نباید برای هر Change فعال شود.

فرض کنید تغییر Emergency برای جلوگیری از Loop انجام شده است؛ اگر سیستم آن را صرفاً به‌دلیل تفاوت با Baseline فوراً Rollback کند، Incident دوباره برمی‌گردد.

بنابراین Auto-Rollback را فقط در Ruleهای کم‌ابهام استفاده کنید.

مناسب برای Auto-Rollback

  • فعال شدن Telnet در محیطی که Policy صریحاً آن را ممنوع کرده است؛
  • تغییر مشخص Security Command روی Deviceهای استاندارد؛
  • Drift شناخته‌شده با Remediation کاملاً تست‌شده.

نامناسب برای Auto-Rollback

  • Routing Change پیچیده؛
  • Emergency Change؛
  • Firewall Rule وابسته به Incident؛
  • Configurationهایی که Context زیادی دارند.

Configlet چه نقشی در Remediation دارد؟

Configlet در Network Configuration Manager برای Automation Commandها و Configuration Taskها استفاده می‌شود. به‌جای اینکه Engineer روی ده‌ها Device Command مشابه را دستی اجرا کند، Template قابل کنترل ساخته می‌شود.

در Drift Remediation، Configlet می‌تواند برای اصلاح استانداردهای مشخص استفاده شود؛ مثلاً:

  • فعال‌سازی SSH استاندارد؛
  • اصلاح NTP Server؛
  • اعمال Syslog Destination؛
  • اصلاح SNMP Configuration؛
  • اعمال Banner یا Policy مشخص.

قبل از Bulk Deployment باید Pilot، Backup و Rollback Plan وجود داشته باشد.

Configuration Drift و Compliance چه ارتباطی دارند؟

Drift می‌تواند Device را از Compliance خارج کند، حتی اگر در روز اول کاملاً مطابق Policy بوده باشد. به همین دلیل Compliance Check فقط در زمان Audit کافی نیست.

Network Configuration Manager می‌تواند Configurationها را با Policyهای تعریف‌شده بررسی کند و بعد از Change نیز Compliance Status را ارزیابی کند.

اگر تمرکز شما روی اجرای Ruleهای CIS و Auto-remediation کنترل‌شده است، مقاله ComplianceIQ در Network Configuration Manager به‌طور تخصصی همان Intent را پوشش می‌دهد. مقاله حاضر روی Drift و Baseline متمرکز است تا این دو محتوا با هم رقابت نکنند.

سناریوی Multi-vendor؛ Drift بین Cisco، Fortinet و Juniper

در شبکه Multi-vendor استانداردسازی دشوارتر است، چون Syntax و قابلیت Deviceها متفاوت است. هدف Golden Configuration نباید «یک فایل برای همه» باشد.

بهتر است Baselineها بر اساس Class تعریف شوند:

  • Cisco Core Switch؛
  • Cisco Access Switch؛
  • Fortinet Branch Firewall؛
  • Juniper WAN Router؛
  • Data Center Load Balancer.

سپس Ruleهای مشترک در سطح Policy تعریف شوند؛ مثلاً NTP، Logging، Management Access و Protocolهای مجاز.

چرا «آخرین Configuration» همیشه Baseline خوبی نیست؟

اگر آخرین Configuration شامل یک Change اشتباه باشد، Label کردن آن به‌عنوان Baseline خطا را رسمی می‌کند.

قبل از Promote کردن Version به Baseline:

  1. Change Ticket را بررسی کنید.
  2. Diff را مرور کنید.
  3. Compliance را Check کنید.
  4. Service Health را Verify کنید.
  5. Running/Startup Sync را بررسی کنید.
  6. Approver مشخص داشته باشید.

Baseline باید نتیجه Validation باشد، نه صرفاً جدیدترین Timestamp.

Drift بعد از Firmware Upgrade

Firmware یا OS Upgrade می‌تواند Default Behavior، Syntax یا برخی Configurationها را تغییر دهد. پس بعد از Upgrade، فقط Availability Device را بررسی نکنید.

Post-upgrade Checklist:

  • Running Config Backup؛
  • Diff با Pre-upgrade؛
  • AAA/SSH Review؛
  • Routing و Interface Review؛
  • Syslog/NTP/SNMP Review؛
  • Compliance Check؛
  • Baseline Update پس از تأیید.

Drift بعد از Disaster Recovery

در Recovery ممکن است Device با Configuration قدیمی بالا بیاید. اگر Backup Repository و Baseline مرکزی داشته باشید، Restore سریع‌تر است.

ManageEngine NCM Backupها را Version می‌کند و امکان Restore به Version مناسب یا Baseline را فراهم می‌کند. نکته مهم این است که Disaster Recovery Drill باید شامل Restore واقعی Configuration هم باشد، نه فقط وجود فایل Backup.

چه Backup Policy برای NCM مناسب است؟

یک Policy واحد برای همه Deviceها لازم نیست.

Device Class پیشنهاد
Core/Edge/Firewall Real-time Change Backup + Scheduled Backup
Distribution Daily + Change Detection
Access Switch Daily/Weekly بسته به Change Rate
Lab Scheduled Backup سبک‌تر

در NCM می‌توان Backupهای Scheduled و Change-triggered را ترکیب کرد. هدف این است که برای Deviceهای Critical، Recovery Point Configuration نزدیک‌تر به زمان واقعی باشد.

Configuration Versioning برای RCA چه ارزشی دارد؟

فرض کنید Incident ساعت ۱۴:۲۰ شروع شده است. Performance Monitoring نشان می‌دهد Packet Loss بالا رفته و Routing تغییر کرده است. در NCM می‌بینید Configuration ساعت ۱۴:۱۵ تغییر کرده است.

این Correlation یک سرنخ قوی می‌سازد:

Change at 14:15 → Performance degradation at 14:20 → Incident at 14:22

در معماری یکپارچه ITOM، داده Configuration باید کنار Monitoring دیده شود. مقاله Network Path Analysis در OpManager نمونه‌ای از تحلیل مسیر را پوشش می‌دهد؛ ترکیب Path Performance با Config Change می‌تواند Root Cause را سریع‌تر محدود کند.

NCM مستقل یا OpManager Nexus/Plus؟

Network Configuration Manager به‌صورت محصول مستقل ManageEngine ارائه می‌شود. از طرف دیگر، ManageEngine در نسل فعلی پلتفرم یکپارچه خود، OpManager Nexus را به‌عنوان نام جدید OpManager Plus معرفی کرده است و Network Configuration Management جزو قابلیت‌های Network Bundle آن است.

انتخاب مناسب برای
Network Configuration Manager مستقل تمرکز مستقیم روی Backup، Change، Compliance و Automation Configuration
OpManager Nexus / OpManager Plus نیاز یکپارچه به Performance، Flow، NCM، IPAM/SPM، Application و سایر لایه‌های ITOM

برای بررسی پلتفرم یکپارچه، صفحه OpManager Plus مدانت مرجع تجاری این Pillar است.

Change Management Rules را چگونه طراحی کنیم؟

Ruleها را از Business Risk شروع کنید، نه از تعداد Device.

نمونه:

Rule Scope Action
Critical Config Change Core/Firewall Email + Ticket + Admin Review
Unauthorized CLI Change Production Devices Alert + Change Validation
Running/Startup Mismatch Critical Network High Priority Alert
Low-risk Change Lab/Access History Only یا Digest
Known Security Drift Standard Device Group Approved Remediation/Configlet

چه KPIهایی برای Configuration Drift مناسب‌اند؟

  • تعداد Configuration Change در ماه؛
  • درصد Changeهای Authorized؛
  • تعداد Drift نسبت به Baseline؛
  • Mean Time to Detect Drift؛
  • Mean Time to Remediate Drift؛
  • تعداد Running/Startup Mismatch؛
  • Rollback Success Rate؛
  • Backup Success Rate؛
  • درصد Deviceهای دارای Baseline معتبر؛
  • درصد Changeهایی که Compliance را Fail کرده‌اند.

اگر فقط تعداد Backup را گزارش کنید، کیفیت Configuration Governance مشخص نمی‌شود.

Runbook پیشنهادی برای Drift Detection

  1. NCM Alert تغییر را دریافت می‌کند.
  2. Device Criticality مشخص می‌شود.
  3. Diff با Baseline بررسی می‌شود.
  4. User/Time/Change Source بررسی می‌شود.
  5. Change Ticket یا Emergency Record جست‌وجو می‌شود.
  6. Running/Startup Status بررسی می‌شود.
  7. Performance/Availability همان بازه بررسی می‌شود.
  8. Change به Authorized یا Unauthorized طبقه‌بندی می‌شود.
  9. در صورت نیاز Rollback یا Configlet اجرا می‌شود.
  10. Post-check و Compliance Check انجام می‌شود.
  11. Baseline فقط پس از Approval Update می‌شود.

Runbook پیشنهادی برای Change Window

قبل از Window:

  • Backup موفق؛
  • Baseline مشخص؛
  • Diff Plan آماده؛
  • Rollback Plan تست‌شده؛
  • Monitoring فعال؛
  • Approval ثبت‌شده.

حین Window:

  • Change Tracking فعال؛
  • هر Version ثبت شود؛
  • Health Check مرحله‌ای انجام شود.

بعد از Window:

  • Final Diff؛
  • Running/Startup Sync؛
  • Compliance Check؛
  • Service Verification؛
  • Close Change؛
  • در صورت لزوم Promote Baseline.

۱۰ خطای رایج در مدیریت Configuration Drift

  1. داشتن Backup بدون Baseline.
  2. فرض اینکه آخرین Version همیشه سالم است.
  3. فعال کردن Alert برای همه Changeها بدون Severity.
  4. Auto-Rollback روی Changeهای پیچیده.
  5. نادیده گرفتن Running/Startup Mismatch.
  6. اجازه تغییر مستقیم CLI بدون Change Tracking.
  7. نداشتن Owner برای Baseline.
  8. Update کردن Baseline قبل از Post-check.
  9. جدا کردن NCM از ITSM و Monitoring.
  10. تست نکردن Restore تا روز Incident.

چک‌لیست استقرار Configuration Drift Management

  • Deviceهای Critical Classify شده‌اند.
  • Credentialها با Least Privilege مدیریت می‌شوند.
  • Running و Startup Backup فعال است.
  • Baseline برای Deviceهای Production تعیین شده است.
  • Real-time Change Detection برای Deviceهای حساس فعال است.
  • Diff View در Runbook استفاده می‌شود.
  • RBAC و Approval تعریف شده است.
  • Change Ruleها بر اساس Risk تنظیم شده‌اند.
  • ITSM Ticket/Change Context در Investigation استفاده می‌شود.
  • Auto-Rollback فقط برای Use Caseهای کم‌ابهام فعال است.
  • Configletها قبل از Bulk Deployment تست می‌شوند.
  • Running/Startup Mismatch Alert دارد.
  • Compliance بعد از Change بررسی می‌شود.
  • Restore Drill دوره‌ای اجرا می‌شود.
  • KPIهای Drift و Remediation گزارش می‌شوند.

نکات کلیدی

  • Configuration Backup و Configuration Drift Management یک چیز نیستند.
  • Baseline باید تأییدشده باشد، نه صرفاً آخرین Version.
  • Real-time Change Tracking فاصله بین Change و Detection را کم می‌کند.
  • Diff View برای تشخیص Command-level Change حیاتی است.
  • Running/Startup Mismatch یکی از Driftهای پنهان و پرریسک است.
  • RBAC، Approval، ITSM و NCM باید کنار هم کار کنند.
  • Auto-Rollback برای همه تغییرها مناسب نیست.
  • در OpManager Nexus/Plus نیز Network Configuration Management داخل Network Bundle ارائه می‌شود.

منابع

سخن پایانی

Configuration Drift معمولاً با یک تغییر بزرگ شروع نمی‌شود؛ با مجموعه‌ای از تغییرهای کوچک، موقت و فراموش‌شده شکل می‌گیرد. سازمانی که فقط Backup می‌گیرد اما Baseline، Change Tracking و Drift Review ندارد، ممکن است فایل Recovery داشته باشد اما نداند وضعیت واقعی شبکه چه زمانی از استاندارد فاصله گرفته است.

Network Configuration Manager با ترکیب Backup، Versioning، Baseline، Diff، Real-time Change Detection، RBAC، Approval و Rollback کمک می‌کند Configuration Management از یک Repository فایل به یک فرآیند Governance تبدیل شود. وقتی این داده با ITSM و Performance Monitoring ترکیب شود، تیم شبکه هم سریع‌تر Root Cause را پیدا می‌کند و هم Changeهای پرریسک را قبل از تبدیل شدن به Incident کنترل می‌کند.

مدانت می‌تواند در استعلام و خرید لایسنس Network Configuration Manager و OpManager Plus/Nexus، طراحی Baseline، Configuration Backup، Change Tracking، Compliance، Configlet Automation، استقرار، Integration با ITSM، آموزش و پشتیبانی همراه سازمان باشد. برای بررسی پلتفرم یکپارچه از OpManager Plus مدانت، برای استعلام لایسنس از فروشگاه و استعلام ManageEngine و برای طراحی Scope از تماس با مدانت استفاده کنید.

مطالب مرتبط جهت افزایش سطح دانش شما:

33

دیدگاه شما

دیدگاه مرتبط و محترمانه بنویسید.