Awaria Cloudflare: zdziera maskę rzekomej decentralizacji branży kryptowalut

4 poważne awarie w ciągu 18 miesięcy – dlaczego problem centralizacji jest tak trudny do rozwiązania?

Źródło: rekt news

Tłumaczenie: Saoirse, Foresight News

18 listopada 2025 roku, godzina 6:20 czasu wschodnioamerykańskiego. Wielu z nas doświadczyło przerwy w działaniu sieci.

Nie była to stopniowa awaria, nie było żadnych sygnałów ostrzegawczych. Jeszcze chwilę wcześniej przeglądałeś telefon, handlowałeś, rozmawiałeś z AI, a w następnej sekundzie wszędzie pojawiały się strony błędu 500.

Twitter nagle przestał działać podczas pisania tweeta, ChatGPT przestał odpowiadać w trakcie rozmowy, a Claude po prostu się zawiesił.

Nawet Downdetector – strona, na którą zaglądasz, gdy wszystkie inne platformy mają awarię – nie ładował się i nie mógł poinformować cię, że „wszystkie usługi padły”.

20% światowego internetu po prostu zniknęło, tylko dlatego, że Cloudflare, który miał chronić internet przed atakami, przypadkowo „zaatakował” sam siebie.

Rutynowa zmiana konfiguracji (aktualizacja uprawnień bazy danych) ujawniła ukrytą lukę w systemie ochrony przed botami, a w mgnieniu oka „strażnik” odciął wszystkich od dostępu.

W październiku, gdy Amazon Web Services (AWS) spowodował wyłączenie Coinbase, użytkownicy Twittera ze świata krypto wyśmiewali wady „centralizacji”.

A co się stało podczas awarii Cloudflare w listopadzie? Przynajmniej przez pierwsze godziny cała społeczność krypto milczała.

W końcu, gdy infrastruktura, na której opiera się Twitter, padła, nie dało się na Twitterze dyskutować o „kruchości infrastruktury”.

Wiele kluczowych usług utknęło (systemy transportowe nie działały), interfejsy sieciowe firm miały awarie, a przeglądarki blockchain, takie jak Arbiscan czy DeFiLlama, wyświetlały błędy 500 – ale sama blockchain nie wykazywała żadnych oznak przerwania konsensusu.

Kiedy twoja rewolucja „decentralizacji” może zostać zatrzymana przez zbyt duży plik konfiguracyjny jednej firmy, kto tak naprawdę trzyma władzę?

Oś czasu awarii: od „zmiany konfiguracji” do „paraliżu całej sieci”

Godzina 11:05 UTC: zakończono wdrażanie zmian w kontroli dostępu do bazy danych.

23 minuty później, o 11:28 UTC, zmiana objęła środowiska użytkowników i po raz pierwszy pojawiły się błędy w ruchu HTTP użytkowników.

Innymi słowy: awaria już się wydarzyła, ale nikt nie wiedział, gdzie leży problem.

O 11:48 UTC oficjalna strona statusu Cloudflare w końcu przyznała, że „wewnętrzne usługi mają awarię” – co w korporacyjnej nowomowie oznacza: „wszystko się posypało i wszyscy to widzą”.

Efekt domina był błyskawiczny: zmiana uszkodziła warstwę zarządzania botami Cloudflare, a gdy system ładował plik funkcji o podwójnym rozmiarze, usługa proxy po prostu „padła”.

Systemy zależne również się zawiesiły: Workers KV (usługa przechowywania klucz-wartość) i Access (usługa kontroli dostępu) nie mogły połączyć się z proxy; wskaźnik błędów w całej sieci gwałtownie wzrósł, a wraz z obciążeniem narzędzi monitorujących, zużycie CPU osiągnęło szczyt.

Ruch nadal napływał do węzłów brzegowych Cloudflare – ale usługa proxy nie mogła już odpowiedzieć.

