Резервные копии и восстановление AI-стека — что делать, когда API Anthropic недоступен

Время: ~30 мин теории + 40 мин практики

Суть урока

AI-стек в production — это электрическая сеть в доме. Пока работает — ты не замечаешь её. Свет горит, холодильник морозит, ноутбук заряжается. Но раз в год бывает blackout.

И вот здесь делятся два типа домов:

• Дом без генератора — сидишь в темноте, еда в холодильнике портится, работа стоит. Ждёшь когда починят. Часы. Иногда сутки.
• Дом с генератором — за пару минут переключение, свет вернулся, работа продолжается. Соседи в темноте, ты работаешь.

AI-стек работает так же. Anthropic API падает. OpenAI падает. Cloudflare падает. Это не "если", это "когда". Вопрос только — есть ли у тебя план переключения, или ты узнаешь о проблеме одновременно с клиентами.

В этом уроке — 7 типичных disaster scenarios, multi-provider fallback strategy, 3-2-1 backup для AI данных, и playbook на 10 минут когда всё сломалось.

🎨 Образ: пилот гражданской авиации тренируется отрабатывать отказ двигателя в полёте. Не потому что часто случается — а потому что когда случается, у пилота должен быть мышечный навык, не паника. Drill quarterly = твоя тренировка отказа двигателя.

🎯 Decision tree: какой уровень preparedness нужен тебе

Personal use (тебе одному):

• ✓ Git backup конфигов и prompts достаточно
• ✓ Manual recovery ok — потерпеть 4 часа outage не критично
• ✗ Multi-provider fallback избыточен

SMB (есть платящие клиенты, $1-10K MRR):

• ✓ Multi-provider fallback обязателен
• ✓ Nightly backups автоматически
• ✓ Basic monitoring (uptime + LLM errors)
• ✓ Communication templates готовы

Professional ($10-50K MRR, customers полагаются):

• ✓ Full 3-2-1 backup
• ✓ Automated key rotation
• ✓ Drill quarterly
• ✓ Status page публичная

Enterprise ($50K+ MRR, SLA contracts):

• ✓ Multi-region deployment
• ✓ Automated failover
• ✓ 24/7 monitoring + on-call
• ✓ SOC 2 compliance backups

По умолчанию для студентов курса — уровень SMB. Этого хватает для большинства реальных кейсов.

Ключевые концепции

• RTO (Recovery Time Objective) — сколько времени допустимо быть down. Для SMB обычно 30 минут, для enterprise — 5-15 минут
• RPO (Recovery Point Objective) — сколько данных допустимо потерять. Nightly backup = RPO 24 часа, real-time replication = RPO около нуля
• Provider fallback chain — список LLM провайдеров в порядке приоритета с автоматическим переключением при сбое
• 3-2-1 backup — 3 копии данных, 2 разных типа storage, 1 копия off-site (другой регион/cloud)
• Incident playbook — заранее написанная инструкция что делать когда X сломался. Не "придумаем на месте"
• Drill — учебная симуляция disaster для проверки что план реально работает
• Blast radius — на что влияет конкретный сбой. Один LLM провайдер вниз = blast radius "все features использующие его"
• Status page — публичная страница с текущим состоянием сервиса. Customers видят сразу, не пишут support

Теория

7 типичных disaster scenarios

Не теоретические: такие случаи регулярно происходят у провайдеров и разработчиков. Конкретные даты и подробности смотри в публичной истории инцидентов (ссылки в конце урока).

Scenario 1: Anthropic API outage

История: у Anthropic бывают и короткие degraded-окна с повышенной latency и ошибками 5xx, и более долгие инциденты. Реальную историю смотри на status.claude.com.

Impact: всё что зависит от Claude API — не работает. Если у тебя single-provider стек — твой продукт down.

Recovery time:

• Без plan: hours-days (ждёшь когда Anthropic починит + ручное переключение если есть куда)
• С plan: 10 minutes (auto-fallback на OpenAI/Gemini, customers ничего не заметят)

Mitigation: multi-provider fallback chain + status page + customer communication.

