Da l'outsourcing à u sviluppu (Parte 1)

Saluta à tutti, mi chjamu Sergey Emelyanchik. Sò u capu di a cumpagnia Audit-Telecom, u principale sviluppatore è autore di u sistema Veliam. Aghju decisu di scrive un articulu nantu à cumu u mo amicu è aghju creatu una sucietà di outsourcing, hà scrittu software per noi stessi è, dopu, hà cuminciatu à distribuisce à tutti via u sistema SaaS. Circa cumu categuricamente ùn aghju micca cridutu chì questu era pussibule. L'articulu cuntene micca solu una storia, ma ancu ditaglii tecnichi di cumu hè statu creatu u pruduttu Veliam. Includendu alcuni pezzi di codice fonte. Vi dicu quali sbagli avemu fattu è cumu l'avemu currettu dopu. Ci era dubbitu di pubblicà un tali articulu. Ma aghju pensatu chì era megliu fà, riceve feedback è migliurà, cà micca publicà l'articulu è pensate à ciò chì saria accadutu se...

Pristoria

Aghju travagliatu in una cumpagnia cum'è impiegatu IT. A cumpagnia era abbastanza grande cù una struttura di rete estensiva. Ùn aghju micca a so rispunsabilità di u travagliu, diceraghju solu chì ùn anu micca definitu u sviluppu di qualcosa.

Avemu avutu u monitoraghju, ma puramente per interessu accademicu vulia pruvà à scrive u mo propiu più simplice. L'idea era questu: vulia chì sia in u web, per pudè andà facilmente senza installà alcun cliente è vede ciò chì succede cù a reta da qualsiasi dispositivu, cumpresu un dispositivu mobile via Wi-Fi, è aghju ancu veramente. vulia capisce rapidamente ciò chì Ci hè un equipamentu in a stanza chì hè diventatu "mopey" perchè ... ci era un requisitu assai strettu per u tempu di risposta à tali prublemi. In u risultatu, un pianu hè natu in u mo capu per scrive una pagina web simplice nantu à quale ci era un sfondate jpeg cù un diagramma di rete, tagliate i dispositi stessi cù i so indirizzi IP in questa stampa, è mostra un cuntenutu dinamicu nantu à a cima. stampa in e coordenate richieste in forma di un indirizzu IP verde o rossu lampante. U compitu hè statu stabilitu, cuminciamu.

Prima, aghju programatu in Delphi, PHP, JS è assai superficialmente C++. So abbastanza bè cumu funziona e rete. VLAN, Routing (OSPF, EIGRP, BGP), NAT. Questu era abbastanza per mè per scrive un prototipu di monitoraghju primitivu.

Aghju scrittu ciò chì avia in mente in PHP. U servitore Apache è PHP eranu attivati Windows perchè Linux per mè in quellu mumentu era qualcosa d'incomprensibile è assai difficiule, cum'è s'hè rivelatu dopu, mi sbagliava assai è in parechji lochi Linux assai più simplice Windows, ma questu hè un tema separatu, è sapemu tutti quante guerre sante ci sò nantu à questu tema. Pianificatore di attività Windows Aghju eseguitu un script PHP à intervalli brevi (ùn mi ricordu micca esattamente, ma qualcosa cum'è una volta ogni trè secondi) chì interrogava tutti l'uggetti cù un simplice ping è salvava u statu in un schedariu.

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

Iè, iè, u travagliu cù una basa di dati in quellu mumentu ùn era ancu maestru per mè. Ùn sapia micca chì era pussibule di parallelizà i prucessi, è passà per tutti i nodi di a rete hà pigliatu assai tempu, perchè ... questu hè accadutu in un filu. I prublemi sò sopratuttu quandu parechji nodi ùn eranu micca dispunibili, perchè ognunu hà ritardatu u script per 300 ms. Da u latu di u cliente ci era una funzione di looping simplice chì, à intervalli di pochi sicondi, scaricava l'infurmazioni aghjurnati da u servitore cù una dumanda Ajax è aghjurnà l'interfaccia. Eppo, dopu, dopu à 3 pings senza successu in una fila, se una pagina web cun monitoraghju era aperta nantu à l'urdinatore, una cumpusizioni allegra hà ghjucatu.

Quandu tuttu hà travagliatu, era assai inspiratu da u risultatu è pensu chì puderia aghjunghje più (per via di a mo cunniscenza è capacità). Ma ùn aghju micca sempre piace à i sistemi cù un milione di carte, chì aghju pensatu allora, è sempre pensu à questu ghjornu, ùn sò micca necessarii in a maiò parte di i casi. Vuliu mette quì solu ciò chì mi aiutava veramente in u mo travagliu. Stu principiu resta fundamentale per u sviluppu di Veliam à questu ghjornu. In più, aghju realizatu chì saria assai bellu s'ellu ùn avia micca bisognu di mantene u monitoraghju apertu è cunnosce i prublemi, è quandu hè accadutu, apre a pagina è vede induve si trova stu nodu di rete problematicu è chì fà cun ellu dopu. . In qualchì modu ùn aghju micca lettu email allora, simpricimenti ùn l'aghju micca usatu. Aghju scontru in Internet chì ci sò gateway SMS à quale pudete mandà una dumanda GET o POST, è mandaranu un SMS à u mo telefuninu cù u testu chì scrivu. Aghju capitu subitu chì vulia veramente questu. E aghju cuminciatu à studià a documentazione. Dopu qualchì tempu aghju riesciutu, è avà aghju ricevutu un SMS nantu à i prublemi nantu à a reta nantu à u mo telefuninu cù u nome di "ughjettu cadutu". Ancu s'ellu u sistema era primitivu, hè statu scrittu da mè stessu, è u più impurtante chì m'hà motivatu à sviluppà hè chì era un prugramma di applicazione chì m'hà aiutatu veramente in u mo travagliu.

