Прочитайте о расписаниях обновления здесь.

Устойчивые решения поддерживают высокое качество обслуживания даже при возникновении сбоев. Если производительность ухудшается или обслуживание прерывается, решение быстро и эффективно восстанавливается.

Устойчивость решения основана на двух ключевых качествах:

• Жесткость: Когда возникают проблемы, решение их выдерживает и переносит.
• Упругость: После решения проблем решение возвращается в идеальное состояние или форму.

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

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

Чтобы повысить устойчивость решений Salesforce, рекомендуем сосредоточиться на трех ключевых привычках.

• Управление жизненным циклом приложения (ALM) — способ управления программным обеспечением на протяжении жизненного цикла, от идеи до вывода из эксплуатации
• Реакция на инциденты: способы выявления, устранения и предотвращения проблем, влияющих на доступность или безопасность системы
• Планирование непрерывности - Как рабочие группы планируют дальнейшее функционирование своих сотрудников и систем, когда незапланированные события создают проблемы

Управление жизненным циклом приложения (ALM) — это практика комплексного управления программным обеспечением на протяжении всего его жизненного цикла, от создания до вывода из эксплуатации. ALM является краеугольным камнем устойчивости системы и охватывает людей, процессы, инструменты и дисциплины, связанные с жизненным циклом приложения. Эти дисциплины включают DevOps и методологии доставки, наблюдаемость, стратегии тестирования, управление и CI/CD.

Когда предприятие практикует эффективное ALM, его рабочие группы быстро реагируют на изменения, а его приложения соответствуют меняющимся бизнес-требованиям без ущерба для стабильности или качества.

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

Симптомы плохого ALM включают:

• Медленные и подверженные ошибкам циклы разработки
• Интенсивные и сложные развертывания
• Серьезные проблемы или ошибки, обнаруженные в производственной и пост-ОК среде
• Агенты на основе искусственного интеллекта, которые галлюцинируют или ведут себя непоследовательно
• Частые откаты или развертывания «горячего исправления», необходимые для стабилизации выпусков

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

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

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

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

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

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

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

Для создания эффективного управления выпусками для Salesforce:

• Жесткое согласование с архитектурным управлением и управлением развитием. Убедитесь, что выпуски запланированы заблаговременно, чтобы соответствовать всем соответствующим форумам управления и элементам управления. Прежде чем начать разработку, просмотрите и утвердите все приоритетные сценарии использования Agentforce в Совете на основе искусственного интеллекта. Получите высокорискованные сценарии использования Agentforce, проверенные группами по правовому и этическому использованию.Используйте контрольные списки развертывания и документацию для отслеживания артефактов развертывания, например, Agentforce API-имена агентов, относительно действий управления.
• Не используйте процессы разработки или выпуска на основе организации. Эта парадигма отражает более старые, более ограниченные технологии разработки и выпуска. С помощью Salesforce CLI рабочие группы теперь могут внедрять возможности разработки и выпуска под управлением источников.
• Выберите наиболее стабильный механизм выпуска. Этот подход позволяет достичь двух целей. Во-первых, это минимизирует продолжительность окон выпуска и прерываний обслуживания. Во-вторых, это позволяет высокоуправляемый и предсказуемый алгоритм выпуска. Чем стабильнее механизм выпуска, тем меньше вероятность внедрения изменений, требующих исправления или отката. В случае возникновения непредвиденной проблемы стабильные механизмы выпуска также создают более простые способы выполнения откатов для сотрудников службы поддержки или системных администраторов.

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

