Gitlab als toonbeeld van totale transparantie

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

2. Ze maken een publieke google doc, waarin alles wordt gedocumenteerd en ook alle interne issues, waar ze tegenaan lopen

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,….

Ondertussen hebben ze zelfs een livestream van de recovery. 😉

Gerelateerde berichten

Herman Maes - online marketeer seo freelancer

Herman Maes

Online marketeer en (tech)blogger sinds 2002. Freelancer (SEO en Digital marketing) met Dailybits als SEO/Hubspot/Marketing Technology Teamlead en thuis de papa van een zoon en een dochter.

Schrijf je in op de maandelijkse Dailybits mailing met een behind-the-scene blik.

One comment

Submit a comment

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *