Customer Communications

Я регулярно вижу две крайности во внешней коммуникации во время инцидента. Одна — молчание: команда тушит, наружу не пишет никто, клиенты читают Twitter и заваливают поддержку. Вторая — поток: каждые пять минут «всё ещё расследуем», клиенты устают и отписываются от статусной страницы. Между ними лежит дисциплина: severity определяет аудиторию, ритм сводок — это обещание, а не «когда будет что сказать», тон честный и без нагнетания. Четвёртый лист под L1 Incident Management (рядом с Incident Response, On-Call Rotation, Severity Classification).

Что должен уметь

Главный навык на уровне L4 — выдерживать sitrep cadence как обещание, даже когда «нечего сказать». Клиенты читают молчание как «они растерялись или вообще не занимаются проблемой». Сообщение вида «в 14:30 — статус: расследуем; пробовали X, не помогло; сейчас проверяем Y; следующее сообщение в 15:00» — полноценное обновление, и доверия оно приносит больше, чем двадцать минут тишины и финальное «всё починили».

Знает матрицу «канал — аудитория»: какие инциденты идут на публичную статусную страницу, какие во внутренний Slack, какие письмом в customer success.
Знает базовые правила тона: честно и без нагнетания, признать влияние, сказать, что известно, сказать, что неизвестно, срок называть только при уверенности выше 80%.

Ведёт внешнюю коммуникацию во время инцидента в роли Comms Lead: сводки не реже раза в полчаса, пока активен SEV0, статусы investigating / identified / monitoring / resolved идут в правильном порядке.
Работает вместе с customer success и продажами: уведомление ключевых клиентов, шаблоны «что говорить тому, кто позвонил», адресные рассылки только затронутым.

Проектирует матрицу «severity → коммуникация»: какому уровню какие каналы (статусная страница, письмо, баннер в продукте, уведомление руководства, регулятор), какой ритм на каждом уровне, какие шаблоны под каждую комбинацию — и всё это пропущено через юристов и customer success.
Вместе с юристами и CISO применяет регуляторные триггеры точно: в GDPR ст. 33 отсчёт идёт от момента, когда контролёр узнал об утечке персональных данных, и там же есть исключение по уровню риска; в SEC Item 1.05 Form 8-K — от решения о том, что инцидент существенен для эмитента.
Использует статусную страницу осознанно: управление подписчиками, компромисс между открытой историей аптайма и её ценой, локализация под международную клиентскую базу.

L6+

Проектирует внешнюю коммуникацию на уровне организации: взаимодействие с регуляторами через юристов и CISO, порог, с которого докладывают совету директоров, публикация постмортемов как осознанная работа с доверием.
Решает, что выносить наружу: делать ли инцидент публичным вообще, писать ли до того, как влияние подтверждено, публиковать ли разбор «что мы из этого поняли» как часть бренда.

Материалы

Книги

Heather Adkins et al. — Building Secure and Reliable Systems (O’Reilly, 2020), главы 17–18 (Crisis Management, Recovery and Aftermath). Кризисная коммуникация в контексте SRE: внутренние сообщения против внешних, эскалации к регуляторам.
Betsy Beyer et al. — The Site Reliability Workbook (O’Reilly, 2018), глава 9, секция Communications. Роль Comms Lead в структуре инцидента, ритм сводок, разделение аудиторий.
Kathleen Fearn-Banks — Crisis Communications: A Casebook Approach (Routledge, 5-е изд.). Академическая кризисная коммуникация. Не про SRE, но подкладывает теорию под приёмы, которые в отрасли применяют по наитию.

Статьи и доклады

