fredag 10. juli 2009 Softwareutvikling Testing / TDD
På NDC 2009 hørte jeg bl.a. på Oren Eini (a.k.a. Ayende Rahien) snakke om Production Quality Software. Første del av sesjonen var ikke så veldig bra, men når han begynte å snakke om hvordan vi bør bygge inn driftsovervåkning i systemene våre ble jeg veldig inspirert.
Oren påpekte at drift er en viktig stakeholder i det meste vi lager, og at vi bør designe for dem. Vi bør synliggjøre systemets status og parametre på en god måte. Han foreslo at alle systemer (av en viss størrelse) bør ha en separat Operations Database som skal gi oss bedre innblikk i hva systemet til enhver tid driver med.
Ops-databasen skal inneholde observasjoner og forventninger. Observasjoner er det enkletse, og noe mange av oss gjør i dag. Å observere vil si å logge ting som skjer, som for eksempel "At date X I started some process Y with parameter Z". Denne informasjonen kan være nyttig i mange tilfeller, ikke minst ved feilsøking (som ellers kan være utfordrende i et produksjonssystem).
Forventninger er anderledes – det kan være ting som at "90% av alle transaksjoner skal fullføres innen 5 sekunder" eller "jobb X skal kjøre hver uke". Ops-databasen kan kontrollere disse forventningene, og trigge en eller annen form for alarm om en eller flere ikke er innfridd.
Hva hadde dette å gjøre med blogging sa du?
Det Oren spesielt foreslo var at systemet kan skrive til en blog. Alle systemer burde ha sin egen blog, og stakeholderne burde abonnere på bloggen. Bloggen til et system bør se ut og fungere som en blog skrevet av og for mennesker – titler og innhold i blogpostene må bestå av normalt språk, og det må ikke postes for hyppig (bedre å summere opp hendelser i én post om det skjer mye på en dag). Dette vil gi dem som leser bloggen et helt annet forhold til det bakenforliggende systemet.
Jeg syntes dette hørtes veldig spennende ut. Her er en mockup av hvordan jeg ser for meg en slik blog skal kommunisere:
De fleste systemer i drift har en SLA – en Service Level Agreement – som sier noe om hvordan systemet skal yte. Men vi, spesielt vi utviklere, har et alt for dårlig forhold til SLA'en. Hvordan vet vi at den er opprettholdt? Oren foreslår at Ops-systemet skal automatisere SLA'en. Systemet kjøre en automatisert audit, f.eks. hvert 30 minutt, som foretar spesifike operasjoner som innebærer database aksess, filaksess, eksekvering av prosesser, osv. Miljøet systemet kjører i kan verifiseres, tilgjengelig diskplass, responstid etc. kan måles.
Alle ulike komponenter i systemet bør ha sine egne SLA'er, og de må være laget sånn at det går an å verifisere dem. Disse vil fungere som automatiserte akseptansetester mens systemet er i drift. Observasjoner, forventninger og miljø-validering vil til sammen gi et komplett bilde av systemet i drift, man vil enklere kunne identifisere feil som inntreffer, og man vil kunne fange opp problemer før det blir så mange av dem at det får hele systemet til å "knele".
En detalj, men likefullt et viktig poeng, er at administrasjonsgrensesnittet, hvor man kan aksessere Ops-databasen, må være separat fra produksjonsgrensesnittet. Hvis produksjonssystemet går ned må man sørge for at man fortsatt har tilgang til Operasions.
For å oppsummere: Vi må designe systemene våre med tanke på drift. Vi har hørt det før, men gjennomfører det sjelden på en god nok måte. Vi må gi driftsfolkene det de trenger, men ikke gi dem for mye, for da mister de oversikten og fokuset på hva som er viktig. Å la systemet skrive en operations blog er et eksempel på et bra grensesnitt. Den viser kun nøkkeldata / hendelser. Og la Ops-systemet foreta automatiske system-verifiseringer gjevnlig for å fange opp problemsituasjoner tidlig, og for å bevise at vår fantastiske konstruksjon overholder SLA'en.
Du kan se Oren's Production Quality Software sesjon ved å følge denne linken.