Bash и Python: наблюдаемый скрипт для парка

Скрипт для одной машины и скрипт для парка — разные вещи. На одной машине вы видите вывод и можете вмешаться; на пятидесяти вы узнаёте только то, что скрипт сам о себе сообщил. Поэтому наблюдаемость закладывается в код, а не добавляется потом.

Сделайте задачу наблюдаемой

• Возвращайте разные коды завершения для разных исходов: сделано, уже было сделано, не применимо, ошибка. Единый ноль превращает отчёт по парку в бесполезную зелёную колонку.
• Пишите в вывод, что именно произошло, а не «OK». Строка «пакет обновлён с 1.2 на 1.4» отвечает на вопросы, «Готово» — нет.
• Разделяйте обычный вывод и ошибки: диагностику — в stderr, результат — в stdout. Тогда сбор результатов по парку не смешивает одно с другим.
• Для bash начинайте со строгого режима — прерывание на ошибке, на необъявленной переменной и на ошибке в конвейере. Без него скрипт продолжит работать после сбоя и оставит машину в промежуточном состоянии.
• Ставьте таймауты на всё, что ходит в сеть. Скрипт, зависший на недоступном сервере, занимает очередь и выглядит как «выполняется» часами.

Проверяйте окружение, а не предполагайте

Самая частая причина «на моей машине работает» — предположение, которого не проверили.

• Не рассчитывайте, что python3 есть и что это нужная версия. Проверяйте в начале и завершайтесь с понятным сообщением, если нет.
• Не полагайтесь на PATH: при запуске из системы окружение отличается от вашей интерактивной оболочки.
• Проверяйте наличие утилит, которые вызываете, а не предполагайте, что они входят в минимальную установку.
• Учитывайте, что дистрибутивы отличаются версиями пакетов и путями. Скрипт, написанный под свежую систему, на консервативной может встретить другую версию утилиты с другими флагами.
• Проверяйте права в начале, а не падайте на середине с половиной выполненной работы.

Параметры вместо зашитых значений

Жёстко зашитые пути, имена и адреса приводят к копиям скрипта под каждый случай — а потом никто не знает, какая из копий актуальна.

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

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

Разбирайте результаты по группам

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