Инциденты и коммуникация: что, как и зачем говорить, когда все сломалось / Виктор Попов

Спикер представляет себя как специалиста, занимающегося PR платформы, несмотря на инженерный контекст команды. Отмечается, что многие технические специалисты испытывают трудности с формулированием своих достижений, неспособные четко описать, что именно ценного было сделано за отчетный период. В рамках доклада определяются пользователи как все, кому предоставляется сервис, включая внутренние команды разработки и других специалистов, использующих платформу. Важно понимать, что опыт основан на коммуникации с технически грамотными пользователями, которые заведомо не являются враждебными, что упрощает построение доверия.

Опыт, которым делится докладчик, не претендует на абсолютную истину, а основан на личной практике в X5 на протяжении полутора лет. Применение изложенных методов требует критического осмысления применимости к конкретным условиям. В контексте пользователей, это могут быть как внешние клиенты, так и 500+ разработчиков и Data Scientists, использующих внутреннюю платформу. Всегда следует помнить о дисклеймере: собственная голова должна применяться для оценки релевантности методов.

Первый ключевой аспект — это доверие. В любой системе рано или поздно произойдет инцидент, и важно быть готовым говорить об этом открыто. Технические планы восстановления и отказоустойчивости важны, но не менее важна прозрачность перед пользователями о самой проблеме. Пользователи всегда узнают о сбое, и лучше, если они получат информацию от ответственной команды, а не из слухов.

Траст ми потому что вот надо верить

Если пользователь получает обрывочную информацию о недоступности сервиса, он склонен трактовать ее произвольно, делая выводы, далекие от правды, что немедленно подрывает доверие. Прозрачность заключается в том, чтобы заявить о проблеме первым. Например, в GitLab открыто демонстрируются публичные доски с метриками доступности, включая не самые лучшие показатели. Это формирует доверие, поскольку сервис не заявляет о недостижимых 100% аптайме, а честно сообщает о достигнутых 99.8%.

Когда пользователи доверяют компетенции команды и верят в транслируемую правду, они не только не мешают процессу восстановления, но и могут проявить неожиданную компетенцию и оказать помощь в решении инцидента.

Человеческий фактор часто называется основной причиной проблем в отрасли, однако это утрирование. Если проблема вызвана человеческим фактором, это, скорее всего, означает, что процессы не были настроены так, чтобы исключить возможность ошибки. Исключая случаи откровенного злого умысла или крайней некомпетентности, необходимо сосредоточиться на устранении системных уязвимостей.

Я никогда никому не вру потому что никого не боюсь только ты лжешь только когда боишься

Существует два пути при возникновении инцидента: скрыть проблему, заявив пользователям, что «вам показалось», или раскрыть факт сбоя и сделать выводы. Второй путь требует уверенности в себе и своей компетенции. Уверенность в том, что даже в случае несогласия работодателя специалист найдет новую работу, позволяет работать, а не прикрывать свою ответственность.

Счастье не оставляет шрамов вот инциденты шрамы оставляют

В мировой практике существуют документы по менеджменту инцидентов, применимые даже к IT-сбоям. Логика поведения при аварии, даже крупной, транслируется в IT-сферу, требуя схожих, хоть и менее масштабных, действий.

На основе SRE-подходов выделяются ключевые роли, необходимые для эффективного реагирования на инциденты. Эти роли должны быть известны и понятны заранее. Чем более автономна и четко прописана роль, тем выше ее эффективность, поскольку это минимизирует необходимость в постоянных согласованиях, что критично в условиях сбоя.

Роль координатора не обязательно должна принадлежать самому опытному или высокопоставленному сотруднику. Джуниор-специалист, который не до конца понимает систему, может быть отличным координатором, поскольку эта роль больше связана с софт скиллами — помощью пожарным и синхронизацией их действий. Центр принятия технических решений может находиться вне координатора, например, у одного из пожарных.

Лидер коммуникации отвечает за информирование пользователей о происходящем. Однако его ключевая задача — защита пожарных от прерываний, включая постоянные запросы от руководства, желающего знать, почему теряются деньги. Лидер коммуникации должен сглаживать гнев и негатив, соглашаясь с руководством и предоставляя нужную информацию, чтобы инженеры могли сконцентрироваться на работе.

К сожалению, не стопроцентная есть какие-то большие боссы которым очень интересно почему они теряют деньги прямо сейчас

Масштаб инцидента определяет необходимость формального разбиения ролей. Для мелких сбоев достаточно одного-двух человек, совмещающих несколько функций. Однако при длительных авариях, занимающих дни, критически важна явная передача эстафеты ролей. Любое недопонимание на этапе смены ответственного может привести к серьезным проблемам, поэтому требуется гарантированное подтверждение приема роли.

