Ang mga developer ay mula sa Mars, ang mga admin ay mula sa Venus

Ang mga pagkakataon ay random, at sa katunayan ito ay nasa ibang planeta...

Gusto kong magbahagi ng tatlong kwento ng tagumpay at kabiguan tungkol sa kung paano gumagana ang isang backend developer sa isang team na may mga admin.

Kuwento isa.
Web studio, ang bilang ng mga empleyado ay mabibilang sa isang kamay. Ngayon layout designer ka, bukas backender ka, kinabukasan admin ka na. Sa isang banda, maaari kang makakuha ng napakalaking karanasan. Sa kabilang banda, may kakulangan ng kakayahan sa lahat ng lugar. Naaalala ko pa ang unang araw ng trabaho, berde pa rin ako, sabi ng boss: "Buksan ang masilya," ngunit hindi ko alam kung ano ito. Ang pakikipag-ugnayan sa mga admin ay hindi kasama, dahil ikaw mismo ay admin. Isaalang-alang natin ang mga kalamangan at kahinaan ng sitwasyong ito.

+ Nasa iyong mga kamay ang lahat ng kapangyarihan.
+ Hindi na kailangang magmakaawa sa sinuman para sa pag-access sa server.
+ Mabilis na oras ng reaksyon sa lahat ng direksyon.
+ Nagpapabuti ng mga kasanayan nang maayos.
+ Magkaroon ng kumpletong pag-unawa sa arkitektura ng produkto.

— Mataas na responsibilidad.
— Panganib na masira ang produksyon.
— Mahirap maging isang mahusay na espesyalista sa lahat ng lugar.

Hindi interesado, magpatuloy tayo

Ang pangalawang kwento.
Malaking kumpanya, malaking proyekto. Mayroong isang departamento ng administrasyon na may 5-7 empleyado at ilang grupo ng pag-unlad. Kapag nagtratrabaho ka sa naturang kumpanya, iniisip ng bawat admin na hindi ka pumunta rito para magtrabaho sa isang produkto, ngunit para sirain ang isang bagay. Ni ang pinirmahang NDA o ang pagpili sa panayam ay hindi nagpapahiwatig ng iba. Hindi, pumunta dito ang lalaking ito gamit ang kanyang maruruming maliliit na kamay para sirain ang produksiyon ng paghalikan namin. Samakatuwid, sa gayong tao kailangan mo ng isang minimum na komunikasyon; sa pinakamaliit, maaari kang magtapon ng sticker bilang tugon. Huwag sagutin ang mga tanong tungkol sa arkitektura ng proyekto. Maipapayo na huwag magbigay ng access hangga't hindi nagtatanong ang pinuno ng koponan. At kapag humingi siya, ibabalik niya ito nang may mas kaunting mga pribilehiyo kaysa sa hiniling nila. Halos lahat ng komunikasyon sa naturang mga admin ay hinihigop ng black hole sa pagitan ng development department at ng administration department. Imposibleng malutas kaagad ang mga isyu. Ngunit hindi ka maaaring pumunta nang personal - ang mga admin ay masyadong abala 24/7. (Ano ang iyong ginagawa sa lahat ng oras?) Ilang katangian ng pagganap:

• Ang average na oras ng pag-deploy sa produksyon ay 4-5 na oras
• Pinakamataas na oras ng pag-deploy sa produksyon na 9 na oras
• Para sa isang developer, ang isang application sa produksyon ay isang black box, tulad ng mismong production server. ilan sila sa kabuuan?
• Mababang kalidad ng mga release, madalas na mga error
• Hindi nakikilahok ang developer sa proseso ng paglabas

Well, what did I expect, siyempre, bawal sa production ang mga bagong tao. Well, okay, pagkakaroon ng pasensya, nagsisimula kaming makakuha ng tiwala ng iba. Ngunit sa ilang kadahilanan, ang mga bagay ay hindi gaanong simple sa mga admin.

Act 1. Ang admin ay invisible.
Araw ng paglabas, hindi nag-uusap ang developer at admin. Walang tanong ang admin. Pero maiintindihan mo kung bakit mamaya. Ang admin ay isang may prinsipyong tao, walang messenger, hindi nagbibigay ng kanyang numero ng telepono sa sinuman, at walang profile sa mga social network. Wala kahit isang litrato niya kahit saan, ano ang hitsura mo dude? Umupo kami kasama ang responsableng tagapamahala nang humigit-kumulang 15 minuto sa pagkalito, sinusubukang itatag ang komunikasyon sa Voyager 1 na ito, pagkatapos ay may lalabas na mensahe sa corporate email na natapos na niya. Magsusulat ba tayo sa pamamagitan ng koreo? Bakit hindi? Maginhawa, hindi ba? Well, okay, cool down tayo. Ang proseso ay isinasagawa na, walang babalikan. Basahin muli ang mensahe. "Tapos na ako". Ano ang natapos mo? saan? Saan kita hahanapin? Dito mo naiintindihan kung bakit normal ang 4 na oras para sa pagpapalabas. Nakakakuha kami ng isang pagkabigla sa pag-unlad, ngunit natapos namin ang paglabas. Wala nang pagnanais na palayain.

Act 2. Hindi ang bersyon na iyon.
Ang susunod na paglabas. Ang pagkakaroon ng karanasan, nagsisimula kaming lumikha ng mga listahan ng kinakailangang software at mga aklatan para sa server para sa mga administrator, na nagpapahiwatig ng mga bersyon para sa ilan. Gaya ng dati, nakakatanggap kami ng mahinang signal ng radyo na may natapos ang admin doon. Magsisimula ang regression test, na tumatagal ng halos isang oras. Mukhang gumagana ang lahat, ngunit mayroong isang kritikal na bug. Hindi gumagana ang mahalagang functionality. Ang sumunod na ilang oras ay pagsasayaw na may mga tamburin, pagkukuwento sa mga bakuran ng kape, at isang detalyadong pagsusuri ng bawat piraso ng code. Sinabi ng admin na ginawa niya ang lahat. Ang application na isinulat ng mga baluktot na developer ay hindi gumagana, ngunit gumagana ang server. Anumang mga katanungan para sa kanya? Sa pagtatapos ng isang oras, hinihiling namin sa admin na ipadala ang bersyon ng library sa production server sa chat at bingo - hindi ito ang kailangan namin. Hinihiling namin sa administrator na i-install ang kinakailangang bersyon, ngunit bilang tugon natanggap namin na hindi niya ito magagawa dahil sa kawalan ng bersyong ito sa OS package manager. Dito, mula sa mga recess ng kanyang memorya, naaalala ng manager na nalutas na ng isa pang admin ang problemang ito sa pamamagitan lamang ng pag-assemble ng kinakailangang bersyon sa pamamagitan ng kamay. Ngunit hindi, hindi ito gagawin ng atin. Ipinagbabawal ng mga regulasyon. Karl, ilang oras na tayong nakaupo dito, anong time limit?! Nakakuha kami ng isa pang pagkabigla at kahit papaano ay natapos ang paglabas.

Act 3, maikli
Ang apurahang tiket, ang pangunahing pag-andar ay hindi gumagana para sa isa sa mga gumagamit sa produksyon. Gumugugol kami ng ilang oras sa pagsundot at pagsuri. Sa isang kapaligiran sa pag-unlad, gumagana ang lahat. May malinaw na pag-unawa na magandang ideya na tingnan ang mga log ng php-fpm. Walang mga log system tulad ng ELK o Prometheus sa proyekto noong panahong iyon. Binuksan namin ang isang tiket sa departamento ng administrasyon upang bigyan sila ng access sa mga log ng php-fpm sa server. Dito kailangan mong maunawaan na humihingi kami ng access para sa isang kadahilanan, hindi mo ba naaalala ang tungkol sa black hole at ang mga admin ay abala 24/7? Kung hihilingin mo sa kanila na tingnan ang mga log mismo, kung gayon ito ay isang gawain na may priyoridad na "wala sa buhay na ito". Nalikha ang tiket, nakatanggap kami ng agarang tugon mula sa pinuno ng departamento ng administrasyon: "Hindi mo dapat kailanganin ang pag-access sa mga log ng produksyon, sumulat nang walang mga bug." Isang kurtina.

