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

1. 6 августа 2026 г. в 10:17 UTCinvestigating

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

2. 6 августа 2026 г. в 15:22 UTCresolved

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

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

1. 27 июня 2026 г. в 18:34 UTCmonitoring

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

2. 27 июня 2026 г. в 19:37 UTCresolved

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

3. 28 июня 2026 г. в 09:03 UTCresolved

   Эта проблема была вызвана неисправностью основного маршрутизатора, повлиявшей на основной центр обработки данных Sirv. Это вызвало кратковременные перебои в хранении и загрузке файлов во всех типах передачи: API, S3 и FTP. Sirv автоматически переключился на свой отказоустойчивый сервис, поэтому обработка и доставка файлов продолжались в обычном режиме. Запросы CDN также продолжались в обычном режиме. Все службы были восстановлены после того, как центр обработки данных устранил отключение основного маршрутизатора.

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

1. 30 января 2026 г. в 12:46 UTCinvestigating

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

2. 30 января 2026 г. в 14:28 UTCresolved

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

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

1. 31 марта 2025 г. в 14:32 UTCinvestigating

   Некоторые запросы из Калифорнии медленные, а небольшое число (менее 2%) терпят неудачу. Это расследование, вероятно, связано с новыми серверами CDN, которые были развернуты сегодня в Лос-Анджелесе.

2. 31 марта 2025 г. в 15:16 UTCresolved

   Вопрос решен. Проблема была вызвана потерей пакетов, повлиявшей на наш новый центр обработки данных в Лос-Анджелесе. Центр обработки данных проследил проблему до их провайдера Arelion, который испытывал нестабильность сети. Проблема была решена, когда Arelion был временно отключен в качестве провайдера, и трафик был перенаправлен через других провайдеров. Мы требуем, чтобы наши центры обработки данных автоматически и быстро идентифицировали и перенаправляли трафик в таких сценариях. Однако решение этого вопроса было недостаточно быстрым и, учитывая, что оно произошло вскоре после принятия этого нового центра обработки данных, мы решили прекратить его использование. Весь трафик теперь маршрутизируется из нашего первоначального дата-центра в Лос-Анджелесе (по состоянию на 7 апреля 2025 года).

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

1. 15 марта 2025 г. в 17:56 UTCresolved

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

2. 16 марта 2025 г. в 08:40 UTCidentified

   Этот вопрос еще не решен. Причина проблемы определена, и мы работаем над ее решением как можно скорее.

3. 16 марта 2025 г. в 15:25 UTCresolved

   Вопрос решен. Проблема была вызвана тем, что два сервера в одном кластере вышли из строя одновременно. Это повлияло на загрузку новых файлов примерно в 20% учетных записей Sirv. Загрузки предназначены для нормальной работы, когда один сервер не работает, но когда два сервера не работают, некоторые загрузки могут выйти из строя. Они потерпели неудачу из-за службы экспортера, которая перестала работать на одном сервере, а затем на другом сервере. Ошибки не позволили возобновить работу служб. Вторая проблема привела к тому, что разрешение заняло гораздо больше времени, чем ожидалось, потому что серверы не могли быть перезагружены. Это произошло из-за устаревшего BIOS. После обновления BIOS серверы были перезагружены, и причина проблемы была решена. Чтобы предотвратить это, мы внедрили новый процесс управления BIOS с нашим центром обработки данных. Мы также сокращаем наш цикл обновления оборудования для более частых обновлений оборудования. Чтобы уменьшить вероятность повторного отказа службы экспортера, мы отключили процесс и отслеживаем показатели сервера.

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

1. 26 февраля 2025 г. в 09:29 UTCinvestigating

   В течение 3 минут между 09:29 и 09:32 UTC некоторые запросы не возвращались. Эта проблема затронула только определенные запросы и только определенные учетные записи. Большинство аккаунтов не пострадали.

2. 26 февраля 2025 г. в 09:32 UTCresolved

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

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

1. 19 декабря 2024 г. в 14:20 UTCresolved

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

2. 19 декабря 2024 г. в 18:09 UTCresolved

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

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

