🥇Az outsourcing fejlesztésbe (1. rész)

Helló mindenkinek, az én nevem Szergej Emeljancsik. Az Audit-Telecom cég vezetője, a Veliam rendszer fő fejlesztője és szerzője vagyok. Úgy döntöttem, hogy írok egy cikket arról, hogyan hoztunk létre egy kiszervezett céget egy barátommal, írtunk magunknak szoftvert, amelyet később elkezdtünk terjeszteni a SaaS rendszerén keresztül. Arról, hogy mennyire nem hittem abban, hogy ez lehetséges. A cikk nemcsak egy történetet, hanem technikai részleteket is tartalmaz a Veliam termék létrehozásának folyamatáról, beleértve néhány részletet a forráskódból. Beszélek arról is, hogy milyen hibákat követtünk el, és hogyan javítottuk ki őket. Volt némi kétségem, hogy érdemes-e ilyen cikket publikálni. De arra gondoltam, hogy jobb megtenni, visszajelzést kapni és fejlődni, mint nem publikálni a cikket és azon gondolkodni, hogy mi lett volna, ha...

Háttér

Egy IT alkalmazottként dolgoztam egy cégnél. A cég meglehetősen nagy volt, kiterjedt hálózati struktúrával. Nem szeretném részletezni a pozícióm felelősségeit, csak annyit mondok, hogy azok között nem szerepelt semmiféle fejlesztés.

Volt monitoringunk, de tisztán akadémiai érdekből szerettem volna kipróbálni, hogy hogyan tudnék írni egy egyszerűt. Az ötlet az volt, hogy webes megoldás legyen, amivel könnyen, bármilyen kliens telepítése nélkül be lehet lépni, és megnézni, mi történik a hálózattal bármilyen eszközről, beleértve a mobil eszközöket is Wi-Fi-n keresztül. Nagyon szerettem volna gyorsan felismerni, hogy melyik helyiségben található a meghibásodott berendezés, mivel nagyon szigorú válaszadási idő követelményeink voltak. Végül a fejemben megszületett egy terv, hogy írjak egy egyszerű weboldalt, aminek háttérképe egy jpeg a hálózati sémával, kivágom a képen lévő eszközöket az IP címeikkel, és a kép fölé a megfelelő koordinátákban dinamikus tartalmat jelenítek meg, zöld vagy villogó piros IP címmel. A feladat adott, nekikezdünk.

Korábban Delphi, PHP, JS programozással foglalkoztam, és nagyon felületesen C++-val. Jól ismerem a hálózatok működését: VLAN, routing (OSPF, EIGRP, BGP), NAT. Ez elegendő volt ahhoz, hogy önállóan elkészítsek egy primitív monitoring prototípust.

Megírtam az elképzelésemet PHP-ban. Az Apache szerver és a PHP Windows alatt futott, mert a Linux számomra akkoriban valami teljesen érthetetlen és nagyon bonyolult dolog volt. Később kiderült, hogy sok szempontból a Linux sokkal egyszerűbb, mint a Windows, de ez egy másik téma, és tudjuk, hogy mennyi vitát generál ez a téma. A Windows feladatütemező egy rövid időközönként (nem emlékszem pontosan, de valami olyasmi, mint három másodpercenként) meghívta a PHP szkriptet, amely minden objektumot pingelt, és az állapotukat egy fájlba mentette.

system(“ping -n 3 -w 100 {$ip_address}“);

Igen, az adatbázissal való munka akkoriban szintén nem volt még ismerős számomra. Nem tudtam, hogy a folyamatokat párhuzamosíthatom, és a hálózaton lévő összes csomópont végigjárása hosszú időt vett igénybe, mivel ez egy szálon történt. Különösen problémák merültek fel, amikor több csomópont nem volt elérhető, mivel mindegyik 300 ms késleltetést okozott a szkript számára. Az ügyfélen egy egyszerű, ciklikus funkció volt, amely néhány másodpercenként frissített információt töltött le a szerverről Ajax kéréssel, és frissítette a felhasználói felületet. Ha pedig három egymást követő pingelés után nem volt sikeres válasz, a monitorozó weboldalon vidám dallam játszott.

Amikor minden sikerült, nagyon inspirált a végeredmény, és úgy gondoltam, hogy még többet is hozzátehetek (a tudásomnak és lehetőségeimnek megfelelően). De sosem tetszettek az olyan rendszerek, amelyek tele voltak milliónyi grafikkal, amit akkor és ma is feleslegesnek tartok a legtöbb esetben. Csak azt akartam hozzáadni, ami tényleg segít a munkámban. Ez az alapelv a Veliam fejlesztésénél mind a mai napig érvényes. Ezt követően rájöttem, hogy nagyon jó lenne, ha nem kellene folyamatosan nyomon követni a monitorozást, és tudni a problémákról, hanem amikor azok bekövetkeznek, akkor nyissam meg az oldalt, és nézzem meg, hol található a problémás hálózati elem, és mit kellene vele tenni. Az elektronikus levelet akkoriban valahogy nem olvastam, egyszerűen nem használtam. Rátaláltam az interneten, hogy léteznek SMS átjárók, amelyekre GET vagy POST kérést küldhetek, és ők elküldenek nekem egy SMS-t a mobiltelefonra az általam megírt szöveggel. Azonnal tudtam, hogy ezt nagyon szeretném. Elkezdtem tanulmányozni a dokumentációt. Néhány idő elteltével sikerült megvalósítanom, és most már SMS-t kaptam a hálózati problémákról mobilra a “letört elem” nevével. Bár a rendszer primitív volt, de én magam írtam, és ami a legfontosabb, ami akkor motivált a fejlesztésére, az az volt, hogy ez egy alkalmazás, amely valóban segít a munkámban.