Początkowo Cloudflare sądził, że jest atakowany, i to przez ogromny rozproszony atak DDoS.

Co dziwniejsze, nawet oficjalna strona statusu, całkowicie hostowana poza infrastrukturą Cloudflare, również padła, co sprawiło, że inżynierowie podejrzewali skoordynowany atak na systemy rdzeniowe i monitoring.

Ale to nie była prawda. Nie było ataku z zewnątrz – problem leżał po ich stronie.

Wkrótce po przywróceniu usług, CTO Cloudflare Dane Knecht opublikował publiczne przeprosiny, nazywając incydent „całkowicie nieakceptowalnym” i obwiniając za awarię rutynową zmianę konfiguracji – to ona wywołała awarię warstwy ochrony przed botami.

„Zawiedliśmy naszych klientów i szerszą społeczność internetową”, napisał Knecht w oświadczeniu. „W jednej z usług wspierających naszą ochronę przed botami istniała potencjalna luka, która po rutynowej zmianie konfiguracji nagle się ujawniła i wywołała szeroko zakrojoną awarię naszej sieci i innych usług. To nie był atak z zewnątrz.”

W szczycie awarii Downdetector otrzymał aż 11 183 zgłoszenia problemów.

Ta „cyfrowa ciemność” trwała ponad 5 i pół godziny – dopiero o 17:06 UTC usługi zostały w pełni przywrócone; jednak już o 14:30, po wdrożeniu poprawnej konfiguracji zarządzania botami na całym świecie, najpoważniejsze skutki zostały złagodzone.

Skutki awarii: od Web2 po krypto – nikt nie został oszczędzony

Platformy Web2 na pierwszej linii

Platforma X otrzymała 9706 zgłoszeń awarii.

Zamiast znajomej osi czasu użytkownicy widzieli komunikat „Ups, coś poszło nie tak”.

ChatGPT nagle „zamilkł” w trakcie rozmowy, nie odpowiadając na żadne polecenia.

Spotify przestał działać, Canva odcięła projektantów od narzędzi, a Uber i Door Dash również miały problemy z funkcjonowaniem.

Nawet gracze nie zostali oszczędzeni – gracze League of Legends byli wyrzucani z gry w trakcie rozgrywki.

Pojawiły się nawet doniesienia, że automaty do zamawiania w McDonald's wyświetlały błędy – w samym środku lunchowego szczytu i awarii infrastruktury.

Branża kryptowalutowa również nie została „oszczędzona”.

Masowe wyłączenia platform krypto

Frontend Coinbase całkowicie się zawiesił, użytkownicy widzieli tylko niedziałającą stronę logowania.

Strona internetowa i aplikacja mobilna Kraken padły – bezpośredni skutek globalnej awarii Cloudflare.

BitMEX ogłosił na stronie statusu: „Trwają prace nad ustaleniem przyczyn awarii, wydajność platformy spadła, ale środki użytkowników są bezpieczne.” – ten sam scenariusz, tylko inna giełda.

Etherscan nie ładował się, Arbiscan całkowicie padł.

Panel analityczny DeFiLlama okresowo wyświetlał błędy serwera wewnętrznego.

Nawet Ledger ogłosił, że z powodu awarii Cloudflare dostępność niektórych usług spadła.

Jedyny „wyjątek”: same protokoły blockchain

Ale następujące systemy nie zostały dotknięte:

Zgodnie z doniesieniami, główne giełdy, takie jak Binance, OKX, Bybit, Crypto.com, KuCoin, nie miały problemów z frontendem, transakcje on-chain przebiegały normalnie – blockchain działał bez zakłóceń konsensusu.

Protokoły blockchain działały niezależnie – problem nie leżał w łańcuchu, lecz w infrastrukturze Web2, przez którą użytkownicy uzyskują do niego dostęp.

Jeśli blockchain działa, ale nikt nie może się do niego dostać, czy krypto naprawdę jest „online”?

Analiza: jak jedno zapytanie do bazy danych sparaliżowało 20% sieci?

