Odpowiedź.

Zero Downtime Deployment — praktyka aktualizacji aplikacji bez przerywania działania i niedostępności dla użytkowników. Osiąga się to przez stopniowe wyłączanie starych i włączanie nowych instancji aplikacji.

Przykład realizacji dla aplikacji stateless w chmurze (np. z użyciem Kubernetes):

1. Wdrożenie nowej wersji podów, nie zabijając starych.
2. Sprawdzenie, że nowe instancje są zdrowe.
3. Dopiero po tym przekierowanie ruchu na nie (blue-green/release lub rolling update).
4. Stare kontenery są stopniowo wyłączane po pełnej pewności co do nowej wersji.

Przykład deployment.yaml z rolling update:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-app:v2

Kluczowe cechy:

• Wymaga stateless serwisów lub specjalistycznych strategii migracji stanu.
• Często realizowane za pomocą rolling update lub blue-green deployment.
• Dla zero downtime na poziomie bazy danych wymagane są migracje w kilku etapach (backward/forward-compatible schemy).

Pytania z pułapką.

Zero Downtime Deployment jest niemożliwe przy zmianie schemy danych?

Jest możliwe, jeśli migracje schematu są realizowane w dwóch krokach: najpierw kod staje się zgodny ze starą i nową schemą, a następnie — sama migracja i usunięcie legacy-kodu.

Jeśli aplikacja jest stateless, zero downtime deployment zawsze jest gwarantowany?

Nie! Ograniczającym czynnikiem może być zewnętrzny stan, czas oczekiwania na połączenia, nieprzetworzone zapytania lub nieobsługiwane zmiany niezgodne wstecz w API.

Zero Downtime Deployment jest potrzebny tylko dużym firmom?

Nie. Nawet dla małych startupów i rozwiązań SaaS zero downtime — krytyczny czynnik dla doświadczeń użytkowników (szczególnie na rynkach globalnych i przy dużym obciążeniu).