Отказоустойчивость, резервирование и непрерывность работы суверенной цифровой инфраструктуры: ЦОДы, доверенные узлы, маршруты, шлюзы, мониторинг, аварийное восстановление, RTO, RPO, SLA и защита критических цифровых сервисов.
Суверенная цифровая инфраструктура должна продолжать работать даже при сбоях оборудования, каналов связи, отдельных узлов, сервисов или площадок.
Availability (доступность) — это способность инфраструктуры сохранять работу цифровых сервисов, доверенных узлов, маршрутов, архивов и проверочных механизмов при штатных нагрузках, технических отказах, сетевых инцидентах и аварийных сценариях.
Суверенная инфраструктура не может зависеть от одной площадки, одного канала, одного сервера или одного оператора. Для доверенной цифровой экосистемы доступность является не дополнительной опцией, а базовым архитектурным требованием.
Коротко за 30 секунд
Availability означает, что инфраструктура цифрового доверия спроектирована так, чтобы не останавливаться из-за отказа одного компонента. Если недоступен один узел, продолжает работать другой. Если нарушен один маршрут, используется резервный маршрут. Если требуется восстановление сервиса, система должна иметь заранее определенные показатели RTO (время восстановления) и RPO (допустимая потеря данных).
В архитектуре sovereign.satcom.kg доступность обеспечивается через несколько ЦОДов, распределенные trust nodes (узлы доверия), резервные маршруты, мониторинг, автоматическое переключение, архивные копии, независимые DLT-узлы и процедуры аварийного восстановления.
Итог: цифровое доверие должно быть доступно не только когда все работает идеально, но и тогда, когда часть инфраструктуры испытывает отказ.
Что такое Availability
Availability (доступность) — это свойство инфраструктуры обеспечивать непрерывное предоставление сервисов в согласованных пределах времени, качества и надежности.
Для обычного сайта доступность означает, что страница открывается. Для суверенной цифровой инфраструктуры доступность означает намного больше:
- доверенные сервисы продолжают принимать и обрабатывать события;
- DLT-узлы продолжают фиксировать доказательства;
- архивные сервисы продолжают принимать и проверять архивные пакеты;
- маршрутизация сохраняет управляемость;
- проверочные сервисы доступны для участников;
- критические журналы не теряются;
- восстановление после сбоя выполняется по заранее определенному сценарию.
Почему это важно для архитектуры доверия
Доверие невозможно, если инфраструктура нестабильна. Документ может быть правильно создан, хэш может быть корректным, DLT-запись может быть подтверждена, но если система проверки, архив или маршруты недоступны в критический момент, доверие становится неполным.
Поэтому доступность должна проектироваться на уровне архитектуры: от ЦОДов и сетевых маршрутов до API-шлюзов, DLT-узлов, архивных сервисов, мониторинга и процедур восстановления.
Ключевые цели Availability
- сохранить работу критических сервисов при отказе отдельных компонентов;
- обеспечить резервирование данных, маршрутов и узлов;
- сократить время восстановления после инцидента;
- исключить единую точку отказа;
- обеспечить предсказуемые SLA для доверенных сервисов;
- поддерживать проверку документов, квитанций и событий даже при частичной деградации инфраструктуры;
- обеспечить техническую и организационную готовность к аварийному восстановлению.
Основные элементы отказоустойчивости
| Элемент | Роль в доступности |
| ЦОДы | Размещение сервисов на нескольких площадках и снижение зависимости от одной инфраструктурной точки. |
| Trust Nodes | Распределенные узлы доверия, которые продолжают работу при недоступности части сети. |
| DLT-узлы | Фиксация доказательств в распределенной сети без единой точки контроля. |
| Archive Nodes | Резервное хранение архивных пакетов и квитанций. |
| Gateway Nodes | Управляемый вход и маршрутизация событий через доверенные шлюзы. |
| Routing | Основные и резервные маршруты для цифровых событий. |
| Monitoring | Наблюдаемость состояния сервисов, узлов, маршрутов и очередей. |
| DR-процедуры | Аварийное восстановление сервисов, данных и маршрутов. |
Модель нескольких ЦОДов
Суверенная цифровая инфраструктура должна использовать несколько инфраструктурных площадок. Один ЦОД может выполнять роль основного контура, второй — резервного, третий — государственного или облачного контура, а дополнительные региональные площадки могут усиливать географическую устойчивость.
Такая модель позволяет разделить функции:
- основной контур — ежедневная работа сервисов и платформ;
- резервный контур — аварийное восстановление и непрерывность;
- архивный контур — сохранность доказательств и архивных пакетов;
- государственный облачный контур — размещение критических государственных сервисов;
- региональные контуры — снижение задержек и повышение устойчивости в регионах.
Распределенность узлов доверия
Trust Nodes (узлы доверия) должны быть распределены по инфраструктуре. Это снижает риск того, что отказ одной площадки остановит всю экосистему.
Для доверенной цифровой архитектуры важны разные типы узлов:
- DLT Node — фиксирует доказательства цифровых событий;
- Archive Node — хранит архивные пакеты и квитанции;
- Gateway Node — принимает и маршрутизирует события;
- Verification Node — обеспечивает проверку документов и квитанций;
- Routing Node — поддерживает управляемый обмен между сетевыми зонами;
- Observer Node — наблюдает состояние сети без права изменения данных;
- Reserve Node — включается при отказе основного узла.
RTO и RPO
Для каждого критического сервиса должны быть определены показатели восстановления.
| Показатель | Что означает | Применение |
| RTO | Recovery Time Objective / целевое время восстановления | Через какое время сервис должен быть восстановлен после сбоя. |
| RPO | Recovery Point Objective / допустимая точка восстановления данных | Какой объем данных допустимо потерять при аварии. |
| SLA | Service Level Agreement / соглашение об уровне сервиса | Какой уровень доступности должен обеспечиваться для участников. |
| MTTR | Mean Time To Repair / среднее время восстановления | Как быстро устраняется типовой инцидент. |
| MTBF | Mean Time Between Failures / среднее время между отказами | Как часто компонент может отказывать статистически. |
Для доверенных сервисов RTO и RPO должны задаваться отдельно для DLT, Архива, verification-сервисов, шлюзов, маршрутов, журналов, интерфейсов и аналитических контуров.
Классы доступности сервисов
| Класс | Описание | Примеры сервисов |
| Класс A | Критические сервисы, которые должны восстанавливаться максимально быстро. | Trust Gateway, DLT anchoring, verification API, журнал критических событий. |
| Класс B | Важные сервисы, допускающие кратковременную деградацию без потери доверия. | Архивные очереди, внутренние панели, административные интерфейсы. |
| Класс C | Сервисные и информационные компоненты, которые могут восстанавливаться позже. | Публичные страницы, справочные материалы, статистические витрины. |
Непрерывность работы DLT
DLT-сеть должна быть спроектирована так, чтобы отсутствие части узлов не разрушало доверенный контур. Узлы должны иметь правила консенсуса, кворума, синхронизации, повторной репликации и восстановления состояния.
При временной недоступности узла он должен иметь возможность вернуться в сеть, получить недостающие записи, пройти проверку целостности и продолжить работу без нарушения общей истории событий.
Непрерывность Арбитражного Архива
Арбитражный Архив должен обеспечивать долгосрочную сохранность доказательств. Для этого требуется не только хранить архивные пакеты, но и обеспечивать резервные копии, неизменяемое хранение, контроль целостности, аудит доступа и возможность восстановления после сбоя.
Архивная квитанция должна оставаться проверяемой даже при переносе архивного пакета между хранилищами или при восстановлении из резервной копии.
Непрерывность маршрутизации
Контролируемый обмен между участниками не должен зависеть от одного сетевого пути. Для критических маршрутов должны быть предусмотрены основные и резервные каналы, альтернативные шлюзы, журналирование маршрутов и механизмы обнаружения деградации.
Каждое событие должно иметь trace_id и route_id, чтобы можно было восстановить путь прохождения даже при частичном отказе инфраструктуры.
Деградация без потери доверия
Инфраструктура должна поддерживать режим graceful degradation (управляемая деградация). Это означает, что при отказе части функций система не должна полностью останавливаться. Она должна сохранять критические операции: идентификацию, прием событий, формирование очередей, журналирование, последующую фиксацию в DLT и передачу в Архив после восстановления.
Важно различать временную недоступность сервиса и потерю доверия. Если событие корректно журналируется, имеет хэш, timestamp, proof и может быть позже зафиксировано в DLT и Архиве по регламенту, доверенная цепочка может быть сохранена.
Наблюдаемость и мониторинг
Availability невозможна без наблюдаемости. Инфраструктура должна постоянно измерять состояние узлов, сервисов, маршрутов, очередей, хранилищ, ключевых API и проверочных механизмов.
- доступность сервисов;
- задержки API;
- состояние DLT-узлов;
- состояние архивных очередей;
- ошибки маршрутизации;
- нагрузку на ЦОДы;
- состояние резервных копий;
- инциденты безопасности;
- время восстановления после сбоя.
Связь Availability с Security
Доступность является частью безопасности. Если система защищена, но недоступна, она не выполняет свою функцию. Если система доступна, но не защищена, она не может быть доверенной. Поэтому availability, security и integrity должны проектироваться вместе. Доступность не должна достигаться за счет ослабления защиты. Резервные маршруты, узлы и сервисы должны иметь такие же требования к идентификации, контролю доступа, журналированию и криптографической защите, как и основные компоненты.