És elérkezett a nap, amikor a munkahelyemen leállt az egyik internetkapcsolat, és a monitorozásom nem jelezte ezt nekem. Mivel a Google DNS-ei továbbra is jól pingelhetőek voltak. Ideje volt gondolkodni, hogyan lehetne monitorozni, hogy a kapcsolat él. Különböző ötleteim voltak, hogyan lehet ezt megvalósítani. Nem volt hozzáférésem minden berendezéshez. Ki kellett találni, hogyan tudom meghatározni, hogy melyik kapcsolat él, de nem volt lehetőségem ránézni a hálózati berendezésekre. Ekkor egy kollégám felajánlotta az ötletet, hogy talán az útvonal követése a nyilvános szerverekhez eltérhet attól függően, hogy melyik internetkapcsolaton keresztül történik a kimenet. Megnéztem, és valóban így volt. Különböző útvonalak voltak az útvonal követésénél.

system(“tracert -d -w 500 8.8.8.8”);

Így született egy újabb script, pontosabban a nyomkövetés miértje a script végére került, ami pingelt minden eszközt a hálózaton. Ez egy újabb hosszú folyamat volt, amely ugyanabban a szálban futott, és lelassította az egész script működését. Akkoriban ez nem volt nyilvánvaló. De így vagy úgy, végezte a dolgát, a kódban szigorúan meg volt határozva, hogy milyen nyomkövetésnek kellett lennie minden csatornán. Így működött a rendszer, amely már monitorozta (hangsúlyos kifejezés, mivel nem voltak gyűjtött metrikák, csak ping) a hálózati eszközöket (routerek, switch-ek, wi-fi stb.) és a kapcsolatokat a külvilággal. Rendszeresen érkeztek az SMS-ek, és a diagramon mindig jól látszott, hol van a probléma.

A továbbiakban a mindennapi munka során keresztkötéssel kellett foglalkoznom. És minden alkalommal belépni a Cisco switch-ekre, hogy megnézzem, melyik interfészt kellene használni, kezdett unalmassá válni. Milyen klassz lenne rákattintani a monitorozás során egy objektumra, és meglátni az interfészek listáját a leírásokkal. Ez időt spórolna nekem. Ráadásul ebben a rendszerben nem kellett volna elindítani a Putty-t vagy a SecureCRT-t, beírni a hitelesítő adatokat és parancsokat. Csak rákattintottam a monitorozásban, láttam, mi kell, és tovább mentem a dolgomra. Elkezdtem keresni, hogyan lehetne interakcióba lépni a switch-ekkel. Egyből két lehetőség ugrott be: SNMP vagy bejelentkezni a switch-be SSH-n keresztül, beírni a szükséges parancsokat és parse-olni az eredményt. Az SNMP-t elvetettem a megvalósítás bonyolultsága miatt, türelmetlenül akartam az eredményt. Az SNMP-vel hosszasan kellett volna turkálni a MIB-ben, és ezen adatok alapján képezni az interfész adatait. Van egy remek parancs a CISCO-ban.

show interface status

Ez pontosan azt mutatja, amire szükségem van a keresztlinkeléshez. Miért szenvedjek az SNMP-vel, amikor csak azt szeretném látni, amit ez a parancs kiad? Néhány idő elteltével megvalósítottam ezt a lehetőséget. Kattintottam egy objektumra a weboldalon. Esemény lépett életbe, amely által AJAX-kal a kliens a szerverhez fordult, majd az SSH-n keresztül csatlakozott a kívánt switchhez (a hitelesítési adatok a kódban voltak beágyazva, nem akartam bonyolítani, külön menüket készíteni, ahol az interfészen keresztül lehetett volna módosítani a hitelesítő adatokat, eredményre volt szükségem, és gyorsan). Beírtam a fent említett parancsot, és visszaküldtem a böngészőbe. Így egyetlen kattintással láttam az interfészek adatait. Ez rendkívül kényelmes volt, különösen amikor egyszerre több switch-en kellett megvizsgálnom az információkat.

A csatornák nyomon követése a nyomvonal alapján nem bizonyult a legjobb ötletnek, mert néha karbantartásokat végeztek a hálózaton, és a nyomvonal változhatott, így a monitorozás folyamatosan azzal fenyegetett, hogy problémák vannak a csatornával. De miután rengeteg időt töltöttem az elemzéssel, rájöttem, hogy minden csatorna működik, és a monitorozásom félrevezet. Végül megkértem kollégáimat, akik a csatorna kialakító switch-eket kezelték, hogy küldjék el nekem a syslog-ot, amikor változott a szomszédok láthatóságának állapota. Ez sokkal egyszerűbb, gyorsabb és valósághűbb volt, mint a nyomvonal. Megérkezett egy neighbor lost esemény, és azonnal értesítést küldtem a csatorna leállásáról.

Ezután, egy kattintással a objektumon még további parancsok jelentek meg, és beépítettem az SNMP-t néhány metrika gyűjtésére, de lényegében ezzel véget ért minden. A rendszer nem fejlődött tovább. Minden megvolt, amire szükségem volt, ez egy jó eszköz volt. Sok olvasó valószínűleg azt mondaná, hogy már rengeteg szoftver létezik ezeknek a feladatoknak a megoldására az interneten. De valójában, akkor nem találtam ingyenes ilyen termékeket, és nagyon szerettem volna fejleszteni a programozási készségeimet, és mi lehetne jobban ösztönözni erre, mint egy valódi alkalmazás feladat. Ezzel befejeződött az első verzió monitorozás, és ez többé nem módosult.

Az Aaudit-Telekom cég létrehozása

Ahogy telt az idő, párhuzamosan elkezdtem más cégeknél dolgozni, mivel a munkaidőm lehetővé tette ezt. Ha különböző cégeknél dolgozik az ember, nagyon gyorsan fejlődik a képessége különböző területeken, és jól bővül a látókör. Vannak olyan cégek, ahol, ahogy mondani szokták, te vagy a szabó, a vágó és a zenész is. Egyrészt ez nehéz, másrészt ha nem lustálkodik az ember, széleskörű szakemberré válik, és ez lehetővé teszi a feladatok gyorsabb és hatékonyabb megoldását, mert tudja, hogyan működik a szomszédos terület.

