IT-drift automatiserar bort sina egna bromsar

Det finns två läger inom IT som just nu utropar samma begravning, och ingen av dem tycks ha märkt den andra.

I området observability görs argumentet att den mänskliga läsaren är färdig. Fallet, som upprepats under det senaste året, är att hela disciplinens historia har varit en strävan att komprimera stora mängder telemetri till något som en person kan ta in på en gång, och att AI tar bort behovet av denna komprimering. Kommentatorer hävdar nu direkt att observability byggdes för människor och att AI-agenter behöver något annat. Corey Quinn använde en keynote på O11yCon, en konferens som ägnas åt ämnet, för att berätta för rummet att den primära läsaren av deras telemetri inte längre sitter i stolen.

I servicehantering görs argumentet att biljetten är färdig. Branschens förutsägelser för 2026 hävdar att biljettlösa operationer kommer att överträffa biljetautomatisering, och skillnaden dras skarpt: biljetautomatisering minskar mänskligt arbete, medan biljettlösa operationer syftar till att eliminera det. Leverantörer inom kategorin lovar nu service desk där problem upptäcks, diagnostiseras och korrigeras innan någon ens tänker på att höja en incident.

Båda lägren har rätt om vad de dödar. Vad ingen av dem har märkt är att de demonterar motsatta halvor av samma struktur, och att en del av vad de drar ut höll vikt.

Två discipliner, en begränsning

Tänk på vad observability faktiskt består av, under verktygen.

Urval finns eftersom ingen kan läsa varje spår. Aggregering finns eftersom ingen kan läsa varje mått. Instrumentpaneler finns eftersom en person behöver kasta en blick på ett system och bilda en uppfattning på några sekunder. Larmtrösklar finns för att omvandla en kontinuerlig ström av tillstånd till en binär signal, så att en människa avbryts endast när avbrott är motiverat.

Var och en av dessa är en komprimeringsmekanism. Observability, strukturellt, är praktiken att rationera information ner till vad en person kan hålla i huvudet.

Tänk nu på servicehantering.

Allvarlighetsgrader finns för att bestämma vem som får uppmärksamhet först. Köer finns för att hålla arbete som ingen är ledig att göra ännu. Eskaleringsnivåer finns eftersom expertis är knapp och dyr. Ändringsråd finns eftersom man inte kan ha alla som granskar allt. Serviceavtal är, i grunden, ett löfte om hur snabbt en begränsad mängd människor kommer att nå dig.

Var och en av dessa är en allokeringsmekanism. IT-servicehantering, strukturellt, är praktiken att rationera mänsklig uppmärksamhet över fler krav än det finns människor.

Så de två disciplinerna löser samma begränsning från motsatta ändar. Observability rationerar information som går in i en person. Servicehantering rationerar uppmärksamhet som kommer ut från en. Personen i mitten är anledningen till att båda fälten har den form de har.

Två discipliner, en begränsning.

Ingen av disciplinerna har någonsin beskrivit sig själv på det här sättet, och det är precis därför ingen av dem kan se tydligt vad de är på väg att ge upp.

Branschen har beslutat att begränsningen är borta

Fallet för att ta bort människan från mitten är starkare än dess kritiker medger, och jag vill framställa det rättvist.

Urval är verkligen en kompromiss som görs under tvång. Det kastar bort data som en maskin kunde använda, för att producera en volym som en person kunde överleva, vid en tidpunkt då lagring var dyr. Maskiner behöver inte instrumentpanelen. De kan hålla mer av ett system i arbetsminne än någon ingenjör, och de blir inte trötta klockan tre på morgonen. En lösenordsåterställning behöver inte en kö. Den behöver ett API-anrop. Om de flesta service desk-volymer består av ett fåtal rutinbegärandetyper, då är en service desk som byggts för att dirigera och triera dessa begäranden ett monument till ett problem som inte längre behöver lösas på det sättet.

Allt detta är sant, och det mesta av det är försenat.

Men här är draget som branschen gör utan att undersöka det. Efter att ha identifierat att mänsklig långsamhet formade båda disciplinerna, har den dragit slutsatsen att allt som är långsamt i båda disciplinerna var där på grund av mänsklig långsamhet.

Detta följer inte. När du tar bort en begränsning som påverkat varje designbeslut i ett område, kan du inte anta att varje designbeslut endast var relaterat till den begränsningen. En del av dem var relaterade till något annat, och det faktum att de råkar vara långsamma är tillfälligt.

Inte allt som är långsamt var en flaskhals

En del av vad dessa discipliner innehåller är en flaskhals. Den finns endast eftersom en person är långsam, den producerar ingenting utom försening, och den bör tas bort utan ceremoni.

Urval är en flaskhals. Manuell korrelation över tre verktyg klockan två på morgonen är en flaskhals. Kategorisering av en inkommande biljett för hand är en flaskhals. Dirigering av den till rätt kö är en flaskhals. Första linjens triage av en lösenordsåterställning är en flaskhals. Inget av dessa steg tillför något. De är skatt.

Men en del av vad dessa discipliner innehåller är en broms, och en broms är ett annat föremål helt.

Allvarlighetsklassificering är inte en försening. Den är en tvingande funktion. Den tvingar en namngiven person att uttala, på skrift, vad de tror är den affärsmässiga påverkan av denna händelse. Utdata är inte etiketten. Utdata är åtagandet.

