Цяпер на хайпе тэма DevOps. Канвеер бесперапыннай інтэграцыі і дастаўкі ўкараняюць усе, каму не лянота. Але большасць не заўсёды надаюць належную ўвагу забеспячэнню надзейнасці працы інфармацыйных сістэм на розных этапах CI/CD Pipeline. У дадзеным артыкуле я жадаў бы пагаварыць аб сваім досведзе аўтаматызацыі праверак якасці ПЗ і рэалізацыі магчымых сцэнараў па ім «самааднаўленню».
Я працую інжынерам у аддзеле кіравання ІТ-паслугамі ў кампаніі . Мой профільны кірунак - укараненне розных сістэм маніторынгу прадукцыйнасці і даступнасці прыкладанняў. Я часта маю зносіны з ІТ-заказчыкамі з розных сегментаў рынку на прадмет актуальных пытанняў па маніторынгу якасці іх ІТ-сэрвісаў. Асноўная задача - мінімізаваць час цыклу рэлізу і павялічыць частату іх выпуску. Гэта, вядома, усё добра: больш рэлізаў - больш новых фіч - больш задаволеных карыстальнікаў - больш прыбытку. Але на справе не заўсёды ўсё атрымоўваецца добра. Пры вельмі высокіх тэмпах разгортвання адразу ўсплывае пытанне аб якасці нашых рэлізаў. Нават пры цалкам аўтаматызаваным канвееры адна з самых вялікіх праблем - пераклад сэрвісаў з тэставання ў вытворчасць, які не ўплывае пры гэтым на час безадмоўнай працы і ўзаемадзеянне карыстальнікаў з дадаткам.
Па выніках шматлікіх гутарак з замоўцамі я магу сказаць, што кантроль якасці рэлізаў, праблема надзейнасці прыкладання і магчымасць яго "самааднаўлення" (напрыклад, адкат да стабільнай версіі) на розных этапах канвеера CI/CD сярод самых хвалюючых і актуальных тэм.
Нядаўна я сам працаваў на баку заказчыка - у службе суправаджэння прыкладнога ПА анлайн-банка. У архітэктуры нашага прыкладання выкарыстоўвалася вялікая колькасць самапісных мікрасэрвісаў. Самае сумнае, што не ўсе распрацоўшчыкі спраўляліся з высокімі тэмпамі распрацоўкі, якасць некаторых мікрасэрвісаў пакутавала, што спараджала смешныя мянушкі для іх і іх стваральнікаў. З'яўляліся байкі, аб тым, з якіх матэрыялаў ствараюцца дадзеныя прадукты.
"Пастаноўка задачы"
Высокая частата рэлізаў і вялікая колькасць мікрасэрвісаў ўносяць цяжкасці ў разуменне працы прыкладання ў цэлым, як на этапе тэсціравання, так і на этапе эксплуатацыі. Змены адбываюцца ўвесь час і кантраляваць іх без добрых інструментаў маніторынгу вельмі цяжка. Часта пасля начнога рэлізу раніцай распрацоўшчыкі сядзяць як на парахавой бочцы і чакаюць, каб нічога не зламалася, хоць на этапе тэсціравання ўсе праверкі былі паспяховымі.
Ёсць яшчэ адзін момант. На этапе тэставання правяраюць працаздольнасць ПЗ: выкананне асноўных функцый прыкладання і адсутнасць памылак. Якасныя адзнакі прадукцыйнасці альбо адсутнічаюць, альбо не ўлічваюць усе аспекты працы прыкладання і інтэграцыйны пласт. Некаторыя метрыкі ўвогуле могуць не правярацца. У выніку пры ўзнікненні паломкі ў прадуктыўным асяроддзі аддзел тэхнічнай падтрымкі пазнае пра гэта толькі калі рэальныя карыстачы пачынаюць скардзіцца. Жадаецца мінімізаваць уплыў няякаснага ПА на канчатковых карыстачоў.
Адзін са шляхоў рашэння - гэта ўкараняць працэсы праверкі якасці ПЗ на розных этапах CI/CD Pipeline, дадаваць розныя сцэнары па аднаўленні сістэмы пры ўзнікненні аварый. Таксама памятаем, што ў нас DevOps. Бізнес чакае максімальна хуткага атрымання новага прадукта. Таму ўсе нашыя праверкі і сцэнары павінны быць аўтаматызаваны.
Задача разбіваецца на дзве складнікі:
- кантроль якасці зборак на этапе тэсціравання (аўтаматызаваць працэс адлоўлівання няякасных зборак);
- кантроль якасці ПЗ у прадасяроддзі (механізмы аўтаматычнага выяўлення праблем і магчымыя сцэнары па іх самааднаўленні).
Інструмент для маніторынгу і збору метрык
Для таго, каб рэалізаваць пастаўленыя задачы, патрабуецца сістэма маніторынгу, здольная выяўляць праблемы і перадаваць іх у сістэмы аўтаматызацыі на розных этапах канвеера CI/CD. Таксама станоўчым момантам будзе, калі дадзеная сістэма прадаставіць карысныя метрыкі для розных каманд: распрацоўкі, тэсціравання, эксплуатацыі. І зусім выдатна, калі і для бізнэсу.
Для збору метрык можна выкарыстоўваць сукупнасць розных сістэм (Prometheus, ELK Stack, Zabbix і тд), але, на мой погляд, пад дадзеныя задачы лепш за ўсё падыходзяць рашэнні класа APM (), якія здольныя моцна спрасціць вам жыццё.
У рамках маёй працы ў службе суправаджэння я пачынаў рабіць аналагічны праект, выкарыстоўваючы рашэнне класа APM ад кампаніі Dynatrace. Цяпер, працуючы ў інтэгратары, я дастаткова добра ведаю рынак сістэм маніторынгу. Маё суб'ектыўнае меркаванне: Dynatrace лепш за ўсё падыходзіць для вырашэння такіх задач.
Рашэнне Dynatrace дае гарызантальнае адлюстраванне кожнай карыстацкай аперацыі з глыбокай ступенню дэталізацыі да ўзроўню выканання кода. Можна адсачыць увесь ланцужок узаемадзеяння паміж рознымі інфармацыйнымі сэрвісамі: ад узроўняў фронтэнд вэб-і мабільных прыкладанняў, back-end сервераў прыкладанняў, інтэграцыйнай шынай да канкрэтнага выкліку ў БД.
. Аўтаматычная пабудова ўсіх залежнасцяў паміж кампанентамі сістэмы
. Аўтаматычнае вызначэнне і пабудова шляху праходжання аперацыі сэрвісу
Таксама памятаем, што нам неабходна інтэгравацца з рознымі прыладамі аўтаматызацыі. Тут рашэнне мае зручны API, які дазваляе аддаваць і атрымліваць розныя метрыкі і падзеі.
Далей пяройдзем да больш падрабязнага разгляду, як вырашаць пастаўленыя задачы з дапамогай сістэмы Dynatrace.
Задача 1. Аўтаматызацыя кантролю якасці зборак на этапе тэсціравання
Першая задача - гэта знайсці праблемы як мага раней на этапах канвеера дастаўкі прыкладання. Толькі «добрыя» зборкі кода павінны дасягаць прод асяроддзя. Для гэтага ў ваш pipeline на этапе тэсціравання павінны быць уключаны дадатковыя маніторы па праверкі якасці вашых сэрвісаў.
Разгледзім па кроках, як гэта рэалізаваць і аўтаматызаваць гэты працэс:
На малюнку паказаны паток аўтаматызаваных крокаў праверкі якасці ПЗ:
- разгортванне сістэмы маніторынгу (усталёўка агентаў);
- вызначэнне падзей ацэнкі якасці вашага ПЗ (метрыкі і парогавыя значэнні) і перадача іх у сістэму маніторынгу;
- генерацыя нагрузкі і тэстаў прадукцыйнасці;
- збор даных аб прадукцыйнасці і даступнасці ў сістэме маніторынгу;
- перадача даных аб тэстах, заснаваных на падзеях ацэнкі якасці ПЗ, з сістэмы маніторынгу ў сістэму CI/CD. Аўтаматычны аналіз зборак.
Крок 1. Разгортванне сістэмы маніторынгу
Спачатку неабходна ўсталяваць агенты ў ваша тэставае асяроддзе. Пры гэтым рашэнне Dynatrace мае прыемную асаблівасць - яно выкарыстоўвае ўніверсальны агент OneAgent, які ўсталёўваецца на OS інстанс (Windows, Linux, AIX), аўтаматычна выяўляе вашыя сэрвісы і пачынае збіраць дадзеныя маніторынгу па іх. Вам не трэба наладжваць асобна агент для кожнага працэсу. Аналагічная сітуацыя будзе для хмарных і кантэйнерных платформ. Пры гэтым працэс усталёўкі агентаў вы таксама можаце аўтаматызаваць. Dynatrace выдатна ўпісваецца ў канцэпт інфраструктура як код (): ёсць ужо гатовыя скрыпты і інструкцыі пад усе папулярныя платформы. Убудоўваеце агент у канфігурацыю вашага сэрвісу, і пры яго разгортванні вы адразу атрымліваеце новы сэрвіс з ужо які працуе агентам.
Крок 2. Вызначэнне падзей ацэнкі якасці вашага ПЗ
Цяпер неабходна вызначыцца з пералікам сэрвісаў і бізнес-аперацый. Важна ўлічваць менавіта тыя аперацыі карыстачоў, якія з'яўляюцца бізнэс-крытычнымі для вашага сэрвісу. Тут рэкамендую пракансультавацца з бізнэс-і сістэмнымі аналітыкамі.
Далей неабходна вызначыць, якія метрыкі вы хочаце ўключыць у праверку для кожнага з узроўняў. Напрыклад, гэта могуць быць час выканання (з падзелам на сярэднюю, медыяну, перцентили і інш.), памылкі (лагічныя, сэрвісныя, інфраструктурныя і інш.) і розныя інфраструктурныя метрыкі (memory heap, garbage collector, thread count і інш.).
Для аўтаматызацыі і зручнасці выкарыстання камандай DevOps з'яўляецца канцэпцыя "Маніторынг як код". Што я пад гэтым маю на ўвазе — распрацоўшчык/тэсціроўшчык можа напісаць просты JSON файл, які вызначае паказчыкі праверкі якасці ПЗ.
Давайце разгледзім прыклад такога JSON-файла. У якасці пары ключ/значэнне выкарыстоўваюцца аб'екты з Dynatrace API (апісанне API можна паглядзець тут ).
{
"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
}
]
}Файл уяўляе сабой масіў азначэнняў часавых шэрагаў (timeseries):
- timeseriesId - правяраная метрыка, напрыклад, Response Time, Error count, Memory used і г.д.;
- aggregation - узровень агрэгацыі метрык, у нашым выпадку avg, але вы можаце выкарыстоўваць любую неабходную для вас (avg, min, max, sum, count, percentile);
- tags - тэг аб'екта ў сістэме маніторынгу, ці можна паказаць канкрэтны ідэнтыфікатар аб'екта;
- severe і warning - дадзеныя паказчыкі рэгулююць парогавыя значэнні нашых метрык, калі значэнне тэстаў перавышае парог severe, то наша зборка пазначаецца як не паспяховая.
На наступным малюнку прадстаўлены прыклад выкарыстання такіх трашолдаў.
Крок 3. Генерацыя нагрузкі
Пасля таго, як мы вызначылі ўзроўні якасці нашага сэрвісу, неабходна згенераваць тэставую нагрузку. Вы можаце выкарыстоўваць любы з зручных вам інструментаў тэсціравання, напрыклад, Jmeter, Selenium, Neotys, Gatling і г.д.
Сістэма маніторынгу Dynatrace дазваляе захопліваць розныя метададзеныя з вашых тэстаў і распазнаваць, які з тэстаў адносіцца да якога цыкла рэлізу і якога сэрвісу. Рэкамендуецца дадаваць дадатковыя загалоўкі ў HTTP-запыты тэста.
На наступным малюнку прадстаўлены прыклад, дзе з дапамогай дадатковага загалоўка X-Dynatrace-Test мы адзначаем, што гэты тэст ставіцца да тэставання аперацыі па даданні тавара ў кошык.
Пры запуску кожнага нагрузачнага тэсту вы адпраўляеце дадатковую кантэкстную інфармацыю ў Dynatrace з дапамогай API падзеі з сервера CI/CD. Такім чынам, сістэма можа адрозніваць розныя выпрабаванні паміж сабой.
. Падзея ў сістэме маніторынгу аб запуску нагрузачнага тэсціравання
Крок 4/5. Збор даных аб прадукцыйнасці і перадача даных у сістэму CI/CD
Разам з генераваным тэстам у сістэму маніторынгу перадаецца падзея аб неабходнасці збору даных аб праверкі паказчыкаў якасці сэрвісу. Таксама паказваецца наш JSON-файл, у якім вызначаны ключавыя метрыкі.
Падзея аб неабходнасці праверкі якасці ПЗ, якое фарміруецца на серверы CI/CD для адпраўкі ў сістэму маніторынгу
У нашым прыкладзе падзея аб праверкі якасці называецца perfSigDynatraceReport (Performance_Signature) - гэта гатовы для інтэграцыі з Jenkins, які распрацавалі хлопцы з T-Systems Multimedia Solutions. У кожнай падзеі аб запуску праверкі змяшчаецца інфармацыя аб сэрвісе, нумары зборцы, часе тэсціравання. Убудова збірае значэнні прадукцыйнасці падчас зборкі, ацэньвае іх і параўноўвае вынік з папярэднімі зборкамі і нефункцыянальнымі патрабаваннямі.
Падзея ў сістэме маніторынгу аб старце праверкі якасці зборкі.
Пасля завяршэння тэсту ўсе метрыкі па адзнацы якасці ПЗ перадаюцца назад у сістэму бесперапыннай інтэграцыі, напрыклад, Jenkins, якая фармуе справаздачу па выніках.
Вынік статыстыкі па зборках на сэрвэры CI/CD.
Для кожнай асобнай зборкі мы бачым статыстыку па кожнай зададзенай намі метрыцы на працягу выканання ўсяго тэста. Мы таксама бачым, калі былі парушэнні ў пэўных парогавых значэннях (warning і severe-трэшолды). На аснове сукупных паказчыкаў уся зборка пазначаецца як стабільная, нестабільная ці правальная. Таксама для зручнасці вы можаце дадаць у справаздачу паказчыкі параўнання бягучай зборкі з папярэдняй.
Прагляд дэталізаванай статыстыкі па зборках на сэрвэры CI/CD.
Дэталізаванае параўнанне дзвюх зборак
Пры неабходнасці можна перайсці ў інтэрфейс Dynatrace і тамака больш дэталёва прагледзець статыстыку па кожнай вашай зборцы і параўнаць іх паміж сабой.
Параўнанне статыстыкі па зборках у Dynatrace.
Высновы
У выніку мы атрымліваем сэрвіс "маніторынг як паслуга", аўтаматызаваны ў канвееры бесперапыннай інтэграцыі. Распрацоўніку ці тэстыравальніку неабходна толькі вызначыць спіс метрык у JSON-файле, а ўсё астатняе адбываецца аўтаматычна. Мы атрымліваем празрысты кантроль якасці рэлізаў: усе апавяшчэнні аб прадукцыйнасці, спажыванні рэсурсаў або архітэктурных рэгрэсіях.
Задача 2. Аўтаматызацыя кантролю якасці ПЗ у прадасяроддзі
Такім чынам, мы вырашылі задачу, як аўтаматызаваць працэс маніторынгу на этапе тэсціравання ў Pipeline. Такім чынам мы мінімізуем працэнт няякасных зборак, якія даходзяць да прод асяроддзя.
Але што рабіць, калі дрэннае ПЗ усё ж дайшло да прода, ну ці проста нешта ламаецца. Для ўтопіі нам хацелася, каб прысутнічалі механізмы аўтаматычнага выяўлення праблем і па магчымасці сістэма сама аднаўляла сваю працаздольнасць, хаця б уначы.
Для гэтага нам трэба па аналогіі з папярэдняй часткай прадугледзець аўтаматычныя праверкі якасці ПЗ у прад асяроддзі і закласці пад іх сцэнары па самааднаўленні сістэмы.
Аўтавыпраўленне як код
У большасці кампаній ужо прысутнічае назапашаная база ведаў па розных тыпах распаўсюджаных праблем і спіс дзеянняў па іх выпраўленні, напрыклад, перазапуск працэсаў, ачыстка рэсурсаў, адкат версій, аднаўленне няслушных змен канфігурацыі, павелічэнне ці памяншэнне колькасці кампанентаў у кластары, пераключэнне сіняга ці зялёнага контуру і інш
Нягледзячы на тое, што гэтыя варыянты выкарыстання вядомыя ўжо шмат гадоў шматлікім камандам, з якімі я маю зносіны, толькі нешматлікія задумваліся і ўклалі сродкі ў іх аўтаматызацыю.
Калі падумаць, то ў рэалізацыі працэсаў па самааднаўленні працаздольнасці прыкладання няма нічога звышскладанага, неабходна ўжо вядомыя сцэнары працы вашых адмінаў прадставіць у выглядзе сцэнарыяў кода (канцэпцыя «аўтавыпраўленне як код»), якія вы загадзя напісалі для кожнага канкрэтнага выпадку. Сцэнары аўтаматычнага выпраўлення павінны быць накіраваны на ўхіленне першапрычыны праблемы. Вы самі ўсталёўваеце правільныя дзеянні рэагавання на інцыдэнт.
У якасці трыгера для запуску сцэнара можа выступаць любая метрыка з вашай сістэмы маніторынгу, галоўнае, каб гэтыя метрыкі сапраўды вызначалі, што ўсё дрэнна, бо не жадалася б атрымаць ілжывыя спрацоўванні ў прадуктыўным асяроддзі.
Вы можаце выкарыстоўваць любую сістэму або сукупнасць сістэм: Prometheus, ELK Stack, Zabbix і т.д. Але я прывяду некалькі прыкладаў на аснове рашэння APM (у якасці прыкладу зноў будзе Dynatrace), якое таксама дапаможа аблегчыць ваша жыццё.
Па-першае, тут ёсць усё, што да працаздольнасці з пункту гледжання працы прыкладання. Рашэнне дае сотні метрык на розных узроўнях, якія вы можаце выкарыстоўваць у якасці трыгераў:
- узровень карыстальнікаў (браўзэры, мабільныя прыкладанні, IoT-прылады, паводзіны карыстальнікаў, канверсія і г.д.);
- узровень сэрвісу і аперацый (прадукцыйнасць, даступнасць, памылкі і тд.);
- узровень інфраструктуры прыкладання (OS-метрыкі хаста, JMX, MQ, web-server і тд);
- ўзровень платформаў (віртуалізацыя, воблака, кантэйнер і г.д).
Узроўні маніторынгу ў Dynatrace.
Па-другое, як я казаў раней, Dynatrace мае адчынены API, які дазваляе вельмі зручна інтэграваць яго з рознымі іншымі сістэмамі. Напрыклад, адпраўка апавяшчэння ў сістэму аўтаматызацыі пры перавышэнні кантрольных параметраў.
Ніжэй прадстаўлены прыклад для ўзаемадзеяння з Ansible.
Далей прывяду некалькі прыкладаў, якія менавіта аўтаматызацыі можна рабіць. Гэта ўсяго толькі частка кейсаў, іх пералік у вашым асяроддзі можа абмяжоўвацца толькі вашай фантазіяй і магчымасцямі вашых інструментаў маніторынгу.
1. Дрэнны deploy - адкат версіі
Нават калі мы ўсё вельмі добра правяраем у тэставым асяроддзі, то ўсё роўна ёсць шанец, што новы рэліз можа забіць ваша прыкладанне ў прад асяроддзі. Той жа чалавечы фактар ніхто не адмяняў.
На наступным малюнку мы бачым, што адбываецца рэзкі скачок часу выканання аперацый на сэрвісе. Пачатак гэтага скачка супадае з часам дэплою на дадатак. Усю гэтую інфармацыю ў якасці падзей мы перадаем у сістэму аўтаматызацыі. Калі працаздольнасць сэрвісу не нармалізуецца па заканчэнні зададзенага намі часу, то аўтаматычна выклікаецца скрыпт, які вырабляе адкат версіі да старой.
Дэградацыя прадукцыйнасці аперацый пасля дэплою.
2. Загрузка рэсурсаў пад 100% - дадаць ноду ў маршрутызацыю
На наступным прыкладзе сістэма маніторынгу вызначае, што на адным з кампанентаў назіраецца загрузка CPU на 100 працэнтаў.
Загрузка CPU 100%
Па гэтай падзеі магчыма некалькі розных сцэнарыяў. Напрыклад, сістэма маніторынгу правярае дадаткова, ці звязаны недахоп рэсурсаў з ростам нагрузкі на сэрвіс. Калі, ды то выконваецца скрыпт, які аўтаматычна дадае ноду ў маршрутызацыю, тым самым аднаўляючы працаздольнасць сістэмы ў цэлым.
Маштабаванне пад пасля інцыдэнту
3. Адсутнасць месца на цвёрдым дыску - чыстка дыска
Я думаю, што дадзеныя працэсы ў многіх ужо аўтаматызаваны. З дапамогай APM таксама можна сачыць за вольным месцам на дыскавай падсістэме. Пры адсутнасці месца ці павольнай працы дыска выкліканы скрыпт для чысткі або дадаем месца.
Загрузка дыска 100%
4. Нізкая актыўнасць карыстальнікаў або нізкая канверсія - пераключэнне паміж сіняй і зялёнай галінкай
Я часта сустракаю заказчыкаў, якія выкарыстоўваюць два контуры (blue-green deploy) для прыкладанняў у прад асяроддзі. Гэта дазваляе хутка перамыкацца паміж галінкамі пры дастаўцы новых рэлізаў. Часта пасля дэплою могуць адбыцца кардынальныя змены, якія не адразу ўдаецца заўважыць. Пры гэтым дэградацыя па прадукцыйнасці і даступнасці можа не назірацца. Для аператыўнага рэагавання на такія змены лепш выкарыстоўваць розныя метрыкі, якія адлюстроўваюць паводзін карыстальнікаў (колькасць сесій і дзеянняў карыстальнікаў, канверсія, bounce rate). На наступным малюнку паказаны прыклад, на якім пры падзенні канверсіі адбываецца пераключэнне паміж галінкамі ПЗ.
Падзенне канверсіі пасля пераключэння паміж галінкамі ПЗ.
Механізмы аўтаматычнага вызначэння праблем
У канцы прывяду яшчэ адзін прыклад, завошта мне больш за ўсё падабаецца Dynatrace.
У частцы майго аповеду пра аўтаматызацыю праверкі якасці зборак у тэставым асяроддзі ўсе парогавыя значэнні мы вызначалі ў ручным рэжыме. Для тэставага асяроддзя гэта нармальна, тэсціроўшчык сам вызначае паказчыкі перад кожнай праверкай у залежнасці ад нагрузкі. У прод асяроддзі пажадана, каб праблемы выяўляліся аўтаматычны з улікам розных механізмаў baseline.
Dynatrace мае цікавыя ўбудаваныя прылады штучнага інтэлекту, якія на аснове механізмаў вызначэння анамальных метрык (baselining) і пабудовы карты ўзаемадзеяння паміж усімі кампанентамі, супастаўляючы і карэлюючы падзеі паміж сабой, вызначаюць анамаліі ў працы вашага сэрвісу і падаюць дэталізаваную інфармацыю па кожнай праблеме і каранёвай прычыне.
Шляхам аўтаматычнага аналізу залежнасцяў паміж кампанентамі Dynatrace вызначае не толькі тое, ці з'яўляецца праблемная служба асноўнай прычынай, але і яе залежнасць ад іншых службаў. У прыведзеным ніжэй прыкладзе Dynatrace аўтаматычна адсочвае і ацэньвае працаздольнасць кожнага сэрвісу ў рамках выканання транзакцый, ідэнтыфікуе службу Golang у якасці асноўнай прычыны.
Прыклад вызначэння каранёвай прычыны збою.
На наступным малюнку намаляваны працэс маніторынгу праблем з вашым дадаткам са старту інцыдэнту.
Візуалізацыя ўзнікае праблемы з адлюстраваннем усіх кампанентаў і падзей на іх
Сістэма маніторынгу сабрала поўную храналогію падзей па ўзнікшай праблеме. У акне пад часовым графікам мы бачым усе ключавыя падзеі на кожным з кампанентаў. Па дадзеных падзеях вы можаце задаць працэдуры для аўтаматычнага выпраўлення ў выглядзе сцэнараў кода.
Дадаткова раю інтэграваць сістэму маніторынгу з Service Desk ці баг-трэкер. Пры ўзнікненні праблемы распрацоўшчыкі аператыўна атрымліваюць поўную інфармацыю для яе аналізу на ўзроўні кода ў прадасяроддзі.
Заключэнне
У выніку ў нас атрымаўся канвеер CI/CD са ўбудаванымі аўтаматызаванымі праверкамі якасці ПЗ у Pipeline. Мы мінімізуем колькасць няякасных зборак, падвышаем надзейнасць сістэмы ў цэлым і, калі ў нас усёткі парушаецца працаздольнасць сістэмы, мы запускаем механізмы па яе ўзнаўленню.
У аўтаматызацыю маніторынгу якасці ПЗ сапраўды варта ўкладваць намаганні, не заўсёды гэта хуткі працэс, але з часам ён прынясе свой плён. Рэкамендую пасля рашэння новага інцыдэнту ў прод асяроддзі адразу прадумаць аб тым, якія маніторы дадаць для праверак у тэставым асяроддзі ў пазбяганне траплення дрэннай зборкі ў прод, а таксама скласці скрыпт для аўтаматычнага выпраўлення дадзеных праблем.
Спадзяюся, мае прыклады дапамогуць вам у вашых пачынаннях. Таксама мне будзе цікава ўбачыць вашыя прыклады выкарыстоўваных метрык для рэалізацыі самааднаўлення працаздольнасці сістэм.
Крыніца: habr.com