1 марта в 05:42

Amazon S3 около трех-четырех часов работал с перебоями, Medium, Slack, Coursera, Trello лежали

Примерно с 9 вечера до часу ночи по Московскому времени были перебои с работой облачного хранилища Amazon S3. Началось это с сообщения в твиттер «S3 is experiencing high error rates. We are working hard on recovering», хотя мир узнал об этом раньше: перестали работать (полностью или частично) сайты Medium, Slack, Coursera, Trello, Adobe и еще куча.

При этом некоторое время не работала страница со статусами status.aws.amazon.com. Ну как не работала — она работала, но показывала, что все хорошо, в Багдаде всё спокойно, «Service is operating normally».

Дополнение от ValdikSS: пользователи мышек фирмы Razer не могли изменить DPI, т.к. для этого нужно, вероятно, соединение с Amazon.

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

Детальной информации о том, в чем был корень проблемы, пока что нет, надеюсь, будет какой-то подробный пресс-релиз

[Исправлено] Service Level Agreement с допустимым uptime можно посмотреть здесь.

Официальный твиттер
Антон Околелов @varanio
карма
108,2
рейтинг 4,9
Руководитель отдела разработки
Похожие публикации
Самое читаемое Администрирование

Комментарии (31)

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

    ахаха, вопрос дня на многих it-форумах «How we connect to Amazon Support?»)
  • +23
    Мне больше всего понравилось, что пользователи мышек фирмы Razer не могли изменить DPI, т.к. для этого нужно, вероятно, соединение с Amazon. Такое чувство, что технологическая сингулярность уже наступила.
    • 0
      Шикарно!
    • +2
    • +7
      Это сингулярность глупости наступает.
    • +4
      Я все боюсь, что наступит тот день, когда меня холодильник не пустит к моему супчику из-за проблем с соединением с Amazon.
      • 0
        Будет забавно когда сервера Amazon не смогут запуститься работать, так как им нужно соединение с Amazon.
  • 0
    Вчера в это же время, впервые временно был недоступен мобильный банк ТКС. Совпадение?
  • 0
    Netflix пишет, что быстро восстановился за счет устойчивой к сбоям архитектуре.
    • 0
      статья старая — Dynamodb в сентябре падал
    • +2
      Да просто потому что они присутствуют во всех регионах. А у Амазона проблема была только в одном из них.
  • +1
    В отличие от падения гитлаба, где в момент эпик фейла ребята запустили онлайн трансляцию восстановления, Amazon лишь иногда выдавал скупые сообщения в твиттер из серии «мы обнаружили корень проблемы и работаем над этим».


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

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

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

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

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

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


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

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

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

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

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

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

    Забыли ещё то, что часть гитхаба не работала. Файлы не скачивались, например.
    • 0
      Спс, поправил
  • 0
    Imgur так же не работал в это время
  • +3
    https://aws.amazon.com/message/41926/

    а вот и более детальная информация о причине сбоя
  • 0
    Кстати во время проблем, так же не смог изменить правила в Security Group в EC2 (регион Франкфурт) :(
  • +1
    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 ..."

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