Apa yang diperlukan agar perusahaan IT bisa sukses di tahun 2019? Para dosen di konferensi dan pertemuan mengucapkan banyak kata-kata keras yang tidak selalu dapat dimengerti oleh orang normal. Perjuangan untuk waktu penerapan, layanan mikro, pengabaian monolit, transformasi DevOps, dan masih banyak lagi. Jika kita membuang keindahan verbal dan berbicara secara langsung dan dalam bahasa Rusia, maka semuanya bermuara pada tesis sederhana: membuat produk berkualitas tinggi, dan melakukannya dengan nyaman untuk tim.
Hal terakhir ini menjadi sangat penting. Bisnis akhirnya sampai pada kesimpulan bahwa proses pengembangan yang nyaman akan meningkatkan produktivitas, dan jika semuanya di-debug dan bekerja seperti jam, hal ini juga memberikan ruang untuk bermanuver dalam situasi kritis. Suatu ketika, demi manuver ini, orang pintar datang dengan cadangan, tetapi industri sedang berkembang, dan kami menemui para insinyur DevOps - orang yang mengubah proses interaksi antara pengembangan dan infrastruktur eksternal menjadi sesuatu yang memadai dan tidak terkait dengan perdukunan.
Keseluruhan cerita “modular” ini luar biasa, tapi... Kebetulan beberapa admin tiba-tiba dijuluki DevOps, dan para insinyur DevOps sendiri mulai dituntut untuk memiliki setidaknya keterampilan telepati dan kewaskitaan.
Sebelum kita berbicara tentang masalah-masalah modern dalam penyediaan infrastruktur, mari kita definisikan apa yang dimaksud dengan istilah ini. Saat ini, situasinya telah berkembang sedemikian rupa sehingga kita telah mencapai dualitas konsep ini: infrastruktur dapat bersifat eksternal bersyarat dan internal bersyarat.
Yang kami maksud dengan infrastruktur eksternal adalah segala sesuatu yang menjamin fungsionalitas layanan atau produk yang dikembangkan tim. Ini adalah server aplikasi atau situs web, hosting, dan layanan lain yang memastikan fungsionalitas produk.
Infrastruktur internal mencakup layanan dan peralatan yang digunakan oleh tim pengembangan itu sendiri dan karyawan lain, yang biasanya jumlahnya banyak. Ini adalah server internal sistem penyimpanan kode, pengelola tugas yang diterapkan secara lokal, dan segala sesuatu yang ada dalam intranet perusahaan.
Apa yang dilakukan administrator sistem di sebuah perusahaan? Selain pekerjaan mengelola intranet korporat ini, seringkali juga menanggung beban masalah ekonomi untuk memastikan pengoperasian peralatan kantor. Adminnya adalah orang yang sama yang akan dengan cepat menyeret unit sistem baru atau laptop cadangan yang siap digunakan dari ruang belakang, memberikan keyboard baru dan merangkak melintasi kantor, merentangkan kabel Ethernet. Administrator adalah pemilik lokal dan penguasa tidak hanya server internal dan eksternal, tetapi juga eksekutif bisnis. Ya, beberapa administrator hanya dapat bekerja di bidang sistem, tanpa perangkat keras. Mereka harus dipisahkan menjadi subkelas terpisah yaitu “administrator sistem infrastruktur.” Dan beberapa mengkhususkan diri dalam melayani peralatan kantor secara eksklusif; untungnya, jika perusahaan memiliki lebih dari seratus orang, pekerjaan tidak akan pernah berakhir. Tapi tak satu pun dari mereka adalah devops.
Siapakah DevOps? Devops adalah orang-orang yang berbicara tentang interaksi pengembangan perangkat lunak dengan infrastruktur eksternal. Lebih tepatnya, pengembang modern terlibat dalam proses pengembangan dan penerapan jauh lebih dalam daripada keterlibatan admin yang hanya mengunggah pembaruan ke ftp. Salah satu tugas utama seorang insinyur DevOps saat ini adalah memastikan proses interaksi yang nyaman dan terstruktur secara efektif antara tim pengembangan dan infrastruktur produk. Orang-orang inilah yang bertanggung jawab untuk menerapkan sistem rollback dan penerapan; orang-orang inilah yang mengambil sebagian beban pengembang dan berkonsentrasi sebanyak mungkin pada tugas mereka yang sangat penting. Pada saat yang sama, devops tidak akan pernah memasang kabel baru atau mengeluarkan laptop baru dari ruang belakang (c) KO
Apa tangkapannya?
Untuk pertanyaan “Siapakah DevOps?” setengah dari pekerja di lapangan mulai menjawab sesuatu seperti "Singkatnya, ini admin yang ..." dan selanjutnya dalam teks. Ya, pada suatu waktu, ketika profesi insinyur DevOps baru saja muncul dari administrator paling berbakat dalam hal pemeliharaan layanan, perbedaan di antara mereka tidak terlihat jelas bagi semua orang. Namun sekarang, ketika fungsi devops dan admin dalam tim telah menjadi sangat berbeda, tidak dapat diterima untuk membingungkan mereka satu sama lain, atau bahkan menyamakan keduanya.
Tapi apa artinya ini bagi bisnis?
Mempekerjakan, itu semua tentang hal itu.
Anda membuka lowongan untuk "Administrator Sistem", dan persyaratan yang tercantum di sana adalah "interaksi dengan pengembangan dan pelanggan", "sistem pengiriman CI/CD", "pemeliharaan server dan peralatan perusahaan", "administrasi sistem internal" dan sebagainya pada; Anda memahami bahwa majikan sedang berbicara omong kosong. Tangkapannya adalah bahwa alih-alih "Administrator Sistem", judul lowongannya haruslah "Insinyur DevOps", dan jika judul ini diubah, maka semuanya akan beres.
Namun, kesan apa yang didapat ketika membaca lowongan seperti itu? Bahwa perusahaan sedang mencari operator multi-mesin yang akan menerapkan kontrol versi dan sistem pemantauan dan akan menekan twister dengan giginya...
Namun agar tidak meningkatkan tingkat kecanduan narkoba di pasar tenaga kerja, cukup menyebutkan lowongan dengan nama aslinya dan memahami dengan jelas bahwa insinyur DevOps dan administrator sistem adalah dua entitas yang berbeda. Namun keinginan yang tak tertahankan dari beberapa pemberi kerja untuk memberikan daftar persyaratan seluas mungkin kepada seorang kandidat mengarah pada fakta bahwa administrator sistem “klasik” tidak lagi memahami apa yang terjadi di sekitar mereka. Apa, profesinya bermutasi dan ketinggalan jaman?
Tidak, tidak, dan sekali lagi tidak. Administrator infrastruktur yang akan mengelola server internal perusahaan, atau menempati posisi pendukung L2/L3 dan membantu karyawan lain, belum dan tidak akan hilang.
Bisakah para spesialis ini menjadi insinyur DevOps? Tentu saja bisa. Faktanya, ini adalah lingkungan terkait yang memerlukan keterampilan administrasi sistem, tetapi selain itu, pekerjaan dengan pemantauan, sistem pengiriman dan, secara umum, interaksi yang erat dengan tim pengembangan dan pengujian juga ditambahkan.
Masalah DevOps lainnya
Faktanya, semuanya tidak terbatas pada perekrutan dan kebingungan terus-menerus antara admin dan pengembang. Pada titik tertentu, bisnis dihadapkan pada masalah penyampaian pembaruan dan interaksi tim pengembangan dengan infrastruktur akhir.
Mungkin saat itulah seorang paman dengan mata berbinar berdiri di atas panggung sebuah konferensi dan berkata, “Kami melakukan ini dan menyebutnya DevOps. Orang-orang ini akan menyelesaikan semua masalah Anda” - dan mulai menceritakan betapa baiknya kehidupan di perusahaan setelah menerapkan praktik DevOps.
Namun, mempekerjakan seorang insinyur DevOps saja tidak cukup untuk membuat semuanya berjalan sebagaimana mestinya. Perusahaan harus menjalani transformasi DevOps secara menyeluruh, yaitu peran dan kemampuan DevOps kami juga harus dipahami dengan jelas di sisi tim pengembangan dan pengujian produk. Kami memiliki kisah “menakjubkan” mengenai topik ini yang sepenuhnya menggambarkan semua kebrutalan yang terjadi di beberapa tempat.
Situasi. DevOps diperlukan untuk menerapkan sistem rollback versi tanpa benar-benar mempelajari cara kerjanya. Mari kita asumsikan bahwa dalam sistem Pengguna terdapat kolom terpisah untuk nama depan, nama belakang, dan kata sandi. Versi baru produk telah dirilis, tetapi bagi pengembang, "kembalikan" hanyalah tongkat ajaib yang akan memperbaiki segalanya, dan mereka bahkan tidak tahu cara kerjanya. Jadi, misalnya, pada patch berikutnya, pengembang menggabungkan kolom nama depan dan belakang, meluncurkannya ke dalam produksi, tetapi versinya lambat karena alasan tertentu. Apa yang terjadi? Manajemen mendatangi devops dan berkata "Tarik tombolnya!", yaitu memintanya untuk memutar kembali ke versi sebelumnya. Apa yang dilakukan devops? Ini mengembalikan ke versi sebelumnya, tetapi karena pengembang tidak ingin mengetahui bagaimana pengembalian ini dilakukan, tidak ada yang memberi tahu tim pengembang bahwa database juga perlu dibatalkan. Akibatnya, semuanya macet bagi kami, dan alih-alih situs web yang lambat, pengguna melihat kesalahan “500”, karena versi lama tidak berfungsi dengan bidang database baru. Devops tidak tahu tentang ini. Para pengembang diam. Manajemen mulai kehilangan keberanian dan uang serta mengingat cadangannya, menawarkan untuk membatalkannya sehingga “setidaknya sesuatu akan berhasil.” Akibatnya, pengguna kehilangan semua datanya selama jangka waktu tertentu.
Yang gila, tentu saja, jatuh ke tangan pengembang, yang “tidak membuat sistem rollback yang tepat,” dan tidak ada yang peduli bahwa rusa besar dalam cerita ini adalah pengembang.
Kesimpulannya sederhana: tanpa pendekatan normal terhadap DevOps, hal ini tidak akan banyak berguna.
Hal utama yang perlu diingat: seorang insinyur DevOps bukanlah seorang pesulap, dan tanpa komunikasi yang berkualitas dan interaksi dua arah dengan pengembangan, ia tidak akan mengatasi tugasnya. Pengembang tidak bisa dibiarkan sendirian dengan “masalah” mereka atau diberi perintah “jangan ikut campur dengan pengembang, tugas mereka adalah membuat kode,” dan kemudian berharap bahwa pada saat kritis semuanya akan berjalan sebagaimana mestinya. Bukan itu cara kerjanya.
Pada dasarnya, DevOps adalah kompetensi yang berada di perbatasan antara manajemen dan teknologi. Selain itu, masih jauh dari jelas bahwa harus ada lebih banyak teknologi daripada manajemen dalam koktail ini. Jika Anda benar-benar ingin membangun proses pengembangan yang lebih cepat dan efisien, Anda harus mempercayai tim pengembang Anda. Dia mengetahui alat yang tepat, dia telah mengimplementasikan proyek serupa, dia tahu bagaimana melakukannya. Bantu dia, dengarkan nasihatnya, jangan mencoba mengisolasi dia ke dalam semacam unit otonom. Jika admin bisa bekerja sendiri, maka devop tidak ada gunanya dalam hal ini, mereka tidak akan bisa membantu Anda menjadi lebih baik jika Anda sendiri tidak mau menerima bantuan ini.
Dan satu hal lagi: berhenti menyinggung administrator infrastruktur. Mereka memiliki pekerjaan mereka sendiri yang sangat penting. Ya, seorang administrator dapat menjadi insinyur DevOps, tetapi hal ini harus terjadi atas permintaan orang tersebut sendiri, dan bukan di bawah tekanan. Dan tidak ada yang salah dengan kenyataan bahwa seorang administrator sistem ingin tetap menjadi administrator sistem - ini adalah profesi dan haknya yang terpisah. Jika Anda ingin menjalani transformasi profesional, jangan pernah lupa bahwa Anda tidak hanya harus membangun keterampilan teknologi, tetapi juga keterampilan manajemen. Kemungkinan besar, sebagai pemimpin, Andalah yang harus menyatukan semua orang ini dan mengajari mereka berkomunikasi dalam bahasa yang sama.
Sumber: www.habr.com