Është e njohur se kompetenca e CTO vlerësohet vetëm në herën e dytë të zbatimit të kësaj role. Sepse një gjë është të punosh për disa vjet në një kompani, duke evoluar së bashku me të dhe, duke qenë në të njëjtin kontekst kulturor, të marrësh gradualisht më shumë përgjegjësi. Dhe krejt ndryshe është të hipësh menjëherë në pozitat e CTO në një kompani me një bagazh trashëgimie dhe shumë probleme të fshehura nën tapet.

Në këtë kuptim, përvoja e Leon Fayerit, e cila ai e ndau në DevOpsConf, nuk është pikërisht unike, por duke u mbështetur në përvojën dhe numrin e rolave të ndryshme që ai ka pasur gjatë 20 viteve, është shumë e dobishme. Në vazhdim është kronologjia e ngjarjeve për 90 ditët dhe shumë anekdota, mbi të cilat është kënaqësi të qeshësh, kur ndodhin me dikë tjetër, por me të cilat nuk është aq argëtuese të përballesh personalisht.

Leon tregon shumë ngjyrosur në rusisht, kështu që nëse keni 35-40 minuta, ju rekomandoj të shihni videon. Versioni tekstual për kursimin e kohës është mëposhtë.

Versioni i parë i raportit ishte një përshkrim i mirë-strukturuar i punës me njerëzit dhe proceset, duke përfshirë rekomandime të dobishme. Por ai nuk përcillte të gjitha surprizat që ndodhnin gjatë rrugës. Prandaj, unë e ndryshova formatin dhe paraqita problemet që dolën para meje në kompaninë e re, si djalli nga kutia, dhe metodat për zgjidhjen e tyre në rend kronologjik.

Një muaj para

Siç ndodhin shumë histori të mira, kjo filloi me alkoolin. Ne ishim ulur me të njohur në një bar dhe, siç është zakoni në mes të teknikëve, secili qante për problemet e tij. Një nga ta sapo kishte ndryshuar punë dhe fliste për problemet e tij me teknologjitë, njerëzit dhe ekipin. Sa më shumë e dëgjoja, aq më shumë kuptoja se ai kishte nevojë për mua, sepse pikërisht këto probleme unë i kisha zgjidhur gjatë 15 viteve të fundit. I thashë atij ashtu dhe ditën tjetër u takuam tashmë në një ambient pune. Kompania quhej Teaching Strategies.

Teaching Strategies është lider në tregun e programeve arsimore për fëmijët nga mosha shumë të re — nga lindja deri në tre vjeç. Kompania tradicionale “paper” ka dekada e tani 40 me digital SaaS versionin e saj 10 vjeçar. Së fundmi ka filluar procesi i adaptimit të teknologjisë digjitale në standardet e kompanisë. Versioni 'i ri' është lansuar në vitin 2017 dhe ishte pothuajse si i vjetri, vetëm se funksiononte më keq.

Më e rëndësishmja, trafikimi i kësaj kompanie është shumë i parashikueshëm — çdo ditë dhe çdo vit mund të parashikohet me saktësi se sa njerëz do të vijnë dhe kur. Për shembull, midis orës 13:00 dhe 15:00, të gjithë fëmijët në kopshte shkojnë për të fjetur, dhe mësuesit fillojnë të fusin informacionin. Dhe kështu ndodh çdo ditë, përveç fundjavave, sepse në fundjavë pothuajse askush nuk punon.

Duke përshkruar pak përpara, do të vërej se fillova punën time gjatë periudhës me trafik më të madh vjetor, që është interesante për shumë arsye.

Platforma, e cila duket se kishte vetëm 2 vjet, kishte një stack të veçantë: ColdFusion & SQL Server 2008. ColdFusion, nëse nuk e dini, dhe ndoshta nuk e dini, është një lloj enterprise PHP, që doli në mesin e viteve '90, dhe që nga atëherë unë nuk kam dëgjuar asgjë për të. Aty ishin gjithashtu: Ruby, MySQL, PostgreSQL, Java, Go, Python. Por monoliti kryesor punonte në ColdFusion dhe SQL Server.

Problemet

Sa më shumë flisja me punonjësit e kompanisë rreth punës dhe problemeve me të cilat përballeshin, aq më shumë kuptoja se problemet nuk ishin vetëm teknike. mirë, teknologjia është e vjetër — dhe ne nuk kemi punuar ndonjëherë mbi të tillë, por kishte probleme me ekipin dhe me proceset, dhe kompania këtë filloi ta kuptojë.

Tradicionalisht, teknologët ishin ulur në një qoshe dhe merreshin me punën e tyre. Por gjithnjë e më shumë biznesi filloi të kalonte pikërisht përmes versionit digjital. Prandaj, në kompaninë gjatë vitit të fundit para fillimit të punës sime u shfaqën: një këshill drejtorësh, një CTO, një CPO dhe një QA-direktor. Pra, kompania filloi të investojë në sferën teknologjike.

Gjurmët e trashëgimisë së rëndë ishin jo vetëm në sisteme. Në kompani kishte procese legacy, njerëz legacy, kulturë legacy. Të gjitha këto duhej të ndryshonin. Mendova se do të ishte e mërzitshme, kështu që vendosa të provoja.

Dy ditë para

Dy ditë para fillimit të punës sime të re, arrita në zyrë, plotësova dokumentet e fundit, njoftova ekipin dhe zbulova se ekipi në atë kohë po luftonte me një problem. Problemi ishte se koha mesatare e ngarkesës së faqeve kishte arritur në 4 sekonda, pra dyfish.

Duke parë grafikët, diçka ishte me siguri ndodhur, por nuk ishte e qartë se çfarë. Duhej të ishte një problem me latency në rrjet në qendrën e të dhënave: 5 ms latency në qendrën e të dhënave transformoheshin në 2 sekonda për përdoruesit. Pse ndodhi kështu, nuk e dija, por në çdo rast u bë e qartë se problemi ishte në qendrën e të dhënave.

Dita e parë

Doli kaluan dy dhe, në ditën time të parë të punës, zbulova se problemi nuk kishte zhdukur.

Doli se në dy ditët e kaluara, faqet për përdoruesit ngarkoheshin mesatarisht për 4 sekonda. Po pyes, a e gjetën se çfarë ishte problemi.

— Po, hapëm një tiket.
— Dhe?
— Epo, ata ende nuk na kanë përgjigjur.

Atëherë e kuptova se gjithçka që më kishin thënë më parë ishte vetëm maja e ajsbergut që duhej të përballeshim.

Ka një citat të mirë që i përshtatet shumë këtij rasti:

«N sometimes for technology to change, the organization must change».

Por përderisa fillova punën në periudhën më të ngarkuar të vitit, duhej të shikoja të dy opsionet për zgjidhjen e problemit: si aty për aty, ashtu edhe në afat të gjatë. Dhe të filloja me atë që ishte kritik në atë moment.

Dita e tretë

Pra, ngarkesa zgjat 4 sekonda, dhe nga ora 13 deri në 15 janë pikat më të larta.

Në ditën e tretë, në këtë interval kohe, shpejtësia e ngarkesës dukej kështu:

Nga këndvështrimi im, asgjë nuk funksiononte. Sipas të tjerëve, funksiononte pak më ngadalë se zakonisht. Por nuk ndodhin gjëra të tilla pa arsye — kjo është një problem serioz.

Përpiqesha të bindja ekipin, por ata më thoshin se thjesht nevojiten më shumë serverë. Kjo është, sigurisht, një zgjidhje për problemin, por nuk është gjithmonë e vetmja dhe më efektivja. Pyeta se pse nuk kishte mjaft serverë, çfarë shkalle trafiku. Ekstrahova të dhënat dhe mora se kishim rreth 150 kërkesa në sekondë, që përfundimisht është brenda kufijve të arsyeshëm.

Por nuk duhet të harrojmë se para se të marrim përgjigjen e saktë, duhet të bëjmë pyetjen e duhur. Pyetja ime tjetër ishte: sa servera frontend kemi. Përgjigja më ‘tronditi pak’ — kishim 17 servera frontend!

— Po, turp t'ju pyes, 150 e ndarë me 17, rezulton afërsisht 8? Doni të thoni se çdo server kalon 8 kërkesa në sekondë, dhe nëse nesër do të kemi 160 kërkesa në sekondë, na nevojiten edhe 2 serverë?

