Naon DevOps

Definisi DevOps rumit pisan, janten urang kedah ngamimitian diskusi ngeunaan éta deui unggal waktos. Aya sarébu publikasi ngeunaan topik ieu dina Habré nyalira. Tapi upami anjeun maca ieu, anjeun panginten terang naon DevOps. Kusabab kuring henteu. Halo Nami abdi Alexander Titov (@osminog), sarta kami ngan bakal ngobrol ngeunaan DevOps sarta kuring bakal babagi pangalaman abdi.

Kuring geus lila mikir ngeunaan kumaha carana sangkan carita kuring mangpaat, jadi bakal aya loba patarosan di dieu - nu kuring nanya ka sorangan jeung nu kuring nanya ka klien parusahaan urang. Ku ngawalon patarosan ieu, pamahaman jadi hadé. Kuring bakal nyarioskeun ka anjeun naha DevOps diperyogikeun tina sudut pandang kuring, naon éta, deui, tina sudut pandang kuring, sareng kumaha ngartos yén anjeun nuju ka DevOps deui tina sudut pandang kuring. Poin pamungkas bakal ngaliwatan patarosan. Ku ngawalon aranjeunna pikeun diri anjeun, anjeun tiasa ngartos naha perusahaan anjeun nuju ka DevOps atanapi naha aya masalah dina sababaraha cara.

Dina hiji waktos kuring naek gelombang merger sareng akuisisi. Kahiji, kuring digawé pikeun ngamimitian leutik disebut Qik, lajeng eta dibeuli ku parusahaan rada gedé disebut Skype, nu ieu lajeng dibeuli ku parusahaan rada gedé disebut Microsoft. Dina waktos éta, kuring mimiti ningali kumaha ideu DevOps dirobih dina perusahaan ukuran anu béda. Sanggeus éta, kuring jadi kabetot dina nempo DevOps ti sudut pandang pasar, sarta kolega kuring jeung kuring ngadegkeun parusahaan Express 42. Pikeun 6 taun ayeuna urang geus pindah sapanjang gelombang pasar.

Diantara hal séjén, kuring salah sahiji panitia komunitas DevOps Moscow sareng panitia DevOps-Days 2017, tapi kuring henteu ngatur 2018. Express 42 gawéna kalayan loba pausahaan. Urang tumuwuh DevOps di dinya, lalajo kumaha kajadian, nyieun kacindekan, nganalisa, ngabejaan dulur urang conclusions, sarta ngalatih jalma dina prakték DevOps. Sacara umum, kami ngalakukeun anu pangsaéna pikeun ningkatkeun pangalaman sareng kaahlian dina hal ieu.

Naha DevOps

Patarosan kahiji anu haunts dulur tur salawasna nyaeta - naha? Seueur jalma nganggap yén DevOps ngan ukur otomatisasi atanapi hal anu sami anu parantos dipiboga ku unggal perusahaan.

- Kami ngagaduhan Integrasi Kontinyu - ieu hartosna urang parantos ngagaduhan DevOps, sareng naha sadaya barang ieu diperyogikeun? Maranéhna keur senang-senang di luar nagri, tapi maranéhna ngahalangan urang gawé!

Leuwih 9 taun ngembangkeun masarakat jeung metodologi, éta geus jadi jelas yén ieu masih teu glitter pamasaran, tapi masih teu sagemblengna jelas naha diperlukeun. Sapertos alat sareng prosés naon waé, DevOps ngagaduhan tujuan khusus anu tungtungna ngahontal.

Sadaya ieu disababkeun ku kanyataan yén dunya robih. Anjeunna ngalir jauh ti pendekatan perusahaan, lamun pausahaan pindah lempeng ka arah impian, sakumaha urang St Petersburg klasik nyanyi, ti titik A ka titik B nurutkeun strategi nu tangtu, kalawan struktur tangtu diwangun pikeun ieu.

Sacara prinsip, sagalana dina IT kudu diwangun nurutkeun pendekatan ieu. Di dieu IT dianggo sacara éksklusif pikeun ngajadikeun otomatis prosés.

Automasi henteu sering robih, sabab nalika perusahaan turun dina jalan anu saé, naon anu kedah dirobih? Gawéna - ulah noél. Ayeuna pendekatan di dunya robih, sareng anu disebut Agile nunjukkeun yén titik tungtung B henteu langsung katingali.

Nalika perusahaan ngaliwat pasar, damel sareng klien, éta terus-terusan ngajelajah pasar sareng ngarobih titik akhir B. Sumawona, langkung sering perusahaan ngarobih arahna, langkung suksés dina tungtungna, sabab milih langkung seueur pasar. niches.

Strategi ieu nunjukkeun ku perusahaan anu pikaresepeun anu nembe kuring diajar. One Box Shave mangrupikeun jasa pangiriman langganan pikeun agul sareng asesoris cukur dina kotak. Aranjeunna terang kumaha carana ngaropea "kotak" maranéhna pikeun klien béda. Hal ieu dilakukeun ku parangkat lunak anu tangtu, anu teras ngirim pesenan ka pabrik Korea anu ngahasilkeun produk.

