Jakina da CTOren konpetentzia probatzen duela zeregin hori betetzen duen bigarren aldian. Gauza bat baita hainbat urtez enpresa batean lan egitea, harekin eboluzionatzea eta, kultur testuinguru berean egonda, pixkanaka ardura gehiago jasotzea. Eta beste oso bat da zuzendari tekniko postuan sartzea ondarearen ekipajea eta arazo mordoa alfonbra azpian txukun-txukun gordeta dituen enpresa batean.

Zentzu honetan, Leon Fire-ren esperientzia, partekatu zuena DevOpsConf, ez zehazki bakarra, baina bere esperientzia eta 20 urtean zehar probatzea lortu zuen rol ezberdinen kopuruak biderkatuta, oso erabilgarria da. Ebakiaren azpian 90 egunetan zehar dauden gertaeren kronologia eta beste norbaiti gertatzen zaizkionean barre egiteko dibertigarriak diren istorio asko daude, baina pertsonalki aurre egiteko hain dibertigarriak ez direnak.

Leonek oso koloretsu hitz egiten du errusieraz, beraz, 35-40 minutu badituzu, bideoa ikustea gomendatzen dizut. Testu bertsioa behean denbora aurrezteko.

Txostenaren lehen bertsioa pertsona eta prozesuekin lan egitearen deskribapen ongi egituratua izan zen, gomendio erabilgarriak zituena. Baina ez zituen bidean aurkitutako sorpresa guztiak helarazi. Hori dela eta, formatua aldatu eta enpresa berrian jack-in-the-box bat bezala agertu zitzaizkidan arazoak eta ordena kronologikoan konpontzeko metodoak aurkeztu nituen.

Hilabete lehenago

Istorio on asko bezala, hau alkoholarekin hasi zen. Taberna batean lagunekin eserita geunden, eta informatikan espezialisten artean espero bezala, denak negarrez ari ziren bere arazoengatik. Horietako bat lanez aldatu berria zen eta teknologiarekin, eta jendearekin eta taldearekin zituen arazoei buruz hitz egiten ari zen. Zenbat eta gehiago entzuten nuen, orduan eta gehiago konturatu nintzen berak kontratatu behar ninduela, azken 15 urteotan konpontzen ibili naizen motatako arazoak baitira. Hala esan nion, eta hurrengo egunean lan giroan elkartu ginen. Enpresak Teaching Strategies deitzen zen.

Teaching Strategies merkatuko liderra da jaiotzatik hiru urtera bitarteko haurrentzako curriculumean. “Paperezko” konpainia tradizionalak 40 urte ditu jada, eta plataformaren SaaS bertsio digitalak 10. Duela gutxi, teknologia digitala konpainiaren estandaretara egokitzeko prozesua hasi zen. Bertsio "berria" 2017an jarri zen martxan eta ia zaharra bezalakoa zen, okerrago funtzionatu zuen.

Interesgarriena da enpresa honen trafikoa oso aurreikusgarria dela - egun batetik bestera, urtetik urtera, oso argi aurreikus dezakezu zenbat jende etorriko den eta noiz. Esaterako, 13:15ak eta XNUMX:XNUMXak bitartean haurreskoletako haur guztiak oheratzen dira eta irakasleak informazioa sartzen hasten dira. Eta hori egunero gertatzen da, asteburuetan izan ezik, asteburuetan ia inork ez duelako lan egiten.

Aurrera begira, kontutan hartuko dut urteko trafiko handienaren garaian hasi nintzela lanean, eta hori arrazoi ezberdinengatik interesgarria da.

Plataformak, 2 urte besterik ez zituela zirudien, pila berezi bat zuen: ColdFusion & SQL Server 2008koa. ColdFusion, ez badakizu, eta ziurrenik ez dakizu, 90eko hamarkadaren erdialdean sortu zen PHP enpresarial bat da, eta orduz geroztik ez dut horren berririk entzun ere egin. Gainera: Ruby, MySQL, PostgreSQL, Java, Go, Python. Baina monolito nagusia ColdFusion eta SQL Server-en exekutatu zen.

Problems

