Щопонеділка — те саме. Хтось мав запустити щотижневий імпорт. І знову не запустив. Data-команда чекає, продуктова роздратована, а єдина людина, яка знає, як це робиться, — у відпустці, ноутбук вимкнено, рівно там, де й має бути. Це історія про те, як я вирішив автоматизувати щотижневий імпорт даних, що тихенько став забутою задачею, яка трималася на пам'яті однієї людини, — cron-задачею, якої ніколи не було, а натомість усе залежало від того, чи згадає хтось натиснути кнопку о шостій ранку.
Патерн, який ніхто не називає вголос
Опишу схему — майже напевно у вас десь є така сама.
Критичний імпорт даних запускався раз на тиждень. Вручну. Однією людиною. Креди жили десь між спільним документом і її власною головою. Моніторингу не було жодного: якщо імпорт падав, про це дізнавалися за кілька годин — коли хтось нижче по ланцюжку нарешті скаржився, що цифри несвіжі.
Сценарій провалу завжди був той самий:
- Відповідальний забув, проспав або був не на місці.
- Імпорт тихо не відпрацював.
- Data-команда в паніці, продуктова — у люті.
- «Рішення» — нагадати людині наступного разу запустити раніше.
Ось цей останній рядок — і є діагноз. Коли ліки від аварії звучать як «нагадати людині бути надійнішою», у вас не проблема з людьми. У вас інженерна діра, яку ви раз за разом вирішуєте не закривати.
Того тижня, коли все вилізло остаточно, відповідальний пішов у відпустку. Кредів не знав більше ніхто. Кроків не знав ніхто. Data-команда дотерпіла до 11-ї ранку, перш ніж хтось узагалі спитав: «а імпорт відпрацював?» Не відпрацював.
Що я зрештою зібрав
Уся заміна зайняла менше дня, і нічого екзотичного в ній немає. У цьому й є неприємна правда — це завжди вирішувалося.
- Scheduled-тригер в Azure спрацьовує щопонеділка о 6 ранку, поки всі сплять. Ні людини в циклі, ні кнопки.
- Bash-скрипти керують прогоном — забирають джерело, перевіряють, що імпортовані дані справді виглядають адекватно, і самі роблять retry на тимчасових збоях, а не вмирають на першій же гикавці.
- Креди переїхали в Key Vault замість блокнота. Скрипти читають їх у рантаймі; ніхто не тримає їх там, де вони протухнуть чи витечуть.
- Slack-алерт при вичерпанні retry. Якщо задача реально не може відновитися, команді миттєво прилітає пінг — вони дізнаються до стендапу, а не після того, як помітить стейкхолдер.
- Кожен прогін логується. Успіх чи падіння — є аудит. На питання «понеділковий імпорт відпрацював?» відповідає дашборд, а не знизування плечима.
Зверніть увагу, що прибирає кожен шматок. Розклад прибирає потребу пам'ятати. Валідація — тихі биті дані. Retry — крихкість. Key Vault — залежність від однієї людини з кредами. Алертинг — багатогодинну діру у виявленні. Логи — саме питання «а воно взагалі запускалося?».
Результат
Від моменту запуску автоматизації — нуль пропущених імпортів. Жодного. Дані готові до стендапу щотижня. Нікому не треба пам'ятати, нікому не треба не спати, нікому не треба бути на зв'язку.
І ось частина, якої ніхто не чекав. Людина, яка була єдиною точкою відмови, — та сама, що не могла до кінця видихнути й на вихідних заходила в Slack «про всяк випадок», — уперше за місяці пішла в справжню відпустку. Залишила ноутбук удома. Бо система більше її не потребувала.
Для мене в цьому вся суть. Автоматизація — це не лише про метрики аптайму. Це про те, щоб не перетворювати колегу на cron із ногами.
Справжній урок
Якщо людина зобов'язана пам'ятати, що раз на тиждень треба щось запустити, — рано чи пізно це забудуть. Не тому що недбала, а тому що людина: люди йдуть у відпустку, змінюють роботу або просто ловлять кепський понеділок. Ставити свій data-pipeline на те, що кепського понеділка не станеться ні в кого й ніколи, — це не стратегія.
І ось питання, з яким варто посидіти. Десь у вашій команді просто зараз одна людина тримає весь контекст процесу, якого більше не розуміє ніхто. Уявіть, що завтра вона подає заяву.
Стало трохи тривожно? От і добре. Ось цю задачу й автоматизуйте першою.