О чём вы в первую очередь думаете, когда слышите «legacy-продукт»? Сложность, техдолг и, конечно, ошибки. Случаются как регулярные инциденты ввиду проблем в конкретных компонентах, так и «скрытые ружья» в местах системы, которым уделили не так много внимания при изначальном системном дизайне.
Худшее, что можно сделать с ошибками в такой сложной системе — пойти решать их в лоб. Решение вряд ли станет подходящим для бизнес-задачи и может усложнить поддержку продукта или добавить ещё техдолга, который замедлит будущее развитие.
Меня зовут Александр, я руковожу продуктами CDN и DNS в компании EdgeЦентр. В этой статье я расскажу несколько историй о том, как правильная работа с ошибками не только сделала жизнь наших пользователей лучше, но и позволила избежать усложнения продуктов.
Природа ошибок
Оба продукта — как CDN, так и DNS, работают понятно: это система доставки контента и доменных имён. В первом случае мы предоставляем нашим клиентам сеть точек кэширования контента, а во втором — авторитативные DNS-серверы, которые хранят их записи. Функционал глобально не менялся со времён Танненбаума и его «Компьютерных Сетей», поэтому в нём не было явных проблемных зон.
Однако, за последние десятки лет сильно развивается концепция DNSaaS и CDNaaS — чем больше можно упаковать в CDN и DNS как сервис, тем больше продукты интересны клиенту. При равном качестве покрытия сети, скорости и надёжности работы, клиент склонен выбирать тот сервис, который решит большинство задач.
Мы стараемся не отставать от тренда: например, наша CDN поддерживает популярные протоколы сжатия, имеет image processing и может гибко управляться политиками прямо с источника. А DNS предлагает гибкие настройки балансировки и Failover-механизм, который включает и выключает источники клиента из раздачи для доступности ресурсов.
Дополнительные опции и фичи приводят к необходимости тонкой настройки, продвинутым интерфейсам и спискам опций. Наши пользователи — системные администраторы и инженеры, которые при помощи API сервисов создают нужную клиенту конфигурацию и могут гибко ей управлять. Однако, такие эксперты есть далеко не во всех компаниях, так что настраивать CDN и DNS приходят менеджеры, бизнес-аналитики и владельцы бизнеса. Им нужна система, в которой легко ориентироваться и можно быстро решать задачи.
Для этой категории пользователей на сайте EdgeЦентр у каждого нашего клиента есть свой личный кабинет, в котором он может подключать или отключать CDN, DNS и другие сервисы компании, а также настраивать их работу. И тут мы приходим к ограничениям бизнес-логики, которые надо транслировать клиенту. Например, некоторые опции могут не работать вместе (например, сжатие одного и того же контента разными алгоритмами). Или данные в аналитике могут быть представлены не так, как ожидает пользователь, и надо досыпать деталей, чтобы стало понятнее, как с этими данными работать.
Мы поставили перед собой большую задачу по наведению простоты и порядка в сложной системе. На примере нашего опыта расскажу о том, как:
сделать ошибки-ориентиры, которые помогают пользователю самостоятельно решить задачу;
скорректировать пользовательский опыт, чтобы данные не интерпретировались как ошибочные;
упростить работу со сложными ошибками так, чтобы они решались наиболее быстро.
Ошибки-ориентиры
DNS и CDN — достаточно простые продукты, работать с которыми может не только системный администратор, но и бизнес-пользователь. В то же время, в настройках этих сервисов присутствуют различные комплексные опции — в том числе, взаимоисключающие. Опции могут иметь разветвлённые дополнительные настройки. Таким образом, мы не всегда можем дать радиокнопки для выбора одной опции из многих, но и сохранить противоречивую комбинацию тоже не позволим. Мы не хотим допустить нестабильной работы системы, но в то же время — нужно выполнить бизнес-задачу нашего пользователя.
Допустим, клиент хочет сжать большой массив изображений и видео, чтобы загрузить их в карточки товара на маркетплейс и управлять контентом при помощи заголовков. Он выбирает такие опции, как «Сжатие GZip», «Сжатие Brotli», «Кастомный заголовок Host», сохраняет, и... ему прилетает сообщение страшного вида вроде «Error! [('brotli_compression', 'fetch_compressed')] is not allowed».
Ошибка эта взялась из API, и системному администратору или инженеру будет вполне понятна, но бизнес-пользователя вводит в ступор.
Мы решили твёрдой рукой пройтись по всем возможным исключениям, чтобы навести порядок. Для этого мы залезли в конфигурацию, нашли все опции, которые невозможно использовать одновременно, и добавили к ним простой словарь. Этот словарь интерпретировал ошибку, выбранный язык в ЛК и отдавал пользователю сообщение вида:
Сжатие Brotli не может быть включено одновременно с оптимизацией доставки больших файлов, сжатием GZip или сжатием на источнике | Brotli compression can't be enabled along with large files delivery optimization, Fetch or GZip compression |
Стало уже лучше, но пользователь всё ещё мог запутаться в исключениях, поэтому мы оставили «человекочитаемые» подсказки, которые зависели от конкретной конфигурации сохранения.
В результате количество обращений за настройками в ЛК в техническую поддержку заметно снизилось. Наш абстрактный бизнес-пользователь даже без чтения документации научился настраивать сервис со второй попытки, учитывая ошибки сохранения.
Учим пользователей безошибочному чтению аналитики
Одна из важных фич CDN EdgeCenter — расширенная статистика. Она позволяет посмотреть метрики сервиса без выгрузки огромных массивов данных в BI-систему. Это хорошо подходит малому и среднему бизнесу, а также крупным клиентам на старте пользования сервисом. Мы показываем трафик в разных разрезах: по географии, по директориям и так далее.
Представим себе онлайн кинотеатр. Аналитик знает, что контент кинотеатра разложен по директориям, например, в /cinema/ru лежат российские фильмы, а в /cinema/int — зарубежные. Аналитик решает собрать статистику за N часов по пользователям в разных директориях, и приходит к выводу, что 45% пользователей смотрели зарубежные фильмы, а 70% — российские. В итоге получается 115% — очень сомнительный тотал, почему же так?
Пользователь имеет полное право прийти в сервис и сказать, что фича предоставляет недостоверные данные, с которыми нельзя работать, а следовательно, не имеет бизнес-ценности.
На самом деле статистика верна, ведь она отображает уникального пользователя ресурса, а один пользователь может посмотреть несколько фильмов за период времени, следовательно — посетить несколько директорий.
Так мы облегчили пользователям работу со статистикой и метриками. Работа над статистикой показала нам, что «объяснение и пример» — это хорошая практика для хинтов в тех случаях, где люди приходят с конкретной бизнес-гипотезой и пытаются выявить её достоверность при помощи цифр. Нужные подсказки мы добавили в разные элементы интерфейса, чтобы сделать взаимодействие с ним максимально понятным.
А что пошло не так?
Кроме предоставления авторитативных серверов с каталогами имён и кэширующих серверов с контентом и логикой его обработки, мы также работаем с пользователями сервисов, а значит — с их настройками, логами и так далее. Это означает, что всё пользовательское управление осуществляется через наши API-интерфейсы — зону возможных проблем и ошибок.
Мы крайне редко встречаем в пользовательских историях что-то совсем страшное, вроде 5ХХ кодов при попытке сохранения данных. Скорее можем предупредить пользователя о том, что он посылает некорректные данные (400) или пытается выполнить действие вне прав доступа (403).
При работе с API напрямую история вполне понятная — коды ошибок сразу дают понятие о том, куда посмотреть и как навести порядок. А что же делать с фронтом, который также отправляет данные по нашему API?
На заре сервиса было принято прекрасное решение — давайте писать на весь экран магическую фразу «Oops, something went wrong» («Упс, что-то пошло не так»). Системный администратор открывал консоль браузера и понимал, о чём идёт речь — получил ошибку 403, пошёл в документацию, обнаружил, что у него не хватает прав на нужное действие. А вот менеджеру или аналитику такое уведомление об ошибке мало что говорит и объясняет в чём и состоит ошибка.
Чтобы решить задачу и упростить жизнь пользователям компании и нашей техподдержке, мы взяли за основу рекомендации по обработке ошибок из RFC. Мы настроили систему так, чтобы со стандартным номером ошибки шёл вспомогательный текст. Например, мы рекомендуем пользователю проверить отправляемые данные, обновить страницу, обратиться к документации и т.д.
На помощь опять же пришли словари. В этот раз в виде «ключ-значение». Мы храним данные о кодах ошибок в key-value виде. Так мы всегда сможем добавить ранее необрабатываемый код и пояснение, или быстро изменить один из текущих хинтов для лучшей информативности.
Это решение позволило не усложнять обработку ошибок на фронте. При поимке любого кода кроме 200, бэк обращается в key-value хранилище и формирует нужное сообщение. Так что для фронта «Oops, something went wrong», как по волшебству превратился в «Error code 400 — Please, make sure that you are trying to send correct data».
И что в итоге?
Меньше обращений в техподдержку, повышение качества обращений («У меня тут 403» уже лучше, чем «Что-то сломалось»), выше уровень удовлетворённости сервисом. Мы, продакты — люди простые, видим метрики и прокачиваем их значения. Дальше мы продолжим повышать уровень простоты и понятности продуктов, потому что бизнесу важно выполнять свои задачи дёшево, быстро и без потерь в качестве работы.
Надеемся, что статья была вам полезна. Больше о работе продуктов EdgeЦентр читайте в нашем профиле.
