Kompania Cloudflare publikoi një analizë të një nga incidente më të mëdha në infrastrukturën e saj, për shkak të së cilës pjesa më e madhe e rrjetit të shpërndarjes së përmbajtjes ishte jashtë funksionit për më shumë se 3 orë. Dështimi ndodhi pas një ndërrimi në strukturën e DB, e cila u ruajt në depozitat ClickHouse, pas së cilës skedari me parametrat për sistemin e kundërveprimit ndaj botëve u dyfishua në madhësi. Në DB u formuan tabela të dyfishta, teksa SQL-çarja për formimin e skedarit thjesht shfaqi të gjithë të dhënat nga të gjitha tabelat sipas çelësit, pa filtruar dyfishimet. SELECT name, type FROM system.columns WHERE table = 'http_requests_features' order by name;
Skedhizuar skedari u shpërnda përmes të gjitha nyjeve të klasterit që përpunojnë kërkesat hyrëse. Në përpunuesin që përdor këtë skedar për të kontrolluar nëse ka kërkesa nga bota, parametrat e specifikuar në skedar u ruajtën në memorie të përkohshme dhe për të mbrojtur nga shpenzimi i tepruar i memories, kodi parashikoi një limit për madhësinë maksimale të lejueshme të skedarit. Në kushte normale, madhësia aktuale e skedarit ishte ndjeshëm më e vogël se kufizimi i vendosur, por pas duplicimit të tabelave e kaloi limitin.
Problemi doli të ishte se, përveç procesimit të saktë të tepricës së limitit dhe vazhdimit të përdorimit të versionit të kaluar të skedarit, me informimin e sistemit të monitorimit për një situatë emergjent, në përpunues aktivizohej përfundimi emergjent, i cili bllokonte kalimin e mëtejmë të trafikut. Gabimi u shkaktua nga përdorimi në kodin në gjuhën Rust të metodës unwrap() me tipin Result.
Kur kur rezultati ka gjendjen "Ok", metoda unwrap() kthen objektin e lidhur me kĂ«tĂ« gjendje, por nĂ«se rezultati nuk Ă«shtĂ« i suksesshĂ«m â thirrja çon nĂ« njĂ« pĂ«rfundim tĂ« papritur (aktivizohet makro "panic!"). Zakonisht, unwrap() pĂ«rdoret gjatĂ« procesit tĂ« debigimit ose gjatĂ« shkrimit tĂ« kodit tĂ« testeve dhe nuk rekomandohet pĂ«r t'u pĂ«rdorur nĂ« projekte nĂ« prodhim.
Burimi: opennet.ru