Scenario 2: OpenAI API outage

История: у OpenAI бывали крупные сбои, когда ChatGPT и API были недоступны несколько часов. Актуальную историю смотри на status.openai.com.

Impact: GPT-based fallback не спасает если он первым в chain. Хуже — разные провайдеры могут падать в одно время из-за общих upstream зависимостей (например, одних и тех же облачных регионов).

Mitigation: не делай fallback только на OpenAI. Минимум 3 разных провайдера в chain, разные cloud regions.

Scenario 3: Cloudflare/Vercel global incident

История:

• Cloudflare, 21 июня 2022 — ошибка в конфигурации маршрутизации отключила 19 дата-центров примерно на час с четвертью (разбор от Cloudflare)
• Cloudflare, 18 ноября 2025 — сбой в системе защиты от ботов вызвал ошибки 5xx в CDN, а также сбои у Workers KV, Dashboard и Access; основной трафик восстановили примерно через три часа (разбор от Cloudflare)
• У Vercel и других платформ тоже бывают инциденты с deploy и edge-инфраструктурой

Impact: твой Worker/Edge Function down даже если LLM работает нормально. Запросы не доходят до твоего кода.

Mitigation: не клади все яйца в одну CDN корзину. Backup deployment на другом provider'е (AWS Lambda как secondary), DNS failover через Cloudflare Health Checks или AWS Route 53.

Scenario 4: Account suspension (TOS violation)

Типичные причины:

• Автоматическая проверка на нарушение правил сервиса срабатывает ошибочно (false positive)
• Подозрительный billing pattern или спор по платежу
• Нарушение условий использования (иногда непреднамеренное)

Impact: moment-to-moment cut-off. Никакого "у вас 30 дней". Аккаунт мгновенно недоступен.

Recovery time без backup account: дни-недели (support tickets, manual review).

Mitigation: secondary account у каждого critical provider. Разные emails, разные cards, разные billing addresses если возможно. Standby keys уже сохранены и протестированы. Второй аккаунт нужен как запасной, а не для обхода блокировки за нарушение правил: проверь условия провайдера.

Scenario 5: Payment failure

Сценарии:

• Карта expired → auto-renewal failed → service paused
• Bank fraud detection блокирует charge → account suspended
• Limit на корпоративной карте превышен внезапным spike usage

Impact: обычно 24-48h до того как customers начнут видеть downtime. Но плохо если узнаешь от customer'а.

Mitigation:

• Dual cards в каждом аккаунте (primary + backup)
• Email alerts на любой failed charge
• Spending alerts когда usage близко к лимиту карты

Scenario 6: Database/KV corruption

Типичные причины:

• Ошибка провайдера хранилища (KV, векторные базы, Postgres)
• Неправильная migration или ошибка в твоём коде
• Случайное удаление или перезапись данных

Impact: customer data lost, нужен restore с backup. Если backup'а нет — данные потеряны навсегда.

Mitigation: automated nightly backups, point-in-time recovery если provider support'ит, тестирование restore процедуры quarterly.

Scenario 7: Security breach

Real cases:

• API keys случайно committed в public GitHub repo (случается регулярно)
• .env файл попал в Docker image и опубликован
• Stolen developer laptop без encryption

Impact: резкий billing spike за часы (чужие запросы через твой API key), reputation damage, потенциально data leak.

Recovery procedure:

1. Detect (monitoring spending anomaly или GitHub secret scanning alert)
2. Immediately rotate ВСЕ keys (не только leaked — связанные тоже)
3. Audit что accessed
4. Notify customers если data potentially affected
5. Postmortem + prevention

Mitigation: pre-commit hooks (gitleaks, trufflehog), secret rotation quarterly, anomaly detection на billing.

Multi-provider fallback strategy

Базовый паттерн: chain of providers с автоматическим переключением.

