Sveiki visi, mano vardas Sergejus Emelyančikas. Esu Audit-Telecom įmonės vadovas, pagrindinis Veliam sistemos kūrėjas ir autorius. Nusprendžiau parašyti straipsnį apie tai, kaip su draugu sukūrėme užsakomųjų paslaugų įmonę, rašėme sau programinę įrangą ir vėliau pradėjome ją platinti visiems per SaaS sistemą. Apie tai, kaip aš kategoriškai netikėjau, kad tai įmanoma. Straipsnyje bus ne tik istorija, bet ir techninės detalės, kaip buvo sukurtas Veliam produktas. Įskaitant kai kurias šaltinio kodo dalis. Papasakosiu, kokias klaidas padarėme ir kaip jas ištaisėme vėliau. Kilo abejonių, ar skelbti tokį straipsnį. Bet aš maniau, kad geriau tai padaryti, gauti atsiliepimų ir tobulėti, nei nepublikuoti straipsnio ir galvoti, kas būtų buvę, jei...
priešistorė
Dirbau vienoje įmonėje IT darbuotoja. Įmonė buvo gana didelė su plačia tinklo struktūra. Prie savo darbo pareigų nesigilinsiu, pasakysiu tik tiek, kad jos tikrai neapėmė nieko tobulinimo.
Stebėjome, bet vien iš akademinio susidomėjimo norėjau pabandyti parašyti savo paprasčiausią. Idėja buvo tokia: norėjau, kad tai būtų žiniatinklyje, kad galėčiau lengvai prisijungti neįdiegęs jokių klientų ir pamatyti, kas vyksta tinkle iš bet kurio įrenginio, įskaitant mobilųjį įrenginį per Wi-Fi, ir aš taip pat tikrai Norėjosi greitai suprasti, kas Kambaryje yra įranga, kuri tapo „netikėta“, nes... buvo nustatyti labai griežti reagavimo į tokias problemas laiko reikalavimai. Dėl to mano galvoje gimė planas parašyti paprastą tinklalapį, kuriame būtų jpeg fonas su tinklo schema, iškirpti pačius įrenginius su jų IP adresais šiame paveikslėlyje, o viršuje rodyti dinamišką turinį. paveikslėlį reikiamomis koordinatėmis žalio arba mirksinčio raudono IP adreso pavidalu. Užduotis nustatyta, pradėkime.
Anksčiau programavau Delphi, PHP, JS ir labai paviršutiniškai C++. Puikiai žinau, kaip veikia tinklai. VLAN, maršruto parinkimas (OSPF, EIGRP, BGP), NAT. To man pakako, kad galėčiau pats parašyti primityvų stebėjimo prototipą.
Ką planavau, parašiau PHP. „Apache“ ir PHP serveris buvo „Windows“, nes... Linux man tuo metu buvo kažkas nesuprantamo ir labai sudėtingo, kaip vėliau paaiškėjo, aš labai klydau ir daug kur Linux yra daug paprastesnis nei Windows, bet tai yra atskira tema ir mes visi žinome, kiek holivarų yra Ši tema. „Windows“ užduočių planuoklis nedideliu intervalu (tiksliai nepamenu, bet kažką panašaus į tris sekundes) ištraukė PHP scenarijų, kuris banaliu pingu apklausė visus objektus ir išsaugojo būseną faile.
system(“ping -n 3 -w 100 {$ip_address}“);
Taip, taip, darbas su duomenų baze tuo metu man taip pat nebuvo įvaldytas. Nežinojau, kad galima lygiagretinti procesus, o perėjimas per visus tinklo mazgus užtruko ilgai, nes... tai atsitiko vienoje temoje. Problemų ypač kilo, kai keli mazgai buvo nepasiekiami, nes kiekvienas iš jų uždelsė scenarijų 300 ms. Kliento pusėje buvo paprasta kilpos funkcija, kuri kelių sekundžių intervalais atsisiųsdavo atnaujintą informaciją iš serverio su Ajax užklausa ir atnaujindavo sąsają. Na, o tada, po 3 nesėkmingų pingų iš eilės, jei kompiuteryje buvo atidarytas tinklalapis su stebėjimu, sugrojo nuotaikingą kompoziciją.
Kai viskas pavyko, rezultatas mane labai įkvėpė ir pagalvojau, kad galiu jį papildyti (dėl savo žinių ir galimybių). Tačiau man visada nepatiko sistemos su milijonu diagramų, kurios, tada maniau ir iki šiol manau, daugeliu atvejų yra nereikalingos. Norėjau ten įdėti tik tai, kas man tikrai padėtų mano darbe. Šis principas išlieka esminis Veliamo vystymuisi iki šiol. Be to, supratau, kad būtų labai šaunu, jei man nereikėtų nuolat stebėti ir žinoti apie problemas, o kai tai atsitiks, atsidaryk puslapį ir pažiūrėk, kur yra šis probleminis tinklo mazgas ir ką su juo daryti toliau. . Kažkaip tada neskaičiau elektroninio pašto, paprasčiausiai jo nenaudojau. Internete aptikau, kad yra SMS vartai, į kuriuos galite siųsti GET arba POST užklausą, ir jie atsiųs SMS į mano mobilųjį telefoną su tekstu, kurį rašau. Iš karto supratau, kad labai to noriu. Ir aš pradėjau studijuoti dokumentaciją. Po kurio laiko man pavyko, o dabar gavau SMS apie problemas tinkle į savo mobilųjį telefoną „nukritusio objekto“ pavadinimu. Nors sistema buvo primityvi, ją parašiau aš pats, o svarbiausia ją kurti paskatino tai, kad tai buvo taikomoji programa, kuri man tikrai padėjo mano darbe.
Ir tada atėjo diena, kai vienas iš interneto kanalų nutrūko, o mano stebėjimas man apie tai nepranešė. Kadangi „Google“ DNS vis tiek skambėjo puikiai. Atėjo laikas pagalvoti, kaip galite stebėti, kad komunikacijos kanalas gyvuotų. Buvo įvairių idėjų, kaip tai padaryti. Aš neturėjau prieigos prie visos įrangos. Turėjome sugalvoti, kaip suprasti, kuris iš kanalų yra tiesioginis, bet negalėdami jo kažkaip peržiūrėti pačioje tinklo įrangoje. Tada kolega sugalvojo, kad gali būti, kad maršruto sekimas iki viešųjų serverių gali skirtis priklausomai nuo to, kokiu ryšio kanalu šiuo metu pasiekiamas internetas. Patikrinau ir taip išėjo. Atsekant buvo skirtingi maršrutai.
system(“tracert -d -w 500 8.8.8.8”);
Taigi atsirado kitas scenarijus, tiksliau, kažkodėl pėdsakas buvo pridėtas prie to paties scenarijaus pabaigos, kuris sujungė visus tinklo įrenginius. Juk tai dar vienas ilgas procesas, kuris buvo vykdomas toje pačioje gijoje ir sulėtino viso scenarijaus darbą. Bet tada tai nebuvo taip akivaizdu. Bet vienaip ar kitaip jis atliko savo darbą, kodas griežtai apibrėžė, koks turi būti kiekvieno kanalo sekimas. Taip pradėjo veikti sistema, kuri jau stebėjo (garsiai pasakyta, nes nebuvo jokių metrikų rinkimo, o tik ping) tinklo įrenginius (maršrutizatorius, komutatorius, wi-fi ir pan.) ir ryšio kanalus su išoriniu pasauliu. . Reguliariai gaudavo SMS žinutes, o diagrama visada aiškiai parodydavo kur problema.
Be to, kasdieniame darbe turėjau atlikti kryžminį perėjimą. Ir aš pavargau kiekvieną kartą eiti į „Cisco“ komutatorius, kad pamatyčiau, kurią sąsają naudoti. Kaip šaunu būtų spustelėti objektą stebint ir pamatyti jo sąsajų sąrašą su aprašymais. Tai sutaupytų man laiko. Be to, šioje schemoje nereikėtų paleisti „Putty“ ar „SecureCRT“, kad būtų galima įvesti paskyras ir komandas. Tiesiog paspaudžiau stebėjimą, pamačiau, ko reikia, ir nuėjau dirbti savo darbo. Pradėjau ieškoti būdų, kaip bendrauti su jungikliais. Iš karto susidūriau su 2 galimybėmis: SNMP arba prisijungimas prie jungiklio per SSH, įvedus man reikalingas komandas ir analizuojant rezultatą. Atsisakiau SNMP dėl jo įgyvendinimo sudėtingumo; nekantrauju gauti rezultato. naudojant SNMP, tektų ilgai gilintis į MIB ir, remiantis šiais duomenimis, generuoti duomenis apie sąsajas. CISCO dirba nuostabi komanda
show interface statusTai tiksliai parodo, ko man reikia kryžkelėms. Kam nerimauti su SNMP, kai noriu tik pamatyti šios komandos išvestį, pagalvojau. Po kurio laiko aš supratau šią galimybę. Spustelėjo objektą tinklalapyje. Buvo suaktyvintas įvykis, kurio metu AJAX klientas susisiekė su serveriu, kuris savo ruožtu per SSH prisijungė prie man reikalingo jungiklio (kredencialai buvo užkoduoti į kodą, nebuvo noro jo tobulinti, daryti atskirus meniu, kur būtų galima pakeisti paskyras iš sąsajos , man reikėjo rezultato ir greitai) ten įvedžiau aukščiau nurodytą komandą ir išsiunčiau atgal į naršyklę. Taigi vienu pelės paspaudimu pradėjau matyti informaciją apie sąsajas. Tai buvo labai patogu, ypač kai reikėjo peržiūrėti šią informaciją skirtinguose jungikliuose vienu metu.
Kanalo stebėjimas, pagrįstas pėdsakais, nebuvo pati geriausia idėja, nes... kartais buvo atliekami darbai tinkle, sekimas galėjo pasikeisti ir stebėjimas pradėjo rėkti ant manęs, kad yra problemų su kanalu. Tačiau daug laiko skyręs analizei supratau, kad visi kanalai veikia, o mano stebėjimas mane apgaudinėja. Todėl paprašiau savo kolegų, kurie valdė kanalų formavimo jungiklius, tiesiog atsiųsti man sistemos žurnalą, kai pasikeičia kaimynų matomumo būsena. Atitinkamai, tai buvo daug paprasčiau, greičiau ir tiksliau nei sekti. Atvyko toks įvykis kaip kaimynas, ir aš nedelsdamas išduodu pranešimą, kad kanalas neveikia.
Be to, spustelėjus objektą pasirodė dar kelios komandos, o SNMP buvo pridėtas tam, kad būtų surinkta kai kuri metrika, ir iš esmės viskas. Sistema niekada nebuvo vystoma toliau. Tai padarė viską, ko man reikėjo, tai buvo geras įrankis. Daugelis skaitytojų tikriausiai man pasakys, kad internete jau yra daug programinės įrangos šioms problemoms spręsti. Bet tiesą sakant, tada aš tokių nemokamų produktų „Google“ neieškojau ir labai norėjau tobulinti savo programavimo įgūdžius, o kas gali būti geresnis būdas tai padaryti, nei tikra taikymo problema. Šiuo metu pirmoji stebėjimo versija buvo baigta ir nebebuvo keičiama.
Įmonės Audit-Telecom sukūrimas
Laikui bėgant pradėjau dirbti ne visą darbo dieną kitose įmonėse, laimei, mano darbo grafikas leido tai padaryti. Kai dirbi skirtingose įmonėse, labai greitai auga tavo įgūdžiai įvairiose srityse, tobulėja akiratis. Yra įmonių, kuriose, kaip sakoma, esi ir švedas, ir pjovėjas, ir trimitininkas. Viena vertus, sunku, kita vertus, jei netingi, tampi generalistu ir tai leidžia greičiau bei efektyviau spręsti problemas, nes žinai, kaip veikia susijusi sritis.
Mano draugas Pavelas (taip pat IT specialistas) nuolat bandė mane paskatinti pradėti savo verslą. Buvo daugybė idėjų su skirtingais to, ką jie darė, variantai. Apie tai diskutuojama ne vienerius metus. Ir galų gale, tai neturėjo nieko daryti, nes aš esu skeptikas, o Pavelas yra svajotojas. Kiekvieną kartą, kai jis pasiūlė idėją, aš visada ja netikėjau ir atsisakydavau dalyvauti. Bet mes tikrai norėjome atidaryti savo verslą.
Pagaliau pavyko rasti variantą, kuris tiko mums abiem ir daryti tai, ką mokame. 2016 metais nusprendėme sukurti IT įmonę, kuri padėtų verslui spręsti IT problemas. Tai IT sistemų (1C, terminalo serverio, pašto serverio ir kt.) diegimas, jų priežiūra, klasikinis HelpDesk vartotojams ir tinklo administravimas.
Atvirai kalbant, įmonės kūrimo metu netikėjau tuo apie 99,9%. Bet kažkaip Pavelas sugebėjo priversti mane pabandyti, o žvelgiant į priekį pasirodė, kad jis buvo teisus. Mes su Pavelu sumokėjome po 300 000 rublių, įregistravome naują UAB „Audit-Telecom“, išsinuomojome mažytį biurą, padarėme šaunias vizitines korteles, na, apskritai, kaip turbūt dauguma nepatyrusių, pradedančių verslininkų, pradėjome ieškoti klientų. Klientų paieška yra visiškai kita istorija. Galbūt parašysime atskirą straipsnį kaip įmonės tinklaraščio dalį, jei kas nors susidomės. Šaltieji skambučiai, skrajutės ir kt. Tai nedavė jokių rezultatų. Kaip dabar skaitau iš daugelio istorijų apie verslą, vienaip ar kitaip, daug kas priklauso nuo sėkmės. Mums pasisekė. ir tiesiogine prasme praėjus porai savaičių po įmonės sukūrimo į mus kreipėsi brolis Vladimiras, kuris atvežė mums pirmąjį klientą. Nevarginsiu jūsų darbo su klientais smulkmenomis, straipsnis ne apie tai, tik pasakysiu, kad nuėjome atlikti auditą, nustatėme kritines sritis ir šios sritys sugedo, kol buvo priimtas sprendimas, ar nuolat bendradarbiauja su mumis kaip užsakovai. Po to iškart buvo priimtas teigiamas sprendimas.
Tada, daugiausia iš lūpų į lūpas per draugus, pradėjo atsirasti kitos paslaugų įmonės. Pagalbos tarnyba buvo vienoje sistemoje. Ryšiai su tinklo įranga ir serveriais yra skirtingi, tiksliau – skirtingi. Kai kurie žmonės išsaugojo nuorodas, kiti naudojo KPP adresų knygas. Stebėjimas yra dar viena atskira sistema. Labai nepatogu komandai dirbti skirtingose sistemose. Svarbi informacija prarandama iš akių. Na, pavyzdžiui, kliento terminalo serveris tapo nepasiekiamas. Paraiškos iš šio kliento vartotojų gaunamos nedelsiant. Pagalbos specialistas atidaro užklausą (ji gauta telefonu). Jei incidentai ir užklausos būtų registruojami vienoje sistemoje, tai palaikymo specialistas iš karto pamatytų, kokia yra vartotojo problema ir apie tai jam praneštų, tuo pačiu prisijungdamas prie reikiamo objekto, kad išsiaiškintų situaciją. Visi žino taktinę situaciją ir dirba darniai. Neradome sistemos, kurioje visa tai būtų sujungta. Tapo aišku, kad laikas gaminti savo gaminį.
Tęsiamas darbas su jūsų stebėjimo sistema
Buvo aišku, kad anksčiau parašyta sistema visiškai netinkama dabartinėms užduotims. Nei funkcionalumo, nei kokybės prasme. Ir buvo nuspręsta sistemą parašyti nuo nulio. Grafiškai jis turėjo atrodyti visiškai kitaip. Tai turėjo būti hierarchinė sistema, kad būtų galima greitai ir patogiai atidaryti reikiamą objektą tinkamam klientui. Schema, kaip ir pirmoje versijoje, šiuo atveju buvo visiškai nepagrįsta, nes Klientai yra skirtingi ir visiškai nesvarbu, kuriose patalpose yra įranga. Tai jau perkelta į dokumentaciją.
Taigi, užduotys:
- Hierarchinė struktūra;
- Kažkokia serverio dalis, kurią galima patalpinti kliento patalpose virtualios mašinos pavidalu, kad surinktume mums reikalingus rodiklius ir nusiunčiame į centrinį serverį, kuris visa tai apibendrins ir parodys mums;
- Perspėjimai. Tie, kurių negalima praleisti, nes... tuo metu nebuvo galima kam nors sėdėti ir tiesiog žiūrėti į monitorių;
- Taikymo sistema. Pradėjo atsirasti klientų, kuriems aptarnavome ne tik serverių ir tinklo įrangą, bet ir darbo vietas;
- Galimybė greitai prisijungti prie serverių ir įrangos iš sistemos;
Užduotys nustatytos, pradedame rašyti. Pakeliui apdorojame klientų užklausas. Tuo metu mūsų jau buvo 4. Pradėjome rašyti iš karto abi dalis: centrinį serverį ir serverį, skirtą įdiegti klientams. Šiuo metu „Linux“ mums nebebuvo svetima ir buvo nuspręsta, kad virtualios mašinos, kurias turės klientai, bus „Debian“. Diegėjų nebus, tiesiog sukursime serverio dalies projektą vienoje konkrečioje virtualioje mašinoje, o tada tik klonuuosime jį į norimą klientą. Tai buvo dar viena klaida. Vėliau paaiškėjo, kad tokioje schemoje atnaujinimo mechanizmas buvo visiškai neišplėtotas. Tie. pridėjome kažkokią naują funkciją, o tada kilo problema ją paskirstyti visiems klientų serveriams, bet prie to grįšime vėliau, viskas tvarkinga.
Sukūrėme pirmąjį prototipą. Jis sugebėjo išsiųsti mums reikalingus klientų tinklo įrenginius ir serverius ir nusiųsti šiuos duomenis į mūsų centrinį serverį. Ir jis savo ruožtu šiuos duomenis masiškai atnaujino centriniame serveryje. Čia parašysiu ne tik pasakojimą apie tai, kaip ir kas sekėsi, bet ir kokios mėgėjiškos klaidos buvo padarytos ir kaip vėliau teko už tai sumokėti su laiku. Taigi visas objektų medis buvo saugomas viename faile serijinio objekto pavidalu. Kol prijungėme kelis klientus prie sistemos, viskas buvo daugmaž normalu, nors kartais pasitaikydavo ir visiškai nesuprantamų artefaktų. Tačiau kai prie sistemos prijungėme tuziną serverių, pradėjo vykti stebuklai. Kartais dėl nežinomos priežasties visi sistemos objektai tiesiog išnykdavo. Čia svarbu pažymėti, kad serveriai, kuriuos klientai siuntė duomenis į centrinį serverį kas kelias sekundes per POST užklausą. Dėmesingas skaitytojas ir patyręs programuotojas jau spėjo, kad kilo problema dėl kelių prieigos prie paties failo, kuriame vienu metu iš skirtingų gijų buvo saugomas serializuotas objektas. Ir kaip tik tada, kai tai vyko, dingus daiktams įvyko stebuklai. Failas tiesiog tapo tuščias. Bet visa tai buvo aptikta ne iš karto, o tik dirbant su keliais serveriais. Per šį laiką buvo pridėta prievadų nuskaitymo funkcija (serveriai į centrą siuntė ne tik informaciją apie įrenginių prieinamumą, bet ir apie juose atidarytus prievadus). Tai buvo padaryta iškvietus komandą:
$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);
rezultatai dažnai buvo neteisingi, o nuskaitymas užtruko ilgai. Aš visiškai pamiršau apie ping, tai buvo padaryta per fping:
system("fping -r 3 -t 100 {$this->ip}");
Tai taip pat nebuvo lygiagreti, todėl procesas buvo labai ilgas. Vėliau visas patvirtinimui reikalingų IP adresų sąrašas buvo išsiųstas iš karto į fping, o atgal gavome jau paruoštą atsakiusiųjų sąrašą. Skirtingai nei mes, fping galėjo lygiagretinti procesus.
Kitas įprastas darbas buvo kai kurių paslaugų nustatymas per WEB. Na, pavyzdžiui, ECP iš MS Exchange. Iš esmės tai tik nuoroda. Ir nusprendėme, kad tokias nuorodas reikia turėti galimybę įdėti tiesiai į sistemą, kad nereikėtų ieškoti dokumentacijoje ar kur kitur žymose, kaip pasiekti konkretaus kliento ECP. Taip atsirado sistemos resursų nuorodų koncepcija, jų funkcionalumas prieinamas iki šiol ir nepasikeitė, na, beveik.
Kaip Veliam veikia išteklių nuorodos
Nuotoliniai ryšiai
Taip atrodo veikiant dabartinėje „Veliam“ versijoje
Viena iš užduočių buvo greitai ir patogiai prisijungti prie serverių, kurių jau buvo daug (daugiau nei šimtas) ir rūšiuoti milijonus iš anksto išsaugotų KPP nuorodų buvo itin nepatogu. Reikėjo įrankio. Internete yra programinės įrangos, kuri yra kažkas panašaus į adresų knygelę tokiems KPP ryšiams, tačiau jie nėra integruoti su stebėjimo sistema, o paskyrų išsaugoti negalima. Kaskart įvesti skirtingų klientų paskyras yra grynas pragaras, kai per dieną dešimtis kartų jungiatės prie skirtingų serverių. Su SSH viskas yra šiek tiek geriau; yra daug geros programinės įrangos, kuri leidžia suskirstyti tokius ryšius į aplankus ir atsiminti paskyras iš jų. Bet yra 2 problemos. Pirma, mes neradome nė vienos programos, skirtos RDP ir SSH ryšiams. Antra, jei tam tikru momentu manęs nėra prie kompiuterio ir man reikia greitai prisijungti arba aš tiesiog iš naujo įdiegiau sistemą, turėsiu pereiti į dokumentaciją, kad peržiūrėčiau šio kliento paskyrą. Tai nepatogu ir laiko švaistymas.
Hierarchinė struktūra, kurios mums reikėjo klientų serveriams, jau buvo mūsų vidiniame produkte. Teko sugalvoti, kaip ten pritvirtinti greitas jungtis prie reikiamos įrangos. Pradedantiesiems, bent jau jūsų tinkle.
Atsižvelgiant į tai, kad klientas mūsų sistemoje buvo naršyklė, neturinti prieigos prie vietinių kompiuterio išteklių, norint tiesiog paleisti mums reikalingą programą su kokia nors komanda, buvo sugalvota viską daryti per „Windows“ tinkinta URL schema“. Taip mūsų sistemai atsirado tam tikras „įskiepis“, kuris tiesiog apėmė „Putty“ ir „Remote Desktop Plus“, o diegimo metu tiesiog užregistravo URI schemą sistemoje „Windows“. Dabar, kai norėjome prisijungti prie objekto per RDP arba SSH, spustelėjome šį veiksmą savo sistemoje ir pasirinktas URI veikė. Buvo paleista standartinė mstsc.exe, integruota sistemoje Windows arba glaistai, kuri buvo "įskiepio" dalis. Žodį įskiepiai įdedu į kabutes, nes tai nėra naršyklės įskiepis klasikine prasme.
Bent jau tai buvo kažkas. Patogi adresų knyga. Be to, „Putty“ atveju viskas buvo gerai, kaip įvesties parametrai galėjo būti nurodyti IP ryšiai, prisijungimas ir slaptažodis. Tie. Mes jau prisijungėme prie Linux serverių savo tinkle vienu paspaudimu neįvesdami slaptažodžių. Tačiau su KPP tai nėra taip paprasta. Standartinis mstsc negali pateikti kredencialų kaip parametrų. Į pagalbą atėjo Remote Desktop Plus. Jis leido tai įvykti. Dabar galime apsieiti ir be jo, bet ilgą laiką tai buvo ištikimas asistentas mūsų sistemoje. Su HTTP(S) svetainėmis viskas paprasta, tokie objektai tiesiog atsidaro naršyklėje ir viskas. Patogu ir praktiška. Bet tai buvo laimė tik vidiniame tinkle.
Kadangi didžiąją daugumą problemų sprendėme nuotoliniu būdu iš biuro, lengviausia buvo padaryti VPN prieinamus klientams. Ir tada buvo galima prie jų prisijungti iš mūsų sistemos. Bet vis tiek buvo kiek nepatogu. Kiekvienam klientui kiekviename kompiuteryje reikėjo turėti krūvą įsimintų VPN jungčių, o prieš prisijungiant prie bet kurio, reikėjo įjungti atitinkamą VPN. Šį sprendimą naudojome gana ilgai. Tačiau daugėja klientų, daugėja ir VPN, ir visa tai pradėjo mus varginti ir reikėjo kažką daryti. Ypač ašaros ištryško iš naujo įdiegus sistemą, kai teko iš naujo įvesti dešimtis VPN jungčių naujame Windows profilyje. Nustokite to taikstytis, pasakiau ir pradėjau galvoti, ką galėčiau dėl to padaryti.
Taip atsitiko, kad visi klientai kaip maršrutizatorius turėjo gerai žinomos kompanijos „Mikrotik“ įrenginius. Jie yra labai funkcionalūs ir patogūs atlikti beveik bet kokią užduotį. Neigiama yra tai, kad jie yra "užgrobti". Šią problemą išsprendėme tiesiog uždarydami visą prieigą iš išorės. Bet reikėjo kažkaip prieiti prie jų neatvykus pas klientą, nes... tai ilgas. Kiekvienam tokiam Mikrotik tiesiog padarėme tunelius ir išskyrėme į atskirą baseiną. be jokio maršruto nustatymo, kad nebūtų jūsų tinklo ryšio su klientų tinklais ir jų tinklais tarpusavyje.
Gimė idėja įsitikinti, kad paspaudus man reikiamą objektą sistemoje, centrinis stebėjimo serveris, žinodamas visų kliento Mikrotik SSH paskyras, prisijungtų prie norimos, sukurtų persiuntimo taisyklę į norimą pagrindinį kompiuterį su reikalingas uostas. Čia yra keli punktai. Sprendimas nėra universalus – jis veiks tik „Mikrotik“, nes komandų sintaksė skiriasi visiems maršrutizatoriams. Be to, tokius persiuntimus tada reikėjo kažkaip ištrinti, o mūsų sistemos serverio dalis iš esmės niekaip negalėjo atsekti, ar aš baigiau savo KPP seansą. Na, toks persiuntimas yra skylė klientui. Bet mes nesiekėme universalumo, nes... produktas buvo naudojamas tik mūsų įmonėje ir nebuvo minčių jį išleisti į viešumą.
Kiekviena iš problemų buvo išspręsta savaip. Kai buvo sukurta taisyklė, šis persiuntimas buvo galimas tik vienam konkrečiam išoriniam IP adresui (iš kurio buvo inicijuotas ryšys). Taigi saugumo skylės buvo išvengta. Bet su kiekvienu tokiu ryšiu į NAT puslapį buvo įtraukta Mikrotik taisyklė ir ji nebuvo išvalyta. Ir visi žino, kad kuo daugiau taisyklių, tuo daugiau įkeliamas maršrutizatoriaus procesorius. Ir apskritai negalėjau susitaikyti, kad vieną dieną nueisiu į kokį Mikrotiką, o ten bus šimtai mirusių, nenaudingų taisyklių.
Kadangi mūsų serveris negali sekti ryšio būsenos, leiskite Mikrotik pačiam juos sekti. Ir aš parašiau scenarijų, kuris nuolat stebėjo visas persiuntimo taisykles su konkrečiu aprašymu ir tikrino, ar TCP ryšys turi tinkamą taisyklę. Jei kurį laiką jo nebuvo, greičiausiai ryšys jau baigtas ir šį persiuntimą galima ištrinti. Viskas pavyko, scenarijus pavyko.
Beje, čia yra:
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
}
}
Tikrai buvo galima padaryti gražesnį, greitesnį ir pan., bet jis veikė, neapkrovė Mikrotik ir atliko puikų darbą. Pagaliau vienu paspaudimu galėjome prisijungti prie klientų serverių ir tinklo įrangos. Neatidarius VPN ir neįvedus slaptažodžių. Sistema tapo tikrai patogi dirbti. Sutrumpėjo aptarnavimo laikas, o visi laiką praleidome dirbdami, o ne jungdamiesi prie reikalingų objektų.
„Mikrotik“ atsarginė kopija
Sukonfigūravome visų „Mikrotik“ atsarginę kopiją į FTP. Ir apskritai viskas buvo gerai. Bet kai reikėjo gauti atsarginę kopiją, turėjote atidaryti šį FTP ir ten jo ieškoti. Turime sistemą, kurioje yra sujungti visi maršrutizatoriai, galime bendrauti su įrenginiais per SSH. Kodėl mums nepadarius taip, kad pati sistema kasdien imtų atsargines kopijas iš viso Mikrotik, pagalvojau. Ir jis pradėjo tai įgyvendinti. Prisijungėme, padarėme atsarginę kopiją ir nunešėme į saugyklą.
Scenarijaus kodas PHP, skirtas atsarginei kopijai daryti iš Mikrotik:
<?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');
?>
Atsarginė kopija daroma dviem formomis - dvejetainiu ir tekstiniu konfigūravimu. Dvejetainė padeda greitai atkurti reikiamą konfigūraciją, o tekstinis vienas leidžia suprasti, ką reikia daryti, jei yra priverstinis įrangos keitimas ir dvejetainio į jį nepavyksta įkelti. Dėl to sistemoje gavome dar vieną patogų funkcionalumą. Be to, pridedant naują Mikrotik nereikėjo nieko konfigūruoti, tiesiog pridėjau objektą prie sistemos ir per SSH nustatiau jam paskyrą. Tada atsarginių kopijų darymu pasirūpino pati sistema. Dabartinė SaaS Veliam versija dar neturi šios funkcijos, bet netrukus ją perkelsime.
Ekrano nuotraukos, kaip tai atrodė vidinėje sistemoje
Perėjimas prie įprastos duomenų bazės saugyklos
Jau rašiau aukščiau, kad atsirado artefaktų. Kartais sistemoje tiesiog dingdavo visas objektų sąrašas, kartais redaguojant objektą informacija neišsaugoma ir objektą tekdavo pervadinti tris kartus. Tai visus siaubingai suerzino. Objektų dingimas pasitaikydavo retai ir buvo nesunkiai atkuriamas atkuriant būtent šį failą, tačiau gedimų redaguojant objektus pasitaikydavo gana dažnai. Tikriausiai iš pradžių to nedariau per duomenų bazę, nes netilpo į galvą, kaip galima laikyti medį su visomis jungtimis plokščioje lentelėje. Jis plokščias, bet medis hierarchinis. Tačiau geras daugialypės prieigos ir vėliau (sistemai tampant sudėtingesnei) sandorių sprendimas yra DBVS. Tikriausiai ne aš pirmas susidūriau su šia problema. Pradėjau googlinti. Paaiškėjo, kad viskas jau buvo sugalvota prieš mane ir yra keli algoritmai, kurie stato medį iš plokščio stalo. Peržiūrėjęs kiekvieną, vieną jų įgyvendinau. Bet tai jau buvo nauja sistemos versija, nes... Tiesą sakant, dėl to man teko nemažai perrašyti. Rezultatas buvo natūralus, atsitiktinio sistemos elgesio problemos išnyko. Kai kas gali pasakyti, kad programinės įrangos kūrimo srityje klaidos yra labai mėgėjiškos (vienos gijos scenarijai, saugoma informacija, kuri vienu metu buvo pasiekta kelis kartus iš skirtingų gijų faile ir tt). Gal tai ir tiesa, bet pagrindinis mano darbas buvo administravimas, o programavimas – šalutinis sielos šurmulys, o tiesiog neturėjau patirties dirbant programuotojų komandoje, kur tokius pagrindinius dalykus man iškart būtų pasiūlęs vyresnysis. bendražygiai. Todėl visus šiuos nelygumus užpildžiau savarankiškai, bet medžiagą išmokau labai gerai. Be to, mano darbas apima susitikimus su klientais, veiksmus, kuriais siekiama reklamuoti įmonę, daugybę administracinių problemų įmonės viduje ir daug daugiau. Bet vienaip ar kitaip, tai, kas jau buvo, buvo paklausa. Aš ir vaikinai produktą naudojome kasdieniame darbe. Atvirai kalbant, buvo nesėkmingų idėjų ir sprendimų, kuriems buvo sugaištas laikas, bet galiausiai paaiškėjo, kad tai nėra darbo įrankis ir niekas jo nenaudojo ir jis neatsidūrė Veliame.
Pagalbos tarnyba – pagalbos tarnyba
Nebūtų neteisinga paminėti, kaip buvo suformuotas HelpDesk. Tai visiškai kitokia istorija, nes... Veliame tai jau 3-ioji visiškai nauja versija, kuri skiriasi nuo visų ankstesnių. Dabar tai paprasta sistema, intuityvi, be nereikalingų varpelių ir švilpukų, su galimybe integruotis su domenu, taip pat galimybe pasiekti tą patį vartotojo profilį iš bet kurios vietos naudojant nuorodą iš el. O svarbiausia – per VNC galima prisijungti prie pareiškėjo iš bet kurios vietos (namuose ar biure) tiesiai iš aplikacijos be VPN ar prievado persiuntimo. Papasakosiu, kaip mes iki to priėjome, kas nutiko anksčiau ir kokie baisūs sprendimai buvo priimti.
Su vartotojais susisiekėme per gerai žinomą „TeamViewer“. Visuose kompiuteriuose, kurių naudotojus aptarnaujame, yra įdiegta TV. Pirmas dalykas, kurį padarėme neteisingai ir vėliau jį pašalinome, buvo kiekvieno HD kliento susiejimas su aparatine įranga. Kaip vartotojas prisijungė prie HD sistemos, kad galėtų palikti užklausą? Be televizoriaus, kiekvienas į savo kompiuterius turėjo įdiegtą specialią programėlę, parašytą Lazarus (daug kas čia akis vartys, o gal net paieškos Google, kas tai yra, bet geriausia, ką aš mokėjau kompiliuota kalba buvo Delphi, o Lazarus beveik tas pats, tik nemokamai). Apskritai vartotojas paleido specialų paketinį failą, kuris paleido šią priemonę, kuri savo ruožtu nuskaito sistemos HWID, o po to buvo paleista naršyklė ir įvyko autorizacija. Kodėl tai buvo padaryta? Kai kuriose įmonėse aptarnaujamų vartotojų skaičius skaičiuojamas individualiai, o paslaugų kaina už kiekvieną mėnesį nustatoma pagal žmonių skaičių. Sakote, tai suprantama, bet kodėl tai susieta su aparatine įranga? Labai paprastai, kai kurie asmenys grįžo namo ir iš savo namų nešiojamojo kompiuterio paprašė „padaryk man čia viską gražu“. Programa ne tik nuskaito sistemos HWID, bet ir iš registro ištraukė dabartinį Teamviewer ID ir perdavė jį mums. „Teamviewer“ turi API integracijai. Ir mes padarėme šią integraciją. Bet buvo vienas laimikis. Per šias API neįmanoma prisijungti prie vartotojo kompiuterio, kai jis aiškiai neinicijuoja šios sesijos ir, pabandęs prie jos prisijungti, taip pat turi spustelėti „patvirtinti“. Tuo metu mums atrodė logiška, kad be vartotojo prašymo niekas neturėtų prisijungti, o kadangi žmogus yra prie kompiuterio, jis inicijuos seansą ir teigiamai atsakys į nuotolinio ryšio užklausą. Viskas pasirodė ne taip. Pareiškėjai pamiršo paspausti inicijuoti sesiją ir turėjo jiems tai pasakyti telefonu. Tai sugaišo laiko ir vargino abi proceso puses. Be to, visai neretai pasitaiko tokių akimirkų, kai žmogus palieka užklausą, o prisijungti leidžiama tik išėjus pietauti. Nes problema nėra kritinė ir jis nenori, kad jo darbo procesas nutrūktų. Atitinkamai jis nepaspaus jokių mygtukų, kad leistų prisijungti. Taip atsirado papildomos funkcijos prisijungus prie HelpDesk – Teamviwer ID skaitymas. Mes žinojome nuolatinį slaptažodį, kuris buvo naudojamas diegiant Teamviwer. Tiksliau, tai žinojo tik sistema, nes ji buvo įmontuota į montuotoją ir į mūsų sistemą. Atitinkamai, iš programos buvo prisijungimo mygtukas, kurį spustelėjus nereikėjo nieko laukti, tačiau Teamviewer iškart atsidarė ir ryšys įvyko. Dėl to buvo dviejų tipų galimi ryšiai. Per oficialią Teamviewer API ir mūsų pačių sukurtą. Mano nuostabai, jie beveik iš karto nustojo naudoti pirmąjį, nors buvo nurodymas jį naudoti tik ypatingais atvejais ir kai vartotojas pats duoda leidimą. Vis dėlto dabar suteik man saugumo. Tačiau paaiškėjo, kad pareiškėjams to nereikėjo. Jie visi yra visiškai gerai, kai yra prijungti prie jų be patvirtinimo mygtuko.
Perėjimas prie kelių gijų „Linux“.
Jau seniai pradėjo kilti klausimas, kaip pagreitinti tinklo skaitytuvo praėjimą, kad būtų atidarytas iš anksto nustatytas prievadų sąrašas ir paprastas tinklo objektų pingavimas. Čia, žinoma, pirmasis sprendimas, kuris ateina į galvą, yra daugiagija. Kadangi pagrindinis pingo laikas yra laukiamas, kol bus grąžintas paketas, o kitas pingas negali prasidėti tol, kol negrąžintas ankstesnis paketas, tai įmonėse, kurios turėjo net 20+ serverių ir tinklo įrangą, tai jau veikė gana lėtai. Esmė ta, kad vienas paketas gali dingti, bet ne iš karto apie tai pranešti sistemos administratoriui. Jis tiesiog labai greitai nustos priimti tokį šlamštą. Tai reiškia, kad prieš padarydami išvadą apie neprieinamumą, kiekvieną objektą turite patikrinti daugiau nei vieną kartą. Per daug nesigilinant į detales, būtina ją sulyginti, nes jei tai nebus padaryta, greičiausiai sistemos administratorius apie problemą sužinos iš kliento, o ne iš stebėjimo sistemos.
Pats PHP nepalaiko kelių gijų iš karto. Galimybė apdoroti daug kartų, galite šakutės. Bet, tiesą sakant, man jau buvo parašytas apklausos mechanizmas ir norėjau padaryti taip, kad vieną kartą suskaičiuočiau visus reikalingus mazgus iš duomenų bazės, viską iš karto pinguočiau, laukčiau kiekvieno atsakymo ir tik po to iškart rašyčiau duomenys. Taip sutaupoma skaitymo užklausų skaičius. Daugialypės sijos puikiai tinka šiai idėjai. PHP yra PThreads modulis, leidžiantis atlikti tikrą kelių gijų kūrimą, nors prireikė nemažai padirbėti, kad tai būtų nustatyta PHP 7.2 versijoje, bet tai buvo padaryta. Prievadų nuskaitymas ir ping dabar yra greiti. Ir vietoj, pavyzdžiui, 15 sekundžių per ratą anksčiau, šis procesas pradėjo užtrukti 2 sekundes. Tai buvo geras rezultatas.
Greitas naujų įmonių auditas
Kaip atsirado įvairių metrikų ir techninės įrangos charakteristikų rinkimo funkcionalumas? Tai paprasta. Kartais mums tiesiog liepiama atlikti esamos IT infrastruktūros auditą. Na, o to paties reikia norint paspartinti naujo kliento auditą. Mums reikėjo kažko, kas leistų ateiti į vidutinę ar didelę įmonę ir greitai išsiaiškinti, ką ji turi. Mano nuomone, pingą vidiniame tinkle blokuoja tik tie, kurie nori patys apsunkinti savo gyvenimą, o tokių, mūsų patirtimi, yra nedaug. Bet yra ir tokių žmonių. Atitinkamai, naudodami paprastą ping galite greitai nuskaityti tinklus, ar nėra įrenginių. Tada galime juos pridėti ir ieškoti atvirų prievadų, kurie mus domina. Tiesą sakant, ši funkcija jau egzistavo, tereikėjo pridėti komandą iš centrinio serverio prie vergo, kad jis nuskaitytų nurodytus tinklus ir įtrauktų į sąrašą viską, ką rado. Pamiršau paminėti, buvo daroma prielaida, kad jau turime paruoštą vaizdą su sukonfigūruota sistema (vergo stebėjimo serveriu), kurį audito metu galime tiesiog išjungti iš kliento ir prijungti jį prie savo debesies.
Tačiau audito rezultatas paprastai apima daugybę skirtingos informacijos, o viena iš jų yra tai, kokie įrenginiai yra tinkle. Visų pirma, mus domino „Windows“ serveriai ir „Windows“ darbo vietos kaip domeno dalis. Kadangi vidutinėse ir didelėse įmonėse domeno nebuvimas yra taisyklės išimtis. Kalbant viena kalba, vidurkis, mano nuomone, yra 100+ žmonių. Reikėjo sugalvoti, kaip rinkti duomenis iš visų Windows mašinų ir serverių, žinant jų IP ir domeno administratoriaus abonementą, bet kiekviename jų neįdiegiant jokios programinės įrangos. Į pagalbą ateina WMI sąsaja. „Windows Management Instrumentation“ (WMI) pažodžiui reiškia „Windows“ valdymo įrankius. WMI yra viena iš pagrindinių technologijų, skirtų centralizuotai valdyti ir stebėti įvairių kompiuterių infrastruktūros dalių, kuriose veikia Windows platforma, veikimą. Paimta iš wiki. Tada turėjau dar kartą padirbėti, kad galėčiau kompiliuoti wmic (tai yra WMI klientas) Debian'ui. Kai viskas buvo paruošta, beliko tiesiog per wmic surinkti reikiamus mazgus, kad gautumėte reikiamą informaciją. Per WMI galite gauti beveik bet kokią informaciją iš „Windows“ kompiuterio, be to, per jį taip pat galite valdyti kompiuterį, pavyzdžiui, siųsti jį perkrauti. Taip atsirado informacijos apie Windows stotis ir serverius mūsų sistemoje rinkinys. Be to, buvo naujausia informacija apie esamus sistemos apkrovos indikatorius. Jų prašome dažniau, o informacijos apie techninę įrangą – rečiau. Po to auditas tapo šiek tiek malonesnis.
Programinės įrangos platinimo sprendimas
Mes patys naudojame sistemą kasdien, ji visada atvira kiekvienam techniniam darbuotojui. Ir pagalvojome, kad galime pasidalinti su kitais tuo, ką jau turime. Sistema dar nebuvo paruošta platinti. Daug ką teko perdirbti, kad vietinė versija virstų SaaS. Tai apima įvairių techninių sistemos aspektų (nuotolinių jungčių, palaikymo paslaugų) pakeitimus, licencijavimo modulių analizę, klientų duomenų bazių dalijimąsi, kiekvienos paslaugos mastelio keitimą ir visų dalių automatinio atnaujinimo sistemų kūrimą. Bet tai bus antroji straipsnio dalis.
Atnaujinti
Šaltinis: www.habr.com