Tiedetään, että teknologiajohtajan pätevyys testataan vasta toisella kerralla, kun hän suorittaa tätä tehtävää. Koska yksi asia on työskennellä yrityksessä useita vuosia, kehittyä sen mukana ja saada vähitellen vastuuta samassa kulttuuriympäristössä. Ja on aivan erilaista tulla suoraan teknisen johtajan tehtävään yrityksessä, jolla on perintömatkatavarat ja joukko ongelmia siististi maton alle.

Tässä mielessä Leon Firen kokemus, jonka hän jakoi DevOpsConf, ei aivan ainutlaatuinen, mutta kerrottuna hänen kokemuksellaan ja useilla eri rooleilla, joita hän onnistui kokeilemaan 20 vuoden aikana, se on erittäin hyödyllinen. Leikkauksen alla on kronologia tapahtumista yli 90 päivän ajalta ja paljon tarinoita, joille on hauska nauraa, kun ne tapahtuvat jollekin toiselle, mutta joita ei ole niin hauskaa kohdata henkilökohtaisesti.

Leon puhuu erittäin värikkäästi venäjää, joten jos sinulla on 35-40 minuuttia, suosittelen katsomaan videon. Alla tekstiversio ajan säästämiseksi.

Raportin ensimmäinen versio oli hyvin jäsennelty kuvaus ihmisten ja prosessien kanssa työskentelystä, sisältäen hyödyllisiä suosituksia. Mutta hän ei välittänyt kaikkia yllätyksiä, joita matkan varrella kohtasi. Siksi vaihdoin formaattia ja esitin eteeni ponnahtaneet ongelmat uudessa yrityksessä kuin jack-in-the-box ja menetelmiä niiden ratkaisemiseksi kronologisessa järjestyksessä.

Kuukausi ennen

Kuten monet hyvät tarinat, tämäkin alkoi alkoholista. Istuimme ystävien kanssa baarissa, ja IT-asiantuntijoiden keskuudessa odotetusti kaikki itkivät ongelmistaan. Yksi heistä oli juuri vaihtanut työpaikkaa ja puhui ongelmistaan ​​tekniikan, ihmisten ja tiimin kanssa. Mitä enemmän kuuntelin, sitä enemmän ymmärsin, että hänen pitäisi vain palkata minut, koska olen ratkaissut tämäntyyppisiä ongelmia viimeiset 15 vuotta. Kerroin hänelle niin, ja seuraavana päivänä tapasimme työympäristössä. Yrityksen nimi oli Teaching Strategies.

Teaching Strategies on markkinajohtaja hyvin pienten lasten opetussuunnitelmissa syntymästä kolmen vuoden ikään. Perinteinen ”paperi”yritys on jo 40 vuotta vanha ja alustan digitaalinen SaaS-versio 10. Suhteellisen äskettäin aloitettiin digitaalisen teknologian mukauttaminen yrityksen standardeihin. "Uusi" versio julkaistiin vuonna 2017 ja oli melkein kuin vanha, vain se toimi huonommin.

Mielenkiintoisinta on, että tämän yrityksen liikenne on hyvin ennustettavaa - päivästä päivään, vuodesta toiseen, voit hyvin selvästi ennustaa kuinka monta ihmistä tulee ja milloin. Esimerkiksi klo 13-15 välisenä aikana kaikki päiväkodin lapset menevät nukkumaan ja opettajat alkavat syöttää tietoja. Ja tätä tapahtuu joka päivä, paitsi viikonloppuisin, koska melkein kukaan ei työskentele viikonloppuisin.

Hieman eteenpäin katsoessani totean, että aloitin työni vuosittaisen liikenteen suurimman liikenteen aikana, mikä on mielenkiintoista eri syistä.

Alustalla, joka näytti olevan vain 2 vuotta vanha, oli erikoinen pino: ColdFusion & SQL Server vuodelta 2008. ColdFusion, jos et tiedä ja todennäköisesti et tiedä, on yritys-PHP, joka julkaistiin 90-luvun puolivälissä, ja sen jälkeen en ole edes kuullut siitä. Siellä oli myös: Ruby, MySQL, PostgreSQL, Java, Go, Python. Mutta päämonoliitti toimi ColdFusionilla ja SQL Serverillä.

Ongelmat

