Поддержка

Всем привет. Сегодня речь пойдет не совсем о разработке. Я даже не знаю с чего начать. Это просто крик души.

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

Хто я?

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

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

Вернувшись в офис, я решил уделить время охотнику за багами. После небольшой переписки, багхантер понимает что вознаграждение не я плачу и что все-таки я бесполезен для него. Ситуация стихает на некоторое время. Но неделю назад все началось с бОльшей силой. Я как обычно сижу на работе, провожу митап со своей командой, как мне начинают звонить. Естественно все по старой схеме: я занят > сброс > звонок. Цикл замкнулся.

while (true) {  const rand = randomFloat();  if (rand > 0.9) {    writeMessage("Hi");    continue;  }    callTelegramm();}

После митапа я пишу "What happened?" ииии... Дальше ничего. Сообщение не прочитано, человек так сильно пытался до меня дозвониться и пропал. Через 3 дня он объявляется и сообщает что нашел аж 10(!) багов. Я думаю "как же так, 10 багов, я о них ничего не знаю". Логично что я сразу же занялся его вопросом и решил лично проверить все.

-_- ([%$#%^&$#] заголовок украден хакерами анонимусами)

После проверки "багов" оказалось что часть из них - возможность вытащить "личные данные пользователей". Звучит страшно, но на деле там оказалось что можно получить nickname пользователя, чей ник ты и так должен знать и (внимание) ID пользователя. Wow. Чтобы было немного понятнее: вы можете найти в телеграм пользователя по его нику. Чтобы его найти - вы и так должны знать ник. Это точно личные данные пользователей уязвимые для атаки? Вот такой же "баг" у нас нашли.

Другой "баг" - возможность доступа к открытым разделам приложения без оплаты. Мы сняли требование оплаты для того чтобы пользователь мог зайти в настройки и изменить емаил или пароль. Или же сменить тарифный план на бесплатный. Так вот как оказалось - это критическая уязвимость.

Еще могу рассказать как взломать абсолютно любой сервис. Как же? Все просто: открываете дев-тулзы на сайте и меняете текст в хтмл на свой личный. Для удобства представим что вы в сообществе вк добавляете модератора. Так вот вы находите в девтулзах слово "модератор" и пишете "владелец". А потом нажимаете кнопку, которая и выдает права. Проверять не стоит, ведь вы и так уверены что сообщество теперь принадлежит другому пользователю. Правда если все же проверить права - он окажется модератором, но это не важно. Звучит как ерунда? Я с вами согласен.

В конечном счете оказалось из 10 багов, за которые, кстати, тот самый нереальный охотник просил $2000, действительно багами считать можно только 2. И то они заключались в том, что мы не ограничиваем максимальное количество вводимых символов в инпут пароля при логине и регистрации. Казалось бы: можно попробовать забить сервер. Но при превышении максимального веса запроса - сервер сам отбросит его, да и к тому же у нас передается очень много данных между клиентом и сервером. Бывает возвращается ответ с 10к+ строк текста.

Пора поговорить о bug bounty

Решение было принято. За это платить $2000 не будем, оно того не стоит. Было предложено $400 за эти 2 момента. Но эта сумма не устроила охотника за багами. Он снисходительно снизил цену до $1500. 1500? Что? За максимальное ограничение символов? Его аргументом стало то, что это можно использовать для DDOS-атаки. Но DDOS-атака не проводится на поля для ввода. Она не так подбирается. Ищется место, в котором сервер медленнее всего обрабатывает запрос - очевидно там тяжелая работа с базой или какая-то дополнительная обработка, а может и в оперативу выгружает большое количество данных. И именно в этом место начинается атака чтобы положить сервер. В результате я предложил решение: проведешь успешную атаку с этим "багом" и мы поговорим об оплате за него.

Тут баг-хантер решил что пора понижать планку еще: до $1000. На самом деле $400 за эти "баги" и так сильно завышенная цена. После моего отказа - начались звонки - я отписал что в данный момент работаю и не могу ответить, но звонки продолжились. На следующий день все повторилось - я перенаправил его на других сотрудников, но с ними сей человек разговаривать не стал и продолжил долбиться ко мне в личку. В конце рабочего дня он отписал, что согласен на $600, после чего мы с ним еще раз поговорили и сошлись на 500, но без дальнейшего продолжения сотрудничества. После чего я связался с CEO компании и оказалось, что за день до этого ему уже перевели $500 (в тот момент, когда его это не устраивало). Я снова списался с охотником на баги и оказалось что он хочет еще $500. То есть в общей сложности $1000. И снова начались звонки... Я запретил ему в настройках звонить мне - он зарегал второй аккаунт, затем третий. После - начал звонить и писать в чат поддержки с требованием перевести ему еще со словами "иначе с вами никто не будет работать". Дальше - больше. Дело пошло к угрозам, жалобным и злобным эмоджи.

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

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

Мораль сей басни такова

1. Не названивайте в телеграм постоянно. Если человек сбросил - он занят и обязательно ответит позже

2. Не ломите цену. Ну ей богу. Ограничение по количеству символов в инпуте не стоит 2000 у.е. Оно и 500 не стоит если честно. Такими темпами можно будет оценивать отсутствие валидации полей на клиенте в тысячу долларов. А главным аргументом станет "Ну и что, что запрос не выполняется. Он же на сервер улетает. Запрос лишний - можно дудосить"

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

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

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

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

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

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

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

Ниже я расскажу, как в 1 клик запустить такого бота и как он технически устроен.

TL;DR: Код выложил сюда: https://github.com/ohld/telegram-support-bot

Юзер стори или как с этим ботом работать.

Действующие лица:

• Ваши Пользователи (читатели канала, клиенты),

• Закрытый Чат Поддержки (где сидят те, кто будет отвечать на вопросы Пользователей),

• Бот (которому Пользователи будут писать свои вопросы).

Вот так это все будет работать:

1. Вы публикуете ссылку на Бота,

2. Пользователи пишут в него свои вопросы,

3. Бот пересылает их сообщения в ваш Чат Поддержки,

4. В этом чате вы или ваши помощники отвечают на сообщение (через reply),

5. Бот пересылает ответ обратно пользователю от своего лица, скрывая аккаунт отвечающего.

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

Как это все запустить? Желательно, без навыков.

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

В README.md я добавил волшебную кнопку от Heroku, которая поможет запустить код из репозитория. После нажатия, при наличии аккаунта на Heroku (который можно создать также по 1 кнопке), вы увидите такую картину:

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

- App name: название приложения в системе Heroku. Можно придумать любое.

- Choose a region: где Хероку запустит ваш код. Можно выбрать любое место.

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

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

- TELEGRAM_TOKEN: токен вашего бота, который можно получить у BotFather.

Как узнать TELEGRAMSUPPORTCHAT_ID

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

Как реализовать такого бота?

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

Примеры кода я буду писать на языке Python и использовать библиотеку python-telegram-bot. Итогда я буду вставлять ссылки на GitHub (гит), чтобы легко можно было найти этот кусок кода в моем репозитории.

Хендлеры (обработчики событий)

Для нашей задумки необходимы всего 3 хендлера (гит):

from telegram.ext import Updaterfrom telegram.ext import CommandHandler, MessageHandler, Filtersupdater = Updater(TELEGRAM_TOKEN)dp = updater.dispatcher# Для приветственного сообщения и для "к вам подключился {username}"dp.add_handler(CommandHandler('start', start))# Для пересылки из бота в чат поддержкиdp.add_handler(MessageHandler(Filters.chat_type.private, forward_to_chat))# Для пересылки ответа из чата обратно пользователюdp.add_handler(MessageHandler(Filters.chat(TELEGRAM_SUPPORT_CHAT_ID) & Filters.reply, forward_to_user))

С командой /start все понятно. Юзер нажал - прислать приветственное сообщение - прислать в чат поддержки о том, что подключился новый юзер (гит).

def start(update, context):    update.message.reply_text(WELCOME_MESSAGE)    user_info = update.message.from_user.to_dict()    context.bot.send_message(        chat_id=TELEGRAM_SUPPORT_CHAT_ID,        text=f"? Connected {user_info}.",    )

В случае пересылки ботом сообщения пользователя из лички в чат поддержки, тоже все просто (гит):

def forward_to_chat(update, context):    update.message.forward(chat_id=TELEGRAM_SUPPORT_CHAT_ID)

В случае отправление ответа (reply) на пересланное сообщение, необходимо скопировать содержимое сообщения и отправить его от лица бота. Если аналогично сделать .forward, то будет виден отправитель. А тут как раз недавно в Telegram Bot API добавили возможность удобно копировать содержимое сообщения (гит):

def forward_to_user(update, context):    user_id = update.message.reply_to_message.forward_from.id    context.bot.copy_message(        message_id=update.message.message_id,        chat_id=user_id,        from_chat_id=update.message.chat_id    )

Бесплатный деплой на Heroku

Чтобы захостить это все бесплатно на Heroku, бот должен быть запущен в режиме Webhook, а не Pooling. Разница их в том, что вебхук "слушает новые сообщения от Телеги", а пулинг "периодически запрашивает". Чтобы запрашивать, сервер должен работать постоянно (условно, каждую секунду запрашивать у серверов Телеграмма новые сообщения, которые кто-то написал в бот). Однако, в случае с вебхуками, сервер может просто ждать, когда серверы Телеграмма сами отправят нам новые обновления бота.

Этот факт критически важен, если мы хотим бесплатно пользоваться услугами Heroku (который по факту дает нам свои серверы в аренду). Хероку любит "усыплять" простаивающие машины, которые пробуждаются в момент нового входящего запроса. Именно новые сообщения от серверов Телеграмма и будут пробуждать наш сервер тогда, когда необходимо переслать пользовательское сообщение из лички бота в наш чат поддержки.

Для того, чтобы настроить Webhook, необходимо поднять вебсервер, который будет слушать входящие сообщения по endpoint. Сказать Телеграму: "присылай события бота мне на сервер - по этому адресу". Также нужно как-нибудь защититься от злоумышленников, которые могут отправить на наш вебсервер событие, прикинувшись сервером телеги. Также телеграм требует, чтобы все работало https.

Звучит сложно, однако Heroku автоматически и бесплатно обеспечит https, а вебсервер для вебхука уже встроен в библиотеку python-telegram-bot. Если добавить секретный токен вашего бота в URL, по которому вы будете слушать события от Телеги, то можно защититься от стороннего вмешательства.

Вот как можно запустить Телеграм бот в webhook-режиме (гит) через эту библиотеку:

# запускаем слушающий вебсервер updater.start_webhook(  listen="0.0.0.0",  port=PORT,  # HEROKU требует, чтобы порт вебсервера задавался через переменные окружения  url_path=TELEGRAM_TOKEN  # добавляем секретное значение в адрес, который слушаем)# говорим Телеграму: "присылай события бота по этому адресу"updater.bot.set_webhook(f"https://{HEROKU_APP_NAME}.herokuapp.com/{TELEGRAM_TOKEN}")updater.idle()

Помните, мы отдельно задавали переменную окружения HEROKU_APP_NAME , куда копипастили название нашей Heroku App? Дело в том, что эта переменная используется в адресе, по которому Heroku запускает наш вебсервер. Но при этом, имя приложения Хероку нельзя получить изнутри, поэтому решение "скопипастить название App Name в отдельную переменную окружения" для меня звучит норм.

Что дальше?

Допустим, вы запустили бота, у вас уже много клиентов и вы хотите усовершенствовать функционал телеграм бота. Что можно сделать?

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

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

А какие другие популярные юзкейсы Телеграм ботов вы бы выделили? Напишите в комментариях.

Привет, меня зовут Сергей и я отвечаю за техническую поддержку компании 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%, но увы, год выдался трудным и к сожалению, многих клиентов мы потеряли по независящим от нас причинам.

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

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

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

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

Заключение

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

Автор: Александр Монахов, Леонтий Онищук, Виталий Гнусин DevOps Engineers, DataArt, Анна Медведенко Project Manager, DataArt

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

1. Что такое Blueprints?

Blueprints сервис Azure Cloud, позволяющий в декларативном виде определять повторяемый набор ресурсов Azure Cloud, соответствующий стандартам и требованиям организации.

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

2. Что можно сделать с помощью Blueprints?

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

• Role Assignments.

• Policy Assignments.

• Azure Resource Manager templates (ARM templates).

• Resource Groups.

В отличие от ARM-темплейтов, сервис Blueprints предназначен для конфигурирования окружения. Такая конфигурация обычно содержит набор из ресурсных групп, политик, ролей и, собственно, ARM-темплейтов. Blueprint содержит все эти артефакты вместе и поддерживает версионирование, что открывает возможность внедрения практик CI/CD.

Также, в отличие от ARM-темплейтов, при разворачивании ресурсов через Blueprint сохраняется связь между определением (что должно быть развернуто) и назначением (что было развернуто). Эта связь позволяет контролировать процесс разворачивания ресурсов.

Каждый Blueprint может (но не обязан) содержать ARM-темплейт.

3. Blueprint as Code

3.1 Предварительные требования

Для удобства работы с Blueprints в Azure DevOps на уровне организации можно установить расширение Azure Blueprints от Neil Peterson.

Работа c Blueprints состоит из следующих этапов:

• Подготовка Blueprint, его артефактов (см. ниже), а также файла с параметрами назначений (assign.json).

• Создание (publish) версии Blueprint в Azure Blueprints service.

• Назначение (assignment) версии Blueprint в результате создается окружение, соответствующее артефактам Blueprint и параметрам из файла assign.json, или же существующее окружение обновляется и приводится в соответствие с ними.

3.2 Структура артефактов Blueprint

Артефакты Blueprint описываются файлами JSON каждый артефакт содержится в отдельном файле.

В общем случае папка с Blueprints и артефактами выглядит так:

Файл blueprint.json основной, его назначение определение самого Blueprint. При деплое Blueprint он вызывается первым, а все артефакты представляют собой его дочерние ресурсы.

Файлassign.json обязателен при операции назначения Blueprint, он содержит значение переменных, которые используются в Blueprint в процессе Assignment (например, имена создающихся компонент, их SKU, регион, в котором будут созданы описанные компоненты, и т. д.). Обычно значения переменных или параметров в этом файле необходимо изменить. Для этого используется трансформация файла.

3.3 Трансформация файла

ФункцияFileTransformможет изменять содержимое XML или JSON-файлов.

Пример:

Файл assign.json, который используется в процессе назначение Blueprint. Нам необходимо изменить значения location, blueprintId, gOrganizationName и g_AzureRegion:

{    "identity": {      "type": "SystemAssigned"    },    "location": "testLocation",    "properties": {      "blueprintId": "testBlueprintId",      "resourceGroups": {},      "parameters": {        "g_Organization_Name": {          "value": "testOrgName"        },        "g_AzureRegion": {          "value": "testLocation"        }      }    }} 

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

variables:  location: 'westeurope'  properties.blueprintId: "/subscriptions/$(SubscriptionId)/providers/Microsoft.Blueprint/blueprints/AM-BP-feature-init"  properties.parameters.g_AzureRegion.value: $(location)  properties.parameters.g_Organization_Name.value: "Integration"

и выполняем трансформацию файла:

- task: FileTransform@1  inputs:    folderPath: '$(Agent.BuildDirectory)\blueprints'    fileType: 'json'    targetFiles: 'assign.json'

Можем посмотреть содержимое трансформированного файла:

- script: type "$(Agent.BuildDirectory)\blueprints\assign.json"

3.4 Типы артефактов

Blueprint состоит из артефактов, причем поддерживаются следующие типы последних:

• Ресурсные группы применяются на уровне подписок.

• ARM-темплейты применяются на уровне подписок и ресурсных групп.

• Назначение политик применяются на уровне подписок и ресурсных групп.

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

Рассмотрим пример файла blueprint.json:

{    "properties": {        "description": "This will be displayed in the essentials, so make it good",        "targetScope": "subscription",        "parameters": {             "principalIds": {                "type": "string",                "metadata": {                    "displayName": "Display Name for Blueprint parameter",                    "description": "This is a blueprint parameter that any artifact can reference. We'll display these descriptions for you in the info bubble",                    "strongType": "PrincipalId"                }            },            "genericBlueprintParameter": {                "type": "string"            }        },        "resourceGroups": {            "SingleRG": {                "description": "An optional description for your RG artifact. FYI location and name properties can be left out and we will assume they are assignment-time parameters",                "location": "eastus"            }        }    },    "type": "Microsoft.Blueprint/blueprints" }

Мы видим два опциональных параметраparameters: principalIdsиgenericBlueprintParameter.

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

3.5 Параметры

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

Параметр может быть определен в простом виде:

"parameters": {     "genericBlueprintParameter": {        "type": "string"    }}

Типы параметров можно найти в этом разделе документации.

Обращение к параметрам может происходить так же, как это делается в свойствах ARM-темплейтов (defaultValue, allowedValue и т. д.). Также мы можем вызвать параметры, определенные ранее:

"properties": {    "genericBlueprintParameter": "[parameters('principalIds')]",}

Также получить значение параметра можем через конструкцию вида:

${{ parameters.genericBlueprintParameter }}

3.6 Свойства Resource Group

Мы определили свойства Resource Group в главном файле blueprint.json с такими параметрами:

• Месторасположение: "location": "eastus".

• Имя размещения для ResourceGroup: SingleRG.

Ресурсная группа еще не создана, это случится после назначения (assignment).

По желанию мы можем указать имя ресурсной группы добавив "name": "myRgName" как дочерний параметр объекта SingleRG (подробнее посмотреть можно здесь).

3.7 Артефакты

Все артефакты должны иметь следующие параметры:

1. Kind, согласно которому, артефакт может быть:

   a. template,

   b. roleAssignment,

   c. policyAssignment.

2. Type, который для артефактов всегда будет:Microsoft.Blueprint/blueprints/artifacts.

3. Properties основной раздел, в котором описываются все свойства артефакта.

   Например:

   a. dependsOn опционально может указывать на зависимость от других артефактов. Больше информациитут.

   b. resourceGroup опционально может указывать на название ресурсной группы, где будут размещаться ресурсы. Если этот параметр не определен, для размещения ресурсов будет использоваться ресурсная группа, указанная в файле bluepring.json.

Полная спецификация для каждого типа артефактов описана здесь: Policy Assignment, Role Assignment, Template.

3.8 Работа с Blueprints в пайплайнах

Для работы с Blueprints можно использовать:

• powershell командлеты (модуль Az.Blueprint, подробнее см. здесь);

• таски, разработанные Neil Peterson (подробнее см. здесь, их мы и используем в этой статье).

3.8.1. Создание Blueprint

steps:- task: nepeters.azure-blueprints.CreateBlueprint.CreateBlueprint@1  displayName: 'Create Azure Blueprint'  inputs:    azureSubscription: 'nepeters-subscription'    BlueprintName: 'blueprints-demo'    BlueprintPath: ./create    IncludeSubFolders: true    PublishBlueprint: true    ChangeNote: 'Added new artifacts.'

Результаты можно просмотреть на Azure портале -> Blueprints -> Blueprint definitions.

3.8.2. Назначение Blueprint

steps:- task: nepeters.azure-blueprints.AssignBlueprint.AssignBlueprint@1  displayName: 'Assign Azure Blueprint'  inputs:    azureSubscription: 'nepeters-internal'    AssignmentName: 'prod-test-one'    BlueprintName: 'prod-test-one'    ParametersFile: 'assign/assign-blueprint.json'    AlternateSubscription: true    SubscriptionID: '00000000-0000-0000-0000-000000000000'    Wait: true    StopOnFailure: true

Результаты можно просмотреть на Azure портале -> Blueprints -> Assigned blueprints. Эта секция особенно полезна для получения детальных логов при ошибках назначения Blueprint.

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

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

ArchUnit

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

- Сайт Archunit

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

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

Репозиторий GitHub и структура тестов

Кэтому посту прилагается репозиторий GitHub.Он содержитминимальное приложение Spring Boot, а такжеправила ArchUnit для поиска классов и методов, на которые нетссылок.

На момент написаниямы использовали ArchUnit 0.15.0.В частности, мы используемподдержку JUnit5черезcom.tngtech.archunit:archunit-junit5:0.15.0.Это приводит к базовой структуре теста:

@AnalyzeClasses(  packagesOf = ArchunitUnusedRuleApplication.class,  importOptions = {    ImportOption.DoNotIncludeArchives.class,    ImportOption.DoNotIncludeJars.class,    ImportOption.DoNotIncludeTests.class})class ArchunitUnusedRuleApplicationTests {  @ArchTest  static ArchRule classesShouldNotBeUnused = classes()    .that()      ...    .should(      ...    );  @ArchTest  static ArchRule methodsShouldNotBeUnused = methods()    .that()      ...    .should(      ...    );}

Обратите внимание, как мы ограничиваем классы, анализируемые с помощью аргументов packagesOf иimportOptionsв аннотации @AnalyzeClasses().Кроме того, использование аннотации @ArchTest встатическом поле типа ArchRule избавляет нас от необходимости вызывать ArchRule.check(JavaClasses),как показано в предыдущем посте в блоге.

Спомощью селекторов classes() и methods() из ArchRuleDefinition выбираем элементы, которыемы хотим проверить с помощью нашего правила. Обычно эти элементы затем дополнительно ограничиваются последовательностью вызовов после.that(), чтобы отсеять потенциально ложные срабатывания. Наконец, с помощью.should()мы проверяем, что все оставшиеся классы удовлетворяют заданному условию, и при обнаружении каких-либо классов вызываем исключение.

Обнаружение неиспользуемых методов

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

Конечно, в типичном приложении Spring Boot есть причины, по которым метод никогда не вызывается напрямую, в частности, когда аннотируется конечная точка сети, прослушиватель сообщений или обработчик команд, событий или исключений.В этих случаях фреймворк будет вызывать методы за вас, поэтому вы не хотите, чтобы они случайно помечались как неиспользуемые в вашем правиле тестирования.То же самое касается общих методов, добавляемых, в частности, при использовании Lombok's@Dataor@Value, которые добавляютequals,hashCodeиtoStringв классы.

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

@ArchTeststatic ArchRule methodsShouldNotBeUnused = methods()  .that().doNotHaveName("equals")  .and().doNotHaveName("hashCode")  .and().doNotHaveName("toString")  .and().doNotHaveName("main")  .and().areNotMetaAnnotatedWith(RequestMapping.class)  .and(not(methodHasAnnotationThatEndsWith("Handler")    .or(methodHasAnnotationThatEndsWith("Listener"))    .or(methodHasAnnotationThatEndsWith("Scheduled"))    .and(declaredIn(describe("component", clazz -> clazz.isMetaAnnotatedWith(Component.class))))))  .should(new ArchCondition<>("not be unreferenced") {    @Override    public void check(JavaMethod javaMethod, ConditionEvents events) {      Set<JavaMethodCall> accesses = new HashSet<>(javaMethod.getAccessesToSelf());      accesses.removeAll(javaMethod.getAccessesFromSelf());      if (accesses.isEmpty()) {        events.add(new SimpleConditionEvent(javaMethod, false, String.format("%s is unreferenced in %s",          javaMethod.getDescription(), javaMethod.getSourceCodeLocation())));      }    }  });static DescribedPredicate<JavaMethod> methodHasAnnotationThatEndsWith(String suffix) {  return describe(String.format("has annotation that ends with '%s'", suffix),   method -> method.getAnnotations().stream()     .anyMatch(annotation -> annotation.getRawType().getFullName().endsWith(suffix)));}

Обнаружение неиспользуемых классов

Чтобы обнаружить целые классы, на которые нет ссылок из других классов, мы можем применить тот же подход с несколькими незначительными изменениями.Мы также не хотели бы ошибочно идентифицировать любой@Componentобъект, содержащий конечную точку, прослушиватель (listener) или обработчик, поэтому нам нужен еще один настраиваемый предикат.В нашей проверке состояния мы также контролируем обнаружение в JavaClass.getDirectDependenciesToSelf() каких-либо зависимостей, чтобы отсеять еще один источник ложных срабатываний.

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

@ArchTeststatic ArchRule classesShouldNotBeUnused = classes()  .that().areNotMetaAnnotatedWith(org.springframework.context.annotation.Configuration.class)  .and().areNotMetaAnnotatedWith(org.springframework.stereotype.Controller.class)  .and(not(classHasMethodWithAnnotationThatEndsWith("Handler")    .or(classHasMethodWithAnnotationThatEndsWith("Listener"))    .or(classHasMethodWithAnnotationThatEndsWith("Scheduled"))    .and(metaAnnotatedWith(Component.class))))  .should(new ArchCondition<>("not be unreferenced") {    @Override    public void check(JavaClass javaClass, ConditionEvents events) {      Set<JavaAccess<?>> accesses = new HashSet<>(javaClass.getAccessesToSelf());      accesses.removeAll(javaClass.getAccessesFromSelf());      if (accesses.isEmpty() && javaClass.getDirectDependenciesToSelf().isEmpty()) {        events.add(new SimpleConditionEvent(javaClass, false, String.format("%s is unreferenced in %s",          javaClass.getDescription(), javaClass.getSourceCodeLocation())));      }    }  });static DescribedPredicate<JavaClass> classHasMethodWithAnnotationThatEndsWith(String suffix) {  return describe(String.format("has method with annotation that ends with '%s'", suffix),    clazz -> clazz.getMethods().stream()      .flatMap(method -> method.getAnnotations().stream())      .anyMatch(annotation -> annotation.getRawType().getFullName().endsWith(suffix)));}

Ограничения

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

Замораживание ложных (или истинных!) срабатываний

К счастью, есть элегантный способ обработки ложных срабатываний в отношении наших пользовательских условий ArchConditions:Freezing Arch Rules.Передав наше правило ArchRule, в FreezingArchRule.freeze(ArchRule) мы можем записать все текущие нарушения и остановить добавление новых нарушений.

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

- Сайт Archunit

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

Протестируйте сами правила ArchUnit

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

@Nestedclass VerifyRulesThemselves {  @Test  void verifyClassesShouldNotBeUnused() {     JavaClasses javaClasses = new ClassFileImporter()       .withImportOption(ImportOption.Predefined.DO_NOT_INCLUDE_ARCHIVES)       .withImportOption(ImportOption.Predefined.DO_NOT_INCLUDE_JARS)       .withImportOption(ImportOption.Predefined.DO_NOT_INCLUDE_TESTS)       .importPackagesOf(ArchunitUnusedRuleApplication.class);     AssertionError error = assertThrows(AssertionError.class,       () -> classesShouldNotBeUnused.check(javaClasses));     assertEquals("""       Architecture Violation [Priority: MEDIUM] - Rule 'classes that are not meta-annotated with @Configuration and are not meta-annotated with @Controller and not has method with annotation that ends with 'Handler' or has method with annotation that ends with 'Listener' or has method with annotation that ends with 'Scheduled' and meta-annotated with @Component should not be unreferenced' was violated (3 times):       Class <com.github.timtebeek.archunit.ComponentD> is unreferenced in (ArchunitUnusedRuleApplication.java:0)       Class <com.github.timtebeek.archunit.ModelF> is unreferenced in (ArchunitUnusedRuleApplication.java:0)       Class <com.github.timtebeek.archunit.PathsE> is unreferenced in (ArchunitUnusedRuleApplication.java:0)""",       error.getMessage());  }  @Test  void verifyMethodsShouldNotBeUnused() {    JavaClasses javaClasses = new ClassFileImporter()      .withImportOption(ImportOption.Predefined.DO_NOT_INCLUDE_ARCHIVES)      .withImportOption(ImportOption.Predefined.DO_NOT_INCLUDE_JARS)      .withImportOption(ImportOption.Predefined.DO_NOT_INCLUDE_TESTS)      .importPackagesOf(ArchunitUnusedRuleApplication.class);    AssertionError error = assertThrows(AssertionError.class,      () -> methodsShouldNotBeUnused.check(javaClasses));    assertEquals("""      Architecture Violation [Priority: MEDIUM] - Rule 'methods that do not have name 'equals' and do not have name 'hashCode' and do not have name 'toString' and do not have name 'main' and are not meta-annotated with @RequestMapping and not has annotation that ends with 'Handler' or has annotation that ends with 'Listener' or has annotation that ends with 'Scheduled' and declared in component should not be unreferenced' was violated (2 times):      Method <com.github.timtebeek.archunit.ComponentD.doSomething(com.github.timtebeek.archunit.ModelD)> is unreferenced in (ArchunitUnusedRuleApplication.java:102)      Method <com.github.timtebeek.archunit.ModelF.toUpper()> is unreferenced in (ArchunitUnusedRuleApplication.java:143)""",      error.getMessage());  }}

Заключение

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