🥇З аўтсорса ў распрацоўку (Частка 1)

Усім прывітанне, мяне клічуць Сяргей Емяльянчык. Я з'яўляюся кіраўніком кампаніі Аўдыт-Тэлекам, галоўным распрацоўшчыкам і аўтарам сістэмы Veliam. Вырашыў напісаць артыкул аб тым, як мы з сябрам стваралі аўтсорсінгавую кампанію, напісалі праграмнае забеспячэнне для сябе і пасля пачалі распаўсюджваць яго ўсім жадаючым па сістэме SaaS. Аб тым, як я катэгарычна не верыў у тое, што гэта магчыма. У артыкуле будзе не толькі апавяданне, але і тэхнічныя падрабязнасці таго, як ствараўся прадукт Veliam. Уключаючы некаторыя кавалкі зыходнага кода. Раскажу пра тое, якія памылкі рабілі і як іх потым выпраўлялі. Былі сумневы, ці публікаваць такі артыкул. Але я падумаў, што лепш зрабіць гэта, атрымаць фідбэк і выправіцца, чым не публікаваць артыкул і думаць аб тым, што было б калі…

перадгісторыя

Працаваў я ў адной кампаніі ІТ супрацоўнікам. Кампанія была вельмі вялікай з разгалінаванай сеткавай структурай. Не буду спыняцца на сваіх службовых абавязках, скажу толькі, што ў іх сапраўды не ўваходзіла распрацоўка чагосьці.

У нас быў маніторынг, але чыста з акадэмічнай цікавасці хацелася паспрабаваць напісаць свой найпросты. Ідэя была такая: хацелася, каб гэта было ў вэбе, каб можна было лёгка без усталёўкі якіх-небудзь кліентаў зайсці і паглядзець, што адбываецца з сеткай з любой прылады, уключаючы мабільную прыладу праз Wi-Fi, а яшчэ вельмі хацелася хутка разумець у якім памяшканні размешчана абсталяванне якое "захандріла", т.я. былі вельмі цвёрдыя патрабаванні да часу рэагавання на падобныя праблемы. У выніку ў галаве нарадзіўся план напісаць прасценькую вэб старонку, на якой быў фонам jpeg са схемай сеткі, выразаць на гэтым малюнку самі прылады з іх IP адрасамі, а па-над карцінкі ў патрэбных каардынатах паказваць ужо дынамічны кантэнт у выглядзе зялёнага або мігатлівага чырвонага IP адрасы. Задача пастаўлена, пачынаем.

Раней я займаўся праграмаваннем на Delphi, PHP, JS і вельмі павярхоўна C++. Даволі нядрэнна ведаю працу сетак. VLAN, Routing (OSPF, EIGRP, BGP), NAT. Гэтага было дастаткова для таго, каб напісаць прататып прымітыўнага маніторынгу самастойна.

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

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

Так-так, праца з БД у той момант таксама для мяне была не засвоена. Я не ведаў, што можна раўналежваць працэсы, і праход па ўсіх вузлах сеткі займаў працяглы час, т.к. гэта адбывалася ў адну плынь. Асабліва праблемы ўзнікалі тады, калі некалькі вузлоў былі недаступныя, т.я. кожны з іх затрымліваў на сабе скрыпт на 300 мс. На баку кліента была простая зацыкленая функцыя, якая з інтэрвалам некалькі секунд спампоўвала абноўленую інфармацыю з сервера Ajax запытам і абнаўляла інтэрфейс. Ды і далей пасля трох няўдалых пінгаў запар, калі на кампутары была адкрыта інтэрнэт старонка з маніторынгам, гуляла вясёленькая кампазіцыя.

Калі ўсё атрымалася, я вельмі натхніўся выніку і думаў, што можна прыкруціць туды яшчэ (у сілу сваіх ведаў і магчымасцяў). Але мне заўсёды не падабаліся сістэмы з мільёнам графікаў, якія як я тады лічыў, ды і лічу дагэтуль, у большасці выпадкаў непатрэбнымі. Жадаў туды прыкручваць толькі тое, што мне рэальна бы дапамагала ў працы. Дадзены прынцып дагэтуль захоўваецца як асноватворны пры распрацоўцы Veliam. Далей, я зразумеў, што было б вельмі класна, калі б не трэба было трымаць адкрытым маніторынг і ведаць аб праблемах, а калі яна здарылася, ужо тады адчыняць старонку і глядзець дзе гэты праблемны вузел сеткі размешчаны і што з ім далей рабіць. Электронную пошту неяк тады не чытаў, проста не карыстаўся. Натыкнуўся ў інтэрнэце, што ёсць СМС шлюзы, на якія можна адправіць GET або POST запыт, і яны дашлюць мне на мабільны тэлефон СМС з тэкстам, які я напішу. Я адразу зразумеў, што вельмі хачу гэтага. І пачаў вывучаць дакументацыю. Праз некаторы час мне ўдалося, і зараз я атрымліваў смс аб праблемах на сетцы на мабільнік з назвай "ўпаў аб'екта". Хоць сістэма і была прымітыўнай, але яна была напісана мною самім, а самае галоўнае, што мяне тады матывавала да яе развіцця - гэта тое, што гэта прыкладная праграма, якая рэальна дапамагае мне ў працы.

