Kamakailan lamang, ang mga naturang patalastas ay bumaha sa Internet. Sa kabila ng kaaya-ayang suweldo, hindi maaaring hindi mapahiya na ang ligaw na maling pananampalataya ay nakasulat sa loob. Sa una ay ipinapalagay na ang "DevOps" at "engineer" ay maaaring magkadikit sa isang salita, at pagkatapos ay mayroong isang random na listahan ng mga kinakailangan, ang ilan ay malinaw na kinopya mula sa bakante ng sysadmin.
Sa post na ito gusto kong pag-usapan nang kaunti kung paano tayo nakarating sa puntong ito ng buhay, kung ano talaga ang DevOps at kung ano ang gagawin dito ngayon.
Ang ganitong mga bakante ay maaaring hatulan sa lahat ng posibleng paraan, ngunit ang katotohanan ay nananatili: marami sa kanila, at ito ay kung paano gumagana ang merkado sa sandaling ito. Nagdaos kami ng isang devop conference at hayagang ipinahayag: “ - hindi para sa mga inhinyero ng DevOps." Ito ay tila kakaiba at ligaw sa marami: kung bakit ang mga taong gumagawa ng ganap na komersyal na kaganapan ay sumasalungat sa merkado. Ngayon ay ipapaliwanag namin ang lahat.
Tungkol sa kultura at proseso
Magsimula tayo sa katotohanan na ang DevOps ay hindi isang disiplina sa engineering. Nagsimula ang lahat sa katotohanan na ang makasaysayang itinatag na dibisyon ng mga tungkulin ay hindi gumagana para sa kalidad ng mga produkto. Kapag ang mga programmer ay nagprograma lamang, ngunit ayaw makarinig ng anuman tungkol sa pagsubok, ang software ay puno ng mga bug. Kapag walang pakialam ang mga admin kung paano o bakit isinulat ang software, nagiging impiyerno ang suporta.
Halimbawa, inilalarawan ang pagkakaiba sa pagitan ng isang administrator ng system at isang diskarte sa SRE sa pamamahala ng serbisyo . Ang mga kagiliw-giliw na pag-aaral ay isinagawa sa loob — malinaw na ang pinakamahuhusay na developer sa anumang paraan ay namamahala na mag-deploy ng mga bagong pagbabago sa produksyon nang mas mabilis kaysa isang beses sa isang oras. Sinusuri nila gamit ang kanilang mga kamay nang hindi hihigit sa 10% (makikita ito mula sa ). Paano nila ito ginagawa? "Excel or die" sabi ng isa sa mga heading ng ulat. Para sa isang detalyadong talakayan ng mga istatistikang ito sa konteksto ng pagsubok, maaari kang sumangguni sa pangunahing tono ng Baruch Sadogursky sa aming iba pang kumperensya, Heisenbug.
“Kapag walang kasunduan sa mga kasama,
Hindi magiging maganda ang mga bagay para sa kanila,
At walang lalabas dito, tanging paghihirap.
Noong unang panahon, isang Swan, isang Crayfish at isang Pike..."
Anong bahagi ng mga web programmer ang sa tingin mo ay talagang nauunawaan ang mga kundisyon kung saan ginagamit ang kanilang mga application sa produksyon? Ilan sa kanila ang pupunta sa mga admin at susubukang malaman kung ano ang mangyayari kung mag-crash ang database? At sino sa kanila ang pupunta sa mga tester at hihilingin sa kanila na turuan sila kung paano magsulat ng mga pagsusulit nang tama? At mayroon ding mga security guard, product manager, at isang grupo ng iba pang mga tao.
Ang pangkalahatang ideya ng DevOps ay lumikha ng pakikipagtulungan sa pagitan ng mga tungkulin at mga departamento. Una sa lahat, ito ay nakakamit hindi sa pamamagitan ng ilang matalinong na-configure na software, ngunit sa pamamagitan ng pagsasanay ng komunikasyon. Ang DevOps ay tungkol sa kultura, mga kasanayan, pamamaraan at proseso. Walang espesyalidad sa engineering na makakasagot sa mga tanong na ito.
Masamang bilog
Saan nagmula ang disiplina ng "devops engineering" noon? May version tayo! Maganda ang mga ideya ng DevOps—napakaganda kaya naging biktima sila ng sarili nilang tagumpay. Ang ilang malilim na recruiter at human trafficker, na may sariling kapaligiran, ay nagsimulang umikot sa buong paksang ito.
Isipin: kahapon ay gumagawa ka ng shawarma sa Khimki, at ngayon ikaw ay isang malaking tao, isang senior recruiter. Mayroong isang buong proseso ng paghahanap at pagpili ng mga kandidato, ang lahat ay hindi madali, kailangan mong maunawaan. Sabihin nating ang pinuno ng isang departamento ay nagsabi: maghanap ng isang espesyalista sa X. Itinalaga namin ang salitang "engineer" sa X, at tapos na kami. Kailangan ng Linux? Well, ito ay talagang isang Linux engineer, kung gusto mo ng DevOps, pagkatapos ay isang DevOps engineer. Ang bakante ay binubuo hindi lamang ng isang pamagat, kundi pati na rin ang ilang teksto na dapat ilagay sa loob. Ang pinakamadaling paraan ay ang magpasok ng isang set ng mga keyword mula sa Google, depende sa iyong imahinasyon. Binubuo ang DevOps ng dalawang salita - "Dev" at "Ops", na nangangahulugang kailangan nating idikit ang lahat ng keyword na nauugnay sa mga developer at administrator sa isang tumpok. Ganito lumilitaw ang mga bakante tungkol sa kahusayan sa 42 programming language at 20 taon ng paggamit ng Kubernetes at Swarm nang sabay-sabay. Diagram ng paggawa.
Ganito nag-ugat sa isipan ng mga tao ang walang kabuluhan at walang awa na imahe ng isang partikular na "devops" na superhero, na magko-configure sa lahat na i-deploy kay Jenkins, at darating ang kaligayahan. Naku, kung ganoon lang kadali ang lahat. "At ito rin ay kung paano mo mahuhuli ang mga tagapangasiwa ng system," sa palagay ng HR, "ito ay isang naka-istilong salita, ang mga keyword ay pareho, dapat nilang makuha ang pain."
Ang demand ay lumilikha ng supply, at ang lahat ng mga bakanteng basurang ito ay napunan ng nakakatuwang bilang ng mga administrator ng system na natanto: magagawa mo ang lahat tulad ng dati, ngunit makakuha ng ilang beses nang higit pa sa pamamagitan ng pagtawag sa iyong sarili na "devops." Tulad ng iyong pag-configure nang manu-mano ng mga server sa pamamagitan ng SSH nang paisa-isa, patuloy mong i-configure ang mga ito, ngunit ngayon ito ay parang isang kasanayan sa devops. Ito ay isang uri ng kumplikadong kababalaghan, na bahagyang nauugnay sa pagmamaliit ng mga klasikong admin at ang hype sa paligid ng DevOps, ngunit sa pangkalahatan, kung ano ang nangyari, nangyari.
So meron tayong supply and demand. Isang mabisyo na bilog na nagpapakain sa sarili. Ito ang ating nilalabanan (kabilang ang paggawa ng kumperensya ng DevOops).
Siyempre, bukod sa mga tagapangasiwa ng system na pinalitan ng pangalan ang kanilang mga sarili bilang "devops," may iba pang kalahok - halimbawa, mga propesyonal na SRE o Infrastructure-as-Code developer.
Ano ang ginagawa ng mga tao sa DevOps (talaga)
Kaya gusto mong magpatuloy sa pag-aaral at paglalapat ng mga kasanayan sa DevOps. Ngunit paano ito gagawin, saang direksyon titingin? Malinaw, hindi ka dapat umasa nang walang taros sa mga sikat na keyword.
Kung may trabaho, dapat may gumawa nito. Nalaman na natin na hindi ito "devops engineers", at sino? Tila mas tama na bumalangkas nito hindi sa mga tuntunin ng mga posisyon, ngunit sa mga tuntunin ng mga partikular na lugar ng trabaho.
Una, maaari mong tugunan ang puso ng DevOps—mga proseso at kultura. Ang kultura ay isang mabagal at mahirap na negosyo, at bagaman ito ay tradisyonal na responsibilidad ng mga tagapamahala, lahat ay kasangkot sa isang paraan o iba pa, mula sa mga programmer hanggang sa mga tagapangasiwa. Ilang buwan na ang nakalipas Tim Lister :
"Ang kultura ay tinutukoy ng mga pangunahing halaga ng organisasyon. Kadalasan ay hindi ito napapansin ng mga tao, ngunit dahil nagtrabaho sa pagkonsulta sa loob ng maraming taon, nakasanayan na natin itong mapansin. Pumasok ka sa isang kumpanya at literal sa loob ng ilang minuto ay sisimulan mong maramdaman kung ano ang nangyayari. Tinatawag namin itong "lasa". Minsan talaga masarap ang amoy na ito. Minsan nagiging sanhi ito ng pagduduwal. (...) Hindi mo mababago ang isang kultura hangga't hindi nauunawaan ang mga halaga at paniniwala sa likod ng mga partikular na aksyon. Ang pag-uugali ay madaling obserbahan, ngunit ang paghahanap ng mga paniniwala ay mahirap. Ang DevOps ay isa lamang magandang halimbawa kung paano nagiging mas kumplikado ang mga bagay."
Mayroon ding teknikal na bahagi ng isyu, siyempre. Kung susuriin ang iyong bagong code sa loob ng isang buwan, ngunit inilabas lamang pagkalipas ng isang taon, at imposibleng mapabilis ang lahat ng ito, maaaring hindi mo matupad ang mga magagandang kasanayan. Ang mabubuting gawi ay sinusuportahan ng magagandang kasangkapan. Halimbawa, na nasa isip ang ideya ng Infrastructure-as-Code, maaari mong gamitin ang anuman mula sa AWS CloudFormation at Terraform hanggang sa Chef-Ansible-Puppet. Kailangan mong malaman at magawa ang lahat ng ito, at isa na itong disiplina sa engineering. Mahalagang huwag malito ang sanhi sa epekto: una kang magtrabaho ayon sa mga prinsipyo ng SRE at pagkatapos lamang ipatupad ang mga prinsipyong ito sa anyo ng ilang partikular na teknikal na solusyon. Kasabay nito, ang SRE ay isang napakakomprehensibong pamamaraan na hindi nagsasabi sa iyo kung paano i-set up ang Jenkins, ngunit tungkol sa limang pangunahing prinsipyo:
- Pinahusay na komunikasyon sa pagitan ng mga tungkulin at mga departamento
- Pagtanggap ng mga pagkakamali bilang mahalagang bahagi ng trabaho
- Paunti-unti ang paggawa ng mga pagbabago
- Paggamit ng tooling at iba pang automation
- Pagsusukat sa lahat ng bagay na maaaring masukat
Ito ay hindi lamang ilang hanay ng mga pahayag, ngunit isang tiyak . Halimbawa, sa landas patungo sa pagtanggap ng mga error, kakailanganin mong maunawaan ang mga panganib, sukatin ang availability at hindi available na mga serbisyo gamit ang isang bagay tulad ng SLI () at SLO (), matutong magsulat ng mga postmortem at gawin itong hindi nakakatakot.
Sa disiplina ng SRE, ang paggamit ng mga kasangkapan ay isang bahagi lamang ng tagumpay, bagama't isang mahalagang bahagi. Kailangan nating patuloy na umunlad sa teknikal, tingnan kung ano ang nangyayari sa mundo at kung paano ito mailalapat sa ating trabaho.
Sa turn, ang mga solusyon sa Cloud Native ay naging napakasikat na ngayon. Gaya ng tinukoy ng Cloud Native Computing Foundation ngayon, ang mga teknolohiya ng Cloud Native ay nagbibigay-daan sa mga organisasyon na bumuo at magpatakbo ng mga scalable na application sa mga dynamic na kapaligiran ngayon, gaya ng pampubliko, pribado, at hybrid na ulap. Kasama sa mga halimbawa ang mga container, mga mesh ng serbisyo, mga microservice, hindi nababagong imprastraktura, at mga declarative na API. Ang lahat ng mga diskarteng ito ay nagbibigay-daan sa maluwag na pinagsamang mga sistema upang manatiling nababanat, mapapamahalaan, at lubos na napapansin. Ang mahusay na automation ay nagbibigay-daan sa mga inhinyero na gumawa ng malalaking pagbabago nang madalas at may mga predictable na resulta nang hindi ito ginagawang isang gawaing-bahay. Ang lahat ng ito ay sinusuportahan ng isang stack ng mga kilalang tool tulad ng Docker at Kubernetes.
Ang medyo kumplikado at malawak na kahulugan ay dahil sa ang katunayan na ang lugar ay medyo kumplikado din. Sa isang banda, pinagtatalunan na ang mga bagong pagbabago sa sistemang ito ay dapat idagdag nang simple. Sa kabilang banda, upang malaman kung paano lumikha ng isang uri ng containerized na kapaligiran kung saan ang mga maluwag na pinagsamang serbisyo ay nabubuhay sa isang imprastraktura na tinukoy ng software at inihahatid doon gamit ang tuluy-tuloy na CI/CD, at bumuo ng mga kasanayan sa DevOps sa lahat ng ito - lahat ng ito ay nangangailangan ng higit pa kaysa sa isang kumain ng aso.
Ano ang gagawin sa lahat ng ito
Ang bawat tao'y malulutas ang mga problemang ito sa kanilang sariling paraan: halimbawa, maaari kang mag-publish ng mga normal na bakante upang masira ang mabisyo na bilog. Maaari mong malaman kung ano ang ibig sabihin ng mga salita tulad ng DevOps at Cloud Native at gamitin ang mga ito nang tama at to the point. Maaari kang bumuo sa DevOps at ipakita ang mga tamang diskarte sa pamamagitan ng iyong halimbawa.
May conference kami , na nagbibigay ng pagkakataong mas malaliman ang mga bagay na napag-usapan lang natin. Mayroong ilang mga pangkat ng mga ulat para dito:
- Mga proseso at kultura;
- Site Reliability Engineering;
- Cloud Native;
Paano pumili kung saan pupunta? Mayroong isang banayad na punto dito. Sa isang banda, ang DevOps ay tungkol sa pakikipag-ugnayan, at talagang gusto ka naming dumalo sa mga presentasyon mula sa iba't ibang mga bloke. Sa kabilang banda, kung ikaw ay isang development manager na dumating sa kumperensya upang tumutok sa isang partikular na gawain, kung gayon walang nililimitahan ka - malinaw naman, ito ay magiging isang bloke tungkol sa mga proseso at kultura. Huwag kalimutan na magkakaroon ka ng mga pag-record pagkatapos ng kumperensya (pagkatapos punan ang form ng feedback), para palagi kang makakapanood ng hindi gaanong mahahalagang presentasyon sa ibang pagkakataon.
Malinaw, sa mismong kumperensya hindi ka maaaring pumunta sa tatlong mga track nang sabay-sabay, kaya inayos namin ang programa sa paraang ang bawat time slot ay may mga paksa para sa bawat panlasa.
Ang natitira na lang ay upang maunawaan kung ano ang gagawin kung ikaw ay isang DevOps engineer! Una, subukang tukuyin kung ano talaga ang iyong ginagawa. Kadalasan gusto nilang tawagan ang salitang ito:
- Mga developer na nagtatrabaho sa imprastraktura. Ang mga pangkat ng mga ulat tungkol sa SRE at Cloud Native ay pinakaangkop para sa iyo.
- Mga tagapangasiwa ng system. Ito ay mas kumplikado dito. Ang DevOops ay hindi tungkol sa pangangasiwa ng system. Sa kabutihang palad, mayroong maraming mahusay na mga kumperensya, libro, artikulo, video sa Internet, atbp sa paksa ng pangangasiwa ng system. Sa kabilang banda, kung interesado kang paunlarin ang iyong sarili sa mga tuntunin ng pag-unawa sa kultura at mga proseso, pag-aaral tungkol sa mga teknolohiya sa cloud at mga detalye ng buhay kasama ang Cloud Native, gustung-gusto naming makita ka! Isipin ito: ikaw ay gumagawa ng pangangasiwa, at pagkatapos ay ano ang iyong gagawin? Upang maiwasan ang biglaang makita ang iyong sarili sa isang hindi kasiya-siyang sitwasyon, dapat kang matuto ngayon.
May isa pang pagpipilian: magpapatuloy ka at patuloy na i-claim na ikaw nga partikular na isang DevOps engineer at wala nang iba, anuman ang ibig sabihin nito. Pagkatapos ay kailangan ka naming biguin, ang DevOops ay hindi isang kumperensya para sa mga inhinyero ng DevOps!
Slide mula sa sa Munich
Ang DevOops 2020 Moscow ay gaganapin sa Abril 29-30 sa Moscow, ang mga tiket ay magagamit na .
Bilang kahalili, maaari mo hanggang Pebrero 8. Pakitandaan na kapag pinupunan ang form, dapat mong piliin ang target na madla na higit na makikinabang sa iyong ulat (may nakabaon na surpresa sa loob ng listahan).
Pinagmulan: www.habr.com