Привет, Хабр! Мы — Дмитрий Дудов, руководитель разработки платформы T-Messenger, и Алексей Стрельников, Product Owner этой платформы. Мы считаем, что доступность — это история на пересечении бизнеса и техники.

В статье расскажем: 

• Как построить бизнес-мониторинг, получить согласованность между бизнесом и техникой и договориться о том, какая доступность должна быть. Посмотрим ситуации, когда договор есть, а цель не выполняется и что делать, чтобы найти те самые девятки.

• Почему воспринимаемая надежность расходится у пользователей и команды разработки. Поставим под сомнение выполнение цели по доступности и покажем, как проверяли, не аптайм ли это.

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

Как выглядит продукт

О нашем продукте проще всего рассказать через цифры. У нас в системе: 

• 700 млн чатов;

• 30 млн сообщений отправляются ежедневно, из них 13 млн — это маркетинговые рассылки о продуктах и акциях; 

• 400 тысяч клиентов обращаются в чат за поддержкой; 

• 5 тысяч операторов каждый день ждут клиентов онлайн. 

Если компания хочет как-то дотянуться до клиента, она пойдет через нашу систему.

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

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

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

По меркам таких систем, как Телеграм, мы пока небольшой продукт. Но у нас десяток различных систем хранения и обработки данных — от Elasticsearch для поиска и Postgres для транзакций до ClickHouse для аналитики, — десятки топиков в Kafka для обмена информацией между сервисами и сотни развернутых приложений (deployments) в Kubernetes. Это все потребляет тысячи ядер CPU каждый день. 

Как было в начале

Мы не всегда были такими большими, сложными и осознанными. Было время, когда пользователи жаловались, что у нас что-то не работает, а мониторинг показывал, что у нас все зеленое. Бывало наоборот, когда у нас срабатывали алерты, но никакого влияния не было. Случались и ситуации, когда алерты работали в тот момент, когда пользователи страдали, но мы не понимали, как именно они страдают и сколько их.

У нас есть история про индикатор «Количество операторов в онлайне». 

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

Индикатор-то полезный, но он ничего не говорил нам о реальном влиянии на клиента — только о потенциальном. Да еще и не гарантировал, что причина техническая и что SRE-инженер тут как-то поможет. 

Можно его, конечно, на линию посадить, чтобы обращения обрабатывал, — тоже помощь. 

Решили делать бизнес-мониторинг

Мэтч случился: мы и технически поняли, что есть проблемы, и пользователи нам об этом сообщили. Но как именно мы влияли и насколько задевали пользователей, было не понятно. И это было плохо.

Непонимание послужило для нас триггером, чтобы идти на шаг ближе к бизнесу и делать бизнес-мониторинг. Мы начали с команды Core: изучили, какие функциональности она предоставляет пользователям, выписали фичи.

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

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

Проблема в том, что у нас появляется зависимость, которая все ломает, — Single Point of Failure, единая точка отказа. От такого нужно избавляться, это правда. Но есть вещи, от которых мы избавиться не можем, например авторизация.

Важно, что текущая реальность ИТ-решений — огромное число взаимосвязей и это особенно заметно в больших компаниях. Такие связи неизбежны: микросервисы постоянно общаются друг с другом, взаимодействуют с базами данных или брокерами сообщений. А веб интерфейсы состоят из микрофронтов, которые завязаны на BFF или вообще рендерятся на основе ответа от сервера (backend driven UI). 

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

Сделали ряд допущений

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

Важно разделять, где наш бизнес-домен, а где реальный код и кто за него отвечает. Такой подход не идеален, кто-то даже может назвать его опасным, но именно так мы и поступили. Мы знали, что придется довериться коллегам и поверить, что они будут  сами качественно себя мониторить и что некоторые хитрые проблемы на сети мы можем пропустить.

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

Мы отказались от мониторинга интеграций, потому что он добавлял лишний шум. Система мониторинга заметно упростилась: из 80 фич, которые надо было замониторить, осталось только 40. Но это все еще довольно много. 

Мы не пришли к успеху

Пришли ли мы к успеху и действительно ли это бизнес-мониторинг? Оказывается, нет. После того как мы настроили все индикаторы и начали следить за аптаймом всех этих фич, мы поняли, что одни фичи без других просто бесполезны. Например, когда клиент отправляет сообщение, мы видим, что ответить ему никто не может, он пишет в пустоту. Тогда зачем нам смотреть только за отправкой сообщения, если нам важен полный путь? 

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

Мы замониторили самое важное: из 40 фич осталось 6. Выбрали сервисы и микросервисы, которые для нас интереснее всего. Определили, какие там будут метрики, kafka latency, рейт ошибок от сервера, время ответа серверов и так далее. 

Оставалось все еще довольно много индикаторов. Видно, что от 40 фич мы перешли к 20—30 индикаторам. Уже лучше, но все еще не то. Мы пожили с таким мониторингом какое-то время.

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

Как итог, число инцидентов стало почти нулевым, но цифры в отчете доступности говорили о том, что у нас еще очень много работы. Хоть крупные сбои и ушли, но все равно еще что-то подшумливало и цифры показывали не то, что мы ощущаем. А ощущали мы, что у нас уже где-то две-три девятки, так как жалобы от наших клиентов перестали к нам приходить, да и сотрудники уже стали забывать, что у нас могут быть какие-то проблемы, а в отчете все еще 94%.

Ожидания бизнеса от нашего продукта

