Vendor Reliability

«Cloudflare лежит — мы тоже лежим, ничего не поделаешь» — позиция, приемлемая для разговора с CEO раз в год, но не каждый месяц. Vendor Reliability — это инженерная практика, а не «купить контракт через закупки»: понять зависимости, измерить, как каждый поставщик влияет на SLO, держать запасной путь для критичных и регулярно пересматривать весь список. SRE — естественная точка ответственности, потому что отказ поставщика это инцидент, а сами зависимости видны из топологии. По моим наблюдениям, чаще всего работа с поставщиками в SRE-команде разложена по кусочкам: «счёт от AWS курирует FinOps, страницу статуса Cloudflare смотрит DevOps, Stripe за биллинговой командой», — и в день отказа Cloudflare никто не знает, какие наши сервисы от него критически зависят и какой playbook открывать.

Граница: Service Ownership — каталог наших сервисов; этот лист — каталог их сервисов, от которых зависим мы. Supply Chain Security смотрит на зависимости со стороны безопасности (CVE, SBOM, подписанные артефакты), этот лист — со стороны надёжности (SLA, история отказов, запасной путь). Cloud Cost Control — финансовая сторона тех же отношений.

Что должен уметь

Главный навык на уровне L5 — считать вклад поставщика в собственный SLO через арифметику составного SLO: если у поставщика SLA 99,9% и он стоит в критическом пути запроса, наш SLO для пользователя выше 99,9% быть не может — пока нет резервирования, запасного пути или режима деградации. Я регулярно вижу команды, которые объявляют SLO 99,95%, а зависят от трёх поставщиков с 99,9%: арифметика не сходится с самого начала. Пользоваться поставщиками это не запрещает. Но составную природу своего SLO приходится признать и записать формулу явно.

Знает критичных поставщиков своего сервиса (облако, DNS, CDN, аутентификация, платежи, мониторинг, очереди); читает их публичные страницы статуса и историю инцидентов.
Подписан на их обновления; когда у поставщика инцидент, смотрит на это через пять минут, а не через час.

Ведёт playbook на отказ поставщика для критичных: что делать, когда лёг Cloudflare, регион AWS, Stripe или Auth0. Конкретные шаги, а не «свяжемся с поддержкой».
Регулярно сверяет обещанный SLA с фактическим аптаймом. Расхождение — повод для пересмотра.

Считает составной SLO: какая часть бюджета ошибок остаётся нам после вычета доли поставщиков. Без явной арифметики SLO превращается в театр.
Оценивает риск: граф зависимостей, концентрация (один поставщик держит сразу несколько критичных путей), цена переезда, глубина привязки.

L6+

Строит портфель поставщиков: компромисс multi-cloud и multi-CDN между ценой, доступностью и нагрузкой на эксплуатацию, политика диверсификации, продуманный аварийный выход.
Планирует выход: что делать, когда поставщика купили, он закрылся или радикально поменял цены. Путь отхода для критичных описан и хотя бы раз пройден на практике.

Материалы

Книги

Betsy Beyer et al. (eds) — Site Reliability Engineering (O’Reilly, 2016), глава 22 «Addressing Cascading Failures». Отдельной главы про вендоров в книге нет, но механика каскада и приёмы вроде graceful degradation и уровней критичности переносятся на отказ внешнего поставщика один в один.
Mike Loukides, J. R. Storment, Mike Fuller — Cloud FinOps (O’Reilly, 2nd ed., 2023). Книга не про надёжность, но даёт основу работы с поставщиками с финансово-операционной стороны. Полезна, чтобы провести границу ответственности между SRE и закупками.
Will Larson — Staff Engineer (2021). Раздел про стратегические решения: выбор поставщика и риск концентрации разбираются как типичная развилка для инженера уровня staff.

Статьи и доклады

