Ni jambo la kawaida kujua kwamba uwezo wa CTO hujaribiwa mara ya pili anapochukua jukumu hilo. Ni jambo moja kufanya kazi kwa kampuni kwa miaka kadhaa, ukibadilika sambamba nayo, na bado ndani ya muktadha huo huo wa kitamaduni, ukipata majukumu zaidi hatua kwa hatua. Ni jambo lingine kabisa kuingia moja kwa moja katika jukumu la CTO katika kampuni yenye matatizo mengi na masuala mengi yaliyofichwa vizuri.

Kwa maana hii, uzoefu wa Leon Fayer, ambao alishiriki katika DevOpsConfSio ya kipekee kabisa, lakini pamoja na uzoefu wake na idadi ya majukumu tofauti ambayo amechukua kwa zaidi ya miaka 20, ni muhimu sana. Hapa chini kuna mfuatano wa matukio kwa siku 90 na hadithi nyingi ambazo ni za kufurahisha kucheka zinapomtokea mtu mwingine, lakini si za kufurahisha sana kukutana nazo ana kwa ana.

Leon anaongea Kirusi kwa uwazi sana, kwa hivyo ikiwa una dakika 35-40, ninapendekeza utazame video. Toleo la maandishi liko hapa chini ili kuokoa muda.

Toleo la kwanza la ripoti lilikuwa maelezo yaliyopangwa vizuri ya kufanya kazi na watu na michakato, likiwa na mapendekezo muhimu. Lakini halikuonyesha mshangao wote uliojitokeza njiani. Kwa hivyo nilibadilisha muundo na kuwasilisha matatizo yaliyojitokeza katika kampuni mpya kama vile jack-in-the-box, na mbinu za kuyashughulikia, kwa mpangilio wa wakati.

Mwezi mmoja kabla

Kama hadithi nyingi nzuri, hii ilianza na pombe. Tulikuwa tumekaa kwenye baa na marafiki, na kama ilivyo kawaida katika miduara ya TEHAMA, kila mtu alikuwa akilalamika kuhusu matatizo yake. Mmoja wao alikuwa amebadilisha kazi na alikuwa akiniambia kuhusu matatizo yake kuhusu teknolojia, watu, na timu. Kadiri nilivyozidi kusikiliza, ndivyo nilivyozidi kugundua kwamba anapaswa kuniajiri, kwa sababu haya ndiyo aina ya matatizo ambayo nimekuwa nikitatua kwa miaka 15 iliyopita. Nilimwambia hivyo, na siku iliyofuata tulikutana katika mazingira ya kazi. Kampuni hiyo iliitwa Teaching Strategies.

Mikakati ya Kufundisha ni kiongozi wa soko katika programu za kielimu kwa watoto wadogo sana—kuanzia kuzaliwa hadi miaka mitatu. Kampuni ya jadi inayotegemea karatasi ina umri wa miaka 40, huku toleo la kidijitali la SaaS la jukwaa likiwa na umri wa miaka 10. Mchakato wa kurekebisha teknolojia ya kidijitali kulingana na viwango vya kampuni ulianza hivi karibuni. Toleo "mpya" lilizinduliwa mwaka wa 2017 na lilikuwa karibu sawa na lile la zamani, lakini lilikuwa na utendaji mdogo.

Jambo la kufurahisha zaidi ni kwamba trafiki ya kampuni hii inatabirika sana—siku baada ya siku, mwaka baada ya mwaka, unaweza kutabiri kwa usahihi ni watu wangapi watakuja na lini. Kwa mfano, kati ya saa 13 na 15 usiku, watoto wote katika shule ya chekechea hulala, na walimu huanza kuingiza taarifa. Na hii hutokea kila siku isipokuwa wikendi, kwa sababu karibu hakuna mtu anayefanya kazi wikendi.

Nikiangalia mbele kidogo, nitagundua kwamba nilianza kazi yangu wakati wa kipindi cha trafiki kubwa zaidi ya kila mwaka, jambo ambalo linavutia kwa sababu mbalimbali.

Jukwaa hilo, ambalo lilionekana kuwa na umri wa miaka miwili tu, lilikuwa na mrundiko wa kipekee: ColdFusion na SQL Server kuanzia mwaka wa 2008. ColdFusion, ikiwa hujui (na labda hujui), ni lugha ya PHP ya biashara iliyotoka katikati ya miaka ya 90, na hata sijasikia kuihusu tangu wakati huo. Pia ilikuwa na Ruby, MySQL, PostgreSQL, Java, Go, na Python. Lakini monolithi kuu ilitumika kwenye ColdFusion na SQL Server.

