To update or Not to update, that is the question

Når man arbejder med operativsystemer og databaser, måske specielt dem fra Redmond, vil man hurtigt stifte bekendtskab med Service Packs og Hotfixes. Hotfixes er quick fixes som ikke altid er gennemtestede, hvor Service Packs er en samling af mange fixes, som har været igennem et beta test forløb.
 
Dette regner jeg med at de fleste læsere på Version2 er klar over.

Hvad jeg til gengæld ser en masse tvivl om er hvornår man lægger dem på, for at gøre det sort/hvidt er der to lejre i holdningen til opdateringer.
 
Den lejr jeg ser mest på database servere, er at de nærmest bliver behandlet som main-frames. 'If it aint broke, don't fix it? er mantraet for denne holdning. Nogen gange er det også bare et skalkeskjul for en underliggende usikkerhed, om implikationerne af en opdatering. Denne holdning ses ofte hos leverandører af standard systemer som kører ovenpå SQL server.
 
Den anden lejr er de hypermoderne, som nærmest ligger Service Packs og Hotfixes på, samme dag eller kort efter de bliver frigivet. Her er en nærmest naiv optimisme på Redmond?s færdigheder, som ikke sjældent bliver straffet. Et amerikansk ordsprog siger at det altid er pionererne der får pilen i ryggen, en ting jeg ofte har set i min konsulent tid.
 
Nu betragtes verden sjældent nuanceret og fornuftigt igennem sort/hvide betragtninger, men dette er de to yderligheder. Hvad er så mine anbefalinger:
 
Generelt venter jeg med Service Packs en måned eller to, medmindre der er stærke sikkerhedsimplikationer. De fleste store fejl opdages altid indenfor denne tid. Efter release af en Service Pack til SQL Server, vil jeg holde mig opdateret indtil jeg har tillid til, at ingen har større problemer med den. 
 
Til gengæld vil en release betyde at jeg begynder at teste den. Grunden til den underliggende usikkerhed, som jeg nævnte før, hænger ofte sammen med et manglende test miljø og/eller tid til at teste. Men hvis man ikke opdaterer sine systemer, vil man ofte møde andre problemer, fordi man ikke opdaterer. Problemer som kan være lige så seriøse eller værre, som dem man undgår ved ikke at være 'early adopter' på Service Packs.
 
Leverandører af standard systemer ovenpå SQL server, kan være meget langsomme til at sige OK til Service Packs, hvilket mange gange skyldes alt fra manglende viden hos ens Account Manager, til at leverandøren ikke har tid/mulighed for at teste. 
 
Jeg kan stadig huske SQL Slammer ormen, som betød at man skulle have SP3 til SQL Server 2000 + en security hotfix. Problemet med SP3 var at den strammede op på sikkerheden i SQL Server 2000 og derfor betød en del arbejde for en del leverandører. Men en del leverandører havde været for langsomme og fik meget travlt grundet SQL Slammer. Så at være 'late adopter' kan være lige så farligt.
 
Så min anbefaling er at undgå såvel 'early adopter' problemer, såvel som 'late adopter' problemer, ved at gøre følgende:

  • Test ved release, brug tid til at sætte dig ind i opdateringen
  • Begynd at planlægge opdateringen af dine produktions servere
  • Snak med dine leverandører af standard systemer på SQL Server
  • Start med at opdatere udviklings og test database servere
  • Påbegynd opdateringen i dit produktions miljø, når Service Pack'en er testet og ingen 'grimme nyheder' er kommet efter 1-2 måneder, eller at der er lavet en 'post fix? pakke til Service Pack 

Kommentarer modtages gerne

Kommentarer (5)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Poul-Henning Kamp Blogger

Du blander to USAnske udtryk sammen:

"It's always the pioneers who get scalped/killed by arrows"

og

"Pioneers tend to get shot in the back."

Den første kræver ingen forklaring, men den anden er temmelig spidsfindig:

Pionerene, dvs. de første der ankom i de nye territorier, faldt sjældent til i de samfund der senere opstod omkring dem når de mere civilizerede "settlers" fulgte efter.

Nogle gange forsøgte de med våben at forsvare deres omfattende krav på land, andre gange forsøgte de at bilægge verbale stridigheder med bly, næsten altid blev de utroligt upopulære i lokalområdet.

Så pilene ramte dem forfra, skudene bag

  • 0
  • 0
Poul-Henning Kamp Blogger

...fra.

Med hensyn til patches er vi næsten helt enige: Jeg ville dog tilføje et punkt '0' på din liste der siger "Sørg for at partitionere og beskytte dine systemer, så du har så lidt brug for patches som muligt".

Poul-Henning

  • 0
  • 0
Kenn Schjødt

Jeg har har altid hørt udtrykket således, på diverse USA SQL konferencer, men det lyder meget logisk :-)

Nummer O passer godt generelt, men på Windows siden, bliver man nødt til at følge nogenlunde med på patches/service packs, da specielt supporten fra Microsoft og andre hænger sammen med at man ikke er for langt bagud.

/Kenn

  • 0
  • 0
Poul-Henning Kamp Blogger

Vores udtryk forvanskes også over tid, bjørnetjeneste har skiftet fortegn, godt og vel kan tage begge fortegn osv.

Enig igen: nummer nul må ikke blive en sovepude. Men det er rart hvis den kan gøre forskellen på om man installerer patches midt i åbningstiden eller i førstkommende planlagte nedetid.

Poul-Henning

  • 0
  • 0
Kenn Schjødt

Så langt er mange Windows admins ikke nået ;-)

Patches og service packs, plejer at betyde weekend/aften arbejde, men det er jo en del af jobbet som IT mand, specielt på server/database siden.

Sidder pt. i Sydney Australien, efter en successfuld fredag/lørdag med ændring af collation på system og database, opdatering til Navision 4.0 SP3 og en opdatering af SQL Server til 2005 SP2+build 3175 hotfixes.

Til gengæld ser jeg ikke frem til 21 timers flyvning i morgen, kombineret med 4-5 timers ventetid i de altid småkedelige lufthavne.

Men så får jeg da læst LOTR "Two Towers" på hjemvejen, læste "Fellowship of the Ring" på vejen ud.

/Kenn

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