Infrastructuur als code: hoe u problemen kunt overwinnen met XP

Hallo, Habr! Eerder klaagde ik over het leven in de Infrastructuur als codeparadigma en bood ik niets aan om de huidige situatie op te lossen. Vandaag ben ik terug om je te vertellen welke benaderingen en praktijken je zullen helpen te ontsnappen uit de afgrond van wanhoop en de situatie in de goede richting te sturen.

In het vorige artikel "Infrastructuur als code: eerste kennismaking" Ik deelde mijn indrukken op dit gebied, probeerde na te denken over de huidige situatie op dit gebied en suggereerde zelfs dat standaardpraktijken die bij alle ontwikkelaars bekend zijn, zouden kunnen helpen. Het lijkt misschien dat er veel klachten waren over het leven, maar er waren geen voorstellen voor een uitweg uit de huidige situatie.

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

Momenteel zitten we in het Sre Onboarding Team, dat bestaat uit zes programmeurs en drie infrastructuur engineers. We proberen allemaal infrastructuur als code (IaC) te schrijven. We doen dit omdat we in principe weten hoe we code moeten schrijven en een geschiedenis hebben als ‘bovengemiddelde’ ontwikkelaars.

• We hebben een aantal voordelen: een bepaalde achtergrond, kennis van praktijken, het vermogen om code te schrijven, een verlangen om nieuwe dingen te leren.
• En er is een verzakkend deel, dat ook een minpunt is: gebrek aan kennis over infrastructuurhardware.

De technologiestapel die we gebruiken in onze IaC.

• Terraform voor het maken van bronnen.
• Packer voor het samenstellen van afbeeldingen. Dit zijn Windows, CentOS 7-afbeeldingen.
• Jsonnet om een ​​krachtige build in drone.io te maken, en om packer json en onze terraform-modules te genereren.
• Azure.
• Ansible bij het voorbereiden van afbeeldingen.
• Python voor hulpdiensten en inrichtingsscripts.
• En dit alles in VSCode met plug-ins die worden gedeeld tussen teamleden.

Conclusie uit mijn laatste artikel was als volgt: ik probeerde (in de eerste plaats bij mezelf) optimisme bij te brengen, ik wilde zeggen dat we de ons bekende benaderingen en praktijken zullen uitproberen om om te gaan met de moeilijkheden en complexiteiten die op dit gebied bestaan.

We kampen momenteel met de volgende IaC-problemen:

• Imperfectie van tools en middelen voor codeontwikkeling.
• Langzame implementatie. Infrastructuur maakt deel uit van de echte wereld en kan traag zijn.
• Gebrek aan benaderingen en praktijken.
• Wij zijn nieuw en weten nog niet veel.

Extreme Programming (XP) schiet te hulp

Alle ontwikkelaars zijn bekend met Extreme Programming (XP) en de praktijken die erachter schuilgaan. Velen van ons hebben met deze aanpak gewerkt, en het is succesvol geweest. Dus waarom zouden we de principes en praktijken die daar zijn vastgelegd niet gebruiken om uitdagingen op het gebied van de infrastructuur te overwinnen? We besloten deze aanpak te volgen en te kijken wat er gebeurt.

Het controleren van de toepasbaarheid van de XP-aanpak op uw brancheHier volgt een beschrijving van de omgeving waarvoor XP zeer geschikt is, en hoe dit op ons van toepassing is:

1. Dynamisch veranderende softwarevereisten. Het was ons duidelijk wat het einddoel was. Maar de details kunnen variëren. Wij bepalen zelf waar we moeten taxiën, waardoor de eisen periodiek veranderen (voornamelijk door onszelf). Als we het SRE-team nemen, dat zelf de automatisering doet, en zelf de vereisten en reikwijdte van het werk beperkt, dan past dit punt goed.

2. Risico's veroorzaakt door tijdelijke projecten waarbij gebruik wordt gemaakt van nieuwe technologie. We kunnen risico's tegenkomen als we bepaalde dingen gebruiken die ons onbekend zijn. En dit is 100% ons geval. Ons hele project bestond uit het gebruik van technologieën waar we nog niet helemaal bekend mee waren. Over het algemeen is dit een voortdurend probleem, omdat... Er ontstaan ​​voortdurend veel nieuwe technologieën in de infrastructuursector.

3,4. Klein, gezamenlijk gevestigd uitgebreid ontwikkelingsteam. De geautomatiseerde technologie die u gebruikt, maakt unit- en functionele tests mogelijk. Deze twee punten bevallen ons niet helemaal. Ten eerste zijn we geen gecoördineerd team, en ten tweede zijn we met zijn negenen, wat als een groot team kan worden beschouwd. Hoewel, volgens sommige definities van een ‘groot’ team, veel uit 14+ mensen bestaat.

Laten we eens kijken naar enkele XP-praktijken en hoe deze de snelheid en kwaliteit van feedback beïnvloeden.

XP Feedback Loop-principe

Naar mijn mening is feedback het antwoord op de vraag: doe ik het juiste, gaan we daarheen? XP heeft hiervoor een goddelijk plan: een tijdfeedbacklus. Het interessante is dat hoe lager we zijn, hoe sneller we het besturingssysteem de nodige vragen kunnen laten beantwoorden.

Dit is een nogal interessant discussieonderwerp, dat het in onze IT-industrie mogelijk is om snel een besturingssysteem te krijgen. Stel je voor hoe pijnlijk het is om een ​​project zes maanden te doen en er dan pas achter te komen dat er in het begin een fout is gemaakt. Dit gebeurt bij het ontwerp en bij elke constructie van complexe systemen.

In ons geval van IaC helpt feedback ons. Ik doe meteen een kleine aanpassing in bovenstaand schema: het releaseplan kent geen maandelijkse cyclus, maar komt meerdere keren per dag voor. Er zijn enkele praktijken verbonden aan deze OS-cyclus die we in meer detail zullen bekijken.

Belangrijk: feedback kan een oplossing zijn voor alle bovengenoemde problemen. Gecombineerd met XP-praktijken kan het je uit de afgrond van wanhoop trekken.

Hoe je jezelf uit de afgrond van de wanhoop kunt trekken: drie praktijken

Testen

Tests worden tweemaal vermeld in de XP-feedbacklus. Het is niet zomaar zo. Ze zijn uiterst belangrijk voor de gehele Extreme Programming-techniek.

Er wordt van uitgegaan dat je eenheids- en acceptatietesten hebt. Sommige geven je binnen een paar minuten feedback, andere binnen een paar dagen, waardoor het schrijven langer duurt en ze minder vaak worden beoordeeld.

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

Hoe is dit raamwerk op ons van toepassing in een IaC-project? Eigenlijk... helemaal niet.

• Unit-tests kunnen, ondanks het feit dat het er veel zouden moeten zijn, niet te veel zijn. Of ze testen iets heel indirect. We kunnen zelfs zeggen dat we ze helemaal niet schrijven. Maar hier zijn een paar toepassingen voor dergelijke tests die we hebben kunnen doen:
  1. Jsonnet-code testen. Dit is bijvoorbeeld onze drone-assemblagepijplijn, die behoorlijk ingewikkeld is. De jsonnet-code wordt goed gedekt door tests.
     Wij gebruiken dit Eenheidstestframework voor Jsonnet.
  2. Tests voor scripts die worden uitgevoerd wanneer de bron start. Scripts zijn geschreven in Python en daarom kunnen er tests op worden geschreven.
