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

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

   Наша команда расследует проблему, затрагивающую службу хранения объектов в US-SEA. В течение этого времени пользователи могут испытывать периодические ошибки 5xx с этой службой.

2. 25 августа 2026 г. в 00:31 UTCinvestigating

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

3. 25 августа 2026 г. в 00:55 UTCidentified

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

4. 25 августа 2026 г. в 01:11 UTCresolved

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

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

1. 21 августа 2026 г. в 17:23 UTCinvestigating

   Наша команда расследует возникающую проблему обслуживания, затрагивающую нас-море (Seattle, WA). Мы будем делиться дополнительными обновлениями, поскольку у нас есть больше информации.

2. 21 августа 2026 г. в 21:59 UTCresolved

   На данный момент мы смогли исправить проблему и служба возобновила нормальную работу.

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

1. 14 августа 2026 г. в 20:13 UTCinvestigating

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

2. 14 августа 2026 г. в 21:18 UTCinvestigating

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

3. 14 августа 2026 г. в 21:30 UTCresolved

   Мы не наблюдали никаких дополнительных проблем с подключением в нашем центре обработки данных IT-MIL (Милан) и теперь рассмотрим этот инцидент. Если вы продолжаете испытывать проблемы, пожалуйста, откройте билет поддержки для помощи.

4. 18 августа 2026 г. в 19:02 UTCpostmortem

   14 августа 2026 года, начиная примерно с 17:30 UTC, во время мероприятия в нашем центре обработки данных IT-MIL (Milan) было сработано несколько предупреждений, указывающих на то, что несколько хостов в этом центре обработки данных стали недоступными. Акамаи немедленно начал расследование и работу по восстановлению пострадавших хозяев. Во время окна воздействия клиенты испытывали периодические тайм-ауты подключения и ошибки во всех службах, развернутых в этом центре обработки данных. Мы восстановили затронутые хосты и исправили проблемы с подключением в 21:20 UTC 14 августа 2026 года. Мы все еще расследуем причину состояния неудачи. Мы привержены предотвращению будущих инцидентов и проведем тщательное расследование того, почему хозяева стали недостижимыми, реализуя меры по повышению стабильности и надежности. Это резюме дает обзор нашего текущего понимания инцидента с учетом имеющейся информации. Наше расследование продолжается, и любая информация здесь может быть изменена.

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

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

   Наша команда расследует вопрос, затрагивающий создание кластеров Linode Kubernetes Engine Enterprise (LKE-E) в дата-центре IAD2 в Вашингтоне. Это продолжение проблемы, о которой сообщалось ранее. Мы будем делиться дополнительными обновлениями, поскольку у нас есть больше информации.

2. 13 августа 2026 г. в 23:02 UTCmonitoring

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

3. 13 августа 2026 г. в 23:24 UTCresolved

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

4. 18 августа 2026 г. в 20:32 UTCpostmortem

   Между 17:25 UTC и 22:50 UTC 13 августа 2026 года клиенты Linode Kubernetes Engine Enterprise \(LKE-E\), пытающиеся развернуть специализированные экземпляры Linode G7 в нашем центре обработки данных Washington \(IAD2\), получили 403 сообщения об ошибках в обеспечении. Активные рабочие нагрузки и рабочие экземпляры не были затронуты этой проблемой. Наше расследование показало, что, хотя общая физическая аппаратная мощность в IAD2 была достаточной, запрос на предоставление вызвал сбой проверки прав из-за первоначального мягкого порога распределения хоста. Акамай решил проблему, увеличив лимит Linode-per-host с 5 до 20 в IAD2. Полные возможности развертывания были восстановлены и стабилизированы в 22:50 UTC. Чтобы предотвратить повторение, мы будем осуществлять специальное оповещение по вопросам прав и возможностей, непосредственно связанное с справочниками ответов для быстрого восстановления. Кроме того, мы создаем централизованную панель обзора мощности для активного отслеживания регионального зала заседаний. Это резюме дает обзор нашего текущего понимания инцидента с учетом имеющейся информации. Наше расследование продолжается, и любая информация здесь может быть изменена.

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