Atlassian Statuspage Best Practices — руководство от создателей Statuspage: когда обновлять, каким тоном писать, что делать с обещанными сроками.
GitHub October 21, 2018 Incident Report. Главный публичный кейс — см. ниже.
Cloudflare incident reports. Регулярные public post-mortems от Cloudflare. По моим наблюдениям, один из лучших образцов постмортема, который не стыдно опубликовать.
Honeycomb — How We Manage Incident Response (Fred Hebert). Про внутреннюю механику, но с честным разделом о том, кто и когда говорит с клиентами в маленькой команде, где выделенного Comms Lead просто нет.
Increment — Incident Response issue. Статьи от Stripe / Slack / Asana о customer comms.
GDPR, Article 33 — первичный текст: уведомление надзорного органа без неоправданной задержки и, где это возможно, в течение 72 часов с момента, когда об утечке стало известно; там же исключение по уровню риска.
U.S. SEC — Cybersecurity incident disclosure rules. Первичный источник для точной формулировки: Item 1.05 Form 8-K обычно подаётся в течение четырёх рабочих дней после того, как эмитент признал инцидент существенным, а не через четыре дня после обнаружения любого события.

Инструменты

Atlassian Statuspage — самый распространённый вариант: управление подписчиками, плановые работы, жизненный цикл инцидента, свои домены, API для автообновления из мониторинга.
Better Stack Status / Instatus / Statuspal — альтернативы Statuspage. По моим наблюдениям, их берут за более свежий интерфейс и цену. Statuspal хостится в Европе — аргумент для клиентов, которым важен GDPR.
Email / SMS broadcast — Customer.io, Braze, Mailchimp + transactional SendGrid/Mailgun. Настраиваются заранее, с готовыми шаблонами под разные сценарии.
In-app banners / system notifications — feature flag плюс компонент интерфейса, который показывает сообщение прямо в продукте. Работает, когда все клиенты авторизованы, то есть в B2B SaaS.

Best practices

Главный публичный кейс — GitHub October 21, 2018 Incident Report. Сервис работал с деградацией 24 часа 11 минут: 43-секундный разрыв связи между сетевым узлом на восточном побережье и основным дата-центром запустил автоматический failover MySQL, после чего в кластерах на двух побережьях оказались расходящиеся записи. Вернуться назад без потери данных было нельзя, и GitHub сознательно выбрал долгое восстановление вперёд вместо быстрого. Часть платформы всё это время работала штатно, а часть отдавала устаревшие данные, не доставляла webhooks и не публиковала Pages. Их постмортем — эталон публичной коммуникации: подробная хронология, конкретные факторы вклада вместо одной «причины», список того, что меняют, и прямое объяснение, почему выбрали медленный путь. Обратите внимание на подачу: нигде не сказано «мы лежали 24 часа», везде описано, что именно не работало — это честнее и одновременно мягче, чем формулировка, которую за них потом придумала пресса. По моим наблюдениям, это один из трёх-четырёх публичных постмортемов, которые в отрасли цитируют десятки раз, — если вы в теме впервые, начинайте с него.

Дальше — три вещи, которые проще решить до инцидента, чем во время. Первая: матрица «severity → аудитория» пишется заранее и целиком. SEV0 — статусная страница, письмо и уведомление руководства в первые пятнадцать минут; SEV1 — статусная страница плюс customer success через полчаса; SEV2 — статусная страница, если клиент это видит; SEV3 — только внутрь. Под давлением инцидента вопрос «писать наружу или нет» решается субъективно, и решают его каждый раз по-разному: то промолчат там, где надо было сказать, то поднимут панику на пустом месте.

Вторая: ритм обновлений — обещание, а не «когда будет что сказать». Молчание клиент читает как растерянность. Sitrep каждые полчаса, пока SEV0 активен, даже с текстом «всё ещё расследуем», сообщает ровно одно: мы работаем и держим вас в курсе. Прерывается этот ритм только статусом resolved.

Третья: статусная страница — первый источник правды, и обновляется она раньше почты и соцсетей. Порядок такой: страница, потом рассылка, потом Twitter, потом точечная работа customer success. Твит «мы лежим» при зелёной статусной странице бьёт по доверию сильнее самого инцидента.

