Как мы научили ML группировать 50 000 событий в инциденты

Десятки, а иногда и сотни тысяч событий в день. Каждое — потенциальная авария, а может, просто шум. L1-инженеру нужно решить: добавить событие к инциденту? Создать новый? А может, это часть уже закрытого? Или всё серьёзнее — и перед нами экосистемный сбой, затрагивающий десятки сервисов? Раньше мы в МТС всё классифицировали вручную. Но при таком объёме и разнообразии инфраструктуры быстро поняли, что нужна автоматизация. Слишком велик риск пропустить важное, не найти корень проблемы, потратить драгоценные минуты в критический момент. В поисках решения придумали использовать то, что есть: богатую разметку от дежурных инженеров, накопленную за годы наблюдений. Так начался наш путь к инструменту, который с помощью ML группирует события в осмысленные цепочки, распознаёт инциденты и помогает дежурным работать точнее, быстрее и спокойнее. В этой публикации мы — Михаил Копытин, руководитель команды разработки, и Евгений Лачугин, руководитель экосистемной команды поддержки в МТС Web Services — расскажем, как построили решение, какие архитектурные решения приняли, какие грабли собрали и как достигли точности выше 80%.

https://habr.com/ru/companies/oleg-bunin/articles/929928/

#itsm #надежность_системы #mcc #ml #ai #алерты #инцидентменеджмент #корреляция #бинарная_классификация

Следствие вели, или Культура инцидент- и проблем-менеджмента в Ozon

Обрыв каналов связи, багованный релиз, мискоммуникация… Серия загадочных событий, авантюрный детектив из цикла «Следствие вели…» — нет, не с Леонидом Каневским, и даже не Колобки, а команда разбора инцидентов, или просто Post. Хей-хей! Я Юля, и я специалист по сопровождению инцидентов в команде Post департамента SRE (Site Reliability Engineering). Когда я рассказываю своим друзьям, чем я занимаюсь на работе, мне часто говорят, что я работаю в детективном агентстве. Поэтому сегодня поговорим о том, как устроено управление инцидентами и проблемами в Ozon и чем оно схоже с работой детективов. Статья-расследование будет интересна всем, кто хоть раз задумывался о том, как большие компании не только справляются с форс-мажорами, но и учатся на своих ошибках. Расскажу о внутренней кухне и почему инцидент- и проблем-менеджмент — не «бюрократия», а палочка-выручалочка на пути к стабильности. Вперед вперед!

https://habr.com/ru/companies/ozontech/articles/925046/

#incident_management #incident #problem_management #postmortem #troubleshooting #инцидентменеджмент #управление_проблемами #управление_инцидентами #sre

Как работать с инцидентами, когда на кону большие деньги

Привет, Хабр! На связи Дарья Попова, тимлид группы мониторинга в Купере. Наша миссия — минимизировать потери от инцидентов для компании и обеспечить сервис на 10/10 для клиентов. Почему это именно группа — вы поймете дальше. Сегодня я расскажу, как мы выстраивали процессы и инструменты мониторинга и автоматизации — и как это все упростило нам жизнь.

https://habr.com/ru/companies/kuper/articles/928632/

#алертинг #инцидентменеджмент #автоматизация_рутины #бот #оповещение_об_аварии #метрики_процесса #runbook #критичные_сервисы #дежурные_инженеры #мониторинг

RAG‑агент для автоматизации инцидент‑менеджмента

Современные крупные организации сталкиваются с большим числом ИТ‑инцидентов — счет может идти на тысячи в месяц. Инциденты нередко повторяются со временем, однако найти похожий случай в базе знаний или в системе регистрации инцидентов непросто: стандартный поиск по ключевым словам часто неэффективен, а «держать в голове» детали всех инцидентов невозможно.

https://habr.com/ru/companies/otus/articles/912228/

#nlp #ai #bigdata #automation #инцидентменеджмент #machine_learning #rag

Тестирование без инцидентов в проде. Утопия или реальность?

Всем привет! Я старший специалист по тестированию в ITFB Group. Сегодня хочу поделиться с вами практическим опытом нашей команды — как нам удалось достичь нулевого количества инцидентов в продакшене за отчётный период. Это не теория, а реальная история из проекта крупного банка, где мы внедрили систему процессов, позволившую минимизировать риски. Если вам интересен практический подход к предотвращению сбоев, давайте разберём его вместе.

https://habr.com/ru/companies/itfb/articles/911760/

#itfb #тестирование #регрессионное_тестирование #qa #agile #инцидентменеджмент #автоматизация_тестирования #разработка_по #разработка_приложений

Как принимать решения при сбоях в IT-системах: методы поддержки принятия решений

