In che modo Atlassian garantisce la prontezza operativa

Livello 0: infrastruttura di backbone critica

Un servizio di livello 0 fornisce l'infrastruttura di assistenza e i componenti di servizio condivisi necessari per il funzionamento dei servizi di livello 1. I componenti sono considerati fondamentali se si verifica una delle seguenti condizioni:

• Sono necessari per l'esecuzione di un servizio di livello 1 o per l'accesso dei suoi utenti.
• Sono necessari affinché un cliente possa effettuare la registrazione a un servizio di livello 1.
• Sono necessari affinché il personale possa supportare o svolgere funzioni operative chiave su un servizio di livello 1, come:

- Avvio/Arresto/Riavvio del servizio
- Esecuzione di una distribuzione, di un upgrade, di un rollback o di un hotfix
- Determinazione dello stato corrente (attivo/non attivo/riduzione delle prestazioni)

Livello 1: servizi essenziali

Un servizio di livello 1 fornisce una funzione fondamentale per l'azienda, il cliente o il prodotto. Si tratta di servizi rivolti ai clienti o di servizi interni business-critical. Quando si verifica un peggioramento delle prestazioni del servizio, l'azienda perde denaro o non è in grado di svolgere funzioni business-critical e/o per il cliente si verifica una perdita delle funzionalità essenziali. I servizi di livello 1 richiedono un'assistenza con reperibilità 24 ore su 24, 7 giorni su 7, hanno SLA elevati per le metriche chiave e una serie rigorosa di requisiti di distribuzione.

Livello 2: servizi non essenziali

Un servizio di livello 2 fornisce un servizio rivolto al cliente che non fa parte delle funzionalità principali. I servizi di livello 2 forniscono un valore aggiunto o un'esperienza utente aggiuntiva che potrebbe essere considerata opzionale o comunque preferenziale.

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.

I servizi di livello 2 possono richiedere o meno l'assistenza con reperibilità 24 ore su 24, 7 giorni su 7, avere SLA meno rigorosi e un minor numero di requisiti di distribuzione.

Livello 3: funzionalità solo interne o non critiche

Un servizio di livello 3 fornisce funzionalità interne all'azienda o servizi beta. Questa classe può includere anche servizi che sono attualmente in fase sperimentale per i primi utenti e dove è prevista l'eventualità di un peggioramento delle prestazioni. Questo livello fornisce un bucket di SLA bassi per i servizi per i quali è prevista unicamente un'assistenza "al meglio".

Perdita di dati (RPO)

Questo numero rappresenta la quantità massima di dati che verranno persi dal servizio in caso di guasto del servizio. Per un servizio di livello 0 si verificherà una perdita di dati inferiore a un'ora in caso di guasto del servizio.

Ripristino del servizio (RTO)

Questo numero rappresenta la quantità di tempo massima prima che il servizio sia di nuovo attivo e funzionante. Un servizio di livello 0 verrà ripristinato completamente in meno di quattro ore.

Backup

Quando si verifica un'interruzione di un servizio, i team potrebbero dover utilizzare i backup per ripristinare i dati in un determinato momento. È importante eseguire backup regolari dei dati, implementare un processo di ripristino e testare regolarmente il processo di backup e ripristino. Il processo di backup e ripristino dovrebbe essere affidabile ed efficace. In questo ambito la documentazione e i test sono fondamentali.

Definizione di completato

• Implementazione di un processo di backup e ripristino
• Documentazione e test del processo di backup e ripristino
• Test condotti regolarmente sul processo di backup e ripristino
  

Gestione delle capacità

Descrivi chiaramente le capacità che il servizio offre ai consumatori. In particolare, identifica gli eventuali limiti che il servizio impone loro. Implementa test delle prestazioni per garantire che il servizio funzioni nell'ambito dei limiti previsti.

Ecco alcuni esempi di informazioni da testare e mettere a disposizione dei consumatori.