È dopu u ghjornu hè ghjuntu quandu unu di i canali Internet hè cascatu à u travagliu, è u mo monitoraghju ùn m'hà micca fattu sapè. Siccomu Google DNS hà sempre pingatu perfettamente. Hè ora di pensà à cumu pudete monitorà chì u canali di cumunicazione hè vivu. Ci era diverse idee nantu à cumu fà questu. Ùn aghju micca accessu à tuttu l'equipaggiu. Avemu avutu à capisce cumu capisce quale di i canali hè in diretta, ma senza pudè vede in qualchì manera nantu à l'equipaggiu di rete stessu. Allora un cullegu hà avutu l'idea chì hè pussibule chì a traccia di a strada à i servitori publichi pò differisce secondu u canali di cumunicazione attualmente utilizatu per accede à Internet. Aghju verificatu è hè stata cusì. Ci era diverse rotte quandu traccia.

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

Allora un altru script apparsu, o piuttostu, per una certa ragione, a traccia hè stata aghjunta à a fine di u listessu script, chì pingava tutti i dispositi in a reta. Dopu tuttu, questu hè un altru prucessu longu chì hè statu eseguitu in u stessu filu è rallentò u travagliu di tuttu u script. Ma allora ùn era micca cusì evidenti. Ma un modu o un altru, hà fattu u so travagliu, u codice strettu prescriva chì tipu di traccia duverebbe esse per ognunu di i canali. Hè cusì chì u sistema hà cuminciatu à travaglià, chì hà digià monitoratu (dittu forte, perchè ùn ci era micca cullizzioni di metriche, ma solu ping) i dispositi di rete (routers, switches, wi-fi, etc.) è i canali di cumunicazione cù u mondu esternu. . I missaghji SMS sò ghjunti regularmente è u diagramma sempre mostrava chjaramente induve era u prublema.

In più, in u travagliu di ogni ghjornu aghju avutu à fà cross-crossing. È aghju stancu di andà à i switch Cisco ogni volta per vede quale interfaccia aduprà. Quantu bellu saria di cliccà nantu à un ughjettu in u monitoraghju è vede una lista di e so interfacce cù descrizzioni. Mi risparmià tempu. Inoltre, in questu schema ùn ci saria bisognu di eseguisce Putty o SecureCRT per inserisce cunti è cumandamenti. Aghju fattu cliccà nantu à u monitoraghju, aghju vistu ciò chì era necessariu è andò à fà u mo travagliu. Aghju cuminciatu à circà modi per interagisce cù i switch. Aghju subitu scontru 2 opzioni: SNMP o login in u switch via SSH, inserendu i cumandamenti chì avia bisognu è analizà u risultatu. Aghju disprezzatu SNMP per via di a cumplessità di a so implementazione, era impaciente per ottene u risultatu. cù SNMP, avete da scavà in u MIB per un bellu pezzu è, basatu annantu à sta dati, generà dati nantu à l'interfaccia. Ci hè una squadra maravigliosa in CISCO

show interface status

