Garatzaileak Martekoak dira, administratzaileak Artizarrakoak

Kasualitateak ausazkoak dira, eta, egia esan, beste planeta batean zegoen...

Hiru arrakasta eta porrot istorio partekatu nahiko nituzke backend garatzaile batek administratzaileekin taldean lan egiten dutenari buruz.

Istorio bat.
Web estudioan, langile kopurua esku batekin zenbatu daiteke. Gaur diseinu-diseinatzailea zara, bihar backender zara, etzi administratzailea zara. Alde batetik, esperientzia izugarria lor dezakezu. Bestalde, arlo guztietan konpetentzia falta dago. Oraindik gogoan dut lehen lan eguna, oraindik berde nago, nagusiak esaten du: “Ireki masilla”, baina ez dakit zer den. Administratzaileekin komunikazioa baztertuta dago, zeren zeu administratzailea zara. Azter ditzagun egoera honen alde onak eta txarrak.

+ Botere guztia zure esku dago.
+ Ez dago inori zerbitzarirako sarbidea eskatzeko beharrik.
+ Erreakzio denbora azkarra norabide guztietan.
+ Trebetasunak ondo hobetzen ditu.
+ Produktuaren arkitektura osoa ulertzea.

— Erantzukizun handia.
— Ekoizpena hausteko arriskua.
— Zaila da arlo guztietan espezialista ona izatea.

Ez zait interesatzen, goazen aurrera

Bigarren istorioa.
Enpresa handia, proiektu handia. 5-7 langile eta hainbat garapen talde dituen administrazio sail bat dago. Horrelako enpresa batera lanera etortzen zarenean, administratzaile bakoitzak uste du ez zarela hona etorri produktu bat lantzera, zerbait apurtzera baizik. Ez sinatutako NDAk ez elkarrizketan egindako hautaketak ez dute adierazten kontrakoa. Ez, gizon hau bere esku txiki zikinekin etorri zen gure musuen ekoizpena hondatzera. Hori dela eta, horrelako pertsona batekin komunikazio minimo bat behar duzu; gutxienez, eranskailu bat bota dezakezu erantzuteko. Ez erantzun proiektuaren arkitekturari buruzko galderei. Gomendagarria da sarbiderik ez ematea taldeko buruak eskatu arte. Eta eskatzen duenean, eskatutakoa baino are pribilegio gutxiagorekin itzuliko du. Horrelako administratzaileekiko komunikazio ia guztia garapen-sailaren eta administrazio-sailaren arteko zulo beltzak xurgatzen du. Ezinezkoa da arazoak berehala konpontzea. Baina ezin zara pertsonalki etorri - administratzaileak lanpetuegia daude 24/7. (Zer egiten ari zara denbora guztian?) Errendimenduaren ezaugarri batzuk:

• Produkzioan inplementatzeko batez besteko denbora 4-5 ordukoa da
• Gehienezko hedapen-denbora ekoizpenean 9 ordu
• Garatzaile batentzat, ekoizpenean dagoen aplikazio bat kutxa beltz bat da, ekoizpen zerbitzaria bera bezala. Zenbat dira guztira?
• Argitalpenen kalitate baxua, maiz akatsak
• Garatzaileak ez du parte hartzen kaleratzeko prozesuan

Beno, zer espero nuen, noski, jende berria ez da produkzioan sartzen uzten. Tira, ados, pazientzia hartu ondoren, besteen konfiantza irabazten hasten gara. Baina arrazoiren batengatik, gauzak ez dira hain sinpleak administratzaileekin.