• Разблокированные пакеты: разблокированные пакеты являются наиболее стабильным артефактом выпуска. Развертывание изменений посредством установки пакета является самым быстрым и предсказуемым способом внедрения изменений. Пакеты используют версию, которая позволяет надежно управлять изменениями и точно детализировать системные откаты. А пакеты требуют сильного управления метаданными, что может помочь вам определить неуправляемые зависимости на раннем этапе. Они также создают проверяемые ожидаемые продажи разработки и артефакты. См. «Пакетируемость».
• DevOps Center — DevOps Center позволяет группам доставки с наборами навыков с низким кодом или прокодом использовать контроль источников, совместно работать над изменениями и определять общие пути выпуска. DevOps Center интегрируется с управлением источниками и позволяет оперативно управлять изменениями и развертываниями.
• Развертывание разработки и метаданных на основе источников посредством Salesforce CLI: если вы не можете использовать пакеты, используйте Salesforce CLI для разработки и развертывания метаданных на основе источников. Не развертывайте метаданные в более старом формате package. xml, структура которого отличается от рекомендованного исходного формата. Исходный формат был разработан для поддержки разработки пакетов, бизнес-правил стартовой организации и более детального отслеживания изменений в безопасных средах. Формат более читаемый, позволяет больше отделять типы сложных метаданных и зависимости и предоставляет гораздо больше контроля над проявлениями развертывания.
• Назовите выпуски. Предоставьте выпускам четкие идентификаторы, чтобы помочь вашим рабочим группам и заинтересованным лицам поддерживать связь. В Salesforce название каждого основного выпуска начинается на «Весна», «Лето» или «Зима», за которыми следует год выпуска (например, «Лето ’25»). Если у вас еще нет правила наименования для определения и систематизации выпусков в вашей компании, создайте его и используйте. Использование четких имен выпусков упрощает организацию на каждом этапе планирования, разработки и доставки в системах рабочих групп. Используйте имена выпусков в дорожной карте, чтобы четко сообщить заинтересованным лицам, какие изменения будут внесены и когда. Используйте имена выпусков в документации, журналах изменений, описаниях работы, комментариях к коду и ответвлениях контроля источников, чтобы легко отслеживать и проверять артефакты разработки.
• В декларации выпуска управляйте зависимостями хорошо. Метаданные Salesforce содержат встроенные зависимости. Распространенная причина неудачного развертывания Salesforce заключается в неправильном управлении зависимостями. Выбор стабильного механизма выпуска, как описано выше, может помочь выявить неуправляемые зависимости на ранних этапах цикла разработки. Одной из основных причин того, что разблокированные пакеты являются наиболее стабильным средством выпуска, является их эффективное управление метаданными, необходимое для разработки и создания пакетов. Если вы или ваши рабочие группы по управлению выпусками не понимаете встроенных зависимостей между типами метаданных Salesforce, вы не сможете заранее обнаружить проблемные сочетания в описаниях развертывания и выпуска. См. Управление зависимостью.

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

Дополнительные сведения об инструментах Salesforce для управления выпусками см. в разделе «Инструменты Salesforce для устойчивости».

Salesforce предоставляет разные среды для использования во время циклов разработки и тестирования приложений. Эффективная стратегия среды для Salesforce требует понимания того, как использовать среды и как выглядит эффективное управление. В ALM, насколько полезна среда разработки или тестирования, зависит от ее лояльности и изолированности от производства.

Хорошая экологическая стратегия предоставляет несколько преимуществ.

• Большая верность производству
• Более быстрые настройки и сносы среды
• Более гибкая разработка и тестирование
• Повышение безопасности в ожидаемых продажах
• Меньше шума и конфликтов на этапах доставки
• Более счастливые группы разработчиков

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

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

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

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

Для разработки эффективной экологической стратегии:

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

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

Кроме того, обратите внимание, что для агентов Agentforce, использующих такие функции, как библиотека данных Einstein, статьи Knowledge и неструктурированные данные, комплексное тестирование ограничено, если у вас нет безопасной среды Data 360. Безопасная среда Data 360 также необходима для обеспечения точных условий тестирования.

• Разделение сред от артефактов выпуска. Не используйте разработку на основе организации. Рассматривайте среды как места, где работа выполняется в течение фиксированного периода времени. Считайте состояние метаданных в среде отдельным от артефактов выпуска. Если часть кода или конфигурации «выясняется» в среде, она должна быть связана с контролем источников, что делает ее артефактом выпуска.

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

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

  • Этапы выпуска применяются к артефактам выпуска, а не к средам. Не создавайте среду только с целью «сбора» всех изменений на определенном этапе выпуска. Для этого и нужен контроль источников, особенно ответвления. Используйте стратегии ответвления в контроле источников для систематизации изменений, которые нужно развернуть в каких средах. В зависимости от выполняемой работы, возможно, потребуется развернуть все метаданные в выпуске в среде. Ветвление позволяет это делать. За некоторыми исключениями, каждая среда разработки должна обновляться или уничтожаться сразу после завершения соответствующей работы. Убедитесь, что вы синхронизируете изменения в метаданных, происходящие в определенной среде, которую хотите сохранить, с управлением источниками.
  • Среды полезны только так, как их верность производству. Оптимизируйте бизнес-правила или автоматизацию настройки среды, чтобы снести или обновить среды как можно быстрее. Рассмотрите любую конфигурацию, которая блокирует выполнение более быстрых и частых обновлений среды как критический риск для общей устойчивости процессов ALM. Если у вас есть связанная работа по исправлению, добавьте ее в планы и расставьте приоритеты. Изучите способы внедрения более слабо связанных модульных единиц в систему. Они позволяют рабочим группам выполнять больше типов разработки в стартовых организациях и освобождают распределения безопасной среды для другой работы. Не забудьте о возможностях, предоставляемых стартовыми организациями для тестирования функций, отсутствующих в производстве, либо потому, что вы не приобрели лицензии на них, либо потому, что они не включены.
  • В средах, доступных бизнес-пользователям или конечным пользователям, позвольте этим пользователям сосредоточиться на том, что им важно. Не создавайте общие недифференцированные среды, в которых многие группы конечных пользователей или бизнес-заинтересованных лиц пытаются выполнять работу, связанную с ALM. Пригласите и активируйте определенных заинтересованных лиц в определенные среды для выполнения определенной работы. Внимательно изучите любой процесс, который ставит конечных пользователей или бизнес-заинтересованных лиц в среду с большим количеством данных, чем может поддерживать безопасная среда Partial Copy. Убедитесь, что объем данных необходим для выполнения работы. Спланируйте циклы приемочного тестирования пользователей и разработки на ранних этапах, чтобы они происходили как можно ближе друг к другу. Оптимизируйте все этапы тестирования, чтобы включить более быстрые, ранние циклы обратной связи и итерации для групп разработчиков и конечных пользователей. См. стратегию тестирования.

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

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

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

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

