Ang ikatlong kumperensya ay ginanap noong Disyembre 7 , na inayos ng komunidad ng Moscow DevOps sa suporta ng Mail.ru Cloud Solutions. Bilang karagdagan sa mga presentasyon ng mga nangungunang DevOps practitioner, ang mga kalahok ay maaaring dumalo sa maiikling nakakaganyak na Lightning Talks, workshop at makipag-usap sa mga bukas na espasyo.
Nangolekta kami ng mahahalagang insight mula sa anim na talumpati at nagsagawa ng mga panayam sa ilang tagapagsalita upang malaman kung ano ang naiwan sa mga ulat.
Sa loob:
- Baruch Sadogursky, JFrog: "Hayaan ang software na dumaloy mula sa vendor patungo sa user tulad ng likido"
- Pavel Selivanov, Southbridge: "Ang Dev at Ops ay may isang karaniwang gawain - upang gumawa ng isang produkto na gumagana"
- Vladimir Utratenko, X5 Retail Group: "Ang DevOps sa Enterprise ay pag-unlad nang walang sakit at sunog"
- Sergey Puzyrev, Facebook: "Ang Production Engineer ay nagmamalasakit sa serbisyo sa kabuuan: upang ang parehong mga user at developer ay magkaroon ng magandang oras"
- Mikhail Chinkov, AMBOSS: "Hindi maaaring sundin ng isang departamento ang landas ng DevOps, dapat itong sundin ng buong kumpanya"
- Mga mahilig sa DevOps ng Rosbank: "1000 araw para ipatupad ang DevOps sa isang madugong negosyo"
1. Baruch Sadogursky, JFrog: "Hayaan ang software na dumaloy mula sa vendor patungo sa user na parang likido"
Ang mga pagkabigo sa pag-update ng software ay nangyayari bawat oras at para sa lahat. Narito ang isang nakakatakot na kuwento mula sa talumpati: Nawala ang Knight Capital ng $440 milyon sa isang oras pagkatapos ng hindi matagumpay na pag-update.
Nagsalita si Baruch tungkol sa mga pattern ng DevOps ng tuluy-tuloy na pag-update na makakatulong na maiwasan ang mga pagkabigo at pagkamuhi ng user:
Lokal na rollback — panatilihin ang nakaraang bersyon ng software sa iyong device upang maibalik kung may mangyari. Poprotektahan ka nito kung ang mga bagay ay lumala nang hindi ka makakapagpadala ng patch sa ere.
Over the air updates - mas mahusay na tuloy-tuloy. Kung hindi, ito ay magiging katulad ng mga nag-develop ng Jaguar: dahil sa isang bug sa sistema ng preno, na hindi ma-update sa hangin, ang mga kotse ay kailangang ma-recall mula sa pagbebenta. Ito ay masakit at mahal.
Patuloy na pag-update — patuloy na i-update ang software sa sandaling handa na ang isang bagong feature. Sa mga bihirang update, ang mga feature ay pinagsama-samang maaaring maghintay para sa mga hindi kritikal. Tulad ng sa Tesla, isang update na dapat ayusin ang random na pagpepreno ay naghihintay para sa isang update sa laro ng chess.
Awtomatikong pag-deploy - palitan ang mga tao ng mga makina, dahil ang mga tao ay hindi maganda sa pagsasagawa ng mga nakagawiang aksyon.
Madalas na pag-update - tulungan kang bumuo ng isang ugali at mapupuksa ang takot. Ang mga bihirang update ay nagiging mga emergency na kaganapan.
Pag-alam sa estado ng device — pagsubok ng mga update, hindi pag-install mula sa simula. Mahalaga ito dahil maaaring magkaiba ang pagkilos ng mga update depende sa estado ng device.
Inilabas ang Canary — ilunsad ang mga update sa isang maliit na bilang ng mga user at obserbahan. Binabawasan nito ang pinsala kung may mali.
Mga update nang walang hindi magagamit — hayaan ang mga customer na mapansin lamang ang mga bagong feature, at hindi maiiwan na walang serbisyo sa loob ng ilang linggo habang naglulunsad ka ng update.
Nakipag-usap kami kay Baruch Sadogursky tungkol sa kung paano naiiba ang view sa DevOps sa Russian at Western IT, kung gagawin ng Cloud ang lahat para sa amin sa lalong madaling panahon at kung ang lahat ng mga serbisyo ng software ay pupunta sa scheme ng aaS - panoorin ang panayam:
2. Pavel Selivanov, Southbridge: "Ang Dev at Ops ay may isang karaniwang gawain - upang gumawa ng isang produkto na gumagana"
Ang pagpapatupad ng Kubernetes ay hindi makakatulong na makamit ang DevOps, at sa kabaligtaran, maaari nitong sirain ang lahat. Ipinaliwanag ni Pavel kung bakit hindi malulutas ng teknolohiya (kahit na ang pinakaastig) ang lahat ng iyong problema:
Ang pagiging kumplikado ng proyekto ay lumampas sa code. Noong nakaraan, mayroong isang kumplikadong aplikasyon: pakikipag-ugnayan sa loob ng proyekto at kumplikadong pag-unlad, ngunit isang simpleng istraktura - na-deploy ito ng administrator, gumagana ang lahat. Lumipat kami sa mga microservice: ang bawat serbisyo ay isang simpleng aplikasyon, komunikasyon gamit ang mga karaniwang protocol at mabilis na pag-unlad, ngunit ang istraktura ng proyekto ay naging mas kumplikado. Ang pagiging kumplikado ng isang proyekto na may arkitektura ng microservice ay hindi nawala - ito ay lumipat nang higit sa code. Ngayon ang inhinyero ng DevOps ay responsable para dito.
Hindi gusto ng mga developer ang mga pagbabago pagkatapos ipatupad ang DevOps. Bilang resulta, ang daloy ng trabaho kasama ang Kubernetes ay patuloy na nagmumukhang paghagis ng mga gawain mula sa Dev patungo sa Ops sa ibabaw ng isang pader, ngunit hindi lamang isang metaporikal - ang Git ay naging isang pader. Inilalagay ng developer ang code doon at gumagana tulad ng dati, at ang mga admin ay mayroong Kubernetes, CI/CD at lahat ng iba pa.
Gayunpaman, kailangang tanggapin ng mga developer ang mga pagbabago. Ang sitwasyon kung kailan hindi alam ng mga developer kung ano ang ginagawa ng mga admin, at hindi alam ng mga admin kung ano ang nangyayari sa mga developer, ay lumilikha ng mga problema.
Kung walang nagbago para sa mga developer, hindi nila napagtanto na ang pagpapatakbo ng application ay kanilang responsibilidad - ang iba't ibang mga teknikal na trick ay hindi gagana.
Sa pagdating ng DevOps at Kubernetes, maraming magbabago sa pag-unlad. Dapat na may kakayahan ang mga dev sa Ops at vice versa. Ang mga espesyalistang ito ay may sariling mga partikular na kasanayan, ngunit dapat silang magkaroon ng kamalayan sa gawain ng bawat isa. Kailangang maging magkaibigan sina Dev at Ops bago ipatupad ang Kubernetes, kung hindi, masisira mo kung ano ang mayroon ka.
Nagsalita si Pavel Selivanov tungkol sa kung ano ang mangyayari sa Kubernetes sa loob ng 5 taon at kung ano ang dapat gawin ng isang modernong startup ng isang stack ng teknolohiya - panoorin ang panayam:
3. Vladimir Utratenko, X5 Retail Group: "Ang DevOps sa Enterprise ay pag-unlad nang walang sakit at apoy"
Dumarating ang mga kumpanya sa pagbabagong-anyo ng DevOps kapag napagtanto nila na ang pag-unlad ay masyadong mabagal at hindi nakakatugon sa mga katotohanan, mayroon silang pagnanais na umunlad nang mas mahusay at ilunsad nang mas mabilis.
Ipinaliwanag ni Vladimir kung paano ito nangyayari at kung ano ang huli:
- Una, kumukuha ang mga kumpanya ng isang engineer ng DevOps. Ito ay isang Senior System Administrator, siya ay kasangkot sa pag-deploy ng release sa produksyon, pag-standardize ng development environment, pag-set up ng imprastraktura, pag-detect at pag-aayos ng iba't ibang problema, pag-automate ng mga proseso at iba pang teknikal na gawain.
- Pagkatapos ay hindi na sapat ang isang engineer ng DevOps, at kumukuha ang kumpanya ng isang koponan ng DevOps. Ito ay isang competence center na nag-oorganisa ng mga pagsisikap ng magkakaibang mga inhinyero at nagbibigay-daan sa kanila na magkonsentrar sa isang direksyon.
- Sa katunayan, ang mga DevOps engineer at DevOps team ay mga anti-pattern ng DevOps transformation. Dahil ang DevOps ay tungkol sa mga kasanayan at kultura, bilang karagdagan, may mga pagpapatupad ng DevOps sa mga kumpanya ng teknolohiya (SRE, Production Engineering).
Anong gagawin? Mag-hire ng pansamantalang DevOps team na tutulong sa pagpapatupad ng pagbabago sa DevOps, magsagawa ng mga kasanayan, maglinang ng kultura ng pag-unlad at kulturang teknolohikal.
Kapag nagsimula ang isang negosyo at namuhunan sa DevOps, maraming mga sitwasyon ang posible: lahat ay babagsak sa pag-alis; mananatili bilang SRE/Production Engineering o Embedded Ops; lilipat sa BizOps, kapag ang mga proseso ay nakabatay sa mga sukatan ng negosyo.
Sinabi sa amin ni Vladimir Utratenko ang tungkol sa kung gaano talaga ka "dugo" ang mga DevOps sa isang negosyo at kung paano ipinapatupad ang mga kasanayan sa malaking retail - panoorin ang panayam:
4. Sergey Puzyrev, Facebook: "Ang Production Engineer ay nagmamalasakit sa serbisyo sa kabuuan: upang ang parehong mga user at developer ay magkaroon ng magandang oras"
Ang Facebook ay isang malaking kumpanya, na may malaking bilang ng mga bahagi, server, tao, at data center. Sa kabila ng napakalaking sukat nito, napakabilis nito - maaaring ilunsad ng mga developer ang mga serbisyo nang maraming beses sa isang araw. Gayundin, mabilis na lumalaki ang Facebook, at hindi lang ang bilang ng mga user at server ang dumarami, ang bilang ng mga developer ay dumarami rin, na ginagawang mas kumplikado ang mga proseso.
Sinabi ni Sergey kung ano ang ginagawa ng isang Production Engineer sa Facebook:
- Ang isang Production Engineer ay maraming code, dapat siyang may kaalaman sa system: mga operating system, file system, database, network at iba pa. Kailangang may karanasan sa pagtatrabaho sa mga distributed system at Reliability Engineering, iyon ay, pagsuporta sa pagiging maaasahan ng produkto. Dapat itong on-call, ibig sabihin, available para sa pagtawag anumang oras.
- Ang Production Engineer ay naiiba sa Software Engineer sa pagkakaroon ng mga advanced na kasanayan sa pagpapatakbo, ngunit, sa katunayan, ay isang subspecies ng Software Engineer. Ang mga Software Engineer ay nag-code nang higit pa; Sa Facebook, ang mga naturang espesyalista ay dapat ding on-call, na dumating bilang isang hindi kasiya-siyang sorpresa para sa marami.
- Ang pyramid ng mga pangangailangan ng isang Production Engineer sa isang kumpanya ay nagsisimula sa pagsubaybay sa mga server at sa kanilang ikot ng buhay, iyon ay, pagkuha ng bagong hardware, pag-set up nito, paglalagay nito sa operasyon. Ang susunod na antas ay pareho sa antas ng serbisyo: pagsubaybay sa mga serbisyo at kanilang ikot ng buhay. Pagkatapos ay darating ang tuluy-tuloy na pag-scale at advanced na pagsubaybay. Lumipat sila sa autoscaling pagkatapos na awtomatiko ang ikot ng buhay ng serbisyo. At sa huli, kailangang mag-tune para maging epektibo ang scaling at makatipid ng pera at resources ang kumpanya.
5. Mikhail Chinkov, AMBOSS: "Hindi maaaring sundin ng isang departamento ang landas ng DevOps, dapat itong sundin ng buong kumpanya"
Naniniwala si Mikhail na ang DevOps ay patuloy na pag-unlad. Hindi ka maaaring magpakilala ng ilang mga tool at huminto doon. Anong mga problema ang pumipigil sa mga kumpanya na maging DevOps at kung paano ipatupad ang mga kasanayan?
Pagkakaiba sa Pag-unawa sa DevOps. Ang mga canonical devops, gaya ng nakikita ng mga ebanghelista, ay nakasalalay sa 5 haligi:
- kultura - tumuon sa mga tao at pakikipagtulungan;
- automation - pagtatalaga ng gawain sa daloy ng trabaho;
- lean - diin sa paghahatid ng halaga sa gumagamit;
- pagbabahagi - patuloy na pagpapalitan ng kaalaman;
- mga sukatan at pagtanggap ng feedback gamit ang mga ito.
Karaniwang nakatuon lamang ang mga kumpanya sa automation at paghahatid ng halaga sa user. Ngunit ang kultura, pagbabahagi ng kaalaman, at mga sukatan ng DevOps upang subaybayan ang pag-unlad ay nawawala sa background.
Mga Hamon sa Standardization ng DevOps. Ang mga layunin ng produkto ay iba para sa lahat ng kumpanya at hindi maaaring i-standardize. Ang estado ng DevOps sa isang kumpanya ay nakasalalay sa kumpanya mismo, ngunit marami ang hindi naiintindihan ito at naniniwala na sapat na ang pag-hire ng isang DevOps engineer.
Bakit hindi pa tayo DevOps? Mayroong dalawang pangunahing problema. Sa Enterprise mayroong isang mabagal na pag-unlad ng organisasyon, mga kahirapan sa pagbabago ng vector sa isipan ng libu-libong empleyado. Sa mga startup, may kakulangan ng mga mapagkukunan ng kaalaman at isang problema sa paglalaan ng mga mapagkukunan para sa pagbabago.
Mga yugto ng pagbuo ng DevOps sa isang kumpanya:
- ang una ay imprastraktura sa cloud, ngunit walang nakakaalam kung paano ito gumagana maliban sa isa o dalawang admin;
- pangalawa, ang imprastraktura ay transparent at naiintindihan ng lahat ng mga inhinyero, ngunit ang mga proseso ay hindi naka-streamline;
- pangatlo - ang mga inhinyero ay nakapag-iisa na naglulunsad at nagkukumpuni ng mga live na serbisyo;
- pang-apat - opsyonal na mag-aambag ang mga inhinyero sa pangunahing imprastraktura, transparent na code sa cloud, deployment sa pamamagitan ng button.
Ang perpektong pamamaraan ay ang lahat ay may parehong access sa imprastraktura, lahat ng mga inhinyero ay may access sa produkto at nauunawaan kung ano ang kanilang ginagawa.
Sa pagsasara ng lahat ng kultural at teknikal na mga gestalt, ang pagbabagong DevOps ng kumpanya ay isasaalang-alang ang feedback mula sa mga sukatan ng negosyo at platform.
6. Mga mahilig sa DevOps ng Rosbank: "1000 araw para ipatupad ang DevOps sa isang madugong negosyo"
Sinabi nina Yuri Bulich, Dina Maltseva, Evgeny Pankov mula sa Rosbank kung paano sila napunta sa DevOps sa loob ng tatlong taon. Mayroong dalawang layunin: upang malutas ang mga partikular na problema sa mga partikular na koponan at ipatupad ang mga sentralisadong tool.
Narito ang mga resultang nakamit:
Mga Resulta para sa Mga Koponan ng Produkto: 30 beses na mas mabilis na pagpupulong, 6 na beses na mas mabilis na pag-install, hanggang sa 30% na matitipid sa buong cycle. Mayroon na kaming kakayahang pindutin ang isang pindutan upang pumunta sa pagiging produktibo
Mga resulta para sa mga utos ng platform: 10 beses na mas mabilis na pagpupulong at pag-install, 87% tumaas na bilang ng mga pag-install, 46% autotest coverage. Hindi na bottleneck ang integration team
Kaya, paano ipatupad ang mga kasanayan sa DevOps sa isang madugong negosyo?
Magpatupad muna ng pilot project: Pumili ng mga koponan, magpasya kung paano ipatupad ang arkitektura, at pumili ng mga tool. Pinili namin ang mga tool na may bukas na lisensya, na may pag-install sa bangko at kadalubhasaan sa pakikipagtulungan sa kanila. Ang Rosbank ay sabay-sabay na nag-deploy ng pribadong cloud kasama ang DevOps platform, at nakatulong ito sa simula. Sa cloud, posible na makuha ang mga kinakailangang mapagkukunan sa pagpindot ng isang pindutan sa 15 minuto dati, ang naturang proseso ay maaaring tumagal ng isang linggo.
Sa mga bangko at iba pang mga negosyo, kinakailangan na isagawa ang mga paghihigpit nang maaga sa pangkat ng seguridad ng impormasyon at maghanap ng solusyon na magpapahintulot sa mga pagbabago na maipatupad.
Pagkatapos ng pilot, kailangang palakihin ang isang matagumpay na solusyon.
- Mahalagang "ituwid" ang pipeline hangga't maaari, alisin ang mga hindi kinakailangang link mula dito, i-highlight ang mga nagbibigay ng halaga, at alisin ang mga natitirang bahagi. Ang mga intermediate ay mga antipattern. Halimbawa, sa Rosbank, maraming mga koponan ang hindi nakabuo ng panloob na pag-unlad, na nag-iiwan lamang ng panlabas na pag-unlad. Ito ay humantong sa paglitaw ng isang nakatuong koponan ng DevOps, na nagsisiguro sa paglilipat ng code mula sa panlabas patungo sa mga panloob na developer. Ang problema ay nalutas sa pamamagitan ng pagsasama ng panlabas na pag-unlad sa CI/CD, upang hindi lamang nila ilipat ang code mula sa kanilang sarili sa bangko, ngunit magiging responsable din para sa tagumpay nito.
- Kasama sa modelo ng maturity ang mga elemento ng mga kasanayan sa DevOps, mga nakalistang tool, at isinasaalang-alang ang mga feature ng pakikipagtulungan sa mga external na supplier - sa hinaharap, nakatulong ito upang mabilis na mabawasan ang backlog ng mga gawain kapag ipinapatupad ang mga ito sa mga bagong team.
- Kailangan natin ng Pamamahala sa anyo ng malambot na kontrol at mga rekomendasyon. Ang Handbook ng DevOps na mahusay na gumagana ay isang set ng mga katangian ng organisasyon at tooling na tumutulong sa mga team na gamitin ang platform nang tama.
- Dapat mong bigyang pansin kaagad ang kultura, kung gayon maraming mga pagbabago ang mangyayari nang mas mabilis at mas madali. Palakihin ang iyong panloob na komunidad, magsagawa ng mga meetup, teknikal na workshop, pagsasanay, at masasayang aktibidad. Nagbubunga ito: ang mga tao ay nagbabahagi ng mga kasanayan, tingnan kung sino ang gumawa ng ano, alam kung saan lilipat, mayroong hype at malusog na kompetisyon sa loob ng kumpanya.
- Walang saysay na makipagtulungan sa mga hindi kasali sa proseso, sa mga koponan na hindi pa matured, mas mahusay na mamuhunan sa mga interesadong koponan at mga tapat na tao.
- Ang napiling solusyon ay dapat na maginhawa para sa mga inhinyero na gumagamit nito.
- Ang panlabas na pag-unlad ay hindi isang blocker;
Kaunting pakinabang pa
Listahan ng mga aklat na sulit basahin para sa mga nasa DevOps, mula kay Alexander Chistyakov, vdsina.ru:
- Irina Yakutenko "Kalooban at pagpipigil sa sarili."
- Daniel Kahneman "Nag-iisip, Mabilis at Mabagal".
- Barbara Oakley "Isang Isip para sa Mga Numero".
- Maxim Dorofeev "Mga diskarte sa Jedi".
- Viktor Frankl "Paghahanap ng Tao para sa Kahulugan".
Manatiling nakatutok
Gustung-gusto din namin ang DevOps. Sundin ang mga anunsyo ng serye at @Kubernetes, pati na rin ang iba pang mga kaganapan sa Mail.ru Cloud Solutions, sa aming Telegram channel:
Pinagmulan: www.habr.com
