Замкните цикл проверенным улучшением

Определите цикл, который хотите замкнуть

Во время использования ПО даёт данные: ошибки, задержки, обращения в поддержку, инциденты, обнаруженные при обслуживании проблемы и повторяющуюся ручную работу. Полный жизненный цикл возвращает эти данные в инженерные решения.

Самосовершенствующееся ПО может означать, что автоматизация помогает выявлять, предлагать, реализовывать и проверять изменения. Это не обязательно означает, что модель обучает себя. Укажите, что меняется: код приложения, конфигурация, тесты, инструкции, процесс или параметры модели.

Самовосстановление возвращает известное рабочее состояние. Самосовершенствование меняет систему ради лучшего результата в будущем. Для второго утверждения нужны сравнение и защита от регрессий.

Проследите одно наблюдение через жизненный цикл

Ниже предложен инженерный метод. Это не утверждение, что какой-либо продукт автономно выполняет все шаги.

Сохраняйте связи между этими результатами. Действие postmortem «улучшить мониторинг» трудно проверить. Определённые сигнал, ответственный, порог и проверенное реагирование делают завершение наблюдаемым.

Оценивайте независимо от предложения

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

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

Отклоняйте более быстрый экспорт, если он теряет записи, обходит авторизацию или превышает допустимую стоимость. Определите эти ограничения до оптимизации. Иначе система может улучшить выбранную метрику и ухудшить сервис.

Если вы меняете инструкции агента или модель, оцените поведение на репрезентативных задачах и известных сбоях. Сохраните предыдущую версию доступной. Обновление инструкций не доказывает, что лежащая в основе модель обучилась на инциденте.

Выпустите изменение и измерьте результат

Canary release направляет ограниченную группу пользователей на проверяемую версию. Сравнивайте сигналы проверяемой и контрольной версий и определяйте, когда расширять охват или останавливаться. Малый трафик или различающиеся нагрузки могут не дать убедительного сравнения. Рекомендации по canary.

Вымышленная команда фиксирует исходный уровень на неизменной синтетической нагрузке. Она проверяет исправление, выпускает его в утверждённых границах и сравнивает сопоставимые периоды production. Если доказательств всё ещё недостаточно, команда записывает неопределённость, а не объявляет улучшение.

Измеряйте и повторяющуюся ручную работу. Автоматизация может уменьшить рутину, но также требует обслуживания и обработки сбоев. Учитывайте эти расходы при оценке результата. Рекомендации по сокращению рутины.

Сделайте запись обратной связи полезной

Используйте для упражнения следующие поля: наблюдение и версия; исходный уровень; предполагаемая причина; критерии приёмки; проверки регрессий; изменение и review; граница релиза; измеренный результат; ответственный и следующий пересмотр.

Taiga Maintaining связывает находки в репозитории с работой по устранению. Initiatives связывает предполагаемое изменение с планированием и поставкой. Это части цепочки доказательств. Ответственный за ваш сервис по-прежнему должен проверить deployment и эксплуатационный результат. Maintaining, Initiatives.

Зрелая фабрика ПО связывает эту работу между продуктами. По мере роста автоматизации сохраняйте ясными права принятия решений и критерии оценки. Итоговое доказательство — проверенное улучшение сервиса, а не рост числа сгенерированных изменений.