Сообщить об ошибкеКороткий ответ
Миграцию стоит проводить поэтапно и по приоритету риска: сначала инвентаризация всех скриптов автоматизации и их критичности, затем немедленное устранение явных угроз безопасности (секреты в коде/истории Git, запуск от root без необходимости), и только потом постепенное приведение к единому стандарту обработки ошибок и логирования по мере изменения каждого скрипта; единого "правильного" темпа и набора стандартов нет — их нужно соразмерить с реальным риском простоя и доступными ресурсами команды.
Как это работает подробнее
большой парк разнородных скриптов, накопленных за годы, обычно невозможно и нежелательно переписывать "большим взрывом" — это высокий риск регрессий в критичной автоматизации при ограниченной пользе немедленно. Более устойчивый подход — ранжировать скрипты по критичности (влияет ли сбой на продакшен, деньги, безопасность) и по риску (секреты в коде, запуск с широкими правами, отсутствие логирования инцидентов) и обрабатывать в этом порядке.
быстрая принудительная миграция всех скриптов разом даёт единообразие немедленно, но несёт риск простоя и перегружает команду; постепенная миграция "по мере изменений" безопаснее, но может растянуться на годы и оставить критичные, редко изменяемые скрипты в исходном рискованном состоянии надолго. Правильный баланс обычно состоит в быстром отдельном треке именно для скриптов с секретами/широкими правами и более медленном органическом улучшении остального — конкретные сроки стоит обсуждать с владельцами затронутых систем, исходя из их готовности и критичности.
Что использовать на практике
- Рекомендация. полезно формализовать минимальный "контракт" скрипта — обязательный
set -euo pipefail/аналог в Python, структурированное логирование с уровнем и контекстом, получение секретов только из менеджера секретов/переменных окружения, а не из файлов в репозитории, явные коды возврата. Этот контракт внедряют как требование для нового кода сразу, а для существующего — по мере "прикосновения" (правило бойскаута) плюс отдельным треком для самых рискованных скриптов независимо от того, меняются ли они по другим причинам.
Подводные камни
- Ошибка. пытаться остановить всю автоматизацию на время "большого рефакторинга", рискуя пропустить критичные операционные задачи; вводить стандарт как жёсткое требование без переходного периода, из-за чего команды начинают игнорировать его под давлением сроков; фокусироваться только на стиле кода (форматирование, линтер) и упускать реальные риски — секреты в открытом виде, отсутствие обработки частичных сбоев, скрипты, которые нельзя безопасно перезапустить.