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

1. 15 октября 2026 г. в 09:44 UTCinvestigating

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

2. 15 октября 2026 г. в 09:58 UTCmonitoring

   Услуги стабилизировались, и Phrase TMS в регионе ЕС теперь работает нормально. Мы продолжаем следить за ситуацией.

3. 15 октября 2026 г. в 10:24 UTCresolved

   Этот инцидент был урегулирован.

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

1. 23 сентября 2026 г. в 08:48 UTCinvestigating

   Некоторые пользователи испытывают проблемы с доступом к Phrase TMS.

2. 23 сентября 2026 г. в 08:58 UTCidentified

   Этот вопрос был определен, и в настоящее время осуществляется исправление.

3. 23 сентября 2026 г. в 09:28 UTCmonitoring

   Это исправление реализовано, и мы следим за результатами. Фраза TMS теперь доступна без каких-либо дополнительных проблем.

4. 23 сентября 2026 г. в 10:03 UTCresolved

   Этот инцидент был урегулирован.

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

   ##Введение Мы хотели бы поделиться подробностями об инциденте, который повлиял на доступ к Phrase TMS 23 сентября 2026 года. Между 9:02 и 11:27 по восточному времени пользователи, открывающие Phrase TMS с платформы Phrase, не смогли завершить вход. Они либо попали в цикл перенаправления, либо вернулись на страницу входа в систему Phrase TMS с ошибкой входа. Пользователи, у которых уже была активная сессия Phrase TMS, не пострадали, и данные клиентов не были потеряны или изменены. Во время инцидента вход в платформу Phrase продолжал работать как с паролем, так и с одним входом. Таким образом, вход с паролем непосредственно на странице входа в Phrase TMS. Этот вскрытие объясняет, что произошло, как это было решено, и что мы делаем, чтобы предотвратить это снова. ##Время ** 23 сентября 2026 года в 9:02 утра по восточному времени** Обновление веб-приложения Phrase TMS вышло в производство. Он включал в себя улучшение безопасности того, как входной поток обрабатывает перенаправления после входа в систему. С этого момента пользователи, открывающие Phrase TMS с платформы Phrase, не могли завершить вход. Вскоре после этого вопросы были расследованы внутри страны. ** 23 сентября 2026 года в 10:59 утра по восточному времени** Обновление от 9:02 AM CEST было идентифицировано как причина, и мы начали готовить откат. ** 23 сентября 2026 года в 11:13 AM CEST** Откат был проверен в нашей тестовой среде, и началось развертывание в производство. ** 23 сентября 2026 года в 11:27 AM CEST** Откат был вживую во всех производственных регионах. Воздействие на клиента закончилось. 23 сентября 2026 года в 11:28 AM CEST** – Мы подтвердили, что регистрация на Phrase TMS от Phrase Platform снова сработала. ** 23 сентября 2026 года в 12:04 вечера CEST** Инцидент был отмечен как разрешенный на нашей странице статуса. ##Коренная причина Инцидент был вызван улучшением безопасности веб-приложения Phrase TMS. Его целью было убедиться, что пользователи отправляются только в доверенные пункты назначения после входа в систему. Для этого веб-приложение принимает только перенаправления на сам веб-адрес Phrase TMS. Однако, когда пользователь открывает Phrase TMS с платформы Phrase, процесс входа законно перемещает пользователя между различными веб-адресами Phrase. Наши серверы уже проверяют каждый из этих перенаправлений по списку доверенных доменов Phrase и разрешают их. Новая проверка в базовом приложении TMS была более строгой, чем проверка на стороне сервера. В результате законные перенаправления были заменены на стартовую страницу Phrase TMS, которая снова начала процесс входа в систему. Пользователи либо неоднократно проходили через вход в систему, либо возвращались на страницу входа в систему Phrase TMS с ошибкой. Во время инцидента вход в платформу Phrase продолжал работать как с паролем, так и с одним входом. Таким образом, вход с паролем непосредственно на странице входа в Phrase TMS. Сбой произошел на том этапе, когда пользователь переходит с платформы Phrase на Phrase TMS. Из-за этого некоторые пострадавшие пользователи сообщили о проблеме как о проблеме с паролем: они успешно ввели свои учетные данные, но затем были отправлены обратно на экран входа в систему. ## Меры по предотвращению рецидивов 1. **Перемены откатились** Обновление, вызвавшее проблему, было отменено во всех производственных регионах в 11:27 по восточному времени, что восстановило нормальную регистрацию. 2. **Непрерывный контроль входа в систему** – Мы добавляем автоматизированные проверки, которые регулярно проводятся во всех производственных регионах и в нашей тестовой среде. Каждая проверка выполняет полный вход с платформы Phrase в Phrase TMS и немедленно предупреждает наших инженеров по вызову, если он выйдет из строя. Прежде чем полагаться на них, мы подтвердим, что эти проверки выявляют точный сбой, который произошел в этом инциденте.

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

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

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

