История сбоев Flexera

1. 27 октября 2026 г. в 17:00 UTCidentified

   Описание инцидента: Мы расследуем задержки, влияющие на обновления контента Technopedia. Содержимое Technopedia, используемое службами Data Platform, IT Visibility и API, не обновлялось с 22 октября из-за повторных сбоев обработки данных. Поэтому клиенты могут видеть устаревший контент Technopedia в затронутых сервисах. Приоритет: P2 Деятельность по восстановлению: наши технические команды выполнили действия по восстановлению для устранения сбоев обработки данных и обновили базовый контент. В настоящее время ведется разработка каталогов, и мы следим за этой деятельностью до ее завершения. Мы предоставим дополнительную информацию по мере восстановления.

2. 28 октября 2026 г. в 01:44 UTCidentified

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

Автоматический перевод официального обновления инцидента.

1. 22 октября 2026 г. в 07:05 UTCinvestigating

   Мы расследуем проблему, затрагивающую функциональность Snow Atlas SAM Core в Южном регионе Великобритании. Некоторые клиенты могут испытывать проблемы с доступом к функциональности пользователей и могут столкнуться с ошибками при доступе к компьютерным данным. Приоритет: P2 Деятельность по восстановлению: Наши технические команды активно изучают этот вопрос и оценивают масштабы воздействия. Мы работаем над выявлением основной причины и восстановлением затронутой функциональности. Дальнейшие обновления будут предоставляться по мере поступления дополнительной информации.

2. 22 октября 2026 г. в 07:21 UTCmonitoring

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

3. 22 октября 2026 г. в 07:38 UTCresolved

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

Автоматический перевод официального обновления инцидента.

1. 15 октября 2026 г. в 22:37 UTCresolved

   После запланированного выпуска Flexera One IT Asset Management 2026R1.4 в регионе Австралии мы столкнулись с проблемой, затрагивающей службы управления ИТ-активами Flexera One в APAC. В результате клиенты не смогли получить доступ к управлению ИТ-активами Flexera One в течение периода воздействия. Приоритет: P1 Импакт-старт: 15 октября 2026 в 11:34 AM PDT Impact End: 15 октября 2026 в 12:32 PM PDT Деятельность по восстановлению: Наши технические команды выявили проблему, затрагивающую сервисные компоненты после запланированного выпуска. Для восстановления доступности услуг на затронутые компоненты была проведена рекультивация. После восстановления службы управления ИТ-активами Flexera One в APAC вернулись к нормальной работе, и проблема теперь считается решенной.

2. 21 октября 2026 г. в 23:40 UTCpostmortem

   ** Описание: Flexera One - IT Asset Management - APAC - Service Unavailability Following 2026R1.4 Выпуск ** Сроки:** 15 октября 2026, 11:34 AM PDT - 15 октября 2026, 12:32 PM PDT ##Резюме происшествия 15 октября 2026 года клиенты, использующие Flexera One IT Asset Management в регионе APAC, столкнулись с перебоями в обслуживании, которые препятствовали доступу к приложению. Сбой произошел после завершения выпуска ITAM 2026R1.4. Хотя услуги изначально были доступны и работали нормально после выпуска, приложение впоследствии стало недоступным. Технические группы исследовали сбои и выявили сбои, влияющие на инициализацию экземпляров приложений. Дальнейшие исследования показали, что производственная среда сохраняла зависимость от предыдущего процесса инициализации приложения, в то время как переход к обновленному процессу осуществлялся. Хотя экземпляры приложений были успешно инициализированы во время выпуска, экземпляры замены не смогли завершить тот же процесс из-за устаревшей конфигурации. Пострадавшие случаи замены не смогли успешно завершить инициализацию или пройти необходимые проверки здоровья, предотвращая возвращение приложения к нормальной работе. Технические команды исправили производственную конфигурацию, чтобы ссылаться на обновленный процесс инициализации и выполнили обновление экземпляра. После этих изменений пострадавшие экземпляры были успешно инициализированы, и доступность сервиса ITAM была восстановлена примерно в 12:32 вечера по местному времени. ##Коренная причина Инцидент был вызван сохраняющейся производственной зависимостью от предыдущего процесса инициализации заявки при переходе на обновленный процесс в производственной среде APAC. Несмотря на то, что среда постановки и тестирования на принятие пользователем уже перешла на обновленный процесс, производственная среда APAC сохранила конфигурацию, которая ссылалась на предыдущий процесс инициализации. Во время выпуска 2026R1.4 экземпляры приложений были инициализированы вручную с использованием обновленного процесса, что позволило ITAM изначально нормально работать, несмотря на оставшуюся производственную зависимость. Впоследствии компоненты, поддерживающие предыдущий процесс, были сокращены, при том понимании, что более широкий переход был в значительной степени завершен. Когда были запущены экземпляры приложений для замены, производственная конфигурация продолжала направлять их на предыдущий процесс инициализации. Поэтому пострадавшие не смогли успешно завершить инициализацию или пройти необходимые медицинские осмотры, что привело к сбою в обслуживании. В качестве основной причины инцидента была подтверждена оставшаяся производственная зависимость от предыдущего процесса инициализации. Коррекция производственной конфигурации для использования обновленного процесса инициализации устранила эту зависимость и позволила успешно инициализировать экземпляры замены. ## Реабилитационные меры В ходе реагирования на инцидент были приняты следующие меры: 1. ** Расследование инцидента инициировано: ** Технические группы исследовали недоступность приложений и выявили сбои, влияющие на инициализацию и проверку работоспособности экземпляров приложений в производственной среде APAC. 2.**Определение конфигурации:** Исследование показало, что производственная конфигурация продолжала ссылаться на предыдущий процесс инициализации приложения, а не на обновленный процесс. 3.** Исправлена конфигурация продукта:** Конфигурация производства была обновлена, чтобы ссылаться на правильный процесс инициализации приложения, устраняя зависимость от предыдущего процесса. 4. **Случаи применения Отредактированные: ** Технические команды выполнили обновление экземпляра после коррекции конфигурации, что позволило успешно инициализировать экземпляры замены. 5 ** Восстановление услуг подтверждено: ** Технические группы подтвердили, что пострадавшие случаи были успешно инициализированы, проверки здоровья приложений проходили, и службы ИТАМ вернулись к нормальной работе. ##Профилактические меры будущего После инцидента была проведена ретроспектива для обзора процесса инициализации заявки, оставшихся производственных зависимостей, процедур валидации выпуска и возможностей для улучшения обнаружения инцидентов и реагирования. Были завершены или осуществляются следующие корректирующие действия и мероприятия по улучшению: 1. ** Коррекция конфигурации производства: ** Производственная среда APAC была обновлена, чтобы использовать правильный процесс инициализации приложения, заменив предыдущую конфигурацию. 2. ** Валидация зависимости от наследственности: ** Последующие действия были установлены, чтобы добавить шаг проверки до того, как устаревшие компоненты платформы будут уменьшены или выведены из эксплуатации, гарантируя, что производственные услуги полностью перешли и никаких оставшихся зависимостей на предыдущей платформе не существует. 3. **Обзор отзыва и проверки работоспособности приложения: ** Существующие проверки здоровья приложений, процедуры валидации высвобождения и охват после выпуска теста на здравомыслие рассматриваются на фоне неудачи, наблюдаемой во время этого инцидента. Обзор определит, существуют ли какие-либо пробелы в охвате и требуется ли дополнительный мониторинг, проверка или другие улучшения. 4.** Расследование масштабирования:** Мы будем продолжать исследовать, что привело к масштабированию первоначальных экземпляров приложения после выпуска, и определить, требуется ли какое-либо дополнительное корректирующее или профилактическое действие. 5. ** Улучшение коммуникации с клиентами: ** Мы определили возможность для более своевременного общения с клиентами во время этого инцидента. Наши установленные методы эскалации инцидентов и коммуникации предназначены для обеспечения активного уведомления клиентов при выявлении незапланированного воздействия на обслуживание. Информация, полученная в результате этого инцидента, была включена в наши текущие методы реагирования на инциденты, чтобы обеспечить последовательное применение этих процедур и своевременное, активное обновление для клиентов во время сбоев в обслуживании.

Автоматический перевод официального обновления инцидента.

1. 8 октября 2026 г. в 10:59 UTCinvestigating

   Описание инцидента: Мы расследуем проблему, затрагивающую Лицензионную службу в SAM Core. Пользователи могут быть не в состоянии загрузить информацию о лицензии и могут столкнуться с сообщениями об ошибках при доступе к функциональности Лицензионного сервиса. Проблема была подтверждена в Южной и Западной Европе, и технические команды в настоящее время оценивают полный объем воздействия. Приоритет: P2 Реставрационная деятельность: Технические группы активно исследуют проблему и рассматривают затронутую услугу. В настоящее время проводится дополнительная проверка для определения полного объема воздействия и восстановления нормальной работы службы. Дальнейшие обновления будут предоставляться по мере поступления дополнительной информации.

2. 8 октября 2026 г. в 11:30 UTCmonitoring

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

3. 8 октября 2026 г. в 12:11 UTCresolved

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

Автоматический перевод официального обновления инцидента.

1. 8 октября 2026 г. в 00:08 UTCinvestigating

   Мы расследуем проблему, затрагивающую функциональность Соглашения в Snow Atlas для клиентов в Австралии. Клиенты могут испытывать недостающие или недоступные данные при доступе к вкладке «Соглашения», и операции обновления данных могут потерпеть неудачу. Приоритет: P2 Реставрационная деятельность: технические команды активно исследуют проблему и оценивают степень воздействия на клиента. Ведутся работы по выявлению причины проблемы и восстановлению нормальной функциональности. Дальнейшие обновления будут предоставляться по мере поступления дополнительной информации.

2. 8 октября 2026 г. в 01:39 UTCresolved

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

Автоматический перевод официального обновления инцидента.

1. 7 октября 2026 г. в 20:27 UTCinvestigating

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

2. 7 октября 2026 г. в 22:23 UTCinvestigating

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

3. 8 октября 2026 г. в 00:03 UTCinvestigating

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

4. 8 октября 2026 г. в 00:04 UTCmonitoring

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

5. 8 октября 2026 г. в 02:24 UTCresolved

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

