Det er kjent at CTOs kompetanse testes først andre gang han utfører denne rollen. For det er én ting å jobbe i en bedrift i flere år, utvikle seg med den og, å være i samme kulturelle kontekst, gradvis få mer ansvar. Og det er noe helt annet å komme rett inn i stillingen som teknisk direktør i et selskap med eldre bagasje og en haug med problemer feid pent under teppet.

I denne forstand, opplevelsen av Leon Fire, som han delte på DevOpsConf, ikke akkurat unik, men multiplisert med hans erfaring og antall forskjellige roller som han klarte å prøve i løpet av 20 år, er det veldig nyttig. Under kuttet er en kronologi over hendelser over 90 dager og mange historier som er morsomme å le av når de skjer med noen andre, men som ikke er så morsomme å møte personlig.

Leon snakker veldig fargerikt på russisk, så hvis du har 35-40 minutter, anbefaler jeg å se videoen. Tekstversjon for å spare tid nedenfor.

Den første versjonen av rapporten var en godt strukturert beskrivelse av arbeid med mennesker og prosesser, med nyttige anbefalinger. Men hun formidlet ikke alle overraskelsene som ble møtt underveis. Derfor endret jeg formatet og presenterte problemene som dukket opp foran meg som en jack-in-the-box i det nye selskapet, og metoder for å løse dem i kronologisk rekkefølge.

En måned før

Som mange gode historier startet denne med alkohol. Vi satt med venner på en bar, og som forventet blant IT-spesialister gråt alle over problemene sine. En av dem hadde nettopp byttet jobb og snakket om problemene sine med teknologi, og med mennesker og med teamet. Jo mer jeg lyttet, jo mer skjønte jeg at han bare burde ansette meg, for det er slike problemer jeg har løst de siste 15 årene. Jeg fortalte ham det, og dagen etter møttes vi i et arbeidsmiljø. Bedriften ble kalt Teaching Strategies.

Teaching Strategies er markedsleder innen læreplan for svært små barn fra fødsel til tre år. Det tradisjonelle «papir»-selskapet er allerede 40 år gammelt, og den digitale SaaS-versjonen av plattformen er 10. Relativt nylig startet prosessen med å tilpasse digital teknologi til bedriftens standarder. Den "nye" versjonen ble lansert i 2017 og var nesten som den gamle, bare den fungerte dårligere.

Det mest interessante er at dette selskapets trafikk er veldig forutsigbar - fra dag til dag, fra år til år kan du veldig tydelig forutsi hvor mange mennesker som kommer og når. For eksempel mellom 13 og 15 legger alle barna i barnehagen seg og lærerne begynner å legge inn informasjon. Og dette skjer hver dag, unntatt helger, for nesten ingen jobber i helgene.

Ser jeg litt fremover, vil jeg legge merke til at jeg startet arbeidet mitt i perioden med høyest årlig trafikk, noe som er interessant av forskjellige grunner.

Plattformen, som så ut til å være bare 2 år gammel, hadde en særegen stack: ColdFusion & SQL Server fra 2008. ColdFusion, hvis du ikke vet, og mest sannsynlig ikke vet, er en bedrifts-PHP som kom ut på midten av 90-tallet, og siden da har jeg ikke engang hørt om det. Det var også: Ruby, MySQL, PostgreSQL, Java, Go, Python. Men hovedmonolitten kjørte på ColdFusion og SQL Server.

Problemer

Jo mer jeg snakket med selskapets ansatte om arbeidet og hvilke problemer som ble møtt, jo mer innså jeg at problemene ikke bare var av teknisk natur. Ok, teknologien er gammel - og de jobbet ikke med den, men det var problemer med teamet og prosessene, og selskapet begynte å forstå dette.

Tradisjonelt satt teknologene deres i hjørnet og gjorde en slags arbeid. Men flere og flere virksomheter begynte å gå gjennom den digitale versjonen. Derfor, det siste året før jeg begynte å jobbe, dukket det opp nye i selskapet: styre, CTO, CPO og QA-direktør. Det vil si at selskapet begynte å investere i teknologisektoren.