Zenbat eta gehiago hitz egin enpresako langileekin lanari buruz eta zer arazo aurkitu ziren, orduan eta gehiago konturatzen nintzen arazoak ez zirela izaera teknikoa soilik. Ados, teknologia zaharra da, eta ez zuten lanik egin, baina arazoak izan ziren taldearekin eta prozesuekin, eta konpainia hori ulertzen hasi zen.

Tradizionalki, haien teknikariak txokoan esertzen ziren eta nolabaiteko lan egiten zuten. Baina gero eta negozio gehiago hasi zen bertsio digitaletik pasatzen. Horregatik, lanean hasi aurreko azken urtean, berriak agertu ziren enpresan: zuzendaritza batzordea, CTO, CPO eta QA zuzendaria. Hau da, konpainia teknologien sektorean inbertitzen hasi zen.

Ondare astun baten aztarnak ez zeuden sistemetan bakarrik. Konpainiak ondare-prozesuak zituen, ondare-jendea, ondare-kultura. Hori guztia aldatu behar izan zen. Zalantzarik gabe ez zela aspergarria izango pentsatu nuen, eta probatzea erabaki nuen.

Bi egun lehenago

Lan berri bat hasi baino bi egun lehenago, bulegora iritsi, azken papera bete, taldea ezagutu eta taldea arazo batekin borrokan ari zela ohartu nintzen une hartan. Orria kargatzeko batez besteko denbora 4 segundora igo zen, hau da, 2 aldiz.

Ordutegiaren arabera, argi eta garbi zerbait gertatu zen, eta ez dago argi zer. Arazoa datu-zentroko sareko latentzia zela ikusi zen: 5 ms-ko latentzia datu-zentroan 2 s bihurtu zen erabiltzaileentzat. Ez nekien zergatik gertatu zen hau, baina nolanahi ere jakin zen arazoa datu zentroan zegoela.

Lehen egunean

Bi egun pasa ziren eta nire lehen lan egunean konturatu nintzen arazoa ez zela desagertu.

Bi egunez, batez beste 4 segundotan kargatu ziren erabiltzaileen orriak. Arazoa zein den aurkitu duten galdetzen diot.

- Bai, txartel bat zabaldu gendun.
- ETA?
- Tira, oraindik ez digute erantzun.

Orduan konturatu nintzen aurretik kontatu zidaten guztia borrokatu behar nuen icebergaren punta txiki bat besterik ez zela.

Horri oso ondo egokitzen zaion aipamen on bat dago:

"Batzuetan teknologia aldatzeko erakundea aldatu behar da".

Baina urteko garairik jendetsuenean lanean hasi nintzenez, arazoa konpontzeko bi aukerak aztertu behar izan nituen: bizkor zein epe luzerako. Eta orain kritikoa denarekin hasi.

Hirugarren egunean

Beraz, kargatzeak 4 segundo irauten du, eta 13tik 15era gailurrik handienak.

Denbora-tarte horretan hirugarren egunean, deskarga-abiadura honelakoa izan zen:

Nire ikuspuntutik, ezer ez zen funtzionatu. Beste guztien ikuspuntutik ohi baino apur bat motelago zebilen. Baina ez da horrela gertatzen, arazo larria da.

Taldea konbentzitzen saiatu nintzen, eta zerbitzari gehiago behar zirela erantzun zidaten. Hau, noski, arazoaren konponbidea da, baina ez da beti bakarra eta eraginkorrena. Zerbitzari nahikoa zergatik ez zegoen galdetu nion, zein zen trafiko-bolumena. Datuak estrapolatu eta segundoko 150 eskaera inguru ditugula ikusi nuen, eta hori, printzipioz, arrazoizko mugen barruan dago.

Baina ez dugu ahaztu behar erantzun egokia jaso aurretik galdera egokia egin behar duzula. Nire hurrengo galdera izan zen: zenbat frontend zerbitzari ditugu? Erantzunak "pixka bat harritu ninduen" - 17 frontend zerbitzari genituen!

— Lotsa ematen dit galdetzeak, baina 150 17z zatituta 8 inguru ematen du? Zerbitzari bakoitzak segundoko 8 eskaera onartzen dituela diozu, eta bihar segundoko 160 eskaera badaude, 2 zerbitzari gehiago beharko ditugula?

Jakina, ez genuen zerbitzari gehigarririk behar. Irtenbidea kodean bertan zegoen, eta azalean:

var currentClass = classes.getCurrentClass();
return currentClass;

Funtzio bat zegoen getCurrentClass(), guneko guztia klase baten testuinguruan funtzionatzen duelako - hori bai. Eta orri bakoitzean funtzio bakarra zegoen 200 eskaera baino gehiago.

Modu honetan konponbidea oso erraza zen, ez zenuen ezer berridatzi beharrik izan ere: ez ezazu informazio bera berriro eskatu.

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

Oso pozik nengoen erabaki nuen herenegun bakarrik aurkitu nuela arazo nagusia. Inozoa nintzenez, arazo askotako bat besterik ez zen hau.

Baina lehen arazo hau ebatzita grafikoa askoz beherago jaitsi zen.

Aldi berean, beste optimizazio batzuk egiten ari ginen. Gauza asko zeuden bistan konpondu daitezkeenak. Esaterako, hirugarren egunean bertan aurkitu nuen sisteman cache bat zegoela azken finean (hasieran uste nuen eskaera guztiak zuzenean datu-basetik zetozela). Cache batean pentsatzen dudanean, Redis edo Memcached estandarrean pentsatzen dut. Baina ni izan nintzen hori uste zuen bakarra, sistema horrek MongoDB eta SQL Server erabiltzen baitzuen cachean gordetzeko -datuak irakurri berri dituen berberak-.

Hamar eguna

Lehen astean oraintxe konpondu behar ziren arazoei aurre egin nien. Bigarren astean nonbait, stand-upera etorri nintzen lehenengoz taldearekin komunikatzeko, zer gertatzen zen eta prozesu osoa nola zihoan ikusteko.

Zerbait interesgarria aurkitu zen berriro. Taldea honako hauek osatzen zuten: 18 garatzaile; 8 probatzaile; 3 kudeatzaile; 2 arkitekto. Eta denek erritual komunetan parte hartzen zuten, hau da, goizero 30 lagun baino gehiago etortzen ziren stand-upera eta egiten zutena kontatzen zuten. Argi dago bilerak ez zuela 5 edo 15 minutu behar izan. Inork ez zuen inor entzuten, denek sistema ezberdinetan lan egiten dutelako. Forma honetan, soinketa saio baterako orduko 2-3 sarrerak emaitza ona zen jada.

Egin genuen lehenengo gauza taldea hainbat produktu-lerrotan banatzea izan zen. Atal eta sistema ezberdinetarako, talde bereiziak esleitu genituen, garatzaileak, probatzaileak, produktu-kudeatzaileak eta negozio-analistak barne.

Ondorioz lortu dugu:

• Stand-up eta rallyak murriztea.
• Produktuari buruzko gaiaren ezagutza.
• Jabetza sentimendua. Jendeak denbora guztian sistemak egiten zituenean, bazekiten ziurrenik beste norbaitek bere akatsekin lan egin beharko zuela, baina ez beraiek.
• Taldeen arteko lankidetza. Esan beharrik ez dago QA ez zela asko komunikatzen programatzaileekin, produktuak berea egiten zuela, etab. Orain erantzukizun puntu komun bat dute.

Eraginkortasunean, produktibitatean eta kalitatean zentratu ginen batez ere; hauek dira taldearen eraldaketarekin konpontzen saiatu ginen arazoak.

Hamaikagarren eguna

Taldearen egitura aldatzeko prozesuan, zenbat zenbatzen aurkitu nuen StoryPuntuak. 1 SP egun baten berdina zen, eta txartel bakoitzak SP zeukan bai garapenerako bai QArako, hau da, gutxienez 2 SP.

Nola deskubritu nuen hau?

Akats bat aurkitu dugu: txostenetako batean, non txostena behar den epearen hasiera eta amaiera data sartzen den, azken eguna ez da kontuan hartzen. Hau da, eskaeraren nonbait ez zegoen <=, besterik gabe < baizik. Hau hiru Story Points dela esan zidaten, alegia 3 egun.

Honen ondoren:

• Story Points balorazio sistema berrikusi da. Orain sistematik azkar pasa daitezkeen akats txikien konponketak erabiltzaileari azkarrago iristen zaizkio.
• Garapen eta probak egiteko erlazionatutako txartelak batzen hasi ginen. Lehen, txartel bakoitza, akats bakoitza ekosistema itxi bat zen, ez beste ezertara lotuta. Orrialde batean hiru botoi aldatzea hiru txartel ezberdin izan zitekeen hiru QA prozesu ezberdinekin, orrialde bakoitzeko proba automatizatu bat izan beharrean.
• Garatzaileekin lanean hasi ginen lan-kostuak kalkulatzeko planteamendu batean. Hiru egun botoi bat aldatzeko ez da dibertigarria.

Hogeigarren eguna

Lehen hilabetearen erdialdean nonbait, egoera apur bat egonkortu zen, funtsean gertatzen ari zena irudikatu nuen, eta jada etorkizunera begira eta epe luzerako irtenbideetan pentsatzen hasi nintzen.

Epe luzerako helburuak:

• Kudeatutako plataforma. Orrialde bakoitzean ehunka eskaera ez dira serioak.
• Aurreikus daitezkeen joerak. Aldizkako trafiko-gailurrak zeuden, lehen begiratuan beste neurketa batzuekin erlazionatzen ez zirenak; hori zergatik gertatu zen ulertu behar genuen eta iragartzen ikasi behar genuen.
• Plataformaren hedapena. Negozioa etengabe hazten ari da, gero eta erabiltzaile gehiago etortzen dira eta trafikoa handitzen ari da.

Iraganean askotan esaten zen: "Berridatzi dezagun dena [hizkuntza/esparruan], dena hobeto funtzionatuko du!"

Kasu gehienetan honek ez du funtzionatzen, ona da berridazketa batere funtzionatzen badu. Hori dela eta, ibilbide-orri bat sortu behar genuen: negozio-helburuak nola lortuko diren (zer egingo dugun eta zergatik) pausoz pauso erakusten duen estrategia espezifikoa, hau da:

• proiektuaren misioa eta helburuak islatzen ditu;
• helburu nagusiak lehenesten ditu;
• horiek lortzeko egutegia dauka.

Aurretik, inork ez zuen taldearekin hitz egin aldaketaren xedeaz. Horrek arrakasta-neurri egokiak behar ditu. Konpainiaren historian lehen aldiz, KPIak ezarri genituen talde teknikorako, eta adierazle horiek antolakuntzakoekin lotzen ziren.

Hau da, antolakuntzako KPIak taldeek onartzen dituzte eta taldeko KPIak banakako KPIek onartzen dituzte. Bestela, KPI teknologikoak antolakuntzakoekin bat ez badatoz, denek bere gain hartzen dute manta.

Adibidez, antolakuntzako KPIetako bat merkatu kuota handitzen ari da produktu berrien bidez.

Nola lagundu dezakezu produktu berri gehiago izateko helburua?

• Lehenik eta behin, denbora gehiago eman nahi dugu produktu berriak garatzen akatsak konpondu beharrean. Neurtzeko erraza den irtenbide logikoa da.
• Bigarrenik, transakzio-bolumenaren igoeraren alde egin nahi dugu, merkatu-kuota zenbat eta handiagoa izan, orduan eta erabiltzaile gehiago eta, ondorioz, trafiko gehiago.

Ondoren, talde barruan exekutatu daitezkeen KPI indibidualak, adibidez, akats nagusiak datozen tokian egongo dira. Atal honetan bereziki zentratzen bazara, ziurtatu dezakezu askoz akats gutxiago daudela, eta gero produktu berriak garatzeko eta berriro antolakuntzako KPIak laguntzeko denbora handituko da.

Horrela, erabaki bakoitzak, kodea berridaztea barne, enpresak ezarri dizkigun helburu zehatzei lagundu behar die (antolakuntza-hazkundea, ezaugarri berriak, kontratazioa).

Prozesu horretan gauza interesgarri bat atera zen argira, teknologikoentzat ez ezik, orokorrean enpresarentzat albiste bihurtu zena: txartel guztiak gutxienez KPI batean zentratu behar dira. Hau da, produktu batek funtzio berri bat egin nahi duela esaten badu, lehenengo galdera egin beharko litzateke: "Zer KPI onartzen du funtzio honek?" Hala ez bada, barkatu - alferrikako funtzioa dirudi.

