1.5 Datakällor och instrumentering

Översikt och motivation

Ett mätetal är bara så tillförlitligt som datan under det, och de flesta metrikprogram lägger långt mer ansträngning på att designa instrumentpaneler än på att verifiera pipelinen som matar dem. Det är bakvänt. Ett vackert designat diagram byggt på inkonsekvent, självrapporterad, eller tyst trasig instrumentering är värre än inget diagram alls, eftersom det ser auktoritativt ut samtidigt som det har fel. Det här ämnet handlar om den oglamorösa grunden resten av den här boken förutsätter: var ingenjörsdata faktiskt kommer ifrån, när man ska lita på automatiserad instrumentering framför självrapportering, och de datakvalitetsmisslyckanden som tyst ogiltigförklarar ett mätetal innan någon märker det.

Mjukvaruingenjörsdata kommer från en handfull källtyper, var och en med olika tillförlitlighetsegenskaper. Versionskontroll och CI/CD-pipelines genererar objektiva, tidsstämplade, svårförfalskade register över vad som faktiskt hände. Ärendehanteringssystem och projekthanteringsverktyg genererar register som beror på att människor uppdaterar status korrekt och snabbt, vilket de ofta gör inkonsekvent. Enkäter genererar självrapporterad data som är ovärderlig för saker inget system kan observera, som nöjdhet, men är föremål för minnesbias och social önskvärdhetseffekt. Observerbarhetsplattformar genererar systemnivåtelemetri som är objektiv men bara täcker vad som instrumenterats. Att veta vilken kategori ett givet mätetals data kommer från berättar hur mycket du ska lita på det och vilka misslyckandemönster du ska vaka över.

På stora företags och myndigheters skala förstärks datakvalitetsproblem eftersom avståndet mellan datans ursprung och dess slutanvändning i en instrumentpanel växer genom flera system, integrationer, och transformationer. Ett fält som betyder en sak i källsystemet kan betyda något subtilt annorlunda när det når ett rapporteringslager, och ingen nedströms märker det eftersom talet fortfarande ser rimligt ut. Att få instrumentering rätt är mindre spännande än att få ramverk rätt, men det är grunden allt annat i den här boken står på.

Nyckelprinciper

Föredra instrumentering framför självrapportering varhelst systemet kan observera händelsen direkt. En driftsättningstidsstämpel från pipelinen är mer tillförlitlig än ett teams självrapporterade driftsättningsantal.
Använd självrapportering bara för vad som inte kan observeras direkt. Nöjdhet, upplevd friktion, och välbefinnande har inget systemregistersubstitut; fråga direkt och designa enkäten väl (ämne 3.7). Reservera självrapportering specifikt för den kategorin.
Varje mätetals data har ett källsystem, en insamlingsmetod, och ett känt misslyckandemönster. Dokumentera alla tre, inte bara definitionen.
Datakvalitet förfaller tyst. En pipeline som fungerade korrekt för ett år sedan kan vara tyst trasig idag, och en instrumentpanel kommer fortsätta rendera ett fel tal utan klagomål.
Instrumentera vid sanningens punkt, inte nedströms av en översättning. Varje hopp mellan händelsen och instrumentpanelen är en chans för betydelsen att glida.

Rekommendationer

Kartlägg varje mätetal till dess faktiska källsystem innan du litar på det

För varje mätetal på en instrumentpanel, namnge det specifika system som genererar den underliggande händelsen: CI/CD-pipelinen för driftsättningshändelser, versionskontrollvärden för commit- och sammanslagningshändelser, incidentspåraren för driftstoppregister, enkätplattformen för självrapporterad nöjdhet. Om du inte kan namnge det exakta systemet vet du faktiskt inte var talet kommer ifrån, och du kan inte utvärdera dess tillförlitlighet. Den här kartläggningen är en förutsättning för styrningsstadgan i ämne 1.4, inte en separat övning.

Instrumentera vid händelsen, inte vid rapporten

Den mest tillförlitliga datan fångar en händelse automatiskt i det ögonblick den sker: en pipeline registrerar en driftsättning i samma ögonblick den slutförs, ett versionskontrollsystem registrerar en sammanslagning i samma ögonblick den landar. Data som beror på att en människa kommer ihåg att uppdatera ett statusfält efteråt, markera ett ärende “klart,” logga en driftsättning manuellt i ett kalkylblad, försämras i noggrannhet ju längre den sitter från den faktiska händelsen och ju upptagnare personen ansvarig blir. Varhelst en automatiserad händelse finns, föredra den framför en mänskligt rapporterad proxy för samma faktum.

