Оценка доступности сервиса
Всем привет! Недавно в тележке написал пост об оценке работы СТО, в котором затронул несколько тем, требующих детализации и разбора на примерах. Коль уж такой запрос есть, то я напишу описание того, как я делаю это на собственных проектах. К сожалению формат блога в ТГ не подойдет ввиду длины и необходимости пояснения картинками, поэтому пишу длинный пост в Телетайп.
Пара дисклеймеров: мой подход отличается от стандартов ITIL, ITSM и т.д., я очень люблю практичность в работе и стараюсь минимизировать то, что называется: "работа ради работы", поэтому постараюсь делать оговорки чем и когда имеет смысл пользоваться.
1. Доступность
Коль уж начинаем говорить о доступности - давайте зададим определение. В этой статье доступностью я называю состояние сервиса, при котором он в полной мере позволяет выполнять основные бизнес-функции. Всё остальное рассуждение строится вокруг этого определения, расширяет и дополняет его. Доступность является естественным КПЭ Технического директора и считается как отношение общего времени доступности всех сервисов компании к общему регламентированному времени их функционирования. Целевой показатель такого времени:
Для b2b с количеством пользователей менее 100 - 90%
Для b2b с количеством пользователей более 100 - 99%
Для b2с с ежедневным количеством пользователей меньше 10000 - 99%
Для b2с с ежедневным количеством пользователей больше 10000 и менее 1000000 - 99,9%
Для b2с с ежедневным количеством пользователей больше 1000000 - 99,99%
Пример.
Представим, что о СТО в b2b есть три сервиса. Два из них облачные с общей нагрузкой более 10 тыс. человек. Один сервис раскатан на 4 клиентах On Premise.
Поскольку уронить даже один стенд, обычно, является сильным ударом по репутации компании - я бы считал КПЭ следующим образом:
Веса я поставил экспертно. В идеале делать развесовку привязываясь либо к количеству активных пользователей, либо к выручке/прибыли или еще какой-то системе. Итоговый КПЭ техдира составил 62,5%, наверное, премию платить не стоит.
С доступностью самого сервиса все достаточно просто: все падения, ошибки, хаки и т.д. - это очевидные кейсы неработоспособности. Их можно мониторить стандартными настройками ПО для мониторинга (Zabbix, VM Monitor, или встроенный мониторинг клауда)
Это базовый уровень мониторинга в большинстве B2B проектов его абсолютно достаточно
2.2. Доступность бизнес-функции
Представьте, что в какой-то момент вы не можете загрузить фото в карточку FanID, например (= Такой сервис является доступным или нет?. Любой техдир скажет, что да, доступен, но в такой момент должен появляться бизнес (заказчик, продакт и т.п.) и говорить, что это 100% DownTime. На базовые бизнес-функции можно кинуть мониторинг. Например, можно мэтчить трафик - и выявлять нестыковки в логах. Уверяю, что тут будет внутренний корпоративный срач, но чаще всего я уступал продактам и соглашался, что сервис "лежит".
Это продвинутый уровень мониторинга, юзайте его на B2C сервисах для B2b подойдет следующий способ мониторинга
2.3. Доступность по техподдержке
Ох, тут может быть столько срача между тремя участниками, что я выбрал максимально безопасную тактику:
Шаг 1. При получении обращения в техподдержку, прогоняются основные сценарии ответов и если обращение не закрыто - оно поступает на оценку продуктовой команде.
Шаг 2. Продуктовая команда либо дает инструкцию по закрытию и признает что сервис работает, либо клацает, что сервис не работает и причину (сломали или нашли крит). Если крит, то пишется таска
Шаг 3. DevOps и Техдир получают либо команду на откат к последней стабильной версии, либо на установку заглушки.
Шаг 4. Закатить крит-фикс и поднять сервис.
Шаг 5. Продуктовая команда подтверждает, что сервис поднят, дает инструкции техподдержке по фидбеку.
Шаг 6. Поддержка извиняется перед клиентом.
Смотрите, почему продуктовая команда появляется в процессе? Потому что нужен независимый взгляд. Пользователь говорит, что бага, разработчик, что фича. Только продуктовая команда говорит, что действительно все работает как надо.
Выглядит этот раздел сложновато, но если механизм реагирования отлажен, то на него не нужно много людей и время реакции может быть очень низким. Видел кейсы, где процесс срабатывает за 15 минут. Главное не ударяться в формализм. Формализовать кейс можно и после устранения крита.
3. Результат
3.1. Подсчет итогового времени
Теперь самое интересное: как это все посчитать? Нужно получать три временных ряда: 0-упало, 1-починили и построить следующую диаграмму по году
В приведенном примере считаем, что гарантированная работа сервиса должна обеспечиваться с 8.00 до 21.00. Вдруг случился плохой день для Техдира и сначала вывалилась 501-я на 3 часа, потом сервис работал с диким лагами с 15 до 17 и еще 2 часа решался крит из техподдержки. Итого за день downtime составил 7 часов. Представим, что это был единственный плохой день для техдира в году. Тогда какой будет его КПЭ? Гарантированный uptime должен был составить 13*365 часов, фактический uptime составил 13*365-7 часов. Итоговый КПЭ техдира по доступности составил 99,85% что неплохо только для сервисов с низким трафиком или для on-premise стендов
3.2. Восстановление
Дополнительным аспектом расчета КПЭ по доступности может являться
4. Что в договор включить, что в КПЭ техдиру
Для B2B проектов в 99% случаев будет достаточно базовой доступности сервиса в договоре, если грамотный заказчик начинает включать вам в SLA доступность бизнес-функций и ServiceDesk - подумайте, надо ли оно вам. Я на паре проектов увеличил прайс на техподдержку в 3 раза и все запросы по расширению SLA отпали (=
ТехДиру, доступность обычно включается в общий годовой КПЭ, который влияет на премию. Тут важно не переборщить. Больше 20-25% - будет явный борщ, и СТО вместо того, чтобы заниматься новыми фичами будет стоять у серверов и охранять кукурузу.
Сорри за лонг-рид, не сочтите за велосипед. Всех обнял,
The CTO