چک‌لیست عملی قبل از تغییر روی F5 BIG-IP در محیط Production

تغییر روی F5 BIG-IP در محیط Production معمولاً شبیه تغییر روی یک تجهیز عادی شبکه نیست. یک تغییر کوچک در Virtual Server، Pool، Monitor، SSL Profile یا Persistence می‌تواند مسیر چند سرویس را هم‌زمان تحت تأثیر قرار دهد. به همین دلیل قبل از هر تغییر باید بدانیم دقیقاً چه چیزی قرار است عوض شود، اثر آن روی ترافیک چیست و اگر نتیجه مطلوب نبود چطور سریع و تمیز برگردیم.

این متن یک چک‌لیست اجرایی برای تیم‌هایی است که F5 را در مسیر سرویس‌های واقعی سازمان دارند و می‌خواهند تغییر را با ریسک کمتر انجام دهند. اگر هنوز معماری کلی F5 برایتان روشن نیست، ابتدا صفحه F5 Load Balancer و مفاهیم BIG-IP را ببینید.

۱. قبل از تغییر، محدوده اثر را دقیق مشخص کنید

اولین سؤال این نیست که «چه کامندی بزنیم؟»؛ سؤال اصلی این است که این تغییر روی کدام سرویس‌ها اثر می‌گذارد. برای هر تغییر، این موارد را یادداشت کنید:

• نام Partition، Virtual Server و Pool مربوطه
• نام Nodeها و Pool Memberهایی که درگیر هستند
• پروفایل‌های مرتبط مثل Client SSL، Server SSL، HTTP، TCP و OneConnect
• نوع Persistence و اینکه کاربران فعال ممکن است Session از دست بدهند یا نه
• وابستگی به DNS، فایروال، WAF، Reverse Proxy یا Route بیرونی

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

۲. بکاپ و خروجی خوانا بگیرید

قبل از تغییر، فقط گرفتن UCS کافی نیست. UCS برای بازگردانی کامل مفید است، اما در یک تغییر کوچک معمولاً به خروجی خوانا هم نیاز دارید تا بتوانید تفاوت قبل و بعد را سریع ببینید.

tmsh save sys config
tmsh save sys ucs /var/local/ucs/before-change.ucs
tmsh list ltm virtual /Common/example_vs
tmsh list ltm pool /Common/example_pool
tmsh list ltm profile client-ssl /Common/example_clientssl

اگر تغییر از طریق GUI انجام می‌شود، باز هم خروجی tmsh از آبجکت‌های درگیر بگیرید. اسکرین‌شات کمک می‌کند، اما برای بررسی دقیق و مقایسه بعدی کافی نیست.

۳. وضعیت سلامت سرویس را قبل از تغییر ثبت کنید

قبل از دست زدن به تنظیمات، وضعیت فعلی باید روشن باشد. اگر Pool از قبل عضو Down دارد یا Monitor خطا می‌دهد، بعد از تغییر نمی‌توان فهمید مشکل جدید است یا قدیمی.

• وضعیت Virtual Server: Available، Offline یا Unknown
• وضعیت Pool Memberها و دلیل Down بودن احتمالی
• نتیجه تست سرویس از سمت کاربر یا Probe بیرونی
• لاگ‌های مرتبط در /var/log/ltm
• مصرف CPU، Memory و تعداد Connectionها در زمان تغییر

برای طراحی بهتر Monitorها، مطلب طراحی Health Monitor در F5 BIG-IP هم مکمل همین چک‌لیست است.

۴. برنامه Rollback را قبل از اجرا بنویسید

Rollback نباید بعد از خراب شدن سرویس طراحی شود. قبل از اجرا مشخص کنید اگر نتیجه بد بود، دقیقاً چه کاری انجام می‌دهید: حذف Rule جدید، برگرداندن SSL Profile قبلی، تغییر Persistence به حالت قبل، یا Restore کردن تنظیم یک آبجکت خاص.

برای تغییرهای حساس، Rollback باید کوتاه، قابل اجرا و قابل تست باشد. جمله‌هایی مثل «اگر نشد برمی‌گردانیم» برنامه Rollback نیستند.

۵. تغییر را کوچک و قابل مشاهده اجرا کنید

اگر هم‌زمان Monitor، Pool، SSL، iRule و Persistence را تغییر دهید، در زمان خطا نمی‌دانید کدام بخش عامل مشکل بوده است. تا جایی که ممکن است تغییر را به چند مرحله کوچک تقسیم کنید و بعد از هر مرحله وضعیت سرویس را بررسی کنید.

• اول تغییر کم‌ریسک‌تر را اعمال کنید.
• بعد از هر تغییر، وضعیت Pool و Virtual Server را ببینید.
• با یک تست واقعی از مسیر کاربر، فقط به Green بودن GUI اکتفا نکنید.
• در تغییرهای SSL، هم Client-side و هم Server-side را بررسی کنید.

۶. بعد از تغییر، فقط Up بودن کافی نیست

سرویسی که Up است ممکن است برای بخشی از کاربران خطا بدهد. بعد از تغییر باید چند نشانه را با هم بررسی کنید: پاسخ HTTP، زمان پاسخ، لاگ اپلیکیشن، خطاهای SSL، وضعیت Session، و اینکه Persistence رفتار مورد انتظار دارد یا نه.

اگر تغییر روی رفتار Session اثر دارد، مطلب Persistence در F5؛ Source Address یا Cookie می‌تواند برای انتخاب روش درست کمک کند.

۷. مستندسازی کوتاه اما دقیق

در پایان تغییر، مستند کنید چه چیزی تغییر کرد، چه کسی اجرا کرد، چه زمانی انجام شد، خروجی تست چه بود و آیا موردی برای پیگیری باقی مانده است یا نه. مستند خوب طولانی نیست؛ قابل استفاده در تغییر بعدی است.

جمع‌بندی

تغییر امن روی F5 BIG-IP بیشتر از اینکه وابسته به حفظ کردن کامندها باشد، به کنترل اثر تغییر وابسته است. قبل از اجرا محدوده اثر را بشناسید، خروجی قابل مقایسه بگیرید، Rollback واقعی داشته باشید و بعد از تغییر فقط به سبز بودن وضعیت اکتفا نکنید.

اگر قرار است روی F5 سازمانی تغییر حساس انجام شود یا طراحی فعلی Health Monitor، Persistence، SSL Profile و Poolها نیاز به بازبینی دارد، صفحه طراحی و پیاده‌سازی F5 BIG-IP Load Balancer مسیر مشاوره و اجرای کنترل‌شده را توضیح می‌دهد.