Txat eztabaida batean oinarrituta
Berriki, benetako borrokak piztu dira DevOps eta SRE definizioaren inguruan.
Izan ere, modu askotan gai honi buruzko eztabaidak dagoeneko hortzak jarri dizkidaten arren, ni barne, gai honi buruzko nire ikuspegia Habra komunitateko epaitegira eramatea erabaki nuen. Interesa dutenentzat, ongi etorria cat. Eta dena berriro has dadila!
historiaurrea
Beraz, antzina, software-garatzaile eta zerbitzari-administratzaile talde bat bereizita bizi ziren. Lehenengoak arrakastaz idatzi zuen kodea, bigarrenak, lehenengoari zuzendutako hainbat hitz bero eta maitagarri erabiliz, zerbitzariak konfiguratu zituen, aldian-aldian garatzaileengana etorriz eta erantzunez "denak funtzionatzen du nire makinan" integrala jasoz. Negozioa softwarearen zain zegoen, dena inaktibo zegoen, aldian-aldian apurtzen zen, denak urduri zeuden. Batez ere nahaspila hau guztia ordaindu zuenak. Lanpara loriatsuen garaia. Bada, dagoeneko badakizu nondik datorren DevOps.
DevOps praktiken sorrera
Orduan mutil serioak etorri ziren eta esan zuten: hau ez da industria bat, ezin duzu horrela lan egin. Eta bizitza zikloaren ereduak ekarri zituzten. Hona hemen, adibidez, V-eredua.
Beraz, zer ikusten dugu? Negozio bat kontzeptu batekin dator, arkitektoek irtenbideak diseinatzen dituzte, garatzaileek kodea idazten dute eta gero huts egiten du. Norbaitek produktua nolabait probatzen du, norbaitek azken erabiltzaileari entregatzen dio nolabait, eta miragarri eredu honen irteeran, nonbait, negozio bezero bakarti bat dago itsaso ondoan agindutako eguraldiaren zain. Prozesu hori ezartzeko aukera emango diguten metodoak behar ditugula ondorioztatu genuen. Eta horiek ezarriko zituzten praktikak sortzea erabaki genuen.
Praktika zer den gaiari buruzko digresio liriko bat
Praktika esan nahi dut teknologia eta diziplina uztartzea. Adibide bat azpiegitura terraform kodea erabiliz deskribatzeko praktika da. Diziplina azpiegitura kodearekin nola deskribatu da, garatzailearen buruan dago eta teknologia terraforma bera da.
Eta DevOps praktikak deitzea erabaki zuten - Garapenetik Operazioetara esan nahi zutela uste dut. Hainbat gauza burutsu asmatu genituen: CI/CD praktikak, IaC printzipioan oinarritutako praktikak, horietako milaka. Eta goaz, garatzaileek kodea idazten dute, DevOps-eko ingeniariek sistemaren deskribapena kode moduan funtzionatzeko sistema bihurtzen dute (bai, kodea, zoritxarrez, deskribapen bat besterik ez da, baina ez sistemaren gorpuztea), entregak jarraitzen du, eta abar. Atzoko administratzaileak, praktika berriak menperatu ostean, harro hartu ziren DevOps ingeniari gisa, eta dena hortik joan zen. Eta arratsaldea, eta goiza... barkatu, ez hortik.
Ez da dena ona berriro, Jainkoari eskerrak
Dena baretu bezain laster, eta hainbat "metodologo" maltzur DevOps praktikei buruzko liburu lodiak idazten hasi zirenean, eztabaidak isilean piztu ziren DevOps ingeniari ezaguna nor zen eta DevOps ekoizpen-kultura dela, desadostasuna sortu zen berriro. Bat-batean, softwarearen entrega erabateko zeregin ez-hutsa dela konturatu zen. Garapen-azpiegitura bakoitzak bere pila bat du, nonbait muntatu behar duzu, nonbait ingurunea zabaldu behar duzu, hemen Tomcat behar duzu, hemen abiarazteko modu maltzur eta konplikatu bat behar duzu - oro har, zure burua kolpatzen ari da. Eta arazoa, bitxia bada ere, prozesuen antolaketan egon zen nagusiki: entrega-funtzio hau, botila-lepo bat bezala, prozesuak blokeatzen hasi zen. Gainera, inork ez zuen Operazioak bertan behera utzi. V-ereduan ez da ikusten, baina eskuinaldean bizi-ziklo osoa dago oraindik. Ondorioz, beharrezkoa da nolabait azpiegitura mantentzea, monitorizazioa kontrolatzea, gorabeherak konpontzea eta entregatzeaz ere arduratzea. Horiek. Eseri oin batekin bai garapenean bai funtzionamenduan - eta bat-batean Garapena eta Eragiketak izan zen. Eta gero, mikrozerbitzuen iragarpen orokorra zegoen. Eta horiekin batera, tokiko makinen garapena hodeira mugitzen hasi zen - saiatu zerbait lokalean arazketa egiten, dozenaka eta ehunka mikrozerbitzu badaude, etengabeko entrega bizirauteko baliabide bihurtzen da. βEnpresa xume txikiβ batentzat ondo zegoen, baina hala ere? Eta Google?
Google-ren SRE
Google etorri zen, kaktus handiena jan eta erabaki zuen: ez dugu hau behar, fidagarritasuna behar dugu. Eta fidagarritasuna kudeatu behar da. Eta fidagarritasuna kudeatuko duten espezialistak behar ditugula erabaki nuen. SR ingeniariei deitu nien eta esan nien, hori da zuretzat, egin ezazue beti bezala. Hona hemen SLI, hona SLO, hemen monitorizazioa. Eta sudurra sartu zuen operazioetan. Eta bere "DevOps fidagarria" SRE deitu zuen. Dena ondo dagoela dirudi, baina Google-k ordaindu dezakeen hack zikin bat dago: SR ingeniarien posturako, garatzaile kualifikatuak ziren pertsonak kontratatu eta etxeko lan pixka bat egin zuten eta lan sistemen funtzionamendua ulertzen zuten. Gainera, Googlek berak arazoak ditu horrelako pertsonak kontratatzeko -batez ere hemen bere buruarekin lehiatzen delako- beharrezkoa da norbaiti negozio-logika deskribatzea. Entrega ingeniariei esleitu zitzaien, SR - ingeniariek fidagarritasuna kudeatzen dute (noski, ez zuzenean, baizik eta azpiegituran eraginez, arkitektura aldatuz, aldaketak eta adierazleak jarraituz, gorabeherak tratatuz). Polita, ahal duzu . Baina zer gertatzen da Google ez bazara, baina fidagarritasuna nolabait kezkagarria bada?
DevOps ideien garapena
Orduantxe iritsi zen Docker, lxc-tik hazi zena, eta orduan hainbat orkestrazio sistemak, hala nola Docker Swarm eta Kubernetes, eta DevOps ingeniariek arnasa hartu zuten: praktiken bateratzeak erraztu zuen entrega. Hain sinplifikatu zuen, non garatzaileei entrega ere azpikontratatu ahal izateko - zer da deployment.yaml. Kontenedoreak arazoa konpontzen du. Eta CI/CD sistemen heldutasuna fitxategi bat idazteko mailan dago jada eta badoaz - garatzaileek beraiek kudea dezakete. Eta gero, gure SRE propioa nola egin dezakegun hitz egiten hasten gara,... edo behintzat norbaitekin.
SRE ez dago Google-n
Beno, ados, entregatu genuen, badirudi arnasestu egin dezakegula, garai onetara bueltatu, administratzaileek prozesadorea kargatzen zutenean, sistemak sintonizatu eta lasai-lasai katiletatik ulertezina den zerbait hartzen zutenean... Gelditu. Ez da horregatik dena hasi dugu (pena!). Bat-batean, Google-ren ikuspegian praktika bikainak erraz har ditzakegula: ez da garrantzitsua prozesadorearen karga, eta ez zenbat aldiz aldatzen ditugun diskoak edo hodeian kostua optimizatzen duguna, baina negozioaren neurketak berdinak dira. SLx. Eta inork ez die kendu azpiegituren kudeaketa, eta gorabeherak konpondu behar dituzte, eta aldian-aldian egon behar dute, eta, oro har, negozio prozesuen gainean egon. Eta lagunok, hasi pixkanaka maila onean programatzen, Google dagoeneko zure zain dago.
Laburtzeko. Bat-batean, baina dagoeneko irakurtzeaz nekatuta zaude eta ezin duzu itxaron artikuluari buruzko iruzkin batean egileari tu eta idazteko. DevOps entrega-praktika gisa beti izan da eta izango da. Eta ez doa inora. SRE praktika operatiboen multzo gisa entrega hau oso arrakastatsua da.
Iturria: www.habr.com