Комментарии 7
На всем не пост-советском пространстве распространён термин Service Desk, цель которого - обработка событий, поступающих в виде обращений пользователей или сообщений систем мониторинга. Смысл объединения - чтобы операторы могли коррелировать одно с другим и понимать, когда мониторинг семафорит но проблемы по факту нет (и не поднимать зазря волну), а когда, наоборот, мониторинг что-то упустил, проблема есть, и зелёный график не соответствует действительности.
По целям. Чтобы достичь высокого аптайма, нужно начинать с MTTR, которое обеспечивается грамотным Incident mngt, и MTBF, которое обеспечивается Problem mngt и отказоустойчивой архитектурой (см Availability mngt). Уменьшать время реакции, конечно, полезно, но это лишь 5-10% от общего времени восстановления. Поэтому, не в первую очередь.
Информирование о сбоях. В таком виде NOC заменяется системой алертинга примерно полностью.
Как практик в области, рекомендую углубиться в описание процессов в ITIL, а не изобретать велосипед. Все рекомендации и процессы описаны ещё лет 20 назад и постоянно совершенствуются. В 2019 году вышла уже 4я версия библиотеки.
А причем тут NoC?
Кажется это обычные метрики реагирования на сбои
Это подмножество обычны метрикик реагирования на сбои, но если у вас есть конкретная NOC-команда - то она может отвечать и работать в рамках этих конкретных метрик. То есть именно они те самые предметные владельцы Response, Acknowledge, Assemble. А не кто-то еще. Это скорее особенность и KPI при такой таксономии отделов.
На всем не пост-советском пространстве распространён термин Service Desk, цель которого - обработка событий, поступающих в виде обращений пользователей или сообщений систем мониторинга. Смысл объединения - чтобы операторы могли коррелировать одно с другим и понимать, когда мониторинг семафорит но проблемы по факту нет (и не поднимать зазря волну), а когда, наоборот, мониторинг что-то упустил, проблема есть, и зелёный график не соответствует действительности.
По целям. Чтобы достичь высокого аптайма, нужно начинать с MTTR, которое обеспечивается грамотным Incident mngt, и MTBF, которое обеспечивается Problem mngt и отказоустойчивой архитектурой (см Availability mngt). Уменьшать время реакции, конечно, полезно, но это лишь 5-10% от общего времени восстановления. Поэтому, не в первую очередь.
Информирование о сбоях. В таком виде NOC заменяется системой алертинга примерно полностью.
Как практик в области, рекомендую углубиться в описание процессов в ITIL, а не изобретать велосипед. Все рекомендации и процессы описаны ещё лет 20 назад и постоянно совершенствуются. В 2019 году вышла уже 4я версия библиотеки.
Спасибо Станислав, мы с вами прекрасно знаем как в стартапе прекрасно работается с отказоустойчивой архитектурой и какие ресурсы были выделены в этом конкретном примере. В условиях ограниченного бюджета и конкретных штатных единиц более подходящим и управляемым оперировать в рамках описанной выше таксономии. Безусловно, вы как более опытный специалист и с опытом внедрения ITIL-а, как более мачурного фреймворка имеете обширный опыт в работе с инцидентами. Было бы здорово поработать с вами в будущем.
"К примеру, у вас есть у вас дашборд с"
----
First Response Time (Время на реакцию)
Ориентир: SLA в 1 минуту.
Не верю. Судя по всему сотрудник сидит и тупо смотрит в монитор пытливо ожидая алерта, чтобы на него среагировать успеть за 1 минуту)
Что такое NOC-команда, и какие 5 KPI на нее вешать для улучшения аптайма вашей платформы