AIOps och vad det faktiskt förändrar för DevOps

Goran Nushkov
27 juli
8 min läsning

AIOps är ett av de där begreppen som betyder fem olika saker beroende på vem som använder det. För vissa handlar det om avvikelsedetektering i mätvärden. För andra är det en chatbot framför en runbook. Och för leverantörer är det ofta vad de råkar sälja just det här kvartalet.

Det här är inte ett inlägg om huruvida AI kommer att ersätta människor. Det handlar om vad som faktiskt förändras i det dagliga arbetet, vad som förblir exakt likadant och var tankesättet behöver utvecklas om du vill fortsätta vara relevant.

Två olika saker med samma namn

Det hjälper att skilja dem åt, eftersom de drar åt två helt olika håll.

AI som hjälper dig att göra DevOps. Assistenter som skriver Terraform-kod, sammanfattar en incident utifrån loggar, föreslår en lösning baserat på en stack trace eller granskar en pull request. Det här är den del som alla pratar om. Den är genuint användbar, men i grunden handlar den mest om verktyg: välj något, lär dig dess begränsningar och var alltid lite skeptisk.

DevOps för AI. Någon i din organisation har byggt något som innehåller en LLM, och nu behöver det en miljö, en deploymentspipeline, autentiseringsuppgifter, nätverksanslutning, övervakning och en budget. Det här är den del som i det tysta håller på att bli en stor del av plattformsarbetet och det är också den del som faktiskt är intressant, eftersom det är här de gamla antagandena börjar knaka i fogarna.

Den första gör dig snabbare. Den andra innebär en helt ny typ av arbetslast som du nu ansvarar för. Det är på den senare jag skulle lägga min tid om jag ville lära mig mer.

Den goda nyheten: det mesta är en helt vanlig arbetslast

Om man skalar bort nyhetens behag är en tjänst som anropar en modell fortfarande bara en tjänst som anropar ett HTTP-API. Den behöver samma saker som alla andra tjänster behöver.

Den behöver autentiseringsuppgifter som ingen behöver rotera manuellt. På AWS innebär det att köra inferens via en hanterad tjänst, så att applikationen autentiserar sig med sin egen IAM-roll i stället för en API-nyckel som ligger i ett hemlighetslager. Det är inte ett AI-beslut – det är samma beslut som du redan har fattat för S3 och för din databas.

Den behöver timeout-inställningar som speglar verkligheten. Modellsvar är långsamma och, ännu viktigare, långsamma på ett ovanligt sätt. En resonemangsmodell kan vara helt tyst i en minut innan den producerar sin första token. Sätter du en vanlig HTTP-timeout får du en ström av avbrutna klientanrop, utan att det finns någonting i serverloggarna som förklarar varför. Jag förlorade själv en hel eftermiddag på just det.

Den behöver återförsök med exponentiell backoff, eftersom hastighetsbegränsningar och tillfälliga kapacitetsproblem är en del av vardagen snarare än undantag.

Den behöver cachelagring, och oftast mer än ett lager av den.

Den behöver tydliga nätverksgränser och ett genomtänkt förhållningssätt till datalagring och dataresidens, särskilt i Europa. Var inferensen sker är nu en del av din efterlevnadsstrategi, på samma sätt som var din databas finns alltid har varit.

Inget av det här är egentligen nytt. Har du arbetat med den här typen av system ett tag vet du redan hur man gör allt detta. Det är den uppmuntrande delen, och den är värd att lyfta fram eftersom diskussionen om AI ofta ger intrycket att allt håller på att uppfinnas på nytt.

Det gör det inte.

Den obekväma delen: tjänsten är inte deterministisk

Det är här det faktiskt blir annorlunda, och det är här jag ser att många blir tagna på sängen.

Allt vi har byggt de senaste femton åren bygger på antagandet att en given indata ger en given utdata. Testning bygger på det. Rollbacks bygger på det. Canary-deployments bygger på det. "Det fungerar i staging" bygger på det.

En modell fungerar inte så. Samma indata kan ge ett något annorlunda resultat vid två anrop i rad. Inte fel – bara annorlunda. Ibland returnerar den ren JSON, ibland paketerar den JSON:en i ett kodblock. Ibland inleder den med ett resonemang. Och ibland, när du skickar in en lång lista, returnerar den tyst nio objekt i stället för tio.

Den sista är värd att stanna upp vid, eftersom det är den typen av fel som faktiskt kommer att ställa till problem. Det är ingen krasch. Det är ingen 500-statuskod. Inga larm går. Resultatet är välformaterat, ser rimligt ut – och är samtidigt diskret ofullständigt.