Spor etter en tung arv var ikke bare i systemene. Selskapet hadde legacy prosesser, legacy people, legacy kultur. Alt dette måtte endres. Jeg tenkte at det definitivt ikke ville være kjedelig, og bestemte meg for å prøve det.

To dager før

To dager før jeg begynte i en ny jobb, kom jeg til kontoret, fylte ut de siste papirene, møtte teamet og oppdaget at teamet slet med et problem på det tidspunktet. Det var at den gjennomsnittlige sidelastingstiden hoppet til 4 sekunder, det vil si 2 ganger.

Etter grafen å dømme skjedde det tydeligvis noe, og det er ikke klart hva. Det viste seg at problemet var nettverksforsinkelse i datasenteret: 5 ms latens i datasenteret ble til 2 s for brukere. Jeg visste ikke hvorfor dette skjedde, men i alle fall ble det kjent at problemet var i datasenteret.

Dag én

To dager gikk og på min første arbeidsdag oppdaget jeg at problemet ikke var borte.

I to dager lastet brukernes sider i gjennomsnitt på 4 sekunder. Jeg spør om de har funnet ut hva problemet er.

– Ja, vi åpnet billett.
- OG?
– Vel, de har ikke svart oss ennå.

Så skjønte jeg at alt jeg hadde blitt fortalt om før var bare et lite tips av isfjellet som jeg måtte kjempe.

Det er et godt sitat som passer veldig godt til dette:

"Noen ganger må du endre organisasjonen for å endre teknologi."

Men siden jeg begynte å jobbe på den travleste tiden av året, måtte jeg se på begge alternativene for å løse problemet: både raskt og langsiktig. Og start med det som er kritisk akkurat nå.

Dag tre

Så lasting varer i 4 sekunder, og fra 13 til 15 de største toppene.

På den tredje dagen i løpet av denne tidsperioden så nedlastingshastigheten slik ut:

Fra mitt ståsted fungerte ingenting i det hele tatt. Fra alle andres synspunkt gikk det litt tregere enn vanlig. Men det skjer bare ikke slik - det er et alvorlig problem.

Jeg prøvde å overbevise teamet, som de svarte at de rett og slett trengte flere servere. Dette er selvfølgelig en løsning på problemet, men det er ikke alltid den eneste og mest effektive. Jeg spurte hvorfor det ikke var nok servere, hva var trafikkvolumet. Jeg ekstrapolerte dataene og fant ut at vi har omtrent 150 forespørsler per sekund, som i prinsippet faller innenfor rimelighetens grenser.

Men vi må ikke glemme at før du får det riktige svaret, må du stille det riktige spørsmålet. Mitt neste spørsmål var: hvor mange frontend-servere har vi? Svaret "forvirret meg litt" - vi hadde 17 frontend-servere!

— Jeg er flau over å spørre, men 150 delt på 17 gir omtrent 8? Sier du at hver server tillater 8 forespørsler per sekund, og hvis det i morgen er 160 forespørsler per sekund, trenger vi 2 flere servere?

Selvfølgelig trengte vi ikke flere servere. Løsningen lå i selve koden, og på overflaten:

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

Det var en funksjon getCurrentClass(), fordi alt på nettstedet fungerer i sammenheng med en klasse - det stemmer. Og for denne ene funksjonen på hver side var det 200+ forespørsler.

Løsningen på denne måten var veldig enkel, du trengte ikke engang å skrive om noe: bare ikke be om den samme informasjonen igjen.

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

Jeg var veldig glad fordi jeg bestemte meg for at jeg bare den tredje dagen hadde funnet hovedproblemet. Naiv som jeg var, var dette bare ett av mange problemer.

Men å løse dette første problemet falt grafen mye lavere.

Samtidig gjorde vi andre optimaliseringer. Det var mange ting i sikte som kunne fikses. For eksempel oppdaget jeg samme tredje dag at det tross alt var en cache i systemet (jeg trodde først at alle forespørsler kom direkte fra databasen). Når jeg tenker på en cache, tenker jeg på standard Redis eller Memcached. Men jeg var den eneste som trodde det, fordi det systemet brukte MongoDB og SQL Server for caching - den samme som dataene nettopp ble lest fra.

Dag ti

Den første uken jobbet jeg med problemer som måtte løses akkurat nå. Et sted i den andre uken kom jeg til stand-up for første gang for å kommunisere med teamet, for å se hva som skjedde og hvordan hele prosessen foregikk.

Noe interessant ble oppdaget igjen. Teamet besto av: 18 utviklere; 8 testere; 3 ledere; 2 arkitekter. Og de deltok alle i vanlige ritualer, det vil si at mer enn 30 personer kom til standupen hver morgen og fortalte hva de gjorde. Det er tydelig at møtet ikke tok 5 eller 15 minutter. Ingen lyttet til noen fordi alle jobber på forskjellige systemer. I denne formen var 2-3 billetter i timen til en stelleøkt allerede et godt resultat.

Det første vi gjorde var å dele opp teamet i flere produktlinjer. For forskjellige seksjoner og systemer tildelte vi separate team, som inkluderte utviklere, testere, produktsjefer og forretningsanalytikere.

Som et resultat fikk vi:

Redusere stand-ups og stevner.
Fagkunnskap om produktet.
En følelse av eierskap. Når folk pleide å fikle med systemer hele tiden, visste de at noen andre mest sannsynlig ville måtte jobbe med feilene deres, men ikke seg selv.
Samarbeid mellom grupper. Unødvendig å si at QA ikke kommuniserte mye med programmerere før, produktet gjorde sine egne ting, etc. Nå har de et felles ansvarspunkt.

Vi fokuserte hovedsakelig på effektivitet, produktivitet og kvalitet - dette er problemene vi prøvde å løse med transformasjonen av teamet.

Dag elleve

I prosessen med å endre teamstrukturen oppdaget jeg hvordan jeg skulle telle StoryPoeng. 1 SP var lik en dag, og hver billett inneholdt SP for både utvikling og QA, det vil si minst 2 SP.

Hvordan oppdaget jeg dette?

Vi fant en feil: I en av rapportene, der start- og sluttdatoen for perioden som rapporten er nødvendig for, er det ikke tatt hensyn til den siste dagen. Det vil si at et sted i forespørselen var det ikke <=, men rett og slett <. Jeg ble fortalt at dette er tre Story Points, altså 3 dager.

Etter dette:

Rangeringssystemet for Story Points har blitt revidert. Nå når rettelser for mindre feil som raskt kan sendes gjennom systemet brukeren raskere.
Vi begynte å slå sammen relaterte billetter for utvikling og testing. Tidligere var hver billett, hver feil et lukket økosystem, ikke knyttet til noe annet. Å endre tre knapper på én side kunne ha vært tre forskjellige billetter med tre forskjellige QA-prosesser i stedet for én automatisert test per side.
Vi begynte å jobbe med utviklere om en tilnærming til å estimere lønnskostnader. Tre dager på å endre én knapp er ikke morsomt.

Dag tjuende

Et sted midt i den første måneden stabiliserte situasjonen seg litt, jeg skjønte hva som egentlig skjedde, og begynte allerede å se inn i fremtiden og tenke på langsiktige løsninger.

Langsiktige mål:

Administrert plattform. Hundrevis av forespørsler på hver side er ikke seriøse.
Forutsigbare trender. Det var periodiske trafikktopper som ved første øyekast ikke korrelerte med andre beregninger - vi trengte å forstå hvorfor dette skjedde og lære å forutsi.
Utvidelse av plattform. Virksomheten vokser stadig, flere og flere brukere kommer, og trafikken øker.

Tidligere ble det ofte sagt: "La oss omskrive alt på [språk/rammeverk], alt vil fungere bedre!"

I de fleste tilfeller fungerer ikke dette, det er bra om omskrivingen i det hele tatt fungerer. Derfor trengte vi å lage et veikart - en spesifikk strategi som illustrerer trinn for trinn hvordan forretningsmål vil bli oppnådd (hva vi vil gjøre og hvorfor), som:

