Оптимизация ресурсов и затрат

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

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

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

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

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

Экономичные решения повышают ценность за счет:

Использование уже приобретенных возможностей платформы
Согласование лицензирования и потребления соответствующего размера с реальным использованием
Моделирование полной стоимости перед принятием обязательства по подходу
Постоянное отслеживание расходов по сравнению с бизнес-результатами

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

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

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

Оптимизировать по общей стоимости владения. Общая стоимость владения (TCO) выходит за пределы абонентской платы и охватывает кредиты потребления, затраты на внедрение, операционные расходы, расходы на интеграцию и усилия по управлению изменениями. Оцените решения с помощью анализа TCO, чтобы отобразить полную картину инвестиций на протяжении срока действия решения. Иногда более высокие первоначальные инвестиции существенно сокращают текущие операционные расходы, и анализ ТСО дает это преимущество. Оптимизируйте по долгосрочному значению, а не по краткосрочному минимизации затрат.
Согласование расходов с бизнес-ценностями. Подключите все инвестиции Salesforce к измеримому бизнес-результату. Расходы на лицензию позволяют измерять производительность пользователей посредством внедрения и выполнения задач. Инвестиции Data 360 влияют на принятие решений, оцениваемых посредством преобразования и ценности срока действия клиента. Безопасная среда обходится в скорость разработки средств, измеренную посредством частоты и качества развертывания. Когда расходы соответствуют стоимости, вы уверенно инвестируете в то, что движет успехом, и определяете расходы, которые больше не приносят прибыли.
Дизайн в пределах платформы. Ограничения для управляющих определяют, что решение может обрабатывать на транзакцию. С самого начала относитесь к ним как к ограничениям дизайна, а не как к препятствиям для обхода. Создавайте транзакции, которые комфортно работают в пределах максимальной загрузки и максимального объема данных, и создавайте запас для будущих функций, других установленных пакетов и непредвиденных схем данных. Решения, разработанные в пределах от замысла, имеют предсказуемую производительность и позволяют избежать экстренного повторного факторинга позже.
Оптимизируйте ресурсы, за которые вы уже платите. Прежде чем покупать дополнительные мощности, увеличьте производительность, эффективность и стоимость уже инициализированных активов платформы. Эффективные запросы, обработка записей в пакете (пакетная обработка), кэширование и жизненный цикл дисциплинированных данных уменьшают вычисления, хранение и потребление API, необходимые решению. Эта эффективность ресурса является механизмом устойчивой оптимизации затрат: отходов, исключенных из обеспеченных ресурсов, повышает как производительность, так и долгосрочную ТСО.
Лицензионные платежи правильного размера и потребление для фактического использования. Соотнесите каждого пользователя с типом лицензии, необходимым для его работы, и создайте автоматизацию и агентов для эффективного вызова дозированных услуг. Наиболее распространенными и дорогостоящими источниками отходов являются чрезмерное лицензирование и неконтролируемые кредиты на потребление. Регулярные проверки ролей, действий входа и возможностей ограничения использования функций, а также четкое отображение кредитных записей поддерживают предсказуемость расходов на основе потребления.
Формирование культуры финансового управления и учета затрат. Управление расходами Salesforce в качестве стратегических инвестиций посредством активного надзора и общей подотчетности. Финансовое управление позволяет учитывать анализ затрат и выгод при принятии проектных решений, а не определять затраты после развертывания. Осведомленность о затратах — это общая ответственность бизнес-заинтересованных лиц, архитекторов и разработчиков, которые оценивают последствия затрат наряду с функциональными требованиями, поэтому интеллектуальные инвестиционные решения принимаются на каждом уровне без централизованных преград.
Постоянная оптимизация. Оптимизация - это постоянная практика, а не одноразовое мероприятие. Отслеживайте расходы и потребление ресурсов посредством панелей мониторинга, доступных заинтересованным техническим и бизнес-лицам. Настройте предупреждения, запускаемые, когда расход расход достигает пороговых значений, прежде чем расход останется незамеченным. Регулярные проверки обнаруживают отходы, которые накапливаются постепенно, проверяют, что предыдущие инвестиции оптимизации принесли ожидаемую прибыль, и появляются новые возможности по мере развития бизнес-приоритетов и объемов данных.

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

Распределение ресурсов для нескольких клиентов: Salesforce обеспечивает справедливый общий доступ к процессору, памяти и подключению к базе данных для всех клиентов в общедоступной инфраструктуре, отслеживает потребление клиентов и применяет ограничения, предотвращающие ухудшение производительности для других клиентов одним клиентом.
Архитектура ограничения для управляющих: Применяемые платформой границы (100 запросов SOQL на синхронную транзакцию, 10 секунд процессорного времени, размер кучи 6 МБ) защищают всех клиентов от исчерпания ресурсов. Salesforce калибрует эти ограничения для многопользовательской инфраструктуры. Эти ограничения являются архитектурными границами, а не произвольными ограничениями.
Оптимизатор запросов и механизм выполнения: Оптимизатор запросов Salesforce создает планы выполнения, ведет статистику по распространению данных и выбирает оптимальные пути запросов. Управляемые платформой индексы в стандартных полях ускоряют распространенные схемы запросов, а оптимизатор автоматически адаптируется к изменениям объема данных.
Масштабирование инфраструктуры: Salesforce инициализирует аппаратную емкость, управляет кластерами базы данных, распределяет нагрузку и масштабирует инфраструктуру по мере роста использования. Вы никогда не инициализируете серверы, не управляете репликацией базы данных и не настраиваете балансировщики загрузки.
Оптимизация производительности платформы: Salesforce постоянно оптимизирует базовый код платформы, выполнение запросов, время ответа API и производительность инфраструктуры пользовательского интерфейса, а также предоставляет улучшения инфраструктуры посредством своих регулярных выпусков, не требуя действий клиента.

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

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

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

Ваши обязанности оптимизации охватывают четыре взаимосвязанные области: производительность, систематизация кода, пакетирование и данные. Каждое из них является решением по стоимости, а не техническим. Данный раздел объясняет, как принять это решение и почему оно важно. Точные рецепты внедрения, шаблоны уровня кода, навигация настройки и определенные пороги настройки, на которые ссылается данный раздел, находятся в библиотеке схем «Оптимизация ресурсов и затрат».

Оптимизация производительности начинается со изменения отношения к контролирующим ограничениям. Они не помехи для обхода. Это архитектурные ограничения, которые, принимаясь с самого начала проектирования, создают решения с предсказуемыми характеристиками производительности. Каждая транзакция выполняется в фиксированных границах, и эти границы существуют для внедрения справедливого общего доступа к ресурсам среди каждого клиента платформы. Транзакция Apex, потребляющая 95 из 100 разрешенных запросов SOQL, не оставляет поля для будущих функций, триггеров, добавленных другими группами, или непредвиденных схем данных. Архитекторы, которые держат транзакции значительно меньше половины лимита, создают решения, которые могут вырасти без экстренного рефакторинга при исчерпании лимита. Дисциплина состоит в том, чтобы проектировать транзакцию в пределах максимальной нагрузки и при максимальных объемах данных, чтобы добавление функции или автоматизации другого пакета никогда не приводило к превышению пределов. Распространенная дорогостоящая ошибка: решение отлично работает против 10 записей в Developer Sandbox, но достигает губернаторских ограничений в производстве. Безопасные среды разработчика копируют только конфигурацию и не содержат данных. Тестирование по реалистичным объемам в безопасной среде Full Copy Sandbox инициирует возникновение проблем масштабируемости раньше, чем клиенты.

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

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

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

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

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

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

Salesforce предоставляет инструменты для поддержания производительности в здоровом состоянии при разработке решения. Scale Center предоставляет доступность на уровне транзакций к долгосрочным операциям, спорам о блокировке строк и ограничениям транзакций, а потом называет конкретный триггер и соответствующий объект. ApexGuru применяет анализ на основе искусственного интеллекта к производственной телеметрии среды выполнения к поверхностным антишаблонам до их достижения в масштабе, а анализатор кода Salesforce выполняет статический анализ в ожидаемых продажах CI/CD, поэтому сборки не выполняются при отображении запросов внутри циклов или других дефектов производительности. Event Monitoring раскрывает тенденции потребления в динамике, а Proactive Monitoring, функция плана успешного выполнения подписи, постоянно оценивает организацию на наличие рисков производительности и масштабируемости.

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

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

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

