Аппендикс

Аппендикс C

Шпаргалки и чек-листы

Назначение

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

Как использовать: Не пытайтесь пройти всё за один подход. Каждый чек-лист рассчитан на отдельную сессию. Берите тот, который релевантен текущей фазе проекта.

#C.1 Production Readiness Checklist

Готов ли сервис к тому, чтобы его увидели реальные пользователи? Этот чек-лист — минимум, ниже которого опускаться нельзя.

#Конфигурация и окружение

#	Пункт	Критерий	Severity
1	Все секреты — в secrets manager	Ни одного пароля, токена или ключа в коде, env-файлах или переменных окружения, которые не защищены	Critical
2	Конфигурация внешняя	Все настройки окружения (staging/production) вынесены из кода, приложение не требует пересборки для смены конфига	Critical
3	Логирование настроено	Есть структурированные логи (JSON), уровень логирования управляется через конфиг, sensitive-поля маскируются	Critical
4	Health checks реализованы	Liveness (`/healthz`) и readiness (`/ready`) эндпоинты отвечают корректно, проверяют зависимые сервисы (БД, кэш, очередь)	Critical
5	Graceful shutdown	При SIGTERM сервис: перестаёт принимать новые запросы, завершает текущие (с таймаутом), закрывает соединения с БД/очередью	Critical
6	Метрики и мониторинг	Метрики (Р50/Р90/Р99 latency, error rate, request rate, CPU, memory) отправляются в систему мониторинга, настроены алерты на SLO breach	High
7	Rate limiting включён	Входящие запросы ограничены (per-IP, per-user), конфигурация соответствует ожидаемым нагрузкам	High

#База данных и хранение

#	Пункт	Критерий	Severity
8	Миграции — отдельный шаг	Схема БД меняется через миграции, которые запускаются до старта приложения, откат миграций реализован	Critical
9	Connection pool настроен	Размер пула подобран под нагрузку, есть таймауты на получение соединения, pool не течёт (closed connections)	Critical
10	Индексы покрывают запросы	Все `EXPLAIN`-проверенные запросы, нет sequential scan на таблицах > 10k строк, нет дублирующихся индексов	High
11	Резервное копирование настроено	Бэкапы БД автоматические, проверено восстановление из бэкапа, retention policy определён	Critical

#Деплой и CI/CD

#	Пункт	Критерий	Severity
12	Pipeline проходит полностью	CI/CD билдит, тестирует (unit + integration), сканирует зависимости, деплоит — и всё это без ручных действий	Critical
13	Zero-downtime deploy	Rolling update или blue-green: старые инстансы не убиваются, пока новые не прошли health check	Critical
14	Feature flags для risky-фич	Любая новая функциональность, которая может сломаться, выключена за флагом — включение не требует деплоя	High
15	Откат протестирован	Скрипт отката существует и был выполнен хотя бы раз в staging, время отката известно	High

#Надёжность

#	Пункт	Критерий	Severity
16	Error tracking настроен	Все необработанные исключения (unhandled exceptions) попадают в Sentry / аналог, есть алерты на новые ошибки	Critical
17	Timeouts везде	HTTP-клиенты, БД, кэш, очереди — у каждого вызова есть timeout и circuit breaker (или retry с backoff)	Critical
18	Ретри с идемпотентностью	Все внешние вызовы, которые могут быть повторены, идемпотентны. Retry — с exponential backoff + jitter	High
19	Dependency map составлена	Документ со всеми зависимостями сервиса (что от чего зависит, что произойдёт при падении каждой зависимости)	Medium

#Безопасность (минимум)

#	Пункт	Критерий	Severity
20	HTTPS-only	HSTS включён, HTTP редиректится на HTTPS, нет смешанного контента (mixed content)	Critical
21	Dependency scan	Зависимости проверены на известные уязвимости, нет CVE с Critical/High без фикса	Critical
22	Заголовки безопасности	`Content-Security-Policy`, `X-Content-Type-Options`, `X-Frame-Options`, `Strict-Transport-Security` настроены	High

Когда проходить

