Dihet se kompetenca e ZKT-së vihet në provë vetëm herën e dytë që ai kryen këtë rol. Sepse është një gjë të punosh në një kompani për disa vite, të evoluosh me të dhe duke qenë në të njëjtin kontekst kulturor, gradualisht të marrësh më shumë përgjegjësi. Dhe është krejt tjetër të hysh direkt në pozicionin e drejtorit teknik në një kompani me bagazh të trashëguar dhe një mori problemesh të zhytura mjeshtërisht nën qilim.

Në këtë kuptim, përvoja e Leon Fire, të cilën ai e ndau DevOpsConf, jo tamam unik, por shumëzuar nga eksperienca e tij dhe numri i roleve të ndryshme që ka arritur të provojë gjatë 20 viteve, është shumë i dobishëm. Më poshtë është një kronologji e ngjarjeve mbi 90 ditë dhe shumë histori që janë argëtuese për të qeshur kur i ndodhin dikujt tjetër, por që nuk janë aq argëtuese për t'u përballur personalisht.

Leon flet shumë ngjyra në rusisht, kështu që nëse keni 35-40 minuta, ju rekomandoj të shikoni videon. Versioni me tekst për të kursyer kohë më poshtë.

Versioni i parë i raportit ishte një përshkrim i mirëstrukturuar i punës me njerëzit dhe proceset, që përmbante rekomandime të dobishme. Por ajo nuk i ka përcjellë të gjitha surprizat që janë hasur gjatë rrugës. Prandaj, ndryshova formatin dhe paraqita problemet që dolën para meje si një prizë në kompaninë e re dhe metodat për zgjidhjen e tyre në rend kronologjik.

Një muaj më parë

Si shumë histori të mira, edhe kjo filloi me alkoolin. Ne ishim ulur me miqtë në një lokal dhe siç pritej mes specialistëve të IT-së, të gjithë qanin për problemet e tyre. Njëri prej tyre sapo kishte ndërruar punë dhe po fliste për problemet e tij me teknologjinë, me njerëzit dhe me ekipin. Sa më shumë dëgjoja, aq më shumë kuptova se ai thjesht duhet të më punësonte, sepse këto janë llojet e problemeve që kam zgjidhur në 15 vitet e fundit. I thashë kështu dhe të nesërmen u takuam në një ambient pune. Kompania u quajt Teaching Strategies.

Teaching Strategies është lider në treg në kurrikulën për fëmijë shumë të vegjël nga lindja deri në moshën tre vjeç. Kompania tradicionale e "letër" është tashmë 40 vjeç dhe versioni dixhital SaaS i platformës është 10 vjet. Relativisht kohët e fundit filloi procesi i përshtatjes së teknologjisë dixhitale me standardet e kompanisë. Versioni "i ri" u lançua në 2017 dhe ishte pothuajse si i vjetri, vetëm se funksionoi më keq.

Gjëja më interesante është se trafiku i kësaj kompanie është shumë i parashikueshëm - nga dita në ditë, nga viti në vit, mund të parashikoni shumë qartë se sa njerëz do të vijnë dhe kur. Për shembull, ndërmjet orës 13 dhe 15:XNUMX, të gjithë fëmijët në kopshte shkojnë në shtrat dhe mësuesit fillojnë të fusin informacionin. Dhe kjo ndodh çdo ditë, përveç fundjavave, sepse pothuajse askush nuk punon në fundjavë.

Duke parë pak përpara, do të vërej se e kam filluar punën time në periudhën e trafikut më të lartë vjetor, i cili është interesant për arsye të ndryshme.

Platforma, e cila dukej se ishte vetëm 2 vjeç, kishte një pirg të veçantë: ColdFusion & SQL Server nga 2008. ColdFusion, nëse nuk e dini, dhe ka shumë të ngjarë që nuk e dini, është një PHP e ndërmarrjes që doli në mesin e viteve '90, dhe që atëherë nuk kam dëgjuar as për të. Gjithashtu kishte: Ruby, MySQL, PostgreSQL, Java, Go, Python. Por monoliti kryesor funksiononte në ColdFusion dhe SQL Server.

Problemet

Sa më shumë që flisja me punonjësit e kompanisë për punën dhe problemet e hasura, aq më shumë kuptova se problemet nuk ishin vetëm të natyrës teknike. Mirë, teknologjia është e vjetër - dhe ata nuk punuan në të, por kishte probleme me ekipin dhe me proceset, dhe kompania filloi ta kuptonte këtë.