Честно, без нагнетания и без поиска виноватых. Я регулярно вижу we are investigating an issue, висящее четыре часа без единой детали. Клиент из такого сообщения не понимает ни масштаба, ни что ему с этим делать: ни переключиться на запасной вариант, ни предупредить собственных клиентов. Работает другой шаблон. Признать влияние — что именно не работает. Сказать, что известно. Сказать, что пока неизвестно. Срок называть только при уверенности выше 80%, а не бросать we will be back in 15 minutes, когда это догадка. Невыполненное обещание бьёт по доверию сильнее честного «не знаем».

Severity для клиента и severity внутри — разные шкалы. «У нас внутри SEV1, значит, на странице красный баннер» — типичная путаница. Внутренний уровень описывает, как мобилизуется команда: собирать ли war room, с каким ритмом писать сводки. Клиентский описывает, что реально сломалось у пользователя. SEV1 с war room внутри вполне может выглядеть снаружи как degraded performance: чтение на десять процентов медленнее, данные целы, запасной путь работает прозрачно. Состояние публичной страницы (operational / degraded performance / partial outage / major outage) — третья, отдельная классификация, и выводится она из обоих значений сразу.

Уведомление регулятора начинается с вопроса о применимости, а не с одного таймера. GDPR ст. 33 привязывает срок к моменту, когда контролёр узнал об утечке персональных данных, и оставляет исключение по уровню риска. SEC Item 1.05 Form 8-K отсчитывает четыре рабочих дня от решения эмитента о том, что инцидент существенен. Это разные триггеры для разных субъектов и юрисдикций, поэтому заготовленные шаблоны и маршрут к юристам и CISO должны ссылаться на первичный текст, а не на памятку «72 часа и четыре дня».

Доверие строится открытостью, а не тишиной. GitHub, Cloudflare, Stripe и Discord публикуют подробные разборы после крупных инцидентов, и, по моим наблюдениям, это работает на доверие годами. Честное «вот что случилось, вот что мы из этого поняли» читается как профессионализм. Спрятанный разбор клиенты всё равно достроят сами, а слухи хуже фактов. Правило стоит записать заранее: инцидент, задевший клиента сильнее порога X, получает публичный постмортем в течение N дней.

Связанные листья

Severity Classification — severity задаёт и аудиторию, и ритм. Без явной классификации решение «кому писать» принимается на глаз прямо в инциденте.
Incident Response — роль Comms Lead в структуре командования инцидентом. В маленькой команде её несёт IC, в большой под неё выделяют отдельного человека.
Blameless Postmortem — коммуникация после инцидента и есть публичный, вычищенный от лишнего постмортем; тон blameless читается снаружи как профессиональная рефлексия.
Runbooks — заготовленные шаблоны сообщений живут в runbook под типовые сценарии: утечка данных, отказ региона, инцидент безопасности.
Service Ownership — владелец сервиса отвечает и за внешнюю коммуникацию по нему; кого из ключевых клиентов уведомлять, знает их менеджер.
Threat Modeling — у инцидентов безопасности своя регуляторная часть; моделирование угроз показывает, какие данные какого уведомления требуют.
Status Page Management — эксплуатация самой площадки: модель подписки, политика открытости по аптайму, анонс плановых работ, инфраструктура, не зависящая от продукта. Этот лист про что говорить, соседний — про как устроен канал.
DR Policy & Stakeholders — дерево оповещения для сценариев восстановления (руководство → совет директоров → регуляторы → клиенты → публика) — часть политики DR; обычная матрица аудиторий по severity расширяется до этого масштаба.

Открытые вопросы

Status Page Management отсюда уже уехал в отдельный лист (см. «Связанные листья»), и вместе с ним — вопрос локализации статусной страницы для международной клиентской базы. Осталось два незакрытых.

Первый — заранее заготовленные шаблоны сообщений (TBD), прошедшие ревью юристов, под типовые сценарии: утечка данных, отказ региона, инцидент безопасности. Пока не решил, подсекция это здесь или самостоятельный лист. Второй — практика публичных постмортемов как осознанная работа с доверием, как это делают Cloudflare, GitHub и Stripe. Она может стать подсекцией в соседнем листе про разбор инцидентов. А может вырасти в отдельный.