🥇Kutoka kwa kazi ya nje hadi maendeleo (Sehemu ya 1)

Hello kila mtu, jina langu ni Sergey Emelyanchik. Mimi ni mkuu wa kampuni ya Audit-Telecom, msanidi mkuu na mwandishi wa mfumo wa Veliam. Niliamua kuandika makala kuhusu jinsi mimi na rafiki yangu tulivyounda kampuni ya kutoa huduma nje, tukajiandikia programu na baadaye tukaanza kuisambaza kwa kila mtu kupitia mfumo wa SaaS. Kuhusu jinsi ambavyo sikuamini kabisa kuwa hii inawezekana. Nakala hiyo haitakuwa na hadithi tu, bali pia maelezo ya kiufundi ya jinsi bidhaa ya Veliam iliundwa. Ikijumuisha baadhi ya vipande vya msimbo wa chanzo. Nitakuambia ni makosa gani tuliyofanya na jinsi tulivyosahihisha baadaye. Kulikuwa na mashaka kama kuchapisha makala kama hiyo. Lakini nilifikiri ni bora kuifanya, kupata maoni na kuboresha, kuliko kutochapisha makala na kufikiri juu ya nini kingetokea ikiwa ...

kabla ya historia

Nilifanya kazi katika kampuni moja kama mfanyakazi wa IT. Kampuni hiyo ilikuwa kubwa kabisa na muundo mpana wa mtandao. Sitakaa juu ya majukumu yangu ya kazi, nitasema tu kwamba hakika hawakujumuisha maendeleo ya chochote.

Tulikuwa na ufuatiliaji, lakini kwa sababu ya maslahi ya kitaaluma nilitaka kujaribu kuandika yangu rahisi zaidi. Wazo lilikuwa hili: Nilitaka iwe kwenye wavuti, ili niweze kuingia kwa urahisi bila kusakinisha wateja wowote na kuona kinachoendelea na mtandao kutoka kwa kifaa chochote, pamoja na kifaa cha rununu kupitia Wi-Fi, na mimi pia kwa kweli. nilitaka kuelewa haraka ni nini Kuna vifaa kwenye chumba ambavyo vimekuwa "mopey" kwa sababu ... kulikuwa na mahitaji madhubuti sana ya wakati wa kujibu shida kama hizo. Kama matokeo, mpango ulizaliwa kichwani mwangu wa kuandika ukurasa rahisi wa wavuti ambao kulikuwa na usuli wa jpeg na mchoro wa mtandao, kukata vifaa vyenyewe na anwani zao za IP kwenye picha hii, na kuonyesha yaliyomo juu ya picha. picha katika kuratibu zinazohitajika kwa namna ya anwani ya IP ya kijani au nyekundu. Jukumu limewekwa, wacha tuanze.

Hapo awali, nilikuwa nikitengeneza programu katika Delphi, PHP, JS na C++ ya juu juu. Najua vizuri jinsi mitandao inavyofanya kazi. VLAN, Uelekezaji (OSPF, EIGRP, BGP), NAT. Hii ilitosha kwangu kuandika mfano wa ufuatiliaji wa awali mwenyewe.

Написал задуманное на PHP. Сервер Apache и PHP был на Windows т.к. Linux для меня в тот момент был чем-то непонятным и очень сложным, как оказалось позже, я сильно ошибался и во многих местах Linux куда проще Windows, но это тема отдельная и мы все знаем сколько холиваров на эту тему. Планировщик задач Windows дергал с небольшим интервалом (точно не помню, но что-то вроде одного раза в три секунды) PHP скрипт, который опрашивал все объекты банальным пингом и сохранял состояние в файл.

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

Ndio, ndio, kufanya kazi na hifadhidata wakati huo pia haikueleweka kwangu. Sikujua kuwa inawezekana kusawazisha michakato, na kupitia nodi zote za mtandao zilichukua muda mrefu, kwa sababu ... hii ilitokea kwenye thread moja. Matatizo hasa yalitokea wakati nodes kadhaa hazikuwepo, kwa sababu kila mmoja wao alichelewesha hati kwa 300 ms. Kwa upande wa mteja kulikuwa na kazi rahisi ya kuzunguka, ambayo, kwa vipindi vya sekunde chache, ilipakua habari iliyosasishwa kutoka kwa seva na ombi la Ajax na kusasisha kiolesura. Kweli, basi, baada ya pings 3 zisizofanikiwa mfululizo, ikiwa ukurasa wa wavuti na ufuatiliaji ulifunguliwa kwenye kompyuta, utungaji wa furaha ulicheza.

Wakati kila kitu kilifanyika, nilitiwa moyo sana na matokeo na nilifikiri kwamba naweza kuongeza zaidi (kutokana na ujuzi na uwezo wangu). Lakini siku zote sikupenda mifumo iliyo na chati milioni, ambayo nilidhani wakati huo, na bado nadhani hadi leo, sio lazima katika hali nyingi. Nilitaka kuweka tu kile ambacho kingenisaidia sana katika kazi yangu. Kanuni hii inabaki kuwa msingi kwa maendeleo ya Veliam hadi leo. Zaidi ya hayo, niligundua kuwa itakuwa nzuri sana ikiwa sikuhitaji kuweka ufuatiliaji wazi na kujua kuhusu matatizo, na ilipotokea, kisha fungua ukurasa na uone mahali ambapo nodi hii ya mtandao yenye matatizo iko na nini cha kufanya nayo ijayo. . Kwa njia fulani sikusoma barua pepe wakati huo, sikuitumia. Niligundua kwenye Mtandao kwamba kuna lango la SMS ambalo unaweza kutuma ombi la GET au POST, na watatuma SMS kwa simu yangu ya rununu na maandishi ninayoandika. Mara moja niligundua kuwa nilitaka sana hii. Na nilianza kusoma nyaraka. Baada ya muda fulani nilifanikiwa, na sasa nilipokea SMS kuhusu matatizo kwenye mtandao kwenye simu yangu ya mkononi na jina la "kitu kilichoanguka". Ingawa mfumo huo ulikuwa wa zamani, uliandikwa na mimi mwenyewe, na jambo muhimu zaidi ambalo lilinitia moyo kuukuza ni kwamba ilikuwa programu ya maombi ambayo ilinisaidia sana katika kazi yangu.