Когда проходить: За 2-4 недели до планируемого запуска. Каждый пункт — либо pass, либо fail. Fail блокирует релиз до исправления для Critical, желательно для High.

#C.2 Performance Review Checklist

Оценка производительности: от быстрых проверок до глубокого профилирования.

#Быстрые проверки (можно автоматизировать)

#	Проверка	Инструмент	Ожидаемый результат
1	Response time P99	APM (Datadog, New Relic, opentelemetry)	< 500ms для API, < 2s для page load
2	CPU usage под нагрузкой	`top`, `htop`, container metrics	< 70% в пике (не упираемся в CPU)
3	Memory usage	metrics / `top`	Нет утечек, стабильный plateau после прогрева
4	Open file descriptors	`lsof`, container metrics	Не приближаются к лимиту системы
5	Connection pool utilization	metrics БД / пула	< 80% занятых соединений в пике
6	Database query time P99	slow query log, pg_stat_statements	< 200ms для OLTP, < 1s для отчётов
7	Cache hit ratio	Redis / memcached metrics	> 85% для read-heavy, > 95% для session cache
8	TLS handshake time	`curl -w`, tcpdump	< 100ms (с OCSP staple, session resumption)
9	Garbage collection (если JVM/Go/JS)	GC logs	< 5% времени CPU на GC, нет full GC циклов

#Нагрузочное тестирование

#	Проверка	Метод	Цель
10	Baseline performance	Одиночный запрос без нагрузки	Понять «потолок» — минимальную задержку системы
11	Load test (ожидаемая нагрузка)	2x ожидаемого RPS в течение 30 мин	Подтвердить latency SLO под типовой нагрузкой
12	Stress test (пиковая нагрузка)	5-10x ожидаемого RPS до отказа	Найти точку breakdown — где система ломается
13	Soak test (длительная нагрузка)	Ожидаемая нагрузка в течение 4-8 часов	Выявить утечки памяти, деградацию, GC thrashing
14	Spike test (резкий скачок)	Нагрузка с 0 до 10x за 10 секунд	Проверить авто-скалинг, rate limiting, queue growth

#Базы данных

#	Проверка	Детали
15	Slow queries	Все запросы > 100ms собраны, проанализированы, оптимизированы (индексы, N+1, кэширование)
16	Connection churn	Не создаются соединения на каждый запрос — pool работает, количество idle соединений стабильно
17	Lock contention	Нет блокировок на уровне строк/таблиц (pg_locks, innodb status); длинные транзакции (< 1s)
18	Sequential scans	`pg_stat_user_tables` / аналоги — sequential scan на таблицах > 10k строк = повод для индекса

#Фронтенд / API

#	Проверка	Детали
19	Bundle size	JS бандл < 200KB (gzip), CSS < 50KB
20	First Contentful Paint	< 1.5s (Lighthouse), < 2.5s на 3G
21	API payload size	JSON ответы < 100KB, если больше — пагинация, projection, или compression
22	Compression	gzip / brotli включены для всех текстовых ресурсов
23	CDN caching	Статика (JS, CSS, images, fonts) — на CDN с длительным cache-control, инвалидация по content hash

Когда проходить

Когда проходить: Регулярно — после каждого крупного релиза с изменением критического пути (новый эндпоинт, изменение схемы БД, новый внешний вызов). Полный прогон — раз в квартал.

#C.3 Security Review Checklist

Безопасность — это процесс, а не одноразовое действие. Этот чек-лист покрывает OWASP Top 10 и типовые проблемы веб-систем.

#Аутентификация и авторизация

#	Проверка	Что смотреть	Severity
1	Пароли не хранятся в plaintext	bcrypt / argon2 / scrypt (не md5, не sha1, не sha256)	Critical
2	JWT подписан и проверяется	RS256 / ES256 (не HS256 на микросервисах), срок жизни < 15 мин для access token	Critical
3	Refresh token rotation	Refresh-токен одноразовый, старый инвалидируется при использовании нового	High
4	Rate limiting на логин	Не более 5-10 попыток в минуту на аккаунт + CAPTCHA после превышения	Critical
5	Доступ проверяется на каждом эндпоинте	RBAC / ABAC, а не только на фронтенде. Каждый API-вызов проверяет права	Critical
6	IDOR невозможен	`GET /api/users/123` не отдаёт данные, если `123` — не текущий пользователь или нет прав admin	Critical
7	Session management	Session ID — случайный, длинный, не в URL, secure + httpOnly + SameSite cookie	Critical

