Incident status update англійською: що відомо, чого ще не знаємо і коли наступний апдейт
14:07, у каналі #incident уже двадцять повідомлень. Оплати в застосунку не проходять, графіки червоні, троє інженерів перевіряють кожен свою гіпотезу. Тут пише менеджерка підтримки: клієнти питають, що їм відповідати. Хтось має за п’ять хвилин написати англійською апдейт, який прочитають і колеги, і клієнти. Відомо поки мало, і саме це найважче сформулювати.
Чотири рядки першого апдейту
Апдейт читають люди, які не бачать Вашого дашборда. Їм потрібен вплив на користувачів, перелік сервісів їм нічого не скаже. Тому спершу пишіть, що бачить користувач, потім що Ви робите, чого ще не знаєте і коли напишете знову.
Час наступного апдейту працює як обіцянка, яку легко виконати, особливо коли апдейти пише окрема людина. Британська урядова цифрова служба в довіднику The GDS Way радить мати в команді реагування incident lead і communications lead: один лагодить, другий стежить, щоб апдейти виходили вчасно. У прикладі таблиці пріоритетів там же повна відмова сервісу означає оновлення щогодини, а суттєва деградація раз на дві години.
Часи дієслів тут несуть зміст. We’re investigating означає, що робота триває і висновку ще немає. We’ve identified the cause повідомляє, що причину вже знайдено. Речення We’ve identified the cause тримається на правилі Present Perfect про результат на зараз: дію завершено, а її наслідок важить у цю хвилину. Коли з’являється точний час, переходьте на минулий: Payments were restored at 15:10 UTC.
Невідоме вголос і без паніки
У першому апдейті найбільше хочеться вгадати. It’s probably the database звучить як висновок, хоча за ним лише гіпотеза. Через годину вона може не підтвердитися, і наступним повідомленням уже вірять менше. Чесніше назвати межу: We haven’t confirmed the cause yet.
Так само точно добирайте слово для стану. Cambridge Dictionary пояснює mitigate як «зробити щось менш шкідливим або поганим»: наслідки пом’якшено, причину не усунуто. Тимчасовий обхід називають workaround, тобто спосіб упоратися з проблемою, не розв’язавши її повністю. Після відкату релізу чесний апдейт звучить так: We’ve rolled back yesterday’s release, and payments are going through again. We’re monitoring while we look for the root cause. Слово resolved лишайте для моменту, коли причину справді прибрано.
Українська звичка підводить у дрібницях. «Найближчим часом» дослівно перетворюється на in the nearest time, і читач так і не дізнається, скільки чекати. Краще одразу назвати годину. «Проблема вирішується» стає the problem is being solved і звучить як відписка. Природніше сказати, хто що робить: we’re working on a fix.
Коли інженер пише свій перший апдейт англійською, причина часто опиняється в першому реченні. Що відбувається з користувачем, читач дізнається лише з третього рядка. Достатньо переставити речення, і той самий текст читається зовсім інакше.
Slack, статус-сторінка і лист клієнту
Один збій зазвичай описують тричі, щоразу для іншого читача. У внутрішньому каналі доречні назви сервісів, номери тикетів і короткі фрази без підмета: Rollback done, error rate back to normal. Що означає ETA і як звучить звичайний тон у Slack, показує гід із робочого чату англійською. Під час збою той самий тон стає ще стислішим.
Статус-сторінку читають користувачі, тож внутрішніх назв там немає. Замість payment gateway pods пишуть card payments, а замість метрик описують те, що людина бачить на екрані. Лист клієнту додає ще одне: що збій означає саме для нього і чи треба йому щось робити.
Поки збій триває: чотири незручні моменти
Чи називати час, коли все запрацює?
Лише якщо Ви в ньому впевнені. Зірваний строк шкодить сильніше за чесне «ще не знаємо». Натомість назвіть час наступного апдейту: We don’t have an estimate for the fix yet. Next update at 15:30 UTCЧи вибачатися вже в першому повідомленні?
На статус-сторінці й у листі клієнту так, одним коротким реченням: We’re sorry for the trouble this is causing. У внутрішньому каналі вибачення зайві: колегам потрібні факти. І не повторюйте його в кожному апдейті, бо тоді воно звучить як формальністьЩо писати, коли з минулого апдейту нічого не змінилося?
Однаково публікуйте вчасно: тиша читається як погана новина. Вистачить двох речень: We’re still testing the fix in staging. Next update at 16:00 UTCПисати від себе чи від команди?
У внутрішньому каналі природно звучить I’m checking the logs. На статус-сторінці та в листі говорить компанія, тому лише we: We’ve identified the cause. Змішувати I і we в одному апдейті не вартоПісля відновлення: розбір без пошуку винних
Коли збій закрито, команда сідає за розбір, який англійською називають postmortem або incident review. The GDS Way радить проводити його в культурі blameless post mortem, щоб сервіс ставав кращим. У мові така культура видна одразу: у центрі речення стоять система й процес, а людина відходить на другий план.
Ось рядок із чернетки розбору, яку тімлід написав після вечірнього збою: Oleh deployed a broken config and didn’t check it. Усе в ньому правда, і все одно речення відповідає на питання «хто», а розбір шукає «чому». Після правки: A config change reached production without validation, because our pipeline doesn’t block unvalidated configs. Тепер зрозуміло, що виправляти: перевірку в пайплайні, а не Олега.
Тон тут близький до доброго коментаря в рев’ю: описуйте зміну та її наслідок, автора не оцінюйте. Більше таких м’яких формулювань дають фрази для коментарів під час code review.
Що зробити сьогодні: відкрийте останній апдейт про збій, який Ви писали, і перевірте його за чотирма частинами. Чи видно вплив у першому реченні? Чи названо час наступного повідомлення? Такі тексти, як і розмову на самому розборі, можна натренувати. Англійська для DevOps і SRE з розбором інцидентів тренує такі апдейти на Ваших робочих ситуаціях.