Nabatid na nasusubok pa lamang ang husay ng CTO sa ikalawang pagkakataong ginampanan niya ang tungkuling ito. Dahil isang bagay ang magtrabaho sa isang kumpanya sa loob ng ilang taon, mag-evolve kasama nito at, dahil nasa parehong konteksto ng kultura, unti-unting tumanggap ng higit pang responsibilidad. At isa pa ang dumiretso sa posisyon ng teknikal na direktor sa isang kumpanyang may legacy na bagahe at isang grupo ng mga problema na maayos na naalis sa ilalim ng alpombra.

Sa ganitong diwa, ang karanasan ni Leon Fire, kung saan ibinahagi niya DevOpsConf, hindi dahil siya ay direktang kakaiba, ngunit pinarami ng kanyang karanasan at ang bilang ng iba't ibang mga tungkulin na nagawa niyang subukan sa loob ng 20 taon, ito ay lubhang kapaki-pakinabang. Sa ibaba ng cut ay isang kronolohiya ng mga kaganapan sa loob ng 90 araw at maraming mga kuwento na nakakatuwang pagtawanan kapag nangyari ang mga ito sa ibang tao, ngunit hindi masyadong nakakatuwang harapin nang personal.

Makulay na nagsasalita si Leon sa Russian, kaya kung mayroon kang 35-40 minuto, inirerekomenda kong panoorin ang video. Bersyon ng teksto upang makatipid ng oras sa ibaba.

Ang unang bersyon ng ulat ay isang mahusay na nakabalangkas na paglalarawan ng pakikipagtulungan sa mga tao at mga proseso, na naglalaman ng mga kapaki-pakinabang na rekomendasyon. Ngunit hindi niya sinabi ang lahat ng mga sorpresa na nakatagpo sa daan. Samakatuwid, binago ko ang format at ipinakita ang mga problemang lumitaw sa harap ko tulad ng isang jack-in-the-box sa bagong kumpanya, at mga pamamaraan para sa paglutas ng mga ito sa magkakasunod na pagkakasunud-sunod.

Isang buwan bago

Tulad ng maraming magagandang kwento, nagsimula ang isang ito sa alak. Nakaupo kami kasama ang mga kaibigan sa isang bar, at gaya ng inaasahan sa mga IT specialist, lahat ay umiiyak tungkol sa kanilang mga problema. Ang isa sa kanila ay nagbago lang ng trabaho at pinag-uusapan ang kanyang mga problema sa teknolohiya, at sa mga tao, at sa koponan. The more I listened, the more I realized na dapat na lang niya akong i-hire, dahil ito ang mga tipo ng problemang na-solve ko for the last 15 years. Sinabi ko sa kanya, at kinabukasan ay nagkita kami sa isang kapaligiran sa trabaho. Ang kumpanya ay tinawag na Mga Istratehiya sa Pagtuturo.

Ang Mga Istratehiya sa Pagtuturo ay isang market leader sa curriculum para sa napakabata na bata mula sa kapanganakan hanggang tatlong taong gulang. Ang tradisyunal na kumpanya ng "papel" ay 40 taong gulang na, at ang digital na bersyon ng SaaS ng platform ay 10 taong gulang. Kamakailan lamang, nagsimula ang proseso ng pag-angkop ng digital na teknolohiya sa mga pamantayan ng kumpanya. Ang "bagong" bersyon ay inilunsad noong 2017 at halos katulad ng luma, ngunit ito ay gumana nang mas malala.

Ang pinaka-kagiliw-giliw na bagay ay ang trapiko ng kumpanyang ito ay nahuhulaan - araw-araw, bawat taon, malinaw mong mahulaan kung ilang tao ang darating at kailan. Halimbawa, sa pagitan ng 13 at 15 p.m. ang lahat ng mga bata sa kindergarten ay natutulog at ang mga guro ay nagsimulang magpasok ng impormasyon. At ito ay nangyayari araw-araw, maliban sa katapusan ng linggo, dahil halos walang nagtatrabaho sa katapusan ng linggo.

Sa hinaharap, mapapansin kong sinimulan ko ang aking trabaho sa panahon ng pinakamataas na taunang trapiko, na kawili-wili sa iba't ibang dahilan.

Ang platform, na tila 2 taong gulang pa lang, ay may kakaibang stack: ColdFusion & SQL Server mula 2008. Ang ColdFusion, kung hindi mo alam, at malamang na hindi mo alam, ay isang enterprise PHP na lumabas noong kalagitnaan ng 90s, at mula noon ay hindi ko na ito narinig. Mayroon ding: Ruby, MySQL, PostgreSQL, Java, Go, Python. Ngunit ang pangunahing monolith ay tumakbo sa ColdFusion at SQL Server.

Mga Problema

Habang nakikipag-usap ako sa mga empleyado ng kumpanya tungkol sa trabaho at kung anong mga problema ang nakatagpo, mas napagtanto ko na ang mga problema ay hindi lamang teknikal sa kalikasan. Okay, luma na ang teknolohiya - at hindi nila ito ginawa, ngunit may mga problema sa koponan at sa mga proseso, at nagsimulang maunawaan ito ng kumpanya.

Ayon sa kaugalian, ang kanilang mga techies ay nakaupo sa sulok at gumawa ng ilang uri ng trabaho. Ngunit mas maraming negosyo ang nagsimulang dumaan sa digital na bersyon. Samakatuwid, noong nakaraang taon bago ako nagsimulang magtrabaho, lumitaw ang mga bago sa kumpanya: board of directors, CTO, CPO at QA director. Iyon ay, nagsimulang mamuhunan ang kumpanya sa sektor ng teknolohiya.

Ang mga bakas ng isang mabigat na pamana ay hindi lamang sa mga sistema. Ang kumpanya ay may legacy na proseso, legacy na mga tao, legacy culture. Ang lahat ng ito ay kailangang baguhin. Naisip ko na tiyak na hindi ito magiging mainip, at nagpasyang subukan ito.

Dalawang araw bago

Dalawang araw bago magsimula ng isang bagong trabaho, dumating ako sa opisina, pinunan ang huling papeles, nakilala ang koponan, at natuklasan na ang koponan ay nahihirapan sa isang problema sa oras na iyon. Ang average na oras ng paglo-load ng pahina ay tumalon sa 4 na segundo, iyon ay, 2 beses.

Sa paghusga sa graph, may malinaw na nangyari, at hindi malinaw kung ano. Lumalabas na ang latency ng network sa data center ang problema: 5 ms latency sa data center naging 2 s para sa mga user. Hindi ko alam kung bakit nangyari ito, ngunit sa anumang kaso nalaman na ang problema ay nasa data center.

Araw isa

Lumipas ang dalawang araw at sa unang araw ko sa trabaho ay natuklasan kong hindi pa rin nawawala ang problema.

Sa loob ng dalawang araw, na-load ang mga page ng user sa average sa loob ng 4 na segundo. Tinatanong ko kung nakita nila kung ano ang problema.

- Oo, nagbukas kami ng tiket.
- AT?
- Well, hindi pa nila kami sinasagot.

Pagkatapos ay napagtanto ko na ang lahat ng sinabi sa akin noon ay isang maliit na dulo lamang ng malaking bato ng yelo na kailangan kong labanan.

May magandang quote na akma dito:

"Minsan para baguhin ang teknolohiya kailangan mong baguhin ang organisasyon."

Ngunit dahil nagsimula akong magtrabaho sa pinaka-abalang oras ng taon, kailangan kong tingnan ang parehong mga opsyon para sa paglutas ng problema: parehong mabilis at pangmatagalan. At magsimula sa kung ano ang kritikal ngayon.

Araw tatlong

Kaya, ang paglo-load ay tumatagal ng 4 na segundo, at mula 13 hanggang 15 ang pinakamalaking mga taluktok.

Sa ikatlong araw sa panahong ito, ang bilis ng pag-download ay ganito:

Mula sa aking pananaw, walang gumana sa lahat. Mula sa pananaw ng iba, medyo mas mabagal ito kaysa karaniwan. Ngunit hindi ito nangyayari nang ganoon—ito ay isang seryosong problema.

Sinubukan kong kumbinsihin ang koponan, kung saan sinagot nila na kailangan lang nila ng higit pang mga server. Ito, siyempre, ay isang solusyon sa problema, ngunit hindi ito palaging ang tanging at pinaka-epektibo. Tinanong ko kung bakit walang sapat na mga server, kung ano ang dami ng trapiko. Na-extrapolate ko ang data at nalaman kong mayroon kaming humigit-kumulang 150 kahilingan sa bawat segundo, na, sa prinsipyo, ay nasa loob ng mga makatwirang limitasyon.

Ngunit hindi natin dapat kalimutan na bago mo makuha ang tamang sagot, kailangan mong itanong ang tamang tanong. Ang susunod kong tanong ay: ilang frontend server ang mayroon tayo? Ang sagot na "medyo nagulat ako" - mayroon kaming 17 frontend server!

— Nahihiya akong magtanong, ngunit ang 150 na hinati sa 17 ay nagbibigay ng mga 8? Sinasabi mo ba na ang bawat server ay nagbibigay-daan sa 8 mga kahilingan sa bawat segundo, at kung bukas ay mayroong 160 mga kahilingan sa bawat segundo, kailangan namin ng 2 higit pang mga server?

Siyempre, hindi namin kailangan ng mga karagdagang server. Ang solusyon ay nasa mismong code, at sa ibabaw:

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

Nagkaroon ng function getCurrentClass(), dahil gumagana ang lahat sa site sa konteksto ng isang klase - tama iyan. At para sa isang function na ito sa bawat pahina ay mayroong 200+ kahilingan.

Ang solusyon sa paraang ito ay napaka-simple, hindi mo na kailangang muling isulat ang anuman: huwag mo na lang hilingin muli ang parehong impormasyon.

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

Tuwang-tuwa ako dahil napagpasyahan ko na sa ikatlong araw pa lamang ay nahanap ko na ang pangunahing problema. Katulad ko noon, isa lang ito sa maraming problema.

Ngunit ang paglutas sa unang problemang ito ay bumaba nang mas mababa sa graph.

Kasabay nito, gumagawa kami ng iba pang mga pag-optimize. Mayroong maraming mga bagay sa paningin na maaaring ayusin. Halimbawa, sa parehong ikatlong araw natuklasan ko na mayroong isang cache sa system pagkatapos ng lahat (sa una ay naisip ko na ang lahat ng mga kahilingan ay direktang nagmumula sa database). Kapag iniisip ko ang isang cache, iniisip ko ang karaniwang Redis o Memcached. Ngunit ako lang ang nag-isip, dahil ginamit ng system na iyon ang MongoDB at SQL Server para sa pag-cache - ang parehong kung saan nabasa ang data.

ikasampung araw

Sa unang linggo hinarap ko ang mga problemang kailangang lutasin ngayon. Sa isang lugar sa ikalawang linggo, pumunta ako sa stand-up sa unang pagkakataon upang makipag-usap sa koponan, upang makita kung ano ang nangyayari at kung paano ang buong proseso ay nangyayari.

Isang bagay na interesante ang muling natuklasan. Ang koponan ay binubuo ng: 18 developer; 8 tester; 3 tagapamahala; 2 arkitekto. At lahat sila ay lumahok sa mga karaniwang ritwal, iyon ay, higit sa 30 katao ang pumupunta sa stand-up tuwing umaga at sinabi ang kanilang ginawa. Malinaw na hindi umabot ng 5 o 15 minuto ang pagpupulong. Walang nakinig sa sinuman dahil gumagana ang lahat sa iba't ibang sistema. Sa form na ito, 2-3 tiket kada oras para sa isang sesyon ng pag-aayos ay isa nang magandang resulta.

Ang unang bagay na ginawa namin ay hatiin ang koponan sa ilang linya ng produkto. Para sa iba't ibang seksyon at system, naglaan kami ng magkakahiwalay na team, na kinabibilangan ng mga developer, tester, product manager, at business analyst.

Bilang resulta, nakuha namin ang:

• Pagbawas ng mga stand-up at rally.
• Kaalaman sa paksa ng produkto.
• Isang pakiramdam ng pagmamay-ari. Kapag ang mga tao ay madalas na nakikipag-usap sa mga system sa lahat ng oras, alam nila na may ibang tao na malamang na kailangang gumawa ng kanilang mga bug, ngunit hindi ang kanilang sarili.
• Pakikipagtulungan sa pagitan ng mga grupo. Hindi na kailangang sabihin, ang QA ay hindi masyadong nakikipag-usap sa mga programmer dati, ang produkto ay gumawa ng sarili nitong bagay, atbp. Ngayon sila ay may isang karaniwang punto ng responsibilidad.

Pangunahing nakatuon kami sa kahusayan, produktibidad at kalidad - ito ang mga problemang sinubukan naming lutasin sa pagbabago ng koponan.

Labing-isang araw

Sa proseso ng pagbabago ng istraktura ng koponan, natuklasan ko kung paano magbilang KuwentoMga puntos. Ang 1 SP ay katumbas ng isang araw, at ang bawat tiket ay naglalaman ng SP para sa parehong pag-unlad at QA, iyon ay, hindi bababa sa 2 SP.

Paano ko ito natuklasan?

Nakakita kami ng bug: sa isa sa mga ulat, kung saan ipinasok ang petsa ng pagsisimula at pagtatapos ng panahon kung saan kailangan ang ulat, hindi isinasaalang-alang ang huling araw. Iyon ay, sa isang lugar sa kahilingan ay walang <=, ngunit simpleng <. Sinabihan ako na ito ay tatlong Story Point, kumbaga 3 araw.

Pagkatapos nito ay:

• Ang sistema ng rating ng Story Points ay binago. Ngayon, ang mga pag-aayos para sa mga menor de edad na bug na maaaring mabilis na maipasa sa system ay maabot ang user nang mas mabilis.
• Sinimulan naming pagsamahin ang mga kaugnay na tiket para sa pag-unlad at pagsubok. Dati, ang bawat tiket, bawat bug ay isang saradong ecosystem, hindi nakatali sa anumang bagay. Ang pagpapalit ng tatlong button sa isang page ay maaaring tatlong magkakaibang tiket na may tatlong magkakaibang proseso ng QA sa halip na isang awtomatikong pagsubok sa bawat pahina.
• Nagsimula kaming makipagtulungan sa mga developer sa isang diskarte sa pagtantya ng mga gastos sa paggawa. Tatlong araw upang baguhin ang isang pindutan ay hindi nakakatawa.