reflekterer oppdraget og målene for prosjektet;
prioriterer hovedmål;
inneholder en tidsplan for å oppnå dem.

Før dette hadde ingen snakket med teamet om hensikten med at eventuelle endringer ble gjort. Dette krever riktige suksessmålinger. For første gang i selskapets historie satte vi KPIer for den tekniske gruppen, og disse indikatorene var knyttet til organisatoriske.

Det vil si at organisasjons-KPI-er støttes av team, og team-KPI-er støttes av individuelle KPI-er. Ellers, hvis teknologiske KPIer ikke er sammenfallende med organisatoriske, så drar alle teppet på seg selv.

For eksempel er en av de organisatoriske KPIene å øke markedsandeler gjennom nye produkter.

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

For det første ønsker vi å bruke mer tid på å utvikle nye produkter i stedet for å fikse feil. Dette er en logisk løsning som er enkel å måle.
For det andre ønsker vi å støtte en økning i transaksjonsvolum, fordi jo større markedsandel, jo flere brukere og følgelig mer trafikk.

Da vil individuelle KPIer som kan utføres innad i gruppen for eksempel være på stedet hvor hovedfeilene kommer fra. Hvis du fokuserer spesifikt på denne delen, kan du sørge for at det er mye færre defekter, og da vil tiden for å utvikle nye produkter og igjen for å støtte organisatoriske KPIer øke.

Derfor må enhver beslutning, inkludert omskriving av kode, støtte de spesifikke målene som selskapet har satt for oss (organisasjonsvekst, nye funksjoner, rekruttering).

I løpet av denne prosessen kom det frem en interessant ting, som ble nyheter ikke bare for teknologer, men generelt i selskapet: alle billetter må være fokusert på minst én KPI. Det vil si at hvis et produkt sier at det ønsker å lage en ny funksjon, bør det første spørsmålet stilles: "Hvilken KPI støtter denne funksjonen?" Hvis ikke, så beklager - det virker som en unødvendig funksjon.

Dag tretti

På slutten av måneden oppdaget jeg en annen nyanse: ingen i Ops-teamet mitt har noen gang sett kontraktene vi inngår med kunder. Du kan spørre hvorfor du trenger å se kontakter.

For det første fordi SLA er spesifisert i kontrakter.
For det andre er SLAer forskjellige. Hver klient kom med sine egne krav, og salgsavdelingen signerte uten å se.

En annen interessant nyanse er at kontrakten med en av de største kundene sier at alle programvareversjoner som støttes av plattformen må være n-1, det vil si ikke den siste versjonen, men den nest siste.

Det er tydelig hvor langt vi var fra n-1 hvis plattformen var basert på ColdFusion og SQL Server 2008, som ikke lenger ble støttet i det hele tatt i juli.

Dag førti-fem

Rundt midten av den andre måneden hadde jeg nok tid til å sette meg ned og gjøre verdistreamkartlegging fullstendig for hele prosessen. Dette er de nødvendige trinnene som må tas, fra å lage et produkt til å levere det til forbrukeren, og de må beskrives så detaljert som mulig.

Du bryter prosessen i små biter og ser hva som tar for mye tid, hva som kan optimaliseres, forbedres osv. For eksempel, hvor lang tid tar det før en produktforespørsel går gjennom grooming, når når den en billett som en utvikler kan ta, QA osv. Så du ser på hvert enkelt trinn i detalj og tenker på hva som kan optimaliseres.

Da jeg gjorde dette, fanget to ting meg:

høy prosentandel av billetter returnert fra QA tilbake til utviklere;
pull request-gjennomgangene tok for lang tid.

Problemet var at dette var konklusjoner som: Det ser ut til å ta mye tid, men vi er ikke sikre på hvor lang tid.

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

Hvordan rettferdiggjøre hvor alvorlig problemet er? Kaster det bort dager eller timer?

For å måle dette, la vi til et par trinn i Jira-prosessen: "ready for dev" og "ready for QA" for å måle hvor lenge hver billett venter og hvor mange ganger den går tilbake til et bestemt trinn.

