Infrastruttura come codice: come superare i problemi utilizzando XP

Ciao, Habr! In precedenza mi sono lamentato della vita nell'infrastruttura come paradigma del codice e non ho offerto nulla per risolvere la situazione attuale. Oggi torno per raccontarti quali approcci e pratiche ti aiuteranno a uscire dall’abisso della disperazione e a indirizzare la situazione nella giusta direzione.

In un precedente articolo "Infrastrutture come codice: prima conoscenza" Ho condiviso le mie impressioni su quest'area, ho cercato di riflettere sulla situazione attuale in quest'area e ho persino suggerito che le pratiche standard note a tutti gli sviluppatori potrebbero aiutare. Potrebbe sembrare che ci fossero molte lamentele sulla vita, ma non c'erano proposte per uscire dalla situazione attuale.

Chi siamo, dove siamo e quali problemi abbiamo

Attualmente facciamo parte dello Sre Onboarding Team, composto da sei programmatori e tre ingegneri delle infrastrutture. Stiamo tutti cercando di scrivere Infrastructure as code (IaC). Lo facciamo perché fondamentalmente sappiamo come scrivere codice e abbiamo una storia di sviluppatori "sopra la media".

• Abbiamo una serie di vantaggi: un certo background, conoscenza delle pratiche, capacità di scrivere codice, desiderio di imparare cose nuove.
• C’è poi un aspetto negativo, che è anche un aspetto negativo: la mancanza di conoscenza dell’hardware dell’infrastruttura.

Lo stack tecnologico che utilizziamo nel nostro IaC.

• Terraform per la creazione di risorse.
• Packer per assemblare le immagini. Queste sono immagini di Windows, CentOS 7.
• Jsonnet per creare una potente build in drone.io, nonché per generare packer json e i nostri moduli terraform.
• Azure.
• Ansible durante la preparazione delle immagini.
• Python per servizi ausiliari e script di provisioning.
• E tutto questo in VSCode con plugin condivisi tra i membri del team.

Conclusione dalla mia ultimo articolo è stato così: ho cercato di instillare (prima di tutto in me stesso) ottimismo, volevo dire che proveremo gli approcci e le pratiche a noi conosciute per affrontare le difficoltà e le complessità che esistono in questo ambito.

Attualmente stiamo lottando con i seguenti problemi IaC:

• Imperfezione di strumenti e mezzi per lo sviluppo del codice.
• Distribuzione lenta. Le infrastrutture fanno parte del mondo reale e possono essere lente.
• Mancanza di approcci e pratiche.
• Siamo nuovi e non sappiamo molto.

Extreme Programming (XP) in soccorso

Tutti gli sviluppatori hanno familiarità con Extreme Programming (XP) e le pratiche che ne stanno dietro. Molti di noi hanno lavorato con questo approccio e ha avuto successo. Allora perché non utilizzare i principi e le pratiche ivi stabiliti per superare le sfide infrastrutturali? Abbiamo deciso di adottare questo approccio e vedere cosa succede.

Verifica l'applicabilità dell'approccio XP al tuo settoreEcco una descrizione dell'ambiente per il quale XP è adatto e come si relaziona a noi:

1. Requisiti software che cambiano dinamicamente. Per noi era chiaro quale fosse l’obiettivo finale. Ma i dettagli possono variare. Decidiamo noi stessi dove rullare, quindi i requisiti cambiano periodicamente (principalmente noi stessi). Se prendiamo il team SRE, che si occupa dell'automazione stessa e limita i requisiti e l'ambito di lavoro, allora questo punto si adatta bene.

2. Rischi causati da progetti a tempo determinato che utilizzano nuove tecnologie. Potremmo incontrare rischi quando utilizziamo alcune cose a noi sconosciute. E questo è il nostro caso al 100%. Il nostro intero progetto prevedeva l'uso di tecnologie con le quali non avevamo piena familiarità. In generale, questo è un problema costante, perché... Ci sono sempre molte nuove tecnologie che emergono nel settore delle infrastrutture.