1. 14 ноября 2024 г. в 09:52 UTCinvestigating

   Для запросов на загрузку файлов API возвращается повышенное количество 504 тайм-аута.

2. 14 ноября 2024 г. в 13:19 UTCinvestigating

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

3. 14 ноября 2024 г. в 15:23 UTCresolved

   Внесены изменения и вопрос практически решен. Большинство запросов на загрузку являются успешными.

4. 14 ноября 2024 г. в 19:06 UTCresolved

   Перегрузка API почти полностью устранена.

5. 15 ноября 2024 г. в 04:42 UTCresolved

   Вопрос был полностью решен. Проблема возникла, когда большие запросы API перегружали API загрузки, в результате чего некоторые запросы API возвращали 504 ошибки. Это было решено, но эффект «стук-он» привел к тому, что примерно 5% запросов API не сработали с ответом 502. Чтобы предотвратить повторение этой проблемы, были сделаны улучшения, чтобы уменьшить нагрузку на масштабирование изображения и лучше распределить нагрузку. Также вносятся изменения в систему регистрации и оповещения для более быстрого выявления таких сценариев. Наибольшее влияние эта проблема оказала на плагин Sirv WordPress. Плагин отправлял запрос API на все страницы администратора, который блокировал загрузку страницы до получения ответа - обычно менее 300 мс, но до 20 секунд, если запросы API были отсрочены. Эти запросы API не требовались, поэтому новая версия плагина WordPress v7.3.3 была выпущена в 1805 UTC (14 ноября), чтобы удалить такие запросы и предотвратить повторение этой проблемы: https://wordpress.org/plugins/sirv/ ------ Если вы используете API Sirv, мы рекомендуем, чтобы ваши скрипты были написаны для повторных запросов, которые получают ответ 502. Рекомендации по обработке 502 и другие ответы на ошибки приведены здесь: https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide

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

1. 22 февраля 2024 г. в 10:52 UTCinvestigating

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

2. 22 февраля 2024 г. в 12:06 UTCresolved

   Вопрос решен. В 1052 UTC около 11% запросов на небольшое количество учетных записей (12 учетных записей из 50 000 +) возвращали 404 ответа (файл не найден), когда они должны были вернуть 200 ответов (ОК). Когда команда Sirv определила проблему, они быстро работали над ее решением, и к 1206 году UTC все такие запросы возвращали нормальный ответ 200. Проблема возникла из-за неправильной конфигурации инженерами Sirv при настройке нового осколка кластера хранения. Некоторые запросы шли к новому осколку, прежде чем он был готов их получить. Классифицируется как степень тяжести 3: Незначительное воздействие.

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

1. 5 января 2024 г. в 20:21 UTCinvestigating

   Большое количество запросов в 25 CDN-локации Sirv возвращает ошибку. Наши инженеры работают быстро, чтобы определить и решить проблему.

2. 5 января 2024 г. в 21:07 UTCresolved

   Вопрос решен. Это было вызвано сбоем программного демона одновременно на нескольких серверах. Это легкий и высокоэффективный сервис-менеджер, который никогда не терпел неудач в прошлом. В течение этого периода от 3% до 58% HTTPS-запросов возвращали ошибку, в зависимости от того, какая из 25 точек CDN получила запрос. В настоящее время мы расследуем, почему это произошло, и будем принимать меры, чтобы это не повлияло на доступность услуг в будущем. Классифицируется как уровень тяжести 2: Значимое воздействие.

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

1. 5 декабря 2023 г. в 15:03 UTCinvestigating

   На CDN происходит 415 ошибок. Наши инженеры изучают причину.

2. 5 декабря 2023 г. в 18:32 UTCinvestigating

   Мы продолжаем расследовать причину этого вопроса. Природа его сложна. Он представляет собой ошибку 415 из файлов с нулевыми байтами. Существует также повышенный, хотя и более низкий уровень ошибок 500. Большинство запросов — 200 ответов. Наши инженеры прилагают все усилия, чтобы понять и решить эту проблему.

3. 5 декабря 2023 г. в 22:56 UTCresolved

   Проблема ошибки 415 была вызвана усечением некоторых файлов, что означает, что они потеряли часть своего содержимого. Эти файлы отображаются в панели управления на my.sirv.com как имеющие 0 байт. Файлы, загруженные сегодня, с большей вероятностью будут усечены, хотя кажется, что усечение происходит с файлами в течение длительного времени. Это не было идентифицировано, потому что они работали полностью как обычно, из-за кэширования не усеченных версий. Проблема усеченных файлов стала заметной только сегодня, после обновления инфраструктуры. Серверные кэши были очищены, и усеченные версии стали очевидными. Причиной усечения, как полагают, была ошибка программного обеспечения, которая теперь была решена. В настоящее время мы работаем над восстановлением усеченных файлов - процесс, который может занять от нескольких часов до нескольких дней. Если вы можете повторно загрузить любые файлы, которые в настоящее время не загружаются, пожалуйста, сделайте это сейчас. По оценкам, проблема затрагивает около 0,2% файлов.

4. 5 декабря 2023 г. в 23:33 UTCresolved

   Около 80% усеченных файлов были восстановлены. Число 415 ошибок значительно сократилось, хотя они остаются повышенными. Чтобы полностью решить проблему, оставшиеся усеченные файлы необходимо заменить исходным файлом. Мы работаем над тем, как восстановить оставшиеся файлы, хотя их трудно получить, и это может занять часы или дни. Для максимально быстрого разрешения рекомендуется повторно загрузить файлы. Такие файлы будут отображаться в вашем аккаунте как имеющие 0 байт. Начните со следующего URL, чтобы увидеть список всех файлов, загруженных за последние 30 дней: https://my.sirv.com/#/search/?created=30d Найдите любые файлы с нулевым байтом, сортируя результаты по размеру, подъему. Еще одно обновление будет опубликовано здесь, как только у нас появятся новости об оставшихся файлах.

5. 6 декабря 2023 г. в 01:48 UTCinvestigating

   Мы продолжаем восстанавливать небольшое количество оставшихся усеченных файлов. По оценкам, для этого потребуется еще 12-24 часа. Если у вас есть какие-либо файлы, которые не обслуживаются, вы можете решить это сразу, перезагрузив их. Мы создаем инструмент для создания списка файлов с нулевым байтом. Если вам нужен список файлов с нулевым байтом в вашей учетной записи, пожалуйста, отправьте запрос по адресу https://sirv.com/help/support/#support, и мы подготовим список, как только инструмент будет готов. Мы продолжим работу по восстановлению всех файлов. Если вы загружаете файлы с помощью функции автоматического захвата Sirv, вы можете просто удалить файлы с нулевым байтом, и они будут повторно извлечены из вашего удаленного местоположения по следующему запросу.

6. 6 декабря 2023 г. в 12:12 UTCresolved

   Было восстановлено больше файлов. Число ошибок 415 продолжает падать. Вы можете увидеть список из 415 ошибок на этой странице вашей учетной записи: https://my.sirv.com/#/analytics/errors/415? from=20231206&to=20231206 Вы можете загрузить файлы, чтобы решить любые 415 ошибок в ваших файлах. При необходимости мы можем предоставить список файлов с нулевым байтом - пожалуйста, спросите команду поддержки Sirv через эту форму: https://sirv.com/help/support/#support Мы продолжаем восстанавливать как можно больше файлов.