6. 20 октября 2026 г. в 17:50 UTCpostmortem

   ** Описание: ** Spot Ocean - Kubernetes - Проблемы подключения прерывистых контроллеров ** Сроки:** 7 октября 2026, 11:20 AM PDT - 12:30 PM PDT ** Резюме инцидента** В среду, 7 октября 2026 года, в 11:20 утра PDT, несколько сред Spot Ocean для Kubernetes испытали перебои с подключением контроллера. Во время инцидента платформа временно интерпретировала информацию о сердцебиении контроллера как устаревшую и приостановленную операцию масштабирования для пострадавших кластеров в качестве меры безопасности. Пострадавшие контроллеры продолжали сообщать информацию о сердцебиении во время инцидента. Однако временная метка, используемая для проверки подключения контроллера, устарела в компоненте базы данных, в результате чего активные контроллеры временно не реагируют. Поведение было прерывистым, и текущая информация о сердцебиении впоследствии стала доступна без ручного вмешательства, что позволило возобновить обычные операции масштабирования. Технические команды рассмотрели путь обработки сердцебиения контроллера, поведение базы данных, сервисную телеметрию и связанные с ней сигналы инфраструктуры, чтобы определить, почему действительная активность сердцебиения интерпретируется как устаревшая. Никаких дополнительных происшествий после инцидента в окне не наблюдалось. После постоянного мониторинга и проверки стабильности обслуживания инцидент был признан урегулированным. **Корневая причина** Инцидент был вызван тем, что старый контроллер перезаписывал более поздний значок времени в компоненте базы данных. Хотя пострадавшие контроллеры продолжали сообщать о нормальном сердцебиении, устаревшая метка времени сделала последнее сохраненное сердцебиение более старым, чем оно было. Когда платформа оценила эту временную метку, она превысила настроенный порог сердцебиения и запустила механизм безопасности, который временно приостановил операции масштабирования для пострадавших кластеров. Конкретное условие, которое задержало более раннее обновление базы данных, не было окончательно установлено. Тем не менее, процесс обновления базы данных не содержал защиты, чтобы предотвратить замену более старой временной метки сердцебиения более новой действительной временной метки. Это позволило отсрочить информацию о сердцебиении, чтобы создать видимость того, что активно сообщающие контроллеры не реагируют. ** Меры по восстановлению** В ходе реагирования на инцидент были приняты следующие меры: 1.Отчеты и поведение клиентов: технические команды рассмотрели примеры, чтобы подтвердить поведение, установить окно воздействия и определить, была ли проблема изолирована или повлияла на несколько сред. 2. Controller Heartbeat Activity Validated: Controller activity was review to determine if the affected controllers had stop reporting. Следствие подтвердило, что информация о сердцебиении продолжала поступать во время инцидента. 3.Расследование пути обработки сердцебиения: технические команды проследили, как генерировалась, хранилась и оценивалась информация о сердцебиении, чтобы определить, где текущая активность сердцебиения интерпретировалась как устаревшая. 4. Database and Service Health Assessed: Relevant database performance, service behavior, and infrastructure telemetry was review to assessment potential processing delays and rule out broader platform instability. 5. Timestamp Regression Identified: Расследование установило, что более старая метка времени биения сердца перезаписала более новую действительную метка времени, в результате чего платформа временно интерпретировала сердцебиение как несвежее. 6. Service Stability Validated: Технические команды продолжали мониторинг после восстановления. Никаких дополнительных случаев не наблюдалось, и операции по масштабированию оставались стабильными до закрытия инцидента. Будущие превентивные меры** Планируются следующие улучшения для усиления обработки сердцебиения и улучшения выявления аналогичных состояний: 1.Сердечное биение Таймстэмп Защита: Процесс обновления базы данных будет изменен, чтобы предотвратить более старую временную метку сердцебиения от перезаписи более недавней действительной временной метки. 2. Улучшенная диагностика: дополнительная регистрация будет введена вокруг обновлений сердечного ритма, чтобы захватить источник каждого обновления, соответствующий контекст запроса, предыдущие и новые значения метки времени и источник метки времени. 3. Мониторинг и оповещение: Новый мониторинг и оповещение будут разработаны с использованием дополнительной диагностической информации для более быстрого выявления регрессий меток времени и аналогичных условий обработки сердцебиения. 4.Обзор доступа к базе данных: шаблоны доступа к базе данных, связанные с обработкой сердцебиения, будут пересмотрены для выявления возможностей сокращения задержек обработки и оптимизации производительности при повышенной нагрузке.

Автоматический перевод официального обновления инцидента.

1. 29 сентября 2026 г. в 11:08 UTCinvestigating

   Описание инцидента: Мы расследуем проблему, затрагивающую службу уведомлений о событиях в нескольких производственных средах. Клиенты могут испытывать задержки или сбои при получении уведомлений о событиях v2, включая уведомления, доставляемые по электронной почте, веб-хукам, Slack и другим поддерживаемым каналам. События продолжают записываться и остаются доступными через консоль Flexera One и API. В настоящее время нет никаких признаков того, что была затронута функциональность базовой платформы или данные о событиях. Приоритет: P3 Деятельность по восстановлению: Наши технические команды определили проблему и внедрили меры по восстановлению услуг. Мониторинг показывает, что уровень ошибок снижается, и команды продолжают проверять стабильность обслуживания и оценивать весь масштаб воздействия. По мере продвижения расследования и усилий по восстановлению будут предоставляться дополнительные обновления. Дальнейшее расследование подтвердило, что эта проблема не повлияла на клиентов. Затрагиваемые уведомления не предназначались для публикации.

2. 29 сентября 2026 г. в 11:53 UTCresolved

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

3. 13 октября 2026 г. в 04:42 UTCpostmortem

   ** Описание: ** Spot by Flexera - Event Notification Processing Errors **Время:** 29 сентября 2026, 2:06 AM PDT - 4:51 AM PDT ** Резюме инцидента** 29 сентября 2026 года Flexera выявила повышенные ошибки приложений в компоненте обработки уведомлений, отвечающем за обработку определенных рабочих процессов уведомлений о событиях. Автоматизированный мониторинг выявил повышенную активность ошибок, что побудило расследование определить, были ли затронуты уведомления, обращенные к клиентам. В ходе расследования технические группы выявили сбои, возникающие на пути обработки уведомлений, и провели подробную оценку пострадавших событий, рабочих процессов уведомлений и потенциального воздействия на клиента. Первоначальный анализ показал, что проблема может потенциально повлиять на обработку уведомлений в более широком смысле, и был объявлен крупный инцидент, в то время как масштабы и последствия были подтверждены. Дальнейшая оценка воздействия подтвердила, что соответствующие уведомления не предназначены для публикации клиентам. Информация о событиях продолжала успешно записываться и оставалась доступной через платформу на протяжении всего расследования. Никакая функциональность, ориентированная на клиента, не была нарушена, данные о событиях не были потеряны, и в результате этой проблемы не было выявлено влияние на клиента. По результатам оценки воздействия приоритет инцидента был понижен, и расследование было завершено после подтверждения того, что услуги, связанные с клиентами, остались незатронутыми. **Корневая причина** Исследование показало, что рабочий процесс обработки уведомлений столкнулся с исключением приложения при обработке подмножества внутренних событий. Эти события были сконфигурированы таким образом, что они не предназначались для доставки уведомлений клиентов. Несмотря на то, что исключения вызвали повышенные ошибки в приложениях и потребовали расследования, последующий анализ подтвердил, что соответствующие уведомления не должны были распространяться среди клиентов. В результате доставка уведомлений, функциональность платформы и доступ к информации о событиях не пострадали. ** Меры по восстановлению** В ходе реагирования на инцидент были приняты следующие меры: 1.Initiated: Технические команды исследовали повышенные ошибки приложений, обнаруженные с помощью автоматизированного мониторинга и оценки потенциального воздействия на клиента. 2. Анализ обработки уведомлений: Рабочий процесс уведомления был рассмотрен для определения источника исключений в приложении и определения объема проблемы. 3.Оценка воздействия на клиента завершена: технические команды проверили типы уведомлений, просмотрели поведение публикации событий и подтвердили, что соответствующие уведомления не предназначены для доставки клиентов. 4. Проведение проверки и мониторинга системы: отслеживались тенденции ошибок, поведение служб и обработка уведомлений, чтобы подтвердить стабильную работу и подтвердить, что услуги, ориентированные на клиента, остались незатронутыми. 5.Реклассификация инцидентов завершена: после подтверждения того, что не было никакого воздействия на клиента, приоритет инцидента был понижен и инцидент был официально урегулирован. Будущие превентивные меры** После этого исследования мы определили возможности для повышения скорости и точности оценки воздействия, когда оперативные оповещения включают внутренние рабочие процессы обработки. 1. Улучшенная оценка воздействия: пересмотр внутренних классификаций уведомлений и процедур расследования для ускорения определения того, влияет ли проблема на функциональность, ориентированную на клиента, во время будущих инцидентов. 2. Enhanced Notification Workflow Visibility: Улучшение оперативной видимости обращенных к клиенту и не обращенных к клиенту путей обработки уведомлений для поддержки более быстрой проверки воздействия и реагирования на инциденты.

Автоматический перевод официального обновления инцидента.

1. 28 сентября 2026 г. в 09:10 UTCinvestigating

   Описание инцидента: Мы расследуем вопрос, влияющий на видимость ИТ в регионе APAC, где панели управления Power BI не загружаются. Клиенты в пострадавшем регионе могут быть не в состоянии получить доступ к панели мониторинга отчетности в приложении. Текущее расследование указывает на то, что проблема ограничена регионом АТР, и в настоящее время в других регионах ее влияние не наблюдается. Приоритет: P2 Деятельность по восстановлению: Наши технические команды активно исследуют проблему, чтобы определить основную причину и восстановить функциональность отчета. Мы продолжаем оценивать масштабы воздействия, следить за состоянием услуг и, при необходимости, осуществлять корректирующие действия. Мы предоставим дополнительные обновления по мере поступления дополнительной информации.

2. 28 сентября 2026 г. в 09:26 UTCresolved

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