Na kisha siku ilikuja ambapo moja ya njia za mtandao zilishuka kazini, na ufuatiliaji wangu haukunijulisha kuhusu hilo. Kwa kuwa Google DNS bado ina pinged kikamilifu. Ni wakati wa kufikiria jinsi unavyoweza kufuatilia kuwa chaneli ya mawasiliano iko hai. Kulikuwa na mawazo tofauti juu ya jinsi ya kufanya hivyo. Sikuweza kufikia vifaa vyote. Ilitubidi kujua jinsi ya kuelewa ni ipi kati ya chaneli ziko moja kwa moja, lakini bila kuweza kuiona kwa njia fulani kwenye vifaa vya mtandao yenyewe. Kisha mwenzako akaja na wazo kwamba inawezekana kwamba ufuatiliaji wa njia kwa seva za umma unaweza kutofautiana kulingana na njia gani ya mawasiliano inatumika kufikia Mtandao. Niliangalia na ikawa hivyo. Kulikuwa na njia tofauti wakati wa kufuatilia.

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

Kwa hiyo script nyingine ilionekana, au tuseme, kwa sababu fulani ufuatiliaji uliongezwa hadi mwisho wa script sawa, ambayo iliweka vifaa vyote kwenye mtandao. Baada ya yote, huu ni mchakato mwingine mrefu ambao ulitekelezwa kwenye uzi mmoja na kupunguza kasi ya kazi ya hati nzima. Lakini basi haikuwa wazi sana. Lakini kwa njia moja au nyingine, alifanya kazi yake, msimbo ulifafanua madhubuti ni aina gani ya ufuatiliaji inapaswa kuwa kwa kila chaneli. Hivi ndivyo mfumo ulianza kufanya kazi, ambao tayari ulifuatilia (kwa sauti kubwa, kwa sababu hakukuwa na mkusanyiko wa metrics yoyote, lakini tu ping) vifaa vya mtandao (ruta, swichi, wi-fi, nk) na njia za mawasiliano na ulimwengu wa nje. . Ujumbe wa SMS ulifika mara kwa mara na mchoro daima ulionyesha wazi tatizo lilikuwa wapi.

Zaidi ya hayo, katika kazi ya kila siku ilinibidi kufanya kuvuka msalaba. Na nilichoka kwenda kwenye swichi za Cisco kila wakati ili kuona ni kiolesura gani cha kutumia. Ingekuwa vyema jinsi gani kubofya kitu katika ufuatiliaji na kuona orodha ya violesura vyake na maelezo. Ingeniokoa wakati. Zaidi ya hayo, katika mpango huu hakutakuwa na haja ya kuendesha Putty au SecureCRT ili kuingiza akaunti na amri. Nilibofya tu ufuatiliaji, nikaona kile kinachohitajika na nikaenda kufanya kazi yangu. Nilianza kutafuta njia za kuingiliana na swichi. Mara moja nilipata chaguzi 2: SNMP au kuingia kwenye swichi kupitia SSH, nikiingiza amri nilizohitaji na kuchambua matokeo. Niliondoa SNMP kwa sababu ya ugumu wa utekelezaji wake; sikuwa na subira kupata matokeo. ukiwa na SNMP, ungelazimika kuchimba kwenye MIB kwa muda mrefu na, kulingana na data hii, kutoa data kuhusu miingiliano. Kuna timu nzuri huko CISCO

show interface status

Inaonyesha kile ninachohitaji kwa vivuko. Kwa nini ujisumbue na SNMP wakati ninataka tu kuona matokeo ya amri hii, nilifikiria. Baada ya muda, niligundua fursa hii. Umebofya kitu kwenye ukurasa wa wavuti. Tukio lilianzishwa ambalo mteja wa AJAX aliwasiliana na seva, na, kwa upande wake, iliunganishwa kupitia SSH kwa swichi niliyohitaji (sifa ziliwekwa ngumu kwa nambari, hakukuwa na hamu ya kuiboresha, kutengeneza menyu tofauti ambapo itawezekana kubadilisha akaunti kutoka kwa kiolesura , nilihitaji matokeo na haraka) Niliingiza amri hapo juu na kuirudisha kwa kivinjari. Kwa hivyo nilianza kuona habari kwenye miingiliano na bonyeza moja ya panya. Hii ilikuwa rahisi sana, haswa wakati ulilazimika kutazama habari hii kwenye swichi tofauti mara moja.

Ufuatiliaji wa kituo unaotegemea ufuatiliaji uliishia kutokuwa wazo bora, kwa sababu... wakati mwingine kazi ilifanyika kwenye mtandao, na ufuatiliaji unaweza kubadilika na ufuatiliaji ulianza kunipigia kelele kwamba kulikuwa na matatizo na kituo. Lakini baada ya kutumia muda mwingi kwenye uchambuzi, niligundua kuwa njia zote zilikuwa zikifanya kazi, na ufuatiliaji wangu ulikuwa ukinidanganya. Kama matokeo, niliuliza wenzangu ambao walisimamia swichi za kuunda chaneli kunitumia tu syslog wakati hali ya mwonekano wa majirani inabadilika. Ipasavyo, ilikuwa rahisi zaidi, haraka na sahihi zaidi kuliko kufuatilia. Tukio kama vile jirani aliyepotea limefika, na mara moja ninatoa arifa kuhusu kituo chini.

