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

1. 20 октября 2026 г. в 11:37 UTCidentified

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

2. 21 октября 2026 г. в 15:33 UTCmonitoring

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

3. 23 октября 2026 г. в 14:55 UTCresolved

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

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

1. 13 октября 2026 г. в 15:03 UTCinvestigating

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

2. 13 октября 2026 г. в 15:07 UTCmonitoring

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

3. 13 октября 2026 г. в 16:15 UTCresolved

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

4. 14 октября 2026 г. в 14:29 UTCpostmortem

   ## ** Резюме** 13 октября 2026 года, примерно с 14:19 до 15:05 \(UTC\), клиенты во всех регионах не смогли войти в консоль KnowBe4 Security Awareness Training \(SAT\), KnowBe4 Learner Experience и консоль PhishER через KnowBe4 SAT. Логины SAML и паролей возвращали ошибки, а консоль KnowBe4 SAT не появлялась на платформе KnowBe4. Некоторые фоновые процессы, в том числе синхронизация пользователей и обучение электронной почты, также не увенчались успехом. Инцидент был вызван выпуском продукта, который противоречил еще одному изменению в нашем коде. Мы восстановили релиз и восстановили логины в разных регионах между 14:59 и 15:05. В результате этой проблемы потери данных не произошло. ##**Корневая причина** Развертывание кода удалило значение конфигурации запуска, чтобы ускорить время запуска приложения. Отдельный компонент, добавленный в наш код после того, как первоначальное изменение было протестировано, не учитывал это измененное значение. В результате каждая попытка сохранить запись пользователя вызывала ошибку, включая обновление, которое записывает попытки входа. ##**Влияние на клиента** Клиенты во всех регионах не могли войти в консоль KSAT через SAML или пароль. Они также не могли получить доступ к Learner Experience и не могли получить доступ к консоли PhishER через консоль KnowBe4 SAT. Создание новых пользователей, синхронизация пользователей и обучение электронной почты не удалось в течение этого времени, но были автоматически восстановлены после развертывания. ##**Смягчение и восстановление** Мы обнаружили, что развертывание убрало значение конфигурации, которое по-прежнему требовалось другому компоненту. Это было смягчено путем возврата выпуска, и мы подтвердили восстановление во всех регионах посредством прямых проверок и автоматизированных тестов. Мы также восстановили первоначальное изменение исходного кода и подготовили исправленную версию, которая включает исправление совместимости, поэтому первоначальное улучшение может быть безопасно восстановлено. ## ** Меры по предотвращению** Мы добавляем дополнительные проверки кода и тестирование для развертывания.

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

1. 13 октября 2026 г. в 08:47 UTCinvestigating

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

2. 13 октября 2026 г. в 11:07 UTCmonitoring

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

3. 13 октября 2026 г. в 13:41 UTCresolved

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

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

   С понедельника, 12 октября 2026 года, примерно в 14:25 \(UTC\), до вторника, 13 октября 2026 года, примерно в 15:07 \(UTC\), некоторые клиенты в ЕС в случаях предотвращения и защиты испытывали трудности с отправкой электронных писем от Microsoft Outlook. Затронутые сообщения не были отправлены, и в надстройке KnowBe4 Email Security была обнаружена следующая ошибка: «Добавленная надстройка KnowBe4 Email Security предотвращает отправку этого сообщения». Эта проблема была вызвана ошибкой в том, как была подготовлена к выпуску дополнительная версия, которая произвела две немного разные копии одной и той же версии. Когда Outlook загружает дополнение, он загружает набор файлов, которые должны совпадать. В ЕС Outlook иногда получал файлы с обеих копий, поэтому дополнение не могло завершить загрузку, и сообщение не отправлялось. Некоторые устройства также сохранили неудавшуюся загрузку, поэтому ошибка продолжалась на этих устройствах до тех пор, пока не было применено исправление. Чтобы решить эту проблему, наша команда исправила файлы добавления ЕС, чтобы каждый клиент получал соответствующий набор. Затем мы выпустили обновленную версию дополнения во всех регионах, которая устранила любые сохраненные ошибки. Добавление KnowBe4 Email Security вернулось к нормальной производительности примерно к 15:07 13 октября 2026 года. Чтобы предотвратить этот тип проблемы в будущем, мы изменяем способ подготовки и выпуска дополнительных версий, так что каждая версия всегда производит один и тот же набор файлов, и каждый клиент получает одну и ту же версию одновременно. Мы также меняем дополнение, чтобы неудавшиеся загрузки файлов добавления не сохранялись на устройствах. Наконец, мы добавляем оповещения об ошибках загрузки, чтобы обнаружить их раньше. В результате этой проблемы потери данных не произошло.

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

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

   В настоящее время мы расследуем проблему снижения производительности для предотвращения и защиты на наших серверах в США.

2. 29 сентября 2026 г. в 13:44 UTCmonitoring

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

3. 2 октября 2026 г. в 10:32 UTCresolved

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

