Уявіть, що у вашій компанії повністю перестав працювати вхід в один з основних фронтів. Як результат — клієнти розлючені, задоволення сервісом падає. Організація втрачає клієнтів, а, отже, і гроші. Як зарадити в цій ситуації, аби зберегти і перших, і друге?
Уявіть, що у вашій компанії повністю перестав працювати вхід в один з основних фронтів. Як результат — клієнти розлючені, задоволення сервісом падає. Організація втрачає клієнтів, а, отже, і гроші. Як зарадити в цій ситуації, аби зберегти і перших, і друге?
У великих організаціях за вирішення подібних ситуацій відповідає окремий процес управління інцидентами. Саме від ефективності процесу найчастіше залежить, чи зможе організація утримати і примножити кошти у разі настання нестандартних ситуацій.
dev.ua поспілкувався із IT Service Operation Lead (ITSOL) Богданом Дехтярем про те, як влаштований процес інцидент-менеджменту в Райфі, і що б трапилося, якби його не було.
Богдан ― випускник Львівської Політехніки. Має ступінь бакалавра за спеціальністю «Комп’ютерні науки». У Райффайзен Банку він працює близько трьох років. Нині займає посаду IT Service Operation Lead. Богдан відповідає за усі процеси, пов’язані з життям сервісів.
Інцидент менеджмент — це процес, що оптимізує реакцію команд на незаплановані події, чи перериви роботи сервісу для відновлення сервісу до його робочого стану максимально ефективно і з мінімальними затратами. Процес потрібен, щоб користувачі могли отримувати відповідний рівень сервісу (швидке відновлення у випадку виникнення неполадок), організація не втрачала кошти (мітигація наслідків неполадок максимально ефективним шляхом), приймати data-driven рішення (отримувати інсайти в питаннях роботи сервісів, що базуються на чітких метриках) тощо.
Управління інцидентами ― невід’ємна частина роботи команди Райфу, яка налаштована усунути усі можливі незручності для клієнтів та партнерів максимально швидко. Тут застосовуються відповідні SRE практики, data-driven decision making, а також Postmortem культура.
«Уявіть, що організація — це людський організм. Всі ми в дитинстві падали з велосипеда, а отже побиті коліна — невідʼємна складова з якою стикався практично кожен. Ця складова однак не змусила вас перестати кататись на велосипеді, тому що коліна кожного разу доволі швидко загоюються. Це і є інцидент менеджмент в широкому розумінні. Ваш організм завжди має заготований план відповіді на такі ушкодження і докладає усіх зусиль, щоб прибрати всі незручності якомога швидше», ― метафорично описує поле діяльності для управлінців інцидентами Богдан.
Однак особливістю процесу управління інцидентами Райфу є поєднання цього процесу з іншими світовими практиками, як, наприклад Postmortem Culture (робота над помилками). Повертаючись до аналогії, описаної вище, за допомогою цих практик, команди, що задіяні в управлінні інцидентами, оволодівають одним з прийомів Джекі Чана, щоб наступного разу замість того, щоб впасти з велосипеда клієнт, або система, з якою він працює, не впала, а зробила сальто і приземлення професійного гімнаста. «Це інцидент менеджмент в Райффайзен Банку», ― гордо пояснює фахівець.
За словами Богдана, у процесі управління інцидентами задіяні всі без виключення фахівці банку. «Якщо бути точнішим — всі, хто потрібен для вирішення конкретного інциденту в конкретний момент часу», ― каже він.
У процесу управління інцидентами є команда-власник, ITSO team. Однак, процес ― це спільна заслуга багатьох команд з різних сфер банку, починаючи від інженерів і закінчуючи юристами. Команда інцидент менеджменту складається з 14 людей ― ці люди координують, комунікують всередині банку, відслідковують динаміку інциденту.
«Що ж до найважливішої частини — вирішення самого інциденту, а пізніше і робота над помилками — то тут ми всі працюємо пліч-о-пліч», — розповідає він. За словами Богдана, в такій ситуації усі співпрацюють разом: і DevOps, якого підняли о другій ночі по OnCall для термінового вирішення питання, і будь-яка інша команда, що допомогає правильно проінформувати клієнта чи може долучитись до вирішення проблеми.
Як працює ця система, легко пояснити на прикладі ситуації, що описана на початку матеріалу. Богдан наводить два варіанти роботи організації ― із процесом управління інцидентами та без нього.
«Якщо в компанії немає процесу управління інцидентами, вірогідніше за все, розвиток подій буде наступним: перші звернення клієнтів будуть адресовані комусь з вузькоспеціалізованих технічних спеціалістів, які не зможуть вирішити комплексну неполадку», ― каже Богдан. На його переконання, фахівці звернуться до висококваліфікованих інженерів, до керівництва або до колег в пошуку рішення. Це займе від 30 хвилин до декількох годин часу.
Втім, якийсь інцидент буде ескалювати до high level менеджменту.
Менеджмент в свою чергу почне ухвалювати термінові рішення, для відновлення роботи бізнесу. «Через відсутність визначених груп стейкхолдерів та виконавців, такий інцидент переросте в дзвінок до 100 людей, 95 з яких будуть на дзвінку „про всяк випадок“. Найсумніше — цілком вірогідно, що вирішиться така ситуація за межами такого дзвінка, коли один з DevOps інженерів цілком випадково помітить і ребутне якийсь сервер на бекенді, який ніхто б і не подумав перевірити», ― констатує Богдан.
В іншому випадку, коли служба інцидент-менеджменту сформована як окрема структура, ситуація вирішиться в рази скоріше. Або ж її взагалі вдасться уникнути. «В ідеальному розвитку подій інциденту не відбудеться, так як алерт з моніторингу автоматично буде маршрутизований на команду, яка може виправити неполадку ще до того, як вона переросла в інцидент», ― розповідає Богдан.
Якщо ж інцидент таки мав місце, то після його виникнення першими отримують інформацію про неполадку команда інженерів першого рівня (комунікація та базовий аналіз, постановка задач). Вони збирають початкові деталі, валідують проблематику та ескалюють відповідній команді SRE-інженерів, що можуть вирішити конкретну неполадку.
Паралельно, розповідає Богдан, відбувається інформування всіх стейкхолдерів про наявність інциденту, відомий вплив та потенційний вплив. Це все, за його словами, займає 15-30 хвилин. За відсутності прогресу у вирішенні неполадки відбувається ескалація (будь-то вертикальна чи горизонтальна). По ходу вирішення неполадки і одразу після вирішення всі стейкхолдери інформуються відповідними каналами комунікації.
Після вирішення інциденту відбувається документація усіх фактів в інцидент тікет створений в перші хвилини інциденту. Потім інженери разом з іншими причетними до вирішення проблеми фахівцями проводять роботу над помилками та документують конкретні дії направлені на недопущення повторення неполадки в майбутньому, та покращення реакції на аналогічні кейси.
Ось кілька фактів, які засвідчують ефективність процесу інцидент менеджменту, який використовуют ь в Райфі.
«Інцидент менеджмент у вакуумі, однак не є чимось особливим чи унікальним, поєднання різних практик однак створює унікальний для кожної організації підхід», — каже Богдан.
Фахівці запевняють, що саме поєднання ІТІЛ (IT Infrastructure Library) та СРЄ практик в основі, а також мінорних вкраплень інших метологій гарантують чудовий результат для Райфу. «Уважний читач міг помітити вище згадки про Blameless postmortem та OnCall. Цей список можна продовжити і іншими відповідними практиками SRE. З цікавого, Райф зараз на шляху до імплементації SLO (service level objectives), що допоможе ще ефективніше управляти роботою сервісів, та досягнути навіть кращої стабільності сервісів», — привідкриває Дехтяр завісу розвитку процесу у банку.