Praktiska konsekvenser:

Parsa alltid defensivt. Utgå från att svaret kan vara omslutet, föregånget eller utfyllt med sådant du aldrig bad om. Rensa bort det innan du parsar. Alla modeller gör det här ibland – även de dyra.
Validera strukturen, inte bara syntaxen. Om du bad om tio resultat, kontrollera att du faktiskt fick tio. Om du bad om tre fält, kontrollera att alla tre finns där. Giltig JSON är inte samma sak som korrekt utdata.
Ha en fallback för saknad data. I en av mina tjänster sparar jag det senast kända korrekta resultatet för varje objekt. Om modellen tappar bort något i en batch återanvänds det tidigare värdet i stället för att objektet försvinner ur svaret. Det är en liten mängd kod som förvandlar ett tyst dataförlustfel till en icke-händelse.
Dina tester kan inte längre verifiera exakt utdata. De kan verifiera struktur, intervall och invarianta egenskaper. Anpassa förväntningarna därefter.

Den mentala modell som hjälpte mig mest var att sluta se det som ett funktionsanrop och i stället börja se det som ett nätverksanrop till en tjänst som för det mesta har rätt. Du vet redan hur man bygger system kring ett beroende av den typen.

Kostnad går från en månadspost till ett beslut per anrop

Det här är den andra stora förändringen, och jag tror att det är den som tydligast påverkar hur en plattformsingenjör skapar värde.

Med traditionell infrastruktur handlar kostnader främst om kapacitet – något man ser över då och då. Med modeller är kostnaden kopplad till varje enskilt anrop. Den skalar linjärt med användningen och kan skilja sig med en tiopotens beroende på vilka val som görs i applikationskoden. Ett team kan lansera en ny funktion på fredagen och märkbart förändra månadskostnaden utan att någon egentligen har gjort något fel.

Tre saker gör störst skillnad, och ingen av dem är särskilt komplicerad:

Alla anrop behöver inte använda din bästa modell. De flesta applikationer gör lite svårt arbete och mycket enkelt arbete: klassificering, rangordning, extrahering och korta förslag. Det enkla arbetet står vanligtvis för merparten av anropsvolymen, och användarna kan ändå inte avgöra vilken modell som har hanterat det. Att dirigera den typen av anrop till en billigare och snabbare modell är den enskilt största möjligheten att minska kostnaderna – och förbättrar ofta svarstiderna på köpet.

Cacha det som återkommer. De flesta leverantörer erbjuder cachelagring av en lång och oföränderlig systemprompt, så att du slipper betala för att bearbeta den på nytt vid varje anrop. Utöver det bör du cacha resultaten i själva applikationen. Tricket är att välja rätt granularitet: cacha per objekt i stället för per batch, så att en förfrågan som bara skiljer sig med ett enda element fortfarande kan använda cachen för resten.

Alla modellanrop behöver inte lämna den egna processen. Embedding-modeller är tillräckligt små för att kunna köras direkt i applikationscontainern på CPU. Det eliminerar ett nätverksberoende, en hastighetsbegränsning och en kostnadspost – för en typ av arbetslast som de flesta reflexmässigt skickar vidare till ett API.

Lägg märke till att alla tre handlar om arkitektur, inte om vilken modell du väljer. Det är ett mönster som återkommer.

Konfiguration, inte inlåsning

Landskapet för AI-modeller förändras snabbare än något annat i vår teknikstack. Något bättre och billigare dyker upp med några månaders mellanrum, och förr eller senare kommer den modell du valde att fasas ut.

Gift dig därför inte med en modell. Lägg den bakom ett konfigurationslager: endpoint, modellnamn, autentiseringsmetod och vilket dataformat den använder. Fyra värden i en miljöfil. Allt ovanför det lagret ska vara helt ovetande om vilken leverantör det faktiskt kommunicerar med.

Jag gjorde det här tidigt, mest av ren bekvämlighet, och det visade sig bli det enskilt mest värdefulla beslutet i hela projektet. Sedan dess har jag växlat mellan lokala och hostade modeller, mellan två olika leverantörer och mellan två olika förfrågningsformat.

Varje gång har det handlat om en konfigurationsändring i stället för en kodändring. När en leverantör visade sig inte exponera en modell via den endpoint jag hade utgått från blev lösningen att lägga till en adapter bakom samma gränssnitt – inte att skriva om hela implementationen.

