Det er kendt, at CTO's kompetence kun testes anden gang, han udfører denne rolle. For det er én ting at arbejde i en virksomhed i flere år, udvikle sig med den og, i den samme kulturelle kontekst, gradvist få mere ansvar. Og det er noget helt andet at komme direkte ind i stillingen som teknisk direktør i en virksomhed med ældre bagage og en masse problemer fejet pænt ind under gulvtæppet.

I denne forstand oplevelsen af ​​Leon Fire, som han delte om DevOpsConf, ikke helt unik, men ganget med hans erfaring og antallet af forskellige roller, som han nåede at prøve i løbet af 20 år, er det meget nyttigt. Under snittet er en kronologi over begivenheder over 90 dage og en masse historier, der er sjove at grine af, når de sker for en anden, men som ikke er så sjove at stå i ansigtet med personligt.

Leon taler meget farverigt på russisk, så hvis du har 35-40 minutter, anbefaler jeg at se videoen. Tekstversion for at spare tid nedenfor.

Den første version af rapporten var en velstruktureret beskrivelse af arbejdet med mennesker og processer, indeholdende nyttige anbefalinger. Men hun formidlet ikke alle de overraskelser, der blev mødt undervejs. Derfor ændrede jeg formatet og præsenterede de problemer, der dukkede op foran mig som en jack-in-the-box i det nye firma, og metoder til at løse dem i kronologisk rækkefølge.

En måned før

Som mange gode historier startede denne med alkohol. Vi sad med venner på en bar, og som forventet blandt it-specialister græd alle over deres problemer. En af dem havde lige skiftet job og talte om sine problemer med teknologi og med mennesker og med teamet. Jo mere jeg lyttede, jo mere indså jeg, at han bare skulle ansætte mig, for det er den type problemer, jeg har løst i de sidste 15 år. Det fortalte jeg ham, og dagen efter mødtes vi i et arbejdsmiljø. Virksomheden hed Teaching Strategies.

Teaching Strategies er markedsleder inden for læseplaner for helt små børn fra fødslen til tre år. Den traditionelle "papir"-virksomhed er allerede 40 år gammel, og den digitale SaaS-version af platformen er 10 år. Relativt for nylig begyndte processen med at tilpasse digital teknologi til virksomhedens standarder. Den "nye" version blev lanceret i 2017 og var næsten som den gamle, bare den fungerede dårligere.

Det mest interessante er, at denne virksomheds trafik er meget forudsigelig - fra dag til dag, fra år til år kan du meget tydeligt forudsige, hvor mange mennesker der kommer og hvornår. For eksempel mellem kl. 13 og 15 går alle børn i børnehaverne i seng, og lærerne begynder at indtaste oplysninger. Og det sker hver dag, undtagen weekender, for næsten ingen arbejder i weekenden.

Ser jeg lidt fremad, vil jeg bemærke, at jeg startede mit arbejde i perioden med den højeste årlige trafik, hvilket er interessant af forskellige årsager.

Platformen, der så ud til at være kun 2 år gammel, havde en ejendommelig stak: ColdFusion & SQL Server fra 2008. ColdFusion, hvis du ikke ved det, og højst sandsynligt ikke ved det, er en enterprise PHP, der udkom i midten af ​​90'erne, og siden da har jeg ikke engang hørt om det. Der var også: Ruby, MySQL, PostgreSQL, Java, Go, Python. Men hovedmonolitten kørte på ColdFusion og SQL Server.

Problemer

Jo mere jeg talte med virksomhedens medarbejdere om arbejdet, og hvilke problemer man stødte på, jo mere indså jeg, at problemerne ikke kun var af teknisk karakter. Okay, teknologien er gammel - og de arbejdede ikke på den, men der var problemer med holdet og med processerne, og virksomheden begyndte at forstå dette.

Traditionelt sad deres teknikere i hjørnet og lavede en eller anden form for arbejde. Men flere og flere virksomheder begyndte at gå gennem den digitale version. Derfor dukkede nye op i virksomheden i det sidste år inden jeg begyndte at arbejde: bestyrelse, CTO, CPO og QA-direktør. Det vil sige, at virksomheden begyndte at investere i teknologisektoren.

Spor af en tung arv var ikke kun i systemerne. Virksomheden havde legacy processer, legacy people, legacy kultur. Alt dette skulle ændres. Jeg tænkte, at det bestemt ikke ville være kedeligt, og besluttede at prøve det.

to dage før

To dage før jeg startede på et nyt job, ankom jeg til kontoret, udfyldte de sidste papirer, mødte holdet og opdagede, at holdet kæmpede med et problem på det tidspunkt. Det var, at den gennemsnitlige sideindlæsningstid sprang til 4 sekunder, det vil sige 2 gange.

At dømme efter grafen skete der tydeligvis noget, og det er ikke klart hvad. Det viste sig, at problemet var netværksforsinkelse i datacentret: 5 ms latency i datacentret blev til 2 s for brugerne. Jeg vidste ikke, hvorfor det skete, men under alle omstændigheder blev det kendt, at problemet var i datacentret.

Dag ét

To dage gik, og på min første arbejdsdag opdagede jeg, at problemet ikke var forsvundet.

I to dage blev brugernes sider i gennemsnit indlæst på 4 sekunder. Jeg spørger, om de har fundet, hvad problemet er.

- Ja, vi åbnede en billet.
- OG?
- Jamen, de har ikke svaret os endnu.

Så gik det op for mig, at alt det, jeg havde fået at vide om før, kun var et lille spids af isbjerget, som jeg skulle kæmpe.

Der er et godt citat, der passer meget godt til dette:

"Nogle gange skal du ændre organisationen for at ændre teknologi."

Men da jeg begyndte at arbejde på den travleste tid af året, var jeg nødt til at se på begge muligheder for at løse problemet: både hurtig og langsigtet. Og start med det, der er kritisk lige nu.

Dag tre

Så lastning varer 4 sekunder, og fra 13 til 15 de største toppe.

På den tredje dag i denne periode så downloadhastigheden sådan ud:

Fra mit synspunkt virkede intet overhovedet. Fra alle andres synspunkt kørte det lidt langsommere end normalt. Men sådan sker det bare ikke - det er et alvorligt problem.

Jeg forsøgte at overbevise holdet, hvortil de svarede, at de simpelthen havde brug for flere servere. Dette er selvfølgelig en løsning på problemet, men det er ikke altid den eneste og mest effektive. Jeg spurgte, hvorfor der ikke var nok servere, hvad var mængden af ​​trafik. Jeg ekstrapolerede dataene og fandt ud af, at vi har cirka 150 anmodninger i sekundet, hvilket i princippet falder inden for rimelige grænser.

Men vi må ikke glemme, at før du får det rigtige svar, skal du stille det rigtige spørgsmål. Mit næste spørgsmål var: hvor mange frontend-servere har vi? Svaret "forvirrede mig lidt" - vi havde 17 frontend-servere!

— Jeg er flov over at spørge, men 150 divideret med 17 giver cirka 8? Siger du, at hver server tillader 8 anmodninger i sekundet, og hvis der i morgen er 160 forespørgsler i sekundet, skal vi bruge 2 servere mere?

Selvfølgelig havde vi ikke brug for yderligere servere. Løsningen lå i selve koden og på overfladen:

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

Der var en funktion getCurrentClass(), fordi alt på siden fungerer i sammenhæng med en klasse - det er rigtigt. Og for denne ene funktion på hver side var der 200+ anmodninger.

Løsningen på denne måde var meget enkel, du behøvede ikke engang at omskrive noget: bare ikke bede om de samme oplysninger igen.

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

Jeg var meget glad, fordi jeg besluttede, at jeg på den tredje dag havde fundet hovedproblemet. Naiv som jeg var, var dette blot et af mange problemer.

Men ved at løse dette første problem faldt grafen meget lavere.

Samtidig var vi i gang med andre optimeringer. Der var mange ting i sigte, der kunne ordnes. For eksempel opdagede jeg samme tredje dag, at der trods alt var en cache i systemet (først troede jeg, at alle anmodninger kom direkte fra databasen). Når jeg tænker på en cache, tænker jeg på standard Redis eller Memcached. Men jeg var den eneste, der mente det, for det system brugte MongoDB og SQL Server til caching - det samme som dataene lige blev læst fra.

