فرض کنید ساعت ۹ صبح است، دهها کاربر در حال ثبت Ticket هستند و ناگهان سرور اصلی ServiceDesk Plus از دسترس خارج میشود. اگر کل میزخدمت روی یک Node، یک Database Path یا یک Storage Point متمرکز باشد، اختلال فقط یک مشکل فنی نیست؛ فرآیند Incident، Change، SLA، ارتباط با کاربران و حتی Escalationها هم متوقف میشوند.
برای سازمانهایی که ServiceDesk Plus به سرویس حیاتی تبدیل شده، طراحی High Availability در ServiceDesk Plus باید از ابتدا با نگاه حذف Single Point of Failure انجام شود. این مقاله روی طراحی Failover، وابستگیهای Database و File Storage، سناریوی Planned/Unplanned Outage، تست Recovery و ارتباط HA با DR تمرکز دارد.
HA با Backup فرق دارد
| کنترل | هدف اصلی | زمان استفاده |
|---|---|---|
| Backup | بازگردانی داده | خرابی داده یا Disaster |
| High Availability | ادامه سرویس با کمترین توقف | خرابی Node یا Service |
| Disaster Recovery | بازگردانی در سایت/زیرساخت جایگزین | اختلال گسترده |
سازمان ممکن است Backup عالی داشته باشد اما HA نداشته باشد؛ در این حالت Recovery ممکن است ساعتها طول بکشد.
Single Point of Failureها را پیدا کنید
- Application Node؛
- Database Server؛
- Shared File Storage؛
- DNS یا Load Balancer؛
- SMTP/Notification Dependency؛
- Authentication Source مثل AD/LDAP؛
- Backup Repository؛
- SSL Certificate و Key Management.
طراحی HA فقط Duplicate کردن Application Server نیست؛ زنجیره وابستگی باید بررسی شود.
معماری پیشنهادی HA
در طراحی متداول، حداقل دو Application Node در نظر گرفته میشوند و Database باید از نظر Availability مستقل بررسی شود. اگر DB هنوز روی یک سرور بدون Failover باشد، HA در لایه Application کامل نیست.
| لایه | کنترل پیشنهادی |
|---|---|
| Application | Active/Standby یا معماری پشتیبانیشده محصول |
| Database | HA مطابق DB Platform |
| Storage | Redundant و دارای Backup مستقل |
| Access | DNS/Load Balancer با Health Check |
| Monitoring | مانیتورینگ Node، DB و Service URL |
RTO و RPO را قبل از معماری تعیین کنید
بدون RTO و RPO، طراحی HA تبدیل به خرید زیرساخت بدون معیار میشود. اگر RTO میزخدمت ۱۵ دقیقه است، معماری باید Failover سریعتری نسبت به محیطی با RTO چهار ساعت داشته باشد.
برای درک بهتر مفاهیم RTO و RPO میتوانید به محتوای مرتبط مدانت در حوزه تداوم خدمت و Disaster Recovery مراجعه کنید و این شاخصها را به BIA سازمان متصل کنید.
Planned Failover را تمرین کنید
یکی از بهترین روشها این است که Failover فقط در بحران واقعی تجربه نشود. Maintenance Window دورهای برای جابهجایی کنترلشده بین Nodeها در نظر بگیرید.
چکلیست Planned Failover
- ثبت Change در ServiceDesk Plus.
- بررسی Backup و Health Database.
- تأیید Sync و Dependencyها.
- جابهجایی Traffic یا Service Role.
- تست Login، Ticket Creation و Attachment.
- تست Email Fetch/Notification.
- ثبت زمان Failover و خطاها.
Unplanned Failover چه تفاوتی دارد؟
در خرابی واقعی، تیم زمان آمادهسازی ندارد. بنابراین Detection باید خودکار یا بسیار سریع باشد. Monitoring باید Availability URL، Process، Database Connectivity و Queueهای حیاتی را پوشش دهد.
HA بدون Monitoring ناقص است
برای پایش زیرساخت ServiceDesk Plus میتوان از ابزارهای ITOM مانند OpManager و Applications Manager استفاده کرد. این کار کمک میکند خرابی Node یا Database قبل از شکایت گسترده کاربران شناسایی شود.
مقاله مانیتورینگ SQL Server با Applications Manager نمونهای از طراحی Monitoring برای Database Dependency است.
Attachment و File Storage را فراموش نکنید
در بسیاری از پروژهها Database HA میشود اما Attachmentها روی Local Disk یک Node باقی میمانند. نتیجه این است که پس از Failover، Ticket باز میشود اما فایلها در دسترس نیستند. Shared Storage یا Storage Architecture باید با مدل پشتیبانیشده ServiceDesk Plus هماهنگ باشد.
Authentication Dependency
اگر Login کاربران از AD/LDAP انجام میشود، خرابی Domain Controller یا شبکه احراز هویت میتواند شبیه خرابی ServiceDesk Plus دیده شود. بنابراین Health Check فقط Application URL کافی نیست.
HA و ServiceDesk Plus Integration
اگر ServiceDesk Plus به Monitoring، ERP، HRMS، Email Gateway یا APIهای دیگر متصل است، Failover باید Integration Endpointها را هم حفظ کند. برای Integrationهای رویدادمحور، مقاله Webhook در ServiceDesk Plus مکمل این موضوع است.
سناریوی Failover واقعی
فرض کنید Node اصلی به دلیل خرابی OS Down شده است. Runbook پیشنهادی:
- تأیید Incident و Scope.
- بررسی سلامت Database و Storage.
- فعالسازی Node جایگزین طبق معماری.
- بررسی DNS/Load Balancer.
- تست Login، Ticket، Attachment و Notification.
- اعلام وضعیت به ذینفعان.
- Root Cause Analysis برای Node اصلی.
- بازگرداندن Redundancy پس از Repair.
HA با DR چگونه کنار هم قرار میگیرد؟
HA معمولاً خرابی محلی Node یا Service را پوشش میدهد. اگر کل Data Center از دسترس خارج شود، DR Site یا Recovery Plan جداگانه لازم است. بنابراین HA نباید جایگزین DR تلقی شود.
شاخصهایی که باید اندازهگیری شوند
- Failover Time؛
- Service Availability؛
- تعداد Failoverهای ناموفق؛
- زمان Detection؛
- زمان بازگرداندن Redundancy؛
- تعداد Ticketهای متاثر از Outage؛
- Recovery Test Success Rate.
مسیر استقرار مدانت
برای بررسی لایسنس، پیادهسازی، فارسیسازی، تقویم شمسی، Integration و توسعه اختصاصی، صفحه ServiceDesk Plus مدانت مسیر اصلی است. همچنین برای محتوای تخصصیتر محصول میتوانید از servicedesk.medanet.ir استفاده کنید.
منابع
نکات کلیدی
- HA با Backup و DR یکسان نیست.
- Database و Storage میتوانند Single Point of Failure باقی بمانند.
- Failover باید دورهای تست شود.
- Integrationها و Authentication Source هم بخشی از Scope هستند.
- RTO/RPO باید قبل از طراحی معماری مشخص شوند.
سخن پایانی
وقتی ServiceDesk Plus به مرکز عملیات IT تبدیل میشود، Downtime آن مستقیماً روی Incident، SLA و تجربه کاربر اثر میگذارد. HA باید بخشی از طراحی سرویس باشد، نه واکنش بعد از اولین خرابی جدی.
مدانت خدمات طراحی HA و DR برای ServiceDesk Plus، نصب و استقرار، Migration، بهینهسازی Database، فارسیسازی، تقویم شمسی، Integration، توسعه اختصاصی و پشتیبانی ارائه میکند. برای بررسی معماری مناسب سازمان با مدانت در ارتباط باشید.