# Pseudo-code: provider chain с fallback
providers = [
    # имена моделей — пример; актуальные модели и цены — на странице «Актуальное сейчас» курса
    {"name": "anthropic", "model": "claude-sonnet-5-5", "priority": 1},
    {"name": "openai", "model": "gpt-6.1-sol", "priority": 2},
    {"name": "google", "model": "gemini-3.8-flash", "priority": 3},
    {"name": "local_ollama", "model": "qwen3:8b", "priority": 4}  # last resort
]

def call_llm(prompt, max_retries_per_provider=2):
    errors = []
    for provider in providers:
        try:
            response = call(
                provider=provider["name"],
                model=provider["model"],
                prompt=prompt,
                timeout=10
            )
            log_success(provider["name"])
            return response
        except (Timeout, ServerError, RateLimit) as e:
            log_failure(provider["name"], str(e))
            errors.append((provider["name"], e))
            continue
        except AuthenticationError:
            # Key revoked — пропускаем без retry
            alert_engineer("API key invalid", provider["name"])
            continue

    # Все провайдеры down — крайний случай
    raise AllProvidersDown(errors)

Важные нюансы:

1. Different model capabilities — модели разных провайдеров по-разному справляются с разными задачами (текст, reasoning, multimodal). Fallback может ухудшить качество — это ok, потому что customer получает работающий продукт вместо ошибки.

2. Prompt portability — твои Claude prompts могут плохо работать на моделях другого провайдера (разный system prompt format, разная reaction на XML tags). Тестируй каждый prompt на всех providers в chain.

3. Cost variance — fallback на более дорогую модель может вызвать billing spike. Установи budget cap на каждый provider отдельно.

4. Local model как last resort — Ollama с открытой моделью (например, из семейства Qwen) на твоём Mac/VPS. Качество ниже cloud моделей, но работает когда весь интернет лежит. Подходит для critical paths где "хоть какой-то ответ" > "ошибка".

3-2-1 backup для AI данных

Классический IT принцип, адаптированный под AI стек:

• 3 копии данных: production + backup1 + backup2
• 2 разных storage types (избегает single-provider corruption)
• 1 копия off-site (другой регион или другой cloud)

Что бэкапить и как:

Vector embeddings tip: не бэкапь embeddings — они дорогие в storage и пересчитываются. Бэкапь сырые тексты + metadata, на disaster пересчитаешь embeddings за час.

API keys management

Storage rules:

• ❌ Никогда в код, даже временно
• ❌ Никогда в .env committed в Git (даже если "потом удалю")
• ✅ Cloudflare Secrets / Vercel Env / AWS Secrets Manager
• ✅ 1Password CLI для локальной разработки
• ✅ Pre-commit hook scanning (gitleaks)

Rotation schedule:

• Quarterly minimum для всех production keys
• Immediately после: leak detection, employee departure, любой security incident
• After major release (если key мог попасть в build artifact)

Emergency rotation procedure (documented, tested):

# rotate_all.sh — pseudo-code
# 1. Generate new keys в каждом provider dashboard
# 2. Update secrets в production
wrangler secret put ANTHROPIC_API_KEY  # Cloudflare Workers
wrangler secret put OPENAI_API_KEY

# 3. Verify production пользует новые
curl https://api.yoursite.com/health/llm

# 4. Revoke old keys в provider dashboards (manual click)

# 5. Audit log — что accessed между leak и rotation
# Check provider usage logs за период

Этот скрипт должен запускаться < 10 минут. Тестируется quarterly.

Multi-account strategy:

• Primary account + backup account у каждого critical provider
• Разные billing methods (если primary card суспендирован, backup работает)
• Backup keys уже сохранены в 1Password и протестированы (не "когда-нибудь сделаю")

Anomaly detection:

• Daily spend > 2× average → alert + investigation
• Spend > monthly budget cap → auto-pause API key
• Unusual geographic origin (запрос из страны где нет твоих customers) → flag

Incident Response Playbook — 4 шага

Когда что-то сломалось, у тебя адреналин, паника и куча impulses. Playbook структурирует.

STOP (1-3 минуты)