Дополнительные сведения об инструментах Salesforce для управления средой см. в разделе «Инструменты Salesforce для устойчивости».

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

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

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

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

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

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

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

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

Чтобы узнать больше об инструментах Salesforce для стратегии сигнализации, см. «Инструменты Salesforce для надежности».

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

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

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

Для создания эффективных стратегий тестирования для Salesforce:

• Проверять как можно чаще, регулярно и с помощью автоматизированных средств. Разработайте и внедрите автоматизацию тестирования, позволяющую рабочим группам выполнять разные типы тестов с учетом разных загруженностей. Оркестрируйте разные тестовые запуски для автоматического выполнения, когда изменения попадают под контроль источников. Этот метод позволяет группам заранее определять и устранять регрессии. Рекомендуем использовать функцию непрерывной интеграции/непрерывной доставки (CI/CD) для данной цели. В противном случае, создайте четкие планы тестирования, позволяющие группам выполнять последовательности тестов на раннем этапе и часто, на основе самообслуживания. При тестировании агентов Agentforce рекомендуем использовать центр тестирования для тщательного пакетного тестирования агентов искусственного интеллекта с различными вводными данными, чтобы обеспечить их корректную работу в разных сценариях.
• Признайте, что не каждое изменение требует каждого типа тестирования. Подобно тому, как эффективные ожидаемые продажи размещают пути для приложений с высоким, средним и низким риском, эффективная стратегия тестирования тоже. Четко определите для рабочих групп, как выбрать и выполнить соответствующий режим тестирования для приложений с разными типами риска, сценариями использования или сложностью. См. Стратегия окружающей среды.
• Определите, какие тесты можно проводить в разных типах среды. Верность производству является ключевым компонентом точного тестирования, но это означает разные вещи для разных типов тестов. Например, регрессионное тестирование требует верности производственной среде с точки зрения метаданных и в некоторой степени данных. Обязательно определите, какая верность производственной среде требуется для данного набора тестов, и четко классифицируйте, какие типы сред могут поддерживать условия, соответствующие разным тестам. Общие сведения о типах работы, соответствующих каждому типу среды, см. в разделе «Стратегия окружающей среды».
• Используйте тесты выносливости, стресса, производительности и шкалы для непрерывной оценки зрелости приложения. Эти тесты показывают, насколько приложение готово к выпуску по сравнению с потребностями производственного уровня. Для основных новых функций выполните эти тесты через несколько интервалов в цикле разработки приложения. Это антипаттерн рассматривать эти тесты как часть только одного этапа или этапа разработки, а не как часть текущих задач. Для рабочих групп наиболее полезно получать отзывы о производительности приложения на раннем этапе и часто, что помогает им лучше понять, насколько близко или далеко приложение от производственной готовности. Возможность более точного определения и решения проблем до запуска изменений в производственную среду вполне заслуживает дополнительной сложности, заключающейся в частом проведении более сложных тестов.
  • Знайте, какие тесты важны. Возможно, у вас будет определенное время для тестирования масштаба или производительности, что сделает непрактичным тестирование каждой грани системы. Не все функции используются одинаково, и не все подводные камни масштаба будут одинаково влиять на бизнес. Убедитесь, что тесты шкалы сосредоточены на наиболее часто используемых и ценных частях системы. Определите и поймите самые важные возможности для проверки и повышения масштаба и производительности в вашей организации.
  • Знайте, как выглядит слово «достаточно хорошо». Определение критериев успешности для тестирования шкалы и производительности имеет решающее значение. Убедитесь, что вы и ваши группы разработчиков используете критерии успеха в качестве критериев тестирования. Также убедитесь, что они содержат функциональные требования, к которым создаются группы разработчиков. Как правило, эти критерии включают поддержку определенного количества параллельных пользователей с временем ответа меньше согласованного значения и целей уровня обслуживания (SLO). Определите ключевые целевые критерии, а потом создайте масштабные тесты и тесты производительности, обеспечивающие соответствие критериям.
  • Убедитесь в наличии надлежащих условий. Масштабирование и тестирование производительности требуют особой верности производству. Ваши наборы данных, демографические данные запросов, уровни запросов и характеристики загруженности в непроизводственных средах должны максимально соответствовать тому, что вы видите в производстве. Для масштабного тестирования необходимо использовать Full Sandbox. Если в вашей организации нет Full Sandbox для тестирования шкалы, вы не сможете выполнить адекватные тесты шкалы.