Shida

Kadiri nilivyozidi kuzungumza na wafanyakazi wa kampuni kuhusu kazi yao na changamoto walizokuwa wakikabiliana nazo, ndivyo nilivyozidi kugundua kuwa matatizo hayakuwa ya kiufundi tu. Sawa, teknolojia ilikuwa ya zamani—walikuwa wamefanya kazi nayo vibaya zaidi, lakini kulikuwa na matatizo na timu na michakato, na kampuni ilikuwa inaanza kuelewa hili.

Kijadi, mafundi wao walikuwa kwenye kona, wakifanya mambo yao wenyewe. Lakini biashara zaidi na zaidi zilianza kubadilika kidijitali. Kwa hivyo, katika mwaka uliopita kabla sijaanza kufanya kazi huko, kampuni iliongeza wanachama wapya: bodi ya wakurugenzi, CTO, CPO, na mkurugenzi wa QA. Kwa maneno mengine, kampuni ilianza kuwekeza katika teknolojia.

Mabaki ya urithi mgumu hayakuwa tu kwenye mifumo. Kampuni ilikuwa na michakato ya urithi, watu wa urithi, na utamaduni wa urithi. Yote haya yalihitaji kubadilishwa. Nilidhani hayangekuwa ya kuchosha, kwa hivyo niliamua kujaribu.

Siku mbili kabla

Siku mbili kabla ya kuanza kazi yangu mpya, nilifika ofisini, nikajaza karatasi za mwisho, nikakutana na timu, na kugundua kuwa walikuwa wakipambana na tatizo. Tatizo lilikuwa kwamba wastani wa muda wa kupakia ukurasa ulikuwa umeongezeka hadi sekunde 4, mara mbili.

Kwa kuzingatia grafu, kuna kitu kilikuwa kimeenda vibaya, na haikuwa wazi ni nini. Ilibainika kuwa tatizo la kuchelewa kwa mtandao katika kituo cha data: ms 5 za kuchelewa katika kituo cha data zilitafsiriwa kwa sekunde 2 kwa watumiaji. Sikujua ni kwa nini hii ilitokea, lakini angalau ikawa wazi kuwa tatizo lilikuwa katika kituo cha data.

Siku ya kwanza

Siku mbili zilipita, na siku yangu ya kwanza kazini niligundua kuwa tatizo halikuwa limeisha.

Kwa siku mbili, kurasa za watumiaji zilikuwa zikipakia kwa wastani wa sekunde 4. Niliwauliza kama wamepata tatizo.

- Ndiyo, tulifungua tiketi.
- NA?
- Naam, bado hawajatujibu.

Hapa niligundua kwamba kila kitu nilichokuwa nimeambiwa hapo awali kilikuwa ni ncha tu ya barafu iliyohitaji kupigwa vita.

Kuna nukuu nzuri ambayo inafaa sana kwa kesi hii:

"Wakati mwingine ili kubadilisha teknolojia lazima ubadilishe shirika."

Lakini kwa kuwa nilianza kazi wakati wa kipindi chenye shughuli nyingi zaidi mwakani, ilinibidi kuzingatia suluhisho za haraka na za muda mrefu. Na ilinibidi nianze na kile kilichokuwa muhimu hivi sasa.

Siku ya tatu

Kwa hivyo, muda wa kupakia ni sekunde 4, na kilele kikubwa zaidi ni kuanzia 13 hadi 15.

Siku ya tatu katika kipindi hiki cha muda, kasi ya kupakua ilionekana hivi:

Kwa mtazamo wangu, hakuna kilichofanya kazi hata kidogo. Kwa mtazamo wa kila mtu mwingine, ilifanya kazi polepole kidogo kuliko kawaida. Lakini hilo halitokei tu—ni tatizo kubwa.

Nilijaribu kuishawishi timu, lakini waliniambia wanahitaji seva zaidi. Hilo hakika ni suluhisho, lakini si suluhisho pekee au lenye ufanisi zaidi. Niliuliza kwa nini hakukuwa na seva za kutosha na kiasi cha trafiki kilikuwa kiasi gani. Nilichanganua data na kugundua kuwa tulikuwa na maombi yapatayo 150 kwa sekunde, ambayo kwa ujumla iko ndani ya mipaka inayofaa.

Lakini hatupaswi kusahau kwamba kabla ya kupata jibu sahihi, ni lazima tuulize swali sahihi. Swali langu linalofuata lilikuwa: je, tuna seva ngapi za mbele? Jibu "lilinishangaza" kidogo—tulikuwa na seva 17 za mbele!

— Ninaona aibu kuuliza, lakini 150 ikigawanywa na 17 ni sawa na takriban 8? Unasema kwamba kila seva inashughulikia maombi 8 kwa sekunde, na ikiwa kesho tutakuwa na maombi 160 kwa sekunde, tutahitaji seva mbili zaidi?

Bila shaka, hatukuhitaji seva za ziada. Suluhisho lilikuwa katika msimbo wenyewe, hapo hapo juu:

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

Kulikuwa na kazi getCurrentClass(), kwa sababu kila kitu kwenye tovuti hufanya kazi katika muktadha wa darasa—kwa usahihi. Na kwa kipengele hiki kimoja kwenye kila ukurasa, Maombi zaidi ya 200.

Kwa hivyo suluhisho lilikuwa rahisi sana, hakukuwa na haja hata ya kuandika upya chochote: usiombe taarifa hiyo hiyo tena.

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

Nilifurahi sana kwa sababu nilidhani nimepata tatizo kuu siku ya tatu tu. Jinsi nilivyokuwa mjinga, lilikuwa moja tu kati ya matatizo mengi.

Lakini kutatua tatizo hili la kwanza kulishusha grafu chini sana.

Wakati huo huo, tulikuwa tukifanya kazi kwenye uboreshaji mwingine. Kulikuwa na mambo mengi ambayo yangeweza kurekebishwa mara moja. Kwa mfano, siku hiyo ya tatu, niligundua kuwa mfumo ulikuwa na kashe (mwanzoni, nilidhani maombi yote yalikuwa yanatoka moja kwa moja kutoka kwenye hifadhidata). Ninapofikiria kashe, ninapiga picha Redis ya kawaida au Memcached. Lakini hiyo ilikuwa mimi tu, kwa sababu kashe katika mfumo huo ilikuwa ikitumia MongoDB na SQL Server—ile ile ile ambayo tungesoma data kutoka kwayo.

Siku ya kumi

Nilitumia wiki ya kwanza kushughulikia masuala yaliyohitaji kushughulikiwa mara moja. Karibu wiki ya pili, nilikuja kwenye mkutano wa kusimama kwa mara ya kwanza kuzungumza na timu, kuona kinachoendelea, na jinsi mchakato mzima ulivyokuwa ukiendelea.

Kitu cha kuvutia kilitokea tena. Timu hiyo ilikuwa na: watengenezaji 18; wapimaji 8; mameneja 3; wasanifu majengo 2. Na wote walishiriki katika mila za pamoja, ikimaanisha kuwa zaidi ya watu 30 walikuja kwenye jukwaa kila asubuhi na kutoa taarifa kuhusu walichokuwa wakifanya. Ni wazi kwamba mkutano haukuchukua dakika 5 au 15. Hakuna mtu aliyemsikiliza mtu mwingine yeyote kwa sababu kila mtu alifanya kazi kwenye mifumo tofauti. Katika muundo huu, tiketi 2-3 kwa saa wakati wa kikao cha urembo tayari zilikuwa matokeo mazuri.

Jambo la kwanza tulilofanya ni kuigawanya timu katika mistari kadhaa ya bidhaa. Kwa sehemu na mifumo tofauti, tuliunda timu tofauti, ikiwa ni pamoja na watengenezaji programu, wapimaji, wasimamizi wa bidhaa, na wachambuzi wa biashara.

Matokeo yalikuwa:

• Kupunguza mikusanyiko na mikutano ya hadhara.
• Ujuzi wa mada kuhusu bidhaa.
• Hisia ya umiliki. Watu walipokuwa wakizunguka-zunguka kati ya mifumo kila mara, walijua kwamba hitilafu zao zingeweza kushughulikiwa na mtu mwingine, si wao wenyewe.
• Ushirikiano kati ya timu. Bila shaka, QA na waandaaji wa programu hawakuwa wameingiliana sana hapo awali; meneja wa bidhaa alikuwa akifanya mambo yake mwenyewe, nk. Sasa wana uwajibikaji wa pamoja.

Lengo letu kuu lilikuwa katika ufanisi, tija, na ubora—haya ndiyo matatizo tuliyokuwa tunajaribu kuyatatua kwa kubadilisha timu.

Siku ya kumi na moja

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

Niligunduaje hili?

Tulipata hitilafu: katika moja ya ripoti, ambapo unaingiza tarehe za mwanzo na mwisho za kipindi unachohitaji ripoti, siku ya mwisho haijazingatiwa. Hiyo ni, mahali fulani katika swali hapakuwa na <=, lakini < tu. Niliambiwa kwamba hii ni Pointi tatu za Hadithi, ikimaanisha 3 siku.

Baada ya hapo sisi:

• Tumerekebisha mfumo wa Pointi za Hadithi. Sasa, marekebisho madogo ya hitilafu ambayo yanaweza kushughulikiwa haraka kupitia mfumo yanawafikia watumiaji haraka zaidi.
• Tulianza kuunganisha tiketi zinazohusiana za ukuzaji na majaribio. Hapo awali, kila tiketi, kila hitilafu, ilikuwa mfumo ikolojia uliofungwa, usiounganishwa na kitu kingine chochote. Kubadilisha vitufe vitatu kwenye ukurasa mmoja kunaweza kusababisha tiketi tatu tofauti zenye michakato mitatu tofauti ya QA badala ya jaribio moja otomatiki kwa kila ukurasa.
• Tulianza kufanya kazi na watengenezaji wa programu katika mbinu ya kukadiria gharama za wafanyakazi. Siku tatu za kubadilisha kitufe kimoja si jambo la kuchekesha.

Siku ya Ishirini

Mahali fulani karibu katikati ya mwezi wa kwanza, hali ilitulia kidogo, niligundua kinachoendelea kimsingi, na nikaanza kutazama wakati ujao na kufikiria kuhusu suluhisho za muda mrefu.

Malengo ya muda mrefu:

• Jukwaa linalosimamiwa. Mamia ya maswali kwenye kila ukurasa si mazito.
• Mitindo inayoweza kutabirika. Kulikuwa na kilele cha trafiki mara kwa mara ambacho, mwanzoni, hakikuonekana kuhusishwa na vipimo vingine—tulihitaji kuelewa ni kwa nini hii ilitokea na kujifunza kuitabiri.
• Upanuzi wa jukwaa. Biashara inakua kila mara, watumiaji wengi zaidi wanakuja, na trafiki inaongezeka.

Zamani mara nyingi ilisemwa: "Tuandike kila kitu upya katika [lugha/mfumo], kila kitu kitafanya kazi vizuri zaidi!"

Mara nyingi, hii haifanyi kazi; ni jambo zuri ikiwa uandishi upya utafanya kazi kabisa. Kwa hivyo tulihitaji kuunda ramani—mkakati halisi unaoonyesha hatua kwa hatua jinsi tutakavyofikia malengo yetu ya biashara (tutafanya nini na kwa nini), ambayo:

• inaonyesha dhamira na malengo ya mradi;
• huweka kipaumbele malengo muhimu;
• ina ratiba ya kuyafikia.

Kabla ya hili, hakuna mtu aliyejadiliana na timu kuhusu madhumuni ya mabadiliko yoyote. Hii inahitaji vipimo sahihi vya mafanikio. Kwa mara ya kwanza katika historia ya kampuni, tuliweka KPI kwa timu ya kiufundi, na tukaunganisha vipimo hivi na vile vya shirika.

Kwa maneno mengine, KPI za shirika zinaungwa mkono na timu, na KPI za timu zinaungwa mkono na KPI za kibinafsi. Vinginevyo, ikiwa KPI za mchakato haziendani na zile za shirika, kila mtu atabaki ameshikilia mfuko.

Kwa mfano, moja ya KPI za shirika inaongeza sehemu ya soko kupitia bidhaa mpya.

Tunawezaje kuunga mkono lengo la kuwa na bidhaa mpya zaidi?

• Kwanza, tunataka kutumia muda mwingi kutengeneza bidhaa mpya badala ya kurekebisha kasoro. Huu ni uamuzi wa kimantiki ambao unaweza kupimika kwa urahisi.
• Pili, tunataka kusaidia ukuaji wa kiasi cha miamala, kwa sababu kadiri sehemu kubwa ya soko inavyokuwa, ndivyo watumiaji wengi na, kwa hivyo, ndivyo trafiki inavyoongezeka.

Kisha, KPI za kibinafsi zinazoweza kutekelezwa ndani ya kikundi zitakuwa, kwa mfano, mahali ambapo kasoro kuu zinaanzia. Kwa kuzingatia hasa sehemu hii, unaweza kupunguza kasoro kwa kiasi kikubwa, kuongeza muda unaotumika kutengeneza bidhaa mpya na, tena, kusaidia KPI za shirika.

Kwa hivyo, kila uamuzi, ikiwa ni pamoja na kuandika upya kanuni, lazima uunge mkono malengo mahususi ambayo kampuni imetuwekea (ukuaji wa shirika, vipengele vipya, kuajiri).

Wakati wa mchakato huu, jambo la kuvutia liliibuka, ambalo lilikuwa habari mpya si kwa timu ya kiufundi tu bali pia kwa kampuni kwa ujumla: tiketi zote lazima zilenge angalau KPI moja. Kwa hivyo, ikiwa meneja wa bidhaa anasema wanataka kujenga kipengele kipya, swali la kwanza linapaswa kuwa, "Kipengele hiki kinaunga mkono KPI gani?" Ikiwa hakuna, basi, samahani—inaonekana kama kipengele kisicho cha lazima.

Siku ya Thelathini

Mwishoni mwa mwezi, niligundua jambo lingine: hakuna mtu katika timu yangu ya Ops aliyewahi kuona mikataba tunayosaini na wateja. Unaweza kuuliza, kwa nini mtu yeyote angependa kuona anwani?

• Kwanza, kwa sababu SLA zimeainishwa katika mikataba.
• Pili, SLA zote ni tofauti. Kila mteja alikuja na mahitaji yake mwenyewe, na timu ya mauzo iliyasaini bila kuyaangalia.

Maelezo mengine ya kuvutia: mkataba na mmoja wa wateja wetu wakubwa unasema kwamba matoleo yote ya programu yanayoungwa mkono na mfumo lazima yawe n-1, ikimaanisha si toleo jipya zaidi, bali toleo la pili kutoka la mwisho.

Ni wazi jinsi tulivyokuwa mbali na n-1 ikiwa mfumo huo ulitegemea ColdFusion na SQL Server 2008, ambayo haikuungwa mkono tena mwezi Julai.

Siku ya arobaini na tano

Mahali fulani karibu katikati ya mwezi wa pili nilikuwa na muda wa kutosha kukaa chini na kufanya thamanimkondoramani Mchakato mzima. Hizi ni hatua muhimu zinazopaswa kuchukuliwa, kuanzia uundaji wa bidhaa hadi uwasilishaji kwa mtumiaji, na lazima zielezwe kwa undani iwezekanavyo.

Unagawanya mchakato huo katika vipande vidogo na kuangalia kinachochukua muda mrefu sana, kinachoweza kuboreshwa, kuboreshwa, n.k. Kwa mfano, inachukua muda gani kwa ombi la bidhaa kupitia urembo, linafikia lini tikiti ambayo msanidi programu anaweza kushughulikia, QA, n.k. Unaangalia kila hatua kwa undani na kufikiria kinachoweza kuboreshwa.

Nilipokuwa nikifanya hivi, mambo mawili yalinivutia:

• asilimia kubwa ya tiketi zilizorejeshwa kutoka QA kwa watengenezaji;
• Mapitio ya ombi la kuvuta yalichukua muda mrefu sana.

Shida ilikuwa kwamba haya yalikuwa hitimisho kama: inaonekana kuchukua muda mrefu, lakini hatuna uhakika ni kiasi gani hasa.

"Huwezi kuboresha kile ambacho huwezi kupima."

Unawezaje kuhalalisha jinsi tatizo lilivyo kubwa? Je, ni kupoteza siku au saa?

Ili kupima hili, tuliongeza hatua kadhaa kwenye mchakato wa Jira: "tayari kwa ajili ya usanidi programu" na "tayari kwa ajili ya QA" ili kupima muda ambao kila tiketi inasubiri na mara ngapi inarudi kwenye hatua fulani.

Pia tuliongeza "katika ukaguzi" ili kufuatilia wastani wa muda ambao tiketi zinakaguliwa, na kisha tunaweza kuanza kupima vitu kuanzia hapo. Tayari tulikuwa na vipimo vya mfumo, lakini sasa tumeongeza vipya na tumeanza kupima:

• Ufanisi wa mchakato: utendaji na mipango/kutekelezwa.
• Ubora wa mchakato: idadi ya kasoro, kasoro kutoka QA.

Inasaidia sana kuelewa kinachoendelea vizuri na kinachoendelea vibaya.

Siku ya hamsini

Haya yote ni mazuri na ya kuvutia, bila shaka, lakini kuelekea mwisho wa mwezi wa pili, jambo lilitokea ambalo kimsingi lilikuwa linatabirika, ingawa sikutarajia kiwango kama hicho. Watu walianza kuondoka kwa sababu viongozi wa juu walikuwa wamebadilika. Watu wapya waliingia katika usimamizi na wakaanza kubadilisha kila kitu, na wale wa zamani waliacha kazi. Na kwa kawaida, katika kampuni ambayo imekuwapo kwa miaka michache, kila mtu ni rafiki na kila mtu anafahamiana.

Hili lilitarajiwa, lakini ukubwa wa kufukuzwa kazi haukutarajiwa. Kwa mfano, katika wiki moja, viongozi wawili wa timu waliwasilisha kujiuzulu kwao kwa wakati mmoja. Kwa hivyo, ilinibidi si tu kusahau masuala mengine, lakini pia kuzingatia kuunda timuHili ni tatizo refu na gumu kulitatua, lakini lilibidi lishughulikiwe kwa sababu tulitaka kuwaweka watu waliobaki (au angalau wengi wao). Tulilazimika kwa namna fulani kuwajibu watu walioondoka ili kudumisha ari kwenye timu.

Kinadharia, hili ni jambo zuri: mtu mpya anafika akiwa na kadi kamili, anaweza kutathmini ujuzi wa timu, na kuchukua nafasi ya wafanyakazi waliopo. Kwa kweli, haiwezekani kuleta watu wapya kwa sababu mbalimbali. Daima kuna haja ya usawa.

• Zamani na mpya. Tunahitaji kuwahifadhi wazee ambao wanaweza kubadilisha na kuunga mkono misheni. Lakini wakati huo huo, tunahitaji kuleta damu mpya, ambayo tutaijadili baadaye kidogo.
• Uzoefu. Nilizungumza sana na wanafunzi wazuri wa kidato cha kwanza ambao walikuwa na hamu ya kujiunga nasi. Lakini sikuweza kuwaajiri kwa sababu hakukuwa na wazee wa kutosha kuwasaidia na kuwashauri. Tulilazimika kuajiri vijana wa juu kwanza, na kisha vijana tu.
• Karoti na kijiti.

Sina jibu zuri kwa swali la uwiano sahihi ni upi, jinsi ya kuudumisha, ni watu wangapi wa kuwa nao, na shinikizo kiasi gani la kutumia. Ni mchakato wa mtu binafsi tu.

Siku ya hamsini na moja

Nilianza kutazama timu ili kuona ni nani niliyekuwa naye, na kwa mara nyingine tena nikakumbuka:

"Matatizo mengi ni matatizo ya watu."

Niligundua kuwa timu nzima, watengenezaji na Ops, ilikuwa na matatizo matatu makubwa:

• Kuridhika na hali ya sasa.
• Ukosefu wa uwajibikaji — kwa sababu hakuna mtu aliyewahi kutafsiri matokeo ya kazi ya waigizaji kuwa athari yao kwenye biashara.
• Hofu ya mabadiliko.

Mabadiliko hukuondoa katika eneo lako la starehe, na vijana wanapokuwa hivyo, ndivyo wanavyozidi kuchukia mabadiliko kwa sababu hawaelewi ni kwa nini au vipi. Jibu la kawaida nililosikia lilikuwa, "Hatujawahi kufanya hivyo." Hili lilifikia hatua ya upuuzi kabisa—hata mabadiliko madogo hayangepita bila mtu kulalamika. Na haijalishi mabadiliko yaliathiri kazi yao kiasi gani, watu wangesema, "Hapana, kwa nini ujisumbue? Hayatafanya kazi."

Lakini huwezi kuwa bora bila kubadilisha chochote.

Nilikuwa na mazungumzo ya kipuuzi kabisa na mfanyakazi, nilikuwa nikimwambia mawazo yangu ya uboreshaji, ambayo alisema:
- Ah, hukuona kile tulichokuwa nacho mwaka jana!
- Kwa hiyo?
— Ni bora zaidi sasa kuliko ilivyokuwa.
- Kwa hivyo, haiwezi kuwa bora zaidi?
- Kwa nini?

Swali zuri—kwa nini? Kana kwamba kama mambo ni bora sasa kuliko yalivyokuwa, basi kila kitu ni kizuri vya kutosha. Hii inasababisha ukosefu wa uwajibikaji, jambo ambalo ni la kawaida kabisa. Kama nilivyosema, kundi la teknolojia lilikuwa pembeni kidogo. Kampuni ilifikiri wanapaswa kuwa hapo, lakini hakuna mtu aliyewahi kuweka viwangoUsaidizi wa teknolojia haukuwahi kuona SLA, kwa hivyo kwa kundi hilo ilikuwa "inakubalika" kikamilifu (na hiyo ndiyo iliyonigusa zaidi):

• Sekunde 12 za kupakia;
• Muda wa kupumzika wa dakika 5-10 kwa kila toleo;
• Masuala muhimu huchukua siku na wiki kutatuliwa;
• Hakuna wafanyakazi wa saa 24 kwa siku, siku 7 kwa siku.

Hakuna mtu aliyewahi kujaribu kuuliza kwa nini hatuwezi kufanya vizuri zaidi, na hakuna mtu aliyewahi kutambua kwamba haipaswi kuwa hivi.

Kama bonasi, kulikuwa na tatizo moja zaidi: ukosefu wa uzoefuWazee waliondoka, na timu iliyobaki ya vijana ilikua chini ya utawala uliopita na ikapewa sumu nayo.

Zaidi ya hayo yote, watu pia waliogopa kushindwa na kuonekana hawana uwezo. Hii ilionyeshwa katika ukweli kwamba, kwanza, bila kujali hali yoyote, hakuna aliyeomba msaadaNi mara ngapi tumekuwa na mazungumzo katika vikundi na kibinafsi, na nimewahi kusema, "Uliza swali ikiwa hujui jinsi ya kufanya jambo?" Ninajiamini na najua naweza kutatua tatizo lolote, lakini itachukua muda. Kwa hivyo nikiweza kumuuliza mtu anayejua jinsi ya kulitatua kwa dakika 10, nitafanya hivyo. Kadiri unavyokuwa na uzoefu mdogo, ndivyo unavyozidi kuogopa kuuliza, kwa sababu unafikiri utachukuliwa kuwa huna uwezo.

Hofu hii ya kuuliza maswali inajidhihirisha kwa njia za kuvutia. Kwa mfano, unauliza, "Kazi hii inaendeleaje?" nao wanasema, "Ni saa chache tu, karibu nimemaliza." Siku inayofuata, unauliza tena na unaambiwa kila kitu kiko sawa, lakini kuna tatizo moja tu, na hakika litakamilika mwishoni mwa siku. Siku nyingine inapita, na hadi utakapowazuia na kuwalazimisha kuzungumza na mtu, mambo yanaendelea hivi. Wanataka kutatua tatizo wenyewe, wakiamini kwamba kutotatua tatizo wenyewe kutakuwa kushindwa kubwa.

Ndiyo sababu watengenezaji waliongeza makadirioIlikuwa ni utani sana: tulipokuwa tukijadili kazi maalum, walinipa takwimu ambayo ilinishangaza sana. Waliniambia kwamba katika makadirio yao, msanidi programu anajumuisha muda utakaochukua kwa tiketi kurudishwa kutoka QA kwa sababu wanapata hitilafu, muda utakaochukua kwa PR, na muda ambao watu wanaopaswa kuupitia wana shughuli nyingi—kwa maneno mengine, kila kitu kinawezekana.

Pili, watu wanaoogopa kuonekana hawana uwezo, uchanganuzi kupita kiasiUnapowaambia nini hasa kinachohitajika kufanywa, wanaanza kusema, "Hapana, vipi tukifikiria hapa?" Kwa maana hii, kampuni yetu si ya kipekee; ni tatizo la kawaida miongoni mwa vijana.

Kujibu, nilianzisha mazoea yafuatayo:

• Sheria ya dakika 30. Ikiwa huwezi kutatua tatizo hilo kwa nusu saa, muombe mtu mwingine akusaidie. Hii inafanya kazi kwa mafanikio tofauti, kwa sababu watu hawaombi hata hivyo, lakini angalau mchakato umeanza.
• Ondoa kila kitu isipokuwa kiini, katika kukadiria muda unaochukua kukamilisha kazi, yaani, fikiria tu muda utakaochukua kuandika msimbo.
• Kuendelea kujifunza Kwa wale wanaochambua kupita kiasi. Ni kazi ya mara kwa mara na watu.

Siku ya sitini

Nilipokuwa nikifanya haya yote, ilikuwa wakati wa kupanga bajeti. Bila shaka, nilipata mambo mengi ya kuvutia kuhusu jinsi tulivyokuwa tukitumia pesa. Kwa mfano, tulikuwa na rafu nzima katika kituo tofauti cha data kilichokuwa na seva moja ya FTP inayotumiwa na mteja mmoja. Ilibainika kuwa "...tulihama, lakini ilibaki pale, hatukuibadilisha." Hiyo ilikuwa miaka miwili iliyopita.

Muswada wa wingu ulikuwa wa kuvutia sana. Nina uhakika sababu kuu ya muswada wa wingu kubwa ni kwamba watengenezaji, kwa mara ya kwanza maishani mwao, wana ufikiaji usio na kikomo wa seva. Hawahitaji kuuliza, "Tafadhali nipe seva ya majaribio"—wanaweza kuichukua wenyewe. Zaidi ya hayo, watengenezaji daima wanataka kujenga mfumo mzuri sana hivi kwamba Facebook na Netflix wangeona wivu.

