Привет! Меня зовут Андрей, я head of platform в финансовом маркетплейсе Банки.ру. 

Для создания своих продуктов мы применяем микросервисный подход. Он помогает нам ускорить разработку и делает ее гибкой и управляемой. Но как в любом подходе, у него есть темная сторона, проявление которой может создать кучу неприятностей и осложнить работу над проектом. Сегодня хочу поговорить об одном из таких аспектов — о сервисах-«сиротах» (так мы их ласково называем в Банки.ру, поэтому дальше кавычки ставить не буду).

Эта статья – оптимистичное и структурированное продолжение моего доклада на ту же тему, с которым я выступал в 2018 году. Текстовая версия есть на Хабре.

Годы взаимодействия с разномастными сиротами помогли их классифицировать, поэтому захотелось уделить больше внимания тому, какие сироты бывают, чем они опасны или хороши (такое тоже случается), каких нужно возвращать в семью, а от каких отказываться. Чтобы было зрелищнее и веселее, использовал образы и иллюстрации из мира «Гарри Поттера» в целом и «Фантастических тварей» в частности, прошу понять и простить. Права на изображения незыблемо принадлежат братьям Уорнер – и всё такое.

Какие качества определяют сервис-сироту  

Каждому сервису нужен хозяин: команда, которая будет поддерживать, развивать сервис, наращивать экспертизу. Если такого хозяина нет —  предыдущие владельцы уволились, перешли на другой проект и не передали сервис в ведение другой команды — поздравляю, у вас «сиротянка».  

Как узнать сервис-сироту: 

• никто не знает, как он работает

• у сервиса нет проекта или команды, а если есть, любые задачи, с ним связанные, демотивируют сотрудников и к результату не приводят: прокрастинация, переползание из спринта в спринт и переоценка приоритетов.

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

• Жабы.

К этому типу мы относим сервисы:  

• с устаревшим фреймворком;

• со специфическими требованиями к железу или операционке;

• с зависимостью от библиотек, которые вообще не поддерживаются либо поддерживаются командами, не вшущающими доверия;

• требующие сложной, а, следовательно, дорогой поддержки.

Откуда берутся жабы? 

Чаще всего, конечно, «исторически сложилось». Иногда жаба становится результатом партизанской разработки, когда сервис создает product owner или разработчик в обход общепринятых технических требований. Случается, что жабы приносят аутсорс-команды, которые реализуют сервисы по требованиям бизнес-департаментов. Такой сервис добавляется в текущий стек, а про его поддержку забывают. 

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

Порой мы побеждаем в bullshit-bingo, когда случается все одновременно: старый сервис-аутсорсер разорился, команда поддержки разбежалась, продукт выгорел и уехал в Тибет… Короче, концов не найти. 

Жабы не всем нравятся, но обычно безобидны. А вот…

• …Оборотни — не очень

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

Откуда берутся оборотни?

Мой любимый портал: CV Driven Development. Разработчик захотел попробовать новый фреймворк или язык программирования. Или, может быть, он просто непризнанный гений со своим уникальным подходом к решению задачи. Такой сервис выкатывают на прод, включают в мониторинг, но как его поддерживать — непонятно. 

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

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

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

От опасных тварей перейдем к красивым.

• Фениксы 

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

Таинственная —  непредсказуемость. Развивать такой сервис невозможно. Даже если вы скрупулёзно изучите код, понятней не станет.  

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

Как появляются фениксы?

Примерно так же, как и оборотни, только в отличие от последних, с фениксами вам повезло: «Играл в bullshit-bingo, проиграл». 

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

• Домовые эльфы

Хорошо и ответственно делают свою работу, понятно масштабируются и поддерживаются, но есть нюанс: изменились бизнес-приоритеты, команду у сервиса забрали – и эльф остался без хозяина. Ну, спасибо хоть не подарили одежду!

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

Риски сервисов-сирот 

В чем риски сервисов-сирот, даже если они за добро, как эльфы или фениксы?

• «Дыры» в безопасности или функциональности: уязвимости, которые могут быть вызваны старыми версиями фреймворков, ОС, зависимостями. 

• Неожиданный отказ и аффект на другие продукты. 

Сервис может сам по себе упасть, тогда функциональность будет нарушена. А может заодно потянуть связанные с ним процессы — тогда проблем будет больше. 

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

• Ресурсов тратится больше, чем этот сервис по итогу вам приносит. 

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

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

Что делать с сиротами

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

Довольно яркий пример – наше старое мобильное приложение, которое было разработано в 2018 году сторонней компаний. Поначалу оно было похоже на «жабу», использовало php-микросервис для кэширования api-запросов. Однако потом мы распознали настоящего оборотня: поскольку некому было следить за этой парочкой, иногда сервис кэширования под нагрузкой «ронял» нам разделы приложения. Результат: 1-2 звездные отзывы в сторах и испорченная репутация. Приложение сняли, кэширование забэкапили и погасили, чтобы освободить место под солнцем для уже собственной разработки мобильного приложения.

Примерный план: 

1. Собрать список сироток. 

2. Оценить влияние, расходы и риски. 

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

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

   

Можно ли предупредить появление сирот?

Короткий ответ: конечно, у монолитных приложений таких проблем нет!

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

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

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

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

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

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

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

Подводя итоги

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