Dies bleibt eines der wichtigsten Bücher, die Softwareentwickler lesen können. Die zweite Ausgabe ist sogar noch besser als die erste. Sie wurde aktualisiert, um viele der "veralteten" Kritikpunkte des ersten Buches zu beheben. Sie enthält die moderne DevOps-Bewegung, Microservices und moderne Technologien, die in der Softwareentwicklung verwendet werden.

Ich kann wirklich nicht genug über dieses Buch sagen. Es muss gelesen werden. Wenn Sie für Code verantwortlich sind, der auf vernetzten Produktionssystemen ausgeführt wird, sollte das Nichtlesen dieses Buches eine strafbare Handlung sein. Überspringen von "Release It!" ist berufliche Fahrlässigkeit. Hören Sie auf, was Sie tun, und lesen Sie dies, bevor Sie eine weitere Codezeile versenden.

Lass es los! dreht sich alles darum, wie man zynische Software erstellt, und wenn man diesen Weg einmal eingeschlagen hat, stellt man fest, dass man nicht mehr anders denken kann. Dieses Buch verändert Sie und Ihre Karriere, es ist einfach phänomenal. Selbst wenn Sie glauben, alles darin zu wissen, weil die darin beschriebenen Muster und Praktiken weit verbreitet sind, lohnt es sich dennoch, sie zu lesen.

Die zweite Ausgabe behebt - oder verbessert zumindest etwas - jede kleinere Beschwerde, die ich über die erste Ausgabe hatte, und organisiert die Informationen neu, fügt viele großartige neue Abschnitte hinzu und entfernt veraltete Cruft. Es ist der ersten Ausgabe in jeder Hinsicht überlegen, und das war ein 5-Sterne-Buch für mich.

Sie verschwenden Zeit damit, diese Rezension zu lesen. Sie könnten stattdessen dieses Buch lesen.

Lass es los! ist eines der wichtigsten Bücher, die Programmierer meiner Meinung nach lesen können, genauso wichtig wie die oft zitierten Klassiker wie The Pragmatic Programmer oder das GoF-Buch. Lass es los! Es geht nicht darum, superschlanken Code oder objektorientiertes Design zu schreiben, sondern es sollte sich drastisch darauf auswirken, wie professionelle Programmierer ihren Code schreiben. Es konzentriert sich darauf, was Ingenieure tun müssen, um ihre Software in einen Zustand zu versetzen, in dem sie tatsächlich sicher in einer Produktionsumgebung bereitgestellt werden kann. Es behandelt Muster und Antimuster, um Stabilität und Kapazität zu unterstützen (oder zu untergraben), und der Abschnitt des Buches, der dies behandelt, ist einfach hervorragend. Aber dann geht es darüber hinaus, auch die betriebliche Aktivierung zu diskutieren. Auch wenn Sie sich nicht für DevOps interessieren und nicht wirklich in die DevOps-Arbeit involviert sein möchten, bietet Ihnen dieses Buch die Tools und Tipps, um herauszufinden, welcher Aspekt von DevOps in den Zuständigkeitsbereich reiner Entwickler fällt.

Niemand, der Software für Produktionsunternehmen schreibt, sollte eine andere Codezeile schreiben, bis er dieses Buch gelesen hat. Ich kann es ehrlich gesagt nicht genug von einer leuchtenden Bestätigung geben. Wie bei jedem anderen Musterbuch ist ein Großteil davon Menschen bekannt, die schon eine Weile in der Branche tätig sind und ihre Prinzipien selbst entwickelt haben (oder ihnen begegnet sind). Aber ich garantiere, wenn es eine einzige Sache in dem Buch gibt, die Sie noch nicht gesehen haben, lohnt es sich, das gesamte Buch zu lesen, so ziemlich jeder Abschnitt ist Gold.

Meine einzige Beschwerde darüber ist, dass Michael Nygard dazu neigt, zufällige Tangenten zu verwenden, insbesondere wenn es um "Fallstudien" geht, die sich im Allgemeinen ergeben, wenn der Autor zu sehr versucht, den Leser davon zu überzeugen, dass er weiß, wovon er spricht. Viele dieser Geschichten handeln von Dingen, denen er persönlich in seiner Karriere begegnet ist, und wie er sie behoben hat, und jede hat eine seltsame arrogante Qualität. Es ist ein wenig abstoßend, um ehrlich zu sein, so wie Nygard fast prahlt. Ich verstehe, dass diese Abschnitte den Wert der Ideen in dem Buch unterstreichen, aber es gibt etwas an ihrer Schreibweise, das prahlerisch oder irritierend wirkt, was ich nicht ganz in Worte fassen kann. Darüber hinaus BEGINNT das Buch mit einer besonders langen Geschichte dieser Art, was es schwierig macht, in das Buch einzusteigen. Ich habe vor Jahren tatsächlich versucht, es zu lesen und habe es sehr früh aufgegeben. Erst kürzlich habe ich mich entschlossen, es erneut zu besuchen und weiter voranzutreiben (basierend auf der Empfehlung eines Kollegen), und ich bin äußerst froh, dass ich es getan habe.

Ich empfehle dringend, dieses Buch in die Hand zu nehmen und es von vorne bis hinten zu lesen. Es ist zunächst ein Kampf wegen der unglücklichen Entscheidung, es mit einem der nervigsten Abschnitte des Buches zu beginnen, aber ich flehe Sie an, es durchzuarbeiten und weiterzulesen. Das ist es wert.

Zunächst muss ich sagen, dass dies eines der besten technischen Bücher ist, die ich je gelesen habe. Für mich ist es genauso unterhaltsam und nützlich wie Code Complete, The Pragmatic Programmer oder The Mythical Man Month. Wenn Sie ein Systemadministrator, Architekt oder Entwickler sind, der mit mittelgroßen bis großen Systemen arbeitet, gehen Sie wie folgt vor:

1. Hör auf, diesen Beitrag zu lesen
2. Bestellen Sie dieses Buch in Ihrer Bibliothek oder kaufen Sie es auf der Website von The Pragmatic Programmer
3. Schuldet mir ein Pint: D.


Worum geht es in dem Buch wirklich?

Eigentlich gibt es eine Sache, die ich an diesem Buch nicht mag, aber es hat wirklich nichts mit dem Buch zu tun. Die Beschreibung dieses Buches auf der Website des Pragmatic Programmer ist zum Kotzen. Es ist vage und gibt dem potenziellen Leser wirklich einen kleinen Einblick in den Inhalt des Buches.

Was es hätte sagen sollen, ist, dass dieses Buch * Tonnen * großartiger Informationen zum Entwerfen, Bereitstellen, Warten und * Verbessern * mittelgroßer bis großer IT-Systeme enthält. Es enthält Muster, Anti-Patterns und allgemeine Best Practices, die Teil des gemeinsamen Lexikons aller Entwickler, Administratoren und Systemarchitekten sein sollten. Außerdem leistet es gute Arbeit, Ihnen genügend Informationen zu geben, um nützlich zu sein, ohne Sie zu Tode zu langweilen. Und schließlich ist es sehr gut geschrieben und es ist eine Freude zu lesen.

Die Highlights

Thread Dumps & Garbage Collection Tuning

Die Interna der Java Virtual Machine (JVM) waren für mich während des größten Teils meiner Karriere in der IT eine Black Box. Zum Glück enthält dieses Buch hervorragende Beispiele dafür, wie Sie Fehler beheben und Ihr System verbessern können, indem Sie Tools verwenden, die eine JVM zur Laufzeit abfragen und bearbeiten.

Für mich war dies der interessanteste und nützlichste Teil des Buches, und ich freue mich darauf zu sehen, was durch das Einstellen und "Stöbern" der JVMs in dem von mir verwalteten System erreicht werden kann.

Muster und Anti-Muster

Es ist großartig, endlich ein Buch zu finden, das einige Muster kodifiziert, die Administratoren und Architekten verwenden können.

Transparenz

