Возможность

Двунаправленные сценарии Health-Check

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

Большинство платформ GSLB рассматривает сценарии health-check как однонаправленные автоматы состояний: условие становится истинным — трафик переключается. То же условие становится ложным — трафик возвращается. Такая симметрия удобна и часто ошибочна. Реальный путь в failover редко совпадает с путём обратно. Сценарии TR7 GTM определяют направление активации и направление деактивации независимо. Каждое направление несёт собственное выражение условия (комбинированные группы AND/OR по результатам health-check), собственный набор срабатывающих триггеров и собственную проверку шлюзования. Операторы решают: возвращаться к нормальному состоянию сразу после восстановления основного узла или ждать продлённого окна стабильности? Запускать ли синтетическую транзакцию перед возвратом трафика? Должно ли событие активации отправлять письмо команде SRE, а событие деактивации — ещё и инициировать хук развёртывания? Такая архитектура позволяет предприятиям выражать асимметричные политики, которые им реально нужны: быстро вход, медленно выход — ради безопасности; консервативно вход, быстро выход — под давлением SLA; ручное подтверждение возврата при автоматизированном failover. Сам сценарий многократно используется: его привязывают к нескольким DNS-записям, к процессам аварийного восстановления, к парам ЦОД. Оператор описывает автомат состояний один раз; платформа применяет его везде, где есть ссылка.

2-way

Независимые пути активации и деактивации

AND / OR

Комбинированное выражение условия с отрицанием

Авто + польз.

Автогенерируемые сценарии пар ЦОД + пользовательские сценарии

Многоразовый

Один сценарий привязан ко множеству записей, DR-потоков и ЦОД

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

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

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

Примеры: быстро вход / медленно выход — failover по первой обнаруженной ошибке ради защиты пользователя, но требование 15 минут чистой работоспособности перед возвратом во избежание дребезга. Консервативно вход / быстро выход — три последовательных отказа до инициации failover, но мгновенный возврат при восстановлении основного узла для соблюдения обязательств RPO/RTO. Авто вход / ручной выход — failover автоматизирован, но возврат требует подтверждения SRE после проверки runbook.

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

Двунаправленные сценарии TR7 GTM позволяют активации и деактивации нести независимые условия, независимые проверки шлюзования и независимые действия триггеров — структуру политики, которую ваш runbook реагирования на инциденты уже подразумевает.

Наш подход

Сценарий — это именованный, многократно используемый автомат состояний с двумя направлениями. Каждое направление определяется комбинированным выражением условия и набором триггеров; два направления не обязаны быть обратными друг другу.

Направление активации — когда сценарий включается

Комбинированное выражение условия оценивает базовые health-check. При значении true сценарий активируется. Опциональные триггеры запускают действия (HTTP/HTTPS-вебхуки, запросы Oracle), а опциональная проверка шлюзования подтверждает, что триггер должен сработать.

Направление деактивации — когда сценарий выключается

Отдельное комбинированное выражение условия оценивает отдельный набор health-check. Путь деактивации может быть обратным активации либо требовать дополнительной стабильности, дополнительных проверок или совершенно других триггеров.

Комбинированные условия с группами AND/OR

Условия — это не одиночные булевые значения, а группы результатов health-check, объединённые AND внутри группы и OR между группами, с опциональным отрицанием. Тот же DSL, что управляет логикой правил трафика на ADC, управляет здесь и оценкой сценария.

Многократное использование между записями, доменами и парами ЦОД

Сценарий определяется один раз и используется по имени в DNS-записях, конфигурациях аварийного восстановления и политиках межЦОД-failover. Операторы не воссоздают одну и ту же логику в нескольких местах.

Возможности

Двунаправленные сценарии — основа политики failover и восстановления в TR7 GTM.

Комбинированное выражение активации

Условие активации строится из результатов health-check одного или нескольких профилей. Группы объединяют проверки через AND; несколько групп объединяются через OR. Каждая отдельная проверка может быть отрицаемой. Операторы выражают условия вида «(API в порядке AND база данных в порядке) OR (резервный путь A в порядке AND резервный путь B в порядке)» без написания скриптов.

Комбинированное выражение деактивации

Условие деактивации не зависит от условия активации. Операторы могут указать «основной узел стабилен 15 минут AND задержка ниже порога», тогда как активация могла быть просто «основной узел недоступен».

Независимые наборы триггеров для каждого направления

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

Проверка шлюзования перед срабатыванием триггеров

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

Три режима поворота для каждого направления: auto / on / off

Каждое направление поддерживает три выбираемых оператором режима. Auto следует выражению условия. On принудительно активирует направление независимо от условий (ручное переопределение). Off полностью отключает направление (например, отключить failback во время технического окна).

Автогенерация сценариев для пар ЦОД

При определении двух ЦОД TR7 GTM автоматически создаёт четыре сценария на пару: from-active, to-active, from-backup, to-backup — каждый с подходящей логикой условий на основе проверок доступности WAN, LAN и интернета. Операторы могут использовать автосценарии как есть, кастомизировать их или создать собственные с нуля.

DNS-запись со статусом, управляемым сценарием

