Totale transparantie bij fuckups. Het wordt steeds belangrijker bij zowel een interne fuckup, als bij een datalek of hack van je systemen.
Markeer zeker mei 2018 in je agenda want de aankomende Europese dataprivacy ruling GDPR gaat transparantie bij datalekken ook opleggen.
Under the GDPR, a “personal data breach” is “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed.”
In the event of a personal data breach, data controllers must notify the supervisory authority “competent under Article 55” which is most likely (looking to Article 56(1)) the supervisory authority of the member state where the controller has its main establishment or only establishment, although this is not entirely clear. Notice must be provided “without undue delay and, where feasible, not later than 72 hours after having become aware of it.” If notification is not made within 72 hours, the controller must provide a “reasoned justification” for the delay.
Een mooi voorbeeld van totale transparantie
Gitlab is een concurrent van het gekende Github en verzorgt het systeem voor developers om versioning van hun code te doen (noodzakelijk wanneer je met meer dan 1 persoon aan dezelfde code begint te prutsen).
Afgelopen nacht heeft Gitlab “een probleempje” gehad, waarbij een developer het gevreesde commando “rm – rf” (dat zelfs een eigen Wikipedia pagina heeft ) heeft losgelaten op de productiedatabase. Die commando gaat alles verwijderen, waarbij er ook geen confirmatie meer nodig is, dat alles mag worden verwijderd.
Ok, geen probleem (normaal gezien). Dan doen we een restore van de meest recente backup, moeten ze gedacht hebben. En toen kwam Murphy meespelen….
Gitlab laat echter wel mooi zien hoe je dit als bedrijf moet aanpakken:
1. Twitteraccount @gitlabstatus gaat direct over tot statusupdates
We are performing emergency database maintenance, https://t.co/r11UmmDLDE will be taken offline
— GitLab.com Status (@gitlabstatus) January 31, 2017
we are experiencing issues with our production database and are working to recover
— GitLab.com Status (@gitlabstatus) February 1, 2017
2. Ze maken een publieke google doc, waarin alles wordt gedocumenteerd en ook alle interne issues, waar ze tegenaan lopen
We accidentally deleted production data and might have to restore from backup. Google Doc with live notes https://t.co/EVRbHzYlk8
— GitLab.com Status (@gitlabstatus) February 1, 2017
Inclusief dergelijke quotes:
So in other words, out of 5 backup/replication techniques deployed none are working reliably or set up in the first place.
5 Wijze lessen?
Altijd interessant om even enkele wijze lessen te trekken uit dit verhaal:
1. Iedereen die iets van Project management in digitaal doet, moet ook dergelijke verhalen leren begrijpen en kunnen inschatten. Ikzelf heb het als goed voornemen voor dit jaar en kan trouwens volgende boeken aanraden: The Phoenix project en Google Site Reliability Engineering.
2. rm -rf is gevaarlijk 😉
3. Test je backups! Doe eens een restore van je backups. Been there… :-/
4. Transparantie is key. Zeker bij Technische gebruikers als doelgroep. Een eenvoudige Twitteraccount en Google Docs kan perfect werken naast een statuspagina (zie deze van Dailybits)
5. Hou je gebruikers continu op de hoogte. Communicatie, communicatie,….
Data transfer has been slow, we are 42% done with the database copy.
— GitLab.com Status (@gitlabstatus) February 1, 2017
Ondertussen hebben ze zelfs een livestream van de recovery. 😉
Live stream of us working to restore https://t.co/r11UmmDLDE: https://t.co/8D641MRczH
— GitLab.com Status (@gitlabstatus) February 1, 2017
Geen rm -rf –no-preserve-root ? 🙂