Infrastructure as Code: hoe problemen te overwinnen met XP

Hallo, Habr! Eerder klaagde ik over het leven in de paradigma van Infrastructure as code en bood ik niets aan om de bestaande situatie op te lossen. Vandaag ben ik terug om te vertellen welke benaderingen en praktijken kunnen helpen om uit de afgrond van wanhoop te geraken en de situatie de juiste richting op te sturen.

In het vorige artikel «Infrastructure as code: een eerste kennismaking» deed ik mijn indrukken van dit gebied uit de doeken, dacht ik na over de huidige situatie in dit domein en stelde ik zelfs voor dat de standaard, bekende praktijken voor ontwikkelaars zouden kunnen helpen. Het kan lijken alsof er veel geklaagd werd over het leven, maar er waren geen voorstellen voor een uitweg uit de bestaande situatie.

Wie zijn wij, waar zijn we en welke problemen hebben we

Momenteel bevinden we ons in het SRE Onboarding Team, dat bestaat uit zes programmeurs en drie infrastructuur engineers. Allen proberen we Infrastructure as code (IaC) te schrijven. We doen dit omdat we in principe in staat zijn om code te schrijven en in onze geschiedenis zijn we ontwikkelaars van ‘boven gemiddeld’ niveau.

• We hebben een aantal voordelen: een bepaalde achtergrond, kennis van praktijken, het vermogen om code te schrijven en de wens om nieuwe dingen te leren.
• En er is een zwak punt, namelijk: gebrek aan kennis van de materie van de infrastructuur.

De technologie stack die we in onze IaC gebruiken.

• Terraform voor het maken van resources.
• Packer voor het bouwen van images. Dit zijn Windows, CentOS 7 afbeeldingen.
• Jsonnet, om krachtige builds te maken in drone.io, en ook voor het genereren van packer json en onze Terraform-modules.
• Azure.
• Ansible bij het bereiden van images.
• Python voor ondersteunende services, evenals provisioning-scripts.
• En dit alles in VSCode met plug-ins die gedeeld worden tussen de teamleden.

De conclusie van mijn vorige artikel was: ik probeerde (vooral mezelf) optimisme in te boezemen, wilde zeggen dat we de benaderingen en praktijken die we kennen zullen proberen om de moeilijkheden en complicaties waarmee we in dit domein geconfronteerd worden, te bestrijden.

Momenteel worstelen we met de volgende problemen in IaC:

• Onvolmaaktheid van de tools, middelen voor de ontwikkeling van code.
• Langzaam uitrollen. Infrastructuur is een deel van de echte wereld, en die kan traag zijn.
• Tekort aan benaderingen en praktijken.
• We zijn nieuw en weten veel niet.

Extreme programming (XP) komt te hulp

Alle ontwikkelaars zijn goed bekend met extreme programmeren (XP) en de achterliggende praktijken. Velen van ons hebben op deze manier gewerkt en het was succesvol. Waarom zouden we de principes en praktijken die daar zijn gelegd niet gebruiken om de problemen van de infrastructuur te overwinnen? We hebben besloten deze benadering toe te passen en te zien wat eruit komt.

Controleer de toepasbaarheid van de XP-aanpak voor uw domein.Hier is een beschrijving van de omgeving waarvoor XP goed geschikt is, en hoe dit zich verhoudt tot ons:

1. Dynamisch veranderende softwarevereisten. Het was ons duidelijk wat het uiteindelijke doel was. Maar in de details kan er variatie zijn. We beslissen zelf waar we heen moeten, dus de vereisten veranderen af en toe (voornamelijk door onszelf). Als we kijken naar het SRE-team dat zelf automatiseert en zelf de vereisten en scope van het werk beperkt, dan valt dit punt goed op zijn plaats.

2. Risico's veroorzaakt door projecten met vastgestelde tijd die nieuwe technologie gebruiken. We kunnen risico's tegenkomen bij het gebruik van dingen die ons onbekend zijn. En dit is 100% ons geval. Ons hele project gaat over het gebruik van technologieën waarmee we niet volledig bekend waren. Dit is een constant probleem, omdat er voortdurend nieuwe technologieën in de infrastructuur verschijnen.

3,4. Klein, co-locatief, uitgebreid ontwikkelingsteam. De technologie die je gebruikt staat geautomatiseerde eenheidstests en functionele tests toe. Deze twee punten passen niet helemaal bij ons. Ten eerste zijn we geen co-locatie team, ten tweede zijn we met negen mensen, wat als een groot team kan worden beschouwd. Hoewel, volgens bepaalde definities van een 'groot' team, veel al 14+ mensen is.

Laten we enkele praktijken uit XP bekijken en hoe ze de snelheid en kwaliteit van feedback beïnvloeden.

Het principe van feedbackcyclus in XP

In mijn begrip is feedback het antwoord op de vraag of ik het goed doe, of we de juiste kant op gaan? In XP is er een goddelijke schema hierover: de feedbackcyclus in de tijd. Het interessante is dat hoe dieper we zijn, hoe sneller we toegang hebben tot feedback om de noodzakelijke vragen te beantwoorden.

Dit is een vrij interessant onderwerp om te bespreken, dat het in onze IT-industrie mogelijk is om snel feedback te krijgen. Stel je voor hoe pijnlijk moeilijk het is om een project zes maanden te doen en pas dan te ontdekken dat er vanaf het begin een fout is gemaakt. Dit gebeurt zowel bij het ontwerpen als bij het bouwen van complexe systemen.

In ons geval help feedback ons met IaC. Ik breng meteen een kleine aanpassing aan in het bovenstaande schema: de releaseplanning heeft geen maandelijkse cyclus, maar vindt meerdere keren per dag plaats. Aan deze cyclus zijn bepaalde praktijken verbonden die we uitgebreider zullen bespreken.

Belangrijk: feedback kan een oplossing zijn voor alle eerder genoemde problemen. In combinatie met XP-praktijken kan het ons uit de afgrond van wanhoop halen.

Hoe jezelf uit de afgrond van wanhoop te halen: drie praktijken

Tests

Tests worden twee keer genoemd in de feedbackcyclus van XP. Dit is niet zonder reden. Ze zijn van cruciaal belang voor de hele techniek van Extreme Programming.

Er wordt verondersteld dat je unit- en acceptatietests hebt. De ene geeft je feedback in enkele minuten, de andere in enkele dagen, omdat deze langer worden geschreven en minder vaak worden uitgevoerd.

Er is een klassieke testpiramide die laat zien dat er meer van bepaalde tests moeten zijn.

Hoe is dit schema van toepassing op ons project IaC? Eigenlijk… helemaal niet.

• Er kunnen, ondanks dat er veel van moeten zijn, niet te veel unit tests zijn. Of ze testen iets zeer indirect. Eigenlijk kun je zeggen dat we ze helemaal niet schrijven. Maar er zijn enkele toepassingen voor zulke tests die we toch hebben kunnen maken:
  1. Code testen op jsonnet. Dit is bijvoorbeeld onze bouwpipeline in drone, die behoorlijk complex is. Code op jsonnet is goed testbaar.
     We gebruiken deze Unit testing framework voor Jsonnet.
  2. Tests voor scripts die worden uitgevoerd bij het starten van de bron. Scripts in Python, wat betekent dat we ook tests daarvoor kunnen schrijven.
