Glitchy Updates weisen auf ein tieferes Problem hin


Windows 10 bei der Präsentation in Tokio im Juli 2015

Offensichtlich war das Windows-Update vom 10. Oktober 2018 nicht das erfolgreichste. Nachrichten über den Verlust von Dateien auf Computern wurden schnell angezeigt, und Microsoft stellte die Verteilung des Updates ein. Seitdem wurde der Fehler behoben , jetzt wird ein neues Update vor seiner erneuten Veröffentlichung getestet.

Dies ist nicht das erste Windows-Update, bei dem Probleme aufgetreten sind. In früheren Updates haben wir beispielsweise erhebliche Hardware-Inkompatibilitäten festgestellt. Es ist jedoch deutlich schlimmer geworden. Die meisten von uns kennen sich mit Backups aus, aber in Wirklichkeit haben viele Daten, insbesondere auf Heimcomputern, kein Backup und ihr Verschwinden ist sehr unangenehm.

Windows als Dienst

In Windows 10 war geplant, den Entwicklungsprozess radikal zu ändern. Microsoft wollte besser auf die Bedürfnisse der Kunden und des Marktes reagieren - und häufiger neue Funktionen veröffentlichen. Windows 10 wurde als "neueste" Version von Windows vorgestellt. Ebenso werden alle neuen Entwicklungen zu Updates von Windows 10, die mehrmals im Jahr über das Update-System bereitgestellt werden. Dieses neue Entwicklungsmodell heißt Windows as a Service. Und nach anfänglichem Durcheinander entschied sich Microsoft für zwei funktionale Updates pro Jahr : im April und im Oktober.

Diese Bemühungen waren erfolgreich. Microsoft veröffentlicht nützliche neue Funktionen für das neue Modell, ohne dass Benutzer drei Jahre warten müssen, um die Hauptversion zu aktualisieren. Beispielsweise wurde eine praktische Funktion zum unsichtbaren Starten von Edge in einer virtuellen Maschine veröffentlicht , die einen besseren Schutz vor schädlichen Websites bietet. Das Windows-Subsystem für Linux (WSL), mit dem Sie Linux-Programme nativ auf einem Windows-System ausführen können, ist zu einem Tool für Entwickler und Administratoren geworden. Die Vorteile für normale Benutzer sind etwas schwieriger zu bemerken, aber Sie können die mit SteamVR kompatiblen VR-Funktionen, die verbesserte Spieleleistung und ein dunkles Thema erwähnen. Obwohl die Verbesserungen nicht so bedeutend sind, ist das aktuelle Windows 10 im Allgemeinen sicherlich besser als das, das vor drei Jahren herauskam.


In den Tagen, in denen Windows nur alle drei Jahre aktualisiert wurde, war es schwer vorstellbar, dass WSL jemals ein nützliches Werkzeug werden würde.

All dies ist gut und einige Dinge wären ohne die Einführung des Windows as a Service-Modells kaum (mindestens so erfolgreich) möglich gewesen. Die WSL-Entwicklung basierte beispielsweise auf Benutzerfeedback. Die Benutzer sprachen über festgestellte Inkompatibilitäten und halfen bei der Priorisierung der Entwicklung neuer Funktionen. Ich glaube nicht, dass die WSL ohne stetigen Update-Fortschritt alle sechs Monate einen solchen Entwicklungsimpuls erhalten würde - niemand würde drei Jahre warten wollen, um eine geringfügige Korrektur zu sehen. Zum Beispiel, damit ein wichtiges Paket für sie richtig funktioniert. Regelmäßige Updates belohnen Benutzer für Fehlermeldungen, da jeder wirklich sieht, dass Fehler rechtzeitig behoben werden.

Das Problem mit dem Windows as a Service-Modell ist die Qualität. Frühere Probleme mit diesem Modell und Sicherheitsupdates haben bereits das Vertrauen in die Windows 10-Update-Richtlinie untergraben. Erfahrene Benutzer waren der Meinung, dass die Qualität der monatlichen Sicherheitsupdates in Windows 10 abgenommen hatte, und die Installation von halbjährlichen Feature-Updates, sobald sie veröffentlicht wurden, war verrückt . Diese Beschwerden haben auch eine lange Geschichte. Schlechte Updates gaben kurz nach der Veröffentlichung von Windows 10 Anlass zur Sorge .

Das letzte Problem beim Löschen von Dateien führte dazu, dass Experten zu viele Feature-Updates pro Jahr durchführen . Redmond sollte die Anzahl auf eins reduzieren, und Microsoft sollte die Entwicklung neuer Funktionen einstellen und nur Fehler beheben . Einige befürchten, dass das Unternehmen einem ernsthaften Vertrauensverlust in Updates gefährlich nahe kommt, und für einige Windows-Benutzer ist dieses Vertrauen bereits verloren.

Dies sind nicht die ersten Aufrufe an Microsoft, um Feature-Updates zu verlangsamen. Es gab Befürchtungen, dass all dies sowohl für IT-Abteilungen als auch für normale Benutzer schwer zu verdauen ist. Angesichts der offensichtlichen Probleme des neuesten Updates werden diese Aufrufe jedoch besonders relevant.

Es geht nicht um die Häufigkeit, sondern darum, wie Updates vorbereitet werden

Aber diejenigen, die auf einem Update pro Jahr statt auf zwei bestehen, verpassen den Punkt. Das Problem ist nicht die Ausgangsfrequenz. Das Problem liegt im Microsoft-Entwicklungsprozess.

Warum ist das Problem nicht in Begriffen? Wir können uns die Update-Zeitpläne anderer Betriebssysteme ansehen.

Einerseits werden macOS, iOS und Android weniger häufig aktualisiert, sodass Sie möglicherweise den Eindruck haben, dass Microsoft zu eifrig ist. Auf der anderen Seite gibt es Präzedenzfälle für erfolgreiche Updates mit einer solchen Häufigkeit: Für Ubuntu gibt es zwei Releases pro Jahr, und ChromeOS von Google erhält wie sein Chrome-Browser alle sechs Wochen Updates. Wenn Sie über das Betriebssystem hinausgehen, führt das Microsoft Office Insider-Programm einen monatlichen Kanal aus, in dem jeden Monat neue Funktionen für Office-Benutzer veröffentlicht werden. Die Entwickler erledigen die Aufgabe, ohne zu viele Beschwerden zu verursachen, und stellen gleichzeitig einen stetigen Strom neuer Funktionen und Korrekturen bereit. Das Visual Studio-Team veröffentlicht häufig Updates für seine Entwicklungsumgebung und interaktive Dienste. Offensichtlich hat Microsoft Teams, die sich gut an die Realität angepasst haben und deren Anwendungen regelmäßig aktualisiert werden.

Wir werden über den Bereich lokaler Software hinausgehen und uns mit Netzwerk- und Cloud-Diensten befassen. Dort führen Microsoft und andere Unternehmen zunehmend die kontinuierliche Lieferung ein . Jedes Update im System wird automatisch auf Produktionsservern bereitgestellt, nachdem eine ausreichende Anzahl automatischer Tests bestanden wurde.

Natürlich kann keines dieser Projekte in seiner Komplexität mit Windows verglichen werden. Ubuntu verfügt möglicherweise über eine breitere Palette von Paketen, aber in jedem Fall werden viele davon unabhängig voneinander entwickelt. Die Tatsache bleibt: Der Umfang von Windows ist ungewöhnlich groß - und die Komponenten sind beispiellos in eine einzige Codebasis integriert. An einigen Stellen ist Windows-Code außergewöhnlich alt.

