Zero‑Downtime Deployment: راهنمای مهندسی برای استقرار بدون توقف در زیرساخت‌های ایرانی

Zero‑Downtime Deployment به‌معنی استقرار به‌صورت پیوسته بدون توقف سرویس برای کاربران نهایی است؛ این مقاله با تحلیل معماری، مقایسه فنی روش‌های Blue‑Green، Canary و Rolling، نمونه کد Kubernetes، چالش‌های بومی‌سازی در زیرساخت‌های ایران و پرسش‌های فنی، راهنمایی عملی برای تیم‌های DevOps ارائه می‌دهد.

۱. مقدمه و ضرورت استقرار بدون توقف

در محیط‌های میکروسرویس‌محور، هر به‌روزرسانی نرم‌افزاری می‌تواند خطر Downtime را به‌وجود آورد. با توجه به SLAهای ۹۹٫۹۹٪ (حداکثر ۵۲٫۵ ثانیه Downtime در ماه) و نیاز به تجربه کاربری بی‌وقفه، Zero‑Downtime Deployment تبدیل به یک ضرورت مهندسی می‌شود. معیارهای کلیدی شامل Latency (هدف < 30 ms)، Throughput (حداقل ۱۰,۰۰۰ req/s) و مصرف حافظه (≤ 4 GB) برای هر نسخه جدید هستند.

۲. الگوهای Zero‑Downtime Deployment

۲.۱. Blue‑Green Deployment

در این الگو دو محیط (Blue و Green) به‌صورت همزمان فعال هستند؛ پس از تست کامل نسخه جدید در محیط Green، ترافیک به‌صورت یک‌باره به آن منتقل می‌شود. زمان تغییر (Switch‑over) معمولاً زیر ۲ ثانیه است، اما هزینه حافظه دو برابر می‌شود.

۲.۲. Canary Release

در Canary، نسخه جدید به‌صورت تدریجی به درصدی از کاربران (مثلاً ۱۰٪) ارائه می‌شود. این روش امکان مانیتورینگ دقیق Latency و Error Rate را فراهم می‌کند؛ در صورت بروز مشکل می‌توان به سرعت به نسخه قبلی بازگشت. زمان تغییر برای هر گام معمولاً ۱‑۲ ثانیه است.

۲.۳. Rolling Update

در Rolling Update، سرورهای موجود به‌تدریج جایگزین می‌شوند؛ هر گام با maxSurge و maxUnavailable تنظیم می‌شود. این روش مصرف حافظه را به‌حداقل می‌رساند (معمولاً +0.5 GB نسبت به حالت ثابت) و Downtime را به زیر ۱۰۰ ms کاهش می‌دهد.

۳. جدول مقایسه فنی روش‌ها

روش	Downtime (ثانیه)	Latency متوسط (ms)	Throughput (req/s)	حافظه مصرفی (GB)	ROI (٪)
Blue‑Green	0.5‑2	25‑35	9,800‑10,200	8 (دو محیط)	+12
Canary	1‑3 (هر گام)	22‑30	10,000‑10,500	4.5	+18
Rolling Update	0.05‑0.1	20‑28	10,200‑10,800	4.2	+22
Feature Flag	0 (درون‌کد)	15‑25	10,500‑11,000	5 (افزایش کد)	+25

۴. نمونه کد پیاده‌سازی Rolling Update در Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  replicas: 6
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2        # 33% افزایش موقت
      maxUnavailable: 1 # حداکثر یک پاد در هر زمان غیرفعال
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: webapp
        image: registry.example.com/webapp:v2.1.0
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            path: /healthz
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 3
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 5"]

در این مثال، با تنظیم maxSurge=2 و maxUnavailable=1، حداکثر دو پاد جدید همزمان ساخته می‌شوند و یک پاد قدیمی تا زمان آماده‌سازی کامل سرویس جدید غیرفعال می‌ماند؛ این ترکیب باعث می‌شود Downtime زیر ۱۰۰ ms باقی بماند.

۵. چالش‌های بومی‌سازی، امنیت و مقیاس‌پذیری در زیرساخت ایران

پیاده‌سازی Zero‑Downtime Deployment در ایران با محدودیت‌های زیرساختی و قانونی مواجه است:

