Общая информация должна быть описана в общей wiki \ readme проекта.
- Название приложение, краткое описание, назначение, и информация о команде \ разработчике которая его поддерживает.
- Ссылки на дашборды проекта.
- Информация о людях \ командах которые могут деплоить приложение на прод.
- Критичность сервиса (тир1 - высоко критичное для бизнеса, тир2 - критичное для внутренних сервисов, тир3 - не критичное)
- Список критичных эндпойнтов сервиса, которые должны быть закрыты снаружи (basic auth или просто запрещены)
- Список критичных особенностей сервиса, в которые он отклоняется от best practice (к примеру, приложен некорректно работает в 2х копиях)
- Политика роллбека \ накатки фиксов
Далее требования к приложению разбитые на несколько категорий.
Приложение
- Все логи приоржения вываливаются только в stdout/stderr и не записываются ни в какие специфичные файлы
- Логи имеют log_level в сообщениях
- debug_log выключен для production по умолчанию
- При любых необрабатываемых ошибках, приложение крашится (fail-fast)
- Приложение умеет в gracefull shutdown
- Дизайн приложения \ кода был отревьювлен старшим разработчиком
Безопасность
- Приложение должно уметь работать в непривелигированном режиме (non-root user)
- Приложение не требует файловой системы с возможностью записи (в идеале может контейнер может быть запущен в режиме read-only)
CI/CD
- Описана специфичная информация о сборке (URL внешних сервисов от которых зависит сервис, обязательные переменные окружения)
- Приложение имеет шаг с тестами в своем пайплайне сборки
- Приложение не требует никаких ручных действий для деплоя в прод
- Инфомация о том как запускаются смок тесты (если они есть)
- Ожидаемое и максимальное время доставки кода в прод \ стейдж (от коммита до окружения, включает время запуска всех шагов, к примеру тестов)
k8s
- Приложение упаковано в helm chart
- Приложение имеет readiness probe (эндпойнт /health)
- Мы не используем liveness probe, для избежания дополнительных нагрузок и каскадных фейлов в моменты рестарта приложений
- Приложение может работать и работает в нескольких копиях (replicas count >=2)
- mem / cpu request выставлены (идеально, на основании нагрузочных тестов)
- mem limit = mem request
- CPU limit не выставляется, для избежания троттлинга
- Приложение корректно сконфигурированно для запуска в контейнере (java specific)
- Один контейнер - одно приложение
- Все ресурсы имеют необходимые лейблы (список стоит уточнить а дальнейшем, что то типа app, component, env, severety)
- Селекторы ресурсов используют максимально полный набор метрик (не только app, но еще и component, env, version и т д)
- Опционально: если приложение имеет повышенные требования к надежности (multi dc) настроены соответсвующие anti-affinity policy
- Опционально: если приложение требует специфичных нод, настроеные tolerations на специфичный пул нод
Мониторинг и сохранность данных
- Метрики приложения доступны по дефолтному пути /metrics
- Список "критичных" метрик приложения, на которые можно ориентироваться как на показатели нормальной работоспособности (SLO)
- Мы мониторим зависимые сервисы которые поставляются с самим приложением (postgres, redis, elastic)
- У нас есть дашборд по приложению в графане по опредленным заранее SLO/SLI
- У нас определены alert rules на основе SLO/SLI
- Настроены правила эскалации алертов
- Мы бекапим данные сервиса
Онколл и ситуации решения проблем
- Все заинтересованные лица имеют доступ в вики с общей информацией по проекту
- Команда имеющая доступ к выливке в прод, имеет доступ до продакшн окружения.
- Есть список рекомендаций, для решения известных проблем, или набор действий в случае неизвестных проблемы (скейлить, ролбечить, фикс)
- Сценарий действий в случае превышения времени недоступности описанного в SLA