2. 10 сентября 2026 г. в 05:34 UTCmonitoring

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

3. 10 сентября 2026 г. в 06:03 UTCresolved

   Мы рады подтвердить, что проблема синхронизации webhook между Phrase Strings и Phrase TMS была решена и проверена как полностью работоспособная, в том числе для клиентов центров обработки данных США. Сейчас этот инцидент закрыт.

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

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

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

2. 1 сентября 2026 г. в 15:00 UTCinvestigating

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

3. 1 сентября 2026 г. в 15:34 UTCmonitoring

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

4. 1 сентября 2026 г. в 16:23 UTCresolved

   Проблема решена, и производительность стабильна.

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

1. 31 августа 2026 г. в 15:06 UTCinvestigating

   В настоящее время мы испытываем периодические ошибки при общении с Gengo, одним из наших сторонних поставщиков переводов. Это вызывает тайм-ауты и 502 ошибки при расчете цен и подаче заказов на переводы, направляемые через Gengo, что влияет как на центры обработки данных в ЕС, так и в США. Гэнго подтвердил этот вопрос и ведет расследование.

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

   Гэнго решил основную проблему с их стороны. Расчеты цен и заявки на перевод в Gengo снова работают.

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

1. 31 августа 2026 г. в 13:11 UTCinvestigating

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

2. 31 августа 2026 г. в 13:22 UTCinvestigating

   Мы продолжаем расследование этого вопроса.

3. 31 августа 2026 г. в 13:46 UTCidentified

   Этот вопрос был определен, и в настоящее время осуществляется исправление.

4. 31 августа 2026 г. в 16:02 UTCmonitoring

   Реализовано исправление, и мы отслеживаем результаты.

5. 31 августа 2026 г. в 16:53 UTCresolved

   Вопрос решен.

6. 4 сентября 2026 г. в 08:45 UTCpostmortem

   ##Введение Мы хотели бы поделиться подробностями об инциденте, который затронул Фразу TMS 31 августа 2026 года. Между 2:26 и 5:57 PM CEST некоторые пользователи устаревшей страницы Project не смогли использовать действия Tools-menu, такие как создание или редактирование заданий и запуск анализов, а нажатие на открытие работы не запустило веб-редактор CAT, как ожидалось, вместо этого возвращая пользователей на страницу проекта. Этот вскрытие объясняет, что произошло, как это было решено, и что мы делаем, чтобы предотвратить это снова. ##Время ** 31 августа 2026 года в 2:26 вечера CEST** - Изменение кода достигло производства, содержащего дефект, который нарушил выполнение сценария на странице Проекта для любого пользователя, который его загрузил. ** 31 августа 2026 года в 2:49 вечера CEST** - Первые отчеты о клиентах появились в описании кнопок «Инструменты-меню» как отключенных и не открывающихся в редакторе рабочих мест. 31 августа 2026 года, примерно в 3:10 вечера по восточному времени - Наша команда определила первопричину проблемы. ** 31 августа 2026 года в 3:48 вечера CEST** — исправление основного дефекта было завершено. ** 31 августа 2026 года в 4:04 вечера CEST** - Фиксация была проверена в предпроизводственной среде. ** 31 августа 2026 года в 5:18 вечера CEST** — Началось развертывание фиксатора к производству. ** 31 августа 2026 года в 5:57 вечера CEST** Ремонт был полностью запущен в производство, и нормальная функциональность была восстановлена для всех пострадавших клиентов. ##Коренная причина Инцидент был вызван изменением кода, предназначенного для устранения несвязанной, незначительной проблемы отображения на общих страницах проекта. Это изменение изменило способ вставки значения в скрипт, встроенный непосредственно на странице. Система, которая отображает страницу, автоматически кодирует значения для безопасности, но это кодирование не различает значение, размещаемое в обычном контенте страницы, по сравнению с внутренним сценарием. В результате синтаксис встроенного скрипта был бесшумно нарушен, как только изменение достигло производства. Поскольку браузеры перестают выполнять любой дополнительный код на странице, как только они сталкиваются с недействительным синтаксисом сценария, каждый сценарий, размещенный после этого момента на странице, перестает работать, а не только часть, связанная с первоначальным изменением. Вот почему клиенты испытали то, что выглядело как две отдельные проблемы (отключенные кнопки меню и рабочие места, не открывающиеся в редакторе), которые на самом деле были побочными эффектами одного и того же дефекта. Проблема не была обнаружена до релиза, потому что проверка, выполненная в то время, подтвердила, что вставленные базовые данные были правильными, но не загрузила фактическую страницу в браузере, чтобы подтвердить, что она отображается и выполняется правильно. ## Меры по предотвращению рецидивов 1. ** Исправлено** - Основной дефект был исправлен и доставлен на производство в тот же день, когда он был обнаружен. 2. ** Инжиниринговое руководство обновлено** Мы обновили нашу внутреннюю инженерную документацию, чтобы четко описать эту конкретную схему отказа и правильный, безопасный способ ее обработки, поэтому эта категория ошибок улавливается во время проверки кода в будущем. 3. ** Автоматизированные улучшения обнаружения** Мы работаем над добавлением автоматизированного мониторинга для этого класса сбоев интерфейса, поэтому аналогичные проблемы могут быть обнаружены и решены до того, как клиенты будут затронуты, а не полагаться на отчеты клиентов.

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