Lakini watengenezaji hawana uzoefu katika ununuzi wa seva na ujuzi wa kubaini ukubwa sahihi wa seva kwa sababu hawajawahi kuhitaji kufanya hivyo hapo awali. Na mara nyingi hawaelewi kikamilifu tofauti kati ya uwezo wa kupanuka na utendaji.

Matokeo ya hesabu:

• Ilitoka katika kituo kimoja cha data.
• Tulisitisha mikataba na huduma tatu za ukataji miti. Kwa sababu tulikuwa na mitano kati yao—kila msanidi programu aliyeanza kucheza na kitu fulani angeajiri mpya.
• Mifumo saba ya AWS ilifungwa. Tena, miradi iliyokufa haikufungwa; iliendelea kufanya kazi.
• Kupunguza gharama za programu kwa mara 6.

Siku ya sabini na tano

Muda ulipita, na katika miezi miwili na nusu nilipangiwa kukutana na bodi ya wakurugenzi. Bodi yetu ya wakurugenzi si bora au mbaya kuliko nyingine yoyote; kama bodi zote, inataka kujua kila kitu. Watu huwekeza pesa na wanataka kuelewa jinsi kazi yetu inavyoendana na KPI zetu.

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

Shida pekee ni kwamba nadhani wastani ni uovu mtupu. Lakini ni vigumu sana kuelezea hili kwa bodi ya wakurugenzi. Wamezoea kufanya kazi na nambari zilizokusanywa, si, kwa mfano, kuenea kwa nyakati za mzigo kwa sekunde.

Kulikuwa na mambo ya kuvutia katika suala hili. Kwa mfano, nilisema kwamba trafiki inapaswa kugawanywa kati ya seva tofauti za wavuti kulingana na aina ya maudhui.

Kwa hivyo, ColdFusion hupitia Jetty na nginx na kuendesha kurasa. Na picha, JS, na CSS hupitia nginx tofauti yenye usanidi wake. Huu ni utaratibu wa kawaida, ambao ninazungumzia. aliandika Miaka michache tu iliyopita. Matokeo yake, picha hupakia kwa kasi zaidi, na... kasi ya wastani ya upakiaji iliongezeka kwa milisekunde 200.

Hili lilitokea kwa sababu grafu inategemea data inayotoka Jetty. Yaani, maudhui ya haraka hayajajumuishwa katika hesabu—takwimu ya wastani iliongezeka. Tulielewa hili, na tulicheka, lakini tunawezaje kuelezea bodi ya wakurugenzi kwa nini tulifanya jambo lililosababisha kushuka kwa 12%?

Siku ya themanini na tano

Kufikia mwisho wa mwezi wa tatu, niligundua kuwa kulikuwa na jambo moja ambalo sikulitegemea kabisa: wakati. Kila kitu ambacho nimezungumzia kinachukua muda.

Hii ni kalenda yangu halisi ya kila wiki—wiki rahisi ya kazi, si yenye shughuli nyingi. Hakuna muda wa kutosha kwa kila kitu. Kwa hivyo, tena, ninahitaji kuajiri watu wa kunisaidia kushughulikia matatizo.

Hitimisho

Sio hayo tu. Katika hadithi hii, sijaelewa hata jinsi tulivyofanya kazi na bidhaa hiyo na kujaribu kufikia lengo moja, au jinsi tulivyounganisha usaidizi wa kiteknolojia, au jinsi tulivyotatua matatizo mengine ya kiufundi. Kwa mfano, niligundua kwa bahati mbaya kwamba hatutumii SEQUENCETuna kazi ya kujiandikia nextID, na haitumiki katika muamala.

Kulikuwa na mambo mengine milioni kama hayo ambayo yangeweza kujadiliwa kwa kirefu. Lakini jambo muhimu zaidi linalostahili kutajwa ni utamaduni.

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

• hawaogopi kushindwa;
• jifunze kutokana na makosa;
• kushirikiana na timu zingine;
• onyesha mpango;
• kuchukua jukumu;
• kukaribisha matokeo kama lengo;
• kusherehekea mafanikio.

Kwa hili, kila kitu kingine kitakuja.

Moto wa Leon kwenye Twitter, facebook na kati.

Kuna mikakati miwili ya kushughulikia urithi: kuepuka kwa gharama yoyote, au kushinda kwa ujasiri matatizo yanayoambatana nao. DevOpsConf Tunachukua njia ya pili, tukibadilisha michakato na mbinu. Jiunge nasi katika youtube, Orodha ya barua и telegramu, na kwa pamoja tutatekeleza utamaduni wa DevOps.

Chanzo: mapenzi.com