Здравствуйте! Меня зовут Дима Кривопальцев. Я руковожу бэкенд-разработкой в Яндекс Диске. Тема этого выпуска — интеграция со смежными системами. Сегодня мы поговорим, почему 9 из 10 интеграций оборачиваются проблемами. И как стать тем самым десятым. Под смежными системами будем понимать всё, что разрабатывается за пределами вашей команды. Например, это может быть поиск по данным вашего сервиса, который разрабатывается соседняя команда, или интеграция с сервисом, который разрабатывается за пределами вашей компании.
Почему это важно? Без интеграции невозможны многие пользовательские сценарии, к которым мы привыкли в современном мире. Может показаться, что проблемы в смежной команде вас не очень касаются. Но на самом деле это не так, потому что страдает ваш сервис и ваши пользователи. А хочется, чтобы они всегда были счастливы. Давайте разберемся, с какими проблемами можно столкнуться и как их решить. А в идеале вообще избежать. Рассуждать мы будем на примере одной интеграции в бэкенде Яндекс Диска. Все истории и действующие лица выдуманы, все совпадения с реальностью случайны.
Представим, что мы хотим интегрироваться с сервисом авторизации и на его основе построить фичу «Доступ к файлам и папкам» по ссылкам. На сервис авторизации возложим задачу проверки прав — имеет конкретный пользователь доступ или нет. Тут, в целом, все как обычно. Продукт принес фичу, обсудили ее, оценили, пообщались со смежной командой, договорились с ними о каком-то верхнеуровневом решении. Споректировали это дело, написали код, протестировали, запустили в продакшен. Флоу обычный, примерно как для любой фичи. Но все самое интересное начинается во время эксплуатации.
Мы запустились, все замечательно. Но тут что-то происходит. У смежного сервиса отказала база данных или упали ноды бэкендов. В общем, сервис частично недоступен и генерирует много ошибок. Смежная команда чинит какое-то время, но все это время наша фича не работает. Конечно, можно сказать, что такое со всеми случается, и сейчас коллеги накрутят процессов, мер по улучшению, и такое будет происходить заметно реже. Но давайте подумаем, можно ли было что-то сделать заранее? Может показаться, что этого невозможно избежать. Ведь это не мы разрабатываем эту систему. Но на самом деле, можно смягчить эти проблемы с нашей стороны:
Можно сделать фоллбэк на старую логику, если мы мигрировали данные из одной системы в другую Можно выбрать политики более мягкой деградации. Например, в этом случае можно переходить в режим read-only для ссылок. Можно смотреть уже созданные, а вот создавать и модифицировать нельзя Еще можно продумать механизмы снижения нагрузки при проблемах. Например, приоритезировать выполняемые задачи. Предположим, у нас есть асинхронные задачи, которые ожидают пользователь. И их обязательно нужно выполнить немедленно. А есть служебные задачи, вроде очистки данных из базы данных. И если база данных нагружена, то менее важные системные задачи просто не запускаются, чтобы не усугублять ситуацию. Теперь вы знаете несколько способов, как избежать проблем при частичном отказе смежной системы:
Во-первых, заранее продумать, как будет вести себя ваша система при проблемах смежной. Во-вторых, при необходимости реализовать механизмы, которые позволят переживать такие проблемы более незаметно для пользователей. Рассмотрим вторую проблему. У смежной системы есть ограничения по нагрузке, что мешает росту вашей. Представим, что начинается PR-компания нашей новой фичи, и ей начинают пользоваться заметно больше людей. Из-за повышенной нагрузки начинаются проблемы у смежной системы авторизации. И наша фича фактически не работает. О, у нас же есть механизм неградации, которую мы сделали на предыдущем шаге! Но он предназначен только для кратковременных проблем. Если у вас каждый день сервис недоступен на запись, это конечно лучше, чем полная недоступность, но все же далеко от желаемого состояния. Получается, что смежная система оказалась не готова к такой нагрузке. Снова кажется, что такого невозможно избежать, но на самом деле есть несколько способов это сделать.