Apakah yang diperlukan oleh syarikat IT untuk berjaya pada tahun 2019? Pensyarah di persidangan dan pertemuan mengucapkan banyak perkataan yang lantang yang tidak selalu dapat difahami oleh orang biasa. Perjuangan untuk masa penggunaan, perkhidmatan mikro, pengabaian monolit, transformasi DevOps dan banyak lagi. Jika kita membuang kecantikan lisan dan bercakap secara langsung dan dalam bahasa Rusia, maka semuanya bermuara kepada tesis mudah: buat produk berkualiti tinggi, dan lakukannya dengan selesa untuk pasukan.
Yang terakhir telah menjadi sangat penting. Perniagaan akhirnya membuat kesimpulan bahawa proses pembangunan yang selesa meningkatkan produktiviti, dan jika semuanya dinyahpepijat dan berfungsi seperti jam, ia juga memberi sedikit ruang untuk bergerak dalam situasi kritikal. Pada suatu masa dahulu, demi gerakan ini, orang pintar tertentu datang dengan sandaran, tetapi industri sedang berkembang, dan kami datang kepada jurutera DevOps - orang yang mengubah proses interaksi antara pembangunan dan infrastruktur luaran menjadi sesuatu yang mencukupi dan tidak berkaitan dengan dukun.
Keseluruhan cerita "modular" ini bagus, tetapi... Kebetulan beberapa pentadbir telah digelar DevOps secara tiba-tiba, dan jurutera DevOps sendiri mula dikehendaki mempunyai sekurang-kurangnya kemahiran telepati dan kewaskitaan.
Sebelum kita bercakap tentang masalah moden penyediaan infrastruktur, mari kita tentukan apa yang kita maksudkan dengan istilah ini. Pada masa ini, keadaan telah berkembang sedemikian rupa sehingga kita telah mencapai dualiti konsep ini: infrastruktur boleh bersyarat luaran dan bersyarat dalaman.
Dengan infrastruktur luaran yang kami maksudkan adalah segala-galanya yang memastikan kefungsian perkhidmatan atau produk yang sedang dibangunkan oleh pasukan. Ini ialah pelayan aplikasi atau tapak web, pengehosan dan perkhidmatan lain yang memastikan kefungsian produk.
Infrastruktur dalaman termasuk perkhidmatan dan peralatan yang digunakan oleh pasukan pembangunan itu sendiri dan pekerja lain, yang biasanya terdapat ramai. Ini adalah pelayan dalaman sistem storan kod, pengurus tugas yang digunakan secara tempatan dan segala-galanya, segala-galanya, segala-galanya yang wujud dalam intranet korporat.
Apakah yang dilakukan oleh pentadbir sistem dalam syarikat? Sebagai tambahan kepada kerja mentadbir intranet yang sangat korporat ini, ia sering menanggung beban kebimbangan ekonomi untuk memastikan kebolehkendalian peralatan pejabat. Pentadbir adalah lelaki yang sama yang akan segera menyeret unit sistem baharu atau komputer riba ganti sedia untuk digunakan dari bilik belakang, memberikan papan kekunci baharu dan merangkak merangkak melalui pejabat, meregangkan kabel Ethernet. Pentadbir ialah pemilik tempatan dan penguasa bukan sahaja pelayan dalaman dan luaran, tetapi juga eksekutif perniagaan. Ya, sesetengah pentadbir hanya boleh bekerja dalam satah sistem, tanpa perkakasan. Mereka harus dipisahkan ke dalam subkelas berasingan "pentadbir sistem infrastruktur." Dan ada yang pakar dalam menyelenggara peralatan pejabat secara eksklusif; mujurlah, jika syarikat itu mempunyai lebih daripada seratus orang, kerja itu tidak pernah berakhir. Tetapi kedua-duanya bukan devops.
Siapa DevOps? Devops ialah lelaki yang bercakap tentang interaksi pembangunan perisian dengan infrastruktur luaran. Lebih tepat lagi, devops moden terlibat dalam proses pembangunan dan penggunaan lebih mendalam berbanding pentadbir yang hanya memuat naik kemas kini ke ftp yang pernah terlibat. Salah satu tugas utama jurutera DevOps kini ialah memastikan proses interaksi yang selesa dan tersusun secara berkesan antara pasukan pembangunan dan infrastruktur produk. Orang-orang inilah yang bertanggungjawab untuk menggunakan sistem rollback dan penempatan; merekalah yang mengambil sebahagian daripada beban pembangun dan menumpukan sebanyak mungkin pada tugas mereka yang sangat penting. Pada masa yang sama, devops tidak akan sekali-kali menjalankan kabel baharu atau mengeluarkan komputer riba baharu dari bilik belakang (c) KO
Apa tangkapannya?
Kepada soalan "Siapa DevOps?" separuh daripada pekerja di lapangan mula menjawab sesuatu seperti "Nah, ringkasnya, ini adalah pentadbir yang ..." dan seterusnya dalam teks. Ya, suatu ketika dahulu, ketika profesion jurutera DevOps baru muncul daripada pentadbir yang paling berbakat dari segi penyelenggaraan perkhidmatan, perbezaan antara mereka tidak jelas kepada semua orang. Tetapi kini, apabila fungsi devops dan admin dalam pasukan telah menjadi berbeza secara radikal, adalah tidak boleh diterima untuk mengelirukan mereka antara satu sama lain, malah menyamakan mereka.
Tetapi apakah maksud ini untuk perniagaan?
Mengupah, semuanya mengenainya.
Anda membuka kekosongan untuk "Pentadbir Sistem", dan keperluan yang disenaraikan di sana ialah "interaksi dengan pembangunan dan pelanggan", "Sistem penghantaran CI/CD", "penyelenggaraan pelayan dan peralatan syarikat", "pentadbiran sistem dalaman" dan sebagainya. pada; anda faham bahawa majikan bercakap kosong. Tangkapannya ialah bukannya "Pentadbir Sistem" tajuk kekosongan itu hendaklah "Jurutera DevOps", dan jika tajuk ini ditukar, maka semuanya akan sesuai.
Namun, apakah kesan yang diperoleh apabila membaca jawatan kosong tersebut? Bahawa syarikat itu sedang mencari pengendali berbilang mesin yang akan menggunakan kedua-dua versi kawalan dan sistem pemantauan dan akan memerah twister dengan giginya...
Tetapi untuk tidak meningkatkan tahap ketagihan dadah dalam pasaran buruh, sudah cukup untuk memanggil kekosongan dengan nama yang betul dan memahami dengan jelas bahawa jurutera DevOps dan pentadbir sistem adalah dua entiti yang berbeza. Tetapi keinginan yang tidak dapat dihalang sesetengah majikan untuk membentangkan senarai keperluan yang paling luas kepada calon membawa kepada fakta bahawa pentadbir sistem "klasik" tidak lagi memahami apa yang berlaku di sekeliling mereka. Apa, profesion itu berubah dan mereka ketinggalan zaman?
Tidak tidak dan sekali lagi tidak. Pentadbir infrastruktur yang akan menguruskan pelayan dalaman syarikat, atau menduduki jawatan sokongan L2/L3 dan membantu pekerja lain, belum pergi dan tidak akan pergi.
Bolehkah pakar ini menjadi jurutera DevOps? Sudah tentu mereka boleh. Sebenarnya, ini adalah persekitaran yang berkaitan yang memerlukan kemahiran pentadbiran sistem, tetapi sebagai tambahan kepada ini, bekerja dengan pemantauan, sistem penyampaian dan, secara amnya, interaksi rapat dengan pasukan pembangunan dan ujian ditambah.
Satu lagi Masalah DevOps
Sebenarnya, segala-galanya tidak terhad kepada hanya mengupah dan kekeliruan berterusan antara pentadbir dan devops. Pada satu ketika, perniagaan berhadapan dengan masalah menyampaikan kemas kini dan interaksi pasukan pembangunan dengan infrastruktur akhir.
Mungkin ketika seorang bapa saudara dengan mata berkilauan berdiri di atas pentas persidangan dan berkata, βKami melakukan ini dan memanggilnya DevOps. Mereka ini akan menyelesaikan semua masalah andaβ - dan mula memberitahu betapa baiknya kehidupan dalam syarikat selepas melaksanakan amalan DevOps.
Walau bagaimanapun, ia tidak mencukupi untuk mengupah jurutera DevOps untuk menjadikan semuanya berfungsi sebagaimana mestinya. Syarikat mesti menjalani transformasi DevOps yang lengkap, iaitu, peranan dan keupayaan DevOps kami juga mesti difahami dengan jelas di sisi pasukan pembangunan dan ujian produk. Kami mempunyai cerita "hebat" mengenai topik ini yang menggambarkan sepenuhnya semua kekejaman yang berlaku di beberapa tempat.
Situasi. DevOps diperlukan untuk menggunakan sistem rollback versi tanpa benar-benar mendalami cara ia akan berfungsi. Mari kita anggap bahawa dalam sistem Pengguna terdapat medan berasingan untuk nama pertama, nama keluarga dan kata laluan. Versi baharu produk keluar, tetapi bagi pembangun, "putar balik" hanyalah tongkat ajaib yang akan membetulkan segala-galanya, dan mereka tidak tahu cara ia berfungsi. Jadi, sebagai contoh, dalam tampalan seterusnya pembangun menggabungkan medan nama pertama dan nama keluarga, melancarkannya ke dalam pengeluaran, tetapi versinya lambat atas sebab tertentu. Apa yang sedang berlaku? Pengurusan datang ke devops dan berkata "Tarik suis!", iaitu, meminta dia untuk kembali ke versi sebelumnya. Apa yang devops lakukan? Ia kembali kepada versi sebelumnya, tetapi oleh kerana pembangun tidak mahu memikirkan cara pemulangan ini dilakukan, tiada siapa yang memberitahu pasukan devops bahawa pangkalan data juga perlu digulung semula. Akibatnya, segala-galanya ranap untuk kami, dan bukannya tapak web yang perlahan, pengguna melihat ralat "500", kerana versi lama tidak berfungsi dengan medan pangkalan data baharu. Devops tidak tahu tentang ini. Pemaju senyap. Pihak pengurusan mula kehilangan saraf dan wang mereka dan mengingati sandaran, menawarkan untuk berpatah balik daripada mereka supaya "sekurang-kurangnya sesuatu akan berfungsi." Akibatnya, pengguna kehilangan semua data mereka dalam satu tempoh masa.
Kacang, sudah tentu, pergi ke devops, yang "tidak membuat sistem rollback yang betul," dan tiada siapa yang peduli bahawa moose dalam cerita ini adalah pembangun.
Kesimpulannya mudah: tanpa pendekatan biasa untuk DevOps seperti itu, ia tidak berguna.
Perkara utama yang perlu diingat: seorang jurutera DevOps bukan ahli silap mata, dan tanpa komunikasi yang berkualiti dan interaksi dua hala dengan pembangunan, dia tidak akan dapat menangani tugasnya. Devs tidak boleh dibiarkan bersendirian dengan "masalah" mereka atau diberi arahan "jangan campur tangan dengan pembangun, tugas mereka adalah untuk mengekod," dan kemudian berharap bahawa pada saat genting semuanya akan berfungsi sebagaimana mestinya. Itu bukan cara ia berfungsi.
Pada asasnya, DevOps ialah kecekapan di sempadan antara pengurusan dan teknologi. Lebih-lebih lagi, adalah jauh dari jelas bahawa perlu ada lebih banyak teknologi daripada pengurusan dalam koktel ini. Jika anda benar-benar mahu membina proses pembangunan yang lebih pantas dan cekap, anda mesti mempercayai pasukan devops anda. Dia tahu alat yang betul, dia telah melaksanakan projek yang serupa, dia tahu bagaimana untuk melakukannya. Bantu dia, dengar nasihatnya, jangan cuba mengasingkan dia ke dalam beberapa jenis unit autonomi. Jika pentadbir boleh bekerja sendiri, maka devops tidak berguna dalam kes ini; mereka tidak akan dapat membantu anda menjadi lebih baik jika anda sendiri tidak mahu menerima bantuan ini.
Dan satu perkara terakhir: berhenti menyinggung pentadbir infrastruktur. Mereka mempunyai bahagian depan kerja mereka sendiri yang sangat penting. Ya, pentadbir boleh menjadi jurutera DevOps, tetapi ini sepatutnya berlaku atas permintaan orang itu sendiri, dan bukan di bawah tekanan. Dan tidak ada yang salah dengan hakikat bahawa pentadbir sistem mahu kekal sebagai pentadbir sistem - ini adalah profesionnya yang berasingan dan haknya. Jika anda ingin menjalani transformasi profesional, maka anda tidak boleh lupa bahawa anda perlu membina bukan sahaja kemahiran teknologi, tetapi juga kemahiran pengurusan. Kemungkinan besar, terpulang kepada anda sebagai pemimpin untuk menyatukan semua orang ini dan mengajar mereka berkomunikasi dalam bahasa yang sama.
Sumber: www.habr.com