Прод и дев что это
Среды, код и релизы
Лучшие практики по именованию и разграничению сред в соответствии с их предназначением, взаимному соответствию сред и ветвей кода, и процессу выпуска.
Именование сред
Разработки [dev] — та среда (база данных, сайт, ВМ и т.д.), где развёртываем свежий код и смотрим, что получается.
Демо [demo] — тут промежуточный результат показывается заказчику. Пока развёрнутый здесь полуготовый функционал ждёт внимания заказчика, на [dev] можно всё сломать, работая дальше.
Тестовая [test] — тут тестируется функциональность. Среда наполнена тестовыми данными, которые могут отражать редко возникающие (в рабочей среде) случаи или быть удобными для тестирования. Пока тут идёт тестирование того, что готовится в продакшен, на [dev] уже появляется код следующего релиза.
Промежуточная [stage], она же предпродакшен — тут тестируется развёртывание. Сюда развёртывается последний бэкап системы из продакшена, чтобы проверить обновление на версию.
Продакшен [prod] — тут работают пользователи.
Связь с кодом
В зависимости от системы бывает, что код идёт в развёртывание вместе с конфигурацией (набором переносимых настроек). При этом, сам код ведётся в репозитории, а конфигурация в среде.
Изначально, код, попадающий в ветвь /dev, выкатывается в среду [dev], где настраивается конфигурация к нему. Затем, код и конфигурация (иногда по частям) переносятся в другие среды.
Путь кода
То, что исправляется в /main при тестировании, естественно → /dev.
Путь конфигурации
[dev] → экспорт в репозиторий отдельно от кода.
Ошибки проектирования систем
Рассмотрим, что в архитектуре системы может сделать невозможным гладкий выпуск.
Двусторонняя зависимость
Бывает, что часть конфигурации зависит от кода (нельзя настроить, пока не выкатится какая-либо сборка), но часть кода зависит от конфигурации (это код, который опирается на структуры в базе данных, которые создаются конфигуратором, либо на сборки, которые собираются конфигуратором).
То, что делает путь релиза таким трудным или уникальным — ошибка архитектуры. Её совершают из побуждений «сделать что-то автоматическим», закладывая возможность в единый конфигуратор системы, вместо того, чтобы закладывать в более низко-уровневые инструменты, или «получить быстрый результат», используя такую возможность.
Бывает, что в покупной системе есть несколько путей создания вещей, таких как структуры данных или объекты. Например, в ELMA-BPM есть создание объектов через конфигуратор, а есть через плагин к Visual Studio. Выбирайте более низко-уровневый способ, иначе попадёте на описанную двустороннюю зависимость.
Логика в базе данных
Переразвернуть базу данных гораздо сложнее чем пересобрать код.
Из-за этого, в системах, где много логики в базе, разработчики работают на одном общем экземпляре БД. Обычно они говорят, что им нужна общая БД для разработки, так как: а) там всегда развёрнут последний код от каждого из них и б) там готовы тестовые данные.
Из-за постоянной работы в общей базе (читай «среде»), в свою очередь, теряется смысл ветвления кода в репозитории.
В итоге, от /dev бессмысленно отделять ветви фич, что, в свою очередь, не позволяет выделять длинные работы и делать релизы независящими от них.
Кроме того, поскольку перенос из среды в среду (ибо это из базы в базу) сложнее, количество сред в процессе пытаются сократить, не выходя за [dev] → [stage] → [prod] (а то и [dev] → [prod]). Тестируют и демонстрируют функционал прямо на [dev].
Логика в БД сегодня, это ошибка архитектуры (по многим причинам), которую, наверное, мало кто будет отрицать (хотя случается и такое). В данном случае, это ограничение для повышения качества и сокращения цикла выпуска.
Что такое среды разработки dev, r/c и prod?
Что такое визуальные компоненты среды VS?
Приветствую. Являются ли компоненты которые предлагает VS, такие как dataGridView, едиными для.
Что такое алгоритм разработки приложения?
Скажите пожалуйста что такое Алгоритм разработки приложения.. И напишите любой пример.Спасибо.
Найти такое наименьшее n, что сумма 1/i больше заданного А (Dev-C++)
Здравствуйте уважаемые господа, взываю к вашей помощи, вот условие задачи: Дано действительное.
Смысл /dev/shm. Что это такое, и вообще, какое отношение имеет к RAM?
По умолчанию в Red Hat (Centos) начиная с 6-ой версии выделяется 50% до ОЗУ под раздел /dev/shm.
Понятия происходят от жизненного цикла разработки программного обеспечения.
Каждому этапу в контексте вашего вопроса соответствует своя среда.
Среда разработки может характеризоваться наличием отдельно стоящей версии backend, отдельного инстанса базы данных.
Что такое APEX? Преимущества использование этого средства разработки сайтов
Пользовались ли вы когда-нибудь APEX? Не могли бы вы назвать главные преимущества и недостатки.
Среды разработки
Столкнулся с проблемой, большинство учебников, предполагают что вы(я) пользуетесь Microsoft Visual.
Промежуточная среда против производственной среды
Значение dev интуитивно понятно: это среда, используемая при разработке приложения.
В чем разница между промежуточной и производственной средой?
Для небольших компаний (неясно, насколько велика ваша), три среды (dev, stage, production) являются общими. Более крупные компании часто имеют среду QA между dev и stage.
Они обычно разбиваются следующим образом:
dev : копия рабочего кода. Здесь вносятся изменения, внесенные разработчиками, чтобы можно было проверить интеграцию и возможности. Эта среда быстро обновляется и содержит самую последнюю версию приложения.
QA : (не все компании будут иметь это). Среда для обеспечения качества; это предоставляет менее часто измененную версию приложения, с которой тестеры могут выполнять проверки. Это позволяет создавать отчеты по общей ревизии, чтобы разработчики знали, исправлены ли конкретные проблемы, обнаруженные тестировщиками, в коде разработки.
staging : это кандидат на выпуск, и эта среда обычно является зеркалом производственной среды. Промежуточная область содержит «следующую» версию приложения и используется для окончательного стресс-тестирования и утверждения клиента / менеджера перед началом работы.
производство : это текущая версия приложения, доступная для клиента / конечных пользователей. Эта версия предпочтительно не меняется, за исключением запланированных выпусков.
Я немного удивлен, что тестовая среда также отсутствует, как место, куда должен идти код, прежде чем перейти в стадию.
Чтобы ответить на вопрос:
Сценическое окружение должно максимально отражать производственную среду.
Как отмечает @Oded, обычно для тестирования кода используется среда QA, которую тестировщики QA используют.
Мой опыт работы с правительством США / министерством обороны США заключается в следующем:
Балетмейстер : среда настроена для размещения предвыпускных заявок после объявления замораживания кода. Он нацелен на руководителя проекта / владельца вместе с командой разработчиков, чтобы согласовать сферу действия кандидата на выпуск. Он включает обеспечение качества, а также команду разработчиков, чтобы сделать окончательные исправления и окончательную отделку перед выпуском в производство. Рекомендуется имитировать производственную среду, используя самые последние данные из оперативной базы данных, скопированные из производственной среды. Как правило, промежуточная среда доступна только внутренней команде и заинтересованным сторонам, поэтому она либо защищена на общедоступном сервере, либо опубликована в среде интрасети, если все заинтересованные стороны могут получить доступ к локальной сети. Промежуточная среда настроена для отображения средних или полных технических ошибок.
Разработка : Частная среда, сконфигурированная одним разработчиком на своей машине для проверки своей работы во время цикла разработки, обычно называемая спринтом в scrum-среде. Среда разработки настроена на отображение полных технических ошибок.
/dev/energy
Сайт о том, как стать программистом и как с этим жить потом
Что такое DevOps? Хайп или реально востребованная вещь?
В августе 2018 года я выступал на конференции «Найди себя в Digital» с докладом на тему «DevOps для разработчика». Общаясь со слушателями после выступления, я ещё раз осознал для себя хайповость слова DevOps. Я могу сравнить уровень его популярности в требованиях работодателей со словом «Highload» лет так пять назад. Поэтому я ещё раз хочу пройтись по основам и постараться расшифровать модное слово для тех, кто мучается поиском.
Откуда пошла проблема
Начать стоит с корней проблемы, как и всегда. Не так давно, когда DevOps ещё даже не появился на рынке в виде жизненно важного требования, мир программирования делился на воинов ордена IDE и ордена Консоли, то бишь на программистов и сисадминов. И фраза «а у меня работает» была притчей во языцах большинства команд, которые выходили в мир больших продуктов с различными уровнями окружений.
Именно появление множества сред создало потребность в более гибком управлении инфарструктурой и конфигурациями окружений, нежели судорожное терзание vim в холодном поту по всему телу, когда при выкатке почему-то упала мастер база. 
Суть DevOps
Современная экосистема разработки состоит из нескольких слоёв. Их число в зависимости от стека, задач и команд может меняться, но базовая картина такова:
Если абстрагироваться от частностей, то мы уже имеем 4 слоя. И это точно не 4 сервера, ведь продакшн требует отказоустойчивости, а разработчиков явно более одного при таком-то количестве слоёв. Совершенно логично здесь возникает вопрос о том, как ставить обновления, доставлять новые версии ПО, да и вообще контролировать весь этот зоопарк. А ведь вскоре появились микросервисы, которые стали умножать количество атомарных крохотных серверов, а значит — творя хаос и увеличивая энтропию.
Исчезновение границ
Даже если взять стек современного web-приложения, то это уже далеко не тот домашний зверёк под именем LAMP, к которому все привыкли в начале десятых. Сейчас это несколько фронт-энд узлов с логикой показа страничек (то есть NGINX, PHP-FPM или чем там кто обрабатывает запросы), перед которыми есть балансировщик (можно тот же NGINX). Базы стабильно уезжают на отдельные сервера ввиду своей прожорливости, и часто также разнесены на ноды (значит, будет, к примеру, Percona + XtraDB Cluster). А ещё добавляются кэши (Redis, Memcached). Да и про интеграцию не надо забывать — там случаются всяческие Kafka с Rabbit, а то и GridGain, появляются Java и Go. А ещё надо как-то анализировать всё это — тут ELK-стек подъезжает. Как видите, всё разрастается с бешеной скоростью, и это я только по верхам пробежался. Контролировать это руками просто нереально.
С подходом классического системного администратора, который работал исключительно с консолью без понимания продукта в целом, в такой ситуации далеко не уедешь. Поэтому неравнодушные люди от мира IT стали придумывать пути решения непростой задачи, выработав в итоге прекрасный подход под названием Development Operations или DevOps. Принято считать, что направление DevOps появилось в 2009 году в результате совместной работы нескольких IT-сообществ.
Началось всё с того, что инженерам надоело бешено долбить команды в консоль, и они подтянули свои скилы в написании кода, чтобы автоматизировать рутинные задачи. С другой стороны разработчики поняли, что вместо постоянного дёргания админов ради очередной пачки логов, стоит самим немного разобраться в среде, которая является средой исполнения для их систем. Так граница начала стираться и становиться невидимой.
Как следствие этого процесса, на свет появились замечательные инструменты — например, Ansible, который позволяет на собирать конфигурации для каждого элемента системы руками, а хранить их в так называемом Playbook-е (файл описания состояния компонентов системы, в котором они должны находиться в указанный момент времени, учитывая установленные пакеты, работающие службы, физические файлы и другие нюансы), который можно «проиграть» на чистой операционке и получить готовую машину с нужным набором свойств.
Для разработчиков стало нормой понимание устройства ландшафта и инфраструктуры, в которой работает их код. Тем не менее, для того, чтобы новая киллер-фича не оказалась киллером для самого бизнеса, приложения стали ограничивать в ресурсах. Сначала это делали установленные лимиты на память, затем фермы виртуальных машин с ограниченным ресурсом, а сейчас это контейнеры, самой популярной системой управления которыми является Docker.
Поскольку инфраструктура получила формальное описание, то и её изменения стали поддаваться удобному версионированию, что привело к входу в обиход инженеров таких систем, как Git.
Когда всё довольно хорошо описано и автоматизировано, то и путешествие изменений в коде и/или инфраструктуре становится автоматизируемой задачей. Точкой, где инженерная часть плотно сходится с кодом — это системы непрерывной интеграции или Continuous Integration. Сама по себе CI является практикой достижения максимально быстрого обнаружения дефектов кода и доставки кода до Production в атоматическом режиме. Если говорить об упрощенной схеме, то действие происходит следующим образом
В момент, когда окружение программного обеспечения достаточно богато описано кодом, развёртывание окружения и становится частью CI. И под новую версию ПО разворачивается новый экземпляр окружения. Но DevOps мир пошёл дальше и создал Docker, который позволяет не просто создавать код, а создавать микро-окружения (так называемые контейнеры), которые доставляются на Production с Development в неизменном состоянии, созданном, изменённом и протестированном самими программистами. Либо доставляются правила создания кластера таких контейнеров, по которым создаётся несколько единиц одинаковых обработчиков логики.
Так что же надо знать?
Таким образом, мы видим, что DevOps — это не какой-то конкретный набор инструментов, а философия организации процесса разработки и доставки ПО, которая подразумевает тесное взаимодействие между разработчиками и инженерами, управление инфраструктурой через код, а также позволяет гибко управлять системами, насчитывающими сотни серверов.
Если Вы хотите погрузиться в философию DevOps глубже, то начать стоит с прекрасной книги за авторством Джина Кима, Кевин Бер и Джорджа Спаффорда «Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему», которая в художественной форме подробно описывает проблемы, стоящие перед отделами, внедряющими современные практики разработки, и пути их решения.
Разработчикам точно стоит посмотреть в сторону организации инфраструктур на платформе Docker с применением Kubernetes, созданием stateless-приложений, способных работать в отвязке от конкретного сервера запуска, да и просто быть в используемой в компании ОС как дома.
Инженерам стоит погружаться в автоматизацию рутинных процессов, создания экземпляров серверов и систем, а также особенностей работы используемого в компании стека ПО. Всё это, разумеется, должно быть хорошо наблюдаемо, что требует подробного мониторинга, например, на Zabbix, и не менее подробного анализа логов, где начинается ELK-стек.
Как видите, пространство для развития очень большое. Выбирать направление Вам, а я надеюсь, что моя статья помогла лучше понять философию модного нынче течения.
Стенд для нагрузочного тестирования: от DEV до PROD
Содержание
Меня зовут Василий Кудрявцев, и вот уже 10 лет я занимаюсь нагрузочным тестированием, а из них последние 1,5 года – в компании РТЛабс.
И сегодня мы поговорим не об инструментах или общих подходах (для этого есть курсы – один из крупных веду я, а еще у многих есть коллеги-эксперты и тот самый чатик в телеге на 3400+ участников), а об области, которую обычно обходят стороной или собирают на коленке — тестовые стенды для нагрузочного тестирования.
Здесь, на Госуслугах, мы пока только конструируем мечту каждого нагрузочника — свой отдельный, выделенный, рабочий (!) тестовый стенд. Особенно это мечта актуальна для небольших продуктовых команд.
Тем не менее, за последний год мы увеличили количество проводимых тестов почти в 10 раз и команду раза в два. Где же мы проводим более 1000 нагрузочных тестов в год без отдельного стенда, спросите вы? Ответ: мы использовали все стенды по максимуму, под шум (крики) продуктовых команд! 🙂
Я попробовал обобщить личный опыт последних лет, успехи прорыва в результативности тестов и, соответственно, в повышении производительности, которого мы смогли достичь в компании за последнее время.
Договоримся о терминологии
НТ — нагрузочное тестирование, для меня это синоним тестирования производительности. В НТ входят всевозможные подвиды тестов, направленные на проверку показателей производительности системы: время отклика, пропускная способность, % успешных операций или доступность, утилизация ресурсов.
Максимальная производительность — уровень пропускной способности системы, после которого система перестаёт удовлетворять предъявленным к ней требованиям — по времени отклика, доступности, утилизации ресурсов.
Тест определения максимальной производительности — ступенчатое повышение нагрузки на систему до достижения этого самого уровня.
Как у нас организована нагрузка
Инструменты:
Протоколы – наиболее часто это REST-ы и web по http, бывают и скрипты нагрузки на БД / очереди
Запуск тестов в Jenkins
Мониторинг в Grafana + Clickhouse
Для мониторинга генераторов нагрузки — Prometheus
Redis и Postgres для хранения тестовых данных, FTP для больших файлов
В общем, всё как у взрослых людей. В следующих статьях расскажем об этом подробнее, если интересно. А сейчас едем дальше.
3+ регулярно нагружаемые крупные системы:
Единый портал государственных услуг (ЕПГУ)
Единая система идентификации и аутентификации (ЕСИА)
Система межведомственного электронного взаимодействия (СМЭВ, шина данных)
…и еще с десяток периодически нагружаемых прикладных систем и сервисов
Основные типы тестов:
Проверка стабильной нагрузки — короткий тест с заданным tps
Стресс-тесты — проверка работы под большой нагрузкой в течение короткого времени
Классическая максимальная производительность
Команда инженеров:
1 лид и 4 нагрузочника разного опыта и происхождения, со средним опытом в НТ =
Вернемся к нагрузочным стендам
Разделим типы стендов на несколько категорий и поймём, что же можно на них тестировать и какие риски / ограничения нужно держать в уме:
DEV — стенд разработки
UAT — стенд регрессионного функционального тестирования
LT — отдельный стенд нагрузочного тестирования
PROD — стенд на базе инфраструктуры Продуктивного контура
Каждый опишем с нескольких сторон по такой схеме:
Summary — короткое резюме от меня
Жиза — как мы используем этот стенд
Что можно — какие тесты можно проводить
Команда — кто здесь понадобится нагрузочнику, насколько самостоятельно выполнение тестов
Advice — совет напоследок обзора стенда
Summary: Отличное место для нагрузки пилотных решений или новых микросервисов, но задержаться на нём для исследований бывает сложно. Особенно, если архитектура монолитная.
Жиза: Не самый активный стенд именно для нагрузки, но супер-массовые новые сервисы сначала тестим здесь — социальные выплаты, сервисы для выборов, онлайн-запись в школы. Конечно же, в микросервисах, особенно часто в кубере. Здесь не проверить какой-нибудь scaling, но 50-70% проблем на данном стенде мы закрывали, хоть пользовались им не так часто, как стоило бы.
Отступление в рамках темы
Отдельного внимания здесь в описании DEV заслуживает наше детище для Системы межведомственного электронного взаимодействия (СМЭВ). Изначально мы планировали собрать стенд LT, но заказчики-разработчики пожелали проверять новые решения и тюнинг/рефакторинг старых здесь и сейчас. У нас вышел эдакий Монстр, которого мы прозвали DEV-LT! По необходимости могли и мощностей накинуть для достижения нужных цифр, но и не ждали отлаженных новых релизов и прочих pipeline-ов для проверки разных гипотез.
В итоге за пару месяцев мы протестили отказоустойчивость при отключении разных сервисов системы, протюнили с десяток компонент и повысили общую производительность системы раза в три (с учётом пост-тестов на других стендах, конечно же). Это был суровый марафон, но глаза горели у всех!
Что можно: стресс-тесты и общая максимальная производительность всего комплекса здесь бессмысленны. Только точечный тюнинг и проверка отдельных компонентов тестами со стабильными потоками (количество открытых соединений / thread-ов) или подачей стабильной нагрузки.
Команда: Если времени мало, то практически в онлайне с разработчиком. Если побольше — в режиме чатика. Очень удобно поработать devops-ом: сделать «кнопку» для разработчика и дать ему «пофрустрировать» самому до желаемого результата. Не забудьте про мониторинг, чтобы он получал удовольствие! Главное вовремя остановить, не доводить до уровня «хочу 100к tps выжать, 12 ночи всего, запускаю ещё тест!»
Pros and cons:
+ экономит время тюнинга на поздних этапах, что особенно актуально для багов по производительности (все мы знаем, они бывают ОЧЕНЬ дорогими)
+ можно запускать «на коленке» и получать реальный value
– не подходит для основательных выводов по максималке / не применить к PROD — нужны дополнительные тесты на других контурах
– стенд обычно шаток и разработчики любят его ломать, а иногда его потом сложно восстановить
– сложно с тестированием интеграций, DEV, как правило, изолирован
Advice: Совет подойдёт и для других стендов — «одно изменение за раз!». Разработчики любят побежать азартно вперёд, и применить много «оптимизаций» между тестами за один раз. Потом приходится часто искать, что именно улучшило или ухудшило производительность. Поэтому лучше стараться делать одно улучшение/изменение за раз и оценивать тестом, хотя бы коротким.
UAT (стенд регрессионного функционального тестирования) — относительно стабильный контур по сборкам, но слабый по железу
Жиза: С этого стенда мы начинали в РТЛабс проводить регулярное НТ — в данном случае проверка релизов на не-ухудшение производительности. В частности, на небольшом железе мы сравниваем «выдерживание» ступени стабильной нагрузки по основным показателям производительности. Дефектов обычно находится не так много, как хотелось бы, потому что у этого стенда всегда много «но» по сравнению с PROD. И это несмотря на то, что по конфигурации компонентов он к нему ближе, чем любой другой.
Что можно: Лучше проводить тесты стабильной нагрузки 10-60 минут. Длительность зависит от вашей ступени стабильной нагрузки, за которую вы сможете адекватно оценить показатели производительности. Если у вас быстрая система с 100-500+ tps и временем отклика в пределах секунды (шина данных, например), то хватит и коротких тестов. Если что-то пользовательское с множеством сценариев — лучше погонять подольше и заодно оценить надежность.
Команда: Как правило, лучший друг нагрузочника — это функциональщик. В данном случае вдвойне, так как это его стенд! Он подскажет, когда и сборка более-менее стабильна и когда можно поломать стенд тестами. С дефектами тут сложнее, чем на DEV — у нас по крайней мере были наводки и на инфраструктурные сбои, а разбор может быть не таким быстрым, как хотелось бы.
Pros and cons:
+ хороший стенд для старта нагрузочного тестирования в плане стабильности и отладки (в том числе на новых готовящихся версиях системы). И для того, чтобы потом куда-то переезжать с тестами на другие стенды
+ обычно неплохая поддержка со стороны ФТ и сопровождения, так как релизы должны ехать в PROD без простоев. А вы, в том числе, занимаете время подготовки релиза 🙂
– придётся выбирать время для тестов, чтобы не мешать ФТ
– сильную нагрузку целиком на систему не подать ввиду слабости стенда по железу, то есть сложно оценить максимальную производительность в целом
Advice: Не убивайте стенд, пожалейте функциональщиков! Не только проведением нагрузки днём, но и забиванием БД тестовыми или созданными в тестах данными. Проработайте процедуры очистки.
LT (отдельный стенд нагрузочного тестирования)
На какой хватит средств какой построите, такой и будет! Но в любом случае он лучше остальных стендов, потому что СВОЙ.
Summary: Здесь всё понятно — идеальный стенд практически для любых целей НТ. Не надо сидеть по ночам / ждать пока он освободится (в пределах одной тестируемой системы, конечно). В некоторых банках даже построили интеграционные стенды НТ. Правда пока я не видел стенд, выдерживающий 100% нагрузку по профилю с Прода, со всех каналов-систем.
Жиза: Выше я рассказывал о том, как мы применяем стенд DEV-LT. Пока мы видим неплохую пользу в совмещении целей для этого контура с учетом имеющейся инфраструктуры PROD для больших тестов (об этом ниже).
Из опыта других компаний могу сказать, что отдельный контур это действительно долго, дорого и замечательно. Причём для стабильного стенда крупной системы «долго» — это скорее всего минимум год, а «дорого» — не только закупка оборудования, но ещё и отдельная команда админов разного профиля. Ведь у вас небольшой PROD, а значит нужны инженеры СПО, ППО, DBA и т.д.
При этом на других стендах можно и нужно ловить 80-90% проблем. Это значит, что в микросервисной архитектуре огромные стенды становятся всё менее полезными.
Что можно: ВСЁ. Ну, правда. Интеграционные нагрузочные тесты можно проводить с эмуляторами, хорошо идут регрессионные тесты, стресс-тест/максималка/надежность/отказоустойчивость и любые другие, которые вы ещё себе придумаете между релизами.
Команда: Если хотите работать эффективно, а не чинить стенд неделями, когда ребята с PROD / тестовых контуров смогут уделить вам время, то только отдельная команда. Если стенд небольшой, можно не выделять отдельно системных администраторов / DBA на задачи одного этого стенда. Но инженеры ППО точно нужны — системы нужно и поднимать с нуля и поддерживать (поднимать) после регулярных тестов и релизов, которые будут их ломать.
Pros and cons:
+ подходит для всех нужных нагрузочных тестов (с интеграционным НТ может быть сложно, но возможно!)
+ не нужно ждать очередь на стенд, есть время для улучшений / экспериментов
+ можно готовить нужные наборы тестовых данных, тестировать объемы
– дорого и долго — и по подготовке железа, и в поддержке
– команде сопровождения нужно долго набираться опыта
– бывает сложно отслеживать все изменения на PROD / тестовых контурах, чтобы тестовый стенд НТ был актуален
Advice: Не надейтесь, что стенд НТ взлетит быстро, особенно если команда собирается с нуля. Исключения — небольшие и простые системы, по ним и PROD просто и быстро собрать.
И раз уж у вас отдельный стенд — пробивайте получение копии БД с PROD (урезанной, обезличенной), это повысит качество тестирования.
Ещё совет— не делайте прогнозирование / домножение результатов, полученных на стенде НТ, для PROD, если у вас LT сильно меньше по ресурсам. Горизонтальное масштабирование — непростая штука. Да простят меня мастера-архитекторы – иногда позволяю себе «умножить на 2» производительность, полученную на стенде НТ, который в 2 раза слабее Прода по ресурсам, при микросервисной архитектуре и не загруженности всех узлов по метрикам серверов. Можно предположить, что на Прод будет не хуже.
Сравнение производительности простой web-ки на node.js при увеличении ресурсов машины в 2 раза.
Как-то студенты курса по НТ проводили простой эксперимент по оценке влияния повышения ресурсов сервера, на котором крутилась простая веб-страничка c node.js под капотом, практически ничего не делающая. Результат налицо. Теперь храню эту картинку и показываю всем, кто любит «умножать на 10».
PROD (стенд на базе инфраструктуры Продуктивного контура) – опасно, но крайне эффективно
Жиза: Чтобы быть уверенными в высокой доступности новых, серьёзных по нагрузке сервисов, финальные тесты мы проводим здесь. Особенно это актуально, когда у нас мало времени, например, при запуске срочных выплат населению страны последних пары лет.
Пользователи Госуслуг засыпают, а мы собираемся на ночной zoom и аккуратно тестируем на PROD-инфраструктуре. Тюним на месте, записываем изменения конфигов «на лету» себе в тикеты «на утро». Отдельно заказываем новые VM туда, где понимаем, что не успеем дотюниться до запуска сервиса.
Конечно, для этого нужна аккуратная и дотошная подготовка скриптов для очистки мусора после тестов и выверенный чёткий план тестирования с автоматизацией запуска тестов.
Что можно: Конечно, не всё. В первую очередь это стресс-тесты — короткие, точные, до первых узких мест, чтобы затем произвести тюнинг. Можно сразу в онлайне, чтобы не уходить потом на ещё одни работы. Не получится использовать инфраструктуру PROD, если у вас интенсивная пользовательская нагрузка 24/7 и нет микросервисов, которые вы можете изолировать от влияния на пользователей на 99%+.
Для тех, кто по каким-то причинам не хочет в этом участвовать, есть отличный аргумент — или мы сейчас проконтролируем что будет, или будем смотреть на это в онлайне, на живых пользователях и чинить, теряя SLA.
Pros and cons:
+ не только НТ, но и тренировка для команды
+ в нехватке времени можно тюнить на лету (конечно, сохраняя улучшения в репозиториях)
– требуется хорошая подготовка плана и скриптов очистки
– не для каждого сервиса возможно НТ на инфраструктуре PROD
Advice: Все же помнят хорошую практику: всё что выкатывается на PROD должно тестироваться? Это же касается и ваших скриптов НТ, тестовых данных, скриптов очистки от мусора после НТ. Всё должно быть протестировано на младших контурах, считайте, что это такой же релиз.
Ну и конечно, так как НТ на PROD — это часто ночные работы, не замучайте команду в ночь перед запуском важных сервисов. Если не успеваете, лучше ребятам поспать ночь и с утра уже готовиться к проблемам на PROD, быстрее будут реагировать.
Во всём нужна мера, потому что, как говорил один мой знакомый менеджер: «Работа отнимает всё отведенное на неё время».
Вместо заключения
Как видите, у каждого стенда НТ найдутся свои нюансы, а главное – своя польза. Уже давно прошли те времена, когда подрядчик требовал нагрузочный стенд, а заказчик закупал его месяцами, тратя огромные деньги. С новыми средствами НТ и микросервисной архитектурой тесты можно проводить на разных этапах и на разных стендах достаточно быстро.
Я бы описал рекомендованный путь становления процессов НТ в компании по части стендов так:
UAT – отсюда можно стартовать регрессионное НТ
DEV – для новых сервисов, которые будут нагружены
PROD – когда отдельного стенда НТ нет, а ожидается новая большая нагрузка
LT – когда уже научитесь тестировать, поймете систему и действительно сможете использовать дорогое удовольствие с пользой
Конечно, эти стенды у вас могут называться по-другому, типы тестов тоже. Я старался использовать плюс-минус общепринятые понятия. На закрепление терминологии не претендую.
Пишите в комментариях про ваш опыт использования тестовых стендов для НТ. Буду рад почерпнуть что-то новое, в том числе по поводу плюсов и минусов каждого.