Схемы доступности и производительности
Узнайте больше о надежности → Высокодоступная архитектура
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Анализ влияния на бизнес | ✅ ООД, определенные для каждой бизнес-возможности (например, “Поток закрытия возможности: готовность 99,9%, задержка р95 под 2 секунды”), а не на технический компонент |
| Документация потока пользователя | ✅ Каждый критический поток пользователя имеет измеримый ООД, охватывающий доступность, задержку, производительность, уровень ошибок и время восстановления, привязанные к фактическому взаимодействию пользователя |
| Записи решений по архитектуре | ✅ Цели доступности на основе анализа влияния простоя предприятия с документированным обоснованием (например, внутренняя пакетная отчетность 99% по сравнению с обработкой критически важного заказа 99,95%) |
| Характеристики SLO | ✅ Реалистичные цели с учетом сложности архитектуры (99% = стандартные возможности платформы, 99,5% = базовое резервирование и активный мониторинг, 99,9% = осведомленность о многих регионах и автоматический отказ, 99,95% = активные схемы и тестирование хаоса, 99,99% = архитектура нескольких организаций) |
| Документация платформы | ✅ ООД решения менее жесткие, чем ООД платформы (например, ООД платформы 99,9% → ООД решения 99,5%), предоставляющие бюджет ошибок для сбоев уровня приложения |
| Конфигурация мониторинга | ✅ Индикаторы уровня обслуживания (SLI), объективно измеряемые посредством контрольно-измерительных приборов платформы: Время работы Trust.salesforce.com, аналитика Experience Cloud, время ответа API мониторинга событий, выполнение AsyncApexJob |
| Показатели взаимодействия пользователя | ✅ SLO отображают завершенные путешествия пользователя (например, “Поток отправки обращения: все 5 шагов выполнены в течение 8 секунд для пользователей р95”) не отдельное время работы API |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Архитектурная документация | ⚠️ «Система должна быть быстрой и надежной» (не измеримой, не управляет решениями по архитектуре) |
| Характеристики SLO | ⚠️ «Всему нужно 99,999% времени работы» (неоправданное игнорирование разницы в бизнес-критичности между операциями с доходом и внутренними инструментами администратора) |
| Стратегия мониторинга | ⚠️ Мониторинг процессора инфраструктуры в качестве основного SLI (архитекторы показателей платформы не могут действовать, не отображая пользовательский опыт) |
| Планирование нагрузки платформы | ⚠️ SLO решения полностью соответствует SLA платформы на уровне 99,9% (нет бюджета ошибок для проблем уровня приложения, ошибок интеграции или запланированного обслуживания) |
| Документация SLO | ⚠️ ООД, определенные на технический компонент, а не на бизнес-возможности, ориентированные на пользователя (доступность компонента необходима, но недостаточна для надежности работы пользователя) |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Региональная стратегия развертывания | ✅ Развертывание одной области с управляемым платформой резервированием Hyperforce (несколько зон доступности, автоматический отказ инфраструктуры) обеспечивает 99,9% SLO для большинства решений |
| Архитектура нескольких организаций | ✅ схемы с участием нескольких организаций только в том случае, если бизнес требует гарантированной РПО/РТО за пределами возможностей платформы, изоляции нормативных географических данных или полной региональной независимости (активно-пассивной или активно-активной с синхронизацией данных); |
| Репликация данных | ✅ Изменение сбора данных для критических данных (около реального времени RPO, минуты), события платформы для бизнес-событий почти в реальном времени, запланированное извлечение Bulk API 2.0 для справочных данных (круглосуточный RPO) |
| Мониторинг состояния платформы | ✅ Подписка на уведомления о статусе Trust.salesforce.com и API статуса экземпляра, позволяющие активно реагировать на инциденты, окна обслуживания и влияния на производительность |
| Динамическое управление нагрузкой | ✅ Решения реагируют на состояние работоспособности платформы, сокращая некритическую пакетную обработку во время деградации, откладывая фоновые задания во время окон обслуживания |
| Использование центра масштабирования | ✅ Еженедельный обзор центра масштаба определяет долгосрочные транзакции и операции, требующие несоразмерных ресурсов, что позволяет исправить архитектуру до воздействия пользователя |
| Слои обнаружения сбоев | ✅ Многоуровневое обнаружение: сбои платформы посредством API статуса, сбои интеграции посредством мониторинга времени ожидания, сбои приложения посредством регистрации исключений, ухудшение производительности посредством процентилей задержки, предупреждения нагрузки посредством Proactive Monitoring |
| Пороги предупреждения | ✅ Предупреждения инициируют схемы ошибок (например, 5 ожиданий API за 60 секунд) или устойчивое ухудшение состояния, а не отдельные сбои, которые являются нормальными в распределенных системах |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Мультиорганизационный дизайн | ⚠️ Мультиорганизационная архитектура внедрена «на всякий случай» без документированного бизнес-требования, обосновывающего операционную сложность синхронизации данных, инициализации пользователя, координации развертывания |
| Мониторинг состояния платформы | ⚠️ Игнорировать уведомления о статусе Trust.salesforce.com, обнаруживать окна обслуживания, когда пользователи сообщают о сбоях (реактивный, а не активный ответ) |
| Обнаружение сбоев | ⚠️ Предупреждение о каждой отдельной ошибке, независимо от уровня (создает усталость предупреждения, скрывающую критические сигналы); время ожидания единого API инициирует блокировку (чрезмерная реакция на нормальное поведение распределенной системы) |
| Репликация данных | ⚠️ Отсутствует мониторинг интеграции, обнаруживаются сбои интеграции, только когда пользователи сообщают о заблокированных операциях (отсутствует доступ к работоспособности внешней системы) |
| Стратегия резервирования | ⚠️ Синхронный вызов внешней службы пополнения без истечения срока действия или резервного копирования (пользователь блокируется, когда внешняя служба медленно или недоступно) |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Мониторинг реальных пользователей (RUM) | ✅ Фактическая задержка пользователя, измеренная посредством аналитики Experience Cloud или настраиваемых приборов, отображающих реальные условия сети, производительность устройства, географическое распределение |
| Синтетический мониторинг | ✅ Автоматические транзакции из нескольких расположений, проверяющие доступность и производительность до того, как пользователи сообщат о проблемах (например, отправка заказа каждые 15 минут из 3 регионов) |
| Отслеживание транзакций | ✅ Многоэтапные операции, оборудованные с указанием времени на этап, идентифицирующие узкие места (например, выноска проверки адреса этапа 3 составляет 70% от общей задержки) |
| Оптимизация запроса | ✅ Выборочные запросы с индексированными фильтрами, запросы взаимосвязи, сокращающие поездки в оба конца, учет оптимизатора запросов с объемами данных в масштабах производства (поведение кардинально меняется с записями 10M+) |
| Использование кэша платформы | ✅ Разделы кэша сеанса или организации, обслуживающие часто используемые справочные данные, предварительно заполненные во время успешных операций, предоставляющих устаревшие, но доступные данные при недоступности API в реальном времени |
| Конфигурация времени ожидания | ✅ Синхронные выноски, ориентированные на пользователя, 5-10 секунд (оперативный пользовательский интерфейс), фоновые выноски асинхронизации 30-60 секунд (переменная внешняя производительность), пакетная обработка 120 секунд (без ожидания пользователем); общая сумма бюджета по нескольким выноскам на транзакцию |
| Мониторинг задержки интеграции | ✅ процентили задержки р50/р95/р99 на интеграцию с ООД на конечную точку; аномалии задержки (время срабатывания дрейфует вверх) обозначают насыщение нагрузки до полного отказа |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Стратегия мониторинга | ⚠️ Мониторинг только показателей инфраструктуры (серверный процессор, пропускная способность сети) без измерения потока пользователя (показатели не отображают фактическое взаимодействие пользователя) |
| Стратегия кэширования | ⚠️ Отсутствие использования кэша платформы для часто используемых справочных данных (повторные запросы для одних и тех же данных, увеличивающие задержку и расходующие ограничения SOQL) |
| Конфигурация времени ожидания | ⚠️ Выноска синхронного потока со 120-секундным ожиданием, заставляющая пользователя смотреть на загрузку спиннера в течение 2 минут (следует использовать 5-10-секундное ожидание с резервным вариантом) |
| Тестирование производительности | ⚠️ Маломасштабное тестирование с минимальными объемами данных (поведение оптимизатора запросов резко меняется при записях 10M+, что вводит в заблуждение результаты малого тестирования) |
| Интеграционный дизайн | ⚠️ Отсутствие отслеживания многоэтапных бизнес-правил на уровне транзакций (этап узких мест не отображается в агрегированных показателях) |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Горизонтальные схемы масштабирования | ✅ Загруженность, распределенная между несколькими ресурсами: пакетная обработка нескольких записей на транзакцию, асинхронная обработка распределяет работу во времени, разделение данных распределяет нагрузку через границы |
| Конфигурация пакетной обработки | ✅ Оптимальный размер пакета, балансирующий производительность и контролирующие ограничения (2000 записей на выполнение пакета Apex, 200 записей на вызов триггера, 25 запросов на вызов составного API) |
| Управление уровнем API | ✅ Интеграция пакетирования и кэширования уменьшает потребление API, отслеживает распределение API за 24 часа по выпуску, планирование нагрузки добавляет лицензии или увеличение ограничения до исчерпания |
| Параллельное выполнение | ✅ Параллельные пакетные задания для разделенных данных (5 региональных пакетов сводки, выполняемых одновременно), Подписчики события платформы, обрабатывающие потоки одновременно |
| Мониторинг глубины очереди | ✅ Для асинхронных интеграций тенденции глубины очереди обозначают отставание обработки от производственного уровня, требующее увеличения нагрузки или оптимизации производительности |
| Обнаружение аномалий объема | ✅ Объемы транзакций, значительно превышающие/ниже ожидаемых схем, могут свидетельствовать о сбежавших процессах, требующих исследования и блокировки |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Пакетная обработка | ⚠️ Обработка всех записей последовательно, когда объем данных требует разделенного параллельного выполнения (разделение на основе даты, типа записи или ответственного включает параллельную обработку) |
| Расход API | ⚠️ Схема интеграции добавляет 25% потребления API без планирования нагрузки (внезапные ошибки «Превышено ограничение API» влияют на пользователей) |
| Мониторинг очереди | ⚠️ Отсутствие мониторинга глубины очереди асинхронной интеграции (обработка отстает от уровня производства без доступности) |
| Управление ограничениями губернатора | ⚠️ Синхронные операции обработки больших объемов, достигающие размера кучи или временных ограничений процессора (должны перейти к асинхронной обработке с выделенными ограничениями) |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Иерархия критичности функций | ✅ Определенные уровни: «Критические» (доход/соответствие, не ухудшается), «Важные» (базовые бизнес-правила, ухудшаются только во время крупных инцидентов), «Вспомогательные» (расширенный опыт, отключение во время сбоя интеграции), «Дополнительные» (приятные, отключение во время высокой нагрузки) |
| Внедрение автоматического выключателя | ✅ Состояния цепи (закрыто = нормально, открыто = не удается сразу после порога, полуоткрыто = зонд восстановления); Кэш платформы сохраняет состояние, изменения широковещания событий платформы; открывается после последовательных сбоев (например, 10 сбоев) |
| Логика повтора | ✅ Экспоненциальное резервное копирование для переходных сбоев (1s, 2s, 4s, 8s, cap при 30-60s); повторите время ожидания сети и ошибки 5xx с резервным копированием, повторите 429 ограничений по доле после заголовка Retry-After; никогда не повторите ошибки 4xx клиента или ограничения управляющего в одной транзакции |
| Резервные стратегии | ✅ Альтернативные источники данных (Кэш платформы, когда API в реальном времени недоступен), стандартное поведение (стандартные правила, когда служба персонализации отключена), ручной процесс (интерфейс администратора для застрявших транзакций), очередь для повторной попытки (События платформы с повтором 72h) |
| Архитектура обработки ошибок | ✅ Быстрый сбой (проверка вводных данных при входе), грациозный сбой (обработка 197 из 200 записей при 3 сбоях проверки), информативный сбой (регистрация с кодом транзакции, контекстом пользователя, трассировкой стека), безопасный сбой (откат частичных транзакций, никогда не открывайте внутренние пользователям) |
| Автоматизация восстановления | ✅ Мониторинг платформы запускает автоматическое восстановление: асинхронные механизмы повторных попыток, очереди мертвых букв для неудачной обработки, бизнес-правила самовосстановления, обеспечивающие быстрое восстановление без ручного вмешательства |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Зависимость интеграции | ⚠️ Отправка заказа не выполняется полностью при сбое службы проверки внешнего адреса (критический поток заблокирован поддерживающей функцией; должен грациозно ухудшиться при проверке вручную) |
| Стратегия автоматического выключателя | ⚠️ Отсутствие автоматического выключателя при внешней выноске, приводящее к ожиданию каждой транзакции 120 секунд до истечения времени ожидания при выходе из строя внешней системы (все пользователи, на которых повлияла одна сбой интеграции) |
| Логика повтора | ⚠️ Превышено ограничение повторной попытки процессора Apex немедленно в том же контексте транзакции (снова не удастся; при необходимости повторной постановки в очередь в качестве асинхронной операции с выделенными ограничениями) |
| Логика повтора | ⚠️ Повторять попытки неопределенно долго до успеха (риск бесконечного цикла, транзакция не завершена; следует ограничить максимальное количество попыток повтора) |
| Обработка ошибок | ⚠️ Исключение пробного ловчего блока без регистрации (сбой, невидимый операторам, предотвращающим диагностику и исправление) |
| Обработка ошибок | ⚠️ Отображение трассировки стека конечному пользователю на странице Lightning (риск безопасности, раскрывающий сведения о внедрении, плохое взаимодействие пользователя) |
| Резервная стратегия | ⚠️ Служба расчета налога не блокирует все отправки заказа (критическая возможность без резерва; должна стоять в очереди для обработки вручную или использовать стандартные курсы) |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Моделирование состояния здоровья | ✅ Совокупное состояние здоровья: Работоспособность службы (уровень успеха транзакции >99,5% зеленый, 98-99,5% желтый, <98% красный), Работоспособность интеграции (все отвечают зеленый, пониженный желтый, выключатель разомкнутый красный), Работоспособность данных (синхронизация текущий зеленый, за желтый, старый/сбой красный), Работоспособность нагрузки (<70% зеленый, 70-85% желтый, >85% красный) |
| Отслеживание событий | ✅ Объекты EventLogFile с доставкой 24 ч/1ч перенаправляются во внешний SIEM для сохранности за пределами собственных ограничений сохранности; собирает вызовы API, просмотры страниц, экспорты отчетов, действия входа, выполнение Apex |
| Предупреждения об Proactive Monitoring | ✅ Постоянные поверхности оценки Скачки ограничения запросов API (исследование запуска порога 75%), параллельные ошибки выполнения Apex, проблемы ограничения строк SOQL, тенденции потребления хранилища |
| Панель мониторинга состояния интеграции | ✅ Показатели на интеграцию: уровень ошибок (<1% целевой), задержка р50/р95/р99 с ООД, уровень ожидания (<0,1% целевой), состояние автоматического выключателя, глубина очереди асинхронизации; структурированные журналы с кодом запроса, конечной точкой, кодом ответа, продолжительностью |
| Создание действенного предупреждения | ✅ Каждое предупреждение определяет, кто отвечает, что проверяет, как исправить; содержит превышенный порог, текущее значение, недавние тенденции, ссылку на панель мониторинга, ссылку на рунет; серьезность соотносится с срочностью (КРИТИЧЕСКИЕ страницы по вызову для влияния пользователя, электронные ПРЕДУПРЕЖДЕНИЯ для проблем с трендингом) |
| Обнаружение аномалий | ✅ Аномалии объема (300% от типичной нагрузки), аномалии уровня ошибок (2% против 0,5% типичной, даже если ниже 5% порога), дрейф задержки (постепенная повышательная тенденция), аномалии поведения (необычные схемы входа, пакетные задания вне расписания); используется для руководства расследованием не инициировать немедленное расширение |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Отслеживание событий | ⚠️ Мониторинг событий включен, но не экспортирован (собственная сохранность недостаточна для анализа трендов, архивные данные утеряны) |
| Дизайн предупреждения | ⚠️ Сообщение-предупреждение “Произошла ошибка” без контекста, порога или действия ответа (создает усталость предупреждения, операторы не могут эффективно распределить) |
| Серьезность предупреждения | ⚠️ Считайте все аномалии критическими предупреждениями (высокий уровень ложно положительных создает усталость предупреждений, приводящую к пропуску критических предупреждений) |
| Мониторинг состояния здоровья | ⚠️ Отсутствие агрегированной модели состояния, операторы перегружены отдельными техническими показателями, в которых отсутствуют межсистемные схемы |
| Мониторинг интеграции | ⚠️ Отсутствие отслеживания состояния ошибок интеграции, задержки или выключателя (сбои интеграции, обнаруженные реактивно в отчетах пользователей) |
| Мониторинг нагрузки | ⚠️ Обзор No Proactive Monitoring или Scale Center (риски надежности от ресурсоемких транзакций остаются незамеченными до воздействия на производство) |
Встроенные примеры и подробные рекомендации см. в столбе «Надежность» или в проводнике по схемам и антипаттернам.