Надежность - схемы аварийного восстановления | Шаблоны |

Надежность - схемы аварийного восстановления

Узнайте больше о надежности → Аварийное восстановление и бесперебойное функционирование

Шаблоны

Где искать	Как хорошо выглядит
Стратегия резервного копирования данных	✅ Еженедельный или ежемесячный автоматический экспорт посредством службы экспорта данных или специальной службы резервного копирования и восстановления (например, «Собственный»). Частота экспорта соответствует требованиям RPO. Данные критических объектов, экспортированные во внешнее хранилище объектов при необходимости.
Стратегия резервной копии метаданных	✅ Все метаданные, версированные в Git посредством исходного формата Salesforce DX. Изменения метаданных развернуты только из элемента управления источником. Конвейеры CI/CD могут воссоздать любую среду из хранилища. Моментальное восстановление доступно в журнале Git.
Стратегия резервной копии файла	✅ Записи версии ContentVersion, вложения и документы, экспортированные во внешнее хранилище по расписанию. Автоматический экспорт файлов для нормативных требований к сохранности. Внешняя архивная система для файлов, содержащих более ранние операционные потребности.
Проверка резервной копии	✅ Ежеквартально восстанавливайте упражнения в средах Full Sandbox или Developer. Восстановите процедуры, задокументированные в беговых книгах с пошаговыми инструкциями. Тестовое восстановление проверяет целостность и полноту резервной копии до возникновения аварий.
Расписание тестирования восстановления	✅ Ежеквартальные тесты частичного восстановления (метаданные, определенные объекты, поднаборы файлов). Ежегодное обучение полному восстановлению с полным восстановлением окружающей среды. Извлеченные уроки задокументированы, а ранбуки обновляются после каждого теста.
Сторонняя служба резервного копирования	✅ Автоматическое резервное копирование с возможностью моментального восстановления. Соглашение об уровне обслуживания, определяющее RPO/RTO. Ежедневная автоматическая проверка выполнения резервной копии. Географическая избыточность с резервными копиями, хранимыми в нескольких регионах.
Настраиваемые объекты и поля	✅ Настраиваемые объекты, добавленные в запланированные запуски службы экспорта данных, со значениями полей формулы и сводного резюмирования, вычисляемыми повторно, а не экспортируемыми (не существует сохраненного значения для извлечения), а файлы или двоичные файлы вложений, обрабатываемые посредством отдельного пути экспорта. Сложные типы полей и взаимосвязи поиска, задокументированные и протестированные в последовательности восстановления.
Файлы и вложения	✅ Объекты ContentDocument и ContentVersion, экспортированные с двоичными файлами. Резервные копии библиотек документов, включая структуры папок и полномочия. Экспортированные файлы сохраняют журнал версий для важных типов документов.
Стратегия обновления безопасной среды	✅ Производственная организация обновляется до Full Sandbox ежеквартально для нагрузочного тестирования и проверки аварийного восстановления. Обновление безопасной среды, используемое в качестве тестирования процедуры восстановления. Маскировка данных применяется после обновления для защиты конфиденциальных данных в тестовых средах.
Резервный мониторинг и оповещение	✅ Автоматические предупреждения о сбое или задержке запланированных резервных копий. Панель мониторинга, отображающая уровень успешной работы резервных копий, время завершения и тенденции объема данных. Расширение по вызову для сбоев резервной копии, превышающих допустимое окно задержки.

Антишаблоны