Tradicionalisht, teknikët e tyre uleshin në qoshe dhe bënin një lloj pune. Por gjithnjë e më shumë biznesi filloi të kalonte përmes versionit dixhital. Prandaj, në vitin e fundit para se të filloja punë, në kompani u shfaqën të reja: bordi i drejtorëve, CTO, CPO dhe drejtor i QA. Kjo do të thotë, kompania filloi të investojë në sektorin e teknologjisë.

Gjurmët e një trashëgimie të rëndë nuk ishin vetëm në sisteme. Kompania kishte procese të trashëgimisë, njerëz të trashëguar, kulturë të trashëgimisë. E gjithë kjo duhej ndryshuar. Mendova se definitivisht nuk do të ishte e mërzitshme dhe vendosa ta provoja.

Dy ditë më parë

Dy ditë para se të filloja një punë të re, mbërrita në zyrë, plotësova dokumentet e fundit, takova ekipin dhe zbulova se ekipi po luftonte me një problem në atë kohë. Ishte se koha mesatare e ngarkimit të faqes u hodh në 4 sekonda, domethënë 2 herë.

Duke gjykuar nga orari, diçka ka ndodhur qartë, dhe nuk është e qartë se çfarë. Doli se problemi ishte vonesa e rrjetit në qendrën e të dhënave: 5 ms vonesa në qendrën e të dhënave u kthye në 2 s për përdoruesit. Nuk e dija pse ndodhi kjo, por në çdo rast u bë e ditur se problemi ishte në qendrën e të dhënave.

Dita e pare

Kaluan dy ditë dhe në ditën time të parë të punës zbulova se problemi nuk ishte zhdukur.

Për dy ditë, faqet e përdoruesve ngarkoheshin mesatarisht në 4 sekonda. Unë pyes nëse e kanë gjetur se cili është problemi.

- Po, kemi hapur një biletë.
- DHE?
- Epo, nuk na janë përgjigjur akoma.

Pastaj kuptova se gjithçka që më kishin thënë më parë ishte vetëm një majë e vogël e ajsbergut që duhej të luftoja.

Ekziston një citim i mirë që i përshtatet shumë mirë kësaj:

"Ndonjëherë për të ndryshuar teknologjinë duhet të ndryshosh organizatën."

Por duke qenë se fillova punën në periudhën më të ngarkuar të vitit, më duhej të shikoja të dyja opsionet për zgjidhjen e problemit: të shpejtë dhe afatgjatë. Dhe filloni me atë që është kritike tani.

Dita e trete

Pra, ngarkimi zgjat 4 sekonda, dhe nga 13 në 15 majat më të mëdha.

Në ditën e tretë gjatë kësaj periudhe kohore, shpejtësia e shkarkimit dukej kështu:

Nga këndvështrimi im, asgjë nuk funksionoi fare. Nga këndvështrimi i të gjithëve, ai po ecën pak më ngadalë se zakonisht. Por thjesht nuk ndodh kështu - është një problem serioz.

Unë u përpoqa të bind ekipin, të cilit ata u përgjigjën se thjesht kishin nevojë për më shumë serverë. Kjo, natyrisht, është një zgjidhje për problemin, por nuk është gjithmonë e vetmja dhe më efektive. Pyeta pse nuk kishte serverë të mjaftueshëm, sa ishte vëllimi i trafikut. Ekstrapolova të dhënat dhe konstatova se kemi afërsisht 150 kërkesa në sekondë, që në parim bien brenda kufijve të arsyeshëm.

Por nuk duhet të harrojmë se përpara se të merrni përgjigjen e duhur, duhet të bëni pyetjen e duhur. Pyetja ime tjetër ishte: sa serverë frontend kemi? Përgjigja "më hutoi pak" - kishim 17 serverë frontend!

- Më vjen turp të pyes, por 150 pjesëtuar me 17 jep rreth 8? A thua se çdo server lejon 8 kërkesa në sekondë, dhe nëse nesër ka 160 kërkesa në sekondë, do të na duhen edhe 2 serverë të tjerë?

Natyrisht, nuk na duheshin serverë shtesë. Zgjidhja ishte në vetë kodin dhe në sipërfaqe:

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

