Smashing Podcast Episode 42 Dengan Jeff Smith: Apa Itu DevOps?

Dalam episode ini, kita berbicara tentang DevOps. Apa itu, dan apakah itu string untuk ditambahkan ke haluan pengembangan web Anda? Drew McLellan berbicara dengan ahli Jeff Smith untuk mencari tahu.

Tampilkan Catatan

• Jeff di Twitter
• Buku Jeff Operations Anti-Patterns, DevOps Solutions
• DevOps yang Dapat Dicapai

Update mingguan

• Menjembatani Kesenjangan Antara Desainer dan Pengembang yang ditulis oleh Matthew Talebi
• React API yang Berguna Untuk Membangun Komponen Fleksibel Dengan TypeScript yang ditulis oleh Gaurav Khanna
• Solusi Smart CSS Untuk Tantangan UI Umum yang ditulis oleh Cosima Mielke
• Tips Dan Trik Untuk Mengevaluasi Desainer UX/UI yang ditulis oleh Nataliya Sambir
• Memecahkan Masalah CLS Di Situs Web E-Commerce Bertenaga Next.js yang ditulis oleh Arijit Mondal

Salinan

Drew McLellan: Dia adalah seorang praktisi DevOps yang berfokus pada tingkat implementasi DevOps yang dapat dicapai, di mana pun Anda berada dalam perjalanan Anda. Dia direktur operasi produksi di platform periklanan digital Centro, serta menjadi pembicara publik, berbagi pengetahuan DevOps dengan audiens di seluruh dunia. Dia adalah penulis buku, Operations Anti-Patterns, DevOps Solutions for Manning Publishing, yang menunjukkan cara menerapkan teknik DevOps di lingkungan yang tidak sempurna yang digunakan sebagian besar pengembang. Jadi kami tahu dia ahli dalam DevOps, tapi tahukah Anda George Clooney menganggapnya sebagai pembuat pesawat kertas terbaik dalam satu generasi? Teman-teman Smashing saya, tolong sambut Jeff Smith. hai jeff. Apa kabar?

Jeff Smith: Saya hebat, Drew, bagaimana kabarmu?

Drew: Aku baik-baik saja. Terima kasih. Itu terdengar baik. Jadi saya ingin berbicara dengan Anda hari ini tentang subjek DevOps, yang merupakan salah satu area utama Anda. Banyak pendengar kami akan terlibat dalam pengembangan web dan aplikasi, tetapi mungkin hanya memiliki sedikit pemahaman tentang apa yang terjadi di sisi operasi. Saya tahu kita yang mungkin bekerja di perusahaan besar akan memiliki seluruh tim rekan kerja yang melakukan operasi. Kami hanya bersyukur bahwa apa pun yang mereka lakukan, mereka melakukannya dengan baik. Tetapi kami mendengar DevOps semakin banyak disebutkan, dan rasanya seperti salah satu hal yang sebagai pengembang, kami harus benar-benar pahami. Jadi Jeff, apa itu DevOps?

Jeff: Jadi jika Anda bertanya kepada 20 orang apa itu DevOps, Anda mungkin mendapatkan 20 jawaban yang berbeda. Jadi saya akan memberikan pendapat saya tentang itu, baiklah, dan ketahuilah bahwa jika Anda berada di sebuah konferensi dan Anda menyebutkan ini, Anda bisa berkelahi dengan seseorang. Tapi bagi saya, DevOps benar-benar tentang hubungan antara, dan kami fokus pada dev dan ops, tetapi sebenarnya hubungan antar tim dan bagaimana kami menyusun pekerjaan kami dan yang lebih penting, menyusun tujuan dan insentif kami untuk memastikan bahwa mereka selaras sehingga kita bekerja menuju tujuan bersama. Dan banyak ide dan konsep inti dari DevOps berasal dari dunia lama di mana dev dan ops selalu bermusuhan, di mana selalu ada konflik ini. Dan ketika Anda memikirkannya, itu karena cara kedua tim itu diberi insentif. Satu tim diberi insentif untuk mendorong perubahan. Tim lain diberi insentif untuk menjaga stabilitas, yang berarti lebih sedikit perubahan.

Jeff: Ketika Anda melakukan itu, Anda menciptakan konflik yang melekat ini dan semuanya tumpah dari sana. Jadi DevOps benar-benar tentang menyelaraskan tim dan tujuan tersebut sehingga kami bekerja menuju strategi bersama, tetapi kemudian juga mengadopsi praktik dari kedua belah pihak, sehingga dev lebih memahami tentang ops dan ops lebih memahami tentang dev, sebagai cara untuk mendapatkan dan berbagi empati satu sama lain sehingga kita memahami perspektif dari mana orang lain itu berasal.

Jeff: Tapi kemudian juga untuk meningkatkan pekerjaan kami. Karena sekali lagi, jika saya memahami perspektif Anda dan memperhitungkannya dalam pekerjaan saya, itu akan jauh lebih bermanfaat bagi kita masing-masing. Dan ada banyak hal yang dapat dipelajari ops dari pengembang dalam hal otomatisasi dan bagaimana kami melakukan pendekatan sehingga mereka dapat dengan mudah direproduksi. Jadi ini pencampuran dan keterampilan. Dan apa yang Anda lihat sekarang adalah bahwa ini berlaku untuk kombinasi grup yang berbeda, jadi Anda mendengar hal-hal seperti DevSecOps, DevSecFinOps, DevSecFinHROps. Itu hanya akan terus tumbuh dan tumbuh dan berkembang. Jadi ini benar-benar pelajaran yang bisa kita terapkan di seluruh organisasi.

Drew: Jadi ini mengambil beberapa konsep yang kami pahami sebagai pengembang dan menyebarkan ide kami lebih jauh ke dalam organisasi, dan pada saat yang sama mempelajari apa yang kami dapat dari operasi untuk mencoba dan memajukan semua orang.

Jeff: Tentu saja, ya. Dan aspek lain dari ops, dan Anda telah menyebutkannya sedikit di intro, kami pikir itu hanya untuk organisasi yang lebih besar dengan tim ops khusus dan hal-hal seperti itu, tetapi satu hal yang perlu dipikirkan adalah ops terjadi di organisasi Anda, terlepas dari ukurannya. Ini hanya masalah apakah Anda melakukannya, atau jika ada tim terpisah yang melakukannya, tetapi entah bagaimana Anda menerapkan kode. Entah bagaimana Anda punya server di luar sana yang berjalan di suatu tempat. Jadi ops ada di suatu tempat di organisasi Anda, terlepas dari ukurannya. Pertanyaannya, siapa yang melakukannya? Dan jika itu adalah satu orang atau satu grup maka DevOps bahkan mungkin lebih menonjol bagi Anda, karena Anda perlu memahami jenis hal yang dilakukan ops.

Drew: Sebagai pengembang profesional, menurut Anda seberapa penting bagi kami untuk memiliki pemahaman yang baik tentang apa itu DevOps dan apa artinya untuk diimplementasikan?

Jeff: Saya pikir ini sangat penting, terutama pada fase perjalanan DevOps ini. Dan alasan yang menurut saya penting adalah, saya pikir kita selalu lebih efisien, sekali lagi, ketika kita memahami apa yang dilakukan rekan kita. Tetapi hal lain adalah untuk dapat mempertimbangkan masalah operasional selama pengembangan desain Anda dan penerapan teknologi apa pun. Jadi satu hal yang saya pelajari dalam karir saya adalah bahwa meskipun saya pikir pengembang adalah penguasa alam semesta dan memahami segala sesuatu yang berkaitan dengan komputer, ternyata itu tidak benar-benar terjadi. Ternyata ada banyak hal yang mereka alihkan ke ops dalam hal pemahaman, dan terkadang itu menghasilkan pilihan desain tertentu atau pilihan implementasi yang mungkin tidak optimal untuk penyebaran produksi.

Jeff: Mereka mungkin baik-baik saja dalam pengembangan dan pengujian dan hal-hal seperti itu, tetapi begitu Anda sampai ke produksi, itu adalah permainan bola yang sedikit berbeda. Jadi bukan untuk mengatakan bahwa mereka perlu memiliki seluruh rangkaian keahlian itu, tetapi mereka setidaknya perlu cukup tahu untuk mengetahui apa yang tidak mereka ketahui. Jadi mereka tahu kapan harus melakukan operasi lebih awal, karena pola umum yang kami lihat adalah pengembangan membuat pilihan. Saya bahkan tidak akan mengatakan buat pilihan karena mereka bahkan tidak menyadari bahwa itu adalah pilihan, tetapi ada sesuatu yang terjadi yang mengarah pada keputusan suboptimal untuk operasi dan pengembangan sama sekali tidak disadari. Jadi hanya memiliki sedikit lebih banyak pengetahuan tentang ops, bahkan jika itu hanya cukup untuk mengatakan, mungkin kita harus membawa ops dalam hal ini untuk mendapatkan perspektif mereka sebelum kita melanjutkan. Itu bisa menghemat banyak waktu dan energi dan stabilitas, tentu saja, karena berkaitan dengan produk apa pun yang Anda rilis.

Drew: Saya melihat begitu banyak kesamaan dengan cara Anda berbicara tentang hubungan antara dev dan ops seperti yang kita miliki antara desain dan dev, di mana Anda memiliki desainer yang mengerjakan mungkin bagaimana antarmuka bekerja dan terlihat dan memiliki pemahaman yang baik tentang bagaimana itu sebenarnya akan dibangun dalam peran pengembangan, dan membawa pengembang untuk berkonsultasi benar-benar dapat meningkatkan solusi keseluruhan hanya dengan memiliki komunikasi yang jelas dan pemahaman tentang apa yang dilakukan satu sama lain. Sepertinya prinsip yang sama dimainkan dengan DevOps, yang sangat, sangat bagus untuk didengar.

Drew: Ketika saya memikirkan hal-hal yang saya dengar tentang DevOps, saya mendengar istilah-istilah seperti Kubernetes, Docker, Jenkins, CircleCI. Saya telah mendengar tentang Kubernetes selama bertahun-tahun. Saya masih tidak tahu apa itu, tetapi dari apa yang Anda katakan, tampaknya DevOps bukan hanya tentang ... Kami tidak hanya berbicara tentang alat di sini, bukan? Tetapi lebih banyak tentang proses dan cara berkomunikasi pada alur kerja, benarkah?

Jeff: Tentu saja. Jadi mantra saya selama 20 tahun terakhir selalu menjadi alat proses orang. Anda mendapatkan orang untuk membeli ke dalam visi. Dari sana, Anda menentukan seperti apa proses Anda nantinya untuk mencapai visi itu. Dan kemudian Anda membawa alat yang akan memodelkan apa pun proses Anda. Jadi saya selalu menempatkan alat di ujung akhir percakapan DevOps, terutama karena jika Anda tidak memiliki persetujuan itu, maka itu tidak masalah. Saya dapat menemukan jalur penyebaran berkelanjutan terbesar yang pernah ada, tetapi jika orang tidak setuju dengan gagasan untuk mengirimkan setiap perubahan langsung ke produksi, itu tidak masalah, bukan? Apa bagusnya alat itu? Jadi alat-alat itu jelas merupakan bagian dari percakapan, hanya karena itu adalah cara standar untuk memenuhi beberapa tujuan umum yang telah kami tetapkan.

Jeff: Tetapi Anda harus memastikan bahwa tujuan yang ditetapkan itu masuk akal bagi organisasi Anda. Mungkin penerapan berkelanjutan tidak masuk akal bagi Anda. Mungkin Anda tidak ingin mengirimkan setiap perubahan begitu keluar. Dan ada banyak perusahaan dan organisasi dan alasan mengapa Anda tidak ingin melakukan itu. Jadi mungkin sesuatu seperti pipa penyebaran berkelanjutan tidak masuk akal bagi Anda. Jadi, meskipun alat itu penting, lebih penting untuk fokus pada apa yang akan memberikan nilai bagi organisasi Anda, lalu memodelkan dan mengimplementasikan alat yang diperlukan untuk mencapainya.

Jeff: Tapi jangan online dan cari tahu apa yang dilakukan semua orang dan jadilah seperti, oh, well, jika kita akan melakukan DevOps, kita harus beralih ke Docker dan Kubernetes karena itulah rantai alatnya. Tidak, bukan itu. Anda mungkin tidak membutuhkan hal-hal itu. Tidak semua orang adalah Google. Tidak semua orang adalah Netflix. Berhenti membaca postingan dari Netflix dan Google. Tolong berhenti membacanya. Karena itu membuat semua orang bersemangat dan mereka suka, inilah yang harus kita lakukan. Dan itu seperti, yah, mereka memecahkan masalah yang sangat berbeda dari masalah yang Anda miliki.

Drew: Jadi jika saya memulai proyek baru, mungkin saya adalah bisnis pemula, membuat perangkat lunak sebagai produk layanan. Saya punya tiga pengembang, saya punya repo Git yang kosong dan saya punya impian untuk IPO. Untuk terlibat dalam pendekatan DevOps untuk membangun produk ini, apa nama blok bangunan yang harus saya miliki dalam hal orang dan proses dan di mana saya harus memulai?

Jeff: Jadi dalam contoh spesifik Anda, tempat pertama yang akan saya mulai adalah menyepak sebagian besar sebanyak mungkin dan menggunakan sesuatu seperti Heroku atau sesuatu untuk efek itu. Karena Anda sangat senang dengan semua hal AWS ini, hal-hal Docker, dan pada kenyataannya, sangat sulit untuk membangun produk yang sukses. Gagasan bahwa Anda berfokus pada bagian DevOps itu seperti, baik saya akan mengatakan melakukan outsourcing sebanyak mungkin hal itu sampai benar-benar menjadi titik sakit. Tetapi jika Anda berada pada titik di mana Anda mengatakan oke, kami siap untuk mengambil barang ini di rumah dan kami siap untuk membawanya ke tingkat berikutnya. Saya akan mengatakan tempat pertama untuk memulai adalah, di mana titik rasa sakit Anda? apa hal-hal yang menyebabkan Anda bermasalah?

Jeff: Jadi bagi sebagian orang itu sesederhana pengujian otomatis. Gagasan bahwa hei, kita perlu menjalankan tes setiap kali seseorang membuat komit, karena terkadang kita mengirimkan barang yang tertangkap oleh tes unit yang sudah kita tulis. Jadi mungkin Anda mulai dengan integrasi berkelanjutan. Mungkin penerapan Anda membutuhkan waktu berjam-jam untuk diselesaikan dan sangat manual, lalu di situlah Anda fokus dan Anda berkata seperti, oke, otomatisasi apa yang kami perlukan untuk menjadikan ini urusan satu klik? Tapi saya benci untuk meresepkan seorang jenderal, ini adalah di mana Anda mulai, hanya karena situasi khusus Anda dan poin rasa sakit khusus Anda akan berbeda. Dan masalahnya adalah, jika itu adalah titik sakit, itu harus meneriaki Anda. Ini harus benar-benar berteriak pada Anda.

Jeff: Itu harus menjadi salah satu hal di mana seseorang berkata, oh, apa yang menyebalkan dalam organisasi Anda? Dan seharusnya seperti, oh, saya tahu persis apa itu. Jadi ketika Anda mendekatinya dari perspektif itu, saya pikir langkah selanjutnya menjadi cukup jelas bagi Anda dalam hal apa yang perlu Anda bongkar dan mulai kerjakan di kotak alat DevOps. Dan kemudian menjadi perubahan tambahan minimal yang terus datang dan Anda melihat bahwa saat Anda mendapatkan kemampuan baru, selera Anda untuk hal-hal di bawah standar menjadi sangat kecil. Jadi Anda beralih dari seperti, oh ya, penyebaran membutuhkan waktu tiga jam dan tidak apa-apa. Anda berusaha keras dan hal berikutnya yang Anda tahu, dalam tiga minggu, Anda seperti, kawan, saya tidak percaya penerapannya masih memakan waktu 30 menit. Bagaimana kita menurunkan ini dari 30 menit? Nafsu makan Anda menjadi tak terpuaskan untuk perbaikan. Jadi hal-hal seperti tumpah keluar dari sana.

Drew: Saya telah membaca buku terbaru Anda dan itu menyoroti apa yang Anda sebut empat pilar DevOps. Dan tidak satupun dari mereka adalah alat, seperti yang disebutkan, tetapi ada empat area fokus utama ini, jika Anda suka, untuk DevOps. Saya perhatikan bahwa yang pertama adalah budaya, saya cukup terkejut dengan itu, pertama, karena saya mengharapkan Anda untuk berbicara lebih banyak tentang alat dan kami sekarang mengerti mengapa, tetapi ketika datang ke budaya, itu sepertinya aneh. hal yang harus dimiliki di awal. Ada dasar untuk pendekatan teknis. Bagaimana budaya memengaruhi seberapa sukses implementasi DevOps dalam suatu organisasi?

Drew: … seberapa sukses implementasi DevOps dalam sebuah organisasi.

Jeff: Budaya benar-benar merupakan landasan segala sesuatu ketika Anda memikirkannya. Dan itu penting karena budaya, dan kita membahasnya sedikit lebih dalam di buku ini, tetapi budaya benar-benar mengatur panggung untuk norma dalam organisasi. Benar. Anda mungkin pernah berada di perusahaan di mana, jika Anda mengirimkan PR tanpa pengujian otomatis, itu bukan masalah besar. Orang-orang menerimanya dan melanjutkan.

Jeff: Tapi kemudian ada organisasi lain di mana itu adalah dosa besar. Benar. Di mana jika Anda telah melakukan itu, itu seperti, “Whoa, apakah kamu gila? Apa yang kamu lakukan? Tidak ada kasus uji di sini. ” Benar. Padahal itu budaya. Itu adalah budaya yang menegakkan norma itu untuk mengatakan seperti, "Ini bukan apa yang kita lakukan."

Jeff: Siapa pun dapat menulis dokumen yang mengatakan bahwa kami akan memiliki kasus uji otomatis, tetapi budaya organisasilah yang memberlakukan mekanisme itu di antara orang-orang. Itu hanya satu contoh kecil mengapa budaya begitu penting. Jika Anda memiliki organisasi di mana budayanya adalah budaya ketakutan, budaya pembalasan. Ini seperti jika Anda membuat kesalahan, kan, itu penistaan. Benar. Itu sama saja dengan pengkhianatan. Benar.

Jeff: Anda menciptakan perilaku dalam organisasi itu yang merugikan apa pun yang bisa berisiko atau berpotensi gagal. Dan itu akhirnya meninggalkan banyak peluang di atas meja. Sedangkan jika Anda menciptakan budaya yang merangkul belajar dari kegagalan, merangkul gagasan keamanan psikologis ini, di mana orang dapat bereksperimen. Dan jika mereka salah, mereka dapat menemukan cara untuk gagal dengan aman dan mencoba lagi. Anda mendapatkan budaya eksperimen. Anda mendapatkan sebuah organisasi di mana orang-orang terbuka untuk ide-ide baru.

Jeff: Saya pikir kita semua pernah berada di perusahaan yang seperti, “Yah, beginilah caranya. Dan tidak ada yang mengubah itu.” Benar. Anda tidak menginginkan itu karena dunia terus berubah. Itu sebabnya kami menempatkan budaya di depan dan di tengah, karena banyak perilaku dalam suatu organisasi ada karena budaya yang ada.

Jeff: Dan masalahnya, aktor budaya bisa baik atau buruk. Benar. Yang ironis, dan kita juga membicarakan hal ini di buku ini, adalah tidak perlu banyak orang seperti yang Anda pikirkan untuk mengubah budaya organisasi. Benar. Karena kebanyakan orang, ada pencela, dan kemudian ada pendukung, dan kemudian ada penjaga pagar ketika datang ke segala jenis perubahan. Dan kebanyakan orang adalah pengasuh pagar. Benar. Hanya dibutuhkan segelintir pendukung untuk benar-benar memberi tip pada timbangan. Tetapi dalam arti yang sama, hanya dibutuhkan segelintir pencela untuk memberi tip pada timbangan.

Jeff: Sepertinya, tidak perlu banyak mengubah budaya menjadi lebih baik. Dan jika Anda memasukkan energi itu ke dalamnya, bahkan tanpa menjadi pemimpin senior, Anda benar-benar dapat memengaruhi budaya tim Anda, yang pada akhirnya memengaruhi budaya departemen Anda, yang pada akhirnya memengaruhi budaya organisasi.

Jeff: Anda dapat membuat perubahan budaya ini sebagai kontributor individu, hanya dengan mendukung gagasan dan perilaku ini dengan lantang dan mengatakan, "Inilah manfaat yang kami dapatkan dari ini." Itulah mengapa saya pikir budaya harus menjadi yang terdepan karena Anda harus membuat semua orang setuju dengan ide ini dan mereka harus memahami bahwa, sebagai sebuah organisasi, itu akan bermanfaat dan mendukungnya.

Drew: Ya. Itu harus menjadi cara hidup, kurasa.

Jef: Tepat.

Drew: Ya. Saya sangat tertarik dengan bidang otomasi karena sepanjang karir saya, saya belum pernah melihat otomasi yang tidak bermanfaat. Benar. Maksud saya, terlepas dari hal yang aneh mungkin di mana ada sesuatu yang otomatis dan terjadi kesalahan. Umumnya, ketika Anda meluangkan waktu untuk duduk dan mengotomatiskan sesuatu yang telah Anda lakukan secara manual, itu selalu menghemat waktu Anda dan menghemat ruang kepala Anda, dan itu hanya beban dari bahu Anda.

Drew: Dalam mengambil pendekatan DevOps, hal-hal seperti apa yang ingin Anda otomatisasi dalam alur kerja Anda? Dan keuntungan apa yang Anda harapkan dari menyelesaikan hal-hal secara manual?

Jeff: Dalam hal otomatisasi, menurut pendapat Anda, sangat jarang ada saat di mana otomatisasi tidak membuat hidup lebih baik. Benar. Masalah yang dihadapi orang adalah menemukan waktu untuk membangun otomatisasi itu. Benar. Dan biasanya, di pekerjaan saya saat ini, bagi kami itu sebenarnya inti dari permintaan. Benar. Karena pada titik tertentu Anda harus mengatakan, "Saya akan berhenti melakukan ini secara manual dan saya akan mengotomatiskannya."

Jeff: Dan mungkin itu saatnya Anda mendapatkan permintaan di mana Anda berkata, “Tahukah Anda? Ini akan memakan waktu dua minggu. Saya tahu kami biasanya membalikkannya dalam beberapa jam, tetapi ini akan memakan waktu dua minggu karena ini adalah permintaan yang diotomatisasi. ” Dalam hal mengidentifikasi apa yang Anda otomatisasi. Di Central, saya menggunakan proses di mana pada dasarnya, saya akan mencicipi semua jenis permintaan berbeda yang datang selama periode empat minggu, katakanlah. Dan saya akan mengkategorikannya sebagai pekerjaan yang direncanakan, pekerjaan yang tidak direncanakan, pekerjaan yang menambah nilai, kerja keras. Kerja keras menjadi pekerjaan yang tidak terlalu berguna, tetapi untuk beberapa alasan, organisasi saya harus melakukannya.

Jeff: Dan kemudian mengidentifikasi hal-hal seperti, “Oke, apa buah gantung rendah yang bisa kita singkirkan jika kita mengotomatiskannya? Apa yang bisa kita lakukan untuk menyederhanakan ini?” Dan beberapa kriteria adalah risiko proses. Benar. Kegagalan database otomatis sedikit menakutkan karena Anda tidak sering melakukannya. Dan perubahan infrastruktur. Benar. Kita berkata, “Seberapa sering kita melakukan hal ini?” Jika kita melakukannya setahun sekali, mungkin tidak layak untuk diotomatisasi karena nilainya sangat kecil. Tapi jika itu salah satu dari hal-hal yang kita dapatkan dua, tiga kali sebulan, oke, mari kita lihat itu. Baiklah.

Jeff: Sekarang, apa yang bisa kita lakukan untuk mempercepat ini? Dan masalahnya adalah, ketika kita berbicara tentang otomatisasi, kita langsung melompat ke, "Saya akan mengklik tombol dan hal ini akan dilakukan secara ajaib." Benar. Tetapi ada begitu banyak langkah berbeda yang dapat Anda lakukan dalam otomatisasi jika Anda merasa mual. Benar. Misalnya, Anda memiliki 10 langkah dengan 10 perintah CLI berbeda yang biasanya Anda jalankan. Langkah otomatisasi pertama Anda bisa sesederhana, jalankan perintah itu, atau setidaknya tunjukkan perintah itu. Benar. Katakan, “Hei, ini yang akan saya eksekusi. Apa menurutmu tidak apa-apa?” "Ya." "Baik. Ini adalah hasil yang saya dapatkan. Apakah tidak apa-apa bagi saya untuk melanjutkan? ” "Ya." "Baik. Inilah hasil yang saya dapatkan.” Benar.

Jeff: Dengan begitu Anda masih punya sedikit kendali. Anda merasa nyaman. Dan kemudian setelah 20 eksekusi, Anda menyadari bahwa Anda baru saja memukul, ya, ya, ya, ya, ya, ya. Anda berkata, “Baiklah. Mari kita rantai semua hal ini bersama-sama dan membuat semuanya menjadi satu.” Ini tidak seperti Anda harus melompat ke ujung yang dalam, klik dan lupakan saja. Anda dapat melangkah ke ini sampai Anda merasa nyaman.

Jeff: Itu adalah jenis hal yang kami lakukan sebagai bagian dari upaya otomatisasi kami secara sederhana, bagaimana kami mempercepat waktu penyelesaian ini dan mengurangi tingkat upaya di pihak kami? Ini mungkin tidak 100% hari pertama, tetapi tujuannya selalu untuk mencapai 100%. Kita akan mulai dengan potongan kecil yang kita akan mengotomatiskan bagian-bagian yang kita rasa nyaman. Ya. Kami merasa sangat yakin bahwa ini akan berhasil. Bagian ini sedikit tidak pasti, jadi mungkin kita akan mendapatkan beberapa verifikasi manusia sebelum melanjutkan.

Jeff: Hal lain yang kami lihat dalam hal kami berbicara tentang otomatisasi, tetapi apakah nilai yang kami tambahkan ke proses tertentu? Dan ini sangat penting untuk operasi. Karena seringkali ops berfungsi sebagai perantara untuk suatu proses. Maka keterlibatan mereka tidak lebih dari beberapa hal akses. Benar. Sepertinya, ops harus melakukannya karena ops adalah satu-satunya orang yang memiliki akses.

Jeff: Yah, seperti, bagaimana kita mengalihdayakan akses itu sehingga orang bisa melakukannya? Karena kenyataannya, kami tidak khawatir tentang pengembang yang memiliki akses produksi. Benar. Kami khawatir tentang pengembang yang memiliki akses produksi yang tidak terbatas. Dan itu benar-benar masalah keamanan. Benar. Ini seperti jika kotak peralatan saya hanya memiliki pisau tajam, saya akan sangat berhati-hati dengan siapa saya memberikannya. Tetapi jika saya dapat mencampur kotak peralatan dengan sendok dan palu sehingga orang dapat memilih alat yang tepat untuk pekerjaan itu, maka akan jauh lebih mudah untuk meminjamkannya.

Jeff: Misalnya, kami memiliki proses di mana orang perlu menjalankan skrip Ruby ad hoc dalam produksi, untuk alasan apa pun. Benar. Perlu membersihkan data, perlu memperbaiki beberapa catatan buruk, apa pun. Dan itu akan selalu datang melalui tim saya. Dan itu seperti, yah, kami tidak menambahkan nilai apa pun untuk ini karena saya tidak dapat menyetujui tiket ini. Benar. Saya tidak punya ide. Anda yang menulis perangkat lunaknya, jadi apa untungnya saya duduk di atas bahu Anda dan berkata, "Yah, saya pikir itu aman"? Benar. Saya tidak menambahkan nilai apa pun untuk mengetiknya karena saya hanya mengetik persis seperti yang Anda suruh saya ketik. Benar.

Jeff: Dan kasus terburuk, dan pada akhirnya, saya benar-benar hanya penghalang bagi Anda karena Anda mengirimkan tiket, lalu Anda menunggu saya kembali dari makan siang. Saya kembali dari makan siang, tetapi saya memiliki hal-hal lain untuk dikerjakan. Kami berkata, "Bagaimana kami mengotomatiskan ini sehingga kami dapat menyerahkan ini ke tangan pengembang sementara pada saat yang sama menangani masalah audit yang mungkin kami miliki?"

Jeff: Kami memasukkannya ke dalam alur kerja JIRA, di mana kami memiliki bot yang akan mengotomatiskan eksekusi perintah yang ditentukan dalam tiket JIRA. Dan kemudian kami dapat menentukan dalam tiket JIRA bahwa itu memerlukan persetujuan dari salah satu dari beberapa insinyur senior. Benar.

Jeff: Lebih masuk akal jika seorang insinyur menyetujui pekerjaan insinyur lain karena mereka memiliki konteksnya. Benar. Mereka tidak harus duduk-duduk menunggu operasi. Bagian audit dijawab karena kami memiliki alur kerja yang jelas yang telah ditentukan dalam JIRA yang didokumentasikan sebagai persetujuan seseorang, seperti yang diminta seseorang. Dan kami memiliki otomatisasi yang menarik perintah itu dan menjalankan perintah itu kata demi kata di terminal. Benar.

Jeff: Anda tidak perlu khawatir saya salah ketik. Anda tidak perlu khawatir saya mengambil tiket yang salah. Itu meningkatkan waktu penyelesaian untuk tiket itu, kira-kira sepuluh kali lipat. Benar. Pengembang tidak diblokir. Tim saya tidak terikat melakukan ini. Dan yang diperlukan hanyalah investasi satu atau dua minggu untuk benar-benar mengembangkan otomatisasi dan izin yang diperlukan agar mereka dapat mengaksesnya.

Jeff: Sekarang kami benar-benar dihapus dari itu. Dan pengembangan sebenarnya mampu mengalihdayakan beberapa fungsi itu ke bagian bawah organisasi. Mereka telah mendorongnya ke layanan pelanggan. Ini seperti sekarang ketika layanan pelanggan tahu bahwa catatan ini perlu diperbarui untuk apa pun, mereka tidak perlu pengembangan. Mereka dapat mengirimkan skrip standar mereka yang telah kami setujui untuk fungsi ini. Dan mereka dapat menjalankannya melalui alur kerja yang sama persis dengan yang dilakukan pengembangan. Ini benar-benar anugerah di sekitar.

Jeff: Dan kemudian memungkinkan kita untuk mendorong pekerjaan lebih rendah dan lebih rendah di seluruh organisasi. Karena saat kami melakukan itu, pekerjaan menjadi lebih murah dan lebih murah karena saya bisa memiliki pengembang mahal dan mewah yang menjalankan ini. Benar. Atau saya dapat meminta petugas layanan pelanggan yang bekerja langsung dengan pelanggan, menjalankannya sendiri saat mereka sedang berbicara di telepon dengan pelanggan yang memperbaiki masalah.

Jeff: Otomasi saya pikir, adalah kunci untuk setiap organisasi. Dan poin terakhir yang akan saya katakan adalah, ini juga memungkinkan Anda untuk mengekspor keahlian. Benar. Sekarang, saya mungkin satu-satunya orang yang tahu bagaimana melakukan ini jika saya perlu melakukan banyak perintah pada baris perintah. Tetapi jika saya memasukkan ini ke dalam otomatisasi, saya dapat memberikannya kepada siapa pun. Dan orang-orang tahu apa hasil akhirnya, tetapi mereka tidak perlu mengetahui semua langkah perantara. Saya telah meningkatkan nilai saya sepuluh kali lipat dengan mendorongnya ke organisasi dan mengambil keahlian saya dan mengkodifikasikannya menjadi sesuatu yang dapat diekspor.

Drew: Anda berbicara tentang mengotomatisasi tugas yang sering terjadi. Apakah ada argumen untuk juga mengotomatisasi tugas yang jarang terjadi sehingga pengembang membutuhkan waktu yang cukup lama untuk kembali ke kecepatan dengan cara kerjanya? Karena semua orang sudah lupa. Sudah lama. Sudah setahun, mungkin tidak ada yang pernah melakukannya sebelumnya. Apakah ada argumen untuk mengotomatiskan hal-hal semacam itu juga?

Jeff: Itu tindakan penyeimbangan yang sulit. Benar. Dan saya selalu mengatakan ambil kasus per kasus. Dan alasan saya mengatakan itu adalah, salah satu mantra di DevOps adalah jika sesuatu yang menyakitkan, lakukan lebih sering. Benar. Karena semakin sering Anda melakukannya, semakin banyak memori otot jadinya dan Anda bisa berolahraga dan menghilangkan kekusutan itu.

Jeff: Masalah yang kami lihat dengan mengotomatisasi tugas yang sangat jarang adalah bahwa lanskap lingkungan cenderung berubah di antara eksekusi otomatisasi itu. Benar. Apa yang akhirnya terjadi adalah kode Anda membuat asumsi khusus tentang lingkungan dan asumsi itu tidak lagi valid. Jadi otomatisasi akhirnya rusak.

Drew: Dan kemudian Anda punya dua masalah.

Jef: Benar. Benar. Tepat. Tepat. Dan Anda seperti, “Apakah saya salah mengetik? Atau ini? Tidak, benda ini benar-benar rusak.” Jadi-

Jeff: Salah ketik atau ini tidak, ini benar-benar rusak. Jadi ketika datang untuk mengotomatisasi tugas-tugas yang jarang, kami benar-benar mengambil kasus per kasus untuk memahami, baik, apa risikonya jika ini tidak berhasil, kan. Jika kita salah, apakah kita dalam keadaan buruk atau hanya karena kita belum menyelesaikan tugas ini? Jadi, jika Anda dapat memastikan bahwa ini akan gagal dengan baik dan tidak berdampak negatif, maka ada baiknya mencoba mengotomatiskannya. Karena setidaknya, Anda memiliki kerangka pemahaman tentang apa yang seharusnya terjadi karena setidaknya, seseorang akan dapat membaca kode dan memahami, baiklah, inilah yang kami lakukan. Dan saya tidak mengerti mengapa ini tidak berhasil lagi, tetapi saya memiliki pemahaman yang jelas tentang apa yang seharusnya terjadi setidaknya berdasarkan waktu desain ketika ini ditulis.