Ich dachte, dass ich vor dem Lesen dieses Buches viel über Überwachung und Transparenz gelernt habe, aber jetzt weiß ich es besser. Ich mag besonders das Konzept einer einheitlichen "OpsDB" und ich bin bestrebt, so etwas selbst für das System zu bauen, das ich pflege.

Integrationspunktrisiken

Ich wusste immer, dass Integrationspunkte (z. B. Datenfeeds, Datenbanken, LDAP-Anbieter usw.) das Risiko für Ihr System erhöhen, aber der Autor leistet hervorragende Arbeit bei der Berechnung des tatsächlichen Risikos. Außerdem zeigt er Ihnen viele Möglichkeiten, wie Sie spröde Integrationspunkte vermeiden können.

Vorsichtsmaßnahmen

Ich habe eine Warnung zu diesem Buch, aber es ist halbherzig. Dieses Buch würde ich alle Java-zentriert. Alle Fallstudien betreffen Systeme, die in Java geschrieben sind, und einige der Abschnitte gelten nur dann direkt für Sie, wenn Sie mit Java-basierter Software arbeiten.

Aber bedeutet das, dass Sie dieses Buch vermeiden sollten, wenn Sie mit Ruby-, PHP- oder .NET-basierter Software arbeiten? Absolut nicht. Obwohl es einige kleine Abschnitte des Buches gibt, die nicht direkt auf Ihre Arbeit zutreffen, gelten die meisten davon indirekt, unabhängig von Ihrer Plattform. Die anderen 94% des Buches beziehen sich direkt auf mittlere bis große Systeme jedes Streifens.

Es gibt eine relativ kurze Liste von Büchern, die ich gerne auf meinem Schreibtisch behalten würde. Meistens sind diese Bücher Referenzen und eine Komposition berühmter Zitate. Nachdem ich diesen Kerl gelesen habe, möchte ich ihn jederzeit auf meinem Schreibtisch haben.

Dieses Buch ist eine perfekte Mischung aus vielen nützlichen technischen Erkenntnissen, Praktiken und Empfehlungen, die aus den hart erarbeiteten Erfahrungen des Autors gewonnen wurden, kombiniert mit einigen der Soft Skills, die Sie für die Erstellung Ihrer Software und deren Wartung benötigen (was nach Angaben des Autors mehr kostet als die anfängliche Version 1.0) so reibungslos wie möglich mit so viel Schlafunterbrechung wie möglich.

Das Buch ist definitiv veraltet, einige der Verweise auf bestimmte Technologien sehen seltsam und offensichtlich aus (wenn nicht sogar lustig). Trotzdem werde ich dieses Buch in eine Reihe mit dem "SRE-Buch" und "Projekt Phoenix" setzen, da es beide kombiniert.

Meine Punktzahl ist 5/5

Es gibt einen Überblick darüber, wie Systeme in der Produktion kaputt gehen und wie dies vermieden werden kann. Der Autor schafft es, ein ziemlich trockenes Thema aufzunehmen und ein Buch zu produzieren, das sehr einfach zu lesen ist.

Jetzt ist es an einigen Stellen ziemlich veraltet. Es ist aus dem Jahr 2007, als der Begriff DevOps noch nicht einmal weit verbreitet war. Gleichzeitig ist es interessant zu sehen, wie viel davon noch hält.

Es gibt zu viele Verweise auf JVM-spezifische Probleme. Ich denke nicht, dass dies die Erfahrung für Leser ruiniert, die außerhalb der JVM arbeiten, aber es ist seltsam, gelegentliche Referenzen (Garbage Collection Tuning, Permgen-Größe, JSP, JMX usw.) an mehreren Stellen zu sehen, während der Buchtitel / Untertitel / Cover / Beschreibung sagt nichts darüber. Vielleicht stammt das aus einer Zeit, in der das Codieren für Unternehmen ausschließlich Java bedeutete.

"Lass es los!" ist ein großartiges Buch, das jeder Softwareentwickler, Architekt, Designer oder sogar QS-Ingenieur lesen sollte. Es konzentriert sich auf Prinzipien und Anleitungen, so dass es den Anschein hat, als würde es einige Details vermissen. Wenn es sich jedoch mehr auf die spezifischen Tools als auf die Prinzipien konzentriert, wird es schnell veraltet. Sie werden es nicht bereuen, Zeit mit dem Buch verbracht zu haben - es umfasst 336 Seiten nützliches und niemals veraltetes Wissen. Sehr empfehlenswert!

Meine vollständige Rezension finden Sie hier: https://e.printstacktrace.blog/releas...

Dieses Buch ist ein Kampf, den jeder Softwareentwickler unbedingt lesen muss. Selbst nach 7 Jahren seit Veröffentlichung des Buches bleibt so ziemlich jeder Rat darin gültig und relevant. Die Idee der Betriebsdatenbank hat bei Produkten wie Splunk Marktbestätigung gefunden. Das Curcuit Breaker-Muster wurde seitdem mehrfach in verschiedenen OSS-Bibliotheken implementiert.

Ein erfahrener Entwickler hätte wahrscheinlich einige der Ratschläge auf die harte Tour gelernt. Trotzdem habe ich viel Weisheit aus dem Buch aufgegriffen, Michaels Geschichtenerzählen gemocht und seine sehr breite Perspektive geschätzt.

Dieses Buch ist eine unglaubliche Einführung in das Erstellen und Verwalten von ausfallsicheren Webanwendungen in realistischen, chaotischen Umgebungen. Dieses Buch hat meine Herangehensweise an die Entwicklung mehr als jedes andere verändert. Jeder Entwickler, der etwas in der Produktion hat, sollte es lesen.

Tolles Buch mit verschiedenen Aspekten und Hinweisen zur Bereitstellung von Software für die Produktion. Viele Softwarearchitekten sind "kurzsichtig" und denken darüber nach, eine Software zu entwickeln, die Unit- / Integrationstests besteht und kurz nach der Veröffentlichung fehlschlägt.

Zitate:

Mit einem Thread-Dump ausgestattet, ist die Anwendung ein offenes Buch, wenn Sie wissen, wie man es liest. Sie können viel über Anwendungen ableiten, für die Sie den Quellcode noch nie gesehen haben. Sie können Folgendes feststellen: Welche Bibliotheken von Drittanbietern verwendet eine Anwendung? Welche Art von Thread-Pools hat sie? Wie viele Threads befinden sich in jedem? Welche Hintergrundverarbeitung verwendet die Anwendung? Welche Protokolle verwendet die Anwendung (anhand der Klassen und Methoden im Stack-Trace jedes Threads?)

So sehr sich RMI die maschinenübergreifende Kommunikation wie lokale Programmierung anfühlte, kann dies gefährlich sein, da Anrufe nicht zum Timeout getätigt werden können. Infolgedessen ist der Anrufer anfällig für Probleme auf dem Remoteserver.

Das Erstaunliche ist, dass die Implementierung des hochstabilen Designs normalerweise die gleichen Kosten verursacht wie das instabile.

Ein robustes System verarbeitet Transaktionen auch dann weiter, wenn vorübergehende Impulse, anhaltende Belastungen oder Komponentenfehler die normale Verarbeitung stören. Das ist es, was die meisten Menschen unter „Stabilität“ verstehen. Es ist nicht nur so, dass Ihre einzelnen Server oder Anwendungen in Betrieb bleiben, sondern dass der Benutzer dennoch seine Arbeit erledigen kann.

Je enger die Architektur gekoppelt ist, desto größer ist die Wahrscheinlichkeit, dass sich dieser Codierungsfehler ausbreitet. Umgekehrt wirken die weniger gekoppelten Architekturen als Stoßdämpfer und verringern die Auswirkungen dieses Fehlers, anstatt sie zu verstärken.

Ereignisse, die den Fehler verursacht haben, sind nicht unabhängig. Ein Fehler in einem Punkt oder einer Schicht erhöht tatsächlich die Wahrscheinlichkeit anderer Fehler. Wenn die Datenbank langsam wird, ist es wahrscheinlicher, dass den Anwendungsservern der Arbeitsspeicher ausgeht. Da die Schichten gekoppelt sind, sind die Ereignisse nicht unabhängig.

