Уявіть лист від бізнес-клієнта: «Це вже втретє цього місяця». Звіт, який мав прийти вночі, знову не прийшов. Перша лінія підтримки, тобто команда, яка першою відповідає на звернення, перевіряє, що сталося, надсилає звіт вручну й закриває тікет як вирішений. Так само, як і два попередні рази.
Кожне закриття було правильним, і жодне нічого не виправило. Для служби підтримки це окремі звернення з різними номерами. Для клієнта це та сама несправність, яку він бачить знову.
Повторювані інциденти помічає клієнт
Atlassian у посібнику з керування проблемами пише про це прямо: терпіння клієнтів уривається, коли вони помічають, що той самий інцидент стається кілька разів. Бізнес-клієнт не бачить ваших номерів звернень. Він бачить, що збій повернувся.
У підтримці бізнес-клієнтів це відчутніше: про ту саму несправність в одній компанії можуть писати різні люди, і другий автор може не знати, що перший уже писав. Служба підтримки рахує звернення, а не причини. Вона бачить кілька дрібних звернень, кожне з яких закрили вчасно. Що це один збій, який повторюється, не видно в жодному з них окремо. Саме перша лінія може відповісти клієнтові: це не новий збій, ось запис про нього, ось чия команда має його виправити. Так клієнт бачить, що закономірність помітили, - сама лише швидка реакція цього не показує.
Інцидент і проблема: що насправді закриває тікет
У керуванні ІТ-послугами це два різні поняття. Той самий посібник Atlassian наводить визначення з ITIL, набору практик керування ІТ-послугами: проблема - це причина або можлива причина одного чи кількох інцидентів. Інцидент, за тим самим ITIL, - це незапланований збій ІТ-послуги або погіршення її якості. Проблема - те, що цей збій спричинило.
Atlassian пояснює різницю на прикладі. Відкат нещодавнього оновлення може відновити роботу послуги й завершити інцидент, проте глибинна проблема лишається. Тікет закрито, причина нікуди не ділася.
На практиці різниця така:
| Інцидент | Проблема | |
|---|---|---|
| Що це | Незапланований збій послуги або погіршення її якості | Причина або можлива причина одного чи кількох інцидентів |
| Коли закінчується | Послуга знову доступна | Причину усунуто |
| Хто цим займається | Лінія підтримки, яка отримала звернення | Команда, що відповідає за систему, яка дала збій |
| Що вважають закриттям | Відновлена робота послуги | Зміна, після якої інциденти не повертаються |
Усередині керування проблемами є ще одне поняття - відома помилка. За визначенням ITIL, яке наводить Atlassian, це проблема, у якої є задокументована першопричина й обхідне рішення. Перша лінія вже знає, що робити, коли збій повернеться, а справжнє виправлення досі за кимось.
Що перша лінія робить із повторюваним інцидентом
Інженери дізнаються про несправність, коли її ескалюють. Клієнт - коли вона заважає йому працювати. Перша лінія бачить кожне звернення, тож саме вона першою може впізнати, що другий випадок - це той самий збій. Для цього потрібні чотири звички:
- Перед закриттям - пошук. Перевірити, чи не було нещодавно звернень з тим самим симптомом від того самого клієнта або щодо тієї самої системи.
- Привʼязати, а не почати з нуля. Нове звернення привʼязують до попередніх, і в ньому одразу видно всю історію.
- Один запис про проблему на одну причину. Запис про проблему - це одне місце у вашій системі обліку завдань, де зібрано причину, усі привʼязані до неї інциденти, обхідне рішення й виправлення. Другого випадку достатньо, щоб його відкрити. Кожен наступний інцидент додають до цього запису, а не заводять новий.
- Обхідне рішення - у базу знань. Якщо є спосіб не зупиняти роботу клієнта, його записують того самого дня, і наступна зміна операторів застосовує його одразу.
У записі про проблему мають бути власник і термін
Запис, за який ніхто не відповідає, лишається нотаткою. Виправлення робить інша команда, тож запис має потрапити в її чергу робіт. Atlassian у довіднику з керування інцидентами показує те саме правило у власному процесі Atlassian: кожну дію, що випливає з розбору інциденту, оформлюють як завдання в Jira й додають до черги робіт команди, яка за неї відповідає. Виправлення першопричин позначають як пріоритетні дії, і для них погоджено термін - 4 або 8 тижнів залежно від послуги, з нагадуваннями, доки роботу не завершать.
Там само визначено, що вважати першопричиною: оптимальне місце в ланцюжку подій, де зміна відверне весь клас інцидентів. Не сьогоднішнє звернення, а всі подібні.
Серед головних цілей письмового розбору інциденту книга Google про Site Reliability Engineering особливо виділяє одну: запровадити дієві запобіжні заходи, які зменшують імовірність повторення або його наслідки. Розбір без власника й без терміну описав інцидент, але не запровадив жодного запобіжного заходу.
Перевірити свою чергу просто. Чи можете ви для кожного відкритого запису про проблему назвати команду, яка відповідає за виправлення, і дату, до якої його мають зробити? Якщо однієї з відповідей немає, за виправлення ніхто не взявся, і причина породжуватиме звернення, доки її не усунуть.
Коли першу лінію веде зовнішня команда
Зовнішня перша лінія бачить кожен повторюваний інцидент, а системи, які їх спричиняють, лишаються у ваших інженерів. Якщо ніхто не домовився, як ці дві сторони взаємодіють, підрядник і далі правильно закриває звернення, а причина і далі їх породжує. Тому до першого звернення варто відповісти на чотири запитання:
- Де зберігаються записи про проблеми? У вашій власній системі обліку завдань, поруч із чергою робіт інженерів, а не в нотатках підрядника.
- Хто може відкрити запис? Перша лінія, вже на другому випадку й без окремого дозволу.
- Куди йде обхідне рішення? У базу знань, з якою працює команда, щоб ним користувалася кожна зміна операторів.
- Що показує регулярний огляд? Відкриті записи про проблеми, привʼязані до них інциденти, власника й термін, а не лише кількість звернень.
Як передавати складне звернення на наступний рівень, ми розібрали окремо: чим відрізняються L1, L2 і L3, тобто перша, друга і третя лінії. Тут питання вужче: перша лінія повинна мати змогу сказати «це не новий збій», і ці слова мають потрапити в чиюсь чергу робіт.
Як працює IMMIDO
У Spribe, міжнародній технологічній компанії, першу лінію якої ми ведемо (описано в нашому кейсі), запити та інциденти обробляються в Jira і Slack, база знань - у Confluence, а до послуги входить ескалація складних випадків на другу лінію (L2).
Незалежно від клієнта, ми ведемо цілодобову першу лінію підтримки у ваших власних інструментах.
За щоденну роботу команди з нашого боку відповідає її керівник. Ми працюємо як команда з фіксованою щомісячною оплатою, а не з оплатою за звернення, тож збій, що повертається, додає нам роботи, а не доходу.
Почати можна з розмови: запишіться на дзвінок і підготуйте кілька нещодавно закритих звернень від одного клієнта. Разом подивимося, чи немає серед них того самого збою, що повертається. Як ми ведемо першу лінію, описано на сторінці послуги.
Джерела: Atlassian, Problem management (визначення проблеми й відомої помилки за ITIL, приклад із відкатом, терпіння клієнтів) · Atlassian, Incident Management Handbook: Postmortems (завдання в черзі команди-власника, термін для пріоритетних дій, першопричини) · Google, Site Reliability Engineering, Postmortem Culture · IMMIDO, кейс Spribe.