Ikadalawampu't araw

Sa isang lugar sa kalagitnaan ng unang buwan, medyo naging matatag ang sitwasyon, naisip ko kung ano ang karaniwang nangyayari, at nagsimula na akong tumingin sa hinaharap at mag-isip tungkol sa mga pangmatagalang solusyon.

Pangmatagalang hangarin:

• Pinamamahalaang platform. Daan-daang mga kahilingan sa bawat pahina ay hindi seryoso.
• Mga nahuhulaang uso. May mga pana-panahong mga peak ng trapiko na sa unang tingin ay hindi nauugnay sa iba pang mga sukatan - kailangan naming maunawaan kung bakit nangyari ito at matutong manghula.
• Pagpapalawak ng platform. Patuloy na lumalaki ang negosyo, dumarami ang mga user, at dumarami ang trapiko.

Noong nakaraan, madalas itong sinasabi: "Isulat muli natin ang lahat sa [wika/balangkas], mas gagana ang lahat!"

Sa karamihan ng mga kaso hindi ito gumagana, ito ay mabuti kung ang muling pagsulat ay gumagana sa lahat. Samakatuwid, kailangan naming gumawa ng roadmap - isang partikular na diskarte na naglalarawan ng hakbang-hakbang kung paano makakamit ang mga layunin sa negosyo (ano ang gagawin namin at bakit), na:

• sumasalamin sa misyon at layunin ng proyekto;
• inuuna ang mga pangunahing layunin;
• naglalaman ng isang iskedyul para sa pagkamit ng mga ito.

Bago ito, walang nakipag-usap sa koponan tungkol sa layunin ng anumang mga pagbabagong gagawin. Nangangailangan ito ng tamang sukatan ng tagumpay. Sa unang pagkakataon sa kasaysayan ng kumpanya, nagtakda kami ng mga KPI para sa teknikal na grupo, at ang mga tagapagpahiwatig na ito ay nakatali sa mga pang-organisasyon.

Ibig sabihin, ang mga KPI ng organisasyon ay sinusuportahan ng mga koponan, at ang mga KPI ng koponan ay sinusuportahan ng mga indibidwal na KPI. Kung hindi, kung ang mga teknolohikal na KPI ay hindi nag-tutugma sa mga pang-organisasyon, kung gayon ang lahat ay kumukuha ng kumot sa kanilang sarili.

Halimbawa, ang isa sa mga KPI ng organisasyon ay ang pagtaas ng bahagi ng merkado sa pamamagitan ng mga bagong produkto.

Paano mo masusuportahan ang layunin ng pagkakaroon ng mas maraming bagong produkto?

• Una, gusto naming gumugol ng mas maraming oras sa pagbuo ng mga bagong produkto sa halip na ayusin ang mga depekto. Ito ay isang lohikal na solusyon na madaling sukatin.
• Pangalawa, gusto naming suportahan ang pagtaas ng dami ng transaksyon, dahil mas malaki ang bahagi ng merkado, mas maraming user at, nang naaayon, mas maraming trapiko.

Pagkatapos, ang mga indibidwal na KPI na maaaring isagawa sa loob ng grupo ay, halimbawa, ay nasa lugar kung saan nagmumula ang mga pangunahing depekto. Kung partikular na tumutok ka sa seksyong ito, maaari mong tiyakin na may mas kaunting mga depekto, at pagkatapos ay tataas ang oras para sa pagbuo ng mga bagong produkto at muli para sa pagsuporta sa mga KPI ng organisasyon.

Kaya, ang bawat desisyon, kabilang ang muling pagsulat ng code, ay dapat na suportahan ang mga partikular na layunin na itinakda ng kumpanya para sa amin (paglago ng organisasyon, mga bagong feature, recruitment).

Sa panahon ng prosesong ito, isang kawili-wiling bagay ang dumating sa liwanag, na naging balita hindi lamang para sa mga techies, ngunit sa pangkalahatan sa kumpanya: ang lahat ng mga tiket ay dapat na nakatuon sa hindi bababa sa isang KPI. Ibig sabihin, kung sasabihin ng isang produkto na gusto nitong gumawa ng bagong feature, dapat itanong ang unang tanong: "Anong KPI ang sinusuportahan ng feature na ito?" Kung hindi, pagkatapos ay paumanhin - tila isang hindi kinakailangang tampok.

Ika-tatlumpu't araw

Sa pagtatapos ng buwan, natuklasan ko ang isa pang nuance: walang sinuman sa aking Ops team ang nakakita ng mga kontratang pinapasok namin sa mga kliyente. Maaari kang magtanong kung bakit kailangan mong makita ang mga contact.

• Una, dahil ang mga SLA ay tinukoy sa mga kontrata.
• Pangalawa, ang mga SLA ay magkakaiba. Ang bawat kliyente ay dumating na may sariling mga kinakailangan, at ang departamento ng pagbebenta ay pumirma nang hindi tumitingin.

Ang isa pang kawili-wiling nuance ay ang kontrata sa isa sa mga pinakamalaking kliyente ay nagsasaad na ang lahat ng mga bersyon ng software na sinusuportahan ng platform ay dapat na n-1, iyon ay, hindi ang pinakabagong bersyon, ngunit ang penultimate.

Malinaw kung gaano tayo kalayo mula sa n-1 kung ang platform ay batay sa ColdFusion at SQL Server 2008, na hindi na suportado noong Hulyo.

Ikaapatnapu't limang araw

Sa bandang kalagitnaan ng ikalawang buwan ay nagkaroon ako ng sapat na oras upang umupo at gawin halagadaloypaggawa ng mga mapa ganap para sa buong proseso. Ito ang mga kinakailangang hakbang na kailangang gawin, mula sa paglikha ng isang produkto hanggang sa paghahatid nito sa mamimili, at kailangan nilang ilarawan nang detalyado hangga't maaari.

Hinahati mo ang proseso sa maliliit na piraso at makita kung ano ang tumatagal ng masyadong maraming oras, kung ano ang maaaring i-optimize, mapabuti, atbp. Halimbawa, gaano katagal bago dumaan sa grooming ang isang kahilingan sa produkto, kailan ito umabot sa isang ticket na maaaring kunin ng developer, QA, atbp. Kaya tingnan mo ang bawat indibidwal na hakbang nang detalyado at isipin kung ano ang maaaring i-optimize.

Noong ginawa ko ito, dalawang bagay ang nakakuha ng pansin ko:

• mataas na porsyento ng mga tiket na ibinalik mula sa QA pabalik sa mga developer;
• Masyadong mahaba ang mga pagsusuri sa kahilingan ng pull.

Ang problema ay ang mga ito ay mga konklusyon tulad ng: Mukhang tumatagal ng maraming oras, ngunit hindi kami sigurado kung gaano katagal.

"Hindi mo mapapabuti ang hindi mo masusukat."

Paano bigyang-katwiran kung gaano kabigat ang problema? Nagsasayang ba ito ng mga araw o oras?

Para sukatin ito, nagdagdag kami ng ilang hakbang sa proseso ng Jira: “ready for dev” at “ready for QA” para sukatin kung gaano katagal maghihintay ang bawat ticket at kung ilang beses itong babalik sa isang partikular na hakbang.

Nagdagdag din kami ng “in review” para malaman kung gaano karaming mga ticket ang nasa average para sa pagsusuri, at mula dito maaari kang magsimulang sumayaw. Mayroon kaming mga sukatan ng system, ngayon ay nagdagdag kami ng mga bagong sukatan at nagsimulang sukatin:

• Kahusayan ng proseso: pagganap at binalak/naihatid.
• Kalidad ng proseso: bilang ng mga depekto, mga depekto mula sa QA.

Ito ay talagang nakakatulong upang maunawaan kung ano ang nangyayari nang maayos at kung ano ang hindi maganda.

Ikalimampu araw

Ito ay lahat, siyempre, mabuti at kawili-wili, ngunit sa pagtatapos ng ikalawang buwan ay may nangyari na, sa prinsipyo, ay mahuhulaan, kahit na hindi ko inaasahan ang gayong sukat. Nagsimulang umalis ang mga tao dahil nagbago ang nangungunang pamamahala. Ang mga bagong tao ay pumasok sa pamamahala at nagsimulang baguhin ang lahat, at ang mga luma ay huminto. At kadalasan sa isang kumpanya na ilang taon na, lahat ay magkaibigan at lahat ay magkakilala.

Ito ay inaasahan, ngunit ang laki ng mga tanggalan ay hindi inaasahan. Halimbawa, sa isang linggo dalawang pinuno ng koponan ang sabay-sabay na nagsumite ng kanilang mga pagbibitiw sa kanilang sariling malayang kalooban. Samakatuwid, kailangan kong hindi lamang kalimutan ang tungkol sa iba pang mga problema, ngunit tumuon sa paglikha ng isang pangkat. Ito ay isang mahaba at mahirap na problema na lutasin, ngunit kailangan itong harapin dahil gusto kong iligtas ang mga taong nanatili (o karamihan sa kanila). Kinakailangan na kahit papaano ay tumugon sa katotohanang umalis ang mga tao upang mapanatili ang moral sa koponan.

