Короткий ответ
#Почему именно эти двадцать восемь
Отобраны по попадаемости, а не по полноте.
Человек, читающий каждую строку системы, незаметно для себя делает огромное число мелких проверок: что будет, если тут null; этот эндпоинт вообще должен быть публичным; это повторяется при сбое; кто это вызывает. Эти проверки не часть никакого процесса — они побочный эффект чтения.
Когда бо́льшая часть системы приезжает быстрее, чем её кто-то читает, не происходит ни одна из них. Список ниже — это то, как выглядят те же попутные проверки, когда их приходится делать намеренно, по убыванию того, как часто они что-нибудь находят.
#Деньги и данные
Шесть проверок
- Что происходит с платежом или заказом, который провайдер так и не подтвердил? Самый урожайный вопрос. Классическая недостающая часть — сверка: деньги списаны, записи нет.
- Безопасно ли повторять любую операцию, которую можно повторить? Повторы без идемпотентности порождают дубли ровно при тех условиях, ради которых повторы и существуют.
- Где хранятся клиентские данные и что уходит из системы наружу?
- Пишется ли что-нибудь по адресу, настроенному вне репозитория? Путь к файлу или URL из переменной окружения, в которую никто не заглядывал.
- Обрабатываются ли суммы в форме, которая не может потерять точность?
- Есть ли путь, удаляющий данные без подтверждения и без возможности восстановления?
#Несчастливые пути
Пять проверок
Счастливый путь обычно проработан тщательно. Тонко у быстрых сборок здесь: способ отказа надо вообразить, а не описать.
- Что происходит, когда внешний вызов отваливается по таймауту?
- Что происходит, когда очередь копится или воркер умирает посреди задачи?
- Что происходит, когда два запроса по одному и тому же приходят одновременно?
- Частичный сбой оставляет систему в согласованном состоянии или применённой наполовину? Многошаговая операция без границы транзакции — самый частый источник «невозможных» данных.
- Порождает ли сбой что-то, что увидит человек, — лог, оповещение, статус? Дорого обходится именно молчаливый сбой.
#Внешние границы
Пять проверок
- Проверяет ли каждый входящий вебхук, кто его прислал? Эндпоинт вебхука без проверки подписи — это неаутентифицированная запись в вашу базу.
- Перечислены ли все внешние зависимости с указанием, на чьём они аккаунте?
- Есть ли у исходящих вызовов таймаут? Вызов без таймаута может удержать запрос, потом воркер, потом весь пул.
- Есть ли исходящее, добавление которого никто не помнит?
- Что сломается и насколько заметно, если каждый внешний сервис отвалится на час?
#Доступ и открытые поверхности
Пять проверок
- Какие эндпоинты доступны без аутентификации и для каждого ли это было задумано? Пройдите по списку явно. Именно здесь сгенерированный файл маршрутов людей и удивляет.
- Видит ли аутентифицированный пользователь только свои данные? Отсутствующая проверка владения выглядит как работающий код в любом тесте, где пользователь один.
- Нет ли доступов где-нибудь в репозитории или в его истории?
- Выключены ли в продакшене режимы отладки, подробные ошибки и инструменты разработки?
- Не выставлено ли в интернет то, что должно быть внутренним, — админка, панель очередей, порт базы?
#Эксплуатация
Четыре проверки
- Что работает по расписанию и что делает каждая задача? Проверьте кодовую базу, консоль облака и crontab. Они редко сходятся.
- Может ли выкатить это тот, кто это не строил, по одной только инструкции?
- Разворачивали ли бэкап, а не просто настраивали?
- Есть ли путь назад от плохого релиза, которым кто-то реально пользовался?
#Понимание
Три проверки
- Проверял ли кто-нибудь документацию, которую сгенерировал агент? Возьмите пять конкретных утверждений и сверьте каждое. Обширная непроверенная документация хуже, чем никакой, потому что ей верят.
- Есть ли письменное описание того, из чего состоит система, которое можно проверить?
- Есть ли список того, чего про неё сейчас никто не может подтвердить? Уверенное «мы знаем всё» про систему, которую никто не читал, — уже само по себе находка.
#Что идёт не так
Ревьюить код строка за строкой перед запуском.
Вместо этого Проработайте семь областей выше. Построчное ревью большой сгенерированной кодовой базы медленно и пропускает ровно те структурные вопросы, что в этом списке.
Считать, что тесты это покрывают.
Вместо этого Проверьте, что тесты на самом деле утверждают. Сгенерированные тесты часто проверяют реализацию, а не требование, и потому проходят при любом поведении кода.
Доверять сгенерированному README.
Вместо этого Проверьте пять утверждений из него. Если два неверны, считайте весь документ утверждением, а не источником.
Считать это разовым упражнением перед запуском.
Вместо этого Перепроверяйте после каждого значимого пуша. Система, построенная так, движется быстрее, чем проверки остаются верными.
Читать этот список как аргумент против кодовых агентов.
Вместо этого Это аргумент за проверки, которые человек-читатель раньше делал попутно. Скорость — настоящий выигрыш; проверки теперь надо делать намеренно.
#Чего это не покрывает
Чего это не делает
- Тестирование безопасности. Несколько пунктов пересекаются с гигиеной безопасности; ничто из этого не является пентестом или сканированием уязвимостей.
- Производительность и нагрузку. Ничто здесь не говорит, как система ведёт себя под трафиком.
- Юридические и регуляторные обязанности: они целиком зависят от того, чем вы занимаетесь и где.
- Качество архитектуры. Это устанавливает, что систему безопасно запускать, а не что она хорошо спроектирована.
- Достаточность тестов сверх одной проверки выше.