• Potentieel is het mogelijk om configuratie in tests te controleren, maar we doen dat niet. Er is ook de mogelijkheid om regels voor het configureren van bronnen te controleren via tflint. Echter, simpelweg voor Terraform zijn de controles daar te basaal, maar er zijn veel testscenario's geschreven voor AWS. We zijn echter op Azure, dus dat is weer niet geschikt.
• Componentintegratietests: dit hangt af van hoe je ze classificeert en hoe je ze indeelt. Maar ze werken in principe.

  Zo zien de integratietests eruit.

  
  
  Dit is een voorbeeld bij het bouwen van afbeeldingen in Drone CI. Om deze te bereiken, moet je 30 minuten wachten tot het Packer-image is opgebouwd, en dan nog eens 15 minuten wachten tot ze zijn doorlopen. Maar ze zijn er!

  Algoritme voor het controleren van afbeeldingen

  1. Eerst moet Packer het image volledig voorbereiden.
  2. Naast de test is er een Terraform met lokale status, waarmee we dit beeld uitrollen.
  3. Bij het uitrollen wordt een klein module gebruikt dat naast ligt, zodat het eenvoudiger is om met het beeld te werken.
  4. Wanneer de VM vanuit het beeld is uitgerold, kunnen we beginnen met de controles. Meestal worden de controles op de machine uitgevoerd. We controleren hoe de scripts werken bij de opstart, en hoe de daemon's functioneren. Hiervoor loggen we via SSH of WinRM in op de net opgezette machine en controleren de configuratiestatus of de services zijn opgestart.

• Een soortgelijke situatie geldt voor integratietests en in de modules voor Terraform. Hier is een korte tabel die de kenmerken van dergelijke tests toelicht.

  
  
  De feedback op de pipeline is ongeveer 40 minuten. Het gaat allemaal heel traag. Het kan worden gebruikt voor regressie, maar voor nieuwe ontwikkeling is het gewoon niet haalbaar. Als je hier heel goed op voorbereid bent, running scripts voorbereidt, kan het tot 10 minuten worden ingekort. Maar het zijn nog steeds geen Unit-tests die in 5 seconden 100 keer draaien.

Het ontbreken van Unit-tests bij het bouwen van beelden of modules in Terraform leidt ertoe dat het werk wordt verschoven naar aparte services, die je gewoon via REST kunt aanspreken, of naar Python-scripts.

Bijvoorbeeld, we moesten ervoor zorgen dat bij het opstarten van de virtuele machine deze zichzelf registreerde bij de service ScaleFT, en bij het vernietigen van de virtuele machine zichzelf verwijderde.

Aangezien ScaleFT als een service werkt, zijn we gedwongen om met de API te werken. Er was een wrapper geschreven die je kunt aanroepen en zeggen: "Ga en verwijder dit en dat". Het bewaart alle noodzakelijke instellingen en toegangen.

Hierop kunnen we normaal gesproken testen schrijven, aangezien het niet verschilt van gewone software: een API wordt gemockt, je roept het aan en we kijken wat er gebeurt.

Resultaten van de tests: Unit-testing die in een minuut door het OS moet worden gegeven, doet dat niet. Hogere testniveaus geven effect, maar dekken slechts een deel van de problemen.

Pair programming

Tests zijn natuurlijk goed. Je kunt er veel schrijven, ze kunnen van verschillende soorten zijn. Ze zullen op hun niveaus werken en ons feedback geven. Maar het probleem met slechte unit tests, die de snelste OS opleveren, blijft bestaan. Toch blijft de wens voor een snelle OS bestaan; het werkt gemakkelijk en fijn. Niet te spreken over de kwaliteit van de oplossing die je krijgt. Gelukkig zijn er technieken waarmee je nog snellere feedback kunt krijgen dan met modul tests. Dit is de focus van pair programming.

Bij het schrijven van code wil je zo snel mogelijk feedback krijgen over de kwaliteit ervan. Ja, je kunt alles in een feature-branch schrijven (om niemand te verstoren), een pull request in GitHub doen, iemand aanwijzen wiens mening zwaar weegt, en op een reactie wachten.

Maar wachten kan lang duren. Mensen zijn allemaal druk, en de reactie, zelfs als deze komt, is misschien niet van de hoogste kwaliteit. Stel je voor dat de reactie meteen kwam, de reviewer de hele opzet onmiddellijk begreep, maar de feedback komt toch met vertraging, post factum. En je wilt het eerder. Pair programming is er precies op gericht – zodat je het meteen, op het moment van schrijven, kunt krijgen.