• Het is eventueel mogelijk om de configuratie in tests te controleren, maar dat doen wij niet. Het is ook mogelijk om configuratieregels voor controlebronnen te configureren via tflint. De controles daar zijn echter simpelweg te basaal voor terraform, maar veel testscripts zijn geschreven voor AWS. En we gebruiken Azure, dus dit is opnieuw niet van toepassing.
• Componentintegratietests: het hangt ervan af hoe je ze classificeert en waar je ze neerzet. Maar in principe werken ze.

  Zo zien integratietesten eruit.

  
  
  Dit is een voorbeeld bij het bouwen van afbeeldingen in Drone CI. Om ze te bereiken, moet je 30 minuten wachten totdat het Packer-beeld is gevormd en vervolgens nog eens 15 minuten wachten totdat ze voorbij zijn. Maar ze bestaan!

  Algoritme voor beeldverificatie

  1. Packer moet de afbeelding eerst volledig voorbereiden.
  2. Naast de test is er een terraform met een lokale status, die we gebruiken om deze afbeelding in te zetten.
  3. Bij het uitvouwen wordt een kleine module gebruikt die vlakbij ligt om het werken met de afbeelding te vergemakkelijken.
  4. Zodra de VM vanaf de image is geïmplementeerd, kunnen de controles beginnen. In principe worden de controles met de auto uitgevoerd. Het controleert hoe de scripts werkten bij het opstarten en hoe de daemons werken. Om dit te doen, loggen we via ssh of winrm in op de nieuw opgerichte machine en controleren we de configuratiestatus en of de services actief zijn.

• De situatie is vergelijkbaar met integratietests in modules voor terraform. Hier is een korte tabel waarin de kenmerken van dergelijke tests worden uitgelegd.

  
  
  Feedback over de pijplijn duurt ongeveer 40 minuten. Alles gebeurt heel lang. Het kan worden gebruikt voor regressie, maar voor nieuwe ontwikkeling is het over het algemeen onrealistisch. Als je hier heel erg op voorbereid bent, bereid dan lopende scripts voor, dan kun je dit terugbrengen tot 10 minuten. Maar dit zijn nog steeds geen Unit-tests, waarbij 5 stuks in 100 seconden worden gedaan.

De afwezigheid van Unit-tests bij het samenstellen van afbeeldingen of terraform-modules stimuleert het verschuiven van het werk naar afzonderlijke services die eenvoudig via REST kunnen worden uitgevoerd, of naar Python-scripts.

We moesten er bijvoorbeeld voor zorgen dat wanneer de virtuele machine start, deze zichzelf in de service registreert SchaalFT, en toen de virtuele machine werd vernietigd, verwijderde deze zichzelf.

Omdat wij ScaleFT als dienst hebben, zijn wij genoodzaakt om er via de API mee te werken. Er was daar een wikkel geschreven die je eruit kon trekken en zeggen: "Ga naar binnen en verwijder dit en dat." Het slaat alle noodzakelijke instellingen en toegangen op.

We kunnen hier al normale tests voor schrijven, omdat het niet anders is dan gewone software: een soort apiha wordt bespot, je trekt eraan en kijkt wat er gebeurt.

Resultaten van de tests: Unit-testen, die het besturingssysteem binnen een minuut zouden moeten opleveren, geven dit niet. En soorten testen hoger in de piramide zijn effectief, maar dekken slechts een deel van de problemen.

Paar programmeren

Testen zijn natuurlijk goed. Je kunt er veel van schrijven, ze kunnen van verschillende typen zijn. Zij werken op hun niveau en geven ons feedback. Maar het probleem met slechte Unit-tests, die het snelste besturingssysteem opleveren, blijft bestaan. Tegelijkertijd wil ik nog steeds een snel besturingssysteem dat gemakkelijk en prettig is om mee te werken. Om nog maar te zwijgen van de kwaliteit van de resulterende oplossing. Gelukkig zijn er technieken die nog snellere feedback kunnen geven dan unit-tests. Dit is pair-programmering.

Als je code schrijft, wil je zo snel mogelijk feedback krijgen over de kwaliteit ervan. Ja, je kunt alles in een feature branch schrijven (om voor niemand iets kapot te maken), een pull-verzoek doen in Github, het toewijzen aan iemand wiens mening gewicht in de schaal legt, en wachten op een reactie.

Maar je kunt lang wachten. Mensen hebben het allemaal druk, en het antwoord, zelfs als dat er is, is misschien niet van de hoogste kwaliteit. Stel dat het antwoord onmiddellijk kwam, de recensent begreep het hele idee onmiddellijk, maar het antwoord komt achteraf nog steeds te laat. Ik wou dat het eerder was. Dit is waar pair programming op gericht is – meteen, op het moment van schrijven.

Hieronder staan ​​de paar programmeerstijlen en hun toepasbaarheid bij het werken aan IaC:

1. Klassiek, Ervaren+Ervaren, ploeg per timer. Twee rollen: bestuurder en navigator. Twee personen. Ze werken aan dezelfde code en wisselen na een bepaalde, vooraf bepaalde tijd van rol.

Laten we eens kijken naar de compatibiliteit van onze problemen met stijl:

• Probleem: imperfectie van tools en tools voor codeontwikkeling.
  Negatieve impact: het duurt langer om zich te ontwikkelen, we vertragen, het tempo/ritme van het werk gaat verloren.
  Hoe we vechten: we gebruiken een andere tooling, een gemeenschappelijke IDE en leren ook snelkoppelingen.
• Probleem: trage implementatie.
  Negatieve impact: verhoogt de tijd die nodig is om een ​​werkend stuk code te maken. We vervelen ons tijdens het wachten, onze handen strekken zich uit om iets anders te doen terwijl we wachten.
  Hoe we vechten: we hebben het niet overwonnen.
• Probleem: gebrek aan benaderingen en praktijken.
  Negatieve impact: er is geen kennis over hoe je het goed en hoe je het slecht kunt doen. Verlengt de ontvangst van feedback.
  Hoe we vechten: wederzijdse uitwisseling van meningen en praktijken in duowerk lost het probleem bijna op.

Het grootste probleem bij het gebruik van deze stijl in IaC is het ongelijke werktempo. Bij traditionele softwareontwikkeling heb je een zeer uniforme beweging. Je kunt vijf minuten besteden en N schrijven. Besteed 10 minuten en schrijf 2N, 15 minuten - 3N. Hier kun je vijf minuten besteden en N schrijven, en dan nog eens 30 minuten besteden en een tiende van N schrijven. Hier weet je niets, je zit vast, stom. Het onderzoek kost tijd en leidt af van het programmeren zelf.

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

2. Pingpong. Deze aanpak houdt in dat één persoon de test schrijft en een ander de implementatie ervan doet. Als je rekening houdt met het feit dat alles ingewikkeld is bij Unit-tests, en je een integratietest moet schrijven die veel tijd kost om te programmeren, verdwijnt al het gemak van pingpong.

Ik kan zeggen dat we hebben geprobeerd de verantwoordelijkheden voor het ontwerpen van een testscript en het implementeren van de code ervoor te scheiden. Eén deelnemer bedacht het script, in dit deel van het werk was hij verantwoordelijk, hij had het laatste woord. En de ander was verantwoordelijk voor de uitvoering. Het pakte goed uit. De kwaliteit van het script neemt met deze aanpak toe.

Conclusie: helaas staat het werktempo het gebruik van pingpong als paarprogrammeringspraktijk in IaC niet toe.

3. Sterke stijl. Moeilijke praktijk. Het idee is dat één deelnemer de regie-navigator wordt en de tweede de rol van uitvoeringsbestuurder op zich neemt. In dit geval berust het beslissingsrecht uitsluitend bij de navigator. De chauffeur print alleen en heeft met één woord invloed op wat er gebeurt. De rollen veranderen lange tijd niet.

Goed om te leren, maar vereist sterke zachte vaardigheden. Dit is waar we wankelden. De techniek was moeilijk. En dan hebben we het nog niet eens over de infrastructuur.

Conclusie: het kan potentieel worden gebruikt, we geven het proberen niet op.

4. Mobbing, zwermen en alle bekende maar niet genoemde stijlen Wij overwegen het niet, omdat We hebben het nog niet geprobeerd en het is onmogelijk om er in de context van ons werk over te praten.

Algemene resultaten bij het gebruik van paarprogrammering:

• We hebben een ongelijk werktempo, wat verwarrend is.
• We kwamen onvoldoende goede soft skills tegen. En het vakgebied helpt niet om deze tekortkomingen van ons te overwinnen.
• Lange tests en problemen met tools maken gepaarde ontwikkeling moeilijk.

