Als het paneel wegvalt

Dit artikel gaat over het ergste scenario: de machine waar het paneel op draait is er niet meer. Brand, een verwijderde VM, een schijf die niet terugkomt.

Het eerste dat je moet weten is het geruststellende deel.

Er gaat niets van je klanten offline

Als het paneel wegvalt, blijven de servers gewoon doen wat ze deden. Websites worden geserveerd, mail komt aan, DNS wordt beantwoord, cron draait, certificaten worden vernieuwd. De agent op elke server werkt door met de instellingen die hij al heeft; hij heeft het paneel niet nodig om te blijven werken, en er is geen enkele situatie waarin het ontbreken van een paneel iets uitzet of weggooit.

Wat wél stilvalt, is het beheer: niemand kan een account aanmaken, DNS wijzigen, een uitrol starten of inloggen. Statistieken worden op elke server gewoon verzameld en tot 35 dagen bewaard; zodra het paneel terug is, worden ze opgehaald.

Je hebt dus tijd. Er loopt geen meter op klantdowntime.

Wat wij beloven, en wat wij daarvoor meten

Die twee getallen zijn geen aannames. Elke maand wordt de backup echt teruggezet in een wegwerpdatabase, en die oefening klokt zichzelf: hoe oud het nieuwste herstelpunt is, en hoe lang het terugzetten duurde. Slaagt de oefening niet, dan gaat er een mail uit. Stopt de oefening met draaien, dan gaat er óók een mail uit — een controle die zwijgt als hij gezond is, is niet te onderscheiden van een controle die dood is, en daar zit een aparte bewaker op.

De vier dingen die je zelf moet regelen

Herstel werkt alleen als deze vier dingen bestaan vóórdat je ze nodig hebt. Niets hiervan kan het paneel voor je doen: het zijn handelingen van een mens.

1. Twee papieren paneelkits. De kit draagt de sleutel waar elk geheim in de database onder is verzegeld. Een backup zónder die sleutel geeft je alle accounts, domeinen en het auditlog terug — en elke verzegelde kolom blijft onleesbaar. Print er twee, leg ze op twee verschillende plekken.
2. Twee papieren buildkits. Die dragen de sleutel waarmee updates worden ondertekend, de sleutel van de eigen certificaatautoriteit en het wachtwoord van de backuprepository. Ook twee exemplaren, op twee andere plekken.
3. Geen enkele kluis met beide soorten kits erin. De hele scheiding is dat wie de backups heeft ze niet kan lezen, en wie een sleutel heeft geen data heeft. Eén la met alles erin heft dat op.
4. Een tweede kopie van de backups. Die wordt elke nacht opgehaald naar een tweede machine, versleuteld — die machine kan de inhoud niet lezen en hoeft dat ook niet.

Wil je weten of dat allemaal nog klopt? De oefening print de menselijke helft als afvinklijst:

ssh root@build.corecp.dev corecp-restore-drill --checklist

Hoe je ziet dat het goed staat

ssh root@build.corecp.dev corecp-restore-drill --result
ssh root@build.corecp.dev corecp-drill-deadman --check

De eerste toont de laatste oefening met haar klok. De tweede zegt of die oefening nog steeds echt draait.

En als het echt gebeurt

Volg dan niet dit artikel maar het draaiboek: docs/dr-runbook.md in de broncode. Dat is geschreven voor iemand die om drie uur 's nachts wakker wordt gebeld, staat stap voor stap met alle commando's erin, en wordt elke ronde opnieuw nagelopen tegen de echte machines.

Twee plekken in het paneel komen daarin voor, en die vind je hier terug:

• een server buiten dienst stellen staat op de pagina van die server zelf, onder Gevarenzone;
• wat de vloot weigert staat onder Beveiliging → Ingetrokken certificaten.

Zie ook

• Het auditlog controleren, exporteren en bewaken
• De backups van je servers