Глобально, как компания, мы предоставляем обслуживание для клиентов. Обслуживание делится на несколько частей: каналы (чат или звонки), CRM для оператора, маршрутизацию и так далее.

Мы рассматриваем ситуацию на примере чата. Обслуживание в чате должно работать — звучит емко, но не дает конкретики. Как понять, что оно работает?

Можем ввести метрику или индикатор доставки сообщения. Клиент пишет сообщение, и оно должно быть доставлено до оператора, скажем, за минуту. Тогда мы будем понимать, что чат работает? А что, если сейчас глубокая ночь, суббота или воскресенье и операторов нет? Получается сбой, раз мы не смогли доставить сообщение клиента до оператора за минуту? Надо разбудить дежурного, чтобы чинил?

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

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

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

Доступность против аптайма

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

У нас есть технический мониторинг, он предотвращает сбои, срабатывает по ранним отклонениям. Его пользователи — инженеры, а показатели — время, за которое отвечает HTTP-сервер, latency ответа и так далее. 

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

Разберем на примерах отличия доступности от аптайма, технического мониторинга от бизнесового. 

Доступность систем

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

Если наши клиенты делают запросы с применением ретраев, доступность для них будет 100%. Они один раз получили 5хх, потом сходили в другой сервер, получили 200 и задачу свою закрыли. Тайминги стали чуть хуже, но в целом потребность закрыта. 

При этом аптайм в зависимости от того, как его считать, будет 0—75%, потому что запросов станет чуть больше из-за ретраев. Если посчитаем соотношение ошибок к 200, получится 75%. Если посчитать по количеству недоступных бэкендов, получится 66%-я доступность. А если посчитать, что хотя бы один бэкенд выпал, тогда говорим, что у нас проблема и будет нулевой аптайм.

Можем взять пример с Apache Kafka. У нас есть топик и три консьюмера, каждый читает свою партицию, и вдруг одна лочится. Например, там «битое» событие, которое мы не можем обработать, так как в нем пропало обязательное поле. Например, такое можно сделать при отключенной проверке на обратную совместимость avro-схем. 

Тогда аптайм у нас будет примерно 0—66% в зависимости от того, как мы его посчитаем: по количеству недоступных консьюмеров или что хотя бы один консьюмер недоступен. При этом доступность для клиента будет 66%, потому что 2/3 всех событий обрабатываются корректно и в установленный срок.

Еще один пример, чуть более интересный, когда доступность — 0%, а аптайм — 100%.

Есть сервер, у которого клиент что-то запрашивает и ждет всего секунду: такой у него таймаут на клиенте. Сервер доступен, но отвечает все время за три секунды. Он считает себя доступным, его все устраивает. Но для клиента доступность нулевая при серверном аптайме 100%.

Пример иллюстрирует, что доступность надо считать поближе к клиенту, а не на сервере. Но, если мы будем вот так измерять доступность, это еще не бизнес-мониторинг, к сожалению. Но это уже доступность систем.

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

Доступность продукта

Для измерения доступности продукта нам нужно сделать zoom-out и посмотреть на всю систему и весь продукт так же, как мы смотрим на один ее узел. Тогда мы сможем ответить на вопрос: «А как воспринимает нашу доступность конечный пользователь?» 

Мы говорим, что мерить доступность продукта надо ближе к клиенту. Но тогда может показаться, что это всегда какой-то frontend и что если его нет, то и доступность невозможно измерить. Это не так. Клиентом продукта может быть как физический пользователь, так и другой бэкенд. При таком подходе, когда мы их не разделяем мерить надо именно End-to-End-закрытие его потребности и не важно кто он – другой сервер или живой человек.

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

Услуги бывают двух типов: локальные и интегральные. Наш кейс про обслуживание мы декомпозировали до «Обслуживания в чате»  — это локальная услуга. 

Интегральная услуга — когда бизнес предоставляет «Обслуживание» целиком и эта услуга состоит не только из чата, но есть и другие каналы: звонки, e-mail, CRM для оператора, маршрутизация и так далее.

Обработка длительных операций

А теперь задача со звездочкой: как измерять доступность при асинхронной обработке событий, когда выполнение клиентского запроса может занимать длительное время? Например, одобрение кредита или выпуск пластиковой карты?

В примере нашего продукта такая ситуация — это очередь в чате. Клиент может написать обращение в пятницу вечером по тематике, которая обрабатывается только в будни с 09 до 18:00. Значит, клиенту не ответят до утра понедельника, и для этой тематики это нормально, нет проблемы, что мы не ответили за выходные. А еще клиент может написать в 13:00 в понедельник, и его обращение будет обработано довольно быстро, в этот же час или в этот же день. Получается, мы можем универсально определить бакет (размер временного отрезка), за который у нас выполняются пользовательские запросы, но он будет очень большой — несколько суток. 

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

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

По сути, база операций, как результат своей работы, выдает нам Success Rate — процента успеха получения конечной ценности пользователями.

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

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

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

С чего начать строить бизнес-мониторинг

Чтобы приблизиться к пониманию того, что должно быть в бизнес-мониторинге продукта, нужно ответить на один простой, казалось бы, вопрос: «Зачем продукт нужен пользователям?»

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

Услуга как раз и есть эта ценность, та суть, которую необходимо уметь чувствовать как пульс продукта: могут ли ее получать и с каким результатом.

Залетайте в комментарии, если остались вопросы или хотите поделиться, как в ваших командах строят мониторинг доступности.