Внедрение процесса работы с инцидентами внутри компании OTUS
2026-03-10 23:07 Diff
https://otus.ru/journal/strong-vnedrenie-processa-raboty-s-incidentami-vnutri-kompanii-strong/4-1-21/

Проектная работа Романа Зулейкова, выпускника курса «Team Lead».

LinkedIn: https://www.linkedin.com/in/roman-zuykov/
Telegram: https://t.me/r0m4n364
Twitter: https://twitter.com/engineer_r0m4n

Идея проекта

На последних местах работы я активно занимался инфраструктурой, мониторингом и обработкой инцидентов. Поэтому уже умел улучшать процессы, связанные с мониторингом и решением инцидентов, когда проходил курс. Также я понимал потребности бизнеса в этом направлении.


Там, где я сейчас работаю, эти процессы были развиты слабо. Вот проблемы, которые мне предстояло решить:

— Бизнес плохо понимал, сколько времени мы недоступны для пользователя.

— Устранять инциденты было сложно, потому что проблемные вопросы плохо поднимались наверх, а зоны ответственности – не были определены.

— Пользователи не знали, когда мы недоступны. Каждый серьезный инцидент сильно увеличивал нагрузку на команду поддержки, бил по репутации компании.

Реализация проекта

Конкретизирую проблемы, нахожу решения

Мы определили, сколько времени нужно, чтобы среагировать на инцидент. 

Назначили команды, ответственные за тот или иной функционал, поделили зоны ответственности в инфраструктуре компании.

Предстояло научиться рассчитывать «время восстановления» для инцидентов, видеть слабые места в наших процессах и сервисах, определять продолжительность инцидента в каждом из уровней критичности. Так можно лучше оценить критичность инцидентов, точнее измерить наш SLI [«индикатор уровня обслуживания»].

Мы решили: пользователь должен знать, какой именно функционал недоступен, а также – примерные сроки восстановления.

Я начал оценивать возможные решения: изучил имеющиеся на рынке сервисы, прочитал статьи о том, как разные компании решали похожие проблемы, посоветовался со знакомыми из других организаций.

В итоге я составил три возможных решения с разными подходами:

— коробочное решение;

— собственная разработка;

— комбинация коробочного решения с собственными доработками.

В каждом случае требовалось оценить:

— затраты на тарифные планы в различных сервисах;

— сложность внедрения и стоимость готовых решений;

— сложность собственной разработки;

— трудозатраты, как со стороны разработчиков, так и со стороны SRE (и при внедрении, и при последующей поддержке).

Я выяснил, сколько та или иная реализация будет стоить для бизнеса. Кстати, подобный подход к оценке оказался одним из самых полезных навыков, освоенных на курсе: этот навык ещё не раз пригодится мне в работе.

Вместе с разными командами мы составили схему окончательного решения. Схема закрывала все наши потребности. Пожалуй, здесь я тоже должен поблагодарить преподавателей курса. Было очень много согласований, встреч, попыток найти компромисс с сотрудниками самых разных уровней: от инженеров до руководителей бизнеса. И без навыков делегирования, ведения дискуссии и решения конфликтных ситуаций я бы точно не смог прийти к нужному решению.

Затем мы составили дорожную карту и построили диаграмму Ганта. Согласовали сроки, принялись за работу.

Заключение

Эта проектная работа потребовала много времени и сил, но определённо окупилась. Я освоил много полезных навыков, увидел точки собственного роста, узнал, как могу стать лучше в каждом из направлений.