Jeff: Tetapi jika Anda pernah berada dalam situasi di mana kegagalan dapat menyebabkan perubahan data atau semacamnya, saya biasanya berhati-hati dan menyimpannya secara manual hanya karena jika saya memiliki skrip otomatisasi, jika saya menemukan beberapa dokumen pertemuan itu tiga tahun yang mengatakan menjalankan skrip ini, saya cenderung memiliki kepercayaan seratus persen pada skrip itu dan saya menjalankannya. Benar. Sedangkan jika itu serangkaian langkah manual yang didokumentasikan empat tahun lalu, saya akan seperti, saya perlu melakukan verifikasi di sini. Benar? Biarkan saya melangkah melalui ini sedikit dan berbicara dengan beberapa orang. Dan terkadang ketika kita merancang proses, ada baiknya memaksakan proses pemikiran itu, bukan? Dan Anda harus berpikir tentang komponen manusia dan bagaimana mereka akan berperilaku. Dan terkadang ada baiknya membuat prosesnya sedikit lebih rumit untuk memaksa orang berpikir apakah saya harus melakukan ini sekarang?

Drew: Apakah ada cara lain untuk mengidentifikasi apa yang harus diotomatisasi melalui semacam pemantauan sistem Anda dan mengukur sesuatu? Maksud saya, saya memikirkan DevOps dan saya berpikir tentang dasbor sebagai salah satu hal, grafik yang bagus. Dan saya yakin ada lebih banyak dasbor itu daripada sekadar terlihat cantik, tetapi selalu menyenangkan memiliki dasbor yang tampak cantik. Apakah ada cara untuk mengukur apa yang sedang dilakukan sistem, untuk membantu Anda membuat keputusan semacam itu?

Jeff: Tentu saja. Dan semacam itu masuk ke bagian metrik kamera, benar, adalah hal-hal apa yang kami lacak di sistem kami untuk mengetahui bahwa mereka beroperasi secara efisien? Dan salah satu jebakan metrik yang umum adalah kami mencari kesalahan alih-alih memverifikasi keberhasilan. Dan itu adalah dua praktik yang sangat berbeda, bukan? Jadi sesuatu dapat mengalir melalui sistem dan tidak harus keluar dari kesalahan, tetapi tidak harus melalui seluruh proses sebagaimana mestinya. Jadi, jika kita menjatuhkan pesan pada antrean pesan, seharusnya ada metrik terkait yang mengatakan, "Dan pesan ini telah diambil dan diproses," bukan? Jika tidak, ya, Anda akan segera mengalami ketidakseimbangan dan sistem tidak bekerja sebagaimana mestinya. Saya pikir kita dapat menggunakan metrik sebagai cara untuk juga memahami berbagai hal yang harus diotomatisasi saat kita memasuki kondisi buruk tersebut.

Jef: Benar? Karena seringkali itu adalah langkah yang sangat sederhana yang perlu diambil untuk membersihkan semuanya, bukan? Untuk orang-orang yang telah ops untuk sementara waktu, benar, peringatan ruang disk, semua orang tahu tentang itu. Oh, kami penuh dengan disk. Oh, kami lupa itu akhir bulan dan penagihan berjalan dan penagihan selalu mengisi log. Dan kemudian log VAR menghabiskan semua ruang disk, jadi kita perlu menjalankan rotasi log. Benar? Anda bisa bangun jam tiga pagi untuk itu, jika itu pilihan Anda. Tetapi jika kita tahu bahwa itulah perilakunya, metrik kita seharusnya bisa memberi kita petunjuk tentang itu. Dan kita dapat dengan mudah mengotomatiskan perintah rotasi log, bukan? Oh, kami telah mencapai ambang ini, jalankan perintah rotasi log. Mari kita lihat apakah peringatan itu hilang. Jika ya, lanjutkan hidup. Jika tidak, maka mungkin kita membangunkan seseorang, kan.

Jeff: Anda melihat ini lebih banyak dengan otomatisasi infrastruktur juga, benar, di mana itu seperti, “Hei, apakah permintaan kami per detik mencapai maksimum teoretis kami. Mungkin kita perlu menskalakan cluster. Mungkin kita perlu menambahkan tiga atau empat node ke kumpulan penyeimbang beban.” Dan kita bisa melakukannya tanpa harus meminta seseorang untuk campur tangan. Kami hanya dapat melihat metrik tersebut dan mengambil tindakan itu dan kemudian mengontrak infrastruktur itu setelah berada di bawah ambang batas tertentu, tetapi Anda harus memiliki metrik tersebut dan Anda harus memiliki kaitan itu ke lingkungan pemantauan Anda untuk dapat melakukannya. Dan di situlah seluruh bagian metrik dari percakapan masuk.

Jeff: Plus, itu juga bagus untuk dapat berbagi informasi itu dengan orang lain karena begitu Anda memiliki data, Anda dapat mulai berbicara tentang berbagai hal dalam realitas bersama, kan, karena sibuk adalah istilah umum, tetapi 5.200 permintaan per detik adalah sesuatu yang jauh lebih konkret yang bisa kita semua pikirkan. Dan saya pikir begitu sering ketika kami berbicara tentang kapasitas atau apa pun, kami menggunakan istilah bergelombang ini, ketika kami dapat melihat dasbor dan memberikan nilai yang sangat spesifik dan memastikan bahwa setiap orang memiliki akses ke dasbor itu, itu mereka tidak tersembunyi di balik beberapa dinding operasi yang hanya dapat kita akses untuk beberapa alasan yang tidak diketahui.

Drew: So while sort of monitoring and using metrics as a decision-making tool for the businesses is one aspect of it, it sounds like the primary aspect is having the system monitor itself, perhaps, and to respond maybe with some of these automations as the system as a whole gives itself feedback on onto what's happening.

Jeff: Absolutely. Feedback loops are a key part of any real system design, right, and understanding the state of the system at any one time. So while it's easy in the world where everything is working fine, the minute something goes bad, those sorts of dashboards and metrics are invaluable to have, and you'll quickly be able to identify things that you have not instrumented appropriately. Benar. So one of the things that we always talk about in incident management is what questions did you have for the system that couldn't be answered, right. So what is it, or you're like, “Oh man, if we only knew how many queries per second were going on right now.” Benar.

Jeff: Well, okay. How do we get that for next time? How do we make sure that that's radiated somewhere? And a lot of times it's hard when you're thinking green field to sit down and think of all the data that you might want at any one time. But when you have an incident, it becomes readily apparent what data you wish you had. So it's important to sort of leverage those incidents and failures and get a better understanding of information that's missing so that you can improve your incident management process and your metrics and dashboarding.

Drew: One of the problems we sometimes face in development is that teammate members, individual team members hold a lot of knowledge about how a system works and if they leave the company or if they're out sick or on vacation, that knowledge isn't accessible to the rest of the team. It seems like the sort of DevOps approach to things is good at capturing a lot of that operational knowledge and building it into systems. So that sort of scenario where an individual has got all the information in their head that doesn't happen so much. Apakah itu penilaian yang adil?

Jeff: It is. I think we've probably, I think as an industry we might have overstated its efficacy. And the only reason I say that is when our systems are getting so complicated, right? Gone are the days where someone has the entire system in their head and can understand it from beginning to end. Typically, there's two insidious parts of it. One, people typically focus on one specific area and someone doesn't have the whole picture, but what's even more insidious is that we think we understand how the system works. Benar. And it's not until an incident happens that the mental model that we have of the system and the reality of the system come into conflict. And we realize that there's a divergence, right? So I think it's important that we continuously share knowledge in whatever form is efficient for folks, whether it be lunch and learns, documentation, I don't know, presentations, anything like that to sort of share and radiate that knowledge.

