Автоматизируйте DevOps-задачи, начиная с еженедельных рутин

Почему ручная ops-работа всё время возвращается

Чаще всего боль в ops начинается одинаково. Один человек каждую неделю делает одну и ту же мелкую задачу, а команда считает это нормой.

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

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

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

По этой же причине новые инструменты часто не помогают. Команды покупают ещё один dashboard, продукт для alerts или слой для deploy, но еженедельная рутина под ним остаётся туманной. Если никто не согласовал точные шаги, новый инструмент просто кладёт более аккуратный экран поверх неясной работы.

Представьте небольшой стартап, где один engineer тратит 40 минут каждую пятницу на проверку упавших jobs, очистку очереди и повторный запуск deploy script после изменения конфигурации. Никто не считает это проблемой, потому что обычно всё работает. Потом этот engineer уезжает на неделю. Releases останавливаются, мелкие баги ждут дольше, чем должны, и все внезапно видят, сколько хрупких знаний сидело в одной голове.

Команды, которые хотят автоматизировать DevOps-задачи, часто начинают слишком далеко вниз по цепочке. Они ищут более крупную систему, прежде чем посмотрят на повторяющееся человеческое действие. Обычно проблема не в нехватке software. Команда просто не превратила повторяющуюся рутину в записанный и проверенный процесс.

Ручная ops-работа всё время возвращается, потому что она прячется на виду. Она знакомая. Её обычно всё-таки делают. Один сильный человек постоянно спасает ситуацию. Это выглядит эффективно, пока команде не нужна скорость, стабильность или release в неудобное время.

Найдите рутину, которую стоит автоматизировать первой

Лучший кандидат для автоматизации обычно скучный, частый и его легко забыть.

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

Запишите каждую рутину простыми словами. Отметьте, кто её делает, когда она происходит, как часто возникает и сколько времени реально занимает. Цифры очень помогают. Задача на 12 минут не кажется чем-то большим, пока один engineer не делает её три раза в неделю и каждый раз не теряет фокус.

Обычно несколько признаков показывают, что задача должна быть в начале списка:

• Она происходит каждую неделю или каждый релиз.
• Один человек всегда помнит о ней по памяти.
• Поздний запуск блокирует deploy или возвращает кого-то к работе ночью.
• Шаги повторяются, даже если команда делает вид, что это «просто часть работы».

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

Простой пример всё делает очевидным. Стартап считает, что его релиз занимает 20 минут. Но когда команда записывает всю последовательность, оказывается, что вокруг самого deploy спрятаны ещё 50 минут. Кто-то запускает бэкап. Кто-то очищает старые артефакты. Кто-то проверяет логи. Кто-то подтверждает права пользователей. Ни один из этих шагов несложный. Вместе они тормозят каждый релиз и превращают одного человека в страховочную сетку.

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

Выберите первую задачу

Первая автоматизация должна казаться почти скучной. Это хороший знак.

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

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

Хорошая первая задача обычно проходит четыре проверки:

• Она происходит часто.
• Кто-то может объяснить её в коротком runbook.
• Можно без споров понять, что она сработала.
• Ошибка раздражает, но не приводит к катастрофе.

Ещё один фильтр тоже помогает. Сэкономленное время должно проявиться уже в этом месяце, а не когда-нибудь потом. Экономия 15 минут каждую пятницу лучше, чем планирование огромного automation-проекта, который так и не выйдет в жизнь. Маленькие победы меняют привычки. Большие планы часто становятся ещё одной рутиной.

На первом шаге пропускайте рискованные задачи. Изменения базы данных, разрушительные задачи очистки, правки DNS и чувствительные изменения прав доступа могут подождать. Возможно, позже их тоже стоит автоматизировать, но для начала это плохие тренировочные колёса. Первая рутина должна быть достаточно скучной, чтобы команда доверяла ей уже после нескольких запусков.

Хороший стартовый пример — утренняя проверка по нескольким серверам: статус бэкапа, свободное место на диске, упавшие cron jobs и состояние сервисов. Шаги понятные. Результат легко прочитать. Первая версия может быть простым скриптом, который отправляет короткий отчёт. Никакой сложной платформы не нужно.