• Отключи affected feature (feature flag → off)
• Предотврати дальнейшее damage (если data corruption — пауза write operations)
• Скажи команде "incident in progress" (если ты не один)
• НЕ начинай debug сходу — сначала остановка кровотечения

TRIAGE (5-10 минут)

• Что произошло? (один specific failure mode, не "что-то сломалось")
• Когда началось? (precise timestamp из logs)
• Scope: какие customers affected? (1 customer / segment / все)
• Blast radius: какие features affected?
• Root cause hypothesis (можно ещё не знать точно, но направление)

STABILIZE (10-30 минут)

• Лучший вариант: rollback на предыдущий known-good деплой
• Второй: fallback на secondary provider/feature
• Третий: temporary fix (быстрый патч, не идеальное решение)
• Communicate с customers (status page update + email если major)
• Голос команды: "продукт работает, мы знаем что было, фиксим"

POSTMORTEM (1-3 часа, после стабилизации)

• Root cause analysis (5 whys или fishbone diagram)
• Timeline reconstruction
• What went well / What went badly / What to do differently
• Action items: monitoring добавить? Prevention? Process improvement?
• Blameless culture — focus на system fix, не на "кто виноват"

Communication templates — готовые когда падаешь

В момент incident'а у тебя нет времени писать красивый email. Шаблоны готовы заранее.

Customer email при outage:

Subject: [Service Update] Кратковременный сбой в [Feature] — Status

Привет [Customer],

Мы зафиксировали временный сбой в [feature/service] начавшийся в [time UTC].
Проблема связана с [generic cause: third-party API issue, infrastructure incident].

Что мы делаем:
- [текущий fix или workaround]
- Engineering команда работает над восстановлением

Estimated recovery: [conservative time, лучше переоценить чем не успеть]
Что вы можете делать сейчас: [workaround если есть, или "просто подождать"]

Следующий update в течение [30 минут / 1 часа].
Если нужна срочная помощь — [contact].

Извините за неудобство.
[Your name]

Status page entry:

[Investigating] LLM API Issues — 2026-02-15 14:23 UTC
Мы расследуем повышенную error rate в [feature]. Часть запросов завершается с ошибкой.
Updates следуют.

[Update 14:45] Identified — root cause связан с upstream provider outage.
Активировали fallback на secondary provider. Часть пользователей всё ещё видит errors.

[Monitoring 15:10] Fallback active. Error rate вернулась к baseline.
Мониторим situation, postmortem будет опубликован в течение 24 часов.

[Resolved 16:00] Issue resolved. Postmortem: [link]

Internal Slack/Telegram alert:

INCIDENT: [Feature] degraded
Severity: [P1 / P2 / P3]
Started: [timestamp]
Owner: [your name]
Status page: [link]
Customers affected: ~[number] или [segment]
Current action: [stabilizing / investigating / monitoring]

Drill schema — тестировать quarterly

План это не план если он никогда не выполнялся. Quarterly drill.

Q1: Simulate Anthropic API down

• Block egress traffic to api.anthropic.com в staging environment
• Verify OpenAI fallback автоматически активируется
• Measure: время до switch, customer impact, success rate fallback
• Document gaps → fix → re-test

Q2: Simulate database corruption

• Take staging database snapshot
• Intentionally corrupt one table
• Practice restore from backup
• Verify data integrity после restore
• Measure: RTO, RPO, data loss если любой

Q3: Simulate key leak

• Pretend ANTHROPIC_API_KEY leaked в Slack
• Execute emergency rotation procedure
• Verify все production systems updated на новый key
• Verify old key revoked в provider dashboard
• Measure: total rotation time (target <10 min)

Q4: Full disaster simulation

• Production down + LLM provider down + backup account недоступен
• Восстановить service на новой infrastructure (new Cloudflare account, новые keys)
• Measure: time-to-restore, data preserved %, customer communication delivered

Drill стоит 4 часа quarterly. Сэкономит дни когда реальный incident случится.

Tools для disaster recovery

Не реклама — практичные опции. Цены и условия меняются, поэтому смотри их на сайтах (на октябрь 2026 они могут отличаться от того, что ты увидишь позже).

