Ein einfacher, schlampig ausgeführter Softwarefehler kann ein Unternehmen viel Geld kosten, aber das lässt sich mit einfachen Änderungen an Architektur und Design vermeiden. Diese neue Ausgabe von ‚Release It‘ wurde im Januar 2018 veröffentlicht. Sie veranschaulicht, wie Sie Systeme entwerfen, die länger mit begrenzten Ausfällen arbeiten und die Kontrolle wiedererlangen, wenn etwas schief geht. Dieses Buch ist ein unentbehrlicher Leitfaden für die Entwicklung von Produktionssystemen.
WIE DIESES BUCH UNS GEHOLFEN HAT?
Dieses Buch hat uns geholfen, Risiken zu vermeiden, die Unternehmen viel Geld in Form von Ausfallzeiten und Reputation kosten. Achtzig Prozent der Lebenszykluskosten eines Produkts fallen in der Produktion an.
DAS BUCH ERKLÄRT IN 60 SEKUNDEN
Die aktualisierte Version von Release it! Design and Deploy Production-Ready Software befasst sich mit der Produktion moderner Systeme – großer, komplexer und stark virtualisierter Systeme. Sie erhalten einen Einblick in das Chaos-Engineering, die Disziplin der Implementierung von Zero-Downtime-Updates und Continuous Delivery sowie die Robustheit von Cloud-nativer Software. Analysieren Sie Ansätze zur Architektur, zum Design und zur Erstellung von Software-primär verteilten Systemen.
DIE DREI BESTEN ZITATE
- „Software-Design, wie es heute gelehrt wird, ist schrecklich unvollständig. Es wird nur darüber gesprochen, was Systeme tun sollten. Es geht nicht um das Gegenteil – was Systeme nicht tun sollten. Sie sollten nicht abstürzen, sich aufhängen, Daten verlieren, die Privatsphäre verletzen, Geld verlieren, Ihr Unternehmen zerstören oder Ihre Kunden töten.“
- „Die meisten Tester, die ich kenne, sind so pervers, dass, wenn Sie ihnen den „glücklichen Weg“ durch die Anwendung sagen, dies das Letzte ist, was sie tun werden. So sollte es auch bei Lasttests sein.“
- „Entwerfen Sie mit Skepsis, und Sie werden Widerstandsfähigkeit erreichen.“
BUCHZUSAMMENFASSUNGEN UND NOTIZEN
Kapitel eins: Stabilität schaffen
Wenn Ihre Software oder Datenbank abstürzt, wechseln Sie das Fenster und versuchen Sie etwas Neues. Ein Techniker vor Ort kann Ihnen bei der Umsetzung der Änderung helfen. Wenn Sie die Datenbank wechseln, versuchen Sie, zu einem besseren Service Provider zu wechseln. Sie können damit beginnen, Ihre Informationen und Daten von der alten Datenbank 1 in die neue Datenbank zwei zu verschieben und dann Datenbank 1 zu aktualisieren. Nachdem Sie die aktualisierte Datenbank überprüft haben, verschieben Sie Ihre Informationen und Daten in Datenbank 1.
Schlechte Stabilität verursacht hohe tatsächliche Kosten. Der scheinbare Preis ist ein Verlust an Einnahmen. Gute Stabilität kostet nicht so viel. Bei der Erstellung der Architektur, des Designs und der Implementierung kleinerer Systeme haben viele Entscheidungspunkte eine große Hebelwirkung auf die Stabilität des Systems. Eine hochstabile Software kostet in der Regel genauso viel wie eine instabile. Um über Stabilität zu sprechen, müssen Sie sich über Transaktionen im Klaren sein. Eine Transaktion ist eine abstrakte Arbeitseinheit, die vom System verarbeitet wird. Eine Transaktion erstreckt sich über viele Seiten und umfasst in der Regel externe Integrationen wie die Überprüfung von Kreditkarten. Transaktionen sind der Grund für die Existenz eines Systems. Ein System kann eine bestimmte Art von Transaktion verarbeiten und sie vollständig dediziert machen.
Die größten Unsicherheitsfaktoren für die Lebensdauer Ihres Systems sind Daten- und Speicherlecks. Beide Gefahren können Ihr System während der Produktion zerstören und werden beim Testen selten erkannt. Testen macht Probleme sichtbar, damit Sie sie beheben können. Die Probleme, die auftreten, wenn Ihre Software fertig ist, sind diejenigen, die Sie nicht getestet haben. Daher werden diese Abstürze auftreten, wenn Sie nicht auf Out-of-Memory-Fehler in der Anwendung testen.
Lieblingszitat des Kapitels: „Entwerfen Sie mit Skepsis, und Sie werden Widerstandsfähigkeit erreichen. .“
Kapitel zwei: Design für die Produktion
Operationen leiten Sie dazu an, Überlegungen zur Produktion anzustellen, indem Sie die physischen Grundlagen des Systems untersuchen: die Maschinen und Kabel, auf denen alles ruht. Lösen Sie einige Probleme in Bezug auf Netzwerke, Hostnamen und IP-Adressen. Jeder Einsatz hat seine eigenen Probleme, die beim Softwaredesign berücksichtigt werden müssen.
- Betrieb – Sicherheit, Kapazität, Status, Kommunikation, Verfügbarkeit
- Control Plane-Deployment, Anomalieerkennung, Funktionen, Systemüberwachung
- Interconnect-Routing, Ausfallsicherung, Verkehrsmanagement, Lastausgleich
- Instanzen – Dienste, Komponenten, Prozesse, Instanzüberwachung
- Basis-Hardware, VMs, physisches Netzwerk, IP-Adressen
Die Vernetzung im Rechenzentrum und in der Cloud erfordert mehr als das Öffnen einer Steckdose. Diese Netzwerke benötigen in der Regel mehr Redundanz und Sicherheit als Desktop-Netzwerke. Wenn Sie eine oder zwei Virtualisierungsschichten hinzufügen, verhalten sich Anwendungen und Dienste anders als in den sicheren Grenzen der IDE. Sie erfordern umfangreiche Arbeiten, um sich in dieser Umgebung korrekt zu verhalten.
Eine Instanz ist eine Installation auf einem einzelnen Rechner (virtuell oder physisch) aus einem Load-Balanced-Array derselben ausführbaren Datei. Einzelne Instanzen sorgen für Transparenz, handhaben die Konfiguration richtig, übernehmen die Kontrolle und verwalten Verbindungen. Jeder Rechner benötigt den richtigen Code, die richtige Konfiguration und die richtigen Netzwerkverbindungen. Entwickler achten in der Regel auf das Verhalten ihres Codes. Deshalb verfügen sie über großartige Tools zum Erstellen, Unterbringen und Bereitstellen von Code. Entwickler sollten in der Lage sein, ein System zu erstellen, Tests durchzuführen und zumindest einen Teil des Systems lokal zu implementieren.
Verbindungsebenen umfassen alle Mechanismen, die eine Reihe von Instanzen zu einem zusammenhängenden System verbinden, einschließlich Verkehrsmanagement, Erkennung und Lastausgleich. Durch die Verbindungsschichten kann eine hohe Verfügbarkeit erreicht werden. Überlegen Sie, welche Lösung für Ihr Unternehmen die richtige ist, wenn Sie den Stack zu Interconnect, Control Pane und Operations hinaufgehen. Nur wenige Techniken zur Erkennung und Innovation von Diensten sind in der Regel auf zusätzliche Software angewiesen. Ein umfangreiches Team mit Tausenden von winzigen Diensten schneidet bei der Verwendung von Consul oder anderen dynamischen Diensten gut ab. Auch die Kosten für den Betrieb von Consul machen sich schnell bezahlt. Für kleine Teams ist DNS die ideale Wahl in einer sich langsam verändernden Infrastruktur. Das würde engagierte physische Maschinen und dedizierte, langlebige virtuelle Maschinen voraussetzen. IP-Adressen bleiben in der Regel stabil, so dass DNS praktisch ist.
Lieblingszitat des Kapitels: „Lastausgleich, Routing, Lastverteilung und Service-Erkennung sind einige der wichtigsten Punkte, die beim Aufbau von Schichten zu berücksichtigen sind.“
Kapitel 3: Liefern Sie Ihr System
Sie sollten nicht nur eine oder einige wenige Verteilungen für die Produktion planen, sondern mehrere. Nachdem Sie Ihre Software geschrieben, komprimiert und zur Bereitstellung an den Betrieb geschickt haben, fügen Sie Versionshinweise zu jeder neuen Konfigurationsoption hinzu, die der Betrieb einstellen soll. Der Betrieb wird eine „geplante Ausfallzeit“ für die Ausführung der Version festlegen. In den meisten Fällen entwerfen Sie den Zustand des Systems nach einer Freigabe. Das Problem dabei ist, dass dies voraussetzt, dass das gesamte System in einem Quantensprung verändert werden kann.
Code ist eine eindeutige Verbindlichkeit zwischen dem Zeitpunkt, an dem Sie den Code im Repository ausführen, und dem Zeitpunkt, an dem er in der Produktion läuft. Nicht bereitgestellter Code ist in der Regel Inventar. Er enthält unentdeckte Fehler und verursacht Ausfallzeiten in der Produktion. Es könnte sich um eine ideale Implementierung einer Funktion handeln, die niemand will. Die kontinuierliche Bereitstellung minimiert die Verzögerung zwischen der Ausführung und der Produktion von Code und die Haftung für nicht bereitgestellten Code.
Datenbanken sind der Hauptgrund für „geplante Ausfallzeiten“, meist Schemaänderungen bei relationalen Datenbanken. Anstatt rohe SQL-Skripte gegen eine Admin-CLI zu implementieren, können Sie Ihre Schemaversion programmgesteuert vorwärts rollen. Ein Migrations-Framework wie Liquibase kann Sie bei der Implementierung von Änderungen am Schema unterstützen. Es macht diese Änderungen jedoch nicht automatisch vorwärts- und abwärtskompatibel.
Achten Sie beim Hinzufügen von Funktionen zu Ihrer Anwendung darauf, dass Sie keine Anwendungen konsumieren. Verschiedene Nutzer Ihres Dienstes haben andere Ziele und Bedürfnisse. Jede konsumierende Anwendung hat ihr eigenes Entwicklungsteam, das nach ihrem Zeitplan arbeitet. Sie können die Verbraucher nicht dazu zwingen, sich an Ihren Veröffentlichungszeitplan anzupassen. Um kompatible API-Änderungen vorzunehmen, sollten Sie überlegen, was eine inkompatible Änderung ausmacht.
Lieblingszitat des Kapitels: „Gleichzeitig hatte ich ein tiefes Gefühl des Verlustes: all die Zeit in der Einsatzarmee. All das vergeudete Potenzial. Die verschwendete Menschlichkeit! Menschen zu benutzen, als wären sie Bots. Das Leben, die Familien, die Schlafgewohnheiten zu zerstören… das war alles eine solche Verschwendung.“
Kapitel Vier: Lösen Sie systemische Probleme
Lasttests sind in der Regel ein unkomplizierter Prozess. Sie legen einen Testplan fest, erstellen einige Skripte, konfigurieren die Lastgeneratoren und den Testdispatcher und starten einen Testlauf über die Nacht. Nachdem der Test abgeschlossen ist, analysieren Sie die während des Tests gesammelten Daten. Prüfen Sie die Ergebnisse, nehmen Sie Konfigurationsänderungen vor und planen Sie den nächsten Testlauf. Lasttests sind sowohl eine Kunst als auch eine Wissenschaft. Es ist unvorstellbar, den realen Datenverkehr in der Produktion nachzubilden. Nutzen Sie daher die Analyse des Datenverkehrs und Ihre Intuition, um eine möglichst realistische Simulation zu erreichen.
Der Wandel ist garantiert, aber das Überleben nicht. Bei der agilen Entwicklung wird der Wandel als Reaktion auf die geschäftlichen Bedingungen begrüßt. Allerdings zeigt der Pfeil wahrscheinlich in die andere Richtung. Softwareveränderungen können neue Produkte und Märkte hervorbringen. Er kann Raum für neue Allianzen und neuen Wettbewerb schaffen und die Fläche zwischen Unternehmen, die früher in verschiedenen Branchen tätig waren, vergrößern. Nicht jede Software muss täglich geändert werden. Manche Software hat kein Potenzial für schnelle Änderungen und Anpassungen. In einigen Branchen müssen Softwareänderungen durch teure und zeitaufwändige Zertifizierungen erfolgen. Sie haben hohe Transaktionskosten, wenn Sie Astronauten mit einem Schraubenzieher und einem Spanabzieher ins All schicken wollen.
Ihr Unternehmen muss einen Entscheidungszyklus durchlaufen, um eine Veränderung zu implementieren. Jemand muss erkennen, dass es einen Bedarf gibt, ein anderer muss entscheiden, dass die Funktion perfekt zu diesem Bedarf passt und es sich lohnt, sie umzusetzen. Dann muss jemand handeln und die Funktion entwerfen und sie auf den Markt bringen – und schließlich muss jemand sehen, ob die Änderung die erwartete Wirkung hat. In kleinen Unternehmen kann dieser Prozess zwei bis drei Personen betreffen. Die Kommunikation ist ziemlich schnell.
Chaos Engineering befasst sich mit verteilten Systemen, in der Regel mit großen Systemen. Staging- oder QA-Umgebungen sind nicht ideal für das Verhalten von Produktionssystemen in großem Maßstab. Unterschiedliche Verhältnisse von Instanzen führen zu qualitativ unterschiedlichem Ausgabeverhalten, was auch für den Verkehr gilt. Überlastete Netzwerke verhalten sich qualitativ anders als nicht überlastete Netzwerke.
Lieblingszitat des Kapitels: „Die meisten Tester, die ich kenne, sind so pervers, dass, wenn Sie ihnen den „glücklichen Weg“ durch die Anwendung sagen, dies das Letzte ist, was sie tun werden. So sollte es auch bei Lasttests sein.“
WIE DIESES BUCH SOFTWAREENTWICKLERN HELFEN KANN
„Release It!“ von Michael T. Nygard ist ein praktischer Leitfaden, der Softwareentwicklern hilft, produktionsreife Software zu entwerfen, zu entwickeln und einzusetzen. Das Buch enthält Beispiele und Fallstudien aus der Praxis, die häufige Fallstricke aufzeigen und Lösungen anbieten, um diese zu vermeiden. Das Buch bietet Tipps und Techniken, um Probleme vor der Bereitstellung zu erkennen und zu beheben, einschließlich der Verwaltung von Abhängigkeiten, Tests und Überwachung. Es behandelt Themen wie Leistungsoptimierung, Skalierbarkeit, Fehlertoleranz, Überwachung und Protokollierung und konzentriert sich auf die Entwicklung von Software, die den harten Anforderungen der Produktion standhalten kann. Wenn Sie die Richtlinien des Buches befolgen, können Softwareentwickler zuverlässige und widerstandsfähige Systeme erstellen, die den Anforderungen ihrer Benutzer und Kunden gerecht werden. Insgesamt ist dieses Buch eine unverzichtbare Ressource für Entwickler, die die Qualität und Leistung ihrer Software in der Produktionsumgebung verbessern möchten.
