Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Привет! Меня зовут Андрей, я head of platform в финансовом маркетплейсе Банки.ру.
Для создания своих продуктов мы применяем микросервисный подход. Он помогает нам ускорить разработку и делает ее гибкой и управляемой. Но как в любом подходе, у него есть темная сторона, проявление которой может создать кучу неприятностей и осложнить работу над проектом. Сегодня хочу поговорить об одном из таких аспектов — о сервисах-«сиротах» (так мы их ласково называем в Банки.ру, поэтому дальше кавычки ставить не буду).
Эта статья – оптимистичное и структурированное продолжение моего доклада на ту же тему, с которым я выступал в 2018 году. Текстовая версия есть на Хабре.
Годы взаимодействия с разномастными сиротами помогли их классифицировать, поэтому захотелось уделить больше внимания тому, какие сироты бывают, чем они опасны или хороши (такое тоже случается), каких нужно возвращать в семью, а от каких отказываться. Чтобы было зрелищнее и веселее, использовал образы и иллюстрации из мира «Гарри Поттера» в целом и «Фантастических тварей» в частности, прошу понять и простить. Права на изображения незыблемо принадлежат братьям Уорнер – и всё такое.
Какие качества определяют сервис-сироту
Каждому сервису нужен хозяин: команда, которая будет поддерживать, развивать сервис, наращивать экспертизу. Если такого хозяина нет — предыдущие владельцы уволились, перешли на другой проект и не передали сервис в ведение другой команды — поздравляю, у вас «сиротянка».
Как узнать сервис-сироту:
никто не знает, как он работает
у сервиса нет проекта или команды, а если есть, любые задачи, с ним связанные, демотивируют сотрудников и к результату не приводят: прокрастинация, переползание из спринта в спринт и переоценка приоритетов.
Какие фантастические твари встречаются в закоулках сложных проектов больших компаний
Жабы.
К этому типу мы относим сервисы:
с устаревшим фреймворком;
со специфическими требованиями к железу или операционке;
с зависимостью от библиотек, которые вообще не поддерживаются либо поддерживаются командами, не вшущающими доверия;
требующие сложной, а, следовательно, дорогой поддержки.
Откуда берутся жабы?
Чаще всего, конечно, «исторически сложилось». Иногда жаба становится результатом партизанской разработки, когда сервис создает product owner или разработчик в обход общепринятых технических требований. Случается, что жабы приносят аутсорс-команды, которые реализуют сервисы по требованиям бизнес-департаментов. Такой сервис добавляется в текущий стек, а про его поддержку забывают.
Иногда это может быть следствием покупки старого конкурента или стартапа, который работает на своем особенном стеке.
Порой мы побеждаем в bullshit-bingo, когда случается все одновременно: старый сервис-аутсорсер разорился, команда поддержки разбежалась, продукт выгорел и уехал в Тибет… Короче, концов не найти.
Жабы не всем нравятся, но обычно безобидны. А вот…
…Оборотни — не очень
Сервис с непопулярным языком или фреймворком, для него требуется компетенции поддержки, которых нет в команде, и особая инфраструктура. Оборотни могут преподносить сюрпризы, появление которых логически необъяснимо, а спрогнозировать такой «черный лебедь» может разве что хороший астролог, следящий за фазами луны и положением Меркурия на небосклоне (на самом деле – конечно, нет).
Откуда берутся оборотни?
Мой любимый портал: CV Driven Development. Разработчик захотел попробовать новый фреймворк или язык программирования. Или, может быть, он просто непризнанный гений со своим уникальным подходом к решению задачи. Такой сервис выкатывают на прод, включают в мониторинг, но как его поддерживать — непонятно.
Покупка молодого конкурента тоже часто приводит к появлению оборотней. Например, для продукта используется код, который, по-хорошему, нужно переписывать под особенности нашего стека и команды, но так делают не всегда. Особенно если этот продукт продвигает бизнес, сервис уже генерирует деньги, а остановка приведет к потерям и усложнит бизнес-процессы. При этом развивать его нужно, но мы не знаем, как.
Оборотень может появиться после использования технологии из «кровавого энтерпрайза». Так я называю проприетарные решения, которые требуют для сопровождения выделенного подразделения, иногда даже «арендуемого» у вендора.
Наличие оборотней в инфраструктуре приводит к появлению «задач-волков», которые постоянно вас «кусают», просят внимания и мешают двигаться вперед. Они доставляют неприятности с завидной регулярностью, но переписывать их слишком долго и дорого, поэтому приходится с ними жить. Отмечу, что приличная часть рисков «оборотней» проявила себя в прошлом году: прекращение поддержки и обновлений, отсутствие возможности продлить или купить лицензию. В результате можно было получить либо полностью нерабочую систему, либо стремительно деградирующий и опасный сервис.
От опасных тварей перейдем к красивым.
Фениксы
Сервис такого типа прекрасен и таинственен. Как правило, он стабильно работает, поднимается сам, отлично справляется с задачами, а любые проблемы решаются перезагрузкой. Это его прекрасная часть.
Таинственная — непредсказуемость. Развивать такой сервис невозможно. Даже если вы скрупулёзно изучите код, понятней не станет.
Если у вас есть сервис, который лечится перезагрузкой — отлично. Важно только учитывать, что если в какой-то момент перезагрузка не поможет (феникс не возродится), а ресурсов для восстановления так и не найдется, нужно будет быстро написать что-нибудь на коленке, чтобы поддержать бизнес. Факел зажечь, дракона нанять — в общем, проявить фантазию.
Как появляются фениксы?
Примерно так же, как и оборотни, только в отличие от последних, с фениксами вам повезло: «Играл в bullshit-bingo, проиграл».
Со странными существами я закончил, перейдем к более разумным.
Домовые эльфы
Хорошо и ответственно делают свою работу, понятно масштабируются и поддерживаются, но есть нюанс: изменились бизнес-приоритеты, команду у сервиса забрали – и эльф остался без хозяина. Ну, спасибо хоть не подарили одежду!
В отличие от предыдущих «коллег», домовой эльф умеет разговаривать: документация понятна, достаточна и актуальна, а логи и алерты содержат в себе рецепты лечения проблем.
Риски сервисов-сирот
В чем риски сервисов-сирот, даже если они за добро, как эльфы или фениксы?
«Дыры» в безопасности или функциональности: уязвимости, которые могут быть вызваны старыми версиями фреймворков, ОС, зависимостями.
Неожиданный отказ и аффект на другие продукты.
Сервис может сам по себе упасть, тогда функциональность будет нарушена. А может заодно потянуть связанные с ним процессы — тогда проблем будет больше.
Вечная диагностика проблем, отвлечение ресурсов, проблемы копятся, но никто с ними толком работать не может. Если откладывать решение этой задачи, диагностика не закончится никогда.
Ресурсов тратится больше, чем этот сервис по итогу вам приносит.
В качестве иллюстрации расскажу случай из жизни. Мы использовали сервис на .NET, чтобы получать и агрегировать данные из большого экселя. Сервис работал, но иногда с треском ломался и ждал шамана с бубном. Когда мы посчитали затраты на инфраструктуру и прибыль, которые он приносит, выяснили, что требует он гораздо больше, чем дает.
В результате мы просто отказались от этой интеграции и стали крепче финансово и технически.
Что делать с сиротами
В 2018-2019 году у нас начался увлекательный крестовый поход против сервисов сирот. Мы обнаружили три десятка сирот, двадцать с лишним за полгода закрыли, 8 нашли новых хозяев. Эльфов и фениксов мы одомашнили и обогрели, оборотней и жаб изгнали обратно в дикую природу.
Довольно яркий пример – наше старое мобильное приложение, которое было разработано в 2018 году сторонней компаний. Поначалу оно было похоже на «жабу», использовало php-микросервис для кэширования api-запросов. Однако потом мы распознали настоящего оборотня: поскольку некому было следить за этой парочкой, иногда сервис кэширования под нагрузкой «ронял» нам разделы приложения. Результат: 1-2 звездные отзывы в сторах и испорченная репутация. Приложение сняли, кэширование забэкапили и погасили, чтобы освободить место под солнцем для уже собственной разработки мобильного приложения.
Примерный план:
Собрать список сироток.
Оценить влияние, расходы и риски.
Лучше всего составить таблицу, из которой будет понятно, какой функционал выполняет сервис, на что влияет, какие риски несет в случае падения, сколько стоит инфраструктура и поддержка, есть ли потенциальные штрафы за падение работоспособности самого сервиса и тех, кто с ними связан.
Если станет понятно, что выгоды от использования превышают расходы или хотя бы балансируют — такой сервис стоит одомашнить. В противном случае — избавиться от него и создать новый.
Можно ли предупредить появление сирот?
Короткий ответ: конечно, у монолитных приложений таких проблем нет!
Но, кажется, большинство пойдет по сложному пути: в любом большом проекте, где больше одного разработчика, сироты заводятся постоянно и полностью остановить этот процесс невозможно.
Один из способов ограничить возникновение сирот – ставить жесткие рамки по использованию стека технологий.
Мы пробовали применять такой подход, но он нам не подошел. Во-первых, он совсем не «бирюзовый», в отличие от нашей компании (не во всех аспектах пока что, но много где). Свобода в разработке приводит не только к созданию сервисов-сирот, но и крутых продуктов и прорывных решений, отказываться от которых глупо. Во-вторых, ограничения все равно приведут к партизанской разработке, когда жёсткие рамки не позволят вовремя спасти мир, и разработчик сделает так, как ему удобно.
Мы подошли к решению проблемы иначе. Стали использовать так называемый «паспорт сервиса». Это стандарт описания, функций, конфигурация, особенностей эксплуатации. В таком паспорте, в числе прочего, содержится информация о связях и влиянии на другие сервисы, технических и финансовых рисках. Правда, и здесь есть сложность: с течением времени эти показатели могут меняться, а поддерживать информацию актуальной сложно.
И, чего греха таить, рост количества сервисов частенько характеризуется пропуском этапа создания паспорта вообще по самым разным причинам. Но с этим мы тоже боремся — автоматизируем учет сервисов.
Еще один способ избавления от сирот: регулярные апдейты используемых сервисов. Каждый год мы обновляем кубер-кластер. Вместе с этим обновлением заново деплоим сервисы: проводим большое ревью, оцениваем, какие сервисы принимают трафик, а какие нет. В зависимости от результатов часть из них не выкатываем обратно на прод.
Поэтому, конечно, у нас периодически заводятся сироты, но большая часть из них на проде не работает.
Подводя итоги
Темные стороны есть у любого подхода – важно их знать и признать, чтобы снизить риски и управлять силой лучше. В нашем случае работают паспорта сервиса и регулярное ревью всех используемых сервисов. Эту работу мы автоматизируем, но это уже другая история… И пока мы ее пишем, подписывайтесь, ставьте лайки и делитесь опытом в комментариях.