Где искать	Как плохо выглядит
Резервная стратегия	⚠️ Автоматическое резервное копирование не настроено, зависит только от резервных копий инфраструктуры платформы. Сторонняя служба резервного копирования настроена, но не протестирована - резервные копии могут быть повреждены или не завершены. Экспорты приложения Data Loader вручную зависят от резервных копий (несогласованное выполнение, неполное покрытие, отсутствие автоматизации).
Версия метаданных	⚠️ Изменения метаданных, развернутые посредством наборов изменений без контроля источников. Хранилище «Без получения» для журнала метаданных. Моментальное восстановление невозможно - не может восстановить последнюю из известных хороших конфигураций после разрушительных изменений.
Проверка резервной копии	⚠️ Резервные копии настроены, но не восстановлены в тестовой среде. Первая попытка восстановления происходит во время фактической катастрофы, отображающей неполную область или поврежденные архивы. Резервные процедуры, задокументированные, но не протестированные резервным персоналом.
Область резервной копии	⚠️ Предположим, что служба экспорта данных собирает все данные, если значения полей формулы и сводного резюмирования не экспортируются (пересчитываются динамически, не сохраняются), а файлы или двоичные файлы вложений требуют отдельной обработки, оставляя пробелы, обнаруженные только при восстановлении.
Процедуры восстановления	⚠️ Рунная книга восстановления содержит устаревшие этапы из архитектуры 2-летней давности. Процедуры восстановления, протестированные одним экспертом, который покинул компанию. Процедуры, выполняемые вручную, настолько сложны, что их выполнение в стрессовом состоянии может привести к ошибкам.
Частота резервирования	⚠️ Важные данные транзакций еженедельно резервируются, если бизнес-требование составляет 24 часа RPO. Частота резервной копии не соответствует бизнес-критичности - одинаковое расписание для всех данных, вне зависимости от важности. Резервное расписание пропущено из-за отсутствия мониторинга и оповещений.
Соответствие нормативным требованиям	⚠️ Хранение резервной копии короче, чем требуется управляющим регламентом. Например, документация о соответствии ЗПИНС (полисы, анализы рисков, ЗВС, записи о нарушениях) была удалена до ее хранения в течение шести лет (§164.316) или регулируемые SOX записи финансовой ревизии были удалены до их хранения в течение семи лет. Пробел в соответствии, обнаруженный во время аудита.
Хранилище файлов	⚠️ Крупные файлы, хранящиеся в Salesforce без стратегии архивирования. Хранилище файлов растет до тех пор, пока организация не приблизится к ограничению. Нет резервной копии записей ContentVersion - файлы потеряны, если организация повреждена. Использование личных копий важных файлов пользователями.
Тестирование безопасной среды	⚠️ Full Sandbox так и не обновился от производства - тестовая среда дико отличается от производственной. Объем данных в безопасной среде 1% от производственной, предотвращая реалистичную проверку восстановления. Обновление безопасной среды обрабатывается как неудобство, а не как возможность проверки послеаварийного восстановления.
Мониторинг	⚠️ Резервные задания выполняются без предупреждения. Обнаруживайте ошибки резервной копии через несколько недель во время катастрофы, когда нужна резервная копия. Панель мониторинга, отображающая тенденции успеха резервной работы, отсутствует. Работоспособность резервной службы отслеживается только при получении счета.
Ключи шифрования	⚠️ Обработка зашифрованных Shield данных как безопасных без защиты материала ключа: ротация ключей сама по себе оставляет предыдущие данные нетронутыми, но уничтожение секрета клиента (криптоизмельчение) или потеря материала Bring Your Own Key или кэш-ключа делает зашифрованные данные невосстановимыми. Управление ключами пропускается в процедурах восстановления.
Межорганизационные зависимости	⚠️ Резервное копирование основной организации самостоятельно, если решение зависит от связанных приложений, внешних интеграций или единого входа: секреты связанного приложения, авторизации именованных регистрационных данных и OAuth, а также маркеры внешней проверки подлинности не сохраняются восстановлением данных и метаданных и должны быть повторно настроены и авторизованы, прежде чем восстановленная организация сможет авторизоваться во внешних системах. Если внешний единый вход является единственным путем входа, недоступный поставщик удостоверений блокирует вход даже в полностью восстановленную организацию.

Шаблоны

