Ngayon ang paksa ng DevOps ay nasa hype. Patuloy na Pagsasama at Pipeline ng Paghahatid lahat ay nagpapatupad nito. Ngunit karamihan ay hindi palaging binibigyang pansin ang pagtiyak sa pagiging maaasahan ng mga sistema ng impormasyon sa iba't ibang yugto ng CI/CD Pipeline. Sa artikulong ito gusto kong pag-usapan ang aking karanasan sa pag-automate ng mga pagsusuri sa kalidad ng software at pagpapatupad ng mga posibleng sitwasyon para sa "pagpapagaling sa sarili" nito.
Nagtatrabaho ako bilang isang engineer sa IT service management department ng isang kumpanya . Ang aking pangunahing lugar ng kadalubhasaan ay ang pagpapatupad ng iba't ibang pagganap ng aplikasyon at mga sistema ng pagsubaybay sa availability. Madalas akong nakikipag-usap sa mga customer ng IT mula sa iba't ibang mga segment ng merkado tungkol sa mga kasalukuyang isyu tungkol sa pagsubaybay sa kalidad ng kanilang mga serbisyo sa IT. Ang pangunahing layunin ay i-minimize ang ikot ng oras ng release at pataasin ang dalas ng mga release. Siyempre, lahat ay mabuti: mas maraming release - mas bagong feature - mas nasisiyahang user - mas maraming kita. Ngunit sa katotohanan, ang mga bagay ay hindi palaging gumagana nang maayos. Sa napakataas na rate ng deployment, agad na bumangon ang tanong tungkol sa kalidad ng aming mga release. Kahit na may ganap na automated na pipeline, ang isa sa mga pinakamalaking hamon ay ang paglipat ng mga serbisyo mula sa pagsubok patungo sa produksyon nang hindi naaapektuhan ang uptime ng application at karanasan ng user.
Batay sa mga resulta ng maraming pag-uusap sa mga customer, masasabi kong ilabas ang kontrol sa kalidad, ang problema sa pagiging maaasahan ng aplikasyon at ang posibilidad ng "pagpapagaling sa sarili" nito (halimbawa, pagbabalik sa isang matatag na bersyon) sa iba't ibang yugto ng CI. Ang /CD pipeline ay kabilang sa mga pinakakapana-panabik at nauugnay na mga paksa.
Kamakailan, ako mismo ay nagtrabaho sa panig ng customer - sa serbisyo ng suporta sa software ng online banking application. Ang arkitektura ng aming aplikasyon ay gumamit ng malaking bilang ng mga self-written na microservice. Ang pinakamalungkot na bagay ay hindi lahat ng mga developer ay maaaring makayanan ang mataas na bilis ng pag-unlad; ang kalidad ng ilang mga microservice ay nagdusa, na nagbunga ng mga nakakatawang palayaw para sa kanila at sa kanilang mga tagalikha. May mga kuwento tungkol sa kung saan ginawa ang mga produktong ito.
"Pagbuo ng problema"
Ang mataas na dalas ng mga release at isang malaking bilang ng mga microservice ay nagpapahirap na maunawaan ang pagpapatakbo ng application sa kabuuan, kapwa sa yugto ng pagsubok at sa yugto ng pagpapatakbo. Patuloy na nagaganap ang mga pagbabago at napakahirap kontrolin ang mga ito nang walang mahusay na mga tool sa pagsubaybay. Kadalasan, pagkatapos ng isang gabing paglabas sa umaga, ang mga developer ay nakaupo na parang sa isang powder keg at naghihintay na walang masira, kahit na ang lahat ng mga tseke ay matagumpay sa yugto ng pagsubok.
May isa pang punto. Sa yugto ng pagsubok, ang pag-andar ng software ay nasuri: ang pagpapatupad ng mga pangunahing pag-andar ng application at ang kawalan ng mga error. Nawawala o hindi isinasaalang-alang ang lahat ng aspeto ng application at ang layer ng integration ng qualitative performance assessments. Maaaring hindi masuri ang ilang sukatan. Bilang resulta, kapag nagkaroon ng breakdown sa isang production environment, malalaman lang ito ng technical support department kapag nagsimulang magreklamo ang mga totoong user. Gusto kong bawasan ang epekto ng mababang kalidad na software sa mga end user.
Ang isa sa mga solusyon ay ang pagpapatupad ng mga proseso para sa pagsuri sa kalidad ng software sa iba't ibang yugto ng CI/CD Pipeline, at magdagdag ng iba't ibang mga sitwasyon para sa pagpapanumbalik ng system sa kaganapan ng isang emergency. Naaalala rin namin na mayroon kaming DevOps. Inaasahan ng mga negosyo na makatanggap ng bagong produkto sa lalong madaling panahon. Samakatuwid, ang lahat ng aming mga pagsusuri at script ay dapat na awtomatiko.
Ang gawain ay nahahati sa dalawang bahagi:
- kontrol sa kalidad ng mga asembliya sa yugto ng pagsubok (upang i-automate ang proseso ng paghuli ng mga mababang kalidad na asembliya);
- kontrol sa kalidad ng software sa kapaligiran ng produksyon (mga mekanismo para sa awtomatikong pagtuklas ng mga problema at posibleng mga sitwasyon para sa kanilang pagpapagaling sa sarili).
Tool para sa pagsubaybay at pagkolekta ng mga sukatan
Upang makamit ang mga nakatakdang layunin, kinakailangan ang isang sistema ng pagsubaybay na maaaring makakita ng mga problema at ilipat ang mga ito sa mga sistema ng automation sa iba't ibang yugto ng pipeline ng CI/CD. Magiging isang positibong bagay din kung ang sistemang ito ay nagbibigay ng mga kapaki-pakinabang na sukatan para sa iba't ibang mga koponan: pag-unlad, pagsubok, pagpapatakbo. At ito ay talagang kahanga-hanga kung ito ay para din sa negosyo.
Upang mangolekta ng mga sukatan, maaari kang gumamit ng isang hanay ng iba't ibang mga system (Prometheus, ELK Stack, Zabbix, atbp.), ngunit, sa palagay ko, ang mga solusyon sa klase ng APM ay pinakaangkop para sa mga gawaing ito (), na maaaring lubos na gawing simple ang iyong buhay.
Bilang bahagi ng aking trabaho sa serbisyo ng suporta, nagsimula akong gumawa ng katulad na proyekto gamit ang isang solusyon sa klase ng APM mula sa Dynatrace. Ngayon, nagtatrabaho para sa isang integrator, alam ko nang mabuti ang merkado ng mga sistema ng pagsubaybay. Ang aking pansariling opinyon: Ang Dynatrace ay pinakaangkop para sa paglutas ng mga naturang problema.
Nagbibigay ang Dynatrace ng pahalang na view ng bawat operasyon ng user sa isang butil-butil na antas hanggang sa antas ng pagpapatupad ng code. Maaari mong subaybayan ang buong kadena ng pakikipag-ugnayan sa pagitan ng iba't ibang serbisyo ng impormasyon: mula sa front-end na antas ng web at mga mobile application, back-end na mga server ng application, integration bus hanggang sa isang partikular na tawag sa database.
. Awtomatikong pagbuo ng lahat ng mga dependency sa pagitan ng mga bahagi ng system
. Awtomatikong pagtuklas at pagtatayo ng landas ng pagpapatakbo ng serbisyo
Natatandaan din namin na kailangan naming isama sa iba't ibang mga tool sa automation. Dito ang solusyon ay may maginhawang API na nagbibigay-daan sa iyong magpadala at tumanggap ng iba't ibang sukatan at kaganapan.
Susunod, lumipat tayo sa isang mas detalyadong pagtingin sa kung paano lutasin ang mga problemang ito gamit ang Dynatrace system.
Gawain 1. Automation ng quality control ng mga assemblies sa testing stage
Ang unang hamon ay ang paghahanap ng mga problema sa lalong madaling panahon sa pipeline ng paghahatid ng aplikasyon. Tanging "magandang" code build ang dapat umabot sa produksyon. Upang gawin ito, ang iyong pipeline sa yugto ng pagsubok ay dapat magsama ng mga karagdagang monitor upang suriin ang kalidad ng iyong mga serbisyo.
Tingnan natin ang hakbang-hakbang na pagtingin sa kung paano ipatupad ito at i-automate ang prosesong ito:
Ipinapakita ng figure ang daloy ng mga automated na hakbang sa pagsubok ng kalidad ng software:
- pag-deploy ng isang sistema ng pagsubaybay (pag-install ng mga ahente);
- pagtukoy ng mga kaganapan para sa pagtatasa ng kalidad ng iyong software (mga sukatan at mga halaga ng threshold) at paglilipat ng mga ito sa sistema ng pagsubaybay;
- pagbuo ng mga pagsubok sa pagkarga at pagganap;
- pagkolekta ng data ng pagganap at kakayahang magamit sa sistema ng pagsubaybay;
- paglilipat ng data ng pagsubok batay sa mga kaganapan sa pagtatasa ng kalidad ng software mula sa monitoring system patungo sa CI/CD system. Awtomatikong pagsusuri ng mga pagtitipon.
Hakbang 1. Deployment ng monitoring system
Una kailangan mong i-install ang mga ahente sa iyong kapaligiran sa pagsubok. Kasabay nito, ang solusyon ng Dynatrace ay may magandang tampok - ginagamit nito ang unibersal na ahente na OneAgent, na naka-install sa isang halimbawa ng OS (Windows, Linux, AIX), awtomatikong nakikita ang iyong mga serbisyo at nagsimulang mangolekta ng data ng pagsubaybay sa mga ito. Hindi mo kailangang mag-configure ng hiwalay na ahente para sa bawat proseso. Magiging katulad ang sitwasyon para sa cloud at container platform. Kasabay nito, maaari mo ring i-automate ang proseso ng pag-install ng ahente. Ang Dynatrace ay akma sa konsepto ng "imprastraktura bilang code" (): May mga handa nang script at tagubilin para sa lahat ng sikat na platform. I-embed mo ang ahente sa configuration ng iyong serbisyo, at kapag na-deploy mo ito, makakatanggap ka kaagad ng bagong serbisyo kasama ang isang nagtatrabaho nang ahente.
Hakbang 2: Tukuyin ang iyong mga kaganapan sa kalidad ng software
Ngayon ay kailangan mong magpasya sa listahan ng mga serbisyo at pagpapatakbo ng negosyo. Mahalagang isaalang-alang nang eksakto ang mga operasyon ng user na kritikal sa negosyo para sa iyong serbisyo. Dito inirerekumenda ko ang pagkonsulta sa mga analyst ng negosyo at system.
Susunod, kailangan mong tukuyin kung aling mga sukatan ang gusto mong isama sa pagsusuri para sa bawat antas. Halimbawa, ito ay maaaring oras ng pagpapatupad (nahati sa average, median, percentiles, atbp.), mga error (lohikal, serbisyo, imprastraktura, atbp.) at iba't ibang sukatan ng imprastraktura (memory heap, basurero, bilang ng thread, atbp.).
Para sa automation at kadalian ng paggamit ng DevOps team, lumalabas ang konsepto ng "Pagsubaybay bilang Code." Ang ibig kong sabihin dito ay ang isang developer/tester ay maaaring magsulat ng isang simpleng JSON file na tumutukoy sa mga sukatan ng kasiguruhan sa kalidad ng software.
Tingnan natin ang isang halimbawa ng naturang JSON file. Ang mga bagay mula sa Dynatrace API ay ginagamit bilang mga pares ng susi/halaga (matatagpuan ang paglalarawan ng API dito ).
{
"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
}
]
}Ang file ay isang hanay ng mga kahulugan ng serye ng oras:
- timeseriesId – ang sukatan na sinusuri, halimbawa, Oras ng Pagtugon, Bilang ng error, Memory na ginamit, atbp.;
- pagsasama-sama - antas ng pagsasama-sama ng mga sukatan, sa aming kaso avg, ngunit maaari mong gamitin ang alinmang kailangan mo (avg, min, max, sum, count, percentile);
- mga tag - object tag sa sistema ng pagsubaybay, o maaari mong tukuyin ang isang partikular na object identifier;
- malubha at babala – kinokontrol ng mga indicator na ito ang mga halaga ng threshold ng aming mga sukatan; kung ang halaga ng pagsubok ay lumampas sa matinding threshold, kung gayon ang aming build ay mamarkahan bilang hindi matagumpay.
Ang sumusunod na figure ay nagpapakita ng isang halimbawa ng paggamit ng naturang mga threshold.
Hakbang 3: Pagbuo ng Pag-load
Kapag natukoy na namin ang mga antas ng kalidad ng aming serbisyo, kailangan naming bumuo ng test load. Maaari mong gamitin ang alinman sa mga tool sa pagsubok na komportable ka, tulad ng Jmeter, Selenium, Neotys, Gatling, atbp.
Ang sistema ng pagsubaybay ng Dynatrace ay nagbibigay-daan sa iyo na kumuha ng iba't ibang metadata mula sa iyong mga pagsubok at kilalanin kung aling mga pagsubok ang nabibilang sa kung aling ikot ng paglabas at kung aling serbisyo. Inirerekomenda na magdagdag ng mga karagdagang header sa mga kahilingan sa pagsubok ng HTTP.
Ang sumusunod na figure ay nagpapakita ng isang halimbawa kung saan, gamit ang karagdagang header na X-Dynatrace-Test, ipinapahiwatig namin na ang pagsubok na ito ay nauugnay sa pagsubok sa pagpapatakbo ng pagdaragdag ng isang item sa cart.
Kapag pinatakbo mo ang bawat pagsubok sa pag-load, magpapadala ka ng karagdagang impormasyon sa konteksto sa Dynatrace gamit ang Event API mula sa CI/CD server. Sa ganitong paraan, maaring magkaiba ang system sa pagitan ng iba't ibang pagsubok.
. Kaganapan sa monitoring system tungkol sa pagsisimula ng load testing
Hakbang 4-5. Kolektahin ang data ng pagganap at ilipat ang data sa CI/CD system
Kasama ang nabuong pagsubok, ang isang kaganapan ay ipinadala sa sistema ng pagsubaybay tungkol sa pangangailangan na mangolekta ng data sa pagsuri sa mga tagapagpahiwatig ng kalidad ng serbisyo. Tinutukoy din nito ang aming JSON file, na tumutukoy sa mga pangunahing sukatan.
Kaganapan tungkol sa pangangailangang suriin ang kalidad ng software na nabuo sa CI/CD server para sa pagpapadala sa monitoring system
Sa aming halimbawa, tinatawag ang kaganapan ng pagsusuri sa kalidad perfSigDynatraceReport (Pagganap_Lagda) - ito ay handa na para sa pagsasama sa Jenkins, na binuo ng mga lalaki mula sa T-Systems Multimedia Solutions. Ang bawat kaganapan sa paglulunsad ng pagsubok ay naglalaman ng impormasyon tungkol sa serbisyo, numero ng build, at oras ng pagsubok. Kinokolekta ng plugin ang mga halaga ng pagganap sa oras ng pagbuo, sinusuri ang mga ito, at inihahambing ang resulta sa mga nakaraang build at hindi gumaganang mga kinakailangan.
Kaganapan sa sistema ng pagsubaybay tungkol sa pagsisimula ng pagsusuri sa kalidad ng build.
Pagkatapos makumpleto ang pagsubok, ang lahat ng sukatan para sa pagtatasa ng kalidad ng software ay ililipat pabalik sa isang tuluy-tuloy na sistema ng pagsasama, halimbawa, Jenkins, na bumubuo ng isang ulat sa mga resulta.
Ang resulta ng mga istatistika sa mga pagtitipon sa CI/CD server.
Para sa bawat indibidwal na build, nakikita namin ang mga istatistika para sa bawat sukatan na itinakda namin sa buong pagsubok. Nakikita rin namin kung may mga paglabag sa ilang partikular na halaga ng threshold (babala at matinding thrashhold). Batay sa mga pinagsama-samang sukatan, ang buong build ay minarkahan bilang stable, hindi matatag, o nabigo. Gayundin, para sa kaginhawahan, maaari kang magdagdag ng mga tagapagpahiwatig sa ulat na naghahambing ng kasalukuyang build sa nauna.
Tingnan ang mga detalyadong istatistika sa mga pagtitipon sa CI/CD server.
Detalyadong paghahambing ng dalawang asembliya
Kung kinakailangan, maaari kang pumunta sa interface ng Dynatrace at doon maaari mong tingnan ang mga istatistika para sa bawat isa sa iyong mga build nang mas detalyado at ihambing ang mga ito sa isa't isa.
Paghahambing ng mga istatistika ng build sa Dynatrace.
Natuklasan
Bilang resulta, nakakakuha kami ng serbisyong "pagsubaybay bilang isang serbisyo", na awtomatiko sa tuluy-tuloy na pipeline ng pagsasama. Kailangan lang ng developer o tester na tumukoy ng listahan ng mga sukatan sa isang JSON file, at lahat ng iba pa ay awtomatikong nangyayari. Nakatanggap kami ng malinaw na kontrol sa kalidad ng mga release: lahat ng mga abiso tungkol sa pagganap, pagkonsumo ng mapagkukunan o mga regression sa arkitektura.
Gawain 2. Automation ng software quality control sa isang production environment
Kaya, nalutas namin ang problema kung paano i-automate ang proseso ng pagsubaybay sa yugto ng pagsubok sa Pipeline. Sa ganitong paraan, binabawasan namin ang porsyento ng mga mababang kalidad na asembliya na umaabot sa kapaligiran ng produksyon.
Ngunit ano ang gagawin kung ang masamang software ay napagbili, o may nasira lang. Para sa isang utopia, gusto namin ng mga mekanismo na awtomatikong makakita ng mga problema at, kung maaari, ang system mismo ay ibalik ang paggana nito, kahit sa gabi.
Upang gawin ito, kailangan namin, sa pamamagitan ng pagkakatulad sa nakaraang seksyon, upang magbigay ng mga awtomatikong pagsusuri sa kalidad ng software sa kapaligiran ng produksyon at ibase ang mga ito sa mga sitwasyon para sa self-healing ng system.
Autocorrect bilang code
Karamihan sa mga kumpanya ay mayroon nang naipon na base ng kaalaman sa iba't ibang uri ng karaniwang mga problema at isang listahan ng mga aksyon upang ayusin ang mga ito, halimbawa, pag-restart ng mga proseso, paglilinis ng mga mapagkukunan, pag-roll back ng mga bersyon, pagpapanumbalik ng mga hindi wastong pagbabago sa configuration, pagtaas o pagbaba ng bilang ng mga bahagi sa ang cluster, pagpapalit ng asul o berdeng outline at iba pa.
Bagama't ang mga kaso ng paggamit na ito ay kilala sa loob ng maraming taon ng marami sa mga team na kausap ko, kakaunti ang nag-isip o namuhunan sa pag-automate ng mga ito.
Kung iisipin mo, walang masyadong kumplikado sa pagpapatupad ng mga proseso para sa pagpapagaling sa sarili na pagganap ng aplikasyon; kailangan mong ipakita ang mga kilalang sitwasyon ng trabaho ng iyong mga administrator sa anyo ng mga script ng code (ang konsepto ng "auto-fix bilang code") , na isinulat mo nang maaga para sa bawat partikular na kaso. Ang mga awtomatikong script ng pag-aayos ay dapat na naglalayong alisin ang ugat na sanhi ng problema. Ikaw mismo ang nagdedetermina ng mga tamang aksyon para tumugon sa isang insidente.
Anumang sukatan mula sa iyong monitoring system ay maaaring kumilos bilang isang trigger upang ilunsad ang script, ang pangunahing bagay ay ang mga sukatan na ito ay tumpak na tinutukoy na ang lahat ay masama, dahil hindi mo nais na makakuha ng mga maling positibo sa isang produktibong kapaligiran.
Maaari kang gumamit ng anumang system o hanay ng mga system: Prometheus, ELK Stack, Zabbix, atbp. Ngunit magbibigay ako ng ilang mga halimbawa batay sa isang APM solution (Dynatrace will be an example again) na makakatulong din na gawing mas madali ang iyong buhay.
Una, mayroong lahat ng nauugnay sa pagganap sa mga tuntunin ng pagpapatakbo ng application. Nagbibigay ang solusyon ng daan-daang sukatan sa iba't ibang antas na magagamit mo bilang mga trigger:
- antas ng user (mga browser, mobile application, IoT device, gawi ng user, conversion, atbp.);
- antas ng serbisyo at pagpapatakbo (pagganap, kakayahang magamit, mga error, atbp.);
- antas ng imprastraktura ng application (mga sukatan ng host OS, JMX, MQ, web-server, atbp.);
- antas ng platform (virtualization, cloud, container, atbp.).
Mga antas ng pagsubaybay sa Dynatrace.
Pangalawa, tulad ng sinabi ko kanina, ang Dynatrace ay may bukas na API, na ginagawang napakadaling isama sa iba't ibang mga third-party system. Halimbawa, ang pagpapadala ng abiso sa sistema ng automation kapag nalampasan ang mga parameter ng kontrol.
Nasa ibaba ang isang halimbawa para sa pakikipag-ugnayan sa Ansible.
Sa ibaba ay magbibigay ako ng ilang mga halimbawa kung anong uri ng automation ang maaaring gawin. Ito ay bahagi lamang ng mga kaso; ang kanilang listahan sa iyong kapaligiran ay maaaring limitado lamang ng iyong imahinasyon at ang mga kakayahan ng iyong mga tool sa pagsubaybay.
1. Masamang pag-deploy – rollback ng bersyon
Kahit na sinubukan namin ang lahat nang napakahusay sa isang kapaligiran ng pagsubok, may pagkakataon pa rin na maaaring patayin ng isang bagong release ang iyong aplikasyon sa isang kapaligiran ng produksyon. Ang parehong kadahilanan ng tao ay hindi nakansela.
Sa sumusunod na figure nakita namin na mayroong isang matalim na pagtalon sa oras ng pagpapatupad ng mga operasyon sa serbisyo. Ang simula ng pagtalon na ito ay kasabay ng oras ng pag-deploy sa application. Ipinapadala namin ang lahat ng impormasyong ito bilang mga kaganapan sa sistema ng automation. Kung ang pagganap ng serbisyo ay hindi bumalik sa normal pagkatapos ng oras na itinakda namin, pagkatapos ay awtomatikong tatawagin ang isang script na magpapabalik sa bersyon sa luma.
Pagbaba ng pagganap ng mga operasyon pagkatapos ng pag-deploy.
2. Naglo-load ng mapagkukunan sa 100% - magdagdag ng node sa pagruruta
Sa sumusunod na halimbawa, tinutukoy ng sistema ng pagsubaybay na ang isa sa mga bahagi ay nakakaranas ng 100% na pag-load ng CPU.
CPU load 100%
Mayroong ilang iba't ibang mga senaryo na posible para sa kaganapang ito. Halimbawa, tinitingnan din ng sistema ng pagsubaybay kung ang kakulangan ng mga mapagkukunan ay nauugnay sa pagtaas ng pagkarga sa serbisyo. Kung gayon, pagkatapos ay ang isang script ay isinasagawa na awtomatikong nagdaragdag ng isang node sa pagruruta, at sa gayon ay ibabalik ang paggana ng system sa kabuuan.
Pagsusukat pagkatapos ng isang insidente
3. Kakulangan ng espasyo sa hard drive - paglilinis ng disk
Sa tingin ko, marami nang tao ang nag-automate na sa mga prosesong ito. Gamit ang APM, maaari mo ring subaybayan ang libreng espasyo sa disk subsystem. Kung walang espasyo o mabagal na tumatakbo ang disk, tatawag kami ng script para linisin ito o magdagdag ng espasyo.
Disc load 100%
4. Mababang aktibidad ng user o mababang conversion - paglipat sa pagitan ng asul at berdeng mga sanga
Madalas kong nakikita ang mga customer na gumagamit ng dalawang loop (blue-green deploy) para sa mga application sa isang production environment. Nagbibigay-daan ito sa iyong mabilis na lumipat sa pagitan ng mga sangay kapag naghahatid ng mga bagong release. Kadalasan, pagkatapos ng pag-deploy, maaaring mangyari ang mga dramatikong pagbabago na hindi agad napapansin. Sa kasong ito, maaaring hindi maobserbahan ang pagkasira sa performance at availability. Upang mabilis na tumugon sa mga naturang pagbabago, mas mainam na gumamit ng iba't ibang sukatan na nagpapakita ng gawi ng user (bilang ng mga session at pagkilos ng user, conversion, bounce rate). Ang sumusunod na figure ay nagpapakita ng isang halimbawa kung saan, kapag bumaba ang mga rate ng conversion, nagaganap ang paglipat sa pagitan ng mga sangay ng software.
Bumababa ang rate ng conversion pagkatapos lumipat sa pagitan ng mga sangay ng software.
Mga mekanismo para sa awtomatikong pagtuklas ng problema
Sa wakas, bibigyan kita ng isa pang halimbawa kung bakit pinakagusto ko ang Dynatrace.
Sa bahagi ng aking kwento tungkol sa pag-automate ng mga pagsusuri sa kalidad ng mga asembliya sa isang kapaligiran ng pagsubok, natukoy namin nang manu-mano ang lahat ng mga halaga ng threshold. Normal ito para sa isang kapaligiran ng pagsubok; ang tester mismo ang tumutukoy sa mga tagapagpahiwatig bago ang bawat pagsubok depende sa pagkarga. Sa isang kapaligiran ng produksyon, ito ay kanais-nais na ang mga problema ay awtomatikong nakita, na isinasaalang-alang ang iba't ibang mga mekanismo ng baseline.
Ang Dynatrace ay may kawili-wiling built-in na mga tool sa artificial intelligence na, batay sa mga mekanismo para sa pagtukoy ng mga maanomalyang sukatan (baselining) at pagbuo ng isang mapa ng pakikipag-ugnayan sa pagitan ng lahat ng mga bahagi, paghahambing at pag-uugnay ng mga kaganapan sa isa't isa, tinutukoy ang mga anomalya sa pagpapatakbo ng iyong serbisyo at nagbibigay ng detalyadong impormasyon sa bawat problema at ugat na sanhi.
Sa pamamagitan ng awtomatikong pagsusuri sa mga dependency sa pagitan ng mga bahagi, tinutukoy ng Dynatrace hindi lamang kung ang problemang serbisyo ang pangunahing sanhi, kundi pati na rin ang dependency nito sa iba pang mga serbisyo. Sa halimbawa sa ibaba, awtomatikong sinusubaybayan at sinusuri ng Dynatrace ang kalusugan ng bawat serbisyo sa loob ng pagpapatupad ng transaksyon, na tinutukoy ang serbisyo ng Golang bilang pangunahing dahilan.
Isang halimbawa ng pagtukoy sa ugat ng isang pagkabigo.
Ipinapakita ng sumusunod na figure ang proseso ng pagsubaybay sa mga problema sa iyong aplikasyon mula sa simula ng isang insidente.
Visualization ng isang umuusbong na problema sa pagpapakita ng lahat ng mga bahagi at kaganapan sa mga ito
Ang sistema ng pagsubaybay ay nakolekta ng isang kumpletong kronolohiya ng mga kaganapan na may kaugnayan sa problemang lumitaw. Sa window sa ibaba ng timeline, makikita natin ang lahat ng mahahalagang kaganapan sa bawat isa sa mga bahagi. Batay sa mga kaganapang ito, maaari kang magtakda ng mga pamamaraan para sa awtomatikong pagwawasto sa anyo ng mga script ng code.
Bukod pa rito, ipinapayo ko sa iyo na isama ang isang monitoring system sa Service Desk o isang bug tracker. Kapag nagkaroon ng problema, mabilis na nakakatanggap ang mga developer ng kumpletong impormasyon upang pag-aralan ito sa antas ng code sa kapaligiran ng produksyon.
Konklusyon
Bilang resulta, napunta kami sa isang pipeline ng CI/CD na may built-in na awtomatikong pagsusuri sa kalidad ng software sa Pipeline. Pinaliit namin ang bilang ng mga mababang-kalidad na asembliya, pinapataas ang pagiging maaasahan ng system sa kabuuan, at kung nabigo pa rin ang aming system, naglulunsad kami ng mga mekanismo para ibalik ito.
Talagang sulit na mag-invest ng pagsisikap sa pag-automate ng pagsubaybay sa kalidad ng software; hindi ito palaging isang mabilis na proseso, ngunit sa paglipas ng panahon ay magbubunga ito. Inirerekomenda ko na pagkatapos malutas ang isang bagong insidente sa kapaligiran ng produksyon, agad mong pag-isipan kung aling mga monitor ang idaragdag para sa mga pagsusuri sa kapaligiran ng pagsubok upang maiwasan ang masamang build mula sa pagpasok sa produksyon, at lumikha din ng script upang awtomatikong itama ang mga problemang ito.
Umaasa ako na ang aking mga halimbawa ay makakatulong sa iyo sa iyong mga pagsisikap. Magiging interesado rin akong makita ang iyong mga halimbawa ng mga sukatan na ginamit upang ipatupad ang mga self-healing system.
Pinagmulan: www.habr.com