En gammel sur ost

Har du nogensinde været så heldig at have kode der skulle sættes i produktion ?

Så har du sikkert også været så heldig at møde en rigtig sur, gammel driftsmand som har gjort sit bedste for at DET projekt IKKE skulle lykkes !!!

En hændelse fra det virkelige liv...

Jeg har lige deployet nyeste version af min kode i produktionsmiljøet. Uret tikker for jeg befinder mig i et servicevindue af en times varighed og l.... SKAL bare funke første gang, da det er en kompleks deployment.

Pludselig falder det mig ind: Arh Scheisse, jeg skal også bruge mail adgang fra serveren. Stupid, silly cow....

Jeg griber knoglen og ringer til driftsafdelingen.
Dette er folkene vi ALDRIG møder i kantinen SELVOM de holder til lige overfor mit kontor. Jeg vil kunne se ind til dem, hvis de ikke havde valgt at få monteret tonet glas på deres facade.

Men jeg ringer op og får fat i deres super-mega overseje hardcore super-duper ekspert indenfor firewalls. Wauw - hvor heldig kan man være...

Kort introduktion. "Jeg vil gerne have åbnet for standard SMTP trafik på server x.y.z.x".
"Njah", lyder svaret. "Det kan jeg ikke klare. Jeg skal bruge de portnumre du skal have åbnet".
Duh, tænker jeg. Måske er det en imitator, som tror firewalls er noget man brænder fingrene på ?
Jeg prøver igen. "S-M-T-P", staver jeg for manden. Nu er jeg stædig...
"Hvilken port", siger en stemme så forladt af empati og forståelse at den sagtens kunne tilhøre en galning der i al hemmelighed skærer små grise i tusind stykker med en neglefil, mens vi andre sover...
"Jaeh, 25?". Jeg giver op og giver informationen.
"Nå, jamen det kunne du jo bare have sagt".

Er det økologisk ?

Ok, ovenstående er jo ikke verdens største hurdle, men desværre kun ét ud af mange eksempler på hvor defensiv, reaktionær og godt gammeldags træls en driftsafdeling kan reagere.

Tro mig: Jeg HAR mødt "økologiske" driftsafdelinger som i det mindste forsøgte at udvise forståelse og levede sig ind i problemerne.
Det er OK, at bruge lidt tid på i fællesskab at finde frem til problemerne.
Og ja, vi må gerne ringe og forstyrre når I arbejder i Incident Management for crying out loud !!!!

Hvorfor skal vi overhovedet forsøge at være agile og arbejde på at sætte udviklingshastigheden i vejret, når vi gang på gang på gang på gang ender med at blive stoppet af en lukket port i en firewall ''?

Nogle har sågar opfundet en protokol der tager højde for denne konstante barriere - nemlig Web Services. Nu tager vi den port de ALTID har åben og fyrer vores data ind igennem. Haha - tag den, Gammel Smølf !

Men lad os nu alle tage hinanden i hånden og sammen se vores frygt i øjnene.
Vi frygter driftsafdelingen og alle dens gerninger. De gemmer vores servere for os, de æder vores sjæl og dræber vores konkurrenceevne.

Havde jeg en ekstra strømskinne og en dieselgenerator i overskud, ja så startede jeg sgu et driftsselskab i morgen ![Eksternt billede](http://www.version2.dk/uploads/smil3dbd4d6422f04.gif" alt=")

Kommentarer (16)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Jan Vestergaard Larsen

Først kort forklaring på overskrift. Jeg er selv tidligere udvikler som solgte min sjæl til det "onde" ved at flytte fra udviklings- til driftafdelingen. Eller måske er udviklingsafdelingen det onde?

Det er en underlig holdning som du jo netop fremfører her. Sådan så jeg selv på forholdet mellem udviklings og driftafdeling det første lille stykke tid jeg var udvikler også. Men så kom jeg til at tænke på at driftafdelingen gør det arbejde de er sat til at varetage. Nemlig at "vogte" driftmiljøet. Der er en god grund til ting skal være velbeskrevet og veltestet før det køres i produktion!

Udover lysten til at prøve kræfter med drift og teknisk videreudvikling, var en af de ting jeg virkelig ønskede mig at bidrage til da jeg flyttede afdeling at skabe bedre kommunikation og forståelse mellem de 2 afdelinger i den virksomhed jeg er ansat i. En opgave jeg stadig her små 3 år efter arbejder på. Det er en betydelig større opgave end ventet, men jeg elsker en god udfordring - og en udfordring er det at få udviklere og driftfolk til at snakke godt sammen har det vist sig.

Så om jeg er en naiv exudvikler eller en sur (gammel) driftmand ved jeg ikke. Selv mener jeg bare jeg er en medarbejder, der vil have tingene til at fungere og sørge for vi som driftfolk, og vores kollegaer udviklerne, har det sjovt - og godt - med det arbejde vi laver.

  • 0
  • 0
#2 Maciej Szeliga

...dog ikke den som du arbejdede med men i samme slags afdeling.

Du kan køre din SMTP trafik gennem firmaets mailserver ellers kan det ikke lade sig gøre og i øvrigt burde du have afklaret din kodes behov (og muligheder) for adgang til ydersiden på forhånd. Hvis du som udvikler ikke ved hvad din kode behøver så tyder det på at koden ikke er færdigtestet og dermed ikke klar til at gå i drift.

vh. Sur Ost IT-Drift

  • 0
  • 0
#3 Død Profil

.. er en protokol, som godtnok har IANA-tildelte porte (for tcp og udp), men kan bruges med alle porte. Derudover er firewalls ofte "til/fra" specificerede, ikke nok med "fra".

Lidt det samme som når driften ringer og siger nu har de installeret Java på serveren og man som udvikler tænker, "gad vide hvilken impl. og version".

Det er bare svært at forstå hinanden udenfor sit eget domæne, man skal være meget præcis i hvad man ønsker, ellers får man det som regel ikke :)