Ett ändringsråd är inte långsamt eftersom människorna i det är långsamma. Det är långsamt eftersom överväganden är vad det producerar. Mötet är inte en överhettning som är knuten till beslutet. Mötet är beslutet.

En postmortem är långsam med flit. Reflektion är inte fördröjning. En organisation som lär sig av misslyckanden på fyra sekunder har inte lärt sig någonting.

Detta är bromsar. De finns för att införa friktion medvetet, exakt i de ögonblick då hastighet inte är det man vill ha.

Och utifrån ser en broms och en flaskhals nästan identiska ut. De ser likadana ut i en processdiagram. De producerar samma klagomål i en undersökning. De båda visar sig som ett gap mellan när något kunde ha hänt och när det gjorde.

De båda ser ut som väntan.

Flaskhals eller broms? Båda ser ut som väntan.

Vad det faktiskt kostar att ta bort en broms

Här är där argumentet slutar vara en fråga om smak, eftersom det nu finns bevis.

Googles DORA-forskning har tillbringat två år med att mäta vad som händer med programvarudistributionen när AI-användningen ökar. 2024 års resultat uppskattade att ökad AI-användning kom med en minskning av leveransstabiliteten på cirka sju procent. Följande år förbättrades genomströmningsbilden, men den negativa relationen med stabilitet höll. Googles egen sammanfattning var att AI accelererar utvecklingen, och att accelerationen exponerar svagheter nedströms.

Det uppenbara försvaret är att hastigheten betalar för skadan. Skeppa snabbare, bryt mer, fixa snabbare, kom ut som vinnare. DORA testade det. Forskarna kontrollerade om AI:s genomströmningsvinster kompenserade för de skador som orsakades av ökad instabilitet, och data stödde inte hypotesen. Instabiliteten betalades inte av hastigheten. Den absorberades helt enkelt någon annanstans.

Se nu på den skarpare förutsägelsen på den agenterade marknaden. I juni 2025 förutspådde Gartner att över 40 procent av agenterade AI-projekt skulle avbrytas senast 2027. Siffran citeras överallt, vanligtvis utan datum, och vanligtvis som en dom över tekniken.

Siffran är inte det intressanta. Orsakerna är. Gartner namngav tre: eskalerande kostnader, oklar affärsnytta och otillräckliga riskkontroller. Modellkapacitet är inte på listan. Inget av dessa tre misslyckandemoderna skulle åtgärdas av en bättre modell.

Läs det som en driftsdiagnos och det blir mycket skarpare. Gartner beskriver inte organisationer vars AI inte var tillräckligt bra. Det beskriver organisationer som tog bort bromsarna.

De orsaker Gartner namngav, och den de inte gjorde.

“En observation från fältet. Den ideala formen är ett fall där ett team automatiserade ett steg som visade sig vara belastningsbärande och upptäckte det efteråt, eller en kund som höll en långsam process trots råd och var rätt i att göra det. Det behöver inte vara dramatiskt. Det behöver vara specifikt och sant.”

Den sortering som ingen kör

Om argumentet håller, är arbetet under de närmaste åren i IT-drift inte hastighet. Det är sortering.

Tag varje långsamt steg i båda disciplinerna och ställ en fråga till det. Är detta långsamt eftersom en människa är långsam, eller är det långsamt eftersom bedömning tar tid?

Den första kategorin bör automatiseras utan sentimentalitet. Ingen bör försvara manuell biljettkategoriisering på grund av hantverk. Ingen bör försvara urval så länge ekonomiskt inte längre kräver det. Dessa steg är inte heliga. De var aldrig något annat än en skatt på knapphet, och knappheten försvinner.

Den andra kategorin behöver något mer noggrant än borttagning. Poängen är inte att hålla en person i loopen för dess egen skull, vilket är hur mänsklig tillsyn vanligtvis försämras till en gummistämpel. Poängen är att ändra vad personen ombeds att göra.

Sluta be dem att utföra arbetet. Börja be dem att fatta beslut på skrift. Inte “granska den här ändringen”, utan “uttala vad du tror är sprängverkan”. Inte “triage den här incidenten”, utan “sätt ditt namn på den här allvarlighetsklassificeringen”. Maskinen kan göra utredningen, samla in bevisen, föreslå åtgärden och utföra den. Vad den inte kan göra är att vara ansvarig för det, och ansvar är inte en långsam version av en snabb sak. Det är en annan sak.

Biljetten var bromsen

Vilket för mig tillbaka till begravningen.

Branschen har beslutat att biljetten dör. Jag tror att motsatsen är närmare sanningen.

Stripa bort allt runt biljetten som var en flaskhals. Ta bort dirigeringen, kategoriseringen, kön, nivåerna, den manuella triagen, väntan. Allt detta var stödbyggnader byggda runt en långsam människa, och allt detta kan försvinna.

Vad som är kvar är biljettens enda ouppdelbara funktion. Den är artefaktet där en namngiven person accepterade ansvar för en utgång. Det är inte ett arbetsflödessteg. Det är en beslutsrekord, och det är den enda saken i hela apparaten som inte blir snabbare när maskinerna blir snabbare.

Service desk blir automatiserad. Instrumentpanelen blir valfri. Kön försvinner. Och den sak som alla var mest angelägna om att begrava visar sig vara den enda komponenten som aldrig handlade om hastighet alls.

Så frågan jag skulle ställa till varje team som är på väg att ta bort ett långsamt steg från sin drift är en enkel en. Vet du vilken sorts långsamhet det var?