Så byggde vi en AIOps-agent – och lät den genomföra root cause analys

Tobias Johansson
för 6 dagar sedan
4 min läsning

Uppdaterat: för 5 dagar sedan

Den 13 mars hade vi en tjänst som var nere.

Inget konstigt i sig, sånt händer.I en komplex miljö så kan det finnas flertalet orsaker till detta, många system att validera och det kan bli tidskrävande att felsöka.

Github (Manifest repo)
Kubernetes (AWS EKS)
ArgoCD
Amazon ECR
AWS Loadbalancers

Det fanns ingen tydlig root cause, samt att börja felsöka varje system för sig kan vara en tidskrävande process.

Vi gjorde något enkelt: vi lät en AI felsöka

Istället för att börja leta manuellt så satte vi en AI på problemet.

En prompt.Ingen dialog fram och tillbaka.Bara: “ta reda på vad som är fel, går ej att nå applikation X”.

Resultatet? 4 fel över tre system

På en run hittade agenten:

1. Fel selector i load balancer (felkonfigurerat kubernetes manifest)

loadbalancer.yaml refererade till devsecops-lab-appp (tre p).

Resultat: inga friska NLB targets.

2. Image tag som inte fanns (felkonfigurerat kubernets manifest)

Deployment.yaml använde v0.0.99, men ECR hade bara v0.0.7.Pod fastnade i ImagePullBackOff.

3. Port mismatch (felkonfigurerat kubernetes manifest)

containerPort 4999 var konfigurerad, medan service och load balancer pekade på 5000.Alla requests hade nekats.

4. Security group blockerade health checks

NodePort 30992 användes, men security group tillät bara 31000–31100.Health checks droppades tyst.

Fyra små fel.Tillsammans: en tjänst som inte fungerade.

Här kommer det viktiga: hur vi byggde det

Det här fungerade inte för att vi “promptade bra”.Det fungerade för att vi byggde rätt struktur runt AI:n.

Låt mig visa hur vi gjorde.

Steg 1: vi byggde en agent som faktiskt kan göra jobbet

Vi började inte med prompts.Vi började med vad agenten faktiskt kan göra.

Vi satte upp en lokal MCP-server och gav agenten tre enkla verktyg:

list – visa tillgänglig kod (för att slippa generera på nytt)
write – för att generera kod
execute – för att köra det den själv skapat

Sedan gjorde vi ett medvetet val. Vi byggde inga färdiga integrationer. (Denna metod kallas specifikt ”Code execution with MCP”).

Istället lät vi agenten själv:

skriva scripts för att läsa Kubernetes-resurser
hämta information från AWS (t.ex. security groups, load balancers)
jämföra konfiguration mot GitHub

Första körningen tog lite längre tid, men efter det kunde den återanvända sina egna “skills”.

Resultatet?

En agent som inte bara svarar, utan faktiskt driver felsökningen.

Steg 2: vi definierade troubleshooting-flödet upfront

Nästa problem: var ska agenten börja?

AI är bra på execution, men inte på att välja rätt väg.

Så vi tog bort det valet helt.

Vi skapade infra-context.md och definierade en tydlig routing:

“App unreachable” →ArgoCD → Deployments → Pods → Services → Manifests

Det här är inget avancerat.Det är bara vår samlade erfarenhet nedskriven.

Skillnaden är att agenten:

följer varje steg
hoppar inte över något
kör allt i samma flow

Det är här vi gick från “AI som testar lite saker”till reproducerbar troubleshooting-process.

Steg 3: vi styrde beteendet, inte bara inputen

Sista delen var att få agenten att bete sig konsekvent.

Det gjorde vi i CLAUDE.md.

Där beskrev vi konkret:

när MCP-servern ska användas
hur workflows ska byggas (kodstruktur)
hur resultat ska struktureras i en rapport
vilka filer som ska läsas för kontext (infra-context.md)

Vi var väldigt tydliga här.

Till exempel:

“läs alltid infra-context.md först”
“bygg ett workflow som kör alla checks i en och samma run”
“returnera ett strukturerat svar med identifierade fel och förslag på åtgärder”

Det här var avgörande.

Utan det fick vi olika svar i olika format baserat på hur prompten såg ut.Med strukturen fick vi en agent som:

jobbar metodiskt
kör hela analysen i ett steg
levererar något vi faktiskt kan använda direkt

Vad vi lärde oss

Det här var det som faktiskt gjorde skillnad:

Struktur optimerar AI-modellen

Dagens LLMs är kraftulla, men kan tendera att hallucinera och gå åt fel håll om inte struktur och regler finns på plats.

AI är bra på att skriva kod

Då LLMs är mer tränade på att generera kod än att använda sig av diverse ”tools” är det fördelaktigt att låta dem göra det, istället för att be dem felsöka med ”frihand”. Detta gör att contexten hålls ”ren” vilket minskar risken för hallucinationer och sparar på tokens.

Rensa kontext mellan körningar

Då en agent utan struktur inte har kunskap om miljön (vi hade behövt prompta hur den kan nå varje system), den finner förmodligen inte samtliga fel efter en körning och behöver åter promptas att fortsätta felsökning (kostar mer tokens och är inte determenistiskt). Detta kan också leda till context bloating vilket tenderar skapa problem för agenten att komma dess ursprungliga uppgift.

Det går att göra reproducerbar

En run → ett svar → samma resultat varje gång.

Vad det här innebär i praktiken

De flesta miljöer idag består av flertalet olika system t.ex. Kubernetes, cloud (AWS/Azure), Någon form av Git, CI/CD, Vms etc.

När något går fel krävs ofta: