It is bekend dat de kompetinsje fan 'e CTO allinich de twadde kear wurdt hifke as hy dizze rol útfiert. Want it is ien ding om ferskate jierren yn in bedriuw te wurkjen, dêrmei te evoluearjen en, yn deselde kulturele kontekst, stadichoan mear ferantwurdlikens te krijen. En it is hiel wat oars om direkt yn de funksje fan technysk direkteur te kommen by in bedriuw mei legacy bagaazje en in bulte problemen kreas ûnder it kleed fege.

Yn dizze sin, de ûnderfining fan Leon Fire, dêr't hy dielde op DevOpsConf, net krekt unyk, mar fermannichfâldige troch syn ûnderfining en it oantal ferskillende rollen dy't hy yn 'e rin fan 20 jier koe besykje, is it heul nuttich. Under de besuniging is in gronology fan eveneminten oer 90 dagen en in protte ferhalen dy't leuk binne om te laitsjen as se mei in oar barre, mar dy't net sa leuk binne om persoanlik tsjin te gean.

Leon praat tige kleurich yn it Russysk, dus as jo 35-40 minuten hawwe, advisearje ik it fideo te besjen. Tekstferzje om tiid hjirûnder te besparjen.

De earste ferzje fan it rapport wie in goed strukturearre beskriuwing fan it wurkjen mei minsken en prosessen, mei nuttige oanbefellings. Mar se hat net alle ferrassingen oerbrocht dy't ûnderweis tsjinkamen. Dêrom haw ik it formaat feroare en de problemen presintearre dy't foar my as in jack-in-the-box yn it nije bedriuw opdûken, en metoaden foar it oplossen fan se yn gronologyske folchoarder.

In moanne earder

Lykas in protte goede ferhalen begon dit mei alkohol. Wy sieten mei freonen yn in bar, en lykas ferwachte ûnder IT-spesjalisten, skriemde elkenien oer har problemen. Ien fan harren hie krekt feroare baan en praat oer syn problemen mei technology, en mei minsken, en mei it team. Hoe mear ik harke, hoe mear ik besefte dat hy my gewoan oannimme moast, want dit binne de soarten problemen dy't ik de lêste 15 jier oplost haw. Ik fertelde him sa, en de oare deis wy moete yn in wurk omjouwing. It bedriuw waard Teaching Strategies neamd.

Teaching Strategies is in merklieder yn kurrikulum foar heul jonge bern fan berte oant trije jier âld. It tradisjonele "papier" bedriuw is al 40 jier âld, en de digitale SaaS ferzje fan it platfoarm is 10 jier âld. Relatyf koartlyn begon it proses fan it oanpassen fan digitale technology oan bedriuwsnormen. De "nije" ferzje lansearre yn 2017 en wie hast as de âlde, allinich wurke it slimmer.

It meast nijsgjirrige is dat it ferkear fan dit bedriuw heul foarsisber is - fan dei ta dei, fan jier nei jier kinne jo heul dúdlik foarsizze hoefolle minsken komme en wannear. Bygelyks, tusken 13 en 15 gean alle bern yn pjutteboartersplakken op bêd en leararen begjinne ynformaasje yn te fieren. En dat bart alle dagen, útsein it wykein, want yn it wykein wurket hast net ien.

In bytsje foarút sjen, sil ik konstatearje dat ik myn wurk begon yn 'e perioade fan' e heechste jierlikse ferkear, wat om ferskate redenen ynteressant is.

It platfoarm, dat mar 2 jier âld like te wêzen, hie in eigenaardige stapel: ColdFusion & SQL Server út 2008. ColdFusion, as jo net witte, en nei alle gedachten jo net witte, is in ûndernimming PHP dy't kaam út yn 'e midden fan' e jierren '90, en sûnt doe haw ik net iens heard fan it. Ek wiene der: Ruby, MySQL, PostgreSQL, Java, Go, Python. Mar de wichtichste monolith rûn op ColdFusion en SQL Server.

Problemen