Где искать	Как хорошо выглядит
Определение цели времени восстановления (RTO)	✅ RTO определено для каждой бизнес-возможности, а не единообразно во всей организации. Операции, важные для дохода: минут до 1 часа. Клиентские услуги: 1-4 часа. Внутренние инструменты: 4-24 часа. Архивный отчет: дней. RTO, документированные с одобрения бизнес-заинтересованных лиц.
Определение цели точки восстановления (RPO)	✅ RPO определено на основе допустимой потери данных на возможность. Финансовые операции: близкая к нулю RPO (секунды, асинхронная репликация под управлением события). Записи клиентов: около нуля (минуты посредством CDC). Данные Analytics: часы (запланированная синхронизация). Временное состояние бизнес-правила: дней (репликация не нужна).
Доступность рабочей группы и роли	✅ Документирование основного и резервного персонала для всех важнейших ролей. Ни одной точки сбоя в оперативных Knowledge. Дерево расширения, определяющее основное средство реагирования, первое резервное, второе резервное. Контактные данные, доступные в системе при недоступности Salesforce.
Процедуры связи	✅ План связи инцидента, определяющий, кто уведомляет пользователей, клиентов, руководителей. Страница внешнего статуса, размещенная вне системы Salesforce для общения с пользователем во время сбоев платформы. Система SMS-уведомлений для дежурной группы при недоступности основных инструментов связи. Временные интервалы расширения задокументированы (когда переходить от рабочей группы к менеджеру к руководителю).
Соотнесение зависимости поставщика	✅ Все важные внешние поставщики, задокументированные, включая Salesforce, партнеров по интеграции, поставщиков пакетов ISV. Документированные соглашения о поставщиках и окна поддержки (круглосуточно по сравнению с часами работы). Контакты и процедуры расширения поставщиков задокументированы. Альтернативные варианты поставщиков, определенные для критических зависимостей.
Обязательства по уведомлениям регулятора	✅ Обязательные требования к уведомлению об инцидентах, документированные по отрасли (финансовые услуги, здравоохранение, правительство). Временные интервалы уведомлений, определенные в соответствии с обязательным окном каждого управляющего регламента. Матрица ответственности, определяющая, кто и в какие регулирующие органы отправляет уведомления. Шаблоны, подготовленные для быстрого уведомления регламента.
Анализ влияния на бизнес	✅ Каждая бизнес-возможность, ранжированная по влиянию на доход, влиянию пользователя и регуляторному риску. Приоритизация восстановления на основе рейтинга влияния на бизнес. Ресурсы, выделяемые на послеаварийное восстановление, пропорциональны важности для бизнеса. Анализ влияния проверяется ежегодно по мере изменения бизнес-приоритетов.

Антишаблоны

Где искать	Как плохо выглядит
Определение RTO/RPO	⚠️ “Система должна быть надежной” без измеримых целей RTO/RPO. RTO/RPO, определенная ИТ-группой без участия бизнес-заинтересованных лиц. Единые цели во всех возможностях, игнорирующие различия в критичности («всему нужно 99,999% работы»).
Готовность рабочей группы	⚠️ Единый администратор Salesforce знает процедуры аварийного восстановления без документации или резервного персонала. В дежурную ротацию входят сотрудники, которые никогда не выполняли процедуры восстановления. Основные спасатели, недоступные во время бедствия (отпуск, болезнь, ушедшая компания).
Планирование коммуникации	⚠️ Нет плана связи - обнаружите необходимость уведомления пользователей после уже выполняемого инцидента. Страница статуса, размещенная в самой Salesforce, недоступна во время сбоя Salesforce. Часы ожидания уведомления руководителей при попытке восстановления.
Зависимости поставщиков	⚠️ Не знает условий соглашения об уровне обслуживания поставщиков до наступления сбоя и ожидает круглосуточной поддержки от поставщика с покрытием только часов работы. Нет задокументированных контактов расширения поставщика. Поставщик пакетов ISV, необходимый для восстановления, но компания больше не работает.
Нормативные требования	⚠️ Не знает законов об обязательном уведомлении о нарушении. Узнайте о требовании уведомления за 24 часа после истечения 48 часов. Шаблоны не подготовлены - составление уведомлений регулятора во время реагирования на инцидент, пока время соответствия тикает.
Приоритизация восстановления	⚠️ Попытка одновременного восстановления всех возможностей во время бедствия вместо приоритета важных для дохода операций. Потратьте 8 часов на восстановление возможности внутренней отчетности, прежде чем обращаться к системе заказов, ориентированных на клиента.
Тестирование и учения	⚠️ План обеспечения непрерывности бизнеса никогда не тестировался посредством учений. Предположим, что документированные процедуры будут работать в стрессовом режиме без проверки. Упражнений столешницы избегали из-за “нехватки времени”, несмотря на то, что потратили дни на восстановление после неоткрытых проблем во время реальных катастроф.
Передача Knowledge	⚠️ Disaster recovery Knowledge сконцентрировалось в одном старшем архитекторе, который ничего не задокументировал. Новые участники рабочей группы, не прошедшие подготовку по аварийному восстановлению. Предположим, что все знают, что делать во время бедствий без четкой подготовки или учений.
Проверка предположения	⚠️ Процедуры восстановления предполагают доступность резервной копии в течение 15 минут, но извлечение резервной копии из холодильной камеры занимает 8 часов. При условии, что рабочая группа доступна в течение 30 минут, но не определены процедуры ротации или расширения по вызову. Оценки времени восстановления, основанные на оптимистических предположениях, не проверенных посредством тестирования.

