Configuration Management

En af ulemperne ved at levere software som Open Source er at man bliver nødt til at levere noget kunden faktisk kan kompilere.

Lige nu sidder jeg og dokumenterer hvorledes en af mine kunder kan bygge al den software jeg har leveret.

Alt i alt er det nok ikke sandsynligt at de nogensinde vil gøre det, for til trods for min dokumentation, skal en eller anden sætte sig ind i det, finde en maskine osv. osv. Det er helt klart nemmere for dem at ringe til Slagelse.

Men busquotienten er forholds vis lav, så det skal kunne lade sig gøre og derfor sidder jeg nu med en 6.2-RELEASE-i386-disc1.iso og en notesblok.

Den slags arbejde kaldte man i gamle dage "Configuration Management" men det er tilsyneladende ikke noget vi bruger mere.

Ihvertfald hørte jeg igen om en forholdsvis stor edb-installation hvor "relikviet" var gået ned og gode dyr var rådne. Jo, man havde en backup og man havde læst den ind, men der var noget der ikke virkede et sted og man der kendte til den engang var vist kloakarbejder i Ulan Bator eller muligvis bare ansat hos en konkurrent.

Ja ikke ? Den har vi hørt så mange gange at den ikke engang er sjov mere.

CM arbejde tager tid og det er trælst indtil man får lidt rutine i det. Derfor er der ikke er nogen, hverken ledelsen eller medarbejderne, der skubber på vognen.

Det burde ellers være gefundenes freßen for ISO9000 indsatsen, CM handler i bund og grund om hvordan man reproducerbart kommer fra en stak distributionsmedier til et fungerende system.

Her er et par tips:

Brug scripts istedet for musen og keyboardet, scripts har meget lavere fejlrate og skal ikke have kaffe- og tisse-pauser.

Standardiser jeres maskiner, så I kan genbruge så meget som muligt og eventuelt have en maskine klar som "halvfabrikata".

Sørg for at jeres CM procedurer ikke afhænger af at nogen enkeltmaskine virker, det bedste er hvis den er stand-alone, helt uden netværksforbindelse.

USB harddiske med ISO images er fantastiske værktøjer til CM. (Husk at dokumentere hvordan men genopbygger USB disken :-)

Brug jeres CM værktøj, så I ved at det virker: Lad være med at updatere softwaren på det kørende system, byg istedet et nyt system med den nye software og skift så når det virker. (Det giver også mindre nedetid).

En backup bør kun bestå af data, programmer og OS skal komme fra CM systemet.

Og når jeres CM indsats så virker: læg mærke til hvor meget mindre idiotarbejde dit job nu indeholder.

phk
(Release engineer FreeBSD 2.x & 3.x)

Kommentarer (5)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Morten Fordsmand

Men mener du ikke Change Mangement:
Altså ændringsstyring

Eller måske Implemnentation Management:
Idriftsættelse.

Og så glemte du i øvrigt dicipliner som fall-back, der bør være beskrevet (og gerne afprøvet) før ændringen.

For yderligere inspiration i de klassiske driftdicipliner, som os der har kørt på rigtige computere lever med dag ud og dag ind, kan man jo kigge på ITIL.

  • 0
  • 0
Poul-Henning Kamp Blogger

Du blander værktøjer og metoder Morten.

Change Management er en metode, der i teorien handler om hvordan man får fundet alle de steder der bliver påvirket af en given ændring inden man udfører den. I praksis er det en Blame Allocation milepæl hvor brugerne bondefanges til at godkende noget de ikke aner hvad betyder.

Implementation Management er også en metode, i teorien hvor man checker at man har husket det hele, også dokumentationen, men i praksis er det en Blame Allocation milepæl hvor den udviklingsafdelingen får aflad fordi driftsafdelingen ikke aner hvad de lige har modtaget.

Configuration Management er det værktøj driftafdelingen bruger til at (re)etablere en given konfiguration af et givent system, uanset årsagen til at behovet opstår.

Poul-Henning

  • 0
  • 0
Morten Fordsmand

Værktøjer? jeg er ikke helt med men når vi taler management så må det vel være metoder. Men det er da indlysende at mange processer forløber mere effektivt og sikkert når de understøttes af dertil egnede værktøjer.

Indrømmet dette er ITIL V2, da jeg ikke pt. har V3