3. 26 октября 2026 г. в 12:10 UTCpostmortem

   **Описание:** Flexera One- IT Visibility- APAC - Отчетные панели приборов недоступны ** Сроки: ** 28 сентября 2026 года, 1:38 утра PDT до 28 сентября 2026 года, 2:15 утра PDT ** Резюме инцидента** В понедельник, 28 сентября 2026 года, в 1:38 утра по PDT, Flexera выявила проблему, затрагивающую доступ к информационным панелям Power BI для клиентов в регионе APAC. Наши технические группы были оперативно привлечены, и первоначальное расследование подтвердило, что воздействие было ограничено АТР, в то время как другие регионы оставались отзывчивыми. Дальнейшее расследование показало, что изменения конфигурации, связанные с запланированной миграцией идентификации и управления доступом, повлияли на настройки подключения, требуемые службами отчетности. Во время применения этих изменений настройки подключения служб отчетности были сброшены до значений, которые не содержали полных адресов обслуживания, необходимых для успешной связи. Следовательно, пострадавшие службы не смогли правильно запуститься, что привело к недоступности панелей отчетности Power BI для клиентов APAC. Для восстановления обслуживания техническая группа вручную исправила затронутые настройки подключения в среде APAC. Это восстановило связь между службами отчетности и аутентификации, что позволило пострадавшим службам восстановиться. После восстановления валидация подтвердила, что информационные панели Power BI были доступны и работали нормально примерно в 2:15 утра по местному времени. **Корневая причина** Инцидент был вызван неправильными настройками подключения, применяемыми к среде APAC во время изменения конфигурации, связанного с миграцией идентификации и управления доступом. Изменение сбрасывает адреса подключения служб отчетности на значения, которые не содержат полных адресов, необходимых для успешной связи с службами аутентификации. В результате пострадавшие службы отчетности не смогли правильно начать работу, что сделало панели отчетности Power BI недоступными для клиентов в регионе APAC. Факторы, способствующие * Несоответствие конфигурации: требуемые адреса соединений ранее обновлялись непосредственно в окружающей среде, но не отражались в конфигурации развертывания. Следовательно, последующее изменение конфигурации вновь ввело неправильные значения. * Пробел в валидации развертывания: процесс развертывания не идентифицировал неправильные настройки соединения до того, как они повлияли на доступность обслуживания. * Координация изменений и проверка зависимостей: Процесс миграции не полностью учитывает требования к конфигурации всех зависимых служб, в результате чего изменения конечных точек применяются без предварительной проверки в зависимости от затронутых служб. ** Меры по восстановлению** Наши команды выполнили нижеприведенные действия по восстановлению сервиса в норме: * Затронутые настройки подключения были исправлены для восстановления связи между службами отчетности и аутентификации. * Пострадавшие службы восстановились, и проверка подтвердила, что панели мониторинга Power BI были доступны и работали нормально. * Впоследствии конфигурация была исправлена для обеспечения последовательного поддержания требуемых настроек соединения для будущих развертываний. Будущие превентивные меры** Выявлены и разрабатываются следующие меры для снижения вероятности повторения и повышения устойчивости обслуживания: Управление конфигурацией: обеспечить последовательное управление изменениями конфигурации службы для предотвращения расхождений между развернутыми настройками и поддерживаемыми конфигурациями. Проверка развертывания: Проверка запланированных изменений конфигурации перед развертыванием для проверки правильности требуемых настроек подключения к сервису. Консистенция конфигурации: Убедитесь, что критические настройки соединения поддерживаются в соответствующих источниках конфигурации и не зависят от ручных изменений в отдельных средах. * Координация изменений: Улучшение координации запланированных миграций и изменений конфигурации, включая проверку требований и зависимостей затронутых служб. Меры предосторожности при развертывании: Усильте проверку перед развертыванием, чтобы определить неправильные настройки конфигурации, прежде чем они вызовут сбои в обслуживании.

Автоматический перевод официального обновления инцидента.

1. 25 сентября 2026 г. в 23:18 UTCinvestigating

   Мы расследуем проблему, затрагивающую определенную интеграцию управления ИТ-активами и сервисами App Portal во всех регионах. Клиенты, использующие уязвимую интеграцию на основе API, могут испытывать сбои аутентификации, что приводит к несанкционированным ошибкам HTTP 401, что может помешать успешному завершению запросов. Пользователи Портала приложений также могут столкнуться с ошибками при отправке запросов. Приоритет: P2 Реставрационная деятельность: Наши технические команды активно исследуют проблему и оценивают корректирующие действия. Ведется работа по расследованию и валидации, и мы работаем над тем, чтобы как можно быстрее восстановить нормальную функциональность сервиса. Дальнейшие обновления будут предоставляться по мере поступления дополнительной информации.

2. 26 сентября 2026 г. в 05:31 UTCidentified

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

3. 26 сентября 2026 г. в 12:30 UTCmonitoring

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

4. 27 сентября 2026 г. в 05:39 UTCmonitoring

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

5. 28 сентября 2026 г. в 17:14 UTCresolved

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

6. 8 октября 2026 г. в 11:25 UTCpostmortem

   **Description:** Flexera One – IT Asset Management – All Regions – App Portal Errors and API Request Failures **Timeframe:** September 24, 2026, 12:12 PM PDT – September 26, 2026, 4:38 AM PDT **Incident Summary** Beginning September 24, 2026, at approximately 12:12 PM PDT, customers using API-based integrations with Flexera One IT Asset Management \(ITAM\) experienced authentication failures that returned HTTP 401 Unauthorized responses. App Portal users also encountered errors when submitting requests, and integrations such as App Broker and Business Adapter that rely on these APIs were affected. Impact was observed across the North America, Europe, and Asia-Pacific regions. Technical teams investigated and confirmed that the failures were not related to customer credentials or customer configuration. Application logs showed that the components required to authenticate these requests were failing to initialize. Further investigation determined that the behavior was introduced by a hotfix deployed as a preventative measure during the response to the earlier ITAM menu loading incident on September 24. Technical teams reproduced the behavior in testing, developed a corrective fix, and validated it. During deployment validation, a secondary component-loading issue was identified and addressed through an updated hotfix. Following deployment of the updated hotfix to Production, technical teams verified that API functionality was operating as expected, and service was restored on September 26 at approximately 4:38 AM PDT. The incident then moved to extended monitoring while customer confirmation was obtained, and confirmation was received on September 28. Following the restoration of service, isolated intermittent authentication failures were reported and investigated separately from the main incident. Technical teams identified additional connection-handling and environment-specific configuration conditions and deployed further hotfixes, which were validated through September 30. Continued monitoring and customer review through October 1 confirmed that the issue could no longer be reproduced and that no further occurrences had been observed. **Root Cause** The incident was caused by a defect in a hotfix that was deployed as a preventative measure during the response to the earlier ITAM menu loading incident on September 24. The hotfix removed a dependency from the application's authentication components and changed how the application reads the configuration it uses to connect to authentication services. The required settings were present in the deployed configuration. However, the application attempted to read them using a method that is not supported for configuration loaded at runtime. As a result, the components required for authentication could not be initialized, and requests that required authentication were rejected as unauthorized. This produced the API errors and App Portal request failures that customers experienced. The same behavior occurred in the pre-production validation environment when the hotfix was applied there. It was not identified before the hotfix reached Production because the affected APIs are not actively used in that environment, and specific error alerting was not yet in place for them. The initial fix addressed the primary configuration defect. During subsequent validation and monitoring, additional component-loading, connection-handling, and environment-specific configuration conditions were identified and required further hotfixes before sustained stability could be confirmed. **Remediation Actions** The following actions were taken during the incident response: 1. Incident Response Initiated: Technical teams began investigating after customers reported authentication failures and API errors. 2. Scope and Customer Configuration Assessed: Technical teams confirmed that the failures were not related to customer credentials or configuration, and confirmed that impact extended to multiple regions. 3. Underlying Condition Identified: Technical teams determined that the required authentication settings were present but could not be read at runtime, and reproduced the behavior in testing. 4. Corrective Fix Developed and Validated: The application code was updated to read the settings using a supported method. Validation testing confirmed that the authentication errors no longer occurred. 5. Corrective Fix Deployed and Service Restored: A secondary component-loading issue identified during deployment validation was addressed through an updated hotfix. After the updated hotfix was deployed to Production, technical teams verified that API functionality was operating as expected. 6. Extended Monitoring and Customer Validation: Technical teams monitored service behavior through the weekend and obtained confirmation from an affected customer. 7. Post-Incident Remediation: After isolated intermittent failures were reported following the restoration of service, technical teams deployed further hotfixes and validated them through September 30. Monitoring and customer review continued through October 1 to confirm that the issue no longer occurred. **Future Preventative Measures** Following the incident, we conducted a retrospective to review the technical cause, hotfix validation process, monitoring capabilities, and factors that contributed to the customer impact. The following measures have been completed or are being implemented: 1. Runtime Configuration Correction: The application has been corrected to read its authentication configuration using a supported method, and additional hotfixes have been deployed and validated across production environments. 2. API Monitoring and Alerting: Error-rate alerting is being added for the affected APIs so that authentication failures are detected in both pre-production and Production environments, even when the service is not actively used. 3. Hotfix Validation Process: We are evaluating additional checks of dependent services, such as API integrations and App Portal functionality, as part of hotfix validation before changes are approved for Production.

Автоматический перевод официального обновления инцидента.

1. 25 сентября 2026 г. в 16:19 UTCinvestigating

   Описание инцидента: Мы расследуем проблему, затрагивающую подмножество клиентов Flexera One по управлению ИТ-активами. Пострадавшие клиенты могут столкнуться с отсутствующими данными о запасах или пустыми результатами при доступе к просмотру «Все запасы» и соответствующим взглядам на основе запасов. Проблема ограничивается подмножеством клиентов в Северной Америке. Приоритет: P2 Реставрационная деятельность: Технические группы активно изучают вопрос и анализируют рабочие процессы обработки кадастровых данных, связанные с затронутой функциональностью. Масштабы воздействия проверяются при оценке вариантов смягчения последствий и восстановления. Дальнейшие обновления будут предоставляться по мере поступления дополнительной информации.

2. 25 сентября 2026 г. в 18:50 UTCidentified

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

3. 25 сентября 2026 г. в 21:22 UTCidentified

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

4. 26 сентября 2026 г. в 00:55 UTCidentified

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

5. 26 сентября 2026 г. в 05:25 UTCmonitoring

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

6. 26 сентября 2026 г. в 07:13 UTCresolved

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

Автоматический перевод официального обновления инцидента.

1. 24 сентября 2026 г. в 21:43 UTCidentified

   Описание инцидента: Мы расследуем проблему, затрагивающую Spot Ocean для AWS. Клиенты могут быть не в состоянии запустить новые экземпляры из-за сбоев в предоставлении экземпляров. В результате пораженные кластеры могут быть не в состоянии масштабироваться, как ожидалось. Существующие рабочие нагрузки остаются работоспособными. Наши технические команды активно изучают масштабы и последствия проблемы. Приоритет: P2 Реставрационная деятельность: Наши технические команды выявили потенциальную проблему, связанную с недавними изменениями, влияющими на предоставление услуг по предоставлению услуг, и активно проверяем влияние. В настоящее время проводятся мероприятия по смягчению последствий, включая откат недавних изменений, в то время как команды контролируют восстановление и поведение службы. Дальнейшие обновления будут предоставляться по мере поступления дополнительной информации.

