Конец первого и начало второго месяца лета 2019 года выдались непростыми и ознаменовались несколькими крупными падениями мировых IT-сервисов. Из заметных: два серьёзных инцидента в инфраструктуре CloudFlare (первый — с кривыми руками и халатным отношением к BGP со стороны некоторых ISP из США; второй — с кривым деплоем уже самих CF, повлияло на всех, пользующихся CF, а это многие заметные сервисы) и нестабильная работа инфраструктуры Facebook CDN (повлияло на все продукты FB, включая Instagram и WhatsApp). Под раздачу пришлось попасть и нам, хотя наш outage был куда менее заметен на мировом фоне. Кто-то стал уже приплетать чёрные вертолёты и «суверенные» заговоры, посему выпускаем публичный post mortem нашего инцидента.
КСНУМКС, КСНУМКС: КСНУМКС
Начали фиксировать проблемы с ресурсами, похожие на нарушение внутренней сетевой связности. Не до конца всё проверив, стали грешить на работоспособность внешнего канала в сторону ДатаЛайн, так как стало понятно, что проблема с доступом внутренней сети в интернет (NAT), вплоть до того, что положили BGP-сессию в сторону DataLine.
КСНУМКС, КСНУМКС: КСНУМКС
Стало очевидно, что вышло из строя оборудование, осуществляющее трансляцию сетевых адресов и доступ из локальной сети площадки в Интернет (NAT). Попытки перезагрузить оборудование ни к чему не привели, поиск альтернативных вариантов организации связности начался до получения ответа от техподдержки, так как по опыту, это бы скорее всего не помогло.
Проблема несколько усугубилась тем, что данное оборудование также терминировало входящие подключения клиентских VPN сотрудников, удалённые работы по восстановлению стало проводить сложнее.
КСНУМКС, КСНУМКС: КСНУМКС
Попытались реанимировать ранее существовавшую запасную схему NAT, которая работала сильно до этого. Но стало понятно, что ряд переоборудований сети сделали данную схему практически полностью нерабочей, так как её восстановление могло в лучшем случае не сработать, в худшем сломать уже работающее.
Стали прорабатывать пару идей перекинуть трафик на комплекс новых маршрутизаторов, обслуживающих backbone, но они показались нерабочими в силу особенностей распространения маршрутов в опорной сети.
КСНУМКС, КСНУМКС: КСНУМКС
Параллельно выявилась проблема в механизме разрешения имён на name-серверах, что привело к ошибкам резолвинга эндпойнтов в приложениях, начали оперативно наполнять hosts-файлы записями критически важных сервисов.
КСНУМКС, КСНУМКС: КСНУМКС
Восстановлена ограниченная работоспособность Хабра.
КСНУМКС, КСНУМКС: КСНУМКС
Но в итоге, было найдено относительно безопасное решение организации пропуска трафика всё же именно через один из пограничных маршрутизаторов, что и было быстро вкорячено. Связность с интернетом восстановилась.
В течение ближайших минут от систем мониторинга пришла масса уведомлений о восстановлении работоспособности агентов мониторинга, однако часть сервисов оказалась неработоспособной, так как был нарушен механизм разрешения имён на name-серверах (dns).
КСНУМКС, КСНУМКС: КСНУМКС
Были перезапущены NS, сброшен кэш. Резолвинг восстановился.
КСНУМКС, КСНУМКС: КСНУМКС
Заработали все сервисы кроме МК, Фрилансима и Тостера.
КСНУМКС, КСНУМКС: КСНУМКС
Заработали МК и Фрилансим.
КСНУМКС, КСНУМКС: КСНУМКС
Вернули назад невиновную BGP-сессию с DataLine.
КСНУМКС, КСНУМКС: КСНУМКС
Стали фиксировать флапанья на ресурсах, связано было со сменой внешнего адреса NAT-пула и его отсутствием в acl ряда сервисов, оперативно поправили. Сразу заработал и Тостер.
КСНУМКС, КСНУМКС: КСНУМКС
Заметили ошибки, связанные с ботами Telegram. Выяснилось, что внешний адрес забыли прописать ещё в паре acl (proxy-серверах), оперативно поправили.
Налази
- Вышло из строя оборудование, которое и до этого сеяло сомнения в своей пригодности. Были планы по исключению его из работы, так как оно мешало развитию сети и имело проблемы совместимости, но при этом осуществляло критически важную функцию, из-за чего какая-либо замена была технически не проста без перерыва сервисов. Теперь можно двигаться дальше.
- Проблемы с DNS можно избежать, переместив их ближе к новой backbone-сети за пределы NAT сети и при этом с полной связностью с серой сетью без трансляции (что и планировалось до инцидента).
- Не стоит при сборке кластеров РСУБД использовать доменные имена, так как удобство прозрачной смены IP-адреса не особо нужно, так как всё равно такие манипуляции требуют пересборки кластера. Данное решение продиктовано историческими причинами и в первую очередь очевидностью эндпойнтов по названию в конфигурациях РСУБД. В общем, классическая ловушка.
- В принципе, проведены учения, сравнимые с «суверенизацией рунета», есть над чем подумать с точки зрения усиления возможностей автономного выживания.
Извор: ввв.хабр.цом