Mitä enemmän keskustelin yrityksen työntekijöiden kanssa työstä ja kohdatuista ongelmista, sitä enemmän ymmärsin, että ongelmat eivät olleet pelkästään teknisiä. Okei, tekniikka on vanhaa - ja he eivät toimineet sen parissa, mutta tiimissä ja prosesseissa oli ongelmia, ja yritys alkoi ymmärtää tämän.

Perinteisesti heidän teknikot istuivat nurkassa ja tekivät jonkinlaista työtä. Mutta yhä useammat yritykset alkoivat käydä läpi digitaalisen version. Siksi viime vuonna ennen kuin aloin työskennellä, yhtiöön tuli uusia: hallitus, CTO, CPO ja QA johtaja. Eli yritys alkoi investoida teknologia-alalle.

Jälkiä raskaasta perinnöstä ei ollut vain järjestelmissä. Yrityksellä oli perinnöllisiä prosesseja, vanhoja ihmisiä, perintökulttuuria. Kaikki tämä piti muuttaa. Ajattelin, että se ei varmasti olisi tylsää, ja päätin kokeilla sitä.

Kaksi päivää ennen

Kaksi päivää ennen uuden työn aloittamista saavuin toimistoon, täytin viimeiset paperit, tapasin tiimin ja huomasin, että tiimi kamppaili tuolloin ongelman kanssa. Keskimääräinen sivun latausaika hyppäsi 4 sekuntiin, eli 2 kertaa.

Kaaviosta päätellen jotain selvästi tapahtui, eikä ole selvää mitä. Kävi ilmi, että ongelma oli verkon latenssi konesalissa: 5 ms viive konesalissa muuttui käyttäjille 2 s:ksi. En tiennyt miksi näin tapahtui, mutta joka tapauksessa tuli tiedoksi, että ongelma oli palvelinkeskuksessa.

Päivä yksi

Kaksi päivää kului ja ensimmäisenä työpäivänäni huomasin, että ongelma ei ollut kadonnut.

Kahden päivän aikana käyttäjien sivut latautuivat keskimäärin 4 sekunnissa. Kysyn, löysivätkö he ongelman.

- Kyllä, avasimme lipun.
- JA?
- No, he eivät ole vielä vastanneet meille.

Sitten tajusin, että kaikki, mistä minulle oli kerrottu aiemmin, oli vain pieni jäävuoren huippu, jota minun oli taisteltava.

Tässä on hyvä lainaus, joka sopii tähän erittäin hyvin:

"Joskus muuttaa teknologiaa, sinun on muutettava organisaatiota."

Mutta koska aloitin työt vuoden kiireisimpänä aikana, jouduin katsomaan molempia ratkaisuvaihtoehtoja ongelman ratkaisemiseksi: sekä nopean että pitkän tähtäimen. Ja aloita siitä, mikä on kriittistä juuri nyt.

Päivä kolme

Joten lataus kestää 4 sekuntia ja 13-15 suurinta huippua.

Kolmantena päivänä tänä aikana latausnopeus näytti tältä:

Minun näkökulmastani mikään ei toiminut ollenkaan. Kaikkien muiden näkökulmasta se kulki hieman tavallista hitaammin. Mutta niin ei vain tapahdu – se on vakava ongelma.

Yritin vakuuttaa tiimin, johon he vastasivat, että he yksinkertaisesti tarvitsevat lisää palvelimia. Tämä on tietysti ratkaisu ongelmaan, mutta se ei ole aina ainoa ja tehokkain. Kysyin, miksi palvelimia ei ollut tarpeeksi, mikä oli liikenteen määrä. Ekstrapoloin tiedot ja totesin, että meillä on noin 150 pyyntöä sekunnissa, mikä periaatteessa on kohtuullisissa rajoissa.

Mutta emme saa unohtaa, että ennen kuin saat oikean vastauksen, sinun on kysyttävä oikea kysymys. Seuraava kysymykseni oli: kuinka monta käyttöliittymäpalvelinta meillä on? Vastaus "hämmästytti minua hieman" - meillä oli 17 etupalvelinta!

– Minua hävettää kysyä, mutta 150 jaettuna 17:llä antaa noin 8? Tarkoitatko, että jokainen palvelin sallii 8 pyyntöä sekunnissa, ja jos huomenna on 160 pyyntöä sekunnissa, tarvitsemme 2 palvelinta lisää?

Emme tietenkään tarvinneet lisäpalvelimia. Ratkaisu oli itse koodissa ja pinnalla:

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

Siellä oli toiminto getCurrentClass(), koska kaikki sivustolla oleva toimii luokan kontekstissa - aivan oikein. Ja tätä varten jokaisella sivulla oli yksi toiminto 200+ pyyntöä.

Ratkaisu tällä tavalla oli hyvin yksinkertainen, sinun ei tarvinnut edes kirjoittaa mitään uudelleen: älä vain kysy samoja tietoja uudelleen.

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

Olin hyvin iloinen, koska päätin, että vasta kolmantena päivänä olin löytänyt pääongelman. Niin naiivi kuin olinkin, tämä oli vain yksi monista ongelmista.

Mutta tämän ensimmäisen ongelman ratkaiseminen pudotti kaavion paljon alemmas.

Samaan aikaan teimme muita optimointeja. Siellä oli paljon asioita, jotka voitaisiin korjata. Esimerkiksi samana kolmantena päivänä huomasin, että järjestelmässä oli välimuisti (alku luulin, että kaikki pyynnöt tulevat suoraan tietokannasta). Kun ajattelen välimuistia, ajattelen tavallista Redistä tai Memcachedia. Mutta minä olin ainoa, joka ajatteli niin, koska järjestelmä käytti välimuistiin MongoDB:tä ja SQL Serveriä - samaa, josta tiedot juuri luettiin.

Päivä kymmenen

Ensimmäisellä viikolla käsittelin ongelmia, jotka piti ratkaista juuri nyt. Jossain toisella viikolla tulin stand-upiin ensimmäistä kertaa kommunikoimaan joukkueen kanssa, katsomaan mitä tapahtuu ja kuinka koko prosessi etenee.

Jotain mielenkiintoista löytyi taas. Ryhmään kuului: 18 kehittäjää; 8 testaajaa; 3 johtajaa; 2 arkkitehtia. Ja he kaikki osallistuivat yhteisiin rituaaleihin, eli yli 30 ihmistä tuli joka aamu stand-upille kertomaan mitä teki. On selvää, että kokous ei kestänyt 5 tai 15 minuuttia. Kukaan ei kuunnellut ketään, koska kaikki työskentelevät eri järjestelmissä. Tässä muodossa 2-3 lippua tunnissa hoitoistuntoon oli jo hyvä tulos.

Ensimmäinen asia, jonka teimme, oli jakaa tiimi useisiin tuotelinjoihin. Varasimme eri osiolle ja järjestelmille erilliset tiimit, joihin kuului kehittäjiä, testaajia, tuotepäälliköitä ja yritysanalyytikoita.

Tuloksena saimme:

• Stand-upien ja rallien vähentäminen.
• Aiheen tuntemus tuotteesta.
• Omistajuuden tunne. Kun ihmiset puuhastelivat järjestelmiä koko ajan, he tiesivät, että jonkun muun olisi todennäköisesti työskenneltävä heidän vikojensa kanssa, mutta ei itsensä.
• Ryhmien välistä yhteistyötä. Sanomattakin on selvää, että QA ei aiemmin kommunikoinut paljon ohjelmoijien kanssa, tuote teki oman asiansa jne. Nyt heillä on yhteinen vastuu.

Keskityimme pääasiassa tehokkuuteen, tuottavuuteen ja laatuun – näitä ongelmia yritimme ratkaista tiimin muutoksella.

Päivä yksitoista

Ryhmärakennetta muutettaessa huomasin kuinka laskea TarinaPoints. 1 SP vastasi yhtä päivää, ja jokainen lippu sisälsi SP:n sekä kehitykselle että laadunvarmistukselle, eli vähintään 2 SP:tä.

Miten löysin tämän?

Löysimme virheen: yhdessä raportissa, johon on syötetty sen jakson alkamis- ja päättymispäivä, jolta raporttia tarvitaan, viimeistä päivää ei oteta huomioon. Eli jossain pyynnössä ei ollut <=, vaan yksinkertaisesti <. Minulle kerrottiin, että tämä on kolme tarinakohtaa 3 päivää.

Tämän jälkeen me:

• Story Points -luokitusjärjestelmää on uudistettu. Nyt korjaukset pieniin bugiin, jotka voidaan siirtää nopeasti järjestelmän läpi, saapuvat käyttäjälle nopeammin.
• Aloitimme liittyvien lippujen yhdistämisen kehitystä ja testausta varten. Aiemmin jokainen lippu, jokainen bugi oli suljettu ekosysteemi, ei sidottu mihinkään muuhun. Kolmen painikkeen muuttaminen yhdellä sivulla olisi voinut olla kolme eri lippua kolmella eri laadunvarmistusprosessilla yhden automaattisen testin sijasta sivua kohden.
• Aloimme työskennellä kehittäjien kanssa työvoimakustannusten arvioinnissa. Kolme päivää yhden painikkeen vaihtamiseen ei ole hauskaa.

Päivä kahdeskymmenes

Jossain ensimmäisen kuukauden puolessa välissä tilanne hieman tasoittui, tajusin mitä pohjimmiltaan oli tapahtumassa ja aloin jo katsoa tulevaisuuteen ja miettiä pitkän tähtäimen ratkaisuja.

Pitkän aikavälin tavoitteet:

• Hallittu alusta. Sadat pyynnöt kullakin sivulla eivät ole vakavia.
• Ennustettavat trendit. Ajoittain esiintyi liikennehuippuja, jotka eivät ensi silmäyksellä korreloineet muiden mittareiden kanssa – meidän piti ymmärtää, miksi näin tapahtui, ja oppia ennustamaan.
• Alustan laajennus. Liiketoiminta kasvaa jatkuvasti, käyttäjiä tulee yhä enemmän ja liikenne kasvaa.

Aikaisemmin sanottiin usein: "Kirjoitetaan kaikki uudelleen [kielellä/kehyksellä], kaikki toimii paremmin!"

Useimmissa tapauksissa tämä ei toimi, on hyvä, jos uudelleenkirjoitus toimii ollenkaan. Siksi meidän piti luoda tiekartta - erityinen strategia, joka havainnollistaa askel askeleelta, kuinka liiketoimintatavoitteet saavutetaan (mitä teemme ja miksi), joka:

• kuvastaa hankkeen tehtävää ja tavoitteita;
• priorisoi päätavoitteet;
• sisältää aikataulun niiden saavuttamiseksi.

Ennen tätä kukaan ei ollut puhunut joukkueen kanssa tehtävien muutosten tarkoituksesta. Tämä vaatii oikeat menestysmittarit. Ensimmäistä kertaa yrityksen historiassa asetimme tekniselle ryhmälle KPI:t, jotka sidottiin organisaation mittareihin.

Eli tiimit tukevat organisaation KPI:itä ja yksittäiset KPI:t. Muuten, jos tekniset KPI:t eivät ole samat kuin organisatoriset, jokainen vetää peiton itselleen.

Esimerkiksi yksi organisaation KPI:istä on markkinaosuuden kasvattaminen uusien tuotteiden avulla.

Miten voit tukea tavoitetta saada lisää uusia tuotteita?

• Ensinnäkin haluamme käyttää enemmän aikaa uusien tuotteiden kehittämiseen vikojen korjaamisen sijaan. Tämä on looginen ratkaisu, joka on helppo mitata.
• Toiseksi haluamme tukea transaktiovolyymien kasvua, koska mitä suurempi markkinaosuus, sitä enemmän käyttäjiä ja vastaavasti liikennettä.

Tällöin yksittäiset KPI:t, jotka voidaan suorittaa ryhmän sisällä, ovat esimerkiksi paikassa, josta suurimmat viat tulevat. Jos keskityt nimenomaan tähän osioon, voit varmistaa, että vikoja on paljon vähemmän, jolloin uusien tuotteiden kehittämiseen ja jälleen organisaation KPI:iden tukemiseen kuluva aika lisääntyy.

Jokaisen päätöksen, mukaan lukien koodin uudelleenkirjoittamisen, on siis tuettava niitä erityisiä tavoitteita, jotka yritys on meille asettanut (organisaation kasvu, uudet ominaisuudet, rekrytointi).

Tämän prosessin aikana paljastui mielenkiintoinen asia, josta tuli uutinen paitsi teknikolle, vaan ylipäätään yhtiössä: kaikkien lippujen tulee keskittyä vähintään yhteen KPI:hen. Eli jos tuote sanoo haluavansa tehdä uuden ominaisuuden, ensimmäinen kysymys tulee esittää: "Mitä KPI:tä tämä ominaisuus tukee?" Jos ei, niin pahoittelut - se vaikuttaa tarpeettomilta ominaisuuksilta.

Päivä kolmekymmentä

Kuukauden lopussa huomasin toisen vivahteen: kukaan Ops-tiimistäni ei ole koskaan nähnyt sopimuksia, joita teemme asiakkaiden kanssa. Voit kysyä, miksi sinun täytyy nähdä yhteystiedot.

