Сервис Моей Мечты

Требования разделены по необходимости и этапам SDLC DevOps.

Минимальные Требования

План

Есть человек, ответственный за разработку, техническое развитие и работоспособность сервиса
Сервис использует технологический стек, поддерживаемый компанией
У сервиса есть техническая документация в README.md, как минимум несколько страниц, описывающих ключевые моменты
Документация сервиса актуальна или есть задача по ее обновлению
Если у сервиса есть API, есть сохраненная спецификация в формате OpenAPI
Сервис использует одно из решений, принятых компанией для хранения данных

Код

Управление зависимостями осуществляется с помощью менеджеров, принятых для языка: composer, go module, yarn, npm и другие

Сборка

Артефакт сборки представляет собой автономный docker-образ
Сервис собирается автоматически, в рамках общего процесса CI/CD
CI/CD выполняется в системе, принятой компанией (GitHub, GitLab, Jenkins, Bitbucket Pipeline и т.д.)
Dockerfile и CI/CD создаются и поддерживаются командой сервиса

Тестирование

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

Развертывание

У сервиса есть несколько сред, в зависимости от того, что принято в компании
Сервис управляется оркестратором (nomad, kubernetes). Исключения для сервисов с высокой нагрузкой на CPU, память и I/O.
Сервис использует terraform для описания своей инфраструктуры, helm для описания ресурсов kubernetes, nomad job в terraform для описания ресурсов nomad
Сервис использует DBaaS, если это не чрезмерно дорого
Вспомогательные приложения устанавливаются в k8s с использованием зависимостей helm chart
Сервис работает как минимум в 2 экземплярах на стадии и 3 в продакшене

Эксплуатация

Сервис пишет логи в stdout
- При запуске пишет свою конфигурацию (маскируя или скрывая конфиденциальные данные)
- В режиме отладки логирует все сырые (до обработки для входящих и после обработки для исходящих) входящие и исходящие запросы и ответы
- Сервис логирует сырые данные для всех исходящих запросов, завершившихся ошибкой или недействительным ответом
Сервис настраивается с помощью переменных окружения или файлов во время выполнения (не во время сборки)
Сервис отвечает 200 на /liveness, если не требует перезапуска
Сервис отвечает 200 на /readiness, если может принимать трафик
Сервис не падает, если базы данных или другие сервисы, от которых он зависит, недоступны
Все HTTP-запросы к другим сервисам и базам данных имеют таймауты. И сумма всех таймаутов меньше общего таймаута всего сервиса

Мониторинг

Сервис предоставляет метрики prometheus Golden Signals с /metrics или
Команда сервиса отвечает за поддержание CI/CD, правил оповещений и дашбордов в grafana

Дополнительные Требования

План

В компании есть несколько человек, способных поддерживать сервис

Код

Сложные и наиболее важные части бизнес-логики покрыты модульными тестами для ускорения разработки
Сообщения коммитов соответствуют https://www.conventionalcommits.org/en/v1.0.0/
Идентификаторы версий релизов сервиса соответствуют https://semver.org/
Используется vendoring (хранение зависимостей в репозитории) для тех сред выполнения, где это возможно

Тестирование

В CI/CD настроены обязательные автоматические проверки стиля кода. Примеры утилит: Golang - golangci, PHP - PHP_CodeSniffer, TypeScript/JavaScript - ESLint.
В CI/CD настроены обязательные статические проверки кода. Примеры утилит: PHP - Psalm/Phan, Golang - golangci, TypeScript/JavaScript - ESLint.
В CI/CD настроены обязательные автоматические проверки уязвимостей зависимостей. Примеры утилит: Golang - govulncheck, PHP - composer audit, TypeScript/JavaScript - npm audit, yarn audit, general - trivy, OWASP dep-check, Snyk.
В CI/CD настроены обязательные автоматические проверки исходного кода на наличие сохраненных учетных данных (сканер учетных данных).
Если приложение имеет API, оно покрыто дымовыми тестами, которые запускаются автоматически в CI/CD.
Бонусное задание: если приложение имеет API, оно покрыто регрессионными тестами, которые запускаются автоматически в CI/CD.

Развертывание

Релизы сервиса происходят не реже одного раза в 2 недели
Бонусное задание: среды создаются динамически по веткам
Бонусное задание: у сервиса есть канареечная среда с реальным трафиком или его копией

Эксплуатация

Сервис пишет логи в stdout в формате: <время (в формате ISO8601 в UTC, с микросекундами)> <уровень> <сообщение>. Например: 2022-10-25T10:44:15.123456Z INFO Некоторая информация
Сервис корректно завершает работу по сигналу SIGTERM
Сервис осмысленно использует повторные запросы (с экспоненциально увеличивающейся паузой между запросами: 1 секунда, 2, 4, …), circuit breaker, backpressure при работе с другими сервисами и базами данных
Сервис готов к изменению IP-адреса используемого сервиса и следует TTL в DNS-записях
/liveness, /readiness и /metrics обслуживаются на отдельном порту
Сервис предоставляет бизнес-метрики в формате prometheus по запросу на /metrics
Бонусное задание: сервис полностью совместим с OpenTelemetry