Hoe Atlassian zorgt voor operationele gereedheid

Niveau-0: Kritieke infrastructuur

Een niveau-0-service biedt ondersteunende infrastructuur en gedeelde servicecomponenten waarop niveau-1-services afhankelijk zijn om te functioneren. Componenten worden als cruciaal beschouwd als een van de volgende situaties waar is:

• Ze zijn nodig voor de uitvoering van niveau-1-services of voor toegang voor gebruikers.
• Een klant heeft ze nodig om zich aan te melden voor een niveau-1-service
• Ze zijn nodig voor personeel om belangrijke operationele functies van een niveau-1-service te ondersteunen of uit te voeren, zoals:

- De service starten/stoppen/opnieuw starten
- Voer een implementatie, upgrade, roll-back of hotfix uit
- Bepaal de huidige status (omhoog/omlaag/gedegradeerd)

Niveau-1: Essentiële services

Een niveau-1-service biedt een essentiële functie voor bedrijven, klanten of producten. Dit zijn klantgerichte services of bedrijfskritieke interne services. Als de service verslechterd of niet beschikbaar is, verliest het bedrijf geld of kan het niet kritieke bedrijfsfuncties uitvoeren, en/of gaat de kernfunctionaliteit vanuit het oogpunt van de klant verloren. Niveau-1-services vereisen een supportrooster dat 24/7 beschikbaar is, hebben hoge SLA's voor belangrijke statistieken en hebben een reeks strenge vereisten om te kunnen starten.

Niveau-2: Niet-standaardservices

Een niveau-2-service biedt een klantgerichte service die geen deel uitmaakt van de kernfunctionaliteit. Niveau-2-services bieden een toegevoegde waarde of een aanvullende gebruikerservaring die als optioneel of 'hebbedingetje' kan worden beschouwd.

A tier-2 service includes public services that function mainly in a marketing capacity, such as public company websites. They don’t offer customers direct business-grade services and internal services used by teams to perform aspects of their roles, such as collaboration tools, work tracking, and more.

Niveau-2-services hebben mogelijk een supportrooster nodig dat 24/7 beschikbaar is, hebben lagere SLA's en minder vereisten voor het live gaan.

Niveau-3: Alleen interne of niet-kritieke functies

Een niveau-3-service biedt interne functionaliteit aan het bedrijf of experimentele bètaservices. Deze klasse kan ook services omvatten die momenteel een experimentele functie zijn voor vroege gebruikers, waarbij de verwachting is dat de kwaliteit van de service tijdens de bèta zal afnemen. Dit niveau biedt een lage SLA-bucket voor services die uitsluitend door inspanningen worden ondersteund.

Gegevensverlies (RPO)

Dit getal staat voor de maximale hoeveelheid gegevens die door de service verloren gaat bij een servicestoring. Bij een niveau-0-service gaat minder dan een uur aan gegevens verloren bij een servicestoring.

Herstel van de reservice (RTO)

Dit getal staat voor de maximale tijd voordat de service weer operationeel is. Een niveau-0-service wordt in minder dan vier uur volledig hersteld.

Back-ups

Als een service uitvalt, moeten teams mogelijk back-ups gebruiken om gegevens terug te zetten naar een bepaald tijdstip. Het is belangrijk om regelmatig back-ups van gegevens te maken, een herstelproces te implementeren en het back-up- en herstelproces regelmatig te testen. Het back-up- en herstelproces moet betrouwbaar en effectief zijn. Documentatie en testen zijn hierbij essentieel.

Definitie van Gereed

• Implementeer een back-up- en herstelproces
• Documenteer en test het back-up- en herstelproces
• Test regelmatig het back-up- en herstelproces
  

Capaciteitsmanagement

Geef duidelijk aan welke capaciteiten de service consumenten biedt. Identificeer met name eventuele beperkingen die de service aan consumenten oplegt. Implementeer prestatietests om ervoor te zorgen dat de service binnen de verwachte limieten werkt.

Hier zijn enkele voorbeelden van informatie om te testen en beschikbaar te stellen aan consumenten.

