Sichere Bereitstellungsmethoden

Manchmal bleibt eine Veröffentlichung hinter den Erwartungen zurück. Trotz der Anwendung von Best Practices und dem Bestehen aller Qualitätsprüfungen gibt es gelegentlich Probleme, die zu einer Produktionsbereitstellung führen und unvorhergesehene Probleme für die Benutzer verursachen. Um die Auswirkungen dieser Probleme zu minimieren und abzuschwächen, müssen DevOps-Teams eine progressive Exposure-Strategie anwenden, die die Exposition einer bestimmten Version mit ihrer bewährten Leistung in Einklang bringt. Wenn sich eine Version in der Produktion bewährt, wird sie schrittweise einem breiteren Publikum zugänglich gemacht, bis sie von allen genutzt wird. Teams können sichere Bereitstellungspraktiken anwenden, um die Qualität und die Geschwindigkeit von Veröffentlichungen in der Produktion zu maximieren.

Kontrolle der Exposition gegenüber Kunden

DevOps-Teams können verschiedene Praktiken anwenden, um die Freigabe von Updates für Kunden zu kontrollieren. In der Vergangenheit waren A/B-Tests eine beliebte Wahl für Teams, die herausfinden wollten, wie verschiedene Versionen eines Dienstes oder einer Benutzeroberfläche im Hinblick auf die Zielvorgaben abschneiden. A/B-Tests sind auch relativ einfach zu handhaben, da die Änderungen in der Regel geringfügig sind und oft nur verschiedene Versionen an der kundenorientierten Seite eines Dienstes verglichen werden.

Sicherer Einsatz durch Ringe

Mit dem Wachstum der Plattformen wachsen in der Regel auch der Umfang der Infrastruktur und die Anforderungen an das Publikum. Daher ist ein Bereitstellungsmodell gefragt, das die mit einer neuen Bereitstellung verbundenen Risiken mit den Vorteilen der versprochenen Aktualisierungen in Einklang bringt. Der Grundgedanke ist, dass eine bestimmte Version zunächst nur einer kleinen Gruppe von Benutzern mit der höchsten Risikotoleranz zugänglich gemacht werden sollte. Wenn die Version dann wie erwartet funktioniert, kann sie einer größeren Gruppe von Nutzern zugänglich gemacht werden. Wenn es keine Probleme gibt, kann der Prozess über breitere Benutzergruppen oder Rings fortgesetzt werden, bis alle die neue Version verwenden. Mit modernen Continuous-Delivery-Plattformen wie GitHub Actions und Azure Pipelines ist der Aufbau eines Bereitstellungsprozesses mit Ringen für DevOps-Teams jeder Größe möglich.

Featureflags

Bestimmte Funktionen müssen manchmal als Teil einer neuen Version bereitgestellt werden, ohne dass sie den Benutzern zunächst zugänglich gemacht werden. In diesen Fällen bietet feature flags eine Lösung, bei der die Funktionalität durch Konfigurationsänderungen je nach Umgebung, Ring oder einer anderen spezifischen Bereitstellung aktiviert werden kann.

Benutzer Opt-in

Ähnlich wie bei den Feature-Flags bietet das User Opt-in eine Möglichkeit, die Exposition zu begrenzen. Bei diesem Modell ist eine bestimmte Funktion in der Version aktiviert, aber nicht für einen Benutzer, es sei denn, er wünscht sie ausdrücklich. Die Entscheidung über die Risikotoleranz wird den Nutzern abgenommen, so dass sie entscheiden können, wie schnell sie bestimmte Aktualisierungen übernehmen wollen.

