Apa sih DevOps itu?

Sejarah Singkat Waktu

Untuk memahami DevOps, kita harus melakukan perjalanan kembali ke masa lalu ketika tidak ada yang lain selain programmer.

Seperti yang diajarkan Tao kepada kita:

Pemrogram zaman dulu sangat misterius dan mendalam. Kami tidak dapat memahami pikiran mereka, jadi yang kami lakukan hanyalah menggambarkan penampilan mereka:

• Sadar, seperti rubah yang melintasi air
• Waspada, seperti seorang jenderal di medan perang
• Baik, seperti nyonya rumah yang menyapa tamunya
• Sederhana, seperti balok kayu yang tidak diukir
• Buram, seperti kolam hitam di gua yang gelap

Programmer melahirkan bahasa mesin. Bahasa mesin melahirkan assembler. Assembler melahirkan compiler. Sekarang ada ribuan bahasa. Setiap bahasa memiliki tujuannya, betapapun rendahnya. Setiap bahasa mengekspresikan Yin dan Yang dari perangkat lunak. Setiap bahasa memiliki tempatnya di dalam perangkat lunak.

Pada saat itu, kantor pengembangan perangkat lunak sebagian besar disebut laboratorium, dan pemrogram adalah ilmuwan. Untuk membuat aplikasi yang baik, pemrogram harus sepenuhnya memahami masalah yang sedang dipecahkan oleh aplikasi tersebut. Mereka harus tahu di mana aplikasi akan digunakan dan sistem seperti apa yang akan menjalankannya. Intinya, programmer tahu segalanya tentang aplikasi mereka mulai dari spesifikasi, pengembangan, hingga penerapan dan dukungan.

Dan kemudian sifat manusia muncul, dan kami mulai meminta lebih. Lebih banyak kecepatan, lebih banyak fitur, lebih banyak pengguna, lebih banyak segalanya.

Menjadi makhluk yang sederhana, rendah hati, dan damai, programmer memiliki kesempatan yang sangat kecil untuk bertahan dari ledakan pengguna yang membutuhkan yang selalu meminta lebih. Kesempatan terbaik untuk menang adalah mulai berevolusi ke arah yang berbeda, dan membuat kasta. Segera, pemrogram punah sebagai nenek moyang dari keturunan baru yang disebut pengembang, insinyur perangkat lunak, administrator jaringan, pengembang basis data, pengembang web, arsitek sistem, insinyur QA, dan banyak lagi. Berkembang cepat dan beradaptasi dengan tantangan dari dunia luar menjadi bagian dari DNA mereka. Kasta baru bisa berkembang dalam hitungan minggu. Pengembang web menjadi pengembang back-end, pengembang front-end, pengembang PHP, pengembang Ruby, pengembang Angular ... semuanya akan menjadi neraka.

Segera mereka semua lupa bahwa mereka berasal dari ayah yang sama, seorang Programmer. Seorang ilmuwan sederhana dan damai yang hanya ingin membuat dunia menjadi tempat yang lebih baik. Mereka mulai berkelahi satu sama lain, mengklaim bahwa masing-masing dari mereka adalah keturunan sejati "The Programmer" dan bahwa darah mereka lebih murni daripada yang lain.

Seiring berjalannya waktu, mereka mengurangi interaksi mereka seminimal mungkin dan berbicara satu sama lain hanya ketika mereka benar-benar harus melakukannya. Mereka berhenti merayakan keberhasilan anggota keluarga jauh mereka, dan akhirnya bahkan berhenti mengirim kartu pos sesekali.

Jika mereka hanya mencari perasaan mereka, mereka akan menemukan bahwa percikan Programmer ada di hati mereka, menunggu untuk bersinar dan membawa kedamaian ke galaksi.

Dalam perlombaan egois dan egosentris mereka untuk menaklukkan dunia, keturunan programmer lupa tujuan pekerjaan mereka - memecahkan masalah untuk klien mereka. Klien mulai merasakan sakitnya perilaku seperti proyek tertunda, terlalu mahal, atau bahkan gagal.

Sesekali, bintang yang terang akan bersinar dan seseorang akan mendapatkan inspirasi untuk mencoba dan berdamai di antara The Descendants. Mereka datang dengan Air Terjun. Ini adalah ide yang brilian, karena memanfaatkan fakta bahwa kelompok pengembang yang berbeda berkomunikasi hanya jika diperlukan. Ketika satu kelompok menyelesaikan bagian pekerjaan mereka, itu berkomunikasi dengan kelompok berikutnya untuk mengirim pekerjaan ke bawah melalui proses dan tidak pernah melihatnya kembali.