• Ensinnäkin siksi, että SLA-sopimukset on määritelty sopimuksissa.
• Toiseksi palvelutasosopimukset ovat erilaisia. Jokainen asiakas tuli omat vaatimuksensa kanssa, ja myyntiosasto allekirjoitti katsomatta.

Toinen mielenkiintoinen vivahde on, että yhden suurimmista asiakkaista tehdyssä sopimuksessa sanotaan, että kaikkien alustan tukemien ohjelmistoversioiden tulee olla n-1, eli ei viimeisin, vaan toiseksi viimeinen.

On selvää, kuinka kaukana olimme n-1:stä, jos alusta perustui ColdFusioniin ja SQL Server 2008:aan, jota ei enää tuettu lainkaan heinäkuussa.

Päivä neljäkymmentäviisi

Toisen kuukauden puolivälissä minulla oli tarpeeksi aikaa istua alas ja tehdä arvovirtakartoitus kokonaan koko prosessin ajan. Nämä ovat välttämättömiä vaiheita, jotka on toteutettava tuotteen luomisesta sen toimittamiseen kuluttajalle, ja ne on kuvattava mahdollisimman yksityiskohtaisesti.

Purat prosessin pieniksi paloiksi ja näet, mikä vie liikaa aikaa, mitä voidaan optimoida, parantaa jne. Esimerkiksi kuinka kauan tuotepyynnön käsittelyssä kestää, milloin se saavuttaa lipun, jonka kehittäjä voi kestää, laadunvarmistus jne. Joten tarkastelet jokaista yksittäistä vaihetta yksityiskohtaisesti ja mietit, mitä voidaan optimoida.

Kun tein tämän, kaksi asiaa pisti silmään:

• korkea prosenttiosuus lipuista, jotka palautettiin laadunvarmistuksesta takaisin kehittäjille;
• vetopyyntöjen tarkastelu kesti liian kauan.

Ongelmana oli, että nämä olivat päätelmiä, kuten: Se näyttää vievän paljon aikaa, mutta emme ole varmoja kuinka kauan.

"Et voi parantaa sitä, mitä et voi mitata."

Miten perustella, kuinka vakava ongelma on? Haaskaako se päiviä vai tunteja?

Tämän mittaamiseksi lisäsimme Jira-prosessiin pari vaihetta: "valmis kehittämiseen" ja "valmis laadunvalvontaan" mittaamaan, kuinka kauan kukin lippu odottaa ja kuinka monta kertaa se palaa tiettyyn vaiheeseen.

Lisäsimme myös "arvioinnin", jotta tiedämme, kuinka monta lippua keskimäärin on arvioitavassa, ja tästä voit aloittaa tanssin. Meillä oli järjestelmämittarit, nyt lisäsimme uusia mittareita ja aloimme mittaamaan:

• Prosessin tehokkuus: suorituskyky ja suunniteltu/toimitettu.
• Prosessin laatu: vikojen määrä, viat laadunvarmistuksesta.

Se todella auttaa ymmärtämään, mikä menee hyvin ja mikä ei.

Päivä viideskymmenes

Tämä kaikki on tietysti hyvää ja mielenkiintoista, mutta toisen kuukauden lopulla tapahtui jotain, mikä periaatteessa oli ennustettavissa, vaikka en odottanutkaan sellaista mittakaavaa. Ihmiset lähtivät, koska ylin johto oli vaihtunut. Uudet ihmiset tulivat johtoon ja alkoivat muuttaa kaikkea, ja vanhat erosivat. Ja yleensä useita vuosia vanhassa yrityksessä kaikki ovat ystäviä ja kaikki tuntevat toisensa.

Tämä oli odotettavissa, mutta irtisanomisten laajuus oli odottamaton. Esimerkiksi viikon aikana kaksi joukkueenjohtajaa jätti eron omasta tahdostaan ​​samanaikaisesti. Siksi minun ei tarvinnut vain unohtaa muita ongelmia, vaan keskittyä niihin joukkueen luominen. Tämä on pitkä ja vaikea ratkaistava ongelma, mutta se oli käsiteltävä, koska halusin pelastaa jäljelle jääneet ihmiset (tai suurimman osan heistä). Oli tarpeen jotenkin reagoida siihen, että ihmiset lähtivät moraalin ylläpitämiseksi joukkueessa.