2. 24 сентября 2026 г. в 22:16 UTCresolved

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

3. 9 октября 2026 г. в 06:33 UTCpostmortem

   ** Описание: ** Spot Ocean for AWS - Отказы в предоставлении информации ** Сроки:** 24 сентября 2026 года, 12:00 PM PDT до 24 сентября 2026 года, 2:54 PM PDT ** Резюме инцидента** 24 сентября 2026 года Spot Ocean для AWS столкнулся с проблемой, которая помешала некоторым клиентам запустить новые экземпляры. В результате затронутые кластеры не смогли масштабироваться, как ожидалось, когда требовалась дополнительная вычислительная мощность. Существующие случаи и рабочие нагрузки оставались в рабочем состоянии на протяжении всего инцидента. Воздействие ограничивалось предоставлением новых экземпляров и операциями по масштабированию кластеров. Техническая группа определила, что недавнее изменение программного обеспечения привело к неожиданному поведению во время процесса резервирования экземпляра. Изменение было отменено, что устранило ошибки в обеспечении и восстановило нормальную работу службы. После отката была выявлена и исправлена основная проблема программного обеспечения. Обновленная функциональность прошла дополнительную проверку, чтобы обеспечить полное решение проблемы до ее повторного внедрения в производственную среду. Технические команды проверили успешные запуски экземпляров после отката, а проверка клиентов подтвердила, что новое предоставление экземпляров работает, как ожидалось. Инцидент был урегулирован в 2:54 вечера ПДТ 24 сентября 2026 года. **Корневая причина** Инцидент был вызван недавним изменением программного обеспечения, которое ввело непреднамеренное поведение во время предоставления экземпляров AWS. Изменение повлияло на то, как обрабатывалась определенная информация о конфигурации кластера, что привело к сбоям в обеспечении некоторых операций масштабирования. Хотя изменение было разработано для поддержки тегов для конкретных ресурсов AWS, его поведение также повлияло на другие поддерживаемые конфигурации кластеров. При определенных условиях обновленная логика тегов привела к тому, что дублированная информация тегов была представлена в рамках запроса на предоставление экземпляра. AWS отклонила эти запросы, поскольку информация меток не соответствовала ожидаемым требованиям. В результате Spot Ocean не смог успешно завершить предоставление некоторых новых экземпляров. Это в первую очередь повлияло на запуски новых экземпляров и операции по масштабированию кластеров. Существующие случаи уже были успешно обеспечены и поэтому продолжали нормально функционировать на протяжении всего инцидента. С тех пор базовая функциональность была исправлена, и выполняется дополнительная проверка для обеспечения последовательной работы обновленного поведения в поддерживаемых конфигурациях кластеров AWS до его возвращения в производство. ** Меры по восстановлению** Наши команды выполнили нижеприведенные действия по восстановлению сервиса в норме: * Перевернул изменение программного обеспечения, восстановив нормальное резервирование экземпляров. Выявлена и исправлена основная проблема в затронутой функциональности. * Выполнена дополнительная проверка исправленной функциональности. Введены дополнительные меры предосторожности, позволяющие развернуть обновленную функциональность контролируемым образом. * Подтверждено, что после отката были проведены новые операции по резервированию экземпляров и масштабированию кластеров. Будущие превентивные меры** * Расширение автоматизированного тестирования, например, сценариев резервирования и масштабирования кластеров. Увеличить регрессионное тестирование в поддерживаемых конфигурациях кластеров AWS. * Расширить сквозное тестирование для масштабирования рабочих процессов. * Улучшить мониторинг и оповещение о сбоях в обеспечении и масштабировании. Усилить проверку изменений до развертывания производства. Ввести дополнительные гарантии для контролируемого развертывания изменений, которые влияют на поведение обеспечения. * Увеличить охват тестирования для крайних случаев и сценариев обработки ошибок.

Автоматический перевод официального обновления инцидента.

1. 24 сентября 2026 г. в 20:46 UTCmonitoring

   Ранее сегодня проблема, затрагивающая обработку запасов в Flexera One IT Asset Management (ITAM) в регионе NAM, затронула подмножество клиентов. Расследование показало, что загрузка запасов была получена успешно, но не обрабатывалась для пострадавших клиентов, что привело к задержкам с данными о запасах, отраженными в Flexera One ITAM. Были проведены восстановительные мероприятия, и с тех пор успешно возобновилась обработка запасов. Запасные файлы продолжают нормально обрабатываться, однако восстановление оставшегося отставания все еще продолжается и отслеживается в результате этого инцидента. Приоритет: P2 Деятельность по восстановлению: Технические команды реализовали действия по восстановлению, которые восстановили обработку файлов инвентаризации и подтвердили успешную обработку с помощью мониторинга и регистрации. Работа службы остается стабильной, и восстановление отставания продолжается, поскольку обрабатываются ранее поставленные в очередь файлы инвентаря. Технические группы активно отслеживают прогресс в восстановлении, здоровье обслуживания и сокращение отставания, в то время как текущие мероприятия по проверке продолжаются. Предыдущие обновления, связанные с более ранними стадиями этого инцидента, можно найти в истории инцидента, связанной ниже. Дальнейшие обновления будут предоставляться по мере прогресса в восстановлении отставания и продолжения деятельности по проверке. https://status.flexera.com/incidents/5wrg6jl9bj2h

2. 25 сентября 2026 г. в 08:15 UTCmonitoring

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

3. 25 сентября 2026 г. в 13:28 UTCresolved

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

4. 23 октября 2026 г. в 17:27 UTCpostmortem

   ** Описание: ** Flexera One - Управление ИТ-активами - NAM - Задержка обработки запасов после производственной деятельности ** Сроки:** 22 сентября 2026 года, 7:05 вечера ПДТ - 25 сентября 2026 года, 5:30 утра ПДТ ** Резюме инцидента** 24 сентября 2026 года технические команды начали расследование сообщений о задержке обновления запасов, затрагивающих подмножество клиентов, использующих Flexera One IT Asset Management \(ITAM\) в регионе Северной Америки \(NAM\). Хотя файлы инвентаризации успешно загружались и оставались доступными, некоторые клиенты испытывали задержки в обработке этих файлов, что не позволяло отразить последнюю информацию о инвентаризации в приложении. Информация о состоянии маяков, отображаемая в ITAM, также может быть устаревшей для пострадавших клиентов. Обработка запасов продолжалась нормально для других клиентов. Проблема возникла после производственного выпуска ITAM 2026R1.3 22 сентября 2026 года. Расследование выявило прерывание процесса, ответственного за передачу загруженных кадастровых файлов в службы обработки кадастров ITAM. В то время как затронутые файлы оставались доступными в хранилище, они не пересылались для обработки. Технические группы также наблюдали повышенные ошибки приложений во время расследования, хотя эти ошибки не были окончательно установлены в качестве причины прерывания. Технические группы выполнили целенаправленный перезапуск затронутого компонента обслуживания, восстановив передачу файлов инвентаризации и позволив возобновить обработку для ранее затронутых клиентов. Дополнительная диагностическая регистрация позволила поддержать дальнейшее исследование. Однако в ходе перерыва накопилось значительное число накопившихся кадастровых файлов, и для их обработки потребовалось дополнительное время. После восстановления обработки технические группы продолжали следить за инвентаризацией и накопленным отставанием. К пятнице, 25 сентября 2026 года, примерно в 5:30 утра по местному времени, связанное с инцидентом отставание вернулось к нормальному рабочему уровню, подтвердив восстановление обработки запасов. **Корневая причина** Инцидент был вызван перерывом в процессе обработки запасов после деятельности по выпуску продукции ITAM 2026R1.3 в регионе NAM. Несмотря на то, что файлы инвентаризации были успешно загружены и оставались доступными в хранилище, компонент, ответственный за пересылку этих файлов на обработку ITAM, прекратил передачу данных инвентаризации для подмножества клиентов. В результате затронутые файлы инвентаризации не обрабатывались, что задерживало обновление инвентарных запасов. Проблема затронула не всех клиентов, поскольку обработка запасов продолжалась обычно для других организаций. Исследование выявило повышенные ошибки и поведение приложений, указывающие на то, что затронутый компонент обработки не восстанавливался, как ожидалось. Точное техническое состояние, ответственное за частичное прерывание, остается под следствием. Целевой перезапуск затронутого компонента обслуживания восстановил обработку запасов для пострадавших клиентов. Накопленное отставание было впоследствии обработано, что позволило обновить запасы до нормального уровня. ** Меры по восстановлению** В ходе реагирования на инцидент были приняты следующие меры: 1. ** Расследование инцидента инициировано: ** Технические группы изучили сообщения о задержках с обновлением запасов, затрагивающих подгруппу клиентов в регионе Движения неприсоединения, и рассмотрели рабочий процесс обработки запасов для определения масштабов проблемы. 2. ** Перебои в обработке информации Выявлены: ** Расследование подтвердило, что загруженные файлы инвентаря были доступны в хранилище, но не были направлены в службы обработки для пострадавших клиентов. 3.** Поврежденный компонент обслуживания:** Целевой перезапуск затронутого компонента обслуживания восстановил передачу файлов инвентаризации и позволил возобновить обработку для ранее затронутых клиентов. 4.**Дополнительная возможность диагностики:** Дополнительная регистрация позволила получить дополнительную техническую информацию и поддержать продолжающееся расследование основного прерывания обработки. 5. ** Мониторинг возврата к учетным записям: ** Технические группы следили за накопленным запасом запасов после восстановления обработки и подтвердили, что файлы запасов успешно обрабатываются. 6 ** Восстановление услуг подтверждено: ** Технические группы подтвердили, что к 25 сентября количество задержек, связанных с инцидентами, восстановилось до нормального уровня и что обработка запасов остается стабильной. Будущие превентивные меры** После инцидента мы провели ретроспективу, чтобы проанализировать частичный сбой в обработке запасов, существующую архитектуру доставки запасов, доступную диагностическую информацию и возможности повышения надежности обработки и видимости сбоев. В настоящее время осуществляются следующие корректирующие действия и мероприятия по улучшению: 1. ** Улучшение архитектуры обработки данных: ** Планируется упростить интеграцию обработки запасов, позволяя ITAM извлекать загруженные файлы запасов непосредственно из уровня хранения, а не полагаться на существующую промежуточную службу пересылки. Это изменение устранит дополнительную зависимость от пути обработки и обеспечит больший контроль над обработкой, управлением отставанием, пропускной способностью и восстановлением. 2.** Улучшенная диагностика:** Диагностическая регистрация и телеметрия, необходимые для захвата соответствующего состояния обслуживания во время частичного сбоя в обработке запасов, будут оценены и усилены в зависимости от обстоятельств. Это обеспечит улучшенную техническую информацию для поддержки определения первопричин, если подобное состояние повторяется.

Автоматический перевод официального обновления инцидента.

1. 24 сентября 2026 г. в 14:08 UTCinvestigating

   Мы расследуем проблему, затрагивающую подмножество клиентов, использующих Flexera One IT Asset Management (ITAM) в регионе NAM. Пострадавшие клиенты могут испытывать проблемы с навигацией, включая элементы меню, которые не видны в интерфейсе ITAM, что приводит к ограниченному доступу к некоторым функциям. Приоритет: P2 Реставрационная деятельность: Наши технические команды активно изучают этот вопрос и работают над восстановлением полной функциональности. Мы будем продолжать предоставлять обновления по мере поступления дополнительной информации.

2. 24 сентября 2026 г. в 15:44 UTCinvestigating

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

3. 24 сентября 2026 г. в 17:48 UTCinvestigating

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

4. 24 сентября 2026 г. в 18:39 UTCmonitoring

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

5. 24 сентября 2026 г. в 20:33 UTCresolved

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

6. 8 октября 2026 г. в 11:23 UTCpostmortem

   **Описание: ** Flexera One - Управление ИТ-активами - NAM - Меню Не Загрузка ** Сроки: ** 24 сентября 2026 года, 5:27 утра PDT - 24 сентября 2026 года, 10:48 утра PDT ** Резюме инцидента** 24 сентября 2026 года клиенты, использующие Flexera One IT Asset Management \(ITAM\) в регионе Северной Америки, испытывали периодические проблемы с загрузкой элементов меню приложений и доступом к частям функциональности ITAM. Некоторые клиенты сталкивались с частично загруженными или отсутствующими меню, сообщениями об ошибках и непоследовательным поведением приложений. Технические команды исследовали проблему в приложениях и службах поддержки и выявили ненормальное использование соединения в компонентах, поддерживающих функциональность ITAM. По мере исчерпания доступной емкости подключения некоторые запросы приложений больше не могли успешно выполняться, что приводило к сбоям, связанным с аутентификацией, и мешало загружать части функциональности ITAM. Служба начала восстанавливаться примерно в 10:46 утра по PDT, прежде чем было завершено развертывание корректирующего исправления. Последние связанные с этим ошибки приложения были зафиксированы в 10:48 утра по PDT. Технические команды продолжали исследовать основную причину при мониторинге окружающей среды и проверке функциональности клиентов. Анализ после инцидента показал, что службы приложений на затронутых серверах возобновили работу, выпустив накопленные соединения и позволив устанавливать новые соединения. Корректирующее исправление было впоследствии развернуто в качестве превентивной меры для устранения поведения при работе с подключением, в то время как расследование основной причины продолжалось. После непрерывного мониторинга и проверки клиентов технические команды подтвердили, что функциональность ITAM вернулась к нормальной работе. **Корневая причина** Инцидент был вызван проблемой управления подключением, введенной во время выпуска ITAM 2026 R1.3. Изменение потока аутентификации приложений привело к тому, что новые служебные соединения создавались неоднократно, а не повторно. Со временем эти соединения накопили и исчерпали доступную емкость соединения в затронутых компонентах приложения. Как только этот потенциал будет исчерпан, новые запросы на подачу заявок не смогут быть успешно удовлетворены. Это привело к сбоям, связанным с аутентификацией, и предотвратило загрузку части функциональности ITAM, что привело к отсутствию пунктов меню, сообщений об ошибках и периодической потере доступа для пострадавших клиентов. Исправление этого поведения уже было создано и включено в план развертывания релиза до развертывания Production. Первоначально исправление было предназначено для среды проверки, поскольку производство еще не было модернизировано. Предполагалось, что он будет применяться для производства в рамках выпуска R1.3, но он не был применен во время развертывания производства. В результате, исправление управления соединением не было сделано, когда выпуск вышел в эфир. ** Меры по восстановлению** 1.Initiated Incident Investigation: Технические команды исследовали ошибки приложения и периодическую потерю функциональности ITAM для определения объема и основной причины. 2. Определение насыщения соединения: Анализ затронутых компонентов приложения выявил ненормальное накопление соединения, которое исчерпало доступную пропускную способность соединения и предотвратило успешное завершение новых запросов приложения. 3. Corrective Hotfix Confirmed: Технические команды идентифицировали существующее исправление, которое исправляло поведение обработки соединений путем повторного использования служебных соединений, а не создания новых соединений для каждого запроса. 4. Corrective Hotfix Deployed: Hotfix был развернут в Производстве в качестве превентивной меры для решения проблемы управления подключением и предотвращения дальнейшего накопления соединения. 5. Service Recovery Validated: Технические команды продолжали отслеживать поведение приложений и проверять функциональность клиентов после восстановления, чтобы подтвердить, что службы ITAM вернулись к нормальной работе. Будущие превентивные меры** После инцидента мы провели ретроспективу, чтобы проанализировать техническую причину, процесс развертывания, возможности мониторинга и факторы, которые способствовали воздействию на клиента. Были завершены или осуществляются следующие меры: 1. Коррекция управления подключением: Корректирующее изменение было реализовано для обеспечения надлежащего повторного использования служебных соединений и предотвращения накопления соединений от истощения имеющихся ресурсов приложения. 2. Проверка развертывания производства: Коррекция управления подключением была развернута и проверена во всех производственных регионах для обеспечения последовательного осуществления. 3.Улучшения процессов выпуска и Hotfix: Процедуры выпуска усиливаются таким образом, что исправления, включенные в планы развертывания выпуска, последовательно назначаются для развертывания производства, включая исправления, первоначально созданные или подтвержденные до обновления производственной среды. 4. Обзор процесса Hotfix: Мы оцениваем улучшения в общем процессе исправления, чтобы уменьшить зависимость от производственных исправлений и еще больше снизить риск требуемых корректирующих изменений, не включенных в будущие выпуски продукции. 5. Enhanced Application Monitoring: Дополнительный мониторинг и оповещение на уровне приложений внедряются для улучшения раннего обнаружения периодических сбоев и ненормальных условий ошибок, прежде чем они приведут к более широкому воздействию на клиента.

Автоматический перевод официального обновления инцидента.

1. 24 сентября 2026 г. в 10:11 UTCinvestigating

   Описание инцидента: Мы выявили проблему, затрагивающую обработку запасов в Flexera One IT Asset Management (ITAM) в регионе NAM, затрагивающую подмножество клиентов. В результате некоторые загрузки инвентаря не обрабатываются успешно, в результате чего данные инвентаризации, отображаемые в Flexera One ITAM, задерживаются и не отражают последний загруженный инвентарь. Приоритет: P2 Реставрационная деятельность: Наши технические команды активно исследуют проблему, чтобы определить основную причину и внедрить исправление. Мы продолжаем внимательно следить за ситуацией и будем предоставлять дальнейшие обновления по мере продвижения расследования.

2. 24 сентября 2026 г. в 12:27 UTCinvestigating

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

3. 24 сентября 2026 г. в 14:32 UTCmonitoring

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

4. 24 сентября 2026 г. в 18:42 UTCmonitoring

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

5. 24 сентября 2026 г. в 20:32 UTCresolved

   Этот инцидент был непреднамеренно отмечен как разрешенный с обновлением, предназначенным для отдельного инцидента. Восстановление обработки инвентарных запасов остается под контролем, поскольку оставшееся отставание продолжается. Технические команды продолжают наблюдать успешную обработку файлов и стабильную работу службы. Текущие обновления восстановления и мониторинг отставания будут продолжаться в рамках вновь созданного инцидента: https://status.flexera.com/incidents/vztp63wmxjjb Мы предоставим дальнейшие обновления по мере продвижения процесса восстановления и продолжения проверки восстановления.