Минимальный стек для SMB: хранилище для backup + UptimeRobot + Langfuse + Sentry + страница статуса. Часть из них бесплатна, итог зависит от выбранных тарифов.

Cost of disaster vs cost of preparedness

Условный расчёт для SaaS с $10K MRR. Цифры иллюстративные: это не статистика и не прогноз, подставь свои.

Disaster cost (без preparedness):

Preparedness cost (annual):

Bottom line: в этом условном примере $130-280/мес страховка для $10K MRR business = 1.3-2.8% revenue, а один реальный disaster без plan стоит как несколько месяцев такой страховки.

Не "если выгодно". Скорее "почему до сих пор не сделал".

Audience рейтинг — что нужно тебе

Новичок (personal use, hobby projects):

• ✅ Git backup для prompts и configs
• ✅ Pre-commit hook для секретов
• ❌ Multi-provider не нужен
• ❌ Status page избыточен
• Cost: $0/мес

Средний (SMB, $1-10K MRR):

• ✅ Multi-provider fallback (минимум 2)
• ✅ Nightly backup customer data
• ✅ Basic monitoring (uptime + LLM errors)
• ✅ Communication templates готовы
• ✅ 1 простой drill в год
• Cost: $30-50/мес

Профессионал (paying customers, $10-50K MRR):

• ✅ Full 3-2-1 backup
• ✅ Multi-provider chain 3-4 providers
• ✅ Automated key rotation
• ✅ Drill quarterly
• ✅ Public status page
• ✅ Postmortem culture
• Cost: $100-200/мес

Enterprise ($50K+ MRR, SLA contracts):

• ✅ Multi-region deployment
• ✅ Automated failover
• ✅ 24/7 on-call rotation
• ✅ SOC 2 compliance backups
• ✅ Dedicated incident response training
• Cost: $500+/мес

Anti-patterns

❌ Один LLM provider в production — Anthropic-only или OpenAI-only. Когда падает, ты падаешь. 2026 год — multi-provider это hygiene, не nice-to-have.

❌ Backups но никогда не тестируешь restore — классика. Backup есть, но никто не пробовал восстановить. День X — выясняется что backup corrupt или процедура сломана.

❌ Не communication с customers во время outage — silence хуже чем bad news. Customer пишет support → получает auto-reply → видит что product лежит → не знает что происходит → теряет trust.

❌ API keys в .env committed в Git history — даже если потом удалил commit, в Git history навсегда. Если когда-либо был committed — считай leaked, rotate immediately.

❌ Manual rollback без documented procedure — "я помню как делать" работает в спокойном уме. В incident'е с адреналином в 2 ночи ты забудешь шаг. Документация = checklist.

❌ "Это редко случается" — until случается один раз и теряешь enterprise deal. Probability × impact, не probability × wishful thinking.

❌ Backup на тот же provider что production — Cloudflare KV primary + Cloudflare R2 backup. Cloudflare лежит → оба недоступны. Backup должен быть на independent provider.

❌ Прятать incident от customers ("сейчас починим, никто не заметит") — заметят. И когда узнают что ты скрыл, trust damage в 10× больше чем от honest disclosure.

❌ Полагаться на provider SLA как на гарантию — SLA даёт refund (часто пропорционально downtime), не предотвращает downtime. 99.9% SLA = около 8.8 часа разрешённого downtime в год (0.1% × 8760 часов).

Чеклист готовности

✅ Multi-provider fallback работает (tested last quarter) ✅ Backups автоматически каждую ночь ✅ Last restore test пройден < 90 дней назад ✅ Communication templates написаны для top-3 incident types ✅ Status page настроена и протестирована ✅ Emergency rotation procedure документирован ✅ Все API keys в secrets manager, ноль в коде ✅ Pre-commit hook сканирует secrets ✅ Monitoring алертит на LLM error rate spike ✅ Spending anomaly detection активен ✅ Drill scheduled на следующий quarter ✅ Postmortem template готов