Natyrisht, nuk na duhen serverë shtesë. Zgjidhja ishte vetë në kod, dhe madje edhe në sipërfaqe:

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

Ishte një funksion getCurrentClass(), sepse gjithçka në faqe funksionon në kontekstin e klasës — siç duhej. Dhe për vetëm këtë funksion në çdo faqe kishte 200+ kërkesa.

Pra, zgjidhja ishte shumë e thjeshtë, nuk nevojitej të rishkruhej asgjë: thjesht të mos kërkohej e njëjta informacion përsëri.

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

U gëzova shumë, sepse mendova se në ditën e tretë e gjetëm problemin kryesor. Sa naiv isha, kjo ishte vetëm një nga shumë probleme.

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

Në të njëjtën kohë, ne ishim duke u marrë me optimizime të tjera. Ishte shumë gjëra që mund të rregulloheshin. Për shembull, në të njëjtën ditë të tretë, zbulova se në sistem kishte një cache (fillimisht mendova se të gjitha kërkesat po vinin direkt nga databaza). Kur mendoj për cache, imagjinoj standardet Redis ose Memcached. Por kështu mendova vetëm unë, sepse për caching në atë sistem përdoren MongoDB dhe SQL Server — të njëjtin nga i cili sapo kishim lexuar të dhënat.

Dita e dhjetë

Java e parë u kalova me problemet që duhej të zgjidheshin menjëherë. Diku në javën e dytë, erdha për herë të parë në stand-up për të biseduar me ekipin, për të parë se çfarë po ndodhte dhe si po shkonte gjithë procesi.

Përsëri doli diçka interesante. Ekipi përbëhej nga: 18 zhvillues; 8 testues; 3 menaxherë; 2 arkitektë. Dhe të gjithë merrnin pjesë në ritualet e përbashkëta, pra më shumë se 30 persona vinin çdo mëngjes në stand-up dhe tregonin se çfarë kishin bërë. E qartë që takimi nuk zgjatën 5 e as 15 minuta. Askush nuk e dëgjonte njëri-tjetrin, pasi të gjithë punonin në sisteme të ndryshme. Në atë formë, 2-3 tiket në orë në sesionin e grooming ishin rezultate të mira.

E para që bëmë, ishte të ndaheshim ekipin në disa linja produktesh. Për seksionet dhe sistemet e ndryshme, kemi përzgjedhur ekipe të veçanta, të cilat përfshinin zhvillues, testues, menaxherë produktesh, analistë biznesi.

Si rezultat morëm:

• Shkurtime të stand-up-eve dhe takimeve.
• Njohuri të thella për produktin.
• Ndjenjë pronësie. Kur më parë njerëzit rotacionoheshin nëpër sisteme, ata e dinin se ndoshta do t'u duhej të punonin me bug-at e tyre për dikë tjetër, por jo për veten e tyre.
• Bashkëpunim mes grupeve. Nuk ka nevojë të themi se QA dhe programuesit deri më tani nuk kishin biseduar shumë, produkti bënte punën e tij etj. Tani ata kishin një pikë të përbashkët përgjegjësie.

Në tërësi, ne u përqendruam në efikasitetin, performancën dhe cilësinë — këto ishin problematikat që përpiqeshim t'i zgjidhnim duke transformuar ekipin.

Dita e njëmbëdhjetë

Gjatë procesit të ndryshimit të strukturës së ekipit, zbulova se si llogariten HistoriaPikat. 1 SP ishte e barabartë me një ditë, dhe çdo biletë kishte SP për zhvillimin dhe QA, pra të paktën 2 SP.

Si e zbulova këtë?

Gjetëm një defekt: në një nga raportet, ku regjistrohet data e fillimit dhe përfundimit të periudhës për të cilën nevojitet raporti, dita e fundit nuk merret parasysh. Pra, diku në kërkesë kishte një <, jo <=. Më thanë se kjo ishte tre Story Points, pra 3 ditë.

Pas kësaj ne:

• Rishikuam sistemin e vlerësimit të Story Points. Tani, rregullimi i defekteve të vogla, që mund të kalojnë shpejt përmes sistemit, arrin më shpejt te përdoruesi.
• Filluam të bashkojmë bileta të lidhura për zhvillim dhe testim. Më parë, çdo biletë, çdo defekt ishte një ekosistem i mbyllur, 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 QA, në vend të një testi automatik në faqen.
• Filluam të punojmë me zhvilluesit mbi qasjen për vlerësimin e punës. Tre ditë për të ndërruar një buton — kjo nuk është qesharake.

