Надежность

Salesforce управляет устойчивой инфраструктурой в нескольких регионах с автоматическим отказоустойчивостью и устойчивостью на уровне инфраструктуры. Платформа занимается резервированием центра обработки данных, доступностью сети и исправлением инфраструктуры, статус доступности платформы в реальном времени можно увидеть на Trust.salesforce.com.

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

Salesforce SLA охватывает платформу, но вы ответственны за надежность всего вышестоящего слоя инфраструктуры. Вы ответственны за определение и достижение собственных целей уровня обслуживания (SLO) - целей надежности, необходимых вашему предприятию. Надежность уровня приложения остается вашей обязанностью, вне зависимости от уровня SLA платформы. Та же платформа, которая гарантирует доступность, также ограничивает ее: управляющий ограничивает потребление ресурсов каждым клиентом, чтобы ни один клиент не мог ухудшить платформу для других. Поэтому ваше решение должно быть изящно расширено в этих пределах, а не просто запрашивать больше нагрузки.

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

Надежность - это не предотвращение всех сбоев. Сбои происходят в распределенных системах. Надежность - это создание систем, которые предвосхищают сбой, помогают сдерживать радиус взрыва и восстанавливают обслуживание автоматически. Требования к надежности определяются влиянием на бизнес. Например, клиентский портал Experience Cloud, требующий 99,9% доступности, использует принципиально другие архитектурные решения, чем внутренний процесс создания пакетных отчетов, допускающий периодические задержки.

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

Надежность — это то, что создается в систему до ее запуска, включая:

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

Надежность - это структурное свойство вашего решения.

Операционное совершенство — это способ эксплуатации, совершенствования и поддержки системы после запуска, включая:

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

Операционное совершенство практикуется; это человеческая и процессная дисциплина, окружающая ваше решение.

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

Учитывайте следующее различие: Надежность решает "выживет ли эта система?" в то время как функция «Operational Excellence» определяет «может ли ваша рабочая группа управлять ею?» Абсолютно надежная система, управляемая рабочей группой без рунетов, непоследовательных развертываний или циклов обратной связи, может не сработать на практике. Отличная в оперативном отношении рабочая группа, управляющая хрупкой, плохо продуманной системой, будет переполнена инцидентами, которые они не смогут предотвратить. Оба компонента необходимы и не заменяют друг друга.

Надежность не работает изолированно. Как описано в предыдущих разделах, «Operational Excellence» является ближайшим партнером. Оба компонента имеют общий уровень наблюдения: надежность определяет, что вы создаете в систему, а оперативное совершенство определяет, как работает ваша команда. Trés также требует инфраструктуру, устойчивую к атакам и поддерживающую целостность данных: система не является надежной, если она может быть скомпрометирована. Оптимизация ресурсов предотвращает исчерпание губернаторского лимита, обеспечивая надежность платформы в масштабах. Оптимизация затрат балансирует инвестиции надежности и бизнес-значение, которое они предоставляют. Цели доступности оправдывают архитектурную сложность, необходимую для их достижения. Ни одна из основ не позволяет создать четкое решение в отрыве друг от друга; надежность обеспечивает структурную основу, от которой зависят и укрепляют другие основы.

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