Dag ti

Den første uge beskæftigede jeg mig med problemer, der skulle løses lige nu. Et sted i den anden uge kom jeg til stand-up for første gang for at kommunikere med holdet, for at se, hvad der skete, og hvordan hele processen forløb.

Noget interessant blev opdaget igen. Holdet bestod af: 18 udviklere; 8 testere; 3 ledere; 2 arkitekter. Og de deltog alle i fælles ritualer, det vil sige, at mere end 30 mennesker kom til stand-up hver morgen og fortalte, hvad de lavede. Det er klart, at mødet ikke tog 5 eller 15 minutter. Ingen lyttede til nogen, fordi alle arbejder på forskellige systemer. I denne form var 2-3 billetter i timen til en grooming session allerede et godt resultat.

Det første, vi gjorde, var at opdele holdet i flere produktlinjer. Til forskellige sektioner og systemer tildelte vi separate teams, som omfattede udviklere, testere, produktchefer og forretningsanalytikere.

Som et resultat fik vi:

• Reduktion af stand-ups og stævner.
• Fagkendskab til produktet.
• En følelse af ejerskab. Når folk plejede at pille ved systemer hele tiden, vidste de, at en anden højst sandsynligt skulle arbejde med deres fejl, men ikke dem selv.
• Samarbejde mellem grupper. Det er overflødigt at sige, at QA ikke kommunikerede meget med programmører før, produktet gjorde sine egne ting osv. Nu har de et fælles ansvar.

Vi fokuserede hovedsageligt på effektivitet, produktivitet og kvalitet - det er de problemer, vi forsøgte at løse med transformationen af ​​teamet.

Dag elleve

I processen med at ændre teamstrukturen opdagede jeg, hvordan man tæller StoryPoints. 1 SP var lig med en dag, og hver billet indeholdt SP for både udvikling og QA, det vil sige mindst 2 SP.

Hvordan opdagede jeg dette?

Vi fandt en fejl: I en af ​​rapporterne, hvor start- og slutdatoen for den periode, hvor rapporten er nødvendig, er indtastet, er den sidste dag ikke taget i betragtning. Det vil sige, et sted i anmodningen var der ikke <=, men blot <. Jeg fik at vide, at dette er tre Story Points, dvs 3 dage.

Herefter:

• Story Points-vurderingssystemet er blevet revideret. Nu når rettelser til mindre fejl, der hurtigt kan sendes gennem systemet, brugeren hurtigere.
• Vi begyndte at fusionere relaterede billetter til udvikling og test. Tidligere var hver billet, hver bug et lukket økosystem, ikke bundet til noget andet. At ændre tre knapper på én side kunne have været tre forskellige billetter med tre forskellige QA-processer i stedet for én automatiseret test pr. side.
• Vi begyndte at arbejde med udviklere om en tilgang til at estimere lønomkostninger. Tre dage til at skifte en knap er ikke sjovt.

Dag tyvende

Et sted midt i den første måned stabiliserede situationen sig lidt, jeg fandt ud af, hvad der i bund og grund skete, og begyndte allerede at se ind i fremtiden og tænke på langsigtede løsninger.

Langsigtede mål:

• Administreret platform. Hundredvis af anmodninger på hver side er ikke seriøse.
• Forudsigelige tendenser. Der var periodiske trafiktoppe, som ved første øjekast ikke korrelerede med andre målinger - vi var nødt til at forstå, hvorfor dette skete, og lære at forudsige.
• Udvidelse af platform. Forretningen vokser konstant, flere og flere brugere kommer, og trafikken er stigende.

Tidligere sagde man ofte: "Lad os omskrive alt i [sprog/ramme], alt vil fungere bedre!"

I de fleste tilfælde virker dette ikke, det er godt, hvis omskrivningen overhovedet virker. Derfor var vi nødt til at lave en køreplan - en specifik strategi, der trin for trin illustrerer, hvordan forretningsmål vil blive opnået (hvad vi vil gøre og hvorfor), som:

• afspejler projektets mission og mål;
• prioriterer hovedmål;
• indeholder en tidsplan for at nå dem.

Inden dette havde ingen talt med holdet om formålet med eventuelle ændringer. Dette kræver de rigtige succesmålinger. For første gang i virksomhedens historie satte vi KPI'er for den tekniske gruppe, og disse indikatorer var knyttet til organisatoriske.

Det vil sige, at organisatoriske KPI'er understøttes af teams, og team-KPI'er understøttes af individuelle KPI'er. Ellers, hvis teknologiske KPI'er ikke falder sammen med organisatoriske, så trækker alle tæppet på sig selv.

For eksempel er en af ​​de organisatoriske KPI'er at øge markedsandele gennem nye produkter.

Hvordan kan du understøtte målet om at få flere nye produkter?

• For det første vil vi bruge mere tid på at udvikle nye produkter i stedet for at rette fejl. Dette er en logisk løsning, som er nem at måle.
• For det andet ønsker vi at støtte en stigning i transaktionsvolumen, fordi jo større markedsandel, jo flere brugere og dermed mere trafik.

Så vil individuelle KPI'er, der kan eksekveres inden for gruppen, for eksempel være det sted, hvor hovedfejlene kommer fra. Hvis du fokuserer specifikt på dette afsnit, kan du sikre dig, at der er meget færre defekter, og så vil tiden til at udvikle nye produkter og igen til at understøtte organisatoriske KPI'er stige.

Enhver beslutning, herunder omskrivning af kode, skal således understøtte de specifikke mål, som virksomheden har sat for os (organisationsvækst, nye funktioner, rekruttering).

I løbet af denne proces kom der en interessant ting frem, som blev en nyhed ikke kun for teknikere, men generelt i virksomheden: alle billetter skal være fokuseret på mindst én KPI. Det vil sige, at hvis et produkt siger, at det vil lave en ny funktion, bør det første spørgsmål stilles: "Hvilken KPI understøtter denne funktion?" Hvis ikke, så undskyld - det virker som en unødvendig funktion.

Dag tredive

I slutningen af ​​måneden opdagede jeg en anden nuance: Ingen på mit Ops-team har nogensinde set de kontrakter, vi indgår med kunder. Du kan spørge, hvorfor du har brug for at se kontakter.

• For det første fordi SLA'er er specificeret i kontrakter.
• For det andet er SLA'er alle forskellige. Hver kunde kom med sine egne krav, og salgsafdelingen skrev under uden at kigge.

En anden interessant nuance er, at kontrakten med en af ​​de største kunder siger, at alle softwareversioner, der understøttes af platformen, skal være n-1, altså ikke den seneste version, men den næstsidste.

Det er tydeligt, hvor langt vi var fra n-1, hvis platformen var baseret på ColdFusion og SQL Server 2008, som slet ikke længere blev understøttet i juli.

Dag femogfyrre

Omkring midten af ​​den anden måned havde jeg nok tid til at sætte mig ned og gøre værdistrømkortlægning fuldstændig for hele processen. Det er de nødvendige skridt, der skal tages, fra at skabe et produkt til at levere det til forbrugeren, og de skal beskrives så detaljeret som muligt.

Du bryder processen op i små stykker og ser, hvad der tager for meget tid, hvad der kan optimeres, forbedres mv. For eksempel hvor lang tid tager det for en produktanmodning at gennemgå grooming, hvornår når den en billet, som en udvikler kan tage, QA osv. Så du ser på hvert enkelt trin i detaljer og tænker over, hvad der kan optimeres.

Da jeg gjorde dette, fangede to ting mig:

• høj procentdel af billetter returneret fra QA tilbage til udviklere;
• pull-anmodningsgennemgange tog for lang tid.

Problemet var, at det var konklusioner som: Det ser ud til at tage meget tid, men vi er ikke sikre på, hvor lang tid.

"Du kan ikke forbedre det, du ikke kan måle."

Hvordan begrunder man, hvor alvorligt problemet er? Spilder det dage eller timer?

For at måle dette har vi tilføjet et par trin til Jira-processen: "klar til dev" og "klar til QA" for at måle, hvor længe hver billet venter, og hvor mange gange den vender tilbage til et bestemt trin.

Vi tilføjede også "i anmeldelse" for at vide, hvor mange billetter der i gennemsnit er til anmeldelse, og herfra kan du begynde at danse. Vi havde systemmålinger, nu tilføjede vi nye målinger og begyndte at måle:

• Proceseffektivitet: ydelse og planlagt/leveret.
• Proces kvalitet: antal defekter, mangler fra QA.

Det hjælper virkelig at forstå, hvad der går godt, og hvad der ikke går godt.

Den halvtredsindstyvende dag

Det hele er selvfølgelig godt og interessant, men mod slutningen af ​​anden måned skete der noget, som i princippet var forudsigeligt, selvom jeg ikke havde forventet sådan en skala. Folk begyndte at gå, fordi topledelsen havde ændret sig. Nye mennesker kom til ledelsen og begyndte at ændre alt, og de gamle sagde op. Og som regel i en virksomhed, der er flere år gammel, er alle venner, og alle kender hinanden.

Dette var forventet, men omfanget af fyringerne var uventet. For eksempel indgav to teamledere på én uge samtidig deres opsigelse af egen fri vilje. Derfor måtte jeg ikke kun glemme andre problemer, men fokusere på skabe et hold. Dette er et langt og vanskeligt problem at løse, men det skulle håndteres, fordi jeg ville redde de mennesker, der blev tilbage (eller de fleste af dem). Det var nødvendigt på en eller anden måde at reagere på, at folk gik for at bevare moralen i holdet.

I teorien er dette godt: Der kommer en ny person ind, som har fuldstændig carte blanche, som kan evaluere holdets færdigheder og erstatte personale. Faktisk kan du ikke bare hente nye mennesker ind af så mange grunde. Balance er altid nødvendig.

• Gammelt og nyt. Vi skal beholde gamle mennesker, der kan ændre og støtte missionen. Men samtidig skal vi have nyt blod ind, det taler vi om lidt senere.
• Erfaring. Jeg talte meget med gode juniorer, som var ivrige og gerne ville arbejde sammen med os. Men jeg kunne ikke tage dem på, fordi der ikke var seniorer nok til at støtte juniorerne og fungere som mentorer for dem. Det var nødvendigt først at rekruttere toppen og først derefter ungdommen.
• Gulerod og stok.

Jeg har ikke et godt svar på spørgsmålet om, hvad den rigtige balance er, hvordan man opretholder den, hvor mange mennesker man skal beholde og hvor meget man skal presse. Dette er en rent individuel proces.

Dag enoghalvtreds

Jeg begyndte at se nærmere på holdet for at forstå, hvem jeg havde, og endnu en gang huskede jeg:

"De fleste problemer er menneskers problemer."

Jeg har fundet ud af, at holdet som sådan - både Dev og Ops - har tre store problemer:

• Tilfredshed med den aktuelle situation.
• Mangel på ansvar - fordi ingen nogensinde har bragt resultaterne af kunstnernes arbejde til at påvirke forretningen.
• Frygt for forandring.

Forandring tager dig altid ud af din komfortzone, og jo yngre mennesker er, jo mere kan de ikke lide forandringer, fordi de ikke forstår hvorfor, og de forstår ikke hvordan. Det mest almindelige svar, jeg har hørt, er: "Det har vi aldrig gjort." Desuden nåede det punktet af fuldstændig absurditet - de mindste ændringer kunne ikke finde sted, uden at nogen var indigneret. Og uanset hvor meget ændringerne påvirkede deres arbejde, sagde folk: ”Nej, hvorfor? Det her vil ikke virke."

Men du kan ikke blive bedre uden at ændre noget.

Jeg havde en absolut absurd samtale med en medarbejder, jeg fortalte ham mine ideer til optimering, hvortil han fortalte mig:
- Åh, du så ikke, hvad vi havde sidste år!
- Og hvad så?
"Nu er det meget bedre, end det var."
- Så det kan ikke blive bedre?
- Hvorfor?

Godt spørgsmål - hvorfor? Det er, som om det er bedre nu, end det var, så er alt godt nok. Dette fører til manglende ansvar, hvilket i princippet er helt normalt. Teknikgruppen var som sagt lidt på sidelinjen. Virksomheden mente, at de burde eksistere, men ingen har nogensinde sat standarderne. Teknisk support så aldrig SLA'en, så det var ganske "acceptabelt" for gruppen (og dette slog mig mest):

