Gästeeintrag.

Als freiberuflicher Entwickler ist das Erben von Projekten ein notwendiges Übel. Fast jedes Projekt hat Legacy-Code, den das Team nicht anfassen möchte. Wenn Sie jedoch als Freiberufler ein Projekt erben, ist meistens die gesamte Codebasis „Legacy“. Während der Umgang mit einer unbekannten Codebasis schwierig ist, kann es noch schwieriger sein, diese Codebasis in einer Produktionsumgebung zum Laufen zu bringen.

Ratespiele

Letzten Oktober habe ich ein Projekt geerbt, das mich fast in den Wahnsinn getrieben hat. Der Quellcode selbst war definitiv ein Chaos, aber was das Projekt zu einem Albtraum machte, war der Mangel an Dokumentation und Kommunikation mit den vorherigen Entwicklern. Dies führte dazu, dass ich die Anwendung zurückentwickeln musste, um sie in der neuen Produktionsumgebung zum Laufen zu bringen.

Ich habe im Grunde genommen ein Ratespiel mit der Architektur gespielt. Ich hatte eine Vorstellung davon, welche Ressourcen ich bereitstellen musste, aber ohne sie den Benutzern vorzustellen, wusste ich wirklich nicht, was mich erwarten würde. Wie Sie sich sicher vorstellen können, endete das nicht gut. Aufgrund ineffizienter Programmiermuster benötigte die Site viermal so viele Ressourcen wie nötig, um ein Mindestmaß an Stabilität zu erreichen.

Zum Glück war eines meiner ersten Dinge, einige Tools für das Vorfallmanagement in das Projekt zu integrieren. So konnte ich bestimmte Schwachstellen frühzeitig und häufig erkennen und sofort beheben. Dies führte zu strategischen Ressourcen- und Projekt-Upgrades, um die Stabilität des Projekts zu verbessern.

Also, was genau habe ich gesehen?

Während ich mich ständig wie beim Maulwurfspiel fühlte, bei dem ich ein halbes Dutzend Probleme gleichzeitig hatte, traten zwei davon so selten auf, dass ich ihre Auswirkung nicht bemerkt hätte, wenn ich keine Tools zur Vorfallverwaltung integriert hätte: Datenbanksperre Und Speicherprobleme . Dies sind zwei relativ häufige Entwicklungsprobleme, die auftreten können. Obwohl sie häufig vorkommen, sind sie mitunter schwer zu diagnostizieren und zu lösen.

Datenbanksperre

Nachdem wir die Produktionsseite stabilisiert hatten, fiel uns als erstes auf, dass die Seite jede Stunde für jeweils etwa 15 Minuten abstürzte. Dank der Informationen unserer Tools zur Vorfallverwaltung konnte ich das Problem auf einen stündlichen Cron-Job eingrenzen. Ich fand heraus, dass ein kritischer Cron-Job bei jeder Ausführung eine primäre Datenbanktabelle sperrte und die Site damit praktisch lahmlegte, bis der Vorgang abgeschlossen war. Dies veranlasste mich dazu, dieses spezielle Skript einfach umzugestalten, wodurch ich die Verfügbarkeit der Site erhöhen und die Frustration der Benutzer verringern konnte.

Speicherprobleme

Speicherlecks sind ärgerlich. In einer komplizierten Anwendung können sie unglaublich schwer aufzuspüren sein – insbesondere, wenn sie in einer Produktionsumgebung auftreten. Leider war dieses Projekt bis zum Rand mit ihnen gefüllt. Einige sind leicht zu beheben, wie z. B. Protokolleinträge, die zeigen, dass dem Redis-Server der Speicher ausgeht (fügen Sie hier mehr Speicher ein), aber andere können ziemlich schwer zu finden sein.

Ein häufiges und scheinbar zufälliges Speicherproblem waren Timeouts. Gelegentlich kam es bei Benutzern zu Timeouts, nachdem der Ladevorgang fünf Minuten gedauert hatte. Obwohl ich aus Erfahrung wusste, dass dies wahrscheinlich durch ineffizientere Datenbankabfragen verursacht wurde, war es eine ziemliche Herausforderung, die genauen Abfragen einzugrenzen. Auch hier war es mir dank des von mir eingerichteten Vorfallmanagement-Frameworks möglich, eine bestimmte Gruppe von Profilseiten zu identifizieren, die fast eine halbe Stunde brauchten, um Daten aus der Datenbank abzurufen. Da dieser Vorgang zu lange dauerte, luden Benutzer die Seite immer wieder neu und starteten den gesamten Vorgang neu.

Als erstes konnte ich genau feststellen, wie lange die Benutzer warteten, bevor sie die Seite neu luden oder aufgaben (etwa 1 Minute). Dann nahm ich einige Änderungen an der Web- und Datenbankserverkonfiguration vor, um alles nach 1 Minute zu beenden. Dies verschaffte mir etwas Luft zum Atmen, sodass diese Seiten nicht den Rest der Site zum Absturz brachten.

Dann musste ich die genauen Abfragen identifizieren, die die Probleme verursachten. Leider waren diese Seiten ziemlich abfrageintensiv, aber nach einem Blick in die Protokolle konnte ich es auf eine bestimmte Zeile eingrenzen, die über 1 GB Daten vom Datenbankserver abfragte, ohne das Ergebnis zwischenzuspeichern. Von hier aus bestanden die nächsten Schritte darin, die Abfrage umzugestalten, das Ergebnis für eine angemessene Zeit zwischenzuspeichern und den Fix so schnell wie möglich an die Benutzer weiterzugeben.

Dies sind nur einige Beispiele für die Probleme, die ich dank meiner historischen Incident-Management-Daten lösen konnte. Hätte ich das Toolset nicht frühzeitig implementiert, würde ich wahrscheinlich immer noch mit verschiedenen Lösungen raten und prüfen. Verstehen Sie mich aber nicht falsch. Dieselben Incident-Management-Tools können auch verwendet werden, um Upgrades für eine gut konzipierte Anwendung zu planen. Die Identifizierung der Umstände, unter denen Ihre Server überlastet sind oder die Dinge langsamer werden, ist entscheidend für Skalierung Ihres Projekts um dem Wachstum Rechnung zu tragen.

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