12.2 Контрольные списки

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

Указания, как пользоваться ими хорошо:

• Держите контрольные списки достаточно короткими, чтобы люди действительно их выполняли. Если контрольный список рутинно пропускают, он слишком длинный или слишком общий.
• Автоматизируйте любой пункт, который может проверить машина (форматирование, тесты, сканирования), чтобы люди тратили внимание на пункты суждения.
• Версионируйте ваши контрольные списки и периодически рецензируйте их. Контрольный список, который никогда не меняется, вероятно, не используется.
• Различайте блокирующие и совещательные пункты, когда это различие важно для вашего процесса.

Контрольный список рецензии кода

Для рецензента, рассматривающего чужое изменение.

• Изменение делает то, что говорят его описание и связанная заявка.
• Объём сфокусирован на одной логической заботе; несвязанные изменения вынесены отдельно.
• Проект вписывается в существующую архитектуру и не вводит зацепление, которого легко избежать.
• Крайние случаи, пути ошибок и режимы отказа обработаны, а не только благополучный путь.
• Тесты существуют, осмысленны и упали бы, если бы поведение регрессировало.
• Имена, структура и комментарии делают код понятным будущему читателю.
• Никакие секреты, учётные данные, токены или персональные данные не закоммичены.
• Чувствительный к безопасности ввод валидируется, кодируется или параметризуется надлежащим образом.
• Публичные интерфейсы, контракты и обратная совместимость сохранены или намеренно версионированы.
• Журналирования, метрик и отчётов об ошибках достаточно, чтобы эксплуатировать изменение в производстве.
• Документация, руководства по эксплуатации и конфигурация обновлены в соответствии с изменением.
• Обратная связь разделена на блокирующие проблемы и предложения и сформулирована о коде.

Контрольный список автора запроса на слияние

Для автора перед запросом рецензии.

• Запрос на слияние достаточно мал и сфокусирован, чтобы тщательно рассмотреть его за один присест.
• Описание сообщает, что изменилось, почему и как это проверено.
• Связанная заявка, задача или проектный документ даёт рецензентам необходимый контекст.
• Все автоматизированные проверки проходят локально или в CI (сборка, линтер, формат, тесты, сканирования).
• Новое и изменённое поведение покрыто тестами.
• Механические рефакторинги отделены от изменений поведения.
• Саморецензия завершена: вы прочли свой diff построчно.
• Не осталось отладочного кода, закомментированных блоков, секретов или случайных файлов.
• Миграции базы данных, флаги функций и изменения конфигурации документированы и обратимы.
• Ломающие изменения явно выделены с путём миграции.
• Снимки экрана, записи или образцы вывода включены там, где помогают рецензии.
• Запрошены нужные рецензенты и любые требуемые ролевые утверждающие.

Определение готовности

Общий стандарт, которому рабочий элемент должен соответствовать, прежде чем считаться завершённым.

• Все критерии приёмки в заявке выполнены и демонстрируемы.
• Код рецензирован коллегами и одобрен требуемыми рецензентами.
• Автоматизированные тесты написаны, проходят и слиты вместе с изменением.
• Код слит в основную линию и чисто разворачивается через конвейер.
• Не остаётся открытых известных дефектов согласованного порога серьёзности.
• Документация, справочные тексты и руководства по эксплуатации обновлены.
• Наблюдаемость на месте: существуют релевантные журналы, метрики и оповещения.
• Последствия для безопасности и приватности рассмотрены и учтены.
• Требования доступности для изменения выполнены там, где оно обращено к пользователю.
• Флаги функций настроены, а план выкатки согласован.
• Владелец продукта или заинтересованная сторона приняли результат.
• Любая последующая работа зафиксирована как отслеживаемые заявки, а не оставлена неявной.

Готовность к запуску в производство

Перед отгрузкой значимого изменения или нового сервиса в производство.

• План выкатки документирован, включая поэтапные или канареечные шаги и критерии успеха.
• План отката документирован, протестирован и может быть быстро исполнен.
• Тестирование мощности и нагрузки показывает, что система соответствует ожидаемому и пиковому спросу.
• Мониторинг, панели и оповещения работают и проверены до запуска.
• Дежурное покрытие запланировано, а реагирующие знают систему.
• Руководства по эксплуатации существуют для наиболее вероятных сбоев и операционных сценариев.
• Зависимости, интеграции и третьи стороны подтверждены как готовые, а ограничения частоты понятны.
• Рецензия безопасности и требуемые подписи завершены.
• Миграция данных, если есть, протестирована от начала до конца с проверенным откатом.
• Флаги функций позволяют отключить изменение без повторного развёртывания.
• Юридические одобрения, одобрения по приватности и соответствию получены там, где требуется.
• План коммуникации охватывает заинтересованные стороны, поддержку и клиентов.
• Решение «идти/не идти» принято названными владельцами по явным критериям.

Контрольный список рецензии безопасности / модели угроз

Для оценки состояния безопасности изменения или системы.

• Границы доверия и потоки данных выявлены и документированы.
• Аутентификация принуждается на каждой точке входа, которая её требует.
• Проверки авторизации принуждают наименьшие привилегии для каждого действия и ресурса.
• Весь внешний ввод валидируется, а вывод кодируется для своего приёмника.
• Секреты хранятся в управляемом хранилище, никогда в коде или конфигурации, и ротируемы.
• Данные шифруются при передаче и в покое, как требует классификация.
• Зависимости сканируются на известные уязвимости и поддерживаются актуальными.
• Риски инъекций, десериализации и SSRF смягчены для недоверенного ввода.
• События, значимые для безопасности, журналируются без записи чувствительных данных.
• Ограничение частоты, квоты и защита от злоупотреблений охраняют открытые конечные точки.
• Сообщения об ошибках не раскрывают трассы стека, внутренности или чувствительные детали.
• Угрозы, выявленные через STRIDE или подобное, записаны со смягчениями или принятым риском.
• Тестирование безопасности (SAST, DAST или тестирование на проникновение) запланировано или завершено.

Контрольный список приватности и защиты данных (в стиле DPIA)

Для обработки, включающей персональные или чувствительные данные.

• Собираемые персональные данные инвентаризированы, классифицированы и минимизированы до необходимого.
• Правовое основание или полномочие для каждой цели обработки документировано.
• Ограничение цели принуждается: данные используются только для заявленных целей.
• Сроки хранения определены, а удаление или анонимизация автоматизированы.
• Права субъектов данных (доступ, исправление, удаление, переносимость) могут быть исполнены.
• Согласие, где на него полагаются, свободно дано, конкретно и отзываемо.
• Третьи стороны и обработчики связаны надлежащими условиями защиты данных.
• Трансграничные передачи имеют надлежащий правовой механизм передачи.
• Доступ к персональным данным ограничен, журналируется и рецензируется.
• Риски приватности для физических лиц оценены и смягчены или эскалированы.
• Процессы обнаружения утечек данных и уведомления определены.
• Выбор приватности по замыслу и по умолчанию документирован для функции.
• Ответственный за защиту данных или рецензент приватности подписал там, где требуется.

Контрольный список доступности (WCAG)

Для пользовательских интерфейсов, согласованный с принципами WCAG.

• Весь контент достижим и управляем только с клавиатуры.
• Порядок фокуса логичен, а видимый индикатор фокуса присутствует.
• Контраст цвета текста соответствует целевому соотношению (обычно 4,5:1 для основного текста).
• У изображений и нетекстового содержимого есть осмысленный альтернативный текст.
• У полей форм есть связанные подписи и ясные сообщения об ошибках.
• Заголовки, ориентиры и структура размечены семантически.
• Интерактивные компоненты предоставляют вспомогательным технологиям правильные имя, роль и состояние.
• Содержимое перетекает и остаётся пригодным при увеличении 200% и на малых экранах.
• Лимиты времени настраиваемы, а движение или автоматически воспроизводимое содержимое можно приостановить.
• Цвет не единственное средство передачи информации.
• У медиа есть субтитры и, где нужно, расшифровки или аудиоописание.
• Интерфейс протестирован программой чтения с экрана и автоматизированными инструментами доступности.

Контрольный список рецензии проекта API

Перед публикацией или изменением API.