Если ≤ 6 ✅ — ты в зоне риска. ≤ 9 ✅ — стандартная SMB готовность. 12/12 — professional уровень.

Практика

Шаг 1: Multi-provider fallback Python implementation

# llm_router.py — простой fallback router
import os
import time
from typing import Optional
import anthropic
import openai
from google import genai

class LLMRouter:
    def __init__(self):
        self.anthropic_client = anthropic.Anthropic(
            api_key=os.getenv("ANTHROPIC_API_KEY")
        )
        self.openai_client = openai.OpenAI(
            api_key=os.getenv("OPENAI_API_KEY")
        )
        self.gemini_client = genai.Client(
            api_key=os.getenv("GOOGLE_API_KEY")
        )

        self.providers = [
            # имена моделей — пример, актуальные смотри на странице «Актуальное сейчас»
            ("anthropic", "claude-sonnet-5-5"),
            ("openai", "gpt-6.1-sol"),
            ("gemini", "gemini-3.8-flash"),
        ]

    def call(self, prompt: str, max_tokens: int = 1000) -> dict:
        errors = []

        for provider_name, model in self.providers:
            try:
                start = time.time()
                response = self._call_provider(
                    provider_name, model, prompt, max_tokens
                )
                latency = time.time() - start

                return {
                    "provider": provider_name,
                    "model": model,
                    "text": response,
                    "latency_ms": int(latency * 1000),
                    "fallback_used": provider_name != "anthropic"
                }
            except Exception as e:
                errors.append({
                    "provider": provider_name,
                    "error": str(e),
                    "type": type(e).__name__
                })
                # Log failure для monitoring
                print(f"[FAIL] {provider_name}: {e}")
                continue

        raise Exception(f"All providers failed: {errors}")

    def _call_provider(self, name, model, prompt, max_tokens):
        if name == "anthropic":
            r = self.anthropic_client.messages.create(
                model=model,
                max_tokens=max_tokens,
                messages=[{"role": "user", "content": prompt}],
                timeout=10
            )
            return "".join(b.text for b in r.content if b.type == "text")

        elif name == "openai":
            r = self.openai_client.chat.completions.create(
                model=model,
                max_completion_tokens=max_tokens,  # у моделей GPT-5 и новее вместо max_tokens
                messages=[{"role": "user", "content": prompt}],
                timeout=10
            )
            return r.choices[0].message.content

        elif name == "gemini":
            r = self.gemini_client.models.generate_content(
                model=model,
                contents=prompt
            )
            return r.text

# Использование
router = LLMRouter()
result = router.call("Объясни что такое disaster recovery в 3 предложениях")
print(f"Provider used: {result['provider']}")
print(f"Fallback used: {result['fallback_used']}")
print(result['text'])

Шаг 2: Backup script для prompts и configs

#!/bin/bash
# backup_ai_stack.sh — nightly backup AI infrastructure

set -e

BACKUP_DIR="/backups/$(date +%Y-%m-%d)"
B2_BUCKET="my-ai-backup"

mkdir -p "$BACKUP_DIR"

# 1. Backup prompts/configs (Git already covers, но extra copy)
tar czf "$BACKUP_DIR/prompts.tar.gz" ./prompts ./.claude

# 2. Backup customer data из Cloudflare D1
wrangler d1 export my-database --remote --output="$BACKUP_DIR/db.sql"

# 3. Backup KV storage: сначала список ключей, затем значения
# (формат файла для kv bulk get смотри в документации Wrangler)
wrangler kv key list --namespace-id=$KV_ID --remote > "$BACKUP_DIR/kv-keys.json"
wrangler kv bulk get "$BACKUP_DIR/kv-keys.json" --namespace-id=$KV_ID --remote > "$BACKUP_DIR/kv.json"

# 4. Upload в Backblaze B2 (off-site)
rclone copy "$BACKUP_DIR" "b2:$B2_BUCKET/$(date +%Y-%m-%d)"

# 5. Retention: удалить backups старше 30 дней локально
find /backups -type d -mtime +30 -exec rm -rf {} +

