⛅️ 🤘🏼 🔷 Tujuh Pola Dasar Transformasi DevOps 😎 😑 🚁

Pertanyaan "bagaimana menerapkan devopae" bukanlah tahun pertama, tetapi tidak ada begitu banyak materi bagus. Terkadang Anda menjadi korban iklan, bukan konsultan yang sangat pintar yang perlu menjual waktu mereka, bagaimanapun caranya. Terkadang ini adalah kata-kata yang suram dan sangat umum tentang bagaimana kapal-kapal megacorporations membajak hamparan alam semesta. Muncul pertanyaan: bagaimana dengan kita? Penulis yang terhormat, dapatkah Anda merumuskan gagasan Anda dengan jelas?

Semua ini berasal dari kenyataan bahwa tidak banyak akumulasi praktik nyata dan pemahaman tentang hasil transformasi budaya perusahaan. Perubahan dalam budaya adalah hal-hal lama, yang hasilnya tidak akan muncul dalam seminggu dan tidak dalam sebulan. Kami membutuhkan seseorang yang cukup kuno untuk melihat bagaimana perusahaan diciptakan dan runtuh selama bertahun-tahun.

John Willis- Salah satu bapak DevOps. Di belakang John - puluhan tahun bekerja dengan sejumlah besar perusahaan. Baru-baru ini, John mulai memperhatikan sendiri pola-pola spesifik yang terjadi dalam bekerja dengan masing-masing dari mereka. Dengan menggunakan arketipe ini, John membimbing perusahaan di jalur transformasi DevOps yang sebenarnya. Baca lebih lanjut tentang arketipe ini dalam terjemahan laporannya dari konferensi DevOops 2018.

Tentang pembicara:

Lebih dari 35 tahun dalam manajemen TI, berpartisipasi dalam penciptaan pendahulu OpenCloud di Canonical, mengambil bagian dalam 10 startup, dua di antaranya dijual oleh Dell dan Docker. Saat ini ia adalah Wakil Presiden DevOps dan Praktik Digital di SJ Technologies.

Berikutnya adalah narasi atas nama John.

Nama saya John Willis dan cara termudah untuk menemukan saya di Twitter adalah @botchagalupe . Saya memiliki alias yang sama di Gmail dan GitHub. Dan di tautan ini Anda dapat menemukan video dari laporan dan presentasi saya kepada mereka.

Saya memiliki banyak pertemuan dengan CIO dari berbagai perusahaan besar. Mereka sangat sering mengeluh bahwa mereka tidak mengerti apa itu DevOps, dan semua orang yang mencoba menjelaskannya kepada mereka sedang membicarakan hal lain. Keluhan umum lainnya adalah bahwa DevOps tidak berfungsi, meskipun tampaknya direksi melakukan semuanya seperti yang dijelaskan kepada mereka. Kita berbicara tentang perusahaan besar yang berumur lebih dari seratus tahun. Setelah berbicara dengan mereka, saya sampai pada kesimpulan bahwa untuk banyak masalah bukan teknologi tinggi, tetapi solusi yang relatif rendah teknologi paling cocok. Selama berminggu-minggu, saya hanya mengobrol dengan orang-orang dari berbagai departemen. Apa yang Anda lihat pada gambar pertama di pos adalah proyek terakhir saya, ruangan tampak seperti ini setelah tiga hari bekerja.

Apa itu DevOps?

Memang, jika Anda bertanya pada 10 orang yang berbeda, mereka akan memberikan 10 jawaban berbeda. Tapi yang menarik: kesepuluh jawaban ini akan benar. Tidak ada jawaban yang salah di sini. Saya mempelajari DevOps cukup dalam, selama sekitar 10 tahun, adalah orang Amerika pertama pada DevOpsDay pertama. Saya tidak akan mengatakan bahwa saya lebih pintar daripada semua orang yang terlibat dalam DevOps, tetapi hampir tidak ada orang yang telah menghabiskan banyak upaya untuk hal ini. Saya percaya bahwa DevOps muncul ketika modal manusia dan teknologi digabungkan. Kita sering melupakan dimensi manusia, walaupun kita banyak berbicara tentang semua jenis budaya.

Sekarang kami memiliki banyak data, lima tahun penelitian akademis, verifikasi teori telah ditetapkan pada skala industri. Studi-studi ini memberi tahu kami hal berikut: jika Anda menggabungkan beberapa pola perilaku dalam budaya organisasi, Anda bisa mendapatkan akselerasi 2000 kali. Akselerasi ini sesuai dengan peningkatan stabilitas yang sama. Ini adalah pengukuran kuantitatif dari manfaat yang dapat diberikan DevOps ke perusahaan mana pun. Beberapa tahun yang lalu saya berbicara tentang DevOps kepada CEO Fortune 5000. Ketika saya sedang mempersiapkan presentasi, saya sangat gugup karena saya perlu menetapkan pengalaman bertahun-tahun dalam 5 menit.