Kishte një funksion getCurrentClass(), sepse gjithçka në sajt funksionon në kontekstin e një klase - kjo është e drejtë. Dhe për këtë një funksion në çdo faqe kishte 200+ kërkesa.

Zgjidhja në këtë mënyrë ishte shumë e thjeshtë, madje nuk duhej të rishkruash asgjë: thjesht mos kërko më të njëjtin informacion.

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

Isha shumë i lumtur sepse vendosa që vetëm në ditën e tretë të kisha gjetur problemin kryesor. Sado naiv të isha, ky ishte vetëm një nga problemet e shumta.

Por zgjidhja e këtij problemi të parë e uli grafikun shumë më poshtë.

Në të njëjtën kohë, ne po bënim optimizime të tjera. Kishte shumë gjëra në horizont që mund të rregulloheshin. Për shembull, në të njëjtën ditë të tretë zbulova se në fund të fundit kishte një cache në sistem (në fillim mendova se të gjitha kërkesat vinin drejtpërdrejt nga baza e të dhënave). Kur mendoj për një cache, mendoj për Redis standarde ose Memcached. Por unë isha i vetmi që mendova kështu, sepse ai sistem përdorte MongoDB dhe SQL Server për caching - i njëjti nga i cili sapo u lexuan të dhënat.

Dita e dhjetë

Javën e parë u mora me probleme që duhej të zgjidheshin pikërisht tani. Diku në javën e dytë erdha për herë të parë në stand-up për të komunikuar me ekipin, për të parë se çfarë po ndodhte dhe si po shkonte i gjithë procesi.

Diçka interesante u zbulua përsëri. Ekipi përbëhej nga: 18 zhvillues; 8 testues; 3 menaxherë; 2 arkitektë. Dhe të gjithë merrnin pjesë në rituale të përbashkëta, domethënë, më shumë se 30 njerëz vinin në stand-up çdo mëngjes dhe tregonin se çfarë bënin. Është e qartë se takimi nuk zgjati 5 apo 15 minuta. Askush nuk dëgjoi askënd sepse të gjithë punojnë në sisteme të ndryshme. Në këtë formë, 2-3 bileta në orë për një seancë kujdesi ishte tashmë një rezultat i mirë.

Gjëja e parë që bëmë ishte ndarja e ekipit në disa linja prodhimi. Për seksione dhe sisteme të ndryshme, ne ndamë ekipe të veçanta, të cilat përfshinin zhvillues, testues, menaxherë produktesh dhe analistë biznesi.

Si rezultat kemi marrë:

Reduktimi i qëndrimeve dhe mitingjeve.
Njohuri për lëndën e produktit.
Një ndjenjë pronësie. Kur njerëzit i përdornin sistemet gjatë gjithë kohës, ata e dinin se dikush tjetër me shumë mundësi do të duhej të punonte me defektet e tyre, por jo vetë.
Bashkëpunimi ndërmjet grupeve. Eshtë e panevojshme të thuhet, QA nuk komunikonte shumë me programuesit më parë, produkti bëri të vetën, etj. Tani ata kanë një pikë të përbashkët përgjegjësie.

Ne u fokusuam kryesisht në efikasitetin, produktivitetin dhe cilësinë - këto janë problemet që u përpoqëm t'i zgjidhnim me transformimin e ekipit.

Dita e njëmbëdhjetë

Në procesin e ndryshimit të strukturës së ekipit, zbulova se si të numëroja HistoriPikët. 1 PS ishte e barabartë me një ditë dhe çdo biletë përmbante PS si për zhvillimin ashtu edhe për QA, pra të paktën 2 PS.

Si e zbulova këtë?

Kemi gjetur një gabim: në një nga raportet, ku shënohet data e fillimit dhe e përfundimit të periudhës për të cilën duhet raporti, dita e fundit nuk merret parasysh. Kjo do të thotë, diku në kërkesë nuk kishte <=, por thjesht <. Më thanë se kjo është tre pika tregimi, d.m.th ditë 3.

Pas kësaj ne:

Sistemi i vlerësimit të Story Points është rishikuar. Tani rregullimet për defektet e vogla që mund të kalohen shpejt përmes sistemit arrijnë te përdoruesi më shpejt.
Ne filluam të bashkojmë biletat përkatëse për zhvillim dhe testim. Më parë, çdo biletë, çdo defekt ishte një ekosistem i mbyllur, jo i lidhur me asgjë tjetër. Ndryshimi i tre butonave në një faqe mund të ishte tre bileta të ndryshme me tre procese të ndryshme të cilësisë së cilësisë në vend të një testi të automatizuar për faqe.
Ne filluam të punojmë me zhvilluesit për një qasje për të vlerësuar kostot e punës. Tre ditë për të ndryshuar një buton nuk është qesharake.