Zaidi ya hayo, amri kadhaa zaidi zilionekana wakati wa kubofya kitu, na SNMP iliongezwa ili kukusanya baadhi ya vipimo, na ndivyo hivyo. Mfumo haukuendelea zaidi. Ilifanya kila nilichohitaji, ilikuwa zana nzuri. Wasomaji wengi labda wataniambia kuwa tayari kuna programu nyingi kwenye mtandao ili kutatua matatizo haya. Lakini kwa kweli, sikutumia google bidhaa kama hizo za bure wakati huo na nilitaka sana kukuza ustadi wangu wa upangaji, na ni njia gani bora ya kushinikiza hii kuliko shida halisi ya programu. Katika hatua hii, toleo la kwanza la ufuatiliaji lilikamilishwa na halikubadilishwa tena.

Uundaji wa kampuni ya Ukaguzi-Telecom

Kadiri muda ulivyopita, nilianza kufanya kazi kwa muda katika makampuni mengine, kwa bahati nzuri ratiba yangu ya kazi iliniruhusu kufanya hivyo. Unapofanya kazi katika makampuni mbalimbali, ujuzi wako katika maeneo mbalimbali hukua haraka sana, na upeo wako hukua vizuri. Kuna kampuni ambazo, kama wanasema, wewe ni Msweden, mvunaji na mpiga tarumbeta. Kwa upande mmoja, ni vigumu, kwa upande mwingine, ikiwa si wavivu, unakuwa generalist na hii inakuwezesha kutatua matatizo kwa kasi na kwa ufanisi zaidi kwa sababu unajua jinsi uwanja unaohusiana unavyofanya kazi.

Rafiki yangu Pavel (pia mtaalamu wa IT) alijaribu mara kwa mara kunitia moyo kuanzisha biashara yake mwenyewe. Kulikuwa na mawazo mengi na tofauti tofauti za kile walichokuwa wakifanya. Hii imejadiliwa kwa miaka. Na mwishowe, haikupaswa kuja kwa chochote kwa sababu mimi ni mwenye shaka, na Pavel ni mwotaji. Kila wakati alipendekeza wazo, siku zote sikuliamini na nilikataa kushiriki. Lakini tulitaka sana kufungua biashara yetu wenyewe.

Hatimaye, tuliweza kupata chaguo ambalo linafaa sisi sote wawili na kufanya kile tunachojua kufanya. Mnamo 2016, tuliamua kuunda kampuni ya TEHAMA ambayo ingesaidia biashara kutatua matatizo ya TEHAMA. Huu ni uwekaji wa mifumo ya TEHAMA (1C, seva ya terminal, seva ya barua, n.k.), matengenezo yake, HelpDesk ya kawaida kwa watumiaji na usimamizi wa mtandao.

Kwa kusema ukweli, wakati wa kuunda kampuni, sikuamini kuhusu 99,9%. Lakini kwa namna fulani Pavel aliweza kunifanya nijaribu, na kuangalia mbele, aligeuka kuwa sahihi. Mimi na Pavel tulinunua rubles 300 kila mmoja, tukasajili kampuni mpya ya "Audit-Telecom", tukakodisha ofisi ndogo, tukatengeneza kadi nzuri za biashara, vizuri, kwa ujumla, kama wafanyabiashara wasio na uzoefu zaidi, na kuanza kutafuta wateja. Kupata wateja ni hadithi tofauti kabisa. Labda tutaandika nakala tofauti kama sehemu ya blogi ya ushirika ikiwa kuna mtu anayevutiwa. Simu za baridi, vipeperushi, nk. Hii haikutoa matokeo yoyote. Ninaposoma sasa kutoka kwa hadithi nyingi kuhusu biashara, kwa njia moja au nyingine, mengi inategemea bahati. Tulikuwa na bahati. na kwa kweli wiki kadhaa baada ya kuundwa kwa kampuni hiyo, kaka yangu Vladimir alitukaribia, ambaye alituletea mteja wetu wa kwanza. Sitakuchosha na maelezo ya kufanya kazi na wateja, hiyo siyo makala inahusu, niseme tu tulienda kufanya ukaguzi, tukabaini maeneo muhimu na maeneo haya yakaharibika huku uamuzi ukitolewa shirikiana nasi kwa msingi unaoendelea kama wafadhili wa nje. Baada ya hayo, uamuzi mzuri ulifanywa mara moja.

Kisha, hasa kwa maneno ya kinywa kupitia marafiki, makampuni mengine ya huduma yalianza kuonekana. Helpdesk ilikuwa katika mfumo mmoja. Viunganisho kwa vifaa vya mtandao na seva ni tofauti, au tuseme tofauti. Baadhi ya watu walihifadhi njia za mkato, wengine walitumia vitabu vya anwani vya RDP. Ufuatiliaji ni mfumo mwingine tofauti. Ni usumbufu sana kwa timu kufanya kazi katika mifumo tofauti. Taarifa muhimu zimepotea. Kweli, kwa mfano, seva ya terminal ya mteja haikupatikana. Maombi kutoka kwa watumiaji wa mteja huyu hupokelewa mara moja. Mtaalamu wa usaidizi anafungua ombi (ilipokelewa kwa simu). Ikiwa matukio na maombi yalisajiliwa katika mfumo mmoja, basi mtaalamu wa usaidizi ataona mara moja tatizo la mtumiaji ni nini na kumwambia kuhusu hilo, wakati huo huo akiunganisha kwa kitu kinachohitajika ili kutatua hali hiyo. Kila mtu anajua hali ya mbinu na anafanya kazi kwa usawa. Hatujapata mfumo ambapo haya yote yameunganishwa. Ilibainika kuwa ni wakati wa kutengeneza bidhaa zetu wenyewe.

Inaendelea kufanya kazi kwenye mfumo wako wa ufuatiliaji

Ilikuwa wazi kwamba mfumo ulioandikwa hapo awali haukufaa kabisa kwa kazi za sasa. Si kwa suala la utendakazi wala ubora. Na iliamuliwa kuandika mfumo kutoka mwanzo. Graphically inapaswa kuonekana tofauti kabisa. Ilibidi iwe mfumo wa kihierarkia ili iwezekane kwa haraka na kwa urahisi kufungua kitu sahihi kwa mteja sahihi. Mpango kama katika toleo la kwanza haukuhesabiwa haki katika kesi ya sasa, kwa sababu Wateja ni tofauti na haijalishi kabisa vifaa vilikuwa katika majengo gani. Hii tayari imehamishiwa kwenye hati.

