Когда политика инфраструктуры мешает: обработка исключений без нарушения безопасности
Вы потратили недели на создание политик инфраструктуры. Каждый ресурс должен следовать соглашениям об именовании, использовать одобренные типы инстансов и никогда не открывать определённые порты для публичного доступа. Пайплайн автоматически применяет эти правила. Всё чисто, контролируемо и безопасно.
Затем к вам приходит команда с запросом, который нарушает сразу три политики. Им нужен инстанс с большим объёмом памяти, обычно запрещённый из-за стоимости. Им нужно временно открыть отладочный порт, потому что проблема в продакшене воспроизводится только в реальном окружении. А унаследованная система, которую они мигрируют, вынуждает их использовать имя ресурса, нарушающее ваш стандарт именования.
Что делать?
Проблема жёстких политик
Если ваш ответ — «политика есть политика, никаких исключений», вы готовите себе провал. Команды найдут обходные пути. Они тихо изменят политики, создадут ресурсы вне пайплайна или просто проигнорируют правила. Политика станет бесполезной, потому что люди предпочтут обходить систему, а не бороться с жёсткими правилами.
Цель не в том, чтобы устранить политики. Цель — сделать их достаточно гибкими, чтобы люди не чувствовали необходимости их обходить. Вам нужен чёткий механизм для исключений, который сохраняет ответственность каждого.
Три обязательных компонента каждого исключения
Хорошо спроектированная система исключений имеет три неотъемлемых компонента: логирование, утверждение и срок действия.
Логирование
Каждое исключение должно быть записано. Кто его запросил, какая политика была нарушена, какие ресурсы затронуты, почему потребовалось исключение и кто его утвердил. Эта информация никогда не должна исчезать. Она служит нескольким целям: аудиторские следы, анализ после инцидентов и мягкое напоминание о том, что команда работает вне обычных правил.
Без логирования исключения становятся невидимым техническим долгом. Вы не будете знать, сколько исключений существует, кто их предоставил и нужны ли они ещё.
Утверждение
Человек, запрашивающий исключение, не может утвердить его сам. Кто-то другой должен дать согласие, желательно тот, кто понимает риски, которые призвана смягчить политика. Если исключение касается безопасности, утверждает команда безопасности. Если оно влияет на стоимость, утверждает финансовый отдел или инженерный менеджер.
Это утверждение можно интегрировать непосредственно в ваш пайплайн в качестве шлюза. Пайплайн приостанавливается, пока уполномоченное лицо не рассмотрит и не утвердит запрос на исключение. Нет утверждения — нет развёртывания.
Срок действия
Исключения никогда не должны быть постоянными. Каждое исключение должно иметь временной лимит, обычно от 7 до 30 дней. После этого политика применяется снова автоматически. Нарушающий ресурс должен быть исправлен или удалён. Если исключение всё ещё необходимо, команда должна отправить новый запрос с обновлённым обоснованием.
Этот механизм предотвращает превращение исключений в новую норму. Он заставляет команды либо исправить основную проблему, либо обосновать необходимость изменения политики.
Проектирование процесса обработки исключений
Процесс исключения должен быть слегка неудобным. Не для наказания людей, а чтобы убедиться, что исключение действительно необходимо. Если это слишком легко, все будут использовать исключения вместо соблюдения политик. Если слишком сложно, люди найдут лазейки. Золотая середина находится где-то посередине: достаточно раздражающе, чтобы заставить людей подумать дважды, но не настолько болезненно, чтобы блокировать легитимную работу.
На практике процесс выглядит так:
Следующая диаграмма иллюстрирует процесс запроса исключения:
- Пайплайн выполняет проверки политик во время plan или apply.
- Обнаружено нарушение. Пайплайн предлагает два варианта: отменить изменение или отправить запрос на исключение.
- Если команда отправляет исключение, пайплайн создаёт тикет или уведомление для уполномоченного утверждающего.
- После утверждения пайплайн продолжается, но помечает ресурс как находящийся в статусе исключения.
- Система отправляет напоминания до истечения срока исключения. После истечения срока она автоматически повторно запускает проверку политики.
Чего не следует делать
Никогда не создавайте исключения без даты истечения или утверждения. Это равносильно отсутствию политики вообще. Исключение, которое никогда не истекает, — это просто политика, которая была молча переписана.
Кроме того, не используйте исключения как предлог, чтобы избежать улучшения ваших политик. Если один и тот же тип исключения появляется снова и снова, ваша политика может быть слишком строгой. Возможно, вам нужна новая категория ресурсов, или первоначальное правило больше не имеет смысла. Частые исключения — это сигнал о том, что ваши политики нуждаются в пересмотре, а не просто в обходных путях.
Практический чек-лист для обработки исключений
- Каждое исключение логируется с указанием запросившего, нарушенной политики, затронутых ресурсов, причины и утверждающего
- Исключения требуют утверждения от лица, понимающего риски политики
- Все исключения имеют явные даты истечения (рекомендуется 7–30 дней)
- Пайплайн блокирует развёртывание до утверждения исключения
- Автоматические напоминания отправляются до истечения срока исключения
- Истекшие исключения запускают автоматическую повторную проверку политики
- Частота исключений пересматривается ежеквартально для выявления возможностей улучшения политик
Вывод
Политики без механизмов исключений создают теневые системы. Команды будут их обходить, и вы потеряете видимость того, что на самом деле работает в вашей инфраструктуре. Хорошо спроектированный процесс обработки исключений не ослабляет ваши политики. Он укрепляет их, делая их достаточно реалистичными, чтобы люди действительно им следовали. Ключевые элементы — логирование, утверждение и срок действия. Без всех трёх у вас нет процесса исключений. У вас есть политика, которая уже нарушена.