Act 4 at higit pa
Nangongolekta pa rin kami ng dose-dosenang mga problema sa produksyon, dahil sa iba't ibang bersyon ng mga aklatan, hindi na-configure na software, hindi nakahandang pag-load ng server, at iba pang mga problema. Syempre, may mga code bug din, hindi namin sisisihin ang mga admin sa lahat ng kasalanan, babanggitin lang namin ang isa pang tipikal na operasyon para sa proyektong iyon. Marami kaming background na manggagawa na inilunsad sa pamamagitan ng superbisor, at ilang script ang kailangang idagdag sa cron. Minsan ang mga manggagawang ito ay tumigil sa pagtatrabaho. Ang load sa queue server ay lumaki sa bilis ng kidlat, at ang malungkot na mga gumagamit ay tumingin sa umiikot na loader. Upang mabilis na ayusin ang mga naturang manggagawa, sapat na upang i-restart lamang ang mga ito, ngunit muli, isang administrator lamang ang makakagawa nito. Habang ginagawa ang naturang pangunahing operasyon, maaaring lumipas ang isang buong araw. Dito, siyempre, nararapat na tandaan na ang mga baluktot na programmer ay dapat sumulat ng mga manggagawa upang hindi sila mag-crash, ngunit kapag sila ay bumagsak, ito ay magiging maganda upang maunawaan kung bakit, na kung minsan ay imposible dahil sa kakulangan ng access sa produksyon, ng kurso, at bilang kinahinatnan, ang kakulangan ng mga log mula sa developer.

Pagbabagong-anyo.
Sa pagtitiis ng lahat ng ito sa loob ng mahabang panahon, kasama ang koponan nagsimula kaming magmaneho sa direksyon na mas matagumpay para sa amin. Upang buod, anong mga problema ang ating kinaharap?

• Kakulangan ng kalidad ng komunikasyon sa pagitan ng mga developer at departamento ng administrasyon
• Ang mga tagapangasiwa, lumalabas(!), Hindi nila nauunawaan kung paano nakaayos ang application, anong mga dependency ang mayroon ito at kung paano ito gumagana.
• Hindi nauunawaan ng mga developer kung paano gumagana ang kapaligiran ng produksyon at, bilang resulta, ay hindi epektibong tumugon sa mga problema.
• Masyadong mahaba ang proseso ng pag-deploy.
• Mga hindi matatag na release.

Ano'ng nagawa natin?
Para sa bawat paglabas, nabuo ang isang listahan ng Mga Tala sa Paglabas, na may kasamang listahan ng mga gawaing kailangang gawin sa server para gumana ang susunod na paglabas. Ang listahan ay naglalaman ng ilang mga seksyon, trabaho na dapat isagawa ng administrator, ang taong responsable para sa pagpapalabas, at ang developer. Nakatanggap ang mga developer ng non-root na access sa lahat ng production server, na nagpabilis sa pag-unlad sa pangkalahatan at paglutas ng problema sa partikular. Ang mga developer ay mayroon ding pag-unawa sa kung paano gumagana ang produksyon, kung anong mga serbisyo ito nahahati, kung saan at kung magkano ang halaga ng mga replika. Ang ilan sa mga pag-load ng labanan ay naging mas malinaw, na walang alinlangan na nakakaapekto sa kalidad ng code. Ang komunikasyon sa panahon ng proseso ng paglabas ay naganap sa chat ng isa sa mga instant messenger. Una, mayroon kaming talaan ng lahat ng mga aksyon, at pangalawa, naganap ang komunikasyon sa isang mas malapit na kapaligiran. Ang pagkakaroon ng kasaysayan ng mga aksyon ay higit sa isang beses na nagpapahintulot sa mga bagong empleyado na mas mabilis na malutas ang mga problema. Ito ay isang kabalintunaan, ngunit madalas itong nakatulong sa mga admin mismo. Hindi ako mangangailangan na sabihin nang sigurado, ngunit tila sa akin ay nagsimula nang mas maunawaan ng mga admin kung paano gumagana ang proyekto at kung paano ito nakasulat. Minsan ay nagbahagi pa kami ng ilang detalye sa isa't isa. Ang average na oras ng pagpapalabas ay nabawasan sa isang oras. Minsan kami ay tapos na sa loob ng 30-40 minuto. Ang bilang ng mga bug ay makabuluhang nabawasan, kung hindi man sampung beses. Siyempre, naiimpluwensyahan din ng iba pang mga salik ang pagbawas sa oras ng paglabas, gaya ng mga autotest. Pagkatapos ng bawat paglabas, nagsimula kaming magsagawa ng mga retrospective. Upang ang buong koponan ay magkaroon ng ideya kung ano ang bago, kung ano ang nabago, at kung ano ang naalis. Sa kasamaang palad, hindi palaging pinupuntahan ng mga admin, aba, abala ang mga admin... Walang alinlangan na tumaas ang aking kasiyahan sa trabaho bilang isang developer. Kapag mabilis mong malutas ang halos anumang problema na nasa iyong lugar ng kakayahan, pakiramdam mo ay nasa itaas. Sa ibang pagkakataon, mauunawaan ko na sa ilang lawak ay ipinakilala namin ang isang kultura ng devops, hindi ganap, siyempre, ngunit kahit na ang simula ng pagbabagong iyon ay kahanga-hanga.