Dita e njëzetë

Diku nga mesi i muajit të parë, situata u stabilizua pak, kuptova se çfarë po ndodhte në thelb dhe tashmë fillova të shikoja të ardhmen dhe të mendoja për zgjidhje afatgjata.

Qëllimet afatgjata:

Platforma e menaxhuar. Qindra kërkesa në çdo faqe nuk janë serioze.
Tendencat e parashikueshme. Kishte maja periodike të trafikut që në shikim të parë nuk lidheshin me metrikë të tjerë - duhej të kuptonim pse ndodhi kjo dhe të mësonim të parashikonim.
Zgjerimi i platformës. Biznesi po rritet vazhdimisht, gjithnjë e më shumë përdorues po vijnë dhe trafiku po rritet.

Në të kaluarën shpesh thuhej: "Le të rishkruajmë gjithçka në [gjuhë/kornizë], gjithçka do të funksionojë më mirë!"

Në shumicën e rasteve kjo nuk funksionon, është mirë nëse rishkrimi funksionon fare. Prandaj, na duhej të krijonim një udhërrëfyes - një strategji specifike që ilustron hap pas hapi se si do të arrihen qëllimet e biznesit (çfarë do të bëjmë dhe pse), e cila:

pasqyron misionin dhe qëllimet e projektit;
i jep përparësi qëllimeve kryesore;
përmban një plan për arritjen e tyre.

Para kësaj, askush nuk kishte folur me ekipin për qëllimin e ndonjë ndryshimi që po bëhej. Kjo kërkon matjet e duhura të suksesit. Për herë të parë në historinë e kompanisë, ne vendosëm KPI për grupin teknik dhe këta tregues u lidhën me ato organizative.

Kjo do të thotë, KPI-të organizative mbështeten nga ekipet, dhe KPI-të e ekipit mbështeten nga KPI-të individuale. Përndryshe, nëse KPI-të teknologjike nuk përkojnë me ato organizative, atëherë të gjithë e tërheqin batanijen mbi veten e tyre.

Për shembull, një nga KPI-të organizative është rritja e pjesës së tregut përmes produkteve të reja.

Si mund ta mbështesni qëllimin për të pasur më shumë produkte të reja?

Së pari, ne duam të shpenzojmë më shumë kohë duke zhvilluar produkte të reja në vend që të rregullojmë defektet. Kjo është një zgjidhje logjike që është e lehtë për t'u matur.
Së dyti, ne duam të mbështesim një rritje të vëllimit të transaksioneve, sepse sa më e madhe të jetë pjesa e tregut, aq më shumë përdorues dhe, në përputhje me rrethanat, aq më shumë trafik.

Pastaj KPI-të individuale që mund të ekzekutohen brenda grupit, për shembull, do të jenë në vendin nga vijnë defektet kryesore. Nëse fokusoheni në mënyrë specifike në këtë seksion, mund të siguroheni që ka shumë më pak defekte dhe më pas koha për zhvillimin e produkteve të reja dhe përsëri për mbështetjen e KPI-ve organizative do të rritet.

Kështu, çdo vendim, duke përfshirë rishkrimin e kodit, duhet të mbështesë qëllimet specifike që kompania ka vendosur për ne (rritje organizative, veçori të reja, rekrutim).

Gjatë këtij procesi doli në dritë një gjë interesante, e cila u bë lajm jo vetëm për teknikët, por në përgjithësi në kompani: të gjitha biletat duhet të fokusohen në të paktën një KPI. Kjo do të thotë, nëse një produkt thotë se dëshiron të krijojë një veçori të re, duhet të bëhet pyetja e parë: "Çfarë KPI mbështet kjo veçori?" Nëse jo, atëherë më vjen keq - duket si një veçori e panevojshme.

Dita e tridhjete

Në fund të muajit, zbulova një nuancë tjetër: askush në ekipin tim Ops nuk i ka parë ndonjëherë kontratat që ne lidhim me klientët. Ju mund të pyesni pse keni nevojë për të parë kontaktet.