Teoriassa tämä on hyvä: paikalle tulee uusi henkilö, jolla on täydellinen carte blanche, joka osaa arvioida tiimin taitoja ja korvata henkilöstöä. Itse asiassa et voi vain tuoda uusia ihmisiä niin monista syistä. Tasapainoa tarvitaan aina.

• Vanha ja uusi. Meidän on säilytettävä vanhoja ihmisiä, jotka voivat muuttua ja tukea tehtävää. Mutta samalla meidän on tuotava uutta verta, puhumme siitä hieman myöhemmin.
• Kokea. Juttelin paljon hyvien junioreiden kanssa, jotka olivat innokkaita ja halusivat työskennellä kanssamme. Mutta en voinut ottaa heitä vastaan, koska ei ollut tarpeeksi senioreita tukemaan junioreita ja toimimaan heille mentoreina. Ensin piti rekrytoida huippu ja vasta sitten nuoriso.
• Porkkana ja tikku.

Minulla ei ole hyvää vastausta kysymykseen, mikä on oikea tasapaino, kuinka se säilytetään, kuinka monta ihmistä pitää ja kuinka paljon työntää. Tämä on puhtaasti yksilöllinen prosessi.

Päivä viisikymmentäyksi

Aloin tarkastella tiimiä tarkasti ymmärtääkseni, kuka minulla oli, ja muistin jälleen kerran:

"Suurin osa ongelmista on ihmisten ongelmia."

Olen huomannut, että tiimillä sellaisenaan - sekä Devillä että Opsilla - on kolme suurta ongelmaa:

• Tyytyväisyys nykyiseen tilanteeseen.
• Vastuun puute - koska kukaan ei ole koskaan tuonut esiintyjien työn tuloksia vaikuttamaan liiketoimintaan.
• Muutoksen pelko.

Muutos vie sinut aina mukavuusalueeltasi, ja mitä nuorempia ihmiset ovat, sitä enemmän he eivät pidä muutoksesta, koska he eivät ymmärrä miksi eivätkä ymmärrä miten. Yleisin vastaus, jonka olen kuullut, on: "Emme ole koskaan tehneet niin." Lisäksi se saavutti täydellisen absurdin pisteen - pienintäkään muutoksia ei voitu tapahtua ilman, että joku suuttui. Ja riippumatta siitä, kuinka paljon muutokset vaikuttivat heidän työhönsä, ihmiset sanoivat: ”Ei, miksi? Tämä ei onnistu."

Mutta et voi parantua muuttamatta mitään.

Kävin täysin absurdin keskustelun työntekijän kanssa, kerroin hänelle optimointiideani, johon hän sanoi minulle:
- Voi, et nähnyt, mitä meillä oli viime vuonna!
- Mitä sitten?
"Nyt se on paljon parempi kuin se oli."
- Eli eikö se voi enää parantua?
- Mitä varten?

Hyvä kysymys - miksi? Tuntuu kuin nyt olisi paremmin kuin ennen, silloin kaikki on tarpeeksi hyvin. Tämä johtaa vastuun puutteeseen, mikä on periaatteessa täysin normaalia. Kuten sanoin, tekninen ryhmä oli hieman sivussa. Yhtiö uskoi, että niiden pitäisi olla olemassa, mutta kukaan ei koskaan asettanut standardeja. Tekninen tuki ei koskaan nähnyt SLA:ta, joten se oli melko "hyväksyttävä" ryhmälle (ja tämä vaikutti minuun eniten):

• 12 sekunnin lataus;
• 5-10 minuutin seisonta-aika jokaisella julkaisulla;
• Kriittisten ongelmien vianmääritys kestää päiviä ja viikkoja;
• päivystyshenkilöstön puute 24x7 / päivystys.

Kukaan ei ole koskaan yrittänyt kysyä, miksi emme tekisi sitä paremmin, eikä kukaan ole koskaan ymmärtänyt, että sen ei tarvitse olla näin.

Bonuksena oli vielä yksi ongelma: kokemuksen puute. Seniorit lähtivät, ja jäljelle jäänyt nuori joukkue kasvoi edellisen hallinnon aikana ja sai sen myrkytyksen.