A barátom, Pavel (ő is informatikus) folyamatosan próbált engem rávenni az ő üzletére. Számtalan ötlet volt különböző vállalkozásokkal. Ezt több mint egy évig tárgyaltuk. Végül nem kellett volna semmivé válnia, mert én szkeptikus vagyok, Pavel pedig álmodozó. Minden alkalommal, amikor valamilyen ötletet javasolt, sosem hittem benne, és visszautasítottam a részvételt. De nagyon vágytunk arra, hogy saját vállalkozást indítsunk.

Végül sikerült megtalálnunk egy mindkettőnk számára megfelelő megoldást, és foglalkozni azzal, amit tudunk. 2016-ban úgy döntöttünk, hogy létrehozunk egy informatikai céget, amely segít a vállalkozásoknak az IT feladatok megoldásában. Ez magába foglalja az IT rendszerek telepítését (1C, terminálszerver, levelezőszerver stb.), azok karbantartását, a klasszikus ügyfélszolgálati rendszert a felhasználók számára és a hálózat adminisztrálását.

Őszintén szólva, amikor a céget alapítottuk, körülbelül 99,9%-ig nem hittem benne. De valahogy Pavel rá tudott venni, hogy kipróbáljam, és előreugorva, igaza lett. Pavel és én összedobtunk 300 000 rubelt, bejegyeztük az új „Audit-Telekom” Kft.-t, béreltünk egy pici irodát, készítettünk menő névjegykártyákat, szóval, mint valószínűleg a legtöbb tapasztalatlan, kezdő vállalkozó, elkezdtük keresni az ügyfeleket. Az ügyfélek keresése — ez egy teljesen külön történet. Lehet, hogy írunk majd egy külön cikket a vállalati blog keretein belül, ha valakit érdekel. Hideg hívások, szórólapok és egyebek. Ennek semmilyen eredménye nem volt. Ahogy most olvasom sok üzleti történetet, úgy tűnik, hogy sok minden a szerencsén múlik. Szerencsénk volt. Alig pár héttel a cég alapítása után, a testvérem, Viktor keresett meg minket, aki az első ügyfelünket hozta. Nem akarom unalmas részletekkel fárasztani, a cikk nem erről szól, annyit elmondok, hogy auditáltunk, felfedtük a kritikus helyeket, és ezek az irányok megszűntek, miközben arra a döntésre vártunk, hogy folyamatosan együttműködünk-e velünk mint külső szolgáltatók. Ezt követően azonnal pozitív döntés született.

Később, főként ismerősök által, más cégek is elkezdtek megjelenni a szolgáltatásaink között. A Helpdesk egy rendszeren belül volt. Az internetes eszközökhöz és szerverekhez való csatlakozások másikban, pontosabban attól függően, ki hogyan. Valaki parancsikonokat mentett, mások RDP címjegyzékeket használtak. A monitorozás pedig egy újabb külön rendszer volt. A csapatnak nagyon kényelmetlen szórványos rendszerekben dolgozni. Fontos információk vesznek el a szem elől. Például, ha a kliens terminálszervere elérhetetlenné válik, azonnal beérkeznek a kérelmek a kliens felhasználóitól. A támogatói szakember létrehozza a kérelmet (telefonon érkezett). Ha az eseményeket és kérelmeket egy rendszerben regisztrálták volna, a támogatói szakember azonnal látta volna, mi a probléma a felhasználónál, és elmondta volna neki, miközben párhuzamosan a szükséges objektumhoz csatlakozott volna a helyzet kezelésére. Mindenki tudja a taktikai helyzetet, és összehangoltan dolgoznak. Nem találtunk olyan rendszert, ahol mindez össze lenne vonva. Nyilvánvalóvá vált, hogy ideje saját terméket fejlesztenünk.

A saját monitorozó rendszerünk építésének folytatása

Nyilvánvaló volt, hogy az a rendszer, amelyet korábban írtak, teljesen alkalmatlan a jelenlegi feladatokra. Sem funkcionálisan, sem minőségben nem felelt meg. Ezért úgy döntöttünk, hogy az elejétől kezdve írjuk meg a rendszert. Grafikai szempontból egészen másképp kellett volna kinéznie. Egy hierarchikus rendszernek kellett lennie, hogy gyorsan és egyszerűen meg lehessen nyitni a szükséges objektumokat a megfelelő ügyfélnél. Az első verzióban használt séma ebben az esetben teljesen indokolt volt, mivel az ügyfelek különbözőek voltak, és egyáltalán nem számított, hogy mely helyiségekben állnak az eszközök. Mindez már át lett rakva a dokumentációra.

Tehát a feladatok:

Hierarchikus struktúra;
Valamilyen szerveroldali rész, amelyet a kliensnél virtuális gépként elhelyezhetünk a szükséges metrikák gyűjtésére és központi szerverre való küldésére, amely összesíti és megjeleníti ezeket nekünk;
Értesítések. Olyan értesítések, amelyeket nem lehet figyelmen kívül hagyni, mivel abban az időben nem volt lehetőség arra, hogy valaki ülve figyelje a monitort;
Jegykezelő rendszer. Elkezdtek megjelenni olyan ügyfelek, akikkel nemcsak a szerveres és hálózati berendezéseket, hanem a munkaállomásokat is kezeltük;
Lehetőség a gyors kapcsolódásra a szerverekhez és berendezésekhez a rendszerből;

