Power BI modell for pålitelighetsteknikk for nettsted (SRE)

Dette dokumentet beskriver Power BI teamets tilnærming til å opprettholde en pålitelig, ytende og skalerbar tjeneste for kunder. Den beskriver overvåking av tjenestetilstanden, begrensning av hendelser, utgivelsesadministrasjon og behandling av nødvendige forbedringer. Andre viktige operasjonelle aspekter, for eksempel sikkerhet, er utenfor omfanget til dette dokumentet. Dette dokumentet ble opprettet for å dele kunnskap med kundene våre, som ofte stiller spørsmål om fremgangsmåter for å lage pålitelighet for nettstedet. Hensikten er å tilby gjennomsiktighet i hvordan Power BI minimerer tjenesteavbrudd gjennom sikker distribusjon, kontinuerlig overvåking og rask hendelsesrespons. Teknikkene som beskrives her, inneholder også en plantegning for team som drifter tjenestebaserte løsninger for å bygge grunnleggende prosesser for direktesendte områder som er effektive og effektive i stor skala.

Forfatter: Yitzhak Kesselman

Bakgrunn

Power BI er et opprinnelig skytilbud og en global tjeneste som støtter følgende kunder og muligheter:

  • Betjene 260 000 organisasjoner og 97 % av Fortune 500-selskaper
  • Distribuert i 52 Azure-områder over hele verden
  • Utfører nesten 20 000 000 spørringer per time på det høyeste
  • Tar inn over 90 petabyte med data per måned inn i kundedatasett
  • Bruker 149 klynger drevet av mer enn 350 000 kjerner

Til tross for at den har tatt i bruk seks rette år med tresifret vekst og betydelige nye egenskaper, har Power BI høy tjenestepålitelighet og driftsdyktighet. Etter hvert som tjenesten vokste og store virksomheter distribuerte den i stor skala til hundrevis av tusenvis av brukere, ble behovet for eksepsjonell pålitelighet avgjørende. Pålitelighetsresultatene som vises i tabellen nedenfor, er den direkte konsekvensen av utvikling, verktøy og kulturendringer som er gjort av Power BI teamet de siste par årene, og er uthevet i denne artikkelen.

Tabell som beskriver statistikk over nettstedspålitelighet.

Gjennom løsninger og disiplinerte operasjoner har Power BI-teamet vedvarende eksponentiell vekst og raske oppdateringssykluser uten å øke den totale kostnaden eller belastningen på direkte nettstedsadministrasjon. I den følgende grafen kan du se den kontinuerlige og betydelige nedgangen i service Reliability Engineering Cost per månedlig aktiv bruker (MAU).

Graph som viser en reduksjon i pålitelighetskostnader for nettstedet, til tross for rask vekst.

Effektene som vi fikk fra teamet for å bygge opp pålitelighet for områder (SRE), forskjøvet kostnaden av å finansiere et slikt team. Størrelsen på SRE-teamet, og de tilsvarende driftskostnadene, har forblitt konstant til tross for eksponentiell tjenestevekst i samme periode. Uten slike dedikerte fokus på effektivitet ville støttekostnadene til live-nettstedet ha økt betydelig med økt tjenestebruk.

Videre kan en økende prosentandel Power BI direkte nettstedshendelser nå adresseres delvis eller fullstendig gjennom automatisering. Diagrammet nedenfor viser en 90 % reduksjon i Time to Mitigate (TTM)-hendelser i løpet av de siste to årene, mens bruk har mer enn tredoblet. I samme periode fikk vi innføringen av varslingsautomatisering for å avvikles mer enn 82 % av hendelsene.

Diagram som viser redusert responstid til tross for økning i bruk.

Disse innsatsene har resultert i betraktelig forbedret servicepålitelighet for kunder, som nærmer seg fire niere (99,99 %) suksessrate.

Resten av denne artikkelen beskriver fremgangsmåten og anbefalte fremgangsmåter som er satt på plass som aktiverte SRE-teamet for å oppnå det forrige diagrammets resultater. De følgende delene inneholder detaljer om hendelsestyper for direktesendte områder, standard undersøkelsesprosesser, anbefalte fremgangsmåter for drift av disse prosessene i stor skala, og Målnøkkelresultater (OKR-er) som brukes av teamet til å måle suksess.

Hvorfor hendelser oppstår og hvordan du lever med dem

Produktteamet Power BI ukentlige funksjonsoppdateringer til tjenesten og målrettede løsninger for å løse problemer med tjenestekvalitet. Lanseringsprosessen inkluderer et omfattende sett med kvalitetsporter, inkludert omfattende kodegjennomgang, ad hoc-testing, automatiserte komponentbaserte og scenariobaserte tester, funksjonsreise og områdesikker distribusjon. Men selv med disse sikringstiltakene kan direktesendte nettstedshendelser skje.

Hendelser på direktesendt nettsted kan deles inn i flere kategorier:

  • Avhengige tjenesteproblemer (for eksempel Azure AD, Azure SQL, Storage, virtual machine scale set, Service Fabric)
  • Infrastrukturbrudd (for eksempel en maskinvarefeil, mislykket datasenter)
  • Power BI miljøkonfigurasjonsproblemer (for eksempel utilstrekkelig kapasitet)
  • Power BI regresjoner av tjenestekode
  • Feilkonfigurert kunde (for eksempel utilstrekkelige ressurser, ugyldige spørringer/rapporter)

Å redusere hendelsesvolumet er en måte å redusere belastningen på aktive områder på og forbedre kundetilfredsheten. Det er imidlertid ikke alltid mulig å gjøre dette, gitt at noen av hendelseskategoriene er utenfor teamets direktekontroll. I tillegg, idet tjenestefotavtrykket utvides for å støtte rask vekst i bruk, øker sannsynligheten for en hendelse på grunn av eksterne faktorer. Høye hendelsesantall kan forekomme selv i tilfeller der Power BI-tjenesten har minimale regresjoner for tjenestekoder, og de har overskredet tjenestenivåmålet (SLO) for den totale påliteligheten på 99,95 %, noe som har ført til at Power BI-teamet bruker betydelige ressurser til å redusere hendelseskostnadene til et nivå som er bærekraftig, med både økonomiske og tekniske mål.

Hendelseprosess for direktesendt nettsted

Når du undersøker direktesendte områdehendelser, følger Power BI teamet en standard driftsprosess som er vanlig på tvers av Microsoft og bransjen. Det følgende bildet oppsummerer livssyklusen til standard hendelseshåndtering for direktesendte områder.

Visualobjekt som viser livssyklusen til hendelsesprosessen på direktesendt nettsted.

I den første fasen, som er fasen for tjenesteovervåking, samarbeider SRE-teamet med ingeniører, programledere og topplederteamet for å definere indikatorer på servicenivå (SLI-er) og mål for tjenestenivå (SLOer) for både store scenarioer og mindre scenarioer. Disse målene gjelder for ulike måledata for tjenesten, inkludert pålitelighet for scenario/komponent, scenario/komponentytelse (ventetid) og ressursforbruk. Den direktesendte områdegruppen og produktteamet utformer deretter varsler som overvåker indikatorer på tjenestenivå (SLI-er) mot målene som er avtalt. Når det oppdages brudd, utløses et varsel for undersøkelse.

I den andre fasen, som er hendelsesresponsfasen, er prosessene strukturert for å forenkle følgende resultater:

  • Spør og målrettet varsling til kunder om alle relevante konsekvenser
  • Analyse av berørte tjenestekomponenter og arbeidsflyter
  • Målrettet begrensning av hendelsespåvirkning

I den siste fasen, som er den kontinuerlige forbedringsfasen, fokuserer teamet på fullføring av relevant postmortem-analyse og løsning for identifiserte prosesser, overvåking eller konfigurasjon eller koderettinger. Rettingene prioriteres deretter mot teamets generelle tekniske backlog, basert på total alvorlighetsgrad og risiko for gjentakelse.

Våre praksiser for tjenesteovervåking

Brukerteamet Power BI en konsekvent, datadrevet og kundeorientert tilnærming til driften av det direktesendte nettstedet. Å definere indikatorer (SLI-er) for tjenestenivå (SLI-er) og implementere tilsvarende overvåkingsvarsler for direktesendte områder er en del av godkjenningskriteriene for aktivering av nye Power BI-funksjonen i produksjon. Ingeniører for produktgrupper inkluderer også trinn for undersøkelse og begrensning av varsler når de oppstår ved hjelp av en mal for feilsøkingsveiledning (TSG). Disse leveransene presenteres deretter i teamet for site Reliability Engineering (SRE).

En måte teamet for Power BI muliggjør eksponentiell tjenestevekst på, er ved å bruke et SRE-team. Disse personene er kompetente med tjenestearkitektur, automasjons- og hendelseshåndteringspraksis og er innebygd i hendelser for å drive ende-til-ende-oppløsning. Tilnærmingen står i kontrast til den rotasjonsmodellen der ingeniørledere fra produktgruppen tar på seg en hendelsesbehandlingsrolle for bare noen få uker per år. SRE-teamet sikrer at en konsekvent gruppe enkeltpersoner er ansvarlige for å føre forbedringer av nettstedet direkte og sikre at læring fra tidligere hendelser inkorporeres i fremtidige eskaleringer. SRE-teamet hjelper også med drilling i stor skala som tester forretningskontinuitet og nødgjenoppretting av tjenesten.

Medlemmer av SRE-teamet bruker sine unike ferdigheter og omfattende erfaring på direktesendt område, og samarbeider også med funksjonsteam for å forbedre sløyfer og varsler fra produktteamet på mange måter. Noen av måtene de forbedrer ytelse på, er blant annet:

  • Avviksvarsler: SRE-er utvikler skjermer som vurderer typiske bruks- og operasjonsmønstre i et gitt produksjonsmiljø, og varsler når det oppstår betydelige avvik. Eksempel: Ventetiden for datasettoppdatering øker med 50 % i forhold til lignende bruksperioder.
  • Kunde-/miljøspesifikke varsler: SRE-er utvikler skjermer som oppdager når bestemte kunder, klargjorte kapasiteter eller distribuerte klynger avviker fra forventet virkemåte. Eksempel: Én enkelt kapasitet som eies av en kunde, kan ikke laste inn datasett for spørring.
  • Finkornete varsler: SREs vurderer delsett av populasjonen som kan oppleve problemer uavhengig av den bredere populasjonen. I slike tilfeller er spesifikke varsler utformet for å sikre at varsler faktisk vil fyre hvis disse mindre vanlige scenarioene mislykkes til tross for lavere volum. Eksempel: Oppdatering av datasett som bruker GitHub koblingen mislykkes.
  • Oppfattede pålitelighetsvarsler: SREs lager også varsler som oppdager tilfeller der kundene mislykkes på grunn av feil. Dette kan inkludere feil fra brukerfeil og indikere behov for forbedret dokumentasjon eller en modifisert brukeropplevelse. Disse varslene kan også varsle teknikere om uventede systemfeil som ellers kan være feilklassifisert som en brukerfeil. Eksempel: Oppdatering av datasett mislykkes på grunn av feil legitimasjon.

En annen kritisk rolle i SRE-teamet er å automatisere TSG-handlinger i den grad det er mulig Azure Automation. I tilfeller der fullstendig automatisering ikke er mulig, definerer SRE-teamet handlinger for å berike et varsel med nyttig og hendelsesspesifikk diagnoseinformasjon for å fremskynde etterfølgende undersøkelser. Slik berikelse er sammenkoblet med forhåndsskriptende veiledning i en tilsvarende TSG, slik at ingeniører på live-nettstedet enten kan foreta en spesifikk handling for å redusere hendelsen eller raskt eskalere til smbler for å få mer undersøkelse. Varsler med berikelse er også kandidater for fullstendig automatisering når det er mulig, og når hendelsesvolum/alvorlighetsgrad gir en tilstrekkelig høy ROI.

Som et direkte resultat av disse tiltakene reduseres mer enn 82 % av hendelsene uten menneskelig samhandling. De gjenværende hendelsene har nok berikelsesdata og støttedokumentasjon til å kunne håndteres uten SME-involvering i 99,7 % av tilfellene.

Diagram som viser automatisering av hendelser og nedfelling.

SRE-er for direkte nettsted håndhever også varselkvalitet på flere måter, inkludert følgende:

  • Dette sikrer at TSG-er inkluderer konsekvensanalyse og opptrappingspolicy
  • Å sikre at varsler kjøres for det absolutt minste tidsvinduet mulig for raskere gjenkjenning
  • Å sikre at varsler bruker pålitelighetsterskler i stedet for absolutte grenser for å skalere klynger med ulik størrelse

Våre praksiser for hendelsesrespons

Når en automatisert hendelse på et direkte nettsted opprettes for Power BI tjeneste, er en av de første prioriteringene å varsle kunder om potensiell innvirkning. Azure har et målvarsel på 15 minutter, som er vanskelig å oppnå når varsler er manuelt lagt inn av hendelsesledere etter at de har blitt med i et anrop. Kommunikasjon i slike tilfeller står i fare for å bli forsinket eller unøyaktig på grunn av påkrevd manuell analyse. Azure-overvåkning tilbyr sentralisert overvåkning og varsler løsninger som kan oppdage innvirkning på bestemte målinger i dette tids vinduet. Power BI er imidlertid et SaaS-tilbud med komplekse scenarier og bruker samhandlinger som enkelt kan modelleres og spores ved hjelp av slike varslings systemer. i svaret utviklete Power BI-teamet en novel-løsning kalt TTN0.

  • TTN0 (tid for å varsle "0") er en fullstendig automatisert hendelses varslings tjeneste som bruker vår interne varslings infrastruktur til å identifisere bestemte scenarioer og kunder som påvirkes av en nylig opprettet hendelse. Det er også integrert med eksterne overvåkings agenter utenfor Azure for å oppdage tilkoblings problemer som ellers kan være avmerket. TTN0 gjør det mulig for kunder å motta en e-post når TTN0 oppdager et tjeneste avbrudd eller en reduksjon. med TTN0 kan Power BI-teamet sende pålitelige, målrettede varslinger innen 10 minutter på innflytelseens start tidspunkt (som er 33% raskere enn Azure-målet). Siden løsningen er fullstendig automatisert, er det minimal risiko for menneskelig feil eller forsinkelser. Fra og med 2021, har mer enn 8 000 selskaper registrert for TTN0-varsler.

som nevnt i den forrige delen, kan Power BI s web område filosofi fremheve automatisert oppløsning av hendelser for å forbedre den generelle skalerbar heten og bærekraftighet i SRE-teamet. Vekting av automat ion gjør det mulig å begrense ved skalering og kan potensielt unngå kostbare tilbake føringer eller risikabele hurtig reparasjoner på produksjons systemer. når manuell undersøkelse kreves, får Power BI en lagdelt tilnærming med innledende undersøkelser gjort av et dedikert SRE-team. SRE gruppe medlemmer er i ferd med å administrere aktive område hendelser, forenkle kommunikasjon på tvers av team og begrense. I tilfeller der det ansvarlige SRE-teamet krever mer kontekst i et berørt scenario/en komponent, kan de engasjere seg i emne eksperten (SME) i området for veiledning. Til slutt utfører SME-teamet simuleringer av system komponent feil for å forstå og redusere problemer på forhånd i en aktiv Live site-hendelse.

når den berørte komponenten/scenarioet for tjenesten fastsettes, har Power BI teamet flere teknikker for rask reduksjon av innvirkning. Noen av dem er følgende:

  • aktiver infrastruktur for side-ved-side distribusjon: Power BI støtter å kjøre ulike versjoner av versjons belastninger i samme klynge, slik at teamet kan kjøre en ny (eller tidligere) versjon av en bestemt arbeids belastning for visse kunder uten å utløse en fullstendig distribusjon (eller tilbakerulling). Tilnærmingen kan redusere reduksjons tiden til 15 minutter og redusere den totale risikoen for distribusjon.
  • Kjør forretnings kontinuitet/nød gjenopprettings prosess (BCDR): Gir teamet mulighet til å failoverere primær arbeids belastninger til dette alternative miljøet i tre minutter hvis det finnes et alvorlig problem i en ny tjeneste versjon. BCDR kan også brukes når miljø faktorer eller avhengige tjenester hindrer den primære klyngen/området i å drifte.
  • utnytter robustheten til avhengige tjenester: Power BI proaktivt evaluerer og investerer om robusthet og redundans-tiltak for alle avhengige tjenester (for eksempel SQL, Redis Cache Key Vault). Robusthet omfatter tilstrekkelig komponent overvåking for å oppdage overgangs-/strøms-og sonebasertee og regionale redundans (der det gjelder). Ved å investere i disse funksjonene sikrer du at det finnes verktøy for automatisk eller manuell utløsing av gjenopprettings operasjoner for å redusere innvirkninger fra en berørt avhengighet.

Våre praksiser for kontinuerlig forbedring

Power BI teamet gjennomgår alle kunder som har innvirkning på hendelser i løpet av en ukentlig tjeneste gjennomgang med representasjon fra alle teknikk grupper som bidrar til Power BI-tjenesten. Vurderingen sprer nøkkelen fra hendelsen til ledere på tvers av organisasjonen, og gir en mulighet til å tilpasse disse prosessene for å lukke tomrom og løse ineffektivhet.

Før du går gjennom, forbereder SRE-teamet å klargjøre-mortem-innhold og identifiserer foreløpig reparasjons elementer for team-og produkt utviklings teamet for Live site. Elementer kan inneholde kode korrigeringer, utvidete telemetri eller oppdaterte varsler/TSGs. Power BI SREs er kjent med mange av disse områdene, og gjør ofte justeringer i sanntid samtidig som de svarer på en aktiv hendelse. Dette bidrar til å sikre at endringer er innlemmet i systemet i tide for å oppdage reforekomst av et lignende problem. I tilfeller der en hendelse var et resultat av en kunde eskalering, justerer SRE-teamet eksisterende automatiserte varslinger og SLIs for å gjenspeile kundenes forventninger. for de ~ 0,3% av hendelsene som krever eskalering til en SME (SRE) i henhold til det berørte scenarioet/komponenten, gjennomgås de ulike metodene i utPower BIet med den samme hendelsen (eller lignende hendelser) uten å måtte eskalere i fremtiden. Den detaljerte analysen av SRE-teamet hjelper produkt utviklings teamet med å utvikle et mer fleksibelt, skalerbart og støtte baslig produkt.

Etter gjennomgang av bestemte postmortems genererer SRE-teamet også rapporter om aggregerte hendelses data for å identifisere muligheter for tjeneste forbedring, for eksempel fremtidig automatisering av hendelser eller produkt løsninger. Rapporteringen kombinerer data fra flere kilder, inkludert kunde støtte teamet, automatisert varsling og tjeneste-telemetri. Den konsoliderte visningen gir innsyn i disse problemene, som er mest negativ når det gjelder tjeneste og Team tilstand, og SRE-teamet så prioriterer potensielle forbedringer basert på total ROI. Hvis for eksempel et bestemt varsel utløses for ofte eller ved å generere uproporsjonalt innvirkning på tjeneste pålitelighet, kan SRE-teamet samarbeide med produkt utviklings teamet for å investere i relevante kvalitets forbedringer. Full fører disse jobb elementene for å forbedre tjeneste og direktesendte område målinger og direkte bidra til nøkkel resultater for organisasjons mål (OKRs). I tilfeller der en SLI er konsekvent oppbrukt i en lang periode, kan SRE-teamet foreslå økninger i tjeneste tjeneste nivå avtale for å gi en forbedret opplevelse for kundene våre.

Å måle vellykkede nøkkel resultater (OKRs)

Power BI teamet har et omfattende sett med mål resultater (OKRs) som brukes til å sikre den totale tjeneste tilstanden, kunde tilfredsheten og lykke. OKRs kan deles inn i to kategorier:

  • Service Health OKRs: Disse OKRsene direkte eller indirekte måler tilstanden til scenarioer eller komponenter i tjenesten og spores ofte av overvåking/varsling. Eksempel: en enkelt kapasitet som eies av en kunde, kan ikke laste inn data sett for spørring.
  • Helse OKRs for direkte område: Disse OKRsene er direkte eller indirekte til å måle hvor effektivt og effektivt operasjoner for direkte område adresserer tjeneste hendelser og-alder som beskrives i tidligere inndelinger. Eksempel: tid for å varsle (TTN) kunder om en innflytelses hendelse.

Tabellen nedenfor viser OKRs for overordnet område tilstand.

Tabell som beskriver viktige nøkkel resultater for tilstands mål for aktivt område.

tiden det tar for Power BI teamet å reagere på hendelser som målt av TTN, TTA og TTM, overgår betydelig mål. Varsel automatisering Sams varer direkte med teamets mulighet til å opprettholde eksponentiell tjeneste vekst, samtidig som de fortsetter å oppfylle eller overholde mål respons tider for hendelses varsling, varsling og reduksjon. i løpet av en periode på to år, ble Power BI SRE-teamet lagt til automatisering i deflect over 82% av hendelser og til å berike en ekstra seks prosent del med detaljer som gir teknikere muligheten til å begrense hendelser raskt når de oppstår. Fremgangs måten gir også SMEs mulighet til å fokusere på funksjoner og forbedringer i proaktiv kvalitet i stedet for gjentatte hendelses undersøkelser.

ovennevnte OKRs spores aktivt av Power BI live site-teamet, og det overordnede teamet, for å sikre at teamet fortsetter å møte eller overholde den nødvendige grunn linjen som kreves for å støtte betydelige tjeneste vekst, for å opprettholde en bærekraftig live site-arbeidsbelastning, og for å sikre høy kunde tilfredshet.

Lanserings administrasjon og distribusjons prosess

Power BI utgir ukentlige funksjons oppdateringer for tjenesten og behovsbetingede rettinger for å løse problemer med tjeneste kvalitet. Tilnærmingen er ment for balanse hastighet og sikkerhet. alle kode endringer i Power BI passerer gjennom ulike valide rings faser før de distribueres til eksterne kunder, som beskrevet i følgende diagram.

Diagram som viser frigivelses administrasjon og distribusjons prosess.

hver endring i Power BI kode basis passerer gjennom automatiserte komponenter og ende-til-ende-tester som validerer vanlige scenarioer og sikrer at samhandlingen gir forventede resultater. i tillegg bruker Power BI et data samle bånd for kontinuerlig integrering/kontinuerlig distribusjon (CI/CD) for hovedutviklings grener for å oppdage andre problemer som er kostnads fritt til å identifiseres i henhold til endringer. CI/CD-prosessen utløser et fullstendig klynge Bygg ut og ulike syntetiske tester som må passere før en endring kan angi neste fase i Utgivelses prosessen. Godkjente CI/CD-Bygg distribueres til interne test miljøer for mer automatisert og manuell Valide ring før de blir inkludert i hver ukentlige funksjons oppdatering. Prosessen betyr at en endring vil bygges inn i en kandidat versjon innen 1 til 7 dager etter at den er fullført av utvikle ren.

den ukentlige funksjons oppdateringen går deretter gjennom forskjellige offisielle distribusjons ringer til Power BIens sikre distribusjons prosess. den oppdaterte produkt builden brukes først på en intern klynge som er vert for innholdet i Power BI teamet, etterfulgt av den interne klyngen som brukes av alle ansatte i Microsoft. Endringene ventes i hvert av disse miljøene for én uke før du flytter til det siste trinnet: produksjons distribusjon. Her vil distribusjons teamet bruke en gradvis utrullings prosess som selektivt tar i bruk den nye builden etter område for å tillate Valide ring i enkelte områder før omfattende program.

Skalering av denne distribusjons modellen for å håndtere eksponentiell tjeneste vekst utføres på flere måter, som følgende punkter beskriver:

  • omfattende gjennomgang av avhengigheter: Power BI er en komplisert tjeneste med mange motspiller-og maskin vare kapasitets krav. Distribusjons teamet sikrer tilgjengelighet og nødvendig kapasitet for alle avhengige ressurser og tjenester i et mål distribusjons område. Bruks modeller prosjekt kapasitets behov basert på forventede kunde behov.

  • automat ion: Power BI distribusjoner er egentlig null berøring med lite til ingen interaksjon som kreves av distribusjons teamet. Det finnes forhåndsbygde berullings spesifikasjoner for flere distribusjons scenarioer. Distribusjons konfigurasjonen er validert ved Build-time for å unngå uventede feil under innrullering av direkte distribusjon.

  • klynge tilstands kontroller: Power BI deployment infrastructure kontrollerer interne tjeneste tilstands modeller før, i løpet av og etter at en oppgradering har mulighet til å identifisere uventede virke måter og potensielle regresjoner. Når det er mulig, prøver distribusjons verktøy automatisk å løse problemer som oppstår.

  • Svar prosess for hendelse: Distribusjons problemer behandles som andre direktesendte område hendelser ved hjelp av teknikker som beskrives i flere detaljer i følgende deler av denne artikkelen. Ingeniører analyserer problemer med fokus på umiddelbar reduksjon og følger deretter opp med relevante manuelle eller automatiserte prosess endringer for å forhindre fremtidig reaktivering.

  • funksjons styring/eksponerings kontroll: Power BI bruker et omfattende rammeverk for å vise nye funksjoner til kunder. Funksjons eksponering er uavhengig av distribusjons cadences og tillater at kode for ny scenario kode distribueres i en deaktivert tilstand til den har sendt alle relevante kvalitets linjer. i tillegg kan nye funksjoner vises for et delsett av den totale Power BI populasjonen som et ekstra valide rings trinn før globalt aktivering. hvis et problem oppdages, gir Power BI funksjons administrasjons tjenesten muligheten til å deaktivere en feil funksjon på sekunder uten å vente på mer tid krevende operasjoner for distribusjon tilbake føring.

disse funksjonene har aktivert Power BI teamet for å forbedre suksess raten til distribusjoner med 18 poeng, samtidig som de absorberer en 400% år – over års vekst i månedlige distribusjoner.

Neste trinn

Et annet element med høy prioritet på SRE-vei kartet er reduksjonen av system støy fra falske positive varsler eller ignorable varsler. I tillegg vil teamet gi deg midlertidige varsler, drive RCAS og avgjøre om det er underliggende system problemer som må løses.

til slutt sikrer et grunnleggende element av Power BI tjeneste robusthet at tjenesten er compartmentalized, slik at hendelsene bare påvirker et delsett av brukerne. Dette gjør det mulig å begrense ved å omadressere påvirket trafikk til en OK-klynge. Støtte for denne Visualiser krever betydelige arkitektur arbeid og design endringer, men bør gi enda høyere tjeneste nivå avtaler enn det som oppnås i dag.

Neste trinn

hvis du vil ha mer informasjon og ressurser i Power BI-tjenesten, kan du ta en titt på følgende artikler.