Vi hÄller pÄ med onboarding av SRE-teamet pÄ företaget. Jag kom in i denna historia frÄn utvecklingssidan. Under processen har jag fÄtt tankar och insikter som jag vill dela med andra utvecklare. I denna reflekterande artikel pratar jag om vad som hÀnder, hur det hÀnder och hur alla ska fortsÀtta att leva med detta.
FortsÀttning pÄ en serie artiklar skrivna inspirerade av förelÀsningar pÄ vÄrt interna evenemang. :
2. Infrastruktur som kod. (Du Àr hÀr)
3. Generering av Typescript-kontrakt frĂ„n C#-modeller. (PĂ„gĂ„râŠ)
4. Introduktion till Raft-konsensusalgoritmen. (PĂ„gĂ„râŠ)
âŠ
Vi beslutade att skapa ett SRE-team genom att förverkliga idéerna . Vi anstÀllde programmerare frÄn vÄra egna utvecklare och skickade dem pÄ utbildning i flera mÄnader.
Teamet stod inför följande utbildningsuppgifter:
- Att beskriva vÄr infrastruktur, som till största delen finns i Microsoft Azure, i form av kod (Terraform och allt som hör till).
- Att lÀra utvecklarna att arbeta med infrastrukturen.
- Att förbereda utvecklarna för att ha jour.
Vi inför begreppet Infrastruktur som kod.
I den vanliga vÀrldens modell (klassisk administration) finns kunskapen om infrastrukturen pÄ tvÄ stÀllen:
- Antingen i form av kunskap i experternas huvuden.
- Eller finns dessa uppgifter pÄ vissa maskiner, varav en del experterna kÀnner till. Men det Àr inte sÀkert att en person utifrÄn (i hÀndelse av att hela vÄrt team plötsligt dör) kan förstÄ vad som fungerar och hur. Det kan finnas mycket information pÄ maskinen: Ätkomster, cron-jobb, en förberedande (se. ) disk och helt enkelt en oÀndlig lista över vad som kan ske. Det Àr svÄrt att förstÄ vad som faktiskt hÀnder.
I bÄda fallen hamnar vi i en fÀlla, dÀr vi blir beroende av:
- antingen av en mÀnniska, som Àr dödlig och utsatt för sjukdomar, kÀrlek, humörsvÀngningar och helt enkelt vanliga avsked;
- eller av en fysiskt fungerande maskin, som ocksÄ kan falla, stjÀlas, ger ovÀntade situationer och besvÀr.
SjÀlvklart framstÄr lösningen som att i idealfallet allt bör översÀttas till mÀnniskolÀsbar, underhÄllen och kvalitetskommenterad kod.
SĂ„ledes Ă€r infrastruktur som kod (Infrastructure as Code â IaC) en beskrivning av all befintlig infrastruktur i form av kod, samt de medel som behövs för att arbeta med den och för att realisera faktisk infrastruktur frĂ„n den.
Varför översÀtta allt till kodMÀnniskor Àr inte maskiner. De kan inte komma ihÄg allt. Reaktionen hos en mÀnniska och en maskin Àr olika. Allt som Àr automatiserat fungerar potentiellt snabbare Àn allt som görs av en mÀnniska. Det viktigaste Àr en enda sanning (single source of truth).
VarifrÄn kommer nya SRE-ingenjörerSÄ vi beslutade oss för att rekrytera nya SRE-ingenjörer, men var hittar vi dem? Boken med de rÀtta svaren () sÀger oss: frÄn utvecklare. De arbetar med kod, och du uppnÄr det perfekta tillstÄndet.
Vi har sökt lÀnge och grundligt efter dem pÄ arbetsmarknaden utanför vÄrt företag. Men vi mÄste erkÀnna att vi inte hittade en enda som matchade vÄra krav. Vi var tvungna att leta bland vÄra egna.
Problem med Infrastructure as Code
LÄt oss nu titta pÄ exempel pÄ hur infrastruktur kan integreras i kod. Koden Àr vÀlskriven, av hög kvalitet, med kommentarer och indrag.
Exempel pÄ kod frÄn Terraform.
Exempel pÄ kod frÄn Ansible.
Mina herrar, men om allt vore sÄ enkelt! Vi lever i den verkliga vÀrlden, och den Àr alltid redo att överraska dig, att ge dig överraskningar och problem. Det finns inga undantag hÀr.
1. Det första problemet Àr att IaC oftast Àr nÄgon form av dsl.
Och DSL Àr i sin tur en beskrivning av strukturen. Mer specifikt det som du bör ha: Json, Yaml, modifieringar frÄn vissa stora företag som har skapat sin egen dsl (HCL anvÀnds i Terraform).
Problemet Àr att den lÀtt kan sakna sÄdana bekanta saker som:
- variabler;
- villkor;
- ibland saknas kommentarer, till exempel i Json, dÀr de inte Àr förutsedda som standard;
- funktioner;
- och det Àr inte ens det mest avancerade, som klasser, arv och sÄdant.
2. Det andra problemet med sÄdan kod Àr att det oftast Àr en heterogen miljö. Vanligtvis arbetar du och sitter med C#, det vill sÀga med ett sprÄk, en stack, ett ekosystem. HÀr har du ett stort utbud av teknologier.
En ganska verklig situation Àr nÀr en bash-skript med Python kör en process dÀr Json smyger sig in. Du analyserar det, och sedan ger ytterligare en generator ut ytterligare 30 filer. För allt detta kommer ingÄngsvariabler frÄn Azure Key Vault, som hÀmtas av ett plugin till drone.io, skrivet i Go, och dessa variabler gÄr igenom en yaml som genererades av en templator jsonnet. Det Àr ganska svÄrt att ha en tydligt vÀlbeskriven kod nÀr din miljö Àr sÄ varierad.
Traditionell utveckling inom ett enda uppdrag sker med ett sprÄk. HÀr arbetar vi dock med ett stort antal sprÄk.
3. Det tredje problemet Àr verktygen.. Vi Àr vana vid fantastiska redaktörer (Ms Visual Studio, Jetbrains Rider) som gör allt Ät oss. Och Àven om vi gör ett misstag, kommer de att berÀtta att vi har fel. Det verkar vara normalt och naturligt.
Men nÀra till hands finns VSCode, dÀr det finns nÄgra plugins som pÄ nÄgot sÀtt installeras, stöds eller inte stöds. Nya versioner kommer ut och det finns inget stöd för dem. Ett enkelt byte av en funktion (Àven om den finns) blir en svÄr och icke-trivial uppgift. En enkel omdöpning av en variabel betyder att göra en ersÀttning i projektet som omfattar tiotals filer. Man fÄr hoppas att den ersÀtter det som behövs. Det finns sjÀlvklart viss syntaxmarkering, det finns autokomplettering, och nÄgonstans finns det formatering (men jag fick det inte att fungera i Terraform pÄ Windows).
Vid tidpunkten för skrivandet av artikeln har Ànnu inte slÀppts för att stödja version 0.12, Àven om den redan har slÀppts i tre mÄnader.
Det Àr dags att glömma bort...
- Debugging.
- Refactoring verktyg.
- Autokomplettering.
- UpptÀckter av fel vid kompilering.
Det lÄter kanske löjligt, men det ökar faktiskt tiden för utveckling och ökar antalet fel som ofelbart uppstÄr.
Det mest skrÀmmande Àr att vi tvingas tÀnka inte pÄ hur vi ska designa, organisera filer i mappar, dekomponera, göra koden underhÄllbar och lÀsbar, utan hur jag korrekt ska skriva det hÀr kommandot, eftersom jag skrev det pÄ nÄgot sÀtt fel.
Som nybörjare försöker du förstĂ„ Terraform, men IDE:n hjĂ€lper dig inte pĂ„ nĂ„got sĂ€tt. NĂ€r det finns dokumentation â gick in, tittade. Men om du skulle lĂ€ra dig ett nytt programmeringssprĂ„k skulle IDE:n ha föreslagit att det finns en sĂ„dan typ, medan det inte finns en annan. Ă tminstone pĂ„ nivĂ„n av int eller string. Detta Ă€r ofta anvĂ€ndbart.
Men hur Àr det med tester?
Ni frÄga: "Vad sÀger ni om tester, mina herrar programmerare?" Serösa killar testar allt i produktion, och det Àr hÄrt. HÀr Àr ett exempel pÄ en enhetstest för Terraform-modulen frÄn webbplatsen. .
De har bra dokumentation. Microsoft har alltid imponerat pÄ mig med sin instÀllning till dokumentation och utbildning. Men man behöver inte vara farbror Bob för att förstÄ att koden hÀr inte Àr perfekt. Observera valideringen som flyttades Ät höger.
Problemet med enhetstest Àr att vi kan kontrollera korrektheten av JSON pÄ utgÄngen. Jag kastade in 5 parametrar, och fick en JSON-strÀng pÄ 2000 rader. Jag kan analysera vad som hÀnder hÀr, validera testresultatet...
Det Ă€r svĂ„rt att analysera JSON i Go. Men man mĂ„ste skriva i Go, eftersom Terraform Ă€r skrivet i Go â det Ă€r en bra praxis att testa i det sprĂ„k som man skriver i. SjĂ€lva koden Ă€r organiserad mycket svagt. ĂndĂ„ Ă€r detta det bĂ€sta biblioteket för testning.
SjÀlva Microsoft skriver sina moduler och testar dem pÄ detta sÀtt. SjÀlvklart Àr detta Open Source. Allt jag pratar om kan du komma och fixa. Jag kan sÀtta mig ner och fixa allt pÄ en vecka, open sourca plugins till VS Code, Terraform, skapa en plugin för Rider. Kanske skriva ett par analyzers, koppla in linters, bidra till ett testbibliotek. Jag kan göra allt detta. Men jag borde inte syssla med det.
BĂ€sta praxis inom Infrastructure as Code.
Vi gÄr vidare. Om det inte finns tester i IaC, dÄligt med IDE och verktyg, sÄ mÄste det Ätminstone finnas bÀsta praxis. Jag gick helt enkelt in pÄ Google Analytics och gjorde en jÀmförelse av tvÄ sökfrÄgor: Terraform bÀsta praxis och C# bÀsta praxis.
Vad ser vi? En obarmhĂ€rtig statistik som inte gĂ„r i vĂ„r favör. NĂ€r det kommer till mĂ€ngden material â samma sak. Inom C#-utveckling simmar vi helt enkelt i material, vi har superba bĂ€sta praxis, vi har böcker skrivna av experter, och Ă€ven böcker skrivna av andra experter som kritiserar dessa böcker. En överflöd av officiell dokumentation, artiklar, utbildningskurser, och nu Ă€ven Open Source utveckling.
NÀr det kommer till sökfrÄgan om IaC: hÀr försöker ni i smÄ bitar samla information frÄn presentationer av hög belastning eller HashiConf, frÄn officiell dokumentation och mÄnga Àrenden pÄ GitHub. Hur ska man egentligen dela upp dessa moduler, vad ska man göra med dem? Det verkar som en verklig problematik⊠Det finns ju ett community, mina herrar, dÀr man fÄr 10 kommentarer pÄ GitHub för varje frÄga. Men det Àr inte sÀkert.
TyvÀrr börjar experterna just nu dyka upp. Det finns fortfarande för fÄ av dem. Och sjÀlva communityn Àr i ett tidigt skede.
Var Àr allt pÄ vÀg och vad ska man göra
Man kan allt överge och ÄtervÀnda till C#, till rider-vÀrlden. Men nej. Varför skulle ni ens göra det om ni inte letade efter en lösning. HÀr Àr mina subjektiva slutsatser. Ni kan gÀrna diskutera med mig i kommentarerna, det skulle bli intressant.
Personligen satsar jag pÄ flera saker:
- Utvecklingen inom detta omrÄde gÄr mycket snabbt. HÀr Àr en graf över förfrÄgningar om DevOps.
Kanske Ă€r Ă€mnet en hype, men faktumet att omrĂ„det vĂ€xer ger viss hopp.Om nĂ„got vĂ€xer sĂ„ snabbt, kommer det definitivt att dyka upp kloka mĂ€nniskor som sĂ€ger hur man bör göra och inte göra. Ăkande popularitet leder till att kanske nĂ„gon fĂ„r tid att slutligen skriva en plugin till jsonnet för vscode, som gör det möjligt att gĂ„ direkt till implementationen av funktionen, istĂ€llet för att söka efter den via ctrl+shift+f. NĂ€r allt utvecklas, dyker det upp fler material. Utgivningen av boken frĂ„n Google om SRE Ă€r ett utmĂ€rkt exempel.
- Det finns utvecklade metoder och praxis inom vanlig utveckling som vi framgÄngsrikt kan tillÀmpa hÀr. Ja, det finns nyanser med testning och heterogen miljö, bristande verktyg, men en enorm mÀngd praxis har samlats som kan vara anvÀndbar och hjÀlpa.
Ett banalt exempel: samarbete genom pair programming. Det hjÀlper verkligen att förstÄ bÀttre. NÀr du har en granne som ocksÄ försöker förstÄ nÄgot, kommer ni tillsammans att förstÄ bÀttre.
Att förstÄ hur refaktorisering görs hjÀlper Àven i en sÄdan situation att genomföra den. Det vill sÀga, du kan inte förÀndra allt pÄ en gÄng, utan förÀndra namnen först, sedan förÀndra placeringen, och kanske vÀlja ut en del, oops, hÀr saknas kommentarer.
Slutsats
Trots att mina resonemang kan verka pessimistiska, ser jag hoppfullt pÄ framtiden och hoppas verkligen att vi (och ni) kommer att lyckas.
Följande del av artikeln förbereds. I den kommer jag att berÀtta om hur vi försökte tillÀmpa metoder frÄn agil utveckling för att förbÀttra vÄr inlÀrningsprocess och vÄrt arbete med infrastrukturen.
KĂ€lla: habr.com
