7 Debugging-Techniken zur Beschleunigung der Fehlerbehebung in der Produktion

Die Bereitstellung von Produktionsunterstützung für eine Anwendung ist einer der herausforderndsten Aspekte der Softwareentwicklung. Entwickler werden dem Wartungsteam zugeordnet und arbeiten an der Behebung von Fehlern in der Anwendung. Sie sind aber auch im Falle eines Produktionsausfalls auf Abruf verfügbar und arbeiten in diesem Fall daran, die Anwendung so schnell wie möglich wieder zum Laufen zu bringen.

Dieser Artikel zielt darauf ab, eine Reihe kuratierter Empfehlungen bereitzustellen, damit Sie Fehler in der Produktion verhindern und Probleme viel schneller finden können. Die Handhabung dieser Anwendungen in der Produktion ist eine komplizierte Aufgabe: Oft ist keine Dokumentation verfügbar, die Anwendung wurde in einem Legacy-Technologie-Stack geschrieben oder beides. Es gibt nur sehr wenige Schulungen, und es kommt häufig vor, dass Sie angerufen werden, um Unterstützung für eine Anwendung zu leisten, über die Sie wenig wissen.

Viele Entwickler haben keine Erfahrung im Umgang mit einer Anwendung in der Produktion. In Produktionsumgebungen treten eine Reihe von Problemen auf, die Fehler und Ausfälle verursachen und dem Unternehmen im Allgemeinen Tausende und manchmal Millionen von Dollar an entgangenen Einnahmen verursachen. Da die Mehrheit der Entwickler der Umwelt nicht ausgesetzt ist, machen sie außerdem immer wieder einige Fehler, die wiederum diese Probleme verursachen. Diese Liste von Tipps sollte Ihren Job weniger schmerzhaft machen, indem Sie aus der Produktionserfahrung lehren.

Tipp Nr. 1: Entfernen oder automatisieren Sie die gesamte Konfiguration, die für die Ausführung der Anwendung erforderlich ist.

Wie viel Konfiguration ist erforderlich, um die Software auf einem neuen Server zu installieren? In der Vergangenheit konnte dies jedes Mal, wenn ein neuer Entwickler im Team war, manchmal drei Tage dauern. Die Installation der Anwendung würde viele Schritte erfordern, die manuell durchgeführt werden müssen. Im Laufe der Zeit entwickelt sich Software zu neuen Versionen, die mit diesen Anweisungen nicht mehr kompatibel sind, und natürlich werden Anweisungen normalerweise nicht aktualisiert. Plötzlich verbringen Sie viel mehr Zeit als nötig, nur um die Anwendung zum Laufen zu bringen.

Mit dem Aufkommen der Containerisierung ist es viel einfacher geworden, eine Möglichkeit bereitzustellen, eine Anwendung in kürzester Zeit zum Laufen zu bringen, ohne Konfiguration und mit dem zusätzlichen Vorteil, dass Sie viel weniger laufen, da das Docker-Image in sich geschlossen ist Risiko von Problemen mit verschiedenen Versionen des verwendeten Betriebssystems, Sprachen und Frameworks.

Vereinfachen Sie außerdem die Entwicklereinrichtung, sodass die Einrichtung und Ausführung, einschließlich der IDE-Einrichtung, nicht viel Zeit in Anspruch nehmen. Ein Entwickler sollte in der Lage sein, in weniger als 30 Minuten von Null auf Helden zu kommen.

Wenn ein Produktionsproblem auftritt, sind Ihre besten Experten manchmal nicht verfügbar (z. B. Urlaub oder Krankheit), und Sie möchten, dass jeder, dem Sie das Problem antun, es schnell lösen kann.

Tipp Nr. 2: Tappen Sie nicht in die Tech-Stack-Suppenfalle.

Je weniger Technologien verwendet werden, desto besser. Natürlich muss man manchmal das richtige Werkzeug für den Job verwenden. Achten Sie jedoch darauf, nicht mit „richtigen Werkzeugen“ zu überladen. Sogar das Trinken von Wasser kann zu ernsthaften Gesundheitsproblemen führen, wenn Sie es zu viel tun. Jede neue Sprache und jedes Framework, das dem Tech-Stack hinzugefügt wird, muss einen klar definierten Entscheidungsprozess unter sorgfältiger Berücksichtigung der Auswirkungen durchlaufen.