Dita e njëzetë

Diku rreth mesit të muajit të parë, situata u stabilizua pak, e orientova veten me atë që kryesisht po ndodhte, dhe përfundimisht fillova të shikoja përpara dhe të mendoja për zgjidhje afatgjata.

Të ruajë kompatibilitetin me formatin e disku të repozitës git (pa mbajtur kompatibilitetin me mjetet);

• Platforma e menaxhuar. Qindra kërkesa në çdo faqe — kjo nuk është serioze.
• Tendenca të parashikueshme. Ishin periudha të rastësishme të trafikut, të cilat në pamje të parë nuk korrelacionoheshin me metricat e tjera — duhej të kuptonim pse ndodhte kështu dhe të mësonim të parashikonim.
• Zgjerimi i platformës. Biznesi rritet vazhdimisht, po vijnë më shumë përdorues, dhe trafiku po rritet.

Në të kaluarën shpesh thuhej: "Le të riprogramojmë gjithçka në [gjuha/frekuencë], gjithçka do të funksionojë më mirë!"

Në shumicën e rasteve, kjo nuk funksionon, mirë është nëse e riprogramuar do të funksionojë fare. Prandaj, na duhej të krijonim një roadmap — një strategji të qartë që ilustron hap pas hapi, si do të arrihen qëllimet e biznesit (çfarë do të bëjmë dhe për çfarë), e cila:

• reflekton misionin dhe qëllimet e projektit;
• prioritetet kryesore;
• përmban një orar të arritjes së tyre.

Para kësaj, askush nuk kishte biseduar me ekipin për qëllimin e çdo ndryshimi. Për këtë nevojiten treguesit e duhur të suksesit. Herën e parë në historinë e kompanisë, vendosëm KPI për grupin teknik, dhe këta tregues janë lidhur me organizatën.

Pra, KPI-të organizative mbështeten nga ekipet, dhe KPI-të e ekipeve mbështeten nga individët. Në të kundërt, nëse KPI-të teknologjike nuk përputhen me ato organizative, atëherë secili tërheq batanije në anën e vet.

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

Si mund të mbështesim qëllimin për më shumë produkte të reja?

• Së pari, ne duam të kalojmë më shumë kohë në zhvillimin e produkteve të reja në vend që të riparojmë defektet. Kjo është një zgjidhje logjike që matet lehtë.
• Së dyti, ne duam të mbështesim rritjen e volumit të transaksioneve, sepse sa më shumë të rritet pjesa e tregut, aq më shumë përdorues dhe, si rrjedhojë, aq më shumë trafik.

Atëherë KPI-të individuale, të cilat mund të përmbushen brenda grupit do të jenë, për shembull, në atë vend nga vijnë defektet kryesore. Nëse fokusoheni në këtë seksion, mund të bëni që defektet të jenë shumë më pak, dhe pastaj të rritet kohën për zhvillimin e produkteve të reja dhe përsëri për të mbështetur KPI-të organizative.

Kështu, çdo vendim, përfshirë riprogramimin e kodit, duhet të mbështesë qëllimet specifike që kompanija ka vendosur para nesh (rritja e organizatës, funksione të reja, angazhimi i punonjësve).

Gjatë këtij procesi doli një gjë interesante, e cila u bë lajm jo vetëm për teknikët, por për të gjithë në kompani: të gjitha ticket-at duhet të jenë të orientuara për të paktën një KPI. Pra, nëse produkti thotë se dëshiron të bëjë një veçori të re, pyetja e parë duhet të jetë: "Cili KPI mbështetet nga kjo veçori?" Nëse asnjë, atëherë na falni — duket se kjo është një veçori e panevojshme.

Dita e tridhjetë

Në fund të muajit, zbulova një tjetër detaj, se askush nga ekipi im i Ops-it nuk kishte parë ndonjëherë kontratat që lidhim me klientët. Mund të pyesni, pse të shikoni kontratat.

• Së pari, sepse në kontrata janë përshkruar SLA-të.
• Së dyti, SLA-të janë të ndryshme. Çdo klient vinte me kërkesat e tij, dhe departamenti i shitjeve nënshkruante pa vështruar.

