что такое саппорт в музыке

Оформление карточки музыканта

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

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

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

Yandex Музыка

Аналогично для оформления карточки артиста, пишем music@support.yandex.ru с указанием лейбла и ссылкой на страницу артиста на Яндекс.Музыка, кидаем аватар, короткое описание о группе и ссылки на соцсети.

Также связаться по этому вопросу можно через форму.

Apple Music

Артист регистрируется в сервисе Apple Music for Artists, запрашивает доступ к личному кабинету артиста и далее самостоятельно оформляет страницу.

Spotify

По аналогии с Apple, в Spotify есть сервис для артистов, где можно самостоятельно оформить страницу своего музыкального профиля.

Tik-Tok

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

Критерии для открытия музыкальной страницы у профиля:

Другие новости

Артист vs лейбл: судебный поход за невыплаченными роялти

Позиционирование артиста в эпоху стриминга

Как музыканту привязать свой аккаунт в инстаграм к музыке в сторис?

Популярные статьи

Музыканты не могут осуществить цифровую дистрибуцию самостоятельно и доставить треки на платформы –.

В криптовалютный мир ворвался новый тренд NFT-токенов (non-fungible tokens) – это новый вид цифровы.

Effective Records – независимый лейбл страны и по факту самый известный российский лейбл за рубежом.

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

Для музыкальной индустрии 2020 год войдет в учебники истории как очень сложный. Влияние COVID-19 ощ.

Будущие мероприятия

Нет предстоящих мероприятия в указанный период времени.

Источник

«Не думай о саппорте свысока»: как реализовать скрытые возможности вашей службы поддержки

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

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

1. Саппорт-психолог

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

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

В нашей Саппорт-практике в Wrike нашлись примеры прекрасных отношений с клиентами, которых мы поддерживаем. Сложившиеся связи в некоторых случаях стали теплыми и дружескими, во многом благодаря многократному взаимодействию со «счастливым исходом». Такие клиенты всегда замолвят за нас словечко — например, при кросс-продаже продукта в другие отделы или при общении с другими пользователями в нашем Сообществе. Свежий пример: недавно мы узнали о переходе одного из наиболее активных в общении с Саппортом клиентов в другую компанию. Одним из условий этого перехода стало использование Wrike как инструмента для планирования проектов. Эту новость в дружеской беседе нам сообщил сам клиент со словами «I’m a Wriker to the end!», что не могло не порадовать всю команду!

2. Саппорт-пожарный

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

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

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

3. Саппорт-коммуникатор

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

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

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

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

4. Саппорт-кузница качественных кадров

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