4. 6 октября 2026 г. в 15:51 UTCpostmortem

   ## ** Резюме** С понедельника, 28 сентября 2026 года, примерно в 16:00 \(UTC\), до среды, 30 сентября 2026 года, примерно в 12:35 \(UTC\), некоторые клиенты испытывали задержку почтового потока и периодические проблемы с доступом к американским экземплярам Prevent and Protect. 28 сентября наш мониторинг показал сильный сетевой трафик с пиками в верхней части каждого часа. Некоторые клиенты начали испытывать периодические проблемы с доступом к американским экземплярам консолей Prevent and Protect. Внутренние поиски, которые обрабатывают почту, зависят от начатого тайминга, и в результате сообщения были поставлены в очередь. Клиенты сообщили об этом нашей команде поддержки, и мы разместили уведомление о статусе. В тот же день производительность восстановилась, поскольку трафик в США сократился. 29 сентября наши инженеры просмотрели данные предыдущего дня через почтовые шлюзы, внутренние службы, от которых они зависят, и сетевой уровень. Задержки потока почты и проблемы с доступом к консолям вернулись на короткое время, а затем облегчились, поскольку сетевой трафик снизился, следуя той же схеме, что и 28 сентября. 30 сентября, примерно с 12:19 до 12:35, наша команда увеличила пропускную способность сетевых сервисов США. Их нагрузка упала сразу после изменения, и «Предотвращение и защита» вернулись к нормальной производительности примерно к 12:35 30 сентября 2026 года. Мы следили за пиковым трафиком в течение 30 сентября и 1 октября и не видели никаких рецидивов. В результате этой проблемы потери данных не произошло. ##**Корневая причина** Эта проблема была вызвана ограничением пропускной способности сетевых сервисов, которые обрабатывают трафик для наших почтовых служб в США. Во время пикового трафика и особенно во время почасовых пиков сетевые службы не могли обрабатывать соединения достаточно быстро. Это добавило задержки к трафику, проходящему через них, и привело к падению некоторых соединений. Этот трафик включал внутренние запросы, которые наши почтовые шлюзы отправляли для поиска членов списка рассылки, поэтому применяются правильные политики. Эти запросы подчиняются строгому сроку, поэтому медленный поиск не может задержать обработку почты на неопределенный срок. Когда сетевые службы задерживали запросы сверх этого предела, они терпели неудачу. В результате обработка почты замедлилась, и сообщения оказались в очереди. Два фактора усугубили проблему и затруднили ее выявление. Во-первых, некоторые внутренние запросы также использовали эти сетевые службы и были затронуты ограничением пропускной способности. Во-вторых, сетевые сервисы начали ухудшаться до того, как их вычислительное использование достигло уровня, который обычно сигнализирует о проблеме. Стандартный компьютерный мониторинг не уловил насыщенность сети, поэтому для выявления причины потребовалось больше времени. Поиск безопасного способа увеличения пропускной способности без прерывания обслуживания также занял время, поэтому исправление было применено 30 сентября. ##**Смягчение и восстановление** Мы обнаружили, что сетевые службы США не имеют достаточной мощности для обработки пикового трафика. Мы смягчили это, увеличив их пропускную способность таким образом, чтобы обслуживание продолжалось на протяжении всего изменения. После увеличения пропускной способности сетевые службы обрабатывали пиковый трафик без дальнейших проблем. Мы также обнаружили, что использование вычислений само по себе не является надежным признаком насыщения сети. Мы расширили наш мониторинг для отслеживания показателей здоровья сети в дополнение к использованию вычислений. Наконец, мы обнаружили, что было трудно найти, где неисправные внутренние запросы ломались. Мы добавили журналирование, которое показывает, где внутренние запросы терпят неудачу и время ожидания. ##**Влияние на клиента** Во время пикового трафика в США 28 и 29 сентября некоторые клиенты испытывали задержки в обработке и доставке входящей и исходящей почты через Prevent and Protect. Сообщения, адресованные спискам рассылки, возможно, обрабатывались медленнее, в то время как поиски перепроверялись. Некоторые клиенты также испытывали периодические трудности при входе или использовании консоли США. Влияние уменьшалось каждый день, так как трафик в США снижался, а очередь почты обрабатывалась после восстановления емкости. После изменения 30 сентября мы не увидели дальнейшей деградации во время пикового трафика. ## ** Меры по предотвращению** Чтобы предотвратить подобные проблемы в будущем, мы увеличили возможности сетевых служб США и расширили наш мониторинг для отслеживания показателей здоровья сети в дополнение к использованию вычислений. Мы также добавили журналирование для улучшения видимости неисправных внутренних запросов.

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

1. 24 сентября 2026 г. в 17:53 UTCinvestigating

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

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

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

3. 24 сентября 2026 г. в 19:57 UTCinvestigating

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

4. 24 сентября 2026 г. в 21:46 UTCmonitoring

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

5. 25 сентября 2026 г. в 09:16 UTCresolved

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