3,4. Team di sviluppo esteso piccolo e co-localizzato. La tecnologia automatizzata che stai utilizzando consente test unitari e funzionali. Questi due punti non ci soddisfano del tutto. In primo luogo, non siamo una squadra coordinata e, in secondo luogo, siamo nove, il che può essere considerato una grande squadra. Sebbene, secondo alcune definizioni di squadra "grande", molto siano più di 14 persone.

Diamo un'occhiata ad alcune pratiche XP e al modo in cui influenzano la velocità e la qualità del feedback.

Principio del ciclo di feedback XP

A mio avviso, il feedback è la risposta alla domanda: sto facendo la cosa giusta, stiamo andando lì? XP ha uno schema divino per questo: un ciclo di feedback temporale. La cosa interessante è che più siamo in basso, più velocemente riusciremo a far sì che il sistema operativo risponda alle domande necessarie.

Questo è un argomento di discussione piuttosto interessante che nel nostro settore IT è possibile ottenere rapidamente un sistema operativo. Immagina quanto sia doloroso portare avanti un progetto per sei mesi e solo poi scoprire che c'è stato un errore all'inizio. Ciò avviene nella progettazione e in ogni realizzazione di sistemi complessi.

Nel nostro caso di IaC, il feedback ci aiuta. Apporto subito una piccola modifica allo schema qui sopra: il piano di rilascio non ha un ciclo mensile, ma avviene più volte al giorno. Ci sono alcune pratiche legate a questo ciclo del sistema operativo che esamineremo più in dettaglio.

Importante: il feedback può essere una soluzione a tutti i problemi sopra indicati. Combinato con le pratiche XP, può tirarti fuori dall’abisso della disperazione.

Come tirarsi fuori dall'abisso della disperazione: tre pratiche

Test

I test sono menzionati due volte nel ciclo di feedback XP. Non è solo così. Sono estremamente importanti per l'intera tecnica di Extreme Programming.

Si presuppone che tu abbia test di unità e di accettazione. Alcuni ti danno un feedback in pochi minuti, altri in pochi giorni, quindi impiegano più tempo a scriverli e vengono revisionati meno spesso.

Esiste una classica piramide dei test, che mostra che dovrebbero esserci più test.

Come si applica questo quadro a noi in un progetto IaC? In realtà... per niente.

• I test unitari, nonostante dovrebbero essercene molti, non possono essere troppi. Oppure stanno testando qualcosa in modo molto indiretto. In effetti possiamo dire che non li scriviamo affatto. Ma ecco alcune applicazioni per tali test che siamo stati in grado di eseguire:
  1. Testare il codice jsonnet. Questa, ad esempio, è la nostra pipeline di assemblaggio di droni, che è piuttosto complicata. Il codice jsonnet è ben coperto dai test.
     Usiamo questo Framework di test unitari per Jsonnet.
  2. Verifica gli script eseguiti all'avvio della risorsa. Gli script sono scritti in Python e quindi su di essi è possibile scrivere dei test.
• È potenzialmente possibile verificare la configurazione nei test, ma non lo facciamo. È anche possibile configurare le regole di configurazione delle risorse di controllo tramite tflint. Tuttavia, i controlli sono semplicemente troppo semplici per Terraform, ma molti script di test sono scritti per AWS. E siamo su Azure, quindi anche questo non si applica.
• Test di integrazione dei componenti: dipende da come li classifichi e dove li metti. Ma fondamentalmente funzionano.

  Ecco come appaiono i test di integrazione.

  
  
  Questo è un esempio quando si creano immagini in Drone CI. Per raggiungerli bisogna attendere 30 minuti affinché si formi l'immagine Packer, quindi attendere altri 15 minuti affinché passino. Ma esistono!

  Algoritmo di verifica delle immagini

  1. Packer deve prima preparare completamente l'immagine.
  2. Accanto al test c'è una terraform con uno stato locale, che utilizziamo per distribuire questa immagine.
  3. Durante l'apertura, viene utilizzato un piccolo modulo situato nelle vicinanze per facilitare il lavoro con l'immagine.
  4. Una volta distribuita la VM dall'immagine, è possibile iniziare i controlli. Sostanzialmente i controlli si effettuano in macchina. Controlla come hanno funzionato gli script all'avvio e come funzionano i demoni. Per fare ciò, tramite ssh o winrm accediamo alla macchina appena sollevata e controlliamo lo stato della configurazione o se i servizi sono attivi.

