Оптимизация затрат на хранение и API - схемы
Узнайте больше о оптимизации ресурсов и затрат → Оптимизация данных
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Активные данные модели данных | ✅ Активные данные получают высокое качество хранилища - Данные, регулярно открываемые для бизнес-операций, остаются в стандартных объектах Salesforce с полной возможностью запроса, автоматизацией бизнес-правил и доступом пользователя. Активные данные оправдывают инвестиции в хранилище, поскольку частый доступ требует немедленной доступности ✅ Пример: Возможности и активные обращения текущего года остаются в стандартных объектах с полным функционалом |
| Теплые данные модели данных | ✅ Теплые данные используют золотую стратегию хранилища - Данные, открываемые время от времени для составления отчетов или ссылок, могут оставаться в Salesforce с пометками архива, поддерживающими отфильтрованные представления, или мигрировать в большие объекты, поддерживающие извлечение на основе индекса без возможности бизнес-правил ✅ Пример: Возможности за предыдущий год, помеченные как архивные, но сохраняющие возможность запроса для архивного анализа |
| Холодные данные модели данных | ✅ Холодные данные, архивированные в большие объекты или внешние системы - Данные, сохраненные для соответствия, но редкодоступные, перемещаются в большие объекты (не учитываются в стандартных ограничениях хранилища данных) или внешние архивные системы. Крупные объекты, подходящие для массового архивирования с предсказуемыми схемами доступа. Внешний архив в хранилища данных или хранилище объектов обеспечивает самую низкую сохранность данных соответствия ✅ Пример: Обращения, архивированные в большие объекты более 36 месяцев, с извлечением на основе индекса для доступа к соответствию |
| Просроченные данные модели данных | ✅ Просроченные данные, удаленные посредством автоматических процессов жизненного цикла: прошлые требования к сохранности данных, не имеющих бизнес-значения, должны быть удалены посредством автоматических процессов, а не накапливаться в течение неопределенного времени. Многие организации никогда не удаляют данные из соображений «а вдруг когда-нибудь они понадобятся», что приводит к увеличению объема хранилища, отнимающего бюджет без бизнес-обоснования ✅ Пример: Политика сохранности данных автоматически удаляет записи через 7 лет на основе нормативных требований к сохранности |
| Настройка → Общие сведения о системе → Хранилище данных Настройка → Использование хранилища | ✅ Схема: Панели мониторинга нагрузки отображают потребление хранилища по объекту с тенденциями роста, использование API по интеграции с пиковыми схемами и использование нагрузки обработки с проекциями ✅ Включите активную оптимизацию, пока ограничения не привели к сбоям или непредвиденным излишкам платежей |
| Без отслеживания хранилища → Годовые сюрпризы | ⚠️ Антишаблон: Избыток хранилища, обнаруженный во время переговоров о продлении, требующий немедленной покупки по премиальному ценообразованию без времени на оценку архивных стратегий ⚠️ Организация ежегодно закупает дополнительное хранилище, не анализируя, какие данные потребляют нагрузку или приведет ли архивирование к снижению роста |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Крупные файлы Salesforce Files | ✅ Интеграция внешнего хранилища файлов в целях экономии средств - Хранение файлов в таких службах, как Amazon S3 или Azure Blob Storage, с Salesforce, поддерживающей ссылки на внешнее содержимое. Внешнее хранилище стоит $0,02-0,05 за ГБ в месяц по сравнению с хранилищем файлов Salesforce из расчета $1-3 за ГБ в месяц, в зависимости от выпуска, что обеспечивает 10-20-кратную экономию средств в масштабах ✅ Пример: Решение по управлению контрактами сохраняет активные контракты (за последние 24 месяца) в Salesforce Files для собственного предварительного просмотра и сотрудничества, автоматически мигрирует старые контракты в S3 со ссылками Salesforce, уменьшая хранилище файлов на 70% при сохранении доступа ✅ Компромисс: Интеграция внешнего хранилища требует усилий по разработке и вводит зависимость от внешней службы, но обеспечивает 10-20-кратную экономию средств для сценариев использования с большим количеством файлов, выходя на безубыточность в течение нескольких месяцев |
| Жизненный цикл файла управления содержимым | ✅ Архивирование или удаление старых файлов посредством управления жизненным циклом файлов. Внедрите автоматическое архивирование, позволяющее перемещать файлы за пределы порога сохранности во внешнее хранилище или удаление. Файлы, доступные редко после первоначального создания, включая вложения обращений для закрытых обращений и замененные версии документов, являются основными кандидатами на архивирование Примечание: Хранилище файлов содержит Salesforce Files, вложения, документы и содержимое. Организации, использующие сценарии активного использования документов, включая управление контрактами, библиотеки активов и вложения обращений, часто приближаются к ограничениям хранилища файлов быстрее, чем хранилища данных |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Шаблоны частичного копирования управления безопасной средой | ✅ Шаблоны выборочных данных оптимизируют объем хранилища безопасной среды - исключите большие объекты из шаблонов частичной копии, если полный объем данных не нужен для сценариев тестирования. Внедрение функции сохранности данных безопасной среды для удаления записей, более старых, чем это требуется для тестирования, освобождая объем дополнительных тестовых данных ✅ Пример: Шаблон безопасной среды Partial Copy Sandbox содержит последние 12 месяцев возможностей и обращений, но исключает архивные данные, предоставляя репрезентативные данные тестирования в пределах 5 ГБ, а не требуя Full Copy ✅ Компромисс: Определение выборочных шаблонов данных требует усилий анализа, но позволяет использовать более дешевые типы безопасных сред, исключая данные, ненужные для тестирования сценариев |
| Каденция обновления управления безопасными средами | ✅ Каденция обновления в соответствии с фактическими требованиями к обновлению данных - Соотнесение обновления безопасной среды с фактическими требованиями к обновлению данных, а не с произвольными расписаниями. Многие организации обновляют безопасные среды Full Copy ежемесячно, когда для их схем тестирования достаточно ежеквартального обновления, что приводит к потере объема обновления, который может поддерживать дополнительные безопасные среды ✅ Пример: Безопасная среда Full Copy обновляется ежеквартально, а не ежемесячно, освобождая объем обновления для дополнительных безопасных сред Partial Copy |
| Временные безопасные среды Sandbox Management | ✅ Временное управление безопасной средой с политиками истечения срока действия - отслеживание сред, созданных для определенных проектов или всплывающего тестирования с задокументированными датами удаления. Распространение временной безопасной среды является распространенным источником отходов, поскольку безопасные среды проекта переходят на постоянный статус без каких-либо оснований. Осуществление политики истечения срока действия, требующей обоснования продления для сохранения временных условий за пределами первоначального диапазона ✅ Пример: Безопасная среда проекта, созданная с 90-дневным истечением срока действия, требующая бизнес-обоснования для выхода за рамки завершения проекта |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Анализ пикового использования мониторинга интеграции | ✅ Анализ пикового использования определяет возможности оптимизации планирования - Определение ежедневных и еженедельных моделей потребления. Расписания интеграции, сосредоточенные в часы работы, конкурируют с инициированными пользователем вызовами API. Распространение пакетных интеграций в непиковые окна оптимизирует использование нагрузки без увеличения ограничений ✅ Пример: Пакетные интеграции перенесены с 9:00 до 02:00, что позволит сократить споры по API в часы пик и включить дополнительные интеграции в рамках существующей нагрузки |
| Настраиваемый код Bulk API 2.0 | ✅ Bulk API 2.0 для любой операции по обработке сотен записей - используйте Bulk API 2.0 для любой операции по обработке более нескольких сотен записей. Bulk API обрабатывает до 150M записей на задание, потребляющее минимальное количество вызовов API по сравнению с обработкой записей по отдельности ✅ Пример: Ночная синхронизация данных использует Bulk API 2.0 обработки 100 000 записей с минимальным потреблением API вместо отдельных вызовов API на запись |
| Кэш платформы настраиваемого кода | ✅ Кэш платформы удаляет повторяющиеся запросы для справочных данных - Кэширование часто используемых справочных данных для устранения повторяющихся запросов. Кэширование кодов стран, каталогов продуктов или данных конфигурации уменьшает потребление API для интеграций, которые постоянно запрашивают неизменные справочные данные ✅ Пример: Каталог продуктов кэшируется в кэше платформы, сокращая вызовы API с 1 000 ежедневных запросов до одного обновления кэша |
| Сбор данных об изменении архитектуры интеграции | ✅ Сбор данных об изменении исключает расточительные схемы опроса - используйте сбор данных об изменении для синхронизации данных, а не для схем опроса. CDC публикует события только при изменении данных, исключая пустые вызовы API, проверяющие непроизведенные изменения ✅ Пример: Синхронизация данных клиентов использует события публикации «Сбор данных об изменении» при обновлении клиентов, расходуя вызовы API только для фактических изменений (200 ежедневно), а не ежечасно опрашивая каждую запись клиента (1,2M ежедневных запросов) ✅ Компромисс: Архитектура под управлением событий требует усилий по внедрению событий платформы или CDC, но уменьшает потребление API 95%+ для схем обнаружения изменений, выходя на безубыточность в течение недель |
| Нет мониторинга → Реактивное обнаружение | ⚠️ Антишаблон: Расход API отслеживается только при наличии предельных исключений, создавая реактивное тушение пожаров и аварийные изменения архитектуры под давлением ⚠️ Отсутствует активный анализ тенденций, включающий оптимизацию до ограничения бизнес-операций |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Синхронный шаблон интеграции в реальном времени | ✅ Синхронные интеграции используют наибольшую нагрузку API - интеграции в реальном времени используют один или несколько вызовов API на транзакцию. Потоки массовых транзакций могут использовать значительную нагрузку API. Синхронные схемы уместны, когда немедленная согласованность данных является обязательным бизнес-требованием, но сопряжена с наивысшей стоимостью потребления API ✅ Пример: Отправка заказа требует немедленной инвентаризации и резервирования в системе ОПР, оправдывающей синхронную схему, несмотря на более высокую стоимость API |
| Пакетная обработка схем интеграции | ✅ Пакетные интеграции уменьшают потребление API на 90% + по сравнению с синхронными - Обработка записей в пакете, резко сокращая вызовы API на запись. Bulk API 2.0 обрабатывает миллионы записей в пределах минимального потребления API. Уместно, когда синхронизация в близком к реальному режиме времени отвечает бизнес-потребностям и исключает 90%+ потребления API по сравнению с синхронными схемами ✅ Пример: Синхронизация данных клиентов выполняется ежечасно вместо обновлений в реальном времени, снижая потребление API на 95% при приемлемой задержке данных 1 час |
| События схемы интеграции | ✅ Шаблоны, управляемые событиями, масштабируют эффективно потребляющие ресурсы только по фактическим изменениям - Использование событий платформы или сбора данных об изменении для эффективного распределения событий без накладных опросов. Шаблоны, управляемые событиями, масштабируются эффективно, поскольку они потребляют ресурсы только при фактических изменениях, а не проверяют повторно на наличие изменений, которые не произошли ✅ Пример: Изменения этапа возможности публикуют события платформы, израсходованные системами в нисходящем направлении, исключая опросы и снижая потребление API на 98% |
| TCO Integration Platform MuleSoft | ✅ MuleSoft добавляет стоимость платформы, но может снизить общую стоимость интеграции TCO - MuleSoft Anypoint Platform добавляет стоимость лицензии платформы ($20-200K+ ежегодно), но может сократить общую стоимость интеграции TCO посредством интеллектуального кэширования, объединения подключений, оптимизации пакетов и единого управления во всех схемах интеграции ✅ Компромисс: Промежуточное программное обеспечение оправдывает инвестиции, когда количество подключений интеграции превышает 5-7, обеспечивая многоразовое использование и управление, которые сокращают долгосрочные расходы на обслуживание |
| Ценообразование API сторонней интеграции | ✅ Стоимость стороннего API, смоделированная на основе прогнозируемых объемов транзакций - стоимость модели стороннего приложения на основе прогнозируемых объемов транзакций, отражающих фактическое использование, а не минимальные уровни, предполагающие низкие объемы. Стороннее API-ценообразование варьируется от бесплатных уровней посредством дозированного выставления счета за вызов до лицензий предприятия с единым тарифом ✅ Пример: Модель интеграции TCO для шлюза оплаты включает $15 тыс. годового платежа платформы + $0,10 за транзакцию, оцениваемую в 50 тыс. транзакций в год ($5 тыс.) + $25 тыс. разработки интеграции + $5 тыс. годового обслуживания для $50 тыс. всего в первый год, $10 тыс. продолжается |
| Обслуживание интеграции между точками и центром | ✅ Интеграции между точками умножают усилия по обслуживанию в геометрической прогрессии. Каждая точка интеграции включает начальную сборку, текущее обслуживание, эволюцию обработки ошибок и адаптацию при изменении любой из конечных точек. Интеграции между точками умножают усилия по обслуживанию в геометрической прогрессии по мере роста количества систем. Пять систем с подключениями между точками требуют 10 потоков обслуживания интеграции. Десять систем требуют 45 потоков. Централизованные схемы посредством интеграционных платформ сокращают экспоненциальный рост до линейного масштабирования ✅ Пример: Организация с 8 подключенными системами переходит с 28 интеграций между точками на 8 концентрационных подключений, сокращая потоки обслуживания на 71% |
| Расходы на поддержку операций интеграции | ✅ Расходы на поддержку и устранение неполадок растут с ростом количества интеграций - Каждая интеграция создает потенциальные точки сбоя, требующие инфраструктуры мониторинга, конфигурации оповещений, документации рунета и возможности реагирования на инциденты. Включение текущих вспомогательных расходов в интеграционный ТСО помимо первоначальной разработки ✅ Пример: Расходы на поддержку интеграции смоделированы из расчета 15-20% от начальной стоимости разработки ежегодно для постоянного мониторинга, устранения неполадок и реагирования на инциденты |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Все архивные данные хранятся в активном хранилище неограниченное время. | ⚠️ Бюджет, отнимающий рост хранилища без бизнес-обоснования. Организации ежегодно приобретают дополнительное хранилище, не анализируя объем потребляемых данных и возможность снижения темпов роста архивных стратегий ⚠️ Восстановление: Определите политику сохранности данных с этапами жизненного цикла: активным (0-12 месяцев), теплым (12-36 месяцев), холодным (36+ месяцев архивировано) и просроченным (удаляется после нормативного сохранения). Внедрение автоматизированного архивирования в большие объекты или внешнее хранилище |
| Шаблон Partial Copy содержит все объекты без фильтрации | ⚠️ Потребляет емкость 5 ГБ с архивными данными, не относящимися к тестированию, что вынуждает покупать Full Copy, когда стратегический выбор данных позволит использовать Partial Copy при значительно меньших затратах ⚠️ Восстановление: Анализ требований к тестированию и создание выборочных шаблонов Partial Copy, включительно с данными только за последние 12-18 месяцев, исключая массовые объекты, ненужные для сценариев тестирования |
| Интеграция опрашивает все записи каждые 15 минут, проверяя изменения | ⚠️ Использует 5M API вызовов ежедневно, когда 95% опросов не находят изменений, тратя нагрузку API на ненужные запросы. Создает риск достижения ограничений API и предотвращения завершения законных интеграций ⚠️ Восстановление: Замените схему опроса на «Изменить сбор данных» или «События платформы», которые потребляют вызовы API только при фактических изменениях, снижая потребление API на 95%+ |
| Интеграция выполняет отдельные вызовы API для каждого типа записи в последовательности | ⚠️ Умножает потребление API в 5-10 раз по сравнению с пакетными подходами. Обработка заказа, потребляющая 8 вызовов API на заказ, если достаточно одного составного вызова ⚠️ Восстановление: Внедрение связанных пакетных операций составного API в один вызов API, снижая потребление с 8 вызовов на транзакцию до 1 вызова на транзакцию (снижение на 87%) |
| Безопасные среды Full Copy, приобретенные для каждой группы разработчика | ⚠️ Умножает стоимость в 5 раз, если Partial Copy соответствует большинству требований тестирования. «Полная копия» стоит на 5-10 раз дороже, чем «Частичная копия», и обновляется только ежемесячно по сравнению с 5 днями ⚠️ Восстановление: Зарезервируйте полную копию исключительно для предсерийного UAT и проверки производительности. Использование Developer Pro для разработки и Partial Copy с целевыми шаблонами данных для тестирования интеграции |
| Интеграция утверждена на основе «свободного уровня API» без моделирования объема | ⚠️ Прогнозируемые объемы транзакций превышают свободный уровень во втором месяце, что приводит к неожиданным ежегодным расходам в размере $15 тыс., не включенным в бюджет или анализ ТСО ⚠️ Восстановление: Моделируйте затраты стороннего API на основе прогнозируемых объемов транзакций, включая проекции масштабирования. Добавьте платежи платформы, расходы на транзакцию и перерасход в TCO интеграции до утверждения |
| Потребление API отслеживается только при наличии предельных исключений | ⚠️ Создание реактивного пожаротушения и аварийных изменений архитектуры под давлением. Ограничения создают сбои до определения возможностей оптимизации ⚠️ Восстановление: Внедрите панель мониторинга активного мониторинга API с атрибуцией на уровне интеграции, анализом пикового использования и проекцией роста. Установка предупреждений на примерах порогов использования, например, 70% и 85%, предоставляющих время интереса для оптимизации |
| Создание настраиваемых документов, так как у нас есть разработчики. | ⚠️ Настраиваемая разработка при начальной сборке $80 тыс. + годовое обслуживание $15 тыс., когда параметр AppExchange при ежемесячной оплате $15 за пользователя ($18 тыс. ежегодно для 100 пользователей) обеспечивает более быстрое развертывание, обслуживание поставщика и снижение 5-летнего TCO ⚠️ Восстановление: Оцените решения AppExchange перед настраиваемой разработкой на наличие товарных возможностей. Модель 3-5 лет TCO сравнения сборки и покупки, включительно с обслуживанием, совместимостью платформы и расходами на поддержку |
| Временные безопасные среды проекта переходят на постоянный статус без обоснования | ⚠️ Бюджет, расходующий распространение безопасной среды без бизнес-значения. Организации накапливают 20+ безопасных сред, когда 10 будут удовлетворять фактические потребности в разработке при надлежащем управлении жизненным циклом ⚠️ Восстановление: Внедрите политики истечения срока действия безопасной среды, требующие обоснования продления. Отслеживание безопасных сред с задокументированными датами удаления и автоматическими предупреждениями для проверки истечения срока действия |
- Компонент оптимизации ресурсов и затрат
- Оптимизация ресурсов и затрат - схемы лицензий
- Опора операционного превосходства
Последнее обновление: 2026-06-08