Lær af Gitlabs fejl: Åbenhed gør alle klogere
Det er surt, når systemadministratoren kommer til at slette den forkerte kopi af databasen i forsøget på at løse et problem. Og det er endnu mere surt, når det viser sig, at flere af backup-procedurerne ikke har virket, og data er gået tabt.
Men derfor er det også vigtigt at rejse sig fra faldet på den rigtige måde. Er man gået på måsen, fordi der var is på fortovet, så er det almindelig hensyntagen til sine medmennesker at advare andre om, at der er glat.
Derfor er det glædeligt at se, at da det gik galt for Gitlab, så fik vi en usædvanlig detaljeret rapport. Den omfattede ikke blot, hvilket system der gav problemer og den sædvanlige undskyldning til kunderne.
I beretningen var også teknikernes overvejelser og observationer med oplysninger om, hvilke værdier der blev ændret i konfigurationen.
Det udløste et forholdsvis konstruktivt svar fra Simon Riggs, som er én af de store bidragydere til databasen PostgreSQL, som var én af de komponenter, der gav problemer for Gitlab.
Svaret indeholder anbefalinger til en bedre konfiguration samt en forklaring på, at noget af den adfærd, Gitlab-teknikerne observerede ved PostgreSQL-databasen, var normal, eller i hvert fald noget, som burde have løst sig selv efter et stykke tid.
Sådan en offentlig dialog er vigtig, for den giver os indblik i praktiske erfaringer, som alle kan bruge.
Manglende verificering
Selve lektien fra Gitlab om, at der både var backup på Microsofts Azure og Amazons S3, men at der manglede en mekanisme eller procedure til at verificere backuppen, er vigtig.
Backuppen hos Azure viste sig ikke at omfatte databasen. Og backuppen hos Amazon viste sig at være tom, og det understreger, at ingen backup er en rigtig backup, hvis den ikke er verificeret.
Der er som regel forskelle mellem, hvordan organisationer har sat deres it-systemer og backup op, men principperne er meget ens. Derfor kan alle lære af fejl, som den der skete hos Gitlabs.
Og når man som Gitlabs er åbne og afslører mange detaljer, så er der også flere bidder af nyttig information, som gør erfaringerne nyttig for flere. Der er måske andre, der har begået den samme fejl i konfigurationen af PostgreSQL. Eller som ikke har tjekket, at databasen også bliver backuppet til skyen.
Eller ligesom Gitlab har en replikeringsprocedure, der er styret af en håndfuld scripts, som aldrig er blevet ordentligt dokumenteret, så teknikeren kommer i tvivl, når det går galt.
It-nedbrud kan ramme alle. Få gange det en tilfældig hændelse, som ingen kunne forudse. Men oftest er det en serie af små fejl, der har akkumuleret over tid, og som i bagklogskabens lys kunne være undgået.
Derfor er det vigtigt at hjælpe hinanden med at være opmærksomme på, hvad det er, der kan gå galt. Og selvom vi nok enten reagerer med et grin eller hovedrysten på historien om, at Gitlab mistede data på grund af fejl i fem backup-procedurer, så bør vi også lytte til erfaringerne og bidrage konstruktivt, hvis vi selv har nyttig viden.
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