Держите объём маленьким. Завершите одну задачу от начала до конца, прежде чем трогать следующую. Скрипт, который проверяет бэкапы и сообщает о проблемах, — более сильный старт, чем «полный ops-bot», который пытается одновременно разворачивать, чистить, мониторить и чинить всё подряд.

Превратите одну еженедельную задачу в рутину

Когда задача выбрана, сначала запишите текущий процесс, и только потом пишите скрипт.

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

Уберите то, что больше не нужно. Команды часто годами держат старые команды после того, как исходная проблема давно исчезла. Если никто не может объяснить, зачем шаг всё ещё нужен, проверьте предположение и уберите его.

Потом перенесите оставшуюся работу в одно место. Это может быть shell script, цель в Make, небольшой Python-файл или GitLab job, если команда уже использует CI. Цель не в элегантности. Цель — в повторяемости. Один и тот же вход должен каждый раз давать один и тот же результат.

Большинству routines нужны одни и те же базовые вещи: понятные входные данные, команды в правильном порядке, читаемые логи и очевидный результат успеха или ошибки.

Сначала проверьте рутину в безопасной среде, прежде чем доверять ей production. Для многих еженедельных задач достаточно staging-сервера, тестовых данных или временного контейнера. Вы хотите увидеть, что ломается, не роняя то, от чего зависят люди.

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

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

Добавьте проверки, прежде чем доверять автоматизации

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

Начните с проверки входных данных. Если скрипт очистки ожидает название проекта, окружение или диапазон дат, пусть он отклоняет пустые значения, неизвестные названия и опасные цели, пока человек их не подтвердит. Короткая пауза на проверку намного дешевле, чем потом восстанавливать данные.

Сделайте вывод понятным. Храните логи в одном общем месте, которое команда уже использует, а не на ноутбуке одного engineer и не в глубине временного контейнера. Хорошие логи быстро отвечают на три вопроса: что запустилось, что изменилось и где всё остановилось.

Alerts тоже важны, но только если они сообщают что-то полезное. «Job failed» — этого мало. Сообщение должно назвать скрипт, цель, шаг, на котором случился сбой, и первый пункт, который нужно проверить. Если ночью ломается бэкап базы данных, дежурному не нужно открывать три разных инструмента, чтобы просто понять проблему.

Инструкции по rollback должны лежать рядом со скриптом, а не в чьей-то голове. Храните их в том же repo и той же папке. Если задача создаёт релиз, заметки по rollback должны показывать, как вернуться к последней стабильной версии, как проверить, что откат сработал, и кому нужно об этом знать.

Для первых нескольких запусков добавьте человеческую проверку. Один teammate должен сравнить результат с ожидаемым и отметить всё странное. Такая проверка быстро ловит мелочи, которые убивают доверие: неверные timestamps, пропущенные hosts или тихие частичные сбои.

Для большинства еженедельных ops-задач достаточно простой базы безопасности:

• Проверяйте входные данные до первого запуска команды.
• Пишите логи в общее место с временными метками.
• Отправляйте alerts с контекстом и следующим шагом.
• Храните заметки по rollback рядом со скриптом.
• Попросите teammate проверить первые несколько запусков.

После трёх-пяти чистых запусков люди начинают доверять рутине. До этого считайте, что у неё ещё есть шероховатости.

Пример для небольшой команды

У стартапа из пяти человек была неприятная пятничная привычка. Основатель заходил на сервер, удалял старые файлы, чтобы освободить место на диске, перезапускал несколько фоновых workers и проверял, двигаются ли jobs дальше. В спокойную неделю это занимало около 40 минут. В плохую — час и задерживало всех остальных.

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

Именно такие задачи и стоит автоматизировать.

Команда не стала покупать ещё одну платформу. Сначала они написали две небольшие вещи: скрипт очистки и health check. Скрипт очистки удалял старые временные файлы, ротацировал логи, чистил одну известную директорию кэша и перезапускал workers в правильном порядке. Затем health check подтверждал свободное место на диске, проверял, что workers работают, и следил, чтобы очередь уменьшалась, а не росла.

Две недели они всё ещё запускали оба шага вручную. Звучит медленно, но это уберегло их от очень обычной ошибки. На одном прогоне они заметили, что workerу нужно ещё 20 секунд, прежде чем он станет healthy. На другом скрипт задел папку, которая выглядела безопасной, но хранила свежие загрузки. Они исправили обе проблемы до того, как поставили что-либо на расписание.