Reservera enkäter för vad bara en person kan berätta för dig

Vissa saker kan genuint inte observeras från systemtelemetri: om en ingenjör känner att deras arbete är meningsfullt, om en process känns frustrerande, om risken för utbrändhet ökar. De här kräver att fråga direkt, och en väldesignad enkät (ämne 3.7 täcker mekaniken) är rätt verktyg. Misstaget är att använda självrapportering för saker ett system istället kunde observera direkt, att be ingenjörer uppskatta sin egen driftsättningsfrekvens istället för att hämta den från pipelinen, vilket introducerar onödigt brus och bias i data som kunde ha varit objektiv.

Bygg datakvalitetskontroller in i själva pipelinen

Behandla mätetalspipelines med samma rigör som produktionskod: lägg till automatiserade kontroller som flaggar när en källa slutar skicka data, när ett fälts distribution skiftar oväntat, eller när ett antal oväntat faller till noll. En instrumentpanel som tyst renderar föråldrad eller trasig data som om den vore aktuell är värre än en instrumentpanel som synligt visar “data otillgänglig,” eftersom den första eroderar förtroende osynligt medan den andra åtminstone berättar sanningen om sina egna begränsningar.

Dokumentera insamlingsmetoden vid sidan av definitionen

Ett mätetals definition (“ledtid för ändringar”) är inte komplett utan dess insamlingsmetod (mätt från första committidsstämpeln i versionskontroll till produktionsdriftsättningstidsstämpeln i pipelinen, exkluderande snabbrättningsgrenar). Två team med samma definition men olika insamlingsmetoder kommer fortfarande producera ojämförbara tal. Registrera båda i metrikstadgan från ämne 1.4, och behandla en ändring av endera som en ändring som kräver samma dokumenterade granskning.

Avvägningar: fördelar och nackdelar

Källtyp	Fördelar	Nackdelar
Automatiserad pipelineinstrumentering (CI/CD, versionskontroll)	Objektiv, tidsstämplad, svår att förfalska, låg löpande insats	Kräver initial ingenjörsinvestering att bygga och underhålla
Ärendehanterings- och projekthanteringsdata	Allmänt tillgänglig, bekant för team	Beror på mänsklig noggrannhet; ofta inkonsekvent mellan team
Enkäter och självrapportering	Enda källan för subjektiv upplevelse (nöjdhet, välbefinnande)	Minnesbias, social önskvärdhetsbias, svarströtthet
Observerbarhets- och telemetriplattformar	Rik, realtids, systemnivåsignal	Täcker bara vad som explicit instrumenterats; kan bli dyrt i skala

Den centrala spänningen är objektivitet kontra täckning. Automatiserad instrumentering är den mest tillförlitliga källan men kan inte observera subjektiv upplevelse alls, medan enkäter kan nå exakt vad automatisering inte kan men bär verklig biasrisk. Lös spänningen genom att använda automatiserad instrumentering varhelst en händelse kan observeras direkt, och reservera självrapportering specifikt och bara för vad som genuint kräver att fråga en person, aldrig som ett lathundssubstitut för data ett system kunde ha tillhandahållit.

Frågor att diskutera med ditt team

För våra fem viktigaste mätetal, kan vi namnge det exakta källsystemet och insamlingsmetoden för vart och ett, eller antar vi en definition utan att veta var datan faktiskt kommer ifrån? Det här är ett förvånansvärt vanligt glapp: ett mätetal adopteras från ett ramverk eller en leverantörs standardinstrumentpanel, och ingen i det nuvarande teamet vet faktiskt vilket system som genererar den underliggande datan eller hur. Spåra var och en tillbaka till dess ursprung som en gruppövning.
Vilka av våra mätetal förlitar sig på självrapportering för något ett system kunde observera direkt, och vad skulle det krävas för att ersätta den självrapporteringen med verklig instrumentering? Självrapporterade driftsättningsantal, självrapporterade arbetstimmar, och självuppskattad cykeltid är alla vanliga exempel på att använda fel datakälla för något automatisering kunde fånga mer tillförlitligt. Identifiera de här och prioritera att ersätta dem med högst insatser.
Hur skulle vi veta om en av våra datapipelines tyst gick sönder? De flesta organisationer upptäcker en trasig mätetalspipeline bara när någon märker att ett tal ser orimligt ut, vilket kan ta månader. Diskutera om någon av era pipelines har automatiserade hälsokontroller idag, och om inte, vilka som mest behöver dem först.
Var har en översättning mellan system ändrat ett mätetals betydelse utan att någon bestämde det med avsikt? Ett fält som betyder en sak i ett källsystem kan betyda något subtilt annorlunda efter en integration eller migrering, och det resulterande talet kan se rimligt ut samtidigt som det har fel. Gå igenom er mest betydelsefulla mätetals fulla datasökväg och leta efter översättningspunkter.
Dokumenterar vi insamlingsmetoder, inte bara definitioner, för vår metrikstadga? Två team kan dela ett mätetals namn och definition medan de beräknar det från olika insamlingsmetoder, och producerar tal som faktiskt inte är jämförbara. Granska ett urval av era stadgar mot det här specifika glappet.
Hur skiljer vi mellan en genuin trend och en datakvalitetsartefakt när ett tal rör sig oväntat? Ett plötsligt skifte i ett mätetal är ofta det första tecknet på antingen en verklig förändring eller en trasig pipeline, och att skilja de två kräver att känna till datakällan tillräckligt väl för att utreda snabbt. Diskutera ert teams faktiska process för det senaste oförklarade mätetalsskiftet ni stötte på.