Jeff: But we also have to prepare and we have to prepare and define a reality where people may not completely understand how the system works. Benar. And the reason I think it's important that we acknowledge that is because you can make a lot of bad decisions thinking you know how the system behaves and being 100% wrong. Benar. So having the wherewithal to understand, okay, we think this is how the system works. We should take an extra second to verify that somehow. Benar. I think that's super important in these complicated environments in these sprawling complex microservice environments. Whereas it can be very, it's easy to be cavalier if you think, oh yeah, this is definitely how it works. And I'm going to go ahead and shut the service down because everything's going to be fine. And then everything topples over. So just even being aware of the idea that, you know what, we may not know a hundred percent how this thing works.

Jeff: So let's take that into account with every decision that we make. I think that's key. And I think it's important for management to understand the reality of that as well because for management, it's easy for us to sit down and say, “Why didn't we know exactly how this thing was going to fail?” And it's like, because it's complicated, right, because there's 500 touch points, right, where these things are interacting. And if you change one of them, it changes the entire communication pattern. So it's hard and it's not getting any easier because we're getting excited about things like microservices. We're getting excited about things like Kubernetes. We're giving people more autonomy and these are just creating more and more complicated interfaces into these systems that we're managing. And it's becoming harder and harder for anyone to truly understand them in their entirety.

Drew: We've talked a lot about a professional context, big organizations and small organizations too. But I know many of us work on smaller side projects or maybe we volunteer on projects and maybe you're helping out someone in the community or a church or those sorts of things. Can a DevOps approach benefit those smaller projects or is it just really best left to big organizations to implement?

Jeff: I think DevOps can absolutely benefit those smaller projects. And specifically, because I think sort of some of the benefits that we've talked about get amplified in those smaller projects. Benar? So exporting of expertise with automation is a big one, right? If I am… Take your church example, I think is a great one, right? If I can build a bunch of automated tests suites to verify that a change to some HTML doesn't break the entire website, right, I can export that expertise so that I can give it to a content creator who has no technical knowledge whatsoever. Benar. They're a theologian or whatever, and they just want to update a new Bible verse or something, right. But I can export that expertise so that they know that I know when I make this content change, I'm supposed to run this build button.

Jeff: And if it's green, then I'm okay. And if it's red, then I know I screwed something up. Benar. So you could be doing any manner of testing in there that is extremely complicated. Benar. It might even be something as simple as like, hey, there's a new version of this plugin. And when you deploy, it's going to break this thing. Benar. So it has nothing to do with the content, but it's at least a red mark for this content creator to say “Oh, something bad happened. I shouldn't continue. Benar. Let me get Drew on the phone and see what's going on.” Benar. And Drew can say, “Oh right. This plugin is upgraded, but it's not compatible with our current version of WordPress or whatever.” Benar. So that's the sort of value that we can add with some of these DevOps practices, even in a small context, I would say specifically around automation and specifically around some of the cultural aspects too.

Jeff: Right? So I've been impressed with the number of organizations that are not technical that are using get to make changes to everything. Benar. And they don't really know what they're doing. They just know, well, this is what we do. This is the culture. And I add this really detailed commit message here. And then I push it. They are no better than us developers. They know three get commands, but it's the ones they use over and over and over again. But it's been embedded culturally and that's how things are done. So everyone sort of rallies around that and the people that are technical can take that pattern.

Jeff: … around that and the people that are technical can take that pattern and leverage it into more beneficial things that might even be behind the scenes that they don't necessarily see. So I think there's some value, definitely. It's a matter of how deep you want to go, even with the operations piece, right? Like being able to recreate a WordPress environment locally very easily, with something like Docker. They may not understand the technology or anything, but if they run Docker Compose Up or whatever, and suddenly they're working on their local environment, that's hugely beneficial for them and they don't really need to understand all the stuff behind it. In that case, it's worthwhile, because again, you're exporting that expertise.

Drew: We mentioned right at the beginning, sort of putting off as much sort of DevOps as possible. You mentioned using tools like Heroku. And I guess that sort of approach would really apply here on getting started with, with a small project. What sort things can platforms like Heroku offer? I mean, obviously, I know you're not a Heroku expert or representative or anything, but those sorts of platforms, what sort of tools are they offering that would help in this context?

Jeff: So for one, they're basically taking that operational context for you and they're really boiling it down into a handful of knobs and levers, right? So I think what it offers is one, it offers a very clear set of what we call the yellow brick road path, where it's like, “If you go this route, all of this stuff is going to be handled for you and it's going to make your life easier. If you want to go another route, you can, but then you got to solve for all this stuff yourself.” So following the yellow brick road route helps because one, they're probably identifying a bunch of things that you hadn't even thought of. So if you're using their database container or technology, guess what? You're going to get a bunch of their metrics for free. You're going to get a lot of their alerting for free. You didn't do anything. You didn't think anything. It's just when you need it, it's there. And it's like, “Oh wow, that's super are helpful.”

Jeff: Two, when it comes to performance sizing and flexibility, this becomes very easy to sort of manage because the goal is, you're a startup that's going to become wildly successful. You're going to have hockey stick growth. And the last thing you necessarily really want to be doing is figuring out how to optimize your code for performance, while at the same time delivering new features. So maybe you spend your way out of it. You say, “Well, we're going to go up to the next tier. I could optimize my query code, but it's much more efficient for me to be spending time building this next feature that's going to bring in this new batch of users, so let's just go up to the next tier,” and you click button and you move on.

Jeff: So being able to sort of spend your way out of certain problems, I think it's hugely beneficial because tech debt gets a bad rap, but tech debt is no different than any debt. It's the trade off of acquiring something now and dealing with the pain later. And that's a strategic decision that you have to make in every organization. So unchecked tech debt is bad, right? But tech debt generally, I think, is a business choice and Heroku and platforms like that enable you to make that choice when it comes to infrastructure and performance.

Drew: You've written a book, Operations, Anti-Patterns, DevOps Solutions, for Manning. I can tell it's packed with years of hard-earned experience. The knowledge sort of just leaps out from the page. And I can tell it's been a real labor of love. It's packed full of information. Who's your sort of intended audience for that book? Is it mostly those who are already working in DevOps, or is it got a broader-

Jeff: It's got a broader… So one of the motivations for the book was that there were plenty of books for people that we're already doing DevOps. You know what I mean? So we were kind of talking to ourselves and high-fiving each other, like, “Yeah, we're so advanced. Awesome.” But what I really wanted to write the book for were people that were sort of stuck in these organizations. I don't want to use the term stuck. That's unfair, but are in these organizations that maybe aren't adopting DevOps practices or aren't at the forefront of technology, or aren't necessarily cavalier about blowing up the way they do work today, and changing things.