Только потом они перевели это в timed job. Каждый понедельник утром команда смотрела короткий отчёт: сколько было места на диске до и после, какие workers перезапустились и прошёл ли health check.

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

Ошибки, из-за которых работы становится больше

Самая частая ошибка — автоматизировать грязный процесс, не приведя его сначала в порядок.

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

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

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

Команды ещё и тратят время впустую, когда покупают новый инструмент до того, как запишут реальные рутинные задачи. Инструмент может помочь, но он не скажет вам, что ваша команда действительно делает каждый вторник в 16:00. Сначала перечислите повторяющиеся задачи. Посчитайте, как часто они происходят, сколько времени занимают и что идёт не так. Этот список обычно подсказывает лучший первый кандидат, чем любой demo продукта.

Несколько недостающих вещей почти сразу создают дополнительную работу: нет логов, нет alerts при зависании задачи, нет заметок по rollback, слабые правила для входных данных и нет понятного владельца после запуска.

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

Назначайте каждой автоматизированной задаче конкретного владельца. Ему не нужно нянчить её вечно. Ему достаточно время от времени проверять её, держать заметки актуальными и решать, когда что-то починить, заменить или убрать. Автоматизация экономит время только тогда, когда кто-то делает её скучной и предсказуемой.

Быстрые проверки, прежде чем считать задачу законченной

Задача не завершена только потому, что она запускается по таймеру.

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

Хорошо работает простой тест: может ли другой человек понять задачу примерно за минуту? Он должен суметь сказать, что она делает, когда запускается, что может пойти не так и как понять, что она сработала. Если на это нужен длинный рассказ, рутину ещё нужно дорабатывать.

Прежде чем считать дело сделанным, проверьте несколько базовых вещей:

• Teammate может объяснить задачу без помощи автора.
• Новый сотрудник может запустить её по письменным шагам и получить тот же результат.
• Скрипт отклоняет плохие входные данные до того, как что-то изменит.
• Alerts называют сбой и дают понятный следующий шаг.
• Команда реально экономит время две недели подряд.

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

Проверка входных данных сильно сокращает последующую уборку. Если скрипт ожидает имя сервера, диапазон дат или окружение, он должен остановиться на опечатке или опасном значении. Быстрое падение лучше, чем чинить сломанный deploy, неправильный путь для бэкапа или отчёт, построенный не по тем данным.

Alerts должны помогать сонному дежурному. «Job failed» — слабое сообщение. «Backup failed on db-prod-2. Disk full. Check free space on /data and rerun backup-cleanup» даёт человеку точку старта.

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

Что делать дальше

На этой неделе запишите все ops-задачи, которые кто-то повторяет вручную. Пишите просто: ротацировать логи, очищать старые images, перезапускать зависший worker, проверять бэкапы, продлевать сертификат. Если человек делает это каждую неделю, задача должна быть в списке.

Потом жёстко сократите список. Выберите одну задачу, которая скучная, частая и легко проверяется. Работа, которая съедает 15–30 минут и каждый раз выполняется по одному и тому же сценарию, обычно лучший первый кандидат, чем блестящая новая платформа.

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

После этого посмотрите, что у вас уже есть. Многие команды платят за ещё один dashboard, очередь или платформу, прежде чем начнут использовать инструменты, которые уже стоят перед ними. Маленький скрипт, cron job, CI pipeline или внутренний инструмент часто убирают еженедельную боль дешевле и с меньшей настройкой.

Держите первый проход небольшим. Запустите его рядом с ручной задачей один или два раза. Проверьте логи. Убедитесь, что alerts срабатывают. Проверьте, что владелец знает, что делать, если что-то сломается.

Если команда слишком близко к хаосу или слишком занята, чтобы навести порядок, внешняя помощь может ускорить процесс. Oleg Sotnikov на oleg.is работает как Fractional CTO и startup advisor, помогает командам сокращать ручную ops-работу, упрощать инфраструктуру и строить компактную автоматизацию без лишних инструментов.

На сейчас достаточно убрать из рутины одну скучную еженедельную задачу. Закончите её, докажите, что она работает, и только потом выбирайте следующую рутину из списка.