આઉટસોર્સિંગથી વિકાસ સુધી (ભાગ 1)

દરેકને નમસ્તે, મારું નામ સેર્ગેઈ એમેલિયાંચિક છે. હું ઓડિટ-ટેલિકોમ કંપનીનો વડા છું, વેલિઅમ સિસ્ટમનો મુખ્ય વિકાસકર્તા અને લેખક છું. મેં અને મારા મિત્રએ એક આઉટસોર્સિંગ કંપની કેવી રીતે બનાવી તેના વિશે એક લેખ લખવાનું નક્કી કર્યું, આપણા માટે સોફ્ટવેર લખ્યા અને ત્યારબાદ SaaS સિસ્ટમ દ્વારા દરેકને તેનું વિતરણ કરવાનું શરૂ કર્યું. કેવી રીતે હું સ્પષ્ટપણે માનતો ન હતો કે આ શક્ય છે તે વિશે. લેખમાં માત્ર એક વાર્તા જ નહીં, પણ વેલિઅમ પ્રોડક્ટ કેવી રીતે બનાવવામાં આવી તેની તકનીકી વિગતો પણ હશે. સ્રોત કોડના કેટલાક ટુકડાઓ સહિત. અમે તમને કઈ ભૂલો કરી અને અમે તેને પછીથી કેવી રીતે સુધારી તે હું તમને જણાવીશ. આવો લેખ પ્રકાશિત કરવો કે કેમ તેની શંકા હતી. પરંતુ મેં વિચાર્યું કે લેખ પ્રકાશિત કરવા અને શું થયું હોત તે વિશે વિચારવા કરતાં, પ્રતિસાદ મેળવો અને સુધારો કરવો વધુ સારું છે.

પ્રાગૈતિહાસિક

હું એક કંપનીમાં આઈટી કર્મચારી તરીકે કામ કરતો હતો. વ્યાપક નેટવર્ક માળખા સાથે કંપની ખૂબ મોટી હતી. હું મારી નોકરીની જવાબદારીઓ પર ધ્યાન આપીશ નહીં, હું ફક્ત એટલું જ કહીશ કે તેમાં ચોક્કસપણે કંઈપણનો વિકાસ શામેલ નથી.

અમારી પાસે મોનિટરિંગ હતું, પરંતુ કેવળ શૈક્ષણિક રસને લીધે હું મારું પોતાનું સૌથી સરળ લખવાનો પ્રયાસ કરવા માંગતો હતો. વિચાર આ હતો: હું ઇચ્છતો હતો કે તે વેબ પર હોય, જેથી હું કોઈપણ ક્લાયંટને ઇન્સ્ટોલ કર્યા વિના સરળતાથી અંદર જઈ શકું અને Wi-Fi દ્વારા મોબાઇલ ઉપકરણ સહિત કોઈપણ ઉપકરણમાંથી નેટવર્ક સાથે શું થઈ રહ્યું છે તે જોઈ શકું અને હું ખરેખર ઝડપથી સમજવા માંગતો હતો કે રૂમમાં એવા કયા સાધનો છે જે "મોપી" બની ગયા છે કારણ કે... આવી સમસ્યાઓ માટે પ્રતિભાવ સમય માટે ખૂબ જ કડક જરૂરિયાતો હતી. પરિણામે, મારા મગજમાં એક સરળ વેબ પેજ લખવા માટે એક યોજનાનો જન્મ થયો કે જેના પર નેટવર્ક ડાયાગ્રામ સાથે jpeg પૃષ્ઠભૂમિ હતી, આ ચિત્રમાં તેમના IP સરનામાઓ સાથે ઉપકરણોને જાતે કાપી નાખો અને ટોચ પર ગતિશીલ સામગ્રી દર્શાવો. લીલા અથવા ફ્લેશિંગ લાલ IP સરનામાના રૂપમાં જરૂરી કોઓર્ડિનેટ્સમાં ચિત્ર. કાર્ય સેટ કરવામાં આવ્યું છે, ચાલો પ્રારંભ કરીએ.

અગાઉ, હું ડેલ્ફી, PHP, JS અને ખૂબ જ ઉપરછલ્લી રીતે C++ માં પ્રોગ્રામિંગ કરતો હતો. હું સારી રીતે જાણું છું કે નેટવર્ક કેવી રીતે કામ કરે છે. VLAN, રૂટીંગ (OSPF, EIGRP, BGP), NAT. આ મારા માટે આદિમ મોનિટરિંગ પ્રોટોટાઇપ લખવા માટે પૂરતું હતું.

મેં PHP માં જે આયોજન કર્યું હતું તે મેં લખ્યું. Apache અને PHP સર્વર Windows પર હતું કારણ કે... તે ક્ષણે મારા માટે લિનક્સ કંઈક અગમ્ય અને ખૂબ જ જટિલ હતું, કારણ કે તે પછીથી બહાર આવ્યું, હું ખૂબ જ ભૂલમાં હતો અને ઘણી જગ્યાએ લિનક્સ વિન્ડોઝ કરતાં વધુ સરળ છે, પરંતુ આ એક અલગ વિષય છે અને આપણે બધા જાણીએ છીએ કે ત્યાં કેટલા હોલિવર છે. આ વિષય. વિન્ડોઝ ટાસ્ક શેડ્યૂલર નાના અંતરાલ પર ખેંચાય છે (મને બરાબર યાદ નથી, પરંતુ દર ત્રણ સેકન્ડમાં એક વાર જેવું કંઈક) એક PHP સ્ક્રિપ્ટ કે જેણે મામૂલી પિંગ સાથે તમામ ઑબ્જેક્ટ્સને પોલ કર્યા અને રાજ્યને ફાઇલમાં સાચવી.

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

હા, હા, તે ક્ષણે ડેટાબેઝ સાથે કામ કરવું પણ મારા માટે નિપુણ ન હતું. મને ખબર નહોતી કે પ્રક્રિયાઓને સમાંતર બનાવવી શક્ય છે, અને તમામ નેટવર્ક નોડ્સમાંથી પસાર થવામાં લાંબો સમય લાગ્યો, કારણ કે... આ એક થ્રેડમાં થયું. સમસ્યાઓ ખાસ કરીને ઊભી થાય છે જ્યારે ઘણા ગાંઠો અનુપલબ્ધ હતા, કારણ કે તેમાંના દરેકે 300 ms માટે સ્ક્રિપ્ટમાં વિલંબ કર્યો. ક્લાયન્ટની બાજુએ એક સરળ લૂપિંગ ફંક્શન હતું જે, થોડી સેકંડના અંતરાલમાં, Ajax વિનંતી સાથે સર્વરમાંથી અપડેટ કરેલી માહિતી ડાઉનલોડ કરે છે અને ઇન્ટરફેસને અપડેટ કરે છે. સારું, પછી, સતત 3 અસફળ પિંગ્સ પછી, જો કમ્પ્યુટર પર મોનિટરિંગ સાથેનું વેબ પૃષ્ઠ ખુલ્લું હતું, તો ખુશખુશાલ રચના વગાડવામાં આવી હતી.

જ્યારે બધું કામ થઈ ગયું, ત્યારે હું પરિણામથી ખૂબ જ પ્રેરિત થયો અને વિચાર્યું કે હું તેમાં વધુ ઉમેરી શકું છું (મારા જ્ઞાન અને ક્ષમતાઓને કારણે). પરંતુ મને હંમેશા મિલિયન ચાર્ટવાળી સિસ્ટમ્સ પસંદ નહોતી, જે મેં ત્યારે વિચાર્યું હતું, અને આજે પણ લાગે છે, મોટાભાગના કિસ્સાઓમાં બિનજરૂરી છે. હું ત્યાં ફક્ત તે જ મૂકવા માંગતો હતો જે મને મારા કાર્યમાં ખરેખર મદદ કરશે. આ સિદ્ધાંત આજ સુધી વેલિયમના વિકાસ માટે મૂળભૂત છે. આગળ, મને સમજાયું કે જો મારે મોનિટરિંગ ખુલ્લું રાખવું અને સમસ્યાઓ વિશે જાણવાની જરૂર ન હોય તો તે ખૂબ જ સરસ રહેશે, અને જ્યારે તે થયું, પછી પૃષ્ઠ ખોલો અને જુઓ કે આ સમસ્યારૂપ નેટવર્ક નોડ ક્યાં સ્થિત છે અને તેની સાથે આગળ શું કરવું. . કોઈક રીતે મેં તે સમયે ઇમેઇલ વાંચ્યો ન હતો, મેં ફક્ત તેનો ઉપયોગ કર્યો ન હતો. મેં ઇન્ટરનેટ પર જોયું કે ત્યાં SMS ગેટવે છે જેના પર તમે GET અથવા POST વિનંતી મોકલી શકો છો, અને તેઓ મારા મોબાઇલ ફોન પર મારા લખેલા ટેક્સ્ટ સાથે SMS મોકલશે. મને તરત જ સમજાયું કે હું ખરેખર આ ઇચ્છું છું. અને મેં દસ્તાવેજીકરણનો અભ્યાસ કરવાનું શરૂ કર્યું. થોડા સમય પછી હું સફળ થયો, અને હવે મને મારા મોબાઇલ ફોન પર "પડેલી વસ્તુ" ના નામ સાથે નેટવર્ક પરની સમસ્યાઓ વિશે એક એસએમએસ મળ્યો. સિસ્ટમ આદિમ હોવા છતાં, તે મારા દ્વારા લખવામાં આવી હતી, અને સૌથી મહત્વની વસ્તુ જેણે મને તેને વિકસાવવા માટે પ્રોત્સાહિત કર્યો તે એ છે કે તે એક એપ્લિકેશન પ્રોગ્રામ હતો જેણે મને મારા કાર્યમાં ખરેખર મદદ કરી.