Genau über diese Ereignisketten: Fehler Eine Bedingung, die einen falschen internen Status in Ihrer Software erzeugt. Ein Fehler kann auf einen latenten Fehler zurückzuführen sein, der ausgelöst wird, oder auf einen ungeprüften Zustand an einer Grenze oder einer externen Schnittstelle. Fehler Sichtbar falsches Verhalten. Wenn Ihr Handelssystem plötzlich zehn Milliarden Dollar Pokemon-Futures kauft, ist das ein Fehler. Fehler Ein nicht reagierendes System. Wenn ein System nicht reagiert, sagen wir, dass es ausgefallen ist. Der Fehler liegt im Auge des Betrachters ... Ein Computer ist möglicherweise eingeschaltet, reagiert jedoch nicht auf Anfragen. Das Auslösen eines Fehlers öffnet den Riss. Fehler werden zu Fehlern, und Fehler provozieren Fehler. So breiten sich die Risse aus. Bei jedem Schritt in der Ausfallkette kann sich der Riss eines Fehlers beschleunigen, verlangsamen oder stoppen.

verursachte ein Remote-Problem, das zu Ausfallzeiten führte. Eine Möglichkeit, sich auf jeden möglichen Fehler vorzubereiten, besteht darin, jeden externen Anruf, jede E / A, jeden Ressourcenverbrauch und jedes erwartete Ergebnis zu überprüfen und zu fragen: „Wie kann dies alles schief gehen?“ Denken Sie über die verschiedenen Arten von Impulsen und Stress nach, die angewendet werden können:

Durch die enge Kopplung können sich Risse in einem Teil des Systems über Schicht- oder Systemgrenzen hinweg ausbreiten oder vermehren. Ein Fehler in einer Komponente führt dazu, dass die Last auf die Peers umverteilt wird, und führt zu Verzögerungen und Stress für die Anrufer. Diese erhöhte Belastung macht es äußerst wahrscheinlich, dass eine andere Komponente im System ausfällt. Dies wiederum macht den nächsten Ausfall wahrscheinlicher und führt schließlich zum völligen Zusammenbruch. In Ihren Systemen kann eine enge Kopplung innerhalb des Anwendungscodes, bei Aufrufen zwischen Systemen oder an jedem Ort auftreten, an dem eine Ressource mehrere Verbraucher hat.

Ein Schmetterlingsstil hat 2N-Verbindungen, ein Spinnennetz könnte bis zu zwei haben, und Ihre liegt irgendwo dazwischen.

Eine Falte, auf die Sie achten müssen, ist, dass es lange dauern kann, bis Sie feststellen, dass Sie keine Verbindung herstellen können. Machen Sie einen kurzen Einblick in die Details des TCP / IP-Netzwerks. Jedes jemals gezeichnete Architekturdiagramm enthält Kästchen und Pfeile, ähnlich wie in der folgenden Abbildung. (Ein neuer Architekt wird sich auf die Kisten konzentrieren; ein erfahrener interessiert sich mehr für die Pfeile.)

Sie müssen das Socket-Timeout festlegen, wenn Sie den blockierenden Anruf abbrechen möchten. In diesem Fall sollten Sie auf eine Ausnahme vorbereitet sein, wenn das Zeitlimit auftritt.

Nachdem wir alle Glieder dieser Fehlerkette verstanden hatten, mussten wir eine Lösung finden. Der Ressourcenpool kann JDBC-Verbindungen vor dem Auschecken auf Gültigkeit prüfen. Die Gültigkeit wurde überprüft, indem eine SQL-Abfrage wie "SELECT SYSDATE FROM DUAL" ausgeführt wurde.

Glücklicherweise erinnerte sich ein scharfer DBA genau an das Ding. Oracle verfügt über eine Funktion namens Dead Connection Detection, mit der Sie feststellen können, wann Clients abgestürzt sind. Wenn diese Option aktiviert ist, sendet der Datenbankserver in regelmäßigen Abständen ein Ping-Paket an den Client. Wenn der Client antwortet, weiß die Datenbank, dass sie noch aktiv ist. Wenn der Client nach einigen Wiederholungsversuchen nicht antwortet, geht der Datenbankserver davon aus, dass der Client abgestürzt ist, und gibt alle von dieser Verbindung gehaltenen Ressourcen frei.

Die effektivsten Stabilitätsmuster zur Bekämpfung von Integrationspunktfehlern sind Leistungsschalter und Entkopplungs-Middleware.

Suchen Sie nach Ressourcenlecks. In den meisten Fällen tritt eine Kettenreaktion auf, wenn in Ihrer Anwendung ein Speicherverlust auftritt. Wenn einem Server der Speicher ausgeht und er ausfällt, übernehmen die anderen Server die Last des Toten. Durch den erhöhten Datenverkehr verlieren sie schneller Speicher.

Verhindern Sie, dass Risse über die Lücke springen. Ein Kaskadenfehler tritt auf, wenn Risse von einem System oder einer Schicht zu einem anderen springen, normalerweise aufgrund unzureichend paranoider Integrationspunkte. Ein Kaskadenfehler kann auch nach einer Kettenreaktion in einer unteren Schicht auftreten. Ihr System ruft sicherlich andere Unternehmenssysteme an. Stellen Sie sicher, dass Sie aufbleiben können, wenn sie fallen.

Ressourcenpools überprüfen. Ein kaskadierender Fehler resultiert häufig aus einem Ressourcenpool, z. B. einem Verbindungspool, der erschöpft ist, wenn keiner seiner Aufrufe zurückkehrt. Die Threads, die die Verbindungen erhalten, blockieren für immer. Alle anderen Threads werden blockiert und warten auf Verbindungen. Sichere Ressourcenpools begrenzen immer die Zeit, die ein Thread warten kann, um eine Ressource auszuchecken.

Wenn Sie in der Cloud arbeiten, ist die automatische Skalierung Ihr Freund. Aber Vorsicht! Es ist nicht schwer, eine große Rechnung durch automatische Skalierung fehlerhafter Anwendungen zu erstellen.

Stellen Sie sicher, dass Ihre Systeme einfach zu patchen sind - Sie werden viel davon tun. Halten Sie Ihre Frameworks auf dem neuesten Stand und halten Sie sich auf dem Laufenden.

Aus diesem Grund empfehle ich, interne Monitore (z. B. Scraping von Protokolldateien, Prozessüberwachung und Portüberwachung) durch externe Überwachung zu ergänzen. Ein Scheinclient irgendwo (nicht im selben Rechenzentrum) kann regelmäßig synthetische Transaktionen ausführen. Dieser Client hat dieselbe Ansicht des Systems wie echte Benutzer. Wenn dieser Client die synthetischen Transaktionen nicht verarbeiten kann, liegt ein Problem vor, unabhängig davon, ob der Serverprozess ausgeführt wird oder nicht.

Wenn Sie feststellen, dass Sie Methoden für Ihre Domänenobjekte synchronisieren, sollten Sie das Design wahrscheinlich überdenken. Finden Sie einen Weg, wie jeder Thread seine eigene Kopie des betreffenden Objekts erhalten kann. Dies ist aus zwei Gründen wichtig. Wenn Sie die Methoden synchronisieren, um die Datenintegrität sicherzustellen, wird Ihre Anwendung zunächst unterbrochen, wenn sie auf mehr als einem Server ausgeführt wird. Die In-Memory-Kohärenz spielt keine Rolle, wenn ein anderer Server die Daten ändert. Zweitens lässt sich Ihre Anwendung besser skalieren, wenn sich Threads zur Bearbeitung von Anforderungen niemals gegenseitig blockieren.

Eine elegante Möglichkeit, die Synchronisierung von Domänenobjekten zu vermeiden, besteht darin, Ihre Domänenobjekte unveränderlich zu machen.