І вось надышоў дзень, калі на працы зваліўся адзін з інтэрнэт-каналаў, а мой маніторынг мне ніяк не даў пра гэта зразумець. Бо гуглаўскія DNS да гэтага часу выдатна пінгаваліся. Нетутэйша час падумаць, як можна маніторыць, што канал сувязі жывы. Былі розныя ідэі, як гэта зрабіць. Не да ўсяго абсталявання ў мяне быў доступ. Прыходзілася прыдумаць як мага разумець які з каналаў жывы, але пры гэтым не маючы магчымасці якія-небудзь выявай паглядзець гэта на самім сеткавым абсталяванні. Тады калега падкінуў ідэю, што магчыма, трасіроўка маршруту да публічных сервераў можа адрознівацца ў залежнасці ад таго па якім канале сувязі зараз ажыццяўляецца выхад у інтэрнэт. Праверыў, так і аказалася. Былі розныя маршруты пры трасіроўцы.

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

Так з'явіўся яшчэ адзін скрыпт, а дакладней трасіроўка навошта-то была дададзеная ў канец таго ж скрыпту, які пінгаваў усе прылады ў сетцы. Бо гэта яшчэ адзін доўгі працэс, які выконваўся ў тым жа струмені і тармазіў працу ўсяго скрыпту. Але тады гэта не было так відавочна. Але так ці інакш, ён рабіў сваю справу, у кодзе было цвёрда прапісана якая павінна была быць трасіроўка ў кожнага з каналаў. Так стала працаваць сістэма, якая ўжо маніторыла (гучна сказана, бо не было збору нейкіх метрык, а проста пінг) сеткавыя прылады (роўтары, камутатары, wi-fi і г.д.) і каналы сувязі з навакольным светам . Спраўна прыходзілі СМС і на схеме было заўсёды добра бачна дзе праблема.

Далей, у паўсядзённай працы даводзілася займацца кросіроўкай. І кожны раз заходзіць на Cisco камутатары для таго, каб паглядзець які інтэрфейс трэба выкарыстоўваць надакучыла. Як было б класна тыкнуць на маніторынгу на аб'ект і ўбачыць спіс яго інтэрфейсаў з апісаннямі. Гэта б зэканоміла мне час. Прычым у гэтай схеме не трэба было б запускаць Putty ці SecureCRT уводзіць улікі і каманды. Проста тыцнуў у маніторынгу, убачыў, што трэба і пайшоў рабіць сваю працу. Пачаў шукаць як мага ўзаемадзейнічаць з камутатарамі. На ўскідку трапілася адразу 2 варыянты: SNMP ці заходзіць на камутатар па SSH, уводзіць неабходныя мне каманды і парсіць вынік. SNMP отмел з-за складанасці рэалізацыі, мне не цярпелася атрымаць вынік. з SNMP прыйшлося б доўга капацца ў MIB, на аснове гэтых дадзеных фармаваць дадзеныя аб інтэрфейсах. Ёсць выдатная каманда ў CISCO

show interface status

Яна паказвае, якраз тое, што мне трэба для кросіровак. Да чаго мучыцца з SNMP, калі я проста хачу бачыць выснову гэтай каманды, падумаў я. Праз некаторы час я рэалізаваў такую магчымасць. Націскаў на вэб старонцы на аб'ект. Спрацоўвала падзея, па якім AJAXам кліент звяртаўся да сервера, а той у сваю чаргу падлучаўся па SSH да патрэбнага мне камутатара (уліковыя дадзеныя былі зашытыя ў код, не было жадання акультурваць, рабіць нейкія асобныя менюшкі дзе можна было б змяняць улікі з інтэрфейсу , патрэбен быў вынік і барзджэй) уводзіў туды вышэйпаказаную каманду і аддаваў зваротна ў браўзэр. Так я пачаў бачыць па адным кліку мышкі інфармацыю па інтэрфейсах. Гэта было вельмі зручна, асабліва калі даводзілася глядзець гэтую інфармацыю на розных камутатарах адразу.

Маніторынгу каналаў на аснове трасіроўкі аказаўся ў выніку не самай лепшай ідэяй, т.я. часам праводзіліся працы на сетцы, і трасіроўка магла мяняцца і маніторынг пачынаў мне лямантаваць аб тым, што ёсць праблемы з каналам. Але патраціўшы кучу часу на аналіз, разумеў, што ўсе каналы працуюць, а мой маніторынг мяне падманвае. У выніку, папытаў калегаў, якія кіравалі каналаўтваральнымі камутатарамі дасылаць мне проста syslog, калі змяняўся стан бачнасці суседзяў (neighbor). Адпаведна, гэта было значна прасцей, хутчэй і праўдзівей, чым трасіроўка. Прыйшла падзея віду neighbor lost, і я адразу раблю апавяшчэнне аб падзенні канала.

Далей, з'явіліся высновы па кліку на аб'ект яшчэ некалькі каманд і дадаўся SNMP для збору некаторых метрык, ну і на гэтым па вялікім рахунку ўсё. Больш за сістэма ніяк не развівалася. Яна рабіла ўсё, што мне было трэба, гэта быў добры інструмент. Шматлікія чытачы, мусіць, мне скажуць, што для рашэння гэтых задач ужо куча софту ў інтэрнэце. Але насамрэч, бясплатных такіх прадуктаў я тады не нагугліў і ўжо вельмі жадалася развіваць скіл праграмавання, а што можа лепш штурхаць да гэтага, чым рэальная прыкладная задача. На гэтым першая версія маніторынгу была скончаная і больш не мадыфікавалася.

Стварэнне кампаніі Аўдыт-Тэлекам

Ішоў час, я пачаў падзарабляць паралельна ў іншых кампаніях, балазе працоўны графік дазваляў мне гэта рабіць. Калі працуеш у розных кампаніях, вельмі хутка расце скіл у розных галінах, добра развіваецца кругагляд. Ёсць кампаніі, у якіх, як прынята казаць, ты і швец, і жнец, і на дудзе ігрок. З аднаго боку, гэта складана, з іншага боку калі не ленавацца, ты становішся адмыслоўцам шырокага профіля і гэта дазваляе хутчэй і эфектыўней вырашаць задачы таму, што ты ведаеш, як працуе сумежная вобласць.

Мой сябар Павел (таксама айцішнік) увесь час спрабаваў мяне падштурхнуць на свой бізнэс. Была незлічоная колькасць ідэй з рознымі варыянтамі сваёй справы. Гэта абмяркоўвалася не адзін год. І ў выніку ні да чаго не павінна было прыйсці таму, што я скептык, а Павел фантазёр. Кожны раз, калі ён прапаноўваў нейкую ідэю, я заўсёды ў яе не верыў і адмаўляўся ўдзельнічаць. Але вельмі нам хацелася адкрыць свой бізнэс.

Нарэшце, мы змаглі знайсці варыянт, які задавальняе нас абодвух і заняцца тым, што мы ўмеем. У 2016 годзе, мы вырашылі стварыць IT кампанію, якая будзе дапамагаць бізнэсу з рашэннем IT задач. Гэта разгортванне ІТ сістэм (1С, сервер тэрміналаў, паштовы сервер і г.д.), іх суправаджэнне, класічны HelpDesk для карыстальнікаў і адміністраванне сеткі.

Шчыра кажучы, у момант стварэння кампаніі, я ў яе не верыў прыкладна на 99,9%. Але нейкім чынам Павел змог мяне прымусіць паспрабаваць, і забягаючы наперад, ён меў рацыю. Мы скінуліся з Паўлам па 300 000 рублёў, зарэгістравалі новае ТАА "Аўдыт-Тэлекам", знялі маленечкі офіс, нарабілі стромкіх візітовак, ну ўвогуле як і, мусіць, большасць неспрактыкаваных, пачаткоўцаў бізнэсмэнаў і пачалі шукаць кліентаў. Пошук кліентаў - гэта наогул асобная гісторыя. Магчыма мы напішам асобны артыкул у рамках карпаратыўнага блога, калі гэта камусьці будзе цікава. Халодныя званкі, улёткі, і іншае. Вынікаў гэта не давала ніякіх. Як я ўжо чытаю зараз, з многіх гісторый аб бізнэсе, так ці інакш шмат што залежыць ад поспеху. Нам пашанцавала. і літаральна праз пару тыдняў пасля стварэння фірмы, да нас звярнуўся мой брат Уладзімір, які і прывёў да нас першага кліента. Не буду стамляць дэталямі працы з кліентамі, артыкул не пра гэта, скажу толькі, што мы паехалі на аўдыт, выявілі крытычныя месцы і гэтыя месцы зламаліся пакуль прымалася рашэнне аб тым ці супрацоўнічаць з намі на сталай аснове ў якасці аўтсорсераў. Пасля гэтага адразу было прынятае станоўчае рашэнне.

Далей, у асноўным па сарафане праз знаёмых, пачалі з'яўляцца і іншыя кампаніі на абслугоўванні. Helpdesk быў у адной сістэме. Падлучэнні да сеткавага абсталявання і серверам у іншай, а дакладней у каго як. Нехта захоўваў ярлыкі, нехта карыстаўся адраснымі кнігамі RDP. Маніторынг - яшчэ адна асобная сістэма. Працаваць камандзе ў разрозненых сістэмах вельмі няёмка. Губляецца з выгляду важная інфармацыя. Ну, напрыклад, стаў недаступны тэрмінальны сервер у кліента. Адразу паступаюць заяўкі ад карыстальнікаў гэтага кліента. Спецыяліст службы падтрымкі заводзіць заяўку (яна паступіла па тэлефоне). Калі б інцыдэнты і заяўкі рэгістраваліся ў адной сістэме, то спецыяліст падтрымкі адразу бачыў бы ў чым праблема ў карыстальніка і сказаў яму пра гэта, паралельна ўжо падключаючыся да патрэбнага аб'екта для адпрацоўкі сітуацыі. Усё ў курсе тактычнай абстаноўкі і зладжана працуюць. Мы не знайшлі такой сістэмы, дзе ўсё гэта аб'яднана. Стала зразумела, што час рабіць свой прадукт.

Працяг працы над сваёй сістэмай маніторынгу

Зразумела было, што тая сістэма, якая была напісана раней, зусім не падыходзіць пад бягучыя задачы. Ні ў плане функцыяналу ні ў плане якасці. І было прынятае рашэнне пісаць сістэму з нуля. Графічна гэта павінна было выглядаць зусім інакш. Гэта павінна была быць іерархічная сістэма, каб можна было хутка і зручна адкрываць патрэбны аб'ект у патрэбнага кліента. Схема як у першай версіяй была ў бягучым выпадку абсалютна не апраўдана, т.я. кліенты розныя і зусім не мела значэння ў якіх памяшканнях стаіць абсталяванне. Гэта ўжо было перакладзена на дакументацыю.

