Kompania Cloudflare publikoi një analizë të një prej incidenteve më të mëdha në infrastrukturën e saj, për shkak të të cilit dje një pjesë e madhe e rrjetit të shpërndarjes së përmbajtjes ishte jashtë funksioni për më shumë se 3 orë. Problemi ndodhi pas një ndryshimi në strukturën e DB, e cila ishte e vendosur në magazinën ClickHouse, pas së cilës skedari i parametrave për sistemin e luftës ndaj boteve u dyfishua në madhësi. Në DB u formuan tabela të dyfishta, megjithatë, SQL-htable për formimin e skedarit thjesht nxirrte të dhënat nga të gjitha tabelat sipas çelësit, pa filtruar kopjet. SELECT name, type FROM system.columns WHERE table = 'http_requests_features' order by name;
Skedari i krijuar u shpërnda në të gjitha nyjat e klasit që përpunonte kërkesat e hyrshme. Në përpunuesin që përdorte këtë skedar për verifikim të kërkesave nga bot, parametrat e specifikuar në skedar ruheshin në memorjen operative dhe për mbrojtje nga shpenzimi i tepruar i memories, ishte parashikuar një kufi për madhësinë maksimale të lejuar të skedarit. Në kushte normale, madhësia aktuale e skedarit ishte ndjeshëm më e vogël se kufiri i caktuar, por pas dyfishimit të tabelave e tejkaloi limitin.
Problemi ishte se në vend të trajtimit të saktë të tejkalimit të kufirit dhe vazhdimit të përdorimit të versionit të kaluar të skedarit duke informuar sistemin e monitorimit për një situatë emergjente, në përpunues ndodhte një përfundim krizë, i cili bllokonte kalimin e mëtejshëm të trafikut. Gabimi u shkaktua nga përdorimi në kodin e gjuhës Rust të metodës unwrap() me llojin Result.
Kur vlera e Result ka statusin 'Ok', metoda unwrap() kthen objektin e lidhur me kĂ«tĂ« status, por nĂ«se rezultati nuk Ă«shtĂ« i suksesshĂ«m â thirrja çon nĂ« njĂ« pĂ«rfundim krizĂ« (aktivizohet makrosi 'panic!'). Zakonisht, unwrap() pĂ«rdoret gjatĂ« procesit tĂ« debugging-ut ose gjatĂ« shkrimit tĂ« kodit tĂ« testeve dhe nuk rekomandohet pĂ«r t'u pĂ«rdorur nĂ« projekte tĂ« punĂ«s.
Burimi: opennet.ru
