Webinariet har dåligt ljud, så vi har transkriberat det.
Jag heter Medvedev Eduard. Idag ska jag prata om vad SRE är, hur SRE såg ut, vilka arbetskriterier SRE-ingenjörer har, lite om tillförlitlighetskriterier, lite om dess övervakning. Vi kommer att gå på topparna, för du kan inte säga mycket på en timme, men jag kommer att ge material för ytterligare granskning, och vi väntar alla på dig . i Moskva i slutet av januari.
Låt oss först prata om vad SRE är - Site Reliability Engineering. Och hur det framstod som en separat position, som en separat riktning. Allt började med att i traditionella utvecklingskretsar är Dev och Ops två helt olika team, oftast med två helt olika mål. Målet för utvecklingsteamet är att rulla ut nya funktioner och möta verksamhetens behov. Målet med Ops-teamet är att se till att allt fungerar och att inget går sönder. Uppenbarligen motsäger dessa mål varandra direkt: för att allt ska fungera och inget ska gå sönder, rulla ut nya funktioner så lite som möjligt. På grund av detta finns det många interna konflikter som metodiken som nu kallas DevOps försöker lösa.
Problemet är att vi inte har en tydlig definition av DevOps och en tydlig implementering av DevOps. Jag talade på en konferens i Jekaterinburg för två år sedan, och fram tills nu började DevOps-sektionen med rapporten "What is DevOps". 2 är Devops nästan 2017 år gammal, men vi bråkar fortfarande vad det är. Och det här är en mycket märklig situation som Google försökte lösa för några år sedan.
2016 släppte Google en bok som heter Site Reliability Engineering. Och faktiskt var det med den här boken som SRE-rörelsen började. SRE är en specifik implementering av DevOps-paradigmet i ett specifikt företag. SRE-ingenjörer är engagerade i att säkerställa att systemen fungerar tillförlitligt. De kommer mestadels från utvecklare, ibland administratörer med en stark utvecklingsbakgrund. Och de gör som systemadministratörer brukade göra, men en stark bakgrund i utveckling och kunskap om systemet vad gäller kod leder till att dessa personer inte är benägna till rutinmässigt administrativt arbete, utan är benägna att automatisera.
Det visar sig att DevOps-paradigmet i SRE-team implementeras av att det finns SRE-ingenjörer som löser strukturella problem. Här är det, samma koppling mellan Dev och Ops som folk har pratat om i 8 år. Rollen för en SRE liknar den för en arkitekt genom att nykomlingar inte blir SREs. Människor i början av sin karriär har ännu ingen erfarenhet, har inte den nödvändiga kunskapsbredden. Eftersom SRE kräver en mycket subtil kunskap om exakt vad och när exakt kan gå fel. Därför behövs här i regel viss erfarenhet både inom och utanför företaget.
De frågar om skillnaden mellan SRE och devops kommer att beskrivas. Hon har precis beskrivits. Vi kan prata om SRE:s plats i organisationen. Till skillnad från detta klassiska DevOps-upplägg, där Ops fortfarande är en separat avdelning, är SRE en del av utvecklingsteamet. De är involverade i produktutveckling. Det finns till och med ett tillvägagångssätt där SRE är en roll som går från en utvecklare till en annan. De deltar i kodgranskningar på samma sätt som till exempel UX-designers, utvecklarna själva, ibland produktchefer. SRE arbetar på samma nivå. Vi måste godkänna dem, vi måste granska dem, så att SRE för varje driftsättning säger: "Okej, den här utplaceringen, den här produkten kommer inte att påverka tillförlitligheten negativt. Och om det gör det, då inom några acceptabla gränser. Vi kommer också att prata om detta.
Följaktligen har SRE ett veto för att ändra koden. Och generellt leder detta också till någon form av liten konflikt om SRE implementeras felaktigt. I samma bok om Site Reliability Engineering berättar många delar, inte ens en, hur man undviker dessa konflikter.
De frågar hur SRE förhåller sig till informationssäkerhet. SRE är inte direkt involverat i informationssäkerhet. I grund och botten, i stora företag, görs detta av individer, testare, analytiker. Men SRE interagerar också med dem i den meningen att vissa operationer, vissa commits, vissa distributioner som påverkar säkerheten också kan påverka produktens tillgänglighet. Därför har SRE som helhet interaktion med alla team, inklusive säkerhetsteam, inklusive analytiker. Därför behövs SRE främst när de försöker implementera DevOps, men samtidigt blir bördan för utvecklare för stor. Dvs utvecklingsteamet själva klarar inte längre av att de nu också behöver ansvara för Ops. Och det finns en separat roll. Denna roll är planerad i budgeten. Ibland är denna roll fastställd i storleken på laget, en separat person dyker upp, ibland blir en av utvecklarna det. Så här dyker den första SRE ut i laget.
Komplexiteten i systemet som påverkas av SRE, komplexiteten som påverkar driftens tillförlitlighet, är nödvändig och oavsiktlig. Nödvändig komplexitet är när en produkts komplexitet ökar i den utsträckning som krävs av nya produktegenskaper. Slumpmässig komplexitet är när komplexiteten i systemet ökar, men produktfunktionen och affärskraven påverkar inte direkt detta. Det visar sig att antingen utvecklaren gjorde ett misstag någonstans, eller så är algoritmen inte optimal, eller så introduceras några ytterligare intressen som ökar produktens komplexitet utan särskilt behov. En bra SRE bör alltid avbryta denna situation. Det vill säga alla commit, alla utplaceringar, alla pull-begäranden, där svårigheten ökar på grund av slumpmässig tillägg, bör blockeras.
Frågan är varför inte bara anlita en ingenjör, en systemadministratör med mycket kunskap i teamet. En utvecklare i rollen som ingenjör, får vi veta, är inte den bästa bemanningslösningen. En utvecklare i rollen som ingenjör är inte alltid den bästa bemanningslösningen, men poängen här är att en utvecklare som är engagerad i Ops har lite mer lust för automatisering, har lite mer kunskap och en färdighet för att kunna implementera denna automatisering. Och följaktligen minskar vi inte bara tiden för vissa specifika operationer, inte bara rutinen, utan också så viktiga affärsparametrar som MTTR (Mean Time To Recovery, recovery time). Således, och vi kommer också att prata om detta lite senare, sparar vi pengar till organisationen.
Låt oss nu prata om kriterierna för driften av SRE. Och först och främst om tillförlitlighet. I små företag, startups, händer det ofta att folk antar att om tjänsten är välskriven, om produkten är skriven bra och korrekt så kommer den att fungera, den går inte sönder. Det är det, vi skriver bra kod, så det finns inget att bryta. Koden är väldigt enkel, det finns inget att bryta. Det här är ungefär samma personer som säger att vi inte behöver tester, för det här är de tre VPI-metoderna, varför bryta här.
Detta är helt fel, naturligtvis. Och dessa människor blir väldigt ofta bitna av sådan kod i praktiken, eftersom saker går sönder. Saker och ting går sönder ibland på de mest oförutsägbara sätt. Ibland säger folk nej, det kommer aldrig att hända. Och det händer hela tiden. Händer tillräckligt ofta. Och det är därför ingen någonsin strävar efter 100% tillgänglighet, eftersom 100% tillgänglighet aldrig händer. Detta är normen. Och därför, när vi talar om tillgängligheten för en tjänst, talar vi alltid om nior. 2 nior, 3 nior, 4 nior, 5 nior. Om vi översätter detta till driftstopp, alltså till exempel 5 nior, så är detta lite mer än 5 minuters driftstopp per år, 2 nior är 3,5 dagars driftstopp.
Men det är uppenbart att det någon gång sker en minskning av POI, avkastning på investeringen. Att gå från två nior till tre nior innebär mindre stilleståndstid med mer än 3 dagar. Att gå från fyra nior till fem minskar stilleståndstiden med 47 minuter per år. Och det visar sig att det kanske inte är kritiskt för företagen. Och i allmänhet är den erforderliga tillförlitligheten inte en teknisk fråga, för det första är det en affärsfråga, det är en produktfråga. Vilken nivå av driftstopp är acceptabel för användare av produkten, vad de förväntar sig, hur mycket de betalar, till exempel hur mycket pengar de förlorar, hur mycket pengar systemet förlorar.
En viktig fråga här är vad är tillförlitligheten hos de återstående komponenterna. Eftersom skillnaden mellan 4 och 5 nior inte kommer att synas på en smartphone med 2 nior av tillförlitlighet. Grovt sett, om något går sönder på en smartphone i din tjänst 10 gånger per år, inträffade troligen 8 gånger haveriet på OS-sidan. Användaren är van vid detta och kommer inte att uppmärksamma en gång om året. Det är nödvändigt att korrelera priset för ökad tillförlitlighet och ökande vinster.
Just i boken om SRE finns ett bra exempel på att öka till 4 nior från 3 nior. Det visar sig att tillgänglighetsökningen är lite mindre än 0,1 %. Och om intäkterna för tjänsten är 1 miljon dollar per år, är ökningen av intäkterna 900 dollar. Om det kostar oss mindre än $900 per år att öka överkomligheten med en nio, är ökningen ekonomiskt vettig. Om det kostar mer än 900 dollar per år är det inte längre vettigt, eftersom intäktsökningen helt enkelt inte kompenserar för arbetskostnaderna, resurskostnaderna. Och 3 nior kommer att räcka för oss.
Detta är naturligtvis ett förenklat exempel där alla förfrågningar är lika. Och att gå från 3 nior till 4 nior är lätt nog, men samtidigt, till exempel att gå från 2 nior till 3, är detta redan en besparing på 9 tusen dollar, det kan vara ekonomiskt vettigt. Naturligtvis, i verkligheten är misslyckandet med registreringsbegäran värre än misslyckandet med att visa sidan, förfrågningar har olika vikt. De kan ha ett helt annat kriterium ur affärssynpunkt, men hur som helst, som regel, om vi inte pratar om några specifika tjänster, är detta en ganska tillförlitlig approximation.
Vi fick en fråga om SRE är en av samordnarna vid val av arkitektonisk lösning för tjänsten. Låt oss säga i termer av integration i den befintliga infrastrukturen, så att det inte blir någon förlust i dess stabilitet. Ja, SRE, på samma sätt som pull-förfrågningar, commits, releaser påverkar arkitekturen, introduktionen av nya tjänster, mikrotjänster, implementeringen av nya lösningar. Varför sa jag innan att erfarenhet behövs, kvalifikationer behövs. Faktum är att SRE är en av de blockerande rösterna i alla arkitektur- och mjukvarulösningar. Följaktligen måste en SRE som ingenjör först och främst inte bara förstå, utan också förstå hur vissa specifika beslut kommer att påverka tillförlitlighet, stabilitet och förstå hur detta relaterar till affärsbehov, och från vilken synvinkel det kan vara acceptabelt och vilket inte.
Därför kan vi nu bara prata om tillförlitlighetskriterier, som traditionellt definieras i SRE som SLA (Service Level Agreement). Med största sannolikhet en bekant term. SLI (Service Level Indicator). SLO (Service Level Objective). Service Level Agreement är kanske en symbolisk term, speciellt om du har arbetat med nätverk, med leverantörer, med hosting. Detta är ett allmänt avtal som beskriver prestanda för hela din tjänst, straffavgifter, vissa straffavgifter för fel, mätvärden, kriterier. Och SLI är själva tillgänglighetsmåttet. Det vill säga vad SLI kan vara: svarstid från tjänsten, antalet fel i procent. Det kan vara bandbredd om det är någon form av filvärd. När det kommer till igenkänningsalgoritmer kan indikatorn vara till och med svarets korrekthet. SLO (Service Level Objective) är en kombination av SLI-indikatorn, dess värde och period.
Låt oss säga att SLA kan vara så här. Tjänsten är tillgänglig 99,95 % av tiden under hela året. Eller så kommer 99 kritiska supportbiljetter att stängas inom 3 timmar per kvartal. Eller så kommer 85 % av frågorna att få svar inom 1,5 sekunder varje månad. Det vill säga, vi kommer gradvis att förstå att fel och misslyckanden är ganska normala. Det här är en acceptabel situation, vi planerar det, vi räknar till och med med det till viss del. Det vill säga att SRE bygger system som kan göra fel, som måste svara normalt på fel, som måste ta hänsyn till dem. Och när det är möjligt bör de hantera fel på ett sådant sätt att användaren antingen inte märker dem eller märker, men det finns någon form av lösning, tack vare vilken allt inte kommer att falla ner helt.
Till exempel, om du laddar upp en video till YouTube, och YouTube inte kan konvertera den omedelbart, om videon är för stor, om formatet inte är optimalt, då kommer begäran naturligtvis inte att misslyckas med en timeout, YouTube kommer inte att ge ett 502-fel , kommer YouTube att säga: "Vi har skapat allt, din video bearbetas. Det kommer att vara klart om cirka 10 minuter." Detta är principen för graciös degradering, som är bekant till exempel från front-end-utveckling, om du någonsin har gjort detta.
Nästa termer som vi kommer att prata om, som är mycket viktiga för att arbeta med tillförlitlighet, med fel, med förväntningar, är MTBF och MTTR. MTBF är medeltiden mellan misslyckanden. MTTR Mean Time To Recovery, genomsnittlig tid till återhämtning. Det vill säga hur lång tid som har gått från det att felet upptäcktes, från det att felet uppstod till det ögonblick då tjänsten återställdes till full normal drift. MTBF fixas huvudsakligen genom arbete med kodkvalitet. Det vill säga det faktum att SRE kan säga "nej". Och du behöver förståelse för hela laget att när SRE säger "nej", säger han det inte för att han är skadlig, inte för att han är dålig, utan för att annars kommer alla att lida.
Återigen, det finns många artiklar, många metoder, många sätt även i just den bok som jag refererar till så ofta, hur man kan se till att andra utvecklare inte börjar hata SRE. MTTR, å andra sidan, handlar om att arbeta med dina SLO:er (Service Level Objective). Och det är mest automation. För att till exempel vår SLO är en drifttid på 4 nior per kvartal. Det betyder att vi på 3 månader kan tillåta 13 minuters driftstopp. Och det visar sig att MTTR inte kan vara mer än 13 minuter. Om vi svarar på minst 13 driftstopp på 1 minuter betyder det att vi redan har förbrukat hela budgeten för kvartalet. Vi bryter SLO. 13 minuter att reagera och fixa en krasch är mycket för en maskin, men väldigt kort för en människa. För tills en person får en varning, tills han reagerar, tills han förstår felet, är det redan flera minuter. Tills en person förstår hur man fixar det, exakt vad man ska fixa, vad man ska göra, då är det några minuter till. Och faktiskt, även om du bara behöver starta om servern, som det visar sig, eller höja en ny nod, är MTTR manuellt redan cirka 7-8 minuter. Vid automatisering av processen når MTTR mycket ofta en sekund, ibland millisekunder. Google brukar prata om millisekunder, men i verkligheten är förstås inte allt så bra.
Helst bör SRE automatisera sitt arbete nästan helt, eftersom detta direkt påverkar MTTR, dess mätvärden, SLO för hela tjänsten och följaktligen affärsvinsten. Om tiden överskrids tillfrågas vi om SRE har fel. Lyckligtvis är det ingen att skylla på. Och det här är en separat kultur som kallas balmeless postmortem, som vi inte kommer att prata om idag, men vi kommer att analysera den på Slurm. Det här är ett väldigt intressant ämne som kan pratas mycket om. I grova drag, om den tilldelade tiden per kvartal överskrids, så är det lite av alla som får skulden, vilket gör att det inte är produktivt att skylla på alla, låt oss istället, kanske inte skylla på någon, utan rätta till situationen och jobba med det vi har. Enligt min erfarenhet är detta tillvägagångssätt lite främmande för de flesta lag, särskilt i Ryssland, men det är vettigt och fungerar mycket bra. Därför kommer jag att rekommendera i slutet av artikeln och litteraturen att du kan läsa om detta ämne. Eller kom till Slurm SRE.
Låt mig förklara. Om SLO-tiden per kvartal överskrids, om stilleståndstiden inte var 13 minuter, utan 15, vem kan vara skyldig till detta? Naturligtvis kan SRE vara skyldig, eftersom han helt klart gjorde någon form av dålig commit eller utplacering. Administratören av datacentret kan vara skyldig till detta, eftersom han kan ha utfört någon form av oplanerat underhåll. Om administratören av datacentret är skyldig till detta, så är det personen från Ops som är skyldig till detta, som inte räknat på underhållet när han kom överens om SLO. Det är chefen, teknisk direktör eller någon som undertecknat datacenterkontraktet och inte uppmärksammat att datacentrets SLA inte är utformat för den nödvändiga stilleståndstiden är skyldig till detta. Följaktligen är alla lite i taget i denna situation skyldiga. Och det betyder att det inte är någon idé att lägga skulden på någon i den här situationen. Men det måste såklart rättas till. Det är därför det finns obduktioner. Och om du läser till exempel GitHub postmortems, och det här alltid är en väldigt intressant, liten och oväntad historia i varje specifikt fall, kan du ersätta att ingen någonsin säger att just den här personen var skyldig. Skulden läggs alltid på specifika ofullkomliga processer.
Låt oss gå vidare till nästa fråga. Automatisering. När jag pratar om automatisering i andra sammanhang hänvisar jag ofta till en tabell som talar om hur länge du kan arbeta med att automatisera en uppgift utan att ta längre tid att automatisera den än du faktiskt sparar. Det finns en hake. Haken är att när SRE automatiserar en uppgift, sparar de inte bara tid, de sparar pengar, eftersom automatisering direkt påverkar MTTR. De sparar så att säga moralen hos anställda och utvecklare, vilket också är en uttömlig resurs. De minskar rutinen. Och allt detta har en positiv effekt på arbetet och, som ett resultat, på verksamheten, även om det verkar som om automatisering inte är vettigt när det gäller tidskostnader.
Det har det faktiskt nästan alltid gjort, och det finns väldigt få fall där något inte borde automatiseras i rollen som SRE. Härnäst ska vi prata om det som kallas felbudgeten, budgeten för fel. Faktum är att det visar sig att om allt är mycket bättre för dig än den SLO som du ställer in för dig själv, så är detta inte heller särskilt bra. Detta är ganska dåligt, eftersom SLO fungerar inte bara som en nedre, utan också som en ungefärlig övre gräns. När du sätter dig själv en SLO på 99% tillgänglighet, och i själva verket har 99,99%, visar det sig att du har lite utrymme för experiment som inte kommer att skada verksamheten alls, eftersom du själv har bestämt detta tillsammans, och du är detta utrymme inte använda. Du har en budget för misstag, som i ditt fall inte förbrukas.
Vad gör vi med det. Vi använder det till bokstavligen allt. För testning i produktionsförhållanden, för utrullning av nya funktioner som kan påverka prestandan, för releaser, för underhåll, för planerade stillestånd. Den omvända regeln gäller också: om budgeten är uttömd kan vi inte släppa något nytt, eftersom vi annars överskrider SLO. Budgeten är redan förbrukad, vi har släppt något om det påverkar prestandan negativt, det vill säga om det här inte är någon form av fix som i sig direkt ökar SLO:en så går vi bortom budgeten, och det här är en dålig situation , måste den analyseras , obduktion och eventuellt några processfixar.
Det vill säga, det visar sig att om tjänsten i sig inte fungerar bra, och SLO spenderas och budgeten spenderas inte på experiment, inte på vissa utgåvor, utan av sig själv, så istället för några intressanta korrigeringar, istället för intressanta funktioner, istället för intressanta utgåvor. Istället för något kreativt arbete kommer du att behöva ta itu med dumma korrigeringar för att få ordning på budgeten igen, eller redigera SLO, och detta är också en process som inte bör ske för ofta.
Därför visar det sig att i en situation där vi har mer budget för fel så är alla intresserade: både SRE och utvecklare. För utvecklare innebär en stor budget för buggar att du kan hantera releaser, tester, experiment. För SRE innebär en budget för fel och att lägga in den budgeten att de direkt gör sitt jobb bra. Och detta påverkar motivationen för något slags gemensamt arbete. Om du lyssnar på dina SRE som utvecklare kommer du att få mer utrymme för bra arbete och mycket mindre rutin.
Det visar sig att experiment i produktion är en ganska viktig och nästan integrerad del av SRE i stora team. Och det brukar kallas för chaos engineering, vilket kommer från teamet på Netflix som släppte ett verktyg som heter Chaos Monkey.
Chaos Monkey ansluter till CI/CD-pipeline och kraschar slumpmässigt servern under produktion. Återigen, i SRE-strukturen talar vi om det faktum att en nedlagd server inte är dålig i sig, det förväntas. Och om det ligger inom budgeten är det acceptabelt och skadar inte verksamheten. Naturligtvis har Netflix tillräckligt med redundanta servrar, tillräckligt med replikering, så att allt detta kan fixas, och så att användaren som helhet inte ens märker det, och ännu mer så att ingen lämnar en server för någon budget.
Netflix hade en hel uppsättning sådana verktyg under ett tag, varav en, Chaos Gorilla, helt stänger av en av Amazons tillgänglighetszoner. Och sådant hjälper till att avslöja för det första dolda beroenden, när det inte är helt klart vad som påverkar vad, vad som beror på vad. Och detta, om du arbetar med en mikrotjänst och dokumentationen inte är helt perfekt, kan detta vara bekant för dig. Och återigen, detta hjälper mycket för att fånga upp fel i koden som du inte kan fånga vid iscensättning, eftersom varje iscensättning inte är exakt en exakt simulering, på grund av det faktum att belastningsskalan är annorlunda, belastningsmönstret är annorlunda, utrustningen är också, med största sannolikhet, annat. Toppbelastningar kan också vara oväntade och oförutsägbara. Och sådan testning, som återigen inte går utöver budgeten, hjälper mycket väl att fånga upp fel i infrastrukturen som staging, autotester, CI/CD-pipeline aldrig kommer att fånga upp. Och så länge allt är inkluderat i din budget spelar det ingen roll att din tjänst gick ner där, även om det verkar väldigt skrämmande, servern gick ner, vilken mardröm. Nej, det är normalt, det är bra, det hjälper till att fånga buggar. Om du har en budget kan du spendera den.
F: Vilken litteratur kan jag rekommendera? Lista i slutet. Det finns mycket litteratur, jag kommer att ge några rapporter. Hur fungerar det, och fungerar SRE i företag utan egen mjukvaruprodukt eller med minimal utveckling. Till exempel i ett företag där den huvudsakliga verksamheten inte är programvara. I ett företag, där huvudaktiviteten inte är mjukvara, fungerar SRE precis som överallt annars, för i ett företag behöver du också använda, även om de inte är utvecklade, mjukvaruprodukter, du behöver rulla ut uppdateringar, du måste ändra infrastrukturen, du behöver växa, du behöver skala. Och SRE hjälper till att identifiera och förutsäga möjliga problem i dessa processer och kontrollera dem efter att en viss tillväxt har börjat och affärsbehoven förändras. För det är absolut inte nödvändigt att vara inblandad i mjukvaruutveckling för att ha en SRE om du har minst ett fåtal servrar och du förväntas ha minst en viss tillväxt.
Detsamma gäller små projekt, små organisationer, eftersom stora företag har budgeten och utrymmet att experimentera. Men samtidigt kan alla dessa frukter av experiment användas var som helst, det vill säga SRE, naturligtvis, dök upp i Google, i Netflix, i Dropbox. Men samtidigt kan små företag och startups redan läsa förtätat material, läsa böcker, titta på rapporter. De börjar höra om det oftare, de tittar på specifika exempel, jag tycker att det är okej, det kan verkligen vara användbart, vi behöver det här också, det är jättebra.
Det vill säga, allt huvudarbete med att standardisera dessa processer har redan gjorts åt dig. Det återstår för dig att bestämma vilken roll SRE har specifikt i ditt företag och börja faktiskt implementera alla dessa metoder, som återigen redan har beskrivits. Det vill säga från användbara principer för små företag är detta alltid definitionen av SLA, SLI, SLO. Om du inte är involverad i mjukvara kommer dessa att vara interna SLA och interna SLO, en intern budget för fel. Detta leder nästan alltid till några intressanta diskussioner inom teamet och inom verksamheten, eftersom det kan visa sig att du spenderar på infrastruktur, på någon form av organisation av idealiska processer, den ideala pipelinen är mycket mer än nödvändigt. Och dessa 4 nior som du har på IT-avdelningen, du behöver dem inte riktigt nu. Men samtidigt kan du lägga tid, lägga budgeten på misstag på något annat.
Följaktligen är övervakning och organisation av övervakning användbar för ett företag av alla storlekar. Och i allmänhet, detta sätt att tänka, där misstag är något acceptabelt, där det finns en budget, där det finns mål, är det återigen användbart för ett företag av vilken storlek som helst, från startups för 3 personer.
Den sista av de tekniska nyanserna att prata om är övervakning. För om vi pratar om SLA, SLI, SLO kan vi inte förstå utan att övervaka om vi passar in i budgeten, om vi följer våra mål och hur vi påverkar den slutliga SLA:n. Jag har sett så många gånger att övervakning sker så här: det finns något värde, till exempel tiden för en förfrågan till servern, den genomsnittliga tiden eller antalet förfrågningar till databasen. Han har en standard fastställd av en ingenjör. Om måttet avviker från normen kommer ett e-postmeddelande. Allt detta är som regel helt värdelöst eftersom det leder till en sådan mängd varningar, en mängd meddelanden från övervakning, när en person för det första måste tolka dem varje gång, det vill säga avgöra om värdet på det metriska betyder behovet av några åtgärder. Och för det andra slutar han helt enkelt att märka alla dessa varningar, när i princip ingen åtgärd krävs från honom. Det är en bra övervakningsregel och den allra första regeln när SRE implementeras är att anmälan bara ska komma när åtgärder krävs.
I standardfallet finns det 3 nivåer av händelser. Det finns varningar, det finns biljetter, det finns loggar. Varningar är allt som kräver att du vidtar omedelbara åtgärder. Det vill säga allt är trasigt, du måste fixa det nu. Biljetter är det som kräver försenade åtgärder. Ja, du måste göra något, du måste göra något manuellt, automatiseringen misslyckades, men du behöver inte göra det under de närmaste minuterna. Loggar är allt som inte kräver åtgärd, och i allmänhet, om det går bra, kommer ingen någonsin att läsa dem. Du behöver bara läsa loggarna när det i efterhand visade sig att något gick sönder under en tid, vi visste inte om det. Eller behöver du göra lite research. Men i allmänhet går allt som inte kräver någon åtgärd till loggarna.
Som en bieffekt av allt detta, om vi har definierat vilka händelser som kräver åtgärder och väl har beskrivit vad dessa åtgärder ska vara, betyder detta att åtgärden kan automatiseras. Det vill säga vad som händer. Vi går från beredskap. Låt oss gå till handling. Vi går till beskrivningen av denna åtgärd. Och sedan går vi vidare till automatisering. Det vill säga att all automatisering börjar med en reaktion på en händelse.
Från övervakning går vi vidare till en term som kallas observerbarhet. Det har också varit lite hype kring detta ord de senaste åren. Och få människor förstår vad det betyder utanför sitt sammanhang. Men huvudpoängen är att observerbarhet är ett mått för systemtransparens. Om något gick fel, hur snabbt kan du avgöra exakt vad som gick fel och hur systemet var i det ögonblicket. Kodmässigt: vilken funktion misslyckades, vilken tjänst misslyckades. Hur var tillståndet för till exempel interna variabler, konfiguration. När det gäller infrastruktur är detta i vilken tillgänglighetszon felet inträffade, och om du har några Kubernetes, i vilken pod felet inträffade, vad var tillståndet för podden. Och följaktligen har Observability en direkt relation med MTTR. Ju högre observerbarhet tjänsten har, desto lättare är det att identifiera felet, desto lättare är det att åtgärda felet, desto lättare är det att automatisera felet, desto lägre MTTR.
När man går vidare till små företag igen, är det mycket vanligt att man redan nu frågar hur man hanterar teamstorlek och om ett litet team behöver anställa en separat SRE. Har redan pratat om detta lite tidigare. I de första stadierna av utvecklingen av en startup eller till exempel ett team är detta inte alls nödvändigt, eftersom SRE kan göras till en övergångsroll. Och detta kommer att återuppliva laget lite, för det finns åtminstone en viss mångfald. Och plus det kommer att förbereda människor för det faktum att med tillväxt, i allmänhet, kommer ansvaret för SRE att förändras mycket avsevärt. Om du anställer en person så har han förstås vissa förväntningar. Och dessa förväntningar kommer inte att förändras med tiden, utan kraven kommer att förändras väldigt mycket. Därför är hur man anlitar en SRE ganska svårt i de tidiga stadierna. Att odla din egen är mycket lättare. Men det är värt att tänka på.
Det enda undantaget är kanske när det finns mycket strikta och väldefinierade tillväxtkrav. Det vill säga, i fallet med en startup kan detta vara någon form av press från investerare, någon form av prognos för tillväxt flera gånger samtidigt. Då är det i grunden motiverat att anlita en SRE eftersom det kan motiveras. Vi har krav på tillväxt, vi behöver en person som kommer att ansvara för att med en sådan tillväxt kommer ingenting att gå sönder.
En till fråga. Vad ska man göra när utvecklarna flera gånger klipper en funktion som klarar testerna, men bryter produktionen, laddar basen, bryter andra funktioner, vilken process som ska implementeras. I det här fallet är det följaktligen budgeten för fel som införs. Och några av tjänsterna, några av funktionerna testas redan i produktionen. Det kan vara kanariefågel, när endast ett litet antal användare, men redan i produktionen, en funktion distribueras, men redan med förväntningen att om något går sönder, till exempel för en halv procent av alla användare, kommer det fortfarande att uppfylla budget för fel. Följaktligen, ja, det kommer att uppstå ett fel, för vissa användare kommer allt att gå sönder, men vi har redan sagt att detta är normalt.
Det var en fråga om SRE-verktyg. Det vill säga, finns det något speciellt som SREs skulle använda som alla andra inte skulle göra. Faktum är att det finns några mycket specialiserade verktyg, det finns någon form av programvara som till exempel simulerar belastningar eller är engagerad i kanariefågel A/B-testning. Men i grund och botten är SRE-verktygslådan vad dina utvecklare redan använder. Eftersom SRE interagerar direkt med utvecklingsteamet. Och har du olika verktyg kommer det att visa sig att det tar tid att synkronisera. Speciellt om SRE arbetar i stora team, i stora företag där det kan finnas flera team, är det företagsövergripande standardisering som kommer att hjälpa mycket här, för om 50 olika verktyg används i 50 team betyder det att SRE måste känna till dem Allt. Och detta kommer naturligtvis aldrig att hända. Och kvaliteten på arbetet, kvaliteten på kontrollen av åtminstone några av teamen kommer att minska avsevärt.
Vårt webinar går mot sitt slut. Jag lyckades berätta några grundläggande saker. Naturligtvis kan ingenting om SRE berättas och förstås på en timme. Men jag hoppas att jag lyckades förmedla detta sätt att tänka, de viktigaste nyckelpunkterna. Och då kommer det att vara möjligt, om du är intresserad, att fördjupa dig i ämnet, lära dig på egen hand, titta på hur det implementeras av andra människor, i andra företag. Och därför, i början av februari, kom till oss på Slurm SRE.
Slurm SRE är en tredagars intensivkurs som ska prata om det jag nu pratar om, men med mycket mer djup, med verkliga fall, med praktik, är hela intensiven inriktad på praktiskt arbete. Människor kommer att delas in i lag. Ni kommer alla att arbeta med verkliga fall. Följaktligen har vi Booking.com-instruktörerna Ivan Kruglov och Ben Tyler. Vi har en underbar Eugene Barabbas från Google, från San Francisco. Och jag ska berätta en sak för dig också. Så se till att besöka oss.
Så, bibliografin. Det finns referenser på SRE. på samma bok, eller snarare på 2 böcker om SRE, skrivna av Google. En till , där villkoren och deras tillämpning är något mer detaljerade. De kommande 3 är rapporter om SRE i olika företag. Först - , detta är en keynote från Ben Trainer från Google. andra - . Den tredje är igen . Fjärde rapporten från , som endast har 5 nyckelanställda i SRE i 190 länder. Det är väldigt intressant att titta på allt detta, för precis som DevOps betyder väldigt olika saker för olika företag och till och med olika team, har SRE väldigt olika ansvar, även i företag av liknande storlek.
2 fler länkar om principerna för kaosteknik: , . Och på slutet finns 3 listor från serien Awesome Lists om , ca och om . Listan på SRE är otroligt stor, det är inte nödvändigt att gå igenom allt, det finns cirka 200 artiklar. Jag rekommenderar starkt artiklar därifrån om kapacitetsplanering och om klanderfri obduktion.
Intressant artikel:
Tack för att du lyssnade på mig hela tiden. Hoppas du har lärt dig något. Hoppas du har tillräckligt med material för att lära dig ännu mer. Och se dig. Förhoppningsvis i februari.
Webinariet var värd av Eduard Medvedev.
PS: för den som gillar att läsa gav Eduard en referenslista. De som föredrar att förstå i praktiken är välkomna att .
Källa: will.com