Vi har også lagt til "i anmeldelse" for å vite hvor mange billetter som er i gjennomsnitt for anmeldelse, og fra dette kan du begynne å danse. Vi hadde systemmålinger, nå la vi til nye beregninger og begynte å måle:

Prosesseffektivitet: ytelse og planlagt/levert.
Prosesskvalitet: antall defekter, mangler fra QA.

Det hjelper virkelig å forstå hva som går bra og hva som ikke går bra.

Dag femtiende

Alt dette er selvfølgelig bra og interessant, men mot slutten av den andre måneden skjedde det noe som i prinsippet var forutsigbart, selv om jeg ikke forventet en slik skala. Folk begynte å gå fordi toppledelsen hadde endret seg. Nye folk kom inn i ledelsen og begynte å endre alt, og de gamle sluttet. Og vanligvis i et selskap som er flere år gammelt, er alle venner og alle kjenner hverandre.

Dette var forventet, men omfanget av permitteringene var uventet. For eksempel, i løpet av en uke, leverte to teamledere samtidig sin oppsigelse av egen fri vilje. Derfor måtte jeg ikke bare glemme andre problemer, men fokusere på skape et team. Dette er et langt og vanskelig problem å løse, men det måtte håndteres fordi jeg ønsket å redde menneskene som ble igjen (eller de fleste av dem). Det var nødvendig å på en eller annen måte reagere på at folk dro for å opprettholde moralen i laget.

I teorien er dette bra: en ny person kommer inn som har fullstendig carte blanche, som kan evaluere lagets ferdigheter og erstatte personell. Faktisk kan du ikke bare få inn nye mennesker av så mange grunner. Balanse er alltid nødvendig.

Gammelt og nytt. Vi må beholde gamle mennesker som kan forandre og støtte oppdraget. Men samtidig må vi få inn nytt blod, det skal vi snakke om litt senere.
Erfaring. Jeg snakket mye med flinke juniorer som var ivrige og ville jobbe med oss. Men jeg kunne ikke ta dem på meg fordi det ikke var nok seniorer til å støtte juniorene og fungere som mentorer for dem. Det var nødvendig å først rekruttere toppen og først deretter ungdommen.
Gulrot og pinne.

Jeg har ikke noe godt svar på spørsmålet om hva den rette balansen er, hvordan man opprettholder den, hvor mange personer man skal beholde og hvor mye man skal presse. Dette er en rent individuell prosess.

Dag femtien

Jeg begynte å se nøye på teamet for å forstå hvem jeg hadde, og igjen husket jeg:

"De fleste problemer er menneskers problemer."

Jeg har funnet ut at teamet som sådan – både Dev og Ops – har tre store problemer:

Tilfredshet med dagens tilstand.
Mangel på ansvar - fordi ingen noen gang har brakt resultatene av utøvernes arbeid for å påvirke virksomheten.
Frykt for forandring.

Endring tar deg alltid ut av komfortsonen din, og jo yngre folk er, jo mer misliker de endringer fordi de ikke forstår hvorfor og ikke forstår hvordan. Det vanligste svaret jeg har hørt er: "Det har vi aldri gjort." Dessuten nådde det punktet av fullstendig absurditet - de minste endringer kunne ikke skje uten at noen ble indignert. Og uansett hvor mye endringene påvirket arbeidet deres, sa folk: «Nei, hvorfor? Dette vil ikke fungere."

Men du kan ikke bli bedre uten å endre noe.

Jeg hadde en helt absurd samtale med en ansatt, jeg fortalte ham ideene mine for optimalisering, som han fortalte meg:
- Å, du så ikke hva vi hadde i fjor!
- Hva så?
"Nå er det mye bedre enn det var."
– Så det kan ikke bli bedre?
- Til hva?

Godt spørsmål - hvorfor? Det er som om det er bedre nå enn det var, så er alt bra nok. Dette fører til manglende ansvar, noe som i utgangspunktet er helt normalt. Teknisk gruppe var som sagt litt på sidelinja. Selskapet mente at de burde eksistere, men ingen har noen gang satt standardene. Teknisk støtte så aldri SLA, så det var ganske "akseptabelt" for gruppen (og dette slo meg mest):