Kwa hivyo, majukumu:

Muundo wa kihierarkia;
Aina fulani ya sehemu ya seva ambayo inaweza kuwekwa kwenye majengo ya mteja katika mfumo wa mashine ya kawaida ya kukusanya metriki tunayohitaji na kuituma kwa seva kuu, ambayo itafanya muhtasari wa haya yote na kutuonyesha;
Tahadhari. Wale ambao hawawezi kukosa, kwa sababu ... wakati huo haikuwezekana mtu kukaa na kuangalia tu kufuatilia;
Mfumo wa maombi. Wateja walianza kuonekana ambao tuliwahudumia sio tu vifaa vya seva na mtandao, lakini pia vituo vya kazi;
Uwezo wa kuunganisha haraka kwa seva na vifaa kutoka kwa mfumo;

Задачи поставлены, начинаем писать. Попутно обрабатывая заявки от клиентов. На тот момент нас уже было 4 человека. Начали писать сразу обе части и центральный сервер, и сервер для установки к клиентам. К этому моменту Linux был уже не чужим для нас и было принято решение, что виртуальные машины, которые будут стоять у клиентов будут на Debian. Не будет никаких установщиков, просто сделаем проект серверной части на одной конкретной виртуальной машине, а потом просто будем ее клонировать к нужному клиенту. Это была очередная ошибка. Позже стало понятно, что в такой схеме абсолютно не проработан механизм апдейтов. Т.е. мы добавляли какую-то новую фичу, а потом была целая проблема распространять ее на все серверы клиентов, но к этому вернемся позже, все по порядку.

Tulifanya mfano wa kwanza. Aliweza kubandika vifaa na seva za mtandao wa mteja tulizohitaji na kutuma data hii kwa seva yetu kuu. Na yeye, kwa upande wake, alisasisha data hii kwa wingi kwenye seva kuu. Hapa sitaandika tu hadithi kuhusu jinsi na nini kilifanikiwa, lakini pia ni makosa gani ya amateurish yalifanywa na jinsi baadaye nililazimika kulipia kwa wakati. Kwa hivyo, mti mzima wa vitu ulihifadhiwa katika faili moja kwa namna ya kitu cha serialized. Wakati tuliunganisha wateja kadhaa kwenye mfumo, kila kitu kilikuwa cha kawaida zaidi au kidogo, ingawa wakati mwingine kulikuwa na mabaki ambayo hayakueleweka kabisa. Lakini tulipounganisha seva kadhaa kwenye mfumo, miujiza ilianza kutokea. Wakati mwingine, kwa sababu isiyojulikana, vitu vyote kwenye mfumo vilitoweka tu. Ni muhimu kutambua hapa kwamba seva ambazo wateja walikuwa wametuma data kwa seva kuu kila baada ya sekunde chache kupitia ombi la POST. Msomaji makini na mtayarishaji programu aliye na uzoefu tayari alikisia kuwa kulikuwa na tatizo la ufikivu mwingi wa faili ambayo kitu cha mfululizo kilihifadhiwa kutoka kwa nyuzi tofauti kwa wakati mmoja. Na tu wakati hii ilifanyika, miujiza ilitokea na kutoweka kwa vitu. Faili ikawa tupu. Lakini yote haya hayakugunduliwa mara moja, lakini tu wakati wa operesheni na seva kadhaa. Wakati huu, utendaji wa skanning ya bandari uliongezwa (seva zilizotumwa katikati sio tu habari kuhusu upatikanaji wa vifaa, lakini pia kuhusu bandari zilizofunguliwa juu yao). Hii ilifanywa kwa kupiga amri:

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

matokeo mara nyingi hayakuwa sahihi na uchunguzi ulichukua muda mrefu kukamilika. Nilisahau kabisa juu ya ping, ilifanywa kupitia fping:

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

Hili pia halikulinganishwa na kwa hivyo mchakato ulikuwa mrefu sana. Baadaye, orodha nzima ya anwani za IP zinazohitajika kwa uthibitishaji zilitumwa kwa fping mara moja, na nyuma tulipokea orodha iliyo tayari ya wale waliojibu. Tofauti na sisi, fping iliweza kusawazisha michakato.

Kazi nyingine ya kawaida ilikuwa kusanidi baadhi ya huduma kupitia WEB. Naam, kwa mfano, ECP kutoka MS Exchange. Kimsingi ni kiungo tu. Na tuliamua kwamba tunahitaji kuwa na uwezo wa kuongeza viungo vile moja kwa moja kwenye mfumo, ili tusiwe na kuangalia katika nyaraka au mahali pengine katika alamisho za jinsi ya kufikia ECP ya mteja maalum. Hivi ndivyo dhana ya viungo vya rasilimali kwa mfumo ilivyoonekana, utendaji wao unapatikana hadi leo na haujabadilika, vizuri, karibu.

Jinsi viungo vya rasilimali hufanya kazi huko Veliam

Viunganisho vya mbali

Hivi ndivyo inavyoonekana katika vitendo katika toleo la sasa la Veliam

Mojawapo ya kazi ilikuwa kuunganisha kwa haraka na kwa urahisi kwenye seva, ambazo tayari zilikuwa na nyingi (zaidi ya mia moja) na kupanga mamilioni ya njia za mkato za RDP zilizohifadhiwa awali ilikuwa ngumu sana. Chombo kilihitajika. Kuna programu kwenye Mtandao ambayo ni kitu kama kitabu cha anwani kwa miunganisho kama hiyo ya RDP, lakini haijaunganishwa na mfumo wa ufuatiliaji, na akaunti haziwezi kuhifadhiwa. Kuingiza akaunti za wateja tofauti kila wakati ni kuzimu unapounganisha mara kadhaa kwa siku kwenye seva tofauti. Ukiwa na SSH, mambo ni bora kidogo; kuna programu nyingi nzuri zinazokuruhusu kupanga miunganisho kama hii kwenye folda na kukumbuka akaunti kutoka kwao. Lakini kuna matatizo 2. Ya kwanza ni kwamba hatukupata programu moja ya miunganisho ya RDP na SSH. Ya pili ni kwamba ikiwa wakati fulani siko kwenye kompyuta yangu na ninahitaji kuunganisha haraka, au nimeweka upya mfumo, nitalazimika kuingia kwenye nyaraka ili kuangalia akaunti kutoka kwa mteja huyu. Ni usumbufu na kupoteza muda.

