Inbyggd återhämtningBuilt in resiliency

Som molnsamarbetsleverantör känner Microsoft till behovet av att ständigt vinna ditt förtroende genom att erbjuda lösningar som fungerar konsekvent och som användarna tycker om.As your cloud collaboration provider, Microsoft recognizes the need to continuously earn your trust by providing solutions that function consistently and that your users love. När en viss tjänst inte är tillgänglig kallas detta för driftsavbrott.When any given service is unavailable, this is called downtime. Definitionen av driftsavbrott varierar beroende på var och en av tjänsterna Microsoft 365, men de har vanligtvis fokus på vilken tidsperiod som helst när användare inte kan använda tjänstens väsentliga funktioner.The definition of downtime varies for each Microsoft 365 service, but they commonly focus on any period of time when users are unable to use the essential functionality of the service. Här är till exempel definitionen av driftsavbrott för SharePoint Online från Microsoft 365-tjänstenivåavtalet:For example, here's the definition of downtime for SharePoint Online taken from the Microsoft 365 service level agreement:

”SharePoint Online-driftsavbrott: valfri tidsperiod när användare inte kan läsa eller skriva någon del av en SharePoint Online-webbplatssamling som de har tillräcklig behörighet för.”"SharePoint Online Downtime: Any period of time when users are unable to read or write any portion of a SharePoint Online site collection for which they have appropriate permissions."

Du hittar definitioner av driftsavbrott för varje tjänst i tjänstenivåavtalen.You can find the downtime definitions for each service in the Service Level Agreements.

För att minimera driftsavbrott, antingen planerat eller oväntat, blir Microsoft 365-tjänsterna utformade och drivna för att ha hög tillgänglighet och vara motståndskraftiga mot fel genom att fokusera på fyra områden:To minimize downtime, either planned or unexpected, Microsoft 365 services are designed and operated to be highly available and resilient to failure by focusing on four areas:

Aktiv/aktiv-strukturActive/Active design

I Microsoft 365 strävar vi efter att ha alla tjänster konstruerade och drivna i en aktiv/aktiv design vilket ökar återhämtningen.In Microsoft 365 we are driving towards having all services architected and operated in an active/active design which increases resiliency. Det innebär att alltid ha flera instanser av en tjänst som körs och som kan svara på användarförfrågningar och som finns i geografiskt spridda datacenter.This means that there are always multiple instances of a service running that can respond to user requests and that they are hosted in geographically dispersed datacenters. All användartrafik kommer via tjänsten Microsoft Front Door och dirigeras automatiskt till den instans av tjänsten som är bäst och kommer att ligga nära alla misslyckade försök att förhindra eller minska påverkan på våra kunder.All user traffic comes in through the Microsoft Front Door service and is automatically routed to the optimally located instance of the service and around any service failures to prevent or reduce impact to our customers.

Minska händelsens omfattningReduce incident scope

Omfattningen av en tjänsthändelse mäts genom hur allvarligt det är, hur lång tid det varar och hur många kunder som påverkas.The scope of a service incident is measured by how severe it is, how long it lasts and how many customers are impacted. Vi strävar efter att begränsa omfattningarna för alla händelser genom att:We strive to limit the scope of all incidents by:

  • ha flera instanser av varje tjänst partitionerade från varandrahaving multiple instances of each service partitioned off from each other
  • distribution av uppdateringar på ett kontrollerat sätt med hjälp av verifieringsringar, så att problem som kan uppstå från uppdateringen kan upptäckas och minskas tidigt i distributionsprocessen.deploying updates in a controlled, graduated fashion using rings of validation so that any issues that might arise from the update can be detected and mitigated early in the deployment process. Med det här alternativet kan du använda regressionen av uppdateringen om det behövs för första gången sker i en liten grupp inom Microsoft (den inre ringen) innan den distribueras till större grupper, t. ex. alla 140 000 Microsoft-anställda globalt (ring 2), därefter till grupper med tidiga användare (grupp 3) och i slutändan till alla kunder globalt (ring 4).This allows for regression of the update if needed and first occurs in a small group inside Microsoft (inner ring) before it is deployed to larger groups like all 140,000 Microsoft employees (ring 2), then to early adopter rings (ring 3) and ultimately to all customers globally (ring 4).
  • genomför förbättringar av övervakning via automatisering.driving improvements in monitoring through automation. Microsoft 365 är mycket stort och drifttiden för SLA-målet är hög.Microsoft 365 is very large, and the SLA target uptime is high. I början av en tjänstehändelse skulle det inte gå att svara tillräckligt snabbt för att uppfylla tjänstenivåavtalet om människor var inblandande.At the very beginning of a service incident, if humans had to be involved in detection and response, we couldn't respond fast enough to meet SLAs. Automation är nyckeln till att snabbt och effektivt upptäcka identifiering och svar för tjänstproblem.Automation is the key to fast and effective service incident detection and response. Ju tidigare vet vi om något, desto snabbare kan det åtgärdas.The sooner we know about something, the faster it can be fixed.

Tillsammans med de aktiva/aktiva funktionerna som är inbyggda i Microsoft 365-tjänstens arkitektur minskar de här åtgärderna allvarlighetsgraden, varaktigheten och antalet påverkade kunder under en tjänstehändelse.Along with the active/active capabilities built into Microsoft 365 service architecture, these efforts mitigate the severity, duration and number of impacted customers during a service incident.

FelisoleringFault isolation

I likhet med att tjänsterna är utformade och körs på ett aktivt/aktivt sätt och är partitionerade från varandra för att förhindra att fel påverkar en tjänst, utvecklas kodbasen för tjänsten med liknande partitioneringsprinciper som kallas för felisolering.Just as the services are designed and operated in an active/active fashion and are partitioned off from each other to prevent a failure in one from affecting another, the code base of the service is developed using similar partitioning principles called fault isolation. Åtgärder för felisolering är stegvisa skydd i själva kodbasen.Fault isolation measures are incremental protections made within the code base itself. De här åtgärderna bidrar till att förhindra att ett problem i ett område överförs till andra arbetsområden.These measures help prevent an issue in one area from cascading into other areas of operation. Felisoleringsåtgärder tillämpas i flera steg under utvecklingen och leveransen av en tjänst, inklusive kodutveckling, tjänstdistribution, belastningsutjämning och databasreplikering.Fault isolation measures are applied at multiple stages of the development and delivery of a service, including code development, service deployment, load balancing and database replication.

Microsoft Security Development Lifecycle (SDL) främjar också återhämtning och består av en uppsättning metoder som stöder säkerhets- och efterlevnadskrav.The Microsoft Security Development Lifecycle (SDL) further promotes resiliency and consists of a set of practices that support security and compliance requirements. SDL vägleder våra utvecklare när de skapar elastiska, säkra, kompatibla tjänster.SDL guides our developers in building resilient, secure, compliant services. Viktiga element i SDL är kodgranskningar, hotmodellering, intrångstestning och standardiserade svarsprocesser för incidenter i Microsoft Cloud.Key elements of SDL include code reviews, threat modeling, penetration testing, and standardized incident response processes across the Microsoft cloud.

M365-tjänsterna är mycket sammankopplade, men systemen och tekniken som ligger bakom dem är utformade på ett sätt som begränsar konsekvenserna om en tjänstehändelse går över till andra tjänster.M365 services are highly interconnected, but the systems and technology behind them are engineered in a way that limits the impact of one service incident from spilling over to other services. Exempelvis påverkar inte ett problem som påverkar Exchange Online inte huvudfunktionerna i Teams, och ett problem med sökfunktionen i SharePoint Online påverkar inte användarens möjlighet att ladda upp eller ladda ned filer.For example, an issue affecting Exchange Online will not impact core functionality in Teams, or an issue with search functionality in SharePoint Online won’t affect users’ ability to upload or download files.

Löpande tjänstförbättringarContinuous service improvement

Vi tar en incident på allvar.When we experience an incident, we take it seriously. Med vår redundanta molnarkitektur och rigorösa interna processer kan våra tjänster vara lättillgängliga.After all, our redundant cloud architecture and rigorous internal processes aim to keep our services accessible. Under en incident identifierar vår övervakning snabbt de berörda tjänsterna och om din klientorganisation påverkas kommer du att bli informerad omedelbart via en mängd olika kanaler.During an incident, our monitoring rapidly detects the affected services and, if your tenant is affected, you'll be notified immediately through a variety of channels. Samtidigt följer teknikerna väldefinierade processer för att prioritera problemet och vidta nödvändiga åtgärder för att återställa normala åtgärder så snabbt som möjligt.Simultaneously, engineers follow well-defined processes to triage the issue and take the necessary steps to restore normal operation as quickly as possible. När tjänsten fungerar som vanligt igen gör vi granskningar efteråt som en del av vår löpande tjänstförbättring.Once the service is functioning normally again, we hold post incident reviews as part of the cycle of continuous service improvement. Under granskningen efter händelsen identifierar vi orsaken till incidenten och vad som krävdes för att åtgärda problemen.During the post incident review, we identify the root causes of the incident and what was required to fix the issues. Vi tar sedan det vi har lärt oss av situationen och tillämpar det på designen och driften i alla våra erbjudanden.Then we take what was learned from the situation and apply it to the design and operations of all of our suite of offerings. Genom att göra det kan vi förhindra att samma rotorsak påverkar andra tjänster och fler kunder.By doing this, we can prevent the same root cause from impacting other services and additional customers.