Практически каждый инженер, который хотя бы несколько лет занимается эксплуатацией инфраструктуры, может вспомнить несколько историй, начинающихся одинаково: "Да это изменение на пять минут", "Мы уже сто раз так делали", "Там вообще нечему ломаться". Удивительно, но именно такие фразы зачастую становятся прологом к очередному многочасовому созвону, десяткам сообщений в аварийном чате и вопросам руководства о том, почему пользователи снова не могут воспользоваться сервисом. В этот момент выясняется, что простое обновление Helm-чарта неожиданно затронуло сетевые политики, автомасштабирование начало создавать новые экземпляры приложения в неподходящих зонах доступности, система мониторинга не прислала критическое оповещение, а документация по откату последний раз обновлялась ещё во времена, когда Kubernetes считался экзотикой.

В мире инфраструктурной инженерии существуют вещи, неподвластные времени. Например, бесконечные YAML-манифесты, которые размножаются быстрее, чем инженеры успевают обновлять документацию. Или удивительная способность специалистов по автоматизации автоматизировать уже существующую автоматизацию, после чего написать ещё один инструмент, который будет автоматизировать предыдущие два. И если ещё несколько лет назад можно было услышать фразы вроде: «Мы создаём виртуальные машины руками через веб-интерфейс, потому что так надёжнее», то сегодня подобные признания воспринимаются примерно так же, как рассказ о том, что резервное копирование производится путём периодического копирования файлов на флешку, лежащую в ящике рабочего стола.

В два часа ночи инфраструктура выглядит совсем не так, как на архитектурных диаграммах, которые любят показывать на внутренних демо и квартальных встречах. На схемах всё красиво и упорядоченно: Kubernetes-кластеры выстроены ровными прямоугольниками, CI/CD-пайплайны текут по аккуратным стрелкам, системы наблюдаемости заботливо собирают телеметрию, а процессы реагирования на инциденты расписаны настолько подробно, что остаётся лишь следовать инструкции. Реальность, как обычно, значительно менее фотогенична. Дежурный инженер открывает ноутбук, пытается одной рукой удержать кружку с давно остывшим кофе, а другой переключается между Prometheus, Grafana, терминалом, журналами приложений, корпоративным чатом и GitLab. Вкладок открыто столько, что даже браузер начинает вести себя как пассивно-агрессивный коллега, намекающий, что человеку давно пора спать.

Есть один неловкий момент, о котором инфраструктурщики, разработчики и архитекторы обычно говорят не со сцены и не во время официальных дискуссий. Такие разговоры случаются значительно позже - когда закончились последние доклады, бейджики перекочевали в карманы рюкзаков, а люди наконец перестали играть роли представителей компаний и снова становятся просто инженерами. Обычно это происходит где-нибудь в лобби гостиницы, возле кофемашины или за столиком в баре, когда разговор неожиданно сворачивает с обсуждения "платформенного подхода" и "инженерной синергии" к чему-то значительно более честному.

Есть момент, который почти невозможно заметить изнутри компании, пока он не случился. Вчера вы были той самой дерзкой командой, которая за выходные запускала новые сервисы, выкатывала изменения без длинных согласований и искренне гордилась тем, что "у нас всё по-простому". А потом однажды выясняется, что инфраструктурный счёт за месяц сопоставим с годовой зарплатой нескольких инженеров, крупный клиент спрашивает про RTO и RPO, служба информационной безопасности интересуется журналами аудита, а генеральный директор неожиданно хочет понять, почему отказ одного сервиса остановил продажи на несколько часов. И именно в этот момент становится очевидно: компания выросла. Даже если сама она ещё не готова себе в этом признаться.

В любой достаточно крупной компании существует старый как мир треугольник: инфраструктура, разработка и информационная безопасность. Формально все три направления работают на одну цель - создание надежных и безопасных сервисов для бизнеса. На практике же иногда кажется, что они участвуют в разных проектах, работают на разных заказчиков и говорят на разных языках. Разработчики хотят быстрее выкатывать новые функции. Инженеры инфраструктуры хотят, чтобы система не развалилась под нагрузкой и чтобы ночью никто не звонил с аварией. Специалисты по информационной безопасности хотят, чтобы все происходило безопасно и соответствовало требованиям регуляторов и внутренним политикам компании.

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