Mostra esattamente ciò chì aghju bisognu per cross-crossings. Perchè preoccupatu cù SNMP quandu vogliu solu vede u risultatu di stu cumandamentu, pensu. Dopu qualchì tempu, aghju realizatu sta opportunità. Cliccate nantu à un oggettu nantu à una pagina web. Un avvenimentu hè stata attivata da u quale u cliente AJAX hà cuntattatu u servitore, è, à u turnu, cunnessu via SSH à u switch chì avia bisognu (i credenziali sò stati codificati in u codice, ùn ci era micca vuluntà di raffinà, per fà alcuni menu separati induve Puderia cambià i cunti da l'interfaccia, aghju bisognu di u risultatu è rapidamente) aghju intrutu in u cumandimu quì sopra è rinviatu à u navigatore. Allora aghju cuminciatu à vede l'infurmazioni nantu à l'interfaccia cù un clic di u mouse. Questu hè stata estremamente còmuda, soprattuttu quandu avete bisognu di vede sta informazione nantu à diversi switch à una volta.

U monitoraghju di u canali basatu in traccia ùn hè micca stata a megliu idea, perchè ... qualchì volta u travagliu era realizatu nantu à a reta, è a traccia puderia cambià è u monitoraghju hà cuminciatu à gridà à mè chì ci sò prublemi cù u canali. Ma dopu avè passatu assai tempu nantu à l'analisi, aghju capitu chì tutti i canali travagliavanu, è u mo monitoraghju m'ingannava. In u risultatu, aghju dumandatu à i mo culleghi chì anu gestitu i switch di furmazione di canali per mandà simpricimenti syslog quandu u statutu di visibilità di i vicini cambiatu. In cunsiquenza, era assai più simplice, più veloce è più precisu di traccia. Un avvenimentu cum'è un vicinu persu hè ghjuntu, è aghju subitu una notificazione annantu à u canali.

In più, parechji altri cumandamenti apparsu quandu cliccà nantu à un ughjettu, è SNMP hè statu aghjuntu per cullà qualchi metrica, è questu hè in fondu. U sistema ùn hà mai sviluppatu più. Hà fattu tuttu ciò chì avia bisognu, era un bonu strumentu. Parechji lettori probabilmente mi diceranu chì ci hè digià assai software in Internet per risolve questi prublemi. Ma in fattu, ùn aghju micca google tali prudutti gratuiti allora è vulia veramente sviluppà e mo cumpetenze di prugrammazione, è quale modu megliu per spinghje per questu chì un veru prublema di applicazione. À questu puntu, a prima versione di surviglianza hè stata cumpletata è ùn era più mudificata.

Creazione di a cumpagnia Audit-Telecom

Quandu u tempu passava, aghju cuminciatu à travaglià part-time in altre imprese, furtunatamente u mo schedariu di travagliu m'hà permessu di fà questu. Quandu travagliate in diverse cumpagnie, e vostre cumpetenze in diverse aree crescenu assai rapidamente, è i vostri orizzonti si sviluppanu bè. Ci sò cumpagnie in quale, cum'è dicenu, site un Svedese, un segatore è un trombettista. Da un latu, hè difficiule, da l'altra banda, sè ùn site micca pigro, diventate un generalista è questu permette di risolve i prublemi più veloce è più efficaci perchè sapete cumu funziona u campu in relazione.

U mo amicu Pavel (ancu un specialistu in l'informatica) hà sempre pruvatu à incuragiscemi à inizià a so propria attività. Ci era innumerevoli idee cù diverse variazioni di ciò chì facianu. Questu hè statu discutitu per anni. È à a fine, ùn deve esse ghjuntu à nunda perchè sò scetticu, è Pavel hè un sognu. Ogni volta chì prupone una idea, ùn aghju micca sempre cridutu è ricusatu di participà. Ma vulemu veramente apre a nostra propria attività.

Infine, avemu pussutu truvà una opzione chì adatta à noi dui è fà ciò chì sapemu fà. In u 2016, avemu decisu di creà una sucietà IT chì aiutava l'imprese à risolve i prublemi IT. Questa hè a implementazione di sistemi IT (1C, servitore di terminal, servitore di mail, etc.), u so mantenimentu, HelpDesk classicu per l'utilizatori è l'amministrazione di a rete.

Francamente parlante, à u mumentu di a creazione di a cumpagnia, ùn aghju micca cridutu in questu circa 99,9%. Ma in una certa manera Pavel hà sappiutu di fà mi pruvà, è guardendu avanti, si rivelò à esse ghjustu. Pavel è aghju fattu un chip in 300 000 rubli ognunu, hà registratu una nova LLC "Audit-Telecom", affittu un uffiziu minuscule, hà fattu carti d'affari cool, bè, in generale, cum'è probabilmente i più inesperti, imprenditori principianti, è cuminciaru à circà i clienti. Truvà i clienti hè una storia completamente diversa. Forsi scriveremu un articulu separatu cum'è parte di u blog corporativu se qualchissia hè interessatu. Cold calls, volantini, etc. Questu ùn hà micca datu risultati. Cumu leghje avà da parechje storie nantu à l'affari, in una manera o l'altra, assai dipende da a furtuna. Avemu avutu furtunatu. è littiralmenti un paru di simani dopu à a creazione di a cumpagnia, u mo fratellu Vladimir hà avvicinatu à noi, chì ci hà purtatu u primu cliente. Ùn vi stancheraghju micca cù i dettagli di u travagliu cù i clienti, ùn hè micca ciò chì l'articulu hè, dicu solu chì avemu andatu per un auditu, identificatu e zone critiche è queste aree anu rottu mentre a decisione hè stata presa. cooperate cun noi in modu continuu cum'è outsourcers. Dopu questu, una decisione pusitiva hè stata immediata.

Allora, principarmenti per via di a bocca à traversu l'amichi, altre cumpagnie di serviziu cuminciaru à cumparisce. Helpdesk era in un sistema. Cunnessioni à l'equipaggiu di rete è i servitori sò diffirenti, o piuttostu diffirenti. Certi pirsuni salvavanu shortcuts, altri anu utilizatu l'indirizzi RDP. U monitoraghju hè un altru sistema separatu. Hè assai inconveniente per una squadra di travaglià in sistemi disparati. L'infurmazione impurtante hè persa di vista. Ebbè, per esempiu, u servitore di terminal di u cliente hè diventatu indisponibile. L'applicazioni sò immediatamente ricevute da l'utilizatori di stu cliente. U specialista di supportu apre una dumanda (hè stata ricevuta per telefunu). Se incidenti è richieste sò stati registrati in un sistema, allora u specialista di supportu vede immediatamente quale hè u prublema di l'utilizatore è li dicenu, mentre chì si cunnetta simultaneamente à l'ughjettu necessariu per risolve a situazione. Tutti sò cuscenti di a situazione tattica è travaglia in armunia. Ùn avemu micca truvatu un sistema induve tuttu questu hè cumminatu. Hè diventatu chjaru chì era ora di fà u nostru propiu pruduttu.

U travagliu cuntinuatu nantu à u vostru sistema di surviglianza

Era chjaru chì u sistema chì era scrittu prima era cumplettamente inadatta per i travaglii attuali. Nè in termini di funziunalità nè in termini di qualità. È hè statu decisu di scrive u sistema da zero. Graficamenti duveria avè vistu completamente diversu. Duvia esse un sistema gerarchicu in modu chì sia pussibule apre rapidamente è convenientemente l'ughjettu ghjustu per u cliente ghjustu. U schema cum'è in a prima versione ùn era assolutamente micca ghjustificatu in u casu attuale, perchè I clienti sò sferenti è ùn importava micca in quale locu l'equipaggiu era situatu. Questu hè digià statu trasferitu à a documentazione.

Allora, i travaglii:

  1. struttura gerarchica;
  2. Qualchese tipu di parte di u servitore chì pò esse piazzatu in u locu di u cliente in a forma di una macchina virtuale per cullà i metrici chì avemu bisognu è mandà à u servitore cintrali, chì riassumerà tuttu questu è ci mostra à noi;
  3. Alerts. Quelli chì ùn ponu micca mancatu, perchè ... in quellu tempu ùn era micca pussibule per qualcunu di pusà è solu fighjà u monitor;
  4. Sistema di applicazione. I clienti cuminciaru à apparisce per quale avemu servitu micca solu l'equipaggiu di u servitore è di a rete, ma ancu e stazioni di travagliu;
  5. Capacità di cunnette rapidamente à i servitori è l'equipaggiu da u sistema;

I travaglii sò stati stabiliti, è avemu cuminciatu à scrive. Lungu a strada, avemu trattatu e richieste di i clienti. À quellu puntu, eramu digià in quattru. Avemu cuminciatu à scrive e duie parte à tempu: u servitore cintrali è u servitore per l'installazione di u cliente. À questu puntu, Linux ùn ci era più straneru è hè statu decisu chì e macchine virtuali chì serianu installate in casa di i clienti serianu accese DebianÙn ci saranu micca installatori; creeremu simpliciamente un prughjettu lato server nantu à una sola macchina virtuale, è dopu u cloneremu simpliciamente à u cliente necessariu. Questu era un altru sbagliu. Più tardi hè diventatu chjaru chì sta cunfigurazione ùn avia assolutamente nisun mecanismu di aghjurnamentu. Dunque, aghjunghjeremu qualchì nova funzione, è dopu seria una vera seccatura distribuisce à tutti i server client. Ma ci ghjunghjeremu più tardi, à u so tempu.

Avemu fattu u primu prototipu. Hè statu capace di ping i dispositi di a reta di u cliente è i servitori chì avemu bisognu è mandà sta dati à u nostru servitore cintrali. È ellu, à u turnu, aghjurnà sta dati in massa nantu à u servitore cintrali. Quì scriveraghju micca solu una storia nantu à cumu è ciò chì hà successu, ma ancu ciò chì i sbagli amatori sò stati fatti è cumu dopu avè avutu a pagari cù u tempu. Allora, tuttu l'arbulu di l'uggetti hè stata guardata in un unicu schedariu in a forma di un ughjettu serializatu. Mentre avemu cunnessu parechji clienti à u sistema, tuttu era più o menu normale, ancu s'ellu ci era qualchì volta alcuni artefatti chì eranu completamente incomprensibili. Ma quandu avemu cunnessu una decina di servitori à u sistema, i miraculi cuminciaru à accade. Calchì volta, per qualchì mutivu scunnisciutu, tutti l'uggetti in u sistema simpricimenti spariti. Hè impurtante di nutà quì chì i servitori chì i clienti avianu mandatu dati à u servitore cintrali ogni pocu seconde via una dumanda POST. Un lettore attentu è un programatore espertu hà digià capitu chì ci era un prublema di accessu multiplu à u schedariu stessu in quale l'ughjettu serializatu era almacenatu da diverse fili à u stessu tempu. È ghjustu quandu questu succidia, i miraculi sò accaduti cù a sparizione di l'uggetti. U schedariu hè diventatu viotu. Ma tuttu questu ùn hè micca scupertu immediatamente, ma solu durante l'operazione cù parechji servitori. Duranti stu tempu, a funziunalità di scanning portu hè stata aghjunta (i servitori mandati à u centru micca solu l'infurmazioni nantu à a dispunibilità di i dispositi, ma ancu nantu à i porti aperti nantu à elli). Questu hè statu fattu chjamendu u cumandamentu:

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

i risultati eranu spessu sbagliati è scans pigghiau assai tempu à compie. Mi sò completamente scurdatu di ping, hè stata fatta via fping:

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

Questu hè ancu micca parallelizatu è per quessa u prucessu era assai longu. In seguitu, tutta a lista di l'indirizzi IP necessarii per a verificazione hè stata mandata à fping in una volta, è torna avemu ricevutu una lista pronta di quelli chì anu rispostu. A cuntrariu di noi, fping hà sappiutu parallelizà i prucessi.

Un altru travagliu di rutina cumuni era a creazione di alcuni servizii via WEB. Ebbè, per esempiu, ECP da MS Exchange. In fondu hè solu un ligame. È avemu decisu chì avemu bisognu di pudè aghjunghje tali ligami direttamente à u sistema, per ùn avè micca bisognu di circà in a documentazione o in un altru locu in i marcatori per cumu accede à l'ECP di un cliente specificu. Hè cusì chì u cuncettu di ligami di risorse per u sistema apparsu, a so funziunalità hè dispunibule finu à questu ghjornu è ùn hà micca cambiatu, bè, quasi.

Cumu funziona i ligami di risorse in Veliam
Da l'outsourcing à u sviluppu (Parte 1)

Cunnessioni remoti

Questu hè ciò chì pare in azzione in a versione attuale di Veliam
Da l'outsourcing à u sviluppu (Parte 1)

Unu di i travaglii era di cunnette rapidamente è convenientemente à i servitori, di i quali ci era digià assai (più di centu) è l'ordine per milioni di scorciatoie RDP pre-salvatu era estremamente inconveniente. Un strumentu era necessariu. Ci hè un software in Internet chì hè qualcosa cum'è un libru d'indirizzu per tali cunnessione RDP, ma ùn sò micca integrati cù u sistema di surviglianza, è i cunti ùn ponu esse salvati. Ingressu cunti per diversi clienti ogni volta hè un infernu puru quandu cunnette decine di volte à ghjornu à diversi servitori. Cù SSH, e cose sò un pocu megliu, ci hè assai bonu software chì vi permette di urganizà tali cunnessione in cartulare è ricurdate i cunti da elli. Ma ci sò 2 prublemi. U primu hè chì ùn avemu micca truvatu un solu prugramma per e cunnessione RDP è SSH. U sicondu hè chì se in un certu puntu ùn sò micca in u mo urdinatore è aghju bisognu di cunnette rapidamente, o solu reinstallatu u sistema, aghju da andà in a documentazione per vede u contu da stu cliente. Hè inconveniente è una perdita di tempu.

A struttura gerarchica chì avemu bisognu per i servitori di u cliente era digià dispunibule in u nostru pruduttu internu. Aviu avutu solu per capisce cumu aghjunghje cunnessione rapida à l'equipaggiu necessariu. Per principianti, almenu in a vostra reta.

Cunsiderendu chì u cliente in u nostru sistema era un navigatore chì ùn avia accessu à e risorse lucali di l'urdinatore, per lancià simpliciamente l'applicazione chì ci vulia cù qualchì cumandamentu, hè statu decisu di fà tuttu per mezu di "Windows schema d'URL persunalizatu." Cusì hè cum'è hè apparsu un "plugin" per u nostru sistema, chì includeva simpliciamente Putty è Remote Desktop Plus è, dopu l'installazione, registrava simpliciamente u schema URI in WindowsAvà, ogni volta chì vuliamu cunnetteci à un ughjettu via RDP o SSH, cliccavamu nantu à quella azzione in u nostru sistema, è l'URI persunalizatu si mette in opera. U mstsc.exe standard integratu in Windows o PuTTY, chì era inclusu cum'è parte di un "plugin". Aghju messu a parola "plugin" trà virgulette perchè ùn hè micca un plugin di navigatore in u sensu classicu.

Era almenu qualcosa. Un libru d'indirizzi praticu. È in u casu di Putty, tuttu andava bè; puderia esse furnitu cù l'indirizzu IP di cunnessione, u login è a password cum'è parametri d'input. Vale à dì, Linux Ci cunnettevamu digià à i servitori di a nostra rete cù un solu clic, senza inserisce password. Ma RDP ùn hè micca cusì simplice. Ùn pudete micca passà credenziali cum'è parametri à u mstsc standard. Remote Desktop Plus hè ghjuntu à u salvamentu. Ci hà permessu di fà questu. Dapoi ci simu arrangiati senza, ma per un bellu pezzu, hè statu un assistente affidabile in u nostru sistema. I siti HTTP (S) sò faciuli; tali oggetti si aprenu solu in u navigatore è basta. Cunveniente è praticu. Ma questu era solu una benedizione per a rete interna.

Siccomu avemu risoltu a grande maggioranza di i prublemi à distanza da l'uffiziu, u modu u più faciule era di cunfigurà VPN per i clienti. Dopu pudemu cunnetteci da u nostru sistema. Ma era sempre un pocu inconveniente. Per ogni cliente, duviamu tene un inseme di password almacenate in ogni urdinatore. VPN Cunnessione, è prima di cunnette si à qualsiasi, a VPN currispundente duvia esse attivata. Avemu utilizatu sta suluzione per un bellu pezzu. Ma u numeru di clienti cresceva, cum'è u numeru di VPN, è tuttu què cuminciava à diventà fastidiosu, è qualcosa duvia esse fattu per quessa. Era particularmente lacrimevule dopu avè reinstallatu u sistema, quandu aghju avutu à rientre decine di cunnessione VPN in un novu prufilu Windows. Aghju dettu: "Ne aghju avutu abbastanza", è aghju cuminciatu à pensà à ciò chì si pudia fà per quessa.

Hè accadutu chì tutti i clienti avianu dispositi da a famosa cumpagnia Mikrotik cum'è routers. Sò assai funziunali è convenienti per fà quasi ogni attività. U svantaghju hè chì sò "hijacked". Avemu risoltu stu prublema solu chjudendu tutti l'accessu da l'esternu. Ma era necessariu di qualchì manera avè accessu à elli senza vene à u locu di u cliente, perchè ... hè longu. Avemu simpliciamente fattu tunnel per ogni tali Mikrotik è siparati in una piscina separata. senza alcunu routing, perchè ùn ci hè micca una cunnessione di a vostra reta cù e rete di clienti è e so rete cù l'altri.

L'idea hè nata per assicurà chì quandu cliccu nantu à l'ughjettu chì aghju bisognu in u sistema, u servitore di surviglianza cintrali, sapendu i cunti SSH di tutti i clienti Mikrotik, cunnetta à l'ughjettu desideratu, crea una regula di spedizione à l'ospite desideratu cù u portu necessariu. Ci sò parechji punti quì. A suluzione ùn hè micca universale - hà da travaglià solu per Mikrotik, postu chì a sintassi di cumanda hè diversa per tutti i routers. Inoltre, tali trasmissioni anu da esse eliminate in qualchì modu, è a parte di u servitore di u nostru sistema essenzialmente ùn pudia micca seguità in alcun modu se aghju finitu a mo sessione RDP. Ebbè, tali trasmissioni hè un pirtusu per u cliente. Ma ùn avemu micca perseguitu l'universalità, perchè ... u pruduttu hè stata utilizata solu in a nostra cumpagnia è ùn ci era micca pensamentu di liberà à u publicu.

Ognunu di i prublemi hè stata risolta in u so modu. Quandu a regula hè stata creata, questa spedizione era dispunibule solu per un indirizzu IP esternu specificu (da quale a cunnessione hè stata inizializzata). Cusì hè stata evitata una fossa di sicurità. Ma cù ogni tali cunnessione, una regula Mikrotik hè stata aghjunta à a pagina NAT è ùn hè micca sbulicata. E ognunu sapi chì più regule ci sò, più u processatore di u router hè carricu. È in generale, ùn pudia accettà chì un ghjornu andaraghju à qualchi Mikrotik, è ci saria cintinara di morti, reguli inùtuli.

Siccomu u nostru servitore ùn pò micca seguità u statutu di cunnessione, lasciate chì Mikrotik li traccia stessu. È aghju scrittu un script chì monitorava constantemente tutte e regule di spedizione cù una descrizzione specifica è verificatu se a cunnessione TCP avia una regula adattata. S'ellu ùn ci hè micca statu unu per qualchì tempu, allura a cunnessione hè probabilmente digià cumpletata è questu rinviu pò esse sguassatu. Tuttu hà travagliatu, u script hà travagliatu bè.

Per via, quì hè:

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

Di sicuru, puderia esse fattu più bella, più veloce, etc., ma hà travagliatu, ùn hà micca caricatu Mikrotik è hà fattu un travagliu eccellente. Pudemu finalmente cunnette cù i servitori di i clienti è l'equipaggiu di rete cù un solu clic. Senza apre una VPN o inserisce password. U sistema hè diventatu veramente convenientu per travaglià. U tempu di serviziu hè stata ridutta, è tutti avemu passatu u tempu di travaglià piuttostu chè di cunnette cù l'uggetti necessarii.

Mikrotik Backup

Avemu cunfiguratu una copia di salvezza di tutti i Mikrotik à FTP. È in generale tuttu era bè. Ma quandu avete bisognu di piglià una copia di salvezza, avete bisognu à apre stu FTP è cercate quì. Avemu un sistema induve tutti i routers sò cunnessi, pudemu cumunicà cù i dispositi via SSH. Perchè ùn facemu micca cusì chì u sistema stessu piglia backups da tutti i Mikrotik ogni ghjornu, pensu. È hà cuminciatu à implementà. Avemu cunnessu, avemu fattu una copia di salvezza è l'hà purtatu à u almacenamiento.

Codice di script in PHP per piglià una copia di salvezza da 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');

?>

A copia di salvezza hè presa in duie forme - cunfigurazione binari è testu. U binariu aiuta à restaurà rapidamente a cunfigurazione necessaria, è u testu vi permette di capisce ciò chì deve esse fattu s'ellu ci hè un rimpiazzamentu furzatu di l'equipaggiu è u binariu ùn pò micca esse caricatu. In u risultatu, avemu avutu una altra funziunalità còmuda in u sistema. Inoltre, quandu aghjunghjenu novu Mikrotik, ùn ci era micca bisognu di cunfigurà nunda, aghju aghjustatu solu l'ughjettu à u sistema è stabilisce un contu per questu via SSH. Allora u sistema stessu hà cura di piglià backups. A versione attuale di SaaS Veliam ùn hà ancu sta funziunalità, ma l'averemu prestu.

Screenshots di ciò chì pareva in u sistema internu
Da l'outsourcing à u sviluppu (Parte 1)

Transizione à u almacenamentu di basa di dati normale

Aghju digià scrittu sopra chì l'artefatti apparsu. A volte, a lista sana di l'uggetti in u sistema hè sparita solu, qualchì volta quandu editate un ughjettu, l'infurmazioni ùn sò micca salvate è l'ughjettu hà da esse rinominatu trè volte. Questu irritava tutti terribilmente. A scumparsa di l'uggetti hè accadutu raramente, è hè stata facilmente restaurata da a ristaurazione di stu schedariu assai, ma i fallimenti in l'edità di l'ogetti sò accaduti abbastanza spessu. Probabilmente, inizialmente ùn aghju micca fattu questu per mezu di a basa di dati perchè ùn hè micca adattatu in a mo mente cumu era pussibule di mantene un arbulu cù tutte e cunnessione in una tavola plana. Hè pianu, ma l'arbulu hè gerarchicu. Ma una bona suluzione per l'accessu multiple, è dopu (cum'è u sistema diventa più cumplessu) transazzione, hè un DBMS. Probabilmente ùn sò micca u primu à scuntrà stu prublema. Aghju cuminciatu à google. Hè risultatu chì tuttu era digià inventatu prima di mè è ci sò parechji algoritmi chì custruiscenu un arbulu da una tavula plana. Dopu à circà à ognunu, aghju implementatu unu di elli. Ma questu era digià una nova versione di u sistema, perchè ... In fatti, per via di questu, aghju avutu à riscrive assai assai. U risultatu era naturali, i prublemi di cumpurtamentu aleatoriu di u sistema si n'andò. Qualchidunu pò dì chì l'errori sò assai dilettanti (scripts single-threaded, almacenà infurmazione chì hè stata accede parechje volte simultaneamente da diversi filamenti in un schedariu, etc.) in u campu di u sviluppu di software. Forsi questu hè veru, ma u mo travagliu principale era l'amministrazione, è a prugrammazione era una mossa laterale per a mo ànima, è simpricimenti ùn aghju micca avutu l'esperienza di travaglià in una squadra di programatori, induve tali cose basi mi sò state immediatamente suggerite da u mo anzianu. camaradi. Per quessa, aghju pienu tutti questi bumps nantu à u mo propiu, ma aghju amparatu u materiale assai bè. È dinò, u mo travagliu implica riunioni cù i clienti, azzioni destinate à pruvà à prumove a cumpagnia, una mansa di prublemi amministrativi in ​​a cumpagnia, è assai, assai di più. Ma d'una manera o di l'altru, ciò chì era digià era in dumanda. I picciotti è aghju utilizatu u pruduttu in u nostru travagliu di ogni ghjornu. Ci sò stati idee è suluzioni francamente senza successu nantu à quale u tempu hè persu, ma à a fine hè diventatu chjaru chì questu ùn era micca un strumentu di travagliu è nimu l'utilizava è ùn hè micca finitu in Veliam.

Helpdesk - HelpDesk

Ùn saria micca sbagliatu di mintuvà cumu hè statu furmatu HelpDesk. Questa hè una storia completamente diversa, perchè ... in Veliam questu hè digià a 3rd versione completamente nova, chì hè sfarente di tutti i precedenti. Avà hè un sistema simplice, intuitivu senza campane è fischi innecessarii, cù a capacità di integrà cù un duminiu, è ancu a capacità di accede à u stessu prufilu d'utilizatore da ogni locu utilizendu un ligame da un email. È più importantemente, hè pussibule cunnetta cù u candidatu via VNC da ogni locu (in casa o in l'uffiziu) direttamente da l'applicazione senza VPN o port forwarding. Vi dicu cumu avemu ghjuntu à questu, ciò chì hè accadutu prima è chì decisioni terribili sò state prese.

Avemu cunnessu cù l'utilizatori attraversu u famosu TeamViewer. Tutti l'urdinatori chì i so utilizatori servimu sò installati TV. A prima cosa chì avemu fattu male, è dopu l'avete eliminata, era ligà ogni cliente HD à hardware. Cumu l'utilizatore hà logatu in u sistema HD per lascià una dumanda? In più di a TV, tutti avianu una utilità speciale installata nantu à i so computer, scritta in Lazarus (assai persone quì sferiscenu l'ochji, è forse ancu andà in Google ciò chì hè, ma a megliu lingua cumpilata ch'e cunnosci era Delphi, è Lazarus hè guasi). listessa cosa, solu gratis). In generale, l'utilizatore hà lanciatu un schedariu batch speciale chì hà lanciatu sta utilità, chì à u turnu leghje u HWID di u sistema è dopu chì u navigatore hè stata lanciata è l'autorizazione hè accaduta. Perchè hè statu fattu questu? In certi cumpagnii, u numeru di utilizatori servitu hè cuntatu individualmente, è u prezzu di serviziu per ogni mese hè basatu annantu à u numeru di persone. Questu hè comprensibile, dite, ma perchè hè ligatu à u hardware? Moltu simplice, certi individui sò ghjunti in casa è anu fattu una dumanda da u so laptop di casa in u stilu di "Fate tuttu bellu per mè quì". In più di leghje u sistema HWID, l'utilità hà tiratu l'attuale Teamviewer ID da u registru è ancu trasmessu à noi. Teamviewer hà una API per l'integrazione. È avemu fattu sta integrazione. Ma ci era una cattura. Per mezu di queste API, hè impussibile di cunnette à l'urdinatore di l'utilizatore quandu ùn hà micca iniziatu esplicitamente sta sessione è dopu avè pruvatu à cunnette cù questu, deve ancu cliccà "cunfirmà". À quellu tempu, ci pareva logicu chì nimu ùn deve cunnette senza a dumanda di l'utilizatori, è postu chì a persona hè in l'urdinatore, hà da inizià a sessione è risponde affirmatively à a dumanda di cunnessione remota. Tuttu hà fattu male. I candidati anu scurdatu di appughjà l'iniziu di a sessione, è anu da dì li questu in una conversazione telefonica. Stu tempu perdu è era frustrante da i dui lati di u prucessu. Inoltre, ùn hè micca pocu cumunu per tali mumenti quandu una persona abbanduneghja una dumanda, ma hè permessu di cunnette solu quandu parte per u pranzu. Perchè u prublema ùn hè micca criticu è ùn vole micca chì u so prucessu di travagliu sia interrottu. In cunsiquenza, ùn appughjà micca alcun buttone per permette a cunnessione. Hè cusì chì e funziunalità supplementari appariscenu quandu accede à HelpDesk - leghje l'ID di Teamviwer. Sapemu a password permanente chì hè stata utilizata durante l'installazione di Teamviewer. Più precisamente, solu u sistema a sapia, postu chì era custruitu in u installatore è in u nostru sistema. In cunsiquenza, ci era un buttone di cunnessione da l'applicazione clicchendu nantu à quale ùn ci era micca bisognu di aspittà per nunda, ma Teamviewer hà apertu immediatamente è una cunnessione hè accaduta. In u risultatu, ci era dui tipi di cunnessione pussibuli. Attraversu l'API Teamviewer ufficiale è a nostra auto-fatta. À a mo sorpresa, anu cessatu di usà u primu quasi subitu, ancu s'ellu ci era una struzzione per usà solu in casi speciali è quandu l'utilizatore stessu dà u passu. Tuttavia, dammi sicurezza avà. Ma hè risultatu chì i candidati ùn anu micca bisognu di questu. Sò tutti assolutamente bè cù esse cunnessi cun elli senza un buttone di cunferma. È postu chì questu hè u casu, a funzionalità di cunnessione API hè stata successivamente eliminata cum'è inutile.