• 12 sekunders indlæsning;
• 5-10 minutters nedetid hver udgivelse;
• Fejlfinding af kritiske problemer tager dage og uger;
• mangel på vagtpersonale 24x7 / vagt.

Ingen har nogensinde prøvet at spørge, hvorfor gør vi det ikke bedre, og ingen har nogensinde indset, at det ikke behøver at være sådan.

Som en bonus var der endnu et problem: manglende erfaring. Seniorerne rejste, og det resterende unge hold voksede op under det tidligere regime og blev forgiftet af det.

Oven i alt dette var folk også bange for at fejle og fremstå inkompetente. Dette kommer til udtryk i, at de for det første under ingen omstændigheder bedt om hjælp. Hvor mange gange har vi talt som gruppe og individuelt, og jeg har sagt: "Stil et spørgsmål, hvis du ikke ved, hvordan man gør noget." Jeg er sikker på mig selv og ved, at jeg kan løse ethvert problem, men det vil tage tid. Derfor, hvis jeg kan spørge nogen, der ved, hvordan man løser det på 10 minutter, vil jeg spørge. Jo mindre erfaring du har, jo mere bange er du for at spørge, fordi du tror, ​​du vil blive betragtet som inkompetent.

Denne frygt for at stille spørgsmål viser sig på interessante måder. For eksempel spørger du: "Hvordan har du det med denne opgave?" - "Et par timer tilbage, jeg er allerede færdig." Næste dag spørger du igen, får du svaret at alt er i orden, men der var et problem, det vil helt sikkert være klar sidst på dagen. Endnu en dag går, og indtil du bliver klemt fast til væggen og tvunget til at tale med nogen, fortsætter dette. En person ønsker at løse et problem selv; han tror på, at hvis han ikke løser det selv, vil det være en stor fiasko.

Det er derfor udviklerne pustede estimaterne op. Det var den samme anekdote, da de diskuterede en bestemt opgave, gav de mig sådan en figur, at jeg blev meget overrasket. Hvortil jeg fik at vide, at i udviklerens estimater inkluderer udvikleren den tid, billetten vil blive returneret fra QA, fordi de vil finde fejl der, og den tid, PR vil tage, og den tid, mens de personer, der skal gennemgå der vil være travlt - det vil sige alt, hvad end der er muligt.

For det andet folk, der er bange for at fremstå inkompetente overanalysere. Når du siger, hvad der præcist skal gøres, starter det: "Nej, hvad nu hvis vi tænker over det her?" I den forstand er vores virksomhed ikke unik, det er et standardproblem for unge mennesker.

Som svar introducerede jeg følgende praksis:

• Regel 30 minutter. Hvis du ikke kan løse problemet på en halv time, så bed nogen om at hjælpe. Dette fungerer med varierende grad af succes, fordi folk stadig ikke spørger, men i det mindste er processen begyndt.
• Eliminer alt undtagen essensen, ved at estimere fristen for at fuldføre en opgave, det vil sige kun overveje, hvor lang tid det vil tage at skrive koden.
• Livslang læring for dem, der overanalyserer. Det er bare konstant arbejde med mennesker.

Dag tresindstyvende

Mens jeg lavede alt dette, var det tid til at finde ud af budgettet. Selvfølgelig fandt jeg en masse interessante ting i, hvor vi brugte vores penge. For eksempel havde vi et helt rack i et separat datacenter med én FTP-server, som blev brugt af én klient. Det viste sig, at "... vi flyttede, men han blev sådan, vi ændrede ham ikke." Det var 2 år siden.

Af særlig interesse var regningen for cloud-tjenester. Jeg tror, ​​at hovedårsagen til den høje skyregning er de udviklere, der har ubegrænset adgang til servere for første gang i deres liv. De behøver ikke at spørge: "Giv mig venligst en testserver," de kan tage den selv. Derudover ønsker udviklere altid at bygge et så sejt system, at Facebook og Netflix vil være jaloux.

Men udviklerne har ikke erfaring med at købe servere og evnen til at bestemme den nødvendige størrelse af servere, fordi de ikke havde brug for det før. Og de forstår normalt ikke helt forskellen mellem skalerbarhed og ydeevne.

Beholdningsresultater:

• Vi forlod det samme datacenter.
• Opsagt kontrakten med 3 logtjenester. Fordi vi havde 5 af dem - hver udvikler, der begyndte at lege med noget, tog en ny.
• 7 AWS-systemer blev lukket ned. Igen stoppede ingen de døde projekter; de fortsatte alle med at arbejde.
• Reducerede softwareomkostninger med 6 gange.

Dag femoghalvfjerds

Tiden gik, og om to en halv måned skulle jeg mødes med bestyrelsen. Vores bestyrelse er hverken bedre eller værre end andre; ligesom alle bestyrelser vil den vide alt. Folk investerer penge og vil gerne forstå, hvor meget det, vi laver, passer ind i de fastsatte KPI'er.

Bestyrelsen modtager en masse information hver måned: antallet af brugere, deres vækst, hvilke tjenester de bruger og hvordan, ydeevne og produktivitet og endelig den gennemsnitlige sideindlæsningshastighed.

Det eneste problem er, at jeg mener, at gennemsnittet er ren ondskab. Men det er meget svært at forklare bestyrelsen. De er vant til at arbejde med aggregerede tal, og ikke for eksempel spredning af indlæsningstider pr.

Der var nogle interessante punkter i denne forbindelse. For eksempel sagde jeg, at vi skal opdele trafik mellem separate webservere afhængigt af typen af ​​indhold.

Det vil sige, at ColdFusion går gennem Jetty og nginx og starter siderne. Og billeder, JS og CSS gennemgår en separat nginx med deres egne konfigurationer. Det er en ret standard praksis, jeg taler om jeg skrev for et par år siden. Som et resultat indlæses billeder meget hurtigere, og... den gennemsnitlige indlæsningshastighed er steget med 200 ms.

Dette skete, fordi grafen er bygget ud fra de data, der følger med Jetty. Det vil sige, at hurtigt indhold ikke er med i beregningen - gennemsnitsværdien er hoppet. Det stod klart for os, vi grinede, men hvordan kan vi forklare bestyrelsen, hvorfor vi gjorde noget, og tingene blev værre med 12 %?

Dag femogfirs

I slutningen af ​​den tredje måned indså jeg, at der var én ting, jeg slet ikke havde regnet med: tid. Alt, hvad jeg talte om, tager tid.

Dette er min rigtige ugentlige kalender - bare en arbejdsuge, ikke særlig travl. Der er ikke tid nok til alt. Derfor skal du igen rekruttere folk, der vil hjælpe dig med at klare problemerne.

Konklusion

Det er ikke alt. I denne historie er jeg ikke engang nået til, hvordan vi arbejdede med produktet og forsøgte at tune ind på den generelle bølge, eller hvordan vi integrerede teknisk support, eller hvordan vi løste andre tekniske problemer. For eksempel lærte jeg helt tilfældigt, at vi ikke bruger de største tabeller i databasen SEQUENCE. Vi har en selvskrevet funktion nextID, og det bruges ikke i en transaktion.

Der var en million flere lignende ting, som vi kunne tale om i lang tid. Men det vigtigste, der stadig mangler at blive sagt, er kultur.

Det er kultur eller mangel på samme, der fører til alle andre problemer. Vi forsøger at opbygge en kultur, hvor mennesker:

• er ikke bange for fiaskoer;
• lære af fejl;
• samarbejde med andre teams;
• tage initiativ;
• tag ansvar;
• byder resultatet velkommen som et mål;
• fejrer succes.

Med dette kommer alt andet.

Leon Fire på twitter, facebook og medium.

Der er to strategier vedrørende arv: undgå at arbejde med det for enhver pris, eller overvind modigt de tilknyttede vanskeligheder. Vi C DevOpsConf Vi går den anden vej, og ændrer processer og tilgange. Slut dig til os youtube, postliste и telegram, og sammen vil vi implementere en DevOps-kultur.

Kilde: www.habr.com