A feladatokat kijelöltük, elkezdjük a programozást. Eközben feldolgozzuk az ügyfelek kérelmeit. Abban az időben már négyen voltunk. Mindkét részét azonnal elkezdtük, és a központi szervert, valamint a klienshez telepítendő szervert írtuk. Ekkorra a Linux már nem volt ismeretlen számunkra, és úgy döntöttünk, hogy a klienseknél álló virtuális gépek Debianon fognak futni. Nem lesznek semmilyen telepítők, egyszerűen elkészítjük a szerveroldal projektjét egy konkrét virtuális gépen, majd egyszerűen klónozzuk azt a megfelelő klienshez. Ez volt egy újabb hiba. Később világossá vált, hogy ebben a séma nem volt kidolgozva az update mechanizmusa. Vagyis hozzáadtunk egy új funkciót, majd problémává vált, hogy ezt eljuttassuk az összes kliens szerverére, de erről később még beszélünk, mindent időrendben.

Elkészítettük az első prototípust. A prototípus képes volt pingelni az ügyfeleink és a szerverek szükséges hálózati eszközeit, és ezt az adatot továbbította a központi szerverünkre. A központi szerver pedig frissítette az adatokat az összesített adatok között. Itt nemcsak arról fogok írni, hogy mit sikerült elérnünk, hanem arról is, hogy milyen amatőr hibákat követtünk el, és mennyit kellett ezért időben megfizetni. Szóval, az összes objektum fájl egyetlen fájlban volt tárolva, mint egy sorozatba állított objektum. Amíg néhány ügyfelet csatlakoztattunk a rendszerhez, minden jól működött, bár néha voltak érthetetlen artefaktumok. De amikor egy tucat szervert csatlakoztattunk a rendszerhez, csodák kezdtek történni. Néha, érthetetlen okból, minden objektum eltűnt a rendszerből. Fontos megjegyezni, hogy az ügyfelek által használt szerverek néhány másodpercenként küldték az adatokat a központi szerverre POST kérések segítségével. A figyelmes olvasó és tapasztalt programozó már rájött, hogy a probléma az volt, hogy több folyamat egyszerre próbálta meg hozzáférni ugyanahhoz a fájlhoz, amelyben a sorozatba állított objektum tárolva volt. És pontosan amikor ez történt, a csodák megjelentek az objektumok eltűnésével. A fájl egyszerűen üressé vált. De ezt nem azonnal fedeztük fel, hanem csak több szerver üzemeltetése során. Ez idő alatt hozzáadtuk a portok szkennelésének funkcióját is (a szerverek nemcsak az eszközök elérhetőségét küldték a központi szervernek, hanem a nyitott portok információját is). Ezt a következő parancs kiadása révén valósítottuk meg:

$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);

a kapott eredmények gyakran helytelenek voltak, és a szkennelés nagyon lassan zajlott. Teljesen elfelejtettem a pingelést, amelyet az fping segítségével hajtottunk végre:

system("fping -r 3 -t 100 {$this->ip}");

Ez szintén nem volt párhuzamosítva, ezért a folyamat nagyon lassú volt. Később az fping már az összes szükséges IP címet egyszerre kapta meg, és visszaalakítva megkaptuk a válaszadókat. A miénktől eltérően az fping képes volt párhuzamosítani a folyamatokat.

Egy másik gyakori rutinfeladat a különféle szolgáltatások beállítása volt a WEB-en keresztül. Például az MS Exchange ECP-je. Nagyjából ez csak egy hivatkozás. És úgy döntöttünk, hogy lehetőséget kell biztosítanunk arra, hogy ilyen hivatkozásokat közvetlenül a rendszerbe adhassunk, hogy ne kelljen a dokumentációban vagy a könyvjelzőink között keresgélnünk, hogyan lépjünk be egy adott ügyfél ECP-jébe. Így született meg a rendszerhez kapcsolódó erőforrás-hivatkozások fogalma, amelyek funkcionalitása ma is elérhető és szinte változatlan maradt.

Erőforrás-hivatkozások működése Veliam-ban

Távkapcsolatok

Így néz ki a gyakorlatban a Veliam aktuális verziójában

Az egyik feladat az volt, hogy gyors és kényelmes hozzáférést biztosítsunk a szerverekhez, amelyekből már jócskán sok (több mint egy száz) és az előre mentett RDP parancsikonokat átböngészni rendkívül kényelmetlen volt. Szerszámra volt szükség. Az interneten van olyan program, ami tulajdonképpen egy címtár a RDP kapcsolatokhoz, de ezek nincsenek integrálva a megfigyelő rendszerrel, és az ügyfélszámlákat nem lehet elmenteni. Minden alkalommal beírni az ügyfélszámlát különböző kliensekhez, igazi rémálom, amikor naponta tucatnyi alkalommal csatlakozol különböző szerverekhez. SSH esetében valamivel jobb a helyzet, sok jó szoftver van, amiben lehetőség van ezeknek a kapcsolatoknak a mappákba rendezésére és a hozzájuk tartozó számlák megjegyzésére. De van két probléma. Az első — az RDP és SSH kapcsolatokhoz nem találtunk egyetlen programot sem. A második — ha valamilyen okból nem vagyok a számítógépem közelében és gyorsan csatlakoznom kell, vagy éppen újratelepítettem a rendszert, be kell merülnöm a dokumentációba, hogy megnézzem az ügyfél számláját. Ez kényelmetlen és időpazarlás.

A szükséges hierarchikus struktúra az ügyfél szerverekhez már meglévő volt a belső termékünkben. Csak annyit kellett kitalálnunk, hogyan tudjuk integrálni a gyors hozzáféréseket a szükséges berendezésekhez. Először is, legalább a saját hálózatunkon belül.

Figyelembe véve, hogy a böngésző, mint ügyfél nem rendelkezik hozzáféréssel a számítógép helyi erőforrásaihoz, ezért nem tudja egy parancs segítségével elindítani a szükséges alkalmazást, egy "Windows egyéni URL séma" megoldást találtunk ki. Így született meg egyfajta "plug-in" a rendszerünkhöz, amely csak a Putty és a Remote Desktop Plus kiegészítéseket tartalmazta, és telepítéskor egyszerűen regisztrálta az URI sémát a Windowsban. Most, amikor RDP vagy SSH kapcsolatra akartunk lépni egy objektummal, egyszerűen megnyomtuk ezt a műveletet a rendszerünkben, és a Custom URI működésbe lépett. Elindult a Windowsba beépített mstsc.exe vagy a Putty, ami a "plug-in" részeként érkezett. Azért írom a plug-in-t idézőjelben, mert ez nem hagyományos értelemben vett böngésző bővítmény.

