Mahirap bang maunawaan ang pangunahing punto kapag pinag-uusapan ang tungkol sa DevOps? Nakolekta namin para sa iyo ang matingkad na pagkakatulad, kapansin-pansing mga formulation at payo mula sa mga eksperto na makakatulong kahit na hindi mga espesyalista na makarating sa punto. Sa huli, ang bonus ay sariling DevOps ng mga empleyado ng Red Hat.
Ang terminong DevOps ay nagmula 10 taon na ang nakakaraan at naging isang malakas na kilusang pangkultura sa mundo ng IT, mula sa isang Twitter hashtag, isang tunay na pilosopiya na naghihikayat sa mga developer na gawin ang mga bagay nang mas mabilis, mag-eksperimento, at umulit pasulong. Ang DevOps ay naging inextricably na nauugnay sa konsepto ng digital transformation. Ngunit gaya ng madalas na nangyayari sa terminolohiya ng IT, sa nakalipas na sampung taon ay nakakuha ang DevOps ng maraming kahulugan, interpretasyon at maling paniniwala tungkol sa sarili nito.
Samakatuwid, madalas mong marinig ang mga tanong tungkol sa DevOps tulad ng, pareho ba ito ng maliksi? O ito ba ay ilang espesyal na pamamaraan? O isa lang itong kasingkahulugan ng salitang "collaboration"?
Kasama sa DevOps ang maraming iba't ibang konsepto (tuloy-tuloy na paghahatid, tuluy-tuloy na pagsasama, automation, atbp.), kaya maaaring maging mahirap ang pag-disstill ng kung ano ang mahalaga, lalo na kapag masigasig ka sa paksa. Gayunpaman, ang kasanayang ito ay lubhang kapaki-pakinabang, hindi mahalaga kung sinusubukan mong ihatid ang iyong mga ideya sa iyong mga nakatataas o simpleng pagsasabi sa isang tao mula sa iyong pamilya o mga kaibigan tungkol sa iyong trabaho. Samakatuwid, isantabi muna natin ang mga terminolohikal na nuances ng DevOps sa ngayon at tumuon sa malaking larawan.
Ano ang DevOps: 6 na Kahulugan at Analogies
Hiniling namin sa mga eksperto na ipaliwanag ang kakanyahan ng DevOps nang simple at maikli hangga't maaari upang ang halaga nito ay maging malinaw sa mga mambabasa na may anumang antas ng teknikal na kaalaman. Batay sa mga resulta ng mga pag-uusap na ito, pinili namin ang mga pinakakapansin-pansing pagkakatulad at kapansin-pansing mga formulation na tutulong sa iyong buuin ang iyong kwento tungkol sa DevOps.
1. Ang DevOps ay isang kultural na kilusan
"Ang DevOps ay isang kultural na kilusan kung saan kinikilala ng magkabilang partido (mga developer ng software at mga espesyalista sa pagpapatakbo ng IT system) na ang software ay hindi nagdudulot ng tunay na mga benepisyo hanggang sa may magsimulang gumamit nito: mga customer, kliyente, empleyado, hindi ang punto," sabi ni Eveline Oehrlich, senior research analyst sa DevOps Institute. “Samakatuwid, magkatuwang na tinitiyak ng dalawang partidong ito ang mabilis at mataas na kalidad na paghahatid ng software.”
2. Ang DevOps ay tungkol sa pagbibigay kapangyarihan sa mga developer.
“Binibigyan ng DevOps ang mga developer na magkaroon ng mga application, patakbuhin ang mga ito, at pamahalaan ang paghahatid mula simula hanggang katapusan."
"Karaniwan, ang DevOps ay pinag-uusapan bilang isang paraan upang mapabilis ang paghahatid ng mga aplikasyon sa produksyon sa pamamagitan ng pagbuo at pagpapatupad ng mga awtomatikong proseso," sabi ni Jai Schniepp, direktor ng mga platform ng DevOps sa kompanya ng insurance na Liberty Mutual. "Ngunit para sa akin ito ay isang mas pangunahing bagay." Binibigyang kapangyarihan ng DevOps ang mga developer na magkaroon ng mga application o partikular na piraso ng software, patakbuhin ang mga ito, at pamahalaan ang kanilang paghahatid mula simula hanggang matapos. Tinatanggal ng DevOps ang pagkalito sa pananagutan at ginagabayan ang lahat ng kasangkot sa paglikha ng isang automated, imprastraktura na hinimok ng developer."
3. Ang DevOps ay tungkol sa pakikipagtulungan sa paggawa at paghahatid ng mga application.
"Sa madaling salita, ang DevOps ay isang diskarte sa paggawa at paghahatid ng software kung saan nagtutulungan ang lahat," sabi ni Gur Staf, presidente at pinuno ng digital business automation sa BMC.
4. Ang DevOps ay isang pipeline
"Posible lang ang pagpupulong ng conveyor kung magkasya ang lahat ng bahagi."
"Ihahambing ko ang DevOps sa isang linya ng pagpupulong ng kotse," patuloy ng Gur Staff. – Ang ideya ay idisenyo at gawin ang lahat ng mga bahagi nang maaga upang sila ay mabuo nang walang indibidwal na pagsasaayos. Ang pagpupulong ng conveyor ay posible lamang kung magkasya ang lahat ng bahagi. Dapat isaalang-alang ng mga nagdidisenyo at gumagawa ng makina kung paano i-mount ito sa katawan o frame. Ang mga gumagawa ng preno ay dapat mag-isip tungkol sa mga gulong, at iba pa. Ang parehong ay dapat na totoo sa software.
Ang isang developer na gumagawa ng logic ng negosyo o isang user interface ay dapat mag-isip tungkol sa database na nag-iimbak ng impormasyon ng customer, ang mga hakbang sa seguridad upang protektahan ang data ng user, at kung paano gagana ang lahat ng ito kapag ang serbisyo ay nagsimulang maghatid ng malaki, marahil kahit multimillion-dollar na madla ng user. ."
"Ang paghikayat sa mga tao na makipagtulungan at pag-isipan ang mga bahagi ng trabaho na ginagawa ng iba, sa halip na tumuon lamang sa kanilang sariling mga gawain, ay ang pinakamalaking balakid na malalampasan. Kung magagawa mo ito, mayroon kang magandang pagkakataon ng digital transformation,” dagdag ng Gur Staff.
5. Ang DevOps ay ang tamang kumbinasyon ng mga tao, proseso at automation
Si Jayne Groll, executive director ng DevOps Institute, ay nag-alok ng isang mahusay na pagkakatulad upang ipaliwanag ang DevOps. Sa kanyang mga salita, "Ang DevOps ay tulad ng isang recipe na may tatlong pangunahing kategorya ng mga sangkap: mga tao, proseso at automation. Karamihan sa mga sangkap na ito ay maaaring kunin mula sa ibang mga lugar at pinagmumulan: Lean, Agile, SRE, CI/CD, ITIL, leadership, culture, tools. Ang sikreto sa DevOps, tulad ng anumang magandang recipe, ay kung paano makuha ang tamang proporsyon at paghahalo ng mga sangkap na ito upang mapataas ang bilis at kahusayan ng paggawa at paglabas ng mga application.
6. Ang DevOps ay kapag ang mga programmer ay nagtatrabaho tulad ng isang koponan ng Formula 1
"Ang karera ay hindi binalak mula sa simula hanggang sa katapusan, ngunit sa kabaligtaran, mula sa pagtatapos hanggang sa simula."
"Kapag pinag-uusapan ko kung ano ang aasahan mula sa isang DevOps initiative, iniisip ko ang isang NASCAR o Formula 1 racing team bilang isang halimbawa," sabi ni Chris Short, senior manager ng cloud platform marketing sa Red Hat at publisher ng DevOps'ish newsletter. – Ang pinuno ng naturang koponan ay may isang layunin: upang makuha ang pinakamataas na posibleng lugar sa pagtatapos ng karera, na isinasaalang-alang ang mga mapagkukunan na magagamit sa koponan at ang mga hamon na nangyari dito. Sa kasong ito, ang karera ay binalak hindi mula sa simula hanggang sa matapos, ngunit sa kabaligtaran, mula sa pagtatapos hanggang sa simula. Una, ang isang ambisyosong layunin ay itinakda, at pagkatapos ay ang mga paraan upang makamit ito ay tinutukoy. Pagkatapos ay hinati-hati sila sa mga subtask at itinalaga sa mga miyembro ng koponan."
"Ang koponan ay gumugugol ng buong linggo bago ang karera na ginagawang perpekto ang pit stop. Gumagawa siya ng lakas ng pagsasanay at cardio upang manatili sa hugis para sa isang nakakapagod na araw ng karera. Mga kasanayan sa pagtutulungan upang malutas ang anumang mga problema na maaaring lumitaw sa panahon ng karera. Gayundin, dapat sanayin ng development team ang kasanayan sa pagpapalabas ng mga bagong bersyon nang madalas. Kung mayroon kang ganitong mga kasanayan at isang mahusay na gumaganang sistema ng seguridad, ang paglulunsad ng mga bagong bersyon sa produksyon ay nangyayari rin nang mas madalas. Sa ganitong pananaw sa mundo, ang pagtaas ng bilis ay nangangahulugan ng pagtaas ng kaligtasan, "sabi ni Short.
"Hindi ito tungkol sa paggawa ng 'tamang bagay,'" dagdag ni Short, "ito ay tungkol sa pag-aalis ng maraming bagay hangga't maaari na humahadlang sa nais na resulta. Makipagtulungan at umangkop batay sa feedback na natatanggap mo sa real time. Maging handa para sa mga anomalya at magtrabaho upang mapabuti ang kalidad upang mabawasan ang epekto nito sa pag-unlad patungo sa iyong layunin. Ito ang naghihintay sa atin sa mundo ng DevOps.”
Paano sukatin ang DevOps: 10 tip mula sa mga eksperto
Ang mga DevOps at mass DevOps ay ganap na magkaibang mga bagay. Sasabihin namin sa iyo kung paano malalampasan ang mga hadlang sa daan mula sa una hanggang sa pangalawa.
Para sa maraming organisasyon, ang paglalakbay sa DevOps ay nagsisimula nang madali at kaaya-aya. Ang mga maliliit na madamdaming koponan ay nilikha, ang mga lumang proseso ay pinapalitan ng mga bago, at ang mga unang tagumpay ay malapit nang dumating.
Naku, isa lamang itong maling kinang, isang ilusyon ng pag-unlad, sabi ni Ben Grinnell, managing director at pinuno ng digital sa consultancy North Highland. Ang mga maagang panalo ay tiyak na nakapagpapatibay, ngunit hindi ito nakakatulong na makamit ang pinakalayunin ng malawakang paggamit ng DevOps sa buong organisasyon.
Madaling makita na ang resulta ay isang kultura ng paghahati sa pagitan ng "tayo" at "kanila".
"Kadalasan, inilulunsad ng mga organisasyon ang mga pangunguna na proyektong ito sa pag-aakalang gagawa sila ng daan para sa mainstream na DevOps, nang hindi isinasaalang-alang kung magagawa o handang sundin ng iba ang landas na iyon," paliwanag ni Ben Grinnell. – Ang mga koponan para sa pagpapatupad ng mga naturang proyekto ay karaniwang kinukuha mula sa mga “Varangians” na may tiwala sa sarili na nakagawa na ng katulad sa ibang mga lugar, ngunit bago sa iyong organisasyon. Kasabay nito, hinihikayat silang labagin at sirain ang mga alituntunin na nananatiling umiiral sa lahat. Madaling makita na ang resulta ay isang kultura ng "tayo" at "kanila" na pumipigil sa paglipat ng kaalaman at kasanayan.
"At ang problemang pangkultura na ito ay isa lamang sa mga dahilan kung bakit mahirap sukatin ang DevOps. Ang mga koponan ng DevOps ay nahaharap sa mas mataas na mga teknikal na hamon na tipikal ng mabilis na lumalagong mga kumpanya ng IT-first, "sabi ni Steve Newman, tagapagtatag at tagapangulo ng Scalyr.
“Sa modernong mundo, nagbabago ang mga serbisyo sa sandaling kailanganin. Napakahusay na patuloy na magpatupad at magpatupad ng mga bagong feature, ngunit ang pag-coordinate ng prosesong ito at pag-aalis ng mga problemang lumalabas ay talagang nakakasakit ng ulo, dagdag ni Steve Newman. – Sa napakabilis na lumalagong mga organisasyon, ang mga inhinyero sa mga cross-functional na team ay nagpupumilit na mapanatili ang visibility sa pagbabago at ang dependency-level cascading effect na nalilikha nito. Bukod dito, ang mga inhinyero ay hindi nasisiyahan kapag sila ay pinagkaitan ng pagkakataong ito at, bilang isang resulta, nagiging mas mahirap para sa kanila na maunawaan ang kakanyahan ng mga problema na lumalabas.
Paano malalampasan ang mga hamong ito na inilarawan sa itaas at lumipat sa malawakang paggamit ng DevOps sa isang malaking organisasyon? Hinihimok ng mga eksperto ang pasensya, kahit na ang iyong pangwakas na layunin ay pabilisin ang iyong ikot ng pagbuo ng software at mga proseso ng negosyo.
1. Tandaan na ang pagbabago ng kultura ay nangangailangan ng oras.
Jayne Groll, Executive Director, DevOps Institute: "Sa aking opinyon, ang pagpapalawak ng DevOps ay dapat na incremental at umuulit bilang maliksi na pag-unlad (at pantay na nakakaantig sa kultura). Binibigyang-diin ng Agile at DevOps ang mga maliliit na koponan. Ngunit habang lumalaki ang mga koponang ito sa bilang at pagsasama-sama, napupunta tayo sa mas maraming tao na gumagamit ng mga bagong paraan ng pagtatrabaho, at bilang isang resulta mayroong isang napakalaking pagbabago sa kultura."
2. Gumugol ng sapat na oras sa pagpaplano at pagpili ng plataporma
Eran Kinsbruner, Lead Technical Evangelist sa Perfecto: “Para gumana ang scaling, dapat munang matutunan ng mga DevOps team na pagsamahin ang mga tradisyunal na proseso, tool, at kasanayan, at pagkatapos ay dahan-dahang pangalagaan at patatagin ang bawat indibidwal na yugto ng DevOps. Nagsisimula ang lahat sa maingat na pagpaplano ng mga kwento ng gumagamit at mga stream ng halaga, na sinusundan ng pagsusulat ng software at kontrol ng bersyon gamit ang pag-develop na nakabatay sa trunk o iba pang mga diskarte na pinakaangkop para sa pagsasanga at pagsasama ng code.
"Pagkatapos ay darating ang yugto ng pagsasama at pagsubok, kung saan ang isang scalable platform para sa automation ay kinakailangan na. Dito mahalaga para sa mga koponan ng DevOps na pumili ng tamang platform na nababagay sa kanilang antas ng kasanayan at sa mga layunin ng pagtatapos ng proyekto.
Ang susunod na yugto ay ang pag-deploy sa produksyon at dapat itong ganap na awtomatiko gamit ang mga tool at lalagyan ng orkestrasyon. Mahalagang magkaroon ng mga virtualized na kapaligiran sa lahat ng yugto ng DevOps (production simulator, QA environment, at aktwal na production environment) at palaging gumamit lamang ng pinakabagong data para sa mga pagsubok upang makakuha ng mga nauugnay na konklusyon. Dapat matalino ang Analytics at may kakayahang magproseso ng malaking data na may mabilis at naaaksyunan na feedback."
3. Alisin ang pagkakasala sa pananagutan.
Gordon Haff, RedHat Evangelist: "Ang paglikha ng isang sistema at kapaligiran na nagpapahintulot at naghihikayat sa pag-eeksperimento ay nagbibigay-daan para sa kung ano ang kilala bilang matagumpay na mga pagkabigo sa maliksi na pagbuo ng software. Hindi ito nangangahulugan na walang ibang mananagot sa mga kabiguan. Sa katunayan, ang pagtukoy kung sino ang may pananagutan ay nagiging mas madali, dahil ang "pagiging responsable" ay hindi na nangangahulugang "nagdudulot ng aksidente." Iyon ay, ang kakanyahan ng responsibilidad ay nagbabago nang husay. Apat na salik ang nagiging kritikal: ang lawak ng pagkagambala, mga diskarte, mga proseso ng produksyon at mga insentibo." (Maaari kang magbasa nang higit pa tungkol sa mga salik na ito sa artikulo ni Gordon Huff na "Mga aralin sa DevOps: 4 na aspeto ng malusog na mga eksperimento.")
4. I-clear ang landas pasulong
Ben Grinnell, managing director at pinuno ng digital sa consultancy North Highland: “Upang makamit ang sukat, inirerekumenda ko ang paglulunsad ng programang “path clearing” kasama ng mga proyektong pangunguna. Ang layunin ng programang ito ay linisin ang mga basurang iniiwan ng mga DevOps pioneer, tulad ng mga lumang alituntunin at mga bagay na tulad niyan, upang manatiling malinaw ang landas ng pasulong.”
“Bigyan ang mga tao ng suporta sa organisasyon at momentum sa pamamagitan ng komunikasyon na higit pa sa pangunguna na grupo sa pamamagitan ng malawakang pagdiriwang ng mga tagumpay ng mga bagong paraan ng pagtatrabaho. Turuan ang mga taong kasali sa susunod na wave ng mga proyekto ng DevOps at kinakabahan sa paggamit ng DevOps sa unang pagkakataon. At tandaan na ang mga taong ito ay ibang-iba sa mga pioneer.”
5. Demokrasya ng mga kasangkapan
Steve Newman, tagapagtatag at tagapangulo ng Scalyr: "Ang mga tool ay hindi dapat itago sa mga tao, at dapat itong medyo madaling matutunan para sa sinumang gustong maglaan ng oras. Kung ang kakayahang mag-query ng mga log ay limitado sa tatlong tao na "certified" na gumamit ng tool, palagi kang magkakaroon ng maximum na tatlong tao na magagamit upang mahawakan ang problema, kahit na mayroon kang napakalaking computing environment. Sa madaling salita, mayroong isang bottleneck dito na maaaring humantong sa malubhang kahihinatnan (negosyo).
6. Lumikha ng mga perpektong kondisyon para sa pangkatang gawain
Tom Clark, pinuno ng Common Platform sa ITV: "Magagawa mo ang lahat, ngunit hindi lahat ng sabay-sabay. Kaya magtakda ng malalaking layunin, magsimula sa maliit, at sumulong sa mabilis na pag-ulit. Sa paglipas ng panahon, magkakaroon ka ng reputasyon sa paggawa ng mga bagay-bagay, kaya gugustuhin din ng iba na gamitin ang iyong mga pamamaraan. At huwag mag-alala tungkol sa pagbuo ng isang lubos na epektibong koponan. Sa halip, bigyan ang mga tao ng perpektong kondisyon sa pagtatrabaho at susunod ang kahusayan.”
7. Huwag kalimutan ang tungkol sa Conway's Law at Kanban boards
Logan Daigle, Direktor ng Software Delivery at DevOps Strategy sa CollabNetVersionOne: “Mahalagang maunawaan ang mga kahihinatnan ng Batas ng Conway. Sa aking maluwag na paraphrase, ang batas na ito ay nagsasaad na ang mga produktong ginagawa namin at ang mga prosesong ginagamit namin para gawin iyon, kasama ang DevOps, ay lumabas na nakabalangkas sa parehong paraan tulad ng aming organisasyon."
"Kung mayroong maraming mga silo sa isang organisasyon, at ang kontrol ay nagbabago ng mga kamay nang maraming beses kapag nagpaplano, nagtatayo at naglalabas ng software, ang epekto ng scaling ay magiging zero o panandalian. Kung ang isang organisasyon ay bumuo ng mga cross-functional na koponan sa paligid ng mga produkto na pinondohan ng isang focus sa merkado, kung gayon ang mga pagkakataon ng tagumpay ay tumataas nang malaki."
"Ang isa pang mahalagang aspeto ng pag-scale ay ang pagpapakita ng lahat ng gawaing isinasagawa (WIP, workinprogress) sa mga Kanban board. Kapag ang isang organisasyon ay may lugar kung saan makikita ng mga tao ang mga bagay na ito, lubos nitong hinihikayat ang pakikipagtulungan, na may positibong epekto sa pag-scale."
8. Maghanap ng mga lumang peklat
Manuel Pais, consultant ng DevOps at co-author ng Team Topologies: "Ang pagkuha ng mga kasanayan sa DevOps na lampas sa Dev at Ops mismo at sinusubukang ilapat ang mga ito sa iba pang mga function ay hindi isang pinakamainam na diskarte. Ito ay tiyak na magkakaroon ng kaunting epekto (halimbawa, sa pamamagitan ng pag-automate ng manu-manong kontrol), ngunit higit pa ang maaaring makamit kung magsisimula tayo sa pag-unawa sa mga proseso ng paghahatid at feedback.
“Kung may mga lumang peklat sa IT system ng isang organisasyon - mga pamamaraan at mekanismo ng pamamahala na ipinatupad bilang resulta ng mga nakaraang insidente, ngunit nawala ang kanilang kaugnayan (dahil sa mga pagbabago sa mga produkto, teknolohiya o proseso) - kung gayon tiyak na kailangang alisin ang mga ito o pinaayos, sa halip na i-automate ang hindi mahusay o hindi kinakailangang mga proseso."
9. Huwag magpalahi ng mga opsyon sa DevOps
Anthony Edwards, Direktor ng Operasyon sa Talong: "Ang DevOps ay isang napakalabing termino, kaya ang bawat koponan ay nagtatapos sa sarili nitong bersyon ng DevOps. At wala nang mas masahol pa kapag ang isang organisasyon ay biglang may 20 na uri ng DevOps na hindi masyadong nagkakasundo. Imposible para sa bawat isa sa tatlong development team na magkaroon ng sarili nilang espesyal na interface sa pagitan ng development at pamamahala ng produkto. Hindi rin dapat magkaroon ng sariling natatanging inaasahan ang mga produkto para sa paghawak ng feedback kapag inilipat sa isang production simulator. Kung hindi, hindi mo masusukat ang DevOps."
10. Ipangaral ang halaga ng negosyo ng DevOps
Steve Newman, tagapagtatag at tagapangulo ng Scalyr: “Magtrabaho para kilalanin ang halaga ng DevOps. Matuto at huwag mag-atubiling pag-usapan ang mga benepisyo ng iyong ginagawa. Ang DevOps ay isang hindi kapani-paniwalang pagtitipid ng oras at pera (isipin na lang: mas kaunting downtime, mas maikling oras para makabawi), at dapat na walang pagod na bigyang-diin (at ipangaral) ng mga koponan ng DevOps ang kahalagahan ng mga hakbangin na ito sa tagumpay ng negosyo. Sa ganitong paraan maaari mong palawakin ang bilog ng mga sumusunod at mapataas ang impluwensya ng DevOps sa organisasyon."
BONUS
Sa Darating ang sarili naming DevOps sa Setyembre 13 - oo, ang Red Hat, bilang isang tagagawa ng software, ay may sariling mga koponan at kasanayan sa DevOps.
Ang aming engineer na si Mark Birger, na bumuo ng mga internal na serbisyo ng automation para sa iba pang mga grupo sa buong organisasyon, ay magsasabi ng kanyang sariling kuwento sa purong Russian - kung paano ang Red Hat DevOps team ay nag-migrate ng mga application mula sa Hat Virtualization virtual environment na pinamamahalaan ng Ansible sa isang ganap na format ng container sa ang OpenShift platform.
Ngunit hindi iyon ang lahat:
Kapag nailipat na ng mga organisasyon ang mga workload sa mga container, maaaring hindi gumana ang mga tradisyonal na paraan ng pagsubaybay sa application. Sa ikalawang pag-uusap ay ipapaliwanag namin ang aming motibasyon para sa pagbabago ng paraan ng aming pag-log at ipakita ang pagpapatuloy ng landas na humantong sa amin sa mga modernong paraan ng pag-log at pagsubaybay.
Pinagmulan: www.habr.com