Конец первого и начало второго месяца лета 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-адреса не особо нужно, так как всё равно такие манипуляции требуют пересборки кластера. Данное решение продиктовано историческими причинами и в первую очередь очевидностью эндпойнтов по названию в конфигурациях РСУБД. В общем, классическая ловушка.
- В принципе, проведены учения, сравнимые с «суверенизацией рунета», есть над чем подумать с точки зрения усиления возможностей автономного выживания.
Автор: Вадим Рыбалко