# 6. Verify backup integrity
SIZE=$(du -sh "$BACKUP_DIR" | cut -f1)
echo "Backup completed: $BACKUP_DIR ($SIZE)"

# 7. Notification on success/failure
if [ $? -eq 0 ]; then
    echo "Backup OK $(date)" >> /var/log/ai-backup.log
else
    echo "Backup FAILED $(date)" | mail -s "ALERT: Backup failed" admin-notifications
fi

Запускается через cron: 0 3 * * * /scripts/backup_ai_stack.sh

Шаг 3: Quick incident response checklist (печатать и держать рядом)

# INCIDENT RESPONSE — 10 минут до восстановления

## STOP (минута 0-3)
[ ] Feature flag → off для affected feature
[ ] Notify team в Slack: "INCIDENT in progress, owner: [me]"
[ ] Open status page draft

## TRIAGE (минута 3-10)
[ ] Что сломалось? (specific failure mode)
[ ] Когда началось? (timestamp из logs)
[ ] Кто affected? (segment / count)
[ ] Severity: P1 / P2 / P3
[ ] Root cause hypothesis (можно ещё не знать точно)

## STABILIZE (минута 10-30)
[ ] Опция A: Rollback на previous good deploy
[ ] Опция B: Activate fallback (provider, region)
[ ] Опция C: Temporary fix (быстрый patch)
[ ] Update status page: "Investigating" → "Identified" → "Monitoring"
[ ] Send customer email если P1

## POSTMORTEM (после стабилизации, в течение 48h)
[ ] Timeline restoration
[ ] 5 whys analysis
[ ] What went well / badly / change
[ ] Action items с owner и deadline
[ ] Update playbook если нашли gap

Шаг 4: Test твоего fallback (drill)

# Симуляция Anthropic API down — block egress
# На локальной разработке через /etc/hosts:
echo "127.0.0.1 api.anthropic.com" | sudo tee -a /etc/hosts

# Запусти твою app
python app.py

# Сделай запрос — должен fallback на OpenAI/Gemini
curl -X POST http://localhost:8000/api/generate \
  -H "Content-Type: application/json" \
  -d '{"prompt": "Test fallback"}'

# Проверь:
# - Response получен? (success criteria)
# - Какой provider использовался? (должен быть не anthropic)
# - Latency приемлемый? (target < 30 sec total)
# - Log записал failure + fallback? (audit trail)

# Откатить /etc/hosts:
sudo sed -i '' '/api.anthropic.com/d' /etc/hosts

Если этот тест не работает в твоей dev среде — он точно не сработает в production incident.

Инструменты и ресурсы

• Claude Status — официальная страница состояния Claude и Anthropic API
• OpenAI Status — состояние OpenAI services
• Cloudflare Status — Cloudflare global status
• AWS Well-Architected — DR Objectives — RTO/RPO framework от AWS
• 3-2-1 Backup Strategy — Backblaze объяснение принципа
• Backblaze B2 — S3-совместимое cloud storage
• Statuspage.io — hosted status pages
• Gitleaks — open source secret scanning
• Langfuse — LLM observability, open source, есть бесплатный облачный план
• UptimeRobot — uptime monitoring, free tier

Ключевые выводы

Не "если" падёт твой LLM provider, а "когда". У крупных провайдеров (Anthropic, OpenAI и других) бывают серьёзные outage: смотри историю на их страницах статуса. Single-provider стек = вопрос времени до твоего первого downtime.

3-2-1 backup это не paranoia, это hygiene. 3 копии, 2 типа storage, 1 off-site. В условном примере выше это порядка десятков долларов в месяц для SMB, а один реальный disaster без backup стоит тысячи в lost revenue, churn и repair work.

Playbook + drill quarterly > impromptu heroics. План написанный заранее и протестированный 4 раза в год превращает 4-часовой incident в 10-минутный switch. Пилоты тренируют отказ двигателя не потому что часто, а чтобы handle when it happens.

Следующий урок

→ Telegram-боты с Claude API. Про оптимизацию расходов на AI-стек: Cost Engineering