Muundo wa daraja tuliohitaji kwa seva za mteja ulikuwa tayari unapatikana katika bidhaa zetu za ndani. Ilinibidi tu kujua jinsi ya kushikamana na viunganisho vya haraka kwa vifaa muhimu hapo. Kwa wanaoanza, angalau ndani ya mtandao wako.

С учетом того, что клиентом в нашей системе выступал браузер, который не имеет доступа к локальным ресурсам компьютера, чтобы просто взять и какой-то командой запустить нужное нам приложение, было придумано сделать все через “Windows custom url scheme”. Так появился некий “плагин” к нашей системе, который просто включал в свой состав Putty и Remote Desktop Plus и при установке просто регистрировал URI схемы в Windows. Теперь, когда мы хотели подключиться к объекту по RDP или SSH, мы нажимали это действие в нашей системе и срабатывала работа Custom URI. Запускался стандартный mstsc.exe встроенный в Windows или putty, который шел в состав “плагина”. Беру слово плагин в кавычки, потому, что это не является плагином браузера в классическом смысле.

Это было уже хотя бы что-то. Удобная адресная книга. Причем в случае с Putty, все было вообще хорошо, ему в качестве входных параметров можно было подать и IP подключения и логин и пароль. Т.е. к Linux серверам в своей сети мы уже подключались одним кликом без ввода паролей. Но с RDP не все так просто. В стандартный mstsc нельзя подать учетные данные в качестве параметров. На помощь пришел Remote Desktop Plus. Он позволял это делать. Сейчас мы уже обходимся без него, но долгое время он был верным помощником в нашей системе. С HTTP(S) сайтами все просто, такие объекты просто открывались в браузере и все. Удобно и практично. Но это было счастье только во внутренней сети.

Kwa kuwa tulitatua matatizo mengi kwa mbali kutoka ofisini, njia rahisi zaidi ilikuwa kuanzisha VPN kwa wateja. Kisha tungeweza kuwaunganisha kutoka kwa mfumo wetu. Lakini bado ilikuwa vigumu. Kwa kila mteja, tulilazimika kuweka nywila nyingi zilizohifadhiwa kwenye kila kompyuta. VPN Miunganisho, na kabla ya kuunganisha kwenye yoyote, VPN inayolingana ilibidi iwezeshwe. Tulitumia suluhisho hili kwa muda mrefu sana. Lakini idadi ya wateja ilikuwa ikiongezeka, kama vile idadi ya VPN, na haya yote yalikuwa yanaanza kuwa ya kukasirisha, na kitu kilibidi kifanyike kuhusu hilo. Ilikuwa ni machozi hasa baada ya kusakinisha upya mfumo, wakati nililazimika kuingiza tena miunganisho kadhaa ya VPN katika wasifu mpya wa Windows. Nikasema, "Nimechoka na haya," na nikaanza kufikiria kuhusu nini kifanyike kuihusu.

Ilifanyika kwamba wateja wote walikuwa na vifaa kutoka kwa kampuni inayojulikana ya Mikrotik kama ruta. Wao ni kazi sana na rahisi kwa kufanya karibu kazi yoyote. Ubaya ni kwamba "wanatekwa nyara". Tulitatua tatizo hili kwa kufunga ufikiaji wote kutoka nje. Lakini ilikuwa ni lazima kwa namna fulani kuzipata bila kufika mahali pa mteja, kwa sababu... ni ndefu. Tulitengeneza vichuguu kwa kila Mikrotik kama hiyo na tukatenganisha kwenye dimbwi tofauti. bila uelekezaji wowote, ili hakuna muunganisho wa mtandao wako na mitandao ya wateja na mitandao yao kwa kila mmoja.

Wazo lilizaliwa ili kuhakikisha kuwa ninapobofya kwenye kitu ninachohitaji kwenye mfumo, seva kuu ya ufuatiliaji, ikijua akaunti za SSH za mteja wote Mikrotik, inaunganisha kwa ile inayotaka, huunda sheria ya kusambaza kwa mwenyeji anayetaka na bandari inayohitajika. Kuna pointi kadhaa hapa. Suluhisho sio la ulimwengu wote - litafanya kazi tu kwa Mikrotik, kwani syntax ya amri ni tofauti kwa ruta zote. Pia, usambazaji kama huo basi ulilazimika kufutwa kwa njia fulani, na sehemu ya seva ya mfumo wetu haikuweza kufuatilia kwa njia yoyote kama nilikuwa nimemaliza kipindi changu cha RDP. Kweli, usambazaji kama huo ni shimo kwa mteja. Lakini hatukufuata ulimwengu wote, kwa sababu ... bidhaa ilitumika tu ndani ya kampuni yetu na hakukuwa na mawazo ya kuitoa kwa umma.

Kila moja ya shida ilitatuliwa kwa njia yake mwenyewe. Wakati sheria iliundwa, usambazaji huu ulipatikana tu kwa anwani moja maalum ya nje ya IP (ambayo uunganisho ulianzishwa). Kwa hivyo shimo la usalama liliepukwa. Lakini kwa kila unganisho kama hilo, sheria ya Mikrotik iliongezwa kwenye ukurasa wa NAT na haikufutwa. Na kila mtu anajua kuwa sheria zaidi zipo, ndivyo processor ya router inavyopakiwa. Na kwa ujumla, sikuweza kukubali kwamba siku moja ningeenda kwa Mikrotik, na kungekuwa na mamia ya sheria zilizokufa, zisizo na maana.