અને પછી તે દિવસ આવ્યો જ્યારે ઈન્ટરનેટ ચેનલોમાંથી એક કામ પર પડી ગઈ, અને મારું મોનિટરિંગ મને તેના વિશે જાણ્યું નહીં. કારણ કે Google DNS હજુ પણ સંપૂર્ણ રીતે પિંગ કરે છે. સંચાર ચેનલ જીવંત છે તે તમે કેવી રીતે મોનિટર કરી શકો તે વિશે વિચારવાનો સમય છે. આ કેવી રીતે કરવું તે અંગે વિવિધ વિચારો હતા. મારી પાસે તમામ સાધનોની ઍક્સેસ ન હતી. કઈ ચેનલો લાઇવ છે તે કેવી રીતે સમજવું તે અમારે શોધવાનું હતું, પરંતુ નેટવર્ક સાધનો પર જ તેને કોઈક રીતે જોવામાં સમર્થ થયા વિના. પછી એક સાથીદારે વિચાર આવ્યો કે સંભવ છે કે સાર્વજનિક સર્વર્સ પરના રૂટ ટ્રેસીંગમાં હાલમાં ઇન્ટરનેટનો ઉપયોગ કરવા માટે કઈ કોમ્યુનિકેશન ચેનલનો ઉપયોગ કરવામાં આવે છે તેના આધારે અલગ હોઈ શકે છે. મેં તપાસ કરી અને તે તે રીતે બહાર આવ્યું. ટ્રેસ કરતી વખતે અલગ-અલગ માર્ગો હતા.

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

તેથી બીજી સ્ક્રિપ્ટ દેખાઈ, અથવા તેના બદલે, કોઈ કારણસર એ જ સ્ક્રિપ્ટના અંતમાં ટ્રેસ ઉમેરવામાં આવ્યું, જેણે નેટવર્ક પરના તમામ ઉપકરણોને પિંગ કર્યા. છેવટે, આ બીજી લાંબી પ્રક્રિયા છે જે સમાન થ્રેડમાં ચલાવવામાં આવી હતી અને સમગ્ર સ્ક્રિપ્ટનું કામ ધીમું કર્યું હતું. પરંતુ તે પછી તે એટલું સ્પષ્ટ ન હતું. પરંતુ એક યા બીજી રીતે, તેણે તેનું કામ કર્યું, કોડે દરેક ચેનલો માટે કયા પ્રકારનું ટ્રેસિંગ હોવું જોઈએ તે સખત રીતે વ્યાખ્યાયિત કર્યું. આ રીતે સિસ્ટમ કામ કરવાનું શરૂ કર્યું, જેણે પહેલેથી જ મોનિટર કર્યું (મોટેથી કહ્યું, કારણ કે ત્યાં કોઈ મેટ્રિક્સનો કોઈ સંગ્રહ નથી, પરંતુ ફક્ત પિંગ) નેટવર્ક ઉપકરણો (રાઉટર્સ, સ્વીચો, વાઇ-ફાઇ, વગેરે) અને બાહ્ય વિશ્વ સાથે સંચાર ચેનલો. . એસએમએસ સંદેશા નિયમિતપણે આવતા હતા અને ડાયાગ્રામ હંમેશા સ્પષ્ટ રીતે દર્શાવે છે કે સમસ્યા ક્યાં છે.

આગળ, રોજિંદા કામમાં મારે ક્રોસ ક્રોસિંગ કરવાનું હતું. અને કયા ઇન્ટરફેસનો ઉપયોગ કરવો તે જોવા માટે હું દર વખતે સિસ્કો સ્વીચો પર જઈને થાકી ગયો. મોનિટરિંગમાં ઑબ્જેક્ટ પર ક્લિક કરવું અને વર્ણનો સાથે તેના ઇન્ટરફેસની સૂચિ જોવાનું કેટલું સરસ રહેશે. તે મારો સમય બચાવશે. વધુમાં, આ સ્કીમમાં એકાઉન્ટ્સ અને આદેશો દાખલ કરવા માટે પુટ્ટી અથવા સિક્યોરસીઆરટી ચલાવવાની જરૂર રહેશે નહીં. મેં ફક્ત મોનિટરિંગ પર ક્લિક કર્યું, શું જોઈતું હતું તે જોયું અને મારું કામ કરવા ગયો. મેં સ્વીચો સાથે ક્રિયાપ્રતિક્રિયા કરવાની રીતો શોધવાનું શરૂ કર્યું. મને તરત જ 2 વિકલ્પો મળ્યા: SNMP અથવા SSH દ્વારા સ્વિચમાં લોગ ઇન કરવું, મને જરૂરી આદેશો દાખલ કરવો અને પરિણામનું વિશ્લેષણ કરવું. તેના અમલીકરણની જટિલતાને કારણે મેં SNMP ને કાઢી નાખ્યું; હું પરિણામ મેળવવા માટે અધીર હતો. SNMP સાથે, તમારે લાંબા સમય સુધી MIB માં ખોદવું પડશે અને, આ ડેટાના આધારે, ઇન્ટરફેસ વિશે ડેટા જનરેટ કરવો પડશે. CISCOમાં એક અદ્ભુત ટીમ છે

show interface status

તે બરાબર બતાવે છે કે મને ક્રોસ-ક્રોસિંગ્સ માટે શું જોઈએ છે. જ્યારે હું ફક્ત આ આદેશનું આઉટપુટ જોવા માંગુ છું ત્યારે SNMP સાથે શા માટે ચિંતા કરવી, મેં વિચાર્યું. થોડા સમય પછી, મને આ તકનો અહેસાસ થયો. વેબ પેજ પર ઑબ્જેક્ટ પર ક્લિક કર્યું. એક ઇવેન્ટ ટ્રિગર કરવામાં આવી હતી જેના દ્વારા AJAX ક્લાયન્ટે સર્વરનો સંપર્ક કર્યો હતો, અને તે બદલામાં, SSH દ્વારા મને જરૂરી સ્વિચ સાથે જોડવામાં આવ્યો હતો (લેખપત્ર કોડમાં હાર્ડકોડ કરવામાં આવ્યા હતા, તેને રિફાઇન કરવાની કોઈ ઈચ્છા નહોતી, કેટલાક અલગ મેનુ બનાવવા માટે જ્યાં ઇન્ટરફેસમાંથી એકાઉન્ટ્સ બદલવાનું શક્ય બનશે , મને પરિણામની જરૂર હતી અને ઝડપથી) મેં ત્યાં ઉપરોક્ત આદેશ દાખલ કર્યો અને તેને બ્રાઉઝર પર પાછો મોકલ્યો. તેથી મેં માઉસની એક ક્લિકથી ઇન્ટરફેસ પરની માહિતી જોવાનું શરૂ કર્યું. આ અત્યંત અનુકૂળ હતું, ખાસ કરીને જ્યારે તમારે આ માહિતી એકસાથે વિવિધ સ્વીચો પર જોવાની હોય.

ટ્રેસ-આધારિત ચેનલ મોનિટરિંગ એ શ્રેષ્ઠ વિચાર નથી, કારણ કે... કેટલીકવાર નેટવર્ક પર કામ કરવામાં આવતું હતું, અને ટ્રેસિંગ બદલાઈ શકે છે અને મોનિટરિંગ મારા પર ચીસો પાડવાનું શરૂ કરે છે કે ચેનલમાં સમસ્યાઓ છે. પરંતુ વિશ્લેષણ પર ઘણો સમય વિતાવ્યા પછી, મને સમજાયું કે બધી ચેનલો કામ કરી રહી છે, અને મારું મોનિટરિંગ મને છેતરતી હતી. પરિણામે, મેં મારા સહકર્મીઓને કહ્યું કે જેઓ ચેનલ-ફોર્મિંગ સ્વિચનું સંચાલન કરે છે, જ્યારે પડોશીઓની દૃશ્યતાની સ્થિતિ બદલાઈ જાય ત્યારે મને સિસ્લોગ મોકલો. તદનુસાર, તે ટ્રેસિંગ કરતાં વધુ સરળ, ઝડપી અને વધુ સચોટ હતું. પાડોશી ગુમાવ્યા જેવી ઘટના આવી છે, અને હું તરત જ ચેનલ ડાઉન વિશે સૂચના જારી કરું છું.

આગળ, ઑબ્જેક્ટ પર ક્લિક કરતી વખતે ઘણા વધુ આદેશો દેખાયા, અને કેટલાક મેટ્રિક્સ એકત્રિત કરવા માટે SNMP ઉમેરવામાં આવ્યું, અને તે મૂળભૂત રીતે તે છે. સિસ્ટમ ક્યારેય વધુ વિકસિત થઈ નથી. તેણે મને જરૂરી બધું કર્યું, તે એક સારું સાધન હતું. ઘણા વાચકો કદાચ મને કહેશે કે આ સમસ્યાઓ ઉકેલવા માટે ઈન્ટરનેટ પર પહેલાથી જ ઘણાં સોફ્ટવેર છે. પરંતુ વાસ્તવમાં, મેં તે સમયે આવા મફત ઉત્પાદનોને ગૂગલ કર્યું ન હતું અને હું ખરેખર મારી પ્રોગ્રામિંગ કુશળતા વિકસાવવા માંગતો હતો, અને વાસ્તવિક એપ્લિકેશન સમસ્યા કરતાં આ માટે દબાણ કરવાનો વધુ સારો રસ્તો કયો હતો. આ બિંદુએ, મોનિટરિંગનું પ્રથમ સંસ્કરણ પૂર્ણ થયું હતું અને હવે તેમાં ફેરફાર કરવામાં આવ્યો નથી.

ઓડિટ-ટેલિકોમ કંપનીની રચના

