🥇Tes ing produksi: Canary Deployment

Kenari minangka manuk cilik sing nyanyi terus-terusan. Manuk iki sensitif marang metana lan karbon monoksida. Malah konsentrasi keluwihan gas sing cilik ing udhara ndadekake dheweke ilang kesadaran utawa mati. Pencari emas lan penambang njupuk manuk kasebut menyang tambang: nalika kenari nyanyi, sampeyan bisa kerja, yen mandheg nyanyi, ana gas ing tambang lan wektune mangkat. Penambang kurban manuk cilik kanggo metu saka tambang urip.

Praktek sing padha wis ditemokake ing IT. Contone, ing tugas standar deploying versi anyar saka layanan utawa aplikasi kanggo produksi karo testing sakdurunge. Lingkungan tes bisa uga larang banget, tes otomatis ora nutupi kabeh sing dikarepake, lan ora nguji lan ngorbanake kualitas mbebayani. Ing kasus kaya mengkono pendekatan Canary Deployment mbantu, nalika lalu lintas produksi nyata sethitik dikirim menyang versi anyar. Pendekatan mbantu kanthi aman mriksa versi anyar kanggo produksi, ngorbanake sethithik kanggo tujuan gedhe. Waca liyane babagan cara pendekatan kasebut, apa gunane lan cara ngetrapake Andrey Markelov (Andrey_V_Markelov), nggunakake conto implementasine ing perusahaan Infobip.

Andrey Markelov — Lead Software Engineer ing Infobip, wis ngembangake aplikasi Java ing bidang keuangan lan telekomunikasi suwene 11 taun. Ngembangake produk Open Source, melu aktif ing Komunitas Atlassian lan nulis plugin kanggo produk Atlassian. Penginjil Prometheus, Docker lan Redis.

Babagan Infobip

Iki minangka platform telekomunikasi global sing ngidini bank, toko, toko online lan perusahaan transportasi ngirim pesen menyang pelanggan liwat SMS, push, surat lan pesen swara. Ing bisnis kuwi, stabilitas lan linuwih penting supaya pelanggan nampa pesen ing wektu.

Infrastruktur IT Infobip ing angka:

15 pusat data ing saindenging jagad;
500 layanan unik ing operasi;
2500 conto layanan, sing luwih akeh tinimbang prentah;
4,5 TB lalu lintas saben wulan;
4,5 milyar nomer telpon;

Bisnis saya tambah akeh, lan kanthi jumlah rilis. Kita nindakake 60 rilis saben dina, amarga pelanggan pengin luwih akeh fitur lan daya. Nanging angel - ana akeh layanan lan sawetara tim. Sampeyan kudu nulis kode kanthi cepet sing kudu digunakake ing produksi tanpa kesalahan.

Rilis

A release khas kanggo kita dadi kaya iki. Contone, ana layanan A, B, C, D lan E, saben wong dikembangake dening tim sing kapisah.

Ing sawetara titik, tim layanan A mutusake kanggo nyebarake versi anyar, nanging tim layanan B, C, D lan E ora ngerti babagan iki. Ana rong opsi carane tim layanan A bakal tumindak.

Bakal tumindak release tambahan: pisanan ngganti siji versi, banjur kaloro.

Nanging ana pilihan kapindho: tim bakal nemokake kapasitas lan mesin tambahan, masang versi anyar, banjur ngalih router, lan versi bakal miwiti digunakake ing produksi.

Ing kasus apa wae, masalah meh tansah muncul sawise panyebaran, sanajan versi wis diuji. Sampeyan bisa nyoba kanthi manual, sampeyan bisa nyoba kanthi otomatis, sampeyan ora bisa nyoba - masalah bakal muncul ing kasus apa wae. Cara sing paling gampang lan paling bener kanggo ngatasi masalah kasebut yaiku muter maneh menyang versi sing digunakake. Mung banjur sampeyan bisa ngatasi karusakan, alasan lan ndandani.

