Карта зависимостей: за два часа выяснить, что на самом деле уронит бизнес

В большинстве компаний схема инфраструктуры существует в двух видах. Первая — красивая презентационная: кластеры, реплики, балансировщики, стрелки между ними. Вторая — настоящая, в голове одного инженера, и она заметно сложнее.

Проблема обеих в том, что они описывают технику, а не бизнес. На них видно, где стоят серверы, но не видно, что именно останавливает продажи. А отказ, который останавливает продажи, почти никогда не выглядит на схеме драматично: это не упавший кластер, а истёкший сертификат, недоступный внешний сервис или аккаунт, к которому потеряли доступ.

Карта зависимостей — способ увидеть систему глазами бизнеса. Она рисуется за один разбор на два часа и почти всегда обнаруживает две-три точки отказа, о которых в компании не думали.

Кого звать

Одних инженеров недостаточно, и это главная ошибка. Инженеры знают, как система устроена; они не всегда знают, что при её отказе происходит с деньгами.

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

Двух часов и одной доски достаточно. Инструмент вторичен: подойдёт онлайн-доска, а на первый раз — лист бумаги.

Как рисовать: по пути запроса

Не начинайте с перечисления серверов — так вы получите инвентарную ведомость, а не карту. Идите по пути клиента, сверху вниз, задавая на каждом шаге вопрос «а дальше что».

1. Точка входа. Где зарегистрирован домен и на кого? У какого провайдера обслуживаются DNS-записи? Кто физически может их изменить в три часа ночи?

2. Транспорт. Как запрос доходит до вашей инфраструктуры? Есть ли сеть доставки контента, защита от атак, кто выпускает и продлевает TLS-сертификат?

3. Точка приёма. Какой балансировщик или веб-сервер встречает запрос? Он один или их несколько?

4. Приложение. Какие сервисы обрабатывают запрос? Где лежит статика — на локальном диске сервера или в объектном хранилище?

5. Данные. Где база данных, где кэш, где очереди. Что происходит с приложением, если кэш недоступен: оно работает медленнее или не работает вовсе?

6. Внешние сервисы. Платёжный шлюз, отправка сообщений, CRM, служба доставки, картографический сервис, сервис авторизации. Каждый вызов наружу — это чужая инфраструктура, на которую вы не влияете.

7. Обеспечивающие системы. Мониторинг, резервное копирование, система выкатки, хранилище паролей. Их отказ не виден клиенту немедленно, но он лишает вас возможности реагировать.

Вторая карта: административные зависимости

Технической карты недостаточно. Параллельно нарисуйте вторую — короче и неприятнее. На ней не серверы, а права, счета и учётные записи:

• На чьё имя зарегистрирован домен и на какую почту приходят уведомления о продлении.
• Чья банковская карта привязана к аккаунту облачного провайдера и когда у неё истекает срок.
• Кто владелец организации в панели провайдера — то есть кто единственный может восстановить доступ остальным.
• Где хранятся ключи и пароли и что произойдёт, если этот сервис окажется недоступен.
• На чей телефон приходит второй фактор для критичных учётных записей.
• Кто получает уведомления об истечении TLS-сертификатов и лицензий.

Эта карта регулярно оказывается опаснее технической. Отказ сервера чинится за час, а восстановление контроля над доменом, оформленным на уволившегося сотрудника, занимает недели — и всё это время сделать нельзя ничего.

Упражнение «закрась красным»

Когда обе карты нарисованы, задайте по каждому узлу один вопрос: что произойдёт с бизнесом, если этот элемент исчезнет прямо сейчас?

Красным отмечайте то, отказ чего немедленно останавливает поступление денег. Жёлтым — то, что ухудшает работу, но позволяет продолжать. Зелёным — то, отсутствие чего сутки никто снаружи не заметит.

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

Что находится почти всегда

Домен и почта на уволившемся сотруднике. Домен зарегистрирован на личный адрес человека, ушедшего два года назад, уведомления о продлении уходят в никуда. Пока всё работает, это незаметно. В день аварии выясняется, что изменить DNS-запись некому.

Синхронный вызов внешнего сервиса без ограничения по времени. При оформлении заказа приложение обращается к внешней CRM и ждёт ответа. Обычно ответ приходит за 100 миллисекунд. В день, когда у CRM начинаются проблемы и ответ приходит за 30 секунд, все свободные обработчики вашего приложения оказываются заняты ожиданием — и сайт перестаёт отвечать целиком, хотя ваша инфраструктура полностью исправна. Лечится ограничением времени ожидания, отключением необязательных вызовов при их деградации и переводом всего, что можно отложить, в асинхронную обработку.

Кэш как незамеченная точка отказа. Сессии пользователей вынесены в Redis ради масштабирования, но сам Redis запущен в одном экземпляре. Его отказ означает, что никто не может войти, хотя база данных полностью работоспособна.

Один канал уведомлений. Мониторинг шлёт оповещения в корпоративный мессенджер, который развёрнут на той же инфраструктуре, что и продукт. При крупной аварии вы не получите сообщения о ней.

Сертификат, который никто не продлевает. Автоматическое продление настроено, но однажды сломалось, и об этом узнают в день, когда браузеры начинают показывать предупреждение о небезопасном соединении.

Что делать дальше

Карта не самоцель. Она нужна, чтобы принять три решения.

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

Второе: определить приоритеты резервирования. Не всё красное нужно резервировать одинаково — сначала считается цена отказа. Об этом отдельный разбор: критичность компонентов.

Третье: перестать считать карту разовым мероприятием. Она устаревает за квартал: появляются интеграции, меняются провайдеры, уходят люди. Разумный ритм — сверять её раз в квартал и обязательно после каждого крупного изменения архитектуры. Пятнадцати минут на сверку обычно хватает, если карта уже есть.

Начните с трёх компонентов на листе бумаги. Неполная карта, нарисованная сегодня, полезнее исчерпывающей схемы, которую собираются сделать когда-нибудь потом.

Внешний слой карты — домен, DNS, почта, сертификаты — проверяется за пару минут автоматически. Остальное разберём вместе, если нужен взгляд со стороны.