Produk ieu dibeuli ku Unilever pikeun $1 milyar. Ayeuna saingan sareng Gillette sareng parantos nyandak pangsa anu signifikan tina konsumen di pasar Amérika. Hiji Box Shave nyebutkeun:

- 4 bilah? Anjeun serius? Naha anjeun peryogi ieu - éta henteu ningkatkeun kualitas cukur. Krim anu dipilih khusus, seungit sareng agul kualitas luhur sareng dua bilah ngarengsekeun langkung seueur masalah tibatan anu bodo 4 bilah Gillette! Naha urang bakal dugi ka 10 pas?

Ieu kumaha dunya robah. Unilever ngaku yén aranjeunna gaduh sistem IT anu saé anu ngamungkinkeun anjeun ngalakukeun ieu. Tungtungna sigana konsép Waktos-ka-pasar, nu teu saurang ogé geus diajak ngobrol ngeunaan.

Titik Time-to-market henteu sabaraha sering urang nyebarkeun. Anjeun mindeng bisa nyebarkeun, tapi siklus release bakal panjang. Lamun siklus release tilu-bulan anu superimposed on silih, shifting aranjeunna ku saminggu, tétéla yén pausahaan sigana deploying saminggu sakali. Sareng ti ideu dugi ka palaksanaan akhir peryogi 3 bulan.

Waktos-ka-pasar nyaéta ngeunaan ngaminimalkeun waktos ti ide ka palaksanaan ahir.

Dina hal ieu, parangkat lunak berinteraksi sareng pasar. Ieu kumaha situs web One Box Shave berinteraksi sareng klien. Aranjeunna teu gaduh salespeople - ngan hiji ramatloka dimana datang klik sarta ninggalkeun kahayang. Sasuai, hal anyar kudu terus dipasang dina loka jeung diropéa luyu jeung kahayang. Salaku conto, di Koréa Kidul aranjeunna nyukur béda ti di Rusia, sareng aranjeunna resep aroma sanés pinus, tapi, contona, wortel sareng vanili.

Kusabab perlu gancang ngarobah eusi situs, ngembangkeun software robah greatly. Ngaliwatan software urang kudu manggihan naon klien hayang. Saméméhna, urang diajar ieu ngaliwatan sababaraha cara roundabout, contona, ngaliwatan manajemen bisnis. Teras we ngararancang éta, nempatkeun sarat kana sistem IT, sareng sadayana saé. Ayeuna béda - parangkat lunak dirancang ku sadayana anu kalibet dina prosésna, kalebet insinyur, sabab ngaliwatan spésifikasi téknis aranjeunna diajar kumaha jalanna pasar sareng ogé ngabagi wawasan sareng bisnis.

Salaku conto, di Qik, urang ujug-ujug diajar yén jalma-jalma resep pisan unggah daptar kontak ka server, sareng aranjeunna masihan kami aplikasi. Awalna urang teu mikir ngeunaan eta. Dina perusahaan klasik, sadayana bakal mutuskeun yén ieu mangrupikeun bug, sabab spésifikasina henteu nyarios yén éta kedah dianggo saé sareng umumna dilaksanakeun dina tuur, aranjeunna bakal mareuman fitur sareng nyarios: "Teu aya anu peryogi ieu, Hal pangpentingna nyaéta yén fungsi utama jalan. " . Sareng perusahaan téknologi ningali ieu salaku kasempetan sareng mimiti ngarobih parangkat lunak saluyu sareng ieu.

Taun 1968, saurang lalaki visioner, Melvin Conway, ngarumuskeun ideu ieu.

Organisasi anu nyiptakeun sistem dibatesan ku desain anu ngayakeun réplikasi struktur komunikasi organisasi éta.

Dina leuwih jéntré, pikeun ngahasilkeun sistem tina tipe béda, anjeun ogé kudu boga struktur komunikasi dina hiji pausahaan tina tipe béda. Upami struktur komunikasi anjeun top-hirarkis, maka ieu moal ngijinkeun anjeun nyiptakeun sistem anu tiasa nyayogikeun indikator Time-to-Market anu luhur pisan.

Maca ngeunaan hukum Conway urang bisa via Tumbu. Penting pikeun ngartos budaya atanapi filosofi DevOps sabab Hiji-hijina hal anu dasarna robih dina DevOps nyaéta struktur komunikasi antara tim.

Tina sudut pandang prosés, sateuacan DevOps, sadaya tahapan: analytics, pamekaran, uji coba, operasi, linier.
Dina kasus DevOps, sadaya prosés ieu lumangsung sakaligus.

Waktu-ka-pasar mangrupikeun hiji-hijina jalan anu tiasa dilakukeun. Pikeun jalma anu digawé dina prosés heubeul, ieu Sigana rada kosmis, sarta umumna kitu-kitu.

Janten naha anjeun peryogi DevOps?

Pikeun ngembangkeun produk digital. Upami perusahaan anjeun henteu ngagaduhan produk digital, DevOps henteu diperyogikeun - éta penting pisan.

DevOps nungkulan watesan laju produksi software sequential. Dina éta sakabéh prosés lumangsung sakaligus.