En närliggande vana är att utveckla mot en liten lokal modell. I dag är det fullt möjligt att köra en sådan på en dator med ett hyggligt GPU, och det ger dig friheten att iterera utan att taxametern tickar. Dessutom skapar det en nyttig disciplin, eftersom en liten modell inte har något utrymme för slarviga instruktioner. Fungerar något mot en mindre lokal modell fungerar det i regel överallt. Fungerar det bara mot den senaste och mest avancerade modellen har du en skör design – och du har upptäckt det till en låg kostnad.

Prompter är produktionskod

Det här var den förändring som tog längst tid för mig att acceptera, och den jag skulle vilja betona mest.

Den största kvalitetsförbättringen i något jag har byggt med modeller kom inte från en bättre modell. Den kom från att skriva om instruktionerna: att vara tydlig med intervall i stället för vag kring kvalitet, att ge ett konkret exempel på hur ett uppenbart dåligt resultat ser ut, att förklara att konsekvens mellan olika objekt är viktigt och att uttryckligen säga att längd inte är ett bevis på substans – eftersom modeller instinktivt verkar utgå från att det är det.

Var och en av de förändringarna består av en enda mening på engelska. Tillsammans hade de större effekt än någon uppgradering av modellen.

Det innebär också att de meningarna är verksamhetskritiska och förtjänar samma behandling som all annan verksamhetskritisk kod: versionshantering, kodgranskning, en tydlig plats i en riktig modul i stället för stränglitteraler utspridda över kodbasen och, helst, tester som upptäcker när en ändring gör resultatet sämre. En ändring i en prompt kan orsaka produktionsproblem precis lika effektivt som en kodändring, men i dag saknar de flesta organisationer helt processer för att hantera det. Där finns en möjlighet för den som vill ta den.

Vad det här betyder för att fortsätta vara relevant

Jag tror inte att AI gör våra kompetenser överflödiga. Jag tror att det tillför en ny typ av arbetslast där de flesta av våra befintliga färdigheter fortfarande är direkt tillämpliga, kompletterade med ett antal nya arbetssätt.

Det som följer med oförändrat är IAM och principen om minsta privilegium, nätverkssegmentering, hantering av autentiseringsuppgifter, timeouter och återförsök, cachestrategier, kostnadsuppföljning, deploymentspipelines och observability. Allt det fortsätter att vara lika relevant.

Det som är värt att utveckla är instinkten att utgå från att modellernas utdata inte är deterministisk och designa systemen därefter, att behandla modellval som en konfigurationsfråga, att tänka kostnad per anrop i stället för kostnad per månad och att se prompter som en viktig del av applikationen.

Och så finns det en vana som inte har med verktyg att göra över huvud taget: använd de här systemen kritiskt. Inte med entusiasmen hos någon som vill att de ska vara magiska, och inte heller med cynismen hos någon som hoppas att de ska misslyckas.

Använd dem tillräckligt mycket för att förstå exakt vad de är bra på och exakt var de i det tysta gör fel. Den kalibreringen är den verkliga bristkompetensen just nu – och det enda sättet att skaffa sig den är genom praktisk erfarenhet.

Sammanfattning

Om jag ska sammanfatta det senaste året är sanningen att arbete med modeller i produktion har varit ungefär 20 procent nytt och 80 procent traditionell plattformsteknik. Själva modellen fungerade nästan direkt. IAM-policyn tog tre försök.

Instruktionerna tog flera veckor. De verkligt intressanta problemen handlade om svarsmönster och latens, kostnad per anrop och hur man hanterar utdata som är subtilt ofullständig. Inget av det är egentligen AI-problem i någon djupare mening. Det är drift- och plattformsproblem i ny förpackning.

Det tycker jag är betryggande. Disciplinen håller inte på att ersättas, den håller på att utökas. Och den utökningen består till största delen av sådant vi redan vet hur man gör.

Hur ser det ut hos er?

Att införa AI handlar sällan om att bara välja rätt modell. Minst lika viktigt är hur modellerna integreras, driftas, övervakas och kostnadsoptimeras i den plattform ni redan har.

Många organisationer har redan en stabil grund med Kubernetes, CI/CD, observability och moderna plattformar. Utmaningen ligger oftare i att bygga rätt arkitektur runt AI-modellerna med fokus på säkerhet, prestanda, kostnad och långsiktig förvaltning.

Vill du diskutera hur AI-arbetslaster skulle kunna passa in i er plattform? Boka ett samtal med en av våra experter på knappen nedan, så visar vi hur vi hjälper organisationer att bygga robusta och skalbara AI-lösningar i praktiken. 👇

Prata med oss om AIOps

Eller kontakta vår kollega Ronnie Qvist direkt, så hjälper han dig vidare.