Saluton, Habr! Antaŭe, mi plendis pri vivo en la Infrastrukturo kiel kodparadigmo kaj nenion proponis por solvi la nunan situacion. Hodiaŭ mi revenas por diri al vi, kiaj aliroj kaj praktikoj helpos vin eskapi el la abismo de malespero kaj direkti la situacion en la ĝusta direkto.
En la antaŭa artikolo Mi konigis miajn impresojn pri ĉi tiu areo, provis pripensi la nunan situacion en ĉi tiu areo, kaj eĉ sugestis, ke normaj praktikoj konataj de ĉiuj programistoj povus helpi. Povas ŝajni, ke estis multaj plendoj pri la vivo, sed ne estis proponoj pri eliro el la nuna situacio.
Kiuj ni estas, kie ni estas kaj kiajn problemojn ni havas
Ni estas nuntempe en la Sre Onboarding Team, kiu konsistas el ses programistoj kaj tri infrastrukturaj inĝenieroj. Ni ĉiuj provas skribi Infrastrukturon kiel kodon (IaC). Ni faras tion ĉar ni esence scias kiel skribi kodon kaj havas historion de esti "super mezumo" programistoj.
- Ni havas aron da avantaĝoj: certa fono, scio pri praktikoj, la kapablo skribi kodon, deziro lerni novajn aferojn.
- Kaj estas saga parto, kiu ankaŭ estas minuso: manko de scio pri infrastruktura aparataro.
La teknologia stako, kiun ni uzas en nia IaC.
- Terraform por krei rimedojn.
- Packer por kunmeti bildojn. Ĉi tiuj estas bildoj de Vindozo, CentOS 7.
- Jsonnet por fari potencan konstruon en drone.io, kaj ankaŭ por generi pakiston json kaj niajn terraformajn modulojn.
- Lazura.
- Ansible kiam vi preparas bildojn.
- Python por helpaj servoj kaj provizantaj skriptoj.
- Kaj ĉio ĉi en VSCode kun kromaĵoj dividitaj inter teamanoj.
Konkludo de mia estis jene: mi provis enŝovi (antaŭ ĉio en mi mem) optimismon, mi volis diri, ke ni provos la alirojn kaj praktikojn konatajn al ni por trakti la malfacilaĵojn kaj kompleksaĵojn, kiuj ekzistas en ĉi tiu areo.
Ni nuntempe luktas kun la sekvaj problemoj de IaC:
- Neperfekteco de iloj kaj rimedoj por koda evoluo.
- Malrapida deplojo. Infrastrukturo estas parto de la reala mondo, kaj ĝi povas esti malrapida.
- Manko de aliroj kaj praktikoj.
- Ni estas novaj kaj ne scias multon.
Ekstrema Programado (XP) al la savo
Ĉiuj programistoj konas Ekstreman Programadon (XP) kaj la praktikojn kiuj staras malantaŭ ĝi. Multaj el ni laboris kun ĉi tiu aliro, kaj ĝi sukcesis. Do kial ne uzi la principojn kaj praktikojn fiksitajn tie por venki infrastrukturajn defiojn? Ni decidis preni ĉi tiun aliron kaj vidi kio okazas.
Kontrolante la aplikeblecon de la XP-aliro al via industrioJen priskribo de la medio, por kiu XP bone taŭgas, kaj kiel ĝi rilatas al ni:
1. Dinamike ŝanĝante programajn postulojn. Estis klare al ni, kio estas la fina celo. Sed la detaloj povas varii. Ni mem decidas kien ni devas taksi, do la postuloj periode ŝanĝiĝas (ĉefe per ni mem). Se ni prenas la SRE-teamon, kiu faras la aŭtomatigon mem, kaj mem limigas la postulojn kaj amplekson de laboro, tiam ĉi tiu punkto bone taŭgas.
2. Riskoj kaŭzitaj de fikstempaj projektoj uzantaj novan teknologion. Ni povas renkonti riskojn kiam ni uzas iujn aferojn nekonatajn al ni. Kaj ĉi tio estas 100% nia kazo. Nia tuta projekto estis la uzo de teknologioj, kiujn ni ne plene konis. Ĝenerale, ĉi tio estas konstanta problemo, ĉar... Estas multaj novaj teknologioj aperantaj en la infrastruktura sektoro la tutan tempon.
3,4. Malgranda, samlokita etendita evolua teamo. La aŭtomatigita teknologio, kiun vi uzas, ebligas unuomajn kaj funkciajn testojn. Ĉi tiuj du punktoj ne tute konvenas al ni. Unue, ni ne estas kunordigita teamo, kaj due, estas naŭ el ni, kiuj povas esti konsiderataj kiel granda teamo. Kvankam, laŭ iuj difinoj de "granda" teamo, multe estas 14+ homoj.
Ni rigardu kelkajn XP-praktikojn kaj kiel ili influas la rapidecon kaj kvaliton de retrosciigo.
XP Reago-Buklo-Principo
Laŭ mia kompreno, retrosciigo estas la respondo al la demando, ĉu mi faras la ĝustan aferon, ĉu ni iras tien? XP havas dian skemon por ĉi tio: temporeligibuklo. La interesa afero estas, ke ju pli malaltaj ni estas, des pli rapide ni kapablas igi la OS respondi la necesajn demandojn.
Ĉi tio estas sufiĉe interesa temo por diskuto, ke en nia IT-industrio eblas rapide akiri OS. Imagu, kiel dolorige estas fari projekton dum ses monatoj kaj nur tiam ekscii, ke estis eraro ĉe la komenco mem. Ĉi tio okazas en dezajno kaj en iu ajn konstruado de kompleksaj sistemoj.
En nia kazo de IaC, sugestoj helpas nin. Mi tuj faros etan ĝustigon al la supra diagramo: la eldona plano ne havas monatan ciklon, sed okazas plurajn fojojn tage. Estas kelkaj praktikoj ligitaj al ĉi tiu OS-ciklo, kiujn ni rigardos pli detale.
Grava: sugestoj povas esti solvo al ĉiuj problemoj deklaritaj supre. Kombinita kun XP-praktikoj, ĝi povas eltiri vin el la abismo de malespero.
Kiel eltiri vin el la abismo de malespero: tri praktikoj
Provoj
Testoj estas menciitaj dufoje en la XP-religibuklo. Ne estas nur tiel. Ili estas ekstreme gravaj por la tuta Ekstrema Programado-tekniko.
Oni supozas, ke vi havas Unuajn kaj Akceptajn testojn. Iuj donas al vi sugestojn post kelkaj minutoj, aliaj post kelkaj tagoj, do ili daŭras pli longe por skribi kaj estas reviziitaj malpli ofte.
Estas klasika testa piramido, kiu montras, ke devus esti pli da testoj.
Kiel ĉi tiu kadro aplikas al ni en projekto de IaC? Efektive... tute ne.
- Unuaj testoj, malgraŭ tio, ke devus esti multaj, ne povas esti tro multaj. Aŭ ili testas ion tre nerekte. Fakte, ni povas diri, ke ni tute ne skribas ilin. Sed jen kelkaj aplikoj por tiaj provoj, kiujn ni povis fari:
- Testante jsonnet-kodon. Ĉi tio, ekzemple, estas nia drona asemblea dukto, kiu estas sufiĉe komplika. La jsonnet-kodo estas bone kovrita de testoj.
Ni uzas ĉi tion . - Testoj por skriptoj kiuj estas ekzekutitaj kiam la rimedo komenciĝas. Skriptoj estas skribitaj en Python, kaj tial testoj povas esti skribitaj sur ili.
- Testante jsonnet-kodon. Ĉi tio, ekzemple, estas nia drona asemblea dukto, kiu estas sufiĉe komplika. La jsonnet-kodo estas bone kovrita de testoj.
- Eble eblas kontroli la agordon en testoj, sed ni ne faras tion. Eblas ankaŭ agordi regulojn pri kontrolado de agordo de rimedoj per . Tamen, la ĉekoj tie estas simple tro bazaj por teraformo, sed multaj testskriptoj estas skribitaj por AWS. Kaj ni estas sur Azure, do ĉi tio denove ne validas.
- Testoj de integriĝo de komponantoj: dependas de kiel vi klasifikas ilin kaj kie vi metas ilin. Sed ili esence funkcias.
Jen kiel integrigaj testoj aspektas.
Ĉi tio estas ekzemplo dum konstruado de bildoj en Drone CI. Por atingi ilin, vi devas atendi 30 minutojn por ke la Packer-bildo formiĝos, tiam atendi aliajn 15 minutojn por ke ili pasu. Sed ili ekzistas!Bilda kontrola algoritmo
- Packer devas unue prepari la bildon tute.
- Apud la testo estas teraformo kun loka ŝtato, kiun ni uzas por deploji ĉi tiun bildon.
- Malfaldante, malgranda modulo kuŝanta proksime estas uzata por faciligi labori kun la bildo.
- Post kiam la VM estas deplojita de la bildo, kontroloj povas komenciĝi. Esence, kontroloj estas faritaj per aŭto. Ĝi kontrolas kiel la skriptoj funkciis ĉe ekfunkciigo kaj kiel funkcias la demonoj. Por fari tion, per ssh aŭ winrm ni ensalutas en la ĵus levitan maŝinon kaj kontrolas la agordan staton aŭ ĉu la servoj funkcias.
- La situacio estas simila kun integrigaj testoj en moduloj por terraform. Jen mallonga tabelo klariganta la trajtojn de tiaj testoj.
Reago pri la dukto estas ĉirkaŭ 40 minutoj. Ĉio okazas dum tre longa tempo. Ĝi povas esti uzata por regreso, sed por nova evoluo ĝi estas ĝenerale nereala. Se vi estas tre, tre preta por ĉi tio, preparu kurantajn skriptojn, tiam vi povas redukti ĝin al 10 minutoj. Sed ĉi tiuj ankoraŭ ne estas Unuaj testoj, kiuj faras 5 pecojn en 100 sekundoj.
La foresto de Unuaj testoj dum kunvenado de bildoj aŭ teraformaj moduloj instigas ŝanĝi la laboron al apartaj servoj, kiuj povas simple ruliĝi per REST, aŭ al Python-skriptoj.
Ekzemple, ni bezonis certigi, ke kiam la virtuala maŝino komenciĝas, ĝi registras sin en la servo , kaj kiam la virtuala maŝino estis detruita, ĝi forigis sin.
Ĉar ni havas ScaleFT kiel servon, ni estas devigitaj labori kun ĝi per la API. Tie estis skribita envolvaĵo, kiun vi povis tiri kaj diri: "Eniru kaj forigu ĉi tion kaj tion." Ĝi konservas ĉiujn necesajn agordojn kaj alirojn.
Ni jam povas skribi normalajn testojn por tio, ĉar ĝi ne diferencas de ordinara programaro: ia apiha estas mokita, vi tiras ĝin, kaj vidu kio okazas.
Rezultoj de la testoj: Unuo-testado, kiu devus doni la OS en minuto, ne donas ĝin. Kaj specoj de provoj pli altaj en la piramido estas efikaj, sed kovras nur parton de la problemoj.
Parprogramado
Testoj estas, kompreneble, bonaj. Vi povas skribi multajn el ili, ili povas esti de malsamaj tipoj. Ili laboros je siaj niveloj kaj donos al ni sugestojn. Sed la problemo kun malbonaj Unuaj testoj, kiuj donas la plej rapidan OS, restas. Samtempe, mi ankoraŭ volas rapidan OS kun kiu estas facila kaj agrabla labori. Sen mencii la kvaliton de la rezulta solvo. Feliĉe, ekzistas teknikoj, kiuj povas doni eĉ pli rapidajn reagojn ol unutestoj. Ĉi tio estas parprogramado.
Skribante kodon, vi volas ricevi komentojn pri ĝia kvalito kiel eble plej rapide. Jes, vi povas skribi ĉion en ĉefbranĉo (por ne rompi ion ajn por iu ajn), fari tiran peton en Github, asigni ĝin al iu, kies opinio havas pezon, kaj atendi respondon.
Sed vi povas atendi longan tempon. Homoj estas ĉiuj okupataj, kaj la respondo, eĉ se ekzistas, eble ne estas de la plej alta kvalito. Supozu, ke la respondo tuj venis, la recenzisto tuj komprenis la tutan ideon, sed la respondo ankoraŭ venas malfrue, post la fakto. Mi deziras, ke ĝi estu pli frue. Ĉi tio celas parprogramado - tuj, en la momento de verkado.
Malsupre estas la paraj programaj stiloj kaj ilia aplikebleco por labori pri IaC:
1. Klasika, Sperta + Sperta, ŝanĝu laŭ tempigilo. Du roloj - ŝoforo kaj navigisto. Du homoj. Ili funkcias per la sama kodo kaj ŝanĝas rolojn post certa antaŭfiksita tempodaŭro.
Ni konsideru la kongruon de niaj problemoj kun stilo:
- Problemo: neperfekteco de iloj kaj iloj por koda evoluo.
Negativa efiko: necesas pli longe por disvolvi, ni malrapidiĝas, la ritmo/ritmo de laboro perdiĝas.
Kiel ni batalas: ni uzas malsaman ilaron, komunan IDE kaj ankaŭ lernas ŝparvojojn. - Problemo: Malrapida deplojo.
Negativa efiko: pliigas la tempon necesan por krei funkciantan kodon. Ni enuiĝas atendante, niaj manoj etendas fari ion alian dum ni atendas.
Kiel ni batalas: ni ne venkis ĝin. - Problemo: manko de aliroj kaj praktikoj.
Negativa efiko: ne estas scio pri kiel fari ĝin bone kaj kiel fari ĝin malbone. Plilongigas la ricevon de sugestoj.
Kiel ni batalas: reciproka interŝanĝo de opinioj kaj praktikoj en duopa laboro preskaŭ solvas la problemon.
La ĉefa problemo kun uzado de ĉi tiu stilo en IaC estas la neegala ritmo de laboro. En tradicia programaro-disvolviĝo, vi havas tre unuforman movadon. Vi povas pasigi kvin minutojn kaj skribi N. Pasigi 10 minutojn kaj skribi 2N, 15 minutojn - 3N. Ĉi tie oni povas pasigi kvin minutojn kaj skribi N, kaj poste pasigi aliajn 30 minutojn kaj skribi dekonon de N. Ĉi tie oni scias nenion, vi estas blokita, stulta. La esploro prenas tempon kaj malatentigas de programado mem.
Konkludo: en sia pura formo ĝi ne taŭgas por ni.
2. Ping-pongo. Ĉi tiu aliro implikas unu personon skribantan la teston kaj alian farantan la efektivigon por ĝi. Konsiderante la fakton, ke ĉio estas komplika kun Unuaj testoj, kaj vi devas skribi integrigan teston, kiu postulas longan tempon por programi, la tuta facileco de ping-pongo malaperas.
Mi povas diri, ke ni provis apartigi respondecojn por desegni testan skripton kaj efektivigi kodon por ĝi. Unu partoprenanto elpensis la skripton, en ĉi tiu parto de la laboro li respondecis, li havis la lastan vorton. Kaj la alia respondecis pri efektivigo. Ĝi funkciis bone. La kvalito de la skripto kun ĉi tiu aliro pliiĝas.
Konkludo: ve, la ritmo de laboro ne permesas la uzon de ping-pongo kiel parprogramadpraktiko en IaC.
3.Forta Stilo. . La ideo estas, ke unu partoprenanto fariĝas la direktiva navigisto, kaj la dua prenas la rolon de la ekzekutisto. En ĉi tiu kazo, la rajto fari decidojn apartenas ekskluzive al la navigisto. La ŝoforo nur presas kaj povas influi tion, kio okazas per vorto. La roloj ne ŝanĝiĝas dum longa tempo.
Bona por lernado, sed postulas fortajn molajn kapablojn. Ĉi tie ni ŝanceliĝis. La tekniko estis malfacila. Kaj eĉ ne temas pri infrastrukturo.
Konkludo: ĝi povas esti uzata, ni ne rezignas provi.
4. Mobbing, svarmado kaj ĉiuj konataj sed ne listigitaj stiloj Ni ne konsideras ĝin, ĉar Ni ne provis ĝin kaj estas neeble paroli pri ĝi en la kunteksto de nia laboro.
Ĝeneralaj rezultoj pri uzado de parprogramado:
- Ni havas neegalan ritmon de laboro, kio estas konfuza.
- Ni renkontis nesufiĉe bonajn molajn kapablojn. Kaj la temo ne helpas venki ĉi tiujn niajn mankojn.
- Longaj provoj kaj problemoj kun iloj malfaciligas parigitan disvolviĝon.
5. Malgraŭ tio, estis sukcesoj. Ni elpensis nian propran metodon "Konverĝo - Diverĝo". Mi mallonge priskribos kiel ĝi funkcias.
Ni havas konstantajn partnerojn dum kelkaj tagoj (malpli ol semajno). Ni faras unu taskon kune. Ni sidas kune dum iom da tempo: unu skribas, la alia sidas kaj rigardas la subtenan teamon. Poste ni disiĝas dum kelka tempo, ĉiu faras kelkajn sendependajn aferojn, poste ni denove kuniĝas, sinkronigas tre rapide, faras ion kune kaj denove disiĝas.
Planado kaj komunikado
La lasta bloko de praktikoj, per kiuj OS-problemoj estas solvitaj, estas la organizo de laboro kun la taskoj mem. Ĉi tio ankaŭ inkluzivas la interŝanĝon de sperto, kiu estas ekster parlaboro. Ni rigardu tri praktikojn:
1. Celoj tra la celo-arbo. Ni organizis la ĝeneralan administradon de la projekto per arbo kiu iras senfine en la estontecon. Teknike, la spurado estas farita en Miro. Estas unu tasko - ĝi estas meza celo. De ĝi iras aŭ pli malgrandaj celoj aŭ grupoj de taskoj. La taskoj mem venas de ili. Ĉiuj taskoj estas kreitaj kaj konservitaj sur ĉi tiu tabulo.
Ĉi tiu skemo ankaŭ provizas retrosciigon, kiu okazas unufoje tage kiam ni sinkronigas ĉe amaskunvenoj. Havi komunan planon antaŭ ĉiuj, sed strukturitan kaj tute malfermitan, permesas al ĉiuj konscii pri tio, kio okazas kaj kiom ni progresis.
Avantaĝoj de vida vizio de taskoj:
- Kaŭzo. Ĉiu tasko kondukas al iu tutmonda celo. Taskoj estas grupigitaj en pli malgrandajn celojn. La infrastruktura domajno mem estas sufiĉe teknika. Ne ĉiam estas tuj klare, kian specifan efikon, ekzemple, skribi kurlibron pri migrado al alia nginx havas sur la komerco. Havi la celkarton proksime faras ĝin pli klara.
Kaŭzeco estas grava eco de problemoj. Ĝi rekte respondas la demandon: "Ĉu mi faras la ĝustan aferon?" - Paralelismo. Estas naŭ el ni, kaj estas simple fizike neeble ĵeti ĉiujn al unu tasko. Ankaŭ taskoj de unu areo eble ne ĉiam sufiĉas. Ni estas devigitaj paraleligi laboron inter malgrandaj laborgrupoj. Samtempe, la grupoj sidas sur sia tasko dum iom da tempo, ili povas esti plifortigitaj de iu alia. Foje homoj forfalas de ĉi tiu laborgrupo. Iu ferias, iu faras raporton por la DevOps-konf, iu skribas artikolon pri Habr. Scii kiajn celojn kaj taskojn oni povas fari paralele fariĝas tre grava.
2. Anstataŭaj prezentistoj de matenaj kunvenoj. Ĉe stand-ups ni havas ĉi tiun problemon - homoj faras multajn taskojn paralele. Foje taskoj estas loze ligitaj kaj ne estas kompreno pri kiu faras kion. Kaj la opinio de alia grupano estas tre grava. Ĉi tio estas pliaj informoj, kiuj povas ŝanĝi la kurson de solvado de la problemo. Kompreneble, kutime estas iu kun vi, sed konsiloj kaj konsiloj estas ĉiam utilaj.
Por plibonigi ĉi tiun situacion, ni uzis la teknikon "Ŝanĝi la Gvidan Standon". Nun ili turniĝas laŭ certa listo, kaj ĉi tio efikas. Kiam estas via vico, vi estas devigita plonĝi kaj kompreni kio okazas por aranĝi bonan Scrum-renkontiĝon.
3. Interna demo. Helpo en solvi problemon de parprogramado, bildigo sur la problem-arbo kaj helpo ĉe scrum-renkontiĝoj matene estas bona, sed ne ideala. Kiel paro, vi estas limigita nur de via scio. La taskarbo helpas tutmonde kompreni kiu faras kion. Kaj la prezentisto kaj kolegoj ĉe la matena kunveno ne plonĝos profunde en viajn problemojn. Ili certe eble maltrafos ion.
La solvo estis trovita en pruvo de la laboro farita unu al la alia kaj poste diskuti ĝin. Ni renkontas unufoje semajne dum unu horo kaj montras detalojn pri solvoj al taskoj, kiujn ni faris dum la pasinta semajno.
Dum la pruvo, necesas malkaŝi la detalojn de la tasko kaj nepre pruvi ĝian funkciadon.
La raporto povas esti farita per kontrola listo.1. Eniru en kuntekston. De kie venis la tasko, kial ĝi eĉ estis necesa?
2. Kiel la problemo estis solvita antaŭe? Ekzemple, amasa musklakado estis postulata, aŭ estis neeble fari ion ajn.
3. Kiel ni plibonigas ĝin. Ekzemple: "Rigardu, nun estas scriptosik, jen la readme."
4. Montru kiel ĝi funkcias. Estas konsilinde rekte efektivigi iun uzantan scenaron. Mi volas X, mi faras Y, mi vidas Y (aŭ Z). Ekzemple, mi deplojas NGINX, fumas la urlon kaj ricevas 200 OK. Se la ago estas longa, preparu ĝin anticipe por ke vi povu montri ĝin poste. Estas konsilinde ne rompi ĝin tro multe unu horon antaŭ la demo, se ĝi estas fragila.
5. Klarigu kiel sukcese la problemo estis solvita, kiaj malfacilaĵoj restas, kio ne estas finita, kiaj plibonigoj eblas estonte. Ekzemple, nun CLI, tiam estos plena aŭtomatigo en CI.
Estas konsilinde por ĉiu parolanto konservi ĝin al 5-10 minutoj. Se via parolado evidente gravas kaj daŭros pli longe, kunordigu tion anticipe en la kanalo sre-takeover.
Post la vizaĝ-al-vizaĝa parto ĉiam estas diskuto en la fadeno. Ĉi tie aperas la sugestoj, kiujn ni bezonas pri niaj taskoj.
Kiel rezulto, enketo estas farita por determini la utilecon de kio okazas. Ĉi tio estas retrosciigo pri la esenco de la parolado kaj la graveco de la tasko.
Longaj konkludoj kaj kio sekvas
Povas ŝajni, ke la tono de la artikolo estas iom pesimisma. Ĉi tio estas malĝusta. Du pli malaltaj niveloj de retrosciigo, nome testoj kaj parprogramado, funkcias. Ne tiel perfekta kiel en tradicia evoluo, sed estas pozitiva efiko de ĝi.
Testoj, en sia nuna formo, disponigas nur partan kodpriraportadon. Multaj agordaj funkcioj finiĝas neprovitaj. Ilia influo sur la reala laboro dum skribado de kodo estas malalta. Tamen, estas efiko de integrigaj testoj, kaj ili permesas al vi sentime efektivigi refaktorigojn. Ĉi tio estas bonega atingo. Ankaŭ, kun la ŝanĝo de fokuso al evoluo en altnivelaj lingvoj (ni havas python, iru), la problemo foriras. Kaj vi ne bezonas multajn kontrolojn por la "gluo"; ĝenerala integriga kontrolo sufiĉas.
Labori duope dependas pli de specifaj homoj. Estas la taskofaktoro kaj niaj molaj kapabloj. Ĉe kelkaj homoj ĝi funkcias tre bone, ĉe aliaj ĝi funkcias pli malbone. Estas certe avantaĝoj de ĉi tio. Estas klare, ke eĉ se la reguloj de parlaboro ne estas sufiĉe observataj, la fakto mem plenumi taskojn kune havas pozitivan efikon sur la kvalito de la rezulto. Persone, mi trovas labori duope pli facila kaj pli agrabla.
Pli altnivelaj manieroj influi la OS - planado kaj laboro kun taskoj precize produktas efikojn: altkvalita scio-interŝanĝo kaj plibonigita disvolva kvalito.
Mallongaj konkludoj en unu linio
- HR-praktikistoj laboras en IaC, sed kun malpli da efikeco.
- Plifortigu tion, kio funkcias.
- Elpensu viajn proprajn kompensajn mekanismojn kaj praktikojn.
fonto: www.habr.com