Ciao, Habr! Nanzu, aghju lagnatu di a vita in l'Infrastruttura cum'è paradigma di codice è ùn offre nunda per risolve a situazione attuale. Oghje sò tornatu per dì ciò chì avvicinamenti è pratiche vi aiuterà à scappà da l'abissu di a disperazione è guidà a situazione in a direzione ghjusta.
In l'articulu precedente Aghju spartutu e mo impressioni di questa zona, pruvatu à riflette nantu à a situazione attuale in questa zona, è ancu suggeriu chì e pratiche standard cunnisciute da tutti i sviluppatori puderanu aiutà. Puderia sembrà chì ci era assai lagnanza di a vita, ma ùn ci era micca pruposte per una manera di esce da a situazione attuale.
Quale simu, induve simu è chì prublemi avemu
Semu attualmente in u Sre Onboarding Team, chì hè custituitu da sei programatori è trè ingegneri di infrastruttura. Avemu tutti pruvà à scrive Infrastruttura cum'è codice (IaC). Facemu questu perchè sapemu in fondu cumu scrive u codice è avè una storia di esse sviluppatori "sopra à a media".
- Avemu un inseme di vantaghji: un certu sfondate, cunniscenze di pratiche, a capacità di scrive codice, un desideriu di amparà cose novi.
- E ci hè una parte sagging, chì hè ancu un minus: mancanza di cunniscenze nantu à u hardware di l'infrastruttura.
A pila di tecnulugia chì usemu in u nostru IaC.
- Terraform per creà risorse.
- Packer per l'assemblea di l'imaghjini. Quessi sò Windows, imagine CentOS 7.
- Jsonnet per fà una custruzione putente in drone.io, è ancu per generà packer json è i nostri moduli terraform.
- Azur.
- Ansible quandu preparanu l'imaghjini.
- Python per i servizii ausiliarii è i script di furnizzioni.
- È tuttu questu in VSCode cù plugins spartuti trà i membri di a squadra.
Conclusioni da u mo era cusì : aghju pruvatu à inculcà (prima di tuttu in mè) ottimisimu, vulia dì chì pruveremu l'approcciu è e pratiche cunnisciute da noi per trattà e difficultà è cumplessità chì ci sò in stu spaziu.
Attualmente, avemu a lotta cù i seguenti prublemi IaC:
- Imperfezzione di l'arnesi è i mezi per u sviluppu di codice.
- Implementazione lenta. L'infrastruttura hè parti di u mondu reale, è pò esse lentu.
- Mancanza di approcci è pratiche.
- Semu novi è ùn sapemu micca assai.
Extreme Programming (XP) in salvezza
Tutti i sviluppatori sò familiarizati cù a Programmazione Extreme (XP) è e pratiche chì stanu daretu. Parechji di noi anu travagliatu cù questu approcciu, è hè successu. Allora perchè micca aduprà i principii è e pratiche stabilite quì per superà e sfide di l'infrastruttura? Avemu decisu di piglià stu approcciu è vede ciò chì succede.
Verificate l'applicabilità di l'approcciu XP à a vostra industriaEccu una descrizzione di l'ambiente chì XP hè bè adattatu per, è cumu si tratta di noi:
1. Esigenze di u software chì cambianu dinamicamente. Era chjaru per noi quale era u scopu finale. Ma i dettagli ponu varià. Noi stessi decidemu induve avemu bisognu di taxi, cusì i requisiti cambianu periodicamente (principalmente da noi stessi). Se pigliemu a squadra SRE, chì face l'automatizazione stessu, è ellu stessu limita i requisiti è u scopu di u travagliu, allora stu puntu si mette bè.
2. Risichi causati da i prughjetti di tempu fissu cù a nova tecnulugia. Pudemu scontru risichi quandu usendu cose scunnisciute per noi. È questu hè 100% u nostru casu. U nostru prughjettu tutale era l'usu di tecnulugii chì ùn eramu micca completamente familiarizati. In generale, questu hè un prublema constante, perchè ... Ci sò parechje tecnulugia novi emergenti in u settore di l'infrastruttura tuttu u tempu.
3,4. Piccola squadra di sviluppu allargata co-locata. A tecnulugia automatizata chì site aduprate permette teste unità è funziunali. Sti dui punti ùn ci cunvene micca bè. Prima, ùn simu micca una squadra coordinata, è in segundu, ci sò nove di noi, chì ponu esse cunsideratu un grande squadra. Ancu s'è, sicondu qualchi definizione di una squadra "grande", assai hè 14+ persone.
Fighjemu alcune pratiche XP è cumu affettanu a velocità è a qualità di feedback.
XP Feedback Loop Principiu
In u mo capiscimentu, u feedback hè a risposta à a quistione, aghju fattu u dirittu, andemu quì? XP hà un schema divinu per questu: un ciclu di feedback di u tempu. L'interessante hè chì u più bassu simu, u più veloce simu capaci di ottene l'OS per risponde à e dumande necessarie.
Questu hè un tema piuttostu interessante per a discussione, chì in a nostra industria IT hè pussibule di ottene rapidamente un OS. Imagine quantu dulurosu hè di fà un prughjettu per sei mesi è solu dopu scopre chì ci hè statu un sbagliu à u principiu. Questu succede in u disignu è in ogni custruzzione di sistemi cumplessi.
In u nostru casu di IaC, u feedback ci aiuta. Immediatamente fà un picculu aghjustamentu à u diagramma sopra: u pianu di liberazione ùn hà micca un ciculu mensu, ma si trova parechje volte à ghjornu. Ci sò qualchi pratiche ligati à stu ciclu OS chì avemu da fighjulà in più dettu.
Impurtante: u feedback pò esse una suluzione à tutti i prublemi dichjarati sopra. Cumminatu cù e pratiche XP, pò tirà fora di l'abissu di a disperazione.
Cumu tirà fora di l'abissu di a disperazione: trè pratiche
Testi
I testi sò citati duie volte in u ciclu di feedback XP. Ùn hè micca solu cusì. Sò assai impurtanti per tutta a tecnica di Programmazione Extreme.
Hè presumitu chì avete teste Unità è Accettazione. Certi vi danu feedback in pochi minuti, altri in pochi ghjorni, cusì piglianu più tempu per scrive è sò rivisitati menu spessu.
Ci hè una piramide di prova classica, chì mostra chì ci deve esse più teste.
Cumu si applica stu quadru à noi in un prughjettu IaC? In verità... micca in tuttu.
- I testi di unità, malgradu u fattu chì ci deve esse assai, ùn ponu esse troppu. O anu pruvatu qualcosa assai indirettu. In fatti, pudemu dì chì ùn li scrivimu micca in tuttu. Ma quì sò uni pochi di applicazioni per tali teste chì avemu pussutu fà:
- Pruvate u codice jsonnet. Questu, per esempiu, hè u nostru pipeline di assemblea di drone, chì hè abbastanza cumplicatu. U codice jsonnet hè ben coperto da e teste.
Avemu aduprà questu . - Testi per i script chì sò eseguiti quandu a risorsa principia. I scripts sò scritti in Python, è dunque e teste ponu esse scritte nantu à elli.
- Pruvate u codice jsonnet. Questu, per esempiu, hè u nostru pipeline di assemblea di drone, chì hè abbastanza cumplicatu. U codice jsonnet hè ben coperto da e teste.
- Hè potenziale pussibule di verificà a cunfigurazione in teste, ma ùn facemu micca. Hè ancu pussibule di cunfigurà e regule di cunfigurazione di risorsa di cuntrollu via . Tuttavia, i cuntrolli sò simpliciamente troppu basi per terraform, ma assai script di teste sò scritti per AWS. È simu in Azure, cusì questu novu ùn hè micca applicatu.
- Test d'integrazione di cumpunenti: dipende da cumu si classificà è induve i mette. Ma basamente travaglianu.
Eccu ciò chì i testi di integrazione parenu.
Questu hè un esempiu di custruisce l'imaghjini in Drone CI. Per ghjunghje à elli, duvete aspittà 30 minuti per a forma di l'imaghjini di Packer, dopu aspittà altri 15 minuti per passà. Ma esistinu !Algoritmu di verificazione di l'imagine
- Packer deve prima preparà l'imaghjini cumpletamente.
- Accantu à a prova ci hè una terraforma cù un statu lucale, chì avemu usatu per implementà sta maghjina.
- Quandu si sviluppa, un picculu modulu chì si trova vicinu hè utilizatu per fà più faciule di travaglià cù l'imaghjini.
- Una volta chì a VM hè implementata da l'imaghjini, i cuntrolli ponu principià. In fondu, i cuntrolli sò realizati in vittura. Cuntrolla cumu si travagliavanu i script à l'iniziu è cumu funzionanu i demoni. Per fà questu, via ssh o winrm avemu logu in a macchina appena rialzata è verificate u statutu di cunfigurazione o se i servizii sò up.
- A situazione hè simile cù testi di integrazione in moduli per terraform. Eccu una tavula corta chì spiega e caratteristiche di tali teste.
Feedback nantu à u pipeline hè di circa 40 minuti. Tuttu succede per un tempu assai longu. Pò esse usatu per a regressione, ma per u novu sviluppu hè generalmente irrealisticu. Sè vo site assai, assai preparatu per questu, preparanu script in esecuzione, allora pudete riduce à 10 minuti. Ma quessi ùn sò ancora testi Unità, chì facenu 5 pezzi in 100 seconde.
L'absenza di teste Unità quandu si assemblanu l'imaghjini o i moduli di terraformi incuragisce à trasfurmà u travagliu à i servizii separati chì ponu esse simpliciamente eseguiti via REST, o à script Python.
Per esempiu, avemu bisognu di assicurà chì quandu a macchina virtuale principia, si registra in u serviziu , è quandu a macchina virtuale hè stata distrutta, s'hè sguassata.
Siccomu avemu ScaleFT cum'è serviziu, simu furzati à travaglià cun ellu attraversu l'API. C'era un involucro scrittu quì chì pudete tirà è dì: "Entra è sguassate questu è quellu". Guarda tutti i paràmetri necessarii è accessi.
Pudemu digià scrive testi normali per questu, postu chì ùn hè micca sfarente di u software ordinariu: un tipu d'apiha hè burlatu, tira, è vede ciò chì succede.
Risultati di e teste: Unità di prova, chì deve dà u OS in un minutu, ùn dà micca. E tipi di teste più altu in a piramide sò efficaci, ma copre solu una parte di i prublemi.
Prugrammazione di coppia
I testi sò, sicuru, boni. Pudete scrive assai di elli, ponu esse di diversi tipi. Travaglieranu à i so livelli è ci daranu feedback. Ma u prublema cù i testi Unità male, chì dà u OS più veloce, ferma. À u listessu tempu, vogliu sempre un OS veloce chì hè faciule è piacevule per travaglià. Senza parlà di a qualità di a suluzione resultanti. Fortunatamente, ci sò tecniche chì ponu furnisce un feedback ancu più veloce cà e teste di unità. Questu hè un prugramma di coppia.
Quandu scrivite u codice, vulete uttene feedback nantu à a so qualità u più prestu pussibule. Iè, pudete scrive tuttu in un ramu di funziunalità (per ùn rompe nunda per nimu), fate una dumanda di pull in Github, assignalu à qualchissia chì l'opinione hà pesu, è aspettate una risposta.
Ma pudete aspittà assai tempu. A ghjente hè tutta occupata, è a risposta, ancu s'ellu ci hè una, pò esse micca di a più alta qualità. Suppone chì a risposta hè ghjunta subitu, u criticu hà capitu istantaneamente tutta l'idea, ma a risposta hè sempre tardi, dopu à u fattu. Mi piacerebbe chì era prima. Hè ciò chì u prugramma di coppia hè destinatu - subitu, à u mumentu di a scrittura.
Quì sottu sò i stili di prugrammazione di coppia è a so applicabilità in u travagliu nantu à IaC:
1. Classic, Esperienza + Esperienza, cambia per timer. Dui roli - cunduttore è navigatore. Dui parsoni. U travagliu nantu à u listessu codice è cambianu roli dopu un certu periodu di tempu predeterminatu.
Fighjemu a cumpatibilità di i nostri prublemi cù u stilu:
- Prublemu: imperfezzione di arnesi è arnesi per u sviluppu di codice.
Impattu negativu : ci vole più longu à sviluppà, rallentemu, u ritmu/ritmu di u travagliu si perde.
Cumu luttàmu: usemu un strumentu diversu, un IDE cumunu è ancu amparà i shortcuts. - Prublemu: implementazione lenta.
Impattu negativu: aumenta u tempu necessariu per creà un pezzu di codice di travagliu. Ci si annoia mentre aspittemu, e nostre mani stendenu per fà qualcosa d'altru mentre aspittemu.
Cumu luttàmu: ùn l'avemu micca superatu. - Prublemu: mancanza di avvicinamenti è pratiche.
Impattu negativu: ùn ci hè micca sapè cumu fà bè è cumu fà male. Allunga a ricezione di feedback.
Cumu luttàmu: u scambiu mutuale d'opinioni è di pratiche in u travagliu in coppia risolve quasi u prublema.
U prublema principali cù l'usu di stu stile in IaC hè u ritmu irregulare di u travagliu. In u sviluppu di software tradiziunale, avete un muvimentu assai uniforme. Pudete passà cinque minuti è scrive N. Passate 10 minuti è scrive 2N, 15 minuti - 3N. Quì pudete passà cinque minuti è scrivite N, è dopu passate altri 30 minuti è scrivite una decima di N. Quì ùn si sà nunda, site stuck, stupidu. L'investigazione piglia u tempu è distracte da u prugramma stessu.
Conclusioni: in a so forma pura ùn hè micca adattatu per noi.
2. Ping-pong. Stu approcciu implica una persona chì scrive u test è un altru chì faci l'implementazione per questu. Pigliendu u fattu chì tuttu hè cumplicatu cù e teste Unità, è avete à scrive una prova di integrazione chì piglia assai tempu per u prugramma, tutte e facilità di ping-pong si ne vanu.
Puderaghju dì chì avemu pruvatu à separà e responsabilità per u disignu di un script di prova è l'implementazione di codice per questu. Un participante ghjunse cù u script, in questa parte di u travagliu era rispunsevuli, avia l'ultima parola. È l'altru era rispunsevule per l'implementazione. Funziona bè. A qualità di u script cù questu approcciu aumenta.
Conclusioni: sfortunatamente, u ritmu di u travagliu ùn permette micca l'usu di u ping-pong cum'è una pratica di prugrammazione par in IaC.
3.Stile forte. . L'idea hè chì un participante diventa u navigatore direttu, è u sicondu piglia u rolu di u driver di esecutivu. In questu casu, u dirittu di piglià decisioni hè solu à u navigatore. U driver stampa solu è pò influenzà ciò chì succede cù una parolla. I roli ùn cambianu per un bellu pezzu.
Bonu per l'apprendimentu, ma esige forti cumpetenze dolci. Hè quì chì avemu falciatu. A tecnica era difficiule. È ùn si tratta ancu di infrastruttura.
Conclusioni: pò esse potenzialmente utilizatu, ùn rinunciamu micca à pruvà.
4. Mobbing, swarming è tutti i stili cunnisciuti ma micca listati Ùn avemu micca cunsideratu, perchè Ùn avemu micca pruvatu è hè impussibile di parlà in u cuntestu di u nostru travagliu.
Risultati generali nantu à l'usu di a prugrammazione di coppia:
- Avemu un ritmu irregulare di travagliu, chì hè cunfusu.
- Avemu intruduciutu cumpetenze soft insuffisentemente bè. È l'area di u sughjettu ùn aiuta micca à superà queste mancanze di i nostri.
- I testi longu è i prublemi cù l'arnesi facenu difficultà u sviluppu paru.
5. Malgradu questu, ci sò successi. Avemu ghjuntu cù u nostru propiu metudu "Convergenza - Divergenza". Descriveraghju brevemente cumu funziona.
Avemu partenarii permanenti per uni pochi di ghjorni (menu di una settimana). Facemu un compitu inseme. Ci si mette inseme un pocu tempu : unu scrive, l'altru si mette è fighjulà a squadra di sustegnu. Allora sparghjemu per qualchì tempu, ognuna face alcune cose indipindenti, dopu avemu riunitu di novu, sincronizemu assai rapidamente, fate qualcosa inseme è sparghjemu di novu.
Pianificazione è cumunicazione
L'ultimu bloccu di pratiche per via di quale i prublemi OS sò risolti hè l'urganizazione di u travagliu cù i travaglii stessi. Questu include ancu u scambiu di sperienza chì hè fora di u travagliu di coppia. Fighjemu trè pratiche:
1. Ugettivi attraversu l'arburu di u scopu. Avemu urganizatu a gestione generale di u prugettu per mezu di un arbre chì và senza fine in u futuru. Tecnicamente, u seguimentu hè fattu in Miro. Ci hè un compitu - hè un scopu intermediu. Da ellu passanu o scopi più chjuchi o gruppi di tarei. I travaglii stessi venenu da elli. Tutti i travaglii sò creati è mantinuti nantu à questu bordu.
Stu schema furnisce ancu feedback, chì si trova una volta à ghjornu quandu sincronizemu in manifestazioni. Avè un pianu cumunu davanti à tutti, ma strutturatu è cumpletamente apertu, permette à tutti di esse cuscenti di ciò chì succede è di quantu avemu avanzatu.
Vantaghji di a visione visuale di i travaglii:
- Causalità. Ogni compitu porta à qualchì scopu globale. I travaglii sò raggruppati in scopi più chjuchi. U duminiu di l'infrastruttura stessu hè abbastanza tecnicu. Ùn hè micca sempre chjaru immediatamente quale impattu specificu, per esempiu, scrive un runbook nantu à a migrazione à un altru nginx hà nantu à l'affari. Avè a carta di destinazione vicinu rende più chjaru.
A causalità hè una pruprietà impurtante di prublemi. Risponde direttamente à a quistione: "Facciu a cosa bona?" - Parallelismu. Ci sò nove di noi, è hè simpricimenti fisicu impussibile di scaccià tutti à una sola tarea. I compiti da una zona pò esse micca sempre abbastanza. Semu furzati à parallelizà u travagliu trà picculi gruppi di travagliu. À u listessu tempu, i gruppi si ponenu nantu à a so attività per qualchì tempu, ponu esse rinfurzati da un altru. Calchì volta a ghjente si alluntanassi da stu gruppu di travagliu. Qualchissia va in vacanze, qualchissia face un rapportu per u DevOps conf, qualchissia scrive un articulu nantu à Habr. Sapendu chì scopi è travaglii ponu esse fatti in parallelu diventa assai impurtante.
2. Presentatori di rimpiazzamentu di e riunioni di a matina. À i stand-ups avemu stu prublema - a ghjente face parechje attività in parallelu. Calchì volta i travaglii sò cunnessi cunnessi è ùn ci hè micca capitu di quale face ciò chì. È l'opinione di un altru membru di a squadra hè assai impurtante. Questa hè infurmazione supplementaria chì pò cambià u cursu di risolve u prublema. Di sicuru, di solitu ci hè qualchissia cun voi, ma cunsiglii è cunsiglii sò sempre utili.
Per migliurà sta situazione, avemu usatu a tecnica "Changing the Leading Stand-Up". Avà sò rotate secondu una certa lista, è questu hà u so effettu. Quandu hè u vostru turnu, vi sò furzati à immerse è capisce ciò chì succede per fà una bona riunione Scrum.
3. Demo interna. Aiutà à risolve un prublema da a prugrammazione di coppia, a visualizazione nantu à l'arbulu di u prublema è l'aiutu à e riunioni di scrum in a matina sò boni, ma micca ideali. Cum'è una coppia, site limitatu solu da a vostra cunniscenza. L'arburu di u travagliu aiuta à capisce globalmente quale face ciò chì. È u presentatore è i culleghi in a riunione di a matina ùn si sfondaranu micca in i vostri prublemi. Certamente puderanu mancassi qualcosa.
A suluzione hè stata truvata in dimustrà u travagliu fattu à l'altri è dopu discutendu. Ci riunitemu una volta à settimana per una ora è mostranu dettagli di suluzioni à e tarei chì avemu fattu in a settimana passata.
Durante a manifestazione, hè necessariu di revelà i dettagli di u compitu è assicuratevi di dimustrà u so funziunamentu.
U rapportu pò esse realizatu cù una lista di cuntrollu.1. Entre in u cuntestu. Da induve vene u compitu, perchè era ancu necessariu?
2. Cumu era u prublema risolta prima ? Per esempiu, un clicu massivu di u mouse era necessariu, o era impussibile di fà nunda.
3. Cumu migliurà. Per esempiu: "Guardate, avà ci hè scriptosik, eccu u readme".
4. Mostra cumu si travaglia. Hè cunsigliatu di implementà direttamente qualchì scenariu d'utilizatori. Vogliu X, facciu Y, vecu Y (o Z). Per esempiu, aghju implementatu NGINX, fume l'url, è uttene 200 OK. Se l'azzione hè longa, preparate in anticipu per pudè vede più tardi. Hè cunsigliatu di ùn rompe micca troppu una ora prima di a demo, s'ellu hè fragile.
5. Spiegà quantu successu u prublema hè stata risolta, chì difficultà restanu, ciò chì ùn hè micca cumpletu, chì megliurenze sò pussibuli in u futuru. Per esempiu, avà CLI, allora ci sarà automatizazione cumpleta in CI.
Hè cunsigliatu per ogni parlante di mantene à 5-10 minuti. Se u vostru discorsu hè ovviamente impurtante è duverà più, coordinate questu in anticipu in u canali di sre-takeover.
Dopu à a parte in faccia ci hè sempre una discussione in u filu. Hè quì chì u feedback chì avemu bisognu nantu à i nostri compiti appare.
In u risultatu, un sondaghju hè realizatu per determinà l'utilità di ciò chì succede. Questu hè un feedback nantu à l'essenza di u discorsu è l'impurtanza di u compitu.
Conclusioni longu è ciò chì hè dopu
Pò esse chì u tonu di l'articulu hè un pocu pessimista. Questu hè sbagliatu. Dui livelli più bassi di feedback, vale à dì testi è prugrammazione di coppia, travaglianu. Micca perfetta cum'è in u sviluppu tradiziunale, ma ci hè un effettu pusitivu da questu.
I testi, in a so forma attuale, furnisce solu una cobertura parziale di codice. Parechje funzioni di cunfigurazione finiscinu senza teste. A so influenza nantu à u travagliu propiu quandu scrive u codice hè bassu. Tuttavia, ci hè un effettu da e teste d'integrazione, è permettenu di realizà senza paura i refactorings. Questu hè un grande successu. Inoltre, cù u cambiamentu di l'enfasi à u sviluppu in lingue d'altu livellu (avemu python, vai), u prublema si ne va. È ùn avete micca bisognu di assai cuntrolli per a "cola"; un cuntrollu di integrazione generale hè abbastanza.
U travagliu in coppie dipende più di e persone specifiche. Ci hè u fattore di compitu è e nostre cumpetenze soft. Cù certi pirsuni funziuna assai bè, cù altri travaglia peggiu. Ci sò sicuramente benefici da questu. Hè chjaru chì ancu s'è i reguli di u travagliu di coppia ùn sò micca abbastanza osservati, u fattu stessu di fà i travaglii inseme hà un effettu pusitivu nantu à a qualità di u risultatu. In modu persunale, mi pare di travaglià in coppie più faciule è più piacevule.
Modi di più altu livellu di influenzà l'OS - a pianificazione è u travagliu cù i travaglii precisamente producenu effetti: scambiu di cunniscenza di alta qualità è qualità di sviluppu megliu.
Conclusioni brevi in una linea
- I praticanti HR travaglianu in IaC, ma cù menu efficienza.
- Furtificà ciò chì travaglia.
- Venite cù i vostri meccanismi è e pratiche compensatorii.
Source: www.habr.com