Отключение питания во время аудируемого действия агента оставляет результат неизвестным

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

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

Именно здесь журнал аудита приносит пользу. Он должен сохранять то, что известно локальной системе, подтверждать, что сохраненные записи не были незаметно изменены, и показывать неопределенность, а не скрывать ее. Он не может превратить потерянный ответ в доказательство того, что запись в базе данных, платеж, развертывание или удаленная команда не произошли.

Тайм-аут означает пробел в доказательствах, а не подтвержденную ошибку

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

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

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

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

Люди часто слишком рано добавляют еще один статус, «частично выполнено». Используйте его только тогда, когда можете назвать завершенную и незавершенную части операции. Если конвейер развертывания создал артефакт, но не выполнил его продвижение, результат частичный, когда оба факта подтверждены. Если запрос исчез после записи клиентом байтов в сокет, результат неизвестен, даже если запрос выглядел простым.

RFC 9110 проводит такое же различие на уровне протокола. Он допускает автоматическую повторную отправку идемпотентных методов после сбоя связи, поскольку повторение операции имеет тот же предполагаемый эффект. При этом стандарт предостерегает от автоматического повтора неидемпотентного запроса, если клиент не может установить, что исходный запрос не был применен, или не знает, что приложение безопасно обрабатывает повторы. Это правило семантики, а не прием транспортного уровня.

Шлюз действий агента должен точно сообщать локальные факты. Формулировка «Запрос отправлен, завершение не наблюдалось» полезна. Формулировка «Действие завершилось ошибкой» может быть утверждением, которое локальный процесс не вправе делать.

Отключение питания разделяет действие на границы надежного сохранения

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

У типичного HTTP-действия есть как минимум такие границы:

1. Шлюз принимает разрешенное намерение и записывает его локально.
2. Шлюз формирует аутентифицированный запрос и начинает его передачу.
3. Удаленный сервис получает достаточно запроса, чтобы начать обработку.
4. Удаленный сервис фиксирует побочный эффект и создает квитанцию.
5. Шлюз получает ответ и записывает наблюдаемый результат.

SSH-действие проходит похожий путь, но удаленный узел может запустить команду до того, как локальный клиент узнает ее код завершения. Узел также может породить работу, которая переживет сессию. Успешное TCP- или SSH-соединение почти ничего не говорит о том, где остановилась команда.

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

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

Для расследования присваивайте каждой записи класс доказательств, а не относитесь ко всем временным отметкам как к одинаково надежным:

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

До тестирования сбоев задайте идентификатор каждой операции с побочным эффектом

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

По возможности используйте два идентификатора:

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

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

Если API поддерживает ключи идемпотентности, явно передавайте идентификатор в запросе и записывайте хеш значимой части полезной нагрузки. Хеш помогает обнаружить случайную попытку повторно использовать старый ключ с измененным запросом.

POST /v1/releases HTTP/1.1
Host: deploy.example.internal
Idempotency-Key: 8b4dbdb6-61e1-49ea-a5b5-9ae225eb2af1
Content-Type: application/json

{
  "operation_id": "8b4dbdb6-61e1-49ea-a5b5-9ae225eb2af1",
  "service": "catalog",
  "artifact": "sha256:3c1f...",
  "environment": "production"
}

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

Полезная запись о намерении может выглядеть так:

{
  "event": "intent_accepted",
  "action_id": "act_01JX8F3Z6Z",
  "operation_id": "8b4dbdb6-61e1-49ea-a5b5-9ae225eb2af1",
  "channel": "http",
  "destination": "deploy.example.internal",
  "method": "POST",
  "path": "/v1/releases",
  "payload_sha256": "3c1f...",
  "authorization": "approved_for_session"
}

Такая запись предотвращает распространенную ошибку расследования: кто-то сравнивает повтор с первым действием только по времени и конечной точке, не замечает изменившийся артефакт или учетную запись и объявляет разные операции одинаковыми.

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

ssh [email protected] \
  '/usr/local/bin/release --operation-id 8b4dbdb6-61e1-49ea-a5b5-9ae225eb2af1 --artifact sha256:3c1f...'

Если команда запускает фоновый рабочий процесс, он должен сохранить идентификатор операции до изменения состояния. Иначе разрыв соединения оставит узел, который, возможно, продолжает работу, но найти ее будет невозможно.