Состояние работоспособности DNS-записи может определяться сценарием, а не статическим булевым значением или одной проверкой. Поле `cond` для записи принимает ссылку на сценарий: при активации сценария запись исключается из ответов; при деактивации — возвращается.

Аварийное восстановление, управляемое сценариями

Записи аварийного восстановления могут указывать `drCond` — сценарий, определяющий, когда DR-набор записей заменяет основной набор в ответах. Оценка DR-сценария двунаправлена, поддерживая управляемые failover и failback.

Триггеры HTTP, HTTPS и Oracle

Триггеры срабатывают как HTTP/HTTPS-вызовы (пользовательский URI, метод, заголовки, тело, ожидаемые коды статуса, проверка содержимого) или вызовы базы данных Oracle (заданный SQL). Операторы связывают активации сценариев с существующими конвейерами управления инцидентами, развёртывания или аудита.

Аудит-трейл по каждому переходу состояния

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

Операционная глубина

Сценарии работают совместно с определениями health-check, конфигурациями триггеров, привязками DNS-записей и конфигурациями аварийного восстановления.

Семантика групп условий

Внутри группы условий все перечисленные проверки должны давать true (AND). Между группами достаточно, чтобы одна группа дала true (OR). Суффикс `!` у ID проверки её отрицает. Структура группировки симметрична для активации и деактивации; у каждого направления свой набор групп.

Общее пространство ID проверок

Условия ссылаются на health-check по ID. Пользовательские профили health-check и автогенерируемые проверки пары ЦОД делят одно пространство ID. Операторы смешивают ручные и автоматические проверки в одной группе условий.

Взаимодействие режима поворота с деактивацией

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

Payload триггера и поведение повторов

Триггеры срабатывают со структурированным payload, несущим ID сценария, направление, метку времени оценки и снимок конфигурации на момент срабатывания. Сбой триггера (HTTP non-2xx, ошибка Oracle) фиксируется и опционально повторяется согласно профилю триггера.

Каденс оценки сценариев

Сценарии оцениваются при каждом изменении состояния health-check, а не по таймеру опроса. Первое изменение состояния, пересекающее порог активации или деактивации, инициирует переход. Стоимость оценки остаётся низкой, поскольку условия ссылаются на предварительно вычисленные состояния.

Видимость текущего состояния сценария

Операторы видят текущее состояние каждого сценария (активирован / деактивирован), время последнего перехода, последний результат оценки каждой группы условий и итоги триггеров. Дашборд выделяет зависшие переходы и конфликтующие переопределения.

Когда использовать

Failover «быстро вход / медленно выход»

Активируйте failover по первой обнаруженной ошибке, чтобы защитить пользователя. Деактивируйте только после 15 минут чистой работы основного узла, чтобы избежать дребезга. Разные условия, разное время — один объект сценария.

Автоматический failover, ручной failback

Failover автоматизирован; путь возврата требует подтверждения SRE. Направление деактивации установлено в off; оператор вручную переключает его в on после проверки runbook. Активация продолжает оцениваться автоматически.

Асимметричная политика межЦОД-failover

Failover DC A → DC B запускает HTTP-вебхук в систему управления инцидентами. Failback DC B → DC A запускает тот же вебхук плюс вызов системы развёртывания для прогрева кеша. Триггеры каждого направления независимы.

Сценарии с учётом состояния базы данных

Используйте Oracle-триггер для запроса к БД перед failover — например, подтвердите, что резервная БД догнала состояние через log shipping. Результат триггера шлюзует фактический переход состояния.

Часто задаваемые вопросы

Можно ли сделать условия активации и деактивации идентичными?

Да — это даст вам традиционное однонаправленное поведение. Двунаправленная структура опциональна; если оба направления используют одно и то же выражение условия, сценарий ведёт себя как классический on/off-сценарий. Архитектура позволяет выражать асимметричную политику, когда нужно, не навязывая её.

Что произойдёт, если условия активации и деактивации одновременно дадут true?

Побеждает активация. Сценарий переходит в активное состояние и остаётся активным, пока условие деактивации не станет true, а условие активации — false. Это исключает осцилляцию в пограничных случаях, когда условия пересекаются.

Чем триггеры отличаются от базовых health-check?

Health-check оценивают состояние эндпоинта. Триггеры — это действия, срабатывающие при переходе сценария. Триггеры могут быть HTTP/HTTPS-вызовами (вебхуками) или вызовами БД Oracle. Health-check определяют состояние сценария; триггеры сообщают это изменение состояния внешним системам.

Добавляют ли двунаправленные сценарии задержку к failover?

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

Может ли сценарий ссылаться на другой сценарий?

Условия ссылаются на health-check (ручные или автоматические). Композиция «сценарий из сценариев» напрямую не выразима; вместо этого сложные политики строятся через привязку сценариев к записям и конфигурациям аварийного восстановления, которые сами участвуют в логике принятия решений более высокого уровня.

Определите путь входа и путь возврата независимо.

Пройдитесь по двунаправленному сценарию, построенному на вашем собственном runbook: быстро вход / медленно выход, ручной failback, асимметричные наборы триггеров — ваша политика, а не стандартная политика платформы.