Transizione à u multithreading in Linux

A quistione di accelerà u passaghju di un scanner di rete per l'apertura di una lista predeterminata di porti è un ping simplice di l'oggetti di a rete hè longu cuminciatu à esse. Quì, sicuru, a prima suluzione chì vene in mente hè multithreading. Siccomu u tempu principalu passatu nantu à u ping hè aspittendu chì u pacchettu sia tornatu, è u prossimu ping ùn pò micca principià finu à chì u pacchettu precedente hè tornatu, in cumpagnie chì anu avutu ancu 20+ servitori più l'equipaggiu di rete, questu hà digià travagliatu abbastanza lentamente. U puntu hè chì un pacchettu pò sparisce, ma ùn avvisate micca immediatamente l'amministratore di u sistema. Hè solu cessà di accettà tali spam assai rapidamente. Questu significa chì avete bisognu di ping ogni ughjettu più di una volta prima di fà una cunclusione nantu à l'inaccessibilità. Senza entre in troppu dettagliu, hè necessariu di parallelizzà, perchè s'ellu ùn hè micca fattu, u più prubabile chì l'amministratore di u sistema ampararà nantu à u prublema da u cliente, è micca da u sistema di surviglianza.

PHP stessu ùn sustene micca u multithreading fora di a scatula. Capace di multiprocessing, pudete fork. Ma, in fattu, aghju digià avutu un mecanismu di votu scrittu è vulia fà cusì chì una volta cuntà tutti i nodi chì avia bisognu di a basa di dati, ping tuttu in una volta, aspittà una risposta da ognunu è solu dopu scrive immediatamente. i dati. Questu salva u numeru di richieste di lettura. Multithreading si adatta perfettamente à questa idea. Per PHP ci hè un modulu PThreads chì vi permette di fà un veru multithreading, ancu s'ellu hà pigliatu una bona quantità di tinkering per stabilisce questu nantu à PHP 7.2, ma hè stata fatta. A scansione di u portu è u ping sò avà veloci. E invece di, per esempiu, 15 seconde per volta prima, stu prucessu hà cuminciatu à piglià 2 seconde. Era un bonu risultatu.

