К основному контенту

Тестирование в продакшене - миф или реальность?

На самом деле, вопрос стоит скорее так: "почему у вас его еще нет"?


Изначально хотел просто сохранить себе и дать вам набор ссылок, что нашел на эту тему, потому что сейчас она у меня болит. Потом захотелось сделать какой то анализ. Потом понял, что письменный анализ - это долго и субъективно (и простите, чуток лень), а вам может будет полезно почитать оригиналы. И честно пытался не дублировать у себя их контент, разве что тезисно.

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

Ну вот, я вас предупредил. Ссылки все равно есть, поэтому можете уверенно двигаться к их списку.


А тем кто остался, в качестве лирического отступления с практическим смыслом, я расскажу историю о своем первом знакомстве с "тестированием в продакшене". Было это лет +/-10 тому назад.

Немного технического контекста. Продукт, которым мы занимались, устанавливался в окружении у наших клиентов и занимался миграцией между их SharePoint-серверами. Пользовательский интерфейс был реализован на вебе, имел backend в виде Python-Django и мордочку лица реализованную на Javascript с элементами jQuery и YUI (сейчас не факт, что на работе кто-нибудь знает про такое). Кроме "управлялки", естественно, были отдельные сервисы (на Python) занимающиеся собственно миграциями.

При реализации фичей разработчики (у нас вообще не было тестировщиков, эххх веселое было время) активно писали автотесты. Это были и модульные (Python и Javascript), и функциональные (Python, Fitnesse-PythonSlim), и на UI (через Python вызывались методы браузера для взаимодействия с контролами).

И часть из этих тестов, достаточно большую часть (кроме, пожалуй, только Fitnesse), можно было запускать на любой машине, где был установлен продукт. Повторюсь, на любой машине. Даже у клиента 😳. Там были и тесты подпадающие под определение классических модульных (без взаимодействия с окружением) и вполне себе серьезные проверки работающие с базой.

Мне сейчас сложно уже вспомнить, парились мы над вопросом "а можно так вообще делать?" или нет, но мы просто писали нужные нам тесты и делали это таким образом, чтобы тесты не мешали друг другу (одно из важнейших правил написания тестов) и не зависели от окружения. И это давало возможность не мешать продакшену, когда эти тесты там запускались.  Дадада, это был очень простой по нынешним меркам сервис и в ваших современных сложных системах так конечно делать нельзя. Но это неточно. Просто вы про это еще не думали. 

Кто же запускал там эти тесты? Мы сами, когда приходилось чинить баги 😁
Залезаешь вместе с клиентом на сервак, разбираешься, в том числе с помощью тестов, чинишь, запускаешь тесты. Бздыньк - клиент доволен, ты делаешь этот же фикс у себя на рабочей машине, ночью собирается билд, прогоняются тесты, имеем сборку уже с этим фиксом.

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

С той поры много чего поменялось, способ доставки продукта клиенту в виде веб-сервиса, который запущен у вас, а не у клиента, стал основным. А мы все также тестируем только (или думаем что "только") в момент разработки, перед релизом, а после выкатки на прод все заканчивается. Но мир меняется и стали попадаться статьи про опыт тестирования в продакшене, про возможность тестировать то, что видит и чем пользуется ваш клиент, работать рядом с ним, на этом же окружении, в тех уже условиях. Но, почему-то, для многих это по-прежнему табу.

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

И мы боимся. Боимся, и как ежики, продолжаем лезть на кактусы.

А окружение у нас становится все сложнее, сервисы все распределеннее, количество неизвестных нам факторов влияния растет, много ресурсов тратится на дублирование продакшен-окружения, потому что где то в глубине души еще живет уверенность в том, что если я проверю на точно таком же, то проблем не будет.
А все равно будут, потому что only production is production, and every time you deploy there you are testing a unique combination of deploy code + software + environment (полная статья).

И поэтому, бинго
Твит

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

И самое смешное, на самом деле, у многих практика тестирования в продакшене уже вошла в жизнь, но они еще не в курсе.

Просто не воспринимают это, как тестирование 🙂.
оригинал тут
Правда ведь, содержимое правых колонок многие уже встречали у себя в проде? А ведь многие виды тестирования из левой колонки спокойно могут применятся и в продакшене, "переезжая" в правые.

А есть те, кто уже официально рассказывает о применении этих подходов у себя?

Да! Например, Netflix со своим Chaos Monkey превратившемся в Chaos Engineering (Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent conditions in production) или DDoS-ом самого себя.
Или Guardian, который проверяет, как работает функциональность по работе со статьями в своем проде.

Если мысль о "классическом" тестировании в проде еще не может войти в вашу голову, задумайтесь над мониторингом и наблюдением (я думаю, это будет следующей моей историей).
Внедрение этих практик тоже сильно упростит вам жизнь. А если, параллельно, вы еще подумайте над тем, как быстро вы умеете выкатывать и откатывать свои изменения в проде, то может получится система, которая лояльнее относится к вашим ошибкам: чем чаще вы делаете деплои, тем проще найти и откатить тот, который что-то ломает.
И возможно это даже проще: "уметь быстро откатывать изменения", вместо "уметь быстро их чинить" (хотя это тоже важно 🙃).
За идеями тык сюда TTR is more important than TBF (for most types of F).

Конечно, все это проще провернуть, если проблемы у себя в проде вы обнаруживаете без "помощи" ваших пользователей.

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

А можно идти дальше и расширять подходы в использовании инструментов A/B тестирования, практики "канареечных" релизов, распределяя реальный пользовательский трафик на интересующие нас версии нашего сервиса.

Возможно, те из вас, кто разрабатывает on-premises продукты спросит - ну а нам то, что делать? Подумайте ("думать - это полезно", ваш КО), что вам может помочь разбираться с проблемам на "вашем" проде, к которому у вас нет доступа, на который вы, иногда, даже не можете подложить тестовые версии бинарников. Например, помогут инструменты, которые получают нужные вам настройки окружения и продукта, и оценивают их корректность. Или инструменты позволяющие проследить прохождение команд (вызовов) между распределенными компонентами вашей системы в проде у заказчика. Какие то метрики состояния здоровья вашего сервиса, которые можно встроить в часто используемые системы (типа syslog), тоже могут пригодиться.
Кстати, такой набор инструментов - хороший вариант в качестве тестовых заданий для новых сотрудников. Когда в реальный боевой код их, по каким то причинам, еще рано пускать.

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

Обещанный набор ссылок про тестирование в проде и не только:
Ссылок на самом деле чуток больше. Тут только те, что успел переварить. Поэтому

Комментарии

Популярные сообщения из этого блога

Полезные ресурсы для молодых (и не только) тестировщиков

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе