Dit is bekend dat die CTO se bevoegdheid eers die tweede keer getoets word wat hy hierdie rol verrig. Want dit is een ding om vir 'n paar jaar in 'n maatskappy te werk, daarmee saam te ontwikkel en, in dieselfde kulturele konteks, geleidelik meer verantwoordelikheid te ontvang. En dit is nogal iets anders om reguit in die pos van tegniese direkteur by 'n maatskappy te kom met ou bagasie en 'n klomp probleme netjies onder die mat ingevee.

In hierdie sin, die ervaring van Leon Fire, wat hy gedeel het DevOpsConf, nie juis uniek nie, maar vermenigvuldig met sy ervaring en die aantal verskillende rolle wat hy oor die loop van 20 jaar reggekry het, is dit baie nuttig. Onder die snit is ’n chronologie van gebeure oor 90 dae en baie stories wat lekker is om voor te lag wanneer dit met iemand anders gebeur, maar wat nie so lekker is om persoonlik in die gesig te staar nie.

Leon praat baie kleurvol in Russies, so as jy 35-40 minute het, beveel ek aan om die video te kyk. Teksweergawe hieronder om tyd te bespaar.

Die eerste weergawe van die verslag was 'n goed gestruktureerde beskrywing van werk met mense en prosesse, wat nuttige aanbevelings bevat. Maar sy het nie al die verrassings wat langs die pad teëgekom is, oorgedra nie. Daarom het ek die formaat verander en die probleme wat voor my opgeduik het soos 'n jack-in-the-box in die nuwe maatskappy, en metodes om dit op te los in chronologiese volgorde aangebied.

Een maand tevore

Soos baie goeie stories, het hierdie een met alkohol begin. Ons het saam met vriende in 'n kroeg gesit, en soos verwag onder IT-spesialiste, het almal oor hul probleme gehuil. Een van hulle het pas van werk verander en praat oor sy probleme met tegnologie, en met mense, en met die span. Hoe meer ek geluister het, hoe meer het ek besef dat hy my maar moet aanstel, want dit is die tipe probleme wat ek al die laaste 15 jaar oplos. Ek het dit vir hom gesê, en die volgende dag het ons in 'n werksomgewing ontmoet. Die maatskappy is Onderrigstrategieë genoem.

Teaching Strategies is 'n markleier in kurrikulum vir baie jong kinders vanaf geboorte tot drie jaar oud. Die tradisionele “papier”-maatskappy is reeds 40 jaar oud, en die digitale SaaS-weergawe van die platform is 10 jaar oud.Betreklik onlangs het die proses begin om digitale tegnologie by maatskappystandaarde aan te pas. Die "nuwe" weergawe wat in 2017 bekendgestel is en was amper soos die ou een, net dit het slegter gewerk.

Die interessantste ding is dat hierdie maatskappy se verkeer baie voorspelbaar is - van dag tot dag, van jaar tot jaar, kan jy baie duidelik voorspel hoeveel mense sal kom en wanneer. Byvoorbeeld, tussen 13:15 en XNUMX:XNUMX gaan al die kinders in kleuterskole bed toe en onderwysers begin inligting invoer. En dit gebeur elke dag, behalwe naweke, want byna niemand werk oor naweke nie.

As ek 'n bietjie vorentoe kyk, sal ek daarop let dat ek my werk begin het gedurende die tydperk van die hoogste jaarlikse verkeer, wat om verskeie redes interessant is.

Die platform, wat blykbaar net 2 jaar oud was, het 'n eienaardige stapel gehad: ColdFusion & SQL Server vanaf 2008. ColdFusion, as jy nie weet nie, en heel waarskynlik weet jy nie, is 'n onderneming PHP wat in die middel 90's uitgekom het, en sedertdien het ek nog nie eens daarvan gehoor nie. Daar was ook: Ruby, MySQL, PostgreSQL, Java, Go, Python. Maar die hoofmonoliet het op ColdFusion en SQL Server gehardloop.

probleme

Hoe meer ek met maatskappywerknemers gepraat het oor die werk en watter probleme ondervind is, hoe meer het ek besef dat die probleme nie net tegnies van aard was nie. Goed, die tegnologie is oud - en hulle het nie daaraan gewerk nie, maar daar was probleme met die span en met die prosesse, en die maatskappy het dit begin verstaan.

Tradisioneel het hul tegnici in die hoek gesit en 'n soort werk gedoen. Maar meer en meer besigheid het deur die digitale weergawe begin gaan. Daarom, in die laaste jaar voordat ek begin werk het, het nuwes in die maatskappy verskyn: raad van direkteure, CTO, CPO en QA-direkteur. Dit wil sê, die maatskappy het in die tegnologiesektor begin belê.

Spore van 'n swaar nalatenskap was nie net in die stelsels nie. Die maatskappy het nalatenskapprosesse, nalatenskapmense, nalatenskapkultuur gehad. Dit alles moes verander word. Ek het gedink dit sou beslis nie vervelig wees nie, en het besluit om dit te probeer.

Twee dae tevore

Twee dae voordat ek met 'n nuwe werk begin het, het ek by die kantoor aangekom, die laaste papierwerk ingevul, die span ontmoet en ontdek dat die span op daardie stadium met 'n probleem gesukkel het. Dit was dat die gemiddelde bladsylaaityd tot 4 sekondes gespring het, dit wil sê 2 keer.

Te oordeel aan die grafiek, het iets duidelik gebeur, en dit is nie duidelik wat nie. Dit het geblyk dat die probleem netwerkvertraging in die datasentrum was: 5 ms latency in die datasentrum het in 2 s vir gebruikers verander. Ek het nie geweet hoekom dit gebeur het nie, maar dit het in elk geval bekend geword dat die probleem in die datasentrum was.

Eerste dag

Twee dae het verbygegaan en op my eerste dag van werk het ek ontdek dat die probleem nie weg is nie.

Vir twee dae het gebruikers se bladsye gemiddeld binne 4 sekondes gelaai. Ek vra of hulle gevind het wat die probleem is.

- Ja, ons het 'n kaartjie oopgemaak.
- EN?
- Wel, hulle het ons nog nie geantwoord nie.

Toe besef ek dat alles waarvan ek al voorheen vertel is, net 'n klein puntjie van die ysberg was wat ek moes veg.

Daar is 'n goeie aanhaling wat baie goed hierby pas:

"Soms moet jy die organisasie verander om tegnologie te verander."

Maar aangesien ek op die besigste tyd van die jaar begin werk het, moes ek na albei opsies kyk om die probleem op te los: vinnig en langtermyn. En begin met dit wat nou krities is.

Derde dag

Dus, laai duur 4 sekondes, en van 13 tot 15 die grootste pieke.

Op die derde dag gedurende hierdie tydperk het die aflaaispoed soos volg gelyk:

Uit my oogpunt het niks glad gewerk nie. Uit almal anders se oogpunt het dit 'n bietjie stadiger as gewoonlik geloop. Maar dit gebeur net nie so nie - dit is 'n ernstige probleem.

Ek het probeer om die span te oortuig, waarop hulle geantwoord het dat hulle eenvoudig meer bedieners nodig het. Dit is natuurlik 'n oplossing vir die probleem, maar dit is nie altyd die enigste en doeltreffendste een nie. Ek het gevra hoekom daar nie genoeg bedieners was nie, wat was die volume verkeer. Ek het die data geëkstrapoleer en gevind dat ons ongeveer 150 versoeke per sekonde het, wat in beginsel binne redelike perke val.

Maar ons moet nie vergeet dat voordat jy die regte antwoord kry, jy die regte vraag moet vra nie. My volgende vraag was: hoeveel frontend-bedieners het ons? Die antwoord "het my 'n bietjie verstom" - ons het 17 frontend-bedieners gehad!

— Ek is skaam om te vra, gee 150 gedeel deur 17 jou omtrent 8? Sê jy dat elke bediener 8 versoeke per sekonde toelaat, en as daar môre 160 versoeke per sekonde is, sal ons nog 2 bedieners benodig?

Natuurlik het ons nie bykomende bedieners nodig gehad nie. Die oplossing was in die kode self, en op die oppervlak:

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

Daar was 'n funksie getCurrentClass(), want alles op die webwerf werk in die konteks van 'n klas - dit is reg. En vir hierdie een funksie op elke bladsy was daar 200+ versoeke.

Die oplossing op hierdie manier was baie eenvoudig, jy hoef nie eers iets oor te skryf nie: moet net nie weer vir dieselfde inligting vra nie.

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

Ek was baie bly, want ek het besluit dat ek net op die derde dag die hoofprobleem gevind het. Naïef soos ek was, was dit net een van vele probleme.

Maar die oplossing van hierdie eerste probleem het die grafiek baie laer laat val.

Terselfdertyd het ons ander optimaliserings gedoen. Daar was baie dinge in sig wat reggemaak kon word. Byvoorbeeld, op dieselfde derde dag het ek ontdek dat daar tog 'n kas in die stelsel is (ek het eers gedink dat alle versoeke direk vanaf die databasis kom). As ek aan 'n kas dink, dink ek aan standaard Redis of Memcached. Maar ek was die enigste een wat so gedink het, want daardie stelsel het MongoDB en SQL Server vir kas gebruik – dieselfde een waaruit die data pas gelees is.

Dag tien

Die eerste week het ek te doen gehad met probleme wat nou opgelos moes word. Iewers in die tweede week het ek vir die eerste keer na die stand-up gekom om met die span te kommunikeer, om te sien wat gebeur en hoe die hele proses verloop.

Iets interessants is weer ontdek. Die span het bestaan ​​uit: 18 ontwikkelaars; 8 toetsers; 3 bestuurders; 2 argitekte. En hulle het almal aan algemene rituele deelgeneem, dit wil sê, meer as 30 mense het elke oggend na die stand-up gekom en vertel wat hulle gedoen het. Dit is duidelik dat die vergadering nie 5 of 15 minute geneem het nie. Niemand het na iemand geluister nie, want almal werk op verskillende stelsels. In hierdie vorm was 2-3 kaartjies per uur vir 'n versorgingsessie reeds 'n goeie resultaat.

Die eerste ding wat ons gedoen het, was om die span in verskeie produklyne te verdeel. Vir verskillende afdelings en stelsels het ons aparte spanne toegewys, wat ontwikkelaars, toetsers, produkbestuurders en besigheidsontleders ingesluit het.

As gevolg hiervan het ons:

• Vermindering van stand-ups en saamtrekke.
• Vakkennis van die produk.
• 'n Gevoel van eienaarskap. Wanneer mense heeltyd met stelsels gepeuter het, het hulle geweet dat iemand anders heel waarskynlik met hul foute sou moes werk, maar nie hulself nie.
• Samewerking tussen groepe. Nodeloos om te sê, QA het voorheen nie veel met programmeerders gekommunikeer nie, die produk het sy eie ding gedoen, ens. Nou het hulle 'n gemeenskaplike punt van verantwoordelikheid.

Ons het hoofsaaklik op doeltreffendheid, produktiwiteit en kwaliteit gefokus – dit is die probleme wat ons probeer oplos het met die transformasie van die span.

Dag elf

In die proses om die spanstruktuur te verander, het ek ontdek hoe om te tel StoryPunte. 1 SP was gelyk aan een dag, en elke kaartjie bevat SP vir beide ontwikkeling en QA, dit wil sê ten minste 2 SP.

Hoe het ek dit ontdek?

Ons het 'n fout gevind: in een van die verslae, waar die begin- en einddatum van die tydperk waarvoor die verslag benodig word ingevoer word, word die laaste dag nie in ag geneem nie. Dit wil sê, iewers in die versoek was daar nie <= nie, maar bloot <. Daar is vir my gesê dat dit drie Storiepunte is, dit wil sê 3 dae.

Hierna het ons:

• Die Storiepunte-graderingstelsel is hersien. Nou kom regstellings vir geringe foute wat vinnig deur die stelsel deurgegee kan word die gebruiker vinniger uit.
• Ons het verwante kaartjies vir ontwikkeling en toetsing begin saamsmelt. Voorheen was elke kaartjie, elke gogga 'n geslote ekosisteem, nie gekoppel aan enigiets anders nie. Die verandering van drie knoppies op een bladsy kon drie verskillende kaartjies gewees het met drie verskillende QA-prosesse in plaas van een outomatiese toets per bladsy.
• Ons het met ontwikkelaars begin werk aan 'n benadering tot die skatting van arbeidskoste. Drie dae om een ​​knoppie te verander is nie snaaks nie.

Dag twintigste

Iewers in die middel van die eerste maand het die situasie 'n bietjie gestabiliseer, ek het uitgepluis wat basies aan die gebeur is, en het reeds in die toekoms begin kyk en oor langtermynoplossings begin dink.

Langtermyn doelwitte:

• Bestuurde platform. Honderde versoeke op elke bladsy is nie ernstig nie.
• Voorspelbare tendense. Daar was periodieke verkeerspieke wat met die eerste oogopslag nie met ander maatstawwe ooreenstem nie – ons moes verstaan ​​hoekom dit gebeur het en leer om te voorspel.
• Platform uitbreiding. Die besigheid groei voortdurend, meer en meer gebruikers kom, en die verkeer neem toe.

In die verlede is dikwels gesê: “Kom ons herskryf alles in [taal/raamwerk], alles sal beter werk!”

In die meeste gevalle werk dit nie, dit is goed as die herskryf enigsins werk. Daarom moes ons 'n padkaart skep - 'n spesifieke strategie wat stap vir stap illustreer hoe besigheidsdoelwitte bereik sal word (wat ons sal doen en hoekom), wat:

• weerspieël die missie en doelwitte van die projek;
• prioritiseer hoofdoelwitte;
• bevat 'n skedule om dit te bereik.

Voor dit het niemand met die span gepraat oor die doel van enige veranderinge wat gemaak word nie. Dit vereis die regte suksesmaatstawwe. Vir die eerste keer in die maatskappy se geskiedenis het ons KPI's vir die tegniese groep opgestel, en hierdie aanwysers was gekoppel aan organisatoriese.

Dit wil sê, organisatoriese KPI's word deur spanne ondersteun, en span-KPI's word deur individuele KPI's ondersteun. Andersins, as tegnologiese KPI's nie saamval met organisatoriese nie, dan trek almal die kombers oor hulself.

Byvoorbeeld, een van die organisatoriese KPI's is om markaandeel deur nuwe produkte te vergroot.

Hoe kan jy die doelwit ondersteun om meer nuwe produkte te hê?

• Eerstens wil ons meer tyd bestee aan die ontwikkeling van nuwe produkte in plaas daarvan om defekte reg te stel. Dit is 'n logiese oplossing wat maklik is om te meet.
• Tweedens wil ons 'n toename in transaksievolume ondersteun, want hoe groter die markaandeel, hoe meer gebruikers en, dienooreenkomstig, hoe meer verkeer.

Dan sal individuele KPI's wat binne die groep uitgevoer kan word, byvoorbeeld op die plek wees waar die vernaamste gebreke vandaan kom. As jy spesifiek op hierdie afdeling fokus, kan jy seker maak dat daar baie minder defekte is, en dan sal die tyd vir die ontwikkeling van nuwe produkte en weer vir die ondersteuning van organisatoriese KPI's toeneem.

Elke besluit, insluitend die herskryf van kode, moet dus die spesifieke doelwitte ondersteun wat die maatskappy vir ons gestel het (organisasiegroei, nuwe kenmerke, werwing).

Tydens hierdie proses het 'n interessante ding aan die lig gekom, wat nie net nuus vir tegnologieë geword het nie, maar in die algemeen in die maatskappy: alle kaartjies moet op ten minste een KPI gefokus wees. Dit wil sê, as 'n produk sê dat dit 'n nuwe kenmerk wil maak, moet die eerste vraag gevra word: "Watter KPI ondersteun hierdie kenmerk?" Indien nie, dan jammer - dit lyk na 'n onnodige kenmerk.

Dag dertig

Aan die einde van die maand het ek nog 'n nuanse ontdek: niemand in my Ops-span het nog ooit die kontrakte gesien wat ons met kliënte aangaan nie. Jy kan vra hoekom jy kontakte moet sien.

• Eerstens omdat SLA's in kontrakte gespesifiseer word.
• Tweedens, SLA's verskil almal. Elke kliënt het met sy eie vereistes gekom, en die verkoopsafdeling het geteken sonder om te kyk.

Nog 'n interessante nuanse is dat die kontrak met een van die grootste kliënte bepaal dat alle sagteware-weergawes wat deur die platform ondersteun word, n-1 moet wees, dit wil sê nie die nuutste weergawe nie, maar die voorlaaste een.

Dit is duidelik hoe ver ons van n-1 was as die platform gebaseer was op ColdFusion en SQL Server 2008, wat glad nie meer in Julie ondersteun is nie.

Dag vyf en veertig

Omstreeks die middel van die tweede maand het ek genoeg tyd gehad om te gaan sit en doen waardestroomkarteer heeltemal vir die hele proses. Dit is die nodige stappe wat geneem moet word, van die skep van 'n produk tot die lewering daarvan aan die verbruiker, en dit moet in soveel detail as moontlik beskryf word.

Jy breek die proses in klein stukkies op en sien wat te veel tyd neem, wat geoptimaliseer, verbeter kan word, ens. Byvoorbeeld, hoe lank neem dit vir 'n produkversoek om deur versorging te gaan, wanneer bereik dit 'n kaartjie wat 'n ontwikkelaar kan neem, QA, ens. So jy kyk na elke individuele stap in detail en dink oor wat geoptimaliseer kan word.

Toe ek dit doen, het twee dinge my oog gevang:

• hoë persentasie kaartjies wat van QA aan ontwikkelaars teruggestuur is;
• trek versoek resensies het te lank geneem.

Die probleem was dat dit gevolgtrekkings was soos: Dit lyk asof dit baie tyd neem, maar ons is nie seker hoe lank nie.

"Jy kan nie verbeter wat jy nie kan meet nie."

Hoe om te regverdig hoe ernstig die probleem is? Mors dit dae of ure?

Om dit te meet, het ons 'n paar stappe by die Jira-proses gevoeg: "gereed vir dev" en "gereed vir QA" om te meet hoe lank elke kaartjie wag en hoeveel keer dit na 'n sekere stap terugkeer.

Ons het ook "in review" bygevoeg om te weet hoeveel kaartjies gemiddeld vir hersiening is, en hieruit kan jy begin dans. Ons het stelselstatistieke gehad, nou het ons nuwe statistieke bygevoeg en begin meet:

• Proses doeltreffendheid: prestasie en beplan/afgelewer.
• Proses kwaliteit: aantal defekte, defekte van QA.

Dit help regtig om te verstaan ​​wat goed gaan en wat nie goed gaan nie.

Dag vyftigste

Dit is alles natuurlik goed en interessant, maar teen die einde van die tweede maand het iets gebeur wat in beginsel voorspelbaar was, hoewel ek nie so 'n skaal verwag het nie. Mense het begin vertrek omdat die topbestuur verander het. Nuwe mense het in die bestuur gekom en alles begin verander, en die oues het opgehou. En gewoonlik in 'n geselskap wat etlike jare oud is, is almal vriende en almal ken mekaar.

Dit was verwag, maar die omvang van die afleggings was onverwags. Byvoorbeeld, in een week het twee spanleiers gelyktydig hul bedankings uit vrye wil ingedien. Daarom moes ek nie net van ander probleme vergeet nie, maar fokus op die skep van 'n span. Dit is 'n lang en moeilike probleem om op te los, maar dit moes hanteer word omdat ek die mense wat oorgebly het (of die meeste van hulle) wou red. Dit was nodig om op een of ander manier te reageer op die feit dat mense weg is om moreel in die span te behou.

In teorie is dit goed: 'n nuwe persoon kom in wat volledige carte blanche het, wat die span se vaardighede kan evalueer en personeel kan vervang. Om die waarheid te sê, jy kan om soveel redes nie net nuwe mense inbring nie. Jy het altyd balans nodig.

• Oud en nuut. Ons moet ou mense aanhou wat kan verander en die missie ondersteun. Maar terselfdertyd moet ons nuwe bloed inbring, ons sal 'n bietjie later daaroor praat.
• Ervaring. Ek het baie met goeie juniors gepraat wat gretig was en saam met ons wou werk. Maar ek kon hulle nie aanvat nie, want daar was nie genoeg seniors om die juniors te ondersteun en as mentors vir hulle op te tree nie. Dit was nodig om eers die top te werf en dan eers die jeug.
• Wortel en stok.

Ek het nie ’n goeie antwoord op die vraag wat die regte balans is, hoe om dit te handhaaf, hoeveel mense om te hou en hoeveel om te druk nie. Dit is 'n suiwer individuele proses.

Dag een en vyftig

Ek het noukeurig na die span begin kyk om te verstaan ​​wie ek het, en weereens onthou ek:

“Die meeste probleme is menseprobleme.”

Ek het gevind dat die span as sodanig - beide Dev en Ops - drie groot probleme het:

• Tevredenheid met die huidige stand van sake.
• Gebrek aan verantwoordelikheid - omdat niemand ooit die resultate van die kunstenaars se werk gebring het om die besigheid te beïnvloed nie.
• Vrees vir verandering.

Verandering neem jou altyd uit jou gemaksone, en hoe jonger mense is, hoe meer hou hulle nie van verandering nie, want hulle verstaan ​​nie hoekom nie en hulle verstaan ​​nie hoe nie. Die mees algemene antwoord wat ek gehoor het, is: "Ons het dit nog nooit gedoen nie." Boonop het dit die punt van volkome absurditeit bereik – die geringste veranderinge kon nie plaasvind sonder dat iemand verontwaardig was nie. En maak nie saak hoeveel die veranderinge hul werk beïnvloed het nie, mense het gesê: “Nee, hoekom? Dit sal nie werk nie.”

Maar jy kan nie beter word sonder om iets te verander nie.

Ek het 'n absoluut absurde gesprek met 'n werknemer gehad, ek het vir hom my idees vir optimalisering vertel, waarop hy vir my gesê het:
- O, jy het nie gesien wat ons verlede jaar gehad het nie!
- So wat?
“Dit is nou baie beter as wat dit was.”
- So, dit kan nie beter gaan nie?
- Vir wat?

Goeie vraag - hoekom? Dit is asof dit nou beter is as wat dit was, dan is alles goed genoeg. Dit lei tot 'n gebrek aan verantwoordelikheid, wat in beginsel absoluut normaal is. Soos ek gesê het, die tegniese groep was bietjie op die kantlyn. Die maatskappy het geglo dat hulle moet bestaan, maar niemand het ooit die standaarde gestel nie. Tegniese ondersteuning het nooit die SLA gesien nie, so dit was redelik "aanvaarbaar" vir die groep (en dit het my die meeste opgeval):

• 12 sekondes laai;
• 5-10 minute stilstand elke vrystelling;
• Die oplos van kritieke probleme neem dae en weke;
• gebrek aan dienspersoneel 24x7 / op roep.

Niemand het nog ooit probeer vra hoekom doen ons dit nie beter nie, en niemand het ooit besef dat dit nie so hoef te wees nie.

As 'n bonus was daar nog een probleem: gebrek aan ervaring. Die seniors het vertrek, en die oorblywende jongspan het onder die vorige regime grootgeword en is daardeur vergiftig.