Dadi apa sing dikarepake?

Kita ora pengin masalah. Yen pelanggan nemokake sadurunge kita, bakal ngrusak reputasi kita. Pramila kita kedah nemokake masalah luwih cepet tinimbang pelangganKanthi nggarap ahead, kita nyilikake karusakan.

Ing wektu sing padha, kita pengin nyepetake panyebaran, supaya kedadeyan kanthi cepet, gampang, alami lan tanpa stres saka tim. Insinyur, insinyur DevOps lan programer kudu dilindhungi - rilis versi anyar nyebabake stres. Tim kasebut ora bisa dikonsumsi, kita usaha nggunakake sumber daya manungsa kanthi rasional.

Masalah panyebaran

Lalu lintas pelanggan ora bisa ditebak. Ora bisa prédhiksi kapan lalu lintas pelanggan bakal paling murah. Kita ora ngerti ngendi lan kapan pelanggan bakal miwiti kampanye - bisa uga bengi iki ing India, lan sesuk ing Hong Kong. Amarga bedane wektu sing akeh, nyebarake sanajan jam 2 esuk ora njamin pelanggan ora bakal kena pengaruh.

Masalah panyedhiya. Utusan lan panyedhiya minangka mitra kita. Kadhangkala ana kegagalan sing nyebabake kesalahan sajrone panyebaran versi anyar.

Tim sing disebarake. Tim sing ngembangake klien lan backend dumunung ing zona wektu sing beda. Amarga iki, dheweke asring ora setuju karo siji liyane.

Pusat data ora bisa ditiru ing panggungAna 200 rak ing siji pusat data - ora bisa uga kira-kira niru iki ing kothak wedhi.

Downtimesora bisa ditampa! Kita duwe tingkat kasedhiyan sing bisa ditampa (Anggaran Kesalahan), nalika kita kerja 99,99% wektu, contone, lan persentase sing isih ana yaiku "hak kanggo nggawe kesalahan". Ora mungkin kanggo entuk linuwih 100%, nanging penting kanggo terus-terusan ngawasi kegagalan lan downtime.

Solusi klasik

Tulis kode tanpa bugNalika aku dadi pangembang enom, manajer bakal teka lan njaluk aku ngeculake tanpa bug, nanging iki ora bisa ditindakake.

Tulis tes. Tes bisa ditindakake, nanging kadhangkala ora kaya sing dikarepake bisnis. Nggawe dhuwit dudu tujuan tes.

Tes ing panggungSajrone 3,5 taun kerja ing Infobip, aku durung nate ndeleng kahanan panggung sanajan sebagian bertepatan karo produksi.

Kita malah nyoba ngembangake gagasan iki: pisanan kita duwe panggung, banjur pra-produksi, lan banjur pra-produksi pra-produksi. Nanging iki uga ora nulungi - dheweke ora cocog karo kekuwatane. Kanthi tataran, kita bisa njamin fungsi dhasar, nanging kita ora ngerti carane bakal bisa ing mbukak.

Rilis kasebut digawe dening sing ngembangake. Praktek sing apik kanggo nambah sanajan ana sing ngganti judhul komentar dadi produksi. Iki mbantu ngembangake tanggung jawab lan ora lali babagan owah-owahan sing ditindakake.

Ana uga komplikasi tambahan. Iku kaku kanggo pangembang kanggo nglampahi akèh wektu mriksa kabeh kanthi manual.

Rilis terkoordinasi. Opsi iki biasane disaranake dening manajemen: "Ayo setuju yen sampeyan bakal nyoba lan nambah versi anyar saben dina." Iki ora bisa: mesthi ana tim sing ngenteni wong liya, utawa kosok balene.

Tes kumelun

Cara liya kanggo ngatasi masalah penyebaran kita. Ayo goleki carane tes kumelun bisa digunakake ing conto sadurunge, nalika Tim A pengin masang versi anyar.

