Mojawapo ya matatizo ambayo wachuuzi wa programu za bidhaa nyingi mara nyingi hukabiliana nayo ni kurudiwa kwa uwezo wa wahandisi - watengenezaji, wajaribu, na wasimamizi wa miundombinu - kwa karibu kila timu. Hii inatumika pia kwa wahandisi wa gharama kubwa - wataalam katika uwanja wa upimaji wa mzigo.
Badala ya kufanya majukumu yao ya moja kwa moja na kutumia uzoefu wao wa kipekee kuunda mchakato wa kupima mzigo, chagua mbinu, vipimo bora zaidi na uandike majaribio ya kiotomatiki kwa mujibu wa wasifu wa upakiaji, mara nyingi wahandisi hulazimika kupeleka miundombinu ya majaribio kuanzia mwanzo, kusanidi zana za upakiaji na kuzipachika. wenyewe katika mifumo ya CI, kuanzisha ufuatiliaji na uchapishaji wa ripoti.
Unaweza kupata suluhu kwa baadhi ya matatizo ya shirika katika majaribio tunayotumia katika Positive Technologies in . Na katika hii, nitazungumza juu ya uwezekano wa kujumuisha vipimo vya mzigo kwenye bomba la kawaida la CI kwa kutumia wazo la "upimaji wa mzigo kama huduma" (upimaji wa mzigo kama huduma). Utajifunza jinsi na picha gani za docker za vyanzo vya mzigo zinaweza kutumika kwenye bomba la CI; jinsi ya kuunganisha vyanzo vya upakiaji kwa mradi wako wa CI kwa kutumia kiolezo cha ujenzi; jinsi bomba la onyesho linavyoonekana kwa kufanya majaribio ya upakiaji na kuchapisha matokeo. Nakala hiyo inaweza kuwa muhimu kwa wahandisi wa majaribio ya programu na wahandisi wa otomatiki katika CI ambao wanafikiria juu ya usanifu wa mfumo wao wa upakiaji.
Kiini cha dhana
Dhana ya kupima upakiaji kama huduma inamaanisha uwezo wa kuunganisha zana za kupakia Apache JMeter, Yandex.Tank na mifumo yako mwenyewe kwenye mfumo wa ujumuishaji unaoendelea bila mpangilio. Onyesho litakuwa la GitLab CI, lakini kanuni ni za kawaida kwa mifumo yote ya CI.
Upimaji wa mzigo kama huduma ni huduma ya kati kwa ajili ya kupima mzigo. Majaribio ya upakiaji hufanywa katika vikundi maalum vya wakala, matokeo huchapishwa kiotomatiki katika Kurasa za GitLab, Influx DB na Grafana au katika mifumo ya kuripoti majaribio (TestRail, ReportPortal, n.k.). Otomatiki na kuongeza hutekelezwa kwa urahisi iwezekanavyo - kwa kuongeza na kuweka vigezo vya kiolezo cha kawaida cha gitlab-ci.yml katika mradi wa GitLab CI.
Faida ya mbinu hii ni kwamba miundombinu yote ya CI, mawakala wa mizigo, picha za docker za vyanzo vya mizigo, mabomba ya kupima, na ripoti za uchapishaji hudumishwa na idara ya kati ya automatisering (wahandisi wa DevOps), wakati wahandisi wa kupima mzigo wanaweza kuelekeza juhudi zao kwenye maendeleo ya mtihani. na uchambuzi wa matokeo yao, bila kushughulikia masuala ya miundombinu.
Kwa urahisi wa maelezo, tutafikiri kwamba programu au seva inayolengwa tayari imetumwa na kusanidiwa mapema (hati za kiotomatiki katika Python, SaltStack, Ansible, n.k. zinaweza kutumika kwa hili). Halafu wazo zima la upimaji wa mzigo kama huduma inafaa katika hatua tatu: maandalizi, upimaji, uchapishaji wa ripoti. Maelezo zaidi kwenye mchoro (picha zote zinaweza kubofya):
Dhana za kimsingi na ufafanuzi katika upimaji wa mzigo
Wakati wa kufanya vipimo vya mzigo, tunajaribu kuzingatia , tumia istilahi zinazofaa na vipimo vinavyopendekezwa. Nitatoa orodha fupi ya dhana kuu na ufafanuzi katika upimaji wa mzigo.
Wakala wa mzigo - mashine ya kawaida ambayo maombi itazinduliwa - chanzo cha mzigo (Apache JMeter, Yandex.Tank au moduli ya mzigo iliyoandikwa binafsi).
Lengo la mtihani (lengo) - seva au programu imewekwa kwenye seva ambayo itakuwa chini ya kupakiwa.
Hali ya jaribio (kesi ya mtihani) - seti ya hatua za parameterized: vitendo vya mtumiaji na athari zinazotarajiwa kwa vitendo hivi, na maombi ya kudumu ya mtandao na majibu, kulingana na vigezo maalum.
Wasifu au mpango wa upakiaji (wasifu) - ndani (Sehemu ya 4.2.4, uk. 43) wasifu wa kupakia hufafanua vipimo ambavyo ni muhimu kwa jaribio fulani na chaguo za kubadilisha vigezo vya upakiaji wakati wa jaribio. Unaweza kuona mifano ya wasifu kwenye takwimu.
Mtihani - hati iliyo na seti iliyoamuliwa mapema ya vigezo.
Mpango wa majaribio (mpango wa majaribio) - seti ya vipimo na wasifu wa mzigo.
Testran (testrun) - marudio moja ya kufanya jaribio moja na hali ya upakiaji iliyotekelezwa kikamilifu na ripoti iliyopokelewa.
Ombi la mtandao (ombi) - Ombi la HTTP lililotumwa kutoka kwa wakala kwenda kwa mlengwa.
Majibu ya mtandao (majibu) - Jibu la HTTP lililotumwa kutoka kwa lengo hadi kwa wakala.
Msimbo wa majibu wa HTTP (hali ya majibu ya HTTP) - msimbo wa kawaida wa majibu kutoka kwa seva ya programu.
Muamala ni mzunguko kamili wa majibu ya ombi. Shughuli inahesabiwa tangu mwanzo wa kutuma ombi (ombi) hadi kukamilika kwa kupokea jibu (jibu).
Hali ya muamala - ikiwa iliwezekana kukamilisha mzunguko wa majibu ya ombi. Ikiwa kulikuwa na hitilafu yoyote katika mzunguko huu, basi shughuli nzima inachukuliwa kuwa haikufaulu.
Muda wa kujibu (muda wa kusubiri) - wakati kutoka mwisho wa kutuma ombi (ombi) hadi mwanzo wa kupokea jibu (jibu).
Pakia vipimo - sifa za huduma iliyopakiwa na wakala wa mzigo kuamua katika mchakato wa kupima mzigo.
Vipimo vya msingi vya kupima vigezo vya mzigo
Baadhi ya zinazotumiwa sana na zinazopendekezwa katika mbinu (uk. 36, 52) vipimo vimeonyeshwa kwenye jedwali lililo hapa chini. Vipimo sawa vya wakala na walengwa vimeorodheshwa kwenye mstari sawa.
Vipimo vya wakala wa upakiaji
Vipimo vya mfumo lengwa au programu inayojaribiwa chini ya upakiaji
Idadi vCPU na kumbukumbu RAM,
Disk - sifa za "chuma" za wakala wa mzigo
CPU, Kumbukumbu, matumizi ya Disk - mienendo ya CPU, kumbukumbu na upakiaji wa diski
katika mchakato wa majaribio. Kawaida hupimwa kama asilimia ya
viwango vya juu vinavyopatikana
upitishaji wa mtandao (kwenye wakala wa mzigo) - throughput
interface ya mtandao kwenye seva,
ambapo wakala wa mzigo umewekwa.
Kawaida hupimwa kwa baiti kwa sekunde (bps)
upitishaji wa mtandao(juu ya lengo) - bandwidth ya interface ya mtandao
kwenye seva inayolengwa. Kawaida hupimwa kwa baiti kwa sekunde (bps)
Watumiaji wa mtandaoni- idadi ya watumiaji wa mtandaoni,
kutekeleza matukio ya mzigo na
kuiga vitendo halisi vya mtumiaji
Hali ya watumiaji wa mtandaoni, Imepita/Imeshindwa/Jumla - idadi ya waliofaulu na
hali zisizofanikiwa za watumiaji pepe
kwa matukio ya mzigo, pamoja na idadi yao jumla.
Kwa ujumla inatarajiwa kwamba watumiaji wote waliweza kukamilisha
kazi zako zote zilizobainishwa kwenye wasifu wa upakiaji.
Hitilafu yoyote itamaanisha kuwa mtumiaji halisi hataweza
kutatua tatizo lako wakati wa kufanya kazi na mfumo
Maombi kwa sekunde (dakika)- idadi ya maombi ya mtandao kwa sekunde (au dakika).
Tabia muhimu ya wakala wa mzigo ni maombi mangapi ambayo inaweza kutoa.
Kwa kweli, huu ni uigaji wa ufikiaji wa programu na watumiaji wa kawaida
Majibu kwa sekunde (dakika)
- idadi ya majibu ya mtandao kwa sekunde (au dakika).
Tabia muhimu ya huduma inayolengwa: ni kiasi gani
kuzalisha na kutuma majibu kwa maswali na
wakala wa upakiaji
Hali ya majibu ya HTTP- idadi ya misimbo tofauti ya majibu
kutoka kwa seva ya programu iliyopokelewa na wakala wa upakiaji.
Kwa mfano, 200 OK inamaanisha simu iliyofanikiwa,
na 404 - kwamba rasilimali haikupatikana
Ukamilifu (wakati wa majibu) - wakati kutoka mwisho
kutuma ombi (ombi) kabla ya kuanza kupokea jibu (majibu).
Kawaida hupimwa kwa milisekunde (ms)
Muda wa majibu ya muamala- wakati wa shughuli moja kamili,
kukamilika kwa mzunguko wa majibu ya ombi.
Huu ni wakati tangu mwanzo wa kutuma ombi (ombi)
hadi kukamilika kwa kupokea majibu (majibu).
Muda wa muamala unaweza kupimwa kwa sekunde (au dakika)
kwa njia kadhaa: fikiria kiwango cha chini,
upeo, wastani na, kwa mfano, asilimia 90.
Usomaji wa kiwango cha chini na wa juu ni uliokithiri
hali ya utendaji wa mfumo.
Asilimia ya tisini ndiyo inayotumika sana,
kama inavyoonyesha watumiaji wengi,
kufanya kazi kwa urahisi kwenye kizingiti cha utendaji wa mfumo
Shughuli kwa sekunde (dakika) - idadi kamili
shughuli kwa sekunde (dakika),
yaani ni kiasi gani maombi yaliweza kukubali na
kushughulikia maombi na kutoa majibu.
Kwa kweli, hii ni matokeo ya mfumo
Hali ya muamala , Imepita / Imeshindwa / Jumla - nambari
iliyofanikiwa, haijafaulu na jumla ya idadi ya miamala.
Kwa watumiaji halisi haikufaulu
muamala utamaanisha kweli
kutokuwa na uwezo wa kufanya kazi na mfumo chini ya mzigo
Mchoro wa Mpangilio wa Kupima Mzigo
Wazo la upimaji wa mzigo ni rahisi sana na lina hatua kuu tatu, ambazo tayari nimezitaja: Tayarisha-Ripoti ya Mtihani, yaani, kuandaa malengo ya mtihani na kuweka vigezo kwa vyanzo vya mzigo, kisha kutekeleza vipimo vya mzigo na, mwishoni, kuzalisha na kuchapisha ripoti ya mtihani.
Vidokezo vya kimkakati:
- QA.Tester ni mtaalamu wa kupima mzigo,
- Lengo ni programu inayolengwa ambayo unataka kujua tabia yake chini ya mzigo.
Ainisho ya vyombo, hatua na hatua kwenye mchoro
Hatua na hatua
Nini kinaendelea
Kuna nini mlangoni
Pato ni nini
Tayarisha: hatua ya maandalizi kwa ajili ya kupima
LoadParameters
Kuweka na kuanzisha
mtumiaji
vigezo vya mzigo,
uchaguzi wa vipimo na
maandalizi ya mpango wa mtihani
(pakia wasifu)
Chaguzi maalum za
uanzishaji wa wakala wa kupakia
Mpango wa mtihani
Kusudi la majaribio
VM
Usambazaji wa wingu
mashine virtual na
sifa zinazohitajika
Mipangilio ya VM ya wakala wa upakiaji
Maandishi ya otomatiki kwa
Uundaji wa VM
VM imeundwa ndani
wingu
Heshima
Usanidi na maandalizi ya OS
mazingira kwa
kazi ya wakala wa mzigo
Mipangilio ya mazingira kwa
wakala wa mzigo
Maandishi ya otomatiki kwa
mipangilio ya mazingira
Mazingira yaliyotayarishwa:
OS, huduma na maombi,
muhimu kwa kazi
wakala wa mzigo
LoadAgents
Ufungaji, usanidi na parameterization
wakala wa upakiaji.
Au kupakua picha ya kizimbani kutoka
chanzo cha upakiaji kilichosanidiwa awali
Pakia picha ya kituo cha chanzo
(YAT, JM au mfumo wa kujiandikia)
Mipangilio
wakala wa mzigo
Weka na tayari
wakala wa mzigo wa kazi
Mtihani: hatua ya utekelezaji wa vipimo vya mzigo. Vyanzo ni mawakala wa kupakia waliotumwa katika madimbwi mahususi ya mawakala kwa GitLab CI
mzigo
Kuanzisha Wakala wa Mzigo
na mpango wa mtihani uliochaguliwa
na vigezo vya kupakia
Chaguzi za Mtumiaji
kwa uanzishaji
wakala wa mzigo
Mpango wa mtihani
Kusudi la majaribio
Kumbukumbu za utekelezaji
vipimo vya mzigo
Kumbukumbu za mfumo
Mienendo ya mabadiliko katika vipimo vya lengo na wakala wa upakiaji
Mawakala wa kukimbia
Utekelezaji wa Wakala
mizigo ya maandishi ya mtihani
kulingana na
pakia wasifu
Mwingiliano wa Wakala wa mzigo
kwa madhumuni ya kupima
Mpango wa mtihani
Kusudi la majaribio
Magogo
Mkusanyiko wa magogo "mbichi".
wakati wa kupima mzigo:
rekodi za shughuli za wakala,
hali ya lengo la mtihani
na VM inayoendesha wakala
Kumbukumbu za utekelezaji
vipimo vya mzigo
Kumbukumbu za mfumo
Metrics
Kukusanya vipimo "mbichi" wakati wa majaribio
Mienendo ya mabadiliko katika vipimo vya lengo
na wakala wa mzigo
Ripoti: hatua ya maandalizi ya ripoti ya mtihani
Jenereta
Usindikaji umekusanywa
mfumo wa upakiaji na
mfumo wa ufuatiliaji "mbichi"
vipimo na kumbukumbu
Uundaji wa ripoti katika
umbo la kibinadamu linaloweza kusomeka
inawezekana na vipengele
wachambuzi
Kumbukumbu za utekelezaji
vipimo vya mzigo
Kumbukumbu za mfumo
Mienendo ya mabadiliko katika vipimo
lengo na wakala wa mzigo
Kumbukumbu "mbichi" zilizosindika
katika muundo unaofaa
upakiaji kwenye hifadhi ya nje
Ripoti ya mzigo tuli,
inayosomeka na binadamu
Chapisha
Uchapishaji wa ripoti
kuhusu mzigo
majaribio ya nje
huduma
Imechakatwa "mbichi"
kumbukumbu katika muundo unaofaa
kwa kupakuliwa kwa nje
hazina
Imehifadhiwa kwa nje
ripoti za uhifadhi
mzigo, unaofaa
kwa uchambuzi wa kibinadamu
Inaunganisha vyanzo vya upakiaji katika kiolezo cha CI
Wacha tuendelee kwenye sehemu ya vitendo. Ninataka kuonyesha jinsi kwenye baadhi ya miradi katika kampuni tumetekeleza dhana ya kupima mzigo kama huduma.
Kwanza, kwa usaidizi wa wahandisi wetu wa DevOps, tuliunda kundi maalum la mawakala katika GitLab CI ili kufanya majaribio ya upakiaji. Ili tusiwachanganye katika violezo na wengine, kama vile mabwawa ya mikusanyiko, tuliongeza lebo kwa mawakala hawa, : mzigo. Unaweza kutumia vitambulisho vingine vyovyote vinavyoeleweka. Wanauliza GitLab CI Runners.
Jinsi ya kujua nguvu inayohitajika na vifaa? Tabia za mawakala wa kupakia - idadi ya kutosha ya vCPU, RAM na Diski - inaweza kuhesabiwa kulingana na ukweli kwamba Docker, Python (ya Yandex.Tank), wakala wa GitLab CI, Java (kwa Apache JMeter) inapaswa kuendeshwa kwenye wakala. . Kwa Java chini ya JMeter, inashauriwa pia kutumia kiwango cha chini cha 512 MB ya RAM na, kama kikomo cha juu, .
Kwa hivyo, kulingana na uzoefu wetu, tunapendekeza kutumia angalau vCPU 4, RAM ya GB 4, SSD ya GB 60 kwa mawakala wa kupakia. Njia ya kadi ya mtandao imedhamiriwa kulingana na mahitaji ya wasifu wa mzigo.
Tunatumia hasa vyanzo viwili vya kupakia - Apache JMeter na picha za Yandex.Tank docker.
ni chombo cha chanzo wazi kutoka kwa Yandex kwa ajili ya kupima mzigo. Usanifu wake wa kawaida unatokana na jenereta ya ombi la HTTP yenye utendakazi wa hali ya juu ya Phantom. Tangi ina ufuatiliaji wa ndani wa rasilimali za seva chini ya jaribio kupitia itifaki ya SSH, inaweza kusimamisha jaribio kiotomati chini ya hali maalum, inaweza kuonyesha matokeo kwenye koni na kwa namna ya grafu, unaweza kuunganisha moduli zako. kwake ili kupanua utendakazi. Kwa njia, tulitumia Tangi wakati haikuwa ya kawaida. Katika makala "Β» unaweza kusoma hadithi ya jinsi tulifanya majaribio ya mzigo nayo mnamo 2013 ni moja ya bidhaa za kampuni yetu.
ni zana huria ya kupima upakiaji kutoka Apache. Inaweza kutumika kwa usawa kwa kujaribu programu tuli na zenye nguvu za wavuti. JMeter inasaidia idadi kubwa ya itifaki na njia za kuingiliana na programu: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, n.k.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) na IMAP(S), hifadhidata kupitia JDBC, zinaweza kutekeleza amri za ganda na kufanya kazi na vitu vya Java. JMeter ina IDE ya kuunda, kurekebisha na kutekeleza mipango ya majaribio. Pia kuna CLI ya uendeshaji wa mstari wa amri kwenye mfumo wowote wa uendeshaji unaoendana na Java (Linux, Windows, Mac OS X). Zana inaweza kuzalisha ripoti ya jaribio la HTML kwa nguvu.
Kwa urahisi wa matumizi ndani ya kampuni yetu, kwa uwezo wa wanaojaribu wenyewe kubadilika na kuongeza mazingira, tulitengeneza picha za docker za vyanzo vya upakiaji kwenye GitLab CI na kuchapishwa kwa ndani. . Hii inafanya iwe haraka na rahisi kuziunganisha kwenye bomba kwa majaribio ya upakiaji. Jinsi ya kufanya docker kushinikiza kwa Usajili kupitia GitLab CI - tazama .
Tulichukua faili hii ya msingi ya kituo cha Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Na kwa Apache JMeter hii:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Unaweza kusoma jinsi mfumo wetu wa ujumuishaji unaoendelea unavyofanya kazi katika kifungu "'.
Kigezo na bomba
Mfano wa template ya kufanya vipimo vya mzigo inapatikana katika mradi huo . Katika Unaweza kusoma maagizo ya kutumia template. Kwenye kiolezo chenyewe (faili ) kuna maelezo kuhusu kila hatua inawajibika kwa nini.
Kiolezo ni rahisi sana na kinaonyesha hatua tatu za kupima mzigo zilizoelezwa kwenye mchoro hapo juu: kuandaa, kupima, na kuchapisha ripoti. Kuwajibika kwa hili : Tayarisha, Jaribio na Ripoti.
- Hatua inapaswa kutumika kusanidi mapema malengo ya jaribio au kuangalia upatikanaji wao. Mazingira ya vyanzo vya upakiaji hayahitaji kusanidiwa, yameundwa awali kama picha za kituo na kutumwa kwenye sajili ya kizimbani: bainisha tu toleo unalotaka katika hatua ya Jaribio. Lakini unaweza kuzijenga upya na kutengeneza picha zako zilizorekebishwa.
- Hatua hutumika kubainisha chanzo cha upakiaji, kufanya majaribio na kuhifadhi vizalia vya majaribio. Unaweza kuchagua chanzo chochote cha upakiaji: Yandex.Tank, Apache JMeter, yako mwenyewe, au zote kwa pamoja. Ili kuzima vyanzo visivyohitajika, toa maoni yako au ufute kazi. Viingilio vya vyanzo vya upakiaji:
- Vigezo vya uzinduzi wa Yandex.Tank vimeainishwa kwenye .,
- Vigezo vya kuanzisha Apache JMeter vimeainishwa kwenye faili .
Kumbuka: Kiolezo cha usanidi wa mkusanyiko kinatumika kuweka mwingiliano na mfumo wa CI na haimaanishi uwekaji wa mantiki ya jaribio ndani yake. Kwa vipimo, sehemu ya kuingia imeainishwa, ambapo hati ya bash ya kudhibiti iko. Mbinu ya kufanya majaribio, kutoa ripoti, na hati za majaribio yenyewe lazima zitekelezwe na wahandisi wa QA. Katika onyesho, kwa vyanzo vyote viwili vya upakiaji, ombi la ukurasa kuu la Yandex hutumiwa kama jaribio rahisi zaidi. Hati na vigezo vya majaribio viko kwenye saraka .
- Kwenye jukwaa unahitaji kueleza jinsi ya kuchapisha matokeo ya majaribio yaliyopatikana katika hatua ya Jaribio kwa hifadhi za nje, kwa mfano, kwa Kurasa za GitLab au mifumo maalum ya kuripoti. Kurasa za GitLab zinahitaji kwamba saraka ya ./public isiwe tupu na iwe na angalau faili ya index.html baada ya majaribio kukamilika. Unaweza kusoma juu ya nuances ya huduma ya Kurasa za GitLab. .
Mifano ya jinsi ya kuhamisha data:
- kutoka JMeter hadi ,
- kutoka Yandex.Tank hadi .
Maagizo ya kuweka mipangilio:
- Takwimu za HTML ndani ,
- kwa InfluxDB na kisha kwa .
Katika mfano wa onyesho, bomba iliyo na vipimo vya mzigo na vyanzo viwili vya mzigo (unaweza kuzima ile isiyo ya lazima) inaonekana kama hii:
Apache JMeter inaweza kutoa ripoti ya HTML yenyewe, kwa hivyo ni faida zaidi kuihifadhi kwenye Kurasa za GitLab kwa kutumia zana za kawaida. Hivi ndivyo ripoti ya Apache JMeter inaonekana kama:
Katika mfano wa demo kwa Yandex.Tank, utaona tu katika sehemu ya Kurasa za GitLab. Wakati wa majaribio, Tangi inaweza kuhifadhi matokeo kwenye hifadhidata ya InfluxDB, na kutoka hapo inaweza kuonyeshwa, kwa mfano, katika Grafana (usanidi unafanywa kwenye faili. ) Hivi ndivyo ripoti ya Tank inavyoonekana huko Grafana:
Muhtasari
Katika kifungu hicho, nilizungumza juu ya wazo la "upimaji wa mzigo kama huduma" (upimaji wa mzigo kama huduma). Wazo kuu ni kutumia miundomsingi ya vidimbwi vilivyosanidiwa awali vya mawakala wa kupakia, picha za kizimbani za vyanzo vya upakiaji, mifumo ya kuripoti na bomba linalozichanganya katika GitLab CI kulingana na kiolezo rahisi cha .gitlab-ci.yml (mfano ) Yote hii inasaidiwa na timu ndogo ya wahandisi wa otomatiki na kuigwa kwa ombi la timu za bidhaa. Natumai hii itakusaidia katika kuandaa na kutekeleza mpango kama huo katika kampuni yako. Asante kwa umakini!
PS Ninataka kusema asante kubwa kwa wenzangu, Sergey Kurbanov na Nikolai Yusev, kwa msaada wa kiufundi na utekelezaji wa dhana ya kupima mzigo kama huduma katika kampuni yetu.
Mwandishi: - Naibu Mkuu wa Michakato ya Teknolojia na Maendeleo (DevOps) katika Positive Technologies
Chanzo: mapenzi.com