Së pari, sepse SLA-të janë të specifikuara në kontrata.
Së dyti, SLA-të janë të gjitha të ndryshme. Secili klient erdhi me kërkesat e veta, dhe departamenti i shitjeve nënshkroi pa parë.

Një nuancë tjetër interesante është se në kontratën me një nga klientët më të mëdhenj thuhet se të gjitha versionet e softuerit të mbështetur nga platforma duhet të jenë n-1, pra jo versioni i fundit, por i parafundit.

Është e qartë se sa larg ishim nga n-1 nëse platforma bazohej në ColdFusion dhe SQL Server 2008, i cili nuk mbështetej më fare në korrik.

Dita dyzet e pesë

Rreth mesit të muajit të dytë pata kohë të mjaftueshme për t'u ulur dhe për të bërë vlerëlumëplanifikim plotësisht për të gjithë procesin. Këta janë hapat e nevojshëm që duhet të ndërmerren, nga krijimi i një produkti e deri te dërgimi i tij te konsumatori dhe duhet të përshkruhen sa më në detaje.

Ju e ndani procesin në copa të vogla dhe shihni se çfarë kërkon shumë kohë, çfarë mund të optimizohet, përmirësohet, etj. Për shembull, sa kohë duhet që një kërkesë produkti të kalojë përmes rregullimit, kur arrin një biletë që mund të marrë një zhvillues, QA, etj. Kështu që ju shikoni në çdo hap individual në detaje dhe mendoni se çfarë mund të optimizohet.

Kur e bëra këtë, dy gjëra më ranë në sy:

përqindje e lartë e biletave të kthyera nga QA tek zhvilluesit;
Shqyrtimet e kërkesave për tërheqje zgjatën shumë.

Problemi ishte se këto ishin përfundime të tilla si: Duket se kërkon shumë kohë, por nuk jemi të sigurt se sa kohë.

"Ju nuk mund të përmirësoni atë që nuk mund të matni."

Si të justifikoni se sa serioz është problemi? A humb ditë apo orë?

Për ta matur këtë, ne shtuam disa hapa në procesin Jira: "gati për dev" dhe "gati për QA" për të matur sa kohë pret çdo biletë dhe sa herë kthehet në një hap të caktuar.

Ne gjithashtu shtuam "në shqyrtim" për të ditur se sa bileta janë mesatarisht për shqyrtim, dhe nga kjo mund të filloni të kërceni. Ne kishim metrikë të sistemit, tani shtuam metrika të reja dhe filluam të masim:

Efikasiteti i procesit: performanca dhe e planifikuar/dorëzuar.
Cilësia e procesit: numri i defekteve, defekte nga QA.

Me të vërtetë ndihmon për të kuptuar se çfarë po shkon mirë dhe çfarë nuk po shkon mirë.

Dita e pesëdhjetë

Kjo është e gjitha, natyrisht, e mirë dhe interesante, por nga fundi i muajit të dytë ndodhi diçka që, në parim, ishte e parashikueshme, megjithëse nuk e prisja një shkallë të tillë. Njerëzit filluan të largoheshin sepse drejtuesit e lartë kishin ndryshuar. Njerëz të rinj erdhën në menaxhim dhe filluan të ndryshojnë gjithçka, dhe të vjetrit u larguan. Dhe zakonisht në një shoqëri disavjeçare, të gjithë janë miq dhe të gjithë e njohin njëri-tjetrin.

Kjo pritej, por shkalla e pushimeve nga puna ishte e papritur. Për shembull, brenda një jave dy drejtues ekipesh dorëzuan njëkohësisht dorëheqjen e tyre me vullnetin e tyre të lirë. Prandaj, më duhej jo vetëm të harroja problemet e tjera, por të fokusohesha në duke krijuar një ekip. Ky është një problem i gjatë dhe i vështirë për t'u zgjidhur, por duhej të zgjidhej sepse doja të shpëtoja njerëzit që mbetën (ose shumicën e tyre). Ishte e nevojshme të reagonim disi për faktin që njerëzit u larguan për të ruajtur moralin në ekip.

Teorikisht, kjo është e mirë: vjen një person i ri, i cili ka "carte blanche" të plotë, i cili mund të vlerësojë aftësitë e ekipit dhe të zëvendësojë personelin. Në fakt, nuk mund të sillni thjesht njerëz të rinj për kaq shumë arsye. Bilanci është gjithmonë i nevojshëm.