• De service is beperkt tot X vereisten per seconde
• De service garandeert een responstijd van X
• De X-functie van de service wordt al dan niet per regio gerepliceerd
• De consument zou niet X
  - de service mogen overbelasten
  - bestanden groter dan X moeten uploaden

Definitie van Voltooid

• Servicelimieten zijn geïdentificeerd en gedocumenteerd
• Er worden prestatietests uitgevoerd om te controleren of aan de limieten wordt voldaan
  

Bewustzijn van klanten

Ondersteunbaarheid is een belangrijk aspect van de kwaliteit van de service dat samengaat met betrouwbaarheid en bruikbaarheid. Teams moeten supportprocessen maken voor een service of nieuwe functie van een service voordat deze beschikbaar wordt gesteld. De support kan bestaan uit een proces voor klantenondersteuning, een proces voor wijzigingsbeheer, runbooks voor support en andere ondersteuningsgerichte items.

Proces voor klantenservice

Ontwikkelaars moeten begrijpen wat er gebeurt als klanten contact opnemen met het ondersteuningsteam voor hulp. Ze moeten ook begrijpen wat hun verantwoordelijkheden zijn met betrekking tot het ondersteuningsproces. Dit kan inhouden dat je deel uitmaakt van een roulatie op afroep of een situatie waar je gevraagd wordt om productieproblemen op te lossen zodra ze zich voordoen.

Proces voor wijzigingsbeheer

Niet alle veranderingen hebben op dezelfde manier invloed op klanten. Sommige veranderingen zijn voor klanten niet waarneembaar. Bijvoorbeeld een kleine bugfix. Sommige vergen veel inspanning van klanten om het te gebruiken, zoals een volledige herschrijving van een API. Wijzigingsbeheer helpt bij het beoordelen van de omvang van de impact op klanten die veranderingen kunnen hebben.

Ondersteuning voor runbooks

Runbooks bieden een uitgebreid overzicht van hoe een service werkt, evenals gedetailleerde uitleg over problemen die kunnen optreden en hoe deze opgelost kunnen worden. Het is belangrijk om de runbooks regelmatig bij te werken en te controleren of de gedocumenteerde ondersteuningsprocedures juist zijn naarmate de service in de loop van de tijd verandert.

Definitie van Voltooid

• Documentatie die de meeste vragen beantwoordt die het ondersteuningsteam nodig heeft om een probleem te onderzoeken
• Een werkend proces voor wijzigingsbeheer
  
  

Disaster Recovery

Een deel van een ramp is het verliezen van een beschikbaarheidszone. Services moeten voldoende veerkrachtig zijn om normaal te kunnen functioneren in geval van een storing in de beschikbaarheidszone. Disaster recovery bestaat uit twee componenten: ten eerste om een noodherstelproces te ontwikkelen en te documenteren en ten tweede om het gedocumenteerde proces voortdurend te testen. Disaster recovery moet regelmatig worden getest. Test de mogelijkheid om een storing in de beschikbaarheidszone op te lossen met behulp van het gedocumenteerde noodherstelplan.

Definitie van Voltooid

• Het DR-plan is gedocumenteerd
• Het DR-plan is getest
• Er zijn terugkerende tests van het DR-plan gepland
  

Loggen

Logs zijn nuttig om verschillende redenen, zoals het opsporen van afwijkingen, onderzoek tijdens of na een uitval van de service en het opsporen van kwaadaardige activiteiten door gerelateerde gebeurtenissen tussen services te koppelen met behulp van unieke identificatiegegevens. Er zijn veel soorten logs. Een paar zeer nuttige logs die de meeste services zouden moeten bevatten, zijn:

• Toegangslogs
• FOUTLOGBOEKEN

Definitie van Voltooid

• Er worden geschikte logs gegenereerd
• Logs worden ergens opgeslagen waar ze gemakkelijk te vinden en doorzoekbaar zijn
  

Logische toegangscontroles

Logische toegangscontroles richten zich op het beheren van interne gebruikerstoegang, toegang voor externe gebruikers, toegang van service tot service en gegevensversleuteling. Hoe voorkomt de service ongeoorloofde toegang tot functionaliteit en gegevens? Hoe worden gebruikersrechten gedefinieerd, geverifieerd, bijgewerkt en verouderd? Bieden deze controles voldoende bescherming voor gevoelige gegevens?

