Rekommendationer för att utforma och skapa ett övervakningssystem

Gäller för den här rekommendationen om checklista för driftseffektivitet i Azure Well-Architected Framework:

OE:07	Utforma och implementera ett övervakningssystem för att validera designval och informera om framtida design- och affärsbeslut. Det här systemet samlar in och exponerar drifttelemetri, mått och loggar som genererar från arbetsbelastningens infrastruktur och kod.

Relaterad guide: Rekommendationer för instrumentering av ett program

Den här guiden beskriver rekommendationerna för att utforma och skapa ett övervakningssystem. För att effektivt övervaka din arbetsbelastning för säkerhet, prestanda och tillförlitlighet behöver du ett omfattande system med en egen stack som utgör grunden för alla övervaknings-, identifierings- och aviseringsfunktioner.

Definitioner

Period	Definition
Loggar	Registrerade systemhändelser. Loggar kan innehålla olika typer av data i ett strukturerat eller fritt textformat. De innehåller en tidsstämpel.
Mått	Numeriska värden som samlas in med jämna mellanrum. Mått beskriver vissa aspekter av ett system vid en viss tidpunkt.

Viktiga designstrategier

Om du vill implementera en omfattande övervakningssystemdesign för din arbetsbelastning följer du dessa grundsatser:

• När det är praktiskt kan du dra nytta av övervakningsverktyg som tillhandahålls av plattformen, vilket vanligtvis kräver mycket lite konfiguration och kan ge djupa insikter om din arbetsbelastning som annars kan vara svår att utföra.

• Samla in loggar och mått från hela arbetsbelastningsstacken. Alla infrastrukturresurser och programfunktioner ska konfigureras för att producera standardiserade, meningsfulla data och dessa data måste samlas in.

• Lagra insamlade data i en standardiserad, tillförlitlig och säker lagringslösning.

• Bearbeta lagrade data så att de kan hanteras av analys- och visualiseringslösningar.

• Analysera bearbetade data för att korrekt fastställa arbetsbelastningens tillstånd.

• Visualisera arbetsbelastningens tillstånd i meningsfulla instrumentpaneler eller rapporter för arbetsbelastningsteam och andra intressenter.

• Konfigurera åtgärdsbara aviseringar och andra automatiska svar på intelligent definierade tröskelvärden för att meddela arbetsbelastningsteam när problem uppstår.

• Inkludera övervaknings- och aviseringssystem i dina övergripande arbetsbelastningstestningsmetoder.

• Se till att övervaknings- och aviseringssystem omfattas av kontinuerliga förbättringar. Program- och infrastrukturbeteende i produktion ger kontinuerliga inlärningsmöjligheter. Införliva dessa lektioner i övervaknings- och aviseringsdesign.

• Koppla de övervakningsdata som du samlar in och analyserar tillbaka till systemet och användarflödena för att korrelera hälsotillståndet för flödena med data utöver den övergripande hälsan för arbetsbelastningen. Genom att analysera dessa data i termer av flödena kan du anpassa din strategi för observerbarhet till din hälsomodell.

Du bör automatisera alla funktioner i övervakningssystemet så mycket som möjligt, och alla bör köras kontinuerligt, hela dagen, varje dag.

Den här arbetsflödespipelinen illustrerar övervakningssystemet:

Samling

Anteckning

Du måste instrumentera programmet för att aktivera loggning. Mer information finns i instrumentationsguiden.

Du bör konfigurera alla arbetsbelastningskomponenter, oavsett om de är infrastrukturresurser eller programfunktioner, för att samla in telemetri och/eller händelser som loggar och mått.

Loggar är främst användbara för att identifiera och undersöka avvikelser. Vanligtvis skapas loggar av arbetsbelastningskomponenten och skickas sedan till övervakningsplattformen eller hämtas av övervakningsplattformen via automatisering.

Mått är främst användbara för att skapa en hälsomodell och identifiera trender i arbetsbelastningens prestanda och tillförlitlighet. Mått är också användbara för att identifiera trender i dina kunders användningsbeteende. Dessa trender kan hjälpa dig att fatta beslut om förbättringar ur kundens perspektiv. Vanligtvis definieras mått i övervakningsplattformen och övervakningsplattformen och andra verktyg avsöker arbetsbelastningen för att samla in mått.

Programdata