E vjetra dhe e reja. Ne duhet të mbajmë të moshuarit që mund të ndryshojnë dhe të mbështesin misionin. Por në të njëjtën kohë, ne duhet të sjellim gjak të ri, do të flasim për këtë pak më vonë.
Përvoja. Kam biseduar shumë me të rinj të mirë që ishin të etur dhe donin të punonin me ne. Por unë nuk mund t'i merrja përsipër sepse nuk kishte mjaft të moshuar për të mbështetur të rinjtë dhe për të vepruar si mentorë për ta. Ishte e nevojshme që fillimisht të rekrutoheshin majat dhe vetëm më pas të rinjtë.
Karrota dhe shkop.

Nuk kam një përgjigje të mirë për pyetjen se cili është ekuilibri i duhur, si ta ruajmë atë, sa njerëz të mbajmë dhe sa të shtyjmë. Ky është një proces thjesht individual.

Dita e pesëdhjetë e një

Fillova të shikoja nga afër ekipin për të kuptuar se kë kisha dhe u kujtova edhe një herë:

"Shumica e problemeve janë problemet e njerëzve."

Kam zbuluar se ekipi si i tillë - si Dev ashtu edhe Ops - ka tre probleme të mëdha:

I kënaqur me gjendjen aktuale të punëve.
Mungesa e përgjegjësisë - sepse askush nuk ka sjellë ndonjëherë rezultatet e punës së interpretuesve për të ndikuar në biznes.
Frika nga ndryshimi.

Ndryshimi ju nxjerr gjithmonë nga zona juaj e rehatisë dhe sa më të rinj të jenë, aq më shumë nuk u pëlqen ndryshimi, sepse nuk e kuptojnë pse dhe nuk e kuptojnë se si. Përgjigja më e zakonshme që kam dëgjuar është: "Nuk e kemi bërë kurrë këtë". Për më tepër, ajo arriti në pikën e absurditetit të plotë - ndryshimet më të vogla nuk mund të ndodhin pa u indinjuar dikush. Dhe sado që ndryshimet ndikuan në punën e tyre, njerëzit thoshin: “Jo, pse? Kjo nuk do të funksionojë."

Por nuk mund të përmirësoheni pa ndryshuar asgjë.

Unë pata një bisedë absolutisht absurde me një punonjës, i thashë idetë e mia për optimizim, të cilave ai më tha:
- Oh, nuk e pe atë që kishim vitin e kaluar!
- Edhe çfarë?
"Tani është shumë më mirë se sa ishte."
- Pra, nuk mund të bëhet më mirë?
- Per cfare?

Pyetje e mirë - pse? Duket sikur tani është më mirë se sa ishte, atëherë gjithçka është mjaft mirë. Kjo çon në mungesë përgjegjësie, gjë që në parim është absolutisht normale. Siç thashë, grupi teknik ishte pak mënjanë. Kompania besonte se ato duhet të ekzistojnë, por askush nuk i ka vendosur kurrë standardet. Mbështetja teknike nuk e pa kurrë SLA, kështu që ishte mjaft "e pranueshme" për grupin (dhe kjo më goditi më shumë):

12 sekonda ngarkim;
5-10 minuta joproduktive çdo lëshim;
Zgjidhja e problemeve kritike kërkon ditë dhe javë;
mungesa e personelit në detyrë 24x7 / në gatishmëri.

Askush nuk u përpoq kurrë të pyeste pse nuk e bëjmë atë më mirë dhe askush nuk e kuptoi se nuk duhet të ishte kështu.

Si bonus, kishte një problem tjetër: mungesa e përvojës. Të moshuarit u larguan dhe ekipi i ri i mbetur u rrit nën regjimin e mëparshëm dhe u helmua prej tij.

Mbi të gjitha këto, njerëzit kishin edhe frikë se mos dështonin dhe shfaqeshin të paaftë. Kjo shprehet në faktin se së pari ata në asnjë rrethanë nuk kërkoi ndihmë. Sa herë kemi biseduar si grup dhe individualisht, dhe unë kam thënë: "Bëj një pyetje nëse nuk di të bësh diçka." Unë jam i sigurt në veten time dhe e di që mund të zgjidh çdo problem, por do të duhet kohë. Prandaj, nëse mund të pyes dikë që di ta zgjidhë për 10 minuta, do të pyes. Sa më pak përvojë të keni, aq më shumë keni frikë të pyesni sepse mendoni se do të konsideroheni të paaftë.