Një detaj tjetër interesant — në kontratën me një nga klientët më të mëdhenj është shkruar se të gjitha versionet e softuerit që mbështet platforma duhet të jenë n-1, që do të thotë jo versioni më i fundit, por versioni paraardhës.

E kuptueshme se sa larg ishim nga n-1, kur platforma ishte në ColdFusion dhe SQL Server të vitit 2008, që në korrik u ndal përfundimisht nga mbështetje.

Dita e dyzet e pesë

Diku në mes të muajit të dytë, pata mjaft kohë për të ulur dhe bërë vlerastreammapping një shqyrtim të plotë të procesit. Këto janë hapat e nevojshëm që duhet të merren, nga krijimi i produktit deri te dërgimi i tij tek konsumatori, duke e shpjeguar ato sa më përmbajtshëm.

Pjesëzon procesin në copa të vogla dhe sheh se çfarë merr shumë kohë, çfarë mund të optizosh, përmirësosh, etj. Për shembull, sa kohë merr një kërkesë nga produkti, kalimi përmes grooming, deri sa të arrijë te tiket që zhvilluesi mund ta marrë, QA, etj. E analizoni hollësisht çdo hap të veçantë dhe mendoni çfarë mund të optizoni.

Kur e bëra këtë, m'u dukën dy gjëra:

• përqindje e lartë e kthimeve të tiketve nga QA tek zhvilluesit;
• rishikimi i pull request merrte shumë kohë.

Problemi ishte që këto ishin përfundime si: duket se po merr shumë kohë, por s'jemi të sigurta se sa saktësisht.

«Nuk mund të përmirësosh atë që nuk mund ta masësh».

Si mund të argumentosh se sa e rëndësishme është problemi? A po humben ditë apo orë për shkak të tij?

Për ta matur këtë, shtuam disa hapa në procesin Jira: «ready for dev» dhe «ready for QA», për të matur sa kohë çdo tiket pret dhe sa herë kthehet në një hap të caktuar.

Po ashtu, shtuam «in review», për të ditur se sa kohë mesatarisht qëndrojnë tiketet në review, dhe nga ajo të veprojmë. Kishim sistemet tona të metrikave, tani shtuam metrika të reja dhe filluam të masim:

• Efektiviteti i procesit: produktivitete dhe e planifikuar/dërguar.
• Cilësia e procesit: numri i defekteve, defektet nga QA.

Kjo vërtet ndihmon për të kuptuar se çfarë po ecën mirë dhe çfarë jo.

Dita e pesëdhjetë

Të gjitha këto, sigurisht, janë mirë dhe interesante, por në fund të muajit të dytë ndodhi ajo që në parim ishte e parashikueshme, ndonëse nuk pritej një shkallë e tillë. Njerëzit filluan të largoheshin, sepse u ndryshua drejtimi. Njerëz të rinj u bënë pjesë e menaxhimit dhe filluan të ndryshojnë gjithçka, dhe të vjetrit u larguan. Në përgjithësi, në një kompani që ka disa vite, të gjithë janë miq dhe njohin njëri-tjetrin.

Ishte e parashikueshme, por ajo që ishte e befasishme ishte shkalla e largimeve. Për shembull, në një javë dy timlidë dorëzuan në të njëjtën kohë kërkesën për dorëheqje. Prandaj, mua më duhej të mos harroja problemet e tjera, por të fokusohem në krijimin e një kolektivi. Kjo është një çështje e gjatë dhe e vështirë për t'u zgjidhur, por duhej të merrej parasysh, sepse dëshiroja të ruaja njerëzit që kishin mbetur (ose shumicën e tyre). Duhej të reagoja ndonjë mënyrë ndaj largimit të njerëzve, për të mbajtur moralin në ekip.

Në teori, kjo është mirë: vjen një person i ri, i cili ka pasur plot mundësi, për të vlerësuar aftësitë e ekipit dhe për të zëvendësuar kadrot. Në të vërtetë, nuk mund të sjellësh thjesht njerëz të rinj për shumë arsye. Gjithmonë nevojitet një ekuilibër.