Wenn es an der Zeit ist, ihren Status zu ändern, erstellen Sie ein „Befehlsobjekt“ und geben Sie es aus. Dieser Stil wird als "Trennung der Verantwortlichkeiten für Befehlsabfragen" bezeichnet und vermeidet eine große Anzahl von Parallelitätsproblemen.

In der Objekttheorie besagt das Liskov-Substitutionsprinzip, dass jede Eigenschaft, die für Objekte eines Typs T gilt, auch für Objekte eines beliebigen Subtyps von T gelten sollte. Mit anderen Worten, eine Methode ohne Nebenwirkungen in einer Basisklasse sollte ebenfalls frei sein Nebenwirkungen in abgeleiteten Klassen. Eine Methode, die die Ausnahme E in Basisklassen auslöst, sollte nur Ausnahmen vom Typ E (oder Untertypen von E) in abgeleiteten Klassen auslösen.

Bibliotheken sind berüchtigte Quellen für das Blockieren von Threads, unabhängig davon, ob es sich um Open-Source-Pakete oder Herstellercode handelt. Viele Bibliotheken, die als Service-Clients arbeiten, führen ihre eigenen Ressourcenpools innerhalb der Bibliothek durch. Dadurch blockieren Anforderungsthreads häufig für immer, wenn ein Problem auftritt. Auf diese Weise können Sie natürlich niemals ihre Fehlermodi konfigurieren, z. B. was zu tun ist, wenn alle Verbindungen unterbrochen sind und auf Antworten warten, die niemals eingehen werden.
Ein blockierter Thread wird häufig in der Nähe eines Integrationspunkts gefunden. Diese blockierten Threads können schnell zu Kettenreaktionen führen, wenn das entfernte Ende der Integration fehlschlägt. Blockierte Threads und langsame Antworten können eine positive Rückkopplungsschleife erzeugen und ein kleines Problem zu einem Totalausfall machen. Denken Sie daran. Denken Sie daran, dass das Antimuster "Blockierte Threads" die unmittelbare Ursache für die meisten Fehler ist.

Verwenden Sie bewährte Grundelemente. Lernen und wenden Sie sichere Grundelemente an. Es scheint einfach zu sein, eine eigene Produzenten- / Konsumentenwarteschlange zu erstellen: das ist es nicht. Jede Bibliothek von Parallelitätsdienstprogrammen verfügt über mehr Tests als Ihre neugeborene Warteschlange. Mit Timeouts verteidigen. Sie können nicht beweisen, dass Ihr Code keine Deadlocks enthält, aber Sie können sicherstellen, dass kein Deadlock für immer anhält. Vermeiden Sie unendliche Wartezeiten bei Funktionsaufrufen. Verwenden Sie eine Version, die einen Timeout-Parameter verwendet. Verwenden Sie immer Zeitüberschreitungen, auch wenn Sie dadurch mehr Code zur Fehlerbehandlung benötigen.

Die automatische Skalierung kann hilfreich sein, wenn der Verkehrsanstieg eintrifft. Achten Sie jedoch auf die Verzögerungszeit. Das Hochfahren neuer virtueller Maschinen dauert wertvolle Minuten. Mein Rat ist, die Konfiguration vor dem Marketing-Event vor der automatischen Skalierung zu erhöhen

Selbstverleugnungsangriffe entstehen in Ihrer eigenen Organisation, wenn Menschen selbst zugefügte Wunden verursachen, indem sie ihre eigenen Flashmobs und Verkehrsspitzen erzeugen. Sie können diese Marketingbemühungen unterstützen und fördern und gleichzeitig Ihr System schützen, aber nur, wenn Sie wissen, was kommt. Stellen Sie sicher, dass niemand Massen-E-Mails mit Deep Links sendet. Senden Sie Massen-E-Mails in Wellen, um die Spitzenlast zu verteilen. Erstellen Sie statische Landezonenseiten für den ersten Klick aus diesen Angeboten. Achten Sie auf eingebettete Sitzungs-IDs in URLs.

Zu oft wird die gemeinsam genutzte Ressource jedoch zur ausschließlichen Verwendung zugewiesen, während ein Client eine Arbeitseinheit verarbeitet. In diesen Fällen skaliert die Wahrscheinlichkeit von Konflikten mit der Anzahl der von der Schicht verarbeiteten Transaktionen und der Anzahl der Clients in dieser Schicht. Wenn die gemeinsam genutzte Ressource gesättigt ist, erhalten Sie ein Verbindungs-Backlog. Wenn das Backlog die Abhörwarteschlange überschreitet, erhalten Sie fehlgeschlagene Transaktionen. Zu diesem Zeitpunkt kann fast alles passieren. Dies hängt davon ab, welche Funktion der Anrufer für die Bereitstellung der gemeinsam genutzten Ressource benötigt. Insbesondere bei Cache-Managern (die Kohärenz für verteilte Caches gewährleisten) führen fehlgeschlagene Transaktionen zu veralteten Daten oder - schlimmer noch - zum Verlust der Datenintegrität.

Wenn eine Reihe von Servern diese vorübergehende Last auf einmal auferlegt, spricht man von einem Hundehaufen. ("Dogpile" ist ein Begriff aus dem American Football, bei dem der Ballträger an der Basis einer riesigen Pyramide aus mit Steroid infundiertem Fleisch zusammengedrückt wird.)

Während Auslastungstests kann sich ein Impuls entwickeln, wenn die virtuellen Benutzerskripte zeitlich festgelegte Wartezeiten aufweisen. Stattdessen sollte auf jede Pause in einem Skript ein kleines zufälliges Delta angewendet werden.

Hundehaufen zwingen Sie dazu, zu viel auszugeben, um die Spitzenlast zu bewältigen. Ein Hundehaufen konzentriert die Nachfrage. Es erfordert eine höhere Spitzenkapazität als Sie benötigen, wenn Sie den Anstieg verteilen. Verwenden Sie zufällige Taktschwankungen, um die Nachfrage zu verteilen. Stellen Sie nicht alle Ihre Cron-Jobs auf Mitternacht oder eine andere Stunde ein. Mischen Sie sie, um die Ladung zu verteilen. Verwenden Sie längere Backoff-Zeiten, um ein Pulsieren zu vermeiden. Ein festes Wiederholungsintervall konzentriert die Nachfrage der Anrufer auf diesen Zeitraum. Verwenden Sie stattdessen einen Backoff-Algorithmus, damit sich verschiedene Anrufer in ihren Backoff-Perioden an unterschiedlichen Punkten befinden.

Wir können ähnliche Sicherheitsvorkehrungen in unserer Steuerebenensoftware implementieren: Wenn Beobachtungen zeigen, dass mehr als 80 Prozent des Systems nicht verfügbar sind, ist es wahrscheinlicher, dass es ein Problem für den Beobachter ist als für das System. Hysterese anwenden. (Siehe Gouverneur.) Starten Sie die Maschinen schnell, aber schalten Sie sie langsam aus. Das Starten neuer Maschinen ist sicherer als das Abschalten alter Maschinen. Wenn die Lücke zwischen dem erwarteten Zustand und dem beobachteten Zustand groß ist, signalisieren Sie dies zur Bestätigung. Dies entspricht einer großen gelben rotierenden Warnleuchte an einem Industrieroboter. Systeme, die Ressourcen verbrauchen, sollten statusbehaftet genug sein, um zu erkennen, ob sie versuchen, unendlich viele Instanzen hochzufahren. Bauen Sie Verzögerungszonen ein, um den Schwung zu berücksichtigen. Angenommen, Ihre Steuerebene erkennt jede Sekunde eine Überlast, aber es dauert fünf Minuten, bis eine virtuelle Maschine gestartet ist, um die Last zu bewältigen. Es muss sichergestellt werden, dass 300 virtuelle Maschinen nicht gestartet werden, da die hohe Last weiterhin besteht.

Ein schneller Fehler ermöglicht es dem aufrufenden System, die Verarbeitung der Transaktion schnell abzuschließen. Ob dies letztendlich ein Erfolg oder ein Misserfolg ist, hängt von der Anwendungslogik ab. Eine langsame Antwort bindet andererseits Ressourcen im aufrufenden System und im aufgerufenen System.