1. 19 августа 2026 г. в 12:16 UTCinvestigating

   В настоящее время мы изучаем проблему, затрагивающую функциональность Translation Memory в Phrase TMS (EU). За это время у пользователей могут возникнуть проблемы с созданием переводческих воспоминаний и других связанных с ними операций. Наша команда активно работает над выявлением причины и восстановлением полной функциональности как можно быстрее.

2. 19 августа 2026 г. в 12:34 UTCidentified

   Вопрос был выявлен, и в настоящее время осуществляется исправление.

3. 19 августа 2026 г. в 13:19 UTCmonitoring

   Было принято решение, и мы следим за ситуацией.

4. 19 августа 2026 г. в 14:09 UTCresolved

   Инцидент был урегулирован.

5. 6 октября 2026 г. в 08:14 UTCpostmortem

   ## ** Введение** Мы хотели бы поделиться более подробной информацией о событиях, которые произошли с Phrase между 2:11 PM CEST и 4:10 PM CEST 19 августа 2026 года, что привело к ухудшению функциональности памяти перевода в Phrase TMS \(EU\) и что делают инженеры Phrase, чтобы предотвратить повторение этих проблем. ####Время** ** 19 августа 2026 года в 2:11 вечера CEST:** Phrase выявил проблему, затрагивающую функциональность Translation Memory в Phrase TMS \(EU\). Пользователи испытывали ошибки при создании переводческих воспоминаний и выполнении связанных с ними операций, включая подтверждение сегментов, повышение частоты ошибок в зависимых сервисах и случаях использования. ** 19 августа 2026 года в 2:32 вечера CEST:** Была выявлена первопричина, и инженеры начали применять исправление к пораженной среде путем перебалансировки кластера и перезапуска пораженных узлов для ускорения восстановления. ** 19 августа 2026 года в 3:10 вечера CEST:** Было подтверждено, что создание переводческой памяти и связанные с ней операции снова функционируют нормально. ** 19 августа 2026 года в 4:10 вечера CEST:** После того, как длительный период мониторинга не показал повторения, инцидент был отмечен как устраненный. ##**Корневая причина** Расследование показало, что инцидент произошел в кластере баз данных, который хранит данные Translation Memory. Единая Память Перевода со временем стала очень большой и требовала непропорциональной доли активности чтения, обслуживаемой узлом, который также координировал управление здоровьем и метаданными более широкого кластера. Поскольку кластер проходил техническое обслуживание с нулевым временем простоя в течение нескольких дней, в кластере наблюдалось более высокое количество координационных действий и повышенная нагрузка на координационные узлы. Эти два в сочетании с пиковой нагрузкой привели к медленному ухудшению производительности нескольких координационных узлов, что привело к повышению частоты ошибок и ухудшению производительности. ##**Действия по предотвращению рецидивов** Для предотвращения подобных инцидентов в будущем и смягчения любых негативных последствий мы: Сбалансировал кластер и его инфраструктуру поддержки, чтобы создать больше возможностей для поиска и обновления памяти перевода. * Приостановил текущее обслуживание кластера Translation Memory. Улучшенная способность координационного узла и будет улучшать топологию кластера, чтобы предотвратить воздействие кластера во время внезапных пиков запросов.

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

1. 7 августа 2026 г. в 07:27 UTCinvestigating

   В настоящее время мы расследуем проблему с событиями ветвления, отсутствующими в строках фраз (ЕС), которые могут привести к изменениям, которые не будут применяться при объединении ветвей.

2. 7 августа 2026 г. в 07:54 UTCinvestigating

   Мы продолжаем расследование этого вопроса.

3. 7 августа 2026 г. в 08:18 UTCidentified

   Этот вопрос был определен, и в настоящее время осуществляется исправление.

4. 7 августа 2026 г. в 08:30 UTCmonitoring

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

5. 7 августа 2026 г. в 14:12 UTCresolved

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

6. 11 сентября 2026 г. в 06:11 UTCpostmortem

   ##Введение Мы хотели бы поделиться подробностями об инциденте, который затронул Фразовые строки на платформе ЕС в период с 6 по 7 августа 2026 года. В течение этого периода изменения, внесенные в филиалы, не фиксировались нашим конвейером по переработке изменений. В результате ветви, которые были объединены во время инцидента, могли быть объединены без изменений, внесенных в них во время этого окна, и экраны сравнения ветвей не могли показать никаких различий, даже когда различия существовали. Этот вскрытие объясняет, что произошло, как это было решено, и что мы делаем, чтобы предотвратить это снова. ##Время ** 6 августа 2026 года в 5:44 вечера по восточному времени (CEST) - прерывание сети разорвало соединение, которое наш конвейер обработки изменений использует для считывания изменений в базе данных. Соединение не восстановилось, и изменения ветвей перестали обрабатываться. Пострадавший компонент продолжал сообщать о себе как о здоровом, поэтому автоматическое оповещение не срабатывало. ** 7 августа 2026 года в 09:11 AM CEST** Проблема была выявлена после отчета клиента. ** 7 августа 2026 года в 09:19 AM CEST** Инцидент обострился до самого высокого уровня. ** 7 августа 2026 года примерно в 10:20 утра по восточному времени** Пораженный компонент был восстановлен путем его перезапуска, и обработка изменений возобновилась. ** 7 августа 2026 года в 10:46 утра по восточному времени** Отставание от ожидающих изменений было полностью обработано, и трубопровод был захвачен. ** 7 августа 2026 года** Пострадавшие клиенты были идентифицированы и индивидуально связались с данными, необходимыми для восстановления их изменений. ##Коренная причина Инцидент был вызван временным прерыванием сети, которое нарушило соединение, используемое нашей системой для передачи изменений из базы данных в наш конвейер обработки ветвей. Компонент, ответственный за это соединение, попытался восстановить соединение автоматически, но попытка повторного соединения висела на неопределенный срок, а не была успешной или неудачной. Поскольку компонент никогда не сообщал о сбое, автоматический механизм восстановления нашей платформы, который перезапускает компоненты, сообщающие о состоянии ошибки, никогда не запускался. Компонент оставался в состоянии, когда казалось, что он работает нормально, не обрабатывая никаких изменений. Вот почему стандартный перезапуск соединения не решил проблему, в то же время полностью перезапустив основной процесс, который установил новое соединение. Ситуация не была обнаружена раньше, потому что наш мониторинг этого трубопровода опирался на сигнал, который продолжал сообщать о «здоровом» во время инцидента, и у нас не было отдельной меры того, действительно ли изменения проходят и обрабатываются. # # Влияние Отделения, которые имели изменения во время инцидента, но не были объединены, не потеряли никаких данных. Их изменения были обработаны после восстановления трубопровода. Отделения, которые были объединены во время инцидента, были объединены без изменений, внесенных в них во время окна инцидента. Изменения, внесенные до инцидента, не были затронуты. В конечном итоге пострадало лишь небольшое количество клиентов. С каждым из них связывались индивидуально и предоставляли данные и шаги, необходимые для восстановления затронутых изменений. ## Меры по предотвращению рецидивов 1. ** Фиксированный вводящий в заблуждение мониторинг** - Мы исправили конфигурацию мониторинга, которая группировала различные производственные среды вместе, что задержало наше осознание проблемы. 2. ** Добавление значимых сигналов здоровья ** Мы добавляем мониторинг, который измеряет, действительно ли изменения идут по трубопроводу и насколько далеко позади него, вместо того, чтобы полагаться на сигнал статуса, который может сообщать о «здоровом» состоянии. Это гарантирует, что аналогичный киоск будет обнаружен немедленно. 3.** Улучшение автоматического восстановления** Мы пересматриваем поведение повторного подключения и повторного запуска этого компонента, так что застрявшее соединение приводит к подлинному сбою, который запускает автоматический перезапуск.

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