6. 23 октября 2026 г. в 17:25 UTCpostmortem

   ** Описание: ** Flexera One - Управление ИТ-активами - NAM - Задержка обработки запасов после производственной деятельности ** Сроки:** 22 сентября 2026 года, 7:05 вечера ПДТ - 25 сентября 2026 года, 5:30 утра ПДТ ** Резюме инцидента** 24 сентября 2026 года технические команды начали расследование сообщений о задержке обновления запасов, затрагивающих подмножество клиентов, использующих Flexera One IT Asset Management \(ITAM\) в регионе Северной Америки \(NAM\). Хотя файлы инвентаризации успешно загружались и оставались доступными, некоторые клиенты испытывали задержки в обработке этих файлов, что не позволяло отразить последнюю информацию о инвентаризации в приложении. Информация о состоянии маяков, отображаемая в ITAM, также может быть устаревшей для пострадавших клиентов. Обработка запасов продолжалась нормально для других клиентов. Проблема возникла после производственного выпуска ITAM 2026R1.3 22 сентября 2026 года. Расследование выявило прерывание процесса, ответственного за передачу загруженных кадастровых файлов в службы обработки кадастров ITAM. В то время как затронутые файлы оставались доступными в хранилище, они не пересылались для обработки. Технические группы также наблюдали повышенные ошибки приложений во время расследования, хотя эти ошибки не были окончательно установлены в качестве причины прерывания. Технические группы выполнили целенаправленный перезапуск затронутого компонента обслуживания, восстановив передачу файлов инвентаризации и позволив возобновить обработку для ранее затронутых клиентов. Дополнительная диагностическая регистрация позволила поддержать дальнейшее исследование. Однако в ходе перерыва накопилось значительное число накопившихся кадастровых файлов, и для их обработки потребовалось дополнительное время. После восстановления обработки технические группы продолжали следить за инвентаризацией и накопленным отставанием. К пятнице, 25 сентября 2026 года, примерно в 5:30 утра по местному времени, связанное с инцидентом отставание вернулось к нормальному рабочему уровню, подтвердив восстановление обработки запасов. **Корневая причина** Инцидент был вызван перерывом в процессе обработки запасов после деятельности по выпуску продукции ITAM 2026R1.3 в регионе NAM. Несмотря на то, что файлы инвентаризации были успешно загружены и оставались доступными в хранилище, компонент, ответственный за пересылку этих файлов на обработку ITAM, прекратил передачу данных инвентаризации для подмножества клиентов. В результате затронутые файлы инвентаризации не обрабатывались, что задерживало обновление инвентарных запасов. Проблема затронула не всех клиентов, поскольку обработка запасов продолжалась обычно для других организаций. Исследование выявило повышенные ошибки и поведение приложений, указывающие на то, что затронутый компонент обработки не восстанавливался, как ожидалось. Точное техническое состояние, ответственное за частичное прерывание, остается под следствием. Целевой перезапуск затронутого компонента обслуживания восстановил обработку запасов для пострадавших клиентов. Накопленное отставание было впоследствии обработано, что позволило обновить запасы до нормального уровня. ** Меры по восстановлению** В ходе реагирования на инцидент были приняты следующие меры: 1. ** Расследование инцидента инициировано: ** Технические группы изучили сообщения о задержках с обновлением запасов, затрагивающих подгруппу клиентов в регионе Движения неприсоединения, и рассмотрели рабочий процесс обработки запасов для определения масштабов проблемы. 2. ** Перебои в обработке информации Выявлены: ** Расследование подтвердило, что загруженные файлы инвентаря были доступны в хранилище, но не были направлены в службы обработки для пострадавших клиентов. 3.** Поврежденный компонент обслуживания:** Целевой перезапуск затронутого компонента обслуживания восстановил передачу файлов инвентаризации и позволил возобновить обработку для ранее затронутых клиентов. 4.**Дополнительная возможность диагностики:** Дополнительная регистрация позволила получить дополнительную техническую информацию и поддержать продолжающееся расследование основного прерывания обработки. 5. ** Мониторинг возврата к учетным записям: ** Технические группы следили за накопленным запасом запасов после восстановления обработки и подтвердили, что файлы запасов успешно обрабатываются. 6 ** Восстановление услуг подтверждено: ** Технические группы подтвердили, что к 25 сентября количество задержек, связанных с инцидентами, восстановилось до нормального уровня и что обработка запасов остается стабильной. Будущие превентивные меры** После инцидента мы провели ретроспективу, чтобы проанализировать частичный сбой в обработке запасов, существующую архитектуру доставки запасов, доступную диагностическую информацию и возможности повышения надежности обработки и видимости сбоев. В настоящее время осуществляются следующие корректирующие действия и мероприятия по улучшению: 1. ** Улучшение архитектуры обработки данных: ** Планируется упростить интеграцию обработки запасов, позволяя ITAM извлекать загруженные файлы запасов непосредственно из уровня хранения, а не полагаться на существующую промежуточную службу пересылки. Это изменение устранит дополнительную зависимость от пути обработки и обеспечит больший контроль над обработкой, управлением отставанием, пропускной способностью и восстановлением. 2.** Улучшенная диагностика:** Диагностическая регистрация и телеметрия, необходимые для захвата соответствующего состояния обслуживания во время частичного сбоя в обработке запасов, будут оценены и усилены в зависимости от обстоятельств. Это обеспечит улучшенную техническую информацию для поддержки определения первопричин, если подобное состояние повторяется.

Автоматический перевод официального обновления инцидента.

1. 23 сентября 2026 г. в 10:05 UTCinvestigating

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

2. 23 сентября 2026 г. в 10:24 UTCmonitoring

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

3. 23 сентября 2026 г. в 11:43 UTCresolved

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

4. 26 октября 2026 г. в 10:40 UTCpostmortem

   **Описание: ** Flexera Один - ЕС - Доступ недоступен ** Временные рамки** * 24 сентября 2026, 2:51 AM PDT до 24 сентября 2026, 3:18 AM PDT * 25 сентября 2026 года, 3:50 утра до 25 сентября 2026 года, 4:30 утра PDT ** Резюме инцидента** 24 сентября 2026 года в 2:51 утра по местному времени клиенты испытывали сбои при входе в систему при попытке получить доступ к среде Flexera One EU Production. Расследование подтвердило деградацию услуг ЕС по управлению идентификацией и доступом, что помешало клиентам получить доступ к платформе. Расследование выявило значительное увеличение подключений к базам данных, связанных с повышенным трафиком от одной организации. Дальнейший анализ показал, что повторные запросы, генерируемые другими службами, также способствовали увеличению нагрузки на службы аутентификации и контроля доступа. В 3:18 утра PDT был восстановлен без прямого технического вмешательства, и платформа вернулась к нормальной работе. 25 сентября 2026 года примерно в 3:50 утра PDT наблюдался очередной рост подключений к базам данных, связанный с повышенным трафиком от той же организации. Повышенная нагрузка продолжалась около 40 минут. В ответ на это автомасштабирование позволило службе управления ресурсами увеличить емкость и повысить стабильность платформы. **Корневая причина** Инцидент был вызван неожиданным увеличением трафика, что вызвало чрезмерный спрос на услуги аутентификации ЕС и связанные с ними подключения к базам данных. Увеличение нагрузки затронуло службы, ответственные за обработку запросов на аутентификацию, что привело к сбоям входа в систему клиентов в производственной среде ЕС. Повторные запросы от других служб к службам аутентификации и контроля доступа также способствовали повышению нагрузки. Кроме того, автоматическое масштабирование не было обеспечено для службы управления ресурсами, что ограничивало ее способность динамически увеличивать емкость в ответ на более высокий спрос. Пробелы в активном мониторинге и оповещении также ограничивали возможность выявления деградации до того, как клиенты столкнулись с сбоями доступа. ** Меры по восстановлению** Наши команды выполнили нижеприведенные действия по восстановлению сервиса в норме: Инцидент 24 сентября разрешился без прямого инженерного вмешательства, а функциональность входа в систему была восстановлена в 3:18 утра по местному времени. 25 сентября автомасштабирование позволило службе управления ресурсами увеличить пропускную способность в ответ на повышенный спрос. Группа продолжила мониторинг подключений к базам данных и состояния обслуживания для оценки стабильности платформы. Будущие превентивные меры** Выявлены и разрабатываются следующие меры для снижения вероятности повторения и повышения устойчивости обслуживания: Автоматическое масштабирование: пересмотр конфигурации автомасштабирования для службы управления ресурсами во всех производственных регионах, чтобы обеспечить адаптацию мощности к изменениям рабочей нагрузки. * Управление пропускной способностью базы данных: Просмотрите настройки пула подключений к базе данных и убедитесь, что масштабирование услуг остается в пределах доступной емкости подключения к базе данных. * Упреждающий мониторинг и оповещение: обзор и введение оповещений о ненормальном росте подключения к базе данных, насыщении пула соединений, задержке обслуживания, частоте ошибок и использовании ресурсов. Мониторинг трафика: улучшение видимости структур трафика на уровне организации для выявления необычных всплесков запросов, прежде чем они повлияют на других клиентов. Управление трафиком: Оцените соответствующие меры контроля за ограничением скорости и дросселированием, чтобы предотвратить чрезмерное движение от одной организации, влияющее на доступность платформы. * Тестирование нагрузки и емкости: Проведение нагрузочного тестирования с использованием моделей трафика, представляющих инцидент, для проверки производительности обслуживания и емкости базы данных при повышенном спросе.

Автоматический перевод официального обновления инцидента.

1. 23 сентября 2026 г. в 06:51 UTCinvestigating

   В настоящее время мы расследуем проблему, затрагивающую среду производства Flexera One IT Asset Management (ITAM) в Северной Америке, которая остается недоступной из-за планового технического обслуживания, выходящего за рамки запланированного окна технического обслуживания. Деятельность по техническому обслуживанию продолжается, пока завершается восстановление базы данных. Приоритет: P1 Реставрационная деятельность: Наши технические команды активно работают над тем, чтобы завершить оставшуюся деятельность по техническому обслуживанию и восстановить обслуживание как можно быстрее. ETA для восстановления базы данных составляет около 2 часов. Наши команды внимательно следят за прогрессом и предоставят дополнительную информацию по мере их поступления.

2. 23 сентября 2026 г. в 09:15 UTCinvestigating

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

3. 23 сентября 2026 г. в 11:47 UTCmonitoring

   Модернизация была успешно завершена. В настоящее время наши команды работают над восстановлением услуг и проведением проверки после развертывания.

4. 23 сентября 2026 г. в 13:02 UTCmonitoring

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

5. 23 сентября 2026 г. в 15:57 UTCresolved

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

