05.07.2019
После серьезного сбоя в Google Cloud в июне месяце, который возник по причине некорректной конфигурации Google Cloud Platform (GCP), корпорация Google столкнулась с еще одной серьезной проблемой. На этот раз Google не признает, что произошел сбой в работе, хотя это вызвало всплеск задержки для клиентов.
После серьезного сбоя в Google Cloud в июне месяце, который возник по причине некорректной конфигурации Google Cloud Platform (GCP), корпорация Google столкнулась с еще одной серьезной проблемой. На этот раз Google не признает, что произошел сбой в работе, хотя это вызвало всплеск задержки для клиентов.
Google заявил, что сбои в работе облачной сети Google были вызваны физическими поврежденными оптоволоконных кабелей в дата-центре us-east1 в Южной Каролине.
Информация о проблеме была впервые опубликована в 10:25 по тихоокеанскому времени на странице состояния Google, на которой есть несколько обновлений, в которых подробно описан ответ и объяснение причин сбоев.
Google снизил количество поврежденных волоконно-оптических линий, «выборочно перенаправив некоторый трафик, чтобы обеспечить надежную работу сервисов клиентов до тех пор, пока не будут восстановлены поврежденные оптоволоконные пути».
Несмотря на эти меры, провайдер облачных услуг предупредил, что у некоторых клиентов будет наблюдаться задержка, превышающая обычную, до тех пор, пока он не исправит поврежденное оптоволокно, что он ожидает сделать в течение следующих 24 часов, и полностью устранит проблемы с задержкой.
Человек, который утверждал, что работает на Google Cloud, используя дескриптор «boulos» на Hacker News, заскочил в ветку на сайте, чтобы исправить комментарии о том, что проблема с сетью означала, что регион «не работает», хотя Булос признал, что «задержка в сети увеличилась для внешняя связь плохая ".
Другой пользователь Hacker News, mrweasel, оспорил объяснение того, что регион технически не остановился.
«Как сказал один из моих старых боссов: меня не волнует, что сайт / служба технически работают, если клиенты не могут добраться до них, то ЭТО СЛОМАН», - пишет mrweasel.
Другой пользователь сказал, что босс mrweasel «придирается» к словам во время кризиса и жертвует «точностью и пониманием».
Mrweasel возразил, что это было точно: «С точки зрения бизнеса сайт был закрыт. Nitpicking говорит ему: нет, это на самом деле, клиент просто не может его использовать».
Болус объяснил, что они вмешались из-за «путаницы» среди комментаторов, которые утверждали, что регион находится в упадке.
«Во время сбоя время передачи сообщений является непростым, поэтому короткие исправления лучше, пока не будет сделано полное посмертное вскрытие», - пишет Булос.
«Дэвид-Како», который утверждал, что работает на AWS, сказал: «Я работаю на AWS. Как правило, необходимо соблюдать баланс при обмене информацией с клиентами. Я полагаю, что это подходит для большинства компаний, поэтому только после вскрытия сообщения полностью очищены ".
Как и Google, популярный поставщик CDN Cloudflare потерпел два перебоя на прошлой неделе и много объяснил. Первым виновата ошибка интернет-маршрутизации Verizon, которая вызвала «катастрофический сбой каскадирования».
Второе, во вторник, было вызвано внутренним «развертыванием плохого программного обеспечения», которое вызвало беспрецедентный всплеск ЦП на его оборудовании. Отключение длилось всего 30 минут, но повлияло на все центры обработки данных Cloudflare по всему миру.
Посетители сайтов, которые зависят от Cloudflare, были встречены с 502 сообщениями об ошибках «плохой шлюз».
Технический директор Cloudflare Джон Грэм-Камминг (John Graham-Cumming) с тех пор обнаружил, что неправильное развертывание программного обеспечения фактически было «единым неправильно настроенным правилом в межсетевом экране Cloudflare Web Application Firewall (WAF) во время обычного развертывания новых правил Cloudflare WAF Managed», предназначенных для усиления защиты от атак JavaScript.
«К сожалению, одно из этих правил содержало регулярное выражение, которое вызывало скачок ЦП на наших машинах во всем мире до 100 процентов. Этот скачок на 100 процентов вызвал 502 ошибки, которые видели наши клиенты. В худшем случае трафик сократился на 82 процента», - написал Грэм. -Cumming.
Он признал, что процедуры тестирования компании были «недостаточными», и сказал, что они в настоящее время пересматриваются. Широкое влияние было вызвано тем, что новые правила WAF были «развернуты глобально за один раз».
ОБНОВЛЕНИЕ 4 июля : Google сообщил, что проблемы облачной сети и балансировки нагрузки Google были решены по состоянию на среду, 3 июля, 7:35 по тихоокеанскому времени, то есть сбои продолжались около 21 часа.
Компания подтвердила, что восстановила поврежденные волоконные жгуты и вернула регион us-east1 в нормальное состояние. Также будет проведена внутренняя проверка инцидента и внесены соответствующие улучшения.
Google заявил, что сбои в работе облачной сети Google были вызваны физическими поврежденными оптоволоконных кабелей в дата-центре us-east1 в Южной Каролине.
Информация о проблеме была впервые опубликована в 10:25 по тихоокеанскому времени на странице состояния Google, на которой есть несколько обновлений, в которых подробно описан ответ и объяснение причин сбоев.
Google снизил количество поврежденных волоконно-оптических линий, «выборочно перенаправив некоторый трафик, чтобы обеспечить надежную работу сервисов клиентов до тех пор, пока не будут восстановлены поврежденные оптоволоконные пути».
Несмотря на эти меры, провайдер облачных услуг предупредил, что у некоторых клиентов будет наблюдаться задержка, превышающая обычную, до тех пор, пока он не исправит поврежденное оптоволокно, что он ожидает сделать в течение следующих 24 часов, и полностью устранит проблемы с задержкой.
Человек, который утверждал, что работает на Google Cloud, используя дескриптор «boulos» на Hacker News, заскочил в ветку на сайте, чтобы исправить комментарии о том, что проблема с сетью означала, что регион «не работает», хотя Булос признал, что «задержка в сети увеличилась для внешняя связь плохая ".
Другой пользователь Hacker News, mrweasel, оспорил объяснение того, что регион технически не остановился.
«Как сказал один из моих старых боссов: меня не волнует, что сайт / служба технически работают, если клиенты не могут добраться до них, то ЭТО СЛОМАН», - пишет mrweasel.
Другой пользователь сказал, что босс mrweasel «придирается» к словам во время кризиса и жертвует «точностью и пониманием».
Mrweasel возразил, что это было точно: «С точки зрения бизнеса сайт был закрыт. Nitpicking говорит ему: нет, это на самом деле, клиент просто не может его использовать».
Болус объяснил, что они вмешались из-за «путаницы» среди комментаторов, которые утверждали, что регион находится в упадке.
«Во время сбоя время передачи сообщений является непростым, поэтому короткие исправления лучше, пока не будет сделано полное посмертное вскрытие», - пишет Булос.
«Дэвид-Како», который утверждал, что работает на AWS, сказал: «Я работаю на AWS. Как правило, необходимо соблюдать баланс при обмене информацией с клиентами. Я полагаю, что это подходит для большинства компаний, поэтому только после вскрытия сообщения полностью очищены ".
Как и Google, популярный поставщик CDN Cloudflare потерпел два перебоя на прошлой неделе и много объяснил. Первым виновата ошибка интернет-маршрутизации Verizon, которая вызвала «катастрофический сбой каскадирования».
Второе, во вторник, было вызвано внутренним «развертыванием плохого программного обеспечения», которое вызвало беспрецедентный всплеск ЦП на его оборудовании. Отключение длилось всего 30 минут, но повлияло на все центры обработки данных Cloudflare по всему миру.
Посетители сайтов, которые зависят от Cloudflare, были встречены с 502 сообщениями об ошибках «плохой шлюз».
Технический директор Cloudflare Джон Грэм-Камминг (John Graham-Cumming) с тех пор обнаружил, что неправильное развертывание программного обеспечения фактически было «единым неправильно настроенным правилом в межсетевом экране Cloudflare Web Application Firewall (WAF) во время обычного развертывания новых правил Cloudflare WAF Managed», предназначенных для усиления защиты от атак JavaScript.
«К сожалению, одно из этих правил содержало регулярное выражение, которое вызывало скачок ЦП на наших машинах во всем мире до 100 процентов. Этот скачок на 100 процентов вызвал 502 ошибки, которые видели наши клиенты. В худшем случае трафик сократился на 82 процента», - написал Грэм. -Cumming.
Он признал, что процедуры тестирования компании были «недостаточными», и сказал, что они в настоящее время пересматриваются. Широкое влияние было вызвано тем, что новые правила WAF были «развернуты глобально за один раз».
ОБНОВЛЕНИЕ 4 июля : Google сообщил, что проблемы облачной сети и балансировки нагрузки Google были решены по состоянию на среду, 3 июля, 7:35 по тихоокеанскому времени, то есть сбои продолжались около 21 часа.
Компания подтвердила, что восстановила поврежденные волоконные жгуты и вернула регион us-east1 в нормальное состояние. Также будет проведена внутренняя проверка инцидента и внесены соответствующие улучшения.