Представьте ситуацию: вечер, срабатывает тревога - ваш интернет-магазин лежит в самый разгар распродажи. В логах куча ошибок, но явной причины не видно. Знакомо? Вот тут-то и начинается самое интересное. Я 3 года проработал в отделе сопровождения информационных систем и накопил десятки подобных случаев. Расскажу, как принимать решения, когда стандартные "перезагрузи и проверь" не работают. Понимаю, что кому-то мой опыт может показаться небольшим, а с некоторыми предложенными методами вы не будете согласны - предлагаю всё обсудить в комментариях. Расскажите о том, как это делается у вас в системах, а также поделитесь своим мнением.

https://habr.com/ru/articles/899266/

#itil #itsm #сбой #инцидент #инцидентменеджмент #поддержка #администрирование

Сбой с вероятностью один раз в 20 лет: о мартовском инциденте в дата-центре

30 марта сервисы, размещённые в одном из наших основных дата‑центров, оказались недоступны. К инциденту привела авария на опорной подстанции, которая спровоцировала отказ сразу двух вводов питания и последующий каскадный сбой оборудования. В этой статье подробно покажем, какие именно риски сработали — а для этого объясним, как устроено энергоснабжение в дата‑центре и на что это влияет. С этой точки зрения посмотрим, как развивались события в этот день и что бывает в дата‑центре, когда случаются ситуации, вероятность которых оценивается как «один на десятилетия». В завершение расскажем, что планируем делать дальше, чтобы не допустить повторения, и какой урок из этого могут извлечь другие инженеры.

https://habr.com/ru/companies/yandex/articles/897626/

#datacenters #датацентры #цод #инциденты #инцидентменеджмент #аварийные_ситуации #аварии_в_датацентрах #аварии_на_цод

Сбой с вероятностью один раз в 20 лет: о мартовском инциденте в дата-центре

30 марта сервисы, размещённые в одном из наших основных дата‑центров, оказались недоступны. К инциденту привела авария на опорной подстанции, которая спровоцировала отказ сразу двух вводов питания и последующий каскадный сбой оборудования. В этой статье подробно покажем, какие именно риски сработали — а для этого объясним, как устроено энергоснабжение в дата‑центре и на что это влияет. С этой точки зрения посмотрим, как развивались события в этот день и что бывает в дата‑центре, когда случаются ситуации, вероятность которых оценивается как «один на десятилетия». В завершение расскажем, что планируем делать дальше, чтобы не допустить повторения, и какой урок из этого могут извлечь другие инженеры.

https://habr.com/ru/companies/yandex/articles/897626/

#datacenters #датацентры #цод #инциденты #инцидентменеджмент #аварийные_ситуации #аварии_в_датацентрах #аварии_на_цод

Повышение качества выпускаемого ПО путем работы с инцидентами

Всем привет! Меня зовут Даша Мельникова, я ведущий релиз-менеджер в МКБ. В рамках этой статьи буду говорить об инцидентах, которые переходят на третью линию (на команду разработки). А еще о такой сущности, как инцидент ЗНО. Это сервисный запрос, обращение пользователя, в рамках которого мы лишь консультируем человека, а не правим код, то есть просто даем советы. Но если в рамках консультации возникает необходимость что-то доработать, то это выливается в создание новой фичи.

https://habr.com/ru/companies/mkb/articles/892962/

#инциденты #инцидентменеджмент #отказоустойчивые_системы #стабильность_системы

Руководство по проведению постмортемов. Как правильно разбирать инциденты для улучшения стабильности в будущем

Согласно определению postmortem – это процедура, посмертное вскрытие и исследование тела, обычно с целью установить причину смерти. Не очень приятное описание, но очень полезная практика, благодаря которой о человеческом организме и причинах его болезней и смерти удалось узнать много жизненно важной информации и использовать ее для сохранения огромного количества судеб. Заимствование практик из соседних наук не редкость – из медицинской практики в нашу рабочую повседневность и пришел принцип создания постмортемов. Для чего же нам нужно проводить “вскрытие” системы после инцидента? Тем более, что жизнь «пациента» была сохранена, и команда, работавшая над сохранением жизни, свою долю стресса и опыта уже получила. Во-первых, постмортемы помогают установить причину возникновения проблемы. Да, мы спасли нашу систему от комы, но, если не понять из-за чего она пыталась впасть в предсмертный припадок, с большой долей вероятности она попытается отправиться на тот свет снова и вполне возможно, что очень скоро. Тут мы открываем вторую причину – с помощью аналитики посмотрема, когда мы выявили причины сбоя, мы можем предотвратить повторение инцидента. В-третьих, при проведении посмотрема “вскрытия” могут обнаружиться на первый взгляд неочевидные системные недостатки внутри наших процессов, которые оказывают опосредованное влияние на работу и нуждаются в оптимизации. Возможно, у нас в шкафу пылится дефибриллятор, в то время как мы в каждый экстренный момент используем ручной массаж сердца, хотя эффективность применения дефибриллятора снизила бы временные и физические затраты команды на реанимацию и уменьшила бы риски человеческой ошибки.

https://habr.com/ru/articles/878366/

#SRE #отказоустойчивость #инцидентменеджмент #postmortem #команды #администрирование