Kasusah nambahan. Nalika para evangelists DevOps nyarioskeun yén éta bakal ngagampangkeun anjeun ngaleupaskeun parangkat lunak, ieu mangrupikeun omong kosong.

Kalayan DevOps, hal-hal bakal langkung rumit.

Dina konperénsi di stand Avito, anjeun tiasa ningali kumaha éta nyebarkeun wadah Docker - tugas anu teu réalistis. Pajeulitna janten ngalarang; anjeun kedah juggle seueur bal dina waktos anu sami.

DevOps lengkep ngarobih prosés sareng organisasi di perusahaan - langkung tepatna, sanés DevOps anu robih, tapi produk digital. Pikeun datang ka DevOps, anjeun masih kedah robih lengkep prosés ieu.

Patarosan pikeun spesialis

Naon anu anjeun gaduh? Patarosan anu anjeun tiasa naroskeun ka diri nalika damel di perusahaan sareng ngembangkeun salaku spesialis.

Naha anjeun gaduh strategi pikeun nyiptakeun produk digital? Upami aya, éta parantos saé. Ieu hartosna perusahaan anjeun nuju nuju DevOps.

Naha perusahaan anjeun parantos nyiptakeun produk digital? Ieu ngandung harti yén anjeun tiasa naék tingkat anu langkung luhur sareng ngalakukeun hal-hal anu langkung narik - deui tina sudut pandang DevOps. Abdi ngan ukur nyarios tina sudut pandang ieu.

Naha perusahaan anjeun salah sahiji pamimpin pasar dina niche produk digital? Spotify, Yandex, Uber mangrupikeun perusahaan anu aya dina puncak kamajuan téknologi ayeuna.

Naroskeun ka diri anjeun patarosan ieu, sareng upami sadaya jawaban henteu, maka panginten anjeun henteu kedah ngalakukeun DevOps di perusahaan ieu. Upami topik DevOps leres-leres pikaresepeun pikeun anjeun, panginten ... anjeun kedah ngalih ka perusahaan sanés? Upami perusahaan anjeun badé lebet kana DevOps, tapi anjeun ngajawab "Henteu" kana sadaya patarosan, maka éta sapertos badak anu éndah anu moal pernah robih.

organisasi

Sakumaha ceuk kuring, nurutkeun Hukum Conway, organisasi perusahaan robih. Kuring bakal mimitian ku naon anu nyegah DevOps nembus jero perusahaan tina sudut pandang organisasi.

Masalah "sumur"

Kecap Inggris "Silo" ditarjamahkeun di dieu kana Rusia salaku "sumur". Intina masalah ieu nya éta euweuh bursa informasi antara tim. Tiap tim ngagali jero kana kaahlianna, tanpa ngawangun peta umum pikeun nganapigasi.

Dina sababaraha hal, ieu reminds kuring ngeunaan hiji jalma anu kakara anjog di Moskow jeung teu acan terang kumaha carana napigasi peta metro. Moskow biasana terang pisan kana daérahna, sareng sapanjang Moskow aranjeunna tiasa napigasi nganggo peta metro. Lamun anjeun datang ka Moskwa pikeun kahiji kalina, anjeun teu boga skill ieu, jeung anjeun ngan disoriented.

DevOps nyarankeun ngaliwat momen disorientasi ieu sareng sadaya departemén damel babarengan pikeun ngawangun peta interaksi umum.

Dua faktor ngahalangan ieu.

Konsékuansi tina sistem manajemen perusahaan. Éta diwangun dina "sumur" hirarki anu misah. Contona, aya KPI tangtu di pausahaan nu ngarojong sistem ieu. Di sisi anu sanés, otak jalma anu sesah ngalangkungan wates kaahlianana sareng napigasi sadayana sistem ngahalangan. Ngan teu genah. Bayangkeun yén anjeun aya di bandara Bangkok - anjeun moal mendakan jalan gancang. DevOps ogé sesah napigasi, sareng éta sababna jalma nyarios anjeun kedah milarian pituduh pikeun ka dinya.

Tapi anu paling penting nyaéta masalah "sumur" pikeun insinyur anu diimbuhan ku sumanget DevOps, parantos maca Fowler sareng sakumpulan buku sanés, dinyatakeun dina kanyataan yén "sumur" teu ngidinan Anjeun pikeun ngalakukeun hal "jelas".. Urang sering ngumpul saatos DevOps Moscow, saling ngobrol, sareng jalma-jalma ngawadul:

- Kami ngan ukur hoyong ngaluncurkeun CI, tapi tétéla yén manajemén henteu peryogi éta.

Ieu kajadian persis sabab CI и Prosés Pangiriman kontinyu aya dina wates loba ujian. Kantun tanpa ngatasi masalah "sumur" dina tingkat organisasi, anjeun moal tiasa maju, henteu paduli naon anu anjeun laksanakeun sareng kumaha sedihna.

Masing-masing pamilon dina prosés di perusahaan: pamekar backend sareng frontend, nguji, DBA, operasi, jaringan, ngali arah sorangan, sareng teu aya anu gaduh peta umum kecuali manajer, anu kumaha waé ngawas aranjeunna sareng ngatur aranjeunna nganggo "dibagi. jeung nalukkeun" métode.

Jalma-jalma berjuang pikeun sababaraha béntang atanapi bandéra, sadayana ngali kaahlianana.

Hasilna, nalika tugas timbul pikeun nyambungkeun sadayana ieu babarengan jeung ngawangun pipa umum, sarta teu aya deui nu peryogi tarung pikeun béntang jeung bandéra, timbul patarosan - naon nu kudu atoh? Urang kudu datang ka hiji perjangjian kumaha bae, tapi teu saurang ogé ngajarkeun urang kumaha ngalakukeun ieu di sakola. Urang diajar ti sakola: kelas dalapan - wow! - dibandingkeun jeung kelas tujuh! Ieu sami di dieu.

Naha éta sami di perusahaan anjeun?

Pikeun mariksa ieu, anjeun tiasa naroskeun ka diri anjeun patarosan di handap ieu.

Naha tim nganggo alat umum sareng nyumbang kana parobihan kana alat umum éta?

Sabaraha sering tim ngatur deui-sababaraha spesialis ti hiji tim pindah ka tim anu sanés? Di lingkungan DevOps ieu janten normal, sabab kadang jalma ngan saukur teu tiasa ngartos naon anu dilakukeun ku daérah kaahlian sanés. Anjeunna pindah ka departemén séjén, digawé di dinya salila dua minggu pikeun nyieun sorangan peta orientasi jeung interaksi jeung departemen ieu.

Naha mungkin pikeun ngabentuk panitia parobahan sareng ngarobih hal-hal? Atawa teu merlukeun leungeun kuat tina manajemen pangluhurna sarta arah? Kuring nembe wrote on Facebook kumaha hiji bank saeutik-dipikawanoh ngalaksanakeun parabot ngaliwatan pesenan: urang nulis pesenan, urang nerapkeun eta pikeun sataun, sarta ningali naon anu lumangsung. Ieu, tangtosna, panjang sareng sedih.

Sabaraha pentingna pikeun manajer nampi prestasi pribadi tanpa mikirkeun prestasi perusahaan?

Upami anjeun ngajawab patarosan ieu pikeun diri anjeun, éta bakal langkung jelas naha anjeun ngagaduhan masalah sapertos kitu di perusahaan anjeun.

Infrastruktur salaku kode

Saatos masalah ieu diliwatan, prakték penting kahiji, tanpa nu hese maju salajengna di DevOps, nyaeta infrastruktur salaku kode.

Paling sering, infrastruktur salaku kode dianggap kieu:

— Hayu urang ngajadikeun otomatis sadayana dina bash, nutupan diri nganggo skrip supados admin kirang damel manual!

Tapi éta henteu leres.

Infrastruktur salaku kode hartosna anjeun ngajelaskeun sistem IT anu anjeun damel dina bentuk kode supados ngartos kaayaanana.

Babarengan sareng tim anu sanés, anjeun nyiptakeun peta dina bentuk kode anu sadayana tiasa ngartos sareng tiasa napigasi sareng napigasi. Henteu janten masalah naon anu dilakukeun - Chef, Ansible, Salt, atanapi nganggo file YAML di Kubernetes - henteu aya bédana.

Dina konférénsi éta, kolega ti 2GIS nyarioskeun kumaha aranjeunna ngadamel hal internal sorangan pikeun Kubernetes, anu ngajelaskeun struktur sistem individu. Pikeun ngajelaskeun 500 sistem, aranjeunna peryogi alat anu misah anu ngahasilkeun pedaran ieu. Nalika aya katerangan ieu, sadayana tiasa saling parios, ngawas parobahan, kumaha carana ngarobih sareng ningkatkeun, naon anu leungit.

Satuju, skrip bash individu biasana henteu masihan pamahaman ieu. Di salah sahiji perusahaan tempat kuring damel, malah aya nami pikeun naskah "tulisan wungkul" - nalika naskahna ditulis, tapi teu tiasa dibaca deui. Jigana ieu wawuh ka anjeun teuing.

Infrastruktur sakumaha kode téh kodeu anu ngajelaskeun kaayaan infrastruktur ayeuna. Seueur produk, infrastruktur, sareng tim jasa damel babarengan dina kode ieu, sareng anu paling penting, aranjeunna sadayana kedah ngartos kumaha kode ieu leres-leres jalanna.

Kode dijaga nurutkeun prakték kode pangalusna: ngembangkeun gabungan, review kode, XP-programming, nguji, requests tarikan, CI pikeun infrastruktur kode - kabeh ieu cocog tur bisa dipaké.

Kode janten basa umum pikeun sadaya insinyur.

Ngarobah infrastruktur dina kode teu butuh loba waktu. Leres, kode infrastruktur ogé tiasa gaduh hutang téknis. Biasana tim sapatemon eta sataun satengah sanggeus aranjeunna mimiti nerapkeun "infrastruktur sakumaha kode" dina bentuk kebat Aksara atawa malah Ansible, nu maranéhna nulis kawas kode spaghetti, sarta maranéhanana ogé buang Aksara bash kana racikanana!

penting: Upami anjeun teu acan nyobian barang ieu, émut éta Ansible henteu bash! Baca dokuméntasi taliti, diajar naon maranéhna nulis ngeunaan eta.

