Most a DevOps témája a hype. Folyamatos integrációs és szállítási csővezeték mindenki végrehajtja. A legtöbb azonban nem mindig fordít kellő figyelmet az információs rendszerek megbízhatóságának biztosítására a CI/CD Pipeline különböző szakaszaiban. Ebben a cikkben a szoftverminőség-ellenőrzések automatizálása és az „öngyógyítás” lehetséges forgatókönyveinek megvalósítása terén szerzett tapasztalataimról szeretnék beszélni.
Mérnökként dolgozom egy cég IT szolgáltatásmenedzsment osztályán . Fő szakterületem különböző alkalmazások teljesítmény- és rendelkezésre állásfigyelő rendszerek megvalósítása. Gyakran kommunikálok a különböző piaci szegmensekből érkező informatikai ügyfelekkel informatikai szolgáltatásaik minőségének ellenőrzésével kapcsolatos aktuális kérdésekről. A fő cél a kibocsátási ciklus idejének minimalizálása és a kibocsátások gyakoriságának növelése. Ez természetesen mind jó: több kiadás - több új funkció - elégedettebb felhasználók - több profit. De a valóságban a dolgok nem mindig mennek jól. A nagyon magas telepítési arány mellett azonnal felmerül a kérdés a kiadásaink minőségével kapcsolatban. Még egy teljesen automatizált folyamat esetén is az egyik legnagyobb kihívás a szolgáltatások tesztelésről a termelésre való áthelyezése anélkül, hogy ez befolyásolná az alkalmazások üzemidejét és a felhasználói élményt.
Az ügyfelekkel folytatott számos beszélgetés eredménye alapján kijelenthetem, hogy a kiadás minőség-ellenőrzése, az alkalmazás megbízhatóságának problémája és „öngyógyulásának” lehetősége (például stabil verzióra való visszagörgetés) a CI különböző szakaszaiban. A /CD pipeline a legizgalmasabb és legrelevánsabb témák közé tartozik.
A közelmúltban magam is az ügyféloldalon dolgoztam - az online banki alkalmazásszoftver-támogató szolgáltatásban. Alkalmazásunk architektúrája nagyszámú saját írású mikroszolgáltatást használt. A legszomorúbb az, hogy nem minden fejlesztő tudott megbirkózni a nagy ütemű fejlesztéssel, egyes mikroszolgáltatások minősége megsérült, ami vicces beceneveket eredményezett számukra és alkotóik számára. Voltak történetek arról, hogy milyen anyagokból készültek ezek a termékek.
"A probléma megfogalmazása"
A kiadások magas gyakorisága és a mikroszolgáltatások nagy száma megnehezíti az alkalmazás egészének működését, mind a tesztelési, mind az üzemeltetési szakaszban. Változások folyamatosan történnek, és jó felügyeleti eszközök nélkül nagyon nehéz ellenőrizni őket. Gyakran a reggeli éjszakai kiadás után a fejlesztők úgy ülnek, mint a porhordón, és várják, hogy semmi se törjön el, bár a tesztelési szakaszban minden ellenőrzés sikeres volt.
Van még egy pont. A tesztelési szakaszban ellenőrzik a szoftver működőképességét: az alkalmazás fő funkcióinak megvalósítását és a hibák hiányát. A minőségi teljesítményértékelések vagy hiányoznak, vagy nem veszik figyelembe az alkalmazás és az integrációs réteg minden aspektusát. Előfordulhat, hogy egyes mutatókat egyáltalán nem ellenőriz. Ennek eredményeként, ha egy üzemi környezetben meghibásodás történik, a műszaki támogatási osztály csak akkor értesül róla, amikor a valódi felhasználók panaszkodni kezdenek. Szeretném minimalizálni az alacsony minőségű szoftverek végfelhasználókra gyakorolt hatását.
Az egyik megoldás a szoftver minőségének ellenőrzésére szolgáló folyamatok megvalósítása a CI/CD Pipeline különböző szakaszaiban, és különféle forgatókönyvek hozzáadása a rendszer vészhelyzet esetén történő visszaállításához. Arra is emlékszünk, hogy van DevOps-unk. A vállalkozások elvárják, hogy a lehető leggyorsabban megkapják az új terméket. Ezért minden ellenőrzésünket és szkriptünket automatizálni kell.
A feladat két részre oszlik:
- az összeállítások minőségellenőrzése a tesztelési szakaszban (az alacsony minőségű szerelvények elfogásának automatizálása érdekében);
- szoftver minőségellenőrzés a termelési környezetben (a problémák automatikus észlelésének mechanizmusai és öngyógyításuk lehetséges forgatókönyvei).
Eszköz a mérőszámok figyelésére és gyűjtésére
A kitűzött célok eléréséhez olyan monitoring rendszerre van szükség, amely képes észlelni a problémákat és átadni azokat az automatizálási rendszereknek a CI/CD folyamat különböző szakaszaiban. Az is pozitívum lesz, ha ez a rendszer hasznos mérőszámokat ad a különböző csapatoknak: fejlesztés, tesztelés, üzemeltetés. És ez teljesen csodálatos, ha üzleti célból is.
A mérőszámok gyűjtéséhez különböző rendszereket használhat (Prometheus, ELK Stack, Zabbix stb.), de véleményem szerint ezekre a feladatokra az APM-osztályú megoldások a legalkalmasabbak (), ami nagyban leegyszerűsítheti az életét.
A támogatási szolgáltatásban végzett munkám részeként elkezdtem egy hasonló projektet a Dynatrace APM osztályú megoldásával. Most, hogy egy integrátornál dolgozom, elég jól ismerem a felügyeleti rendszerek piacát. Szubjektív véleményem: Ilyen problémák megoldására a Dynatrace a legalkalmasabb.
A Dynatrace vízszintes nézetet biztosít minden felhasználói műveletről, egészen a kódvégrehajtási szintig. Nyomon követheti a különböző információs szolgáltatások közötti interakciók teljes láncolatát: a webes és mobilalkalmazások front-end szintjétől, a háttéralkalmazás-szervereken, az integrációs buszon át az adatbázishoz érkezett konkrét hívásokig.
. A rendszerelemek közötti összes függőség automatikus felépítése
. A szolgáltatás működési útvonalának automatikus felismerése és kialakítása
Emlékezzünk arra is, hogy integrálnunk kell különféle automatizálási eszközökkel. Itt a megoldás egy kényelmes API-val rendelkezik, amely lehetővé teszi különféle mutatók és események küldését és fogadását.
Ezután térjünk át egy részletesebb áttekintésre, hogyan lehet ezeket a problémákat megoldani a Dynatrace rendszer használatával.
1. feladat Szerelvények minőségellenőrzésének automatizálása a tesztelési szakaszban
Az első kihívás az, hogy a lehető legkorábban megtaláljuk a problémákat az alkalmazás-szállítási folyamatban. Csak a „jó” kódfelépítések érhetik el a termelést. Ehhez a tesztelési szakaszban lévő csővezetéknek további monitorokat kell tartalmaznia a szolgáltatások minőségének ellenőrzéséhez.
Lépésről lépésre nézzük meg, hogyan kell ezt megvalósítani és automatizálni a folyamatot:
Az ábra az automatizált szoftverminőség-tesztelési lépések menetét mutatja:
- monitoring rendszer kiépítése (ügynökök telepítése);
- események azonosítása a szoftver minőségének értékeléséhez (mérőszámok és küszöbértékek), és ezek átvitele a felügyeleti rendszerbe;
- terhelési és teljesítménytesztek generálása;
- teljesítmény- és rendelkezésre állási adatok gyűjtése a monitoring rendszerben;
- szoftverminőség-értékelési eseményeken alapuló tesztadatok átvitele a felügyeleti rendszerből a CI/CD rendszerbe. Összeállítások automatikus elemzése.
1. lépés: A felügyeleti rendszer telepítése
Először telepítenie kell az ügynököket a tesztkörnyezetbe. Ugyanakkor a Dynatrace megoldásnak van egy jó tulajdonsága is: az univerzális OneAgent ügynököt használja, amely egy operációs rendszer példányra van telepítve (Windows, Linux, AIX), automatikusan felismeri a szolgáltatásait, és elkezdi gyűjteni a megfigyelési adatokat. Nem kell külön ügynököt konfigurálnia minden folyamathoz. Hasonló lesz a helyzet a felhő- és konténerplatformok esetében is. Ugyanakkor automatizálhatja az ügynök telepítési folyamatát is. A Dynatrace tökéletesen illeszkedik az "infrastruktúra mint kód" koncepcióba (): Vannak kész szkriptek és utasítások minden népszerű platformhoz. Az ügynököt beágyazza a szolgáltatás konfigurációjába, és amikor telepíti, azonnal kap egy új szolgáltatást egy már működő ügynökkel.
2. lépés: Határozza meg a szoftverminőségi eseményeket
Most döntenie kell a szolgáltatások és az üzleti műveletek listájáról. Fontos, hogy pontosan azokat a felhasználói műveleteket vegye figyelembe, amelyek üzleti szempontból kritikusak a szolgáltatás szempontjából. Itt azt javaslom, hogy konzultáljon üzleti és rendszerelemzőkkel.
Ezután meg kell határoznia, hogy az egyes szinteken mely mutatókat kívánja belefoglalni a felülvizsgálatba. Ez lehet például a végrehajtási idő (átlagra, mediánra, százalékokra stb. felosztva), hibák (logikai, szolgáltatási, infrastruktúra stb.) és különféle infrastrukturális mérőszámok (memóriakupac, szemétgyűjtő, szálak száma stb.).
Az automatizálás és a DevOps csapat általi könnyebb használat érdekében megjelenik a „Monitoring as Code” koncepció. Ez alatt azt értem, hogy egy fejlesztő/tesztelő írhat egy egyszerű JSON-fájlt, amely meghatározza a szoftver minőségbiztosítási mérőszámait.
Nézzünk egy példát egy ilyen JSON-fájlra. A Dynatrace API objektumai kulcs/érték párokként használatosak (az API leírása itt található ).
{
"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
}
]
}A fájl idősor-definíciók tömbje:
- timeseriesId – az ellenőrzött mérőszám, például: Válaszidő, Hibaszám, Felhasznált memória stb.;
- aggregáció - a mérőszámok összesítési szintje, esetünkben avg, de bármelyiket használhatja, amire szüksége van (avg, min, max, sum, count, percentilis);
- tags – objektumcímke a megfigyelő rendszerben, vagy megadhat egy konkrét objektumazonosítót is;
- súlyos és figyelmeztető – ezek a mutatók szabályozzák mérőszámaink küszöbértékeit; ha a tesztérték meghaladja a súlyos küszöböt, akkor a buildünk nem sikeresnek minősül.
A következő ábra példát mutat az ilyen küszöbértékek használatára.
3. lépés: Betöltés generálása
Miután megállapítottuk szolgáltatásunk minőségi szintjeit, tesztterhelést kell generálnunk. Bármelyik tesztelő eszközt használhatja, amivel kényelmes, mint például a Jmeter, Selenium, Neotys, Gatling stb.
A Dynatrace megfigyelőrendszere lehetővé teszi, hogy különböző metaadatokat rögzítsen a tesztekből, és felismerje, hogy mely tesztek melyik kiadási ciklushoz és melyik szolgáltatáshoz tartoznak. Javasoljuk, hogy további fejléceket adjon hozzá a HTTP-teszt kérésekhez.
A következő ábra egy példát mutat be, ahol az X-Dynatrace-Test kiegészítő fejléc használatával jelezzük, hogy ez a teszt egy termék kosárba helyezésének működésének tesztelésére vonatkozik.
Minden egyes terhelési teszt futtatásakor további környezeti információkat küld a Dynatrace-nek az Event API használatával a CI/CD-kiszolgálóról. Ily módon a rendszer különbséget tud tenni a különböző tesztek között.
. Esemény a megfigyelő rendszerben a terhelési tesztelés kezdetéről
4-5. Gyűjtse össze a teljesítményadatokat, és vigye át az adatokat a CI/CD rendszerbe
A generált teszttel együtt egy esemény kerül továbbításra a felügyeleti rendszerbe a szolgáltatásminőségi mutatók ellenőrzésére vonatkozó adatok gyűjtésének szükségességéről. Meghatározza a JSON-fájlunkat is, amely meghatározza a legfontosabb mérőszámokat.
Esemény arról, hogy ellenőrizni kell a CI/CD szerveren generált szoftver minőségét a felügyeleti rendszerbe küldéshez
Példánkban a minőségellenőrzés esemény ún perfSigDynatraceReport (Performance_Signature) - ez kész a Jenkins-szel való integrációhoz, amelyet a T-Systems Multimedia Solutions srácai fejlesztettek ki. Minden tesztindítási esemény információkat tartalmaz a szolgáltatásról, a build számáról és a tesztelési időről. A beépülő modul összegyűjti a teljesítményértékeket a felépítés idején, kiértékeli azokat, és összehasonlítja az eredményt a korábbi buildekkel és a nem funkcionális követelményekkel.
Esemény a felügyeleti rendszerben az összeállítás minőségi ellenőrzésének megkezdéséről.
A teszt befejezése után a szoftverminőség értékelésére szolgáló összes mérőszám visszakerül egy folyamatos integrációs rendszerbe, például a Jenkins-be, amely jelentést készít az eredményekről.
A CI/CD szerveren lévő összeállításokra vonatkozó statisztikák eredménye.
Minden egyes összeállításhoz a teljes teszt során beállított összes mutatóhoz látunk statisztikákat. Azt is látjuk, hogy történt-e bizonyos küszöbértékek megsértése (figyelmeztetés és súlyos küszöbértékek). Az összesített mutatók alapján a teljes build stabilnak, instabilnak vagy sikertelennek van megjelölve. Ezenkívül a kényelem érdekében mutatókat is hozzáadhat a jelentéshez, amely összehasonlítja az aktuális buildet az előzővel.
Tekintse meg a CI/CD szerveren lévő összeállítások részletes statisztikáit.
Két szerelvény részletes összehasonlítása
Ha szükséges, a Dynatrace felületére léphetsz, és ott részletesebben megtekintheted az egyes buildek statisztikáit és összehasonlíthatod egymással.
A Dynatrace összeállítási statisztikáinak összehasonlítása.
Álláspontja
Ennek eredményeként a folyamatos integrációs folyamatban automatizált „monitoring mint szolgáltatás” szolgáltatást kapunk. A fejlesztőnek vagy tesztelőnek csak egy JSON-fájlban kell megadnia a metrikák listáját, és minden más automatikusan megtörténik. Átlátható minőség-ellenőrzést kapunk a kiadásokról: minden értesítést a teljesítményről, az erőforrás-felhasználásról vagy az építészeti regresszióról.
2. feladat Szoftverminőség-ellenőrzés automatizálása termelési környezetben
Tehát megoldottuk azt a problémát, hogyan automatizáljuk a megfigyelési folyamatot a Pipeline tesztelési szakaszában. Így minimalizáljuk a termelési környezetbe jutó gyenge minőségű szerelvények százalékos arányát.
De mi a teendő, ha rossz szoftvert adnak el, vagy valami elromlik. Egy utópiához olyan mechanizmusokat szerettünk volna, amelyek automatikusan észlelik a problémákat, és ha lehetséges, maga a rendszer is visszaállítja a működőképességét, legalább éjszaka.
Ehhez az előző részhez hasonlóan automatikus szoftverminőség-ellenőrzést kell biztosítanunk a termelési környezetben, és ezeket a rendszer önjavító forgatókönyveire kell alapozni.
Automatikus javítás kódként
A legtöbb vállalat már rendelkezik felhalmozott tudásbázissal a különböző típusú gyakori problémákról, valamint a megoldásukra szolgáló műveletek listájáról, például folyamatok újraindításáról, erőforrások tisztításáról, verziók visszaállításáról, érvénytelen konfigurációs módosítások visszaállításáról, az összetevők számának növeléséről vagy csökkentéséről. a klaszter, a kék vagy zöld körvonal váltása stb.
Míg ezeket a használati eseteket sok csapat, akikkel beszélgetek, évek óta ismeri, kevesen gondoltak rájuk, vagy fektettek be automatizálásukra.
Ha belegondolunk, az öngyógyító alkalmazások teljesítményét szolgáló folyamatok megvalósításában semmi sem túl bonyolult, a rendszergazdák már ismert munkaforgatókönyveit kódszkriptek formájában kell bemutatni (az „automatikus javítás kódként” koncepció) , amelyet minden konkrét esetre előre megírtál. Az automatikus javító szkripteknek a probléma kiváltó okának kiküszöbölésére kell irányulniuk. Ön maga határozza meg a megfelelő lépéseket egy eseményre való reagáláshoz.
A felügyeleti rendszer bármely mérőszáma triggerként működhet a szkript elindításához, a lényeg az, hogy ezek a mérőszámok pontosan meghatározzák, hogy minden rossz, mivel produktív környezetben nem szeretne hamis pozitív eredményeket kapni.
Bármilyen rendszert vagy rendszerkészletet használhat: Prometheus, ELK Stack, Zabbix stb. De mondok néhány példát egy APM-megoldás alapján (ismét a Dynatrace lesz példa), ami szintén megkönnyíti az életét.
Először is, minden a teljesítménnyel kapcsolatos az alkalmazás működése szempontjából. A megoldás több száz mérőszámot kínál különböző szinteken, amelyeket triggerként használhat:
- felhasználói szint (böngészők, mobilalkalmazások, IoT-eszközök, felhasználói viselkedés, konverzió stb.);
- a szolgáltatás és a működés szintje (teljesítmény, rendelkezésre állás, hibák stb.);
- alkalmazás infrastruktúra szintje (gazda operációs rendszer mérőszámai, JMX, MQ, webszerver stb.);
- platform szinten (virtualizáció, felhő, konténer stb.).
Szintek figyelése a Dynatrace-ben.
Másodszor, ahogy korábban mondtam, a Dynatrace nyitott API-val rendelkezik, ami nagyon megkönnyíti a különféle harmadik féltől származó rendszerekkel való integrálást. Például értesítés küldése az automatizálási rendszernek a szabályozási paraméterek túllépése esetén.
Az alábbiakban egy példa látható az Ansible-vel való interakcióra.
Az alábbiakban néhány példát mutatok be arra, hogy milyen automatizálást lehet végrehajtani. Ez csak egy része az eseteknek, listájuknak az Ön környezetében csak a fantáziája és a megfigyelő eszközeinek lehetősége szabhat határt.
1. Rossz telepítés – a verzió visszaállítása
Még ha mindent nagyon jól tesztelünk is tesztkörnyezetben, akkor is fennáll annak a lehetősége, hogy egy új kiadás megölheti az alkalmazást éles környezetben. Ugyanazt az emberi tényezőt nem törölték.
A következő ábrán azt látjuk, hogy éles ugrás tapasztalható a szolgáltatáson végzett műveletek végrehajtási idejében. Ennek az ugrásnak a kezdete egybeesik az alkalmazás telepítésének idejével. Mindezeket az információkat eseményként továbbítjuk az automatizálási rendszernek. Ha a szolgáltatás teljesítménye nem tér vissza a normál értékre az általunk beállított idő után, akkor automatikusan meghívódik egy szkript, amely visszaállítja a verziót a régire.
A működési teljesítmény romlása a telepítés után.
2. 100%-os erőforrás-betöltés – csomópont hozzáadása az útválasztáshoz
A következő példában a megfigyelő rendszer megállapítja, hogy az egyik összetevő 100%-os CPU-terhelést tapasztal.
CPU terhelés 100%
Ennek az eseménynek több különböző forgatókönyve is lehetséges. Például a felügyeleti rendszer azt is ellenőrzi, hogy az erőforrások hiánya összefügg-e a szolgáltatás terhelésének növekedésével. Ha igen, akkor egy parancsfájl kerül végrehajtásra, amely automatikusan hozzáad egy csomópontot az útválasztáshoz, ezáltal visszaállítja a rendszer egészének funkcionalitását.
Méretezés egy esemény után
3. Helyhiány a merevlemezen - lemez tisztítása
Szerintem sokan automatizálták már ezeket a folyamatokat. Az APM segítségével a lemezalrendszeren lévő szabad területet is figyelemmel kísérheti. Ha nincs hely, vagy a lemez lassan fut, hívunk egy parancsfájlt, hogy megtisztítsuk vagy helyet adjunk.
Lemezterhelés 100%
4. Alacsony felhasználói aktivitás vagy alacsony konverzió – váltás a kék és zöld ágak között
Gyakran látom, hogy az ügyfelek két hurkot (kék-zöld telepítés) használnak az alkalmazásokhoz éles környezetben. Ez lehetővé teszi a gyors váltást a fiókok között új kiadások kézbesítésekor. A telepítés után gyakran olyan drámai változások következhetnek be, amelyek nem azonnal észrevehetők. Ebben az esetben előfordulhat, hogy a teljesítmény és a rendelkezésre állás romlása nem figyelhető meg. Az ilyen változásokra való gyors reagáláshoz jobb, ha különböző mutatókat használ, amelyek tükrözik a felhasználói viselkedést (munkamenetek és felhasználói műveletek száma, konverzió, visszafordulási arány). A következő ábra egy olyan példát mutat be, amelyben a konverziós arányok csökkenésekor megtörténik a szoftverágak közötti váltás.
A szoftverágak közötti váltás után a konverziós arány csökken.
Automatikus problémafelismerési mechanizmusok
Végül mondok még egy példát arra, hogy miért szeretem a Dynatrace-t a legjobban.
Történetemnek az összeállítások tesztkörnyezetben történő minőségellenőrzésének automatizálásáról szóló részében az összes küszöbértéket manuálisan határoztuk meg. Ez normális tesztkörnyezetben, a tesztelő maga határozza meg a mutatókat minden teszt előtt a terheléstől függően. Éles környezetben kívánatos, hogy a problémákat a rendszer automatikusan észlelje, figyelembe véve a különféle alapmechanizmusokat.
A Dynatrace érdekes beépített mesterséges intelligencia eszközökkel rendelkezik, amelyek a rendellenes mutatók meghatározására (alapvonalazás) és az összes komponens közötti interakció térképének felépítésére, az események egymással való összehasonlítására és korrelációjára alapozva meghatározzák az anomáliákat a szolgáltatás működésében, és részletes tájékoztatást nyújtanak. információkat az egyes problémákról és kiváltó okról.
Az összetevők közötti függőségek automatikus elemzésével a Dynatrace nemcsak azt határozza meg, hogy a problémás szolgáltatás-e a kiváltó ok, hanem azt is, hogy más szolgáltatásoktól függ-e. Az alábbi példában a Dynatrace automatikusan figyeli és értékeli az egyes szolgáltatások állapotát a tranzakció végrehajtásán belül, és a Golang szolgáltatást azonosítja kiváltó okként.
Példa a hiba kiváltó okának meghatározására.
A következő ábra az alkalmazással kapcsolatos problémák megfigyelésének folyamatát mutatja az incidens kezdetétől.
Egy felmerülő probléma megjelenítése az összes összetevő és esemény megjelenítésével
A megfigyelő rendszer a felmerült problémával kapcsolatos események teljes kronológiáját gyűjtötte össze. Az idővonal alatti ablakban láthatjuk az egyes összetevők összes kulcsfontosságú eseményét. Ezen események alapján beállíthatja az automatikus javítási eljárásokat kódszkriptek formájában.
Ezenkívül azt javaslom, hogy integráljon egy megfigyelő rendszert a Service Desk szolgáltatással vagy egy hibakövetővel. Probléma esetén a fejlesztők gyorsan teljes körű információt kapnak, hogy azt kódszinten elemezzék az éles környezetben.
Következtetés
Ennek eredményeként egy CI/CD-folyamathoz jutottunk, amely beépített automatizált szoftverminőség-ellenőrzéssel rendelkezik a Pipeline-ban. Minimálisra csökkentjük a rossz minőségű szerelvények számát, növeljük a rendszer egészének megbízhatóságát, és ha a rendszerünk továbbra is meghibásodik, mechanizmusokat indítunk a helyreállítására.
Mindenképpen érdemes a szoftverminőség-ellenőrzés automatizálásába fektetni, ez nem mindig gyors folyamat, de idővel meghozza a gyümölcsét. Azt javaslom, hogy az éles környezetben bekövetkezett új incidens megoldása után azonnal gondolja át, hogy mely monitorokat vegye fel a tesztkörnyezet ellenőrzéséhez, hogy elkerülje a rossz build élesbe kerülését, és készítsen egy szkriptet is, amely automatikusan kijavítja ezeket a problémákat.
Remélem, hogy a példáim segíteni fognak a törekvéseiben. Érdeklődni fogok az öngyógyító rendszerek megvalósításához használt mérőszámokra vonatkozó példáira is.
Forrás: will.com