6. 6 октября 2026 г. в 15:51 UTCpostmortem

   ## ** Резюме** С четверга, 24 сентября 2026 года, примерно в 17:07 \(UTC\), до пятницы, 25 сентября 2026 года, примерно в 09:16 \(UTC\), некоторые клиенты испытывали периодическую медлительность, ошибки и задержку почтового потока для случаев защиты и предотвращения в США. 24 сентября необычайно большой всплеск трафика электронной почты установил устойчивую нагрузку на сетевые сервисы, которые обрабатывают трафик для обработки почты в США. Наш мониторинг предупредил нас примерно в 17:07 (UTC). Некоторые клиенты видели медленный или прерывистый доступ к Защите и случайные ошибки при загрузке страниц или расширенных опций. Доступ был непоследовательным, поэтому некоторые клиенты могли использовать Protect, в то время как другие видели ошибки. Обработка почты через американские экземпляры замедлилась, а некоторые сообщения были задержаны или не отображались в почтовом ящике модерации, когда ожидалось. Производительность улучшилась, поэтому мы переместили наше уведомление о статусе на Мониторинг в 18:39. Позже проблема повторилась, и клиенты сообщили о продолжающейся медлительности нашей команде поддержки. В 19:57 (UTC) мы вернули уведомление в Investigating и расширили его, включив в него Prevent. Наша команда контролировала затронутые системы, в то время как повышенный объем почты снижался. По мере того, как нагрузка на сетевые сервисы возвращалась к норме, обработка почты восстанавливалась, а почтовые очереди возвращались к норме в одночасье. Мы подтвердили, что Protect загружается нормально и что тестовые сообщения доставляются снова, а затем продолжили мониторинг. Защита и предотвращение вернулись к нормальной работе примерно к 09:16 25 сентября 2026 года. В результате этой проблемы потери данных не произошло. ##**Корневая причина** Эта проблема была вызвана необычно большим всплеском трафика электронной почты. Увеличение объема привело к постоянной нагрузке на сетевые сервисы, которые обрабатывают трафик для обработки почты в США. Эти сетевые службы работают в пределах фиксированной емкости, и их емкость не может быть увеличена во время всплеска. Поскольку они не могли идти в ногу с всплеском, они замедлились, и некоторая обработка периодически терпела неудачу. В результате большой объем почты был поставлен в очередь при обработке почты в США, некоторые страницы и действия в Protect возвращали ошибки, а некоторые сообщения задерживались или не появлялись в почтовом ящике модерации, когда ожидалось. Два фактора затрудняют решение проблемы. Во-первых, из-за того, что доступ периодически терпел неудачу, некоторые проверки были успешными, в то время как клиенты продолжали видеть ошибки, что затрудняло подтверждение восстановления. Во-вторых, наш мониторинг показал пиковую нагрузку на сетевые сервисы более четко, чем текущая нагрузка, что затрудняет оценку в режиме реального времени, была ли нагрузка все еще повышена. ##**Смягчение и восстановление** Мы обнаружили, что сетевые службы, обрабатывающие обработку почты в США, достигли своих фиксированных пределов пропускной способности во время всплеска трафика, и их пропускная способность не могла быть увеличена во время мероприятия. Наша команда контролировала затронутые системы, в то время как повышенный объем почты снижался, а нагрузка на сетевое обслуживание возвращалась к норме. Затем обработка почты восстановилась, и очередь почты была обработана. Поскольку ранее казалось, что проблема улучшилась до повторения, мы подтвердили восстановление несколькими способами, прежде чем разрешить инцидент. Мы подтвердили, что Protect загружается в обычном режиме, что тестовые сообщения доставляются через почтовую обработку в США, и что запросы на поддержку продвигаются нормально. Мы также наблюдали в одночасье и не получали никаких новых отчетов от клиентов в США. ##**Влияние на клиента** Некоторые клиенты имели медленный или прерывистый доступ к Protect и иногда видели ошибки при загрузке страниц или расширенных опций. Обработка почты через американские инстанции была отложена для защиты и предотвращения. В некоторых случаях сообщения задерживались или не появлялись в почтовом ящике модерации, когда ожидалось. Клиенты, чья почта зашифрована, расшифрована или модерируется по мере ее прохождения через нашу почтовую обработку в США, с большей вероятностью будут затронуты. Большинство клиентов Protect, использующих надстройку, не пострадали от задержек обработки почты. Консоли Protect и Prevent оставались доступными, хотя на некоторые действия консоли повлияла более медленная обработка почты. ## ** Меры по предотвращению** Чтобы предотвратить подобные проблемы в будущем, мы улучшаем наш мониторинг необычного увеличения объема электронной почты. Мы также улучшаем наш мониторинг, чтобы показать текущую нагрузку на наши сетевые сервисы, а не только пиковые значения. Кроме того, мы оцениваем способы более динамичного масштабирования нашей сети во время внезапных всплесков трафика и оцениваем долгосрочные улучшения сетевой инфраструктуры, которая обрабатывает обработку почты в США. С тех пор мы также увеличили пропускную способность сетевых служб США в ответ на [более поздний инцидент] (https://status.knowbe4.com/incidents/9wc6rjm8g70v).

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

1. 23 сентября 2026 г. в 09:52 UTCidentified

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

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

   Проблема была выявлена, исправлена и будет обновлять эту страницу, когда у нас будет больше информации.

3. 23 сентября 2026 г. в 14:58 UTCresolved

   Этот инцидент был успешно устранен, и все системы работают в полном объеме.

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

1. 23 сентября 2026 г. в 09:00 UTCinvestigating

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

2. 23 сентября 2026 г. в 10:47 UTCidentified

   Вопрос был выявлен, и исправление было осуществлено. Соответственно, последует обновление с дополнительной информацией.

3. 23 сентября 2026 г. в 10:58 UTCmonitoring

   Проблема была выявлена, исправлена и будет обновлять эту страницу, когда у нас будет больше информации.

4. 23 сентября 2026 г. в 14:58 UTCresolved

   Этот инцидент был успешно устранен, и все системы работают в полном объеме.

5. 20 октября 2026 г. в 15:53 UTCpostmortem

   В среду, 23 сентября 2026 года, примерно с 08:15 до 11:18 \(UTC\), некоторые клиенты испытали медлительность и не смогли подать заявки в британских экземплярах Secure Webforms. Эта проблема была вызвана ограничениями производительности базы данных в производственной среде Великобритании после недавних изменений. Настройка базы данных также привела к неэффективной работе некоторых запросов. В результате время отклика увеличилось, и некоторые формы представления не увенчались успехом. Чтобы решить эту проблему, наша команда временно приостановила задачу синхронизации фона, чтобы уменьшить нагрузку, настроила настройки базы данных для повышения эффективности запросов и увеличения пропускной способности хранилища. Безопасные веб-формы вернулись к нормальной производительности к 11:18. Чтобы предотвратить этот тип проблемы в будущем, мы добавляем дополнительный мониторинг пропускной способности базы данных. Мы также повышаем эффективность задачи фоновой синхронизации. В результате этой проблемы потери данных не произошло.

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