Cloudflare nie hostuje stron internetowych ani nie oferuje usług chmurowych jak AWS.

Jego rola to „pośrednik” – pośredniczy między użytkownikiem a internetem, obsługując 24 miliony stron przez węzły w 120 krajach i 330 miastach, przetwarzając 20% światowego ruchu sieciowego.

Cloudflare reklamuje się jako „tarcza i akcelerator internetu”, oferując całodobową ochronę DDoS, ochronę przed botami, routing ruchu, globalny Web Application Firewall (WAF), terminację TLS, edge computing oparty na Workers i usługi DNS – wszystko na jednej „bezpieczno-wydajnościowej” sieci.

W rzeczywistości ma 82% udziału w rynku ochrony DDoS, łączną przepustowość węzłów brzegowych 449 Tbps i jest połączony z wieloma głównymi dostawcami usług internetowych (ISP) i chmurowych na świecie.

Problem polega na tym, że gdy pośrednik zawodzi, wszystkie usługi za nim stają się „nieosiągalne”.

CTO Cloudflare Dane Knecht napisał na platformie X bez ogródek:

„Powiem wprost: dziś rano z powodu problemów w sieci Cloudflare ucierpiało wiele zależnych od nas usług, zawiedliśmy klientów i szerszą społeczność internetową.”

CEO Matthew Prince wyraził się jeszcze dosadniej:

„To najpoważniejsza awaria Cloudflare od 2019 roku... Przez ponad 6 lat nie mieliśmy awarii, która uniemożliwiłaby przesyłanie większości kluczowego ruchu przez naszą sieć.”

Techniczne źródło awarii

Wszystko zaczęło się od rutynowej aktualizacji uprawnień bazy danych. O 11:05 UTC Cloudflare wprowadził zmianę w klastrze bazy ClickHouse, by zwiększyć bezpieczeństwo i niezawodność – użytkownicy z „implicit access” mieli teraz „explicit” dostęp do metadanych tabel.

Gdzie był problem? Zapytanie generujące plik konfiguracyjny ochrony przed botami Cloudflare nie filtrowało „nazwy bazy danych”.

Zapytanie zarządzające ruchem zagrożeń zaczęło zwracać duplikaty – jedną z domyślnej bazy, drugą z bazowego magazynu r0. To podwoiło rozmiar pliku funkcji z około 60 do ponad 200 cech.

Cloudflare ustawił twardy limit 200 cech dla przydziału pamięci, uznając, że „to znacznie więcej niż obecne 60 cech”. Typowe inżynierskie myślenie: ustawić „wystarczająco szeroki” margines bezpieczeństwa, aż do niespodzianki.

Zbyt duży plik przekroczył limit, kod Rust się wywalił, a komunikat błędu brzmiał: „thread fl2_worker_thread panicked: called Result::unwrap () on an Err value” (wątek fl2_worker_thread się zawiesił: wywołano Result::unwrap () na wartości Err).

System ochrony przed botami to kluczowy komponent warstwy kontrolnej Cloudflare. Po jego awarii system health check, informujący load balancer o „zdrowych” serwerach, również przestał działać.

Co gorsza: plik konfiguracyjny był generowany co 5 minut.

Błędne dane pojawiały się tylko, gdy zapytanie działało na „zaktualizowanych węzłach klastra”. W efekcie co 5 minut sieć Cloudflare przełączała się między „normalnym” a „awaryjnym” stanem – raz ładowała poprawny plik, raz błędny.

To „skakanie” sprawiło, że inżynierowie sądzili, iż to atak DDoS – wewnętrzne błędy rzadko powodują cykle „awaria-odzyskanie”.

W końcu wszystkie węzły ClickHouse zostały zaktualizowane i każdy plik był błędny. „Skakanie” ustało, zastąpione przez „pełną, stabilną awarię”.