Infrastruktur salaku kode nyaéta pamisahan kode infrastruktur kana lapisan anu misah.

Di perusahaan kami, kami ngabédakeun 3 lapisan dasar, anu jelas pisan sareng saderhana, tapi tiasa langkung seueur. Anjeun tiasa ningali kode infrastruktur anjeun sareng ngawartosan naha anjeun ngagaduhan kaayaan ieu atanapi henteu. Upami henteu aya lapisan anu disorot, maka anjeun kedah nyandak sababaraha waktos sareng refactor sakedik.


lapisan dasar - ieu kumaha OS, cadangan tur hal-tingkat low séjén anu ngonpigurasi, Contona, kumaha Kubernetes ieu deployed dina tingkat dasar.

Tingkat palayanan - Ieu mangrupikeun jasa anu anjeun nyayogikeun ka pamekar: logging salaku jasa, ngawaskeun salaku jasa, database salaku jasa, balancer salaku jasa, antrian salaku jasa, Pangiriman Kontinyu salaku jasa - sakumpulan jasa anu tim individu bisa nyadiakeun keur pangwangunan. Ieu sadayana kedah dijelaskeun dina modul anu misah dina sistem manajemen konfigurasi anjeun.

Lapisan dimana aplikasi dijieun sarta ngajelaskeun kumaha maranéhna bakal bentang dina luhureun dua lapisan saméméhna.

soal tés

Naha perusahaan anjeun gaduh gudang infrastruktur umum? Naha anjeun ngatur hutang téknis dina infrastruktur anjeun? Naha anjeun ngagunakeun prakték pangwangunan dina gudang infrastruktur? Naha infrastruktur anjeun dipotong kana lapisan? Anjeun tiasa pariksa diagram Base-service-APP. Kumaha héséna nyieun parobahan?

Upami anjeun parantos ngalaman yén peryogi sadinten satengah pikeun ngarobih, ieu hartosna anjeun gaduh hutang téknis sareng kedah damel sareng éta. Anjeun ngan stumbled kana rake hutang teknis dina kode infrastruktur Anjeun. Kuring émut seueur carita sapertos kitu nalika, pikeun ngarobih sababaraha CCTL, anjeun kedah nyerat deui satengah kode infrastruktur, sabab kréativitas sareng kahayang pikeun ngajadikeun otomatis sadayana nyababkeun kanyataan yén sadayana corroded dimana-mana, sadaya gagangna parantos dihapus, sareng perlu refactor.

Pangiriman kontinyu

Hayu urang ngabandingkeun debit jeung kiridit. Kahiji datang katerangan ngeunaan infrastruktur, nu bisa jadi rada dasar. Anjeun teu kudu ngajelaskeun sagalana di jéntré, tapi sababaraha pedaran dasar diperlukeun sangkan anjeun tiasa dianggo kalayan eta. Upami teu kitu, teu jelas naon anu kudu dipigawé kalayan pangiriman kontinyu salajengna. Sadaya prakték ieu dibuka sakaligus nalika anjeun sumping ka DevOps, tapi dimimitian ku ngartos naon anu anjeun gaduh sareng kumaha ngaturna. Ieu justru prakték infrastruktur salaku kode.

Sakali janten jelas yén anjeun gaduh sareng kumaha carana ngatur éta, anjeun mimiti terang kumaha cara ngirim kode pamekar ka produksi gancang-gancang. Maksad abdi sareng pamekar - urang émut ngeunaan masalah "sumur", nyaéta, sanés jalma individu anu ngadamel ieu, tapi tim.

Nalika urang jeung Vanya Evtukhovich nempo buku munggaran Jez Humble jeung kelompok pangarang "Pangiriman Terus-terusan", anu dirilis dina 2009, urang mikir lila ngeunaan kumaha carana narjamahkeun judul na kana Rusia. Aranjeunna hoyong narjamahkeun salaku "Terus nganteurkeun", tapi, hanjakalna, ditarjamahkeun salaku "Pangiriman Kontinyu". Sigana mah aya hal Rusia dina ngaran urang, kalawan tekanan.

Terus nganteurkeun hartosna

Kodeu anu aya dina gudang produk salawasna tiasa diunduh ka produksi. Anjeunna bisa jadi teu deflated, tapi anjeunna salawasna siap pikeun eta. Sasuai, anjeun salawasna nulis kode kalawan rarasaan teuas-to-dijelaskeun tina sababaraha kahariwang handapeun tailbone Anjeun. Éta sering muncul nalika anjeun ngagulung kode infrastruktur. Perasaan ieu sababaraha kahariwang kedah hadir - eta micu prosés otak nu ngidinan Anjeun pikeun nulis kode saeutik béda. Ieu kedah kacatet dina aturan dina pangwangunan.

Pikeun konsistén nganteurkeun, anjeun peryogi format artefak anu ngalangkungan platform infrastruktur. Upami anjeun ngalungkeun "runtah hirup" tina format anu béda-béda dina platform infrastruktur, teras janten ngahiji, sesah dijaga, sareng masalah hutang téknis timbul. Format artefak kedah dijajarkeun - ieu ogé mangrupikeun tugas koléktif: urang sadayana kedah ngumpul, rustle otak urang sareng ngadamel format ieu.

Artefak ieu terus ditingkatkeun sareng robih pikeun nyocogkeun lingkungan produksi nalika ngalangkungan pipa pangiriman. Nalika hiji artefak ngalir sapanjang pipa, eta terus encounters sababaraha hal pikaresepeun pikeun eta, nu sarupa jeung naon artefak nu nempatkeun kana encounters produksi. Upami dina pamekaran klasik ieu dilakukeun ku administrator sistem anu ngaluncurkeun, teras dina prosés DevOps ieu kajantenan unggal waktos: di dieu aranjeunna diuji ku sababaraha tés, di dieu aranjeunna ngalungkeun kana klaster Kubernetes, anu langkung seueur atanapi kirang sami. ka produksi, teras ujug-ujug aranjeunna ngamimitian nguji beban.

Ieu rada reminiscent tina kaulinan Pac-Man - artefak nu ngaliwatan sababaraha jenis carita. Dina waktos anu sami, penting pikeun ngontrol naha kodeu leres-leres ngalangkungan carita sareng naha éta aya hubunganana sareng produksi anjeun. Carita tina produksi tiasa nyeret kana prosés Pangiriman Kontinyu: sapertos kieu nalika aya anu murag, ayeuna hayu urang ngan ukur program skenario ieu di jero sistem. Unggal waktos kode bakal ngaliwatan skenario kieu teuing, jeung anjeun moal sapatemon masalah ieu waktos salajengna. Anjeun bakal diajar ngeunaan éta langkung awal tibatan ngahontal klien anjeun.

strategi deployment béda. Salaku conto, anjeun nganggo uji AB atanapi panyebaran kanaria pikeun nguji kode anu béda dina klien anu béda, kéngingkeun inpormasi ngeunaan kumaha kode éta jalan, sareng langkung awal tibatan nalika digulung ka 100 juta pangguna.

"Konsisten nganteurkeun" Sigana mah ieu.

Proses pangiriman Dev, CI, Test, PreProd, Prod sanes lingkungan anu kapisah, ieu mangrupikeun tahapan atanapi stasion kalayan jumlah seuneu anu ngalangkungan artefak anjeun.

Upami anjeun gaduh kode infrastruktur anu didadarkeun salaku Base Service APP maka éta ngabantosan tong hilap sadayana naskahna, sareng tuliskeun salaku kode pikeun artefak ieu, ngamajukeun artefak sareng robih nalika anjeun angkat.

Patarosan tés nyalira

Waktos ti pedaran fitur pikeun dileupaskeun kana produksi dina 95% kasus kirang ti saminggu? Naha kualitas artefak ningkat dina unggal tahapan pipa? Aya carita nu ngaliwat? Naha anjeun nganggo strategi panyebaran anu béda?

Lamun kabeh jawaban nu enya, mangka anjeun incredibly cool! Tulis waleran anjeun dina koméntar - Abdi bakal bungah).

Обратная связь

Ieu prakték paling hese sadaya. Dina konferensi DevOpsConf, batur sapagawean ti Infobip, ngawangkong ngeunaan eta, éta rada bingung dina kecap-Na, sabab ieu estu prakték pisan kompléks ngeunaan kanyataan yén anjeun kudu ngawas sagalana!

Salaku conto, lami pisan, nalika kuring damel di Qik sareng urang sadar yén urang kedah ngawas sadayana. Urang ngalakukeun ieu, sarta kami ayeuna boga 150 item dina Zabbix, nu terus diawaskeun. Éta pikasieuneun, sutradara téknis ngacungkeun ramo ka kuilna:

- Guys, naha anjeun memperkosa server kalawan hal teu jelas?

Tapi teras aya kajadian anu nunjukkeun yén ieu mangrupikeun strategi anu saé pisan.

Salah sahiji layanan mimiti nabrak terus. Mimitina, éta henteu nabrak, anu pikaresepeun, kodeu henteu ditambihan didinya, sabab éta calo dasar, anu praktis henteu aya fungsionalitas bisnis - éta ngan saukur ngirim pesen antara jasa individu. Palayanan henteu robih salami 4 bulan, sareng ujug-ujug mimiti nabrak sareng kasalahan "Segmentasi sesar".

Kami ngajempolan, dibuka grafik kami di Zabbix, sarta tétéla yén saminggu satengah kaliwat paripolah requests dina layanan API nu make calo ieu robah greatly. Salajengna urang nempo yén frékuénsi ngirim hiji tipe tangtu pesen geus robah. Engké urang manggihan yén ieu klien android. Urang nanya:

— Guys, naon anu lumangsung ka anjeun saminggu satengah kaliwat?

Salaku réspon, kami nguping carita anu pikaresepeun ngeunaan kumaha aranjeunna ngadesain ulang UI. Teu aya kamungkinan yén saha waé bakal langsung nyarios yén aranjeunna ngarobih perpustakaan HTTP. Pikeun klien Android, éta sapertos ngarobih sabun di kamar mandi - aranjeunna henteu émut. Hasilna, saatos 40 menit paguneman, urang mendakan yén aranjeunna parantos ngarobih perpustakaan HTTP, sareng waktos standarna parantos robih. Ieu ngakibatkeun kabiasaan lalulintas dina server API ngarobah, nu ngarah ka kaayaan anu ngabalukarkeun lomba dina calo nu, sarta eta mimiti nabrak.

