Ваш продукт могут убить не конкуренты, регулятор или хреновая юнит-экономика. Убить его может маленькая, тихая, никому не интересная интеграция. Та самая «мелочь», которую команда обычно добавляет вообще без обсуждений.
Я часто говорю о рисках интеграций, настало время привести несколько примеров.
Google Fonts в Китае, 2014–2015.
Когда в Китае начали активно блокировать Google CDN, сайты, построенные на красивых веб-шрифтах, превратились в визуальную катастрофу. Текст обрушивался в дефолтные fallback-шрифты, где ломалась иерархия, исчезали акценты, рушился tone of voice бренда. Продукт формально работал, но доверие и «фейс» компании сыпались прямо на глазах.
Падение Stripe, сентябрь 2022.
Сбой в инфраструктуре платежного гиганта парализовал обработку транзакций по всему миру. Тысячи стартапов и e-commerce-площадок лишились выручки в течение нескольких часов. Для конечных пользователей звучало просто: «карта не проходит». Для бизнеса это означало потерянный оборот, сбитые метрики и лавина тикетов в поддержку.
GitHub Actions, ноябрь 2020.
Инфраструктура автоматизации упала почти на сутки. Команды, полностью завязанные на CI/CD через GitHub, встали: код не собирался, тесты не прогонялись, релизы зависали. Многие команды в спешке начали подключать Jenkins или GitLab CI, теряя дни и недели на переключение. Кто-то сорвал контракты, потому что «не смог выкатиться в срок».
Amazon S3 outage, февраль 2017.
Один из крупнейших кейсов в истории облаков. Из-за ошибки при отладке команда AWS положила S3 в регионе US-East-1. На несколько часов часть интернета превратилась в неоткрываемое говно: Slack, Quora, Trello, Guardian, Imgur и сотни других сервисов. Самое смешное, что даже статус-дашборд AWS перестал работать, потому что его изображения хранились в том же S3.
Все эти истории объединяет одно: маленькая внешняя зависимость может обрушить огромный бизнес.
Что делать, чтобы этого не допустить?
1. Фиксируйте карту зависимостей. Это должен быть прям отдельный сквозной артефакт.
2. Имейте альтернативы. Если один смс-шлюз сдох, вы должны мгновенно перейти на другой.
3. Проверяйте продукт на «обрыв проводов». В E2E-тестировании проходитесь не только по базовым сценариям.
4. Планируйте так, будто чужой сервис точно однажды упадёт.
Потому что упадёт.