6. 30 сентября 2026 г. в 16:02 UTCpostmortem

   ** Описание: Flexera One - Управление ИТ-активами - Северная Америка - Недоступность услуг после 2026R1.3 техническое обслуживание ** Сроки:** 22 сентября 2026, 9:00 PM PDT - 23 сентября 2026, 5:47 AM PDT ** Резюме инцидента** 22 сентября 2026 года Flexera провела запланированный выпуск 2026R1.3 для Flexera One IT Asset Management в регионе Северной Америки. Модернизация успешно прошла через подавляющее большинство баз данных в окружающей среде. Однако, когда окно планового технического обслуживания завершилось в 9:00 вечера по местному времени, требуемая операция по миграции базы данных все еще продолжалась. Поскольку производственная среда не могла быть восстановлена до завершения миграции, управление ИТ-активами оставалось недоступным после запланированного периода технического обслуживания. Оставшаяся миграция потребовала восстановления большого индекса базы данных, включающего значительный объем данных. Операция стала критическим путем для завершения выпуска и заняла значительно больше времени, чем ожидалось. После завершения начального этапа индексной обработки база данных по-прежнему нуждается в дополнительной сортировке и создании индексов. Эта работа продолжалась несколько часов и продлила общую продолжительность миграции. В ходе расследования технические группы оценили имеющиеся варианты восстановления, в том числе вопрос о том, может ли затронутая база данных быть временно отделена от миграционного пути, чтобы позволить остальной части окружающей среды вернуться к обслуживанию. В связи с этапом развертывания и дополнительными восстановительными работами, которые потребовались бы при таком подходе, наиболее надежным путем восстановления было бы позволить завершить работу базы данных до восстановления окружающей среды. После завершения миграции базы данных технические группы приступили к восстановлению приложений и вспомогательных услуг. Во время запуска была обнаружена дополнительная проблема восстановления обслуживания, которая требовала ручного вмешательства, прежде чем восстановление могло продолжаться. После восстановления оставшиеся приложения и платформы были успешно восстановлены. Затем технические команды завершили валидацию, подтвердили доступ клиентов и провели расширенный мониторинг для проверки стабильности обслуживания. Воздействие на клиента закончилось 23 сентября 2026 года в 5:47 утра по PDT. **Корневая причина** Отключение было вызвано несоответствием конфигурации индекса базы данных, которое было выявлено во время миграции 2026R1.3, что привело к крупной операции по восстановлению индекса, которая значительно превысила запланированное окно обслуживания. Расследование после инцидента показало, что индекс в базе данных не соответствует структуре базы данных, ожидаемой к текущему выпуску. Индекс ранее был воссоздан с использованием более старого определения, которое не включало последующее изменение дизайна базы данных. В ходе развертывания 2026R1.3 процесс миграции выявил эту разницу и инициировал работу базы данных, необходимую для приведения индекса в соответствие с текущим определением базы данных. Из-за исключительно большого размера набора данных в результате перестройка стала длительной и ресурсоемкой операцией, которая значительно превысила запланированное окно обслуживания. После начала реконструкции оставшаяся продолжительность обработки не может быть надежно предсказана, что затрудняет точную оценку завершения, пока операция продолжается. ** Меры по восстановлению** В ходе реагирования на инцидент были приняты следующие меры: * Index Rebuild Monitored: восстановление индекса и оставшиеся мероприятия по обновлению базы данных постоянно контролировались по завершении. Оценка вариантов восстановления: были оценены доступные подходы к восстановлению для определения наиболее безопасного и надежного пути возвращения производственной среды в эксплуатацию. Обновление базы данных завершено: восстановление индекса и оставшиеся мероприятия по обновлению базы данных были завершены до начала восстановления приложений. Восстановление служб поддержки и приложений: Восстановление служб поддержки и приложений. Целевые действия по восстановлению были выполнены, когда возникла дополнительная проблема запуска службы. * Восстановление обслуживания: был подтвержден доступ клиентов и функциональность приложения, была рассмотрена оставшаяся фоновая обработка и завершен расширенный мониторинг для проверки стабильной работы. Будущие превентивные меры** Flexera признает важность и продолжительность этого отключения и его влияние на клиентов в регионе Северной Америки. Полный анализ первопричин и кросс-функциональная ретроспектива были завершены, и в рамках текущих усилий по улучшению были определены следующие профилактические меры: 1.Процедура проверки баз данных: Технические команды оценивают, как пересматриваются и поддерживаются процедуры восстановления баз данных, чтобы они оставались в соответствии с текущими требованиями к продукту по мере развития платформы. 2. Проверка перед развертыванием: оцениваются процессы валидации высвобождения для определения того, как можно выявить и оценить неожиданные различия в конфигурации базы данных до начала технического обслуживания производства. 3. High-Impact Operation Assessment: Технические группы оценивают, как можно определить потенциально длительные или ресурсоемкие операции с базами данных во время подготовки к выпуску, чтобы их ожидаемая продолжительность и оперативное воздействие могли быть лучше поняты до развертывания. 4.Планирование готовности к выпуску и восстановления: Практика готовности к выпуску и планирования восстановления пересматривается в целях улучшения видимости мероприятий, которые могут существенно повлиять на продолжительность развертывания и сроки восстановления обслуживания. Предоставление надежных и устойчивых услуг остается приоритетом. Выводы, полученные в результате проведенного анализа и ретроспективы первопричин, включаются в технические и оперативные усовершенствования, направленные на снижение вероятности повторения и укрепление планирования и осуществления будущих мероприятий по техническому обслуживанию.

Автоматический перевод официального обновления инцидента.

1. 22 сентября 2026 г. в 05:56 UTCinvestigating

   В настоящее время мы расследуем проблему, затрагивающую подмножество наших клиентов, использующих Snow Atlas в регионе Австралии. Пострадавшие клиенты могут столкнуться с задержками в просмотре последней компьютерной информации, и прием данных также может быть затронут. Приоритет: P2 Реставрационная деятельность: Была выявлена и решена более ранняя проблема, связанная с DNS. Однако сейчас наблюдаются дополнительные ошибки. Наши технические команды активно изучают эти ошибки, чтобы определить основную причину и восстановить нормальную обработку. Мы будем продолжать оценивать влияние и предоставлять дальнейшие обновления по мере поступления дополнительной информации.

2. 22 сентября 2026 г. в 07:19 UTCinvestigating

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

3. 22 сентября 2026 г. в 10:15 UTCmonitoring

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

4. 23 сентября 2026 г. в 07:05 UTCresolved

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

5. 13 октября 2026 г. в 12:49 UTCpostmortem

   ** Описание:** Снежный атлас- APAC - Задержка приема и обработки данных ** Сроки:** 21 сентября 2026 года, 5:48 вечера PDT до 22 сентября 2026 года, 3:15 утра PDT ** Резюме инцидента** В понедельник, 21 сентября 2026 года, в 5:48 вечера PDT, проблема затронула нескольких арендаторов Snow Atlas в регионе Восточная Австралия, что привело к задержкам в обновлении инвентарных данных. Пострадавшие клиенты испытали устаревшую информацию об устройстве на странице Компьютеры, в то время как Расширители снега отображали статус «Бег с ошибками». Ошибки также наблюдались во время приема данных. Расследование выявило устаревшую запись DNS, связанную с ранее выведенной из эксплуатации инфраструктурой в юго-восточном регионе Австралии. Эта запись мешала подключению к окружающей среде на востоке Австралии, предотвращая обработку данных о запасах. Устаревшая запись DNS была удалена, что позволило трафику достичь правильной конечной точки и позволило возобновить обновления сканирования инвентаря. После изменения количество инвентарных запасов начало прогрессировать, и статусы затронутых услуг связи впоследствии вернулись к норме 22 сентября 2026 года в 3:15 утра по местному времени. После длительного периода ночного мониторинга услуги связи оставались стабильными, и проблема была объявлена решенной 23 сентября в 12:05 утра по местному времени. О дальнейших проблемах не сообщалось, а ранее использовавшаяся инфраструктура Юго-Восточной Австралии была полностью выведена из эксплуатации. **Корневая причина** Инцидент был вызван устаревшей записью DNS, которая осталась после вывода из эксплуатации инфраструктуры в юго-восточном регионе Австралии. Эта запись направляла трафик от правильной конечной точки для окружающей среды на востоке Австралии, нарушая связь, необходимую для обработки инвентарных данных. В результате обновления запасов задерживались, и пострадавшие клиенты не могли получить последнюю информацию об устройстве. Устаревшая запись была удалена, восстановив подключение к правильной конечной точке и позволив возобновить обработку запасов. ** Меры по восстановлению** Наши команды выполнили нижеприведенные действия по восстановлению сервиса в норме: Выявлена и удалена устаревшая запись DNS, связанная с ранее выведенной из эксплуатации инфраструктурой. Восстановлена связь с правильной конечной точкой Австралии. * Проверено, что обновления сканирования запасов и подсчет запасов прогрессируют. • Мониторинг окружающей среды для подтверждения стабильности обслуживания. * Подтверждено, что состояние услуг связи Snow впоследствии нормализовалось, и никаких дополнительных проблем не было зарегистрировано. Будущие превентивные меры** Проверка очистки записей DNS во время вывода из эксплуатации инфраструктуры для обеспечения удаления устаревших записей. * Улучшить проверку после вывода из эксплуатации для выявления записей, которые остаются после удаления ресурсов.

Автоматический перевод официального обновления инцидента.

1. 18 сентября 2026 г. в 13:03 UTCinvestigating

   Описание инцидента: Мы расследуем проблему, затрагивающую обработку данных о запасах в производственных средах ЕС и APAC. Клиенты могут наблюдать задержки в обновлении запасов, в результате чего данные о запасах не отражают самую последнюю активность импорта. Приоритет: P2 Реставрационная деятельность: Наши технические команды активно исследуют проблему, проверяют масштабы воздействия и работают с соответствующими зависимостями для восстановления нормальной обработки запасов. Дальнейшие обновления будут предоставляться по мере поступления дополнительной информации.

2. 18 сентября 2026 г. в 13:50 UTCidentified

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

3. 18 сентября 2026 г. в 14:34 UTCidentified

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

4. 18 сентября 2026 г. в 14:39 UTCmonitoring

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

5. 18 сентября 2026 г. в 18:52 UTCmonitoring

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

6. 18 сентября 2026 г. в 19:49 UTCmonitoring

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

7. 18 сентября 2026 г. в 21:55 UTCmonitoring

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

8. 19 сентября 2026 г. в 11:07 UTCmonitoring

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

9. 19 сентября 2026 г. в 19:09 UTCmonitoring

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

10. 20 сентября 2026 г. в 19:55 UTCresolved

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

