Rok 2000 i pluskwa Y2K – historia paniki informatycznej
Grudzień 1999. Rządy wydają miliardy, dziennikarze piszą o apokalipsie, sklepowe półki z żywnością pustoszeją. Czy pluskwa Y2K była naprawdę tak groźna? A może to był największy sukces w historii IT – problem, który nie wybuchł, bo go naprawiono?
Czym był problem Y2K?
Komputery przez dekady zapisywały rok jako dwie cyfry: 1985 → "85", 1999 → "99". Powód był prozaiczny – w latach 60. i 70. każdy bajt pamięci kosztował krocie. Nikt poważnie nie planował, że systemy będą działać 30–40 lat.
Problem pojawił się, gdy 1999 przeszło w 2000. System zapisujący rok jako "00" mógł interpretować to jako rok 1900. Efekty? Aplikacje finansowe mogłyby naliczać odsetki za 100 lat, harmonogramy i daty ważności stałyby się nonsensowne, a logi systemowe – bezużyteczne.
Gdzie problem był realny, a gdzie nie?
Nie każdy system był podatny w równym stopniu. Najbardziej zagrożone były systemy mainframe z lat 60.–80. używane przez banki, ubezpieczalnie i administrację państwową, pisane w języku COBOL z hardkodowanymi dwucyfrowymi datami. Do tego dochodziły systemy wbudowane w urządzeniach przemysłowych.
Najmniej zagrożone: nowy sprzęt, systemy z czterocyfrowymi datami, większość sprzętu konsumenckiego. Wbrew medialnej narracji, lot samolotem 1 stycznia 2000 nie był szaleństwem – systemy awioniczne były szczegółowo sprawdzone i certyfikowane.
Skala i koszty przygotowań
Szacunki mówią o 600 miliardach dolarów wydanych globalnie na naprawę Y2K w latach 1995–1999. Sama Wielka Brytania wydała 14 miliardów funtów, USA ponad 100 miliardów dolarów. Banki zatrudniały emerytowanych programistów COBOL, bo młode pokolenie już tego języka nie znało.
Zaangażowano miliony programistów – to jeden z powodów eksplozji outsourcingu IT do Indii. Indyjskie firmy programistyczne (Infosys, Tata, Wipro) zdobyły globalną reputację właśnie podczas Y2K.
Co się naprawdę stało 1 stycznia 2000?
Północ nadeszła i... niewiele się stało. Kilka drobnych incydentów:
- Stacja monitoringu nuklearnego w Tennessee wyświetliła rok 1900 – szybko naprawione, zero zagrożenia
- Japońskie reaktory atomowe wyświetliły błędy daty – nie miało to wpływu na bezpieczeństwo
- Kilka systemów wojskowych miało problemy z logami
- Belgijskie autobusy przez kilka godzin nie drukowały ważnych biletów
Żadnego blackoutu. Żadnego bankructwa banku. Żaden samolot nie spadł. Żaden reaktor nie eksplodował.
Sukces czy przekręt?
Opinie do dziś są podzielone. Sceptycy mówią: "Y2K to największy przekręt w historii IT – programiści zarobili miliardy na fikcyjnym problemie." Specjaliści odpowiadają: "Problem był realny. Nie wydarzyło się nic strasznego właśnie dlatego, że go naprawiliśmy."
Rzeczywistość jest pośrodku. Problem istniał w wielu krytycznych systemach – i w tych systemach faktycznie znaleziono i naprawiono setki tysięcy błędów. Media i część branży IT podgrzały atmosferę paniki ponad miarę, ale rdzeń problemu był autentyczny.
Lekcja, która nadchodzi: problem roku 2038
Historia Y2K może się powtórzyć. Unix Timestamp Problem 2038 – 32-bitowe systemy przechowujące czas jako liczbę sekund od 1970-01-01 przepełnią się 19 stycznia 2038 o 03:14:07 UTC. Większość nowoczesnych systemów już używa 64-bitowych timestampów – ale systemy wbudowane w infrastrukturze przemysłowej, urządzeniach medycznych i starych serwerach? To kwestia czasu i uwagi.
Twoja infrastruktura IT nie ma podobnych tykających bomb?
Stare systemy, nieaktualizowane oprogramowanie, urządzenia z lat 2000. Audyt IT znajdzie problemy zanim staną się kosztownymi awariami.