• Të vjetrëve dhe të rinjve. Duhet të mbani njerëzit e vjetër, të cilët mund të ndryshojnë dhe të mbështesin misionin. Por njëkohësisht, duhet të sjellim gjak të ri, për të cilin do të flasim pak më vonë.
• Përvojës. Kam folur shumë me juniorë të mirë, të cilët ishin të motivuar dhe do të dëshironin të punonin me ne. Por nuk mund t'i merrja, sepse kishte pak seniorë që do t'i mbështesin juniorët dhe do të ishin për ta mentorë. Duhej fillimisht të mbushja nivelin e lartë dhe pastaj rinia.
• Me ndihmë dhe guxim.

Nuk kam një përgjigje të mirë për pyetjen se cili është ekuilibri i duhur, si ta mbash atë, sa njerëz duhet të lësh dhe sa duhet të shtypesh. Ky është një proces krejt individual.

Dita e pesëdhjetë e parë

Në fillim po vrojtoja ekipin, për të kuptuar se kush isha, dhe përsëri kujtoj:

«Shumica e problemeve janë probleme me njerëzit».

Zbulova se në ekip, të dyja — zhvilluesit dhe Ops — ekzistojnë tri probleme të mëdha:

• Kënaqësia me situatën aktuale.
• Mungesa e përgjegjësisë — sepse askush nuk e kishte lidhur ndonjëherë rezultatin e punës së ekzekutorëve me ndikimin në biznes.
• Frika nga ndryshimi.

Ndryshimet gjithmonë na nxjerrin nga zona e komfortit, dhe sa më të rinj të jenë njerëzit, aq më shumë nuk i duan ndryshimet, sepse nuk e kuptojnë arsyen dhe nuk dinë si të veprojnë. Përgjigjja më e zakonshme që kam dëgjuar është: "Ne nuk e kemi bërë kurrë si njëherë". E përfshirë ndonjëherë deri në absurditet — çdo ndryshim i vogël nuk kalonte pa që dikush të protestonte. Dhe nuk ka rëndësi sa ata janë të prekshëm nga ndryshimi, njerëzit thoshin: "Pse? Kjo nuk do të funksionojë."

Por nuk mund të bëhesh më i mirë pa bërë ndonjë ndryshim.

Bëra një bisedë krejt absurde me një punonjës, i tregoja idetë e mia për optimizimin, për të cilat ai më tha:
— A, nuk e ke parë se çfarë kemi pasur vitin e kaluar!
— Dhe çfarë?
— Tani është shumë më mirë se sa ishte.
— Pra, nuk mund të ketë akoma më mirë?
— Pse është e nevojshme?

Një pyetje e shkëlqyer — pse? Si duket, nëse tani është më mirë se sa ishte, atëherë gjithçka është mjaft e mirë. Kjo çon në mungesë përgjegjësie, e cila në thelb është krejt normale. Siç e thashë, grupi teknik ishte paksa jashtë. Në kompani konsiderohet se ata duhet të jenë, por askush nuk ka vendosur kurrë standarde.Në mbështetje teknike nuk e kishin parë kurrë SLA-në, prandaj për grupin ishte krejtësisht "e pranueshme" (dhe kjo më habiti më shumë se gjithçka):

• 12 sekonda ngarkesë;
• 5-10 minuta downtime për çdo lëshim;
• zgjidhja e problemeve kritike merr ditë dhe javë;
• mungesa e ndihmës 24/7 / on-call.

Askush nuk ka provuar ndonjëherë të pyesë, pse të mos e bëjmë këtë më mirë, dhe askush nuk ka kuptuar kurrë se si gjërat nuk duhet të jenë.

Si një bonus, kishte gjithashtu një problem tjetër: mungesa e përvojës.Seniorët ishin larguar, dhe grupi i ri që kishte mbetur kishte rritur në mënyrën e mëparshme dhe ishte helmuar prej saj.

Përveç kësaj, njerëzit gjithashtu kishin frikë të dështojnë, të duken të paftë. Kjo shprehet në faktin se ata, së pari, nën asnjë rrethanë nuk kërkonin ndihmë.Sa herë që biseduam në grup dhe individualisht, dhe unë thosha: "Bëni një pyetje, nëse nuk e dini si të bëni diçka". Unë kam besim në veten time dhe e di se mund të zgjidh çdo problem, por kjo do të marrë kohë. Prandaj, nëse mund të pyesësh dikë që e di si ta zgjidhë atë në 10 minuta, do ta bëj. Sa më pak përvojë ke, aq më shumë frikë ke të pyesësh, sepse mendon se do të të konsiderojnë të paftë.