Verificazione rapida di e novi cumpagnie

Cumu hè ghjunta a funziunalità per cullà diverse metriche è caratteristiche hardware? Hè simplice. A volte ci hè solu urdinatu di audità l'infrastruttura IT attuale. Eppo, a stessa cosa hè necessariu per accelerà l'auditu di un novu cliente. Avemu bisognu di qualcosa chì ci permette di vene à una cumpagnia media o grande è capisce rapidamente ciò chì anu. In u mo parè, u ping nantu à a reta interna hè bluccatu solu da quelli chì volenu cumplicà a so propria vita, è in a nostra sperienza ci sò pocu di elli. Ma ci sò ancu tali persone. Per quessa, pudete scansà rapidamente e rete per a presenza di i dispositi cù un ping simplice. Allora pudemu aghjunghje è scansà i porti aperti chì ci interessanu. In fattu, sta funziunalità era digià esistita solu per aghjunghje un cumandamentu da u servitore cintrali à l'esclave per esse scansà e rete specificate è aghjunghje tuttu ciò chì hà truvatu à a lista. Aghju scurdatu di mintuvà, era presumitu chì avemu digià avutu una maghjina pronta cù un sistema cunfiguratu (servitore di monitoraghju slave) chì pudemu simplificà da u cliente durante un auditu è ​​cunnette à u nostru nuvulu.