Saya akhirnya memberikan definisi DevOps berikut: Ini adalah serangkaian praktik dan pola yang memungkinkan untuk mengubah modal manusia menjadi modal organisasi yang sangat produktif. Contohnya adalah bagaimana Toyota telah bekerja selama 50 atau 60 tahun terakhir.

(Selanjutnya, skema tersebut disajikan bukan sebagai bahan referensi, tetapi sebagai ilustrasi. Isinya akan berbeda untuk setiap perusahaan baru. Namun demikian, gambar dapat dilihat secara terpisah dan diperbesar oleh tautan ini.)

Salah satu praktik yang paling sukses adalah value stream pemetaan. Beberapa buku bagus telah ditulis tentang ini, penulis yang paling sukses di antaranya adalah Karen Martin. Tetapi selama setahun terakhir, saya sampai pada kesimpulan bahwa bahkan pendekatan ini terlalu berteknologi tinggi. Dia tentu memiliki banyak keunggulan, saya banyak menggunakannya. Tetapi ketika CEO bertanya kepada Anda mengapa perusahaannya tidak dapat beralih ke jalur baru, masih terlalu dini untuk berbicara tentang pemetaan value stream. Ada banyak pertanyaan mendasar yang perlu dijawab terlebih dahulu.

Tampak bagi saya bahwa kesalahan banyak kolega saya adalah bahwa mereka hanya memberi perusahaan panduan lima poin, dan kemudian kembali enam bulan kemudian dan melihat apa yang terjadi. Bahkan sirkuit yang bagus seperti pemetaan aliran nilai, katakanlah, blind spot. Setelah ratusan wawancara dengan direktur dari berbagai perusahaan, saya menemukan pola tertentu yang memungkinkan kita untuk menguraikan masalah menjadi komponen, dan sekarang kita akan membahas masing-masing komponen ini secara berurutan. Sebelum menerapkan solusi teknologi apa pun, saya menggunakan pola ini, dan sebagai hasilnya saya memiliki semua dinding digantung dengan pola. Saya baru-baru ini bekerja dengan satu reksa dana, dan saya berakhir dengan 100-150 skema ini.

Budaya buruk memakan pendekatan sarapan yang baik

Gagasan utamanya adalah ini: tidak ada Lean, Agile, SAFE dan DevOps yang akan membantu jika budaya organisasi buruk. Itu sama dengan menyelam ke kedalaman tanpa peralatan selam atau beroperasi tanpa sinar-X. Dengan kata lain, mengutip Drucker dan Deming: budaya organisasi yang buruk akan menelan sistem yang baik dan tidak tersedak.

Untuk mengatasi masalah utama ini, Anda harus mengambil langkah-langkah berikut:

Jadikan Semua Kerja Terlihat: Jadikan semua pekerjaan terlihat. Bukan dalam arti bahwa itu harus ditampilkan pada layar apa pun, tetapi dalam arti bahwa itu harus dapat diamati.
Consolidate Work Management Systems: . «» 9 10 . «Phoenix Project» - , , - . «» . c .
Theory of Constraints Methodology: .
Collaboration hacks: .
Toyota Kata (Coaching Kata): Toyota Kata . , .
Market Oriented Organization: .
Shift-left auditors: .

Saya mulai bekerja dengan organisasi dengan sangat sederhana: Saya pergi ke perusahaan dan berbicara dengan karyawan. Seperti yang Anda lihat, tidak ada teknologi tinggi. Yang diperlukan hanyalah menulis. Saya mengumpulkan beberapa tim dalam satu ruangan dan menganalisis apa yang mereka katakan dari sudut pandang 7 arketipe saya. Dan kemudian saya memberi mereka spidol sendiri dan meminta mereka untuk menulis di papan tulis dalam menulis semua yang sejauh ini mereka katakan dengan keras. Biasanya pada pertemuan seperti itu ada satu orang yang menuliskan semuanya, dan dalam kasus terbaik, ia dapat merekam 10% dari diskusi. Dengan metode saya, angka ini dapat dinaikkan menjadi sekitar 40%.

(Untuk ilustrasi terpisah, lihat tautannya )

Pendekatan saya didasarkan pada karya William Schneider, The Reengineering Alternative) Pendekatan ini didasarkan pada gagasan bahwa setiap organisasi dapat diuraikan menjadi empat kotak. Skema ini bagi saya biasanya merupakan hasil dari bekerja dengan ratusan skema lain yang muncul ketika menganalisis suatu organisasi. Misalkan kita memiliki organisasi dengan tingkat kontrol yang tinggi, tetapi dengan kompetensi yang rendah. Ini adalah pilihan yang sangat tidak diinginkan: ketika semua orang berjalan di sepanjang garis, tetapi tidak ada yang tahu apa yang harus dilakukan.