જેમ જેમ સમય વીતતો ગયો તેમ તેમ મેં અન્ય કંપનીઓમાં પાર્ટ-ટાઇમ કામ કરવાનું શરૂ કર્યું, સદનસીબે મારા કામના શેડ્યૂલએ મને આ કરવાની મંજૂરી આપી. જ્યારે તમે વિવિધ કંપનીઓમાં કામ કરો છો, ત્યારે વિવિધ ક્ષેત્રોમાં તમારી કુશળતા ખૂબ જ ઝડપથી વધે છે અને તમારી ક્ષિતિજો સારી રીતે વિકસિત થાય છે. એવી કંપનીઓ છે જેમાં તેઓ કહે છે તેમ, તમે સ્વીડન છો, કાપણી કરનાર છો અને ટ્રમ્પેટ પ્લેયર છો. એક તરફ, તે મુશ્કેલ છે, બીજી તરફ, જો તમે આળસુ ન હોવ, તો તમે સામાન્યવાદી બનો છો અને આ તમને સમસ્યાઓને ઝડપથી અને વધુ અસરકારક રીતે હલ કરવાની મંજૂરી આપે છે કારણ કે તમે જાણો છો કે સંબંધિત ક્ષેત્ર કેવી રીતે કાર્ય કરે છે.

મારા મિત્ર પાવેલ (આઇટી નિષ્ણાત પણ) મને પોતાનો વ્યવસાય શરૂ કરવા માટે સતત પ્રોત્સાહિત કરવાનો પ્રયાસ કરતા હતા. તેઓ જે કરી રહ્યા હતા તેની વિવિધ ભિન્નતાઓ સાથે અસંખ્ય વિચારો હતા. વર્ષોથી આની ચર્ચા થઈ રહી છે. અને અંતે, તે કંઈપણ પર આવવું ન જોઈએ કારણ કે હું એક સંશયવાદી છું, અને પાવેલ એક સ્વપ્નદ્રષ્ટા છે. જ્યારે પણ તેણે કોઈ વિચાર પ્રસ્તાવિત કર્યો, ત્યારે હું હંમેશા તેના પર વિશ્વાસ કરતો ન હતો અને ભાગ લેવાનો ઇનકાર કરતો હતો. પરંતુ અમે ખરેખર અમારો પોતાનો વ્યવસાય ખોલવા માંગતા હતા.

અંતે, અમે એક વિકલ્પ શોધી શક્યા જે અમારા બંનેને અનુકૂળ હોય અને અમે જે કરવું તે જાણીએ છીએ. 2016 માં, અમે એક IT કંપની બનાવવાનું નક્કી કર્યું જે વ્યવસાયોને IT સમસ્યાઓ ઉકેલવામાં મદદ કરશે. આ IT સિસ્ટમ્સ (1C, ટર્મિનલ સર્વર, મેલ સર્વર, વગેરે), તેમની જાળવણી, વપરાશકર્તાઓ માટે ક્લાસિક હેલ્પડેસ્ક અને નેટવર્ક એડમિનિસ્ટ્રેશનની જમાવટ છે.

સાચું કહું તો, કંપની બનાવતી વખતે, હું તેના પર લગભગ 99,9% માનતો ન હતો. પરંતુ કોઈક રીતે પાવેલ મને અજમાવવામાં સક્ષમ હતો, અને આગળ જોતા, તે સાચો નીકળ્યો. પાવેલ અને મેં દરેકે 300 રુબેલ્સમાં ચિપિંગ કર્યું, એક નવું LLC “ઓડિટ-ટેલિકોમ” રજીસ્ટર કર્યું, એક નાનકડી ઓફિસ ભાડે લીધી, સરસ બિઝનેસ કાર્ડ્સ બનાવ્યા, સામાન્ય રીતે, કદાચ સૌથી બિનઅનુભવી, શિખાઉ ઉદ્યોગપતિઓની જેમ, અને ગ્રાહકોને શોધવાનું શરૂ કર્યું. ગ્રાહકો શોધવી એ એક સંપૂર્ણપણે અલગ વાર્તા છે. જો કોઈને રસ હોય તો કદાચ અમે કોર્પોરેટ બ્લોગના ભાગ રૂપે એક અલગ લેખ લખીશું. કોલ્ડ કૉલ્સ, ફ્લાયર્સ, વગેરે. આનાથી કોઈ પરિણામ આવ્યું નથી. જેમ કે હવે હું વ્યવસાય વિશેની ઘણી વાર્તાઓમાંથી વાંચું છું, એક અથવા બીજી રીતે, ઘણું નસીબ પર નિર્ભર છે. અમે નસીબદાર હતા. અને શાબ્દિક રીતે કંપનીની રચનાના થોડા અઠવાડિયા પછી, મારા ભાઈ વ્લાદિમીર અમારો સંપર્ક કર્યો, જે અમને અમારો પ્રથમ ક્લાયંટ લાવ્યો. હું તમને ક્લાયન્ટ્સ સાથે કામ કરવાની વિગતોથી કંટાળીશ નહીં, આ લેખ તેના વિશે નથી, હું ફક્ત એટલું જ કહીશ કે અમે ઓડિટ માટે ગયા હતા, નિર્ણાયક વિસ્તારો ઓળખી કાઢ્યા હતા અને આ વિસ્તારો તૂટી ગયા હતા જ્યારે નિર્ણય લેવામાં આવ્યો હતો કે શું કરવું આઉટસોર્સર તરીકે ચાલુ ધોરણે અમારી સાથે સહકાર આપો. આ પછી તરત જ સકારાત્મક નિર્ણય લેવામાં આવ્યો હતો.

પછી, મુખ્યત્વે મિત્રો દ્વારા મોં દ્વારા, અન્ય સેવા કંપનીઓ દેખાવા લાગી. હેલ્પડેસ્ક એક સિસ્ટમમાં હતું. નેટવર્ક સાધનો અને સર્વર્સ સાથેના જોડાણો અલગ છે, અથવા તેના બદલે અલગ છે. કેટલાક લોકોએ શોર્ટકટ સાચવ્યા, અન્ય લોકોએ RDP એડ્રેસ બુકનો ઉપયોગ કર્યો. મોનીટરીંગ એ બીજી અલગ સિસ્ટમ છે. ટીમ માટે અલગ-અલગ સિસ્ટમમાં કામ કરવું ખૂબ જ અસુવિધાજનક છે. મહત્વપૂર્ણ માહિતીની દૃષ્ટિ ગુમાવી છે. સારું, ઉદાહરણ તરીકે, ક્લાયંટનું ટર્મિનલ સર્વર અનુપલબ્ધ બન્યું. આ ક્લાયંટના વપરાશકર્તાઓની અરજીઓ તરત જ પ્રાપ્ત થાય છે. સપોર્ટ નિષ્ણાત વિનંતી ખોલે છે (તે ફોન દ્વારા પ્રાપ્ત થઈ હતી). જો ઘટનાઓ અને વિનંતીઓ એક સિસ્ટમમાં નોંધવામાં આવી હોય, તો પછી સપોર્ટ નિષ્ણાત તરત જ જોશે કે વપરાશકર્તાની સમસ્યા શું છે અને તેને તેના વિશે જણાવશે, જ્યારે તે જ સમયે પરિસ્થિતિને ઉકેલવા માટે જરૂરી ઑબ્જેક્ટ સાથે કનેક્ટ થશે. દરેક વ્યક્તિ વ્યૂહાત્મક પરિસ્થિતિથી વાકેફ છે અને સુમેળથી કામ કરે છે. અમને એવી સિસ્ટમ મળી નથી કે જ્યાં આ બધું જોડવામાં આવે. તે સ્પષ્ટ થઈ ગયું કે તે આપણું પોતાનું ઉત્પાદન બનાવવાનો સમય છે.

તમારી મોનિટરિંગ સિસ્ટમ પર કામ ચાલુ રાખો

તે સ્પષ્ટ હતું કે અગાઉ લખાયેલ સિસ્ટમ વર્તમાન કાર્યો માટે સંપૂર્ણપણે અયોગ્ય હતી. ન તો કાર્યક્ષમતાના સંદર્ભમાં કે ન ગુણવત્તાની દ્રષ્ટિએ. અને સિસ્ટમને શરૂઆતથી લખવાનું નક્કી કરવામાં આવ્યું હતું. ગ્રાફિકલી તે સંપૂર્ણપણે અલગ દેખાવું જોઈએ. તે એક અધિક્રમિક સિસ્ટમ હોવી જોઈએ જેથી કરીને યોગ્ય ક્લાયંટ માટે યોગ્ય ઑબ્જેક્ટ ઝડપથી અને સગવડતાપૂર્વક ખોલવાનું શક્ય બને. પ્રથમ સંસ્કરણની જેમ યોજના વર્તમાન કિસ્સામાં સંપૂર્ણપણે ન્યાયી ન હતી, કારણ કે ગ્રાહકો અલગ છે અને સાધનો કયા પરિસરમાં સ્થિત હતા તેનાથી કોઈ ફરક પડતો નથી. આ પહેલાથી જ દસ્તાવેજીકરણમાં સ્થાનાંતરિત કરવામાં આવ્યું છે.

તેથી, કાર્યો:

1. વંશવેલો માળખું;
2. અમુક પ્રકારનો સર્વર ભાગ જે ક્લાયંટના પરિસરમાં અમને જોઈતા મેટ્રિક્સને એકત્રિત કરવા માટે વર્ચ્યુઅલ મશીનના રૂપમાં મૂકી શકાય છે અને તેને સેન્ટ્રલ સર્વર પર મોકલી શકે છે, જે આ બધાનો સારાંશ આપશે અને અમને બતાવશે;
3. ચેતવણીઓ. જે ચૂકી ન શકાય, કારણ કે... તે સમયે કોઈ વ્યક્તિ માટે બેસીને મોનિટરને જોવું શક્ય ન હતું;
4. એપ્લિકેશન સિસ્ટમ. ક્લાયન્ટ્સ દેખાવા લાગ્યા કે જેમના માટે અમે ફક્ત સર્વર અને નેટવર્ક સાધનો જ નહીં, પણ વર્કસ્ટેશન પણ સેવા આપી હતી;
5. સિસ્ટમમાંથી સર્વર અને સાધનો સાથે ઝડપથી કનેક્ટ થવાની ક્ષમતા;

કાર્યો સેટ કરવામાં આવ્યા છે, અમે લખવાનું શરૂ કરીએ છીએ. રસ્તામાં, ગ્રાહકોની વિનંતીઓ પર પ્રક્રિયા કરી રહી છે. તે સમયે અમે પહેલાથી જ 4 હતા. અમે બંને ભાગો એકસાથે લખવાનું શરૂ કર્યું: કેન્દ્રીય સર્વર અને સર્વર ક્લાયંટને ઇન્સ્ટોલ કરવા માટે. આ બિંદુએ, લિનક્સ હવે અમારા માટે અજાણ્યું ન હતું અને તે નક્કી કરવામાં આવ્યું હતું કે ક્લાયંટ પાસે જે વર્ચ્યુઅલ મશીનો હશે તે ડેબિયન પર હશે. ત્યાં કોઈ ઇન્સ્ટોલર્સ હશે નહીં, અમે ફક્ત એક ચોક્કસ વર્ચ્યુઅલ મશીન પર સર્વર પાર્ટ પ્રોજેક્ટ બનાવીશું, અને પછી અમે તેને ઇચ્છિત ક્લાયંટ પર ક્લોન કરીશું. આ બીજી ભૂલ હતી. પાછળથી તે સ્પષ્ટ થયું કે આવી યોજનામાં અપડેટ મિકેનિઝમ સંપૂર્ણપણે અવિકસિત હતું. તે. અમે કેટલીક નવી સુવિધા ઉમેરી રહ્યા હતા, અને પછી તેને બધા ક્લાયંટ સર્વર્સ પર વિતરિત કરવાની સંપૂર્ણ સમસ્યા હતી, પરંતુ અમે પછીથી આ પર પાછા આવીશું, બધું ક્રમમાં.

અમે પ્રથમ પ્રોટોટાઇપ બનાવ્યો. તે અમને જોઈતા ક્લાયંટ નેટવર્ક ઉપકરણો અને સર્વર્સને પિંગ કરવામાં સક્ષમ હતા અને આ ડેટા અમારા કેન્દ્રીય સર્વરને મોકલતા હતા. અને તેણે, બદલામાં, સેન્ટ્રલ સર્વર પર બલ્કમાં આ ડેટા અપડેટ કર્યો. અહીં હું માત્ર કેવી રીતે અને શું સફળ થયું તે વિશે એક વાર્તા લખીશ નહીં, પણ કઈ કલાપ્રેમી ભૂલો કરવામાં આવી હતી અને પછીથી મને સમય સાથે તેની કિંમત કેવી રીતે ચૂકવવી પડી હતી. તેથી, ઑબ્જેક્ટનું આખું વૃક્ષ શ્રેણીબદ્ધ ઑબ્જેક્ટના સ્વરૂપમાં એક જ ફાઇલમાં સંગ્રહિત કરવામાં આવ્યું હતું. જ્યારે અમે ઘણા ક્લાયન્ટ્સને સિસ્ટમ સાથે કનેક્ટ કર્યા હતા, ત્યારે બધું વધુ કે ઓછું સામાન્ય હતું, જો કે કેટલીકવાર કેટલીક કલાકૃતિઓ હતી જે સંપૂર્ણપણે અગમ્ય હતી. પરંતુ જ્યારે અમે એક ડઝન સર્વરને સિસ્ટમ સાથે કનેક્ટ કર્યું, ત્યારે ચમત્કારો થવા લાગ્યા. કેટલીકવાર, કોઈ અજાણ્યા કારણોસર, સિસ્ટમમાંની બધી વસ્તુઓ ખાલી અદૃશ્ય થઈ જાય છે. અત્રે એ નોંધવું અગત્યનું છે કે જે સર્વર ક્લાયન્ટ્સે સેન્ટ્રલ સર્વરને દર થોડીક સેકન્ડમાં POST વિનંતી દ્વારા ડેટા મોકલ્યો હતો. એક સચેત રીડર અને અનુભવી પ્રોગ્રામરે પહેલેથી જ અનુમાન લગાવ્યું હતું કે તે જ ફાઇલની બહુવિધ ઍક્સેસમાં સમસ્યા છે જેમાં એક જ સમયે વિવિધ થ્રેડોમાંથી શ્રેણીબદ્ધ ઑબ્જેક્ટ સંગ્રહિત કરવામાં આવ્યો હતો. અને જ્યારે આ થઈ રહ્યું હતું, ત્યારે વસ્તુઓના અદ્રશ્ય થવા સાથે ચમત્કારો થયા. ફાઈલ ખાલી ખાલી થઈ ગઈ. પરંતુ આ બધું તરત જ મળી આવ્યું ન હતું, પરંતુ ફક્ત કેટલાક સર્વર્સ સાથે ઓપરેશન દરમિયાન. આ સમય દરમિયાન, પોર્ટ સ્કેનિંગ કાર્યક્ષમતા ઉમેરવામાં આવી હતી (સર્વર્સ કેન્દ્રને ફક્ત ઉપકરણોની ઉપલબ્ધતા વિશે જ નહીં, પણ તેમના પર ખુલ્લા પોર્ટ વિશે પણ માહિતી મોકલવામાં આવે છે). આ આદેશને કૉલ કરીને કરવામાં આવ્યું હતું:

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

પરિણામો ઘણીવાર ખોટા હતા અને સ્કેન પૂર્ણ થવામાં ઘણો સમય લાગ્યો હતો. હું પિંગ વિશે સંપૂર્ણપણે ભૂલી ગયો, તે fping દ્વારા કરવામાં આવ્યું હતું:

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

આ પણ સમાંતર નહોતું અને તેથી પ્રક્રિયા ઘણી લાંબી હતી. બાદમાં, ચકાસણી માટે જરૂરી IP સરનામાઓની સંપૂર્ણ સૂચિ એક જ સમયે fping પર મોકલવામાં આવી હતી, અને પાછા અમને પ્રતિસાદ આપનારાઓની તૈયાર સૂચિ પ્રાપ્ત થઈ હતી. અમારાથી વિપરીત, fping પ્રક્રિયાઓને સમાંતર બનાવવામાં સક્ષમ હતું.

અન્ય સામાન્ય નિયમિત કામ WEB દ્વારા કેટલીક સેવાઓ સેટ કરવાનું હતું. સારું, ઉદાહરણ તરીકે, એમએસ એક્સચેન્જમાંથી ઇ.સી.પી. મૂળભૂત રીતે તે માત્ર એક લિંક છે. અને અમે નક્કી કર્યું છે કે અમારે આવી લિંક્સને સિસ્ટમમાં સીધી ઉમેરવા માટે સક્ષમ બનવાની જરૂર છે, જેથી કોઈ ચોક્કસ ક્લાયન્ટના ECPને કેવી રીતે ઍક્સેસ કરવું તે માટે દસ્તાવેજીકરણમાં અથવા ક્યાંય બુકમાર્ક્સમાં જોવાની જરૂર ન પડે. આ રીતે સિસ્ટમ માટે સંસાધન લિંક્સનો ખ્યાલ દેખાયો, તેમની કાર્યક્ષમતા આજની તારીખે ઉપલબ્ધ છે અને લગભગ બદલાઈ નથી.

વેલિઅમમાં સંસાધન લિંક્સ કેવી રીતે કાર્ય કરે છે

દૂરસ્થ જોડાણો

વેલિઅમના વર્તમાન સંસ્કરણમાં તે આના જેવું લાગે છે

એક કાર્ય ઝડપથી અને સગવડતાપૂર્વક સર્વર્સ સાથે કનેક્ટ થવાનું હતું, જેમાંથી પહેલાથી જ ઘણા બધા (સો કરતાં વધુ) હતા અને લાખો પહેલાથી સાચવેલા RDP શૉર્ટકટ્સ દ્વારા વર્ગીકરણ અત્યંત અસુવિધાજનક હતું. એક સાધનની જરૂર હતી. ઇન્ટરનેટ પર એવા સૉફ્ટવેર છે જે આવા RDP કનેક્શન માટે એડ્રેસ બુક જેવું છે, પરંતુ તે મોનિટરિંગ સિસ્ટમ સાથે સંકલિત નથી, અને એકાઉન્ટ્સ સાચવી શકાતા નથી. જ્યારે તમે દિવસમાં ડઝનેક વખત જુદા જુદા સર્વર્સ સાથે કનેક્ટ કરો છો ત્યારે દર વખતે જુદા જુદા ક્લાયન્ટ્સ માટે એકાઉન્ટ્સ દાખલ કરવું એ શુદ્ધ નરક છે. SSH સાથે, વસ્તુઓ થોડી સારી છે; ત્યાં ઘણા સારા સૉફ્ટવેર છે જે તમને ફોલ્ડર્સમાં આવા જોડાણોને ગોઠવવા અને તેમાંથી એકાઉન્ટ્સ યાદ રાખવાની મંજૂરી આપે છે. પરંતુ ત્યાં 2 સમસ્યાઓ છે. પ્રથમ એ છે કે અમને RDP અને SSH જોડાણો માટે એક પણ પ્રોગ્રામ મળ્યો નથી. બીજું એ છે કે જો કોઈ સમયે હું મારા કમ્પ્યુટર પર ન હોઉં અને મારે ઝડપથી કનેક્ટ કરવાની જરૂર હોય, અથવા મેં હમણાં જ સિસ્ટમ ફરીથી ઇન્સ્ટોલ કરી હોય, તો મારે આ ક્લાયન્ટના એકાઉન્ટને જોવા માટે દસ્તાવેજીકરણમાં જવું પડશે. તે અસુવિધાજનક અને સમયનો વ્યય છે.

ક્લાયંટ સર્વર્સ માટે અમારે જરૂરી અધિક્રમિક માળખું અમારા આંતરિક ઉત્પાદનમાં પહેલેથી જ ઉપલબ્ધ હતું. મારે ત્યાં જરૂરી સાધનો સાથે ઝડપી કનેક્શન કેવી રીતે જોડવું તે શોધવાનું હતું. શરૂઆત માટે, ઓછામાં ઓછું તમારા નેટવર્કમાં.

