info@ipesoft.com
+421 907 703 854
Obchodná 9076/3D
010 08 Žilina
Slovensko
SK
10.9.2024
Robiť profylaktiku? Áno či nie?
"Robiť profylaktiku? A načo, veď systém funguje. Keď prestane, tak to budeme riešiť. Profylaktika je mrhanie časom."
Aj takýto názor môže mať Váš zákazník po nasadení a odovzdaní SCADA či MES systému do prevádzky a pri následnom jednaní o servisnej zmluve. Skúsme rozobrať jeho námietky a ukázať na príkladoch, ako sa dá profylaktika automatizovať a vykonávať čo najefektívnejšie.
„A načo, veď systém funguje“. Použijúc tento argument, majitelia áut by mohli ignorovať servisné prehliadky, výmenu oleja, kontrolu opotrebovania brzdových platničiek a podobne. Načo, veď auto funguje.. Určite by ušetrili, teda aspoň krátkodobo .. do prvej poruchy, ktorá by podľa Murphyho zákonov prišla v ten najnevhodnejší čas.
Aplikovanie analógie do sveta SCADA / MES systémov? Zbytočné zlyhania v dôsledku zaplnených diskov či databáz, strata dát kvôli zlyhaniu komunikácií, ktoré neboli monitorované, alebo úplný výpadok aplikácie.
Význam profylaktiky je ešte vyšší v redundantných systémoch. Tam sa výpadok jedného komponentu (aplikačného servera, archívneho servera, sieťového switcha, napájacieho zdroja či disku v RAID poli) na funkčnosti systému neprejaví – ale tým dôležitejšia je jeho detekcia a následné riešenie problémov. V opačnom prípade sa môže zákazník o pár dní alebo týždňov pri zlyhaní toho druhého komponentu, ktorý doteraz fungoval, ísť sťažovať akurát tak pánovi Murphymu. Takže – načo investoval do redundantného riešenia (čítaj: drahšieho ako štandardné), pokiaľ sa oň nestará a nie je si istý, že sa naň môže vždy spoľahnúť?
„Keď prestane, tak to budeme riešiť“. Pokiaľ problém začneme riešiť až keď sa vyskytne (reaktívna údržba), tak je to spravidla drahšie. Príslovie hovorí, že gram prevencie je lepší ako kilogram liekov. Hrozí strata dát, nedostupnosť služby, nespokojnosť užívateľov prípadne zákazníkov. Je tu otázka dostupnosti dodávateľa pri riešení incidentu (aké sú jeho SLA, bude k dispozícii v nedeľu alebo o tretej v noci – a ako rýchlo chybu odstráni?). Prípadne, pri riešení vlastnými silami, ako rýchlo, kvalitne (a ochotne) budú naši technici schopní problém odstrániť? Pán Murphy by povedal, že k incidentom s obľubou dochádza počas dovoleniek technického personálu a počas plánovaných školení mimo firmy ...
„Profylaktika je mrhanie časom...“
Hm. Môže byť. Ako každá aktivita, ak sa robí zle alebo neefektívne. Pokiaľ sa profylaktika týka SCADA a MES systémov, tak si treba uvedomiť, že sú to systémy na automatizovaný zber dát (Supervisory Control And Data Acquisiton). No a aké iné systémy by mali mať v sebe zabudovanú automatizáciu profylaktických činností, ak nie tieto?
Takže jednoduchý recept na profylaktiku: venujte jednorazové úsilie automatizácii najčastejších profylaktických činností (zber diagnostických údajov o stave systému, automatizovaná ‘udržba’) a následne nechajte technikov, aby riešili problémy, ktoré diagnostika reportuje.
Príliš obecné a nekonkrétne? V poriadku, poďme skúsiť rozmeniť bankovku teórie na drobné mince praxe zo spoločnosti Ipesoft. Fakty:
- trieda systémov: SCADA / MES / EMS / SELT / SKEI / SKVI ..
- použitá bázová technológia: D2000
- automatizovaný profylaktický modul: od r. 2010
- počet systémov s nasadením: cca 90
- nasadenie profylaktického modulu: niekoľko hodín až desiatok hodín podľa veľkosti systému
Profylaktický modul zabezpečuje monitorovanie:
- serverov a zariadení: sieťová dostupnosť, uptime
- operačných systémov Windows, Centos/RedHat, HP-UX, OpenVMS: obsadenie pamäte, počet handlov a threadov, využitie swapu, obsadenie diskov
- procesov D2000: doba behu, alokovaná pamäť, počet handlov, stav redundantných procesov
- komunikácií: funkčnosť komunikácie, počty nových hodnôt z komunikácie
- archívov: voľné miesto, počty spracovaných požiadaviek za sekundu a požiadaviek vo frontách
- databáz: voľné miesto, počty paralelných spojení na databázu
- stavu HW serverov: zisťovanie stavu HP serverov (pomocou WBEM/CIM/SNMP) v operačných systémoch Windows, Centos/RedHat, VmWare, HP-UX a OpenVMS
- stavu diskových polí (MSA2000 G2, P2000 G3, P4300 G2)
- záloh – sledovanie veku a veľkosti záloh + aktívne zálohovanie (konfiguračná a monitorovacia databáza, archívne a aplikačné databázy – platformy SQL Anywhere, Oracle, PostgreSQL, MariaDB, aplikačné adresáre, registry databáza a iné)
- aplikačne závislých parametrov špecifických pre konkrétnu aplikáciu. Tu môže byť prakticky čokoľvek, čo je považované za dôležité. Sledovanie stavu Oracle clustra, ‘zamrznutých’ hodnôt z komunikácie, stavu aplikačných skriptov, prijímania emailov alebo priemerného zaťaženia výpočtového servera..
Ako to funguje?
- profylaktický subsystém zberá dáta
- archívny subsystém ich uchováva (štandardne 1 rok s optimálne nastavenými zmenovými filtrami)
- logika vyhodnocuje alarmové stavy (napr. 85% zaplnenosť diskov)
- lokálni správcovia majú prístup k profylaktickým schémam
- systémy so zazmluvnenou profylaktickou kontrolou posielajú pravidelne profylaktické dáta na profylaktický server v Ipesofte, kde sú vyhodnocované vyhradenou aplikáciou
- technici sa následne venujú analýze a riešeniu reportovaných alarmových stavov zobrazených na prehľadovej schéme
Príklady obrazoviek profylaktických schém dostupných pre lokálnych správcov zákazníka:
Reálne prínosy automatizovanej profylaktiky? Pre zákazníkov aj pre nás:
- výrazné zredukovanie počtu servisných incidentov riešených technikmi držiacimi pohotovosť 24/7 (a zníženie stresu, čo ovplyvňuje spokojnosť technikov :)
- vyššia spokojnosť zákazníka – veľká časť problémov je riešená skôr, ako by následky začali vnímať užívatelia
- nižšie náklady na profylaktiku (efektívne riešenie problémov počas bežnej pracovnej doby namiesto drahšieho riešenia v rámci pohotovosti)
- použitie archivovaných dát na ďalšiu analýzu, prípadne plánovanie. Napr. otázky typu “Odkedy a prečo sa nám zvýšeným tempom zapĺňa archív?” alebo “Spôsobila výmena PLC nárast zaťaženia MES-u v dôsledku vyššieho množstva prenesených dát?” či “Za aký čas sa úplne zaplní databáza, ak nenavýšime kapacitu diskového poľa?”
- použitie archivovaných dát pri riešení problémov. Napríklad nedávno sme dokázali, že za niekoľkominútový výpadok komunikácie nenesie zodpovednosť žiadna z komunikujúcich strán, ale problémy v sieťovej infraštruktúre – vďaka monitorovaniu dostupnosti sieťových zariadení na komunikačnej trase.
A ešte pár technických perličiek:
- v dobe začiatku vývoja (r. 2010) bol profylaktický modul navrhnutý tak, aby sa dal nasadiť v na všetky vtedy podporované verzie D2000 (od verzie 7.2.05 cez verzie 8.x). V súčasnosti je nasadený na verziách 7.2.05 až po najnovšiu 11.0.52.
- profylaktický server v Ipesofte obsahuje kópiu profylaktických schém zo zákazníckych systémov. Technici si tak vedia zobraziť detailné údaje zákazníka, vykonať základnú analýzu a často aj určiť závažnosť problému bez potreby prihlasovať sa do jeho systémov.
- po úpravách profylaktických schém u zákazníka (napr. z dôvodu rozširovania aplikácie) stačí vykonať XML export menených schém a ich import na profylaktickom serveri.
- prenos profylaktických dát prebieha pomocou e-mailov bez potreby priameho prepojenia sietí zákazníka a Ipesoftu. Dáta sú pred odoslaním zozipované a zaheslované s použitím kryptovacieho algoritmu AES-256.
- profylaktické dáta sa odosielajú minimálne raz za hodinu, ale pokiaľ je nejaká udalosť vyhodnotená ako alarm (napr. zaplnenie databázy nad definovanú medzu), je aktivované odoslanie do minúty. Toto oneskorenie je z dôvodu naakumulovania následných alarmov, pokiaľ by vznikli – napr. po alarme sieťovej nedostupnosti môže nasledovať alarm stavu komunikácie. Profylaktický server alarmuje obsluhe aj informáciu, že posledné dáta boli prijaté od zákazníka viac ako pred hodinou.
Čo dodať na záver? Takmer sedem rokov skúseností s automatizovanou profylaktikou nás presviedča, že efektívna profylaktická kontrola nie je mrhanie časom, ale udržuje systém funkčný, dostupný a v dobrej kondícii. Prispieva k spokojnosti užívateľov aj dodávateľa. Poskytuje zároveň dáta pre analýzu problémov, meranie parametrov systému a plánovanie prostriedkov potrebných v budúcnosti (napr. diskové miesto). Plánujeme ju naďalej vylepšovať, rozširovať, podporovať nový hardvér a nové verzie operačných systémov.
7.6.2017, Ing. Peter Humaj
Iné blogy