Ons bedrijf is bezig met het aanwerven van een SRE-team. Ik kwam in dit hele verhaal terecht vanaf de ontwikkelingskant. Daarbij kwam ik tot gedachten en inzichten die ik met andere ontwikkelaars wil delen. In dit reflectieartikel vertel ik over wat er gebeurt, hoe het gebeurt en hoe iedereen ermee kan blijven leven.
Voortzetting van een reeks artikelen geschreven op basis van toespraken op ons interne evenement :
2. Infrastructuur als code. (Je bent hier)
3. Genereren van Typescript-contracten met behulp van C#-modellen. (Bezig...)
4. Inleiding tot het Raft-consensusalgoritme. (Bezig...)
...
We besloten een SRE-team op te richten dat de ideeën zou implementeren . Ze rekruteerden programmeurs uit hun eigen ontwikkelaars en stuurden ze een aantal maanden op training.
Het team had de volgende trainingstaken:
- Beschrijf onze infrastructuur, die zich grotendeels in Microsoft Azure bevindt in de vorm van code (Terraform en alles daaromheen).
- Leer ontwikkelaars hoe ze met infrastructuur moeten werken.
- Bereid ontwikkelaars voor op hun taak.
We introduceren het concept van infrastructuur als code
In het gebruikelijke wereldmodel (klassiek bestuur) bevindt kennis over infrastructuur zich op twee plaatsen:
- Of in de vorm van kennis in de hoofden van deskundigen.
- Of deze informatie staat op sommige typemachines, waarvan sommige bij experts bekend zijn. Maar het is geen feit dat een buitenstaander (voor het geval ons hele team plotseling overlijdt) kan achterhalen wat werkt en hoe het werkt. Er kan veel informatie op een machine staan: accessoires, cronjobs, geïntimideerd (zie. ) schijf en slechts een eindeloze lijst van wat er kan gebeuren. Het is moeilijk te begrijpen wat er werkelijk gebeurt.
In beide gevallen zitten we vast in de afhankelijkheid:
- of van een persoon die sterfelijk is, onderhevig is aan ziekte, verliefd wordt, stemmingswisselingen en eenvoudigweg banale ontslagen;
- of van een fysiek werkende machine, die ook valt, wordt gestolen en voor verrassingen en ongemakken zorgt.
Het spreekt voor zich dat idealiter alles vertaald zou moeten worden in voor mensen leesbare, onderhoudbare en goed geschreven code.
Infrastructuur als code (Incfastructure as Code - IaC) is dus een beschrijving van de gehele bestaande infrastructuur in de vorm van code, evenals gerelateerde tools om ermee te werken en daaruit echte infrastructuur te implementeren.
Waarom alles in code vertalen?Mensen zijn geen machines. Ze kunnen niet alles onthouden. De reactie van een mens en een machine is verschillend. Alles wat geautomatiseerd is, is potentieel sneller dan alles wat door een mens wordt gedaan. Het allerbelangrijkste is één enkele bron van waarheid.
Waar komen nieuwe SRE-ingenieurs vandaan?Daarom hebben we besloten nieuwe SRE-ingenieurs aan te nemen, maar waar kunnen we die vandaan halen? Boek met juiste antwoorden () vertelt ons: van de ontwikkelaars. Ze werken tenslotte met de code en je bereikt de ideale staat.
We hebben lang naar hen gezocht op de personeelsmarkt buiten ons bedrijf. Maar we moeten toegeven dat we niemand hebben gevonden die aan onze verzoeken voldeed. Ik moest zoeken onder mijn eigen mensen.
Problemen Infrastructuur als code
Laten we nu eens kijken naar voorbeelden van hoe infrastructuur hardgecodeerd kan worden in code. De code is goed geschreven, van hoge kwaliteit, met opmerkingen en inkepingen.
Voorbeeldcode van Terraforma.
Voorbeeldcode van Ansible.
Heren, was het maar zo eenvoudig! We zijn in de echte wereld en die staat altijd klaar om je te verrassen, je voor verrassingen en problemen te stellen. Ook hier kunnen we niet zonder.
1. Het eerste probleem is dat IaC in de meeste gevallen een soort DSL is.
En DSL is op zijn beurt een beschrijving van de structuur. Preciezer gezegd, wat je zou moeten hebben: Json, Yaml, aanpassingen van enkele grote bedrijven die met hun eigen dsl kwamen (HCL wordt gebruikt in terraform).
Het probleem is dat het gemakkelijk niet zulke bekende dingen bevat als:
- variabelen;
- voorwaarden;
- ergens zijn er geen opmerkingen, bijvoorbeeld in Json, deze worden standaard niet verstrekt;
- functies;
- en dan heb ik het niet eens over zaken op hoog niveau als klassen, erfenis en zo.
2. Het tweede probleem met dergelijke code is dat het meestal een heterogene omgeving is. Meestal zit en werk je met C#, d.w.z. met één taal, één stapel, één ecosysteem. En hier heb je een enorme verscheidenheid aan technologieën.
Het is een zeer reële situatie wanneer bash met Python een proces start waarin Json wordt ingevoegd. Je analyseert het, en een andere generator produceert nog eens 30 bestanden. Voor dit alles worden invoervariabelen ontvangen van Azure Key Vault, die worden samengevoegd door een plug-in voor drone.io geschreven in Go, en deze variabelen passeren yaml, die is gegenereerd als resultaat van het genereren van de jsonnet-sjabloonengine. Het is behoorlijk moeilijk om strikt goed beschreven code te hebben als je in zo'n diverse omgeving zit.
Traditionele ontwikkeling binnen het kader van één taak gaat gepaard met één taal. Hier werken wij met een groot aantal talen.
3. Het derde probleem is afstemming. We zijn gewend aan coole editors (Ms Visual Studio, Jetbrains Rider) die alles voor ons doen. En zelfs als we dom zijn, zullen ze zeggen dat we ongelijk hebben. Het lijkt normaal en natuurlijk.
Maar ergens in de buurt is er VSCode, waarin enkele plug-ins zijn die op de een of andere manier zijn geïnstalleerd, ondersteund of niet ondersteund. Er kwamen nieuwe versies uit die niet werden ondersteund. Een banale overgang naar het implementeren van een functie (zelfs als deze bestaat) wordt een complex en niet-triviaal probleem. Een simpele hernoeming van een variabele is een herhaling in een project van een tiental bestanden. Je hebt geluk als hij plaatst wat je nodig hebt. Natuurlijk is er hier en daar achtergrondverlichting, er is automatische aanvulling, ergens is er opmaak (hoewel het voor mij niet werkte in terraform op Windows).
РќР ° РјРѕРјРµРЅС ‚РЅР ° РїРёСЃР ° РЅРёСЏ стР° тьи zijn nog niet vrijgegeven ter ondersteuning van versie 0.12, hoewel deze al drie maanden beschikbaar is.
Het is tijd om te vergeten...
- Debuggen.
- Refactoring-tool.
- Automatische voltooiing.
- Het detecteren van fouten tijdens het compileren.
Het is grappig, maar dit verlengt ook de ontwikkeltijd en verhoogt het aantal fouten dat onvermijdelijk optreedt.
Het ergste is dat we gedwongen worden om niet na te denken over hoe we moeten ontwerpen, bestanden in mappen ordenen, ontleden, de code onderhoudbaar, leesbaar maken, enzovoort, maar over hoe ik dit commando correct kan schrijven, omdat ik het op de een of andere manier verkeerd heb geschreven .
Als beginner probeer je terravormen te leren, en de IDE helpt je helemaal niet. Als er documentatie is, ga dan naar binnen en kijk. Maar als u een nieuwe programmeertaal zou invoeren, zou de IDE u vertellen dat er zo'n type bestaat, maar zoiets bestaat niet. Tenminste op int- of stringniveau. Dit is vaak handig.
Hoe zit het met de testen?
Je vraagt: “Hoe zit het met de tests, heren programmeurs?” Serieuze jongens testen alles tijdens de productie, en het is zwaar. Hier is een voorbeeld van een unit-test voor een terraform-module van de website .
Ze hebben goede documentatie. Ik heb Microsoft altijd gewaardeerd vanwege de benadering van documentatie en training. Maar je hoeft geen oom Bob te zijn om te begrijpen dat dit geen perfecte code is. Let op de validatie aan de rechterkant.
Het probleem met een unittest is dat jij en ik de juistheid van de Json-uitvoer kunnen controleren. Ik gooide 5 parameters in en kreeg een Json-voetdoek met 2000 lijnen. Ik kan analyseren wat hier aan de hand is, het testresultaat valideren...
Het is moeilijk om Json in Go te parseren. En je moet in Go schrijven, omdat terraform in Go een goede gewoonte is om te testen in de taal waarin je schrijft. De organisatie van de code zelf is erg zwak. Tegelijkertijd is dit de beste bibliotheek om te testen.
Microsoft schrijft zelf zijn modules en test ze op deze manier. Natuurlijk is het Open Source. Alles waar ik het over heb, kun je komen repareren. Ik kan gaan zitten en alles in een week repareren, open source VS-code-plug-ins, terraforms, een plug-in maken voor de rijder. Misschien een paar analysers schrijven, linters toevoegen, een bibliotheek bijdragen om te testen. Ik kan alles. Maar dat is niet wat ik zou moeten doen.
Best practices Infrastructuur als code
Laten we verder gaan. Als er geen tests in IaC zijn, de IDE en de afstemming slecht zijn, dan zouden er op zijn minst best practices moeten zijn. Ik ging gewoon naar Google Analytics en vergeleek twee zoekopdrachten: Terraform best practices en c# best practices.
Wat zien we? Meedogenloze statistieken zijn niet in ons voordeel. De hoeveelheid materiaal is hetzelfde. Bij de ontwikkeling van C# worden we eenvoudigweg overspoeld met materialen, we hebben superbest practices, er zijn boeken geschreven door experts, en ook boeken die over boeken zijn geschreven door andere experts die die boeken bekritiseren. Een zee aan officiële documentatie, artikelen, trainingen en nu ook open source-ontwikkeling.
Wat betreft het IaC-verzoek: hier probeer je beetje bij beetje informatie te verzamelen uit highload- of HashiConf-rapporten, uit officiële documentatie en talloze problemen op Github. Hoe deze modules in het algemeen te distribueren, wat ermee te doen? Het lijkt erop dat dit een echt probleem is... Er is een community, heren, waar u voor elke vraag 10 reacties op Github krijgt. Maar dat is het niet precies.
Helaas beginnen op dit moment de deskundigen nog maar net op te duiken. Tot nu toe zijn dat er te weinig. En de gemeenschap zelf hangt rond op het rudimentaire niveau.
Waar gaat dit allemaal heen en wat te doen
Je kunt alles laten vallen en teruggaan naar C#, naar de wereld van de rijder. Maar nee. Waarom zou je dit überhaupt doen als je geen oplossing kunt vinden? Hieronder presenteer ik mijn subjectieve conclusies. Je kunt met mij discussiëren in de reacties, het zal interessant zijn.
Persoonlijk gok ik op een paar dingen:
- De ontwikkeling op dit gebied gaat zeer snel. Hier vindt u een schema met aanvragen voor DevOps.
Het onderwerp mag dan een hype zijn, maar juist het feit dat de sfeer groeit geeft enige hoop.Als iets zo snel groeit, zullen er zeker slimme mensen verschijnen die je zullen vertellen wat je wel en niet moet doen. De toename in populariteit leidt ertoe dat iemand misschien tijd heeft om eindelijk een plug-in aan jsonnet toe te voegen voor vscode, waarmee je verder kunt gaan met het implementeren van de functie, in plaats van ernaar te zoeken via ctrl+shift+f. Naarmate de dingen evolueren, verschijnen er meer materialen. De uitgave van een boek van Google over SRE is hiervan een uitstekend voorbeeld.
- Er zijn ontwikkelde technieken en praktijken in conventionele ontwikkeling die we hier met succes kunnen toepassen. Ja, er zijn nuances met testen en een heterogene omgeving, onvoldoende tools, maar er is een groot aantal praktijken verzameld die nuttig en nuttig kunnen zijn.
Een triviaal voorbeeld: samenwerking via pair programming. Het helpt enorm om het uit te zoeken. Als je een buurman in de buurt hebt die ook iets probeert te begrijpen, zul je samen beter begrijpen.
Als u begrijpt hoe refactoring wordt uitgevoerd, kunt u dit zelfs in een dergelijke situatie uitvoeren. Dat wil zeggen, je kunt niet alles in één keer veranderen, maar verander de naamgeving, verander dan de locatie, dan kun je een deel markeren, oh, maar er zijn hier niet genoeg opmerkingen.
Conclusie
Ondanks dat mijn redenering misschien pessimistisch lijkt, kijk ik hoopvol naar de toekomst en hoop ik oprecht dat alles goed zal komen voor ons (en jou).
Het tweede deel van het artikel wordt hierna voorbereid. Daarin zal ik het hebben over hoe we agile ontwikkelingspraktijken probeerden te gebruiken om ons leerproces te verbeteren en met infrastructuur te werken.
Bron: www.habr.com