Resilienza del servizio predefinita in Microsoft 365

Come provider di servizi cloud, Microsoft riconosce la necessità di guadagnare continuamente la fiducia degli utenti fornendo soluzioni che funzionino in modo coerente e che piacciano agli utenti. Quando un determinato servizio non è disponibile, viene chiamato tempo di inattività. La definizione del tempo di inattività varia in base a ogni servizio Microsoft 365, ma in genere sta a indicare un periodo di tempo in cui gli utenti non riescono a usare le funzionalità essenziali del servizio. Ad esempio, ecco la definizione di tempo di inattività per SharePoint Online, tratta dal contratto di servizio di Microsoft 365:

“Tempo di inattività di SharePoint Online: periodo di tempo in cui gli utenti non riescono né a leggere né a scrivere qualunque parte di una raccolta siti di SharePoint Online per cui dispongono delle autorizzazioni appropriate".

È possibile trovare le definizioni di tempo di inattività per ogni servizio nei Contratti di servizio.

Per ridurre al minimo i tempi di inattività, sia previsti che non previsti, i servizi di Microsoft 365 sono progettati e gestiti per essere altamente disponibili e resistenti ai guasti concentrandosi su quattro aree:

Modello attivo/attivo

In Microsoft 365 stiamo guidando verso l'architettura e il funzionamento di tutti i servizi in una progettazione attiva/attiva che aumenta la resilienza. Questa progettazione significa che sono sempre presenti più istanze di un servizio in esecuzione che possono rispondere alle richieste degli utenti e che sono ospitate in data center geograficamente distribuiti. Tutto il traffico degli utenti passa per il servizio Frontdoor di Microsoft e viene automaticamente instradato verso l'istanza del servizio meglio posizionata ed evitando qualsiasi errore di servizio per impedire o ridurre l'impatto sui clienti.

Ridurre la portata degli eventi imprevisti

La portata di un evento imprevisto relativo a un servizio viene misurata in base al livello di gravità, alla durata e al numero di clienti interessati. Per limitare la portata di tutti gli eventi imprevisti sono in atto le seguenti misure:

• avere più istanze di ogni servizio divise l’una dall’altra
• distribuire gli aggiornamenti in modo controllato e graduato usando anelli di convalida in modo che gli eventuali problemi che potrebbero derivare dall'aggiornamento possano essere individuati e attenuati all'inizio del processo di distribuzione. Questa progettazione consente la regressione dell'aggiornamento, se necessario, e si verifica prima in un piccolo gruppo all'interno di Microsoft (anello interno) prima che venga distribuito per gruppi più grandi come tutti i 140.000 dipendenti Microsoft (anello 2), quindi per gli anelli early adopter (anello 3) e infine per tutti i clienti a livello globale (anello 4).
• migliorare il monitoraggio tramite l’automazione. Microsoft 365 è un servizio di grandi dimensioni e il tempo di attività della destinazione del contratto di servizio è elevato. All'inizio di un evento imprevisto di un servizio, se gli esseri umani dovessero occuparsi del rilevamento e della risposta, non sarebbe possibile rispondervi abbastanza velocemente da rispettare il contratto di servizio. L'automazione è la chiave per individuare e rispondere in modo rapido ed efficace. Prima si viene a conoscenza di un problema, prima questo può essere risolto.

Insieme alle funzionalità attive/attive integrate nell'architettura del servizio Microsoft 365, queste attività riducono la gravità, la durata e il numero di clienti interessati durante un evento imprevisto del servizio.

Isolamento del guasto

Così come i servizi sono progettati e gestiti in modo attivo/attivo e sono divisi l’uno dall’altro per evitare che un errore in uno di essi influisca su un altro, il code base del servizio viene sviluppato usando simili criteri di partizionamento denominati isolamento del guasto. Le misure di isolamento del guasto sono protezioni incrementali eseguite all'interno del code base stesso. Queste misure consentono di impedire che un problema verificatosi in un'area si propaghi ad altre aree di attività. Le misure di isolamento degli errori vengono applicate in più fasi dello sviluppo e del recapito di un servizio, tra cui sviluppo di codice, distribuzione del servizio, bilanciamento del carico e replica del database.

Il Microsoft Security Development Lifecycle (SDL) favorisce ulteriormente la resilienza e consiste in una serie di procedure che supportano i requisiti di sicurezza e conformità. SDL consente agli sviluppatori di creare servizi resilienti, sicuri e conformi. Gli elementi principali di SDL includono revisioni di codice, modellazione delle minacce, test di penetrazione e processi standard di risposta agli eventi imprevisti nel cloud di Microsoft.

I servizi di Microsoft 365 sono altamente interconnessi, ma i sistemi e la tecnologia sottostanti sono progettati in modo da limitare l'impatto di un evento imprevisto del servizio dalla distribuzione ad altri servizi. Ad esempio, un problema che interessa Exchange Online non influirà sulle funzionalità di base di Teams o un problema con la funzionalità di ricerca in SharePoint Online non influirà sulla capacità degli utenti di caricare o scaricare file.

Miglioramento continuo del servizio

Se si verifica un evento imprevisto, è importante prenderlo seriamente. Dopo tutto, l'architettura cloud ridondante e i rigorosi processi interni di Microsoft hanno l’obiettivo di mantenere accessibili i servizi. Durante un evento imprevisto, il monitoraggio rileva rapidamente i servizi interessati e, se il tenant è interessato, verrà inviata una notifica immediatamente tramite vari canali. Contemporaneamente, gli ingegneri seguono processi ben definiti per la valutazione del problema ed eseguono i passaggi necessari per ripristinare il funzionamento normale nel più breve tempo possibile. Una volta che il servizio funziona di nuovo normalmente, delle revisioni post-evento imprevisto vengono integrate nel ciclo di miglioramento continuo del servizio. Durante la revisione post-evento imprevisto vengono identificate le cause principali dell’evento imprevisto e gli elementi necessari alla risoluzione dei problemi. Infine, quello che si è imparato dalla situazione viene applicato ai modelli e alle operazioni dell’intera famiglia di prodotti. Con questa conoscenza, è possibile impedire che la stessa causa radice influirà su altri servizi e clienti aggiuntivi.