Wyjaśnienie Braku Wielkoskalowych Badań w IT

Praktycy IT proszą o nie każdego dnia, a jednak nie istnieją – wielkoskalowe badania ryzyka i wydajności sprzętu oraz oprogramowania IT. Obejmują one szeroki wachlarz możliwości, lecz typowe przykłady to wskaźniki awarii różnych modeli serwerów, dysków twardych, systemów operacyjnych, typów macierzy RAID, komputerów stacjonarnych, laptopów i tak dalej. A mimo to, niezależnie od dużego popytu na takie dane, nie są one dostępne. Jak to możliwe.

Nie wszystkie przypadki są takie same, oczywiście, ale generalnie istnieją trzy naprawdę istotne czynniki, które wchodzą w grę i powstrzymują tego rodzaju dane przed trafieniem do branży. Są to: wysoki koszt przeprowadzenia badania, długi horyzont czasowy niezbędny dla badania oraz brak motywacji do tworzenia i/lub udostępniania tych danych innym firmom.

Koszt jest zdecydowanie największym czynnikiem. Gdyby można było przezwyciężyć koszt wielkoskalowych badań, dla wszystkich innych czynników można by znaleźć rozwiązania. Jednak niestety natura wielkoskalowego badania sprawia, że będzie ono kosztowne. Jako przykład możemy spojrzeć na wskaźniki niezawodności serwerów.

Aby określić wskaźniki awarii serwerów, potrzebujemy dużej liczby serwerów do zebrania tych danych. Może się to wydawać skrajnym przykładem, ale wskaźniki awarii serwerów są jedną z najczęściej poszukiwanych wartości w wielkoskalowych badaniach, więc przykład jest ważny. Potrzebowalibyśmy może kilkuset serwerów do bardzo małego badania, ale aby uzyskać statystycznie istotne dane, prawdopodobnie potrzebowalibyśmy tysięcy serwerów. Jeśli założymy, że jeden serwer kosztuje pięć tysięcy dolarów, co byłoby stosunkowo podstawowym serwerem, mówilibyśmy o łatwo dwudziestu pięciu milionach dolarów sprzętu! I to tylko tyle, by przeprowadzić nieco małe badanie (zaledwie pięć tysięcy serwerów) stosunkowo niedrogiego urządzenia. Gdybyśmy mówili o serwerach enterprise, koszt łatwo wzrósłby do trzydziestu czy nawet pięćdziesięciu tysięcy dolarów za serwer, doprowadzając łączny koszt nawet do ćwierć miliarda dolarów.

Oczywiście koszt ten dotyczy testowania jednej konfiguracji jednego modelu serwera. Aby badanie miało sens, potrzebowalibyśmy wielu różnych modeli serwerów. Być może kilku od każdego producenta, by porównać różne linie i funkcje. Być może wielu różnych producentów. Łatwo zobaczyć, jak szybko koszt badania staje się niemożliwie wysoki.

To jednak dopiero początek kosztów. Dobre badanie będzie wymagało starannie kontrolowanych środowisk na poziomie najlepszych centrów danych, by w jak największym stopniu odizolować problemy środowiskowe. Oznacza to wysoce niezawodne zasilanie, chłodzenie, przepływ powietrza, kontrolę wilgotności, wibracji i pyłu. Dobre obiekty tego rodzaju są bardzo drogie i dlatego wiele firm nie płaci za nie nawet dla cennych workloadów produkcyjnych. W dużym badaniu ten koszt mógłby łatwo przekroczyć koszt samego sprzętu przez cały czas trwania badania.

Następnie oczywiście musimy zająć się potrzebami specjalnych czujników i testowania. Co dokładnie stanowi awarię? Nawet w systemach produkcyjnych często toczy się spór na ten temat. Czy awaria dysku twardego w macierzy to awaria, nawet jeśli sama macierz nie ulega awarii? Czy przewidywana awaria to awaria? Jeśli w badaniu chodzi o awarię napędu, jak uwzględnić komponenty ludzkie, takie jak wymiana napędu, która może nie być wykonywana w jednolity sposób? Istnieją sposoby na poradzenie sobie z tym, ale dodają one komplikacji i sprawiają, że badania odbiegają od danych z rzeczywistego świata, stając się danymi sztucznymi na potrzeby badania. Ustalenie wytycznych badania, które są przydatne i stosowalne dla użytkowników końcowych, jest znacznie trudniejsze, niż się wydaje.

I największy koszt to praca ludzka. Utrzymanie środowiska dla dużego badania będzie wymagało zasobów ludzkich, które mogą równać się kosztowi samego badania. Utrzymanie środowiska badania, prowadzenie samego badania, monitorowanie go i zbieranie danych wymaga dużej liczby osób. Łącznie koszty są generalnie po prostu niemożliwe do poniesienia.

Oczywiście moglibyśmy znacznie ograniczyć skalę testu, uruchamiając tylko kilka serwerów i tylko dwa lub trzy modele, ale wartość testu szybko spada i istnieje ryzyko uzyskania wyników, których nikt nie może użyć, podczas gdy nadal wydano dużą sumę pieniędzy.

Drugi nieprzezwyciężalny problem to czas. Większość rzeczy musi być testowana pod kątem wskaźników awarii w czasie, a ponieważ sprzęt IT jest zazwyczaj zaprojektowany do niezawodnej pracy przez dziesięciolecia, zbieranie danych o wskaźnikach awarii wymaga wielu lat. Wartości Mean Time to Failure (MTTF) są tylko częściowo wartościowe; Mean Time Between Failures (MTBF) oraz typy, tryby i statystyki awarii są bardzo ważne, aby badanie było użyteczne. Oznacza to, że aby badanie było naprawdę użyteczne, musi trwać przez bardzo długi czas, generując coraz większe koszty.

Ale to nie jest największy problem. Znacznie większą kwestią jest to, że zanim badanie będzie miało wystarczająco dużo czasu, by wygenerować użyteczne liczby awarii, nawet gdyby te liczby pojawiały się “na żywo” w miarę ich powstawania, byłoby już za późno. Testowany sprzęt byłby już starzejący się i zbliżałby się do czasu wymiany na rynku produkcyjnym, zanim badanie zaczęłoby produkowaą naprawdę użyteczne wczesne wyniki. Często sprzęt produkcyjny jest kupowany tylko na trzy do pięciu lat łącznego okresu użytkowania. Uzyskanie wyników nawet rok po tym czasie miałoby niewielką wartość. A nowe produkty mogą zastąpić te badane nawet szybciej niż produkty starzeją się naturalnie, sprawiając, że badanie jest wartościowe jedynie z perspektywy historycznej, bez żadnego zastosowania w określaniu wyborów w roli decyzji produkcyjnych – wyniki byłyby zbyt stare, żeby być użyteczne w momencie ich dostępności.

Ostatnim ważnym czynnikiem jest brak motywacji do udostępniania istniejących danych tym, którzy ich potrzebują. Chociaż istnieje niewiele źródeł danych, kilka istnieje, ale prawie wszystkie są niekompletne i służą dużym dostawcom do pomiaru jakości ich własnego sprzętu, wskaźników awarii i tym podobnych. Rzadko są przeprowadzane w kontrolowanych środowiskach i często obejmują dane zebrane w terenie. W wielu przypadkach dane te mogą być nawet prywatne dla klientów i niemożliwe do udostępnienia z prawnego punktu widzenia niezależnie od wszystkiego.

Jednak dostawcy, którzy zbierają dane, nie robią tego w równomierny, monitorowany sposób, więc udostępnienie tych danych mogłoby być dla nich bardzo szkodliwe, ponieważ nie ma gwarancji, że równoważne dane od ich konkurentów byłyby dostępne. Niekontrolowane statystyki tego rodzaju nie przyniosłyby żadnych prawdziwych korzyści rynkowi ani dostawcom, którzy je posiadają, więc dostawcy mają silną motywację, by ściśle chronić takie dane.