Hieronder geef ik de stijlen van pair programming en hun toepasbaarheid in het werken met IaC:

1. Classic, Ervaren+ervaren, wisselen op basis van een timer. Twee rollen – driver en navigator. Twee mensen. Ze werken aan dezelfde code en wisselen van rol na een vooraf bepaalde tijdsperiode.

Laten we de compatibiliteit van onze problemen met de stijl bekijken:

• Probleem: onvolkomenheden in de tools, middelen voor het ontwikkelen van code.
  Negatief effect: langer ontwikkelen, we vertragen, het werktempo/rhythm gaat verloren.
  Hoe we het bestrijden: we gebruiken andere tooling, een gezamenlijke IDE en leren ook shortcuts.
• Probleem: trage implementatie.
  Negatief effect: verhoogt de tijd die nodig is om een werkend stuk code te creëren. We vervelen ons terwijl we wachten, en de handen willen iets anders gaan doen terwijl je wacht.
  Hoe we het bestrijden: we hebben het probleem niet opgelost.
• Probleem: gebrek aan benaderingen en praktijken.
  Negatief effect: je hebt geen kennis over wat goed of slecht is. Dit verlengt de tijd voor feedback.
  Hoe we het bestrijden: wederzijdse uitwisseling van meningen en praktijken in pair programming lost het probleem bijna op.

Het grootste probleem bij het toepassen van deze stijl in IaC is het onregelmatige werktempo. Bij traditionele softwareontwikkeling beweeg je vrij gelijkmatig. Je kunt vijf minuten besteden en N schrijven. Tien minuten besteden en 2N schrijven, vijftien minuten – 3N. Hier kun je vijf minuten besteden en N schrijven, en daarna dertig minuten besteden om een tiende van N te schrijven. Je weet hier niets, je komt vast te zitten. Het uitzoeken kost tijd en haalt je af van het programmeren.

Conclusie: in zijn pure vorm is het niet geschikt voor ons.

2. Ping-pong. Deze aanpak houdt in dat één deelnemer de test schrijft en de andere deze implementeert. Gezien het feit dat het schrijven van unit-tests moeilijk is en je tijdrovende integratietests moet schrijven, verdwijnt het gemak van ping-pong.

Ik kan zeggen dat we geprobeerd hebben om verantwoordelijkheden te scheiden voor het ontwerpen van de testscenario's en het implementeren van de code. Eén deelnemer bedacht het scenario, en voor dat deel van het werk was hij verantwoordelijk, hij had het laatste woord. De ander was verantwoordelijk voor de implementatie. Dit werkte goed. De kwaliteit van het scenario neemt toe met deze aanpak.

Conclusie: helaas laat het werktempo geen ruimte voor ping-pong als praktijk van paired programming binnen IaC.

3. Strong Style. Complexe praktijk.Het idee is dat één deelnemer de sturende navigator wordt, terwijl de ander de uitvoerende driver speelt. Hierbij ligt het recht om beslissingen te nemen uitsluitend bij de navigator. De driver typt alleen en kan met woorden invloed uitoefenen op wat er gebeurt. De rollen veranderen gedurende lange tijd niet.

Deze methode is goed voor het leren, maar vereist sterke soft skills. Daar zijn we ook op vastgelopen. De techniek ging moeizaam. En het ligt niet eens aan de infrastructuur.

Conclusie: potentieel toepasbaar, we geven het niet op.

4. Mobbing, swarming en alle bekende, maar hier niet vermelde stijlen. worden niet overwogen, omdat we ze niet hebben geprobeerd en we kunnen er niets over zeggen in de context van ons werk.

Algemene conclusies over het gebruik van pair programming:

• We hebben een onregelmatig werktempo, wat ons uit de balans brengt.
• We zijn gestuit op onvoldoende goede soft skills. En het onderwerp helpt niet om deze tekortkomingen te overwinnen.
• Lange tests en problemen met de tools maken pair programming moeizaam.