1. 6 августа 2026 г. в 08:11 UTCinvestigating

   We are currently investigating an issue affecting Connectors in Phrase TMS. Customers may be unable to access or use Connector functionality during this time. Our engineering team is actively working to identify the cause and restore full service as quickly as possible.

2. 6 августа 2026 г. в 08:18 UTCinvestigating

   We are continuing to investigate this issue.

3. 6 августа 2026 г. в 08:43 UTCmonitoring

   We have identified the root cause and the issue has now been resolved. Connectors should be appearing as active again. We will continue to monitor the situation to ensure full stability.

4. 6 августа 2026 г. в 12:00 UTCmonitoring

   We continue monitoring the situation.

5. 6 августа 2026 г. в 13:19 UTCresolved

   The incident has been resolved and all components are back to operational.

1. 28 июля 2026 г. в 07:19 UTCinvestigating

   Инженерная группа выявила проблему с Orchestrator, когда новый Workflow Engine в настоящее время не выполняет рабочие процессы. Проблема находится под следствием.

2. 28 июля 2026 г. в 07:53 UTCinvestigating

   Мы продолжаем расследование этого вопроса.

3. 28 июля 2026 г. в 08:30 UTCidentified

   Этот вопрос был определен, и в настоящее время осуществляется исправление.

4. 28 июля 2026 г. в 08:35 UTCmonitoring

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

5. 28 июля 2026 г. в 11:49 UTCresolved

   Все казни были обработаны. Этот инцидент был урегулирован.

6. 30 июля 2026 г. в 07:09 UTCpostmortem

   ##Введение Мы хотели бы поделиться подробностями об инциденте, который произошел 27-28 июля 2026 года. В течение этого периода выполнение рабочих процессов в движке рабочего процесса Next-Gen не могло прогрессировать и оставалось в «исполняющем» состоянии. Во время инцидента никаких данных не было потеряно. Вскрытие объясняет, что произошло, когда это было решено, и шаги, которые мы предприняли, чтобы предотвратить повторение. ##Время ** 27 июля 2026 в 18:55 CEST** Движок рабочего процесса начал производить ошибки, поскольку производительность запросов базы данных ухудшилась. Выполнение рабочих процессов застопорилось и перестало прогрессировать. ** 27 июля 2026 в 20:54 CEST** Получен первый клиентский отчет о казнях, застрявших в «исполнении». ** 27 июля 2026 в 22:39 CEST** Инцидент был официально объявлен. ** 28 июля 2026 года в 02:18 CEST** — Временная помощь была возобновлена при перезапуске службы. ** 28 июля 2026 в 05:15 CEST** - Проблема повторялась по мере того, как сохранялась основная проблема производительности базы данных. ** 28 июля 2026 в 09:56 CEST** - Была выявлена и устранена первопричина. Никаких казней не было потеряно; однако из-за частичного перезапуска службы некоторые действия в казнях были восстановлены, что, возможно, привело к тому, что небольшое количество казней потерпело неудачу, которая в противном случае была бы успешной. ** 28 июля 2026 в 13:46 CEST** Полное отставание в казнях было подтверждено. Система была признана стабильной. ** 28 июля 2026 года в 13:48 CEST** — Инцидент разрешен. ##Коренная причина Инцидент был вызван прогрессивным вздутием индексов баз данных, используемых системой планирования рабочих процессов. Производительность этих конкретных индексов постепенно ухудшалась с течением времени, поскольку они накапливали мертвые записи индекса из предыдущих записей и обновлений. Механизм планирования работы получает блоки координации на уровне базы данных при запросе этих индексов, чтобы определить, какие рабочие места отправлять. По мере того, как поиски индексов росли медленнее, они начали превышать настроенный тайм-аут в базе данных. Когда поиск был отменен тайм-аутом, процесс планирования, ответственный за эту работу, потерпел крах и возобновился. Без запуска планировщиков не могли быть отправлены шаги рабочего процесса, и все выполняемые рабочие процессы застряли. Сам сервер базы данных оставался здоровым на протяжении всего инцидента, с нормальным процессором и уровнем подключения. Проблема заключалась исключительно в блокировке и задержке внутри слоя планирования. Сервисный перезапуск очистил разбитые процессы и временно восстановил исполнение. Однако из-за того, что раздутие индекса все еще присутствовало, такая же деградация повторялась после возобновления нагрузки запроса. Ручной индекс полностью восстановил производительность и решил проблему. ## Меры по предотвращению рецидивов 1. ** Автоматизированное техническое обслуживание индекса добавлено ** - Запланированное автоматическое техническое обслуживание индекса было настроено для соответствующих индексов. Это гарантирует, что вздутие не может накапливаться с течением времени и устраняет условия, которые вызвали этот инцидент. 2. ** Индексы наследственности удалены ** - Неиспользованные индексы устаревших баз данных были идентифицированы и удалены, что снижает общую поверхность обслуживания и упрощает гигиену будущих индексов. 3. ** Обновленная информация о мониторинге** Наш ландшафт мониторинга пересматривается и обновляется, чтобы отразить текущее состояние двигателя рабочего процесса. Эта работа закроет пробелы, которые позволили не обнаружить деградацию до первого отчета клиента.

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