Hogeita hamar eguna

Hilabete amaieran, beste ñabardura bat aurkitu nuen: nire Ops taldeko inork ez ditu inoiz bezeroekin egiten ditugun kontratuak ikusi. Kontaktuak zergatik ikusi behar dituzun galdetu dezakezu.

• Lehenik eta behin, SLAak kontratuetan zehazten direlako.
• Bigarrenik, SLA guztiak desberdinak dira. Bezero bakoitza bere eskakizunekin etorri zen, eta salmenta sailak begiratu gabe sinatu zuen.

Beste ñabardura interesgarri bat da bezero handienetako batekin egindako kontratuak plataformak onartzen dituen software bertsio guztiek n-1 izan behar dutela dio, hau da, ez azken bertsioa, azkenaurrekoa baizik.

Argi dago n-1etik noraino geunden plataforma ColdFusion eta SQL Server 2008-n oinarritzen bazen, uztailean jada ez zen batere onartzen.

Berrogeita bost eguna

Bigarren hilabetearen erdialdera nahikoa denbora izan nuen esertzeko eta egiteko balioakorronteamapping guztiz prozesu osorako. Hauek dira eman beharreko urratsak, produktu bat sortzen hasi eta kontsumitzaileari entregatu arte, eta ahalik eta xehetasun handienarekin deskribatu behar dira.

Prozesua zati txikitan zatitzen duzu eta ikusten duzu zer ari den denbora gehiegi hartzen, zer optimizatu, hobetu, etab. Esaterako, zenbat denbora behar da produktu-eskaera bat apainketara igarotzeko, noiz iristen den garatzaile batek har dezakeen txartel batera, QA, etab. Beraz, urrats bakoitza zehatz-mehatz aztertu eta zer optimizatu daitekeen pentsatzen duzu.

Hau egin nuenean, bi gauza deitu zidaten begia:

• Garatzaileei QAtik itzultzen zaizkien txartelen ehuneko handia;
• tira-eskaeraren berrikuspenak luzeegia hartu zuen.

Arazoa zen honako ondorio hauek zirela: Denbora asko behar dela dirudi, baina ez dakigu zenbat denbora.

"Ezin duzu neurtu ezin duzuna hobetu".

Nola justifikatu arazoa zein larria den? Egunak edo orduak galtzen al ditu?

Hori neurtzeko, Jira prozesuari urrats pare bat gehitu dizkiogu: “garapenerako prest” eta “QArako prest” neurtzeko txartel bakoitzak zenbat denbora itxaron duen eta urrats jakin batera zenbat aldiz itzultzen den neurtzeko.

"Review" ere gehitu dugu, batez beste zenbat sarrera dauden berrikusteko, eta honetatik dantzan has zaitezke. Sistemaren neurketak genituen, orain neurketa berriak gehitu eta neurtzen hasi ginen:

• Prozesuaren eraginkortasuna: errendimendua eta aurreikusita/ematea.
• Prozesuaren kalitatea: akats kopurua, QA-ren akatsak.

Benetan laguntzen du ondo zer eta zer ez den ondo ulertzen.

Berrogeita hamargarren eguna

Hau guztia ona eta interesgarria da, noski, baina bigarren hilabetearen amaiera aldera, printzipioz aurreikusten zen zerbait gertatu zen, nahiz eta ez nuen halako eskalarik espero. Jendea alde egiten hasi zen goi zuzendaritza aldatu zelako. Jende berria sartu zen zuzendaritzan eta dena aldatzen hasi zen, eta zaharrak utzi egin zuten. Eta normalean hainbat urte dituen enpresa batean, denak lagunak dira eta denek elkar ezagutzen dute.

Hori espero zen, baina kaleratzeen tamaina ustekabekoa zen. Esaterako, aste batean bi taldeburuk aldi berean aurkeztu zituzten beren dimisioak beren borondatez. Horregatik, beste arazo batzuk ahaztu ez ezik, arreta jarri behar izan nuen talde bat sortzea. Arazo luzea eta zaila da konpontzea, baina landu beharra zegoen, geratzen zen jendea (edo gehienak) salbatu nahi nuelako. Jendeak alde egin izanaren aurrean nolabait erreakzionatu beharra zegoen taldean moralari eusteko.