5. Desondanks waren er ook successen. We hebben onze eigen methode 'Convergentie - divergentie' bedacht. Ik beschrijf kort hoe het werkt.

We hebben vaste partners voor een paar dagen (minder dan een week). We werken samen aan een taak. Een tijdje zitten we samen: de één schrijft, de ander kijkt toe als een ondersteunend team. Daarna gaan we even uit elkaar, doet ieder zijn eigen dingen, en dan komen we weer snel samen, synchroniseren, doen iets samen en gaan weer uit elkaar.

Planning en communicatie

De laatste blok van praktijken waarmee problemen van het besturingssysteem worden opgelost, betreft de organisatie van het werk met de taken zelf. Dit omvat ook de uitwisseling van ervaringen die buiten de duo-werking ligt. Laten we drie praktijken bekijken:

1. Taken via een doelboom. We hebben de algehele projectleiding georganiseerd via een boom die eindeloos naar de toekomst reikt. Technisch gezien gebeurt het beheer in Miro. Er is één taak - dit is een tussenliggende doelstelling. Hieruit komen ofwel kleinere doelstellingen ofwel groepen van taken. Van hen komen dan de daadwerkelijke taken. Alle taken worden aangemaakt en beheerd op dit bord.

Deze schema biedt ook feedback, die één keer per dag plaatsvindt wanneer we synchroniseren tijdens vergaderingen. De aanwezigheid van een gemeenschappelijk plan voor iedereen, dat gestructureerd en volledig open is, stelt iedereen in staat om op de hoogte te zijn van wat er gebeurt en hoe ver we gevorderd zijn in de voortgang.

Voordelen van visuele taakweergave:

• Causaliteit. Elke taak leidt tot een bepaalde mondiale doelstelling. Taken worden gegroepeerd op basis van kleinere doelen. Het domein van infrastructuur is op zichzelf vrij technisch. Het is niet altijd meteen duidelijk welk specifiek effect het schrijven van een migratie-handboek voor een andere nginx op de business heeft. Het hebben van een doelkaart ernaast maakt dit duidelijker.
  
  Causaliteit is een belangrijk kenmerk van taken. Het beantwoordt rechtstreeks de vraag: 'Doe ik wel het juiste?'
• Parallelisme. We zijn met negen mensen, en het is simpelweg fysiek onmogelijk voor iedereen om zich op één taak te storten. Taken uit één enkel domein zijn ook niet altijd voldoende. We delen het werk noodgedwongen op tussen kleine werkgroepen. Deze groepen werken enige tijd aan hun taak en kunnen door anderen versterkt worden. Soms vallen er mensen uit deze werkgroep weg. Iemand gaat op vakantie, iemand anders maakt een presentatie voor de DevOps-conferentie, weer iemand anders schrijft een artikel voor Habr. Het wordt erg belangrijk om te weten welke doelen en taken parallel kunnen worden uitgevoerd.

2. Wisselende voorzitters van de ochtendvergaderingen. Bij de stand-ups ontstond een probleem – veel taken worden parallel uitgevoerd door mensen. Soms zijn de taken slecht met elkaar verbonden en ontbreekt het aan inzicht in wie wat doet. De mening van een ander teamlid is erg belangrijk. Dit is aanvullende informatie die het verloop van de taak kan veranderen. Natuurlijk is er meestal iemand bij je in de groep, maar advies en hints zijn nooit overbodig.

Om deze situatie te verbeteren, hebben we de techniek "Wisselende voorzitter van de stand-up" toegepast. Nu draaien ze rond volgens een bepaalde lijst, en dat heeft zijn effect. Wanneer jouw beurt aanbreekt, moet je je verdiepen en begrijpen wat er aan de hand is, zodat je de scrummeting goed kunt leiden.

3. Interne demo. Hulp bij het oplossen van taken door pair programming, visualisatie in een takenboom en ondersteuning tijdens de scrummeting in de ochtend – dat is goed, maar niet perfect. In een paar ben je beperkt tot je eigen kennis. De takenboom helpt om globaal te begrijpen wie wat doet. Maar de voorzitter en collega's tijdens de ochtendvergadering zullen niet diep in jouw problemen duiken. Ze kunnen zeker iets missen.