1. 13 августа 2026 г. в 18:46 UTCinvestigating

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

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

   По состоянию на 19:30 UTC удалось исправить проблему, затрагивающую API во всех регионах. Мы будем следить за этим, чтобы сервис оставался стабильным. Если вы все еще испытываете проблемы и не можете открыть билет поддержки, пожалуйста, позвоните нам по телефону 855-454-6633 (+1-609-380-7100 Intl.) или отправьте электронное письмо по адресу [email protected].

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

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

4. 14 августа 2026 г. в 00:26 UTCresolved

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

5. 17 августа 2026 г. в 17:38 UTCpostmortem

   13 августа 2026 года, примерно в 18:15 UTC, Акамай наблюдал кратковременное отключение обслуживания, затрагивающее [ api.linode.com ] (http://api.linode.com). Общее прерывание обслуживания продолжалось около 3 минут, завершившись в 18:18 UTC. После восстановления первоначального подключения повышенная задержка отклика API сохранялась до 19:06 UTC, вызывая более медленное время отклика и периодические задержки для клиентов, взаимодействующих с службами API. Чтобы устранить влияние производительности, инженерные команды Akamai выявили несоответствие конфигурации на вторичном узле инфраструктуры кэширования, которое мешало ему поглощать полную нагрузку на трафик после отказа. Инженеры завершили контролируемую миграцию и перенесли трафик кэширования запросов обратно на основной хост. После этого изменения задержка API быстро снизилась до нормального уровня. Первоначальное состояние было вызвано неожиданной перезагрузкой физического узла первичного кэширования. В то время как избыточная инфраструктура была активна, вторичный узел не мог беспрепятственно обрабатывать отказоустойчивый трафик, что привело к длительному ухудшению производительности. Наши инженерные команды проводят последующее исследование механизмов отказоустойчивости для оптимизации скорости выполнения и согласования настроек конфигурации между избыточными узлами, гарантируя, что вторичные системы могут беспрепятственно обрабатывать трафик в будущих событиях. Это резюме дает обзор нашего текущего понимания инцидента с учетом имеющейся информации. Наше расследование продолжается, и любая информация здесь может быть изменена.

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

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

   Наша команда изучает проблему, затрагивающую двигатель Linode Kubernetes (LKE). Мы будем делиться дополнительными обновлениями, поскольку у нас есть больше информации.

2. 13 августа 2026 г. в 16:30 UTCmonitoring

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

3. 13 августа 2026 г. в 17:54 UTCresolved

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

4. 17 августа 2026 г. в 21:30 UTCpostmortem

   Начиная примерно с 14:50 по 13 августа 2026 года, клиенты, которые пытались предоставить кластеры Linode Kubernetes Engine Enterprise (LKE-E) в центре обработки данных IAD2, не смогли. Мы определили, что проблема была связана с исключением двух компонентов в IAD2 в недавнем обновлении версии программного обеспечения, что привело к несоответствию API. Мы обновили идентифицированные компоненты, чтобы привести их в соответствие с ожидаемым состоянием. Это смягчило проблему примерно в 16:00 UTC 13 августа 2026 года. Чтобы предотвратить возникновение этой проблемы в будущем, мы пересматриваем процессы обновления программного обеспечения LKE, чтобы гарантировать, что все включенные компоненты будут полностью обновлены до их повторного ввода в эксплуатацию во время обновлений программного обеспечения платформы. Это резюме дает обзор нашего текущего понимания инцидента с учетом имеющейся информации. Наше расследование продолжается, и любая информация здесь может быть изменена.

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

1. 14 августа 2026 г. в 15:46 UTCresolved

   13 августа 2026 года, примерно с 14:00 до 16:30 UTC, мы наблюдали периодические сбои и задержки при предоставлении новых кластеров LKE-E в регионе Сиэтла (SEA1). Проблема, затрагивающая службу LKE-E в Сиэтле, была исправлена примерно в 16:30 UTC, и с тех пор мы не наблюдали повторения. Мы активно расследуем причину. Мы продолжим следить за службой стабильности. Если у вас возникли какие-либо проблемы с этой услугой, пожалуйста, откройте билет поддержки для помощи.

2. 21 августа 2026 г. в 13:13 UTCpostmortem

   On August 13, 2026, between approximately 14:30 and 16:30 UTC, Akamai experienced an issue affecting Linode Kubernetes Engine Enterprise \(LKE-E\) cluster provisioning and deployment in the Seattle \(SEA1\) region. During this time, customers attempting to create new clusters encountered failures or delays. In some cases, clusters were created but nodes were not fully provisioned, while in others, the control plane responsible for managing the cluster could not be deployed. Akamai identified the issue through customer reports, which was then validated by reproducing the failures in Seattle-based test clusters. Other regions continued to operate normally, and no existing customer workloads were impacted. By around 16:30 UTC on August 13, 2026, cluster provisioning and deployment in the Seattle region returned to normal, allowing new cluster creations to proceed without issue. After recovery, we monitored the region for several days and began a technical investigation into the service disruption. Initial findings indicate a correlation between the issue and a recent network configuration update that occurred at approximately 14:30 UTC and was rolled back at approximately 14:45 UTC. Our current hypothesis suggests that a timing conflict during the cluster provisioning process may have triggered the failures. We are continuing to investigate the technical details to confirm the root cause. We are continuing to investigate the technical details behind this issue and are working to ensure it does not recur. We will also review the scope of affected data centers and track corrective actions. This summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing and any information herein is subject to change.

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

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

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

2. 11 августа 2026 г. в 23:35 UTCinvestigating

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

3. 12 августа 2026 г. в 03:29 UTCidentified

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

4. 21 августа 2026 г. в 18:40 UTCresolved

   Мы можем подтвердить, что проблема была смягчена в 06:30 UTC 20 августа 2026 года и служба возобновила нормальную работу.

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

1. 31 июля 2026 г. в 17:49 UTCinvestigating

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

2. 31 июля 2026 г. в 18:25 UTCidentified

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

3. 4 августа 2026 г. в 18:36 UTCidentified

   We are continuing to work with our upstream provider to resolve the packet loss affecting some paths between the in-maa and in-bom-2 data centers and the US region. We will share further updates as progress continues.

4. 5 августа 2026 г. в 01:34 UTCresolved

   At this time the upstream provider has been able to correct the issue causing packet loss on some routes from the in-maa & in-bom-2 data centers into the US region and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

5. 5 августа 2026 г. в 17:49 UTCpostmortem

   On July 31, 2026, at approximately 10:00 UTC, Akamai observed intermittent network losses affecting compute users accessing US locations from our India sites \(MAA and BOM\). Customers’ services in North America, particularly the Miami data center region, experienced increased latency, intermittent connectivity issues, slower data transfers, and difficulty reaching certain applications or services. Performance was unstable, with periods of normal operation followed by disruptions. To address the issue, Akamai applied a deny-all policy to the impacted upstream provider transit link, redirecting traffic around the impacted routes. Despite this mitigation, ongoing IPv6 losses occurred due to congestion between two alternative upstream providers, impacting some users. One provider acknowledged a bottleneck in the Asia region, and the alternate provider worked to reroute traffic away from affected links.  The initial impacted service provider confirmed that two fiber cuts in Mexico caused congestion on the impacted routes. One of these fiber cuts was resolved at 23:43 UTC on July 31, 2026, and no further issues were observed following this mitigation.  This summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing and any information herein is subject to change.

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

1. 28 июля 2026 г. в 18:14 UTCinvestigating

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

2. 28 июля 2026 г. в 19:27 UTCidentified

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

3. 28 июля 2026 г. в 20:17 UTCidentified

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

4. 28 июля 2026 г. в 22:51 UTCmonitoring

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

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

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

6. 31 июля 2026 г. в 18:57 UTCpostmortem

   27 июля 2026 года в 3:30 UTC Акамай наблюдал увеличение ошибок при подключении к базе данных хостинга Linode, в первую очередь влияющих на объемные вложения Block Storage. Это привело к сбоям в работе хоста и ограниченному влиянию на клиента, при этом некоторые пользователи испытывали сообщения об ошибках и прерывали рабочие процессы. Повышенные показатели тайм-аута были отмечены в журналах для определенных местоположений центров обработки данных, что совпало с постепенным развертыванием нового флага функции. Первоначальное расследование выявило периодические падения пакетов из прокси-сервера базы данных на хосты клиентов во время рукопожатия TLS. Нынешняя теория предполагает, что был достигнут предел DDoS-защиты, связанный со слишком большими ICMP-сообщениями. Когда прокси-сервер отправлял пакеты TCP с большим MTU, ожидаемые сообщения ICMP были сброшены маршрутизаторами шлюза Далласа из-за превышения настроенной допустимой скорости. Это привело к подключению прокси-сервера базы данных TCP к тайм-ауту для вычислительных хостов. Проблема была вызвана включением нового флага функции, который изменил путь маршрутизации и удалил зажим MTU до того, как пакеты достигли шлюзов. Чтобы смягчить проблему, Akamai откатила последние изменения в сети на пострадавших сайтах Compute, начиная с 20:50 UTC. По состоянию на 22:57 UTC скорость перезапуска услуг вернулась к доинцидентным уровням. Akamai также планирует внести изменения, чтобы увеличить допустимый порог для пакетов слишком больших сообщений ICMP. Это резюме дает обзор нашего текущего понимания инцидента с учетом имеющейся информации. Наше расследование продолжается, и любая информация здесь может быть изменена.

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

1. 20 июля 2026 г. в 01:52 UTCinvestigating

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

2. 20 июля 2026 г. в 02:56 UTCinvestigating

   Мы продолжаем расследование этого вопроса. Мы предоставим следующее обновление по мере продвижения вперед.

3. 20 июля 2026 г. в 03:12 UTCinvestigating

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

4. 20 июля 2026 г. в 03:20 UTCmonitoring

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

5. 20 июля 2026 г. в 04:10 UTCresolved

   Мы не наблюдали никаких дополнительных проблем с подключением в нашем центре обработки данных в Милане (Италия), и теперь рассмотрим этот инцидент. Если вы продолжаете испытывать проблемы, пожалуйста, откройте билет поддержки для помощи.

6. 20 июля 2026 г. в 05:45 UTCpostmortem

   Начиная примерно с 00:33 20 июля 2026 года, некоторые хосты в центре обработки данных Милана, Италия, стали недоступны, что повлияло на доступ клиентов к Linodes. Следствие установило, что эта проблема возникла во время запланированных обновлений прошивки маршрутизатора. Несмотря на то, что мы следуем поэтапному процессу обновления, чтобы предотвратить сбои в обслуживании, неожиданное пересечение параллельных мероприятий по техническому обслуживанию привело к временной потере сетевого подключения для пострадавших хостов. Сервис был полностью восстановлен к 02:16 UTC 20 июля 2026 года, и все системы теперь работают, как и ожидалось. Внутренне мы пересматриваем наши процедуры управления изменениями и планирования технического обслуживания, чтобы обеспечить лучшую координацию и предотвратить подобные проблемы в будущем. Мы приносим извинения за последствия и благодарим вас за терпение и постоянную поддержку. Мы стремимся постоянно совершенствовать наши системы и предотвращать их повторение. Это резюме дает обзор нашего текущего понимания инцидента с учетом имеющейся информации. Наше расследование продолжается, и любая информация здесь может быть изменена.

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

1. 18 июля 2026 г. в 03:34 UTCinvestigating

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

2. 18 июля 2026 г. в 03:54 UTCidentified

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

3. 18 июля 2026 г. в 04:36 UTCresolved

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

4. 21 июля 2026 г. в 15:26 UTCpostmortem

   18 июля 2026 года, примерно между 00:30 UTC и 04:00 UTC, пользователи могли испытывать ошибки 5xx при попытке создать новое ведро в хранилище объектов для следующих конечных точек. * [us-ord-1.linodeobjects.com] (http://us-ord-1.linodeobjects.com) * [us-lax-1.linodeobjects.com] (http://us-lax-1.linodeobjects.com) * [us-iad-1.linodeobjects.com] (http://us-iad-1.linodeobjects.com) * [us-sea-1.linodeobjects.com] (http://us-sea-1.linodeobjects.com) * [fr-par-1.linodeobjects.com] (http://fr-par-1.linodeobjects.com) Проблема началась, когда инфраструктура, поддерживающая Object Storage, вошла в деградировавшее состояние во всех узлах. Это мешало сервису обрабатывать запросы, что приводило к сбоям во время операций по созданию ковша. Чтобы смягчить воздействие, мы применили исправление в бэкэнд-системе, отвечающей за создание ведра. Последствия были смягчены после этого действия. Наши специалисты исследуют первопричину и предпримут соответствующие профилактические действия. Мы приносим извинения за влияние и ценим ваше терпение и постоянную поддержку. Мы вносим изменения в конфигурацию и работу наших систем, чтобы предотвратить повторение этого, и стремимся к постоянному совершенствованию. Это резюме дает обзор нашего текущего понимания инцидента, учитывая имеющуюся информацию. Наше расследование продолжается, и любая информация здесь может быть изменена.

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

1. 16 июля 2026 г. в 01:24 UTCresolved

   Наша команда исследовала проблему, которая повлияла на связь в нашем центре обработки данных US-MIA (Miami) между 21:20 UTC и примерно 23:28 UTC 15 июля 2026 года. Во время этого окна пользователи могли испытывать ухудшение сетевой производительности и потерю пакетов для вычислительных служб, развернутых в этом регионе. Вопрос был решен после того, как мы внедрили исправление. Мы продолжаем работать с нашим сторонним поставщиком услуг, чтобы подтвердить первопричину, поскольку первоначальные доказательства указывают на перекрёстное соединение кампуса (темное волокно) на их инфраструктуре.

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

1. 14 июля 2026 г. в 12:21 UTCinvestigating

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

2. 14 июля 2026 г. в 12:58 UTCidentified

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

3. 14 июля 2026 г. в 13:11 UTCmonitoring

   На данный момент мы смогли исправить проблему, затрагивающую Cloud Manager и API. Мы будем следить за этим, чтобы сервис оставался стабильным. Если вы все еще испытываете проблемы и не можете открыть билет поддержки, пожалуйста, позвоните нам по телефону 855-454-6633 (+1-609-380-7100 Intl.) или отправьте электронное письмо по адресу [email protected].

4. 14 июля 2026 г. в 18:36 UTCmonitoring

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

5. 14 июля 2026 г. в 19:26 UTCresolved

   Мы не наблюдали никаких дополнительных проблем с Cloud Manager, API или CLI, и теперь рассмотрим этот инцидент. Если вы продолжаете испытывать проблемы, пожалуйста, свяжитесь с нами по телефону 855-454-6633 (+1-609-380-7100 Intl.) или отправьте электронное письмо по адресу [email protected] для получения помощи.

6. 16 июля 2026 г. в 18:13 UTCpostmortem

   14 июля 2026 года в 10:57 UTC Акамай выявил увеличение 502 ошибок и задержки, влияющих на клиентов, использующих API Linode, CLI и Cloud Manager. Это нарушение привело к умеренному влиянию сервиса, когда клиенты сообщали о повышенных показателях ошибок. Наше первоначальное расследование привело к задержке с услугами IAM, которая была решена, но повышенные ошибки сохранялись. Дальнейший анализ, проведенный соответствующими экспертами, показал, что инцидент был вызван ручным отказом от основного балансира нагрузки Cloud IAM. Это действие было вызвано предупреждением о том, что вторичный балансировщик нагрузки действует как хранимый мастер. Ручной процесс запуска и остановки служб для инициирования отказа отличался от автоматизированного процесса и приводил к каскаду устаревших соединений GRPC, вызывая увеличение задержки и ошибок API. Перезапуск серверов API позволил очистить устаревшие соединения и восстановить нормальные операции. Влияние клиентов было смягчено примерно в 13:10 по 14 июля 2026 года. Чтобы предотвратить рецидив, Акамай исследует, почему ручной отказ вызвал такое поведение. Команда рассматривает возможность реализации команды дренажа для очистки соединений GRPC во время отказоустойчивости и настройки предупреждений для обнаружения устаревших соединений для проактивного вмешательства. Тем не менее, основное внимание по-прежнему уделяется пониманию первопричины, а оповещение и автоматизация запланированы на более поздних этапах. Несколько клиентов подтвердили разрешение в своих развертываниях. Akamai будет продолжать следить за состоянием системы и ждать дополнительных отзывов клиентов, прежде чем объявить о полном восстановлении. Это резюме дает обзор нашего текущего понимания инцидента с учетом имеющейся информации. Наше расследование продолжается, и любая информация здесь может быть изменена.

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

1. 13 июля 2026 г. в 18:29 UTCidentified

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

2. 13 июля 2026 г. в 19:54 UTCresolved

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

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

1. 9 июля 2026 г. в 16:57 UTCinvestigating

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

2. 9 июля 2026 г. в 17:24 UTCinvestigating

   Мы продолжаем расследование этого вопроса. Мы предоставим обновление в течение следующих 30 минут.

3. 9 июля 2026 г. в 17:49 UTCmonitoring

   На данный момент мы смогли исправить проблему, затрагивающую логины Cloud Manager. Мы будем следить за этим, чтобы сервис оставался стабильным. Если вы все еще испытываете проблемы и не можете открыть билет поддержки, пожалуйста, позвоните нам по телефону 855-454-6633 (+1-609-380-7100 Intl.) или отправьте электронное письмо по адресу [email protected].

4. 9 июля 2026 г. в 18:21 UTCresolved

   Мы не заметили никаких дополнительных проблем с логинами Cloud Manager и теперь рассмотрим этот инцидент. Если вы продолжаете испытывать проблемы, пожалуйста, свяжитесь с нами по телефону 855-454-6633 (+1-609-380-7100 Intl.) или отправьте электронное письмо по адресу [email protected] для получения помощи.

5. 10 июля 2026 г. в 12:30 UTCpostmortem

   9 июля 2026 года в 15:43 UTC клиенты не смогли войти в [cloud.linode.com] (http://cloud.linode.com) с использованием имени пользователя и пароля. Клиенты получали сообщение об ошибке «неправильный пароль». Расследование показало, что проблема была вызвана внутренней выдачей сертификата. Чтобы смягчить последствия, мы зафиксировали выдачу сертификата на пострадавших серверах в 17:24 UTC 9 июля 2026 года. После некоторого мониторинга наших систем мы подтвердили, что проблема полностью решена. Akamai развернет постоянное исправление, чтобы предотвратить повторение проблемы.

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

1. 6 июля 2026 г. в 18:04 UTCinvestigating

   Our team is investigating an emerging service issue affecting Managed Databases across all regions. Customers may experience latency when provisioning new databases or deleting existing ones. There is no observed impact to the performance or availability of active, running databases at this time. We will provide updates as more information becomes available.

2. 7 июля 2026 г. в 15:31 UTCresolved

   This incident has been resolved.

1. 1 июля 2026 г. в 17:21 UTCidentified

   Our team is investigating a service issue that affects the auto configuration of networking on Linodes by Network Helper to fail. During that time, some users may have Linodes provision but appear to have no connectivity. This also can impact Linodes created by the Linode Kubernetes Engine and impact autoscaling or provisioning of clusters. Customers can still manually configure networking via the LISH console to mitigate this issue. Please see our guide on manual network configuration on a Compute Instance . We will share additional updates as we have more information.

2. 1 июля 2026 г. в 18:09 UTCmonitoring

   A fix has been implemented to resolve the automated network configuration issue on Linodes using Network Helper. We recommend rebooting your Linode to restore full network functionality. We are actively monitoring the results to ensure continued stability.

3. 1 июля 2026 г. в 18:28 UTCresolved

   We haven’t observed any additional issues with the Linode Automated Networking service, and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

1. 30 июня 2026 г. в 18:54 UTCinvestigating

   Our team is investigating an emerging issue affecting the Block Storage service in our Singapore Expansion, SP (sg-sin-2) data center. During this time, users may experience connection timeouts and errors with this service. We will share additional updates as we have more information.

2. 30 июня 2026 г. в 19:55 UTCinvestigating

   We are continuing to investigate this issue.

3. 30 июня 2026 г. в 20:36 UTCidentified

   Our team has identified the issue affecting the Block Storage service in our Singapore Expansion, SP (sg-sin-2) data center. We are working quickly to implement a fix, and we will provide an update as soon as the solution is in place.

4. 30 июня 2026 г. в 21:36 UTCidentified

   We are continuing to work on a fix for this issue.

5. 30 июня 2026 г. в 22:10 UTCmonitoring

   At this time we have been able to correct the issues affecting the Block Storage service. We will be monitoring this to ensure that it remains stable. If you continue to experience problems, please open a Support ticket for assistance.

6. 30 июня 2026 г. в 23:22 UTCresolved

   We haven’t observed any additional issues with the Block Storage service in Singapore Expansion, SP (sg-sin-2), and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

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

   On June 30, 2026, between approximately 17:30 UTC and 21:45 UTC, users may have experienced connection timeouts and errors related to the Block Storage service in Singapore Expansion, SP \(sg-sin-2\). The issue began when one host in the cluster was taken down for maintenance while another host unexpectedly encountered network issues. A configuration issue also contributed to the impact. These factors led to a degraded state that affected performance and, to a limited extent, data availability. We mitigated the impact to customers at 21:45 UTC on June 30, 2026 by correcting the network, configuration and cluster issues. We apologize for the impact and appreciate your patience and ongoing support. We are making configuration and operational changes to our systems to help prevent this from happening again, and remain committed to continuous improvement. This summary provides an overview of our current understanding of the incident, given the information available. Our investigation is ongoing, and any information herein is subject to change.

1. 26 июня 2026 г. в 17:35 UTCinvestigating

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

2. 26 июня 2026 г. в 18:19 UTCinvestigating

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

3. 26 июня 2026 г. в 19:08 UTCinvestigating

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

4. 26 июня 2026 г. в 20:04 UTCinvestigating

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

5. 26 июня 2026 г. в 21:13 UTCmonitoring

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

6. 30 июня 2026 г. в 00:02 UTCmonitoring

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

7. 8 июля 2026 г. в 12:26 UTCresolved

   Мы не наблюдали никаких дополнительных проблем с сервисом Cloud Pulse Metrics (ACLP Metrics), и теперь рассмотрим этот инцидент. Если вы продолжаете испытывать проблемы, пожалуйста, откройте билет поддержки для помощи.

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