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