Kjo frikë për të bërë pyetje shfaqet në mënyra interesante. Për shembull, ju pyesni: "Si po ia dilni me këtë detyrë?" - "Kanë mbetur edhe nja dy orë, tashmë po mbaroj." Të nesërmen që pyet sërish, merr përgjigjen se gjithçka është në rregull, por ka pasur një problem, patjetër do të jetë gati deri në fund të ditës. Kalon një ditë tjetër dhe derisa të fiksohesh në mur dhe të detyrohesh të flasësh me dikë, kjo vazhdon. Një person dëshiron ta zgjidhë vetë një problem; ai beson se nëse nuk e zgjidh vetë, do të jetë një dështim i madh.

Kjo është arsyeja pse zhvilluesit i frynë vlerësimet. Ishte e njëjta anekdotë, kur diskutonin për një detyrë të caktuar, më dhanë një shifër të tillë sa u habita shumë. Për të cilën më thanë se në vlerësimet e zhvilluesit, zhvilluesi përfshin kohën që bileta do të kthehet nga QA, sepse ata do të gjejnë gabime atje, dhe kohën që do të marrë PR, dhe kohën kur njerëzit që duhet të shqyrtojnë do të jetë e zënë - domethënë gjithçka, çfarëdo që të jetë e mundur.

Së dyti, njerëzit që kanë frikë të duken të paaftë mbianalizoj. Kur thoni se çfarë saktësisht duhet bërë, fillon: "Jo, po sikur ta mendojmë këtu?" Në këtë kuptim, kompania jonë nuk është unike, ky është një problem standard për të rinjtë.

Si përgjigje, unë prezantova praktikat e mëposhtme:

Rregulli 30 minuta. Nëse nuk mund ta zgjidhni problemin në gjysmë ore, kërkoni dikë që të ndihmojë. Kjo funksionon me shkallë të ndryshme suksesi, sepse njerëzit ende nuk pyesin, por të paktën procesi ka filluar.
Eliminoni gjithçka përveç thelbit, në vlerësimin e afatit për përfundimin e një detyre, domethënë, merrni parasysh vetëm sa kohë do të duhet për të shkruar kodin.
Mësuarit gjatë gjithë jetës për ata që mbianalizojnë. Është thjesht punë e vazhdueshme me njerëzit.

Dita e gjashtëdhjetë

Ndërsa po bëja të gjitha këto, ishte koha për të kuptuar buxhetin. Sigurisht, gjeta shumë gjëra interesante në vendin ku kemi shpenzuar paratë tona. Për shembull, ne kishim një raft të tërë në një qendër të veçantë të dhënash me një server FTP, i cili përdorej nga një klient. Doli që "... ne lëvizëm, por ai mbeti ashtu, nuk e ndryshuam." Ishte 2 vjet më parë.

Me interes të veçantë ishte fatura për shërbimet cloud. Unë besoj se arsyeja kryesore për faturën e lartë të cloud janë zhvilluesit që kanë akses të pakufizuar në serverë për herë të parë në jetën e tyre. Ata nuk kanë nevojë të pyesin: "Ju lutem më jepni një server testimi", ata mund ta marrin vetë. Plus, zhvilluesit duan gjithmonë të ndërtojnë një sistem kaq të lezetshëm sa Facebook dhe Netflix do të jenë xhelozë.

Por zhvilluesit nuk kanë përvojë në blerjen e serverëve dhe aftësinë për të përcaktuar madhësinë e kërkuar të serverëve, sepse ata nuk kishin nevojë për të më parë. Dhe ata zakonisht nuk e kuptojnë plotësisht ndryshimin midis shkallëzueshmërisë dhe performancës.

Rezultatet e inventarit:

Ne lamë të njëjtën qendër të dhënash.
Ndërpreu kontratën me 3 shërbime log. Sepse ne kishim 5 prej tyre - çdo zhvillues që filloi të luante me diçka mori një të re.
7 sisteme AWS u mbyllën. Përsëri, askush nuk i ndali projektet e vdekura; të gjithë vazhduan të punojnë.
Ulja e kostove të softuerit me 6 herë.

Dita e shtatëdhjetë e pesë