Godt forhold i mellem afdelinger er også svært, så det er ikke altid man "bare lige" kan gå og spørge, selv om kontoret ligger lige ved siden af.

  • 0
  • 0
#4 Tommy Dejbjerg Pedersen

Tak for de gode kommentarer !

Mistforstå mig ikke, jeg har stor respekt for driftsafdelingens rolle i forhold til at være vogtere over for de "skøre" udviklere der kan finde på hvad som helst uden respekt for stabilitet og sikkerhed i driften :-)

Jeg beder blot om en fornuftig dialog mellem afdelingerne og derfor er det også fedt at høre om dine erfaringer Jan, som jo netop tager fat på brobygningen. Stor respekt for det!

SMTP eksemplet var (måske et dårligt eksempel :-) ), men der er jo en hel perlerække af eksempler at tage ud fra. I den afdeling jeg på det tidspunkt befandt mig i, var folk generelt bange for at tage kontakten til driftsafdelingen fordi de netop ikke havde de færdigbryggede svar klar, men havde brug for lidt sparring. Så kan man sige at det er en mærkelig måde at reagere på for mine med-udviklere, men de havde travlt med at sætte sig ind i en masse ny teknologi og kunne ikke gennemskue driftsrelaterede issues uden hjælp fra driftsafdelingen.

Efterfølgende har jeg flere gange været konsulent i en række projekter hvor jeg tit fik den rolle at jeg skulle tage fat i driftsfolkene, fordi de fastansatte ikke længere kunne finde ud af at føre en dialog med dem. Når en deadline afhænger af om man tør at ringe til en sur driftsmand, så mener jeg at der er et reelt problem.

Jeg mener generelt det er usundt for et projekt og for en virksomhed, såfremt afdelingerne ikke kan snakke sammen på en konstruktiv måde.

Er det et ledelsesproblem kan man spørge? Ikke isoleret set synes jeg - det starter ved den enkelte udvikler og driftsmedarbejder, som bør tænke i at være imødekommende.

Næste blogindlæg kunne måske hedde "En lidt for frisk ost" og handle om de sløsede udviklere set fra driftsafdelingens perspektiv ? :-)

  • 0
  • 0
#6 Klavs Klavsen

Så jeg kan da nævne at mine erfaringer med at sætte "nyudviklede/opdaterede" applikationer i drift, er at driftsfolkene slet ikke bliver inddraget i udviklingen af denne.

Det bliver normalt smidt på bordet som "færdigt - sæt så i drift", på trods af at det så forventes at applikationen skalerer op til det ønskede behov og har "tæt på" 100% oppetid.

Desværre så indser de færreste udviklere at for at en applikation skal være stabil i drift (skalerbar og fejltolerant etc.) så skal det designes ind fra starten af, ellers kan man nemt komme til at træffe nogle designvalg, som gør det nærmest uopnåeligt i virkeligheden (drift).

Mit råd vil være at få en god driftsmand, der også har forstand på at programmere (de findes - typisk har mange unix folk også programmørevner, fordi de laver en masse scripting etc.) og sørg for at inddrage ham i designbeslutningerne, så han kan stille alle de spørgsmål der er relevante for drift, under designet af applikationen. På den måde, er applikationen virkelig klar til drift, når udviklerne er færdige, og drift ved at deres behov er blevet imødekommet, således at de har mulighed for at leve op til de krav der stilles til dem.