Boonop was mense ook bang om te misluk en onbevoeg voor te kom. Dit word uitgedruk in die feit dat, eerstens, hulle onder geen omstandighede om hulp gevra nie. Hoeveel keer het ons as 'n groep en individueel gepraat, en ek het gesê: "Vra 'n vraag as jy nie weet hoe om iets te doen nie." Ek is vol vertroue in myself en weet dat ek enige probleem kan oplos, maar dit sal tyd neem. Daarom, as ek iemand kan vra wat weet hoe om dit binne 10 minute op te los, sal ek vra. Hoe minder ondervinding jy het, hoe banger is jy om te vra omdat jy dink jy sal as onbevoeg beskou word.

Hierdie vrees om vrae te vra manifesteer hom op interessante maniere. Byvoorbeeld, jy vra: "Hoe gaan dit met hierdie taak?" - "'n Paar uur oor, ek is reeds klaar." Die volgende dag vra jy weer, jy kry die antwoord dat alles reg is, maar daar was een probleem, dit sal beslis klaar wees aan die einde van die dag. Nog 'n dag gaan verby, en totdat jy teen die muur vasgepen word en gedwing word om met iemand te praat, gaan dit voort. 'n Persoon wil self 'n probleem oplos; hy glo dat as hy dit nie self oplos nie, dit 'n groot mislukking sal wees.

Dis hoekom die ontwikkelaars het die skattings opgeblaas. Dit was daardie selfde staaltjie, toe hulle 'n sekere taak bespreek het, het hulle my so 'n figuur gegee dat ek baie verbaas was. Waaraan ek meegedeel is dat in die ontwikkelaar se skattings, die ontwikkelaar die tyd insluit wat die kaartjie van QA teruggestuur sal word, want hulle sal foute daar vind, en die tyd wat die PR sal neem, en die tyd terwyl die mense wat moet hersien dit sal besig wees - dit wil sê alles, wat ook al moontlik is.

Tweedens, mense wat bang is om onbevoeg voor te kom oorontleed. Wanneer jy sê wat presies gedoen moet word, begin dit: “Nee, wat as ons hier daaroor dink?” In hierdie sin is ons maatskappy nie uniek nie; dit is 'n standaardprobleem vir jongmense.

In reaksie hierop het ek die volgende praktyke ingestel:

• Reël 30 minute. As jy nie die probleem binne 'n halfuur kan oplos nie, vra iemand om te help. Dit werk met verskillende grade van sukses, want mense vra steeds nie, maar die proses het ten minste begin.
• Elimineer alles behalwe die essensie, in die skatting van die sperdatum vir die voltooiing van 'n taak, dit wil sê, oorweeg slegs hoe lank dit sal neem om die kode te skryf.
• Lewenslange leer vir diegene wat oorontleed. Dit is net konstante werk met mense.

Dag sestigste

Terwyl ek dit alles gedoen het, was dit tyd om die begroting uit te vind. Ek het natuurlik baie interessante dinge gevind waar ons ons geld spandeer het. Ons het byvoorbeeld 'n hele rek in 'n aparte datasentrum gehad met een FTP-bediener, wat deur een kliënt gebruik is. Dit het geblyk dat "... ons het getrek, maar hy het so gebly, ons het hom nie verander nie." Dit was 2 jaar gelede.

Van besondere belang was die rekening vir wolkdienste. Ek glo die hoofrede vir die hoë wolkrekening is die ontwikkelaars wat vir die eerste keer in hul lewe onbeperkte toegang tot bedieners het. Hulle hoef nie te vra: "Gee my asseblief 'n toetsbediener nie," hulle kan dit self neem. Boonop wil ontwikkelaars altyd so 'n oulike stelsel bou dat Facebook en Netflix jaloers sal wees.

Maar die ontwikkelaars het nie ondervinding in die aankoop van bedieners en die vaardigheid om die vereiste grootte van bedieners te bepaal nie, want hulle het dit nie voorheen nodig gehad nie. En hulle verstaan ​​gewoonlik nie heeltemal die verskil tussen skaalbaarheid en werkverrigting nie.

Voorraadresultate:

• Ons het dieselfde datasentrum verlaat.
• Ons het die kontrak met 3 logdienste beëindig. Omdat ons 5 van hulle gehad het - elke ontwikkelaar wat met iets begin speel het, het 'n nuwe een geneem.
• 7 AWS-stelsels is gesluit. Weereens, niemand het die dooie projekte gestop nie; hulle het almal aangehou werk.
• Sagtewarekoste met 6 keer verlaag.

Dag vyf en sewentig

Die tyd het verbygegaan, en oor twee en 'n half maande moes ek met die direksie vergader. Ons direksie is nie beter of slegter as ander nie; soos alle direksies wil dit alles weet. Mense belê geld en wil verstaan ​​hoeveel dit wat ons doen by die vasgestelde KPI's inpas.

Die raad van direkteure ontvang elke maand baie inligting: die aantal gebruikers, hul groei, watter dienste hulle gebruik en hoe, prestasie en produktiwiteit, en laastens, gemiddelde bladsylaaispoed.

Die enigste probleem is dat ek glo dat die gemiddelde pure boosheid is. Maar dit is baie moeilik om dit aan die direksie te verduidelik. Hulle is gewoond daaraan om met saamgestelde getalle te werk, en nie byvoorbeeld die verspreiding van laaitye per sekonde nie.

Daar was 'n paar interessante punte in hierdie verband. Ek het byvoorbeeld gesê dat ons verkeer tussen aparte webbedieners moet verdeel, afhangende van die tipe inhoud.

Dit wil sê, ColdFusion gaan deur Jetty en nginx en begin die bladsye. En beelde, JS en CSS gaan deur 'n aparte nginx met hul eie konfigurasies. Dit is 'n redelik standaard praktyk waarvan ek praat Ek skryf 'n paar jaar gelede. Gevolglik laai prente baie vinniger, en... die gemiddelde aflaaispoed het met 200 ms toegeneem.

Dit het gebeur omdat die grafiek gebou is op grond van die data wat saam met Jetty kom. Dit wil sê, vinnige inhoud is nie by die berekening ingesluit nie - die gemiddelde waarde het gespring. Dit was vir ons duidelik, ons het gelag, maar hoe kan ons aan die direksie verduidelik hoekom ons iets gedoen het en dinge met 12% vererger het?

Dag vyf en tagtig

Aan die einde van die derde maand het ek besef daar is een ding waarop ek glad nie gereken het nie: tyd. Alles waaroor ek gepraat het, neem tyd.

Hierdie is my regte weeklikse kalender – net 'n werksweek, nie baie besig nie. Daar is nie genoeg tyd vir alles nie. Daarom moet jy weer mense werf wat jou sal help om die probleme die hoof te bied.

Gevolgtrekking

Dit is nie al nie. In hierdie storie het ek nie eers uitgekom by hoe ons met die produk gewerk het en probeer het om in te skakel op die algemene golf, of hoe ons tegniese ondersteuning geïntegreer het, of hoe ons ander tegniese probleme opgelos het nie. Ek het byvoorbeeld heel toevallig geleer dat ons nie op die grootste tabelle in die databasis gebruik nie SEQUENCE. Ons het 'n selfgeskrewe funksie nextID, en dit word nie in 'n transaksie gebruik nie.

Daar was nog 'n miljoen soortgelyke dinge waaroor ons lank kon praat. Maar die belangrikste ding wat nog gesê moet word, is kultuur.

Dit is kultuur of die gebrek daaraan wat tot alle ander probleme lei. Ons probeer 'n kultuur bou waar mense:

• is nie bang vir mislukkings nie;
• leer uit foute;
• met ander spanne saam te werk;
• neem inisiatief;
• neem verantwoordelikheid;
• verwelkom die resultaat as 'n doelwit;
• sukses te vier.

Hiermee sal alles anders kom.

Leon Vuur op twitter, Facebook en medium.

Daar is twee strategieë met betrekking tot nalatenskap: vermy om ten alle koste daarmee te werk, of oorkom die gepaardgaande probleme dapper. ons c DevOpsConf Ons neem die tweede pad, verander prosesse en benaderings. Sluit by ons aan YouTube, poslys и telegram, en saam sal ons 'n DevOps-kultuur implementeer.

Bron: will.com