Ini berhasil untuk sementara waktu, tetapi seperti biasa, manusia (Klien) menginginkan lebih lagi. Mereka ingin mengambil bagian lebih aktif dalam seluruh proses pembuatan perangkat lunak, lebih sering memberikan pendapat, dan meminta perubahan meskipun sudah terlambat.

Proyek perangkat lunak menjadi sangat rentan terhadap kegagalan sehingga diterima sebagai standar industri. Statistik menunjukkan bahwa lebih dari 50% proyek gagal, dan sepertinya tidak ada yang bisa dilakukan untuk itu (ZDNet, CNet)

Setiap generasi memiliki beberapa individu yang berpikiran terbuka yang tahu bahwa semua kelompok pengembang ini harus menemukan cara untuk bekerja sama, berkomunikasi, dan fleksibel untuk memastikan klien mereka akan menerima solusi terbaik. Ada jejak upaya ini bahkan sejak tahun 1957, oleh rekan-rekan John Von Neumann yang hebat. Namun kami harus menunggu hingga awal 2001 untuk memulai revolusi, ketika selusin yang kotor menciptakan Manifesto Agile.

Manifesto Agile didasarkan pada dua belas prinsip:

1. Kepuasan pelanggan dengan pengiriman perangkat lunak yang berharga secara dini dan berkelanjutan
2. Menyambut perubahan persyaratan, bahkan dalam pengembangan yang terlambat
3. Perangkat lunak yang berfungsi sering dikirimkan (berminggu-minggu, bukan berbulan-bulan)
4. Kerja sama yang erat dan setiap hari antara pelaku bisnis dan pengembang
5. Proyek dibangun di sekitar individu yang termotivasi, yang harus dipercaya
6. Percakapan tatap muka adalah bentuk komunikasi terbaik (co-location)
7. Perangkat lunak yang berfungsi adalah ukuran utama kemajuan
8. Pembangunan berkelanjutan, mampu mempertahankan kecepatan yang konstan
9. Perhatian terus menerus pada keunggulan teknis dan desain yang baik
10. Kesederhanaan—seni memaksimalkan jumlah pekerjaan yang tidak dilakukan—sangat penting
11. Tim yang mengatur diri sendiri
12. Adaptasi reguler terhadap perubahan keadaan

Manifesto tangkas adalah langkah besar pertama dalam membawa perdamaian ke Galaxy dan memulihkan keseimbangan Force. Untuk pertama kalinya dalam waktu yang sangat lama, menghubungkan semua pemangku kepentingan dalam proses pengembangan perangkat lunak didasarkan pada cara budaya dan "manusia", sebanyak secara prosedural dan mekanis. Orang-orang mulai berbicara satu sama lain, bertemu secara teratur, dan bertukar ide dan komentar sepanjang waktu. Mereka menyadari bahwa mereka memiliki lebih banyak kesamaan yang mereka pikirkan, dan klien menjadi bagian dari tim, bukan hanya beberapa faktor eksternal yang diharapkan untuk mengirim uang dan tidak mengajukan pertanyaan.

Masih ada beberapa rintangan yang harus diatasi, tetapi masa depan tampak lebih cerah dari sebelumnya. Menjadi gesit berarti terbuka dan bersedia untuk beradaptasi dengan perubahan yang konstan. Namun, dengan terlalu banyak perubahan, sulit untuk tetap fokus pada tujuan akhir dan penyampaian. Dan itulah bagaimana Lean Software Development menjadi hidup.

Terikat pada LSD (pun intended) dan mempertaruhkan untuk diasingkan dan terbuang, beberapa keturunan mencari solusi di luar kasta mereka dan industri perangkat lunak. Mereka menemukan keselamatan dalam karya-karya produsen mobil besar. Sistem Produksi Toyota luar biasa dalam kesederhanaannya dan sangat jelas bahwa lean manufacturing-nya dapat dengan mudah diterapkan pada pengembangan perangkat lunak.

Ada 7 prinsip lean:

1. Menghilangkan limbah
2. Membangun Kualitas Dalam
3. Ciptakan Pengetahuan (Perkuat pembelajaran)
4. Tunda Komitmen (Putuskan selambat mungkin)
5. Kirim secepat mungkin
6. Menghormati Orang (Berdayakan tim)
7. Optimalkan Keseluruhan

Ditambahkan di atas Agile, prinsip Lean mendukung mentalitas dan fokus untuk melakukan hal yang benar, sambil tetap fleksibel selama seluruh proses.

Setelah Agile dan Lean diadopsi oleh tim pengembangan perangkat lunak, hanya perlu satu langkah lagi untuk menerapkan seluruh rangkaian prinsip ke TI secara Keseluruhan - yang akhirnya membawa kami ke DevOps!

Masuki DevOps - Jalan raya tiga jalur