Sådan kort fortalt :)

  • 0
  • 0
#7 Søren S. Nielsen

"Mistforstå mig ikke, jeg har stor respekt for driftsafdelingens rolle i forhold til at være vogtere over for de "skøre" udviklere der kan finde på hvad som helst uden respekt for stabilitet og sikkerhed i driften :-)"

Forklar mig lige hvordan DU ud fra dit indlæg adskiller dig fra de "skøre" udviklere? Hvis du ikke har inkluderet driften i udviklen af dit projekt, men som 99% af alle andre bare smider et projekt på bordet og råber "I DRIFT! NU!" i forventing om at det så kommer til at virke 100% så står du i min bog på listen over de skøre.

Der er dage hvor jeg overvejer at søge job på en fabrik og putte ting i kasser, for drift er simpelthen det mest utaknemmelige job i verden.

Når alt går godt er vi nogle vrangvillige oste der ikke vil snakke i kantinen.

Når tingene går sydpå, servere vælter og netværk går ned, så er vi nogle tosser der ikke gør det godt nok.

Kunne det tænkes at et stabilt miljø kræver mere end konstant strømforsyning? At der er load balancing der skal laves, incidents der skal efterforskes så fremtidige hændelser kan forebygges? At levere stabil IT infrastruktur er ikke bare at tænde for serverne - Det kræver en konstant indsats.

Når en udvikler så stolt åbner døren med et projekt i hænderne han forventer at have i drift dagen efter tænker man først på resten af firmaet der forventer at deres servere og netvæk kører upåklageligt som altid. Hvis noget nyt skal implementeres OG status quo skal opretholdes på trods af denne nye variabel og potentielle fejlkilde så må man kende det nye projekt til bunds. Hvis så udvikleren af projektet knap ved hvilke porte der skal åbnes i hvilke retninger ville jeg ikke stole på at hans projekt var sundt for netværket.

Vi vil hjertens gerne være agile. Men for hver udvikler der synes vi skal være agile er der 99 andre ansatte der synes vi skal være stabile.

  • 0
  • 0
#8 Klavs Klavsen

Og så glemte jeg lige at tilføje, at udover skalerbarhed, så "glemmer" man ofte at checke svartider i driftsmiljøet. Har set flere "mystiske" situationer, hvor tingene kørte fint på udviklernes egne arbejdsstationer (hvor de kun er en bruger osv.), men var laaangsomt i driftsmiljøet - uden at det iøvrigt var fordi driftsserveren var optaget på nogen måde.

Eksempler på underlige programmører, der f.ex. istedet for at bruge en pre-eksisterende dato funktion til at fortælle dem hvilken uge de var i, kaldte en funktion på deres egen hjemmeserver (via http) osv. osv. har jeg mange historier om :)

Så sørg endelig for at have et realistisk test-miljø som, afhængig af behov, kunne blive det fremtidige driftsmiljø (isoleret som ønsket).

  • 0
  • 0
#10 Jan Flodin

Tommy skriver: Og ja, vi må gerne ringe og forstyrre når I arbejder i Incident Management for crying out loud !!!!

Men Tommy i henhold til ITIL hører det problem du står med i den pågældende situation IKKE hjemme i Incident Management. Du burde i stedet have haft din nye kode kørt gennem jeres Change Management proces, og hvis den var sat ordentligt op med de rigtige mennesker så havde du undgået problemet.

Overordnet set er din blog dog udtryk for den evige krig mellem forretningsudvikling og drift. Udviklingsfolkene lever af forandringer - dynamiske forandringer og jo flere jo hurtigere jo bedre kan man få et indtryk af. Derfor har man nu opfundet SOA så ændringer kan ske bare ved at sætte nogle (service)klodser sammen på en ny måde.

Men er der noget driftsfolkk hader så er det forandringer for de ved at 80 % af IT problemerne opstår som følge af dårligt styrede ændringer. Derfor har de opfundet ITIL.

Ingen af disse nye "hypes" vil dog løse nogen problemer med mindre man får lært udviklings- og driftsfolk at forstå og respektere hinanden og hinandens modsatrettede behov.

  • 0
  • 0
#12 Lasse Hillerøe Petersen

"Du burde i stedet have haft din nye kode kørt gennem jeres Change Management proces, og hvis den var sat ordentligt op med de rigtige mennesker så havde du undgået problemet."

Er den virkelige WTF (findes der i grunden en fordansket ækvivalent?) ikke der hvor Tommy siger, at han "har lige deployet nyeste version af min kode i produktionsmiljøet"?

Eller er det bare mig der har været så heldig at være steder, hvor der er i hvert fald principielt er separation af udvikling og deployment, og hvor alt først prøvedeployes til et test/stagingmiljø?

Det er klart at de steder hvor drift er indskrænket til netværk, strøm, hardware og køling, vil det ikke være driftsafdelingen der står for deployment. Men så må det være en udvikler der får det ansvar. Og principielt bør vedkommende nok ikke have skrevet det kode der deployes.

Hvad ITIL angår, så tror jeg det lidt handler om at driftsfolk er umådeligt dårlige til at sælge ITIL til udviklere og arkitekter. Og jeg tror der er en verden til forskel på et system, som er designet med ITIL-styret drift i tankerne, og et hvor ITIL bliver forsøgt presset ind bagefter...

Eller "kunne være" - har nogen set et system hvor dette faktisk er sket: at ITIL var tænkt ind fra starten?

Kommentaren om at "forstyrre når I arbejder i Incident Management", ved jeg ikke helt hvad vej vender, og incidents kan være flere ting; men jeg vil bare sige at ved tilstrækkeligt alvorlige incidents er der en pæn risiko for en brosten i nakken eller lignende, hvis man forstyrrer mig med noget der ikke er relateret til det incident. Det er vel det ServiceDesk er til.

I øvrigt vil jeg gerne tilslutte mig de andre kommentarer der antyder at drift og systemadministration er et pokkers utaknemmeligt job. Gør man det rigtigt godt, bliver man usynlig og "overflødig", og gør man det bare nogenlunde godt har man altid nogen på nakken.

(Derudover er det helt rigtigt set, at der mangler nogen til at bygge bro mellem drift og udviklere. Den "gatekeeper" rolle er om muligt endnu mere utaknemmelig end ren drift - og af en eller anden grund havner jeg altid i den suk...)

-Lasse "Down, not across!" (a.s.r motto!)

  • 0
  • 0
#13 Deleted User

Tommy, tak fordi du lige har genopfrisket min hukommelse fra tiden i en større dansk virksomhed :) Det er virkeligt nostalgisk at læse både din blog og de kommentarer der er kommet ind. Det er fuldstændigt som at være tilbage i hin udviklingsafdeling igen :)))

Diskussionen og argumenterne er præcis de samme, men tillad mig alligevel at give et indspark.

SMTP eksemplet er perfekt. For det viser netop dilemmaet som udviklerne står i. De ved nemlig IKKE at SMTP i virkeligheden kan køre over en valgfri port. Det skal man være netværks-nørd (altså "nørd" ment på den fede måde) for. HA! siger driftsfolkene. Det kunne vi godt fortælle, men vi bliver jo altid involveret i sidste øjeblik, lige 5 minutter i panisk idriftsættelse. Og det er jo et godt men p....-irriterende argument.

Problemet på min gamle arbejdsplads var bare, at når vi så forsøgte at få driftsfolkene involveret tidligere i projekterne, så havde de ikke tid fordi de skulle - ja... suk... - idriftsætte eller brandslukke et eller andet. På et tidspunkt var der en fyr i driften der kapitulerede: "Vi er en driftsorganisation, ikke en projektorganisation. Vi har ikke tid til at indgå i projekterne".

Perspektivet omkring SOA som den tekniske løsning er sødt, og helt igennem på sin plads for vi nørder, men jeg tror nu også vi kunne komme langt med at erkende, at drifts-nørderne også skal (have tid til at) involveres i projekterne.

My $2/100

  • 0
  • 0
#15 Lasse Hillerøe Petersen

Hvis udviklere ikke ved noget om netværk, burde de måske ikke kode noget der bruger netværk...?

Gendigtet dialog, som en gammel driftskollega D havde med en (ekstern) udvikler U en gang: U: Vi har brug for en fw-åbning for adgang til jeres testmiljø. D: Okay, jeg skal sørge for at skrive en Request for Change til netværksadministratoren. Hvilken IP-adresse tilgår I os fra? U: 192.168.17.240? D: D'oh!

-Lasse (enhver lighed med virkelige situationer, adresser osv er tilfældig.)

  • 0
  • 0
#16 Anonym

DER ER IKKE NOGET DER ER LIGE SÅ GODT SOM OST! JEG MÅ HAVE MERE OST, JEG LAVEDE INDBRUD I EN OST-BUTIK, FORDI JEG SKULLE HAVE OST!!!!!!

  • 0
  • 0
Log ind eller Opret konto for at kommentere