Sla

Направление Site Reliability Engineering становится всё более популярным. Хайп не на пустом месте: проблемы и задачи, которые решает SRE, действительно насущны для многих компаний.

Популярность SRE растёт, но знаний о нём всё ещё недостаточно. Я не буду повторять формальные определения, а вместо этого расскажу несколько историй из жизни системного инженера Лёхи. Путь выдуманного Лёхи во многом похож на путь, который прошли реальные крупные компании, где впервые и возникли SRE-инженеры (даже если назывались иначе).

Через историю Лёхи вы узнаете о задачах, которые решает SRE, и причинах, по которым для решения этих задач пришлось выделять отдельный класс инженеров.

Глава 1. Hope is not a strategy

Утро понедельника, инженеру эксплуатации Лёхе звонит разработчик Толя:

У нас проблема! Ошибки в сервисе Плутон.

Подробности будут?

Там какие-то проблемы при работе с внешними ресурсами. Надо срочно починить! У нас всё лежит в проде.

Хорошо, сейчас посмотрим.

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

Там потери у магистрального провайдера, часть запросов теряются.

Ну и? Когда починишь?

Эм, что? Это не у нас проблема, это у магистрального провайдера!

Ну значит, звони магистральному провайдеру, пусть срочно чинят!

Серьезно? Да им пофиг на нас. Могу позвонить в администрацию президента, толку и то больше будет

Ну тогда звони нашему провайдеру, пусть с магистральным разберётся, мы платим за сетевое соединение, всё должно быть доступно на 100%!

До перехода в эксплуатацию Лёха 3,5 года работал программистом. Он решил вспомнить прошлое и написал маленький патч для Плутона с возможностью автоматически выполнять retry в течение заданного времени.

А диалога про 100% доступность могло бы не состояться, если бы Толик понимал: рассчитывать, что хоть один сервис в мире (да что там в мире, в галактике!) имеет 100% доступность, глупо. Сколько бы ты ни платил денег, это недостижимо. В погоне за 100% доступностью можно растратить весь бюджет, но так и не достигнуть её. Куда лучше быть готовым к нестабильности и уметь с ней работать.

Леха понимает, что 100% доступность чего угодно невозможна, но он не разработчик, хоть у него и есть опыт работы разработчиком, это не его зона ответственности. Толик разрабатывает приложения и мог бы научить приложение работать стабильно в нестабильных условиях. Если приложение попадет в зону ответственности Лехи, то мы получим первого SRE.

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

Почему никто не стремится к 100% доступности? спросил Толя

100% доступность невозможна и бессмысленна. Надо исходить из предположения, что ошибки и сбои неизбежны, и также учитывать стабильность работы внешних компонентов, таких как браузер, мобильная ОС, сеть клиента, так как их надежность зачастую ниже даже 99%, и наши усилия будут незаметны для пользователя . Более того, предстоящие сбои надо учитывать при разработке и эксплуатации.

Оценивая доступность, говорят о девятках:

• две девятки 99%,

• три девятки 99,9%,

• четыре девятки 99,99%,

• пять девяток 99,999%.

Пять девяток это чуть больше 5 минут даунтайма в год, две девятки это 3,5 дня даунтайма.

Стремиться к повышению доступности нормально, однако чем ближе она к 100%, тем выше стоимость и техническая сложность сервиса. В какой-то момент происходит уменьшение ROI отдача инвестиций снижается.

Например, переход от двух девяток к трём уменьшает даунтайм на три с лишним дня в год. Заметный прогресс! А вот переход с четырёх девяток до пяти уменьшает даунтайм всего на 47 минут. Для бизнеса это может быть не критично. При этом затраты на повышение доступности могут превышать рост выручки.

При постановке целей учитывают также надёжность окружающих компонентов. Пользователь не заметит переход стабильности приложения от 99,99% к 99,999%, если стабильность его смартфона 99%. Грубо говоря, из 10 сбоев 8 будет приходится на сбои, связанные с работой смартфона, а не самого сервиса. Пользователь к этому привык, поэтому на один лишний раз в год не обратит внимания.

Глава 2. Нестабильность сохраняется

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

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

Сударь, а вы осведомлены, что у вас приложение работает из рук вон плохо? Я бы даже сказал, отвратительно.

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

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

Я сожалею, что вы не осведомлены о проблемах, но коль уж так, извольте слушать. Во время обеда с партнёром решил я рассказать ему про наш новый продукт Русь. А он в ответ: Да слышал я, и даже заходил поглядеть, но так и не дождался загрузки главной страницы. Я ринулся проверять и тут же сам убедился в его словах (лицо Ивана Эрнестовича изобразило отчаяние).

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

Я подожду.

Быстрый обзор системы мониторинга показал, что все показатели в рамках нормы. В частности, за последние 3 часа было всего ~ 1000 неуспешных запросов (неуспешными по мнению Лехи считаются только те запросы, на которые был получен 50x код ответа).

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

Сколько? И вы смеете называть это работает? Это недопустимый показатель!

Вы, как всегда, правы, Иван Эрнестович. 1000 неуспешных запросов звучит грустно. Но это всего 1.5% от общего количества запросов. А это, согласитесь, не так уж и плохо.

Действительно, 1.5% не так страшно, но все ж почему мы не смогли открыть приложение?

А вы, говорите, обедали? В таком случае, проблема может быть не с нашим приложением, а с мобильным интернетом или Wi-Fi в ресторане.

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

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

И прекратите пугать людей большими цифрами! Жду предложение по изменению системы мониторинга. Твоя идея с соотношением мне понравилась, надобно ее проработать.

С этими словами Иван Эрнестович удалился, а наш герой Лёха выдохнул, дооформил задачу по инциденту, передал данные ночному дежурному и тоже удалился.

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

Фактически Лёха создал то, что сейчас обязательно используется в рамках SRE подхода:

Целевые показатели: SLA, SLI, SLO

Чтобы в следующий раз Иван Эрнестович не был удивлён, узнав о 1,5% проваленных запросов, Лёха выбрал ключевые метрики, по которым можно отслеживать, насколько стабильно работает наш сервис. Также предложил сразу установить для данных метрик границы, при пересечении которых команда, отвечающая за сервис, понимает, что все стало плохо и пора сфокусироваться над стабильностью. И даже придумал название для таких метрик: соглашение о целевом уровне обслуживания Service-Level Objective (SLO).

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

В SLO закрепляют целевые показатели доступности, которые вырабатывают вместе с продакт-оунером. То есть Лёха может их предложить, но утвердить не может. Здесь нужно согласие всех лиц, принимающих решение.

Чтобы понимание было ясным, соглашение должно содержать конкретные числовые показатели Service Level Indicator (SLI). Это может быть время ответа, количество ошибок в процентном соотношении, пропускная способность, корректность ответа что угодно в зависимости от продукта.

SLO и SLI это внутренние соглашения, нужные для взаимодействия команды. Обязанности компании перед клиентами закрепляются в Service Level Agreement (SLA). Это соглашение описывает работоспособность всего сервиса и штрафы за превышение времени простоя или другие нарушения.

Примеры SLA: сервис доступен 99,95% времени в течение года; 99 критических тикетов техподдержки будет закрыто в течение трёх часов за квартал; 85% запросов получат ответы в течение 1,5 секунд каждый месяц.

Среднее время между сбоями и среднее время восстановления MTBF и MTTR

Чтобы избежать претензий, Лёха пошёл дальше сформулировал ещё два показателя: MTBF и MTTR.

