Kritický bod selhání a průšvihy v IT, které se na nás navalily

Dění v IT v poslední době pozoruji se zájmem, ale tiše: V infrastruktuře a bezpečnosti se moc nevyznám, takže si nechám podstatu problému vysvětlit od lidí, kteří jsou v tom podstatně více zběhlí. Tak například detaily o podstatě problému s Crowdstrike vám nejlépe vyloží Michal „Altair“ Valášek. Altair IT dlouhá léta vyučuje, je zkušený a srozumitelný – takže pokud vás to zajímá, tak vám jeho video doporučuji.

Všechny velké maléry poslední doby ale ukazují na problémy ve dvou základních doménách: Za prvé velké množství lidí spoléhá na velmi malý počet kritických komponent, ať už softwarových anebo hardwarových. Za druhé se ukazuje, že přestože jde o kritické komponenty, tak se podle všeho šetří na testování a obecně se přehlíží bezpečnost, která je nedostatečná. 

V případě problému s Crowdstrike se přímo mluví o „single point of failure“, kde podle všeho poškozený datový soubor s profily útoků způsobil při svém načtení pád programu, který měl systémy chránit. Ukázalo se, že šlo „o lék horší než sama nemoc“, což u systémových utilit a antivirů není tak neobvyklé. 

Kdykoliv máme příležitost udělat něco robustněji a rezilientněji – anebo naopak levněji a výnosněji, tak si vybereme vyšší výnosy. Pokaždé, když nastane malér a výnosnost klesá, typicky na to firmy reagují propouštěním. Pokud je pravda to, k čemu se dostal Gamers Nexus, tak problémy Intelu s novými procesory povedou k vyhazovu patnácti tisíc lidí z Intelu. Ouch!

Člověk by řekl, že gigantické firmy s obřími výnosy budou mít zájem nedělat velké chyby a když už nic jiného, tak se zaměří na pořádné testování a budou spíš konzervativní. Zdá se, že opak je pravdou – a přinejmenším z historických dokumentů zjišťuji, že se často kritickou komponentou zabýval jenom malý tým a úspěch anebo neúspěch celé firmy tak trochu stál a padal s tím, co stvoří. 

Pokud se bavíme o Intelu, stačí vypíchnout dva projekty z jejich minulosti, z nichž seznam „nejhorších procesorů Intelu“ překvapivě nezmiňuje ani jeden.

První architekturou, která představovala problém, byl Intel iAPX 432 (1981), pokus o „minipočítač na čipu“ (přesněji řečeno na několika čipech). Druhou neúspěšnou architekturou byl Intel i960 (1988), což byl raný pokus o jejich RISC procesor. V obou případech se ukázalo, že velké potíže nastaly u kompilátorů pro tyto systémy – a když přišlo Itanium (2001), tak se opět ukázalo, že největší problémy jsou s kompilátory. 

Pokud historické zdroje nelžou, tak se vývojem kompilátorů zabývalo v Intelu méně lidí, než by bylo vhodné, což možná souviselo s poněkud optimistickými očekáváními stran architektur a s tím, že se objevovaly problémy, které nikdo nečekal, jako například memory stalling, kdy kód byl sice přeložený správně, ale data se nepřednačítávala efektivně, a proto kód čekal více, než se odhadovalo.