POČÍTAČ, KTERÝ SE „NIKDY NEPOKAZÍ“: OD SYSTEMIC COMPUTING K SELF-HEALING SYSTÉMŮM

ÚVOD

V roce 2013 zaujal média výzkum University College London titulkem o počítači, který „nikdy nespadne“. Nešlo o magický hardware bez poruch. Šlo o experimentální přístup nazvaný systemic computing, jehož cílem bylo zbavit program závislosti na jedné křehké sekvenci instrukcí a umožnit systému reorganizovat se po chybách.

Myšlenka je stále aktuální. Moderní cloudová infrastruktura, kosmické systémy i bezpečnostně kritické řízení už nepočítají s tím, že žádná součást nikdy neselže. Naopak: předpokládají, že chyba přijde, a navrhují celek tak, aby ji přežil.

1. PROČ POČÍTAČE PADAJÍ

Běžný počítačový program vykonává přesnou posloupnost instrukcí a předpokládá, že hardware, paměť, soubory a síť jsou v očekávaném stavu. Když se předpoklad poruší, chyba se může propagovat systémem.

Příčiny sahají od programátorské chyby přes vadný bit v paměti až po poruchu disku, výpadek napájení, ztrátu síťového spojení nebo závod dvou procesů. U distribuovaných systémů se přidává ještě horší problém: část systému neví, zda je jiný uzel mrtvý, pomalý nebo pouze odpojený.

„Počítač, který se nikdy nepokazí“ proto nelze postavit tak, že vyrobíme dokonalý tranzistor. Musíme předpokládat nedokonalost a navrhnout způsob zotavení.

2. SYSTEMIC COMPUTING UCL

Peter Bentley a Christos Sakellariou z UCL zkoumali architekturu inspirovanou biologickými systémy. Místo jednoho pevného programu měli množství malých systémů, které spolu reagovaly a jejichž organizace nebyla vázána na jednu přesnou adresu v paměti.

Experimentální počítač měl být schopen pokračovat i po poškození části svého stavu. Kód a data byly distribuovány a systém mohl z dostupných částí vytvořit novou funkční konfiguraci.

Mediální zkratka „never crashes“ byla samozřejmě nadsázka. Každý fyzický systém lze zničit dostatečně velkou poruchou. Výzkum ale správně ukazoval změnu filozofie: nezabraňovat všem chybám, nýbrž umožnit systému přežít některé chyby bez globálního pádu.

3. DIJKSTRA A SELF-STABILIZATION

Myšlenka samoopravného distribuovaného systému je starší. Edsger W. Dijkstra v 70. letech formuloval koncept self-stabilization: systém se může dostat do libovolného chybného stavu, ale pokud chyby přestanou přicházet, jeho protokol jej postupně vrátí do legitimního stavu bez vnějšího restartu.

Je to velmi silná vlastnost. Nemusíme přesně vědět, jak porucha vznikla. Stačí dokázat, že pravidla systému z jakéhokoli přípustného stavu konvergují zpět k pořádku.

4. ECC PAMĚŤ: OPRAVIT BIT DŘÍV, NEŽ SI HO PROGRAM VŠIMNE

Na hardwarové úrovni se běžně používá Error-Correcting Code memory. K uloženým datům přidává redundantní bity, které umožní detekovat a často opravit jednobitovou chybu.

Taková chyba může vzniknout elektrickým rušením nebo ionizujícím zářením. V serverech, které pracují roky s velkým množstvím RAM, není pravděpodobnost zanedbatelná.

ECC ukazuje základní princip odolnosti: redundance není plýtvání, pokud díky ní dokážeme rozeznat chybu od platných dat.

5. RAID A REPLIKACE DAT

Stejnou myšlenku používají disková pole. RAID může data rozdělit a doplnit paritou tak, aby selhání jednoho či více disků nezničilo celý svazek.

V datových centrech se ochrana posouvá o úroveň výš: soubor nebo objekt existuje na několika fyzických serverech, někdy dokonce v několika budovách či geografických regionech. Když jeden uzel zmizí, klienta obslouží jiný.

Ani zde není nic „nezničitelného“. Pokud smažeme všechny repliky nebo chybná data synchronně replikujeme všude, redundance nepomůže. Odolnost vždy závisí na typu poruchy, proti níž je navržena.

6. DISTRIBUOVANÝ KONSENZUS

Systémy jako databázové clustery musí řešit nejen dostupnost, ale i otázku, která verze dat je správná. Algoritmy rodin Paxos nebo Raft umožňují skupině uzlů dohodnout se na pořadí změn, i když některé uzly selžou nebo jsou dočasně nedostupné.