Tanpa ngawaskeun jero umumna teu mungkin pikeun muka ieu. Lamun organisasi masih boga masalah "sumur", lamun dulur throws duit silih, ieu bisa hirup di pikeun taun. Anjeun saukur ngabalikan deui server sabab mustahil pikeun ngajawab masalah. Nalika anjeun ngawas, ngalacak, ngalacak sadaya kajadian anu anjeun gaduh, sareng nganggo ngawaskeun salaku uji - nyerat kode sareng langsung nunjukkeun kumaha ngawasna, ogé dina bentuk kode (urang parantos ngagaduhan infrastruktur salaku kode), sadayana janten jelas kumaha dina lontar. Malah masalah kompléks sapertos gampang dilacak.

Kumpulkeun sadaya inpormasi ngeunaan naon anu lumangsung ka artefak dina unggal tahapan prosés pangiriman - sanés dina produksi.

Unggah ngawaskeun ka CI, sareng sababaraha hal dasar bakal katingali di dinya. Engké anjeun bakal nempo aranjeunna dina Test, PredProd, sarta nguji beban. Kumpulkeun inpormasi dina sadaya tahapan, henteu ngan ukur métrik, statistik, tapi ogé log: kumaha aplikasi digulung, anomali - kumpulkeun sadayana.

Upami teu kitu, éta bakal hésé pikeun manggihan eta kaluar. Kuring parantos nyarios yén DevOps langkung rumit. Pikeun Cope jeung pajeulitna ieu, anjeun kudu boga analytics normal.

Patarosan pikeun kadali diri

Naha ngawaskeun sareng logging anjeun alat pangembangan pikeun anjeun? Nalika nyerat kode, naha pamekar anjeun, kalebet anjeun, mikirkeun kumaha ngawasna?

Dupi anjeun ngadangu ngeunaan masalah ti nasabah? Naha anjeun ngartos klien langkung saé tina ngawaskeun sareng logging? Naha anjeun ngartos sistem langkung saé tina ngawaskeun sareng logging? Naha anjeun ngarobih sistem kusabab anjeun ningali yén tren dina sistem naék sareng anjeun ngartos yén dina 3 minggu sanés sadayana bakal maot?

Sakali anjeun gaduh tilu komponén ieu, anjeun tiasa mikir ngeunaan jenis platform infrastruktur anu anjeun gaduh di perusahaan anjeun.

Platform infrastruktur

Intina henteu yén éta mangrupikeun sakumpulan alat anu béda-béda anu dipiboga ku unggal perusahaan.

Inti tina platform infrastruktur nyaéta yén sadaya tim nganggo alat ieu sareng ngembangkeun babarengan.

Éta jelas yén aya tim anu misah anu tanggung jawab pikeun ngembangkeun potongan individu tina platform infrastruktur. Tapi dina waktos anu sami, unggal insinyur nanggung tanggung jawab pikeun pangwangunan, kinerja, sareng promosi platform infrastruktur. Dina tingkat internal janten alat umum.

Sadaya tim ngembangkeun platform infrastruktur sareng ngarawatna kalayan ati-ati salaku IDE sorangan. Dina IDE Anjeun masang plugins béda pikeun sagalana nice jeung gancang, sarta ngonpigurasikeun hotkeys. Lamun anjeun muka Sublime, Atom atawa Visual Studio Code, kasalahan kode nu tuang di na anjeun nyadar yén éta teu mungkin keur dianggo pisan, anjeun langsung ngarasa hanjelu jeung anjeun ngajalankeun mun ngalereskeun IDE Anjeun.

Ngubaran platform infrastruktur anjeun ku cara anu sami. Upami anjeun ngartos yén aya anu lepat, tinggalkeun pamundut upami anjeun henteu tiasa ngalereskeunana nyalira. Upami aya anu saderhana, édit éta nyalira, kirimkeun pamenta tarik, jalma-jalma bakal nganggap sareng nambihanana. Ieu mangrupikeun pendekatan anu rada béda pikeun alat rékayasa dina sirah pamekar.

Platform infrastruktur ngajamin transfer artefak tina pamekaran ka klien kalayan perbaikan kualitas anu terus-terusan. IP diprogram ku sakumpulan carita anu lumangsung dina kode dina produksi. Sapanjang taun pangwangunan, seueur pisan carita ieu, sababaraha di antarana unik sareng ngan ukur aya hubunganana sareng anjeun - aranjeunna henteu tiasa Googled.