Такім чынам, задачы:

Іерархічная структура;
Нейкая серверная частка, якую можна змясціць у кліента ў выглядзе віртуальнай машыны для збору неабходных нам метрык і пасылкі на цэнтральны сервер, які будзе ўсё гэта абагульняць і паказваць нам;
Абвесткі. Такія, якія нельга прапусціць, т.я. на той момант не было магчымасці камусьці сядзець і толькі глядзець у манітор;
Сістэма заявак. Пачалі з'яўляцца кліенты, у якіх мы абслугоўвалі не толькі сервернае і сеткавае абсталяванне, але і працоўныя станцыі;
Магчымасць хутка падлучацца да сервераў і абсталяванню з сістэмы;

Задачы пастаўлены, пачынаем пісаць. Адначасна апрацоўваючы заяўкі ад кліентаў. На той момант нас ужо было 4 чалавекі. Пачалі пісаць адразу абедзве часткі і цэнтральны сервер, і сервер для ўстаноўкі да кліентаў. Да гэтага моманту Linux быў ужо не чужым для нас і было прынятае рашэнне, што віртуальныя машыны, якія будуць стаяць у кліентаў будуць на Debian. Не будзе ніякіх усталёўшчыкаў, проста зробім праект сервернай часткі на адной пэўнай віртуальнай машыне, а потым проста будзем яе кланаваць да патрэбнага кліента. Гэта была чарговая памылка. Пазней стала зразумела, што ў такой схеме абсалютна не прапрацаваны механізм апдэйтаў. Г.зн. мы дадавалі нейкую новую фічу, а потым была цэлая праблема распаўсюджваць яе на ўсе серверы кліентаў, але да гэтага вернемся пазней, усё па парадку.

Зрабілі першы прататып. Ён умеў пінгаваць неабходныя нам сеткавыя прылады кліентаў і серверы і дасылаць гэтыя дадзеныя да нас на цэнтральны сервер. А ён у сваю чаргу абнаўляў гэтыя дадзеныя ў агульнай масе на цэнтральным сэрвэры. Я тут буду пісаць не толькі гісторыю пра тое, як і што ўдавалася, але і якія дылетанцкія памылкі рабіліся і як потым даводзілася за гэта плаціць часам. Дык вось, усё дрэва аб'ектаў захоўвалася ў адным адзіным файле ў выглядзе серыялізаванага аб'екта. Пакуль мы падключылі да сістэмы некалькі кліентаў, усё было больш-менш нармальна, хаця і часам былі нейкія артэфакты, якія былі зусім незразумелыя. Але калі мы падлучылі да сістэмы дзясятак сервераў, пачаліся дзеяцца цуды. Часам, незразумела з якой прычыны, усе аб'екты ў сістэме проста знікалі. Тут важна адзначыць, што серверы, якія былі ў кліентаў, дасылалі дадзеныя на цэнтральны сервер кожныя некалькі секунд з дапамогай POST запыту. Уважлівы чытач і дасведчаны праграміст ужо здагадаўся, што ўзнікала праблема множнага доступу да таго самага файла ў якім захоўваўся серыялізаваны аб'ект з розных струменяў адначасова. І якраз, калі гэта адбывалася, праяўляліся цуды са знікненнем аб'ектаў. Файл проста станавіўся пустым. Але гэта ўсё выявілася не адразу, а толькі падчас эксплуатацый з некалькімі серверамі. За гэты час быў дададзены функцыянал па сканіраванні партоў (серверы дасылалі на цэнтральны не толькі інфармацыю аб даступнасці прылад, але і аб адкрытых на іх партах). Зроблена гэта было шляхам выкліку каманды:

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

вынікі часта былі няправільнымі і выконвалася сканіраванне вельмі доўга. Зусім забыўся пра пінг, ён выконваўся праз fping:

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

Гэта ўсё таксама не было паралелена і таму працэс быў вельмі доўгі. Пазней у fping ужо перадаваўся адразу ўвесь спіс неабходных для праверкі IP адрасоў і зваротна атрымалі гатовы спіс тых, хто адгукнуўся. У адрозненне ад нас, fping умеў паралеліць працэсы.

Яшчэ адной частай руціннай працай была настройка нейкіх сэрвісаў праз WEB. Ну, напрыклад, ECP ад MS Exchange. Па вялікім рахунку, гэта ўсяго толькі спасылка. І мы вырашылі, што трэба даць магчымасць нам дадаваць такія спасылкі прама ў сістэму, каб не шукаць у дакументацыі ці яшчэ недзе ў закладках як зайсці на ECP канкрэтнага кліента. Так з'явілася паняцце рэсурсных спасылак для сістэмы, іх функцыянал даступны і дагэтуль і не зведаў змен, ну амаль.

Праца рэсурсных спасылак у Veliam

Выдаленыя падключэнні

Вось як гэта выглядае ў справе ў бягучай версіі Veliam