Pilihan yang sedikit lebih baik dengan tingkat kontrol dan kompetensi yang tinggi. Jika perusahaan semacam itu memiliki untung, maka mungkin tidak perlu DevOps. Sangat menarik untuk bekerja dengan perusahaan yang memiliki tingkat kontrol yang tinggi, kompetensi yang rendah dan kerja sama, tetapi pada saat yang sama memiliki tingkat budaya yang tinggi (budidaya). Ini berarti bahwa perusahaan memiliki banyak orang yang suka bekerja di sana, turnover tenaga kerjanya rendah.

(Anda dapat melihat ilustrasi ini secara terpisah dari tautannya ).

Bagi saya, metode dengan rekomendasi dengan kode keras pada akhirnya mengganggu pencapaian kebenaran. Secara khusus, pemetaan aliran nilai memiliki banyak aturan mengenai bagaimana menyusun informasi. Pada tahap awal pekerjaan yang saya bicarakan sekarang, tidak ada yang membutuhkan aturan ini. Jika seseorang dengan spidol di tangannya menggambarkan situasi nyata di perusahaan di papan tulis, ini adalah cara terbaik untuk memahami situasinya. Informasi semacam itu tidak sampai ke direksi. Pada saat ini, bodoh untuk memotong seseorang dan mengatakan bahwa ia menggambar panah yang salah. Pada tahap ini, lebih baik menggunakan aturan sederhana, misalnya: abstraksi multi-level dapat dibuat hanya menggunakan penanda multi-warna.

Saya ulangi, tidak ada teknologi tinggi. Spidol hitam menggambarkan realitas objektif, cara kerja semuanya. Orang-orang menandai dengan spidol merah apa yang sebenarnya tidak mereka sukai dalam keadaan saat ini. Penting bahwa mereka menulisnya, bukan saya. Ketika saya pergi ke Direktur Teknologi Informasi setelah pertemuan, saya tidak mengusulkan daftar 10 hal yang perlu diperbaiki. Saya berusaha keras untuk menemukan hubungan antara apa yang dikatakan orang di perusahaan dan pola yang sudah terbukti. Akhirnya, penanda biru menyarankan solusi yang mungkin untuk masalah tersebut.

(Secara terpisah, ilustrasi ini dapat dilihat di tautan )

Contoh dari pendekatan ini sekarang digambarkan di atas. Pada awal tahun ini saya bekerja dengan satu bank. Pekerja dari departemen keamanan di sana yakin bahwa mereka tidak boleh datang untuk memeriksa persyaratan dan desain (tinjauan desain dan persyaratan).

(Anda dapat melihat ilustrasi ini secara terpisah dari tautan )

Dan kemudian kami berbicara dengan orang-orang dari departemen lain dan ternyata sekitar 8 tahun yang lalu, pengembang perangkat lunak mengeluarkan pekerja keamanan karena mereka melambat. Dan kemudian berubah menjadi larangan, yang diterima begitu saja. Meski sebenarnya tidak ada larangan.

Pertemuan kami merupakan langkah yang sangat membingungkan: selama sekitar tiga jam, lima tim yang berbeda tidak dapat menjelaskan kepada saya apa yang terjadi antara kode dan majelis. Dan ini, tampaknya, adalah hal yang paling sederhana. Kebanyakan konsultan DevOps berasumsi sebelumnya bahwa semua orang sudah mengetahui hal ini.

Kemudian orang yang bertanggung jawab atas tata kelola TI, yang diam selama empat jam, tiba-tiba menjadi hidup ketika kami sampai pada subjeknya dan menduduki kami untuk waktu yang sangat lama. Pada akhirnya, saya bertanya kepadanya apa pendapatnya tentang pertemuan itu, dan saya tidak akan pernah melupakan jawabannya. Dia berkata: "Saya dulu berpikir bahwa hanya ada dua cara untuk mengirimkan perangkat lunak di bank kami, dan sekarang saya tahu bahwa ada lima di antaranya, dan saya bahkan tidak curiga ada tiga."

(Secara terpisah, ilustrasi ini dapat dilihat di tautan )

Pertemuan terakhir di bank ini adalah dengan tim perangkat lunak investasi. Itu bersamanya bahwa ternyata sirkuit penanda tulisan dengan spidol pada lembar lebih baik daripada menulis di papan tulis, dan bahkan lebih baik daripada menulis di papan tulis.

Foto-foto yang Anda lihat tampak seperti ruang konferensi hotel pada hari keempat pertemuan kami. Dan kami menggunakan pola ini untuk mencari pola, yaitu, pola dasar.

