标签：#sergeyshinder

Die meisten schwerwiegenden Vorfälle, die ich erlebt habe, kamen nicht aus dem eigenen Code. Sie kamen von der Grenze, an der mein System mit einem fremden gesprochen hat. Eine API, die plötzlich langsamer antwortete. Ein Feld, das eines Tages null war, obwohl es das nie sein durfte. Eine Antwort, die kein JSON mehr war, sondern eine HTML-Fehlerseite eines Proxys dazwischen. Aus diesen Erfahrungen ist eine Grundhaltung geworden, die vielleicht misstrauisch klingt, aber pragmatisch gemeint ist: Ich vertraue keiner Schnittstelle, die nicht mir gehört. Und ehrlich gesagt vertraue ich auch den eigenen nur bedingt. Das heißt nicht, dass ich von schlechter Absicht ausgehe. Es heißt, dass ich davon ausgehe, dass alles, was schiefgehen kann, irgendwann schiefgeht, und dass es genau dann passiert, wenn es am schlechtesten passt. Ganz konkret bedeutet das ein paar unverhandelbare Punkte. Jeder ausgehende Aufruf hat ein Timeout. Immer. Ein Aufruf ohne Timeout ist ein Aufruf, der mein ganzes System zum Stillstand bringen kann, weil ein Thread ewig auf jemanden wartet, der nie antwortet. Jede Antwort wird geprüft, bevor ich ihr glaube. Ich lese nicht einfach ein Feld aus, ich frage erst, ob es da ist und ob es sinnvoll ist. Und für Ausfälle des Gegenübers habe ich einen bewussten Plan, sei es ein Wiederholungsversuch mit Verzögerung, ein Fallback oder ein sauberer Fehler nach oben. Was mir am meisten Ruhe gebracht hat, ist die Idee des Circuit Breakers. Wenn ein fremder Dienst offensichtlich am Boden liegt, hört mein System auf, ihn immer wieder anzurufen. Es wartet, gibt ihm Zeit, sich zu erholen, und schützt sich selbst davor, im Warten zu ertrinken. Ein sturer Retry gegen ein totes System macht die Sache für alle nur schlimmer. Integration ordentlich zu machen heißt nicht, Fehler zu verhindern. Das kann ich nicht, denn die andere Seite gehört mir nicht. Es heißt, dafür zu sorgen, dass der Fehler des anderen nicht automatisch mein Fehler wird. Die Grenze zwischen zwei Systemen

In meinem ersten größeren Projekt waren wir stolz auf unsere Alarme. Wir hatten Hunderte davon. Jede Metrik, die uns eingefallen ist, bekam einen Schwellwert und eine Benachrichtigung. Wir dachten, das sei gründlich. In Wahrheit hatten wir uns eine Umgebung gebaut, in der niemand mehr hinschaute. Der Effekt kam schleichend. Erst überflog man die Alarme noch. Dann klickte man sie weg. Am Ende gab es einen eigenen Ordner, in den die ganzen Mails wanderten, ungelesen. Als dann ein echter Ausfall kam, ging seine Meldung im Rauschen unter, genau wie alle anderen. Wir hatten Alarme, aber wir hatten keine Alarmierung mehr. Das ist ein Unterschied. Seitdem behandle ich Alarme mit einer fast strengen Sparsamkeit. Meine Leitfrage lautet: Wenn dieser Alarm nachts losgeht, würde ich wollen, dass jemand aufsteht? Wenn die Antwort nein ist, dann ist es kein Alarm. Dann ist es höchstens ein Eintrag in einem Dashboard, das man morgens anschaut. Diese Trennung zwischen „jemand muss jetzt handeln" und „das ist zur Kenntnis" hat unsere Bereitschaft gerettet. Der zweite Grundsatz ist, auf Symptome zu alarmieren, nicht auf Ursachen. Nutzer merken nicht, dass eine CPU bei achtzig Prozent liegt. Sie merken, dass die Seite langsam ist oder Fehler zurückkommt. Also alarmiere ich auf das, was der Nutzer spürt: Latenz, Fehlerrate, gescheiterte Anfragen. Die hohe CPU ist dann eine Information für die Diagnose, kein Grund, jemanden zu wecken. Oft löst sich eine hohe Auslastung von selbst, ohne dass ein Mensch je etwas tun müsste. Am meisten hat mir geholfen, jeden Alarm mit einer ehrlichen Verfallsprüfung zu versehen. Alle paar Wochen gehe ich die Liste durch und frage bei jedem einzelnen: Ist der schon mal losgegangen? Hat daraufhin jemand etwas getan? Wenn ein Alarm seit Monaten nur Lärm macht und nie zu einer Handlung geführt hat, dann löse ich ihn auf. Das fühlt sich mutig an, ist aber das Gegenteil. Ein Alarm, dem niemand traut, schützt niemanden. Gutes Monitoring erkennt man nicht an der