Уявіть звернення, яке надходить до служби підтримки посеред збою: «У нас не проходять платежі. Це у вас чи в нас?». За кілька хвилин схожі звернення надсилають уже інші клієнти.
Відповіді першої лінії на ці звернення і є повідомленням про збій для цих клієнтів, навіть якщо ніхто його так не називав. Тож питання не в тому, чи говорити з клієнтами під час інциденту. Питання в тому, хто вирішує, що саме їм сказати і коли.
Повідомлення про збій починається в черзі підтримки
Atlassian у посібнику з комунікації під час інцидентів перелічує групи, яким потрібні оновлення. Одна з них - команда першої лінії підтримки: люди, які безпосередньо відповідають на запитання клієнтів і повідомляють їм новини під час інциденту.
Отже, перша лінія водночас і отримувач, і канал. Їй потрібні факти раніше, ніж клієнтам, інакше вона відповідає навздогад. А кожна її відповідь під час інциденту стає оновленням для клієнта.
Як розподілити цю роботу? У книжці Google Site Reliability Engineering сказано, що під час інциденту окремі ролі слід доручати конкретним людям. Одна з них - комунікація. Людина в цій ролі є «публічним обличчям» команди реагування, і до її обовʼязків належать регулярні оновлення для самої команди й зацікавлених сторін. Над самою системою працює інша роль.
Інженер, який усуває збій, не має часу думати над формулюваннями. Тому пише одна призначена людина, хтось із команди реагування передає їй факти, а перша лінія отримує кожне оновлення ще до того, як його побачать клієнти. Як звести звернення від різних клієнтів до одного інциденту, ми описали в статті про підтримку бізнес-клієнтів.
Перше оновлення - ще до того, як відома причина
Посібник PagerDuty щодо сторінок статусу радить опублікувати перше оновлення протягом 10-15 хвилин після виявлення збою. Причина для цього не потрібна. Замість неї, за Atlassian, перше оновлення має визнати проблему, коротко описати, що відомо про наслідки, пообіцяти наступні оновлення і, якщо це можливо, зняти побоювання щодо безпеки чи втрати даних.
Наслідки - це те, що бачить клієнт, описане його словами: «у частини клієнтів не проходять платежі». Назва сервера, який зупинився, - не наслідок.
Якщо є тимчасовий обхідний шлях, PagerDuty радить повідомити про нього одразу.
Перше оновлення, написане заздалегідь
Нам відомо, що [що бачить клієнт] - [у яких клієнтів або в яких функціях]. Ми вже працюємо над цим. [Обхідний шлях, якщо він є.] Наступне оновлення о [час].
Кожне оновлення називає час наступного
Atlassian радить у кожному оновленні вказувати, коли чекати наступного оновлення. PagerDuty пояснює навіщо: названий час наступного оновлення зменшує тривогу клієнтів і потребу звертатися до підтримки.
Як часто? У порадах Atlassian для Statuspage - кожні 30 хвилин або з іншою частотою, яка відповідає ситуації. PagerDuty вважає оновлення кожні 30 хвилин добрим орієнтиром для великих збоїв. Atlassian у посібнику ставить межу: поки збій заважає клієнтам користуватися продуктом, не довше ніж одну годину без оновлення.
Увесь графік тримається на нудному, але простому правилі. Якщо час наступного оновлення настав, а новин немає, оновлення однаково виходить. Atlassian пише, що навіть «ми досі працюємо над проблемою, нічого нового» краще, ніж мовчання. Обіцяний час, що минув у тиші, показує клієнтові, що обіцянка нічого не важила.
| Оновлення | Коли виходить | Що в ньому |
|---|---|---|
| Перше | Протягом 10-15 хвилин після виявлення збою (PagerDuty) | Що бачить клієнт, що над цим уже працюють, обхідний шлях, якщо він є, і час наступного оновлення |
| Кожне наступне | Кожні 30 хвилин або з частотою, що відповідає ситуації (Atlassian Statuspage; PagerDuty - для великих збоїв); не довше ніж одну годину без оновлення, поки збій заважає клієнтам користуватися продуктом (посібник Atlassian) | Що змінилося або що змін немає, і час наступного оновлення |
| Останнє | Коли сервіс знову працює | Що все працює, що зробили, в одному-двох реченнях, і який розбір буде далі |
Один основний канал і однакові слова
Під час інциденту те саме запитання приходить через чергу звернень, чат, пошту і телефон менеджера, закріпленого за клієнтом. Atlassian радить обрати один основний канал і спрямовувати туди всіх з інших каналів. А в порадах для Statuspage Atlassian окремо радить: оновлення в усіх каналах мають бути узгодженими.
Для першої лінії це означає коротку відповідь на звернення про збій: що відомо, посилання на сторінку з оновленнями, час наступного оновлення. Змінилася сторінка - змінюється й відповідь, ще до того, як перша лінія відповість на наступне звернення.
Atlassian радить зробити основним каналом окрему сторінку статусу. Якщо її ще немає, підійде лист клієнтам, яких зачепив збій, або оголошення в клієнтському кабінеті. Важливо, щоб канал був один і щоб перша лінія знала, який саме.
Коли на звернення відповідає зовнішня команда
Якщо першу лінію веде підрядник, його команда першою бачить звернення, але факти отримує тільки від вас. Atlassian радить мати заздалегідь узгоджені формулювання: погодити їх із керівництвом і зберегти в шаблоні. Із зовнішньою командою це вже не порада, а частина домовленості. До першого інциденту варто вирішити чотири речі:
- Хто оголошує інцидент. Конкретна людина з вашого боку, з якою можна звʼязатися будь-коли і яка підтверджує, що серія звернень - це один інцидент.
- Що зовнішня команда надсилає без погодження. Затверджене перше оновлення: про проблему відомо, над нею працюють, ось час наступного оновлення.
- Хто пише наступні оновлення. Формулювання - за однією людиною з вашого боку. Зовнішня команда відповідає цими оновленнями на кожне звернення, якого стосується збій.
- Звідки приходять факти. Один канал, за яким стежить зовнішня команда, щоб перша лінія дізнавалася про зміни раніше за ваших клієнтів.
Останнє оновлення і розбір після інциденту
PagerDuty описує останнє оновлення так: коли сервіс відновлено, підтвердіть, що все працює стабільно, коротко поясніть, що зробили для виправлення, і пообіцяйте розбір після інциденту, який допоможе запобігти повторенню.
Цю обіцянку варто виконати й надіслати розбір клієнтам, яких зачепив збій. Якщо той самий збій повертається знову і знову, одного оновлення замало. Як за допомогою запису про проблему повʼязати такі звернення з однією причиною, ми писали в статті про повторювані інциденти.
Як працює IMMIDO
Ми ведемо цілодобову першу лінію підтримки у ваших власних інструментах. Працюємо як команда з фіксованою щомісячною оплатою, а не з оплатою за звернення.
Spribe - один із клієнтів, роботу з яким ми описали публічно. Там запити й інциденти ведуться в Jira та Slack, а за зобовʼязанням щодо часу відповіді, яке встановив клієнт, перша відповідь на кожен запит має надійти протягом 15 хвилин. Так це описано в кейсі IMMIDO для Spribe. Як ми ведемо першу лінію, розказано на сторінці технічної підтримки.
Якщо ваша перша лінія досі не знає, що казати клієнтам під час збою, домовтеся про це до наступного інциденту, а не посеред нього. Запишіться на дзвінок, і ми розберемо з вами чотири пункти домовленості із зовнішньою командою.
Джерела: Atlassian, Incident communication best practices (команда першої лінії, перше оновлення, час наступного оновлення, одна година, основний канал, «нічого нового», заздалегідь узгоджені формулювання) · Atlassian Statuspage, Incident communication tips (кожні 30 хвилин, узгоджені оновлення в усіх каналах) · PagerDuty, Status page guide (10-15 хвилин, 30 хвилин для великих збоїв, названий час наступного оновлення, обхідний шлях, останнє оновлення) · Google, Site Reliability Engineering, Managing Incidents (окремі ролі, роль комунікації) · IMMIDO, кейс Spribe.