1. ekintza. Administratzailea ikusezina da.
Argitaratze eguna, garatzailea eta administratzailea ez dira komunikatzen. Administratzaileak ez du galderarik. Baina gero ulertzen duzu zergatik. Administratzailea printzipiozko pertsona bat da, ez du mezularirik, ez dio bere telefono zenbakia inori ematen eta ez du sare sozialetan profilik. Ez dago haren argazkirik ere inon, zer itxura duzu lagun? Arduradun arduradunarekin 15 minutu inguru esertzen gara harrituta, Voyager 1 honekin komunikazioa ezarri nahian, gero mezu bat agertzen da mezu elektroniko korporatiboan amaitu duela. Posta bidez erantzungo al dugu? Zergatik ez? Erosoa, ezta? Beno, ados, hozten gaitezen. Prozesua martxan dago jada, ez dago atzera bueltarik. Irakurri mezua berriro. "Amaitu dut". Zer bukatu duzu? Non? Non bilatu behar zaitut? Hemen ulertzen duzu zergatik den normala askatzeko 4 ordu. Garapen shock bat jasotzen dugu, baina kaleratzea amaitzen dugu. Jada ez dago askatzeko gogorik.

2. akta. Ez bertsio hori.
Hurrengo kaleratzea. Esperientzia lortuta, zerbitzarirako beharrezko software eta liburutegien zerrendak sortzen hasten gara administratzaileentzat, batzuen bertsioak adieraziz. Beti bezala, administratzaileak zerbait amaitu duela dioen irrati-seinale ahula jasotzen dugu. Erregresio proba hasten da, eta horrek ordubete inguru irauten du. Dena funtzionatzen ari dela dirudi, baina akats kritiko bat dago. Funtzio garrantzitsuak ez du funtzionatzen. Hurrengo orduak danbolinekin dantzan, kafe-hondarrean igartzea eta kode bakoitzaren errepaso zehatza izan ziren. Administratzaileak dena egin duela dio. Garatzaile makurrak idatzitako aplikazioak ez du funtzionatzen, baina zerbitzariak funtzionatzen du. Berarentzat galderarik? Ordu baten amaieran, administratzaileak produkzio-zerbitzariko liburutegiaren bertsioa txat eta bingora bidaltzea lortzen dugu - ez da behar duguna. Administratzaileari eskatzen diogu behar den bertsioa instalatzeko, baina erantzun moduan ezin duela egin hau OS paketeen kudeatzailean bertsio hau ez dagoelako. Hemen, bere memoriaren hutsuneetatik, kudeatzaileak gogoratzen du beste administratzaile batek dagoeneko konpondu zuela arazo hori, eskatutako bertsioa eskuz muntatuz besterik gabe. Baina ez, gureak ez du hau egingo. Araudiak debekatzen du. Karl, hainbat ordu daramatzagu hemen eserita, zein da denbora muga?! Beste shock bat jasotzen dugu eta nolabait oharra amaitzen dugu.

3. akta, laburra
Premiazko txartela, funtsezko funtzionalitateak ez du funtzionatzen produkzioko erabiltzaileetako batentzat. Pare bat ordu ematen ditugu zulatu eta egiaztatzen. Garapen ingurune batean, dena funtzionatzen du. Argi dago ideia ona litzatekeela php-fpm erregistroak aztertzea. Garai hartan ez zegoen ELK edo Prometheus bezalako erregistro sistemarik proiektuan. Tiketa bat irekitzen dugu administrazio departamenturako, zerbitzariko php-fpm erregistroetarako sarbidea eman dezaten. Hemen ulertu behar duzu arrazoi batengatik sarbidea eskatzen ari garela, ez al zara gogoratzen zulo beltza eta administratzaileak 24/7 lanpetuta egoteaz? Erregistroak beraiek begiratzeko eskatzen badiezu, "bizitza honetan ez" lehentasuna duen zeregina da. Tiketa sortu zen, berehalako erantzuna jaso genuen administrazio saileko buruak: "Ez zenuke ekoizpen-erregistroetarako sarbiderik behar, idatzi akatsik gabe". Gortina bat.