Шаблоны

Где искать	Как хорошо выглядит
Архитектурное выравнивание RTO	✅ Архитектурные решения соответствуют обязательствам RTO. Минуты RTO требуют автоматического отказа и горячей готовности. Часы RTO требуют восстановления по сценарию и теплой готовности. Дни RTO принимает восстановление вручную из холодной резервной копии. Избежания чрезмерной инженерии там, где бизнес не оправдывает сложности.
Стратегия репликации RPO	✅ Метод репликации соответствует цели RPO. Околонулевое RPO: асинхронная потоковая передача событий посредством событий платформы при каждом сохранении записи (секунды задержки распространения, как минимум раз доставки). Минуты RPO: Изменение асинхронной репликации сбора данных. РПО часов: запланированное извлечение пакетного API. ООД дней: резервное копирование вручную по фиксированному расписанию.
Тестирование RTO	✅ Процедуры восстановления протестированы в условиях времени. Фактическая ставка возмещения, измеренная во время учений по аварийному восстановлению. Выявленные и устраненные промежутки между целевым и достигнутым РТО. RTO достижима резервным персоналом, а не только основными экспертами.
Проверка RPO	✅ Потеря данных, измеренная во время тестов восстановления. Фактический RPO по сравнению с целевым во время учений. Задержка репликации отслеживается постоянно в производстве. Предупреждения, настроенные, когда репликация отстает от обязательства RPO.
РТО/РПО для возможностей	✅ Разные бизнес-возможности имеют разные цели RTO/RPO, отображающие важность бизнеса. Поток заказов электронной коммерции: 15-минутный RTO, почти нулевой RPO (обосновывает мультиорганизационную активно-пассивную). Внутренняя база Knowledge: 8-часовой RTO, 24-часовой RPO (обосновывает восстановление вручную из резервной копии).
Анализ затрат и результатов	✅ Цели RTO/RPO сбалансированы с затратами на внедрение. Более жесткие цели требуют экспоненциального увеличения инвестиций. Экономическое обоснование, отображающее затраты на простой, оправдывающие инвестиции в аварийное восстановление. Ежегодный обзор подтверждает постоянное соответствие инвестиций и стоимости бизнеса.
Выравнивание SLA	✅ Цели RTO/RPO решения учитывают базовый уровень SLA платформы. Решение может предоставить RTO только лучше, чем базовый уровень платформы с архитектурой нескольких организаций. Реалистичные цели установлены с учетом возможностей платформы в качестве основы.
Мониторинг возможностей восстановления	✅ Постоянный мониторинг резервной валюты (возраст резерва по сравнению с целью RPO). Предупреждение об отставании резервной копии от графика. Автоматическая проверка работоспособности инфраструктуры восстановления (дополнительная организация, внешнее хранилище).
Автоматическое или ручное восстановление	✅ Агрессивные цели RTO (минуты) требуют автоматического отказа при минимальном вмешательстве человека. Модерируемые цели RTO (часы) позволяют восстанавливать сценарии по инициативе человека. Смягченные цели RTO (дни) принимают восстановление вручную в соответствии с задокументированными процедурами.

Антишаблоны