Speicherverluste treten häufig über langsame Antworten auf, da die virtuelle Maschine immer härter arbeitet, um genügend Speicherplatz für die Verarbeitung einer Transaktion zurückzugewinnen.

Häufiger sehe ich jedoch Anwendungen, bei denen die Sendepuffer ihrer Sockets geleert werden und sich die Empfangspuffer füllen, was zu einem TCP-Stillstand führt. Dies geschieht normalerweise in einem handgerollten Socket-Protokoll auf niedriger Ebene, bei dem die Leseroutine erst dann eine Schleife durchläuft, wenn der Empfangspuffer leer ist.

Viele APIs bieten sowohl einen Aufruf mit Zeitüberschreitung als auch einen einfacheren, einfacheren Aufruf, der für immer blockiert. Es wäre besser, wenn die No-Timeout-Version anstelle einer einzelnen Funktion die Bezeichnung "CheckoutAndMaybeKillMySystem" tragen würde.

Wenden Sie Zeitüberschreitungen auf Integrationspunkte, blockierte Threads und langsame Antworten an. Das Timeout-Muster verhindert, dass Aufrufe von Integrationspunkten zu blockierten Threads werden. Zeitüberschreitungen verhindern somit Kaskadenfehler. Wenden Sie Timeouts an, um unerwartete Fehler zu beheben. Wenn eine Operation zu lange dauert, ist es uns manchmal egal, warum ... wir müssen einfach aufgeben und in Bewegung bleiben. Mit dem Timeout-Muster können wir das tun. Betrachten Sie verzögerte Wiederholungsversuche. Die meisten Erklärungen für eine Zeitüberschreitung betreffen Probleme im Netzwerk oder im Remote-System, die nicht sofort behoben werden können. Sofortige Wiederholungsversuche können das gleiche Problem verursachen und zu einer weiteren Zeitüberschreitung führen. Dadurch wartet der Benutzer nur noch länger auf seine Fehlermeldung. Meistens sollten Sie den Vorgang in die Warteschlange stellen und später erneut versuchen. Leistungsschalter Vor nicht allzu langer Zeit, als elektrische Leitungen zum ersten Mal in Häuser eingebaut wurden, fielen viele Menschen der Physik zum Opfer.

Jetzt schützen Leistungsschalter übereifrige Gerätehunde davor, ihre Häuser niederzubrennen. Das Prinzip ist dasselbe: Übermäßige Nutzung erkennen, zuerst ausfallen und den Stromkreis öffnen.

Noch abstrakter ist der Leistungsschalter vorhanden, damit ein Teilsystem (ein Stromkreis) ausfällt (übermäßige Stromaufnahme, möglicherweise aufgrund eines Kurzschlusses), ohne das gesamte System (das Haus) zu zerstören. Sobald die Gefahr vorüber ist, kann der Leistungsschalter zurückgesetzt werden, um die volle Funktion des Systems wiederherzustellen.
Leaky Bucket-Muster aus Mustersprachen des Programmdesigns Es ist ein einfacher Zähler, den Sie jedes Mal erhöhen können, wenn Sie einen Fehler beobachten. Im Hintergrund dekrementiert ein Thread oder Timer den Zähler regelmäßig (natürlich auf Null). Wenn die Anzahl einen Schwellenwert überschreitet, wissen Sie, dass Fehler schnell eintreffen.

Der Betrieb benötigt eine Möglichkeit, den Leistungsschalter direkt auszulösen oder zurückzusetzen. Der Leistungsschalter ist auch ein praktischer Ort, um Messdaten zu Anrufvolumen und Antwortzeiten zu erfassen.

Leistungsschalter schützen wirksam vor Integrationspunkten, Kaskadenfehlern, unausgeglichenen Kapazitäten und langsamen Reaktionen. Sie arbeiten so eng mit Zeitüberschreitungen zusammen, dass sie Zeitüberschreitungsfehler häufig getrennt von Ausführungsfehlern verfolgen.
Die Bulkheads-Musterpartitions können die Teilfunktionalität beibehalten, wenn schlimme Dinge passieren. Wählen Sie eine nützliche Granularität. Sie können Thread-Pools in einer Anwendung, CPUs in einem Server oder Server in einem Cluster partitionieren. Berücksichtigen Sie Bulkheads insbesondere bei Shared-Services-Modellen. Fehler in serviceorientierten oder Microservice-Architekturen können sich sehr schnell ausbreiten. Wenn Ihr Service aufgrund einer Kettenreaktion ausfällt, kommt das gesamte Unternehmen zum Stillstand? Dann sollten Sie besser ein paar Schotte einsetzen.

Trotzdem wird Ihre kleine Datenbank eines Tages erwachsen. Wenn es die Teenagerjahre trifft - ungefähr zwei in menschlichen Jahren - wird es launisch, mürrisch und ärgerlich. Im schlimmsten Fall wird es das gesamte System untergraben (und es wird sich wahrscheinlich beschweren, dass es auch niemand versteht).

Hier gibt es nur wenige allgemeine Regeln. Viel hängt von der verwendeten Datenbank und den verwendeten Bibliotheken ab. RDBMS plus ORM kann beispielsweise schlecht mit baumelnden Referenzen umgehen, während eine dokumentenorientierte Datenbank dies nicht einmal bemerkt.

Eine Protokolldatei ist wie ein Haufen Kuhdung - nicht sehr wertvoll, und Sie möchten lieber nicht darin stöbern. Sammeln Sie Tonnen von Kuhdung und es wird "Dünger". Wenn Sie genügend Protokolldateien sammeln, können Sie ebenfalls einen Wert ermitteln.
Senden Sie die Protokolldateien an einen zentralen Protokollierungsserver, z. B. Logstash, wo sie indiziert, durchsucht und überwacht werden können.
Für einen Server mit langer Laufzeit ist Speicher wie Sauerstoff. Der Cache, der nicht gepflegt wird, saugt den gesamten Sauerstoff auf. Niedrige Speicherbedingungen gefährden sowohl die Stabilität als auch die Kapazität.

Die unsachgemäße Verwendung des Caching ist die Hauptursache für Speicherverluste, die wiederum zu Schrecken wie täglichen Neustarts des Servers führen. Nichts macht Administratoren zur Gewohnheit, in die Produktion eingeloggt zu werden, wie tägliche (oder nächtliche) Aufgaben.

Stellen Sie auch bei einem schnellen Fehler sicher, dass ein Systemfehler (Ressourcen nicht verfügbar) anders gemeldet wird als ein Anwendungsfehler (Parameterverletzungen oder ungültiger Status). Das Melden einer allgemeinen Fehlermeldung kann dazu führen, dass ein vorgeschaltetes System einen Leistungsschalter auslöst, nur weil ein Benutzer fehlerhafte Daten eingegeben und drei- oder viermal auf Neu laden geklickt hat.

Vermeiden Sie langsame Reaktionen und scheitern Sie schnell. Wenn Ihr System seine SLA nicht einhalten kann, informieren Sie die Anrufer schnell. Lassen Sie sie nicht auf eine Fehlermeldung warten, und lassen Sie sie nicht warten, bis sie eine Zeitüberschreitung haben. Das macht Ihr Problem nur zu ihrem Problem.

Ressourcen reservieren, Integrationspunkte frühzeitig überprüfen. Stellen Sie unter dem Thema "Keine nutzlose Arbeit erledigen" sicher, dass Sie die Transaktion abschließen können, bevor Sie beginnen. Wenn kritische Ressourcen nicht verfügbar sind, z. B. ein ausgefallener Leistungsschalter bei einem erforderlichen Callout, verschwenden Sie keine Arbeit, indem Sie an diesen Punkt gelangen. Die Wahrscheinlichkeit, dass sich die Transaktion zwischen dem Beginn und der Mitte der Transaktion ändert, ist gering.