Pandangan sekolah lama dari tim pengembangan perangkat lunak termasuk analis bisnis, arsitek sistem, pengembang front-end, pengembang back-end, penguji, dan sebagainya. Mengoptimalkan proses pengembangan perangkat lunak, termasuk prinsip-prinsip tangkas dan ramping, sebagian besar difokuskan pada ini. Setelah aplikasi "siap produksi", itu dikirim ke "Operasi" termasuk insinyur sistem, insinyur rilis, DBA, insinyur jaringan, profesional keamanan, dll. Menghapus tembok besar antara Dev dan Ops adalah kekuatan pendorong utama DevOps .

DevOps adalah hasil dari penerapan prinsip lean ke seluruh aliran nilai TI. Aliran nilai TI memperluas pengembangan ke dalam produksi, menggabungkan semua 'kerabat jauh' yang diturunkan dari Programmer asli.

Penjelasan terbaik dari solusi DevOps diberikan oleh Gene Kim, dan Jika Anda belum membaca The Phoenix Project , saya sarankan Anda meluangkan waktu dan melakukannya.

Anda tidak boleh mempekerjakan seorang insinyur DevOps dan DevOps tidak boleh menjadi departemen baru di TI Anda. DevOps adalah budaya, pola pikir, dan merupakan bagian dari TI secara Keseluruhan. Tidak ada alat yang akan menjadikan TI Anda sebagai organisasi DevOps , dan tidak ada tingkat otomatisasi yang akan memberdayakan tim Anda untuk memberikan nilai maksimum kepada klien Anda.

DevOps biasanya disebut sebagai metode tiga cara, tetapi saya melihatnya sebagai tiga jalur dari jalan raya yang sama. Anda mulai di jalur satu, lalu Anda mempercepat dan beralih ke jalur dua, dan akhirnya Anda melaju kencang di jalur ketiga.

• Jalur satu - Kinerja sistem secara keseluruhan adalah titik fokus utama dan lebih ditekankan daripada kinerja setiap elemen individu dari sistem

• Jalur dua - Pastikan bahwa ada loop umpan balik konstan yang dikirim ke hulu, dan tidak diabaikan

• Jalur tiga - Kembangkan eksperimen, peningkatan konstan, dan gagal dengan cepat

Jalur satu - Mempercepat

Memahami pentingnya keseluruhan sistem, dan memprioritaskan item pekerjaan dengan benar adalah hal pertama yang harus dipelajari oleh organisasi TI saat mengadopsi prinsip-prinsip DevOps. Tidak seorang pun di arus nilai TI yang diizinkan untuk membuat hambatan dan mengurangi alur kerja.

Memastikan alur kerja yang tidak terganggu adalah tujuan akhir untuk semua orang yang termasuk dalam proses. Terlepas dari peran yang dimiliki seseorang atau tim, sangat penting bahwa mereka berusaha untuk mencapai pemahaman yang mendalam tentang sistem. Mengadopsi cara berpikir ini memiliki dampak langsung pada kualitas, karena cacat tidak pernah diturunkan begitu saja karena akan menyebabkan kemacetan.

Memastikan bahwa pekerjaan tidak terhenti tidaklah cukup. Sebuah organisasi yang produktif harus selalu berusaha untuk meningkatkan aliran. Ada banyak metodologi untuk meningkatkan aliran. Anda dapat menemukan solusinya di Theory Of Constraints, Six Sigma, Lean, atau Toyota Production System. Jangan ragu untuk memilih salah satu dari ini, buat sendiri, atau gabungkan.

Prinsip-prinsip DevOps tidak peduli tim mana yang Anda miliki, jika Anda seorang Arsitek Sistem, DBA, QA, atau administrator jaringan. Aturan yang sama berlaku untuk semua orang, dan setiap orang diharapkan mengikuti dua prinsip sederhana:

• Jaga agar aliran sistem tidak terganggu
• Tingkatkan dan optimalkan alur kerja setiap saat

Jalur dua - Bersiaplah

Aliran sistem yang tidak terputus adalah satu arah, dan diharapkan dari pengembangan ke operasi. Di dunia yang ideal ini berarti bahwa perangkat lunak dibuat dengan cepat dengan kualitas tinggi, diterapkan ke produksi, dan memberikan nilai kepada klien.

Namun, DevOps bukanlah Utopia, dan jika pengiriman satu arah dimungkinkan, metode waterfall sudah cukup. Mengevaluasi kiriman dan mengkomunikasikan arus sangat penting untuk memastikan kualitas. Saluran komunikasi “upstream” pertama yang harus diimplementasikan adalah Ops to Dev.

