Канец першага і пачатак другога месяца лета 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