Автоматизація з самовідновленням без кнопки дозволу: пристрої, які працюють о 3 години ранку

Як тільки команда запускає десятки запланованих процедур та сесій агентів, наступне бажання стає очевидним: коли процедура зустрічає помилку в собі чи у своєму середовищі, вона має самостійно усунути первинну причину або створити окрему сесію, яка це зробить, без необхідності отримання схвалення для кожного кроку посеред ночі. Мета розумна. Однак небезпека полягає у тому, що найшвидший шлях до неї — усунення механізмів схвалення чи автоматизація дій — перетворює незначну несправність на інцидент у всій мережі, до того ж із хибним сигналом про усунення проблеми. Цей посібник показує, як досягти справжнього автономного ремонту, зберігаючи єдине важливе критерії — чи можна скасувати певну дію.

Що йде не так, коли зникають механізми контролю

Два типи збоїв постійно зустрічаються у автоматизованих операціях, і обидва варто вивчити перед тим, як щось будувати.

Правильна команда, виконана у масштабі

Рішенням є правило, достатньо коротке для запам’ятовування: будь-яка команда, яка впливає на велику кількість об’єктів, вимикає цілу категорію завдань чи не може бути скасована, отримує один рядок підтвердження перед виконанням. У цьому рядку вказується, що буде змінено та які наслідки матиме скасування. Його читання займає секунду; відновлення після інциденту без нього займає годину чи більше.

Друга проблема є більш прихованою. Після такого інциденту у записах про відновлення зазначається щось на кшталт „відновлено 30 з 30“. Через кілька днів перевірка за актуальним графіком показує, що 27 завдань все ще вимкнені, серед них резервне копіювання конфігурації, монітор синхронізації та механізм контролю сеансу. Рядок статусу був заповнений на основі того, що мав зробити оператор, а не на основі того, що фактично показувала система.

Це призводить до суворого правила звітності. Фраза на кшталт „відновлено N з N“ дозволяється лише поруч із результатом виконання команди, який підтверджує цей статус. Без таких доказів правильним формулюванням буде „надіслано команду на відновлення“.

Це є основним ризиком автоматичного відновлення. Фахівець, який оголошує про успіх, не перевіривши результат, гірший, ніж взагалі жоден фахівець, адже це перетворює збою на збій разом із впевненим повідомленням про те, що все гаразд.

П’ять правил для автономного ремонту

1. Рутина не може бути власним ремонтником

Якщо рутина пошкоджена, її вбудована логіка саморемонту зазвичай також пошкоджується, і обидві функції беззвучно виходять з ладу одночасно. Ремонт має знаходитися на наступному рівні: окремий процес, бажано на окремій машині, який стежить за рутиною ззовні.

Він повинен стежити за віком результату роботи рутини, а не за її кодом завершення. Завдання, яке завершується зі статусом 0 та нічого не записує, виглядає абсолютно справним за будь-якою перевіркою коду завершення. Цілком можливо, що таке завдання залишиться непоміченим протягом тижнів. Перевірка свіжості („файл звіту молодший за 26 годин“, „останній рядок у таблиці — сьогоднішній“) виявляє саме ті проблеми, які приховують коди статусу.

2. Класифікуйте дії, а не схвалення

Запит щодо того, щоб „ніхто не міг натискати «дозволити» вночі“, є обґрунтованим, але бот, який автоматично натискає «дозволити», — це неправильне рішення. Він стирає єдину рядок, який справді має значення — той, що розділяє дії, які можна скасувати, від дій, яких не можна, і робить це найшвидше саме тоді, коли немає людини, яка б спостерігала. Крім того, це приховує рішення: хтось все одно вирішив, що ці дії безпечні, а бот просто приховує, хто та коли ухвалив це рішення.

Робочою альтернативою є класифікація самих дій за рівнями:

• Автоматично, без участі людини, у будь-який час: перезапуск застряглої служби, повторна реєстрація запланованої задачі, яка зазнала збою, скидання застарілого блокування, повторна обробка імпорту, відновлення індексу. Це дії з обмеженими наслідками, які можна скасувати та безпечно повторювати.

Автоматично з гучним повідомленням: зміна конфігурації на окремому вузлі, перевстановлення залежностей, оновлення кешу. Вони виконуються, а людина перевіряє те, що сталось після цього.

