11-5 · Глава 11 · 4 мин. чтения

Почему запись утверждений и доказательств важнее, чем просто получить «да»

Узнайте, почему фиксация утверждений и доказательств в CI/CD критична для аудита и расследования инцидентов. Практическое руководство для DevOps и SRE.

Почему запись утверждений и доказательств важнее, чем просто получить «да»

Вы только что получили устное одобрение от руководителя на развёртывание изменения базы данных поздно ночью. Он сказал: «давай», вы запустили деплой, и всё казалось нормальным. Через неделю что-то ломается. Во время пост-мортема вы говорите, что руководитель одобрил изменение. Руководитель говорит, что не помнит, чтобы одобрял что-то подобное. Теперь у вас две проблемы: техническая проблема, вызвавшая сбой, и спор о том, кто авторизовал изменение.

Такой сценарий разыгрывается чаще, чем большинство команд готовы признать. Утверждение состоялось, но нет никакой записи о нём. Нет доказательств того, кто сказал «да», когда он это сказал или что он видел перед согласием. Без этой записи утверждение могло бы и не существовать.

Что должна содержать настоящая запись об утверждении

Правильная запись об утверждении отвечает на три вопроса. Пропустите любой из них — и в вашем аудиторском следе появится дыра, которая может вызвать серьёзные проблемы позже.

Вот как может выглядеть полная запись об утверждении в журнале аудита пайплайна:

{
  "change_id": "DEPLOY-2024-11-05-142",
  "approver": {
    "name": "alice.chen",
    "role": "engineering_manager"
  },
  "timestamp": "2024-11-05T14:30:00Z",
  "evidence": [
    {
      "type": "test_results",
      "url": "https://ci.internal/pipeline/1234/test-report"
    },
    {
      "type": "security_scan",
      "summary": "0 critical, 2 high, 5 medium findings - all waived per policy"
    },
    {
      "type": "change_request",
      "url": "https://tickets.internal/CR-7890"
    }
  ]
}

Кто утвердил

Пайплайн должен логировать личность человека, давшего утверждение. Не просто имя, а его роль в команде. Был это tech lead, engineering manager или DBA? Роль важна, потому что она показывает, имел ли этот человек полномочия утверждать такой тип изменений.

Что ещё важнее, система должна проверять, что утверждение действительно пришло от этого человека, а не от кого-то другого, использующего его учётную запись. Именно поэтому рабочие процессы утверждения должны проходить через системы, интегрированные с аутентификацией вашей команды, а не через сообщения в чате или электронные письма, которые легко подделать или переслать. Если кто-то может скопировать и вставить сообщение «одобрено» из треда Slack, у вас нет системы утверждения. У вас есть игра в скриншоты.

Когда утверждено

Временная метка должна включать минуты и часовой пояс. Это может показаться излишним, пока вам не понадобится восстановить последовательность событий во время расследования инцидента.

Рассмотрим такой таймлайн:

Изменение отправлено в 14:00
Утверждение получено в 14:30
Развёртывание в production в 14:45
Инцидент обнаружен в 15:10

С чёткими временными метками вы можете точно увидеть, как всё развивалось. Без них вы гадаете, было ли утверждение до или после деплоя. Утверждение, которое происходит после деплоя — это не утверждение. Это уведомление, замаскированное под управление.

На основании каких доказательств

Это та часть, которую большинство команд упускает. Кто-то утвердил изменение, но что именно он видел перед тем, как нажать «утвердить»? Просмотрел ли он результаты тестов? Прочитал ли changelog? Проверил ли, влияет ли изменение на другие системы? Или просто доверился, что всё в порядке?

Пайплайн должен фиксировать доказательства, на основании которых было принято решение. Это могут быть:

Ссылка на запуск пайплайна со всеми пройденными гейтами
Скриншот результатов сканирования безопасности
Просмотренный документ с запросом на изменение
Сводка того, что было проверено и подтверждено

Когда вы фиксируете эти доказательства, утверждение перестаёт быть формальностью и становится проверяемым решением. Любой может позже оглянуться назад и увидеть, что было известно на момент утверждения, а не просто то, что кто-то сказал «да».

Построение аудиторского следа

Эти три части информации вместе формируют ваш аудиторский след. Аудиторский след — это полная запись того, что произошло с изменением от начала до конца: кто его сделал, кто проверил, какие гейты он прошёл, кто утвердил, когда был развёрнут и был ли деплой успешным или неудачным.

Полный аудиторский след служит двум целям. Во-первых, он удовлетворяет требованиям соответствия. Есть ли у вашей компании внутренние политики или внешние нормативы, наличие чёткой записи каждого изменения и того, кто его авторизовал, часто обязательно.

Во-вторых, и это более практично, он ускоряет и упрощает расследование инцидентов. Когда что-то идёт не так, вам не нужно разыскивать людей и спрашивать «кто это сделал?» или «почему это было пропущено?». Ответы уже записаны. Вы можете сосредоточиться на исправлении проблемы вместо восстановления того, что произошло.

Как это работает на практике

Большинство современных CI/CD-инструментов уже фиксируют часть этой информации. GitLab CI/CD, GitHub Actions и Jenkins с правильными плагинами могут логировать, кто утвердил изменение и когда. Но часть с доказательствами обычно требует ручных усилий от утверждающего.

Решение простое, но требует дисциплины: сделайте привычкой перед утверждением добавлять комментарий со ссылкой или сводкой того, что было проверено. Без этой привычки ваши записи об утверждении будут просто говорить «утверждено» без контекста. Это ненамного лучше, чем вообще не иметь записи.

Некоторые команды идут дальше, встраивая сбор доказательств прямо в пайплайн. Шаг утверждения может показывать сводку результатов тестов, выводы сканирования безопасности и детали изменения прямо в интерфейсе утверждения. Утверждающий видит всё необходимое, не покидая пайплайн, а система логирует то, что было показано. Это устраняет необходимость в ручных комментариях и делает сбор доказательств автоматическим.

Краткий чек-лист для ваших записей об утверждении

Если вы настраиваете или пересматриваете свой процесс утверждения, пройдитесь по этим пунктам:

Логирует ли пайплайн личность и роль утверждающего?
Достаточно ли точна временная метка для восстановления последовательности событий?
Фиксируются ли доказательства, на основании которых принято утверждение, автоматически или вручную?
Сможет ли человек, просматривающий аудиторский след через шесть месяцев, понять, почему это изменение было утверждено?
Интегрирована ли система утверждения с аутентификацией вашей команды, а не просто с сообщением в чате?

Суть

Утверждение без записи — это не утверждение. Это разговор, который может запомниться по-разному каждым участником. Когда вы фиксируете, кто утвердил, когда утвердил и какие доказательства видел, вы превращаете небрежное «окей, давай» в решение, которое можно проверить, аудировать и защитить. В этом разница между процессом, который выглядит так, будто у него есть контроль, и тем, у которого он действительно есть.