Inajulikana kuwa uwezo wa CTO hujaribiwa mara ya pili tu anapofanya jukumu hili. Kwa sababu ni jambo moja kufanya kazi katika kampuni kwa miaka kadhaa, kubadilika nayo na, kuwa katika mazingira sawa ya kitamaduni, hatua kwa hatua kupokea jukumu zaidi. Na ni jambo lingine kabisa kuja moja kwa moja katika nafasi ya mkurugenzi wa kiufundi katika kampuni iliyo na mizigo ya urithi na rundo la matatizo yaliyofagiliwa vizuri chini ya zulia.

Kwa maana hii, uzoefu wa Leon Fire, ambayo alishiriki DevOpsConf, sio ya kipekee kabisa, lakini ikizidishwa na uzoefu wake na idadi ya majukumu tofauti ambayo aliweza kujaribu kwa kipindi cha miaka 20, ni muhimu sana. Chini ya mpangilio huo kuna mpangilio wa matukio kwa zaidi ya siku 90 na hadithi nyingi ambazo ni za kufurahisha kucheka zinapotokea kwa mtu mwingine, lakini ambazo hazifurahishi sana kukutana nazo ana kwa ana.

Leon anaongea kwa rangi sana kwa Kirusi, kwa hivyo ikiwa una dakika 35-40, napendekeza kutazama video. Toleo la maandishi ili kuokoa muda hapa chini.

Toleo la kwanza la ripoti lilikuwa maelezo yaliyoundwa vizuri ya kufanya kazi na watu na michakato, iliyo na mapendekezo muhimu. Lakini hakuonyesha mshangao wote ambao walikutana nao njiani. Kwa hivyo, nilibadilisha umbizo na kuwasilisha shida zilizojitokeza mbele yangu kama kisanduku katika kampuni mpya, na njia za kuzitatua kwa mpangilio wa matukio.

Mwezi mmoja kabla

Kama hadithi nyingi nzuri, hii ilianza na pombe. Tulikuwa tumekaa na marafiki kwenye baa, na kama ilivyotarajiwa kati ya wataalamu wa IT, kila mtu alikuwa akilia juu ya shida zao. Mmoja wao alikuwa amebadilisha kazi na alikuwa anazungumza juu ya shida zake na teknolojia, na watu, na timu. Kadiri nilivyokuwa nikisikiliza ndivyo nilivyogundua kwamba anapaswa kuniajiri tu, kwa sababu hizi ni aina za matatizo ambayo nimekuwa nikiyatatua kwa miaka 15 iliyopita. Nilimwambia hivyo, na siku iliyofuata tukakutana katika mazingira ya kazi. Kampuni hiyo iliitwa Teaching Strategies.

Mikakati ya Kufundisha ni kiongozi wa soko katika mtaala wa watoto wadogo sana kutoka kuzaliwa hadi miaka mitatu. Kampuni ya jadi ya "karatasi" tayari ina umri wa miaka 40, na toleo la digital la SaaS la jukwaa lina umri wa miaka 10. Hivi karibuni, mchakato wa kurekebisha teknolojia ya digital kwa viwango vya kampuni ulianza. Toleo "mpya" lililozinduliwa mnamo 2017 na lilikuwa karibu kama la zamani, tu lilifanya kazi mbaya zaidi.

Jambo la kufurahisha zaidi ni kwamba trafiki ya kampuni hii inatabirika sana - siku hadi siku, mwaka hadi mwaka, unaweza kutabiri kwa uwazi ni watu wangapi watakuja na lini. Kwa mfano, kati ya 13 na 15 p.m. watoto wote katika shule za chekechea hulala na walimu huanza kuingiza habari. Na hii hutokea kila siku, isipokuwa mwishoni mwa wiki, kwa sababu karibu hakuna mtu anayefanya kazi mwishoni mwa wiki.

Kuangalia mbele kidogo, nitagundua kuwa nilianza kazi yangu wakati wa trafiki ya juu zaidi ya kila mwaka, ambayo inavutia kwa sababu tofauti.

Jukwaa, ambalo lilionekana kuwa na umri wa miaka 2 tu, lilikuwa na safu ya kipekee: ColdFusion & SQL Server kutoka 2008. ColdFusion, ikiwa hujui, na uwezekano mkubwa haujui, ni PHP ya biashara iliyotoka katikati ya miaka ya 90, na tangu wakati huo sijaisikia hata. Pia kulikuwa na: Ruby, MySQL, PostgreSQL, Java, Go, Python. Lakini monolith kuu iliendesha ColdFusion na SQL Server.

Shida

Kadiri nilivyozungumza na wafanyikazi wa kampuni juu ya kazi hiyo na shida gani zilipatikana, ndivyo niligundua kuwa shida hazikuwa za kiufundi tu. Sawa, teknolojia ni ya zamani - na hawakuifanyia kazi, lakini kulikuwa na shida na timu na michakato, na kampuni ilianza kuelewa hili.

Kijadi, teknolojia zao zilikaa kwenye kona na kufanya aina fulani ya kazi. Lakini biashara zaidi na zaidi ilianza kupitia toleo la dijiti. Kwa hiyo, katika mwaka jana kabla ya kuanza kufanya kazi, wapya walionekana katika kampuni: bodi ya wakurugenzi, CTO, CPO na mkurugenzi wa QA. Hiyo ni, kampuni ilianza kuwekeza katika sekta ya teknolojia.

Athari za urithi mzito hazikuwa kwenye mifumo tu. Kampuni hiyo ilikuwa na michakato ya urithi, watu wa urithi, utamaduni wa urithi. Yote hii ilibidi ibadilishwe. Nilidhani kwamba hakika haingekuwa ya kuchosha, na niliamua kujaribu.

Siku mbili kabla

Siku mbili kabla ya kuanza kazi mpya, nilifika ofisini, nikajaza karatasi za mwisho, nikakutana na timu, na kugundua kwamba timu ilikuwa ikipambana na tatizo wakati huo. Ilikuwa kwamba muda wa wastani wa upakiaji wa ukurasa uliruka hadi sekunde 4, ambayo ni, mara 2.

Kwa kuzingatia grafu, kitu kilifanyika wazi, na haijulikani ni nini. Ilibadilika kuwa shida ilikuwa latency ya mtandao katika kituo cha data: 5 ms latency katika kituo cha data iligeuka kuwa 2 s kwa watumiaji. Sikujua kwa nini hii ilitokea, lakini kwa hali yoyote ilijulikana kuwa tatizo lilikuwa kwenye kituo cha data.

Siku ya kwanza

Siku mbili zilipita na siku ya kwanza ya kazi niligundua kuwa shida haijaisha.

Kwa siku mbili, kurasa za watumiaji zilipakiwa kwa wastani katika sekunde 4. Nauliza kama wamegundua tatizo ni nini.

- Ndio, tulifungua tikiti.
- NA?
- Kweli, bado hawajatujibu.

Kisha nikagundua kwamba kila kitu nilichokuwa nimeambiwa hapo awali kilikuwa kidokezo kidogo tu cha barafu ambacho nilipaswa kupigana.

Kuna nukuu nzuri ambayo inafaa hii vizuri:

"Wakati mwingine ili kubadilisha teknolojia lazima ubadilishe shirika."

Lakini tangu nilipoanza kazi wakati wa kazi zaidi wa mwaka, nilipaswa kuangalia chaguzi zote mbili za kutatua tatizo: kwa haraka na kwa muda mrefu. Na anza na kile ambacho ni muhimu hivi sasa.

Siku ya tatu

Kwa hivyo, upakiaji huchukua sekunde 4, na kutoka 13 hadi 15 kilele kikubwa zaidi.

Katika siku ya tatu katika kipindi hiki cha muda, kasi ya upakuaji ilionekana kama hii:

Kwa mtazamo wangu, hakuna kilichofanya kazi hata kidogo. Kwa mtazamo wa kila mtu ilikuwa inakwenda polepole zaidi kuliko kawaida. Lakini haifanyiki hivyo - ni shida kubwa.

Nilijaribu kushawishi timu, ambayo walijibu kwamba wanahitaji seva zaidi. Hii, bila shaka, ni suluhisho la tatizo, lakini sio daima pekee na yenye ufanisi zaidi. Niliuliza kwa nini hakukuwa na seva za kutosha, ni kiasi gani cha trafiki. Niliongeza data na nikagundua kuwa tuna takriban maombi 150 kwa sekunde, ambayo, kimsingi, iko ndani ya mipaka inayofaa.

Lakini hatupaswi kusahau kwamba kabla ya kupata jibu sahihi, unahitaji kuuliza swali sahihi. Swali langu lililofuata lilikuwa: tuna seva ngapi za sehemu ya mbele? Jibu "lilinishangaza kidogo" - tulikuwa na seva 17 za mbele!

- Nina aibu kuuliza, lakini 150 iliyogawanywa na 17 inatoa karibu 8? Je, unasema kwamba kila seva inaruhusu maombi 8 kwa sekunde, na ikiwa kesho kuna maombi 160 kwa sekunde, tutahitaji seva 2 zaidi?

Bila shaka, hatukuhitaji seva za ziada. Suluhisho lilikuwa kwenye nambari yenyewe, na juu ya uso:

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

Kulikuwa na tamasha getCurrentClass(), kwa sababu kila kitu kwenye tovuti hufanya kazi katika mazingira ya darasa - hiyo ni sawa. Na kwa kazi hii moja kwenye kila ukurasa kulikuwa na 200+ maombi.

Suluhisho kwa njia hii lilikuwa rahisi sana, hata haukuhitaji kuandika tena chochote: usiulize habari sawa tena.

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

Nilifurahi sana kwa sababu niliamua kwamba siku ya tatu tu nilikuwa nimepata tatizo kuu. Naive kama mimi, hii ilikuwa moja tu ya shida nyingi.

Lakini kutatua tatizo hili la kwanza kuliangusha grafu chini sana.

Wakati huo huo, tulikuwa tukifanya uboreshaji mwingine. Kulikuwa na mambo mengi mbele ambayo yangeweza kurekebishwa. Kwa mfano, siku hiyo hiyo ya tatu niligundua kuwa kuna cache katika mfumo baada ya yote (mwanzoni nilifikiri kwamba maombi yote yanakuja moja kwa moja kutoka kwa hifadhidata). Ninapofikiria kache, ninafikiria Redis ya kawaida au Memcached. Lakini mimi ndiye pekee niliyefikiria hivyo, kwa sababu mfumo huo ulitumia MongoDB na SQL Server kwa caching - ile ile ambayo data ilisomwa tu.

Siku ya kumi

Wiki ya kwanza nilishughulikia matatizo ambayo yalihitaji kutatuliwa sasa hivi. Mahali fulani katika wiki ya pili, nilikuja kusimama kwa mara ya kwanza ili kuwasiliana na timu, kuona nini kinatokea na jinsi mchakato mzima ulivyokuwa.

Kitu cha kuvutia kiligunduliwa tena. Timu ilijumuisha: watengenezaji 18; Wapimaji 8; wasimamizi 3; 2 wasanifu. Na wote walishiriki katika mila ya kawaida, ambayo ni, zaidi ya watu 30 walikuja kusimama kila asubuhi na kuwaambia walichokifanya. Ni wazi kwamba mkutano haukuchukua dakika 5 au 15. Hakuna mtu aliyemsikiliza mtu yeyote kwa sababu kila mtu anafanya kazi kwenye mifumo tofauti. Katika fomu hii, tikiti 2-3 kwa saa kwa kikao cha utayarishaji tayari zilikuwa matokeo mazuri.

Jambo la kwanza tulilofanya ni kugawa timu katika mistari kadhaa ya bidhaa. Kwa sehemu na mifumo tofauti, tulitenga timu tofauti, ambazo zilijumuisha wasanidi programu, wanaojaribu, wasimamizi wa bidhaa na wachambuzi wa biashara.

Kama matokeo, tulipata:

Kupunguza mikusanyiko na mikusanyiko.
Ujuzi wa mada ya bidhaa.
Hisia ya umiliki. Wakati watu walikuwa wakicheza na mifumo kila wakati, walijua kwamba kuna uwezekano mkubwa kwamba mtu mwingine atalazimika kufanya kazi na wadudu wao, lakini sio wao wenyewe.
Ushirikiano kati ya vikundi. Bila kusema, QA haikuwasiliana sana na waandaaji wa programu hapo awali, bidhaa ilifanya jambo lake mwenyewe, nk. Sasa wana jukumu la kawaida.

Tulizingatia sana ufanisi, tija na ubora - haya ni matatizo tuliyojaribu kutatua na mabadiliko ya timu.

Siku ya kumi na moja

Katika mchakato wa kubadilisha muundo wa timu, niligundua jinsi ya kuhesabu HadithiPoints. 1 SP ilikuwa sawa na siku moja, na kila tiketi ilikuwa na SP kwa ajili ya maendeleo na QA, yaani, angalau 2 SP.

Je, niligunduaje hili?

Tulipata hitilafu: katika moja ya ripoti, ambapo tarehe ya kuanza na ya mwisho ya kipindi ambacho ripoti inahitajika imeingizwa, siku ya mwisho haijazingatiwa. Hiyo ni, mahali fulani katika ombi hapakuwa <=, lakini kwa urahisi <. Niliambiwa kwamba hizi ni Pointi tatu za Hadithi, yaani 3 siku.

Baada ya haya sisi:

Mfumo wa ukadiriaji wa Alama za Hadithi umefanyiwa marekebisho. Sasa marekebisho ya hitilafu ndogo ambazo zinaweza kupitishwa kwa haraka kupitia mfumo humfikia mtumiaji haraka zaidi.
Tulianza kuunganisha tikiti zinazohusiana za ukuzaji na majaribio. Hapo awali, kila tikiti, kila mdudu ulikuwa mfumo wa ikolojia uliofungwa, haujafungwa na kitu kingine chochote. Kubadilisha vitufe vitatu kwenye ukurasa mmoja kunaweza kuwa tikiti tatu tofauti zenye michakato mitatu tofauti ya QA badala ya jaribio moja la kiotomatiki kwa kila ukurasa.
Tulianza kufanya kazi na wasanidi programu katika mbinu ya kukadiria gharama za wafanyikazi. Siku tatu kubadili kifungo kimoja sio funny.

Siku ya ishirini

Mahali fulani katikati ya mwezi wa kwanza, hali hiyo imetulia kidogo, nilifikiri nini kilikuwa kinatokea kimsingi, na tayari nikaanza kuangalia katika siku zijazo na kufikiri juu ya ufumbuzi wa muda mrefu.

Malengo ya muda mrefu:

Jukwaa linalosimamiwa. Mamia ya maombi kwenye kila ukurasa sio mazito.
Mitindo inayotabirika. Kulikuwa na vilele vya mara kwa mara vya trafiki ambavyo kwa mtazamo wa kwanza havikuhusiana na vipimo vingine - tulihitaji kuelewa ni kwa nini hii ilitokea na kujifunza kutabiri.
Upanuzi wa jukwaa. Biashara inakua kila wakati, watumiaji zaidi na zaidi wanakuja, na trafiki inaongezeka.

Hapo awali ilisemwa mara nyingi: "Hebu tuandike upya kila kitu katika [lugha/mfumo], kila kitu kitafanya kazi vizuri zaidi!"

Katika hali nyingi hii haifanyi kazi, ni vizuri ikiwa uandishi utafanya kazi hata kidogo. Kwa hivyo, tulihitaji kuunda ramani - mkakati maalum unaoonyesha hatua kwa hatua jinsi malengo ya biashara yatafikiwa (tutafanya nini na kwa nini), ambayo:

huonyesha dhamira na malengo ya mradi;
hutanguliza malengo makuu;
ina ratiba ya kuyafikia.

Kabla ya hili, hakuna mtu aliyezungumza na timu kuhusu madhumuni ya mabadiliko yoyote kufanywa. Hii inahitaji vipimo sahihi vya mafanikio. Kwa mara ya kwanza katika historia ya kampuni, tuliweka KPIs kwa kikundi cha kiufundi, na viashiria hivi viliunganishwa na wale wa shirika.

Hiyo ni, KPI za shirika zinasaidiwa na timu, na KPI za timu zinaungwa mkono na KPI za kibinafsi. Vinginevyo, ikiwa KPI za kiteknolojia haziendani na zile za shirika, basi kila mtu huvuta blanketi juu yake mwenyewe.

Kwa mfano, mojawapo ya KPI za shirika inaongeza hisa ya soko kupitia bidhaa mpya.

Unawezaje kuunga mkono lengo la kuwa na bidhaa nyingi mpya?

Kwanza, tunataka kutumia muda mwingi kutengeneza bidhaa mpya badala ya kurekebisha kasoro. Hii ni suluhisho la kimantiki ambalo ni rahisi kupima.
Pili, tunataka kuunga mkono ongezeko la kiasi cha shughuli, kwa sababu kadiri sehemu ya soko inavyokuwa kubwa, ndivyo watumiaji wengi zaidi na, ipasavyo, trafiki zaidi.

Kisha KPI za kibinafsi zinazoweza kutekelezwa ndani ya kikundi zitakuwa, kwa mfano, mahali ambapo kasoro kuu zinatoka. Ikiwa utazingatia hasa sehemu hii, unaweza kuhakikisha kuwa kuna kasoro chache zaidi, na kisha wakati wa kutengeneza bidhaa mpya na tena kwa kusaidia KPI za shirika utaongezeka.

Kwa hivyo, kila uamuzi, pamoja na msimbo wa kuandika upya, lazima uunge mkono malengo mahususi ambayo kampuni imeweka kwa ajili yetu (ukuaji wa shirika, vipengele vipya, uajiri).

Wakati wa mchakato huu, jambo la kuvutia lilikuja, ambalo likawa habari sio tu kwa techies, lakini kwa ujumla katika kampuni: tiketi zote zinapaswa kuzingatia angalau KPI moja. Hiyo ni, ikiwa bidhaa inasema kwamba inataka kutengeneza kipengele kipya, swali la kwanza linapaswa kuulizwa: "Je, kipengele hiki kinaauni KPI gani?" Ikiwa sivyo, basi pole - inaonekana kama kipengele kisichohitajika.

Siku ya thelathini

Mwishoni mwa mwezi, niligundua jambo lingine: hakuna mtu kwenye timu yangu ya Ops ambaye amewahi kuona kandarasi tunazoingia na wateja. Unaweza kuuliza kwa nini unahitaji kuona anwani.

Kwanza, kwa sababu SLA zimeainishwa katika mikataba.
Pili, SLA zote ni tofauti. Kila mteja alikuja na mahitaji yake mwenyewe, na idara ya mauzo ilisaini bila kuangalia.

Nuance nyingine ya kuvutia ni kwamba mkataba na mmoja wa wateja wakubwa unasema kwamba matoleo yote ya programu yanayoungwa mkono na jukwaa lazima yawe n-1, yaani, si toleo la hivi karibuni, lakini la mwisho.

Ni wazi jinsi tulivyokuwa mbali na n-1 ikiwa jukwaa liliegemezwa kwenye ColdFusion na SQL Server 2008, ambayo haikutumika tena kabisa mwezi wa Julai.

Siku ya arobaini na tano

Karibu katikati ya mwezi wa pili nilikuwa na muda wa kutosha wa kukaa na kufanya thamanimkondoramani kabisa kwa mchakato mzima. Hizi ni hatua muhimu zinazohitajika kuchukuliwa, kutoka kwa kuunda bidhaa hadi kuwasilisha kwa watumiaji, na zinahitaji kuelezewa kwa undani iwezekanavyo.

Unavunja mchakato katika vipande vidogo na kuona nini kinachukua muda mwingi, ni nini kinachoweza kuboreshwa, kuboreshwa, nk. Kwa mfano, inachukua muda gani kwa ombi la bidhaa kupitia urembo, lini inafikia tikiti ambayo msanidi programu anaweza kuchukua, QA, n.k. Kwa hivyo unatazama kila hatua ya mtu binafsi kwa undani na fikiria juu ya kile kinachoweza kuboreshwa.

Nilipofanya hivi, mambo mawili yalinivutia:

asilimia kubwa ya tikiti zilizorejeshwa kutoka kwa QA kwa watengenezaji;
ukaguzi wa ombi la kuvuta ulichukua muda mrefu sana.

Shida ilikuwa kwamba haya yalikuwa mahitimisho kama: Inaonekana kuchukua muda mwingi, lakini hatuna uhakika ni muda gani.

"Huwezi kuboresha kile ambacho huwezi kupima."

Jinsi ya kuhalalisha jinsi shida ni kubwa? Inapoteza siku au masaa?

Ili kupima hili, tuliongeza hatua kadhaa kwenye mchakato wa Jira: "tayari kwa matumizi" na "tayari kwa QA" ili kupima muda ambao kila tikiti inasubiri na mara ngapi inarudi kwa hatua fulani.

Pia tuliongeza "katika ukaguzi" ili kujua ni tikiti ngapi kwa wastani za kukaguliwa, na kutoka kwa hii unaweza kuanza kucheza. Tulikuwa na vipimo vya mfumo, sasa tuliongeza vipimo vipya na tukaanza kupima:

Ufanisi wa mchakato: utendaji na uliopangwa/kutolewa.
Ubora wa mchakato: idadi ya kasoro, kasoro kutoka kwa QA.

Inasaidia sana kuelewa ni nini kinaendelea vizuri na kile ambacho hakiendi vizuri.

Siku ya hamsini

Hii yote, kwa kweli, ni nzuri na ya kufurahisha, lakini hadi mwisho wa mwezi wa pili kitu kilifanyika ambacho, kimsingi, kilitabirika, ingawa sikutarajia kiwango kama hicho. Watu walianza kuondoka kwa sababu uongozi wa juu ulikuwa umebadilika. Watu wapya walikuja kwenye usimamizi na wakaanza kubadilisha kila kitu, na wale wa zamani waliacha. Na kwa kawaida katika kampuni ambayo ina umri wa miaka kadhaa, kila mtu ni marafiki na kila mtu anamjua mwenzake.

Hii ilitarajiwa, lakini ukubwa wa walioachishwa kazi haukutarajiwa. Kwa mfano, katika wiki moja viongozi wa timu mbili kwa wakati mmoja waliwasilisha kujiuzulu kwa hiari yao wenyewe. Kwa hiyo, nilipaswa kusahau tu matatizo mengine, lakini kuzingatia kuunda timu. Hili ni tatizo la muda mrefu na gumu kutatua, lakini ilibidi kushughulikiwa kwa sababu nilitaka kuokoa watu waliobaki (au wengi wao). Ilihitajika kwa namna fulani kuguswa na ukweli kwamba watu waliondoka ili kudumisha ari katika timu.

Kwa nadharia, hii ni nzuri: mtu mpya anakuja ambaye ana carte blanche kamili, ambaye anaweza kutathmini ujuzi wa timu na kuchukua nafasi ya wafanyakazi. Kwa kweli, huwezi tu kuleta watu wapya kwa sababu nyingi. Mizani inahitajika kila wakati.

Zamani na mpya. Tunahitaji kuwaweka wazee ambao wanaweza kubadilika na kuunga mkono misheni. Lakini wakati huo huo, tunahitaji kuleta damu mpya, tutazungumzia kuhusu hilo baadaye kidogo.
Uzoefu. Nilizungumza mengi na vijana wazuri ambao walikuwa na hamu na walitaka kufanya kazi nasi. Lakini sikuweza kuwachukua kwa sababu hakukuwa na wazee wa kutosha kusaidia vijana na kuwa washauri kwao. Ilikuwa ni lazima kwanza kuajiri wakuu na kisha tu vijana.
Karoti na fimbo.

Sina jibu zuri kwa swali la usawa sahihi ni nini, jinsi ya kuitunza, ni watu wangapi wa kuweka na ni kiasi gani cha kushinikiza. Huu ni mchakato wa mtu binafsi.

Siku ya hamsini na moja

Nilianza kuangalia kwa karibu timu ili kuelewa nilikuwa na nani, na kwa mara nyingine tena nikakumbuka:

"Matatizo mengi ni matatizo ya watu."

Nimegundua kuwa timu kama hiyo - Dev na Ops - ina shida tatu kubwa:

Kuridhika na hali ya sasa ya mambo.
Ukosefu wa wajibu - kwa sababu hakuna mtu aliyewahi kuleta matokeo ya kazi ya watendaji kushawishi biashara.
Hofu ya mabadiliko.

Mabadiliko daima hukuondoa katika eneo lako la faraja, na vijana ndivyo wanavyozidi kutopenda mabadiliko kwa sababu hawaelewi kwa nini na hawaelewi jinsi gani. Jibu la kawaida ambalo nimesikia ni, "Hatujawahi kufanya hivyo." Zaidi ya hayo, ilifikia hatua ya upuuzi kabisa - mabadiliko madogo hayangeweza kufanyika bila mtu kuwa na hasira. Na haijalishi ni kiasi gani mabadiliko hayo yaliathiri kazi yao, watu walisema: “Hapana, kwa nini? Hii haitafanya kazi."

Lakini huwezi kuwa bora bila kubadilisha chochote.

Nilikuwa na mazungumzo ya kipuuzi kabisa na mfanyakazi, nilimwambia maoni yangu ya utoshelezaji, ambayo aliniambia:
- Ah, haukuona tulichokuwa nacho mwaka jana!
- Kwa hiyo?
"Sasa ni bora zaidi kuliko ilivyokuwa."
- Kwa hivyo, haiwezi kuwa bora zaidi?
- Kwa nini?

Swali zuri - kwa nini? Ni kana kwamba ni bora sasa kuliko ilivyokuwa, basi kila kitu ni nzuri vya kutosha. Hii inasababisha ukosefu wa uwajibikaji, ambayo ni ya kawaida kabisa kwa kanuni. Kama nilivyosema, kikundi cha ufundi kilikuwa pembeni kidogo. Kampuni hiyo iliamini kwamba inapaswa kuwepo, lakini hakuna aliyewahi kuweka viwango. Usaidizi wa kiufundi haujawahi kuona SLA, kwa hivyo "ilikubalika" kwa kikundi (na hii ilinivutia zaidi):

Upakiaji wa sekunde 12;
Dakika 5-10 za kupumzika kila kutolewa;
Kutatua matatizo muhimu huchukua siku na wiki;
ukosefu wa wafanyakazi wa wajibu 24x7 / on-call.

Hakuna mtu aliyewahi kujaribu kuuliza kwa nini tusiifanye vizuri zaidi, na hakuna mtu aliyewahi kutambua kwamba haifai kuwa hivi.

Kama bonasi, kulikuwa na shida moja zaidi: ukosefu wa uzoefu. Wazee waliondoka, na timu ya vijana iliyobaki ilikua chini ya utawala uliopita na ilitiwa sumu nayo.

