Apploggar och telemetri behövs för att förstå varför en användare inte kunde slutföra sitt arbete. Men mer insamling ger inte automatiskt bättre felsökning. Om varje fel innehåller hela formulär och råa nätverksanrop kan loggsystemet bli en ny samling av uppgifter som få behöver se och som är svår att hantera när något går fel.
I en påhittad bokningsportal misslyckas vissa ombokningar när en extern kalender svarar långsamt. Teamet behöver veta vilken operation som påverkades och i vilket steg den fastnade. Exemplet är en tänkt felsökningssituation, inte ett beskrivet kundprojekt. Förklaringen kräver inte nödvändigtvis att deltagarens fria anteckningar eller fullständiga kontaktuppgifter skickas till loggtjänsten.
Utgå från frågor som går att besvara
Skriv ned vilka frågor jouren behöver kunna svara på: tog systemet emot begäran, skapades en kalenderändring och skickades bekräftelsen? Koppla stegen med en operationsidentifierare och registrera resultat, relevant tjänst och varaktighet. Då kan teamet följa samma försök utan att göra varje loggrad till en kopia av användarens inmatade innehåll.
Skilj på ett tekniskt fel och ett förväntat verksamhetsavslag. En fullbokad tid är inte samma sak som en otillgänglig databas. Tydliga felkategorier gör det lättare att hitta avbrott utan att läsa känslig fritext. Dokumentera vilka fält som är tillåtna och vem som får lägga till nya, så att schemat inte växer genom tillfälliga felsökningsutskrifter.
Filtrera vid insamlingen och kontrollera andra vägar
Undvik att skicka lösenord, åtkomsttoken och fullständiga signaturförsedda länkar till loggar. En lista över fält som får samlas in är ofta lättare att granska än en växande lista över undantag. Filtrering bör ske innan uppgifterna lämnar applikationen där det är möjligt, inte enbart när någon öppnar en vy i loggverktyget.
Granska även stackspår, fel från underleverantörer och automatiska nätverksrapporter. Ett bibliotek kan lägga in en adress med personuppgifter i ett felmeddelande trots att de egna loggfälten är begränsade. Använd syntetiska testvärden som går att känna igen och följ dem genom hela kedjan. Skicka inte verkliga hemligheter bara för att prova om filtret fungerar.
Begränsa läsning, export och lagring
Bestäm vilka roller som behöver se driftdata och om kundsupport kan arbeta med en smalare vy. Att kunna öppna en felöversikt behöver inte innebära rätt att exportera alla loggar. Följ även kopior i nedladdade filer, ärendehanteringssystem och incidentdokument. Uppgifter som lämnar det centrala verktyget kan annars finnas kvar efter att ursprunglig lagring har löpt ut.
Lagringstiden ska motsvara ett uttalat syfte och verksamhetens krav. Hantera åtkomstgranskning och borttagning som faktiska driftuppgifter med ansvariga. Om särskilda regler eller avtal gäller behöver de bedömas för verksamheten. Att följa en generell teknisk rekommendation är inte ett bevis på att alla dataskyddskrav redan är uppfyllda.
Prova felsökning utan att öppna allt
Skapa ett misslyckat bokningsförsök med syntetiska uppgifter och låt en ansvarig följa operationen. Kan personen skilja timeout från avslag, se vad som behöver upprepas och avgöra om kunden redan fått en bekräftelse? Kontrollera sedan att förbjudna testvärden saknas i råloggar, exporter och anslutna tjänster, inte bara i den vanliga översikten.
Brainbaby Labs kan hjälpa till att utforma observabilitet för applikationer och infrastruktur. Skicka gärna några typer av fel som teamet behöver kunna förklara samt en översikt över nuvarande loggflöde. Det gör det möjligt att välja användbara mätpunkter, tydliggöra åtkomst och pröva om felsökningen fungerar med en mer avgränsad insamling.