Nun la temo de DevOps estas en hype. Kontinua Integriĝo kaj Livera Dukto ĉiuj efektivigas ĝin. Sed la plej multaj ne ĉiam atentas certigi la fidindecon de informsistemoj en diversaj stadioj de la CI/CD-Dukto. En ĉi tiu artikolo mi ŝatus paroli pri mia sperto pri aŭtomatigo de programaraj kvalitkontroloj kaj efektivigo de eblaj scenaroj por ĝia "mem-resanigo".
Mi laboras kiel inĝeniero en la fako pri administrado de IT-servo de firmao . Mia kerna kompetenteco estas la efektivigo de diversaj aplikaĵaj agado kaj haveblecaj monitoraj sistemoj. Mi ofte komunikas kun IT-klientoj de malsamaj merkatsegmentoj pri aktualaj aferoj pri monitorado de la kvalito de iliaj IT-servoj. La ĉefa celo estas minimumigi la eldonciklotempon kaj pliigi la oftecon de eldonoj. Ĉi tio, kompreneble, estas tute bona: pli da eldonoj - pli da novaj funkcioj - pli kontentaj uzantoj - pli da profito. Sed fakte, aferoj ne ĉiam funkcias bone. Kun tre altaj deplojprocentoj, la demando tuj ekestas pri la kvalito de niaj eldonoj. Eĉ kun plene aŭtomatigita dukto, unu el la plej grandaj defioj estas movi servojn de testado al produktado sen influi aplikaĵon kaj uzantan sperton.
Surbaze de la rezultoj de multnombraj konversacioj kun klientoj, mi povas diri, ke liberigas kvalitan kontrolon, la problemon de fidindeco de aplikaĵo kaj la ebleco de ĝia "mem-resanigo" (ekzemple, reveni al stabila versio) en diversaj stadioj de la CI. /KD-dukto estas inter la plej ekscitaj kaj rilataj temoj.
Lastatempe mi mem laboris ĉe la klienta flanko - en la interreta banka aplika programaro-subtena servo. La arkitekturo de nia aplikaĵo uzis grandan nombron da memskribitaj mikroservoj. La plej malĝoja estas, ke ne ĉiuj programistoj povis elteni la altan ritmon de disvolviĝo; la kvalito de iuj mikroservoj suferis, kio kaŭzis amuzajn kromnomojn por ili kaj iliaj kreintoj. Estis rakontoj pri kiaj materialoj ĉi tiuj produktoj estis faritaj.
"Formulo de la problemo"
La alta ofteco de eldonoj kaj granda nombro da mikroservoj malfaciligas kompreni la funkciadon de la aplikaĵo entute, kaj en la testa stadio kaj en la funkcia stadio. Ŝanĝoj okazas konstante kaj estas tre malfacile kontroli ilin sen bonaj monitoraj iloj. Ofte, post nokta liberigo matene, programistoj sidas kiel sur pulvobarelo kaj atendas ke nenio rompiĝu, kvankam ĉiuj kontroloj sukcesis en la testa stadio.
Estas unu plia punkto. En la prova etapo, la funkcieco de la programaro estas kontrolita: la efektivigo de la ĉefaj funkcioj de la aplikaĵo kaj la foresto de eraroj. Kvalitaj agado-taksoj aŭ mankas aŭ ne konsideras ĉiujn aspektojn de la aplikaĵo kaj la integriga tavolo. Iuj metrikoj eble tute ne estas kontrolitaj. Kiel rezulto, kiam paneo okazas en produktadmedio, la fako de teknika subteno nur ekscias pri tio kiam veraj uzantoj komencas plendi. Mi ŝatus minimumigi la efikon de malaltkvalita programaro sur finaj uzantoj.
Unu el la solvoj estas efektivigi procezojn por kontroli softvarkvaliton en diversaj stadioj de la CI/CD Pipeline, kaj aldoni diversajn scenarojn por restarigi la sistemon en kazo de krizo. Ni ankaŭ memoras, ke ni havas DevOps. Komercoj atendas ricevi novan produkton kiel eble plej rapide. Tial, ĉiuj niaj ĉekoj kaj skriptoj devas esti aŭtomatigitaj.
La tasko estas dividita en du komponentojn:
- kvalita kontrolo de asembleoj en la testa stadio (por aŭtomatigi la procezon de kaptado de malaltkvalitaj asembleoj);
- programara kvalito-kontrolo en la produktadmedio (mekanismoj por aŭtomata detekto de problemoj kaj eblaj scenaroj por ilia mem-resaniĝo).
Ilo por monitorado kaj kolektado de metrikoj
Por atingi la fiksitajn celojn, necesas monitora sistemo, kiu povas detekti problemojn kaj transdoni ilin al aŭtomatigaj sistemoj en diversaj stadioj de la CI/KD-dukto. Ankaŭ estos pozitiva afero, se ĉi tiu sistemo provizas utilajn metrikojn por diversaj teamoj: disvolviĝo, testado, funkciado. Kaj ĝi estas absolute mirinda se ĝi ankaŭ estas por komerco.
Por kolekti metrikojn, vi povas uzi aron da malsamaj sistemoj (Prometheus, ELK Stack, Zabbix, ktp.), sed, laŭ mi, APM-klasaj solvoj plej taŭgas por ĉi tiuj taskoj (), kiu povas multe simpligi vian vivon.
Kiel parto de mia laboro en la subtena servo, mi komencis fari similan projekton uzante APM-klasan solvon de Dynatrace. Nun, laborante por integristo, mi sufiĉe bone konas la merkaton de monitoraj sistemoj. Mia subjektiva opinio: Dynatrace plej taŭgas por solvi tiajn problemojn.
Dynatrace disponigas horizontalan vidon de ĉiu uzantoperacio sur grajneca nivelo ĝis la koda ekzekutnivelo. Vi povas spuri la tutan ĉenon de interagado inter diversaj informaj servoj: de la antaŭfinaj niveloj de retejo kaj moveblaj aplikoj, malantaŭaj aplikaĵserviloj, integriga buso ĝis specifa alvoko al la datumbazo.
. Aŭtomata konstruado de ĉiuj dependecoj inter sistemaj komponantoj
. Aŭtomata detekto kaj konstruado de la servo-operacia vojo
Ni ankaŭ memoras, ke ni devas integriĝi kun diversaj aŭtomatigaj iloj. Ĉi tie la solvo havas oportunan API, kiu ebligas al vi sendi kaj ricevi diversajn metrikojn kaj eventojn.
Poste, ni transiru al pli detala rigardo pri kiel solvi ĉi tiujn problemojn uzante la Dynatrace-sistemon.
Tasko 1. Aŭtomatigo de kvalito-kontrolo de asembleoj ĉe la testa stadio
La unua defio estas trovi problemojn kiel eble plej frue en la aplikaĵa livero-dukto. Nur "bonaj" kodaj konstruoj devas atingi produktadon. Por fari tion, via dukto ĉe la testa stadio devus inkluzivi pliajn monitorojn por kontroli la kvaliton de viaj servoj.
Ni rigardu paŝon post paŝo kiel efektivigi ĉi tion kaj aŭtomatigi ĉi tiun procezon:
La figuro montras la fluon de aŭtomatigitaj programaj kvalitprovaj paŝoj:
- deplojo de monitora sistemo (instalado de agentoj);
- identigi eventojn por taksi la kvaliton de via programaro (metrikoj kaj sojlaj valoroj) kaj transdoni ilin al la monitora sistemo;
- generacio de testoj pri ŝarĝo kaj rendimento;
- kolektado de rendimento kaj haveblecaj datumoj en la monitora sistemo;
- translokigo de testdatenoj bazitaj sur programaraj kvalittaksaj eventoj de la monitora sistemo al la CI/CD-sistemo. Aŭtomata analizo de asembleoj.
Paŝo 1. Disvolviĝo de la monitora sistemo
Unue vi devas instali la agentojn en via testa medio. Samtempe, la solvo Dynatrace havas belan funkcion - ĝi uzas la universalan agenton OneAgent, kiu estas instalita sur OS-instanco (Vindozo, Linukso, AIX), aŭtomate detektas viajn servojn kaj komencas kolekti monitorajn datumojn pri ili. Vi ne bezonas agordi apartan agenton por ĉiu procezo. La situacio estos simila por nubaj kaj ujplatformoj. Samtempe, vi ankaŭ povas aŭtomatigi la procezon de instalado de agento. Dynatrace persvadas perfekte en la "infrastrukturo kiel kodo" koncepto (): Estas pretaj skriptoj kaj instrukcioj por ĉiuj popularaj platformoj. Vi enigas la agenton en la agordon de via servo, kaj kiam vi deplojas ĝin, vi tuj ricevas novan servon kun jam funkcianta agento.
Paŝo 2: Difinu viajn programajn kvalitajn eventojn
Nun vi devas decidi pri la listo de servoj kaj komercaj operacioj. Gravas konsideri ĝuste tiujn uzantoperaciojn, kiuj estas komercaj kritikaj por via servo. Ĉi tie mi rekomendas konsulti kun komercaj kaj sistemaj analizistoj.
Poste, vi devas determini kiajn metrikojn vi volas inkludi en la revizio por ĉiu nivelo. Ekzemple, tio povus esti ekzekuttempo (dividita en mezumo, mediano, procentoj, ktp.), eraroj (logikaj, servo, infrastrukturo, ktp.) kaj diversaj infrastrukturaj metrikoj (memoramaso, rubokolektilo, fadenkalkulo, ktp.).
Por aŭtomatigo kaj facileco de uzo de la teamo DevOps, aperas la koncepto "Monitorado kiel Kodo". Kion mi volas diri per ĉi tio, estas, ke programisto/testilo povas skribi simplan JSON-dosieron, kiu difinas mezurojn pri kvalita certigo de programaro.
Ni rigardu ekzemplon de tia JSON-dosiero. Objektoj de la Dynatrace API estas uzataj kiel ŝlosilaj/valoraj paroj (API-priskribo troveblas ĉi tie ).
{
"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
}
]
}La dosiero estas tabelo de temposeriodifinoj:
- timeseriesId - la metriko estanta kontrolita, ekzemple, Respondtempo, Erarkalkulo, Memoro uzata, ktp.;
- aggregation - nivelo de metrika agregado, en nia kazo averg, sed vi povas uzi iun ajn, kiun vi bezonas (avg, min, max, sum, count, percentile);
- etikedoj - objekta etikedo en la monitora sistemo, aŭ vi povas specifi specifan objektan identigilon;
- severa kaj averto - ĉi tiuj indikiloj reguligas la sojlaj valoroj de niaj metrikoj; se la testa valoro superas la severan sojlon, tiam nia konstruo estas markita kiel ne sukcesa.
La sekva figuro montras ekzemplon de la uzo de tiaj sojloj.
Paŝo 3: Ŝarĝu Generacio
Post kiam ni determinis la kvalitajn nivelojn de nia servo, ni devas generi testan ŝarĝon. Vi povas uzi iun ajn el la testaj iloj kun kiuj vi komfortas, kiel Jmeter, Selenium, Neotys, Gatling, ktp.
La monitoradsistemo de Dynatrace permesas vin kapti diversajn metadatenojn de viaj testoj kaj rekoni kiuj testoj apartenas al kiu eldonciklo kaj kiu servo. Oni rekomendas aldoni pliajn kapliniojn al HTTP-testpetoj.
La sekva figuro montras ekzemplon, kie, uzante la kroman kaplinion X-Dynatrace-Test, ni indikas, ke ĉi tiu testo rilatas al testado de la operacio aldoni eron al la ĉaro.
Kiam vi faras ĉiun ŝarĝteston, vi sendas pliajn kuntekstan informon al Dynatrace uzante la Event API de la CI/CD-servilo. Tiamaniere, la sistemo povas diferencigi malsamajn provojn.
. Evento en la monitora sistemo pri la komenco de ŝarĝtestado
Paŝo 4-5. Kolektu rendimentajn datumojn kaj transigu datumojn al la CI/CD-sistemo
Kune kun la generita testo, evento estas transdonita al la monitora sistemo pri la bezono kolekti datumojn pri kontrolado de servokvalitaj indikiloj. Ĝi ankaŭ specifas nian JSON-dosieron, kiu difinas la ŝlosilajn metrikojn.
Evento pri la bezono kontroli la kvaliton de programaro generita sur la CI/KD-servilo por sendado al la monitora sistemo
En nia ekzemplo, la kvalitkontrola evento estas nomita perfSigDynatraceReport (Efikeco_Signo) - ĉi tio estas preta por integriĝo kun Jenkins, kiu estis evoluigita de la uloj de T-Systems Multimedia Solutions. Ĉiu testa lanĉa evento enhavas informojn pri la servo, konstrunumero kaj testa tempo. La kromaĵo kolektas rendimentajn valorojn je konstrua tempo, taksas ilin kaj komparas la rezulton kun antaŭaj konstruoj kaj nefunkciaj postuloj.
Evento en la monitora sistemo pri la komenco de konstrukvalita kontrolo.
Post kiam la testo finiĝas, ĉiuj metrikoj por taksi softvarkvaliton estas translokigitaj reen al kontinua integriga sistemo, ekzemple Jenkins, kiu generas raporton pri la rezultoj.
La rezulto de statistiko pri asembleoj sur la CI/CD-servilo.
Por ĉiu individua konstruo, ni vidas statistikojn por ĉiu metriko, kiun ni starigis dum la tuta testo. Ni ankaŭ vidas, ĉu estis malobservoj en iuj sojlaj valoroj (averto kaj severaj draŝoj). Surbaze de entuta metriko, la tuta konstruo estas markita kiel stabila, malstabila aŭ malsukcesa. Ankaŭ, por komforto, vi povas aldoni indikilojn al la raporto komparante la nunan konstruon kun la antaŭa.
Rigardu detalajn statistikojn pri asembleoj sur la CI/CD-servilo.
Detala komparo de du asembleoj
Se necese, vi povas iri al la interfaco de Dynatrace kaj tie vi povas vidi la statistikojn por ĉiu el viaj konstruaĵoj pli detale kaj kompari ilin unu kun la alia.
Komparo de konstrustatistikoj en Dynatrace.
trovoj
Kiel rezulto, ni ricevas servon de "monitorado kiel servo", aŭtomatigita en la kontinua integriga dukto. La programisto aŭ testilo nur bezonas difini liston de metrikoj en JSON-dosiero, kaj ĉio alia okazas aŭtomate. Ni ricevas travideblan kvalitkontrolon de eldonoj: ĉiuj sciigoj pri rendimento, konsumo de rimedoj aŭ arkitekturaj regresoj.
Tasko 2. Aŭtomatigo de programara kvalitkontrolo en produktadmedio
Do, ni solvis la problemon kiel aŭtomatigi la monitoran procezon ĉe la testa stadio en Pipeline. Tiel ni minimumigas la procenton de malaltkvalitaj asembleoj, kiuj atingas la produktadmedion.
Sed kion fari se malbona programaro finas vendiĝi, aŭ io nur rompiĝas. Por utopio, ni volis mekanismojn por aŭtomate detekti problemojn kaj, se eble, la sistemo mem por restarigi sian funkciecon, almenaŭ nokte.
Por fari tion, ni devas, analoge kun la antaŭa sekcio, provizi aŭtomatajn programajn kvalitkontrolojn en la produktadmedio kaj bazi ilin sur scenaroj por sistema mem-resanigo.
Aŭtokorektu kiel kodo
Plej multaj kompanioj jam havas amasigitan scion de diversaj specoj de komunaj problemoj kaj liston de agoj por ripari ilin, ekzemple, rekomenci procezojn, purigi rimedojn, restarigi versiojn, restarigi nevalidajn agordajn ŝanĝojn, pliigi aŭ malpliigi la nombron da komponantoj en la areto, ŝanĝante la bluan aŭ verdan konturon kaj ktp.
Kvankam ĉi tiuj uzkazoj estas konataj de multaj el la teamoj kun kiuj mi parolas, malmultaj pensis aŭ investis en aŭtomatigi ilin.
Se vi pensas pri tio, estas nenio tro komplika en efektivigado de procezoj por memresaniga aplikaĵo-agado; vi devas prezenti la jam konatajn laborscenarojn de viaj administrantoj en formo de kodaj skriptoj (la koncepto "aŭtofiki kiel kodo"). , kiun vi skribis anticipe por ĉiu specifa kazo. Aŭtomataj riparaj skriptoj devas celi forigi la radikan kaŭzon de la problemo. Vi mem determinas la ĝustajn agojn por respondi al okazaĵo.
Ajna metriko de via monitora sistemo povas funkcii kiel ellasilo por lanĉi la skripton, la ĉefa afero estas, ke ĉi tiuj metrikoj precize determinas, ke ĉio estas malbona, ĉar vi ne volus ricevi falsajn pozitivojn en produktiva medio.
Vi povas uzi ajnan sistemon aŭ aron de sistemoj: Prometheus, ELK Stack, Zabbix, ktp. Sed mi donos kelkajn ekzemplojn bazitajn sur APM-solvo (Dynatrace denove estos ekzemplo), kiuj ankaŭ helpos faciligi vian vivon.
Unue, estas ĉio rilata al agado laŭ aplika funkciado. La solvo provizas centojn da metrikoj je diversaj niveloj, kiujn vi povas uzi kiel ellasilon:
- uzantnivelo (retumiloj, moveblaj aplikoj, IoT-aparatoj, uzantkonduto, konvertiĝo, ktp.);
- nivelo de servo kaj operacioj (efikeco, havebleco, eraroj, ktp.);
- aplika infrastruktura nivelo (gastiga OS-metriko, JMX, MQ, retservilo, ktp.);
- platforma nivelo (virtualigo, nubo, ujo, ktp.).
Monitorado de niveloj en Dynatrace.
Due, kiel mi diris pli frue, Dynatrace havas malfermitan API, kiu faciligas integriĝon kun diversaj triaj sistemoj. Ekzemple, sendante sciigon al la aŭtomatiga sistemo kiam kontrolaj parametroj estas superitaj.
Malsupre estas ekzemplo por interagi kun Ansible.
Malsupre mi donos kelkajn ekzemplojn pri kia aŭtomatigo povas esti farita. Ĉi tio estas nur parto de la kazoj; ilia listo en via medio povas esti limigita nur de via imago kaj la kapabloj de viaj monitoraj iloj.
1. Malbona deplojo - versio-reveno
Eĉ se ni testas ĉion tre bone en testa medio, ankoraŭ ekzistas ŝanco, ke nova eldono povus mortigi vian aplikaĵon en produktadmedio. La sama homa faktoro ne estis nuligita.
En la sekva figuro ni vidas, ke estas akra salto en la ekzekuttempo de operacioj sur la servo. La komenco de ĉi tiu salto koincidas kun la tempo de deplojo al la aplikaĵo. Ni transdonas ĉiujn ĉi tiujn informojn kiel eventojn al la aŭtomatiga sistemo. Se la agado de la servo ne normaliĝas post la tempo, kiun ni fiksis, tiam skripto estas aŭtomate vokita, kiu retroiras la version al la malnova.
Degradiĝo de operacia rendimento post deplojo.
2. Rimedo-ŝarĝado je 100% - aldonu nodon al enrutado
En la sekva ekzemplo, la monitora sistemo determinas ke unu el la komponantoj spertas 100% CPU-ŝarĝon.
CPU-ŝarĝo 100%
Estas pluraj malsamaj scenaroj eblaj por ĉi tiu evento. Ekzemple, la monitora sistemo aldone kontrolas ĉu la manko de rimedoj rilatas al pliigo de la ŝarĝo de la servo. Se jes, tiam skripto estas ekzekutita, kiu aŭtomate aldonas nodon al la vojigo, tiel restarigante la funkciecon de la sistemo kiel tutaĵo.
Skalado post okazaĵo
3. Manko de spaco sur la malmola disko - purigado de disko
Mi pensas, ke multaj homoj jam aŭtomatigis ĉi tiujn procezojn. Uzante APM, vi ankaŭ povas monitori la liberan spacon sur la disksubsistemo. Se mankas spaco aŭ la disko funkcias malrapide, ni vokas skripton por purigi ĝin aŭ aldoni spacon.
Diskoŝarĝo 100%
4. Malalta uzantaktiveco aŭ malalta konvertiĝo - ŝanĝi inter bluaj kaj verdaj branĉoj
Mi ofte vidas klientojn uzante du buklojn (blu-verda deplojo) por aplikoj en produktadmedio. Ĉi tio permesas vin rapide ŝanĝi inter branĉoj dum liverado de novaj eldonoj. Ofte, post deplojo, dramecaj ŝanĝoj povas okazi, kiuj ne estas tuj rimarkeblaj. En ĉi tiu kazo, degenero en rendimento kaj havebleco eble ne estas observitaj. Por rapide respondi al tiaj ŝanĝoj, estas pli bone uzi diversajn metrikojn, kiuj reflektas uzantan konduton (nombro da sesioj kaj uzant-agoj, konvertiĝo, resalto). La sekva figuro montras ekzemplon en kiu, kiam konvertaj indicoj malpliiĝas, okazas ŝanĝado inter programaraj branĉoj.
Konverta indico falas post ŝanĝado inter programaraj branĉoj.
Mekanismoj por aŭtomata problemo-detekto
Fine, mi donos al vi plian ekzemplon pri kial mi plej ŝatas Dynatrace.
En la parto de mia rakonto pri aŭtomatigo de kvalitkontroloj de asembleoj en testa medio, ni determinis ĉiujn sojlovalorojn permane. Ĉi tio estas normala por testa medio; la testilo mem determinas la indikilojn antaŭ ĉiu testo depende de la ŝarĝo. En produktadmedio, estas dezirinde ke problemoj estas detektitaj aŭtomate, konsiderante diversajn bazliniajn mekanismojn.
Dynatrace havas interesajn enkonstruitajn ilojn de artefarita inteligenteco, kiuj, surbaze de mekanismoj por determini anomaliajn metrikojn (bazlinio) kaj konstrui mapon de interago inter ĉiuj komponantoj, komparante kaj korelaciantajn eventojn inter si, determinas anomaliojn en la funkciado de via servo kaj provizas detalajn. informojn pri ĉiu problemo kaj radika kaŭzo.
Aŭtomate analizante dependecojn inter komponantoj, Dynatrace determinas ne nur ĉu la problema servo estas la radika kaŭzo, sed ankaŭ ĝia dependeco de aliaj servoj. En la suba ekzemplo, Dynatrace aŭtomate kontrolas kaj taksas la sanon de ĉiu servo ene de la transakcia ekzekuto, identigante la Golang-servon kiel la radika kaŭzo.
Ekzemplo de determinado de la radika kaŭzo de fiasko.
La sekva figuro montras la procezon de monitorado de problemoj kun via aplikaĵo ekde la komenco de okazaĵo.
Bildigo de emerĝanta problemo kun montrado de ĉiuj komponantoj kaj eventoj sur ili
La monitora sistemo kolektis kompletan kronologion de eventoj rilataj al la aperinta problemo. En la fenestro sub la templinio ni vidas ĉiujn ŝlosilajn eventojn pri ĉiu el la komponantoj. Surbaze de ĉi tiuj eventoj, vi povas agordi procedurojn por aŭtomata korekto en formo de kodaj skriptoj.
Aldone, mi konsilas al vi integri monitoran sistemon kun Service Desk aŭ cimspurilo. Kiam problemo okazas, programistoj rapide ricevas kompletajn informojn por analizi ĝin je la kodnivelo en la produktadmedio.
konkludo
Kiel rezulto, ni finis kun CI/KD-dukto kun enkonstruitaj aŭtomatigitaj programaraj kvalitkontroloj en Pipeline. Ni minimumigas la nombron da malaltkvalitaj asembleoj, pliigas la fidindecon de la sistemo entute, kaj se nia sistemo ankoraŭ malsukcesas, ni lanĉas mekanismojn por restarigi ĝin.
Nepre indas investi penon por aŭtomatigi programaran kvalitan monitoradon; ĝi ne ĉiam estas rapida procezo, sed kun la tempo ĝi donos fruktojn. Mi rekomendas, ke post solvado de nova okazaĵo en la produktadmedio, vi tuj pensu pri kiuj monitoroj aldoni por kontroloj en la testa medio por eviti ke malbona konstruo eniru en produktadon, kaj ankaŭ krei skripton por aŭtomate korekti ĉi tiujn problemojn.
Mi esperas, ke miaj ekzemploj helpos vin en viaj klopodoj. Mi ankaŭ interesiĝos vidi viajn ekzemplojn de metrikoj uzataj por efektivigi mem-resanigajn sistemojn.
fonto: www.habr.com