Hoe mear ik mei meiwurkers fan it bedriuw praat oer it wurk en hokker problemen der tsjinkaam, hoe mear ik besefte dat de problemen net allinnich technysk fan aard wiene. Okay, de technology is âld - en se wurken der net oan, mar d'r wiene problemen mei it team en mei de prosessen, en it bedriuw begon dit te begripen.

Tradysjoneel sieten har technyk yn 'e hoeke en diene wat soarte wurk. Mar mear en mear bedriuwen begûn te gean troch de digitale ferzje. Dêrom ferskynden yn it lêste jier foardat ik begon te wurkjen nijen yn it bedriuw: ried fan direkteuren, CTO, CPO en QA-direkteur. Dat is, it bedriuw begon te ynvestearjen yn 'e technologysektor.

Spoaren fan in swiere erfenis wiene net allinich yn 'e systemen. It bedriuw hie legacy prosessen, legacy minsken, legacy kultuer. Dit alles moast feroare wurde. Ik tocht dat it perfoarst net saai wêze soe, en besleat it te besykjen.

Twa dagen earder

Twa dagen foar it begjin fan in nije baan, kaam ik op it kantoar, folde it lêste papierwurk yn, moete it team, en ûntduts dat it team op dat stuit mei in probleem wraksele. It wie dat de gemiddelde side-laadtiid sprong nei 4 sekonden, dat is 2 kear.

Te oardieljen nei de grafyk, wat dúdlik bard, en it is net dúdlik wat. It die bliken dat it probleem netwurklatinsje yn it datasintrum wie: 5 ms latency yn it datasintrum feroare yn 2 s foar brûkers. Ik wist net wêrom dit barde, mar yn alle gefallen waard bekend dat it probleem yn it datasintrum wie.

Earste dei

Twa dagen ferrûn en op myn earste wurkdei ûntduts ik dat it probleem net fuort wie.

Twa dagen lang laden de siden fan brûkers gemiddeld yn 4 sekonden. Ik freegje oft se fûn wat it probleem is.

- Ja, wy hawwe in kaartsje iepene.
- EN?
- No, se hawwe ús noch net antwurde.

Doe besefte ik dat alles wat ik earder ferteld wie mar in lyts tipje fan 'e iisberch wie dat ik moast fjochtsje.

D'r is in goed sitaat dat hjir goed past:

"Soms om technology te feroarjen moatte jo de organisaasje feroarje."

Mar sûnt ik begon te wurkjen yn 'e drokste tiid fan it jier, moast ik nei beide opsjes sjen om it probleem op te lossen: sawol fluch as op lange termyn. En begjin mei wat no kritysk is.

Day Three

Sa, it laden duorret 4 sekonden, en fan 13 oant 15 de grutste toppen.

Op de tredde dei yn dizze perioade seach de downloadsnelheid sa út:

Fanút myn eachpunt wurke hielendal neat. Ut alle oaren syn eachpunt gie it wat stadiger as oars. Mar it bart gewoan net sa - it is in serieus probleem.

Ik besocht it team te oertsjûgjen, wêrop se antwurden dat se gewoan mear tsjinners nedich wiene. Dit is fansels in oplossing foar it probleem, mar it is net altyd de ienige en meast effektive. Ik frege wêrom't d'r net genôch servers wiene, wat wie it folume fan ferkear. Ik haw de gegevens ekstrapolearre en fûn dat wy sawat 150 oanfragen per sekonde hawwe, dy't yn prinsipe binnen ridlike grinzen falt.

Mar wy moatte net ferjitte dat foardat jo it goede antwurd krije, jo de juste fraach moatte stelle. Myn folgjende fraach wie: hoefolle frontend-servers hawwe wy? It antwurd "ferbjustere my in bytsje" - wy hiene 17 frontend-tsjinners!

- Ik skamje my om te freegjen, mar 150 dield troch 17 jout sa'n 8? Binne jo sizze dat eltse tsjinner jout 8 fersiken per sekonde, en as moarn binne der 160 fersiken per sekonde, wy sille nedich 2 mear tsjinners?

Fansels hiene wy ​​gjin ekstra servers nedich. De oplossing wie yn 'e koade sels, en op it oerflak:

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