Jadi, saya mengajukan pertanyaan kepada karyawan, mereka menuliskan jawaban dengan spidol tiga warna (hitam, merah dan biru). Saya menganalisis jawaban mereka untuk arketipe. Sekarang mari kita bahas semua arketipe secara berurutan.

1. Jadikan Semua Kerja Terlihat: Jadikan pekerjaan itu terlihat.

Sebagian besar perusahaan tempat saya bekerja memiliki persentase pekerjaan tidak dikenal yang sangat tinggi. Sebagai contoh, ini adalah ketika seorang karyawan datang ke karyawan lain dan hanya meminta untuk melakukan sesuatu. Dalam organisasi besar, mungkin ada 60% pekerjaan yang tidak direncanakan. Dan hingga 40% dari pekerjaan tidak didokumentasikan dengan cara apa pun. Jika itu adalah Boeing, maka dalam hidup saya, saya tidak akan pernah naik pesawat lagi. Jika hanya setengah dari pekerjaan yang didokumentasikan, maka tidak diketahui apakah pekerjaan ini dilakukan dengan benar atau tidak. Semua metode lain ternyata tidak berguna - tidak ada gunanya mencoba mengotomatisasi sesuatu, karena 50% yang terkenal mungkin hanya bagian yang paling koheren dan jelas dari pekerjaan, otomatisasi yang tidak akan memberikan hasil yang bagus, dan semua yang paling mengerikan - di bagian yang tidak terlihat. Dengan tidak adanya dokumentasi tidak mungkin untuk menemukan semua jenis peretasan dan pekerjaan tersembunyi, tidak untuk menemukan kemacetan,"Brents" yang sama yang sudah saya bicarakan. Ada buku yang indah karya Dominica De Grandis (Dominica DeGrandis)"Membuat Pekerjaan Terlihat . " Ini mengidentifikasi lima " pencuri waktu" yang berbeda:

Terlalu Banyak Pekerjaan dalam Proses (WIP)
Ketergantungan Tidak Dikenal
Pekerjaan yang tidak direncanakan
Prioritas yang saling bertentangan
Pekerjaan Terabaikan

Ini adalah analisis yang sangat berharga, dan buku ini sangat bagus, tetapi semua tips ini tidak berguna jika hanya 50% dari data yang terlihat. Anda dapat menerapkan metode yang diusulkan oleh Dominika jika akurasi dicapai di atas 90%. Saya berbicara tentang situasi di mana atasan memberi tugas 15 menit kepada bawahan, dan itu membutuhkan waktu tiga hari; tetapi bos tidak benar-benar tahu bahwa bawahan ini tergantung pada empat atau lima orang lainnya.

Proyek Phoenix adalah kisah hebat tentang proyek yang terlambat tiga tahun. Salah satu pahlawan diancam akan dipecat karena hal ini, dan ia bertemu dengan karakter lain yang ditampilkan sebagai semacam Sokrates. Dia membantu mencari tahu apa yang salah. Ternyata perusahaan itu memiliki satu administrator sistem, yang namanya Brent, dan semua pekerjaan entah bagaimana melewatinya. Pada salah satu pertemuan, salah satu bawahan ditanya: mengapa tugas setengah jam setiap minggu? Sebagai tanggapan, eksposisi yang sangat disederhanakan dari teori antrian dan hukum Little mengikuti, dan dalam eksposisi ini ternyata pada 90% pekerjaan setiap jam kerja membutuhkan waktu 9 jam. Setiap tugas harus dikirim ke tujuh orang lain, jadi jam ini berubah menjadi 63 jam, 7 kali 9. Saya mengatakan ini,Untuk menggunakan hukum Little atau teori antrian yang rumit, Anda harus setidaknya memiliki data.

Oleh karena itu, ketika saya berbicara tentang visibilitas, saya tidak bermaksud bahwa semuanya ada di layar, tetapi setidaknya perlu memiliki data. Ketika mereka, sering ternyata ada sejumlah besar pekerjaan yang tidak direncanakan, yang untuk beberapa alasan dikirim ke Brent, meskipun ini tidak perlu. Dan Brent adalah pria yang hebat, dia tidak akan pernah mengatakan tidak, tetapi dia tidak memberi tahu siapa pun bagaimana dia melakukan pekerjaannya.

Saat pekerjaan terlihat, Anda dapat mengklasifikasikan data secara akurat (seperti yang dilakukan Dominika di foto), Anda dapat menerapkan abstraksi dari lima kebocoran waktu dan mengotomatiskannya.

2. Konsolidasi Sistem Manajemen Kerja: Manajemen Tugas