• Распределение загруженности посредством пакетирования. Обработка нескольких записей в одной транзакции вместо использования последовательных операций на запись. Пакетная обработка использует общие управляющие ограничения в пакете, обработанном в одной транзакции, соблюдая эти ограничения при увеличении производительности. Обработка Apex на основе коллекций, пакетные задания с настраиваемой областью и события платформы, израсходованные в пакете, - все это воплощает этот принцип. Хорошо пакетированные решения обрабатывают 200 записей с таким же количеством операторов SOQL и DML, как и одна запись в последовательной обработке. Распределенные схемы загруженности обеспечивают устойчивость, поскольку ни одна ошибка записи не влияет на обработку всего пакета.
• Предположим, все не удастся. Ограничения для управляющих, окна обслуживания платформы и зависимости интеграции создают режимы сбоев, связанные с многопользовательской архитектурой Salesforce. Создайте для этих ошибок платформы с самого начала. Запросы SOQL превышают ограничения строк в искажении данных. Процессорное время Apex может истечь во время сложных расчетов. Время ожидания выноски может произойти из-за медленной работы внешних служб. Блокировки строк DML не выполняются при столкновении параллельных транзакций. Ограничения по объему хранилища могут не выполниться при неожиданном увеличении загрузки файлов. Архитекторы, планирующие эти ошибки, создают надежные решения без ручного вмешательства. Эти надежные системы определяют приближающиеся контролирующие ограничения, содержат радиус взрыва посредством обработки ошибок и восстанавливаются автоматически посредством инфраструктур повторных попыток и событий платформы.
• Создание самовосстанавливающихся систем. Создайте решения, которые определяют сбои и восстанавливаются автоматически без вмешательства человека. События платформы включают настраиваемые схемы повтора. Доставка подписчику может быть повторена посредством EventBus.RetryableException, хотя повтор исходной транзакции требует настраиваемой архитектуры. Обработка ошибок потока направляет исключения в потоки восстановления. Пакетные задания Apex изолируют сбои фрагментов - неудачный фрагмент не мешает обработке других фрагментов - включительно с частичным выполнением задания и целевой повторной попыткой. Внедрите четкую логику повтора, используя отслеживание ошибок в AsyncApexJob для восстановления после временного сбоя. Примените экспоненциальную обратную связь к этим схемам повтора при обработке переходных сбоев. Самовосстанавливающиеся системы сохраняют целевые показатели доступности даже во время инцидентов в нерабочее время, когда люди могут быть недоступны, уменьшая оперативную нагрузку и сокращая среднее время восстановления.
• Сначала создайте бизнес-требования. Определите цели уровня обслуживания на основе фактического влияния на бизнес, прежде чем выбирать технические решения. Не каждый компонент требует наличия пяти девяток. Соотнесите инвестиции в надежность с бизнес-критичностью и создайте изящное ухудшение для вспомогательных функций. Реалистичные цели позволяют выбирать подходящую архитектуру и избегать чрезмерного проектирования или недопоставки.
• Проверка восстановления посредством учений. Запланируйте учения по послеаварийному восстановлению, которые тестируют резервное восстановление, отказоустойчивые процедуры и сценарии реагирования на инциденты. Восстановите безопасную среду Full Copy Sandbox из производственной резервной копии для проверки процессов восстановления. Внедрите преднамеренные сбои в безопасной среде, чтобы убедиться, что мониторинг обнаруживает проблемы и что автоматическое восстановление выполняется корректно. Учения обнаруживают пробелы в процедурах, инструментах и беговых книгах, прежде чем реальные инциденты отобразят их. Документируйте результаты обучения и отслеживайте устранение обнаруженных пробелов. Регулярное тестирование обеспечивает актуальность возможностей восстановления по мере изменения решений и состава участников рабочей группы.

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

• Мультирегиональная инфраструктура и отказоустойчивость: Salesforce Hyperforce предоставляет региональным центрам обработки и хранения данных автоматический отказ внутренних служб. Он также предоставляет несколько зон доступности в регионах и репликацию данных на уровне инфраструктуры. Платформа прозрачно обрабатывает избыточность и распределение зон доступности в регионах.
• Обязательства по платформе SLA: Гарантированные уровни доступности с помощью договорных средств правовой защиты согласовываются для каждого клиента. Trust.salesforce.com публикует статус платформы и журнал работы в реальном времени, но любая конкретная гарантия доступности и ее исправления содержатся в соглашении, заключенном вами. Просмотрите контракт и текущую документацию Salesforce Trust и Compliance на наличие обязательств, применимых к вашей организации.
• Избыточность инфраструктуры: Платформа поддерживает избыточные серверы, пути сети, инфраструктуру базы данных и системы хранения данных. Сбой на уровне инфраструктуры происходит автоматически во время сбоев аппаратного обеспечения без действий клиента. Резервные копии платформы защищают от потери данных на уровне инфраструктуры.
• Обслуживание и обновления платформы: Основные выпуски платформы предоставляют функции и исправления безопасности с обратной совместимостью под управлением Salesforce. Окна обслуживания платформы запланированы и отображаются на Trust.salesforce.com. Исправление инфраструктуры происходит прозрачно, без участия клиента.
• Мониторинг состояния базовой платформы: Salesforce отслеживает производительность инфраструктуры, включая время ответа базы данных, задержку сети, работоспособность шлюза API и производительность системы хранения данных. Состояние работоспособности платформы отображается на Trust.salesforce.com и содержит обновления инцидентов в реальном времени. Статус экземпляра доступен посредством API статуса.

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

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

Цели уровня обслуживания (SLO) количественно определяют требования к надежности в измеримых выражениях. SLO соединяют бизнес-требования и техническую архитектуру. Прежде чем выбрать технологии или создать модели данных, установите ООД, определяющие успех для каждого важного потока пользователя.

ООД обычно измеряют:

• Доступность - процент времени функционирования и доступности системы
• Задержка - время, необходимое для выполнения операций, измеряемое как процентили (p50, p95, p99)
• Промежуточная реализация - объем операций, выполненных успешно за единицу времени
• Уровень ошибок - процент запросов, которые не выполняются или возвращают ошибки
• Время восстановления - продолжительность, необходимая для восстановления обслуживания после инцидентов

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

Соглашения об уровне обслуживания (SLA) — это договорные обязательства с последствиями сбоев. Любой уровень гарантированной доступности и его средства правовой защиты по контрактам согласовываются для каждого клиента. Просмотрите соглашение и текущую документацию Salesforce Trust и Compliance на наличие обязательств, применимых к вашей организации.

ООД решения должны быть менее жесткими, чем ООД платформы, чтобы сохранить бюджет ошибки. Если SLA платформы и SLO решения нацелены на 99,9%, любой значительный простой платформы напрямую расходует ваш бюджет ошибки, не оставляя буфера для сбоев уровня приложения, проблем интеграции или запланированного обслуживания в одном периоде измерения. ООД формально нарушается, только если совокупный простой исчерпывает полный бюджет ошибки для периода измерения. Если SLA и SLO установлены на одну цель, один инцидент платформы может полностью исчерпать этот бюджет. Например, если платформа предоставляет 99,9%, нацельтесь на SLO решения 99,5%, чтобы сохранить значимый буфер для проблем, которые нужно решить — ошибок приложения, ошибок интеграции и окон развертывания.

Индикаторы уровня обслуживания (SLI) - это измерения, используемые для оценки достижения SLO. SLI должны быть объективно измеримы, последовательно собраны и напрямую связаны с взаимодействием пользователя.

В решениях Salesforce SLI включают:

• Время работы платформы посредством Trust.salesforce.com
• Время загрузки страницы посредством аналитики Experience Cloud
• Время ответа API посредством Event Monitoring (для чего требуется надстройка Event Monitoring или Salesforce Shield)
• Уровень успеха транзакций посредством настраиваемой регистрации приложения
• Пакетное выполнение задания посредством мониторинга AsyncApexJob

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

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

Определите надежность с точки зрения пользователя, а не только на основе технических показателей. Система, сообщающая о 99,9% времени работы, но сталкивающаяся с частым истечением времени ожидания, не справляется с надежностью на основе взаимодействия пользователя. Пользователи больше заинтересованы в успешном завершении бизнес-правил, чем в индивидуальном времени работы API.

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

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

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

Внутрирегиональный сбой в зонах доступности происходит автоматически и включен в стандартные обязательства платформы SLA — Salesforce управляет этим прозрачно на уровне инфраструктуры. Межрегиональное (внерегиональное) аварийное восстановление является отдельным платным предложением и не включено по умолчанию в стандартную версию. Если ваши требования к обеспечению непрерывности бизнеса требуют межрегионального сбоя, задокументируйте эту зависимость четко в плане послеаварийного восстановления, чтобы заинтересованные лица понимали различие между включенной устойчивостью платформы и приобретенными возможностями межрегионального DR.

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

• Бизнес требует гарантированного RPO/RTO за пределами возможностей платформы
• Требования нормативных актов предписывают географическую изоляцию данных, планирование обеспечения непрерывности деятельности требует полной независимости от одного региона
• Консолидация организации невозможна из-за требований к автономности бизнес-единиц.

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

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

Создайте синхронизацию данных, соответствующую требованиям RPO. События платформы предоставляют поток событий в близком к реальному режиме времени для важных изменений данных. Сбор данных об изменении предоставляет автоматическое отслеживание изменений для выбранных объектов с минимальным развитием. Запланированная репликация API посредством Bulk API 2.0 на фиксированных интервалах соответствует менее чувствительным к времени справочным данным.

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

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

Мониторинг состояния платформы Salesforce посредством API Trust.salesforce.com и статусов экземпляров. Подпишитесь на уведомления о статусе экземпляра для получения предупреждений об инцидентах, окнах обслуживания и влиянии на производительность. Сигналы работоспособности платформы включают упреждающее реагирование, а не устранение неполадок.

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

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

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

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

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

Важнейшие губернаторские ограничения, влияющие на архитектурные решения:

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

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

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

Автоматизация, запущенная записью, должна обрабатывать 200 записей на вызов триггера, поскольку платформа обрабатывает выполнение триггера пакетами до 200 записей. Операции Lightning Data Service пакетируются автоматически, но настраиваемые компоненты должны четко внедрять пакетные схемы при выполнении операций DML.

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

Асинхронные возможности Salesforce и их архитектурное соответствие:

• Пакет Apex: Обработка больших объемов записей фрагментами до 2 000 записей на метод выполнения. Пакет предоставляет выделенные контролирующие ограничения на фрагмент и изоляцию от сбоев — неудачный фрагмент не препятствует выполнению других фрагментов. Это обеспечивает частичный успех и целенаправленную повторную попытку. Внедрите настраиваемую логику повторной попытки для переходных сбоев, отслеживая неудачные диапазоны фрагментов в объекте AsyncApexJob и создавая повторную очередь целевых пакетных заданий. Используйте пакет для миграции данных, запланированных пакетных обновлений и широкомасштабной обработки данных. Существует не более пяти пакетных заданий, выполняемых или ожидающих выполнения одновременно в организации. Дополнительные задания в очереди Flex Apex (до 100 заданий в статусе «Удержание») и выполняются автоматически по мере открытия интервалов.
• Apex в очереди: Выполнение асинхронных заданий с возможностью цепочки для включения многоэтапных бизнес-правил и параметров сложных объектов. Очередь Apex делит единые ограничения DailyAsyncApexExecutions 250 000 выполнений в сутки со всеми другими асинхронными Apex — пакетными, Future и Scheduled Apex — вместо того, чтобы удерживать выделенное распределение для очереди. Используйте Queuable Apex для многоэтапной оркестрации и интеграции бизнес-процессов, требующих последовательной обработки с лучшим мониторингом, чем методы @ future.
• События платформы: События платформы используются в архитектуре событий публикации и подписки, которая отделяет публикаторов от подписчиков. События воспроизводятся из окна сохранности 72 часа (3 дня). Продленное хранение более 72 часов доступно в качестве платной надстройки — проверьте текущие максимальные ограничения и статус GA в последней документации событий Salesforce Platform, прежде чем подтверждать обязательства по SLA, зависящие от расширенного воспроизведения. Используйте события платформы для автоматизации под управлением событий, межсистемной интеграции и потоковой передачи данных в реальном времени. События платформы предоставляют естественные асинхронные границы между этапами транзакций.
• Запланированный Apex: Выполнение заданий по фиксированному расписанию посредством выражений CRON посредством System.schedule(). Задание может быть запланировано на выполнение не более одного раза в час — поля секунд и минут CRON должны использовать фиксированные значения, а не диапазоны. Не выходя за пределы максимального количества запланированных заданий Apex на организацию, объединив похожие операции в единые запланированные классы.

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

• Разделение на основе даты: Обрабатывайте данные во временных окнах, включительно с транзакциями текущего месяца или обращениями последнего квартала. Архивируйте архивные данные в большие объекты или внешнее хранилище для обеспечения управляемости рабочего набора. Большинство транзакционных запросов фокусируются на последних данных, что делает разделение по времени естественным эффективным.
• Разделение типа записи: Обрабатывайте разные типы записей независимо, включительно с обращениями партнеров и обращениями клиентов или организациями-предприятиями и организациями SMB. Отдельные пакетные задания на тип включают параллелизацию. Тип записи часто коррелирует с разными бизнес-процессами, оправдывающими независимую обработку.
• Разделение на основе ответственности: Распространяйте обработку по ответственному за запись, например, обрабатывайте возможности каждого региона продаж отдельно. Разделение на основе ответственности особенно эффективно в сочетании с моделью общего доступа, поскольку безопасность обеспечивается с помощью существующих механизмов. Разделение на основе ответственности включает географическое распределение загрузки обработки.

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

• Лицензии пользователя - рост количества заголовков, стимулирующий распределение вызовов API и права хранения на пользователя
• Хранилище данных - объемы транзакций и политики сохранности, стимулирующие потребление хранилища (номинально планируется как минимум 10- 20% годового прироста)
• Вызовы API - количество интеграции и частота распределения API за 24 часа (каждая новая схема интеграции добавляет регулярное потребление)
• Пропускная способность обработки - Количество пакетных заданий и сложность, влияющие на очереди асинхронной обработки и ограничения параллельного выполнения

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

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

• Тестирование объема данных: Заполните объемы данных в производственном масштабе в безопасной среде Full Copy Sandbox, чтобы проверить производительность запроса с помощью реального перекоса данных, глубины взаимосвязи и количества записей. Протестируйте с помощью 10 миллионов+ записей, когда производство достигнет этого масштаба. Алгоритм оптимизатора запросов резко меняется по мере увеличения объема данных, что может привести к введению в заблуждение результатов мелкого Масштабного тестирования.
• Параллельное тестирование пользователя: Имитация максимальной параллельной загрузки пользователя для проверки производительности транзакций и спора. Используйте масштабные тесты, доступные для соответствующих организаций, чтобы имитировать производственные нагрузки в безопасной среде перед развертыванием. Параллельное выполнение открывает проблемы блокировки, недоступные в однопользовательском тестировании.
• Нагрузочное тестирование API: Создайте пиковые объемы API для проверки масштабируемости интеграции, обработки ограничения частоты и поведения выключателя при устойчивой нагрузке. Тесты загрузки API определяют корректность логики повтора и обработки ошибок в стрессовых условиях.
• Масштабное тестирование: Масштабное тестирование — это продукт Salesforce, используемый для имитации загруженности производства по сравнению со средой Full Copy Sandbox, масштабированной в соответствии с производственной мощностью. Масштабное тестирование выполняется против безопасных сред Full Copy Sandbox в Hyperforce. Для использования производственного экземпляра не обязательно использовать Hyperforce. Вы создаете планы тестирования в производственной организации, а тесты выполняются в безопасной среде. Используйте Масштабное тестирование для проверки предельной головной офис губернатора, производительности обработки асинхронизации и алгоритма ответа интеграции в условиях пиковой нагрузки перед основными развертываниями.

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

Определение иерархии важности функций:

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

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

Состояния автоматического выключателя:

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

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

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

Экспоненциальное отклонение предотвращает повторные бури, которые перегружают восстанавливающие системы. Первая попытка может произойти через 1 секунду, вторая - через 2 секунды, третья - через 4 секунды и четвертая - через 8 секунд. Максимальная задержка составляет 30-60 секунд, независимо от экспоненциального роста. Эта схема резервирования предоставляет сбойным системам время на восстановление, ограничивая общую продолжительность повторных попыток.

Соотнесите стратегию повторной попытки с типом сбоя.

• Время ожидания сети: Повторите попытку с коротким отступлением (операция могла не дойти до сервера)
• Ошибки ограничения уровня (429): Повторите попытку после значения заголовка «Повторить попытку после» или после времени сброса ограничения скорости
• Ошибки сервера (5xx): Повторите попытку с экспоненциальным резервным копированием, так как сервер может временно перегрузить
• Ошибки клиента (4xx, кроме 429): Не повторяйте попытки; исправьте запрос, поскольку ошибка указывает на недопустимый ввод
• Ошибки ограничения администратора: Не пытайтесь повторить транзакцию; повторная очередь в качестве асинхронной операции с выделенными ограничениями, например, посредством публикации события сбоя, которое асинхронный подписчик обрабатывает с резервной копией в соответствии с новыми ограничениями транзакций

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

• Альтернативный источник данных: Извлекайте данные из сеанса кэширования платформы или из раздела организации, если интерфейс API в реальном времени недоступен. Предварительно заполните кэш во время успешных операций. Кэш предоставляет устаревшие, но доступные данные, что лучше, чем полный сбой для многих способов использования.
• Поведение по умолчанию: Примените стандартные бизнес-правила, если услуга персонализации или пополнения недоступна. Процесс со значениями по умолчанию и пометка для пополнения после восстановления службы. Стандартный алгоритм сохраняет производительность при снижении точности.
• Процесс вручную: Включите выполнение операций вручную при сбое автоматизации. Предоставьте администраторский интерфейс для завершения застрявших транзакций. Резервное копирование вручную предотвращает потерю данных и поддерживает непрерывность бизнеса при нарушении автоматизации.
• Очередь для повторной попытки: Храните операции в событиях платформы или настраиваемых объектах очереди для обработки при восстановлении внешней системы. Повтор события платформы с 72-часовым стандартным сохранением включает восстановление подписчика после временных сбоев, без потери данных.

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

Рекомендации по проектированию времени ожидания:

• Синхронные выноски пользователя: Используйте максимум 5-10 секунд для поддержки адаптивного пользовательского интерфейса, поскольку пользователи обычно не ждут больше времени
• Фоновые выноски асинхронизации: Используйте 30-60 секунд для размещения переменной внешней производительности без ожидания пользователя
• Выноски пакетной обработки: Использовать всю 120 секунд, отведенную на ожидание ответа
• Несколько выносок на транзакцию: Общее время бюджета во всех выносках, например, три выноски по 10 секунд каждая, занимающие 30 секунд 120-секундного бюджета.

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

Создайте комплексную обработку ошибок для трансформации сбоев из аварий в управляемую деградацию:

• Быстрый сбой: Проверьте вводные данные и предварительные условия в точках входа. Проверьте контролирующее ограничение потребления перед дорогостоящими операциями. Определяйте сбои немедленно, а не распространяйте недопустимое состояние через несколько уровней обработки. Раннее обнаружение уменьшает радиус взрыва и упрощает отладку.
• Провал: Поддерживайте возможности пользователя даже при частичном сбое операций. Если проверка 3 из 200 записей в пакете не удалась, обработайте 197 успешных записей и сообщите о 3 сбоях, а не об ошибке всего пакета. Частичный успех лучше, чем полный сбой для пакетных операций.
• Информативный сбой: Зарегистрируйте ошибки с кодом транзакции, контекстом пользователя, параметрами ввода и трассировкой стека. Недостаточный контекст ошибки является основным препятствием для быстрого устранения инцидентов. Каждый журнал ошибок должен позволить ответчику понять, что не удалось, почему и как воспроизвести.
• Безопасный сбой: Убедитесь, что сбои не нарушают целостность или безопасность данных. Откат частичных транзакций, а не оставление данных в несогласованном состоянии. Никогда не открывайте сведения о внутренней ошибке конечным пользователям, поскольку трассировка стека открывает сведения о внедрении, полезные злоумышленникам.

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

RTO зависит от бизнес-возможности:

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

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

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

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

• Резервные копии данных: Внедрите комплексную стратегию резервного копирования данных и метаданных. Экспортируйте данные критических объектов посредством собственной службы экспорта данных — каждые 7 дней для версий Enterprise Edition, Performance Edition и Unlimited Edition; каждые 29 дней для версий Professional Edition и ниже. Экспорт файлов доступен в течение 48 часов после отправки электронного уведомления, не считая выходных, после чего он автоматически удаляется. Настройте автоматический процесс загрузки, чтобы файлы не терялись без возможности восстановления. Используйте Metadata API и Salesforce CLI (извлечение проекта sf) для конфигурации организации управления версиями, настраиваемого кода и декларативной автоматизации в системе контроля источников, например, Git. Используйте резервную копию метаданных как часть стандартных ожидаемых продаж CI/CD. Дополните резервную копию данных специальными службами резервного копирования и восстановления, например, Own для моментального восстановления, восстановления детализированных записей и сохранения за пределами собственной каденции экспорта. Экспорт собственных данных не поддерживает моментальное восстановление, и сторонняя оснастка обязательна, если RTO/RPO требует детализированных окон восстановления. Регулярно тестируйте процедуры восстановления; резервная копия, которая не была восстановлена, является непроверенным предположением.
• Резервные копии метаданных: Управление версиями всех метаданных посредством исходного формата Salesforce DX в хранилищах Git. Управление версиями метаданных позволяет быстро восстановить конфигурацию после повреждения или непреднамеренных изменений. Каждое развертывание должно воспроизводиться из элементов исходного управления. Метаданные в Git предоставляют моментальное восстановление для конфигурации.
• Резервные копии файлов: Экспортируйте записи, вложения и документы ContentVersion во внешнее хранилище. Salesforce лучше работает для активных данных, а не для длительного архивирования файлов - экспортируйте файлы во внешнее хранилище для сохранности по регламенту. Внедрите автоматический экспорт файлов для нормативных требований к сохранности, превышающих возможности платформы.
• Проверка: Периодически восстанавливайте резервные копии в стартовых организациях или в безопасных средах разработчика для проверки как процедур, так и целостности резервных копий. Непроверенные резервные копии часто не выполняются при необходимости из-за неполной области резервного копирования или поврежденных архивов. Запланируйте ежеквартальное восстановление проверки для обнаружения проблем до возникновения аварий. Отслеживайте резервную свежесть в дополнение к восстановлению проверки. Предупреждение, когда последняя успешная резервная копия старше ожидаемой каденции, например, когда еженедельный экспорт не завершен более 8 дней. При такой проверке скрыто неудачное резервное задание появляется немедленно, а не при следующем обучении.

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

• Сбор данных об изменении (CDC): Подпишитесь на события изменения для отслеживаемых объектов. CDC предоставляет создание, обновление, удаление и отмену событий с измененными значениями полей. Предоставляет репликацию практически в режиме реального времени с минимальными усилиями по разработке для поддерживаемых объектов, включая стандартные и настраиваемые. При условии ежедневного распределения доставки на основе выпуска.
• События платформы: Архитектура настраиваемых событий для репликации бизнес-событий и изменений состояния. Более гибкий, чем CDC, поддерживающий настраиваемые полезные данные и сложные структуры событий, но требующий четкой логики публикации в триггерах или процессах. Стандарт окна 72-часового воспроизведения включает восстановление после временных ошибок подписчика.
• Запланированная репликация API: Репликация API расписания - это пакетное извлечение посредством Bulk API 2.0 по фиксированному расписанию. Это простейшее внедрение с RPO, равным частоте извлечения. Репликация запланированного API подходит для некритических данных, где выполнение в близком к реальному режиме времени не обязательно, например, со справочными данными или архивной аналитикой.
• Репликация, организованная MuleSoft: Для сложных топологий мультисистемной репликации платформа MuleSoft Anypoint Platform предоставляет оркестрацию, трансформацию и мониторинг. Его использование целесообразно для репликации в Salesforce и нескольких внешних системах, что требует сложной логики маршрутизации и трансформации.

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

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

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

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