MTBF (Mean Time Between Failures) среднее время между сбоями.

Показатель MTBF зависит от качества кода. То есть чем меньше будет косячить разработчик Толя, тем лучше будет показатель MTBF. Но поскольку каждый косяк Толи влияет на Лёху, у Лёхи должна быть возможность делать ревью кода и, в случае совсем уж очевидных проблем, говорить Нет!.

По крайней мере, это предполагает подход SRE. Он же предполагает понимание со стороны команды: когда SRE блокирует какой-то коммит, он делает это не из вредности, а потому, что иначе страдать будут все.

MTTR (Mean Time To Recovery) среднее время восстановления (сколько прошло от появления ошибки до отката к нормальной работе).

Показатель MTTR рассчитывается на основе SLO. Инженер по SRE влияет на него за счёт автоматизации. Например, в SLO прописан аптайм 99,99% на квартал, значит, у команды есть 13 минут даунтайма на 3 месяца. В таком случае время восстановления никак не может быть больше 13 минут, иначе за один инцидент весь бюджет на квартал будет исчерпан, SLO нарушено.

13 минут на реакцию это очень мало для человека, поэтому здесь нужна автоматизация. Что человек сделает за 7-8 минут, с тем скрипт справится за несколько секунд. При автоматизации процессов MTTR очень часто достигает секунд, иногда миллисекунд.

Бюджет на ошибки

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

Поэтому Лёха предложил ввести еще одно понятие бюджет ошибок. Это степень риска, которая допустима для данного сервиса, и ее можно прописать в SLO.

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

Если бюджет на ошибки содержит 43 минуты даунтайма в месяц, и 40 минут из них сервис уже лежал, то очевидно: чтобы оставаться в рамках SLO, надо сократить риски. Как вариант, остановить выпуск фич и сосредоточиться на баг-фиксах.

Если бюджет на ошибки не исчерпан, то у команды остаётся пространство для экспериментов.

Чтобы не выйти за рамки, Error budget делят на несколько частей в зависимости от задач. Каждая команда должна оставаться в пределах своего бюджета на ошибки.

Если это все будет внедрено, можно будет получить объективную картину, насколько стабильно работает наш сервис. Но остается одна серая зона: что делать, если бюджет на ошибки был исчерпан.

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

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

Глава 3. Post mortem

Придя в понедельник в офис, первым делом Лёха открыл результаты расследования инцидента. Увиденное не радовало. Небольшая цитата:

В период с 14-00 до 18-00 наблюдались проблемы с сервисом Русь. Они были связаны с тем, что сервис Плутон, от которого зависит наш сервис, переезжал в другой ДЦ и были потери пакетов. Написали служебку на запрет проведения работ в рабочее время для команды разработки и эксплуатации сервиса Плутон!

Лёха грустно вздохнул: от такого расследования проку мало, и принялся писать свой отчет для Ивана Эрнестовича.

Иван Эрнестович, наши отчеты об инцидентах, как и система мониторинга, деструктивны. Я подготовил собственный отчет, предлагаю данный вид документа сделать стандартным и назвать его, допустим, post-mortem. Цель этого документа не найти виноватых, а понять, в каких процессах есть проблемы и как можно их улучшить!

Что и когда произошло

16.10. 2015 19.45 поступила жалоба от Генерального директора о недоступности сервиса Русь, примерно в 16 часов.

16.10. 2015 19.55 Инженер по эксплуатации Анатолий по данным системы мониторинга зафиксировал 1000 неудачных запросов в период с 14 до 17 часов. В момент поступления жалобы инцидент уже был разрешен.

Причины и факторы

Нетехническая причина:

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

Техническая причина:

Отсутствие механизма повтора запросов у сервиса Русь.

Обнаружение

Жалоба генерального директора.

Решение

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

Что прошло хорошо

В системе мониторинга присутствовали все необходимые графики.

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

Что можно улучшить

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

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

Внедрить метрики на основе соотношения успешных и неуспешных запросов.

Где нам повезло

Количество неуспешных запросов было 1.5%, и большинство пользователей не заметили проблему.

Задачи

RUS-347 доработка системы мониторинга. Добавление метрик соотношения неуспешных запросов к общему числу запросов.

RUS-354 разработка библиотеки для реализации механизма повтора неуспешных запросов.

Лёха сложил два документа в одно письмо и отправил их курьером Ивану Эрнестовичу, так как тот больше любил бумажные письма.

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

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

P. S. история может показаться утрированной, таковой она и является. Примерно такой путь прошли компании, которые придумали SRE.

Так чем же будет заниматься инженер по SRE Лёха

1. Формировать целевые показатели надёжности системы и поддерживать их.

2. Проверять и оптимизировать код, опираясь на знания о надёжности системы.

3. Анализировать возникающие ошибки. Делать выводы, писать скрипты автоматизации для разрешения проблем.

И это только малая часть обязанностей SRE-инженера. Если вам интересны подробности, то прочтите обзорную статью по SRE от Слёрма (выдержки из неё вошли в этот текст). В конце обзорной статьи вы найдёте ещё массу полезных ссылок.

А если есть желание попробовать свои силы на практике, то приходите на интенсив. Там будет много практических кейсов и практикующие SRE-инженеры из крупнейших ИТ-компаний мира.

Узнать подробности и записаться

Автор статьи: Владимир Гурьянов архитекторрешений Southbridge, Certified Kubernetes Administrator.

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

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

Идеальная метрика

Впервые я с этим столкнулся в самом начале своей карьеры. Тогда я работал сетевым инженером в региональном операторе связи, и в мои обязанности входила обработка метрик из системы мониторинга для подготовки KPI-отчета по техническому блоку. За основу брались данные о том, пингуется или нет узел связи (без привязки количества абонентов, которые от него зависят). Но в жизни качество предоставляемых провайдером услуг измеряется далеко не прохождением ICMP-пакетов от сервера мониторинга до коммутатора в подъезде, тем более, когда эти коммутаторы находятся в своем стерильном VLAN-е. Этого, наверное, не знали, но смогли прочувствовать на себе абоненты, особенно, нового в то время сервиса: IPTV через multicast. Зависающие картинки на телевизорах абонентов никак не коррелировали с прекрасной зеленой картинкой, подаваемой на стол руководства, и премиальным фондом. Результатом стала проваленная маркетинговая кампания по продвижению IPTV и немного пошатнувшаяся репутация. А дальше по цепочке: пересмотр KPI для инженеров с включением в него кучи новых метрик (в том числе и с бизнес уклоном), весовых коэффициентов, которые было просто невозможно рассчитать, и на которые было сложно повлиять. И вишенка на торте: восприятие сотрудниками KPI в качестве репрессивного инструмента сокращения зарплаты, и полная неэффективность его регуляторной функции. Я думаю, что у вас будет много подобных примеров из практики, особенно если коснуться такой острой темы как KPI и SLA. Вообще тема KPI, особенно в IT, заслуживает отдельного остросюжетного романа.

Я вспомнил описанную выше историю, когда практически одновременно несколько корпоративных заказчиков обратились с проблемой непрозрачного расчета SLA и KPI своих ИТ-подразделений. Стоит пояснить, что сейчас я работаю над продуктом зонтичного мониторинга для оперативного обнаружения и устранения сбоев в ИТ нашим продуктом пользуется ряд очень крупных клиентов из разных сфер: от госуправления и финтеха до СМИ и авиакомпаний.