Der wie in funksje getCurrentClass(), om't alles op 'e side wurket yn' e kontekst fan in klasse - dat is krekt. En foar dizze iene funksje op elke side wiene der 200+ oanfragen.

De oplossing op dizze manier wie heul ienfâldich, jo hoegden net iens wat oer te skriuwen: freegje gewoan net wer om deselde ynformaasje.

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

Ik wie tige bliid, om't ik besletten dat ik krekt de tredde dei it haadprobleem fûn hie. Naïv as ik wie, dit wie mar ien fan de protte problemen.

Mar it oplossen fan dit earste probleem sakke de grafyk folle leger.

Tagelyk diene wy ​​oare optimalisaasjes. Der wiene in protte dingen yn sicht dy't reparearre wurde koene. Bygelyks, op deselde tredde dei ûntduts ik dat der nei alle gedachten in cache yn it systeem wie (earst tocht ik dat alle oanfragen direkt út de databank kamen). As ik tink oan in cache, Ik tink oan standert Redis of Memcached. Mar ik wie de iennichste dy't dat tocht, om't dat systeem MongoDB en SQL Server brûkte foar caching - deselde wêrfan de gegevens krekt lêzen waarden.

Dei tsien

De earste wike hie ik te krijen mei problemen dy't no krekt oplost wurde moasten. Ergens yn de twadde wike kaam ik foar it earst nei de stand-up om te kommunisearjen mei it team, om te sjen wat der bart en hoe't it hiele proses ferrint.

Der waard wer wat nijsgjirrichs ûntdutsen. It team bestie út: 18 ûntwikkelders; 8 testers; 3 bestjoerders; 2 arsjitekten. En se diene allegear mei oan mienskiplike rituelen, dat is, mear as 30 minsken kamen elke moarn nei de stand-up en fertelden wat se diene. It is dúdlik dat de gearkomste gjin 5 of 15 minuten duorre. Nimmen harke nei ien, om't elkenien op ferskate systemen wurket. Yn dizze foarm wiene 2-3 kaarten yn 'e oere foar in trimsesje al in goed resultaat.

It earste wat wy diene wie it team te splitsen yn ferskate produktlinen. Foar ferskate seksjes en systemen hawwe wy aparte teams tawiisd, dy't ûntwikkelders, testers, produktbehearders en saaklike analisten omfetten.

As resultaat krigen wy:

• It ferminderjen fan stand-ups en rallyen.
• Underwerp kennis fan it produkt.
• In gefoel fan eigendom. Doe't minsken eartiids altyd mei systemen knutselen, wisten se dat in oar nei alle gedachten mei har bugs soe moatte wurkje, mar net harsels.
• Gearwurking tusken groepen. Unmooglik om te sizzen dat QA earder net folle kommunisearre mei programmeurs, it produkt die syn eigen ding, ensfh. No hawwe se in mienskiplik punt fan ferantwurdlikens.

Wy rjochte ús benammen op effisjinsje, produktiviteit en kwaliteit - dit binne de problemen dy't wy besochten op te lossen mei de transformaasje fan it team.

Dei alve

Yn it proses fan it feroarjen fan de teamstruktuer, ûntduts ik hoe't ik telle Ferhaalpunten. 1 SP wie gelyk oan ien dei, en elk kaartsje befette SP foar sawol ûntwikkeling en QA, dat is op syn minst 2 SP.

Hoe haw ik dit ûntdutsen?

Wy fûnen in brek: yn ien fan 'e rapporten, wêr't de start- en eindatum fan 'e perioade wêrfoar't it rapport nedich is ynfierd wurdt, wurdt de lêste dei net yn rekken brocht. Dat is, earne yn it fersyk wie net <=, mar gewoan <. Ik waard ferteld dat dit trije Story Points, dat is 3 fan 'e dei.

Nei dit wy:

• It wurdearringsysteem Story Points is feroare. No reparaasjes foar lytse bugs dy't fluch troch it systeem kinne wurde trochjûn, berikke de brûker rapper.
• Wy begûnen besibbe kaartsjes te fusearjen foar ûntwikkeling en testen. Earder wie elk kaartsje, elke brek in sletten ekosysteem, net bûn oan wat oars. It feroarjen fan trije knoppen op ien side koe trije ferskillende kaartsjes west hawwe mei trije ferskillende QA-prosessen ynstee fan ien automatisearre test per side.
• Wy begûnen te wurkjen mei ûntwikkelders oan in oanpak foar it skatten fan arbeidskosten. Trije dagen om ien knop te feroarjen is net grappich.

Dei tweintichste

Earne yn 'e midden fan' e earste moanne stabilisearre de situaasje in bytsje, ik fûn út wat der yn prinsipe bart, en begon al yn 'e takomst te sjen en te tinken oer oplossingen op lange termyn.

Lange termyn doelen:

• Beheard platfoarm. Hûnderten oanfragen op elke side binne net serieus.
• Foarsisbere trends. D'r wiene periodike ferkearspieken dy't op it earste each net korrelearren mei oare metriken - wy moasten begripe wêrom't dit barde en learje te foarsizzen.
• Platfoarm útwreiding. It bedriuw groeit konstant, mear en mear brûkers komme, en ferkear nimt ta.

Yn it ferline waard faak sein: "Litte wy alles opnij skriuwe yn [taal / ramt], alles sil better wurkje!"

Yn 'e measte gefallen wurket dit net, it is goed as it herskriuwen hielendal wurket. Dêrom moasten wy in roadmap meitsje - in spesifike strategy dy't stap foar stap yllustrearret hoe't bedriuwsdoelen sille wurde berikt (wat wy sille dwaan en wêrom), dy't:

• wjerspegelet de missy en doelen fan it projekt;
• prioritearret haaddoelen;
• befettet in skema foar it berikken fan harren.

Dêrfoar hie gjinien mei it team praat oer it doel fan feroaringen dy't makke wurde. Dit fereasket de juste súksesmetriken. Foar it earst yn 'e skiednis fan it bedriuw sette wy KPI's foar de technyske groep, en dizze yndikatoaren wiene bûn oan organisatoaryske.

Dat is, organisatoaryske KPI's wurde stipe troch teams, en team KPI's wurde stipe troch yndividuele KPI's. Oars, as technologyske KPI's net gearfalle mei organisatoaryske, dan lûkt elkenien de tekken op himsels.

Bygelyks, ien fan 'e organisatoaryske KPI's fergruttet merkoandiel troch nije produkten.

Hoe kinne jo it doel stypje om mear nije produkten te hawwen?

• Earst wolle wy mear tiid besteegje oan it ûntwikkeljen fan nije produkten ynstee fan it reparearjen fan defekten. Dit is in logyske oplossing dy't maklik te mjitten is.
• Twads wolle wy in ferheging fan transaksjevolumint stypje, om't hoe grutter it merkoandiel, hoe mear brûkers en, dus, hoe mear ferkear.

Dan sille yndividuele KPI's dy't binnen de groep útfierd wurde kinne, bygelyks op it plak wêze wêr't de wichtichste mankeminten weikomme. As jo ​​spesifyk rjochtsje op dizze seksje, kinne jo der wis fan dat der folle minder mankeminten, en dan sil tanimme de tiid foar it ûntwikkeljen fan nije produkten en wer foar it stypjen fan organisatoaryske KPIs.

Sa moat elke beslút, ynklusyf herskriuwen fan koade, de spesifike doelen stypje dy't it bedriuw foar ús hat ynsteld (organisatoaryske groei, nije funksjes, werving).

Tidens dit proses kaam der in nijsgjirrich ding oan it ljocht, dat waard nijs net allinnich foar techies, mar yn it algemien yn it bedriuw: alle kaartsjes moatte wurde rjochte op op syn minst ien KPI. Dat is, as in produkt seit dat it in nije funksje wol meitsje, moat de earste fraach steld wurde: "Hokker KPI stipet dizze funksje?" As net, sorry dan - it liket in ûnnedige funksje.