1. 27 июля 2026 г. в 23:48 UTCinvestigating

   Инженеры выявили проблему с Orchestrator, когда новый Workflow Engine в настоящее время не выполняет рабочие процессы. Проблема находится под следствием.

2. 28 июля 2026 г. в 00:41 UTCresolved

   Все рабочие процессы выполняются снова, как и ожидалось.

3. 30 июля 2026 г. в 07:08 UTCpostmortem

   ##Введение Мы хотели бы поделиться подробностями об инциденте, который произошел 27-28 июля 2026 года. В течение этого периода выполнение рабочих процессов в движке рабочего процесса Next-Gen не могло прогрессировать и оставалось в «исполняющем» состоянии. Во время инцидента никаких данных не было потеряно. Вскрытие объясняет, что произошло, когда это было решено, и шаги, которые мы предприняли, чтобы предотвратить повторение. ##Время ** 27 июля 2026 в 18:55 CEST** Движок рабочего процесса начал производить ошибки, поскольку производительность запросов базы данных ухудшилась. Выполнение рабочих процессов застопорилось и перестало прогрессировать. ** 27 июля 2026 в 20:54 CEST** Получен первый клиентский отчет о казнях, застрявших в «исполнении». ** 27 июля 2026 в 22:39 CEST** Инцидент был официально объявлен. ** 28 июля 2026 года в 02:18 CEST** — Временная помощь была возобновлена при перезапуске службы. ** 28 июля 2026 в 05:15 CEST** - Проблема повторялась по мере того, как сохранялась основная проблема производительности базы данных. ** 28 июля 2026 в 09:56 CEST** - Была выявлена и устранена первопричина. Никаких казней не было потеряно; однако из-за частичного перезапуска службы некоторые действия в казнях были восстановлены, что, возможно, привело к тому, что небольшое количество казней потерпело неудачу, которая в противном случае была бы успешной. ** 28 июля 2026 в 13:46 CEST** Полное отставание в казнях было подтверждено. Система была признана стабильной. ** 28 июля 2026 года в 13:48 CEST** — Инцидент разрешен. ##Коренная причина Инцидент был вызван прогрессивным вздутием индексов баз данных, используемых системой планирования рабочих процессов. Производительность этих конкретных индексов постепенно ухудшалась с течением времени, поскольку они накапливали мертвые записи индекса из предыдущих записей и обновлений. Механизм планирования работы получает блоки координации на уровне базы данных при запросе этих индексов, чтобы определить, какие рабочие места отправлять. По мере того, как поиски индексов росли медленнее, они начали превышать настроенный тайм-аут в базе данных. Когда поиск был отменен тайм-аутом, процесс планирования, ответственный за эту работу, потерпел крах и возобновился. Без запуска планировщиков не могли быть отправлены шаги рабочего процесса, и все выполняемые рабочие процессы застряли. Сам сервер базы данных оставался здоровым на протяжении всего инцидента, с нормальным процессором и уровнем подключения. Проблема заключалась исключительно в блокировке и задержке внутри слоя планирования. Сервисный перезапуск очистил разбитые процессы и временно восстановил исполнение. Однако из-за того, что раздутие индекса все еще присутствовало, такая же деградация повторялась после возобновления нагрузки запроса. Ручной индекс полностью восстановил производительность и решил проблему. ## Меры по предотвращению рецидивов 1. ** Автоматизированное техническое обслуживание индекса добавлено ** - Запланированное автоматическое техническое обслуживание индекса было настроено для соответствующих индексов. Это гарантирует, что вздутие не может накапливаться с течением времени и устраняет условия, которые вызвали этот инцидент. 2. ** Индексы наследственности удалены ** - Неиспользованные индексы устаревших баз данных были идентифицированы и удалены, что снижает общую поверхность обслуживания и упрощает гигиену будущих индексов. 3. ** Обновленная информация о мониторинге** Наш ландшафт мониторинга пересматривается и обновляется, чтобы отразить текущее состояние двигателя рабочего процесса. Эта работа закроет пробелы, которые позволили не обнаружить деградацию до первого отчета клиента.

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

