Краят на първия и началото на втория месец от лятото на 2019 г. се оказа труден и бе белязан от няколко големи спада на световните ИТ услуги. Сред забележителните: два сериозни инцидента в инфраструктурата на CloudFlare (първият - с криви ръце и небрежно отношение към BGP от страна на някои интернет доставчици от САЩ; вторият - с криво разполагане на самите CF, което засегна всички, използващи CF , а това са много забележителни услуги) и нестабилна работа на CDN инфраструктурата на Facebook (засегнати всички FB продукти, включително Instagram и WhatsApp). Ние също трябваше да се увлечем в разпространението, въпреки че прекъсването ни беше много по-малко забележимо на глобалния фон. Някой вече е започнал да вкарва черни хеликоптери и „суверенни“ конспирации, така че ние пускаме публична аутопсия на нашия инцидент.
03.07.2019, 16: 05
Започнаха да се записват проблеми с ресурсите, подобни на срив във вътрешната мрежова свързаност. След като не провериха напълно всичко, те започнаха да обвиняват производителността на външния канал към DataLine, тъй като стана ясно, че проблемът е с достъпа на вътрешната мрежа до Интернет (NAT), до точката на поставяне на BGP сесията към DataLine.
03.07.2019, 16: 35
Стана очевидно, че оборудването, осигуряващо транслация на мрежови адреси и достъп от локалната мрежа на сайта до Интернет (NAT), е повредено. Опитите за рестартиране на оборудването не доведоха до нищо, търсенето на алтернативни възможности за организиране на свързаност започна, преди да получи отговор от техническата поддръжка, тъй като от опит това най-вероятно не би помогнало.
Проблемът беше донякъде утежнен от факта, че това оборудване също прекратява входящите връзки на клиентски VPN служители и работата по отдалечено възстановяване стана по-трудна за извършване.
03.07.2019, 16: 40
Опитахме се да съживим съществуваща преди това резервна NAT схема, която работеше добре преди. Но стана ясно, че редица ремонти на мрежата направиха тази схема почти напълно неработеща, тъй като нейното възстановяване можеше в най-добрия случай да не работи или в най-лошия да наруши това, което вече работеше.
Започнахме да работим върху няколко идеи за прехвърляне на трафик към набор от нови рутери, обслужващи гръбнака, но те изглеждаха неосъществими поради особеностите на разпределението на маршрутите в основната мрежа.
03.07.2019, 17: 05
В същото време беше идентифициран проблем в механизма за разрешаване на имена на сървъри за имена, което доведе до грешки при разрешаването на крайни точки в приложенията и те започнаха бързо да запълват файловете на хостове със записи на критични услуги.
03.07.2019, 17: 27
Ограничената функционалност на Habr е възстановена.
03.07.2019, 17: 43
Но в крайна сметка беше намерено относително безопасно решение за организиране на трафика през един от граничните рутери, което бързо беше инсталирано. Интернет връзката е възстановена.
През следващите няколко минути дойдоха много известия от системите за наблюдение за възстановяване на функционалността на агентите за наблюдение, но някои от услугите се оказаха неработещи, тъй като механизмът за разрешаване на имена на сървърите за имена (dns) беше повреден.
03.07.2019, 17: 52
NS беше рестартиран и кеша беше изчистен. Разрешаването е възстановено.
03.07.2019, 17: 55
Всички услуги започнаха да работят с изключение на MK, Freelansim и Toaster.
03.07.2019, 18: 02
MK и Freelansim започнаха работа.
03.07.2019, 18: 07
Възстановете невинна BGP сесия с DataLine.
03.07.2019, 18: 25
Те започнаха да записват проблеми с ресурсите, което се дължеше на промяна на външния адрес на NAT пула и липсата му в acl на редица услуги, което беше своевременно коригирано. Тостерът започна да работи веднага.
03.07.2019, 20: 30
Забелязахме грешки, свързани с ботове на Telegram. Оказа се, че са забравили да регистрират външния адрес в няколко acl (прокси сървъра), което веднага беше коригирано.
Данни
- Оборудването, което преди това посяваше съмнения относно годността му, отказа. Имаше планове да бъде елиминиран от работа, тъй като пречеше на развитието на мрежата и имаше проблеми със съвместимостта, но в същото време изпълняваше критична функция, поради което всяка подмяна беше технически трудна, без да прекъсва услугите. Сега можете да продължите.
- Проблемът с DNS може да бъде избегнат, като ги преместите по-близо до новата опорна мрежа извън NAT мрежата и все още имате пълна свързаност към сивата мрежа без превод (какъвто беше планът преди инцидента).
- Не трябва да използвате имена на домейни, когато сглобявате RDBMS клъстери, тъй като удобството за прозрачна промяна на IP адреса не е особено необходимо, тъй като подобни манипулации все още изискват повторно изграждане на клъстера. Това решение беше продиктувано от исторически причини и на първо място от очевидността на крайните точки по име в конфигурациите на RDBMS. Като цяло класически капан.
- По принцип са проведени учения, сравними с „суверенизацията на Рунет“, има какво да се мисли по отношение на укрепването на възможностите за автономно оцеляване.
Източник: www.habr.com