Dumasar sawala chat
Anyar-anyar ieu, perang nyata parantos ningkat dina definisi DevOps sareng SRE.
Sanaos kanyataan yén dina sababaraha cara diskusi ngeunaan topik ieu parantos nyéépkeun huntu kuring, kalebet kuring, kuring mutuskeun pikeun nyandak pandangan kuring ngeunaan topik ieu ka pangadilan komunitas Habra. Pikeun anu minat, wilujeng sumping ka ucing. Sarta ngantep sagalana dimimitian anew!
prasajarah
Janten, di jaman kuno, tim pamekar parangkat lunak sareng pangurus server cicing nyalira. Anu kahiji suksés nyerat kodeu, anu kadua, ngagunakeun sababaraha kecap anu haneut, kaasih anu ditujukan pikeun anu kahiji, nyetél server, périodik sumping ka pamekar sareng nampi réspon komprehensif "sadayana jalan dina mesin kuring." Usaha ngantosan parangkat lunak, sadayana dianggurkeun, périodik rusak, sadayana gugup. Utamana anu mayar kanggo sadaya kekacauan ieu. Jaman lampu mulya. Nya, anjeun parantos terang ti mana asalna DevOps.
Lahirna prakték DevOps
Teras lalaki anu serius sumping sareng nyarios - ieu sanés industri, anjeun moal tiasa damel sapertos kitu. Jeung maranéhna dibawa dina model siklus kahirupan. Di dieu, contona, V-model.
Janten naon anu urang tingali? Usaha hadir sareng konsép, solusi desain arsiték, pamekar nyerat kode, teras gagal. Batur kumaha bae nguji produk, batur kumaha bae delivers ka pamaké tungtung, sarta wae di kaluaran model mujijat ieu sits customer bisnis ngalamun ngantosan cuaca jangji ku laut. Kami dugi ka kacindekan yén urang peryogi metode anu bakal ngamungkinkeun urang pikeun netepkeun prosés ieu. Sareng urang mutuskeun pikeun nyiptakeun prakték anu bakal ngalaksanakeunana.
A digression liris dina subyek naon prakték
Ku prakna hartosna kombinasi téknologi sareng disiplin. Hiji conto nyaéta prakték ngajéntrékeun infrastruktur ngagunakeun kode terraform. Disiplin nyaéta kumaha ngajelaskeun infrastruktur sareng kode, éta aya dina sirah pamekar, sareng téknologi mangrupikeun terraform sorangan.
Sareng aranjeunna mutuskeun pikeun nyauran aranjeunna prakték DevOps - Jigana aranjeunna hartosna tina Pangwangunan ka Operasi. Urang datang nepi ka sagala rupa hal pinter - prakték CI/CD, prakték dumasar kana prinsip IaC, rébuan sahijina. Sareng urang angkat, pamekar nyerat kode, insinyur DevOps ngarobih pedaran sistem dina bentuk kode kana sistem kerja (enya, kodeu, hanjakalna, ngan ukur pedaran, tapi sanés perwujudan sistem), pangiriman diteruskeun, teras salajengna. Pangurus kamari, parantos ngawasa prakték énggal, reueus dilatih deui salaku insinyur DevOps, sareng sadayana angkat ti dinya. Jeung aya sore, jeung aya isuk ... punten, teu ti dinya.
Henteu sadayana saé deui, alhamdulillah
Pas sagalana tenang, sarta sagala rupa "methodologists" licik mimiti nulis buku kandel dina prakték DevOps, sengketa quietly flared up ngeunaan saha insinyur DevOps notorious éta sarta yén DevOps mangrupakeun budaya produksi, discontent timbul deui. Ujug-ujug tétéla yén pangiriman software mangrupa tugas kacida non-trivial. Masing-masing infrastruktur pangwangunan gaduh tumpukan sorangan, dimana waé anjeun kedah ngumpul, dimana waé anjeun kedah nyebarkeun lingkungan, di dieu anjeun peryogi Tomcat, di dieu anjeun peryogi cara anu licik sareng rumit pikeun ngaluncurkeunana - sacara umum, sirah anjeun ditumbuk. Sareng masalahna, cukup aneh, tétéla utamina dina organisasi prosés - fungsi pangiriman ieu, sapertos bottleneck, mimiti ngahalangan prosés. Salaku tambahan, teu aya anu ngabolaykeun Operasi. Ieu teu katempo dina V-modél, tapi aya kénéh sakabéh siklus hirup di katuhu. Hasilna, perlu kumaha bae ngajaga infrastruktur, ngawas ngawas, ngabéréskeun kajadian, sarta ogé nungkulan pangiriman. Jelema. linggih sareng hiji suku dina pangwangunan sareng operasi - sareng ujug-ujug janten Pangembangan & Operasi. Lajeng aya hype umum pikeun microservices. Sareng sareng aranjeunna, pamekaran tina mesin lokal mimiti ngalih ka awan - cobian debug hiji hal sacara lokal, upami aya puluhan sareng ratusan microservices, teras pangiriman konstan janten cara salamet. Pikeun "perusahaan modest leutik" éta sadayana leres, tapi tetep? Kumaha upami Google?
SRE ku Google
Google sumping, tuang kaktus panggedéna sareng mutuskeun - kami henteu peryogi ieu, kami peryogi reliabilitas. Sareng reliabilitas kedah diurus. Sareng kuring mutuskeun yén urang peryogi spesialis anu bakal ngatur réliabilitas. Kuring disebut aranjeunna insinyur SR sarta ngomong, éta pikeun anjeun, lakukeun ogé sakumaha biasa. Ieu SLI, ieu SLO, ieu monitoring. Sarta anjeunna poked irung na kana operasi. Sareng anjeunna nyebat "DevOps anu dipercaya" SRE. Sadayana sigana henteu kunanaon, tapi aya hiji hack kotor anu Google tiasa mampuh - pikeun posisi insinyur SR, nyewa jalma anu pamekar anu mumpuni sareng ogé ngalaksanakeun PR sakedik sareng ngartos fungsi sistem kerja. Sumawona, Google sorangan ngagaduhan masalah sareng nyewa jalma sapertos kitu - utamina kusabab di dieu éta bersaing sareng dirina - perlu ngajelaskeun logika bisnis ka batur. Pangiriman ditugaskeun pikeun ngaleupaskeun insinyur, SR - insinyur ngatur reliabiliti (tangtu, teu langsung, tapi ku influencing infrastruktur, ngarobah arsitéktur, nyukcruk parobahan jeung indikator, kaayaan insiden). Nice, anjeun tiasa . Tapi kumaha upami anjeun sanés Google, tapi reliabilitas masih kumaha waé perhatian?
Ngembangkeun ide DevOps
Ngan harita Docker sumping, anu tumbuh tina lxc, teras sababaraha sistem orkestrasi sapertos Docker Swarm sareng Kubernetes, sareng insinyur DevOps ngambekan - ngahijikeun prakték nyederhanakeun pangiriman. Ieu disederhanakeun ka extent misalna hiji janten mungkin mun malah outsource pangiriman ka pamekar - what is deployment.yaml. Containerization ngajawab masalah. Sareng kematangan sistem CI / CD parantos aya dina tingkat nyerat hiji file sareng urang angkat - pamekar tiasa ngadamelana nyalira. Lajeng urang mimitian ngobrol ngeunaan kumaha urang bisa nyieun SRE sorangan, kalawan ... atawa sahenteuna kalawan batur.
SRE henteu aya dina Google
Muhun, ok, urang nganteurkeun pangiriman, sigana urang bisa exhale, balik ka jaman baheula alus, nalika admins diawaskeun beban processor, disetel sistem na quietly sipped hal teu kaharti tina mugs dina karapihan sarta sepi ... Eureun. Ieu teu naha urang ngamimitian sagalana (anu karunya!). Ujug-ujug tétéla yén dina pendekatan Google urang bisa kalayan gampang ngadopsi prakték alus teuing - éta lain beban prosesor anu penting, sarta teu sabaraha sering urang ngarobah disk dinya, atawa ngaoptimalkeun biaya dina awan, tapi métrik bisnis anu sarua notorious. SLx. Sareng teu aya anu ngaleungitkeun manajemén infrastruktur ti aranjeunna, sareng aranjeunna kedah ngabéréskeun kajadian, sareng janten tugas périodik, sareng umumna tetep dina prosés bisnis. Sareng guys, mimitian program sakedik-saeutik dina tingkat anu saé, Google parantos ngantosan anjeun.
Pikeun nyimpulkeun. Ujug-ujug, tapi anjeun parantos bosen maca sareng anjeun henteu tiasa ngantosan nyiduh sareng nyerat ka panulis dina koméntar dina tulisan. DevOps salaku prakték pangiriman sok aya sareng bakal. Sareng éta henteu kamana waé. SRE salaku sakumpulan prakték operasional ngajantenkeun pangiriman ieu suksés.
sumber: www.habr.com