Pertanyaan “bagaimana menerapkan devops” telah ada selama bertahun-tahun, namun tidak banyak materi yang bagus. Terkadang Anda menjadi korban iklan dari konsultan yang tidak terlalu pintar yang perlu menjual waktu mereka, bagaimanapun caranya. Kadang-kadang ini adalah kata-kata yang tidak jelas dan sangat umum tentang bagaimana kapal-kapal perusahaan besar mengarungi luasnya alam semesta. Timbul pertanyaan: apa pentingnya hal ini bagi kita? Penulis yang terhormat, dapatkah Anda merumuskan ide-ide Anda dengan jelas dalam sebuah daftar?
Semua ini berasal dari kenyataan bahwa tidak banyak praktik nyata dan pemahaman tentang hasil transformasi budaya perusahaan yang terkumpul. Perubahan budaya merupakan hal yang bersifat jangka panjang, yang hasilnya tidak akan terlihat dalam seminggu atau sebulan. Kita membutuhkan seseorang yang cukup umur untuk melihat bagaimana perusahaan dibangun dan gagal selama bertahun-tahun.
John Willis - salah satu bapak DevOps. John memiliki pengalaman puluhan tahun bekerja dengan banyak perusahaan. Baru-baru ini, John mulai memperhatikan pola-pola spesifik yang terjadi ketika bekerja dengan masing-masing pola tersebut. Dengan menggunakan arketipe ini, John memandu perusahaan menuju jalur transformasi DevOps yang sebenarnya. Baca selengkapnya tentang arketipe ini dalam terjemahan laporannya dari konferensi DevOops 2018.
Tentang pembicara:
Lebih dari 35 tahun di bidang manajemen TI, berpartisipasi dalam penciptaan pendahulu OpenCloud di Canonical, mengambil bagian dalam 10 startup, dua di antaranya dijual ke Dell dan Docker. Saat ini dia adalah Wakil Presiden DevOps dan Praktik Digital di SJ Technologies.
Berikutnya adalah cerita dari sudut pandang John.
Nama saya John Willis dan tempat termudah untuk menemukan saya adalah di Twitter, . Saya memiliki alias yang sama di Gmail dan GitHub. A Anda dapat menemukan rekaman video laporan dan presentasi saya untuk mereka.
Saya banyak melakukan pertemuan dengan CIO dari berbagai perusahaan besar. Mereka sangat sering mengeluh bahwa mereka tidak memahami apa itu DevOps, dan setiap orang yang mencoba menjelaskannya kepada mereka membicarakan sesuatu yang berbeda. Keluhan umum lainnya adalah DevOps tidak berfungsi, meskipun tampaknya para direktur melakukan segalanya seperti yang dijelaskan kepada mereka. Kita berbicara tentang perusahaan besar yang berusia lebih dari seratus tahun. Setelah berbicara dengan mereka, saya sampai pada kesimpulan bahwa untuk banyak masalah, bukan teknologi tinggi yang paling cocok, melainkan solusi yang relatif berteknologi rendah. Selama berminggu-minggu saya hanya berbicara dengan orang-orang dari departemen yang berbeda. Apa yang Anda lihat pada gambar pertama di postingan adalah proyek terakhir saya, seperti inilah ruangan itu setelah tiga hari pengerjaan.
Apa itu DevOps?
Memang benar, jika Anda bertanya kepada 10 orang berbeda, mereka akan memberikan 10 jawaban berbeda. Namun ada hal yang menarik: kesepuluh jawaban ini semuanya benar. Tidak ada jawaban yang salah di sini. Saya cukup mendalami DevOps, selama sekitar 10 tahun, dan menjadi orang Amerika pertama di DevOpsDay pertama. Saya tidak akan mengatakan bahwa saya lebih pintar dari semua orang yang terlibat dalam DevOps, namun hampir tidak ada orang yang menghabiskan banyak upaya untuk hal itu. Saya percaya bahwa DevOps terjadi ketika sumber daya manusia dan teknologi bersatu. Kita sering melupakan dimensi kemanusiaan, padahal kita banyak membicarakan segala macam budaya.
Sekarang kita memiliki banyak data, penelitian akademis selama lima tahun, pengujian teori dalam skala industri. Studi-studi ini menunjukkan bahwa jika Anda menggabungkan beberapa pola perilaku dalam budaya organisasi, Anda dapat mencapai peningkatan 2000x lipat. Akselerasi ini diimbangi dengan peningkatan stabilitas yang setara. Ini adalah pengukuran kuantitatif atas manfaat yang dapat diberikan DevOps kepada perusahaan mana pun. Beberapa tahun yang lalu, saya berbicara tentang DevOps kepada CEO sebuah perusahaan Fortune 5000. Ketika saya sedang mempersiapkan presentasi, saya sangat gugup karena saya harus merangkum pengalaman saya selama bertahun-tahun dalam 5 menit.
Pada akhirnya saya memberikan yang berikut ini Definisi DevOps: Ini adalah serangkaian praktik dan pola yang memungkinkan transformasi sumber daya manusia menjadi modal organisasi berkinerja tinggi. Contohnya adalah cara Toyota beroperasi selama 50 atau 60 tahun terakhir.
(Selanjutnya diagram tersebut diberikan bukan sebagai bahan referensi, melainkan sebagai ilustrasi. Isinya akan berbeda-beda untuk setiap perusahaan baru. Namun gambarnya dapat dilihat secara terpisah dan diperbesar.
Salah satu praktik yang paling sukses adalah pemetaan value stream. Beberapa buku bagus telah ditulis tentang hal ini, yang paling sukses adalah karya Karen Martin. Namun selama setahun terakhir, saya sampai pada kesimpulan bahwa pendekatan ini pun terlalu berteknologi tinggi. Pastinya banyak sekali kelebihannya dan saya sudah sering menggunakannya. Namun ketika CEO bertanya kepada Anda mengapa perusahaannya tidak dapat beralih ke jalur baru, masih terlalu dini untuk membicarakan pemetaan aliran nilai. Masih banyak pertanyaan mendasar yang harus dijawab terlebih dahulu.
Saya pikir kesalahan yang dilakukan banyak kolega saya adalah mereka hanya memberikan lima poin panduan kepada perusahaan dan kemudian kembali lagi enam bulan kemudian dan melihat apa yang terjadi. Bahkan skema yang bagus seperti pemetaan aliran nilai, katakanlah, memiliki titik buta. Setelah ratusan wawancara dengan direktur berbagai perusahaan, saya telah mengembangkan pola tertentu yang memungkinkan kita memecah masalah menjadi komponen-komponennya, dan sekarang kita akan membahas masing-masing komponen tersebut secara berurutan. Sebelum menerapkan solusi teknologi apa pun, saya menggunakan pola ini, dan hasilnya, dinding saya dipenuhi diagram. Baru-baru ini saya bekerja dengan reksa dana dan saya mendapatkan 100-150 skema seperti itu.
Budaya buruk memakan pendekatan yang baik untuk sarapan
Ide utamanya adalah: Lean, Agile, SAFE, dan DevOps tidak akan membantu jika budaya organisasi itu sendiri buruk. Ini seperti menyelam ke kedalaman tanpa peralatan selam atau beroperasi tanpa x-ray. Dengan kata lain, jika diparafrasekan oleh Drucker dan Deming: budaya organisasi yang buruk akan menelan sistem yang baik tanpa menghambatnya.
Untuk mengatasi masalah utama ini, Anda perlu melakukan langkah-langkah berikut:
- Jadikan Semua Pekerjaan Terlihat: Anda perlu membuat semua pekerjaan terlihat. Bukan dalam arti bahwa hal tersebut harus ditampilkan pada suatu layar, namun dalam arti bahwa hal tersebut harus dapat diamati.
- Sistem Manajemen Kerja Konsolidasi: sistem manajemen perlu dikonsolidasikan. Dalam masalah pengetahuan “suku” dan pengetahuan institusional, dalam 9 dari 10 kasus, hambatannya adalah manusia. Di dalam buku masalahnya ada pada satu orang, Brent, yang menyebabkan proyek tersebut terlambat tiga tahun dari jadwal. Dan saya bertemu dengan “Brents” ini di mana-mana. Untuk mengatasi kemacetan ini, saya menggunakan dua item berikutnya dalam daftar kami.
- Metodologi Teori Kendala: teori kendala.
- Peretasan kolaborasi: peretasan kolaborasi.
- Kata Toyota (): Saya tidak akan berbicara banyak tentang Toyota Kata. Jika tertarik, di github saya pada hampir semua topik ini.
- Organisasi Berorientasi Pasar: organisasi yang berorientasi pasar.
- Auditor shift-kiri: audit pada tahap awal siklus.
Saya mulai bekerja dengan sebuah organisasi dengan sangat sederhana: Saya pergi ke perusahaan dan berbicara dengan karyawan. Seperti yang Anda lihat, tidak ada teknologi tinggi. Yang Anda butuhkan hanyalah sesuatu untuk ditulis. Saya mengumpulkan beberapa tim dalam satu ruangan dan menganalisis apa yang mereka katakan kepada saya dari sudut pandang 7 arketipe saya. Dan kemudian saya sendiri yang memberi mereka spidol dan meminta mereka menuliskan di papan tulis semua yang telah mereka katakan dengan lantang sejauh ini. Biasanya dalam rapat seperti ini ada satu orang yang menuliskan semuanya, dan paling banter dia bisa menuliskan 10% pembahasan. Dengan metode saya, angka ini bisa dinaikkan menjadi sekitar 40%.
(Ilustrasi ini dapat dilihat secara terpisah )
Pendekatan saya didasarkan pada karya William Schneider. ). Pendekatan ini didasarkan pada gagasan bahwa setiap organisasi dapat dibagi menjadi empat kotak. Skema ini bagi saya biasanya merupakan hasil kerja dengan ratusan skema lain yang muncul ketika menganalisis sebuah organisasi. Misalkan kita mempunyai organisasi dengan tingkat kendali yang tinggi, namun kompetensinya rendah. Ini adalah pilihan yang sangat tidak diinginkan: ketika semua orang mematuhi batas, tetapi tidak ada yang tahu apa yang harus dilakukan.
Pilihan yang lebih baik adalah yang memiliki tingkat kendali dan kompetensi yang tinggi. Jika perusahaan seperti itu menguntungkan, mungkin perusahaan tersebut tidak memerlukan DevOps. Yang paling menarik adalah bekerja di perusahaan yang memiliki tingkat kontrol yang tinggi, kompetensi dan kerjasama yang rendah, namun pada saat yang sama memiliki tingkat budaya (budaya) yang tinggi. Artinya perusahaan tersebut memiliki banyak orang yang suka bekerja disana dan tingkat perputaran tenaga kerja rendah.
(Ilustrasi ini dapat dilihat secara terpisah )
Bagi saya, metode-metode dengan pedoman yang kaku pada akhirnya menghalangi pencapaian kebenaran. Khususnya dalam pemetaan aliran nilai, ada banyak aturan mengenai bagaimana informasi harus disusun. Pada tahap awal pekerjaan, yang saya bicarakan sekarang, tidak ada yang membutuhkan aturan-aturan ini. Jika seseorang dengan spidol di tangannya menggambarkan situasi sebenarnya di perusahaan di papan tulis, ini adalah cara terbaik untuk memahami keadaannya. Informasi tersebut tidak sampai ke direktur. Pada saat ini, adalah bodoh untuk menyela seseorang dan mengatakan bahwa dia salah menggambar panah. Pada tahap ini sebaiknya menggunakan aturan sederhana, misalnya: abstraksi bertingkat dapat dibuat hanya dengan menggunakan spidol multi-warna.
Saya ulangi, tidak ada teknologi tinggi. Penanda hitam menggambarkan realitas obyektif tentang cara kerja segala sesuatu. Dengan spidol merah, orang menandai apa yang tidak mereka sukai dari keadaan saat ini. Yang penting mereka menulis ini, bukan saya. Ketika saya menemui CIO setelah rapat, saya tidak menawarkan daftar 10 hal yang perlu diperbaiki. Saya berusaha untuk menemukan hubungan antara apa yang dikatakan orang-orang di perusahaan dan pola-pola yang sudah terbukti. Terakhir, penanda biru menyarankan solusi yang mungkin untuk masalah tersebut.
(Ilustrasi ini dapat dilihat secara terpisah )
Contoh pendekatan ini digambarkan di atas. Awal tahun ini saya bekerja dengan satu bank. Petugas keamanan di sana yakin bahwa mereka tidak boleh datang untuk meninjau desain dan persyaratan.
(Ilustrasi ini dapat dilihat secara terpisah )
Lalu kami berbicara dengan orang-orang dari departemen lain dan ternyata sekitar 8 tahun yang lalu, pengembang perangkat lunak memecat pekerja keamanan karena mereka memperlambat pekerjaan. Dan kemudian berubah menjadi larangan, yang dianggap remeh. Meski pada kenyataannya tidak ada larangan.
Pertemuan kami berlangsung dengan cara yang sangat membingungkan: selama sekitar tiga jam, lima tim berbeda tidak dapat menjelaskan kepada saya apa yang terjadi antara kode dan majelis. Dan ini tampaknya merupakan hal yang paling sederhana. Kebanyakan konsultan DevOps berasumsi sebelumnya bahwa semua orang sudah mengetahui hal ini.
Kemudian penanggung jawab tata kelola TI, yang telah terdiam selama empat jam, tiba-tiba menjadi hidup ketika kami membahas topiknya, dan menyibukkan kami untuk waktu yang sangat lama. Pada akhirnya saya menanyakan pendapatnya tentang pertemuan tersebut, dan saya tidak akan pernah melupakan jawabannya. Dia berkata: “Dulu saya berpikir bahwa bank kami hanya memiliki dua cara untuk menyediakan perangkat lunak, tetapi sekarang saya tahu bahwa ada lima cara, dan saya bahkan tidak tahu tentang tiga cara tersebut.”
(Ilustrasi ini dapat dilihat secara terpisah )
Pertemuan terakhir di bank ini adalah dengan tim software investasi. Bersamanya ternyata menulis diagram dengan spidol di selembar kertas lebih baik daripada di papan, dan bahkan lebih baik daripada di papan pintar.
Foto-foto yang Anda lihat adalah seperti apa ruang konferensi hotel pada hari keempat pertemuan kami. Dan kami menggunakan skema ini untuk mencari pola, yaitu arketipe.
Jadi saya ajukan pertanyaan kepada pekerja, mereka menuliskan jawabannya dengan spidol tiga warna (hitam, merah dan biru). Saya menganalisis jawaban mereka untuk mengetahui arketipe. Sekarang mari kita bahas semua arketipe secara berurutan.
1. Jadikan Semua Pekerjaan Terlihat: Jadikan pekerjaan terlihat
Sebagian besar perusahaan tempat saya bekerja memiliki persentase pekerjaan yang tidak diketahui yang sangat tinggi. Misalnya, ketika seorang karyawan mendatangi karyawan lain dan sekadar meminta untuk melakukan sesuatu. Di organisasi besar, mungkin terdapat 60% pekerjaan yang tidak direncanakan. Dan hingga 40% pekerjaan tidak didokumentasikan dengan cara apa pun. Jika itu Boeing, saya tidak akan pernah menaiki pesawat mereka lagi seumur hidup saya. Jika hanya separuh pekerjaan yang terdokumentasi, maka tidak diketahui apakah pekerjaan tersebut dilakukan dengan benar atau tidak. Semua metode lain ternyata tidak berguna - tidak ada gunanya mencoba mengotomatisasi apa pun, karena 50% yang diketahui mungkin merupakan bagian pekerjaan yang paling koheren dan jelas, otomatisasi yang tidak akan memberikan hasil yang bagus, dan yang terburuk adalah segala sesuatunya berada di bagian yang tidak terlihat. Dengan tidak adanya dokumentasi, mustahil untuk menemukan segala macam peretasan dan pekerjaan tersembunyi, tidak menemukan hambatan, “Brents” yang telah saya bicarakan. Ada sebuah buku yang luar biasa karya Dominica DeGrandis . Dia mengungkapkan lima "kebocoran waktu" yang berbeda (pencuri waktu):
- Terlalu Banyak Pekerjaan dalam Proses (WIP)
- Dependensi Tidak Diketahui
- Pekerjaan yang Tidak Direncanakan
- Prioritas yang bertentangan
- Pekerjaan yang Terabaikan
Ini adalah analisis yang sangat berharga dan bukunya bagus, tetapi semua nasihat ini tidak ada gunanya jika hanya 50% data yang terlihat. Metode yang diusulkan Dominika dapat digunakan jika tercapai akurasi di atas 90%. Saya sedang berbicara tentang situasi di mana seorang atasan memberi tugas kepada bawahannya selama 15 menit, tetapi itu membutuhkan waktu tiga hari; tapi atasannya tidak begitu tahu kalau bawahannya ini bergantung pada empat atau lima orang lainnya.
Proyek Phoenix adalah kisah luar biasa tentang sebuah proyek yang terlambat tiga tahun. Salah satu karakter menghadapi pemecatan karena hal ini, dan dia bertemu dengan karakter lain yang ditampilkan sebagai semacam Socrates. Dia membantu mencari tahu apa yang sebenarnya salah. Ternyata perusahaan tersebut memiliki satu administrator sistem, bernama Brent, dan semua pekerjaan dilakukan melalui dia. Dalam salah satu rapat, salah satu bawahan ditanya: mengapa setiap tugas setengah jam memakan waktu seminggu? Jawabannya adalah pemaparan teori antrian dan hukum Little yang sangat disederhanakan, dan pada pemaparan ini ternyata pada okupansi 90% maka setiap jam kerja membutuhkan waktu 9 jam. Setiap tugas perlu dikirim ke tujuh orang lainnya, sehingga jamnya menjadi 63 jam, 7 kali 9. Maksud saya adalah untuk menggunakan Hukum Kecil atau teori antrian rumit apa pun, Anda setidaknya perlu memiliki data.
Jadi ketika saya berbicara tentang visibilitas, yang saya maksud bukan semuanya ada di layar, tetapi setidaknya Anda memiliki data. Ketika mereka melakukannya, sering kali ternyata ada sejumlah besar pekerjaan yang tidak direncanakan yang dikirim ke Brent ketika tidak diperlukan. Dan Brent adalah orang yang hebat, dia tidak akan pernah mengatakan tidak, tapi dia tidak memberi tahu siapa pun bagaimana dia melakukan pekerjaannya.
Ketika pekerjaan terlihat, data dapat diklasifikasikan dengan rapi (seperti yang dilakukan Dominika dalam foto), abstraksi dari lima kebocoran waktu dapat diterapkan, dan otomatisasi dapat diterapkan.
2. Konsolidasi Sistem Manajemen Kerja: Manajemen Tugas
Arketipe yang saya bicarakan adalah sejenis piramida. Jika yang pertama dilakukan dengan benar, maka yang kedua sudah menjadi semacam tambahan. Banyak di antaranya yang tidak berlaku untuk perusahaan rintisan, namun hal ini perlu diingat untuk perusahaan besar seperti Fortune 5000. Perusahaan terakhir tempat saya bekerja memiliki 10 sistem tiket. Satu tim memiliki Remedy, tim lain menulis sistemnya sendiri, tim ketiga menggunakan Jira, dan beberapa menggunakan email. Masalah yang sama muncul jika perusahaan memiliki 30 jaringan pipa yang berbeda, namun saya tidak punya waktu untuk membahas semua kasus tersebut.
Saya berdiskusi dengan orang-orang tentang cara pembuatan tiket, apa yang terjadi selanjutnya, dan cara menghindarinya. Hal yang paling menarik adalah orang-orang di pertemuan kami berbicara dengan cukup tulus. Saya bertanya berapa banyak orang yang memberi “dampak kecil/tidak berdampak” pada tiket yang seharusnya diberikan “dampak besar”. Ternyata hampir semua orang melakukan hal ini. Saya tidak terlibat dalam kecaman dan berusaha dengan segala cara untuk tidak mengidentifikasi orang. Ketika mereka dengan tulus mengakui sesuatu kepadaku, aku tidak akan memberikan orang itu begitu saja. Namun ketika hampir semua orang melewati sistem, itu berarti semua keamanan pada dasarnya hanya sekedar hiasan jendela. Oleh karena itu, tidak ada kesimpulan yang dapat diambil dari data sistem ini.
Untuk mengatasi masalah tiket, Anda harus memilih satu sistem utama. Jika Anda menggunakan Jira, pertahankan Jira. Jika ada alternatif lain, biarlah itu menjadi satu-satunya. Intinya adalah bahwa tiket harus dilihat sebagai langkah lain dalam proses pengembangan. Setiap tindakan harus memiliki tiket, yang harus mengalir melalui alur kerja pengembangan. Tiket dikirim ke tim, yang mempostingnya di storyboard dan kemudian bertanggung jawab atas tiket tersebut.
Hal ini berlaku untuk semua departemen, termasuk infrastruktur dan operasional. Dalam hal ini, dimungkinkan untuk membentuk setidaknya beberapa gagasan yang masuk akal tentang keadaan. Setelah proses ini ditetapkan, tiba-tiba menjadi mudah untuk mengidentifikasi siapa yang bertanggung jawab atas setiap aplikasi. Karena sekarang kami menerima bukan 50%, tapi 98% layanan baru. Jika proses inti ini berhasil, maka akurasi di seluruh sistem akan meningkat.
Jalur layanan
Sekali lagi ini hanya berlaku untuk perusahaan besar. Jika Anda adalah perusahaan baru di bidang baru, singsingkan lengan baju Anda dan bekerjalah dengan Travis CI atau CircleCI Anda. Kalau bicara perusahaan Fortune 5000, contohnya yang terjadi di bank tempat saya bekerja. Google mendatangi mereka dan mereka diperlihatkan diagram sistem IBM lama. Orang-orang dari Google bertanya dengan bingung - di mana kode sumbernya? Tapi tidak ada kode sumber, bahkan GUI pun tidak. Inilah kenyataan yang harus dihadapi oleh organisasi-organisasi besar: catatan bank berusia 40 tahun pada mainframe kuno. Salah satu klien saya menggunakan container Kubernetes dengan pola Circuit Breaker, ditambah Chaos Monkey, semuanya untuk aplikasi KeyBank. Namun container ini pada akhirnya terhubung ke aplikasi COBOL.
Orang-orang dari Google sangat yakin bahwa mereka akan menyelesaikan semua masalah klien saya, dan kemudian mereka mulai mengajukan pertanyaan: apa itu datapipe IBM? Mereka diberitahu: ini adalah konektor. Apa hubungannya? Ke sistem Sperry. Dan apakah itu? Dan seterusnya. Sekilas sepertinya: DevOps seperti apa yang ada? Namun kenyataannya, hal itu mungkin saja terjadi. Ada sistem pengiriman yang memungkinkan Anda menyerahkan alur kerja kepada tim pengiriman.
3. Teori Kendala: Teori Kendala
Mari kita beralih ke pola dasar ketiga: pengetahuan institusional/"kesukuan". Biasanya, di organisasi mana pun ada beberapa orang yang mengetahui segalanya dan mengelola segalanya. Mereka adalah orang-orang yang paling lama berada di organisasi dan mengetahui semua solusinya.
Ketika hal ini muncul dalam diagram, saya secara khusus melingkari orang-orang tersebut dengan spidol: misalnya, ternyata Lou tertentu hadir di semua pertemuan. Dan jelas bagi saya: ini adalah Brent lokal. Ketika CIO memilih antara saya yang mengenakan T-shirt dan sepatu kets dan pria dari IBM yang mengenakan setelan jas, saya dipilih karena saya dapat memberi tahu sutradara hal-hal yang tidak akan diceritakan oleh orang lain dan yang mungkin tidak ingin didengar oleh sutradara. . Saya memberi tahu mereka bahwa penghambat di perusahaan mereka adalah seseorang bernama Fred dan seseorang bernama Lou. Kemacetan ini perlu diatasi, pengetahuan mereka perlu diperoleh dari mereka dengan cara apa pun.
Untuk mengatasi masalah seperti ini, misalnya saya dapat menyarankan penggunaan Slack. Seorang sutradara yang cerdas akan bertanya - mengapa? Biasanya, dalam kasus seperti itu, konsultan DevOps menjawab: karena semua orang melakukannya. Kalau sutradaranya pintar banget, dia akan bilang: terus kenapa. Dan di sinilah dialog berakhir. Dan jawaban saya adalah: karena ada empat hambatan di perusahaan, Fred, Lou, Susie dan Jane. Untuk melembagakan pengetahuan mereka, pertama-tama kita harus memperkenalkan Slack. Semua wiki Anda benar-benar omong kosong karena tidak ada yang tahu keberadaannya. Jika tim teknik terlibat dalam pengembangan front-end dan back-end dan semua orang perlu mengetahui bahwa mereka dapat menghubungi tim pengembangan front-end atau tim infrastruktur jika ada pertanyaan. Saat itulah Lou atau Fred mungkin punya waktu untuk bergabung dengan wiki. Dan kemudian di Slack seseorang mungkin bertanya mengapa, katakanlah, langkah 5 tidak berhasil, lalu Lou atau Fred akan memperbaiki instruksi di wiki. Jika Anda menetapkan proses ini, maka banyak hal akan berjalan dengan sendirinya.
Inilah poin utama saya: untuk merekomendasikan teknologi tinggi apa pun, Anda harus terlebih dahulu meletakkan fondasinya, dan ini dapat dilakukan dengan solusi teknologi rendah yang baru saja dijelaskan. Jika Anda memulai dengan teknologi tinggi dan tidak menjelaskan mengapa teknologi itu dibutuhkan, maka, biasanya, ini tidak akan berakhir dengan baik. Salah satu klien kami menggunakan Azure ML, solusi yang sangat murah dan sederhana. Sekitar 30% pertanyaan mereka dijawab oleh mesin belajar mandiri itu sendiri. Dan hal ini ditulis oleh operator yang tidak terlibat dalam ilmu data, statistik, atau matematika. Ini penting. Biaya untuk solusi semacam itu minimal.
4. Peretasan kolaborasi: Peretasan kolaborasi
Pola dasar keempat adalah kebutuhan untuk melawan isolasi. Kebanyakan orang sudah mengetahui hal ini: isolasi menimbulkan permusuhan. Jika setiap departemen berada di lantainya masing-masing, dan orang-orang tidak saling bersinggungan dengan cara apa pun, kecuali di dalam lift, maka permusuhan di antara mereka muncul dengan sangat mudah. Namun jika sebaliknya, orang-orang berada satu ruangan satu sama lain, dia langsung pergi. Ketika seseorang melontarkan tuduhan umum, misalnya, antarmuka ini dan itu tidak pernah berfungsi, tidak ada yang lebih mudah untuk mendekonstruksi tuduhan tersebut. Pemrogram yang menulis antarmuka hanya perlu mulai mengajukan pertanyaan spesifik, dan akan segera menjadi jelas bahwa, misalnya, pengguna salah menggunakan alat tersebut.
Ada banyak cara untuk mengatasi isolasi. Saya pernah diminta menjadi konsultan di sebuah bank di Australia, namun saya menolaknya karena saya mempunyai dua orang anak dan seorang istri. Yang bisa saya lakukan untuk membantu mereka hanyalah merekomendasikan penceritaan grafis. Ini adalah sesuatu yang terbukti berhasil. Cara menarik lainnya adalah pertemuan lean coffee. Dalam organisasi besar, ini adalah pilihan bagus untuk menyebarkan pengetahuan. Selain itu, Anda bisa mengadakan devopsday internal, hackathon, dan lain sebagainya.
5. Melatih Kata
Seperti yang saya peringatkan di awal, saya tidak akan membicarakan hal ini hari ini. Jika Anda tertarik, Anda bisa melihatnya .
Ada juga pembicaraan bagus tentang topik ini dari Mike Rother:
6. Berorientasi Pasar: organisasi yang berorientasi pasar
Ada masalah berbeda di sini. Misalnya orang “I”, orang “T”, dan orang “E”. Orang “saya” adalah mereka yang hanya melakukan satu hal. Biasanya mereka ada di organisasi dengan departemen yang terisolasi. "T" adalah ketika seseorang pandai dalam satu hal tetapi juga pandai dalam beberapa hal lainnya. "E" atau bahkan "sisir" adalah ketika seseorang memiliki banyak keterampilan.
Hukum Conway berlaku di sini (), yang dalam bentuk yang paling sederhana dapat dinyatakan sebagai berikut: jika tiga tim mengerjakan penyusun, maka hasilnya adalah penyusun tiga bagian. Oleh karena itu, jika terdapat tingkat isolasi yang tinggi dalam suatu organisasi, bahkan Kubernetes, Circuit breaker, ekstensibilitas API, dan hal-hal mewah lainnya dalam organisasi ini akan diatur dengan cara yang sama seperti organisasi itu sendiri. Benar-benar menurut Conway dan membuat kalian semua geek muda kesal.
Solusi untuk masalah ini telah dijelaskan berkali-kali. Misalnya, ada arketipe organisasi yang dijelaskan oleh Fernando Fernandez. Arsitektur bermasalah yang baru saja saya bicarakan, dengan isolasi, adalah arsitektur berorientasi fungsi. Tipe kedua adalah yang terburuk, arsitektur matriks, yang berantakan dari dua lainnya. Yang ketiga adalah apa yang terlihat di sebagian besar startup, dan perusahaan-perusahaan besar pun berusaha menyamai tipe ini. Ini adalah organisasi yang berorientasi pasar. Di sini kami mengoptimalkan untuk mencapai respons tercepat terhadap permintaan pelanggan. Kadang-kadang hal ini disebut organisasi datar.
Banyak orang menggambarkan struktur ini dengan cara yang berbeda, saya suka kata-katanya membangun/menjalankan tim, di Amazon mereka menyebutnya dua tim pizza. Dalam struktur ini, semua orang tipe “I” dikelompokkan dalam satu layanan, dan lambat laun mereka semakin dekat dengan tipe “T”, dan jika ada manajemen yang tepat, mereka bahkan bisa menjadi “E”. Argumen tandingan pertama di sini adalah bahwa struktur seperti itu mengandung unsur-unsur yang tidak perlu. Mengapa Anda memerlukan penguji di setiap departemen jika Anda dapat memiliki departemen penguji khusus? Yang saya jawab: biaya tambahan dalam hal ini adalah harga bagi seluruh organisasi untuk menjadi tipe “E” di masa depan. Dalam struktur ini, penguji secara bertahap belajar tentang jaringan, arsitektur, desain, dll. Akibatnya, setiap peserta dalam organisasi menyadari sepenuhnya segala sesuatu yang terjadi dalam organisasi. Jika Anda ingin mengetahui cara kerja skema ini di industri, bacalah .
7. Auditor shift-kiri: mengaudit pada awal siklus. Kepatuhan terhadap aturan keselamatan dipamerkan
Ini adalah saat tindakan Anda tidak lolos uji penciuman. Orang yang bekerja untuk Anda tidaklah bodoh. Jika, seperti pada contoh di atas, mereka memberikan dampak kecil/tidak ada dampak sama sekali, hal ini berlangsung selama tiga tahun, dan tidak ada seorang pun yang memperhatikan apa pun, maka semua orang tahu betul bahwa sistem tersebut tidak berfungsi. Atau contoh lain - dewan penasihat perubahan, yang laporannya harus diserahkan setiap, katakanlah, hari Rabu. Ada sekelompok orang yang bekerja di sana (yang gajinya tidak terlalu tinggi) yang, secara teori, seharusnya mengetahui cara kerja sistem secara keseluruhan. Dan selama lima tahun terakhir, Anda mungkin memperhatikan bahwa sistem kita sangatlah kompleks. Dan lima atau enam orang harus membuat keputusan tentang perubahan yang tidak mereka lakukan dan tidak mereka ketahui apa pun.
Tentu saja pendekatan ini tidak berhasil. Saya harus menyingkirkan hal-hal seperti itu karena orang-orang ini tidak melindungi sistem. Keputusan harus diambil oleh tim itu sendiri, karena tim harus bertanggung jawab. Jika tidak, situasi paradoks muncul ketika seorang manajer yang belum pernah menulis kode seumur hidupnya memberi tahu programmer berapa lama waktu yang dibutuhkan untuk menulis kode. Satu perusahaan tempat saya bekerja memiliki 7 dewan berbeda yang meninjau setiap perubahan, termasuk dewan arsitektur, dewan produk, dll. Bahkan ada masa tunggu wajib, meskipun salah satu karyawan mengatakan kepada saya bahwa selama sepuluh tahun bekerja, tidak ada seorang pun yang pernah menolak perubahan yang dilakukan orang tersebut selama masa wajib tersebut.
Auditor perlu diundang untuk bergabung dengan kami, dan bukan menyingkirkan mereka. Beri tahu mereka bahwa Anda menulis wadah biner yang tidak dapat diubah yang, jika mereka lulus semua pengujian, akan tetap tidak dapat diubah selamanya. Beri tahu mereka bahwa Anda memiliki saluran pipa sebagai kode dan jelaskan apa artinya. Tunjukkan pada mereka skema berikut: biner read-only yang tidak dapat diubah dalam wadah yang lolos semua uji kerentanan; dan tidak hanya tidak ada yang menyentuhnya, mereka bahkan tidak menyentuh sistem yang membuat saluran pipa, karena saluran tersebut juga dibuat secara dinamis. Saya punya klien, Capital One, yang menggunakan Vault untuk membuat sesuatu seperti blockchain. Auditor tidak perlu menunjukkan “resep” dari Chef; cukup menunjukkan blockchain, yang darinya jelas apa yang terjadi pada tiket Jira dalam produksi dan siapa yang bertanggung jawab atasnya.
Menurut , dibuat pada tahun 2018 oleh Sonatype, terdapat 2017 miliar permintaan unduhan OSS pada tahun 87.
Kerugian yang timbul karena kerentanan sangat besar. Terlebih lagi, angka-angka yang Anda lihat di atas belum termasuk biaya peluang. Singkatnya, apa itu DevSecOps? Izinkan saya segera mengatakan bahwa saya tidak tertarik membicarakan betapa suksesnya nama ini. Intinya adalah karena DevOps sangat sukses, kita harus mencoba menambahkan keamanan pada pipeline tersebut.
Contoh rangkaian ini:
Ini bukan rekomendasi untuk produk tertentu, meski saya suka semuanya. Saya mengutipnya sebagai contoh untuk menunjukkan bahwa DevOps, yang awalnya didasarkan pada paradigma organisasi di industri, memungkinkan Anda mengotomatiskan setiap tahap pengerjaan suatu produk.
Dan tidak ada alasan mengapa kami tidak dapat mengambil pendekatan keamanan yang sama.
Total
Sebagai penutup, saya akan memberikan beberapa tips untuk DevSecOps. Anda perlu melibatkan auditor dalam proses pembuatan sistem Anda dan meluangkan waktu untuk mendidik mereka. Anda perlu bekerja sama dengan auditor. Selanjutnya, Anda perlu melakukan perjuangan yang sangat kejam melawan kesalahan positif. Bahkan dengan alat pemindaian kerentanan yang paling mahal sekalipun, Anda dapat menciptakan kebiasaan yang sangat buruk di antara pengembang Anda jika Anda tidak mengetahui berapa rasio signal-to-noise Anda. Pengembang akan kewalahan dengan acara dan akan menghapusnya begitu saja. Jika Anda mendengar cerita Equifax, hal itulah yang terjadi di sana, di mana tingkat kewaspadaan tertinggi diabaikan. Selain itu, kerentanan perlu dijelaskan sedemikian rupa sehingga memperjelas dampaknya terhadap bisnis. Misalnya, Anda bisa mengatakan bahwa ini adalah kerentanan yang sama seperti dalam cerita Equifax. Kerentanan keamanan harus diperlakukan sama seperti masalah perangkat lunak lainnya, yaitu harus disertakan dalam keseluruhan proses DevOps. Anda perlu bekerja dengan mereka melalui Jira, Kanban, dll. Pengembang tidak boleh berpikir bahwa orang lain akan melakukan hal ini - sebaliknya, setiap orang harus melakukan hal ini. Terakhir, Anda perlu mengeluarkan energi untuk melatih orang.
Berguna Link
Berikut beberapa pembicaraan dari konferensi DevOops yang mungkin berguna bagi Anda:
- Sergey Berdnikov, Artyom Kalichkin - Kisah sukses, atau “Dev+DevOps+Ops” (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps dalam skala: tragedi Yunani dalam tiga babak (, )
- Alexander Titov, Kirill Tolkachev -
- Timotius Lister -
Memeriksa DevOops 2020 Moskow — banyak juga hal menarik di sana.
Sumber: www.habr.com