Atlassian

Atlassian: als het incident groter wordt dan het proces

In april 2022 verwijderde een onderhoudsscript bij Atlassian per ongeluk 883 cloudomgevingen van 775 klanten. Voor een deel van de klanten duurde de storing tot 14 dagen. In de eigen evaluatie concludeerde Atlassian dat het incidentproces niet was ontworpen voor een incident van deze omvang, en dat elke rol 24/7 een back-up nodig heeft.

Wat er gebeurde

Atlassian levert onder meer Jira en Confluence als clouddienst. Op 5 april 2022 draaide tussen 07:38 en 08:01 UTC een script dat oude onderdelen van klantomgevingen moest opruimen. Door een communicatiegat tussen het team dat de verwijdering aanvroeg en het team dat het script uitvoerde, werden de identificaties van complete klantomgevingen aangeleverd in plaats van die van losse onderdelen. Het script verwijderde daardoor 883 omgevingen.

Hetzelfde script wiste ook de contactgegevens van de beheerders bij de klant. Daardoor konden getroffen klanten via het normale kanaal geen supportverzoek met hoge prioriteit indienen. Escalaties kwamen vervolgens binnen via e-mail, telefoon, tickets aan de CEO, LinkedIn en andere sociale media.

Wat de evaluatie vaststelt

Atlassian publiceerde een uitgebreide Post-Incident Review. Over de respons stelt Atlassian zelf vast:

• Het incidentmanagementprogramma en de teams waren niet ontworpen voor de diepte, omvang en duur van dit type incident.
• Klant-escalaties kwamen binnen via veel verschillende kanalen, wat de respons vertraagde en het overzicht bemoeilijkte.
• Atlassian had veel eerder breder moeten communiceren met getroffen klanten en eindgebruikers.

Atlassian benoemt onder meer deze verbeteracties:

• Voor elke rol in het incidentproces 24/7 een back-up, voor ziekte, vakantie of andere onvoorziene situaties.
• Investeren in één uniform escalatiesysteem.
• Het communicatieplaybook voor incidenten aanvullen, met duidelijke rollen en communicatielijnen, en het regelmatig herzien.

Lessen voor de respons

De volgende lessen zijn de interpretatie van OrcaGroup, op basis van de evaluatie.

1. Bepaal vooraf wat een groot incident is. Een proces dat werkt voor een storing van een uur, werkt niet vanzelf voor een incident van twee weken met honderden betrokkenen. Leg vast wanneer u opschaalt en wie dan welke rol heeft.
2. Een back-up per rol, niet per team. Atlassian trok deze les zelf. Wie rollen en vervangers niet vooraf plant, improviseert ze op het moment dat het het slechtst uitkomt.
3. Eén kanaal voor escalatie. Escalaties via tientallen kanalen maken regie onmogelijk. Eén plek waar alarmeringen en reacties samenkomen, geeft overzicht.
4. Houd crisiscontacten buiten het getroffen systeem. Bij Atlassian verdwenen de klantcontacten in hetzelfde incident. Contactgegevens en alarmering voor crisissituaties horen niet in het systeem dat kan uitvallen.

Wat dit betekent voor IT en dienstverlening

Voor IT-dienstverleners en managed service providers is dit geen ver-van-mijn-bedje-show. Onder de Cyberbeveiligingswet vallen ook beheerde ICT-diensten, en de wet vraagt om een plan voor crisisbeheer met taken en bevoegdheden. Uw klanten rekenen erop dat u bij een groot incident snel de juiste specialisten op de been heeft, ook ’s nachts en in het weekend, en dat u hen tijdig informeert.

DutyFlow maakt zichtbaar wie op welk moment dienst heeft en wie de back-up is. iTelAlert mobiliseert het incidentteam in één handeling, los van de systemen die door het incident zijn getroffen. De koppeling tussen DutyFlow en iTelAlert is in ontwikkeling.