Dlaczego Windows 10 ma takie problemy z jakością?

Po kilku miesiącach batalii, wreszcie udało się wydać końcową wersję wydania 1809 systemu Windows 10. Poważne, acz ograniczone w swoim oddziaływaniu problemy związane z utratą danych doprowadziły do szeregu opóźnień i sporej draki wizerunkowej. Co gorsza, to kolejna wpadka z opóźnieniami premiery wydania Windows 10: wersję 1803, czyli "kwietniową", udało się ukończyć dopiero w maju. Coraz więcej osób zadaje sobie pytanie - co takiego strasznego dzieje się w procesie wydawniczym Microsoftu, że aż tak trudno jest im ukończyć kolejne kompilacje? Za wzór do naśladowania przytacza się między innymi program Google Chrome, który niemal do perfekcji opanował politykę "ciągłej integracji". Dzięki temu nawet kanał Canary, w którym publikowany jest ostatni kompilujący się stan głównej gałęzi, dostarcza program wystarczająco stabilny do codziennej pracy. Wielu komentatorów bezlitośnie konstatuje, że Microsoft jest dziś najwyraźniej niezdolny do dostarczenia oprogramowania spełniającego elementarne normy jakości. Złośliwi dodają, że być może nigdy nie był... Zapominają oni jednak o pewnym przykładzie sprawnie działającej Ciągłej Integracji rodem z Microsoftu: pakiecie Office 365. Gdzie nawet kanał Insider Fast, aktualizujący się ciężkimi paczkami mniej więcej co tydzień, zapewnia bezpieczne i stabilne oprogramowanie. Więc jak to jest? Dlaczego Office może, a Windows nie?

Peter Bright sugerował niedawno, że jest to zaszłość po poprzedniej mentalności rozwoju oprogramowania w Redmond, która była oparta o przestarzały, ciężki i powolny proces. Dawne metody okazały się mało podatne na reformy i prędko okazało się, że samym hasłem "bądźmy agile!" nie da się magicznie z dnia na dzień tworzyć oprogramowania zgodnego z CI/CD, czyli mieć zawsze dostępną kompilację, która działa - nawet, jeżeli jest niekompletna. Będzie w owej hipotezie bezsprzecznie wiele prawdy, ale trudno oprzeć się wrażeniu, że poza powodami psychologicznymi, istnieje pewien dług technologiczny, którego obecność uniemożliwia prędkie przejście na nowe tory. Możliwe, że dług ten jest możliwy do zaobserwowania z perspektywy użytkownika.

Przychodzą do głowy dwie kwestie, jedna ogólna i druga szczegółowa. Po pierwsze - Windows jest po prostu za duży. Kod systemu jest gigantyczną plątaniną współzależnego kodu i nawet dzieląc pracę między teoretycznie niezależne zespoły, końcowy etap integracji i testów może się okazać horrorem. Nie wiadomo, ile czasu zajmuje przejście danej kompilacji Windows przez zbiór (niewątpliwie istniejących) testów automatycznych. Możliwe, że wiele dni. Oczywiście, na tak postawiony zarzut można odpowiedzieć, że to przecież przypadłość każdego dużego projektu informatycznego i Windows nie powinien mieć tutaj taryfy ulgowej. Ale to niekoniecznie prawda. Na rynku tak naprawdę nie ma drugiej takiej rzeczy, jak Windows: nie istnieje system ogólnego przeznaczenia (od serwerów po tablety z Biedronki) o takiej mnogości interfejsów programowania, bibliotek i komponentów. Z tego powodu o wiele trudniej jest kreślić analogie np. do Ubuntu, gdzie środowisko graficzne jest intensywnie rozwijane przez zespół zupełnie oddalony np. od fachowców zajmujących się jądrem. W Windows, nawet jeżeli takie WinRT jest budowane kompletnie niezależnie od aktualizacji menedżera pamięci albo nowych interfejsów COM, to prędzej czy później przychodzi etap integracji, który w przypadku dzisiejszej inkarnacji NT musi być prawdziwym koszmarem. Dlatego efekt skali, nieobcy wielu projektom informatycznym, jest szczególnie niekorzystny gdy mowa o Windowsach.