Teorian, ona da: pertsona berri bat sartzen da, karta zuri osoa duena, taldearen gaitasunak ebaluatu eta langileak ordezkatu ditzakeena. Izan ere, ezin duzu jende berria ekarri hainbeste arrazoirengatik. Oreka beti behar da.

• Zaharrak eta berriak. Misioa alda dezaketen eta lagundu dezaketen zaharrak mantendu behar ditugu. Baina, aldi berean, odol berria ekarri behar dugu, horretaz apur bat geroago hitz egingo dugu.
• Esperientzia. Asko hitz egin nuen jubenil onekin, gogotsu eta gurekin lan egin nahi zutenekin. Baina ezin izan nituen hartu, gazteei laguntzeko eta haien tutore gisa jarduteko adineko nahikorik ez zegoelako. Beharrezkoa zen lehenik goiena eta gero gazteak kontratatu.
• Azenarioa eta makila.

Ez daukat erantzun ona zein den oreka egokia, nola mantendu, zenbat pertsona mantendu eta zenbat bultzatu. Hau prozesu indibidual hutsa da.

Berrogeita hamar bat eguna

Taldeari arretaz begiratzen hasi nintzen nor nuen ulertzeko, eta berriro gogoratu nintzen:

"Arazo gehienak pertsonen arazoak dira".

Taldeak, hala nola Dev eta Ops, hiru arazo handi dituela ikusi dut:

• Gaur egungo egoerarekin gogobetetzea.
• Erantzukizun falta - inork ez dituelako inoiz ekarri interpreteen lanaren emaitzak negozioan eragiteko.
• Aldaketaren beldurra.

Aldaketak beti ateratzen zaitu zure erosotasun gunetik, eta zenbat eta gazteagoak izan, orduan eta gehiago ez dute aldaketarik gustuko, ez baitute ulertzen zergatik eta ez baitute ulertzen nola. Entzun dudan erantzun ohikoena: "Ez dugu inoiz halakorik egin". Gainera, erabateko zentzugabetasunera iritsi zen: aldaketarik txikienak ezin ziren gertatu norbait haserretu gabe. Eta aldaketek euren lanean zenbaterainoko eragina izan zuten ere, jendeak zera esaten zuen: «Ez, zergatik? Ez du funtzionatuko».

Baina ezin zara hobetu ezer aldatu gabe.

Langile batekin elkarrizketa guztiz absurdua izan nuen, optimizaziorako nire ideiak kontatu nizkion, eta honek esan zidan:
- Ai, ez zenuen ikusi iaz genuena!
- Orduan zer?
"Orain zena baino askoz hobea da".
- Orduan, ezin da hobetu?
- Zertarako?

Galdera ona - zergatik? Orain lehen baino hobeto balego bezala, orduan dena nahikoa da. Horrek erantzukizun falta dakar, printzipioz guztiz normala dena. Esan bezala, talde teknikoa pixka bat alboan zegoen. Enpresak uste zuen existitu behar zirela, baina inork ez ditu inoiz estandarrak ezarri. Laguntza teknikoak ez zuen inoiz SLA ikusi, beraz, nahiko "onargarria" izan zen taldearentzat (eta hau deigarria izan zait gehien):

• 12 segundo kargatzen;
• 5-10 minutuko geldialdia kaleratze bakoitzean;
• Arazo larriak konpontzeko egunak eta asteak behar dira;
• 24x7 / guardiako langile falta.

Inor ez zen sekula saiatu galdetzen zergatik ez dugun hobeto egiten, eta inor ez zen inoiz konturatu horrela ez zela izan behar.

Hobari gisa, arazo bat gehiago zegoen: esperientzia falta. Nagusiek alde egin zuten, eta gainerako talde gaztea aurreko erregimenean hazi eta pozoitu egin zuten.

Honetaz guztiaz gain, jendea ere beldurra zen huts egitearen eta ezgaia agertzearen beldur. Hori adierazten da, lehenik eta behin, haiek inolaz ere laguntzarik eskatu. Zenbat aldiz hitz egin dugu taldean eta bakarka, eta nik esan dut: "Egin galdera bat zerbait nola egin ez badakizu". Nire buruan konfiantza dut eta badakit edozein arazo konpondu dezakedala, baina denbora beharko da. Horregatik, 10 minututan konpontzen dakien bati galdetzen badiot, galdetuko diot. Zenbat eta esperientzia gutxiago izan, orduan eta beldur handiagoa izango diozu galdetzeko, ezgaitzat hartuko zarela uste duzulako.

