Dat laatste bepaalt of zij werkt. Delen beide hetzelfde onderdeel, dan neemt één gebeurtenis ze allebei mee. Op papier heeft u er dan twee. In werkelijkheid heeft u er één.

Vier organisaties hebben opgeschreven hoe dat bij hen uitpakte. Ik gebruik hun eigen publicaties, omdat die nauwkeuriger zijn dan de berichtgeving erover.

Vier keer nam één gebeurtenis ook het vangnet mee

Toyota, augustus 2023. Bij onderhoud aan een database werd opgehoopte data verwijderd en geordend. Daarbij ontstond een fout door onvoldoende schijfruimte en het systeem stopte. De productie in de Japanse fabrieken viel stil. Toyota schrijft dat de servers op hetzelfde systeem draaiden, dat daardoor een vergelijkbare storing optrad in de back-upfunctie, en dat overschakelen niet lukte.

UniSuper en Google Cloud, mei 2024. Bij Google Cloud werd een privatecloudomgeving van het Australische pensioenfonds onbedoeld verwijderd. In zijn eigen analyse schrijft Google dat het ging om één van de privateclouds van de klant, lopend over twee zones. Operators lieten daarbij een parameter leeg. Die twee zones stonden binnen wat werd verwijderd, dus de verdubbeling ging in dezelfde handeling mee. Wat erbuiten stond, bleef staan. De back-ups in Google Cloud Storage in dezelfde regio hielpen volgens Google bij het snelle herstel.

Universiteit Maastricht, december 2019. Na een gijzelaanval stelde Fox-IT vast dat back-upservers onderdeel waren van hetzelfde domein als de versleutelde servers, en dat er op netwerkniveau geen segmentatie was aangebracht. Daardoor kon de aanvaller meerdere back-ups versleutelen. Niet alle back-ups zijn geraakt. De universiteit schrijft dat het om een beperkt aantal systemen ging, en zij schrijft erbij waarom haar back-ups zo waren ingericht. Tot dan toe koos zij ervoor om back-ups vooral te gebruiken om na een storing of uitval snel weer over een werkende omgeving te beschikken.

Atlassian, april 2022. Een script dat één applicatie moest verwijderen kreeg de identificatiecodes van complete klantomgevingen mee in plaats van die van de applicatie. In drieëntwintig minuten verdwenen 883 omgevingen van 775 klanten. Hetzelfde script verwijderde ook de contactgegevens van die klanten uit de productieomgeving. Atlassian schrijft dat het veel klanten niet kon bereiken, omdat het hun contactgegevens kwijt was met de omgevingen die waren verwijderd.

Wat de vier gemeen hebben

In alle vier bestond de voorziening en was zij bekend. Toyota had een back-upfunctie. UniSuper had verdubbeling. Maastricht had back-upservers. Atlassian had onveranderlijke back-ups en toetste die doorlopend op herstelbaarheid. Bij geen van de vier ontbrak de maatregel.

Wat verschilde, is wat de voorziening deelde met het systeem eronder. Bij Toyota was dat het systeem waarop beide draaiden. Bij UniSuper de omgeving waarbinnen de twee zones stonden. Bij Maastricht het domein en het netwerk. Bij Atlassian de gegevens die het herstel nodig had.

Die laatste is de minst zichtbare vorm, en daarom de leerzaamste. Het herstel deelde geen systeem met de gebeurtenis. Het deelde de gegevens waarmee de getroffen klanten bereikbaar waren, en die gingen mee in dezelfde handeling.

Vastgelegd is niet beproefd

Een voorziening kan in orde zijn en toch niet beproefd op de gebeurtenis die haar zal treffen. Atlassian beschrijft dat zelf. Het script was in een testomgeving getest volgens het eigen wijzigingsbeheer. Die test kon de fout niet aantonen, omdat de verkeerd meegegeven identificatiecodes in die testomgeving niet bestonden.

Er is dus getest, met een geslaagde uitkomst, op iets anders dan wat er misging. Dat is geen nalatigheid. Het is wat er gebeurt wanneer de proef het onderdeel overslaat dat beide kanten draagt.