Kwa kuwa seva yetu haiwezi kufuatilia hali ya muunganisho, acha Mikrotik ifuatilie yenyewe. Na niliandika hati ambayo ilifuatilia kila mara sheria zote za usambazaji na maelezo maalum na kuangalia ikiwa muunganisho wa TCP ulikuwa na sheria inayofaa. Ikiwa haikuwepo kwa muda, basi muunganisho labda tayari umekamilika na usambazaji huu unaweza kufutwa. Kila kitu kilifanyika, maandishi yalifanya kazi vizuri.

Kwa njia, hii hapa:

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
	}
}

Hakika inaweza kufanywa kuwa nzuri zaidi, haraka, nk, lakini ilifanya kazi, haikupakia Mikrotik na ilifanya kazi nzuri. Hatimaye tuliweza kuunganisha kwenye seva za wateja na vifaa vya mtandao kwa kubofya mara moja tu. Bila kufungua VPN au kuingiza nywila. Mfumo umekuwa rahisi sana kufanya kazi nao. Muda wa huduma ulipunguzwa, na sisi sote tulitumia muda wa kufanya kazi badala ya kuunganisha kwenye vitu muhimu.

Hifadhi nakala ya Microtik

Tulisanidi nakala rudufu ya Mikrotik yote hadi FTP. Na kwa ujumla kila kitu kilikuwa sawa. Lakini ulipohitaji kupata chelezo, ilibidi ufungue FTP hii na kuitafuta hapo. Tuna mfumo ambapo vipanga njia vyote vimeunganishwa; tunaweza kuwasiliana na vifaa kupitia SSH. Kwa nini tusiifanye ili mfumo yenyewe uchukue salama kutoka kwa Mikrotik yote kila siku, nilifikiri. Na akaanza kutekeleza. Tuliunganisha, tukahifadhi nakala na kuipeleka kwenye hifadhi.

Nambari ya hati katika PHP ya kuchukua nakala rudufu kutoka 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');

?>

Hifadhi nakala inachukuliwa kwa aina mbili - usanidi wa binary na maandishi. Binary husaidia kurejesha haraka usanidi unaohitajika, na maandishi moja hukuruhusu kuelewa kile kinachohitajika kufanywa ikiwa kuna uingizwaji wa kulazimishwa wa vifaa na binary haiwezi kupakiwa kwake. Kama matokeo, tulipata utendakazi mwingine unaofaa katika mfumo. Kwa kuongezea, wakati wa kuongeza Mikrotik mpya, hakukuwa na haja ya kusanidi chochote; niliongeza tu kitu kwenye mfumo na kuweka akaunti yake kupitia SSH. Kisha mfumo yenyewe ulitunza kuchukua chelezo. Toleo la sasa la SaaS Veliam bado halina utendakazi huu, lakini tutalihamisha hivi karibuni.

Picha za skrini za jinsi ilivyokuwa katika mfumo wa ndani

Mpito hadi hifadhi ya kawaida ya hifadhidata

Tayari niliandika hapo juu kwamba mabaki yalionekana. Wakati mwingine orodha nzima ya vitu kwenye mfumo ilipotea tu, wakati mwingine wakati wa kuhariri kitu, habari haikuhifadhiwa na kitu kilipaswa kubadilishwa jina mara tatu. Jambo hili lilimkera kila mtu sana. Kutoweka kwa vitu kulitokea mara chache, na kurejeshwa kwa urahisi kwa kurejesha faili hii, lakini kushindwa wakati wa kuhariri vitu kulifanyika mara nyingi. Pengine, mwanzoni sikufanya hili kwa njia ya hifadhidata kwa sababu haikufaa katika akili yangu jinsi ilivyowezekana kuweka mti na viunganisho vyote kwenye meza ya gorofa. Ni tambarare, lakini mti ni wa kihierarkia. Lakini suluhisho nzuri kwa ufikiaji mwingi, na baadaye (kadiri mfumo unavyozidi kuwa mgumu) wa shughuli, ni DBMS. Labda mimi sio wa kwanza kukutana na shida hii. Nilianza ku-google. Ilibadilika kuwa kila kitu kilikuwa tayari zuliwa kabla yangu na kuna algorithms kadhaa zinazounda mti kutoka kwa meza ya gorofa. Baada ya kuangalia kila moja, nilitekeleza mojawapo. Lakini hii tayari ilikuwa toleo jipya la mfumo, kwa sababu ... Kwa kweli, kwa sababu ya hii, ilibidi niandike tena sana. Matokeo yake yalikuwa ya asili, matatizo ya tabia ya random ya mfumo yalikwenda. Wengine wanaweza kusema kwamba makosa ni ya ajabu sana (hati zenye nyuzi moja, kuhifadhi habari ambayo ilifikiwa mara nyingi wakati huo huo kutoka kwa nyuzi tofauti kwenye faili, nk) katika uwanja wa ukuzaji wa programu. Labda hii ni kweli, lakini kazi yangu kuu ilikuwa usimamizi, na programu ilikuwa shida ya roho yangu, na sikuwa na uzoefu wa kufanya kazi katika timu ya waandaaji wa programu, ambapo mambo ya msingi kama haya yangependekezwa kwangu mara moja na mkuu wangu. wandugu. Kwa hivyo, nilijaza matuta haya yote peke yangu, lakini nilijifunza nyenzo vizuri sana. Na pia, kazi yangu inahusisha mikutano na wateja, vitendo vinavyolenga kujaribu kukuza kampuni, rundo la masuala ya utawala ndani ya kampuni, na mengi zaidi. Lakini kwa njia moja au nyingine, kile kilichokuwa tayari kilikuwa katika mahitaji. Vijana na mimi mwenyewe tulitumia bidhaa hiyo katika kazi yetu ya kila siku. Kulikuwa na maoni na suluhisho ambazo hazikufanikiwa kwa wakati, lakini mwishowe ikawa wazi kuwa hii haikuwa zana ya kufanya kazi na hakuna mtu aliyeitumia na haikuishia Veliam.