Cloudflare — Cloudflare outage on June 21, 2022 и July 2 2019 outage post-mortem. Главный публичный кейс — см. ниже.
Отказ Fastly 8 июня 2021 года. Изменение конфигурации одного клиента разбудило спавший в коде дефект и на час положило заметную часть интернета — NYT, Reddit, Twitch, сайт британского правительства. Разбор Fastly публиковала у себя в блоге; по старым адресам он больше не открывается, ищите по дате. Хороший повод обсудить, что было бы в вашем playbook.
AWS — Summary of the AWS Service Event in the US-EAST-1 Region, December 7 2021. Смежный случай: AWS как поставщик, на котором сходится всё сразу, и что вообще значит «AWS лежит».
CrowdStrike outage of July 19, 2024. Поставщик софта, а не инфраструктуры, но случай показательный: одно его обновление положило IT по всему миру.
Status Page Aggregators и Atlassian Statuspage. Не статья, а указатель на инфраструктуру для наблюдения за поставщиками.

Инструменты

Vendor inventory in repo / Notion — самый базовый и самый часто пропускаемый инструмент. Таблица в markdown: поставщик, SLA, критичность, влияние на SLO, запасной путь, ссылка на playbook, дата продления контракта. По моим наблюдениям, разница между командами, у которых поставщики под контролем, и всеми остальными — в наличии этой таблицы.
StatusGator / IsDown — агрегаторы чужих страниц статуса, шлют алерт, когда у поставщика инцидент. Полезны там, где поставщиков SaaS набираются десятки.
Synthetic monitoring (Datadog Synthetics / Checkly) — своя проверка живости поставщика; ловит частичную деградацию раньше, чем он обновит публичный статус.
Cloudflare Workers / multi-CDN configuration — рабочий способ зарезервировать слой CDN. Один из немногих классов поставщиков, где схема с двумя реально работает.
Анти-инструмент: «vendor SLA в PDF контракта, который никто не читал». Если SLA нельзя отследить, измерить и как-то на неё отреагировать, её попросту нет.

Best practices

Главный публичный кейс — Cloudflare outage, July 2, 2019. Регулярное выражение в правиле WAF съело процессор на пограничных серверах; по дороге в production ошибку никто не поймал. Двадцать семь минут глобальный трафик самого Cloudflare был ниже нормы примерно на 82 процента — и вместе с ним лежали сайты, которые никакого отношения к деплою этого правила не имели. Что показал инцидент: даже Reddit, Twitch и Discord оказались недоступны, потому что все они прятались за одним и тем же провайдером. Оговорюсь про масштаб, потому что его любят преувеличивать: речь не про половину интернета, а про одного провайдера, через которого проходит порядка десятой части веб-трафика. Этого хватило, чтобы день выдался запоминающимся. Я регулярно вижу команды, у которых «у нас Cloudflare» как полный ответ на вопрос «что у вас по DDoS / DNS / CDN», без понимания, что концентрация на одном поставщике — это риск для надёжности, и в день его отказа любое резервирование внутри собственной инфраструктуры уже бесполезно. Cloudflare тут ни при чём. Вопрос в том, есть ли у вас playbook на отказ поставщика: что мы делаем — уходим в деградацию, в режим только чтения, в обход CDN, — когда поднять его мы не можем в принципе.

Всё остальное вырастает из трёх артефактов, и первый из них — инвентаризация. Пока нет явного списка критичных vendors с SLA, уровнем критичности и влиянием на SLO, обсуждение держится в голове у пары человек, а в день отказа выясняется, что головы эти в отпуске. Список живёт в репозитории и меняется через PR — при добавлении и при выпиливании поставщика.

Второй артефакт — явная арифметика composite SLO. «Наш SLO 99.95%» при зависимости от поставщика с 99.9% и без redundancy — это не цель, а математическая невозможность. Выход один из трёх: делать redundancy, честно писать 99.9% или ниже, либо явно признать, что часть бюджета мы отдаём на сторону поставщика.

Третий — playbook на отказ каждого критичного поставщика. Что конкретно мы делаем, когда лёг Cloudflare, регион AWS или Stripe: переходим в degraded mode, в read-only, обходим CDN. «Свяжемся с support» — не шаг. И этот playbook хотя бы раз в год прокатывается на game day, иначе он художественная литература.

