но в телеге проще общаться

а кто-то ещё, из присутсвующих тут, считает эти показатели (о которых пишут в статье)? автоматом кто-то научился считать их?

наш пока еще только MTTD пока еще только в разработке

а время начала инцидента уже научились автоматом определять? у меня с этим самая большая трудность :(

Так а в чем проблема:
- деградация бизнес метрик, или как написано в статье, около бизнес метрик
- количество ошибочных ответов свыше 1% от общего объёма ответов пользователям
- увеличение времени ответа в 3-4 раза относительно нормали;
+ Продолжительность вышеупомянутого в течении N сек/мин/интервалов_проверки;
Всё это говорит о деградации вашего сервиса/проекта, пора звать дежурного, врубать эскалацию и ставить отметку о начале инцидента.

Как только метрика/триггер вернулись в состояние ОК, и повторно не появились в течение часа/дня/какого-то_волшебного_мгновения, можно констатировать завершение инцидента и ставить ещё одну отметку. Разница во времени между ними легко высчитывается любым кроном.

👍

Конкретно у нас за это всё чудо отвечает Jira. При инцидентах мы создаём в ней  таски на дежурного(админа/дба/сетевика/девелопера_который_лил_в_монолит_свой_код_и_на_2_дня_автоматически_залетел_на_дежуство/любого_бедалагу_который_по_какой-то_причине_оказался_в_списке_дежурных_какой-либо_команды), в эти таски мы аттачим скрины графиков, логи, ссылки на предыдущие схожие таски, описания, инфу о состоянии дочерних зааффекченных метриках. И всё это дублируем в личку в Slack, добавляя туда кнопку "Acknowledge"(если на триггере описана эскалация), чтобы нашим ребятам небыло необходимости лазить в вебморду нашей системы алертинга.

Да, в теории это просто) но на практике намного сложнее, поэтому и интересно пообщаться с теми, кто это уже сделал

Но таск ведь создаётся по алерту? А как фиксируете время начала проблемы?

Я же выше описал.

Ну т.е. Время начала вручную указывается?

Тебя интересуют конкретные метрики и способы их анализа?

Нет)

Таск создаётся автоматически при алерте, Алерт формируется на основании анализа входящих метрик и их исторического поведения.

Ага, это и у нас так) просто время срабатывания алерта != времени начала проблемы иногда

Зависит от многих факторов, но по опыту, время простоя до сработки алерта по тригеру ~= времени простоя до возвращения триггера в ОК. Поэтому время жизни инцидента приблизительно точное.

Статья написана наспех.

<время простоя>/<длительность периода> * 100 = процент доступности за период

Скорее недоступности, которую потом надо вычесть из 100 для вычисления доступности (аптайма).

Согласна. Вот сейчас так и считаем приблизительно 🙁

Закладывайте эти знания в ваши скрипты анализа инцидентов, и оно будет более точым. Тут уже на какие то секунды счёт - не уверен что это супер критично. Первоначально был вопрос как это делать автоматизировано. Ответ, я думаю, вы получили, руками ничего считать не надо