Налаштування RTO (Recovery Time Objective) та RPO (Recovery Point Objective)

Налаштування RTO та RPO для критичних систем

RTO (Recovery Time Objective) — максимально допустимий час простоя після сбою. RPO (Recovery Point Objective) — максимально допустима втрата даних у одиницях часу. Ці два параметри визначають всю архітектуру резервування: чим нижче значення, тим дорожча інфраструктура.

Залежність вартості від RTO/RPO

Визначення бізнес-вимог

# Розрахунок вартості простоя для визначення прийнятного RTO
class RtoCalculator:
    def calculate_downtime_cost(
        self,
        hourly_revenue: float,
        customer_churn_per_hour: float,
        penalty_per_sla_violation: float,
        avg_customer_lifetime_value: float,
        total_customers: int
    ) -> dict:

        costs_per_hour = {
            'lost_revenue': hourly_revenue,
            'customer_churn': (customer_churn_per_hour / 100) * total_customers
                             * avg_customer_lifetime_value,
            'sla_penalties': penalty_per_sla_violation,
            'recovery_labor': 500
        }

        total_per_hour = sum(costs_per_hour.values())

        return {
            'cost_per_hour': total_per_hour,
            'recommended_rto': self._recommend_rto(total_per_hour),
        }

PostgreSQL: конфігурація для RPO = 5 хвилин

# postgresql.conf — WAL archiving для PITR
wal_level = replica
archive_mode = on
archive_command = 'pgbackrest --stanza=main archive-push %p'

# Частота checkpoint
checkpoint_timeout = 5min

Patroni: автоматичний failover (RTO < 30 сек)

# /etc/patroni/patroni.yml
scope: postgres-cluster
namespace: /service/
name: pg-node-1

bootstrap:
  dcs:
    ttl: 30               # failover через 30 сек без heartbeat
    maximum_lag_on_failover: 1048576

  postgresql:
    parameters:
      wal_level: replica
      hot_standby: on
      max_wal_senders: 10
      archive_mode: on
      archive_command: 'pgbackrest --stanza=main archive-push %p'

HAProxy: маршрутизація з урахуванням ролі

# haproxy.cfg
frontend postgres_write
  bind *:5432
  default_backend postgres_primary

backend postgres_primary
  option httpchk GET /master
  http-check expect status 200
  server pg-node-1 pg-node-1-ip:5432 check port 8008
  server pg-node-2 pg-node-2-ip:5432 check port 8008
  server pg-node-3 pg-node-3-ip:5432 check port 8008

frontend postgres_read
  bind *:5433
  default_backend postgres_replicas

backend postgres_replicas
  balance roundrobin
  option httpchk GET /replica
  http-check expect status 200
  server pg-node-1 pg-node-1-ip:5432 check port 8008
  server pg-node-2 pg-node-2-ip:5432 check port 8008
  server pg-node-3 pg-node-3-ip:5432 check port 8008

Моніторинг RTO/RPO метрик

# Prometheus alerting для SLA нарушень
- alert: ReplicationLagCritical
  expr: postgresql_replication_lag_seconds > 300
  for: 2m
  labels:
    severity: critical
  annotations:
    summary: "RPO at risk: replica lag {{ $value }}s > 5min RPO target"

Тривалість

Налаштування Patroni + pgBackRest + HAProxy для досягнення RTO < 30 хв та RPO < 5 хв — 3–5 робочих днів.