• La situazione è simile con i test di integrazione nei moduli per terraform. Ecco una breve tabella che spiega le caratteristiche di tali test.

  
  
  Il feedback sulla pipeline è di circa 40 minuti. Tutto accade per molto tempo. Può essere utilizzato per la regressione, ma per il nuovo sviluppo è generalmente irrealistico. Se sei molto, molto preparato per questo, prepara gli script di esecuzione, quindi puoi ridurlo a 10 minuti. Ma questi non sono ancora test unitari, che eseguono 5 pezzi in 100 secondi.

L'assenza di unit test durante l'assemblaggio di immagini o moduli terraform incoraggia a spostare il lavoro su servizi separati che possono essere semplicemente eseguiti tramite REST o su script Python.

Ad esempio, dovevamo assicurarci che all'avvio la macchina virtuale si registrasse nel servizio ScalaFTe quando la macchina virtuale è stata distrutta, si è cancellata da sola.

Poiché abbiamo ScaleFT come servizio, siamo costretti a lavorarci tramite l'API. C'era scritto un involucro che potevi tirare e dire: "Entra e cancella questo e quello". Memorizza tutte le impostazioni e gli accessi necessari.

Possiamo già scrivere test normali per questo, poiché non è diverso dal software ordinario: una sorta di apiha viene deriso, lo tiri e vedi cosa succede.

Risultati dei test: il test unitario, che dovrebbe fornire il sistema operativo in un minuto, non lo fornisce. E i tipi di test più in alto nella piramide sono efficaci, ma coprono solo una parte dei problemi.

Programmazione in coppia

I test sono, ovviamente, buoni. Puoi scriverne molti, possono essere di diversi tipi. Lavoreranno ai loro livelli e ci daranno feedback. Ma rimane il problema con i test unitari errati, che forniscono il sistema operativo più veloce. Allo stesso tempo, voglio ancora un sistema operativo veloce con cui sia facile e piacevole lavorare. Per non parlare della qualità della soluzione risultante. Fortunatamente, esistono tecniche che possono fornire un feedback ancora più rapido rispetto ai test unitari. Questa è la programmazione in coppia.

Quando scrivi il codice, vuoi ottenere un feedback sulla sua qualità il più rapidamente possibile. Sì, puoi scrivere tutto in un ramo di funzionalità (per non rompere nulla a nessuno), fare una richiesta pull in Github, assegnarla a qualcuno la cui opinione ha peso e attendere una risposta.

Ma puoi aspettare a lungo. Le persone sono tutte occupate e la risposta, anche se ce n'è una, potrebbe non essere della massima qualità. Supponiamo che la risposta sia arrivata immediatamente, il revisore ha capito immediatamente l'intera idea, ma la risposta arriva comunque tardi, a posteriori. Vorrei che fosse prima. Questo è lo scopo a cui mira la programmazione in coppia: subito, nel momento in cui scrivo.

Di seguito sono riportati gli stili di programmazione in coppia e la loro applicabilità nel lavorare su IaC:

1. Classico, esperto+esperto, turno con timer. Due ruoli: conducente e navigatore. Due persone. Lavorano sullo stesso codice e cambiano ruolo dopo un certo periodo di tempo predeterminato.

