Інцидент-менеджмент на практиці: як ми вибудували процес від хаосу до системи
Сервер лежить, всюди паніка, команда бігає і метушиться – це інцидент. Кожна хвилина такого стану – це гроші та довіра клієнтів. У UPSTARS ми пережили чат, що червонів від повідомлень і перетворили хаос на системний процес за кілька тижнів.
У цьому блозі поділюсь досвідом моєї команди – розкажу, як впроваджували процес інцидент-менеджменту, де зіштовхнулись із проблемами, які технічні рішення знайшли та до якого результату прийшли. Це не покрокова інструкція з впровадження, а радше суб’єктивний досвід інтеграції процесу в UPSTARS.
Почнемо з бази: що таке інцидент?
Інцидент – це позаштатна ситуація, в якій фінальні користувачі не задоволені сервісом.
У цей момент команда намагається зрозуміти, що пішло не так, на чиїй стороні проблеми – ну і далі за списком. Ми, як і всі інші компанії, стикались з цією ситуацією, пройшли всі стадії поневірянь, та зрештою налагодили свій механізм опрацювання інцидентів.
Чим інцидент відрізняється від звичайної технічної проблеми?
Головна відмінність – у раптовості. Він впливає на роботу систем тут і зараз та потребує термінової реакції. Команда не може відкласти його «на потім», бо кожна хвилина означає втрату грошей та довіри клієнтів.
Як ми зрозуміли, що хаос більше не працює
Наш хаос зростав поступово. Кілька факторів раз за разом змушували замислитись над необхідністю нового рішення:
Зростання команд і втрата контролю
Спочатку команда була невеликою: у кожного була своя зона відповідальності, а в разі інцидентів можна було викликати чергових навіть серед ночі. З часом кількість команд зросла, моноліт почав перетворюватися на сервіси, пряма комунікація між командами зменшилася. Відповідальність за сервіси стала абстрактною, тож виникла потреба у впровадженні чергувань по командах.
Спроба вирішити проблему через OpsGenie та Slack-бота
Ми адаптували OpsGenie під свої потреби та почали створювати інцидент-бота для Slack. Спершу все виглядало просто: наші співробітники генерують інциденти, розробники їх вирішують. Але виявилось, що не всі колеги розуміють, яка команда за що відповідає. Спроби замапити сервіси на функціонал через фокус-групу не спрацювали: команди росли занадто швидко, і будь-який мапінг виявився нестабільним.
Масла у вогонь підлив лист від OpsGenie. Повідомили, що сервіс більше не буде підтримуватись і його невдовзі згорнуть. Тож ідея боту і використання OpsGenie втратили сенс.
Пошук нового рішення
OpsGenie трансформувався у Jira Service Management, що відкрило нові можливості інтеграції з іншими продуктами Atlassian. Ми почали досліджувати цей інструмент і вирішили більше не вигадувати велосипед, а вивчити готові рішення для роботи з інцидентами.
Чому звичні інструменти не підійшли
Підписуйтеся на наші соцмережі
Як ми робили раніше:
На проді з’являється інцидент. Той, хто його помітив, біжить в спеціалізований чат в Slack і пише про нього, при цьому тегаючи чергового. Далі вся комунікація по інциденту відбувається в треді: підтягуються залучені розробники, SRE та інші дотичні тіммейти, створюються задачі й далі за стандартним протоколом.
Коли ми почали вивчати наявний на ринку інструментарій, то не змогли знайти адекватну реалізацію, яка б повністю влаштовувала як нас, технічну команду, так й інших зацікавлених осіб.
Майже у всіх ботів для Slack vs Atlassian, для створення інциденту у співробітника має бути платна ліцензія, що було незручно. Особливо якщо інцидент можуть створювати колеги з різних юнітів.
Але найбільший біль – те, що всі вони були загальними, без можливості кастомізувати під себе.
Наш шлях до нових процесів
Крок 1. Пошук рішень та повернення до ідеї інцидент-бота
Протягом тижня команда вивчала й тестувала різні варіанти інтеграцій. Зрештою стало зрозуміло, що готових рішень недостатньо, і потрібно створювати власний інструмент під наші потреби. Так інцидент-бот знову став актуальним.
Крок 2. Переписування бота та перші результати
Ми проаналізували код існуючого інцидент-бота та вирішили переписати його, залишивши лише Slack-вікна комунікації з додатковими змінами. За тиждень написали основу нового додатку. У результаті з’явився перший функціонал, з яким можна було працювати.
Крок 3. Тестування та нові вимоги
Розпочали тестування: спочатку власноруч, а потім залучили керівників інших команд. Поступово функціонал почав обростати «хочухами» і навіть пасхалками. Технічне питання ми вирішили, але залишалося організаційне: хто за що відповідає і як зробити створення інциденту максимально простим для співробітників.
Крок 4. Автоматизація через аналіз звернень
Щоб знайти рішення, ми залучили AI для аналізу всіх користувацьких звернень. Хвилювалися, що проблем буде занадто багато, але на практиці вийшло лише 7–12 пунктів. Далі ми склали список проблем щодо команд і це дозволило створити мапінг звернень за напрямами.
Крок 5. Налаштування залежних продуктів
Наступним етапом стала масштабна робота з налаштування всіх залежних продуктів, якими користується команда. Цей процес виявився настільки об’ємним, що заслуговує окремої історії.
Як працює наш інцидент-менеджмент зараз
Ми вже виокремили два типи інцидентів: critical та not critical, P1 та P2+ відповідно.
Якщо інцидент стосується масових звернень і впливає на основний функціонал продукту, це однозначно P1. Такий інцидент має опрацьовуватись одразу. При створенні цього інциденту одразу відпрацьовує алерт на відповідну команду (і чергового), реакція на такий інцидент не має перевищувати 15 хвилин 24/7.
P2+ – це такий тип інцидентів, який прямо не впливає на задоволеність, але може мати негативні наслідки й має бути опрацьований найближчим часом. Інциденти такого типу опрацьовуються в робочий день і не піднімають чергового серед ночі.
Самі інциденти можуть бути як умовно локального характеру, так і major. Відрізняються тим, що звичайний інцидент зрозумілий, а от major тягне за собою проведення Kaizen зустрічі.
Після отримання інциденту черговий відмічає алерт, як acknowledged і бере в роботу. Якщо є розуміння, що ситуація не може вирішитись в рамках цієї команди і має бути передана іншій, додає в алерт іншу команду. Так ми не втрачаємо фокус відповідальності по проблемі.
Всі зміни статусів по інциденту відображаються в Slack-треді, тож кожен може зрозуміти, на якій стадії вирішення ми знаходимось. Вся комунікація, включно з аттачментами, синхронізується в Jira.
Як відреагувала команда
При впровадженні рішення ми очікували, що буде неприйняття зі сторони «замовників», але все пройшло добре. Ситуація змінилась, коли ми почали збирати безпосередні команди, які відповідають за той чи інший функціонал.
Частина команди вже мала досвід чергувань, частина – або не мала зовсім або ті стосувались лише технічних моментів. Тож ми почали комунікувати з керівниками відділів, пояснюючи, навіщо це потрібно і як допоможе налагодити процеси. Проводили зустрічі й з командами, де пояснили: якщо все працює добре, то чергування – це просто формальність. Але були й ті, хто активно не хотів мати справи з інцидент-менеджментом.
5 уроків, які ми винесли з цього досвіду
1. Не намагайтесь одразу впровадити ідеальне рішення
Інциденти трапляються, і ви нічого з цим не можете зробити, окрім як зменшити шкоду. Єдине питання: як з цим боротись, щоб мінімізувати вплив на фінального користувача. У нашому випадку рішення прийшло еволюційним шляхом і вже було на поверхні, залишалось лише його систематизувати.
2. Спершу візьміть на озброєння прості інструменти
Ми не йшли шляхом впровадження чогось нового. Враховуючи велику кількість людей, залучених у процесі, це могло викликати відторгнення та неприйняття. Ми просто покращили вже наявний флоу.
3. Пояснюйте командам, чому це важливо
Співробітники просто отримали додаткові 5 кнопок, які автоматизують рутинну роботу. Але за кожною кнопкою стоїть велика робота різних відділів та рівнів компанії. Коли команди розуміють цінність процесу, вони легше його приймають.
4. Автоматизація має бути інтуїтивною
Процес має запускатися плавно, без зайвих питань і стресу. Тіммейти повинні відчувати, що новий інструмент полегшує їхню роботу, а не створює додаткові бар’єри.
5. Не намагайтесь обігнати самих себе
Якщо у вашій компанії немає розгалуженої архітектури й достатньо вже наявного процесу – цього цілком може вистачити. Кожне рішення повинно бути інтуїтивним і побудованим на культурі саме вашої компанії.