Kjo frikë për të bërë pyetje shfaqet në forma interesante. Për shembull, pyet: "Si po shkon kjo detyrë?" - "I kanë mbetur disa orë, po përfundoj." Ditën tjetër e pyet përsëri, merr përgjigjen se gjithçka është mirë, por ka një problem të vogël, deri në fund të ditës do të përfundojë me siguri. Kalon një tjetër ditë, dhe derisa të mos e shtysh në mur dhe të mos e detyrosh të flasë me dikë, kështu vazhdon. Njeriut i pëlqen ta zgjidhë vetë problemin, mendon se nëse nuk e zgjidh vetë, do të jetë një dështim i madh.

Prandaj zhvilluesit i kanë exageruar vlerësimet. Ishte një anekdotë e tillë, kur po diskutonim për një detyrë të caktuar, më dhanë një shifër që më befasoi shumë. U thashë se në vlerësimet zhvilluesi përfshin edhe kohën që biletat do të kthehen nga QA, sepse atje do të gjejnë gabime, dhe kohën që do të marrë PR, dhe kohën derisa njerëzit që duhet ta rishikojnë të jenë të zënë - pra, gjithçka që është e mundshme.

Së dyti, njerëzit që frikësohen të duken të paaftë, analizojnë tepër. Kur thua se çfarë duhet bërë konkretisht, fillon: "Jo, por çfarë nëse këtu mendojmë?" Në këtë kuptim, kompania jonë nuk është unike, është një problem standard i të rinjve.

Në përgjigje, unë kam futur praktikat e mëposhtme:

• Rregulli i 30 minutave. Nëse brenda gjysmë ore nuk mund të zgjidhni problemin, kërkoni ndihmë nga dikush tjetër. Kjo funksionon me sukses të ndryshueshëm, sepse njerëzit ende nuk kërkojnë, por të paktën procesi fillon.
• Shkëputni gjithçka, përveç thelbit, në vlerësimin e kohës për zbatimin e detyrës, duke llogaritur vetëm sa kohë do të duhen për të shkruar kodin.
• Mësimi i vazhdueshëm për ata që analizojnë shumë. Kjo është thjesht një punë e vazhdueshme me njerëzit.

Dita e njëzetë

Ndërsa merren me këtë, erdhi koha për të kuptuar buxhetin. Sigurisht, gjeta shumë interesante në atë se ku po shpenzonim paratë. Për shembull, kishim një raft të tërë në një qendër të dhënash të veçantë, mbi të cilin ishte një server FTP, që përdorej nga një klient. Doli se "... ne ishim duke u transferuar, dhe ai i mbeti, nuk e ndryshuam." Kjo ishte 2 vjet më parë.

Një interes të veçantë kishte llogaria për shërbimet në cloud. Jam i sigurt se arsyeja kryesore për faturat e larta për shërbimet cloud është se zhvilluesit kanë tani për herë të parë qasje të pakufizuar në serverë. Ata nuk kanë nevojë të kërkojnë: "Më jepni një server provë, ju lutem" — ata mund ta marrin vetë. Për më tepër, zhvilluesit gjithmonë duan të krijojnë një sistem aq të avancuar sa që Facebook dhe Netflix të ndjehen të ziliqarë.

Por zhvilluesit nuk kanë përvojë në blerjen e serverëve dhe në përcaktimin e madhësisë së nevojshme të serverëve, sepse nuk u nevojitej më parë. Dhe zakonisht, ata nuk e kuptojnë plotësisht diferencën midis shkallëzueshmërisë dhe performancës.

Rezultatet e inventarizimit:

• Doli nga një qendër të dhënash.
• Kemi anuluar kontratën me 3 shërbime log. Sepse patëm 5 — çdo zhvillues që fillonte të eksperimentohej merrte një të re.
• Çaktivizuam 7 sisteme AWS. Edhe një herë, projektet e vdekura askush nuk i ndalte, ata vazhdonin të funksiononin.
• U ulën shpenzimet për softuer në 6 herë.