4. akta eta aurrerago
Ekoizpenean dozenaka arazo biltzen ari gara oraindik, liburutegien bertsio ezberdinengatik, konfiguratu gabeko softwareagatik, prestatu gabeko zerbitzarien kargagatik eta beste arazo batzuengatik. Noski, kode akatsak ere badaude, ez diegu administratzaileei leporatuko bekatu guztien errua, proiektu horretarako ohiko eragiketa bat besterik ez dugu aipatuko. Begiralearen bidez abiarazitako atzealdeko langile asko genituen, eta script batzuk gehitu behar izan ziren cron-era. Batzuetan, langile hauek lan egiteari uzten zioten. Ilara zerbitzariaren karga tximista-abiaduran hazi zen, eta erabiltzaile tristeak biraka kargatzaileari begiratu zioten. Horrelako langileak azkar konpontzeko, nahikoa zen berrabiaraztea, baina berriro ere, administratzaile batek bakarrik egin zezakeen hau. Oinarrizko operazio hori egiten zen bitartean, egun oso bat pasa zitekeen. Hemen, noski, azpimarratzekoa da programatzaile okertuek langileak idatzi behar dituztela huts egin ez dezaten, baina erortzen direnean, ondo legoke ulertzea zergatik, eta hori batzuetan ezinezkoa den ekoizpenerako sarbide faltagatik, noski, eta, ondorioz, garatzailearen erregistro falta.

Eraldaketa.
Hori guztia denbora luzez jasan ondoren, taldearekin batera guretzat arrakastatsuagoa izan zen norabide batean ibiltzen hasi ginen. Laburbilduz, zein arazo izan genituen?

• Garatzaileen eta administrazio sailaren arteko kalitatezko komunikazio falta
• Administratzaileek, antza denez (!), ez dute batere ulertzen aplikazioa nola egituratuta dagoen, zein menpekotasun dituen eta nola funtzionatzen duen.
• Garatzaileek ez dute ulertzen nola funtzionatzen duen ekoizpen-inguruneak eta, ondorioz, ezin dute arazoei modu eraginkorrean erantzun.
• Zabaltze-prozesuak luzeegia hartzen du.
• Argitalpen ezegonkorrak.

Zer egin dugu?
Argitalpen bakoitzeko, bertsio-oharrak zerrenda bat sortu zen, hurrengo bertsioak funtziona dezan zerbitzarian egin beharreko lanen zerrenda barne. Zerrendak hainbat atal zituen, administratzaileak egin beharreko lanak, kaleratzearen arduradunak eta garatzaileak. Garatzaileek produkzio-zerbitzari guztietarako root ez den sarbidea jaso zuten, eta horrek garapena, oro har, eta arazoen konponketa, bereziki, azkartu zituen. Garatzaileek ere badakite nola funtzionatzen duen ekoizpena, zer zerbitzutan banatzen den, non eta zenbat balio duten erreplikak. Borroka karga batzuk argiago geratu dira, eta horrek, dudarik gabe, kodearen kalitatean eragiten du. Askapen prozesuan komunikazioa berehalako mezularietako baten txatean gertatu zen. Lehenik eta behin, ekintza guztien erregistroa genuen, eta bigarrenik, komunikazioa ingurune hurbilago batean egiten zen. Ekintzen historia izateak behin baino gehiagotan ahalbidetu die langile berriei arazoak azkarrago konpontzeko. Paradoxa bat da, baina honek askotan administratzaileei laguntzen zien. Ez naiz ziur esateko konpromisoa hartuko, baina iruditzen zait administratzaileak gehiago ulertzen hasi direla proiektua nola funtzionatzen duen eta nola idatzita dagoen. Batzuetan, detaile batzuk elkarbanatzen genituen. Batez besteko kaleratzeko denbora ordu batera murriztu da. Batzuetan 30-40 minututan egin genuen. Akatsen kopurua nabarmen murriztu da, hamar aldiz ez bada. Jakina, beste faktore batzuek ere eragina izan zuten kaleratze denboraren murrizketan, autotestek adibidez. Kaleratze bakoitzaren ostean, atzera begirakoak egiten hasi ginen. Talde osoak ideia bat izan dezan zer berri, zer aldatu den eta zer kendu den. Zoritxarrez, administratzaileak ez ziren beti haiengana etortzen, tira, administratzaileak lanpetuta daude... Garatzaile gisa nire lanaren gogobetetasuna handitu egin da, dudarik gabe. Zure gaitasun-eremuan dauden ia arazo guztiak azkar konpontzen dituzunean, goian sentitzen zara. Geroago, ulertuko dut neurri batean devops kultura bat sartu genuela, ez guztiz, noski, baina eraldaketaren hasiera hura ere ikusgarria izan zen.