Kaping pisanan, tim nyebarake siji conto kanggo produksi. Pesen kanggo Kayata saka mocks simulates lalu lintas nyata, supaya cocog karo lalu lintas saben dina normal. Yen kabeh apik, tim ngalih versi anyar menyang lalu lintas pangguna.

Opsi kapindho yaiku nyebarake karo wesi tambahan. Tim nguji ing produksi, banjur ngalih, lan kabeh bisa.

Kekurangan tes rokok:

Tes ora bisa dipercaya. Ing endi bisa entuk lalu lintas sing padha karo produksi? Aku bisa nggunakake wingi utawa minggu kepungkur, nanging ora mesthi cocog karo sing saiki.
Hard kanggo njaga. Sampeyan kudu njaga akun test, terus-terusan ngreset sadurunge saben penyebaran nalika rekaman langsung dikirim menyang repositori. Iki luwih angel tinimbang nulis tes ing kothak wedhi.

Bonus mung kene sampeyan bisa mriksa kinerja.

Rilis Canary

Amarga kekurangan tes asap, kita wiwit nggunakake rilis kenari.

Praktek sing padha karo para penambang nggunakake kenari kanggo nunjukake tingkat gas wis ditemokake ing IT. We lagi diluncurake sawetara lalu lintas produksi nyata kanggo versi anyar, nalika nyoba kanggo ketemu Service Level Agreement (SLA). SLA minangka "hak kanggo nggawe kesalahan" sing bisa digunakake saben taun (utawa kanggo sawetara wektu liyane). Yen kabeh apik, kita bakal nambah lalu lintas. Yen ora, kita bakal bali menyang versi sadurungé.

Implementasi lan nuansa

Kepiye carane kita ngetrapake rilis kenari? Contone, klompok klien ngirim pesen liwat layanan kita.

Penyebaran dadi kaya iki: kita mbusak siji simpul saka balancer (1), ngganti versi (2) lan kapisah miwiti lalu lintas sethitik (3).

Umumé, kabeh wong ing grup bakal seneng, sanajan siji pangguna ora seneng. Yen kabeh apik, kita ngganti kabeh versi.

Aku bakal nuduhake sampeyan skematis carane iki katon kanggo microservices ing paling kasus.

Ana Service Discovery lan loro layanan liyane: S1N1 lan S2. Layanan pisanan (S1N1) ngabari Service Discovery nalika diwiwiti, lan Service Discovery ngelingi. Layanan kapindho kanthi rong simpul (S2N1 lan S2N2) uga menehi kabar marang Discovery Layanan nalika diwiwiti.

Layanan kapindho dianggo minangka server kanggo sing pisanan. Sing pertama njaluk informasi babagan server saka Service Discovery, lan nalika nampa, dheweke nggoleki lan mriksa ("pemeriksaan kesehatan"). Nalika mriksa wong-wong mau, iku ngirim pesen.

Nalika ana wong sing pengin nyebarake versi anyar saka layanan kapindho, ngandhani Service Discovery yen simpul kapindho bakal dadi simpul kenari: bakal nampa kurang lalu lintas amarga panyebaran bakal ditindakake. Kita mbusak simpul kenari saka balancer lan layanan pisanan ora ngirim lalu lintas menyang.

Kita ngganti versi lan Service Discovery ngerti yen simpul kapindho saiki kenari - kita bisa menehi kurang mbukak (5%). Yen kabeh apik, kita ngganti versi, mbalekake beban lan terus kerja.

Kanggo ngleksanakake kabeh iki, kita kudu:

ngimbangi;
ngawasi, amarga penting kanggo ngerti apa sing dikarepake saben pangguna lan cara layanan kita bisa digunakake kanthi rinci;
analisis versi, kanggo mangerteni carane versi anyar bakal bisa digunakake ing produksi;
otomatisasi - kita nulis pipa penyebaran.

Balancing

Iki minangka perkara pisanan sing kudu kita pikirake. Ana rong strategi imbangan.