• پهنای باند محدود: ISPهای داخلی معمولاً حداکثر ۱۰۰ Mbps برای دیتاسنترهای محلی فراهم می‌کنند؛ بنابراین استراتژی Canary باید با گام‌های کوچک (۵٪) و مانیتورینگ دقیق Latency (حداکثر ۴۰ ms) اجرا شود.
• قوانین داده‌محور: ذخیره‌سازی داده‌های حساس در دیتاسنترهای داخلی الزامی است؛ برای Blue‑Green باید از Replication بین دو دیتاسنتر (تهران‑مشهد) استفاده کرد که هزینه حافظه را ۲‑۳ GB افزایش می‌دهد.
• دسترسی به CDN داخلی: استفاده از CDNهای داخلی (آی‌نوا، پارس‌نت) می‌تواند Latency را از ۲۵ ms به زیر ۱۵ ms کاهش دهد؛ اما نیاز به تنظیم Headerهای مخصوص CDN دارد.
• امنیت شبکه: فایروال‌های ملی (مانند فایروال‌پذیر) مانع برخی پورت‌های Docker می‌شوند؛ بنابراین باید از سرویس‌های داخلی (NodePort یا ClusterIP) به‌جای LoadBalancer استفاده کرد.
• پایداری برق: در مناطق با قطع برق مکرر، استفاده از UPS و تنظیم Rolling Update با maxSurge=0 (بدون افزایش موقت) خطر از دست رفتن پادها را کاهش می‌دهد.

با در نظر گرفتن این چالش‌ها، ترکیب Rolling Update با Feature Flag به‌عنوان بهترین راهکار برای اکثر سرویس‌های وب در ایران شناخته می‌شود؛ زیرا نیاز به منابع اضافی کمتر است و می‌تواند به‌سرعت به‌روزرسانی‌های کوچک را اعمال کند.

۶. چک‌لیست اجرایی برای Zero‑Downtime Deployment

• آماده‌سازی محیط: اطمینان از وجود دو محیط (Blue/Green) یا حداقل یک ReplicaSet سالم با حداقل ۳ پاد فعال.
• پیکربندی Readiness Probe: زمان تاخیر اولیه ≤ 5 s و دوره بررسی ≤ 3 s برای تشخیص سریع وضعیت سرویس.
• تنظیم maxSurge / maxUnavailable: برای سرویس‌های حساس به Latency، maxSurge=1 و maxUnavailable=0 تنظیم کنید.
• مانیتورینگ کلیدی: ثبت Latency، Error Rate، CPU (≤ 70٪) و Memory (≤ 4 GB) در زمان استقرار.
• Rollback خودکار: تعریف آستانه‌های Error Rate > 2٪ یا Latency > 40 ms برای بازگشت به نسخه قبلی.
• آزمون‌های پس از استقرار: اجرای Smoke Test‌های API (حداقل ۱۰ درخواست) قبل از انتشار کامل.

۷. جمع‌بندی و نتایج کلیدی

Zero‑Downtime Deployment با ترکیب استراتژی‌های Blue‑Green، Canary یا Rolling Update می‌تواند Downtime را زیر ۰٫۱ ثانیه نگه دارد، Latency متوسط زیر ۳۰ ms، و Throughput بیش از ۱۰,۰۰۰ req/s را تضمین کند. در زیرساخت‌های ایرانی، محدودیت‌های پهنای باند، قوانین داده‌محور و پایداری برق نقش مهمی در انتخاب روش مناسب دارند؛ بنابراین ترکیب Rolling Update با Feature Flag به‌عنوان بهینه‌ترین راهکار شناخته می‌شود.

پرسش‌های متداول مهندسی (FAQ)

چگونه می‌توان با استفاده از Canary به‌صورت تدریجی ۵٪ کاربر را به نسخه جدید منتقل کرد؟

با تنظیم وزن ترافیک در سرویس Mesh (مثلاً Istio) به ۰.۰۵ برای نسخه جدید و ۰.۹۵ برای نسخه قبلی، می‌توانید گام‌های ۵٪ را به‌صورت خودکار اعمال کنید؛ سپس با مانیتورینگ Latency و Error Rate تصمیم به ادامه یا بازگشت می‌گیرید.

آیا می‌توان Rolling Update را بدون افزایش حافظه (maxSurge=0) اجرا کرد؟

بله؛ با maxSurge=0 و maxUnavailable=1، هر بار یک پاد قدیمی حذف و جایگزین می‌شود؛ این روش حافظه ثابت را حفظ می‌کند اما زمان استقرار طولانی‌تر (حدود ۲‑۳ دقیقه برای ۶ پاد) می‌شود.

در صورتی که سرویس پس از استقرار به‌سرعت خطا بدهد، چه مکانیسمی برای Rollback خودکار وجود دارد؟

می‌توانید از Kubernetes Deployment با ویژگی "progressDeadlineSeconds" استفاده کنید؛ اگر پس از این زمان معیارهای سلامت (Readiness) برآورده نشوند، Deployment به نسخه قبلی باز می‌گردد. همچنین می‌توانید از ابزارهای CI/CD مانند Argo Rollouts برای تعریف آستانه‌های خطا (مثلاً Error Rate > 2٪) استفاده کنید.