Hirugarren istorioa
Hasi. Administratzaile bat, garapen sail txikia. Iristean zero osoa naiz, zeren... Ez dut inon sarbiderik postatik izan ezik. Administratzaileari idazten diogu eta sarbidea eskatzen diogu. Horrez gain, langile berria ezagutzen duela eta saio-hasiera/pasahitza igortzeko beharra dago. Biltegitik eta VPNtik sarbidea ematen dute. Zergatik eman wiki, teamcity, rundesk sarbidea? Alferrikako gauzak backend zati osoa idazteko deitu zioten pertsona batentzat. Denborarekin bakarrik lortzen dugu tresna batzuetarako sarbidea. Etorrerak, noski, mesfidantza izan zuen. Pixkanaka-pixkanaka proiektuaren azpiegiturak nola funtzionatzen duen ulertzen saiatzen ari naiz txat eta galderen bidez. Funtsean, ez dut ezer ezagutzen. Ekoizpena lehengo kutxa beltz bera da. Baina hori baino gehiago, probak egiteko erabiltzen diren etapa zerbitzariak ere kutxa beltza dira. Ezin dugu Git-eko adar bat bertan zabaldu baino ezer egin. Ezin dugu gure aplikazioa .env fitxategiak bezala konfiguratu. Eragiketa horietarako sarbidea ez da ematen. Test zerbitzariko aplikazioaren konfigurazioan lerro bat aldatzeko eskatu behar duzu. (Bada teoria bat administratzaileek proiektuan garrantzitsuak sentitzea ezinbestekoa dela; konfigurazioetan lerroak aldatzeko eskatzen ez bazaie, ez dira beharrezkoak izango). Tira, beti bezala, ez al da komenigarria? Hau azkar aspertzen da, administratzailearekin zuzeneko elkarrizketa baten ondoren jakin dugu garatzaileak kode txarra idazteko jaio zirela, berez pertsona ezgaiak direla eta hobe dela produkziotik urruntzea. Baina hemen ere proba zerbitzarietatik, badaezpada. Gatazka azkar areagotzen ari da. Ez dago administrazioarekin komunikaziorik. Egoera larriagotu egiten da bera bakarrik egoteak. Honakoa argazki tipikoa da. Askatu. Zenbait funtzionalitate ez dute funtzionatzen. Denbora asko behar dugu zer gertatzen ari den jakiteko, garatzaileen hainbat ideia botatzen dira txatean, baina halako egoeran dagoen administratzaileak bere gain hartzen du normalean garatzaileak direla errudunak. Orduan txatean idazten du, itxaron, zuzendu dut. Arazoa zein den informazioarekin istorio bat atzean uzteko eskatzen zaienean, aitzakia toxikoak jasotzen ditugu. Esaterako, ez sartu sudurra ez dagokion tokian. Garatzaileek kodea idatzi behar dute. Oso tristea da proiektu batean gorputz-mugimendu asko pertsona bakar batengandik igarotzen diren eta berak bakarrik daukan aukera denak behar dituen eragiketak egiteko. Horrelako pertsona bat ikaragarria da. Devops ideiak merkaturatzeko denbora murrizten ahalegintzen badira, orduan horrelako pertsonak Devops ideien etsairik okerrena dira. Zoritxarrez, oihala hemen ixten da.

PS Garatzaileei eta administratzaileei buruz apur bat hitz egin ondoren jendearekin txatetan, nire mina partekatzen zuen jendea ezagutu nuen. Baina bazen ere horrelakorik inoiz topatu ez zutela esaten zutenak. Devops-eko hitzaldi batean, Anton Isanini (Alfa Bank) galdetu nion administratzaileen moduan botila-lepoaren arazoari nola egin zioten aurre, eta esan zuen: "Botoiekin ordezkatu genituen". Bide batez podcasta bere parte-hartzearekin. Sinetsi nahiko nuke etsai baino askoz administratzaile on gehiago daudela. Eta bai, hasierako irudia benetako korrespondentzia da.

Iturria: www.habr.com