Тестирование микросервисной архитектуры
Меня зовут Кирилл, я работаю в компании Slotegrator и возглавляю отдел QA. Наша команда занимается разработкой платформ для онлайн-казино. У этого продукта очень разнообразный функционал, который включает в себя следующие пункты:
- Модуль регистрации и авторизации;
- Пополнение баланса и отслеживание статуса;
- Подтверждение пользователей;
- Бонусный модуль и т. д.
В этой статье речь пойдет о том, как нам удалось преодолеть трудности благодаря переходу на микросервисную архитектуру и как происходит процесс ее тестирования.
Как все начиналось?
В начале моей карьеры в Slotegrator, наша команда из 30-ти человек работала с 5-6 клиентами. И этого было достаточно, чтобы создавать платформу на PHP-монолите. То есть, она была построена как единое целое, где вся логическая обработка запросов помещалась внутрь одного процесса.
Но, со временем, наша компания значительно расширила свою клиентскую базу и разрабатывать платформу на монолите PHP стало не удобно, поскольку пожелания клиентов стали разнообразными и каждый хочет создать свою уникальную платформу.
У монолита модульная структура, которая включает в себя различные модули. Между этими модулями очень сильная связь, поэтому любое изменение одного из них отражается на функционировании всего приложения. При любом обновлении необходимо было выполнить множество команд. И самым большим недостатком в этом являлось то, что мы не могли выполнить обновления быстро.
Архитектура нашего продукта включает в себя следующие пункты:
- интерфейс пользователя;
- серверная часть, которая отвечает за бизнес-логику приложения;
- доступ к данным;
- база данных.
В монолитных приложениях очень ограниченная гибкость, т. к. в одном монолитном блоке объединены все модули и при разворачивании код находится на одном сервере. Таким образом, каждое небольшое обновление или изменение требует полного повторного развертывания новой версии всего приложения.
Работая с монолитом, у нас возникали сложности с масштабированием части приложения, поэтому мы были вынуждены делать это для всего приложения.
Например, запрос касательно игрового функционала происходит значительно чаще, нежели изменение контактных данных или просмотр новостей. В данной ситуации, необходимо было бы уделить этой функции больше внимания, но работая в монолите это просто невозможно. Чтобы обновить новую версию приложения, нужна большая команда, которая будет полностью соответствовать выбранной архитектуре. Однако, такой командой будет очень трудно управлять. В эту команду должны входить специалисты, которые проектируют пользовательский интерфейс, отдельные специалисты по бизнес-логике, базе данных и так далее. Тем не менее все эти команды должны полностью разбираться и уметь работать со всеми бизнес-функциями.
Почему микросервисы?
После того как наша команда столкнулась с рядом проблем, мы решили перейти на микросервисную архитектуру.
Миксервисная архитектура отличается от монолитной тем, что приложение создается как небольшие и независимые компоненты, которые можно развертывать, разрабатывать и поддерживать автономно друг от друга. Безусловно, здесь также есть свои трудности и подводные камни.
Увеличение количества небольших независимых сервисных единиц приводит к возрастанию операционной сложности. Поскольку невозможно обрабатывать десятки услуг без автоматизации их тестирования и развертывания, увеличивается роль непрерывной интеграции и доставки. Из-за технологического разнообразия сервисов возникают повышенные требования к мониторингу.
Однако, нам удалось преодолеть все эти трудности. Мы приобрели огромное количество новых знаний и навыков, а также овладели новыми инструментами.
И благодаря правильной организации работы у нас получилось обеспечить полноценное сотрудничество программистов, тестировщиков, разработчиков и других участников процесса. Это значительно ускорило процесс разработки платформы.
Тестирование микросервисов
Процесс тестирование микросервисной архитектуры значительно отличается от обычного. Микросервисная архитектура — это совокупность небольших сервисов, где каждый из них обслуживает одну бизнес-задачу. В целом эти небольшие сервисы являются готовым приложением и решают основную задачу.
Эти сервисы находятся на разных серверах и написаны на различных языках программирования, таких как Java и.Net. Однако, это также является и недостатком, поскольку разработчики определенного микросервиса практически не знают, что делают остальные микросервисы. Таким образом, это делает процесс тестирования не из легких.
Тем не менее у нас есть возможность обновить отдельный микросервис быстро и протестировать его не затронув другие.
- unit-тестирование;
- контрактное тестирование;
- интеграционное тестирование;
- end-to-end тестирование;
- нагрузочное тестирование;
- UI- или функциональное тестирование.
Теперь рассмотрим подробнее все виды тестирования.
Unit-тестирование
Unit-тестирование (модульное тестирование) — это вид тестирования ПО, позволяющий проверить корректность отдельных модулей или компонентов программного обеспечения. Цель: проверка того, что каждая единица программного кода работает корректно.
Unit-тестирование бывает двух видов:
- позитивное (проверить поведение методов в нормальных условиях);
- негативное (проверить устойчивость системы к нештатным ситуациям).
Когда мы подходим к этапу разработки функционала, девелоперы самостоятельно пишут Unit-тесты, так как каждый из разработчиков лучше знает и понимает работу своего кода, и может лучше выполнить эту задачу, чем тестировщики.
Мы покрыли 70% функционала unit-тестами, и поскольку используем CI/CD, то не можем развернуть приложение, пока они не пройдены.
Контрактное тестирование
У нас работают над микросервисами несколько команд:
- бэкенд;
- фронтенд;
- тестировщики.
Чтобы понимать какой ендпоинт и в каком формате отдаёт и принимает данные, мы договариваемся между собой. Для этого, используем контракт между командами, который называется Pact. Он содержит в себе все методы и возвраты всех сервисов.
Контрактное тестирование подразумевает отношение к микросервису, как к черному ящику. Оно нацелено на то, чтобы мы могли убедиться, что все работает так как надо. Если одна из схем работает не по пакту, это считается дефектом.
Наша команда работает с контрактным тестированием следующим образом: мы получаем ТЗ, которое согласованно со всеми стейкхолдерами. Согласно техническому заданию, мы оцениваем задачи и создаем схему работы.
Интеграционное тестирование
Во время интеграционного тестирования проверяется, насколько корректно разные микросервисы взаимодействуют друг с другом. Этот вид тестирования считается самым критичным тестом всей архитектуры. При положительном исходе тестирования мы можем быть уверены, что она спроектирована правильно, и все независимые микросервисы работают как единое целое в соответствии с ожиданиями.
End-to-end тестирование
E2E тестирует бизнес-логику подобно процессу тестирования в интеграционном, но уже не изолированно, а в масштабе всей системы.
В end-to-end тестировании проверяется, как взаимодействуют все сервисы c платформой:
- регистрация;
- авторизация;
- игровая деятельность;
- пополнение и снятие денежных средств.
То есть мы проверяем насколько соответствует все приложение запросам заказчика.
Нагрузочное тестирование
Процесс нагрузочного тестирования формально делится на 4 этапа:
- тестирование производительности (Performance Testing);
- тестирование стабильности или надежности;
- стресс-тестирование;
- объемное тестирование (Volume Testing).
Для тестирования, мы используем JMeter, а сами нагрузочные скрипты написаны на Groovy.
Также, мы используем около пяти виртуальных машин, развернутых на AWS и у нас есть 7 физических машин. Физические машины, мы используем если нам необходимо создать большую нагрузку от 15,000 RPS и более. Виртуальные машины такие показатели дать не могут, поскольку каждый запрос необходимо отправлять с подписью шифрования, вследствие чего процессор сильно нагружается. Поэтому, мы используем виртуальные машины только для фоновой или статической нагрузки — 2000 RPS.
Что касается статистики, мы её собираем в Grafana. После чего, мы анализируем все показатели, такие как нагрузка на CPU, GPU, сеть, диски и т. д.
UI- или функциональное тестирование
Это итоговый вид тестирования. Мы тестируем практически все то же самое, что и при end-to-end тестировании, но только с использованием UI. Мы проводим UI тестирование мануально и также делаем автотесты.
Вывод
У микросервисной архитектуры есть свои плюсы и минусы, поэтому она подойдет не всем. Все зависит от продукта, который вы разрабатываете. Для небольших приложений, которые редко обновляются, достаточно использовать монолит. Мы пришли к использованию микросервисной архитектуры, потому что у нас расширялся и функционал приложения. Несмотря на все трудности, для нашего проекта использовать микросервис — это преимущество. Теперь нам значительно легче внедрять что-то новое, развиваться и улучшаться.
end-to-end
pl стр. эндсы, дилены;
to be on the end of a line попасться на удочку;
to make both (или two) ends meet сводить концы с концами end амер. аспект, сторона;
the political end of (smth.) политический аспект( чего-л.)
конец, смерть;
he is near(ing) his end он умирает
кончать;
заканчивать;
прекращать;
to end all wars положить конец всем войнам;
to end one’s life покончить с собой
кончаться, завершаться (in, with) ;
to end in disaster окончиться катастрофой;
the story ends with the hero’s death рассказ кончается смертью героя
результат, следствие;
happy end благополучная развязка, счастливый конец;
it is difficult to foresee the end трудно предвидеть результат
цель;
to that end с этой целью;
to gain one’s ends достичь цели;
ends and means цели и средства
амер. часть, отдел;
the retail end of a business отдел розничной торговли
pl стр. эндсы, дилены;
to be on the end of a line попасться на удочку;
to make both (или two) ends meet сводить концы с концами
кончать;
заканчивать;
прекращать;
to end all wars положить конец всем войнам;
to end one’s life покончить с собой
кончаться, завершаться (in, with) ;
to end in disaster окончиться катастрофой;
the story ends with the hero’s death рассказ кончается смертью героя the
justifies the means цель оправдывает средства;
any means to an end все средства хороши
of data вчт. конец данных
of financial period конец отчетного периода
of financial year конец финансового года
of month конец месяца
of period конец периода
of previous financial year конец предыдущего финансового года
конец;
окончание;
предел;
end on концом вперед;
to put an end to (smth.), to make an end of (smth.) положить конец (чему-л.), уничтожить (что-л.)
кончать;
заканчивать;
прекращать;
to end all wars положить конец всем войнам;
to end one’s life покончить с собой to the bitter
до предела, до точки;
до последней капли крови;
to keep one’s end up сделать все от себя зависящее;
не сдаваться;
end to end непрерывной цепью
up оканчиваться, прекращаться, обрываться
цель;
to that end с этой целью;
to gain one’s ends достичь цели;
ends and means цели и средства
край;
граница;
ends of the earth край земли;
глухомань;
the world’s end край света
of file, EOF вчт. конец файла on
беспрерывно, подряд;
for two years on end два года подряд
цель;
to that end с этой целью;
to gain one’s ends достичь цели;
ends and means цели и средства
результат, следствие;
happy end благополучная развязка, счастливый конец;
it is difficult to foresee the end трудно предвидеть результат happy:
счастливый;
happy man! счастливец!;
happy end счастливый конец (романа, фильма и т. п.) ;
as happy as the day is long очень счастливый
конец, смерть;
he is near(ing) his end он умирает no
в заключение;
в конечном счете;
they won the battle in the end в конечном счете они добились победы
результат, следствие;
happy end благополучная развязка, счастливый конец;
it is difficult to foresee the end трудно предвидеть результат to the bitter
до предела, до точки;
до последней капли крови;
to keep one’s end up сделать все от себя зависящее;
не сдаваться;
end to end непрерывной цепью laid
конец;
окончание;
предел;
end on концом вперед;
to put an end to (smth.), to make an end of (smth.) положить конец (чему-л.), уничтожить (что-л.)
pl стр. эндсы, дилены;
to be on the end of a line попасться на удочку;
to make both (или two) ends meet сводить концы с концами no
obliged to you чрезвычайно вам признателен no
of разг. много, масса;
no end of trouble масса хлопот, неприятностей no
of разг. прекрасный, исключительный;
he is no end of a fellow он чудесный малый;
we had no end of a time мы прекрасно провели время no:
end of очень много, множество;
we had no end of good time мы превосходно провели время no
of разг. много, масса;
no end of trouble масса хлопот, неприятностей normal
беспрерывно, подряд;
for two years on end два года подряд on
стоймя;
дыбом end амер. аспект, сторона;
the political end of (smth.) политический аспект (чего-л.) position
позиция на конец месяца
конец;
окончание;
предел;
end on концом вперед;
to put an end to (smth.), to make an end of (smth.) положить конец (чему-л.), уничтожить (что-л.)
амер. часть, отдел;
the retail end of a business отдел розничной торговли
кончаться, завершаться (in, with) ;
to end in disaster окончиться катастрофой;
the story ends with the hero’s death рассказ кончается смертью героя
цель;
to that end с этой целью;
to gain one’s ends достичь цели;
ends and means цели и средства to:
prep указывает на цель действия на, для;
to the rescue на помощь;
to that end с этой целью in the
в заключение;
в конечном счете;
they won the battle in the end в конечном счете они добились победы to the bitter
до предела, до точки;
до последней капли крови;
to keep one’s end up сделать все от себя зависящее;
не сдаваться;
end to end непрерывной цепью no
of разг. прекрасный, исключительный;
he is no end of a fellow он чудесный малый;
we had no end of a time мы прекрасно провели время
край;
граница;
ends of the earth край земли;
глухомань;
the world’s end край света year
End to end что означает
В 2014 году Фредерик Лалу, консультант, коуч и фасилитатор, выпустил книгу «Открывая организации будущего», в которой предположил, что все организации можно поделить на 5 типов. Каждый тип для наглядности получил свой цвет: красный, янтарный, оранжевый, зеленый и бирюзовый. Не буду подробно рассказывать всю теорию, остановлюсь на нескольких основных примерах.
«Красная» система представляет собой организацию, где есть вождь и его племя, ведущие борьбу с враждебным миром и другими такими же организациями. «Янтарный» уровень предполагает иерархию, где все подчиняются скорее не одному человеку, а жестким неизменным правилам. Большинство корпораций сегодня находятся на следующем, «оранжевом» уровне. В них уже нет правильного и неправильного, а есть эффективное и неэффективное. У сотрудников появляются ответственность и контроль за ситуацией вместо обязанности слепо исполнять приказы.
В «зелёных» организациях отношения внутри группы и общие ценности команды важнее выгоды. Миссия такой компании — быть новаторами. Все вместе они хотят изменить мир, и каждый член команды верит, что делает это своим вкладом в большое дело. Долгое время именно эта стратегия считалась самой современной и выигрышной, однако Лалу заметил, что компании, выбирающие этот путь, не всегда становятся успешными и умеют зарабатывать.
Так появилась новая ступень — то самое «бирюзовое» управление. Оно состоит из трех основных принципов: самоуправление, целостность и эволюционная цель. Ее отличие от «зеленой» в том, что каждый сотрудник видит в работе не только общую миссию компании — изменить мир — но и отлично понимает свое место и цели компании, на которые он влияет. В ней еще больше свободы и ответственности на каждом члене команда. Это та самая модель, к которой сегодня стремятся современные digital-компании, и мы в «Манго Страхование» в этом смысле не исключение.
Однако стартануть сразу «бирюзовыми» не так-то и просто. Это такое золотое Эльдорадо, куда все стремятся прийти, но для этого все сотрудники, а особенно лидеры, должны очень хорошо понимать особенности бизнеса, быть самостоятельными и ориентированными на результат. Чтобы стать «бирюзовыми», люди в каждой команде должны не только вырасти, но еще и сработаться между собой.
Наша компания сейчас зависает где-то между «зелёной» и «бирюзовой» организацией. Я бы сказала, что мы ближе к «зелёной» компании с «бирюзовыми» вкраплениями.
Наша иерархия сейчас выглядит следующим образом:
- Топ-менеджмент состоит из пяти человек, его возглавляет фаундер Виктор Лавренко. Я отвечаю за продуктовую разработку, генеральный директор Павел Конев — за всю страховую часть, CMO Диана Акчурина — за бренд и продвижение, CFO Елена Колесник — финансы и бухгалтерия. У каждого своя зона ответственности.
- End-to-end команды — это костяк, где находится большая часть сотрудников. В каждую команду входят продакт-менеджер, менеджер по маркетингу, разработчики и представитель службы заботы о клиентах.
- Дизайн-команда временно вынесена за пределы end-to-end команд, чтобы навести порядок в наших коммуникациях. Через какое-то время, когда будет выработан фреймворк работы дизайнеров, они вернутся обратно в команды.
- Команда цифровых коммуникаций, которая ведет наши соцсети, блог и несет миру знание о нас и о ценности современного страхования.
- Cлужба заботы о клиентах — это лицо и голос компании. Задача ребят — максимально оперативно и дружелюбно решать любые проблемы пользователей.
Топ-менеджмент не руководит командами, а выступает кураторами. Это очень важно для понимания уровня ответственности и свободы внутри компании. Причем в разный период времени за нами закреплены разные команды. Допустим, в команде «Страхование животных» в этом квартале нужно усилить диджитал часть — тогда я беру их себе в кураторство и помогаю разобраться. Если нужно подтянуть страховую часть — подключается директор Паша Конев. Все зависит от целей команды в тот или иной период времени.
KPI: ставить или не ставить?
По моему мнению KPI (ключевой показатель эффективности) уже устарел. Мы используем OKR (objective and key results) — это другая методология, которая предполагает более гибкое отношение к целям. Строится она на том, что вся компания имеет стратегический бизнес-план примерно на пять лет, в котором очень крупными мазками написано, каких показателей мы хотим достигнуть в долгосрочной перспективе: сколько денег заработаем, сколько клиентов привлечем. Там же обязательно есть миссия и позиционирование по ключевым вопросам. Условно, что мы делаем и не делаем, в какие отрасли идем, а в какие нет.
Следующим уровнем идёт уже OKR компании на год. Их разрабатывают топ-менеджеры, обсудив с лидерами команд. Мы получаем обратную связь и совместно, в несколько итераций, добиваемся общих целей с конкретными метриками. Глядя на общий OKR, команды рисуют свои цели на квартал, синхронизируются с друг другом и согласовывают с нами. Мы, менеджеры борда, отвечаем за общую стратегию и процессы в компании. Ответственность же за достижение целей лежит на лидерах команд.
Для контроля достаточно двух регулярных мероприятий: еженедельная планерка и ежемесячная отчетная встреча на всю компанию, которая у нас называется «Царь-Демо». Команды делятся друг с другом проделанной работой и результатами, получают обратную связь и с нашей помощью корректируют планы.
Больше свободы и ответственности
По опыту работы в «Альфа-Банке» я могу сказать, что в крупных компаниях продуктовые команды хоть и пытаются работать более-менее автономно, все равно отвечают за локальный набор метрик. Например, за скачивание приложения или конверсию. То есть они почти никогда не отвечают за общий результаты, такой как привлеченные клиенты или прибыль. Мы осознанно заносим эту ответственность внутрь команды, чтобы продакты всегда держали в голове юнит-экономику и продумывали, как каждое их решение влияет на цели компании.
Такой подход дает больше ответственности и свободы. Лидеры команд сами распоряжаются своим бюджетом на маркетинг. Обычно это происходит так: продакт продумывает, какой бюджет им будет необходим на следующий квартал, приходят со своим маркетологом на собрание по согласованию бюджета. Мы даем обратную связь. Иногда говорим, что это слишком дорого или наоборот не слишком амбициозно и стоит подумать еще, а иногда согласовываем сразу.
Кроме того, мы стремимся, чтобы у каждого лидера команды была ответственность и за людей внутри: за их найм, зарплаты, мотивацию и прочее. В идеале руководитель команды должен уметь сам увольнять и нанимать сотрудников. Мы хотим создать мини-CEO внутри каждой команды. Это один из шагов в сторону «бирюзовой» организации. Но пока для самих людей тяжело принять на себя много свободы и ответственности одновременно.
Если мы видим, что человек справляется с наймом людей, он этим занимается. Если же ему пока тяжело, мы не будем настаивать и оставим за собой эту функцию. Например, разработчиков в команды пока еще помогаю набирать я, а вот маркетологов ребята уже ищут и собеседуют сами под присмотром CMO.
Где найти ответственных людей
Обычно на этапе собеседования уже видно, насколько человек радуется той структуре компании, которую мы описываем. Реакция соискателя многое говорит о том, впишется он в команду или нет. Люди с бизнес-мышлением, например, продакты или маркетологи, обычно счастливы получить свободу. А вот исполнители, привыкшие работать по указке сверху, зачастую теряются. Это важно обнаружить как можно раньше, поэтому финального кандидата у нас собеседуют несколько людей с разным бэкграундом.
По поиску людей круче всего работает нетворкинг — когда текущие сотрудники зовут своих знакомых, друзей и бывших коллег.
Сейчас у нас почти половина сотрудников как раз те, кого привели наши текущие работники. Это создает общий культурный фон, который тоже крайне важен.
Важно быть готовым к тому, что своих сотрудников придется растить, так как даже самый крутой профессионал может не сразу быть готовым ко всему спектру ответственности. Однако такие вложения для стартапа лишь плюс. Со временем сотрудник, который развивается вместе с компанией, станет вашим лояльным, ответственным и заинтересованным партнером, а не просто наемным работником.