• Il servizio è limitato a X requisiti al secondo.
• Il servizio garantisce un tempo di risposta pari a X.
• La funzione X del servizio è o non è replicata in tutte le regioni.
• Il consumatore non dovrebbe effettuare X
  - sovraccaricare il servizio
  - caricare file di dimensioni maggiori di X

Definizione di "completato"

• I limiti di servizio sono identificati e documentati.
• Vengono condotti test delle prestazioni per verificare l'applicazione dei limiti.
  

Consapevolezza dei clienti

La supportabilità è un aspetto importante della qualità del servizio che va di pari passo con l'affidabilità e l'usabilità. I team devono creare processi di assistenza per un servizio o una nuova funzionalità di un servizio prima che venga implementata. La supportabilità può includere un processo di assistenza clienti, un processo di controllo delle modifiche, runbook di assistenza e altri aspetti incentrati sull'assistenza.

Processo di assistenza clienti

Gli sviluppatori devono capire cosa succede quando i clienti contattano il team di assistenza e devono comprendere le proprie responsabilità con riferimento al processo di assistenza. Ciò può includere la partecipazione a una rotazione su chiamata o la richiesta di risolvere i problemi di produzione man mano che si verificano.

Processo di controllo delle modifiche

Non tutte le modifiche hanno lo stesso impatto sui clienti. Alcune sono impercettibili per i clienti, ad esempio, una piccola correzione di bug; altre comportano un impegno elevato da parte dei clienti, come una riscrittura completa di un'API. Il controllo delle modifiche aiuta a valutare l'entità dell'impatto che le modifiche potrebbero avere sul cliente.

Runbook di assistenza

I runbook forniscono una panoramica generale del funzionamento di un servizio, oltre a spiegazioni dettagliate dei problemi che possono verificarsi e su come risolverli. È importante aggiornare regolarmente i runbook e verificare che le procedure di assistenza documentate vengano aggiornate man mano che il servizio cambia nel tempo.

Definizione di "completato"

• Documentazione che risponde alla maggior parte delle domande che il team di assistenza potrebbe avere per condurre le dovute indagini su un problema.
• Un processo funzionante per il controllo delle modifiche.
  
  

Disaster Recovery

Un evento disastroso comporta varie conseguenze, tra cui la perdita di una zona di disponibilità. I servizi devono disporre di una resilienza sufficiente per funzionare normalmente in caso di guasto di una zona di disponibilità. Il ripristino di emergenza ha due componenti: il primo serve per sviluppare e documentare un processo di ripristino di emergenza e il secondo per eseguire test continui del processo documentato. Il ripristino di emergenza deve essere testato regolarmente. Verifica la capacità di gestire un errore nella zona di disponibilità utilizzando il piano documentato di ripristino di emergenza.

Definizione di "completato"

• Il piano di ripristino di emergenza è documentato.
• Il piano di ripristino di emergenza è testato.
• Sono previsti test ricorrenti del piano di ripristino di emergenza.
  

Registrazione

I log sono utili per innumerevoli motivi, ad esempio il rilevamento di anomalie, le indagini durante o dopo un'interruzione del servizio e il monitoraggio di attività dannose effettuato utilizzando identificatori univoci per connettere eventi correlati tra i servizi. Esistono molti tipi di log. Alcuni sono molto utili e dovrebbero essere inclusi nella maggior parte dei servizi. Tra questi:

• Log di accesso
• LOG DEGLI ERRORI

Definizione di "completato"

• Vengono generati i log appropriati
• I log sono archiviati in una certa posizione e sono facilmente reperibili e ricercabili
  

Controlli logici degli accessi

Lo scopo principale dei controlli logici degli accessi è quello di gestire l'accesso degli utenti interni, l'accesso degli utenti esterni, l'accesso da servizio a servizio e la crittografia dei dati. In che modo il servizio impedisce l'accesso non autorizzato a funzionalità e dati? Come vengono definite, verificate, aggiornate e deprecate le autorizzazioni utente? Questi controlli forniscono una protezione sufficiente per i dati sensibili?