1. 21 сентября 2026 г. в 09:32 UTCinvestigating

   Мы получили сообщения о том, что пользователи не могут отправлять электронные письма через Web Access (Secure Message Portal) в регионе Великобритании с ошибкой «503 Service Unavailable». Мы изучаем эту проблему и будем обновлять эту страницу, когда у нас будет больше информации.

2. 21 сентября 2026 г. в 14:36 UTCmonitoring

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

3. 21 сентября 2026 г. в 14:38 UTCmonitoring

   Мы продолжаем отслеживать любые дополнительные проблемы.

4. 22 сентября 2026 г. в 08:27 UTCresolved

   Этот инцидент был успешно устранен, и все системы работают в полном объеме.

5. 8 октября 2026 г. в 13:45 UTCpostmortem

   В понедельник, 21 сентября 2026 года, примерно с 08:55 до вторника, 22 сентября 2026 года, примерно в 14:30 \(UTC\), некоторые пользователи испытали ошибки и не смогли отправить электронные письма через Web Access \(Secure Message Portal\) в регионе Великобритании. Этот инцидент был вызван ошибкой конфигурации во время обновления базы данных, что привело к перебоям в обслуживании. Чтобы решить эту проблему, мы восстановили конфигурацию, и 22 сентября 2026 года Web Access вернулся к нормальной производительности к 14:30 \(UTC\). Чтобы предотвратить подобные проблемы в будущем, мы пересматриваем и обновляем нашу конфигурацию базы данных. В результате этой проблемы потери данных не произошло.

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

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

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

2. 18 сентября 2026 г. в 16:48 UTCresolved

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

3. 8 октября 2026 г. в 14:07 UTCpostmortem

   ## ** Резюме** 17 сентября 2026 года фоновая работа архивировала большую группу пользователей и выполнялась как единая транзакция с неограниченной базой данных. Эта транзакция заблокировала большое количество строк пользователей, что привело к тому, что логины в США вышли из строя, потому что они пишут в одну и ту же таблицу. После достижения предела выполнения платформы работа была прекращена и автоматически повторена пять раз за 15-минутные интервалы, что привело к 75-минутному отключению. Чтобы решить проблему, мы развернули исправление, которое отделило логины от замка. Затем мы развернули последующее исправление для регрессии, введенной изменением входа в систему, а также для архивной работы. ##**Что случилось** Предыдущее изменение переместило действие «архив всех пользователей» из синхронного, тайм-аута веб-запроса в неограниченную фоновую работу. Когда большая группа пользователей была заархивирована, это вызвало новую фоновую работу. Работа блокировала все затронутые пользовательские строки в одной транзакции, выполняя записи для каждого пользователя и синхронный внешний вызов службы перед совершением. Попытки входа, которые пишутся в ту же таблицу, были поставлены в очередь за закрытой работой и отведены для пользователей из США. Когда работа достигла 15-минутного предела исполнения платформы, она была прекращена в середине транзакции, транзакция откатилась назад, и работа была возвращена в очередь. Этот цикл происходил пять раз, что приводило к 75-минутному отключению. Когда сбои были обнаружены внутри в 22:35, был объявлен инцидент, и инженер был вызван, чтобы ответить. Смягчение для отделения действия записи от потока входа в систему было развернуто примерно в 23:44 \(UTC\). Само смягчение вызвало регрессию: любой пользователь в любом регионе, который ранее неправильно ввел пароль, больше не мог войти в систему, потому что сбросы для неудачных попыток входа в систему пытались написать в базу данных только для чтения. К 09:17 18 сентября 2026 года исправление для этой регрессии было развернуто по регионам. Первоначальная проблема с архивом только в США повторялась в два раза чаще между 13:45 и 14:05 до того, как постоянное исправление было развернуто примерно в 15:00. Инцидент был полностью разрешен к 19:12 (UTC) 18 сентября 2026 года. ##**Корневая причина** Неограниченная, однотранзакционная фоновая работа для архива пользователей большой группы содержала эксклюзивные блокировки на многих затронутых строках, блокируя запись собственного строки процесса входа в систему. Предварительное изменение для переноса этой операции с тайм-аута веб-запроса на фоновую работу устранило единственный оставшийся предел его продолжительности. 15-минутный лимит исполнения платформы затем вызвал автоматические циклы «убить и вернуть», повторяя разряд блокировки пять раз и приводя к 75-минутному отключению окна. ## ** Обнаружение и смягчение последствий** Мы обнаружили, что неограниченная транзакция архива блокирует большое количество затронутых пользовательских строк, блокируя другие записи таблицы. Это было смягчено в краткосрочной перспективе путем отделения зависимости записи процесса входа в систему от затронутой таблицы, а затем исправлено в долгосрочной перспективе путем исправления работы архива. Мы также обнаружили, что нескоординированная параллель между работниками усиливает противоречие блокировки. Это было смягчено в краткосрочной перспективе путем ручного сокращения параллелизма рабочих. Планируется долгосрочное исправление для шатания и сериализации этих рабочих мест. Наконец, мы обнаружили, что регрессия исправления входа вызвала сбои входа во все области для пользователей с предыдущими неудачными попытками, потому что записи были отклонены базой данных только для чтения. Это было исправлено с помощью целевого изменения кода, которое было развернуто и проверено во всех регионах. ##**Превентивные меры** Мы улучшаем наши архивные операции большой группы, ограничивая их, обрабатывая небольшими пакетами и сохраняя внешние вызовы вне транзакции базы данных. Мы также добавляем проверку изменений к конкретному фоновому сотруднику, чтобы пропустить записи, которые ничего не меняют. Наконец, мы добавляем прямые оповещения о возрасте транзакций в базе данных и задержках очистки в дополнение к периодическим косвенным проверкам. ##**Воздействие на клиента** Сбои в логине продолжались около 75 минут в США. Два коротких рецидива произошли на следующее утро и были очищены вручную в течение нескольких минут. Также были затронуты некоторые действия администратора, такие как управление пользователями. Логины партнеров не пострадали. Вторичная регрессия длилась около 10 часов и затронула все регионы для пользователей, которые ранее не смогли войти в систему. К полудню 18 сентября было подтверждено полное восстановление во всех регионах, и страница статуса была помечена как решенная. В результате этой проблемы потери данных не произошло. ## ** Вывод** Одна неограниченная фоновая транзакция в сочетании с автоматическим механизмом повторного запуска вызвала сбой входа в регион США. Конкретная работа запуска и ее поведение повторного запуска были исправлены, и вход в систему больше не зависит от предполагаемого пути записи. Одинаковая регрессия и два незначительных рецидива были устранены в течение нескольких часов. Выше отслеживается продолжение профилактической работы, включая координацию действий работников и мониторинг операций с базами данных.

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