Natürlich erschweren diese Faktoren die Entwicklung von Windows, aber ist es wirklich unmöglich, zwei Updates pro Jahr zu überwältigen? Dies ist überhaupt nicht der Punkt. Sie brauchen nur den richtigen Entwicklungsprozess.


Windows 10 zum Zeitpunkt der Veröffentlichung im Jahr 2015 (Wo sind alle meine Symbole und das Startmenü?)

Ein Prozess, der in der Geschichte verwurzelt ist

Microsoft gibt keine spezifischen Details des Windows 10-Entwicklungsprozesses bekannt, aber es gibt beobachtbare Merkmale dieses Prozesses (wie neue Funktionen an Insider gesendet werden, Arten von Fehlern in Insider-Builds) und es gibt einige Informationen aus dem Unternehmen. Alle diese indirekten Tatsachen weisen auf die Minderwertigkeit des Entwicklungsprozesses hin. Er behielt einige Ähnlichkeiten mit dem Entwicklungsprozess bei, den das Unternehmen während der dreijährigen Versionen von Windows verwendete. Das Timing ist gesunken, aber der grundlegende Ansatz hat sich nicht geändert.



In den alten Tagen, als zwischen den großen Releases zwei bis drei Jahre vergingen, kam Microsoft zu einem Prozess, der in mehrere Phasen unterteilt war:

1. Design und Planung;
2. Komponentenentwicklung;
3. Integration;
4. Stabilisierung.

Etwa 4-6 Monate Planung und Design, 6-8 Wochen intensive Codierung und dann 4 Monate Integration (jede Funktion wird normalerweise in einem eigenen Zweig entwickelt, sodass alle zusammengebaut und kombiniert werden müssen) und Stabilisierung (Testen und Korrigieren von Fehlern). Während der Produktentwicklung wird dieser Zyklus zwei- oder dreimal wiederholt. Windows wird drei Iterationen haben, von denen die erste ein Prototyp ist und die nächsten zwei real sind. Die Dauer der Phasen kann variieren, aber die Grundstruktur ist im Unternehmen weit verbreitet.

Einige Dinge sind aus diesem Prozess ersichtlich. Das vielleicht Auffälligste ist, dass überraschend wenig Zeit direkt für die Entwicklung neuen Codes aufgewendet wird: Für die Veröffentlichung von Windows sind dies zwei Intervalle von 6 bis 8 Wochen während des gesamten Dreijahreszeitraums. Zwischen der Planungs- / Entwurfsphase und dem tatsächlich funktionierenden Produkt vergeht viel Zeit. Dies ist der Hauptfaktor, warum dieser Prozess nicht als „flexible Entwicklung“ bezeichnet werden kann: Neue Funktionen sind fest im Endprodukt verankert, sodass es schwierig ist, sie als Reaktion auf Rückmeldungen zu ändern.

Die Trennung von Entwicklungs- und Fehlerkorrekturen ist ebenfalls ein Problem: In den Phasen der Entwicklung und Integration ist die Zuverlässigkeit und Stabilität von Software sehr lahm. Integrierte Funktionen werden nicht grundlegend getestet (da das Testen später erfolgt) und werden nie miteinander verwendet (da sie alle vor der Integrationsphase separat in ihren eigenen Zweigen entwickelt wurden). Das Software-Durcheinander wird dann durch Testen, Fehlerberichterstattung und Fehlerkorrektur während der langen Stabilisierungsphase auf ein akzeptables Niveau gebracht. In diesem Prozess müssen Sie die Zuverlässigkeit des Produkts wiederholt verbessern.


Nadella führt die Welt 2015 in Windows 10 ein

Die neue Welt ist nicht so neu

In der neuen Welt sehen wir, dass ein vollständiger Unternehmenszyklus sieben oder acht Monate dauert. Obwohl zwischen den Veröffentlichungen nur sechs Monate liegen, findet der Beginn des nächsten Zyklus statt, bevor der vorherige abgeschlossen ist - für Insider ist dies aus der Eröffnung der Skip Ahead-Gruppe ersichtlich.