För program kan insamlingstjänsten vara ett APM-verktyg (Application Performance Management) som kan köras självständigt från det program som genererar instrumentationsdata. När APM har aktiverats har du tydlig insyn i viktiga mått, i realtid och historiskt. Använd en lämplig loggningsnivå. Utförlig loggning kan medföra betydande kostnader. Ange loggnivåer enligt miljön. Lägre miljöer behöver till exempel inte samma detaljnivå som produktion.

Programloggar stöder programlivscykeln från slutpunkt till slutpunkt. Loggning är viktigt för att förstå hur programmet fungerar i olika miljöer, vilka händelser som inträffar och under vilka förhållanden de inträffar.

Vi rekommenderar att du samlar in programloggar och händelser i alla större miljöer. Avgränsa data mellan miljöer så mycket som möjligt genom att använda olika datalager för varje miljö, om det är praktiskt. Använd filter för att säkerställa att icke-kritiska miljöer inte komplicerar tolkningen av produktionsloggar. Slutligen bör motsvarande loggposter i programmet avbilda ett korrelations-ID för deras respektive transaktioner.

Du bör samla in programhändelser i strukturerade datatyper med maskinläsbara datapunkter i stället för ostrukturerade strängtyper. Ett strukturerat format som använder ett välkänt schema kan göra det enklare att parsa och analysera loggar. Dessutom kan strukturerade data enkelt indexeras och genomsökas, och rapporteringen kan förenklas avsevärt.

Data ska vara i ett oberoende format som är oberoende av datorn, operativsystemet eller nätverksprotokollet. Generera till exempel information i ett självbeskrivande format som JSON, MessagePack eller Protobuf i stället för ETL/ETW. Med ett standardformat kan systemet konstruera bearbetningspipelines. Komponenter som läser, transformerar och skickar data i standardformatet kan enkelt integreras.

Infrastrukturdata

Se till att samla in både loggar och mått för infrastrukturresurser i din arbetsbelastning. För IaaS-system (infrastruktur som en tjänst) avbildar du operativsystem, programlager och diagnostikloggar utöver mått som rör arbetsbelastningshälsa. För PaaS-resurser (plattform som en tjänst) kan du vara begränsad i din möjlighet att samla in loggar som är relaterade till den underliggande infrastrukturen, men se till att du kan samla in diagnostikloggar utöver mått relaterade till arbetsbelastningens hälsa.

Samla in loggar från din molnplattform så mycket som möjligt. Du kanske kan samla in aktivitetsloggar för din prenumeration och diagnostikloggar för hanteringsplanet.

Insamlingsstrategier

Undvik att hämta telemetridata manuellt från varje komponent. Flytta data till en central plats och konsolidera dem där. För en lösning för flera regioner rekommenderar vi att du först samlar in, konsoliderar och lagrar data region för region och sedan aggregerar regionala data i ett enda centralt system.

Kompromiss: Tänk på att det finns kostnadskonsekvenser med att ha regionala och centraliserade datalager.

För att optimera användningen av bandbredd prioriterar du baserat på vikten av data. Du kan överföra mindre brådskande data i batchar. Dessa data får dock inte fördröjas på obestämd tid, särskilt om de innehåller tidskänslig information.

Det finns två primära modeller som samlingstjänsten kan använda för att samla in instrumentationsdata:

• Pull-modell: Hämtar aktivt data från de olika loggarna och andra källor för varje instans av programmet.

• Push-modell: Väntar passivt på att data ska skickas från de komponenter som utgör varje instans av programmet.

Övervaka agenter

Du kan använda övervakningsagenter i pull-modellen. Agenter körs lokalt i en separat process med varje instans av programmet, hämtar regelbundet data och skriver informationen direkt till gemensam lagring som delas av alla instanser av programmet.

Anteckning

Användning av en övervakningsagent är helt anpassat för att läsa in instrumentationsdata som hämtas naturligt från en datakälla. Det är lämpligt för ett småskaligt program som körs på ett begränsat antal noder på en enda plats. Exempel är information från SQL Server dynamiska hanteringsvyer eller längden på en Azure Service Bus kö.

Saker att tänka på gällande prestanda

