Umgang mit nicht reproduzierbaren Fehlern

Angenommen, Ihr Team schreibt ein Softwaresystem, das (ziemlich überraschend!) Einwandfrei funktioniert.

Eines Tages führt einer der Ingenieure versehentlich einige SQL-Abfragen aus, die einige der DB-Daten ändern, und vergisst es dann.

Nach einiger Zeit entdecken Sie die beschädigten / fehlerhaften Daten und jeder kratzt sich am Kopf, welcher Teil des Codes dies verursacht hat und warum, ohne Erfolg. In der Zwischenzeit besteht der Projektmanager darauf, dass wir den Teil des Codes finden, der ihn verursacht hat.

Wie gehst du damit um?

Es ist klar, dass kein Projektmanager unendlich viel Zeit in ein solches Problem investieren wird. Sie wollen verhindern, dass dieselbe Situation erneut auftritt.

Um dieses Ziel zu erreichen, ist es oft möglich, Maßnahmen zu ergreifen, auch wenn man die Ursache eines solchen Fehlers nicht finden kann

• Erkennen Sie solche Fehler früher, falls sie erneut auftreten
• Verringern Sie die Wahrscheinlichkeit, dass derselbe Fehler erneut auftritt
• Machen Sie das System robuster gegen die spezifische Art von Inkonsistenz

Eine detailliertere Protokollierung, eine genauere Fehlerbehandlung oder eine sofortige Fehlersignalisierung können beispielsweise dazu beitragen, dass derselbe Fehler nicht erneut auftritt oder die Grundursache gefunden wird. Wenn Ihr System das Hinzufügen von Datenbank-Triggern zulässt, können Sie möglicherweise einen Trigger hinzufügen, der das erstmalige Einführen von Inkonsistenzen verhindert.

Überlegen Sie, welche Art von Aktion in Ihrer Situation angemessen ist, und schlagen Sie dies dem Team vor. Ich bin sicher, Ihr Projektmanager wird sich freuen.

Eines Tages führt einer der Ingenieure versehentlich einige SQL-Abfragen aus, die einige der DB-Daten ändern, und vergisst es dann.

Wie von anderen erwähnt, ist es auch eine gute Idee, ein solches Verfahren zu verbieten (wenn Sie Einfluss auf die Funktionsweise des Systems haben). Niemand darf undokumentierte Ad-hoc-Abfragen ausführen, die den Datenbankinhalt ändern. Wenn eine solche Abfrage erforderlich ist, stellen Sie sicher, dass eine Richtlinie zum Speichern der Abfrage zusammen mit dem Ausführungsdatum, dem Namen der Person, die sie ausgeführt hat, und dem Grund, warum sie verwendet wurde, an einem dokumentierten Ort vorhanden ist.

Dies ist kein Fehler

Zumindest nicht in Ihrem Code. Es ist ein Fehler in Ihrem Prozess . Ihr Projektmanager sollte sich mehr Sorgen um Ihren Prozess machen als um Ihren Code.

Wie gehst du damit um?

Ganz einfach, indem Ingenieure keine Änderungen an der Produktion oder an gemeinsam genutzten Entwicklungsdatenbanken vornehmen .

Angenommen, dies ist eine gemeinsame Entwicklungsdatenbank:

Vermeiden Sie im Idealfall, wenn überhaupt möglich, eine gemeinsam genutzte Datenbank . Verwenden Sie stattdessen Datenbanken pro Entwickler, die nur von kurzer Dauer sind. Dies sollte mit Skripten automatisiert werden, da sonst die Testkosten zu hoch werden und ein Anreiz besteht, Dinge nicht zu testen. Sie können diese Datenbanken entweder auf der Workstation des Entwicklers oder auf einem zentralen Server haben.

Wenn Sie aus irgendeinem Grund unbedingt eine gemeinsam genutzte Datenbank haben MÜSSEN, sollten Sie Fixtures verwenden - im Wesentlichen etwas, das die Datenbank jedes Mal, wenn Sie sie verwenden müssen, in einen als funktionierend bekannten Zustand versetzt. Dadurch wird vermieden, dass Entwickler von Änderungen anderer Personen gebissen werden.

Wenn Sie dauerhafte Änderungen an der Datenbank vornehmen müssen, sollten Sie diese in Ihre Quellcodeverwaltung übernehmen . Richten Sie Ihre Datenbank so ein, dass Entwickler nicht die Berechtigung haben, direkt darauf zu schreiben, und verfügen Sie über ein Programm, das Änderungen aus der Quellcodeverwaltung abruft und sie anwendet.

Nach Ihrer Beschreibung, wie Sie Dinge debuggen, hört es sich schließlich so an, als würden Sie CI nicht verwenden . Verwenden Sie CI . Es ist ein bisschen mühsam einzurichten, aber es spart auf lange Sicht SO viel Zeit, ganz zu schweigen davon, dass Sie sich über nicht reproduzierbare Datenbankfehler Sorgen machen. Sie müssen sich jetzt nur noch um Heisenbugs kümmern !

Angenommen, dies ist eine Produktionsdatenbank:

Wenn Ihre Entwickler Produktionsdatenbanken ändern, sind viele Dinge schrecklich schief gelaufen, auch wenn die Änderungen absolut korrekt sind.

Entwickler sollten niemals auf Produktionsdatenbanken zugreifen . Es gibt absolut keinen Grund und so viele Dinge, die sehr, sehr schief gehen können .

Wenn Sie etwas in einer Produktionsdatenbank reparieren müssen, sichern Sie zuerst diese Sicherung, stellen Sie sie auf einer anderen (Entwicklungs-) Instanz wieder her, und spielen Sie dann diese Entwicklungsdatenbank herum. Sobald Sie der Meinung sind, dass Sie einen Fix bereit haben (in der Quellcodeverwaltung!), Führen Sie die Wiederherstellung erneut durch, wenden den Fix an und sehen das Ergebnis. Nachdem Sie die Daten erneut gesichert haben (und im Idealfall gleichzeitige Aktualisierungen verhindert haben), reparieren Sie die Produktionsinstanz im Idealfall über einen Software-Patch.

Wenn Sie etwas in einer Produktionsdatenbank testen müssen ... nein, das tun Sie nicht. Welche Tests Sie auch durchführen müssen, sollten Sie in einer Entwicklungsinstanz durchführen. Wenn Sie Daten für die Tests benötigen, werden diese Daten dort abgerufen.

Eine Produktionsdatenbank sollte über vollständige Zugriffsprotokollierung und rollenbasierte Zugriffskontrollen verfügen. Aus diesem Grund sollten Sie belastbare Beweise dafür haben, wer WANN in die Datenbank aufgenommen hat, um die Aufmerksamkeit vom Code auf eine schlechte Betriebssicherheit zu lenken.

In diesem Fall haben Sie letztendlich die Ursache herausgefunden, aber Ihre Hypothese angenommen, dass Sie es nicht getan haben ...

Analysieren Sie zunächst, was sich geändert hat. Wenn das System zuvor einwandfrei lief, kann ein genauer Blick auf alle kürzlich durchgeführten Aktionen Aufschluss über die Änderung geben, die den Fehler verursacht hat. Überprüfen Sie Ihre Versionskontrolle, CI / Deployment-Systeme und Konfigurationskontrolle systematisch, um festzustellen, ob sich etwas geändert hat. Führen Sie git bisect oder einen äquivalenten Mechanismus aus, um eine binäre Suche durchzuführen. Überprüfen Sie die Protokolle. Suchen Sie nach Protokollen, von denen Sie nicht wissen, dass Sie sie haben. Sprechen Sie mit allen Benutzern, die Zugriff auf das System haben, um festzustellen, ob sie in letzter Zeit etwas unternommen haben. Wenn Sie in diesem Prozess gründlich genug sind, sollte dies für Ihr Problem hoffentlich die vergessenen SQL-Abfragen aufdecken.

