Bankunkban a dokumentációt támogató rendszer folyamatosan fejlődik, skálázódik, a sebességre és a hibatűrésre vonatkozó követelmények pedig csak nőnek. Valamikor túl kockázatossá vált az LMS fenntartása hatékony központosított felügyelet nélkül. A VTB üzleti folyamatainak biztonságosabbá tétele és az adminisztrátorok munkájának leegyszerűsítése érdekében nyílt technológiákon alapuló megoldást vezettünk be. Segítségével proaktívan tudunk reagálni az eseményekre, megelőzve az esetleges problémákat. A vágás alatt egy történet a nagyméretű üzleti rendszerek felügyeletére szolgáló ingyenes szoftverek használatával kapcsolatos tapasztalatainkról.
Miért figyelje a dokumentumkezelő rendszerét?
2005 óta a VTB Bank dokumentációs támogatását a CompanyMedia rendszer „kezeli”. Az LMS több mint 60 ezer felhasználót foglalkoztat, akik havonta több mint egymillió új dokumentumot hoznak létre. Szervereinknek a nap 24 órájában kell működniük: szinte minden pillanatban 2500-3000 ember van a rendszerben, akik Petropavlovszk-Kamcsatszkijtól Kalinyingrádig az ország egész területén kapcsolatban állnak egymással. Az LMS működésének minden másodperce 10-15 változtatást jelent.
Annak érdekében, hogy a rendszer pontosan teljesítse a rábízott feladatokat, hibatűrő infrastruktúrát építettünk ki proxy szerverek, kéréskiegyenlítés, információvédelem, teljes szöveges keresés, integrációs útvonalak és biztonsági mentés segítségével. Egy ilyen léptékű projekt támogatása és igazgatása hatalmas erőforrásokat igényel. Az adminisztrátorok éjjel-nappal figyelik az alapvető információkat a szerver működéséről, a RAM terheléséről, a CPU idejéről, az I/O alrendszerről stb. De ezen kívül még finomabb elemzésekre van szükség:
- az üzleti forgatókönyvek végrehajtására fordított idő kiszámítása;
- a rendszer teljesítményének és terhelésének dinamikájának figyelése;
- a rendszerelemekben a jóváhagyott nem funkcionális követelményektől való eltérések keresése.
11 évvel az LMS bevezetése után különösen élessé vált a különféle típusú hibákra való proaktív reagálás kérdése. A bank vezetése belátta, hogy a monitorok és a rendszerélet-konzol nélküli munka a tűzzel játszik: egy ilyen szintű üzleti rendszerben a legkisebb meghibásodás milliós veszteséget okozhat.
2016-ban megkezdtük az LMS működésével kapcsolatos problémák gyors azonosítására szolgáló eszközök bevezetését, beleértve a számunkra érdekes paraméterek valós idejű monitorozását. Korábban az alkalmazott monitoring rendszert az InterTrust vállalati infrastruktúra keretein belül telepítették és tesztelték.
Hogy kezdődött mindez
A VTB LMS nyílt forráskódú szoftvertermékekre épülő központosított alkalmazásfigyelő rendszere ma már segít megelőzni a legtöbb dokumentumáramlással kapcsolatos hibát, gyorsan és pontosan osztályozza a problémákat, és azonnal reagál az esetleges incidensekre. Két alrendszert tartalmaz:
- a rendszerszolgáltatások informatikai infrastruktúrájának figyelésére;
- az LMS működésében fellépő hibák figyelésére.
Az egész egyetlen ingyenes megfigyelőalkalmazással kezdődött. Több lehetőség átfutása után a Zabbix mellett döntöttünk – ez az ingyenes szoftver, amelyet eredetileg banki szolgáltatásokhoz és berendezésekhez írtak. Ez a PHP web alapú rendszer, amely MySQL, PostgreSQL, SQLite vagy Oracle Database-ben képes adatokat tárolni, tökéletesen megfelelt az igényeinknek.
A Zabbix minden kiszolgálón futtatja ügynökeit, és valós időben egyetlen adatbázisba gyűjti össze az érdekes metrikákra vonatkozó információkat. Az alkalmazás segítségével kényelmesen gyűjthet adatokat a processzorok és a RAM terheléséről, a hálózat és egyéb komponensek használatáról, ellenőrizheti a szabványos szolgáltatások (SMTP vagy HTTP) elérhetőségét és válaszát, külső programokat futtathat, és a monitoron keresztül támogatja a monitorozást. SNMP.
A Zabbix telepítése után szabványos hardveres mérőszámokat konfiguráltunk, és először ez elég volt. A VTB SDO azonban folyamatosan fejlődik és növekszik: 2016-ban észrevehetően nőtt a szerverek száma, megjelentek a migrációs folyamatok, a Bank of Moscow, a VTB Capital és a VTB24 csatlakozott a rendszerhez. Már nincs elég szabványos mérőszám, és megtanítottuk a Zabbix-ot, hogy nyomon kövesse a sorok jelenlétére vonatkozó információkat a kiszolgálóhoz csatlakoztatott egyes köteteken (a Zabbix a dobozból csak az általános lemezsort tükrözi), valamint az ehhez szükséges időt. egy adott eljárás befejezéséhez.
Ezenkívül több triggerrel is felszereltük a rendszert - olyan feltételekkel, amelyek esetén értesítést küld a rendszergazdának (üzenet a Telegramban, SMS egy telefonszámra vagy e-mail). A triggerek bármely paraméterkészlethez konfigurálhatók. Például megadhat egy bizonyos százalékos szabad lemezterületet, és a rendszer figyelmezteti az adminisztrátort, ha eléri a megadott küszöböt, vagy értesíti Önt, ha egy háttéreljárás a szokásosnál tovább fut.
Java kapcsolat és adatvizualizáció
Jelentősen bővítettük az elemzett adatok körét, de ez hamarosan nem volt elegendő a hatékony monitorozáshoz. Kihasználva azt a tényt, hogy a CompanyMedia LMS-je egy Java alkalmazás, a JMX interfészen keresztül csatlakoztunk a Java Virtual Machine-hez, és közvetlenül tudtuk átvenni a Java metrikákat. És nem csak a Java létfontosságú tevékenységének standard paraméterei, mint például a GC munkaintenzitás vagy a kupac fogyasztás, hanem a futtatható alkalmazáskódhoz közvetlenül kapcsolódó speciális tesztek is.
2017-ben, körülbelül egy évvel a monitoring rendszer bevezetése után világossá vált, hogy a Zabbixban gyűjtött kolosszális mennyiségű adattal való normális működéshez nem volt elegendő vizualizáció - összetett képernyők. A probléma legjobb megoldása ismét az ingyenes szoftver volt – a Grafana, egy kényelmes műszerfal a mérőszámokhoz, amely lehetővé teszi az összes adat egy képernyőn történő összesítését.
A Grafana felület interaktív, OLAP rendszerre emlékeztet. Az alrendszer egyetlen képernyőn jeleníti meg a Zabbix által fogadott adatokat, könnyen elemezhető grafikonok és diagramok formájában jeleníti meg az információkat. Az adminisztrátor könnyen testreszabhatja a számára szükséges szeleteket.
Az LMS rendszer hibáinak monitorozása és megelőző kiküszöbölése
Az ELK nyílt forráskódú szoftverplatform segít a monitorozás során kapott információk szűrésében és elemzésében. Ez a nyílt forráskódú termék három hatékony eszközből áll az adatok gyűjtésére, tárolására és elemzésére: Elasticsearch, Logstash és Kibana. Ennek az alrendszernek a megvalósítása lehetővé teszi különösen annak valós időben történő megtekintését, hogy hány hiba történt a rendszerben, mely szervereken és hogy ezek a hibák megismétlődnek-e.
A rendszergazda most már korai szakaszban észleli a problémát, még azelőtt, hogy a felhasználó találkozna vele. Az ilyen proaktív felügyelet lehetővé teszi a rendszer hibáinak megelőzését a hibák időben történő kiküszöbölésével. Ezen túlmenően megérthetjük, hogyan változott a rendszer viselkedése a frissítés után, valamint észlelhetjük az új problémákat, ha azok megjelennek.
Üzleti műveletek megfigyelése
Az erőforrás-felhasználás monitorozásának alapvető funkciói mellett a rendszer képes az üzleti műveletek elemzésére és ellenőrzésére.
Az üzleti műveletek teljes végrehajtási idejének figyelemmel kísérése lehetővé teszi az új tényezők azonosítását és a rendszer működésére gyakorolt hatásuk megértését.
Az egyes üzleti szolgáltatásokra vonatkozó kérések végrehajtási idejének figyelése lehetővé teszi a megszokottól eltérő műveletek észlelését.
A fenti képernyőkép egy példa egy háttérfeladat megfigyelésére a normától való eltérés szempontjából.
Az ellenőrzött feladatok listája egy adott szerveren végzett tevékenységük alapján lehetővé teszi a hibák azonosítását – beleértve a feladatvégrehajtás megkettőzését – az összes szerveren.
A háttéreljárások végrehajtási idejének alakulását is figyelemmel kísérik.
A rendszer növekszik, fejlődik és segít megbirkózni a problémákkal
A leírt rendszer megvalósításával az LMS szerverek működésének felügyelete jelentősen leegyszerűsödött. Ennek ellenére időről időre felmerülnek különféle konfliktusok, amelyek befolyásolják a dokumentumáramlás sebességét, és felhasználói panaszokat okoznak. Így rájöttünk, hogy magának az alkalmazásnak a viselkedését kell ellenőrizni, nem csak a szervereket.
A probléma megoldására egy kiegyenlítőt csatlakoztattak a megfigyelő rendszerhez API-n keresztül, amely alkalmazáskiszolgálók fürtjével működik. Ennek köszönhetően az adminisztrátor láthatja, hogy mennyi időbe telik, amíg a szerver válaszol az egyes felhasználói kérésekre.
Elemzhetővé váltak a szerver válaszidejére vonatkozó adatok, amelyek lehetővé tették az LMS lassulását a szerveren lezajló folyamatok összekapcsolását. Különösen érdekes helyzet alakult ki: a szerver lassan fut, bár jelenleg nincs betöltve. Az anomáliát elemezve eltéréseket fedeztünk fel a Garbage Collector Java működésében. Végül kiderült, hogy ennek a szolgáltatásnak a helytelen működése vezetett ehhez a helyzethez. A Garbage Collector Java irányításával teljesen kiküszöböltük a problémát.
A szabad szoftverek így segítik a bankszektor dokumentumkezelő rendszerének fejlődését és növekedését. Csak a VTB SDO felügyeleti rendszerrel kapcsolatos főbb kérdéseket érintettük. Ha érdekelnek a részletek, kérdezz kommentben, szívesen megosztjuk veled tapasztalatainkat.
Forrás: will.com