DevOps oso gai ezaguna bihurtu da azken urteotan. Jende askok amesten du bertan sartzea, baina, praktikak erakusten duen moduan, askotan soldaten mailagatik bakarrik.
Batzuek DevOps zerrendatzen dute beren curriculumean, nahiz eta ez duten beti terminoaren funtsa ezagutzen edo ulertzen. Batzuek uste dute Ansible, GitLab, Jenkins, Terraform eta antzekoak ikasi ondoren (zerrenda zure gustuaren arabera jarraitu daitekeela), berehala "devopsist" bihurtuko zarela. Hau, noski, ez da egia.
Azken urteotan, batez ere, hainbat enpresatan DevOps-en ezarpenean parte hartu dut. Hori baino lehen, 20 urte baino gehiagoz lan egin zuen sistemaren administratzailetik hasi eta IT zuzendarirainoko postuetan. Gaur egun DevOps ingeniari nagusia Playgendary-n.
Nor da DevOps
Artikulu bat idazteko ideia beste galdera baten ondoren sortu zen: "nor da DevOps?" Oraindik ez dago zehaztutako terminorik zer edo nor den. Erantzun batzuk dagoeneko honetan daude . Lehenik eta behin, puntu nagusiak nabarmenduko ditut, eta gero nire behaketak eta gogoetak partekatuko ditut.
DevOps ez da kontratatu daitekeen espezialista, ez utilitate multzo bat eta ez ingeniariekin garatzaileen sail bat.
DevOps filosofia eta metodologia bat da.
Beste era batera esanda, garatzaileei sistema-administratzaileekin modu aktiboan elkarreragiten laguntzen dien praktika multzo bat da. Hau da, lan-prozesuak elkarren artean konektatzea eta integratzea.
DevOps-en etorrerarekin, espezialisten egitura eta eginkizunak berdin jarraitu zuten (garatzaileak daude, ingeniariak daude), baina elkarrekintza-arauak aldatu egin dira. Sailen arteko mugak lausotu egin dira.
DevOps-en helburuak hiru puntutan deskriba daitezke:
- Softwarea aldizka eguneratu behar da.
- Softwarea azkar egin behar da.
- Softwarea eroso eta denbora laburrean zabaldu behar da.
Ez dago tresna bakarra DevOps-erako. Hainbat produktu konfiguratzeak, entregatzeak eta aztertzeak ez du esan nahi DevOps enpresan agertu denik. Tresna asko daude eta guztiak fase desberdinetan erabiltzen dira, baina helburu komun bat dute.
Eta hau DevOps tresnen zati bat baino ez da
Duela 2 urte baino gehiago daramatzat jendea elkarrizketatzen DevOps ingeniari kargurako, eta konturatu naiz zein garrantzitsua den terminoaren funtsa argi ulertzea. Partekatu nahi ditudan esperientzia, behaketa eta pentsamendu zehatzak pilatu ditut.
Elkarrizketa esperientziatik, argazki hau ikusten dut: DevOps lan-titulutzat hartzen duten espezialistek normalean gaizki-ulertuak izaten dituzte lankideekin.
Adibide deigarri bat zegoen. Gazte bat elkarrizketa batera etorri zen bere curriculumean hitz burutsu asko zituela. Bere azken hiru lanetan, 5-6 hilabeteko esperientzia zuen. Bi startup utzi nituen, "ez zirelako aireratu". Baina hirugarren enpresari buruz, han inork ez duela ulertzen esan zuen: garatzaileek kodea idazten dute Windows-en, eta zuzendariak kode hori Docker arruntean "biltarazi" eta CI/CD kanalizazioan integratzera behartzen du. Tipoak gauza negatibo asko esan zituen bere egungo lantokiari eta bere lankideei buruz; nik erantzun nahi nuen: "Beraz, ez duzu elefanterik salduko".
Orduan hautagai bakoitzarentzat nire zerrendan goian dagoen galdera bat egin nion.
β Zer esan nahi du DevOps zuretzat pertsonalki?
- Orokorrean ala nola hautematen dut?
Haren iritzi pertsonala interesatzen zitzaidan. Terminoaren teoria eta jatorria ezagutzen zituen, baina ez zegoen oso ados haiekin. DevOps lan-titulua zela uste zuen. Hor dago bere arazoen erroa. Baita iritzi bereko beste espezialista batzuk ere.
Enpresaburuek, "DevOps-en magia"ri buruz asko entzunda, "magia" hori sortuko duen pertsona bat aurkitu nahi dute. Eta "DevOps lana da" kategoriako eskatzaileek ez dute ulertzen ikuspegi honekin ezin izango dituztela itxaropenak bete. Eta, oro har, DevOps idatzi zuten beren curriculumean, joera bat delako eta asko ordaintzen dutelako.
DevOps metodologia eta filosofia
Metodologia teorikoa eta praktikoa izan daiteke. Gure kasuan, bigarrena da. Goian aipatu dudan bezala, DevOps adierazitako helburuak lortzeko erabiltzen diren praktika eta estrategien multzoa da. Eta kasu bakoitzean, enpresaren negozio prozesuen arabera, nabarmen desberdina izan daiteke. Horrek ez du hobe edo okerrago egiten.
DevOps metodologia helburuak lortzeko bitarteko bat baino ez da.
Orain DevOps filosofia zer den. Eta hau da ziurrenik galdera zailena.
Nahiko zaila da erantzun labur eta labur bat formulatzea, oraindik ez baita formalizatu. Eta DevOps filosofiaren jarraitzaileak praktikan gehiago arduratzen direnez, ez dago filosofatzeko astirik. Hala ere, prozesu oso garrantzitsua da. Gainera, ingeniaritza jarduerekin zuzenean lotuta dago. Ezagutza arlo espezializatu bat ere badago - .
Nire unibertsitatean ez zegoen halako irakasgairik, 90eko hamarkadan aurkitzen nituen materialak erabiliz dena ikasi behar nuen nire kabuz. Gaia hautazkoa da ingeniaritza hezkuntzarako, hortik erantzunaren formalizazio falta. Baina DevOps-en serio murgilduta dauden pertsona horiek konpainiaren prozesu guztien "espiritu" edo "inkontzientetasun integral" bat sentitzen hasten dira.
Nire esperientzia erabiliz, filosofia honen βpostulatuβ batzuk formalizatzen saiatu nintzen. Emaitza hau da:
- DevOps ez da ezagutza edo jarduera eremu bereizi batean bereiz daitekeen zerbait independentea.
- Enpresako langile guztiek DevOps metodologia gidatu behar dute beren jarduerak planifikatzerakoan.
- DevOps-ek enpresa bateko prozesu guztietan eragiten du.
- DevOps enpresa bateko edozein prozesuren denbora-kostuak murrizteko existitzen da, bere zerbitzuen garapena eta bezeroaren erosotasun handiena bermatzeko.
- DevOps, hizkuntza modernoan, konpainiako langile guztien jarrera proaktiboa da, denbora kostuak murrizteko eta gure inguruko IT produktuen kalitatea hobetzera zuzenduta.
Nire "postulatu" eztabaidarako gai bereizia dela uste dut. Baina orain badago zerbait eraikitzeko.
DevOps-ek egiten duena
Hemen gakoa komunikazioa da. Komunikazio asko daude, eta horien abiarazleak DevOps ingeniari bera izan beharko luke. Zergatik da hori? Hau filosofia eta metodologia delako, eta orduan bakarrik ingeniaritza ezagutza.
Ezin dut mendebaldeko lan-merkatuaz %100eko konfiantzarekin hitz egin. Baina asko dakit Errusiako DevOps merkatuari buruz. Ehunka elkarrizketaz gain, azken urte eta erdian Errusiako enpresa eta banku handientzako "DevOps ezarpena" zerbitzurako ehunka aurresalmenta teknikotan parte hartu dut.
Errusian, DevOps oso gaztea da oraindik, baina dagoeneko trending topic. Nik dakidala, Moskun bakarrik 2019an 1000 pertsona baino gehiagoko espezialisten eskasia izan zen. Eta enpresaburuentzako Kubernetes hitza ia zezenentzako trapu gorri bat bezalakoa da. Tresna honen atxikitzaileak prest daude erabiltzeko, nahiz eta beharrezkoa ez den eta ekonomikoki errentagarria izan. Enpresaburuak ez du beti ulertzen zein kasutan zer den egokiagoa erabiltzea, eta hedapen egokiarekin, Kubernetes kluster bat mantentzea 2-3 aldiz gehiago kostatzen da aplikazio bat ohiko kluster eskema erabiliz zabaltzea baino. Erabili benetan behar duzun tokian.
DevOps ezartzea garestia da diru aldetik. Eta justifikatzen da beste arlo batzuetan onura ekonomikoak ekartzen dituen lekuetan bakarrik, eta ez bere kabuz.
DevOps-eko ingeniariak dira, hain zuzen ere, aitzindariak: haiek izan beharko lukete lehenak izan beharko luketenak metodologia hau enpresan ezartzen eta prozesuak eraikitzen. Honek arrakasta izan dezan, espezialistak etengabe interaktuatu behar du maila guztietako langile eta lankideekin. Esan ohi dudan bezala, konpainiako langile guztiek parte hartu behar dute DevOps ezarpen-prozesuan: garbitzailetik hasi eta zuzendari nagusira arte. Eta hau ezinbesteko baldintza da. Taldeko kide txikienak ez badaki eta ulertzen zer den DevOps eta zergatik egiten diren zenbait antolakuntza-ekintza, orduan inplementazio arrakastatsuak ez du funtzionatuko.
Gainera, DevOps ingeniari batek administrazio-baliabide bat erabili behar du noizean behin. Adibidez, "ingurumen erresistentzia" gainditzeko - taldea DevOps tresnak eta metodologia onartzeko prest ez dagoenean.
Garatzaileak kodea eta probak bakarrik idatzi behar ditu. Horretarako, ez du behar ordenagailu eramangarri super-adarrik, proiektuaren azpiegitura osoa zabaldu eta lokalean laguntzeko. Adibidez, front-end garatzaile batek aplikazioaren elementu guztiak gordetzen ditu bere ordenagailu eramangarrian, datu-basea, S3 emuladorea (minio), etab barne. Hau da, denbora asko ematen du tokiko azpiegitura hori mantentzen eta bakarka borrokatzen du halako konponbide baten arazo guztiekin. Aurrealdeko kodea garatu beharrean. Horrelako pertsonak oso erresistenteak izan daitezke edozein aldaketaren aurrean.
Baina badira, aitzitik, tresna eta metodo berriak aurkezteaz eta prozesu honetan aktiboki parte hartzen duten taldeak. Kasu honetan ere, DevOps ingeniariaren eta taldearen arteko komunikazioa ez zen bertan behera utzi.
DevOps behar ez denean
DevOps beharrezkoa ez den egoerak daude. Hau gertaera bat da - ulertu eta onartu behar da.
Lehenik eta behin, edozein enpresari (batez ere enpresa txikiei) aplikatzen zaie, haien irabaziak bezeroei informazio zerbitzuak eskaintzen dizkieten informatika-produktuen presentziaren edo ezaren menpe zuzenean ez daudenean. Eta hemen ez gara enpresaren webguneaz ari, izan βbisita-txartelβ estatiko bat edo albiste bloke dinamikoekin, etab.
DevOps beharrezkoa da zure bezeroaren gogobetetasuna eta zuregana berriro itzultzeko nahia bezeroarekin elkarreragiteko informazio-zerbitzu horien erabilgarritasunaren, kalitatearen eta bideratzearen araberakoak direnean.
Adibide deigarri bat banku ezagun bat da. Enpresak ez du ohiko bezeroen bulegorik, dokumentuen fluxua posta edo mezularitza bidez egiten da, eta langile askok etxetik lan egiten dute. Konpainiak banku bat izateari utzi dio eta, nire ustez, DevOps teknologia garatuak dituen IT enpresa bihurtu da.
Beste hainbat adibide eta hitzaldi topa daitezke gaikako topaketen eta hitzaldien grabazioetan. Horietako batzuk pertsonalki bisitatu ditut - oso esperientzia erabilgarria da norabide horretan garatu nahi dutenentzat. Hona hemen YouTube kanaletarako estekak DevOps-en hitzaldi eta material onekin:
Begiratu orain zure negozioa eta pentsatu hau: zenbaterainoko mende dago zure enpresa eta bere irabaziak IT produktuen bezeroen elkarrekintza ahalbidetzeko?
Zure enpresak arraina denda txiki batean saltzen badu eta produktu informatiko bakarra bi 1C bada: Enpresa konfigurazioak (Kontabilitatea eta UNF), orduan ez du zentzurik DevOps-i buruz hitz egiteak.
Merkataritza eta fabrikazio enpresa handi batean lan egiten baduzu (adibidez, ehiza-fusilak ekoizten dituzu), orduan pentsatu beharko zenuke. Ekimena har dezakezu eta zure zuzendaritzari DevOps ezartzeko aukerak helarazi. Beno, eta aldi berean, eraman prozesu hau. Posizio proaktiboa DevOps filosofiaren oinarri garrantzitsuetako bat da.
Urteko fakturazio finantzarioaren tamaina eta bolumena ez da zure enpresak DevOps behar duen ala ez zehazteko irizpide nagusia.
Imajina dezagun bezeroekin zuzenean elkarreragiten ez duen industria-enpresa handi bat. Adibidez, zenbait autogile eta automobilgintzako enpresa. Orain ez nago ziur, baina nire iraganeko esperientziaren arabera, urte askotan bezeroen interakzio guztiak posta elektronikoz eta telefonoz egin ziren.
Haien bezeroak auto-saltzaileen zerrenda mugatua dira. Eta bakoitzari fabrikatzailearen espezialista bat esleitzen zaio. Barne dokumentu-fluxu guztia SAP ERP bidez gertatzen da. Barneko langileak informazio sistemaren bezeroak dira funtsean. Baina IS hau kluster-sistemak kudeatzeko bitarteko klasikoen bidez kontrolatzen da. Horrek DevOps praktikak erabiltzeko aukera baztertzen du.
Hortik ondorioa: horrelako enpresentzat, DevOps-en ezarpena ez da oso garrantzitsua den zerbait, metodologiaren helburuak artikuluaren hasieratik gogoratzen baditugu. Baina ez dut baztertzen gaur DevOps tresna batzuk erabiltzen dituztenik.
Bestalde, enpresa txiki asko daude DevOps metodologia, filosofia, praktika eta tresnak erabiliz softwarea garatzen dutenak. Eta uste dute DevOps ezartzearen kostua softwarearen merkatuan eraginkortasunez lehiatzeko aukera ematen dien kostua dela. Horrelako enpresen adibideak ikus daitezke .
DevOps behar den ala ez ulertzeko irizpide nagusia: zure IT produktuek zein balio duten enpresarentzat eta bezeroentzat.
Irabaziak sortzen dituen konpainiaren produktu nagusia softwarea bada, DevOps behar duzu. Eta ez da hain garrantzitsua beste produktu batzuk erabiliz benetako dirua irabazten baduzu. Honek ere barne hartzen ditu lineako dendak edo jokoekin mugikorretarako aplikazioak.
Edozein joko dago finantzaketari esker: jokalarien zuzenekoa edo zeharkakoa. Playgendary-n, mugikorretarako doako jokoak garatzen ditugu haien sorkuntzan zuzenean parte hartzen duten 200 pertsona baino gehiagorekin. Nola erabiltzen dugu DevOps?
Bai, goian deskribatutako berdina. Garatzaile eta probatzaileekin etengabe komunikatzen naiz, eta DevOps metodologia eta tresnetan langileentzako barne prestakuntza egiten dut.
Jenkins aktiboki erabiltzen ari gara CI/CD kanalizazio tresna gisa Unity-rekin muntaketa kanalizazio guztiak exekutatzeko eta gero App Store eta Play Market-en inplementatzeko. Tresna klasikotik gehiago:
- Asana - proiektuen kudeaketarako. Jenkins-ekin integrazioa konfiguratu da.
- Google Meet - bideo-bileretarako.
- Slack - komunikazioetarako eta hainbat alertatarako, Jenkins-en jakinarazpenak barne.
- Atlassian Confluence - dokumentaziorako eta talde-lanerako.
Gure berehalako planak dira SonarQube erabiliz kode estatikoen analisia sartzea eta Selenium erabiliz Interfazearen proba automatikoak egitea etengabeko integrazio fasean.
Horren ordez Ondorio baten
Ondoko hausnarketarekin amaitu nahi nuke: DevOps ingeniari oso kualifikatua izateko, ezinbestekoa da jendearekin zuzenean komunikatzen ikastea.
DevOps ingeniari bat taldeko jokalaria da. Eta kito. Lankideekin komunikatzeko ekimenak beregandik etorri behar du, eta ez egoera batzuen eraginpean. DevOps espezialista batek taldearentzat irtenbiderik onena ikusi eta proposatu behar du.
Eta bai, edozein konponbide ezartzeak eztabaida asko eskatuko du, eta azkenean guztiz alda daiteke. Era independentean garatuz, bere ideiak proposatuz eta gauzatuz, pertsona horrek gero eta balio handiagoa du taldearentzat zein enpresaburuarentzat. Hori, azken finean, bere hileko ordainsariaren zenbatekoan edo sari osagarrien moduan islatzen da.
Iturria: www.habr.com