O gontract allanol i ddatblygiad (Rhan 1)

Helo pawb, fy enw i yw Sergey Emelianchik. Fi yw pennaeth y cwmni Audit-Telecom, prif ddatblygwr ac awdur system Veliam. Penderfynais ysgrifennu erthygl am sut y creodd fy ffrind a minnau gwmni allanol, ysgrifennu meddalwedd i ni ein hunain ac wedi hynny dechreuais ei ddosbarthu i bawb trwy'r system SaaS. Ynglŷn â sut yn bendant nid oeddwn yn credu bod hyn yn bosibl. Bydd yr erthygl yn cynnwys nid yn unig stori, ond hefyd fanylion technegol ar sut y crëwyd y cynnyrch Veliam. Gan gynnwys rhai darnau o god ffynhonnell. Byddaf yn dweud wrthych pa gamgymeriadau a wnaethom a sut y gwnaethom eu cywiro yn ddiweddarach. Roedd amheuon a ddylid cyhoeddi erthygl o'r fath. Ond roeddwn i'n meddwl ei bod yn well ei wneud, cael adborth a gwella, na pheidio â chyhoeddi'r erthygl a meddwl beth fyddai wedi digwydd pe bai...

cynhanes

Gweithiais mewn un cwmni fel gweithiwr TG. Roedd y cwmni'n eithaf mawr gyda strwythur rhwydwaith helaeth. Ni fyddaf yn canolbwyntio ar fy nghyfrifoldebau swydd, ni fyddaf ond yn dweud nad oeddent yn bendant yn cynnwys datblygiad unrhyw beth.

Roedd gennym ni fonitro, ond o ddiddordeb academaidd yn unig roeddwn i eisiau ceisio ysgrifennu fy un symlaf fy hun. Y syniad oedd hyn: roeddwn i eisiau iddo fod ar y we, fel y gallwn i fynd i mewn yn hawdd heb osod unrhyw gleientiaid a gweld beth oedd yn digwydd gyda'r rhwydwaith o unrhyw ddyfais, gan gynnwys dyfais symudol trwy Wi-Fi, a minnau hefyd mewn gwirionedd eisiau deall yn gyflym beth Mae offer yn yr ystafell sydd wedi dod yn “mopei” oherwydd... roedd gofynion llym iawn o ran amser ymateb i broblemau o'r fath. O ganlyniad, ganwyd cynllun yn fy mhen i ysgrifennu tudalen we syml lle'r oedd cefndir jpeg gyda diagram rhwydwaith, torri allan y dyfeisiau eu hunain gyda'u cyfeiriadau IP yn y llun hwn, a dangos cynnwys deinamig ar ben y llun yn y cyfesurynnau gofynnol ar ffurf cyfeiriad IP gwyrdd neu goch sy'n fflachio. Mae'r dasg wedi'i gosod, gadewch i ni ddechrau.

Yn flaenorol, roeddwn yn rhaglennu yn Delphi, PHP, JS ac yn arwynebol iawn C ++. Rwy'n gwybod yn eithaf da sut mae rhwydweithiau'n gweithio. VLAN, Llwybro (OSPF, EIGRP, BGP), NAT. Roedd hyn yn ddigon i mi ysgrifennu prototeip monitro cyntefig fy hun.

Ysgrifennais yr hyn yr oeddwn yn bwriadu yn PHP. Roedd gweinydd Apache a PHP ar Windows oherwydd ... Roedd Linux i mi ar y foment honno yn rhywbeth annealladwy a chymhleth iawn, fel y digwyddodd yn ddiweddarach, roeddwn i'n camgymryd yn fawr ac mewn sawl man mae Linux yn llawer symlach na Windows, ond mae hwn yn bwnc ar wahân ac rydyn ni i gyd yn gwybod faint o holivars sydd ymlaen y pwnc hwn. Tynnodd trefnydd tasgau Windows ar gyfnod bach (nid wyf yn cofio'n union, ond rhywbeth fel unwaith bob tair eiliad) sgript PHP a holodd yr holl wrthrychau gyda phing banal ac arbed y cyflwr i ffeil.

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

Ie, ie, nid oedd gweithio gyda chronfa ddata ar yr adeg honno hefyd wedi'i feistroli i mi. Doeddwn i ddim yn gwybod ei bod hi'n bosibl cyfochri prosesau, a chymerodd amser hir i fynd trwy'r holl nodau rhwydwaith, oherwydd... digwyddodd hyn mewn un llinyn. Cododd problemau yn arbennig pan nad oedd sawl nod ar gael, oherwydd gohiriodd pob un ohonynt y sgript am 300 ms. Ar ochr y cleient roedd swyddogaeth dolennu syml a oedd, o fewn ychydig eiliadau, yn llwytho gwybodaeth wedi'i diweddaru o'r gweinydd gyda chais Ajax ac yn diweddaru'r rhyngwyneb. Wel, felly, ar ôl 3 ping aflwyddiannus yn olynol, pe bai tudalen we gyda monitro ar agor ar y cyfrifiadur, roedd cyfansoddiad siriol yn chwarae.

Pan weithiodd popeth allan, cefais fy ysbrydoli'n fawr gan y canlyniad a meddyliais y gallwn ychwanegu mwy ato (oherwydd fy ngwybodaeth a'm galluoedd). Ond nid oeddwn bob amser yn hoffi systemau gyda miliwn o siartiau, yr oeddwn yn meddwl bryd hynny, ac yn dal i feddwl hyd heddiw, yn ddiangen yn y rhan fwyaf o achosion. Roeddwn i eisiau rhoi dim ond yr hyn a fyddai'n fy helpu i yn fy ngwaith. Erys yr egwyddor hon yn sylfaenol i ddatblygiad Veliam hyd heddiw. Ymhellach, sylweddolais y byddai'n cŵl iawn pe na bai'n rhaid i mi gadw monitro ar agor a gwybod am broblemau, a phan ddigwyddodd, yna agorwch y dudalen a gweld ble mae'r nod rhwydwaith problemus hwn wedi'i leoli a beth i'w wneud ag ef nesaf . Rhywsut wnes i ddim darllen e-bost bryd hynny, yn syml wnes i ddim ei ddefnyddio. Deuthum ar draws ar y Rhyngrwyd bod pyrth SMS y gallwch anfon cais GET neu POST iddynt, a byddant yn anfon SMS i fy ffôn symudol gyda'r testun rwy'n ei ysgrifennu. Sylweddolais yn syth fy mod i wir eisiau hyn. A dechreuais astudio'r ddogfennaeth. Ar ôl peth amser llwyddais, a nawr derbyniais SMS am broblemau ar y rhwydwaith ar fy ffôn symudol gydag enw “gwrthrych wedi cwympo”. Er bod y system yn gyntefig, fe’i hysgrifennwyd gennyf fi fy hun, a’r peth pwysicaf a’m hysgogodd i’w datblygu oedd ei bod yn rhaglen ymgeisio a oedd yn help mawr i mi yn fy ngwaith.

