Vitað er að hæfni CTO reynist aðeins í annað skiptið sem hann gegnir þessu hlutverki. Því það er eitt að vinna í fyrirtæki í nokkur ár, þróast með því og vera í sama menningarlegu samhengi og fá smám saman meiri ábyrgð. Og það er allt annað að koma beint í stöðu tæknistjóra hjá fyrirtæki með eldri farangur og fullt af vandamálum snyrtilega sópað undir teppið.

Í þessum skilningi, upplifun Leon Fire, sem hann deildi á DevOpsConf, ekki beinlínis einstakt, en margfaldað með reynslu hans og fjölda mismunandi hlutverka sem hann náði að prófa á 20 árum, er það mjög gagnlegt. Fyrir neðan klippið er tímaröð atburða yfir 90 daga og fullt af sögum sem gaman er að hlæja að þegar þær koma fyrir einhvern annan, en sem er ekki svo gaman að horfast í augu við í eigin persónu.

Leon talar mjög litríkt á rússnesku þannig að ef þú hefur 35-40 mínútur mæli ég með að horfa á myndbandið. Textaútgáfa til að spara tíma hér að neðan.

Fyrsta útgáfa skýrslunnar var vel skipulögð lýsing á vinnu með fólki og ferlum, með gagnlegum ráðleggingum. En hún kom ekki öllum á óvart sem kom upp á leiðinni. Því breytti ég sniðinu og kynnti vandamálin sem skutust upp fyrir framan mig eins og tjakkur í nýja fyrirtækinu og aðferðir til að leysa þau í tímaröð.

Einum mánuði áður

Eins og margar góðar sögur byrjaði þessi á áfengi. Við sátum með vinum á bar og eins og við var að búast meðal upplýsingatæknisérfræðinga grétu allir yfir vandamálum sínum. Einn þeirra var nýbúinn að skipta um vinnu og var að tala um vandamál sín með tæknina, og fólkið og liðið. Því meira sem ég hlustaði, því betur áttaði ég mig á því að hann ætti bara að ráða mig, því þetta eru svona vandamál sem ég hef verið að leysa síðustu 15 árin. Ég sagði honum það og daginn eftir hittumst við í vinnuumhverfi. Fyrirtækið hét Teaching Strategies.

Teaching Strategies er leiðandi á markaði í námskrá fyrir mjög ung börn frá fæðingu til þriggja ára. Hið hefðbundna „pappírs“ fyrirtæki er nú þegar 40 ára og stafræna SaaS útgáfan af pallinum er 10 ára.Tiltölulega nýlega hófst ferlið við að laga stafræna tækni að stöðlum fyrirtækja. „Nýja“ útgáfan kom á markað árið 2017 og var næstum eins og sú gamla, bara hún virkaði verr.

Það áhugaverðasta er að umferð þessa fyrirtækis er mjög fyrirsjáanleg - frá degi til dags, frá ári til árs er hægt að spá mjög skýrt fyrir um hversu margir munu koma og hvenær. Til dæmis, milli 13 og 15:XNUMX fara öll börn í leikskólum að sofa og kennarar byrja að slá inn upplýsingar. Og þetta gerist á hverjum degi, nema um helgar, því nánast enginn vinnur um helgar.

Þegar ég lít aðeins fram á veginn tek ég eftir því að ég hóf störf á því tímabili sem mest árferði var, sem er áhugavert af ýmsum ástæðum.

Vettvangurinn, sem virtist vera aðeins 2 ára gamall, var með sérkennilegum stafla: ColdFusion & SQL Server frá 2008. ColdFusion, ef þú veist það ekki, og líklegast veist þú það ekki, er PHP fyrirtækja sem kom út um miðjan tíunda áratuginn og síðan þá hef ég ekki einu sinni heyrt um það. Einnig voru: Ruby, MySQL, PostgreSQL, Java, Go, Python. En aðaleiningin keyrði á ColdFusion og SQL Server.

Vandamál

Því meira sem ég ræddi við starfsmenn fyrirtækisins um vinnuna og hvaða vandamál upp komu, því betur áttaði ég mig á því að vandamálin voru ekki aðeins tæknilegs eðlis. Allt í lagi, tæknin er gömul - og þeir unnu ekki á henni, en það voru vandamál með teymið og ferlana og fyrirtækið fór að skilja þetta.

Að venju sátu tæknimenn þeirra úti í horni og unnu einhvers konar vinnu. En fleiri og fleiri viðskipti fóru að fara í gegnum stafrænu útgáfuna. Þess vegna, á síðasta ári áður en ég hóf störf, komu nýir fram í fyrirtækinu: stjórn, CTO, CPO og QA forstöðumaður. Það er, fyrirtækið byrjaði að fjárfesta í tæknigeiranum.

Ummerki um þunga arfleifð voru ekki aðeins í kerfunum. Fyrirtækið var með arfleifðarferli, arfleifð fólk, arfleifð menningu. Öllu þessu varð að breyta. Ég hélt að það væri örugglega ekki leiðinlegt og ákvað að prófa það.

Tveimur dögum áður

Tveimur dögum áður en ég byrjaði í nýju starfi mætti ég á skrifstofuna, fyllti út síðustu pappírana, hitti teymið og komst að því að teymið var að glíma við vandamál á þeim tíma. Það var að meðalhleðslutími síðu fór í 4 sekúndur, það er 2 sinnum.

Af línuritinu að dæma gerðist greinilega eitthvað og það er ekki ljóst hvað. Í ljós kom að vandamálið var netleynd í gagnaverinu: 5 ms leynd í gagnaverinu breyttist í 2 s fyrir notendur. Ég vissi ekki hvers vegna þetta gerðist, en í öllum tilvikum varð vitað að vandamálið var í gagnaverinu.

Dagur eitt

Tveir dagar liðu og á fyrsta vinnudegi mínum uppgötvaði ég að vandamálið var ekki horfið.

Í tvo daga hlóðust síður notenda að meðaltali á 4 sekúndum. Ég spyr hvort þeir hafi fundið hvað vandamálið er.

- Já, við opnuðum miða.
- OG?
- Jæja, þeir hafa ekki svarað okkur ennþá.

Svo áttaði ég mig á því að allt sem mér hafði verið sagt áður var bara lítill toppur af ísjakanum sem ég þurfti að berjast við.

Það er góð tilvitnun sem passar mjög vel við þetta:

"Stundum til að breyta tækni þarftu að breyta skipulaginu."

En þar sem ég hóf störf á mesta annatíma ársins þurfti ég að skoða báða möguleikana til að leysa vandamálið: bæði fljótlega og til langs tíma. Og byrjaðu á því sem er mikilvægt núna.

Dagur þrjú

Svo, hleðsla varir í 4 sekúndur, og frá 13 til 15 stærstu tindar.

Á þriðja degi á þessu tímabili leit niðurhalshraðinn svona út:

Frá mínu sjónarhorni virkaði ekkert. Frá sjónarhóli allra annarra gekk þetta aðeins hægar en venjulega. En það gerist bara ekki svona - þetta er alvarlegt vandamál.

Ég reyndi að sannfæra teymið, sem þeir svöruðu að þeir þyrftu einfaldlega fleiri netþjóna. Þetta er auðvitað lausn á vandanum, en það er ekki alltaf sú eina og árangursríkasta. Ég spurði hvers vegna það væru ekki nógu margir netþjónar, hvað væri umferðarmagnið. Ég framreiknaði gögnin og komst að því að við höfum um það bil 150 beiðnir á sekúndu, sem í grundvallaratriðum fellur innan skynsamlegra marka.

En við megum ekki gleyma því að áður en þú færð rétta svarið þarftu að spyrja réttu spurningarinnar. Næsta spurning mín var: hversu marga framenda netþjóna höfum við? Svarið „hryggði mig svolítið“ - við vorum með 17 framendaþjóna!

— Ég skammast mín fyrir að spyrja, en 150 deilt með 17 gefur um það bil 8? Ertu að segja að hver server leyfi 8 beiðnir á sekúndu og ef á morgun eru 160 beiðnir á sekúndu, þá þurfum við 2 servera í viðbót?

Auðvitað þurftum við ekki fleiri netþjóna. Lausnin var í kóðanum sjálfum og á yfirborðinu:

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

Það var aðgerð getCurrentClass(), vegna þess að allt á síðunni virkar í samhengi við bekk - það er rétt. Og fyrir þessa eina aðgerð á hverri síðu voru 200+ beiðnir.

Lausnin á þennan hátt var mjög einföld, þú þurftir ekki einu sinni að endurskrifa neitt: bara ekki biðja um sömu upplýsingar aftur.

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

Ég var mjög ánægð því ég ákvað að á þriðja degi hefði ég fundið aðalvandamálið. Eins og ég var barnaleg var þetta bara eitt af mörgum vandamálum.

En að leysa þetta fyrsta vandamál lækkaði línuritið mun lægra.

Á sama tíma vorum við að gera aðrar hagræðingar. Það var margt í sjónmáli sem hægt var að laga. Til dæmis, á sama þriðja degi uppgötvaði ég að það væri skyndiminni í kerfinu eftir allt saman (ég hélt fyrst að allar beiðnir kæmu beint úr gagnagrunninum). Þegar ég hugsa um skyndiminni hugsa ég um staðlað Redis eða Memcached. En ég var sá eini sem hélt það, því það kerfi notaði MongoDB og SQL Server fyrir skyndiminni - það sama og gögnin voru bara lesin úr.

Dagur tíu

Fyrstu vikuna tókst mér á við vandamál sem þurfti að leysa núna. Einhvers staðar í annarri viku kom ég í fyrsta skipti í uppistandið til að eiga samskipti við liðið, sjá hvað var að gerast og hvernig allt ferlið gengi.

Eitthvað áhugavert uppgötvaðist aftur. Liðið samanstóð af: 18 þróunaraðilum; 8 prófunartæki; 3 stjórnendur; 2 arkitektar. Og allir tóku þátt í sameiginlegum helgisiðum, það er að segja meira en 30 manns mættu á uppistandið á hverjum morgni og sögðu frá því sem þeir gerðu. Ljóst er að fundurinn tók ekki 5 eða 15 mínútur. Enginn hlustaði á neinn því allir vinna á mismunandi kerfum. Í þessu formi voru 2-3 miðar á klukkustund fyrir snyrtingu þegar góður árangur.

Það fyrsta sem við gerðum var að skipta liðinu í nokkrar vörulínur. Fyrir mismunandi hluta og kerfi úthlutuðum við sérstökum teymum, sem innihéldu þróunaraðila, prófunaraðila, vörustjóra og viðskiptafræðinga.

Í kjölfarið fengum við:

Að draga úr uppistandi og fjöldamótum.
Efnisþekking á vörunni.
Tilfinning um eignarhald. Þegar fólk var að fikta í kerfum allan tímann vissi það að einhver annar þyrfti líklegast að vinna með gallana sína, en ekki þeir sjálfir.
Samvinna milli hópa. Óþarfur að segja að QA hafði ekki mikil samskipti við forritara áður, varan gerði sitt eigið o.s.frv. Nú hafa þeir sameiginlega ábyrgð.

Við lögðum aðallega áherslu á skilvirkni, framleiðni og gæði - þetta eru vandamálin sem við reyndum að leysa með umbreytingu liðsins.

Dagur ellefu

Í því ferli að breyta liðsskipaninni uppgötvaði ég hvernig á að telja SagaStig. 1 SP jafngilti einum degi og hver miði innihélt SP fyrir bæði þróun og QA, það er að minnsta kosti 2 SP.

Hvernig uppgötvaði ég þetta?

Við fundum villu: í einni af skýrslunum, þar sem upphafs- og lokadagsetning tímabilsins sem skýrsluna er þörf fyrir, er slegið inn, er síðasti dagurinn ekki tekinn með í reikninginn. Það er, einhvers staðar í beiðninni var ekki <=, heldur einfaldlega <. Mér var sagt að þetta væru þrír sögupunktar, þ.e 3 daga.

Eftir þetta:

Sögustigastigakerfið hefur verið endurskoðað. Nú er lagfæring fyrir minniháttar villur sem hægt er að fara fljótt í gegnum kerfið til notanda hraðar.
Við byrjuðum að sameina tengda miða fyrir þróun og prófun. Áður fyrr var hver miði, hver galla lokað vistkerfi, ekki bundið neinu öðru. Að breyta þremur hnöppum á einni síðu gæti hafa verið þrír mismunandi miðar með þremur mismunandi QA ferlum í stað eins sjálfvirks prófs á síðu.
Við byrjuðum að vinna með þróunaraðilum að aðferð til að meta launakostnað. Þrír dagar til að breyta einum hnappi er ekki fyndið.

Dagur tuttugasta

Einhvers staðar um miðjan fyrsta mánuðinn var ástandið aðeins stöðugt, ég áttaði mig á því hvað var í rauninni að gerast og fór þegar að horfa inn í framtíðina og hugsa um langtímalausnir.

Langtímamarkmið:

Stýrður vettvangur. Hundruð beiðna á hverri síðu eru ekki alvarlegar.
Fyrirsjáanleg þróun. Það voru reglulega umferðartoppar sem við fyrstu sýn tengdust ekki öðrum mæligildum - við þurftum að skilja hvers vegna þetta gerðist og læra að spá fyrir um.
Stækkun pallur. Starfsemin stækkar stöðugt, fleiri og fleiri notendur koma og umferð eykst.

Áður fyrr var oft sagt: „Við skulum endurskrifa allt á [tungumáli/ramma], allt mun virka betur!

Í flestum tilfellum virkar þetta ekki, það er gott ef endurskrifin virkar yfirleitt. Þess vegna þurftum við að búa til vegvísi - sérstaka stefnu sem sýnir skref fyrir skref hvernig viðskiptamarkmiðum verður náð (hvað við munum gera og hvers vegna), sem:

endurspeglar verkefni og markmið verkefnisins;
forgangsraðar helstu markmiðum;
inniheldur áætlun til að ná þeim.

Fyrir þetta hafði enginn rætt við liðið um tilgang breytinga. Þetta krefst réttra árangursmælinga. Í fyrsta skipti í sögu fyrirtækisins settum við KPI fyrir tæknihópinn og voru þessir vísbendingar bundnir við skipulag.

Það er að segja að KPI fyrir skipulagsheildir eru studdar af teymum og KPI teymi eru studdir af einstökum KPI. Annars, ef tæknilegir KPIs fara ekki saman við skipulagslega, þá draga allir sængina á sig.

Til dæmis er eitt af lykileinkennum skipulagsheilda að auka markaðshlutdeild með nýjum vörum.

Hvernig geturðu stutt það markmið að vera með fleiri nýjar vörur?

Í fyrsta lagi viljum við eyða meiri tíma í að þróa nýjar vörur í stað þess að laga galla. Þetta er rökrétt lausn sem auðvelt er að mæla.
Í öðru lagi viljum við styðja aukið viðskiptamagn, því því meiri markaðshlutdeild, því fleiri notendur og því meiri umferð.

Þá verða einstakir KPI sem hægt er að framkvæma innan hópsins til dæmis á þeim stað sem helstu gallarnir koma frá. Ef þú einbeitir þér sérstaklega að þessum hluta geturðu gengið úr skugga um að það séu mun færri gallar og þá mun tíminn til að þróa nýjar vörur og aftur til að styðja við skipulagslega KPI aukast.

Þannig verður hver ákvörðun, þar með talið endurskrifa kóða, að styðja við þau sérstöku markmið sem fyrirtækið hefur sett okkur (skipulagsvöxtur, nýir eiginleikar, ráðningar).

Í þessu ferli kom athyglisverður hlutur í ljós, sem varð frétt ekki aðeins fyrir tæknimenn heldur almennt í fyrirtækinu: allir miðar verða að vera einbeittir að minnsta kosti einum KPI. Það er að segja, ef vara segir að hún vilji búa til nýjan eiginleika ætti fyrsta spurningin að vera spurð: „Hvaða KPI styður þessi eiginleiki? Ef ekki, þá fyrirgefðu - það virðist vera óþarfa eiginleiki.

Dagur þrjátíu

Í lok mánaðarins uppgötvaði ég annan blæ: enginn í Ops teyminu mínu hefur nokkru sinni séð samningana sem við gerum við viðskiptavini. Þú gætir spurt hvers vegna þú þarft að sjá tengiliði.

Í fyrsta lagi vegna þess að SLA eru tilgreind í samningum.
Í öðru lagi eru SLAs öll mismunandi. Hver viðskiptavinur kom með sínar eigin kröfur og söludeildin skrifaði undir án þess að skoða.

Annar athyglisverður blæbrigði er að samningurinn við einn af stærstu viðskiptavinunum segir að allar hugbúnaðarútgáfur sem pallurinn styður verði að vera n-1, það er ekki nýjasta útgáfan heldur sú næstsíðasta.

Það er ljóst hversu langt við vorum frá n-1 ef pallurinn var byggður á ColdFusion og SQL Server 2008, sem var alls ekki lengur stutt í júlí.

Dagur fjörutíu og fimm

Um miðjan annan mánuð hafði ég nægan tíma til að setjast niður og gera gildistraumikortlagning algjörlega fyrir allt ferlið. Þetta eru nauðsynleg skref sem þarf að taka, frá því að búa til vöru til að koma henni til neytenda, og þeim þarf að lýsa eins ítarlega og hægt er.

Þú brýtur ferlið í litla bita og sérð hvað tekur of mikinn tíma, hvað er hægt að hagræða, bæta o.s.frv. Til dæmis, hversu langan tíma tekur það fyrir vörubeiðni að fara í gegnum snyrtingu, hvenær nær hún miða sem þróunaraðili getur tekið, QA o.s.frv. Svo þú skoðar hvert einstakt skref í smáatriðum og veltir fyrir þér hvað er hægt að hagræða.

Þegar ég gerði þetta kom tvennt í augun:

hátt hlutfall miða sem skilað var frá QA til baka til þróunaraðila;
endurskoðunarbeiðni tók of langan tíma.

Vandamálið var að þetta voru ályktanir eins og: Það virðist taka mikinn tíma, en við erum ekki viss um hversu langan tíma.

"Þú getur ekki bætt það sem þú getur ekki mælt."

Hvernig á að réttlæta hversu alvarlegt vandamálið er? Eyðir það dögum eða klukkustundum?

Til að mæla þetta bættum við nokkrum skrefum við Jira ferlið: „tilbúinn fyrir þróun“ og „tilbúinn fyrir QA“ til að mæla hversu lengi hver miði bíður og hversu oft hann fer aftur í ákveðið skref.

Við bættum líka við „í endurskoðun“ til að vita hversu margir miðar eru að meðaltali til skoðunar og út frá þessu geturðu byrjað að dansa. Við vorum með kerfismælingar, nú bættum við við nýjum mælingum og fórum að mæla:

Skilvirkni ferli: frammistöðu og skipulögð/afhent.
Gæði ferli: fjöldi galla, galla frá QA.

Það hjálpar virkilega að skilja hvað gengur vel og hvað gengur ekki vel.

Dagur fimmtugur

Þetta er auðvitað allt gott og áhugavert, en undir lok annars mánaðar gerðist eitthvað sem í grundvallaratriðum var fyrirsjáanlegt, þó ég hafi ekki búist við slíkum mælikvarða. Fólk fór að hætta vegna þess að æðstu stjórnin höfðu breyst. Nýtt fólk kom í stjórnun og fór að breyta öllu og það gamla hætti. Og yfirleitt í nokkurra ára fyrirtæki, allir eru vinir og allir þekkjast.

Búist var við því en umfang uppsagnanna var óvænt. Sem dæmi má nefna að á einni viku skiluðu tveir liðsstjórar uppsagnir samtímis af fúsum og frjálsum vilja. Þess vegna þurfti ég ekki aðeins að gleyma öðrum vandamálum heldur einbeita mér að búa til lið. Þetta er langt og erfitt vandamál að leysa, en það varð að takast á við það því ég vildi bjarga fólkinu sem eftir var (eða flest). Það þurfti einhvern veginn að bregðast við því að menn fóru til þess að halda móralnum í liðinu.

Fræðilega séð er þetta gott: ný manneskja kemur inn sem er með algjöra carte blanche, sem getur metið færni liðsins og skipt út starfsfólki. Reyndar geturðu ekki bara fengið nýtt fólk inn af svo mörgum ástæðum. Jafnvægi er alltaf þörf.

Gamalt og nýtt. Við þurfum að halda á gömlu fólki sem getur breytt og stutt verkefnið. En á sama tíma þurfum við að koma með nýtt blóð, við tölum um það aðeins síðar.
Reynsla. Ég talaði mikið við góða unglinga sem voru áhugasamir og vildu vinna með okkur. En ég gat ekki tekið þá að mér vegna þess að það voru ekki nógu margir eldri til að styðja yngri unglingana og vera leiðbeinendur fyrir þá. Fyrst þurfti að ráða toppliðið og þá aðeins unglingana.
Gulrót og stafur.

Ég hef ekki gott svar við spurningunni um hvað sé rétt jafnvægi, hvernig eigi að viðhalda því, hversu mörgum eigi að halda og hversu mikið eigi að ýta á. Þetta er eingöngu einstaklingsbundið ferli.

Dagur fimmtíu og einn

Ég fór að skoða liðið vel til að skilja hver ég ætti og enn og aftur minntist ég:

"Flest vandamál eru vandamál fólks."

Ég hef komist að því að liðið sem slíkt - bæði Dev og Ops - hefur þrjú stór vandamál:

Ánægja með núverandi stöðu mála.
Skortur á ábyrgð - vegna þess að enginn hefur nokkru sinni fært niðurstöður vinnu flytjenda til að hafa áhrif á viðskiptin.
Ótti við breytingar.

Breytingar taka þig alltaf út fyrir þægindarammann þinn og því yngra sem fólk er, því meira líkar það ekki við breytingar vegna þess að það skilur ekki hvers vegna og það skilur ekki hvernig. Algengasta svarið sem ég hef heyrt er: "Við höfum aldrei gert það." Þar að auki náði hún því marki að vera algjör fáránleiki - minnstu breytingar gætu ekki átt sér stað án þess að einhver væri reiður. Og það var sama hversu mikil áhrif breytingarnar höfðu á starf þeirra sagði fólk: „Nei, hvers vegna? Þetta gengur ekki."

En þú getur ekki batnað án þess að breyta neinu.

Ég átti algjörlega fáránlegt samtal við starfsmann, ég sagði honum hugmyndir mínar um hagræðingu, sem hann sagði mér:
- Ó, þú sást ekki hvað við áttum í fyrra!
- Og hvað?
„Nú er þetta miklu betra en það var“
— Svo, það getur ekki orðið betra?
- Til hvers?

Góð spurning - hvers vegna? Það er eins og það sé betra núna en það var, þá er allt nógu gott. Þetta leiðir til ábyrgðarleysis, sem er algjörlega eðlilegt í grundvallaratriðum. Tæknihópurinn var sem sagt aðeins á hliðarlínunni. Fyrirtækið taldi að þeir ættu að vera til, en enginn setti nokkurn tíma viðmiðin. Tæknileg aðstoð sá aldrei SLA, svo það var alveg "viðunandi" fyrir hópinn (og þetta sló mig mest):

12 sekúndur hleðsla;
5-10 mínútur í biðtíma í hverri útgáfu;
Úrræðaleit við mikilvæg vandamál tekur daga og vikur;
skortur á vaktmönnum allan sólarhringinn / á vakt.

Enginn hefur nokkurn tíma reynt að spyrja hvers vegna við gerum þetta ekki betur og enginn hefur nokkurn tíma áttað sig á því að þetta þarf ekki að vera svona.

Sem bónus var eitt vandamál í viðbót: skortur á reynslu. Öldungarnir fóru og unga liðið sem eftir var ólst upp undir fyrri stjórn og var eitrað fyrir því.

Ofan á allt þetta voru menn líka hræddir við að mistakast og virðast óhæfir. Þetta kemur fram í því að í fyrsta lagi þeir undir engum kringumstæðum beðið um hjálp. Hversu oft höfum við talað saman sem hópur og einstaklingsbundið, og ég hef sagt: "Spyrðu spurningar ef þú veist ekki hvernig á að gera eitthvað." Ég er öruggur með sjálfan mig og veit að ég get leyst hvaða vandamál sem er, en það mun taka tíma. Þess vegna, ef ég get spurt einhvern sem veit hvernig á að leysa það á 10 mínútum, mun ég spyrja. Því minni reynslu sem þú hefur, því hræddari ertu að spyrja vegna þess að þú heldur að þú verðir talinn óhæfur.

Þessi ótti við að spyrja spurninga kemur fram á áhugaverðan hátt. Til dæmis spyrðu: "Hvernig gengur þér með þetta verkefni?" - "Nokkrar klukkustundir eftir, ég er nú þegar að klára." Daginn eftir sem þú spyrð aftur færðu svarið að allt sé í lagi, en það var eitt vandamál, það verður örugglega tilbúið í lok dags. Enn einn dagur líður og þangað til þú ert fest við vegginn og neyddur til að tala við einhvern heldur þetta áfram. Einstaklingur vill leysa vandamál sjálfur; hann trúir því að ef hann leysir það ekki sjálfur verði það stór mistök.

Þess vegna framkvæmdaraðilar blása upp áætlanir. Það var sama sagan, þegar þeir voru að ræða ákveðið verkefni, gáfu þeir mér slíka mynd að ég varð mjög hissa. Sem mér var sagt að í áætlunum þróunaraðilans tekur verktaki með tímanum sem miðanum verður skilað frá QA, vegna þess að þeir munu finna villur þar, og þann tíma sem PR mun taka, og tímann á meðan fólkið sem ætti að skoða það verður upptekið - það er allt, hvað sem er mögulegt.

Í öðru lagi fólk sem óttast að sýnast óhæft ofgreina. Þegar þú segir hvað nákvæmlega þarf að gera, byrjar það: "Nei, hvað ef við hugsum um það hér?" Í þessum skilningi er fyrirtækið okkar ekki einstakt, þetta er staðlað vandamál fyrir ungt fólk.

Til að bregðast við, kynnti ég eftirfarandi starfshætti:

Regla 30 mínútur. Ef þú getur ekki leyst vandamálið á hálftíma skaltu biðja einhvern um að hjálpa. Þetta virkar með misjöfnum árangri, því fólk spyr samt ekki, en ferlið er að minnsta kosti hafið.
Útrýmdu öllu nema kjarnanum, við áætlanir um frest til að klára verkefni, það er að segja aðeins hversu langan tíma það tekur að skrifa kóðann.
Símenntun fyrir þá sem ofgreina. Þetta er bara stöðug vinna með fólki.

Dagur sextugur

Á meðan ég var að gera þetta allt var kominn tími til að reikna út fjárhagsáætlunina. Auðvitað fann ég margt áhugavert í því hvar við eyddum peningunum okkar. Til dæmis vorum við með heilan rekki í sérstakri gagnaver með einum FTP netþjóni, sem var notaður af einum viðskiptavin. Það kom í ljós að „... við fluttum, en hann var svona, við breyttum honum ekki.“ Það var fyrir 2 árum.

Sérstaklega vakti athygli frumvarpið um skýjaþjónustu. Ég tel að aðalástæðan fyrir háum skýjareikningi sé verktaki sem hafa ótakmarkaðan aðgang að netþjónum í fyrsta skipti á ævinni. Þeir þurfa ekki að spyrja: „Vinsamlegast gefðu mér prufuþjón,“ þeir geta tekið það sjálfir. Auk þess vilja verktaki alltaf byggja svo flott kerfi að Facebook og Netflix verða afbrýðisamir.

En verktaki hefur ekki reynslu í að kaupa netþjóna og kunnáttu til að ákvarða nauðsynlega stærð netþjóna, vegna þess að þeir þurftu það ekki áður. Og þeir skilja venjulega ekki alveg muninn á sveigjanleika og frammistöðu.

Niðurstöður birgða:

Við yfirgáfum sama gagnaverið.
Við sögðum upp samningnum við 3 logþjónustur. Vegna þess að við áttum 5 þeirra - hver þróunaraðili sem byrjaði að spila með eitthvað tók nýjan.
7 AWS kerfum var lokað. Aftur stöðvaði enginn hin dauðu verkefni; þau héldu áfram að vinna.
Lækkaði hugbúnaðarkostnað um 6 sinnum.

Dagur sjötíu og fimm

Tíminn leið og eftir tvo og hálfan mánuð þurfti ég að hitta stjórnina. Stjórnin okkar er hvorki betri né verri en önnur, eins og allar stjórnir vill hún vita allt. Fólk fjárfestir peninga og vill skilja hversu mikið það sem við gerum passar inn í settar KPIs.

Stjórnin fær miklar upplýsingar í hverjum mánuði: fjölda notenda, vöxt þeirra, hvaða þjónustu þeir nota og hvernig, afköst og framleiðni og að lokum meðalhleðsluhraði síðunnar.

Vandamálið er bara að ég trúi því að meðaltalið sé hrein illska. En það er mjög erfitt að útskýra þetta fyrir stjórninni. Þeir eru vanir að starfa með samanteknum tölum, en ekki til dæmis með dreifingu hleðslutíma á sekúndu.

Það voru áhugaverðir punktar í þessu sambandi. Til dæmis sagði ég að við þurfum að skipta umferð á milli aðskildra netþjóna eftir því hvers konar efni er.

Það er, ColdFusion fer í gegnum Jetty og nginx og opnar síðurnar. Og myndir, JS og CSS fara í gegnum sérstakan nginx með eigin stillingum. Þetta er nokkuð hefðbundin venja sem ég er að tala um skrifaði fyrir nokkrum árum síðan. Fyrir vikið hlaðast myndir mun hraðar og... meðalhleðsluhraði hefur aukist um 200 ms.

Þetta gerðist vegna þess að línuritið er byggt á gögnunum sem fylgja Jetty. Það er, hratt efni er ekki innifalið í útreikningnum - meðalgildið hefur hoppað. Þetta var okkur ljóst, við hlógum, en hvernig getum við útskýrt fyrir stjórninni hvers vegna við gerðum eitthvað og hlutirnir versnuðu um 12%?

Dagur áttatíu og fimm

Í lok þriðja mánaðar áttaði ég mig á því að það var eitt sem ég hafði alls ekki reiknað með: tíma. Allt sem ég talaði um tekur tíma.

Þetta er alvöru vikudagatalið mitt - bara vinnuvika, ekki mjög upptekin. Það er ekki nægur tími fyrir allt. Þess vegna, aftur, þú þarft að ráða fólk sem mun hjálpa þér að takast á við vandamálin.

Ályktun

Það er ekki allt. Í þessari sögu hef ég ekki einu sinni komist að því hvernig við unnum með vöruna og reyndum að stilla inn á almenna bylgjuna, eða hvernig við samþættum tæknilega aðstoð eða hvernig við leystum önnur tæknileg vandamál. Til dæmis lærði ég alveg óvart að á stærstu töflunum í gagnagrunninum notum við ekki SEQUENCE. Við erum með sjálfskrifað hlutverk nextID, og það er ekki notað í viðskiptum.

Það voru milljón fleiri svipaðir hlutir sem við gætum talað um í langan tíma. En það mikilvægasta sem enn þarf að segja er menningin.

Það er menning eða skortur á henni sem leiðir til allra annarra vandamála. Við erum að reyna að byggja upp menningu þar sem fólk:

eru ekki hræddir við mistök;
læra af mistökum;
vinna með öðrum liðum;
taka frumkvæði;
taka ábyrgð;
fagna niðurstöðunni sem markmiði;
fagna árangri.

Með þessu mun allt annað koma.

Leon Fire á twitter, Facebook og miðlungs.

Það eru tvær aðferðir varðandi arfleifð: forðastu að vinna með það hvað sem það kostar, eða sigrast á tilheyrandi erfiðleikum. Við c DevOpsConf Við erum að fara aðra leiðina, breyta ferlum og nálgunum. Vertu með okkur áfram YouTube, Póstlisti и símskeyti, og saman munum við innleiða DevOps menningu.

Heimild: www.habr.com

Erfðir eldri kerfa og ferla eða Fyrstu 90 dagarnir sem tæknistjóri