Oni scias, ke la kompetenteco de la CTO estas provita nur la duan fojon, kiam li plenumas ĉi tiun rolon. Ĉar unu afero estas labori en firmao dum pluraj jaroj, evolui kun ĝi kaj, estante en la sama kultura kunteksto, iom post iom ricevi pli da respondeco. Kaj estas tute alia veni rekte en la pozicion de teknika direktoro ĉe firmao kun heredaĵa pakaĵo kaj aro da problemoj bonorde balaitaj sub la tapiŝo.

En ĉi tiu senso, la sperto de Leon Fire, kiun li dividis sur DevOpsConf, ne ĝuste unika, sed multobligita per lia sperto kaj la nombro da malsamaj roloj, kiujn li sukcesis provi dum 20 jaroj, ĝi estas tre utila. Sub la tranĉo estas kronologio de eventoj dum 90 tagoj kaj multaj rakontoj, pri kiuj estas amuza ridi, kiam ili okazas al iu alia, sed kiuj ne estas tiel amuzaj por alfronti persone.

Leono parolas tre bunte en la rusa, do se vi havas 35-40 minutojn, mi rekomendas spekti la videon. Teksta versio por ŝpari tempon sube.

La unua versio de la raporto estis bone strukturita priskribo pri laboro kun homoj kaj procezoj, enhavanta utilajn rekomendojn. Sed ŝi ne transdonis ĉiujn surprizojn, kiuj estis renkontitaj survoje. Tial mi ŝanĝis la formaton kaj prezentis la problemojn, kiuj aperis antaŭ mi kiel fanto-en-kesto en la nova firmao, kaj metodojn por solvi ilin en kronologia ordo.

Unu monaton antaŭe

Kiel multaj bonaj rakontoj, ĉi tiu komenciĝis per alkoholo. Ni sidis kun amikoj en drinkejo, kaj kiel atendite inter IT-specialistoj, ĉiuj ploris pri siaj problemoj. Unu el ili ĵus ŝanĝis laboron kaj parolis pri siaj problemoj kun teknologio, kaj kun homoj, kaj kun la teamo. Ju pli mi aŭskultis, des pli mi rimarkis, ke li simple dungi min, ĉar ĉi tiuj estas la tipoj de problemoj, kiujn mi solvis dum la lastaj 15 jaroj. Mi diris tion al li, kaj la sekvan tagon ni renkontis en labormedio. La firmao estis nomita Teaching Strategies.

Teaching Strategies estas merkatgvidanto en instruplano por tre junaj infanoj de naskiĝo ĝis tri jaroj. La tradicia "papera" firmao jam aĝas 40 jarojn, kaj la cifereca SaaS-versio de la platformo estas 10 jarojn aĝa. Relative lastatempe komenciĝis la procezo de adapto de cifereca teknologio al kompaniaj normoj. La "nova" versio lanĉita en 2017 kaj estis preskaŭ kiel la malnova, nur ĝi funkciis pli malbone.

La plej interesa afero estas, ke la trafiko de ĉi tiu kompanio estas tre antaŭvidebla - de tago al tago, de jaro al jaro, vi povas tre klare antaŭdiri kiom da homoj venos kaj kiam. Ekzemple, inter la 13-a kaj la 15-a horo ĉiuj infanoj en infanĝardenoj enlitiĝas kaj instruistoj komencas enigi informojn. Kaj tio okazas ĉiutage, krom semajnfinoj, ĉar preskaŭ neniu laboras semajnfine.

Rigardante iom antaŭen, mi rimarkos, ke mi komencis mian laboron dum la periodo de la plej alta ĉiujara trafiko, kiu estas interesa pro diversaj kialoj.

La platformo, kiu ŝajnis esti nur 2-jara, havis strangan stakon: ColdFusion & SQL Server de 2008. ColdFusion, se vi ne scias, kaj plej verŝajne vi ne scias, estas entreprena PHP, kiu aperis meze de la 90-aj jaroj, kaj ekde tiam mi eĉ ne aŭdis pri ĝi. Ankaŭ estis: Ruby, MySQL, PostgreSQL, Java, Go, Python. Sed la ĉefa monolito funkciis per ColdFusion kaj SQL Server.

Problemoj

Ju pli mi parolis kun firmaaj dungitoj pri la laboro kaj kiaj problemoj estis renkontitaj, des pli mi rimarkis, ke la problemoj ne estis nur teknikaj. Bone, la teknologio estas malnova - kaj ili ne funkciis pri ĝi, sed estis problemoj kun la teamo kaj kun la procezoj, kaj la kompanio komencis kompreni ĉi tion.

Tradicie, iliaj teknikistoj sidis en la angulo kaj faris ian laboron. Sed pli kaj pli da komerco komencis trapasi la ciferecan version. Tial, en la lasta jaro antaŭ ol mi eklaboris, novaj aperis en la firmao: estraro de direktoroj, CTO, CPO kaj QA-direktoro. Tio estas, la kompanio komencis investi en la teknologia sektoro.

Spuroj de peza heredaĵo estis ne nur en la sistemoj. La firmao havis heredaĵprocezojn, heredaĵhomojn, heredaĵkulturon. Ĉio ĉi devis esti ŝanĝita. Mi pensis, ke ĝi certe ne enuos, kaj decidis provi ĝin.

Du tagojn antaŭe

Du tagojn antaŭ ol komenci novan laboron, mi alvenis al la oficejo, plenigis la lastan paperaĵon, renkontis la teamon kaj malkovris, ke la teamo tiutempe luktas kun problemo. Estis, ke la averaĝa paĝa ŝarĝotempo saltis al 4 sekundoj, tio estas, 2 fojojn.

Juĝante laŭ la grafikaĵo, io klare okazis, kaj ne estas klare kio. Montriĝis, ke la problemo estis reta latenco en la datumcentro: 5 ms latenco en la datumcentro fariĝis 2 s por uzantoj. Mi ne sciis kial tio okazis, sed ĉiukaze oni sciis, ke la problemo estas en la datumcentro.

Unua tago

Du tagoj pasis kaj en mia unua labortago mi malkovris, ke la problemo ne malaperis.

Dum du tagoj, la paĝoj de uzantoj ŝarĝis averaĝe en 4 sekundoj. Mi demandas ĉu ili trovis, kio estas la problemo.

- Jes, ni malfermis bileton.
- kaj?
- Nu, ili ankoraŭ ne respondis al ni.

Tiam mi konstatis, ke ĉio, pri kio mi antaŭe estis rakontita, estis nur malgranda pinto de la glacimonto, kiun mi devis batali.

Estas bona citaĵo, kiu tre bone kongruas kun ĉi tio:

"Foje por ŝanĝi teknologion oni devas ŝanĝi la organizon."

Sed ĉar mi komencis labori en la plej okupata tempo de la jaro, mi devis rigardi ambaŭ eblojn por solvi la problemon: kaj rapide kaj longtempe. Kaj komencu per kio estas kritika nun.

Tria tago

Do, ŝarĝo daŭras 4 sekundojn, kaj de 13 ĝis 15 la plej grandaj pintoj.

En la tria tago dum ĉi tiu tempodaŭro, la elŝuta rapideco aspektis jene:

El mia vidpunkto tute nenio funkciis. El ĉies vidpunkto ĝi funkciis iom pli malrapide ol kutime. Sed ĝi simple ne okazas tiel—ĝi estas grava problemo.

Mi provis konvinki la teamon, al kiu ili respondis, ke ili simple bezonas pli da serviloj. Ĉi tio, kompreneble, estas solvo al la problemo, sed ĝi ne ĉiam estas la sola kaj plej efika. Mi demandis, kial ne estas sufiĉe da serviloj, kia estis la volumo de trafiko. Mi eksterpolis la datumojn kaj trovis, ke ni havas proksimume 150 petojn por sekundo, kio principe estas ene de raciaj limoj.

Sed ni ne devas forgesi, ke antaŭ ol vi ricevas la ĝustan respondon, vi devas demandi la ĝustan demandon. Mia sekva demando estis: kiom da frontendaj serviloj ni havas? La respondo "iom konfuzis min" - ni havis 17 frontend-servilojn!

