Bubar iki, iklan kaya ngono wis mbanjiri Internet. Senadyan gaji penake, siji ora bisa bantuan nanging dadi isin sing sesat alam bébas ditulis nang. Kaping pisanan dianggep yen "DevOps" lan "insinyur" piye wae bisa digabung dadi siji tembung, banjur ana dhaptar syarat acak, sawetara sing disalin kanthi jelas saka lowongan sysadmin.
Ing kirim iki, aku pengin ngomong sethithik babagan carane kita tekan titik urip iki, apa sejatine DevOps lan apa sing kudu ditindakake saiki.
Lowongan kasebut bisa disalahake ing kabeh cara, nanging kasunyatane tetep: ana akeh, lan iki minangka cara pasar saiki. Kita nganakake konferensi devops lan kanthi terang-terangan nyatakake: " - ora kanggo insinyur DevOps." Iki bakal koyone aneh lan alam bébas kanggo akeh: kok wong sing nindakake acara rampung komersial nglawan pasar. Saiki kita bakal nerangake kabeh.
Babagan budaya lan proses
Ayo diwiwiti kanthi kasunyatan manawa DevOps dudu disiplin teknik. Iku kabeh diwiwiti kanthi kasunyatan manawa divisi peran sing diadegake sacara historis ora bisa digunakake kanggo kualitas produk. Nalika programer mung program, nanging ora pengin krungu apa-apa bab testing, piranti lunak wis littered karo kewan omo. Nalika admin ora peduli carane utawa ngapa piranti lunak kasebut ditulis, dhukungan dadi neraka.
Contone, njlèntrèhaké prabédan antarane administrator sistem lan pendekatan SRE kanggo manajemen layanan . pasinaon menarik wis digawa metu ing - jelas manawa pangembang sing paling apik bisa ngatur pangowahan anyar kanggo produksi luwih cepet saka sapisan saben jam. Dheweke nyoba nganggo tangan ora luwih saka 10% (iki bisa dideleng saka ). Kepiye carane nindakake iki? "Excel or die" ujare salah sawijining judhul laporan. Kanggo dhiskusi rinci babagan statistik kasebut ing konteks tes, sampeyan bisa ngrujuk menyang intine Baruch Sadogursky ing konferensi kita liyane, Heisenbug.
"Yen ora ana kesepakatan ing antarane kanca,
Urusane ora bakal lancar,
Lan ora ana sing bakal metu, mung glepung.
Ing jaman biyen ana Angsa, Crayfish lan Pike ... "
Apa bagean saka programer web sing sampeyan pikir ngerti banget babagan kondisi aplikasi sing digunakake ing produksi? Pira wong-wong mau bakal pindhah menyang admin lan nyoba kanggo mangerteni apa sing bakal kelakon yen database tubrukan? Lan sapa sing bakal teka menyang penguji lan njaluk supaya bisa mulang carane nulis tes kanthi bener? Lan ana uga penjaga keamanan, manajer produk, lan akeh wong liya.
Ide sakabèhé saka DevOps yaiku nggawe kolaborasi antarane peran lan departemen. Kaping pisanan, iki ora digayuh dening sawetara piranti lunak sing dikonfigurasi kanthi cerdas, nanging kanthi praktik komunikasi. DevOps babagan budaya, praktik, metodologi lan proses. Ora ana spesialisasi teknik sing bisa mangsuli pitakon kasebut.
Lingkaran ganas
Saka ngendi asale disiplin "devops engineering"? Kita duwe versi! Ide DevOps apik-apik banget nganti dadi korban suksese dhewe. Sawetara perekrut teduh lan perdagangan manungsa, sing duwe atmosfer dhewe, wiwit ngubengi topik iki.
Bayangake: wingi sampeyan nggawe shawarma ing Khimki, lan dina iki sampeyan wis dadi wong gedhe, rekrut senior. Ana proses nggoleki lan milih calon, kabeh ora gampang, sampeyan kudu ngerti. Ayo dadi kepala departemen ngandika: golek spesialis ing X. We nemtokake tembung "engineer" kanggo X, lan kita wis rampung. Butuh Linux? Ya, iki mesthi insinyur Linux, yen sampeyan pengin DevOps, banjur insinyur DevOps. Kekosongan kasebut ora mung kalebu judhul, nanging uga sawetara teks sing kudu dilebokake ing njero. Cara paling gampang yaiku ngetik set tembung kunci saka Google, gumantung saka imajinasi sampeyan. DevOps kasusun saka rong tembung - "Dev" lan "Ops", tegese kita kudu nggabungake tembung kunci sing ana gandhengane karo pangembang lan pangurus, kabeh dadi tumpukan. Iki carane lowongan katon babagan keahlian ing 42 basa pamrograman lan 20 taun nggunakake Kubernetes lan Swarm bebarengan. Diagram kerja.
Iki minangka gambar sing ora ana gunane lan tanpa ampun saka pahlawan super "devops" tartamtu sing wis ana ing pikirane wong, sing bakal ngatur kabeh wong kanggo nyebar menyang Jenkins, lan rasa seneng bakal teka. Oh, yen kabeh iku prasaja. "Lan iki uga carane sampeyan bisa mburu administrator sistem," mikir HR, "iku tembung sing modis, tembung kunci sing padha, kudu njupuk umpan."
Panjaluk nggawe pasokan, lan kabeh kekosongan sampah iki wis diisi karo administrator sistem sing ora ngerti: sampeyan bisa nindakake kabeh kaya sadurunge, nanging entuk kaping pirang-pirang kanthi nelpon dhewe "devops". Kaya nalika sampeyan ngatur server liwat SSH kanthi manual siji-sijine, sampeyan bakal terus ngatur, nanging saiki iki mesthine minangka praktik devops. Iki minangka fenomena kompleks, sebagian ana gandhengane karo underestimasi admin klasik lan hype ing sekitar DevOps, nanging umume, kedadeyan kasebut kedadeyan.
Dadi kita duwe pasokan lan dikarepake. A bunder ganas sing feed dhewe. Iki sing kita geluti (kalebu nggawe konferensi DevOops).
Mesthine, saliyane administrator sistem sing wis ganti jeneng dadi "devops," ana peserta liyane - contone, SRE profesional utawa pangembang Infrastruktur-as-Code.
Apa sing ditindakake wong ing DevOps (tenan)
Dadi, sampeyan pengin maju sinau lan ngetrapake praktik DevOps. Nanging carane nindakake iki, ing arah sing katon? Temenan, sampeyan ora kudu ngandelake tembung kunci sing populer.
Yen ana pegaweyan, wong kudu nindakake. Kita wis ngerti manawa iki dudu "insinyur devops", banjur sapa? Iku misale jek luwih bener kanggo ngrumusake iki ora ing syarat-syarat posisi, nanging ing wilayah tartamtu saka karya.
Pisanan, sampeyan bisa ngatasi jantung DevOps-proses lan budaya. Budaya minangka bisnis sing alon lan angel, lan sanajan biasane tanggung jawab manajer, kabeh wong melu kanthi cara siji utawa liyane, saka programer nganti administrator. Sawetara sasi kepungkur Tim Lister :
"Budaya ditemtokake dening nilai-nilai inti organisasi. Biasane wong ora sok dong mirsani iki, nanging wis makarya ing consulting kanggo akèh taun, kita wis digunakake kanggo sok dong mirsani iku. Sampeyan mlebu perusahaan lan secara harfiah sajrone sawetara menit sampeyan mulai ngrasakake apa sing kedadeyan. Kita nyebut iki "rasa". Kadhangkala gondho iki apik banget. Kadhangkala nyebabake mual. (...) Sampeyan ora bisa ngganti budaya nganti nilai lan kapercayan ing mburi tumindak tartamtu dimangerteni. Tingkah laku iku gampang diamati, nanging nggoleki kapercayan iku angel. DevOps mung minangka conto sing apik babagan kedadeyane dadi luwih rumit.
Ana uga bagean teknis saka masalah kasebut, mesthi. Yen kode anyar bakal dites ing sasi, nanging dirilis mung setahun mengko, lan iku fisik mokal kanggo nyepetake kabeh munggah, sampeyan bisa uga ora manggon nganti laku apik. Praktek apik didhukung dening piranti sing apik. Contone, kanthi gagasan Infrastruktur-as-Code, sampeyan bisa nggunakake apa wae saka AWS CloudFormation lan Terraform kanggo Chef-Ansible-Puppet. Sampeyan kudu ngerti lan bisa nindakake kabeh iki, lan iki wis cukup disiplin engineering. Penting supaya ora mbingungake sabab kanthi efek: pisanan sampeyan kerja miturut prinsip SRE lan mung banjur ngetrapake prinsip kasebut ing sawetara solusi teknis tartamtu. Ing wektu sing padha, SRE minangka metodologi sing komprehensif sing ora ngandhani carane nyiyapake Jenkins, nanging babagan limang prinsip dhasar:
- Komunikasi apik antarane peran lan departemen
- Nampa kesalahan minangka bagean integral saka proyek
- Nggawe owah-owahan kanthi bertahap
- Nggunakake perkakas lan otomatisasi liyane
- Ngukur kabeh sing bisa diukur
Iki ora mung sawetara set statements, nanging tartamtu . Contone, ing dalan kanggo nrima kesalahan, sampeyan kudu ngerti risiko, ngukur kasedhiyan lan ora kasedhiya layanan nggunakake kaya SLI () lan SLO (), sinau nulis postmortem lan nggawe nulis ora medeni.
Ing disiplin SRE, panggunaan alat mung minangka bagean saka sukses, sanajan sing penting. Kita kudu terus berkembang kanthi teknis, ndeleng apa sing kedadeyan ing jagad iki lan kepiye bisa ditrapake ing karya kita.
Sabanjure, solusi Cloud Native saiki wis populer banget. Kaya sing ditetepake dening Cloud Native Computing Foundation saiki, teknologi Cloud Native ngidini organisasi ngembangake lan mbukak aplikasi sing bisa diukur ing lingkungan dinamis saiki, kayata awan umum, pribadi, lan hibrida. Conto kalebu wadhah, jejaring layanan, layanan mikro, infrastruktur sing ora bisa diganti, lan API deklaratif. Kabeh teknik kasebut ngidini sistem sing digandhengake kanthi longgar supaya tetep elastis, bisa diatur, lan bisa diamati. Otomatisasi sing apik ngidini para insinyur nggawe owah-owahan gedhe kanthi asring lan kanthi asil sing bisa diprediksi tanpa nggawe tugas. Kabeh iki didhukung dening tumpukan alat sing kondhang kayata Docker lan Kubernetes.
Dhéfinisi sing rada rumit lan jembar iki amarga wilayah kasebut uga cukup rumit. Ing tangan siji, dikandhakake manawa owah-owahan anyar ing sistem iki kudu ditambahake kanthi gampang. Ing sisih liya, kanggo ngerteni carane nggawe lingkungan wadah sing ana layanan sing digandhengake kanthi bebas ing infrastruktur sing ditetepake piranti lunak lan dikirim ing kana nggunakake CI / CD sing terus-terusan, lan mbangun praktik DevOps ing kabeh iki - kabeh iki mbutuhake luwih akeh. saka siji mangan asu.
Apa apa karo kabeh iki
Saben uwong ngatasi masalah kasebut kanthi cara dhewe: contone, sampeyan bisa nerbitake lowongan normal kanggo ngilangi lingkaran ganas. Sampeyan bisa ngerteni apa tegese tembung kaya DevOps lan Cloud Native lan gunakake kanthi bener lan langsung. Sampeyan bisa berkembang ing DevOps lan nduduhake pendekatan sing bener kanthi conto sampeyan.
Kita lagi nindakake konferensi , sing menehi kesempatan kanggo nyelidiki luwih jero babagan perkara sing lagi wae kita rembugan. Ana sawetara klompok laporan kanggo iki:
- Proses lan budaya;
- Site Reliability Engineering;
- Cloud Native;
Carane milih arep menyang ngendi? Ana titik subtle kene. Ing tangan siji, DevOps babagan interaksi, lan kita pengin sampeyan rawuh ing presentasi saka macem-macem blok. Ing sisih liya, yen sampeyan minangka manajer pangembangan sing teka ing konferensi kasebut kanggo konsentrasi ing siji tugas tartamtu, mula ora ana sing mbatesi sampeyan - jelas, iki bakal dadi blok babagan proses lan budaya. Aja lali yen sampeyan bakal duwe rekaman sawise konferensi (sawise ngisi formulir umpan balik), supaya sampeyan bisa nonton presentasi sing kurang penting mengko.
Temenan, ing konferensi dhewe ora bisa pindhah ing telung trek bebarengan, supaya kita ngatur program ing kuwi cara sing saben slot wektu wis topik kanggo saben rasa.
Sing isih ana yaiku ngerti apa sing kudu ditindakake yen sampeyan dadi insinyur DevOps! Pisanan, coba nemtokake apa sing sampeyan lakoni. Biasane dheweke seneng nyebut tembung iki:
- Pangembang sing nggarap infrastruktur. Klompok laporan babagan SRE lan Cloud Native paling cocok kanggo sampeyan.
- Administrator sistem. Luwih rumit ing kene. DevOops ora babagan administrasi sistem. Untunge, ana akeh konferensi, buku, artikel, video ing Internet, lan sapiturute sing apik banget babagan topik administrasi sistem. Ing sisih liya, yen sampeyan kepengin ngembangake dhewe babagan pemahaman budaya lan proses, sinau babagan teknologi awan lan rincian urip karo Cloud Native, mula kita bakal seneng ndeleng sampeyan! Coba pikirake: sampeyan lagi nindakake administrasi, banjur apa sing bakal sampeyan lakoni? Supaya ora tiba-tiba nemokake dhewe ing kahanan sing ora nyenengake, sampeyan kudu sinau saiki.
Ana pilihan liyane: sampeyan tetep lan terus ngaku yen sampeyan khusus insinyur DevOps lan ora liya, apa tegese. Banjur kita kudu nguciwani sampeyan, DevOops dudu konferensi kanggo insinyur DevOps!
Geser saka ing Munich
DevOops 2020 Moscow bakal dianakake tanggal 29-30 April ing Moskow, tiket wis kasedhiya .
Utawa, sampeyan bisa nganti 8 Februari. Elinga yen nalika ngisi formulir, sampeyan kudu milih target pamirsa sing bakal entuk manfaat paling akeh saka laporan sampeyan (ana kejutan sing dikubur ing dhaptar).
Source: www.habr.com