Памятуя о своем неудачном опыте на первом месте работы, я не очень хотел ввязываться в KPI и SLA. Вначале я предложил решить эту проблему через настройку соответствующих Service Desk, тем более так рекомендует нам ITSM (Service Desk - единая точка входа и агрегации всей информации об услугах), а мой продукт будет лишь продолжать регистрировать инциденты и помогать с их дедупликацией за счет определения массовых сбоев и понимания: относится ли новый алерт к проблеме, находящейся на контроле у инженеров, или нет. Но коллегам хотелось не отчетности и репрессивного контроля, как я изначально ошибочно предположил, - им хотелось инструмента управления, который бы помогал и бизнесу, и инженерам находить некий общий язык и добавлял бы прозрачности в их отношения.

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

1. Бизнес-ориентация. Метрика должна отражать работу нашего ИТ-окружения не с позиции работоспособности какого-либо сервера, а с позиции того, насколько это важно нашим клиентам;

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

3. Декомпозируемость. По результатам можно провести анализ, разложить нашу единую синтетическую метрику на компоненты/факторы и выделить наиболее критический. В идеальном случае на выходе получить root cause анализ.

В итоге было предложено два варианта реализации: 1) метрика доступности сервиса/объекта (Service Availability); 2) карта здоровья (Health Map). Карта здоровья в итоге оказалась более сложной как в реализации, так и в аналитическом сопровождении, и была определена как перспективная целевая схема, и на время ее доработки был выбран более простой и привычный подход с оценкой доступности сервиса, о котором и пойдет дальше речь.

Доступность сервиса - это про бизнес, но и про ИТ

Итак, что же такое доступность сервиса? Я сформулировал для себя следующее определение: Доступность сервиса (англ. Service Availability)- это такое состояние нашего ИТ-окружения, когда наши клиенты могут и хотят получить услугу и остаться в целом удовлетворенными. Стоит также подчеркнуть, что здесь может быть только два состояния: либо условия выполняются, либо нет. Все полутона только смазывают картинку. Никакой деградации, никакой сниженной производительности - все это технические показатели, необходимые исключительно инженерам для оценки динамики состояния системы.

Приведу пример: потенциальный клиент хочет подать онлайн-заявку на оформление кредита в банке, но система работает со сбоями. Из-за высокого времени ожидания ответа сервера форма постоянно сбрасывается или на ней возникают ошибки, но минут за 30 заявку можно подать. Это приводит к тому, что конверсия в воронке продаж резко падает. С позиции классического инженерного мониторинга это серьезная деградация, но услуга доступна, а вот с позиции бизнеса это неприемлемое состояние системы, когда он теряет потенциальных клиентов. В данном примере доступность сервиса должна считаться равной 0. Приведу обратный пример: у вас, в силу каких-то непредвиденных обстоятельств, полностью выключается целый ЦОД и ваши системы переходят на резервный, при этом клиенты в штатном режиме, правда, чуть дольше, чем обычно, но регистрируют заявки на кредит, и конверсия не падает. А тут мы говорим, что сервис доступен полностью и мы, как инженеры, молодцы - обеспечили горячее резервирование. Хотя при этом половина наших серверов и каналов связи находятся в коме и не доступны. Таким образом, определение доступности сервиса целиком находится на стороне бизнеса, а мы должны лишь зафиксировать в каком соответствующем состоянии должно находится наше ИТ-окружение. Можно поддаться искушению сделать все просто и повесить, например, метрику конверсии как KPI для ИТ-департамента, забывая при этом, что ИТ не про конверсию, его нормальная работа - необходимое, но недостаточное условие для продвижения клиентов по воронке продаж. Поэтому использование бизнес-метрики в лоб приведет к непониманию и отторжению инженерного состава. К сожалению, этому искушению простоты очень часто поддаются руководители и в результате получают прямо противоположный эффект.

Особенности реализации

Необходимо сразу пояснить, что в нашей системе зонтичного мониторинга мы зачастую имеем дело не с метриками, а с уже конкретными событиями, алертами, возникшими в различных системах мониторинга. Эти алерты мы распределяем по конфигурационным единицам (сервисы, сервера, виртуальные машины, кластеры и т.д., далее - КЕ) в ресурсно-сервисной модели. Также, в зависимости от пришедших событий, мы изменяем статус синтетических триггеров (синтетические - потому что могут рассчитываться на основании алертов из разных систем мониторинга, далее СТ). По сути синтетический триггер - это аналог аварийной ситуации / бизнес-проблемы, у которой есть начало и конец.

В нашей системе мы позволяем рассчитывать доступность, как отдельной КЕ, так и совокупную доступность группы КЕ. Метрика доступности для группы КЕ - это и есть искомая верхнеуровневая метрика доступности конечного сервиса, потому что сервис зачастую оказывается целым комплексом информационных систем и, в целом, представляет цепочку более мелких сервисов (ЦОД отвечает за сервис предоставления виртуальных машин, Облако за сервис системных компонентов, Информационная систем за прикладные сервисы и так далее). А доступность отдельной КЕ - это оценка работоспособности того или иного объекта с позиции оказания конечного сервиса. Взаимоувязка позволяет в дальнейшем проводить факторный анализ и определять вклад каждого объекта в общий результат, таким образом, находить узкое горлышко.

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

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

• Есть ли у нас RTO (recovery time objective) - максимально допустимое время, в течение которого наш объект может находиться в аварийном состоянии;

• Учитываем или нет согласованные сервисные окна.

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

Собственно методика

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

Для расчета доступности за период SA (Service Availability) необходимо построить функцию проблемного состояния КЕ от времени fProblem(t), которая в каждый момент времени принимает одно из четырех значений:

• Значение (0) говорит о том, что в конкретный момент времени на КЕ не зафиксированы проблемы, отвечающие фильтру;

• Значение (1) - в конкретный момент времени на КЕ зафиксирована проблема (-ы), подпадающая под условия;

• Значение (N), что КЕ находится в необслуживаемом состоянии;

• Значение (S), что КЕ находится в согласованном сервисном режиме.

В результате мы получим следующие показатели:

• timeNonWorking - нерабочее время КЕ на исследуемом периоде. Значение функции равно "N";

• timeWorkingProblem - время нахождения КЕ в не удовлетворяющим SLA состоянии на исследуемом промежутке времени. Значение функции равно "1";

• timeWorkingService - время согласованного простоя, когда, в рабочее время, КЕ находилась в сервисном режиме. Значение функции равно "S";

• timeWorkingOK - время, в которое наша КЕ удовлетворяла SLA. Функция fProblem(t) находилась в состоянии "0".

Расчет доступности за период для одиночной КЕ SA (Service Availability) осуществляется по формуле:

SA =timeWorkingOK / (timeWorkingOK+timeWorkingProblem) * 100%

Для группового расчета доступности за период SAG (Service Availability Group) необходимо построить функцию проблемного состояния КЕ от времени fProblem(t) для каждой КЕ, входящей в группу. Далее наложить получившиеся функции fProblem(t) по каждой КЕ друг на друга, исходя из определенных правил (см. Табл. 1)

ТАБЛИЦА 1.

В результате получаем функцию fGroupProblem(t). Суммируем длительность участков данной функции следующим образом:

• timeGroupService - время, когда fGroupProblem(t)= S;

• timeGroupOK - время, когда fGroupProblem(t) = 0;

