Menjembatani Kesenjangan: Pentingnya Komunikasi DevOps

Meskipun metodologi DevOps telah bersama kami selama beberapa waktu sekarang, itu masih menjadi pusat diskusi panas. Perusahaan menginginkannya tetapi tidak yakin bagaimana mendekatinya.

DevOps ada di mana-mana. Dan sementara itu tren yang menarik, itu harus disesuaikan dengan produk, bukan sebaliknya.

Tetapi beberapa orang tidak melihatnya seperti itu. Saya sering mendapat pertanyaan seperti, “Apakah menurut Anda sebaiknya kita mulai menggunakan Docker, atau langsung menggunakan Kubernetes?” Pertanyaan seperti itu tidak ada artinya bahkan tanpa mengetahui tentang apa produk itu.

Semua istilah mewah itu—cloud, Kubernetes, container, manajemen konfigurasi, Infrastructure-as-Code—menjanjikan beberapa peningkatan. Tapi mereka bagi DevOps sama seperti teleskop bagi astronomi. Mereka mungkin berguna, tetapi mereka tidak perlu.

Pada intinya, DevOps bertujuan untuk menutup kesenjangan antara apa yang dipesan klien dan apa yang telah disampaikan oleh tim pengembangan. Ada penekanan pada siklus rilis pendek, pendekatan berulang untuk desain, dan otomatisasi langkah berulang. Menurut Anda apa yang paling penting untuk mewujudkannya?

Jika Anda mengatakan "komunikasi yang hebat", Anda benar. Alatnya bagus semua. Tetapi mereka hanya bernilai uang yang diinvestasikan di dalamnya ketika mereka meningkatkan komunikasi.

Salah satu aspek komunikasi adalah mengetahui apa yang diperlukan untuk menyelesaikan pekerjaan. Dan pekerjaan itu tidak berarti "kode dikomit ke repositori." Anggap saja sebagai "klien melihat perubahan dalam produksi dan menerimanya."

Segera setelah langkah pertama ini ditentukan, dan semua orang tahu apa yang perlu terjadi, itulah waktu terbaik untuk menuliskannya. Di mana? Yah, saya seorang pendukung besar mempertahankan README.md . Setiap orang dalam tim selalu dapat mengintip ke dalamnya dan mengetahui keadaan proyek, dan ini adalah tujuan alami bagi pendatang baru proyek.

Otomatisasi, langkah selanjutnya setelah menulis README, adalah opsional. Namun, ini adalah hasil alami dari mendokumentasikan proses. Dan ya, otomatisasi adalah hal yang sering terlintas dalam pikiran ketika memikirkan DevOps.

Tunggu sebentar… otomatisasi adalah opsional untuk DevOps? Bukankah DevOps adalah departemen orang yang melakukan penerapan?

Apa yang biasanya dipahami orang di bawah istilah "insinyur DevOps" adalah insinyur keandalan perangkat lunak, insinyur platform, atau insinyur otomasi operasi. Ini semua adalah peran valid yang memungkinkan praktik DevOps, tetapi menggunakan istilah kolektif "insinyur DevOps" mungkin agak ambigu.

Jadi mari kita lihat lebih dekat DevOps itu sendiri.

DevOps Dijelaskan

Pertama, izinkan saya menunjukkan kepada Anda apa yang bukan DevOps:

1. Ini bukan hanya awalan jabatan
2. Ini bukan tim (tapi "Dev" dan "Ops")
3. Ini bukan teknologi
4. Itu tidak berarti "seorang administrator sistem yang dapat membuat kode"
5. Itu tidak berarti "mengotomatiskan hal-hal"
6. Itu tidak berarti "tidak ada tim operasi sekarang"

Mengetahui hal ini, Anda sekarang sadar bahwa Anda tidak bisa hanya "menyewa insinyur DevOps" atau "membuat tim DevOps" di perusahaan untuk memastikan Anda tahan di masa depan. DevOps mirip dengan pengembangan Agile. Apakah Anda akan menyewa pengembang Agile seperti itu ? Mungkin tidak. Entah Anda mengembangkan produk dengan cara Agile atau tidak.

Lalu bagaimana DevOps dapat dijelaskan? Ini adalah metodologi. Atau mungkin sebuah budaya. Bahkan mungkin roh. Melakukan produk sesuai dengan prinsip DevOps berarti setiap orang—baik itu pengembang, insinyur operasi, atau manajer produk—berbagi visi yang sama, memeliharanya melalui komunikasi. Pada tingkat lebih rendah, itu juga berarti bahwa setiap orang menggunakan alat yang sama. Alat-alat ini tidak dimaksudkan untuk membantu sekelompok orang. Mereka dimaksudkan untuk mendorong produk ke depan.

Mengikuti konsep ini membutuhkan perubahan pola pikir yang serius, yang menjadi kendala utama. Mengapa demikian? Itu karena orang harus keluar dari zona nyamannya dan mulai berkolaborasi dengan orang-orang yang memiliki kompetensi berbeda. Pengembang tiba-tiba perlu mempelajari cara kerja cloud dan mulai menerapkan kode mereka sendiri. Orang-orang operasi harus meninggalkan penyiapan manual dan mulai membuat kode. Setiap orang perlu mempelajari konsep-konsep baru. Setiap orang memiliki tanggung jawab baru .

Ini tidak mudah, tetapi dengan komunikasi yang baik dan tujuan bersama, itu cukup dapat dicapai. Komunikasi ini melibatkan pembentukan budaya, pengaturan proses ringan, dan pemeliharaan dokumentasi yang tepat.

Otomatisasi DevOps adalah Dokumentasi

Anda mungkin tidak pernah berpikir seperti itu. Tetapi sebagian besar alat yang biasanya dikaitkan dengan DevOps adalah alat dokumentasi :

• Skrip build yang ditulis agar mudah dibaca berfungsi untuk mendokumentasikan proses build
• Pipeline integrasi berkelanjutan mendokumentasikan proses integrasi, mulai dari membangun satu bagian hingga keseluruhan produk
• Pipeline penerapan berkelanjutan melangkah lebih jauh dengan mendokumentasikan cara menerapkan produk yang dapat digunakan klien Anda
• File manajemen konfigurasi mendokumentasikan proses instalasi dan konfigurasi
• Spesifikasi infrastruktur sebagai kode mendokumentasikan infrastruktur yang diperlukan (secara formal, sebenarnya!)
• Kontainer dilengkapi dengan Dockerfile mereka sendiri yang mendokumentasikan cara membangun dan mengonfigurasi layanan mikro yang diberikan

Semua konsep mewah ini pada dasarnya melakukan satu hal: Mereka membantu anggota tim berkomunikasi lebih baik dengan mendokumentasikan proses. Proses ini kemudian dapat dijalankan secara manual atau otomatis. Yang penting adalah bahwa setiap pemangku kepentingan dalam suatu proyek dapat mengikuti mereka.

Mendokumentasikan proses Anda sebagai kode memiliki satu keuntungan besar dibandingkan manual instruksi biasa. Kode dapat diverifikasi dan berperilaku prediktif. Mengingat input yang sama, menghasilkan output yang sama.

Dengan instruksi tertulis, Anda akan memiliki interpretasi sebanyak pembaca. Jika Anda menulis dokumentasi yang ambigu atau tidak jelas, orang yang membacanya akan mengisi kekosongan tersebut. Intinya adalah, Anda tidak memiliki kendali atas apa yang masuk ke celah.

Ini jauh lebih sederhana dengan kode. Tanpa langkah konkrit, program akan berhenti berjalan. Langkah-langkah konkret ini adalah salah satu aspek kunci dari komunikasi DevOps.

Komunikasi DevOps: Satu-satunya Cara untuk Menjembatani Kesenjangan Antara Pengembangan dan Operasi

Dalam buku The Phoenix Project kita menyaksikan masalah seorang manajer yang baru dipromosikan yang ditugaskan untuk menjalankan proyek besar. Karena tidak ada yang tahu apa yang sedang terjadi, semua orang memadamkan api tanpa banyak kemajuan. Subjudul buku menyebutkan bahwa ini adalah kisah DevOps. Saya setuju dengan itu.

Namun yang menarik adalah bahwa sepanjang buku ini, tidak ada satu pun alat baru yang diperkenalkan. Bisakah Anda mencapai keadaan DevOps dengan meningkatkan komunikasi saja? Protagonis buku melakukannya, jadi ada harapan untuk Anda juga!

Meskipun pendekatan protagonis dapat dianggap "sekolah lama" (menggunakan kartu kertas yang sebenarnya daripada sistem pelacakan bug yang tepat), hal-hal mulai berubah menjadi lebih baik hanya setelah semua pihak yang terlibat mulai berbicara satu sama lain.

Anda mungkin berpikir itu hanya mungkin untuk meningkatkan kolaborasi antara pengembangan dan operasi dengan membuat antarmuka yang lebih baik di antara mereka, seperti perjanjian tingkat layanan atau backlog insiden. Tapi sebaliknya adalah benar. Dengan meruntuhkan antarmuka dan memperkenalkan empati dan tujuan bersama, Anda akan memiliki tim yang bekerja menuju tujuan bersama.

Struktur Tim DevOps: Siapa yang Ada di Tim?

Idealnya, setiap produk hanya boleh memiliki satu tim: tim produk.

Saya pernah berada di tim pengembangan di mana tujuan bersama dengan tim lain tidak ada. Tim pengembangan ingin mendorong sebanyak mungkin perubahan. Tim validasi ditugaskan untuk mencegah pengenalan cacat. Mereka memiliki manajer yang berbeda dan mereka dievaluasi secara individual.

Hasil? Pengembangan dan Validasi bermain ping-pong dengan laporan cacat. Ketika Validasi menemukan tes yang tidak lulus, Pengembangan lebih tertarik untuk menemukan kekurangan dalam kode tes itu sendiri daripada mencoba membuat kode mereka sendiri bebas dari bug.

Siklus rilis membengkak, tentu saja, karena ada overhead yang sangat besar yang diperlukan untuk mengisi laporan, kontra-laporan, dan sebagainya dengan benar. Apa yang tampaknya gagal untuk dikenali adalah bahwa dalam hal produk, kedua tim harus memiliki tujuan yang sama dan bekerja sama untuk mencapainya. Tetapi kurangnya kerja sama yang tepat dan mentalitas silo membuatnya sangat sulit untuk diperhatikan.

Memerangi Sampah Adalah Upaya Bersama

Pola pikir produksi ramping yang mengilhami The Manifesto for Agile Software Development (yang pada gilirannya memperkenalkan kami pada DevOps) adalah tentang memerangi pemborosan. Yang kami maksud dengan pemborosan adalah segala sesuatu yang tidak secara langsung relevan dengan apa yang dipesan oleh klien. Pekerjaan dalam proses yang menumpuk adalah pemborosan. Setiap langkah dari proses yang tidak jelas mengarah pada pelepasan adalah pemborosan.

Tapi sampah hanya bisa dilihat dari tingkat tinggi. Dalam lingkup satu tim, beberapa prosedur mungkin tampak penting. Namun, dari perspektif produk, mereka mungkin tidak berguna.

Untuk mengetahui upaya mana yang sia-sia, Anda harus menggabungkan kekuatan dan mempertimbangkan siklus hidup produk yang dikirim. Anda juga perlu berpikir dari sudut pandang klien. Apakah fitur ini sesuatu yang diinginkan klien? Jika tidak, Anda dapat melewatkannya saat ini. Apakah proses Anda sederhana dan ramping? Lihatlah lebih dalam terutama pada mereka yang melintasi batas tim.

Apakah Anda ingin memastikan pengembangan produk seefisien mungkin? Undang orang luar untuk melihat cara Anda bekerja. Seseorang yang bukan bagian dari tim Anda akan dapat mengajukan pertanyaan mendalam dan menemukan area baru untuk perbaikan.

Prinsip DevOps: Pertahankan CALM Anda

CALMS adalah deskripsi yang sangat akurat tentang bagaimana seseorang harus berlatih DevOps:

• budaya
• Sebuah otomasi
• sedikit
• pengukuran
• S haring

Perhatikan bahwa itu dibentuk seperti sandwich. Tiga nilai tengah lebih bersifat teknis, sedangkan nilai terluar berhubungan dengan soft skill. Tetapi dasar dari semua budaya adalah komunikasi: Kami bertukar nilai dan keyakinan kami dengan anggota tim lain sampai kami mencapai konsensus tentang bagaimana seharusnya berperilaku.

Sama halnya dengan berbagi. Berbagi sesuatu yang mendasar seperti makanan tidak memerlukan komunikasi. Gerakan itu sendiri, bagaimanapun, juga dapat dilihat sebagai tindakan komunikasi. "Aku peduli padamu, jadi aku berbagi denganmu." Kami tidak ingin membatasi ruang lingkup hanya pada komunikasi verbal.

Berbagi ide dan alat, bagaimanapun, membutuhkan komunikasi. Bagaimana kita harus membaginya? Di mana kita menempatkan mereka? Apakah mereka berguna untuk setiap orang dalam tim atau hanya untuk kelompok yang lebih kecil?