#Input validation и injection

#	Проверка	Что смотреть	Severity
8	SQL injection невозможен	Используются parameterized queries / ORM, никакой конкатенации в SQL	Critical
9	NoSQL injection	MongoDB / Couchbase — экранирование, валидация типов, недопущение `$where`	Critical
10	Command injection	`exec()`, `system()`, `subprocess` — юзерский ввод не попадает в командную строку	Critical
11	SSRF защита	Внешние URL из запроса проходят валидацию (allowlist доменов, запрет internal IP)	High
12	XSS защита	Все юзерские выводы экранированы (context-aware), CSP настроен	High
13	File upload validation	Тип файла проверяется по content/magic bytes (не по расширению), размер ограничен, файлы — вне document root	High

#Транспорт и сеть

#	Проверка	Что смотреть	Severity
14	TLS 1.2+	TLS 1.0/1.1 отключены, нет устаревших cipher suites	Critical
15	mTLS между сервисами	В production — взаимная TLS-аутентификация сервисов (service mesh / cert-manager)	High
16	CORS настроен минимально	`Access-Control-Allow-Origin` — не `*`, только нужные origin'ы, не доверяем `Origin` заголовку слепо	High
17	Network segmentation	Сервисы в разных сетях/VPC, БД не доступна из интернета, только из app-слоя	Critical

#Зависимости и инфраструктура

#	Проверка	Что смотреть	Severity
18	Dependencies без CVE	SCA (Dependabot, Snyk, Trivy) — нет Critical/High уязвимостей без фикса	Critical
19	Container image scan	Docker image не содержит shell, утилит, лишних слоёв (distroless / scratch по возможности)	High
20	SAST проведён	Статический анализ (SonarQube, Semgrep, CodeQL) — найденные issue классифицированы и назначены	High
21	DAST проведён	Динамический анализ — хотя бы базовое сканирование (OWASP ZAP / Burp) перед релизом	Medium
22	Audit logging	Все подозрительные действия (неудачные логины, change of privileges, delete) логируются с контекстом	High

#Анти-паттерны безопасности

#	Пункт	Почему плохо
23	Секреты в env-файлах в репозитории	Попадут в git history → утечка, даже если удалить файл
24	«Security through obscurity»	Спрятанный эндпоинт не равно защищённый эндпоинт
25	Слишком доверчивый CORS	Origin `null` разрешён → атаки с `data:` URI / iframe sandbox
26	Отсутствие rate limiting на auth	Перебор паролей (brute force) завалит сервис

Когда проходить

Когда проходить: SAST/SCA — каждый PR. Полный security review — перед каждым major-релизом и не реже раза в полгода.

#C.4 Resilience Checklist

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

#Circuit Breaker и Bulkhead

#	Проверка	Критерий
1	Все внешние вызовы обёрнуты в circuit breaker	При timeout или 5xx — breaker размыкается (open), запросы не летят к павшему сервису
2	Конфигурация breaker'а адекватна	`failureThreshold` — не 1 (слишком чувствительно) и не 1000 (слишком терпимо). Обычно 5-10. `halfOpenMaxRequests` — 3-5
3	Bulkhead для критических ресурсов	Connection pool на БД не общий для всех клиентов — тяжелые запросы не блокируют лёгкие
4	Timeouts на каждый внешний вызов	Connect timeout + read timeout. Нет «вечных» запросов. Значения — 2x от P99 latency в норме
5	Fallback реализован (или graceful degradation)	При падении рекомендательного сервиса — показать топ-10 популярного (не ошибку)

#Graceful Degradation