Ale jest też inny problem. Leży on bezpośrednio w cudzie techniki, jakim jest narzędzie serwisowania obrazów Windows, czyli nieszczęsnym komponencie DISM, znanym wielu administratorom. DISM i obrazy WIM zadebiutowały wraz z systemem Windows Vista i miały być rozwiązaniem problemów z integracją aktualizacji i sterowników podczas wdrażania. Jednocześnie zadbano o to, by tak stworzone narzędzie było jak najbardziej uniwersalne: DISM traktuje obraz płyty z systemem na tej samej zasadzie, jak żywy, zainstalowany system, spod którego pracuje. Ten pomysł z biegiem czasu okazuje się być w coraz większym stopniu jedynie skomplikowanym eksperymentem naukowym, nieprzynoszącym wymiernych korzyści. Wyabstrahowanie wyżej wymienionych funkcji do poziomu, na którym są identyczne, wygląda na łatwe i eleganckie jedynie na wierzchu. Pod spodem czai się mnóstwo skomplikowanej logiki, podatnej na błędy i zaskakująco powolnej. Są też inne problemy...

Na przykład modularyzacja. W roku 2007, na pewnej prezentacji w Microsofcie zaprezentowano "modularność" systemu Windows. Chcąc zadać kłam powszechnej opinii, że Vista jest otyła i monolityczna, przygotowano prototyp MinWin, czyli podstawowy rdzeń systemu Windows, jeszcze bardziej okrojony niż Server Core i działający na około czterdziestu megabajtach pamięci. Owa prezentacja na krótko obiegła świat i stała się źródłem wielu fałszywych przekonań dotyczących wnętrzności przygotowywanego wtedy Windows 7. Wygenerowała również zbiór plotek szczególnie szkodliwych, jak np. to, że MinWin, w połączeniu z modelem serwisowania Visty, pozwala na silną modularyzację systemu i złożenie własnego obrazu instalacyjnego z klocków. Każdy, kto próbował "ogolić" Windows 7 ze zbędnych komponentów wie, jak dalekie jest to od prawdy. Nawet dziś, w czasach skonteneryzowanych aplikacji APPX.

Jak Windows instaluje aktualizacje? Proces roboczy zaufanego instalatora komponentów (Trusted Installer Worker) wykorzystuje do swojego działania koncepcję paczek (cabinet packages). Każdy element systemu został zapakowany i nazwany w odpowiedni sposób, któremu towarzyszy numer wersji i architektura. Maksymalnie dużą liczbę komponentów oddzielono od ich tłumaczeń, które również umieszczono w oddzielnych paczkach. Instalatory aktualizacji i dostawcy komponentów, czyli pakiety MSU, składają się z wielu właśnie takich paczek, o długich nazwach kanonicznych. Paczki te mają ściśle odpowiadać tym obecnym w systemie. Trusted Installer rozwiązuje zależności między nimi, dba o deduplikację i rejestruje stan załatania każdej z nich tak, by możliwe było stworzenie jednoznacznego inwentarza zawartości. Dzięki niemu wiadomo konkretnie, które pakiety zostały zainstalowane. Nie aktualizacje - pakiety! W ten sposób możliwe jest stworzenie pakietów kumulatywnych, pobieranie tylko tych elementów systemu, które nie zostały zaktualizowane oraz nienadpisywanie elementów już dostarczonych przez inny element. Taki model zarządzania stanem systemu nazywa się CBS: Component-Based Servicing. CBS jest powszechnym źródłem mylnego przekonania o modularności Windows.

Traktowanie poszczególnych komponentów jako oddzielnych pakietów wcale bowiem nie oznacza, że są one od siebie niezależne. Usunięcie z obrazu instalacyjnego niektórych elementów (czyli doprowadzenie do stanu, w którym komponenty nie sumują się na znany, wydany system) doprowadza do sytuacji, w której niemożliwe jest zaaplikowanie aktualizacji. Bo choć nałożyłaby ona tylko łatki na elementy, które są niezaktualizowane, sam pakiet MSU "celuje" (targets) w system, czyli ściśle zdefiniowany zbiór komponentów! Innymi słowy, jeżeli w systemie jest aktualna wersja Internetowej Gry Warcaby, to pakiet z nią nie zostanie podbity. Ale jeżeli w systemie nie ma Warcabów, aplikowanie aktualizacji nie powiedzie się. Zatem komponentyzacja nie oznacza jeszcze niezależności.

Bardzo często podział na małe komponenty jest uznawany jako cel sam w sobie, w ramach którego „za darmo” przychodzą inne zalety, jak łatwość dostarczania i możliwość izolowanego przeprowadzania testów. Wydawać by się mogło, że jeżeli fragmenty systemu są skomponentyzowane, to znaczy że są od siebie niezależne. To jednak nieprawda. Podczas prac nad CBS próbowano rozwiązać mniej więcej te same problemy, które rozwiązywano wprowadzając pakiety MSI: chodziło o samo-zawarte transakcje o przewidywalnym przebiegu oraz wyeliminowanie ryzyka wzajemnego nadpisywania swoich zmian. W obu przypadkach w rezultacie stworzono gigantyczne i skomplikowane narzędzie, jednocześnie w ogóle nie rozwiązując problemów, które można tu załatwić „przy okazji”. Efektem jest narzędzie zupełnie niepodatne na rzeczywistą modularyzację. Rozwiązując jedynie część problemów, model CBS w dalszym ciągu wymusza dostarczanie systemu jako jeden, wielki obraz. To jednak samo w sobie nie jest problemem, wiele narzędzi jest dostarczanych w postaci „bezstanowych barył” (stateless blobs). Problemy zaczynają się, gdy okazuje się to być jedyną metodą dostarczania systemu. Zarówno do testów, jak i do klienta końcowego.