• Именование ресурсов и операций последовательно и предсказуемо.
• Контракт задан в машиночитаемой схеме (например, OpenAPI).
• Стратегия версионирования определена, а обратная совместимость сохранена или управляема.
• Постраничная выдача, фильтрация и сортировка следуют последовательным конвенциям.
• Ответы об ошибках используют последовательную структуру, коды и применимые сообщения.
• Аутентификация и авторизация заданы для каждой операции.
• Валидация ввода и ограничения размера определены и принуждаются.
• Идемпотентность определена для операций, где ожидаются повторы.
• Ограничения частоты, квоты и поведение троттлинга документированы.
• Тайм-ауты, повторы и семантика сбоев ясны клиентам.
• Раскрытие чувствительных данных в ответах минимизировано и обосновано.
• Документация включает примеры для каждой операции и случая ошибки.
• Политика устаревания и сроки вывода определены.

Контрольный список рецензии решения по архитектуре (ADR)

Для рецензии предлагаемой записи архитектурного решения.

• Контекст и решаемая проблема изложены ясно.
• Решение изложено недвусмысленно как единый выбор.
• Рассмотрены и сравнены как минимум две реалистичные альтернативы.
• Последствия, как положительные, так и отрицательные, документированы.
• Нефункциональные воздействия (производительность, безопасность, цена, эксплуатируемость) учтены.
• Решение согласуется с существующими принципами и предыдущими ADR или явно их заменяет.
• Затронутые команды и заинтересованные стороны были проконсультированы.
• Обратимость и цена изменения оценены.
• Допущения и ограничения сделаны явными.
• Статус (предложено, принято, заменено) задан и датирован.
• Решение обнаруживаемо и связано из релевантных систем.
• Любые последующие действия или миграции зафиксированы как отслеживаемая работа.

Контрольный список реагирования на инцидент

Во время активного производственного инцидента.

• Объявите инцидент и назначьте единого командира инцидента.
• Оцените и сообщите серьёзность, охват и воздействие на клиентов.
• Откройте выделенный канал связи и запись инцидента.
• Назначьте ясные роли: командир, ответственный за коммуникацию и ответственный за операции.
• Приоритизируйте смягчение и восстановление сервиса над анализом первопричины.
• Публикуйте регулярные обновления статуса заинтересованным сторонам с установленным ритмом.
• Фиксируйте хронологию событий, действий и решений по мере их возникновения.
• Эскалируйте к дополнительным реагирующим или поставщикам, когда нужно.
• Уведомите юристов, безопасность и соответствие, если затронуты данные или регулирование.
• Проверьте исправление и подтвердите, что система полностью восстановилась.
• Формально закройте инцидент и сообщите о разрешении.
• Назначьте безвинный разбор до того, как люди разойдутся.

Контрольный список разбора инцидента

Для ретроспективной рецензии после инцидента.

• Рецензия безвинна и сосредоточена на системах и способствующих факторах.
• Фактическая хронология инцидента с метками времени документирована.
• Воздействие на клиентов и бизнес квантифицировано (длительность, охват, цена).
• Обнаружение проанализировано: как и когда проблему заметили.
• Реагирование проанализировано: что помогло и что замедлило восстановление.
• Способствующие причины выявлены, а не только единственная первопричина.
• Записано, что прошло хорошо, а также что прошло плохо.
• Действия конкретны, назначены владельцам и имеют сроки.
• Действия касаются предотвращения, обнаружения и смягчения.
• Последующие пункты отслеживаются до завершения в обычном бэклоге.
• Разбор широко распространён, чтобы другие могли учиться на нём.
• Системные закономерности по инцидентам периодически рецензируются.

Контрольный список готовности к дежурству

Перед тем как кто-то принимает дежурную смену.

• У реагирующего есть доступ ко всем системам, панелям и инструментам, что ему нужны.
• Оповещения надёжно доходят до реагирующего и протестированы.
• Пути эскалации и контакты вторичного дежурного известны и актуальны.
• Руководства по эксплуатации существуют для наиболее частых и наиболее серьёзных оповещений.
• Реагирующий прошёл вхождение или сопровождение по этим системам.
• Недавние изменения, текущие инциденты и известные проблемы переданы.
• Пороги оповещений настроены так, чтобы минимизировать шум и ложные вызовы.
• Реагирующий знает, как объявить инцидент и связаться с командиром.
• Доступ к производству возможен из рабочего окружения реагирующего.
• Каналы связи и контакты заинтересованных сторон документированы.
• График дежурств опубликован, а покрытие не имеет пробелов.
• Компенсация, ожидания и пределы нагрузки для дежурства ясны.