Kaiken tämän lisäksi ihmiset myös pelkäsivät epäonnistumista ja näyttäytymistä epäpäteviltä. Tämä ilmenee siinä tosiasiassa, että ensinnäkin he ei missään olosuhteissa pyytänyt apua. Kuinka monta kertaa olemme keskustelleet ryhmässä ja yksilöllisesti, ja olen sanonut: "Kysy, jos et tiedä, miten jotain tehdään." Luotan itseeni ja tiedän, että voin ratkaista minkä tahansa ongelman, mutta se vie aikaa. Siksi, jos voin kysyä joltakin, joka tietää kuinka ratkaista se 10 minuutissa, kysyn. Mitä vähemmän kokemusta sinulla on, sitä enemmän pelkäät kysyä, koska luulet, että sinua pidetään epäpätevänä.

Tämä kysymysten pelko ilmenee mielenkiintoisin tavoin. Kysyt esimerkiksi: "Kuinka sinulla menee tämä tehtävä?" - "Pari tuntia jäljellä, olen jo lopettamassa." Seuraavana päivänä kysyt uudelleen, saat vastauksen, että kaikki on hyvin, mutta oli yksi ongelma, se on varmasti valmis päivän loppuun mennessä. Kulkee toinen päivä, ja tämä jatkuu, kunnes sinut on kiinnitetty seinään ja pakotettu puhumaan jonkun kanssa. Ihminen haluaa ratkaista ongelman itse; hän uskoo, että jos hän ei ratkaise sitä itse, se on suuri epäonnistuminen.

Siksi kehittäjät liioittivat arvioita. Se oli sama anekdootti, kun he keskustelivat tietystä tehtävästä, he antoivat minulle sellaisen kuvan, että olin hyvin yllättynyt. Mihin minulle kerrottiin, että kehittäjän arvioihin kehittäjä sisällyttää ajan, jolloin lippu palautetaan QA:lta, koska he löytävät sieltä virheitä, ja ajan, joka PR:n vie, ja ajan, jonka ihmiset, joiden pitäisi tarkistaa se on kiireinen - eli kaikki , mikä tahansa on mahdollista.

Toiseksi ihmiset, jotka pelkäävät näyttävänsä epäpäteviltä ylianalysoida. Kun sanot, mitä tarkalleen pitää tehdä, se alkaa: "Ei, entä jos ajattelemme sitä täällä?" Tässä mielessä yrityksemme ei ole ainutlaatuinen, tämä on nuorille tavallinen ongelma.

Vastauksena esitin seuraavat käytännöt:

• Sääntö 30 minuuttia. Jos et pysty ratkaisemaan ongelmaa puolessa tunnissa, pyydä jotakuta auttamaan. Tämä toimii vaihtelevalla menestyksellä, koska ihmiset eivät vieläkään kysy, mutta prosessi on ainakin alkanut.
• Poista kaikki paitsi olemus, arvioitaessa tehtävän suorittamisen määräaikaa, eli laske vain kuinka kauan koodin kirjoittaminen kestää.
• Jatkuva oppiminen niille, jotka ylianalysoivat. Se on vain jatkuvaa työtä ihmisten kanssa.

Päivä kuudeskymmenes

Kun tein tätä kaikkea, oli aika selvittää budjetti. Tietysti löysin paljon mielenkiintoisia asioita siitä, mihin käytimme rahamme. Meillä oli esimerkiksi kokonainen teline erillisessä konesalissa, jossa oli yksi FTP-palvelin, jota yksi asiakas käytti. Kävi ilmi, että "... muutimme, mutta hän pysyi sellaisena, emme vaihtaneet häntä." Se oli 2 vuotta sitten.

Erityisen kiinnostava oli lasku pilvipalveluista. Uskon, että suurin syy korkeaan pilvilaskuun on kehittäjät, joilla on ensimmäistä kertaa elämässään rajoittamaton pääsy palvelimiin. Heidän ei tarvitse kysyä: "Anna minulle testipalvelin", he voivat ottaa sen itse. Lisäksi kehittäjät haluavat aina rakentaa niin hienon järjestelmän, että Facebook ja Netflix ovat kateellisia.

Mutta kehittäjillä ei ole kokemusta palvelimien ostamisesta ja taitoa määrittää tarvittava palvelimien koko, koska he eivät tarvinneet sitä aiemmin. Ja he eivät yleensä ymmärrä skaalautuvuuden ja suorituskyvyn eroa.

Varaston tulokset:

• Poistuimme samasta datakeskuksesta.
• Irtisanoimme sopimuksen 3 hirsipalvelun kanssa. Koska meillä oli niitä 5 - jokainen kehittäjä, joka alkoi pelata jollakin, otti uuden.
• 7 AWS-järjestelmää suljettiin. Jälleen, kukaan ei pysäyttänyt kuolleita projekteja, ne kaikki jatkoivat työtä.
• Ohjelmistokustannukset alenevat 6 kertaa.

Päivä seitsemänkymmentäviisi

Aika kului, ja kahden ja puolen kuukauden kuluttua minun piti tavata hallitus. Hallituksemme ei ole parempi tai huonompi kuin muut; kuten kaikki hallitukset, se haluaa tietää kaiken. Ihmiset sijoittavat rahaa ja haluavat ymmärtää, kuinka paljon toimintamme mahtuu asetettuihin KPI-arvoihin.

Hallitus saa kuukausittain paljon tietoa: käyttäjien määrä, heidän kasvunsa, mitä palveluita he käyttävät ja miten, suorituskyky ja tuottavuus sekä lopuksi sivujen keskimääräinen latausnopeus.

Ainoa ongelma on, että uskon keskiarvon olevan puhdasta pahaa. Mutta tätä on erittäin vaikea selittää hallitukselle. He ovat tottuneet toimimaan aggregoiduilla numeroilla, eivät esimerkiksi latausaikojen leviämisellä sekunnissa.

Tässä oli mielenkiintoisia kohtia. Sanoin esimerkiksi, että meidän on jaettava liikenne eri verkkopalvelimien välillä sisällön tyypin mukaan.

Toisin sanoen ColdFusion käy Jettyn ​​ja nginxin läpi ja käynnistää sivut. Ja kuvat, JS ja CSS käyvät läpi erillisen nginxin omilla kokoonpanoillaan. Tämä on melko yleinen käytäntö, josta puhun kirjoitin pari vuotta sitten. Tämän seurauksena kuvat latautuvat paljon nopeammin ja... keskimääräinen latausnopeus on kasvanut 200 ms.

Tämä tapahtui, koska kaavio on rakennettu Jettyn ​​mukana tulevien tietojen perusteella. Eli nopea sisältö ei sisälly laskelmaan - keskiarvo on hypännyt. Tämä oli meille selvää, nauroimme, mutta kuinka voimme selittää hallitukselle, miksi teimme jotain ja asiat pahenivat 12 prosenttia?

Päivä kahdeksankymmentäviisi

Kolmannen kuukauden lopussa tajusin, että oli yksi asia, jota en ollut laskenut ollenkaan: aika. Kaikki mistä puhuin vie aikaa.

Tämä on oikea viikkokalenterini - vain työviikko, ei kovin kiireinen. Aika ei riitä kaikkeen. Siksi jälleen kerran sinun on rekrytoitava ihmisiä, jotka auttavat sinua selviytymään ongelmista.

Johtopäätös

Ei siinä kaikki. Tässä tarinassa en ole edes perehtynyt siihen, kuinka työskentelimme tuotteen kanssa ja yritimme virittää yleiseen aaltoon tai kuinka integroimme teknisen tuen tai kuinka ratkaisimme muita teknisiä ongelmia. Opin esimerkiksi aivan vahingossa, että tietokannan suurimmissa taulukoissa emme käytä SEQUENCE. Meillä on itsekirjoitettu toiminto nextID, ja sitä ei käytetä tapahtumassa.

Oli miljoona muuta samanlaista asiaa, joista voisimme puhua pitkään. Mutta tärkein asia, joka on vielä sanottava, on kulttuuri.

Kulttuuri tai sen puute johtaa kaikkiin muihin ongelmiin. Yritämme rakentaa kulttuuria, jossa ihmiset:

• eivät pelkää epäonnistumisia;
• oppia virheistä;
• tehdä yhteistyötä muiden tiimien kanssa;
• tehdä aloite;
• ottaa vastuuta;
• tervetuloa tulos tavoitteeksi;
• juhlimassa menestystä.

Tämän myötä kaikki muu tulee.

Leon Fire Twitterissä, facebook ja edelleen keskikokoinen.

Perinnössä on kaksi strategiaa: välttää sen kanssa työskentelemistä hinnalla millä hyvänsä tai voittaa rohkeasti siihen liittyvät vaikeudet. Me c DevOpsConf Otamme toisen polun, muutamme prosesseja ja lähestymistapoja. Liity meihin youtube, postitus lista и sähke, ja toteutamme yhdessä DevOps-kulttuurin.

Lähde: will.com