Kort svar: Når sitet er nede kl. 23, er den værste plan at improvisere. En nedbrudsplan på ÉN side løser det: tre roller (én FEJLFINDER, én KOMMUNIKERER, én BESLUTTER – gerne samme person med kasketterne på i den rækkefølge), et fast første kvarter (bekræft nedbruddet udefra, tjek hostingens driftstatus, slå op i ændringsloggen: hvad blev sidst ændret? – og rul det tilbage) og et beslutningstræ: egen ændring → rollback; server/hosting → support + statusside; usikkert → eskalér efter nødkontaktlisten. Skriv planen i fredstid, print den, og øv den én gang om året – så er kl. 23 bare en procedure.
Nedbrud er ikke et spørgsmål om hvis, men hvornår – og om der så findes en plan, eller kun adrenalin. Forskellen måles i timer: med plan er de fleste nedbrud løst eller eskaleret på under en time; uden bruges den første time på at lede efter kodeord og diskutere, hvem der ringer til hvem. Her er planen – klar til at skrive af.
Alt nedbrudsarbejde består af tre opgaver, der ØDELÆGGER hinanden, når de blandes: FEJLFINDEREN undersøger og retter – og skal have RO (hver „er der nyt?“-afbrydelse koster fem minutters koncentration); KOMMUNIKATØREN opdaterer statussiden, svarer support og holder ledelsen orienteret – så fejlfinderen slipper; BESLUTTEREN tager de få valg, teknik ikke kan („ring vi bureauet ind nu?“, „lukker vi for betalinger, til det er løst?“). I en lille virksomhed er alle tre ofte samme person – og NETOP derfor skal rollerne stå på skrift: så ved du, at første opgave er fejlfinding, at statussiden opdateres på faste tidspunkter i stedet for konstant, og at eskalering er en beslutning, du træffer efter planen – ikke en følelse af nederlag. Står flere til rådighed, fordeles kasketterne i første opkald, FØR nogen åbner en terminal.
Kvarteret er en tjekliste, ikke en undersøgelse: 1) BEKRÆFT udefra – er sitet nede for alle eller kun for dig? (mobilnet i stedet for wifi, et „er det nede“-tjekværktøj, og overvågningens alarm som facit – halvdelen af alle „nedbrud“ er lokal DNS eller cache). 2) SCOPE – er ALT nede eller kun én funktion (checkout, mail, login)? Det afgør både hast og spor. 3) TJEK HOSTINGENS DRIFTSTATUS – er det en kendt hændelse hos udbyderen, er dit job kun at kommunikere og vente. 4) SLÅ OP I ÆNDRINGSLOGGEN – langt de fleste selvforskyldte nedbrud følger inden for timer efter en ændring: en opdatering, et nyt plugin, en DNS-rettelse. Er der en, så RUL TILBAGE først og analysér bagefter. 5) FØRSTE STATUS ud til kunderne. Først DEREFTER begynder egentlig fejlfinding – med logs og systematik frem for tilfældige genstarter.
Efter kvarteret står du i én af fire situationer, og planen anviser vejen i hver: EGEN ÆNDRING (rullet tilbage og oppe igen → dokumentér, og genindfør ændringen forsigtigt i morgen – aldrig kl. 23), HOSTING-HÆNDELSE (opret sag/følg driftstatus, opdatér statussiden med deres tidsløfter – og lad være med at „fejlrette“ i noget, der ikke er din fejl), KENDT FEJLTYPE (databasefejl, fuld disk, udløbet certifikat – følg opskriften i driftsdokumentationen; loglæsnings-guiden hjælper med at stille diagnosen) og USIKKERT (ingen årsag efter 30-45 minutter → ESKALÉR efter nødkontaktlisten: hosting-support med konkrete observationer, derefter bureau/udvikler – „jeg prøver lige lidt endnu“ er planens dyreste sætning). Skriv de fire scenarier ind i jeres beredskabsaftaler, så tærsklerne er aftalt, før de skal bruges.
Kunderne tilgiver nedbrud – de tilgiver ikke tavshed. Rutinen: statussiden opdateres FØRST (inden for 15 minutter, med løfte om næste opdatering), supporten svarer med link til den i stedet for individuelle forklaringer, og direkte besked (mail/sms) sendes kun, når noget kræver handling af kunden eller nedbruddet rammer aftaler (ordrer, bookinger, frister). Skabelonerne ligger klar i planen – „vi undersøger“, „årsag fundet“, „løst“ – så ingen skal formulere sig under pres. Og én regel for tonen: ærlig og konkret, uden dramatik og uden tekniske undskyldninger – „betalinger fejlede mellem 22:41 og 23:37; ingen ordrer er gået tabt“ er alt, kunden behøver. Internt gælder samme disciplin: ledelsen følger statussiden, ikke fejlfinderens telefon.
Når pulsen er nede, samles trådene inden for en uge: tidslinje og årsag i to afsnit, én forebyggende ændring og én proces-forbedring – hele formatet står i post mortem-guiden – og hændelsen føres til ændringsloggen og statussidens historik. Test derefter planen selv: en årlig SKRIVEBORDSØVELSE („sitet er nede nu – hvad gør vi?“ gennemspillet på 20 minutter) afslører forældede numre og manglende adgange, længe før virkeligheden gør. Og vælg et fundament, hvor planen sjældent aktiveres: hosting med døgnovervågning, daglig backup og dansk support, der svarer, når du ringer – performance-garantien hos Hostious er bygget til præcis de aftener. Så bliver kl. 23-nedbruddet det, det bør være: en procedure, ikke en krise.
Bekræft det udefra (er det nede for alle?), tjek hostingens driftstatus, og slå op i ændringsloggen: den seneste ændring er den mest sandsynlige årsag – rul den tilbage først.
Når der ingen sandsynlig årsag er efter 30-45 minutter – med konkrete observationer i hånden. „Jeg prøver lige lidt endnu“ er nedbruddets dyreste sætning.
Ja – som rækkefølge: fejlfind først, kommunikér på faste tidspunkter, beslut eskalering efter planen. Kasketterne på skrift forhindrer, at alt sker på én gang – og intet ordentligt.
