DevOps telah menjadi topik yang sangat populer selama beberapa tahun terakhir. Banyak orang bermimpi untuk bergabung, tetapi, seperti yang diperlihatkan oleh praktik, seringkali hanya karena besarnya gaji.
Beberapa orang mencantumkan DevOps di resume mereka, meskipun mereka tidak selalu mengetahui atau memahami inti dari istilah tersebut. Ada yang beranggapan setelah mempelajari Ansible, GitLab, Jenkins, Terraform dan sejenisnya (daftarnya bisa dilanjutkan sesuai selera), Anda akan langsung menjadi “devopsist”. Tentu saja hal ini tidak benar.
Selama beberapa tahun terakhir, saya terutama terlibat dalam penerapan DevOps di berbagai perusahaan. Sebelumnya, ia bekerja selama lebih dari 20 tahun di berbagai posisi mulai dari administrator sistem hingga direktur TI. Saat ini Insinyur Utama DevOps di Playgendary.
Siapa DevOps
Ide untuk menulis artikel muncul setelah pertanyaan lain: “siapakah DevOps?” Masih belum ada istilah pasti untuk apa atau siapa itu. Beberapa jawabannya sudah ada di sini . Pertama, saya akan menyoroti poin-poin utama darinya, dan kemudian saya akan membagikan pengamatan dan pemikiran saya.
DevOps bukanlah spesialis yang dapat dipekerjakan, bukan sekumpulan utilitas, dan bukan departemen pengembang dengan insinyur.
DevOps adalah filosofi dan metodologi.
Dengan kata lain, ini adalah serangkaian praktik yang membantu pengembang berinteraksi secara aktif dengan administrator sistem. Artinya, menghubungkan dan mengintegrasikan proses kerja satu sama lain.
Dengan munculnya DevOps, struktur dan peran spesialis tetap sama (ada pengembang, ada insinyur), namun aturan interaksi telah berubah. Batasan antar departemen menjadi kabur.
Tujuan DevOps dapat dijelaskan dalam tiga poin:
- Perangkat lunak harus diperbarui secara berkala.
- Perangkat lunak harus dilakukan dengan cepat.
- Perangkat lunak harus diterapkan dengan mudah dan dalam waktu singkat.
Tidak ada alat tunggal untuk DevOps. Mengonfigurasi, mengirimkan, dan mempelajari beberapa produk tidak berarti DevOps telah muncul di perusahaan. Ada banyak alat dan semuanya digunakan pada tahapan yang berbeda, tetapi memiliki satu tujuan yang sama.
Dan ini hanya sebagian dari alat DevOps
Saya telah mewawancarai orang-orang untuk posisi insinyur DevOps selama lebih dari 2 tahun, dan saya menyadari betapa pentingnya memahami dengan jelas esensi istilah tersebut. Saya telah mengumpulkan pengalaman, pengamatan, dan pemikiran spesifik yang ingin saya bagikan.
Dari pengalaman wawancara, saya melihat gambar berikut: spesialis yang menganggap DevOps sebagai jabatan biasanya memiliki kesalahpahaman dengan rekan kerja.
Ada sebuah contoh yang mencolok. Seorang pria muda datang ke wawancara dengan banyak kata cerdas di resumenya. Pada tiga pekerjaan terakhirnya, dia memiliki pengalaman 5-6 bulan. Saya meninggalkan dua startup karena “tidak berkembang”. Namun mengenai perusahaan ketiga, dia mengatakan bahwa tidak ada yang memahaminya di sana: pengembang menulis kode di Windows, dan direktur memaksa kode ini untuk “dibungkus” dalam Docker biasa dan dimasukkan ke dalam pipeline CI/CD. Orang tersebut mengatakan banyak hal negatif tentang tempat kerjanya saat ini dan rekan-rekannya - saya hanya ingin menjawab: “Jadi, Anda tidak akan menjual seekor gajah.”
Lalu saya mengajukan pertanyaan yang paling penting dalam daftar saya untuk setiap kandidat.
— Apa arti DevOps bagi Anda secara pribadi?
- Secara umum atau bagaimana cara saya memandangnya?
Saya tertarik dengan pendapat pribadinya. Dia tahu teori dan asal usul istilah tersebut, tapi dia sangat tidak setuju dengan keduanya. Dia percaya DevOps adalah sebuah jabatan. Di sinilah letak akar permasalahannya. Serta pakar lain yang berpendapat sama.
Pengusaha, setelah mendengar banyak tentang “keajaiban DevOps”, ingin menemukan seseorang yang akan datang dan menciptakan “keajaiban” ini. Dan pelamar dari kategori “DevOps adalah pekerjaan” tidak memahami bahwa dengan pendekatan ini mereka tidak akan dapat memenuhi harapan. Dan, secara umum, mereka menulis DevOps di resume mereka karena ini sedang tren dan mereka membayar mahal untuk itu.
Metodologi dan filosofi DevOps
Metodologinya bisa teoritis dan praktis. Dalam kasus kami, ini yang kedua. Seperti yang saya sebutkan di atas, DevOps adalah serangkaian praktik dan strategi yang digunakan untuk mencapai tujuan yang telah ditetapkan. Dan dalam setiap kasus, bergantung pada proses bisnis perusahaan, hal tersebut mungkin berbeda secara signifikan. Yang tidak menjadikannya lebih baik atau lebih buruk.
Metodologi DevOps hanyalah sarana untuk mencapai tujuan.
Sekarang tentang apa itu filosofi DevOps. Dan ini mungkin pertanyaan yang paling sulit.
Agak sulit merumuskan jawaban yang singkat dan ringkas, karena belum diformalkan. Dan karena penganut filosofi DevOps lebih banyak terlibat dalam praktik, tidak ada waktu untuk berfilsafat. Namun, ini adalah proses yang sangat penting. Apalagi berkaitan langsung dengan kegiatan rekayasa. Bahkan ada bidang pengetahuan khusus - .
Tidak ada mata pelajaran seperti itu di universitas saya, saya harus mempelajari semuanya sendiri menggunakan materi yang saya temukan di tahun 90an. Topik ini bersifat opsional untuk pendidikan teknik, sehingga jawabannya kurang diformalkan. Namun orang-orang yang benar-benar mendalami DevOps mulai merasakan “semangat” atau “kelengkapan bawah sadar” tertentu dari semua proses perusahaan.
Dengan menggunakan pengalaman saya sendiri, saya mencoba memformalkan beberapa “postulat” filosofi ini. Hasilnya adalah sebagai berikut:
- DevOps bukanlah sesuatu yang independen dan dapat dipisahkan menjadi suatu bidang pengetahuan atau aktivitas tersendiri.
- Semua karyawan perusahaan harus dipandu oleh metodologi DevOps saat merencanakan aktivitas mereka.
- DevOps mempengaruhi semua proses dalam perusahaan.
- DevOps hadir untuk mengurangi biaya waktu untuk setiap proses dalam perusahaan guna memastikan pengembangan layanannya dan kenyamanan pelanggan yang maksimal.
- DevOps, dalam bahasa modern, adalah posisi proaktif setiap karyawan perusahaan, yang bertujuan untuk mengurangi biaya waktu dan meningkatkan kualitas produk TI di sekitar kita.
Saya pikir “postulat” saya adalah topik diskusi tersendiri. Tapi sekarang ada sesuatu yang perlu dikembangkan.
Apa yang Dilakukan DevOps
Kata kuncinya di sini adalah komunikasi. Ada banyak komunikasi, yang penggagasnya haruslah insinyur DevOps yang sama. Mengapa demikian? Karena ini adalah filsafat dan metodologi, dan baru kemudian pengetahuan rekayasa.
Saya tidak dapat berbicara dengan keyakinan 100% tentang pasar tenaga kerja di Barat. Tapi saya tahu cukup banyak tentang pasar DevOps di Rusia. Selain ratusan wawancara, selama satu setengah tahun terakhir saya telah berpartisipasi dalam ratusan prapenjualan teknis untuk layanan “Implementasi DevOps” untuk perusahaan dan bank besar Rusia.
Di Rusia, DevOps masih sangat muda, namun sudah menjadi trending topik. Sejauh yang saya tahu, di Moskow saja, kekurangan spesialis semacam itu pada tahun 2019 berjumlah lebih dari 1000 orang. Dan kata Kubernetes bagi pemberi kerja hampir seperti kain merah untuk seekor banteng. Penganut alat ini siap menggunakannya meski tidak diperlukan dan menguntungkan secara ekonomi. Perusahaan tidak selalu memahami dalam kasus apa apa yang lebih tepat untuk digunakan, dan dengan penerapan yang tepat, memelihara cluster Kubernetes membutuhkan biaya 2-3 kali lebih banyak daripada menerapkan aplikasi menggunakan skema cluster konvensional. Gunakan di tempat yang benar-benar Anda butuhkan.
Menerapkan DevOps mahal dari segi uang. Dan hal ini hanya dibenarkan jika hal tersebut membawa manfaat ekonomi di bidang lain, dan tidak dalam manfaatnya sendiri.
Faktanya, para insinyur DevOps adalah pionir - merekalah yang harus menjadi orang pertama yang menerapkan metodologi ini di perusahaan dan membangun proses. Agar hal ini berhasil, spesialis harus terus berinteraksi dengan karyawan dan kolega di semua tingkatan. Seperti yang biasa saya katakan, semua karyawan perusahaan harus dilibatkan dalam proses implementasi DevOps: dari petugas kebersihan hingga CEO. Dan ini merupakan prasyarat. Jika anggota tim yang paling junior tidak mengetahui dan memahami apa itu DevOps dan mengapa tindakan organisasi tertentu dilakukan, maka implementasi yang sukses tidak akan berhasil.
Selain itu, teknisi DevOps perlu menggunakan sumber daya administratif dari waktu ke waktu. Misalnya, untuk mengatasi “resistensi lingkungan” - ketika tim belum siap menerima alat dan metodologi DevOps.
Pengembang hanya boleh menulis kode dan pengujian. Untuk melakukan ini, dia tidak memerlukan laptop super kuat yang akan digunakannya dan mendukung seluruh infrastruktur proyek secara lokal. Misalnya, seorang front-end developer menyimpan semua elemen aplikasi di laptopnya, termasuk database, emulator S3 (minio), dll. Artinya, dia menghabiskan banyak waktu untuk memelihara infrastruktur lokal ini dan sendirian berjuang dengan semua masalah dari solusi tersebut. Daripada mengembangkan kode untuk bagian depan. Orang-orang seperti itu bisa sangat menolak perubahan apa pun.
Namun ada tim yang, sebaliknya, dengan senang hati memperkenalkan alat dan metode baru, dan berpartisipasi aktif dalam proses ini. Meskipun demikian, komunikasi antara teknisi DevOps dan tim tidak dibatalkan.
Saat DevOps tidak diperlukan
Ada situasi ketika DevOps tidak diperlukan. Ini adalah fakta yang perlu dipahami dan diterima.
Pertama-tama, hal ini berlaku untuk perusahaan mana pun (terutama usaha kecil), ketika keuntungan mereka tidak secara langsung bergantung pada ada tidaknya produk TI yang memberikan layanan informasi kepada klien. Dan di sini kita tidak berbicara tentang situs web perusahaan, apakah itu “kartu nama” statis atau blok berita dinamis, dll.
DevOps diperlukan ketika kepuasan klien Anda dan keinginannya untuk kembali kepada Anda bergantung pada ketersediaan layanan informasi ini untuk interaksi dengan klien, kualitas dan penargetannya.
Contoh yang mencolok adalah salah satu bank terkenal. Perusahaan tidak memiliki kantor klien tradisional, aliran dokumen dilakukan melalui surat atau kurir, dan banyak karyawan bekerja dari rumah. Perusahaan ini tidak lagi hanya sekedar bank dan, menurut saya, telah berubah menjadi perusahaan IT dengan teknologi DevOps yang berkembang.
Banyak contoh dan ceramah lainnya dapat ditemukan dalam rekaman pertemuan dan konferensi tematik. Saya mengunjungi beberapa di antaranya secara pribadi - ini adalah pengalaman yang sangat berguna bagi mereka yang ingin berkembang ke arah ini. Berikut tautan ke saluran YouTube dengan ceramah dan materi bagus tentang DevOps:
Sekarang lihat bisnis Anda dan pikirkan hal ini: Seberapa besar perusahaan Anda dan keuntungannya bergantung pada produk TI untuk memungkinkan interaksi pelanggan?
Jika perusahaan Anda menjual ikan di toko kecil dan satu-satunya produk TI adalah dua konfigurasi 1C: Perusahaan (Akuntansi dan UNF), maka hampir tidak masuk akal untuk membicarakan DevOps.
Jika Anda bekerja di perusahaan perdagangan dan manufaktur besar (misalnya, Anda memproduksi senapan berburu), Anda harus memikirkannya. Anda dapat mengambil inisiatif dan menyampaikan kepada manajemen Anda prospek penerapan DevOps. Nah, dan pada saat yang sama, pimpin proses ini. Posisi proaktif adalah salah satu prinsip penting filosofi DevOps.
Ukuran dan volume perputaran keuangan tahunan bukanlah kriteria utama untuk menentukan apakah perusahaan Anda memerlukan DevOps.
Bayangkan sebuah perusahaan industri besar yang tidak berinteraksi langsung dengan pelanggan. Misalnya, beberapa produsen mobil dan perusahaan manufaktur mobil. Saya tidak yakin sekarang, tapi dari pengalaman saya sebelumnya, selama bertahun-tahun semua interaksi pelanggan dilakukan melalui email dan telepon.
Klien mereka adalah daftar terbatas dealer mobil. Dan masing-masing ditugaskan seorang spesialis dari pabrikan. Semua aliran dokumen internal terjadi melalui SAP ERP. Karyawan internal pada dasarnya adalah klien dari sistem informasi. Namun IS ini dikendalikan dengan cara klasik dalam mengelola sistem cluster. Yang mengecualikan kemungkinan menggunakan praktik DevOps.
Oleh karena itu kesimpulannya: untuk perusahaan seperti itu, penerapan DevOps bukanlah sesuatu yang sangat penting, jika kita mengingat tujuan metodologi dari awal artikel. Namun saya tidak mengesampingkan bahwa mereka menggunakan beberapa alat DevOps saat ini.
Di sisi lain, ada banyak perusahaan kecil yang mengembangkan perangkat lunak menggunakan metodologi, filosofi, praktik, dan alat DevOps. Dan mereka percaya bahwa biaya penerapan DevOps adalah biaya yang memungkinkan mereka bersaing secara efektif di pasar perangkat lunak. Contoh perusahaan tersebut dapat dilihat .
Kriteria utama untuk memahami apakah DevOps diperlukan: apa nilai produk TI Anda bagi perusahaan dan pelanggan.
Jika produk utama perusahaan yang menghasilkan keuntungan adalah software, Anda memerlukan DevOps. Dan itu tidak begitu penting jika Anda menghasilkan uang nyata dengan menggunakan produk lain. Ini juga termasuk toko online atau aplikasi seluler dengan permainan.
Permainan apa pun ada berkat pendanaan: langsung atau tidak langsung dari para pemainnya. Di Playgendary, kami mengembangkan game seluler gratis dengan lebih dari 200 orang terlibat langsung dalam pembuatannya. Bagaimana cara kami menggunakan DevOps?
Ya, sama persis seperti yang dijelaskan di atas. Saya terus berkomunikasi dengan pengembang dan penguji, dan melakukan pelatihan internal untuk karyawan mengenai metodologi dan alat DevOps.
Kami sekarang secara aktif menggunakan Jenkins sebagai alat pipeline CI/CD untuk menjalankan semua pipeline perakitan dengan Unity dan penerapan selanjutnya ke App Store dan Play Market. Lebih banyak dari toolkit klasik:
- Asana - untuk manajemen proyek. Integrasi dengan Jenkins telah dikonfigurasi.
- Google Meet - untuk rapat video.
- Slack - untuk komunikasi dan berbagai peringatan, termasuk notifikasi dari Jenkins.
- Atlassian Confluence - untuk dokumentasi dan kerja kelompok.
Rencana jangka pendek kami termasuk memperkenalkan analisis kode statis menggunakan SonarQube dan melakukan pengujian UI otomatis menggunakan Selenium pada tahap Integrasi Berkelanjutan.
Alih-alih sebuah kesimpulan
Saya ingin mengakhiri dengan pemikiran berikut: untuk menjadi insinyur DevOps yang berkualifikasi tinggi, mempelajari cara berkomunikasi langsung dengan orang lain sangatlah penting.
Seorang insinyur DevOps adalah pemain tim. Dan tidak ada lagi. Inisiatif dalam berkomunikasi dengan rekan kerja harus datang dari dirinya, dan bukan di bawah pengaruh keadaan tertentu. Seorang spesialis DevOps harus melihat dan mengusulkan solusi terbaik untuk tim.
Dan ya, penerapan solusi apa pun akan memerlukan banyak diskusi, dan pada akhirnya mungkin akan berubah total. Berkembang secara mandiri, mengusulkan dan mengimplementasikan ide-idenya, orang seperti itu semakin bernilai baik bagi tim maupun bagi pemberi kerja. Yang pada akhirnya tercermin dalam besaran remunerasi bulanannya atau dalam bentuk bonus tambahan.
Sumber: www.habr.com