Kumusta sa lahat, ang pangalan ko ay Sergey Emelyanchik. Ako ang pinuno ng kumpanya ng Audit-Telecom, ang pangunahing developer at may-akda ng sistema ng Veliam. Nagpasya akong magsulat ng isang artikulo tungkol sa kung paano kami ng aking kaibigan ay lumikha ng isang outsourcing na kumpanya, nagsulat ng software para sa aming sarili at pagkatapos ay nagsimulang ipamahagi ito sa lahat sa pamamagitan ng SaaS system. Tungkol sa kung paano ako tiyak na hindi naniniwala na posible ito. Ang artikulo ay naglalaman ng hindi lamang isang kuwento, kundi pati na rin ang mga teknikal na detalye kung paano nilikha ang produkto ng Veliam. Kasama ang ilang piraso ng source code. Sasabihin ko sa iyo kung anong mga pagkakamali ang nagawa namin at kung paano namin itinatama ang mga ito sa ibang pagkakataon. May mga pagdududa kung maglalathala ng naturang artikulo. Ngunit naisip ko na ito ay mas mahusay na gawin ito, makakuha ng feedback at pagbutihin, kaysa sa hindi i-publish ang artikulo at isipin kung ano ang maaaring mangyari kung...
prehistory
Nagtrabaho ako sa isang kumpanya bilang isang empleyado ng IT. Ang kumpanya ay medyo malaki na may malawak na istraktura ng network. Hindi ako magtatagal sa aking mga responsibilidad sa trabaho, sasabihin ko lang na tiyak na hindi nila kasama ang pag-unlad ng anuman.
Nagkaroon kami ng monitoring, ngunit dahil lamang sa akademikong interes gusto kong subukang magsulat ng sarili kong pinakasimpleng isa. Ang ideya ay ito: Gusto kong nasa web ito, upang madali akong makapasok nang hindi nag-i-install ng anumang mga kliyente at makita kung ano ang nangyayari sa network mula sa anumang device, kabilang ang isang mobile device sa pamamagitan ng Wi-Fi, at ako rin talaga gustong mabilis na maunawaan kung ano May kagamitan sa silid na naging “mopey” dahil... mayroong napakahigpit na mga kinakailangan para sa oras ng pagtugon sa mga naturang problema. Bilang resulta, nabuo sa isip ko ang isang plano na magsulat ng isang simpleng web page kung saan mayroong jpeg background na may network diagram, gupitin ang mga device mismo kasama ang kanilang mga IP address sa larawang ito, at ipakita ang dynamic na nilalaman sa ibabaw ng larawan sa kinakailangang mga coordinate sa anyo ng berde o kumikislap na pulang IP address. Naitakda na ang gawain, magsimula na tayo.
Dati, nagprograma ako sa Delphi, PHP, JS at napakababaw ng C++. Alam ko na kung paano gumagana ang mga network. VLAN, Pagruruta (OSPF, EIGRP, BGP), NAT. Ito ay sapat na para sa akin na magsulat ng isang primitive monitoring prototype sa aking sarili.
Isinulat ko ang aking binalak sa PHP. Ang Apache at PHP server ay nasa Windows dahil... Ang Linux para sa akin sa sandaling iyon ay isang bagay na hindi maintindihan at napakakumplikado, dahil sa paglaon, ako ay lubos na nagkakamali at sa maraming lugar ang Linux ay mas simple kaysa sa Windows, ngunit ito ay isang hiwalay na paksa at alam nating lahat kung gaano karaming mga holivar ang mayroon sa ang paksang ito. Ang Windows task scheduler ay humila sa isang maliit na agwat (hindi ko matandaan nang eksakto, ngunit isang bagay tulad ng isang beses bawat tatlong segundo) isang PHP script na polled lahat ng mga bagay na may isang banal na ping at nai-save ang estado sa isang file.
system(“ping -n 3 -w 100 {$ip_address}“);
Oo, oo, ang pagtatrabaho sa isang database sa sandaling iyon ay hindi rin pinagkadalubhasaan para sa akin. Hindi ko alam na posibleng i-parallelize ang mga proseso, at ang pagdaan sa lahat ng node ng network ay tumagal ng mahabang panahon, dahil... nangyari ito sa isang thread. Ang mga problema ay lalo na lumitaw kapag ang ilang mga node ay hindi magagamit, dahil bawat isa sa kanila ay naantala ang script ng 300 ms. Sa panig ng kliyente mayroong isang simpleng pag-loop na function na, sa pagitan ng ilang segundo, na-download ang na-update na impormasyon mula sa server na may kahilingan ng Ajax at na-update ang interface. Kung gayon, pagkatapos ng 3 sunud-sunod na hindi matagumpay na pag-ping, kung ang isang web page na may pagsubaybay ay nakabukas sa computer, isang masayang komposisyon ang naglaro.
Nang maayos ang lahat, sobrang na-inspire ako sa resulta at naisip kong madadagdagan pa ito (dahil sa aking kaalaman at kakayahan). Ngunit palagi kong hindi gusto ang mga system na may isang milyong mga tsart, na naisip ko noon, at iniisip pa rin hanggang ngayon, ay hindi kailangan sa karamihan ng mga kaso. Nais kong ilagay doon lamang kung ano ang talagang makakatulong sa akin sa aking trabaho. Ang prinsipyong ito ay nananatiling saligan sa pag-unlad ng Veliam hanggang sa araw na ito. Dagdag pa, napagtanto ko na magiging napaka-cool kung hindi ko kailangang panatilihing bukas ang pagsubaybay at malaman ang tungkol sa mga problema, at kapag nangyari ito, pagkatapos ay buksan ang pahina at tingnan kung saan matatagpuan ang problemang network node na ito at kung ano ang susunod na gagawin dito. . Kahit papaano hindi ako nagbabasa ng email noon, hindi ko lang ito ginamit. Nakita ko sa Internet na may mga SMS gateway kung saan maaari kang magpadala ng kahilingan sa GET o POST, at magpapadala sila ng SMS sa aking mobile phone kasama ang text na sinusulat ko. Napagtanto ko kaagad na gusto ko talaga ito. At sinimulan kong pag-aralan ang dokumentasyon. Pagkaraan ng ilang oras nagtagumpay ako, at ngayon nakatanggap ako ng isang SMS tungkol sa mga problema sa network sa aking mobile phone na may pangalan ng isang "nahulog na bagay". Bagaman ang sistema ay primitive, ako mismo ang sumulat nito, at ang pinakamahalagang bagay na nag-udyok sa akin na bumuo nito ay ito ay isang application program na talagang nakatulong sa akin sa aking trabaho.
At pagkatapos ay dumating ang araw na ang isa sa mga channel sa Internet ay nawala sa trabaho, at ang aking pagsubaybay ay hindi ipinaalam sa akin ang tungkol dito. Dahil ang Google DNS ay naka-ping pa rin nang perpekto. Oras na para isipin kung paano mo masusubaybayan na buhay ang channel ng komunikasyon. Nagkaroon ng iba't ibang ideya kung paano ito gagawin. Wala akong access sa lahat ng kagamitan. Kinailangan naming malaman kung paano mauunawaan kung alin sa mga channel ang live, ngunit nang hindi matingnan ito kahit papaano sa mismong kagamitan ng network. Pagkatapos ay nagkaroon ng ideya ang isang kasamahan na posibleng mag-iba ang pagsubaybay sa ruta sa mga pampublikong server depende sa kung aling channel ng komunikasyon ang kasalukuyang ginagamit upang ma-access ang Internet. I checked and it turned out that way. Mayroong iba't ibang mga ruta kapag sumusubaybay.
system(“tracert -d -w 500 8.8.8.8”);
Kaya lumitaw ang isa pang script, o sa halip, para sa ilang kadahilanan ay idinagdag ang bakas sa dulo ng parehong script, na nag-ping sa lahat ng mga device sa network. Pagkatapos ng lahat, ito ay isa pang mahabang proseso na naisakatuparan sa parehong thread at pinabagal ang gawain ng buong script. Ngunit pagkatapos ay hindi masyadong halata. Ngunit sa isang paraan o iba pa, ginawa niya ang kanyang trabaho, ang code ay mahigpit na tinukoy kung anong uri ng pagsubaybay ang dapat para sa bawat isa sa mga channel. Ito ay kung paano nagsimulang gumana ang system, na sinusubaybayan na (malakas na sinabi, dahil walang koleksyon ng anumang mga sukatan, ngunit ping lang) mga device sa network (router, switch, wi-fi, atbp.) at mga channel ng komunikasyon sa labas ng mundo . Regular na dumating ang mga mensaheng SMS at palaging malinaw na ipinapakita ng diagram kung saan ang problema.
Dagdag pa, sa pang-araw-araw na trabaho kailangan kong gumawa ng cross-crossing. At napagod ako sa pagpunta sa Cisco switch sa bawat oras upang makita kung aling interface ang gagamitin. Napakahusay na mag-click sa isang bagay sa pagsubaybay at makita ang isang listahan ng mga interface nito na may mga paglalarawan. Makakatipid ako ng oras. Bukod dito, sa pamamaraang ito ay hindi na kailangang patakbuhin ang Putty o SecureCRT upang magpasok ng mga account at command. Nag-click lang ako sa pagsubaybay, nakita kung ano ang kailangan at ginawa ang aking trabaho. Nagsimula akong maghanap ng mga paraan upang makipag-ugnayan sa mga switch. Agad akong nakatagpo ng 2 pagpipilian: SNMP o pag-log in sa switch sa pamamagitan ng SSH, pagpasok ng mga utos na kailangan ko at pag-parse ng resulta. Ibinasura ko ang SNMP dahil sa pagiging kumplikado ng pagpapatupad nito; naiinip akong makuha ang resulta. gamit ang SNMP, kailangan mong maghukay sa MIB nang mahabang panahon at, batay sa data na ito, bumuo ng data tungkol sa mga interface. May napakagandang team sa CISCO
show interface statusIto ay eksaktong nagpapakita kung ano ang kailangan ko para sa cross-crossings. Bakit mag-abala sa SNMP kung gusto ko lang makita ang output ng command na ito, naisip ko. Pagkaraan ng ilang oras, napagtanto ko ang pagkakataong ito. Nag-click sa isang bagay sa isang web page. Na-trigger ang isang kaganapan kung saan nakipag-ugnayan ang kliyente ng AJAX sa server, at ito naman, ay nakakonekta sa pamamagitan ng SSH sa switch na kailangan ko (ang mga kredensyal ay na-hardcode sa code, walang pagnanais na pinuhin ito, upang gumawa ng ilang hiwalay na mga menu kung saan posible na baguhin ang mga account mula sa interface , kailangan ko ang resulta at mabilis) Ipinasok ko ang utos sa itaas doon at ipinadala ito pabalik sa browser. Kaya nagsimula akong makakita ng impormasyon sa mga interface sa isang pag-click ng mouse. Ito ay lubos na maginhawa, lalo na kapag kailangan mong tingnan ang impormasyong ito sa iba't ibang mga switch nang sabay-sabay.
Ang pagsubaybay sa channel na nakabatay sa bakas ay hindi naging pinakamahusay na ideya, dahil... minsan ang trabaho ay isinasagawa sa network, at ang pagsubaybay ay maaaring magbago at ang pagsubaybay ay nagsimulang sumigaw sa akin na may mga problema sa channel. Ngunit pagkatapos gumugol ng maraming oras sa pagsusuri, napagtanto ko na gumagana ang lahat ng mga channel, at nililinlang ako ng aking pagsubaybay. Bilang resulta, hiniling ko sa aking mga kasamahan na namamahala sa mga switch na bumubuo ng channel na magpadala lang sa akin ng syslog kapag nagbago ang visibility status ng mga kapitbahay. Alinsunod dito, ito ay mas simple, mas mabilis at mas tumpak kaysa sa pagsubaybay. Dumating ang isang kaganapan tulad ng pagkawala ng kapitbahay, at agad akong naglabas ng notification tungkol sa channel down.
Dagdag pa, lumitaw ang ilang higit pang mga utos kapag nag-click sa isang bagay, at idinagdag ang SNMP upang mangolekta ng ilang sukatan, at iyon talaga. Ang sistema ay hindi na binuo pa. Ginawa nito ang lahat ng kailangan ko, ito ay isang mahusay na tool. Maraming mga mambabasa ang malamang na magsasabi sa akin na mayroon nang maraming software sa Internet upang malutas ang mga problemang ito. Ngunit sa katunayan, hindi ako nag-google ng mga ganitong libreng produkto noon at talagang gusto kong paunlarin ang aking mga kasanayan sa programming, at kung ano ang mas mahusay na paraan upang itulak ito kaysa sa isang tunay na problema sa aplikasyon. Sa puntong ito, ang unang bersyon ng pagsubaybay ay nakumpleto at hindi na binago.
Paglikha ng kumpanya ng Audit-Telecom
Sa paglipas ng panahon, nagsimula akong magtrabaho ng part-time sa ibang mga kumpanya, buti na lang at pinayagan ako ng schedule ng trabaho ko na gawin ito. Kapag nagtatrabaho ka sa iba't ibang kumpanya, ang iyong mga kasanayan sa iba't ibang mga lugar ay lumalaki nang napakabilis, at ang iyong mga abot-tanaw ay umuunlad nang maayos. May mga kumpanya kung saan, gaya ng sinasabi nila, ikaw ay isang Swede, isang reaper, at isang trumpeta player. Sa isang banda, mahirap, sa kabilang banda, kung hindi ka tamad, magiging generalist ka at ito ay nagbibigay-daan sa iyo upang malutas ang mga problema nang mas mabilis at mas mahusay dahil alam mo kung paano gumagana ang kaugnay na larangan.
Ang aking kaibigan na si Pavel (isa ring espesyalista sa IT) ay patuloy na sinubukan akong hikayatin na magsimula ng kanyang sariling negosyo. Mayroong hindi mabilang na mga ideya na may iba't ibang mga pagkakaiba-iba ng kanilang ginagawa. Ito ay tinalakay sa loob ng maraming taon. At sa huli, hindi ito dapat dumating sa anumang bagay dahil ako ay isang may pag-aalinlangan, at si Pavel ay isang mapangarapin. Sa tuwing nagmumungkahi siya ng isang ideya, palagi akong hindi naniniwala dito at tumangging lumahok. Pero gusto talaga naming magbukas ng sarili naming negosyo.
Sa wakas, nakahanap kami ng opsyon na angkop sa aming dalawa at gawin ang alam namin kung paano gawin. Noong 2016, nagpasya kaming lumikha ng isang kumpanya ng IT na makakatulong sa mga negosyo na malutas ang mga problema sa IT. Ito ang deployment ng mga IT system (1C, terminal server, mail server, atbp.), ang kanilang maintenance, classic HelpDesk para sa mga user at network administration.
Sa totoo lang, sa oras ng paglikha ng kumpanya, hindi ako naniniwala dito tungkol sa 99,9%. Ngunit kahit papaano ay nakuha ako ni Pavel na subukan, at sa pagtingin sa unahan, siya ay naging tama. Kami ni Pavel ay nakakuha ng 300 rubles bawat isa, nagrehistro ng isang bagong LLC na "Audit-Telecom", nagrenta ng isang maliit na opisina, gumawa ng mga cool na business card, well, sa pangkalahatan, tulad ng malamang na karamihan sa mga walang karanasan, mga baguhang negosyante, at nagsimulang maghanap ng mga kliyente. Ang paghahanap ng mga kliyente ay isang ganap na naiibang kuwento. Marahil ay magsusulat kami ng isang hiwalay na artikulo bilang bahagi ng corporate blog kung sinuman ang interesado. Malamig na tawag, flyer, atbp. Hindi ito nagbigay ng anumang resulta. Habang nagbabasa ako ngayon mula sa maraming kwento tungkol sa negosyo, sa isang paraan o iba pa, marami ang nakasalalay sa suwerte. Kami ay mapalad. at literal na ilang linggo pagkatapos ng paglikha ng kumpanya, nilapitan kami ng aking kapatid na si Vladimir, na nagdala sa amin ng aming unang kliyente. Hindi ako magsasawa sa mga detalye ng pakikipagtulungan sa mga kliyente, hindi iyon ang tungkol sa artikulo, sasabihin ko lang na nagpunta kami para sa isang audit, natukoy ang mga kritikal na lugar at ang mga lugar na ito ay nasira habang ang desisyon ay ginawa kung makipagtulungan sa amin sa patuloy na batayan bilang mga outsourcer. Pagkatapos nito, isang positibong desisyon ang ginawa kaagad.
Pagkatapos, higit sa lahat sa pamamagitan ng salita ng bibig sa pamamagitan ng mga kaibigan, ang iba pang mga kumpanya ng serbisyo ay nagsimulang lumitaw. Nasa isang sistema ang helpdesk. Ang mga koneksyon sa network equipment at server ay iba, o sa halip ay iba. Ang ilang mga tao ay nag-save ng mga shortcut, ang iba ay gumamit ng RDP address book. Ang pagsubaybay ay isa pang hiwalay na sistema. Napakahirap para sa isang pangkat na magtrabaho sa magkakaibang sistema. Ang mahahalagang impormasyon ay nawawala sa paningin. Halimbawa, naging hindi available ang terminal server ng kliyente. Ang mga aplikasyon mula sa mga gumagamit ng kliyenteng ito ay agad na natatanggap. Ang espesyalista sa suporta ay nagbubukas ng isang kahilingan (natanggap ito sa pamamagitan ng telepono). Kung ang mga insidente at kahilingan ay nakarehistro sa isang system, pagkatapos ay makikita kaagad ng espesyalista sa suporta kung ano ang problema ng gumagamit at sasabihin sa kanya ang tungkol dito, habang sabay na kumokonekta sa kinakailangang bagay upang ayusin ang sitwasyon. Alam ng lahat ang taktikal na sitwasyon at gumagana nang maayos. Wala kaming nakitang sistema kung saan pinagsama ang lahat ng ito. Naging malinaw na oras na para gumawa ng sarili nating produkto.
Patuloy na trabaho sa iyong monitoring system
Malinaw na ang sistema na isinulat kanina ay ganap na hindi angkop para sa kasalukuyang mga gawain. Ni sa mga tuntunin ng pag-andar o sa mga tuntunin ng kalidad. At napagpasyahan na isulat ang sistema mula sa simula. Graphically ito ay dapat na tumingin ganap na naiiba. Ito ay dapat na isang hierarchical system upang maging posible na mabilis at maginhawang buksan ang tamang bagay para sa tamang kliyente. Ang pamamaraan tulad ng sa unang bersyon ay ganap na hindi nabigyang-katwiran sa kasalukuyang kaso, dahil Magkaiba ang mga kliyente at hindi mahalaga kung saang lugar matatagpuan ang kagamitan. Nailipat na ito sa dokumentasyon.
Kaya, ang mga gawain:
- Hierarchical na istraktura;
- Ilang uri ng bahagi ng server na maaaring ilagay sa lugar ng kliyente sa anyo ng isang virtual machine upang kolektahin ang mga sukatan na kailangan namin at ipadala ito sa gitnang server, na magbubuod sa lahat ng ito at ipakita ito sa amin;
- Mga alerto. Ang mga hindi maaaring palampasin, dahil... sa oras na iyon ay hindi posible para sa isang tao na umupo at tumingin lamang sa monitor;
- Sistema ng aplikasyon. Nagsimulang lumitaw ang mga kliyente kung saan kami nagseserbisyo hindi lamang sa mga kagamitan sa server at network, kundi pati na rin sa mga workstation;
- Kakayahang mabilis na kumonekta sa mga server at kagamitan mula sa system;
Ang mga gawain ay naitakda na, nagsisimula kaming magsulat. Kasabay nito, pinoproseso ang mga kahilingan mula sa mga kliyente. At that time, 4 na kami. Sinimulan naming isulat ang parehong bahagi nang sabay-sabay: ang gitnang server at ang server para sa pag-install sa mga kliyente. Sa puntong ito, ang Linux ay hindi na estranghero sa amin at napagpasyahan na ang mga virtual machine na magkakaroon ng mga kliyente ay nasa Debian. Hindi magkakaroon ng mga installer, gagawa lang kami ng proyekto ng bahagi ng server sa isang partikular na virtual machine, at pagkatapos ay i-clone lang namin ito sa gustong kliyente. Ito ay isa pang pagkakamali. Nang maglaon ay naging malinaw na sa gayong pamamaraan ang mekanismo ng pag-update ay ganap na hindi nabuo. Yung. nagdaragdag kami ng ilang bagong feature, at pagkatapos ay nagkaroon ng buong problema sa pamamahagi nito sa lahat ng client server, ngunit babalikan namin ito mamaya, ang lahat ay maayos.
Ginawa namin ang unang prototype. Nagawa niyang i-ping ang mga device at server ng network ng kliyente na kailangan namin at ipadala ang data na ito sa aming central server. At siya naman, na-update ang data na ito nang maramihan sa gitnang server. Dito ay magsusulat ako hindi lamang ng isang kuwento tungkol sa kung paano at kung ano ang matagumpay, kundi pati na rin kung anong mga pagkakamali ang nagawa at kung paano ko kinailangan itong bayaran sa paglipas ng panahon. Kaya, ang buong puno ng mga bagay ay naka-imbak sa isang solong file sa anyo ng isang serialized na bagay. Habang ikinonekta namin ang ilang mga kliyente sa system, ang lahat ay higit pa o hindi gaanong normal, bagaman kung minsan ay may ilang mga artifact na ganap na hindi maintindihan. Ngunit nang ikonekta namin ang isang dosenang mga server sa system, nagsimulang mangyari ang mga himala. Minsan, para sa ilang hindi kilalang dahilan, ang lahat ng mga bagay sa system ay nawala lamang. Mahalagang tandaan dito na ang mga server na ipinadala ng mga kliyente ng data sa gitnang server bawat ilang segundo sa pamamagitan ng isang kahilingan sa POST. Nahulaan na ng isang matulungin na mambabasa at isang bihasang programmer na mayroong problema sa maramihang pag-access sa mismong file kung saan naka-imbak ang serialized na bagay mula sa iba't ibang mga thread nang sabay-sabay. At nang mangyari ito, nangyari ang mga himala sa pagkawala ng mga bagay. Ang file ay naging walang laman. Ngunit ang lahat ng ito ay hindi natuklasan kaagad, ngunit sa panahon lamang ng operasyon na may maraming mga server. Sa panahong ito, idinagdag ang pag-andar ng pag-scan ng port (ang mga server na ipinadala sa gitna hindi lamang ang impormasyon tungkol sa pagkakaroon ng mga device, kundi pati na rin ang tungkol sa mga port na nakabukas sa kanila). Ginawa ito sa pamamagitan ng pagtawag sa utos:
$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);
ang mga resulta ay madalas na hindi tama at ang mga pag-scan ay tumagal ng mahabang panahon upang makumpleto. Nakalimutan ko ang tungkol sa ping, ginawa ito sa pamamagitan ng fping:
system("fping -r 3 -t 100 {$this->ip}");
Hindi rin ito parallelized at samakatuwid ang proseso ay napakahaba. Nang maglaon, ang buong listahan ng mga IP address na kinakailangan para sa pag-verify ay ipinadala sa fping nang sabay-sabay, at pabalik ay nakatanggap kami ng isang handa na listahan ng mga tumugon. Hindi tulad sa amin, nagawang i-parallelize ng fping ang mga proseso.
Ang isa pang karaniwang gawain ay ang pagse-set up ng ilang mga serbisyo sa pamamagitan ng WEB. Well, halimbawa, ECP mula sa MS Exchange. Talaga ito ay isang link lamang. At napagpasyahan namin na kailangan naming maidagdag ang mga naturang link nang direkta sa system, upang hindi na tumingin sa dokumentasyon o sa ibang lugar sa mga bookmark para sa kung paano i-access ang ECP ng isang partikular na kliyente. Ito ay kung paano lumitaw ang konsepto ng mga link ng mapagkukunan para sa system, ang kanilang pag-andar ay magagamit hanggang sa araw na ito at hindi nagbago, mabuti, halos.
Paano gumagana ang mga link ng mapagkukunan sa Veliam
Mga malalayong koneksyon
Ito ang hitsura nito sa aksyon sa kasalukuyang bersyon ng Veliam
Ang isa sa mga gawain ay ang mabilis at maginhawang kumonekta sa mga server, kung saan mayroon nang marami (higit sa isang daan) at ang pag-uuri sa milyun-milyong pre-save na mga shortcut ng RDP ay lubhang hindi maginhawa. Isang kasangkapan ang kailangan. Mayroong software sa Internet na parang isang address book para sa mga naturang koneksyon sa RDP, ngunit hindi sila isinama sa sistema ng pagsubaybay, at hindi mai-save ang mga account. Ang pagpasok ng mga account para sa iba't ibang mga kliyente sa bawat oras ay purong impiyerno kapag kumonekta ka ng dose-dosenang beses sa isang araw sa iba't ibang mga server. Sa SSH, ang mga bagay ay medyo mas mahusay; mayroong maraming mahusay na software na nagbibigay-daan sa iyo upang ayusin ang mga naturang koneksyon sa mga folder at tandaan ang mga account mula sa kanila. Ngunit mayroong 2 problema. Ang una ay wala kaming nakitang isang programa para sa RDP at SSH na mga koneksyon. Ang pangalawa ay kung sa isang punto ay wala ako sa aking computer at kailangan kong mabilis na kumonekta, o muling na-install ko ang system, kailangan kong pumunta sa dokumentasyon upang tingnan ang account mula sa kliyenteng ito. Ito ay hindi maginhawa at isang pag-aaksaya ng oras.
Ang hierarchical na istraktura na kailangan namin para sa mga client server ay magagamit na sa aming panloob na produkto. Kailangan ko lang malaman kung paano mag-attach ng mabilis na mga koneksyon sa mga kinakailangang kagamitan doon. Para sa mga nagsisimula, hindi bababa sa loob ng iyong network.
Isinasaalang-alang ang katotohanan na ang kliyente sa aming system ay isang browser na walang access sa mga lokal na mapagkukunan ng computer, upang mailunsad lamang ang application na kailangan namin gamit ang ilang utos, ito ay naimbento upang gawin ang lahat sa pamamagitan ng "Windows pasadyang url scheme". Ito ay kung paano lumitaw ang isang partikular na "plugin" para sa aming system, na isinama lang ang Putty at Remote Desktop Plus at, sa panahon ng pag-install, nirehistro lang ang URI scheme sa Windows. Ngayon, kapag gusto naming kumonekta sa isang bagay sa pamamagitan ng RDP o SSH, na-click namin ang pagkilos na ito sa aming system at gumana ang Custom na URI. Ang karaniwang mstsc.exe na binuo sa Windows o putty, na bahagi ng "plugin," ay inilunsad. Inilagay ko ang salitang plugin sa mga quote dahil hindi ito isang browser plugin sa klasikal na kahulugan.
Hindi bababa sa iyon ay isang bagay. Maginhawang address book. Bukod dito, sa kaso ng Putty, ang lahat ay karaniwang maayos; maaari itong bigyan ng mga koneksyon sa IP, pag-login at password bilang mga parameter ng input. Yung. Nakakonekta na kami sa mga server ng Linux sa aming network sa isang pag-click nang hindi naglalagay ng mga password. Ngunit sa RDP hindi ito ganoon kasimple. Ang karaniwang mstsc ay hindi makakapagbigay ng mga kredensyal bilang mga parameter. Ang Remote Desktop Plus ay sumagip. Hinayaan niyang mangyari ito. Ngayon ay magagawa natin nang wala ito, ngunit sa loob ng mahabang panahon ito ay isang tapat na katulong sa aming sistema. Sa HTTP(S) na mga site ang lahat ay simple, ang mga naturang bagay ay binuksan lamang sa browser at iyon na. Maginhawa at praktikal. Ngunit ito ay kaligayahan lamang sa panloob na network.
Dahil nalutas namin ang karamihan sa mga problema nang malayuan mula sa opisina, ang pinakamadaling bagay ay gawing available ang mga VPN sa mga kliyente. At pagkatapos ay posible na kumonekta sa kanila mula sa aming system. Ngunit ito ay medyo hindi komportable. Para sa bawat kliyente, kinakailangan na panatilihin ang isang bungkos ng mga naaalalang koneksyon sa VPN sa bawat computer, at bago kumonekta sa alinman, kinakailangan upang paganahin ang kaukulang VPN. Ginamit namin ang solusyon na ito sa loob ng mahabang panahon. Ngunit ang bilang ng mga kliyente ay tumataas, ang bilang ng mga VPN ay tumataas din, at ang lahat ng ito ay nagsimulang maghirap at may kailangang gawin tungkol dito. Lalo na ang mga luha sa aking mga mata pagkatapos muling i-install ang system, nang kailangan kong muling ipasok ang dose-dosenang mga koneksyon sa VPN sa isang bagong profile sa Windows. Itigil ang pagtitiis dito, sabi ko, at nagsimulang mag-isip tungkol sa kung ano ang maaari kong gawin tungkol dito.
Ito ay nangyari na ang lahat ng mga kliyente ay may mga aparato mula sa kilalang kumpanya na Mikrotik bilang mga router. Ang mga ito ay napaka-functional at maginhawa para sa pagsasagawa ng halos anumang gawain. Ang downside ay "na-hijack" sila. Nalutas namin ang problemang ito sa pamamagitan lamang ng pagsasara ng lahat ng access mula sa labas. Ngunit kinakailangan na kahit papaano ay magkaroon ng access sa kanila nang hindi pumupunta sa lugar ng kliyente, dahil... ito ay mahaba. Gumawa lang kami ng mga tunnel para sa bawat naturang Mikrotik at pinaghiwalay ang mga ito sa isang hiwalay na pool. nang walang anumang pagruruta, upang walang koneksyon ng iyong network sa mga network ng mga kliyente at sa kanilang mga network sa isa't isa.
Ang ideya ay ipinanganak upang matiyak na kapag nag-click ako sa bagay na kailangan ko sa system, ang sentral na server ng pagsubaybay, alam ang mga SSH account ng lahat ng kliyente na Mikrotik, kumokonekta sa nais, lumilikha ng isang patakaran sa pagpapasa sa nais na host na may kinakailangang port. Mayroong ilang mga punto dito. Ang solusyon ay hindi pangkalahatan - ito ay gagana lamang para sa Mikrotik, dahil ang command syntax ay iba para sa lahat ng mga router. Gayundin, ang mga naturang pagpapasa ay kailangang matanggal kahit papaano, at ang bahagi ng server ng aming system ay hindi talaga masusubaybayan sa anumang paraan kung natapos ko na ang aking RDP session. Well, ang ganitong pagpapasa ay isang butas para sa kliyente. Ngunit hindi namin itinuloy ang pagiging pangkalahatan, dahil... ang produkto ay ginamit lamang sa loob ng aming kumpanya at walang naisip na ilabas ito sa publiko.
Ang bawat isa sa mga problema ay nalutas sa sarili nitong paraan. Noong ginawa ang panuntunan, available lang ang pagpapasahang ito para sa isang partikular na panlabas na IP address (kung saan nasimulan ang koneksyon). Kaya't naiwasan ang isang butas sa seguridad. Ngunit sa bawat ganitong koneksyon, isang panuntunan ng Mikrotik ang idinagdag sa pahina ng NAT at hindi na-clear. At alam ng lahat na kung mas maraming mga panuntunan ang mayroon, mas maraming na-load ang processor ng router. At sa pangkalahatan, hindi ko matanggap na isang araw ay pupunta ako sa ilang Mikrotik, at magkakaroon ng daan-daang patay, walang silbi na mga patakaran.
Dahil hindi masusubaybayan ng aming server ang status ng koneksyon, hayaan ang Mikrotik na subaybayan ang mga ito mismo. At sumulat ako ng isang script na patuloy na sinusubaybayan ang lahat ng mga patakaran sa pagpapasa na may isang tiyak na paglalarawan at sinuri kung ang koneksyon ng TCP ay may angkop na panuntunan. Kung wala nang isa para sa ilang oras, malamang na ang koneksyon ay nakumpleto na at ang pagpapasahang ito ay maaaring tanggalin. Lahat ay gumana, ang script ay gumana nang maayos.
Sa pamamagitan ng paraan, narito ito:
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
}
}
Tiyak na maaari itong gawing mas maganda, mas mabilis, atbp., ngunit ito ay gumana, hindi nag-load ng Mikrotik at gumawa ng isang mahusay na trabaho. Sa wakas ay nakakonekta kami sa mga server ng kliyente at kagamitan sa network sa isang click lang. Nang hindi nagbukas ng VPN o naglalagay ng mga password. Ang sistema ay naging talagang maginhawa upang gumana sa. Ang oras ng serbisyo ay nabawasan, at lahat kami ay gumugol ng oras sa pagtatrabaho kaysa sa pagkonekta sa mga kinakailangang bagay.
Backup ng Mikrotik
Na-configure namin ang backup ng lahat ng Mikrotik sa FTP. At sa pangkalahatan ay maayos ang lahat. Ngunit kapag kailangan mong makakuha ng backup, kailangan mong buksan ang FTP na ito at hanapin ito doon. Mayroon kaming sistema kung saan nakakonekta ang lahat ng router; maaari kaming makipag-ugnayan sa mga device sa pamamagitan ng SSH. Bakit hindi natin gawin ito upang ang system mismo ay kumukuha ng mga backup mula sa lahat ng Mikrotik araw-araw, naisip ko. At sinimulan niyang ipatupad ito. Kumonekta kami, gumawa ng backup at dinala ito sa storage.
Script code sa PHP para sa pagkuha ng backup mula sa 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');
?>
Ang backup ay kinuha sa dalawang anyo - binary at text config. Ang binary ay tumutulong upang mabilis na maibalik ang kinakailangang config, at ang teksto ay nagbibigay-daan sa iyo upang maunawaan kung ano ang kailangang gawin kung mayroong sapilitang pagpapalit ng kagamitan at ang binary ay hindi mai-upload dito. Bilang resulta, nakakuha kami ng isa pang maginhawang pag-andar sa system. Bukod dito, kapag nagdaragdag ng bagong Mikrotik, hindi na kailangang i-configure ang anuman; idinagdag ko lang ang bagay sa system at nagtakda ng isang account para dito sa pamamagitan ng SSH. Pagkatapos ang system mismo ang nag-asikaso sa pagkuha ng mga backup. Ang kasalukuyang bersyon ng SaaS Veliam ay wala pang ganitong functionality, ngunit ipo-port namin ito sa lalong madaling panahon.
Mga screenshot ng kung ano ang hitsura nito sa internal system
Paglipat sa normal na imbakan ng database
Naisulat ko na sa itaas na lumitaw ang mga artifact. Minsan ang buong listahan ng mga bagay sa system ay nawala lang, minsan kapag nag-e-edit ng isang bagay, ang impormasyon ay hindi nai-save at ang bagay ay kailangang palitan ang pangalan ng tatlong beses. Ito ay labis na ikinairita ng lahat. Ang pagkawala ng mga bagay ay bihirang nangyari, at madaling naibalik sa pamamagitan ng pagpapanumbalik ng mismong file na ito, ngunit ang mga pagkabigo kapag ang pag-edit ng mga bagay ay madalas na nangyari. Marahil, sa una ay hindi ko ito ginawa sa pamamagitan ng database dahil hindi ito akma sa aking isipan kung paano posible na panatilihin ang isang puno na may lahat ng mga koneksyon sa isang flat table. Ito ay patag, ngunit ang puno ay hierarchical. Ngunit isang mahusay na solusyon para sa maramihang pag-access, at pagkatapos (habang nagiging mas kumplikado ang system) transactional, ay isang DBMS. Marahil hindi ako ang unang nakatagpo ng problemang ito. Nagsimula akong mag-googling. Ito ay lumabas na ang lahat ay naimbento na bago sa akin at mayroong ilang mga algorithm na bumuo ng isang puno mula sa isang patag na mesa. Matapos tingnan ang bawat isa, ipinatupad ko ang isa sa kanila. Ngunit ito ay isa nang bagong bersyon ng system, dahil... Sa katunayan, dahil dito, kailangan kong muling magsulat ng marami. Ang resulta ay natural, ang mga problema ng random na pag-uugali ng system ay nawala. Maaaring sabihin ng ilan na ang mga error ay napaka-amateurish (mga single-threaded na script, nag-iimbak ng impormasyon na na-access nang maraming beses nang sabay-sabay mula sa iba't ibang mga thread sa isang file, atbp.) sa larangan ng software development. Marahil ito ay totoo, ngunit ang aking pangunahing trabaho ay pangangasiwa, at ang programming ay isang side hustle para sa aking kaluluwa, at wala akong karanasan na magtrabaho sa isang pangkat ng mga programmer, kung saan ang mga pangunahing bagay ay agad na iminungkahi sa akin ng aking nakatatanda. mga kasama. Samakatuwid, napunan ko ang lahat ng mga bump na ito sa aking sarili, ngunit natutunan ko ang materyal nang husto. At gayundin, ang aking trabaho ay nagsasangkot ng mga pagpupulong sa mga kliyente, mga aksyon na naglalayong subukang i-promote ang kumpanya, isang grupo ng mga administratibong isyu sa loob ng kumpanya, at marami, marami pang iba. Ngunit sa isang paraan o iba pa, kung ano ang naroon ay hinihiling. Ang mga lalaki at ako mismo ang gumamit ng produkto sa aming pang-araw-araw na gawain. May mga lantarang hindi matagumpay na ideya at solusyon kung saan nasayang ang oras, ngunit sa huli ay naging malinaw na ito ay hindi isang gumaganang kasangkapan at walang gumamit nito at hindi ito napunta sa Veliam.
Helpdesk - HelpDesk
Hindi mali na banggitin kung paano nabuo ang HelpDesk. Ito ay isang ganap na kakaibang kuwento, dahil... sa Veliam ito na ang ika-3 ganap na bagong bersyon, na iba sa lahat ng nauna. Ngayon ito ay isang simpleng sistema, madaling maunawaan nang walang hindi kinakailangang mga kampanilya at sipol, na may kakayahang isama sa isang domain, pati na rin ang kakayahang ma-access ang parehong profile ng user mula sa kahit saan gamit ang isang link mula sa isang email. At higit sa lahat, posibleng kumonekta sa aplikante sa pamamagitan ng VNC mula sa kahit saan (sa bahay o sa opisina) nang direkta mula sa application nang walang VPN o port forwarding. Sasabihin ko sa iyo kung paano tayo napunta dito, kung ano ang nangyari noon at kung anong mga kakila-kilabot na desisyon ang ginawa.
Kumonekta kami sa mga user sa pamamagitan ng kilalang TeamViewer. Ang lahat ng mga computer na ang mga user na pinaglilingkuran namin ay may naka-install na TV. Ang unang bagay na nagawa naming mali, at pagkatapos ay inalis ito, ay ang pagli-link sa bawat HD client sa hardware. Paano nag-log in ang user sa HD system para makapag-iwan ng kahilingan? Bilang karagdagan sa TV, ang bawat isa ay may espesyal na utility na naka-install sa kanilang mga computer, na nakasulat sa Lazarus (maraming mga tao dito ay iikot ang kanilang mga mata, at marahil ay pumunta sa Google kung ano ito, ngunit ang pinakamahusay na pinagsama-samang wika na alam ko ay Delphi, at si Lazarus ay halos ang parehong bagay, libre lamang). Sa pangkalahatan, naglunsad ang user ng isang espesyal na batch file na naglunsad ng utility na ito, na binasa naman ang HWID ng system at pagkatapos nito ay inilunsad ang browser at naganap ang pahintulot. Bakit ito ginawa? Sa ilang kumpanya, ang bilang ng mga user na naserbisyuhan ay binibilang nang isa-isa, at ang presyo ng serbisyo para sa bawat buwan ay batay sa bilang ng mga tao. Ito ay naiintindihan, sabi mo, ngunit bakit ito nakatali sa hardware? Napakasimple lang, ilang indibidwal ang umuwi at gumawa ng kahilingan mula sa kanilang laptop sa bahay sa istilong "gawing maganda ang lahat para sa akin dito." Bilang karagdagan sa pagbabasa ng system HWID, hinila ng utility ang kasalukuyang Teamviewer ID mula sa registry at ipinadala rin ito sa amin. Ang Teamviewer ay may API para sa pagsasama. At ginawa namin ang pagsasamang ito. Ngunit may isang nahuli. Sa pamamagitan ng mga API na ito, imposibleng kumonekta sa computer ng user kapag hindi niya tahasang sinimulan ang session na ito at pagkatapos subukang kumonekta dito, dapat din niyang i-click ang "kumpirmahin". Sa oras na iyon, tila lohikal sa amin na walang dapat kumonekta nang walang kahilingan ng user, at dahil nasa computer ang tao, sisimulan niya ang session at tumutugon nang positibo sa kahilingan sa remote na koneksyon. Nagkamali ang lahat. Nakalimutan ng mga aplikante na pindutin ang simulan ang session, at kinailangang sabihin ito sa kanila sa isang pag-uusap sa telepono. Nag-aksaya ito ng oras at nakakadismaya sa magkabilang panig ng proseso. Bukod dito, hindi karaniwan para sa mga ganitong sandali kapag ang isang tao ay umalis sa isang kahilingan, ngunit pinapayagan lamang na kumonekta kapag umalis siya para sa tanghalian. Dahil hindi kritikal ang problema at ayaw niyang maputol ang proseso ng kanyang trabaho. Alinsunod dito, hindi niya pipindutin ang anumang mga pindutan upang payagan ang koneksyon. Ganito lumitaw ang karagdagang functionality noong nagla-log in sa HelpDesk - binabasa ang ID ng Teamviewer. Alam namin ang permanenteng password na ginamit noong nag-i-install ng Teamviewer. Mas tiyak, ang system lang ang nakakaalam nito, dahil ito ay binuo sa installer at sa aming system. Alinsunod dito, mayroong isang pindutan ng koneksyon mula sa application sa pamamagitan ng pag-click kung saan hindi na kailangang maghintay ng anuman, ngunit agad na binuksan ang Teamviewer at naganap ang isang koneksyon. Bilang resulta, mayroong dalawang uri ng posibleng koneksyon. Sa pamamagitan ng opisyal na Teamviewer API at ang aming sariling gawa. Sa aking sorpresa, halos agad-agad silang huminto sa paggamit ng una, kahit na mayroong tagubilin na gamitin lamang ito sa mga espesyal na kaso at kapag ang gumagamit mismo ang nagbigay ng go-ahead. Gayunpaman, bigyan mo ako ng seguridad ngayon. Ngunit lumabas na hindi ito kailangan ng mga aplikante. Lahat sila ay ganap na maayos sa pagiging konektado sa kanila nang walang pindutan ng pagkumpirma.
Lumipat sa multithreading sa Linux
Ang tanong ng pagpapabilis ng pagpasa ng isang scanner ng network para sa pagiging bukas ng isang paunang natukoy na listahan ng mga port at simpleng pag-ping ng mga bagay sa network ay matagal nang nagsimulang lumitaw. Dito, siyempre, ang unang solusyon na nasa isip ay multithreading. Dahil ang pangunahing oras na ginugol sa ping ay naghihintay na maibalik ang packet, at ang susunod na ping ay hindi maaaring magsimula hanggang sa maibalik ang nakaraang packet, sa mga kumpanya na kahit na mayroong 20+ server at kagamitan sa network, ito ay gumana nang medyo mabagal. Ang punto ay maaaring mawala ang isang pakete, ngunit huwag agad na ipaalam sa administrator ng system ang tungkol dito. Ihihinto na lang niya ang pagtanggap ng ganoong spam nang napakabilis. Nangangahulugan ito na kailangan mong i-ping ang bawat bagay nang higit sa isang beses bago gumawa ng konklusyon tungkol sa hindi naa-access. Nang walang masyadong maraming detalye, kinakailangang i-parallelize ito dahil kung hindi ito nagawa, malamang na matututunan ng system administrator ang problema mula sa kliyente, at hindi mula sa monitoring system.
Ang PHP mismo ay hindi sumusuporta sa multithreading out of the box. May kakayahang multiprocessing, maaari mong tinidor. Ngunit, sa katunayan, mayroon na akong nakasulat na mekanismo ng botohan at gusto kong gawin ito upang minsan kong bilangin ang lahat ng mga node na kailangan ko mula sa database, i-ping ang lahat nang sabay-sabay, maghintay ng tugon mula sa bawat isa at pagkatapos lamang na magsulat kaagad. ang data. Makakatipid ito sa bilang ng mga kahilingan sa pagbasa. Ang multithreading ay ganap na akma sa ideyang ito. Para sa PHP mayroong isang module ng PThreads na nagpapahintulot sa iyo na gumawa ng tunay na multithreading, bagama't kinailangan ng isang patas na dami ng tinkering upang i-set up ito sa PHP 7.2, ngunit ito ay tapos na. Mabilis na ngayon ang pag-scan sa port at pag-ping. At sa halip na, halimbawa, 15 segundo bawat lap mas maaga, ang prosesong ito ay nagsimulang tumagal ng 2 segundo. Ito ay isang magandang resulta.
Mabilis na pag-audit ng mga bagong kumpanya
Paano nabuo ang functionality para sa pagkolekta ng iba't ibang sukatan at katangian ng hardware? Simple lang. Minsan inutusan lang kaming i-audit ang kasalukuyang imprastraktura ng IT. Well, ang parehong bagay ay kinakailangan upang mapabilis ang pag-audit ng isang bagong kliyente. Kailangan namin ng isang bagay na magpapahintulot sa amin na makarating sa isang katamtaman o malaking kumpanya at mabilis na malaman kung ano ang mayroon sila. Sa palagay ko, ang ping sa panloob na network ay hinaharangan lamang ng mga gustong gawing kumplikado ang kanilang sariling buhay, at sa aming karanasan ay kakaunti sila. Pero may mga ganyan din. Alinsunod dito, mabilis mong mai-scan ang mga network para sa pagkakaroon ng mga device na may simpleng ping. Pagkatapos ay maaari naming idagdag ang mga ito at mag-scan para sa mga bukas na port na interesado sa amin. Sa katunayan, umiral na ang pag-andar na ito; kinakailangan lamang na magdagdag ng utos mula sa gitnang server sa alipin upang mai-scan nito ang mga tinukoy na network at idagdag ang lahat ng nahanap nito sa listahan. Nakalimutan kong banggitin, ipinapalagay na mayroon na kaming handa na imahe na may naka-configure na system (serve ng pagsubaybay ng alipin) na maaari naming i-roll out mula sa kliyente sa panahon ng pag-audit at ikonekta ito sa aming cloud.
Ngunit ang resulta ng isang pag-audit ay karaniwang may kasamang grupo ng iba't ibang impormasyon, at isa sa mga ito ay kung anong uri ng mga device ang nasa network. Una sa lahat, interesado kami sa mga Windows server at Windows workstation bilang bahagi ng isang domain. Dahil sa katamtaman at malalaking kumpanya ang kakulangan ng isang domain ay malamang na isang pagbubukod sa panuntunan. Upang magsalita ng isang wika, ang karaniwan, sa palagay ko, ay 100+ tao. Kinailangan na makabuo ng paraan upang mangolekta ng data mula sa lahat ng Windows machine at server, alam ang kanilang IP at domain administrator account, ngunit nang walang pag-install ng anumang software sa bawat isa sa kanila. Ang interface ng WMI ay dumating upang iligtas. Ang Windows Management Instrumentation (WMI) ay literal na nangangahulugang mga tool sa pamamahala ng Windows. Ang WMI ay isa sa mga pangunahing teknolohiya para sa sentralisadong pamamahala at pagsubaybay sa pagpapatakbo ng iba't ibang bahagi ng imprastraktura ng computer na tumatakbo sa Windows platform. Kinuha mula sa wiki. Susunod, kinailangan kong mag-tinker muli upang mai-compile ang wmic (ito ay isang WMI client) para sa Debian. Matapos ang lahat ay handa na, ang natitira na lang ay i-poll lamang ang mga kinakailangang node sa pamamagitan ng wmic para sa kinakailangang impormasyon. Sa pamamagitan ng WMI maaari kang makakuha ng halos anumang impormasyon mula sa isang Windows computer, at higit pa rito, maaari mo ring kontrolin ang computer sa pamamagitan nito, halimbawa, ipadala ito upang i-reboot. Ito ay kung paano lumitaw ang koleksyon ng impormasyon tungkol sa mga istasyon at server ng Windows sa aming system. Bilang karagdagan dito, mayroong kasalukuyang impormasyon tungkol sa kasalukuyang mga tagapagpahiwatig ng pagkarga ng system. Hinihiling namin ang mga ito nang mas madalas, at mas madalas ang impormasyon sa hardware. Pagkatapos nito, naging mas kasiya-siya ang pag-audit.
Desisyon sa pamamahagi ng software
Kami mismo ang gumagamit ng system araw-araw, at ito ay palaging bukas para sa bawat teknikal na empleyado. At naisip namin na maaari naming ibahagi sa iba kung ano ang mayroon kami. Ang sistema ay hindi pa handa na ipamahagi. Marami ang kailangang i-rework upang ang lokal na bersyon ay maging SaaS. Kabilang dito ang mga pagbabago sa iba't ibang teknikal na aspeto ng system (mga remote na koneksyon, serbisyo ng suporta), pagsusuri ng mga module para sa paglilisensya, sharding ng mga database ng customer, pag-scale ng bawat serbisyo, at pagbuo ng mga auto-update system para sa lahat ng bahagi. Ngunit ito ang magiging pangalawang bahagi ng artikulo.
Mga update
Pinagmulan: www.habr.com