На самом деле, вопрос стоит скорее так: "почему у вас его еще нет"?
Изначально хотел просто сохранить себе и дать вам набор ссылок, что нашел на эту тему, потому что сейчас она у меня болит. Потом захотелось сделать какой то анализ. Потом понял, что письменный анализ - это долго и субъективно (и простите, чуток лень), а вам может будет полезно почитать оригиналы. И честно пытался не дублировать у себя их контент, разве что тезисно.
Поэтому статья получилась половинчатой и скорее побудительной к действиям или хотя бы к мыслям, чем с практической пользой. Не обессудьте.
Ну вот, я вас предупредил. Ссылки все равно есть, поэтому можете уверенно двигаться к их списку.
А тем кто остался, в качестве лирического отступления с практическим смыслом, я расскажу историю о своем первом знакомстве с "тестированием в продакшене". Было это лет +/-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), тоже могут пригодиться.
Кстати, такой набор инструментов - хороший вариант в качестве тестовых заданий для новых сотрудников. Когда в реальный боевой код их, по каким то причинам, еще рано пускать.
В общем, снимите шоры, включите мозг и попробуйте сделать себя и свою работу чуть лучше.
Обещанный набор ссылок про тестирование в проде и не только:
Поэтому статья получилась половинчатой и скорее побудительной к действиям или хотя бы к мыслям, чем с практической пользой. Не обессудьте.
Ну вот, я вас предупредил. Ссылки все равно есть, поэтому можете уверенно двигаться к их списку.
А тем кто остался, в качестве лирического отступления с практическим смыслом, я расскажу историю о своем первом знакомстве с "тестированием в продакшене". Было это лет +/-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), тоже могут пригодиться.
Кстати, такой набор инструментов - хороший вариант в качестве тестовых заданий для новых сотрудников. Когда в реальный боевой код их, по каким то причинам, еще рано пускать.
В общем, снимите шоры, включите мозг и попробуйте сделать себя и свою работу чуть лучше.
Обещанный набор ссылок про тестирование в проде и не только:
- Testing in production: Yes, you can (and should)
- Testing Microservices, the sane way
- How Netflix DDoS’d Itself To Help Protect the Entire Internet
- Testing in Production: How we combined tests with monitoring (Guardian)
- Testing and monitoring in production - your QA is incomplete without it
- TTR is more important than TBF (for most types of F).
- Shift Right — Testing in Production
- Observability and Monitoring
- How release canaries can save your bacon - CRE life lessons
- Видео I Don't Test Often ... But When I Do, I Test in Production
Комментарии
Отправить комментарий