Ніколи не автоматично, чергується на ранок: все, що стосується грошей, видалень, облікових даних, повідомлень, надісланих від імені людини, змін схеми чи масових дій у всьому флоті.

Завдяки цьому перший рівень працює повністю автономно протягом ночі, третій рівень очікує у ранковому звіті, і ніхто не клацає нічим о 3 годині ранку. Не менш важливо те, що о 3 годині ранку не відбувається нічого незворотного.

Запис класифікації робить рішення щодо довіри чітким, підлягаючим перевірці та зміні в одному файлі. Це такий самий рівень довіри, який надає інструмент allow-clicker, але він зберігається у місці, де можна проводити аудит та тестування. Для більш детального розгляду рівнів ризику та процедур схвалення для агентів загалом дивіться наш посібник про дозволи, процедури схвалення та рівні ризику.

3. Спочатку канаркові узли, потім весь флот

Впровадження виправлення одночасно на всі вузли є самим по собі точкою відмови: якщо виправлення неправильне, воно буде неправильним усюди одразу. Краще впроваджувати його поетапно:

• застосувати зміни до одного вузла
• перевірити, прочитавши отриманий стан, а не покладаючись на код повернення
• застосувати їх до другого вузла іншого типу
• лише тоді розповсюдити їх на всіх

Назвіть процедуру скасування змін ще до початку, щоб її виконання було загальновідомою процедурою, а не імпровізацією під тиском.

4. Не створюйте пристрій для усунення несправностей вже після першої проблеми

Автоматичні пристрої для ремонту легко множаться, адже кожна поодинока помилка здається гідною власного робота. Певний поріг стримує це явище. Перша поява проблеми фіксується одним записом у журналі з датою. Механізм створюється лише тоді, коли така сама категорія несправностей трапляється втретє, і лише за наявності конкретного користувача, який його потребує.

Без такого правила накладні витрати можуть зрости до тривожних рівнів. Одна команда, яка вимірювала свою роботу, виявила, що 82% її роботи стало «мета-роботою» — пристроями, створеними для керування іншими пристроями. Автоматизація ремонту — саме та категорія, яка найбільш схильна до цього спіралеподібного розвитку.

5. Надайте кожній запущеній сесії самодостатню інструкцію

Сесія, запущена о 4 ранку спостережною групою, не має того контексту, який був у процесі, що виявив проблему. Необхідно надати їй інформацію, яка містить:

• що зламалося
• докази
• що вже було спробовано
• межі того, чим можна займатися
• визначення завершення роботи

Ці межі — це те, про що люди забувають. Без них ентузіастичний працівник може допомогти виправити сусідні елементи, про які ніхто не просив, через що невелике виправлення перетворюється на широкі зміни без перевірки.

Коли один працівник схвалює іншого

Поширеною пропозицією є дозволити одному агенту схвалювати іншого, наприклад у спільному чаті, де агент-керівник просить працівника продовжити роботу. Існують готові інструменти для ініціювання сеансів у такий спосіб. Ця модель добре підходить для першого рівня дій. Саме так також схвалюються дії третього рівня о 3 години ночі, якщо вони не мають особливих ознак. Як тільки дії стають зворотно простими, схвалення агентом-агенту стає безпечним для використання, оскільки керівник може схвалити лише те, що вже дозволено класифікацією.

Ключові висновки

• Розміщуйте процес ремонту поза самим об’єктом, який ремонтують, та оцінюйте стан об’єкта за свіжістю результатів, а не за кодами вихіду.
• Замініть натискання кнопки схвалення на письмову класифікацію дій за критеріями зворотності та впливу.
• Вимагайте однорядкового підтвердження для масових, загальнокласових чи незворотних замовлень, у якому мають бути вказані обсяг та витрати на скасування.

Відзвітуйте про „виправлення“ лише у разі наявності доказів відтворення стану; інакше повідомте про те, що було надіслано.

Впровадження виправлень відбувається через канарковий вузол та другий вузол іншого типу перед усіма іншими.

Створюйте автоматизацію на третьому виникненні певної категорії помилок, а не на першому, та інформуйте кожну запущену сесію про обсяг завдань та критерії його виконання.