Где искать	Как плохо выглядит
Нереалистичные цели	⚠️ Подтверждение 15-минутного RTO с процедурами восстановления вручную, требующими 4 часов для выполнения. Обещающий нулевой RPO без инфраструктуры синхронной репликации. Цели RTO, заданные ИТ без архитектурной поддержки.
Несоответствие архитектуры	⚠️ 30-минутное обязательство RTO, но без автоматических процедур отказа и восстановления, выполняется полностью вручную. Нулевое обязательство RPO, но настроены только ежедневные резервные копии. Агрессивные цели без соответствующих инвестиций в автоматизацию и резервирование.
Непроверенные цели	⚠️ RTO никогда не проверялся посредством учений по аварийному восстановлению. Предполагая 2-часовой RTO достижимый, но никогда фактически не восстанавливаемый в условиях временных ограничений. Обнаружение во время настоящей катастрофы, задокументировавшей 4-часовое RTO, на самом деле требует 18 часов.
Единые цели	⚠️ Все возможности, назначенные одинаковому RTO/RPO, вне зависимости от важности бизнеса. Внутренняя система пакетных отчетов, предназначенная для доступности пяти девяти, в то время как важная для дохода электронная торговля имеет такую же цель. Массовые переинвестиции в некритические возможности и недоинвестирование в критические системы.
Игнорирование зависимостей	⚠️ RTO предполагает только восстановление организации Salesforce, но решение зависит от внешнего поставщика удостоверений, также недоступного. RPO предполагает, что резервная копия данных достаточна, но регистрационные данные интеграции и конфигурация не резервируются. Оценки времени восстановления игнорируют время восстановления зависимых систем.
Пробелы в репликации	⚠️ Обязательство 15-минутного RPO, но сбор данных об изменении настроен только для 3 из 12 важных объектов. Репликация события платформы настроена, но отсутствует мониторинг задержки доставки события. Инфраструктура репликации ломается и остается незамеченной неделями до катастрофы.
Незнание расходов	⚠️ Обязательство пятидевяти доступности без понимания стоимости внедрения. Набор целей RTO/RPO без анализа затрат и результатов. Бизнес не желает финансировать инфраструктуру, требуемую для целей, уже принятых перед клиентами.
Статические цели	⚠️ RTO/RPO, определенная 5 лет назад, так и не была переоценена, несмотря на рост бизнеса и изменение приоритетов. Цели остаются неизменными по мере развития решения и изменения его важности. Годовой процесс проверки отсутствует.
Пробелы в документации	⚠️ Цели RTO/RPO, задокументированные в документе об архитектуре, но не сообщенные бизнес-заинтересованным лицам. Предприятия, не знающие о соответствующих возможностях восстановления. Пробел обнаружен, когда предприятие ожидает восстановления на 1 час, но архитектура поддерживает только 24-часовое RTO.
Ложная точность	⚠️ Обязательство «99,97% доступности», когда инфраструктура мониторинга не может измерить с такой точностью. Цели определены с ложной точностью, предполагающей строгость, если основной анализ является приблизительной оценкой.
Отслеживание отсутствия	⚠️ Отсутствие постоянного мониторинга возможностей восстановления. Резервная копия отстает от графика на 2 дня, нарушая обязательство RPO, но предупреждений нет. Дополнительная организация в активно-пассивной архитектуре не получает обновления репликации, но проверки состояния не настроены.
Планирование без выполнения	⚠️ Красивый план послеаварийного восстановления с агрессивными целями RTO/RPO, но без автоматизации, тестирования или проверенных процедур. План создан для соответствия флажку «Соответствие», но отсутствует операционная реальность за обязательствами.

Шаблоны