Pilihan sing paling gampang yaiku nalika siji simpul tansah kenari. Node iki tansah nampa kurang lalu lintas lan kita miwiti panyebaran saka iku. Yen ana masalah, kita bakal mbandhingake karyane sadurunge lan sajrone penyebaran. Contone, yen jumlah kasalahan wis tikel kaping pindho, banjur karusakan wis tikel.

Node Canary disetel sajrone panyebaran. Nalika panyebaran rampung lan kita mbusak status simpul kenari saka iku, imbangan lalu lintas bakal dibalèkaké. Kanthi mesin sing luwih sithik, kita bakal entuk distribusi sing adil.

Ngawasi

Watu dhasar rilis kenari kudu jelas babagan kenapa kita nindakake lan metrik apa sing arep kita kumpulake.

Conto metrik sing diklumpukake saka layanan kita.

Jumlah kasalahan, sing ditulis ing log. Iki minangka indikator sing jelas yen kabeh bisa digunakake kaya sing dikarepake. Sakabèhé, iki minangka metrik sing apik.
Wektu eksekusi pitakon (latensi) Iki minangka metrik sing dipantau saben wong amarga kabeh wong pengin kerja cepet.
Ukuran antrian (throughput).
Jumlah respon sing sukses saben detik.
Wektu eksekusi kanggo 95% kabeh panjalukan.
Metrik bisnis: pinten dhuwit bisnis nggawe liwat wektu tartamtu utawa pangguna churn. Metrik iki bisa uga luwih penting kanggo versi anyar kita tinimbang sing ditambahake dening insinyur.

Conto metrik ing sistem pemantauan sing paling populer.

Counter. Iki sawetara nambah nilai, contone, nomer kasalahan. Metrik iki gampang diinterpolasi lan nyinaoni grafik: wingi ana 2 kesalahan, lan dina iki 500, tegese ana sing salah.

Jumlah kesalahan saben menit utawa per detik minangka indikator paling penting sing bisa diitung nggunakake Counter. Data iki menehi gambaran sing jelas babagan operasi sistem sajrone wektu. Ayo goleki conto grafik jumlah kesalahan per detik kanggo rong versi sistem produksi.

Versi pisanan duwe sawetara kewan omo, bisa uga audit ora bisa ditindakake. Versi kapindho luwih elek. Kita mesthi bisa ngomong yen ana masalah, mula kita kudu muter maneh versi iki.

Gauge. Metrik padha karo Counter, nanging kita ngrekam nilai sing bisa nambah utawa nyuda, kayata wektu eksekusi pitakon utawa ukuran antrian.

Grafik kasebut nuduhake conto wektu nanggepi (latency). Grafik kasebut nuduhake manawa versi kasebut padha, sampeyan bisa nggarap. Nanging yen sampeyan ndeleng kanthi teliti, sampeyan bisa ndeleng carane owah-owahan regane. Yen wektu eksekusi pitakon mundhak nalika nambahake pangguna, mula langsung jelas yen ana masalah - iki durung kedadeyan sadurunge.

Ringkesan. Salah sawijining metrik sing paling penting kanggo bisnis yaiku persentil. Metrik nuduhake yen ing 95% kasus sistem kita dianggo cara kita arep. Kita bisa nampa masalah nang endi wae amarga kita ngerti tren umum, carane apik utawa ala kabeh.

Piranti

Tumpukan ELK. Sampeyan bisa ngetrapake kenari nggunakake Elasticsearch - kita nulis kesalahan nalika kedadeyan. Kanthi telpon API sing prasaja, sampeyan bisa entuk jumlah kesalahan ing sembarang wektu lan mbandhingake karo segmen sadurunge: GET /applg/_cunt?q=level:errr.

Prometheus. Wis kabukten kanthi apik ing Infobip. Iki ngidini ngleksanakake metrik multidimensi amarga label digunakake.

