Согласуйте с бизнесом план роста трафика сервиса на 1,2,3,4,5 лет вперед

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

Бизнес не будет строить никаких планов привлечения новых клиентов, его продавцы не пойдут в поля продавать, а инвесторы не дадут на все это деньги до тех пор, пока между вами и бизнесом не будет согласован план роста трафика сервиса на 1,2,3,4,5 лет вперед.

Измеряйте время полной недоступности

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

Поэтому клиент не будет ждать если Ваш сервис недоступен, а уйдет к конкурентам.

С другой стороны, наша память устроена так, что чем более отдалены от текущего момента наши воспоминания, тем более теплыми они оказываются. Поэтому не найдетесь, что бизнес вспомнит, что в прошлом году система суммарно лежала 40 часов, а в этом едва ли накопилось 4 часа: если Вы сами не будете измерять время недоступности сервиса и показывать его бизнесу, то никто не будет этого делать.

Устанавливайте и измеряйте SLA на автоматизированные операции от их старта до финиша

Бизнес знает, что конверсия в воронке продаж и NPS, а вместе с ними и рентабельность бизнеса, падают в разы, если сервис откликается медленно.

Факты таковы:

1. Google установил, что на каждую секунду задержки отображения мобильной страницы, конверсия падает на 20%. Например, если взять классический устойчивый бизнес, в котором стоимость привлечения клиента составляет $100, издержки на обслуживание еще $50 и суммарная выручка с клиента $450, то это вполне устойчивый бизнес с соотношением стоимости обслуживания к себестоимости равным трем. Изменим в этом бизнесе одну из вводных: добавим 4-секундную задержку в открытии одной из страниц в воронке привлечения. Стоимость привлечения вырастет на 80% с $100 до $180, а отношение стоимости обслуживания к себестоимости упадет с 3 до 1.95 и бизнес перестанет быть устойчивым (эмпирически устойчивый бизнес начинается от коэффициента 2.4, что позволяет бизнесу пережить "трудные" времена).

2. Amazon установил, что каждые дополнительные 100 миллисекунд задержки отклика приводят к уменьшению выручки на 1%. Возьмем устойчивый бизнес из предыдущего примера: стоимость привлечения клиента составляет $100, издержки на обслуживание еще $50 и суммарная выручка с клиента $450. Изменим в это бизнесе другую вводную: 2-секундную задержку не при открытии посадочной страницы, а при использовании сервиса. Согласно исследованию Amazon, выручка упадет на 20% с $450 до $360, а отношение стоимости обслуживания к себестоимости упадет с 3 до 2 - бизнес перестанет быть устойчивым.

Если Вы установите и измерите SLA на автоматизированные операции в горизонте 1,2,3,4,5 лет, то легко сможете объяснить бизнесу экономический эффект от вашей работы. В частности, почему Вам необходимо осуществить какие-либо масштабные изменения, например, внедрить новые архитектурные паттерны, избавиться от некоторых устаревших систем и нарастить аппаратные мощности.

Пример согласованного SLA с бизнесом:

1. Текущий SLA: главная страница сервиса открывается не дольше 10 секунд в 99% случаев

2. +1 год от текущей даты: главная страница сервиса открывается не дольше 5 секунд в 99% случаев для 500 операций в минуту

3. +2 года от текущей даты: главная страница сервиса открывается не дольше 3 секунд в 99% случаев для 1.000 операций в минуту

4. +3 года от текущей даты: главная страница сервиса открывается не дольше 2 секунд в 99% случаев для 2.000 операций в минуту

5. +4 год от текущей даты: главная страница сервиса открывается не дольше 1 секунд в 99% случаев для 4.000 операций в минуту

6. +5 лет от текущей даты: главная страница сервиса открывается не дольше 500 миллисекунд в 99% случаев для 8.000 операций в минуту

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

N.B.2: Сотрудники компании - такие же люди. Если они жалуются на низкую скорость работы систем, не выполняют планы, у них низкий eNPS (Employee Net Promoter Score) и на отдельных участках высокая текучесть кадров - измерьте SLA внутренних сервисов. В некоторых ситуациях оптимизация внутренних сервисов дает хороший экономический эффект за счет повышения производительности труда сотрудников и снижения затрат на замещение уволившихся сотрудников.

Поставьте ИИ-средства поиска аномалий

Существенная часть происходящих сбоев развивается стремительно с "подвисания" или рестарта одной из компонент.

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

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

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

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

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