Контрольный список определения SLO

При определении целевого уровня обслуживания.

• Пользовательский путь или возможность, которую защищает SLO, ясно определены.
• Индикаторы уровня обслуживания (SLI) определены как ясные измеримые величины.
• SLI измеряются с точки зрения пользователя, где возможно.
• Целевое значение цели задано на уровне, который пользователям действительно нужен, а не 100%.
• Окно измерения (например, скользящие 28 дней) задано.
• Бюджет ошибок, выведенный из цели, вычислен и понят.
• Политика определяет, что происходит при исчерпании бюджета ошибок.
• Источники данных для SLI надёжны и инструментированы.
• Оповещения привязаны к скорости сжигания, а не только к нарушениям порога.
• Владельцы и заинтересованные стороны согласны, что SLO реалистичен и осмыслен.
• SLO документирован и виден на панели.
• Существует график рецензии и пересмотра SLO по мере развития сервиса.

Контрольный список конвейера CI/CD

Для конвейера непрерывной интеграции и поставки.

• Каждый коммит запускает автоматизированную сборку и прогон тестов.
• Конвейер быстро падает и ясно сообщает результаты авторам.
• Линтинг, форматирование и статический анализ запускаются автоматически.
• Модульные, интеграционные и релевантные сквозные тесты запускаются в конвейере.
• Сканирование безопасности и зависимостей запускается при каждой сборке.
• Артефакты сборки версионированы, неизменяемы и хранятся в реестре.
• Секреты внедряются безопасно и никогда не печатаются в журналах.
• Развёртывания автоматизированы и повторяемы по окружениям.
• Стратегия развёртывания (канарейка, сине-зелёное, скользящее) определена и используется.
• Откат автоматизирован или является единственным документированным действием.
• Права конвейера следуют наименьшим привилегиям и поддаются аудиту.
• Конфигурация конвейера хранится в системе контроля версий как код.
• Происхождение сборки и перечень компонентов программного обеспечения производятся там, где требуется.

Контрольный список рецензии инфраструктуры как кода

Для рецензии инфраструктуры, определённой как код.

• Изменения выражены целиком в коде и применяются через конвейер.
• План или вывод пробного прогона рецензируется перед применением.
• Состояние хранится безопасно с блокировкой, предотвращающей одновременные изменения.
• Ресурсы следуют конвенциям именования, тегирования и владения.
• Используются роли и политики IAM с наименьшими привилегиями, без подстановочных знаков, где можно избежать.
• Сетевое раскрытие минимизировано; нет непреднамеренного публичного доступа.
• Секреты и чувствительные значения ссылаются из хранилища, а не зашиты в код.
• Шифрование включено для хранилищ, баз данных и передачи.
• Изменения идемпотентны и безопасны для повторного применения.
• Радиус поражения понят; разрушительные изменения выделены.
• Воздействие изменения на цену учтено.
• Модули повторно используемы, версионированы и протестированы.
• Обнаружение дрейфа на месте, чтобы ловить внеполосные изменения.

Контрольный список релиза модели ИИ/МО

Перед выпуском модели машинного обучения в производство.

• Предназначенное использование, объём и ограничения модели документированы.
• Происхождение, лицензирование и согласие на данные обучения и оценки проверены.
• Данные и модель версионированы и воспроизводимы.
• Производительность оценена на репрезентативных отложенных тестовых данных.
• Справедливость и смещение оценены по релевантным подгруппам.
• Модель оценена относительно действующей или базовой.
• Режимы отказа, крайние случаи и поведение вне распределения поняты.
• Риски безопасности, злоупотребления и вредного вывода оценены и смягчены.
• Мониторинг дрейфа, качества данных и деградации производительности на месте.
• Существует откат или запасной переход на предыдущую модель или путь на правилах.
• Человеческий надзор или апелляция обеспечены для значимых решений.
• Рецензия приватности охватывает данные обучения и входы и выходы вывода.
• Карточка модели или эквивалентная документация опубликована для заинтересованных сторон.