Zweitens Instrumentierung. Wenn Sie die Ursache eines Fehlers nicht direkt finden können, fügen Sie eine Instrumentierung hinzu, um Daten zum Problem zu sammeln. Fragen Sie sich, "ob ich diesen Fehler auf Befehl reproduzieren könnte, was ich im Debugger ansehen möchte", und protokollieren Sie das dann. Wiederholen Sie diesen Vorgang nach Bedarf, bis Sie das Problem besser verstanden haben. Fügen Sie, wie von Doc Brown vorgeschlagen, die Protokollierung für die für den Fehler relevanten Zustände hinzu. Fügen Sie Behauptungen hinzu, die beschädigte Daten erkennen. Wenn es sich bei Ihrem Fehler beispielsweise um einen Anwendungsabsturz handelt, fügen Sie einen Mechanismus zur Protokollierung von Abstürzen hinzu. Wenn Sie bereits eine haben, können Sie den Absturzprotokollen Anmerkungen hinzufügen, um den möglicherweise für den Absturz relevanten Status aufzuzeichnen. Überlegen Sie, ob Parallelitätsprobleme vorliegen können, und testen Sie, ob Threadsicherheit gewährleistet ist .

Drittens Ausfallsicherheit. Fehler sind unvermeidlich. Fragen Sie sich daher, wie Sie Ihre Systeme so verbessern können, dass sie widerstandsfähiger sind, sodass die Fehlerbehebung einfacher ist. Könnten Ihre Backups verbessert werden (oder vorhanden sein)? Bessere Überwachung, Failover und Alarmierung? Mehr Redundanz? Bessere Fehlerbehandlung? Abhängige Dienste voneinander entkoppeln? Können Sie Ihre Prozesse rund um den Datenbankzugriff und manuelle Abfragen verbessern? Im besten Fall werden diese Dinge die Konsequenzen Ihres Bugs weniger schwerwiegend machen, und im schlimmsten Fall sind sie wahrscheinlich sowieso gute Dinge, die Sie tun können.

1. Erklären Sie Ihrem Projektmanager, dass die wahrscheinlichste Ursache der manuelle Datenbankzugriff ist.
2. Wenn Sie weiterhin nach dem Code suchen sollen, der dies verursacht hat, schauen Sie sich den Code noch einmal an.
3. Kommen Sie in ein paar Stunden (oder zu einem anderen geeigneten Zeitpunkt) zurück und sagen Sie, dass Sie keinen Code finden können, der dies verursacht hätte. Daher glauben Sie immer noch, dass der wahrscheinlichste Grund der manuelle Datenbankzugriff ist.
4. Wenn sie weiterhin möchten, dass Sie nach dem Code suchen, fragen Sie, wie viel Zeit Sie dafür aufwenden sollen. Erinnern Sie sie subtil daran, dass Sie währenddessen nicht an Feature X, Bug Y oder Enhancement Z arbeiten.
5. Verbringe so viel Zeit, wie sie verlangen. Wenn Sie immer noch der Meinung sind, dass der manuelle Datenbankzugriff die wahrscheinlichste Ursache ist, teilen Sie ihnen dies mit.
6. Wenn Sie weiterhin nach dem Code suchen sollen, eskalieren Sie das Problem, da dies eindeutig zu einer unproduktiven Nutzung der Zeit Ihres Teams geworden ist.

Möglicherweise möchten Sie auch überlegen, ob Sie zusätzliche Prozesse hinzufügen sollten, um die Wahrscheinlichkeit zu verringern, dass der manuelle Datenbankzugriff in Zukunft derartige Probleme verursacht.

Ich arbeitete im Entwicklungsteam für ein Mainframe-Datenbankprodukt, als ein Kunde berichtete, dass er eine beschädigte Datenbank hatte. Eine Beschädigung in dem Sinne, dass der interne Zustand der Bits auf der Platte bedeutete, dass die Datenbank nicht über die Datenbanksoftware lesbar war. In der Mainframe-Welt zahlen Kunden Ihnen Millionen Dollar und Sie müssen dies ernst nehmen. Das haben wir gemacht:

Schritt 0: Helfen Sie dem Kunden, wieder einsatzbereit zu sein, indem Sie die Datenbank reparieren.

Schritt 1: Indem wir die Datei auf der Disc auf hexadezimaler Ebene untersuchten, stellten wir fest, dass die Beschädigung systematisch war: Es gab viele Fälle derselben Beschädigung. Es wurde also definitiv auf der Ebene der Datenbanksoftware verursacht. Es war in der Tat systematisch genug, um Multithreading-Probleme auszuschließen.

Nachdem wir viele andere Theorien beseitigt hatten, beschäftigten wir uns mit einem Dienstprogramm, das zur physischen Reorganisation der Datenbank verwendet werden konnte. Es schien der einzige Code zu sein, der auf der richtigen Ebene Zugriff auf die Daten hatte. Wir haben dann eine Möglichkeit gefunden, dieses Dienstprogramm mit sorgfältig ausgewählten Optionen auszuführen, die das Problem reproduzierten. Der Kunde war nicht in der Lage zu bestätigen oder zu leugnen, dass dies das war, was er getan hatte, aber da dies die einzige Erklärung war, die wir finden konnten, entschieden wir, dass dies die wahrscheinliche Ursache war und sie hatten keine andere Wahl, als unsere Diagnose anzunehmen .

Schritt 2: Wir haben dann zwei Änderungen an der Software vorgenommen: (a) Es wurde schwieriger, diesen Effekt versehentlich durch die Benutzeroberfläche "Ja, ich weiß, was ich tue" hervorzurufen, und (b) eine neue Protokolldatei eingeführt, damit wenn Es ist immer wieder vorgekommen, wir hätten eine Aufzeichnung der Benutzeraktionen.

Im Grunde genommen (a) reparieren Sie den Schaden und stellen Sie den Betrieb wieder her, (b) finden Sie die Ursache, (c) tun Sie alles Notwendige, um ein erneutes Auftreten zu verhindern oder um eine einfache Diagnose zu ermöglichen, falls es erneut auftritt.

Meiner Erfahrung nach möchte Ihr Chef eine gewisse Sicherheit, dass dies nicht wieder vorkommt. Wenn es der Fall ist, dass kein Code die Ursache ist, da dies durch Unity-Tests sichergestellt wird, und Sie davon ausgehen, dass Ihre Codebasis bereits über Testabdeckung verfügt, sollte die Lösung Ihrer Datenbank "testing" hinzufügen. Ich zitiere Don Gilman, denn er hat es geschafft:

Eine Produktionsdatenbank sollte über vollständige Zugriffsprotokollierung und rollenbasierte Zugriffskontrollen verfügen. Aus diesem Grund sollten Sie belastbare Beweise dafür haben, wer WANN in die Datenbank aufgenommen hat, um die Aufmerksamkeit vom Code auf eine schlechte Betriebssicherheit zu lenken.

Sie sollten jedoch auch über die Standardarbeitsanweisung zum Ändern von Daten in der Produktion verfügen. Zum Beispiel sollte kein DBA Daten ändern, kein Entwickler sollte die Änderung selbst ausführen und sie sollten, wie in der SOP definiert, die Änderung per Post oder Ticket formal zueinander verlangen.

Irgendwo muss es ein Zitat wie dieses geben, wenn nicht, kannst du mich darauf zitieren:

Es gibt einen guten Grund, warum Köche nicht für die Reinigung der Toiletten verantwortlich sind.

Es gibt einige Dinge, die mit nicht reproduzierbaren Fehlern erledigt werden müssen.

1. Erstellen Sie ein Ticket dafür

Erstellen Sie ein Ticket und protokollieren Sie alles, was Sie sich im Ticket vorstellen können. Überprüfen Sie auch, ob dieser "Bug" bereits protokolliert wurde, und verknüpfen Sie die Tickets miteinander. Eventuell erhalten Sie genug Tickets, um ein Muster für die Reproduktion des Fehlers zu erstellen. Dies schließt Workarounds ein, mit denen versucht wird, dies zu vermeiden. Auch wenn dies die einzige Instanz ist, wird es bei einem ersten Mal irgendwann ein zweites Mal geben. Wenn Sie die Ursache gefunden haben, schließen Sie das Ticket mit einer Erklärung der Ursache, damit Sie eine genaue Vorstellung davon haben, was passiert ist, wenn es erneut passiert (Fix lost in bad merge).