અમારી સિસ્ટમમાં ક્લાયંટ એ એક બ્રાઉઝર હતું જે કમ્પ્યુટરના સ્થાનિક સંસાધનોની ઍક્સેસ ધરાવતું નથી તે હકીકતને ધ્યાનમાં લેતા, અમુક આદેશ સાથે અમને જોઈતી એપ્લિકેશનને ફક્ત લૉન્ચ કરવા માટે, "વિન્ડોઝ" દ્વારા બધું કરવાની શોધ કરવામાં આવી હતી. કસ્ટમ url સ્કીમ”. આ રીતે અમારી સિસ્ટમ માટે ચોક્કસ "પ્લગઇન" દેખાયું, જેમાં ખાલી પુટ્ટી અને રિમોટ ડેસ્કટોપ પ્લસનો સમાવેશ થાય છે અને, ઇન્સ્ટોલેશન દરમિયાન, ફક્ત Windows માં URI સ્કીમ રજીસ્ટર કરવામાં આવી હતી. હવે, જ્યારે અમે RDP અથવા SSH દ્વારા ઑબ્જેક્ટ સાથે જોડાવા માગતા હતા, ત્યારે અમે અમારી સિસ્ટમ પર આ ક્રિયાને ક્લિક કરી અને કસ્ટમ URI કામ કર્યું. વિન્ડોઝ અથવા પુટ્ટીમાં બનેલ માનક mstsc.exe, જે "પ્લગઇન" નો ભાગ હતું, લોન્ચ કરવામાં આવ્યું હતું. મેં પ્લગઇન શબ્દને અવતરણમાં મૂક્યો છે કારણ કે આ શાસ્ત્રીય અર્થમાં બ્રાઉઝર પ્લગઇન નથી.

ઓછામાં ઓછું તે કંઈક હતું. અનુકૂળ એડ્રેસ બુક. વધુમાં, પુટ્ટીના કિસ્સામાં, બધું સામાન્ય રીતે સારું હતું; તેને ઇનપુટ પરિમાણો તરીકે IP કનેક્શન, લોગિન અને પાસવર્ડ આપી શકાય છે. તે. અમે પહેલાથી જ અમારા નેટવર્ક પર લિનક્સ સર્વર્સ સાથે પાસવર્ડ દાખલ કર્યા વિના એક ક્લિકથી કનેક્ટ થઈ ગયા છીએ. પરંતુ RDP સાથે તે એટલું સરળ નથી. માનક mstsc પરિમાણો તરીકે ઓળખપત્રો સપ્લાય કરી શકતું નથી. રિમોટ ડેસ્કટોપ પ્લસ બચાવમાં આવ્યા. તેણે આ થવા દીધું. હવે આપણે તેના વિના કરી શકીએ છીએ, પરંતુ લાંબા સમયથી તે અમારી સિસ્ટમમાં વિશ્વાસુ સહાયક હતો. HTTP(S) સાઇટ્સ સાથે બધું સરળ છે, આવા ઑબ્જેક્ટ્સ ફક્ત બ્રાઉઝરમાં ખોલવામાં આવે છે અને બસ. અનુકૂળ અને વ્યવહારુ. પરંતુ આ ફક્ત આંતરિક નેટવર્ક પર જ ખુશી હતી.

અમે ઑફિસમાંથી મોટાભાગની સમસ્યાઓ દૂરસ્થ રીતે હલ કરી હોવાથી, ગ્રાહકોને VPN ઉપલબ્ધ કરાવવાનું સૌથી સરળ હતું. અને પછી અમારી સિસ્ટમથી તેમને કનેક્ટ કરવું શક્ય હતું. પરંતુ તે હજુ પણ કંઈક અંશે અસુવિધાજનક હતું. દરેક ક્લાયંટ માટે, દરેક કમ્પ્યુટર પર યાદ રાખેલા VPN કનેક્શન્સનો સમૂહ રાખવા જરૂરી હતું, અને કોઈપણ સાથે કનેક્ટ કરતા પહેલા, તેને સંબંધિત VPN સક્ષમ કરવું જરૂરી હતું. અમે આ સોલ્યુશનનો લાંબા સમયથી ઉપયોગ કર્યો છે. પરંતુ ગ્રાહકોની સંખ્યા વધી રહી છે, VPN ની સંખ્યા પણ વધી રહી છે, અને આ બધું તાણવા લાગ્યું અને તેના માટે કંઈક કરવું પડ્યું. સિસ્ટમ પુનઃસ્થાપિત કર્યા પછી ખાસ કરીને મારી આંખોમાં આંસુ આવ્યા, જ્યારે મારે નવી Windows પ્રોફાઇલમાં ડઝનેક VPN કનેક્શન્સ ફરીથી દાખલ કરવા પડ્યા. આને સહન કરવાનું બંધ કરો, મેં કહ્યું, અને હું તેના વિશે શું કરી શકું તે વિશે વિચારવાનું શરૂ કર્યું.

એવું બન્યું કે બધા ગ્રાહકો પાસે રાઉટર તરીકે જાણીતી કંપની મિક્રોટિકના ઉપકરણો હતા. તેઓ લગભગ કોઈપણ કાર્ય કરવા માટે ખૂબ જ કાર્યાત્મક અને અનુકૂળ છે. નુકસાન એ છે કે તેઓ "હાઇજેક" છે. અમે બહારથી તમામ એક્સેસ બંધ કરીને આ સમસ્યાનું નિરાકરણ કર્યું. પરંતુ ગ્રાહકના સ્થાને આવ્યા વિના કોઈક રીતે તેમની ઍક્સેસ હોવી જરૂરી હતી, કારણ કે ... તે લાંબુ છે. અમે આવા દરેક મિક્રોટિક માટે ટનલ બનાવી અને તેને અલગ પૂલમાં અલગ કરી. કોઈપણ રૂટીંગ વિના, જેથી તમારા નેટવર્કનું ક્લાઈન્ટના નેટવર્ક અને એકબીજા સાથેના નેટવર્ક સાથે કોઈ જોડાણ ન હોય.

આ વિચારનો જન્મ એ સુનિશ્ચિત કરવા માટે થયો હતો કે જ્યારે હું સિસ્ટમમાં મને જોઈતા ઑબ્જેક્ટ પર ક્લિક કરું છું, ત્યારે કેન્દ્રીય મોનિટરિંગ સર્વર, બધા ક્લાયન્ટ મિક્રોટિકના SSH એકાઉન્ટ્સ જાણીને, ઇચ્છિત એક સાથે જોડાય છે, ઇચ્છિત હોસ્ટને ફોરવર્ડિંગ નિયમ બનાવે છે. જરૂરી પોર્ટ. અહીં કેટલાક મુદ્દાઓ છે. ઉકેલ સાર્વત્રિક નથી - તે ફક્ત Mikrotik માટે જ કામ કરશે, કારણ કે આદેશ વાક્યરચના બધા રાઉટર્સ માટે અલગ છે. ઉપરાંત, આવા ફોરવર્ડિંગને પછી કોઈક રીતે કાઢી નાખવાની જરૂર હતી, અને અમારી સિસ્ટમનો સર્વર ભાગ અનિવાર્યપણે કોઈપણ રીતે ટ્રૅક કરી શકતો નથી કે મેં મારું RDP સત્ર પૂર્ણ કર્યું છે કે કેમ. ઠીક છે, આવા ફોરવર્ડિંગ ક્લાયંટ માટે એક છિદ્ર છે. પરંતુ અમે સાર્વત્રિકતાનો પીછો કર્યો નથી, કારણ કે ... ઉત્પાદનનો ઉપયોગ ફક્ત અમારી કંપનીમાં જ થતો હતો અને તેને જાહેરમાં રજૂ કરવાનો કોઈ વિચાર નહોતો.

દરેક સમસ્યાનું નિરાકરણ તેની રીતે કરવામાં આવ્યું હતું. જ્યારે નિયમ બનાવવામાં આવ્યો હતો, ત્યારે આ ફોરવર્ડિંગ માત્ર એક ચોક્કસ બાહ્ય IP સરનામા માટે ઉપલબ્ધ હતું (જેમાંથી કનેક્શન શરૂ થયું હતું). તેથી સુરક્ષા છિદ્ર ટાળવામાં આવ્યું હતું. પરંતુ આવા દરેક જોડાણ સાથે, NAT પૃષ્ઠ પર એક Mikrotik નિયમ ઉમેરવામાં આવ્યો હતો અને તેને સાફ કરવામાં આવ્યો ન હતો. અને દરેક જણ જાણે છે કે જેટલા વધુ નિયમો છે, તેટલું વધુ રાઉટરનું પ્રોસેસર લોડ થાય છે. અને સામાન્ય રીતે, હું સ્વીકારી શક્યો નહીં કે એક દિવસ હું કેટલાક મિક્રોટિક પર જઈશ, અને ત્યાં સેંકડો મૃત, નકામા નિયમો હશે.

કારણ કે અમારું સર્વર કનેક્શન સ્ટેટસને ટ્રૅક કરી શકતું નથી, તેથી Mikrotik તેને પોતે જ ટ્રૅક કરવા દો. અને મેં એક સ્ક્રિપ્ટ લખી છે જે ચોક્કસ વર્ણન સાથે ફોરવર્ડિંગના તમામ નિયમોનું સતત નિરીક્ષણ કરે છે અને TCP કનેક્શનમાં યોગ્ય નિયમ છે કે કેમ તે તપાસે છે. જો ત્યાં થોડા સમય માટે એક ન હોય, તો પછી કનેક્શન કદાચ પહેલાથી જ પૂર્ણ થઈ ગયું છે અને આ ફોરવર્ડિંગ કાઢી નાખી શકાય છે. બધું કામ કર્યું, સ્ક્રિપ્ટ સારી રીતે કામ કર્યું.

માર્ગ દ્વારા, તે અહીં છે:

