Zer behar da IT enpresa batek arrakasta izateko 2019an? Hitzaldi eta topaketetako irakasleek jende arruntarentzat beti ulergarriak ez diren hitz ozen asko esaten dituzte. Hedapen-denbora, mikrozerbitzuak, monolitoa uztea, DevOps eraldaketa eta askoz, askoz gehiago lortzeko borroka. Hitzezko edertasuna baztertzen badugu eta zuzenean eta errusieraz hitz egiten badugu, dena tesi soil batera dator: kalitate handiko produktu bat egin eta taldearentzat erosotasunez egin.
Azken honek garrantzi kritikoa hartu du. Enpresak, azkenean, ondorioztatu du garapen prozesu eroso batek produktibitatea areagotzen duela, eta dena arazketa eta erloju baten moduan funtzionatzen badu, egoera kritikoetan maniobrarako tartea ere ematen duela. Garai batean, maniobra honen mesedetan, pertsona adimendun jakin batek babeskopiak egin zituen, baina industria garatzen ari da, eta DevOps ingeniariengana iritsi ginen - garapenaren eta kanpoko azpiegituren arteko elkarrekintza-prozesua zerbait egoki bihurtzen duten pertsonak. ez dago txamanismoarekin.
Istorio “modular” hau oso zoragarria da, baina... Gertatu zen administratzaile batzuei bat-batean DevOps izena jarri zitzaiela, eta DevOps ingeniariei beraiek telepatia eta argi-ikuspegiaren trebetasunak gutxienez eskatzen hasi zitzaizkiela.
Azpiegiturak hornitzeko arazo modernoei buruz hitz egin aurretik, defini dezagun zer esan nahi dugun termino honekin. Momentu honetan, egoera halako moduan garatu da, non kontzeptu honen bikoiztasunera iritsi gara: azpiegiturak baldintzapean kanpokoak eta baldintzapean barnekoak izan daitezke.
Kanpoko azpiegituraz taldea garatzen ari den zerbitzu edo produktuaren funtzionaltasuna bermatzen duen guztia esan nahi dugu. Aplikazio edo webguneen zerbitzariak, ostalaritza eta produktuaren funtzionaltasuna bermatzen duten beste zerbitzu batzuk dira.
Barne-azpiegiturak garapen-taldeak berak eta beste langile batzuek erabiltzen dituzten zerbitzuak eta ekipamenduak biltzen ditu, asko izan ohi direnak. Hauek kodea biltegiratzeko sistemen barne zerbitzariak dira, lokalean zabaldutako zereginen kudeatzailea eta intranet korporatiboan dagoen guztia, dena, dena.
Zer egiten du sistema-administratzaileak enpresa batean? Intranet oso korporatibo hau administratzeko lanez gain, askotan kezka ekonomikoen zama hartzen du bulegoko ekipoen funtzionagarritasuna ziurtatzeko. Administratzailea sistema-unitate berri bat edo ordezko ordenagailu eramangarri bat azkar arrastatuko duen tipo bera da atzeko gelatik erabiltzeko prest, teklatu berri bat eman eta bulegoetan zehar lau hanketan arakatuko duena, Ethernet kablea luzatuz. Administratzailea barneko eta kanpoko zerbitzarien tokiko jabea eta agintaria da, baina baita enpresa-exekutiboa ere. Bai, administratzaile batzuek sistemaren planoan bakarrik lan egin dezakete, hardwarerik gabe. "azpiegitura-sistemaren administratzaile" azpiklase batean banatu behar dira. Eta batzuk esklusiboki bulegoko ekipoen zerbitzuan espezializatuta daude; zorionez, enpresak ehun pertsona baino gehiago baditu, lana ez da inoiz amaitzen. Baina bietako bat ere ez dira devopeak.
Nor dira DevOps? Devops software garapenak kanpoko azpiegiturekin duen elkarrekintzari buruz hitz egiten duten mutilak dira. Zehatzago esanda, devop modernoak garapen eta inplementazio prozesuetan parte hartzen dute ftp-ra eguneraketak besterik gabe kargatu dituzten administratzaileek baino askoz sakonago. DevOps ingeniari baten funtsezko zereginetako bat garapen taldeen eta produktuaren azpiegituren arteko elkarrekintza prozesu eroso eta eraginkortasunez egituratua bermatzea da. Pertsona hauek dira atzera botatzeko eta inplementatzeko sistemak hedatzeaz arduratzen direnak; pertsona horiek garatzaileei kargaren zati bat kentzen diete eta ahal den neurrian beren zeregin garrantzitsuan kontzentratzen dutenak. Aldi berean, devops-ek ez du inoiz kable berririk exekutatu edo ordenagailu eramangarri berririk aterako atzeko gelan (c) KO
Zein da harrapaketa?
"Nor da DevOps?" galderari alorreko langileen erdiak “Beno, laburbilduz, hau da admin nor...” bezalako zerbait erantzuten hasten dira eta testuan aurrerago. Bai, garai batean, DevOps ingeniariaren lanbidea zerbitzuen mantentzeari dagokionez administratzailerik talentu handienetatik sortzen ari zenean, haien arteko desberdintasunak ez ziren denentzat nabariak. Baina orain, taldean devops eta administratzaileen funtzioak zeharo desberdinak direnean, onartezina da elkarren artean nahastea, ezta berdintzea ere.
Baina zer esan nahi du horrek negozioarentzat?
Kontratazioa, dena da.
"Sistema Administratzailea" lanpostu bat irekitzen duzu, eta bertan zerrendatutako baldintzak "garapenarekin eta bezeroekin elkarrekintza", "CI/CD entrega-sistema", "enpresako zerbitzarien eta ekipamenduen mantentzea", "barne sistemen administrazioa" eta abar dira. on; ulertzen duzu enpresariak zentzugabekeriak esaten ari dela. Kontua da "Sistema Administratzailea" ordez hutsik dagoen titulua "DevOps ingeniaria" izan behar dela, eta titulu hori aldatzen bada, dena bere tokian sartzen da.
Hala ere, zer inpresio ematen du halako lanpostu huts bat irakurtzean? Konpainia makina anitzeko operadore baten bila dabilela, bertsioak kontrolatzeko eta kontrolatzeko sistema zabalduko duena eta bihurritua hortzekin estutuko duena...
Baina lan-merkatuan droga-mendekotasun-maila ez handitzeko, nahikoa da hutsik dauden lanpostuei beren izen propioekin deitzea eta argi ulertzea DevOps ingeniari bat eta sistema administratzaile bat bi entitate desberdin direla. Baina enpresaburu batzuek hautagai bati ahalik eta eskakizun-zerrenda zabalena aurkezteko duten nahi ezinezkoak sistema-administratzaile "klasikoek" inguruan gertatzen dena ulertzeari eragiten dio. Zer, lanbidea aldatzen ari da eta garaien atzean daude?
Ez ez eta beste behin ez. Enpresaren barne zerbitzariak kudeatuko dituzten azpiegituren administratzaileak, edo L2/L3 laguntza-postuak okupatuko dituztenak eta beste langile batzuk lagunduko dituztenak, ez dira joan eta ez dira joango.
Espezialista hauek DevOps ingeniari bihurtu al daitezke? Noski ahal dutela. Izan ere, erlazionatutako ingurunea da, sistema administratzeko trebetasunak behar dituena, baina horretaz gain, monitorizazio, entrega sistemekin eta, oro har, garapen eta proba taldearekin elkarreragin estua gehitzen da.
DevOps-en beste arazo bat
Izan ere, dena ez da soilik kontrataziora eta administratzaileen eta debopenen arteko etengabeko nahasmenera mugatzen. Noizbait, negozioak eguneraketak emateko eta garapen-taldeak azken azpiegiturarekin elkarreragiteko arazoa izan zuen.
Beharbada, begi distiratsuak zituen osaba bat konferentzia baten eszenatokian altxatu eta esan zuen: "Hau egiten dugu eta DevOps deitzen diogu. Mutil hauek zure arazo guztiak konponduko dituzte" - eta DevOps praktikak ezarri ondoren konpainian bizitza zein ona den kontatzen hasi zen.
Hala ere, ez da nahikoa DevOps ingeniari bat kontratatzea dena behar den bezala funtziona dezan. Konpainiak DevOps erabateko eraldaketa jasan behar du, hau da, gure DevOps-en eginkizuna eta gaitasunak ere argi ulertu behar dira produktuen garapen eta proba-taldearen aldetik. Gai honi buruzko istorio “zoragarri” bat dugu, leku batzuetan gertatzen ari den basakeria guztia guztiz erakusten duena.
Egoera. DevOps bertsioak itzultzeko sistema bat zabaltzeko beharrezkoa da, nola funtzionatuko duen benetan sakondu gabe. Demagun Erabiltzaileen sistemaren barruan izen-abizenak eta pasahitza eremu bereiziak daudela. Produktuaren bertsio berri bat ateratzen da, baina garatzaileentzat, "errebota" bat dena konponduko duen makila magiko bat besterik ez da, eta nola funtzionatzen duen ere ez dakite. Beraz, adibidez, hurrengo adabakian garatzaileek lehen eta abizenen eremuak konbinatu zituzten, ekoizpenera zabaldu zuten, baina bertsioa motela da arrazoiren batengatik. Zer ari da gertatzen? Zuzendaritza devops-era dator eta "Tira etengailua!" esaten dio, hau da, aurreko bertsiora itzultzeko eskatzen dio. Zer egiten du devops-ak? Aurreko bertsiora itzultzen da, baina garatzaileek ez zutenez itzulera hori nola egin zen jakin nahi, inork ez zion esan devops taldeari datu-basea ere atzera egin behar zela. Ondorioz, dena matxuratzen zaigu, eta webgune motel baten ordez, erabiltzaileek "500" errore bat ikusten dute, bertsio zaharrak ez duelako funtzionatzen datu-base berriko eremuekin. Devops-ek ez daki honen berri. Garatzaileak isilik daude. Zuzendaritza nerbioak eta dirua galtzen hasten da eta babeskopiak gogoratzen ditu, haietatik atzera egitea eskainiz, "zerbaitek behintzat funtziona dezan". Ondorioz, erabiltzaileek beren datu guztiak galtzen dituzte denbora tarte batean.
Fruitu lehorrak, noski, devops-etara joaten dira, "ez zuten itzulera sistema egokirik egin", eta inori ez zaio axola istorio honetako altzariak garatzaileak direnik.
Ondorioa sinplea da: DevOps-en ikuspegi normal bat izan gabe, ezer gutxi balio du.
Gogoratu beharreko gauza nagusia: DevOps ingeniari bat ez da magoa, eta kalitatezko komunikaziorik eta garapenarekin bi norabideko elkarrekintzarik gabe, ez ditu bere zereginei aurre egingo. Garatzaileak ezin dira bakarrik utzi beren "arazoekin" edo "ez nahastu garatzaileekin, haien lana kodetzea da" komandoa eman, eta, ondoren, une kritiko batean dena behar den bezala funtzionatuko duela espero. Ez da horrela funtzionatzen.
Funtsean, DevOps kudeaketa eta teknologiaren arteko mugan dagoen konpetentzia bat da. Gainera, ez dago begi bistakoa koktel honetan kudeaketa baino teknologia gehiago egon behar dela. Benetan garapen prozesu azkarragoak eta eraginkorragoak eraiki nahi badituzu, zure devops taldean fidatu behar zara. Tresna egokiak ezagutzen ditu, antzeko proiektuak gauzatu ditu, badaki nola egin. Lagundu iezaiozu, entzun bere aholkuak, ez saiatu nolabaiteko unitate autonomo batean isolatzen. Administratzaileek beren kabuz lan egiten badute, devopek ez dute ezertarako balio kasu honetan; ezin izango zaituzte hobetzen lagundu, zuk zeuk laguntza hau onartu nahi ez baduzu.
Eta azken gauza bat: azpiegituren administratzaileak iraintzeari utzi. Bere lan-aurrealde oso garrantzitsua dute. Bai, administratzaile bat DevOps ingeniari bihur daiteke, baina hori pertsonak berak eskatuta gertatu behar da, eta ez presiopean. Eta ez dago gaizki sistema-administratzaile batek sistema-administratzaile izaten jarraitu nahi izateak - hau da bere lanbide bereizia eta bere eskubidea. Eraldaketa profesional bat egin nahi baduzu, ez duzu inoiz ahaztu behar teknologia-gaitasunak ez ezik, kudeaketa-gaitasunak ere garatu beharko dituzula. Ziurrenik, zure esku egongo zara lider gisa pertsona horiek guztiak elkartzea eta hizkuntza berean komunikatzen irakastea.
Iturria: www.habr.com