Persoalan "bagaimana untuk melaksanakan devops" telah wujud selama bertahun-tahun, tetapi tidak banyak bahan yang baik. Kadang-kadang anda menjadi mangsa iklan daripada perunding yang tidak begitu bijak yang perlu menjual masa mereka, tidak kira bagaimana. Kadang-kadang ini adalah kata-kata yang samar-samar, sangat umum tentang bagaimana kapal-kapal syarikat mega membajak hamparan alam semesta. Persoalannya timbul: apakah kepentingan ini kepada kita? Pengarang yang dihormati, bolehkah anda merumuskan idea anda dengan jelas dalam senarai?
Semua ini berpunca daripada fakta bahawa tidak banyak amalan sebenar dan pemahaman hasil transformasi budaya syarikat telah terkumpul. Perubahan dalam budaya adalah perkara jangka panjang, yang hasilnya tidak akan muncul dalam seminggu atau sebulan. Kami memerlukan seseorang yang cukup umur untuk melihat bagaimana syarikat telah dibina dan gagal selama ini.
John Willis - salah seorang bapa DevOps. John mempunyai pengalaman berdekad-dekad bekerja dengan sejumlah besar syarikat. Baru-baru ini, John mula melihat corak tertentu yang berlaku apabila bekerja dengan setiap daripada mereka. Menggunakan arketaip ini, John membimbing syarikat pada laluan sebenar transformasi DevOps. Baca lebih lanjut mengenai arketaip ini dalam terjemahan laporannya daripada persidangan DevOops 2018.
Mengenai pembesar suara:
Lebih daripada 35 tahun dalam pengurusan IT, mengambil bahagian dalam penciptaan OpenCloud terdahulu di Canonical, mengambil bahagian dalam 10 permulaan, dua daripadanya telah dijual kepada Dell dan Docker. Pada masa ini beliau ialah Naib Presiden DevOps dan Amalan Digital di SJ Technologies.
Seterusnya ialah cerita dari sudut pandangan John.
Nama saya John Willis dan tempat paling mudah untuk mencari saya ialah di Twitter, . Saya mempunyai alias yang sama pada Gmail dan GitHub. A anda boleh mencari rakaman video laporan dan pembentangan saya untuk mereka.
Saya mempunyai banyak pertemuan dengan CIO pelbagai syarikat besar. Mereka sering mengadu bahawa mereka tidak faham apa itu DevOps, dan setiap orang yang cuba menerangkannya kepada mereka bercakap tentang sesuatu yang berbeza. Satu lagi aduan biasa ialah DevOps tidak berfungsi, walaupun nampaknya pengarah melakukan segala-galanya seperti yang dijelaskan kepada mereka. Kita bercakap tentang syarikat besar yang berusia lebih daripada seratus tahun. Selepas bercakap dengan mereka, saya membuat kesimpulan bahawa untuk banyak masalah, bukan teknologi tinggi yang paling sesuai, tetapi penyelesaian berteknologi rendah. Selama berminggu-minggu saya hanya bercakap dengan orang dari jabatan yang berbeza. Apa yang anda lihat dalam gambar pertama dalam siaran adalah projek terakhir saya, ini adalah rupa bilik selepas tiga hari bekerja.
Apakah itu DevOps?
Memang kalau tanya 10 orang berbeza, mereka akan bagi 10 jawapan berbeza. Tetapi inilah perkara yang menarik: kesemua sepuluh jawapan ini adalah betul. Tiada jawapan yang salah di sini. Saya sangat mendalami DevOps, selama kira-kira 10 tahun, dan merupakan orang Amerika pertama pada DevOpsDay yang pertama. Saya tidak akan mengatakan bahawa saya lebih bijak daripada semua orang yang terlibat dalam DevOps, tetapi hampir tidak ada orang yang telah menghabiskan banyak usaha untuknya. Saya percaya bahawa DevOps berlaku apabila modal insan dan teknologi bersatu. Kita sering lupa tentang dimensi manusia, walaupun kita banyak bercakap tentang semua jenis budaya.
Kini kami mempunyai banyak data, lima tahun penyelidikan akademik, ujian teori pada skala industri. Kajian ini memberitahu kami bahawa jika anda menggabungkan beberapa corak tingkah laku dalam budaya organisasi, anda boleh mendapatkan kelajuan 2000x. Pecutan ini dipadankan dengan peningkatan yang sama dalam kestabilan. Ini ialah ukuran kuantitatif manfaat yang boleh dibawa oleh DevOps kepada mana-mana syarikat. Beberapa tahun yang lalu, saya bercakap tentang DevOps kepada Ketua Pegawai Eksekutif sebuah syarikat Fortune 5000. Semasa saya membuat persediaan untuk pembentangan, saya sangat gementar kerana saya perlu meringkaskan pengalaman bertahun-tahun saya dalam masa 5 minit.
Pada akhirnya saya memberikan yang berikut Definisi DevOps: Ia adalah satu set amalan dan corak yang membolehkan transformasi modal insan kepada modal organisasi berprestasi tinggi. Contohnya ialah cara Toyota beroperasi selama 50 atau 60 tahun yang lalu.
(Selepas ini, gambar rajah tersebut disediakan bukan sebagai bahan rujukan, tetapi sebagai ilustrasi. Kandungannya akan berbeza untuk setiap syarikat baharu. Walau bagaimanapun, gambar tersebut boleh dilihat secara berasingan dan diperbesarkan
Salah satu amalan yang paling berjaya adalah nilai aliran pemetaan. Beberapa buku bagus telah ditulis mengenai perkara ini, yang paling berjaya adalah oleh Karen Martin. Tetapi sepanjang tahun lalu, saya telah membuat kesimpulan bahawa pendekatan ini terlalu berteknologi tinggi. Ia sememangnya mempunyai banyak kelebihan dan saya telah banyak menggunakannya. Tetapi apabila Ketua Pegawai Eksekutif bertanya kepada anda mengapa syarikatnya tidak boleh bertukar kepada landasan baharu, masih terlalu awal untuk bercakap tentang pemetaan aliran nilai. Terdapat banyak lagi soalan asas yang mesti dijawab terlebih dahulu.
Saya rasa kesilapan yang dilakukan oleh ramai rakan sekerja saya ialah mereka hanya memberi syarikat panduan lima mata dan kemudian kembali enam bulan kemudian dan melihat apa yang berlaku. Malah skim yang baik seperti pemetaan aliran nilai mempunyai, katakan, titik buta. Selepas beratus-ratus temu bual dengan pengarah pelbagai syarikat, saya telah membangunkan corak tertentu yang membolehkan kita memecahkan masalah kepada komponennya, dan kini kita akan membincangkan setiap komponen ini mengikut urutan. Sebelum menggunakan sebarang penyelesaian teknologi, saya menggunakan corak ini, dan sebagai hasilnya, semua dinding saya ditutup dengan gambar rajah. Baru-baru ini saya bekerja dengan dana bersama dan saya mendapat 100-150 skim sedemikian.
Budaya buruk memakan pendekatan yang baik untuk sarapan pagi
Idea utama ialah ini: tiada jumlah Lean, Agile, SAFE dan DevOps akan membantu jika budaya organisasi itu sendiri buruk. Ia seperti menyelam ke kedalaman tanpa peralatan skuba atau beroperasi tanpa x-ray. Dengan kata lain, untuk menghuraikan Drucker dan Deming: budaya organisasi yang buruk akan menelan mana-mana sistem yang baik tanpa mencekiknya.
Untuk menyelesaikan masalah utama ini, anda perlu mengambil langkah berikut:
- Jadikan Semua Kerja Terlihat: anda perlu membuat semua kerja kelihatan. Bukan dalam erti kata bahawa ia semestinya mesti dipaparkan pada beberapa skrin, tetapi dalam erti kata ia mesti boleh diperhatikan.
- Sistem Pengurusan Kerja Disatukan: sistem pengurusan perlu disatukan. Dalam masalah pengetahuan "puak" dan pengetahuan institusi, dalam 9 kes daripada 10 kesesakan adalah orang. Dalam buku masalahnya adalah dengan seorang bujang, Brent, yang menyebabkan projek itu ketinggalan tiga tahun dari jadual. Dan saya bertemu dengan "Brents" ini di mana-mana. Untuk menyelesaikan kesesakan ini, saya menggunakan dua item seterusnya dalam senarai kami.
- Metodologi Teori Kekangan: teori kekangan.
- Godam kerjasama: godam kerjasama.
- Toyota Kata (): Saya tidak akan bercakap banyak tentang Toyota Kata. Jika berminat, di github saya pada hampir setiap satu daripada topik ini.
- Organisasi Berorientasikan Pasaran: organisasi berorientasikan pasaran.
- Juruaudit beralih ke kiri: audit pada peringkat awal kitaran.
Saya mula bekerja dengan organisasi dengan sangat mudah: Saya pergi ke syarikat dan bercakap dengan pekerja. Seperti yang anda lihat, tiada teknologi tinggi. Apa yang anda perlukan hanyalah sesuatu untuk ditulis. Saya mengumpulkan beberapa pasukan dalam satu bilik dan menganalisis apa yang mereka beritahu saya dari perspektif 7 arketaip saya. Dan kemudian saya memberi mereka penanda sendiri dan meminta mereka menulis di papan tulis semua yang mereka katakan dengan lantang setakat ini. Biasanya dalam mesyuarat jenis ini ada seorang yang menulis segala-galanya, dan paling baik dia boleh menulis 10% daripada perbincangan. Dengan kaedah saya, angka ini boleh dinaikkan kepada kira-kira 40%.
(Ilustrasi ini boleh dilihat secara berasingan )
Pendekatan saya adalah berdasarkan karya William Schneider. ). Pendekatan ini berdasarkan idea bahawa mana-mana organisasi boleh dibahagikan kepada empat petak. Skim ini bagi saya biasanya hasil daripada bekerja dengan beratus-ratus skim lain yang timbul semasa menganalisis organisasi. Katakan kita mempunyai organisasi yang mempunyai tahap kawalan yang tinggi, tetapi dengan kecekapan yang rendah. Ini adalah pilihan yang sangat tidak diingini: apabila semua orang mengikut garisan, tetapi tiada siapa yang tahu apa yang perlu dilakukan.
Pilihan yang lebih baik sedikit ialah pilihan yang mempunyai tahap kawalan dan kecekapan yang tinggi. Jika syarikat sedemikian menguntungkan, maka mungkin ia tidak memerlukan DevOps. Paling menarik untuk bekerja dengan syarikat yang mempunyai tahap kawalan yang tinggi, kecekapan dan kerjasama yang rendah, tetapi pada masa yang sama tahap budaya (penanaman) yang tinggi. Ini bermakna syarikat itu mempunyai ramai orang yang suka bekerja di sana dan perolehan buruh adalah rendah.
(Ilustrasi ini boleh dilihat secara berasingan )
Nampaknya pada saya kaedah dengan garis panduan yang tegar akhirnya menghalang jalan untuk mencapai kebenaran. Dalam pemetaan aliran nilai khususnya, terdapat banyak peraturan mengenai cara maklumat harus distrukturkan. Pada peringkat awal kerja, yang saya bincangkan sekarang, tiada siapa yang memerlukan peraturan ini. Jika seseorang dengan penanda di tangannya menerangkan keadaan sebenar dalam syarikat di papan, ini adalah cara terbaik untuk memahami keadaan hal ehwal. Maklumat sedemikian tidak sampai kepada pengarah. Pada masa ini, adalah bodoh untuk mengganggu orang itu dan mengatakan bahawa dia melukis beberapa jenis anak panah dengan salah. Pada peringkat ini, lebih baik menggunakan peraturan mudah, sebagai contoh: abstraksi pelbagai peringkat boleh dibuat hanya dengan menggunakan penanda pelbagai warna.
Saya ulangi, tiada teknologi tinggi. Penanda hitam menggambarkan realiti objektif bagaimana semuanya berfungsi. Dengan penanda merah, orang ramai menandakan perkara yang mereka tidak suka tentang keadaan semasa. Yang penting mereka menulis ini, bukan saya. Apabila saya pergi ke CIO selepas mesyuarat, saya tidak menawarkan senarai 10 perkara yang perlu diperbaiki. Saya berusaha untuk mencari perkaitan antara perkara yang diperkatakan oleh orang dalam syarikat dan corak terbukti sedia ada. Akhir sekali, penanda biru mencadangkan penyelesaian yang mungkin untuk masalah tersebut.
(Ilustrasi ini boleh dilihat secara berasingan )
Contoh pendekatan ini kini digambarkan di atas. Pada awal tahun ini saya bekerja dengan satu bank. Orang keselamatan di sana yakin bahawa mereka tidak sepatutnya datang untuk reka bentuk dan semakan keperluan.
(Ilustrasi ini boleh dilihat secara berasingan )
Dan kemudian kami bercakap dengan orang dari jabatan lain dan ternyata kira-kira 8 tahun yang lalu, pembangun perisian memecat pekerja keselamatan kerana mereka melambatkan kerja. Dan kemudian ia berubah menjadi larangan, yang diambil begitu sahaja. Walaupun pada hakikatnya tidak ada larangan.
Pertemuan kami berjalan dengan cara yang sangat mengelirukan: selama kira-kira tiga jam, lima pasukan berbeza tidak dapat menjelaskan kepada saya apa yang berlaku antara kod dan perhimpunan. Dan ini nampaknya menjadi perkara yang paling mudah. Kebanyakan perunding DevOps beranggapan bahawa semua orang sudah mengetahui perkara ini.
Kemudian orang yang bertanggungjawab dalam tadbir urus IT, yang telah berdiam diri selama empat jam, tiba-tiba hidup apabila kami sampai ke topiknya, dan menduduki kami untuk masa yang sangat lama. Pada akhirnya saya bertanya kepadanya apa yang dia fikir tentang pertemuan itu, dan saya tidak akan melupakan jawapannya. Dia berkata: "Saya pernah berfikir bahawa bank kami hanya mempunyai dua cara untuk menyampaikan perisian, tetapi sekarang saya tahu bahawa terdapat lima daripadanya, dan saya tidak tahu tentang tiga."
(Ilustrasi ini boleh dilihat secara berasingan )
Pertemuan terakhir di bank ini adalah dengan pasukan perisian pelaburan. Bersamanya ternyata menulis gambar rajah dengan penanda pada helaian kertas adalah lebih baik daripada di papan, dan lebih baik daripada di papan pintar.
Foto yang anda lihat adalah rupa bilik persidangan hotel pada hari keempat mesyuarat kami. Dan kami menggunakan skema ini untuk mencari corak, iaitu, archetypes.
Jadi, saya bertanya soalan pekerja, mereka menulis jawapan dengan penanda tiga warna (hitam, merah dan biru). Saya menganalisis jawapan mereka untuk archetypes. Sekarang mari kita bincangkan semua arketaip mengikut urutan.
1. Jadikan Semua Kerja Nampak: Jadikan kerja boleh dilihat
Kebanyakan syarikat yang bekerja dengan saya mempunyai peratusan kerja yang tidak diketahui yang sangat tinggi. Sebagai contoh, ini adalah apabila seorang pekerja datang kepada pekerja lain dan hanya meminta untuk melakukan sesuatu. Dalam organisasi besar, mungkin terdapat 60% kerja yang tidak dirancang. Dan sehingga 40% daripada kerja tidak didokumenkan dalam apa cara sekalipun. Jika Boeing, saya tidak akan menaiki pesawat mereka lagi seumur hidup saya. Jika hanya separuh daripada kerja yang didokumenkan, maka tidak diketahui sama ada kerja ini dilakukan dengan betul atau tidak. Semua kaedah lain ternyata tidak berguna - tidak ada gunanya cuba mengautomasikan apa-apa, kerana 50% yang diketahui mungkin merupakan bahagian kerja yang paling koheren dan jelas, automasi yang tidak akan memberikan hasil yang hebat, dan semua yang paling teruk. benda berada dalam separuh yang tidak kelihatan. Dengan ketiadaan dokumentasi, adalah mustahil untuk mencari pelbagai jenis penggodaman dan kerja tersembunyi, bukan untuk mencari kesesakan, "Brents" yang telah saya bincangkan. Terdapat sebuah buku yang menarik oleh Dominica DeGrandis . Dia mendedahkan lima "kebocoran masa" berbeza (pencuri masa):
- Terlalu Banyak Kerja dalam Proses (WIP)
- Ketergantungan Tidak Diketahui
- Kerja Tidak Terancang
- Keutamaan yang bercanggah
- Kerja Terabai
Ini adalah analisis yang sangat berharga dan buku itu hebat, tetapi semua nasihat ini tidak berguna jika hanya 50% daripada data yang dapat dilihat. Kaedah yang dicadangkan oleh Dominica boleh digunakan jika ketepatan melebihi 90% dicapai. Saya bercakap tentang situasi di mana bos memberikan tugasan 15 minit kepada bawahan, tetapi ia mengambil masa tiga hari; tapi bos tak tahu sangat yang orang bawahan ni bergantung pada empat lima orang lagi.
Projek Phoenix ialah cerita indah tentang projek yang terlambat tiga tahun. Salah satu watak menghadapi pemecatan kerana ini, dan dia bertemu dengan watak lain yang dipersembahkan sebagai sejenis Socrates. Dia membantu untuk mengetahui apa yang sebenarnya berlaku. Ternyata syarikat itu mempunyai satu pentadbir sistem, yang namanya Brent, dan semua kerja entah bagaimana melaluinya. Di salah satu mesyuarat, salah seorang pegawai bawahan ditanya: mengapa setiap tugas setengah jam mengambil masa seminggu? Jawapannya ialah pembentangan teori beratur dan undang-undang Little yang sangat dipermudahkan, dan dalam pembentangan ini ternyata pada 90% penghunian, setiap jam bekerja mengambil masa 9 jam. Setiap tugasan perlu dihantar kepada tujuh orang lain, supaya jam itu menjadi 63 jam, 7 kali 9. Perkara yang saya nyatakan ialah untuk menggunakan Undang-undang Kecil atau mana-mana teori giliran kompleks, anda sekurang-kurangnya perlu mempunyai data.
Jadi apabila saya bercakap tentang keterlihatan, saya tidak bermaksud bahawa segala-galanya ada pada skrin, tetapi anda sekurang-kurangnya mempunyai data. Apabila mereka melakukannya, sering ternyata terdapat sejumlah besar kerja yang tidak dirancang yang entah bagaimana dihantar kepada Brent apabila tidak diperlukan. Dan Brent adalah lelaki yang hebat, dia tidak akan pernah berkata tidak, tetapi dia tidak memberitahu sesiapa cara dia melakukan tugasnya.
Apabila kerja dapat dilihat, data boleh diklasifikasikan dengan kemas (itulah yang dilakukan oleh Dominique dalam foto), abstraksi kebocoran lima masa boleh digunakan, dan automasi boleh digunakan.
2. Menyatukan Sistem Pengurusan Kerja: Pengurusan Tugas
Arketiip yang saya maksudkan adalah sejenis piramid. Jika yang pertama dilakukan dengan betul, maka yang kedua sudah menjadi semacam add-on. Kebanyakan ini tidak berfungsi untuk pemula, mereka perlu diingat untuk syarikat yang lebih besar seperti Fortune 5000. Syarikat terakhir yang saya bekerja mempunyai 10 sistem tiket. Satu pasukan mempunyai Remedy, satu lagi menulis beberapa jenis sistemnya sendiri, satu lagi menggunakan Jira, dan beberapa lagi menggunakan e-mel. Masalah yang sama timbul jika syarikat mempunyai 30 saluran paip yang berbeza, tetapi saya tidak mempunyai masa untuk membincangkan semua kes sedemikian.
Saya berbincang dengan orang ramai tentang cara tiket dibuat, apa yang berlaku kepada mereka seterusnya, dan cara ia dielakkan. Perkara yang paling menarik ialah orang di mesyuarat kami bercakap dengan agak ikhlas. Saya bertanya berapa ramai yang meletakkan "minor / no impact" pada tiket yang sepatutnya diberi "major impact". Ternyata hampir semua orang melakukan ini. Saya tidak terlibat dalam pengecaman dan cuba dalam setiap cara yang mungkin untuk tidak mengenal pasti orang. Apabila mereka dengan ikhlas mengaku sesuatu kepada saya, saya tidak memberikan orang itu. Tetapi apabila hampir semua orang memintas sistem, ini bermakna semua keselamatan pada dasarnya adalah pembalut tingkap. Oleh itu, tiada kesimpulan yang boleh dibuat daripada data sistem ini.
Untuk menyelesaikan masalah tiket, anda perlu memilih satu sistem utama. Kalau pakai Jira, simpan Jira. Jika ada alternatif, biarlah satu-satunya. Intinya ialah tiket harus dilihat sebagai satu lagi langkah dalam proses pembangunan. Setiap tindakan mesti mempunyai tiket, yang mesti mengalir melalui aliran kerja pembangunan. Tiket dihantar kepada pasukan, yang menyiarkannya di papan cerita dan kemudian bertanggungjawab ke atasnya.
Ini terpakai kepada semua jabatan, termasuk infrastruktur dan operasi. Dalam kes ini, adalah mungkin untuk membentuk sekurang-kurangnya beberapa idea yang munasabah tentang keadaan. Sebaik sahaja proses ini ditubuhkan, tiba-tiba menjadi mudah untuk mengenal pasti siapa yang bertanggungjawab untuk setiap permohonan. Kerana sekarang kami tidak menerima 50%, tetapi 98% perkhidmatan baharu. Jika proses teras ini berfungsi, maka ketepatan bertambah baik di seluruh sistem.
Saluran paip perkhidmatan
Ini sekali lagi hanya terpakai kepada syarikat besar. Jika anda syarikat baharu dalam bidang baharu, singsingkan lengan baju anda dan bekerjasama dengan Travis CI atau CircleCI anda. Apabila bercakap mengenai syarikat Fortune 5000, satu kes yang berlaku di bank tempat saya bekerja. Google datang kepada mereka dan mereka ditunjukkan gambar rajah sistem IBM lama. Lelaki dari Google bertanya dalam kekeliruan - di manakah kod sumber untuk ini? Tetapi tiada kod sumber, walaupun GUI. Inilah realiti yang perlu dihadapi oleh organisasi besar: rekod bank berusia 40 tahun pada kerangka utama purba. Salah seorang pelanggan saya menggunakan bekas Kubernetes dengan corak Pemutus Litar, serta Chaos Monkey, semuanya untuk aplikasi KeyBank. Tetapi bekas ini akhirnya bersambung ke aplikasi COBOL.
Lelaki dari Google benar-benar yakin bahawa mereka akan menyelesaikan semua masalah pelanggan saya, dan kemudian mereka mula bertanya soalan: apakah itu paip data IBM? Mereka diberitahu: ini adalah penyambung. Apakah sambungnya? Kepada sistem Sperry. Dan apa itu? Dan sebagainya. Pada pandangan pertama nampaknya: apakah jenis DevOps yang boleh ada? Tetapi sebenarnya, ia mungkin. Terdapat sistem penghantaran yang membolehkan anda menyerahkan aliran kerja kepada pasukan penghantaran.
3. Teori Kekangan: Teori Kekangan
Mari kita beralih kepada archetype ketiga: pengetahuan institusi/"puak". Sebagai peraturan, dalam mana-mana organisasi terdapat beberapa orang yang mengetahui segala-galanya dan menguruskan segala-galanya. Mereka ini adalah mereka yang paling lama berada dalam organisasi dan mengetahui semua penyelesaiannya.
Apabila perkara ini muncul pada rajah, saya secara khusus membulatkan orang sedemikian dengan penanda: sebagai contoh, ternyata Lou tertentu hadir pada semua mesyuarat. Dan ia jelas kepada saya: ini Brent tempatan. Apabila CIO memilih antara saya berbaju T dan kasut dan lelaki dari IBM dalam sut, saya dipilih kerana saya boleh memberitahu pengarah perkara yang lelaki lain tidak akan beritahu dan pengarah mungkin tidak suka mendengar . Saya memberitahu mereka bahawa halangan dalam syarikat mereka ialah seseorang bernama Fred dan seseorang bernama Lou. Kesesakan ini perlu dirungkai, pengetahuan mereka perlu diperoleh daripada mereka satu cara atau yang lain.
Untuk menyelesaikan masalah seperti ini, saya boleh, sebagai contoh, mencadangkan menggunakan Slack. Seorang pengarah yang bijak akan bertanya - kenapa? Biasanya, dalam kes sedemikian, perunding DevOps menjawab: kerana semua orang melakukannya. Jika pengarah itu benar-benar bijak, dia akan berkata: jadi apa. Dan di sinilah dialog berakhir. Dan jawapan saya untuk ini ialah: kerana terdapat empat kesesakan dalam syarikat itu, Fred, Lou, Susie dan Jane. Untuk menginstitusikan pengetahuan mereka, seseorang mesti memperkenalkan Slack terlebih dahulu. Semua wiki anda adalah karut sepenuhnya kerana tiada siapa yang tahu tentang kewujudannya. Jika pasukan kejuruteraan terlibat dalam pembangunan bahagian hadapan dan belakang dan semua orang perlu tahu bahawa mereka boleh menghubungi pasukan pembangunan bahagian hadapan atau pasukan infrastruktur dengan soalan. Pada masa itulah Lou atau Fred mungkin mempunyai masa untuk menyertai wiki. Dan kemudian dalam Slack seseorang mungkin bertanya mengapa, katakan, langkah 5 tidak berfungsi. Kemudian Lou atau Fred akan membetulkan arahan pada wiki. Jika anda menetapkan proses ini, maka banyak perkara akan berlaku dengan sendirinya.
Ini adalah perkara utama saya: untuk mengesyorkan mana-mana teknologi tinggi, anda mesti meletakkan asas untuknya dengan teratur, dan ini boleh dilakukan dengan penyelesaian teknologi rendah yang baru diterangkan. Jika anda bermula dengan teknologi tinggi dan tidak menjelaskan mengapa ia diperlukan, maka, sebagai peraturan, ini tidak berakhir dengan baik. Salah seorang pelanggan kami menggunakan Azure ML, penyelesaian yang sangat murah dan mudah. Kira-kira 30% daripada soalan mereka telah dijawab oleh mesin pembelajaran kendiri itu sendiri. Dan perkara ini ditulis oleh operator yang tidak terlibat dalam sains data, statistik atau matematik. Ini penting. Kos penyelesaian sedemikian adalah minimum.
4. Godam kerjasama: Godam kerjasama
Arketip keempat ialah keperluan untuk memerangi pengasingan. Kebanyakan orang sudah mengetahui perkara ini: pengasingan menimbulkan permusuhan. Jika setiap jabatan berada di tingkatnya sendiri, dan orang tidak bersilang antara satu sama lain dalam apa cara sekalipun, kecuali dalam lif, maka permusuhan antara mereka timbul dengan mudah. Tetapi jika, sebaliknya, orang berada di dalam bilik yang sama antara satu sama lain, dia segera pergi. Apabila seseorang melemparkan beberapa tuduhan umum, sebagai contoh, antara muka ini dan itu tidak pernah berfungsi, tidak ada yang lebih mudah untuk merungkai tuduhan tersebut. Pengaturcara yang menulis antara muka hanya perlu mula bertanya soalan khusus, dan tidak lama lagi akan menjadi jelas bahawa, sebagai contoh, pengguna hanya menggunakan alat itu dengan tidak betul.
Terdapat banyak cara untuk mengatasi pengasingan. Saya pernah diminta untuk berunding untuk sebuah bank di Australia, tetapi saya enggan melakukannya kerana saya mempunyai dua anak dan seorang isteri. Apa yang boleh saya lakukan untuk membantu mereka ialah mengesyorkan penceritaan grafik. Ini adalah sesuatu yang terbukti berkesan. Satu lagi cara yang menarik ialah mesyuarat kopi tanpa lemak. Dalam organisasi yang besar, ini adalah pilihan terbaik untuk menyebarkan pengetahuan. Di samping itu, anda boleh menjalankan devopsdays dalaman, hackathon, dan sebagainya.
5. Coaching Kata
Seperti yang saya amaran pada awal-awal lagi, saya tidak akan bercakap tentang perkara ini hari ini. Kalau berminat boleh tengok .
Terdapat juga ceramah yang baik mengenai topik ini dari Mike Rother:
6. Berorientasikan Pasaran: organisasi berorientasikan pasaran
Terdapat pelbagai masalah di sini. Contohnya, orang "I", orang "T" dan orang "E". Orang "saya" adalah mereka yang melakukan hanya satu perkara. Biasanya mereka wujud dalam organisasi dengan jabatan terpencil. "T" ialah apabila seseorang itu pandai dalam satu perkara tetapi juga pandai dalam beberapa perkara lain. "E" atau pun "comb" ialah apabila seseorang itu mempunyai banyak kemahiran.
Undang-undang Conway berfungsi di sini (), yang dalam bentuk yang paling mudah boleh dinyatakan seperti berikut: jika tiga pasukan bekerja pada pengkompil, maka hasilnya akan menjadi penyusun tiga bahagian. Oleh itu, jika terdapat tahap pengasingan yang tinggi dalam organisasi, malah Kubernetes, Pemutus Litar, kebolehlanjutan API dan perkara-perkara mewah lain dalam organisasi ini akan diatur dengan cara yang sama seperti organisasi itu sendiri. Tegasnya mengikut Conway dan walaupun anda semua geeks muda.
Penyelesaian kepada masalah ini telah diterangkan berkali-kali. Terdapat, sebagai contoh, arketaip organisasi yang diterangkan oleh Fernando Fernandez. Seni bina bermasalah yang baru saya bincangkan, dengan pengasingan, adalah seni bina berorientasikan fungsi. Jenis kedua adalah yang paling teruk, seni bina matriks, kucar-kacir daripada dua yang lain. Yang ketiga ialah apa yang dilihat dalam kebanyakan pemula, dan syarikat besar juga cuba memadankan jenis ini. Ia adalah organisasi yang berorientasikan pasaran. Di sini kami mengoptimumkan untuk mencapai respons terpantas kepada permintaan pelanggan. Ini kadang-kadang dipanggil organisasi rata.
Ramai orang menerangkan struktur ini dengan cara yang berbeza, saya suka kata-katanya membina/menjalankan pasukan, di Amazon mereka memanggilnya dua pasukan pizza. Dalam struktur ini, semua orang jenis "I" dikumpulkan di sekitar satu perkhidmatan, dan secara beransur-ansur mereka menjadi lebih dekat dengan jenis "T", dan jika pengurusan yang betul disediakan, mereka juga boleh menjadi "E". Hujah balas pertama di sini ialah struktur sedemikian mengandungi unsur-unsur yang tidak perlu. Mengapa anda memerlukan penguji di setiap jabatan jika anda boleh mempunyai jabatan penguji khas? Yang saya jawab: kos tambahan dalam kes ini ialah harga untuk keseluruhan organisasi menjadi jenis "E" pada masa hadapan. Dalam struktur ini, penguji secara beransur-ansur belajar tentang rangkaian, seni bina, reka bentuk, dsb. Hasilnya, setiap peserta dalam organisasi mengetahui sepenuhnya segala yang berlaku dalam organisasi. Jika anda ingin tahu bagaimana skim ini berfungsi dalam industri, baca .
7. Juruaudit beralih ke kiri: audit awal dalam kitaran. Pematuhan peraturan keselamatan yang dipamerkan
Ini adalah apabila tindakan anda tidak lulus ujian bau, boleh dikatakan. Orang yang bekerja untuk anda tidak bodoh. Jika, seperti dalam contoh di atas, mereka menetapkan impak kecil/tiada di mana-mana, ini berlangsung selama tiga tahun, dan tiada siapa yang perasan apa-apa, maka semua orang tahu dengan baik bahawa sistem itu tidak berfungsi. Atau contoh lain - papan penasihat perubahan, di mana laporan perlu diserahkan setiap, katakan, Rabu. Terdapat sekumpulan orang yang bekerja di sana (dengan cara ini tidak dibayar dengan sangat baik) yang, secara teori, harus tahu bagaimana sistem secara keseluruhan berfungsi. Dan sepanjang lima tahun yang lalu, anda mungkin perasan bahawa sistem kami adalah sangat kompleks. Dan lima atau enam orang perlu membuat keputusan tentang perubahan yang tidak mereka lakukan dan yang mereka tidak tahu apa-apa.
Sudah tentu, pendekatan ini tidak berfungsi. Saya perlu menyingkirkan perkara sedemikian kerana mereka ini tidak melindungi sistem. Keputusan mesti dibuat oleh pasukan sendiri, kerana pasukan mesti bertanggungjawab ke atasnya. Jika tidak, situasi paradoks timbul apabila pengurus yang tidak pernah menulis kod dalam hidupnya memberitahu pengaturcara berapa lama masa yang diperlukan untuk menulis kod. Satu syarikat yang saya bekerjasama mempunyai 7 papan berbeza yang menyemak setiap perubahan, termasuk papan seni bina, papan produk, dsb. Malah terdapat tempoh menunggu yang wajib, walaupun seorang pekerja memberitahu saya bahawa dalam sepuluh tahun bekerja, tiada siapa yang pernah menolak perubahan yang dibuat oleh orang ini dalam tempoh wajib ini.
Juruaudit perlu dijemput untuk menyertai kami, dan bukan menyingkirkan mereka. Beritahu mereka bahawa anda menulis bekas binari tidak berubah yang, jika mereka lulus semua ujian, kekal tidak berubah selama-lamanya. Beritahu mereka bahawa anda mempunyai saluran paip sebagai kod dan terangkan maksudnya. Tunjukkan kepada mereka skema berikut: binari baca sahaja yang tidak boleh diubah dalam bekas yang melepasi semua ujian kerentanan; dan kemudian bukan sahaja tiada sesiapa yang menyentuhnya, mereka juga tidak menyentuh sistem yang mencipta saluran paip, kerana ia juga dicipta secara dinamik. Saya mempunyai pelanggan, Capital One, yang menggunakan Vault untuk mencipta sesuatu seperti blockchain. Juruaudit tidak perlu menunjukkan "resipi" daripada Chef; ia sudah cukup untuk menunjukkan blokchain, dari mana jelas apa yang berlaku kepada tiket Jira dalam pengeluaran dan siapa yang bertanggungjawab untuknya.
Menurut , yang dicipta pada 2018 oleh Sonatype, terdapat 2017 bilion permintaan muat turun OSS pada 87.
Kerugian yang ditanggung akibat kelemahan adalah terlalu besar. Selain itu, angka yang anda lihat sekarang di atas tidak termasuk kos peluang. Apa itu DevSecOps secara ringkas? Biar saya katakan dengan segera bahawa saya tidak berminat untuk bercakap tentang kejayaan nama ini. Intinya ialah memandangkan DevOps telah begitu berjaya, kita harus cuba menambah keselamatan pada saluran paip itu.
Contoh urutan ini:
Ini bukan cadangan untuk produk tertentu, walaupun saya suka semuanya. Saya memetiknya sebagai contoh untuk menunjukkan bahawa DevOps, yang pada mulanya berdasarkan paradigma organisasi dalam industri, membolehkan anda mengautomasikan setiap peringkat kerja pada produk.
Dan tiada sebab mengapa kami tidak boleh mengambil pendekatan yang sama terhadap keselamatan.
Jumlah
Sebagai kesimpulan, saya akan memberikan beberapa petua untuk DevSecOps. Anda perlu memasukkan juruaudit dalam proses mencipta sistem anda dan meluangkan masa untuk mendidik mereka. Anda perlu bekerjasama dengan juruaudit. Seterusnya, anda perlu melancarkan perjuangan yang sangat kejam terhadap positif palsu. Walaupun dengan alat pengimbasan kerentanan yang paling mahal, anda akhirnya boleh mencipta tabiat yang sangat buruk dalam kalangan pembangun anda jika anda tidak mengetahui nisbah isyarat kepada hingar anda. Pembangun akan menjadi terharu dengan acara dan hanya akan memadamkannya. Jika anda mendengar tentang cerita Equifax, itulah yang berlaku di sana, di mana tahap amaran tertinggi diabaikan. Selain itu, kelemahan perlu dijelaskan dengan cara yang menjelaskan cara ia memberi kesan kepada perniagaan. Sebagai contoh, anda boleh mengatakan bahawa ini adalah kelemahan yang sama seperti dalam cerita Equifax. Kerentanan keselamatan harus dilayan sama seperti isu perisian lain, iaitu, ia harus disertakan dalam keseluruhan proses DevOps. Anda perlu bekerjasama dengan mereka melalui Jira, Kanban, dsb. Pemaju tidak sepatutnya berfikir bahawa orang lain akan melakukan ini - sebaliknya, semua orang harus melakukan ini. Akhir sekali, anda perlu menghabiskan tenaga untuk melatih orang.
Pautan berguna
Berikut ialah beberapa ceramah daripada persidangan DevOops yang mungkin berguna kepada anda:
- Sergey Berdnikov, Artyom Kalichkin - Kisah kejayaan, atau βDev+DevOps+Opsβ (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps pada skala: tragedi Yunani dalam tiga tindakan (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Melihat kedalam DevOops 2020 Moscow β terdapat juga banyak perkara menarik di sana.
Sumber: www.habr.com