Команда:
Все услуги (бизнес-сервисы) описаны — 5
Релизы регистрируются а едином каталоге — 10
Уведомляем пользователей и коллег о сбоях через единый механизм — 10
Есть команда дежурных инженеров 24х7 — 5
На дежурстве достаточное количество человек: 4 человека — 1, 5-6 человека — 2, 7-10 человека — 3, >10 человека — 5
Команда имеет актуальный runbook — 5
Есть коммиты  от SRE в основные продакшен сервисы (тот код, который обслуживает клиентов) не старше 6 месяцев — 10
Команда обеспечивает рекавери сервиса в 90% сбоев без привлечения разработчиков — 15

Процессы:
Любой член SRE команды может произвести релиз любого MC/BC/BO приложения — 2
Безопасные релизы: Используются Feature-toggle — 10
Безопасные релизы: Blue-green или Canary или rolling update релизы — 10
Релизы делаются без downtime — 15
Для любого релиза возможен rollback — 5
Возможен быстрый rollback: <1 мин — 10, <5 мин — 8, <10 мин — 5
Команда пишет постмортемы — 3
Все постмортемы старше 3-х месяцев переведены в статус «Закрыт» (выполнены все action items) — 20
Команда не использует прямой SSH доступ инженерами в регулярной деятельности (только во время крупных сложных сбоев) — 5
Раз в квартал все нагруженные сервисы профилируются (может делать команда разработки) — 10
Персональные данные отсутствуют в логах приложений — 20
Важные сервисы регулярно проверяются на (может делать команда разработки) — 15:
  Утечки ресурсов
  Оптимальную работу с базой данных
  Узкие места (файловые дескрипторы, место на диске, оперативная память, счетчики, iops, CPU и т.д.)
  И т.п.
  Нужен отчёт о проверках (Вики, Джира)
Команда ведет «дневник продакшена» — 3
Команда проводит продакшен встречу как минимум раз в две недели — 5:
  На встрече обсуждают вопросы: «Какие были проблемы на проде?», «Что съедает больше всего времени и сил при поддержке прода?», «Как можно все это поправить?» и т.п.
У команды есть регулярная (не реже раза в месяц) встреча с разработчиками — рассказ о продакшен — 8
У команды есть регулярная встреча с "бизнесом", где разбираются вопросы надежности — 10
SRE команда привлекается к ревью архитектурных решений командой разработки — 12
Есть онбординг и обучение для новых участников команды. Перед выходом на дежурство новенький сдаёт экзамен.	— 10

SLA:
Все MC, BC и BO сервисы имеют описанный, верифицированный и учитываемый SLA — 20 (5 если не верифицирован)
Команда разбирает каждый инцидент — 5
Во время сбоя автоматически считаем критичность сбоя (ущерб, число пострадавших и т.п.) — 10

Мониторинг:
Важные алерты доставляются с подтверждением получения от дежурного инженера — 3
Алертов <3 в день в среднем за квартал — 10
Логи собираются централизованно — 8
Приложения экспортируют метрики — 8
Мониторинг построен на запросах к метрикам, а не логам — 20
Триггеры алертов редактируются через Git и настроен процесс ревью — 5
Для мониторинга активно используются синтетические тесты на проде (пробер) — 20
На проекте используется End-to-End Tracing — 20
Количество "пропущенных" (не было алерта) сбоев (начиная с желтого и серьезнее) меньше 3 в квартал — 30
В течение квартала не было пропущенных и просроченных алертов — 5
Команда способна обнаружить существенные изменения в работе приложения под нагрузкой после релиза (потребление CPU, количество порождаемых внешних запросов, нагрузка на БД и т.п.) — 30

Доступность:
MC/BC/BO сервисы соответствуют SLA — 100
MC/BC/BO сервисы переживают отключение одного DC/availability-zones — 80
Есть возможность провести быстрый релиз: <5мин — 20, <10мин — 10, <15мин — 8
Есть бекап данных и возможность восстановления из бекапа регулярно (не реже раза в месяц) тестируется — 10
Есть план по восстановлению после тотального сбоя, когда все придется разворачивать заново — 30
Команда тестирует возможность восстановления после тотального сбоя, когда все разворачивается заново (не реже раза в год) — 50
Вспомогательные утилиты (logback, prometheus экспортеры) запущены в cgroups и не могут забрать ресурсы у основного приложения — 20