Consideriamo la compatibilità dei nostri problemi con lo stile:

• Problema: imperfezione di strumenti e strumenti per lo sviluppo del codice.
  Impatto negativo: ci vuole più tempo per svilupparsi, rallentiamo, il ritmo del lavoro si perde.
  Come combattiamo: utilizziamo strumenti diversi, un IDE comune e impariamo anche scorciatoie.
• Problema: distribuzione lenta.
  Impatto negativo: aumenta il tempo necessario per creare un pezzo di codice funzionante. Ci annoiamo nell'attesa, le nostre mani si allungano per fare qualcos'altro mentre aspettiamo.
  Come combattiamo: non l’abbiamo superato.
• Problema: mancanza di approcci e pratiche.
  Impatto negativo: non si sa come farlo bene e come farlo male. Allunga la ricezione dei feedback.
  Come litighiamo: lo scambio reciproco di opinioni e pratiche nel lavoro di coppia risolve quasi il problema.

Il problema principale con l'utilizzo di questo stile in IaC è il ritmo di lavoro irregolare. Nello sviluppo software tradizionale, il movimento è molto uniforme. Puoi spendere cinque minuti e scrivere N. Spendi 10 minuti e scrivi 2N, 15 minuti - 3N. Qui puoi spendere cinque minuti e scrivere N, e poi spendere altri 30 minuti e scrivere un decimo di N. Qui non sai niente, sei bloccato, stupido. L'indagine richiede tempo e distrae dalla programmazione stessa.

Conclusione: nella sua forma pura non è adatto a noi.

2. Ping-pong. Questo approccio prevede che una persona scriva il test e un'altra ne esegua l'implementazione. Tenendo conto del fatto che tutto è complicato con i test unitari e devi scrivere un test di integrazione che richiede molto tempo per essere programmato, tutta la facilità del ping-pong scompare.

Posso dire che abbiamo provato a separare le responsabilità tra la progettazione di uno script di test e l'implementazione del relativo codice. Un partecipante ha ideato la sceneggiatura, in questa parte del lavoro era responsabile, aveva l'ultima parola. E l'altro era responsabile dell'implementazione. Ha funzionato bene. La qualità della sceneggiatura con questo approccio aumenta.

Conclusione: ahimè, il ritmo di lavoro non consente l'uso del ping-pong come pratica di programmazione in coppia in IaC.

3. Stile forte. Pratica difficile. L'idea è che un partecipante diventi il ​​navigatore direttivo e il secondo assuma il ruolo di conducente dell'esecuzione. In questo caso il diritto di prendere decisioni spetta esclusivamente al navigatore. Il driver stampa solo e può influenzare ciò che accade con una parola. I ruoli non cambiano per molto tempo.

Buono per l'apprendimento, ma richiede forti competenze trasversali. È qui che abbiamo vacillato. La tecnica era difficile. E non si tratta nemmeno di infrastrutture.

Conclusione: potenzialmente è utilizzabile, non rinunciamo a provarci.

4. Mobbing, sciamatura e tutti gli stili conosciuti ma non elencati Non lo consideriamo, perché Non l’abbiamo provato ed è impossibile parlarne nel contesto del nostro lavoro.

Risultati generali sull'utilizzo della programmazione in coppia:

• Abbiamo un ritmo di lavoro irregolare, il che crea confusione.
• Ci siamo imbattuti in competenze trasversali non sufficientemente buone. E l'area tematica non aiuta a superare queste nostre mancanze.
• Lunghi test e problemi con gli strumenti rendono difficile lo sviluppo in coppia.

5. Nonostante ciò, ci sono stati dei successi. Abbiamo ideato il nostro metodo “Convergenza - Divergenza”. Descriverò brevemente come funziona.

