Sięgnijmy pamięcią do roku 2000, kiedy niektórzy z niepokojem odliczali dni do sylwestra w obawie, że globalna infrastruktura IT po prostu… padnie.
Czym dokładnie był słynny problem roku 2000 (Y2K)? Czy rzeczywiście groził nam technologiczna apokalipsa, czy może raczej dobrze opakowana panika?
Cofnijmy się znowu w czasie, by zrozumieć jedno z największych wyzwań w historii informatyki.
Problem roku 2000
W latach gdy komputery zajmowały czasami całe pomieszczenia, a przestrzeń na dane mierzono w bajtach, każdy bit był na wagę złota. Dlatego wcześni programiści oszczędzali miejsce, gdzie tylko się dało, również w formacie dat. Zamiast zapisywać rok jako cztery cyfry (np. 1987), skracano go do dwóch (czyli np. 87).
Na czym polegał problem? Otóż komputery nie miały pojęcia, co zrobić z datą 00. Zadawano pytanie czy odczytają to jako 1900 czy 2000? Dla systemów bankowych czy baz danych różnica była fundamentalna.
Programy mogły np.:
W ekstremalnych przypadkach przewidywano nawet awarie systemów lotniczych, elektrowni, szpitali itp… Wystarczyło, że zegar systemowy przeskoczył nagle z 31.12.1999 do 01.01.1900, by efekt domina mógł rozpocząć się na dobre.
Nie był to klasyczny błąd programistyczny, ale raczej konsekwencja długotrwałych decyzji projektowych i braku przewidywania skutków w dłuższym horyzoncie czasowym.
Pod koniec lat 90. Temat Y2K do tego stopnia rozgrzał media, rządy, firmy, że szacunkowe przygotowania do przełomu milenijnego kosztowały świat ponad 300 miliardów dolarów.
Tylko w samych Stanach Zjednoczonych utworzono specjalne komitety Y2K, a największe firmy IT typu IBM, Microsoft, Oracle rozpoczęły intensywne testy i audyty.
Sam Pentagon przeanalizował 2,5 miliona linii kodu w systemach obronnych, a FAA (amerykańska agencja lotnictwa) przetestowała wszystkie systemy kontroli ruchu.
W Polsce również nie zignorowano tematu, spółki strategiczne jak np. PKO BP, ZUS, ORLEN i Telekomunikacja Polska prowadziły na bieżąco wewnętrzne testy. W niektórych przypadkach profilaktycznie wymieniono nawet całe systemy legacy (systemy przestarzałe), które dawały zbyt duże ryzyko.
1 stycznia 2000
Kiedy już nadszedł długo wyczekiwany moment, zegary przeskoczyły na rok 2000 i świat się nie skończył. Nie odcięto prądu, z nieba nie spadły samoloty, nie zniknęły pieniądze z kont.
Ale czy to oznacza, że problem był wydumany? Nie do końca, bo się przygotowaliśmy.
Dzięki odpowiednim inwestycjom i ogromowi pracy wykonanej wcześniej, udało się uniknąć większości katastrof, które teoretycznie mogły się wydarzyć.
Niemniej jednak, zdarzały się drobne incydenty typu terminale kart płatniczych błędnie ustawiły datę na 1900 lub systemy pocztowe miały problemy z sortowaniem przesyłek.
Sumarycznie – nie był to koniec świata, jednakże problem roku 2000 zdecydowanie nauczył nas, że coś z pozoru błahego może urosnąć do rangi wyzwania na skalę globalną, a drobne błędy są zbyt często lekceważone, aż do momentu, gdy skala systemu sprawia, że ich naprawa kosztuje miliony.
Czy podobna sytuacja może się powtórzyć?
Zdecydowanie tak i już mamy tego przedsmak – Problem roku 2038
W tym wypadku problem polega na tym, że systemy 32-bitowe oparte na tzw. Unix time (czas uniksowy) przechowują datę jako liczbę sekund od 1 stycznia 1970. Limit tej liczby dla nich kończy się 19 stycznia 2038 o godzinie 03:14:07 UTC, co może spowodować poważne błędy w obliczaniu upływu czasu.
Czy podejmiemy odpowiednie kroki, które temu zapobiegną? Przekonamy się za 13 lat.
Wróć