In der Regel beginnt jedes Update mit einer eher ruhigen Phase mit mehreren sichtbaren Änderungen und einige Monate mit der Einführung großer Änderungen - und einer großen Anzahl von Fehlern. Ungefähr einen Monat vor dem Update sehen wir eine starke Verlangsamung der Anzahl der vorgenommenen Änderungen und einen starken Schwerpunkt auf Fehlerkorrekturen und nicht auf neuen Funktionen.

Wie die Mitarbeiter von Microsoft selbst beschreiben, umfassen die letzten Monate der Entwicklung die "Tell" -Phase und dann einen Monat der "Ask Permission" -Phase. In der Phase "Benachrichtigen" wird die Windows-Verwaltung über Änderungen informiert, die mit der Richtlinie vorgenommen wurden, diese Änderungen standardmäßig zu akzeptieren. In der Phase „Bitte um Erlaubnis“ sind nur wirklich wichtige Änderungen zulässig, in der Regel nur wenige Änderungen pro Tag.

Beispielsweise wurde der erste Build des Oktober-Updates (Codename RS5) am 14. Februar für Insider veröffentlicht, und der stabile Build des April-Updates (RS4) erfolgte zwei Monate später am 16. April. RS5 erhielt bis zum 7. März keine wesentlichen neuen Funktionen. Im Mai, Juni und Juli wurden viele Funktionen hinzugefügt, und im August und September wurden nur geringfügige Änderungen vorgenommen. Einige kleine Features wurden sogar im August entfernt, da es schwierig war, sich auf ihre Veröffentlichung im Oktober vorzubereiten.

Natürlich hat sich der Prozess etwas geändert. Beispielsweise werden über viele Monate hinweg neue Funktionen in Pre-Builds angezeigt. Dies weist darauf hin, dass die Integration neuer Funktionen viel früher zu erfolgen scheint - wenn Funktionen entwickelt werden und nicht am Ende in einem großen Zusammenführungspaket.

Qualitätsverlust

Es gibt jedoch wesentliche Ähnlichkeiten. Am wichtigsten ist, dass ein absichtlich fehlerhafter Code in eine gemeinsame Datenbank integriert wird und die Test- und Stabilisierungsphase zur Lösung von Problemen verwendet wird. Dieser Moment wird sogar ausdrücklich erkannt: Microsoft kündigt eine neue vorläufige Baugruppe an und warnt: „Wie üblich zu Beginn des Entwicklungszyklus können Baugruppen Fehler enthalten, die schmerzhaft sein können. Wenn dies zu Unannehmlichkeiten führt, können Sie in einen langsamen Aktualisierungszyklus (langsamer Klingelton) wechseln. Dort werden die Baugruppen noch von höherer Qualität sein. “

Wir sehen dies in der Praxis in RS5. Im Oktober letzten Jahres wurde mit dem Update eine neue Funktion für OneDrive eingeführt: Platzhalter, mit denen Dateien in der Cloud angezeigt werden, die nicht lokal heruntergeladen wurden. Wenn eine Anwendung versucht, eine Datei zu öffnen, extrahiert OneDrive die Datei transparent aus dem Cloud-Speicher und speichert sie lokal. Die Anwendung weiß nicht einmal, dass auf die Datei ursprünglich nicht lokal zugegriffen werden konnte. Der RS5-Build hat die Funktion implementiert, replizierte Cloud-Dateien aus dem lokalen Speicher zu bereinigen, wenn der Speicherplatz knapp wird.

Dies ist eine wirklich intelligente, nützliche Funktion, die die Integration in den Cloud-Speicher verbessert. Dies ist ein neuer Code. Es gibt einen Kerneltreiber, der eine Verknüpfung zwischen dem Cloud-Synchronisierungscode (zum Hochladen von Dateien und Herunterladen von Änderungen) und Symbolen im Dateisystem bereitstellt. Es gibt auch eine API (anscheinend können Dritte diese Funktion auch für ihre Synchronisierungsdienste verwenden).