#	Проверка	Критерий
6	Функциональность не падает каскадом	Падение сервиса A не валит сервис B (из-за таймаутов, занятых потоков, съеденной памяти)
7	Кэш работает без бэкенда	Redis упал — сервис всё ещё отвечает (с нагрузкой на БД, но отвечает)
8	Статика доступна при падении API	SPA-фронтенд загружается с CDN, даже если API не отвечает. Пользователь видит UI с индикацией проблем
9	Read-only mode реализован	При проблемах с БД — отключить write-операции, но читать можно (из кэша)
10	Feature-флаги позволяют отключить фичу	Обнаружили проблему в поиске — выключили фичу флагом, без деплоя

#Chaos Engineering (продвинутый уровень)

#	Эксперимент	Что проверяем
11	Убить один инстанс	Autoscaler / orchestrator поднял новый? Трафик перераспределился?
12	Отключить одну зависимость (БД, кэш, очередь)	Сервис отвечает с degraded-функциональностью или падает целиком?
13	Внести задержку (latency injection) +100ms	Timeouts не массовые? Queues не растут бесконечно?
14	CPU pressure (загрузка одного ядра на 100%)	Request latency не превышает SLO? Другие запросы не блокируются?
15	Network partition (изолировать сервис)	Retry/jitter не перегружают соседние сервисы? Circuit breaker сработал?

#Disaster Recovery

#	Проверка	Критерий
16	RTO (Recovery Time Objective) известен	Сколько времени нужно, чтобы поднять сервис с нуля? Документировано.
17	RPO (Recovery Point Objective) известен	Сколько данных мы готовы потерять? Измерено в минутах/часах.
18	Disaster recovery plan протестирован	Хотя бы раз в год — полный DR: переключение на резервный регион, проверка данных
19	Multi-region deployment настроен (если применимо)	Трафик переключается между регионами, данные реплицируются
20	Runbook для типовых инцидентов существует	«Что делать, если упала БД» — пошаговая инструкция, доступная всем дежурным

#Анти-паттерны resilience

#	Пункт	Почему плохо
21	Retry без backoff	При падении БД — 1000 запросов в секунду на ретрай добьют её окончательно
22	Весь кластер — один инстанс	Нет распределения — падение инстанса = падение сервиса
23	Бесконечные таймауты	Один медленный запрос зависает и съедает весь connection pool
24	Игнорирование thundering herd	После восстановления БД — все запросы, накопленные за время падения, бьют одновременно

Когда проходить

Когда проходить: Базовые проверки (1-10) — при каждом релизе. Chaos Engineering (11-15) — раз в квартал. DR (16-20) — раз в полгода.

#C.5 Scalability Assessment Matrix

Матрица для оценки текущего уровня масштабируемости компонента или системы в целом. Каждый параметр оценивается от 1 (не масштабируется) до 5 (горизонтально масштабируется без ограничений).

#Архитектура

Параметр	Оценка 1	Оценка 3	Оценка 5
Statelessness	Состояние хранится в памяти инстанса	Сессия — external store, но локальный кэш привязан к ноде	Полностью stateless: любой запрос — любому инстансу
Coupling	Сервисы вызывают друг друга синхронно, циклические зависимости	Основные коммуникации — sync, но критические — через очереди	Осознанный баланс sync/async, bounded contexts чётко разделены
Database coupling	Единая БД на все сервисы, schema sharing	Раздельные схемы, но общая БД	Database per service, никакой shared schema
Caching	Нет кэша	Только application cache in-memory	Многоуровневый кэш: L1 (in-memory) + L2 (Redis) + CDN

#Данные

Параметр	Оценка 1	Оценка 3	Оценка 5
Read scalability	Один мастер, чтение с него же	Read replicas есть, но приложение не различает read/write	Read replicas + CQRS: reads и writes на разные модели
Write scalability	Один мастер, все writes — на него	Sharding на уровне приложения (не прозрачно)	Автоматический sharding (Citus, Vitess) или NewSQL (Spanner, CockroachDB)
Query complexity	JOIN на 5+ таблиц, full table scans	Индексы покрывают 90% запросов, есть materialized views	Denormalized read models, no JOIN на горячем пути
Data growth	Нет плана по архивации	Старые данные периодически архивируются	TTL, auto-scaling storage, partitioning по времени