Ett komplext och mycket skalbart program kan generera enorma mängder data. Mängden data kan enkelt överbelasta I/O-bandbredden som är tillgänglig för en enda central plats. Telemetrilösningen får inte fungera som flaskhals och måste vara skalbar när systemet expanderar. Helst bör lösningen innehålla en viss redundans för att minska risken för att viktig övervakningsinformation förloras (t.ex. gransknings- eller faktureringsdata) om en del av systemet misslyckas.

Ett sätt att buffera instrumentationsdata är att använda köer:

I den här arkitekturen publicerar datainsamlingstjänsten data till en kö. En meddelandekö är lämplig eftersom den tillhandahåller "minst en gång" semantik som säkerställer att köade data inte går förlorade när de har publicerats. Du kan implementera tjänsten för lagringsskrivning med hjälp av en separat arbetsroll. Du kan använda mönstret Prioritetskö för att implementera den här arkitekturen.

För skalbarhet kan du köra flera instanser av tjänsten för lagringsskrivning. Om en stor mängd händelser eller ett stort antal datapunkter övervakas kan du använda Azure Event Hubs för att skicka data till en annan beräkningsinstans för bearbetning och lagring.

Konsolideringsstrategier

Data som samlas in från en enda instans av ett program ger en lokaliserad vy över den instansens hälsa och prestanda. För att utvärdera systemets övergripande hälsa måste du konsolidera vissa aspekter av data från de lokala vyerna. Du kan göra det när data har lagrats, men i vissa fall kan du göra det när data samlas in.

Instrumentationsdata kan passera genom en separat datakonsolideringstjänst som kombinerar data och fungerar som en filter- och rensningsprocess. Du kan till exempel amalgamatera instrumentationsdata som innehåller samma korrelationsinformation, till exempel ett aktivitets-ID. (En användare kan starta en affärsåtgärd på en nod och sedan överföras till en annan nod om den första noden misslyckas eller på grund av hur belastningsutjämning har konfigurerats.) Den här processen kan också identifiera och ta bort duplicerade data. (Duplicering kan inträffa om telemetritjänsten använder meddelandeköer för att skicka ut instrumentationsdata till lagring.)

Storage

När du väljer en lagringslösning bör du tänka på typen av data, hur den används och hur brådskande den är.

Anteckning

Använd separata lagringslösningar för icke-produktions- och produktionsmiljöer för att säkerställa att data från varje miljö är enkla att identifiera och hantera.

Lagringstekniker

Överväg en flerspråkig beständighetsmetod, där olika typer av information lagras i tekniker som är mest lämpliga för hur varje typ sannolikt kommer att användas.

Till exempel används Azure Blob Storage och Azure Table Storage på liknande sätt. Men de åtgärder som du kan utföra på dem skiljer sig åt, liksom kornigheten för de data som de innehåller. Om du behöver utföra mer analytiska åtgärder eller kräver sökfunktioner för fullständig text på dina data kan det vara mer användbart att använda datalagring med funktioner som är optimerade för specifika typer av frågor och dataåtkomst. Exempel:

• Prestandaräknardata kan lagras i en SQL-databas för att aktivera ad hoc-analyser.

• Det kan vara bättre att lagra spårningsloggar i Azure Monitor-loggar eller Azure Data Explorer.

• Du kan lagra säkerhetsinformation i en HDFS-lösning.

Samma instrumentationsdata kan krävas för flera ändamål. Du kan till exempel använda prestandaräknare för att ge en historisk vy över systemets prestanda över tid. Genom att kombinera den här informationen med andra användningsdata kan du generera kundens faktureringsinformation. I dessa situationer kan samma data skickas till fler än ett mål, till exempel till en dokumentdatabas som kan vara ett långsiktigt lager för att lagra faktureringsinformation och till ett flerdimensionellt lager för hantering av komplexa prestandaanalyser.

Se till att aktivera funktioner för att skydda data från oavsiktlig borttagning, till exempel resurslås och mjuk borttagning.

Se också till att du skyddar åtkomsten till lagring med hjälp av rollbaserad åtkomstkontroll för att säkerställa att endast personer som behöver åtkomst till data kan göra det.

Konsolideringstjänst

Du kan implementera en annan tjänst som regelbundet hämtar data från delad lagring, partitioner och filtrerar dem efter dess syfte och sedan skriver dem till en lämplig uppsättning datalager.

En annan metod är att inkludera den här funktionen i konsoliderings- och rensningsprocessen och skriva data direkt till lagringsplatserna när de hämtas, istället för att spara dem i en mellanliggande delad lagringsplats.

