Автоматизация очень легко превращается в отдельное хобби.
Сначала ты хочешь не запускать одну команду вручную. Через вечер у тебя уже скрипт, таймер, логирование, уведомления и ещё один скрипт, который проверяет первый.
Иногда это оправдано. Иногда ручная команда была проще.
Автосборка сайта — да
Публикацию заметок я точно не хотел превращать в ритуал с подключением к серверу.
Контент синхронизируется, система замечает изменения, Quartz пересобирает сайт, готовая версия обновляется. Всё.
Это хороший кандидат для автоматизации: процесс повторяется, шаги понятны, а результат легко проверить.
Главное — не запускать несколько сборок одновременно и не выкатывать сломанную версию поверх рабочей. Такие вещи обычно обнаруживаются после первой же гонки процессов.
Музыкальные задачи тоже удобнее по расписанию
Обновление библиотеки и повторное сканирование не требуют творческого решения.
Их можно запускать ночью или в другое спокойное время. Если задача прошла — отлично. Если нет — достаточно записи в журнале или уведомления.
Здесь автоматизация экономит реальное время, потому что вручную про такие операции просто забываешь.
Уведомления полезнее бесконечных дашбордов
Я не хочу каждый день открывать пять панелей и смотреть, всё ли зелёное.
Гораздо удобнее, когда система молчит, пока ничего не происходит, и отправляет сообщение только при значимом событии.
Но уведомления тоже легко испортить. Если бот пишет по каждому чиху, через день чат становится фоном, который никто не читает.
Хорошее уведомление должно отвечать хотя бы на два вопроса: что произошло и нужно ли что-то делать.
Где автоматика начинает вредить
Опасные операции я стараюсь не запускать полностью вслепую.
Обновления с миграциями, удаление данных, массовая перезапись файлов — это уже не тот случай, где хочется довериться расписанию в три часа ночи.
Автоматизация не умеет сомневаться. Если условие написано неправильно, она очень последовательно выполнит неправильное действие.
Поэтому мне нужны блокировка параллельных запусков, понятные коды завершения, резервные копии, ограничение области действия, нормальные логи и ручная остановка.
Самый неприятный тип ошибки
Когда процесс «успешно» завершился, но сделал не то.
Сборка прошла, однако нужная страница не попала на сайт. Сканирование завершилось, но библиотека обновилась частично. Скрипт отправил уведомление, хотя основная операция упала.
Такие ошибки хуже явного падения. Красная ошибка хотя бы честная.
Поэтому автоматизация должна проверять результат, а не только факт запуска команды.
Моё правило
Я автоматизирую скучное и повторяемое.
Всё, что может дорого сломаться или требует контекста, сначала оставляю ручным. Если через время процесс становится понятным и стабильным — только тогда переношу его в фон.
Иначе получается не экономия времени, а роботизированный способ создавать себе новые проблемы.
Практический пример — публикация сада, границы системы — в Архитектуре, диагностика контейнеров — в LazyDocker.