Dei tritich

Oan 'e ein fan' e moanne ûntduts ik in oare nuânse: gjinien yn myn Ops-team hat ea de kontrakten sjoen dy't wy mei kliïnten oangeane. Jo kinne freegje wêrom't jo kontakten moatte sjen.

• As earste, om't SLA's binne spesifisearre yn kontrakten.
• Twad, SLA's binne allegear oars. Elke klant kaam mei syn eigen easken, en de ferkeapôfdieling tekene sûnder te sjen.

In oare nijsgjirrige nuânse is dat it kontrakt mei ien fan 'e grutste kliïnten stelt dat alle softwareferzjes dy't troch it platfoarm stipe wurde moatte n-1 wêze, dat is net de lêste ferzje, mar de foarlêste.

It is dúdlik hoe fier wy wiene fan n-1 as it platfoarm wie basearre op ColdFusion en SQL Server 2008, dat waard net mear stipe hielendal yn july.

Dei fiifenfjirtich

Om 'e midden fan' e twadde moanne hie ik genôch tiid om te sitten en te dwaan weardestreammappen folslein foar it hiele proses. Dit binne de nedige stappen dy't moatte wurde nommen, fan it meitsjen fan in produkt oant it leverjen fan it oan de konsumint, en se moatte sa yn detail mooglik beskreaun wurde.

Jo brekke it proses yn lytse stikken en sjogge wat tefolle tiid nimt, wat kin wurde optimalisearre, ferbettere, ensfh. Bygelyks, hoe lang duorret it foar in produktfersyk om troch fersoarging te gean, wannear berikt it in kaartsje dat in ûntwikkelder kin nimme, QA, ensfh. Sa sjogge jo elke yndividuele stap yn detail en tinke oer wat kin wurde optimalisearre.

Doe't ik dit die, foelen twa dingen myn each:

• hege persintaazje kaartsjes werom fan QA werom nei ûntwikkelders;
• pull fersyk resinsjes naam te lang.

It probleem wie dat dit konklúzjes wiene lykas: It liket in protte tiid te nimmen, mar wy binne net wis hoe lang.

"Jo kinne net ferbetterje wat jo net mjitte kinne."

Hoe te rjochtfeardigjen hoe serieus it probleem is? Fergrieme it dagen of oeren?

Om dit te mjitten hawwe wy in pear stappen tafoege oan it Jira-proses: "klear foar dev" en "klear foar QA" om te mjitten hoe lang elk ticket wacht en hoefolle kear it weromkomt nei in bepaalde stap.

Wy hawwe ek tafoege "yn resinsje" om te witten hoefolle tickets binne gemiddeld foar resinsje, en fan dit kinne jo begjinne te dûnsjen. Wy hiene systeemmetriken, no hawwe wy nije metriken tafoege en begon te mjitten:

• Proses effisjinsje: prestaasje en pland / levere.
• Proses kwaliteit: oantal mankeminten, mankeminten út QA.

It helpt echt om te begripen wat goed giet en wat net goed giet.

Dei fyftichste

Dit is fansels allegear goed en nijsgjirrich, mar nei de ein fan 'e twadde moanne barde der wat dat yn prinsipe foarsisber wie, hoewol ik sa'n skaal net ferwachte. Minsken begûnen fuort te gean om't it topmanagement feroare wie. Nije minsken kamen yn it management en begûnen alles te feroarjen, en de âlde stopten. En meastal yn in bedriuw dat in pear jier âld is, elkenien is freonen en elkenien kin inoar.

Dit waard ferwachte, mar de skaal fan de ûntslaggen wie ûnferwachts. Sa hawwe yn ien wike twa teamleaders tagelyk har ûntslach yntsjinne út eigen frije wil. Dêrom, ik moast net allinne ferjitte oer oare problemen, mar rjochtsje op it meitsjen fan in team. Dit is in lang en dreech probleem om op te lossen, mar it moast wurde behannele om't ik de minsken dy't oerbleaune (of de measten fan harren) rêde woe. It wie nedich om ien of oare manier te reagearjen op it feit dat minsken fuortgeane om de moraal yn it team te behâlden.