1. 20 июля 2026 г. в 12:53 UTCresolved

   Между 16 июня 2026 года 01:00PM CEST и 17 июня 2026 года 11:00AM CEST разъем Phrase Job Sync имел ухудшенную производительность. Клиенты, использующие Job Sync с типом подключения по умолчанию, испытывали сбои. Инженерная команда определила первопричину и предоставила исправление.

2. 20 июля 2026 г. в 12:54 UTCpostmortem

   ###Введение Мы хотели бы поделиться более подробной информацией о событиях, которые произошли с Phrase между 16 июня 2026 года, 01:00PM CEST и 17 июня 2026 года, 11:00AM CEST, что привело к ухудшению производительности API Phrase Strings, в результате чего клиенты, использующие Job Sync с типом подключения по умолчанию, испытывают сбои. Мы приносим извинения за нарушения и стремимся предотвратить подобные инциденты в будущем. ###Время ** 16 июня 2026 года @ 01:00 PM CEST** — Job Sync начала выходить из строя для клиентов, использующих тип подключения по умолчанию. Коннекторы не смогли аутентифицироваться против API Phrase Strings. ** 17 июня 2026 @ 10:00 AM CEST** - Провал аутентификации был выявлен инженерной командой. ** 17 июня 2026 @ 10:28 AM CEST** — Подтверждена область воздействия: Пострадали клиенты, использующие соединение Job Sync по умолчанию. Клиенты, использующие разъемы на основе токенов, не пострадали. ** 17 июня 2026 @ 10:29 AM CEST** — Была выявлена первопричина: Недавнее изменение, которое добавило поддержку мультиплатформенных токенов, непреднамеренно ввело ошибки с некоторыми существующими токенами платформы. ** 17 июня 2026 года @ 10:40 AM CEST** — исправление подготовлено и представлено на рассмотрение. ** 17 июня 2026 @ 10:53 AM CEST** - Ремонт был развернут, а функциональность JobSync полностью восстановлена. ###Коренная причина Изменение кода, введенное для добавления поддержки многоплатформенных токенов аутентификации, изменило то, как входящие токены платформы проверяются и обрабатываются в API Phrase Strings. Это изменение не было совместимо с существующим форматом токенов, используемым по умолчанию. В результате токены платформы были отклонены API Strings с ответом «401 Unauthorized». Разъем повторно устанавливал соединение до тех пор, пока не исчерпал свой бюджет повторного использования, в результате чего все затронутые операции вышли из строя. Клиенты, использующие токены личного доступа, не пострадали, поскольку их токены следуют другому пути кода. ###Действия по предотвращению рецидивов Основной причиной было обратно несовместимое изменение обработки токенов, которое не было обнаружено во время разработки. Принимаются следующие меры: ** Тестирование совместимости формата токена в изменениях: ** При введении нового формата токена/аутентификации наряду с существующим, тесты должны явно охватывать случай перехода — токены старого формата, обрабатываемые в соответствии с новой логикой обнаружения, а не только каждый формат в отдельности.

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

1. 16 июля 2026 г. в 15:47 UTCinvestigating

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

2. 16 июля 2026 г. в 16:29 UTCidentified

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

3. 16 июля 2026 г. в 17:31 UTCmonitoring

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

4. 16 июля 2026 г. в 19:04 UTCidentified

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

5. 17 июля 2026 г. в 13:02 UTCmonitoring

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

