
Apa yang dibutuhkan untuk kesuksesan sebuah perusahaan IT di tahun 2019? Dosen di konfs dan mitaps berbicara banyak dengan kata-kata yang keras dan tidak selalu jelas kepada orang normal. Perjuangan untuk penyebaran, layanan mikro, penolakan monolit, transformasi DevOps dan banyak lagi. Jika Anda membuang keindahan verbal dan berbicara secara langsung dan dalam bahasa Rusia, semuanya bermuara pada tesis sederhana: membuat produk yang berkualitas, dan melakukannya dengan nyaman untuk tim.
Yang terakhir ini menjadi sangat penting. Bisnis akhirnya sampai pada kesimpulan bahwa proses pengembangan yang nyaman meningkatkan produktivitas, dan jika semuanya debugged dan bekerja seperti jarum jam, itu juga memberikan ruang untuk bermanuver dalam situasi kritis. Pernah, demi manuver ini, beberapa orang pintar menemukan cadangan, tetapi industri ini berkembang, dan kami mendatangi para insinyur DevOps - orang yang mengubah proses interaksi antara pembangunan dan infrastruktur eksternal menjadi sesuatu yang memadai dan tidak terkait dengan perdukunan.
Seluruh cerita dari "modulo" itu indah, tapi ... Kebetulan bagian dari admin tiba-tiba dijuluki DevOps, dan insinyur DevOps sendiri mulai membutuhkan setidaknya keterampilan telepati dan kewaskitaan.
Sebelum berbicara tentang masalah modern dalam penyediaan infrastruktur, mari kita putuskan apa yang kita maksud dengan istilah ini. Sampai saat ini, situasinya telah berkembang sedemikian rupa sehingga kami telah mencapai dualitas konsep ini: infrastruktur dapat bersifat eksternal bersyarat dan bersyarat internal.
Infrastruktur eksternal harus berarti segala sesuatu yang memastikan kemudahan layanan atau produk yang sedang dikembangkan tim. Ini adalah server aplikasi atau situs, hosting, dan layanan lain yang memastikan kinerja produk.
Infrastruktur internal mencakup layanan dan peralatan yang digunakan oleh tim pengembangan itu sendiri dan karyawan lain, yang biasanya ada banyak. Ini adalah server internal dari sistem penyimpanan kode, task manager yang dikerahkan secara lokal dan segalanya-segalanya-segalanya yang ada dalam intranet perusahaan.
Apa yang administrator sistem lakukan di perusahaan? Selain mengelola intranet perusahaan ini sendiri, sering kali meletakkan beban kekhawatiran ekonomi untuk memastikan ketersediaan peralatan kantor. Admin adalah orang yang sama yang dengan cepat menyeret unit sistem baru keluar dari ruang belakang atau laptop cadangan yang siap untuk bekerja, mengeluarkan keyboard baru dan merangkak merangkak di sekitar kantor, merentangkan kabel Ethernet. Admin adalah pemilik dan master lokal tidak hanya server internal dan eksternal, tetapi juga seorang eksekutif bisnis. Ya, beberapa administrator hanya dapat bekerja di system plane, tanpa perangkat keras. Mereka harus dibedakan dalam subkelas yang terpisah dari "administrator sistem infrastruktur." Dan seseorang mengkhususkan diri dalam melayani peralatan kantor secara eksklusif, untungnya, jika perusahaan memiliki lebih dari seratus orang, pekerjaan itu tidak pernah berakhir. Tapi tidak satu atau yang lain tidak.
Dan siapa DevOps? Devops adalah orang-orang yang berbicara tentang interaksi pengembangan perangkat lunak dengan infrastruktur eksternal. Lebih tepatnya, pengembang modern terlibat dalam proses pengembangan dan penyebaran jauh lebih dalam daripada administrator yang hanya membanjiri pembaruan di ftp yang pernah terlibat. Salah satu tugas utama insinyur DevOps sekarang adalah untuk memastikan proses interaksi yang dibangun dengan nyaman dan efisien antara tim pengembangan dan infrastruktur produk. Orang-orang inilah yang bertanggung jawab atas penyebaran rollback dan sistem penempatan, orang-orang inilah yang mengambil bagian dari pengembang dan berkonsentrasi sebanyak mungkin pada tugas mereka yang sangat penting. Pada saat yang sama, para devops tidak akan pernah meregangkan kabel baru atau memberikan laptop baru dari ruang belakang.
Apa yang menangkap?
Untuk pertanyaan "Siapa itu DevOps?" setengah dari karyawan sphere mulai merespons dengan sesuatu seperti "Yah, singkatnya, ini admin yang ..." dan selanjutnya. Ya, pada suatu waktu, ketika profesi insinyur-DevOps baru saja dimulai dari administrator paling berbakat dalam hal pelayanan, perbedaan di antara mereka tidak jelas bagi semua orang. Tetapi sekarang, ketika fungsi para biarawati dan admin dalam tim mulai berbeda secara radikal, membingungkan mereka di antara mereka sendiri, atau bahkan menempatkan tanda yang sama di antara mereka, tidak dapat diterima.
Tetapi apa artinya ini dalam bisnis?
Mempekerjakan, ini semua tentang dia.
Anda membuka lowongan "Administrator Sistem", dan di sana persyaratannya tercantum: "interaksi dengan pengembangan dan pelanggan", "sistem pengiriman CI / CD", "melayani server dan peralatan perusahaan", "mengelola sistem internal" dan seterusnya; Anda mengerti bahwa majikan itu membawa omong kosong. Tangkapannya adalah bahwa alih-alih "Sistem Administrator" dalam judul lowongan harus "DevOps-engineer", dan jika judul ini diubah, maka semuanya jatuh pada tempatnya.
Namun, kesan apa yang tercipta saat membaca lowongan seperti itu? Bahwa perusahaan sedang mencari operator multi-alat, yang akan menggunakan kontrol versi dan sistem pemantauan dan menggoyangkan giginya dengan ...
Tetapi untuk tidak meningkatkan tingkat kecanduan narkoba di pasar tenaga kerja, cukup untuk memanggil lowongan dengan nama yang tepat dan jelas memahami bahwa insinyur dan administrator sistem DevOps adalah dua entitas yang berbeda. Satu-satunya keinginan tak tertahankan dari beberapa pengusaha untuk memberikan kepada calon daftar persyaratan seluas mungkin mengarah pada fakta bahwa administrator sistem "klasik" berhenti untuk memahami apa yang terjadi di sekitar mereka. Apa, profesi bermutasi dan mereka ketinggalan kehidupan?
Tidak, tidak, dan tidak lagi. Administrator infrastruktur yang akan mengarahkan server internal perusahaan, atau menempati posisi dukungan L2 / L3 dan membantu karyawan lain, belum pergi ke mana pun dan tidak akan pergi.
Bisakah spesialis ini menjadi insinyur DevOps? Tentu saja mereka bisa. Sebenarnya, ini adalah lingkungan saudara mereka, yang membutuhkan keterampilan administrasi sistem, tetapi di samping itu, bekerja dengan pemantauan, sistem pengiriman, dan, secara umum, interaksi yang erat dengan tim pengembangan dan pengujian ditambahkan.
Masalah DevOps Lain
Faktanya, semuanya tidak terbatas pada perekrutan dan kebingungan konstan antara administrator dan devops. Di beberapa titik, bisnis dihadapkan dengan masalah pengiriman pembaruan dan interaksi tim pengembangan dengan infrastruktur akhir.
Mungkin inilah saat seorang paman dengan mata menyala datang ke tempat konferensi dan berkata, βDan kami melakukan ini dan menyebutnya DevOps. Orang-orang ini akan menyelesaikan semua masalah Anda β- dan mulai memberi tahu seberapa baik dia hidup di perusahaan setelah penerapan praktik DevOps.
Namun, itu tidak cukup untuk menyewa seorang insinyur DevOps agar semuanya berjalan sebagaimana mestinya. Perusahaan harus sepenuhnya melalui transformasi DevOps, yaitu, peran dan kemampuan pengembang kami harus dipahami dengan jelas juga di sisi pengembangan produk dan tim pengujian. Kami memiliki kisah "indah" tentang hal ini, yang sepenuhnya menggambarkan semua kaleng di tempat.
Situasi. Devops diwajibkan untuk menggunakan sistem rollback versi, tanpa secara khusus menyelidiki bagaimana itu akan bekerja. Misalkan, di dalam sistem Pengguna, ini adalah bidang yang terpisah di bawah nama depan, nama belakang dan kata sandi. Versi baru produk ini dirilis, tetapi untuk pengembang, "rollback" hanyalah tongkat ajaib yang akan memperbaiki segalanya, dan mereka bahkan tidak tahu cara kerjanya. Jadi, misalnya, para pengembang di tambalan berikutnya menggabungkan bidang nama depan dan belakang, meluncurkannya ke dalam prod, dan versi melambat untuk beberapa alasan. Apa yang sedang terjadi Manual datang ke devoop dan mengatakan "Tarik sakelar pisau!", Yaitu, memintanya untuk memutar kembali ke versi sebelumnya. Apa yang dilakukan devops? Rolls kembali ke versi sebelumnya, tetapi karena pengembang tidak ingin memahami bagaimana rollback ini dilakukan, tidak ada yang mengatakan kepada devo bahwa itu juga perlu untuk mengembalikan basis. Akibatnya, semuanya jatuh untuk kita, dan bukannya situs melambat, pengguna melihat kesalahan "500", karena versi lama tidak bekerja dengan bidang basis data baru. Devops tidak menyadari hal ini. Dikembangkan diam. Manajemen mulai kehilangan keberanian dan uang dan mengingat cadangan, menawarkan untuk mundur dari mereka sehingga "setidaknya sesuatu bekerja". Akibatnya, pengguna kehilangan semua data mereka untuk jangka waktu tertentu.
Kacang pergi, tentu saja, kepada para devops, yang "tidak membuat sistem rollback yang tepat," dan fakta bahwa rusa besar dalam cerita ini adalah pengembang tidak mengganggu siapa pun.
Kesimpulannya sederhana: tanpa pendekatan yang normal untuk DevOps, tidak ada banyak.
Hal utama yang perlu diingat: Insinyur DevOps bukanlah seorang pesulap, dan tanpa komunikasi berkualitas tinggi dan interaksi dua arah dengan pengembangan, ia tidak akan dapat mengatasi tugasnya. Devops tidak bisa dibiarkan sendirian dengan "masalah" mereka atau diberi perintah "jangan pergi ke pengembang, kode bisnis mereka", dan kemudian berharap bahwa pada saat kritis semuanya akan berfungsi sebagaimana mestinya. Jadi tidak berhasil.
Pada dasarnya, DevOps adalah kompetensi di antara manajemen dan teknologi. Selain itu, jauh dari jelas bahwa dalam koktail teknologi ini seharusnya ada lebih dari manajemen. Jika Anda benar-benar ingin membangun proses pengembangan yang lebih cepat dan lebih efisien, Anda harus memercayai pengembang Anda. Dia tahu alat yang tepat, dia telah mengimplementasikan proyek serupa, dia tahu bagaimana melakukannya. Bantu dia, dengarkan nasihatnya, jangan mencoba untuk mengisolasi di beberapa unit otonom. Jika admin dapat mengerjakannya sendiri, maka devops tidak berguna dalam kasus ini, mereka tidak akan dapat membantu Anda menjadi lebih baik jika Anda sendiri tidak ingin menerima bantuan ini.
Dan hal terakhir: berhentilah menyinggung administrator infrastruktur. Mereka memiliki bidang pekerjaan mereka sendiri yang sangat penting. Ya, admin bisa menjadi insinyur DevOps, tetapi ini harus terjadi atas permintaan orang itu sendiri, dan bukan dari bawah tongkat. Dan tidak ada yang salah dengan kenyataan bahwa administrator sistem ingin tetap menjadi administrator sistem - ini adalah profesi dan haknya yang terpisah. Jika ada keinginan untuk menjalani transformasi profesional, maka kita tidak boleh lupa bahwa perlu untuk membangun tidak hanya keterampilan teknologi, tetapi juga keterampilan manajerial. Kemungkinan besar Anda sebagai pemimpin harus menyatukan semua orang ini dan belajar berkomunikasi dalam satu bahasa.