• Доступность рабочей группы: Процедуры расширения документов и резервный персонал для важных ролей. Убедитесь в отсутствии единой точки сбоя в operational Knowledge. Основные службы реагирования могут быть недоступны во время стихийных бедствий, что делает резервный персонал критически важным.
• Процедуры связи: Определите способ передачи инцидентов пользователям, клиентам и руководителям. Создайте каналы связи, функционирующие при недоступности основных инструментов (например, страниц внешнего статуса или систем SMS-уведомлений), включая саму Salesforce.
• Зависимости поставщиков: Соотнесите зависимости внешних поставщиков, важные для работы с решениями. Пути расширения документов и контрактные соглашения об обслуживании для каждого важного поставщика, включительно с Salesforce, партнерами по интеграции и поставщиками пакетов ISV. Например, узнайте, какие поставщики предоставляют круглосуточную поддержку, а у каких есть поддержка только по часам работы, влияющая на время восстановления.
• Нормативные обязательства: Определите требования к уведомлениям, инициированные длительными сбоями. Финансовые услуги, здравоохранение и государственные контракты часто требуют уведомления об инциденте в определенных временных рамках. Несоблюдение может создать регулятивный и правовой риск, что усугубляет последствия бедствий.

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

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

Сигналы статуса платформы (ранее описанные в разделе «Отслеживание состояния платформы») показывают, когда инфраструктура Salesforce деградирует, но не производительность собственного решения.

Дополните эти сигналы возможностью наблюдения за конкретным решением:

• Отслеживание событий: Отслеживание событий содержит подробные журналы, собирающие вызовы API, просмотры страниц, экспорты отчетов, действия входа и выполнение Apex. Объекты EventLogFile доставляют журналы с частотой 24 часа (ежедневно) или 1 час – ежечасная доставка требует надстройки Event Monitoring или Salesforce Shield. Хранение настраивается до 365 дней посредством настройки, но расширенное хранение требует надстройки Salesforce Shield или Event Monitoring Без надстройки файлы журнала хранятся 1 день. Перенаправляйте события во внешнюю систему управления информацией о безопасности и событиями (SIEM) или на платформу агрегации журнала для корреляции, оповещения и сохранения за пределами собственных ограничений. Используйте Event Monitoring для обнаружения аномальных моделей потребления API, для определения запущенных процессов Apex и для аудита доступа к данным в регулируемых средах.
• Центр масштаба: Scale Center предоставляет доступ уровня транзакций к долгосрочным операциям, спорам о блокировке строк и ресурсоемким транзакциям. Scale Center позволяет архитекторам определять риски надежности из определенных схем транзакций, прежде чем они станут причиной инцидентов, ориентированных на пользователя. Еженедельные проверки могут открыть возможности оптимизации.
• Активный мониторинг: Proactive Monitoring позволяет постоянно оценивать состояние организации, производительность наплавки и риски масштабируемости. Proactive Monitoring предоставляет предупреждения о скачках ограничения запросов API, параллельных сбоях выполнения Apex, проблемах ограничения строк SOQL и тенденциях потребления хранилища. Он доступен клиентам с правом «Успех подписи» (ранее «Поддержка подписи») — функция самообслуживания не входит в стандартные версии.

Отслеживайте производительность приложения с точки зрения пользователя, а не инфраструктуры:

• Отслеживание реальных пользователей (RUM): Измерьте фактическое взаимодействие пользователя посредством аналитики Experience Cloud или настраиваемых инструментов. RUM собирает реальную задержку, отображающую фактические условия сети, производительность устройства и географическое распределение. Синтетический мониторинг не может реплицировать эту переменную.
• Синтетический мониторинг: Периодически выполняйте автоматические транзакции из нескольких расположений для проверки доступности и производительности. Синтетический мониторинг обнаруживает проблемы до того, как пользователи сообщат о них. Внедрите синтетический мониторинг посредством запланированного Apex, выполнения критических операций и составления отчетов по результатам с помощью событий платформы.
• Отслеживание транзакций: Прибор сложных многоэтапных операций для сбора времени на шаг. Далее определите, какой этап пятиэтапного бизнес-правила вводит задержку. Не обрабатывайте весь поток как черный ящик. Время этапа отображает возможности оптимизации, недоступные в агрегированных показателях.

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