Windows-Pre-Builds verwenden einen grünen "Todesbildschirm" anstelle von Blau, sodass sie leicht zu unterscheiden sind

Es ist davon auszugehen, dass Microsoft eine Reihe von Tests für diesen neuen Code durchführt: Erstellen einer Datei, Überprüfen der Synchronisierung, Löschen einer lokalen Kopie durch Speichern des Symbols, Öffnen des Symbols beim tatsächlichen Laden der Datei, vollständiges Löschen der Datei usw. Es gibt verschiedene grundlegende Vorgänge zum Bearbeiten von Dateien und Verzeichnissen. In jedem flexiblen Entwicklungsprozess werden Tests durchgeführt, um zu überprüfen, ob alle Vorgänge wie erwartet funktionieren, und die API macht das, was sie tun sollte.

Darüber hinaus war davon auszugehen, dass jede Codeänderung, die die Tests unterbricht, abgelehnt wird und nicht integriert werden darf. Der Code muss repariert werden, er muss seine Tests bestehen, bevor er jemals in den Hauptzweig von Windows gelangt, und noch mehr, er geht an Betatester.

Trotzdem gab es in vielen vorläufigen Builds einen Fehler: Das System legte beim Löschen eines mit OneDrive synchronisierten Verzeichnisses auf. Dieser Fehler wurde nicht nur in Windows-Code integriert, sondern auch für Endbenutzer freigegeben.

Testen Sie die Software vor der Veröffentlichung, nicht danach

Dies legt einige der Grundprinzipien der Windows-Entwicklung nahe. Entweder gibt es überhaupt keine Tests für diesen Code (mir wurde gesagt, dass es erlaubt ist, den Code ohne Tests zu integrieren, obwohl ich hoffe, dass dies nicht die Norm ist), oder Testfehler werden als akzeptable, nicht blockierende Probleme angesehen, und Entwickler dürfen Code integrieren, der offensichtlich nicht ist funktioniert richtig. Draußen können wir nicht genau sagen, was genau passiert - vielleicht sogar eine Kombination beider Ansätze -, aber keiner von ihnen kann als gut bezeichnet werden.

Für ältere Teile von Windows kann dies als entschuldbarer angesehen werden - schließlich wurden sie vor der Ära des automatisierten Testens entwickelt, und es gibt möglicherweise wirklich keine Tests. OneDrive-Badges sind jedoch kein alter Bestandteil von Windows, sondern eine völlig neue Funktion. Es gibt keinen guten Grund, warum es keine soliden Tests zum Testen der Grundfunktionalität für den neuen Code gibt. Und ein bekannter fehlerhafter Code sollte definitiv nicht in die Codebasis aufgenommen werden, bis er behoben ist, ganz zu schweigen davon, dass er an Tester gesendet wurde.

Infolgedessen folgt die Entwicklung von Windows 10 immer noch den alten Prinzipien. Neue Funktionen werden mit der Verschlechterung der Stabilität und Zuverlässigkeit in die Datenbank aufgenommen. Es wird davon ausgegangen, dass die Codebasis in der Test- und Stabilisierungsphase auf ein akzeptables Niveau gebracht wird.

Unzureichendes automatisiertes Testen und / oder Ignorieren von Testfehlern bedeutet wiederum, dass Windows-Entwickler nicht sicher sein können, dass Änderungen und Korrekturen keine Welligkeitseffekte verursachen. Hierher kam die Entwicklungsphase „Bitte um Erlaubnis“: Nach Abschluss des Updates muss die Anzahl der Änderungen minimiert werden, da Microsoft nicht sicher ist, ob Umfang und Auswirkungen jeder Änderung isoliert sind. Dieses Vertrauen kommt nur mit einer massiven Infrastruktur disziplinierter Tests zustande: Sie wissen, dass Änderungen sicher sind, da alle Tests erfolgreich bestanden wurden. Unabhängig davon, welche Art von Tests das Unternehmen für Windows durchführt, reicht es eindeutig nicht aus, um ein solches Vertrauen zu gewinnen.