Yn teory is dit goed: der komt in nije persoan dy't folsleine carte blanche hat, dy't de feardichheden fan it team evaluearje kin en personiel ferfange kin. Yn feite kinne jo net gewoan nije minsken bringe om safolle redenen. Balâns is altyd nedich.

• Ald en nij. Wy moatte âlde minsken hâlde dy't feroarje kinne en de missy stypje. Mar tagelyk moatte wy nij bloed ynhelje, dêr prate wy efkes letter oer.
• Ûnderfining. Ik ha in protte praat mei goede junioaren dy't entûsjast wiene en mei ús wurkje woene. Mar ik koe se net oannimme om't der net genôch senioaren wiene om de junioaren te stypjen en as mentors foar har op te treden. It wie nedich om earst de top te rekrutearjen en pas dan de jeugd.
• Wortel en stok.

Ik haw gjin goed antwurd op de fraach wat it goede lykwicht is, hoe it te behâlden, hoefolle minsken te hâlden en hoefolle te triuwe. Dit is in suver yndividueel proses.

Dei ienenfyftich

Ik begon goed nei it team te sjen om te begripen wa't ik hie, en nochris herinnerde ik my:

"De measte problemen binne problemen fan minsken."

Ik haw fûn dat it team as sadanich - sawol Dev as Ops - trije grutte problemen hat:

• Tefredenheid oer de aktuele stân fan saken.
• Gebrek oan ferantwurdlikens - om't nimmen de resultaten fan 'e wurken fan 'e artysten oait brocht hat om it bedriuw te beynfloedzjen.
• Eangst foar feroaring.

Feroaring nimt jo altyd út jo komfortensône, en de jongere minsken binne, hoe mear se net leukje fan feroaring, om't se net begripe wêrom en se net begripe hoe. It meast foarkommende antwurd dat ik haw heard is: "Dat hawwe wy noait dien." Boppedat berikte it it punt fan folsleine absurditeit - de minste feroarings koenen net plakfine sûnder dat immen ferûntskuldigje. En hoefolle de feroaringen ek beynfloede har wurk, minsken seine: "Nee, wêrom? Dit sil net wurkje."

Mar jo kinne net better wurde sûnder wat te feroarjen.

Ik hie in absurd konversaasje mei in meiwurker, ik fertelde him myn ideeën foar optimalisaasje, dêr't hy my fertelde:
- Och, do hast net sjoen wat wy ferline jier hiene!
- No en?
"No is it folle better as it wie."
- Dus, it kin net better?
- Wêrfoar?

Goede fraach - wêrom? It is as is it no better as it wie, dan is alles goed genôch. Dit liedt ta in gebrek oan ferantwurdlikens, wat yn prinsipe absolút normaal is. Sa't ik sei, de technyske groep wie in bytsje oan 'e kant. It bedriuw leaude dat se moatte bestean, mar gjinien ea set de noarmen. Technyske stipe hat de SLA noait sjoen, dus it wie frij "akseptabel" foar de groep (en dit foel my it meast):

• 12 sekonden laden;
• 5-10 minuten downtime eltse release;
• Troubleshooting krityske problemen duorret dagen en wiken;
• gebrek oan plicht personiel 24x7 / on-call.

Nimmen hat ea besocht om te freegjen wêrom dogge wy it net better, en gjinien hat ea beseft dat it net sa hoecht te wêzen.

As bonus wie d'r noch ien probleem: gebrek oan ûnderfining. De senioaren ferlieten, en it oerbleaune jonge team groeide op ûnder it foarige rezjym en waard dêrtroch fergiftige.

Boppe-op dit alles wiene de minsken ek bang om te mislearjen en ynkompetint te ferskinen. Dit wurdt útdrukt yn it feit dat, foarearst, sy ûnder gjin omstannichheden frege om help. Hoefolle kearen hawwe wy praat as in groep en yndividueel, en ik haw sein, "Stel in fraach as jo net witte hoe te dwaan wat." Ik bin fertrouwen yn mysels en wit dat ik elk probleem kin oplosse, mar it sil tiid nimme. Dêrom, as ik ien freegje kin dy't it yn 10 minuten kin oplosse, sil ik freegje. Hoe minder ûnderfining jo hawwe, hoe banger jo binne om te freegjen, om't jo tinke dat jo sille wurde beskôge as inkompetint.