De oplossing werd gevonden in het demonstreren van het werk aan elkaar en het daaropvolgende bespreken ervan. We komen wekelijks een uur bijeen en tonen de details van de oplossingen voor de taken die we de afgelopen week hebben gedaan.

Tijdens de demonstratie moet je de details van de taak onthullen en zeker het werk ervan demonstreren.

De presentatie kan volgens een checklist worden gehouden.1. Breng in context. Waar komt de taak vandaan, waarom was dit überhaupt nodig?

2. Hoe werd de taak eerder opgelost? Bijvoorbeeld, was er massaal klikken met de muis nodig, of was het überhaupt onmogelijk iets te doen?

3. Hoe verbeteren we dit. Bijvoorbeeld: "Kijk, nu is er een scriptje, hier is de README."

4. Laat zien hoe het werkt. Bij voorkeur, voer een gebruikersscenario direct uit. Ik wil X, doe Y, zie Z. Bijvoorbeeld, ik deploy NGINX, controleer de url, ontvang 200 OK. Als de actie lang duurt, bereid het dan van tevoren voor, zodat je het later kunt laten zien. Het is wenselijk om een uur voor de demo niet meer te breken, vooral als het kwetsbaar is.

5. Leg uit hoe succesvol de probleemoplossing is, welke moeilijkheden er zijn blijven bestaan, wat nog niet is afgerond, en welke verbeteringen in de toekomst mogelijk zijn. Bijvoorbeeld, nu is het cli, later zal er volledige automatisering in CI zijn.

Bij voorkeur moet elke spreker zich houden aan 5-10 minuten. Als jouw presentatie duidelijk belangrijk is en meer tijd in beslag zal nemen, stem dit dan van tevoren af in het sre-takeover kanaal.

Na het fysieke deel volgt altijd een discussie in de thread. Hier komt de benodigde feedback over onze taken naar voren.

Aan het einde wordt er een enquête gehouden om de nuttigheid van wat er gebeurt te bepalen. Dit is al feedback over de essentie van de presentatie en de belangrijkheid van de taak.

Lange conclusies en wat verder

Het kan lijken dat de toon van het artikel wat pessimistisch is. Dat is niet het geval. De twee basale niveaus van feedback, namelijk tests en paired programming, werken. Niet perfect, zoals in traditionele ontwikkeling, maar er is een positief effect.

Tests, in hun huidige vorm, bieden slechts gedeeltelijke codecoverage. Veel configuratiefuncties blijken niet getest te zijn. Hun invloed op de directe werkzaamheden bij het coderen is laag. Maar het effect van integratietests is daar, en zij stellen ons in staat om zonder angst te refactoren. Dit is een grote prestatie. Bovendien, met de verschuiving van de focus naar ontwikkeling in high-level talen (wij gebruiken python en go) verdwijnt het probleem. En met het 'lijm' zijn er veel checks nodig en dat is niet nodig, algemene integratietests zijn voldoende.

Het werken in paren hangt meer af van de specifieke mensen. Er is de factor van de taak en onze soft skills. Met sommige mensen gaat het heel goed, met anderen minder. De voordelen zijn er zeker. Het is duidelijk dat zelfs bij onvoldoende naleving van de regels voor paired work, de feitelijke samenwerking bij het uitvoeren van taken een positieve invloed heeft op de kwaliteit van het resultaat. Persoonlijk werkt het voor mij eenvoudiger en aangenamer in een paar.

Hogere niveaus van invloed op het OS – planning en takenbeheer zorgen zeker voor effecten: kwalitatieve kennisuitwisseling en verbetering van de ontwikkelingskwaliteit.

Korte conclusies in één zin

• XP-praktijken werken in IaC, maar met lagere efficiëntie.
• Versterk wat werkt.
• Bedenk je eigen compenserende mechanismen en praktijken.

Bron: habr.com