Obrazowanie WIM, jakże rewolucyjne w porównaniu z poprzednią metodą (stos skompresowanych plików kopiowanych jeden po drugim i zimna inicjalizacja ustawień i rejestru od zera), okazuje się być długiem technicznym, a nie rewolucją. Dyskusje na ten temat można dostrzec bardzo rzadko. Tymczasem poszlaki pojawiają się wszędzie wokół. Jaki był pierwszy krok zespołu Office, gdy zdecydowano się iść w stronę Ciągłego Dostarczania? Było nim przejście na Click-To-Run dostarczany w ramach metodyki App-V. Innymi słowy, przepakowano cały pakiet Office z wersji trzymanej w plikach MSI na moduły możliwe do serwisowania i strumieniowania w bardziej bezbolesny sposób. Odbyło się to bez sentymentów. Mimo, że to właśnie zespół Office był pierwszym, który rozpoczął korzystanie z pakietów MSI. Dzisiejszy Office 365 jest nie tylko strumieniowany, ale i w całości zapakowany w pakiet Windows Store, a zespół serwerowy pracuje nad następcą pakietów MSI, czyli pakietami MSIX, pozwalającymi na niezależne wdrażania, korzystając z wielu zalet architektury opartej o Sklep (wbrew pozorom takowe istnieją).

Dzięki zupełnie nowej metodzie dostarczania pakietu Office, komponenty aktualizują się pod spodem sesji i w sposób niezauważalny, w dodatku z dużą częstotliwością, o wiele częściej niż system Windows 10. A jeszcze ani razu nie wybuchła w związku z tym afera. To dlatego, że w przeciwieństwie do „Dziesiątki”, nie następują tu gigantyczne, zatrzymujące pracę aktualizacje podmieniające całe oprogramowanie. Co więcej, dzięki strumieniowaniu aplikacji, część pakietu Office może być nowa, a część nie. W przypadku Windows jest to o wiele trudniejsze.

Nie oznacza to jednak, że obrazowanie WIM stoi w miejscu. Przeciwnie – aktualizacje dla samego stosu serwisowego DISM wychodzą regularnie co kilka miesięcy, a w 2017 roku miała premierę technologia UUP, która w zamierzeniu ma dostarczać wyłącznie binaria różnicowe. Cóż jednak z tego, skoro docelowo „duża” aktualizacja to w dalszym ciągu operacja oparta o pełne obrazy, nakładane metodą podmiany podwozia podczas trwającego wiele minut przestoju. Jeżeli testy nowych komponentów przebiegają właśnie w taki sposób, gdzie komponentyzacja pomaga jedynie na śledzenie aktualizacji, ale cały system i tak musi być stawiany zawsze i od zera, to trudno się dziwić, że cierpi na tym jakość końcowego produktu.

Chciałoby się zatem zakrzyknąć, że niezbędnym jest przepakowanie Windows do nowego nośnika wdrażania, że należy odstawić sentymenty i pogodzić się z faktem, że ciężko wypracowana modularyzacja przebiegła źle i jej obecny stan już się nie skaluje. Ale to „genialne” rozwiązanie może być trudne do wcielenia w życie. Mimo, że Microsoft upiera się, że nie ma już w swoim procesie dostarczania systemu takiego stanu, jak „RTM”, a nowe wersje systemu są dostarczane w trybie ciągłym, to jest to nieprawda. W dalszym ciągu istnieją półroczne kamienie milowe (nowe kompilacje, w praktyce nowy system) oraz comiesięczne aktualizacje zbiorcze (pakiety MSU w formie mniejszej, niż Service Pack). Wynika to z potrzeby istnienia czegoś takiego, jak „baseline”, na którym mogą standaryzować na przykład twórcy sterowników. Jest to problem zupełnie obcy aplikacjom użytkowym, takim jak Office. Ale w przypadku Windows, do nowego modelu wdrażania musiałby się przekonać nie tylko Microsoft, ale i cały świat. Na przykład firma Qualcomm. Dziś tworząc sprzęt z procesorem ARM, wysyła ona pytanie do Microsoftu „w której wersji Windows zapewniona jest obsługa sprzętu X?” i otrzymuje konkretną odpowiedź typu „w kompilacji 17763”. Od tego momentu cała standaryzacja przebiega na kompilacji 17763. Wprowadzenie czegoś, co wyglądałoby na rolling release jest oczywiście możliwe. Ale wymagałoby pogodzenia interesów i opinii wielu grup o drastycznie odmiennych poglądach, również w samym Microsofcie. No i oczywiście, należałoby zacząć – jak na każdej grupie odwykowej – od przyznania się, że istnieje problem. Obecnie problemów szuka się wszędzie wokół.