6. 20 июля 2026 г. в 12:07 UTCresolved

   Этот инцидент был урегулирован.

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

1. 16 июля 2026 г. в 14:49 UTCinvestigating

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

2. 16 июля 2026 г. в 15:27 UTCinvestigating

   Мы продолжаем расследование этого вопроса.

3. 16 июля 2026 г. в 15:27 UTCidentified

   Этот вопрос был определен, и в настоящее время осуществляется исправление.

4. 16 июля 2026 г. в 15:41 UTCmonitoring

   Реализовано исправление, и мы отслеживаем результаты.

5. 16 июля 2026 г. в 16:12 UTCresolved

   Orchestrator (EU) доступен с 5:32 PM CEST. Все ожидаемые казни обрабатываются. Этот инцидент был урегулирован.

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

1. 10 июля 2026 г. в 14:24 UTCinvestigating

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

2. 10 июля 2026 г. в 14:37 UTCmonitoring

   Реализовано исправление, и мы отслеживаем результаты.

3. 10 июля 2026 г. в 15:24 UTCresolved

   Этот инцидент был урегулирован.

4. 7 августа 2026 г. в 07:14 UTCpostmortem

   ## Introduction On July 10, 2026, parts of the Phrase Strings frontend at [app.phrase.com](http://app.phrase.com/) failed to load correctly for a short period, after required stylesheets and scripts failed to load — the underlying service itself stayed available. The issue began at 16:08 CEST and was resolved by 16:27 CEST. This post-mortem explains what happened and what we're doing to prevent a recurrence. ## Timeline * **Jul 10, 2026 at 16:08 CEST** – A deployment introduced new application assets that were never uploaded to our storage service, so the application could no longer load its stylesheets and scripts for customers. * **Jul 10, 2026 at 16:21 CEST** – Issue detected, incident declared. * **Jul 10, 2026 at 16:24 CEST** – Root cause identified. * **Jul 10, 2026 at 16:26 CEST** – Fix applied. * **Jul 10, 2026 at 16:27 CEST** – Customer-facing impact ended. * **Jul 10, 2026 at 16:32 CEST** – Incident downgraded to monitoring while the underlying configuration was addressed. * **Jul 10, 2026 at 17:12 CEST** – Configuration corrected, incident resolved. ## Root Cause During a planned, routine maintenance, a configuration change unintentionally disabled the process that uploads application assets \(stylesheets, scripts\) to our storage and content-delivery service. This went unnoticed at first, since the assets already in place kept working and no new versions had been shipped yet. On July 10, 2026, a deployment shipped new versions of these assets. Because uploading was still disabled, the new files never reached the storage service, and the application could not load its stylesheets and scripts. ## Actions to Prevent Recurrence 1. **Asset synchronization re-enabled** – The disabled process was fixed, restoring correct asset delivery. 2. **Asset availability monitoring** – Adding monitoring to detect asset load failures automatically, before customers are affected.

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

1. 8 июля 2026 г. в 12:57 UTCinvestigating

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

2. 8 июля 2026 г. в 13:08 UTCmonitoring

   Вопрос определен, исправление осуществлено, и мы следим за ситуацией.

3. 8 июля 2026 г. в 13:55 UTCresolved

   Инцидент был урегулирован.

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

1. 7 июля 2026 г. в 08:34 UTCinvestigating

   We are currently investigating issues with CAT Web Editor.

2. 7 июля 2026 г. в 08:59 UTCmonitoring

   The issue has been identified, a fix was implemented and we are monitoring the situation.

3. 7 июля 2026 г. в 09:27 UTCresolved

   The incident has been resolved.

1. 29 июня 2026 г. в 07:30 UTCinvestigating

   Hi everyone, this is a test. Please ignore, thank you!

2. 29 июня 2026 г. в 08:05 UTCidentified

   Hi everyone, this is a test. Please ignore, thank you!

3. 29 июня 2026 г. в 08:09 UTCresolved

   This incident has been resolved.

1. 26 июня 2026 г. в 16:19 UTCinvestigating

   Hi everyone, this is a test. Please ignore. Thank you!

1. 26 июня 2026 г. в 07:31 UTCinvestigating

   Hello everyone, this is a test. Please ignore, thank you!

2. 26 июня 2026 г. в 08:16 UTCinvestigating

   Hello everyone, this is a test. We're "investigating" the issue. Please ignore, thank you!