Каждый понедельник — одно и то же. Кто-то должен был запустить еженедельный импорт. И снова не запустил. Data-команда ждёт, продуктовая раздражена, а единственный человек, который знает, как это делается, — в отпуске, ноутбук выключен, ровно там, где и должен быть. Это история о том, как я решил автоматизировать еженедельный импорт данных, который тихо превратился в забытую задачу, державшуюся на памяти одного человека, — cron-задачу, которой никогда не было, а вместо неё всё зависело от того, вспомнит ли кто-то нажать кнопку в шесть утра.
Паттерн, который никто не называет вслух
Опишу схему — почти наверняка у вас где-то есть такая же.
Критичный импорт данных запускался раз в неделю. Вручную. Одним человеком. Креды жили где-то между общим документом и его собственной головой. Мониторинга не было никакого: если импорт падал, об этом узнавали через несколько часов — когда кто-то ниже по цепочке наконец жаловался, что цифры несвежие.
Сценарий провала всегда был один и тот же:
- Ответственный забыл, проспал или был не на месте.
- Импорт тихо не отработал.
- Data-команда в панике, продуктовая — в ярости.
- «Решение» — напомнить человеку в следующий раз запустить пораньше.
Вот эта последняя строчка — и есть диагноз. Когда лекарство от аварии звучит как «напомнить человеку быть надёжнее», у вас не проблема с людьми. У вас инженерная дыра, которую вы раз за разом решаете не закрывать.
В ту неделю, когда всё вскрылось окончательно, ответственный ушёл в отпуск. Кредов не знал больше никто. Шагов не знал никто. Data-команда дотерпела до 11 утра, прежде чем кто-то вообще спросил: «а импорт-то отработал?» Не отработал.
Что я в итоге собрал
Вся замена заняла меньше дня, и ничего экзотического в ней нет. В этом и есть неприятная правда — это всегда решалось.
- Scheduled-триггер в Azure срабатывает каждый понедельник в 6 утра, пока все спят. Ни человека в цикле, ни кнопки.
- Bash-скрипты рулят прогоном — забирают источник, проверяют, что импортированные данные и правда выглядят вменяемо, и сами ретраят на временных сбоях, а не умирают на первой же икоте.
- Креды переехали в Key Vault вместо блокнота. Скрипты читают их в рантайме; никто не хранит их там, где они протухнут или утекут.
- Slack-алерт при исчерпании ретраев. Если задача реально не может восстановиться, команде мгновенно прилетает пинг — они узнают до стендапа, а не после того, как заметит стейкхолдер.
- Каждый прогон логируется. Успех или падение — есть аудит. На вопрос «понедельничный импорт отработал?» отвечает дашборд, а не пожатие плечами.
Обратите внимание, что убирает каждый кусок. Расписание убирает необходимость помнить. Валидация — тихие битые данные. Ретраи — хрупкость. Key Vault — зависимость от одного человека с кредами. Алертинг — многочасовую дыру в обнаружении. Логи — сам вопрос «а оно вообще запускалось?».
Результат
С момента запуска автоматизации — ноль пропущенных импортов. Ни одного. Данные готовы до стендапа каждую неделю. Никому не нужно помнить, никому не нужно бодрствовать, никому не нужно быть на связи.
И вот часть, которую никто не ждал. Человек, который был единой точкой отказа, — тот самый, что не мог до конца выдохнуть и на выходных заходил в Slack «на всякий случай», — впервые за месяцы ушёл в настоящий отпуск. Оставил ноутбук дома. Потому что система больше в нём не нуждалась.
Для меня в этом вся суть. Автоматизация — это не только про метрики аптайма. Это про то, чтобы не превращать коллегу в cron с ногами.
Настоящий урок
Если человек обязан помнить, что раз в неделю надо что-то запустить, — рано или поздно это забудут. Не потому что раздолбай, а потому что человек: люди уходят в отпуск, меняют работу или просто ловят паршивый понедельник. Ставить свой data-pipeline на то, что паршивого понедельника не случится ни у кого и никогда, — это не стратегия.
И вот вопрос, с которым стоит посидеть. Где-то в вашей команде прямо сейчас один человек держит весь контекст процесса, которого больше не понимает никто. Представьте, что завтра он приносит заявление.
Стало чуть тревожно? Вот и хорошо. Вот эту задачу и автоматизируйте первой.