#Инфраструктура

Параметр	Оценка 1	Оценка 3	Оценка 5
Horizontal scaling	Вертикальное масштабирование — единственный путь	Автоскалинг по CPU, но разогрев контейнера — 5 мин	Автоскалинг по custom metric (queue depth, latency), разогрев < 30 сек
Deployment model	Один экземпляр, deploy с простоем	Rolling update с health check	Blue-green или canary deploy, авто-откат по метрикам
Service mesh	Нет, все коммуникации point-to-point	Частичный mesh для observability	Полный mesh: mTLS, traffic shifting, circuit breaking на уровне mesh
Multi-region	Один регион	Пассивный DR (standby в другом регионе)	Активный multi-region: трафик распределяется, conflict resolution

#Процессы

Параметр	Оценка 1	Оценка 3	Оценка 5
Capacity planning	Нет, «докинем ресурсов когда упадёт»	Мониторинг трендов, планирование на квартал	Автоматический capacity management, прогнозирование нагрузки на основе исторических данных
Load testing	Не проводится	Разовый тест перед релизом	Continuous load testing в CI/CD, регрессия производительности отслеживается
Team scalability	Bus factor = 1 человека	Документация есть, но никто не читает	Чёткие ownership-границы, API-first дизайн, team работает независимо

#Итоговая оценка

Уровень	Сумма баллов (все параметры)	Рекомендация
Startup	16-30	Масштабирование — ещё не проблема. Сфокусируйтесь на product-market fit
Growth	31-50	Начинайте думать о scaling bottlenecks. Приоритет — statelessness и caching
Scale	51-70	Система масштабируется, но есть узкие места. Работайте над weakest links
Enterprise	71-85	Хорошая база. Инвестиции в automation, multi-region, chaos engineering
Planet-scale	86-100	Ваша система готова к глобальной нагрузке. Поддерживайте и улучшайте

Как использовать

Как использовать: Выберите компонент (сервис, БД, инфраструктура). Пройдите по каждому параметру — поставьте оценку от 1 до 5. Сложите баллы. Сравните с таблицей уровней. Определите топ-3 параметра с наименьшими оценками — это ваши ближайшие точки роста.

#C.6 Как комбинировать чек-листы: roadmap

Реальный мир не проходится по одному чек-листу за раз. Вот типовые сценарии:

У вас	Возьмите	На что обратить внимание
Запуск нового сервиса	Production Readiness (C.1) + Security (C.3)	Critical-пункты блокируют запуск
Ревью перед major-релизом	Performance (C.2) + Resilience (C.4)	SLO не должны деградировать
Архитектурное ревью квартала	Scalability Matrix (C.5) + Security (C.3)	Оценка всех компонентов, план на следующий квартал
Инцидент: падение production	Resilience (C.4) — секция DR	Проверить runbook'и, дополнить новым сценарием
Плановая оптимизация	Performance (C.2) + Scalability (C.5)	Найти узкие места, приоритизировать

#C.7 Чек-лист самих чек-листов (meta)

Последний — и самый важный. Чек-листы живут, только когда их используют.

#	Пункт	Критерий готовности
1	Чек-листы доступны команде	Лежат в репозитории, в docs/ или wiki, каждый знает где искать
2	Чек-листы встроены в процесс	Production readiness — обязательный шаг перед релизом, а не «по желанию»
3	Чек-листы обновляются	После каждого инцидента — новый пункт. Раз в квартал — ревью актуальности
4	Результаты сохраняются	История прохождений чек-листов хранится: кто, когда, какие пункты не прошли, что сделали
5	Автоматизация там, где можно	80% пунктов можно проверить скриптом. Чем меньше ручного — тем чаще проходят

И помните: чек-лист не заменяет инженерное мышление. Он — страховочная сетка, чтобы в суматохе перед релизом не забыть очевидное. Хороший чек-лист экономит часы отладки в 3 часа ночи.