2. Härtungsanalyse durchführen

Schauen Sie sich das System an, was fehlgeschlagen ist und wie es fehlgeschlagen ist. Versuchen Sie, Bereiche des Codes zu finden, die aktualisiert werden können, um die Wahrscheinlichkeit eines Fehlers zu verringern. Einige Beispiele...

• Ersetzen Sie den Ad - hoc - Code durch einen dedizierten Anruf (wie execute(<query>)beiexecuteMyStoredProcedure(<params>)
• Führen Sie nächtliche Überprüfungsskripts aus, um die Datenintegrität zu überprüfen (sodass dies beim nächsten Mal innerhalb von 24 Stunden erkannt werden kann).
• Hinzufügen / Verbessern der Protokollierung und Archivierung (Sicherung).
• Ändern Sie unzulässige Sicherheitsbeschränkungen (z. B. Personen / Programme, die nur Daten lesen und keine Schreibberechtigung haben; Entwickler, die nicht für die Produktion verantwortlich sind, dürfen sich nicht bei den Produktionsservern anmelden).
• Fügen Sie eine Datenüberprüfung / -bereinigung hinzu, wenn diese fehlt

Dies behebt den Fehler möglicherweise nicht, aber selbst wenn dies nicht der Fall ist, ist das System jetzt stabiler und sicherer, sodass es sich dennoch auszahlt.

3. Fügen Sie Systemwarnungen hinzu

Ein bisschen Teil von 2, aber etwas ist passiert, und Sie müssen wissen, wann es wieder passiert. Sie sollten einige Health-Check-Skripte / -Programme erstellen, um das System zu überwachen, damit Administratoren innerhalb von 24 Stunden nach dem Auftauchen des Fehlers benachrichtigt werden können (je kürzer, desto besser, desto vernünftiger). Dies erleichtert die Bereinigung erheblich. (Beachten Sie, dass das Betriebssystem zusätzlich zu den Protokollen der Datenbanken auch protokollieren sollte, wer sich bei ihr anmeldet, sowie alle nicht gelesenen Aktionen, die sie ausführen. Zumindest sollten Netzwerkprotokolle des Datenverkehrs zu diesem Computer vorhanden sein.)

Ihr Problem wurde nicht durch einen Fehler in Ihrer Software verursacht, sondern durch jemanden, der an der Datenbank herumfummelt. Wenn Sie Dinge, die schief gehen, als "Fehler" bezeichnen, ist Ihr Fehler leicht reproduzierbar: Es wird immer schief gehen, wenn jemand dumme Dinge an der Datenbank tut. Und es gibt Möglichkeiten, diesen "Fehler" zu vermeiden, indem die Datenbank nicht manuell oder mit nicht getesteter Software geändert werden kann und genau kontrolliert wird, wer die Datenbank ändern kann.

Wenn Sie Fehler in Ihrer Datenbank nur als "Fehler" bezeichnen, haben Sie keinen nicht reproduzierbaren Fehler, Sie haben überhaupt keinen Fehler. Möglicherweise haben Sie einen Fehlerbericht, aber Sie haben auch Beweise dafür, dass das Problem nicht durch einen Fehler verursacht wurde. Sie können den Fehlerbericht also nicht als "nicht reproduzierbar", sondern als "beschädigte Datenbank" schließen. Es ist nicht ungewöhnlich, Fehlerberichte zu haben, bei denen die Untersuchung zeigt, dass es keinen Fehler gibt, aber ein Benutzer hat die Software falsch verwendet, die Erwartungen des Benutzers waren falsch usw.

In diesem Fall wissen Sie immer noch, dass es ein Problem gibt, das Sie nicht wiederholen möchten. Führen Sie daher die gleiche Aktion aus wie im ersten Fall.