Ang tanong na "kung paano ipatupad ang mga devops" ay nasa loob ng maraming taon, ngunit walang maraming magagandang materyales. Minsan nabibiktima ka ng mga advertisement mula sa hindi masyadong matalinong mga consultant na kailangang ibenta ang kanilang oras, gaano man kaganda. Minsan ang mga ito ay malabo, lubhang pangkalahatang mga salita tungkol sa kung paano inaararo ng mga barko ng megacorporations ang mga kalawakan ng uniberso. Ang tanong ay lumitaw: ano ang kahalagahan nito sa atin? Mahal na may-akda, maaari mong malinaw na bumalangkas ang iyong mga ideya sa isang listahan?
Ang lahat ng ito ay nagmumula sa katotohanan na hindi gaanong tunay na kasanayan at pag-unawa sa kinalabasan ng mga pagbabago sa kultura ng kumpanya ang naipon. Ang mga pagbabago sa kultura ay mga pangmatagalang bagay, ang mga resulta nito ay hindi lilitaw sa isang linggo o isang buwan. Kailangan namin ng isang taong may sapat na gulang upang makita kung paano naitayo at nabigo ang mga kumpanya sa paglipas ng mga taon.
John Willis - isa sa mga ama ng DevOps. Si John ay may mga dekada ng karanasan sa pagtatrabaho sa isang malaking bilang ng mga kumpanya. Kamakailan, nagsimulang mapansin ni John ang mga tiyak na pattern na nagaganap kapag nagtatrabaho sa bawat isa sa kanila. Gamit ang mga archetype na ito, ginagabayan ni John ang mga kumpanya sa totoong landas ng pagbabagong DevOps. Magbasa nang higit pa tungkol sa mga archetype na ito sa pagsasalin ng kanyang ulat mula sa kumperensya ng DevOops 2018.
Tungkol sa tagapagsalita:
Mahigit sa 35 taon sa pamamahala ng IT, lumahok sa paglikha ng hinalinhan ng OpenCloud sa Canonical, nakibahagi sa 10 mga startup, dalawa sa mga ito ay naibenta sa Dell at Docker. Sa kasalukuyan siya ay Bise Presidente ng DevOps at Digital Practices sa SJ Technologies.
Susunod ay ang kuwento mula sa pananaw ni John.
Ang pangalan ko ay John Willis at ang pinakamadaling lugar para mahanap ako ay sa Twitter, . Mayroon akong parehong alias sa Gmail at GitHub. A makakahanap ka ng mga video recording ng aking mga ulat at mga presentasyon para sa kanila.
Marami akong mga pagpupulong sa mga CIO ng iba't ibang malalaking kumpanya. Madalas silang nagreklamo na hindi nila naiintindihan kung ano ang DevOps, at lahat ng sumusubok na ipaliwanag ito sa kanila ay pinag-uusapan ang tungkol sa ibang bagay. Ang isa pang karaniwang reklamo ay ang DevOps ay hindi gumagana, bagaman tila ginagawa ng mga direktor ang lahat tulad ng ipinaliwanag sa kanila. Pinag-uusapan natin ang mga malalaking kumpanya na higit sa isang daang taong gulang. Pagkatapos makipag-usap sa kanila, ako ay dumating sa konklusyon na para sa maraming mga problema, ito ay hindi mataas na teknolohiya na pinaka-angkop, ngunit sa halip medyo mababang-tech na mga solusyon. Ilang linggo ko lang nakipag-usap ang mga tao mula sa iba't ibang departamento. Ang nakikita mo sa pinakaunang larawan sa post ay ang aking huling proyekto, ito ang hitsura ng silid pagkatapos ng tatlong araw na trabaho.
Ano ang DevOps?
Sa katunayan, kung tatanungin mo ang 10 iba't ibang tao, magbibigay sila ng 10 iba't ibang mga sagot. Ngunit narito ang kawili-wiling bagay: lahat ng sampung sagot na ito ay magiging tama. Walang maling sagot dito. Medyo malalim ako sa DevOps, sa loob ng humigit-kumulang 10 taon, at ako ang unang Amerikano sa unang DevOpsDay. Hindi ko sasabihin na mas matalino ako kaysa sa lahat ng kasangkot sa DevOps, ngunit halos walang sinuman ang gumugol ng labis na pagsisikap dito. Naniniwala ako na nangyayari ang DevOps kapag nagsasama-sama ang human capital at teknolohiya. Madalas nating nakakalimutan ang tungkol sa dimensyon ng tao, bagama't marami tayong pinag-uusapan tungkol sa lahat ng uri ng kultura.
Ngayon ay mayroon na tayong maraming data, limang taon ng akademikong pananaliksik, pagsubok ng mga teorya sa isang pang-industriyang sukat. Ang sinasabi sa amin ng mga pag-aaral na ito ay kung pagsasamahin mo ang ilang mga pattern ng pag-uugali sa isang kultura ng organisasyon, makakamit mo ang isang 2000x na bilis. Ang acceleration na ito ay tinutugma ng pantay na pagpapabuti sa katatagan. Isa itong quantitative measurement ng benepisyo na maidudulot ng DevOps sa anumang kumpanya. Ilang taon na ang nakalilipas, pinag-uusapan ko ang tungkol sa DevOps sa CEO ng isang kumpanya ng Fortune 5000. Noong naghahanda ako para sa pagtatanghal, labis akong kinabahan dahil kailangan kong ibuod ang aking mga taon ng karanasan sa loob ng 5 minuto.
Sa huli ay ibinigay ko ang mga sumusunod Kahulugan ng DevOps: Ito ay isang hanay ng mga kasanayan at pattern na nagbibigay-daan sa pagbabago ng human capital tungo sa mataas na pagganap na kapital ng organisasyon. Ang isang halimbawa ay ang paraan ng pagpapatakbo ng Toyota sa nakalipas na 50 o 60 taon.
(Pagkatapos nito, ang mga naturang diagram ay ibinigay hindi bilang sangguniang materyal, ngunit bilang mga paglalarawan. Mag-iiba ang kanilang nilalaman para sa bawat bagong kumpanya. Gayunpaman, ang larawan ay maaaring tingnan nang hiwalay at palakihin
Ang isa sa pinakamatagumpay na gayong mga kasanayan ay halaga stream mapping. Maraming magagandang libro ang naisulat tungkol dito, ang pinakamatagumpay ay ni Karen Martin. Ngunit sa nakalipas na taon, nakarating ako sa konklusyon na kahit ang diskarte na ito ay masyadong high-tech. Ito ay tiyak na maraming mga pakinabang at ginamit ko ito ng marami. Ngunit kapag tinanong ka ng CEO kung bakit hindi maaaring lumipat ang kanyang kumpanya sa mga bagong riles, masyadong maaga para pag-usapan ang tungkol sa value stream mapping. Marami pang pangunahing katanungan na dapat munang masagot.
Sa tingin ko ang pagkakamali ng marami sa aking mga kasamahan ay binibigyan lang nila ang kumpanya ng limang puntos na gabay at pagkatapos ay bumalik pagkalipas ng anim na buwan at tingnan kung ano ang nangyari. Kahit na ang isang magandang scheme tulad ng value stream mapping ay may, sabihin nating, blind spots. Pagkatapos ng daan-daang panayam sa mga direktor ng iba't ibang kumpanya, nakabuo ako ng isang tiyak na pattern na nagpapahintulot sa amin na hatiin ang problema sa mga bahagi nito, at ngayon ay tatalakayin natin ang bawat isa sa mga bahaging ito sa pagkakasunud-sunod. Bago mag-apply ng anumang mga teknolohikal na solusyon, ginagamit ko ang pattern na ito, at bilang isang resulta, ang lahat ng aking mga dingding ay natatakpan ng mga diagram. Kamakailan ay nagtatrabaho ako sa isang mutual fund at napunta ako sa 100-150 tulad ng mga scheme.
Ang masamang kultura ay kumakain ng magagandang paraan para sa almusal
Ang pangunahing ideya ay ito: walang halaga ng Lean, Agile, SAFE at DevOps ang makakatulong kung ang kultura mismo ng organisasyon ay masama. Ito ay tulad ng pagsisid sa kalaliman nang walang scuba gear o gumagana nang walang x-ray. Sa madaling salita, sa paraphrase Drucker at Deming: isang masamang kultura ng organisasyon ay lalamunin ang anumang magandang sistema nang hindi sinasakal ito.
Upang malutas ang pangunahing problemang ito, kailangan mong gawin ang mga sumusunod na hakbang:
- Gawing Nakikita ang Lahat ng Trabaho: kailangan mong gawing nakikita ang lahat ng gawain. Hindi sa kahulugan na dapat itong ipakita sa ilang screen, ngunit sa kahulugan na dapat itong maobserbahan.
- Pinagsama-samang Sistema sa Pamamahala ng Trabaho: kailangang pagsama-samahin ang mga sistema ng pamamahala. Sa problema ng "tribal" na kaalaman at institusyonal na kaalaman, sa 9 na kaso sa 10 ang bottleneck ay mga tao. Nasa libro ang problema ay sa isang nag-iisang tao, si Brent, na naging dahilan upang ang proyekto ay nahuli ng tatlong taon sa iskedyul. At nakatagpo ako sa mga "Brents" na ito kahit saan. Upang malutas ang mga bottleneck na ito, ginagamit ko ang susunod na dalawang item sa aming listahan.
- Teorya ng Mga Limitasyon na Pamamaraan: teorya ng limitasyon.
- Mga hack sa pakikipagtulungan: mga hack sa pakikipagtulungan.
- Toyota Kata (): Hindi ako masyadong magsasalita tungkol sa Toyota Kata. Kung interesado, sa aking github sa halos bawat isa sa mga paksang ito.
- Organisasyong Nakatuon sa Market: organisasyong nakatuon sa merkado.
- Mga shift-left auditor: pag-audit sa mga unang yugto ng ikot.
Nagsisimula akong magtrabaho sa isang organisasyon nang napakasimple: Pumunta ako sa kumpanya at nakikipag-usap sa mga empleyado. Tulad ng nakikita mo, walang mataas na teknolohiya. Ang kailangan mo lang ay may masusulatan. Nag-iipon ako ng ilang mga koponan sa isang silid at sinusuri kung ano ang sinasabi nila sa akin mula sa pananaw ng aking 7 archetypes. At pagkatapos ay bibigyan ko sila ng marker at hihilingin sa kanila na isulat sa pisara ang lahat ng sinabi nila nang malakas sa ngayon. Karaniwan sa mga ganitong uri ng pagpupulong ay may isang tao na nagsusulat ng lahat, at sa pinakamainam ay maaari niyang isulat ang 10% ng talakayan. Sa aking pamamaraan, ang bilang na ito ay maaaring itaas sa halos 40%.
(Ang larawang ito ay maaaring tingnan nang hiwalay )
Ang aking diskarte ay batay sa gawa ni William Schneider. ). Ang diskarte ay batay sa ideya na ang anumang organisasyon ay maaaring hatiin sa apat na parisukat. Ang pamamaraan na ito para sa akin ay karaniwang resulta ng pagtatrabaho sa daan-daang iba pang mga pamamaraan na lumitaw kapag sinusuri ang isang organisasyon. Ipagpalagay na mayroon tayong isang organisasyon na may mataas na antas ng kontrol, ngunit may mababang kakayahan. Ito ay isang labis na hindi kanais-nais na opsyon: kapag ang lahat ay nasa linya, ngunit walang nakakaalam kung ano ang gagawin.
Ang isang bahagyang mas mahusay na opsyon ay isa na may mataas na antas ng parehong kontrol at kakayahan. Kung kumikita ang naturang kumpanya, marahil ay hindi nito kailangan ang DevOps. Ito ay pinaka-kagiliw-giliw na magtrabaho sa isang kumpanya na may mataas na antas ng kontrol, mababang kakayahan at pakikipagtulungan, ngunit sa parehong oras ay isang mataas na antas ng kultura (paglilinang). Ibig sabihin, ang kumpanya ay maraming tao na gustong magtrabaho doon at mababa ang labor turnover.
(Ang larawang ito ay maaaring tingnan nang hiwalay )
Para sa akin, ang mga pamamaraan na may mahigpit na mga alituntunin ay humaharang sa paraan ng pagkamit ng katotohanan. Sa partikular na pagmamapa ng stream ng halaga, maraming mga panuntunan tungkol sa kung paano dapat isaayos ang impormasyon. Sa mga unang yugto ng trabaho, na pinag-uusapan ko ngayon, walang nangangailangan ng mga patakarang ito. Kung ang isang tao na may marker sa kanyang mga kamay ay naglalarawan sa totoong sitwasyon sa kumpanya sa board, ito ang pinakamahusay na paraan upang maunawaan ang estado ng mga gawain. Ang naturang impormasyon ay hindi nakakarating sa mga direktor. Sa sandaling ito, hangal na matakpan ang tao at sabihin na hindi tama ang pagguhit niya ng ilang uri ng arrow. Sa yugtong ito, mas mahusay na gumamit ng mga simpleng panuntunan, halimbawa: ang multi-level abstraction ay maaaring malikha sa pamamagitan lamang ng paggamit ng maraming kulay na mga marker.
Uulitin ko, walang high technology. Ang itim na marker ay naglalarawan ng layunin na katotohanan kung paano gumagana ang lahat. Gamit ang pulang marker, minarkahan ng mga tao kung ano ang hindi nila gusto tungkol sa kasalukuyang estado ng mga gawain. Mahalaga na sila ang sumulat nito, hindi ako. Kapag pumunta ako sa CIO pagkatapos ng isang pulong, hindi ako nag-aalok ng listahan ng 10 bagay na kailangang ayusin. Nagsusumikap akong makahanap ng mga koneksyon sa pagitan ng sinasabi ng mga tao sa kumpanya at ng mga umiiral nang napatunayang pattern. Sa wakas, ang isang asul na marker ay nagmumungkahi ng mga posibleng solusyon sa problema.
(Ang larawang ito ay maaaring tingnan nang hiwalay )
Ang isang halimbawa ng diskarteng ito ay inilalarawan na ngayon sa itaas. Sa simula ng taong ito nagtrabaho ako sa isang bangko. Ang mga taong panseguridad doon ay kumbinsido na hindi sila dapat pumunta sa mga pagsusuri sa disenyo at kinakailangan.
(Ang larawang ito ay maaaring tingnan nang hiwalay )
At pagkatapos ay nakipag-usap kami sa mga tao mula sa ibang mga departamento at lumabas na mga 8 taon na ang nakakaraan, ang mga developer ng software ay nagtanggal ng mga manggagawa sa seguridad dahil sila ay nagpapabagal sa trabaho. At pagkatapos ay naging isang pagbabawal, na kinuha para sa ipinagkaloob. Bagaman sa katotohanan ay walang pagbabawal.
Ang aming pagpupulong ay nagpatuloy sa isang lubhang nakakalito na paraan: sa loob ng halos tatlong oras, limang magkakaibang koponan ang hindi makapagpaliwanag sa akin kung ano ang nangyayari sa pagitan ng code at ng pagpupulong. At ito ay tila ang pinakasimpleng bagay. Karamihan sa mga consultant ng DevOps ay ipinapalagay na alam na ito ng lahat.
Tapos yung namamahala sa IT governance, na apat na oras na nanahimik, biglang nabuhay nung makarating kami sa topic niya, at in-occupy kami ng napakahabang panahon. Sa pagtatapos ay tinanong ko siya kung ano ang iniisip niya tungkol sa pagpupulong, at hindi ko malilimutan ang kanyang sagot. Sinabi niya: "Akala ko noon, ang aming bangko ay mayroon lamang dalawang paraan ng paghahatid ng software, ngunit ngayon alam ko na mayroong lima sa kanila, at hindi ko alam ang tungkol sa tatlo."
(Ang larawang ito ay maaaring tingnan nang hiwalay )
Ang huling pagpupulong sa bangkong ito ay kasama ang investment software team. Kasama niya na ang pagsusulat ng mga diagram na may marker sa isang sheet ng papel ay mas mahusay kaysa sa isang board, at mas mahusay kaysa sa isang smartboard.
Ang mga larawang nakikita mo ay kung ano ang hitsura ng conference room ng hotel sa ikaapat na araw ng aming pagpupulong. At ginamit namin ang mga scheme na ito upang maghanap ng mga pattern, iyon ay, archetypes.
Kaya, nagtatanong ako sa mga manggagawa, isinusulat nila ang mga sagot na may mga marker ng tatlong kulay (itim, pula at asul). Sinusuri ko ang kanilang mga sagot para sa mga archetypes. Ngayon talakayin natin ang lahat ng mga archetypes sa pagkakasunud-sunod.
1. Gawing Visible ang Lahat ng Trabaho: Gawing nakikita ang trabaho
Karamihan sa mga kumpanyang nagtatrabaho ako ay may napakataas na porsyento ng hindi kilalang trabaho. Halimbawa, ito ay kapag ang isang empleyado ay pumupunta sa isa pa at hinihiling lamang na gawin ang isang bagay. Sa malalaking organisasyon, maaaring mayroong 60% na hindi planadong gawain. At hanggang sa 40% ng trabaho ay hindi dokumentado sa anumang paraan. Kung Boeing, hindi na ako sasakay sa eroplano nila sa buong buhay ko. Kung kalahati lamang ng gawain ang naidokumento, kung gayon hindi alam kung ang gawaing ito ay ginagawa nang tama o hindi. Ang lahat ng iba pang mga pamamaraan ay naging walang silbi - walang saysay na subukang i-automate ang anuman, dahil ang kilalang 50% ay maaaring ang pinaka magkakaugnay at malinaw na bahagi ng trabaho, ang automation na kung saan ay hindi magbibigay ng magagandang resulta, at lahat ng pinakamasama. ang mga bagay ay nasa di-nakikitang kalahati. Sa kawalan ng dokumentasyon, imposibleng makahanap ng lahat ng uri ng mga hack at nakatagong trabaho, hindi upang makahanap ng mga bottleneck, ang mga mismong "Brents" na napag-usapan ko na. Mayroong isang kahanga-hangang libro ni Dominica DeGrandis . Ibinunyag niya limang magkakaibang "time leaks" (mga magnanakaw ng oras):
- Masyadong Maraming Trabaho sa Proseso (WIP)
- Hindi kilalang Dependencies
- Hindi Planong Trabaho
- Magkasalungat na priyoridad
- Napabayaang Trabaho
Ito ay napakahalagang pagsusuri at ang aklat ay mahusay, ngunit ang lahat ng payo na ito ay walang silbi kung 50% lamang ng data ang makikita. Ang mga pamamaraan na iminungkahi ng Dominica ay maaaring gamitin kung ang katumpakan na higit sa 90% ay makakamit. Pinag-uusapan ko ang mga sitwasyon kung saan binibigyan ng isang boss ang isang subordinate ng 15 minutong gawain, ngunit tumatagal ito ng tatlong araw; pero hindi talaga alam ng amo na nakadepende ang subordinate na ito sa apat o limang tao.
Ang Phoenix Project ay isang magandang kuwento tungkol sa isang proyekto na huli na ng tatlong taon. Ang isa sa mga karakter ay nahaharap sa pagpapaalis dahil dito, at nakilala niya ang isa pang karakter na ipinakita bilang isang uri ng Socrates. Tumutulong siya upang malaman kung ano ang eksaktong nangyari. Lumalabas na ang kumpanya ay may isang tagapangasiwa ng system, na ang pangalan ay Brent, at lahat ng trabaho ay dumadaan sa kanya. Sa isa sa mga pagpupulong, ang isa sa mga subordinates ay tinanong: bakit ang bawat kalahating oras na gawain ay tumatagal ng isang linggo? Ang sagot ay isang napakasimpleng presentasyon ng teorya ng queuing at batas ni Little, at sa presentasyong ito ay lumalabas na sa 90% occupancy, ang bawat oras ng trabaho ay tumatagal ng 9 na oras. Ang bawat gawain ay kailangang ipadala sa pitong iba pang mga tao, upang ang oras na iyon ay maging 63 oras, 7 beses 9. Ang sinasabi ko ay upang magamit ang Batas ni Little o anumang kumplikadong teorya ng pagpila, kailangan mo man lang magkaroon ng data.
Kaya kapag pinag-uusapan ko ang tungkol sa visibility, hindi ko ibig sabihin na lahat ay nasa screen, ngunit mayroon kang data. Kapag ginawa nila, madalas lumalabas na napakaraming hindi planadong trabaho na kahit papaano ay ipinapadala kay Brent kapag hindi na kailangan. At si Brent ay isang mahusay na tao, hindi siya tatanggi, ngunit hindi niya sinasabi sa sinuman kung paano niya ginagawa ang kanyang trabaho.
Kapag ang trabaho ay nakikita, ang data ay maaaring maayos na naiuri (iyan ang ginagawa ni Dominika sa larawan), ang abstraction ng limang beses na pagtagas ay maaaring ilapat, at ang automation ay maaaring ilapat.
2. Pagsama-samahin ang Work Management Systems: Task Management
Ang mga archetype na sinasabi ko ay isang uri ng pyramid. Kung ang una ay ginawa nang tama, kung gayon ang pangalawa ay isa nang uri ng add-on. Marami sa mga ito ay hindi gumagana para sa mga startup, kailangang tandaan ang mga ito para sa mas malalaking kumpanya tulad ng Fortune 5000. Ang huling kumpanyang pinagtrabahuan ko ay mayroong 10 ticketing system. Ang isang koponan ay may Remedy, ang isa pa ay nagsulat ng ilang uri ng sarili nitong sistema, ang pangatlo ay gumamit ng Jira, at ang ilan ay gumawa ng email. Ang parehong problema ay lumitaw kung ang kumpanya ay may 30 iba't ibang mga pipeline, ngunit wala akong oras upang talakayin ang lahat ng mga naturang kaso.
Tinatalakay ko sa mga tao nang eksakto kung paano nilikha ang mga tiket, kung ano ang susunod na mangyayari sa kanila, at kung paano sila naiiwasan. Ang pinaka-kagiliw-giliw na bagay ay ang mga tao sa aming mga pulong ay nagsasalita ng lubos na taos-puso. Tinanong ko kung gaano karaming tao ang naglalagay ng "minor / no impact" sa mga tiket na dapat talagang bigyan ng "major impact". Halos lahat pala ay gumagawa nito. Hindi ako nakikibahagi sa pagtuligsa at sinusubukan sa lahat ng posibleng paraan na hindi makilala ang mga tao. Kapag taos-puso silang nagtapat sa akin ng isang bagay, hindi ko ibinibigay ang tao. Ngunit kapag halos lahat ay lumampas sa sistema, nangangahulugan ito na ang lahat ng seguridad ay mahalagang window dressing. Samakatuwid, walang mga konklusyon ang maaaring makuha mula sa data ng sistemang ito.
Upang malutas ang problema sa tiket, kailangan mong pumili ng isang pangunahing sistema. Kung gumagamit ka ng Jira, panatilihin ito Jira. Kung mayroong anumang alternatibo, hayaan itong maging isa lamang. Ang ilalim na linya ay ang mga tiket ay dapat tingnan bilang isa pang hakbang sa proseso ng pag-unlad. Ang bawat aksyon ay dapat may tiket, na dapat dumaloy sa daloy ng trabaho sa pag-unlad. Ang mga tiket ay ipinapadala sa koponan, na nagpo-post sa kanila sa storyboard at pagkatapos ay mananagot para sa kanila.
Nalalapat ito sa lahat ng departamento, kabilang ang imprastraktura at mga operasyon. Sa kasong ito, posible na bumuo ng hindi bababa sa ilang makatwirang ideya ng estado ng mga gawain. Kapag naitatag na ang prosesong ito, biglang nagiging madaling matukoy kung sino ang responsable para sa bawat aplikasyon. Dahil ngayon, hindi 50% ang natatanggap namin, kundi 98% ng mga bagong serbisyo. Kung gumagana ang pangunahing prosesong ito, bubuti ang katumpakan sa buong system.
Pipeline ng mga serbisyo
Nalalapat lamang ito sa malalaking korporasyon. Kung ikaw ay isang bagong kumpanya sa isang bagong larangan, isara ang iyong mga manggas at makipagtulungan sa iyong Travis CI o CircleCI. Pagdating sa Fortune 5000 companies, isang case in point na nangyari sa banko kung saan ako nagtrabaho. Lumapit sa kanila ang Google at ipinakita sa kanila ang mga diagram ng mga lumang IBM system. Ang mga lalaki mula sa Google ay nagtanong sa pagkalito - nasaan ang source code para dito? Ngunit walang source code, kahit isang GUI. Ito ang katotohanang kailangang harapin ng malalaking organisasyon: 40 taong gulang na mga rekord ng bangko sa isang sinaunang mainframe. Gumagamit ang isa sa aking mga kliyente ng mga container ng Kubernetes na may mga pattern ng Circuit Breaker, kasama ang Chaos Monkey, lahat para sa KeyBank application. Ngunit ang mga lalagyang ito sa huli ay kumokonekta sa isang COBOL application.
Ang mga lalaki mula sa Google ay lubos na nagtitiwala na malulutas nila ang lahat ng mga problema ng aking kliyente, at pagkatapos ay nagsimula silang magtanong: ano ang IBM datapipe? Sinabi sa kanila: ito ay isang connector. Ano ang koneksyon nito? Sa sistema ng Sperry. At ano yan? At iba pa. Sa unang tingin, tila: anong uri ng DevOps ang maaaring mayroon? Ngunit sa katunayan, ito ay posible. May mga sistema ng paghahatid na nagbibigay-daan sa iyong ibigay ang daloy ng trabaho sa mga pangkat ng paghahatid.
3. Theory of Constraints: Theory of Constraints
Lumipat tayo sa ikatlong archetype: kaalamang institusyonal/"tribal". Bilang isang patakaran, sa anumang organisasyon mayroong maraming mga tao na nakakaalam ng lahat at namamahala sa lahat. Ito ang mga taong pinakamatagal sa organisasyon at alam ang lahat ng mga solusyon.
Kapag lumabas ito sa diagram, partikular kong binilog ang mga taong iyon gamit ang isang marker: halimbawa, lumalabas na ang isang Lou ay naroroon sa lahat ng mga pagpupulong. At ito ay malinaw sa akin: ito ay lokal na Brent. Kapag ang CIO ay pumili sa pagitan ko na naka-T-shirt at sneakers at ang lalaking mula sa IBM na naka-suit, ako ang napili dahil nasasabi ko sa direktor ang mga bagay na hindi sasabihin ng ibang lalaki at na maaaring hindi gustong marinig ng direktor. . Sinasabi ko sa kanila na ang bottleneck sa kanilang kumpanya ay isang nagngangalang Fred at isang nagngangalang Lou. Ang bottleneck na ito ay kailangang alisin, ang kanilang kaalaman ay kailangang makuha mula sa kanila sa isang paraan o iba pa.
Upang malutas ang ganitong uri ng problema, maaari kong, halimbawa, magmungkahi ng paggamit ng Slack. Magtatanong ang isang matalinong direktor - bakit? Kadalasan, sa mga ganitong kaso, ang mga consultant ng DevOps ay sumasagot: dahil ginagawa ito ng lahat. Kung talagang matalino ang direktor, sasabihin niya: so what. At dito nagtatapos ang dialogue. At ang sagot ko dito ay: dahil may apat na bottleneck sa kumpanya, sina Fred, Lou, Susie at Jane. Upang ma-institutionalize ang kanilang kaalaman, kailangan munang ipakilala ang Slack. Ang lahat ng iyong wiki ay ganap na walang kapararakan dahil walang nakakaalam tungkol sa kanilang pag-iral. Kung ang engineering team ay kasangkot sa front-end at back-end development at kailangang malaman ng lahat na maaari silang makipag-ugnayan sa front-end development team o sa infrastructure team para sa mga tanong. Noon ay malamang na magkakaroon ng oras si Lou o Fred na sumali sa wiki. At pagkatapos ay sa Slack maaaring may magtanong kung bakit, sabihin nating, hindi gumagana ang hakbang 5. At pagkatapos ay itatama ni Lou o Fred ang mga tagubilin sa wiki. Kung itatatag mo ang prosesong ito, maraming bagay ang mahuhulog sa kanilang sarili.
Ito ang aking pangunahing punto: upang magrekomenda ng anumang mataas na teknolohiya, dapat mo munang ilagay ang pundasyon para sa mga ito sa pagkakasunud-sunod, at ito ay maaaring gawin sa mga low-tech na solusyon na inilarawan lamang. Kung nagsimula ka sa mga mataas na teknolohiya at hindi ipaliwanag kung bakit kailangan ang mga ito, kung gayon, bilang panuntunan, hindi ito nagtatapos nang maayos. Gumagamit ang isa sa aming mga kliyente ng Azure ML, isang napakamura at simpleng solusyon. Humigit-kumulang 30% ng kanilang mga tanong ang sinagot ng self-learning machine mismo. At ang bagay na ito ay isinulat ng mga operator na hindi kasangkot sa data science, statistics o mathematics. Ito ay makabuluhan. Ang halaga ng naturang solusyon ay minimal.
4. Mga hack sa pakikipagtulungan: Mga hack sa pakikipagtulungan
Ang ikaapat na archetype ay ang pangangailangan upang labanan ang paghihiwalay. Alam na ito ng karamihan sa mga tao: ang paghihiwalay ay nagdudulot ng poot. Kung ang bawat departamento ay nasa sarili nitong palapag, at ang mga tao ay hindi nagsasalubong sa isa't isa sa anumang paraan, maliban sa elevator, kung gayon ang poot sa pagitan nila ay napakadali. Ngunit kung, sa kabaligtaran, ang mga tao ay nasa iisang silid sa isa't isa, agad siyang umalis. Kapag ang isang tao ay nagtapon ng ilang pangkalahatang akusasyon, halimbawa, ang ganito at ganoong interface ay hindi kailanman gumagana, walang mas madaling i-deconstruct ang naturang akusasyon. Ang mga programmer na nagsulat ng interface ay kailangan lang magsimulang magtanong ng mga partikular na tanong, at magiging malinaw na, halimbawa, ginamit lang ng user ang tool nang hindi tama.
Maraming paraan para malampasan ang paghihiwalay. Minsan ay pinakonsulta ako para sa isang bangko sa Australia, ngunit tumanggi akong gawin ito dahil mayroon akong dalawang anak at isang asawa. Ang magagawa ko lang para matulungan sila ay magrekomenda ng graphical storytelling. Ito ay isang bagay na napatunayang gumagana. Ang isa pang kawili-wiling paraan ay ang mga lean coffee meeting. Sa isang malaking organisasyon, ito ay isang mahusay na opsyon para sa pagpapalaganap ng kaalaman. Bilang karagdagan, maaari kang magsagawa ng mga panloob na devopsday, hackathon, at iba pa.
5. Pagtuturo ng Kata
Gaya ng binala ko sa simula pa lang, hindi ko na ito pag-uusapan ngayon. Kung interesado ka, maaari mong tingnan .
Mayroon ding magandang pag-uusap sa paksang ito mula kay Mike Rother:
6. Market Oriented: organisasyong nakatuon sa pamilihan
Mayroong iba't ibang mga problema dito. Halimbawa, "I" people, "T" people at "E" people. Ang mga taong "ako" ay ang mga taong gumagawa lamang ng isang bagay. Karaniwang umiiral ang mga ito sa mga organisasyong may mga nakahiwalay na departamento. Ang "T" ay kapag ang isang tao ay mahusay sa isang bagay ngunit mahusay din sa ilang iba pang mga bagay. Ang "E" o kahit na "suklay" ay kapag ang isang tao ay may maraming kakayahan.
Gumagana dito ang batas ni Conway (), na sa pinaka-pinasimpleng anyo ay maaaring sabihin tulad ng sumusunod: kung ang tatlong mga koponan ay nagtatrabaho sa compiler, kung gayon ang resulta ay isang compiler ng tatlong bahagi. Samakatuwid, kung mayroong mataas na antas ng paghihiwalay sa loob ng isang organisasyon, kahit na ang mga Kubernetes, Circuit breaker, API extensibility at iba pang magagarang bagay sa organisasyong ito ay isasaayos sa parehong paraan tulad ng mismong organisasyon. Mahigpit na ayon kay Conway at sa kabila ng lahat ng mga batang geeks.
Ang solusyon sa problemang ito ay inilarawan nang maraming beses. Mayroong, halimbawa, mga archetype ng organisasyon na inilarawan ni Fernando Fernandez. Ang problemadong arkitektura na kakausap ko lang, na may paghihiwalay, ay isang function-oriented na arkitektura. Ang pangalawang uri ay ang pinakamasama, matrix architecture, isang gulo ng iba pang dalawa. Ang pangatlo ay kung ano ang nakikita sa karamihan ng mga startup, at sinusubukan din ng malalaking kumpanya na tumugma sa ganitong uri. Ito ay isang organisasyong nakatuon sa merkado. Dito kami nag-optimize upang makamit ang pinakamabilis na pagtugon sa mga kahilingan ng customer. Minsan ito ay tinatawag na isang patag na organisasyon.
Maraming tao ang naglalarawan sa istrukturang ito sa iba't ibang paraan, gusto ko ang mga salita bumuo/magpatakbo ng mga koponan, sa Amazon tinatawag nila ito dalawang pizza team. Sa istrukturang ito, ang lahat ng uri ng "I" na mga tao ay pinagsama-sama sa isang serbisyo, at unti-unti silang nagiging mas malapit sa uri ng "T", at kung ang tamang pamamahala ay nasa lugar, maaari pa silang maging "E". Ang unang counterargument dito ay ang ganitong istraktura ay may mga hindi kinakailangang elemento. Bakit kailangan mo ng tester sa bawat departamento kung maaari kang magkaroon ng espesyal na departamento ng mga tester? Ang sagot ko: ang mga dagdag na gastos sa kasong ito ay ang presyo para sa buong organisasyon na maging uri ng "E" sa hinaharap. Sa istrukturang ito, unti-unting natututo ang tester tungkol sa mga network, arkitektura, disenyo, atbp. Bilang resulta, ang bawat kalahok sa organisasyon ay lubos na nakakaalam ng lahat ng nangyayari sa organisasyon. Kung gusto mong malaman kung paano gumagana ang scheme na ito sa industriya, basahin .
7. Shift-left auditors: pag-audit nang maaga sa cycle. Pagsunod sa mga panuntunang pangkaligtasan na ipinapakita
Ito ay kapag ang iyong mga aksyon ay hindi pumasa sa pagsubok ng amoy, kumbaga. Ang mga taong nagtatrabaho para sa iyo ay hindi tanga. Kung, tulad ng sa halimbawa sa itaas, nagtakda sila ng menor de edad/walang epekto sa lahat ng dako, tumagal ito ng tatlong taon, at walang nakapansin ng anuman, kung gayon alam ng lahat na hindi gumagana ang system. O isa pang halimbawa - isang change advisory board, kung saan kailangang isumite ang mga ulat tuwing, halimbawa, Miyerkules. Mayroong isang grupo ng mga tao na nagtatrabaho doon (hindi masyadong mahusay na binabayaran, sa pamamagitan ng paraan) na, sa teorya, ay dapat malaman kung paano gumagana ang sistema sa kabuuan. At sa nakalipas na limang taon, malamang na napansin mo na ang aming mga system ay hindi kapani-paniwalang kumplikado. At lima o anim na tao ang kailangang gumawa ng desisyon tungkol sa isang pagbabago na hindi nila ginawa at tungkol sa kung saan ay wala silang alam.
Siyempre, hindi gumagana ang diskarteng ito. Kailangan kong alisin ang mga ganoong bagay dahil hindi pinoprotektahan ng mga taong ito ang sistema. Ang desisyon ay dapat gawin ng koponan mismo, dahil ang koponan ay dapat na responsable para dito. Kung hindi man, ang isang kabalintunaan na sitwasyon ay lumitaw kapag ang isang tagapamahala na hindi kailanman nagsulat ng code sa kanyang buhay ay nagsasabi sa programmer kung gaano katagal dapat isulat ang code. Ang isang kumpanyang nakatrabaho ko ay mayroong 7 magkakaibang board na nagsuri sa bawat pagbabago, kabilang ang isang architecture board, isang product board, atbp. Mayroon pa ngang ipinag-uutos na panahon ng paghihintay, bagama't sinabi sa akin ng isang empleyado na sa loob ng sampung taon ng trabaho, walang sinuman ang tumanggi sa pagbabagong ginawa ng taong ito sa panahon ng mandatoryong panahon na ito.
Kailangang imbitahan ang mga auditor na sumali sa amin, at huwag silang alisin. Sabihin sa kanila na sumulat ka ng mga hindi nababagong binary na lalagyan na, kung makapasa sila sa lahat ng mga pagsubok, mananatiling hindi nababago magpakailanman. Sabihin sa kanila na mayroon kang pipeline bilang code at ipaliwanag kung ano ang ibig sabihin nito. Ipakita sa kanila ang sumusunod na pamamaraan: isang hindi nababagong read-only na binary sa isang lalagyan na pumasa sa lahat ng pagsubok sa kahinaan; at pagkatapos ay hindi lamang walang humahawak dito, hindi rin nila ginagalaw ang system na lumilikha ng pipeline, dahil dynamic din itong nilikha. Mayroon akong mga kliyente, ang Capital One, na gumagamit ng Vault upang lumikha ng isang bagay tulad ng isang blockchain. Ang auditor ay hindi kailangang magpakita ng "mga recipe" mula sa Chef; ito ay sapat na upang ipakita ang blockchain, kung saan malinaw kung ano ang nangyari sa Jira ticket sa produksyon at kung sino ang responsable para dito.
Ayon sa , na ginawa noong 2018 ng Sonatype, mayroong 2017 bilyong kahilingan sa pag-download ng OSS noong 87.
Ang mga pagkalugi na natamo dahil sa mga kahinaan ay humahadlang. Bukod dito, ang mga numero na nakikita mo ngayon sa itaas ay hindi kasama ang mga gastos sa pagkakataon. Ano ang DevSecOps sa maikling salita? Hayaan mong sabihin ko kaagad na hindi ako interesadong pag-usapan kung gaano matagumpay ang pangalang ito. Ang punto ay dahil naging matagumpay ang DevOps, dapat nating subukang magdagdag ng seguridad sa pipeline na iyon.
Isang halimbawa ng pagkakasunod-sunod na ito:
Hindi ito rekomendasyon para sa mga partikular na produkto, bagama't gusto ko silang lahat. Binanggit ko ang mga ito bilang isang halimbawa upang ipakita na ang DevOps, na sa simula ay batay sa paradigma ng organisasyon sa industriya, ay nagbibigay-daan sa iyo na i-automate ang bawat yugto ng trabaho sa isang produkto.
At walang dahilan kung bakit hindi namin magawa ang parehong diskarte sa seguridad.
Kabuuan
Bilang konklusyon, magbibigay ako ng ilang tip para sa DevSecOps. Kailangan mong isama ang mga auditor sa proseso ng paglikha ng iyong mga system at maglaan ng oras sa pagtuturo sa kanila. Kailangan mong makipagtulungan sa mga auditor. Susunod, kailangan mong magsagawa ng ganap na walang awa na paglaban sa mga maling positibo. Kahit na sa pinakamahal na tool sa pag-scan ng kahinaan, maaari kang lumikha ng napakasamang gawi sa iyong mga developer kung hindi mo alam kung ano ang ratio ng iyong signal sa ingay. Ang mga developer ay mapupuno sa mga kaganapan at tatanggalin lamang ang mga ito. Kung narinig mo ang tungkol sa kuwento ng Equifax, iyon ang nangyari doon, kung saan hindi pinansin ang pinakamataas na antas ng alerto. Bilang karagdagan, ang mga kahinaan ay kailangang ipaliwanag sa paraang ginagawang malinaw kung paano nakakaapekto ang mga ito sa negosyo. Halimbawa, maaari mong sabihin na ito ay ang parehong kahinaan tulad ng sa kuwento ng Equifax. Ang mga kahinaan sa seguridad ay dapat tratuhin kapareho ng iba pang mga isyu sa software, ibig sabihin, dapat silang isama sa pangkalahatang proseso ng DevOps. Kailangan mong makipagtulungan sa kanila sa pamamagitan ng Jira, Kanban, atbp. Hindi dapat isipin ng mga developer na may ibang gagawa nito - sa kabaligtaran, dapat gawin ito ng lahat. Sa wakas, kailangan mong gumastos ng enerhiya sa pagsasanay sa mga tao.
Kapaki-pakinabang na mga link
Narito ang ilang mga pag-uusap mula sa kumperensya ng DevOops na maaaring maging kapaki-pakinabang sa iyo:
- Sergey Berdnikov, Artyom Kalichkin - Kuwento ng tagumpay, o βDev+DevOps+Opsβ (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps sa isang sukat: isang trahedya ng Griyego sa tatlong kilos (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Tumingin sa DevOops 2020 Moscow β marami ring mga kawili-wiling bagay doon.
Pinagmulan: www.habr.com