Byg bro mellem udvikling og administration
Mange af os kender historien. Det er fredag eftermiddag og lige et kvarter før lukketid ringer telefonen: "Hej, det er $udvikler. Jeg er lige igang med at sætte en ny version af $produkt i drift, men jeg skal lige have åbnet for mail-adgang til serveren. [...] Chefen siger at det skal i drift nu". Man ved også godt hvor lang tid der vil gå før man har chefen i røret, så den eneste tanke der går gennem hovedet er "Down, not across".
Vi kan bygge en mur af bureaukrati op omkring os for at undgå den slags sløsede ændringer. Den gennemsnitlige programmør vil let bruge 20 minutter på at gennemskue om det er Problem Management, Change Management eller Configuration Management han skal have fat i og så er opgaven let udskudt til på mandag. Men ville det ikke have været lettere at fange problemet på forhånd?
Man kan forsøge at sætte sig med hænderne i skødet indtil udviklerne ser lyset. Men jeg tror at man kommer til at vente lang tid. Men hvad kan som administrator gøre proaktivt? Her er mine bud:
Involver dig i designfasen! Mange problemer med sikkerhed og skalering er lettest at håndterer hvis de fanges tidligt i udviklingsfasen. Det er her du skal ind og finde løsninger der passer med jeres sikkerhedspolitik og komme med forslag der hjælper skaleringsproblematikken.
Lav virtualiserede, lettilgængelige testmiljøer! Uanset om testmiljøet er udviklerens workstation eller en dediceret server, så har de det med at ganske langsomt at skride længere og længere væk fra driftsmiljøet. Hvis udviklerne med et enkelt klik på en knap kan få adgang til et helt frisk testmiljø, næsten identisk med driftsmiljøet, så kan du forvente en meget mere præcis liste af ændringer for at få en ny version til at virke.
Sæt små ændringer i drift! Måske den største kamel at sluge, men hvis du vil have et stabilt system, så sæt mindre ændringer i drift oftere. Mindre ændringer er lettere at håndtere og alt andet lige så kan udvikleren bedre huske hvad han egentlig skal have ændret, hvis det bliver sat i drift med det samme.
Kom med konstruktiv tilbagemelding! Hvis det du får fra udviklerne ikke virker, så lad være med at opfører dig som en bruger. "Det virker ikke mumle mumle mumle" er hverken særlig hjælpsomt når det kommer fra dine brugere eller når du siger det til udviklerne.
Vær system-eksperten! Det er dig der kender jeres systemer fra den daglige drift. Du kan se hvad flaskehalsen er når I har skaleringsproblemer. Du ved at I kører NFS og at låsning af filer derfor ikke helt virker som systemdokumentationen siger. Brug den viden så I i fællesskab kan få et bedre system.
Hvad gør du for at lette samarbejdet mellem udviklere og administratorer?
Om Peter MakholmKommentarer (6)
Jeg bliver mere og mere overbevist om, at udviklere selv skal stå for driften af det system de laver. Det har i mine øjne flere fordele:
Udviklerne får førstehåndserfaring med systemet i produktion, og derved en meget bedre forståelse for hvordan det samlede systemet hænger sammen.
Der er et stort incitament for at automatisere og effektivisere driftsopgaver. Derved skabes mere overskuelige og stabile systemer.
Værdien af kvalitetssikring bliver tydelig. Udviklerne får direkte besked når de introducerer fejl. For eksempel klokken 3 om natten :-).
Det er muligt at et tværfagligt team, bestående af både udviklere og driftsfolk vil opnå det samme. Er der nogle der har erfaringer med dette?
-
0 -
0
Fejltagelse nr. 1. "Hej, det er $udvikler. Jeg er lige igang med at sætte en ny version af $produkt i drift." Udviklere skal aldrig have generel adgang til produktionsmiljøet, og specifik adgang bør kun foregå i forbindelse med udførelsen af en konkret change request, som selvfølgelig er afprøvet i et testmiljø, og som er verificeret i alle ender og kanter. Så problematikken "men jeg skal lige have åbnet for mail-adgang" burde slet ikke kunne opstå, for det burde være beskrevet i dokumentationen af den pågældende change, med identifikation af den ansvarlige for lige netop den delopgave.
Men hvad så? Nogen skal jo gøre det? Ja - driftsfolk, selvfølgelig. Og hvis applikationen er så kompleks, at det ikke er muligt for en vilkårlig administrator at udføre changen, så skal der allokeres tid til at sætte et par mand ind i applikationens spidsfindigheder. Det kan enten være folk fra driftsgruppen, eller driftsfolk som er permanent forankrede i udviklingsgruppen, men ikke har primær fokus på udvikling af kode. Mængden af folk som både har adgang til produktionsmiljøet (og dermed produktionsdata) OG til koden bør være så lille som overhovedet mulig, alene af principielle sikkerhedshensyn.
Jeg har et par gange siddet som næsten-udvikler/næsten-driftsmand i et projekt, og det er som jeg ser det en hensigtsmæssig, men overset rolle. Udviklere skal ikke stå for driften, fordi udviklere ofte - i min erfaring - har ret snævert fokus på applikationskoden og ikke på systemet som helhed. Ting man kan leve med i et udviklingsmiljø ("vi prøver lige og ser hvad der sker") er bare ikke acceptable i produktionsmiljøet.
Det giver også mulighed for at automatisere, effektivisere og kvalitetssikre driftsopgaver på en langt mere hensigtsmæssig måde, end hvis driftsafdelingen skulle gøre det, som Peter Mechlenborg er inde på. Så ud over at jeg mener det skal være en person med driftsfokus er jeg enig med PM.
I et firma jeg har været i, var rollen vist næsten "formaliseret" under navnet "gatekeeper". Her var den forankret i udvikling, med en ret krævende driftsafdeling i modtagerenden. Jeg havde dog ikke adgang til produktion, til gengæld var der et snævert samarbejde med driftafdelingens folk.
I mit sidste job udkrystalliserede rollen sig også ret naturligt på det projekt jeg var på, men da jeg senere til en medarbejdersamtale med en ny leder (forbandet være matrixorganisationen!) forsøgte at forklare hvorfor jeg mente netop den rolle (som jeg vil karakterisere som en slags diplomat eller forhandler mellem drift og udvikling, men på "hands-on niveau") var vigtig, blev jeg skudt i skoene at jeg "bare ville svæve over vandene og ikke rigtigt lave noget". Jeg var lamslået. Siden har jeg tænkt jeg burde have sagt: "Nej, det er jo ikke en ledelsesfunktion det handler om."
Desværre er der vist langt imellem ledere som forstår ideen med "gatekeeper"funktionen - måske fordi udviklingschefer og driftschefer tror at det er den andens ansvar? Jeg har i hvert fald søgt efter en stilling med det indhold temmelig længe efterhånden...
Jeg kunne derfor vældig godt tænke mig at høre hvor andre mener den rolle naturligt bør være forankret? Drift eller udvikling?
-
0
-
0
Det er lidt sjovt, hvordan de første par svar her ser problemet så forskelligt. Jeg laver selv både udvikling og drift på et par systemer, og kan da både se fordele og ulemper. Men det der slog mig mest ved blog-posten var, at der var en chef der reelt troede, at noget skulle i drift en fredag eftermiddag?
Min ledelse og jeg har en fælles forståelse for, at idriftssættelse af ting "lige inden dem der kan fikse det går hjem" er en skidt ting. Det er sjældent der kommer noget godt ud af den slags panik-deployments alligevel.
-
0
-
0
idriftssættelse af ting "lige inden dem der kan fikse det går hjem"
Jeg erindrer en IT chef der godkendte en driftstart på en fredag.
Lige før de var klar til at "trykke på knappen" stak han hovedet ind for at se hvor soveposerne var, mens han pegede i den del af driftstart-politiken der omtalte den nødvendige døgnvagt mv.
Så blev driftstarten skubbet til mandag i stedet, hvilket han pudsigt nok allerede havde skrevet i sin kalender.
Det gør underværker når ledelsen tar driftkvaliteten alvorligt.
Poul-Henning
-
0
-
0
Jeg vil da ikke sige jeg ser det så meget forskelligt fra Peter Mechlenborg. For mig at se er DevOps (tusind tak for det ord, Martin! Hvorfor er jeg ikke stødt på det før?) naturligt forankret i udvikling, men det skal bare ikke være vilkårligt hvilke udviklere der løser opgaverne; det skal være nogen med driftsfokus og -forståelse. Jeg tror det værste man kunne gøre var fx at give hver enkelt udvikler ansvaret for deployment af den kode han har udviklet.
/Lasse
-
0
-
0
Tilføj kommentar