Juu ya haya yote, watu pia walikuwa na hofu ya kushindwa na kuonekana wasio na uwezo. Hii inaonyeshwa kwa ukweli kwamba, kwanza, wao chini ya hali yoyote hakuomba msaada. Ni mara ngapi tumezungumza kama kikundi na kibinafsi, na nimesema, "Uliza swali ikiwa hujui jinsi ya kufanya jambo fulani." Ninajiamini na najua kuwa ninaweza kutatua shida yoyote, lakini itachukua muda. Kwa hivyo, ikiwa ninaweza kuuliza mtu anayejua jinsi ya kutatua kwa dakika 10, nitauliza. Kadiri unavyokuwa na uzoefu mdogo, ndivyo unavyoogopa kuuliza kwa sababu unafikiri utachukuliwa kuwa huna uwezo.

Hofu hii ya kuuliza maswali inajidhihirisha kwa njia za kuvutia. Kwa mfano, unauliza: "Unaendeleaje na kazi hii?" - "Saa chache zimesalia, tayari ninamaliza." Siku inayofuata unauliza tena, unapata jibu kwamba kila kitu kiko sawa, lakini kulikuwa na tatizo moja, hakika itakuwa tayari mwishoni mwa siku. Siku nyingine hupita, na mpaka umefungwa kwenye ukuta na kulazimishwa kuzungumza na mtu, hii inaendelea. Mtu anataka kusuluhisha shida mwenyewe; anaamini kwamba ikiwa hatasuluhisha mwenyewe, itakuwa shida kubwa.

Ndiyo sababu watengenezaji waliongeza makadirio. Ilikuwa ni hadithi hiyo hiyo, walipokuwa wakijadili kazi fulani, walinipa sura ambayo nilishangaa sana. Ambayo niliambiwa kuwa katika makadirio ya msanidi programu, msanidi hujumuisha wakati ambao tikiti itarejeshwa kutoka kwa QA, kwa sababu watapata makosa hapo, na wakati ambao PR itachukua, na wakati ambao watu wanapaswa kukagua. itakuwa busy - yaani, kila kitu, chochote kinachowezekana.

Pili, watu ambao wanaogopa kuonekana wasio na uwezo kuchambua kupita kiasi. Unaposema ni nini hasa kinachohitajika kufanywa, huanza: "Hapana, vipi ikiwa tutafikiria juu yake hapa?" Kwa maana hii, kampuni yetu si ya kipekee; hili ni tatizo la kawaida kwa vijana.

Kwa kujibu, nilianzisha mazoea yafuatayo:

Kanuni ya dakika 30. Ikiwa huwezi kutatua tatizo kwa nusu saa, muulize mtu akusaidie. Hii inafanya kazi kwa viwango tofauti vya mafanikio, kwa sababu watu bado hawaulizi, lakini angalau mchakato umeanza.
Ondoa kila kitu isipokuwa kiini, katika kukadiria tarehe ya mwisho ya kukamilisha kazi, yaani, fikiria tu itachukua muda gani kuandika msimbo.
Kuendelea kujifunza kwa wale wanaochambua kupita kiasi. Ni kazi ya mara kwa mara tu na watu.

Siku ya sitini

Wakati nikifanya haya yote, ulikuwa wakati wa kufikiria bajeti. Bila shaka, nilipata mambo mengi ya kuvutia ambapo tulitumia pesa zetu. Kwa mfano, tulikuwa na rack nzima katika kituo tofauti cha data na seva moja ya FTP, ambayo ilitumiwa na mteja mmoja. Ilibadilika kuwa "... tulihama, lakini alikaa hivyo, hatukumbadilisha." Ilikuwa miaka 2 iliyopita.

Ya riba hasa ilikuwa muswada wa huduma za wingu. Ninaamini sababu kuu ya muswada wa juu wa wingu ni watengenezaji ambao wana ufikiaji usio na kikomo kwa seva kwa mara ya kwanza katika maisha yao. Hawana haja ya kuuliza: "Tafadhali nipe seva ya mtihani," wanaweza kuchukua wenyewe. Zaidi, watengenezaji daima wanataka kujenga mfumo mzuri sana kwamba Facebook na Netflix watakuwa na wivu.

Lakini watengenezaji hawana uzoefu katika ununuzi wa seva na ujuzi wa kuamua ukubwa unaohitajika wa seva, kwa sababu hawakuhitaji hapo awali. Na kwa kawaida hawaelewi kabisa tofauti kati ya scalability na utendaji.

Matokeo ya hesabu:

Tuliondoka kwenye kituo kimoja cha data.
Tulikatisha mkataba na huduma 3 za kumbukumbu. Kwa sababu tulikuwa na 5 kati yao - kila msanidi ambaye alianza kucheza na kitu alichukua mpya.
Mifumo 7 ya AWS ilizimwa. Tena, hakuna aliyesimamisha miradi iliyokufa; wote waliendelea kufanya kazi.
Gharama za programu zilipunguzwa kwa mara 6.

