Driftsmedvetenhet
För att vi ska börja arbeta med övervakning för tillförlitlighet finns det ett föregående steg som vi måste ta. Vi måste först se till att vi har en rimlig nivå av driftsmedvetenhet.
Det enklaste sättet att säga detta är att för att arbeta mot systemens tillförlitlighet i produktionen måste vi först ha en anständig förståelse för dessa system och hur de fungerar i produktion.
Samla in information om den aktuella konfigurationen
Även om det kan låta märkligt, i många miljöer den första frågan wee behöver svara är "Vad exakt körs i produktion?" Våra produktionsmiljöer i dag och sökvägarna till distribution till dem är tillräckligt komplexa att det inte är ovanligt att först behöva göra lite identifiering först. Vilka är komponentdelarna i ett specifikt program? Vilka delar kommunicerar med andra delar? Vilka är de uppenbara (och inte så uppenbara) beroendena för det här programmet?
Samla in information om normal och tidigare prestanda
När vi har skaffat den informationen kan vi försöka få en baslinje kring systemets prestanda och ”normala” beteende. Det finns många anledningar till att vi kan behöva den här informationen, inte minst för att hjälpa oss när vi måste sortera ett problem med programmet. Mitt i ett avbrott är en dålig tid att ta reda på om databasservrarna som körs på 80% CPU är en bra sak eller en dålig sak.
Som ett led i upprättandet av den här baslinjen behöver vi ta en titt på tidigare prestanda. Även om det är sant att tidigare prestanda inte är någon garanti för framtida resultat, kan det ibland hjälpa oss att kalibrera våra förväntningar. På samma sätt, om vi har tillgång till information om tidigare avbrott eller hicka med en tjänst, kan de ge oss åtminstone en känsla av potentiella fellägen som vi kommer att behöva införliva i vårt tänkande kring tillförlitlighet.
Samla in information om kontexten
Och slutligen är det användbart för oss att få lite kontextuell kunskap kring ett system. Kontexten kan hämtas från flera olika ställen, mycket av det sociotekniskt. Till exempel: på socio-sidan vill vi samla in bra information om de intressenter som är associerade med en tjänst eller ett program.
Du kanske tror att det är uppenbart vem som äger eller bryr sig om en viss app/tjänst, men i företagssituationer eller andra komplexa organisationer kan detta vara mycket svårare än det låter.
Den sorgliga sanningen är att vi inte kommer att kunna göra mycket framsteg på ett systems tillförlitlighet utan en tydlig uppfattning om vilka intressenterna är (av skäl som kommer att bli tydliga senare när vi diskuterar SLO: er och SLO).
På den tekniska sidan av kontextfrågan är det verkligen bra för oss att uppmärksamma tekniska frågor som hur det här programmet kom i produktion? Distribuerades den manuellt under en "episk" distribution, eller distribuerades den via en automatiserad CI/CD-pipeline med en stor uppsättning enhetstester?
Den här informationen kan ha många konsekvenser, inklusive hur enkelt det blir att iterera om och när vi har tillförlitlighet som förbättrar uppdateringarna. Det är också möjligen en användbar indikator på arbete som vi kan göra som kommer att göra verklig skillnad.
Azure Tools för driftsmedvetenhet
Att få driftsmedvetenhet är ofta inte lätt, men vi ska titta på några verktyg som Azure tillhandahåller som kan hjälpa till med processen. Detta kommer att bli en mycket ytlig utforskning; I slutet av den här modulen tar vi med pekare till andra Microsoft Learn-moduler och dokumentation om du vill utforska något av dessa mer ingående.
Programinsikter
De första verktygen vi ska titta på kan hjälpa oss med frågan "vad körs egentligen?". Som driftspersoner är det inte ovanligt att bli ombedd att arbeta med ett program som redan körs i produktion. Även om vi helst skulle vara en del av hela livscykeln för programvaran, med början i designfasen, är det inte alltid (eller kanske ofta) fallet. När detta händer, särskilt med mer komplexa program baserade på flera nivåer eller mikrotjänster, kan det krävas arbete för att bara kunna förstå vad alla rörliga delar gör.
Ett verktyg som kan minska den här ansträngningen – plus att ge oss information om programmets beteende i produktion – är Application Insights. Med minimal ansträngning kan utvecklare instrumentera sitt program så att det automatiskt skickar information om telemetri till insamlare som körs i Azure. Med den här informationen kan Application Insights skapa en visuell karta över programmets komponenter och kommunikationen mellan dessa komponenter.
Här är ett exempel:
I föregående bild kan du se inte bara programmets komponenter, utan även kommunikationen mellan dessa komponenter. Om du zoomar in på en av anslutningarna mellan komponenter kan du se antalet anrop som görs mellan komponenter och den genomsnittliga svarstiden för dessa anrop. Du kan också se en representation av antalet lyckade och antalet misslyckade anrop. Om du väljer något av dessa kartelement kan du med Application Insights granska informationen för att se detaljerad statistik om prestanda- och framgångs-/felmått för dessa anrop. Det här kan vara ett bra sätt att få en översikt över programmets komponenter och hur de fungerar som en baslinje. Som en påminnelse bör du utforska din programkarta och allt som Application Insights kan erbjuda innan du får ett avbrott.
Azure Resource Graph
Application Insights är ett bra sätt att få viss driftsmedvetenhet för ett program, men vad händer om du vill få en vy från ännu högre upp och se alla resurser som du har i azure i en prenumeration? Tidigare skulle du ladda ned rapporter eller skriva PowerShell för att samla in den här informationen, men nu finns det ett mycket enklare sätt.
Azure Resource Graph Explorer tillhandahåller en interaktiv frågemiljö direkt från Azure-portalen för de data du behöver. Med hjälp av den kan du köra godtyckliga frågor som returnerar realtidssvar baserat på de resurser som används för närvarande. Om du till exempel vill se alla virtuella datorer som du kör för närvarande kan du köra följande fråga:
och du får tillbaka en fullständig detaljerad lista över de virtuella datorer som används i vår prenumeration:
Frågespråket som används i den här miljön är Kusto Query Language (KQL). Vi diskuterar det mer ingående längre fram i den här modulen när vi pratar om Azure Monitor Log Analytics.
Instrumentpaneler
Det mest traditionella driftsverktyget för driftsmedvetenhet är instrumentpanelen. Ofta när vi föreställer oss driftsansvariga ser vi dem sitta framför stora bildskärmar och intensivt stirra på instrumentpaneler fulla med grafer, diagram och räknare. I den här modulen kommer vi inte att utforska hur du skapar, redigerar eller använder instrumentpaneler. Det görs i stort genom att fästa innehåll från andra platser i portalen och sedan flytta runt dem enligt eget tycke.
I stället ska vi titta på två instrumentpanelsfunktioner som är mindre vanliga och som kan vara till stor nytta för dig. Du hittar de här funktionerna överst på varje instrumentpanel.
Med de två markerade pilarna kan du ladda upp och exportera JSON-representationer av instrumentpaneler.
Börja med att börja med exportfunktionen. Om du väljer Exportera väljer du Ladda ned, en JSON-fil som representerar den aktuella instrumentpanelen laddas ned till datorn. Om du vill kan du prova detta nu genom att logga in på portalen, välja Instrumentpanel på produktmenyn och sedan välja Exportera>nedladdning.
Det finns minst två saker du kan göra med den här filen som du kan ha nytta av:
Du kan kontrollera filen i källkontrollsystemet. På så sätt kan du hålla reda på dina olika versioner av instrumentpaneler och även tillåta andra att komma åt dem om de vill använda instrumentpanelen. Vissa kan kalla det här för ”instrumentpaneler som kod”.
Du kan använda den här filen som grund för en ny instrumentpanel. Här är ett konkret exempel som vi återkommer till senare i den här utbildningsvägen: Anta att du måste visa en kollega hur en viss instrumentpanel såg ut i en timme under ett avbrott som inträffade förra veckan. Du kan publicera instrumentpanelen och be dem att gå och välja exakt tid och tidsperiod. Men mycket enklare och mindre felbenägen kan du ladda ned din instrumentpanel som konfigurerats precis som du behöver och dela den JSON-filen. Om du vill markera en andra period från samma instrumentpanel, låt oss säga en timme i framtiden, är det enkelt att redigera JSON.
Det är exportfunktionen. Nu ska vi fokusera på användningarna för uppladdningsfunktionen. Förutom att kunna läsa in de versionsstyrda eller redigerade filerna från det sista avsnittet kan du använda uppladdningsfunktionen för att använda andras noggranna arbete när du skapar instrumentpaneler.
Vi ska ta en titt på ett sista exempel för det här avsnittet som snyggt binder samman de två idéerna i den här enheten. Om du laddar ned JSON-filen
till datorn och sedan ladda upp den till en instrumentpanel bör du se något liknande:
Du har nu en live instrumentpanel som visar en ganska lätt förståelig inventering av resurserna som används i en prenumeration. Den här instrumentpanelens data kommer från samma källa som Azure Resource Graph Explorer som vi tittade på tidigare. Om du väljer en av panelerna kan du se (och redigera om så önskas) den exakta fråga som körs för att visa informationen på den kvadraten. Jättebra, eller hur?
Med den hjälpen för vår driftsmedvetenhet ska vi börja utforska precis vad vi vill övervaka för att hjälpa oss att förbättra vår tillförlitlighet.