"
The goals of Configuration Management are to:

Account for all the IT assets and configuration within the organisation and its services"
Provide accurate information on configuration and their documentqation to support all th other Service Management processes
Provide a sound basis for Incident Management, problem Management, Change Management and Release Management
verify the configuration against the infrastructure and correct any exceptions"

Og det er vist ikke det du taler om.

I øvrigt mente jeg "release management" da jeg skrev "implementation management" :-(

Release management handler netop om at kunne distribuere og styre opgraderinger i miljøet.

Når jeg leger sprogrygter, så er det jo fordi at man med ITIL i det mindste prøver på at blive enige om hvad de enkelte termer drejer sig om.

Og så havde jeg i øvrigt håbet at du kunne causere om det store ITIL-dyr CMDB'en der vel kun kan beskrives som "The holy grail of System Management" det er nemlig et emne

  • 0
  • 0
Morten Fordsmand

Nu kan man slet ikke certificere mod ITIL, og man kan ikke være ITIL-compliant.
Men da mange har svært ved at holde styr på en mere og mere kompleks IT leverance har ITIL vist sig at være en god hjælp til at få styr på koncepterne, og derfor er konsulenter, kursusarrangører og diverse plattenslager begyndt at kredse som gribbe på himlen.

Men ved at google lidt på "Configuration Management" så ryger man først i Wikipedia http://en.wikipedia.org/wiki/Configuration_management
Ikke at wikipedia er en endegyldig dommer men som jeg læser dens definition, er det som Simon og Poul-Henning referer en del af den deldiciplin der omtales om Software Configuration Management. Som nok er det udviklere ser som Configuration Management, men desværre er verden større end softwareudvikling.

Problemet er jo at vi kan have "CM-server" som PHK beskriver det (eller DSL=Definitive software library som ITIL vist nok kalder det), det er bare ikke nok til at kunne levere det brugerne har brug for, men det er ganske rigtigt en rigtig god ide. Men vi har som sagt brug for mere det store problem er faktisk hvor vi skal trække grænsen for hvilken information vi skal lagre omkring den kørende IT-infrastruktur og hvordan vi skal lagre den. Det er der ITIL's Cfg.Mgmt for alvor løber ud i udfordringer nemlig hvordan skal vi modelere alle relevante items for vores drift.

  • 0
  • 0
Lasse Hillerøe Petersen

PHK har ret i at fremhæve Conf. Mgmt. For Conf. Mgmt. er så vidt jeg kan se (på baggrund af min ITIL+ certificering og almindelig interesse) nøglestenen i ITIL. For at lave noget, må man udføre en change. Men for at kunne gøre det, er man nødt til at vide hvad man har at starte med, og hvad man forventer at have bagefter. Det er Conf. Mgmt.

At PHK så lige forveksler CMDB ("værktøjet") med Conf Management processen, er en anden sag.

Endelig vil jeg lige nævne, at selv om man ikke kan certificere mod ITIL, så kan man vist mod fx ISO/IEC 20000, og det er vist tæt nok på.

Problemet med ITIL som jeg ser det, er at der som med alle den slags systemer er en tilbøjelighed til at implementere dem "by name" i stedet for "by value". Fx ved at mappe begreberne ud fra et "best match" princip til eksisterende arbejdsmåder og strukturer. Eller ved at tage en enkelt proces, fx ServiceDesk, og forsøge at implementere den først. No Can Do.

Det absolut sværeste er nok at sætte sig ned og lave Conf. Mgmt. fornemmer jeg - og det er den eneste fornuftige vej til ITIL, så vidt jeg kan se. SLAer er meget godt, men CMDB er der hvor "sandheden" om virkeligheden skal findes. Hvis den ikke er veldefineret og ajour, så famler man altid mere eller mindre i blinde, og så sker der fejl.

Og så skal man ikke glemme hvor kode og dokumentation, og dermed også incidents, changes, SLAer osv hører til: nemlig i CMDB.

(Nogen burde i øvrigt sætte sig ned og skrive en bog om hvordan man starter fra CHANGE 0 og derfra opbygger en ITIL-compliant IT-serviceorganisation. Lidt ligesom en bog om åbninger i skak, tror jeg. Det ville måske blive en bestseller.)

-Lasse

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