Manchmal ist es das Beste, was Sie tun können, um Stabilität auf Systemebene zu schaffen, die Stabilität auf Komponentenebene aufzugeben. In der Erlang-Welt wird dies als "Let it Crash" -Philosophie bezeichnet.
Wir müssen in der Lage sein, in diesen sauberen Zustand zurückzukehren und den normalen Betrieb so schnell wie möglich wieder aufzunehmen. Andernfalls wird die Leistung beeinträchtigt, wenn zu viele unserer Instanzen gleichzeitig neu gestartet werden. Im Limit kann es zu einem Dienstausfall kommen, da alle unsere Instanzen gerade neu gestartet werden. Bei In-Process-Komponenten wie Akteuren wird die Neustartzeit in Mikrosekunden gemessen. Es ist unwahrscheinlich, dass Anrufer diese Art von Störung wirklich bemerken. Sie müssten einen speziellen Testfall einrichten, um ihn zu messen.

Akteursysteme verwenden einen hierarchischen Baum von Supervisoren, um die Neustarts zu verwalten. Immer wenn ein Akteur beendet wird, benachrichtigt die Laufzeit den Supervisor. Der Supervisor kann dann entscheiden, den untergeordneten Akteur neu zu starten, alle untergeordneten Akteure neu zu starten oder sich selbst zum Absturz zu bringen. Wenn der Supervisor abstürzt, beendet die Laufzeit alle untergeordneten Elemente und benachrichtigt den Supervisor des Supervisors. Letztendlich können Sie ganze Zweige des Überwachungsbaums dazu bringen, mit einem sauberen Zustand neu zu starten. Das Design des Überwachungsbaums ist ein wesentlicher Bestandteil des Systemdesigns.

Absturzkomponenten zum Speichern von Systemen. Es mag nicht intuitiv erscheinen, durch Instabilität auf Komponentenebene Stabilität auf Systemebene zu schaffen. Trotzdem kann es der beste Weg sein, zu einem Kn zurückzukehren

Die Originalausgabe dieses Buches führte mich in Stabilitätsmuster und ihre bösen Zwillinge ein, Stabilitäts-Antimuster. Ich habe seit dem Lesen unzählige Male auf seine Terminologie verwiesen, insbesondere auf Steady State, Circuit Breaker und Fail Fast. Ich nehme dies immer in meine Liste auf, wenn neuere Entwickler fragen, was sie lesen sollen. Es ist voller Weisheit über verteilte Systeme, die niemand in der Schule unterrichtet. Die Techniken hier machen den Unterschied zwischen Code, der bei der geringsten Brise umkippt, und der Architektur, die Sie durch die Hochsaison Ihres Unternehmens führt, ohne ausgelagert zu werden.

Die zweite Ausgabe baut darauf auf und fügt noch mehr hinzu. Anstatt nur ein neues Kapitel über Docker oder etwas anderes am Ende anzusprechen, wird es komplett überarbeitet und neu organisiert. Die offensichtlichste Änderung ist, dass es wirklich in den Zeitgeist eingebunden zu sein scheint und die neueste Ernte von Open-Source-PaaS-Tools mit einem zutiefst pragmatischen Blick von jemandem abdeckt, der sowohl nachdenkliche Anwendungen von Tools als auch unerfahrene Entwickler gesehen hat, die glänzende Dinge verfolgen. Ich habe besonders den erweiterten Abschnitt zu Deep Networking-Themen (Interconnect) geschätzt. In den Abschnitten zu Bereitstellungen ohne Ausfallzeiten waren gut formulierte Konzepte enthalten, auf die ich zuvor noch nicht gestoßen war, z. B. Gruppierungsschritte unter "Erweiterung" und "Bereinigung". Ich sehe Konzeptualisierungen als einen der nützlichsten Teile beim Lesen dieser Art von Büchern an, da sie Ihnen helfen werden, über Jahre hinweg über diese Ideen zu kommunizieren.

Diese Ausgabe leidet etwas unter dem Second System-Effekt. Trotz einer nahezu identischen Seitenzahl fühlte es sich nicht so konzentriert an und versucht, ein bisschen zu viele verwandte Themen wie Sicherheit und sogar organisatorische Probleme wie Feedback-Schleifen bei der Entscheidungsfindung abzudecken. Ich hätte mir auch mehr Fallstudien gewünscht, weil ich ein Trottel für die Ursachenanalyse von Katastrophen bin. Die einzigen zwei neuen in dieser Ausgabe wurden öffentlich veröffentlicht (Reddit und S3) und enthielten daher nicht so viele saftige Details.

Abgesehen von diesen kleinen Kritikpunkten bleibt dies ein unverzichtbares und unvergleichliches Buch über das Erstellen von Software für die reale Welt.

Dieses Buch hat die Art und Weise, wie ich Software erstelle und bereitstelle, radikal beeinflusst.

Es ist eine Wirbelsturm-Tour durch das Entwerfen von Code, der sich in der Produktion gut verhält, die vielfältigen Möglichkeiten, wie die Interaktion zwischen mehreren Systemen fehlschlagen kann, Bereitstellungsstile, die geplante Ausfallzeiten vermeiden, und Fallstudien, um die Überraschungen zu demonstrieren, die in der realen Welt auftreten.

Für diejenigen, die neue Produktionssoftware entwickeln und bereitstellen, ist das Tempo möglicherweise schwer zu verfolgen, aber diejenigen mit ein wenig Erfahrung werden feststellen, dass dies Erinnerungen auslöst, eine Sprache und einen Rahmen bietet, um die Probleme zu verstehen, auf die Sie in der Produktion gestoßen sind, und Muster um Ihnen bei der Verwaltung dieser Probleme zu helfen, wenn sie erneut auftreten.

Für diejenigen, die die erste Ausgabe von Release it gelesen haben, ist die zweite Ausgabe einen erneuten Besuch wert. In 10 Jahren hat sich viel geändert, und das Buch wurde erheblich aktualisiert, um dies zu berücksichtigen. Ich mag auch die logische Weiterentwicklung des neuen Buchumrisses - Stabilität schaffen, für die Produktion entwerfen, Ihr System liefern.

Ich habe an einem Projekt gearbeitet, bei dem Clouds und Hochverfügbarkeit für relativ kurze Zeit stark genutzt wurden, aber selbst diese Erfahrung hat mir geholfen, dieses Buch zu schätzen.

Das Buch ist älter als der Hype der Entwickler, gibt Ihnen aber dennoch unzählige Vorschläge, wie Sie eine robuste, skalierbare und leicht verständliche Anwendung erstellen können, wenn etwas schief geht: Denken Sie an einen Fehler, jede mögliche Komponente wird ausfallen Produktion. Jede mögliche "gemeinsame" wie externe Systeminteraktion wird unterbrochen. Jede mögliche und unmögliche Situation wird eintreten, und Sie sollten darauf vorbereitet sein: nicht indem Sie versuchen, sie zu beseitigen, sondern indem Sie akzeptieren, dass eine Katastrophe eintreten wird.

Einige der Ratschläge sind etwas veraltet (aber schauen Sie sich den Titel an, das Buch stammt aus dem Jahr 2007!), Und einige von ihnen sind weniger klar, als ich wollte, aber insgesamt ist das Buch hilfreich.

Um ehrlich zu sein, habe ich etwas anderes als erwartet. Was ich suchte, war eine weitere "kontinuierliche Lieferung" - ein Buch über moderne Praktiken zur Verkürzung des Lieferzyklus, gefüllt mit Beispielen / Fällen / Ideen.

In diesem Buch geht es eigentlich um die Gesamtqualität von Softwareprodukten (aus sehr unterschiedlichen Perspektiven betrachtet) und darum, wie sich verschiedene Arten von Fehlern letztendlich auf das Produkt / die Dienstleistung auswirken. Wie Sie sehen können, ist dies ein weitaus umfassenderes (und allgemeineres) Thema. Wenn Sie danach suchen, werden Sie sehr glücklich sein, da das Buch recht anständig geschrieben ist. Ich habe es auch genossen, auch wenn ich nach etwas anderem gesucht habe.

