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