Ez már valami volt. Egy kényelmes névjegyzék. Ráadásul a Putty esetében a belépési paraméterek közé IP-t, felhasználónevet és jelszót is adhattunk. Tehát a saját hálózatunkban lévő Linux szerverekhez már egy kattintással csatlakozhattunk, anélkül, hogy meg kellett volna adni a jelszavakat. Az RDP azonban nem volt ilyen egyszerű. A standard mstsc-nél nem lehetett a hitelesítő adatokat paraméterként megadni. Ekkor jött a képbe a Remote Desktop Plus. Ez lehetővé tette ezt. Jelenleg már nélkülözni tudjuk, de hosszú ideig hű társunk volt a rendszerünkben. A HTTP(S) weboldalakkal minden egyszerűen ment, ezek az objektumok egyszerűen megnyíltak a böngészőben, és ennyi. Kényelmes és praktikus volt. De ez csak a belső hálózaton volt valódi öröm.

Mivel a problémák többségét távolról oldottuk meg az irodából, a legegyszerűbb megoldás a VPN-ek létrehozása volt az ügyfelekhez. Így a rendszerünkből hozzá tudtunk férni hozzájuk. De ez még mindig kissé kényelmetlen volt. Minden ügyfél számára rengeteg mentett kapcsolatot kellett fenntartanunk minden számítógépen. VPN Kapcsolatokat kellett tartani, és bármilyen csatlakozás előtt bekapcsolni a megfelelő VPN-t. Ezzel a megoldással viszonylag hosszú ideig éltünk. De az ügyfelek száma növekedett, a VPN-ek száma is, és minden kezdett egyre kellemetlenebbé válni. Különösen könnybe lábadt a szemem a rendszer újratelepítése után, amikor újra be kellett írni tucatnyi VPN kapcsolatot az új Windows profilba. Elegem lett belőle, mondtam, és elkezdtem gondolkodni, mit lehetne ezzel tenni.

Tradicionálisan minden ügyfelünknek a Mikrotik által ismert eszközei voltak routerként. Ezek rendkívül funkcionálisak és kényelmesek szinte minden feladat ellátásához. Hátrányként említendő, hogy ezeket "elcsábítják". Ezt a problémát egyszerűen úgy oldottuk meg, hogy lezártuk minden külső hozzáférést. De valahogy hozzá kellett férnünk hozzájuk anélkül, hogy el kellene utaznunk az ügyfélhez, mivel ez időigényes. Egyszerűen minden Mikrotikhez létrehoztunk alagutakat, és külön csoportba soroltuk őket. Az útvonalkezelés nélkül, hogy elkerüljük a saját hálózatunk és az ügyfél hálózatai közötti összekapcsolódást.

Felmerült az ötlet, hogy amikor rákattintok a nekem szükséges objektumra a rendszerben, a központi monitorozó szerver, tudva az SSH-fiókok adatait az összes ügyfél Mikrotik-jához, csatlakozzon a szükségeshez, és létrehozzon egy porttovábbító szabályt a kívánt hoszthoz a megfelelő porttal. Itt több szempont is felmerül. Ez a megoldás nem univerzális - csak a Mikrotiknál működik, hiszen a parancsok szintaxisa minden router esetében eltérő. Ezen kívül ezeket a továbbításokat később valahogy törölni is kellett, a rendszerünk szerveroldala lényegében nem tudta nyomon követni, befejeztem-e a RDP munkamenetemet. És ez a továbbítás nyílás az ügyfél számára. Az univerzalitás után nem is vágytunk, mivel a terméket csak a cégen belül használtuk, és még csak nem is volt eszünkben publikálni.

Minden egyes probléma a saját módján lett megoldva. Amikor létrehoztuk a szabályt, a továbbítás csak egy adott külső IP-címre volt elérhető (ahonnan a kapcsolódás kezdeményezésre került). Így sikerült elkerülni a biztonsági réseket. De minden ilyen kapcsolódáskor egy új szabály került hozzáadásra a Mikrotik NAT oldalához, és nem került törlésre. Tudjuk, hogy minél több szabály van ott, annál nagyobb terhelést jelent a router processzorára. Emellett nem tudtam elfogadni azt, hogy egyszer belépek egy Mikrotikbe, és ott hirtelen száz halott, senkinek sem szükséges szabály várakozik.

Mivel a szerverünk nem tudja nyomon követni a kapcsolat állapotát, hagyjuk, hogy a mikrotik tegye ezt magától. Írtam egy scriptet, amely folyamatosan ellenőrizte az összes, bizonyos leírással rendelkező NAT szabályt, és ellenőrizte, van-e TCP kapcsolat a megfelelő szabályhoz. Ha egy ideje nem volt ilyen, akkor valószínűleg a kapcsolat már megszűnt, és ezt a NAT szabályt el lehet távolítani. Minden működött, a script jól működött.

Egyébként itt van:

global atmonrulecounter {"dontDelete"="dontDelete"}
:foreach i in=[/ip firewall nat find comment~"atmon_script_main"] do={ 
	local dstport [/ip firewall nat get value-name="dst-port" $i]
	local dstaddress [/ip firewall nat get value-name="dst-address" $i]
	local dstaddrport "$dstaddress:$dstport"
	#log warning message=$dstaddrport
	local thereIsCon [/ip firewall connection find dst-address~"$dstaddrport"]
	if ($thereIsCon = "") do={
		set ($atmonrulecounter->$dstport) ($atmonrulecounter->$dstport + 1)
		#:log warning message=($atmonrulecounter->$dstport)
		if (($atmonrulecounter->$dstport) > 5) do={
			#log warning message="NAT szabályok eltávolítása, amelyeket az atmon_script automatikusan hozzáadott"
			/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_main_$dstport"]
			/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_sub_$dstport"]
			set ($atmonrulecounter->$dstport) 0
		}
	} else {
		set ($atmonrulecounter->$dstport) 0
	}
}

