Hola, Habr! Anteriorment, em queixava de la vida a la Infraestructura com a paradigma de codi i no oferia res per resoldre la situació actual. Avui torno per explicar-vos quins enfocaments i pràctiques us ajudaran a escapar de l'abisme de la desesperació i a dirigir la situació en la direcció correcta.
En un article anterior Vaig compartir les meves impressions sobre aquesta àrea, vaig intentar reflexionar sobre la situació actual en aquesta àrea i fins i tot vaig suggerir que les pràctiques estàndard conegudes per tots els desenvolupadors podrien ajudar. Pot semblar que hi havia moltes queixes sobre la vida, però no hi havia propostes per sortir de la situació actual.
Qui som, on som i quins problemes tenim
Actualment estem al Sre Onboarding Team, format per sis programadors i tres enginyers d'infraestructura. Tots estem intentant escriure Infraestructura com a codi (IaC). Ho fem perquè bàsicament sabem escriure codi i tenim un historial de desenvolupadors "per sobre de la mitjana".
- Tenim un conjunt d'avantatges: una formació determinada, coneixements de pràctiques, capacitat per escriure codi, ganes d'aprendre coses noves.
- I hi ha una part caiguda, que també és un inconvenient: la manca de coneixement sobre el maquinari de la infraestructura.
La pila de tecnologia que utilitzem al nostre IaC.
- Terraform per a la creació de recursos.
- Packer per muntar imatges. Aquestes són imatges de Windows, CentOS 7.
- Jsonnet per fer una compilació potent a drone.io, així com per generar packer json i els nostres mòduls terraform.
- Blau.
- Ansible a l'hora de preparar imatges.
- Python per a serveis auxiliars i scripts de subministrament.
- I tot això en VSCode amb connectors compartits entre els membres de l'equip.
Conclusió de la meva va ser així: vaig intentar inculcar (en primer lloc) optimisme, volia dir que provarem els plantejaments i pràctiques que ens coneixem per fer front a les dificultats i complexitats que hi ha en aquest àmbit.
Actualment estem lluitant amb els següents problemes d'IaC:
- Imperfecció d'eines i mitjans per al desenvolupament de codi.
- Desplegament lent. La infraestructura forma part del món real i pot ser lenta.
- Manca d'enfocaments i pràctiques.
- Som nous i no sabem gaire.
Programació extrema (XP) al rescat
Tots els desenvolupadors estan familiaritzats amb la programació extrema (XP) i les pràctiques que hi ha al darrere. Molts de nosaltres hem treballat amb aquest enfocament i ha tingut èxit. Llavors, per què no utilitzar els principis i pràctiques establerts allà per superar els reptes de la infraestructura? Vam decidir adoptar aquest enfocament i veure què passa.
Comprovació de l'aplicabilitat de l'enfocament XP al vostre sectorAquí teniu una descripció de l'entorn per al qual s'adapta bé XP i com es relaciona amb nosaltres:
1. Requisits de programari canviants dinàmicament. Teníem clar quin era l'objectiu final. Però els detalls poden variar. Nosaltres mateixos decidim on hem de taxi, de manera que els requisits canvien periòdicament (principalment per nosaltres mateixos). Si prenem l'equip SRE, que fa l'automatització per si mateix, i limita els requisits i l'abast del treball, aquest punt encaixa bé.
2. Riscos ocasionats per projectes a temps determinat amb noves tecnologies. És possible que ens trobem amb riscos quan utilitzem coses desconegudes per a nosaltres. I aquest és 100% el nostre cas. Tot el nostre projecte va ser l'ús de tecnologies que no coneixíem del tot. En general, aquest és un problema constant, perquè... Hi ha moltes noves tecnologies que sorgeixen en el sector de les infraestructures tot el temps.
3,4. Equip de desenvolupament extens petit i coubicat. La tecnologia automatitzada que utilitzeu permet fer proves unitàries i funcionals. Aquests dos punts no ens encaixen del tot. En primer lloc, no som un equip coordinat, i en segon lloc, som nou, que podem considerar un gran equip. Tot i que, segons algunes definicions d'un equip "gran", molts són més de 14 persones.
Vegem algunes pràctiques de XP i com afecten la velocitat i la qualitat dels comentaris.
Principi del bucle de retroalimentació XP
Al meu entendre, el feedback és la resposta a la pregunta, estic fent el correcte, hi anem? XP té un esquema diví per a això: un bucle de retroalimentació temporal. L'interessant és que com més baix estem, més ràpid aconseguirem que el sistema operatiu respongui les preguntes necessàries.
Aquest és un tema força interessant de discussió, que a la nostra indústria informàtica és possible obtenir ràpidament un sistema operatiu. Imagineu el dolorós que és fer un projecte durant sis mesos i només aleshores descobrir que hi va haver un error al principi. Això passa en el disseny i en qualsevol construcció de sistemes complexos.
En el nostre cas d'IaC, els comentaris ens ajuden. Immediatament faré un petit ajust al diagrama anterior: el pla de llançament no té un cicle mensual, sinó que es produeix diverses vegades al dia. Hi ha algunes pràctiques vinculades a aquest cicle del sistema operatiu que veurem amb més detall.
Important: els comentaris poden ser una solució a tots els problemes esmentats anteriorment. Combinat amb les pràctiques XP, us pot treure de l'abisme de la desesperació.
Com sortir de l'abisme de la desesperació: tres pràctiques
Proves
Les proves s'esmenten dues vegades al bucle de retroalimentació XP. No és només així. Són extremadament importants per a tota la tècnica de programació extrema.
Se suposa que teniu proves d'unitat i d'acceptació. Alguns et donen comentaris en pocs minuts, d'altres en pocs dies, de manera que triguen més a escriure'ls i es revisen amb menys freqüència.
Hi ha una piràmide de proves clàssica, que demostra que hi hauria d'haver més proves.
Com ens aplica aquest marc en un projecte IaC? De fet... en absolut.
- Les proves unitàries, malgrat que n'hi hauria d'haver moltes, no poden ser massa. O estan provant alguna cosa de manera molt indirecta. De fet, podem dir que no els escrivim gens. Però aquí hi ha algunes aplicacions per a aquestes proves que hem pogut fer:
- Prova el codi jsonnet. Aquest, per exemple, és el nostre pipeline de muntatge de drons, que és força complicat. El codi jsonnet està ben cobert per les proves.
Utilitzem això . - Proves dels scripts que s'executen quan s'inicia el recurs. Els scripts estan escrits en Python i, per tant, s'hi poden escriure proves.
- Prova el codi jsonnet. Aquest, per exemple, és el nostre pipeline de muntatge de drons, que és força complicat. El codi jsonnet està ben cobert per les proves.
- Potencialment és possible comprovar la configuració en proves, però no ho fem. També és possible configurar regles de configuració de recursos de comprovació mitjançant . Tanmateix, les comprovacions que hi ha són simplement massa bàsiques per a terraform, però molts scripts de prova estan escrits per a AWS. I estem a Azure, així que això de nou no s'aplica.
- Proves d'integració de components: depèn de com les classifiqueu i on les poseu. Però bàsicament funcionen.
Així són les proves d'integració.
Aquest és un exemple quan es construeixen imatges a Drone CI. Per arribar-hi, cal esperar 30 minuts perquè es formi la imatge de Packer i després esperar 15 minuts més perquè passin. Però existeixen!Algorisme de verificació d'imatges
- Primer ha de preparar la imatge completament.
- Al costat de la prova hi ha una terraforma amb un estat local, que utilitzem per desplegar aquesta imatge.
- Quan es desplega, s'utilitza un petit mòdul situat a prop per facilitar el treball amb la imatge.
- Un cop desplegada la VM des de la imatge, les comprovacions poden començar. Bàsicament, les comprovacions es fan amb cotxe. Comprova com van funcionar els scripts a l'inici i com funcionen els dimonis. Per fer-ho, mitjançant ssh o winrm iniciem sessió a la màquina que s'acaba de plantejar i comprovem l'estat de configuració o si els serveis estan activats.
- La situació és similar amb les proves d'integració en mòduls per terraform. Aquí teniu una taula breu que explica les característiques d'aquestes proves.
Els comentaris sobre el pipeline són d'uns 40 minuts. Tot passa durant molt de temps. Es pot utilitzar per a la regressió, però per a nous desenvolupaments generalment no és realista. Si esteu molt, molt preparat per a això, prepareu scripts en execució, podeu reduir-ho a 10 minuts. Però aquestes encara no són proves unitàries, que fan 5 peces en 100 segons.
L'absència de proves unitàries quan s'assemblen imatges o mòduls de terraforma fomenta el canvi de treball a serveis separats que simplement es poden executar mitjançant REST o scripts de Python.
Per exemple, ens havíem d'assegurar que quan s'inicia la màquina virtual, es registra al servei , i quan es va destruir la màquina virtual, es va esborrar.
Com que tenim ScaleFT com a servei, ens veiem obligats a treballar-hi a través de l'API. Hi havia un embolcall escrit allà que podia treure i dir: "Entra i esborra això i allò". Emmagatzema tots els paràmetres i accessos necessaris.
Ja podem escriure proves normals per a això, ja que no és diferent del programari normal: es burla d'algun tipus d'apiha, l'estireu i mireu què passa.
Resultats de les proves: les proves unitàries, que haurien de donar el sistema operatiu en un minut, no ho donen. I els tipus de proves més altes de la piràmide són efectius, però cobreixen només una part dels problemes.
Programació per parelles
Les proves són, per descomptat, bones. En pots escriure molts, poden ser de diferents tipus. Treballaran al seu nivell i ens donaran comentaris. Però el problema amb les proves unitàries dolentes, que donen el sistema operatiu més ràpid, continua. Al mateix temps, encara vull un sistema operatiu ràpid que sigui fàcil i agradable de treballar. Per no parlar de la qualitat de la solució resultant. Afortunadament, hi ha tècniques que poden proporcionar un feedback encara més ràpid que les proves unitàries. Aquesta és la programació per parelles.
Quan escriu codi, vols rebre comentaris sobre la seva qualitat el més aviat possible. Sí, podeu escriure-ho tot en una branca de funcions (per no trencar res per a ningú), fer una sol·licitud d'extracció a Github, assignar-la a algú l'opinió del qual té pes i esperar una resposta.
Però pots esperar molt de temps. La gent està ocupada i la resposta, encara que n'hi hagi una, pot ser que no sigui de la màxima qualitat. Suposem que la resposta va arribar immediatament, el revisor va comprendre a l'instant tota la idea, però la resposta encara arriba tard, després del fet. M'agradaria que fos abans. Això és el que pretén la programació en parella, de seguida, en el moment d'escriure.
A continuació es mostren els estils de programació de parelles i la seva aplicabilitat per treballar amb IaC:
1. Clàssic, experimentat + experimentat, canvi per temporitzador. Dues funcions: conductor i navegant. Dues persones. Treballen amb el mateix codi i canvien de rol després d'un període de temps predeterminat.
Considerem la compatibilitat dels nostres problemes amb l'estil:
- Problema: imperfecció de les eines i eines per al desenvolupament de codi.
Impacte negatiu: triga més a desenvolupar-se, alentim, el ritme/ritme de treball es perd.
Com lluitem: fem servir una eina diferent, un IDE comú i també aprenem dreceres. - Problema: desplegament lent.
Impacte negatiu: augmenta el temps que es necessita per crear una part de codi de treball. Ens avorrim mentre esperem, les nostres mans s'estenen per fer alguna cosa més mentre esperem.
Com lluitem: no ho hem superat. - Problema: manca d'enfocaments i pràctiques.
Impacte negatiu: no es coneix com fer-ho bé i com fer-ho malament. Allarga la recepció de comentaris.
Com lluitem: l'intercanvi mutu d'opinions i pràctiques en el treball per parelles gairebé soluciona el problema.
El principal problema d'utilitzar aquest estil a IaC és el ritme desigual de treball. En el desenvolupament de programari tradicional, teniu un moviment molt uniforme. Pots dedicar cinc minuts i escriure N. Passar 10 minuts i escriure 2N, 15 minuts - 3N. Aquí pots passar cinc minuts i escriure N, i després passar 30 minuts més i escriure una dècima de N. Aquí no saps res, estàs atrapat, estúpid. La investigació pren temps i distreu de la programació.
Conclusió: en la seva forma pura no ens convé.
2. Ping-pong. Aquest enfocament implica que una persona escrigui la prova i una altra en faci la implementació. Tenint en compte que tot és complicat amb les proves unitàries, i cal escriure una prova d'integració que triga molt a programar-se, tota la facilitat del ping-pong desapareix.
Puc dir que vam intentar separar les responsabilitats per dissenyar un script de prova i implementar-hi codi. A un participant se li va ocórrer el guió, en aquesta part de l'obra era el responsable, tenia l'última paraula. I l'altre era el responsable de la implementació. Va sortir bé. La qualitat del guió amb aquest enfocament augmenta.
Conclusió: per desgràcia, el ritme de treball no permet l'ús del ping-pong com a pràctica de programació en parella a IaC.
3.Estil fort. . La idea és que un participant es converteixi en el navegador directiu i el segon pren el paper de controlador d'execució. En aquest cas, el dret a prendre decisions correspon exclusivament al navegador. El controlador només imprimeix i pot influir en el que passa amb una paraula. Els rols no canvien durant molt de temps.
Bo per aprendre, però requereix fortes habilitats suaus. Aquí és on hem vacil·lat. La tècnica era difícil. I ni tan sols es tracta d'infraestructures.
Conclusió: potencialment es pot utilitzar, no renunciarem a intentar-ho.
4. Mobbing, swarming i tots els estils coneguts però no enumerats No ho considerem, perquè No ho hem provat i és impossible parlar-ne en el context del nostre treball.
Resultats generals sobre l'ús de la programació per parelles:
- Tenim un ritme de treball desigual, que és confús.
- Ens hem trobat amb habilitats suaus insuficientment bones. I l'àrea temàtica no ajuda a superar aquestes nostres mancances.
- Les proves llargues i els problemes amb les eines dificulten el desenvolupament en parella.
5. Malgrat això, hi va haver èxits. Hem creat el nostre propi mètode "Convergència - Divergència". Descriuré breument com funciona.
Tenim socis permanents durant uns dies (menys d'una setmana). Fem una tasca junts. Ens asseiem una estona junts: un escriu, l'altre s'asseu i mira l'equip de suport. Després ens dispersem durant un temps, cadascú fa algunes coses independents, després ens tornem a unir, ens sincronitzem molt ràpidament, fem alguna cosa junts i ens tornem a dispersar.
Planificació i comunicació
L'últim bloc de pràctiques a través del qual es resolen els problemes del sistema operatiu és l'organització del treball amb les tasques pròpies. Això també inclou l'intercanvi d'experiències fora del treball en parella. Vegem tres pràctiques:
1. Objectius a través de l'arbre d'objectius. Hem organitzat la gestió global del projecte a través d'un arbre que s'endinsa sense parar cap al futur. Tècnicament, el seguiment es fa a Miro. Hi ha una tasca: és un objectiu intermedi. D'això surten objectius més petits o grups de tasques. Les pròpies tasques provenen d'ells. Totes les tasques es creen i es mantenen en aquest tauler.
Aquest esquema també proporciona feedback, que es produeix un cop al dia quan ens sincronitzem a les concentracions. Tenir un pla comú davant de tothom, però estructurat i totalment obert, permet que tothom sigui conscient del que està passant i fins on hem avançat.
Avantatges de la visió visual de les tasques:
- Causalitat. Cada tasca porta a un objectiu global. Les tasques s'agrupen en objectius més petits. El domini de la infraestructura en si és força tècnic. No sempre està clar immediatament quin impacte específic, per exemple, escriure un runbook sobre la migració a un altre nginx té en el negoci. Tenir la targeta objectiu a prop ho fa més clar.
La causalitat és una propietat important dels problemes. Respon directament a la pregunta: "Estic fent el correcte?" - Paral·lelisme. Som nou, i és simplement físicament impossible llançar tothom a una tasca. Les tasques d'una àrea potser no sempre són suficients. Ens veiem obligats a paral·lelitzar el treball entre petits grups de treball. Al mateix temps, els grups s'asseuen a la seva tasca durant un temps, poden ser reforçats per algú altre. De vegades, la gent s'allunya d'aquest grup de treball. Algú se'n va de vacances, algú fa un informe per al DevOps conf, algú escriu un article sobre Habr. Saber quins objectius i tasques es poden fer en paral·lel esdevé molt important.
2. Presentadors substitutius de les reunions matinals. Als stand-up tenim aquest problema: la gent fa moltes tasques en paral·lel. De vegades, les tasques estan poc connectades i no s'entén qui fa què. I l'opinió d'un altre membre de l'equip és molt important. Aquesta és informació addicional que pot canviar el curs de la resolució del problema. Per descomptat, normalment hi ha algú amb tu, però els consells i consells sempre són útils.
Per millorar aquesta situació, hem fet servir la tècnica “Canviar el lideratge de peu”. Ara es giren segons una llista determinada, i això té el seu efecte. Quan és el vostre torn, us oblideu a submergir-vos i entendre què està passant per dur a terme una bona reunió de Scrum.
3. Demo interna. L'ajuda per resoldre un problema des de la programació per parelles, la visualització a l'arbre de problemes i l'ajuda a les reunions scrum del matí són bones, però no ideals. Com a parella, només esteu limitats pels vostres coneixements. L'arbre de tasques ajuda a entendre globalment qui fa què. I el presentador i els companys de la reunió del matí no aprofundiran en els vostres problemes. Segurament es poden perdre alguna cosa.
La solució es va trobar demostrant la feina feta entre ells i després discutint-la. Ens reunim un cop a la setmana durant una hora i mostrem detalls de les solucions a les tasques que hem fet durant la setmana passada.
Durant la demostració, cal revelar els detalls de la tasca i assegurar-se de demostrar el seu funcionament.
L'informe es pot realitzar mitjançant una llista de verificació.1. Entra en context. D'on va sortir la tasca, per què era fins i tot necessària?
2. Com es resolia el problema abans? Per exemple, calia fer clic massiu amb el ratolí o era impossible fer res.
3. Com ho millorem. Per exemple: "Mira, ara hi ha scriptosik, aquí està el readme".
4. Mostra com funciona. És aconsellable implementar directament algun escenari d'usuari. Vull X, faig Y, veig Y (o Z). Per exemple, implemento NGINX, fumo l'URL i obteniu 200 d'acord. Si l'acció és llarga, prepareu-la amb antelació per poder mostrar-la més tard. S'aconsella no trencar-lo massa una hora abans de la demo, si és fràgil.
5. Explica amb quina èxit s'ha resolt el problema, quines dificultats queden, què no s'ha completat, quines millores són possibles en el futur. Per exemple, ara CLI, llavors hi haurà una automatització completa a CI.
S'aconsella que cada altaveu el mantingui en 5-10 minuts. Si el vostre discurs és òbviament important i trigarà més temps, coordina-ho amb antelació al canal de presa de possessió.
Després de la part cara a cara sempre hi ha una discussió al fil. Aquí és on apareix el feedback que necessitem sobre les nostres tasques.
Com a resultat, es realitza una enquesta per determinar la utilitat del que està passant. Es tracta d'un feedback sobre l'essència del discurs i la importància de la tasca.
Conclusions llargues i què segueix
Pot semblar que el to de l'article és una mica pessimista. Això està malament. Funcionen dos nivells inferiors de feedback, és a dir, les proves i la programació per parelles. No és tan perfecte com en el desenvolupament tradicional, però hi ha un efecte positiu.
Les proves, en la seva forma actual, només proporcionen una cobertura parcial del codi. Moltes funcions de configuració acaben sense provar. La seva influència en el treball real en escriure codi és baixa. Tanmateix, hi ha un efecte de les proves d'integració i permeten dur a terme refactoritzacions sense por. Aquest és un gran assoliment. A més, amb el canvi de focus cap al desenvolupament en llenguatges d'alt nivell (tenim python, vaja), el problema desapareix. I no necessiteu moltes comprovacions per a la "cola"; una comprovació d'integració general és suficient.
El treball per parelles depèn més de persones concretes. Hi ha el factor tasca i les nostres habilitats suaus. A algunes persones els surt molt bé, a altres els surt pitjor. Definitivament hi ha beneficis d'això. És evident que encara que les regles del treball en parella no s'observen prou, el fet mateix de realitzar tasques junts té un efecte positiu en la qualitat del resultat. Personalment, trobo més fàcil i més agradable treballar per parelles.
Maneres de nivell superior d'influir en el sistema operatiu: planificar i treballar amb tasques amb precisió produeixen efectes: intercanvi de coneixements d'alta qualitat i millora de la qualitat del desenvolupament.
Conclusions breus en una línia
- Els professionals de recursos humans treballen a IaC, però amb menys eficiència.
- Reforça el que funciona.
- Crea els teus propis mecanismes i pràctiques compensatòries.
Font: www.habr.com