Pola dasar yang saya bicarakan adalah sejenis piramida. Jika yang pertama dilakukan dengan benar, maka yang kedua sudah semacam add-on. Banyak dari mereka tidak bekerja untuk startup, mereka harus diingat dalam kasus perusahaan besar, seperti yang ada di daftar Fortune 5000. Perusahaan terakhir tempat saya bekerja memiliki 10 sistem tiket. Remedy ada di satu tim, yang lain menulis semacam sistem sendiri, yang ketiga digunakan Jira, dan orang lain lewat email. Masalah yang sama muncul jika perusahaan memiliki 30 saluran pipa yang berbeda, tetapi saya tidak punya waktu untuk membahas semua kasus tersebut.

Saya berdiskusi dengan orang-orang bagaimana tepatnya tiket dibuat, apa yang terjadi pada mereka selanjutnya, bagaimana mereka dielakkan. Yang paling menarik adalah orang-orang di pertemuan kami berbicara dengan cukup tulus. Saya bertanya berapa banyak orang yang mengatur “dampak minor / tidak ada dampak” untuk tiket yang benar-benar seharusnya ditetapkan sebagai “dampak besar”. Ternyata hampir semua orang melakukannya. Saya tidak terlibat dalam pengaduan dan dalam segala hal saya berusaha untuk tidak mengidentifikasi orang. Ketika mereka dengan tulus mengakui kepada saya dalam sesuatu, saya tidak mengkhianati seseorang. Tetapi ketika hampir semua orang melewati sistem, ini berarti bahwa semua keamanan, pada dasarnya, adalah hiasan. Oleh karena itu, tidak ada kesimpulan yang dapat diambil dari data sistem ini.

Untuk menyelesaikan masalah dengan tiket, Anda harus memilih satu sistem utama. Jika Anda menggunakan Jira, biarlah itu hanya Jira. Jika ada alternatif, biarkan hanya itu. Intinya adalah bahwa tiket harus dianggap sebagai langkah lain dalam proses pengembangan. Setiap tindakan harus memiliki tiket yang harus melalui alur kerja pengembangan. Tiket dikirim ke tim, yang menempatkannya di storyboard, dan kemudian bertanggung jawab untuk itu.

Ini berlaku untuk semua departemen, termasuk infrastruktur dan operasi. Dalam hal ini, Anda dapat membuat setidaknya beberapa gagasan yang masuk akal tentang keadaan. Ketika proses ini dibuat, tiba-tiba ternyata Anda dapat dengan mudah menetapkan siapa yang bertanggung jawab untuk setiap aplikasi. Karena sekarang kita tidak mendapatkan 50%, tetapi 98% dari layanan baru. Jika proses dasar ini berhasil, akurasi meningkat di seluruh sistem.

Layanan Pipa

Ini lagi berlaku hanya untuk perusahaan besar. Jika Anda adalah perusahaan baru di bidang baru, gulung lengan baju Anda dan bekerja dengan Travis CI atau CircleCI Anda. Sedangkan untuk perusahaan Fortune 5000, kasus yang terjadi dengan bank tempat saya bekerja merupakan indikasi. Mereka datang kepada mereka dari Google, dan mereka ditunjukkan diagram dengan sistem IBM lama. Orang-orang dari Google dengan kesalahpahaman bertanya - di mana kode sumber untuk ini? Dan tidak ada kode sumber, bahkan GUI. Ini adalah kenyataan bahwa organisasi besar harus bekerja dengan: catatan perbankan 40 tahun pada mainframe kuno. Salah satu klien saya menggunakan wadah Kubernetes dengan pola Circuit Breaker, plus Chaos Monkey, semuanya untuk KeyBank. Namun wadah ini akhirnya terhubung ke aplikasi COBOL.

Orang-orang dari Google sepenuhnya yakin bahwa mereka akan menyelesaikan semua masalah klien saya, dan kemudian mulai mengajukan pertanyaan: apa datapipe IBM? Mereka dijawab: ini adalah konektor. Untuk apa terhubung? Ke sistem Sperry. Dan apakah itu? Dll Sekilas tampaknya: DevOps macam apa itu? Namun pada kenyataannya, itu mungkin. Ada sistem pengiriman yang memungkinkan Anda untuk mentransfer alur kerja ke tim pengiriman.

3. Teori Kendala: Teori Kendala

Mari kita beralih ke pola dasar ketiga: pengetahuan institusional / "suku". Sebagai aturan, di organisasi mana pun ada beberapa orang yang tahu segalanya dan mengelola semuanya. Mereka adalah mereka yang bekerja paling lama dalam organisasi dan yang mengetahui semua solusi.

