Как зафиксировать состояние системы до изменения: исходная точка эксперимента
После обновления приложение стало отвечать быстрее. Или медленнее. Потребление памяти изменилось, число ошибок выросло, нагрузка на базу снизилась. Но само сравнение «после стало иначе» мало что объясняет, если неизвестно, в каком состоянии система находилась до изменения.
Поэтому перед обновлением, оптимизацией или экспериментом полезно сохранить исходное состояние системы. В инженерной практике такое состояние часто называют baseline. Это не одна цифра и не скриншот графика, а набор данных, по которому позднее можно восстановить условия сравнения.
Baseline — это не одна метрика
Предположим, до изменения API отвечал в среднем за 180 мс, а после — за 140 мс. Разница заметна, но двух значений недостаточно.
Нужно понимать хотя бы следующее:
- какая версия приложения работала во время первого измерения;
- какая использовалась конфигурация;
- не менялись ли зависимости и среда выполнения;
- на какой инфраструктуре выполнялась проверка;
- какая нагрузка подавалась на систему;
- какие данные обрабатывались;
- когда и в течение какого периода проводилось измерение.
Если часть этих условий изменилась, сравниваться могут уже не два состояния одного объекта, а две разные комбинации факторов.
Поэтому baseline удобнее рассматривать как карточку состояния системы на конкретный момент времени.
Сначала нужно определить, что именно мы собираемся менять
Фиксировать абсолютно всё техническое состояние проекта обычно бессмысленно. Через несколько итераций такой документ превращается в большой архив, которым трудно пользоваться.
Состав исходного состояния зависит от проверяемого вопроса.
Если меняется алгоритм кэширования, важны версия приложения, конфигурация кэша, характеристики запросов и показатели, по которым будет проводиться сравнение.
Если обновляется база данных, к этому набору могут добавиться версия СУБД, параметры сервера, состояние индексов и характеристики тестовой нагрузки.
При изменении инфраструктуры понадобится описание самой среды: вычислительные ресурсы, число экземпляров, ограничения памяти и процессора и другие параметры, способные повлиять на результат.
Исходное состояние должно позволять понять, что оставалось неизменным во время сравнения и какие условия могли влиять на наблюдаемый результат.
Что стоит сохранить до изменения
| Что фиксируем | Пример | Зачем это нужно |
|---|---|---|
| Версия приложения | Commit, tag, build ID или номер релиза | Позволяет установить, какой именно код работал во время измерения |
| Конфигурация | Версия конфигурационного файла или значения существенных параметров | Одинаковый код при другой конфигурации может вести себя иначе |
| Зависимости | Runtime, библиотеки, СУБД, внешние компоненты | Помогает заметить изменения вне основной кодовой базы |
| Среда | ОС, контейнер, CPU, память, регион, число экземпляров | Позволяет отделить изменение приложения от изменения условий выполнения |
| Данные и нагрузка | Набор данных, профиль запросов, число параллельных клиентов | Делает сравнение двух прогонов содержательным |
| Наблюдаемое состояние | Значения показателей, относящихся к проверяемому изменению | Создаёт фактическую основу для сравнения «до» и «после» |
| Время | Дата, начало и длительность измерения | Помогает сопоставить состояние системы с изменениями и другими событиями |
Необязательно складывать всё это в один документ. Версия приложения уже может находиться в Git, конфигурация — в отдельном репозитории, параметры инфраструктуры — в Infrastructure as Code, а измерения — в системе мониторинга.
Важно другое: позднее должна сохраняться возможность связать эти данные с одним конкретным состоянием системы.
Версия кода — только часть состояния
Фраза «мы сравнили предыдущий и новый commit» звучит достаточно точно, пока между двумя проверками не обнаруживается ещё несколько изменений.
Например, исходный код мог измениться вместе с другими компонентами:
- поменялась конфигурация приложения;
- обновилась версия runtime;
- изменилась используемая библиотека;
- у экземпляра стало меньше доступной памяти;
- тест выполнялся на другом наборе данных.
В таком случае commit хорошо идентифицирует код, но уже не описывает всё состояние работающей системы.
В Google SRE подход к release engineering строится в том числе вокруг повторяемости процессов сборки и выпуска. Используемые артефакты и конфигурации должны позволять понимать, какое состояние системы фактически было развёрнуто.
Для сравнения поэтому полезно уметь идентифицировать не только код, но и условия, в которых он выполнялся.
Условия проверки должны оставаться сравнимыми
Особенно заметна эта проблема при измерении производительности.
Допустим, первый прогон выполнялся при 50 одновременных запросах, а второй — при 200. Даже если между проверками действительно изменился код, полученные значения уже нельзя читать как простое сравнение одной версии с другой.
То же относится к объёму данных, характеристикам инфраструктуры, предварительному прогреву системы, продолжительности проверки и другим условиям выполнения.
Если задача требует численно сравнить две версии приложения, следующий вопрос уже не про само исходное состояние, а про то, как воспроизвести одинаковые условия проверки.
Этому посвящён отдельный материал о воспроизводимом бенчмарке приложения.
Baseline не заменяет резервную копию
Эти два объекта решают разные задачи.
Резервная копия нужна, чтобы восстановить данные или систему после сбоя.
Baseline нужен, чтобы понять, каким было наблюдаемое состояние до изменения и с чем сравнивать следующее состояние.
Иногда один и тот же артефакт полезен в обоих процессах. Например, сохранённая конфигурация может понадобиться и при восстановлении, и при анализе эксперимента. Но назначение у этих процедур разное.
Baseline не является целевым значением
Есть ещё одно смешение понятий, которое легко пропустить.
Если сервис сейчас отвечает за 300 мс, это значение может войти в исходное состояние. Из этого не следует, что 300 мс — хороший или допустимый результат.
Baseline отвечает на вопрос:
«Что наблюдалось до изменения?»
Целевое значение или требование отвечает на другой:
«Какое состояние мы считаем приемлемым?»
Эти значения могут совпасть, но методологически это разные объекты.
Не нужно сохранять секреты ради полноты исходного состояния
Конфигурацию важно идентифицировать, но это не означает, что вместе с карточкой эксперимента следует копировать пароли, токены, приватные ключи и другие секретные значения.
Обычно достаточно сохранить версию конфигурации, имя окружения, идентификатор секрета или другой безопасный способ понять, какое состояние использовалось. Сам секрет должен оставаться в предназначенной для него системе хранения.
Так сохраняется воспроизводимость проверки без создания нового источника чувствительных данных.
Простой шаблон карточки исходного состояния
Для небольшого изменения baseline может быть довольно компактным.
| Поле | Что записать |
|---|---|
| Дата и время | Когда состояние было зафиксировано |
| Проверяемый вопрос | Какое изменение планируется оценивать |
| Версия приложения | Commit, tag, release или build ID |
| Конфигурация | Версия или идентификатор конфигурации |
| Среда | Существенные параметры окружения и инфраструктуры |
| Данные и нагрузка | Какие входные условия использовались |
| Измерение | Исходные значения выбранных показателей |
| Артефакты | Ссылки на логи, отчёт, конфигурацию или результаты проверки |
Главное достоинство такой карточки — не количество заполненных полей. Через неделю или месяц по ней должно быть понятно, какую систему сравнивали и при каких условиях.
Когда старый baseline уже нельзя использовать
Исходное состояние привязано к определённой версии системы и её окружению. Поэтому оно не остаётся актуальным навсегда.
Если до запланированной проверки произошло существенное изменение архитектуры, конфигурации, инфраструктуры или нагрузки, разумнее сформировать новое исходное состояние.
Иначе возникает странная конструкция: новая версия оценивается относительно системы, которой к моменту эксперимента уже фактически не существует.
Поэтому перед сравнением стоит проверить не только наличие baseline, но и его актуальность.
Что исходное состояние даёт инженерному эксперименту
Сам по себе baseline ещё ничего не доказывает. Он создаёт точку, относительно которой можно описывать последующие события.
После него всё равно потребуется:
- зафиксировать само изменение;
- сохранить время события;
- получить данные после изменения;
- сопоставить два состояния;
- учесть другие события, происходившие одновременно;
- отделить наблюдение от объяснения результата.
Исходное состояние поэтому является одним слоем более широкой процедуры. Полная логика разобрана в материале об инженерном подходе к эксперименту, где baseline связывается с журналом изменений, наблюдением и границей причинного вывода.
До изменения важно сохранить не красивый скриншот «до», а достаточно информации, чтобы исходное состояние можно было идентифицировать и содержательно сравнить со следующим.
Источники
Технические источники проверены 19 августа 2026 года. Использованы официальные материалы Google SRE и Microsoft.