Диаграмму, которую рисуют все, можно назвать "счастливым путём": пользователь обращается к приложению, приложение к базе данных, готово. Для доски сойдёт, для эксплуатации системы бесполезно. У продакшена другая форма, потому что ему приходится переживать всплески трафика, отказы узлов, деплои и иногда неудачный день. Схема продакшен-архитектуры, которая отражает эту реальность, а не аккуратный набросок, превращает диаграмму в операционный инструмент.
Хитрость в том, чтобы перестать рисовать "что с чем говорит" и начать рисовать три пересекающихся представления: путь трафика, домены отказа и границы масштабирования. Большинство продакшен-диаграмм запутаны, потому что пытаются показать все три сразу и без цели. Рисуйте их осознанно, и картинка станет тем, с чем действительно можно рассуждать в три часа ночи.
Представление первое: путь трафика
Проследите один запрос от внешнего мира до данных и обратно и нарисуйте каждый шаг, который он реально проходит. В продакшене этот путь длиннее, чем признаёт набросок:
- CDN или edge впереди, отдающий попадания в кэш ещё до того, как запрос увидит ваш origin.
- Балансировщик нагрузки, распределяющий трафик по инстансам.
- Слой stateless-серверов приложений, а не один блок.
- Кэш, в который попадает большинство чтений до базы данных.
- Основная база данных для записи и реплики для чтения для остального.
- Асинхронный путь: очередь и воркеры для работы, которая не должна выполняться в самом запросе.
Представление второе: диаграмма доменов отказа
Теперь нарисуйте линии, группирующие всё по принципу "что отказывает вместе". Зоны доступности самый очевидный пример: две или три колонки, по которым распределены слой приложений и слой данных, чтобы отказ зоны вас не положил. Но домены отказа шире зон. Общий кэш это домен. Единственная основная база данных это домен. Очередь это домен. Если нарисовать эти границы, единые точки отказа невозможно пропустить: они выглядят как блок, от которого всё зависит и рядом с которым нет пары.
Продакшен-диаграмма окупается в тот момент, когда показывает вам блок, который вы не можете себе позволить потерять.
Представление третье: границы масштабирования
Отметьте, что масштабируется и как. Слой приложений масштабируется горизонтально, поэтому рисуйте его как растущую группу, а не фиксированную пару. База данных масштабируется иначе: вверх для записи, вширь репликами для чтения, и эту асимметрию стоит показать, потому что именно в неё продакшен-системы упираются. Группы автомасштабирования, пулы воркеров, растущие с глубиной очереди, и любой компонент с фиксированной ёмкостью заслуживают видимой пометки. История масштабирования это половина планирования мощностей, и она живёт в этом представлении.
Не забудьте компоненты, которые существуют только в проде
Дизайн-документ их опускает; продакшен не может. Наблюдаемость (метрики, логи, трейсы) подключена почти к каждому компоненту. Секреты и конфигурация откуда-то берутся. Есть bastion или приватный путь доступа для людей. Бэкапы работают со слоем данных. Не нужно рисовать всё это на одной диаграмме, и не стоит, но продакшен-картина, где нет ни одного из этих элементов, это вымысел. Дайте важным из них свой блок.
Поддерживайте актуальность, иначе она врёт
Продакшен-диаграмма полезна, только если совпадает с продакшеном, а продакшен постоянно меняется. Это аргумент в пользу того, чтобы выводить её из Terraform или манифестов и перегенерировать с определённой периодичностью, а не с любовью поддерживать вручную рисунок, который расходится с реальностью. Объедините сгенерированный скелет со своими пометками, встройте в runbook и обновляйте, когда меняется инфраструктура. Актуальная схема продакшена один из самых ценных документов, которыми может владеть команда.
Нарисуйте путь трафика, отметьте домены отказа, покажите границы масштабирования и генерируйте основу из реальной инфраструктуры, чтобы она оставалась честной. Именно эту диаграмму вы захотите держать открытой во время инцидента.