— Mi embarasas demandi, sed 150 dividita per 17 donas proksimume 8? Ĉu vi diras, ke ĉiu servilo permesas 8 petojn sekundo, kaj se morgaŭ estos 160 petoj sekundo, ni bezonos 2 pliajn servilojn?

Kompreneble, ni ne bezonis pliajn servilojn. La solvo estis en la kodo mem, kaj sur la surfaco:

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

Estis funkcio getCurrentClass(), ĉar ĉio en la retejo funkcias en la kunteksto de klaso - ĝuste. Kaj por ĉi tiu unu funkcio sur ĉiu paĝo estis 200+ petoj.

La solvo tiamaniere estis tre simpla, vi eĉ ne devis reverki ion: simple ne petu denove la samajn informojn.

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

Mi estis tre feliĉa ĉar mi decidis, ke nur en la tria tago mi trovis la ĉefan problemon. Kiel mi estis naiva, ĉi tio estis nur unu el multaj problemoj.

Sed solvi ĉi tiun unuan problemon faligis la grafeon multe pli malalte.

Samtempe, ni faris aliajn optimumojn. Estis multaj aferoj en vido, kiuj povus esti riparitaj. Ekzemple, en la sama tria tago mi malkovris, ke ja estas kaŝmemoro en la sistemo (komence mi pensis, ke ĉiuj petoj venas rekte el la datumbazo). Kiam mi pensas pri kaŝmemoro, mi pensas pri norma Redis aŭ Memcached. Sed mi estis la sola kiu pensis tion, ĉar tiu sistemo uzis MongoDB kaj SQL-Servilon por kaŝmemoro - la sama el kiu la datumoj ĵus estis legitaj.

Tago dek

La unuan semajnon mi traktis problemojn, kiujn oni devis solvi ĝuste nun. Ie en la dua semajno, mi venis al la stand-up por la unua fojo por komuniki kun la teamo, por vidi kio okazas kaj kiel la tuta procezo iras.

Io interesa denove estis malkovrita. La teamo konsistis el: 18 programistoj; 8 elproviloj; 3 administrantoj; 2 arkitektoj. Kaj ili ĉiuj partoprenis en komunaj ritoj, tio estas, pli ol 30 homoj venis al la stando ĉiumatene kaj rakontis kion ili faris. Estas klare, ke la kunveno ne daŭris 5 aŭ 15 minutojn. Neniu aŭskultis iun, ĉar ĉiuj laboras en malsamaj sistemoj. En ĉi tiu formo, 2-3 biletoj hore por prizorga sesio jam estis bona rezulto.

La unua afero, kiun ni faris, estis dividi la teamon en plurajn produktseriojn. Por malsamaj sekcioj kaj sistemoj, ni asignis apartajn teamojn, kiuj inkludis programistojn, testistojn, produktmanaĝerojn kaj komercajn analizistojn.

Kiel rezulto ni ricevis:

• Reduktante stand-ups kaj mitingoj.
• Subjekta scio pri la produkto.
• Sento de posedo. Kiam homoj ĉiam tuŝis sistemojn, ili sciis, ke iu alia plej verŝajne devos labori kun siaj cimoj, sed ne mem.
• Kunlaboro inter grupoj. Ne necesas diri, ke QA ne multe komunikis kun programistoj antaŭe, la produkto faris sian propran aferon, ktp. Nun ili havas komunan respondecon.

Ni ĉefe koncentriĝis pri efikeco, produktiveco kaj kvalito - ĉi tiuj estas la problemoj, kiujn ni provis solvi per la transformo de la teamo.

Tago dek unu

En la procezo ŝanĝi la teamstrukturon, mi malkovris kiel kalkuli rakontopunktoj. 1 SP estis egala al unu tago, kaj ĉiu bileto enhavis SP por kaj evoluo kaj QA, tio estas, almenaŭ 2 SP.

Kiel mi malkovris ĉi tion?

Ni trovis cimon: en unu el la raportoj, kie la komenca kaj findato de la periodo, por kiu la raporto estas bezonata, estas enmetitaj, la lastan tagon ne estas konsiderata. Tio estas, ie en la peto estis ne <=, sed simple <. Oni diris al mi, ke tio estas tri Story Points, tio estas 3 tagoj.

Post ĉi tio ni:

• La Story Points-taksa sistemo estis reviziita. Nun korektoj por etaj eraroj, kiuj povas esti rapide trapasitaj tra la sistemo, atingas la uzanton pli rapide.
• Ni komencis kunfandi rilatajn biletojn por disvolviĝo kaj testado. Antaŭe, ĉiu bileto, ĉiu cimo estis fermita ekosistemo, ne ligita al io alia. Ŝanĝi tri butonojn sur unu paĝo povus estinti tri malsamaj biletoj kun tri malsamaj QA-procezoj anstataŭ unu aŭtomatigita testo per paĝo.
• Ni komencis labori kun programistoj pri aliro al taksado de laborkostoj. Tri tagoj por ŝanĝi unu butonon ne estas amuza.

Tago dudeka

Ie en la mezo de la unua monato, la situacio iom stabiliĝis, mi komprenis, kio esence okazas, kaj jam komencis rigardi la estontecon kaj pensi pri longdaŭraj solvoj.

Longtempaj celoj:

• Administrita platformo. Centoj da petoj sur ĉiu paĝo ne estas seriozaj.
• Antaŭvideblaj tendencoj. Estis periodaj trafikpintoj, kiuj unuavide ne korelaciis kun aliaj metrikoj - ni bezonis kompreni kial tio okazis kaj lerni antaŭdiri.
• Pligrandigo de platformo. La komerco konstante kreskas, pli kaj pli da uzantoj venas, kaj trafiko pliiĝas.

En la pasinteco oni ofte diris: "Ni reverku ĉion en [lingvo/kadro], ĉio funkcios pli bone!"

Plejofte tio ne funkcias, estas bone se la reverko entute funkcias. Tial ni bezonis krei vojmapon - specifan strategion ilustrantan paŝon post paŝo kiel komercaj celoj estos atingitaj (kion ni faros kaj kial), kiuj:

• reflektas la mision kaj celojn de la projekto;
• prioritatas ĉefajn celojn;
• enhavas horaron por atingi ilin.

Antaŭ tio, neniu parolis al la teamo pri la celo de iuj ŝanĝoj faritaj. Ĉi tio postulas la ĝustajn sukcesajn mezurojn. Por la unua fojo en la historio de la kompanio, ni starigis KPIojn por la teknika grupo, kaj ĉi tiuj indikiloj estis ligitaj al organizaj.

Tio estas, organizaj KPIoj estas subtenataj de teamoj, kaj teamaj KPIoj estas subtenataj de individuaj KPIoj. Alie, se teknologiaj KPI-oj ne koincidas kun organizaj, tiam ĉiuj tiras la kovrilon sur sin.

Ekzemple, unu el la organizaj KPIoj pliigas merkatparton per novaj produktoj.

Kiel vi povas subteni la celon havi pli da novaj produktoj?

• Unue, ni volas pasigi pli da tempo disvolvante novajn produktojn anstataŭ ripari difektojn. Ĉi tio estas logika solvo, kiu estas facile mezurebla.
• Due, ni volas subteni pliigon de transakcia volumo, ĉar ju pli granda estas merkatparto, des pli da uzantoj kaj, sekve, des pli da trafiko.

Tiam individuaj KPI-oj, kiuj povas esti ekzekutitaj ene de la grupo, estos, ekzemple, en la loko, de kie venas la ĉefaj difektoj. Se vi fokusiĝas specife al ĉi tiu sekcio, vi povas certigi, ke estas multe malpli da difektoj, kaj tiam pliiĝos la tempo por disvolvi novajn produktojn kaj denove por subteni organizajn KPIojn.

Tiel, ĉiu decido, inkluzive de reverkado de kodo, devas subteni la specifajn celojn, kiujn la firmao starigis por ni (organiza kresko, novaj funkcioj, varbado).

Dum ĉi tiu procezo aperis interesa afero, kiu fariĝis novaĵo ne nur por teknikistoj, sed ĝenerale en la kompanio: ĉiuj biletoj devas esti koncentritaj al almenaŭ unu KPI. Tio estas, se produkto diras, ke ĝi volas fari novan funkcion, oni devas fari la unuan demandon: "Kion KPI subtenas ĉi tiu funkcio?" Se ne, do pardonu - ĝi ŝajnas nenecesa funkcio.