Ikatlong kwento
Magsimula. Isang admin, maliit na departamento ng pag-unlad. Sa pagdating ako ay ganap na zero, dahil... Wala akong access kahit saan maliban sa mail. Sumulat kami sa admin at humihingi ng access. Bilang karagdagan, mayroong impormasyon na alam niya ang bagong empleyado at ang pangangailangang mag-isyu ng mga login/password. Nagbibigay sila ng access mula sa repositoryo at VPN. Bakit nagbibigay ng access sa wiki, teamcity, rundesk? Mga walang kwentang bagay para sa isang taong tinawag para isulat ang buong bahagi ng backend. Sa paglipas lamang ng panahon ay nagkakaroon tayo ng access sa ilang mga tool. Ang pagdating, siyempre, ay sinalubong ng kawalan ng tiwala. Sinusubukan kong dahan-dahang madama kung paano gumagana ang imprastraktura ng proyekto sa pamamagitan ng mga chat at nangungunang tanong. Talaga wala akong nakikilala. Ang produksyon ay ang parehong itim na kahon tulad ng dati. Ngunit higit pa riyan, kahit na ang mga stage server na ginagamit para sa pagsubok ay isang itim na kahon. Wala kaming magagawa kung hindi mag-deploy ng branch mula sa Git doon. Hindi rin namin mai-configure ang aming application tulad ng mga .env file. Ang pag-access para sa mga naturang operasyon ay hindi ibinibigay. Kailangan mong magmakaawa upang mapalitan ang isang linya sa config ng iyong aplikasyon sa test server. (May teorya na mahalaga para sa mga admin na maramdaman ang kanilang sarili na mahalaga sa proyekto; kung hindi sila hihilingin na baguhin ang mga linya sa mga config, hindi na sila kakailanganin). Well, gaya ng dati, hindi ba ito maginhawa? Mabilis itong nagiging boring, pagkatapos ng isang direktang pakikipag-usap sa admin nalaman namin na ang mga developer ay ipinanganak upang magsulat ng masamang code, ay likas na walang kakayahan na mga indibidwal at mas mahusay na ilayo sila sa produksyon. Ngunit narito rin mula sa mga server ng pagsubok, kung sakali. Mabilis na lumalala ang salungatan. Walang komunikasyon sa admin. Ang sitwasyon ay pinalala ng katotohanan na siya ay nag-iisa. Ang sumusunod ay isang tipikal na larawan. Palayain. Hindi gumagana ang ilang function. Ito ay tumatagal sa amin ng mahabang panahon upang malaman kung ano ang nangyayari, iba't ibang mga ideya mula sa mga developer ang itinapon sa chat, ngunit ang admin sa ganoong sitwasyon ay karaniwang ipinapalagay na ang mga developer ang may kasalanan. Tapos nagsusulat siya sa chat, teka, tinama ko siya. Kapag hiniling na mag-iwan ng isang kuwento sa likod ng impormasyon tungkol sa kung ano ang problema, nakakatanggap kami ng mga nakakalason na dahilan. Tulad ng, huwag idikit ang iyong ilong sa hindi nararapat. Dapat magsulat ng code ang mga developer. Ang sitwasyon kung saan maraming galaw ng katawan sa isang proyekto ang dumaan sa isang solong tao at siya lamang ang may access upang maisagawa ang mga operasyong kailangan ng lahat ay lubhang nakakalungkot. Ang gayong tao ay isang kakila-kilabot na bottleneck. Kung ang mga ideya ng Devops ay nagsusumikap na bawasan ang oras-sa-market, kung gayon ang mga taong iyon ang pinakamasamang kaaway ng mga ideya ng Devops. Sa kasamaang palad, ang kurtina ay nagsasara dito.

PS Pagkatapos makipag-usap ng kaunti tungkol sa mga developer kumpara sa mga admin sa mga chat sa mga tao, nakilala ko ang mga taong nagbahagi ng aking sakit. Pero may mga nagsabi rin na wala pa silang na-encounter na ganito. Sa isang kumperensya ng devops, tinanong ko si Anton Isanin (Alfa Bank) kung paano nila hinarap ang problema ng bottleneck sa anyo ng mga admin, kung saan sinabi niya: "Pinalitan namin sila ng mga pindutan." Siya nga pala podcast kasama ang kanyang pakikilahok. Gusto kong maniwala na marami pang magaling na admin kaysa sa mga kalaban. At oo, ang larawan sa simula ay isang tunay na sulat.

Pinagmulan: www.habr.com