Slutet av den första och början av den andra sommarmånaden 2019 visade sig vara svårt och präglades av flera stora nedgångar i globala IT-tjänster. Bland de anmärkningsvärda: två allvarliga incidenter i CloudFlare-infrastrukturen (den första - med krokiga händer och försumlig inställning till BGP från vissa internetleverantörer från USA; den andra - med en skev utplacering av CF själva, vilket påverkade alla som använde CF , och dessa är många anmärkningsvärda tjänster) och instabil drift av Facebook CDN-infrastrukturen (påverkade alla FB-produkter, inklusive Instagram och WhatsApp). Vi var också tvungna att fastna i distributionen, även om vårt avbrott var mycket mindre märkbart mot den globala bakgrunden. Någon har redan börjat släpa in svarta helikoptrar och "suveräna" konspirationer, så vi släpper en offentlig obduktion av vår incident.
03.07.2019, 16: 05
Problem med resurser började registreras, liknande ett haveri i den interna nätverksanslutningen. Efter att inte ha kontrollerat allt, började de fel på den externa kanalens prestanda mot DataLine, eftersom det blev uppenbart att problemet var med det interna nätverkets åtkomst till Internet (NAT), till den grad att BGP-sessionen sattes mot DataLine.
03.07.2019, 16: 35
Det blev uppenbart att utrustningen som tillhandahåller nätverksadressöversättning och åtkomst från webbplatsens lokala nätverk till Internet (NAT) hade misslyckats. Försök att starta om utrustningen ledde inte till någonting, sökandet efter alternativa alternativ för att organisera anslutning började innan man fick svar från teknisk support, eftersom det av erfarenhet troligen inte skulle ha hjälpt.
Problemet förvärrades något av det faktum att denna utrustning också avslutade inkommande anslutningar för klient VPN-anställda, och fjärråterställningsarbete blev svårare att utföra.
03.07.2019, 16: 40
Vi försökte återuppliva ett tidigare befintligt backup-NAT-schema som hade fungerat bra tidigare. Men det blev uppenbart att ett antal nätverksrenoveringar gjorde detta system nästan helt inoperativt, eftersom dess återställande i bästa fall inte kunde fungera, eller i värsta fall bryta det som redan fungerade.
Vi började arbeta med ett par idéer för att överföra trafik till en uppsättning nya routrar som betjänade stamnätet, men de verkade oanvändbara på grund av särdragen i distributionen av rutter i kärnnätet.
03.07.2019, 17: 05
Samtidigt identifierades ett problem i namnupplösningsmekanismen på namnservrar, vilket ledde till fel i att lösa slutpunkter i applikationer, och de började snabbt fylla värdfiler med register över kritiska tjänster.
03.07.2019, 17: 27
Habrs begränsade funktionalitet har återställts.
03.07.2019, 17: 43
Men till slut hittade man en relativt säker lösning för att organisera trafiken genom en av gränsroutrarna, som snabbt installerades. Internetanslutningen har återställts.
Under de närmaste minuterna kom många meddelanden från övervakningssystemen om återställandet av övervakningsagenternas funktionalitet, men några av tjänsterna visade sig vara inoperable eftersom namnupplösningsmekanismen på namnservrarna (dns) var trasig.
03.07.2019, 17: 52
NS startades om och cachen rensades. Lösningen har återställts.
03.07.2019, 17: 55
Alla tjänster började fungera utom MK, Freelansim och Toaster.
03.07.2019, 18: 02
MK och Freelansim började jobba.
03.07.2019, 18: 07
Få tillbaka en oskyldig BGP-session med DataLine.
03.07.2019, 18: 25
De började registrera problem med resurser, vilket berodde på en ändring av den externa adressen för NAT-poolen och dess frånvaro i acl för ett antal tjänster, vilket snabbt korrigerades. Brödrost började fungera direkt.
03.07.2019, 20: 30
Vi märkte fel relaterade till Telegram-bots. Det visade sig att de glömt att registrera den externa adressen i ett par acl (proxyservrar), vilket snabbt rättades till.
Resultat
- Utrustningen, som tidigare sått tvivel om dess lämplighet, misslyckades. Det fanns planer på att eliminera det från arbetet, eftersom det störde utvecklingen av nätverket och hade kompatibilitetsproblem, men samtidigt utförde det en kritisk funktion, varför ett utbyte var tekniskt svårt utan att avbryta tjänsterna. Nu kan du gå vidare.
- DNS-problemet kan undvikas genom att flytta dem närmare det nya stamnätet utanför NAT-nätverket och fortfarande ha full anslutning till det grå nätverket utan översättning (vilket var planen före incidenten).
- Du bör inte använda domännamn när du monterar RDBMS-kluster, eftersom bekvämligheten med att transparent ändra IP-adressen inte är särskilt nödvändig, eftersom sådana manipulationer fortfarande kräver ombyggnad av klustret. Detta beslut dikterades av historiska skäl och, först och främst, av uppenbarheten av endpoints med namn i RDBMS-konfigurationer. I allmänhet en klassisk fälla.
- I princip har övningar jämförbara med "suveräniseringen av Runet" genomförts; det finns något att tänka på när det gäller att stärka förmågan till autonom överlevnad.
Källa: will.com