Transcription

Cześć! Okazja zacna, więc opowiem Wam dzisiaj o problemie roku 2000, zwanym też bardziej pieszczotliwie pluskwą milenijną. Szykując się na wejście w nowe tysiąclecie, w skali całego świata wydano miliardy dolarów na przygotowania. Zwiastowano różnorakie katastrofy, w tym nawet zagładę nuklearną i wtedy nagle w sumie nic wielkiego się nie stało. Czy w takim razie problem ten w ogóle istniał? Czy jeszcze kiedyś się powtórzy? I czego się dzięki niemu nauczyliśmy? Zapraszam! Przenieśmy się w przeszłość, do czasów tuż po dinozaurach, ale jeszcze przed Windowsem Millennium. Są lata 60. XX wieku. Jeden kilobajt pamięci kosztuje jakieś 1000 zielonych dolarów, nie jest więc tanio, a nawet nie wziąłem pod uwagę inflacji. Dlatego bardzo istotną cechą wytwarzanego wtedy oprogramowania była jego efektywność w kwestii zarządzania pamięcią właśnie. Jeżeli tylko można było na czymś zaoszczędzić kilka bajtów, generowało to w efekcie ogromne oszczędności. Tylko jak to zrobić? Dość prostym sposobem na odchudzenie programu jest rezygnacja z przechowywania danych, które są zbędne. I tak, zamiast zapisywać za każdym razem rok w postaci 1984, wystarczy zapisać samo 84. Biorąc jeszcze pod uwagę, że daty w systemach informatycznych przechowywane są praktycznie wszędzie i to w dużych ilościach, np. w dziennikach systemowych, potencjalna oszczędność jest ogromna. Genialne, prawda? Z czasem możliwości komputerów rosły, zresztą bardzo szybko. W międzyczasie okazało się, że 640 kilobajtów pamięci jednak nie każdemu wystarczy. Sukcesywnie więc koszt przechowywania danych spadał i spadał i można było przestać oszczędzać pojedyncze bajty na każdym kroku. Niestety, kiedy w grę wchodzi zachowanie wstecznej kompatybilności z napisanym już oprogramowaniem, mało kto jest skory do wprowadzania drastycznych zmian. Tak więc jeszcze długo ten sposób zapisu dat był szeroko używany praktycznie wszędzie. I pewnie byłby nadal, gdyby nie pewien istotny detal. Zbliżał się rok 2000. I co z tego ktoś zapyta? Ano to, że 1 stycznia roku 2000 data zmienić się miała z 99 na 00. Powodowało to dwie dość spore trudności dla komputerów. Po pierwsze, bardzo istotna jest kwestia wieloznaczności. Czy dwa zera to rok 2000, czy na przykład 1900, a może 2100? Dla człowieka to nie kłopot, ponieważ bez większego problemu zrozumie, o co chodzi na podstawie kontekstu. Komputer niestety nie ma takiej możliwości. Po drugie, narażamy się na błędy chronologiczne. Jeżeli w kodzie programu występuje sprawdzenie, która data występuje wcześniej, to w takim przypadku 1 stycznia 2000 roku wyliczenie będzie błędne. Przecież 00 jest mniejsze niż 99. Jeżeli program będzie chciał policzyć na przykład czyjś wiek, to uzyskany wynik nie będzie prawidłowy. Podobnie z księgowaniem bankowych transferów. Nagle okazać się może, że pochodzą z przyszłości i przestają zgadzać się wszystkie salda. Najgorsze w tym wszystkim jednak nie było to, że spodziewano się wystąpienia błędów. Po prostu nikt do końca nie wiedział, jakie będą ich konsekwencje. W tamtych czasach nie zakładano, że wytwarzane oprogramowanie działać będzie przez wiele, wiele lat. Jedną z pierwszych osób, która zwracała uwagę na potencjalny kłopot z krótkim zapisem daty, był Bob Boehmer. To jest fascynująca postać. Pracował m.in. dla IBM-a oraz miał swój udział w tworzeniu języków programowania COBOL i TECH oraz kodu ASCII. Bob już na przełomie lat 50. i 60. napotkał na kłopot wynikający z krótkiego zapisu daty przy tworzeniu oprogramowania związanego z genealogią. Próbował edukować innych na ten temat jednak bez większych sukcesów. Zresztą nawet po przejściu na emeryturę nadal pracował nad rozwiązaniem tego problemu. Nasz ZUS byłby z niego naprawdę dumny. Tu ciekawostka. Ludzie piszący w COBOLu to takie dinozaury. Jest to bardzo stara technologia, jednak nadal wykorzystywana przez wiele firm, szczególnie sektora finansowego. Tego już nie uczy się na studiach, stąd wedle mojej wiedzy na chwilę obecną znając ten język można naprawdę nieźle zarobić. Jak w sumie w każdej egzotycznej gałęzi informatyki. Trzeba mieć jednak świadomość, że nie będzie to raczej projektowanie czegoś nowego i ekscytującego choćby z gałęzi sztucznej inteligencji, a raczej poprawianie cudzych błędów sprzed 40 lat. Na przykład podobnych do tego, o którym dzisiaj rozmawiamy. Co do prehistorii jeszcze. Pamiętacie coś takiego jak USENET? Tam też już w roku 1985 ktoś zadał pytanie, co się stanie w roku 2000. Link do tej ciekawej dyskusji zostawiam Wam w opisie. No dobra, ale tak poza tymi wszystkimi bankami i drzewami genealogicznymi, dlaczego w ogóle data jest tak istotna dla komputerów? W sumie nie powinno im robić jakiejś wielkiej różnicy, czy znajdują się w roku 3000 czy 1410. Chociaż w tym drugim przypadku mogłyby mieć kłopoty z zasilaniem, prądy wtedy były związane tylko z rzekami. A no, problem pojawia się w momencie, kiedy wymagana jest jakaś interakcja. Czy to z użytkownikiem, czy z innym systemem. Potrzebujemy zapisać datę na przykład w logach, aby wiedzieć, co się działo i w jakiej dokładnie kolejności. Podobnie w bazach danych. Przechowujemy daty z różnych powodów i w różnych celach, na przykład analitycznych. Kiedy potrzebujemy zsynchronizować pracę wielu urządzeń, nie jest to możliwe bez działającego precyzyjnie zegara. O poprawnym wyświetlaniu naszego osobistego kalendarza nawet nie wspominam. Jak więc widzicie, data w systemach informatycznych używana jest praktycznie wszędzie. Ale problem pluskwii milenijnej nie dotyczył tylko szeroko pojętych komputerów, a w sumie wszystkiego, co wyposażono w mikroprocesor. Jakakolwiek elektronika i automatyka były potencjalnie narażone na nieprzewidziane zachowanie. A co miało się dziać? Jedną z apokaliptycznych wizji, która dziś z perspektywy czasu może wydawać się śmieszna, była zagłada nuklearna całego świata. Czy zegary w komputerach elektrowni atomowych nie zwariują, doprowadzając do wybuchów reaktorów? A może systemy rakiet balistycznych z czasów zimnej wojny w wyniku jakiejś automatycznej, zapomnianej procedury wystrzelą wszystkie ładunki nuklearne? Nawet jeżeli nie dojdzie do wybuchów, to czy wszystkie elektrownie, sygnalizacje świetlne, szpitale, giełdy, czy cała reszta infrastruktury niezbędnej nam do życia, będzie nadal działać? Czy w systemach nawigacyjnych samolotów nie dojdzie do jakiegoś błędu, w wyniku którego wszystkie naraz spadną z nieba? Swoją drogą, byłoby z tego dość sporo odcinków katastrof w przestworzach. Z dzisiejszej perspektywy może się to wydawać niedorzeczne, czy wręcz foliarskie, ale ludzie naprawdę się tego obawiali przed nadejściem roku 2000. W dodatku, znikoma wtedy wiedza na temat nowych technologii na pewno nie pomagała. Oliwy do ognia dolewały oczywiście wszelkiej maści brukowce i inne superaki prześcigające się w wymyślaniu coraz to i bardziej idiotycznych nagłówków. Prepersi robili zapasy jedzenia, paliwa, wody, czy też broni i amunicji. Sytuacja wykorzystywała również niezliczona rzesza skamerów od pseudoreligijnych guru wieszczących koniec świata, podobnie jak to dziś niektórzy robią ze sztuczną inteligencją, po osoby oszukujące właścicieli kart kredytowych. Nie pomagało to całej sytuacji. Panika, taka z prawdziwego zdarzenia, była ostatnim, czego świat w tamtej chwili dodatkowo potrzebował. Tylko jak przygotować się na nadejście takiego błędu i naprawić zawczasu swoje systemy? Teoretycznie jest to dość proste. Trzeba przejrzeć całe oprogramowanie, jakim dysponuje ludzkość i sprawdzić, gdzie występuje data w takim krótkim formacie, a potem zmienić ten format na długi. A, no i jeszcze warto byłoby przetestować, czy wszystko działa prawidłowo. No bo jeżeli nasza aplikacja po prostu przestanie działać, to w sumie nie jest to jeszcze tragedia. Gorzej, jeżeli będzie działać dalej, jednak generując masę błędów i np. potencjalnie uszkadzając zbierane latami dane. Proste? W teorii może nawet tak. Ale szybko pojawiają się dość spore problemy. Np. nie do każdego oprogramowania, z którego korzystamy, mamy kody źródłowe. Naprawa w takim wypadku może i nie jest niemożliwa, ale na pewno znacznie utrudniona. Dekompilacja i dezasemblacja aplikacji, z których korzystamy, to syzyfowa praca. Zresztą wspominałem o tym w niedawnym odcinku o aferze z pociągami Newagu. No ale zegar nieubłaganie tyka, a czasu na poprawki wcale nie przybywa. No i do takiego zadania trzeba też niewyobrażalnej wręcz rzeszy programistów i testerów, których po prostu w tamtych czasach nie ma. Koszty związane z naprawą błędów na taką skalę szacowano na wiele miliardów dolarów. Podaje się zresztą, że takie kwoty wydano w większości zachodnich krajów ze Stanami Zjednoczonymi oczywiście na czele. Na ratunek Amerykanom i reszcie świata niespodziewanie ruszyli Hindusi. Co ciekawe, pomogło im np. to, że pracowali przeważnie na dość leciwym już sprzęcie, nawet jak na tamte czasy. Spotykali się więc z problemami, o których inni zdążyli już zapomnieć. Dzięki tym wydarzeniom właśnie rynek outsourcingu w Indiach mógł znacznie się rozwinąć. Niektórzy nawet uważają, że to dzięki temu okresowi dzisiaj są taką potęgą w branży. W roku 1998 sektor IT stanowił nieco ponad 1% indyjskiego PKB. 20 lat później było to już prawie 8 razy więcej. Z ciekawostek Rosjanie podobno mieli to wszystko w nosie. W końcu co ma być, to będzie. Pożywią i widim. Jak coś rzeczywiście przestawało działać, to pewnie po prostu przestawiali daty na 1984, a wtedy pozostawało już tylko strzelić po kielichu, gratulując sobie świetnie wykonanej roboty. Co się tak naprawdę wydarzyło w godzinę zero, czyli w sylwestrową noc roku 1999 na 2000? Które z systemów okazały się wrażliwe na błędy? Czy świat skończył się, a my od tamtej pory żyjemy w symulacji? Podam Wam kilka przykładów, a Wy sami ocencie ich powagę. United States Naval Observatory, czyli taka leciwa instytucja, której zadaniem jest m.in. podawanie oficjalnego czasu Stanów Zjednoczonych, na swojej oficjalnej stronie internetowej wyświetlała aktualny rok jako 19 tys. setny. W Australii przestały działać automaty do biletów autobusowych. To pewnie dlatego, że były do gór nogami. Szkody finansowe z tym związane oszacowano mniej więcej na poziomie porównywalnym do skutków zbombardowania Centrum Sosnowca. Kilka elektrowni atomowych odnotowało drobne błędy lub wyłączyło się, jednak żadna z nich nie wybuchła. Przynajmniej tym razem. Część terminali do kart płatniczych odrzucała ważne karty, a niektóre bankomaty nie działały. Internet Explorer, tak, mówiłem, że to było zaraz po dinozaurach, oraz Hotmail wyświetlały rok 3 tys. dziewięćsetny. W Korei Południowej wezwano ludzi do sądu na 4 stycznia 1900 roku. Ciekawe, czy ktoś dostał jakąś karę za niestawiennictwo. Satelity szpiegowskie Stanów Zjednoczonych przez kilka dni transmitowały całkowicie nieczytelne dane. Co ciekawe, podobno przyczyną tego nie była sama pluskwa milenijna, ale właśnie łatka, która wspomniane satelity miała na nią odpornić. Na koniec zostawiłem jednak najpoważniejszą sprawę. Ktoś w Nowym Jorku zwrócił z opóźnieniem wypożyczony film na kasecie VHS. Wypożyczalnia kaset wideo, tak było kiedyś coś takiego, wyliczyła karę na ponad dziewięćdziesiąt jeden tysięcy dolarów za sto lat opóźnienia. Więc jak? Było grubo? Czy niekoniecznie? 1 stycznia, w momencie kulminacyjnym całego strachu, w sumie nie stało się praktycznie nic. Ale to tylko fragment historii. Tak naprawdę w roku 2000 mieliśmy do czynienia nie z jednym kłopotem związanym z datą, a z dwoma. O ile cały blicht i sława przypadły właśnie pluskwie milenijnej, o tyle wystąpił jeszcze problem związany z Rokiem Przestępnym. Algorytm jego wyznaczania wcale nie jest taki prosty. Sam do chwili przygotowywania tego odcinka myślałem, że po prostu dzieli się przez cztery. I wiecie co? Bo rzeczywiście Rok Przestępny to taki, który jest podzielny przez cztery. Ale nie może być podzielny przez sto. No chyba, że jest podzielny przez czterysta. I o ile pierwsze dwa warunki jeszcze są dość powszechnie znane, o tyle ten ostatni czasem mógł zostać pominięty lub zapomniany, bo jest przecież spełniony raz na czterysta lat. A technologia mikroprocesorów w roku 1600 stała na dość niskim poziomie. No ale właśnie Rok 2000 był znowu takim wyjątkiem od wyjątku. Sytuacji nie pomagał dodatkowo fakt, że 29 lutego był w przeciwieństwie do Nowego Roku dniem roboczym, więc działo się wtedy zdecydowanie więcej. Potencjał na wystąpienie poważnych problemów znacznie więc urósł. Ten błąd zresztą padł też niejako ofiarą sukcesu w radzeniu sobie ze zmianą daty na lata 2000. Z racji tego, że przejście z Sylwestra w Nowy Rok poszło tak gładko, niewiele osób brało na poważnie kwestie związane z Rokiem Przestępnym. Szczęśliwie również 1 marca roku 2000 nie nastąpił koniec świata. Zaczęły pojawiać się więc głosy, że był to wszystko po prostu jakiś nieśmieszny prank siejący zbędną panikę. A pieniędzy na łatanie dziur w oprogramowaniu lepiej było nie wydawać. Czy panikowano niepotrzebnie? I tak, i nie. Z jednej strony praktycznie nic się nie stało, ale istnieje spora szansa, że to właśnie dzięki dobremu przygotowaniu konsekwencje były tak niewielkie. Szacuje się, że USA wydały około 100 miliardów dolarów, aby poradzić sobie z problemem roku 2000. Badacze zarzucali, że to kwota o jakieś 30% zbyt wysoka i pieniądze po prostu poszły w błoto. Bardzo spodobał mi się też cytat z Paula Safo, który zajmował się tym zagadnieniem. Powiedział on, nigdy nie zostaniesz doceniony za katastrofy, którym zapobiegłeś. W szczególności, jeżeli jesteś programistą i nikt nie rozumie, czym się zajmujesz. Bo dzięki temu, że wprowadzono wiele różnych procedur na czarną godzinę, staliśmy się m.in. bardziej odporni na katastrofy, również te niespodziewane. Np. po ataku na wieżę World Trade Center półtorej roku później, systemy finansowe były w stanie wznowić pracę już po około tygodniu. To w dużej mierze zasługa testów sprawdzających połączenie pomiędzy nimi, dzięki czemu można było sprawdzić i zagwarantować, że dane są zgodne między wszystkimi uczestnikami handlu. Bez przygotowania na taką ewentualność zajęłoby to pewnie wielokrotnie więcej czasu. Ponadto całe zamieszanie miało jeszcze jeden istotny aspekt. Chyba po raz pierwszy na tak szeroką skalę uświadomiło ludzkość, oczywiście razem z premierą pierwszego Matrixa, jak bardzo jesteśmy uzależnieni od nowoczesnych technologii. Dzisiaj w sumie też zwracamy na to uwagę, głównie w sytuacjach, gdy mówimy o bezpieczeństwie naszych danych i różnorakich atakach. Ale po co o tym mówić w kontekście innym niż historyczne? Przecież programiści uczą się na błędach i ten problem nigdy już więcej nie wystąpi. I wtedy właśnie na scenę wchodzi Unix cały na biało. A raczej wejdzie w roku 2038. Mowa o błędzie, który został pieszczotliwie nazwany Epokalips od słowa epok znaczącego początek. Zakładam, że drugi człon, czyli słowo apokalipsa jest Wam znane, na przykład kiedy skończy się papier toaletowy. Początkiem czasu w 32-bitowych systemach Unix jest północ 1 stycznia roku 1970. I każda sekunda, która upłynęła od tego momentu podnosi wartość daty o 1 bit w 32-bitowej zmiennej ze znakiem. W takiej zmiennej można przechowywać pewną maksymalną wartość, więc co sekundę zbliżamy się do jej limitu. I ten właśnie limit to godzina 3.14 i 7 sekund 19 stycznia 2038 roku. Co wydarzy się dokładnie w następną sekundę? Ano dojdzie do tak zwanego przepełnienia zmiennej, czyli zaczniemy liczyć od początku. Ale w związku z tym, że zmienna daty przechowuje również znak, to nie wrócimy do roku 1970, ale aż do grudnia roku 1901. Jakie będą tego konsekwencje? Systemy 32-bitowe oparte o Unixa, odwołując się do dat po 2038 roku, mogą zwracać błędy. Na przykład starsze telefony z Androidem po ustawieniu w systemie takiej daty przestają się uruchamiać. Uprzejmie proszę w tym miejscu, aby nie psuć telefonów znajomym. Problem może też dotyczyć urządzeń wbudowanych, których producenci po prostu nie przewidzieli, że będą one działać tak długo. Albo po prostu mieli to w nosie. Zwróćcie uwagę, że nie dotyczy to oprogramowania, w których korzysta się z 64-bitowych zmiennych. Tam zakres dat kończy się za jakieś około, grubsza licząc, 292 miliardy lat. A więc spokojnie zdążycie jeszcze nagotować bigosu. No dobra, powiecie. To pojedynczy i odległy jeszcze w czasie błąd. W dodatku dotyczy jakiegoś tam Unixa. A taki Microsoft, jako poważna korporacja, na pewno ma to przetestowane. No tak, nie do końca. Na przełomie roku 2021 i 2022 bardzo podobny błąd przytrafił się serwerom Microsoft Exchange. Nie dotyczył on może samego czasu, ale był z nim mocno związany. W dużym skrócie sposób numerowania aktualizacji systemu do wykrywania złośliwego oprogramowania zaczynał się od dwucyfrowego roku. Czyli na przykład 21-12-31 byłby aktualizacją z Sylwestra roku 2021. Aktualizacja w nowym roku miałaby w tej nomenklaturze numer 22-01-01. Za datą dodawany był jeszcze czterocyfrowy numer. Dzięki temu system zawsze powinien jasno wiedzieć, która aktualizacja jest tą najnowszą. No i jak się już pewnie domyślacie, zmienna, w której przechowywano numer aktualizacji, miała pojemność 31 bitów. A więc maksymalna jej wartość została przekroczona w momencie, w którym rok zmienił się na 2022. W efekcie system anty-malware serwera Exchange nie był w stanie działać poprawnie, a przesyłane maile lądowały w ciągle wydłużającej się kolejce. Tymczasowym rozwiązaniem problemu było wyłączenie mechanizmu wykrywania złośliwego oprogramowania, jednak to dość marna rekomendacja. Wyobrażacie sobie bycie administratorem takiego padniętego systemu, kiedy telefon dzwoni o czwartej rano w nowy rok, a Wy jeszcze jesteście na turbokacu? Łączę się w bólu ze wszystkimi, którzy tak właśnie spędzili 1 stycznia, dwa lata temu. Wybaczcie, że Wam o tym przypomniałem. Co robić i jak żyć? Pamiętaj, żeby przy projektowaniu aplikacji czy też systemów nie iść na algorytmiczne skróty, np. pomijając jakiś istotny warunek, który jednak ma zastosowanie, tylko po prostu niezwykle rzadko. Zastanów się, jakie konsekwencje nawet w dalszej przyszłości będą miały wybory, których dokonujesz. Nigdy nie wiesz, czy to właśnie Twoim zadaniem nie zostanie kiedyś utrzymywanie tak niedbale napisanego oprogramowania. Jeżeli zarządzasz systemami, szczególnie takimi, które do najmłodszych nie należą, to może warto sprawdzić ich wrażliwość na tego typu błędy. Tam, gdzie nie dało się użyć daty w formacie czterocyfrowym, czasami stosowano różne sztuczki. Np. definiowano na sztywno, że lata od 00 do 50 są już w XXI wieku. W tym przypadku, w roku 2051, taki system cofnie się o 100 lat do tyłu. Warto więc sprawdzić, co w konsekwencji się stanie, np. zmieniając w jakimś środowisku testowym daty i przenieść się o kilkadziesiąt lat w czasie do przodu. Po co? Aby po prostu mieć pewność, że akurat na okoliczność tego zagrożenia jesteś odporny. Podobnie jest zresztą w kwestii wspomnianego dzisiaj epokalips, na którego nadejście masz jeszcze czas się dobrze przygotować. Jesteśmy coraz bardziej zależni od technologii. Korzystamy też z wielu urządzeń, które na co dzień ratują życie wielu ludzi. Warto byłoby sprawdzić, czy ich działanie nie zostanie zakłócone. Jak chyba widzisz, zarządzanie czasem w systemach nie jest trywialną sprawą. Polskie koleje też się z nim nie do końca uporały, bo za każdym razem, kiedy dochodzi do zmiany czasu na zimowy, pociągi muszą się na godzinę zatrzymać. Na szczęście nie robią tego w środku pola, ale na najbliższej stacji. Z racji tego, jak szeroko czas wykorzystywany jest praktycznie wszędzie, jakiekolwiek wpadki w tej kwestii mają bardzo poważne konsekwencje. Warto więc korzystać z centralnych źródeł czasu, dzięki serwerom NTP oraz oprogramowaniach jak Crony czy też protokołu NTPsec. Ale być może w roku 2038 ktoś odkopie ten materiał. W takim przypadku życzę wszystkim, abym nie mógł powiedzieć, a nie mówiłem. I to już wszystko na dziś. Tymczasem dziękuję za Waszą uwagę i do zobaczenia w nowym roku!