• Fügen Sie keine neue Framework-Abhängigkeit hinzu, nur weil Sie eine StringUtils -Klasse benötigen.
• Fügen Sie keine komplett neue Sprache hinzu, nur weil Sie ein schnelles Skript zum Verschieben von Dateien schreiben müssen.

Ein großer Haufen Abhängigkeiten kann Ihnen das Leben schwer machen, wenn Bibliotheken inkompatibel werden oder wenn Sicherheitsbedrohungen entweder in den Frameworks selbst oder in ihren transitiven Abhängigkeiten gefunden werden.

Denken Sie außerdem daran, dass zusätzliche Stack-Komplexitäten es schwierig machen, neue Entwickler für das Team zu finden und zu schulen. Menschen wechseln in neue Rollen in anderen Unternehmen, und Sie müssen neue finden. Die Fluktuation ist in Ingenieurteams sehr hoch, selbst in Unternehmen, die für ihre großartigen Vergünstigungen und Work-Life-Balance-Leckereien bekannt sind. Sie möchten das neue Teammitglied so schnell wie möglich finden. Jede neue Technologie, die dem Technologie-Stack hinzugefügt wird, verlängert die Zeit, um einen neuen Kandidaten zu finden, und hat das Potenzial, Neueinstellungen immer teurer zu machen.

Tipp Nr. 3: Die Protokollierung muss Sie anleiten, das Problem zu finden, und darf Sie nicht mit nutzlosen Details ertränken.

Die Protokollierung ist Kommentaren sehr ähnlich. Es ist notwendig, alle wichtigen Entscheidungen zu dokumentieren, die getroffen werden, sowie alle Informationen, die Sie in Ihren Debugging-Techniken verwenden können. Es ist nicht einfach, aber mit ein wenig Erfahrung ist es möglich, einige mögliche Szenarien von Produktionsausfällen zu skizzieren und dann die notwendige Protokollierung vorzunehmen, um zumindest das zu lösen. Natürlich entwickelt sich die Protokollierung zusammen mit der Codebasis, je nachdem, welche Art von Problemen auftaucht. Im Allgemeinen sollten Sie 80 % Ihrer Protokollierung auf die wichtigsten 20 % Ihres Codes verwenden – den Teil, der am häufigsten verwendet wird. Wichtige Informationen sind beispielsweise Werte von Argumenten, die an eine Methode übergeben werden, Laufzeittypen von untergeordneten Klassen und wichtige Entscheidungen, die von der Software getroffen wurden – das heißt, der Zeitpunkt, an dem sie an einem Scheideweg stand und entweder links oder rechts wählte.

Tipp Nr. 4: Gehen Sie mit unerwarteten Situationen um.

Stellen Sie sehr klar dar, was die Annahmen des Codes sind. Wenn eine bestimmte Variable immer die Werte 2, 5 oder 7 enthalten soll, stellen Sie sicher, dass sie vom Typ Enum ist und nicht vom Typ Int. Die häufigste Ursache für große Produktionsausfälle ist das Scheitern einer bestimmten Annahme. Alle suchen das Problem an der falschen Stelle, weil sie manche Dinge für selbstverständlich halten.

Annahmen sollten ausdrücklich dokumentiert werden, und alle Abweichungen von diesen Annahmen sollten genügend Alarm auslösen, damit das Produktionsunterstützungsteam die Situation schnell beheben kann. Es sollte auch Code geben, der verhindert, dass Daten in einen ungültigen Zustand übergehen, oder in diesem Fall zumindest eine Art Warnung erzeugt. Wenn bestimmte Informationen in einem Datensatz gespeichert werden sollen und plötzlich zwei Datensätze vorhanden sind, sollte eine Warnung ausgelöst werden.

Tipp Nr. 5: Es sollte einfach sein, ein Problem zu replizieren, das einem Kunden passiert.