global atmonrulecounter {"dontDelete"="dontDelete"}
:foreach i in=[/ip firewall nat find comment~"atmon_script_main"] do={ 
	local dstport [/ip firewall nat get value-name="dst-port" $i]
	local dstaddress [/ip firewall nat get value-name="dst-address" $i]
	local dstaddrport "$dstaddress:$dstport"
	#log warning message=$dstaddrport
	local thereIsCon [/ip firewall connection find dst-address~"$dstaddrport"]
	if ($thereIsCon = "") do={
		set ($atmonrulecounter->$dstport) ($atmonrulecounter->$dstport + 1)
		#:log warning message=($atmonrulecounter->$dstport)
		if (($atmonrulecounter->$dstport) > 5) do={
			#log warning message="Removing nat rules added automaticaly by atmon_script"
			/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_main_$dstport"]
			/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_sub_$dstport"]
			set ($atmonrulecounter->$dstport) 0
		}
	} else {
		set ($atmonrulecounter->$dstport) 0
	}
}

ચોક્કસ તે વધુ સુંદર, ઝડપી, વગેરે બનાવી શકાયું હોત, પરંતુ તે કામ કર્યું, મિક્રોટિક લોડ કર્યું નહીં અને એક ઉત્તમ કાર્ય કર્યું. અમે આખરે માત્ર એક ક્લિકથી ક્લાયન્ટના સર્વર અને નેટવર્ક સાધનો સાથે કનેક્ટ થવામાં સક્ષમ હતા. VPN ખોલ્યા વિના અથવા પાસવર્ડ દાખલ કર્યા વિના. સિસ્ટમ સાથે કામ કરવા માટે ખરેખર અનુકૂળ બની ગયું છે. સેવાનો સમય ઘટાડવામાં આવ્યો હતો, અને અમે બધાએ જરૂરી વસ્તુઓ સાથે કનેક્ટ થવાને બદલે કામ કરવાનો સમય પસાર કર્યો.

Mikrotik બેકઅપ

અમે તમામ Mikrotik ના બેકઅપને FTP પર ગોઠવ્યું છે. અને એકંદરે બધું સારું હતું. પરંતુ જ્યારે તમારે બેકઅપ લેવાની જરૂર હોય, ત્યારે તમારે આ FTP ખોલીને તેને ત્યાં શોધવું પડતું હતું. અમારી પાસે એક સિસ્ટમ છે જ્યાં બધા રાઉટર્સ જોડાયેલા છે; અમે SSH દ્વારા ઉપકરણો સાથે વાતચીત કરી શકીએ છીએ. અમે તેને કેમ ન બનાવીએ કે સિસ્ટમ પોતે જ દરરોજ તમામ મિક્રોટિકમાંથી બેકઅપ લે, મેં વિચાર્યું. અને તેણે તેનો અમલ કરવાનું શરૂ કર્યું. અમે કનેક્ટ કર્યું, બેકઅપ લીધું અને તેને સ્ટોરેજમાં લઈ ગયા.

Mikrotik માંથી બેકઅપ લેવા માટે PHP માં સ્ક્રિપ્ટ કોડ:

<?php

	$IP = '0.0.0.0';
	$LOGIN = 'admin';
	$PASSWORD = '';
	$BACKUP_NAME = 'test';

    $connection = ssh2_connect($IP, 22);

    if (!ssh2_auth_password($connection, $LOGIN, $PASSWORD)) exit;

    ssh2_exec($connection, '/system backup save name="atmon" password="atmon"');
    stream_get_contents($connection);
    ssh2_exec($connection, '/export file="atmon.rsc"');
    stream_get_contents($connection);
    sleep(40); // Waiting bakup makes

    $sftp = ssh2_sftp($connection);

    // Download backup file
    $size = filesize("ssh2.sftp://$sftp/atmon.backup");
    $stream = fopen("ssh2.sftp://$sftp/atmon.backup", 'r');
    $contents = '';
    $read = 0;
    $len = $size;
    while ($read < $len && ($buf = fread($stream, $len - $read))) {
        $read += strlen($buf);
        $contents .= $buf;
    }
    file_put_contents ($BACKUP_NAME . ‘.backup’,$contents);
    @fclose($stream);

    sleep(3);
    // Download RSC file
    $size = filesize("ssh2.sftp://$sftp/atmon.rsc");
    $stream = fopen("ssh2.sftp://$sftp/atmon.rsc", 'r');
    $contents = '';
    $read = 0;
    $len = $size;
    while ($read < $len && ($buf = fread($stream, $len - $read))) {
        $read += strlen($buf);
        $contents .= $buf;
    }
    file_put_contents ($BACKUP_NAME . ‘.rsc’,$contents);
    @fclose($stream);

    ssh2_exec($connection, '/file remove atmon.backup');
    ssh2_exec($connection, '/file remove atmon.rsc');

?>

બેકઅપ બે સ્વરૂપોમાં લેવામાં આવે છે - બાઈનરી અને ટેક્સ્ટ રૂપરેખા. દ્વિસંગી જરૂરી રૂપરેખાને ઝડપથી પુનઃસ્થાપિત કરવામાં મદદ કરે છે, અને એક ટેક્સ્ટ તમને એ સમજવાની મંજૂરી આપે છે કે જો સાધનસામગ્રીની ફરજિયાત ફેરબદલી હોય અને બાઈનરી તેના પર અપલોડ કરી શકાતી નથી તો શું કરવાની જરૂર છે. પરિણામે, અમને સિસ્ટમમાં બીજી અનુકૂળ કાર્યક્ષમતા મળી. તદુપરાંત, નવી મિક્રોટિક ઉમેરતી વખતે, કંઈપણ ગોઠવવાની જરૂર નહોતી; મેં ફક્ત સિસ્ટમમાં ઑબ્જેક્ટ ઉમેર્યું અને SSH દ્વારા તેના માટે એકાઉન્ટ સેટ કર્યું. ત્યારબાદ તંત્રએ પોતે બેકઅપ લેવાની કાળજી લીધી હતી. SaaS Veliam ના વર્તમાન સંસ્કરણમાં હજી આ કાર્યક્ષમતા નથી, પરંતુ અમે તેને ટૂંક સમયમાં પોર્ટ કરીશું.

આંતરિક સિસ્ટમમાં તે કેવું દેખાતું હતું તેના સ્ક્રીનશૉટ્સ

સામાન્ય ડેટાબેઝ સ્ટોરેજમાં સંક્રમણ

મેં પહેલેથી જ ઉપર લખ્યું છે કે કલાકૃતિઓ દેખાય છે. કેટલીકવાર સિસ્ટમમાં ઑબ્જેક્ટ્સની સંપૂર્ણ સૂચિ અદૃશ્ય થઈ જાય છે, કેટલીકવાર ઑબ્જેક્ટને સંપાદિત કરતી વખતે, માહિતી સાચવવામાં આવતી નથી અને ઑબ્જેક્ટનું ત્રણ વખત નામ બદલવું પડતું હતું. આનાથી દરેક જણ ભયંકર રીતે ચિડાઈ ગયા. ઑબ્જેક્ટ્સનું અદૃશ્ય થવું ભાગ્યે જ બન્યું હતું, અને આ ફાઇલને પુનઃસ્થાપિત કરીને સરળતાથી પુનઃસ્થાપિત કરવામાં આવી હતી, પરંતુ ઑબ્જેક્ટ્સનું સંપાદન કરતી વખતે નિષ્ફળતા ઘણી વાર બની હતી. સંભવતઃ, મેં શરૂઆતમાં ડેટાબેઝ દ્વારા આ કર્યું ન હતું કારણ કે તે મારા મગજમાં બંધબેસતું ન હતું કે ફ્લેટ ટેબલમાં તમામ કનેક્શન્સ સાથેનું વૃક્ષ કેવી રીતે રાખવું શક્ય છે. તે સપાટ છે, પરંતુ વૃક્ષ અધિક્રમિક છે. પરંતુ મલ્ટીપલ એક્સેસ, અને ત્યારબાદ (જેમ કે સિસ્ટમ વધુ જટિલ બને છે) વ્યવહાર માટેનો સારો ઉકેલ એ DBMS છે. હું કદાચ આ સમસ્યાનો સામનો કરનાર પ્રથમ નથી. મેં ગુગલ કરવાનું શરૂ કર્યું. તે બહાર આવ્યું છે કે મારા પહેલાં દરેક વસ્તુની શોધ થઈ ચૂકી છે અને ત્યાં ઘણા અલ્ગોરિધમ્સ છે જે સપાટ ટેબલમાંથી એક વૃક્ષ બનાવે છે. દરેકને જોયા પછી, મેં તેમાંથી એકનો અમલ કર્યો. પરંતુ આ પહેલેથી જ સિસ્ટમનું નવું સંસ્કરણ હતું, કારણ કે... હકીકતમાં, આના કારણે, મારે ઘણું બધું ફરીથી લખવું પડ્યું. પરિણામ સ્વાભાવિક હતું, સિસ્ટમના રેન્ડમ વર્તનની સમસ્યાઓ દૂર થઈ ગઈ. કેટલાક એવું કહી શકે છે કે સોફ્ટવેર ડેવલપમેન્ટના ક્ષેત્રમાં ભૂલો ખૂબ જ કલાપ્રેમી છે (સિંગલ-થ્રેડેડ સ્ક્રિપ્ટો, માહિતીનો સંગ્રહ કે જે ફાઇલમાં વિવિધ થ્રેડોમાંથી એકસાથે ઘણી વખત એક્સેસ કરવામાં આવી હતી, વગેરે). કદાચ આ સાચું છે, પરંતુ મારું મુખ્ય કાર્ય વહીવટ હતું, અને પ્રોગ્રામિંગ એ મારા આત્મા માટે એક બાજુની હસ્ટલ હતી, અને મને પ્રોગ્રામરોની ટીમમાં કામ કરવાનો અનુભવ નહોતો, જ્યાં આવી મૂળભૂત બાબતો મને મારા વરિષ્ઠ દ્વારા તરત જ સૂચવવામાં આવી હોત. સાથીઓ તેથી, મેં આ બધી મુશ્કેલીઓ મારી જાતે ભરી દીધી, પરંતુ મેં સામગ્રી ખૂબ સારી રીતે શીખી. અને એ પણ, મારી નોકરીમાં ક્લાયન્ટ્સ સાથે મીટિંગ્સ, કંપનીને પ્રમોટ કરવાનો પ્રયાસ કરવાના હેતુથી કરવામાં આવેલી ક્રિયાઓ, કંપનીમાં વહીવટી સમસ્યાઓનો સમૂહ અને ઘણું બધું સામેલ છે. પરંતુ એક અથવા બીજી રીતે, જે પહેલેથી જ હતું તેની માંગ હતી. છોકરાઓ અને મેં જાતે અમારા રોજિંદા કામમાં ઉત્પાદનનો ઉપયોગ કર્યો. નિખાલસપણે અસફળ વિચારો અને ઉકેલો હતા કે જેના પર સમયનો વ્યય થતો હતો, પરંતુ અંતે તે સ્પષ્ટ થઈ ગયું કે આ કોઈ કાર્યકારી સાધન નથી અને કોઈએ તેનો ઉપયોગ કર્યો નથી અને તે વેલિઆમમાં સમાપ્ત થયો નથી.