5. Desondanks waren er successen. Wij hebben onze eigen methode “Convergentie – Divergentie” bedacht. Ik zal kort beschrijven hoe het werkt.

Wij hebben vaste partners voor enkele dagen (minder dan een week). Eén taak doen we samen. We zitten een tijdje bij elkaar: de een schrijft, de ander zit en kijkt naar het ondersteuningsteam. Dan gaan we een tijdje uit elkaar, ieder doet wat onafhankelijke dingen, dan komen we weer samen, synchroniseren heel snel, doen samen iets en gaan weer uiteen.

Plannen en communiceren

Het laatste blok van praktijken waarmee OS-problemen worden opgelost, is de organisatie van het werk met de taken zelf. Dit omvat ook de uitwisseling van ervaringen die buiten het duowerk vallen. Laten we eens kijken naar drie praktijken:

1. Doelstellingen via de doelenboom. We hebben het algehele beheer van het project georganiseerd via een boom die eindeloos de toekomst in gaat. Technisch gezien gebeurt de tracking in Miro. Er is één taak: het is een tussendoel. Daaruit gaan kleinere doelen of groepen taken. De taken zelf komen van hen. Op dit bord worden alle taken gemaakt en onderhouden.

Dit schema geeft ook feedback, die één keer per dag plaatsvindt wanneer we synchroniseren tijdens rally's. Door een gemeenschappelijk plan voor iedereen te hebben, maar gestructureerd en volledig open, kan iedereen zich bewust zijn van wat er gebeurt en hoe ver we zijn gevorderd.

Voordelen van visuele visie op taken:

• Causaliteit. Elke taak leidt tot een mondiaal doel. Taken zijn gegroepeerd in kleinere doelen. Het infrastructuurdomein zelf is behoorlijk technisch. Het is niet altijd direct duidelijk welke specifieke impact, bijvoorbeeld het schrijven van een runbook over het migreren naar een andere nginx, heeft op de business. Als u de doelkaart in de buurt heeft, wordt het duidelijker.
  
  Causaliteit is een belangrijke eigenschap van problemen. Het geeft direct antwoord op de vraag: “Doe ik het juiste?”
• Parallellisme. We zijn met zijn negenen, en het is fysiek onmogelijk om iedereen op één taak te richten. Taken uit één gebied zijn misschien ook niet altijd voldoende. We zijn gedwongen om het werk tussen kleine werkgroepen te parallelliseren. Tegelijkertijd blijven de groepen enige tijd met hun taak bezig, ze kunnen door iemand anders worden versterkt. Soms vallen mensen weg van deze werkgroep. Iemand gaat op vakantie, iemand maakt een verslag voor de DevOps conf, iemand schrijft een artikel op Habr. Weten welke doelen en taken parallel kunnen worden uitgevoerd, wordt erg belangrijk.

2. Vervangende presentatoren van ochtendbijeenkomsten. Bij stand-ups hebben we dit probleem: mensen voeren veel taken tegelijkertijd uit. Soms zijn taken losjes met elkaar verbonden en is er geen inzicht in wie wat doet. En de mening van een ander teamlid is erg belangrijk. Dit is aanvullende informatie die de loop van het oplossen van het probleem kan veranderen. Natuurlijk is er meestal iemand bij je, maar advies en tips zijn altijd nuttig.

Om deze situatie te verbeteren, hebben we de ‘Changing the Leading Stand-Up’-techniek gebruikt. Nu worden ze gerouleerd volgens een bepaalde lijst, en dit heeft zijn effect. Als het jouw beurt is, word je gedwongen erin te duiken en te begrijpen wat er aan de hand is om een ​​goede Scrum-bijeenkomst te kunnen houden.

3. Interne demo. Hulp bij het oplossen van een probleem vanuit paarprogrammering, visualisatie van de probleemboom en hulp bij scrumvergaderingen in de ochtend zijn goed, maar niet ideaal. Als koppel wordt u alleen beperkt door uw kennis. De takenboom helpt om globaal te begrijpen wie wat doet. En de presentator en collega's tijdens de ochtendbijeenkomst zullen niet diep in uw problemen duiken. Het kan zeker zijn dat ze iets missen.