Varje metod har sina för- och nackdelar. Implementeringen av en separat partitioneringstjänst minskar belastningen på konsoliderings- och rensningstjänsten och gör att åtminstone en del av de partitionerade data kan återskapas om det behövs (beroende på hur mycket data som behålls i delad lagring). Den här metoden förbrukar dock ytterligare resurser. Dessutom kan det vara en fördröjning mellan mottagandet av instrumentationsdata från varje programinstans och konverteringen av data till tillämplig information.

Frågeöverväganden

Överväg hur snabbt data krävs. Data som genererar aviseringar måste nås snabbt, så de bör lagras i snabb datalagring och indexeras eller struktureras för att optimera de frågor som aviseringssystemet utför. I vissa fall kan det vara nödvändigt för insamlingstjänsten att formatera och spara data lokalt så att en lokal instans av aviseringssystemet snabbt kan skicka meddelanden. Samma data kan skickas till tjänsten för att skriva till lager, som visas i tidigare diagram, och lagras centralt om det krävs av andra orsaker.

Överväganden för datakvarhållning

I vissa fall när data har bearbetats och överförts kan du ta bort de ursprungliga rådata som lagrades lokalt. I andra fall kan det vara nödvändigt eller användbart att spara rådata. Du kanske till exempel vill behålla data som genereras för felsökning tillgängliga i dess råa formulär, men sedan ignorera dem snabbt när eventuella buggar har lösts.

Prestandadata har ofta en längre livslängd så att du kan använda dem för att upptäcka prestandatrender och för kapacitetsplanering. Samlad vy över dessa data lagras vanligtvis online under en begränsad period för snabb åtkomst. Efteråt kan den arkiveras eller tas bort.

Det är användbart att lagra historiska data så att du kan upptäcka långvariga trender. I stället för att spara gamla data i sin helhet kanske du kan minska datamängdens upplösning och spara lagringskostnader. I stället för att till exempel spara prestandaindikatorer minut för minut kan du konsolidera data som är mer än en månad gamla för att bilda en timme för timme-vy.

Data som samlas in för mätning och fakturering av kunder kan behöva sparas på obestämd tid. Dessutom kan regelkrav kräva att information som samlas in för granskning och säkerhet måste arkiveras och sparas. Dessa data är också känsliga och kan behöva krypteras och skyddas på annat sätt för att förhindra manipulation. Du bör aldrig registrera användarlösenord eller annan information som kan användas för att begå identitetsbedrägerier. Du bör rensa informationen från data innan den lagras.

För att säkerställa att du följer lagar och förordningar minimerar du lagringen av identifierbar information. Om du behöver lagra identifierbar information måste du när du utformar din lösning ta hänsyn till krav som gör det möjligt för enskilda användare att begära att deras information tas bort.

Analys

När du har samlat in data från olika datakällor analyserar du dem för att utvärdera systemets övergripande välbefinnande. För den här analysen har du en tydlig förståelse för:

• Strukturera data baserat på KPI:er och prestandamått som du har definierat.

• Så här korrelerar du data som samlas in i olika mått och loggfiler. Den här korrelationen är viktig när du spårar en sekvens med händelser och kan hjälpa dig att diagnostisera problem.

I de flesta fall samlas data för varje komponent i arkitekturen in lokalt och kombineras sedan korrekt med data som genereras av andra komponenter.

Ett program med tre nivåer kan till exempel ha:

• En presentationsnivå som gör att en användare kan ansluta till en webbplats.

• En mellannivå som är värd för en uppsättning mikrotjänster som bearbetar affärslogik.

• En databasnivå som lagrar data som är associerade med åtgärden.

Användningsdata för en enskild affärsåtgärd kan omfatta alla tre nivåerna. Den här informationen måste korreleras för att ge en övergripande vy över resursen och bearbetningsanvändningen för åtgärden. Korrelationen kan omfatta viss förbearbetning och filtrering av data på databasnivån. På mellannivån är aggregering och formatering vanliga uppgifter.

Rekommendationer

• Korrelera loggar på programnivå och resursnivå. Utvärdera data på båda nivåerna för att optimera identifieringen av problem och felsökning av dessa problem. Du kan aggregera data i en enda datamottagare eller dra nytta av metoder som frågar efter händelser på båda nivåerna. Vi rekommenderar en enhetlig lösning, till exempel Azure Log Analytics, för att aggregera och köra frågor mot loggar på program- och resursnivå.

