company_banner

Habr postmortem report: на газетку упало

    Конец первого и начало второго месяца лета 2019 года выдались непростыми и ознаменовались несколькими крупными падениями мировых IT-сервисов. Из заметных: два серьёзных инцидента в инфраструктуре CloudFlare (первый — с кривыми руками и халатным отношением к BGP со стороны некоторых ISP из США; второй — с кривым деплоем уже самих CF, повлияло на всех, пользующихся CF, а это многие заметные сервисы) и нестабильная работа инфраструктуры Facebook CDN (повлияло на все продукты FB, включая Instagram и WhatsApp). Под раздачу пришлось попасть и нам, хотя наш outage был куда менее заметен на мировом фоне. Кто-то стал уже приплетать чёрные вертолёты и «суверенные» заговоры, посему выпускаем публичный post mortem нашего инцидента.



    03.07.2019, 16:05
    Начали фиксировать проблемы с ресурсами, похожие на нарушение внутренней сетевой связности. Не до конца всё проверив, стали грешить на работоспособность внешнего канала в сторону ДатаЛайн, так как стало понятно, что проблема с доступом внутренней сети в интернет (NAT), вплоть до того, что положили BGP-сессию в сторону DataLine.

    03.07.2019, 16:35
    Стало очевидно, что вышло из строя оборудование, осуществляющее трансляцию сетевых адресов и доступ из локальной сети площадки в Интернет (NAT). Попытки перезагрузить оборудование ни к чему не привели, поиск альтернативных вариантов организации связности начался до получения ответа от техподдержки, так как по опыту, это бы скорее всего не помогло.

    Проблема несколько усугубилась тем, что данное оборудование также терминировало входящие подключения клиентских VPN сотрудников, удалённые работы по восстановлению стало проводить сложнее.

    03.07.2019, 16:40
    Попытались реанимировать ранее существовавшую запасную схему NAT, которая работала сильно до этого. Но стало понятно, что ряд переоборудований сети сделали данную схему практически полностью нерабочей, так как её восстановление могло в лучшем случае не сработать, в худшем сломать уже работающее.

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

    03.07.2019, 17:05
    Параллельно выявилась проблема в механизме разрешения имён на name-серверах, что привело к ошибкам резолвинга эндпойнтов в приложениях, начали оперативно наполнять hosts-файлы записями критически важных сервисов.

    03.07.2019, 17:27
    Восстановлена ограниченная работоспособность Хабра.

    03.07.2019, 17:43
    Но в итоге, было найдено относительно безопасное решение организации пропуска трафика всё же именно через один из пограничных маршрутизаторов, что и было быстро вкорячено. Связность с интернетом восстановилась.

    В течение ближайших минут от систем мониторинга пришла масса уведомлений о восстановлении работоспособности агентов мониторинга, однако часть сервисов оказалась неработоспособной, так как был нарушен механизм разрешения имён на name-серверах (dns).



    03.07.2019, 17:52
    Были перезапущены NS, сброшен кэш. Резолвинг восстановился.

    03.07.2019, 17:55
    Заработали все сервисы кроме МК, Фрилансима и Тостера.

    03.07.2019, 18:02
    Заработали МК и Фрилансим.

    03.07.2019, 18:07
    Вернули назад невиновную BGP-сессию с DataLine.

    03.07.2019, 18:25
    Стали фиксировать флапанья на ресурсах, связано было со сменой внешнего адреса NAT-пула и его отсутствием в acl ряда сервисов, оперативно поправили. Сразу заработал и Тостер.

    03.07.2019, 20:30
    Заметили ошибки, связанные с ботами Telegram. Выяснилось, что внешний адрес забыли прописать ещё в паре acl (proxy-серверах), оперативно поправили.


    Выводы


    • Вышло из строя оборудование, которое и до этого сеяло сомнения в своей пригодности. Были планы по исключению его из работы, так как оно мешало развитию сети и имело проблемы совместимости, но при этом осуществляло критически важную функцию, из-за чего какая-либо замена была технически не проста без перерыва сервисов. Теперь можно двигаться дальше.
    • Проблемы с DNS можно избежать, переместив их ближе к новой backbone-сети за пределы NAT сети и при этом с полной связностью с серой сетью без трансляции (что и планировалось до инцидента).
    • Не стоит при сборке кластеров РСУБД использовать доменные имена, так как удобство прозрачной смены IP-адреса не особо нужно, так как всё равно такие манипуляции требуют пересборки кластера. Данное решение продиктовано историческими причинами и в первую очередь очевидностью эндпойнтов по названию в конфигурациях РСУБД. В общем, классическая ловушка.
    • В принципе, проведены учения, сравнимые с «суверенизацией рунета», есть над чем подумать с точки зрения усиления возможностей автономного выживания.
    Хабр
    147,62
    Создаем и развиваем сервисы для гиков
    Поделиться публикацией

    Комментарии 30

      +3
      Из всех ваших сервисов вчера дольше всех держался (частично) один только Тостер. Пришлось читать его, пока поднимали Хабр.
        +1

        Хабр тоже долго жил в виде кэшей nginx. Лайфхак: потереть сессионные куки.

          +1

          Принято. Но надеюсь, что не пригодится.

        0
        Либо у вас неторопливые инженеры, либо банальная экономия на резервировании оборудованиях сыграла с вами злую шутку.
          +1

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

          +10
          На КДПВ подорожник не той стороной приложен. Надо было сразу правильно прикладывать — проблем бы не было.
            +5
            Вообще без разницы какой стороной его прикладывать, главное пожамкать чтобы сок давал.
            +5

            Спасибо за прояснение ситуации. Фиг я ещё когда-нибудь возьмусь за это неблагодарное дело по освещению деталей произошедшего вместо официального представителя.

              0
              Фиг я ещё когда-нибудь возьмусь за это неблагодарное дело по освещению деталей произошедшего

              А я вот хотел поблагодарить за чудесную детализированную статью, потому что в тот вечер реально было трудно понять, что происходит в этой запутанной ситуации.
              Но потом увидел вот это, и все стало на свои места
              image

              Так здорово, что есть такие статьи, в которых можно узнать нечто новое, да еще и с деталями. А на минусы не обращайте внимания, это все хейтеры.
              +2
              03.07.2019, 17:27
              Восстановлена ограниченная работоспособность Хабра.
              А вот этот пункт совсем непонятен. Какую педаль нажали? Куда рулили?
                0

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

                –1
                del
                  +1
                  однако часть сервисов оказалась неработоспособной, так как был нарушен механизм разрешения имён на name-серверах (dns).

                  Прям картинка с деревянным бегемотом вспомнилась.
                    –2
                    Собственно, есть же правило: если при любой настройке серверов используются хостнеймы, а не ip-адреса, то обязательно нужно сделать, то, что было сделано в процессе восстановления:
                    наполнять hosts-файлы записями критически важных сервисов.


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

                    Но, да, использовать IP-адреса и отключить в настройках сервиса ресолвинг имен — и надежнее, и «дешевле» для приложения, не будет затраты времени на любой ресолвинг.
                      0
                      Всё отлично, только про учения не понял. Или это юмор?
                        +1
                        Это суровая правда жизни в нынешних реалиях.
                          +1

                          Вполне себе отработка кейса, когда по чьей-то воле вдруг теряется связность с частью используемых api и иных ресурсов. Или ломается в том или ином виде часть DNS (или DNSSSec для всей .com-зоны).

                          0
                          есть над чем подумать с точки зрения усиления возможностей автономного выживания

                          Dual stack с IPv6 пригодился бы. У моего провайдера пару недель назад были похожие по симптомам проблемы (не работал NAT или другая проблема с IP маршрутизацией). Зато ресурсы с IPv6 были доступны.
                            +1

                            IPv6 активно пилим.

                              0

                              Тоже за Куратора будете "прятать"?

                                +1

                                У нас отделена сеть автономной системы от сети публичных сервисов. Это вообще два не взаимосвязанных сегмента. IPv6 на публичных сервисах появится тогда, когда появится у Qrator, на backbone у нас уже есть IPv6.

                            0

                            То что иконки отъехали примерно в это же время в мобильном FF, может быть как-то связано?

                              +2

                              Они, кстати, до сих пор не пашут.

                              +1
                              А десять минут назад что это за афтершок был?
                                0
                                Проблема несколько усугубилась тем, что данное оборудование также терминировало входящие подключения клиентских VPN сотрудников, удалённые работы по восстановлению стало проводить сложнее.

                                Интересно! А сколько из прочитавших этот абзац осознали, что и у них VPN и NAT повязаны, я уж молчу про тех кто «ходит» по железкам из дома через рабочий ПК.

                                Теперь ждём статью по следам этого postmortem о том как вы разнесли NAT на разное оборудование, с резервированием и/или распределением нагрузки. Плюсы, минусы, подводные камни…
                                  +1

                                  Мы сейчас разворачиваем технически отделённую oob-сеть. С ipsec и bgp через lte-модемы. Скорее всего будет пост.

                                  0
                                  Извините, но сетевиков ваших (если они у вас есть) гнать нужно ссаными тряпками за такое.
                                  И за то, что служебный VPN сидит рядом с продуктивом (вероятно на ASA), и за NAT (ЗАЧЕМ?!), и за то, что нет резервирования…
                                    +1

                                    Если всех гнать ссаными тряпками — тряпок не хватит. Или тех, кого ими гнать. Как бы то ни было, не самое конструктивное решение. Сказываются затянувшиеся переделки опорной сети, на одном из этапов которых "временно" VPN сел на ASA (а не за неё). Но нет ничего более постоянного, чем временное, это уже недогляд и неправильная приоритезация задач.

                                      +1
                                      Не, сам VPN на ASA — это норм. Anyconnect — очень удобная и гибкая штука.
                                      Тут дело в другом — как вообще можно совмещать на одном железе oob и продуктив?! Даже временно. Как можно не резервировать критичные компоненты? Переезд переездом, но это не повод снижать надёжность системы.
                                    0
                                    Не хватает полноценного хаба с постмортемами, спасибо, полезная информация.

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

                                    Самое читаемое