Адной з задач было хуткае і зручнае падлучэнне да сервераў, якіх стала ўжо шмат (не адна сотня) і перабіраць мільёны загадзя захаваных RDP цэтлікаў было вельмі няёмкім. Патрэбна была прылада. Ёсць у інтэрнэце софт, які ўяўляе з сябе нешта тыпу адраснай кнігі для такіх RDP падлучэнняў, але яны не інтэграваныя з сістэмай маніторынгу, і ўлікі не захаваць. Кожны раз уводзіць улікі для розных кліентаў гэта сапраўднае пекла, калі ў дзень ты падлучаешся не адзін дзясятак разоў на розныя серверы. З SSH справы ідуць ледзь лепш, ёсць шмат добрага софту у якім ёсць магчымасць раскладваць такія падлучэнні па татачках і запамінаць улікі ад іх. Але ёсць 2 праблемы. Першая - для падлучэнняў RDP і SSH мы не знайшлі адзіную праграму. Другая – калі я ў нейкі момант не знаходжуся за сваім кампутарам і мне трэба хутка падключыцца, ці я проста пераўсталяваў сістэму, мне давядзецца лезці ў дакументацыю, каб глядзець улік ад гэтага кліента. Гэта няёмка і пустая трата часу.

Патрэбная нам іерархічная структура па серверах кліентаў ужо мелася ў нашым унутраным прадукце. Трэба было толькі прыдумаць як прыкруціць туды хуткія падключэнні да патрэбнага абсталявання. Для пачатку, хаця б унутры сваёй сеткі.

З улікам таго, што кліентам у нашай сістэме выступаў браўзэр, які не мае доступу да лакальных рэсурсаў кампутара, каб проста ўзяць і нейкай камандай запусціць патрэбнае нам прыкладанне, было прыдумана зрабіць усё праз "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) сайтамі ўсё проста, такія аб'екты проста адчыняліся ў браўзэры і ўсё. Зручна і практычна. Але гэта было шчасце толькі ва ўнутранай сетцы.

Так як пераважная колькасць праблем мы вырашалі выдалена з офіса, самым простым было зрабіць VPN'ы да кліентаў. І тады з нашай сістэмы можна было далучацца і да іх. Але ўсё роўна было некалькі няёмка. Для кожнага кліента трэба было трымаць на кожным кампутары кучу запомненых VPN злучэнняў і перад падлучэннем да які-небудзь, трэба было ўключаць які адпавядае VPN. Такім рашэннем мы карысталіся дастаткова працяглы час. Але колькасць кліентаў павялічваецца, колькасць VPN'аў таксама і ўсё гэта пачало напружваць і трэба было нешта з гэтым рабіць. Асабліва наварочваліся слёзы на вачах пасля пераўсталёўкі сістэмы, калі трэба было забіваць зноўку дзясяткі VPN падлучэнняў у новым профілі вінды. Хопіць гэта цярпець, сказаў я і пачаў думаць, што можна з гэтым зрабіць.

Так павялося, што ва ўсіх кліентаў у якасці маршрутызатараў былі прылады ўсім вядомай фірмы Mikrotik. Яны вельмі функцыянальныя і зручныя для выканання практычна любых задач. З мінусаў - іх "зганяюць". Мы гэтую праблему вырашылі проста, зачыніўшы ўсе доступы звонку. Але трэба было неяк мець да іх доступ, не прыязджаючы да кліента на месца, т.я. гэта доўга. Мы проста зрабілі да кожнага такога мікратыка тунэлі і вылучылі іх у асобны пул. без якой-небудзь маршрутызацыі, каб не было аб'яднання сваёй сеткі з сеткамі кліентаў і іх сетак паміж сабой.

Нарадзілася ідэя зрабіць так, каб пры націску на патрэбны мне аб'ект у сістэме, цэнтральны сервер маніторынгу, ведаючы ўліковыя запісы ад SSH усіх кліенцкіх мікратыкаў, падлучаўся да патрэбнага, ствараў правіла пракіду да патрэбнага хаста з патрэбным портам. Тут адразу некалькі момантаў. Рашэнне не ўніверсальнае - будзе працаваць толькі для мікратыка, як так сінтаксіс каманд ва ўсіх роўтэраў свой. Гэтак жа такія пракіды потым трэба было неяк выдаляць, а серверная частка нашай сістэмы па ісце не магла адсочваць якія-небудзь чынам скончыў ці я свой сеанс працы па RDP. Ну і такі пракід - гэта дзірышча для кліента. А за ўніверсальнасцю мы і не гналіся, т.к. прадукт выкарыстоўваўся толькі ўнутры нашай кампаніі і выводзіць яго ў паблік нават думак не было.

Кожная з праблем была вырашана па-свойму. Калі стваралася правіла, то пракід гэты быў даступны толькі для аднаго канкрэтнага знешняга IP адраса (з якога было ініцыялізавана падлучэнне). Так што дзюры ў бяспецы ўдалося пазбегнуць. Але пры кожным такім падключэнні, дадавалася правіла на мікрацік на старонку NAT і не чысцілася. А ўсім вядома, што чым больш там правіл, тым мацней нагружаецца працэсар роўтара. Ды і ў цэлым, я не мог прыняць такое, што я зайду аднойчы на нейкі мікрацік, а тамака сотні мёртвых нікому не патрэбных правілаў.

Раз наш сервер не можа адсочваць стан падключэння, няхай мікратык адсочвае іх сам. І напісаў скрыпт, які ўвесь час адсочваў усе правілы пракіду з вызначаным апісаннем (description) і правяраў ці ёсць TCP падлучэнне падыходнае правіла. Калі такога не было ўжо некаторы час, тое верагодна падлучэнне ўжо завершанае і пракід гэты можна выдаляць. Усё атрымалася, скрыпт добра працаваў.