11. 23 октября 2026 г. в 17:20 UTCpostmortem

    ** Описание: ** Flexera One - Управление ИТ-активами - ЕС и APAC - Задержка обработки запасов после проблемы конфигурации развертывания ** Сроки:** 16 сентября 2026, 2:00 PM PDT - 20 сентября 2026, 9:52 AM PDT ** Резюме инцидента** В пятницу, 18 сентября 2026 года, технические команды начали расследование сообщений о задержке обновления запасов, затрагивающих клиентов Flexera One IT Asset Management в Европе и Азиатско-Тихоокеанском регионе. Обновленная информация о запасах не была отражена в заявке, и некоторые клиенты сообщили, что их последние доступные данные о запасах остались от 16 сентября. Проблема затронула не общую доступность платформы ITAM, а обработку запасов. Первоначальный анализ показал, что услуги по обработке инвентарных запасов выглядят здоровыми, но поступающие файлы инвентарных запасов не проходят через ожидаемый рабочий процесс обработки. Дальнейшее расследование проследило прерывание до развертывания, выполненного 16 сентября, в ходе которого проблема конфигурации затронула службы, ответственные за обработку данных инвентаризации. Технические группы определили и исправили конфигурацию развертывания, что позволило возобновить обработку запасов. Однако в ходе перерыва накопилось значительное число накопившихся кадастровых файлов, и для их обработки потребовалось дополнительное время. Обработка запасов восстановлена сначала в APAC, где накопленное отставание было очищено 18 сентября примерно в 12:21 вечера по местному времени. Регион ЕС потребовал дополнительного времени восстановления из-за большого количества незавершенных файлов. Технические группы скорректировали параметры емкости обработки и продолжали отслеживать отставание по мере обработки файлов инвентаризации. Оставшееся отставание от ЕС было полностью очищено 20 сентября примерно в 9:52 утра по местному времени. Последующий мониторинг подтвердил, что обработка запасов вернулась к нормальному уровню эксплуатации. **Корневая причина** Инцидент был вызван проблемой конфигурации развертывания, введенной во время обновления служб обработки запасов 16 сентября. На момент развертывания инфраструктура по обработке запасов осуществляла переход между прикладными средами, при этом различные службы должны были оставаться активными в каждой среде в зависимости от региона. Это увеличило сложность поддержания правильной производственной конфигурации, а требуемая конфигурация обслуживания не была правильно сохранена во время развертывания. В результате в регионах ЕС и АТР был прерван рабочий процесс по обработке кадастров, что не позволило обрабатывать поступающие кадастровые файлы и задерживать обновление кадастровых данных. После того, как конфигурация была исправлена, обработка запасов возобновилась, а накопленное отставание потребовало дополнительного времени для обработки до полного восстановления нормальных операционных уровней. ** Меры по восстановлению** В ходе реагирования на инцидент были приняты следующие меры: 1. ** Расследование инцидента инициировано: ** Технические группы изучили сообщения о задержках с обновлением запасов в регионах ЕС и АТР и рассмотрели рабочий процесс обработки запасов, чтобы определить источник прерывания. 2. ** Вопрос конфигурации развертывания: ** Расследование проследило прерывание развертывания 16 сентября и выявило неправильную конфигурацию службы, влияющую на обработку запасов в пострадавших регионах. 3.** Исправлена конфигурация продукта:** Необходимые обновления конфигурации были применены для восстановления затронутых услуг по обработке запасов, что позволило входящие файлы запасов возобновить обработку. 4. ** Резервное восстановление инвентаря инициировано: ** Технические группы контролировали накопленные файлы инвентаризации и скорректировали имеющиеся ресурсы обработки для поддержки восстановления отставания после восстановления рабочего процесса обработки. 5. ** Оптимизированная пропускная способность: ** Во время восстановления ЕС технические группы определили ограничения пропускной способности в связи с увеличением рабочей нагрузки и скорректировали параллельную обработку для повышения пропускной способности при сохранении стабильности обслуживания. 6 ** Восстановление услуг подтверждено: ** Технические команды подтвердили, что отставание от APAC было устранено 18 сентября, а 20 сентября последовало полное восстановление отставания от ЕС. Продолжение мониторинга подтвердило, что обработка инвентарных запасов вернулась к нормальному рабочему уровню. Будущие превентивные меры** После инцидента мы провели ретроспективу для рассмотрения проблемы конфигурации развертывания, различий между средами приложений, возможностей мониторинга обработки запасов и возможностей для улучшения проверки развертывания и оперативной видимости. Были завершены или осуществляются следующие корректирующие действия и мероприятия по улучшению: 1.**Региональное управление конфигурацией сервиса:** Для документирования и поддержания требуемых конфигураций услуг в различных средах развертывания был внедрен региональный список конфигурации услуг, что снижает риск несоответствий конфигурации во время будущих выпусков. 2.** Улучшения валидации развертывания:** Был составлен контрольный список развертывания для проверки того, что требуемые услуги по обработке инвентарных запасов выполняются в соответствующих условиях в ходе развертывания. 3.** Усовершенствованный мониторинг обработки инвентарных запасов:** Были осуществлены дополнительные мониторинг и оповещение для выявления перерывов в обработке инвентарных запасов и обеспечения более быстрого расследования и восстановления. 4.** Улучшенная видимость ошибки обработки:** Были внедрены панели мониторинга для обеспечения большей видимости ненормальных моделей реагирования приложений, включая ошибки, связанные с производительностью. Эти улучшения уже способствовали более раннему обнаружению и восстановлению во время последующих проблем с обработкой. 5**Упрощение производственной среды:** Текущая работа по консолидации модели развертывания уменьшит операционную сложность, связанную с поддержанием различных конфигураций обслуживания в разных средах и регионах, что поможет снизить риск аналогичных прерываний обработки, связанных с конфигурацией.

Автоматический перевод официального обновления инцидента.

1. 16 сентября 2026 г. в 09:04 UTCidentified

   Описание инцидента: В настоящее время мы сталкиваемся с проблемой, затрагивающей сайт сообщества Flexera. Из-за продолжающегося отключения, влияющего на стороннего поставщика услуг, клиенты могут быть не в состоянии получить доступ к порталу сообщества Flexera или могут испытывать прерывистое и ненадежное поведение. Кроме того, клиенты могут быть не в состоянии создавать, обновлять или взаимодействовать с кейсами поддержки через сайт Сообщества. Электронные письма, отправленные на [email protected] в течение этого периода, не могут быть получены или обработаны до устранения основного сбоя. Отключение стороннего поставщика услуг также влияет на возможность проактивного мониторинга для групп поддержки Spot для обнаружения любых проблем с клиентской средой, а также виджета чат-бота внутри консоли Spot. Приоритет: P3 Деятельность по восстановлению: Наши технические команды активно следят за ситуацией и работают со сторонним поставщиком для отслеживания усилий по восстановлению. Мы будем продолжать оценивать влияние клиентов и предоставлять дальнейшие обновления по мере поступления дополнительной информации.

2. 16 сентября 2026 г. в 12:31 UTCidentified

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

3. 16 сентября 2026 г. в 19:25 UTCmonitoring

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

4. 16 сентября 2026 г. в 22:00 UTCmonitoring

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

5. 17 сентября 2026 г. в 11:01 UTCresolved

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

6. 30 сентября 2026 г. в 12:30 UTCpostmortem

   **Описание:** Услуга Flexera Community недоступна ** Сроки:** 16 сентября 2026 года, 12:50 утра PDT до 16 сентября 2026 года, 8:26 утра PDT ** Резюме инцидента** 16 сентября 2026 года в 12:50 утра PDT Flexera выявила проблему, затрагивающую доступность и надежность сайта сообщества Flexera из-за сбоя, затрагивающего внешнего поставщика услуг, поддерживающего платформу сообщества. Во время инцидента клиенты, возможно, не смогли получить доступ к сообществу Flexera, поднять или управлять делами поддержки или получить ответы на существующие дела через сообщество. Электронные письма, отправленные на [email protected], также могут быть задержаны или не обработаны во время сбоя. Проблема также затронула функциональность чатбота в консоли Spot, которая зависит от затронутых сервисов. Кроме того, отключение затронуло возможности проактивного мониторинга, используемые командами Spot Support для выявления определенных проблем клиентской среды, которые зависят от уведомлений об услугах. Впоследствии поставщик услуг подтвердил исправление и начал развертывать его в пострадавших случаях по регионам. По мере развертывания мер по смягчению последствий службы постепенно возвращались к нормальной работе. После развертывания сервисная телеметрия оставалась здоровой во всех средах, ориентированных на клиента. Проверка подтвердила, что функциональность Flexera Community и Spot chatbot работает нормально. Инцидент с провайдером был впоследствии объявлен урегулированным, и Flexera завершила окончательную проверку и закрыла инцидент. **Корневая причина** Инцидент был вызван сбоем, повлиявшим на услуги внешнего поставщика услуг, которые поддерживают сообщество Flexera и связанную с ним функциональность. Перебои в обслуживании повлияли на доступность и надежность платформы Сообщества и связанные с ней интеграции, что привело к временному нарушению функциональности корпуса обслуживания клиентов и связанных с ним возможностей Spot. ** Меры по восстановлению** * Исправление поставщика: внешний поставщик услуг проверил и развернул исправление в пострадавших случаях. Проверка сервиса: команды Flexera отслеживали сообщество, функциональность чат-ботов и связанные с ними услуги по мере развертывания восстановления. Мониторинг восстановления: здоровье и функциональность службы контролировались для подтверждения стабильности после восстановления. Закрытие инцидента: После того, как основная проблема провайдера была решена и Flexera завершила проверку, инцидент был закрыт. Будущие превентивные меры** Улучшенный мониторинг зависимостей: продолжайте мониторинг критических внешних зависимостей, которые поддерживают услуги, ориентированные на клиента. Оценка воздействия на клиента: продолжайте оценивать влияние внешних сбоев в работе интегрированных сервисов Flexera, включая Community, управление случаями поддержки и функциональность Spot. Мониторинг после инцидента: Продолжить мониторинг остаточного воздействия на клиента после восстановления внешних услуг.

Автоматический перевод официального обновления инцидента.

1. 15 сентября 2026 г. в 23:05 UTCinvestigating

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

2. 16 сентября 2026 г. в 06:16 UTCmonitoring

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

3. 16 сентября 2026 г. в 08:24 UTCresolved

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

4. 12 октября 2026 г. в 12:02 UTCpostmortem

   ** Описание** Flexera - EU - Policies/Automation Unavailable ** Сроки:** 15 сентября 2026 года, 3:50 вечера PDT до 16 сентября 2026 года, 1:22 утра PDT ** Резюме инцидента** 15 сентября 2026 года, в 3:50 вечера, модернизация инфраструктуры, поддерживающая автоматизацию в производственной среде ЕС, привела к нарушению сетевого подключения, затрагивающему политику и автоматизацию. Клиенты испытывали трудности с просмотром политик в пользовательском интерфейсе, а связанные с политикой операции провалились. Исследование выявило неожиданное поведение устаревшего сетевого компонента. Это нарушило связь, требуемую затронутыми службами. Команда определила вовлеченный компонент и вывела необходимый ресурс в сеть, восстановив сетевое подключение. Основной вопрос был решен 15 сентября в 10:13 вечера ПДТ. После этого команда продолжила мониторинг восстановления сервиса и обработки накопившегося в ходе сбоя отставания. После того, как обработка отставания прошла, как ожидалось, и стабильность обслуживания была подтверждена, инцидент был объявлен полностью восстановлен 16 сентября 2026 года в 1:22 утра по местному времени. Воздействие было ограничено производственной средой ЕС. **Корневая причина** Инцидент был вызван неожиданным поведением устаревшего сетевого компонента во время модернизации инфраструктуры автоматизации в регионе ЕС. Это нарушило сетевое подключение, требуемое политикой и автоматизацией, что привело к недоступности услуг и сбоям в функциональности, связанной с политикой. ** Меры по восстановлению** Наши команды выполнили нижеприведенные действия по восстановлению сервиса в норме: Восстановление подключений: Выявлена унаследованная составляющая и приведен необходимый ресурс в Интернете для восстановления сетевого подключения. Восстановление обслуживания: Восстановление подключения и решение основной проблемы, затрагивающей политику и автоматизацию. Обработка бэклогов: отслеживал накопленный бэклог по мере восстановления обработки после восстановления обслуживания. Валидация после восстановления: Подтверждена стабильность обслуживания и проверена, что обработка отставания продвигается, как ожидалось, прежде чем объявить инцидент полностью восстановленным. Будущие превентивные меры** Миграционное планирование: соответствующая миграция в США была перенесена с более длинным окном обслуживания, чтобы обеспечить дополнительное время для устранения неполадок и восстановления. Замена устаревшего компонента: устаревший компонент заменяется в рамках усилий по модернизации инфраструктуры. Как только замена будет завершена, эта специфическая зависимость от наследия будет устранена во всех средах.

Автоматический перевод официального обновления инцидента.