Ano ang kinakailangan para sa isang kumpanya ng IT upang maging matagumpay sa 2019? Ang mga lecturer sa mga conference at meetup ay nagsasabi ng maraming malalakas na salita na hindi laging naiintindihan ng mga normal na tao. Ang pakikibaka para sa oras ng pag-deploy, mga microservice, pag-abandona sa monolith, pagbabago ng DevOps at marami pa. Kung itatapon natin ang kagandahang pandiwa at magsalita nang direkta at sa Russian, kung gayon ang lahat ay bumaba sa isang simpleng thesis: gumawa ng isang de-kalidad na produkto, at gawin ito nang may ginhawa para sa koponan.
Ang huli ay naging kritikal na mahalaga. Ang negosyo ay sa wakas ay dumating sa konklusyon na ang isang komportableng proseso ng pag-unlad ay nagpapataas ng produktibidad, at kung ang lahat ay na-debug at gumagana tulad ng isang orasan, nagbibigay din ito ng ilang puwang para sa pagmamaniobra sa mga kritikal na sitwasyon. Noong unang panahon, para sa kapakanan ng maniobra na ito, isang matalinong tao ang gumawa ng mga backup, ngunit umuunlad ang industriya, at napunta kami sa mga inhinyero ng DevOps - mga taong ginagawang sapat ang proseso ng pakikipag-ugnayan sa pagitan ng pag-unlad at panlabas na imprastraktura. hindi nauugnay sa shamanismo.
Ang buong "modular" na kwentong ito ay kahanga-hanga, ngunit... Nagkataon na ang ilan sa mga admin ay biglang tinawag na DevOps, at ang mga inhinyero ng DevOps mismo ay nagsimulang kailanganin na magkaroon ng hindi bababa sa mga kasanayan sa telepathy at clairvoyance.
Bago natin pag-usapan ang mga modernong problema sa pagbibigay ng imprastraktura, tukuyin natin kung ano ang ibig sabihin ng terminong ito. Sa kasalukuyang sandali, ang sitwasyon ay umunlad sa paraang naabot natin ang duality ng konseptong ito: ang imprastraktura ay maaaring may kondisyong panlabas at may kondisyong panloob.
Sa pamamagitan ng panlabas na imprastraktura ang ibig naming sabihin ay lahat ng bagay na nagsisiguro sa paggana ng serbisyo o produkto na binubuo ng koponan. Ang mga ito ay mga server ng application o website, pagho-host at iba pang mga serbisyo na nagsisiguro sa paggana ng produkto.
Kasama sa panloob na imprastraktura ang mga serbisyo at kagamitan na ginagamit mismo ng development team at iba pang mga empleyado, na kadalasang marami. Ito ay mga panloob na server ng mga sistema ng pag-iimbak ng code, isang lokal na naka-deploy na task manager at lahat, lahat, lahat na umiiral sa loob ng corporate intranet.
Ano ang ginagawa ng isang system administrator sa isang kumpanya? Bilang karagdagan sa gawain ng pangangasiwa sa mismong corporate intranet na ito, kadalasang pinapasan nito ang mga alalahanin sa ekonomiya upang matiyak ang kakayahang magamit ng mga kagamitan sa opisina. Ang admin ay ang parehong tao na mabilis na magda-drag ng isang bagong unit ng system o isang ekstrang laptop na handa nang gamitin mula sa likod na silid, magbibigay ng isang sariwang keyboard at gumapang nang nakadapa sa mga opisina, na iniunat ang Ethernet cable. Ang isang administrator ay isang lokal na may-ari at pinuno ng hindi lamang panloob at panlabas na mga server, kundi pati na rin ng isang executive ng negosyo. Oo, ang ilang mga administrator ay maaari lamang gumana sa system plane, nang walang hardware. Dapat silang ihiwalay sa isang hiwalay na subclass ng "mga administrator ng sistema ng imprastraktura." At ang ilan ay nagdadalubhasa sa pagseserbisyo ng eksklusibong kagamitan sa opisina; sa kabutihang palad, kung ang kumpanya ay may higit sa isang daang tao, ang trabaho ay hindi natatapos. Ngunit wala sa kanila ang mga devops.
Sino ang DevOps? Ang mga devop ay mga taong nagsasalita tungkol sa pakikipag-ugnayan ng software development sa panlabas na imprastraktura. Mas tiyak, ang mga modernong devop ay kasangkot sa mga proseso ng pag-develop at pag-deploy na mas malalim kaysa sa mga admin na nag-upload lang ng mga update sa ftp ay kasangkot. Isa sa mga pangunahing gawain ng isang DevOps engineer ngayon ay upang matiyak ang isang komportable at epektibong nakabalangkas na proseso ng pakikipag-ugnayan sa pagitan ng mga development team at imprastraktura ng produkto. Ang mga taong ito ang may pananagutan sa pag-deploy ng mga rollback at deployment system; ang mga taong ito ang kumukuha ng ilan sa pag-load sa mga developer at tumutok hangga't maaari sa kanilang napakahalagang gawain. Kasabay nito, hindi kailanman tatakbo ang devops ng bagong cable o maglalabas ng bagong laptop mula sa likod na silid (c) KO
Ano ang catch?
Sa tanong na "Sino ang DevOps?" kalahati ng mga manggagawa sa bukid ay nagsimulang sumagot ng isang bagay tulad ng "Well, sa madaling salita, ito ang admin na ..." at higit pa sa teksto. Oo, noong unang panahon, noong ang propesyon ng inhinyero ng DevOps ay umuusbong pa lamang mula sa mga pinaka mahuhusay na administrador sa mga tuntunin ng pagpapanatili ng serbisyo, ang mga pagkakaiba sa pagitan nila ay hindi halata sa lahat. Ngunit ngayon, kapag ang mga pag-andar ng devops at admin sa koponan ay naging lubhang naiiba, hindi katanggap-tanggap na malito sila sa isa't isa, o kahit na itumbas sila.
Ngunit ano ang ibig sabihin nito para sa negosyo?
Pag-hire, lahat tungkol dito.
Magbubukas ka ng bakante para sa "System Administrator", at ang mga kinakailangan na nakalista doon ay "pakikipag-ugnayan sa pag-unlad at mga customer", "CI/CD delivery system", "pagpapanatili ng mga server at kagamitan ng kumpanya", "administrasyon ng mga panloob na sistema" at iba pa sa; naiintindihan mo na ang employer ay nagsasalita ng walang kapararakan. Ang catch ay na sa halip na "System Administrator" ang pamagat ng bakante ay dapat na "DevOps Engineer", at kung ang pamagat na ito ay binago, ang lahat ay nahuhulog sa lugar.
Gayunpaman, anong impresyon ang nakukuha ng isang tao kapag nagbabasa ng ganoong bakante? Na ang kumpanya ay naghahanap ng isang multi-machine operator na magpapakalat ng parehong bersyon ng control at monitoring system at pipigain ang twister gamit ang kanyang mga ngipin...
Ngunit upang hindi mapataas ang antas ng pagkagumon sa droga sa labor market, sapat na na tawagan ang mga bakante sa pamamagitan ng kanilang mga wastong pangalan at malinaw na maunawaan na ang isang DevOps engineer at isang system administrator ay dalawang magkaibang entity. Ngunit ang hindi mapipigilan na pagnanais ng ilang mga tagapag-empleyo na ipakita ang pinakamalawak na posibleng listahan ng mga kinakailangan sa isang kandidato ay humahantong sa katotohanan na ang "klasikong" mga tagapangasiwa ng system ay huminto sa pag-unawa sa kung ano ang nangyayari sa kanilang paligid. Ano, ang propesyon ay mutating at sila ay nasa likod ng mga panahon?
Hindi hindi at isa pang pagkakataon ay hindi. Ang mga administrador ng imprastraktura na mamamahala sa mga panloob na server ng kumpanya, o sumasakop sa mga posisyon ng suporta sa L2/L3 at tumutulong sa ibang mga empleyado, ay hindi umalis at hindi aalis.
Maaari bang maging mga inhinyero ng DevOps ang mga espesyalistang ito? Syempre kaya nila. Sa katunayan, ito ay isang nauugnay na kapaligiran na nangangailangan ng mga kasanayan sa pangangasiwa ng system, ngunit bilang karagdagan dito, magtrabaho kasama ang pagsubaybay, mga sistema ng paghahatid at, sa pangkalahatan, ang malapit na pakikipag-ugnayan sa pangkat ng pagbuo at pagsubok ay idinagdag.
Isa pang Problema sa DevOps
Sa katunayan, ang lahat ay hindi limitado sa pag-hire at patuloy na pagkalito sa pagitan ng mga admin at devops. Sa ilang mga punto, ang negosyo ay nahaharap sa problema sa paghahatid ng mga update at pakikipag-ugnayan ng development team sa panghuling imprastraktura.
Marahil ay nang tumayo ang isang tiyuhin na may kumikinang na mga mata sa entablado ng ilang kumperensya at sinabing, βGinagawa namin ito at tinawag itong DevOps. Ang mga taong ito ay malulutas ang lahat ng iyong mga problema" - at nagsimulang sabihin kung gaano kahusay ang buhay sa kumpanya pagkatapos ipatupad ang mga kasanayan sa DevOps.
Gayunpaman, hindi sapat ang pag-hire ng isang DevOps engineer upang gawin ang lahat ng bagay sa nararapat. Ang kumpanya ay dapat sumailalim sa isang kumpletong pagbabagong DevOps, ibig sabihin, ang tungkulin at kakayahan ng aming mga DevOps ay dapat ding malinaw na nauunawaan sa panig ng pangkat ng pagbuo at pagsubok ng produkto. Mayroon kaming isang "kahanga-hangang" kuwento sa paksang ito na ganap na naglalarawan ng lahat ng kalupitan na nangyayari sa ilang mga lugar.
Sitwasyon. Kinakailangan ng DevOps na mag-deploy ng isang bersyon ng rollback system nang hindi talaga pinag-aaralan kung paano ito gagana. Ipagpalagay natin na sa loob ng sistema ng Mga Gumagamit ay mayroong magkahiwalay na mga patlang para sa pangalan, apelyido at password. Ang isang bagong bersyon ng produkto ay lumalabas, ngunit para sa mga developer, ang isang "rollback" ay isang magic wand na mag-aayos ng lahat, at hindi nila alam kung paano ito gumagana. Kaya, halimbawa, sa susunod na patch, pinagsama ng mga developer ang mga field ng una at apelyido, inilunsad ito sa produksyon, ngunit ang bersyon ay mabagal sa ilang kadahilanan. Anong nangyayari? Lumapit ang management sa devops at nagsasabing "Hilahin ang switch!", ibig sabihin, hinihiling sa kanya na bumalik sa nakaraang bersyon. Ano ang ginagawa ng devops? Bumalik ito sa nakaraang bersyon, ngunit dahil ayaw malaman ng mga developer kung paano ginawa ang rollback na ito, walang nagsabi sa devops team na kailangan ding i-rollback ang database. Bilang isang resulta, ang lahat ay nag-crash para sa amin, at sa halip na isang mabagal na website, ang mga gumagamit ay nakakakita ng "500" na error, dahil ang lumang bersyon ay hindi gumagana sa mga patlang ng bagong database. Hindi alam ni Devops ang tungkol dito. Ang mga developer ay tahimik. Nagsisimulang mawalan ng nerbiyos at pera ang management at naaalala ang mga backup, na nag-aalok na i-roll back mula sa kanila nang sa gayon ay βmay gagana man lang.β Bilang resulta, nawawala ang lahat ng data ng mga user sa loob ng isang yugto ng panahon.
Ang mga mani, siyempre, ay napupunta sa mga devops, na "hindi gumawa ng wastong sistema ng rollback," at walang nagmamalasakit na ang moose sa kuwentong ito ay mga developer.
Ang konklusyon ay simple: nang walang isang normal na diskarte sa DevOps tulad nito, ito ay walang gaanong pakinabang.
Ang pangunahing bagay na dapat tandaan: ang isang DevOps engineer ay hindi isang salamangkero, at walang kalidad na komunikasyon at dalawang-daan na pakikipag-ugnayan sa pag-unlad, hindi niya makayanan ang kanyang mga gawain. Hindi maaaring iwanang mag-isa ang mga dev sa kanilang "mga problema" o binibigyan ng utos na "huwag makialam sa mga developer, ang kanilang trabaho ay mag-code," at pagkatapos ay umaasa na sa isang kritikal na sandali ay gagana ang lahat ayon sa nararapat. Hindi iyon kung paano ito gumagana.
Mahalaga, ang DevOps ay isang kakayahan sa hangganan sa pagitan ng pamamahala at teknolohiya. Bukod dito, malayong malinaw na dapat mayroong higit na teknolohiya kaysa sa pamamahala sa cocktail na ito. Kung talagang gusto mong bumuo ng mas mabilis at mas mahusay na mga proseso ng pag-unlad, dapat kang magtiwala sa iyong devops team. Alam niya ang mga tamang tool, nagpatupad siya ng mga katulad na proyekto, alam niya kung paano ito gagawin. Tulungan siya, makinig sa kanyang payo, huwag subukang ihiwalay siya sa ilang uri ng autonomous unit. Kung ang mga admin ay maaaring gumana nang mag-isa, kung gayon ang mga devop ay walang silbi sa kasong ito; hindi ka nila matutulungan na maging mas mahusay kung ikaw mismo ay hindi gustong tumanggap ng tulong na ito.
At isang huling bagay: itigil ang nakakasakit sa mga administrator ng imprastraktura. Mayroon silang sariling, napakahalagang harap ng trabaho. Oo, ang isang administrator ay maaaring maging isang DevOps engineer, ngunit ito ay dapat mangyari sa kahilingan ng tao mismo, at hindi sa ilalim ng presyon. At walang mali sa katotohanang nais ng isang tagapangasiwa ng system na manatiling isang tagapangasiwa ng sistema - ito ang kanyang hiwalay na propesyon at ang kanyang karapatan. Kung nais mong sumailalim sa isang propesyonal na pagbabagong-anyo, hindi mo dapat kalimutan na kailangan mong bumuo ng hindi lamang mga teknolohikal na kasanayan, kundi pati na rin sa pamamahala. Malamang, ikaw ang bahala bilang isang pinuno upang tipunin ang lahat ng mga taong ito at turuan silang makipag-usap sa parehong wika.
Pinagmulan: www.habr.com