Риск концентрации против простоты эксплуатации — главный компромисс. Один поставщик на всё — только AWS, только Cloudflare, только Stripe — это простая эксплуатация и полная беззащитность перед его инцидентами. Двое и больше убирают единую точку отказа, но требуют вдвое больше сил: сложная маршрутизация, резервный платёжный путь и всё остальное. По моим наблюдениям, разумная граница проходит по слоям. В инфраструктурном — облако, DNS, CDN, платежи — второй поставщик оправдан там, где отказ дорого обходится бизнесу. В операционном — мониторинг, сбор ошибок, средства связи — обычно хватает одного с явным запасным вариантом. Где именно провести черту, зависит от критичности бизнеса и от SLO, который вы пообещали клиенту.

SLA поставщика — нижняя граница, а не ожидание. Фактический аптайм обычно лучше контрактного: поставщик бережёт свой бюджет компенсаций. Но раз в год отказ случается. В планировании SLO закладывается именно контрактная цифра, а не наблюдаемая, иначе любой отказ, который укладывается в SLA, сжигает наш бюджет — и на собственные инциденты уже ничего не остаётся. Дисциплина базовая, а откладывают её постоянно.

Выход от поставщика — не мысленное упражнение. Я регулярно вижу команды, где привязку к вендору обсуждают в ADR, но ни разу не проверяют на практике. Проверенный путь отхода — это раз в год-полтора реально переехать хотя бы одним некритичным сервисом. Без такого опыта выход остаётся пожеланием, а не планом. Особенно это касается аутентификации (Auth0, Okta, Cognito), платежей (Stripe, Adyen, Braintree) и мониторинга (Datadog, New Relic, Grafana Cloud).

Статус поставщика проверяется автоматически, а не глазами. Я регулярно вижу команды, у которых обнаружение чужого инцидента устроено как «кто-то заметил в Slack» или «увидели в Twitter». Это поздний сигнал. Рабочий вариант — подписка на RSS, webhook или API поставщика, заведённая прямо в собственный процесс инцидентов. От его объявления до нашей реакции должны проходить минуты, а не полчаса.

Ежегодный смотр поставщиков. Раз в год стоит пройтись по списку: кем мы вообще пользуемся (про часть уже забыли), где расходы растут быстрее пользы, у кого обещанный SLA разошёлся с наблюдаемым, какие контракты скоро продлевать (это окно для переговоров), кого купили или с кем слили. Без такого ритуала список превращается в осадок из старых решений, которые никто не пересматривал.

Связанные листья

Cloud Cost Control — поставщики съедают заметную долю счёта; обязательства перед ними (зарезервированные мощности, многолетние контракты) — часть работы над стоимостью.
SLO Engineering — арифметика составного SLO: наш SLO — произведение SLA поставщиков на нашу собственную надёжность. Их цифры и есть вход для честного обещания.
Capacity Planning — квоты у поставщика, срок ожидания при расширении, концентрация в одном его регионе.
Supply Chain Security — риск поставщика со стороны безопасности (CVE, SBOM, подписанные артефакты); этот лист — со стороны надёжности. Практики соседние и опираются на общий список.
Service Ownership — каталог сервисов хранит и зависимости от поставщиков; ответственный за отношения с каждым назван явно.
Incident Response — отказ поставщика — отдельный класс инцидента; IC проверяет его статус в первые пять минут.
Resilience Patterns — плавная деградация на случай недоступности поставщика: отдача из кэша, запасной провайдер, урезанный режим.
Architecture Decision Records — выбор поставщика — типичная ADR; концентрация против диверсификации возвращается снова и снова.
Composite SLO Methodology — SLA поставщиков идут в составную арифметику; этот лист ведёт список, соседний считает по нему.

Открытые вопросы

Multi-Cloud Strategy (TBD) — когда multi-cloud оправдан, а когда антипаттерн; пересечение с capacity planning и управлением стоимостью облака.
Vendor Concentration Metrics (TBD) — как количественно мерить концентрацию: доля выручки, доля критичных путей, blast radius.

Отдельная незакрытая тема — open source как «поставщик». Дистрибутив Linux, Kubernetes, PostgreSQL: вопросы governance те же самые, а контекст совсем другой, потому что предъявить SLA некому. Туда же переговорная часть: инженерная сторона переговоров, где технические аргументы конвертируются в условия контракта, живёт на стыке с закупками, и я не видел устоявшейся практики, как это делить.

Не уверен и в правильной степени детализации инвентаризации: вести её на уровне поставщика, отдельных ручек или фич. Если у вас есть рабочая модель — расскажите через PR.