Sektorperspektiv

Startup. Med en liten stack kan de flesta av era mätetal komma direkt från er CI/CD-leverantör, versionskontrollvärd, och ett lättviktigt enkätverktyg, utan att bygga anpassade pipelines. Risken är att hoppa över även grundläggande hälsokontroller eftersom teamet rör sig snabbt; en femminuters automatiserad kontroll att en datakälla fortfarande skickar händelser är billig försäkring mot att tyst flyga blint.

Litet företag. Luta er mot den inbyggda rapporteringen i era befintliga verktyg istället för att bygga anpassade datapipelines ni saknar kapaciteten att underhålla. Var explicita om vilka tal som kommer från automatiserade system och vilka som är uppskattningar någon skriver in i ett kalkylblad, eftersom de två bär mycket olika tillförlitlighet, även om de hamnar på samma sida.

Stort företag. Datakvalitetsproblem förstärks över integrationer, migreringar, och affärsenhetsgränser. Investera i centraliserade, väl övervakade datapipelines för era mest betydelsefulla mätetal, bygg automatiserade datakvalitetskontroller som standardpraxis, och granska insamlingsmetoder, inte bara definitioner, närhelst mätetal jämförs mellan affärsenheter.

Myndighet. Dataproveniens kan bära juridisk och revisionstyngd: en publicerad prestationssiffra kan behöva överleva en extern revision av inte bara dess värde utan hela dess insamlingskedja. Dokumentera datalinjen explicit, behåll historiska insamlingsmetodregister även efter att en metodik ändras, och var beredd att demonstrera exakt hur ett tal producerades, inte bara vad det för närvarande visar.

Exempel

Stort företag. Ett finansiellt tjänsteföretags ingenjörsledning hade spårat “ledtid för ändringar” i två år innan de upptäckte att en datapipelinemigrering arton månader tidigare tyst hade bytt tidsstämpelkällan från första commit till skapandet av pull request, vilket förkortade den synbara ledtiden med i genomsnitt flera timmar över varje team utan att någon märkte eller godkände ändringen. Lösningen instiftade en datakvalitetskontroll som jämförde varje mätetals distribution vecka för vecka och flaggade statistiskt ovanliga skiften för mänsklig granskning, vilket fångade ytterligare två tysta pipelineproblem under det följande året.

Myndighet. En transportmyndighets offentliga instrumentpanel för tjänstetillförlitlighet förlitade sig på en blandning av automatiserad sensortelemetri och manuellt inmatade incidentrapporter från regionala kontor. En revision fann att regioner med mindre personalkapacitet systematiskt underrapporterade mindre incidenter, inte av oärlighet utan helt enkelt eftersom manuell inmatning konkurrerade om tid med mer brådskande arbete, vilket betydde att den publicerade tillförlitlighetssiffran var bättre än verkligheten exakt i de regioner som minst hade råd att låta underresurssatt underhåll gå obemärkt. Myndighetens lösning ersatte manuell incidentinmatning med automatiserad sensorutlöst loggning varhelst genomförbart och lade till en dokumenterad uppskattning av manuell rapporteringstäckning vid sidan av den publicerade siffran.

Verksamhetsnytta: motiv, ROI och TCO

Avkastningen på solid instrumentering är förtroende: en ledningsgrupp som litar på sin data kan agera på den beslutsamt, medan ett team som bränts av en tyst trasig pipeline börjar ifrågasätta varje tal, vilket saktar ner varje beslut som beror på mätetal. Den förlusten av förtroende är dyr och svår att reparera, och tar ofta mycket längre att återuppbygga än vad den ursprungliga instrumenteringsinvesteringen skulle ha kostat.