• Убедитесь, что тестовые нагрузки помогают измерять нефункциональные требования. Не забудьте учесть следующее:
  • Данные тестирования - Каждый вид тестирования должен проводиться на основе данных, изолированных от производственной среды. Внедрите схемы фабрики данных в единичные тесты Apex, чтобы код генерировал собственные тестовые данные, изолированные от данных среды. Можно также создавать и обслуживать тестовые наборы данных в разных форматах для тестирования алгоритмов загрузки данных, заполнения сред разработки данными для тестов на основе пользовательского интерфейса и помощи в тестировании интеграции. Все тестовые данные, независимо от того, хранятся ли они в качестве внешнего набора данных или создаются по запросу кодом фабрики данных, должны быть удалены из конфиденциальных и идентифицирующих данных. Он должен содержать поврежденные, неполные и неправильные данные для поддержки отрицательных и граничных алгоритмов тестирования единиц.
  • Службы имитации и заглушки. Для тестирования интеграции можно использовать службы имитации и заглушки для имитации ответов API. Apex поддерживает Stub API для создания фреймворков издевательств для использования в тестах Apex. Издевка для создания фреймворков для издевательств, которые можно использовать в тестах Apex. Макеты и заглушки могут помочь проверить алгоритмы обработки данных системы, меньше полагаясь на сложные фабрики данных или наборы данных внешних тестов. Макеты и заглушки иногда лучше использовать в тестах, где трафик производственного назначения или объемы данных не актуальны.
  • Устройства и вспомогательные технологии - Ключевым элементом создания привлекательных и доступных приложений является обеспечение их соответствия ожиданиям пользователей на различных устройствах и с использованием различных видов вспомогательных технологий. Эффективное тестирование на удобство использования может потребовать дополнительных инвестиций и опыта разного рода, но это важная часть понимания того, насколько хорошо будут созданы приложения, ориентированные на пользователя, после их выпуска.
  • Симуляторы: если вам нужно реплицировать объемы запросов пользователей, трафик API или изменения скорости сети, вам могут понадобиться инструменты, имитирующие данные условия. Не каждому тесту нужен такой уровень инвестиций. Эти инструменты часто наиболее полезны в тестировании масштабируемости и производительности.
  • Тестирование на основе искусственного интеллекта и агентов - Основная цель тестирования - уменьшение галлюцинаций на основе искусственного интеллекта, которые являются убедительными ответами, сфабрикованными и некорректными . Убедитесь, что сценарии использования искусственного интеллекта тестируются для выявления распространенных проблем, вызванных неполным пониманием клиента, отсутствующими данными, полями с неполными метаданными и устаревшими данными. Используйте центр тестирования для помощи в создании необходимых тестовых данных для таких тестов.

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

✨ Узнайте больше о схемах для ALM в проводнике по схемам и антисхемам.

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

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

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

При возникновении инцидента первоочередной задачей должно быть восстановление стабильного рабочего состояния систем. Часто компании думают, что единственный способ восстановиться после инцидента – «устранить проблему». Это предположение справедливо в том смысле, что точный анализ и устранение коренных причин - это способ окончательного решения критических проблем в системе. Однако, «устранение проблемы» на ранних этапах антикризисных мер — не самый практичный подход. В зависимости от серьезности инцидента, каждая секунда инцидента и его влияние могут привести к потере дохода или репутации предприятия.

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

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

Для внедрения менталитета «Восстановление - в первую очередь» для реагирования на инцидент:

• Установка и достижение ООД целей обслуживания. SLO - это стандарты, разрабатываемые совместно с заинтересованными лицами для определенных нефункциональных требований (NFR) системы, например, производительность или время работы. Эти цели оцениваются индикаторами уровня обслуживания (SLI) за определенный период времени. Без SLO большая часть работы по реагированию на инциденты и устранению сложных проблем может показаться неорганизованной и реактивной, например, побуждая к быстрым действиям, чтобы «остановить эту конкретную ошибку для этой группы пользователей, сообщивших о ней». Этот цикл часто приводит к тому, что рабочие группы продвигают анализ коренных причин ближе к реакции на инцидент, поскольку кажется, что это поможет остановить реактивные алгоритмы. Создание ООД и ООД является более эффективным способом начать. Чтобы установить ООД, обдумайте данные вопросы.
  • Какой NFR вашей системы на ближайшие 1-3 года? Например, NFR может содержать время ответа, пиковые уровни запросов и параллельных пользователей, которых должна поддерживать ваша система.
  • Что должно произойти с клиентами и их пользователями? Основывайте свои SLO на ответе на этот вопрос: «Пользователи могут быстро запускать отчеты в Salesforce».
  • Что можно измерить и за какой период времени это следует измерить? Основывайте SLI на ответе на этот вопрос. SLI, соответствующий предыдущему примеру, может составлять «x% загружаемых отчетов в среднем в течение не секунд, измеряемых в течение 30 дней».
• Определите и стандартизируйте тактику восстановления. Откаты изменений и временные решения могут помочь восстановить функциональность системы и минимизировать влияние инцидента. Тактики и протоколы восстановления документов, которые могут быть выполнены соответствующими участниками группы поддержки или операционной группы. Тактика восстановления зависит от типа инцидента. Следующая таблица отображает общую инфраструктуру, соотносящую типы инцидентов с тактикой восстановления. Дополнительные сведения об определении точек сбоя и стратегий смягчения см. в разделе «Доступность».

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

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

Дополнительные сведения об инструментах Salesforce, помогающих восстановить время, см. в разделе «Инструменты Salesforce для устойчивости».

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

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

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

Чтобы рабочие группы могли эффективно сортировать проблемы в решениях Salesforce:

• Убедитесь, что группы поддержки имеют доступ к полезной информации.
  • Задокументируйте систему и схемы проектирования. Обеспечение удобочитаемости и последовательности решений является ключевым элементом предоставления сотрудникам службы поддержки возможности понять систему, за поддержку которой они отвечают. В документации подумайте, как рабочие группы найдут сведения о том, как расставить приоритеты проблем или инцидентов с разными частями системы. Также, обеспечьте, чтобы рабочие группы могли быстро получить технические сведения о тактике восстановления на основе области влияния. Предоставьте актуальные руководства по устранению неполадок для распространенных проблем Agentforce, например, Классификация тем и Выбор действий, которые могут помочь группам быстро распределить проблемы, связанные с полномочиями или конфигурацией.
  • Разработайте с учетом отладки. Группы поддержки и администраторы организации должны будут включить отладку и диагностику для корректного распределения проблем пользователей в разных средах. Примеры удобных для отладки схем включают схемы, внедряющие регистрацию и настраиваемые сообщения об ошибках в пути выполнения в системе. Включите группы поддержки по распространенным подходам отладки Agentforce посредством таких инструментов, как журналы событий и представление рассуждений конструктора Agentforce.
  • Определение МСП и заинтересованных сторон. Создание списка соответствующих МСП или заинтересованных сторон, которые должны оказывать поддержку в восстановлении после инцидента и которые должны участвовать в анализе после инцидента.
  • Относитесь к передачам вдумчиво. Убедитесь в качестве каждой передачи решения группам поддержки или операционным группам в процессе внедрения. Предоставьте обучение для вспомогательного персонала по соответствующей архитектуре системы и инсценировке учений по реагированию на инциденты. Подумайте о передачах после инцидента, включительно с тем, как рабочие группы должны документировать сведения, не собранные журналами или примечаниями к обращениям, а также как специалисты по реагированию на инциденты могут способствовать расследованию коренных причин или выполнить тестирование приемки пользователей для любых исправлений.
• Если вас консультируют, держите всех в центре внимания на восстановлении.
  • Быстро отвечайте. Быстро реагируйте на все полученные запросы службы поддержки пользователей, уведомления о мониторинге и предупреждения.
  • Помогите отличить симптомы от проблем. Работайте над определением наличия фактического системного инцидента, который нужно устранить. Попробуйте определить компоненты с фактическими проблемами. Помогите обеспечить соблюдение согласованных тактик восстановления для быстрого выхода системы из статуса инцидента.
• Для агентов Agentforce, поддерживающих критические сценарии использования, обеспечьте наличие жизнеспособных и актуальных обходных путей, которые можно включить с коротким уведомлением в качестве меры избыточности. Например, переключение на ручную обработку или переадресация на соответствующую документацию для проверки вручную.

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

Чтобы узнать больше об инструментах Salesforce, помогающих сортировать данные, см. «Инструменты Salesforce для устойчивости».

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

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

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

Архитектор для эффективного мониторинга и оповещения в решениях Salesforce:

• Сделайте автоматизацию приоритетом. Хотя уведомление пользователей об изменениях критических состояний является важной частью поддержания стабильности и работоспособности систем, в идеальной архитектуре система самостоятельно исправляет проблемы, когда это возможно, и отправляет предупреждения только о срочных, не поддающихся восстановлению проблемах. Даже без возможностей самостоятельной коррекции автоматизация может сделать ваши предупреждения и отчеты более полезными.
  • Начните с того, что уже предоставляет Salesforce. Salesforce Platform предоставляет актуальные журналы и API для мониторинга операций решения с учетом контролирующих ограничений. Кроме того, платформа отправляет предупреждения о нарушениях губернаторского лимита и подобных проблемах. Используйте эти журналы и предупреждения в качестве основы для изучения способов более полной автоматизации самостоятельного восстановления системы, составления отчетов по инцидентам и предупреждений. Например, можно внедрить автоматизацию, отслеживающую журнал, а потом предпринять действие восстановления при регистрации определенного типа события.
  • Классифицировать изменения в состоянии системы предсказуемым способом. Создайте определенные значимые категории для ключевых состояний, по которым нужно отслеживать и составлять отчеты. Соотнесите эти категории с категориями, заданными для управления состоянием в компонентах приложения. Примите ориентированный на API подход к обработке сведений об изменении состояния. Согласованные форматы сообщений и категории областей упрощают автоматизацию, составление отчетов и оповещение.
  • Согласуйте логику автоматизации с другими компонентами системы. Если вы создали правильную обработку ошибок автоматизации, вы можете расширить эти схемы до классификации изменений состояния и ответа автоматизацией. Для изменений состояния, которые считаются восстанавливаемыми, можно автоматизировать алгоритмы повторных попыток. Для изменений состояния, которые считаются критическими или смертельными, автоматизируйте предупреждения пользователей.
• Избегайте создания шума. Когда пользователи получают слишком много предупреждений, особенно предупреждений, не требующих принятия каких-либо мер, они обычно начинают отключать или игнорировать все предупреждения. Этот сценарий подрывает любые усилия по созданию полезных предупреждений. Чтобы лучше определить, кто получает предупреждения, что их запускает и когда они запускаются, рекомендуем выполнить данные действия.
  • Создание карт заинтересованных лиц. Чтобы обеспечить своевременную доставку системой нужных предупреждений соответствующим заинтересованным лицам, сперва определите и классифицируйте группы заинтересованных лиц.
  • Маршрутизация сообщений на основе полномочий пользователя. Отправляйте предупреждения только получателям, имеющим возможность и полномочия для ответа. Бизнес-пользователям могут быть полезны предупреждения о проблемах, которые они могут исправить, исправив проблемы в записях, к которым у них есть доступ. Если проблема требует более активного технического ответа, предупреждения должны направляться вспомогательному персоналу.
  • Определите ожидаемый ответ. Отправляйте предупреждения только в сценариях, требующих человеческого вмешательства. Структурируйте сообщения, чтобы четко обозначать действие, ожидаемое от получателя. Если вы отправляете предупреждение заинтересованному лицу для доступности, и от него не требуется никаких действий, уточните это в версии сообщения, которое оно получает.
  • Сделайте предупреждения своевременными и актуальными. Предупреждения, доставляемые в ответ на возникшие сбои и требующие исправления) не столь полезны, как предупреждения о потенциальном сбое. В идеале, вспомогательный персонал получает предупреждение, как только в системе возникают проблемные условия, что дает возможность определить проблемы до того, как они могут оказать негативное воздействие на хозяйственные операции.

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

Дополнительные сведения об инструментах Salesforce для мониторинга и оповещения см. в разделе «Инструменты Salesforce для надежности».

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

✨ Узнайте больше о схемах реагирования на инциденты в проводнике по схемам и антисхемам.

Ключом к устойчивости бизнеса является планирование непрерывности, которое фокусируется на том, как предоставить людям и системам возможность работать в проблемах, вызванных незапланированным событием. Планы обеспечения непрерывности бизнеса (ПБП) используют ориентированное на людей представление о том, как поддерживать процессы в кризисном состоянии. Технические аспекты планирования обеспечения непрерывности содержатся в разделах БКП, посвященных послеаварийному восстановлению. См. «Технологическая преемственность».

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

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

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

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

