Расскажи про то, как вы контролируете надежность ваших сервисов, какие метрики считаете для SLA/SLO? Как организованна работа по инцидентам - в идеале конечно на примере пары постмортенов =)
Для сла метрики стандартные - сколько не работал сервис с точки зрения клиентов. Там самые простые (если не погружатся в тонкости). То есть подсчёт по времени 50х ошибок (грубо говоря).
Так внутри конечно метрик больше. RPS по базам, по REST/HTTP запросам. Сколько каждый сервис тратил времени на запрос к базе, сколько и какой размер пакетов передавался, сколько и каких пкетов в итоге передано/получено от клиентов. Ну и базовые загруженность сетевых интерфейсов (дропы, pps, bw), диски (iops и т.п), ОЗУ, CPU. Стандартно довольно. Всё сведено на борду для саппорта 1/2 линии.
Если инциденты уровня "ой отвалился в 5 утра сервер от кластера немного поштормило (+n к времени запроса к базе например), но всё перебалансилось и стало хорошо" - решаются в штатное время. Уровня "АААА!!! ТУТ НИЧЕГО НЕ РАБОТАЕ ААААА!!!" - тогда уже могут текущего дежурного "дёвопса" поднять. Класска опять же.
По самим метрикам проблем нет совершенно. Объясняешь лиду нужной команды почему она нужна, какие значения должны выдаватся и частота. Дальше они делают, мы проверяем удовлетворила ли (потому что тут QA уже мало помогут и через них дольше).
Постмортеры довольно скучные так-то. Померло железо, но софт нормально не обработал это и "завис" продолжая отвечать на лайвнесс пробу. Из-за этого шедуллер не переназначил такой под на другую ноду. Что привео к n% деградации сервиса (те самы 50х-и по сути). Решение - правильная проба и баг в разработку.
Так что ничего прям уровня "мы проебали базу гитлаба" поведать не могу.