In der Regel werden mehrere Verfahren gleichzeitig angewandt. Ein Team kann zum Beispiel eine experimentelle Funktion für einen ganz bestimmten Anwendungsfall haben. Da es riskant ist, werden sie es im ersten Ring für interne Benutzer zum Testen bereitstellen. Doch auch wenn die Funktionen im Code enthalten sind, muss jemand das Feature-Flag für eine bestimmte Bereitstellung innerhalb des Rings setzen, damit die Funktion über die Benutzeroberfläche sichtbar wird. Selbst dann kann es sein, dass das Funktionskennzeichen dem Nutzer nur die Möglichkeit gibt, sich für die Nutzung der neuen Funktion zu entscheiden. Jeder, der sich nicht im Ring befindet, nicht an diesem Einsatz teilnimmt oder sich nicht angemeldet hat, wird die Funktion nicht nutzen können. Dies ist zwar ein ziemlich konstruiertes Beispiel, aber es soll die Flexibilität und Praktikabilität der progressiven Belichtung verdeutlichen.

Häufige Probleme, mit denen Teams am Anfang konfrontiert werden

Wenn Teams zu einer agileren DevOps-Praxis übergehen, können sie auf die gleichen Probleme stoßen wie andere, die von traditionellen monolithischen Lieferungen abgewichen sind. Teams, die daran gewöhnt sind, ihre Produkte alle paar Monate bereitzustellen, haben eine Denkweise, die auf Stabilisierung ausgerichtet ist. Sie gehen davon aus, dass jede Einführung eine wesentliche Veränderung ihres Dienstes mit sich bringt und dass es unvorhergesehene Probleme geben wird.

Die Nutzlasten sind zu groß

Dienste, die alle paar Monate bereitgestellt werden, sind in der Regel mit vielen Änderungen verbunden. Das erhöht die Wahrscheinlichkeit, dass es sofort Probleme gibt, und erschwert zudem die Fehlerbehebung, da es so viele neue Dinge gibt. Durch die Umstellung auf häufigere Lieferungen werden die Unterschiede bei der Bereitstellung kleiner, was gezieltere Tests und eine einfachere Fehlersuche ermöglicht.

Keine Dienstisolierung

Monolithische Systeme werden traditionell durch Aufstockung der Hardware skaliert, auf der sie eingesetzt werden. Wenn jedoch etwas mit der Instanz schief geht, führt dies zu Problemen für alle. Eine einfache Lösung besteht darin, mehrere Instanzen hinzuzufügen, um einen Lastausgleich zwischen den Benutzern zu erreichen. Dies kann jedoch erhebliche architektonische Überlegungen erfordern, da viele Altsysteme nicht für die Verwendung mehrerer Instanzen ausgelegt sind. Außerdem müssen möglicherweise erhebliche doppelte Ressourcen für Funktionen bereitgestellt werden, die an anderer Stelle besser konsolidiert werden könnten.

Wenn neue Funktionen hinzugefügt werden, müssen Sie prüfen, ob eine Microservices-Architektur dank einer besseren Service-Isolierung den Betrieb und die Skalierung unterstützen kann.

Manuelle Schritte führen zu Fehlern

Wenn ein Team nur ein paar Mal im Jahr ausliefert, lohnt sich die Investition in die Automatisierung der Auslieferung möglicherweise nicht. Infolgedessen werden viele Verteilungsprozesse manuell verwaltet. Dies erfordert einen erheblichen Zeit- und Arbeitsaufwand und ist anfällig für menschliche Fehler. Die Automatisierung der häufigsten Build- und Deployment-Aufgaben kann viel dazu beitragen, Zeitverluste und unvorhergesehene Fehler zu vermeiden.

Teams können auch infrastructure as code nutzen, um eine bessere Kontrolle über Bereitstellungsumgebungen zu haben. Dadurch entfällt die Notwendigkeit, das Betriebsteam zu bitten, manuelle Änderungen vorzunehmen, wenn neue Funktionen oder Abhängigkeiten in verschiedenen Bereitstellungsumgebungen eingeführt werden.

Nur Ops können Einsätze durchführen