Дарэчы вось ён:

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

Напэўна яго можна было зрабіць прыгажэй, хутчэй і г.д., але ён працаваў, не нагружаў мікратыкі і выдатна спраўляўся. Мы нарэшце змаглі падлучацца да сервераў і сеткавага абсталявання кліентаў проста адным націскам мышкі. Не паднімаючы VPN і не ўводзячы паролі. З сістэмай стала рэальна вельмі зручна працаваць. Час на абслугоўванне скарачалася, а ўсе мы марнавалі час на працу, а не на тое каб далучыцца да патрэбных аб'ектаў.

Рэзервовае капіраванне Mikrotik

У нас было наладжана рэзервовае капіраванне ўсіх мікратыкаў на FTP. І ў цэлым усё было добра. Але калі трэба было дастаць бэкап, але трэба было адчыняць гэты FTP і шукаць яго тамака. Сістэма дзе ўсе роўтэры заведзены ў нас ёсць, мець зносіны з прыладамі па SSH мы ўмеем. Чаго б нам не зрабіць так, што сістэма сама будзе штодня забіраць з усіх мікратыкаў бэкапы, падумаў я. І прыняўся рэалізоўваць. Падключыліся, зрабілі бэкап і забралі яго ў сховішча.

Код скрыпту на PHP для зняцця бэкапу з мікратыка:

<?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');

?>

Бэкап здымаецца ў двух відах - бінарнік і тэкставы канфіг. Бінарнік дапамагае хутка старыць патрэбны канфіг, а тэкставы дазваляе разумець, што трэба рабіць, калі адбылася вымушаная замена абсталявання і бінарнік на яго заліць нельга. У выніку атрымалі яшчэ адзін зручны функцыянал у сістэме. Прычым, пры даданні новых мікратыкаў не трэба было нічога наладжваць, проста дадаў аб'ект у сістэму і задаў для яго ўлік ад SSH. Далей сістэма сама займалася з'ёмам бэкапаў. У бягучай версіі SaaS Veliam гэтага функцыяналу пакуль няма, але хутка які портуецца яго.

Скрыны як гэта выглядала ва ўнутранай сістэме

Пераход на нармальнае захоўванне ў базе даных

Вышэй я ўжо пісаў аб тым, што з'яўляліся артэфакты. Часам проста знікаў увесь спіс аб'ектаў у сістэме, часам пры рэдагаванні аб'екта, інфармацыя не захоўвалася і даводзілася па тры разы пераназываць аб'ект. Гэта жудасна раздражняла ўсіх. Знікненне аб'ектаў адбывалася рэдка, і лёгка аднаўлялася шляхам узнаўлення гэтага самага файла, а вось фэйл пры рэдагаванні аб'ектаў гэта прамы было часта. Верагодна, я першапачаткова не зрабіў гэта праз БД таму, што ў розуме не ўкладвалася як мага дрэва з усімі сувязямі трымаць у плоскай табліцы. Яна ж плоская, а дрэва іерархічнае. Але добрае рашэнне множнага доступу, а пасля (пры ўскладненні сістэмы) і транзакцыйнага - гэта СКБД. Я ж, напэўна, не першы хто сутыкнуўся з гэтай праблемай. Палез гугліць. Аказалася, што ўжо ўсё прыдумана да мяне і ёсць некалькі алгарытмаў, якія будуюць дрэва з плоскай табліцы. Паглядзеўшы на кожны, я рэалізаваў адзін з іх. Але гэта ўжо была новая версія сістэмы, т.я. у сутнасці перапісваць з-за гэтага прыйшлося вельмі шмат. Вынік быў заканамерны, праблемы рандомных паводзін сістэмы сышлі. Хтосьці можа сказаць, што памылкі вельмі дылетанцкія (аднаструменныя скрыпты, захоўванне інфармацыі да якой быў множны адначасовы доступ з розных струменяў у файле і т.д.) у сферы распрацоўцы праграмнага забеспячэння. Можа так і ёсць, але мая асноўная праца была адміністраванне, а праграмаванне было пабочным для душы, і ў мяне проста не было досведу працы ў камандзе праграмістаў, там, дзе такія элементарныя рэчы мне падказалі б адразу старэйшыя таварышы. Таму я ўсе гэтыя шышкі набіваў самастойна, але вельмі добра засвоіў матэрыял. А яшчэ, свая справа – гэта і сустрэчы з кліентамі, і дзеянні накіраваныя на спробу раскруткі фірмы, і куча адміністрацыйных пытанняў усярэдзіне кампаній і шматлікае-многае іншае. Але так ці інакш, тое, што было ўжо – было запатрабавана. Хлопцы і я сам выкарыстоўвалі прадукт у паўсядзённай працы. Былі і адкрыта няўдалыя ідэі, і рашэнні, на якія было выдаткаваны час, а ў выніку стала зразумела, што гэта непрацоўная прылада і ім ніхто не карыстаўся і гэта не патрапіла ў Veliam.

Служба падтрымкі - HelpDesk

