Pitakonan "carane ngetrapake devops" wis pirang-pirang taun, nanging ora akeh bahan sing apik. Kadhangkala sampeyan dadi korban iklan saka konsultan sing ora pinter sing kudu ngedol wektu, ora ketompo. Kadhangkala iki samar-samar, tembung-tembung sing umum banget babagan carane kapal-kapal megacorporation ngluku expanses alam semesta. Pitakonan muncul: apa prakara iki kanggo kita? Penulis sing dihormati, apa sampeyan bisa ngrumusake ide kanthi jelas ing dhaptar?
Kabeh iki asale saka kasunyatan sing ora akeh praktik nyata lan pangerten babagan asil transformasi budaya perusahaan wis akumulasi. Owah-owahan ing budaya minangka perkara jangka panjang, asile ora bakal katon sajrone seminggu utawa sasi. Kita butuh wong sing cukup umur kanggo ndeleng kepiye perusahaan wis dibangun lan gagal sajrone pirang-pirang taun.
John Willis - salah siji saka rama DevOps. John duwe pengalaman puluhan taun nggarap pirang-pirang perusahaan. Bubar, John wiwit ngelingi pola tartamtu sing kedadeyan nalika nggarap saben wong. Nggunakake archetypes iki, John nuntun perusahaan ing dalan bener transformasi DevOps. Waca liyane babagan archetypes iki ing terjemahan laporan saka konferensi DevOops 2018.
Babagan speaker:
Luwih saka 35 taun ing manajemen IT, melu nggawe pendahulu OpenCloud ing Canonical, melu 10 startup, loro sing didol menyang Dell lan Docker. Saiki dheweke dadi Wakil Presiden DevOps lan Praktek Digital ing SJ Technologies.
Sabanjure crita saka sudut pandang John.
Jenengku John Willis lan papan sing paling gampang kanggo nggoleki aku yaiku ing Twitter, . Aku duwe alias padha ing Gmail lan GitHub. A sampeyan bisa nemokake rekaman video saka laporan lan presentations kanggo wong-wong mau.
Aku duwe akeh rapat karo CIO saka macem-macem perusahaan gedhe. Dheweke kerep banget sambat yen dheweke ora ngerti apa DevOps, lan saben wong sing nyoba nerangake babagan dheweke ngomong babagan sing beda. Keluhan umum liyane yaiku DevOps ora bisa digunakake, sanajan para direktur nindakake kabeh kaya sing diterangake. Kita ngomong babagan perusahaan gedhe sing umure luwih saka satus taun. Sawise ngomong karo wong-wong mau, aku teka menyang kesimpulan sing kanggo akeh masalah, iku ora teknologi dhuwur sing paling cocog, nanging solusi relatif kurang-tech. Wis pirang-pirang minggu aku mung ngobrol karo wong-wong saka macem-macem departemen. Apa sing sampeyan deleng ing gambar pisanan ing kiriman kasebut minangka proyek pungkasanku, kaya ngono ruangan kasebut sawise telung dina kerja.
Apa DevOps?
Pancen, yen sampeyan takon 10 wong sing beda-beda, dheweke bakal menehi 10 jawaban sing beda. Nanging iki sing menarik: kabeh sepuluh jawaban iki bakal bener. Ora ana jawaban sing salah ing kene. Aku cukup jero ing DevOps, kira-kira 10 taun, lan dadi wong Amerika pisanan ing DevOpsDay pisanan. Aku ora bakal ngomong yen aku luwih pinter tinimbang kabeh wong sing melu DevOps, nanging meh ora ana sing wis ngupayakake. Aku percaya yen DevOps kedadeyan nalika modal manungsa lan teknologi teka bebarengan. Kita asring lali babagan dimensi manungsa, sanajan kita akeh ngomong babagan kabeh jinis budaya.
Saiki kita duwe akeh data, riset akademik limang taun, nguji teori ing skala industri. Apa sing dicritakake dening panliten iki yaiku yen sampeyan nggabungake sawetara pola prilaku ing budaya organisasi, sampeyan bisa entuk kacepetan 2000x. Akselerasi iki cocog karo perbaikan stabilitas sing padha. Iki minangka pangukuran kuantitatif babagan mupangat sing bisa ditindakake DevOps menyang perusahaan apa wae. Sawetara taun kepungkur, aku ngomong babagan DevOps menyang CEO saka perusahaan Fortune 5000. Nalika aku nyiapake presentasi, aku gugup banget amarga kudu ngringkes pengalamanku taun-taun ing menit 5.
Ing pungkasan aku menehi ing ngisor iki Definisi DevOps: Iki minangka sakumpulan praktik lan pola sing ngidini transformasi modal manungsa dadi modal organisasi kanthi kinerja dhuwur. Conto yaiku cara Toyota beroperasi sajrone 50 utawa 60 taun kepungkur.
(Sabanjure, diagram kasebut ora diwenehake minangka bahan referensi, nanging minangka ilustrasi. Isine bakal beda-beda kanggo saben perusahaan anyar. Nanging, gambar kasebut bisa dideleng kanthi kapisah lan digedhekake.
Salah sawijining praktik sing paling sukses yaiku pemetaan aliran nilai. Sawetara buku sing apik wis ditulis babagan iki, sing paling sukses yaiku dening Karen Martin. Nanging ing taun kepungkur, aku wis nyimpulake manawa pendekatan iki uga dhuwur banget. Mesthi akeh kaluwihan lan aku wis nggunakake akeh. Nanging nalika CEO takon sampeyan apa perusahaan ora bisa ngalih menyang ril anyar, iku banget awal kanggo pirembagan bab pemetaan stream Nilai. Ana akeh pitakonan sing luwih dhasar sing kudu dijawab dhisik.
Aku mikir kesalahan sing ditindakake dening kanca-kancaku yaiku mung menehi pandhuan limang poin marang perusahaan banjur bali nem wulan mengko lan ndeleng apa sing kedadeyan. Malah skema sing apik kaya pemetaan aliran nilai duwe, ayo ngomong, titik wuta. Sawise atusan wawancara karo direktur saka macem-macem perusahaan, aku wis ngembangake pola tartamtu sing ngidini kita ngilangi masalah kasebut dadi komponen, lan saiki kita bakal ngrembug saben komponen kasebut kanthi urutan. Sadurunge ngetrapake solusi teknologi, aku nggunakake pola iki, lan minangka asil, kabeh tembokku ditutupi diagram. Bubar aku nggarap dana bebarengan lan aku entuk 100-150 skema kasebut.
Budaya ala mangan pendekatan sing apik kanggo sarapan
Gagasan utama yaiku: ora ana jumlah Lean, Agile, SAFE lan DevOps sing bakal mbantu yen budaya organisasi kasebut dhewe ala. Iku kaya nyilem menyang telenging tanpa peralatan scuba utawa operasi tanpa x-ray. Ing tembung liya, kanggo paraphrase Drucker lan Deming: budaya organisasi sing ala bakal nguntal sistem sing apik tanpa keselak.
Kanggo ngatasi masalah utama iki, sampeyan kudu nindakake langkah-langkah ing ngisor iki:
- Nggawe Kabeh Karya Katon: sampeyan kudu nggawe kabeh karya katon. Ora ing pangertèn sing kudu kudu ditampilake ing sawetara layar, nanging ing pangertèn sing kudu diamati.
- Sistem Manajemen Kerja Konsolidasi: sistem manajemen kudu digabungake. Ing masalah kawruh "suku" lan kawruh institusi, ing 9 kasus saka 10 bottleneck iku wong. Ing buku masalah ana siji wong siji, Brent, sing nyebabake project dadi telung taun konco jadwal. Lan aku mbukak menyang "Brents" iki nang endi wae. Kanggo ngatasi bottlenecks iki, aku nggunakake rong item sabanjure ing dhaptar kita.
- Teori Kendala Metodologi: teori kendala.
- Hacks kolaborasi: hacks kolaborasi.
- Toyota Kata (): Aku ora bakal ngomong akeh babagan Toyota Kata. Yen kasengsem, ing githubku ing meh saben topik iki.
- Organisasi Berorientasi Pasar: organisasi berorientasi pasar.
- Auditor ngiwa: audit ing tahap awal siklus.
Aku miwiti nggarap organisasi kanthi gampang: Aku menyang perusahaan lan ngobrol karo karyawan. Nalika sampeyan bisa ndeleng, ora teknologi dhuwur. Sampeyan mung perlu kanggo nulis. Aku klumpukne sawetara tim ing siji kamar lan njelasno apa padha marang kula saka perspektif sandi 7 archetypes. Banjur aku menehi tandha dhewe lan njaluk dheweke nulis ing papan kabeh sing wis diomongake kanthi banter nganti saiki. Biasane ing jinis rapat iki ana siji wong sing nulis kabeh, lan paling apik dheweke bisa nulis 10% diskusi. Kanthi caraku, angka iki bisa diunggahake nganti 40%.
(Ilustrasi iki bisa dideleng kanthi kapisah )
Pendekatanku adhedhasar karya William Schneider. ). Pendekatan kasebut adhedhasar gagasan manawa organisasi apa wae bisa dipérang dadi papat kothak. Skema iki kanggo kula biasane asil nggarap atusan skema liyane sing muncul nalika nganalisa organisasi. Upaminipun kita duwe organisasi kanthi tingkat kontrol sing dhuwur, nanging kanthi kompetensi sing kurang. Iki minangka pilihan sing ora dikarepake: nalika kabeh wong mlaku ing garis, nanging ora ana sing ngerti apa sing kudu ditindakake.
Pilihan sing luwih apik yaiku sing nduweni tingkat kontrol lan kompetensi sing dhuwur. Yen perusahaan kasebut duwe bathi, mula bisa uga ora butuh DevOps. Sing paling menarik kanggo nggarap perusahaan sing nduweni tingkat kontrol sing dhuwur, kompetensi lan kerjasama sing kurang, nanging ing wektu sing padha tingkat budaya (kultivasi). Iki tegese perusahaan akeh sing seneng kerja ing kana lan omzet tenaga kerja sithik.
(Ilustrasi iki bisa dideleng kanthi kapisah )
Iku misale jek kula sing cara karo pedoman kaku mungkasi munggah ing cara kanggo nampa bebener. Ing pemetaan aliran nilai utamane, ana akeh aturan babagan carane informasi kudu disusun. Ing tahap awal karya, sing dakkandhakake saiki, ora ana sing butuh aturan kasebut. Yen wong karo spidol ing tangan njlèntrèhaké kahanan nyata ing perusahaan ing Papan, iki cara paling apik kanggo ngerti kahanan. Informasi kasebut ora tekan direktur. Ing wektu iki, bodho ngganggu wong kasebut lan ujar manawa dheweke salah nggambar panah. Ing tahap iki, luwih becik nggunakake aturan sing prasaja, contone: abstraksi multi-level bisa digawe mung kanthi nggunakake spidol multi-warna.
Aku mbaleni, ora teknologi dhuwur. Penanda ireng nggambarake kasunyatan objektif babagan cara kerjane kabeh. Kanthi tandha abang, wong menehi tandha apa sing ora disenengi babagan kahanan saiki. Sing penting padha nulis iki, dudu aku. Nalika aku lunga menyang CIO sawise rapat, aku ora menehi dhaptar 10 perkara sing kudu didandani. Aku usaha kanggo golek sambungan antarane apa wong ing perusahaan ngandika lan ana bukti buktiaken pola. Pungkasan, tandha biru nuduhake solusi sing bisa ditindakake kanggo masalah kasebut.
(Ilustrasi iki bisa dideleng kanthi kapisah )
Conto pendekatan iki saiki digambarake ing ndhuwur. Ing awal taun iki aku kerjo karo siji bank. Wong keamanan ana padha nggawe percoyo sing padha ngirim ora teka kanggo desain lan reviews requirement.
(Ilustrasi iki bisa dideleng kanthi kapisah )
Banjur kita ngobrol karo wong-wong saka departemen liyane lan ternyata kira-kira 8 taun kepungkur, pangembang piranti lunak mecat buruh keamanan amarga padha alon-alon kerja. Lan banjur dadi larangan, sing dijupuk kanggo diwenehake. Senajan ing kasunyatan ora ana larangan.
Rapat kita ditindakake kanthi cara sing mbingungake: kira-kira telung jam, limang tim sing beda-beda ora bisa nerangake apa sing kedadeyan ing antarane kode lan majelis. Lan iki bakal katon minangka sing paling gampang. Umume konsultan DevOps nganggep manawa kabeh wong wis ngerti iki.
Banjur wong sing ngurusi tata kelola IT, sing wis patang jam meneng, dumadakan urip nalika kita tekan topik kasebut, lan ngenggoni kita nganti suwe. Ing pungkasan aku takon apa dheweke mikir babagan rapat kasebut, lan aku ora bakal lali jawabane. Dheweke kandha, "Aku mikir yen bank kita mung duwe rong cara kanggo ngirim piranti lunak, nanging saiki aku ngerti yen ana lima, lan aku ora ngerti babagan telu."
(Ilustrasi iki bisa dideleng kanthi kapisah )
Rapat pungkasan ing bank iki yaiku karo tim piranti lunak investasi. Iku karo dheweke ternyata nulis diagram karo panandha ing sheet saka kertas luwih apik tinimbang ing Papan, lan malah luwih apik tinimbang ing smartboard.
Foto-foto sing sampeyan deleng kaya apa kamar konferensi hotel ing dina kaping papat rapat kita. Lan kita nggunakake skema iki kanggo nggoleki pola, yaiku, archetypes.
Dadi, aku takon marang para pekerja, dheweke nulis jawaban kanthi tandha telung warna (ireng, abang lan biru). Aku nganalisa jawaban kanggo archetypes. Saiki ayo ngrembug kabeh archetypes kanthi urutan.
1. Nggawe Kabeh Karya Katon: Nggawe karya katon
Umume perusahaan sing kerjane duwe persentase kerja sing ora dingerteni. Contone, iki nalika siji karyawan teka menyang liyane lan mung njaluk apa. Ing organisasi gedhe, bisa uga ana 60% karya sing ora direncanakake. Lan nganti 40% karya ora didokumentasikake kanthi cara apa wae. Yen Boeing, aku ora bakal numpak pesawat maneh ing uripku. Yen mung setengah saka karya sing didokumentasikake, mula ora dingerteni manawa karya iki ditindakake kanthi bener utawa ora. Kabeh cara liyane ora ana gunane - ora ana gunane nyoba ngotomatisasi apa wae, amarga 50% sing dikenal bisa dadi bagian sing paling koheren lan jelas saka karya, otomatisasi sing ora bakal menehi asil sing apik, lan kabeh sing paling awon. barang ana ing setengah kang ora katon. Yen ora ana dokumentasi, ora bisa nemokake kabeh jinis hacks lan karya sing didhelikake, ora nemokake bottlenecks, "Brents" sing wis dakkandhakake. Ana buku apik banget dening Dominica DeGrandis . Dheweke mbukak limang beda "wektu bocor" (maling jaman):
- Kakehan Kerja ing Proses (WIP)
- Dependensi sing ora dingerteni
- Karya sing ora direncanakake
- Prioritas konflik
- Kerja sing diabaikan
Iki minangka analisis sing larang banget lan buku kasebut apik banget, nanging kabeh saran iki ora ana gunane yen mung 50% data sing katon. Cara sing diusulake Dominika bisa digunakake yen akurasi ing ndhuwur 90% wis diraih. Aku ngomong bab kahanan ngendi boss menehi bawahan tugas 15 menit, nanging njupuk telung dina; nanging bos ora ngerti tenan yen bawahan iki gumantung ing papat lima wong liyane.
Proyek Phoenix minangka crita sing apik babagan proyek sing wis telat telung taun. Salah sawijining karakter ngadhepi dipecat amarga iki, lan dheweke ketemu karo karakter liyane sing ditampilake minangka jinis Socrates. Dheweke mbantu ngerteni apa sing salah. Pranyata metu sing perusahaan wis siji administrator sistem, kang jenenge Brent, lan kabeh karya liwat wong. Ing salah sawijining rapat, salah sawijining bawahan ditakoni: kenapa saben tugas setengah jam butuh seminggu? Jawaban kasebut minangka presentasi teori antrian lan hukum Little sing disederhanakake, lan ing presentasi iki ternyata ing 90% pendhudhuk, saben jam kerja butuh 9 jam. Saben tugas kudu dikirim menyang wong pitu liyane, supaya jam kasebut dadi 63 jam, 7 kaping 9. Apa sing dakkandhakake yaiku kanggo nggunakake Little's Law utawa teori antrian sing rumit, sampeyan kudu duwe data.
Dadi yen aku ngomong babagan visibilitas, aku ora ateges kabeh ana ing layar, nanging sampeyan duwe data paling ora. Nalika padha nindakake, iku kerep dadi metu sing ana jumlah gedhe banget karya unplanned sing piye wae dikirim menyang Brent nalika ana ora perlu. Lan Brent minangka wong sing apik banget, dheweke ora bakal ngomong ora, nanging dheweke ora ngandhani sapa wae carane nindakake tugase.
Nalika karya katon, data bisa diklasifikasikake kanthi rapi (iku sing ditindakake Dominika ing foto), abstraksi bocor limang wektu bisa ditrapake, lan otomatisasi bisa ditrapake.
2. Konsolidasi Sistem Manajemen Kerja: Manajemen Tugas
Arketipe sing dakkandhakake yaiku jinis piramida. Yen sing pisanan ditindakake kanthi bener, mula sing kapindho wis dadi tambahan. Akeh iki ora bisa kanggo wiwitan, padha kudu katahan ing atine kanggo perusahaan gedhe kaya Fortune 5000. Perusahaan pungkasan aku makarya kanggo 10 sistem tiket. Siji tim duwe Remedy, liyane nulis sawetara sistem dhewe, sing katelu digunakake Jira, lan sawetara digawe karo email. Masalah sing padha muncul yen perusahaan duwe 30 pipa sing beda, nanging aku ora duwe wektu kanggo ngrembug kabeh kasus kasebut.
Aku ngrembug karo wong persis carane karcis digawe, apa mengkono kanggo wong-wong mau sabanjuré, lan carane lagi circumvented. Sing paling menarik yaiku wong-wong ing rapat-rapat kita ngomong kanthi tulus. Aku takon carane akeh wong sijine "suntingan / ora impact" ing tiket sing kudu bener diwenehi "dampak gedhe". Pranyata meh kabeh wong nindakake iki. Aku ora melu denunciation lan nyoba ing kabeh cara bisa ora kanggo ngenali wong. Nalika padha tulus ngakoni marang aku, aku ora menehi wong kasebut. Nanging nalika meh kabeh wong nglewati sistem kasebut, tegese kabeh keamanan sejatine ditutupi jendhela. Mula, ora ana kesimpulan sing bisa dijupuk saka data sistem iki.
Kanggo ngatasi masalah tiket, sampeyan kudu milih siji sistem utama. Yen sampeyan nggunakake Jira, tetep Jira. Yen ana alternatif, mung siji. Intine yaiku tiket kudu dideleng minangka langkah liyane ing proses pangembangan. Saben tumindak kudu duwe tiket, sing kudu ngliwati alur kerja pangembangan. Tiket dikirim menyang tim, sing dikirim ing papan crita lan banjur tanggung jawab.
Iki ditrapake kanggo kabeh departemen, kalebu infrastruktur lan operasi. Ing kasus iki, iku bisa kanggo mbentuk paling sawetara idea masuk akal saka kahanan. Sawise proses iki ditetepake, dumadakan dadi gampang kanggo ngenali sing tanggung jawab kanggo saben aplikasi. Amarga saiki kita ora nampa 50%, nanging 98% layanan anyar. Yen proses inti iki bisa digunakake, akurasi nambah ing saindhenging sistem.
Layanan pipa
Iki maneh mung ditrapake kanggo perusahaan gedhe. Yen sampeyan perusahaan anyar ing lapangan anyar, gulungake lengen klambi lan nggarap Travis CI utawa CircleCI. Nalika nerangake perusahaan Fortune 5000, kasus sing kedadeyan ing bank sing aku kerja. Google teka menyang dheweke lan ditampilake diagram sistem IBM lawas. Wong lanang saka Google takon kanthi bingung - ngendi kode sumber iki? Nanging ora ana kode sumber, malah GUI. Iki minangka kasunyatan sing kudu ditindakake dening organisasi gedhe: cathetan bank 40 taun ing kerangka utama kuno. Salah sawijining klienku nggunakake wadhah Kubernetes kanthi pola Circuit Breaker, ditambah Chaos Monkey, kabeh kanggo aplikasi KeyBank. Nanging wadhah kasebut pungkasane nyambung menyang aplikasi COBOL.
Wong lanang saka Google pancen yakin bakal ngrampungake kabeh masalah klienku, banjur padha takon: apa datapipe IBM? Padha marang: iki konektor. Apa nyambungake? Kanggo sistem Sperry. Lan apa iku? Lan sateruse. Sepisanan katon: DevOps apa sing bisa ana? Nanging ing kasunyatan, iku bisa. Ana sistem pangiriman sing ngidini sampeyan nyerahake alur kerja menyang tim pangiriman.
3. Teori Watesan: Teori Watesan
Ayo pindhah menyang archetype katelu: kawruh institusional / "suku". Minangka aturan, ing organisasi apa wae ana sawetara wong sing ngerti kabeh lan ngatur kabeh. Iki minangka wong sing paling dawa ing organisasi lan ngerti kabeh solusi.
Nalika iki muncul ing diagram, aku khusus ngubengi wong-wong kasebut kanthi tandha: contone, ternyata Lou tartamtu ana ing kabeh rapat. Lan iku cetha kanggo kula: iki Brent lokal. Nalika CIO milih ing antarane aku nganggo kaos oblong lan sepatu olahraga lan wong lanang saka IBM nganggo setelan jas, aku dipilih amarga aku bisa ngandhani direktur apa wae sing ora bakal dicritakake wong liya lan direktur bisa uga ora seneng ngrungokake. . Aku pitutur marang wong-wong mau sing bottleneck ing perusahaan iku wong jenenge Fred lan wong jenenge Lou. Kemacetan iki kudu dirungokake, ilmune kudu dipikolehi kanthi cara apa wae.
Kanggo ngatasi masalah iki, aku bisa, contone, nyaranake nggunakake Slack. Sutradara sing pinter bakal takon - kenapa? Biasane, ing kasus kasebut, konsultan DevOps mangsuli: amarga kabeh wong nindakake. Yen direktur pancen pinter, dheweke bakal ngomong: apa. Lan ing kene dialog kasebut rampung. Lan jawabanku yaiku: amarga ana papat bottlenecks ing perusahaan, Fred, Lou, Susie lan Jane. Kanggo institusionalisasi kawruh, siji kudu ngenalake Slack. Kabeh wiki sampeyan pancen omong kosong amarga ora ana sing ngerti babagan orane. Yen tim teknik melu pembangunan ngarep lan mburi lan kabeh wong kudu ngerti yen dheweke bisa ngubungi tim pangembangan ngarep utawa tim infrastruktur kanthi pitakonan. Nalika iku Lou utawa Fred bakal duwe wektu kanggo gabung ing wiki. Banjur ing Slack ana wong sing takon kenapa, ucapake, langkah 5 ora bisa digunakake. Banjur Lou utawa Fred bakal mbenerake instruksi ing wiki. Yen sampeyan netepake proses iki, mula akeh perkara sing bakal ditindakake dhewe.
Iki minangka titik utamaku: kanggo menehi rekomendasi teknologi sing dhuwur, sampeyan kudu nggawe dhasar dhasar kasebut, lan iki bisa ditindakake kanthi solusi teknologi rendah sing wis diterangake. Yen sampeyan miwiti kanthi teknologi dhuwur lan ora nerangake apa sing dibutuhake, mula, minangka aturan, iki ora rampung kanthi apik. Salah sawijining klien nggunakake Azure ML, solusi sing murah banget lan gampang. Udakara 30% pitakone dijawab dening mesin sinau dhewe. Lan bab iki ditulis dening operator sing ora melu ing ilmu data, statistik utawa matématika. Iki penting. Biaya solusi kasebut minimal.
4. Kolaborasi hacks: Kolaborasi hacks
Arketipe kaping papat yaiku kabutuhan kanggo nglawan isolasi. Umume wong wis ngerti iki: pamisahan nyebabake permusuhan. Yen saben departemen ing lantai dhewe, lan wong ora intersect karo saben liyane ing sembarang cara, kajaba ing elevator, banjur musuhan antarane wong-wong mau muncul banget gampang. Nanging yen, ing nalisir, wong ing kamar sing padha karo saben liyane, dheweke langsung ninggalake. Nalika wong mbuwang sawetara tuduhan umum, contone, antarmuka kasebut ora bisa digunakake, ora ana sing luwih gampang kanggo dekonstruksi tuduhan kasebut. Programer sing nulis antarmuka mung kudu miwiti takon pitakon tartamtu, lan bakal dadi jelas manawa, umpamane, pangguna mung nggunakake alat kasebut kanthi ora bener.
Ana akeh cara kanggo ngatasi isolasi. Aku tau dijaluk takon bank ing Australia, nanging aku ora gelem amarga aku duwe anak loro lan bojo. Kabeh sing bisa daklakoni kanggo mbantu dheweke yaiku menehi rekomendasi crita grafis. Iki minangka bukti sing bisa ditindakake. Cara liyane sing menarik yaiku rapat kopi tanpa lemak. Ing organisasi gedhe, iki minangka pilihan sing apik kanggo nyebarake kawruh. Kajaba iku, sampeyan bisa nindakake devopsdays internal, hackathon, lan liya-liyane.
5. Pembinaan Kata
Kaya sing dakelingake ing wiwitan, aku ora bakal ngomong babagan iki dina iki. Yen sampeyan kasengsem, sampeyan bisa ndeleng .
Ana uga omongan sing apik babagan topik iki saka Mike Rother:
6. Berorientasi Pasar: organisasi berorientasi pasar
Ana macem-macem masalah ing kene. Contone, wong "I", wong "T" lan wong "E". "Aku" wong sing nindakake mung siji. Biasane ana ing organisasi kanthi departemen sing terisolasi. "T" iku nalika wong apik ing siji bab nanging uga apik ing sawetara liyane. "E" utawa malah "sisir" iku nalika wong wis akeh skills.
Hukum Conway dianggo ing kene (), sing ing wangun sing paling disederhanakake bisa kasebut ing ngisor iki: yen telung tim nggarap compiler, banjur asil bakal dadi compiler saka telung bagean. Mula, yen ana tingkat isolasi sing dhuwur ing sawijining organisasi, mula Kubernetes, Circuit breaker, ekstensibilitas API lan barang-barang mewah liyane ing organisasi iki bakal disusun kanthi cara sing padha karo organisasi kasebut. Strictly miturut Conway lan éwadéné kabeh geeks enom.
Solusi kanggo masalah iki wis diterangake kaping pirang-pirang. Ana, contone, archetypes organisasi diterangake dening Fernando Fernandez. Arsitèktur masalah sing dakkandhakake, kanthi pamisahan, yaiku arsitektur berorientasi fungsi. Jinis kapindho sing paling awon, arsitektur matriks, kekacoan saka loro liyane. Katelu yaiku apa sing katon ing paling wiwitan, lan perusahaan gedhe uga nyoba cocog karo jinis iki. Iku organisasi orientasi pasar. Ing kene kita ngoptimalake kanggo entuk respon paling cepet kanggo panjaluk pelanggan. Iki kadhangkala disebut organisasi flat.
Akeh wong njlèntrèhaké struktur iki ing macem-macem cara, Aku seneng tembung mbangun / mbukak tim, ing Amazon padha nyebataken loro tim pizza. Ing struktur iki, kabeh jinis "I" wong diklompokaké watara siji layanan, lan mboko sithik padha dadi nyedhaki ngetik "T", lan yen manajemen tengen ing panggonan, malah bisa dadi "E". Bantahan pisanan ing kene yaiku struktur kasebut ngemot unsur sing ora perlu. Napa sampeyan butuh panguji ing saben departemen yen sampeyan bisa duwe departemen penguji khusus? Aku mangsuli: biaya ekstra ing kasus iki yaiku rega kanggo kabeh organisasi dadi jinis "E" ing mangsa ngarep. Ing struktur iki, tester mboko sithik sinau babagan jaringan, arsitektur, desain, lsp. Akibaté, saben peserta ing organisasi ngerti kabeh sing kedadeyan ing organisasi. Yen sampeyan pengin ngerti carane skema iki bisa digunakake ing industri, waca .
7. auditor Shift-kiwa: audit awal ing siklus. Selaras karo aturan safety ing tampilan
Iki nalika tumindak sampeyan ora lulus tes mambu. Wong sing kerja kanggo sampeyan ora bodho. Yen, kaya ing conto ing ndhuwur, padha nyetel suntingan / ora ana impact nang endi wae, iki tahan telung taun, lan ora ana sing weruh apa-apa, banjur kabeh wong ngerti kanthi becik yen sistem kasebut ora bisa digunakake. Utawa conto liyane - papan penasehat owah-owahan, ing ngendi laporan kudu diajukake saben, ngomong, Rebo. Ana klompok wong sing kerja ing kana (ora dibayar kanthi apik) sing, miturut teori, kudu ngerti carane sistem kasebut bisa digunakake. Lan sajrone limang taun kepungkur, sampeyan bisa uga ngerteni manawa sistem kita pancen rumit banget. Lan lima utawa enem wong kudu nggawe keputusan babagan owah-owahan sing ora ditindakake lan ora ngerti apa-apa.
Mesthi, pendekatan iki ora bisa. Aku kudu nyingkirake perkara kasebut amarga wong-wong iki ora nglindhungi sistem kasebut. Kaputusan kudu digawe dening tim dhewe, amarga tim kudu tanggung jawab. Yen ora, kahanan paradoks muncul nalika manajer sing ora tau nulis kode sajrone urip ngandhani programmer suwene wektu kanggo nulis kode. Siji perusahaan sing aku kerjo duwe 7 papan sing beda-beda sing mriksa saben owah-owahan, kalebu papan arsitektur, papan produk, lsp. Malah ana wektu tunggu wajib, sanajan ana karyawan sing ngandhani yen sajrone sepuluh taun kerja, ora ana sing nolak owah-owahan sing ditindakake dening wong kasebut sajrone periode wajib iki.
Auditor kudu diundang kanggo gabung karo kita, lan ora nyingkirake. Marang wong-wong mau yen sampeyan nulis wadhah binar sing ora bisa diganti yen, yen lulus kabeh tes, tetep ora bisa diganti ing salawas-lawase. Marang wong-wong mau sing duwe pipeline minangka kode lan nerangake apa tegese. Tampilake skema ing ngisor iki: binar mung diwaca sing ora bisa diganti ing wadhah sing ngliwati kabeh tes kerentanan; banjur ora mung ora ana kang tutul, padha ora malah tutul sistem sing nggawe pipo, awit iku uga digawe dinamis. Aku duwe klien, Capital One, sing nggunakake Vault kanggo nggawe kaya blockchain. Auditor ora perlu nuduhake "resep" saka Chef; cukup kanggo nuduhake pamblokiran, saka ngendi jelas apa sing kedadeyan karo tiket Jira ing produksi lan sapa sing tanggung jawab.
Miturut , digawe ing 2018 dening Sonatype, ana 2017 milyar panjalukan download OSS ing 87.
Kerugian sing ditimbulake amarga kerentanan pancen ora bisa ditindakake. Kajaba iku, angka sing saiki sampeyan deleng ing ndhuwur ora kalebu biaya kesempatan. Apa DevSecOps kanthi ringkes? Ayo kula ngomong langsung yen aku ora kasengsem ngomong babagan carane sukses jeneng iki. Intine yaiku wiwit DevOps wis sukses, kita kudu nyoba nambah keamanan menyang pipa kasebut.
Conto saka urutan iki:
Iki dudu rekomendasi kanggo produk tartamtu, sanajan aku seneng kabeh. Aku kasebut minangka conto kanggo nuduhake yen DevOps, sing wiwitane adhedhasar paradigma organisasi ing industri, ngidini sampeyan ngotomatisasi saben tahapan karya ing produk.
Lan ora ana alesan kenapa kita ora bisa njupuk pendekatan sing padha kanggo keamanan.
Asile
Minangka kesimpulan, aku bakal menehi sawetara tips kanggo DevSecOps. Sampeyan kudu nyakup auditor ing proses nggawe sistem lan mbuwang wektu kanggo ngajari. Sampeyan kudu kerja sama karo auditor. Sabanjure, sampeyan kudu nindakake perang sing ora kejam nglawan positip palsu. Malah kanthi alat pindai kerentanan sing paling larang, sampeyan bisa nggawe kabiasaan ala banget ing antarane pangembang yen sampeyan ora ngerti rasio sinyal-ke-noise sampeyan. Pangembang bakal kepunjulen karo acara lan mung bakal mbusak. Yen sampeyan krungu bab crita Equifax, iku cukup akeh kedadeyan ing kono, ing ngendi tingkat tandha paling dhuwur ora digatekake. Kajaba iku, kerentanan kudu diterangake kanthi cara sing jelas babagan pengaruhe bisnis kasebut. Contone, sampeyan bisa ujar manawa iki minangka kerentanan sing padha karo crita Equifax. Kerentanan keamanan kudu dianggep padha karo masalah piranti lunak liyane, yaiku, kudu dilebokake ing proses DevOps sakabèhé. Sampeyan kudu bisa karo wong liwat Jira, Kanban, etc. Pangembang ora kudu mikir yen wong liya bakal nindakake iki - sebaliknya, kabeh wong kudu nindakake iki. Pungkasan, sampeyan kudu mbuwang energi kanggo nglatih wong.
link migunani
Mangkene sawetara obrolan saka konferensi DevOops sing bisa migunani kanggo sampeyan:
- Sergey Berdnikov, Artyom Kalichkin - Kisah sukses, utawa "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps ing skala: tragedi Yunani ing telung tumindak (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Deleng ing DevOops 2020 Moscow — ana uga akèh iku menarik ana.
Source: www.habr.com