12 sekunder lasting;
5-10 minutter nedetid hver utgivelse;
Feilsøking av kritiske problemer tar dager og uker;
mangel på vaktpersonell 24x7 / vakt.

Ingen har noen gang prøvd å spørre hvorfor vi ikke gjør det bedre, og ingen har noen gang skjønt at det ikke trenger å være slik.

Som en bonus var det ett problem til: mangel på erfaring. Seniorene dro, og det gjenværende unge laget vokste opp under det forrige regimet og ble forgiftet av det.

På toppen av alt dette var folk også redde for å feile og fremstå som inkompetente. Dette kommer til uttrykk ved at de for det første under ingen omstendigheter bedt om hjelp. Hvor mange ganger har vi snakket som en gruppe og individuelt, og jeg har sagt: "Still et spørsmål hvis du ikke vet hvordan du skal gjøre noe." Jeg er trygg på meg selv og vet at jeg kan løse ethvert problem, men det vil ta tid. Derfor, hvis jeg kan spørre noen som vet hvordan jeg skal løse det om 10 minutter, vil jeg spørre. Jo mindre erfaring du har, jo mer redd er du for å spørre fordi du tror du vil bli ansett som inhabil.

Denne frykten for å stille spørsmål viser seg på interessante måter. For eksempel spør du: "Hvordan har du det med denne oppgaven?" - "Et par timer igjen, jeg er allerede ferdig." Neste dag du spør igjen, får du til svar at alt er i orden, men det var ett problem, det vil garantert være klart mot slutten av dagen. Enda en dag går, og helt til du blir festet til veggen og tvunget til å snakke med noen, fortsetter dette. En person ønsker å løse et problem selv; han tror at hvis han ikke løser det selv, vil det være en stor fiasko.

Det er derfor utviklerne blåste opp estimatene. Det var den samme anekdoten, da de diskuterte en bestemt oppgave, ga de meg en slik figur at jeg ble veldig overrasket. Som jeg ble fortalt at i utviklerens estimater inkluderer utvikleren tiden billetten vil bli returnert fra QA, fordi de vil finne feil der, og tiden som PR-en vil ta, og tiden mens personene som skal vurdere det vil være travelt - det vil si alt, uansett hva som er mulig.

For det andre folk som er redde for å fremstå som inkompetente overanalysere. Når du sier hva som må gjøres, begynner det: "Nei, hva om vi tenker på det her?" Slik sett er ikke vårt selskap unikt, dette er et standardproblem for unge mennesker.

Som svar introduserte jeg følgende praksis:

Regel 30 minutter. Hvis du ikke kan løse problemet på en halvtime, be noen om å hjelpe. Dette fungerer med ulik grad av suksess, fordi folk fortsatt ikke spør, men prosessen har i det minste begynt.
Eliminer alt annet enn essensen, ved å estimere fristen for å fullføre en oppgave, det vil si at du bare vurderer hvor lang tid det vil ta å skrive koden.
Kontinuerlig læring for de som overanalyserer. Det er bare konstant arbeid med mennesker.

Dag sekstiende

Mens jeg gjorde alt dette, var det på tide å finne ut budsjettet. Selvfølgelig fant jeg mye interessant i hvor vi brukte pengene våre. For eksempel hadde vi et helt rack i et eget datasenter med én FTP-server, som ble brukt av én klient. Det viste seg at "... vi flyttet, men han ble sånn, vi endret ham ikke." Det var 2 år siden.

Spesielt interessant var regningen for skytjenester. Jeg tror hovedårsaken til den høye skyregningen er utviklerne som har ubegrenset tilgang til servere for første gang i livet. De trenger ikke å spørre: "Vennligst gi meg en testserver," de kan ta den selv. Dessuten ønsker utviklere alltid å bygge et så kult system at Facebook og Netflix vil være sjalu.