Koha kaloi dhe në dy muaj e gjysmë më duhej të takohesha me bordin e drejtorëve. Bordi ynë i drejtorëve nuk është më i mirë apo më i keq se të tjerët; si të gjitha bordet e drejtorëve, ai dëshiron të dijë gjithçka. Njerëzit investojnë para dhe duan të kuptojnë se sa ajo që ne bëjmë përshtatet në grupet e KPI-ve.

Bordi i drejtorëve merr shumë informacion çdo muaj: numrin e përdoruesve, rritjen e tyre, çfarë shërbimesh dhe si përdorin, performancën dhe produktivitetin dhe së fundi, shpejtësinë mesatare të ngarkimit të faqeve.

Problemi i vetëm është se unë besoj se mesatarja është e keqe e pastër. Por është shumë e vështirë t'ia shpjegosh këtë bordit të drejtorëve. Ata janë mësuar të veprojnë me numra të përmbledhur, dhe jo, për shembull, me përhapjen e kohëve të ngarkimit në sekondë.

Kishte disa pika interesante në këtë drejtim. Për shembull, thashë që ne duhet të ndajmë trafikun midis serverëve të veçantë në internet në varësi të llojit të përmbajtjes.

Kjo do të thotë, ColdFusion kalon nëpër Jetty dhe nginx dhe hap faqet. Dhe imazhet, JS dhe CSS kalojnë nëpër një nginx të veçantë me konfigurimet e tyre. Kjo është një praktikë mjaft standarde për të cilën po flas kam shkruar nja dy vite më parë. Si rezultat, fotografitë ngarkohen shumë më shpejt dhe... shpejtësia mesatare e ngarkimit është rritur me 200 ms.

Kjo ndodhi sepse grafiku është ndërtuar bazuar në të dhënat që vijnë me Jetty. Kjo do të thotë, përmbajtja e shpejtë nuk përfshihet në llogaritje - vlera mesatare është rritur. Kjo ishte e qartë për ne, ne qeshnim, por si mund t'i shpjegojmë bordit të drejtorëve pse bëmë diçka dhe gjërat u përkeqësuan me 12%?

Dita e tetëdhjetë e pesë

Në fund të muajit të tretë, kuptova se kishte një gjë në të cilën nuk e kisha llogaritur fare: kohën. Gjithçka për të cilën fola kërkon kohë.

Ky është kalendari im i vërtetë javor - vetëm një javë pune, jo shumë e zënë. Nuk ka kohë të mjaftueshme për gjithçka. Prandaj, përsëri, ju duhet të rekrutoni njerëz që do t'ju ndihmojnë të përballoni problemet.

Përfundim

Kjo nuk është e gjitha. Në këtë histori, as që kam arritur të kuptoj se si kemi punuar me produktin dhe jemi përpjekur të përshtatemi me valën e përgjithshme, ose si kemi integruar mbështetjen teknike, ose si kemi zgjidhur probleme të tjera teknike. Për shembull, mësova krejt rastësisht se në tabelat më të mëdha në bazën e të dhënave nuk përdorim SEQUENCE. Ne kemi një funksion të shkruar vetë nextID, dhe nuk përdoret në një transaksion.

Kishte një milion gjëra të tjera të ngjashme për të cilat mund të flisnim për një kohë të gjatë. Por gjëja më e rëndësishme që duhet thënë ende është kultura.

Është kultura apo mungesa e saj që çon në të gjitha problemet e tjera. Ne po përpiqemi të ndërtojmë një kulturë ku njerëzit:

nuk keni frikë nga dështimet;
mësoni nga gabimet;
të bashkëpunojë me ekipe të tjera;
të marrë iniciativën;
marr pergjegjesi;
mirëpresim rezultatin si objektiv;
duke festuar suksesin.

Me këtë do të vijë gjithçka tjetër.

Leon Fire në twitter, facebook dhe medium.

Ekzistojnë dy strategji në lidhje me trashëgiminë: shmangni punën me të me çdo kusht, ose kapërceni me guxim vështirësitë që lidhen me të. Ne c DevOpsConf Ne po marrim rrugën e dytë, duke ndryshuar procese dhe qasje. Bashkohuni me ne youtube, lista e postimeve и telegram, dhe së bashku do të zbatojmë një kulturë DevOps.

Burimi: www.habr.com

Trashëgimia e sistemeve dhe proceseve të trashëguara ose 90 ditët e para si CTO