Så här använder Microsoft tillförlitliga system med DevOps

Microsoft har drivit komplexa onlineplattformar sedan de tidigaste dagarna av det kommersiella Internet. Längs vägen har vi utvecklat en omfattande uppsättning metoder för att hålla system tillgängliga, felfria och säkra. Dessa metoder är en del av ett större initiativ för att underhålla och förbättra en live-webbplatskultur.

Kultur för livewebbplatser

Live-webbplatskulturen är i fokus för en organisation för att prioritera livewebbplatsens upplevelse och tillförlitlighet framför allt annat. När allt kommer om, kunder kan flytta över tjänsteleverantörer ganska enkelt nuförtiden med molnet och internetbaserade tjänster, vilket avsevärt förstärker vikten av kundförtroende. Live-webbplatsen måste alltid vara tillgänglig och fungera som utlovat för kunderna.

Det finns olika faktorer som bidrar till en framgångsrik live-webbplatskultur.

Live-webbplats först

Att sätta livewebbplatsupplevelsen först är en integrerad del av en framgångsrik plattform. Team kan inte fokusera allt på nya, glänsande funktioner och bortse från den väg där dessa funktioner presenteras för användarna. Vi förlitar oss på säkra distributionsmetoder som hjälper våra kunder att få oavbruten plattformsåtkomst. Detta kan bli särskilt komplicerat när det gäller att släppa versioner av tjänstuppdateringar utan avbrott.

Kontrollera exponering via funktionsflaggor

När vi distribuerar ut via våra nivåer och faser,som styr exponeringen med funktionsflaggor, upptäcker vi ibland ett problem i produktionen. Trots all vår automatisering och våra recensioner händer saker ibland fortfarande. Som de säger, det finns ingen plats som produktion!

Vanligtvis varnar hälsoövervakning och telemetri oss när något inte är rätt. En utvecklare kan skapa en gren av main, göra en korrigering och hämta den till main. Att behålla samma allmänna arbetsflöde innebär att utvecklare inte behöver kontextväxel eller lära sig en annan process för en annan kodändring.

För att hantera en snabbkorrigeringsdistribution krävs ytterligare ett steg, vilket är att välja ändringen i versionsgrenen. Vi kör en snabbkorrigeringsdistribution från den aktuella versionsgrenen varje vardagsmorgon, men vi kan också göra detta på begäran för brådskande korrigeringar. Korrigeringen träffar faktiskt produktionen från versionsgrenen först. Men eftersom vi utvecklas först main vet vi att den inte kommer att gå tillbaka till nästa sprint när en ny versionsgren skapas från main.

Versioner av lokala produkter är i stort sett desamma, men utan distributionsnivåer och faser. Eftersom vi utför mer manuell testning av olika konfigurationer och dataformer finns det dessutom en längre svans mellan att skära av versionsgrenen och lägga produkten i händerna på kunderna.

Säkerheten bör tas personligen

Fokus är att göra sårbarheter verkliga och personliga. Detta säkerställer att människor verkligen bryr sig. Vi använder även krigsspel i stor utsträckning för att hitta och hantera säkerhetsrisker i hela systemet, oavsett om det är kod eller inte. När det röda teamet kan visa att de kom in i kod genom att vända upp och ned på en dialogruta motiverar det verkligen kodägaren att åtgärda problemet och se till att det inte händer igen någon annanstans. Den typen av konkurrens är mycket mer verklig och personlig än en statisk analysvarning om en potentiell XSS-risk. Vi skapar den här typen av kultur och dynamisk genom krigsspel och andra säkerhetsövningar. Människor är stolta över att hacka sig in i varandras kod eller att kunna blockera försöken. Detta ingjuter en säker kodkultur.

Vi kan inte planera för varje attackvektor, men vad vi kan göra är att anta att det kommer att bli ett intrång och planera hur snabbt vi kan reagera på den överträdelsen. Mycket av säkerhetsarbetet har varit runt det för våra team.

Slutligen gör människor misstag. De blir ibland lata och gör saker som att lagra lösenord på filresurser. Vi kan säga åt dem att inte göra det och vi kan skicka dem till säkerhetsutbildning och vi kan göra alla möjliga andra saker. De flesta lär sig, men det krävs bara en person för att bryta systemet. Du kan ha alla typer av listor över bästa praxis, men om du inte gör det på riktigt måste du anta att människor kommer att göra misstag. Detta kräver en viss tillsynsnivå för att säkerställa att kritiska processer följs.

Teknik är mer än en ops-partner

Vi lärde oss tidigt att göra livewebbplatsen till en viktig del av teknikteamets ansvarsområden. Det var enormt för oss eftersom en person tidigare kunde distribuera något, lämna för helgen och återvända måndag för att hitta 900 kundproblem som kundsupport- och ops-teamen hanterade hela helgen. Det är viktigt att teknikerna betalar priset för problem med livewebbplatser. Annars finns det inget incitament att skapa system som undviker dessa problem. När du blir kallad klockan 02.00 för att fixa något du bröt, kommer du ihåg.

När vi utvecklade detta ansvar är Live-webbplatsen det viktigaste vi gör blev hela teamets mantra. Det är kundupplevelsen de har just nu och det är inte bara en skatt. Det är faktiskt något folk räknar med från oss och vi är stolta över det. Det måste vara en särskiljande funktion i vår produkt.

Produktionstelemetri är pulsslag för din tjänst

För att överleva i den snabba världen där praktiskt taget allt kan gå fel behöver vi stora varningssystem. Ogenomförbara aviseringar, redundanta aviseringar eller överväldigande aviseringsvolymer gör att du ignorerar alla aviseringar. Det är enkelt att skapa alldeles för många aviseringar, så processen destilleras verkligen till en enkel fråga: Kan den här aviseringen fungera? Detta säkerställer att vi engagerar oss i rätt kundproblem och hanterar dem så snabbt som möjligt.

När teknikteamet nollade in på användbara aviseringar märkte de att många problem som kommer upp, särskilt mitt i natten, tenderar att ha liknande korrigeringar, åtminstone tillfälligt. Detta resulterade i ett fokus på system som var bättre på att redväxa och självåterställning. Nu inträffar problemen, skapar aviseringar och åtgärdar sig sedan tillräckligt bra för att teknikteamet ska kunna vänta till morgonen för att åtgärda problemet. Detta skulle inte ha hänt om ingenjörsteamet bara tryckte ut bitar som höll andra människor uppe på natten. Nu arbetar de för att balansera dessa förbättringar som en del av inte bara funktionshastighet, utan även teknisk förbättringshastighet.

Sammanfattning

Införandet av en kultur för livewebbplatser har påverkat hur Microsoft bygger och levererar programvara. Genom att göra teknikteam till en viktig del av säkerhet och drift har kvaliteten på vår kod och slutanvändarupplevelse förbättrats drastiskt. Att vara en fullvärdig deltagare i verksamheten har gjort konstruktionen till en viktig intressent, vilket resulterar i system som är utformade för bättre drift.