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