Resiliência de serviço incorporada no Microsoft 365

A Microsoft reconhece a necessidade de fornecer soluções que funcionem de forma consistente e permaneçam altamente disponíveis de forma a que os nossos clientes possam confiar nas mesmas. Quando um determinado serviço está indisponível, chama-se período de indisponibilidade. A definição do tempo de inatividade varia de acordo com o serviço do Microsoft 365, mas normalmente se concentra em qualquer período de tempo em que os usuários não conseguem usar a funcionalidade essencial do serviço. Por exemplo, eis a definição de tempo de inatividade para o SharePoint retirado do contrato de nível de serviço do Microsoft 365:

"Tempo de Inatividade do SharePoint: qualquer período de tempo em que os utilizadores não consigam ler ou escrever qualquer parte de uma coleção de sites do SharePoint para a qual tenham as permissões adequadas."

Você pode encontrar as definições de tempo de inatividade para cada serviço nos Acordos de nível de serviço.

Para minimizar o tempo de inatividade, seja planejado ou inesperado, os serviços do Microsoft 365 são projetados e operados para estarem altamente disponíveis e serem resilientes a falhas, concentrando-se em quatro áreas:

Design ativo/ativo

No Microsoft 365, estamos a caminhar para que todos os serviços sejam arquitetados e operados num design ativo/ativo que aumente a resiliência. Esta estrutura significa que existem sempre várias instâncias de um serviço em execução que podem responder a pedidos de utilizador e que estão alojadas em datacenters dispersos geograficamente. Todo o tráfego de usuário é fornecido pelo serviço de Porta Frontal da Microsoft e é roteado automaticamente para a instância com localização ideal para o serviço e para se desviar de qualquer falha de serviço a fim de evitar ou reduzir o impacto em nossos clientes.

Redução do escopo do incidente

O escopo de um incidente de serviço é medido de acordo com a gravidade, duração e número de clientes afetados. Gostaríamos de limitar o escopo de todos os incidentes ao:

• ter várias instâncias de cada serviço particionadas umas das outras
• implantar atualizações de forma controlada e graduada usando anéis de validação, para que seja possível detectar e atenuar todos os problemas que possam surgir com a atualização logo no início do processo de implantação. Esta estrutura permite a regressão da atualização, se necessário, e ocorre primeiro num pequeno grupo dentro da Microsoft (cadência interna) antes de ser implementada para grupos maiores, como todos os 140.000 funcionários da Microsoft (anel 2), depois para anéis adotantes iniciais (anel 3) e, em última análise, para todos os clientes globalmente (anel 4).
• gerando melhorias no monitoramento por meio da automação. O Microsoft 365 é um serviço grande e o tempo de atividade de destino do SLA é elevado. No início de um incidente de serviço, se houvesse a necessidade de intervenção humana na detecção e resposta, não conseguiríamos responder de forma rápida o suficiente para atender aos SLAs. A automação é a chave para a detecção e resposta rápidas e eficazes de incidentes de serviço. Quanto mais cedo soubermos de algo, mais rápido poderemos corrigir o problema.

Juntamente com as capacidades ativas/ativas incorporadas na arquitetura do serviço Microsoft 365, estes esforços mitigam a gravidade, a duração e o número de clientes afetados durante um incidente de serviço.

Isolamento de falhas

Assim como os serviços são projetados e operados de maneira ativa/ativa e são divididos entre si para evitar que uma falha afete outra, a base de código do serviço é desenvolvida usando princípios de particionamento semelhantes, os chamados isolamento de falhas. As medidas de isolamento de falha são proteções incrementais feitas dentro da própria base de código. Essas medidas ajudam a impedir que um problema em uma área se propague para outras áreas de operação.

As medidas de isolamento de falhas são aplicadas em várias fases do desenvolvimento e entrega de um serviço, incluindo desenvolvimento de código, implementação de serviços, balanceamento de carga e replicação de base de dados.

O SDL (Microsoft Security Development Lifecycle) promove a resiliência e consiste em um conjunto de práticas que oferece suporte a requisitos de segurança e conformidade. O SDL orienta nossos desenvolvedores na criação de serviços resilientes, seguros e em conformidade. Os principais elementos do SDL incluem revisões de códigos, modelagem de ameaças, testes de penetração e processos padronizados de resposta a incidentes na nuvem da Microsoft.

Os serviços do Microsoft 365 estão altamente interligados, mas os sistemas e a tecnologia subjacentes são concebidos de forma a limitar o impacto de um incidente de serviço de transposição para outros serviços. Por exemplo, um problema que afeta o Exchange não afetará a funcionalidade principal no Teams ou um problema com a funcionalidade de pesquisa no SharePoint não afetará a capacidade dos utilizadores de carregar ou transferir ficheiros.

Melhoria contínua do serviço

Levamos a sério quando um incidente ocorre. Afinal, nossa arquitetura de nuvem redundante e processos internos rigorosos visam manter nossos serviços acessíveis. Durante um incidente, a nossa monitorização deteta rapidamente os serviços afetados e, se o seu inquilino for afetado, será notificado através de vários canais. Simultaneamente, os engenheiros seguem processos bem definidos para analisar o problema e tomar as medidas necessárias para restaurar a operação normal assim que possível. Depois que o serviço volta a funcionar normalmente, realizamos revisões pós-incidente como parte do ciclo de melhoria contínua do serviço. Durante a revisão pós-incidente, identificamos as causas principais do incidente e o que foi necessário para corrigir os problemas. Em seguida, usamos o que foi aprendido com a situação e aplicamos ao design e às operações de todo o nosso pacote de ofertas. Com este conhecimento, podemos impedir que a mesma causa principal afete outros serviços e clientes adicionais.