Selbst fast sieben Jahre nach der Veröffentlichung ist das Buch eine Inspirationsquelle für die Entwicklung produktionsfreundlicher Software. Ich wünschte, ich könnte das Buch vor drei Jahren lesen. Es würde mir und meinen Kollegen ein paar schlaflose Nächte bescheren. Das Buch sollte erweitert werden, z. B. Cloud, Software As A Service und sogar DevOps, da sie heutzutage die wichtigsten Änderungstreiber im Release- / Bereitstellungsprozess sind. Auf jeden Fall lesenswert und Daumen hoch.

Sie können anhand des ersten Anwendungsfalls erkennen, dass der Autor mit großen Websites und Java gearbeitet hat. Dennoch enthält das Buch viele nützliche Ratschläge zum Entwerfen von Softwareprojekten in Bezug auf Skalierbarkeit, Transparenz, Anpassungsfähigkeit und einfache Fehlerbehebung. Ich habe den Stil genossen - die Beispiele sind gut ausgewählt und der Detaillierungsgrad ist nicht zu tief, gerade genug, um zu erklären, warum einige Entscheidungen besser sind als die anderen und wie man bei Bedarf ein gutes Urteilsvermögen anwendet.

Dieses Buch ist ein seltenes Juwel. Es ist voller wertvoller Erkenntnisse und in einer sehr guten Sprache verfasst. Das macht dieses Buch nicht nur zu einer wertvollen Informationsquelle, sondern auch zu einer Freude beim Lesen.
Ich würde 10 Starts von 5 möglichen Bewertungen setzen, wenn ich könnte.

Empfehlen Sie es auf jeden Fall jedem Softwareentwickler oder Systemingenieur.

Eine herausragende Karriere in der Softwareentwicklung mit all ihren schwer verdienten Lektionen in einem einzigen, leicht verdaulichen Buch. Lass es los! Ist ein im Wesentlichen praktisches Buch, das auf den vom Autor wahrgenommenen Mangel an Fokus auf die Entwicklung von Software zurückzuführen ist, damit diese in einer Produktionsumgebung ausgeführt werden kann.

Wie würden solche Systeme mit Schwerpunkt für den realen Einsatz aussehen? Er beginnt damit, Stabilitäts-Anti-Muster zu skizzieren. Dies sind schlechte Praktiken, die häufig beim Entwurf von Systemen auftreten, die sie anfälliger machen und infolgedessen den Bedienern weniger Schlaf ermöglichen. Ich habe diese drei Kategorien unterteilt: Codierungsmängel, systemische Effekte und spontane Effekte. Andererseits gibt es auch Stabilitätsmuster, Schemata, die wir implementieren sollten, um Anti-Mustern entgegenzuwirken und unser System robuster zu machen. Fügen Sie beispielsweise unseren Anrufen Zeitüberschreitungen hinzu, indem Sie unter anderem separate Middleware verwenden, um Kopplung und Komplexität zu reduzieren. Diese habe ich klassifiziert in: Selbsterhaltung, systemische Zusammenarbeit und Systemmanagement.

In den folgenden Kapiteln werden wichtige Aspekte eines Systems behandelt, z. B. die Analyse von Best Practices auf verschiedenen Abstraktionsebenen, angefangen beim Bare Metal und den Bits bis hin zur mit dem Endbenutzer interagierenden Anwendung. Wie man Systeme entwickelbar macht, das Chaos als Verbündeten zur Erhöhung der Robustheit nutzt und kontinuierlich einsetzt, um gut funktionierende Systeme und zufriedene Kunden zu gewährleisten.

Alles in allem ist dies ein großartiges Buch, das von allen Software-Ingenieuren gelesen werden sollte, die sich mit komplexen Systemen befassen, insbesondere wenn Sie gerade erst Ihre Karriere beginnen und mehr Verantwortung übernehmen. Ich verspreche Ihnen, dass Sie auf diesen Seiten viel Wert finden werden.

Dies war ein Diskussionsbuch in meiner jetzigen Firma. Als Ausgangspunkt für Gespräche funktionierte es gut genug. Es hatte definitiv einige Herausforderungen. Das Schreiben eines softwarebezogenen Buches impliziert fast bestimmte Technologien. Die Angabe dieser Technologien macht das Buch jedoch fast sofort veraltet, wie in diesem. Aber nur der Umgang mit Konzepten macht das Buch undurchdringlich. Aber nur durch Kapitel zu streifen, macht es nur nervig. Dieses Buch war uneinheitlich, aber es setzte sich für eine bessere Protokollierung und Metrik ein. Wie schlimm könnte es also sein?

Wenn Sie im Bereich der Herstellung von Softwaresystemen tätig sind, haben Sie wahrscheinlich schon von Nygards Buch gehört. Die Leute schwärmen davon, seit es 2007 veröffentlicht wurde.

In diesem Fall war es schon eine Weile auf meiner Liste, aber ohne Dringlichkeit. Dann ging ich zu einer Konferenz, wo ich zwei Sitzungen mit Michael Nygard hörte, in denen er seine Ideen vorstellte. Danach wusste ich, dass ich das Buch sofort bekommen musste.

Lass es los! ist etwas so Seltenes wie ein Buch, das bahnbrechend ist und gleichzeitig das Offensichtliche ausdrückt.

Zunächst macht Nygard den einfachen Punkt, dass wir (dh die Mitarbeiter im Geschäft) uns nur allzu sehr darauf konzentrieren, unsere Systeme für das Bestehen der QS-Tests vorzubereiten und nicht für die Inbetriebnahme. Das sind kaum Neuigkeiten, aber es ist das schmutzige kleine Geheimnis des Geschäfts. Es ist nicht etwas, was du laut sagen sollst. Doch Nygard macht das. Und nicht nur das, er wagt es zu fordern, dass wir es besser machen.

Nachdem er diese Häresie begangen hat, erklärt er weiter, wie wir das tun können.

Er macht das auf zwei Arten. Zuerst präsentiert er uns die Anti-Muster, die uns daran hindern, ein laufendes System in der Produktion zu haben, und dann präsentiert er uns die Muster, die es ermöglichen, sie zu vermeiden. Oder, wenn es nicht möglich ist, sie zu vermeiden, den durch sie verursachten Schaden zu minimieren.

Das ist ein weiteres Thema in Nygards Buch. Das Bestehen darauf, dass das System kaputt geht, und der Fokus auf die Implementierung von Möglichkeiten zur Schadensbegrenzung und -behebung.

Das Buch richtet sich nicht nur an Programmierer, obwohl sie es unbedingt lesen sollten, sondern auch an alle anderen Personen, die auf technischer Ebene an der Entwicklung, Prüfung, Konfiguration und Bereitstellung des Systems beteiligt sind, einschließlich der Personen, die an der Planung dieser Aufgaben beteiligt sind.

Wie die Leute inzwischen vielleicht gedacht haben, ist der Hype um das Buch meiner Meinung nach sehr gerechtfertigt, und ich denke, dass jede Person, die auf diesem Gebiet tätig ist, gut daran tun würde, das Buch zu lesen.

Ich würde sagen, dieses Buch war für mich nur durchschnittlich, aber es gibt einen Grund dafür, der sich aus bereits übernommenen Methoden für den Umgang mit Software ergibt, die von einem Unternehmen stammt, für das ich derzeit arbeite. Aber fangen wir von vorne an.

Ich glaube immer noch, dass das Buch viele nützliche Informationen enthält, aber sie sind eher allgemein gehalten. Sie werden keine echten Codebeispiele, Informationen zu Randfällen usw. finden. Ich war mir dessen vor dem Kauf dieser Position bewusst, aber ich habe das Gefühl, dass viele Informationen in verschiedenen Kapiteln immer wieder wiederholt werden, aber Sie wissen nicht wirklich, wo Sie anfangen sollen. Natürlich werden in dem Buch viele Dinge aus verschiedenen Aspekten der Bereitstellung einer App erwähnt. Wenn man also bei jedem einzelnen genauer sein möchte, hätte das Buch nicht nur 350 Seiten. Meiner Meinung nach ist die auf dem Cover des Buches angegebene Metrik "Fähigkeitsstufe" nicht korrekt (sie zeigt die "Expertenstufe" an).

