Marami sa inyo ay maaaring may kamalayan sa lahat ng mga teoryang nauugnay sa . Ngunit alam mo ba kung paano ipatupad ang mga prinsipyo ng DevOps sa totoong buhay? Sa blog na ito, tatalakayin ko ang mga sitwasyon ng DevOps Real Time na makakatulong sa iyo na makakuha ng isang maikling pag-unawa sa kung paano gumagana ang mga bagay sa real-time.
Ang mga pahiwatig na sasakupin ko ditoArtikulo ng Mga Tunay na Oras ng DevOpsay:
- Ano ang DevOps?
- Ang mga problemang nalutas ng DevOps
- Mga Scenario ng CI (Patuloy na Pagsasama)
- Mga Scenario ng CT (Patuloy na Pagsubok)
- Mga Scenario sa CD (Patuloy na Paghahatid)
- Mga Scenario ng Data ng DevOps
Kaya't magsimula tayo sa ating unang paksa.
Ano ang DevOps?
Ang DevOps ay isang diskarte sa pag-unlad ng software na nagsasangkot ng Patuloy na Pag-unlad, Patuloy na Pagsubok, Patuloy na Pagsasama, Patuloy na Pag-deploy at Patuloy na Pagsubaybay ng software sa buong pag-ikot ng buhay sa pag-unlad. Ang mga aktibidad na ito ay posible lamang sa DevOps, hindi Agile o talon. Ito ang dahilan kung bakit pinili ng Facebook at iba pang mga nangungunang kumpanya ang DevOps bilang daan sa kanilang mga layunin sa negosyo.Pangunahin ang ginustong DevOps para sa pagbuo ng de-kalidad na software sa mas maikling mga ikot ng pag-unlad na nagreresulta sa higit na kasiyahan sa customer.
Sa susunod na seksyon nitoAng artikulo ng DevOps Real Time Scenarios, titingnan namin ang iba't ibang mga problema na nalutas ng DevOps.
Ang mga problemang nalutas ng DevOps
1. Maghatid ng halaga sa Mga Customer
- Mga DevOps pinapaliit ang oras kinakailangan upang maihatid ang halaga sa mga customer. Ang oras ng pag-ikot mula sa pagkumpleto ng developer ng isang kuwento / gawain hanggang sa mabawasan ng produksyon nang malaki, na pinapayagan ang halaga na maisakatuparan sa lalong madaling panahon.
Ang pinakamahalagang halagang napagtanto sa pamamagitan ng DevOps ay pinapayagan nito ang mga IT na samahan na ituon ang kanilang 'pangunahing' mga aktibidad sa negosyo . Sa pamamagitan ng pag-aalis ng mga hadlang sa loob ng stream ng halaga at pag-automate ng mga pipeline ng paglawak, ang mga koponan ay maaaring tumuon sa mga aktibidad. Nakakatulong ito sa paglikha ng halaga ng customer sa halip na paglipat lamang ng mga piraso at byte. Ang mga aktibidad na ito ay nagdaragdag ng napapanatiling mapagkumpitensyang kalamangan ng isang kumpanya at lumikha ng mas mahusay na kinalabasan ng negosyo.
2. Nabawasan ang oras ng pag-ikot
Ang panloob na DevOps ay ang tanging paraan upang makamit ang liksi upang maihatid ang ligtas na code na may mga pananaw. Mahalaga na magkaroon ng mga pintuang-daan at isang maayos na proseso ng DevOps. Kapag naghahatid ka ng isang bagong bersyon, maaari itong magpatakbo ng tabi-tabi sa kasalukuyang bersyon. Maaari mo ring ihambing ang mga sukatan upang magawa ang nais mo sa mga sukatan ng application at pagganap.
Hinahatid ng mga DevOps ang mga koponan sa pag-unlad patungo patuloy na pagpapabuti at mas mabilis na mga siklo ng paglabas . Kung nagawa nang maayos, pinapayagan ng umuulit na proseso na ito ang higit na pagtuon sa paglipas ng panahon, sa mga bagay na talagang mahalaga. Tulad ng mga bagay na lumilikha ng magagandang karanasan para sa mga gumagamit - at mas kaunting oras sa pamamahala ng mga tool, proseso, at tech.
3. Oras sa merkado
Ang pinakamahalagang problema na malulutas ay ang pagbawas ng pagiging kumplikado ng proseso. Malaki ang ambag nito patungo sa tagumpay ng aming negosyo sa pamamagitan ng pagpapaikli ng aming oras sa merkado, pagbibigay sa amin ng mabilis na feedback sa mga tampok, at ginagawang mas tumutugon kami sa mga pangangailangan ng aming mga customer.
4. Paglutas ng Suliranin
Ang pinakadakilang halaga ng matagumpay na pagpapatupad ng DevOps ay ang mas mataas na kumpiyansa sa paghahatid, kakayahang makita, at kakayahang masubaybayan sa mga nangyayari, upang mas mabilis mong malutas ang mga problema.
Ang isa pang mahalagang bentahe ng DevOps ay hindi nag-aaksaya ng anumang oras. Ang pag-align sa mga tao at mapagkukunan ng isang organisasyon ay nagbibigay-daan sa mabilis na pag-deploy at pag-update. Pinapayagan nito ang mga programa ng DevOps na ayusin ang mga problema bago sila maging mga sakuna.Lumilikha ang DevOps ng isang kultura ng transparency na nagtataguyod ng pagtuon at pakikipagtulungan sa mga development, operasyon, at security team.
CI (Patuloy na Pagsasama) saMga Scenario ng Totoong Oras ng DevOps
1. Ang mga Indibidwal ay Maaaring Makakita ng Patuloy na Pagsasama-sama na Counterproductive
Ang mga miyembro ng isang koponan sa pag-unlad ay may iba't ibang mga tungkulin, responsibilidad, at mga prayoridad. Posibleng ang unang priyoridad ng manager ng Produkto ay maaaring maglunsad ng mga bagong tampok, kailangang tiyakin ng manager ng proyekto na natutugunan ng kanilang koponan ang deadline. Maaaring isipin ng mga programmer na kung titigil sila upang ayusin ang isang menor de edad na bug sa tuwing nangyayari ito ay magpapabagal sa kanila. Maaaring pakiramdam nila ang pagpapanatiling malinis ang pagbuo ay isang labis na pasanin sa kanila at hindi sila ang mapapakinabangan para sa kanilang labis na pagsisikap. Maaari nitong mapanganib ang proseso ng pagbagay.
Upang mapagtagumpayan ito:
Una, siguraduhin na ang iyong buong koponan ay nakasakay bago ka magpatibay ng tuluy-tuloy na pagsasama.
Dapat tulungan ng mga CTO at pinuno ng koponan ang mga miyembro ng koponan na maunawaan ang mga gastos at benepisyo ng patuloy na pagsasama.
I-highlight kung ano at kailan ang mga coder ay makikinabang sa pamamagitan ng paglalaan ng kanilang sarili sa ibang pamamaraan ng pagtatrabaho na nangangailangan ng kaunting pagiging bukas at kakayahang umangkop.
2. Pagsasama sa CI Sa Iyong Umiiral na Daloy ng Pag-unlad
Ang pag-aampon sa CI ay hindi maiiwasang may kasamang pangangailangan para sa mahalagang pagbabago ng ilang bahagi ng iyong pag-unlad na daloy. Posibleng hindi maaayos ng iyong mga developer ang daloy ng trabaho kung hindi ito nasira. Posible itong pangunahin kung ang iyong koponan ay may isang mas malaking gawain sa pagpapatupad ng kanilang kasalukuyang daloy ng trabaho.
Kung nais mong baguhin ang daloy ng trabaho pagkatapos ay dapat mong gawin ito nang may mahusay na pag-iingat. Kung hindi man, maaari nitong ikompromiso ang pagiging produktibo ng koponan ng pag-unlad at pati na rin ang kalidad ng produkto. Nang walang sapat na suporta mula sa pamumuno, ang koponan sa pag-unlad ay maaaring maging medyo nag-aatubili na magsagawa ng isang gawain na may kasamang mga panganib.
Upang mapagtagumpayan ito:
Dapat mong tiyakin na magbibigay ka ng sapat na oras para sa iyong koponan upang paunlarin ang kanilang bagong daloy ng trabaho. Ginagawa ito upang pumili ng isang nababaluktot na tuluy-tuloy na solusyon sa pagsasama na maaaring suportahan ang kanilang bagong daloy ng trabaho.
Gayundin, tiyakin sa kanila na ang kumpanya ay may kanilang mga likod kahit na ang mga bagay ay maaaring hindi masyadong maayos sa simula.
3. Muling pagbabalik sa Dating Mga Kasanayan sa Pagsubok
Ang agarang epekto ng paghango ng tuluy-tuloy na pagsasama ay ang iyong koponan ay mas madalas na susubukan. Kaya't maraming pagsubok ang kakailanganin ng maraming mga kaso sa pagsubok at ang pagsusulat ng mga kaso ng pagsubok ay maaaring gugugol ng oras. Samakatuwid, madalas na kailangang hatiin ng mga developer ang kanilang oras sa pagitan ng pag-aayos ng mga bug at pagsusulat ng mga kaso sa pagsubok.
Pansamantala, maaaring makatipid ng oras ang mga developer sa pamamagitan ng manu-manong pagsusuri, ngunit maaaring masaktan ito sa pangmatagalan. Ang mas maraming pagpapaliban nila sa mga kaso ng pagsusulit sa pagsusulat, mas mahirap maging abutin ang pag-unlad ng kaunlaran. Sa pinakapangit na sitwasyon, ang iyong koponan ay maaaring mapunta sa kanilang dating proseso ng pagsubok.
Upang mapagtagumpayan ito:
Dapat mong bigyang-diin na ang pagsusulat ng mga kaso ng pagsubok mula sa simula ay maaaring makatipid ng maraming oras para sa iyong koponan at masisiguro ang mataas na saklaw ng pagsubok ng iyong produkto.
Gayundin, i-embed ang ideya sa kultura ng iyong kumpanya na ang mga pagsubok na kaso ay kasing halaga ng mga assets tulad ng codebase mismo.
sa oras lamang tagatala ng java
4. Ang Mga Nag-develop Hindi Pinapansin ang Mga Mensahe ng Error
Ito ay isang pangkaraniwang problema na kapag ang mas malalaking koponan ay nagtutulungan ang halaga ng mga abiso sa CI ay naging napakalaki at sinimulan ng mga developer na huwag pansinin at i-mute ang mga ito. Samakatuwid, posible na maaari nilang makaligtaan ang mga update na nauugnay sa kanila.
Maaari itong humantong sa isang yugto kung saan ang mga coder ay nagkakaroon ng isang kamag-anak na kaligtasan sa sakit sa sirang mga build at error na mensahe. Kung mas matagal nilang binabalewala ang mga nauugnay na notification, mas matagal ang pag-unlad na walang feedback sa maling direksyon. Posibleng maging sanhi ito ng malaking pag-rollback, pag-aksaya ng pera, mapagkukunan, at oras.
Upang mapagtagumpayan ito:
Dapat mo lang ipadala ang mga kritikal na pag-update.
Ipadala lamang ang abiso sa kani-kanilang mga developer na namamahala sa pag-aayos nito.
CT (Patuloy na Pagsubok) saMga Scenario ng Totoong Oras ng DevOps
Pagkuha ng Pagtukoy ng Mga Kinakailangan na tama
Kung makukuha mo mismo ang iyong mga hinihiling sa gayon halos kalahati ng labanan ang napanalunan. Kaya't kung mayroon kang isang napaka tukoy at tumpak na pag-unawa sa mga kinakailangan, maaari kang mag-disenyo ng mga plano sa pagsubok nang mas mahusay at masakop nang maayos ang mga kinakailangan.
Gayunpaman, maraming mga koponan ang gumugugol ng maraming oras at pagsisikap na linilinaw lamang ang mga kinakailangan. Ito ay isang pangkaraniwang pitfall at upang maiwasan ito, ang mga koponan ay maaaring magpatibay ng mga diskarteng Pagsubok na batay sa Model at mga diskarte sa Pag-unlad na Pinatulak ng Pag-uugali. Nakakatulong ito upang mag-disenyo ng mga sitwasyon sa pagsubok nang tumpak at sapat.
Ang mga kasanayan na ito ay tiyak na makakatulong na matugunan at malutas ang mga puwang nang mas mabilis. Gayundin, nagbibigay-daan ito sa kanila na makabuo ng higit pang mga kaso ng pagsubok na awtomatikong mula mismo sa mga unang yugto ng isang sprint.
Pipeline Orchestration
Ang mga kalamangan ng tuluy-tuloy na pagsubok at tuloy-tuloy na paghahatid ay malapit na nakatali sa orkestra ng pipeline. Direktang nangangahulugan ito ng pag-unawa sa kung paano ito gumagana, kung bakit ito gumagana, kung paano pag-aralan ang mga resulta, at kung paano at kailan susukat. Ang lahat ay nakasalalay sa pipeline at samakatuwid kailangan mong isama ang pipeline sa automation suite.
Ngunit ang dahilan kung bakit nagkamali ang mga koponan ay iyon, walang iisang solusyon na nagbibigay ng kumpletong toolchain na kinakailangan upang bumuo ng isang pipeline ng CD.
Karaniwang hinahanap ng mga koponan ang mga piraso ng palaisipan na tama para sa kanila. Walang mga perpektong tool, karaniwang mga tool na pinakamahusay na lahi lamang, na nagbibigay ng mga pagsasama kasama ang maraming iba pang mga tool. At syempre, isang API na nagpapahintulot din sa madaling pagsasama.
Sa madaling salita, imposibleng magpatupad ng tuluy-tuloy na pagsubok nang walang bilis at pagiging maaasahan ng isang istandardado at awtomatikong pipeline.
Pagtaas at pamamahala ng pagiging kumplikado
Ang isa pang mahalagang senaryo ay ang tuluy-tuloy na pagsubok ay nagiging mas kumplikado sa paglipat nito patungo sa kapaligiran ng produksyon. Lumalaki ang mga pagsubok sa bilang pati na rin ang pagiging kumplikado sa pagkahinog ng code at nagiging mas kumplikado ang kapaligiran.
Dapat mong i-update ang mga pagsubok sa bawat oras na mag-update ka ng iba't ibang mga phase at mga awtomatikong script. Bilang isang resulta, ang pangkalahatang oras na kinakailangan upang magpatakbo ng mga pagsubok ay may kaugaliang tumaas patungo sa paglabas.
Ang solusyon para dito ay nakasalalay sa pinahusay na orkestra ng pagsubok na nagbibigay ng tamang dami ng saklaw ng pagsubok sa mas maiikling siklo ng sprint at nagbibigay-daan sa mga koponan na makapaghatid nang buong kumpiyansa. Sa isip, ang buong proseso ay dapat na awtomatiko sa CT na isinasagawa sa iba't ibang mga yugto. Ginagawa ito sa pamamagitan ng paggamit ng mga pintuan ng patakaran at manu-manong interbensyon, hanggang sa maitulak ang code sa paggawa.
Lumilikha ng mga loop ng feedback
Nang walang madalas na mga loop ng feedback sa bawat yugto ng pag-ikot ng pag-unlad, hindi posible ang tuluy-tuloy na pagsubok. Bahagyang ito ang dahilan kung bakit mahirap ipatupad ang CT. Hindi mo lang kailangan ng mga awtomatikong pagsubok, ngunit kailangan mo rin ng kakayahang makita ang mga resulta ng pagsubok at pagpapatupad.
Ang mga tradisyonal na feedback loop tulad ng mga tool sa pag-log, mga profile profil, at mga tool sa pagsubaybay sa pagganap ay hindi na epektibo. Hindi sila nagtutulungan o nagbibigay ng lalim ng kinakailangang pananaw upang ayusin ang mga isyu. Ang mga real-time na dashboard na awtomatikong bumubuo ng mga ulat at naaaksyong feedback sa buong SDLC ay tumutulong na palabasin ang software nang mas mabilis sa produksyon na may mas kaunting mga depekto. Ang pag-access ng real-time sa mga dashboard at pag-access para sa lahat ng mga miyembro ng koponan ay tumutulong sa patuloy na mekanismo ng feedback.
Kakulangan ng Mga Kapaligiran
Ang patuloy na Pagsubok ay nangangahulugan lamang ng mas madalas na pagsubok at nangangailangan ito ng mas madalas na pagpindot sa maraming mga kapaligiran. Nagpapakita ito ng isang bottleneck kung ang mga nasabing kapaligiran ay hindi magagamit sa oras na kinakailangan sila. Ang ilang mga kapaligiran ay magagamit sa pamamagitan ng mga API at ang ilan sa pamamagitan ng iba't ibang mga interface. Ang ilan sa mga kapaligiran na ito ay maaaring maitayo gamit ang modernong arkitektura habang ang iba ay may monolithic legacy client / server o mainframe system.
Ngunit ang tanong dito ay paano mo maiuugnay ang pagsubok sa pamamagitan ng iba't ibang mga may-ari ng kapaligiran? Posible rin na maaaring hindi nila palaging mapanatili ang pagpapatakbo ng mga kapaligiran. Ang sagot sa lahat ng ito ay Virtualization . Sa pamamagitan ng pag-virtualize sa kapaligiran, maaari mong subukan ang code nang hindi masyadong nag-aalala tungkol sa mga lugar na hindi nagbabago.Ang paggawa ng mga kapaligiran na naa-access at magagamit na on-demand sa pamamagitan ng virtualization ay tiyak na makakatulong na alisin ang isang makabuluhang bottleneck mula sa iyong pipeline.
CD (Patuloy na Paghatid) saMga Scenario ng Totoong Oras ng DevOps
Ang mga pag-deploy na masyadong tumatagal
Ang mga ipinamamahaging aplikasyon ay karaniwang nangangailangan ng higit sa 'pagkopya at pag-paste' ng mga file sa isang server. Ang pagiging kumplikado ay may kaugaliang tumaas kung mayroon kang isang sakahan ng mga server. Ang kawalan ng katiyakan tungkol sa kung ano ang ilalagay, kung saan, at paano, ay isang medyo normal na bagay. Ang resulta? Mahabang oras ng paghihintay upang makuha ang aming mga artifact sa susunod na kapaligiran ng ruta upang maantala ang lahat, pagsubok, oras upang mabuhay, atbp.
Ano ang dinadala ng DevOps sa mesa? Ang mga koponan sa pagpapaunlad at IT pagpapatakbo ay tumutukoy sa isang proseso ng paglawak sa isang walang sala na sesyon ng pakikipagtulungan. Una, pinatutunayan nila kung ano ang gumagana at pagkatapos ay dalhin ito sa susunod na antas na may awtomatiko upang mapadali ang patuloy na paghahatid. Mahigpit na binabawasan nito ang tiyempo para sa pag-deploy na ito ay nagbibigay daan din para sa mas madalas na pag-deploy.
Nawawalang mga artifact, script, at iba pang mga dependency
Madalas kaming nakatagpo ng mga pagkabigo na mai-post ang pag-deploy ng isang bagong bersyon ng isang gumaganang piraso ng software. Ito ay madalas na sanhi ng mga nawawalang aklatan o database ng mga script na hindi na-update. Karaniwan itong sanhi ng kawalan ng kaliwanagan tungkol sa kung aling mga dependency ang dapat i-deploy at ang kanilang lokasyon. Ang pagtaguyod ng pakikipagtulungan sa pagitan ng pag-unlad at pagpapatakbo ay maaaring makatulong na malutas ang mga ganitong uri ng mga problema sa karamihan ng mga kaso.
Pagdating sa pag-aautomat, maaari mong tukuyin ang mga dependency na makakatulong nang husto sa pagpapabilis ng mga pag-deploy. Ang mga tool sa pamamahala ng pagsasaayos tulad ng Papet o Hepe magbigay ng dagdag na antas ng kahulugan ng mga dependency. Maaari naming tukuyin hindi lamang ang mga dependency sa loob ng aming application ngunit din sa antas ng imprastraktura at pagsasaayos ng server. Halimbawa, makakalikha kami ng isang virtual machine para sa isang pagsubok, at mai-install / i-configure tomcat bago mailathala ang aming mga artifact.
Hindi mabisang pagsubaybay sa produksyon
Minsan nai-configure mo ang mga tool sa pagsubaybay sa isang paraan na gumagawa ng maraming walang katuturang data mula sa produksyon, gayunpaman, sa ibang mga oras na hindi sila nakakagawa ng sapat o wala man lang. Walang kahulugan ng kung ano ang kailangan mong alagaan at kung ano ang mga sukatan.
Dapat kang sumang-ayon sa kung ano ang susubaybayan at aling impormasyon ang gagawa, at pagkatapos ay ilagay ang mga kontrol sa lugar. Ang mga tool sa pamamahala ng Pagganap ng Pagganap ay isang malaking tulong kung kayang bayaran ito ng iyong samahan tingnan ang AppDynamics, New Relic at AWS X-Ray.
Mga Scenario ng Data ng DevOps
Ang DevOps ay tungkol sa pag-aalis ng mga panganib na nauugnay sa bagong pag-unlad ng software: Kinikilala ng pagtatasa ng data ang mga panganib na iyon. Upang patuloy na sukatin at pagbutihin ang proseso ng DevOps, dapat sumaklaw ang analytics sa buong pipeline. Nagbibigay ito ng napakahalagang pananaw sa pamamahala sa lahat ng mga yugto ng lifecycle ng pag-unlad ng software.
1. Mas kaunting oras upang pag-aralan ang data
Sa lahat ng data na nabuo sa anumang naibigay na oras, kailangang tanggapin ng mga samahan na hindi nila ito masusuri ang lahat. Mayroong simpleng walang sapat na oras sa araw - at sa kasamaang palad, ang mga robot ay hindi pa sopistikadong sapat upang magawa ang lahat para sa atin.
Para sa kadahilanang iyon, mahalagang alamin kung aling mga hanay ng data ang pinakamahalaga. Sa karamihan ng mga kaso, magkakaiba ito para sa bawat samahan. Kaya bago sumabak, tukuyin ang mga pangunahing layunin at layunin sa negosyo. Karaniwan, ang mga layuning ito ay umiikot sa mga pangangailangan ng customer - pangunahin ang pinakamahalagang tampok na pinakamahalaga sa mga end-user. Para sa isang tingi, halimbawa, pag-aaral kung paano nakikipag-ugnay ang trapiko sa pahina ng pag-checkout sa site at sinusubukan kung paano ito gumagana sa back-end ay nasa tuktok ng listahan.
Ang ilang mga mabilis na tip upang makilala kung aling data ang pinakamahalagang pag-aralan:
Gumawa ng isang tsart: Tukuyin ang mga epekto sa outages sa iyong negosyo, nagtatanong tulad ng, 'Kung X break , ano ang magiging epekto nito sa iba pang mga tampok? '
Tumingin sa makasaysayang data: Kilalanin kung saan lumitaw ang mga isyu sa nakaraan at patuloy na pag-aralan ang data mula sa mga pagsubok at pagbuo upang matiyak na hindi na ito mauulit.
2. Mahirap na komunikasyon
Ngayon, ang karamihan sa mga organisasyon ay nagpapatakbo pa rin ng iba't ibang mga koponan at personas na kinikilala ang kanilang sariling mga layunin at gumagamit ng kanilang sariling mga tool at teknolohiya. Ang bawat koponan ay kumikilos nang nakapag-iisa, naka-disconnect mula sa pipeline at nakikipagtagpo sa ibang mga koponan sa panahon lamang ng pagsasama-sama.
Pagdating sa pagtingin sa mas malaking larawan at pagkilala kung ano ang mayroon at hindi gumagana, nagpupumilit ang samahan na magkaroon ng isang solusyon. Ito ay dahil sa karamihan dahil sa bawat isa ay nabigo upang ibahagi ang pangkalahatang data, na ginagawang imposible ang pagtatasa.
Upang mapagtagumpayan ang isyung ito, maingat na pagsusuri ng daloy ng komunikasyon upang matiyak na ang lahat ay nakikipagtulungan sa buong SDLC, hindi lamang sa panahon ng proseso ng pagsasama.
Una, tiyaking mayroong malakas na pagsabay sa mga sukatan ng DevOps mula sa get-go. Ang pag-usad ng bawat koponan ay dapat ipakita sa isang solong dashboard, na gumagamit ng parehong Mga Tagapagpahiwatig ng Key Performance (KPI) upang mabigyan ng kakayahang makita ang pamamahala sa buong proseso. Ginagawa ito upang makolekta nila ang lahat ng kinakailangang data upang pag-aralan kung ano ang mali (o kung anong nagtagumpay).
Higit pa sa pag-uusap sa panukat na sukatan, dapat mayroong palaging komunikasyon sa pamamagitan ng mga pagpupulong ng koponan o mga digital na channel tulad ng Slack.
3. Kakulangan ng lakas ng tao
Kapag may maikling tauhan, kailangan namin ng mas matalinong tool na gumagamit ng malalim na pag-aaral upang mai-slot ang data na kinokolekta namin at mabilis na maabot ang mga desisyon. Pagkatapos ng lahat, walang tao ang may oras upang tingnan ang bawat solong pagpapatupad ng pagsubok (at para sa ilang malalaking organisasyon, maaaring mayroong humigit-kumulang na 75,000 sa isang naibigay na araw). Ang bilis ng kamay ay upang alisin ang ingay at hanapin ang mga tamang bagay na pagtuunan ng pansin.
c ++ na recursive
Dito makakatulong ang artipisyal na katalinuhan at pag-aaral ng makina. Maraming mga tool sa merkado ngayon ang gumagamit ng AI at ML upang gawin ang mga bagay tulad ng:
Bumuo ng mga script at pagsubok upang ilipat at mapatunayan ang iba't ibang mga piraso ng data
Mag-ulat sa kalidad batay sa dating natutunang pag-uugali
Magtrabaho bilang tugon sa mga pagbabago sa real-time.
Kaya sa pamamagitan nito, napunta kami sa dulo ng artikulong ito sa DevOps Real Time Scenarios.
Ngayon na naintindihan mo kung ano ang Mga Pamamahala ng Totoong Oras ng DevOps, tingnan ito ni Edureka, isang pinagkakatiwalaang kumpanya sa pag-aaral sa online na may isang network na higit sa 250,000 nasiyahan na mga nag-aaral na kumalat sa buong mundo. Ang kurso sa Edureka DevOps Certification Training ay tumutulong sa mga nag-aaral na maunawaan kung ano ang DevOps at makakuha ng kadalubhasaan sa iba't ibang mga proseso at tool ng DevOps tulad ng Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack at GIT para sa pag-automate ng maraming mga hakbang sa SDLC.
May tanong ba sa amin? Mangyaring banggitin ito sa seksyon ng mga komento ditoArtikulo ng Mga Tunay na Oras ng DevOpsat babalikan ka namin.