Einer der schwierigsten Schritte ist immer, das Problem zu replizieren, mit dem der Kunde konfrontiert ist. Oft verbringen Sie 95 % der Zeit damit, das Problem zu replizieren, und sobald Sie es replizieren können, ist es eine Frage von Minuten, es zu patchen, zu testen und bereitzustellen. Daher sollte der Anwendungsarchitekt sicherstellen, dass Probleme äußerst einfach und schnell repliziert werden können. Vieles davon geschieht, weil der Entwickler einen erheblichen Umfang an Anwendungskonfigurationen vornehmen muss, um in dieselbe Situation zu gelangen, in der sich der Kunde befindet. Es sind viele Aufzeichnungen gespeichert, die zusammen die Situation des Kunden verschlimmern – das Problem besteht darin, dass Sie als Entwickler genau erraten müssen, was der Kunde getan hat. Und manchmal haben sie eine Reihe von Schritten ausgeführt, von denen sie sich nur an den letzten erinnern.

Außerdem erklärt der Kunde das Problem in betriebswirtschaftlichen Begriffen, die der Entwickler dann in technische Begriffe übersetzen muss. Und wenn der Entwickler weniger Erfahrung mit der Anwendung hat, wird er nicht nach den fehlenden Details fragen können, da er die fehlenden Details noch nicht einmal kennt. Das Kopieren der gesamten Produktionsdatenbank auf Ihre Maschine ist nicht machbar. Es sollte also ein Tool geben, um schnell nur die wenigen Datensätze aus der Produktionsdatenbank zu importieren, die zur Simulation der Situation erforderlich sind.

Angenommen, der Kunde hat ein Problem mit dem Bestellbildschirm. Möglicherweise müssen Sie einige ihrer Bestellungen, ihren Kundendatensatz, einige Bestelldetaildatensätze, Bestellkonfigurationsdatensätze usw. importieren. Dann können Sie das in eine Datenbank innerhalb einer Docker-Instanz exportieren, diese Instanz starten und schon sind Sie fertig das Gleiche sehen, was der Kunde sieht. All dies sollte natürlich mit der entsprechenden Sorgfalt erfolgen, um sicherzustellen, dass kein Entwickler Zugriff auf sensible Daten hat.

Tipp Nr. 6: Es sollte offensichtlich sein, wo die Breakpoints in der Anwendung platziert werden.

Wenn Sie einen Kundenbildschirm haben, sollte es ein Kundenobjekt geben, in dem Sie die Haltepunkte platzieren können, um ein Problem auf diesem Bildschirm zu debuggen. Manchmal geraten Entwickler ins Abstraktionsfieber und lassen sich unglaublich schlaue Konzepte einfallen, wie man mit den Ereignissen der Benutzeroberfläche umgeht. Stattdessen sollten wir uns immer auf das KISS-Prinzip (Keep it Simple, St— er, Silly) verlassen und pro UI-Event eine leicht auffindbare Methode haben. Ebenso sollte es für Batch-Verarbeitungsjobs und geplante Aufgaben eine einfache Möglichkeit geben, zu erkennen, wo sich Haltepunkte befinden, um zu beurteilen, ob dieser Code funktioniert oder nicht.

Tipp Nr. 7: Stellen Sie sicher, dass alle externen Abhängigkeiten explizit dokumentiert sind.

Idealerweise tun Sie dies in der README-Datei innerhalb des Quellcodeverwaltungssystems, damit die Dokumentation nicht verloren gehen kann. Dokumentieren Sie alle externen Systeme, Datenbanken oder Ressourcen, die verfügbar sein müssen, damit die Anwendung ordnungsgemäß ausgeführt werden kann. Beachten Sie auch, welche davon optional sind, und fügen Sie Anweisungen hinzu, wie Sie damit umgehen, wenn sie optional und nicht verfügbar sind.

Jenseits von Debugging-Techniken

Sobald diese Empfehlungen bei der Erstellung neuer Funktionen oder der Wartung eines Systems befolgt werden, wird der Produktionssupport viel einfacher und Ihr Unternehmen wird viel weniger Zeit (und Geld) aufwenden. Wie Sie bereits wissen, ist Zeit bei der Behebung von Produktionsfehlern und -abstürzen von entscheidender Bedeutung – jede Minute, die eingespart werden kann, macht unterm Strich einen großen Unterschied. Viel Spaß beim Codieren!