Автономная система самовосстановления без кнопки разрешения: устройства, работающие в 3 часа ночи

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

Что идет не так, когда исчезают контрольные механизмы

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

Правильная команда, выполняемая в масштабах

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

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

Отчет о восстановлении, составленный с учётом целей

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

Это порождает строгое правило отчетности. Фраза вроде «восстановлено N из N» допускается только рядом с выводом команды, который восстанавливает этот статус. Без таких доказательств правильной формулировкой будет «отправлена команда на восстановление».

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

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

1. Рутина не может быть сама собой ремонтником

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

Необходимо контролировать возраст вывода рутины, а не её код выхода. Задача, которая завершается со статусом 0 и не записывает ничего, кажется совершенно здоровой при проверке кода выхода. Вполне возможно, что такая задача останется незамеченной на несколько недель. Проверка свежести («файл отчета моложе 26 часов», «последняя строка в таблице — сегодняшняя») выявляет именно те сбои, которые скрываются кодами статуса.

2. Классифицируйте действия, а не утверждения

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

Рабочей альтернативой является классификация самих действий по уровням:

• Автоматические, без участия человека, в любое время: перезапуск застрявшей службы, повторная регистрация сбросившейся запланированной задачи, снятие устаревшего блокировки, повторная обработка идемпотентного импорта, воссоздание индекса. Эти действия ограничены, обратимы и безопасны для повторения.

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

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

Благодаря этому первый уровень работает в полной автономии всю ночь, третий уровень ожидает обработки в утреннем отчете, и никто не кликает ни на что в 3 часа ночи. Не менее важно то, что в 3 часа ночи не происходит ничего необратимого.

Запись классификации делает решение о доверии явным, позволяет его проверять и изменять в одном файле. Это то же самое доверие, которое предоставляет механизм разрешения кликов, но оно хранится в месте, где его можно аудитировать и тестировать. Для более подробного рассмотрения уровней риска и правил одобрения для агентов в целом ознакомьтесь с нашим руководством по разрешениям, правилам одобрения и уровням риска.

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

Установка исправления на все узлы одновременно сама по себе является точкой отказа: если исправление неверно, оно будет неверным везде сразу. Вместо этого выполняйте его в несколько этапов:

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

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

4. Не создавайте устройство для ремонта при первой же неисправности

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

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

5. Дайте каждой запущенной сессии самодостаточное описание задачи

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

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

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

Когда один сотрудник утверждает работу другого

Распространённым предложением является разрешение одному агенту утверждать действия другого, например в общем чате, где агент-руководитель просит сотрудника продолжить работу. Существуют готовые инструменты для инициирования сессий таким образом. Эта модель хорошо работает для действий первого уровня. Именно также происходит утверждение действий третьего уровня в 3 часа ночи, если они не имеют особых отличий. Как только действия становятся обратимыми, утверждение их агентом-агенту становится безопасным в использовании, поскольку руководитель может утвердить только то, что уже разрешено классификацией.

Основные выводы

• Размещайте процесс ремонта вне самого объекта, который ремонтируется, и оценивайте его состояние по свежести результатов, а не по кодам выхода.
• Замените нажатие кнопки утверждения письменной классификацией действий с учётом их обратимости и возможного влияния.
• Для массовых, общеклассовых или необратимых операций требуйте однострочного подтверждения с указанием объёма действий и стоимости отката.

Отмечайте, что проблема «исправлена», только если имеются доказательства восстановления состояния; в противном случае указывайте то, что было отправлено.

Исправления внедряются сначала через канарейку и узел другого типа, а затем уже во всей сети.

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