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

Camunda 8.10 Self-Managed меняет то, как выглядят эти часы. Восстановление — это операция кластера, которую вы вызываете через API. Никаких перезапусков брокеров, никаких изменений развертывания, никакой работы с узлами по одному.

Чего раньше стоило восстановление кластера

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

Каждый шаг представлял собой изменение развертывания, поэтому его нельзя было выразить декларативно. Его нельзя было запустить через Terraform или конвейер (pipeline), а репетиция означала выделение целого дня чьего-то времени.

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

Восстановление как операция кластера

Встроенное восстановление выполняется через REST API кластера оркестрации в три этапа.

Переведите кластер в режим восстановления: PATCH /v2/mode?mode=RECOVERING. Обработка приостанавливается. Брокеры остаются активными.
Восстановите вторичное хранилище, Elasticsearch, OpenSearch или реляционную базу данных до той точки, к которой хотите вернуться.
Запустите восстановление: POST /v2/restore с идентификатором резервной копии.
Опрашивайте GET /v2/restore, чтобы следить за возвращением разделов.
Подтвердите работоспособность с помощью GET /v2/topology.

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

Что это меняет для аварийного восстановления?

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

Менее очевидное изменение заключается в том, что восстановление становится кодом. Это последовательность аутентифицированных вызовов API, поэтому она хранится там же, где у вас уже находится операционная логика: модуль Terraform, хук Helm, контейнер инициализации Kubernetes, задача конвейера. Она проходит проверку, версионируется и изменяется так же, как и все остальное, что вы запускаете в продакшене. Это делает репетицию достаточно дешевой, чтобы ее действительно можно было проводить. Добавьте запланированную задачу, которая восстанавливает вчерашнюю производственную резервную копию во временный кластер и проверяет, что топология снова исправна. Запускайте ее ежеквартально, и ваше целевое время восстановления станет измерением, а не целью.

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

Что не входит в рамки

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

Попробуйте: проведите учения по восстановлению до того, как они вам понадобятся

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

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

Полная информация, включая многопользовательские эндпоинты (endpoints) и шаги, специфичные для хранилища, содержится в документации Backup and Restore.