• timeGroupProblem - время, когда fGroupProblem(t) = 1;

Таким образом, искомая метрика:

SAG = timeGroupOK / (timeGroupOK+timeGroupProblem) * 100%

Факторный анализ

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

Факторный анализ позволяет определить: какой фактор-проблема повлиял за отчетный период на расчет доступности и сравнить степень такого влияния с остальным факторами-проблемами.

Предположения методики:

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

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

Методика расчета:

1. Необходимо взять функцию fProblem(t), построенную при расчете SA.

2. Для каждого участка, где итоговая функция fProblem(t) = 1, составить список проблем данной КЕ, на основании которых данному участку было присвоено значение. При составлении списка необходимо учитывать и проблемы, которые начинались или заканчивались за пределами участка функции.

3. Проставить проблеме метрику влияния. Она равняется длительности проблемы на участке умноженную на вес. В случае, если на участке в области свой длительности проблема была единственная, то ей устанавливается вес, равный 1, в случае множественных проблем вес равен 1/N, где N - количество одновременно произошедших проблем.

4. При расчете следует учесть следующие моменты:

   1. В общем случае на одном и том же участке на разных интервалах вес проблемы мог меняться из-за появления новых проблем.

   2. Одна и та же проблема может присутствовать на разных участках fProblem(t) = 1. Например, проблема началась в пятницу, закончилась во вторник, а в выходные КЕ не обслуживается согласно SLA.

5. В итоге должен быть сформирован список проблем, которые участвовали в расчете функции fProblem(t). При этом у каждой проблемы должна быть посчитана метрика влияния на SA.

6. Необходимо обязательно верифицировать расчет. Сумма метрик влияния всех проблем должна равняться timeWorkingProblem.

7. Пользователю необходимо выводить относительное значение влияния в %. Для этого метрику влияния необходимо разделить на timeWorkingProblem и умножить на 100%.

8. В случае, если нужно группировать проблемы и показывать влияние группы, достаточно суммировать метрики всех входящих в группу проблем. Это утверждение справедливо, только если выполняется следующее условие: каждая проблема может одновременно входить только в одну группу.

В результате получаем вот такую картину (см. рис 4.)

Промежуточные итоги

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

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

В любом случае, это не последняя наша попытка найти Святой Грааль - идеальную метрику и метод ее расчета, чтобы помочь нашим клиентам не превратить свое ИТ-окружение в тот самый арбуз. Следующая наша ставка на Карту здоровья. Надеюсь в дальнейшем продолжить делиться с вами полученными результатами.

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

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

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

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

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

Можно ли с этим что-то сделать? Конечно! Работающие и очень эффективные меры давно известны это Бережливое производство (Lean Manufacturing) и Теория ограничений (Theory of Constraints, TOC).

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

Небольшой экскурс в Lean и TOC

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

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

Теория ограничений это как бы надстройка над Бережливым производством, которая гласит, что в любом производстве есть всего лишь одно единственное узкое место, которое тормозит всё. И скорость всего предприятия в целом равно скорости этого узкого места (бутылочного горлышка).

Бесполезно расширять что-либо еще, кроме бутылочного горлышка это всё равно ни к чему не приведёт. Именно поэтому локальные оптимизации не работают. И именно поэтому нет смысла утилизировать мощности отделов на 100% - это только вызовет перепроизводство.

А вот увеличение производительности горлышка на X% приведет к увеличению прибыли всего предприятия на X%. А это миллионы, а может и миллиарды!

Это если кратко.

Единственная, но очень важная метрика теории ограничений

В Теории ограничений есть, по сути, единственная метрика, на основе которой принимаются все решения это Проход (или Проток, Throughput).

T_u=P TVC,

где T_u величина прохода на единицу продукции;
P цена единицы продукции;
TVC полностью переменные затраты