Siku ya sabini na tano

Muda ulipita, na baada ya miezi miwili na nusu nililazimika kukutana na halmashauri ya wakurugenzi. Bodi yetu ya wakurugenzi si bora au mbaya zaidi kuliko wengine; kama bodi zote za wakurugenzi, inataka kujua kila kitu. Watu huwekeza pesa na wanataka kuelewa ni kiasi gani tunachofanya kinafaa katika KPIs seti.

Bodi ya wakurugenzi hupokea taarifa nyingi kila mwezi: idadi ya watumiaji, ukuaji wao, huduma gani wanazotumia na jinsi gani, utendaji na tija, na hatimaye, kasi ya wastani ya upakiaji wa ukurasa.

Shida pekee ni kwamba ninaamini kuwa wastani ni uovu mtupu. Lakini ni vigumu sana kueleza hili kwa bodi ya wakurugenzi. Wamezoea kufanya kazi na nambari zilizojumuishwa, na sio, kwa mfano, kuenea kwa nyakati za upakiaji kwa sekunde.

Kulikuwa na mambo ya kuvutia katika suala hili. Kwa mfano, nilisema kwamba tunahitaji kugawanya trafiki kati ya seva tofauti za wavuti kulingana na aina ya yaliyomo.

Hiyo ni, ColdFusion inapitia Jetty na nginx na kuzindua kurasa. Na picha, JS na CSS hupitia nginx tofauti na usanidi wao wenyewe. Hii ni mazoezi ya kawaida ambayo ninazungumza aliandika miaka michache iliyopita. Matokeo yake, picha hupakia kwa kasi zaidi, na ... kasi ya upakiaji wa wastani imeongezeka kwa 200 ms.

Hii ilitokea kwa sababu grafu imeundwa kulingana na data inayokuja na Jetty. Hiyo ni, maudhui ya haraka hayajajumuishwa katika hesabu - thamani ya wastani imeruka. Hili lilikuwa wazi kwetu, tulicheka, lakini tunawezaje kueleza bodi ya wakurugenzi kwa nini tulifanya kitu na mambo yakawa mabaya zaidi kwa 12%?

Siku ya themanini na tano

Mwishoni mwa mwezi wa tatu, niligundua kwamba kulikuwa na jambo moja ambalo sikuwa nimehesabu kabisa: wakati. Kila nilichozungumza kinachukua muda.

Hii ndiyo kalenda yangu halisi ya kila wiki - wiki ya kazi tu, isiyo na shughuli nyingi. Hakuna wakati wa kutosha kwa kila kitu. Kwa hiyo, tena, unahitaji kuajiri watu ambao watakusaidia kukabiliana na matatizo.

Hitimisho

Hiyo sio yote. Katika hadithi hii, hata sijapata jinsi tulivyofanya kazi na bidhaa na kujaribu kusikiliza wimbi la jumla, au jinsi tulivyounganisha usaidizi wa kiufundi, au jinsi tulivyotatua matatizo mengine ya kiufundi. Kwa mfano, nilijifunza kwa bahati mbaya kwamba kwenye meza kubwa zaidi kwenye hifadhidata hatutumii SEQUENCE. Tuna kazi iliyoandikwa kibinafsi nextID, na haitumiki katika muamala.

Kulikuwa na vitu vingine milioni sawa ambavyo tunaweza kuzungumza juu kwa muda mrefu. Lakini jambo muhimu zaidi ambalo bado linahitaji kusemwa ni utamaduni.

Ni utamaduni au ukosefu wake unaosababisha matatizo mengine yote. Tunajaribu kujenga utamaduni ambapo watu:

usiogope kushindwa;
jifunze kutokana na makosa;
kushirikiana na timu zingine;
kuchukua hatua;
kuchukua jukumu;
kukaribisha matokeo kama lengo;
kusherehekea mafanikio.

Pamoja na hili kila kitu kingine kitakuja.

Leon Moto kwenye twitter, facebook na kati.

Kuna mikakati miwili kuhusu urithi: epuka kufanya kazi nayo kwa gharama yoyote, au ushinde kwa ujasiri matatizo yanayohusiana. Sisi c DevOpsConf Tunachukua njia ya pili, kubadilisha taratibu na mbinu. Jiunge nasi kwenye youtube, Orodha ya barua и telegramu, na kwa pamoja tutatekeleza utamaduni wa DevOps.

Chanzo: mapenzi.com

Urithi wa mifumo na michakato ya urithi au siku 90 za Kwanza kama CTO