Где искать	Как хорошо выглядит
Избыточность данных	✅ Платформа предоставляет резервное копирование инфраструктуры автоматически. Репликация на уровне приложения дополняет резервную копию платформы, когда бизнес требует более быстрого восстановления. Сбор данных об изменении или события платформы постоянно реплицируют важные данные в дополнительное хранилище. Репликация позволяет восстанавливаться после логических повреждений или ошибок конфигурации, которые не могут быть исправлены резервными копиями инфраструктуры.
Избыток заявок	✅ Логика приложения без гражданства, сохраняющая ошибки отдельных транзакций. Нет серверного состояния, предотвращающего горизонтальное масштабирование. Типы настраиваемых метаданных и настраиваемые параметры конфигурации мгновенно доступны на всех серверах приложений. Любой сервер приложений может обработать любой запрос без зависимости от определенного состояния сервера.
Избыточность интеграции	✅ Схемы выключателей определяют сбои интеграций. Запросы очереди событий платформы при недоступности внешних систем вместо блокировки операций пользователя. Ошибки внешней системы, изолированные от функций пользователя. Определено несколько параметров внешнего поставщика для критических интеграций, обеспечивающих быстрое переключение поставщика во время сбоев поставщика.
Шаблоны с несколькими организациями для критических нагрузок	✅ Активно-пассивная схема: основная организация обслуживает весь трафик, дополнительная организация синхронизирована, но простаивает, сбой во время отключения основной области. Активно-активная схема: обе организации непрерывно обслуживают производственный трафик, пользователей, распределенных по географическому признаку или бизнес-единице. Мультиорганизация оправдана, только если бизнес требует RPO/RTO за пределами возможностей платформы.
Синхронизация данных нескольких организаций	✅ Сбор данных об изменении обеспечивает репликацию важных данных в режиме, близком к реальному времени (15-минутный RPO). События платформы предоставляют потоковую передачу событий для критических транзакций (около нулевого RPO). Запланированная репликация Bulk API 2.0 для справочных данных (допустимо круглосуточное RPO). Стратегия разрешения конфликтов, определенная для активных при изменении одной записи в обеих организациях.
Активно-пассивная архитектура с несколькими организациями	✅ Основная организация в Восточном регионе США обслуживает весь производственный трафик. Дополнительная организация в регионе Европы синхронизирована посредством CDC, но простаивает. Уровень маршрутизации или проверки подлинности DNS направляет пользователей в активную организацию. Автоматические проверки состояния инициируют сбой, если основная организация недоступна в течение 10 минут подряд.
Активно-активная архитектура с несколькими организациями	✅ Пользователи EMEA в организации Europe, пользователи AMER в организации US на основе поля региона профиля пользователя. Двусторонняя репликация для общедоступных справочных данных (организации, продукты). Региональные данные остаются в соответствующих организациях (заказы, обращения). Устранение конфликтов использует функцию «последние продажи с региональными полномочиями» для основных данных клиентов.
Географическое распределение	✅ Региональные центры обработки и хранения данных Hyperforce включают географическое распределение. Развертывание одной области с управляемым платформой резервированием, достаточным для доступности 99,9%. Мультиорганизация в регионах, учитываемая только для требований 99,95%+ или мандатов резидентства данных регулирования.
Резервирование внешней системы	✅ Критические внешние API имеют основную и отказоустойчивую конечные точки. Автоматический выключатель переключается на конечную точку сбоя при возникновении постоянных сбоев. Внешние службы с географической избыточностью предпочтительнее поставщиков из одного региона для важнейших интеграций.
Мониторинг инфраструктуры	✅ trust.salesforce.com отслеживается посредством status API. Подпишитесь на уведомления о статусе экземпляра. Решение реагирует на состояние работоспособности платформы динамически, снижая некритическую нагрузку во время деградации. Scale Center определяет ресурсоемкие операции до их влияния на резервирование.
Автоматизация отказоустойчивости	✅ Автоматический отказ предпочтителен по сравнению с ручным для агрессивных целей RTO. Проверка состояния выполняется каждые 1-5 минут с обнаружением сбоев. Логика принятия отказоустойчивого решения позволяет избежать ложных положительных результатов (требуется устойчивый сбой, а не временные ошибки). Автоматический откат, если цель отказа также нездоровая.
Отдельные точки сбоя	✅ Проверка архитектуры определяет все отдельные точки сбоя. Каждая определенная SPOF оценивается с точки зрения влияния на бизнес и стоимости смягчения последствий. Высокоэффективные SPOF, смягченные за счет избыточности. Неэффективные SPOF, принятые с документированными процедурами принятия риска и восстановления.
Тестирование возможностей резервирования	✅ Запланированные учения по отказу проверяют автоматическую логику отказа. Резервные системы, протестированные под нагрузкой (не только простаивающие теплые режимы ожидания). Дополнительная нагрузка организации проверена при обработке производственной нагрузки во время активно-пассивных тестов. Уроки, извлеченные из каждого теста, улучшают автоматизацию и процедуры.