Ac yna daeth y diwrnod pan aeth un o'r sianeli Rhyngrwyd i lawr yn y gwaith, ac ni roddodd fy monitro i mi wybod amdano. Ers Google DNS dal pinged berffaith. Mae'n bryd meddwl sut y gallwch chi fonitro bod y sianel gyfathrebu yn fyw. Roedd syniadau gwahanol ar sut i wneud hyn. Nid oedd gennyf fynediad i'r holl offer. Roedd yn rhaid i ni ddarganfod sut i ddeall pa un o'r sianeli sy'n fyw, ond heb allu ei weld ar yr offer rhwydwaith ei hun rywsut. Yna daeth cydweithiwr â'r syniad ei bod hi'n bosibl y gallai'r llwybr olrhain i weinyddion cyhoeddus amrywio yn dibynnu ar ba sianel gyfathrebu a ddefnyddir ar hyn o bryd i gael mynediad i'r Rhyngrwyd. Yr wyf yn gwirio ac mae'n troi allan y ffordd honno. Roedd gwahanol lwybrau wrth olrhain.

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

Felly ymddangosodd sgript arall, neu yn hytrach, am ryw reswm ychwanegwyd yr olrhain at ddiwedd yr un sgript, a oedd yn pingio pob dyfais ar y rhwydwaith. Wedi'r cyfan, mae hon yn broses hir arall a gyflawnwyd yn yr un edefyn ac arafu gwaith y sgript gyfan. Ond wedyn nid oedd mor amlwg. Ond un ffordd neu'r llall, gwnaeth ei waith, roedd y cod yn diffinio'n fanwl pa fath o olrhain ddylai fod ar gyfer pob un o'r sianeli. Dyma sut y dechreuodd y system weithio, a oedd eisoes yn monitro (meddai'n uchel, oherwydd nid oedd unrhyw gasgliad o unrhyw fetrigau, ond dim ond ping) dyfeisiau rhwydwaith (llwybryddion, switshis, wi-fi, ac ati) a sianeli cyfathrebu â'r byd y tu allan . Roedd negeseuon SMS yn cyrraedd yn rheolaidd ac roedd y diagram bob amser yn dangos yn glir ble roedd y broblem.

Ymhellach, mewn gwaith bob dydd roedd yn rhaid i mi wneud croes-groesi. Ac fe wnes i flino ar fynd i switshis Cisco bob tro i weld pa ryngwyneb i'w ddefnyddio. Pa mor cŵl fyddai hi i glicio ar wrthrych wrth fonitro a gweld rhestr o'i ryngwynebau gyda disgrifiadau. Byddai'n arbed amser i mi. Ar ben hynny, yn y cynllun hwn ni fyddai angen rhedeg Putty neu SecureCRT i gofnodi cyfrifon a gorchmynion. Fe wnes i glicio ar y monitro, gweld beth oedd ei angen ac es i wneud fy ngwaith. Dechreuais chwilio am ffyrdd o ryngweithio â switshis. Deuthum ar unwaith ar draws 2 opsiwn: SNMP neu fewngofnodi i'r switsh trwy SSH, mynd i mewn i'r gorchmynion yr oeddwn eu hangen a dosrannu'r canlyniad. Gwrthodais SNMP oherwydd cymhlethdod ei weithrediad; roeddwn yn ddiamynedd i gael y canlyniad. gyda SNMP, byddai'n rhaid i chi gloddio i'r MIB am amser hir ac, yn seiliedig ar y data hwn, cynhyrchu data am y rhyngwynebau. Mae tîm gwych yn CISCO

show interface status

Mae’n dangos yn union beth sydd ei angen arnaf ar gyfer croesfannau. Pam trafferthu gyda SNMP pan dwi eisiau gweld allbwn y gorchymyn hwn, meddyliais. Ar ôl peth amser, sylweddolais y cyfle hwn. Wedi clicio ar wrthrych ar dudalen we. Sbardunwyd digwyddiad pan gysylltodd y cleient AJAX â'r gweinydd, ac fe gysylltodd, yn ei dro, trwy SSH â'r switsh yr oedd ei angen arnaf (roedd y manylion wedi'u codio'n galed i'r cod, nid oedd unrhyw awydd i'w fireinio, i wneud rhai dewislenni ar wahân lle byddai'n bosibl newid cyfrifon o'r rhyngwyneb , roedd angen y canlyniad arnaf ac yn gyflym) rhoddais y gorchymyn uchod yno a'i anfon yn ôl i'r porwr. Felly dechreuais weld gwybodaeth am ryngwynebau gydag un clic o'r llygoden. Roedd hyn yn hynod o gyfleus, yn enwedig pan oedd yn rhaid i chi weld y wybodaeth hon ar wahanol switshis ar unwaith.

Yn y pen draw nid monitro sianel yn seiliedig ar olrhain oedd y syniad gorau, oherwydd ... weithiau roedd gwaith yn cael ei wneud ar y rhwydwaith, a gallai'r olrhain newid a dechreuodd y monitro sgrechian arnaf fod problemau gyda'r sianel. Ond ar ôl treulio llawer o amser ar ddadansoddi, sylweddolais fod pob sianel yn gweithio, ac roedd fy monitro yn fy nhwyllo. O ganlyniad, gofynnais i'm cydweithwyr a oedd yn rheoli switshis ffurfio sianeli anfon syslog ataf pan newidiodd statws gwelededd cymdogion. Yn unol â hynny, roedd yn llawer symlach, cyflymach a mwy cywir nag olrhain. Mae digwyddiad fel cymydog ar goll wedi cyrraedd, ac rwy'n cyhoeddi hysbysiad ar unwaith am y sianel i lawr.

Ymhellach, ymddangosodd sawl gorchymyn arall wrth glicio ar wrthrych, ac ychwanegwyd SNMP i gasglu rhai metrigau, a dyna ni yn y bôn. Ni ddatblygodd y system ymhellach. Gwnaeth bopeth yr oeddwn ei angen, roedd yn arf da. Mae'n debyg y bydd llawer o ddarllenwyr yn dweud wrthyf fod llawer o feddalwedd eisoes ar y Rhyngrwyd i ddatrys y problemau hyn. Ond mewn gwirionedd, wnes i ddim google cynnyrch rhad ac am ddim o'r fath bryd hynny ac roeddwn i wir eisiau datblygu fy sgiliau rhaglennu, a pha ffordd well i wthio am hyn na phroblem cymhwysiad go iawn. Ar y pwynt hwn, cwblhawyd y fersiwn gyntaf o fonitro ac ni chafodd ei haddasu mwyach.

Creu'r cwmni Audit-Telecom

Wrth i amser fynd heibio, dechreuais weithio'n rhan-amser mewn cwmnïau eraill, yn ffodus roedd fy amserlen waith yn caniatáu i mi wneud hyn. Pan fyddwch chi'n gweithio mewn cwmnïau gwahanol, mae eich sgiliau mewn meysydd amrywiol yn tyfu'n gyflym iawn, ac mae'ch gorwelion yn datblygu'n dda. Mae yna gwmnïau lle rydych chi, fel maen nhw'n dweud, yn Swede, yn fedelwr, ac yn chwaraewr trwmped. Ar y naill law, mae'n anodd, ar y llaw arall, os nad ydych chi'n ddiog, rydych chi'n dod yn gyffredinolwr ac mae hyn yn caniatáu ichi ddatrys problemau yn gyflymach ac yn fwy effeithlon oherwydd eich bod chi'n gwybod sut mae'r maes cysylltiedig yn gweithio.

Roedd fy ffrind Pavel (hefyd yn arbenigwr TG) yn ceisio fy annog yn gyson i ddechrau ei fusnes ei hun. Roedd yna syniadau di-ri gyda gwahanol amrywiadau o'r hyn yr oeddent yn ei wneud. Mae hyn wedi cael ei drafod ers blynyddoedd. Ac yn y diwedd, ni ddylai fod wedi dod i unrhyw beth oherwydd fy mod yn amheuwr, ac mae Pavel yn freuddwydiwr. Bob tro y cynigiodd syniad, nid oeddwn bob amser yn credu ynddo a gwrthodais gymryd rhan. Ond roedden ni wir eisiau agor ein busnes ein hunain.

Yn olaf, roeddem yn gallu dod o hyd i opsiwn a oedd yn addas ar gyfer y ddau ohonom a gwneud yr hyn yr ydym yn gwybod sut i'w wneud. Yn 2016, fe benderfynon ni greu cwmni TG a fyddai’n helpu busnesau i ddatrys problemau TG. Dyma'r defnydd o systemau TG (1C, gweinydd terfynell, gweinydd post, ac ati), eu cynnal a chadw, Desg Gymorth glasurol ar gyfer defnyddwyr a gweinyddiaeth rhwydwaith.

A siarad yn blwmp ac yn blaen, ar adeg creu'r cwmni, doeddwn i ddim yn credu ynddo tua 99,9%. Ond rhywsut roedd Pavel yn gallu fy nghael i drio, ac wrth edrych ymlaen, fe drodd allan i fod yn iawn. Fe wnaeth Pavel a minnau roi 300 o rubles yr un, cofrestru LLC newydd “Audit-Telecom”, rhentu swyddfa fach, gwneud cardiau busnes cŵl, wel, yn gyffredinol, fel y rhan fwyaf o ddynion busnes dibrofiad, dibrofiad yn ôl pob tebyg, a dechrau chwilio am gleientiaid. Mae dod o hyd i gleientiaid yn stori hollol wahanol. Efallai y byddwn yn ysgrifennu erthygl ar wahân fel rhan o'r blog corfforaethol os oes gan unrhyw un ddiddordeb. Galwadau diwahoddiad, taflenni, ac ati. Ni roddodd hyn unrhyw ganlyniadau. Wrth i mi ddarllen nawr o lawer o straeon am fusnes, un ffordd neu'r llall, mae llawer yn dibynnu ar lwc. Buom yn ffodus. ac yn llythrennol ychydig wythnosau ar ôl creu'r cwmni, daeth fy mrawd Vladimir atom, a ddaeth â'n cleient cyntaf atom. Ni fyddaf yn diflasu arnoch gyda manylion gweithio gyda chleientiaid, nid dyna yw hanfod yr erthygl, byddaf yn dweud inni fynd am archwiliad, nodi meysydd hollbwysig a chwalodd y meysydd hyn tra gwnaed y penderfyniad ynghylch a ddylid. cydweithredu â ni yn barhaus fel contractwyr allanol. Ar ôl hyn, gwnaed penderfyniad cadarnhaol ar unwaith.

Yna, yn bennaf ar lafar trwy ffrindiau, dechreuodd cwmnïau gwasanaeth eraill ymddangos. Roedd y ddesg gymorth mewn un system. Mae cysylltiadau ag offer rhwydwaith a gweinyddwyr yn wahanol, neu braidd yn wahanol. Arbedodd rhai pobl lwybrau byr, defnyddiodd eraill lyfrau cyfeiriadau RDP. Mae monitro yn system arall ar wahân. Mae'n anghyfleus iawn i dîm weithio mewn systemau gwahanol. Mae gwybodaeth bwysig yn cael ei cholli. Wel, er enghraifft, nid oedd gweinydd terfynell y cleient ar gael. Derbynnir ceisiadau gan ddefnyddwyr y cleient hwn ar unwaith. Mae'r arbenigwr cymorth yn agor cais (fe'i derbyniwyd dros y ffôn). Pe bai digwyddiadau a cheisiadau'n cael eu cofrestru mewn un system, yna byddai'r arbenigwr cymorth yn gweld yn syth beth yw problem y defnyddiwr ac yn dweud wrtho amdani, gan gysylltu â'r gwrthrych gofynnol ar yr un pryd i weithio allan y sefyllfa. Mae pawb yn ymwybodol o'r sefyllfa dactegol ac yn gweithio'n gytûn. Nid ydym wedi dod o hyd i system lle mae hyn i gyd yn cael ei gyfuno. Daeth yn amlwg ei bod yn bryd gwneud ein cynnyrch ein hunain.

Gwaith parhaus ar eich system fonitro

Roedd yn amlwg bod y system a ysgrifennwyd yn gynharach yn gwbl anaddas ar gyfer y tasgau presennol. Nid o ran ymarferoldeb nac o ran ansawdd. A phenderfynwyd ysgrifennu'r system o'r dechrau. Yn graffigol dylai fod wedi edrych yn hollol wahanol. Roedd yn rhaid iddi fod yn system hierarchaidd fel y byddai modd agor y gwrthrych cywir yn gyflym ac yn gyfleus ar gyfer y cleient cywir. Nid oedd y cynllun fel yn y fersiwn gyntaf yn gwbl gyfiawn yn yr achos presennol, oherwydd Mae’r cleientiaid yn wahanol ac nid oedd ots o gwbl ym mha adeilad y lleolwyd yr offer. Mae hwn eisoes wedi'i drosglwyddo i'r ddogfennaeth.

Felly, y tasgau:

1. Strwythur hierarchaidd;
2. Rhyw fath o ran gweinydd y gellir ei gosod ar safle'r cleient ar ffurf peiriant rhithwir i gasglu'r metrigau sydd eu hangen arnom a'i anfon at y gweinydd canolog, a fydd yn crynhoi hyn i gyd ac yn ei ddangos i ni;
3. Rhybuddion. Y rhai na ellir eu colli, oherwydd... bryd hynny nid oedd yn bosibl i rywun eistedd ac edrych ar y monitor;
4. System ymgeisio. Dechreuodd cleientiaid ymddangos ac fe wnaethom wasanaethu nid yn unig offer gweinydd a rhwydwaith, ond hefyd gweithfannau;
5. Y gallu i gysylltu'n gyflym â gweinyddwyr ac offer o'r system;

Mae'r tasgau wedi'u gosod, rydyn ni'n dechrau ysgrifennu. Ar hyd y ffordd, prosesu ceisiadau gan gleientiaid. Bryd hynny roedd 4 ohonom eisoes. Dechreuon ni ysgrifennu'r ddwy ran ar unwaith: y gweinydd canolog a'r gweinydd i'w gosod i gleientiaid. Erbyn hyn, nid oedd Linux bellach yn ddieithr i ni a phenderfynwyd y byddai'r peiriannau rhithwir a fyddai gan gleientiaid ar Debian. Ni fydd unrhyw osodwyr, byddwn yn gwneud prosiect rhan gweinydd ar un peiriant rhithwir penodol, ac yna byddwn yn ei glonio i'r cleient a ddymunir. Camgymeriad arall oedd hwn. Yn ddiweddarach daeth yn amlwg nad oedd y mecanwaith diweddaru wedi'i ddatblygu'n llwyr mewn cynllun o'r fath. Y rhai. roeddem yn ychwanegu rhywfaint o nodwedd newydd, ac yna roedd yr holl broblem o'i ddosbarthu i bob gweinydd cleient, ond byddwn yn dod yn ôl at hyn yn ddiweddarach, popeth mewn trefn.

Fe wnaethon ni'r prototeip cyntaf. Llwyddodd i pingio'r dyfeisiau rhwydwaith cleientiaid a gweinyddwyr yr oedd eu hangen arnom ac anfon y data hwn i'n gweinydd canolog. Ac fe ddiweddarodd ef, yn ei dro, y data hwn mewn swmp ar y gweinydd canolog. Yma byddaf yn ysgrifennu nid yn unig stori am sut a beth oedd yn llwyddiannus, ond hefyd pa gamgymeriadau amatur a wnaethpwyd a pha mor ddiweddarach y bu'n rhaid i mi dalu amdano gydag amser. Felly, cafodd y goeden gyfan o wrthrychau ei storio mewn un ffeil ar ffurf gwrthrych cyfresol. Er ein bod yn cysylltu nifer o gleientiaid â'r system, roedd popeth yn fwy neu lai yn normal, er weithiau roedd rhai arteffactau a oedd yn gwbl annealladwy. Ond pan wnaethon ni gysylltu dwsin o weinyddion â'r system, dechreuodd gwyrthiau ddigwydd. Weithiau, am ryw reswm anhysbys, diflannodd yr holl wrthrychau yn y system. Mae'n bwysig nodi yma bod y gweinyddwyr yr oedd y cleientiaid wedi anfon data i'r gweinydd canolog bob ychydig eiliadau trwy gais POST. Roedd darllenydd sylwgar a rhaglennydd profiadol eisoes wedi dyfalu bod problem mynediad lluosog i'r union ffeil lle'r oedd y gwrthrych cyfresol yn cael ei storio o wahanol edafedd ar yr un pryd. A dim ond pan oedd hyn yn digwydd, digwyddodd gwyrthiau gyda diflaniad gwrthrychau. Yn syml, daeth y ffeil yn wag. Ond ni ddarganfuwyd hyn i gyd ar unwaith, ond dim ond yn ystod gweithrediad gyda sawl gweinydd. Yn ystod yr amser hwn, ychwanegwyd ymarferoldeb sganio porthladdoedd (y gweinyddwyr a anfonwyd at y canol nid yn unig gwybodaeth am argaeledd dyfeisiau, ond hefyd am y porthladdoedd sydd ar agor arnynt). Gwnaethpwyd hyn trwy alw'r gorchymyn:

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

roedd y canlyniadau'n aml yn anghywir a chymerodd amser hir i gwblhau'r sganiau. Anghofiais yn llwyr am ping, fe'i gwnaed trwy fping:

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

Nid oedd hyn ychwaith yn gyfochrog ac felly roedd y broses yn hir iawn. Yn ddiweddarach, anfonwyd y rhestr gyfan o gyfeiriadau IP sydd eu hangen ar gyfer dilysu i fping ar unwaith, ac yn ôl cawsom restr barod o'r rhai a ymatebodd. Yn wahanol i ni, roedd fping yn gallu cyfochri prosesau.

Swydd arferol arall oedd sefydlu rhai gwasanaethau trwy WEB. Wel, er enghraifft, ECP o MS Exchange. Yn y bôn, dim ond dolen ydyw. Ac fe wnaethom benderfynu bod angen i ni allu ychwanegu dolenni o'r fath yn uniongyrchol i'r system, er mwyn peidio â gorfod edrych yn y ddogfennaeth neu rywle arall mewn nodau tudalen ar sut i gael mynediad at ECP cleient penodol. Dyma sut yr ymddangosodd y cysyniad o gysylltiadau adnoddau ar gyfer y system, mae eu swyddogaeth ar gael hyd heddiw ac nid yw wedi newid, wel, bron.

Sut mae cysylltiadau adnoddau yn gweithio yn Veliam

Cysylltiadau o bell

Dyma sut mae'n edrych ar waith yn y fersiwn gyfredol o Veliam

Un o'r tasgau oedd cysylltu'n gyflym ac yn gyfleus â gweinyddwyr, ac roedd llawer ohonynt eisoes (mwy na chant) ac roedd didoli trwy filiynau o lwybrau byr CDG a arbedwyd ymlaen llaw yn anghyfleus iawn. Roedd angen teclyn. Mae meddalwedd ar y Rhyngrwyd sy'n rhywbeth fel llyfr cyfeiriadau ar gyfer cysylltiadau RDP o'r fath, ond nid ydynt wedi'u hintegreiddio â'r system fonitro, ac ni ellir cadw cyfrifon. Mae mynd i mewn i gyfrifon gwahanol gleientiaid bob tro yn uffern pur pan fyddwch chi'n cysylltu dwsinau o weithiau'r dydd â gwahanol weinyddion. Gyda SSH, mae pethau ychydig yn well; mae yna lawer o feddalwedd da sy'n eich galluogi i drefnu cysylltiadau o'r fath yn ffolderi a chofio'r cyfrifon ganddyn nhw. Ond mae yna 2 broblem. Y cyntaf yw na wnaethom ddod o hyd i un rhaglen ar gyfer cysylltiadau RDP a SSH. Yr ail yw, os nad wyf ar fy nghyfrifiadur ar ryw adeg a bod angen i mi gysylltu'n gyflym, neu rwyf newydd ailosod y system, bydd yn rhaid i mi fynd i mewn i'r ddogfennaeth i edrych ar y cyfrif gan y cleient hwn. Mae'n anghyfleus ac yn wastraff amser.

Roedd y strwythur hierarchaidd yr oedd ei angen arnom ar gyfer gweinyddwyr cleientiaid eisoes ar gael yn ein cynnyrch mewnol. Roedd yn rhaid i mi ddarganfod sut i gysylltu cysylltiadau cyflym â'r offer angenrheidiol yno. I ddechrau, o leiaf o fewn eich rhwydwaith.

Gan ystyried y ffaith bod y cleient yn ein system yn borwr nad oes ganddo fynediad at adnoddau lleol y cyfrifiadur, er mwyn lansio'r rhaglen yr oedd ei hangen arnom gyda rhywfaint o orchymyn, fe'i dyfeisiwyd i wneud popeth trwy'r “Windows cynllun url personol”. Dyma sut yr ymddangosodd “ategyn” penodol ar gyfer ein system, a oedd yn syml yn cynnwys Putty a Remote Desktop Plus ac, yn ystod y gosodiad, yn syml wedi cofrestru'r cynllun URI yn Windows. Nawr, pan oeddem am gysylltu â gwrthrych trwy RDP neu SSH, fe wnaethom glicio ar y weithred hon ar ein system a gweithiodd yr URI Custom. Lansiwyd y mstsc.exe safonol sydd wedi'i gynnwys yn Windows neu bwti, a oedd yn rhan o'r “ategyn”. Rhoddais y gair plugin mewn dyfyniadau oherwydd nid yw hwn yn ategyn porwr yn yr ystyr clasurol.

O leiaf roedd hynny'n rhywbeth. Llyfr cyfeiriadau cyfleus. Ar ben hynny, yn achos Putty, roedd popeth yn iawn ar y cyfan; gellid rhoi cysylltiadau IP, mewngofnodi a chyfrinair iddo fel paramedrau mewnbwn. Y rhai. Rydym eisoes wedi cysylltu â gweinyddwyr Linux ar ein rhwydwaith gydag un clic heb nodi cyfrineiriau. Ond gyda'r Cynllun Datblygu Gwledig nid yw mor syml â hynny. Ni all mstsc safonol gyflenwi tystlythyrau fel paramedrau. Daeth Remote Desktop Plus i'r adwy. Caniataodd i hyn ddigwydd. Nawr gallwn wneud hebddo, ond am amser hir bu'n gynorthwyydd ffyddlon yn ein system. Gyda gwefannau HTTP(S) mae popeth yn syml, mae gwrthrychau o'r fath yn agor yn y porwr a dyna ni. Cyfleus ac ymarferol. Ond dim ond hapusrwydd ar y rhwydwaith mewnol oedd hyn.

Ers i ni ddatrys y mwyafrif helaeth o broblemau o bell o'r swyddfa, y peth hawsaf oedd sicrhau bod VPNs ar gael i gleientiaid. Ac yna roedd yn bosibl cysylltu â nhw o'n system. Ond roedd yn dal i fod braidd yn anghyfleus. Ar gyfer pob cleient, roedd angen cadw criw o gysylltiadau VPN cofiadwy ar bob cyfrifiadur, a chyn cysylltu ag unrhyw un, roedd angen galluogi'r VPN cyfatebol. Fe wnaethon ni ddefnyddio'r datrysiad hwn am amser eithaf hir. Ond mae nifer y cleientiaid yn cynyddu, mae nifer y VPNs hefyd yn cynyddu, a dechreuodd hyn i gyd straen ac roedd yn rhaid gwneud rhywbeth yn ei gylch. Daeth dagrau i'm llygaid yn arbennig ar ôl ailosod y system, pan fu'n rhaid i mi ail-osod dwsinau o gysylltiadau VPN mewn proffil Windows newydd. Stopiwch ddioddef hyn, meddwn i, a dechreuais feddwl beth allwn i ei wneud am y peth.

Digwyddodd felly bod gan bob cleient ddyfeisiau gan y cwmni adnabyddus Mikrotik fel llwybryddion. Maent yn ymarferol iawn ac yn gyfleus ar gyfer cyflawni bron unrhyw dasg. Yr anfantais yw eu bod yn cael eu “herwgipio”. Fe wnaethom ddatrys y broblem hon yn syml trwy gau pob mynediad o'r tu allan. Ond roedd angen rhywsut cael mynediad atynt heb ddod i le'r cleient, oherwydd... mae'n hir. Yn syml, gwnaethom dwneli ar gyfer pob Mikrotik o'r fath a'u gwahanu'n bwll ar wahân. heb unrhyw lwybro, fel nad oes unrhyw gysylltiad o'ch rhwydwaith â rhwydweithiau cleientiaid a'u rhwydweithiau â'i gilydd.

Ganwyd y syniad i wneud yn siŵr, pan fyddaf yn clicio ar y gwrthrych sydd ei angen arnaf yn y system, bod y gweinydd monitro canolog, gan wybod cyfrifon SSH pob cleient Mikrotik, yn cysylltu â'r un a ddymunir, yn creu rheol anfon ymlaen at y gwesteiwr a ddymunir gyda'r porthladd gofynnol. Mae yna sawl pwynt yma. Nid yw'r ateb yn gyffredinol - dim ond i Mikrotik y bydd yn gweithio, gan fod cystrawen y gorchymyn yn wahanol ar gyfer pob llwybrydd. Hefyd, roedd yn rhaid dileu blaengyfeiriadau o'r fath rywsut, ac yn y bôn ni allai rhan gweinydd ein system olrhain mewn unrhyw ffordd a oeddwn wedi gorffen fy sesiwn RDP. Wel, mae anfon ymlaen o'r fath yn dwll i'r cleient. Ond wnaethon ni ddim mynd ar drywydd cyffredinolrwydd, oherwydd ... dim ond o fewn ein cwmni y defnyddiwyd y cynnyrch ac nid oedd unrhyw feddyliau am ei ryddhau i'r cyhoedd.

Datryswyd pob un o'r problemau yn ei ffordd ei hun. Pan grëwyd y rheol, dim ond ar gyfer un cyfeiriad IP allanol penodol yr oedd y cyfeiriad hwn ar gael (y cychwynnwyd y cysylltiad ohono). Felly cafodd twll diogelwch ei osgoi. Ond gyda phob cysylltiad o'r fath, ychwanegwyd rheol Mikrotik at dudalen NAT ac ni chafodd ei chlirio. Ac mae pawb yn gwybod po fwyaf o reolau sydd yna, y mwyaf y mae prosesydd y llwybrydd yn cael ei lwytho. Ac yn gyffredinol, ni allwn dderbyn y byddwn un diwrnod yn mynd i rai Mikrotik, a byddai cannoedd o reolau marw, diwerth.

Gan na all ein gweinydd olrhain statws y cysylltiad, gadewch i Mikrotik eu holrhain ei hun. Ac ysgrifennais sgript a oedd yn monitro'r holl reolau anfon ymlaen yn gyson gyda disgrifiad penodol ac yn gwirio a oedd gan y cysylltiad TCP reol addas. Os nad oes un wedi bod ers peth amser, mae'n debyg bod y cysylltiad eisoes wedi'i gwblhau a gellir dileu'r anfon hwn ymlaen. Gweithiodd popeth allan, gweithiodd y sgript yn dda.

Gyda llaw, dyma fe:

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

Yn sicr, gallai fod wedi'i wneud yn fwy prydferth, yn gyflymach, ac ati, ond fe weithiodd, ni lwythodd Mikrotik a gwnaeth waith rhagorol. O'r diwedd roeddem yn gallu cysylltu â gweinyddwyr cleientiaid ac offer rhwydwaith gydag un clic yn unig. Heb agor VPN na mynd i mewn i gyfrineiriau. Mae'r system wedi dod yn gyfleus iawn i weithio gyda hi. Lleihawyd amser gwasanaeth, a threuliasom i gyd amser yn gweithio yn hytrach na chysylltu â'r gwrthrychau angenrheidiol.

Mikrotik wrth gefn

Fe wnaethom ffurfweddu copi wrth gefn o'r holl Mikrotik i FTP. Ac ar y cyfan roedd popeth yn iawn. Ond pan oedd angen i chi gael copi wrth gefn, roedd yn rhaid ichi agor y FTP hwn a chwilio amdano yno. Mae gennym system lle mae'r holl lwybryddion wedi'u cysylltu; gallwn gyfathrebu â dyfeisiau trwy SSH. Pam na wnawn ni fel bod y system ei hun yn cymryd copïau wrth gefn o bob Mikrotik yn ddyddiol, meddyliais. A dechreuodd ei weithredu. Fe wnaethon ni gysylltu, gwneud copi wrth gefn a mynd ag ef i'r storfa.

Cod sgript yn PHP ar gyfer cymryd copi wrth gefn gan 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');

?>

Mae'r copi wrth gefn yn cael ei gymryd mewn dwy ffurf - deuaidd a ffurfwedd testun. Mae'r deuaidd yn helpu i adfer y cyfluniad gofynnol yn gyflym, ac mae'r testun un yn caniatáu ichi ddeall beth sydd angen ei wneud os oes angen amnewid offer ac na ellir llwytho'r deuaidd iddo. O ganlyniad, cawsom swyddogaeth gyfleus arall yn y system. Ar ben hynny, wrth ychwanegu Mikrotik newydd, nid oedd angen ffurfweddu unrhyw beth; Yn syml, ychwanegais y gwrthrych i'r system a gosod cyfrif ar ei gyfer trwy SSH. Yna roedd y system ei hun yn gofalu am gymryd copïau wrth gefn. Nid oes gan y fersiwn gyfredol o SaaS Veliam y swyddogaeth hon eto, ond byddwn yn ei drosglwyddo'n fuan.

Sgrinluniau o sut olwg oedd arno yn y system fewnol

Trosglwyddo i storfa gronfa ddata arferol

Ysgrifennais eisoes uchod bod arteffactau wedi ymddangos. Weithiau roedd y rhestr gyfan o wrthrychau yn y system yn diflannu, weithiau wrth olygu gwrthrych, ni arbedwyd y wybodaeth a bu'n rhaid ailenwi'r gwrthrych dair gwaith. Roedd hyn yn cythruddo pawb yn ofnadwy. Anaml y digwyddodd diflaniad gwrthrychau, ac roedd yn hawdd ei adfer trwy adfer yr union ffeil hon, ond roedd methiannau wrth olygu gwrthrychau yn digwydd yn eithaf aml. Yn ôl pob tebyg, ni wnes i hyn trwy'r gronfa ddata i ddechrau oherwydd nid oedd yn ffitio yn fy meddwl sut yr oedd yn bosibl cadw coeden gyda'r holl gysylltiadau mewn bwrdd gwastad. Mae'n wastad, ond mae'r goeden yn hierarchaidd. Ond ateb da ar gyfer mynediad lluosog, ac wedi hynny (wrth i'r system ddod yn fwy cymhleth) trafodaethol, yw DBMS. Mae'n debyg nad fi yw'r cyntaf i ddod ar draws y broblem hon. Dechreuais googling. Daeth i'r amlwg bod popeth eisoes wedi'i ddyfeisio o'm blaen ac mae yna sawl algorithm sy'n adeiladu coeden o fwrdd gwastad. Ar ôl edrych ar bob un, rhoddais un ohonynt ar waith. Ond roedd hwn eisoes yn fersiwn newydd o'r system, oherwydd ... Yn wir, oherwydd hyn, roedd yn rhaid i mi ailysgrifennu cryn dipyn. Roedd y canlyniad yn naturiol, aeth problemau ymddygiad ar hap y system i ffwrdd. Efallai y bydd rhai'n dweud bod y gwallau'n amaturaidd iawn (sgriptiau edau sengl, yn storio gwybodaeth y cyrchwyd sawl gwaith ar yr un pryd o wahanol edafedd mewn ffeil, ac ati) ym maes datblygu meddalwedd. Efallai bod hyn yn wir, ond gweinyddu oedd fy mhrif swydd, ac roedd rhaglennu yn fwrlwm o’r ochr i’m henaid, ac yn syml iawn nid oedd gennyf brofiad o weithio mewn tîm o raglenwyr, lle byddai pethau mor sylfaenol wedi cael eu hawgrymu ar unwaith i mi gan fy uwch dîm. cymrodyr. Felly, llenwais yr holl bumps hyn ar fy mhen fy hun, ond dysgais y deunydd yn dda iawn. A hefyd, mae fy swydd yn cynnwys cyfarfodydd gyda chleientiaid, camau gweithredu wedi'u hanelu at geisio hyrwyddo'r cwmni, criw o faterion gweinyddol o fewn y cwmni, a llawer, llawer mwy. Ond un ffordd neu'r llall, roedd galw am yr hyn oedd yno eisoes. Roedd y dynion a minnau'n defnyddio'r cynnyrch yn ein gwaith bob dydd. Roedd yna syniadau ac atebion aflwyddiannus a dweud y gwir ynghylch gwastraffu amser, ond yn y diwedd daeth yn amlwg nad oedd hwn yn arf gweithredol ac nad oedd neb yn ei ddefnyddio ac ni ddaeth i ben yn Veliam.

Desg Gymorth - Desg Gymorth

Ni fyddai'n anghywir sôn am sut y ffurfiwyd y Ddesg Gymorth. Mae hon yn stori hollol wahanol, oherwydd... yn Veliam dyma'r 3ydd fersiwn hollol newydd yn barod, sy'n wahanol i'r holl rai blaenorol. Nawr mae'n system syml, sythweledol heb glychau a chwibanau diangen, gyda'r gallu i integreiddio â pharth, yn ogystal â'r gallu i gael mynediad at yr un proffil defnyddiwr o unrhyw le gan ddefnyddio dolen o e-bost. Ac yn bwysicaf oll, mae'n bosibl cysylltu â'r ymgeisydd trwy VNC o unrhyw le (yn y cartref neu yn y swyddfa) yn uniongyrchol o'r cais heb VPN neu anfon porthladd ymlaen. Fe ddywedaf wrthych sut y daethom i hyn, beth ddigwyddodd o’r blaen a pha benderfyniadau ofnadwy a wnaed.

Fe wnaethon ni gysylltu â defnyddwyr trwy'r TeamViewer adnabyddus. Mae teledu wedi'i osod ar bob cyfrifiadur yr ydym yn ei wasanaethu. Y peth cyntaf a wnaethom yn anghywir, a'i ddileu wedyn, oedd cysylltu pob cleient HD â chaledwedd. Sut gwnaeth y defnyddiwr fewngofnodi i'r system HD er mwyn gadael cais? Yn ogystal â theledu, roedd gan bawb gyfleustodau arbennig wedi'u gosod ar eu cyfrifiaduron, a ysgrifennwyd yn Lasarus (bydd llawer o bobl yma yn rholio eu llygaid, ac efallai hyd yn oed yn mynd Google beth ydyw, ond yr iaith a luniwyd orau roeddwn i'n ei hadnabod oedd Delphi, ac mae Lasarus bron â bod yr un peth, dim ond am ddim). Yn gyffredinol, lansiodd y defnyddiwr ffeil swp arbennig a lansiodd y cyfleustodau hwn, a oedd yn ei dro yn darllen HWID y system ac ar ôl hynny lansiwyd y porwr a chafwyd awdurdodiad. Pam y gwnaed hyn? Mewn rhai cwmnïau, mae nifer y defnyddwyr gwasanaeth yn cael eu cyfrif yn unigol, ac mae pris y gwasanaeth ar gyfer pob mis yn seiliedig ar nifer y bobl. Mae hyn yn ddealladwy, meddech chi, ond pam ei fod ynghlwm wrth galedwedd? Mae'n syml iawn, daeth rhai unigolion adref a gwneud cais o'u gliniadur cartref yn yr arddull “gwnewch bopeth yn brydferth i mi yma.” Yn ogystal â darllen HWID y system, tynnodd y cyfleustodau yr ID Teamviewer cyfredol o'r gofrestrfa a'i drosglwyddo i ni hefyd. Mae gan Teamviewer API ar gyfer integreiddio. A gwnaethom yr integreiddio hwn. Ond roedd un dal. Trwy'r APIs hyn, mae'n amhosibl cysylltu â chyfrifiadur y defnyddiwr pan nad yw'n cychwyn y sesiwn hon yn benodol ac ar ôl ceisio cysylltu ag ef, rhaid iddo hefyd glicio “cadarnhau”. Ar y pryd, roedd yn ymddangos yn rhesymegol i ni na ddylai unrhyw un gysylltu heb gais y defnyddiwr, a chan fod y person wrth y cyfrifiadur, bydd yn cychwyn y sesiwn ac yn ymateb yn gadarnhaol i'r cais am gysylltiad o bell. Trodd popeth allan o'i le. Anghofiodd ymgeiswyr bwyso i gychwyn y sesiwn, a bu'n rhaid iddynt ddweud hyn wrthynt mewn sgwrs ffôn. Roedd hyn yn gwastraffu amser ac yn rhwystredig ar ddwy ochr y broses. Ar ben hynny, nid yw'n anghyffredin o gwbl ar gyfer eiliadau o'r fath pan fydd person yn gadael cais, ond dim ond pan fydd yn gadael am ginio y caniateir iddo gysylltu. Oherwydd nad yw'r broblem yn hollbwysig ac nid yw am i'w broses waith gael ei thorri. Yn unol â hynny, ni fydd yn pwyso unrhyw fotymau i ganiatáu cysylltiad. Dyma sut yr ymddangosodd swyddogaethau ychwanegol wrth fewngofnodi i'r Ddesg Gymorth - darllen ID Teamviwer. Roeddem yn gwybod y cyfrinair parhaol a ddefnyddiwyd wrth osod Teamviwer. Yn fwy manwl gywir, dim ond y system oedd yn ei adnabod, gan ei fod wedi'i gynnwys yn y gosodwr ac yn ein system. Yn unol â hynny, roedd botwm cysylltiad o'r cais trwy glicio arno nad oedd angen aros am unrhyw beth, ond agorodd Teamviewer ar unwaith a digwyddodd cysylltiad. O ganlyniad, roedd dau fath o gysylltiadau posibl. Trwy'r API Teamviewer swyddogol a'n un hunan-wneud. Er mawr syndod i mi, fe wnaethon nhw roi'r gorau i ddefnyddio'r un cyntaf bron ar unwaith, er bod yna gyfarwyddyd i'w ddefnyddio mewn achosion arbennig yn unig a phan fydd y defnyddiwr ei hun yn rhoi sêl bendith. Eto i gyd, rhowch sicrwydd i mi nawr. Ond daeth i'r amlwg nad oedd angen hyn ar yr ymgeiswyr. Maen nhw i gyd yn hollol iawn gyda chael eu cysylltu â nhw heb fotwm cadarnhau.

Newid i multithreading yn Linux

Mae'r cwestiwn o gyflymu taith sganiwr rhwydwaith ar gyfer pa mor agored yw rhestr o borthladdoedd a bennwyd ymlaen llaw a phing syml o wrthrychau rhwydwaith wedi dechrau codi ers tro. Yma, wrth gwrs, yr ateb cyntaf sy'n dod i'r meddwl yw multithreading. Gan mai'r prif amser a dreulir ar ping yw aros i'r pecyn gael ei ddychwelyd, ac ni all y ping nesaf ddechrau nes bod y pecyn blaenorol yn cael ei ddychwelyd, mewn cwmnïau a oedd â hyd yn oed 20+ o weinyddion ynghyd ag offer rhwydwaith, mae hyn eisoes yn gweithio'n eithaf araf. Y pwynt yw y gall un pecyn ddiflannu, ond peidiwch â hysbysu gweinyddwr y system amdano ar unwaith. Bydd yn rhoi'r gorau i dderbyn sbam o'r fath yn gyflym iawn. Mae hyn yn golygu bod angen i chi pingio pob gwrthrych fwy nag unwaith cyn dod i gasgliad am anhygyrchedd. Heb fynd i ormod o fanylion, mae angen ei gyfochri oherwydd os na wneir hyn, yna mae'n fwyaf tebygol y bydd gweinyddwr y system yn dysgu am y broblem gan y cleient, ac nid o'r system fonitro.

Nid yw PHP ei hun yn cefnogi multithreading allan o'r blwch. Yn gallu amlbrosesu, gallwch fforc. Ond, mewn gwirionedd, roedd gen i fecanwaith pleidleisio eisoes wedi'i ysgrifennu ac roeddwn i eisiau ei wneud fel y byddwn i unwaith yn cyfrif yr holl nodau roeddwn i eu hangen o'r gronfa ddata, yn ping popeth ar unwaith, yn aros am ymateb gan bob un a dim ond ar ôl hynny ysgrifennu ar unwaith y data. Mae hyn yn arbed ar nifer y ceisiadau darllen. Mae multithreading yn ffitio'n berffaith i'r syniad hwn. Ar gyfer PHP mae modiwl PThreads sy'n eich galluogi i wneud multithreading go iawn, er ei fod wedi cymryd cryn dipyn o dinceri i sefydlu hyn ar PHP 7.2, ond fe'i gwnaed. Mae sganio porthladdoedd a ping bellach yn gyflym. Ac yn lle, er enghraifft, 15 eiliad y lap yn gynharach, dechreuodd y broses hon gymryd 2 eiliad. Roedd yn ganlyniad da.

Archwiliad cyflym o gwmnïau newydd

Sut daeth y swyddogaeth ar gyfer casglu amrywiol nodweddion metrigau a chaledwedd i fodolaeth? Mae'n syml. Weithiau cawn ein gorchymyn i archwilio’r seilwaith TG presennol. Wel, mae'r un peth yn angenrheidiol i gyflymu'r archwiliad o gleient newydd. Roedd angen rhywbeth arnom a fyddai'n caniatáu inni ddod at gwmni canolig neu fawr a darganfod yn gyflym beth sydd ganddynt. Yn fy marn i, dim ond y rhai sydd am gymhlethu eu bywydau eu hunain sy'n rhwystro ping ar y rhwydwaith mewnol, ac yn ein profiad ni nid oes llawer ohonynt. Ond mae yna bobl o'r fath hefyd. Yn unol â hynny, gallwch sganio rhwydweithiau yn gyflym am bresenoldeb dyfeisiau gyda ping syml. Yna gallwn eu hychwanegu a sganio am borthladdoedd agored sydd o ddiddordeb i ni. Mewn gwirionedd, roedd y swyddogaeth hon eisoes yn bodoli; dim ond gorchymyn o'r gweinydd canolog i'r caethwas oedd angen ei ychwanegu fel y byddai'n sganio'r rhwydweithiau penodedig ac yn ychwanegu popeth y daeth o hyd iddo at y rhestr. Anghofiais sôn, tybiwyd bod gennym ni ddelwedd barod eisoes gyda system wedi'i ffurfweddu (gweinydd monitro caethweision) y gallem ei chyflwyno'n syml gan y cleient yn ystod archwiliad a'i gysylltu â'n cwmwl.

Ond mae canlyniad archwiliad fel arfer yn cynnwys criw o wahanol wybodaeth, ac un ohonynt yw pa fath o ddyfeisiadau sydd ar y rhwydwaith. Yn gyntaf oll, roedd gennym ddiddordeb mewn gweinyddwyr Windows a gweithfannau Windows fel rhan o barth. Oherwydd mewn cwmnïau canolig a mawr mae'n debyg bod diffyg parth yn eithriad i'r rheol. I siarad un iaith, y cyfartaledd, yn fy marn i, yw 100+ o bobl. Roedd angen meddwl am ffordd o gasglu data o holl beiriannau a gweinyddwyr Windows, gan wybod eu cyfrif gweinyddwr IP a pharth, ond heb osod unrhyw feddalwedd ar bob un ohonynt. Daw rhyngwyneb WMI i'r adwy. Mae Offeryniaeth Rheoli Windows (WMI) yn llythrennol yn golygu offer rheoli Windows. WMI yw un o'r technolegau sylfaenol ar gyfer rheolaeth ganolog a monitro gweithrediad gwahanol rannau o'r seilwaith cyfrifiadurol sy'n rhedeg platfform Windows. Wedi'i gymryd o wiki. Nesaf, bu'n rhaid i mi tincian eto er mwyn llunio wmic (mae hwn yn gleient WMI) ar gyfer Debian. Ar ôl i bopeth fod yn barod, y cyfan oedd ar ôl oedd dim ond pleidleisio'r nodau angenrheidiol trwy wmic am y wybodaeth angenrheidiol. Trwy WMI gallwch gael bron unrhyw wybodaeth o gyfrifiadur Windows, ac ar ben hynny, gallwch hefyd reoli'r cyfrifiadur drwyddo, er enghraifft, ei anfon i ailgychwyn. Dyma sut yr ymddangosodd y casgliad o wybodaeth am orsafoedd a gweinyddwyr Windows yn ein system. Yn ogystal â hyn, roedd gwybodaeth gyfredol am ddangosyddion llwyth system gyfredol. Rydym yn gofyn amdanynt yn amlach, a gwybodaeth am galedwedd yn llai aml. Ar ôl hyn, daeth archwilio ychydig yn fwy pleserus.

Penderfyniad dosbarthu meddalwedd

Rydym ni ein hunain yn defnyddio'r system bob dydd, ac mae bob amser ar agor i bob gweithiwr technegol. Ac roeddem yn meddwl y gallem rannu ag eraill yr hyn sydd gennym eisoes. Nid oedd y system yn barod i'w dosbarthu eto. Roedd yn rhaid ail-weithio llawer er mwyn i'r fersiwn leol droi'n SaaS. Mae'r rhain yn cynnwys newidiadau mewn amrywiol agweddau technegol ar y system (cysylltiadau anghysbell, gwasanaeth cefnogi), dadansoddi modiwlau ar gyfer trwyddedu, rhannu cronfeydd data cwsmeriaid, graddio pob gwasanaeth, a datblygu systemau diweddaru awtomatig ar gyfer pob rhan. Ond dyma fydd ail ran yr erthygl.

Diweddariad

Ail ran

Ffynhonnell: hab.com