Błąd w systemie płatności AWS doprowadził do usunięcia danych. Historia programisty stała się przestrogą dla użytkowników chmury

Inżynier oprogramowania i znany w społeczności open-source deweloper, Abdelkader Boudih, posługujący się pseudonimem „Seuros”, doświadczył sytuacji, którą sam określił mianem „całkowitej cyfrowej anihilacji”. Jego konto w usłudze Amazon Web Services (AWS), z którego korzystał przez dekadę, zostało nagle usunięte wraz z całą zawartością. Sprawa, która początkowo wyglądała na błąd w systemie płatności, ujawniła głębsze problemy systemowe w obsłudze klienta i architekturze usług jednego z największych podmiotów na rynku chmury obliczeniowej.

Koszmar z obsługą klienta i nagła kasacja danych

Wszystko zaczęło się w lipcu 2025 roku, kiedy Seuros otrzymał prośbę o weryfikację konta. Problem dotyczył faktu, że jego rachunki w AWS od blisko roku pokrywała firma zewnętrzna, która nagle zniknęła z rynku. Mimo że deweloper posiadał na koncie własną, aktywną kartę płatniczą i wielokrotnie prosił o przywrócenie jej jako głównej metody rozliczeń, jego prośby spotykały się z odmową.

Kulminacją był 20-dniowy maraton kontaktów z działem wsparcia AWS. Jak relacjonował Boudih na swoim blogu, dziewięciu różnych konsultantów udzielało mu jedynie szablonowych, wymijających odpowiedzi, nie potrafiąc odpowiedzieć na kluczowe pytanie: czy jego dane wciąż istnieją. Cały proces zakończył się 23 lipca, w dniu urodzin programisty, kiedy otrzymał powiadomienie o zamknięciu konta. Jak twierdził, stracił w ten sposób nie tylko narzędzia deweloperskie, ale również nieopublikowane książki, tutoriale i lata pracy.

Zwrot akcji: interwencja jednego pracownika i odzyskane dane

Historia nabrała nieoczekiwanego zwrotu, gdy pierwszy artykuł Seurosa na ten temat zyskał dużą popularność w sieci. Skontaktował się z nim pracownik AWS, Tarus Balog, który zszokowany sytuacją postanowił interweniować. Dzięki jego zaangażowaniu sprawa została eskalowana na najwyższy poziom menedżerski, co doprowadziło do utworzenia zgłoszenia o najwyższym priorytecie.

Ku zdziwieniu dewelopera, po kilku dniach jego konto zostało w pełni przywrócone. Okazało się, że dane nigdy nie zostały trwale usunięte, co rzuciło nowe światło na całą sytuację i kompetencje działu wsparcia.

Odkrycie, które podważa wersję AWS

Kiedy Seuros odzyskał dostęp do konta, dokonał odkrycia, które podważyło całą komunikację z AWS. Okazało się, że jego infrastruktura wcale nie została trwale usunięta – kluczowe serwery były jedynie wyłączone i gotowe do ponownego startu. Co więcej, kopia zapasowa jego bazy danych została wykonana cztery dni po tym, jak obsługa klienta zapewniała go, że wszystko zostało bezpowrotnie skasowane.

Według wyjaśnień, które otrzymał, prawdziwym problemem technicznym była architektura połączonych płatności. Jego konto było tak mocno powiązane z kontem znikającego płatnika, że ich rozdzielenie wymagało niestandardowej, ręcznej interwencji i przywrócenia obu kont jednocześnie. Ta operacja wykraczała poza standardowe procedury, do których dostęp miał zwykły dział wsparcia.

Głos społeczności

Sprawa wywołała ożywioną dyskusję na forach internetowych, takich jak Reddit. Choć wielu użytkowników współczuło deweloperowi, znaczna część społeczności zwróciła uwagę na ryzyko, jakie podjął, decydując się na model współdzielonego płatnika. Wielu komentujących podkreślało, że oddając kontrolę nad płatnościami stronie trzeciej, Seuros faktycznie utracił pełną własność nad swoim kontem w oczach AWS. Jeden z użytkowników ujął to wprost:

Zdaniem krytyków, choć reakcja AWS była skrajna, deweloper sam naraził się na niebezpieczeństwo, angażując się w „resellerski” schemat rozliczeń, który jest często odradzany ze względu na utratę kontroli.

Lekcje z cyfrowej katastrofy

Chociaż dane Seurosa ostatecznie odzyskano, jego historia stała się głośną przestrogą dla wszystkich użytkowników chmury. Ujawniła, że nawet najlepsze praktyki tworzenia kopii zapasowych w ramach jednego dostawcy mogą zawieść, jeśli sam dostawca stanie się źródłem problemu.

Przypadek ten uwypuklił kilka systemowych słabości:

1. Bezosobowe wsparcie techniczne, które nie jest w stanie odejść od skryptów i wykazać się elastycznością.
2. Niejasna terminologia, gdzie słowo „zakończony/terminated” może w praktyce oznaczać coś zupełnie innego w zależności od kontekstu.
3. Ryzyko związane ze złożonymi modelami rozliczeniowymi, które mogą prowadzić do utraty kontroli nad własnymi zasobami.

Seuros podkreśla, że jego zaufanie do AWS zostało nadszarpnięte. Jednocześnie docenia pomoc konkretnego pracownika, która udowodniła, że nawet w największych korporacjach jednostka potrafi zrobić różnicę. Jego historia to jednak przede wszystkim ostrzeżenie: w chmurze nigdy nie należy ufać jednemu rozwiązaniu bez posiadania niezależnej strategii wyjścia i zewnętrznych kopii zapasowych.