Героизм, когда сотрудник работает 20 часов подряд, часто является признаком нехватки профессионализма в системе. Усталость приводит к ухудшению качества принимаемых решений. Вводится понятие саппорт-роли, которая может взять на себя задачи по обеспечению базовых потребностей команды, например, заказ еды. Это простая задача, которую может выполнить не задействованный в тушении сотрудник, но о которой часто забывают в условиях кризиса.

Во время инцидента важно не молчать, так как в отсутствие информации пользователи склонны придумывать мрачные сценарии. Однако флуд недопустим — необходимо давать регулярный статус, соответствующий заявленным срокам. Если сроки сдвигаются, нужно объяснить причину, чтобы не подорвать доверие к компетенции команды в прогнозировании.

Коммуникации должны быть максимально таргетированы. Рассылка информации о специфическом инциденте на максимально широкую группу может быть неэффективной. Важно оценивать сроки трезво, так как многократное продление сроков из-за заниженных оценок подрывает доверие к прогнозированию. В случае длительных аварий, если пользователи не получают четкого объяснения причин задержек, возникает вопрос об адекватности занимаемой должности.

После устранения аварии необходимо сообщить статус о том, что все работает, но с какими ограничениями (например, сохраняется проблема с производительностью). Важно указать реалистичные сроки полного возврата в эталонное состояние. Если требуются действия от пользователей (например, перезапуск пайплайнов), они охотнее их выполнят, если доверяют команде и понимают, почему это необходимо.

Написание постмортема — это не формальность, а критически важный процесс, требующий артефактов инцидента, таких как журнал инцидента и записи координатора. В постмортеме важна хронология событий, откуда поступила информация, и, самое главное, какие конкретные шаги предприняты, чтобы подобное больше не повторилось. Если инцидент повторяется по той же причине, проблема заключается в процессах, а не в ошибке.

Для достижения корневой причины используется метод «Пять Почему». Это позволяет докопаться до истинного источника проблемы, который часто представляет собой череду случайностей. Например, удаление основной базы данных произошло потому, что случайно удалили реплику, а это было необходимо для остановки реплики из-за выросшей нагрузки, совпавшей с плановыми работами.

Постмортем без реальных задач бесполезен. Публичное освещение проблемы — это публичное обещание, что ситуация не повторится. Задачи из постмортема должны быть реальными, иметь сроки и ответственных, а не быть абстрактными формулировками. Выполнение этих обещаний конвертируется в доверие пользователей, а их невыполнение — в потерю этого доверия.

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

Анонсы работ должны быть сделаны «с человеческим лицом», объясняя, зачем они нужны и обосновывая срочность. Необходимо четко указывать влияние работ: какие сервисы будут недоступны или какие действия станут невозможными (например, отключение админки Kubernetes). Объяснение пользы (например, появление нового функционала или исправление бага с бэкапами) оправдывает временный простой.

Если вопрос задается более двух раз, на него стоит ответить массово. Это экономит время команды и снижает уровень стресса. Аналогия с табличкой в туалете в клинике показывает, как простое системное решение устраняет постоянный поток идентичных запросов, делая сотрудников менее задолбанными и ускоряя получение информации пользователями.

Ключ к эффективной коммуникации — краткость, которая является сестрой таланта. Необходимо отбрасывать все, что не несет смысла, включая излишнюю вежливость или канцеляризмы. Сообщения должны быть структурированы: одна мысль — один абзац. Это повышает конверсию чтения, так как пользователи сначала считывают жирный текст или заголовки, а затем углубляются в детали, если это необходимо.

Информационный стиль базируется на трех принципах: лаконичность (краткость), интерес и честность. Интерес достигается добавлением забавных фактов или шуток (например, о тануки, логотипе GitLab). Честность означает отказ от уверток и прямое освещение проблем, поскольку любая ложь вскроется. Для первичного анализа читаемости текста рекомендуется использовать сервис Главред.ру.

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

В конечном итоге, пользователи являются друзьями команды, даже если они еще не осознали этого. Предоставление лучшего сервиса — это не только высокие показатели аптайма, но и хороший пользовательский опыт (UX) и опыт разработчика (DX). Доверительные отношения позволяют получать ценную обратную связь, которая повышает качество продукта и лояльность.

Традиционное разделение Dev/Ops часто приводит к перекидыванию ответственности. В эту конструкцию необходимо добавить пользователя. Предлагается концепция DevUserOps, где фокус смещается на удовлетворение потребностей конечного пользователя. Это гарантирует, что правильность решений будет понята и использована теми, для кого они предназначены, минимизируя ошибки интерпретации.