Dita e pesëdhjetë e pestë

Koha kalonte, dhe pas dy muajsh e një periudhe dyjavore, duhej të takohesha me këshillin e drejtuesve. Këshilli ynë i drejtuesve nuk është më i mirë e as më i keq se të tjerët, ai siç është i gjithë këshilli i drejtuesve dëshiron të dijë gjithçka. Njerëzit investojnë para dhe duan të kuptojnë se si ajo që bëjmë përputhet me KPI-të e përcaktuar.

Këshilli i drejtuesve merr shumë informacion çdo muaj: numrin e përdoruesve, rritjen e tyre, cilat shërbime përdorin dhe si, performancën dhe produktivitetin, dhe përfundimisht, shpejtësinë mesatare të ngarkesës së faqes.

Problemi është se mendoj se mesatarja është një e keqe e pastër. Por është shumë e vështirë t'ua shpjegosh këtë këshillit të drejtorëve. Ata janë mësuar të operojnë me numra të agreguar, dhe jo, për shembull, me shtrirjen e kohës së ngarkesës në sekonda.

Në këtë kuptim, kishte momente interesante. Për shembull, thashë se duhej të ndaja trafikun midis seriverëve të ndryshëm të uebit në varësi të llojit të përmbajtjes.

Pra, ColdFusion kalon përmes Jetty dhe nginx dhe ngarkon faqet. Ndërsa imazhet, JS dhe CSS shkojnë përmes një nginx të veçantë me konfigurimet e tij. Kjo është një praktikë mjaft standarde, për të cilën unë shkruar kisha dëgjuar disa vite më parë. Si rezultat, imazhet u ngarkuan shumë më shpejt, dhe … shpejtësia mesatare e ngarkesës u rrit me 200 ms.

Kjo ndodhi sepse grafiku ndërtohet në bazë të të dhënave që vijnë nga Jetty. D.m.th. përmbajtja e shpejtë nuk përfshihet në llogaritje — mesatarja u rrit. Ne e kuptuam këtë, u qeshëm, por si t'ia shpjegojmë këshillit të drejtuesve pse bëmë diçka dhe u bë më keq me 12%?

Dita e tetëdhjetë e pestë

Në fund të muajit të tretë, kuptova se për një gjë nuk kisha llogaritur fare — është koha. Për të gjitha ato që kam treguar, nevojitet kohë.

Ky është kalendari im real për javën — thjesht një javë pune, jo shumë e ngarkuar. Koha nuk më mjafton për gjithçka. Prandaj përsëri duhen të angazhohen njerëz që do ndihmojnë në zgjidhjen e problemeve.

Përfundimi

Kjo nuk është gjithçka. Në këtë tregim nuk kam arritur akoma në mënyrën se si punuam me produktin dhe u përpoqëm të harmonizoheshim, apo si e integruam mbështetje teknike, apo si e zgjidhëm probleme të tjera teknike. Për shembull, mësova rastësisht se në tabelat më të mëdha në databazë nuk po përdornim SEQUENCE. Kemi një funksion të shkruar nga vetë nextID, dhe nuk përdoret në transaksione.

Ishte edhe një milion gjëra të ngjashme, për të cilat mund të flasësh për një kohë të gjatë. Por gjëja më e rëndësishme që duhet diskutuar është kultura.

Pikërisht kultura, ose mungesa e saj, çon në të gjitha problemet e tjera. Ne përpiqemi të ndërtim një kulturë ku njerëzit:

• nuk kanë frikë nga dështimi;
• mësojnë nga gabimet;
• bashkëpunojnë me ekipe të tjera;
• ka iniciativa;
• marrin përgjegjësinë për vetë;
• pranojnë rezultatin si qëllim;
• festojnë suksesin.

Me këtë, gjërat e tjera do të vijnë.

Leon Fayer në twitter, facebook dhe te medium.

Në lidhje me legacy ka dy strategji: të shmangim me çdo kusht punën me të, ose të përballojmë me guxim vështirësitë që e shoqërojnë. Ne DevOpsConf jemi në rrugën e dytë, duke ndryshuar proceset dhe qasjet. Bashkohuni me ne në youtube, dërgesën dhe telegram, dhe të punojmë së bashku për të vendosur kulturën DevOps.

Burimi: habr.com