Dizze eangst foar it stellen fan fragen manifestearret him op nijsgjirrige manieren. Jo freegje bygelyks: "Hoe giet it mei dizze taak?" - "In pear oeren oer, ik bin al klear." De oare deis freegje jo nochris, jo krije it antwurd dat alles goed is, mar der wie ien probleem, it sil grif klear wêze oan 'e ein fan 'e dei. Noch in dei giet foarby, en oant jo oan 'e muorre pinne wurde en twongen om mei immen te praten, giet dit troch. In persoan wol in probleem sels oplosse; hy leaut dat as hy it sels net oplost, it in grutte mislearring sil wêze.

Dat is dêrom de ûntwikkelders opblaze de rûzingen. It wie dyselde anekdoate, doe't se oer in bepaalde taak wiene, joegen se my sa'n figuer dat ik tige ferrast wie. Dêr't ik waard ferteld dat yn 'e rûzingen fan' e ûntwikkelders, de ûntwikkelder de tiid omfettet dat it kaartsje sil wurde weromjûn fan QA, om't se dêr flaters sille fine, en de tiid dy't de PR sil nimme, en de tiid wylst de minsken dy't moatte besjen it sil drok wêze - dat is alles, wat mooglik is.

Twads, minsken dy't bang binne om ynkompetint te ferskinen oeranalyze. As jo ​​sizze wat der krekt dien wurde moat, begjint it: "Nee, wat as wy hjir oer tinke?" Yn dizze sin is ús bedriuw net unyk; dit is in standertprobleem foar jonge minsken.

As antwurd yntrodusearre ik de folgjende praktiken:

• Regel 30 minuten. As jo ​​​​it probleem net yn in heal oere kinne oplosse, freegje dan ien om te helpen. Dit wurket mei wikseljend súkses, om't minsken noch net freegje, mar teminsten is it proses begûn.
• Eliminearje alles behalve de essinsje, by it skatten fan de deadline foar it foltôgjen fan in taak, dat is, beskôgje allinich hoe lang it sil nimme om de koade te skriuwen.
• Libbenslang leare foar dyjingen dy't overanalyze. It is gewoan konstant wurk mei minsken.

Dei sechstichste

Wylst ik dit alles die, wie it tiid om de begrutting út te finen. Fansels fûn ik in protte nijsgjirrige dingen yn wêr't wy ús jild útjûn hawwe. Bygelyks, wy hiene in hiele rack yn in apart data sintrum mei ien FTP tsjinner, dat waard brûkt troch ien klant. It die bliken dat "... wy ferhuze, mar hy bleau sa, wy hawwe him net feroare." It wie 2 jier lyn.

Fan bysûnder belang wie de rekken foar wolktsjinsten. Ik leau dat de wichtichste reden foar de hege wolkenrekken is de ûntwikkelders dy't foar it earst yn har libben ûnbeheinde tagong hawwe ta servers. Se hoege net te freegjen: "Jou my asjebleaft in testtsjinner," se kinne it sels nimme. Plus, ûntwikkelders wolle altyd sa'n koel systeem bouwe dat Facebook en Netflix jaloersk sille wêze.

Mar de ûntwikkelders hawwe gjin ûnderfining yn it keapjen fan servers en de feardigens om de fereaske grutte fan servers te bepalen, om't se it earder net nedich hawwe. En se begripe gewoanlik it ferskil tusken skalberens en prestaasjes net hielendal.

Ynventarisaasje resultaten:

• Wy ferlieten itselde datasintrum.
• Wy hawwe it kontrakt mei 3 log tsjinsten beëinige. Om't wy 5 fan harren hiene - elke ûntwikkelder dy't begon te boartsjen mei wat naam in nij.
• 7 AWS-systemen waarden ôfsletten. Nochris stoppe gjinien de deade projekten; se bleauwen allegear wurkje.
• Reduzearre software kosten mei 6 kear.