Для создания соответствующего планирования непрерывности бизнеса для систем Salesforce:

• Определение приоритетов восстановления. Как и в случае с общим подходом к реагированию на инциденты, восстановление должно быть первоочередной задачей для систем в кризисные моменты. Многие важные для бизнеса службы выполняются в Salesforce и вместе с ним. Необходимо помочь заинтересованным лицам определить правильный приоритет для восстановления различных бизнес-функций и возможностей. Общие рамки могут быть следующими:
  • Стабилизировать важную бизнес-инфраструктуру.
  • Стабилизировать обслуживание клиентов.
  • Стабилизировать обслуживание сотрудников и партнеров.
• Учитывайте экосистему в БКП. Salesforce - не единственная система в вашем ландшафте. Убедитесь, что вы определили пробелы в BCP вокруг систем, интегрируемых с Salesforce, решений, установленных от поставщиков AppExchange и любых других систем, подключаемых к данным или процессам в Salesforce. Если возможность доставки зависит от поставщиков, обратитесь к этим поставщикам за информацией о планах обеспечения непрерывности. Оцените их возможности и спланируйте, как обеспечить доступность систем.
• Интегрируйте проблемы BCP в стратегию тестирования. Создайте планы тестирования для BCP и выполните их. Особенно важно тестировать области BCP, связанные с процессами или людьми, которые часто пропускаются. Включите актуальные элементы из BCP в общую стратегию тестирования ALM. Создайте и выполните расписание техобслуживания, чтобы проверить тесты и обеспечить актуальность плана.

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

Дополнительные сведения об инструментах Salesforce для определения непрерывности бизнеса см. в разделе «Инструменты Salesforce для надежности».

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

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

Для обеспечения лучшей технологической непрерывности в системах Salesforce:

• Оцените инфраструктуру. Наиболее распространенной стратегией исправления технологических сбоев или проблем является создание избыточных служб или систем, к которым можно вернуться во время инцидента. В Salesforce у нас намеренно избыточная архитектура, то есть мы сохраняем копии систем и служб наших клиентов в разных физических расположениях. Мы используем несколько методов послеаварийного восстановления, включая переключение сайтов, что позволяет направлять трафик пользователей из одного центра обработки и хранения данных в другой при необходимости. Чтобы определить, где может понадобиться создать намеренное дублирование, задайте себе данные вопросы.
  • Что происходит во время прерывания обслуживания службы [X]? Можно переключиться с этой службы на другую?
  • Сколько времени нужно для восстановления [X]? Какое влияние на наших клиентов? Какое влияние оказывают на наших партнеров? Каким является влияние на внутренние рабочие группы?
  • А как же резервные копии и их частота? Могут ли резервные копии предоставить данные, необходимые для поддержки предприятия?
  • У нас есть зависимости от поставщиков? Какие у них планы БКП?
• Предоставить оперативную поддержку. Оперативная поддержка — это восстановление работоспособности рабочих групп как можно быстрее. Продумайте, как ваша система может справиться со значительным увеличением требований к пропускной способности и спроса от непредвиденных изменений, включительно с изменениями в отрасли, регионе или мире. Убедитесь, что BCP учитывает дополнительные ресурсы или процедуры стеклоподъемности, которые могут понадобиться инженеру надежности сайта (SRE) или группам поддержки для эффективного реагирования на инциденты. Вопросы по оперативной поддержке включают:
  • Будут ли у наших технических групп в наличии инструменты, необходимые для продолжения работы? Моделировали ли мы сбой для проверки планов или определения пробелов?
  • Если бедствие происходит в определенной области, есть ли у нас планы покрытия для этой области?
  • Наши клиенты глобальные? Они работают круглосуточно?
  • Есть ли у нас надлежащий контроль и оповещение для уведомления соответствующих лиц о сбоях?
• Автоматизируйте и протестируйте тактику восстановления. После устранения ошибки определите место и способ ее устранения. Если вы можете на основе исправления автоматизировать тактику восстановления и скорректировать все проблемы процесса. Многие компании планируют моделирование инцидентов для поднабора служб для тестирования устойчивости системы. Примером может быть имитация блокировки или взлома организации системного администратора или имитация сбоя или проблемы с поставщиком AppExchange. См. Ответ на инцидент.)Вопросы о том, как тестирование и автоматизация могут помочь вам быстрее восстановить службы, включают:
  • Как часто мы планируем и выполняем симуляции инцидентов?
  • Знаете ли мы, сколько времени нужно, чтобы восстановить обслуживание в стабильном состоянии?
  • У нас есть стабильные процессы доставки?
  • Знаете ли мы, где можно автоматизировать отказ и восстановление?

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

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