Sa teorya, ito ay mabuti: isang bagong tao ang dumating na may kumpletong carte blanche, na maaaring suriin ang mga kasanayan ng koponan at palitan ang mga tauhan. Sa katunayan, hindi ka maaaring magdala ng mga bagong tao sa napakaraming dahilan. Palaging kailangan ang balanse.

• Luma at bago. Kailangan nating panatilihin ang mga matatandang maaaring magbago at sumuporta sa misyon. Ngunit sa parehong oras, kailangan nating magdala ng bagong dugo, pag-uusapan natin iyan sa ibang pagkakataon.
• Karanasan. Marami akong nakipag-usap sa magagaling na juniors na sabik at gustong makatrabaho kami. Ngunit hindi ko sila makuha dahil walang sapat na mga nakatatanda upang suportahan ang mga junior at kumilos bilang mga tagapayo para sa kanila. Kinailangan na unang kumalap sa tuktok at pagkatapos lamang ng kabataan.
• Karot at stick.

Wala akong magandang sagot sa tanong kung ano ang tamang balanse, kung paano ito mapanatili, kung gaano karaming tao ang dapat panatilihin at kung magkano ang dapat itulak. Ito ay isang purong indibidwal na proseso.

Araw ng ikalimampu't isa

Sinimulan kong tingnang mabuti ang koponan upang maunawaan kung sino ang mayroon ako, at muli kong naalala:

"Karamihan sa mga problema ay problema ng mga tao."

Nalaman ko na ang pangkat tulad nito - parehong Dev at Ops - ay may tatlong malalaking problema:

• Kasiyahan sa kasalukuyang estado ng mga gawain.
• Kawalan ng responsibilidad - dahil walang sinuman ang nagdala ng mga resulta ng trabaho ng mga gumaganap upang maimpluwensyahan ang negosyo.
• Takot sa pagbabago.

Palagi kang inaalis ng pagbabago sa iyong comfort zone, at ang mga nakababata, mas hindi nila gusto ang pagbabago dahil hindi nila naiintindihan kung bakit at hindi nila naiintindihan kung paano. Ang pinakakaraniwang sagot na narinig ko ay, "Hindi pa namin nagawa iyon." Bukod dito, umabot ito sa punto ng ganap na kahangalan - ang pinakamaliit na pagbabago ay hindi maaaring mangyari nang walang nagagalit. At gaano man kalaki ang epekto ng mga pagbabago sa kanilang trabaho, sinabi ng mga tao: “Hindi, bakit? Hindi ito gagana."

Ngunit hindi ka makakabuti nang walang pagbabago.

Mayroon akong ganap na walang katotohanan na pag-uusap sa isang empleyado, sinabi ko sa kanya ang aking mga ideya para sa pag-optimize, kung saan sinabi niya sa akin:
- Oh, hindi mo nakita kung ano ang mayroon kami noong nakaraang taon!
- E ano ngayon?
"Ngayon ito ay mas mahusay kaysa noon."
- Kaya, hindi ito maaaring maging mas mahusay?
- Para saan?

Magandang tanong - bakit? Parang mas maganda na ngayon kaysa noon, tapos lahat ay sapat na. Ito ay humahantong sa isang kakulangan ng responsibilidad, na kung saan ay ganap na normal sa prinsipyo. Gaya ng sabi ko, medyo nasa sideline ang technical group. Naniniwala ang kumpanya na dapat silang umiral, ngunit walang nagtakda ng mga pamantayan. Hindi nakita ng teknikal na suporta ang SLA, kaya medyo "katanggap-tanggap" para sa grupo (at ito ang pinakanagulat sa akin):

• 12 segundo na naglo-load;
• 5-10 minutong downtime bawat release;
• Ang pag-troubleshoot ng mga kritikal na problema ay tumatagal ng mga araw at linggo;
• kakulangan ng mga tauhan sa tungkulin 24x7 / on-call.

Walang sinuman ang sumubok na magtanong kung bakit hindi natin gawin ito nang mas mahusay, at walang sinuman ang nakakaalam na hindi ito kailangang maging ganito.

Bilang bonus, may isa pang problema: kakulangan ng karanasan. Umalis ang mga nakatatanda, at ang natitirang batang koponan ay lumaki sa ilalim ng nakaraang rehimen at nalason nito.