Jeff: Saya ingin menulisnya kepada mereka, terutama kontributor individu dan manajer menengah untuk mengatakan seperti, “Anda tidak perlu menjadi CTO untuk dapat membuat perubahan inkremental semacam ini, dan Anda tidak harus memiliki ini seluruh revolusi penjualan untuk dapat memperoleh beberapa manfaat dari DevOps.” Jadi itu benar-benar semacam surat cinta kepada mereka untuk mengatakan seperti, “Hei, kamu bisa melakukan ini berkeping-keping. Anda dapat melakukannya sendiri. Dan ada semua hal ini yang mungkin tidak Anda pikirkan terkait dengan DevOps karena Anda menganggapnya sebagai alat dan Kubernetes.” Tidak setiap organisasi… Jika Anda mendukung Negara Bagian New York ini, seperti pemerintah negara bagian, Anda tidak akan datang begitu saja dan menerapkan Kubernetes dalam semalam. Benar? Tetapi Anda dapat menerapkan bagaimana tim berbicara satu sama lain, bagaimana mereka bekerja bersama, bagaimana kita memahami masalah satu sama lain, dan bagaimana kita dapat mengatasi masalah tersebut melalui otomatisasi. Itu adalah hal-hal yang berada dalam lingkup pengaruh Anda yang dapat meningkatkan kehidupan Anda sehari-hari.

Jeff: Jadi itu benar-benar surat untuk orang-orang itu, tapi saya pikir ada cukup data di sana dan informasi yang cukup untuk orang-orang yang berada di organisasi DevOps untuk dikumpulkan dan berkata seperti, “Hei, ini masih berguna bagi kami. ” Dan banyak orang, saya pikir mengidentifikasi dengan cepat dengan membaca buku, bahwa mereka tidak berada dalam organisasi DevOps, mereka hanya memiliki perubahan jabatan. Dan itu terjadi cukup sedikit. Jadi mereka berkata seperti, "Hei, kami adalah insinyur DevOps sekarang, tetapi kami tidak melakukan praktik semacam ini yang dibicarakan dalam buku ini dan bagaimana kami sampai di sana?"

Drew: Jadi sepertinya buku Anda adalah salah satunya, tetapi apakah ada sumber daya lain yang dapat digunakan oleh orang-orang yang ingin memulai DevOps? Apakah ada tempat yang bagus untuk mempelajari hal ini?

Jeff: Ya. Saya pikir DevOps For Dummies oleh Emily Freeman adalah tempat yang bagus untuk memulai. Ini benar-benar melakukan pekerjaan yang baik dalam menyortir meletakkan beberapa konsep inti dan ide, dan apa yang kita perjuangkan. Jadi itu akan menjadi tempat yang baik untuk memulai, hanya untuk semacam mendapatkan lay dari tanah. Saya pikir Proyek Phoenix jelas merupakan sumber hebat lainnya dari Gene Kim. Dan itu bagus, semacam itu mengatur panggung untuk jenis masalah yang tidak bisa terjadi di lingkungan DevOps. Dan itu melakukan pekerjaan yang bagus untuk menyoroti pola dan kepribadian yang terjadi yang kita lihat di semua jenis organisasi berulang kali. Saya pikir itu melakukan pekerjaan yang bagus untuk menyoroti itu. Dan jika Anda membaca buku itu, saya pikir Anda akan berteriak pada halaman-halamannya dan berkata, “Ya, ya. Ini. Ini." Jadi, itu tempat bagus lainnya.

Jeff: Dan kemudian dari sana, selami salah satu buku pegangan DevOps. Saya akan menendang diri sendiri karena mengatakan ini, tetapi Buku Pegangan Google SRE adalah tempat lain yang bagus untuk dilihat. Pahami bahwa Anda bukan Google, jadi jangan merasa Anda harus menerapkan semuanya, tetapi menurut saya banyak ide dan strategi mereka cocok untuk organisasi mana pun, dan merupakan tempat yang bagus di mana Anda dapat mengambil berbagai hal dan katakan seperti, "Oke, kita, kita akan membuat lingkungan operasi kita sedikit lebih efisien." Dan itu, saya pikir akan menjadi sangat penting untuk pengembang yang memainkan peran ops, karena fokus pada banyak jenis pendekatan terprogram untuk memecahkan beberapa masalah ini.

Drew: Jadi, saya telah mempelajari semua tentang DevOps. Apa yang telah Anda pelajari akhir-akhir ini, Jeff?

Jeff: Kubernetes, kawan. Ya. Kubernetes telah menjadi semacam sumber bacaan dan pengetahuan yang nyata bagi kami. Jadi kami mencoba menerapkannya di Centro saat ini, sebagai sarana untuk lebih memberdayakan pengembang. Kami ingin mengambil langkah lebih jauh dari tempat kami berada sekarang. Kami memiliki banyak otomatisasi di tempat, tetapi sekarang, ketika datang ke layanan baru, tim saya masih cukup banyak terlibat dengan itu, tergantung pada sifat layanan. Dan kami tidak ingin berada di jalur pekerjaan itu. Kami ingin pengembang dapat mengambil ide dari konsep ke kode hingga penerapan, dan melakukannya di mana keahlian operasional dikodifikasikan dalam sistem. Jadi, saat Anda bergerak melalui sistem, sistem memandu Anda. Jadi menurut kami Kubernetes adalah alat yang akan membantu kami melakukannya.

Jeff: Ini sangat rumit. Dan itu adalah potongan besar untuk digigit. Jadi mencari tahu seperti apa penerapannya? Bagaimana kami memanfaatkan operator ini di dalam Kubernetes? Seperti apa CICD di dunia baru ini? Jadi sudah banyak membaca, tetapi di bidang ini, Anda terus belajar, bukan? Tidak peduli berapa lama Anda berada di dalamnya, berapa lama Anda telah melakukannya, Anda adalah seorang idiot dalam beberapa aspek bidang ini di suatu tempat. Jadi, itu hanya sesuatu yang Anda adaptasikan

Drew: Yah, angkat topi seperti yang saya katakan, bahkan setelah bertahun-tahun, meskipun saya agak mengerti di mana ia berada di tumpukan, saya masih benar-benar tidak tahu apa yang dilakukan Kubernetes.

Jeff: Terkadang saya merasa serupa. Rasanya seperti melakukan sedikit segalanya, bukan? Ini adalah DNS abad ke-21.

Drew: Jika Anda, pendengar, ingin mendengar lebih banyak dari Jeff, Anda dapat menemukannya di Twitter, di mana dia berada di kegelapan dan kutu buku, dan temukan bukunya serta tautan ke presentasi dan posting blog sebelumnya di situsnya, reachabledevops.com. Terima kasih telah bergabung dengan kami hari ini, Jeff. Apakah Anda memiliki kata-kata perpisahan?

Jeff: Teruslah belajar, keluarlah, teruslah belajar dan berbicaralah dengan rekan-rekan Anda. Ngomong ngomong ngomong. Semakin banyak Anda dapat berbicara dengan orang-orang yang bekerja dengan Anda, pemahaman yang lebih baik, empati yang lebih baik akan Anda hasilkan untuk mereka, dan jika ada seseorang tertentu dalam organisasi yang Anda benci, pastikan Anda berbicara dengan mereka terlebih dahulu.