Am 07.02.2018 war KreditSmart für viele Vermittler nur eingeschränkt benutzbar. Anfragen waren sporadisch sehr langsam oder funktionierten gar nicht. Unser Team bei EUROPACE erhielt entsprechende Hinweise durch Zendesk. Insgesamt dauerte der Incident ca. 4 Stunden, bis KreditSmart wieder wie gewohnt funktionierte.
Wie kam es dazu und was werden wir zukünftig tun, um solche Unannehmlichkeiten für unsere Nutzer zu vermeiden?
Vermehrte Hinweise auf Probleme
Am Vormittag um ca. 11 Uhr bemerkten einige unserer Mitarbeiter und unsere Nutzer, dass KreditSmart langsamer als gewohnt arbeitete. Die Symptome waren leider nur sporadisch sichtbar, und unser Monitoring und die Logs zeigten keine besonderen Auffälligkeiten.
Da nach und nach unsere Nutzer immer mehr Tickets erstellten, wurden mehr Teammitglieder zur Analyse des Problems herangezogen. Wir konnten mit Hilfe von TrackJS zumindest die Wahrnehmung der Nutzer bestätigen, dass Requests zu unseren Backends langsam waren und auch in Timeouts liefen. Diesmal war die Ursache jedoch nicht die gleiche wie beim letzten Incident, denn dann wären wir schon durch unser Monitoring darauf aufmerksam gemacht worden.
Reaktion 1: Rollback
Ein erster Verdacht fiel auf eine Änderung vom Vortag, die möglicherweise Einfluss auf das Connection Management unserer Services hatte. Um diese als Ursache auszuschließen wurde eine Vorversion deployed. Leider ergab dies keine Verbesserung, so dass als weitere Maßnahme einige Services abgeschaltet wurden, die für den Betrieb von KreditSmart keine elementare Rolle spielen und für kurze Zeiträume pausieren können. Außerdem wurden einige Services neu gestartet.
Reaktion 2: VM-Restart
Eine unserer Nodes war immer noch unter hoher Last, so dass wir diese neu starteten. Leider traten daraufhin neue Fehler auf, die auf Probleme beim DNS-Lookup hinwiesen. Die Ursache war ein nicht gestarteter lokaler DNS-Cache, was sich schnell beheben ließ. Danach lief KreditSmart wieder, allerdings noch träge und wir beobachteten eine erhöhte Anzahl von Connections.
Reaktion 3: Skalierung auf weitere Nodes
Um für die Nutzer wieder eine akzeptable Verfügbarkeit zu erreichen, wurden die Kern-Services von KreditSmart auf weitere Nodes skaliert. Durch die breitere Lastverteilung beruhigte sich das System wieder und wir konnten in TrackJS auch eine Verringerung der Fehlerrate beobachten. Der Incident war damit behoben.
Post Mortem und Learnings
Nach solchen Incidents kommen alle Beteiligten zusammen und betrachten sowohl den Verlauf als auch mögliche Problemursachen, um in Zukunft besser und schneller reagieren zu können.
Im konkreten Fall hatten wir ursprünglich zwar eine Codeänderung verdächtigt, aber erst die Skalierung auf mehr Nodes führte zur Besserung. In der Nachbetrachtung fiel uns auf, dass wir schon vor dem für Nutzer wahrnehmbaren Incident durch unser Monitoring hätten alarmiert werden können: Die träge Latenz von Requests war schon früher erkennbar und wir konnten eine ungewöhnlich hohe Zahl an JVM Threads feststellen - allerdings hatten wir versäumt entsprechende Metriken ins Monitoring aufzunehmen. Dies holen wir umgehend nach und werden auch andere Basis-Metriken berücksichtigen, falls diese noch nicht monitored werden. Googles SRE Book wird uns dabei eine Hilfe sein, genauso wie die Hinweise im Artikel Monitoring and Observability with USE and RED.
Wir können also derzeit keine konkrete Ursache nennen, sondern nur erhöhte Last oder temporäre Probleme auf einigen Nodes als mögliche Auslöser heranziehen.
Als weitere Aktion ergänzen wir nicht nur unser Monitoring, sondern bereiten auch weitere Nodes vor, auf denen KreditSmart mit seinen Microservices laufen kann. Weitere Optimierungen betreffen den Deployment-Prozess, den wir beschleunigen wollen, um noch schneller auf Probleme reagieren zu können.