• Definiera tydliga kvarhållningstider för lagring för kall analys. Vi rekommenderar den här metoden för att aktivera historisk analys under en viss period. Det kan också hjälpa dig att kontrollera lagringskostnaderna. Implementera processer som säkerställer att data arkiveras till billigare lagring och aggregerade data för långsiktig trendanalys.

• Analysera långsiktiga trender för att förutsäga driftsproblem. Utvärdera långsiktiga data för att skapa operativa strategier och även förutsäga vilka driftsproblem som sannolikt kommer att uppstå och när. Du kan till exempel tänka på att de genomsnittliga svarstiderna långsamt ökar med tiden och närmar sig det maximala målet.

Detaljerad vägledning om dessa rekommendationer finns i Analysera övervakningsdata för molnprogram.

Visualisering

Instrumentpaneler

Det vanligaste sättet att visualisera data är att använda instrumentpaneler som kan visa information som en serie diagram eller diagram, eller i något annat visuellt format. Dessa objekt kan parametriseras och en analytiker kan välja viktiga parametrar, till exempel tidsperioden, för varje specifik situation.

Justera dina instrumentpaneler med din hälsomodell så att de anger när arbetsbelastningen eller komponenterna i arbetsbelastningen är felfria, degraderade eller inte felfria.

För att ett instrumentpanelssystem ska fungera effektivt måste det vara meningsfullt för arbetsbelastningsteamet. Visualisera information som relaterar till arbetsbelastningens hälsa och som också kan användas. När arbetsbelastningen eller en komponent är degraderad eller inte felfri bör medlemmar i arbetsbelastningsteamet enkelt kunna identifiera var i arbetsbelastningen problemet har sitt ursprung och påbörja sina korrigerande åtgärder eller undersökningar. Om du inkluderar information som inte kan åtgärdas eller som inte är relaterad till arbetsbelastningens hälsa kan instrumentpanelen göra instrumentpanelen onödigt komplex och frustrerande för teammedlemmar som försöker urskilja bakgrundsbrus från användbara data.

Du kan ha instrumentpaneler för intressenter eller utvecklare som är anpassade för att endast visa data om den arbetsbelastning som de tycker är relevant. Se till att arbetsbelastningsteamet förstår vilka typer av datapunkter som andra team är intresserade av att se och förhandsgranskar instrumentpanelerna innan de delas för att söka efter klarhet. Att tillhandahålla instrumentpaneler om din arbetsbelastning för intressenter är ett bra sätt att hålla dem underrättade om arbetsbelastningens hälsa, men det riskerar att bli kontraproduktivt om intressenterna inte tydligt förstår de data de ser.

En bra instrumentpanel visar inte bara information. Det gör det också möjligt för en analytiker att ställa improviserade frågor om den informationen. Vissa system tillhandahåller hanteringsverktyg som en operatör kan använda för att utföra dessa uppgifter och utforska underliggande data. Beroende på vilken lagringsplats som används för att lagra informationen kan det i stället vara möjligt att fråga data direkt eller importera dem till verktyg som Excel för ytterligare analys och rapportering.

Anteckning

Begränsa instrumentpanelens åtkomst till behörig personal. Information på instrumentpaneler kan vara kommersiellt känslig. Du bör också skydda underliggande data för att förhindra användare från att ändra dem.

Rapportering

Rapportering används till att generera en översiktlig vy av systemet. Den kan innehålla historiska data och aktuell information. Rapporteringskraven delas in i två breda kategorier: driftrapportering och säkerhetsrapportering.

Driftrapportering omfattar vanligtvis följande:

• Aggregera statistik som du kan använda för att förstå resursutnyttjandet av det övergripande systemet eller angivna undersystem under en angiven tidsperiod.

• Identifiera trender i resursanvändningen för det övergripande systemet eller angivna undersystem under en angiven period.

• Övervakning av undantag som har inträffat i hela systemet eller i angivna undersystem under en angiven period.

• Fastställa programmets effektivitet för de distribuerade resurserna och förstå om resursvolymen och deras associerade kostnader kan minskas utan att prestanda påverkas i onödan.

Säkerhetsrapportering spårar kundens användning av systemet. Det kan omfatta:

• Granska användaråtgärder. Den här uppgiften kräver registrering av enskilda begäranden som varje användare slutför, tillsammans med datum och tider. Data bör struktureras så att en administratör snabbt kan rekonstruera sekvensen av åtgärder som en användare slutför under en angiven period.

• Spårning av användares resursanvändning. Den här uppgiften kräver att du registrerar hur varje begäran från en användare kommer åt de olika resurser som utgör systemet och hur länge. En administratör kan använda dessa data för att generera en användningsrapport, per användare, under en angiven period, eventuellt för fakturering.

Ofta kan batchprocesser generera rapporter enligt ett definierat schema. Svarstid är normalt inte ett problem. Du bör också ha batchprocesser som kan generera rapporter spontant efter behov. Om du till exempel lagrar data i en relationsdatabas som Azure SQL Database kan du använda ett verktyg som SQL Server Reporting Services för att extrahera och formatera data och presentera dem som en uppsättning rapporter.

Aviseringar

För att säkerställa att systemet förblir felfritt, responsivt och säkert anger du aviseringar så att operatörerna kan svara på dem i tid. En avisering kan innehålla tillräckligt med sammanhangsinformation för att hjälpa dem att snabbt komma igång med diagnostikaktiviteter. Aviseringar kan användas för att anropa reparationsfunktioner som autoskalning eller andra självåterställningsmekanismer. Aviseringar kan också möjliggöra kostnadsmedvetenhet genom att ge insyn i budgetar och gränser.

Rekommendationer

• Definiera en process för aviseringssvar som identifierar ansvariga ägare och åtgärder.

• Konfigurera aviseringar för ett väldefinierat omfång (resurstyper och resursgrupper) och justera utförligheten för att minimera bruset.

• Använd en automatiserad aviseringslösning, till exempel Splunk eller Azure Monitor, i stället för att kräva att personer aktivt söker efter problem.

• Använd aviseringar för att operationalisera reparationsprocesser. Skapa till exempel automatiskt biljetter för att spåra problem och lösningar.

• Spåra hälsotillståndet för dina molnplattformstjänster i regioner, kommunikation om avbrott, planerade underhållsaktiviteter och andra hälsorekommendationer.

Tröskelvärden

Aviseringar genereras när tröskelvärden överskrids, vilket identifieras av ditt övervakningssystem. Se till att de tröskelvärden du anger i allmänhet ger dig tillräckligt med tid för att implementera nödvändiga ändringar i din arbetsbelastning för att undvika försämring eller avbrott. Ange till exempel tröskelvärdet för automatisk skalning för att initiera skalning innan något av de system som körs överbelastas till den grad att användarupplevelsen försämras. Basera tröskelvärdena som du tilldelar på din tidigare erfarenhet av att hantera infrastrukturen och verifiera dem genom de tester som du utför som en del av dina testmetoder.

Detaljerad vägledning om aviseringsanvändningsfall och andra överväganden finns i Utforma en tillförlitlig strategi för övervakning och aviseringar.

Azure-underlättande

• Azure Monitor är en omfattande övervakningslösning för att samla in, analysera och svara på övervakningsdata från molnmiljöer och lokala miljöer.

• Log Analytics är ett verktyg i Azure Portal som du kan använda för att redigera och köra loggfrågor mot data på Log Analytics-arbetsytan.

  Om du använder flera arbetsytor kan du läsa mer i Log Analytics-arkitekturguiden för arbetsytor för bästa praxis.

• Application Insights är ett tillägg för Azure Monitor. Den innehåller APM-funktioner.

• Azure Monitor Insights är avancerade analysverktyg för specifika Azure-tekniker (till exempel virtuella datorer, apptjänster och containrar). De här verktygen ingår i Azure Monitor och Log Analytics.

• Azure Monitor för SAP-lösningar är ett Azure-övervakningsverktyg för SAP-landskap som körs i Azure.

• Azure Policy kan hjälpa dig att genomdriva organisationens standarder och utvärdera efterlevnad i stor skala.

Relaterade länkar

• Instrumentationsguide
• Rekommendationer för att utforma en tillförlitlig strategi för övervakning och avisering
• Rekommendationer för övervakning och hotidentifiering
• Rekommendationer för insamling av prestandadata

Checklista för utmärkt drift

Se den fullständiga uppsättningen rekommendationer.

Checklista för utmärkt drift