7. 6 декабря 2023 г. в 19:47 UTCresolved

   Проблема, вызвавшая повышенную скорость 415 ошибок, решена. Усеченные файлы были вызваны проблемой программного обеспечения, которое записывало некоторые файлы с нулевыми байтами. Поскольку это было программное обеспечение, это привело к тому, что усеченные файлы были реплицированы во всех версиях основного файла. Sirv тройняет каждый файл для защиты от аппаратных проблем (сбоев сервера или жесткого диска), однако обновленные файлы прошли все проверки и добросовестно утроили файлы. Он существовал без обнаружения, поскольку кэшированные версии файлов использовались для обработки и доставки. Все системы работали идеально до вчерашнего обновления инфраструктуры, когда кэшированные файлы были очищены. Корневая причина была решена путем выявления и исправления проблемы программного обеспечения, которая вызвала усечение. 5 декабря было завершено 1500 UTC. Затем была поставлена задача восстановить те файлы, которые были усечены. По всей платформе было затронуто около 0,2% файлов. Из этих файлов мы смогли восстановить от 95% до 100%, в зависимости от учетной записи. Любая учетная запись с восстановлением менее 100% отправляет список файлов с нулевым байтом, которые должны быть восстановлены путем повторной загрузки файлов. Пожалуйста, обратите внимание на нашу электронную почту со списком файлов. Пожалуйста, сообщите нам по следующему URL-адресу, если вам нужна какая-либо помощь: https://sirv.com/help/support/#support Ведется тщательное расследование вопроса, о котором будет подробно сообщено по электронной почте. В рамках доклада будет представлен перечень мер, принимаемых для предотвращения возможного повторения этой проблемы, а также усовершенствования и новые функции, которые уже разрабатываются. Мы приносим извинения всем клиентам, которые пострадали от этой проблемы. Это первый случай, когда основные данные были потеряны. Мы извлечем из этого все возможные уроки и сделаем Sirv еще сильнее и надежнее, чем раньше.

8. 21 декабря 2023 г. в 10:05 UTCresolved

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

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

1. 2 декабря 2023 г. в 04:19 UTCinvestigating

   С 0419 UTC из расположения CDN в Сиднее был возвращен повышенный уровень 429 ошибок.

2. 2 декабря 2023 г. в 10:31 UTCresolved

   Вопрос был решен в 1031 UTC. Причиной стала неправильная конфигурация сервера, которая заставила местоположение CDN в Сиднее видеть все запросы, поступающие с одного и того же IP-адреса, вместо истинного IP-адреса клиента. Это вызвало защиту DDOS, чтобы ограничить чрезмерное количество запросов от одного и того же IP. На многие запросы было возвращено 429 ответов. Проблема, казалось, была чрезвычайно короткой, когда сеть центров обработки данных Сиднея стала недоступной. Этот вопрос длился всего 1 минуту. Однако фактический инцидент начался сразу после того, как наша команда восстановила местоположение CDN в Сиднее, когда была применена неправильная конфигурация сервера. Проблема была решена, когда мы обнаружили неправильную конфигурацию и исправили ее. Принимаются многочисленные меры для предотвращения повторения этой проблемы и уменьшения воздействия аналогичных, но различных проблем в будущем: - Дополнительный мониторинг и предупреждение - Новая форма представления - Контекстный чувствительный совет по разрешению Более широкое внутреннее оповещение затронуло только местоположение CDN в Сиднее. Классифицируется как степень тяжести 3: Незначительное воздействие.

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

1. 22 ноября 2023 г. в 18:30 UTCinvestigating

   Примерно в 1830 году 22 ноября UTC начала обновление базы данных до нового, более мощного кластера. Несмотря на обновление, поисковые запросы API терпели неудачу.

2. 23 ноября 2023 г. в 10:35 UTCresolved

   В 1035 UTC 23 ноября обновление было завершено, и поиски возобновились. Не было простоев, и все системы работали нормально, за исключением того, что поисковые запросы API возвращали ответы на ошибки. Проблема не была выявлена, потому что другие запросы API возвращались как обычно, поэтому общие ответы на ошибки API были только слегка повышены, и не было срабатывано никаких предупреждений. Проблема была выявлена после события, после того, как сообщение пользователя вызвало расследование. Чтобы автоматически выявлять такие проблемы в будущем, мы оцениваем способы мониторинга API поиска. Мы также обновим плагин Sirv WordPress, чтобы показать четко описанное сообщение в случае неудачного поиска. Классифицируется как степень тяжести 4: минимальное воздействие.

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

1. 13 ноября 2023 г. в 20:47 UTCinvestigating

   Инструменты управления файлами на my.sirv.com загружаются медленно из-за неисправного сервера. Перечень файлов и поиск файлов занимает от 2 до 20 секунд, в то время как обычно это занимает от 1 до 4 секунд. Неисправный сервер заменяется, и мы ожидаем, что скорость вернется к норме в течение 72 часов. За этим последует значительное обновление всего кластера серверов панели управления в течение следующих 3 месяцев.

2. 14 ноября 2023 г. в 21:33 UTCinvestigating

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

3. 15 ноября 2023 г. в 14:09 UTCresolved

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

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

1. 23 октября 2023 г. в 13:10 UTCinvestigating

   Резкое увеличение числа запросов в Вашингтон 23 октября произошло в 14:10 UTC, в результате чего небольшая часть запросов была возвращена медленно - более 2 секунд. Проблема утихла в течение следующих 3 часов, хотя среднее время ответа оставалось повышенным. Проблема вернулась на следующий день в 14:32 UTC 24 октября, что более серьезно, чем раньше, вызвало медленную загрузку 17% запросов - более 2 секунд, а некоторые до 30 секунд. Проблема затронула два из 25 CDN Sirv.

2. 25 октября 2023 г. в 05:48 UTCresolved

   Вопрос был решен к 06:48 UTC 25 октября. Расследование указывает на две причины - всплеск был вызван провайдером DNS Sirv, направляющим запросы POP в Лос-Анджелес в Вашингтон. Это было бы хорошо в изоляции, но центр обработки данных, похоже, затормозил пропускную способность принимающих серверов, вызывая медленные ответы. Расследование продолжается, пока не пришло к окончательным выводам и требует сотрудничества с нашими поставщиками DNS и центров обработки данных. Уже принимаются меры для предотвращения возможного повторения этого вопроса. Полностью подробный доклад будет представлен здесь позднее.

3. 14 ноября 2023 г. в 13:37 UTCresolved

   Детальное расследование этого вопроса выявило два способствующих фактора. Первым стало обновление AWS Route53, которое было реализовано 17 октября. Это изменение не было внесено Sirv в правила Route53, а в саму услугу Route53. СОЗ в Лос-Анджелесе имела несколько иную логику маршрутизации по сравнению с другими СОЗ, и обновление AWS привело к тому, что маршрутизация вела себя по-другому, а трафик направлялся в Вашингтон. Это осталось незамеченным, поскольку более высокая нагрузка все еще находилась в пределах его возможностей, и запросы были успешно возвращены, поэтому это осталось незамеченным, поскольку Вашингтон смог справиться с дополнительной нагрузкой. Второй фактор был выше обычного трафика в пиковые часы торгов в США 23 и 24 октября. Эти два фактора привели к тому, что жесткие диски Вашингтона возвращали запросы значительно медленнее, чем обычно. С тех пор, как этот вопрос возник, мы предприняли множество действий, чтобы предотвратить его повторение; смягчить последствия аналогичных возможных инцидентов; и ускорить время разрешения в случае инцидента. Действия включают: - Применяется новая логика маршрутизации. Мощность Вашингтона была увеличена. Резервные мощности были увеличены во всех других местах CDN. Новый допуск, введенный для удаления местоположения CDN из маршрутизации. Дополнительный мониторинг диска, чтобы помочь ранней подготовке модернизации емкости. HDD заменяются SSD. Обновленная SOP для нашей группы поддержки для расследования и реагирования на аналогичные проблемы. Классифицируется как степень тяжести 3: Незначительное воздействие.

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

1. 22 мая 2023 г. в 14:57 UTCinvestigating

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

2. 22 мая 2023 г. в 15:06 UTCresolved

   Проблема разрешилась в течение 9 минут после нормализации объема загрузки. За этот период примерно 98% загрузок увенчались успехом, а 2% провалились. Загрузки API REST ограничены в час, до суммы, указанной на странице использования вашей учетной записи Sirv https://my.sirv.com/#/account/usage. Если вы используете API REST для загрузки изображений, лучше всего проверить ответ для каждого запроса на загрузку, и если вы получаете ответ на ошибку (400, 401, 429 и т. Д.), Затем приостановить загрузку и повторить попытку позже. См. документы здесь: https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide Классифицируется как степень тяжести 4: минимальное воздействие.

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