Не лішнім будзе згадаць як фармаваўся HelpDesk. Гэта ўвогуле асобная гісторыя, т.я. у Veliam гэта ўжо 3я зусім новая версія, якая адрозніваецца ад усіх папярэдніх. Цяпер гэта простая сістэма, інтуітыўна зразумелая без лішніх рушак і фінтыфлюшак з магчымасцю інтэгравацца з даменам, а таксама з магчымасцю доступу да гэтага ж профілю карыстальніка з любога месца па спасылцы з ліста. І што самае важнае, ёсць магчымасць з любой кропкі (дома я ці ў офісе) падлучыцца да заяўніка па VNC прама з заяўкі без VPN або пракідаў партоў. Раскажу, як мы да гэтага прыйшлі, што было да гэтага і якія жахлівыя рашэнні былі.

Мы падключаліся да карыстальнікаў праз усім вядомы TeamViewer. На ўсіх кампутарах, карыстальнікаў якіх мы абслугоўваем усталяваны ТБ. Першае, што мы зрабілі не так, і пасля прыбралі гэта - прывязка кожнага кліента ХД па жалезе. Як карыстач заходзіў у сістэму ХД для таго, каб пакінуць заяўку? Усім на кампутары, апроч ТБ была ўсталяваная адмысловая ўтыліта, напісаная на Lazarus (тут шматлікія акругляць вочы, і магчыма нават палезуць гугліць што гэта такое, але лепш за ўсё з кампіляваных моў я ведаў Delphi, а Lazarus гэта амаль тое ж самае, толькі бясплатнае). Увогуле карыстач запускаў у сябе адмысловы батнік, які запускаў гэтую ўтыліту, тая ў сваю чаргу счытвала HWID сістэмы і пасля гэтага запускаўся браўзэр і адбывалася аўтарызацыя. Нашто гэта было зроблена? У некаторых кампаніях, падлік абслугоўваных карыстальнікаў вядзецца паштучна, і кошт абслугоўвання за кожны месяц фарміруецца зыходзячы з колькасці людзей. Гэта зразумела, скажаце вы, але навошта прывязка да жалеза. Вельмі проста, некаторыя індывіды, прыходзілі дадому і рабілі з хатняга наўтбука заяўку ў стылі "зрабіце мне тут усё прыгожа". Апроч счытвання HWID сістэмы, утыліта выцягвала з рэестра бягучы ID Teamviewer'а і гэтак жа перадавала да нас. У Teamviewer ёсць API для інтэграцыі. І мы зрабілі гэтую інтэграцыю. Але была адна загваздка. Праз гэтыя API нельга падлучыцца да кампутара карыстача, калі ён відавочна не ініцыюе гэтую сесію і пасля спробы падлучыцца да яго ён павінен яшчэ націснуць "пацвердзіць". На той момант, нам падалося лагічным, што без попыту карыстальніка ніхто не павінен падключацца, а калі чалавек за кампутарам, то ён і сесію ініцыюе і сцвярджальна адкажа на запыт выдаленага падключэння. Усё аказалася не так. Заяўнікі забывалі націснуць ініцыяцыю сесіі, і даводзілася ім у тэлефоннай размове гэта казаць. Гэта марнавала час і нервавала абодва бакі працэсу. Больш за тое, зусім не рэдкасць такія моманты, калі чалавек пакідае заяўку, але падключыцца дазваляе толькі тады, калі ён ідзе на абед. Бо праблема не крытычная і не жадае, каб яго працоўны працэс перарываўся. Адпаведна, ён не націсне ніякіх кнопак для дазволу далучыцца. Так і з'явіўся дадатковы функцыянал пры аўтарызацыі ў HelpDesk – счытванне ID Teamviwer'а. Мы ведалі пастаянны пароль, які выкарыстоўваўся пры ўстаноўцы Teamviwer. Дакладней, яго ведала толькі сістэма, бо ён быў ушыты ва ўсталёўшчык, і ў нашу сістэму. Адпаведна была кнопка падлучэння з заяўкі па націску на якую не трэба было нічога чакаць, а адразу адчыняўся Teamviewer і адбываўся канэкт. У выніку стала два віды магчымых падключэнняў. Праз афіцыйны API Teamviewer і наш самапальны. Да майго здзіўлення, першым амаль адразу перасталі карыстацца, хоць і было ўказанне карыстацца ім толькі ў адмысловых выпадках і калі карыстач сам дае на гэта дабро. Усё ж бяспеку зараз падавай. Але аказалася, што заяўнікам гэта не трэба. Яны ўсё абсалютна не супраць, што да іх падлучаюцца без кнопкі пацверджання.

Пераход на шматструменнасць у Linux

Даўно ўжо пачало напрошвацца пытанне паскарэння праходу сканара сеткі на прадмет адкрытасці загадзя вызначанага спісу партоў і простая прапінгаванне аб'ектаў сеткі. Тут само сабой першае рашэнне, якое прыходзіць у галаву - шматструменнасць. Бо асноўны час, які марнуецца на пінг - гэта чаканне вяртання пакета, і наступны пінг не можа пачацца пакуль не вернецца папярэдні пакет, у кампаніях у якіх нават 20 + сервераў плюс сеткавага абсталявання гэта ўжо працавала даволі павольна. Іста ў тым, што адзін пакет можа і знікнуць, не апавяшчаць жа аб гэтым адразу сістэмнага адміністратара. Ён проста такі спам вельмі хутка перастане ўспрымаць. Значыць трэба пінгаваць кожны аб'ект яшчэ не адзін раз перш чым рабіць выснову аб недаступнасці. Калі не ўдавацца ўжо зусім у падрабязнасці, то трэба паралеліць таму, што калі гэтага не зрабіць, то хутчэй за ўсё, сістэмны адміністратар будзе даведвацца аб праблеме ад кліента, а не ад сістэмы маніторынгу.

