Здраво свима, моје име је Сергеи Емелианцхик. Ја сам на челу компаније Аудит-Телецом, главног програмера и аутора система Велиам. Одлучио сам да напишем чланак о томе како смо мој пријатељ и ја створили компанију за спољне послове, писали софтвер за себе и потом почели да га дистрибуирамо свима преко СааС система. О томе како категорички нисам веровао да је то могуће. Чланак ће садржати не само причу, већ и техничке детаље о томе како је настао производ Велиам. Укључујући неке делове изворног кода. Касније ћу вам рећи које смо грешке направили и како смо их исправили. Било је недоумица да ли објавити такав чланак. Али мислио сам да је боље да то урадим, добијем повратне информације и побољшам се, него да не објавим чланак и размислим шта би се десило да...
praistorija
Радио сам у једној фирми као ИТ службеник. Компанија је била прилично велика са широком мрежном структуром. Нећу се задржавати на својим радним обавезама, само ћу рећи да оне дефинитивно нису укључивале развој било чега.
Имали смо мониторинг, али чисто из академског интереса сам желео да покушам да напишем свој најједноставнији. Идеја је била следећа: желео сам да буде на вебу, тако да могу лако да уђем без инсталирања клијената и да видим шта се дешава са мрежом са било ког уређаја, укључујући мобилни уређај преко Ви-Фи мреже, а такође сам заиста желео је да брзо схвати шта се налази у просторији која је постала "мопеи" јер... постојали су веома строги захтеви за време одговора на такве проблеме. Као резултат тога, у мојој глави се родио план да напишем једноставну веб страницу на којој је била јпег позадина са мрежним дијаграмом, исечем саме уређаје са њиховим ИП адресама на овој слици и прикажем динамички садржај на врху слику у траженим координатама у виду зелене или трепћуће црвене ИП адресе. Задатак је постављен, почнимо.
Раније сам програмирао у Делпхију, ПХП-у, ЈС-у и врло површно Ц++. Знам прилично добро како мреже раде. ВЛАН, рутирање (ОСПФ, ЕИГРП, БГП), НАТ. Ово ми је било довољно да сам напишем примитивни прототип за праћење.
Написал задуманное на PHP. Сервер Apache и PHP был на Windows јер Linux для меня в тот момент был чем-то непонятным и очень сложным, как оказалось позже, я сильно ошибался и во многих местах Linux куда проще Windows, но это тема отдельная и мы все знаем сколько холиваров на эту тему. Планировщик задач Windows дергал с небольшим интервалом (точно не помню, но что-то вроде одного раза в три секунды) PHP скрипт, который опрашивал все объекты банальным пингом и сохранял состояние в файл.
system(“ping -n 3 -w 100 {$ip_address}“);
Да, да, рад са базом података у том тренутку такође није био савладан за мене. Нисам знао да је могуће паралелизирати процесе, а пролазак кроз све чворове мреже је дуго трајао, јер... ово се догодило у једној нити. Проблеми су посебно настали када је неколико чворова било недоступно, јер сваки од њих је одложио скрипту за 300 мс. На страни клијента постојала је једноставна функција петље која је, у интервалима од неколико секунди, преузимала ажуриране информације са сервера уз Ајак захтев и ажурирала интерфејс. Па, онда, након 3 неуспешна пинга заредом, ако је на рачунару отворена веб страница са надзором, свирала је весела композиција.
Када је све успело, био сам веома инспирисан резултатом и помислио сам да могу да му додам још (због свог знања и могућности). Али увек нисам волео системе са милион графикона, за које сам тада мислио, а и дан данас мислим, да су у већини случајева непотребни. Хтео сам да унесем само оно што би ми заиста помогло у раду. Овај принцип остаје фундаменталан за развој Велиама до данас. Даље, схватио сам да би било супер да не морам да пратим отворен и да знам за проблеме, а када се то деси, онда отворим страницу и видим где се налази овај проблематични мрежни чвор и шта даље да радим са њим . Некако тада нисам читао е-пошту, једноставно је нисам користио. На интернету сам наишао да постоје СМС гејтвеји на које можете послати ГЕТ или ПОСТ захтев, а они ће ми послати СМС на мобилни телефон са текстом који ја напишем. Одмах сам схватио да ово заиста желим. И почео сам да проучавам документацију. После извесног времена успео сам, а сада сам на мобилни телефон добио СМС о проблемима на мрежи са именом „палог предмета“. Иако је систем био примитиван, написао сам га сам, а најважније што ме је мотивисало да га развијем је то што је то био апликативни програм који ми је заиста помогао у раду.
А онда је дошао дан када се један од интернет канала покварио, а мој мониторинг ме није обавестио о томе. Пошто је Гоогле ДНС и даље савршено пинговао. Време је да размислите о томе како можете да пратите да ли је комуникациони канал жив. Постојале су различите идеје како да се то уради. Нисам имао приступ свој опреми. Морали смо да смислимо како да разумемо који од канала је уживо, али без могућности да га некако погледамо на самој мрежној опреми. Тада је колега дошао на идеју да је могуће да се праћење руте до јавних сервера може разликовати у зависности од тога који комуникациони канал се тренутно користи за приступ Интернету. Проверио сам и испало је тако. Било је различитих рута приликом трасирања.
system(“tracert -d -w 500 8.8.8.8”);
Тако се појавила друга скрипта, тачније, из неког разлога је траг додат на крај исте скрипте, који је пинговао све уређаје на мрежи. На крају крајева, ово је још један дуг процес који је извршен у истој нити и успорио рад читаве скрипте. Али тада то није било тако очигледно. Али на овај или онај начин, он је урадио свој посао, код је стриктно дефинисао какво праћење треба да буде за сваки од канала. Тако је почео да ради систем који је већ надгледао (гласно речено, јер није било прикупљања метрике, већ само пинговање) мрежних уређаја (рутери, прекидачи, ви-фи итд.) и комуникациони канали са спољним светом . СМС поруке су стизале редовно и дијаграм је увек јасно показивао где је проблем.
Даље, у свакодневном раду морао сам да радим укрштање. И уморио сам се да сваки пут одлазим на Цисцо прекидаче да видим који интерфејс да користим. Како би било супер кликнути на објекат у надгледању и видети листу његових интерфејса са описима. То би ми уштедело време. Штавише, у овој шеми не би било потребе да се покреће Путти или СецуреЦРТ за унос налога и команди. Само сам кликнуо на мониторинг, видео шта треба и отишао да радим свој посао. Почео сам да тражим начине за интеракцију са прекидачима. Одмах сам наишао на 2 опције: СНМП или пријављивање на свитцх преко ССХ-а, уношење команди које су ми биле потребне и рашчлањивање резултата. Одбацио сам СНМП због сложености његове имплементације, био сам нестрпљив да добијем резултат. са СНМП-ом, морали бисте дуго да копате по МИБ-у и на основу ових података генеришете податке о интерфејсима. У ЦИСЦО-у постоји диван тим
show interface statusПоказује тачно шта ми треба за унакрсне прелазе. Зашто се мучити са СНМП-ом када само желим да видим излаз ове команде, помислио сам. После неког времена, схватио сам ову прилику. Кликнули сте на објекат на веб страници. Покренуо се догађај којим је АЈАКС клијент контактирао сервер, а он се, заузврат, преко ССХ-а повезао са прекидачем који ми је био потребан (акредитиви су били тврдо кодирани у коду, није било жеље да се он пречишћава, да се праве посебни менији где било би могуће променити налоге из интерфејса, био ми је потребан резултат и то брзо) Унео сам горњу команду тамо и послао је назад у претраживач. Тако сам почео да видим информације о интерфејсима једним кликом миша. Ово је било изузетно згодно, посебно када сте морали да видите ове информације на различитим прекидачима одједном.
Праћење канала засновано на траговима на крају није била најбоља идеја, јер... понекад се радило на мрежи, а праћење се могло променити и мониторинг је почео да виче на мене да има проблема са каналом. Али након што сам потрошио много времена на анализу, схватио сам да сви канали раде, а моје праћење ме вара. Као резултат тога, замолио сам своје колеге који су управљали прекидачима за формирање канала да ми једноставно пошаљу системски дневник када се статус видљивости суседа промени. Сходно томе, било је много једноставније, брже и тачније од праћења. Стигао је догађај као што је комшија је изгубио, и одмах издајем обавештење о прекиду канала.
Даље, појавило се још неколико команди када се кликне на објекат, а додат је СНМП за прикупљање неких метрика, и то је у суштини то. Систем се никада није даље развијао. Урадио је све што ми је требало, био је добар алат. Многи читаоци ће ми вероватно рећи да већ постоји много софтвера на Интернету за решавање ових проблема. Али у ствари, тада нисам гуглао такве бесплатне производе и заиста сам желео да развијем своје вештине програмирања, а има ли бољег начина да то постигнем од правог проблема са апликацијом. У овом тренутку, прва верзија праћења је завршена и више није модификована.
Оснивање компаније Аудит-Телецом
Како је време пролазило, почео сам да радим на пола радног времена у другим компанијама, на срећу, мој радни распоред ми је то дозвољавао. Када радите у различитим компанијама, ваше вештине у различитим областима расту веома брзо, а ваши хоризонти се добро развијају. Има компанија у којима си, како кажу, Швеђанин, косац, трубач. С једне стране, тешко је, с друге стране, ако нисте лењи, постајете генералиста и то вам омогућава да брже и ефикасније решавате проблеме јер знате како сродна област функционише.
Мој пријатељ Павел (такође информатичар) је стално покушавао да ме подстакне да покренем сопствени бизнис. Било је безброј идеја са различитим варијацијама онога што су радили. О томе се расправља годинама. И на крају, није требало да дође до ничега, јер ја сам скептик, а Павел је сањар. Сваки пут када је предложио идеју, увек нисам веровао у њу и одбијао сам да учествујем. Али заиста смо желели да отворимо сопствени бизнис.
Коначно, успели смо да пронађемо опцију која је одговарала обојици и урадимо оно што знамо да радимо. 2016. године одлучили смо да направимо ИТ компанију која ће помоћи предузећима да реше ИТ проблеме. То је постављање ИТ система (1Ц, терминал сервер, маил сервер, итд.), њихово одржавање, класични ХелпДеск за кориснике и администрација мреже.
Искрено говорећи, у време стварања компаније нисам веровао у њу око 99,9%. Али некако је Павел успео да ме натера да покушам, и гледајући унапред, показало се да је био у праву. Павел и ја смо убацили по 300 рубаља, регистровали ново ЛЛЦ „Аудит-Телецом“, изнајмили малу канцеларију, направили цоол визит карте, па, уопште, као вероватно већина неискусних, почетника бизнисмена, и почели да траже клијенте. Проналажење клијената је сасвим друга прича. Можда ћемо написати посебан чланак као део корпоративног блога ако неко буде заинтересован. Хладни позиви, летци итд. Ово није дало никакве резултате. Како сада читам из многих прича о бизнису, на овај или онај начин, много зависи од среће. Имали смо среће. и буквално пар недеља након настанка фирме пришао нам је брат Владимир, који нам је довео првог клијента. Нећу да вас замарам детаљима рада са клијентима, није о томе у чланку, само ћу рећи да смо отишли на ревизију, идентификовали критичне области и ове области су се поквариле док је донета одлука да ли ће сарађујете са нама на сталној основи као спољни наручиоци. После овога, одмах је донета позитивна одлука.
Тада су, углавном усмено преко пријатеља, почеле да се појављују и друге услужне компаније. Хелпдеск је био у једном систему. Везе на мрежну опрему и сервере су различите, тачније другачије. Неки људи су сачували пречице, други су користили РДП адресаре. Мониторинг је још један посебан систем. Веома је незгодно да тим ради у различитим системима. Важне информације се губе из вида. Па, на пример, терминалски сервер клијента је постао недоступан. Пријаве корисника овог клијента се одмах примају. Специјалиста за подршку отвара захтев (примљен је телефоном). Ако би се инциденти и захтеви регистровали у једном систему, онда би стручњак за подршку одмах видео у чему је проблем корисника и рекао му о томе, док би се истовремено повезао са потребним објектом како би решио ситуацију. Сви су свесни тактичке ситуације и раде складно. Нисмо нашли систем где се све ово комбинује. Постало је јасно да је време да направимо сопствени производ.
Наставак рада на вашем систему за праћење
Било је јасно да је систем који је раније написан потпуно неподесан за садашње задатке. Ни по функционалности ни по квалитету. И одлучено је да се систем напише од нуле. Графички је требало да изгледа потпуно другачије. Морао је да буде хијерархијски систем да би било могуће брзо и повољно отворити прави објекат за правог клијента. Шема као у првој верзији апсолутно није била оправдана у тренутном случају, јер Клијенти су различити и уопште није било важно у којим просторијама се налази опрема. Ово је већ пребачено у документацију.
Дакле, задаци:
- Хијерархијска структура;
- Нека врста серверског дела који се може поставити у просторије клијента у виду виртуелне машине за прикупљање потребних метрика и слање на централни сервер, који ће све ово сумирати и показати нам;
- Алертс. Оне које се не могу пропустити, јер... у то време није било могуће да неко седи и само гледа у монитор;
- Систем апликација. Почели су да се појављују клијенти за које смо сервисирали не само серверску и мрежну опрему, већ и радне станице;
- Могућност брзог повезивања са серверима и опремом из система;
Задачи поставлены, начинаем писать. Попутно обрабатывая заявки от клиентов. На тот момент нас уже было 4 человека. Начали писать сразу обе части и центральный сервер, и сервер для установки к клиентам. К этому моменту Linux был уже не чужим для нас и было принято решение, что виртуальные машины, которые будут стоять у клиентов будут на Debian. Не будет никаких установщиков, просто сделаем проект серверной части на одной конкретной виртуальной машине, а потом просто будем ее клонировать к нужному клиенту. Это была очередная ошибка. Позже стало понятно, что в такой схеме абсолютно не проработан механизм апдейтов. Т.е. мы добавляли какую-то новую фичу, а потом была целая проблема распространять ее на все серверы клиентов, но к этому вернемся позже, все по порядку.
Направили смо први прототип. Био је у могућности да пингује клијентске мрежне уређаје и сервере који су нам били потребни и пошаље ове податке на наш централни сервер. А он је, заузврат, ажурирао ове податке на велико на централном серверу. Овде ћу написати не само причу о томе како и шта је било успешно, већ и које су аматерске грешке направљене и како сам касније то морао да платим временом. Дакле, читаво стабло објеката је ускладиштено у једној датотеци у облику серијализованог објекта. Док смо неколико клијената повезивали на систем, све је било мање-више нормално, иако је понекад било неких артефаката који су били потпуно неразумљиви. Али када смо на систем повезали десетак сервера, почела су да се дешавају чуда. Понекад, из неког непознатог разлога, сви објекти у систему једноставно нестану. Овде је важно напоменути да су сервери којима су клијенти слали податке централном серверу сваких неколико секунди путем ПОСТ захтева. Пажљиви читалац и искусни програмер већ су претпоставили да постоји проблем са вишеструким приступом самој датотеци у којој је серијализовани објекат истовремено ускладиштен из различитих нити. И баш када се то дешавало, дешавала су се чуда са нестанком предмета. Датотека је једноставно постала празна. Али све ово није откривено одмах, већ само током рада са неколико сервера. За то време је додата функционалност скенирања портова (сервери су слали централи не само информације о доступности уређаја, већ и о отвореним портовима на њима). Ово је урађено позивањем команде:
$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);
резултати су често били нетачни и скенирање је требало дуго да се заврши. Потпуно сам заборавио на пинг, то је урађено преко фпинга:
system("fping -r 3 -t 100 {$this->ip}");
Ово такође није било паралелно и самим тим је процес био веома дуг. Касније је цела листа ИП адреса потребних за верификацију одједном послата фпингу, а назад смо добили готову листу оних који су одговорили. За разлику од нас, фпинг је успео да паралелизује процесе.
Још један уобичајени рутински посао било је постављање неких услуга путем ВЕБ-а. Па, на пример, ЕЦП из МС Екцханге-а. У суштини то је само веза. И одлучили смо да морамо да можемо да додамо такве везе директно у систем, како не бисмо морали да тражимо у документацији или негде другде у обележивачима како да приступимо ЕЦП-у одређеног клијента. Тако се појавио концепт линкова ресурса за систем, њихова функционалност је доступна до данас и није се променила, па, скоро.
Како функционишу везе са ресурсима у Велиаму
Удаљене везе
Овако то изгледа у акцији у тренутној верзији Велиама
Један од задатака је био да се брзо и згодно повеже са серверима, којих је већ било много (више од сто) и сортирање кроз милионе унапред сачуваних РДП пречица је било изузетно незгодно. Био је потребан алат. На Интернету постоји софтвер који је нешто попут адресара за такве РДП везе, али они нису интегрисани са системом за праћење, а налози се не могу сачувати. Сваки пут уношење налога за различите клијенте је прави пакао када се повежете десетине пута дневно на различите сервере. Са ССХ-ом ствари су мало боље, постоји много доброг софтвера који вам омогућава да организујете такве везе у фасцикле и запамтите налоге из њих. Али постоје 2 проблема. Први је што нисмо пронашли ниједан програм за РДП и ССХ везе. Други је да ако у неком тренутку нисам за рачунаром и треба да се брзо повежем, или сам само поново инсталирао систем, мораћу да уђем у документацију да погледам налог са овог клијента. То је незгодно и губљење времена.
Хијерархијска структура која нам је била потребна за клијентске сервере је већ била доступна у нашем интерном производу. Само сам морао да смислим како да спојим брзе везе на потребну опрему тамо. За почетак, барем унутар ваше мреже.
С учетом того, что клиентом в нашей системе выступал браузер, который не имеет доступа к локальным ресурсам компьютера, чтобы просто взять и какой-то командой запустить нужное нам приложение, было придумано сделать все через “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 конекција у нови Windows профил. Рекао сам: „Доста ми је овога“, и почео да размишљам шта би се могло учинити поводом тога.
Тако се десило да су сви клијенти као рутере имали уређаје познате компаније Микротик. Веома су функционални и погодни за обављање готово свих задатака. Лоша страна је што су „отети“. Овај проблем смо решили једноставним затварањем свих приступа споља. Али било је потребно некако доћи до њих без доласка код клијента, јер... дуго је. Једноставно смо направили тунеле за сваки такав Микротик и одвојили их у посебан базен. без икаквог рутирања, тако да нема везе ваше мреже са мрежама клијената и њихових мрежа међусобно.
Родила се идеја да се, када кликнем на објекат који ми је потребан у систему, централни сервер за праћење, знајући ССХ налоге свих клијената Микротик, повеже са жељеним, креира правило прослеђивања до жељеног хоста са потребна лука. Овде постоји неколико тачака. Решење није универзално – радиће само за Микротик, пошто је синтакса команде различита за све рутере. Такође, таква прослеђивања су тада морала да се некако обришу, а серверски део нашег система у суштини није могао ни на који начин да прати да ли сам завршио своју РДП сесију. Па такво прослеђивање је рупа за клијента. Али нисмо тежили универзалности, јер... производ је коришћен само у нашој компанији и није било размишљања о његовом пуштању у јавност.
Сваки од проблема је решен на свој начин. Када је правило креирано, ово прослеђивање је било доступно само за једну специфичну спољну ИП адресу (са које је веза иницијализована). Тако је избегнута безбедносна рупа. Али са сваком таквом везом, Микротик правило је додато на НАТ страницу и није обрисано. И сви знају да што је више правила, то је више учитан процесор рутера. И уопште, нисам могао да прихватим да ћу једног дана отићи у неки Микротик, а тамо ће бити стотине мртвих, бескорисних правила.
Пошто наш сервер не може да прати статус везе, нека Микротик сам прати. И написао сам скрипту која је стално пратила сва правила прослеђивања са одређеним описом и проверавала да ли ТЦП веза има одговарајуће правило. Ако га није било неко време, онда је веза вероватно већ завршена и ово прослеђивање се може избрисати. Све је испало, сценарио је добро функционисао.
Узгред, ево га:
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
}
}
Сигурно је могло да се направи лепшим, бржим итд, али је успело, није оптеретио Микротик и одлично је урадио посао. Коначно смо били у могућности да се само једним кликом повежемо на сервере клијената и мрежну опрему. Без отварања ВПН-а или уноса лозинки. Систем је постао заиста згодан за рад. Време услуге је смањено и сви смо трошили време радећи уместо да се повезујемо са потребним објектима.
Микротик Бацкуп
Конфигурисали смо резервну копију свих Микротик-а на ФТП. И генерално све је било у реду. Али када је требало да добијете резервну копију, морали сте да отворите овај ФТП и тамо га потражите. Имамо систем где су сви рутери повезани и можемо да комуницирамо са уређајима преко ССХ-а. Зашто не бисмо направили тако да сам систем свакодневно узима резервне копије од свих Микротика, помислио сам. И почео је да га спроводи. Повезали смо се, направили резервну копију и однели у складиште.
Код скрипте у ПХП-у за прављење резервне копије са Микротика:
<?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');
?>
Резервна копија се узима у два облика - бинарној и текстуалној конфигурацији. Бинарна датотека помаже да се брзо врати потребна конфигурација, а текстуална вам омогућава да разумете шта треба да се уради ако дође до принудне замене опреме и бинарни фајл се не може учитати у њега. Као резултат тога, добили смо још једну згодну функционалност у систему. Штавише, приликом додавања новог Микротика, није било потребе да било шта конфигуришем, једноставно сам додао објекат у систем и поставио налог за њега преко ССХ-а. Затим се сам систем побринуо за прављење резервних копија. Тренутна верзија СааС Велиам-а још увек нема ову функционалност, али ћемо је ускоро пренети.
Снимци екрана како је то изгледало у унутрашњем систему
Прелазак на нормално складиштење базе података
Већ сам горе написао да су се појавили артефакти. Понекад је цела листа објеката у систему једноставно нестала, понекад приликом уређивања објекта информација није сачувана и објекат је морао да се преименује три пута. Ово је све страшно изнервирало. Нестајање објеката се дешавало ретко и лако се враћало враћањем овог фајла, али су се грешке приликом уређивања објеката дешавале прилично често. Вероватно, у почетку то нисам радио преко базе података јер ми се није уклапало у то како је могуће држати стабло са свим везама у равној табели. Раван је, али је дрво хијерархијско. Али добро решење за вишеструки приступ, а после тога (како систем постаје сложенији) трансакциони, је ДБМС. Вероватно нисам први који се сусрео са овим проблемом. Почео сам да гуглам. Испоставило се да је све већ било измишљено пре мене и да постоји неколико алгоритама који граде дрво од равног стола. Након што сам погледао сваки, имплементирао сам један од њих. Али ово је већ била нова верзија система, јер... У ствари, због овога сам морао доста тога да преписујем. Резултат је био природан, проблеми насумичног понашања система су нестали. Неки би могли рећи да су грешке веома аматерске (једнонитне скрипте, складиштење информација којима се приступало више пута истовремено из различитих нити у датотеци, итд.) у области развоја софтвера. Можда је то и тачно, али мој главни посао је била администрација, а програмирање ми је било споредна гужва за душу, и једноставно нисам имао искуства у раду у тиму програмера, где би ми такве основне ствари одмах сугерисао мој старији другови. Стога сам све ове неравнине сам попунио, али сам одлично научио градиво. Такође, мој посао укључује састанке са клијентима, акције у циљу промоције компаније, гомилу административних питања унутар компаније и још много, много више. Али, на овај или онај начин, тражило се оно што је већ постојало. Момци и ја смо користили производ у свакодневном раду. Било је искрено неуспешних идеја и решења на која се губило време, али је на крају постало јасно да то није радни алат и нико га није користио и није завршио у Велиаму.
Хелпдеск - ХелпДеск
Не би било лоше поменути како је формиран ХелпДеск. Ово је сасвим друга прича, јер... у Велиаму је ово већ 3. потпуно нова верзија, која се разликује од свих претходних. Сада је то једноставан систем, интуитиван без непотребних звона и звиждука, са могућношћу интеграције са доменом, као и могућношћу приступа истом корисничком профилу са било ког места користећи линк из е-поште. И што је најважније, могуће је повезати се са подносиоцем захтева преко ВНЦ-а са било ког места (код куће или у канцеларији) директно из апликације без ВПН-а или прослеђивања портова. Рећи ћу вам како смо дошли до овога, шта се десило раније и које су страшне одлуке донете.
Повезали смо се са корисницима преко добро познатог ТеамВиевер-а. Сви рачунари чије кориснике опслужујемо имају инсталиран ТВ. Прва ствар коју смо погрешили, а потом и уклонили, било је повезивање сваког ХД клијента са хардвером. Како се корисник пријавио на ХД систем да би оставио захтев? Поред ТВ-а, сви су имали инсталиран посебан услужни програм на својим рачунарима, написан на Лазарусу (многи људи овде ће преврнути очима, па можда и прогуглати шта је, али најбољи компајлирани језик који сам знао је Делпхи, а Лазарус је скоро иста ствар, само бесплатна). Генерално, корисник је покренуо посебну батцх датотеку која је покренула овај услужни програм, који је заузврат прочитао ХВИД система и након тога је покренут претраживач и дошло је до ауторизације. Зашто је то урађено? У неким предузећима број сервисираних корисника се рачуна појединачно, а цена услуге за сваки месец се заснива на броју људи. Ово је разумљиво, кажете, али зашто је то везано за хардвер? Врло је једноставно, неки појединци су долазили кући и са свог кућног лаптопа тражили захтев у стилу „учини ми све овде лепим“. Поред читања системског ХВИД-а, услужни програм је извукао тренутни Теамвиевер ИД из регистра и такође нам га је пренео. Теамвиевер има АПИ за интеграцију. И ми смо урадили ову интеграцију. Али постојала је једна квака. Преко ових АПИ-ја немогуће је повезати се са рачунаром корисника када он експлицитно не покрене ову сесију и након покушаја да се повеже са њом, мора такође да кликне на „потврди“. Тада нам се чинило логичним да се нико не повезује без захтева корисника, а пошто је особа за рачунаром, она ће покренути сесију и одговорити потврдно на захтев за даљинско повезивање. Све је испало наопако. Подносиоци захтева су заборавили да притисну да започну седницу и морали су да им то кажу у телефонском разговору. Ово је изгубљено време и било је фрустрирајуће на обе стране процеса. Штавише, уопште нису неуобичајени такви тренуци када особа остави захтев, али му је дозвољено да се повеже само када оде на ручак. Зато што проблем није критичан и не жели да се његов радни процес прекида. Сходно томе, он неће притиснути ниједно дугме да би омогућио везу. Овако се појавила додатна функционалност приликом пријављивања на ХелпДеск - читање Теамвивер ИД-а. Знали смо трајну лозинку која је коришћена приликом инсталирања Теамвивер-а. Тачније, знао је само систем, пошто је уграђен у инсталатер и у наш систем. Сходно томе, постојало је дугме за повезивање из апликације кликом на које није требало ништа чекати, али се Теамвиевер одмах отворио и дошло је до везе. Као резултат тога, постојала су два типа могућих веза. Преко званичног Теамвиевер АПИ-ја и нашег само-направљеног АПИ-ја. На моје изненађење, прву су скоро одмах престали да користе, иако је постојало упутство да се користи само у посебним случајевима и када сам корисник да зелено светло. Ипак, дај ми сигурност сада. Али испоставило се да подносиоцима представке ово није било потребно. Сви су потпуно у реду што су повезани са њима без дугмета за потврду. И пошто је то случај, функционалност API повезивања је накнадно елиминисана као непотребна.
Переход на многопоточность в Linux
Питање убрзавања проласка мрежног скенера ради отворености унапред одређене листе портова и једноставног пинговања мрежних објеката одавно је почело да се поставља. Овде, наравно, прво решење које вам пада на памет је мултитхреадинг. Пошто је главно време утрошено на пинг чекање да се пакет врати, а следећи пинг не може да почне док се не врати претходни пакет, у компанијама које су имале чак 20+ сервера плус мрежну опрему, то је већ функционисало прилично споро. Поента је да један пакет може нестати, али немојте одмах о томе обавестити администратора система. Једноставно ће врло брзо престати да прихвата такву нежељену пошту. То значи да морате да пингујете сваки објекат више пута пре него што донесете закључак о неприступачности. Не улазећи превише у детаље, потребно је то паралелизирати јер ако се то не уради, онда ће највероватније систем администратор сазнати за проблем од клијента, а не од система за праћење.
Сам ПХП не подржава мултитхреадинг из кутије. Способан за вишеструку обраду, можете се рачвати. Али, у ствари, већ сам имао написан механизам гласања и желео сам да га направим тако да једном пребројим све чворове који су ми потребни из базе података, пингујем све одједном, чекам одговор од сваког и тек након тога одмах напишем Подаци. Ово штеди на броју захтева за читање. Мултитхреадинг се савршено уклапа у ову идеју. За ПХП постоји ПТхреадс модул који вам омогућава да правите прави вишенитни рад, иако је било потребно доста труда да се ово подеси на ПХП 7.2, али је урађено. Скенирање портова и пинг су сада брзи. И уместо, на пример, 15 секунди по кругу раније, овај процес је почео да траје 2 секунде. Био је то добар резултат.
Брза ревизија нових компанија
Како је настала функционалност за прикупљање различитих метрика и хардверских карактеристика? То је једноставно. Понекад нам је једноставно наређено да извршимо ревизију тренутне ИТ инфраструктуре. Па, иста ствар је неопходна да би се убрзала ревизија новог клијента. Требало нам је нешто што би нам омогућило да дођемо у средњу или велику компанију и брзо схватимо шта они имају. По мом мишљењу, пинг на интерној мрежи блокирају само они који желе да себи закомпликују живот, а по нашем искуству их је мало. Али има и таквих. Сходно томе, можете брзо скенирати мреже за присуство уређаја једноставним пингом. Затим их можемо додати и скенирати отворене портове који нас занимају. У ствари, ова функционалност је већ постојала, било је потребно само додати команду са централног сервера на подређени како би скенирао наведене мреже и додао све што нађе на листу. Заборавио сам да напоменем, претпостављало се да већ имамо готову слику са конфигурисаним системом (славе мониторинг сервер) коју можемо једноставно да избацимо са клијента током ревизије и повежемо је са нашим облаком.
Но результат аудита обычно включает в себя кучу различной информации и одна из них это — что вообще за устройства в сети. В первую очередь нас интересовали Windows серверы и рабочие станции Windows в составе домена. Так как в средних и крупных компаниях отсутствие домена — это, наверное, исключение из правил. Что бы говорить на одном языке, средняя, в моем представлении, это 100+ человек. Нужно было придумать способ как собрать данные со всех виндовых машин и серверов, зная их IP и учетную запись доменного администратора, но при этом не устанавливая на каждую из них какой-то софт. На помощь приходит интерфейс WMI. Windows Management Instrumentation (WMI) в дословном переводе — инструментарий управления Windows. WMI — это одна из базовых технологий для централизованного управления и слежения за работой различных частей компьютерной инфраструктуры под управлением платформы Windows. Взято из вики. Далее пришлось опять повозиться, с тем, чтобы собрать wmic (это клиент WMI) для Debian. После того как все было готово оставалось просто опрашивать через wmic нужные узлы на предмет нужной информации. Через WMI можно достать с Windows компьютера почти любую информацию, и более того, через него можно еще и управлять компьютером, ну, например, отправить в перезагрузку. Так появился сбор информации о Windows станциях и серверах в нашей системе. Плюсом к этому шла и текущая информация о текущих показателях загруженности системы. Их мы запрашиваем почаще, а информацию по железу пореже. После этого, проводить аудит стало немного приятней.
Одлука о дистрибуцији софтвера
Ми сами користимо систем сваки дан и увек је отворен за сваког техничког радника. И мислили смо да можемо да поделимо са другима оно што већ имамо. Систем још није био спреман за дистрибуцију. Много тога је морало да се преради како би се локална верзија претворила у СааС. То укључује промене у различитим техничким аспектима система (даљинске везе, услуга подршке), анализу модула за лиценцирање, дељење база података корисника, скалирање сваке услуге и развој система за аутоматско ажурирање за све делове. Али ово ће бити други део чланка.
Ажурирај
Извор: ввв.хабр.цом