Саппорт Wrike, к примеру, работает из Западной и Восточной Европы, России, Северной и Южной Америки; мы говорим на русском, украинском, английском, испанском, французском, немецком, португальском (и, кстати, в этой связи помогаем с локализацией продукта). На этом языковой потенциал команды не исчерпан — знание некоторых менее распространенных языков (эстонский, шведский, тибетский (!) нечасто находит применение в работе, но зато является приятным бонусом для любого носителя редкого языка, заглянувшего в наш Саппорт-чат.

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

Источник

Танцы с саппортом: виды и формы поддержки. Саппорт систем, работающих в бою

Всем привет! Меня зовут Александр Афенов, и я тимлид команды Order Processing в Lamoda. Сегодня хочу рассказать вам о том, как мы разгребаем саппорт.

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

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

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

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

Сервис крутится на РНР 7, завернут в Docker и оркестрируется Kubernetes, но при этом реализован на фреймворке Zend1 и кусках Symfony 2. Те, кто программируют на РНР, сейчас, возможно, содрогнулись. Для остальных я поясню, что Zend1 – это фреймворк, у которого случился end of life полтора года назад. Он больше не поддерживается и не имеет даже патчей по безопасности.

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

Первое, что мы вынесли из монолита – это так называемый Refund tool. Он является вторым сервисом в ведении моей команды и отвечает за автоматическое возвращение денег клиенту (подробнее в докладе моего коллеги).

Несмотря на то, что у Refund tool современный технологический стек, он все равно порождает кучу саппорта из-за наследия Order processing.

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

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

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

Процессы и роли

Пропорциональные ведра — это то, как я называю наши бакеты.

10% мы берем из технического бэклога на то, чтобы он не застаивался и бесконечно не накапливался.

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

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

Но самая интересная вещь – это незапланированный саппорт. То есть мы предполагаем, что за период итерации что-то может сломаться, и мы потратим время на ремонт.

Оставшиеся 30% — это проекты.

Наверное, вы заметили, что здесь получается больше 100%. Связано это с тем, что мы стараемся всегда сделать больше, чем реально можем. Иногда нам это удаётся, иногда не очень.

Основные параметры саппорта

Каждому саппортному тикету мы даем оценку по следующим параметрам:

Критичность и приоритетность — это разные термины

Blocker – что-то сломало абсолютно все, остановило бизнес. Не создаются заказы, не уходят в доставку, не принимаются платежи и так далее.

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

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

Есть еще такая вещь как service level agreement, который устанавливается службой поддержки совместно с командой и бизнес-владельцем системы. Они смотрят на то, какое направление бизнеса сломалось в рамках конкретной жалобы. Если, например, перестали создаваться заказы (основной хлеб интернет-магазина), то у этой проблемы будет высокий приоритет, который мы называем Р1. Р — priority, единичка — самое важное.

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

Р2 — это что-то менее значимое, что мы должны взять в работу в течение пары часов и решить в течение дня.

Р3-Р4 — это то, что сломалось и не требует срочного ремонта. Можно когда-нибудь сделать, взять в следующую итерацию.

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

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

Кажется, что среди основных параметров не хватает одного наиболее важного – нормального описания. Довольно часто у нас появляются саппортные задачи, заведенные из системы Sentry, куда падают ошибки, exception’ы и т.д. Человек видит, что появилась какая-то небольшая проблема, и создает задачку в Jira. Так как у нас системы интегрированы друг с другом, то в таск-трекере появляется задача, в описании которой есть только ссылка на Sentry, а в названии – текст ошибки. Все.

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

Кто же все разгребет?

Более подробно о том, кто такой саппорт-инженер и чем он занимается, вы можете послушать в моем докладе «Техническая ипотека: что и кому должен тимлид» с TeamLeadConf 2018.

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

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

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

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

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

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

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

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

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

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

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

Проставление detailed priority

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

Сражение за приоритет

Например, вам поставили задачу и говорят: “Ребят, не выгружается ежемесячный отчет. Нам его через неделю надо уже иметь, а он не работает. Пожалуйста, почините. Приоритет Р1. Нужно в течение 2-3 часов решить.”

И вы спрашиваете: “Серьезно? О чем речь, ребят? Ведь есть неделя, чтобы это зафиксить. Давайте снизим до Р2, и у нас будет пара дней.”

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

Заведение новых задач

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

Контроль выполнения SLA

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

Поддержка инженера поддержки

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

Передача роли следующему из команды

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

Помочь в поиске первоисточника проблемы

Люди любят просто разгребать задачи, но при этом не фокусируются на поиске той самой первопричины. Стоит задать вопрос: “Если ты закрыл задачу, то почему проблема изначально возникла?”. Эта практика позволит найти причину, устранить ее, и, возможно, избавиться от потока такого саппорта в будущем.

Потребность в “свежем взгляде”

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

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

Разработка инструментов для автоматизации

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

Источники саппорта

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

Стабилизация новых систем и процессов

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

Поддержка развития старых систем

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

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

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

Человеческий фактор, который привел к сбою

Кто-то со словами «я сейчас все починю» выдернул жесткий диск из сервера, на котором крутился биллинг. В итоге получили то, что получили. Это не опыт Lаmoda, но реальный случай из моей практики.

Виды саппорта

Запрос на аналитику

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

Например, я не сразу узнал, что большинство данных о заказе у нас хранятся в Oracle базе департамента D&A, и все можно достать оттуда. Такой саппорт либо автоматизируется через интерфейсы, либо передается в отдел аналитики.

Запросы на изменение данных

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

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

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

Фича Х перестала работать

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

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

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

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

Major Incident

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

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

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

Как узнать, что что-то происходит?

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

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

Но самое приятное — узнавать самостоятельно по наличию мониторингов. То есть у вас может использоваться система, которая отслеживает динамику по метрикам. Например, если на подвешенном телевизоре что-то загорелось красным, то, допустим, умер Rabbit.

Это прикольно, но, кажется, что этого мало. Многие проблемы можно отловить еще на подходе, если мониторить определенные тренды. У нас был такой кейс, когда мы заметили на мониторе, что с утра начал расти расход памяти на кластере Rabbit MQ. Мы понимали, что у нас там всего 16 гигабайт, и с такой динамикой через несколько часов память кончится, и все упадет.

Так как мы увидели такую тенденцию, то вовремя всполошились. Оказалось, что у нас завис shovel-plugin, и течет память. Проблема была решена, а major предотвращен.

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

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

И после того, как удалось все потушить, наступает этап ретроспективы.

Ретроспектива

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

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

Мы видим, что в 13.05 поступила жалоба в колл-центр. Приблизительно к 13.13 стало понятно, что она массовая. И лишь только в 14.50 команда взяла задачу в работу. Перед этим почему-то 1,5 часа был простой, хотя задача была поставлена, а команда оповещена. Кажется, что этот гэп в 1,5 часа можно было бы сократить и тем самым сэкономить на этом инциденте миллионы рублей.

Почему эта проблема возникла?

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

Также видно, что фикс оказался в продакшене в 16.55, что тоже странно, так как до этого прошло уже 40 с лишним минут. Когда вроде все проверено, можно катить, но мы этого не делали.

Почему так происходит?

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

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

Затем формулировка preventive actions. Это важно, потому что вам нужно как-то гарантировать себе, руководству и кому угодно, что эта же штука не выстрелит сегодня же вечером, завтра и так далее. То есть вам нужно не повторить этот же инцидент. Для этого мы формулируем preventive actions. То есть, как вы этого добьетесь, как от этого защититься или предвосхитить.

Также необходимо проставить дедлайны/fix versions.

А затем проконтролировать выполнение. Планы — это хорошо, но избежание проблемы — намного важнее.

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

Подводные плюсы и минусы

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

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

Где же взять на это все время?

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

Lamoda была организована несколькими управляющими директорами, один из которых курировал IT. Он смог объяснить другим управляющим директорам, отвечающим за другие части бизнеса, что если мы создаем сервис-провайдер и интернет-магазин со своей автоматизацией и внутренней разработкой, то важно научиться договариваться намного заранее о том, как бизнес взаимодействует с IT-департаментом. А также ему удалось донести, что не стоит пытаться на 80% заполнить спринты новыми фичами, не оставив времени ни на стабилизацию, ни на саппорт, ни на разгребание проблем. Он смог это сделать и добиться результата.

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

Источник