Kita bisa nggunakake level, instance, service, gabungke ing siji sistem. Kanthi bantuan saka offset sampeyan bisa ndeleng, contone, ing Nilai saka jumlah minggu kepungkur karo mung siji printah GET /api/v1/query?query={query}ngendi {query}:

rate(logback_appender_total{ 
    level="error",  
    instance=~"$instance" 
}[5m] offset $offset_value)

Analisis versi

Ana sawetara strategi kanggo analisis versi.

Deleng metrik mung kanggo kelenjar kenari. Salah siji opsi paling gampang: masang versi anyar lan sinau mung karya. Nanging yen insinyur ing wektu iki wiwit sinau log, terus-terusan gugup reloading kaca, banjur solusi iki ora beda saka liyane.

Node Canary dibandhingake karo simpul liyane. Iki minangka perbandingan karo kedadeyan liyane sing mlaku kanthi lalu lintas lengkap. Contone, yen ana sing luwih elek utawa ora luwih apik kanthi lalu lintas sing sithik tinimbang kedadeyan nyata, mula ana sing salah.

Node Canary dibandhingake karo awake dhewe. Node sing dialokasikan kanggo kenari bisa dibandhingake karo data historis. Contone, yen kabeh apik seminggu kepungkur, kita bisa nggunakake data iki kanggo mangerteni kahanan saiki.

Otomasi

Kita pengin mbebasake insinyur saka perbandingan manual, mula penting kanggo ngetrapake otomatisasi. Pipa penyebaran biasane katon kaya iki:

ayo miwiti;
mbusak simpul saka sangisore balancer;
kita nginstal simpul kenari;
kita nguripake balancer kanthi jumlah lalu lintas sing winates;
ayo mbandhingake.

Ing tataran iki kita ngleksanakake comparison otomatis. Ayo katon kaya apa lan kenapa luwih apik tinimbang mriksa sawise panyebaran nggunakake conto saka Jenkins.

Iki minangka pipa kanggo Groovy.

while (System.currentTimeMillis() < endCanaryTs) {
    def isOk = compare(srv, canary, time, base, offset, metrics)
    if (isOk) {
        sleep DEFAULT SLEEP
    }   else {
        echo "Canary failed, need to revert"  
        return false
    }
}

Kene ing siklus kita nyetel sing kita bakal mbandhingaké simpul anyar ing jam. Yen proses kenari durung rampung, kita nelpon fungsi kasebut. Iku laporan apa kabeh apik utawa ora: def isOk = compare(srv, canary, time, base, offset, metrics).

Yen kabeh apik - sleep DEFAULT SLEEP, contone, kanggo liyane, lan terus. Yen ora, metu - panyebaran gagal.

Katrangan saka metrik. Ayo ndeleng apa fungsi kasebut compare nggunakake DSL minangka conto.

metric(
    'errorCounts',
    'rate(errorCounts{node=~"$canaryInst"}[5m] offset $offset)',
    {   baseValue, canaryValue ->
        if (canaryValue > baseValue * 1.3) return false 
        return true
    }
)

Contone, kita mbandhingake jumlah kesalahan lan pengin ngerti jumlah kesalahan per detik sajrone 5 menit pungkasan.

Kita duwe rong nilai: simpul basa lan kenari. Nilai simpul kenari yaiku saiki. Dasar yaiku baseValue - iki regane simpul non-kenari liyane. Kita mbandhingake nilai-nilai kasebut kanthi nggunakake rumus sing disetel adhedhasar pengalaman lan pengamatan. Yen nilai canaryValue ala, banjur panyebaran gagal, lan kita muter maneh.

Yagene kabeh iki perlu?

Wong ora bisa mriksa atusan lan ewu metrik, utamane kanggo nindakake kanthi cepet. Perbandingan otomatis mbantu mriksa kabeh metrik lan menehi kabar kanthi cepet babagan masalah. Wektu kabar kritis: yen ana kedadeyan ing 2 detik pungkasan, karusakane ora bakal gedhe kaya kedadeyan 15 menit kepungkur. Ing wektu wong sok dong mirsani masalah, nulis kanggo ndhukung, lan ndhukung kanggo kita muter maneh, sampeyan bisa ilang pelanggan.