Interne gebruikers

Enkele belangrijke vragen om te beantwoorden zijn: Hoe worden interne gebruikers geverifieerd? Hoe wordt toegang toegekend/verleend? Hoe wordt het weggenomen? Hoe werkt een escalatie van bevoegdheden? Wat is het proces voor regelmatige toegangsbeoordelingen en audits?

Externe gebruikers

Hoe wordt authenticatie voor klanten afgehandeld? Hoe wordt toegang toegekend/verleend? Hoe wordt het weggenomen? Hoe werkt een escalatie van bevoegdheden? Wat is het proces voor regelmatige toegangsbeoordelingen en audits?

Van service naar service

Dit is vergelijkbaar met interne en externe gebruikers. Teams moeten bepalen hoe services zich bij elkaar authenticeren. Bijvoorbeeld door OAuth 2.0 in te stellen.

Versleuteling

Teams willen waarschijnlijk hun gegevens versleutelen wanneer ze in-transit en at-rest zijn. Leg uit hoe de service de versleuteling van gegevens beheert. Hoe gaat het team om met codes? Wat is het beleid voor de roulatie van codes?

Definitie van Voltooid

• Logische toegangscontroles worden gedocumenteerd, geïmplementeerd en getest voor interne gebruikers, externe gebruikers en van service tot service.
• Gegevens worden versleuteld at-rest
• Gegevens worden versleuteld in-transit
• Versleuteling is geïmplementeerd en getest
  

Releases

De implementatie van een nieuwe versie van de service mag het klantenverkeer niet verder verstoren dan wat is gedefinieerd in de SLA van de service. Alle wijzigingen moeten door collega's worden beoordeeld, getest en geïmplementeerd via CI/CD-pipelines. Controleer na elke implementatie of de implementatie succesvol was en of er geen functionaliteit kapot ging. Geautomatiseerde verificatie na de implementatie heeft de voorkeur. Zorg voor meerdere omgevingen, zoals tests, stagen, pre-productie en productie, zodat implementaties kunnen worden getest.

Definitie van Voltooid

• De service heeft een zero downtime-installatie
• Er zijn omgevingen waarin de service moet worden geïmplementeerd en getest voordat de productie kan worden gestart
  

Beveiligingschecklist

De beveiligingschecklist is een reeks praktijken en standaarden voor het ontwikkelen en onderhouden van veilige infrastructuur en software. Deze standaarden verkleinen de kans op privacyschendingen en datalekken en leiden op hun beurt tot een groter vertrouwen van klanten. Teams moeten een beveiligingschecklist opstellen waarin wordt ingegaan op de aard van de service die ze bouwen. Zie hier een aantal voorbeelden van vereisten:

Definitie van Voltooid

• Bewijs dat er geen open kritieke of grote kwetsbaarheden bestaan voor de service
• Gebruik van versleuteling at-rest voor alle datastores
• Bewijs dat de service geen onveilige HTTP-verbindingen toestaat
  

Servicestatistieken

Servicestatistieken bieden essentiële gezondheids- en diagnostische informatie over een service en stellen teams in staat om incidenten te monitoren en erop te reageren. Begin met het definiëren van een reeks statistieken die voor elke service worden gemonitord. Maak vervolgens een dashboard met deze statistieken in een tool zoals Datadog of New Relic. Sla alarm als een statistiek te ver gaat en verhoog probleemtickets in geval van een alarm.

Definitie van Voltooid
Hier zijn enkele voorbeelden van zaken om te meten:

• Latentie: de tijd die nodig is om een aanvraag te behandelen
• Verkeer: belasting op de service van externe gebruikers
• Fouten: aantal gebruikers dat invloed heeft op fouten of storingen
• Verzadiging: hoe druk is de service en hoeveel meer kan de service aan?
• Onderliggend bronnengebruik: CPU, geheugen, schijf
• Interne onderdelen van de applicatie, zoals wachtrijen, tijdstippen en flow
• Gebruik en kernfunctionaliteit van je service: actieve gebruikers, acties per minuut
  

Veerkrachtige service

