Koniec pierwszego i początek drugiego miesiąca lata 2019 okazał się trudny i upłynął pod znakiem kilku dużych spadków w globalnych usługach IT. Wśród godnych uwagi: dwa poważne incydenty w infrastrukturze CloudFlare (pierwszy - z krzywymi rękami i niedbałym podejściem do BGP ze strony niektórych dostawców usług internetowych z USA; drugi - z nieuczciwym wdrożeniem samych CF, co dotknęło wszystkich korzystających z CF , a jest ich wiele godnych uwagi usług) oraz niestabilne działanie infrastruktury CDN Facebooka (dotknęło to wszystkie produkty FB, w tym Instagram i WhatsApp). Musieliśmy też dać się wciągnąć w dystrybucję, chociaż nasze przestoje były znacznie mniej zauważalne na tle globalnym. Ktoś już zaczął wciągać czarne helikoptery i „suwerenne” spiski, dlatego publikujemy publiczną sekcję zwłok naszego incydentu.
03.07.2019, 16: 05
Zaczęto odnotowywać problemy z zasobami, podobne do awarii łączności w sieci wewnętrznej. Nie sprawdziwszy wszystkiego do końca, zaczęto zarzucać działanie kanału zewnętrznego DataLine, gdyż stało się jasne, że problem dotyczy dostępu sieci wewnętrznej do Internetu (NAT), do tego stopnia, że sesja BGP skierowana jest w stronę DataLine.
03.07.2019, 16: 35
Stało się oczywiste, że sprzęt zapewniający translację adresów sieciowych i dostęp z sieci lokalnej witryny do Internetu (NAT) uległ awarii. Próby ponownego uruchomienia sprzętu do niczego nie doprowadziły, poszukiwanie alternatywnych opcji organizacji łączności rozpoczęło się przed otrzymaniem odpowiedzi od pomocy technicznej, ponieważ z doświadczenia najprawdopodobniej by to nie pomogło.
Problem został nieco pogłębiony przez fakt, że sprzęt ten przerywał również połączenia przychodzące pracowników klienckich VPN, a zdalne przywracanie danych stało się trudniejsze do przeprowadzenia.
03.07.2019, 16: 40
Próbowaliśmy ożywić wcześniej istniejący zapasowy schemat NAT, który wcześniej działał dobrze. Stało się jednak jasne, że szereg modernizacji sieci sprawił, że system ten prawie całkowicie przestał działać, ponieważ jego przywrócenie w najlepszym przypadku mogło nie zadziałać lub, w najgorszym, zepsuć to, co już działało.
Zaczęliśmy pracować nad kilkoma pomysłami przeniesienia ruchu do zestawu nowych routerów obsługujących szkielet, ale wydawało się to niewykonalne ze względu na specyfikę dystrybucji tras w sieci szkieletowej.
03.07.2019, 17: 05
Jednocześnie zidentyfikowano problem w mechanizmie rozpoznawania nazw na serwerach nazw, co doprowadziło do błędów w rozpoznawaniu punktów końcowych w aplikacjach i zaczęły one szybko zapełniać pliki hostów zapisami usług krytycznych.
03.07.2019, 17: 27
Przywrócono ograniczoną funkcjonalność Habr.
03.07.2019, 17: 43
Ostatecznie jednak znaleziono stosunkowo bezpieczne rozwiązanie w zakresie organizacji ruchu przez jeden z routerów granicznych, który został szybko zainstalowany. Łączność z Internetem została przywrócona.
W ciągu następnych kilku minut z systemów monitorujących napłynęło wiele powiadomień o przywróceniu funkcjonalności agentów monitorujących, jednak część usług okazała się nie działać, ponieważ zepsuł się mechanizm rozpoznawania nazw na serwerach nazw (dns).
03.07.2019, 17: 52
NS został ponownie uruchomiony i pamięć podręczna została wyczyszczona. Rozwiązywanie zostało przywrócone.
03.07.2019, 17: 55
Wszystkie usługi zaczęły działać oprócz MK, Freelansim i Toaster.
03.07.2019, 18: 02
MK i Freelansim rozpoczęli współpracę.
03.07.2019, 18: 07
Przywróć niewinną sesję BGP za pomocą DataLine.
03.07.2019, 18: 25
Zaczęli odnotowywać problemy z zasobami, co było spowodowane zmianą adresu zewnętrznego puli NAT i jego brakiem na liście szeregu usług, co zostało szybko poprawione. Toster od razu zaczął działać.
03.07.2019, 20: 30
Zauważyliśmy błędy związane z botami Telegramu. Okazało się, że zapomnieli zarejestrować adres zewnętrzny na kilku acl (serwerach proxy), co zostało natychmiast poprawione.
odkrycia
- Sprzęt, który wcześniej budził wątpliwości co do jego przydatności, zawiódł. Planowano wyeliminować go z pracy, gdyż zakłócał rozwój sieci i stwarzał problemy z kompatybilnością, ale jednocześnie pełnił funkcję krytyczną, dlatego jakakolwiek wymiana była technicznie trudna bez zakłócania usług. Teraz możesz przejść dalej.
- Problemów z DNS można uniknąć, przenosząc je bliżej nowej sieci szkieletowej poza sieć NAT i nadal mając pełną łączność z szarą siecią bez translacji (co było planem przed incydentem).
- Nie należy używać nazw domen podczas składania klastrów RDBMS, ponieważ wygoda przejrzystej zmiany adresu IP nie jest szczególnie konieczna, ponieważ takie manipulacje nadal wymagają przebudowy klastra. Decyzja ta została podyktowana względami historycznymi, a przede wszystkim oczywistością nazwy punktów końcowych w konfiguracjach RDBMS. Generalnie klasyczna pułapka.
- W zasadzie przeprowadzono ćwiczenia porównywalne z „suwerenizacją Runetu”, jest nad czym myśleć w zakresie wzmacniania zdolności do autonomicznego przetrwania.
Źródło: www.habr.com