Biztosan lehetett volna szebbé, gyorsabbá tenni, és így tovább, de működött, nem terhelte meg a mikrotiket, és kiválóan végezte a dolgát. Végre egy kattintással csatlakozni tudtunk a szerverekhez és az ügyfelek hálózati berendezéseihez. VPN emelése és jelszavak beírása nélkül. A rendszerrel való munkavégzés valóban nagyon kényelmes lett. Az ügyintézés ideje csökkent, és mindannyian időt töltöttünk munkával, nem pedig a szükséges objektumokhoz való csatlakozással.

Mikrotik biztonsági mentés

Beállítottuk az összes mikrotik biztonsági mentését FTP-n. Összességében minden rendben volt. De amikor a mentéshez szükség volt, meg kellett nyitni ezt az FTP-t, és ott keresni. Van egy rendszerünk, ahol minden router fel van vezetve, tudunk SSH-n kapcsolatba lépni az eszközökkel. Miért ne tehetnénk úgy, hogy a rendszer napról napra automatikusan összegyűjti a mentéseket az összes mikrotikról, gondoltam. És nekiláttam a megvalósításnak. Csatlakoztunk, készítettünk biztonsági másolatot, és elhoztuk a tárolóba.

PHP script kód a mikrotikról vonatkozó biztonsági mentés készítésére:

<?php

	$IP = '0.0.0.0';
	$LOGIN = 'admin';
	$PASSWORD = '';
	$BACKUP_NAME = 'test';

    $connection = ssh2_connect($IP, 22);

    if (!ssh2_auth_password($connection, $LOGIN, $PASSWORD)) exit;

    ssh2_exec($connection, '"/system backup save name=\"atmon\" password=\"atmon\""');
    stream_get_contents($connection);
    ssh2_exec($connection, '"/export file=\"atmon.rsc\""');
    stream_get_contents($connection);
    sleep(40); 

    $sftp = ssh2_sftp($connection);

    
    $size = filesize("ssh2.sftp://$sftp/atmon.backup");
    $stream = fopen("ssh2.sftp://$sftp/atmon.backup", 'r');
    $contents = '';
    $read = 0;
    $len = $size;
    while ($read < $len && ($buf = fread($stream, $len - $read))) {
        $read += strlen($buf);
        $contents .= $buf;
    }
    file_put_contents ($BACKUP_NAME . ‘.backup’,$contents);
    @fclose($stream);

    sleep(3);
    
    $size = filesize("ssh2.sftp://$sftp/atmon.rsc");
    $stream = fopen("ssh2.sftp://$sftp/atmon.rsc", 'r');
    $contents = '';
    $read = 0;
    $len = $size;
    while ($read < $len && ($buf = fread($stream, $len - $read))) {
        $read += strlen($buf);
        $contents .= $buf;
    }
    file_put_contents ($BACKUP_NAME . ‘.rsc’,$contents);
    @fclose($stream);

    ssh2_exec($connection, '"/file remove atmon.backup"');
    ssh2_exec($connection, '"/file remove atmon.rsc"');

?>

A biztonsági mentés két formában készült - bináris és szöveges konfiguráció. A bináris fájl gyors helyreállítást segít, míg a szöveges fájl lehetővé teszi az eljárások megértését, ha az eszközöket kényszerből cserélni kell, és a bináris fájl nem tölthető fel. Ezáltal még egy praktikus funkció jelent meg a rendszerben. Ráadásul, amikor új MikroTik eszközöket adhattunk hozzá, nem kellett semmit konfigurálni, csak annyit kellett tennünk, hogy hozzáadtuk az objektumot a rendszerhez, és beállítottuk neki az SSH fiókot. Aztán a rendszer automatikusan kezelte a biztonsági mentések készítését. A jelenlegi SaaS Veliam verzióban még nincs meg ez a funkció, de hamarosan átportáljuk.

Képek arról, hogy ez hogyan nézett ki a belső rendszerben

Átállás a normál adatbázis tárolásra

Már említettem, hogy artefaktumok jelentek meg. Néha az egész objektumlista eltűnt a rendszerből, máskor az objektum szerkesztésekor az információ nem mentődött el, és háromszor kellett átnevezni az objektumot. Ez nagyon idegesítette mindenkit. Az objektumok eltűnése ritkán történt, és könnyen helyreállítható volt a fájl visszaállításával, de az objektumok szerkesztési hibái gyakran előfordultak. Valószínűleg kezdetben nem az adatbázison keresztül csináltam, mert nem tudtam elképzelni, hogyan lehet a fákat minden kapcsolattal egy lapos táblázatban tartani. Az lapos, a fa pedig hierarchikus. De a többszörös hozzáférés jó megoldás a későbbi (a rendszer bonyolításakor) tranzakciós ügyintézéshez — ez az adatbázis-kezelő rendszer. Biztosan nem vagyok az első, aki ezzel a problémával szembesült. Elkezdtem guglizni. Kiderült, hogy már mindent kitaláltak előttem, és van néhány algoritmus, ami fát épít egy lapos táblázatból. Mindegyiket megnézve, megvalósítottam az egyiket. De ez már egy újabb verziója volt a rendszernek, mivel valójában sok mindent újra kellett írni miatta. Az eredmény logikus volt, a rendszer véletlenszerű működésének problémái eltűntek. Valaki azt mondhatja, hogy a hibák eléggé kezdetlegesek (egyszálú skriptek, a párhuzamos hozzáférés tárolásának információi különböző szálakból fájlban, stb.) a szoftverfejlesztés terén. Talán igaz is, de az én fő feladatom az adminisztrálás volt, és a programozás csak hobbiként szerepelt, és nem volt tapasztalatom a programozók csapatában, ahol az ilyen alapvető dolgokat azonnal elmondhatták volna a tapasztaltabb kollégák. Ezért minden ilyen pofont magam kaptam, de nagyon jól elsajátítottam az anyagot. Ráadásul a saját munkám magában foglalta az ügyfelekkel való találkozásokat, a cég népszerűsítésére irányuló lépéseket, és számos adminisztratív kérdést a cégen belül, és még sok minden mást. De így vagy úgy, ami már volt — az keresett volt. A srácok és én magam is használtuk a terméket a mindennapi munkánk során. Voltak kifejezetten sikertelen ötletek, és olyan megoldások, amelyekre időt pazaroltunk, és végül kiderült, hogy ez egy működésképtelen eszköz, amit senki nem használt, és ez nem került be a Veliam-ba.