1. 17 сентября 2026 г. в 22:44 UTCinvestigating

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

2. 18 сентября 2026 г. в 01:28 UTCmonitoring

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

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

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

4. 18 сентября 2026 г. в 16:47 UTCresolved

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

5. 5 октября 2026 г. в 21:16 UTCpostmortem

   ## ** Резюме** 17 сентября 2026 года фоновая работа архивировала большую группу пользователей и выполнялась как единая транзакция с неограниченной базой данных. Эта транзакция заблокировала большое количество строк пользователей, что привело к тому, что логины в США вышли из строя, потому что они пишут в одну и ту же таблицу. После достижения предела выполнения платформы работа была прекращена и автоматически повторена пять раз за 15-минутные интервалы, что привело к 75-минутному отключению. Чтобы решить проблему, мы развернули исправление, которое отделило логины от замка. Затем мы развернули последующее исправление для регрессии, введенной изменением входа в систему, а также для архивной работы. ##**Что случилось** Предыдущее изменение переместило действие «архив всех пользователей» из синхронного, тайм-аута веб-запроса в неограниченную фоновую работу. Когда большая группа пользователей была заархивирована, это вызвало новую фоновую работу. Работа блокировала все затронутые пользовательские строки в одной транзакции, выполняя записи для каждого пользователя и синхронный внешний вызов службы перед совершением. Попытки входа, которые пишутся в ту же таблицу, были поставлены в очередь за закрытой работой и отведены для пользователей из США. Когда работа достигла 15-минутного предела исполнения платформы, она была прекращена в середине транзакции, транзакция откатилась назад, и работа была возвращена в очередь. Этот цикл происходил пять раз, что приводило к 75-минутному отключению. Когда сбои были обнаружены внутри в 22:35, был объявлен инцидент, и инженер был вызван, чтобы ответить. Смягчение для отделения действия записи от потока входа в систему было развернуто примерно в 23:44 \(UTC\). Само смягчение вызвало регрессию: любой пользователь в любом регионе, который ранее неправильно ввел пароль, больше не мог войти в систему, потому что сбросы для неудачных попыток входа в систему пытались написать в базу данных только для чтения. К 09:17 18 сентября 2026 года исправление для этой регрессии было развернуто по регионам. Первоначальная проблема с архивом только в США повторялась в два раза чаще между 13:45 и 14:05 до того, как постоянное исправление было развернуто примерно в 15:00. Инцидент был полностью разрешен к 19:12 (UTC) 18 сентября 2026 года. ##**Корневая причина** Неограниченная, однотранзакционная фоновая работа для архива пользователей большой группы содержала эксклюзивные блокировки на многих затронутых строках, блокируя запись собственного строки процесса входа в систему. Предварительное изменение для переноса этой операции с тайм-аута веб-запроса на фоновую работу устранило единственный оставшийся предел его продолжительности. 15-минутный лимит исполнения платформы затем вызвал автоматические циклы «убить и вернуть», повторяя разряд блокировки пять раз и приводя к 75-минутному отключению окна. ## ** Обнаружение и смягчение последствий** Мы обнаружили, что неограниченная транзакция архива блокирует большое количество затронутых пользовательских строк, блокируя другие записи таблицы. Это было смягчено в краткосрочной перспективе путем отделения зависимости записи процесса входа в систему от затронутой таблицы, а затем исправлено в долгосрочной перспективе путем исправления работы архива. Мы также обнаружили, что нескоординированная параллель между работниками усиливает противоречие блокировки. Это было смягчено в краткосрочной перспективе путем ручного сокращения параллелизма рабочих. Планируется долгосрочное исправление для шатания и сериализации этих рабочих мест. Наконец, мы обнаружили, что регрессия исправления входа вызвала сбои входа во все области для пользователей с предыдущими неудачными попытками, потому что записи были отклонены базой данных только для чтения. Это было исправлено с помощью целевого изменения кода, которое было развернуто и проверено во всех регионах. ##**Превентивные меры** Мы улучшаем наши архивные операции большой группы, ограничивая их, обрабатывая небольшими пакетами и сохраняя внешние вызовы вне транзакции базы данных. Мы также добавляем проверку изменений к конкретному фоновому сотруднику, чтобы пропустить записи, которые ничего не меняют. Наконец, мы добавляем прямые оповещения о возрасте транзакций в базе данных и задержках очистки в дополнение к периодическим косвенным проверкам. ##**Воздействие на клиента** Сбои в логине продолжались около 75 минут в США. Два коротких рецидива произошли на следующее утро и были очищены вручную в течение нескольких минут. Также были затронуты некоторые действия администратора, такие как управление пользователями. Логины партнеров не пострадали. Вторичная регрессия длилась около 10 часов и затронула все регионы для пользователей, которые ранее не смогли войти в систему. К полудню 18 сентября было подтверждено полное восстановление во всех регионах, и страница статуса была помечена как решенная. В результате этой проблемы потери данных не произошло. ## ** Вывод** Одна неограниченная фоновая транзакция в сочетании с автоматическим механизмом повторного запуска вызвала сбой входа в регион США. Конкретная работа запуска и ее поведение повторного запуска были исправлены, и вход в систему больше не зависит от предполагаемого пути записи. Одинаковая регрессия и два незначительных рецидива были устранены в течение нескольких часов. Выше отслеживается продолжение профилактической работы, включая координацию действий работников и мониторинг операций с базами данных.

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

1. 16 сентября 2026 г. в 17:47 UTCidentified

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

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

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

3. 16 сентября 2026 г. в 20:58 UTCresolved

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

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

1. 11 сентября 2026 г. в 12:43 UTCresolved

   8 сентября мы узнали, что входящие письма HTML частично или полностью отображаются в Classic Outlook из-за обычного обновления библиотеки HTML в движке удаления вредоносного кода Defend, взаимодействующем с устаревшим движком рендеринга Word Classic Outlook. Новые Outlook и Outlook в сети не пострадали. Это была проблема с дисплеем: ни одно электронное письмо не было задержано, потеряно или скомпрометировано, а обнаружение угроз оставалось полностью активным. Инженерия вернула обновление, чтобы восстановить нормальный рендеринг. Если вы временно отключили удаление вредоносного кода во время этого окна, пожалуйста, повторно включите его для обеспечения полной защиты.

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

1. 4 сентября 2026 г. в 10:53 UTCinvestigating

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

2. 4 сентября 2026 г. в 14:24 UTCmonitoring

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

3. 7 сентября 2026 г. в 08:25 UTCresolved

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

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

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

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

2. 26 августа 2026 г. в 16:46 UTCmonitoring

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

3. 26 августа 2026 г. в 19:51 UTCresolved

   Наша инженерная команда внедрила исправление проблемы, которая вызывает задержки обработки сообщений в PhishER.

4. 16 октября 2026 г. в 20:36 UTCpostmortem

   ## ** Резюме** Во время рутинного развертывания 26 августа 2026 года структура управления инфраструктурой неожиданно удалила как первичные очереди обработки сообщений, так и вторичные очереди, в которых хранятся сообщения, которые не могли быть обработаны. Это привело к временному прерыванию входящей доставки электронной почты в почтовые ящики клиентов PhishER. В результате этой проблемы потери данных не произошло. ##**Корневая причина** 24 августа 2026 года внутреннее изменение конфигурации не синхронизировалось с нашим кодом. Более позднее обновление кода не возвращало эти записи. Когда 26 августа 2026 года началось плановое развертывание производства, активный код конфигурации не содержал записей о перемещении ресурсов. В результате развертывание рассматривало активные очереди как неуправляемые ресурсы и убирало их. ##**Смягчение и восстановление** Автоматизированный мониторинг предупредил нас о падении обработки сообщений, и была собрана команда реагирования на инциденты. Мы обнаружили, что очереди были удалены. Это было смягчено в краткосрочной перспективе путем повторного запуска затронутых производственных рабочих мест для воссоздания недостающих очередей. Затем мы подтвердили, что обработка электронной почты в режиме реального времени возобновилась. Наконец, мы воспроизвели полезные нагрузки электронной почты, хранящиеся в облачном хранилище во время сбоя в почтовых ящиках клиентов. ####Время** Все времена в UTC. ** 24 августа 2026, 18:41:** Внутреннее изменение конфигурации записывает обновленные записи ресурсов в конфигурацию живого производства. ** 26 августа 2026 года, 15:15:** Развертывание производства удалило входящие очереди и очереди, в которых хранятся сообщения, которые не могли быть обработаны в производстве, прекратив доставку электронной почты в почтовые ящики клиентов. ** 26 августа 2026 года, 15:59:** Наш автоматизированный мониторинг предупредил инженерную команду об обработке нулевых сообщений, и команда реагирования на инциденты была размещена на странице. ** 26 августа 2026 года, 16:01:** Мы подтвердили, что очереди были удалены, и подтвердили, что входящие полезные нагрузки по электронной почте по-прежнему надежно хранятся. ** 26 августа 2026 года, 16:15:** Мы определили несоответствие конфигурации как основную причину. ** 26 августа 2026 года, 16:25:** Наша команда восстановила рабочие места, и очереди были воссозданы. ** 26 августа 2026 года, 18:44:** Наш автоматический повтор закончил доставку всех отложенных электронных писем в почтовые ящики клиентов. ## ** Меры по предотвращению** Чтобы предотвратить этот тип проблемы в будущем, мы удалили шаг живой конфигурации из предварительных проверок и отделили планирование развертывания от производственных изменений. Мы также добавили автоматизированные проверки, чтобы подтвердить здоровье очереди после завершения выпуска. ##**Влияние на клиента** С 15:15 до 16:25 26 августа 2026 года входящие электронные письма, отправленные в PhishER, не были обработаны в почтовые ящики клиентов. Входящие полезные нагрузки электронной почты безопасно хранились в облачном хранилище во время сбоев. После того, как очереди были восстановлены, автоматический повтор доставил электронные письма в почтовые ящики клиентов. Все отложенные сообщения были доставлены в 18:44 (UTC). Данные электронной почты клиентов не были потеряны в результате этой проблемы.

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