In einigen Unternehmen gibt es Richtlinien, die vorschreiben, dass alle Bereitstellungen von den Betriebsmitarbeitern initiiert und verwaltet werden müssen. Auch wenn es in der Vergangenheit gute Gründe dafür gab, ist es für einen agilen DevOps-Prozess von großem Vorteil, wenn das Entwicklungsteam Bereitstellungen initiieren und kontrollieren kann. Moderne Continuous-Delivery-Plattformen bieten eine granulare Kontrolle darüber, wer welche Bereitstellungen initiieren kann und wer auf Statusprotokolle und andere Diagnoseinformationen zugreifen kann, um sicherzustellen, dass die richtigen Personen so schnell wie möglich die richtigen Informationen erhalten.

Fehlerhafte Implementierungen werden fortgesetzt und können nicht rückgängig gemacht werden

Manchmal geht ein Einsatz schief und die Teams müssen sich darum kümmern. Wenn die Prozesse jedoch manuell ablaufen und der Zugriff auf Informationen langsam und begrenzt ist, kann es schwierig sein, zu einer früheren funktionierenden Implementierung zurückzukehren. Glücklicherweise gibt es verschiedene Tools und Praktiken zur Minderung des Risikos fehlgeschlagener Implementierungen.

Kernprinzipien

Teams, die sichere Bereitstellungspraktiken einführen wollen, müssen einige Grundprinzipien festlegen, um ihre Bemühungen zu untermauern.

Seien Sie konsequent

In Entwicklungs- und Testumgebungen müssen dieselben Tools verwendet werden, die auch in der Produktion eingesetzt werden. Wenn es Probleme gibt, wie z. B. solche, die häufig durch neue Versionen von Abhängigkeiten oder Werkzeugen entstehen, müssen sie erkannt werden, bevor der Code für die Produktion freigegeben wird.

Sorge um Qualitätssignale

Zu viele Teams tappen in die übliche Falle, sich nicht wirklich um Qualitätssignale zu kümmern. Mit der Zeit stellen sie vielleicht fest, dass sie Tests schreiben oder Qualitätsaufgaben übernehmen, nur um eine gelbe Warnung in eine grüne Genehmigung zu verwandeln. Qualitätssignale sind sehr wichtig, da sie den Puls eines Projekts darstellen. Die Qualitätssignale, die zur Genehmigung von Bereitstellungen herangezogen werden, müssen tagtäglich nachverfolgt werden.

Einsätze müssen keine Ausfallzeiten erfordern

Es ist zwar nicht entscheidend, dass jeder Dienst immer verfügbar ist, aber die Teams müssen ihre DevOps-Bereitstellungs- und Betriebsphasen mit der Einstellung angehen, dass sie neue Versionen bereitstellen können und müssen, ohne sie für eine gewisse Zeit außer Betrieb nehmen zu müssen. Die moderne Infrastruktur und die Pipeline-Tools sind inzwischen so weit fortgeschritten, dass praktisch jedes Team eine Betriebszeit von 100 % erreichen kann.

Die Einsätze müssen während der Arbeitszeit erfolgen

Wenn ein Team mit der Einstellung arbeitet, dass Bereitstellungen keine Ausfallzeiten erfordern, dann ist es eigentlich egal, wann eine Bereitstellung erfolgt. Außerdem ist es vorteilhaft, die Bereitstellung während der Arbeitszeit zu forcieren, insbesondere am frühen Morgen und am Anfang der Woche. Wenn etwas schief geht, sollte es früh genug aufgespürt werden, um den Explosionsradius zu kontrollieren. Außerdem sind alle Beteiligten bereits bei der Arbeit und konzentrieren sich auf die Behebung von Problemen.

Ringbasierte Bereitstellung

Teams mit ausgereiften DevOps-Veröffentlichungspraktiken sind in der Lage, die ringbasierte Bereitstellung zu übernehmen. Bei diesem Modell werden neue Funktionen zuerst bei Kunden eingeführt, die bereit sind, das größte Risiko einzugehen. Wenn sich der Einsatz bewährt hat, wird der Kreis der Nutzer erweitert, bis er von allen genutzt wird.

Ein Beispiel für ein Ringmodell

Ein typisches Ring-Implementierungsmodell ist darauf ausgelegt, durch eine sorgfältige Segmentierung von Benutzern und Infrastruktur Probleme so früh wie möglich zu erkennen. Das folgende Beispiel zeigt, wie Ringe von einem großen Team bei Microsoft verwendet werden.

Ring	Zweck	Benutzer	Rechenzentrum
0	Findet die meisten Fehler, die sich auf die Benutzer auswirken und die durch die Bereitstellung verursacht werden	Nur intern, hohe Risikotoleranz und Fehleranfälligkeit	USA, Westen-Mitte
1	Bereiche, die das Team nicht ausgiebig testet	Kunden, die ein breites Spektrum des Produkts nutzen	Ein kleines Rechenzentrum
2	Skalenbezogene Fragen	Öffentliche Konten, idealerweise kostenlose Konten mit einer Vielzahl von Funktionen	Ein mittleres oder großes Rechenzentrum
3	Skalenfragen in der internen Rechnungslegung und internationale Fragen	Interne Großkunden und europäische Kunden	Internes Rechenzentrum und ein europäisches Rechenzentrum
4	Verbleibende Skaleneinheiten	Alle anderen	Alle Einsatzziele

Backzeit zulassen

Der Begriff bake time bezieht sich auf die Zeitspanne, die ein Einsatz laufen darf, bevor er auf den nächsten Ring erweitert wird. Bei einigen Problemen kann es Stunden oder länger dauern, bis die ersten Symptome auftreten. Daher sollte die Freisetzung eine angemessene Zeit lang in Betrieb sein, bevor sie als fertig betrachtet wird.

Im Allgemeinen sollte ein 24-Stunden-Tag für die meisten Szenarien ausreichen, um latente Wanzen freizulegen. Bei Diensten, die während der Geschäftszeiten Spitzenlasten aufweisen, sollte dieser Zeitraum jedoch einen Zeitraum mit Spitzenlasten umfassen, der einen vollen Arbeitstag erfordert.

Hotfixes beschleunigen

Ein live site incident (LSI) tritt auf, wenn ein Fehler schwerwiegende Auswirkungen auf die Produktion hat. LSIs erfordern die Erstellung eines Hotfixes, eines Out-of-Band-Updates, das ein Problem von hoher Priorität beheben soll.

Handelt es sich um Sev 0, die schwerwiegendste Art von Fehler, kann der Hotfix so schnell wie verantwortungsvoll möglich direkt auf die betroffene Skaleneinheit aufgespielt werden. Es ist zwar wichtig, dass die Korrektur die Situation nicht verschlimmert, aber Fehler dieses Schweregrads werden als so störend angesehen, dass sie sofort behoben werden müssen.

Fehler, die mit Sev 1 bewertet werden, müssen über den Ring 0 verteilt werden, können dann aber an die betroffenen Skaleneinheiten verteilt werden, sobald sie genehmigt sind.

Hotfixes für Fehler mit geringerem Schweregrad müssen wie geplant über alle Ringe verteilt werden.

Wichtige Erkenntnisse

Jedes Team möchte Aktualisierungen schnell und in bestmöglicher Qualität liefern. Mit den richtigen Praktiken kann die Bereitstellung ein produktiver und schmerzloser Teil des DevOps-Zyklus sein.

• Setzen Sie sie häufig ein.
• Bleiben Sie während des gesamten Sprints grün.
• Verwendung konsistenter Verteilungswerkzeuge in Entwicklung, Test und Produktion.
• Verwenden Sie eine Continuous-Delivery-Plattform, die Automatisierung und Autorisierung ermöglicht.
• Befolgen Sie sichere Einsatzpraktiken.

Nächste Schritte

Erfahren Sie, wie Feature Flags dazu beitragen, dass neue Funktionen den Benutzern zugänglich gemacht werden.