Saiki topik DevOps ana ing hype. Integrasi Terus-terusan lan Pipa Pangiriman kabeh wong ngleksanakake. Nanging umume ora tansah menehi perhatian kanggo njamin linuwih sistem informasi ing macem-macem tahapan Pipeline CI/CD. Ing artikel iki, aku pengin ngomong babagan pengalamanku ngotomatisasi pamriksa kualitas piranti lunak lan ngleksanakake skenario sing bisa kanggo "penyembuhan diri".
Aku kerja minangka insinyur ing departemen manajemen layanan IT ing sawijining perusahaan . Wilayah inti keahlianku yaiku implementasine macem-macem kinerja aplikasi lan sistem pemantauan kasedhiyan. Aku kerep komunikasi karo pelanggan IT saka macem-macem segmen pasar babagan masalah saiki babagan ngawasi kualitas layanan IT. Tujuan utama yaiku nyilikake wektu siklus rilis lan nambah frekuensi rilis. Iki, mesthine, kabeh apik: luwih akeh rilis - luwih akeh fitur anyar - luwih akeh pangguna sing marem - luwih akeh bathi. Nanging ing kasunyatan, iku ora tansah dadi apik. Kanthi tingkat penyebaran sing dhuwur banget, pitakonan langsung muncul babagan kualitas rilis kita. Malah kanthi pipa otomatis kanthi otomatis, salah sawijining tantangan paling gedhe yaiku mindhah layanan saka tes menyang produksi tanpa mengaruhi wektu aplikasi lan pengalaman pangguna.
Adhedhasar asil akeh obrolan karo pelanggan, aku bisa ujar manawa ngeculake kontrol kualitas, masalah keandalan aplikasi lan kemungkinan "penyembuhan diri" (umpamane, bali menyang versi stabil) ing macem-macem tahapan CI. Pipa / CD minangka salah sawijining topik sing paling nyenengake lan relevan.
Bubar, aku dhewe kerja ing sisih pelanggan - ing layanan dhukungan piranti lunak aplikasi perbankan online. Arsitektur aplikasi kita nggunakake akeh layanan mikro sing ditulis dhewe. Sing paling sedhih yaiku ora kabeh pangembang bisa ngrampungake kanthi cepet pembangunan; kualitas sawetara layanan mikro sing nandhang sangsara, sing nyebabake julukan lucu kanggo dheweke lan pangripta. Ana crita babagan bahan apa sing digawe saka produk kasebut.
"Formulasi masalah"
Frekuensi rilis sing dhuwur lan akeh layanan mikro nggawe angel ngerti operasi aplikasi kanthi sakabehe, ing tahap tes lan ing tahap operasional. Owah-owahan kedadeyan terus-terusan lan angel banget kanggo ngontrol tanpa alat ngawasi sing apik. Asring, sawise release wengi ing wayah esuk, pangembang njagong kaya ing keg bubuk lan ngenteni apa-apa kanggo break, sanajan kabeh mriksa sukses ing tataran testing.
Ana siji titik maneh. Ing tahap tes, fungsionalitas piranti lunak dicenthang: implementasine fungsi utama aplikasi lan ora ana kesalahan. Evaluasi kinerja kualitatif ora ana utawa ora nggatekake kabeh aspek aplikasi lan lapisan integrasi. Sawetara metrik bisa uga ora dicenthang. Akibaté, nalika risak ana ing lingkungan produksi, departemen technical support mung ngerti bab iku nalika pangguna nyata wiwit sambat. Aku pengin nyilikake impact saka piranti lunak kualitas kurang ing pangguna pungkasan.
Salah sawijining solusi yaiku ngleksanakake proses kanggo mriksa kualitas piranti lunak ing macem-macem tahapan CI / CD Pipeline, lan nambah macem-macem skenario kanggo mulihake sistem nalika ana darurat. Kita uga ngelingi yen kita duwe DevOps. Bisnis ngarepake nampa produk anyar kanthi cepet. Mula, kabeh pamriksa lan skrip kita kudu otomatis.
Tugas kasebut dipérang dadi rong komponen:
- kontrol kualitas majelis ing tahap testing (kanggo ngotomatisasi proses nyekel rakitan kualitas rendah);
- kontrol kualitas piranti lunak ing lingkungan produksi (mekanisme kanggo deteksi otomatis masalah lan bisa skenario kanggo poto-marasake awakmu).
Alat kanggo ngawasi lan ngumpulake metrik
Kanggo nggayuh tujuan sing ditemtokake, sistem pemantauan dibutuhake sing bisa ndeteksi masalah lan nransfer menyang sistem otomatisasi ing macem-macem tahapan pipa CI / CD. Iku uga bakal dadi positif yen sistem iki menehi metrik migunani kanggo macem-macem tim: pembangunan, testing, operasi. Lan pancen apik tenan yen uga kanggo bisnis.
Kanggo ngumpulake metrik, sampeyan bisa nggunakake sakumpulan sistem sing beda-beda (Prometheus, ELK Stack, Zabbix, lan liya-liyane), nanging, miturut pendapatku, solusi kelas APM paling cocog kanggo tugas kasebut (), sing bisa nyederhanakake urip sampeyan.
Minangka bagéan saka karya ing layanan support, Aku miwiti nindakake project padha nggunakake solusi kelas APM saka Dynatrace. Saiki, nggarap integrator, aku ngerti pasar sistem pemantauan kanthi apik. Pendapat subjektifku: Dynatrace paling cocog kanggo ngrampungake masalah kasebut.
Dynatrace nyedhiyakake tampilan horisontal saben operasi pangguna ing tingkat granular nganti tingkat eksekusi kode. Sampeyan bisa nglacak kabeh rantai interaksi ing antarane macem-macem layanan informasi: saka tingkat ngarep web lan aplikasi seluler, server aplikasi mburi mburi, bus integrasi nganti telpon tartamtu menyang database.
. Konstruksi otomatis kabeh dependensi antarane komponen sistem
. Deteksi otomatis lan konstruksi jalur operasi layanan
Kita uga ngelingi yen kita kudu nggabungake karo macem-macem alat otomatisasi. Ing kene solusi kasebut nduweni API sing trep sing ngidini sampeyan ngirim lan nampa macem-macem metrik lan acara.
Sabanjure, ayo pindhah menyang tampilan sing luwih rinci babagan carane ngatasi masalah kasebut nggunakake sistem Dynatrace.
Tugas 1. Otomatisasi kontrol kualitas rakitan ing tahap tes
Tantangan pisanan yaiku nemokake masalah sedini mungkin ing pipa pangiriman aplikasi. Mung mbangun kode "apik" kudu tekan produksi. Kanggo nindakake iki, pipa sampeyan ing tahap tes kudu kalebu monitor tambahan kanggo mriksa kualitas layanan sampeyan.
Ayo goleki langkah demi langkah babagan cara ngetrapake iki lan ngotomatisasi proses iki:
Tokoh kasebut nuduhake aliran langkah-langkah pengujian kualitas piranti lunak otomatis:
- penyebaran sistem pemantauan (instalasi agen);
- ngenali acara kanggo netepake kualitas piranti lunak (metrik lan nilai ambang) lan nransfer menyang sistem ngawasi;
- generasi tes beban lan kinerja;
- ngumpulake data kinerja lan kasedhiyan ing sistem ngawasi;
- transfer data test adhedhasar acara Assessment kualitas piranti lunak saka sistem ngawasi kanggo sistem CI / CD. Analisis otomatis saka rakitan.
Langkah 1. Penyebaran sistem ngawasi
Pisanan sampeyan kudu nginstal agen ing lingkungan tes sampeyan. Ing wektu sing padha, solusi Dynatrace nduweni fitur sing apik - nggunakake agen universal OneAgent, sing diinstal ing conto OS (Windows, Linux, AIX), kanthi otomatis ndeteksi layanan sampeyan lan wiwit ngumpulake data pemantauan. Sampeyan ora perlu ngatur agen kapisah kanggo saben proses. Kahanan bakal padha kanggo platform awan lan wadhah. Ing wektu sing padha, sampeyan uga bisa ngotomatisasi proses instalasi agen. Dynatrace cocog banget karo konsep "infrastruktur minangka kode" (): Ana skrip lan instruksi sing wis siap kanggo kabeh platform populer. Sampeyan nampilake agen kasebut menyang konfigurasi layanan sampeyan, lan nalika sampeyan nyebarake, sampeyan langsung nampa layanan anyar karo agen sing wis kerja.
Langkah 2: Nemtokake acara kualitas piranti lunak
Saiki sampeyan kudu mutusake dhaptar layanan lan operasi bisnis. Penting kanggo nggatekake operasi pangguna sing penting banget kanggo layanan sampeyan. Ing kene aku nyaranake konsultasi karo analis bisnis lan sistem.
Sabanjure, sampeyan kudu nemtokake metrik sing pengin dilebokake ing review kanggo saben level. Contone, iki bisa dadi wektu eksekusi (dipérang dadi rata-rata, median, persentil, lan sapiturute), kesalahan (logis, layanan, infrastruktur, lan liya-liyane) lan macem-macem metrik infrastruktur (tumpukan memori, kolektor sampah, count thread, etc.).
Kanggo otomatisasi lan gampang digunakake dening tim DevOps, konsep "Monitoring as Code" katon. Apa sing dakkarepake yaiku pangembang / panguji bisa nulis file JSON sing prasaja sing nemtokake metrik jaminan kualitas piranti lunak.
Ayo goleki conto file JSON kasebut. Obyek saka Dynatrace API digunakake minangka pasangan kunci/nilai (deskripsi API bisa ditemokake ing kene ).
{
"timeseries": [
{
"timeseriesId": "service.ResponseTime",
"aggregation": "avg",
"tags": "Frontend",
"severe": 250000,
"warning": 1000000
},
{
"timeseriesId": "service.ResponseTime ",
"aggregation": "avg",
"tags": "Backend",
"severe": 4000000,
"warning": 8000000
},
{
"timeseriesId": "docker.Container.Cpu",
"aggregation": "avg",
"severe": 50,
"warning": 70
}
]
}File kasebut minangka macem-macem definisi seri wektu:
- timeseriesId - metrik sing dicenthang, contone, Response Time, Error count, Memory used, etc.;
- aggregation - tingkat panggabungan metrik, ing kasus kita rata-rata, nanging sampeyan bisa nggunakake sembarang sing sampeyan butuhake (rata-rata, min, maks, jumlah, count, persentil);
- tags - tag obyek ing sistem ngawasi, utawa sampeyan bisa nemtokake pengenal obyek tartamtu;
- abot lan bebaya - indikator iki ngatur nilai ambang metrik kita; yen nilai tes ngluwihi ambang abot, mula bangunan kita ditandhani ora sukses.
Tokoh ing ngisor iki nuduhake conto panggunaan ambang kasebut.
Langkah 3: Muat Generasi
Sawise nemtokake tingkat kualitas layanan, kita kudu ngasilake beban tes. Sampeyan bisa nggunakake alat testing apa wae sing sampeyan seneng, kayata Jmeter, Selenium, Neotys, Gatling, lsp.
Sistem ngawasi Dynatrace ngidini sampeyan njupuk macem-macem metadata saka tes lan ngenali tes sing kalebu siklus rilis lan layanan apa. Disaranake kanggo nambah header tambahan kanggo panjalukan tes HTTP.
Tokoh ing ngisor iki nuduhake conto ing ngendi, nggunakake header tambahan X-Dynatrace-Test, kita nuduhake yen test iki ana hubungane karo testing operasi nambah item menyang cart.
Nalika sampeyan mbukak saben test mbukak, sampeyan ngirim informasi kontekstual tambahan kanggo Dynatrace nggunakake Event API saka CI / server CD. Kanthi cara iki, sistem bisa mbedakake antarane tes sing beda.
. Acara ing sistem ngawasi babagan wiwitan tes beban
Langkah 4-5. Nglumpukake data kinerja lan transfer data menyang sistem CI / CD
Bebarengan karo tes sing digawe, acara dikirim menyang sistem pemantauan babagan kabutuhan ngumpulake data babagan mriksa indikator kualitas layanan. Iki uga nemtokake file JSON kita, sing nemtokake metrik kunci.
Acara babagan kudu mriksa kualitas piranti lunak sing digawe ing server CI / CD kanggo dikirim menyang sistem ngawasi
Ing conto kita, acara mriksa kualitas diarani perfSigDynatraceReport (Performance_Signature) - iki siap kanggo integrasi karo Jenkins, sing dikembangake dening wong lanang saka T-Systems Multimedia Solutions. Saben acara peluncuran tes ngemot informasi babagan layanan, nomer mbangun, lan wektu tes. Plugin ngumpulake nilai kinerja ing wektu mbangun, ngevaluasi, lan mbandhingake asil karo mbangun sadurunge lan syarat non-fungsi.
Acara ing sistem ngawasi babagan wiwitan pamriksa kualitas mbangun.
Sawise tes rampung, kabeh metrik kanggo netepake kualitas piranti lunak ditransfer maneh menyang sistem integrasi sing terus-terusan, contone, Jenkins, sing ngasilake laporan babagan asil.
Asil statistik ing rakitan ing server CI / CD.
Kanggo saben mbangun individu, kita ndeleng statistik kanggo saben metrik sing disetel ing kabeh tes. Kita uga weruh yen ana pelanggaran ing nilai ambang tartamtu (peringatan lan ambang abot). Adhedhasar metrik agregat, kabeh bangunan ditandhani minangka stabil, ora stabil, utawa gagal. Uga, kanggo penak, sampeyan bisa nambah indikator ing laporan sing mbandhingake bangunan saiki karo sing sadurunge.
Deleng statistik rinci babagan rakitan ing server CI / CD.
Perbandingan rinci saka rong majelis
Yen perlu, sampeyan bisa pindhah menyang antarmuka Dynatrace lan ing kana sampeyan bisa ndeleng statistik kanggo saben bangunan sampeyan kanthi luwih rinci lan mbandhingake karo saben liyane.
Perbandingan statistik mbangun ing Dynatrace.
temonan
Akibaté, kita entuk layanan "monitoring minangka layanan", kanthi otomatis ing pipa integrasi sing terus-terusan. Pangembang utawa panguji mung kudu nemtokake dhaptar metrik ing file JSON, lan kabeh liya kedadeyan kanthi otomatis. Kita nampa kontrol kualitas sing transparan kanggo rilis: kabeh kabar babagan kinerja, konsumsi sumber daya utawa regresi arsitektur.
Tugas 2. Otomatisasi kontrol kualitas piranti lunak ing lingkungan produksi
Dadi, kita wis ngrampungake masalah babagan cara ngotomatisasi proses pemantauan ing tahap tes ing Pipeline. Kanthi cara iki, kita nyilikake persentase rakitan berkualitas rendah sing tekan lingkungan produksi.
Nanging apa sing kudu ditindakake yen piranti lunak ala bakal didol, utawa ana sing rusak. Kanggo utopia, kita pengin mekanisme kanggo ndeteksi masalah kanthi otomatis lan, yen bisa, sistem kasebut bisa mulihake fungsine, paling ora ing wayah wengi.
Kanggo nindakake iki, kita kudu, kanthi analogi karo bagean sadurunge, kanggo nyedhiyakake pamriksa kualitas piranti lunak otomatis ing lingkungan produksi lan adhedhasar skenario kanggo marasake awak sistem.
Autocorrect minangka kode
Umume perusahaan wis duwe basis pengetahuan akumulasi babagan macem-macem jinis masalah umum lan dhaptar tumindak kanggo ndandani, contone, miwiti maneh proses, ngresiki sumber daya, muter maneh versi, mulihake owah-owahan konfigurasi sing ora bener, nambah utawa nyuda jumlah komponen ing kluster, ngoper outline biru utawa ijo lan liya-liyane.
Nalika kasus panggunaan iki wis dikenal pirang-pirang taun dening akeh tim sing dakkandhakake, sawetara sing wis mikir utawa nandur modal kanggo ngotomatisasi.
Yen sampeyan mikir babagan iki, ora ana sing rumit banget kanggo ngleksanakake proses kanggo kinerja aplikasi marasake awakmu dhewe; sampeyan kudu nampilake skenario kerja sing wis dingerteni para pangurus sampeyan ing bentuk skrip kode (konsep "fix otomatis minangka kode") , sing sampeyan tulis luwih dhisik kanggo saben kasus tartamtu. Skrip repair otomatis kudu ngarahke ing mbusak sabab ROOT saka masalah. Sampeyan dhewe nemtokake tumindak sing bener kanggo nanggapi kedadeyan.
Sembarang metrik saka sistem pemantauan sampeyan bisa dadi pemicu kanggo miwiti skrip, sing paling penting yaiku metrik kasebut kanthi akurat nemtokake manawa kabeh iku ala, amarga sampeyan ora pengin entuk positip palsu ing lingkungan sing produktif.
Sampeyan bisa nggunakake sistem utawa set sistem apa wae: Prometheus, ELK Stack, Zabbix, lsp. Nanging aku bakal menehi sawetara conto adhedhasar solusi APM (Dynatrace bakal dadi conto maneh) sing uga bakal nggawe urip luwih gampang.
Kaping pisanan, ana kabeh sing ana gandhengane karo kinerja babagan operasi aplikasi. Solusi kasebut nyedhiyakake atusan metrik ing macem-macem tingkat sing bisa digunakake minangka pemicu:
- tingkat pangguna (browser, aplikasi seluler, piranti IoT, prilaku pangguna, konversi, lsp);
- tingkat layanan lan operasi (kinerja, kasedhiyan, kasalahan, etc.);
- tingkat infrastruktur aplikasi (metrik OS host, JMX, MQ, web-server, lsp);
- tingkat platform (virtualisasi, awan, wadhah, lsp).
Tingkat ngawasi ing Dynatrace.
Kapindho, kaya sing dakkandhakake sadurunge, Dynatrace duwe API sing mbukak, sing gampang banget kanggo nggabungake karo macem-macem sistem pihak katelu. Contone, ngirim kabar menyang sistem otomatis nalika parameter kontrol ngluwihi.
Ing ngisor iki minangka conto kanggo sesambungan karo Ansible.
Ing ngisor iki aku bakal menehi sawetara conto babagan otomatisasi apa sing bisa ditindakake. Iki mung bagean saka kasus; dhaptar ing lingkungan sampeyan mung bisa diwatesi dening imajinasi lan kemampuan alat ngawasi sampeyan.
1. Bad masang - versi rollback
Sanajan kita nyoba kabeh kanthi apik ing lingkungan tes, isih ana kemungkinan rilis anyar bisa mateni aplikasi sampeyan ing lingkungan produksi. Faktor manungsa sing padha durung dibatalake.
Ing tokoh ing ngisor iki kita weruh sing ana lompat cetha ing wektu eksekusi operasi ing layanan. Awal lompat iki pas karo wektu penyebaran menyang aplikasi. Kita ngirim kabeh informasi iki minangka acara menyang sistem otomatisasi. Yen kinerja layanan ora bali menyang normal sawise wektu kita nyetel, banjur script otomatis disebut sing muter maneh versi menyang lawas.
Degradasi kinerja operasi sawise penyebaran.
2. Loading sumber daya ing 100% - nambah simpul kanggo nuntun
Ing conto ing ngisor iki, sistem ngawasi nemtokake manawa salah sawijining komponen ngalami beban CPU 100%.
beban CPU 100%
Ana sawetara skenario sing beda kanggo acara iki. Contone, sistem ngawasi uga mriksa manawa kekurangan sumber daya digandhengake karo kenaikan beban ing layanan kasebut. Yen mangkono, skrip dieksekusi kanthi otomatis nambahake simpul menyang nuntun, saéngga mulihake fungsi sistem kanthi sakabehe.
Scaling sawise kedadean
3. Lack saka papan ing hard drive - reresik disk
Aku mikir yen akeh wong sing wis ngotomatisasi proses kasebut. Nggunakake APM, sampeyan uga bisa ngawasi ruang kosong ing subsistem disk. Yen ora ana spasi utawa disk mlaku alon-alon, kita nelpon script kanggo ngresiki utawa nambah spasi.
Beban disk 100%
4. Aktivitas pangguna sing kurang utawa konversi sing sithik - ngalih ing antarane cabang biru lan ijo
Aku kerep ndeleng pelanggan nggunakake rong puteran (biru-ijo nyebar) kanggo aplikasi ing lingkungan produksi. Iki ngidini sampeyan kanthi cepet ngalih ing antarane cabang nalika ngirim rilis anyar. Asring, sawise panyebaran, owah-owahan dramatis bisa kedadeyan sing ora langsung katon. Ing kasus iki, degradasi kinerja lan kasedhiyan bisa uga ora diamati. Kanggo cepet nanggapi owah-owahan kasebut, luwih becik nggunakake macem-macem metrik sing nggambarake prilaku pangguna (jumlah sesi lan tumindak pangguna, konversi, tingkat bouncing). Tokoh ing ngisor iki nuduhake conto sing, nalika tingkat konversi mudhun, ngalih ing antarane cabang piranti lunak kedadeyan.
Tingkat konversi mudhun sawise ngalih ing antarane cabang piranti lunak.
Mekanisme kanggo deteksi masalah otomatis
Pungkasan, aku bakal menehi conto liyane kenapa aku seneng karo Dynatrace.
Ing bagean crita babagan ngotomatisasi pamriksa kualitas rakitan ing lingkungan tes, kita nemtokake kabeh nilai ambang kanthi manual. Iki normal kanggo lingkungan tes; penguji dhewe nemtokake indikator sadurunge saben tes gumantung saka beban. Ing lingkungan produksi, mesthine masalah dideteksi kanthi otomatis, kanthi njupuk macem-macem mekanisme garis dasar.
Dynatrace nduweni alat intelijen buatan sing menarik, adhedhasar mekanisme kanggo nemtokake metrik anomali (baselining) lan mbangun peta interaksi antarane kabeh komponen, mbandhingake lan ngubungake acara siji liyane, nemtokake anomali ing operasi layanan sampeyan lan menehi rincian. informasi babagan saben masalah lan sababe.
Kanthi otomatis nganalisa dependensi antarane komponen, Dynatrace nemtokake ora mung apa layanan masalah iku sabab ROOT, nanging uga gumantung ing layanan liyane. Ing conto ing ngisor iki, Dynatrace kanthi otomatis ngawasi lan ngevaluasi kesehatan saben layanan ing eksekusi transaksi, ngenali layanan Golang minangka panyebab utama.
Conto kanggo nemtokake sabab saka kegagalan.
Tokoh ing ngisor iki nuduhake proses ngawasi masalah karo aplikasi sampeyan wiwit kedadeyan.
Visualisasi masalah sing muncul kanthi nampilake kabeh komponen lan acara
Sistem ngawasi ngumpulake kronologi lengkap acara sing ana gandhengane karo masalah sing muncul. Ing jendhela ing ngisor garis wektu, kita ndeleng kabeh acara utama ing saben komponen. Adhedhasar acara kasebut, sampeyan bisa nyetel tata cara kanggo koreksi otomatis ing wangun skrip kode.
Kajaba iku, aku menehi saran supaya sampeyan nggabungake sistem pemantauan karo Service Desk utawa bug tracker. Nalika ana masalah, pangembang kanthi cepet nampa informasi lengkap kanggo nganalisa ing tingkat kode ing lingkungan produksi.
kesimpulan
Akibaté, kita rampung karo pipo CI / CD kanthi mriksa kualitas piranti lunak otomatis ing Pipeline. Kita nyilikake jumlah rakitan kualitas rendah, nambah linuwih sistem kanthi sakabehe, lan yen sistem isih gagal, kita miwiti mekanisme kanggo mulihake.
Mesthine kudu nandur modal kanggo ngotomatisasi pemantauan kualitas piranti lunak; ora mesthi proses cepet, nanging suwe-suwe bakal metokake woh. Aku nyaranake sing sawise mecahaken kedadean anyar ing lingkungan produksi, sampeyan langsung mikir bab kang monitor kanggo nambah kanggo mriksa ing lingkungan test supaya ora mbangun ala saka njaluk menyang produksi, lan uga nggawe script kanggo mbenerake masalah iki kanthi otomatis.
Muga-muga contoku bakal mbantu sampeyan ing upaya sampeyan. Aku uga bakal kasengsem ndeleng conto metrik sing digunakake kanggo ngetrapake sistem penyembuhan diri.
Source: www.habr.com