Ketika ini terungkap pada diagram, saya secara khusus menggambar penanda di sekitar orang-orang seperti itu: misalnya, ternyata Lou tertentu hadir di semua rapat. Dan bagi saya sudah jelas: ini adalah Brent lokal. Ketika CIO memilih antara saya dengan T-shirt dan sepatu kets dan seorang lelaki mengenakan jas dari IBM, mereka memilih saya karena saya dapat memberi tahu direktur tentang hal-hal yang tidak akan diceritakan oleh lelaki lain dan yang mungkin tidak ingin didengar oleh direktur. Saya memberi tahu mereka bahwa ada hambatan di perusahaan mereka, itu adalah seseorang bernama Fred dan seseorang bernama Lu. Kemacetan ini perlu diikat, pengetahuan mereka perlu diperoleh dengan satu atau lain cara dari mereka.

Untuk mengatasi masalah seperti ini, saya dapat, misalnya, menyarankan menggunakan Slack. Seorang sutradara yang cerdas bertanya mengapa? Biasanya, dalam kasus seperti itu, konsultan DevOps merespons: karena semua orang melakukannya. Jika sutradara benar-benar pintar, ia akan berkata: lalu bagaimana. Dan di sinilah dialog berakhir. Dan saya menjawab ini: karena perusahaan memiliki empat kemacetan, Fred, Lou, Susie dan Jane. Untuk membuat pengetahuan mereka dilembagakan, Anda harus terlebih dahulu memperkenalkan Slack. Semua wiki Anda sepenuhnya omong kosong karena tidak ada yang tahu tentang keberadaan mereka. Jika tim insinyur terlibat dalam pengembangan eksternal dan internal dan semua orang harus tahu bahwa Anda dapat menghubungi tim pengembangan eksternal atau tim infrastruktur dengan pertanyaan. Saat itu, mungkin Lou atau Fred akan punya waktu untuk terhubung ke wiki. Dan kemudian di Slack, seseorang mungkin bertanyamengapa itu tidak berhasil, katakanlah, langkah 5. Dan kemudian Lou atau Fred akan memperbaiki instruksi di wiki. Jika Anda menetapkan proses ini, maka banyak yang akan jatuh ke tempatnya.

Ini adalah ide utama saya: untuk merekomendasikan beberapa teknologi tinggi, Anda harus terlebih dahulu menata fondasi bagi mereka, dan Anda dapat melakukan ini dengan solusi teknologi rendah yang baru saja dijelaskan. Jika Anda mulai dengan teknologi tinggi dan tidak menjelaskan mengapa mereka dibutuhkan, maka, sebagai suatu peraturan, ini tidak berakhir dengan sesuatu yang baik. Salah satu pelanggan kami menggunakan Azure ML, solusi yang sangat murah dan mudah. Di suatu tempat, 30% dari pertanyaan dijawab oleh mesin belajar mandiri itu sendiri. Dan operator yang tidak berurusan dengan ilmu data, statistik atau matematika menulis hal ini. Ini indikatif. Biaya solusi semacam itu minimal.

4. Retasan kolaborasi: Retasan kolaborasi

Pola dasar keempat adalah kebutuhan untuk melawan isolasi. Kebanyakan orang sudah tahu tentang ini: isolasi menimbulkan permusuhan. Jika setiap departemen berada di lantai masing-masing, dan orang-orang tidak bersinggungan satu sama lain dengan cara apa pun, kecuali dalam lift, maka permusuhan di antara mereka muncul dengan sangat mudah. Dan jika, sebaliknya, orang-orang berada di ruangan yang sama satu sama lain, dia segera pergi. Ketika seseorang melemparkan semacam tuduhan umum, misalnya, antarmuka ini dan itu tidak pernah berfungsi - tidak ada yang lebih mudah untuk mendekonstruksi tuduhan semacam itu. Sudah cukup bagi programmer yang menulis antarmuka untuk mulai mengajukan pertanyaan spesifik, dan segera menjadi jelas bahwa, misalnya, pengguna hanya menggunakan alat secara tidak benar.

Ada banyak cara untuk mengatasi isolasi. Saya pernah diminta untuk memberi nasihat kepada bank di Australia, saya menolak melakukan ini karena saya punya dua anak dan seorang istri. Yang bisa saya bantu adalah saya merekomendasikan cerita grafis kepada mereka. Ini adalah hal yang terbukti bekerja. Cara lain yang menarik adalah pertemuan format kopi ramping. Dalam organisasi besar, ini adalah cara yang bagus untuk menyebarkan pengetahuan. Selain itu, Anda dapat mengadakan devopsdays internal, hackathons, dan sebagainya.

5. Coaching Kata

Seperti yang sudah saya peringatkan di awal, hari ini saya tidak akan membicarakannya. Jika tertarik, Anda dapat melihat beberapa presentasi saya .

Ada juga laporan bagus tentang topik ini dari Mike Rother:

6. Berorientasi Pasar: Organisasi Berorientasi Pasar

Ada berbagai masalah di sini. Misalnya, orang "I", orang "T" dan orang "E". Orang "Aku" adalah mereka yang hanya terlibat dalam satu hal. Biasanya mereka ada di organisasi dengan unit yang terisolasi. "T" adalah jika seseorang mengetahui satu hal dengan baik, tetapi juga unggul dalam beberapa hal lainnya. "E" atau bahkan "sisir" adalah ketika seseorang memiliki banyak keterampilan. Hukum Conway

bekerja di sini , yang dalam bentuk paling sederhana dapat dinyatakan sebagai berikut: jika tiga tim terlibat dalam kompiler, hasilnya akan menjadi kompiler tiga bagian. Oleh karena itu, jika organisasi memiliki tingkat isolasi yang tinggi, maka bahkan Kubernetes, Circuit breaker, API extensibility, dan hal-hal modis lainnya dalam organisasi ini akan diatur dengan cara yang sama dengan organisasi itu sendiri. Menurut Conway dan meskipun kalian semua, Geeks muda.

Solusi untuk masalah ini telah dijelaskan berkali-kali. Misalnya, ada arketipe organisasi yang dijelaskan oleh Fernando Fernandez. Arsitektur masalah yang baru saja saya bicarakan dengan isolasi adalah arsitektur berorientasi fungsi. Tipe kedua adalah yang terburuk, arsitektur matriks, ada kekacauan dari dua lainnya. Yang ketiga adalah apa yang terlihat di sebagian besar startup, dan perusahaan besar juga mencoba untuk mencocokkan jenis ini. Ini adalah organisasi yang berorientasi pasar. Berikut ini adalah pengoptimalan untuk mencapai respons tercepat terhadap permintaan pelanggan. Ini kadang-kadang disebut organisasi datar.

Banyak orang menggambarkan struktur ini dengan cara yang berbeda, saya suka kata-kata tim build / run , di Amazon mereka menyebutnya dua tim pizza. Dalam struktur ini, semua orang dari tipe "I" dikelompokkan di sekitar satu layanan, dan secara bertahap mereka menjadi lebih dekat dengan tipe "T", dan jika manajemen yang tepat didirikan, bahkan "E" bisa menjadi. Pertentangan pertama di sini adalah bahwa ada elemen yang berlebihan dalam struktur seperti itu. Mengapa kita memerlukan tester di setiap departemen, jika Anda dapat memiliki departemen penguji khusus? Yang saya jawab: kelebihan biaya dalam hal ini adalah harga untuk memastikan bahwa di masa depan seluruh organisasi menjadi tipe "E". Dalam struktur ini, tester secara bertahap belajar tentang jaringan, arsitektur, desain, dll. Akibatnya, setiap anggota organisasi sepenuhnya menyadari segala sesuatu yang terjadi dalam organisasi. Jika Anda ingin tahu cara kerja sirkuit ini di industri, lihat Mike Rother, Toyota Kata .

7. Shift-left auditor: audit pada tahap awal siklus. Kepatuhan terhadap peraturan keselamatan

Inilah saatnya tindakan Anda tidak lulus, jadi, tes bau. Orang-orang yang bekerja untuk Anda tidak bodoh. Jika mereka, seperti dalam contoh di atas, di mana-mana menunjukkan dampak kecil / tidak ada, ini berlangsung tiga tahun, dan tidak ada yang memperhatikan apa pun, maka semua orang tahu bahwa sistem tidak berfungsi. Atau contoh lain adalah dewan penasehat perubahan, di mana setiap, katakanlah, lingkungan perlu dilaporkan. Sekelompok orang bekerja di sana (omong-omong, tidak dibayar terlalu tinggi), yang secara teori harus tahu bagaimana sistem bekerja secara keseluruhan. Dan selama lima tahun terakhir, Anda mungkin memperhatikan bahwa sistem kami sangat kompleks. Dan lima atau enam orang harus memutuskan perubahan yang tidak mereka lakukan dan bahwa mereka tidak tahu apa-apa.

Tentu saja, pendekatan ini tidak berhasil. Saya harus menyingkirkan hal-hal seperti itu, karena orang-orang ini tidak melindungi sistem. Keputusan harus dibuat oleh tim itu sendiri, karena tim harus bertanggung jawab untuk itu. Jika tidak, situasi paradoks muncul ketika manajer, yang tidak pernah menulis kode dalam hidupnya, memberi tahu programmer berapa lama untuk menulis kode. Di satu perusahaan tempat saya bekerja, ada 7 tips berbeda yang melihat setiap perubahan, termasuk arsitektur, produk, dan sebagainya. Bahkan ada masa tunggu wajib, meskipun seorang karyawan mengatakan kepada saya bahwa dalam sepuluh tahun bekerja, tidak ada seorang pun dalam periode wajib ini yang pernah menolak perubahan yang dilakukan oleh orang ini.