1. 21 августа 2026 г. в 08:52 UTCinvestigating

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

2. 21 августа 2026 г. в 12:03 UTCidentified

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

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

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

4. 21 августа 2026 г. в 14:57 UTCresolved

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

5. 26 августа 2026 г. в 15:55 UTCpostmortem

   В пятницу, 21 августа 2026 года, примерно с 05:20 до 12:55 некоторые клиенты испытывали периодические сбои при использовании надстройки Gmail Phish Alert Button для сообщения о подозрительных электронных письмах, получая сообщение «Внутренняя ошибка произошла» вместо успешного подтверждения отчета. Проблема затронула клиентов во всех регионах, причем наибольшие объемы ошибок сосредоточены в регионах обслуживания ЕС-Запад и США-Восток. Эта проблема была вызвана сбоем службы кэширования на платформе Google Apps Script, на которую опирается дополнение для хранения конфигурации сеанса для каждого пользователя. Служба начала периодически возвращать пустые результаты при чтении, все еще принимая новые записи, что привело к сбою представленных отчетов. KnowBe4 напрямую связался с Google и подал официальный отчет об ошибках между 12:19 и 12:39. Объем ошибок резко сократился вскоре после того, как состояние на стороне поставщика исчезло, и кнопка оповещения Gmail Phish вернулась к нормальной производительности примерно к 12:55. Чтобы предотвратить этот тип проблемы в будущем, мы продолжаем работать с Google, чтобы отслеживать разрешение основного дефекта кэширования. В результате этой проблемы потери данных не произошло.

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

1. 18 августа 2026 г. в 14:29 UTCinvestigating

   Мы расследуем проблему, в результате которой отчет о непоставке (NDR) должен быть возвращен, когда сообщение сообщается через кнопку оповещения о фише, а в настройках учетной записи включена «Отправить нам копию»

2. 18 августа 2026 г. в 15:26 UTCmonitoring

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

3. 18 августа 2026 г. в 20:14 UTCresolved

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

4. 30 сентября 2026 г. в 20:06 UTCpostmortem

   Во вторник, 18 августа 2026 года, примерно с 14:10 до 14:55 \(UTC\), клиенты, использующие Кнопку оповещения Фиша \(PAB\) с включенной функцией **Отправить нам Копию**, получали отчеты о непоставке для почтового ящика **Отправить нам Копию**. Эта проблема была вызвана изменением конфигурации инфраструктуры маршрутизации электронной почты. Это изменение переименовало компонент обмена сообщениями, используемый как в нашей постановочной, так и в производственной среде. Поскольку производственное правило зависело от этого разделяемого компонента, переименование вызвало сбои в доставке в почтовый ящик **Send Us a Copy** и спровоцировало сообщения о непоставке. Чтобы решить эту проблему, наша команда обновила затронутую конфигурацию, чтобы ссылаться на правильный компонент, и функция «Отправить нам копию» вернулась к нормальной производительности к 14:55. Чтобы предотвратить этот тип проблемы в будущем, мы разделяем конфигурации маршрутизации электронной почты для наших производственных сред. Мы также согласовываем устаревшие конфигурации с нашими текущими стандартами управления инфраструктурой. В результате этой проблемы потери данных не произошло.

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

1. 5 августа 2026 г. в 19:29 UTCinvestigating

   We are currently investigating an issue affecting Google PhishRIP queries, which may cause them to fail.

2. 5 августа 2026 г. в 21:24 UTCmonitoring

   Based on our investigation into the recent errors affecting Google PhishRIP queries, it appears these may be related to suspended Gmail accounts. We are continuing to monitor the issue.

3. 6 августа 2026 г. в 21:56 UTCresolved

   Upon further investigation we have determined that the errors affecting Google PhishRIP queries were related to individual issues on Google accounts.

1. 4 августа 2026 г. в 19:19 UTCidentified

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

2. 4 августа 2026 г. в 19:51 UTCmonitoring

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

3. 5 августа 2026 г. в 12:17 UTCresolved

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

4. 28 сентября 2026 г. в 14:35 UTCpostmortem

   Во вторник, 4 августа 2026 года, примерно с 18:22 до 19:43 \(UTC\), у некоторых клиентов возникли проблемы с загрузкой страницы ** Настройки учетной записи ** в консоли KnowBe4 в регионах CA, DE, ЕС, Великобритании и США. Эта проблема была вызвана серией изменений приложений, которые увеличили сложность запроса GraphQL, используемого в настройках учетной записи. Каждое изменение оставалось ниже настроенного порога сложности платформы при индивидуальной оценке, но в совокупности запрос превышал этот порог и мешал загрузке страницы. Инженеры определили порог сложности как способствующий фактор и развернули корректирующее изменение, начинающееся примерно в 19:14. После того, как исправление было проверено в пострадавших регионах, консоль KnowBe4 вернулась к нормальной производительности примерно к 19:43. Чтобы предотвратить эту проблему в будущем, мы увеличили порог сложности. В результате этой проблемы потери данных не произошло.

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

1. 28 июля 2026 г. в 20:00 UTCinvestigating

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

2. 28 июля 2026 г. в 20:35 UTCmonitoring

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

3. 29 июля 2026 г. в 18:58 UTCresolved

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