Чтобы узнать больше об инструментах Salesforce для планирования непрерывности технологии, см. «Инструменты Salesforce для надежности».

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

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

Чтобы обеспечить преемственность стратегий резервного копирования и восстановления в решениях Salesforce:

• Начните. Первым шагом к созданию хорошей стратегии резервного копирования и восстановления является наличие стратегии в первую очередь. Даже такое простое действие, как создание ночных резервных копий всех данных и метаданных организации, может спасти ваше предприятие от потери важной информации или функций во время сбоя.
• Ограничить доступ к резервным копиям. Системные администраторы — единственные пользователи, имеющие доступ к резервным копиям данных. Это ограничение доступа не позволяет бизнес-пользователю просматривать записи в резервной копии, которую он не сможет просматривать в вашей организации.
• Регулярно тестируйте процесс восстановления. Независимо от применяемой стратегии резервного копирования и восстановления, регулярно тестируйте процесс восстановления в безопасной среде Full или Partial Copy, чтобы убедиться в его корректной работе.
• Согласуйте стратегию резервной копии и восстановления со стратегией архивирования данных. Определите, что должно происходить в резервных копиях или архивах при архивировании или удалении записей из системы. См. Объем данных).

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

Чтобы сделать стратегию резервной копии более детализированной:

• Ограничьте резервные копии определенными объектами. Данная стратегия предусматривает создание резервных копий записей из разных объектов в разные промежутки времени. Помните, что дочерние объекты должны создаваться резервными копиями через те же промежутки времени, что и их родительские объекты, чтобы поддерживать согласованность данных.
• Частичные резервные копии временного интервала. Эта стратегия предусматривает проведение различия между полными резервными копиями (всех данных и метаданных) и частичными резервными копиями (только метаданных и записей, добавленных или измененных после последнего резервного копирования).

*Не прекращайте выполнение резервных копий. Важно иметь в виду, что не следует полностью удалять резервные копии, даже если объемы данных приводят к длительному выполнению. Для больших объемов данных рекомендуем регулярно, но редко создавать полные резервные копии (например, еженедельные). Также спланируйте более частые частичные или объектные резервные копии (например, ночные резервные копии или резервные копии каждые X часов). Этот метод предоставляет гибкость для восстановления наиболее полного и точного набора данных для использования в процессах восстановления*.

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

Salesforce Backup and Recover, интегрированное решение Salesforce, содержащее Own Recover from the Own, защищает важные данные от потери или повреждения. Наше высоконадежное, легко настраиваемое и всегда доступное решение обеспечивает непрерывность бизнеса и устойчивость данных, а также упрощает соответствие требованиям.

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

Автоматические ежедневные резервные копии защищают все важные данные организации, включая метаданные, безопасные среды, данные управляемого пакета, вложения файлов и прочее. Запускайте резервные копии так часто, как это необходимо для достижения целей точки восстановления (RPO) и обеспечения безопасности развертываний. Резервные копии всегда доступны и хранятся безопасно и в соответствии с требованиями. Постоянная защита данных также доступна для еще более конфиденциальных или транзакционных данных, что позволяет ускорить восстановление быстро меняющейся важной информации.

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

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

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

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

• Уменьшение влияния инцидентов с данными. Система Salesforce Backup and Recover помогает смягчить инциденты с данными, например, кибератаки или вредоносные внутренние или внешние действия, позволяя пользователям возвращать поврежденные записи в предынцидентное состояние. Функции экспорта «Резервная копия и восстановление» гарантируют постоянный доступ к важным данным пользователей и их удобство использования.
• Предотвращение необратимой потери данных. Человеческая ошибка остается основной причиной потери данных. Функция «Резервная копия и восстановление» предлагает точное и быстрое решение этих ошибок.
• Более легко соответствовать требованиям соответствия данных и законодательства. Система Salesforce Backup and Recover поддерживает модель общей ответственности, что позволяет использовать функцию самообслуживания для пакетного восстановления или исправления данных в резервных данных.

Дополнительные сведения об инструментах резервного копирования и восстановления Salesforce см. в разделе «Инструменты Salesforce для повышения надежности».

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

✨ Ознакомьтесь с дополнительными схемами планирования непрерывности в Проводнике по схемам и антипаттернам.

Помогите нам поддерживать актуальность Salesforce «Хорошо архитектура». Пройдите опрос, чтобы предоставить отзыв об этом содержимом и сообщить, что вы хотите видеть дальше.