Helpdesk - HelpDesk

Haitakuwa vibaya kutaja jinsi HelpDesk iliundwa. Hii ni hadithi tofauti kabisa, kwa sababu ... katika Veliam hili tayari ni toleo la 3 jipya kabisa, ambalo ni tofauti na zile zote zilizopita. Sasa ni mfumo rahisi, intuitive bila kengele na filimbi zisizohitajika, na uwezo wa kuunganishwa na kikoa, pamoja na uwezo wa kufikia wasifu sawa wa mtumiaji kutoka popote kwa kutumia kiungo kutoka kwa barua pepe. Na muhimu zaidi, inawezekana kuunganishwa na mwombaji kupitia VNC kutoka popote (nyumbani au ofisini) moja kwa moja kutoka kwa programu bila VPN au usambazaji wa bandari. Nitakuambia jinsi tulivyofikia hii, ni nini kilifanyika hapo awali na ni maamuzi gani mabaya yalifanywa.

Tuliunganisha kwa watumiaji kupitia TeamViewer inayojulikana sana. Kompyuta zote ambazo watumiaji wake tunawahudumia wamesakinisha TV. Jambo la kwanza tulilofanya vibaya, na baadaye kuliondoa, lilikuwa kuunganisha kila mteja wa HD kwenye maunzi. Je, mtumiaji aliingiaje kwenye mfumo wa HD ili kuacha ombi? Mbali na TV, kila mtu alikuwa na huduma maalum iliyosanikishwa kwenye kompyuta zao, iliyoandikwa kwa Lazaro (watu wengi hapa watatoa macho yao, na labda hata kwenda Google ni nini, lakini lugha bora zaidi iliyokusanywa nilijua ilikuwa Delphi, na Lazaro yuko karibu. kitu kimoja, bure tu). Kwa ujumla, mtumiaji alizindua faili maalum ya kundi ambayo ilizindua shirika hili, ambalo lilisoma HWID ya mfumo na baada ya kuwa kivinjari kilizinduliwa na idhini ilitokea. Kwa nini hili lilifanyika? Katika baadhi ya makampuni, idadi ya watumiaji wanaohudumiwa huhesabiwa kila mmoja, na bei ya huduma kwa kila mwezi inategemea idadi ya watu. Hii inaeleweka, unasema, lakini kwa nini imefungwa kwa vifaa? Kwa urahisi sana, baadhi ya watu walifika nyumbani na kufanya ombi kutoka kwa kompyuta yao ya pajani kwa mtindo wa "nifanyie kila kitu kizuri hapa." Mbali na kusoma mfumo wa HWID, shirika lilichomoa Kitambulisho cha sasa cha Teamviewer kutoka kwa usajili na pia kukisambaza kwetu. Teamviewer ina API ya kuunganishwa. Na tulifanya ujumuishaji huu. Lakini kulikuwa na samaki mmoja. Kupitia API hizi, haiwezekani kuunganisha kwenye kompyuta ya mtumiaji wakati hajaanzisha kwa uwazi kikao hiki na baada ya kujaribu kuunganisha nayo, lazima pia bonyeza "kuthibitisha". Wakati huo, ilionekana kuwa na mantiki kwetu kwamba hakuna mtu anayepaswa kuunganisha bila ombi la mtumiaji, na kwa kuwa mtu yuko kwenye kompyuta, ataanzisha kikao na kujibu kwa uthibitisho kwa ombi la uunganisho wa mbali. Kila kitu kiligeuka kuwa sawa. Waombaji walisahau kushinikiza kuanzisha kikao, na ilibidi kuwaambia hili katika mazungumzo ya simu. Hii ilipoteza muda na ilikuwa inakatisha tamaa pande zote mbili za mchakato. Aidha, sio kawaida kabisa kwa wakati huo wakati mtu anaacha ombi, lakini anaruhusiwa kuunganisha tu wakati anaondoka kwa chakula cha mchana. Kwa sababu tatizo si muhimu na hataki mchakato wake wa kazi ukatishwe. Ipasavyo, hatabonyeza vitufe vyovyote ili kuruhusu muunganisho. Hivi ndivyo utendaji wa ziada ulivyoonekana wakati wa kuingia kwenye HelpDesk - kusoma Kitambulisho cha Teamviewer. Tulijua nenosiri la kudumu ambalo lilitumiwa wakati wa kusakinisha Teamviewer. Kwa usahihi, mfumo tu ndio ulijua, kwani ilijengwa ndani ya kisakinishi na kwenye mfumo wetu. Ipasavyo, kulikuwa na kitufe cha unganisho kutoka kwa programu kwa kubofya ambayo hakukuwa na haja ya kungojea chochote, lakini Teamviewer ilifunguliwa mara moja na unganisho likatokea. Matokeo yake, kulikuwa na aina mbili za viunganisho vinavyowezekana. Kupitia API rasmi ya Kitazamaji cha Timu na ile tuliyojitengenezea. Kwa mshangao wangu, waliacha kutumia ya kwanza mara moja, ingawa kulikuwa na maagizo ya kuitumia tu katika hali maalum na wakati mtumiaji mwenyewe anatoa idhini. Bado, nipe usalama sasa. Lakini ikawa kwamba waombaji hawakuhitaji hili. Wote ni sawa kabisa kwa kuunganishwa nao bila kitufe cha uthibitisho. Na kwa kuwa hii ndiyo hali, utendaji kazi wa muunganisho wa API uliondolewa baadaye kama usio wa lazima.

Переход на многопоточность в Linux

