Сейчас много софта, который позволяет языковой модели решать, что произойдёт с вашим боевым сайтом. Это не тот случай.
Что делает модель
Перед установкой обновления его changelog загружается и прочитывается моделью, которая возвращает оценку риска и короткую рекомендацию. Это действительно полезная работа. Номер версии не говорит ни о чём; именно в примечаниях к релизу написано “переписали REST-эндпоинты” или “отказались от поддержки PHP 8.1” – обычным текстом, у каждого автора по-своему. Быстро читать это по всему портфелю сайтов каждую ночь – хорошее применение модели.
Чего модели делать нельзя
Рекомендация – это вход. Решение принимает код, по правилам, записанным для конкретного сайта ещё до начала прогона:
- Никогда автоматически. Перечисленные поимённо плагины не устанавливаются автоматически, что бы ни говорила оценка.
- Порог риска. Выше порога сайта обновление сначала идёт на копию сайта на нашем сервере. Боевой сайт увидит его, только если там оно выжило.
- Только минорные. Мажорные релизы ядра ждут человека, если сайт так настроен.
Уверенная в себе и ошибающаяся модель не сможет протолкнуть мажорное обновление на сайт клиента, потому что ни один участок кода не спрашивает у неё разрешения. Если модель вообще недоступна, прогон всё равно завершится – просто консервативнее.
Откат устроен так же
Откатывается ли обновление, определяют три независимых сигнала: HTTP-проверка доступности, результаты тестов и визуальное сравнение. Достаточно, чтобы один из них сказал “сломано”. Модель не спрашивают, потому что именно это решение через неделю нужно уметь объяснить клиенту одной фразой.
Суждение там, где оно помогает, правила там, где это важно
Модели хорошо читают текст и плохо несут ответственность. С правилами наоборот: они жёсткие, но их можно прочитать, с ними можно спорить, их можно менять – и на четырёхсотом сайте они ведут себя так же, как на первом. Держать модель на совещательной стороне этой границы – не осторожность ради осторожности. Именно это делает систему безопасной для работы без присмотра.