Ang kahulugan ng DevOps ay napakakumplikado, kaya kailangan nating simulan muli ang talakayan tungkol dito sa bawat oras. Mayroong isang libong publikasyon sa paksang ito sa HabrΓ© lamang. Ngunit kung binabasa mo ito, malamang alam mo kung ano ang DevOps. Dahil hindi ako. Kamusta? Ang pangalan ko ay Alexander Titov (@), at pag-uusapan lang natin ang tungkol sa DevOps at ibabahagi ko ang aking karanasan.
Matagal ko nang pinag-iisipan kung paano gagawing kapaki-pakinabang ang aking kwento, kaya magkakaroon ng maraming mga katanungan dito - ang mga itinatanong ko sa aking sarili at ang mga itatanong ko sa mga kliyente ng aming kumpanya. Sa pagsagot sa mga tanong na ito, nagiging mas mahusay ang pag-unawa. Sasabihin ko sa iyo kung bakit kailangan ang DevOps mula sa aking pananaw, kung ano ito, muli, mula sa aking pananaw, at kung paano mauunawaan na muli kang lumilipat patungo sa DevOps mula sa aking pananaw. Ang huling punto ay sa pamamagitan ng mga tanong. Sa pamamagitan ng pagsagot sa kanila para sa iyong sarili, mauunawaan mo kung ang iyong kumpanya ay sumusulong sa DevOps o kung may mga problema sa ilang paraan.
Sa isang pagkakataon ay sumakay ako sa mga alon ng mga pagsasanib at pagkuha. Una, nagtrabaho ako para sa isang maliit na startup na tinatawag na Qik, pagkatapos ay binili ito ng isang bahagyang mas malaking kumpanya na tinatawag na Skype, na pagkatapos ay binili ng isang bahagyang mas malaking kumpanya na tinatawag na Microsoft. Sa sandaling iyon, sinimulan kong makita kung paano nagbabago ang ideya ng DevOps sa iba't ibang laki ng mga kumpanya. Pagkatapos noon, naging interesado ako sa pagtingin sa DevOps mula sa isang market point of view, at itinatag namin ng aking mga kasamahan ang kumpanyang Express 42. Sa loob ng 6 na taon ngayon kami ay gumagalaw sa mga alon ng merkado.
Sa iba pang mga bagay, isa ako sa mga tagapag-ayos ng komunidad ng DevOps Moscow at ang tagapag-ayos ng DevOps-Days 2017, ngunit hindi ko inayos ang 2018. Gumagana ang Express 42 sa maraming kumpanya. Pinapalaki namin ang mga DevOps doon, panoorin kung paano ito nangyayari, gumawa ng mga konklusyon, sinusuri, sinasabi sa lahat ang aming mga konklusyon, at sinasanay ang mga tao sa mga kasanayan sa DevOps. Sa pangkalahatan, ginagawa namin ang aming makakaya upang madagdagan ang aming karanasan at kadalubhasaan sa bagay na ito.
Bakit DevOps
Ang unang tanong na bumabagabag sa lahat at palaging - bakit? Maraming mga tao ang nag-iisip na ang DevOps ay automation lamang o isang katulad na bagay na mayroon na ang bawat kumpanya.
β Nagkaroon kami ng Continuous Integration - nangangahulugan ito na mayroon na kaming DevOps, at bakit kailangan ang lahat ng bagay na ito? Nagsasaya sila sa ibang bansa, pero pinipigilan nila tayong magtrabaho!
Sa paglipas ng 9 na taon ng pag-unlad ng komunidad at pamamaraan, naging malinaw na ito ay hindi pa rin marketing glitter, ngunit hindi pa rin lubos na malinaw kung bakit ito kinakailangan. Tulad ng anumang tool at proseso, ang DevOps ay may mga partikular na layunin na sa huli ay nakakamit nito.
Ang lahat ng ito ay dahil sa ang katunayan na ang mundo ay nagbabago. Lumalayo siya sa diskarte sa enterprise, kapag ang mga kumpanya ay dumiretso sa isang panaginip, gaya ng pagkanta ng aming klasikong St. Petersburg, mula sa punto A hanggang sa punto B ayon sa isang tiyak na diskarte, na may partikular na istraktura na binuo para dito.
Sa prinsipyo, ang lahat ng bagay sa IT ay dapat na binuo ayon sa pamamaraang ito. Dito eksklusibong ginagamit ang IT para i-automate ang mga proseso.
Ang pag-automate ay hindi madalas na nagbabago, dahil kapag ang isang kumpanya ay bumagsak sa isang maayos na rut, ano ang dapat baguhin? Gumagana ito - huwag hawakan ito. Ngayon ang mga diskarte sa mundo ay nagbabago, at ang tinatawag na Agile ay nagmumungkahi na ang dulong punto B ay hindi agad nakikita.
Kapag ang isang kumpanya ay dumaan sa merkado, nakikipagtulungan sa isang kliyente, patuloy nitong ginalugad ang merkado at binabago ang dulong punto B. Bukod dito, mas madalas na nagbabago ang direksyon ng kumpanya, mas matagumpay ito sa huli, dahil pinipili nito ang mas maraming merkado mga niches.
Ang diskarte ay ipinakita ng isang kawili-wiling kumpanya na kamakailan kong natutunan. Ang One Box Shave ay isang serbisyo sa paghahatid ng subscription para sa mga pang-ahit at mga accessory sa pag-ahit sa isang kahon. Alam nila kung paano i-customize ang kanilang "kahon" para sa iba't ibang kliyente. Ginagawa ito ng isang partikular na software, na pagkatapos ay nagpapadala ng order sa pabrika ng Korea na gumagawa ng mga kalakal.
Ang produktong ito ay binili ng Unilever sa halagang $1 bilyon. Nakikipagkumpitensya na ito ngayon kay Gillette at inalis ang malaking bahagi ng mga mamimili sa merkado ng Amerika. Sabi ng One Box Shave:
β 4 na talim? Seryoso ka ba? Bakit mo ito kailangan - hindi ito nagpapabuti sa kalidad ng ahit. Ang isang espesyal na piniling cream, halimuyak at isang de-kalidad na labaha na may dalawang blades ay nakakalutas ng higit pang mga problema kaysa sa mga hangal na 4 na Gillette blades! Malapit na ba tayong mag 10?
Ganito nagbabago ang mundo. Sinasabi ng Unilever na mayroon silang isang cool na IT system na nagpapahintulot sa iyo na gawin ito. Sa huli, ito ay parang isang konsepto Time-to-market, na wala pang napag-usapan.
Ang punto ng Time-to-market ay hindi kung gaano kadalas tayo nagde-deploy. Madalas kang maaaring mag-deploy, ngunit ang mga ikot ng paglabas ay magiging mahaba. Kung ang tatlong buwang mga siklo ng paglabas ay ipinapatong sa isa't isa, inilipat ang mga ito ng isang linggo, lumalabas na ang kumpanya ay tila nagde-deploy nang isang beses sa isang linggo. At mula sa ideya hanggang sa huling pagpapatupad ay tumatagal ng 3 buwan.
Ang time-to-market ay tungkol sa pagliit ng oras mula sa ideya hanggang sa huling pagpapatupad.
Sa kasong ito, nakikipag-ugnayan ang software sa merkado. Ito ay kung paano nakikipag-ugnayan ang One Box Shave website sa kliyente. Wala silang mga salespeople - isang website lang kung saan nagki-click ang mga bisita at nag-iiwan ng mga kagustuhan. Alinsunod dito, ang isang bagong bagay ay dapat na patuloy na mai-post sa site at na-update alinsunod sa mga kagustuhan. Halimbawa, sa South Korea nag-ahit sila nang iba kaysa sa Russia, at gusto nila ang pabango hindi ng pine, ngunit, halimbawa, ng mga karot at banilya.
Dahil kinakailangan na mabilis na baguhin ang nilalaman ng site, malaki ang pagbabago sa pagbuo ng software. Sa pamamagitan ng software dapat nating malaman kung ano ang gusto ng kliyente. Dati, natutunan namin ito sa pamamagitan ng ilang roundabout na paraan, halimbawa, sa pamamagitan ng pamamahala sa negosyo. Pagkatapos ay idinisenyo namin ito, inilagay ang mga kinakailangan sa IT system, at lahat ay cool. Ngayon ay iba na - ang software ay idinisenyo ng lahat na kasangkot sa proseso, kabilang ang mga inhinyero, dahil sa pamamagitan ng mga teknikal na detalye ay natututo sila kung paano gumagana ang merkado at ibinabahagi rin ang kanilang mga insight sa negosyo.
Halimbawa, sa Qik bigla naming nalaman na talagang nagustuhan ng mga tao ang pag-upload ng mga listahan ng contact sa server, at binigyan nila kami ng application. Nung una hindi namin inisip yun. Sa isang klasikong kumpanya, lahat ay nagpasya na ito ay isang bug, dahil ang spec ay hindi sinabi na ito ay dapat gumana nang mahusay at sa pangkalahatan ay ipinatupad sa tuhod, sila ay pinatay ang tampok at sinabi: "Walang nangangailangan nito, ang pinakamahalagang bagay ay gumagana ang pangunahing pag-andar.β . At ang kumpanya ng teknolohiya ay nakikita ito bilang isang pagkakataon at nagsisimulang baguhin ang software alinsunod dito.
Noong 1968, isang visionary guy, si Melvin Conway, ang bumuo ng sumusunod na ideya.
Ang organisasyong lumilikha ng system ay napipigilan ng isang disenyo na ginagaya ang istraktura ng komunikasyon ng organisasyong iyon.
Sa higit pang detalye, para makagawa ng mga system na may ibang uri, dapat ay mayroon ka ring istraktura ng komunikasyon sa loob ng isang kumpanya ng ibang uri. Kung top-hierarchical ang istraktura ng iyong komunikasyon, hindi ka nito papayagan na lumikha ng mga system na makakapagbigay ng napakataas na indicator ng Time-to-Market.
Basahin maaari . Mahalaga para sa pag-unawa sa kultura o pilosopiya ng DevOps dahil ang tanging bagay na pangunahing nagbabago sa DevOps ay ang istruktura ng komunikasyon sa pagitan ng mga koponan.
Mula sa punto ng proseso, bago ang DevOps, ang lahat ng mga yugto: analytics, pagbuo, pagsubok, operasyon, ay linear.
Sa kaso ng DevOps, lahat ng mga prosesong ito ay nangyayari nang sabay-sabay.
Time-to-market ang tanging paraan na magagawa ito. Para sa mga taong nagtrabaho sa lumang proseso, ito ay mukhang cosmic, at sa pangkalahatan ay ganoon.
Kaya bakit kailangan ang DevOps?
Para sa pagbuo ng digital na produkto. Kung walang digital na produkto ang iyong kumpanya, hindi kailangan ang DevOps - ito ay napakahalaga.
Napagtagumpayan ng DevOps ang mga limitasyon sa bilis ng sunud-sunod na paggawa ng software. Sa loob nito ang lahat ng mga proseso ay nangyayari nang sabay-sabay.
Ang kahirapan ay tumataas. Kapag sinabi sa iyo ng mga ebanghelista ng DevOps na gagawing mas madali para sa iyo na maglabas ng software, ito ay walang kapararakan.
Sa DevOps, magiging mas kumplikado lang ang mga bagay.
Sa conference sa Avito stand, makikita mo kung ano ang pakiramdam ng pag-deploy ng Docker container - isang hindi makatotohanang gawain. Ang pagiging kumplikado ay nagiging mahigpit; kailangan mong mag-juggle ng maraming bola nang sabay-sabay.
Ganap na binabago ng DevOps ang proseso at organisasyon sa kumpanya β mas tiyak, hindi DevOps ang nagbabago, ngunit ang digital na produkto. Upang makarating sa DevOps, kailangan mo pa ring ganap na baguhin ang prosesong ito.
Mga tanong para sa isang espesyalista
Anong meron ka? Mga tanong na maaari mong itanong sa iyong sarili habang nagtatrabaho sa isang kumpanya at umuunlad bilang isang espesyalista.
Mayroon ka bang diskarte para sa paglikha ng isang digital na produkto? Kung mayroon man, mabuti na iyon. Nangangahulugan ito na ang iyong kumpanya ay lumilipat patungo sa DevOps.
Gumagawa na ba ng digital na produkto ang iyong kumpanya? Nangangahulugan ito na maaari kang umakyat sa isa pang antas at gumawa ng mga bagay nang mas kawili-wili - muli mula sa isang DevOps na pananaw. Nagsasalita lang ako mula sa puntong ito.
Ang iyong kumpanya ba ay isa sa mga nangunguna sa merkado sa digital product niche? Ang Spotify, Yandex, Uber ay mga kumpanyang nasa rurok ng pag-unlad ng teknolohiya ngayon.
Tanungin ang iyong sarili sa mga tanong na ito, at kung ang lahat ng sagot ay hindi, marahil ay hindi mo dapat gawin ang DevOps sa kumpanyang ito. Kung talagang interesante sa iyo ang paksa ng DevOps, siguro... dapat kang lumipat sa ibang kumpanya? Kung gusto ng iyong kumpanya na pumasok sa DevOps, ngunit sumagot ka ng "Hindi" sa lahat ng mga tanong, kung gayon ito ay tulad ng magagandang rhinocero na hindi magbabago.
Samahan
Gaya nga ng sabi ko, ayon sa Conway's Law, nagbabago ang organisasyon ng isang kumpanya. Magsisimula ako sa kung ano ang pumipigil sa DevOps mula sa pagtagos sa loob ng kumpanya mula sa pananaw ng organisasyon.
Ang problema ng "mga balon"
Ang salitang Ingles na "Silo" ay isinalin dito sa Russian bilang "well". Ang punto ng problemang ito ay iyon walang pagpapalitan ng impormasyon sa pagitan ng mga koponan. Ang bawat koponan ay naghuhukay ng malalim sa kanilang kadalubhasaan, nang hindi gumagawa ng isang karaniwang mapa upang mag-navigate.
Sa ilang mga paraan, ito ay nagpapaalala sa akin ng isang tao na kararating lang sa Moscow at hindi pa alam kung paano mag-navigate sa mapa ng metro. Karaniwang alam ng mga Muscovite ang kanilang lugar, at sa buong Moscow maaari silang mag-navigate gamit ang mapa ng metro. Kapag dumating ka sa Moscow sa unang pagkakataon, wala kang ganitong kasanayan, at nalilito ka lang.
Iminumungkahi ng DevOps na malampasan ang sandaling ito ng disorientasyon at ang lahat ng mga departamento ay nagtutulungan upang bumuo ng isang pangkaraniwang mapa ng pakikipag-ugnayan.
Dalawang salik ang humahadlang dito.
Bunga ng sistema ng pamamahala ng korporasyon. Ito ay itinayo sa magkahiwalay na hierarchical na "mga balon". Halimbawa, may ilang partikular na KPI sa mga kumpanyang sumusuporta sa sistemang ito. Sa kabilang banda, ang utak ng isang taong nahihirapang lumampas sa mga hangganan ng kanilang kadalubhasaan at mag-navigate sa buong sistema ay humahadlang. Ito ay hindi komportable. Isipin na ikaw ay nasa paliparan ng Bangkok - hindi mo mahahanap ang iyong paraan nang mabilis. Mahirap ding i-navigate ang DevOps, at iyon ang dahilan kung bakit sinasabi ng mga tao na kailangan mong humanap ng gabay para makarating doon.
Ngunit ang pinakamahalagang bagay ay ang problema ng "mga balon" para sa isang inhinyero na puno ng diwa ng DevOps, ay nagbasa ng Fowler at isang grupo ng iba pang mga libro, ay ipinahayag sa katotohanan na Ang "mga balon" ay hindi nagpapahintulot sa iyo na gumawa ng mga bagay na "halata".. Madalas kaming magkasama pagkatapos ng DevOps Moscow, makipag-usap sa isa't isa, at nagrereklamo ang mga tao:
β Gusto lang namin maglunsad ng CI, pero hindi naman kailangan ng management.
Nangyayari ito nang eksakto dahil CI ΠΈ Tuloy-tuloy na proseso ng Paghahatid ay nasa hangganan ng maraming pagsusulit. Nang hindi nalampasan ang problema ng "mga balon" sa antas ng organisasyon, hindi mo magagawang sumulong, anuman ang iyong gawin at gaano man ito kalungkot.
Ang bawat kalahok sa proseso sa kumpanya: mga developer ng backend at frontend, pagsubok, DBA, operasyon, network, naghuhukay sa kanilang sariling direksyon, at walang sinuman ang may karaniwang mapa maliban sa manager, na kahit papaano ay sinusubaybayan sila at namamahala sa kanila gamit ang βdivide at lupiginβ na pamamaraan.
Ang mga tao ay nakikipaglaban para sa ilang mga bituin o mga bandila, lahat ay naghuhukay ng kanilang kadalubhasaan.
Bilang isang resulta, kapag ang gawain ay lumitaw sa pagkonekta sa lahat ng ito nang sama-sama at pagbuo ng isang karaniwang pipeline, at hindi na kailangan upang labanan para sa mga bituin at mga bandila, ang tanong ay lumitaw - ano pa rin ang gagawin? Kailangan naming magkasundo kahit papaano, ngunit walang nagturo sa amin kung paano gawin ito sa paaralan. Itinuro na kami mula sa paaralan: ikawalong baitang - wow! - kumpara sa ikapitong baitang! Ganun din dito.
Pareho ba ito sa iyong kumpanya?
Upang suriin ito, maaari mong tanungin ang iyong sarili ng mga sumusunod na katanungan.
Gumagamit ba ang mga team ng mga karaniwang tool at nag-aambag sa mga pagbabago sa mga karaniwang tool na iyon?
Gaano kadalas muling nag-aayos ang mga koponanβang ilang mga espesyalista mula sa isang koponan ay lumipat sa isa pang koponan? Ito ay sa isang kapaligiran ng DevOps na ito ay nagiging normal, dahil kung minsan ang isang tao ay hindi maintindihan kung ano ang ginagawa ng isa pang larangan ng kadalubhasaan. Lumipat siya sa ibang departamento, nagtatrabaho doon ng dalawang linggo upang lumikha para sa kanyang sarili ng isang mapa ng oryentasyon at pakikipag-ugnayan sa departamentong ito.
Posible bang bumuo ng komite ng pagbabago at baguhin ang mga bagay? O nangangailangan ba ito ng malakas na kamay ng pinakamataas na pamamahala at direksyon? Isinulat ko kamakailan sa Facebook kung paano nagpapatupad ng mga tool ang isang maliit na kilalang bangko sa pamamagitan ng mga order: sumusulat kami ng isang order, ipinapatupad namin ito sa loob ng isang taon, at tingnan kung ano ang mangyayari. Ito, siyempre, ay mahaba at malungkot.
Gaano kahalaga para sa mga tagapamahala na makatanggap ng mga personal na tagumpay nang hindi isinasaalang-alang ang mga nagawa ng kumpanya?
Kung sasagutin mo ang mga tanong na ito para sa iyong sarili, magiging mas malinaw kung mayroon kang ganoong problema sa iyong kumpanya.
Imprastraktura bilang code
Matapos maipasa ang problemang ito, ang unang mahalagang kasanayan, kung wala ito ay mahirap na sumulong pa sa DevOps, ay imprastraktura bilang code.
Kadalasan, ang imprastraktura bilang code ay nakikita bilang mga sumusunod:
β I-automate natin ang lahat sa bash, takpan ang ating mga sarili ng mga script upang ang mga admin ay magkaroon ng mas kaunting manu-manong gawain!
Ngunit hindi iyon totoo.
Ang imprastraktura bilang code ay nangangahulugan na inilalarawan mo ang IT system na ginagamit mo sa anyo ng code upang patuloy na maunawaan ang estado nito.
Kasama ng iba pang mga koponan, lumikha ka ng isang mapa sa anyo ng code na mauunawaan ng lahat at maaaring mag-navigate at mag-navigate. Hindi mahalaga kung ano ang ginagawa nito - Chef, Ansible, Salt, o paggamit ng mga YAML file sa Kubernetes - walang pagkakaiba.
Sa kumperensya, sinabi ng isang kasamahan mula sa 2GIS kung paano nila ginawa ang kanilang sariling panloob na bagay para sa Kubernetes, na naglalarawan sa istruktura ng mga indibidwal na sistema. Upang ilarawan ang 500 system, kailangan nila ng hiwalay na tool na bumubuo ng paglalarawang ito. Kapag mayroong ganitong paglalarawan, lahat ay maaaring suriin sa isa't isa, subaybayan ang mga pagbabago, kung paano ito baguhin at pagbutihin, kung ano ang kulang.
Sumang-ayon, ang mga indibidwal na script ng bash ay karaniwang hindi nagbibigay ng ganitong pag-unawa. Sa isa sa mga kumpanyang pinagtatrabahuhan ko, mayroon pa ngang pangalan para sa script na "write only" - kapag nakasulat ang script, ngunit hindi na ito maaaring basahin. Sa tingin ko ito ay pamilyar din sa iyo.
Ang imprastraktura bilang code ay code na naglalarawan sa kasalukuyang kalagayan ng imprastraktura. Maraming mga pangkat ng produkto, imprastraktura, at serbisyo ang nagtutulungan sa code na ito, at higit sa lahat, kailangan nilang maunawaan kung paano talaga gumagana ang code na ito.
Ang code ay pinananatili ayon sa pinakamahusay na mga kasanayan sa code: joint development, code review, XP-programming, testing, pull requests, CI para sa code infrastructures - lahat ng ito ay angkop at magagamit.
Ang code ay nagiging isang karaniwang wika para sa lahat ng mga inhinyero.
Ang pagpapalit ng imprastraktura sa code ay hindi tumatagal ng maraming oras. Oo, ang code sa imprastraktura ay maaari ding magkaroon ng teknikal na utang. Kadalasan, nakakaharap ito ng mga koponan sa isang taon at kalahati pagkatapos nilang simulan ang pagpapatupad ng "imprastraktura bilang code" sa anyo ng isang grupo ng mga script o kahit na Ansible, na sinusulat nila tulad ng spaghetti code, at itinapon din nila ang mga script ng bash sa halo!
Mahalagang: Kung hindi mo pa nasusubukan ang bagay na ito, tandaan iyan Ang Ansible ay hindi bash! Basahing mabuti ang dokumentasyon, pag-aralan kung ano ang isinulat nila tungkol dito.
Ang imprastraktura bilang code ay ang paghihiwalay ng code ng imprastraktura sa magkahiwalay na mga layer.
Sa aming kumpanya, nakikilala namin ang 3 pangunahing mga layer, na napakalinaw at simple, ngunit maaaring may higit pa sa mga ito. Maaari mong tingnan ang iyong code sa imprastraktura at sabihin kung mayroon kang ganitong kondisyon o wala. Kung walang mga layer na naka-highlight, pagkatapos ay kailangan mong tumagal ng ilang oras at refactor ng kaunti.
base layer - ito ay kung paano na-configure ang OS, mga backup at iba pang mga bagay na mababa ang antas, halimbawa, kung paano na-deploy ang Kubernetes sa pangunahing antas.
Antas ng serbisyo - ito ang mga serbisyong ibinibigay mo sa developer: pag-log bilang isang serbisyo, pagsubaybay bilang isang serbisyo, database bilang isang serbisyo, balancer bilang isang serbisyo, pila bilang isang serbisyo, Patuloy na Paghahatid bilang isang serbisyo - isang grupo ng mga serbisyo na ang mga indibidwal na koponan maaaring magbigay sa pag-unlad. Ang lahat ng ito ay kailangang ilarawan sa magkahiwalay na mga module sa iyong configuration management system.
Ang layer kung saan ginawa ang mga application at inilalarawan kung paano sila magbubukas sa ibabaw ng nakaraang dalawang layer.
Kontrolin ang mga tanong
Ang iyong kumpanya ba ay may isang karaniwang imbakan ng imprastraktura? Pinamamahalaan mo ba ang teknikal na utang sa iyong imprastraktura? Gumagamit ka ba ng mga kasanayan sa pag-unlad sa isang imbakan ng imprastraktura? Ang iyong imprastraktura ay hiniwa sa mga layer? Maaari mong tingnan ang Base-service-APP diagram. Gaano kahirap gumawa ng pagbabago?
Kung naranasan mo na na tumagal ng isang araw at kalahati upang gumawa ng mga pagbabago, nangangahulugan ito na mayroon kang teknikal na utang at kailangan mong pagtrabahuhan ito. Natisod ka lang sa isang technical debt rake sa iyong infrastructure code. Naaalala ko ang maraming ganoong mga kuwento nang, upang mabago ang ilang CCTL, kailangan mong muling isulat ang kalahati ng code ng imprastraktura, dahil ang pagkamalikhain at ang pagnanais na i-automate ang lahat ay humantong sa katotohanan na ang lahat ay nabubulok sa lahat ng dako, ang lahat ng mga hawakan ay tinanggal, at ito ay kinakailangan upang refactor.
Tuloy-tuloy na Paghahatid
Ihambing natin ang debit sa kredito. Una ay ang isang paglalarawan ng imprastraktura, na maaaring medyo basic. Hindi mo kailangang ilarawan ang lahat nang detalyado, ngunit kailangan ang ilang pangunahing paglalarawan upang magawa mo ito. Kung hindi, hindi malinaw kung ano ang gagawin sa susunod na paghahatid. Ang lahat ng kasanayang ito ay sabay-sabay na nagbubukas kapag dumating ka sa DevOps, ngunit nagsisimula ito sa pag-unawa kung ano ang mayroon ka at kung paano ito pamahalaan. Ito ay tiyak na pagsasanay ng imprastraktura bilang code.
Sa sandaling maging malinaw na mayroon ka nito at kung paano pamahalaan ito, sisimulan mong malaman kung paano ipadala ang code ng developer sa produksyon sa lalong madaling panahon. Ibig kong sabihin kasama ang developer - naaalala namin ang tungkol sa problema ng "mga balon", iyon ay, hindi mga indibidwal na tao ang nakabuo nito, ngunit isang koponan.
Pag kasama namin Vanya Evtukhovich nakita ang unang libro Jez Humble at mga pangkat ng mga may-akda "Patuloy na Paghahatid", na inilabas noong 2009, matagal naming pinag-isipan kung paano isalin ang pamagat nito sa Russian. Nais nilang isalin ito bilang "Patuloy na paghahatid", ngunit, sa kasamaang-palad, ito ay isinalin bilang "Patuloy na paghahatid". Tila sa akin ay mayroong isang bagay na Ruso sa aming pangalan, na may presyon.
Patuloy na paghahatid ng paraan
Ang code na nasa imbakan ng produkto ay palaging mada-download sa produksyon. Maaaring hindi siya nababalisa, ngunit lagi siyang handa para dito. Alinsunod dito, palagi kang nagsusulat ng code na may mahirap na ipaliwanag na pakiramdam ng ilang pagkabalisa sa ilalim ng iyong tailbone. Madalas itong lumalabas kapag inilunsad mo ang code ng imprastraktura. Ang pakiramdam na ito ng ilang pagkabalisa ay dapat na naroroon - pinalitaw nito ang mga proseso ng utak na nagbibigay-daan sa iyo na magsulat ng code nang medyo naiiba. Dapat itong maitala sa mga patakaran sa loob ng pag-unlad.
Para tuloy-tuloy na makapaghatid, kailangan mo ng artifact na format na tumatakbo sa isang platform ng imprastraktura. Kung magtapon ka ng "basura sa buhay" ng iba't ibang mga format sa isang platform ng imprastraktura, pagkatapos ito ay magiging pinag-isa, mahirap mapanatili, at lumitaw ang problema ng teknikal na utang. Kailangang ihanay ang format ng artifact - isa rin itong kolektibong gawain: kailangan nating lahat na magsama-sama, kumaluskos ang ating mga utak at makabuo ng ganitong format.
Ang artifact ay patuloy na pinahusay at nagbabago upang umangkop sa kapaligiran ng produksyon habang ito ay gumagalaw sa pipeline ng paghahatid. Kapag gumagalaw ang isang artifact sa pipeline, palagi itong nakakatagpo ng ilang hindi maginhawang bagay para dito, na katulad ng kung ano ang nakatagpo ng artifact na inilagay mo sa produksyon. Kung sa klasikal na pag-unlad ito ay ginagawa ng isang tagapangasiwa ng system na gumagawa ng rollout, pagkatapos ay sa proseso ng DevOps nangyayari ito sa lahat ng oras: dito sinubukan nila ito sa ilang mga pagsubok, dito nila itinapon ito sa isang Kubernetes cluster, na higit pa o hindi gaanong katulad sa produksyon, pagkatapos ay biglang nagsimula silang mag-load ng pagsubok.
Ito ay medyo nakapagpapaalaala sa larong Pac-Man - ang artifact ay dumaan sa ilang uri ng kuwento. Kasabay nito, mahalagang kontrolin kung ang code ay talagang dumadaan sa kuwento at kung ito ay kahit papaano ay nauugnay sa iyong produksyon. Ang mga kwento mula sa produksyon ay maaaring i-drag sa proseso ng Continuous Delivery: ganito kapag may nahulog, ngayon ay i-program na lang natin ang scenario na ito sa loob ng system. Sa bawat oras na dadaan din ang code sa sitwasyong ito, at hindi mo na makakaharap ang problemang ito sa susunod. Malalaman mo ang tungkol dito nang mas maaga kaysa maabot nito ang iyong kliyente.
Iba't ibang mga diskarte sa pag-deploy. Halimbawa, gumagamit ka ng AB testing o mga deployment ng canary upang subukan ang code sa iba't ibang mga kliyente, kumuha ng impormasyon tungkol sa kung paano gumagana ang code, at mas maaga kaysa noong inilunsad ito sa 100 milyong user.
"Patuloy na maghatid" ganito ang hitsura.
Ang proseso ng paghahatid ng Dev, CI, Test, PreProd, Prod ay hindi isang hiwalay na kapaligiran, ito ay mga yugto o istasyon na may hindi masusunog na kabuuan kung saan dumadaan ang iyong artifact.
Kung mayroon kang code sa imprastraktura na inilalarawan bilang Base Service APP, nakakatulong ito huwag kalimutan ang lahat ng mga script, at isulat ang mga ito bilang code para sa artifact na ito, isulong ang artifact at baguhin ito habang ikaw ay pupunta.
Mga tanong sa pagsusulit sa sarili
Ang oras mula sa paglalarawan ng tampok hanggang sa paglabas sa produksyon sa 95% ng mga kaso ay wala pang isang linggo? Gumaganda ba ang kalidad ng artifact sa bawat yugto ng pipeline? May kwento ba na pinagdadaanan? Gumagamit ka ba ng iba't ibang mga diskarte sa pag-deploy?
Kung ang lahat ng mga sagot ay oo, kung gayon ikaw ay hindi kapani-paniwalang cool! Isulat ang iyong mga sagot sa mga komento - matutuwa ako).
feedback
Ito ang pinakamahirap na kasanayan sa lahat. Sa kumperensya ng DevOpsConf, isang kasamahan mula sa Infobip, na nagsasalita tungkol dito, ay medyo nalilito sa kanyang mga salita, dahil ito ay talagang isang napaka-komplikadong kasanayan tungkol sa katotohanan na kailangan mong subaybayan ang lahat!
Halimbawa, matagal na ang nakalipas, noong nagtrabaho ako sa Qik at napagtanto namin na kailangan naming subaybayan ang lahat. Ginawa namin ito, at mayroon na kaming 150 item sa Zabbix, na patuloy na sinusubaybayan. Ito ay nakakatakot, ang teknikal na direktor ay pinilipit ang kanyang daliri sa kanyang templo:
- Guys, bakit mo ginagahasa ang server na may hindi malinaw?
Ngunit pagkatapos ay naganap ang isang insidente na nagpakita na ito ay talagang isang napaka-cool na diskarte.
Ang isa sa mga serbisyo ay nagsimulang mag-crash palagi. Sa una, hindi ito nag-crash, na kung saan ay kawili-wili, ang code ay hindi idinagdag doon, dahil ito ay isang pangunahing broker, na halos walang pag-andar sa negosyo - nagpadala lamang ito ng mga mensahe sa pagitan ng mga indibidwal na serbisyo. Hindi nagbago ang serbisyo sa loob ng 4 na buwan, at bigla itong nagsimulang mag-crash na may error na "Segmentation fault".
Nagulat kami, binuksan ang aming mga chart sa Zabbix, at lumabas na isang linggo at kalahati na ang nakalipas, ang pag-uugali ng mga kahilingan sa serbisyo ng API na ginagamit ng broker na ito ay nagbago nang malaki. Susunod na nakita namin na ang dalas ng pagpapadala ng isang partikular na uri ng mensahe ay nagbago. Nang maglaon, nalaman namin na ang mga ito ay mga kliyente ng android. Tinanong namin:
β Guys, ano ang nangyari sa inyo isang linggo at kalahati na ang nakalipas?
Bilang tugon, narinig namin ang isang kawili-wiling kuwento tungkol sa kung paano nila muling idisenyo ang UI. Malamang na hindi kaagad sasabihin ng sinuman na binago nila ang HTTP library. Para sa mga kliyente ng Android, parang pagpapalit ng sabon sa banyo - hindi lang nila maalala. Bilang resulta, pagkatapos ng 40 minutong pag-uusap, nalaman namin na binago nila ang HTTP library, at ang mga default na timing nito ay nagbago. Nagdulot ito ng pagbabago sa gawi ng trapiko sa server ng API, na humantong sa isang sitwasyon na nagdulot ng karera sa loob ng broker, at nagsimula itong bumagsak.
Kung walang malalim na pagsubaybay sa pangkalahatan ay imposibleng buksan ito. Kung ang organisasyon ay mayroon pa ring problema ng "mga balon", kapag ang lahat ay nagtatapon ng pera sa isa't isa, maaari itong mabuhay nang maraming taon. I-restart mo lang ang server dahil imposibleng malutas ang problema. Kapag sinusubaybayan mo, sinusubaybayan, sinusubaybayan ang lahat ng mga kaganapan na mayroon ka, at ginamit ang pagsubaybay bilang pagsubok - sumulat ng code at agad na ipahiwatig kung paano ito susubaybayan, pati na rin sa anyo ng code (mayroon na kaming imprastraktura bilang code), ang lahat ay nagiging malinaw kung paano sa palad. Kahit na ang mga kumplikadong problema ay madaling masubaybayan.
Kolektahin ang lahat ng impormasyon tungkol sa kung ano ang mangyayari sa artifact sa bawat yugto ng proseso ng paghahatid - hindi sa produksyon.
I-upload ang pagsubaybay sa CI, at ang ilang mga pangunahing bagay ay makikita na doon. Mamaya makikita mo sila sa Test, PredProd, at load testing. Kolektahin ang impormasyon sa lahat ng mga yugto, hindi lamang mga sukatan, istatistika, kundi pati na rin ang mga tala: kung paano inilunsad ang application, mga anomalya - kolektahin ang lahat.
Kung hindi, ito ay magiging mahirap na malaman ito. Nasabi ko na na mas kumplikado ang DevOps. Upang makayanan ang kumplikadong ito, kailangan mong magkaroon ng normal na analytics.
Mga tanong para sa pagpipigil sa sarili
Ang iyong pagsubaybay at pag-log ay ang tool sa pag-unlad para sa iyo? Kapag nagsusulat ng code, iniisip ba ng iyong mga developer, kasama ka, kung paano ito susubaybayan?
Naririnig mo ba ang tungkol sa mga problema mula sa mga customer? Mas naiintindihan mo ba ang kliyente mula sa pagsubaybay at pag-log? Mas naiintindihan mo ba ang system mula sa pagsubaybay at pag-log? Binago mo ba ang system dahil lang sa nakita mong lumalaki ang trend sa system at naiintindihan mo na sa susunod na 3 linggo ay mamamatay ang lahat?
Kapag mayroon ka ng tatlong sangkap na ito, maaari mong isipin kung anong uri ng platform ng imprastraktura ang mayroon ka sa iyong kumpanya.
Platform ng imprastraktura
Ang punto ay hindi na ito ay isang set ng magkakaibang mga tool na mayroon ang bawat kumpanya.
Ang punto ng isang platform ng imprastraktura ay ang lahat ng mga koponan ay gumagamit ng mga tool na ito at bumuo ng mga ito nang sama-sama.
Malinaw na mayroong magkakahiwalay na mga koponan na responsable para sa pagbuo ng mga indibidwal na piraso ng platform ng imprastraktura. Ngunit sa parehong oras, ang bawat inhinyero ay may pananagutan para sa pagpapaunlad, pagganap, at pagsulong ng platform ng imprastraktura. Sa isang panloob na antas ito ay nagiging isang karaniwang tool.
Binubuo ng lahat ng mga koponan ang platform ng imprastraktura at ituring ito nang may pag-iingat bilang kanilang sariling IDE. Sa iyong IDE nag-i-install ka ng iba't ibang mga plugin upang gawing maganda at mabilis ang lahat, at i-configure ang mga hotkey. Kapag binuksan mo ang Sublime, Atom o Visual Studio Code, bumubuhos ang mga error sa code at napagtanto mo na imposibleng gumana, agad kang nalulungkot at tumakbo ka para ayusin ang iyong IDE.
Tratuhin ang iyong platform ng imprastraktura sa parehong paraan. Kung naiintindihan mo na may mali dito, mag-iwan ng kahilingan kung hindi mo ito maayos. Kung mayroong isang bagay na simple, i-edit ito sa iyong sarili, magpadala ng pull request, isasaalang-alang ito ng mga lalaki at idagdag ito. Ito ay isang bahagyang naiibang diskarte sa mga tool sa engineering sa ulo ng developer.
Tinitiyak ng platform ng imprastraktura ang paglipat ng artifact mula sa pag-unlad patungo sa kliyente na may patuloy na pagpapabuti sa kalidad. Ang IP ay naka-program sa isang hanay ng mga kuwento na nangyayari sa code sa produksyon. Sa paglipas ng mga taon ng pag-unlad, maraming mga kuwentong ito, ang ilan sa mga ito ay natatangi at nauugnay lamang sa iyo - hindi maaaring i-Google.
Sa puntong ito, ang platform ng imprastraktura ay nagiging iyong competitive advantage, dahil mayroon itong nakapaloob dito na wala sa tool ng kakumpitensya. Kung mas malalim ang iyong IP, mas malaki ang iyong competitive advantage sa mga tuntunin ng Time-to-market. Lumilitaw dito problema sa lock ng vendor: Maaari kang kumuha ng platform ng ibang tao, ngunit gamit ang karanasan ng ibang tao, hindi mo mauunawaan kung gaano ito kaugnay sa iyo. Oo, hindi lahat ng kumpanya ay maaaring bumuo ng isang platform tulad ng Amazon. Ito ay isang mahirap na linya kung saan ang karanasan ng kumpanya ay nauugnay sa posisyon nito sa merkado, at hindi ka maaaring gumamit ng lock ng vendor doon. Mahalaga rin itong pag-isipan.
Ang pamamaraan
Ito ay isang pangunahing diagram ng isang platform ng imprastraktura na makakatulong sa iyong i-set up ang lahat ng mga kasanayan at proseso sa isang kumpanya ng DevOps.
Tingnan natin kung ano ang binubuo nito.
Sistema ng orkestrasyon ng mapagkukunan, na nagbibigay ng CPU, memorya, disk sa mga application at iba pang serbisyo. Higit pa rito- mababang antas ng mga serbisyo: pagsubaybay, pag-log, CI/CD Engine, imbakan ng artifact, imprastraktura bilang code ng system.
Mas mataas na antas ng mga serbisyo: database bilang serbisyo, pila bilang serbisyo, Load Balance bilang serbisyo, pagbabago ng laki ng imahe bilang serbisyo, Big Data factory bilang serbisyo. Higit pa rito- pipeline na naghahatid ng patuloy na binagong code sa iyong kliyente.
Makakatanggap ka ng impormasyon tungkol sa kung paano gumagana ang iyong software para sa kliyente, palitan ito, ibigay muli ang code na ito, tumanggap ng impormasyon - at sa gayon ay patuloy mong binubuo ang platform ng imprastraktura at ang iyong software.
Sa diagram, ang pipeline ng paghahatid ay binubuo ng maraming yugto. Ngunit ito ay isang schematic diagram na ibinigay bilang isang halimbawa - hindi na kailangang ulitin ito nang paisa-isa. Ang mga yugto ay nakikipag-ugnayan sa mga serbisyo na parang mga serbisyoβbawat brick ng platform ay may sariling kwento: kung paano inilalaan ang mga mapagkukunan, kung paano inilunsad ang application, gumagana sa mga mapagkukunan, sinusubaybayan, at nagbabago.
Mahalagang maunawaan na ang bawat bahagi ng platform ay may dalang kuwento, at tanungin ang iyong sarili kung anong kuwento ang dinadala ng ladrilyo na ito, marahil ay dapat itong itapon at palitan ng serbisyo ng third-party. Halimbawa, posible bang mag-install ng Okmeter sa halip na isang ladrilyo? Marahil ang mga lalaki ay nakabuo na ng kadalubhasaan na ito nang higit pa kaysa sa mayroon tayo. Ngunit maaaring hindi - marahil mayroon kaming natatanging kadalubhasaan, kailangan naming i-install ang Prometheus at paunlarin pa ito.
Paglikha ng plataporma
Ito ay isang kumplikadong proseso ng komunikasyon. Kapag mayroon kang mga pangunahing kasanayan, sisimulan mo ang komunikasyon sa pagitan ng iba't ibang mga inhinyero at mga espesyalista na bumuo ng mga kinakailangan at pamantayan, at patuloy na binabago ang mga ito sa iba't ibang mga tool at diskarte. Ang kultura na mayroon tayo sa DevOps ay mahalaga dito.
Sa kultura ang lahat ay napakasimple - ito ay tungkol sa pakikipagtulungan at komunikasyon, iyon ay, ang pagnanais na magtrabaho sa isang karaniwang larangan sa isa't isa, ang pagnanais na hawakan ang isang instrumento nang magkasama. Walang rocket science dito - ang lahat ay napaka-simple, karaniwan. Halimbawa, lahat tayo ay nakatira sa pasukan at pinananatili itong malinis - tulad ng isang antas ng kultura.
Anong meron ka?
Muli, mga tanong na maaari mong itanong sa iyong sarili.
Nakatuon ba ang platform ng imprastraktura? Sino ang may pananagutan sa pag-unlad nito? Naiintindihan mo ba ang mapagkumpitensyang bentahe ng iyong platform sa imprastraktura?
Kailangan mong patuloy na tanungin ang iyong sarili sa mga tanong na ito. Kung ang isang bagay ay maaaring ilipat sa mga serbisyo ng third-party, dapat itong ilipat; kung ang isang third-party na serbisyo ay nagsimulang harangan ang iyong paggalaw, pagkatapos ay kailangan mong bumuo ng isang sistema sa loob ng iyong sarili.
Kaya, DevOps...
... ito ay isang kumplikadong sistema, dapat itong magkaroon ng:
- Digital na produkto.
- Mga module ng negosyo na bumuo ng digital na produktong ito.
- Mga pangkat ng produkto na nagsusulat ng code.
- Patuloy na Paghahatid ng mga kasanayan.
- Mga platform bilang isang serbisyo.
- Imprastraktura bilang isang serbisyo.
- Imprastraktura bilang code.
- Paghiwalayin ang mga kasanayan para sa pagpapanatili ng pagiging maaasahan, na binuo sa DevOps.
- Isang kasanayan sa feedback na naglalarawan sa lahat ng ito.
Magagamit mo ang diagram na ito, na itinatampok dito kung ano ang mayroon ka na sa iyong kumpanya sa ilang anyo: binuo ba ito o kailangan pa ring i-develop.
Matatapos ito sa loob ng ilang linggo . bilang bahagi ng RIT++. Halika sa kumperensya, kung saan makakahanap ka ng maraming magagandang ulat tungkol sa tuluy-tuloy na paghahatid, imprastraktura bilang code at pagbabago ng DevOps. , ang huling deadline ng presyo ay sa Mayo 20
Pinagmulan: www.habr.com