Galderak egiteko beldur hori modu interesgarrietan agertzen da. Adibidez, galdetzen duzu: "Zer moduz zaude zeregin honekin?" - "Pare bat ordu falta dira, dagoeneko bukatzen ari naiz". Hurrengo egunean berriro galdetzen duzunean, dena ondo dagoela erantzungo duzu, baina arazo bat zegoen, behin betiko prest egongo da egunaren amaieran. Beste egun bat igarotzen da, eta horman itsatsi eta norbaitekin hitz egitera behartu arte, honek jarraitzen du. Pertsona batek berak konpondu nahi du arazo bat; uste du berak konpontzen ez badu, porrot handia izango dela.

Horregatik garatzaileek estimazioak puztu zituzten. Anekdota bera zen, zeregin jakin bat eztabaidatzen ari zirenean, halako zifra bat eman zidaten, non oso harrituta geratu nintzen. Esan zidaten sustatzailearen kalkuluetan, garatzaileak QA-tik txartela itzuliko den denbora sartzen duela, bertan akatsak aurkituko dituztelako, eta PR-ak hartuko duen denbora eta berrikusi beharko luketen jendeak. lanpetuta egongo da, hau da, dena, posible dena.

Bigarrenik, ezgaiak agertzearen beldur diren pertsonak gainaztertu. Zehazki zer egin behar den esaten duzunean, hau hasten da: "Ez, eta hemen pentsatzen badugu?" Zentzu honetan, gure enpresa ez da bakarra, gazteentzako ohiko arazoa da.

Erantzun gisa, praktika hauek aurkeztu nituen:

• Araua 30 minutu. Ezin baduzu arazoa ordu erdian konpondu, eskatu norbaiti laguntzeko. Horrek arrakasta maila ezberdinekin funtzionatzen du, jendeak oraindik ez duelako galdetzen, baina prozesua hasi da behintzat.
• Esentzia izan ezik dena kendu, zeregin bat burutzeko epea kalkulatzerakoan, hau da, kodea idazteko zenbat denbora beharko duen kontuan hartu.
• Etengabeko ikaskuntza gehiegi aztertzen dutenentzat. Jendearekin etengabeko lana besterik ez da.

Hirurogeigarren eguna

Hau guztia egiten ari nintzela, aurrekontua asmatzeko garaia iritsi zen. Jakina, gauza interesgarri asko aurkitu ditut gure dirua non gastatzen genuen. Adibidez, rack oso bat genuen datu-zentro bereizi batean FTP zerbitzari batekin, bezero batek erabiltzen zuena. Hori gertatu zen “... mugitu ginen, baina horrela geratu zen, ez genuen aldatu”. Duela 2 urte izan zen.

Interes berezia izan zen hodeiko zerbitzuen faktura. Uste dut hodei altuko fakturaren arrazoi nagusia bizitzan lehen aldiz zerbitzarietarako sarbide mugagabea duten garatzaileak direla. Ez dute galdetu behar: "Mesedez, emaidazu proba-zerbitzari bat", beraiek har dezakete. Gainera, garatzaileek beti nahi dute hain sistema zoragarri bat eraiki, non Facebook eta Netflix jeloskor egongo diren.

Baina garatzaileek ez dute zerbitzariak erosteko esperientziarik eta zerbitzarien beharrezko tamaina zehazteko trebetasuna, aurretik ez zutelako behar. Eta normalean ez dute ondo ulertzen eskalagarritasunaren eta errendimenduaren arteko aldea.

Inbentarioaren emaitzak:

• Datu zentro beretik irten ginen.
• 3 erregistro zerbitzuekin kontratua eten genuen. Horietako 5 genituelako: zerbaitekin jolasten hasi zen garatzaile bakoitzak berri bat hartu zuen.
• 7 AWS sistema itzali ziren. Berriz ere, inork ez zituen hildako proiektuak gelditu; denek lanean jarraitu zuten.
• Softwarearen kostuak 6 aldiz murriztu ditu.