Tago tridek

Fine de la monato, mi malkovris alian nuancon: neniu en mia Ops-teamo iam vidis la kontraktojn, kiujn ni faras kun klientoj. Vi povas demandi kial vi bezonas vidi kontaktojn.

• Unue, ĉar SLAoj estas specifitaj en kontraktoj.
• Due, SLAoj estas ĉiuj malsamaj. Ĉiu kliento venis kun siaj propraj postuloj, kaj la venda fako subskribis sen rigardi.

Alia interesa nuanco estas, ke la kontrakto kun unu el la plej grandaj klientoj deklaras, ke ĉiuj programaj versioj subtenataj de la platformo devas esti n-1, tio estas, ne la plej nova versio, sed la antaŭlasta.

Estas klare kiom malproksime ni estis de n-1 se la platformo baziĝis sur ColdFusion kaj SQL Server 2008, kiuj tute ne plu estis subtenata en julio.

Tago kvardek kvin

Ĉirkaŭ la mezo de la dua monato mi havis sufiĉe da tempo por sidiĝi kaj fari valororiveretosurĵeto tute por la tuta procezo. Ĉi tiuj estas la necesaj paŝoj, kiuj devas esti faritaj, de kreado de produkto ĝis liverado de ĝi al la konsumanto, kaj ili devas esti priskribitaj kiel eble plej detale.

Vi rompas la procezon en malgrandajn pecojn kaj vidas, kio prenas tro da tempo, kio povas esti optimumigita, plibonigita, ktp. Ekzemple, kiom da tempo necesas por ke produkta peto trapasas tualeton, kiam ĝi atingas bileton, kiun programisto povas preni, QA, ktp. Do vi rigardas ĉiun individuan paŝon detale kaj pensas pri tio, kio povas esti optimumigita.

Kiam mi faris tion, du aferoj kaptis mian atenton:

• alta procento de biletoj resenditaj de QA reen al programistoj;
• tirpetaj recenzoj daŭris tro longe.

La problemo estis, ke ĉi tiuj estis konkludoj kiel: Ĝi ŝajnas preni multan tempon, sed ni ne certas kiom longe.

"Vi ne povas plibonigi tion, kion vi ne povas mezuri."

Kiel pravigi kiom serioza estas la problemo? Ĉu ĝi malŝparas tagojn aŭ horojn?

Por mezuri ĉi tion, ni aldonis kelkajn paŝojn al la Jira-procezo: "preta por dev" kaj "preta por QA" por mezuri kiom longe ĉiu bileto atendas kaj kiom da fojoj ĝi revenas al certa paŝo.

Ni ankaŭ aldonis "en revizio" por scii kiom da biletoj estas averaĝe por revizio, kaj de ĉi tio vi povas komenci danci. Ni havis sistemajn metrikojn, nun ni aldonis novajn metrikojn kaj komencis mezuri:

• Proceza efikeco: agado kaj planita/liverita.
• Proceza kvalito: nombro da difektoj, difektoj de QA.

Ĝi vere helpas kompreni kio iras bone kaj kio ne iras bone.

Tago kvindeka

Ĉio ĉi estas, kompreneble, bona kaj interesa, sed je la fino de la dua monato okazis io, kio principe estis antaŭvidebla, kvankam mi ne atendis tian skalon. Homoj komencis foriri ĉar la supera administrado ŝanĝiĝis. Novaj homoj venis en administradon kaj komencis ĉion ŝanĝi, kaj la malnovaj rezignis. Kaj kutime en firmao kiu aĝas plurajn jarojn, ĉiuj estas amikoj kaj ĉiuj konas unu la alian.

Ĉi tio estis atendita, sed la amplekso de la maldungoj estis neatendita. Ekzemple, en unu semajno du teamgvidantoj samtempe prezentis siajn demisiojn memvole. Tial mi devis ne nur forgesi aliajn problemojn, sed koncentriĝi pri tio kreante teamon. Ĉi tio estas longa kaj malfacile solvi problemon, sed ĝi devis esti traktita ĉar mi volis savi la homojn kiuj restis (aŭ la plimulton de ili). Necesis iel reagi al tio, ke homoj foriris por konservi moralon en la teamo.

En teorio, ĉi tio estas bona: nova persono venas, kiu havas kompletan karton, kiu povas taksi la kapablojn de la teamo kaj anstataŭigi personaron. Fakte, vi ne povas simple alporti novajn homojn pro tiom da kialoj. Ekvilibro ĉiam bezonas.

• Malnova kaj nova. Ni devas konservi maljunulojn, kiuj povas ŝanĝi kaj subteni la mision. Sed samtempe, ni devas alporti novan sangon, pri tio ni parolos iom poste.
• Sperto. Mi multe parolis kun bonaj junuloj, kiuj fervoris kaj volis labori kun ni. Sed mi ne povis akcepti ilin ĉar ne estis sufiĉe da maljunuloj por subteni la junulojn kaj agi kiel mentoroj por ili. Necesis unue varbi la supron kaj nur poste la junulon.
• Karoto kaj bastono.

Mi ne havas bonan respondon al la demando pri kio estas la ĝusta ekvilibro, kiel konservi ĝin, kiom da homoj konservi kaj kiom puŝi. Ĉi tio estas pure individua procezo.

Tago kvindek unu

Mi komencis atente rigardi la teamon por kompreni, kiun mi havis, kaj denove mi rememoris:

"Plej multaj problemoj estas homaj problemoj."

Mi trovis, ke la teamo kiel tia - kaj Dev kaj Ops - havas tri grandajn problemojn:

• Kontenteco pri la nuna stato de aferoj.
• Manko de respondeco - ĉar neniu iam alportis la rezultojn de la laboro de la prezentistoj por influi la komercon.
• Timo de ŝanĝo.

Ŝanĝo ĉiam eltiras vin el via komforta zono, kaj ju pli junaj homoj estas, des pli ili malŝatas ŝanĝon, ĉar ili ne komprenas kial kaj ili ne komprenas kiel. La plej ofta respondo, kiun mi aŭdis, estas: "Ni neniam faris tion." Krome, ĝi atingis la punkton de plena absurdaĵo – la plej etaj ŝanĝoj ne povus okazi sen ke iu indigniĝu. Kaj kiom ajn la ŝanĝoj influis ilian laboron, homoj diris: “Ne, kial? Ĉi tio ne funkcios."

Sed vi ne povas pliboniĝi sen ŝanĝi ion ajn.

Mi havis absolute absurdan konversacion kun dungito, mi rakontis al li miajn ideojn por optimumigo, al kiu li diris al mi:
- Ho, vi ne vidis, kion ni havis pasintjare!
- Do kio?
"Nun ĝi estas multe pli bona ol ĝi estis."
- Do, ĉu ĝi ne povas pliboniĝi?
- Por kio?

Bona demando - kial? Estas kvazaŭ ĝi estas pli bona nun ol ĝi estis, tiam ĉio estas sufiĉe bona. Ĉi tio kondukas al manko de respondeco, kio principe estas absolute normala. Kiel mi diris, la teknika grupo estis iom flanke. La firmao kredis ke ili devus ekzisti, sed neniu iam starigis la normojn. Teknika subteno neniam vidis la SLA, do ĝi estis sufiĉe "akceptebla" por la grupo (kaj ĉi tio plej frapis min):

• 12 sekundoj ŝarĝo;
• 5-10 minutoj malfunkcio ĉiu eldono;
• Solvado de kritikaj problemoj prenas tagojn kaj semajnojn;
• manko de deĵorpersonaro 24x7 / survoka.

Neniu iam provis demandi kial ni ne faras tion pli bone, kaj neniu iam rimarkis, ke ne devas esti tiel.

Kiel gratifiko, estis unu plia problemo: manko de sperto. La maljunuloj foriris, kaj la restanta juna teamo kreskis sub la antaŭa reĝimo kaj estis venenita de ĝi.

Krom ĉio ĉi, homoj ankaŭ timis malsukcesi kaj ŝajni nekompetenta. Ĉi tio estas esprimita en la fakto, ke unue ili sub neniu cirkonstanco petis helpon. Kiom da fojoj ni parolis grupe kaj individue, kaj mi diris: "Demandu, se vi ne scias kiel fari ion." Mi fidas en mi mem kaj scias, ke mi povas solvi ajnan problemon, sed ĝi bezonos tempon. Tial, se mi povas demandi iun, kiu scias kiel solvi ĝin en 10 minutoj, mi demandos. Ju malpli da sperto vi havas, des pli vi timas demandi ĉar vi pensas, ke vi estos konsiderata nekompetenta.

Ĉi tiu timo fari demandojn manifestiĝas en interesaj manieroj. Ekzemple, vi demandas: "Kiel vi fartas kun ĉi tiu tasko?" - "Restas kelkaj horoj, mi jam finas." La sekvan tagon vi demandas denove, vi ricevas la respondon, ke ĉio estas en ordo, sed estis unu problemo, ĝi certe estos preta ĝis la fino de la tago. Alia tago pasas, kaj ĝis vi estas alpinglita al la muro kaj devigita paroli kun iu, tio daŭras. Homo volas mem solvi problemon; li kredas, ke se li ne solvas ĝin mem, ĝi estos granda fiasko.

Tial la programistoj ŝveligis la taksojn. Estis tiu sama anekdoto, kiam ili diskutis pri certa tasko, ili donis al mi tian figuron, ke mi estis tre surprizita. Al kiu oni diris al mi, ke en la taksoj de la programisto, la programisto inkluzivas la tempon, kiam la bileto estos resendita de QA, ĉar ili trovos erarojn tie, kaj la tempon, kiun prenos la PR, kaj la tempon dum la homoj, kiuj devus revizii. ĝi estos okupata - tio estas ĉio, kio ajn eblas.

Due, homoj, kiuj timas ŝajni nekompetentaj troanalizi. Kiam vi diras, kion precize necesas fari, ĝi komenciĝas: "Ne, kaj se ni pripensos ĝin ĉi tie?" Tiusence, nia kompanio ne estas unika; ĉi tio estas norma problemo por junuloj.

En respondo, mi enkondukis la sekvajn praktikojn:

• Regulo 30 minutoj. Se vi ne povas solvi la problemon en duonhoro, petu iun helpi. Ĉi tio funkcias kun diversaj gradoj de sukceso, ĉar homoj ankoraŭ ne demandas, sed almenaŭ la procezo komenciĝis.
• Forigu ĉion krom la esencon, en taksado de la limdato por plenumi taskon, tio estas, konsideri nur kiom da tempo necesas por skribi la kodon.
• Tutviva lernado por tiuj, kiuj troanalizas. Ĝi estas nur konstanta laboro kun homoj.

Tago sesdeka

Dum mi faris ĉion ĉi, estis tempo eltrovi la buĝeton. Kompreneble, mi trovis multajn interesajn aferojn en kie ni elspezis nian monon. Ekzemple, ni havis tutan rakon en aparta datumcentro kun unu FTP-servilo, kiu estis uzata de unu kliento. Montriĝis ke "... ni moviĝis, sed li restis tiel, ni ne ŝanĝis lin." Estis antaŭ 2 jaroj.

Aparte interesa estis la fakturo por nubaj servoj. Mi kredas, ke la ĉefa kialo de la alta nuba fakturo estas la programistoj, kiuj havas senliman aliron al serviloj unuafoje en siaj vivoj. Ili ne bezonas demandi: "Bonvolu doni al mi testan servilon," ili mem povas preni ĝin. Krome, programistoj ĉiam volas konstrui tiel bonegan sistemon, ke Facebook kaj Netflix estos ĵaluza.

Sed la programistoj ne havas sperton pri aĉetado de serviloj kaj la lertecon determini la bezonatan grandecon de serviloj, ĉar ili antaŭe ne bezonis ĝin. Kaj ili kutime ne tute komprenas la diferencon inter skaleblo kaj rendimento.

Rezultoj de inventaro:

• Ni forlasis la saman datumcentron.
• Ni nuligis la kontrakton kun 3 logservoj. Ĉar ni havis 5 el ili - ĉiu programisto, kiu komencis ludi kun io, prenis novan.
• 7 AWS-sistemoj estis fermitaj. Denove, neniu haltigis la mortajn projektojn; ili ĉiuj daŭre funkciis.
• Reduktis programajn kostojn je 6 fojojn.

Tago sepdek kvin

La tempo pasis, kaj post du monatoj kaj duono mi devis renkontiĝi kun la estraro. Nia estraro ne estas pli bona aŭ pli malbona ol aliaj; kiel ĉiuj estraroj, ĝi volas scii ĉion. Homoj investas monon kaj volas kompreni kiom tio, kion ni faras, taŭgas en la aro de KPIoj.

La estraro de direktoroj ricevas multajn informojn ĉiumonate: la nombro da uzantoj, ilia kresko, kiajn servojn ili uzas kaj kiel, rendimento kaj produktiveco, kaj fine, averaĝa paĝa ŝarĝrapideco.

La nura problemo estas ke mi kredas ke la mezumo estas pura malbono. Sed estas tre malfacile klarigi tion al la estraro. Ili kutimas funkcii kun agregataj nombroj, kaj ne, ekzemple, la disvastiĝon de ŝarĝaj tempoj por sekundo.

Estis kelkaj interesaj punktoj ĉi-rilate. Ekzemple, mi diris, ke ni devas dividi trafikon inter apartaj retserviloj depende de la speco de enhavo.

Tio estas, ColdFusion trairas Jetty kaj nginx kaj lanĉas la paĝojn. Kaj bildoj, JS kaj CSS trairas apartan nginx kun siaj propraj agordoj. Ĉi tio estas sufiĉe norma praktiko, pri kiu mi parolas skribis antaŭ kelkaj jaroj. Rezulte, bildoj ŝarĝas multe pli rapide, kaj... la meza ŝarĝrapideco pliiĝis je 200 ms.

Ĉi tio okazis ĉar la grafikaĵo estas konstruita surbaze de la datumoj kiuj venas kun Jetty. Tio estas, rapida enhavo ne estas inkluzivita en la kalkulo - la averaĝa valoro saltis. Ĉi tio estis klara al ni, ni ridis, sed kiel ni povas klarigi al la estraro kial ni faris ion kaj aferoj plimalboniĝis je 12%?

Tago okdek kvin

Fine de la tria monato, mi konstatis, ke estas unu afero, pri kiu mi tute ne kalkulis: la tempo. Ĉio, pri kio mi parolis, bezonas tempon.

Jen mia vera semajna kalendaro - nur laborsemajno, ne tre okupata. Ne estas sufiĉe da tempo por ĉio. Tial, denove, vi devas varbi homojn, kiuj helpos vin trakti la problemojn.

konkludo

Tio ne estas ĉio. En ĉi tiu rakonto, mi eĉ ne atingis kiel ni laboris kun la produkto kaj provis agordi la ĝeneralan ondon, aŭ kiel ni integris teknikan subtenon, aŭ kiel ni solvis aliajn teknikajn problemojn. Ekzemple, mi lernis tute hazarde, ke sur la plej grandaj tabeloj en la datumbazo ni ne uzas SEQUENCE. Ni havas memskribitan funkcion nextID, kaj ĝi ne estas uzata en transakcio.

Estis miliono pli da similaj aferoj, pri kiuj ni povus paroli dum longa tempo. Sed la plej grava afero, kiun oni ankoraŭ devas diri, estas kulturo.

Estas kulturo aŭ ties manko kiu kondukas al ĉiuj aliaj problemoj. Ni provas konstrui kulturon kie homoj:

• ne timas malsukcesojn;
• lerni de eraroj;
• kunlabori kun aliaj teamoj;
• preni iniciaton;
• preni respondecon;
• bonvenigi la rezulton kiel celon;
• festante sukceson.

Kun ĉi tio venos ĉio alia.

Leono Fajro en tvitero, facebook kaj plu meza.

Estas du strategioj koncerne heredaĵon: eviti labori kun ĝi ĉiakoste, aŭ kuraĝe venki la rilatajn malfacilaĵojn. Ni ĉ DevOpsConf Ni prenas la duan vojon, ŝanĝante procezojn kaj alirojn. Aliĝu al ni youtube, dissendolisto и telegramo, kaj kune ni efektivigos kulturon DevOps.

fonto: www.habr.com