Adhedhasar diskusi chatting
Bubar, perang nyata wis suda babagan definisi DevOps lan SRE.
Senadyan kasunyatan manawa diskusi babagan topik iki wis akeh banget, kalebu aku, aku mutusake kanggo nggawa pandanganku babagan topik iki menyang pengadilan komunitas Habra. Kanggo sing minat, welcome to cat. Lan supaya kabeh diwiwiti maneh!
prasejarah
Dadi, ing jaman kuna, tim pangembang piranti lunak lan administrator server urip kanthi kapisah. Sing pertama kasil nulis kode kasebut, sing nomer loro, nggunakake macem-macem tembung sing anget lan tresna marang sing pertama, nyiyapake server, kanthi periodik teka menyang pangembang lan nampa respon lengkap "kabeh bisa digunakake ing mesinku." Bisnis ngenteni piranti lunak, kabeh ora aktif, rusak sacara periodik, kabeh wong gugup. Utamane sing mbayar kabeh kekacoan iki. Jaman lampu mulya. Ya, sampeyan wis ngerti asale saka DevOps.
Lair saka praktik DevOps
Banjur wong lanang serius teka lan ujar - iki dudu industri, sampeyan ora bisa kerja kaya ngono. Lan padha nggawa model siklus urip. Kene, contone, V-model.
Dadi apa sing kita deleng? Bisnis dilengkapi konsep, solusi desain arsitek, pangembang nulis kode, lan banjur gagal. Ana wong sing nyoba produk kasebut, ana sing ngirimake menyang pangguna pungkasan, lan ing endi wae ing output model ajaib iki ana pelanggan bisnis sing sepi nunggu cuaca sing dijanjekake ing segara. Kita teka ing kesimpulan yen kita butuh cara sing bakal ngidini kita netepake proses iki. Lan kita mutusake kanggo nggawe praktik sing bakal ditindakake.
A digression lyrical ing subyek apa laku
Miturut laku tegese kombinasi teknologi lan disiplin. Tuladhane yaiku praktik njlentrehake prasarana nggunakake kode terraform. Disiplin yaiku carane njlèntrèhaké infrastruktur kanthi kode, ana ing sirah pangembang, lan teknologi minangka terraform dhewe.
Lan dheweke mutusake kanggo nyebat praktik DevOps - Aku rumangsa tegese saka Pembangunan nganti Operasi. Kita teka kanthi macem-macem perkara sing pinter - praktik CI / CD, praktik adhedhasar prinsip IaC, ewonan. Lan kita lunga, pangembang nulis kode, insinyur DevOps ngowahi deskripsi sistem ing bentuk kode dadi sistem kerja (ya, kode kasebut, sayangé, mung deskripsi, nanging dudu perwujudan sistem), pangiriman terus, lan liya-liyane. Administrator wingi, sing wis nguwasani praktik anyar, kanthi bangga dilatih maneh minangka insinyur DevOps, lan kabeh wis ana. Lan ana sore, lan ana esuk ... nuwun, ora saka ing kono.
Ora kabeh apik maneh, alhamdulillah
Sanalika kabeh dadi tenang, lan macem-macem "metodologi" sing licik wiwit nulis buku tebal babagan praktik DevOps, perselisihan kanthi tenang babagan sapa insinyur DevOps sing kondhang lan yen DevOps minangka budaya produksi, rasa ora puas muncul maneh. Dumadakan ternyata pangiriman piranti lunak minangka tugas sing ora pati penting. Saben prasarana pangembangan duwe tumpukan dhewe, ing endi wae sampeyan kudu ngumpulake, ing endi wae sampeyan kudu nyebarake lingkungan, ing kene sampeyan butuh Tomcat, ing kene sampeyan butuh cara sing licik lan rumit kanggo miwiti - umume, sirah sampeyan ketukan. Lan masalah, cukup aneh, dadi utamane ing organisasi proses - fungsi pangiriman iki, kaya bottleneck, wiwit mblokir proses. Kajaba iku, ora ana sing mbatalake Operasi. Ora katon ing model V, nanging isih ana kabeh siklus urip ing sisih tengen. Akibaté, perlu kanggo njaga infrastruktur, ngawasi ngawasi, ngrampungake kedadeyan, lan uga ngatasi pangiriman. Sing. njagong kanthi sikil siji ing pembangunan lan operasi - lan dumadakan dadi Development & Operations. Lan banjur ana hype umum kanggo microservices. Lan karo wong-wong mau, pangembangan saka mesin lokal wiwit pindhah menyang maya - nyoba kanggo debug soko lokal, yen ana Welasan lan atusan microservices, banjur pangiriman pancet dadi sarana kaslametané. Kanggo "perusahaan cilik andhap asor" iku kabeh tengen, nanging isih? Kepiye babagan Google?
SRE dening Google
Google teka, mangan kaktus paling gedhe lan mutusake - kita ora butuh iki, kita butuh linuwih. Lan linuwih kudu dikelola. Lan aku mutusake yen kita butuh spesialis sing bakal ngatur linuwih. Aku disebut engineers SR lan ngandika, iku kanggo sampeyan, nindakaken uga minangka biasanipun. Punika SLI, punika SLO, punika ngawasi. Lan dheweke ngobati irung kanggo operasi. Lan dheweke diarani "DevOps sing bisa dipercaya" SRE. Kabeh katon apik, nanging ana hack kotor sing bisa ditindakake Google - kanggo posisi insinyur SR, nyewa wong sing dadi pangembang sing mumpuni lan uga nindakake pakaryan cilik lan ngerti fungsi sistem kerja. Kajaba iku, Google dhewe duwe masalah karo nyewa wong - utamane amarga ing kene saingan karo awake dhewe - perlu kanggo njlèntrèhaké logika bisnis marang wong liya. Pangiriman ditugasake kanggo ngeculake insinyur, SR - insinyur ngatur linuwih (mesthi, ora langsung, nanging kanthi mengaruhi infrastruktur, ngganti arsitektur, nelusuri owah-owahan lan indikator, ngatasi kedadeyan). Nice, sampeyan bisa . Nanging kepiye yen sampeyan dudu Google, nanging linuwih isih dadi prihatin?
Pangembangan ide DevOps
Nalika iku Docker teka, sing tuwuh saka lxc, lan banjur macem-macem sistem orkestrasi kayata Docker Swarm lan Kubernetes, lan insinyur DevOps exhaled - penyatuan praktik nyederhanakake pangiriman. Nyederhanakake nganti bisa nganti bisa ngirim outsource menyang pangembang - what is deployment.yaml. Containerization ngrampungake masalah kasebut. Lan kadewasan sistem CI / CD wis ana ing tingkat nulis siji file lan mateni - pangembang bisa ngatasi dhewe. Banjur kita miwiti ngomong babagan carane kita bisa nggawe SRE dhewe, karo ... utawa paling ora karo wong.
SRE ora ana ing Google
Inggih, ok, kita ngirim kiriman, misale jek kita bisa exhale, bali menyang dina lawas apik, nalika admins mirsani mbukak prosesor, nyetel sistem lan quietly sipped soko ora dingerteni saka cangkir ing tentrem lan sepi ... Stop. Iki ora kok kita miwiti kabeh (sing tega!). Dumadakan ternyata ing pendekatan Google kita bisa kanthi gampang ngetrapake praktik sing apik banget - dudu beban prosesor sing penting, lan ora sepira kerepe kita ngganti disk ing kana, utawa ngoptimalake biaya ing awan, nanging metrik bisnis padha kondhang. SLx. Lan ora ana siji wis dibusak Manajemen infrastruktur saka wong-wong mau, lan padha kudu mutusake masalah kedadosan, lan ing tugas periodik, lan umume tetep ing ndhuwur proses bisnis. Lan wong lanang, miwiti program sithik-sithik ing tingkat sing apik, Google wis ngenteni sampeyan.
Kanggo ngringkes. Dumadakan, nanging sampeyan wis kesel maca lan sampeyan ora bisa ngenteni kanggo ngidoni lan nulis menyang penulis ing komentar ing artikel kasebut. DevOps minangka praktik pangiriman wis mesthi lan bakal. Lan ora menyang ngendi wae. SRE minangka sakumpulan praktik operasional ndadekake pangiriman iki sukses banget.
Source: www.habr.com