DevOps wis dadi topik sing populer banget sajrone sawetara taun kepungkur. Akeh wong ngimpi gabung, nanging, minangka praktik nuduhake, asring mung amarga tingkat gaji.
Sawetara wong dhaptar DevOps ing resume, sanajan dheweke ora ngerti utawa ngerti inti saka istilah kasebut. Sawetara wong mikir yen sawise sinau Ansible, GitLab, Jenkins, Terraform lan liya-liyane (dhaptar bisa diterusake miturut selera sampeyan), sampeyan bakal langsung dadi "devopsist". Iki, mesthi, ora bener.
Kanggo sawetara taun kepungkur, aku utamane melu implementasi DevOps ing macem-macem perusahaan. Sadurunge, dheweke kerja luwih saka 20 taun ing posisi wiwit saka administrator sistem nganti direktur IT. Saiki DevOps Lead Engineer ing Playgendary.
Sapa sing DevOps
Gagasan kanggo nulis artikel muncul sawise pitakonan liyane: "Sapa DevOps?" Isih durung ana istilah sing ditemtokake kanggo apa utawa sapa. Sawetara jawaban wis ana ing iki . Kaping pisanan, aku bakal nyorot poin utama saka iku, banjur aku bakal nuduhake pengamatan lan pikiranku.
DevOps dudu spesialis sing bisa nyewa, dudu sakumpulan utilitas, lan dudu departemen pangembang karo insinyur.
DevOps minangka filosofi lan metodologi.
Ing tembung liyane, iki minangka sakumpulan praktik sing mbantu pangembang kanthi aktif sesambungan karo administrator sistem. Yaiku, kanggo nyambungake lan nggabungake proses kerja menyang saben liyane.
Kanthi tekane DevOps, struktur lan peran spesialis tetep padha (ana pangembang, ana insinyur), nanging aturan interaksi wis diganti. Wates antarane departemen wis burem.
Tujuan DevOps bisa diterangake ing telung poin:
- Piranti lunak kudu dianyari kanthi rutin.
- Piranti lunak kudu ditindakake kanthi cepet.
- Piranti lunak kudu disebarake kanthi trep lan ing wektu sing cendhak.
Ora ana alat siji kanggo DevOps. Konfigurasi, ngirim lan sinau sawetara produk ora ateges DevOps wis muncul ing perusahaan. Ana akeh alat lan kabeh digunakake ing macem-macem tahapan, nanging dadi tujuan umum.
Lan iki mung bagean saka alat DevOps
Aku wis ngewawancarai wong kanggo posisi insinyur DevOps luwih saka 2 taun saiki, lan aku ngerti kepiye pentinge ngerti kanthi jelas babagan inti istilah kasebut. Aku wis nglumpukake pengalaman tartamtu, pengamatan lan pikirane sing pengin dituduhake.
Saka pengalaman wawancara, aku ndeleng gambar ing ngisor iki: spesialis sing nganggep DevOps judhul proyek biasane duwe misunderstandings karo kolega.
Ana conto sing nggumunake. Wong enom teka ing wawancara karo akeh tembung pinter ing resume. Ing telung proyek pungkasan, dheweke duwe pengalaman 5-6 sasi. Aku ninggalake loro startup amarga padha "ora njupuk mati." Nanging babagan perusahaan katelu, dheweke ujar manawa ora ana sing ngerti dheweke: pangembang nulis kode ing Windows, lan direktur meksa kode kasebut "dibungkus" ing Docker biasa lan digabungake menyang pipa CI / CD. Wong lanang kasebut ujar akeh perkara negatif babagan papan kerja saiki lan kanca-kancane - aku mung pengin mangsuli: "Dadi sampeyan ora bakal adol gajah."
Banjur aku takon pitakonan sing paling dhuwur ing dhaptar kanggo saben calon.
- Apa tegese DevOps kanggo sampeyan?
- Umume utawa kepiye carane aku ngerteni?
Aku kasengsem ing pendapat pribadi. Dheweke ngerti teori lan asal saka istilah kasebut, nanging dheweke ora setuju banget. Dheweke percaya DevOps minangka judhul proyek. Iki ngendi oyod saka masalah kang dumunung. Uga spesialis liyane kanthi pendapat sing padha.
Pengusaha, wis krungu akeh babagan "sihir DevOps", pengin golek wong sing bakal teka lan nggawe "sihir" iki. Lan pelamar saka kategori "DevOps minangka proyek" ora ngerti manawa kanthi pendekatan iki ora bakal bisa nyukupi pangarepan. Lan, umume, dheweke nulis DevOps ing resume amarga iki minangka tren lan mbayar akeh.
Metodologi lan filosofi DevOps
Metodologi bisa teoritis lan praktis. Ing kasus kita, iku sing nomer loro. Kaya sing wis dakcritakake ing ndhuwur, DevOps minangka sakumpulan praktik lan strategi sing digunakake kanggo nggayuh tujuan sing wis ditemtokake. Lan ing saben kasus, gumantung saka proses bisnis perusahaan, bisa uga beda-beda. Sing ora nggawe luwih apik utawa luwih elek.
Metodologi DevOps mung minangka sarana kanggo nggayuh tujuan.
Saiki babagan filosofi DevOps. Lan iki mbokmenawa pitakonan paling angel.
Cukup angel kanggo ngrumusake jawaban sing ringkes lan ringkes, amarga durung diformalkan. Lan amarga para penganut filosofi DevOps luwih melu praktik, ora ana wektu kanggo filosofi. Nanging, iki minangka proses sing penting banget. Kajaba iku, langsung ana hubungane karo kegiatan teknik. Malah ana area kawruh khusus - .
Ora ana subjek kasebut ing universitasku, aku kudu sinau kabeh dhewe nggunakake bahan sing bisa ditemokake ing taun 90an. Topik kasebut opsional kanggo pendhidhikan teknik, mula ora ana formalisasi jawaban. Nanging wong-wong sing serius nyemplungake ing DevOps wiwit ngrasakake "semangat" utawa "komprehensif semaput" tartamtu saka kabeh proses perusahaan.
Nggunakake pengalaman dhewe, aku nyoba kanggo formalize sawetara "postulates" filsafat iki. Asil kasebut ing ngisor iki:
- DevOps dudu barang mandiri sing bisa dipisahake dadi area kawruh utawa kegiatan sing kapisah.
- Kabeh karyawan perusahaan kudu dipandu dening metodologi DevOps nalika ngrancang kegiatane.
- DevOps mengaruhi kabeh proses ing perusahaan.
- DevOps ana kanggo nyuda biaya wektu kanggo proses apa wae ing perusahaan kanggo njamin pangembangan layanan lan kenyamanan pelanggan maksimal.
- DevOps, ing basa modern, minangka posisi proaktif saben karyawan perusahaan, kanthi tujuan nyuda biaya wektu lan ningkatake kualitas produk IT ing sekitar kita.
Aku mikir yen "postulates" minangka topik sing kapisah kanggo diskusi. Nanging saiki ana sing kudu dibangun.
Apa sing ditindakake DevOps
Tembung kunci ing kene yaiku komunikasi. Ana akeh komunikasi, sing wiwitane kudu persis karo insinyur DevOps sing padha. Kok ngono? Amarga iki filsafat lan metodologi, lan mung kawruh engineering.
Aku ora bisa ngomong kanthi yakin 100% babagan pasar tenaga kerja Barat. Nanging aku ngerti akeh babagan pasar DevOps ing Rusia. Saliyane atusan wawancara, sajrone setengah taun kepungkur aku wis melu atusan presales teknis kanggo layanan "Implementasi DevOps" kanggo perusahaan lan bank Rusia gedhe.
Ing Rusia, DevOps isih enom banget, nanging wis dadi topik trending. Sing aku ngerti, mung ing Moskow kekurangan spesialis kasebut ing 2019 luwih saka 1000 wong. Lan tembung Kubernetes kanggo juragan meh kaya gombal abang kanggo bantheng. Penganut alat iki siap digunakake sanajan ora perlu lan nguntungake ekonomi. Majikan ora tansah mangertos ing kasus apa sing luwih cocok kanggo nggunakake, lan karo panyebaran sing tepat, njaga klaster Kubernetes biaya 2-3 kaping luwih saka nyebarke aplikasi nggunakake skema cluster conventional. Gunakake ing ngendi sampeyan pancene mbutuhake.
Ngleksanakake DevOps larang regane. Lan iku sabdho mung ngendi ndadekke keuntungan ekonomi ing wilayah liyane, lan ora ing dhewe.
Insinyur DevOps, nyatane, pionir - dheweke sing kudu dadi sing pertama ngetrapake metodologi iki ing perusahaan lan mbangun proses. Kanggo sukses, spesialis kudu terus sesambungan karo karyawan lan kolega ing kabeh tingkat. Kaya sing biasane dakkandhakake, kabeh karyawan perusahaan kudu melu proses implementasi DevOps: saka wanita pembersih nganti CEO. Lan iki minangka prasyarat. Yen anggota paling enom saka tim ora ngerti lan ngerti apa DevOps lan ngapa tumindak organisasi tartamtu ditindakake, mula implementasine sing sukses ora bakal bisa ditindakake.
Uga, insinyur DevOps kudu nggunakake sumber daya administratif saka wektu kanggo wektu. Contone, kanggo ngatasi "resistensi lingkungan" - nalika tim durung siyap nampa alat lan metodologi DevOps.
Pangembang mung kudu nulis kode lan tes. Kanggo nindakake iki, dheweke ora butuh laptop super kuat sing bakal dipasang lan ndhukung kabeh infrastruktur proyek sacara lokal. Contone, pangembang ngarep nyimpen kabeh unsur aplikasi ing laptop, kalebu database, emulator S3 (minio), etc. Tegese, dheweke mbuwang akeh wektu kanggo njaga infrastruktur lokal iki lan berjuang kanthi tangan siji-sijine karo kabeh masalah solusi kasebut. Tinimbang ngembangaken kode kanggo ngarep. Wong kaya ngono bisa tahan banget marang owah-owahan apa wae.
Nanging ana tim sing, sebaliknya, seneng ngenalake alat lan metode anyar, lan aktif melu proses iki. Sanajan ing kasus iki, komunikasi antarane insinyur DevOps lan tim ora dibatalake.
Nalika DevOps ora dibutuhake
Ana kahanan nalika DevOps ora dibutuhake. Iki kasunyatan - kudu dimangerteni lan ditampa.
Kaping pisanan, iki ditrapake kanggo perusahaan apa wae (utamane bisnis cilik), nalika bathi ora langsung gumantung saka anane utawa ora ana produk IT sing nyedhiyakake layanan informasi kanggo klien. Lan ing kene kita ora ngomong babagan situs web perusahaan, dadi "kertu bisnis" statis utawa kanthi pamblokiran warta dinamis, lsp.
DevOps dibutuhake nalika kepuasan klien lan kepinginan bali menyang sampeyan maneh gumantung saka kasedhiyan layanan informasi iki kanggo interaksi karo klien, kualitas lan nargetake.
Conto sing nyenengake yaiku salah sawijining bank sing kondhang. Perusahaan kasebut ora duwe kantor klien tradisional, aliran dokumen ditindakake liwat surat utawa kurir, lan akeh karyawan kerja saka omah. Perusahaan kasebut wis mandheg dadi bank lan, miturut pendapatku, wis dadi perusahaan IT kanthi teknologi DevOps sing dikembangake.
Akeh conto lan ceramah liyane sing bisa ditemokake ing rekaman pertemuan tematik lan konferensi. Aku ngunjungi sawetara wong kanthi pribadi - iki minangka pengalaman sing migunani banget kanggo wong sing pengin berkembang ing arah iki. Iki link menyang saluran YouTube kanthi ceramah lan materi sing apik babagan DevOps:
Saiki deleng bisnis sampeyan lan pikirake babagan iki: Pira perusahaan sampeyan lan bathi gumantung karo produk IT kanggo ngaktifake interaksi pelanggan?
Yen perusahaan sampeyan adol iwak ing toko cilik lan siji-sijine produk IT yaiku rong 1C: Konfigurasi perusahaan (Akuntansi lan UNF), mula ora ana gunane kanggo ngomong babagan DevOps.
Yen sampeyan kerja ing perusahaan dagang lan manufaktur gedhe (contone, sampeyan ngasilake bedhil mburu), sampeyan kudu mikir babagan iki. Sampeyan bisa njupuk inisiatif lan ngirimake menyang manajemen prospek kanggo ngetrapake DevOps. Inggih, lan ing wektu sing padha, mimpin proses iki. Posisi sing proaktif minangka salah sawijining prinsip penting saka filosofi DevOps.
Ukuran lan volume omset finansial taunan ora dadi kriteria utama kanggo nemtokake manawa perusahaan sampeyan butuh DevOps.
Ayo mbayangno perusahaan industri gedhe sing ora sesambungan langsung karo pelanggan. Contone, sawetara produsen mobil lan perusahaan manufaktur mobil. Aku ora yakin saiki, nanging saka pengalaman kepungkur, nganti pirang-pirang taun kabeh interaksi pelanggan ditindakake liwat email lan telpon.
Klien kasebut minangka dhaptar bakul mobil sing winates. Lan saben wong diwenehi spesialis saka pabrikan. Kabeh aliran dokumen internal dumadi liwat SAP ERP. Karyawan internal sejatine minangka klien saka sistem informasi. Nanging IS iki dikontrol kanthi cara klasik kanggo ngatur sistem kluster. Sing ora kalebu kamungkinan nggunakake praktik DevOps.
Mula kesimpulane: kanggo perusahaan kasebut, implementasine DevOps ora penting banget, yen kita ngelingi tujuan metodologi kasebut wiwit wiwitan artikel. Nanging aku ora nolak yen dheweke nggunakake sawetara alat DevOps saiki.
Ing sisih liya, ana akeh perusahaan cilik sing ngembangake piranti lunak nggunakake metodologi, filosofi, praktik lan alat DevOps. Lan dheweke percaya yen biaya implementasi DevOps minangka biaya sing ngidini dheweke bisa bersaing kanthi efektif ing pasar piranti lunak. Conto perusahaan kasebut bisa dideleng .
Kriteria utama kanggo mangerteni apa DevOps dibutuhake: apa nilai produk IT sampeyan kanggo perusahaan lan pelanggan.
Yen produk utama perusahaan sing ngasilake bathi yaiku piranti lunak, sampeyan butuh DevOps. Lan ora penting banget yen sampeyan entuk dhuwit nyata nggunakake produk liyane. Iki uga kalebu toko online utawa aplikasi seluler kanthi game.
Sembarang game ana thanks kanggo pendanaan: langsung utawa ora langsung saka pemain. Ing Playgendary, kita ngembangake game seluler gratis kanthi luwih saka 200 wong sing langsung melu nggawe. Kepiye cara nggunakake DevOps?
Ya, persis kaya sing kasebut ing ndhuwur. Aku terus komunikasi karo pangembang lan penguji, lan nindakake latihan internal kanggo karyawan babagan metodologi lan alat DevOps.
Saiki kita aktif nggunakake Jenkins minangka alat pipa CI / CD kanggo nglakokake kabeh pipa perakitan kanthi Unity lan penyebaran sabanjure menyang App Store lan Play Market. Liyane saka toolkit klasik:
- Asana - kanggo manajemen proyek. Integrasi karo Jenkins wis diatur.
- Google Meet - kanggo rapat video.
- Slack - kanggo komunikasi lan macem-macem tandha, kalebu kabar saka Jenkins.
- Atlassian Confluence - kanggo dokumentasi lan kerja kelompok.
Rencana langsung kita kalebu ngenalake analisis kode statis nggunakake SonarQube lan nganakake tes UI otomatis nggunakake Selenium ing tahap Integrasi Terus-terusan.
Tinimbang kesimpulan
Aku pengin mungkasi karo pikirane ing ngisor iki: dadi insinyur DevOps sing mumpuni, penting kanggo sinau cara komunikasi langsung karo wong.
Insinyur DevOps minangka pemain tim. Lan ora liya. Inisiatif ing komunikasi karo kolega kudu teka saka dheweke, lan ora ing pangaribawa saka sawetara kahanan. Spesialis DevOps kudu ndeleng lan ngusulake solusi sing paling apik kanggo tim kasebut.
Lan ya, implementasine solusi apa wae bakal mbutuhake diskusi akeh, lan ing pungkasan bisa uga owah-owahan. Ngembangake kanthi mandiri, ngusulake lan ngleksanakake gagasane, wong sing kaya mengkono nambah nilai kanggo tim lan majikan. Sing, pungkasane, dibayangke ing jumlah remunerasi saben wulan utawa ing bentuk bonus tambahan.
Source: www.habr.com