Higit sa lahat ng ito, ang mga tao ay natatakot din na mabigo at magmukhang walang kakayahan. Ito ay ipinahayag sa katotohanan na, una, sila sa ilalim ng anumang pagkakataon ay humingi ng tulong. Ilang beses na kaming nag-usap bilang isang grupo at indibidwal, at sinabi ko, "Magtanong kung hindi mo alam kung paano gawin ang isang bagay." May tiwala ako sa sarili ko at alam kong kaya kong lutasin ang anumang problema, ngunit magtatagal ito. Samakatuwid, kung maaari akong magtanong sa isang taong nakakaalam kung paano lutasin ito sa loob ng 10 minuto, magtatanong ako. Kung gaano ka kaunting karanasan, mas natatakot kang magtanong dahil sa tingin mo ay maituturing kang walang kakayahan.

Ang takot na ito sa pagtatanong ay nagpapakita ng sarili sa mga kawili-wiling paraan. Halimbawa, itatanong mo: "Kumusta ka sa gawaing ito?" - "Ilang oras na lang, tapos na ako." Kinabukasan nagtanong ka ulit, nakuha mo ang sagot na maayos ang lahat, ngunit may isang problema, tiyak na magiging handa ito sa pagtatapos ng araw. Lumipas ang isa pang araw, at hanggang sa maipit ka sa pader at sapilitang makipag-usap sa isang tao, nagpapatuloy ito. Nais ng isang tao na lutasin ang isang problema sa kanyang sarili; naniniwala siya na kung hindi niya ito lutasin sa kanyang sarili, ito ay isang malaking kabiguan.

Iyon ang dahilan kung bakit pinalaki ng mga developer ang mga pagtatantya. Ito ay ang parehong anekdota, kapag sila ay tinatalakay ang isang tiyak na gawain, sila ay nagbigay sa akin ng isang figure na ako ay labis na nagulat. Kung saan sinabi sa akin na sa mga pagtatantya ng developer, kasama ng developer ang oras na ibabalik ang ticket mula sa QA, dahil makakahanap sila ng mga error doon, at ang oras na aabutin ng PR, at ang oras habang ang mga taong dapat mag-review magiging abala ito - iyon ay, lahat, anuman ang posible.

Pangalawa, ang mga taong natatakot na magmukhang walang kakayahan overanalyze. Kapag sinabi mo kung ano ang eksaktong kailangang gawin, magsisimula ito: "Hindi, paano kung pag-isipan natin dito?" Sa ganitong kahulugan, ang aming kumpanya ay hindi natatangi; ito ay isang karaniwang problema para sa mga kabataan.

Bilang tugon, ipinakilala ko ang mga sumusunod na kasanayan:

• Panuntunan 30 minuto. Kung hindi mo malutas ang problema sa loob ng kalahating oras, humingi ng tulong sa isang tao. Gumagana ito sa iba't ibang antas ng tagumpay, dahil hindi pa rin nagtatanong ang mga tao, ngunit hindi bababa sa nagsimula na ang proseso.
• Tanggalin ang lahat maliban sa kakanyahan, sa pagtatantya ng deadline para sa pagkumpleto ng isang gawain, ibig sabihin, isaalang-alang lamang kung gaano katagal bago isulat ang code.
• Patuloy na pag-aaral para sa mga nag-overanalyze. Ito ay palagiang trabaho sa mga tao.

Ika-animnapung araw

Habang ginagawa ko ang lahat ng ito, oras na para alamin ang badyet. Siyempre, marami akong nakitang kawili-wiling mga bagay kung saan namin ginastos ang aming pera. Halimbawa, mayroon kaming isang buong rack sa isang hiwalay na data center na may isang FTP server, na ginamit ng isang kliyente. Lumalabas na "... lumipat kami, ngunit nanatili siyang ganoon, hindi namin siya binago." 2 taon na ang nakalipas.

Ang partikular na interes ay ang bayarin para sa mga serbisyo sa cloud. Naniniwala ako na ang pangunahing dahilan ng mataas na cloud bill ay ang mga developer na may walang limitasyong access sa mga server sa unang pagkakataon sa kanilang buhay. Hindi nila kailangang magtanong: "Pakibigay sa akin ng isang test server," maaari nilang kunin ito mismo. Dagdag pa, ang mga developer ay palaging nais na bumuo ng isang cool na sistema na ang Facebook at Netflix ay magseselos.

Ngunit ang mga developer ay walang karanasan sa pagbili ng mga server at ang kasanayan sa pagtukoy ng kinakailangang laki ng mga server, dahil hindi nila ito kailangan noon. At kadalasan ay hindi nila masyadong naiintindihan ang pagkakaiba sa pagitan ng scalability at performance.

Mga resulta ng imbentaryo:

• Umalis kami sa parehong data center.
• Tinapos namin ang kontrata sa 3 serbisyo ng log. Dahil mayroon kaming 5 sa kanila - bawat developer na nagsimulang maglaro ng isang bagay ay kumuha ng bago.
• 7 AWS system ang isinara. Muli, walang huminto sa mga patay na proyekto; lahat sila ay nagpatuloy sa paggawa.
• Binawasan ang mga gastos sa software ng 6 na beses.