Swali la kuharakisha kifungu cha skana ya mtandao kwa uwazi wa orodha iliyotanguliwa ya bandari na pinging rahisi ya vitu vya mtandao kwa muda mrefu imeanza kutokea. Hapa, bila shaka, suluhisho la kwanza linalokuja akilini ni multithreading. Kwa kuwa wakati kuu unaotumiwa kwenye ping ni kusubiri pakiti kurejeshwa, na ping inayofuata haiwezi kuanza hadi pakiti ya awali irejeshwe, katika makampuni ambayo hata yalikuwa na seva 20+ pamoja na vifaa vya mtandao, hii tayari ilifanya kazi polepole kabisa. Jambo ni kwamba mfuko mmoja unaweza kutoweka, lakini usijulishe mara moja msimamizi wa mfumo kuhusu hilo. Ataacha tu kukubali barua taka kama hizo haraka sana. Hii inamaanisha kuwa unahitaji kuweka kila kitu zaidi ya mara moja kabla ya kufanya hitimisho juu ya kutoweza kufikiwa. Bila kuingia kwa undani sana, ni muhimu kuifanya sambamba kwa sababu ikiwa hii haijafanywa, basi uwezekano mkubwa wa msimamizi wa mfumo atajifunza kuhusu tatizo kutoka kwa mteja, na si kutoka kwa mfumo wa ufuatiliaji.

PHP yenyewe haiauni usomaji mwingi nje ya kisanduku. Uwezo wa kuzidisha, unaweza kutengeneza uma. Lakini, kwa kweli, tayari nilikuwa na utaratibu wa kupigia kura ulioandikwa na nilitaka kuifanya ili mara moja nihesabu nodi zote nilizohitaji kutoka kwa hifadhidata, ping kila kitu mara moja, subiri jibu kutoka kwa kila mmoja na tu baada ya hapo andika mara moja. data. Hii inaokoa kwa idadi ya maombi yaliyosomwa. Multithreading inafaa kikamilifu katika wazo hili. Kwa PHP kuna moduli ya PThreads ambayo hukuruhusu kufanya usomaji halisi wa maandishi mengi, ingawa ilichukua kiasi cha kutosha cha kuchezea kuweka hii kwenye PHP 7.2, lakini ilifanyika. Uchanganuzi wa bandari na ping sasa ni haraka. Na badala ya, kwa mfano, sekunde 15 kwa kila mzunguko mapema, mchakato huu ulianza kuchukua sekunde 2. Ilikuwa matokeo mazuri.

Ukaguzi wa haraka wa makampuni mapya

Je, utendakazi wa kukusanya vipimo na sifa mbalimbali za maunzi ulikujaje? Ni rahisi. Wakati mwingine tunaagizwa tu kukagua miundombinu ya sasa ya IT. Naam, kitu kimoja ni muhimu ili kuharakisha ukaguzi wa mteja mpya. Tulihitaji kitu ambacho kingeturuhusu kuja kwa kampuni ya kati au kubwa na kujua haraka kile wanacho. Kwa maoni yangu, ping kwenye mtandao wa ndani imefungwa tu na wale ambao wanataka kufanya maisha yao kuwa magumu, na katika uzoefu wetu kuna wachache wao. Lakini pia kuna watu kama hao. Ipasavyo, unaweza kukagua mitandao haraka kwa uwepo wa vifaa na ping rahisi. Kisha tunaweza kuziongeza na kutafuta milango iliyo wazi ambayo inatuvutia. Kwa kweli, utendakazi huu tayari ulikuwepo; ilikuwa ni lazima tu kuongeza amri kutoka kwa seva kuu hadi kwa mtumwa ili iweze kuchanganua mitandao iliyoainishwa na kuongeza kila kitu kilichopatikana kwenye orodha. Nilisahau kutaja, ilichukuliwa kuwa tayari tuna picha iliyopangwa tayari na mfumo uliowekwa (seva ya ufuatiliaji wa watumwa) ambayo tunaweza tu kutoka kwa mteja wakati wa ukaguzi na kuiunganisha kwenye wingu letu.

Но результат аудита обычно включает в себя кучу различной информации и одна из них это — что вообще за устройства в сети. В первую очередь нас интересовали Windows серверы и рабочие станции Windows в составе домена. Так как в средних и крупных компаниях отсутствие домена — это, наверное, исключение из правил. Что бы говорить на одном языке, средняя, в моем представлении, это 100+ человек. Нужно было придумать способ как собрать данные со всех виндовых машин и серверов, зная их IP и учетную запись доменного администратора, но при этом не устанавливая на каждую из них какой-то софт. На помощь приходит интерфейс WMI. Windows Management Instrumentation (WMI) в дословном переводе — инструментарий управления Windows. WMI — это одна из базовых технологий для централизованного управления и слежения за работой различных частей компьютерной инфраструктуры под управлением платформы Windows. Взято из вики. Далее пришлось опять повозиться, с тем, чтобы собрать wmic (это клиент WMI) для Debian. После того как все было готово оставалось просто опрашивать через wmic нужные узлы на предмет нужной информации. Через WMI можно достать с Windows компьютера почти любую информацию, и более того, через него можно еще и управлять компьютером, ну, например, отправить в перезагрузку. Так появился сбор информации о Windows станциях и серверах в нашей системе. Плюсом к этому шла и текущая информация о текущих показателях загруженности системы. Их мы запрашиваем почаще, а информацию по железу пореже. После этого, проводить аудит стало немного приятней.

Uamuzi wa usambazaji wa programu

Sisi wenyewe tunatumia mfumo kila siku, na huwa wazi kwa kila mfanyakazi wa kiufundi. Na tulifikiri kwamba tunaweza kushiriki na wengine kile ambacho tayari tunacho. Mfumo ulikuwa bado haujawa tayari kusambazwa. Mengi ilibidi kufanyiwa kazi upya ili toleo la ndani ligeuke kuwa SaaS. Hizi ni pamoja na mabadiliko katika vipengele mbalimbali vya kiufundi vya mfumo (miunganisho ya mbali, huduma ya usaidizi), uchanganuzi wa moduli za utoaji leseni, ugawaji wa hifadhidata za wateja, kuongeza kila huduma, na uundaji wa mifumo ya kusasisha kiotomatiki kwa sehemu zote. Lakini hii itakuwa sehemu ya pili ya kifungu hicho.