Ich finde es toll, wie der Autor die Notwendigkeit betont, Dinge zu verhindern, anstatt sie zu heilen, und wie wichtig es ist, die Dinge vor dem Versand gründlich zu überdenken - aber wie ich zu Beginn der Überprüfung festgestellt habe, sind viele der im Buch erwähnten Regeln mehr oder weniger "Natürlich" für mich, wie wir es täglich für die meisten Anwendungen in meinem Unternehmen tun (wie das Sammeln der Protokolle, das Verwenden von Tools zum Überwachen anfälliger Abhängigkeiten usw.).

Ich glaube auch, dass das Lesen dieses Buches in verschiedener Hinsicht für mich von Vorteil war - ich habe erneut den Beweis erhalten, dass die Werkzeuge, Metriken und viele Gewohnheiten, die in dem Projekt verwendet werden, in dem ich derzeit arbeite, ein langer Weg sind und dass ich ' Ich bleibe nicht zurück, also werde ich für den Fall, dass ich irgendwann zu einem neuen wechseln werde, die Fähigkeiten bereits kennen.

Ich würde sagen, dass Sie sich nur dann für das Buch entscheiden sollten, wenn Sie ein bestimmtes Niveau repräsentieren. Ich lese auch gerne Bücher mit Code- / Konfigurationsbeispielen.

Dieses Buch ist fantastisch.

Seien wir ehrlich: Ich bin voreingenommen, weil der Autor ein Freund und Kollege ist und ich einige der Geschichten kenne, die er aus persönlicher Erfahrung erzählt (ich bin sogar anonym in einer davon).

Nygard schreibt sehr gut, nimmt komplexe Konzepte auf, zerlegt sie in ihre Komponenten und überlässt dem Leser wesentliche Erkenntnisse über die Muster, die Probleme verursachen, und die Muster, die sie verhindern können. Der Begriff wird in diesem Buch nie verwendet, aber das Konzept von DevOps liegt der ganzen Sache zugrunde. Nygard spricht über die zentrale Herausforderung bei der Erstellung von Anwendungssoftware im Web-Maßstab. Wie stellen Sie sicher, dass die Dinge, die Sie erstellen, tatsächlich funktionieren, wenn Sie sie in Produktion nehmen? Dabei geht es nicht um Leistungs- oder Sicherheitstests (obwohl diese Dinge wesentlich sind), sondern darum, die Leistung Ihrer Anwendungen im Voraus zu gestalten. Und das bedeutet, wirklich darüber nachzudenken, wie sie interagieren werden und was diese Interaktionen im Maßstab bedeuten werden.

Ich habe dieses Buch zweimal vollständig gelesen und bin ein Dutzend Mal zurückgegangen, um eine Auswahl zu lesen. Ich habe es jedem Webarchitekten empfohlen, den ich kenne. Ich halte es für eine wichtige Lektüre für jeden, der versucht, Webanwendungen maßstabsgetreu zu erstellen.

Ich war mir ziemlich sicher, dass es mir gefallen würde, als ich früh auf folgendes Zitat stieß:

"... Websites werden jetzt voraussichtlich 24 mal 7 mal 365 verfügbar sein." Fußnote: "Dieser Satz hat mich immer gestört. Als Ingenieur erwarte ich, dass er entweder '24 mal 365 'oder '24 mal 7 mal 52' ist."

Dieses Buch enthält viele gute Informationen zum Erstellen von Webanwendungen, die einer sehr hohen Belastung standhalten. Es ist gut geschrieben und er erklärt sehr gut die Gründe, warum unterschiedliche Ansätze besonders gut oder schlecht sind.

Ich habe es einfach nicht fertiggestellt, weil das für mich momentan kein Schwerpunkt ist. Wenn ich jedoch jemals Webanwendungen für Zehntausende von Benutzern entwickle, werde ich auf dieses Buch zurückkommen.

Genial! Muss für jeden gelesen werden, der mit dem Entwerfen und Ausführen weitgehend verteilter (Unternehmens-) Systeme konfrontiert ist (oder sein möchte). Tatsächlich würde ich es jedem Ingenieur empfehlen.

Das Buch enthält viele Geschichten aus dem wirklichen Leben sowie gute Vorschläge, wie Probleme im Voraus hätten gemildert werden können.

Einige meiner Imbissbuden:
- Ressourcenpools enthalten als Möglichkeit Fehler innerhalb defekter Integrationspunkte
(richtig gekocht: geringe Konkurrenz, konfigurierbar, mit Zeitüberschreitungen und Behandlung "Keine freie Ressource gefunden", Fall "Planungsservice zur Zeit nicht verfügbar")
- Kosten für Sitzungen, Deep Links und implizite Kosten für mangelnde Effizienz (z. B. langsam = mehr Streit = langsamer)
- Wir (die IT) dienen dem Geschäft, Architektur ist ein Ausdruck dafür, Schönheit wird abgeleitet

Eines der interessantesten Bücher, die ich kürzlich gelesen habe. Normalerweise ist es ziemlich langweilig, diese Art von Material zu lesen, aber Michael Nygard präsentierte es auf eine reibungslose und manchmal sogar lustige Art und Weise. Inhaltlich wird selbst eine erfahrene Person mit Erfahrung in der Ausführung von Softwaresystemen in der Produktion etwas Interessantes finden. Ich glaube, dass sich Entwickler nach dem Lesen dieses Buches und "Continuous Delivery" von Humble und Farley wirklich auf die Schrecken einer Live-Produktionsumgebung vorbereitet fühlen können.
Ich möchte unbedingt eine zweite Ausgabe dieses Buches sehen, die um Kapitel über Clouds, NoSQL-Datenbanken und andere Dinge erweitert wurde, die nach der Veröffentlichung des Buches im Jahr 2007 populär wurden.

Sehr cooles Buch! Total. Tolle Anwendungsfälle (ich wünschte, es gäbe mehr). Dieses Buch führt Sie in eine andere Welt ein, in der Systeme kaputt gehen, Code schief geht, Benutzer frustriert sind, SLAs verletzt werden: kurz gesagt in die reale Welt :)

Ich denke, Entwickler würden am meisten von diesem Buch profitieren, da wir uns meiner Erfahrung nach oft zu sehr darauf konzentrieren, Code bereitzustellen und Probleme zu lösen, die später, na ja, später auftreten. Ich denke, Produktmanager und Architekten sind in diesem Bereich erfahrener (ich hoffe es!) Und werden daher weniger überrascht sein, aber sie sollten dieses Buch trotzdem lesen.

Erforderliche Lektüre für jeden Entwickler und jede Person. Gelegentlich etwas JVM-zentriert, aber größtenteils generisch genug, um auf die meisten Computersysteme angewendet zu werden. Ich finde es toll, dass viele Kapitel in Muster und Anti-Muster unterteilt sind. Nach 9 Jahren Erfahrung auf dem Gebiet der IT erkannte ich die meisten Muster und Anti-Muster und es freute mich zu sehen, dass jemand sie aufgeschrieben hatte!

Hervorragender Überblick über wichtige Konzepte, wenn Sie Software schreiben möchten, die von vielen Menschen verwendet wird.

Viele Java-Beispiele, aber sie veranschaulichen Muster und Antimuster, über die jeder Programmierer nachdenken sollte, unabhängig von der verwendeten Technologie.

Ich werde es mir wahrscheinlich zur Gewohnheit machen, dieses Buch während meiner gesamten Softwarekarriere regelmäßig zu überfliegen.

Ich dachte, ich würde 5 Sterne holen, während ich das meiste davon lese. Am Ende hatte ich vier, weil ich die letzten Kapitel etwas verwirrend fand. Auf jeden Fall ist das Buch voller Weisheit und ich würde argumentieren, dass es ein Muss ist.