Не измеряйте то, что не коррелирует с очередью в контакт-центр

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

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

Спрашивайте "кто что видит"

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

Например:

1. У нас много сессий? Давайте как можно быстрее ограничим их максимальное количество и повесим окно ожидания на входе

2. Сервис не откликается? Давайте его как можно быстрее перезагрузим

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

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

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

Расследуйте каждый сбой

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

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

2. Внешняя DDoS - атака

3. Исчерпание одного из внутренних ресурсов - физического (например: диска, памяти) или логического (например: пула соединений)

4. Бесконечное взаимное ожидание высвобождения ресурса (дедлоки)

5. Внутренний сбой сервиса из-за программной ошибки

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

Экспериментируйте на промышленной среде

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

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

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

Заведите тестовый нагрузочный стенд

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

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

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

Вы вынуждены будете стыдясь и краснея (что делает Вам честь) отвечать бизнесу на вопрос "почему раньше было хорошо, а теперь опять все стало плохо?"

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

Достигните быстрых побед

Можно согласовать с бизнесом SLA на 1,2,3,4,5 лет, но означает ли это, что первое улучшение будет через год? Вы даже можете нарисовать новую архитектуру и мысленным экспериментом объяснить почему через 1 или 2 года система начнет работать в разы быстрее. Но поверит ли в это бизнес, особенно если Вы согласовали SLA в первый раз в своей жизни, у Вас нет имиджа решателя подобных проблем и не тянется шлейф прошлых побед? К сожалению, вероятнее всего, нет. Поэтому идти к цели Вам придется через последовательное зарабатывание репутации, то есть через быстрые победы.

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

Например:

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

2. Расширение аппаратных и логических ресурсов

3. Перенос компонент на свободные аппаратные ресурсы

4. Изучение top-5 запросов в БД и их оптимизация (хинтование, добавление индексов)

5. Замена последовательных обращений в коде на пакетную обработку

6. Перенос тесно взаимодействующих компонент на один сервер для снижения влияния задержек в сети

7. Профилирование и оптимизация кода

8. Устранение ошибок в коде, приводящих к утечке ресурсов

9. Поиск и устранение дедлоков

10. Тонкая настройка параметров платформенного программного обеспечения

11. Кластеризация

12. Уменьшение уровня логирования

13. Отключение антивирусов

14. Ограничение пропускной способности через создание очередей на вход

Ищите и оптимизируйте узкое место, не тратя время на другие проблемы

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

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

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

Оптимизируйте операции целиком, меняя последовательность шагов в них

Допустим, Вы разрабатываете зарплатный сервис мобильного банкинга.

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

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

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

Воспользуйтесь событийной архитектурой для инвалидации кешей

Проблема времени инвалидации кешей относится к одной из двух трудно решаемых проблем ИТ (второй является проблема выбора удачных наименований).

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

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

Внедряйте CDC для переноса вычислений из не масштабируемых систем в масштабируемые

Многие унаследованные системы не могут масштабироваться - это факт.

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

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

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

Вычисляйте данные "впрок"

Для выполнения некоторых SLA придется заранее подготовить данные в нужном формате, поскольку попытка вычислить их "на лету" обречена на провал.

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

Не кешируйте

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

Говорите кто за все отвечает

К этому моменту Вы уже понимаете насколько много обещаний Вы дали и как многого от Вас ждут.

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

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

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

Нет "вашей" и "нашей" системы

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

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

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

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

Собирайте команду на 5-минутки 1 раз в день

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

Привлеките к 5-минутке всех, кто задействован в устранении узкого места

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

Спрашивайте на 5-минутках 3 главных вопроса

Спрашивайте у каждого сотрудника на 5-минутке 3 вопроса, популяризированных в Scrum:

1. Что было сделано вчера?

2. Какие возникли трудности/чем помочь?

3. Какие планы на сегодня?

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

Помогайте, если член команды столкнулся с трудностью

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

Меняйте членов команды, которые не показывают результата

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

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

Научитесь рисовать презентации

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

Пиарьте достижения членов команды

За сухими цифрами SLA не всегда будет виден вклад каждого из членов команды.

Раскрыть эту информацию и отметить вклад каждого из сотрудников в достижение результата - Ваша работа.

Заключение

Оптимизация SLA сервисов - одна из самых интересных и захватывающих задач, возникающих на стадии масштабирования бизнеса.

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

Желаю Вам удачи в этом нелегком деле.