Контрольный список качества конвейера данных

Для конвейера данных, питающего аналитику или продукты.

• Схемы исходных данных валидируются, а изменения схемы обнаруживаются.
• Приём правильно обрабатывает запоздавшие, дублирующиеся и неупорядоченные записи.
• Проверки качества данных (полнота, уникальность, диапазоны) запускаются автоматически.
• Неудавшиеся записи помещаются в карантин и выводятся наружу, а не молча отбрасываются.
• Преобразования протестированы на репрезентативных и крайних входах.
• Конвейер идемпотентен и безопасен для повторного запуска после сбоя.
• Свежесть и задержка выходов мониторятся относительно ожиданий.
• Происхождение документировано, чтобы потребители знали, откуда берутся данные.
• Персональные и чувствительные данные классифицированы, маскированы или ограничены надлежащим образом.
• Дозаполнения и повторная обработка поддерживаются и документированы.
• Оповещения уведомляют владельцев о сбоях и нарушениях качества.
• Политики хранения и удаления принуждаются на сохранённых данных.
• Нижестоящие потребители и SLA документированы.

Контрольный список приёма открытого исходного кода и рецензии лицензии

Перед принятием компонента с открытым исходным кодом.

• Лицензия компонента выявлена и входит в список одобренных.
• Лицензионные обязательства (указание авторства, копилефт, уведомления) поняты и выполнены.
• Совместимость лицензии с вашей моделью распространения подтверждена.
• Проект активно сопровождается и имеет здоровое сообщество.
• Известные уязвимости проверены, а версия актуальна.
• Зависимость и её транзитивные зависимости инвентаризированы.
• Состояние безопасности и история прошлых инцидентов рассмотрены.
• Компонент закрывает реальную потребность без значительного дублирования.
• Цена выхода и заменяемость компонента учтены.
• Компонент записан в перечень компонентов программного обеспечения.
• Названный владелец отвечает за отслеживание обновлений и бюллетеней.
• Политики вклада обратно и внутренних форков соблюдаются при изменении.

Контрольный список рисков поставщика / третьей стороны

Перед подключением внешнего поставщика или сервиса.

• Бизнес-потребность и данные, к которым поставщик получит доступ, ясно определены.
• Состояние безопасности поставщика оценено (сертификации, аудиты, опросник).
• Условия обработки данных, владение и удаление при выходе контрактно ясны.
• Субобработчики и расположение данных поставщика раскрыты и приемлемы.
• Соответствие релевантному регулированию проверено.
• Время работы, поддержка и обязательства SLA документированы.
• Обязательства уведомления об утечках и сроки включены в контракт.
• Доступ ограничен наименьшими привилегиями и отзываем.
• Непрерывность бизнеса и воздействие сбоя поставщика оценены.
• План выхода и миграции данных существует, чтобы избежать привязки.
• Цены, условия продления и положения об изменении цен поняты.
• Поставщик добавлен в реестр рисков с датой рецензии.

Контрольный список готовности к государственному соответствию (в стиле ATO / FedRAMP)

Для систем, требующих формального разрешения на эксплуатацию.

• Граница системы и потоки данных определены и изображены на диаграмме.
• Данные категоризированы по уровню воздействия и чувствительности.
• Применимый базис средств контроля выбран и адаптирован.
• План безопасности системы документирует, как реализован каждый контроль.
• Контроли реализованы, подтверждены свидетельствами и сопоставлены с планом.
• Непрерывный мониторинг и сканирование уязвимостей действуют.
• План действий и этапов отслеживает открытые находки до устранения.
• Управление доступом, журналирование аудита и управление идентичностью соответствуют требованиям.
• Шифрование использует одобренные алгоритмы и проверенные модули.
• План реагирования на инциденты документирован и протестирован.
• План непрерывности и аварийного восстановления документирован и протестирован.
• Независимая оценка или аудит контролей завершены.
• У уполномочивающего должностного лица есть оценка риска, необходимая для предоставления разрешения.
• Триггеры повторного разрешения и ритм текущего разрешения определены.