Bez precyzyjnych sygnałów systemowych system domyślnie przechodził w „tryb zachowawczy”, uznając większość serwerów za „niezdrowe”. Ruch napływał, ale nie był prawidłowo kierowany.

Węzły brzegowe Cloudflare odbierały żądania użytkowników – ale nie mogły ich obsłużyć.

„To nie był atak z zewnątrz”, podkreślał Knecht, „nie było złośliwych działań, to nie był DDoS. To tylko zapytanie do bazy danych bez filtra, które zbiegło się z aktualizacją uprawnień i wywołało awarię.”

Cloudflare obiecywał „99,99% dostępności” – tym razem obietnica nie została spełniona.

Tak właśnie było.

Historia się powtarza: 4 poważne awarie w 18 miesięcy – dlaczego problem centralizacji jest nierozwiązywalny?

20 października 2025 – awaria AWS trwała 15 godzin. W regionie US East 1 baza DynamoDB miała awarię DNS, co spowodowało zamrożenie Coinbase, spowolnienie Robinhood, przerwę w działaniu Infura (a więc i MetaMask), a sieci blockchain Base, Polygon, Optimism, Arbitrum, Linea, Scroll zostały wyłączone. Choć środki użytkowników były bezpieczne on-chain, wielu widziało saldo „zero”.

29 października 2025 – awaria Microsoft Azure. Problemy z synchronizacją konfiguracji Azure Front Door wyłączyły Microsoft 365, Xbox Live i usługi korporacyjne.

Lipiec 2024 – aktualizacja Windows od CrowdStrike (firma bezpieczeństwa) miała lukę. Awaria zatrzymała loty, opóźniła procedury medyczne w szpitalach, zamroziła usługi finansowe, pełne przywrócenie trwało kilka dni.

Czerwiec 2022 – poprzednia poważna awaria Cloudflare. Wiele giełd krypto musiało zawiesić usługi – ten sam schemat, tylko inny rok.

Lipiec 2019 – jeszcze wcześniejsza awaria Cloudflare. Coinbase padł, CoinMarketCap był niedostępny – to był pierwszy zignorowany „sygnał ostrzegawczy”.

W ciągu zaledwie 18 miesięcy doszło do 4 poważnych awarii infrastruktury.

Cztery awarie, ta sama lekcja: scentralizowana infrastruktura nieuchronnie prowadzi do „scenariusza scentralizowanej awarii”.

Cztery awarie mogły przyspieszyć przejście branży krypto na decentralizację – ale wciąż polega ona na infrastrukturze trzech firm.

Ile ostrzeżeń potrzeba, by branża zaczęła budować systemy zakładając, że awarie są nieuniknione, a nie tylko możliwe?

Kłamstwo decentralizacji: zdecentralizowany protokół nie oznacza zdecentralizowanego dostępu

Obiecywali ci taką wizję:

„Decentralized finance, censorship-resistant currency, trustless systems, no single point of failure, ‘not your keys, not your coins’, code is law.”

Rzeczywistość 18 listopada była brutalna: jedna poranna awaria Cloudflare zatrzymała część usług branży krypto na kilka godzin.

Prawda techniczna:

Nie zgłoszono żadnej awarii protokołu blockchain. Sieć Bitcoin działała normalnie, Ethereum również – sam łańcuch nie miał problemów.

Rzeczywistość użytkowa:

Interfejsy giełd się zawiesiły, przeglądarki blockchain padły, interfejsy portfeli nie działały, platformy analityczne się wyłączyły, a ekrany transakcyjne wyświetlały błędy 500.

Użytkownicy nie mogli dostać się do „zdecentralizowanego” blockchaina, który rzekomo „posiadali”. Protokół działał – pod warunkiem, że mogłeś się do niego dostać.

Poniższe wypowiedzi mogą być dla wielu niewygodne…

David Schwed, COO SovereignAI, nie owijał w bawełnę:

„Dzisiejsza awaria Cloudflare, awaria AWS sprzed kilku tygodni – to pokazuje, że nie można po prostu outsourcować ‘odporności na awarie’ do jednego dostawcy. Jeśli twoja organizacja musi działać 24/7, musisz budować infrastrukturę zakładając, że awarie są nieuniknione. Jeśli twój plan ciągłości działania to tylko ‘czekać, aż dostawca naprawi’, to czyste zaniedbanie.”

„Czyste zaniedbanie” – nie przypadek, nie przeoczenie, ale zaniedbanie.

Jameson Lopp trafił w sedno:

„Mamy świetną zdecentralizowaną technologię, ale przez koncentrację usług u kilku dostawców staje się ona ekstremalnie krucha.”

Ben Schiller powiedział podczas poprzedniej awarii AWS coś, co dziś jest równie aktualne:

„Jeśli twój blockchain pada przez awarię AWS, to nie jest wystarczająco zdecentralizowany.”

Zamień „AWS” na „Cloudflare” – problem ten sam. Branża nie wyciąga wniosków.

Dlaczego wybieramy „wygodę” zamiast „zasad”?

Budowa własnej infrastruktury oznacza: zakup drogiego sprzętu, zapewnienie stabilnego zasilania, utrzymanie dedykowanego łącza, zatrudnienie ekspertów ds. bezpieczeństwa, wdrożenie geograficznej redundancji, budowę systemów disaster recovery, monitoring 24/7 – każda z tych rzeczy wymaga dużych nakładów.

Korzystanie z Cloudflare to tylko: kliknięcie przycisku, wpisanie numeru karty, wdrożenie w kilka minut.

Ochronę DDoS zapewnia ktoś inny, dostępność zapewnia ktoś inny, skalowanie to czyjś problem.

Startupy chcą „szybko wejść na rynek”, VC wymagają „efektywności kapitałowej” – wszyscy wybierają „wygodę”, nie „odporność na awarie”.

Aż do momentu, gdy „wygoda” przestaje być wygodna.

Październikowa awaria AWS wywołała na Twitterze niekończące się dyskusje o „decentralizacji”.

A awaria Cloudflare w listopadzie? Cisza.

Nie z powodu „filozoficznego milczenia” ani „głębokiej refleksji”.

Po prostu: ludzie chcieli narzekać, ale ich ulubiona platforma (Twitter) też padła przez awarię infrastruktury.

Kiedy „single point of failure” jest platformą, na której wyśmiewasz „single point of failure”, nie masz gdzie narzekać.

Kiedy warstwa dostępu zależy od infrastruktury trzech firm, z których dwie miały awarię w tym samym miesiącu, „decentralizacja na poziomie protokołu” nie ma znaczenia.

Jeśli użytkownicy nie mogą dostać się do blockchaina, to co właściwie „decentralizujemy”?

Problem monopolu: trzy firmy kontrolują 60% rynku chmury – dokąd zmierza branża krypto?

AWS kontroluje około 30% światowego rynku infrastruktury chmurowej, Microsoft Azure 20%, Google Cloud 13%.

Trzy firmy kontrolują ponad 60% infrastruktury chmurowej wspierającej współczesny internet.

Branża krypto, która miała być rozwiązaniem problemu „centralizacji”, dziś polega na najbardziej scentralizowanej infrastrukturze na świecie.

Lista „centralizowanych zależności” branży krypto

• Coinbase – zależny od AWS;
• Binance, BitMEX, Huobi, Crypto.com – wszystkie zależne od AWS;
• Kraken, choć zbudowany na AWS, również ucierpiał przez awarię CDN Cloudflare.

Wiele giełd reklamujących się jako „zdecentralizowane” działa na scentralizowanej infrastrukturze.

Jest jeszcze jedna kluczowa różnica między awariami z października i listopada:

Podczas awarii AWS platforma X (dawny Twitter) działała, więc użytkownicy krypto mogli wyśmiewać „kruchość infrastruktury”.

Podczas awarii Cloudflare platforma X też padła.