De oplossing werd gevonden door elkaar het werk te laten zien en dit vervolgens te bespreken. We komen één keer per week een uur lang bijeen en laten details zien van oplossingen voor taken die we de afgelopen week hebben uitgevoerd.

Tijdens de demonstratie is het noodzakelijk om de details van de taak te onthullen en de werking ervan te demonstreren.

De rapportage kan worden uitgevoerd aan de hand van een checklist.1. Ga in de context. Waar kwam de taak vandaan, waarom was het überhaupt nodig?

2. Hoe werd het probleem eerder opgelost? Er was bijvoorbeeld massaal muisklikken nodig, of het was onmogelijk om helemaal niets te doen.

3. Hoe we het verbeteren. Bijvoorbeeld: "Kijk, nu is er scriptosik, hier is de leesmij."

4. Laat zien hoe het werkt. Het is raadzaam om een ​​gebruikersscenario direct te implementeren. Ik wil X, ik doe Y, ik zie Y (of Z). Ik implementeer bijvoorbeeld NGINX, rook de URL en krijg 200 OK. Als de actie lang duurt, bereid deze dan van tevoren voor, zodat je deze later kunt laten zien. Het is raadzaam om het een uur voor de demo niet te veel kapot te maken, als het kwetsbaar is.

5. Leg uit hoe succesvol het probleem is opgelost, welke moeilijkheden er nog zijn, wat nog niet is voltooid, welke verbeteringen in de toekomst mogelijk zijn. Nu bijvoorbeeld CLI, dan komt er volledige automatisering in CI.

Het is voor elke spreker raadzaam om deze tussen de 5 en 10 minuten te houden. Als uw toespraak duidelijk belangrijk is en langer gaat duren, coördineer dit dan vooraf in het sre-takeover-kanaal.

Na het face-to-face gedeelte is er altijd een discussie in de draad. Hier verschijnt de feedback die we nodig hebben over onze taken.

Als gevolg hiervan wordt een onderzoek uitgevoerd om het nut van wat er gebeurt te bepalen. Dit is feedback op de essentie van de toespraak en het belang van de taak.

Lange conclusies en wat nu

Het lijkt misschien dat de toon van het artikel enigszins pessimistisch is. Dit is fout. Twee lagere feedbackniveaus, namelijk tests en paarprogrammering, werken. Niet zo perfect als bij traditionele ontwikkeling, maar het heeft wel een positief effect.

Tests bieden in hun huidige vorm slechts gedeeltelijke codedekking. Veel configuratiefuncties blijven ongetest. Hun invloed op het daadwerkelijke werk bij het schrijven van code is laag. Er is echter wel een effect van integratietests en ze stellen je in staat onbevreesd refactorings uit te voeren. Dit is een geweldige prestatie. Ook met de verschuiving van de focus naar ontwikkeling in talen op hoog niveau (we hebben Python, go), verdwijnt het probleem. En voor de ‘lijm’ heb je niet veel controles nodig; een algemene integratiecheck is voldoende.

Het werken in tweetallen is meer afhankelijk van specifieke personen. Er is de taakfactor en onze soft skills. Bij sommige mensen pakt het heel goed uit, bij anderen pakt het slechter uit. Hier zitten zeker voordelen aan. Het is duidelijk dat zelfs als de regels van paarwerk niet voldoende worden nageleefd, juist het feit dat taken samen worden uitgevoerd een positief effect heeft op de kwaliteit van het resultaat. Persoonlijk vind ik het werken met z’n tweeën makkelijker en leuker.

Manieren op een hoger niveau om het besturingssysteem te beïnvloeden - het nauwkeurig plannen en werken met taken levert effecten op: hoogwaardige kennisuitwisseling en verbeterde ontwikkelingskwaliteit.

Korte conclusies in één regel

• HR-professionals werken in IaC, maar met minder efficiëntie.
• Versterk wat werkt.
• Bedenk uw eigen compensatiemechanismen en -praktijken.

Bron: www.habr.com