Avbrottsloggar kan få smarta team att verka helt vilsna. Du har en stack trace, Slack glöder och alla gissar vilken ändring som ”måste ha orsakat det”. Under tiden rinner tiden iväg.
Den här stack trace-fixen är byggd för beredskapsingenjörer som behöver en lugn, evidensbaserad genomgång av en krasch på några minuter, engineering managers som måste kommunicera påverkan och nästa steg till intressenter, och supportansvariga som behöver en tydlig förklaring att omvandla till kundnära uppdateringar. Resultatet är en detektivlik genomgång som innehåller en incidenttidslinje, den mest sannolika rotorsaken (med tydligt angiven osäkerhet) och en praktisk plan för åtgärd och förebyggande.
Vad gör den här AI-prompten och när ska du använda den?
| Vad den här prompten gör | När du ska använda den här prompten | Det här får du |
|---|---|---|
|
|
|
Hela AI-prompten: stack trace-detektivgenomgång + åtgärdsplan
Fyll i fälten nedan för att anpassa prompten efter dina behov.
| Variabel | Vad du ska ange | Anpassa prompten |
|---|---|---|
[STACK_TRACE] |
Ange den råa stack trace:en från kraschen eller felet, inklusive alla stackramar, felmeddelanden samt relevanta fil- och radreferenser. Till exempel: "Exception in thread 'main' java.lang.NullPointerException at com.example.MyClass.myMethod(MyClass.java:42) at com.example.MyApp.main(MyApp.java:15)"
|
|
[KONTEXT] |
Beskriv miljön och situationen där felet uppstod, inklusive körningsdetaljer, konfiguration och eventuella nyliga förändringar. Till exempel: "Java 11-applikation som körs på AWS EC2 med en Spring Boot-backend. Felet uppstod efter driftsättning av en ny version med uppdaterat databasschema."
|
|
[KOMPETENSNIVA] |
Ange den tekniska kunskapsnivån hos personen som ska använda förklaringen, till exempel nybörjare, medelnivå eller avancerad. Till exempel: "Medelnivå: Van vid felsökning men inte särskilt erfaren av att läsa detaljerade stack traces."
|
|
[BRANSCH] |
Ange bransch eller domän som är relevant för applikationen, eftersom det kan påverka terminologi och vad som bör prioriteras. Till exempel: "Spelutveckling: Motor för multiplayer i realtid för ett onlineskjutspel."
|
|
[PRIMART_MAL] |
Ange huvudsyftet med att tolka stack trace:en, till exempel att åtgärda buggen, hitta grundorsaken eller förbättra driftsäkerheten. Till exempel: "Diagnostisera grundorsaken till en NullPointerException och föreslå åtgärder som förhindrar att den återkommer."
|
Proffstips för bättre resultat från AI-prompten
- Klistra in tracen exakt som den är och lägg sedan till två rader kontext. Inkludera runtime-version och den utlösande åtgärden (”händer när checkout skickas”, ”misslyckas under startup-migrering”). Bara en extra ledtråd kan ändra rankningen av troliga orsaker. Om du har bråttom, lägg till: ”Miljö: prod, släppt för 10 minuter sedan, felfrekvensen hoppade från 0,1 % till 8 %.”
- Be den anpassa sig efter läsaren. Den här prompten anpassar detaljnivån, men du får mer strukturerat output om du anger målgruppen. Prova: ”Förklara detta för en junior utvecklare och lägg sedan till en sammanfattning på 5 meningar för en uppdatering i incidentkanalen.”
- Tvinga fram en ”motivering av körtidsordning” när traces är förvirrande. Vissa stackar är kontraintuitiva eftersom async-/task-gränser eller proxy-lager rör till berättelsen. Följ upp med: ”Peka ut var körtidsordningen är tvetydig och förklara hur du avgjorde exekveringssekvensen.” Kort, men det ökar förtroendet.
- Iterera på åtgärdsplanen, inte på förklaringen. Efter första output, be: ”Gör nu alternativ 2 mer offensivt och alternativ 4 mer konservativt. Inkludera risk, utrullningssteg och hur vi skulle upptäcka regressioner.” Då får du snabbt något som går att göra om till en checklista i ett ärende.
- Kombinera med en lättviktig KPI-snapshot för incidenten. Ärligt talat: de bästa åtgärdsplanerna innehåller ”hur vi vet att det är fixat”. Para ihop output med en enkel mätprompt: ”Lista 5 metrics/loggsignaler för att bekräfta återhämtning och förhindra återkommande fel (felfrekvenser, specifika loggsignaturer, latens, ködjup).” Om du redan följer mål och KPI:er kan du koppla det till ett system som https://nodenordic.se/prompts/bygg-ett-malstyrt-kpi-system-med-ai-prompten för löpande rapportering av driftsäkerhet.
Vanliga frågor
Site reliability engineers använder den för att omvandla råa traces till en ordnad exekveringsberättelse och en prioriterad valideringsplan, vilket snabbar upp inneslutning. Backendingenjörer förlitar sig på den för att ringa in sannolika felande moduler och avgöra vilka kodvägar som ska granskas först (särskilt när ramverk dominerar stacken). Engineering managers använder den för att ta fram en tydlig incidentberättelse och nästa steg som är förankrade i evidens, inte gissningar. Support- och eskaleringsansvariga använder förklaringen på klarspråk för att skriva korrekta uppdateringar medan engineering jobbar på fixen.
SaaS-bolag får värde eftersom en enda topp av undantag kan påverka tusentals användare, och de behöver snabb och konsekvent tolkning av ramverkstunga traces. E-handel och marknadsplatser använder den vid fel i checkout, betalning eller lager, där ett tydligt budskap om ”vad som gick sönder och vad vi gör åt det” minskar intäktspåverkan. Spel och realtidsappar gynnas av personans produktion-debuggande mindset, särskilt när krascher är intermittenta och loggarna är ofullständiga. Professionella tjänster och byråer använder den för att förklara fel för kunder på ett sätt som är tekniskt nog för trovärdighet, men tillräckligt strukturerat för att gå att agera på.
En typisk prompt som ”Skriv en rotorsak för den här stack tracen” faller eftersom den: saknar en tvingande föranalys (gissning av språk/runtime och feltyp), ger ingen struktur för att segmentera ramverk vs app-frames, ignorerar osäkerhet och överdriver sina slutsatser, producerar en generell förklaring i stället för att följa den faktiska exekveringsordningen i runtime, och missar beteendet ”be bara om det som saknas” som håller utredningen i rörelse. Du får något som låter självsäkert, men inte något du tryggt kan agera på.
Ja. Även om prompten inte har inbyggda variabler anpassar du den genom att lägga till en kort ”kontextheader” före tracen: språkgissning (om du vet), miljö, vilken handling som utlöste kraschen och vad som nyligen ändrades. Du kan också ange målgrupp och önskat djup (”lär upp en junior” vs ”skriv en kort incidentuppdatering”). En bra följdfråga är: ”Ge mig två åtgärdsspår: en säker hotfix för i dag och en djupare refaktor för nästa sprint, med valideringssteg för båda.” Om tracen är ofullständig, svara bara på frågorna om saknad information som den ställer och kör sedan igen.
Det största misstaget är att klistra in en avklippt trace utan att säga att den är ofullständig — i stället för ”här är felet”, säg ”tracen är avklippt efter 40 rader; jag kan klistra in mer vid behov.” Ett annat vanligt fel är att utelämna triggern; ”den kraschar ibland” är svagare än ”kraschar när man laddar upp en CSV på 40 MB efter att ha klickat på Importera.” Folk glömmer också att ange miljö och timing, vilket spelar stor roll; ”prod direkt efter deploy 2f31c” slår ”problem i produktion.” Slutligen: be inte om en enda definitiv fix; be om rankade hypoteser plus nästa kontroller så att du snabbt kan bekräfta den verkliga orsaken.
Den här prompten är inte optimal för problem som inte ger en meningsfull stack trace (långsamma queries, minnesläckor utan krascher eller vaga ”det känns segt”-rapporter). Den är heller inte rätt verktyg om du behöver garanterad korrekthet utan tillgång till kod, input och miljödetaljer; den förblir evidensbaserad, men den kan inte köra ditt system. Och om ditt huvudsakliga behov är en säkerhetsgranskning eller prestandatuning, använd i stället en specialiserad granskningsprocess – om inte tracen tydligt pekar dit.
Du behöver inte mer spekulation under en incident. Klistra in tracen, lägg till en minimal mängd kontext och låt den här prompten omvandla kaos till en läsbar berättelse och en genomförbar åtgärdsplan.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.