nospam0000@gmail.com (=?iso-8859-1?q?Thorbj=F8rn_Ravn_Andersen?=) writes:
>Spørgsmålet er hvad dine profiessionelle erfaringer er med at drifte
>store ting på Unixplatform med redundans og transparent overtagelse af
>forpligtigelser. Hvad skal der til for at både kunder, ejere og
>driftsfolk er glade?
Den situation er svær at komme i for driftsfolkene, mens den er
forholdsvis nem for kunder og ejere
Som driftsfolk er man altid "skraldespanden", fordi alle andre
discipliner er højt specialiserede. Man kan f.eks. ikke få SAP-
eller databasefolk til at røre Unix med en ildtang, mens Unix-
folk gladeligt kaster sig over ting, de har en anelse forstand
på.
I et tidligere firma blev der lavet en interessant statistik,
der sagde, at non-clustered løsninger faktisk havde højere
oppetid end clustered. Meget af det havde nok at gøre med, at
systemerne blev installeret af udviklere. Og at udviklerne i
de non-clustered miljøer faktisk havde designet deres egne
former for clusters (hvilket faktisk virkede - men nok var
spild af kundens penge, når man nu kan købe færdige clustre).
Min erfaring siger mig, at man ikke skal have udviklere til at
designe eller implementere andet end applikationen. Clusteret,
konfiguration af maskiner, adgangskontrol osv. skal sysadms
tage sig af.
Det lyder lidt hårdt at sige, men man KAN ikke være dygtig
udvikler OG dygtig sysadm. Udviklerne går i detaljer og har
en meget kompleks tankegang, der er absolut nødvendig for at
deltage i et udviklingsprojekt over mange måneder.
Sysadms tænker helt modsat: "lad os fikse dether på et minut,
og næste gang skal det højst tage 30 sekunder". Det behøver
ikke være pænt, men det skal virke, være effektivt og sikre
en høj oppetid. Hvis det går i stykker med næste version af
applikationen, er det fint - så laver vi bare en ny.
Man skal ikke sætte sig ned og tænke klokken fire om natten,
når noget er gået ned. Det skal være operationelt. Tag en
tilfældig manual. Hvis den er skrevet af en udvikler, skal
du bruge en halv time på at læse om applikationens dataflow
fra A til Z. Er den skrevet af en sysadm, er den operationel:
"hvis den siger A, gør B. Og hvis den under B kommer med fejl
C, så gør D. Gentag om nødvendigt til den siger E. Når den er
kommet op igen, tjek den med F".
Cluster, alarmopsætning og alt detder har sysadms altså meget
mere praktisk erfaring i. Det er derfor vigtigt med et samspil
mellem udvikling og administration under udviklingsprocessen,
så sysadms ikke på en halv dag skal overtage noget juks, der
ikke er målrettet stordrift. Og så sysadm'erne får en grundig
forståelse af applikationens behov og derfor kan designe et
operationelt miljø at drifte applikationen i.
Det absolut vigtigste for at gøre sysadms glade er, at de ikke
er bange for nattevagter. Det kræver faktisk kun to ting: en
god manual (se ovenfor) og nogle gode alarmer.
Jeg har set mange alarmer à la "Application cannot write to
predefined middleware queue". Okay, hvaffen applikation,
hvaffen noget middleware (i vores setups har vi ofte 2-3
stykker), og hvaffen en kø (okay, kø lugter af MQ eller JMS,
men præcis hvor skal jeg lede?)
Nej tak. Lad os få det oversat til en operationel alarm - så
kan udvikleren skrive sin højtflyvende forklaring i en anden
logfil. "Dataloader ABC failed to write to queue manager DEF
queue GHI.TO.JKL: Broken pipe". Sådan! Nu kan jeg hoppe lige
ind på DEF og finde ud af, hvorfor GHI.TO.JKL er i stykker.
Og min pet peeve: et stacktrace. I det tilfælde beder jeg
kunden ringe og vække udvikleren - så må han lære at lave
fejlhåndtering, hvis han gerne vil sove om natten.
Sikke en masse ord, der egentlig bare siger:
* Udviklere skal udvikle applikationer og intet andet.
* Systemadministratorer skal opsætte maskiner og cluseret.
* Systemadministratorer skal installere udviklernes software.
* Systemadministratorer skal lave alarmopsætning og whatnot.
....og sysadms skal give udviklerne feedback. Med det samme. Dét
er vi som faggruppe elendige til, og det er ris til egen mås,
for det bliver jo aldrig bedre, hvis vi ikke beder om det. At
gå og være sur på et udviklingsteam, fordi de ikke laver noget,
man aldrig har bedt dem om, bør være fyringsgrund.
Men hvordan undgår sysadms at blive udviklere, hvis de skal
installere nye maskiner hele tiden?
Man kan sagtens have to parallelle teams af sysadms, der f.eks.
tager en tørn i "systemopsætning", mens de andre laver rigtigt
sysadm-arbejde. Og så bytter de 3-6 måneder senere. På den måde
har alle i opsætnings-gruppen stadig up2date erfaring med drift
og dermed også mulighed for at installere systemerne, så de
bliver nemmest at fikse klokken 4 om morgenen.
Det er IMHE(xperience) *måden* at få en stabil drift på: at
systemerne er sat op af folk, der er vant til at håndtere dem,
når de går i stykker. Folk med teoretisk viden om Unix er helt
sikkert dygtige - men de duer ikke en pind til at konfigurere
dem til drift, hvis de ikke har års vaskeægte erfaring med
systemadministration på fuld tid.
Mvh.
Klaus.
PS! Og så skal man huske, at Unix - cluster eller ej - ikke
kommer bare i nærheden af OS/400 eller z/OS hvad stabilitet
angår. Unix er designet til at løse en masse små opgaver og
have et udviklingstempo der er meget hurtigere end de andres.
Det er ikke praktisk at have mere end et par releases om året
på mini/mainframe-applikationer. Mens vi på Unix er vant til
måske 10-20 stykker.
Når en Unix-boks går ned, så går der mindst 2-3 minutter i
komplekse setups, før tjensten er oppe igen. I mainframe-
verdenen kan et helt datacenter eksplodere, mens brugeren
end ikke opdager en forsinkelse. Teknologier som GDPS gør,
at applikationen ufortrødent kører videre på et andet site
med få sekunders failover-tid - og uden at tabe kørende
transaktioner.
Det er ikke vores verden i Unix-regi. Vi skal stille en
platform til rådighed, som det er let at udvikle til, som
kan skaleres, klones og omlægges på nogle få dage, og som
giver en oppetid på måske 99,5% eller en anelse højere.
Mainframes kan levere 99,999% oppetid målt på årsbasis -
i et dynamisk miljø. Måske en faktor 10 højere i et mere
statisk miljø hvor applikationerne aldrig ændrer sig.
Det får man aldrig Unix til. Og det er vigtigt, at man gør
kunden det faktum klart. Forventningsafstemning med andre
ord.
PPS! Ovenstående giver måske også lidt forklaring på min
ret praktiske tilgang til problemer og muligheder i Unix.
Og forklarer måske også, hvorfor jeg hader teoretiske "det
kan man altså godt"-ideer, som aldrig vil skalere, virke,
give høj oppetid eller på en eller anden måde ødelægge
oplevelsen for kunden. Det er mere eller mindre mit job at
stoppe den slags ideer, inden de kommer i drift
Er nogen stadig vågne?