Dei fiifensantich

De tiid gie foarby, en yn twa en in heale moanne moast ik moetsje mei de ried fan bestjoer. Us ried fan bestjoer is net better of minder as oaren; lykas alle rieden fan bestjoer wol it alles witte. Minsken ynvestearje jild en wolle begripe hoefolle wat wy dogge past yn 'e set KPI's.

De ried fan bestjoer krijt alle moannen in soad ynformaasje: it oantal brûkers, har groei, hokker tsjinsten se brûke en hoe, prestaasjes en produktiviteit, en as lêste, gemiddelde sideladingssnelheid.

It ienige probleem is dat ik leau dat it gemiddelde is suver kwea. Mar it is hiel lestich om dit út te lizzen oan de ried fan bestjoer. Se binne wend om te operearjen mei aggregearre nûmers, en net, bygelyks, de fersprieding fan laden tiden per sekonde.

D'r wiene wat nijsgjirrige punten yn dit ferbân. Ik sei bygelyks dat wy ferkear moatte splitse tusken aparte webservers ôfhinklik fan it type ynhâld.

Dat is, ColdFusion giet troch Jetty en nginx en lanseart de siden. En ôfbyldings, JS en CSS geane troch in aparte nginx mei har eigen konfiguraasjes. Dit is in frij standert praktyk dêr't ik it oer ha skreaun in pear jier lyn. As gefolch, foto's laden folle flugger, en ... de gemiddelde laden snelheid is ferhege mei 200 ms.

Dit barde omdat de grafyk is boud op basis fan de gegevens dy't komt mei Jetty. Dat is, snelle ynhâld is net opnommen yn 'e berekkening - de gemiddelde wearde is sprongen. Dit wie ús dúdlik, wy laken, mar hoe kinne wy ​​de direksje útlizze wêrom't wy wat diene en it mei 12% minder waard?

Dei fiifentachtich

Oan 'e ein fan 'e tredde moanne realisearre ik dat der ien ding wie wêr't ik hielendal net op rekkene hie: tiid. Alles wêr't ik oer praat nimt tiid.

Dit is myn echte wyklikse kalinder - gewoan in wurkwike, net heul drok. Der is net genôch tiid foar alles. Dêrom moatte jo wer minsken rekrutearje dy't jo sille helpe om de problemen om te gaan.

konklúzje

Dat is net alles. Yn dit ferhaal haw ik net iens krigen hoe't wy mei it produkt wurken en besochten yn te stimmen op 'e algemiene welle, of hoe't wy technyske stipe yntegreare, of hoe't wy oare technyske problemen oplosse. Bygelyks, ik learde hiel tafallich dat op 'e grutste tabellen yn' e databank wy net brûke SEQUENCE. Wy hawwe in selsskreaune funksje nextID, en it wurdt net brûkt yn in transaksje.

D'r wiene in miljoen mear ferlykbere dingen wêr't wy lang oer koene prate. Mar it wichtichste dat noch sein wurde moat is kultuer.

It is kultuer of it ûntbrekken dêrfan dy't liedt ta alle oare problemen. Wy besykje in kultuer op te bouwen dêr't minsken:

• binne net bang foar mislearrings;
• leare fan flaters;
• gearwurkje mei oare teams;
• inisjatyf nimme;
• ferantwurdlikens nimme;
• wolkom it resultaat as doel;
• celebrating súkses.

Mei dit alles sil komme.

Leon Fier op twitter, facebook en oan medium.

D'r binne twa strategyen oangeande legacy: foarkom der foar elke priis mei te wurkjen, of oerwinne de byhearrende swierrichheden moedich. wy c DevOpsConf Wy nimme it twadde paad, feroarjende prosessen en oanpak. Doch mei ús op youtube, ferstjoerlist и telegram, en tegearre sille wy in DevOps-kultuer ymplementearje.

Boarne: www.habr.com