В любой достаточно крупной компании существует старый как мир треугольник: инфраструктура, разработка и информационная безопасность. Формально все три направления работают на одну цель - создание надежных и безопасных сервисов для бизнеса. На практике же иногда кажется, что они участвуют в разных проектах, работают на разных заказчиков и говорят на разных языках. Разработчики хотят быстрее выкатывать новые функции. Инженеры инфраструктуры хотят, чтобы система не развалилась под нагрузкой и чтобы ночью никто не звонил с аварией. Специалисты по информационной безопасности хотят, чтобы все происходило безопасно и соответствовало требованиям регуляторов и внутренним политикам компании.
И вот здесь начинается самое интересное. Разработка приходит с просьбой открыть доступы, инфраструктура отвечает, что сначала нужно понять последствия, а безопасность приносит документ на двадцать страниц с замечаниями и словами "не рекомендуется". Через пару часов переговоров все участники процесса искренне уверены, что именно они спасают компанию, а остальные только мешают работать.
Самое забавное заключается в том, что обычно все стороны одновременно правы и одновременно ошибаются.
За последние годы мне довелось работать в командах, где эти подразделения буквально воевали друг с другом. Иногда конфликты были открытыми, иногда скрытыми, но итог всегда оказывался одинаковым. Релизы задерживались, сотрудники выгорали, бизнес терял деньги, а технический долг рос быстрее, чем количество микросервисов в очередном модном проекте.
Парадокс состоит в том, что современные технологии настолько сложны, что ни одна из сторон уже не может существовать изолированно. Времена, когда разработчик писал код и забывал о нем после передачи в эксплуатацию, давно закончились. Точно так же закончились времена, когда инфраструктурная команда могла просто выдавать виртуальные машины и считать свою работу завершенной. А безопасность давно перестала быть подразделением, которое появляется за неделю до запуска проекта и начинает запрещать всё подряд.
Хотя, будем честны, иногда они все еще пытаются.
Самый дорогой конфликт в IT - это конфликт между людьми, которые на самом деле работают над одной задачей.
Почему начинаются войны между подразделениями
Проблема редко связана с людьми. Обычно она связана с различием целей и метрик.
Разработчика оценивают по скорости поставки функциональности. Бизнесу важно, чтобы новая возможность появилась как можно быстрее. Инженера инфраструктуры оценивают по стабильности систем, доступности сервисов и отсутствию аварий. Специалиста по безопасности оценивают по количеству предотвращенных рисков и соответствию требованиям.
Если посмотреть на ситуацию поверхностно, становится понятно, почему возникают конфликты. Разработчик хочет выкатить новую функцию сегодня вечером. Инфраструктура говорит, что сначала нужно протестировать нагрузку, проверить резервирование и подготовить мониторинг. Безопасность напоминает про аудит, сканирование уязвимостей и необходимость изменить схему авторизации.
Каждый выполняет свою работу правильно. Но каждый видит только собственную часть картины.
В результате появляется классическая ситуация. Разработка считает инфраструктуру тормозом прогресса. Инфраструктура считает разработку источником бесконечных проблем. Безопасность воспринимается как отдел, который приходит на совещание исключительно для того, чтобы сказать слово "нельзя".
На одном из проектов я наблюдал почти комичную картину. Разработчики несколько месяцев создавали новый сервис. Инфраструктуру подключили за неделю до запуска. Безопасников пригласили за три дня до релиза. Через сутки стало понятно, что сервис не соответствует требованиям по аутентификации, журналированию действий пользователей и хранению данных. Релиз перенесли почти на месяц.
После этого все подразделения долго обвиняли друг друга.
Самое смешное, что виноватых не было вообще. Была лишь плохая организация взаимодействия.
Инфраструктура как переводчик между мирами
Многие считают, что инфраструктурная команда отвечает исключительно за серверы, контейнеры, базы данных и сети. В современных компаниях это давно не так.
На практике инфраструктура часто становится своеобразным переводчиком между разработкой и безопасностью. Именно инфраструктурные инженеры обычно понимают ограничения обеих сторон. Они знают, как устроены приложения, как работает сеть, как функционируют средства защиты и что произойдет после очередного изменения.
Хороший инфраструктурный инженер способен объяснить разработчику, почему нельзя запускать сервис с правами администратора. При этом он способен объяснить безопаснику, почему его предложение сломает половину производственных процессов.
Если такой роли в компании нет, каждая сторона начинает разговаривать на собственном профессиональном диалекте.
Разработчик говорит про бизнес-логику, фреймворки и сроки.
Инфраструктурщик говорит про отказоустойчивость, балансировку и резервное копирование.
Безопасник говорит про угрозы, риски, соответствие требованиям и последствия компрометации.
В итоге получается классическая история про Вавилонскую башню, только вместо древних строителей спорят люди с ноутбуками стоимостью как подержанный автомобиль.
Именно поэтому инфраструктура часто становится центром координации технических решений. Не потому что она главнее остальных, а потому что находится на пересечении всех процессов.
Почему дружба дешевле войны
Есть одна крайне непопулярная мысль, которую многие инженеры не любят слышать.
Большинство проблем в IT являются организационными, а не техническими.
Технические вопросы обычно решаются быстро. Можно заменить балансировщик, перестроить кластер, изменить архитектуру приложения или внедрить новую систему мониторинга. Гораздо сложнее решить проблему недоверия между подразделениями.
Когда команды не общаются, появляется огромное количество скрытых потерь. Разработчики принимают архитектурные решения без учета особенностей инфраструктуры. Инфраструктура строит платформу без понимания потребностей разработки. Безопасность формирует требования без знания внутренних процессов продукта.
Результат всегда одинаковый - бесконечные переделки.
Каждая переделка означает потерянное время, дополнительные деньги и новые риски.
В одной компании разработчики решили использовать собственную систему хранения файлов. Решение выглядело красиво на презентациях и отлично работало на тестовом стенде. Инфраструктуру о проекте никто не спросил. Через несколько месяцев объем данных вырос настолько, что система начала регулярно падать. После этого пришлось мигрировать всё на централизованное объектное хранилище.
На миграцию ушло несколько месяцев.
На консультацию с инфраструктурой в начале проекта потребовался бы один час.
Разница в стоимости решения оказалась колоссальной.
Час совместного обсуждения обычно дешевле месяца героического исправления последствий.
Почему безопасники раздражают и почему это нормально
Наверное, не существует ни одной инфраструктурной команды, которая хотя бы раз не жаловалась на безопасность.
Иногда кажется, что специалисты по ИБ обладают особым талантом находить проблемы именно в тот момент, когда проект уже почти готов к запуску. Более того, они часто обнаруживают проблемы, о которых никто даже не задумывался.
Поэтому у инженеров возникает естественное желание воспринимать безопасность как источник препятствий.
Но здесь важно понимать одну простую вещь.
Безопасность видит риски, которые остальные команды обычно не замечают.
Когда инфраструктурщик смотрит на сервис, он думает об отказоустойчивости. Когда разработчик смотрит на сервис, он думает о функциональности. Когда безопасник смотрит на сервис, он представляет себе человека, который пытается этот сервис взломать.
Разница в подходе огромная.
Да, иногда требования безопасности бывают чрезмерными. Иногда встречаются формальные проверки ради самих проверок. Иногда можно встретить специалистов, которые искренне считают слово "запретить" универсальным инструментом управления рисками.
Но в большинстве случаев безопасность выполняет крайне важную функцию.
Проблема возникает тогда, когда безопасники подключаются слишком поздно. Если команда ИБ появляется в проекте за неделю до запуска, конфликт практически гарантирован. Если же специалисты участвуют в обсуждении архитектуры с самого начала, большая часть противоречий исчезает еще на этапе проектирования.
Именно поэтому хорошие отношения между инфраструктурой и безопасностью становятся стратегическим преимуществом компании.
Даже если иногда хочется немного пошутить над очередным согласованием на тридцать страниц.
Как разделить ответственность правильно
Одна из главных причин конфликтов заключается в размытых границах ответственности. Когда никто точно не понимает, кто отвечает за конкретную часть системы, начинается знаменитая игра под названием "это не наша зона ответственности".
Удивительно, насколько быстро она появляется даже в очень сильных командах.
На практике хорошо работает достаточно простая модель:
- Разработка отвечает за приложение, бизнес-логику, качество кода, тестирование и устранение дефектов внутри продукта.
- Инфраструктура отвечает за платформу, вычислительные ресурсы, сети, контейнерную среду, мониторинг, резервное копирование и эксплуатационную надежность.
- Безопасность отвечает за требования безопасности, анализ рисков, аудит, контроль соответствия и рекомендации по защите данных и сервисов.
Важно понимать, что это не стены между подразделениями. Это зоны основной ответственности.
Например, безопасность не должна самостоятельно внедрять изменения в производственную инфраструктуру. Но она должна участвовать в согласовании решений. А разработка не должна самостоятельно менять сетевую архитектуру. Но она обязана понимать последствия своих требований. Ну и инфраструктура не должна принимать решения о бизнес-логике приложения. Но обязана участвовать в обсуждении технических ограничений.
Когда эти границы прозрачны, количество конфликтов снижается в разы.
Практические способы построить нормальные отношения
Самый эффективный инструмент взаимодействия удивительно прост.
Нужно начать разговаривать друг с другом до возникновения проблем.
Регулярные архитектурные комитеты, совместные технические обсуждения, внутренние митапы и разборы инцидентов дают гораздо больше пользы, чем кажется на первый взгляд. Люди начинают понимать мотивацию коллег и видеть общую картину.
Очень полезной практикой являются совместные разборы аварий без поиска виноватых. Если после каждого инцидента начинается охота на ведьм, сотрудники быстро учатся скрывать проблемы. Если же цель заключается в улучшении процессов, команды начинают обмениваться знаниями и работать значительно эффективнее.
Еще одна полезная практика - раннее вовлечение всех сторон в проект. Чем раньше инфраструктура и безопасность узнают о новой системе, тем дешевле обходятся изменения.
Особенно хорошо работает принцип общей ответственности за результат. Пользователю совершенно безразлично, кто именно допустил ошибку - разработчик, инфраструктурщик или безопасник. Для него существует одна компания и один сервис.
Поэтому успешные команды перестают мыслить категориями подразделений и начинают мыслить категориями продукта.
Вместо заключения
Современная инфраструктура, разработка и информационная безопасность больше не могут существовать как независимые королевства со своими границами и дипломатическими конфликтами. Сложность технологий выросла настолько, что успех любого проекта определяется не только качеством технических решений, но и качеством взаимодействия между людьми.
Да, разработчики будут продолжать просить доступы "прямо сейчас". Да, инфраструктурщики будут требовать мониторинг и резервирование. Да, безопасники будут находить очередную потенциальную угрозу в самый неожиданный момент. Это нормально. Так устроена работа.
Ненормально, когда подразделения начинают воспринимать друг друга как противников.
Потому что в реальности они находятся по одну сторону баррикад.
И если инфраструктура, разработка и безопасность научатся работать как единая команда, выигрывают все: инженеры получают меньше бессонных ночей, бизнес получает более надежные сервисы, а пользователи даже не замечают, сколько сложных процессов происходит за кулисами.
А это, пожалуй, и есть лучший показатель хорошо построенной инженерной культуры.
Хорошая инфраструктура, хорошая разработка и хорошая безопасность редко спорят о том, кто важнее. Они слишком заняты тем, чтобы вместе делать систему лучше.