Jak OpenAI wytropiło 18-letni błąd w Linuksie dzięki analizie zrzutów pamięci
OpenAI opisało, jak analiza zrzutów pamięci z awarii własnej infrastruktury doprowadziła do wykrycia i naprawy błędu obecnego w oprogramowaniu od 18 lat.
👁 687 przeczytań
Za każdą awarią, która kładzie proces obliczeniowy na łopatki, zostaje ślad: zrzut pamięci, czyli fotografia stanu programu w momencie, gdy przestał działać. W infrastrukturze OpenAI takich fotografii powstają tysiące. Zamiast usuwać je jak cyfrowe śmieci, inżynierowie firmy potraktowali je jak materiał dowodowy - i podeszli do problemu jak epidemiolodzy, którzy w rozproszonych przypadkach chorób szukają jednego, wspólnego źródła zakażenia.
Ta metoda ma nawet nazwę zaczerpniętą z medycyny: epidemiologia zrzutów pamięci. Zamiast reagować na każdą awarię z osobna, OpenAI zebrało je razem, poszukując statystycznych wzorców. Efektem tego dochodzenia było wytropienie błędu, który tkwił w używanym oprogramowaniu od około 18 lat, ukryty przed niezliczonymi programistami przez niemal dwie dekady.
Pojedyncza awaria kłamie, tysiąc awarii mówi prawdę
Klasyczne debugowanie zaczyna się od jednego incydentu: coś się wysypało, ktoś otwiera zrzut pamięci, próbuje odtworzyć sytuację i znaleźć przyczynę. Problem w tym, że pojedynczy zrzut bywa mylący. Objaw widoczny w momencie awarii często nie jest jej prawdziwą przyczyną - to końcowy efekt łańcucha zdarzeń, który zaczął się znacznie wcześniej i w zupełnie innym miejscu programu.
Podejście epidemiologiczne odwraca tę logikę. Zamiast pytać „dlaczego padł ten konkretny proces”, OpenAI zapytało „co łączy wszystkie procesy, które padły”. Przy skali, na jakiej działa firma, próbka jest ogromna, a to zmienia jakość wniosków: przypadkowy szum się uśrednia, a powtarzalne wzorce zaczynają wystawać ponad tło. Coś, co w jednym zrzucie wygląda na dziwny zbieg okoliczności, w tysiącu zrzutów zamienia się w twardy sygnał.
W praktyce oznaczało to zbudowanie danych i narzędzi wokół awarii - traktowanie ich jako zbioru, który można przeszukiwać, grupować i analizować statystycznie. Dopiero z tej perspektywy dało się dostrzec, że część pozornie niepowiązanych awarii ma wspólny mianownik ukryty głęboko w bazowym oprogramowaniu.
Błąd starszy niż większość dzisiejszych aplikacji
Najbardziej uderzający w całej historii jest wiek znalezionego defektu. Osiemnaście lat to w informatyce epoka - błąd przetrwał niezliczone wersje systemów, aktualizacje i przeglądy kodu, a mimo to nie został wcześniej namierzony. Nie dlatego, że nikt nie patrzył, tylko dlatego, że objawiał się rzadko i w sposób, który w pojedynczych przypadkach łatwo było zrzucić na karb losowego pecha.
To pokazuje coś istotnego o dojrzałym oprogramowaniu: fakt, że kod działa od lat, nie znaczy, że jest wolny od wad. Znaczy tylko, że jego wady są na tyle rzadkie, że nie bolą wystarczająco często, by ktoś zainwestował czas w ich wytropienie. Skala OpenAI sprawiła, że nawet bardzo rzadki błąd zaczął pojawiać się dostatecznie regularnie, by stać się widoczny w danych.
Firma opisała cały proces w publikacji „Core dump epidemiology: fixing an 18-year-old bug”, przedstawiając go jako przykład tego, jak infrastruktura danych i myślenie statystyczne mogą wspierać klasyczną robotę inżynierską.
Google · Twoje źródłaPromptowy wyżej w Twoim Google - jednym kliknięciemDodaj do preferowanych źródeł →Poprawka, która wraca do wszystkich
Kluczowe jest to, co stało się po znalezieniu błędu. Skoro tkwił on w bazowym, powszechnie używanym oprogramowaniu, jego naprawa nie kończy się na wewnętrznej infrastrukturze OpenAI. Poprawka wraca do wspólnego kodu, z którego korzysta znacznie szersza społeczność - a więc zysk odnoszą także wszyscy inni, którzy o istnieniu tego defektu nawet nie wiedzieli.
To dobrze pokazuje, jak działa ekosystem otwartego oprogramowania: firma z ogromną skalą i odpowiednimi narzędziami wyłapuje rzadki problem, którego mniejsi użytkownicy nigdy by nie zauważyli, a naprawa staje się darmowym prezentem dla całej reszty.
Historia OpenAI jest więc mniej o jednym konkretnym błędzie, a bardziej o metodzie. Gdy awarii jest wystarczająco dużo, przestają być serią niezależnych wypadków, a stają się zbiorem danych - a dane, w przeciwieństwie do pojedynczego zrzutu pamięci, potrafią wskazać źródło problemu ukrywające się od niemal dwóch dekad.
Cały tydzień w AI, w jednym mailu
Wybrane premiery, narzędzia i analizy. Raz w tygodniu, prosto do skrzynki.
Zapisz się za darmo →