Men utviklerne har ikke erfaring med å kjøpe servere og ferdigheten til å bestemme den nødvendige størrelsen på servere, fordi de ikke trengte det før. Og de forstår vanligvis ikke helt forskjellen mellom skalerbarhet og ytelse.

Beholdningsresultater:

Vi forlot det samme datasenteret.
Vi sa opp kontrakten med 3 loggtjenester. Fordi vi hadde 5 av dem - hver utvikler som begynte å leke med noe tok en ny.
7 AWS-systemer ble stengt. Igjen, ingen stoppet de døde prosjektene; de fortsatte alle å jobbe.
Reduserte programvarekostnader med 6 ganger.

Dag syttifem

Tiden gikk, og om to og en halv måned måtte jeg møte med styret. Vårt styre er verken bedre eller dårligere enn andre; som alle styrer ønsker det å vite alt. Folk investerer penger og ønsker å forstå hvor mye det vi gjør passer inn i de angitte KPIene.

Styret mottar mye informasjon hver måned: antall brukere, deres vekst, hvilke tjenester de bruker og hvordan, ytelse og produktivitet, og til slutt gjennomsnittlig sidelastingshastighet.

Problemet er bare at jeg mener at gjennomsnittet er ren ondskap. Men det er veldig vanskelig å forklare dette for styret. De er vant til å operere med aggregerte tall, og ikke for eksempel spredning av lastetider per sekund.

Det var noen interessante poeng i denne forbindelse. For eksempel sa jeg at vi må dele trafikk mellom separate webservere avhengig av type innhold.

Det vil si at ColdFusion går gjennom Jetty og nginx og starter sidene. Og bilder, JS og CSS går gjennom en egen nginx med sine egne konfigurasjoner. Dette er en ganske standard praksis som jeg snakker om jeg skrev for et par år siden. Som et resultat laster bilder mye raskere, og... den gjennomsnittlige lastehastigheten har økt med 200 ms.

Dette skjedde fordi grafen er bygget basert på dataene som følger med Jetty. Det vil si at raskt innhold ikke er inkludert i beregningen - gjennomsnittsverdien har hoppet. Dette var tydelig for oss, vi lo, men hvordan kan vi forklare styret hvorfor vi gjorde noe og ting ble verre med 12 %?

Dag åttifem

På slutten av den tredje måneden skjønte jeg at det var én ting jeg ikke hadde regnet med i det hele tatt: tid. Alt jeg snakket om tar tid.

Dette er min virkelige ukekalender - bare en arbeidsuke, ikke veldig travel. Det er ikke nok tid til alt. Derfor må du igjen rekruttere folk som vil hjelpe deg med å takle problemene.

Konklusjon

Det er ikke alt. I denne historien har jeg ikke engang kommet til hvordan vi jobbet med produktet og prøvde å stille inn på den generelle bølgen, eller hvordan vi integrerte teknisk støtte, eller hvordan vi løste andre tekniske problemer. For eksempel lærte jeg ganske ved en tilfeldighet at vi ikke bruker de største tabellene i databasen SEQUENCE. Vi har en egenskrevet funksjon nextID, og den brukes ikke i en transaksjon.

Det var en million flere lignende ting som vi kunne snakke om lenge. Men det viktigste som fortsatt må sies er kultur.

Det er kultur eller mangel på sådan som fører til alle andre problemer. Vi prøver å bygge en kultur der mennesker:

er ikke redd for feil;
lære fra feil;
samarbeide med andre team;
ta initiativ;
ta ansvar;
velkommen resultatet som et mål;
feire suksess.

Med dette vil alt annet komme.

Leon Brann på Twitter, facebook og medium.

Det er to strategier angående arv: unngå å jobbe med det for enhver pris, eller overvinn de tilknyttede vanskelighetene modig. Vi c DevOpsConf Vi tar den andre veien, endrer prosesser og tilnærminger. Bli med oss på youtube, nyhetsbrev и telegram, og sammen skal vi implementere en DevOps-kultur.

Kilde: www.habr.com

Arv av eldre systemer og prosesser eller første 90 dager som CTO