Антишаблоны

Где искать	Как плохо выглядит
Отдельные точки сбоя	⚠️ Все решение зависит от одного внешнего API без резервного копирования. Поставщиком настраиваемого домена является SPOF - при сбое поставщика пользователи не могут получить доступ к Experience Cloud. Единая организация пользователя интеграции - при отключении все интеграции не выполняются.
Непроверенная избыточность	⚠️ Активно-пассивная архитектура нескольких организаций настроена, но не протестирована. Дополнительная организация не синхронизируется, но проверка состояния не настроена. Первая попытка сбоя происходит во время реальной катастрофы, выявляющей поврежденную или неработоспособную дополнительную организацию.
Пробелы в синхронизации данных	⚠️ Активно-пассивная мультиорганизация с репликацией CDC, настроенной для 5 из 30 важных объектов. Происходит сбой, но в дополнительной организации отсутствует 80% обязательных данных. Отсутствует мониторинг задержки репликации - дополнительная организация на 3 дня позже основной, но без предупреждений.
Ложная избыточность	⚠️ При условии многорегиональной архитектуры, когда обе организации фактически размещались в одном регионе Hyperforce. «Избыточные» внешние API, которые фактически используют одного поставщика в верхнем звене. Несколько путей интеграции, которые все перенаправляются через одну точку сбоя.
Государственная архитектура	⚠️ Логика приложения зависит от состояния памяти, предотвращающего горизонтальное масштабирование. Сервер единого приложения удерживает состояние сеанса пользователя - перезагрузка сервера выводит всех пользователей. Статические ресурсы кэшируются в памяти приложения вместо кэша платформы, создавая несоответствие между серверами.
Нет автоматических выключателей	⚠️ Внешняя интеграция не выполняется, и каждая транзакция ожидает полного 120-секундного ожидания. Все пользователи, на которых повлияет недоступность отдельной внешней системы. Нет изоляции сбоев - одна неудачная интеграция ухудшает производительность всей платформы.
Только отказ вручную	⚠️ Мультиорганизационная архитектура с только ручными процедурами отказа. Требует 2-часовой процедуры для запуска сбоя во время сбоя бизнеса. Автоматическая проверка состояния не внедрена. Решение об отказе требует утверждения руководителя, откладывающего восстановление.
Сбой планирования нагрузки	⚠️ Дополнительная организация в активно-пассивной архитектуре, размер которой составляет 20% от производственной загрузки. Происходит сбой, но дополнительная организация не может обработать полный производственный трафик. Активная архитектура с загрузкой обеих организаций на 85% не оставляет избыточности при сбое одной организации.
Отклонение конфигурации	⚠️ Основная и дополнительная организации расходятся во времени из-за не синхронизированных развертываний. Метаданные развернуты в основной, но не в дополнительной. Отказ отображает дополнительную организацию под управлением 6-месячной версии кода.
Переработка	⚠️ Мультиорганизационная архитектура с активной репликацией для внутренних инструментов администратора, используемых 5 людьми. Операционная сложность мультиорганизации, не оправданная бизнес-критичностью. Цель доступности 99,999% для пакетного отчета приемлема на уровне 99%.
Географическое непонимание	⚠️ Если предположить, что Hyperforce “мультирегион” предоставляет возможности мультиорганизации автоматически. Непонимание того, что одна организация всегда находится в одном регионе, а несколько регионов требуют наличия нескольких организаций. Избыточность на основе географии невозможна в архитектуре одной организации.
Интеграционная муфта	⚠️ Все интеграции синхронны без асинхронного резерва. Недоступность внешней системы блокирует операции пользователя. Механизм очереди отсутствует - транзакции не выполняются, если внешняя система временно не работает. Пользователи не могут продолжить работу при недоступной поддержке интеграции.