В среду, во время проведения масштабного мероприятия Dreamforce, компания Salesforce столкнулась с серьезной технической проблемой: сервис стал недоступен примерно на семь с половиной часов. Это привело к затруднениям в работе для пользователей и возникновению значительных задержек, а также периодических ошибок. Кроме того, часть клиентов не смогла воспользоваться службой поддержки.
Проблема была зафиксирована в 3:50 утра по восточному времени, и, по данным Salesforce, она затронула "несколько серверов в разных регионах". Сервис был восстановлен примерно в 15:00 по восточному времени после нескольких часов мониторинга, чтобы убедиться в успешности внесенных изменений.
Изначально компания связывала проблему с "сбоем в работе внешнего компонента", который влиял на устаревшую систему аутентификации. Ключевой компонент системы оказался перегружен, что ограничило его способность обрабатывать поступающие запросы. Компания подтвердила, что инфраструктура сторонних поставщиков функционировала нормально.
Помимо очевидной неловкости, связанной с тем, что инцидент произошел во время Dreamforce, аналитик отметил, что этот случай подчеркивает важность обеспечения устойчивости облачных сервисов, а не только устаревших систем.
Облачные технологии не полностью устраняют существующие архитектурные зависимости», – отметил Аббас Джаффри, ведущий консультант в Info-Tech Research Group. «Иногда эти зависимости могут быть менее заметными. Однако, когда конкретная платформа становится ключевым источником данных для компании, скрытые зависимости превращаются в серьезную угрозу для бизнеса, а не просто в техническую проблему».
Google Copilot продолжает давать сбои: проблемы возникают на протяжении всего дня
Компания Salesforce столкнулась с техническими проблемами в работе сервиса 16 сентября в 03:50 по восточному времени. Первоначальный анализ показал, что запросы начали зависать в ожидании ответа от внутреннего сервиса авторизации, который перегружал ресурсы сервера.
Сначала Salesforce временно заблокировала доступ к API и попыталась выполнить частичный перезапуск сервиса. Затем были применены исправления, направленные на решение проблемы в отдельных регионах. К 07:20 пользователи начали сообщать о восстановлении работы сервиса. Компания занималась разработкой "долгосрочного решения, которое будет исправлять проблему в коде".
Тем не менее, полное восстановление не произошло для всех пользователей. Некоторые автоматические решения не решили проблему полностью. Например, пользователи сообщали о том, что запланированные задачи не выполнялись даже после восстановления сервиса. Salesforce вручную перезапустила эти экземпляры.
Позже компания Salesforce сообщила, что "область, на которую повлияли проблемы, оказалась меньше, чем предполагалось". Восстановление началось примерно в 11 утра по восточному времени, и большинство пользователей смогли снова подключиться к сервису.
Последняя группа серверов Hyperforce была восстановлена. Меры по устранению последствий были применены ко всем серверам в 11:39 утра по восточному времени. Компания Salesforce продолжала мониторить ситуацию до момента, когда инцидент был признан решенным в 14:59 по восточному времени.
"Мы приносим извинения за неудобства, которые этот инцидент вызвал у вас и вашей компании", – говорится в сообщении компании в блоге об инцидентах. "Мы проведем тщательное расследование, чтобы установить техническую причину произошедшего, выявить основную проблему и разработать меры, которые помогут предотвратить подобные ситуации в будущем".
Новый вызов: как искусственный интеллект создает проблемы с временными данными
Для компаний, где Salesforce является ключевой системой, даже несколько часов недоступности или сбоев могут привести к возникновению проблем с временными данными, – пояснил Jaffery из Info-Tech. "В результате, события, которые должны были произойти в определенный момент, могут произойти позже, вообще не произойти или произойти в неправильном порядке", – отметил он.
Например, взаимодействие с клиентом может произойти через другой канал, в то время как Salesforce недоступен, но интеграция, рабочий процесс или запланированная процедура, которая обычно фиксирует или распространяет эту информацию, не может быть выполнена.
Это может иметь ряд негативных последствий, – сказал Jaffery. Задержки в обработке транзакций и взаимодействии с клиентами; накопление повторных попыток, таймаутов и очередей в API и промежуточном ПО. Временная неконсистентность записей и пропуск запланированных задач и рабочих процессов. Сотрудники могут потерять видимость истории взаимодействия с клиентом или статуса обращения, даже если основная информация не была потеряна, что приводит к "разложению данных".
Первой и, возможно, самой распространенной ошибкой является успокоение, полагая, что инцидент окончен, поскольку пользователи смогли войти в систему. – подчеркнул Джеффри. – Организациям необходимо немедленно перейти к этапу проверки и восстановления целостности данных. Это включает не только проверку интерактивного доступа, но и API, интеграций, запланированных задач, очередей, рабочих процессов, автоматизации, механизмов аутентификации и систем, подключенных к Salesforce.
В первую очередь, организациям следует выяснить, какие транзакции не были завершены, частично завершены или дублированы в период сбоя. Какие запланированные или асинхронные процессы не были выполнены? Успешно ли удалось повторить интеграции, или они привели к образованию длинной очереди или "шторма" повторных попыток? Соответствуют ли системы, подключенные к Salesforce, текущему состоянию?
Командам безопасности также необходимо проверить поведение аутентификации и сессий, доступ привилегированных пользователей, учетные данные интеграций и любые экстренные изменения, внесенные в процессе восстановления. – пояснил Джеффри. – Самый важный вопрос – это не просто "Работает ли Salesforce?", а "Что организация ожидала, что произойдет в период сбоя, и можем ли мы это подтвердить?".
Как правильно составлять отчеты после инцидентов: советы экспертов
По мнению Джеффри, для проведения эффективного анализа инцидента, компания Salesforce должна выявить последовательность причинно-следственных связей, начиная с первоначального события и сбоя, и заканчивая техническими проблемами, влиянием на клиентов, обнаружением, мерами по устранению, восстановлению и, наконец, постоянными мерами по предотвращению подобных ситуаций.
Представители компании должны уметь оперативно отвечать на эти вопросы, – отметил он.
Какая конкретно проблема вызвала сбой, и почему она затронула процесс входа в систему?
Из-за этой уязвимости, возникшей в данной зависимости, могли быть задействованы значительные вычислительные ресурсы, что, в свою очередь, могло негативно сказаться на работе ключевых сервисов.
Почему механизмы изоляции или резервирования не смогли предотвратить возникновение проблем?
Почему первые попытки решить проблему не принесли желаемого результата, и почему последующее внедрение потребовало дополнительных ресурсов?
Какие меры безопасности принимаются, чтобы избежать подобных инцидентов в будущем?
Как компания Salesforce планирует продемонстрировать реальную эффективность предпринятых мер в случае возникновения непредвиденных ситуаций?
Обычно сообщение о восстановлении сервиса звучит просто: «Сервис снова работает». Однако, более детальный анализ проблемы позволяет сообщить клиентам: «Мы понимаем, почему произошел сбой, почему наши системы не смогли его предотвратить, и какие изменения были внесены, чтобы вероятность повторения подобной ситуации была минимальной».
Не только устаревшие компоненты, но и новые технологии определяют будущее разработки.
Один из главных выводов, сделанных после этого инцидента, заключается в том, что даже небольшая, на первый взгляд, незначительная часть системы может оказаться критически важной. Эксперт подчеркнул, что устаревший компонент не обязательно должен быть большим, чтобы стать ключевым. Например, старый сервис аутентификации может оставаться частью современной системы и, соответственно, становиться зависимостью для новых сервисов.
"Важность компонента определяется не столько его возрастом, сколько его местом в структуре взаимосвязей, потенциальным ущербом в случае сбоя и качеством обработки ошибок", – пояснил Jaffery, ссылаясь на ход событий: увеличение нагрузки на внутренний сервис аутентификации привело к расследованию проблемы с внешним сервисом, что, в свою очередь, выявило влияние на устаревший сервер аутентификации. В итоге, компания Salesforce сообщила, что "основные компоненты системы столкнулись с повышенной нагрузкой, что ограничило их способность обрабатывать запросы".
Это типичный вопрос о надежности: может ли сбой в одном сервисе остаться локализованным, или он перерастет в проблему для всей платформы?
Модернизация не должна оцениваться только по количеству устаревших технологий, которые были заменены, – важно также учитывать концентрацию зависимостей, уровень изоляции, возможности "безотказной работы", пути восстановления и потенциальный ущерб от сбоя, – отметил эксперт.
Это особенно важно для архитекторов корпоративных решений», – подчеркнул он.
Снижение производительности: как "умные" инструменты могут усугубить ситуацию после сокращений
По словам Дэвида Шиплея, генерального директора компании Beauceron Security, на данный момент нет убедительных доказательств того, что произошедшее является результатом взлома. "На текущий момент все указывает на то, что это, скорее всего, следствие неудачного обновления."
Шиплей напомнил о случае в декабре 2025 года, когда внутренний ИИ-агент Amazon, Kiro, вызвал 13-часовое отключение сервисов AWS в регионе материкового Китая. "Я не буду удивлен, если мы увидим, что подобные масштабные сбои будут связаны с работой подобных систем."
Значительные сокращения штата в Salesforce за последние несколько лет также могли усугубить ситуацию, отметил Шиплей. "То, что это произошло во время Dreamforce, стало серьезным испытанием для их отделов продаж и поддержки клиентов. Важно оказать им поддержку в этот сложный период, пока они работают над восстановлением доверия и улучшением качества обслуживания."
Статья изначально была опубликована на CIO.com.