Dina titik ieu, platform infrastruktur janten kaunggulan kalapa anjeun, sabab boga hal diwangun kana eta teu aya dina alat pesaing urang. Langkung jero IP anjeun, langkung ageung kaunggulan kalapa anjeun dina hal Time-to-market. Nembongan di dieu masalah konci ngajual: Anjeun tiasa nyandak platform batur, tapi ngagunakeun pangalaman batur, anjeun moal ngarti kumaha relevan éta pikeun anjeun. Leres, henteu unggal perusahaan tiasa ngawangun platform sapertos Amazon. Ieu mangrupikeun garis anu sesah dimana pangalaman perusahaan relevan pikeun posisina di pasar, sareng anjeun henteu tiasa nganggo konci ngajual di dinya. Ieu ogé penting pikeun mikir ngeunaan.

Skéma

Ieu mangrupikeun diagram dasar tina platform infrastruktur anu bakal ngabantosan anjeun nyetél sadaya prakték sareng prosés di perusahaan DevOps.

Hayu urang nempo naon diwangun ku.

Sistim orkestrasi sumberdaya, nu nyadiakeun CPU, memori, disk ka aplikasi tur jasa lianna. Di luhureun ieu - jasa tingkat handap: ngawaskeun, logging, CI / CD Engine, gudang artefak, infrastruktur salaku kode sistem.

jasa tingkat luhur: database salaku jasa a, antrian salaku jasa a, Beban Balance salaku layanan a, pangaturan ukuran jadi gambar salaku layanan a, pabrik Big Data salaku layanan a. Di luhureun ieu - pipeline nu delivers kode terus dirobah ka klien Anjeun.

Anjeun nampi inpormasi ngeunaan kumaha parangkat lunak anjeun tiasa dianggo pikeun klien, robih, nyayogikeun kode ieu deui, nampi inpormasi - sareng anjeun terus ngembangkeun platform infrastruktur sareng parangkat lunak anjeun.

Dina diagram, pipa pangiriman diwangun ku sababaraha tahapan. Tapi ieu diagram skématik anu dirumuskeun sabagé conto - teu kedah ngulang hiji-hiji. Tahap berinteraksi sareng jasa saolah-olah éta jasa-unggal bata tina platform mawa carita sorangan: kumaha sumber daya dialokasikeun, kumaha aplikasi diluncurkeun, jalan sareng sumber daya, diawaskeun, sareng parobihan.

Kadé ngartos yen unggal bagian tina platform nu mawa carita, sarta nanya ka diri naon carita teu dibawa bata ieu, meureun kudu dialungkeun jauh jeung diganti ku layanan pihak-katilu. Contona, éta mungkin pikeun masang Okmeter tinimbang bata? Panginten budak lalaki parantos ngembangkeun kaahlian ieu langkung seueur tibatan urang. Tapi meureun henteu - sugan urang boga kaahlian unik, urang kudu install Prometheus tur ngamekarkeun eta salajengna.

Nyiptakeun platform

Ieu prosés komunikasi kompléks. Nalika anjeun ngagaduhan prakték dasar, anjeun ngamimitian komunikasi antara insinyur sareng spesialis anu béda anu ngembangkeun syarat sareng standar, sareng teras-terasan ngarobih kana alat sareng pendekatan anu béda. Budaya anu urang gaduh di DevOps penting di dieu.

Kalayan budaya sadayana saderhana pisan - éta ngeunaan kolaborasi sareng komunikasi, nyaeta, kahayang pikeun digawé dina widang umum saling, kahayang pikeun wield hiji alat babarengan. Henteu aya élmu rokét di dieu - sadayana saderhana pisan, banal. Contona, urang sadaya hirup di lawang jeung tetep bersih - tingkat sapertos budaya.

Naon anu anjeun gaduh?

Sakali deui, patarosan anjeun tiasa naroskeun ka diri anjeun.

Naha platform infrastruktur dikhususkeun? Saha anu tanggung jawab pangwangunanana? Naha anjeun ngartos kaunggulan kalapa tina platform infrastruktur anjeun?

Anjeun kudu terus nanya ka diri patarosan ieu. Upami aya anu tiasa ditransfer ka jasa pihak katilu, éta kedah ditransfer; upami jasa pihak katilu mimiti ngahalangan gerakan anjeun, maka anjeun kedah ngawangun sistem dina diri anjeun.

Janten, DevOps ...

... ieu sistem kompléks, éta kudu boga:

• Produk digital.
• Modul bisnis anu ngembangkeun produk digital ieu.
• Tim produk nu nulis kode.
• prakték Pangiriman kontinyu.
• Platform salaku jasa.
• Infrastruktur salaku jasa.
• Infrastruktur salaku kode.
• Prakték misah pikeun ngajaga reliabilitas, diwangun kana DevOps.
• Hiji prakték eupan balik anu ngajelaskeun eta sadayana.

Anjeun tiasa nganggo diagram ieu, nyorot di dinya naon anu anjeun gaduh di perusahaan anjeun dina sababaraha bentuk: naha éta parantos dikembangkeun atanapi masih kedah dikembangkeun.

Ieu bakal réngsé dina sababaraha minggu DevOpsConf 2019. salaku bagian tina RIT ++. Datangna kana konperénsi, dimana anjeun bakal mendakan seueur laporan anu saé ngeunaan pangiriman kontinyu, infrastruktur salaku kode sareng transformasi DevOps. Buku tiket Anjeun, deadline harga panungtungan nyaéta 20 Méi

sumber: www.habr.com