Ahoj všetci, volám sa Sergey Emelyanchik. Som šéfom spoločnosti Audit-Telecom, hlavným vývojárom a autorom systému Veliam. Rozhodol som sa napísať článok o tom, ako sme s kamarátom vytvorili outsourcingovú spoločnosť, napísali softvér pre seba a následne ho začali distribuovať všetkým prostredníctvom systému SaaS. O tom, ako som kategoricky neveril, že je to možné. Článok bude obsahovať nielen príbeh, ale aj technické detaily ako produkt Veliam vznikal. Vrátane niektorých častí zdrojového kódu. Neskôr vám poviem, aké chyby sme urobili a ako sme ich napravili. Objavili sa pochybnosti, či takýto článok zverejniť. Ale myslel som si, že je lepšie to urobiť, získať spätnú väzbu a zlepšiť sa, ako nezverejniť článok a zamyslieť sa nad tým, čo by sa stalo, keby...
pravek
Pracoval som v jednej firme ako IT zamestnanec. Spoločnosť bola pomerne veľká s rozsiahlou sieťovou štruktúrou. Nebudem sa rozpisovať nad mojimi pracovnými povinnosťami, poviem len, že k nim rozhodne nepatril rozvoj čohokoľvek.
Mali sme monitoring, ale čisto z akademického záujmu som chcel skúsiť napísať svoj vlastný najjednoduchší. Myšlienka bola takáto: Chcel som, aby to bolo na webe, aby som tam mohol jednoducho ísť bez inštalácie akýchkoľvek klientov a vidieť, čo sa deje so sieťou z akéhokoľvek zariadenia, vrátane mobilného zariadenia cez Wi-Fi, a tiež naozaj chcel som rýchlo pochopiť, čo V miestnosti je zariadenie, ktoré sa stalo „mopey“, pretože... existovali veľmi prísne požiadavky na čas odozvy na takéto problémy. V dôsledku toho sa v mojej hlave zrodil plán napísať jednoduchú webovú stránku, na ktorej bude pozadie vo formáte jpeg so sieťovým diagramom, vystrihnúť samotné zariadenia s ich IP adresami na tomto obrázku a zobraziť dynamický obsah na vrchu obrázok v požadovaných súradniciach vo forme zelenej alebo blikajúcej červenej IP adresy. Úloha je nastavená, začnime.
Predtým som programoval v Delphi, PHP, JS a veľmi povrchne C++. Veľmi dobre viem, ako fungujú siete. VLAN, smerovanie (OSPF, EIGRP, BGP), NAT. To mi stačilo na to, aby som sám napísal prototyp primitívneho monitorovania.
Napísal som, čo som plánoval v PHP. Server Apache a PHP bol na Windowse, pretože... Linux bol pre mňa v tej chvíli niečo nepochopiteľné a veľmi zložité, ako sa neskôr ukázalo, veľmi som sa mýlil a na mnohých miestach je Linux oveľa jednoduchší ako Windows, ale toto je samostatná téma a všetci vieme, koľko holivarov je na táto téma. Plánovač úloh systému Windows stiahol v malom intervale (nepamätám si presne, ale niečo ako raz za tri sekundy) skript PHP, ktorý pýtal všetky objekty banálnym príkazom ping a uložil stav do súboru.
system(“ping -n 3 -w 100 {$ip_address}“);
Áno, áno, práca s databázou v tej chvíli pre mňa tiež nebola zvládnutá. Nevedel som, že je možné paralelizovať procesy a prechod cez všetky sieťové uzly trvalo dlho, pretože... stalo sa to v jednom vlákne. Problémy nastali najmä vtedy, keď viacero uzlov bolo nedostupných, pretože každý z nich oneskoril skript o 300 ms. Na strane klienta bola jednoduchá funkcia looping, ktorá v intervaloch niekoľkých sekúnd sťahovala aktualizované informácie zo servera s požiadavkou Ajax a aktualizovala rozhranie. No ak teda po 3 neúspešných pingoch za sebou, ak bola v počítači otvorená webová stránka s monitorovaním, hrala veselá skladba.
Keď sa všetko podarilo, výsledok ma veľmi inšpiroval a napadlo ma, že by som k nemu mohol pridať viac (vzhľadom na moje znalosti a schopnosti). Vždy som však nemal rád systémy s miliónmi grafov, o ktorých som si vtedy a dodnes myslím, že sú vo väčšine prípadov zbytočné. Chcel som tam dať len to, čo by mi naozaj pomohlo v mojej práci. Tento princíp zostáva základom vývoja spoločnosti Veliam dodnes. Ďalej som si uvedomil, že by bolo veľmi cool, keby som nemusel mať monitorovanie otvorené a vedel o problémoch, a keď sa to stane, otvorím stránku a uvidím, kde sa nachádza tento problematický uzol siete a čo s ním ďalej robiť. . Nejako som vtedy nečítal e-maily, jednoducho som ich nepoužíval. Na internete som narazil na to, že existujú SMS brány, na ktoré môžete poslať požiadavku GET alebo POST a na mobil mi pošlú SMS s textom, ktorý napíšem. Hneď som si uvedomil, že toto naozaj chcem. A začal som študovať dokumentáciu. Po nejakom čase sa mi to podarilo a teraz mi na mobil prišla SMS o problémoch v sieti s názvom „spadnutý predmet“. Hoci bol systém primitívny, napísal som ho sám a najdôležitejšou vecou, ktorá ma motivovala k jeho vývoju, bolo, že to bol aplikačný program, ktorý mi skutočne pomohol v mojej práci.
A potom prišiel deň, keď jeden z internetových kanálov vypadol v práci a môj monitoring mi o tom nedal vedieť. Keďže Google DNS stále pingoval perfektne. Je čas premýšľať o tom, ako môžete sledovať, či je komunikačný kanál živý. Boli rôzne nápady, ako to urobiť. Nemal som prístup ku všetkým zariadeniam. Museli sme prísť na to, ako pochopiť, ktorý z kanálov je naživo, ale bez toho, aby sme ho mohli nejako zobraziť na samotnom sieťovom zariadení. Potom kolega prišiel s myšlienkou, že je možné, že sledovanie trasy na verejné servery sa môže líšiť v závislosti od toho, ktorý komunikačný kanál sa momentálne používa na prístup na internet. Skontroloval som a dopadlo to tak. Pri sledovaní boli rôzne trasy.
system(“tracert -d -w 500 8.8.8.8”);
Takže sa objavil ďalší skript, alebo skôr, z nejakého dôvodu bola stopa pridaná na koniec toho istého skriptu, ktorý testoval všetky zariadenia v sieti. Koniec koncov, ide o ďalší dlhý proces, ktorý bol vykonaný v rovnakom vlákne a spomalil prácu celého skriptu. Ale potom to nebolo také zrejmé. Ale tak či onak, svoju prácu urobil, kód prísne definoval, aký druh sledovania by mal byť pre každý z kanálov. Takto začal fungovať systém, ktorý už monitoroval (nahlas povedané, pretože neexistoval zber žiadnych metrík, ale len ping) sieťové zariadenia (smerovače, prepínače, wi-fi atď.) a komunikačné kanály s okolitým svetom. . SMS správy prichádzali pravidelne a schéma vždy jasne ukazovala, kde je problém.
Ďalej, v každodennej práci som musel robiť kríže. A už ma unavovalo zakaždým chodiť na prepínače Cisco, aby som zistil, ktoré rozhranie použiť. Aké skvelé by bolo kliknúť na objekt v monitorovaní a zobraziť zoznam jeho rozhraní s popismi. Ušetrilo by mi to čas. Navyše v tejto schéme by nebolo potrebné spúšťať Putty alebo SecureCRT na zadávanie účtov a príkazov. Len som klikol na monitoring, videl, čo bolo treba a išiel som robiť svoju prácu. Začal som hľadať spôsoby interakcie s prepínačmi. Okamžite som narazil na 2 možnosti: SNMP alebo prihlásenie sa do switchu cez SSH, zadanie potrebných príkazov a parsovanie výsledku. SNMP som zamietol z dôvodu zložitosti jeho implementácie; netrpezlivo som čakal na výsledok. pri SNMP by ste sa museli dlho hrabať v MIB a na základe týchto údajov generovať údaje o rozhraniach. V CISCO je skvelý tím
show interface statusUkazuje presne to, čo potrebujem na prechody. Načo sa trápiť s SNMP, keď chcem len vidieť výstup tohto príkazu, pomyslel som si. Po nejakom čase som si uvedomil túto príležitosť. Kliknutie na objekt na webovej stránke. Bola spustená udalosť, pri ktorej klient AJAX kontaktoval server a ten sa následne pripojil cez SSH k prepínaču, ktorý som potreboval (prihlasovacie údaje boli napevno zakódované do kódu, nebolo potrebné ho upravovať, vytvárať nejaké samostatné ponuky, kde bolo by možné zmeniť účty z rozhrania, potreboval som výsledok a rýchlo) Zadal som tam vyššie uvedený príkaz a poslal som ho späť do prehliadača. Takže som začal vidieť informácie o rozhraniach jediným kliknutím myši. Bolo to mimoriadne pohodlné, najmä keď ste tieto informácie museli zobraziť na rôznych prepínačoch naraz.
Monitorovanie kanálov na základe sledovania sa nakoniec ukázalo ako nie najlepší nápad, pretože... niekedy sa na sieti pracovalo a sledovanie sa mohlo zmeniť a monitorovanie na mňa začalo kričať, že sú problémy s kanálom. Ale keď som strávil veľa času analýzou, uvedomil som si, že všetky kanály fungujú a moje monitorovanie ma klamalo. V dôsledku toho som požiadal svojich kolegov, ktorí spravovali prepínače na vytváranie kanálov, aby mi jednoducho poslali syslog, keď sa zmení stav viditeľnosti susedov. Preto to bolo oveľa jednoduchšie, rýchlejšie a presnejšie ako sledovanie. Prišla udalosť, ako je strata suseda, a okamžite vydávam upozornenie o výpadku kanála.
Ďalej sa pri kliknutí na objekt objavilo niekoľko ďalších príkazov a bol pridaný SNMP na zhromažďovanie niektorých metrík, a to je v podstate všetko. Systém sa nikdy ďalej nevyvíjal. Robil všetko, čo som potreboval, bol to dobrý nástroj. Mnohí čitatelia mi asi povedia, že na vyriešenie týchto problémov je na internete už množstvo softvéru. Ale v skutočnosti som vtedy takéto bezplatné produkty negooglil a naozaj som chcel rozvíjať svoje programátorské zručnosti a aký lepší spôsob, ako to dosiahnuť, ako skutočný problém s aplikáciou. V tomto bode bola dokončená prvá verzia monitorovania a už nebola upravovaná.
Vznik spoločnosti Audit-Telecom
Postupom času som začal pracovať na čiastočný úväzok v iných spoločnostiach, našťastie mi to môj pracovný režim umožnil. Keď pracujete v rôznych spoločnostiach, vaše schopnosti v rôznych oblastiach veľmi rýchlo rastú a vaše obzory sa dobre rozvíjajú. Sú spoločnosti, v ktorých ste, ako sa hovorí, Švéd, kosec a trubkár. Na jednej strane je to ťažké, na druhej strane, ak nie ste leniví, stanete sa generalistom a to vám umožňuje rýchlejšie a efektívnejšie riešiť problémy, pretože viete, ako príbuzný odbor funguje.
Môj kamarát Pavel (tiež IT špecialista) sa ma neustále snažil povzbudiť, aby som si založil vlastný biznis. Bolo tam nespočetne veľa nápadov s rôznymi variáciami toho, čo robili. O tom sa diskutuje už roky. A nakoniec k ničomu nemalo dôjsť, pretože ja som skeptik a Pavel je snílek. Zakaždým, keď navrhol nápad, vždy som tomu neveril a odmietol som sa zúčastniť. Naozaj sme však chceli otvoriť vlastný podnik.
Nakoniec sa nám podarilo nájsť možnosť, ktorá nám obom vyhovovala a robiť to, čo vieme. V roku 2016 sme sa rozhodli vytvoriť IT spoločnosť, ktorá by pomáhala firmám riešiť IT problémy. Ide o nasadenie IT systémov (1C, terminálový server, mail server a pod.), ich údržbu, klasický HelpDesk pre používateľov a správu siete.
Úprimne povedané, v čase založenia spoločnosti som tomu neveril na 99,9%. Ale nejako ma Pavel dokázal prinútiť, aby som to skúsil a pri pohľade dopredu sa ukázalo, že mal pravdu. S Pavlom sme vložili každý 300 000 rubľov, zaregistrovali sme novú LLC „Audit-Telecom“, prenajali sme si malú kanceláriu, vyrobili skvelé vizitky, no, vo všeobecnosti, ako pravdepodobne väčšina neskúsených začínajúcich podnikateľov, a začali sme hľadať klientov. Hľadanie klientov je úplne iný príbeh. Možno napíšeme samostatný článok v rámci firemného blogu, ak by mal niekto záujem. Studené hovory, letáky atď. To neprinieslo žiadne výsledky. Ako teraz čítam z mnohých príbehov o podnikaní, tak či onak veľa závisí od šťastia. Mali sme šťastie. a doslova pár týždňov po vzniku firmy nás oslovil môj brat Vladimír, ktorý nám priviedol prvého klienta. Nebudem vás nudiť detailami práce s klientmi, o tom ten článok nie je, poviem len, že sme išli na audit, identifikovali sme kritické oblasti a tieto oblasti sa pokazili, kým sa rozhodovalo, či priebežne s nami ako outsourceri spolupracujú. Potom bolo okamžite prijaté kladné rozhodnutie.
Potom, najmä ústnym podaním priateľov, sa začali objavovať ďalšie spoločnosti poskytujúce služby. Helpdesk bol v jednom systéme. Pripojenia k sieťovým zariadeniam a serverom sú rôzne, alebo skôr odlišné. Niektorí ľudia ukladali skratky, iní používali adresáre RDP. Monitoring je ďalší samostatný systém. Pre tím je veľmi nepohodlné pracovať v nesúrodých systémoch. Dôležité informácie sa strácajú zo zreteľa. Napríklad terminálový server klienta sa stal nedostupným. Žiadosti od používateľov tohto klienta sú okamžite prijímané. Špecialista podpory otvorí požiadavku (bola prijatá telefonicky). Ak by boli incidenty a požiadavky zaregistrované v jednom systéme, špecialista podpory by okamžite videl, aký je problém používateľa a povedal by mu o tom, pričom by sa súčasne pripojil k požadovanému objektu, aby vyriešil situáciu. Každý si uvedomuje taktickú situáciu a pracuje harmonicky. Nenašli sme systém, kde by sa toto všetko spojilo. Bolo jasné, že je čas vyrobiť si vlastný produkt.
Pokračujte v práci na vašom monitorovacom systéme
Bolo jasné, že systém, ktorý bol napísaný skôr, je úplne nevhodný pre súčasné úlohy. Ani z hľadiska funkčnosti, ani z hľadiska kvality. A bolo rozhodnuté napísať systém od začiatku. Graficky by to malo vyzerať úplne inak. Musel to byť hierarchický systém, aby bolo možné rýchlo a pohodlne otvoriť správny objekt pre správneho klienta. Schéma ako v prvej verzii nebola v tomto prípade absolútne opodstatnená, pretože Klienti sú rôzni a vôbec nezáležalo na tom, v ktorých priestoroch sa zariadenie nachádzalo. Toto už bolo prenesené do dokumentácie.
Takže úlohy:
- Hierarchická štruktúra;
- Nejaký druh serverovej časti, ktorá môže byť umiestnená v priestoroch klienta vo forme virtuálneho stroja na zhromažďovanie potrebných metrík a ich odoslanie na centrálny server, ktorý to všetko zhrnie a ukáže nám to;
- Upozornenia. Tie, ktoré nemožno vynechať, pretože... v tom čase nebolo možné, aby niekto sedel a len hľadel na monitor;
- Systém aplikácie. Začali sa objavovať klienti, pre ktorých sme obsluhovali nielen serverové a sieťové zariadenia, ale aj pracovné stanice;
- Schopnosť rýchleho pripojenia k serverom a zariadeniam zo systému;
Úlohy sú stanovené, začíname písať. Popri tom vybavovanie požiadaviek od klientov. V tom čase sme už boli 4. Začali sme písať obe časti naraz: centrálny server a server na inštaláciu klientom. V tomto bode nám už Linux nebol cudzí a bolo rozhodnuté, že virtuálne stroje, ktoré budú mať klienti, budú na Debiane. Nebudú tu žiadni inštalátori, len vytvoríme projekt serverovej časti na jednom konkrétnom virtuálnom stroji a potom ho len naklonujeme na požadovaného klienta. Toto bola ďalšia chyba. Neskôr sa ukázalo, že v takejto schéme bol mechanizmus aktualizácie úplne nevyvinutý. Tie. pridávali sme nejakú novú funkciu a potom nastal celý problém s jej distribúciou na všetky klientske servery, ale k tomu sa vrátime neskôr, všetko v poriadku.
Vyrobili sme prvý prototyp. Bol schopný pingovať klientske sieťové zariadenia a servery, ktoré sme potrebovali, a odoslať tieto údaje na náš centrálny server. A on zase tieto údaje hromadne aktualizoval na centrálnom serveri. Tu napíšem nielen príbeh o tom, ako a čo sa podarilo, ale aj aké amatérske chyby sa urobili a ako som na to neskôr musel doplatiť časom. Takže celý strom objektov bol uložený v jednom súbore vo forme serializovaného objektu. Kým sme do systému pripojili viacerých klientov, všetko bolo viac-menej normálne, aj keď občas sa vyskytli nejaké artefakty, ktoré boli úplne nepochopiteľné. Keď sme však k systému pripojili tucet serverov, začali sa diať zázraky. Niekedy z neznámeho dôvodu všetky objekty v systéme jednoducho zmizli. Tu je dôležité poznamenať, že servery, ktoré mali klienti, posielali údaje na centrálny server každých pár sekúnd prostredníctvom požiadavky POST. Pozorný čitateľ a skúsený programátor už tušili, že je problém s viacnásobným prístupom práve k súboru, v ktorom bol serializovaný objekt uložený z rôznych vlákien súčasne. A práve keď sa to dialo, nastali zázraky so zmiznutím predmetov. Súbor sa jednoducho vyprázdnil. To všetko sa však nezistilo okamžite, ale až počas prevádzky s niekoľkými servermi. Počas tejto doby pribudla funkcia skenovania portov (servery posielali do centrály nielen informácie o dostupnosti zariadení, ale aj o otvorených portoch). Urobilo sa to volaním príkazu:
$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);
výsledky boli často nesprávne a skenovanie trvalo dlho. Úplne som zabudol na ping, robilo sa to cez fping:
system("fping -r 3 -t 100 {$this->ip}");
Toto tiež nebolo paralelné, a preto bol proces veľmi dlhý. Neskôr bol na fping naraz odoslaný celý zoznam IP adries potrebných na overenie a späť sme dostali hotový zoznam tých, ktorí odpovedali. Na rozdiel od nás, fping dokázal paralelizovať procesy.
Ďalšou bežnou rutinnou prácou bolo nastavenie niektorých služieb cez WEB. No napríklad ECP z MS Exchange. V podstate je to len odkaz. A rozhodli sme sa, že takéto odkazy musíme vedieť pridať priamo do systému, aby sme nemuseli hľadať v dokumentácii alebo niekde inde v záložkách, ako sa dostať do ECP konkrétneho klienta. Takto sa objavil koncept odkazov na zdroje pre systém, ich funkčnosť je k dispozícii dodnes a takmer sa nezmenila.
Ako fungujú odkazy na zdroje vo Veliame
Vzdialené pripojenia
Takto to vyzerá v akcii v aktuálnej verzii Veliam
Jednou z úloh bolo rýchle a pohodlné pripojenie k serverom, ktorých už bolo veľa (viac ako sto) a triedenie medzi miliónmi vopred uložených RDP skratiek bolo mimoriadne nepohodlné. Bol potrebný nástroj. Na internete existuje softvér, ktorý je niečo ako adresár pre takéto pripojenia RDP, ale nie sú integrované s monitorovacím systémom a účty sa nedajú uložiť. Zadávanie účtov pre rôznych klientov zakaždým je čisté peklo, keď sa pripájate desiatky krát denne k rôznym serverom. S SSH je to trochu lepšie, existuje veľa dobrého softvéru, ktorý vám umožňuje organizovať takéto pripojenia do priečinkov a pamätať si z nich účty. Ale sú tu 2 problémy. Prvým je, že sme nenašli ani jeden program na pripojenie RDP a SSH. Druhým je, že ak v určitom okamihu nie som pri počítači a potrebujem sa rýchlo pripojiť, alebo som len preinštaloval systém, budem musieť ísť do dokumentácie a pozrieť sa na účet od tohto klienta. Je to nepohodlné a strata času.
Hierarchická štruktúra, ktorú sme potrebovali pre klientske servery, bola už dostupná v našom internom produkte. Len som musel vymyslieť, ako tam pripevním rýchle spoje na potrebné vybavenie. Pre začiatok, aspoň v rámci vašej siete.
Berúc do úvahy skutočnosť, že klientom v našom systéme bol prehliadač, ktorý nemá prístup k miestnym zdrojom počítača, aby sme jednoducho spustili aplikáciu, ktorú sme potrebovali pomocou nejakého príkazu, bolo vynájdené robiť všetko cez „Windows vlastná schéma adresy URL“. Takto sa objavil určitý „plugin“ pre náš systém, ktorý jednoducho obsahoval Putty a Remote Desktop Plus a počas inštalácie jednoducho zaregistroval schému URI vo Windows. Teraz, keď sme sa chceli pripojiť k objektu cez RDP alebo SSH, klikli sme na túto akciu v našom systéme a Custom URI fungovalo. Bol spustený štandardný súbor mstsc.exe zabudovaný do systému Windows alebo putty, ktorý bol súčasťou „doplnku“. Slovo plugin som dal do úvodzoviek, pretože toto nie je doplnok prehliadača v klasickom zmysle.
To bolo aspoň niečo. Pohodlný adresár. Navyše v prípade Putty bolo vo všeobecnosti všetko v poriadku, ako vstupné parametre bolo možné zadať IP pripojenia, prihlasovacie meno a heslo. Tie. Už sme sa pripojili k serverom Linux v našej sieti jedným kliknutím bez zadávania hesiel. Ale s RDP to nie je také jednoduché. Štandardné mstsc nemôže poskytnúť poverenia ako parametre. Remote Desktop Plus prišiel na záchranu. Dovolil, aby sa to stalo. Teraz sa bez neho zaobídeme, no dlho bol verným pomocníkom v našom systéme. Pri HTTP(S) stránkach je všetko jednoduché, takéto objekty sa jednoducho otvoria v prehliadači a je to. Pohodlné a praktické. Ale to bolo šťastie iba na internej sieti.
Keďže sme drvivú väčšinu problémov riešili na diaľku z kancelárie, najjednoduchšie bolo sprístupniť klientom VPN. A potom bolo možné sa k nim pripojiť z nášho systému. Ale stále to bolo trochu nepohodlné. Pre každého klienta bolo potrebné zachovať na každom počítači kopu zapamätaných VPN pripojení a pred pripojením k akémukoľvek bolo potrebné povoliť zodpovedajúcu VPN. Toto riešenie sme používali pomerne dlho. Ale klientov pribúda, pribúda aj VPN a toto všetko začalo napínať a bolo s tým treba niečo robiť. Slzy sa mi tlačili do očí najmä po preinštalovaní systému, keď som musel znova zadať desiatky VPN pripojení v novom Windows profile. Prestaň to znášať, povedal som a začal som rozmýšľať, čo by som s tým mohol urobiť.
Stalo sa, že všetci klienti mali ako routery zariadenia od známej firmy Mikrotik. Sú veľmi funkčné a vhodné na vykonávanie takmer akejkoľvek úlohy. Nevýhodou je, že sú „unesené“. Tento problém sme vyriešili jednoducho uzavretím všetkých prístupov zvonku. Bolo však potrebné nejako sa k nim dostať bez toho, aby som prišiel ku klientovi, pretože... je to dlhé. Pre každý takýto Mikrotik sme jednoducho urobili tunely a oddelili ich do samostatného bazéna. bez akéhokoľvek smerovania, aby nedochádzalo k prepojeniu vašej siete so sieťami klientov a ich sieťami medzi sebou.
Zrodila sa myšlienka zabezpečiť, že keď kliknem na objekt, ktorý v systéme potrebujem, centrálny monitorovací server, ktorý pozná SSH účty všetkých klientov Mikrotik, sa pripojí k požadovanému a vytvorí pravidlo preposielania na požadovaný hostiteľ s požadovaný port. Je tu niekoľko bodov. Riešenie nie je univerzálne - bude fungovať iba pre Mikrotik, pretože syntax príkazov je pre všetky smerovače odlišná. Také preposielania potom museli byť nejakým spôsobom vymazané a serverová časť nášho systému v podstate nemohla žiadnym spôsobom sledovať, či som ukončil svoju RDP reláciu. No takéto preposielanie je pre klienta diera. Ale nesledovali sme univerzálnosť, pretože... výrobok bol používaný len v rámci našej spoločnosti a o jeho uvoľnení na verejnosť sa neuvažovalo.
Každý z problémov bol vyriešený vlastným spôsobom. Pri vytváraní pravidla bolo toto presmerovanie dostupné len pre jednu konkrétnu externú IP adresu (z ktorej sa inicializovalo spojenie). Tak sa predišlo bezpečnostnej diere. Ale pri každom takomto pripojení sa na stránku NAT pridalo pravidlo Mikrotik a nebolo vymazané. A každý vie, že čím viac pravidiel existuje, tým viac je zaťažený procesor smerovača. A vôbec som nemohol akceptovať, že jedného dňa pôjdem na nejaký Mikrotik a budú tam stovky mŕtvych, zbytočných pravidiel.
Keďže náš server nemôže sledovať stav pripojenia, nechajte Mikrotik sledovať ich sám. A napísal som skript, ktorý neustále sledoval všetky pravidlá preposielania s konkrétnym popisom a kontroloval, či má TCP spojenie vhodné pravidlo. Ak už nejaký čas neexistuje, pripojenie už bolo pravdepodobne dokončené a toto preposielanie je možné vymazať. Všetko vyšlo, scenár fungoval dobre.
Mimochodom, tu je:
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="Removing nat rules added automaticaly by atmon_script"
/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
}
}
Určite sa to dalo spraviť krajšie, rýchlejšie atď., ale fungovalo to, nenačítalo Mikrotik a odviedlo to na výbornú. Konečne sme sa mohli pripojiť k serverom a sieťovým zariadeniam klientov jediným kliknutím. Bez otvárania VPN alebo zadávania hesiel. Systém sa stal skutočne pohodlným na prácu. Skrátil sa servisný čas a všetci sme trávili čas prácou a nie pripájaním sa k potrebným objektom.
Záloha Mikrotik
Nastavili sme zálohovanie všetkých Mikrotikov na FTP. A celkovo bolo všetko v poriadku. Ale keď ste potrebovali získať zálohu, museli ste otvoriť tento FTP a hľadať ho tam. Máme systém, kde sú pripojené všetky smerovače, so zariadeniami môžeme komunikovať cez SSH. Prečo to neurobíme tak, aby si systém sám robil zálohy zo všetkých Mikrotikov denne, pomyslel som si. A začal to realizovať. Pripojili sme sa, urobili zálohu a odniesli ju do úložiska.
Kód skriptu v PHP na vytvorenie zálohy z Mikrotiku:
<?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); // Waiting bakup makes
$sftp = ssh2_sftp($connection);
// Download backup file
$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);
// Download RSC file
$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');
?>
Záloha prebieha v dvoch formách – binárna a textová konfigurácia. Binárna pomáha rýchlo obnoviť požadovanú konfiguráciu a textová vám umožňuje pochopiť, čo je potrebné urobiť, ak dôjde k nútenej výmene zariadenia a binárny súbor sa doň nedá nahrať. Výsledkom je, že sme v systéme získali ďalšiu pohodlnú funkciu. Navyše pri pridávaní nového Mikrotiku nebolo potrebné nič konfigurovať, jednoducho som objekt pridal do systému a nastavil mu účet cez SSH. Potom sa o zálohovanie postaral samotný systém. Aktuálna verzia SaaS Veliam zatiaľ túto funkcionalitu nemá, ale čoskoro ju prenesieme.
Snímky obrazovky, ako to vyzeralo v internom systéme
Prechod na normálne úložisko databázy
Už som písal vyššie, že sa objavili artefakty. Niekedy jednoducho zmizol celý zoznam objektov v systéme, niekedy sa pri úprave objektu informácie neuložili a objekt bolo potrebné trikrát premenovať. To všetkých strašne dráždilo. K zmiznutiu objektov dochádzalo zriedkavo a bolo možné ho ľahko obnoviť obnovením práve tohto súboru, ale k zlyhaniam pri úprave objektov dochádzalo pomerne často. Pravdepodobne som to spočiatku nerobil cez databázu, pretože mi nezodpovedalo, ako je možné udržať strom so všetkými spojeniami v rovnej tabuľke. Je plochý, ale strom je hierarchický. Ale dobrým riešením pre viacnásobný prístup a následne (ako sa systém stáva zložitejším) transakčný je DBMS. Asi nie som prvý, kto sa s týmto problémom stretol. Začal som googliť. Ukázalo sa, že všetko už bolo vynájdené predo mnou a existuje niekoľko algoritmov, ktoré stavajú strom z plochého stola. Po zhliadnutí každého z nich som implementoval jeden z nich. Ale toto už bola nová verzia systému, pretože... V skutočnosti som kvôli tomu musel dosť veľa prepisovať. Výsledok bol prirodzený, problémy náhodného správania systému odišli. Niekto by mohol povedať, že chyby sú veľmi amatérske (jednovláknové skripty, ukladanie informácií, ku ktorým sa pristupovalo viackrát súčasne z rôznych vlákien v súbore a pod.) v oblasti vývoja softvéru. Možno je to pravda, ale mojou hlavnou náplňou práce bola administratíva a programovanie bol pre mňa zhon na duši a jednoducho som nemal skúsenosti s prácou v tíme programátorov, kde by mi takéto základné veci okamžite navrhol môj starší súdruhovia. Všetky tieto hrbolčeky som si preto vyplnila sama, no látku som sa naučila veľmi dobre. A moja práca zahŕňa stretnutia s klientmi, akcie zamerané na propagáciu spoločnosti, kopu administratívnych záležitostí v rámci spoločnosti a mnoho, oveľa viac. Ale tak či onak, to, čo tam už bolo, bolo žiadané. S chlapcami sme tento produkt používali pri každodennej práci. Boli úprimne neúspešné nápady a riešenia, na ktorých sa strácal čas, ale nakoniec sa ukázalo, že to nie je pracovný nástroj a nikto ho nepoužíval a neskončil vo Veliame.
Helpdesk - HelpDesk
Nebolo by od veci spomenúť, ako vznikol HelpDesk. Toto je úplne iný príbeh, pretože... vo Veliame je to už 3. úplne nová verzia, ktorá je iná ako všetky predchádzajúce. Teraz je to jednoduchý systém, intuitívny bez zbytočných zvončekov a píšťaliek, s možnosťou integrácie s doménou, ako aj s možnosťou prístupu k rovnakému užívateľskému profilu odkiaľkoľvek pomocou odkazu z e-mailu. A hlavne je možné pripojiť sa k žiadateľovi cez VNC odkiaľkoľvek (doma alebo v kancelárii) priamo z aplikácie bez VPN či presmerovania portov. Poviem vám, ako sme sa k tomu dostali, čo sa stalo predtým a aké hrozné rozhodnutia boli prijaté.
K používateľom sme sa pripojili cez známy TeamViewer. Všetky počítače, ktorých používateľov obsluhujeme, majú nainštalovaný televízor. Prvá vec, ktorú sme urobili zle a následne sme ju odstránili, bolo prepojenie každého HD klienta s hardvérom. Ako sa používateľ prihlásil do systému HD, aby mohol zanechať požiadavku? Okrem TV mal každý na svojom počítači nainštalovanú špeciálnu utilitu napísanú v Lazarus (mnohí tu budú prevracať oči a možno si aj vygúgli, čo to je, ale najlepšie skompilovaný jazyk, ktorý som poznal, bol Delphi a Lazarus je skoro to isté, len zadarmo). Vo všeobecnosti používateľ spustil špeciálny dávkový súbor, ktorý spustil tento nástroj, ktorý zase načítal HWID systému a potom sa spustil prehliadač a došlo k autorizácii. Prečo sa to urobilo? V niektorých spoločnostiach sa počet obsluhovaných používateľov počíta individuálne a cena služby za každý mesiac sa odvíja od počtu osôb. To je pochopiteľné, hovoríte si, ale prečo je to viazané na hardvér? Je to veľmi jednoduché, niektorí ľudia prišli domov a zo svojho domáceho notebooku požiadali v štýle „urob mi tu všetko krásne“. Okrem čítania systémového HWID utilita stiahla aktuálne ID Teamviewer z registra a tiež nám ho preniesla. Teamviewer má rozhranie API na integráciu. A urobili sme túto integráciu. Malo to však jeden háčik. Prostredníctvom týchto rozhraní API nie je možné pripojiť sa k počítaču používateľa, keď túto reláciu výslovne neiniciuje a po pokuse o pripojenie k nej musí kliknúť aj na „potvrdiť“. Vtedy sa nám zdalo logické, že nikto by sa nemal pripojiť bez žiadosti používateľa, a keďže je táto osoba pri počítači, iniciuje reláciu a na žiadosť o vzdialené pripojenie odpovie kladne. Všetko dopadlo zle. Uchádzači zabudli stlačiť tlačidlom iniciovať reláciu a museli im to povedať v telefonickom rozhovore. Tento premárnený čas bol frustrujúci na oboch stranách procesu. Navyše nie je vôbec nezvyčajné, že také chvíle, keď človek zanechá žiadosť, ale smie sa pripojiť až vtedy, keď odchádza na obed. Pretože problém nie je kritický a nechce, aby bol jeho pracovný proces prerušený. V súlade s tým nestlačí žiadne tlačidlo na povolenie pripojenia. Takto sa objavila dodatočná funkcionalita pri prihlásení do HelpDesk - čítanie Teamviwer's ID. Poznali sme trvalé heslo, ktoré sa použilo pri inštalácii Teamviwer. Presnejšie, vedel to iba systém, keďže bol zabudovaný do inštalátora a do nášho systému. V súlade s tým existovalo tlačidlo pripojenia z aplikácie kliknutím, na ktoré nebolo potrebné na nič čakať, ale Teamviewer sa okamžite otvoril a došlo k pripojeniu. V dôsledku toho existovali dva typy možných spojení. Prostredníctvom oficiálneho Teamviewer API a nášho vlastného vytvoreného. Na moje prekvapenie prvý z nich prestali používať takmer okamžite, aj keď tam bol návod na použitie len v špeciálnych prípadoch a keď k tomu dá súhlas sám používateľ. Napriek tomu mi teraz daj istotu. Ukázalo sa však, že to žiadatelia nepotrebujú. Všetky sú úplne v poriadku, ak sú k nim pripojené bez potvrdzovacieho tlačidla.
Prechod na multithreading v Linuxe
Otázka urýchlenia prechodu sieťového skenera pre otvorenosť vopred určeného zoznamu portov a jednoduché pingovanie sieťových objektov sa už dávno začala vynárať. Tu, samozrejme, prvé riešenie, ktoré príde na myseľ, je multithreading. Keďže hlavný čas strávený pingom je čakanie na vrátenie paketu a ďalší ping nemôže začať, kým sa nevráti predchádzajúci paket, v spoločnostiach, ktoré mali dokonca 20+ serverov plus sieťové vybavenie, to už fungovalo dosť pomaly. Ide o to, že jeden balík môže zmiznúť, ale neinformujte o tom okamžite správcu systému. Jednoducho veľmi rýchlo prestane prijímať takýto spam. To znamená, že musíte pingovať každý objekt viac ako raz, kým urobíte záver o neprístupnosti. Bez toho, aby sme zachádzali do prílišných podrobností, je potrebné to paralelizovať, pretože ak sa tak nestane, správca systému sa s najväčšou pravdepodobnosťou dozvie o probléme od klienta a nie od monitorovacieho systému.
Samotné PHP nepodporuje multithreading hneď po vybalení. Schopný multiprocessing, môžete vidličkou. Ale v skutočnosti som už mal napísaný mechanizmus dopytovania a chcel som to urobiť tak, že raz spočítam všetky uzly, ktoré potrebujem z databázy, pingujem všetko naraz, čakám na odpoveď od každého a až potom okamžite napíšem dáta. Tým sa ušetrí počet požiadaviek na čítanie. Multithreading do tejto myšlienky dokonale zapadá. Pre PHP existuje modul PThreads, ktorý vám umožňuje robiť skutočný multithreading, hoci nastavenie tohto nastavenia v PHP 7.2 si vyžadovalo poriadnu dávku práce, ale podarilo sa. Skenovanie portov a ping sú teraz rýchle. A namiesto napríklad 15 sekúnd na kolo skôr, tento proces začal trvať 2 sekundy. Bol to dobrý výsledok.
Rýchly audit nových spoločností
Ako vznikla funkcionalita na zhromažďovanie rôznych metrík a hardvérových charakteristík? Je to jednoduché. Niekedy nám jednoducho nariadia audit súčasnej IT infraštruktúry. No to isté je potrebné na urýchlenie auditu nového klienta. Potrebovali sme niečo, čo by nám umožnilo prísť do strednej alebo veľkej spoločnosti a rýchlo zistiť, čo majú. Podľa mňa ping na internej sieti blokuje len ten, kto si chce skomplikovať život a takých je podľa našich skúseností málo. Ale sú aj takí ľudia. V súlade s tým môžete rýchlo skenovať siete na prítomnosť zariadení pomocou jednoduchého pingu. Potom ich môžeme pridať a vyhľadať otvorené porty, ktoré nás zaujímajú. V skutočnosti táto funkcionalita už existovala, bolo len potrebné pridať príkaz z centrálneho servera na podriadený, aby prehľadal zadané siete a pridal do zoznamu všetko, čo našiel. Zabudol som spomenúť, predpokladalo sa, že už máme hotový image s nakonfigurovaným systémom (podriadený monitorovací server), ktorý sme mohli jednoducho stiahnuť z klienta počas auditu a pripojiť ho k nášmu cloudu.
Výsledok auditu však zvyčajne obsahuje množstvo rôznych informácií a jednou z nich je, aké zariadenia sú v sieti. V prvom rade nás zaujímali Windows servery a Windows pracovné stanice ako súčasť domény. Keďže v stredných a veľkých spoločnostiach je absencia domény pravdepodobne výnimkou z pravidla. Hovoriť jedným jazykom, priemer je podľa mňa 100+ ľudí. Bolo potrebné vymyslieť spôsob, ako zbierať údaje zo všetkých počítačov a serverov so systémom Windows, poznať ich IP a účet správcu domény, ale bez inštalácie akéhokoľvek softvéru na každý z nich. Na pomoc prichádza rozhranie WMI. Windows Management Instrumentation (WMI) doslova znamená nástroje na správu systému Windows. WMI je jednou zo základných technológií pre centralizovanú správu a monitorovanie prevádzky rôznych častí počítačovej infraštruktúry s platformou Windows. Prevzaté z wiki. Ďalej som sa musel znova pohrať, aby som skompiloval wmic (toto je klient WMI) pre Debian. Keď bolo všetko pripravené, zostávalo už len jednoducho požiadať potrebné uzly cez wmic o potrebné informácie. Prostredníctvom WMI môžete získať takmer akékoľvek informácie z počítača so systémom Windows a navyše cez neho môžete počítač ovládať, napríklad ho poslať na reštart. Takto vyzeral zber informácií o staniciach a serveroch Windows v našom systéme. Okrem toho tu boli aktuálne informácie o aktuálnych indikátoroch zaťaženia systému. Požadujeme ich častejšie a informácie o hardvéri menej často. Potom sa auditovanie stalo o niečo príjemnejším.
Rozhodnutie o distribúcii softvéru
My sami systém používame každý deň a je vždy otvorený pre každého technického zamestnanca. A napadlo nás, že by sme sa s ostatnými mohli podeliť o to, čo už máme. Systém ešte nebol pripravený na distribúciu. Aby sa lokálna verzia zmenila na SaaS, bolo treba veľa prepracovať. Patria sem zmeny v rôznych technických aspektoch systému (vzdialené pripojenia, služba podpory), analýza modulov pre licencovanie, sharding zákazníckych databáz, škálovanie každej služby a vývoj systémov automatických aktualizácií pre všetky časti. Ale toto bude druhá časť článku.
Aktualizácia
Zdroj: hab.com