Инфраструктурный комитет - зачем бизнесу нужен "совет взрослых" в IT

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

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

Когда в компании впервые звучит фраза: «Нам нужно определить класс защищённости», в переговорной обычно разворачивается небольшой спектакль в трёх действиях. Специалист по информационной безопасности открывает несколько десятков вкладок с приказами, методиками и разъяснениями регуляторов. DevOps-инженер незаметно пытается вспомнить, сколько серверов работают на версиях операционных систем, которые давно сняты с поддержки, и какие именно сервисы никто не обновлял последние три года, потому что "трогать страшно - вдруг перестанет работать". Бизнес, как правило, задаёт самый прагматичный вопрос:

А можно всё это сделать подешевле? И желательно без остановки сервисов?!

Есть две стадии взросления инфраструктурного инженера. И если вы достаточно долго работаете в эксплуатации, разработке платформ или DevOps, велика вероятность, что через обе вы уже проходили. Первая стадия выглядит удивительно безобидно. Человек получает доступ к серверу, открывает терминал и думает: "Сейчас я быстро всё настрою через SSH и пару shell-скриптов. Тут работы минут на двадцать". В этот момент он искренне верит, что инфраструктура - это набор машин, несколько конфигурационных файлов и немного Bash-магии. Скрипты складываются в папку scripts, пароли временно живут в заметках, а документация существует преимущественно в голове человека, который всё это написал.

Когда приложение состоит из одного app.py, жизнь кажется удивительно простой. Открываешь терминал, запускаешь tail -f, смотришь несколько строк логов и довольно быстро понимаешь, что происходит. Ошибка подключения к базе данных выглядит как ошибка подключения к базе данных. Исключение в коде находится ровно в том месте, где его выбросили. Если что-то сломалось, виновник обычно обнаруживается быстрее, чем успевает остыть кофе. Именно поэтому многие инженеры годами живут с ощущением, что логов достаточно для любых задач наблюдаемости.

А потом приложение начинает расти.

Интернет задумывался как глобальная сеть, в которой любой компьютер может связаться с любым другим компьютером. На практике всё давно работает немного иначе. Где-то провайдер режет определённые сервисы, где-то появляются ограничения на отдельные протоколы, где-то плохо работает международная маршрутизация, а иногда нужный ресурс оказывается недоступен просто потому, что находится за пределами привычного маршрута вашего трафика. В результате даже опытный инженер периодически сталкивается с ситуацией, когда нужная документация не открывается, очередной релиз на GitHub скачивается со скоростью почтового голубя, пакеты PyPi становятся недоступными, Telemost начинает заикаться в голосовых каналах, а какой-нибудь зарубежный сервис внезапно оказывается недоступен из-за особенностей маршрутизации или региональной политики доступа.