Araw ng pitumpu't lima

Lumipas ang panahon, at sa loob ng dalawa at kalahating buwan ay kinailangan kong makipagpulong sa lupon ng mga direktor. Ang aming lupon ng mga direktor ay hindi mas mahusay o mas masahol kaysa sa iba; tulad ng lahat ng mga lupon ng mga direktor, nais nitong malaman ang lahat. Namumuhunan ang mga tao ng pera at gustong maunawaan kung magkano ang aming ginagawa sa mga nakatakdang KPI.

Ang lupon ng mga direktor ay tumatanggap ng maraming impormasyon bawat buwan: ang bilang ng mga gumagamit, ang kanilang paglaki, kung anong mga serbisyo ang kanilang ginagamit at kung paano, pagganap at pagiging produktibo, at panghuli, ang average na bilis ng paglo-load ng pahina.

Ang problema lang ay naniniwala ako na ang karaniwan ay puro kasamaan. Ngunit napakahirap ipaliwanag ito sa board of directors. Nakasanayan na nila ang pagpapatakbo gamit ang mga pinagsama-samang numero, at hindi, halimbawa, ang pagkalat ng mga oras ng paglo-load bawat segundo.

Mayroong ilang mga kawili-wiling punto sa bagay na ito. Halimbawa, sinabi ko na kailangan nating hatiin ang trapiko sa pagitan ng magkakahiwalay na mga web server depende sa uri ng nilalaman.

Ibig sabihin, dumaan ang ColdFusion sa Jetty at nginx at inilulunsad ang mga pahina. At ang mga imahe, JS at CSS ay dumaan sa isang hiwalay na nginx na may sariling mga pagsasaayos. Ito ay isang medyo karaniwang kasanayan na pinag-uusapan ko ako wrote ilang taon na ang nakalipas. Bilang resulta, ang mga larawan ay naglo-load nang mas mabilis, at... ang average na bilis ng pag-download ay tumaas ng 200 ms.

Nangyari ito dahil binuo ang graph batay sa data na kasama ng Jetty. Iyon ay, ang mabilis na nilalaman ay hindi kasama sa pagkalkula - ang average na halaga ay tumalon. Ito ay malinaw sa amin, kami ay natawa, ngunit paano namin ipapaliwanag sa board of directors kung bakit kami gumawa ng isang bagay at ang mga bagay ay lumala ng 12%?

Araw ng ikawalumpu't lima

Sa pagtatapos ng ikatlong buwan, napagtanto ko na may isang bagay na hindi ko naisip: oras. Lahat ng napag-usapan ko ay nangangailangan ng oras.

Ito ang aking tunay na lingguhang kalendaryo - isang linggo ng trabaho, hindi masyadong abala. Walang sapat na oras para sa lahat. Samakatuwid, muli, kailangan mong kumalap ng mga tao na tutulong sa iyo na makayanan ang mga problema.

Konklusyon

Hindi lamang yan. Sa kuwentong ito, hindi ko pa naiintindihan kung paano namin ginawa ang produkto at sinubukang tumuon sa pangkalahatang wave, o kung paano namin isinama ang teknikal na suporta, o kung paano namin nalutas ang iba pang mga teknikal na problema. Halimbawa, natutunan ko nang hindi sinasadya na sa pinakamalaking mga talahanayan sa database ay hindi namin ginagamit SEQUENCE. Mayroon kaming self-written function nextID, at hindi ito ginagamit sa isang transaksyon.

Mayroong isang milyong higit pang mga katulad na bagay na maaari naming pag-usapan sa mahabang panahon. Ngunit ang pinakamahalagang bagay na kailangan pang sabihin ay ang kultura.

Ang kultura o ang kakulangan nito ang humahantong sa lahat ng iba pang problema. Sinusubukan naming bumuo ng isang kultura kung saan ang mga tao ay:

• ay hindi natatakot sa mga pagkabigo;
• Matuto sa mga pagkakamali;
• makipagtulungan sa iba pang mga koponan;
• kumuha ng inisyatiba;
• kumuha ng responsibilidad;
• tanggapin ang resulta bilang isang layunin;
• nagdiriwang ng tagumpay.

Kasama nito ang lahat ng iba pa ay darating.

Leon Fire sa Twitter, facebook at medium.

Mayroong dalawang mga diskarte tungkol sa legacy: iwasang magtrabaho kasama ito sa lahat ng mga gastos, o matapang na pagtagumpayan ang kaugnay na mga paghihirap. Kami c DevOpsConf Tayo ay tumatahak sa pangalawang landas, nagbabago ng mga proseso at diskarte. Sumali sa amin sa youtube, newsletter и telegrama, at sama-sama nating ipapatupad ang isang kultura ng DevOps.

Pinagmulan: www.habr.com