1. 22 мая 2023 г. в 11:31 UTCinvestigating

   Небольшое количество запросов на загрузку REST API терпят неудачу из-за очень высокой нагрузки.

2. 22 мая 2023 г. в 12:37 UTCresolved

   Эта проблема разрешилась, как только нагрузка на API загрузки начала падать. За этот период примерно 97% загрузок увенчались успехом, а 3% провалились. Загрузки API REST ограничены в час, до суммы, указанной на странице использования вашей учетной записи Sirv https://my.sirv.com/#/account/usage. Если вы используете API REST для загрузки изображений, лучше всего проверить ответ для каждого запроса на загрузку, и если вы получаете ответ на ошибку (400, 401, 429 и т. Д.), Затем приостановить загрузку и повторить попытку позже. См. документы здесь: https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide Классифицируется как степень тяжести 4: минимальное воздействие.

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

1. 27 апреля 2023 г. в 23:00 UTCinvestigating

   Один из серверов CDN в Лос-Анджелесе стал нездоровым и начал возвращать ошибки 4xx при 0000 UTC. Он был удален из маршрутизации через 90 секунд, а через 60 секунд весь трафик был направлен на здоровые серверы.

2. 27 апреля 2023 г. в 23:03 UTCresolved

   Проблема была автоматически решена в течение 3 минут. Классифицируется как степень тяжести 4: минимальное воздействие.

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

1. 16 марта 2023 г. в 12:17 UTCinvestigating

   Некоторые запросы в лондонский POP Sirv CDN, возвращают ошибки из-за высокой нагрузки. Этот POP обслуживает Великобританию и Ирландию. Мы работаем над резолюцией.

2. 16 марта 2023 г. в 13:33 UTCresolved

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

3. 16 марта 2023 г. в 16:22 UTCresolved

   Некоторые запросы, полученные одним из лондонских серверов CDN, не удались из-за сочетания локального разрешения DNS и пульсирующих сетевых тайм-аутов. Проблема началась в 1215 году и была решена в 1332 году. За этот период 25% запросов из Великобритании и Ирландии вернули ошибку 404 или 500. Проблема была бы решена раньше, но несвязанный отказ проверки SSL-сертификата несколькими часами ранее заблокировал оповещения от получения нашей системой мониторинга. Изменения уже были внесены, чтобы предотвратить повторение этой проблемы. Решена проблема SSL-сертификата, настроен второй уровень независимого мониторинга, опробована дополнительная автоматизация здравоохранения. Классифицируется как степень тяжести 3: Незначительное воздействие.

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

1. 23 февраля 2023 г. в 07:55 UTCresolved

   Вопрос был решен в 0755 UTC. В 0625 UTC некоторые запросы в Indore CDN POP, который обслуживает Индию, начали возвращать ответ 404 (файл не найден), вместо ответа 200 (ОК). Проблема возникла через 14 часов после обновления всех серверов CDN по всему миру. Все СОЗ вели себя хорошо, включая СОЗ Индии, но СОЗ Индора не обновлялась успешно и в конечном итоге начала возвращать ошибки. Как только проблема была выявлена, она была решена путем перераспределения обновленной информации в СОЗ Индии. В ходе инцидента 94% запросов вернули ошибку. Просьбы во все остальные страны были возвращены в обычном порядке. Чтобы предотвратить повторение этой проблемы, создается новое правило автоматического развертывания для части процесса развертывания, где была только проверка человека. Также создается дополнительная метрика оповещения, чтобы определить ситуацию, в которой развертывание потерпело неудачу. Мы приносим извинения всем клиентам, которые пострадали от этого инцидента, и мы оцениваем другие изменения, которые могут помочь предотвратить любое возможное повторение проблемы. Если возникает подобная проблема CDN, одним из немедленных решений, находящихся под вашим контролем, является временное отключение CDN в настройках Sirv здесь: https://my.sirv.com/#/account/settings/domains Классифицируется как уровень тяжести 2: Значимое воздействие.

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