De vereisten voor de veerkrachtigheid van de service bepalen of een service veranderingen in de belasting en/of defecten van verschillende onderdelen aankan. Een service die veerkrachtig is, wordt waarschijnlijk automatisch geschaald en is bestand tegen storingen in één knooppunt.

Automatisch schalen

Als de service automatisch kan worden geschaald, zorg er dan voor dat de automatische schaling goed is geconfigureerd en getest. Bepaal welke statistiek automatische schaling activeert en test of deze werkt. Als de service bijvoorbeeld vereist dat gegevens op een schijf worden opgeslagen, kan deze het percentage vrije schijfruimte controleren en automatisch schalen door opslagruimte toe te voegen wanneer het percentage vrije ruimte onder een drempelwaarde daalt.

Testen op storingen in één knooppunt

Het is wenselijk om over services te beschikken die kunnen overleven bij storingen in één knooppunt. Als één serviceknooppunt uitvalt, moet de service blijven functioneren, mogelijk met een verminderde capaciteit. Test dit door ten minste één knooppunt in de service af te sluiten en het gedrag van het systeem te observeren. Er wordt verwacht dat jouw service één knooppuntstoring oplost. De omgeving waarin je een storing in één knooppunt gaat simuleren, moet in de gaten worden gehouden.

Definitie van Voltooid

• Bewijs van automatische schaalbaarheid die geïmplementeerd en getest is
• Bewijs dat er in de productie- en/of testomgeving meerdere knooppunten worden uitgevoerd.
• Bewijs dat de service bestand is tegen storingen in één knooppunt
  

Ondersteuning

Support is het proces om een service te ondersteunen na release. Teams moeten beschikken over runbooks, ops-tools en roulaties op afroep voordat ze live gaan, zodat services die problemen ondervinden een procedure hebben om ze op te lossen.

Runbooks

Runbooks bieden op-afroepresonders de context en instructies die ze nodig hebben voor incidentrespons en herstelinspanningen.

Ops-tools

Een service naar een voldoende standaard uitvoeren betekent dat er een op-afroeprooster is en dat een ops-tool zoals Opsgenie is ingesteld om de aanwezigen te waarschuwen wanneer er problemen zijn met de service.

Op afroep

Voor een niveau-2- en niveau-3-service is een op-afroeprooster vereist

Voor een niveau-1- en niveau-0-service is een op-afroeprooster van 24/7 vereist

Definitie van Voltooid

• Runbooks zijn geschreven en kunnen worden gevonden door support
• De Ops-tool is geconfigureerd en getest
• Er is een op-afroeproulatie en mensen worden opgeroepen als er problemen zijn
  

Voorgestelde controles voor operationale gereedheid van niveau-3

• Back-ups
• Loggen
• Releases
• Beveiligingschecklist
• Servicestatistieken
• Support
  

Niveau-3-services beginnen met de meest elementaire vereisten voor operationele gereedheid.

Voorgestelde controles van de operationele gereedheid van niveau-2 en niveau-1

• Back-ups
• Disaster Recovery
• Loggen
• Releases
• Beveiligingschecklist
• Servicestatistieken
• Veerkrachtige service
• Ondersteuning

Niveau-2- en niveau-1-services voegen de vereisten voor disaster recovery en veerkracht van de service toe. Het is belangrijk om op te merken dat niveau-2- en niveau-1-services verschillende vereisten voor operationele gereedheid kunnen hebben. Het is niet verplicht dat de niveaus verschillende vereisten hebben. Als een andere vereiste operationele gereedheid noodzakelijk wordt geacht voor een specifiek serviceniveau, voeg die dan toe. Niveau-2 en niveau-1 kunnen verschillen, afhankelijk van de behoeften van het team.

Voorgestelde controles voor operationale gereedheid van niveau-0

• Back-ups
• Capaciteitsmanagement
• Bewustzijn van klanten
• Disaster Recovery
• Loggen
• Logische toegangscontroles
• Releases
• Beveiligingschecklist
• Servicestatistieken
• Veerkrachtige service
• Ondersteuning

Niveau-0-services voegen capaciteitsbeheer, klantbewustzijn en logische toegangscontroles toe.