Сам па сабе PHP са скрынкі не ўмее шматструменнасць. Умее шматпрацэснасць, можна форкаць. Але, у мяне ўжо ў сутнасці быў напісаны механізм апытання і хацелася зрабіць так, каб я адзін раз лічыў усе патрэбныя мне вузлы з БД, прапінгаваў усё адразу, дачакаўся адказу ад кожнага і толькі пасля гэтага адразу пісаў дадзеныя. Гэта эканоміць на колькасці запытаў на чытанне. У гэтую ідэю добра ўкладвалася шматструменнасць. Для PHP ёсць модуль PThreads, які дазваляе рабіць рэальную шматструменнасць, праўда прыйшлося ладна павазіцца, каб наладзіць гэта на PHP 7.2, але справа была зроблена. Сканіраванне партоў і пінг сталі хуткімі. І замест, напрыклад 15 секунд на круг раней, на гэты працэс стала сыходзіць 2 секунды. Гэта быў добры вынік.

Хуткі аўдыт новых кампаній

Як з'явіўся функцыянал збору розных метрык і характарыстык жалеза? Усё проста. Нам часам замаўляюць проста аўдыт бягучай ІТ інфраструктуры. Ну і тое ж самае неабходна для паскарэння правядзення аўдыту новага кліента. Трэба было нешта, што дазволіць прыйсці ў сярэднюю ці буйную кампанію і хутка зарыентавацца, што ў іх увогуле ёсць. Пінг ва ўнутранай сетцы блакуюць, на мой погляд, толькі тыя, хто сам сабе хоча ўскладніць жыццё, і такіх па нашым досведзе няшмат. Але і такія сустракаюцца. Адпаведна, можна хутка адсканаваць сеткі на наяўнасць прылад простым пінг. Далей можна іх дадаць і прасканаваць на прадмет адчыненых партоў, якія нас цікавяць. У сутнасці гэты функцыянал ужо быў, неабходна толькі было дадаць каманду з цэнтральнага сервера на падначалены, каб той прасканаваў зададзеныя сеткі і дадаў у спіс усё што знойдзе. Забыўся згадаць, меркавалася, што ў нас ужо ёсць гатовая выява з наладжанай сістэмай (падпарадкаваны сервер маніторынгу) які мы маглі проста раскачаць у кліента пры аўдыце і падчапіць яго да свайго воблака.

Але вынік аўдыту звычайна ўключае ў сябе кучу рознай інфармацыі і адна з іх гэта - што наогул за прылады ў сетцы. У першую чаргу нас цікавілі Windows серверы і працоўныя станцыі Windows у складзе дамена. Так як у сярэдніх і буйных кампаніях адсутнасць дамена - гэта, напэўна, выключэнне з правілаў. Што б казаць на адной мове, сярэдняя, у маім уяўленні, гэта 100+ чалавек. Трэба было прыдумаць спосаб як сабраць дадзеныя са ўсіх віндовых машын і сервераў, ведаючы іх IP і ўліковы запіс даменнага адміністратара, але пры гэтым не ўсталёўваючы на кожную з іх нейкі софт. На дапамогу прыходзіць інтэрфейс WMI. Windows Management Instrumentation (WMI) у даслоўным перакладзе – інструментар кіравання Windows. WMI – гэта адна з базавых тэхналогій для цэнтралізаванага кіравання і сачэння за працай розных частак кампутарнай інфраструктуры пад кіраваннем платформы Windows. Узята з вікі. Далей прыйшлося зноў павазіцца, з тым, каб сабраць wmic (гэта кліент WMI) для Debian. Пасля таго як усё было гатова заставалася проста апытваць праз wmic патрэбныя вузлы на прадмет патрэбнай інфармацыі. Праз WMI можна дастаць з Windows кампутара амаль любую інфармацыю, і больш за тое, праз яго можна яшчэ і кіраваць кампутарам, ну, напрыклад, адправіць у перазагрузку. Так з'явіўся збор інфармацыі аб Windows станцыях і серверах у нашай сістэме. Плюсам да гэтага ішла і бягучая інфармацыя аб бягучых паказчыках загружанасці сістэмы. Іх мы запытваем часцей, а інфармацыю па жалезе радзей. Пасля гэтага, праводзіць аўдыт стала крыху прыемней.

Рашэнне аб распаўсюджванні ПЗ

Мы самі штодня карыстаемся сістэмай, і яна заўсёды адчыненая ў кожнага тэхнічнага супрацоўніка. І мы падумалі, што можна і зь іншымі падзяліцца тым, што ўжо ёсьць. Сістэма была яшчэ зусім не гатова да таго, каб яе распаўсюджваць. Неабходна было перапрацаваць вельмі шматлікае, што б лакальная версія ператварылася ў SaaS. Гэта і змены розных тэхнічных аспектаў у працы сістэмы (выдаленыя падлучэнні, служба падтрымкі), і аналізу модуляў на прадмет ліцэнзавання, і шаліраванне баз дадзеных кліентаў, і маштабаванне кожнага з сэрвісаў, і распрацоўка сістэм аўтаабнаўленняў для ўсіх частак. Але пра гэта будзе другая частка артыкула.

абнаўленне

другая частка

Крыніца: habr.com

З аўтсорса ў распрацоўку (Частка 1)