Memberi tos pada diri sendiri itu mudah, tetapi meminta umpan balik dan memberi umpan balik adalah cara untuk melihat gambaran sebenarnya. Sangat penting bahwa setiap langkah kecil ke hilir diikuti dengan konfirmasi hulu instan.

Tidak masalah bagaimana Anda membuat loop umpan balik. Anda dapat mengundang pengembang untuk bergabung dengan rapat tim dukungan, atau membawa admin jaringan ke perencanaan sprint mingguan. Selama umpan balik Anda ada, dan komentar diambil dan ditangani, organisasi Anda melaju kencang di jalan raya DevOps.

Jalur tiga - Warp 10

Jalur cepat DevOps bukan untuk orang yang berpikiran lemah. Untuk masuk ke jalur cepat DevOps, organisasi Anda harus cukup matang. Ini semua tentang mengambil risiko dan belajar dari kegagalan, terus bereksperimen, dan menerima bahwa pengulangan dan latihan adalah prasyarat untuk penguasaan. Cukup sering Anda akan mendengar istilah Kata, dan ini karena suatu alasan. Latihan terus menerus dan pengulangan mengarah pada penguasaan karena membuat gerakan kompleks menjadi rutinitas.

Tetapi sebelum Anda mulai menggabungkan gerakan, Anda harus menguasai setiap langkah terlebih dahulu.

“Apa yang pantas untuk Guru tidak pantas untuk pemula. Anda harus memahami Tao sebelum melampaui struktur.”

DevOps Third Way/Fast Lane mencakup alokasi waktu untuk terus bereksperimen setiap hari, terus-menerus memberi penghargaan kepada tim karena mengambil risiko, dan memasukkan kesalahan ke dalam sistem untuk meningkatkan ketahanan.

Untuk memastikan bahwa organisasi Anda tidak akan meledak saat menerapkan tindakan semacam ini, Anda harus sering membuat loop umpan balik antara semua tim, sambil memastikan bahwa semua kemacetan jelas dan aliran sistem tidak terganggu.

Menerapkan langkah-langkah ini membuat organisasi Anda waspada setiap saat dan mampu menanggapi tantangan dengan cepat dan efektif.

Ringkasan - Daftar periksa organisasi DevOps

Berikut adalah daftar periksa yang dapat Anda gunakan untuk memvalidasi cara DevOps mengaktifkan organisasi TI Anda. Silakan, jangan ragu untuk mengomentari artikel dan menambahkan poin Anda sendiri.

• Tidak ada dinding antara tim pengembangan dan tim operasi. Keduanya adalah bagian dari proses yang sama
• Pekerjaan yang dikirim dari satu tim ke tim lain selalu diverifikasi dan kualitas terbaik
• Tidak ada "penumpukan" pekerjaan, dan semua kemacetan ditangani
• Tim pengembangan tidak menggunakan waktu Operasi untuk aktivitasnya, karena penyebaran dan pemeliharaan adalah bagian dari kotak waktu yang sama
• Tim pengembangan tidak mengirimkan kode untuk penerapan pada pukul 17.00 pada hari Jumat, meninggalkan operasi untuk membersihkan pekerjaan mereka selama akhir pekan
• Lingkungan pengembangan distandarisasi, dan operasi dapat dengan mudah mereproduksi dan menskalakannya ke dalam produksi
• Tim pengembangan dapat memberikan versi baru yang dianggap sesuai dan operasi dapat dengan mudah menerapkannya ke dalam produksi
• Ada jalur komunikasi yang jelas antara semua tim
• Semua anggota tim memiliki waktu untuk bereksperimen dan bekerja pada peningkatan sistem
• Cacat diperkenalkan (atau disimulasikan) dan ditangani dalam sistem secara teratur. Pelajaran yang dipetik dari setiap percobaan didokumentasikan dan dibagikan kepada semua orang yang relevan. Penanganan insiden adalah rutinitas dan sebagian besar ditangani dengan cara yang diketahui

Kesimpulan

Menggunakan Alat DevOps modern seperti Chef, Docker, Ansible, Packer, Troposphere, Consul, Jenkins, SonarQube, AWS, dll. tidak berarti Anda menerapkan prinsip DevOps. DevOps adalah cara berpikir. Kita semua adalah bagian dari proses yang sama, kita berbagi waktu yang sama dan memberikan nilai bersama. Setiap orang yang mengambil bagian dalam proses pengiriman perangkat lunak dapat mempercepat atau memperlambat seluruh sistem. Bug yang dibuat selama pengembangan dapat menurunkan sistem, serta konfigurasi firewall yang salah.

Semua orang adalah bagian dari DevOps, dan setelah organisasi Anda memahaminya, alat dan tumpukan teknologi yang akan membantu Anda mengelolanya akan muncul secara ajaib.