Pull to refresh

Comments 31

http://www.theverge.com/2017/2/28/14765042/amazon-s3-outage-causing-trouble

ахаха, вопрос дня на многих it-форумах «How we connect to Amazon Support?»)
Мне больше всего понравилось, что пользователи мышек фирмы Razer не могли изменить DPI, т.к. для этого нужно, вероятно, соединение с Amazon. Такое чувство, что технологическая сингулярность уже наступила.
Это сингулярность глупости наступает.
Я все боюсь, что наступит тот день, когда меня холодильник не пустит к моему супчику из-за проблем с соединением с Amazon.
Будет забавно когда сервера Amazon не смогут запуститься работать, так как им нужно соединение с Amazon.
Вчера в это же время, впервые временно был недоступен мобильный банк ТКС. Совпадение?
Netflix пишет, что быстро восстановился за счет устойчивой к сбоям архитектуре.
статья старая — Dynamodb в сентябре падал
UFO just landed and posted this here
В отличие от падения гитлаба, где в момент эпик фейла ребята запустили онлайн трансляцию восстановления, Amazon лишь иногда выдавал скупые сообщения в твиттер из серии «мы обнаружили корень проблемы и работаем над этим».


Вот с каких пор амазон или любая другая компания должна разворачивать клоунаду такого масштаба, как это сделали gitlab? Или это стало стандарт де-факто в случае каких либо инцидентов?
Да, было весело, многие посмеялись, а некоторые сделали вывод.

П.С. Топик по своей информативности, практически нулевой.
«Клоунаду» с трансляцией можно считать чем-то ненормальным, согласен.
Но и несколько постов в твиттере, без существенных деталей, когда упало пол интернета — тоже не очень хорошо, не так ли?

> П.С. Топик по своей информативности, практически нулевой.
Ну так в том-то и дело, что особо не где было ее взять.
Саппорт у амазона достаточно бодро отвечает.
сначала fix, потом объяснение. У нас инфраструктура так же вчера попала под раздачу и я конечно хотел бы узнать, что случилось, но в первую очередь я бы хотел получить fix.

gitlab утроил трансляцию исключительно из-за того, что поднимали они долго. В таких условиях это нормальный ход. У Amazon все заняло около 3х часов. Не то время, что устраивать шоу. Плюс они более корпоративная компания — подготовить официальный анонс с полным анализом и опубликуют.
Да, сначала фикс, здесь согласен
downtime сервиса не должен превышать 53 минуты в год («Расчетная доступность на уровне 99,99% в течение года")

не в течении года. У них по SLA 99.9% в месяц, что дает 43 минуты в месяц. А в год получается почти 8.5 часов.
Да, но у них в SLA по ссылке в новости не 99.9%, а 99.0%! Грубо, это по 7 часов даунтайма в месяц (на самом деле там все сложнее — если количество ошибок деленное на количество запросов в среднем за 5 минут будет больше и т.п., но не думаю что станет сильно лучше).

У нас перестали работать два препродакшен сервера (статика лежит на s3). Продакшен почему-то не отвалился, хотя на нем тоже статика на S3, повезло.


Самое прикольное в этой ситуации что наш CI-сервер деплоит так же через S3 и естественно ничего не получалось обновить через него. Пришлось по-старинке. Собирать все у себя и деплоить руками.

Ну упали, бывает, больше всего расстраивает в этой ситуации,
что многие сервисы до сих пор не поняли что нельзя быть зависимым от одного ДЦ.
Ведь трактористы, которые выкапывают оптику и котята, которые залазят в трансформаторы есть по всему миру. :(

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

сравнение гитлаб и амазона порадовало :)

А мы статику раздаем через Cloudfront с ориджином на S3. Все нормально было, Cloudfront не затронуло. Хотя я из-за сбоя не смог применить темплейт для Clodformation. Было обидно, но не смертельно

в Богдаде всё спокойно
Багдад пишется через букву А.

Забыли ещё то, что часть гитхаба не работала. Файлы не скачивались, например.
Imgur так же не работал в это время
Кстати во время проблем, так же не смог изменить правила в Security Group в EC2 (регион Франкфурт) :(
After some investigation we now know what happened to S3. You can read the details here: https://aws.amazon.com/message/41926/

"… At 9:37AM PST, an authorized S3 team member using an established playbook executed a command which was intended to remove a small number of servers for one of the S3 subsystems that is used by the S3 billing process. Unfortunately, one of the inputs to the command was entered incorrectly and a larger set of servers was removed than intended ..."
Sign up to leave a comment.

Articles