Rzadkim wyjątkiem są niektóre badania sprzętowe od dostawców takich jak Google i BackBlaze, którzy posiadają duże liczby konsumenckich dysków twardych w stosunkowo kontrolowanych środowiskach i zbierają wskaźniki awarii dla własnych celów, ale mają niewielkie lub żadne ryzyko ze strony konkurentów wykorzystujących te dane, a jednocześnie mają wartość PR w ich publikowaniu i dlatego od czasu do czasu publikują badanie niezawodności sprzętu w ograniczonym zakresie. Te badania są chciwie pochłaniane przez branżę, mimo że zazwyczaj zawierają stosunkowo niewielką wartość, ponieważ ich dane są stare i zbierane w nieznanych warunkach i progach, często nie zawierają statystycznie znaczących danych do porównania produktów i w najlepszym razie zawierają ogólne trendy statystyczne całej branży, które są w pewnym stopniu przydatne do prognozowania przyszłych ścieżek niezawodności.

Większość innych firm wystarczająco dużych, by mieć wewnętrzne statystyki niezawodności, posiada je dla wąskiego zakresu sprzętu i uważa te informacje za zastrzeżone, potencjalne ryzyko w przypadku ujawnienia (ujawniłyby ważne szczegóły implementacji architektonicznych) i przewagę konkurencyjną. Z tych powodów nie są one udostępniane.

Miałem szczęście być zaangażowanym i przeprowadzić wielkoskalowy test niezawodności pamięci masowej, który był przeprowadzony nieco nieformalnie, ale niezwykle wartościowo, na ponad dziesięciu tysiącach serwerów enterprise przez osiem lat, co dało osiemdziesiąt tysięcy server-lat badania – rzadka okazja. Ale to, co ustalono w tym badaniu, wykazało, że chociaż było ono niezwykle wartościowe, to przede wszystkim pokazało, że na tak dużym zbiorze nadal nie byliśmy w stanie zaobserwować ani jednej awarii! Brak awarii był sam w sobie bardzo wartościowy. Ale nie byliśmy w stanie wygenerować żadnej standardowej statystyki jak Mean Time to Failure. Aby uzyskać dane, których ludzie oczekują, wiemy, że potrzebowalibyśmy setek tysięcy server-lat, co najmniej, żeby uzyskać jakąkolwiek statystyczną istotność, ale nie możemy rzetelnie stwierdzić, że nawet to byłoby wystarczające. Być może konieczne byłyby miliony server-lat. Nie ma sposobu, żeby naprawdę to wiedzieć.

Gdzie nas to pozostawia, to że wielkoskalowe badania w IT po prostu nie istnieją i prawdopodobnie nigdy nie będą istnieć. Kiedy się pojawią, będą izolowane i niemal na pewno ograniczone przez wymogi rzeczywistości. Nie ma możliwości monetyzacji badań na poziomie niezbędnym do tego, by były użyteczne, głównie dlatego, że wskaźniki awarii sprzętu enterprise są tak niskie, a sprzęt tak drogi, że firmy zewnętrzne nigdy nie pokryją kosztów prowadzenia tych badań. Jako branża musimy przyjąć, że tego rodzaju dane nie istnieją i aktywnie szukać alternatyw dla dostępu do takich danych. Zaskakujące jest, że tak wiele osób w branży oczekuje, że tego rodzaju dane będą dostępne, gdy historycznie nigdy nie były.

Nasze jedyne realne opcje, biorąc pod uwagę tę lukę, to zbieranie dostępnych dowodów anegdotycznych (bardzo niebezpieczna rzecz do zrobienia, wymagająca starannego rozważenia kontekstu) oraz stosowanie logiki do oceny podejść i technik niezawodności. Jest to szeroka sytuacja, w której obserwacja z konieczności nas zawodzi i jedynie logika oraz intuicja mogą wypełnić wynikającą z niej lukę w wiedzy.