Hirurogeita hamabost eguna

Denbora pasa zen, eta bi hilabete eta erdian zuzendaritza batzordearekin bildu behar izan nuen. Gure zuzendaritza batzordea ez da beste batzuk baino hobea edo txarragoa; administrazio kontseilu guztiek bezala, dena jakin nahi du. Jendeak dirua inbertitzen du eta egiten duguna multzoko KPIetan zenbat sartzen den ulertu nahi du.

Administrazio kontseiluak informazio asko jasotzen du hilero: erabiltzaile kopurua, haien hazkundea, zer zerbitzu erabiltzen dituzten eta nola, errendimendua eta produktibitatea, eta azkenik, orrialdeak kargatzeko batez besteko abiadura.

Arazo bakarra da uste dudala batez bestekoa gaitz hutsa dela. Baina oso zaila da hori administrazio kontseiluari azaltzea. Zenbaki agregatuekin funtzionatzen ohituta daude, eta ez, adibidez, segundoko karga-denborak zabaltzera.

Zentzu honetan puntu interesgarri batzuk zeuden. Adibidez, esan nuen trafikoa web zerbitzari ezberdinen artean banatu behar dugula eduki motaren arabera.

Hau da, ColdFusion Jetty eta nginx-etik igarotzen da eta orriak abiarazten ditu. Eta irudiak, JS eta CSS bereizitako nginx batetik pasatzen dira beren konfigurazioekin. Honetaz ari naizen praktika nahiko estandarra da idatzi nuen duela urte pare bat. Ondorioz, irudiak askoz azkarrago kargatzen dira, eta... kargatzeko batez besteko abiadura 200 ms handitu da.

Grafikoa Jetty-rekin datorren datuetan oinarrituta eraikitzen delako gertatu da. Hau da, eduki azkarra ez da kalkuluan sartzen - batez besteko balioa jauzi egin da. Hori argi genuen, barre egin genuen, baina nola azaldu administrazio kontseiluari zergatik egin genuen zerbait eta gauzak %12 okerrera egin zuen?

Laurogeita bost eguna

Hirugarren hilabetearen amaieran konturatu nintzen bazela batere kontatu ez nuen gauza batekin: denbora. Hitz egin dudan guztiak denbora behar du.

Hau da nire benetako asteko egutegia - lan aste bat besterik ez, ez oso lanpetuta. Ez dago denbora nahikorik denetarako. Horregatik, berriro ere, arazoei aurre egiten lagunduko dizuten jendea kontratatu behar duzu.

Ondorioa

Hori ez da guztia. Istorio honetan, produktuarekin nola lan egin eta olatu orokorrarekin sintonizatzen saiatu ere ez naiz iritsi, edo laguntza teknikoa nola integratzen genuen, edo beste arazo tekniko batzuk nola konpondu genituen ere. Adibidez, ustekabean jakin nuen datu-baseko taula handienetan ez dugula erabiltzen SEQUENCE. Norberak idatzitako funtzioa dugu nextID, eta ez da transakzio batean erabiltzen.

Antzeko milioi bat gauza gehiago zeuden denbora luzez hitz egin genitzakeenak. Baina oraindik esan beharreko gauzarik garrantzitsuena kultura da.

Kultura edo horren falta da beste arazo guztiak ekartzen dituena. Kultura bat eraikitzen saiatzen ari gara, non jendeak:

• ez dira porrotak beldur;
• akatsetatik ikasi;
• beste talde batzuekin elkarlanean aritzea;
• ekimena hartu;
• ardura hartu;
• ongi etorri emaitza helburu gisa;
• arrakasta ospatzen.

Honekin gainontzeko guztia etorriko da.

Leon Sua twitterren, facebook eta abar medium.

Bi estrategia daude ondareari dagokionez: kosta ahala kosta horrekin lan egitea saihestea edo lotutako zailtasunak ausardiaz gainditzea. Guk c DevOpsConf Bigarren bidea hartzen ari gara, prozesuak eta planteamenduak aldatzen. Sartu gurekin youtube, buletina и telegrama, eta elkarrekin DevOps kultura ezarriko dugu.

Iturria: www.habr.com