Den totala ägandekostnaden för god instrumentering inkluderar det initiala ingenjörsarbetet att bygga tillförlitliga pipelines och den löpande kostnaden för datakvalitetsövervakning, båda lätta att underinvestera i eftersom ingen av dem producerar en synlig instrumentpanelsruta av egen rätt. Den underinvesteringen är falsk ekonomi: kostnaden för att upptäcka en tyst trasig pipeline efter månader av beslut fattade på dålig data är mycket högre än kostnaden för att bygga de hälsokontroller som skulle ha fångat det dag ett.

Antimönster och fallgropar

Att lita på ett tal utan att veta dess källsystem: ett mätetal adopterat från ett ramverk eller leverantörsstandard utan att någon spårar var datan faktiskt kommer ifrån.
Att självrapportera vad ett system kunde observera direkt: introducerar onödigt brus och bias i data som kunde ha varit objektiv.
Inga automatiserade datakvalitetskontroller på en mätetalspipeline: en tyst trasig pipeline kan rendera fel tal i månader oupptäckt.
Att bara dokumentera definitionen, inte insamlingsmetoden: två team med samma mätetalsnamn kan ändå beräkna ojämförbara tal.
En instrumentpanel som renderar “0” eller föråldrad data som om aktuell, utan indikation på ett källfel: värre än ett synligt “data otillgänglig”-meddelande.
Underresurssatta regioner eller team som systematiskt underrapporterar på grund av manuell inmatningsbörda: ett datakvalitetsglapp som korrelerar med exakt de områden som behöver mest uppmärksamhet.

Mognadsmodell

Nivå 1, Initiera: Ingen kan tillförlitligt spåra ett mätetal tillbaka till dess källsystem; pipelines har inga hälsokontroller och misslyckanden går obemärkta.
Nivå 2, Utveckla: Vissa mätetal har dokumenterade källor, men insamlingsmetoder är inkonsekventa och datakvalitetskontroller är ad hoc i bästa fall.
Nivå 3, Standardisera: Varje styrt mätetal dokumenterar sitt källsystem och insamlingsmetod; automatiserade pipelines föredras framför självrapportering varhelst en händelse kan observeras direkt.
Nivå 4, Hantera: Automatiserade datakvalitetskontroller övervakar varje betydelsefull pipeline, flaggar anomalier för granskning, och datalinjen är dokumenterad och granskningsbar.
Nivå 5, Orkestrera: Organisationen behandlar datakvalitet som en förstklassig ingenjörsdisciplin med sin egen övervakning och incidentrespons, och kan demonstrera full proveniens för vilket publicerat mätetal som helst på begäran.

Diskussionsidéer

Skulle vi kunna spåra våra tre viktigaste mätetal tillbaka till deras exakta källsystem just nu, live, i det här mötet?
Vilka av våra nuvarande mätetal förlitar sig på självrapportering för något ett system kunde mäta direkt?
Har någon av våra mätetalspipelines automatiserade hälsokontroller idag?
När upptäckte vi senast en tyst trasig datapipeline, och hur länge hade den haft fel?
Var skapar manuell datainmatning ett glapp mellan rapporterad och faktisk verklighet?

Viktiga slutsatser

Föredra automatiserad instrumentering framför självrapportering varhelst ett system kan observera händelsen direkt; reservera självrapportering för genuint subjektiv upplevelse.
Varje mätetal behöver ett dokumenterat källsystem och insamlingsmetod, inte bara en definition.
Datakvalitet förfaller tyst; bygg automatiserade kontroller in i själva pipelinen istället för att upptäcka haveri av misstag.
Instrumentera vid händelsen, inte nedströms av en översättning, för att minimera glidning mellan vad som hände och vad instrumentpanelen visar.
Kostnaden för en tyst trasig pipeline, månader av beslut fattade på dålig data, överstiger vida kostnaden för de hälsokontroller som skulle ha fångat den.

Källor och vidare läsning

Observability Engineering, av Charity Majors, Liz Fong-Jones och George Miranda (principer för instrumentering och telemetridesign).
Accelerate: The Science of Lean Software and DevOps, av Nicole Forsgren, Jez Humble och Gene Kim (instrumenteringsansatsen bakom DORA-mätetalen).
Data Quality: The Accuracy Dimension, av Jack E. Olson (datakvalitetskoncept tillämpliga på mätetalspipelines).
How to Measure Anything, av Douglas W. Hubbard (mätmetoder för kvantiteter som verkar svåra att observera direkt).