Ma u risultatu di l'audit include di solitu un inseme d'infurmazioni diverse, è una di elle hè u tipu di dispusitivi chì sò in rete. Eramu principalmente interessati à Windows servitori è stazioni di travagliu Windows Cum'è parte di un duminiu. In l'imprese medie è grande, a mancanza di un duminiu hè probabilmente l'eccezzione piuttostu chè a regula. Per parlà a stessa lingua, una impresa di medie dimensioni, à parer mio, hè più di 100 persone. Avemu bisognu di truvà un modu per raccoglie dati da tutte e macchine è i servitori Windows, cunnoscendu i so indirizzi IP è i conti di l'amministratore di duminiu, senza avè da installà alcun software nantu à ognunu. L'interfaccia WMI hè ghjunta à u salvamentu. Windows Strumentazione di Gestione (WMI) significa letteralmente strumentazione di gestione WindowsWMI hè una di e tecnulugie basiche per a gestione centralizzata è u monitoraghju di varie parti di l'infrastruttura informatica sottu u cuntrollu di a piattaforma. WindowsPigliatu da u wiki. Dopu aghju avutu à armeghjà torna per custruisce wmic (un cliente WMI) per DebianUna volta chì tuttu era prontu, tuttu ciò chì restava era di dumandà i nodi richiesti via wmic per l'infurmazioni richieste. Via WMI, pudete ottene Windows urdinatore guasi ogni infurmazione, è in più, pudete ancu cuntrullà l'urdinatore per mezu di questu, per esempiu, mandallu à riavvià. Eccu cumu a cullezzione d'infurmazioni nantu à Windows stazioni è servitori in u nostru sistema. Questu hè statu cumplementatu da informazioni attuali nantu à l'indicatori di carica di u sistema attuale. Li dumandemu più spessu, mentre chì l'infurmazioni nantu à l'hardware sò menu frequenti. Dopu questu, l'auditing hè diventatu un pocu più piacevule.

Decisione di distribuzione di software

Avemu noi stessi aduprà u sistema ogni ghjornu, è hè sempre apertu per ogni impiigatu tecnicu. È avemu pensatu chì pudemu sparte cù l'altri ciò chì avemu digià. U sistema ùn era ancu prontu per esse distribuitu. Assai duvia esse rielaboratu in modu chì a versione lucale diventerà SaaS. Questi includenu cambiamenti in diversi aspetti tecnichi di u sistema (connessioni remoti, serviziu di supportu), analisi di moduli per licenze, sharding di basa di dati di i clienti, scaling di ogni serviziu, è sviluppu di sistemi d'aghjurnamentu automaticu per tutte e parte. Ma questu serà a seconda parte di l'articulu.

vagabonda

Seconda parte

Source: www.habr.com

Cumprate un hosting affidabile per i siti cù prutezzione DDoS, servitori VPS VDS 🔥 Cumprate un hosting di siti web affidabile cù prutezzione DDoS, servitori VPS VDS | ProHoster