Моя ночная смена, которая никогда не спит, и предохранители, благодаря которым я ей доверяю

Часть самой полезной моей работы делается, пока я сплю. Рутинные задачи идут ночью, и утром я просыпаюсь к готовому результату: что-то прибрано, что-то обобщено, что-то подготовлено и ждёт меня. Звучит как мечта об автоматизации, и это действительно она, ровно до того момента, когда в три часа ночи что-то ломается, а рядом никого. Вот о чём никогда не говорят любители «автоматизируй всё»: работа без присмотра ценна только тогда, когда ей можно доверять без присмотра. Иначе вы просто собрали машину, которая тихо устраивает беспорядок, пока вы спите. Расскажу, как я сделал ночную автоматизацию достаточно надёжной, чтобы на неё реально полагаться. И почти вся соль — в скучной части.

Коротко

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

Мечта и подвох

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

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

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

Так что настоящая задача — не «запустить это ночью». Это как раз просто. Настоящая задача — сделать так, чтобы за этим можно было не следить. Совсем другое дело, и куда важнее.

Предохранитель первый: она всегда мне сообщает

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

Звучит банально. И это самое важное из всего.

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

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

Предохранитель второй: она падает безопасно

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

Сломавшийся ночной запуск должен быть пустяком. Просто не случился, сам мне об этом сказал, а разберусь я после кофе. Вот цель проектирования. Худшее, что допустимо, — «ничего не произошло, и меня предупредили», но никогда не «случилось что-то плохое, а я не знал».

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

Предохранитель третий: она чинится сама или зовёт меня

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

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

Что это значит, если вы автоматизируете для команды

Урок масштабируется напрямую. Когда вы что-то автоматизируете, первый порыв — порадоваться сэкономленному времени. Дисциплина в том, чтобы сначала спросить: как мы узнаем, что это сломалось, и что произойдёт, когда сломается?

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

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

Что бы я сделал иначе

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

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

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