હેલ્પડેસ્ક - હેલ્પડેસ્ક

હેલ્પડેસ્કની રચના કેવી રીતે થઈ તેનો ઉલ્લેખ કરવો ખોટું નથી. આ એક સંપૂર્ણપણે અલગ વાર્તા છે, કારણ કે ... વેલિઆમમાં આ પહેલેથી જ 3જી સંપૂર્ણપણે નવું સંસ્કરણ છે, જે અગાઉના બધા કરતા અલગ છે. હવે તે એક સરળ સિસ્ટમ છે, બિનજરૂરી ઘંટડીઓ અને સીટીઓ વિના સાહજિક, ડોમેન સાથે સંકલિત કરવાની ક્ષમતા સાથે, તેમજ ઇમેઇલની લિંકનો ઉપયોગ કરીને ગમે ત્યાંથી સમાન વપરાશકર્તા પ્રોફાઇલને ઍક્સેસ કરવાની ક્ષમતા સાથે. અને સૌથી મહત્ત્વની વાત એ છે કે, VPN અથવા પોર્ટ ફોરવર્ડિંગ વિના કોઈપણ જગ્યાએથી (ઘરે કે ઑફિસમાં) સીધા જ એપ્લિકેશનમાંથી VNC મારફત અરજદાર સાથે કનેક્ટ થવું શક્ય છે. હું તમને કહીશ કે અમે આમાં કેવી રીતે આવ્યા, પહેલા શું થયું અને કયા ભયંકર નિર્ણયો લેવામાં આવ્યા.

અમે જાણીતા TeamViewer દ્વારા વપરાશકર્તાઓ સાથે કનેક્ટ થયા છીએ. અમે જે વપરાશકર્તાઓને સેવા આપીએ છીએ તે તમામ કમ્પ્યુટર્સ ટીવી ઇન્સ્ટોલ કરેલું છે. પ્રથમ વસ્તુ જે અમે ખોટું કર્યું, અને પછીથી તેને દૂર કર્યું, તે દરેક HD ક્લાયંટને હાર્ડવેર સાથે લિંક કરવાનું હતું. વિનંતી છોડવા માટે વપરાશકર્તાએ HD સિસ્ટમમાં કેવી રીતે લૉગ ઇન કર્યું? ટીવી ઉપરાંત, દરેક વ્યક્તિએ તેમના કમ્પ્યુટર પર એક વિશિષ્ટ ઉપયોગિતા સ્થાપિત કરી હતી, જે લાઝરસમાં લખેલી હતી (અહીં ઘણા લોકો તેમની આંખો ફેરવશે, અને કદાચ Google પર પણ જશે કે તે શું છે, પરંતુ હું જાણતો હતો કે શ્રેષ્ઠ સંકલિત ભાષા ડેલ્ફી હતી, અને લાઝરસ લગભગ તે જ વસ્તુ, ફક્ત મફત). સામાન્ય રીતે, વપરાશકર્તાએ એક વિશિષ્ટ બેચ ફાઇલ શરૂ કરી હતી જેણે આ ઉપયોગિતાને લોન્ચ કરી હતી, જે બદલામાં સિસ્ટમના HWID વાંચે છે અને તે પછી બ્રાઉઝર લોંચ કરવામાં આવ્યું હતું અને અધિકૃતતા આવી હતી. આ કેમ કરવામાં આવ્યું? કેટલીક કંપનીઓમાં, સેવા આપતા વપરાશકર્તાઓની સંખ્યા વ્યક્તિગત રીતે ગણવામાં આવે છે, અને દરેક મહિના માટે સેવાની કિંમત લોકોની સંખ્યા પર આધારિત છે. આ સમજી શકાય તેવું છે, તમે કહો છો, પરંતુ તેને હાર્ડવેર સાથે કેમ જોડવામાં આવે છે? તે ખૂબ જ સરળ છે, કેટલાક વ્યક્તિઓ ઘરે આવ્યા અને તેમના ઘરના લેપટોપમાંથી "મારા માટે અહીં બધું સુંદર બનાવો" ની શૈલીમાં વિનંતી કરી. સિસ્ટમ HWID વાંચવા ઉપરાંત, ઉપયોગિતાએ વર્તમાન ટીમવ્યુઅર ID ને રજિસ્ટ્રીમાંથી ખેંચી અને તે અમને ટ્રાન્સમિટ પણ કર્યું. ટીમવ્યુઅર પાસે એકીકરણ માટે API છે. અને અમે આ એકીકરણ કર્યું. પરંતુ એક કેચ હતો. આ APIs દ્વારા, વપરાશકર્તાના કમ્પ્યુટર સાથે કનેક્ટ થવું અશક્ય છે જ્યારે તે સ્પષ્ટપણે આ સત્રની શરૂઆત ન કરે અને તેની સાથે કનેક્ટ કરવાનો પ્રયાસ કર્યા પછી, તેણે "પુષ્ટિ કરો" પર પણ ક્લિક કરવું આવશ્યક છે. તે સમયે, તે અમને તાર્કિક લાગતું હતું કે વપરાશકર્તાની વિનંતી વિના કોઈએ કનેક્ટ થવું જોઈએ નહીં, અને તે વ્યક્તિ કમ્પ્યુટર પર હોવાથી, તે સત્રની શરૂઆત કરશે અને રિમોટ કનેક્શન વિનંતીનો હકારાત્મક પ્રતિસાદ આપશે. બધું ખોટું બહાર આવ્યું. અરજદારો સત્રની શરૂઆત કરવાનું પ્રેસ કરવાનું ભૂલી ગયા હતા, અને તેમને ટેલિફોન વાતચીતમાં આ કહેવું પડ્યું હતું. આનાથી સમયનો વ્યય થયો અને પ્રક્રિયાની બંને બાજુએ નિરાશાજનક હતી. તદુપરાંત, જ્યારે કોઈ વ્યક્તિ વિનંતી છોડે છે ત્યારે આવી ક્ષણો માટે તે બિલકુલ અસામાન્ય નથી, પરંતુ જ્યારે તે લંચ માટે નીકળે ત્યારે જ તેને કનેક્ટ કરવાની મંજૂરી આપવામાં આવે છે. કારણ કે સમસ્યા ગંભીર નથી અને તે નથી ઈચ્છતો કે તેની કાર્ય પ્રક્રિયામાં વિક્ષેપ આવે. તદનુસાર, તે કનેક્શનને મંજૂરી આપવા માટે કોઈપણ બટન દબાવશે નહીં. હેલ્પડેસ્કમાં લોગ ઇન કરતી વખતે વધારાની કાર્યક્ષમતા આ રીતે દેખાય છે - ટીમવિવરનું ID વાંચવું. ટીમવિવર ઇન્સ્ટોલ કરતી વખતે ઉપયોગમાં લેવાતો કાયમી પાસવર્ડ અમે જાણતા હતા. વધુ સ્પષ્ટ રીતે, ફક્ત સિસ્ટમ જ તે જાણતી હતી, કારણ કે તે ઇન્સ્ટોલર અને અમારી સિસ્ટમમાં બનાવવામાં આવી હતી. તદનુસાર, એપ્લિકેશનમાંથી એક કનેક્શન બટન હતું જેના પર ક્લિક કરીને કોઈ પણ વસ્તુ માટે રાહ જોવાની જરૂર નહોતી, પરંતુ ટીમવ્યુઅર તરત જ ખોલ્યું અને કનેક્શન આવ્યું. પરિણામે, બે પ્રકારના સંભવિત જોડાણો હતા. અધિકૃત Teamviewer API અને અમારા સ્વ-નિર્મિત એક દ્વારા. મારા આશ્ચર્યની વાત એ છે કે, તેઓએ લગભગ તરત જ પ્રથમનો ઉપયોગ કરવાનું બંધ કરી દીધું હતું, જો કે તેનો ઉપયોગ ફક્ત વિશિષ્ટ કેસોમાં જ કરવાની સૂચના હતી અને જ્યારે વપરાશકર્તા પોતે જ આગળ વધે ત્યારે. તેમ છતાં, મને હવે સુરક્ષા આપો. પરંતુ તે બહાર આવ્યું છે કે અરજદારોને આની જરૂર નથી. પુષ્ટિકરણ બટન વિના તેમની સાથે કનેક્ટ થવાથી તે બધા એકદમ ઠીક છે.

Linux માં મલ્ટિથ્રેડિંગ પર સ્વિચ કરી રહ્યાં છીએ