In anderer Hinsicht tut Microsoft jedoch so, als ob es diese Gewissheit hätte. Das Unternehmen hat viele Tests; Mir wurde gesagt, dass ein vollständiger Testzyklus für Windows viele Wochen dauert. Dieser vollständige Zyklus wird wirklich ausgeführt, nur nicht bei den Baugruppen, die tatsächlich in Produktion gehen. Ein Beispiel ist das Update vom Oktober 2018: Der Code wurde am 15. September zusammengestellt, und am 2. Oktober wurde die Versammlung veröffentlicht. Unabhängig davon, welcher RS5-Build einen vollständigen Testzyklus durchlaufen hat, ist dies nicht der, den wir tatsächlich erhalten haben, da ein vollständiger Testzyklus zu viel Zeit in Anspruch nimmt.

Dies ist eine kontroverse Position. Wenn nachfolgende Änderungen am Code mit einem hohen Maß an Sicherheit vorgenommen werden, dass nichts beschädigt wurde, können Sie den vollständigen Testzyklus für die vorherige Assembly starten. Wenn Microsoft jedoch ein so hohes Vertrauen hätte, dass diese Änderungen nichts bewirken würden, müsste es sie in der Phase „Bitte um Erlaubnis“ nicht so sehr erwürgen.


Windows 10 kann wirklich wie ein zuverlässiger Computer funktionieren

Wie man es richtig macht

Wir sehen einen signifikanten Unterschied zu echten agilen Projekten. Zum Beispiel ein Entwicklungsprozess, den Google für seinen Anzeigenversand-Server verwendet. Dies ist ein kritischer Teil der Infrastruktur für das Unternehmen, aber neue Entwickler im Unternehmen beschreiben, dass sie Änderungen vorgenommen haben, um einen kleinen Fehler zu schließen - und die Änderungen gingen im Laufe des Tages in die Produktion. Wenn ein Fix an das Repository gesendet wird, wird er automatisch neu erstellt und einer Reihe von Tests unterzogen. Der Betreuer dieses Codeabschnitts berücksichtigt dann die Änderung, akzeptiert sie und kombiniert sie mit der Hauptcodebasis, die erneut getestet und in der Produktion bereitgestellt wird.

Es ist natürlich etwas unfair, dies mit Windows zu vergleichen: Schließlich ist es für Cloud-Dienste viel einfacher, die Änderung zurückzusetzen, wenn ein Fehler erkannt wird. Das Ändern von Windows mit einem Bluescreen beim Systemstart ist viel schwieriger rückgängig zu machen und wiederherzustellen. — Google, , , . , .

. , . Microsoft — « , », , .


Chrome , , —

, Agile . , Google Chrome. - Chrome , . , Chrome , . dev- Chrome — , , . : Chrome , , Windows.

Google . , Chrome , . , . Google , . , Google Chrome , .

Windows

Microsoft — . , , . Windows 10 , Microsoft , .

. , Windows . Windows 7 , . Windows, Service Pack 1. ? — , Service Pack 1 .

, Windows , , . Überhaupt nicht. , , « Service Pack 1» . , Microsoft , — - . «» Service Pack 1.

, : Windows , . — , . , Service Pack .

— . . , Windows , , .

— . Microsoft , . 2014 . , , . Windows Insider — (). , - Windows.

, . , , . , Microsoft . . , , , , . , , .

Microsoft , . , , : .

. Insider — . , . . , Microsoft .

, , . . , : . .

Chrome Windows — . Windows , . , OneDrive, . .

, Windows — « », « , ». . Microsoft , . , — . . , . , .