Yen proses kasebut sukses lan kabeh apik, kita masang kabeh kelenjar liyane kanthi otomatis. Sajrone wektu iki, insinyur ora nindakake apa-apa. Mung nalika ngluncurake kenari, dheweke mutusake apa metrik sing kudu ditindakake, suwene wektu kanggo nindakake perbandingan, strategi apa sing bakal digunakake.

Yen ana masalah, kita kanthi otomatis muter maneh simpul kenari, nggarap versi sadurunge lan ndandani kesalahan sing ditemokake. Gampang ditemokake nggunakake metrik lan ndeleng karusakan saka versi anyar.

alangan

Mesthine, ora gampang kanggo ngetrapake iki. Kaping pisanan, perlu Sistem monitoring umum. Insinyur duwe metrik dhewe, dhukungan lan analis duwe liyane, lan bisnis duwe liyane. Sistem umum minangka basa umum sing diomongake bisnis lan pangembangan.

Perlu kanggo nyoba ing laku stabilitas metrik. Priksa mbantu ngerti, apa set minimal metrik sing dibutuhake kanggo njamin kualitas.

Kepiye carane entuk iki? Gunakake layanan kenari ora ing wektu penyebaran. Kita nambah layanan kanggo versi lawas sing bisa njupuk sembarang simpul darmabakti ing sembarang wektu, nyuda lalu lintas tanpa penyebaran prajurit. Banjur kita mbandhingake: sinau kesalahan lan goleki baris kasebut nalika entuk kualitas.

Kepiye entuk manfaat saka rilis kenari

Nyilikake persentase karusakan saka kewan omo. Umume kesalahan panyebaran amarga sawetara data utawa ora konsistensi prioritas. Saiki luwih sithik kesalahan kasebut amarga kita bisa ndandani masalah kasebut ing detik pisanan.

Ngoptimalake karya tim. Newbies duwe "hak kanggo nggawe kesalahan": padha bisa nyebar menyang produksi tanpa wedi nggawe kesalahan, inisiatif tambahan lan insentif kanggo karya katon. Yen dheweke ngrusak barang, ora bakal kritis, lan wong sing salah ora bakal dipecat.

Panyebaran otomatis. Iki ora ana maneh proses manual, kaya sadurunge, nanging sing bener-bener otomatis. Nanging luwih suwe.

Metrik penting sing disorot. Perusahaan kabeh, saka bisnis nganti insinyur, ngerti apa sing penting banget ing produk kita, metrik apa, contone, pangguna churn lan influx. Kita ngontrol proses kasebut: kita nguji metrik, ngenalake sing anyar, ndeleng cara kerja sing lawas kanggo mbangun sistem sing bakal entuk dhuwit kanthi luwih efisien.

Kita duwe akeh praktik lan sistem sing apik sing mbantu kita. Senadyan mangkono, kita ngupayakake dadi profesional lan nindakake pakaryan kanthi becik, ora preduli apa kita duwe sistem sing bakal nulungi kita utawa ora.

Pendekatan lan praktik teknik - fokus utama konferensi TechLead Conf. Yen sampeyan wis sukses ing dalan kanggo keunggulan teknis lan siap ngandhani apa sing mbantu sampeyan entuk iki, nglamar kanggo laporan.
We planning kanggo terus TechLead Conf 8 Juni Kita ngerti manawa angel nggawe keputusan babagan melu konferensi saiki. Nanging ing wektu sing padha, kita percaya yen karantina dudu alesan kanggo mungkasi komunikasi lan pangembangan profesional. Mulane, ing kasus apa wae, kita bakal nemokake cara kanggo ngrembug tugas pimpinan teknologi lan pendekatan kanggo ngrampungake - yen perlu, kita bakal online lan nyebarake jaringan ing kana!

Source: www.habr.com