Utenti interni

Ecco alcune domande importanti a cui rispondere: come vengono autenticati gli utenti interni? Come viene concesso/fornito l'accesso? Come viene revocato? In che modo funziona un'escalation di privilegi? Qual è la procedura per le revisioni e gli audit regolari degli accessi?

Utenti esterni

Come viene gestita l'autenticazione per i clienti? Come viene concesso/fornito l'accesso? Come viene revocato? In che modo funziona un'escalation di privilegi? Qual è la procedura per le revisioni e gli audit regolari degli accessi?

Da servizio a servizio

La procedura è simile a quella per gli utenti interni ed esterni. I team devono stabilire la modalità reciproca di autenticazione dei servizi, ad esempio configurando OAuth 2.0.

Crittografia

I team probabilmente vogliono crittografare i propri dati inattivi e in transito. In che modo il servizio gestisce la crittografia dei dati? In che modo il team gestisce le chiavi? Qual è la policy di rotazione delle chiavi?

Definizione di "completato"

• I controlli logici di accesso sono documentati, implementati e testati per gli utenti interni, gli utenti esterni e da servizio a servizio.
• I dati vengono crittografati quando sono inattivi.
• I dati vengono crittografati in transito.
• La crittografia è implementata e testata.
  

Release

La distribuzione di una nuova versione del servizio non deve causare interruzioni nel traffico dei clienti in misura maggiore di quanto definito nello SLA dei servizi. Tutte le modifiche devono essere sottoposte a peer review, testate e distribuite tramite pipeline CI/CD. Verifica che ogni distribuzione effettuata sia andata a buon fine e non abbia causato alcuna interruzione nelle funzionalità. È preferibile la verifica automatizzata post-distribuzione. La disponibilità di più ambienti come test, staging, pre-produzione e produzione permette di testare le distribuzioni.

Definizione di "completato"

• Il servizio prevede una distribuzione senza tempo di inattività.
• In alcuni ambienti il servizio deve essere distribuito e testato prima di essere inviato in produzione.
  

Checklist di sicurezza

La checklist di sicurezza è un insieme di pratiche e standard per lo sviluppo e la manutenzione di infrastrutture e software sicuri. Questi standard riducono la probabilità che si verifichino violazioni della privacy e dei dati e, di conseguenza, determinano una maggiore fiducia da parte dei clienti. I team devono sviluppare una checklist di sicurezza che tenga conto della natura del servizio che stanno creando. Ecco alcuni esempi di requisiti:

Definizione di "completato"

• Prova che non esistono vulnerabilità aperte, critiche o elevate per il servizio.
• Utilizzo della crittografia dei dati a riposo per tutti gli archivi dati.
• Prova che il servizio non consente connessioni HTTP non sicure.
  

Metriche del servizio

Le metriche del servizio forniscono informazioni diagnostiche e di stato essenziali in relazione a un servizio e consentono ai team di monitorare e rispondere agli imprevisti. Inizia definendo una serie di metriche monitorate per ogni servizio. Quindi, crea una dashboard con queste metriche in uno strumento come Datadog o New Relic. Attiva allarmi quando una metrica supera i limiti e genera ticket di problemi in caso di allarme.

Definizione di "completato"
Ecco alcuni esempi di aspetti da misurare:

• Latenza: il tempo impiegato per gestire una richiesta.
• Traffico: carico sul servizio da parte di utenti esterni.
• Errori: numero di utenti che influiscono su errori o guasti.
• Saturazione: livello di occupazione del servizio e disponibilità residua.
• Utilizzo delle risorse sottostanti: CPU, memoria, disco.
• Elenchi interni dell'applicazione come code, tempistiche e flusso.
• Utilizzo e funzionalità principali del servizio: utenti attivi, azioni al minuto.
  

Resilienza del servizio

I requisiti di resilienza del servizio determinano se un servizio è in grado o meno di gestire le modifiche di carico e/o i guasti di vari componenti. Un servizio resiliente è probabilmente scalabile in modo automatico e in grado di resistere ai guasti di un singolo nodo.