Kiedy platforma, na której wyśmiewasz „single point of failure”, sama jest jego częścią, nie jest ci do śmiechu.

Ten ironiczny paradoks sprawił, że branżowa dyskusja została zduszona w zarodku.

Trzy poważne awarie w ciągu 30 dni – regulatorzy już się temu przyglądają.

Kluczowe pytania dla regulatorów

• Czy te firmy są „instytucjami o znaczeniu systemowym”?
• Czy podstawowe usługi internetowe powinny być regulowane jak „usługi publiczne”?
• Jakie ryzyka niesie połączenie „zbyt dużych, by upaść” z infrastrukturą technologiczną?
• Jeśli Cloudflare kontroluje 20% światowego ruchu sieciowego, czy to już problem monopolu?

Corinne Cath-Speth z organizacji Article 19 już podczas poprzedniej awarii AWS mówiła wprost: „Gdy jeden dostawca pada, kluczowe usługi również – media są odcięte, aplikacje jak Signal przestają działać, infrastruktura cyfrowego społeczeństwa się rozpada. Potrzebujemy pilnie dywersyfikacji chmury.”

Innymi słowy: rządy zaczynają rozumieć, że kilka firm może zatrzymać internet.

Alternatywy zdecentralizowane istnieją od dawna, ale nikt nie chce ich używać.

Na przykład Arweave do przechowywania, IPFS do rozproszonego przesyłania plików, Akash do obliczeń, Filecoin do zdecentralizowanego hostingu.

Dlaczego zdecentralizowane rozwiązania są „chwilowo modne”, ale niepopularne?

Wydajność ustępuje scentralizowanym rozwiązaniom, a opóźnienia są odczuwalne dla użytkownika.

Bardzo niska popularność, a w porównaniu z wygodą „kliknij, by wdrożyć na AWS”, obsługa zdecentralizowanych rozwiązań jest skomplikowana.

Koszty często są wyższe niż wynajęcie infrastruktury od „wielkiej trójki” (AWS, Azure, Google Cloud).

Rzeczywistość jest taka:

Zbudowanie prawdziwie zdecentralizowanej infrastruktury jest bardzo trudne – znacznie trudniejsze, niż się wydaje.

Większość projektów tylko mówi o „decentralizacji”, ale rzadko ją wdraża. Wybór scentralizowanego rozwiązania jest zawsze łatwiejszy i tańszy – aż do 4 awarii w 18 miesięcy, gdy okazuje się, że „łatwo i tanio” ma swoją cenę.

Max Li, CEO OORT, w niedawnym felietonie dla CoinDesk, wprost nazwał branżę hipokrytami:

„Branża, która szczyci się ‘decentralizacją’ i nieustannie ją promuje, a jednocześnie polega na kruchej scentralizowanej chmurze – to czysta hipokryzja.”

Jego rozwiązanie: strategia chmury hybrydowej, by giełdy rozpraszały kluczowe systemy w zdecentralizowanych sieciach.

Scentralizowane chmury mają niezastąpione zalety wydajności i skali – ale gdy w grę wchodzą miliardy dolarów i każda sekunda transakcji jest kluczowa, odporność na awarie jest znacznie niższa niż w rozwiązaniach rozproszonych.

Dopiero gdy cena „wygody” stanie się tak wysoka, że wymusi zmianę zachowań branży, „zasady” zwyciężą nad „wygodą”.

Najwyraźniej awaria z 18 listopada nie była wystarczająco dotkliwa, ta z 20 października na AWS też nie, podobnie jak awaria CrowdStrike w lipcu 2024.

Jak daleko musi zajść, by „zdecentralizowana infrastruktura” stała się wymogiem, a nie tylko tematem do rozmów?

18 listopada branża krypto nie „zawiodła” – blockchain działał perfekcyjnie.