Jika Anda hanya berfokus pada aspek yang lebih teknis—Otomasi, Lean, dan Pengukuran—Anda kehilangan poin DevOps. Apa gunanya memiliki skrip penerapan otomatis yang tidak pernah digunakan siapa pun selain penulis? Jika skrip menghemat waktu, maka itu mungkin dibenarkan. Tapi bayangkan berapa banyak waktu yang bisa dihemat jika semua orang membagikan skrip ini. Ini mengatakan sesuatu tentang memerangi limbah!

DevOps Membawa Bisnis Lebih Dekat ke Pengembangan

Ada yang mengatakan DevOps membawa operasi lebih dekat ke pengembangan. Ini benar, tapi itu bukan seluruh kebenaran. Jika dilakukan dengan benar, DevOps mendekatkan setiap unit. Hal ini memungkinkan bisnis dan klien untuk melihat perkembangan apa yang dilakukan, hampir secara real time.

Putaran umpan balik yang lebih pendek ini menguntungkan semua pemangku kepentingan. Pekerjaan umumnya lebih terlihat, dan pengembang juga dapat dengan mudah melihat bagaimana klien menggunakan kode yang mereka hasilkan. Dengan penerapan tradisional, Anda dapat menunggu beberapa bulan sebelum seseorang mengetahui bug atau persyaratan yang terlewat. Dengan penerapan yang berkelanjutan, setiap orang dapat bereaksi terhadap masalah apa pun yang muncul. Pengembang, operasi, bisnis, dan klien dapat duduk di satu ruangan dan memodifikasi aplikasi yang berfungsi sesuai dengan kebutuhan saat ini.

Alat DevOps Pertama? Pikirkan lagi

Tentu saja, ada kebutuhan untuk semua alat untuk memungkinkannya.

Tetapi tidak ada alat yang dapat menggantikan komunikasi dan empati yang baik di dalam perusahaan. Saya pernah mengamati sebuah produk yang proses pembuatannya dimiliki oleh satu tim, sedangkan kode yang diberikan dimiliki oleh tim lain.

Masalah dengan sistem build adalah hal biasa. Pengembang tidak yakin bagaimana menggunakannya. Itu didasarkan pada alat standar tetapi mereka disesuaikan ke titik di mana setiap dokumentasi yang tersedia di web terbukti tidak berguna.

Semua orang ingin memperbaiki situasi, tetapi tidak ada kesepahaman antara kedua tim. Ini berarti bahwa kedua belah pihak memperkenalkan alat-alat baru tanpa berkonsultasi dengan pihak lain. Ini hanya memperlebar jarak, bukannya menutupnya.

Jika Anda ingin memulai transformasi DevOps dalam organisasi Anda, mulailah dengan meningkatkan cara Anda berkomunikasi. Jangan hanya berasumsi sebuah solusi: Lakukan brainstorming dengan pikiran terbuka terlebih dahulu . Kemudian Anda mungkin menemukan bahwa, misalnya, dukungan perkakas tidak cukup untuk kebutuhan Anda. Saat itulah Anda dapat mempertimbangkan untuk mengubah alat Anda saat ini atau memperkenalkan beberapa yang baru—jika tidak, Anda mungkin akan menambah masalah aslinya.

Cara Tercepat untuk Membangun DevOps? Komunikasi yang Lebih Baik!

Dalam pendahuluan, saya menyebutkan pertanyaan yang sering diajukan klien kepada saya: “Haruskah saya menggunakan Docker atau haruskah saya langsung beralih ke Kubernetes?” Setelah membaca artikel ini, Anda dapat melihat bahwa pertanyaan seperti itu paling baik dijawab setelah melakukan beberapa pekerjaan persiapan—dengan pola pikir DevOps.

Jika Anda tahu tim produk Anda memahami manfaat DevOps untuk dirinya sendiri dan untuk klien, tim dan klien dapat memulai dengan menetapkan harapan mereka. Kemudian para insinyur dapat mengetahui model pengembangan dan penerapan. Terakhir, Anda bisa menentukan alat mana yang dibutuhkan.

Setelah semua persyaratan didokumentasikan, pilihan teknologi jauh lebih mudah dibuat.

Saya adalah pendukung semua alat otomatisasi DevOps hebat yang membuat pekerjaan kami lebih mudah dan lebih mudah dikelola. Tetapi pekerjaan kami sehari-hari adalah bekerja dengan orang- orang . Mari luangkan waktu untuk meningkatkan aspek praktik terbaik DevOps ini daripada mendapatkan sertifikat teknologi lainnya.