4. 30 июля 2026 г. в 16:38 UTCpostmortem

   ## ** Резюме** 28 июля 2026 года обновление сервиса PhishRIP привело к тому, что некоторые поисковые запросы PhishRIP совпали более широко, чем они должны были. Доброкачественные электронные письма, которые не соответствовали настроенным критериям отправителя, были помещены на карантин в некоторых учетных записях клиентов. Автоматизированный мониторинг и поддержка клиентов быстро вскрыли проблему. Инженеры вернули изменения в течение примерно 25 минут после объявления инцидента и остановили непреднамеренный карантин. Затем инженеры вручную восстановили неправильно помещенные в карантин электронные письма в почтовые ящики клиентов. ##**Корневая причина** 28 июля 2026 года мы развернули обновление обслуживания службы запросов PhishRIP. Это обновление было разработано для улучшения обработки недействительных адресов отправителя, позволяя системе возвращаться к поиску только доменной части адреса. Однако существующая логика проверки использовала обычное выражение, которое требовало символа «@» в поле отправителя. Когда в запросе использовался голый домен, такой как [example.com] (http://example.com) без имени пользователя или символа «@», регекс помечал домен как недействительный. Этот конфликт между существующей валидацией и обновлением поиска домена привел к тому, что система полностью отказалась от критериев отправителя. Запрос работал против почтовых ящиков, используя только оставшиеся параметры, сопоставляя и карантинируя электронные письма далеко за пределами предполагаемого отправителя. ####Время** Все времена в UTC. ** Время** * * Событие** [править править код] 19:36 Наш автоматизированный мониторинг обнаружил аномальные схемы выполнения запросов и предупредил наших инженеров, которые немедленно начали расследование. ! [19:51] Проблема была доведена до производственного инцидента с высокой степенью тяжести, и была собрана группа реагирования. ! 19:52 Наша команда поддержки увеличила количество первых билетов клиентов, которые сообщили о неожиданных карантинах. | 19:54 | Корневая причина была прослежена до недавнего развертывания API запросов, и инженерия начала возвращать изменения. 20:00 Сообщения об инцидентах были размещены на нашей странице статуса, а PhishRIP был помечен как «Деградированный». 20:16 — развертывание полностью восстановлено. 20:35 Проверки производства подтвердили, что запросы по предметам и доменам снова соответствуют только намеченным целям, и что никакие дальнейшие сообщения не были помещены в карантин по ошибке. Наша страница статуса была обновлена соответствующим образом. ! 20:39 Инженеры приступили к восстановлению некорректно закрытых электронных писем. | 03:49 \(следующий день\) | Реставрации были завершены для всех наборов запросов клиентов, зарегистрированных через нашу службу поддержки. ##**Смягчение и восстановление** **Возвращение кода** Мы взвесили остановку активных операций PhishRIP в середине пути против возвращения кода. Прекращение фоновых задач нарушило бы законные рабочие процессы безопасности для каждого арендатора, поэтому лучшим вариантом было возвращение. Обратный код был развернут и проверен в производстве в течение примерно 40 минут после эскалации. ** Восстановление электронной почты** Чтобы избежать выпуска по-настоящему вредоносных электронных писем обратно в клиентскую среду, мы вручную восстановили их, а не оптом. Инженеры использовали внутренние инструменты администратора для восстановления электронных писем партиями и работали с поддержкой для проверки каждого идентификатора учетной записи, идентификатора запроса и получения сначала одобрения клиента. Все зарегистрированные счета были восстановлены в одночасье. ##** Меры профилактики** *** Регрессионное покрытие**: Мы добавляем модульные и интеграционные тесты только для доменных, нестандартных и простых отправителей запросов, чтобы поймать эти входные кейсы перед развертыванием. ** Охранные ограждения **: Мы добавляем проверку в движке запроса, которая блокирует выполнение запросов, если их основные параметры фильтрации сбрасываются во время оценки. ## ** Вывод** Это было вызвано одним правилом проверки: регекс, который предполагал, что каждое поле отправителя содержит «@». Когда запросы использовали голый домен, это предположение снизило фильтр отправителя, и запросы соответствовали гораздо большему количеству почты, чем предполагалось. Решение было простым, как только мы нашли его, и возврат остановил повреждение в течение примерно 25 минут после объявления инцидента. Восстановление карантинной почты было более трудным процессом: мы не могли восстановить электронную почту оптом, не рискуя по-настоящему вредоносными электронными письмами, возвращающимися в почтовые ящики. Наша команда решила действовать осторожно, работая со службой поддержки в течение всей ночи. Две превентивные меры могли бы поймать это раньше: тест, охватывающий только доменные запросы отправителя, и ограждение, которое отказывается запускать запрос, когда его фильтр отправителя был снят. Оба уже запланированы. Непосредственный вопрос решен, и все зарегистрированные счета восстановлены. ##*Глоссарий** ** ФишРИП: ** Функция Phisher, которая позволяет администраторам искать и карантинно сопоставлять фишинговые электронные письма в каждом почтовом ящике пользователя в организации. ** Регекс \(регулярное выражение \):** Модель, используемая в программном обеспечении для поиска текста и проверки ввода, например, проверки правильного форматирования адреса электронной почты. **Возврат кода:** Обновление программного обеспечения для возврата к предыдущей стабильной версии.

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

1. 17 июля 2026 г. в 13:18 UTCinvestigating

   Мы расследуем неспособность пользователей приобрести лицензии Protect на сайте store.knowbe4.com. Мы обновим эту страницу, когда у нас будет больше информации.

2. 17 июля 2026 г. в 18:55 UTCmonitoring

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

3. 20 июля 2026 г. в 18:24 UTCinvestigating

   Мы получили сообщения о том, что клиенты не могут приобрести лицензии Protect на сайте store.knowbe4.com. Мы изучаем эту проблему и будем обновлять эту страницу, когда у нас будет больше информации.

4. 29 июля 2026 г. в 18:40 UTCmonitoring

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

5. 17 августа 2026 г. в 21:02 UTCmonitoring

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

6. 11 сентября 2026 г. в 15:04 UTCresolved

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

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