Scalabilità automatica

Se il servizio è scalabile automaticamente, assicurati che la scalabilità automatica sia testata e configurata in modo appropriato. Determina la metrica che attiverà la scalabilità automatica e testala per verificarne il funzionamento. Ad esempio, se il servizio richiede l'archiviazione di dati su disco, può monitorare la percentuale dello spazio libero sui dischi ed è scalabile automaticamente aggiungendo spazio di archiviazione quando la percentuale di spazio libero scende al di sotto di una determinata soglia.

Test dei guasti di un singolo nodo

È auspicabile disporre di servizi in grado di continuare a funzionare qualora si verifichi un guasto di un singolo nodo. Se un singolo nodo di servizio non funziona, il servizio dovrebbe continuare a funzionare, anche con una capacità ridotta. Prova a effettuare questa verifica terminando almeno un nodo del servizio e osserva il comportamento del sistema. Il servizio dovrebbe essere in grado di gestire il guasto di un singolo nodo. L'ambiente in cui simulerai un guasto di un singolo nodo deve essere monitorato.

Definizione di "completato"

• Prova che la scalabilità automatica è implementata e testata.
• Prova che gli ambienti di produzione e/o di staging eseguono più nodi.
• Prova che il servizio è resiliente a un guasto di un singolo nodo.
  

Assistenza

L'assistenza è il processo di assistenza per un servizio fornito dopo il rilascio. I team devono disporre di runbook, strumenti operativi e rotazioni su chiamata prima di effettuare la distribuzione dei servizi, in modo che sia presente un processo per correggere i servizi con problemi.

Runbook

I runbook forniscono agli addetti alla risposta su chiamata il contesto e le istruzioni di cui hanno bisogno per gestire la riposta rapida agli imprevisti e le attività di correzione.

Strumenti operativi

Eseguire un servizio in conformità a uno standard sufficiente significa che è disponibile la reperibilità su chiamata e che è configurato uno strumento operativo come Opsgenie per inviare avvisi su chiamata in caso di problemi del servizio.

Reperibilità

Per un servizio di livello 2 e 3 è richiesta la reperibilità su chiamata.

Per un servizio di livello 1 è richiesta la reperibilità su chiamata 24 ore su 24, 7 giorni su 7.

Definizione di "completato"

• I runbook sono scritti e reperibili dall'assistenza.
• Lo strumento operativo è configurato e testato.
• Sono implementate rotazioni su chiamata e il personale viene contattato in caso di problemi.
  

Controlli di prontezza operativa suggeriti di livello 3

• Backup
• Registrazione
• Release
• Checklist di sicurezza
• Metriche del servizio
• Assistenza
  

I servizi di livello 3 iniziano con i requisiti di prontezza operativa di base.

Controlli di prontezza operativa suggeriti di livello 2 e 1

• Backup
• Disaster Recovery
• Registrazione
• Release
• Checklist di sicurezza
• Metriche del servizio
• Resilienza del servizio
• Assistenza

I servizi di livello 2 e 1 aggiungono requisiti di prontezza operativa per il ripristino di emergenza e la resilienza del servizio. È importante notare che i servizi di livello 2 e 1 potrebbero avere requisiti di prontezza operativa diversi. Non è necessario che i livelli abbiano requisiti diversi. Se un altro requisito di prontezza operativa è ritenuto necessario per un livello di servizio specifico, aggiungilo. Il livello 2 e il livello 1 potrebbero divergere in base alle esigenze del team.

Controlli di prontezza operativa suggeriti di livello 0

• Backup
• Gestione delle capacità
• Consapevolezza dei clienti
• Disaster Recovery
• Registrazione
• Controlli logici degli accessi
• Release
• Checklist di sicurezza
• Metriche del servizio
• Resilienza del servizio
• Assistenza

I servizi di livello 0 aggiungono la gestione della capacità, la consapevolezza dei clienti e i controlli logici degli accessi.