100% oppetidsgaranti findes ikke! Jeg har selv haft services, der kørte uden stop i 7-8 år ad gangen. Der findes forskellige metoder og tekniske løsninger man kan benytte sig af, men uanset hvad, kan du ikke forudsige det uforudsigelige, og hvis du bygger en forretning på den antagelse, at dine servere aldrig går ned, så begår du en stor fejl.
Vi skal selvfølgelig bestræbe os på at komme så tæt på som muligt, men vi er stadig nødt til at have en plan for, hvad der skal ske, når og ikke, hvis det går galt.
Jeg havde engang en kunde, som kørte en virkelig stor portal, vi snakker flere hundrede tusinde samtidige brugere. Af og til sker det, at en bruger rammer en side, der ikke findes, og så skal brugeren have en fejlbesked.
Det havde kundens egen programmør valgt at håndtere ved at lave en generel fejlhåndteringsside, denne side fungerer således, at den først kontakter databasen og spørger om nogle data, der skulle bruges for at vise fejlsiden. Derefter indsatte den fejlbeskeden, og slutbrugeren ville så få en pæn og letlæselig fejlbesked.
Det fungerede rigtig godt i princippet, ihvertfald så længe, at fejlbeskeden handlede om ikke-eksisterende sider. Hvis fejlen derimod skyldtes en databasefejl. Ja lad os antage, at databasen er gået ned, eller belastet så meget,at den ikke når at svare. Resultatet er så, at brugeren får en fejl med beskeden “Kan ikke kommunikere med databasen.” Mén før fejlen vises, skal vi lige kontakte databasen, så vi kan vise fejlbeskeden i en pæn og letlæselig version.
Denne kontakt til databasen vil selvsagt også producere en fejl, denne nye fejl vil påny forbinde til databasen, som igen vil forårsage en ny fejl … og ja, jeg behøver vidst ikke skære det mere ud i pap?
I det førnævnt tilfælde var resultatet, at på ganske få sekunder ville alle 8 webservere, blive belastet af flere tusinde processer og holde op med at svare. En kortvarig spidsbelastning på en lille del af databasen ville altså lægge samtlige 12 servere (8 webservere og 4 databaseservere) ned på ganske få sekunder.
Kundens udvikler brugte 3-4 måneder på at finde fejlen, men på trods af, at han var en re dygtig udvikler, kunne han slet ikke forstå problemet. Vi fandt faktisk først selv fejlen efter en intens undersøgelse af processeen, men da var den også åbenlys, for os.
Læresætningen her må altså være, at selvom man er dygtig til at lave hjemmesider, er man ikke nødvendigvis god til at bygge driftsikre løsninger der skallerer. Så hvis ikke din udvikler har planlagt, hvad der skal ske, når det går galt, så var det måske en ide at få et par friske øjne på projektet? 😉