Abbiamo partner permanenti per alcuni giorni (meno di una settimana). Facciamo un compito insieme. Ci sediamo insieme per un po': uno scrive, l'altro si siede e osserva il team di supporto. Poi ci disperdiamo per un po', ognuno fa alcune cose in modo indipendente, poi ci riuniamo di nuovo, ci sincronizziamo molto velocemente, facciamo qualcosa insieme e poi ci disperdiamo di nuovo.

Pianificazione e comunicazione

L'ultimo blocco di pratiche attraverso il quale vengono risolti i problemi del sistema operativo è l'organizzazione del lavoro con le attività stesse. Ciò include anche lo scambio di esperienze che esula dal lavoro di coppia. Consideriamo tre pratiche:

1. Obiettivi attraverso l'albero degli obiettivi. Abbiamo organizzato la gestione complessiva del progetto attraverso un albero che va all'infinito nel futuro. Tecnicamente il tracciamento viene effettuato in Miro. C'è un compito: è un obiettivo intermedio. Da esso partono obiettivi più piccoli o gruppi di compiti. I compiti stessi provengono da loro. Tutte le attività vengono create e gestite su questa bacheca.

Questo schema fornisce anche un feedback, che avviene una volta al giorno quando ci sincronizziamo ai raduni. Avere un piano comune davanti a tutti, ma strutturato e completamente aperto, permette a tutti di essere consapevoli di ciò che sta accadendo e di quanto siamo andati avanti.

Vantaggi della visione visiva dei compiti:

• Causalità. Ogni attività porta a un obiettivo globale. Le attività sono raggruppate in obiettivi più piccoli. Il settore delle infrastrutture in sé è piuttosto tecnico. Non è sempre immediatamente chiaro quale impatto specifico abbia sull’azienda, ad esempio, la scrittura di un runbook sulla migrazione a un altro nginx. Avere la carta bersaglio nelle vicinanze rende tutto più chiaro.
  
  La causalità è una proprietà importante dei problemi. Risponde direttamente alla domanda: “Sto facendo la cosa giusta?”
• Parallelismo. Siamo nove ed è semplicemente fisicamente impossibile affidare a tutti un compito. Anche i compiti di un'area potrebbero non essere sempre sufficienti. Siamo costretti a parallelizzare il lavoro tra piccoli gruppi di lavoro. Allo stesso tempo, i gruppi restano seduti per un po' sul loro compito, possono essere rinforzati da qualcun altro. A volte le persone si allontanano da questo gruppo di lavoro. Qualcuno va in vacanza, qualcuno fa un rapporto per la conferenza DevOps, qualcuno scrive un articolo su Habr. Sapere quali obiettivi e compiti possono essere svolti in parallelo diventa molto importante.

2. Relatori sostitutivi delle riunioni mattutine. Negli stand-up abbiamo questo problema: le persone svolgono molti compiti in parallelo. A volte i compiti sono vagamente collegati e non si capisce chi sta facendo cosa. E l'opinione di un altro membro del team è molto importante. Si tratta di informazioni aggiuntive che possono cambiare il corso della risoluzione del problema. Certo, di solito c'è qualcuno con te, ma consigli e suggerimenti sono sempre utili.

Per migliorare questa situazione, abbiamo utilizzato la tecnica “Cambiare il Leading Stand-Up”. Ora vengono ruotati secondo un determinato elenco e questo ha il suo effetto. Quando è il tuo turno, sei costretto a immergerti e capire cosa sta succedendo per poter organizzare un buon meeting Scrum.

3. Dimostrazione interna. L'aiuto nella risoluzione di un problema tramite la programmazione in coppia, la visualizzazione sull'albero dei problemi e l'aiuto alle riunioni Scrum al mattino sono buoni, ma non ideali. In coppia, sei limitato solo dalla tua conoscenza. L'albero delle attività aiuta a comprendere globalmente chi sta facendo cosa. E il presentatore e i colleghi della riunione mattutina non approfondiranno i tuoi problemi. Certamente potrebbero perdere qualcosa.