Przychodzi do głowy również wiele rozwiązań hybrydowych. Na przykład aktualizowanie systemu odpowiednio rzadko i stosowanie aktualizacji jedynie dla wyższych warstw, w formie zbliżonej do pakietu Service Pack. Czyli coś mniejszego, niż Windows 8.1, ale większego, niż „comiesięczna aktualizacja kumulatywna”. Niestety, i do tego zadania dzisiejszy stos serwisowy się nie nadaje. Obraz systemu „łatany” aktualizacjami bezustannie rośnie. Docelowy WIM systemu Windows 7, po zintegrowaniu wszystkich dotychczas wydanych pakietów MSU po kolei, staje się około dwukrotnie cięższy, niż oryginał. Gdyby w ten sam sposób traktować na przykład trzyipółletnie wydanie system Windows 10 z lipca 2015, mielibyśmy dziś do czynienia z opasłym, kilkudziesięciogigabajtowym monstrum, którego aktualizowanie trwa wiele godzin. Skoro zatem i w tym przypadku model CBS jest niewystarczający, należy pilnie pomyśleć o następcy.

Jednak nawet najlepsze metody dostarczania nie zdadzą się na nic, jeżeli nie zmieni się „kultura pracy” i podejście do testów. Poleganie na programie Insider musi zostać ponownie ocenione, a narzędzia zgłaszania błędów zaktualizowane. Rzeczywista komponentyzacja i zredukowanie wzajemnych zależności (tightly-coupled entity) zwiększyłaby jakość testów integracyjnych. Wreszcie, przejrzystość w procedurze prywatności i niepchanie dodatków typu Cortana, Candy Crush Saga i reklamy w Poczcie sprawiłoby, że znacząco mniej osób decydowałoby się na uszkadzanie systemowych narzędzi telemetrycznych, dzięki którym możliwe jest identyfikowanie problemów z systemem operacyjnym. W takiej sytuacji, nowe wersje Windows mogłyby być wydawane nie co pół roku, ale co miesiąc i nikt by nawet nie zauważył. Microsoft jest bezsprzecznie zdolny do ciągłego dostarczania oprogramowania. Dzieje się to w przypadku usług chmurowych, środowiska Azure, pakietu Office, oprogramowania SCCM i kilku innych produktów, które zarabiają w Redmond solidne pieniądze. Windows 10 ze swoimi wpadkami jakościowymi jest w zasadzie odstającym wyjątkiem w palecie całkiem nieźle działającej oferty. Wbrew opinii wielu krytyków, często niemających o tym pojęcia.

Michael Fortin, CVP (wiceprezes) działu Windows, w swoim niedawnym artykule na temat metodyki zapewniania jakości w Dziesiątce, ponownie użył wyświechtanego hasła: [quote=lol]„podejście Windows Jako Usługa oznacza, że dzisiejsze wersje systemu publikujemy zupełnie inaczej, niż dawne wydania pudełkowe.”[/quote] Być może taka decyzja zapadła na szczeblu menedżerskim i odpowiadające jej szablony płacowe zostały przekazane do działów marketingu. Ale nie wpłynęło to fundamentalnie na model serwisowy, który działa wewnątrz systemu. W dalszym ciągu jest to odświeżone wcielenie pomysłu opracowanego na potrzeby systemu Windows Vista.

Na koniec warto także pamiętać o tym, że aktualizacje Windows są dostarczane na sporą większość kilkuset milionów urządzeń z owym systemem i mimo poważnych ograniczeń i zgrzytów, świat jeszcze nie zawalił się od Windows Update. Mimo, że od powstania tej usługi w 1998 roku nigdy nie miała ona dobrej prasy ani przychylnej opinii, nie da się dziś uniknąć ciągłego dostarczania i niekończących się aktualizacji oprogramowania. Na laptopie, telefonie, lodówce i zegarku. Pozostało jednak wciąż bardzo wiele pracy w kwestii zapewnienia odpowiedniej jakości.