Модульность распространяется на созданные компоненты. Создавайте веб-компоненты Lightning вокруг одной ответственности с четкими интерфейсами свойств, отдавайте предпочтение компоновке, а не наследованию, чтобы сложные пользовательские интерфейсы собирались из маленьких сфокусированных компонентов, и используйте настраиваемые события для родительской коммуникации, а не обращайтесь напрямую к родительской. Предоставьте многоразовый Apex в качестве вызываемых действий, чтобы администраторы могли создавать автоматизацию в Flow Builder из возможностей, созданных разработчиком, что уменьшает дублирование и связывает декларативный и программный миры. Хорошо спроектированная модульность — это то, что позволяет создавать возможность один раз и повторно использовать ее, а не повторно внедрять и отдельно обслуживать в любом месте, где это необходимо.

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

Выберите механизм архивирования только после определения соответствия. Прежде чем выбрать механизм, убедитесь, что требования к резидентству, праву на удаление или сохранности данных ограничивают ваши возможности. Функция «Большие объекты» не может быть изменена после вставки, что делает удаление архивных личных данных только записями операцией удаления и восстановления, которая может повлиять на контрольные журналы. Большие объекты хранят массивы архивных наборов данных в хранилище отдельно от стандартных ограничений и подходят для завершенных транзакций и журналов аудита, больше не нужных для ежедневной работы. Внешнее хранилище поддерживает возможность запроса данных посредством Salesforce Connect, уменьшая при этом объем организации, и соответствует гибким схемам запросов или интеграции с корпоративным хранилищем данных. Отслеживайте потребление хранилища на уровне объекта, чтобы рост был видимым до того, как возникнут проблемы, используйте Salesforce Files, а не устаревшие вложения, и настройте сохранность контрольного журнала поля для каждого поля в соответствии с требованиями соответствия, а не применяйте общее максимальное количество, тратящее хранилище.

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

Прямые расходы на внедрение, эксплуатацию и обслуживание системы:

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

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

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

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

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

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

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

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

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

AgentExchange (ранее AppExchange) - ведущий источник готовых решений от сообщества Salesforce ISV. Его инвестиционный профиль способствует быстроте и совместному обслуживанию. Развертывание измеряется неделями, а не месяцами, необходимыми для сопоставимой настраиваемой сборки. Поставщик поддерживает функции, включая совместимость выпуска платформы, без усилий клиента. Функциональность подтверждается существующей клиентской базой, что уменьшает риск внедрения. Специализированные возможности выигрывают от опыта поставщиков домена и инвестиций в исследования, превышающих то, что одна компания финансировала бы самостоятельно. Доступность поддержки зависит от ISV, обычно с определенным путем расширения для проблем, и она несет постоянную стоимость подписки на модель.

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

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

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

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

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

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

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

Оптимизация кредита потребления имеет все большее значение, поскольку компании внедряют Agentforce, Data 360 и другие возможности на основе искусственного интеллекта, которые оцениваются по использованию, а не по месту нахождения. Кредитные пулы могут истощаться удивительно быстро, когда рабочие группы неэффективно разрабатывают процессы или не отслеживают схемы их использования. В отличие от фиксированного количества лицензий, потребление может резко возрасти без принятия решения по инициализации. Установите четкое отображение уровня сжигания кредита, задайте пороги потребления, запускающие проверку, и создайте автоматизацию и агентов, чтобы они были эффективны в вызове дозированных услуг. Та же работа по повышению эффективности, которая поддерживает транзакцию в пределах контролирующих ограничений, позволяет держать дозированное обслуживание в кредитном бюджете. Это та же идея стоимости на стоимость, выраженная в терминах потребления.

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

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

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

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

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

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

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

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

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

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

Адаптируйте облачные практики FinOps к экономике Salesforce Platform, чтобы создать возможность постоянной оптимизации, а не периодической очистки. Пять практик имеют значение.

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

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

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

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

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

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

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

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

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

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

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

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

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

Моделирование стоимости и затрат

Подключите все значительные инвестиции Salesforce к измеримому бизнес-результату.
Моделируйте общую стоимость владения в прямых, непрямых, разовых и текущих категориях, прежде чем подтверждать приверженность подходу.
Сравнение TCO для базового уровня и для оптимизированных архитектурных альтернатив за 3-5-летний горизонт.
Примените последовательную оценку «построить по сравнению с покупкой», которая оценивает стратегическую дифференциацию, время до стоимости и стоимость выхода, а не зависит от ситуативного суждения.

Эффективность ресурсов

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

Лицензия и потребление

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

Мониторинг и управление

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

Постоянная оптимизация и устойчивость

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

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