Auditor harus dipanggil untuk diri mereka sendiri, dan tidak menyingkirkan mereka. Beri tahu mereka bahwa Anda menulis wadah biner yang tidak dapat diubah yang, jika semua tes lulus, tetap tidak berubah selamanya. Beri tahu mereka Anda memiliki pipeline sebagai kode dan jelaskan apa artinya itu. Perlihatkan kepada mereka diagram berikut: biner read-only yang tidak dapat diubah dalam sebuah wadah yang lulus semua tes kerentanan; dan kemudian, tidak hanya orang yang menyentuhnya - mereka bahkan tidak menyentuh sistem yang membuat pipa, karena itu juga dibuat secara dinamis. Saya punya klien, Capital One, yang menggunakan Vault untuk membuat sesuatu seperti blockchain. Anda tidak dapat menunjukkan "resep" dari Chef ke auditor, cukup tunjukkan blockchain, yang jelas apa yang terjadi pada tiket Jira dalam produksi dan siapa yang bertanggung jawab untuk itu.

Menurut laporan itudibuat oleh Sonatype pada tahun 2018, ada 87 miliar permintaan unduhan OSS pada tahun 2017.

Kerentanan yang timbul adalah penghalang. Selain itu, angka-angka yang Anda lihat di atas tidak termasuk biaya peluang. Singkatnya tentang apa itu DevSecOps. Saya ingin segera mengatakan bahwa saya tidak tertarik membicarakan seberapa sukses nama ini. Intinya adalah karena DevOps sangat sukses, Anda perlu mencoba menambahkan keamanan ke saluran ini.

Contoh urutan seperti

ini : Ini bukan rekomendasi untuk produk tertentu, meskipun saya suka semuanya. Saya mengutip mereka sebagai contoh untuk menunjukkan bahwa DevOps, yang awalnya didasarkan pada paradigma organisasi dalam industri, memungkinkan Anda untuk mengotomatisasi setiap tahap pekerjaan pada suatu produk.

Dan tidak ada alasan mengapa kita tidak bisa mengambil pendekatan keamanan yang sama.

Total

Sebagai kesimpulan, saya akan memberikan beberapa tips untuk DevSecOps. Anda perlu menyertakan auditor dalam proses menciptakan sistem Anda, menghabiskan waktu untuk pendidikan mereka. Penting untuk bekerja sama dengan auditor. Lebih jauh, perlu untuk melakukan perlawanan yang benar-benar kejam terhadap hal-hal positif yang salah. Bahkan dengan alat pemindaian kerentanan yang paling mahal, Anda akhirnya dapat menciptakan kebiasaan yang sangat buruk bagi pengembang Anda jika Anda tidak tahu apa itu rasio signal-to-noise. Pengembang akan kelebihan beban dengan acara, dan mereka hanya akan menghapusnya. Jika Anda mendengar cerita dengan Equifax, maka itulah yang terjadi di sana, sinyal tingkat bahaya tertinggi diabaikan di sana. Selain itu, kerentanan perlu dijelaskan sehingga jelas bagaimana mereka mempengaruhi bisnis. Sebagai contoh, kita dapat mengatakan bahwa ini adalah kerentanan yang sama seperti dalam cerita Equifax. Kerentanan KeamananAnda perlu mempertimbangkan cara yang sama seperti masalah lain dengan perangkat lunak, yaitu, mereka harus dimasukkan dalam proses keseluruhan DevOps. Anda perlu bekerja dengan mereka melalui Jira, Kanban, dll. Pengembang seharusnya tidak berpikir bahwa orang lain akan melakukan ini, sebaliknya, semua orang harus melakukannya. Akhirnya, Anda perlu menghabiskan energi untuk mendidik orang.

tautan yang bermanfaat

Berikut adalah beberapa pembicaraan dari konferensi DevOops yang mungkin bermanfaat bagi Anda:

Sergey Berdnikov, Artyom Kalichkin - Kisah Sukses, atau “Dev + DevOps + Ops” ( video , transkrip laporan )
Baruch Sadogursky, Leonid Igolnik - DevOps dalam skala: Tragedi Yunani dalam tiga babak ( video , transkrip laporan )
Alexander Titov, Kirill Tolkachev - DevOps, insinyur dan komunitas
Timothy Lister - Karakter, komunitas, dan budaya: Faktor penting untuk kemakmuran

Mengambil lihat di dalam DevOops 2020 Moskow Program - ada juga banyak hal menarik di sana.

Tujuh Pola Dasar Transformasi DevOps