Atlassian schrijft er ook bij waarop het zich wel had voorbereid. Op uitval van infrastructuur, zoals het verlies van een database, een dienst of een beschikbaarheidszone. Het kon een grote verzameling klantomgevingen niet in één keer terugzetten naar een eerder moment. Voor uitval op die schaal lagen er geen draaiboeken klaar. Het hersteldoel in tijd is niet gehaald, het hersteldoel in gegevensverlies wel.

Dat is het verschil tussen een voorziening die is vastgelegd en een voorziening waarvan is aangetoond dat zij werkt. De eerste zegt dat er iets is. De tweede zegt wat er gebeurt wanneer u haar aanspreekt, en bij welke gebeurtenis.

Waarom het gedeelde onderdeel nergens staat

Het gedeelde onderdeel hoort bij geen van beide kanten. Het is het systeem eronder, het domein eromheen, de omgeving waarbinnen beide staan, of de gegevens waarmee u de getroffenen bereikt. In een overzicht van maatregelen komt het niet voor, want het is geen maatregel. In een testverslag komt het niet voor, want dat gaat over één kant.

Zo ontstaat een beeld dat per regel klopt en als geheel niet. Elke regel is verdedigbaar. De optelsom is dat niemand kan aanwijzen welke gebeurtenis beide kanten tegelijk raakt.

Toyota schrijft over hetzelfde systeem, Google over dezelfde omgeving, Fox-IT over hetzelfde domein. Drie keer een onderdeel dat in geen van beide kolommen thuishoort.

Wat ik typisch zie

  • de uitwijk draait bij dezelfde leverancier als het systeem dat zij vervangt, en niemand heeft dat ooit als punt benoemd
  • de back-up staat in hetzelfde netwerk en onder hetzelfde beheer als de gegevens die zij moet redden
  • er is een jaarlijkse test, en die begint op een moment dat alles het nog doet
  • het draaiboek voor uitval staat in het systeem dat bij uitval niet bereikbaar is
  • de wachtwoorden voor het herstel liggen in een kluis die pas na het herstel weer opengaat
  • de leverancier levert een tweede omgeving, en op welk onderdeel die van de eerste verschilt staat in geen contract
  • de test van vorig jaar is geslaagd, en niemand kan zeggen welke gebeurtenis er is nagebootst
  • wie het herstel moet uitvoeren, is dezelfde persoon die op dat moment de storing onderzoekt
  • de contactgegevens van de mensen die u tijdens uitval nodig heeft, staan in het systeem dat uitvalt
  • de vraag wat de twee kanten delen komt pas op tafel na een gebeurtenis, en dan onder tijdsdruk

Ieder onderdeel is op zichzelf verdedigbaar. Bij elkaar levert het geen bestuurbaar beeld op.

Welke vragen dit oproept

  • Welk proces mag niet stilvallen, en hoe lang is niet stilvallen precies?
  • Welke voorziening vangt de uitval daarvan op?
  • Wat delen die twee: een systeem, een netwerk, een domein, een leverancier, een abonnement, een beheerder?
  • Welke gebeurtenis raakt dat gedeelde onderdeel, en wat blijft er dan over?
  • Is de voorziening beproefd op die gebeurtenis, en niet alleen op het uitvallen van een apparaat?
  • Wat had u nodig tijdens het herstel, en bestond dat op dat moment nog?
  • Wie stelt vast dat de proef is geslaagd, en waaruit blijkt dat?

Kern

Een tweede voorziening is pas een tweede voorziening wanneer zij niet met de eerste kan meegaan. Wat dat bepaalt, is wat zij delen, en dat staat niet in de vastlegging.

Vastgelegd betekent dat er iets is. Beproefd betekent dat u weet wat er gebeurt wanneer u het aanspreekt. Zolang dat verschil niet is gemaakt, weet u niet of u één voorziening heeft of twee.

Die vraag is bestuurlijk en niet technisch. Welk onderdeel beide kanten draagt, is een feit over uw eigen inrichting, en iemand kan het opzoeken. Of dat gebeurt, hangt af van wie de vraag stelt.