(https://tocpeople.com/2012/08/upravlenie-predpriyatiem-po-finansovym-pokazatelyam-tos/)

Если грубо, то это операционная прибыль, заложенная в конкретную единицу продукта.

Как это можно использовать?

Давайте рассмотрим известный пример с двумя продуктами. Пусть человек-бутылочное горлышко принимает участие в производстве продуктов А и Б.

Продукт А стоит 300 руб, а продукт Б 400 руб.

При этом Проход (грубо - Прибыль) продукта А = 100 руб, а у продукта Б = 200 руб

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

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

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

Время производства продукта А 5 мин, продукта Б 30 мин.

Продукт А: 100 руб / 5 мин = 20 руб / мин

Продукт Б: 200 руб / 30 мин = 6,6 руб / мин

Получается, что при изготовлении продукта А компания получает прибыль в 20 руб/мин, а при изготовлении продукта Б всего 6,6 руб/мин.

Выбор очевиден, не правда ли? Нужно производить как можно больше продукта А, а в оставшееся время продукт Б.

Переложение метрики Прохода для технической поддержки

Самое главное сомнение, которое у Вас скорее всего возникнет в тех поддержке нет прибыли. Совершенно верно.

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

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

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

Из Jira, например, можно извлечь следующие данные:

Приоритетзадачи

Категория задачи

Общее время исполнения(от регистрации до перевода в статус Resolved) с учетом всех дней и выходных. Время исполнения с точки зрения клиента от самого начала до самого конца.

Дополнительно можно вычислить Touch time - время ручной работы админа по каждой задаче. Другими словами время, затраченное администратором на задачу за вычетом выходных, нерабочего времени и нахождения задачи в статусе Need Info (запрос доп информации от клиента).

Если на человеке висело несколько параллельных задач, то Touch time вычисляется по каждой завершенной задаче отдельно, а затем берется 85% персентиль от всего полученного множества.

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

В Jira значение Touch time можно вычислить как время между сменами статусов.

Время работы человека-горлышка (или время, затраченное на производства продукта) = Touch time

Проход = количество выполненных задач конкретной категории и приоритета

К прохода = Прибыль / Время работы горлышка

или

К прохода = количество выполненных горлышком задач / Touch time

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

Вот реальный пример из службы тех поддержки:

Колонка template Категория задач. Строки упорядочены по убыванию коэффициента прохода.

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

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

Почитайте интересную статью про технологию Swarming в которой есть много подобных нестандартных выводов.

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

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

Поиск бутылочного горлышка техподдержки

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

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

Эффективность потока = Суммарное время создания ценности / Общее время цикла * 100%

Часто эффективность потока в компаниях не превышает 5-10%.

Каким образом посчитать эффективность потока для задач тех поддержки?

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

Можно использовать метод проще и считать по количеству выполненных задач за период:

Эффективность потока = Кол-во выполненных задач / (Всего задач в работе) * 100%

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

Вот примеры с реальными данными:

Можно отфильтровать данные по наименее эффективным группам и получить эффективность входящих в них админов.

Что обозначает эффективность потока в тех поддержке?

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

Вот пример реальной ситуации по настоящему, не выдуманному админу:

Как видите, ситуация жесткая он делает всего 4-5 задач в день, а вешают на него аж по 10 штук.

Естественно, о какой эффективности тут может идти речь.

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

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

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

Т.е. метрики бережливого производства действительно могут помочь с налаживанием дел в технической поддержки.

Что делать со всеми этими метриками?

Улучшать, конечно. С помощью Kaizen непрерывного совершенствования. В низкой эффективность виноваты не люди виновата система. И её надо перестраивать.

Т.е. нужно находить корневую причину проблемы (истинную причину, а не лежащую на поверхности) и устранять её. И так поступать с каждой проблемой.

Вот хороший пример как в Службе Service Desk использовали Lean (бережливый подход) и что из этого получилось.

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

Зуб даю, что первое, что Вы увидите в тех поддержке - это то, что админы (/сотрудники тех поддержки) делают по десятку задач одновременно (см. график выше). Вы наверняка на себе испытали как это работает:

Клиент оставляет обращение, оно назначается на админа, а тот быстро-быстро что-то отвечает и мгновенно переводит задачу обратно с целью получения доп информации, либо переводит задачу на какого-то другого человека. И всё потому, что ему некогда ждать пока клиент ответит ему нужно сделать сегодня еще кучу задач.

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

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

При однозадачности задачи выполняются в разы быстрее, чем при многозадачности:

Решить проблему можно. Теория ограничений для этого случая говорит:

Расширьте бутылочное горлышко

Подчините ему всё производство

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

Простая перестройка процесса позволит админу выполнять только одну задачу за раз. Это может увеличить его производительность в разы:

Вариантов решений множество.

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

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

А на этом всё.

NB. Все выводы в этой статье сделаны на основе наблюдений за реальным отделом технической поддержки большой компании.

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

Ваши комментарии он с удовольствием прочитает и ответит на них.

Сегодня мы хотим обсудить практическую сторону внедрения концепций Service Level Objectives и Service Level Indicators. Рассмотреть, что входит в понятия SLI, SLO и Error budget, как рассчитывать эти показатели, как за 7 шагов внедрить их отслеживание и как в последствии контролировать эти показатели на примере инструмента Instana.

Определимся с терминологией

Service Level Indicator (SLI) это количественная оценка работы сервиса, как правило, связанная с удовлетворенностью пользователей производительностью приложения или сервиса за заданный период времени (месяц, квартал, год). А если говорить конкретнее это индикатор пользовательского опыта, который отслеживает одну из многочисленных возможных метрик (рассмотрим их ниже) и, чаще всего, представляется в процентном эквиваленте, где 100 % - означает отличный пользовательский опыт, а 0% - ужасный.

Service Level Objectives (SLO) это желаемое, целевое значение нашего SLI или группы SLI. При установке SLO необходимо указывать реально достижимое значение для каждого конкретного SLI. Ниже мы рассмотрим логику установки SLO на примере конкретных SLI.

Также важно понимать, что SLO это наш внутренний показатель качества работы сервиса и/или приложения, в отличие от Service Level Agreement (SLA), который обычно устанавливается бизнесом как внешнее обязательство по доступности сервиса перед клиентами компании.

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

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

Использование данного показателя упрощает командам процесс контроля времени недоступности приложений/сервисов посредством ввода наглядного индикатора. Устанавливая ErrorBudget, мы ставим для себя цель не выйти за рамки разрешенного нам самим downtime.

Например, если в качестве SLI для одного из наших приложений у нас указана метрика Availability, а в качестве SLO для этого SLI мы указали значение 99,95% в месяц, то наш ErrorBudget за месяц (30 дней) составит 21 минуту 54 секунды. Конкретную цифру ErrorBudget можно не рассчитывать самостоятельно, а воспользоваться готовым калькулятором.

Для анализа текущего положения дел с ErrorBudget с учетом установленного SLO/SLA и среднего показателя Availability на момент расчета, можно использовать вот такой калькулятор.

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

7 последовательных шагов по имплементации SLO

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

2. Для выбранных сервисов определяем набор метрик, которые войдут в наш SLI.
   
   Чаще всего в SLI включают метрики, непосредственно связанные с пользовательским опытом, доступностью и производительностью, такие как время исполнения транзакций, время отклика, процент ошибок, доступность.

3. Определяем текущее распределение значений выбранных метрик.
   
   Если вы используете промышленное APM решение, то скорей всего вам уже доступно определение baseline метрик. Например, мы видим, что у транзакции чекаута время исполнения по 90-му перцентилю равняется 110 мс за последние две недели.

4. Определяем SLO, учитывая нормальное поведение выбранных метрик или данных по baseline и устанавливаем Error Budget.

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

   Например, можно установить порог 110 мс по 90-му перцентилю и SLO в 95%. Это будет означать, что мы допускаем 5% времени, в которое время исполнения транзакции по 90-му перцентилю будет выше 110 мс.

5. Прописываем процедуру действий на случай истощения Error Budget

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

   1. Оповещение при превышении Error Budget

   2. Повышение приоритета для команд разработки и DevOps у работ по восстановлению доступности сервиса перед работами по выкатке новых фич на определенный период времени.

   3. Lessons learned, post mortem и другие документы фиксация причин превышения Error Budget в каждом конкретном случае в базу знаний и работа над ошибками.

6. Отслеживаем выполнение установленных нами SLO для соответствующих SLIs во времени.

7. Оцениваем результаты внедрения SLI SLO, как и с любым процессом, следующим логике Plan-Do-Check-Act. Лучше начать с небольшого количества SLO, определить достижимые цели, научиться отслеживать показатели и проводить улучшения постепенно.

А теперь давайте посмотрим, как концепция SLI SLO реализована в инструменте Instana.

Реализация концепции SLO и SLI в Instana

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

ВInstanaопределитьпутипользователяпоприложениюможно с помощьюфункцииApplicationPerspective.Подробнее отом,какещеиспользоватьApplicationPerspective, можно прочитать в нашем посте-Observabilityсистема для микросервисов на примереInstana, часть 1

Для созданияApplicationPerspective перейдем винтерфейсеInstanaкразделуApplication,кликнемнаNewApplicationPerspective.

Впоявившемся окне будутпредложены вариантыApplicationPerspective. Выбрав acriticaluserjourney, мыукажем, какие сервисы иэндпоинтывходятв путь пользователя.А если говоритьпроще то мы определили какие сервисы иэндпоинтывходятв одну из бизнес-транзакций, по которойнеобходимоопределитьSLO.

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

Конфигурация SLI

Создадим новыйкастомныйдашборд.

На которомдобавим SLO виджети выберем созданноеранееApplicationPerspective.

КликнувнаManageSLIперейдемк списку всех доступных индикаторов для выбранногоApplicationPerspective.

ВыбравCreateSLI,мы перейдемксозданиюSLI.

Для создания индикатора:

1. Укажем имя индикатора.

2. Определим тип индикатора:Time-BasedилиEvent-Based.

3. Определимграницыдлявызовов:InboundCallsилиAllCalls.

   1. Inboundcalls:ВсевходящиевызовыврамкахсервисоввходящихвApplicationPerspective.

   2. Allcalls:ВсевходящиевызовыврамкахApplicationPerspectiveиисходящиевызовыизApplication Perspective.

4. Укажем необходимую конфигурацию в зависимости отвыбранноготипа индикатора.

5. СохранимSLIкликнув наCreate.

Time Based SLI

Time-Based индикаторосновываетсяназначенияхвыбраннойметрики (временного ряда). Среди доступных метрик:

• Latency времяисполнения вызовов;

• CallCount количество вызовов;

• Error Rate процент ошибок;

• ErroneousCallsколичество вызовов,содержащихошибку.

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

В процессе установки SLI мы:

• Определяем область действия этого индикатора - можем выбратькакконкретный сервис,так и использоваться все сервисы входящие вApplicationPerspective. Для более детального определения можем указать конкретныйэндпоинтсервиса.

• Выбираемметрику,которая войдет вSLI. Этоможетбыть-Latency, CallCount, ErrorRate, ErroneousCalls.

• Определяем, как будем агрегировать значение метрики: по перцентилям (90, 50, 99ит.д.), по среднему значению, по минимальному или максимальному значению.

• Определяем пороговое значение метрики.

После того, как мы указали метрику и ее пороговое значение,SLIрассчитаетсяпо формуле:

SLI = (1 - #minutes_where_threshold_is_violated / #minutes_in_time_window) * 100%

Посмотрим на примернастройки Time-Basedиндикатора.

Все вызовы сервисаproto.groupдолжныисполнятьсяв среднем не более чем за 25мс.

Event-Based SLI

Event-Based индикатор основывается на хороших и плохих событиях.

Хорошие события- этонабор вызовов, которые указывают на положительное качество работы сервиса, например, 2ххHTTPстатус коды.

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

В ходе настройки Event-Based SLI мы:

• С помощью фильтров определим, какие вызовы указывают наположительное качество работы сервиса;

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

SLIв таком случае рассчитывается по формуле:

SLI= #good_events/ (#good_events+ #bad_events) * 100%

Рассмотрим примернастройки Event-Basedиндикатора.

Мы определили, что хорошие события это все вызовы с 2ххHTTPстатус кодом, а плохие - все вызовы с 5ххHTTPстатус кодом.

SLO отчет

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

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

SLOрассматриваем за выбранный промежуток времени 24часа,и намдоступно72 минуты на простой нашего сервиса(ErrorBudget).Надашбордевышемы видим,чтоSLOнарушался 116минутза выбранный промежуток времени, нашErrorBudgetпревышенна44минуты.

Еще пример SLO отчета для Event-Based SLI:

КонфигурацияSLOвиджета

В этом разделе мы расскажем, как создатьSLOWidgetдля любогоApplicationPerspective.

Перейдемна свойкастомныйдашборди добавимSLO виджет, просто кликнув на AddWidget:

В открывшемся окне перейдем на вкладкуSLO и для настройки сделаем следующее:

1. Укажем имя виджета.

2. ВыберемApplicationPerspective/критически важный пользовательскийпуть,по которому нужно задатьSLO

3. Выберем заранее созданный целевой индикаторSLIдля выбранногоApplicationPerspective.

4. Определим цельSLOкоторую нужно достичь

5. Выберемвременной период,за которыйбудетрассчитыватьсяSLO:

   1. DynamictimewindowSLOбудет рассчитываться за период, который указан в таймпикере. Таймпикердоступен в правом верхнем углу интерфейсаInstana,в неммывыбираемпериод времени,закоторый будут отображаться данные.
      

      

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

   3. FixedtimeintervalSLOбудетрассчитываться за фиксированный период времени с определенной датой начала и длительностью. Например, ежемесячно начиная с2020-01-01.

6. Убедимся, что мы заполнили все необходимые поля конфигурации.Нажав на Highlightmissingconfiguration нам подсветятся все не заполненные поля.

7. Сохраним виджет, нажав на Create

Итоги

Мы настроили SLI и SLO для сервисов, начали с выбора критичного пути пользователя по сайту, определили какие метрики использовать для SLI, указали error budget и настроили виджет, визуализирующий текущий статус SLO. Метрики приложений мы собрали автоматически, путем установки агента, реализующего инструментацию приложений - метрики не потребовалось описывать вручную.

Подробнее про основные возможности observability системы Instana можно почитать в нашем обзоре продукта.

Также приглашаем на наш вебинар, посвященный использованию Instana для мониторинга Kubernetes и снижения MTTR.

Количество самого разного оборудования во всём мире неуклонно растет. Не последнюю роль в этом играет развитие промышленного интернета вещей (Industrial Internet of Things, IIoT) и повсеместное проникновение умных устройств: датчиков, контроллеров и т. д. Согласно прогнозам уже к концу 2020 года количество умных устройств в мире превысит 200 миллиардов. Вся эта "армия" оборудования, несмотря на возможности удаленного управления, требует профилактического и выездного обслуживания (Field Service Management, FSM).

Расскажем об основных правилах повышения эффективности выездного обслуживания. Их 7.

Что такое Field Service Management? Особенности в двух словах

Field service management или "выездное обслуживание" - это подход и практики к управлению работой выездных инженеров или техников.

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

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

Малый и средний бизнес зачастую пытается использовать для решения задач управления выездным обслуживанием CRM или системы для автоматизации внутри внутренних процессов компании (ITIL или ITSM ориентированные). Но подобные решения не покрывают значительную часть вопросов. Без специализированных инструментов здесь обойтись сложно.

Field Service в России и мире. Обзор рынка

На западе вопросу эффективного выездного обслуживания давно уделяют пристальное внимание. В США FSM - это сформировавшаяся отрасль, где основная доля принадлежит крупным компаниям. Крупному бизнесу неизбежно приходится заботиться о решении вопросов с распределением задач между исполнителями и в целом о повышении эффективности своей работы. Поэтому они в первую очередь внедряют инструменты для управления выездным сервисом. Вслед за крупным бизнесом на такие решения переходят и небольшие компании.Так, согласно исследованиям и прогнозам Allied Market Research к 2026 году рынок выездного обслуживания увеличится более чем в 3 раза до 10,81 миллиарда долларов. При этом во всем мире, согласно отчёту Mordor Intelligence, количество выездных техников уже достигло 20 миллионов.

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

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

Возможно ли российским компаниям небольшими усилиями улучшить качество выездного обслуживания? Ниже 7 советов, которые помогут!

Фиксируйте 100% обращений

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

Качество обслуживания неразрывно связано с сохранением клиентской базы. По данным Teleperformance Customer Experience Lab, клиенты на 13% лояльнее к компаниям, с техподдержкой которых у них был позитивный опыт взаимодействия. Если же опыт был негативным, лояльность клиентов может снизится на 27%.

Согласно всероссийскому исследованию интеграторов спутникового мониторинга транспорта и телематики (подробнее в записи презентации результатов), проведенного нами в этом году, почти 60% компаний утверждают, что их клиенты отказываются от продолжения сотрудничества из-за некачественного сервиса. При этом у 69,7% компаний доля выручки от сервисного обслуживания составляет от 10% до 25%.

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

Планируйте работы и выезды умно и эффективно

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

На начальном этапе планировать выезды можно в том же Google Календаре. Однако этот инструмент ничего не знает ни про соглашение об уровне сервиса (Service Level Agreement, SLA), ни про саму обслуживаемую инфраструктуру. Главное - он не позволяет оценить реальную фактическую загрузку сотрудников. Поэтому начните использовать для распределения заявок и планирования специализированные системы или модули, встроенные в решения для автоматизации выездного обслуживания. Вот, например, как выглядит модуль планирования на месяц/неделю/день внутри Okdesk:

Сократите расходы на бензин и увеличьте продуктивность

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

Чтобы оптимизировать загрузку инженера, распределение задач лучше осуществлять с учетом двух ключевых аспектов:

• местоположение объекта заявки;

• местоположение или маршрут сотрудника.

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

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

Отслеживание местоположения сотрудников позволит компании исключить и левые выезды.

Сделайте инженеров и выездных техников на 100% мобильными

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

Переход на мобильные рельсы и уход от обязательных совещаний по утрам может сократить расходы на фонд оплаты труда на 20% без потери качества предоставляемых услуг.

Оценивайте реальную ситуацию в бизнесе

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

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

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

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

Откажитесь от бесплатной работы

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

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

Привет, меня зовут Сергей и я отвечаю за техническую поддержку компании itsoft, так что, в этой статье речь пойдет именно про поддержку.

Поддержка это лицо компании для текущих клиентов. Однако, так ли часто мы сталкиваемся с хорошей поддержкой? Ответ, к сожалению, очевиден.

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

Что всех бесит в поддержке

Начать я решил со списка того, что меня и моих коллег (да и вас, скорее всего) бесит в поддержке:

• долгое ожидание;

• роботы;

• некомпетентность;

• ограниченное количество каналов для связи;

• письма с адреса no-reply@domain.ru;

• нельзя пожаловаться (отсутствие обратной связи).

Долгое ожидание

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

• Сейчас мы не можем ответить на звонок;

• Оператор сейчас ответит, пожалуйста, оставайтесь на линии;

• Сейчас все операторы заняты, вам ответит первый освободившийся оператор;

• Продолжать можно до бесконечности!

Мало того, что нам приходится тратить на это много времени, так еще и далеко не всегда понятно сколько придется ждать, может 5 минут, может 20.

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

Есть уникальное в своем роде решение Ричарда Брэнсона, владельца авиакомпании Virgin Atlantic, который вместо раздражающих и клишированных фраз записал на автоответчик следующее обращение:

Здравствуйте, меня зовут Ричард Брэнсон, я владелец авиакомпании Virgin Atlantic. Сейчас все операторы заняты. Это непорядок. Давайте поступим следующим образом: если через 18 секунд никто не ответит на ваш звонок, вы получите скидку 450 фунтов. Я начинаю обратный отсчет 18, 17, 16, 15

Однако, мы с хоть каким-то подобием данного подхода пока не встречались, к сожалению.

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

Роботы

Переходим ко второму нашему пункту, который нас бесит общение с роботами.

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

• всевозможными чат-ботами, которые сегодня "умеют" практически все, даже пытаются учиться;

• автоматической системой распределения тикетов с ИИ и без него;

• роботом на телефоне и другими искусственными заменителями.

В редких ситуациях это действительно удобно и скорее всего эффективно, однако, чаще всего это очередная возможность серьезно взбесить своего клиента!

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

У нас даже есть забавная статистика, по которой около 5% обращений в наш онлайн-чат приходят с единственным вопросом: Это робот?. Однако, мы роботами не пользуемся и не планируем, так что, на все обращения отвечают живые сотрудники.

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

Некомпетентность

Следующий пункт, который нас бесит в поддержке некомпетентность сотрудников.

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

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

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

Такие причины как низкие зарплаты, а как следствие высокая текучка и низкая квалификация кадров, попавших туда по массовому отбору понятны, а вот что непонятно почему это устраивает большинство компаний?

Пример из жизни: когда-то давно, получив в банке свою первую пластиковую карточку я пытался привязать ее к счету в paypal, но была смешная по нынешним меркам проблема на карточке отсутствовал cvc-код. Забегая вперед скажу, что проблема заключалась в том, что карта не являлась дебетовой, это была visa electron, на которых наличие cvc-кода не предусмотрено. Решалась проблема просто нужно было завести другую карту, например, виртуальную. Однако, для выяснения этой информации мне пришлось раз 6 позвонить в поддержку банка и лишь на третий день на другом конце провода попался компетентный сотрудник, который за 2 минуты все объяснил. Само собой, новую карту я завел уже в другом банке.

Невнимательность

Отдельным пунктом, который мы решили выписать изолировать от некомпетентности будет невнимательность сотрудников поддержки, которая бесит не меньше!

Знакома ли вам ситуация, когда в процессе переписки с поддержкой вы задаете три вопроса, но получаете ответ только на один или два? Нам знакома! Стоит отметить, что даже педантично пронумерованные вопросы тоже могут потеряться. Комментарии тут излишни.

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

Ограниченное количество каналов для связи

Еще один пункт в нашем антирейтинге это ограниченное количество каналов для связи. Какой смысл даже в хорошей поддержке, с которой у вас нет возможности связаться?

Тут речь пойдет не о личных предпочтениях каждого, а о ситуациях, когда вам НУЖНО связаться с поддержкой, но из-за ограниченного количества каналов связи такой возможности не представляется.

Вот достаточный список:

• тикет-система, если клиенту так комфортнее и нужно отслеживать статус обращения;

• адрес электронной почты, если нет возможности авторизоваться в тикет-системе;

• номер телефона, на случай отсутствия доступа в интернет;

• возможность связаться через мессенджер или онлайн-чат, если нет возможности позвонить.

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

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

Письма с адреса no-reply@domain.ru

Пожалуй, самый безобидный, но наиболее распространенный пункт, который нас тоже бесит.

В данной ситуации раздражает факт того, что мы не можем ответить на такое письмо. Точнее можем, но его никто не прочитает.

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

Нельзя пожаловаться

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

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

Типичный пример: в некоторых банках окна обслуживания оборудованы кнопками (чаще всего это красный и зеленый смайлик), которые позволяют оценить качество того самого обслуживания. Но что произойдет, если нажать на красный, поставить отрицательную оценку? Вероятнее всего ничего. Возможно, где-то в корпоративной системе будет зафиксирован минус в карму сотруднику, но это не точно (с). Что точно никто не побежит разбираться в причинах негативной оценки, так какой в этом смысл?!

Отсутствие желания у руководства разбираться в каждой негативной ситуации можно понять, но это бесит!

На что влияет качество поддержки

Разобравшись со списком того, что нас бесит в поддержке пришло время подумать, а на что же это влияет?

Тут можно выделить 3 основных момента:

• отток клиентов;

• отсутствие лояльности;

• и как следствие, отсутствие продаж по "сарафанке".

Отток клиентов

Начнем с оттока клиентов, в чем нам поможет исследование ресурса pwc.com. В исследовании проводился анализ причин оттока клиентов, а лидерами рейтинга стали:

• плохое отношение сотрудников компании к клиентам;

• недружелюбное обслуживание клиентов;

• плохая репутация компании;

• некомпетентные сотрудники;

• низкая эффективность;

• недоступность товара (услуги).

Ничего не напоминает?

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

Отсутствие лояльности

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

Лояльность клиента подразумевает:

• адресное и продуктивно общение с отделом продаж;

• объективная, честная и своевременная обратная связь;

• готовность к изменениям, которые вы запланировали;

• помощь, в ряде ситуаций, причем как словом, так и делом;

• и конечно же, рекомендации!

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

Отсутствие продаж по сарафанке

Согласно индексу NPS, стать промоутером вашей компании могут только максимально лояльные клиенты, которые набирают 9-10 баллов, т.е. полностью довольны результатом вашего сотрудничества и качеством услуг. Будет ли доволен клиент, которого бесит ваша поддержка?! Конечно же нет.

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

Методы, которые сработали у нас

Далее, я расскажу про те методы, которые сработали у нас в компании и помогли сделать отличную поддержку. Вот список того, что мы сделали:

• запустили поддержку в Telegram;

• наладили систему премирования;

• внедрили систему оценок качества поддержки;

• перестали работать с некомпетентными и невнимательными сотрудниками.

Поддержка дата-центра в Telegram

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

Можно воспользоваться виджетом в правом нижнем углу на нашем сайте, либо найти чат в самом мессенджере (@itsoft_bot) и задать интересующий его вопрос.

Для интеграции с рабочей средой (у наc это Slack) использовали сервис telebot.im.

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

Система премирования

Еще один метод, который помогает нам удерживать планку это система премирования, которая завязана на ряд параметров KPI каждого сотрудника поддержки.

Многие параметры KPI связаны непосредственно со скоростью реакции сотрудника на поступившее обращение и качеством его работы, например:

• скорость реакции на поступившее обращение;

• время, которое потребовалось на его закрытие;

• количество пропущенных звонков;

• качество коммуникации с клиентом.

Следовательно, если сотрудник хочет получить премию он заинтересован в том, чтобы быстро и качественно обработать каждое обращение.

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

Если говорить о цифрах, то каждый сотрудник поддержки, который выдерживает уровень своих показателей KPI выше 95% на протяжении некоторого времени может поднять уровень своей зарплаты на 40% от базовой ставки, это не считая премии. Самые же эффективные сотрудники поддержки всегда могут рассчитывать на квартальную премию в размере 50% от уровня базовой зарплаты. Без кнута тут тоже не обходится, но об этом немного позже. Не жалейте денег на сотрудников, мотивация делает вещи!

Система оценок качества поддержки

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

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

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

Оценки можно ставить:

• в переписке по электронной почте;

• в тикет-системе;

• в чате Telegram.

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

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

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

Мы не работаем с некомпетентными и невнимательными сотрудниками

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

Звучит проще, чем кажется на самом деле. Но вот как это на самом деле:

• начинается все с длительного отбора и череды собеседований (благодаря премиальной системе и достойному уровню зарплаты мы можем позволить себе опытных специалистов);

• каждый сотрудник поддержки проходит испытательный срок длительностью три месяца;

• на испытательном сроке тратится много сил на закрытие пробелов как по части коммуникаций, так и по техническим моментам (для этого мы разработали подробную систему обучения и массу инструкций, регламентов и регулярно наполняем корпоративную wiki);

• по итогам испытательного срока обязательная аттестация;

• если испытательный срок не пройден - увольняем;

• для тех сотрудников, которые уже прошли испытательный срок действует вышеупомянутая система KPI и правила, которых мы придерживаемся (если показатели KPI продолжительное время ниже 90% - увольняем);

• если сотрудник систематически (чаще трех раз в квартал) нарушает регламент или прямые распоряжения руководства - увольняем.

Стоит отметить, что даже несмотря на строгость, текучка у нас практически отсутствует, но на это есть свои причины.

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

Риски перемен и как работать с персоналом

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

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

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

Однако, даже такой подход не может застраховать от ряда проблем, вот 3 основных:

• итальянская забастовка;

• увольнения;

• демотивация и нежелание работать.

К ним и перейдем.

Итальянская забастовка

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

Все прекрасно понимают, что такой формат взаимодействия невозможен.

Всегда находятся сотрудники, которые не хотят ничего менять в устоявшейся, родной, привычной схеме работы, им сложно самим принимать решения и ответственность в новых условиях. Они боятся навредить себе и/или компании, приговаривая дайте мне инструкции, и я буду их выполнять. Вот тут начинается самое интересное. Да, правила, инструкции и регламенты нужны и должны быть, но есть 3 момента:

• вы не закроете инструкциями 100% возможных ситуаций;

• ситуации, которые не закрыты инструкцией требуют, чтобы сотрудник думал самостоятельно;

• чем больше инструкций, тем меньше сотрудник думает самостоятельно.

Ситуация, на самом деле патовая, но мы стараемся ее избежать:

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

• в узких местах наша система оценки и мотивации гибкая, но не нарушает базовых принципов, цели и правила компании (например, если принято неверное решение, но оно имеет адекватно обоснование, мы дорабатываем систему, а не скидываем вину на сотрудника);

• мы не стесняемся объяснить сотрудникам цели компании, ее принципы, мотивацию руководителя и суть наших бизнес-процессов;

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

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

Увольнения

Да, у нас, как и у других случаются увольнения. Значит цели и ценности компании и сотрудника сейчас не совпадают.

Но мы стараемся выяснить чем вызвано такое решение и получить максимально подробную обратную связь:

• устраивает ли заработная плата? (иногда вопрос сводится к сумме, которую мы можем себе позволить, сохранив сотрудника);

• в каком направлении сотрудник решил двигаться? (может быть и нам нужен такой специалист, у нас несколько разных направлений);

• если это результат конфликта, то в чем он заключался? (может быть есть проблемы, о которых мы не знаем);

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

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

Демотивация, нежелание работать

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

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

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

Тут мы придерживаемся следующих принципов:

• система KPI прозрачна и понятна всем, причем, создавалась она не единолично, все участвовали в этом, имея возможность высказать опасения и предложить решение;

• параметры KPI реальны и достижимы, мы не пытались задрать планку на такую высоту, которую никто не возьмет, при этом, не стали опускать ее слишком низко;

• мы поддерживаем тягу сотрудников к развитию своих профессиональных навыков, готовы оплатить им курсы, повысить заработную плату или пригласить на другую должность;

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

Результаты

Как мы знаем, главное это результат, о котором далее и пойдет речь.

Чего мы добились благодаря нашим методам и работе с сотрудниками?

Вот краткий список:

• увеличилась скорость реакции поддержки;

• увеличилась скорость закрытия обращений;

• снизилось количество пропущенных звонков;

• увеличилось количество обращений на сотрудника;

• снизился отток клиентов.

Далее, разберем каждый пункт немного подробнее и приведем цифры.

Увеличилась скорость реакции поддержки

За последние три года мы смогли сократить время ожидания клиентов на 43%. Например, в рамках тикет-системы до середины 2017 года среднее время ответа поддержки составляло 8,6 минуты, на данный момент это 4,9 минуты.

Увеличилась скорость закрытия обращений

Если взять за шаблон такой тип обращения как Подключение IP-KVM, то за три года мы добились сокращения сроков на 76%! Стоит отметить, что и принцип закрытия обращений изменился. Мы не закрываем обращения без обратной связи от клиента (само собой, если это необходимо), а значит, мы добавили промежуточный этап, но все равно стали быстрее.

Снизилось количество пропущенных звонков

Пропущенным звонком мы считаем ситуацию, когда трубку не подняли за 5 гудков, так вот, таких ситуаций стало ниже. Му улучшили показатели с 9% три года назад до 3% на данный момент. 6% не такой уж и выдающийся показательно, но и звонков с тех пор стало больше примерно на 10%.

Увеличилось количество обращений на сотрудника

Многих вышеперечисленных показателей легко достигнуть, растеряв часть клиентской базы или увеличив штат поддержки, но в нашем случае клиентская база росла, а среднее количество обращений на сотрудника за три года увеличилось на 76%, а это значит, что мы стали не просто быстрее, мы стали эффективнее!

Снизился отток клиентов

Эффективность не имеет смысла, если клиенты все равно уходят, но и эту статистику мы смогли выправить.

Вот наши показатели оттока клиентов по годам:

• за 2017-й год средний отток составлял 2,8 %, для нас это много, и мы начали действовать;

• в 2018-м мы получили первые результаты, отток снизился и составил 1,6 %;

• в 2019-м показатель не сильно изменился и оставался на уровне 1,7 %;

• за текущий, 2020-й год средний отток составляет всего 1,1 %.

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

Появился отдел поддержки

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

С полным списком наших клиентов вы можете ознакомиться на нашем сайте.

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

Заключение

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