henrik knopper bloghoved

Hvis det kan testes kan det automatiseres

Ovenstående udsagn kom fra Goto-konferencen automater of all things Sascha Bates, som jeg fik lokket til en snak om løst og fast (interview er sådan et stort ord at bruge – det kunne endda sætte forventningerne til dette indlæg urimeligt højt…).

Hendes holdning var – naturligvis – at hvis det kan automatiseres så skal det.

Det store problem var at få folk til at gøre det. Til at bruge de værktøjer og scripts der blev stillet til rådighed.

Specielt i store virksomheder hvor folk var specialiseret i meget smalle arbejdsprocesser var det en udfordring at ændre holdningen fra ”jeg flytter lige den bit selv og så kører det igen” til ”jeg ændrer lige den indstilling i konfigurations-scriptet og så kører det efter næste udrulning”.

Saschas erfaring var at det ikke var af ond vilje – Noone breaks things on purpose - men mere fordi folk følte at værktøjet ikke dækkede opgaven eller de kendte det ikke godt nok og så forsøgte de at kompensere efter bedste evne.

Hvilket næsten altid virkede, men hvis man har et system der checker konfigurationen på alle servere regelmæssigt kan det godt give frustration at en manuel fejlretning bliver overskrevet, for så oplever slutbrugerne at systemet er nede igen.

For mange af den slags oplevelser og så er et automatiseringsværktøj hurtigt dømt ude.

Men i miljøer hvor compliance er vigtigt – hun talte CIS, men jeg kunne genkende det fra både pharma og finans – er den hurtige, manuelle fejlretning alligevel tegn på at man ikke har kontrol.

Så uanset at det ifølge Sascha lige præcis er i de miljøer folk bliver mest skræmte ved tanken om at automatisere så er det der gevinsten vil være størst.

Og når det først er indført og virker bliver det – i princippet - meget lettere for udviklere og testere at få oprettet miljøer, da man kan oprette og nedlægge løbende i stedet for at oprette en gang og tilrette løbende.

Udfordringen for dem der vil indføre automatisering er at gøre det let at gøre det rigtige.

Nogen der har erfaringer de vil dele?

Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Klavs Klavsen

Forudsat at man husker, at dem der har root - SKAL kunne arbejde med det.

Jeg har personligt designet adskillige store firmaers miljøer, så de er fuldt automatiseret og jeg har næsten ikke lavet andet end automatisering de sidste mange år (af de ting jeg normalt altid har lavet - såsom overvågning, loadbalancering, server opsætning generelt osv. ).

Jeg bruger et værktøj der hedder Puppet - men uanset værktøjet, så gælder det at man må huske på, at Drift først og fremmest er en service funktion, og hvis man har uddelt root til ikke-drifts personer (udviklere) - så vil automatisering fratage dem noget kontrol de før havde (som du også beskriver, vil deres ændringer blive rullet tilbage jo) - men jeg har god erfaring med at også at få udviklere til at spille med i den situation og benytte Puppet, til at lave deres ændringer istedet.

Man skal bare huske på at Drift er en servicefunktion, og begynder man at automatisere, får man de største gevinster, ved at sørge for at en server er 100% automatiseret - og derved skal man sørge for at ALLE skal opleve det som en gevinst, og ikke som en gene (hvor de f.ex. tvinges til at oprette en sag og vente X tid, før nogen kigger på den osv. - for at de kan komme videre med deres arbejde).

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