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

Привет, Хабр! Меня зовут Никита Борзов, я руковожу командами поддержки и внедрения инфраструктур в K2 Cloud. В этой статье из моего доклада на конференции K2 Cloud Conf ’26 я хочу поговорить про то, что поддержка — это не один инженер за терминалом, а система коммуникаций, которая работает параллельно с техническим решением. Именно её архитектура определяет, насколько болезненным будет инцидент для клиента.

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

Два вида поддержки и одно клиентское ожидание

Прежде чем разбирать инцидент, нужно зафиксировать контекст — иначе непонятно, почему решения принимались именно так.

У нас два вида поддержки, и они принципиально различаются по зоне ответственности.

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

Второй вид — Professional Services — покупается отдельно. Это команда, которая работает уже не с платформой, а с инфраструктурой конкретного клиента: проектирует, погружается в детали, ведёт документацию и обеспечивает работоспособность 24/7. Если платформенная поддержка смотрит на облако в целом, то Professional Services смотрит на ваш проект.

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

Если хотя бы одно условие не выполнено — клиент узнаёт о проблеме сам, пишет в поддержку и запускает процесс эскалации. Именно так и произошло 20 ноября.

Как устроена поддержка изнутри

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

Первая линия — точка входа для любого обращения. Именно здесь тикет принимается в работу, получает приоритет и маршрутизируется дальше. Первая линия дежурит круглосуточно и одинаково быстро реагирует как на алерт от мониторинга, так и на сообщение клиента. Её задача во время инцидента — не решать техническую проблему, а следить за тем, чтобы процесс не остановился: если SLA использовано на 70%, первая линия идёт к инженерам и запрашивает статус.

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

Professional Services устроен сложнее, внутри него три роли. On-call инженеры работают 24/7 и когда падает инфраструктура клиента, подключаются по звонку — как правило, именно они ведут инцидент до закрытия. Проектный инженер закреплён за конкретным клиентом: он глубже всех понимает архитектуру и ведёт документацию, которая позволяет всей дежурной смене быстро ориентироваться в незнакомом проекте. Технический менеджер — последняя линия эскалации: к нему идут либо когда инфраструктуры ещё нет и её нужно выстроить с нуля, либо когда инцидент настолько сложен, что предыдущие уровни не справились. 

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

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

Инцидент 20 ноября: хроника и выводы

Обнаружение: первые десять минут

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

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

Первичная реакция: следующие десять минут

Первая линия приняла поток тикетов, расставила приоритеты и определила масштаб: инцидент массовый, затронуты все клиенты платформы. К работе подключили сразу две команды — службу эксплуатации облака и Professional Services. О ситуации уведомили руководителя поддержки.

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

Впрочем, при массовом сбое одного сообщения недостаточно. Часть клиентов немедленно запустила эскалацию: звонки менеджерам, письма с требованием назвать время решения. Именно здесь проявляется первая организационная развилка — и самая болезненная.

Диагностика: пятнадцать минут на понимание

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

После этого клиенты получили официальные уведомления с конкретной формулировкой: диски недоступны, причина установлена, работа по устранению ведётся.

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

Эскалация и параллельные конф-коллы

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

Это разделение принципиально. Внутренний звонок должен быть техническим и быстрым — там нет места объяснениям «для бизнеса». Клиентский звонок должен быть понятным и спокойным — там нет места техническому жаргону и неопределённости. Смешивать их значит,  сделать оба плохо.

Служба эксплуатации облака нашла и устранила причину сбоя, после чего передала информацию всем командам. Professional Services вернулся к клиентам на конф-коллах и приступил к восстановлению их систем по инструкции от команды облака.

Остаточный эффект: когда «починено» ещё не значит «работает»

Здесь инцидент мог бы закончиться — но не закончился. Часть дисков после восстановления перешла в режим read-only. Системы клиентов формально получили доступ к дискам, но записать на них ничего было нельзя.

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

Дальше пути клиентов разошлись в зависимости от наличия Professional Services. Те, у кого поддержка была, получили готовое решение: инженеры восстановили работу их систем самостоятельно. Те, у кого поддержки не было, получили инструкцию и попытались восстановиться по ней. Если не получалось — приходили к менеджеру.

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

Постмортем: что происходит после

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

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

Этот документ согласовывается с руководителем поддержки и менеджером, после чего передаётся клиенту. Ценность постмортема выходит за пределы одного инцидента: рекомендации часто применимы не только в контексте конкретного облака, но и в других средах, где работает инфраструктура клиента.

Инструменты и метрики: чем измеряется качество поддержки

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

Обнаружение проблемы

Первый рубеж — мониторинг. Выбор инструмента зависит от инфраструктуры клиента: Prometheus там, где стек современный, Zabbix — там, где среда требует более классического подхода. Визуализация в обоих случаях идёт через Grafana. Дежурная смена смотрит на дашборды круглосуточно, алерты настроены на автоматическую отправку команде.

Сейчас мы тестируем Monq — инструмент, который должен закрыть один конкретный разрыв: позвонить инженеру до того, как первая линия увидит инцидент и позвонит сама. Разница в несколько минут на старте инцидента может существенно сократить время до его закрытия.

Учёт и маршрутизация

Все обращения фиксируются в Jira. Это не только трекер задач — это источник данных для анализа. Каждый закрытый тикет остаётся в истории, и именно на этой истории работает следующий инструмент.

Снижение нагрузки на инженера

Полгода назад мы начали тестировать ИИ-ассистент, который анализирует входящий тикет и сравнивает его с историей закрытых обращений. Если совпадение достигает 95%, инженер получает готовое предложение по решению — не как инструкцию к исполнению, а как гипотезу для проверки. Финальное решение всегда остаётся за человеком.

За шесть месяцев точность предложений выросла до практически полезного уровня. Главное правило при работе с таким инструментом — не снижать порог критического мышления по мере того, как ИИ всё чаще оказывается прав. Именно поэтому проверка рекомендаций инженером — не опциональный шаг, а обязательный.

Чем измеряется результат

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

Для клиентов Professional Services SLA индивидуален и определяется требованиями к системе на этапе подключения. Диапазон широкий: от сорока минут до восьми часов, в зависимости от критичности сервиса.

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

Заключение

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

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

Если обобщить опыт этого инцидента в практические выводы, они выглядят так.

• Мониторинг и клиент — равнозначные источники информации о сбое. Выстраивать поддержку так, чтобы клиент всегда оказывался быстрее мониторинга — значит системно терять время на старте каждого инцидента.

• Коммуникация с клиентом во время инцидента — отдельная работа, а не побочная функция инженера. Человек, который её ведёт, должен быть свободен от технического решения. Иначе страдает и то, и другое.

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

• И последнее. Поддержка — это инфраструктура, которая требует таких же инвестиций, как и техническая. Её не видно, пока всё работает. Её отсутствие очень заметно, когда что-то ломается.