Моделируйте прерывания на границах, которые меняют решение

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

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

Начните с пяти случаев:

1. Сбой до сохранения намерения. Действие должно отсутствовать в надежном локальном журнале и у адресата. Если адресат изменился, порядок операций неверен или действие выполнил другой компонент.
2. Сбой после сохранения намерения, но до отправки. Журнал должен показывать принятое действие без записи об отправке. Классифицировать его как невыполненное можно только тогда, когда шлюз докажет, что не передавал действие транспортному уровню или исполнителю.
3. Сбой во время передачи запроса. Адресат мог не увидеть ничего, получить часть запроса или получить его полностью. Считайте результат неизвестным, если адресат не предоставил однозначный отказ или результат поиска.
4. Сбой после фиксации результата на удаленной стороне, но до сохранения локального завершения. Адресат должен показывать операцию завершенной, а в локальном журнале не должно быть события завершения. Именно этот тест выявляет опасную логику повторов.
5. Сбой после сохранения локального завершения, но до получения ответа агентом. Локальный журнал содержит ответ, хотя агент считает вызов завершившимся по тайм-ауту. Новая сессия агента должна запросить запись действия, а не выполнять операцию вслепую повторно.

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

# Терминал 1: запустить тестовый адресат с управляемыми паузами.
./test-api --pause-after=commit --state-file ./tmp/remote-state.json

# Терминал 2: выполнить одно разрешенное действие с известным идентификатором операции.
./gateway-test invoke \
  --operation-id 8b4dbdb6-61e1-49ea-a5b5-9ae225eb2af1 \
  --pause-file ./tmp/client-dispatch.pause

# Когда адресат сообщит «committed», завершить локальный процесс.
kill -9 "$(pgrep -f 'gateway-test invoke')"

# Терминал 3: проверить адресат, не выполняя новую мутацию.
./test-api lookup 8b4dbdb6-61e1-49ea-a5b5-9ae225eb2af1

kill -9 проверяет сбой процесса. Он не проверяет поведение хранилища при жестком отключении питания и не отменяет действие, которое удаленный сервис уже принял. Для изучения классификации результатов это полезное ограничение: оно заставляет команду перестать считать завершение вызывающего процесса доказательством состояния вызываемой системы.

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

Журнал аудита должен сообщать, что ему известно, и сохранять пробелы

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

Для прерванного действия записывайте отдельные события, а не перезаписывайте одно изменяемое поле статуса. Последовательность событий только для добавления позволяет показать факты, не выдумывая итог:

intent_accepted     action=act_01JX8F3Z6Z op=8b4d... principal=agent-process
transport_started   action=act_01JX8F3Z6Z channel=http
outcome_unobserved  action=act_01JX8F3Z6Z reason=local-process-terminated
reconciled_success  action=act_01JX8F3Z6Z receipt=rel_4921 source=remote-api

Третья строка не должна говорить remote_failed. Она сообщает только, что шлюз не увидел конечный результат. Четвертая строка добавляет более позднее утверждение от источника, которому принадлежит состояние выпуска.

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

Sallyport строит журналы Sessions и Activity из одного зашифрованного журнала с хеш-цепочкой, который не предназначен для чтения, а sp audit verify проверяет эту цепочку офлайн поверх шифротекста. Это дает расследователю надежный способ проверить, изменялась ли сохраненная локальная история, но оставляет удаленный результат удаленным доказательствам, когда это необходимо.

Храните доказательства разрешения отдельно от доказательств результата. Разрешение показывает, что человек или настроенный контроль позволил выполнить действие. Оно не доказывает завершение действия. Смешение этих утверждений превращает разрешенное, но прерванное изменение в ошибочно зарегистрированное завершенное изменение.

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

Сетевым вызовам нужна удаленная сверка, а не оптимизм

Когда HTTP-вызов теряет ответ, адресат обычно является источником истины о том, изменилось ли запрошенное состояние. Сначала запросите его, а уже потом повторяйте операцию. Запрос должен однозначно отличать это действие от похожей работы.

Самый безопасный порядок сверки такой:

1. Найдите у адресата идентификатор операции или ключ идемпотентности.
2. Если адресат возвращает завершенную операцию, сравните идентификаторы ресурсов и хеш полезной нагрузки с исходным намерением.
3. Если он возвращает сохраненный отказ, сохраните этот ответ как доказательство ошибки.
4. Если записи нет, проверьте, описывает ли API отложенную обработку, асинхронные очереди или задержку создания записи, прежде чем повторять запрос.
5. Повторяйте только тогда, когда семантика конечной точки и имеющиеся доказательства делают повтор безопасным.

Не считайте GET безобидной проверкой только из-за безопасного метода. Некоторые API скрывают работу за конечной точкой чтения, а некоторые кэши ответов отстают от пути записи. Проверьте контракт провайдера и по возможности получите конкретный созданный ресурс или запись операции, а не ищите ее в широком списке по времени.

Названия HTTP-методов помогают, но не определяют поведение приложения. Запрос PUT может быть идемпотентным на уровне HTTP, а сервер при каждом получении все равно отправлять дублирующие письма, списывать плату или запускать хук развертывания. RFC 9110 прямо отмечает, что идемпотентность относится к запрошенному эффекту, тогда как сервер может хранить отдельные журналы или создавать другие побочные эффекты. Поэтому задокументированная идентичность операции, определенная владельцем API, важнее глагола в клиентской библиотеке.

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

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

Для SSH-команд нужны доказательства с удаленного узла

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

Не используйте одну большую строку оболочки, которая выполняет несколько изменений без контрольных точек. Разделите удаленную работу на операции с собственными идентификаторами и надежным состоянием. Например, оболочка развертывания может записывать для одного идентификатора операции состояния received, validated, applied и completed, а затем предоставлять команду чтения статуса.

/usr/local/bin/release-status \
  --operation-id 8b4dbdb6-61e1-49ea-a5b5-9ae225eb2af1

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

Осторожно относитесь к ловушкам очистки оболочки как к доказательствам восстановления. Локальная ловушка не сработает после резкого отключения питания. Удаленная ловушка может не сработать после принудительного завершения и может выполниться, пока дочерний процесс продолжает работу. Очистка уменьшает беспорядок, но не доказывает итоговое состояние.

Используйте удаленный маркер только тогда, когда между маркером и побочным эффектом есть содержательная связь. Строка, добавленная в /tmp/action-done, не доказывает фиксацию миграции базы данных. Запись в таблице миграций, созданная в той же транзакции, лучше. Запись о развертывании, созданная контроллером развертывания, еще надежнее.

Sallyport направляет SSH через встроенный stateless-помощник sp-ssh, но правило остается тем же: локальная запись действия может подтвердить, что шлюз пытался сделать и что наблюдал. Только удаленный узел или система, измененная командой, может установить не наблюдавшийся удаленный результат.

Проведите расследователя через одно прерванное развертывание

Представим, что агент запрашивает выпуск в рабочую среду через HTTP-конечную точку. Шлюз записывает разрешенное намерение с идентификатором действия act_01JX8F3Z6Z, идентификатором операции 8b4d..., хешем артефакта 3c1f... и согласованием сессии. Он начинает запрос. Сервис выпусков фиксирует выпуск и присваивает квитанцию rel_4921. До того как ответ достигает шлюза, ноутбук отключается.

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

Правильное расследование начинается с остановки автоматического повтора для act_01JX8F3Z6Z. Проверьте локальную цепочку аудита. Запишите последнее сохраненное событие, данные о завершении локального процесса, адресата, хеш полезной нагрузки и идентификатор операции. Затем запросите в сервисе выпусков операцию 8b4d....

Возможны три полезных результата:

• Сервис возвращает rel_4921 с хешем артефакта 3c1f.... После сверки классифицируйте исходное действие как подтвержденный успех. Отсутствие локального завершения остается пробелом аудита, а не причиной повторять выпуск.
• Сервис возвращает надежный отказ, связанный с 8b4d.... Классифицируйте результат как подтвержденную ошибку. Сохраните причину отказа до решения о том, нужно ли отправлять исправленный запрос.
• Сервис не возвращает запись. Проверьте, ставит ли он запросы в очередь до создания записей операций и нет ли задержки в пути поиска. Если отложенную работу нельзя исключить, сохраните статус неизвестного результата и передайте вопрос на разбор, а не повторяйте запрос вслепую.

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

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

Правила повторов должны быть достаточно узкими, чтобы работать в плохой день

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

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

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

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

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

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

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

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