• Уровень ошибок - Процент вызовов, возвращающих ошибки (цель: <1% для здоровой интеграции)
• Задержка - Время ответа, измеренное в p50, p95, p99 (установленное SLO на интеграцию на основе бюджета времени ожидания)
• Срок ожидания - Процент превышения настроенного времени ожидания (целевой показатель: <0,1%)
• Состояние автоматического выключателя - Разомкнутое состояние обозначает устойчивый сбой, требующий немедленного внимания
• Глубина очереди - Для асинхронных интеграций растущая очередь обозначает отставание обработки от уровня производства

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

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

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

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

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

Для клиентов с правом «Успех подписи» Proactive Monitoring предоставляет обнаружение аномалий на уровне платформы без дополнительной конфигурации. Дополните его обнаружением аномалий приложения для настраиваемых SLI, экспортированных на внешние аналитические платформы. Используйте сигналы аномалии для руководства расследованием, а не для запуска немедленного расширения, поскольку обнаружение аномалии имеет более высокий уровень ложно положительных результатов, чем предупреждения о пороге.

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

Цели надежности и ООД

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

Высокодоступная архитектура

• Создание избыточности на уровнях данных, приложений и интеграции
• Мониторинг состояния платформы посредством Trust.salesforce.com и API статуса экземпляра
• Внедрение проверки работоспособности приложения, независимо от статуса платформы
• Учитывайте архитектуру нескольких организаций, только если бизнес-требования четко оправдывают сложность
• Создание автоматического отказа с помощью протестированных бегунок для схем нескольких организаций

Масштабируемость и планирование нагрузки

• Разработка транзакций, выполненных в пределах 70% от контролирующих ограничений при нормальной загрузке
• Внедрение пакетных схем во все триггеры Apex, пакетные классы и интеграции
• Использование асинхронной обработки для операций, превышающих синхронные ограничения
• Пакетные интеграции API, а не отдельные вызовы записей
• Проведение нагрузочного тестирования с использованием объемов данных в производственном масштабе перед развертыванием
• Мониторинг использования пропускной способности посредством OrgLimits API или настраиваемого Apex и предупреждение по мере приближения потребления к 70% операционного потолка
• Требования к возможностям проекта на основе ожиданий роста за 12 месяцев
• Разделение массовых данных по дате, типу записи или ответственному для включения параллельной обработки, когда объемы превышают последовательные ограничения

Отказоустойчивость и устойчивость

• Создание изящного ухудшения с определенными уровнями важности функций
• Внедрение автоматических выключателей для всех внешних интеграций системы
• Применение логики повтора с экспоненциальным резервированием для переходных сбоев
• Настройка времени ожидания, соответствующего типу операции (5-10s для пользователя, 30-60s для асинхронизации)
• Разработка резервных стратегий посредством кэша платформы и схем на основе очереди
• Внедрение структурированной обработки ошибок с достаточным контекстом диагностики

Аварийное восстановление и бесперебойное функционирование

• Определение RTO и RPO на бизнес-возможность до проектирования
• Внедрение автоматического резервного копирования данных, метаданных (управление источниками) и файлов
• Проверка процедур восстановления резервных копий ежеквартально в непроизводственных средах
• Отслеживание свежести резервной копии и предупреждение о просрочке запланированной резервной копии
• Разработка стратегии репликации данных, соответствующей требованиям РПО
• Ежегодно проводить тестирование послеаварийного восстановления (ежеквартально)
• Процедуры обеспечения непрерывности деятельности документов, включая пути расширения поставщиков

Мониторинг и возможность наблюдения

• Определение сигналов агрегации службы, интеграции, данных и нагрузки модели здоровья
• Подпишитесь на уведомления о статусе платформы для экземпляра Salesforce
• Внедрение мониторинга реальных пользователей для критических потоков Experience Cloud
• Мониторинг состояния интеграции с помощью уровня ошибок, задержки и состояния выключателя
• Разработка действенных предупреждений с определенными процедурами реагирования и ответственностью
• Перенаправление данных Event Monitoring на внешние платформы для долгосрочного хранения и анализа
• Использование Proactive Monitoring and Scale Center для постоянной оценки риска надежности
• Применение обнаружения аномалий для объема, уровня ошибок и схемы задержки для обнаружения ухудшения, которое пропускается статическими порогами

Опубликуйте отзыв о инфраструктуре с хорошей архитектурой.