Gastbeitrag.

Als freiberuflicher Entwickler ist die Übernahme bestehender Projekte ein notwendiges Übel. Fast jedes Projekt enthält Altcode, den das Team nur ungern anrührt. Übernimmt man jedoch als Freiberufler ein Projekt, besteht die gesamte Codebasis meist aus Altcode. Der Umgang mit einer unbekannten Codebasis ist zwar schon schwierig genug, doch noch schwieriger ist es, diese Codebasis in einer Produktionsumgebung zum Laufen zu bringen.

Ratespiele

Letzten Oktober übernahm ich ein Projekt, das mich fast in den Wahnsinn trieb. Der Quellcode selbst war in einem desolaten Zustand, aber was das Projekt zu einem solchen Albtraum machte, war die mangelnde Dokumentation und Kommunikation der vorherigen Entwickler. Das zwang mich dazu, die Anwendung per Reverse Engineering zu analysieren, um sie in der neuen Produktionsumgebung zum Laufen zu bringen.

Im Grunde habe ich bei der Architektur geraten. Ich hatte zwar eine ungefähre Vorstellung davon, welche Ressourcen ich benötigen würde, aber ohne die Website den Nutzern präsentieren zu können, wusste ich nicht, was mich erwarten würde. Wie Sie sich sicher denken können, ging das nicht gut aus. Aufgrund ineffizienter Programmiermuster benötigte die Website viermal so viele Ressourcen wie nötig, um überhaupt ein Mindestmaß an Stabilität zu erreichen.

Zum Glück hatte ich als eine der ersten Maßnahmen Incident-Management-Tools in das Projekt integriert. Dadurch konnte ich frühzeitig und regelmäßig spezifische Schwachstellen erkennen und umgehend beheben. Dies führte zu strategischen Ressourcen- und Projektoptimierungen, die die Stabilität des Projekts verbesserten.

Was genau habe ich also gesehen?

Obwohl ich das Gefühl hatte, ständig mit einem halben Dutzend Problemen gleichzeitig zu kämpfen, gab es zwei, die so selten auftraten, dass ich ihre Auswirkungen nicht bemerkt hätte, wenn ich keine Tools für das Vorfallmanagement eingesetzt hätte: Datenbanksperrung Und Speicherprobleme Dies sind zwei relativ häufig auftretende Entwicklungsprobleme, die jedoch trotz ihrer Häufigkeit schwer zu diagnostizieren und zu lösen sein können.

Datenbanksperrung

Nach der Stabilisierung des Produktionsstandorts stellten wir als Erstes fest, dass die Website stündlich, zur vollen Stunde, für jeweils etwa 15 Minuten abstürzte. Dank der Informationen unserer Tools für das Vorfallmanagement Ich konnte das Problem auf einen stündlichen Cronjob eingrenzen. Dabei stellte ich fest, dass ein kritischer Cronjob bei jeder Ausführung eine primäre Datenbanktabelle sperrte und die Website dadurch bis zum Abschluss des Prozesses lahmlegte. Dies ermöglichte mir eine einfache Umstrukturierung des betreffenden Skripts, wodurch ich die Verfügbarkeit der Website erhöhen und die Frustration der Nutzer verringern konnte.

Speicherprobleme

Speicherlecks sind echt nervig. In komplexen Anwendungen sind sie oft extrem schwer aufzuspüren – vor allem in der Produktionsumgebung. Leider war mein Projekt voll davon. Manche lassen sich leicht beheben, wie zum Beispiel Logeinträge, die anzeigen, dass dem Redis-Server der Speicher ausgeht (hier einfach mehr Speicher hinzufügen), aber andere sind ziemlich knifflig.

Ein häufiges und scheinbar zufälliges Speicherproblem waren Timeouts. Gelegentlich stürzte die Website nach etwa fünf Minuten Ladezeit ab. Erfahrungsgemäß vermutete ich ineffiziente Datenbankabfragen, doch die genauen Abfragen zu identifizieren, gestaltete sich schwierig. Dank des von mir implementierten Incident-Management-Systems konnte ich schließlich eine bestimmte Gruppe von Profilseiten ausfindig machen, deren Datenabruf aus der Datenbank fast eine halbe Stunde dauerte. Da dieser Vorgang zu lange dauerte, luden die Nutzer die Seite immer wieder neu und starteten den gesamten Prozess von vorn.

Als Erstes konnte ich genau feststellen, wie lange die Nutzer warteten, bevor sie die Seite neu luden oder aufgaben (etwa eine Minute). Anschließend habe ich die Konfigurationen des Web- und Datenbankservers so angepasst, dass nach einer Minute alle Prozesse abgebrochen wurden. Dadurch hatte ich etwas Spielraum, sodass die betroffenen Seiten den Rest der Website nicht zum Absturz brachten.

Anschließend musste ich die genauen Abfragen identifizieren, die die Probleme verursachten. Leider waren diese Seiten sehr abfrageintensiv, aber nach Durchsicht der Protokolle konnte ich das Problem auf eine bestimmte Zeile eingrenzen, die über 1 GB Daten vom Datenbankserver abfragte, ohne das Ergebnis zwischenzuspeichern. Daraufhin bestanden die nächsten Schritte darin, die Abfrage zu überarbeiten, das Ergebnis für eine angemessene Zeit zwischenzuspeichern und die Korrektur so schnell wie möglich für die Benutzer bereitzustellen.

Dies sind nur einige Beispiele für Probleme, die ich dank meiner historischen Daten zum Störungsmanagement lösen konnte. Hätte ich die Tools nicht frühzeitig implementiert, würde ich wahrscheinlich immer noch verschiedene Lösungen ausprobieren. Verstehen Sie mich nicht falsch: Dieselben Störungsmanagement-Tools lassen sich auch zur Planung von Upgrades für eine gut strukturierte Anwendung nutzen. Die Identifizierung der Umstände, unter denen Ihre Server überlastet sind oder es zu Leistungseinbußen kommt, ist entscheidend für die Zukunft. Skalierung Ihres Projekts um dem Wachstum gerecht zu werden.

Erfahren Sie mehr darüber, wie Sie Muster in all Ihren Systemdaten visualisieren können, um das Vorfallmanagement zu verbessern, indem Sie die PagerDuty Operations Command Console besuchen.