બંદરોની પૂર્વનિર્ધારિત સૂચિની નિખાલસતા અને નેટવર્ક ઑબ્જેક્ટ્સની સરળ પિંગિંગ માટે નેટવર્ક સ્કેનરના પેસેજને ઝડપી બનાવવાનો પ્રશ્ન લાંબા સમયથી ઉભો થવા લાગ્યો છે. અહીં, અલબત્ત, પ્રથમ ઉકેલ જે ધ્યાનમાં આવે છે તે મલ્ટિથ્રેડિંગ છે. પિંગ પર વિતાવેલો મુખ્ય સમય પેકેટ પરત કરવાની રાહ જોતો હોવાથી, અને આગલું પિંગ જ્યાં સુધી પાછલું પેકેટ પાછું ન આવે ત્યાં સુધી શરૂ થઈ શકતું નથી, જે કંપનીઓમાં 20+ સર્વર વત્તા નેટવર્ક સાધનો પણ હતા, આ પહેલેથી જ એકદમ ધીમી ગતિએ કામ કરે છે. મુદ્દો એ છે કે એક પેકેજ અદૃશ્ય થઈ શકે છે, પરંતુ તેના વિશે સિસ્ટમ એડમિનિસ્ટ્રેટરને તરત જ સૂચિત કરશો નહીં. તે આવા સ્પામને ખૂબ જ ઝડપથી સ્વીકારવાનું બંધ કરશે. આનો અર્થ એ છે કે અપ્રાપ્યતા વિશે કોઈ નિષ્કર્ષ કાઢતા પહેલા તમારે દરેક ઑબ્જેક્ટને એક કરતા વધુ વાર પિંગ કરવાની જરૂર છે. વધુ પડતી વિગતમાં ગયા વિના, તેને સમાંતર બનાવવું જરૂરી છે કારણ કે જો આ કરવામાં આવ્યું નથી, તો સંભવતઃ સિસ્ટમ એડમિનિસ્ટ્રેટર ક્લાયંટ પાસેથી સમસ્યા વિશે શીખશે, મોનિટરિંગ સિસ્ટમમાંથી નહીં.

PHP પોતે બૉક્સની બહાર મલ્ટિથ્રેડિંગને સપોર્ટ કરતું નથી. મલ્ટિપ્રોસેસિંગ માટે સક્ષમ, તમે ફોર્ક કરી શકો છો. પરંતુ, વાસ્તવમાં, મારી પાસે પહેલેથી જ એક મતદાન મિકેનિઝમ લખાયેલું હતું અને હું તેને બનાવવા માંગતો હતો જેથી હું એકવાર ડેટાબેઝમાંથી મને જોઈતા તમામ નોડ્સની ગણતરી કરી શકું, એક જ સમયે બધું પિંગ કરી શકું, દરેકના પ્રતિસાદની રાહ જુઓ અને તે પછી જ તરત જ લખો. માહિતી. આ વાંચવાની વિનંતીઓની સંખ્યાને બચાવે છે. મલ્ટિથ્રેડિંગ આ વિચારમાં સંપૂર્ણ રીતે ફિટ છે. PHP માટે એક PThreads મોડ્યુલ છે જે તમને વાસ્તવિક મલ્ટિથ્રેડીંગ કરવાની પરવાનગી આપે છે, જો કે તેને PHP 7.2 પર સેટ કરવા માટે વાજબી માત્રામાં ટિંકરિંગની જરૂર પડી, પરંતુ તે થઈ ગયું. પોર્ટ સ્કેનિંગ અને પિંગ હવે ઝડપી છે. અને તેના બદલે, ઉદાહરણ તરીકે, પહેલા લેપ દીઠ 15 સેકન્ડ, આ પ્રક્રિયામાં 2 સેકન્ડનો સમય લાગવા લાગ્યો. તેનું સારું પરિણામ આવ્યું.

નવી કંપનીઓનું ઝડપી ઓડિટ

વિવિધ મેટ્રિક્સ અને હાર્ડવેર લાક્ષણિકતાઓ એકત્રિત કરવાની કાર્યક્ષમતા કેવી રીતે આવી? તે સરળ છે. કેટલીકવાર અમને વર્તમાન આઈટી ઈન્ફ્રાસ્ટ્રક્ચરનું ઓડિટ કરવાનો આદેશ આપવામાં આવે છે. ઠીક છે, નવા ક્લાયંટના ઑડિટને ઝડપી બનાવવા માટે આ જ વસ્તુ જરૂરી છે. અમને એવી કોઈ વસ્તુની જરૂર હતી જે અમને મધ્યમ અથવા મોટી કંપનીમાં આવવા દે અને તેમની પાસે શું છે તે ઝડપથી શોધી શકાય. મારા મતે, આંતરિક નેટવર્ક પર પિંગ ફક્ત તે લોકો દ્વારા અવરોધિત છે જેઓ તેમના પોતાના જીવનને જટિલ બનાવવા માંગે છે, અને અમારા અનુભવમાં તેમાંથી થોડા છે. પરંતુ આવા લોકો પણ છે. તદનુસાર, તમે સરળ પિંગ વડે ઉપકરણોની હાજરી માટે નેટવર્ક્સને ઝડપથી સ્કેન કરી શકો છો. પછી અમે તેમને ઉમેરી શકીએ છીએ અને અમને રુચિ ધરાવતા ખુલ્લા બંદરો માટે સ્કેન કરી શકીએ છીએ. વાસ્તવમાં, આ કાર્યક્ષમતા પહેલાથી જ અસ્તિત્વમાં છે; સેન્ટ્રલ સર્વરમાંથી સ્લેવમાં આદેશ ઉમેરવા માટે તે જરૂરી હતું જેથી તે ઉલ્લેખિત નેટવર્ક્સને સ્કેન કરી શકે અને સૂચિમાં જે મળે તે બધું ઉમેરી શકે. હું ઉલ્લેખ કરવાનું ભૂલી ગયો, એવું માનવામાં આવે છે કે અમારી પાસે પહેલેથી જ રૂપરેખાંકિત સિસ્ટમ (સ્લેવ મોનિટરિંગ સર્વર) સાથે તૈયાર છબી છે જે અમે ઑડિટ દરમિયાન ક્લાયંટમાંથી ફક્ત રોલ આઉટ કરી શકીએ છીએ અને તેને અમારા ક્લાઉડ સાથે કનેક્ટ કરી શકીએ છીએ.

પરંતુ ઑડિટના પરિણામમાં સામાન્ય રીતે વિવિધ માહિતીનો સમૂહ શામેલ હોય છે, અને તેમાંથી એક એ છે કે નેટવર્ક પર કયા પ્રકારનાં ઉપકરણો છે. સૌ પ્રથમ, અમને ડોમેનના ભાગ રૂપે Windows સર્વર્સ અને Windows વર્કસ્ટેશનમાં રસ હતો. મધ્યમ અને મોટી કંપનીઓમાં ડોમેનનો અભાવ કદાચ નિયમનો અપવાદ છે. એક ભાષા બોલવા માટે, સરેરાશ, મારા મતે, 100+ લોકો છે. તમામ વિન્ડોઝ મશીનો અને સર્વર્સમાંથી ડેટા એકત્રિત કરવાની રીત સાથે આવવું જરૂરી હતું, તેમના IP અને ડોમેન એડમિનિસ્ટ્રેટર એકાઉન્ટને જાણીને, પરંતુ તેમાંના દરેક પર કોઈપણ સોફ્ટવેર ઇન્સ્ટોલ કર્યા વિના. WMI ઇન્ટરફેસ બચાવમાં આવે છે. વિન્ડોઝ મેનેજમેન્ટ ઇન્સ્ટ્રુમેન્ટેશન (WMI) નો શાબ્દિક અર્થ છે વિન્ડોઝ મેનેજમેન્ટ ટૂલ્સ. WMI એ વિન્ડોઝ પ્લેટફોર્મ પર ચાલતા કોમ્પ્યુટર ઈન્ફ્રાસ્ટ્રક્ચરના વિવિધ ભાગોની કામગીરીના કેન્દ્રિય સંચાલન અને દેખરેખ માટેની મૂળભૂત તકનીકોમાંની એક છે. વિકિ પરથી લીધેલ. આગળ, ડેબિયન માટે wmic (આ WMI ક્લાયંટ છે) કમ્પાઇલ કરવા માટે મારે ફરીથી ટિંકર કરવું પડ્યું. બધું તૈયાર થઈ ગયા પછી, જરૂરી માહિતી માટે wmic દ્વારા જરૂરી નોડ્સનું મતદાન કરવાનું બાકી હતું. WMI દ્વારા તમે Windows કમ્પ્યુટરમાંથી લગભગ કોઈપણ માહિતી મેળવી શકો છો, અને વધુમાં, તમે તેના દ્વારા કમ્પ્યુટરને નિયંત્રિત પણ કરી શકો છો, ઉદાહરણ તરીકે, તેને રીબૂટ કરવા માટે મોકલો. આ રીતે અમારી સિસ્ટમમાં વિન્ડોઝ સ્ટેશનો અને સર્વર્સ વિશેની માહિતીનો સંગ્રહ દેખાયો. આ ઉપરાંત, વર્તમાન સિસ્ટમ લોડ સૂચકાંકો વિશે વર્તમાન માહિતી હતી. અમે તેમને વધુ વાર વિનંતી કરીએ છીએ, અને હાર્ડવેર પરની માહિતી ઓછી વાર. આ પછી, ઓડિટીંગ થોડું વધુ આનંદપ્રદ બન્યું.

સોફ્ટવેર વિતરણ નિર્ણય

અમે દરરોજ સિસ્ટમનો ઉપયોગ કરીએ છીએ, અને તે દરેક તકનીકી કર્મચારી માટે હંમેશા ખુલ્લું છે. અને અમે વિચાર્યું કે અમારી પાસે જે છે તે અમે અન્ય લોકો સાથે શેર કરી શકીએ છીએ. તંત્ર હજુ સુધી વિતરણ કરવા તૈયાર ન હતું. ઘણું બધું ફરીથી કામ કરવું પડ્યું જેથી સ્થાનિક સંસ્કરણ SaaS માં ફેરવાઈ જાય. આમાં સિસ્ટમના વિવિધ ટેકનિકલ પાસાઓ (રિમોટ કનેક્શન્સ, સપોર્ટ સર્વિસ), લાઇસન્સિંગ માટેના મોડ્યુલ્સનું વિશ્લેષણ, ગ્રાહક ડેટાબેઝનું શાર્ડિંગ, દરેક સેવાનું સ્કેલિંગ અને તમામ ભાગો માટે ઓટો-અપડેટ સિસ્ટમ્સનો વિકાસ સામેલ છે. પરંતુ આ લેખનો બીજો ભાગ હશે.

અપડેટ

બીજો ભાગ

સોર્સ: www.habr.com