Ügyfélszolgálat — HelpDesk

Hasznos megemlíteni, hogyan alakult a HelpDesk. Ez egy külön történet, mivel a Veliam esetében már a harmadik, teljesen új verzióról van szó, amely minden korábbi verziótól eltér. Jelenleg egy egyszerű rendszer, intuitív és felesleges díszítések nélkül, lehetőséggel a domain-integrációra, valamint arra, hogy ugyanazt a felhasználói profilt bármely helyről, egy e-mailből származó linken keresztül elérjük. És ami a legfontosabb, lehetőség van arra, hogy bármilyen helyről (otthon vagy az irodában) közvetlenül a bejelentővel VNC-n keresztül csatlakozzunk a kérelemből, VPN vagy portforwarding nélkül. Elmondom, hogyan jutottunk idáig, mi volt előtte, és milyen szörnyű megoldások voltak korábban.

A felhasználókat a jól ismert TeamViewer segítségével csatlakoztattuk. Minden olyan számítógépen, amelyeket támogatunk, telepítve volt a TV. Az első hiba, amit elkövettünk, és később eltávolítottunk — minden ügyfél HWID-jének hardverhez való hozzárendelése. Hogyan lépett be a felhasználó a HWID rendszerébe, hogy kérdést tegyen fel? Minden számítógépre, a TV mellett, telepítve volt egy speciális, Lazarus-ban írt segédprogram (sokan csodálkozni fognak, és talán még gugliznak is, hogy mi az, de a fordítható nyelvek közül a Delphi a legjobban ismertem, és a Lazarus majdnem ugyanaz, csak ingyenes). Egy szóval, a felhasználó elindított egy speciális batch fájlt, amely futtatta ezt a segédprogramot, az pedig kiolvasta a rendszer HWID-ját, és ezt követően elindult a böngésző, és megtörtént a bejelentkezés. Miért volt ez szükséges? Néhány cégnél az ellátott felhasználók számát külön-külön számolják, és a havi szolgáltatási díj a felhasználók számán alapul. Ez világos, mondhatjátok, de miért a hardverhez való hozzárendelés? Nagyon egyszerű, egyes egyének hazamentek és otthoni laptopjukon nyújtották be a kérdést, mint „csináljatok nekem mindent széppé itt”. A HWID rendszer kiolvasása mellett a segédprogram kiolvasta a TeamViewer aktuális ID-ját a rendszerleíró adatbázisból és átadta nekünk. A TeamViewer-nek van API-ja az integrációhoz. Mi pedig elkészítettük ezt az integrációt. De volt egy kis bonyodalom. Ezen API-k segítségével nem lehet csatlakozni a felhasználó számítógépéhez, amikor ő nyíltan nem kezdeményezi ezt a munkamenetet, és csatlakozási kísérletünk után még „megerősíteni” is kell. Akkor úgy gondoltuk, hogy a felhasználó engedélye nélkül senkinek sem szabad csatlakoznia, és mivel az ember a számítógép előtt ül, ő kezdeményezi a munkamenetet, és megerősíti a távoli csatlakozási kérést. De minden nem úgy alakult, ahogy elképzeltük. A felhasználók elfelejtették kezdeményezni a munkamenetet, és telefonbeszélgetésben kellett nekik mondani. Ez időt vett igénybe, és mindkét fél számára frusztráló volt. Ráadásul nem ritka esetek, amikor valaki kérdést hagy, de csatlakozni csak akkor engedélyez, amikor éppen ebédelni megy. Mivel a probléma nem kritikus, nem akarja, hogy a munkafolyamatát megszakítsák. Ezért nem nyom neki semmilyen gombot a csatlakozás engedélyezésére. Így jött létre a további funkció a HelpDesk bejelentkezésnél - a TeamViewer ID kiolvasása. Tudtuk a folyamatos jelszót, amelyet a TeamViewer telepítésekor használtak. Pontosabban, ezt csak a rendszer tudta, mivel be volt építve a telepítőbe és a mi rendszerünkbe. Így volt egy gomb a kérdésből való csatlakozáshoz, amelyre kattintva nem kellett várni, hanem azonnal megnyílt a TeamViewer és megtörtént a csatlakozás. Végül két típusú csatlakozási lehetőség lett. Az hivatalos TeamViewer API-n keresztül és a mi saját megoldásunkon. Meglepő módon az elsőt szinte azonnal abbahagyták, bár azt jelezték, hogy csak speciális esetekben kell használni, amikor a felhasználó is engedélyezi. Mégis, a biztonság az elsődleges. De kiderült, hogy a felhasználóknak ez nem fontos. Teljesen elégedettek voltak azzal, hogy komoly nyomógomb nélkül csatlakoznak hozzájuk. Ha így van, akkor a jövőben az API-n keresztüli csatlakozás is feleslegessé vált.

Áttérés a párhuzamosságra Linuxban

Már régóta aktuális kérdésként merült fel a hálózati szkenner gyorsabb működése, hogy előre meghatározott portlistát ellenőrizzen és egyszerűen pингelje a hálózati objektumokat. Az első megoldás, ami eszembe jut, az a párhuzamosság. Mivel a pingelés legnagyobb része a csomag visszatérésére való várakozás, és a következő ping nem kezdődhet el a korábbi csomag visszaérkezése előtt, a cégeknél, ahol 20 vagy több szerver és hálózati eszköz található, ez eléggé lassan működött. A lényeg az, hogy egy csomag elveszhet, de erről azonnal nem értesíthetjük a rendszeradminisztrátort. Ő nagyon gyorsan megszokja az ilyen spameket. Ezért minden objektumot többször is pingelni kell, mielőtt a hozzáférhetetlenségről következtetnénk. Ha nem merülünk részletekbe, párhuzamosítani kell, mert ha ezt nem tesszük, a rendszeradminisztrátor valószínűleg a klienssel fog először értesülni a problémáról, és nem a monitorozó rendszertől.

A PHP alapból nem támogatja a párhuzamosságot. Többprocesszoros működést tud, lehet fork-olni. De már volt egy működő kérdező mechanizmusom, és úgy akartam, hogy egyszerre olvassam le az összes szükséges csomópontot az adatbázisból, pingeljem le őket, várjam meg a választ mindegyiktől, és csak ezután írjam be az adatokat. Ez csökkenti az olvasási kérések számát. A párhuzamosság remekül illeszkedett ebbe az elképzelésbe. A PHP-hoz van egy PThreads modul, amely lehetővé teszi a tényleges párhuzamosságot, bár elég sokat kellett bajlódnom, hogy beállítsam PHP 7.2-hez, de a munkát elvégeztük. A portok szkennelése és a pingelés gyors lett. Egy példán keresztül, korábban 15 másodpercet vett igénybe egy kör, most pedig 2 másodpercre csökkent ez a folyamat. Ez jó eredmény volt.

Gyors audit új vállalatok számára

Hogyan alakult ki a különböző metrikák és hardverjellemzők gyűjtésének funkciója? Minden egyszerű. Néha egyszerűen csak az aktuális IT infrastruktúra auditálását kérik tőlünk. Hasonlóra van szükség az új ügyfél auditjának gyorsítása érdekében is. Olyan megoldásra volt szükség, amely lehetővé teszi, hogy egy közepes vagy nagy céghez érkezve gyorsan orientálódjunk, hogy egyáltalán milyen eszközeik vannak. Szerintem a belső hálózaton a ping blokkolását csak azok alkalmazzák, akik maguknak akarják megnehezíteni az életüket, és tapasztalataink szerint ilyenekből nem sok van. De azért ezek is előfordulnak. Ezért gyorsan be lehet scan-elni a hálózatokat eszközök után egyszerű pingeléssel. Ezt követően hozzáadhatjuk őket és átvizsgálhatjuk a nyitott portok tekintetében, amelyek minket érdekelnek. Gyakorlatilag ez a funkció már létezett, csak annyit kellett hozzátenni, hogy a központi szerverről egy parancsot küldjünk az alárendelt szervernek, hogy az átvizsgálja a megadott hálózatokat és hozzáadja a listához mindent, amit talál. Elfelejtettem megemlíteni, hogy feltételeztük, hogy már van egy kész képünk egy beállított rendszerrel (monitoring alárendelt szerver), amelyet csak telepíthettünk az ügyfélnél az audit során, és csatlakoztathattuk a saját felhőnkhöz.

Az audit eredménye általában sokféle információt tartalmaz, és az egyik ezek közül az, hogy milyen eszközök találhatók a hálózaton. Elsősorban a Windows szerverek és Windows munkaállomások érdekeltek minket a tartományon belül. Mivel a közepes és nagy cégeknél a tartomány hiánya valószínűleg a kivétel, nem a szabály. Hogy egy nyelvet beszéljünk, a közepes, véleményem szerint, ez 100+ főt jelent. Ki kellett találni egy módot arra, hogyan szedjük össze az adatokat az összes Windows gépről és szerverről, ismerve IP-címüket és a tartományi adminisztrátor fiókját, de úgy, hogy ne kelljen semmiféle szoftvert telepíteni rájuk. Itt jön segítségül a WMI felület. A Windows Management Instrumentation (WMI) szó szerint fordítva a Windows kezelőeszközöket jelenti. A WMI az egyik alapvető technológia a Windows platform alatt működő számítógépes infrastruktúra különböző részeinek központosított kezelésére és monitorozására. A Wikipédiából van. Ezután ismét sokat kellett dolgozni, hogy elkészítsem a wmic-et (ez a WMI kliens) Debianra. Miután minden készen állt, már csak annyit kellett tennem, hogy a wmic segítségével megkérdezem a szükséges csomópontokat a megkívánt információkért. A WMI-n keresztül szinte bármilyen információt ki lehet nyerni egy Windows számítógépről, és ami még jobb, hogy a számítógépet is lehet kezelni, például újraindítást is lehet kérni. Így alakult ki az információgyűjtés a Windows állomásokról és szerverekről a rendszerünkben. Ehhez pluszban jött a rendszer aktuális terhelési mutatóinak információja. Ezeket gyakrabban kérdezzük le, míg a hardverekről ritkábban. Ezt követően az auditálás egy kicsit kellemesebbé vált.

Szoftver elosztási döntés

Mindennap használjuk a rendszert, és mindig nyitva van minden műszaki munkatárs számára. Gondoltunk arra, hogy megoszthatjuk másokkal is, ami már létezik. A rendszer még nem volt eléggé készen arra, hogy elosszuk. Nagyon sok mindent át kellett alakítani ahhoz, hogy a helyi verzió SaaS-sá váljon. Ez magában foglalja a rendszer működésének különböző műszaki aspektusainak módosításait (távoli kapcsolatok, ügyfélszolgálat), valamint a modulok licencelésének elemzését, az ügyfelek adatbázisainak shardelését, minden szolgáltatás skálázását, és az összes rész automatikus frissítési rendszerének kidolgozását. De erről második rész következik.