Почему я начал автоматизировать мелочи и перестал ждать

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

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

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

С чего всё началось

Спойлер: я не строил никакой сложной платформы и не запускал проект на квартал. Всё началось с одного простого скрипта, который проверял доступность сервисов и писал мне в мессенджер, если что-то падало. Раньше я сам заходил на панель управления и смотрел статусы. Звучит смешно, но именно этот скрипт сэкономил мне первые полчаса в день.

Дальше — больше. Я добавил уведомление, которое напоминало мне о зависших ревью. Не всем, а только мне. Если мой запрос на проверку кода висел больше двух часов, я получал сообщение. И знаете, что интересно? Оказалось, что чаще всего я просто забывал напомнить коллеге. Не потому что он плохой, а потому что у всех своя рутина.

Потом я автоматизировал сборку релизного чек-листа. Раньше я собирал его руками, копируя пункты из разных документов. Теперь скрипт сам подтягивает нужные данные из задач и формирует список. Мне остаётся только пробежаться глазами и нажать кнопку.

Десять сценариев, которые реально работают

Через пару месяцев таких экспериментов у меня набралось около десяти сценариев, которые крутятся постоянно. Вот основные из них:

• Автоматическая проверка доступности всех сервисов с уведомлением в общий чат.

• Напоминание о зависших запросах на ревью — через два и через четыре часа.

• Формирование чек-листа релиза из связанных задач.

• Отслеживание изменений в конфигурационных файлах и оповещение о подозрительных правках.

• Автоматический сбор логов после падения сервиса — чтобы не искать их руками в трёх местах.

• Проверка наличия свежих бэкапов и уведомление, если что-то не записалось.

• Мониторинг свободного места на дисках — с предупреждением за день до критической отметки.

• Автоматическое создание задачи на тестирование, когда код уходит в ревью.

• Уведомление о том, что кто-то из команды закоммитил код в неправильную ветку.

• Еженедельный отчёт о том, сколько времени мы реально тратим на ожидание между этапами.

Если честно, некоторые из этих сценариев звучат банально. Но именно они убрали те самые паузы, из-за которых time-to-market растягивался на дни.

Экономика вопроса

Я посчитал, сколько времени это экономит в неделю. Получилось около четырёх-пяти часов. Казалось бы, не так уж много. Но если пересчитать на месяцы, то это два полных рабочих дня, которые раньше уходили в никуда.

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

Критерий, по которому я решаю, что автоматизировать

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

И ещё одно наблюдение. Самое сложное — не написать скрипт, а заметить, что ты вообще занимаешься ерундой. Мы привыкаем к рутине и перестаём её замечать. Я, например, месяцами вручную проверял статусы серверов, пока однажды не спросил себя: а зачем я это делаю, если можно поручить это машине?

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