La soluzione è stata trovata nel dimostrare reciprocamente il lavoro svolto e poi discuterne. Ci incontriamo una volta alla settimana per un'ora e mostriamo i dettagli delle soluzioni alle attività che abbiamo svolto nell'ultima settimana.

Durante la dimostrazione, è necessario rivelare i dettagli dell'attività ed assicurarsi di dimostrarne il funzionamento.

Il rapporto può essere condotto utilizzando una lista di controllo.1. Entra nel contesto. Da dove viene il compito, perché era addirittura necessario?

2. Come è stato risolto il problema prima? Ad esempio, era necessario fare clic in modo massiccio con il mouse oppure era impossibile fare qualsiasi cosa.

3. Come lo miglioriamo. Ad esempio: "Guarda, ora c'è scriptosik, ecco il file leggimi."

4. Mostra come funziona. Si consiglia di implementare direttamente alcuni scenari utente. Voglio X, faccio Y, vedo Y (o Z). Ad esempio, distribuisco NGINX, fumo l'URL e ottengo 200 OK. Se l'azione è lunga, preparala in anticipo in modo da poterla mostrare in seguito. Si consiglia di non romperlo troppo un’ora prima della demo, se è fragile.

5. Spiegare con che successo è stato risolto il problema, quali difficoltà rimangono, cosa non è stato completato, quali miglioramenti sono possibili in futuro. Ad esempio, ora CLI, quindi ci sarà la completa automazione in CI.

È consigliabile che ciascun oratore si mantenga entro 5-10 minuti. Se il tuo discorso è ovviamente importante e richiederà più tempo, coordinalo in anticipo nel canale sre-takeover.

Dopo la parte faccia a faccia c'è sempre una discussione nel thread. È qui che appare il feedback di cui abbiamo bisogno sui nostri compiti.

Di conseguenza, viene condotto un sondaggio per determinare l'utilità di ciò che sta accadendo. Questo è un feedback sull'essenza del discorso e sull'importanza del compito.

Conclusioni lunghe e cosa verrà dopo

Può sembrare che il tono dell'articolo sia alquanto pessimista. Questo è sbagliato. Due livelli inferiori di feedback, vale a dire test e programmazione in coppia, funzionano. Non così perfetto come nello sviluppo tradizionale, ma ne deriva un effetto positivo.

I test, nella loro forma attuale, forniscono solo una copertura parziale del codice. Molte funzioni di configurazione finiscono per non essere testate. La loro influenza sul lavoro effettivo durante la scrittura del codice è bassa. Tuttavia, i test di integrazione hanno un effetto e consentono di eseguire refactoring senza timore. Questo è un grande risultato. Inoltre, con lo spostamento dell’attenzione sullo sviluppo in linguaggi di alto livello (abbiamo Python, go), il problema scompare. E non servono tante verifiche per fare da “collante”, basta una verifica generale di integrazione.

Lavorare in coppia dipende più da persone specifiche. C'è il fattore compito e le nostre competenze trasversali. Con alcune persone funziona molto bene, con altre funziona peggio. Ci sono sicuramente dei benefici da questo. È chiaro che, anche se le regole del lavoro in coppia non vengono sufficientemente rispettate, il fatto stesso di svolgere compiti insieme ha un effetto positivo sulla qualità del risultato. Personalmente trovo che lavorare in coppia sia più semplice e divertente.

Modi di livello superiore per influenzare il sistema operativo: la pianificazione e il lavoro con le attività producono effetti precisi: scambio di conoscenze di alta qualità e migliore qualità dello sviluppo.

Brevi conclusioni in una riga

• I professionisti delle risorse umane lavorano in IaC, ma con meno efficienza.
• Rafforza ciò che funziona.
• Elabora i tuoi meccanismi e le tue pratiche compensative.

Fonte: habr.com