Prawdziwą „porażką” było zbiorowe samooszukiwanie się branży: przekonanie, że można budować „niepowstrzymane aplikacje” na „łatwej do wyłączenia infrastrukturze”; że „odporność na cenzurę” ma sens, gdy trzy firmy kontrolują „kanały dostępu”; że „decentralizacja” jest prawdziwa, skoro jeden plik konfiguracyjny Cloudflare decyduje, czy miliony ludzi mogą handlować.

Jeśli blockchain nadal tworzy bloki, ale nikt nie może przesłać transakcji, czy naprawdę jest „online”?

Branża nie ma żadnego planu awaryjnego.

Gdy coś się zepsuje, trzeba czekać, aż Cloudflare naprawi, aż AWS przywróci usługi, aż Azure wdroży poprawkę.

To obecna „strategia disaster recovery” branży.

Wyobraź sobie: co się stanie, gdy tożsamość cyfrowa zostanie głęboko powiązana z blockchainem?

Departament Skarbu USA forsuje wprowadzenie tożsamości do smart kontraktów, wymagając KYC przy każdej interakcji z DeFi.

Przy kolejnej awarii infrastruktury użytkownicy stracą nie tylko możliwość handlu – ale też możliwość „potwierdzenia tożsamości” w systemie finansowym.

Awaria trwająca 3 godziny zamieni się w 3 godziny „nieladującego się ekranu weryfikacji” – bo usługa weryfikacji działa na niedziałającej infrastrukturze.

Regulatorzy chcą budować „bezpieczne barierki”, ale warunkiem jest „zawsze dostępna infrastruktura”. Awaria z 18 listopada pokazała, że ten warunek nie jest spełniony.

Gdy problem „nadmiernego nadzoru” stanie się oczywisty, branża technologiczna zwróci się ku „ochronie prywatności”.

Może nadszedł czas, by „odporność infrastruktury na awarie” też stała się takim wymogiem.

Nie powinna być „opcjonalnym bonusem”, ale „podstawowym wymogiem” – bez niej nie ma sensu mówić o innych funkcjach.

Kolejna awaria już się czai – może z AWS, może z Azure, może z Google Cloud, a może znowu z Cloudflare.

Może za miesiąc, może za tydzień. Infrastruktura się nie zmieniła, zależności się nie zmieniły, mechanizmy motywacyjne branży też nie.

Wybór scentralizowanego rozwiązania wciąż jest tańszy, szybszy, wygodniejszy – aż przestanie taki być.

Gdy kolejna rutynowa zmiana konfiguracji Cloudflare ujawni kolejną ukrytą lukę w kluczowej usłudze, znów zobaczymy znajomy „scenariusz”: wszędzie błędy 500, handel wstrzymany, blockchain działa, ale nikt nie ma dostępu, chcesz tweetować o „decentralizacji”, ale Twitter padł, firmy obiecują „następnym razem będzie lepiej”, ale nigdy nie dotrzymują słowa.

Niczego to nie zmieni, bo „wygoda” zawsze wygrywa z „zarządzaniem ryzykiem” – aż cena „wygody” stanie się nie do przeoczenia.

Tym razem „strażnik” padł na 3,5 godziny.

Następnym razem awaria może potrwać dłużej; następnym razem może się zdarzyć podczas krachu rynkowego, gdy każda sekunda transakcji decyduje o życiu i śmierci; następnym razem systemy weryfikacji tożsamości też mogą zostać wciągnięte w awarię.

Kiedy infrastruktura, od której zależy twoje życie, pada w najgorszym możliwym momencie – czyja to wina?

Źródła danych: The Guardian, Jony Popov, PC Magazine, IT Professional, CNBC, Cloudflare, TechCrunch, Associated Press, CoinDesk, Tom’s Hardware, Dane Knecht, Tom’s Guide, Surya, Sheep Esports, TheBlock, Kraken, BitMEX, Ledger, Blockchain News, Statista, Sizzling Computer, Jameson Lopp, Ben Schiller, Article 19, CoinTelegraph