To je jeden z pilířů moderních cloudových služeb. Uživatel může vnímat jednu službu, ale ve skutečnosti za ní pracují desítky či tisíce procesů, které průběžně nahrazují své mrtvé členy.

7. BYZANTSKÉ CHYBY

Ještě těžší scénář nastává, když uzel nejen mlčí, ale poskytuje různé nebo chybné informace různým částem systému. To se modeluje jako Byzantine fault.

Byzantine Fault Tolerance algoritmy používají větší redundanci a hlasování, aby systém mohl pokračovat i s určitým počtem chybných nebo kompromitovaných uzlů. Princip se používá v některých kritických distribuovaných systémech a je příbuzný mechanismům konsenzu v části blockchainových sítí.

8. WATCHDOG: KDYŽ SE PROGRAM ZASEKNE

Jednodušší, ale velmi účinná technika je watchdog timer. Program musí periodicky potvrzovat, že žije. Pokud potvrzení nepřijde, nezávislý obvod nebo proces provede restart.

Watchdogy jsou běžné v embedded systémech, automobilech, průmyslu, routerech a kosmické elektronice. Někdy je nejlepší samooprava prostě kontrolovaný restart malé části systému místo pádu celého zařízení.

9. KOSMICKÉ SONDY: FAULT TOLERANCE BEZ SERVISNÍHO TECHNIKA

Kosmická sonda je extrémní příklad. Hardware pracuje v radiaci, komunikace může trvat minuty či hodiny a technik nemůže vyměnit vadný modul.

Proto se používá redundantní avionika, radiačně odolná elektronika, ECC, bezpečné režimy a autonomní diagnostika. Pokud software zjistí nekonzistentní stav, sonda může přejít do safe mode, natočit panely ke Slunci a čekat na instrukce.

„Nezhroutit se“ zde neznamená pokračovat vždy plnou rychlostí. Znamená přejít do jednoduššího stavu, v němž zařízení přežije.

10. ERLANG: „LET IT CRASH“

Programovací jazyk Erlang, původně vyvinutý pro telekomunikační systémy Ericssonu, proslul filozofií „let it crash“. Neznamená ignorovat chyby. Znamená rozdělit program do izolovaných procesů, jejichž selhání může zachytit nadřazený supervisor a vadnou část znovu vytvořit.

Místo obrovského monolitu, kde chyba jednoho vlákna otráví celý proces, máme mnoho malých komponent s jasnou strategií restartu.

11. KONTEJNERY A ORCHESTRACE

Moderní Kubernetes a další orchestrace formalizují podobný princip v datových centrech. Pokud kontejner přestane odpovídat na health check, orchestrátor jej ukončí a vytvoří nový. Pokud zemře celý server, workload se přesune jinam.

Uživatel může zaznamenat malý výpadek nebo žádný, přestože uvnitř infrastruktury hardware skutečně selhal.

12. CHAOS ENGINEERING: PORUCHU SI VYROBÍME SCHVÁLNĚ

Netflix a další provozovatelé rozsáhlých distribuovaných služeb popularizovali chaos engineering. Myšlenka je radikální: pokud tvrdíme, že systém přežije poruchu, nemáme čekat na náhodný incident. Máme bezpečně a kontrolovaně vypínat instance, zvyšovat latenci nebo simulovat výpadek regionu a ověřovat, zda návrh opravdu funguje.

Tím se spolehlivost mění z víry na experimentálně testovanou vlastnost.

13. PROČ „100% UPTIME“ NENÍ FYZIKÁLNĚ REALISTICKÝ

Každý systém má hranici svého fault modelu. Dva redundantní zdroje nepomohou při požáru celé budovy. Tři datová centra nepomohou, pokud software obsahuje společnou chybu, která současně poškodí data ve všech třech. Záloha nepomůže, pokud nikdy nezkusíme její obnovu.

Proto inženýři pracují s cíli dostupnosti – například 99,9 %, 99,99 % nebo více – a s pojmy RTO a RPO, tedy časem potřebným k obnově a maximální přijatelnou ztrátou dat.

14. SELF-HEALING A AI

Současné platformy používají strojové učení k detekci anomálií, předpovědi poruch disků nebo dynamickému škálování. Termín „self-healing“ se tak často používá pro systém, který sám zjistí degradaci a provede nápravnou akci.

AI však neodstraňuje základní potřebu deterministických bezpečnostních mechanismů. Model může chybovat. Kritická infrastruktura proto potřebuje jasné limity, fallback, auditovatelnost a možnost zásahu člověka.

15. JAK BY VYPADAL OPRAVDU „NEPADACÍ“ OS

Místo jedné fantastické vlastnosti by kombinoval mnoho vrstev:

• paměť s ECC;
• kontrolní součty dat;
• izolaci procesů;
• transakční souborový systém;
• snapshoty a rollback;
• watchdog;
• redundantní služby;
• automatické health checks;
• replikované úložiště;
• deterministický safe mode;
• průběžné testování obnovy.

Takový systém může působit, jako by „nikdy nespadl“, protože jednotlivé pády průběžně absorbuje.

ZÁVĚR

Počítač, který se nikdy fyzicky neporouchá, neexistuje. Počítačový systém, který dokáže mnoho poruch přežít bez ztráty své služby, však není sci-fi. Je to základ moderního návrhu kritické infrastruktury.

Výzkum UCL z roku 2013 byl zajímavý nikoli proto, že by konečně odstranil všechny chyby, ale protože zdůraznil biologicky inspirovanou myšlenku: robustní systém nemusí být dokonale neměnný. Může být robustní právě proto, že se průběžně přeskupuje, zahazuje vadné části a znovu vytváří funkční stav.

16. MIKROJÁDRO A IZOLACE CHYB

Jedním ze způsobů, jak zabránit řetězové reakci, je zmenšit množství kódu běžícího s nejvyššími oprávněními. Mikrojádrové operační systémy přesouvají ovladače a služby mimo malé jádro. Pokud ovladač zvukové karty spadne, nemusí tím poškodit celý kernel.

Formálně ověřené mikrojádro seL4 jde ještě dál: důležité vlastnosti implementace byly matematicky propojeny se specifikací. To neznamená nezničitelnost, ale drasticky zmenšuje třídu softwarových chyb, které mohou porušit izolaci.

17. CRASH CONSISTENCY: JAK NEZNIČIT DATA PŘI VÝPADKU PROUDU

Představme si, že souborový systém nejprve označí blok jako použitý a až potom zapíše jeho obsah. Pokud mezi kroky vypadne elektřina, disk může zůstat v nekonzistentním stavu.

Journaling, copy-on-write a transakční techniky proto mění pořadí zápisů tak, aby se po restartu dalo jednoznačně rozhodnout mezi starým a novým stavem. Systém neočekává, že napájení nikdy nevypadne; navrhuje datovou strukturu tak, aby výpadek v libovolném okamžiku nezpůsobil nekontrolovatelnou korupci.

18. COMMON-MODE FAILURE: NEPŘÍTEL REDUNDANCE

Dva servery nejsou skutečně nezávislé, pokud oba stojí v jednom racku napájeném jedním zdrojem. Tři datová centra nejsou úplně nezávislá, pokud ve všech běží tentýž chybný update.

Nejnebezpečnější chyby jsou právě common-mode failures – jedna příčina zasáhne všechny redundantní části současně. Proto se kritické systémy snaží diverzifikovat software, hardware, lokality a někdy i implementace stejné funkce.

19. BYZANTSKÁ ODOLNOST A BEZPEČNOST NEJSOU TOTÉŽ

Fault tolerance řeší náhodnou nebo modelovanou poruchu. Kybernetický útočník se ale chová adaptivně a snaží se najít přesně tu cestu, kterou návrhář neočekával. Redundance může zvýšit bezpečnost, ale také zvětšit attack surface.

Opravdu odolný systém proto spojuje recovery s principy least privilege, autentizací, kryptografií, auditním logem a segmentací sítě.

20. „NEPADACÍ“ SYSTÉM JE PROCES, NE PRODUKT

Spolehlivost není vlastnost, kterou výrobce jednou přidá a pak na ni zapomene. Závislosti se mění, firmware stárne, certifikáty expirují a lidé dělají nové chyby. Proto mají vyspělé organizace incident response, post-mortem analýzy a pravidelně testují obnovu.

Nejodolnější systém tedy není ten, který tvrdí „nikdy neselže“, ale ten, který dokáže přesně říci, co udělá, až určitá část selže.

ZDROJE A DALŠÍ ČTENÍ

[1] University College London — Computer that never crashes (2013), systemic computing.

ucl.ac.uk
https://www.ucl.ac.uk/news/headlines/2013/feb/computer-never-crashes

[2] Dijkstra, E. W. — Self-stabilizing systems in spite of distributed control (historický základ self-stabilization; souhrny a literatura).

link.springer.com
https://link.springer.com/book/10.1007/978-3-031-02013-1

[3] The Raft Consensus Algorithm — původní projekt a materiály.

raft.github.io
https://raft.github.io/

[4] Kubernetes documentation — Self-healing.

kubernetes.io
https://kubernetes.io/docs/concepts/architecture/self-healing/

[5] NASA — Fault management / spacecraft engineering resources.

nasa.gov
https://www.nasa.gov/