A Cloudflare többórás üzemzavara a hibakezelés helytelen megvalósítására vezethető vissza

A Cloudflare közzétette a vizsgálati jelentést az infrastruktúrájuk egyik legnagyobb hibájáról, amelynek következtében a tartalomszolgáltató hálózat nagy része több mint 3 órán keresztül nem volt működőképes. A kiesés egy adatbázis-struktúrában végrehajtott módosítás után következett be a ClickHouse alapú tárolórendszerben. A módosítás eredményeként a botvédelemhez használt paraméterfájl mérete a duplájára nőtt.

Az adatbázisban duplikált táblák keletkeztek, miközben az SQL-lekérdezés, amely a fájl generálását végezte, egyszerűen az összes táblából kiolvasta a kulcs szerinti adatokat anélkül, hogy kiszűrte volna a duplikátumokat:

SELECT
 name,
 type
FROM system.columns
WHERE
 table = 'http_requests_features'
ORDER BY name;
 

A létrehozott fájl ezután szétterjedt a klaszter összes olyan csomópontjára, amelyek a bejövő kéréseket dolgozzák fel. Az azt használó feldolgozó modul a botok által indított kérések felismeréséhez a fájl paramétereit a memóriába töltötte. A túlzott memóriahasználat megakadályozására a kódban be volt állítva egy maximális fájlméret-korlát. Normál esetben a fájl mérete jóval a határérték alatt maradt, de a táblák duplikációja után meghaladta a limitet.

A probléma lényege az volt, hogy a rendszer nem megfelelően kezelte a limit túllépését. Ahelyett, hogy szabályosan jelezte volna a felügyeleti rendszer felé a rendellenes helyzetet, miközben tovább használja a korábbi, érvényes fájlverziót, a feldolgozó modul hibára futott és leállt. Ez a leállás blokkolta a forgalom továbbítását.

A hibát az okozta, hogy a Rust nyelven írt kódban a Result típushoz tartozó unwrap() metódust használták. Ha a Result állapota „Ok”, akkor az unwrap() visszaadja a benne lévő értéket; ha viszont nem sikeres („Err”), a hívás azonnali programösszeomlást eredményez (a „panic!” makró fut le). Az unwrap() általában csak hibakeresés során vagy tesztkódokban ajánlott, és nem javasolt éles rendszerekben.

Hozzászólások

Azért itt a change management process is el volt szúrva keményen. Nem volt rollback / backout plan.

Meg eleve nem terítek konfiguráció változást az összes prod gépre, ha megoldható, hogy körökre bontom. Microsoft is futott már bele ebbe a hibába - talán a WU-nál.

Szóval megint rust kód, megint tesztelés (és ész) nélkül. Remélem ez már elég nagy esemény ahhoz, hogy ne menjenek el mellette szó nélkül.

Debian - The "What?!" starts not!
http://nyizsa.blogspot.com

Ez igencsak facepalm eset... Sokszor ugyanilyen szintű kreténségekkel találkozom máshol is, sajnos senkiháziak kezében van a popszakma...

Nem értek a rust-hoz de valahol leírták hogy unwrap() -ot nem hagyunk production kódban. 
Triviálisnak tűnik berakni erre egy rule-t bármilyen static analyzerbe / CI-CD pipeline-ba.

Se automatikus, se manuális code-review nem volt. És ennek a cégnek fizetnek nem keveset ...

...de a Rust-ban megírt kódok majd jobbak lesznek.

Avagy megintcsak azt látjuk, hogy felesleges mindent Rust-ban újraírni, mert a kód csak annyira lesz gyors és biztonságos, amennyire a fejlesztő ért az adott nyelvhez. Ehhez semmi köze nincs a nyelvnek meg a runtime-nak.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-