ਆਊਟਸੋਰਸਿੰਗ ਤੋਂ ਵਿਕਾਸ ਤੱਕ (ਭਾਗ 1)

ਸਾਰਿਆਂ ਨੂੰ ਹੈਲੋ, ਮੇਰਾ ਨਾਮ ਸੇਰਗੇਈ ਐਮੇਲਯਾਚਿਕ ਹੈ. ਮੈਂ ਆਡਿਟ-ਟੈਲੀਕਾਮ ਕੰਪਨੀ ਦਾ ਮੁਖੀ ਹਾਂ, ਵੇਲੀਅਮ ਸਿਸਟਮ ਦਾ ਮੁੱਖ ਵਿਕਾਸਕਾਰ ਅਤੇ ਲੇਖਕ ਹਾਂ। ਮੈਂ ਇਸ ਬਾਰੇ ਇੱਕ ਲੇਖ ਲਿਖਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਕਿ ਕਿਵੇਂ ਮੈਂ ਅਤੇ ਮੇਰੇ ਦੋਸਤ ਨੇ ਇੱਕ ਆਊਟਸੋਰਸਿੰਗ ਕੰਪਨੀ ਬਣਾਈ, ਆਪਣੇ ਲਈ ਸੌਫਟਵੇਅਰ ਲਿਖਿਆ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਇਸਨੂੰ SaaS ਸਿਸਟਮ ਦੁਆਰਾ ਹਰ ਕਿਸੇ ਨੂੰ ਵੰਡਣਾ ਸ਼ੁਰੂ ਕੀਤਾ। ਇਸ ਬਾਰੇ ਮੈਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਵਿਸ਼ਵਾਸ ਨਹੀਂ ਕੀਤਾ ਕਿ ਇਹ ਸੰਭਵ ਹੈ. ਲੇਖ ਵਿੱਚ ਨਾ ਸਿਰਫ਼ ਇੱਕ ਕਹਾਣੀ ਹੋਵੇਗੀ, ਸਗੋਂ ਇਸ ਬਾਰੇ ਤਕਨੀਕੀ ਵੇਰਵੇ ਵੀ ਹੋਣਗੇ ਕਿ ਵੇਲੀਅਮ ਉਤਪਾਦ ਕਿਵੇਂ ਬਣਾਇਆ ਗਿਆ ਸੀ। ਸਰੋਤ ਕੋਡ ਦੇ ਕੁਝ ਟੁਕੜਿਆਂ ਸਮੇਤ। ਮੈਂ ਤੁਹਾਨੂੰ ਦੱਸਾਂਗਾ ਕਿ ਅਸੀਂ ਕਿਹੜੀਆਂ ਗਲਤੀਆਂ ਕੀਤੀਆਂ ਹਨ ਅਤੇ ਅਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਕਿਵੇਂ ਸੁਧਾਰਿਆ ਹੈ। ਸ਼ੰਕੇ ਸਨ ਕਿ ਅਜਿਹਾ ਲੇਖ ਛਾਪਿਆ ਜਾਵੇ ਜਾਂ ਨਹੀਂ। ਪਰ ਮੈਂ ਸੋਚਿਆ ਕਿ ਲੇਖ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਨਾ ਕਰਨ ਅਤੇ ਇਸ ਬਾਰੇ ਸੋਚਣ ਨਾਲੋਂ ਕਿ ਅਜਿਹਾ ਕਰਨਾ, ਫੀਡਬੈਕ ਪ੍ਰਾਪਤ ਕਰਨਾ ਅਤੇ ਸੁਧਾਰ ਕਰਨਾ ਬਿਹਤਰ ਸੀ, ਜੇ ...

prehistory

ਮੈਂ ਇੱਕ ਕੰਪਨੀ ਵਿੱਚ ਇੱਕ IT ਕਰਮਚਾਰੀ ਵਜੋਂ ਕੰਮ ਕੀਤਾ। ਇੱਕ ਵਿਆਪਕ ਨੈੱਟਵਰਕ ਢਾਂਚੇ ਦੇ ਨਾਲ ਕੰਪਨੀ ਕਾਫ਼ੀ ਵੱਡੀ ਸੀ। ਮੈਂ ਆਪਣੀਆਂ ਨੌਕਰੀਆਂ ਦੀਆਂ ਜ਼ਿੰਮੇਵਾਰੀਆਂ 'ਤੇ ਧਿਆਨ ਨਹੀਂ ਰੱਖਾਂਗਾ, ਮੈਂ ਸਿਰਫ ਇਹ ਕਹਾਂਗਾ ਕਿ ਉਨ੍ਹਾਂ ਨੇ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਦੇ ਵਿਕਾਸ ਨੂੰ ਸ਼ਾਮਲ ਨਹੀਂ ਕੀਤਾ.

ਸਾਡੇ ਕੋਲ ਨਿਗਰਾਨੀ ਸੀ, ਪਰ ਅਕਾਦਮਿਕ ਦਿਲਚਸਪੀ ਤੋਂ ਬਾਹਰ ਮੈਂ ਆਪਣਾ ਸਭ ਤੋਂ ਸਰਲ ਲਿਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ। ਵਿਚਾਰ ਇਹ ਸੀ: ਮੈਂ ਚਾਹੁੰਦਾ ਸੀ ਕਿ ਇਹ ਵੈੱਬ 'ਤੇ ਹੋਵੇ, ਤਾਂ ਜੋ ਮੈਂ ਬਿਨਾਂ ਕਿਸੇ ਗਾਹਕ ਨੂੰ ਸਥਾਪਿਤ ਕੀਤੇ ਆਸਾਨੀ ਨਾਲ ਅੰਦਰ ਜਾ ਸਕਾਂ ਅਤੇ ਦੇਖ ਸਕਾਂ ਕਿ ਕਿਸੇ ਵੀ ਡਿਵਾਈਸ ਤੋਂ ਨੈੱਟਵਰਕ ਨਾਲ ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਜਿਸ ਵਿੱਚ Wi-Fi ਰਾਹੀਂ ਇੱਕ ਮੋਬਾਈਲ ਡਿਵਾਈਸ ਵੀ ਸ਼ਾਮਲ ਹੈ, ਅਤੇ ਮੈਂ ਅਸਲ ਵਿੱਚ ਜਲਦੀ ਸਮਝਣਾ ਚਾਹੁੰਦਾ ਸੀ ਕਿ ਕਮਰੇ ਵਿੱਚ ਅਜਿਹਾ ਕੀ ਉਪਕਰਨ ਹੈ ਜੋ "ਮੋਪੀ" ਬਣ ਗਿਆ ਹੈ ਕਿਉਂਕਿ... ਅਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦੇ ਜਵਾਬ ਸਮੇਂ ਲਈ ਬਹੁਤ ਸਖਤ ਲੋੜਾਂ ਸਨ। ਨਤੀਜੇ ਵਜੋਂ, ਮੇਰੇ ਸਿਰ ਵਿੱਚ ਇੱਕ ਸਧਾਰਨ ਵੈਬ ਪੇਜ ਲਿਖਣ ਲਈ ਇੱਕ ਯੋਜਨਾ ਪੈਦਾ ਹੋਈ ਸੀ ਜਿਸ ਉੱਤੇ ਇੱਕ ਨੈਟਵਰਕ ਡਾਇਗ੍ਰਾਮ ਦੇ ਨਾਲ ਇੱਕ jpeg ਬੈਕਗ੍ਰਾਉਂਡ ਸੀ, ਇਸ ਤਸਵੀਰ ਵਿੱਚ ਉਹਨਾਂ ਦੇ IP ਪਤਿਆਂ ਦੇ ਨਾਲ ਡਿਵਾਈਸਾਂ ਨੂੰ ਆਪਣੇ ਆਪ ਕੱਟੋ, ਅਤੇ ਇਸਦੇ ਸਿਖਰ 'ਤੇ ਗਤੀਸ਼ੀਲ ਸਮੱਗਰੀ ਦਿਖਾਓ। ਹਰੇ ਜਾਂ ਫਲੈਸ਼ਿੰਗ ਲਾਲ IP ਐਡਰੈੱਸ ਦੇ ਰੂਪ ਵਿੱਚ ਲੋੜੀਂਦੇ ਨਿਰਦੇਸ਼ਾਂਕ ਵਿੱਚ ਤਸਵੀਰ। ਕੰਮ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ, ਆਓ ਸ਼ੁਰੂ ਕਰੀਏ.

ਪਹਿਲਾਂ, ਮੈਂ ਡੇਲਫੀ, ਪੀਐਚਪੀ, ਜੇਐਸ ਅਤੇ ਬਹੁਤ ਹੀ ਸਤਹੀ C++ ਵਿੱਚ ਪ੍ਰੋਗਰਾਮਿੰਗ ਕਰ ਰਿਹਾ ਸੀ। ਮੈਂ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਣਦਾ ਹਾਂ ਕਿ ਨੈੱਟਵਰਕ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ। VLAN, ਰੂਟਿੰਗ (OSPF, EIGRP, BGP), NAT। ਇਹ ਮੇਰੇ ਲਈ ਆਪਣੇ ਆਪ ਨੂੰ ਇੱਕ ਮੁੱਢਲੀ ਨਿਗਰਾਨੀ ਪ੍ਰੋਟੋਟਾਈਪ ਲਿਖਣ ਲਈ ਕਾਫੀ ਸੀ.

ਮੈਂ ਉਹ ਲਿਖਿਆ ਜੋ ਮੈਂ PHP ਵਿੱਚ ਯੋਜਨਾ ਬਣਾਈ ਸੀ. ਅਪਾਚੇ ਅਤੇ PHP ਸਰਵਰ ਵਿੰਡੋਜ਼ ਉੱਤੇ ਸੀ ਕਿਉਂਕਿ... ਉਸ ਸਮੇਂ ਮੇਰੇ ਲਈ ਲੀਨਕਸ ਕੁਝ ਸਮਝ ਤੋਂ ਬਾਹਰ ਅਤੇ ਬਹੁਤ ਗੁੰਝਲਦਾਰ ਸੀ, ਜਿਵੇਂ ਕਿ ਇਹ ਬਾਅਦ ਵਿੱਚ ਸਾਹਮਣੇ ਆਇਆ, ਮੈਂ ਬਹੁਤ ਗਲਤ ਸੀ ਅਤੇ ਕਈ ਥਾਵਾਂ 'ਤੇ ਲੀਨਕਸ ਵਿੰਡੋਜ਼ ਨਾਲੋਂ ਬਹੁਤ ਸਰਲ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਵੱਖਰਾ ਵਿਸ਼ਾ ਹੈ ਅਤੇ ਅਸੀਂ ਸਾਰੇ ਜਾਣਦੇ ਹਾਂ ਕਿ ਇੱਥੇ ਕਿੰਨੇ ਹੋਲੀਵਰ ਹਨ। ਇਸ ਵਿਸ਼ੇ. ਵਿੰਡੋਜ਼ ਟਾਸਕ ਸ਼ਡਿਊਲਰ ਨੇ ਇੱਕ ਛੋਟੇ ਅੰਤਰਾਲ 'ਤੇ ਖਿੱਚਿਆ (ਮੈਨੂੰ ਬਿਲਕੁਲ ਯਾਦ ਨਹੀਂ ਹੈ, ਪਰ ਹਰ ਤਿੰਨ ਸਕਿੰਟਾਂ ਵਿੱਚ ਇੱਕ ਵਾਰ ਵਰਗਾ ਕੁਝ) ਇੱਕ PHP ਸਕ੍ਰਿਪਟ ਜਿਸ ਨੇ ਇੱਕ ਆਮ ਪਿੰਗ ਨਾਲ ਸਾਰੀਆਂ ਵਸਤੂਆਂ ਨੂੰ ਪੋਲ ਕੀਤਾ ਅਤੇ ਸਟੇਟ ਨੂੰ ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕੀਤਾ.

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

ਹਾਂ, ਹਾਂ, ਉਸ ਸਮੇਂ ਇੱਕ ਡੇਟਾਬੇਸ ਨਾਲ ਕੰਮ ਕਰਨਾ ਵੀ ਮੇਰੇ ਲਈ ਮਾਹਰ ਨਹੀਂ ਸੀ. ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ ਸੀ ਕਿ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਸਮਾਨਾਂਤਰ ਬਣਾਉਣਾ ਸੰਭਵ ਸੀ, ਅਤੇ ਸਾਰੇ ਨੈਟਵਰਕ ਨੋਡਾਂ ਵਿੱਚੋਂ ਲੰਘਣ ਵਿੱਚ ਬਹੁਤ ਸਮਾਂ ਲੱਗਿਆ, ਕਿਉਂਕਿ ... ਇਹ ਇੱਕ ਥਰਿੱਡ ਵਿੱਚ ਵਾਪਰਿਆ। ਸਮੱਸਿਆਵਾਂ ਖਾਸ ਤੌਰ 'ਤੇ ਪੈਦਾ ਹੋਈਆਂ ਜਦੋਂ ਕਈ ਨੋਡ ਉਪਲਬਧ ਨਹੀਂ ਸਨ, ਕਿਉਂਕਿ ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਨੇ ਸਕ੍ਰਿਪਟ ਨੂੰ 300 ms ਲਈ ਦੇਰੀ ਕੀਤੀ। ਕਲਾਇੰਟ ਸਾਈਡ 'ਤੇ ਇੱਕ ਸਧਾਰਨ ਲੂਪਿੰਗ ਫੰਕਸ਼ਨ ਸੀ ਜੋ, ਕੁਝ ਸਕਿੰਟਾਂ ਦੇ ਅੰਤਰਾਲਾਂ 'ਤੇ, Ajax ਬੇਨਤੀ ਨਾਲ ਸਰਵਰ ਤੋਂ ਅੱਪਡੇਟ ਕੀਤੀ ਜਾਣਕਾਰੀ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਦਾ ਸੀ ਅਤੇ ਇੰਟਰਫੇਸ ਨੂੰ ਅੱਪਡੇਟ ਕਰਦਾ ਸੀ। ਖੈਰ, ਫਿਰ, ਇੱਕ ਕਤਾਰ ਵਿੱਚ 3 ਅਸਫਲ ਪਿੰਗਾਂ ਤੋਂ ਬਾਅਦ, ਜੇ ਕੰਪਿਊਟਰ 'ਤੇ ਨਿਗਰਾਨੀ ਵਾਲਾ ਇੱਕ ਵੈੱਬ ਪੇਜ ਖੁੱਲ੍ਹਾ ਸੀ, ਤਾਂ ਇੱਕ ਖੁਸ਼ਹਾਲ ਰਚਨਾ ਖੇਡੀ ਗਈ।

ਜਦੋਂ ਸਭ ਕੁਝ ਕੰਮ ਕੀਤਾ, ਮੈਂ ਨਤੀਜੇ ਤੋਂ ਬਹੁਤ ਪ੍ਰੇਰਿਤ ਸੀ ਅਤੇ ਸੋਚਿਆ ਕਿ ਮੈਂ ਇਸ ਵਿੱਚ ਹੋਰ ਵਾਧਾ ਕਰ ਸਕਦਾ ਹਾਂ (ਮੇਰੇ ਗਿਆਨ ਅਤੇ ਸਮਰੱਥਾਵਾਂ ਦੇ ਕਾਰਨ)। ਪਰ ਮੈਨੂੰ ਹਮੇਸ਼ਾ ਇੱਕ ਮਿਲੀਅਨ ਚਾਰਟ ਵਾਲੇ ਸਿਸਟਮ ਪਸੰਦ ਨਹੀਂ ਸਨ, ਜੋ ਮੈਂ ਉਦੋਂ ਸੋਚਿਆ ਸੀ, ਅਤੇ ਅੱਜ ਵੀ ਸੋਚਦਾ ਹਾਂ, ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਬੇਲੋੜੇ ਹਨ। ਮੈਂ ਉੱਥੇ ਸਿਰਫ਼ ਉਹੀ ਪਾਉਣਾ ਚਾਹੁੰਦਾ ਸੀ ਜੋ ਅਸਲ ਵਿੱਚ ਮੇਰੇ ਕੰਮ ਵਿੱਚ ਮੇਰੀ ਮਦਦ ਕਰੇਗਾ। ਇਹ ਸਿਧਾਂਤ ਅੱਜ ਤੱਕ ਵੇਲੀਅਮ ਦੇ ਵਿਕਾਸ ਲਈ ਬੁਨਿਆਦੀ ਬਣਿਆ ਹੋਇਆ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਮੈਂ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਇਹ ਬਹੁਤ ਵਧੀਆ ਹੋਵੇਗਾ ਜੇਕਰ ਮੈਨੂੰ ਨਿਗਰਾਨੀ ਨੂੰ ਖੁੱਲ੍ਹਾ ਰੱਖਣ ਅਤੇ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਜਾਣਨਾ ਨਾ ਪਵੇ, ਅਤੇ ਜਦੋਂ ਇਹ ਵਾਪਰਿਆ, ਤਾਂ ਪੰਨਾ ਖੋਲ੍ਹੋ ਅਤੇ ਦੇਖੋ ਕਿ ਇਹ ਸਮੱਸਿਆ ਵਾਲਾ ਨੈਟਵਰਕ ਨੋਡ ਕਿੱਥੇ ਸਥਿਤ ਹੈ ਅਤੇ ਇਸ ਨਾਲ ਅੱਗੇ ਕੀ ਕਰਨਾ ਹੈ . ਕਿਸੇ ਤਰ੍ਹਾਂ ਮੈਂ ਉਸ ਸਮੇਂ ਈਮੇਲ ਨਹੀਂ ਪੜ੍ਹੀ, ਮੈਂ ਇਸਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ. ਮੈਨੂੰ ਇੰਟਰਨੈੱਟ 'ਤੇ ਪਤਾ ਲੱਗਾ ਹੈ ਕਿ ਐਸਐਮਐਸ ਗੇਟਵੇ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਤੁਸੀਂ ਇੱਕ GET ਜਾਂ POST ਬੇਨਤੀ ਭੇਜ ਸਕਦੇ ਹੋ, ਅਤੇ ਉਹ ਮੇਰੇ ਮੋਬਾਈਲ ਫੋਨ 'ਤੇ ਮੇਰੇ ਲਿਖੇ ਟੈਕਸਟ ਦੇ ਨਾਲ ਇੱਕ SMS ਭੇਜਣਗੇ। ਮੈਨੂੰ ਤੁਰੰਤ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਮੈਂ ਸੱਚਮੁੱਚ ਇਹ ਚਾਹੁੰਦਾ ਸੀ. ਅਤੇ ਮੈਂ ਦਸਤਾਵੇਜ਼ਾਂ ਦਾ ਅਧਿਐਨ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। ਕੁਝ ਸਮੇਂ ਬਾਅਦ ਮੈਂ ਸਫਲ ਹੋ ਗਿਆ, ਅਤੇ ਹੁਣ ਮੈਨੂੰ "ਡਿੱਗੀ ਹੋਈ ਵਸਤੂ" ਦੇ ਨਾਮ ਨਾਲ ਆਪਣੇ ਮੋਬਾਈਲ ਫੋਨ 'ਤੇ ਨੈਟਵਰਕ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਇੱਕ SMS ਪ੍ਰਾਪਤ ਹੋਇਆ। ਹਾਲਾਂਕਿ ਸਿਸਟਮ ਮੁੱਢਲਾ ਸੀ, ਇਹ ਮੇਰੇ ਦੁਆਰਾ ਲਿਖਿਆ ਗਿਆ ਸੀ, ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਣ ਚੀਜ਼ ਜਿਸਨੇ ਮੈਨੂੰ ਇਸਨੂੰ ਵਿਕਸਤ ਕਰਨ ਲਈ ਪ੍ਰੇਰਿਤ ਕੀਤਾ ਉਹ ਸੀ ਕਿ ਇਹ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਗਰਾਮ ਸੀ ਜਿਸਨੇ ਮੇਰੇ ਕੰਮ ਵਿੱਚ ਸੱਚਮੁੱਚ ਮੇਰੀ ਮਦਦ ਕੀਤੀ।

ਅਤੇ ਫਿਰ ਉਹ ਦਿਨ ਆਇਆ ਜਦੋਂ ਇੰਟਰਨੈਟ ਚੈਨਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਕੰਮ 'ਤੇ ਚਲਾ ਗਿਆ, ਅਤੇ ਮੇਰੀ ਨਿਗਰਾਨੀ ਨੇ ਮੈਨੂੰ ਇਸ ਬਾਰੇ ਪਤਾ ਨਹੀਂ ਲੱਗਣ ਦਿੱਤਾ. ਕਿਉਂਕਿ Google DNS ਅਜੇ ਵੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪਿੰਗ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਹ ਸੋਚਣ ਦਾ ਸਮਾਂ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਵੇਂ ਨਿਗਰਾਨੀ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਸੰਚਾਰ ਚੈਨਲ ਜ਼ਿੰਦਾ ਹੈ। ਇਹ ਕਿਵੇਂ ਕਰਨਾ ਹੈ ਇਸ ਬਾਰੇ ਵੱਖੋ-ਵੱਖਰੇ ਵਿਚਾਰ ਸਨ। ਮੇਰੇ ਕੋਲ ਸਾਰੇ ਉਪਕਰਨਾਂ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਸੀ। ਸਾਨੂੰ ਇਹ ਪਤਾ ਲਗਾਉਣਾ ਪਿਆ ਕਿ ਕਿਸ ਤਰ੍ਹਾਂ ਇਹ ਸਮਝਣਾ ਹੈ ਕਿ ਕਿਹੜਾ ਚੈਨਲ ਲਾਈਵ ਹੈ, ਪਰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਇਸ ਨੂੰ ਨੈੱਟਵਰਕ ਉਪਕਰਣਾਂ 'ਤੇ ਦੇਖਣ ਦੇ ਯੋਗ ਹੋਣ ਤੋਂ ਬਿਨਾਂ। ਫਿਰ ਇੱਕ ਸਹਿਕਰਮੀ ਨੇ ਇਹ ਵਿਚਾਰ ਲਿਆ ਕਿ ਇਹ ਸੰਭਵ ਹੈ ਕਿ ਜਨਤਕ ਸਰਵਰਾਂ ਲਈ ਰੂਟ ਟਰੇਸਿੰਗ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਵਰਤਮਾਨ ਵਿੱਚ ਇੰਟਰਨੈਟ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਕਿਹੜਾ ਸੰਚਾਰ ਚੈਨਲ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਮੈਂ ਜਾਂਚ ਕੀਤੀ ਅਤੇ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਨਿਕਲਿਆ. ਟਰੇਸ ਕਰਨ ਵੇਲੇ ਵੱਖ-ਵੱਖ ਰਸਤੇ ਸਨ।

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

ਇਸ ਲਈ ਇੱਕ ਹੋਰ ਸਕ੍ਰਿਪਟ ਪ੍ਰਗਟ ਹੋਈ, ਜਾਂ ਇਸ ਦੀ ਬਜਾਏ, ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਉਸੇ ਸਕ੍ਰਿਪਟ ਦੇ ਅੰਤ ਵਿੱਚ ਟਰੇਸ ਜੋੜਿਆ ਗਿਆ ਸੀ, ਜਿਸ ਨੇ ਨੈੱਟਵਰਕ 'ਤੇ ਸਾਰੇ ਡਿਵਾਈਸਾਂ ਨੂੰ ਪਿੰਗ ਕੀਤਾ ਸੀ। ਆਖ਼ਰਕਾਰ, ਇਹ ਇਕ ਹੋਰ ਲੰਬੀ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜੋ ਇਕੋ ਧਾਗੇ ਵਿਚ ਚਲਾਈ ਗਈ ਸੀ ਅਤੇ ਪੂਰੀ ਸਕ੍ਰਿਪਟ ਦੇ ਕੰਮ ਨੂੰ ਹੌਲੀ ਕਰ ਦਿੱਤਾ ਗਿਆ ਸੀ. ਪਰ ਫਿਰ ਇਹ ਇੰਨਾ ਸਪੱਸ਼ਟ ਨਹੀਂ ਸੀ. ਪਰ ਇੱਕ ਤਰੀਕੇ ਨਾਲ ਜਾਂ ਕੋਈ ਹੋਰ, ਉਸਨੇ ਆਪਣਾ ਕੰਮ ਕੀਤਾ, ਕੋਡ ਨੇ ਸਖਤੀ ਨਾਲ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਕਿ ਹਰੇਕ ਚੈਨਲ ਲਈ ਕਿਸ ਤਰ੍ਹਾਂ ਦੀ ਟਰੇਸਿੰਗ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ. ਇਸ ਤਰ੍ਹਾਂ ਸਿਸਟਮ ਨੇ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ, ਜਿਸ ਨੇ ਪਹਿਲਾਂ ਹੀ ਨਿਗਰਾਨੀ ਕੀਤੀ (ਉੱਚੀ ਕਿਹਾ, ਕਿਉਂਕਿ ਇੱਥੇ ਕੋਈ ਮੈਟ੍ਰਿਕਸ ਦਾ ਕੋਈ ਸੰਗ੍ਰਹਿ ਨਹੀਂ ਸੀ, ਪਰ ਸਿਰਫ਼ ਪਿੰਗ) ਨੈਟਵਰਕ ਡਿਵਾਈਸਾਂ (ਰਾਊਟਰ, ਸਵਿੱਚ, ਵਾਈ-ਫਾਈ, ਆਦਿ) ਅਤੇ ਬਾਹਰੀ ਸੰਸਾਰ ਨਾਲ ਸੰਚਾਰ ਚੈਨਲ। . SMS ਸੁਨੇਹੇ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਆਉਂਦੇ ਹਨ ਅਤੇ ਚਿੱਤਰ ਹਮੇਸ਼ਾ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਸਮੱਸਿਆ ਕਿੱਥੇ ਸੀ।

ਅੱਗੋਂ ਰੋਜ਼ ਦੇ ਕੰਮ ਵਿੱਚ ਮੈਨੂੰ ਕਰਾਸਿੰਗ ਕਰਨੀ ਪੈਂਦੀ ਸੀ। ਅਤੇ ਮੈਂ ਇਹ ਦੇਖਣ ਲਈ ਹਰ ਵਾਰ ਸਿਸਕੋ ਸਵਿੱਚਾਂ 'ਤੇ ਜਾਣ ਤੋਂ ਥੱਕ ਗਿਆ ਕਿ ਕਿਹੜਾ ਇੰਟਰਫੇਸ ਵਰਤਣਾ ਹੈ। ਨਿਗਰਾਨੀ ਵਿੱਚ ਕਿਸੇ ਵਸਤੂ 'ਤੇ ਕਲਿੱਕ ਕਰਨਾ ਅਤੇ ਵਰਣਨ ਦੇ ਨਾਲ ਇਸਦੇ ਇੰਟਰਫੇਸਾਂ ਦੀ ਸੂਚੀ ਦੇਖਣਾ ਕਿੰਨਾ ਵਧੀਆ ਹੋਵੇਗਾ। ਇਹ ਮੇਰਾ ਸਮਾਂ ਬਚਾਏਗਾ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਸ ਸਕੀਮ ਵਿੱਚ ਖਾਤਿਆਂ ਅਤੇ ਕਮਾਂਡਾਂ ਨੂੰ ਦਾਖਲ ਕਰਨ ਲਈ ਪੁਟੀ ਜਾਂ ਸਕਿਓਰਸੀਆਰਟੀ ਚਲਾਉਣ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੋਵੇਗੀ। ਮੈਂ ਹੁਣੇ ਹੀ ਨਿਗਰਾਨੀ 'ਤੇ ਕਲਿੱਕ ਕੀਤਾ, ਦੇਖਿਆ ਕਿ ਕੀ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਆਪਣਾ ਕੰਮ ਕਰਨ ਲਈ ਚਲਾ ਗਿਆ. ਮੈਂ ਸਵਿੱਚਾਂ ਨਾਲ ਗੱਲਬਾਤ ਕਰਨ ਦੇ ਤਰੀਕੇ ਲੱਭਣੇ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੇ। ਮੈਨੂੰ ਤੁਰੰਤ 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 ਸਕੀਮ"। ਇਸ ਤਰ੍ਹਾਂ ਸਾਡੇ ਸਿਸਟਮ ਲਈ ਇੱਕ ਖਾਸ "ਪਲੱਗਇਨ" ਪ੍ਰਗਟ ਹੋਇਆ, ਜਿਸ ਵਿੱਚ ਸਿਰਫ਼ ਪੁਟੀ ਅਤੇ ਰਿਮੋਟ ਡੈਸਕਟਾਪ ਪਲੱਸ ਸ਼ਾਮਲ ਸਨ ਅਤੇ, ਇੰਸਟਾਲੇਸ਼ਨ ਦੌਰਾਨ, ਵਿੰਡੋਜ਼ ਵਿੱਚ ਯੂਆਰਆਈ ਸਕੀਮ ਨੂੰ ਸਿਰਫ਼ ਰਜਿਸਟਰ ਕੀਤਾ ਗਿਆ ਸੀ। ਹੁਣ, ਜਦੋਂ ਅਸੀਂ RDP ਜਾਂ SSH ਰਾਹੀਂ ਕਿਸੇ ਵਸਤੂ ਨਾਲ ਜੁੜਨਾ ਚਾਹੁੰਦੇ ਸੀ, ਅਸੀਂ ਆਪਣੇ ਸਿਸਟਮ 'ਤੇ ਇਸ ਐਕਸ਼ਨ ਨੂੰ ਕਲਿੱਕ ਕੀਤਾ ਅਤੇ ਕਸਟਮ URI ਨੇ ਕੰਮ ਕੀਤਾ। ਵਿੰਡੋਜ਼ ਜਾਂ ਪੁਟੀ ਵਿੱਚ ਬਣਾਇਆ ਗਿਆ ਮਿਆਰੀ mstsc.exe, ਜੋ ਕਿ “ਪਲੱਗਇਨ” ਦਾ ਹਿੱਸਾ ਸੀ, ਲਾਂਚ ਕੀਤਾ ਗਿਆ ਸੀ। ਮੈਂ ਸ਼ਬਦ ਪਲੱਗਇਨ ਨੂੰ ਕੋਟਸ ਵਿੱਚ ਪਾਉਂਦਾ ਹਾਂ ਕਿਉਂਕਿ ਇਹ ਕਲਾਸੀਕਲ ਅਰਥਾਂ ਵਿੱਚ ਇੱਕ ਬ੍ਰਾਊਜ਼ਰ ਪਲੱਗਇਨ ਨਹੀਂ ਹੈ।

ਘੱਟੋ ਘੱਟ ਇਹ ਕੁਝ ਸੀ. ਸੁਵਿਧਾਜਨਕ ਪਤਾ ਕਿਤਾਬ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਪੁਟੀ ਦੇ ਮਾਮਲੇ ਵਿਚ, ਸਭ ਕੁਝ ਆਮ ਤੌਰ 'ਤੇ ਠੀਕ ਸੀ; ਇਸ ਨੂੰ ਇਨਪੁਟ ਪੈਰਾਮੀਟਰਾਂ ਵਜੋਂ IP ਕਨੈਕਸ਼ਨ, ਲੌਗਇਨ ਅਤੇ ਪਾਸਵਰਡ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਉਹ. ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਪਾਸਵਰਡ ਦਾਖਲ ਕੀਤੇ ਬਿਨਾਂ ਇੱਕ ਕਲਿੱਕ ਨਾਲ ਸਾਡੇ ਨੈੱਟਵਰਕ 'ਤੇ ਲੀਨਕਸ ਸਰਵਰਾਂ ਨਾਲ ਜੁੜ ਚੁੱਕੇ ਹਾਂ। ਪਰ RDP ਨਾਲ ਇਹ ਇੰਨਾ ਸੌਖਾ ਨਹੀਂ ਹੈ। ਸਟੈਂਡਰਡ mstsc ਪੈਰਾਮੀਟਰਾਂ ਦੇ ਤੌਰ 'ਤੇ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਦੀ ਸਪਲਾਈ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ। ਰਿਮੋਟ ਡੈਸਕਟੌਪ ਪਲੱਸ ਬਚਾਅ ਲਈ ਆਇਆ. ਉਸਨੇ ਅਜਿਹਾ ਹੋਣ ਦਿੱਤਾ। ਹੁਣ ਅਸੀਂ ਇਸ ਤੋਂ ਬਿਨਾਂ ਕਰ ਸਕਦੇ ਹਾਂ, ਪਰ ਲੰਬੇ ਸਮੇਂ ਲਈ ਇਹ ਸਾਡੇ ਸਿਸਟਮ ਵਿੱਚ ਇੱਕ ਵਫ਼ਾਦਾਰ ਸਹਾਇਕ ਸੀ. HTTP(S) ਸਾਈਟਾਂ ਦੇ ਨਾਲ ਸਭ ਕੁਝ ਸਧਾਰਨ ਹੈ, ਅਜਿਹੀਆਂ ਵਸਤੂਆਂ ਨੂੰ ਸਿਰਫ਼ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਖੋਲ੍ਹਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਬੱਸ. ਸੁਵਿਧਾਜਨਕ ਅਤੇ ਵਿਹਾਰਕ. ਪਰ ਇਹ ਸਿਰਫ ਅੰਦਰੂਨੀ ਨੈੱਟਵਰਕ 'ਤੇ ਖੁਸ਼ੀ ਸੀ.

ਕਿਉਂਕਿ ਅਸੀਂ ਦਫਤਰ ਤੋਂ ਬਹੁਤ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਦੂਰ ਤੋਂ ਹੱਲ ਕੀਤਾ ਹੈ, ਸਭ ਤੋਂ ਆਸਾਨ ਗੱਲ ਇਹ ਸੀ ਕਿ ਗਾਹਕਾਂ ਨੂੰ VPN ਉਪਲਬਧ ਕਰਾਉਣਾ। ਅਤੇ ਫਿਰ ਸਾਡੇ ਸਿਸਟਮ ਤੋਂ ਉਹਨਾਂ ਨਾਲ ਜੁੜਨਾ ਸੰਭਵ ਸੀ. ਪਰ ਇਹ ਅਜੇ ਵੀ ਕੁਝ ਅਸੁਵਿਧਾਜਨਕ ਸੀ. ਹਰੇਕ ਕਲਾਇੰਟ ਲਈ, ਹਰੇਕ ਕੰਪਿਊਟਰ 'ਤੇ ਯਾਦ ਕੀਤੇ VPN ਕਨੈਕਸ਼ਨਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਰੱਖਣਾ ਜ਼ਰੂਰੀ ਸੀ, ਅਤੇ ਕਿਸੇ ਨਾਲ ਜੁੜਨ ਤੋਂ ਪਹਿਲਾਂ, ਸੰਬੰਧਿਤ VPN ਨੂੰ ਸਮਰੱਥ ਕਰਨਾ ਜ਼ਰੂਰੀ ਸੀ। ਅਸੀਂ ਇਸ ਹੱਲ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਲਈ ਵਰਤਿਆ ਹੈ. ਪਰ ਗਾਹਕਾਂ ਦੀ ਗਿਣਤੀ ਵਧ ਰਹੀ ਹੈ, VPN ਦੀ ਗਿਣਤੀ ਵੀ ਵੱਧ ਰਹੀ ਹੈ, ਅਤੇ ਇਹ ਸਭ ਕੁਝ ਤਣਾਅਪੂਰਨ ਹੋਣ ਲੱਗਾ ਅਤੇ ਇਸ ਬਾਰੇ ਕੁਝ ਕਰਨਾ ਪਿਆ। ਸਿਸਟਮ ਨੂੰ ਮੁੜ ਸਥਾਪਿਤ ਕਰਨ ਤੋਂ ਬਾਅਦ ਖਾਸ ਤੌਰ 'ਤੇ ਮੇਰੀਆਂ ਅੱਖਾਂ ਵਿੱਚ ਹੰਝੂ ਆ ਗਏ, ਜਦੋਂ ਮੈਨੂੰ ਇੱਕ ਨਵੇਂ ਵਿੰਡੋਜ਼ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਦਰਜਨਾਂ VPN ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਦਾਖਲ ਕਰਨਾ ਪਿਆ। ਇਸ ਨੂੰ ਸਹਿਣਾ ਬੰਦ ਕਰੋ, ਮੈਂ ਕਿਹਾ, ਅਤੇ ਇਸ ਬਾਰੇ ਸੋਚਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ ਕਿ ਮੈਂ ਇਸ ਬਾਰੇ ਕੀ ਕਰ ਸਕਦਾ ਹਾਂ।

ਅਜਿਹਾ ਹੋਇਆ ਕਿ ਸਾਰੇ ਗਾਹਕਾਂ ਕੋਲ ਰਾਊਟਰਾਂ ਵਜੋਂ ਜਾਣੀ-ਪਛਾਣੀ ਕੰਪਨੀ ਮਿਕਰੋਟਿਕ ਦੀਆਂ ਡਿਵਾਈਸਾਂ ਸਨ. ਉਹ ਲਗਭਗ ਕਿਸੇ ਵੀ ਕੰਮ ਨੂੰ ਕਰਨ ਲਈ ਬਹੁਤ ਕਾਰਜਸ਼ੀਲ ਅਤੇ ਸੁਵਿਧਾਜਨਕ ਹਨ. ਨਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਉਹ "ਹਾਈਜੈਕ" ਹਨ। ਅਸੀਂ ਬਾਹਰੋਂ ਸਾਰੀਆਂ ਪਹੁੰਚਾਂ ਨੂੰ ਬੰਦ ਕਰਕੇ ਇਸ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕੀਤਾ ਹੈ। ਪਰ ਗਾਹਕ ਦੇ ਸਥਾਨ 'ਤੇ ਆਉਣ ਤੋਂ ਬਿਨਾਂ ਕਿਸੇ ਤਰ੍ਹਾਂ ਉਨ੍ਹਾਂ ਤੱਕ ਪਹੁੰਚ ਕਰਨਾ ਜ਼ਰੂਰੀ ਸੀ, ਕਿਉਂਕਿ ... ਇਹ ਲੰਬਾ ਹੈ। ਅਸੀਂ ਅਜਿਹੇ ਹਰੇਕ ਮਿਕਰੋਟਿਕ ਲਈ ਸਿਰਫ਼ ਸੁਰੰਗਾਂ ਬਣਾਈਆਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਪੂਲ ਵਿੱਚ ਵੱਖ ਕੀਤਾ। ਬਿਨਾਂ ਕਿਸੇ ਰੂਟਿੰਗ ਦੇ, ਤਾਂ ਜੋ ਤੁਹਾਡੇ ਨੈਟਵਰਕ ਦਾ ਗਾਹਕਾਂ ਦੇ ਨੈਟਵਰਕ ਅਤੇ ਉਹਨਾਂ ਦੇ ਇੱਕ ਦੂਜੇ ਨਾਲ ਨੈਟਵਰਕ ਨਾਲ ਕੋਈ ਕਨੈਕਸ਼ਨ ਨਾ ਹੋਵੇ।

ਇਹ ਵਿਚਾਰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਪੈਦਾ ਹੋਇਆ ਸੀ ਕਿ ਜਦੋਂ ਮੈਂ ਸਿਸਟਮ ਵਿੱਚ ਲੋੜੀਂਦੇ ਆਬਜੈਕਟ 'ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹਾਂ, ਤਾਂ ਕੇਂਦਰੀ ਨਿਗਰਾਨੀ ਸਰਵਰ, ਸਾਰੇ ਕਲਾਇੰਟ ਮਿਕਰੋਟਿਕ ਦੇ SSH ਖਾਤਿਆਂ ਨੂੰ ਜਾਣਦਾ ਹੋਇਆ, ਲੋੜੀਂਦੇ ਇੱਕ ਨਾਲ ਜੁੜਦਾ ਹੈ, ਲੋੜੀਂਦੇ ਹੋਸਟ ਲਈ ਇੱਕ ਫਾਰਵਰਡਿੰਗ ਨਿਯਮ ਬਣਾਉਂਦਾ ਹੈ. ਲੋੜੀਂਦਾ ਪੋਰਟ। ਇੱਥੇ ਕਈ ਨੁਕਤੇ ਹਨ. ਹੱਲ ਸਰਵ ਵਿਆਪਕ ਨਹੀਂ ਹੈ - ਇਹ ਸਿਰਫ ਮਿਕਰੋਟਿਕ ਲਈ ਕੰਮ ਕਰੇਗਾ, ਕਿਉਂਕਿ ਕਮਾਂਡ ਸੰਟੈਕਸ ਸਾਰੇ ਰਾਊਟਰਾਂ ਲਈ ਵੱਖਰਾ ਹੈ। ਨਾਲ ਹੀ, ਅਜਿਹੇ ਫਾਰਵਰਡਿੰਗਾਂ ਨੂੰ ਫਿਰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਮਿਟਾਉਣਾ ਪੈਂਦਾ ਸੀ, ਅਤੇ ਸਾਡੇ ਸਿਸਟਮ ਦਾ ਸਰਵਰ ਹਿੱਸਾ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਟਰੈਕ ਨਹੀਂ ਕਰ ਸਕਦਾ ਸੀ ਕਿ ਮੈਂ ਆਪਣਾ RDP ਸੈਸ਼ਨ ਪੂਰਾ ਕਰ ਲਿਆ ਸੀ ਜਾਂ ਨਹੀਂ। ਖੈਰ, ਅਜਿਹੇ ਫਾਰਵਰਡਿੰਗ ਗਾਹਕ ਲਈ ਇੱਕ ਮੋਰੀ ਹੈ. ਪਰ ਅਸੀਂ ਸਰਵ ਵਿਆਪਕਤਾ ਦਾ ਪਿੱਛਾ ਨਹੀਂ ਕੀਤਾ, ਕਿਉਂਕਿ... ਉਤਪਾਦ ਦੀ ਵਰਤੋਂ ਸਿਰਫ਼ ਸਾਡੀ ਕੰਪਨੀ ਦੇ ਅੰਦਰ ਕੀਤੀ ਗਈ ਸੀ ਅਤੇ ਇਸ ਨੂੰ ਜਨਤਾ ਲਈ ਜਾਰੀ ਕਰਨ ਦਾ ਕੋਈ ਵਿਚਾਰ ਨਹੀਂ ਸੀ।

ਹਰ ਸਮੱਸਿਆ ਨੂੰ ਆਪਣੇ ਤਰੀਕੇ ਨਾਲ ਹੱਲ ਕੀਤਾ ਗਿਆ ਸੀ. ਜਦੋਂ ਨਿਯਮ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਤਾਂ ਇਹ ਫਾਰਵਰਡਿੰਗ ਸਿਰਫ਼ ਇੱਕ ਖਾਸ ਬਾਹਰੀ IP ਪਤੇ ਲਈ ਉਪਲਬਧ ਸੀ (ਜਿਸ ਤੋਂ ਕੁਨੈਕਸ਼ਨ ਸ਼ੁਰੂ ਕੀਤਾ ਗਿਆ ਸੀ)। ਇਸ ਲਈ ਇੱਕ ਸੁਰੱਖਿਆ ਮੋਰੀ ਬਚ ਗਿਆ ਸੀ. ਪਰ ਅਜਿਹੇ ਹਰੇਕ ਕੁਨੈਕਸ਼ਨ ਦੇ ਨਾਲ, ਇੱਕ ਮਾਈਕਰੋਟਿਕ ਨਿਯਮ ਨੂੰ NAT ਪੰਨੇ ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ ਸੀ ਅਤੇ ਸਾਫ਼ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ। ਅਤੇ ਹਰ ਕੋਈ ਜਾਣਦਾ ਹੈ ਕਿ ਜਿੰਨੇ ਜ਼ਿਆਦਾ ਨਿਯਮ ਹਨ, ਓਨਾ ਹੀ ਜ਼ਿਆਦਾ ਰਾਊਟਰ ਦਾ ਪ੍ਰੋਸੈਸਰ ਲੋਡ ਹੁੰਦਾ ਹੈ। ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ, ਮੈਂ ਇਹ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰ ਸਕਦਾ ਸੀ ਕਿ ਇਕ ਦਿਨ ਮੈਂ ਕੁਝ ਮਿਕਰੋਟਿਕ ਵਿਚ ਜਾਵਾਂਗਾ, ਅਤੇ ਸੈਂਕੜੇ ਮਰੇ ਹੋਏ, ਬੇਕਾਰ ਨਿਯਮ ਹੋਣਗੇ.

ਕਿਉਂਕਿ ਸਾਡਾ ਸਰਵਰ ਕਨੈਕਸ਼ਨ ਸਥਿਤੀ ਨੂੰ ਟਰੈਕ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ, ਮਿਕਰੋਟਿਕ ਨੂੰ ਉਹਨਾਂ ਨੂੰ ਖੁਦ ਟ੍ਰੈਕ ਕਰਨ ਦਿਓ। ਅਤੇ ਮੈਂ ਇੱਕ ਸਕ੍ਰਿਪਟ ਲਿਖੀ ਹੈ ਜੋ ਇੱਕ ਖਾਸ ਵਰਣਨ ਦੇ ਨਾਲ ਸਾਰੇ ਫਾਰਵਰਡਿੰਗ ਨਿਯਮਾਂ ਦੀ ਨਿਰੰਤਰ ਨਿਗਰਾਨੀ ਕਰਦੀ ਹੈ ਅਤੇ ਜਾਂਚ ਕਰਦੀ ਹੈ ਕਿ ਕੀ 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 ਖੋਲ੍ਹੇ ਜਾਂ ਪਾਸਵਰਡ ਦਾਖਲ ਕੀਤੇ ਬਿਨਾਂ। ਸਿਸਟਮ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਅਸਲ ਵਿੱਚ ਸੁਵਿਧਾਜਨਕ ਬਣ ਗਿਆ ਹੈ. ਸੇਵਾ ਦਾ ਸਮਾਂ ਘਟਾਇਆ ਗਿਆ ਸੀ, ਅਤੇ ਅਸੀਂ ਸਭ ਨੇ ਜ਼ਰੂਰੀ ਵਸਤੂਆਂ ਨਾਲ ਜੁੜਨ ਦੀ ਬਜਾਏ ਕੰਮ ਕਰਨ ਵਿੱਚ ਸਮਾਂ ਬਿਤਾਇਆ।

ਮਾਈਕਰੋਟਿਕ ਬੈਕਅੱਪ

ਅਸੀਂ ਸਾਰੇ ਮਿਕਰੋਟਿਕ ਦੇ ਬੈਕਅੱਪ ਨੂੰ FTP ਵਿੱਚ ਕੌਂਫਿਗਰ ਕੀਤਾ ਹੈ। ਅਤੇ ਕੁੱਲ ਮਿਲਾ ਕੇ ਸਭ ਕੁਝ ਠੀਕ ਸੀ. ਪਰ ਜਦੋਂ ਤੁਹਾਨੂੰ ਬੈਕਅੱਪ ਲੈਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਸੀ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਸ FTP ਨੂੰ ਖੋਲ੍ਹਣਾ ਪੈਂਦਾ ਸੀ ਅਤੇ ਇਸ ਨੂੰ ਉੱਥੇ ਲੱਭਣਾ ਪੈਂਦਾ ਸੀ। ਸਾਡੇ ਕੋਲ ਇੱਕ ਸਿਸਟਮ ਹੈ ਜਿੱਥੇ ਸਾਰੇ ਰਾਊਟਰ ਜੁੜੇ ਹੋਏ ਹਨ; ਅਸੀਂ SSH ਰਾਹੀਂ ਡਿਵਾਈਸਾਂ ਨਾਲ ਸੰਚਾਰ ਕਰ ਸਕਦੇ ਹਾਂ। ਅਸੀਂ ਇਸਨੂੰ ਕਿਉਂ ਨਹੀਂ ਬਣਾਉਂਦੇ ਤਾਂ ਕਿ ਸਿਸਟਮ ਆਪਣੇ ਆਪ ਹੀ ਰੋਜ਼ਾਨਾ ਸਾਰੇ ਮਿਕਰੋਟਿਕ ਤੋਂ ਬੈਕਅੱਪ ਲੈਂਦਾ ਹੈ, ਮੈਂ ਸੋਚਿਆ. ਅਤੇ ਉਸਨੇ ਇਸਨੂੰ ਲਾਗੂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ. ਅਸੀਂ ਕਨੈਕਟ ਕੀਤਾ, ਇੱਕ ਬੈਕਅੱਪ ਬਣਾਇਆ ਅਤੇ ਇਸਨੂੰ ਸਟੋਰੇਜ ਵਿੱਚ ਲੈ ਗਏ।

ਮਿਕਰੋਟਿਕ ਤੋਂ ਬੈਕਅੱਪ ਲੈਣ ਲਈ PHP ਵਿੱਚ ਸਕ੍ਰਿਪਟ ਕੋਡ:

<?php

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

    $connection = ssh2_connect($IP, 22);

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

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

    $sftp = ssh2_sftp($connection);

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

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

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

?>

ਬੈਕਅੱਪ ਦੋ ਰੂਪਾਂ ਵਿੱਚ ਲਿਆ ਜਾਂਦਾ ਹੈ - ਬਾਈਨਰੀ ਅਤੇ ਟੈਕਸਟ ਸੰਰਚਨਾ। ਬਾਈਨਰੀ ਲੋੜੀਂਦੀ ਸੰਰਚਨਾ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਬਹਾਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ, ਅਤੇ ਇੱਕ ਟੈਕਸਟ ਤੁਹਾਨੂੰ ਇਹ ਸਮਝਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਕਿ ਜੇਕਰ ਸਾਜ਼ੋ-ਸਾਮਾਨ ਦੀ ਜ਼ਬਰਦਸਤੀ ਬਦਲੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਬਾਈਨਰੀ ਨੂੰ ਇਸ 'ਤੇ ਅੱਪਲੋਡ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਤਾਂ ਕੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਸਾਨੂੰ ਸਿਸਟਮ ਵਿੱਚ ਇੱਕ ਹੋਰ ਸੁਵਿਧਾਜਨਕ ਕਾਰਜਸ਼ੀਲਤਾ ਮਿਲੀ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਨਵਾਂ ਮਾਈਕਰੋਟਿਕ ਜੋੜਦੇ ਸਮੇਂ, ਕੁਝ ਵੀ ਕੌਂਫਿਗਰ ਕਰਨ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਸੀ; ਮੈਂ ਬਸ ਸਿਸਟਮ ਵਿੱਚ ਆਬਜੈਕਟ ਜੋੜਿਆ ਅਤੇ SSH ਦੁਆਰਾ ਇਸਦੇ ਲਈ ਇੱਕ ਖਾਤਾ ਸੈਟ ਕੀਤਾ. ਫਿਰ ਸਿਸਟਮ ਨੇ ਖੁਦ ਬੈਕਅਪ ਲੈਣ ਦਾ ਧਿਆਨ ਰੱਖਿਆ। SaaS Veliam ਦੇ ਮੌਜੂਦਾ ਸੰਸਕਰਣ ਵਿੱਚ ਅਜੇ ਇਹ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨਹੀਂ ਹੈ, ਪਰ ਅਸੀਂ ਇਸਨੂੰ ਜਲਦੀ ਹੀ ਪੋਰਟ ਕਰਾਂਗੇ।

ਅੰਦਰੂਨੀ ਸਿਸਟਮ ਵਿੱਚ ਇਹ ਕਿਹੋ ਜਿਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਸੀ ਦੇ ਸਕ੍ਰੀਨਸ਼ੌਟਸ

ਸਧਾਰਨ ਡਾਟਾਬੇਸ ਸਟੋਰੇਜ਼ ਵਿੱਚ ਤਬਦੀਲੀ

ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਉੱਪਰ ਲਿਖਿਆ ਹੈ ਕਿ ਕਲਾਤਮਕ ਚੀਜ਼ਾਂ ਪ੍ਰਗਟ ਹੋਈਆਂ. ਕਈ ਵਾਰ ਸਿਸਟਮ ਵਿੱਚ ਵਸਤੂਆਂ ਦੀ ਪੂਰੀ ਸੂਚੀ ਗਾਇਬ ਹੋ ਜਾਂਦੀ ਹੈ, ਕਈ ਵਾਰ ਕਿਸੇ ਵਸਤੂ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਨ ਵੇਲੇ, ਜਾਣਕਾਰੀ ਨੂੰ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਸੀ ਅਤੇ ਵਸਤੂ ਦਾ ਤਿੰਨ ਵਾਰ ਨਾਮ ਬਦਲਣਾ ਪੈਂਦਾ ਸੀ। ਇਸ ਨੇ ਸਾਰਿਆਂ ਨੂੰ ਬੁਰੀ ਤਰ੍ਹਾਂ ਪਰੇਸ਼ਾਨ ਕੀਤਾ। ਵਸਤੂਆਂ ਦਾ ਗਾਇਬ ਹੋਣਾ ਬਹੁਤ ਘੱਟ ਵਾਪਰਦਾ ਹੈ, ਅਤੇ ਇਸ ਫਾਈਲ ਨੂੰ ਬਹਾਲ ਕਰਕੇ ਆਸਾਨੀ ਨਾਲ ਬਹਾਲ ਕੀਤਾ ਗਿਆ ਸੀ, ਪਰ ਵਸਤੂਆਂ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਨ ਵੇਲੇ ਅਸਫਲਤਾਵਾਂ ਅਕਸਰ ਵਾਪਰਦੀਆਂ ਹਨ। ਸੰਭਵ ਤੌਰ 'ਤੇ, ਮੈਂ ਸ਼ੁਰੂ ਵਿੱਚ ਇਹ ਡੇਟਾਬੇਸ ਦੁਆਰਾ ਨਹੀਂ ਕੀਤਾ ਕਿਉਂਕਿ ਇਹ ਮੇਰੇ ਦਿਮਾਗ ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਬੈਠਦਾ ਸੀ ਕਿ ਇੱਕ ਫਲੈਟ ਟੇਬਲ ਵਿੱਚ ਸਾਰੇ ਕਨੈਕਸ਼ਨਾਂ ਦੇ ਨਾਲ ਇੱਕ ਰੁੱਖ ਨੂੰ ਕਿਵੇਂ ਰੱਖਣਾ ਸੰਭਵ ਸੀ. ਇਹ ਸਮਤਲ ਹੈ, ਪਰ ਰੁੱਖ ਲੜੀਵਾਰ ਹੈ। ਪਰ ਮਲਟੀਪਲ ਐਕਸੈਸ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ (ਜਿਵੇਂ ਕਿ ਸਿਸਟਮ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਹੋ ਜਾਂਦਾ ਹੈ) ਲੈਣ-ਦੇਣ ਲਈ ਇੱਕ ਚੰਗਾ ਹੱਲ, ਇੱਕ DBMS ਹੈ। ਮੈਂ ਸ਼ਾਇਦ ਇਸ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਨ ਵਾਲਾ ਪਹਿਲਾ ਵਿਅਕਤੀ ਨਹੀਂ ਹਾਂ। ਮੈਂ ਗੂਗਲ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਮੇਰੇ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਹਰ ਚੀਜ਼ ਦੀ ਖੋਜ ਕੀਤੀ ਗਈ ਸੀ ਅਤੇ ਕਈ ਐਲਗੋਰਿਦਮ ਹਨ ਜੋ ਇੱਕ ਫਲੈਟ ਟੇਬਲ ਤੋਂ ਇੱਕ ਰੁੱਖ ਬਣਾਉਂਦੇ ਹਨ. ਹਰ ਇੱਕ ਨੂੰ ਦੇਖਣ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਲਾਗੂ ਕੀਤਾ. ਪਰ ਇਹ ਪਹਿਲਾਂ ਹੀ ਸਿਸਟਮ ਦਾ ਨਵਾਂ ਸੰਸਕਰਣ ਸੀ, ਕਿਉਂਕਿ ... ਅਸਲ ਵਿੱਚ, ਇਸ ਕਾਰਨ, ਮੈਨੂੰ ਬਹੁਤ ਕੁਝ ਦੁਬਾਰਾ ਲਿਖਣਾ ਪਿਆ. ਨਤੀਜਾ ਕੁਦਰਤੀ ਸੀ, ਸਿਸਟਮ ਦੇ ਬੇਤਰਤੀਬ ਵਿਹਾਰ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦੂਰ ਹੋ ਗਈਆਂ. ਕੁਝ ਲੋਕ ਕਹਿ ਸਕਦੇ ਹਨ ਕਿ ਸੌਫਟਵੇਅਰ ਵਿਕਾਸ ਦੇ ਖੇਤਰ ਵਿੱਚ ਗਲਤੀਆਂ ਬਹੁਤ ਸ਼ੁਕੀਨ ਹਨ (ਸਿੰਗਲ-ਥ੍ਰੈਡਡ ਸਕ੍ਰਿਪਟਾਂ, ਜਾਣਕਾਰੀ ਨੂੰ ਸਟੋਰ ਕਰਨਾ ਜੋ ਕਿ ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਥ੍ਰੈਡਾਂ ਤੋਂ ਇੱਕੋ ਸਮੇਂ ਕਈ ਵਾਰ ਐਕਸੈਸ ਕੀਤੀ ਗਈ ਸੀ, ਆਦਿ)। ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਸੱਚ ਹੋਵੇ, ਪਰ ਮੇਰਾ ਮੁੱਖ ਕੰਮ ਪ੍ਰਸ਼ਾਸਨ ਸੀ, ਅਤੇ ਪ੍ਰੋਗਰਾਮਿੰਗ ਮੇਰੀ ਰੂਹ ਲਈ ਇੱਕ ਪਾਸੇ ਦੀ ਭੀੜ ਸੀ, ਅਤੇ ਮੇਰੇ ਕੋਲ ਪ੍ਰੋਗਰਾਮਰਾਂ ਦੀ ਇੱਕ ਟੀਮ ਵਿੱਚ ਕੰਮ ਕਰਨ ਦਾ ਤਜਰਬਾ ਨਹੀਂ ਸੀ, ਜਿੱਥੇ ਅਜਿਹੀਆਂ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਮੇਰੇ ਸੀਨੀਅਰ ਦੁਆਰਾ ਮੈਨੂੰ ਤੁਰੰਤ ਸੁਝਾਅ ਦਿੱਤੀਆਂ ਜਾਂਦੀਆਂ ਸਨ। ਕਾਮਰੇਡ ਇਸ ਲਈ, ਮੈਂ ਇਹ ਸਾਰੇ ਬੰਪਰ ਆਪਣੇ ਆਪ ਭਰੇ, ਪਰ ਮੈਂ ਸਮੱਗਰੀ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਿੱਖ ਲਿਆ. ਅਤੇ ਇਹ ਵੀ, ਮੇਰੀ ਨੌਕਰੀ ਵਿੱਚ ਗਾਹਕਾਂ ਨਾਲ ਮੀਟਿੰਗਾਂ, ਕੰਪਨੀ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੇ ਉਦੇਸ਼ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ, ਕੰਪਨੀ ਦੇ ਅੰਦਰ ਪ੍ਰਬੰਧਕੀ ਮੁੱਦਿਆਂ ਦਾ ਇੱਕ ਸਮੂਹ, ਅਤੇ ਹੋਰ ਬਹੁਤ ਕੁਝ ਸ਼ਾਮਲ ਹੈ। ਪਰ ਇੱਕ ਜਾਂ ਦੂਜੇ ਤਰੀਕੇ ਨਾਲ, ਜੋ ਪਹਿਲਾਂ ਹੀ ਮੰਗ ਵਿੱਚ ਸੀ. ਮੈਂ ਅਤੇ ਮੁੰਡਿਆਂ ਨੇ ਆਪਣੇ ਰੋਜ਼ਾਨਾ ਦੇ ਕੰਮ ਵਿੱਚ ਉਤਪਾਦ ਦੀ ਵਰਤੋਂ ਕੀਤੀ. ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਅਸਫਲ ਵਿਚਾਰ ਅਤੇ ਹੱਲ ਸਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਸਮਾਂ ਬਰਬਾਦ ਕੀਤਾ ਗਿਆ ਸੀ, ਪਰ ਅੰਤ ਵਿੱਚ ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਇਹ ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲਾ ਸੰਦ ਨਹੀਂ ਸੀ ਅਤੇ ਕਿਸੇ ਨੇ ਇਸਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਅਤੇ ਇਹ ਵੇਲੀਅਮ ਵਿੱਚ ਖਤਮ ਨਹੀਂ ਹੋਇਆ.

ਹੈਲਪਡੈਸਕ - ਹੈਲਪਡੈਸਕ

ਇਹ ਦੱਸਣਾ ਗਲਤ ਨਹੀਂ ਹੋਵੇਗਾ ਕਿ ਹੈਲਪਡੈਸਕ ਕਿਵੇਂ ਬਣਾਈ ਗਈ ਸੀ। ਇਹ ਇੱਕ ਬਿਲਕੁਲ ਵੱਖਰੀ ਕਹਾਣੀ ਹੈ, ਕਿਉਂਕਿ ... ਵੇਲੀਅਮ ਵਿੱਚ ਇਹ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਤੀਜਾ ਬਿਲਕੁਲ ਨਵਾਂ ਸੰਸਕਰਣ ਹੈ, ਜੋ ਪਿਛਲੇ ਸਾਰੇ ਸੰਸਕਰਣਾਂ ਤੋਂ ਵੱਖਰਾ ਹੈ। ਹੁਣ ਇਹ ਇੱਕ ਸਧਾਰਨ ਪ੍ਰਣਾਲੀ ਹੈ, ਬੇਲੋੜੀ ਘੰਟੀਆਂ ਅਤੇ ਸੀਟੀਆਂ ਤੋਂ ਬਿਨਾਂ, ਇੱਕ ਡੋਮੇਨ ਨਾਲ ਏਕੀਕ੍ਰਿਤ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਦੇ ਨਾਲ, ਨਾਲ ਹੀ ਇੱਕ ਈਮੇਲ ਤੋਂ ਲਿੰਕ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਿਤੇ ਵੀ ਉਸੇ ਉਪਭੋਗਤਾ ਪ੍ਰੋਫਾਈਲ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਦੇ ਨਾਲ. ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਬਿਨਾਂ VPN ਜਾਂ ਪੋਰਟ ਫਾਰਵਰਡਿੰਗ ਦੇ ਬਿਨੈਕਾਰ ਨਾਲ ਕਿਤੇ ਵੀ (ਘਰ ਜਾਂ ਦਫਤਰ ਵਿੱਚ) VNC ਰਾਹੀਂ ਬਿਨੈਕਾਰ ਨਾਲ ਜੁੜਨਾ ਸੰਭਵ ਹੈ। ਮੈਂ ਤੁਹਾਨੂੰ ਦੱਸਾਂਗਾ ਕਿ ਅਸੀਂ ਇਸ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚੇ, ਪਹਿਲਾਂ ਕੀ ਹੋਇਆ ਅਤੇ ਕਿਹੜੇ ਭਿਆਨਕ ਫੈਸਲੇ ਲਏ ਗਏ।

ਅਸੀਂ ਜਾਣੇ-ਪਛਾਣੇ TeamViewer ਦੁਆਰਾ ਉਪਭੋਗਤਾਵਾਂ ਨਾਲ ਜੁੜੇ ਹਾਂ। ਉਹ ਸਾਰੇ ਕੰਪਿਊਟਰ ਜਿਨ੍ਹਾਂ ਦੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਅਸੀਂ ਸੇਵਾ ਦਿੰਦੇ ਹਾਂ, ਟੀਵੀ ਸਥਾਪਿਤ ਕੀਤਾ ਹੋਇਆ ਹੈ। ਪਹਿਲੀ ਚੀਜ਼ ਜੋ ਅਸੀਂ ਗਲਤ ਕੀਤੀ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਇਸਨੂੰ ਹਟਾ ਦਿੱਤਾ, ਹਰ HD ਕਲਾਇੰਟ ਨੂੰ ਹਾਰਡਵੇਅਰ ਨਾਲ ਲਿੰਕ ਕਰਨਾ ਸੀ। ਇੱਕ ਬੇਨਤੀ ਛੱਡਣ ਲਈ ਉਪਭੋਗਤਾ ਨੇ HD ਸਿਸਟਮ ਵਿੱਚ ਕਿਵੇਂ ਲੌਗਇਨ ਕੀਤਾ? ਟੀਵੀ ਤੋਂ ਇਲਾਵਾ, ਹਰ ਕਿਸੇ ਨੇ ਆਪਣੇ ਕੰਪਿਊਟਰਾਂ 'ਤੇ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਉਪਯੋਗਤਾ ਸਥਾਪਿਤ ਕੀਤੀ ਸੀ, ਜੋ ਲਾਜ਼ਰ ਵਿੱਚ ਲਿਖੀ ਗਈ ਸੀ (ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਆਪਣੀਆਂ ਅੱਖਾਂ ਨੂੰ ਰੋਲ ਕਰਨਗੇ, ਅਤੇ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਗੂਗਲ ਵੀ ਜਾਣ ਕਿ ਇਹ ਕੀ ਹੈ, ਪਰ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਪਾਇਲ ਕੀਤੀ ਭਾਸ਼ਾ ਜੋ ਮੈਂ ਜਾਣਦਾ ਸੀ ਉਹ ਡੇਲਫੀ ਸੀ, ਅਤੇ ਲਾਜ਼ਰ ਲਗਭਗ ਉਹੀ ਚੀਜ਼, ਸਿਰਫ਼ ਮੁਫ਼ਤ). ਆਮ ਤੌਰ 'ਤੇ, ਉਪਭੋਗਤਾ ਨੇ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਬੈਚ ਫਾਈਲ ਲਾਂਚ ਕੀਤੀ ਜਿਸ ਨੇ ਇਸ ਉਪਯੋਗਤਾ ਨੂੰ ਲਾਂਚ ਕੀਤਾ, ਜੋ ਬਦਲੇ ਵਿੱਚ ਸਿਸਟਮ ਦੇ HWID ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਇਸ ਤੋਂ ਬਾਅਦ ਬ੍ਰਾਉਜ਼ਰ ਨੂੰ ਲਾਂਚ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਅਧਿਕਾਰ ਪ੍ਰਾਪਤ ਹੋਇਆ ਸੀ। ਅਜਿਹਾ ਕਿਉਂ ਕੀਤਾ ਗਿਆ? ਕੁਝ ਕੰਪਨੀਆਂ ਵਿੱਚ, ਸੇਵਾ ਕੀਤੇ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਗਿਣਤੀ ਵਿਅਕਤੀਗਤ ਤੌਰ 'ਤੇ ਗਿਣੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਹਰੇਕ ਮਹੀਨੇ ਲਈ ਸੇਵਾ ਦੀ ਕੀਮਤ ਲੋਕਾਂ ਦੀ ਗਿਣਤੀ 'ਤੇ ਅਧਾਰਤ ਹੁੰਦੀ ਹੈ। ਇਹ ਸਮਝਣ ਯੋਗ ਹੈ, ਤੁਸੀਂ ਕਹਿੰਦੇ ਹੋ, ਪਰ ਇਹ ਹਾਰਡਵੇਅਰ ਨਾਲ ਕਿਉਂ ਜੁੜਿਆ ਹੋਇਆ ਹੈ? ਇਹ ਬਹੁਤ ਸਧਾਰਨ ਹੈ, ਕੁਝ ਵਿਅਕਤੀ ਘਰ ਆਏ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਘਰ ਦੇ ਲੈਪਟਾਪ ਤੋਂ "ਮੇਰੇ ਲਈ ਇੱਥੇ ਸਭ ਕੁਝ ਸੁੰਦਰ ਬਣਾਓ" ਦੀ ਸ਼ੈਲੀ ਵਿੱਚ ਬੇਨਤੀ ਕੀਤੀ। ਸਿਸਟਮ HWID ਨੂੰ ਪੜ੍ਹਨ ਤੋਂ ਇਲਾਵਾ, ਉਪਯੋਗਤਾ ਨੇ ਰਜਿਸਟਰੀ ਤੋਂ ਮੌਜੂਦਾ Teamviewer ID ਨੂੰ ਖਿੱਚਿਆ ਅਤੇ ਇਸਨੂੰ ਸਾਡੇ ਕੋਲ ਪ੍ਰਸਾਰਿਤ ਵੀ ਕੀਤਾ। ਟੀਮਵਿਊਅਰ ਕੋਲ ਏਕੀਕਰਣ ਲਈ API ਹੈ। ਅਤੇ ਅਸੀਂ ਇਹ ਏਕੀਕਰਣ ਕੀਤਾ. ਪਰ ਇੱਕ ਕੈਚ ਸੀ. ਇਹਨਾਂ APIs ਦੁਆਰਾ, ਉਪਭੋਗਤਾ ਦੇ ਕੰਪਿਊਟਰ ਨਾਲ ਕਨੈਕਟ ਕਰਨਾ ਅਸੰਭਵ ਹੈ ਜਦੋਂ ਉਹ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਇਸ ਸੈਸ਼ਨ ਨੂੰ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸ ਨਾਲ ਜੁੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਉਸਨੂੰ "ਪੁਸ਼ਟੀ ਕਰੋ" ਨੂੰ ਵੀ ਕਲਿੱਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਉਸ ਸਮੇਂ, ਇਹ ਸਾਡੇ ਲਈ ਤਰਕਪੂਰਨ ਜਾਪਦਾ ਸੀ ਕਿ ਕਿਸੇ ਨੂੰ ਵੀ ਉਪਭੋਗਤਾ ਦੀ ਬੇਨਤੀ ਤੋਂ ਬਿਨਾਂ ਕਨੈਕਟ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕਿਉਂਕਿ ਵਿਅਕਤੀ ਕੰਪਿਊਟਰ 'ਤੇ ਹੈ, ਉਹ ਸੈਸ਼ਨ ਦੀ ਸ਼ੁਰੂਆਤ ਕਰੇਗਾ ਅਤੇ ਰਿਮੋਟ ਕਨੈਕਸ਼ਨ ਦੀ ਬੇਨਤੀ ਦਾ ਹਾਂ-ਪੱਖੀ ਜਵਾਬ ਦੇਵੇਗਾ। ਸਭ ਕੁਝ ਗਲਤ ਨਿਕਲਿਆ। ਬਿਨੈਕਾਰ ਸੈਸ਼ਨ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਪ੍ਰੈਸ ਕਰਨਾ ਭੁੱਲ ਗਏ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਟੈਲੀਫੋਨ 'ਤੇ ਗੱਲਬਾਤ ਵਿੱਚ ਇਹ ਦੱਸਣਾ ਪਿਆ। ਇਸ ਨਾਲ ਸਮਾਂ ਬਰਬਾਦ ਹੋਇਆ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਦੇ ਦੋਵੇਂ ਪਾਸੇ ਨਿਰਾਸ਼ਾਜਨਕ ਸੀ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਜਿਹੇ ਪਲਾਂ ਲਈ ਇਹ ਬਿਲਕੁਲ ਅਸਧਾਰਨ ਨਹੀਂ ਹੈ ਜਦੋਂ ਕੋਈ ਵਿਅਕਤੀ ਬੇਨਤੀ ਛੱਡਦਾ ਹੈ, ਪਰ ਉਦੋਂ ਹੀ ਸੰਪਰਕ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਉਹ ਦੁਪਹਿਰ ਦੇ ਖਾਣੇ ਲਈ ਜਾਂਦਾ ਹੈ. ਕਿਉਂਕਿ ਸਮੱਸਿਆ ਨਾਜ਼ੁਕ ਨਹੀਂ ਹੈ ਅਤੇ ਉਹ ਨਹੀਂ ਚਾਹੁੰਦਾ ਕਿ ਉਸ ਦੇ ਕੰਮ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿਚ ਵਿਘਨ ਪਵੇ। ਇਸ ਅਨੁਸਾਰ, ਉਹ ਕੁਨੈਕਸ਼ਨ ਦੀ ਆਗਿਆ ਦੇਣ ਲਈ ਕੋਈ ਬਟਨ ਨਹੀਂ ਦਬਾਏਗਾ। ਹੈਲਪਡੈਸਕ ਵਿੱਚ ਲੌਗਇਨ ਕਰਨ ਵੇਲੇ ਵਾਧੂ ਕਾਰਜਕੁਸ਼ਲਤਾ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ - ਟੀਮਵਿਵਰ ਦੀ ਆਈਡੀ ਨੂੰ ਪੜ੍ਹਨਾ। ਸਾਨੂੰ ਸਥਾਈ ਪਾਸਵਰਡ ਪਤਾ ਸੀ ਜੋ Teamviwer ਨੂੰ ਸਥਾਪਿਤ ਕਰਨ ਵੇਲੇ ਵਰਤਿਆ ਗਿਆ ਸੀ। ਵਧੇਰੇ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ, ਸਿਰਫ਼ ਸਿਸਟਮ ਹੀ ਇਸ ਨੂੰ ਜਾਣਦਾ ਸੀ, ਕਿਉਂਕਿ ਇਹ ਇੰਸਟਾਲਰ ਅਤੇ ਸਾਡੇ ਸਿਸਟਮ ਵਿੱਚ ਬਣਾਇਆ ਗਿਆ ਸੀ। ਇਸ ਅਨੁਸਾਰ, ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਇੱਕ ਕੁਨੈਕਸ਼ਨ ਬਟਨ ਸੀ ਜਿਸ 'ਤੇ ਕਲਿੱਕ ਕਰਨ ਲਈ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਲਈ ਇੰਤਜ਼ਾਰ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਸੀ, ਪਰ ਟੀਮਵਿਊਅਰ ਤੁਰੰਤ ਖੁੱਲ੍ਹਿਆ ਅਤੇ ਇੱਕ ਕੁਨੈਕਸ਼ਨ ਹੋ ਗਿਆ। ਨਤੀਜੇ ਵਜੋਂ, ਦੋ ਤਰ੍ਹਾਂ ਦੇ ਸੰਭਾਵੀ ਕੁਨੈਕਸ਼ਨ ਸਨ। ਅਧਿਕਾਰਤ Teamviewer API ਅਤੇ ਸਾਡੇ ਸਵੈ-ਬਣਾਇਆ ਇੱਕ ਦੁਆਰਾ। ਮੇਰੇ ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਹੈ ਕਿ, ਉਹਨਾਂ ਨੇ ਪਹਿਲੇ ਦੀ ਵਰਤੋਂ ਲਗਭਗ ਤੁਰੰਤ ਬੰਦ ਕਰ ਦਿੱਤੀ, ਹਾਲਾਂਕਿ ਇਸਦੀ ਵਰਤੋਂ ਸਿਰਫ ਵਿਸ਼ੇਸ਼ ਮਾਮਲਿਆਂ ਵਿੱਚ ਕਰਨ ਦੀ ਹਦਾਇਤ ਸੀ ਅਤੇ ਜਦੋਂ ਉਪਭੋਗਤਾ ਖੁਦ ਅੱਗੇ ਵਧਦਾ ਹੈ. ਫਿਰ ਵੀ, ਮੈਨੂੰ ਹੁਣ ਸੁਰੱਖਿਆ ਦਿਓ। ਪਰ ਪਤਾ ਲੱਗਾ ਕਿ ਬਿਨੈਕਾਰਾਂ ਨੂੰ ਇਸ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ। ਬਿਨਾਂ ਪੁਸ਼ਟੀਕਰਨ ਬਟਨ ਦੇ ਉਹਨਾਂ ਨਾਲ ਕਨੈਕਟ ਹੋਣ ਦੇ ਨਾਲ ਉਹ ਸਾਰੇ ਬਿਲਕੁਲ ਠੀਕ ਹਨ।

ਲੀਨਕਸ ਵਿੱਚ ਮਲਟੀਥ੍ਰੈਡਿੰਗ ਵਿੱਚ ਬਦਲਣਾ

ਪੋਰਟਾਂ ਦੀ ਇੱਕ ਪੂਰਵ-ਨਿਰਧਾਰਤ ਸੂਚੀ ਦੇ ਖੁੱਲਣ ਅਤੇ ਨੈਟਵਰਕ ਆਬਜੈਕਟ ਦੀ ਸਧਾਰਨ ਪਿੰਗਿੰਗ ਲਈ ਇੱਕ ਨੈਟਵਰਕ ਸਕੈਨਰ ਦੇ ਬੀਤਣ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਦਾ ਸਵਾਲ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਉੱਠਣਾ ਸ਼ੁਰੂ ਹੋ ਗਿਆ ਹੈ. ਇੱਥੇ, ਬੇਸ਼ਕ, ਮਨ ਵਿੱਚ ਆਉਣ ਵਾਲਾ ਪਹਿਲਾ ਹੱਲ ਮਲਟੀਥ੍ਰੈਡਿੰਗ ਹੈ. ਕਿਉਂਕਿ ਪਿੰਗ 'ਤੇ ਬਿਤਾਇਆ ਗਿਆ ਮੁੱਖ ਸਮਾਂ ਪੈਕੇਟ ਦੇ ਵਾਪਸ ਆਉਣ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਅਗਲਾ ਪਿੰਗ ਉਦੋਂ ਤੱਕ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋ ਸਕਦਾ ਜਦੋਂ ਤੱਕ ਕਿ ਪਿਛਲਾ ਪੈਕੇਟ ਵਾਪਸ ਨਹੀਂ ਆ ਜਾਂਦਾ, ਉਹਨਾਂ ਕੰਪਨੀਆਂ ਵਿੱਚ ਜਿਨ੍ਹਾਂ ਕੋਲ 20+ ਸਰਵਰ ਅਤੇ ਨੈਟਵਰਕ ਉਪਕਰਣ ਵੀ ਸਨ, ਇਹ ਪਹਿਲਾਂ ਹੀ ਬਹੁਤ ਹੌਲੀ ਕੰਮ ਕਰਦਾ ਹੈ। ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ ਇੱਕ ਪੈਕੇਜ ਅਲੋਪ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਸ ਬਾਰੇ ਸਿਸਟਮ ਪ੍ਰਬੰਧਕ ਨੂੰ ਤੁਰੰਤ ਸੂਚਿਤ ਨਾ ਕਰੋ. ਉਹ ਬਹੁਤ ਜਲਦੀ ਅਜਿਹੇ ਸਪੈਮ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਬੰਦ ਕਰ ਦੇਵੇਗਾ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਪਹੁੰਚਯੋਗਤਾ ਬਾਰੇ ਕੋਈ ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਹਰੇਕ ਵਸਤੂ ਨੂੰ ਇੱਕ ਤੋਂ ਵੱਧ ਵਾਰ ਪਿੰਗ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਬਹੁਤ ਜ਼ਿਆਦਾ ਵੇਰਵਿਆਂ ਵਿੱਚ ਜਾਣ ਤੋਂ ਬਿਨਾਂ, ਇਸਨੂੰ ਸਮਾਨਾਂਤਰ ਬਣਾਉਣਾ ਜ਼ਰੂਰੀ ਹੈ ਕਿਉਂਕਿ ਜੇਕਰ ਅਜਿਹਾ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ ਗਾਹਕ ਤੋਂ ਸਮੱਸਿਆ ਬਾਰੇ ਸਿੱਖੇਗਾ, ਨਾ ਕਿ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਤੋਂ।

PHP ਖੁਦ ਬਕਸੇ ਦੇ ਬਾਹਰ ਮਲਟੀਥ੍ਰੈਡਿੰਗ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਮਲਟੀਪ੍ਰੋਸੈਸਿੰਗ ਦੇ ਸਮਰੱਥ, ਤੁਸੀਂ ਫੋਰਕ ਕਰ ਸਕਦੇ ਹੋ। ਪਰ, ਅਸਲ ਵਿੱਚ, ਮੇਰੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਪੋਲਿੰਗ ਵਿਧੀ ਲਿਖੀ ਹੋਈ ਸੀ ਅਤੇ ਮੈਂ ਇਸਨੂੰ ਬਣਾਉਣਾ ਚਾਹੁੰਦਾ ਸੀ ਤਾਂ ਜੋ ਮੈਂ ਇੱਕ ਵਾਰ ਡੇਟਾਬੇਸ ਤੋਂ ਲੋੜੀਂਦੇ ਸਾਰੇ ਨੋਡਾਂ ਦੀ ਗਿਣਤੀ ਕਰਾਂ, ਸਭ ਕੁਝ ਇੱਕ ਵਾਰ ਵਿੱਚ ਪਿੰਗ ਕਰਾਂ, ਹਰੇਕ ਦੇ ਜਵਾਬ ਦੀ ਉਡੀਕ ਕਰਾਂ ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਤੁਰੰਤ ਲਿਖਾਂ। ਡਾਟਾ. ਇਹ ਪੜ੍ਹਨ ਦੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਬਚਾਉਂਦਾ ਹੈ। ਮਲਟੀਥ੍ਰੈਡਿੰਗ ਇਸ ਵਿਚਾਰ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਫਿੱਟ ਹੈ। PHP ਲਈ ਇੱਕ PThreads ਮੋਡੀਊਲ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਅਸਲੀ ਮਲਟੀਥ੍ਰੈਡਿੰਗ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਹਾਲਾਂਕਿ ਇਸਨੂੰ PHP 7.2 'ਤੇ ਸੈੱਟ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਟਿੰਕਰਿੰਗ ਦੀ ਲੋੜ ਹੈ, ਪਰ ਇਹ ਕੀਤਾ ਗਿਆ ਸੀ। ਪੋਰਟ ਸਕੈਨਿੰਗ ਅਤੇ ਪਿੰਗ ਹੁਣ ਤੇਜ਼ ਹਨ। ਅਤੇ ਇਸਦੀ ਬਜਾਏ, ਉਦਾਹਰਨ ਲਈ, 15 ਸਕਿੰਟ ਪ੍ਰਤੀ ਲੈਪ ਪਹਿਲਾਂ, ਇਸ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ 2 ਸਕਿੰਟ ਲੱਗਣੇ ਸ਼ੁਰੂ ਹੋ ਗਏ। ਇਹ ਇੱਕ ਚੰਗਾ ਨਤੀਜਾ ਸੀ.

ਨਵੀਆਂ ਕੰਪਨੀਆਂ ਦਾ ਤੁਰੰਤ ਆਡਿਟ

ਵੱਖ-ਵੱਖ ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਹਾਰਡਵੇਅਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਲਈ ਕਾਰਜਕੁਸ਼ਲਤਾ ਕਿਵੇਂ ਆਈ? ਇਹ ਸਧਾਰਨ ਹੈ. ਕਈ ਵਾਰ ਸਾਨੂੰ ਸਿਰਫ਼ ਮੌਜੂਦਾ IT ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਆਡਿਟ ਕਰਨ ਦਾ ਹੁਕਮ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਖੈਰ, ਨਵੇਂ ਕਲਾਇੰਟ ਦੇ ਆਡਿਟ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਲਈ ਇਹੀ ਚੀਜ਼ ਜ਼ਰੂਰੀ ਹੈ. ਸਾਨੂੰ ਕਿਸੇ ਅਜਿਹੀ ਚੀਜ਼ ਦੀ ਲੋੜ ਸੀ ਜੋ ਸਾਨੂੰ ਇੱਕ ਮੱਧਮ ਜਾਂ ਵੱਡੀ ਕੰਪਨੀ ਵਿੱਚ ਆਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇ ਅਤੇ ਜਲਦੀ ਪਤਾ ਲਗਾ ਸਕੇ ਕਿ ਉਹਨਾਂ ਕੋਲ ਕੀ ਹੈ। ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਅੰਦਰੂਨੀ ਨੈਟਵਰਕ ਤੇ ਪਿੰਗ ਸਿਰਫ ਉਹਨਾਂ ਦੁਆਰਾ ਬਲੌਕ ਕੀਤਾ ਗਿਆ ਹੈ ਜੋ ਆਪਣੀ ਜ਼ਿੰਦਗੀ ਨੂੰ ਗੁੰਝਲਦਾਰ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਨ, ਅਤੇ ਸਾਡੇ ਤਜ਼ਰਬੇ ਵਿੱਚ ਉਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਘੱਟ ਹਨ. ਪਰ ਅਜਿਹੇ ਲੋਕ ਵੀ ਹਨ। ਇਸ ਅਨੁਸਾਰ, ਤੁਸੀਂ ਇੱਕ ਸਧਾਰਨ ਪਿੰਗ ਨਾਲ ਡਿਵਾਈਸਾਂ ਦੀ ਮੌਜੂਦਗੀ ਲਈ ਨੈਟਵਰਕ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਕੈਨ ਕਰ ਸਕਦੇ ਹੋ। ਫਿਰ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਜੋੜ ਸਕਦੇ ਹਾਂ ਅਤੇ ਖੁੱਲ੍ਹੀਆਂ ਪੋਰਟਾਂ ਲਈ ਸਕੈਨ ਕਰ ਸਕਦੇ ਹਾਂ ਜੋ ਸਾਡੀ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹਨ. ਵਾਸਤਵ ਵਿੱਚ, ਇਹ ਕਾਰਜਕੁਸ਼ਲਤਾ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਸੀ; ਇਹ ਸਿਰਫ਼ ਕੇਂਦਰੀ ਸਰਵਰ ਤੋਂ ਸਲੇਵ ਵਿੱਚ ਇੱਕ ਕਮਾਂਡ ਜੋੜਨਾ ਜ਼ਰੂਰੀ ਸੀ ਤਾਂ ਜੋ ਇਹ ਨਿਸ਼ਚਿਤ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਸਕੈਨ ਕਰ ਸਕੇ ਅਤੇ ਸੂਚੀ ਵਿੱਚ ਮਿਲੀ ਹਰ ਚੀਜ਼ ਨੂੰ ਜੋੜ ਸਕੇ। ਮੈਂ ਜ਼ਿਕਰ ਕਰਨਾ ਭੁੱਲ ਗਿਆ, ਇਹ ਮੰਨਿਆ ਗਿਆ ਸੀ ਕਿ ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਸੰਰਚਿਤ ਸਿਸਟਮ (ਸਲੇਵ ਮਾਨੀਟਰਿੰਗ ਸਰਵਰ) ਦੇ ਨਾਲ ਇੱਕ ਤਿਆਰ-ਬਣਾਇਆ ਚਿੱਤਰ ਹੈ ਜੋ ਅਸੀਂ ਇੱਕ ਆਡਿਟ ਦੌਰਾਨ ਕਲਾਇੰਟ ਤੋਂ ਆਸਾਨੀ ਨਾਲ ਰੋਲ ਆਊਟ ਕਰ ਸਕਦੇ ਹਾਂ ਅਤੇ ਇਸਨੂੰ ਸਾਡੇ ਕਲਾਉਡ ਨਾਲ ਜੋੜ ਸਕਦੇ ਹਾਂ.

ਪਰ ਇੱਕ ਆਡਿਟ ਦੇ ਨਤੀਜੇ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਜਾਣਕਾਰੀਆਂ ਦਾ ਇੱਕ ਸਮੂਹ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਇਹ ਹੈ ਕਿ ਨੈੱਟਵਰਕ 'ਤੇ ਕਿਸ ਤਰ੍ਹਾਂ ਦੀਆਂ ਡਿਵਾਈਸਾਂ ਹਨ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਇੱਕ ਡੋਮੇਨ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਵਿੰਡੋਜ਼ ਸਰਵਰਾਂ ਅਤੇ ਵਿੰਡੋਜ਼ ਵਰਕਸਟੇਸ਼ਨਾਂ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਸੀ। ਕਿਉਂਕਿ ਮੱਧਮ ਅਤੇ ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਵਿੱਚ ਇੱਕ ਡੋਮੇਨ ਦੀ ਘਾਟ ਸ਼ਾਇਦ ਨਿਯਮ ਦਾ ਇੱਕ ਅਪਵਾਦ ਹੈ। ਇੱਕ ਭਾਸ਼ਾ ਬੋਲਣ ਲਈ, ਔਸਤ, ਮੇਰੀ ਰਾਏ ਵਿੱਚ, 100+ ਲੋਕ ਹਨ। ਸਾਰੀਆਂ ਵਿੰਡੋਜ਼ ਮਸ਼ੀਨਾਂ ਅਤੇ ਸਰਵਰਾਂ ਤੋਂ ਡਾਟਾ ਇਕੱਠਾ ਕਰਨ ਲਈ ਇੱਕ ਢੰਗ ਨਾਲ ਆਉਣਾ ਜ਼ਰੂਰੀ ਸੀ, ਉਹਨਾਂ ਦੇ IP ਅਤੇ ਡੋਮੇਨ ਪ੍ਰਸ਼ਾਸਕ ਖਾਤੇ ਨੂੰ ਜਾਣਦੇ ਹੋਏ, ਪਰ ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ 'ਤੇ ਕੋਈ ਵੀ ਸੌਫਟਵੇਅਰ ਸਥਾਪਤ ਕੀਤੇ ਬਿਨਾਂ. WMI ਇੰਟਰਫੇਸ ਬਚਾਅ ਲਈ ਆਉਂਦਾ ਹੈ। ਵਿੰਡੋਜ਼ ਮੈਨੇਜਮੈਂਟ ਇੰਸਟਰੂਮੈਂਟੇਸ਼ਨ (WMI) ਦਾ ਸ਼ਾਬਦਿਕ ਅਰਥ ਹੈ ਵਿੰਡੋਜ਼ ਮੈਨੇਜਮੈਂਟ ਟੂਲ। WMI ਕੇਂਦਰੀਕ੍ਰਿਤ ਪ੍ਰਬੰਧਨ ਅਤੇ ਵਿੰਡੋਜ਼ ਪਲੇਟਫਾਰਮ 'ਤੇ ਚੱਲ ਰਹੇ ਕੰਪਿਊਟਰ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਦੇ ਸੰਚਾਲਨ ਦੀ ਨਿਗਰਾਨੀ ਲਈ ਬੁਨਿਆਦੀ ਤਕਨੀਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਵਿਕੀ ਤੋਂ ਲਿਆ ਗਿਆ। ਅੱਗੇ, ਡੇਬੀਅਨ ਲਈ wmic (ਇਹ ਇੱਕ WMI ਕਲਾਇੰਟ ਹੈ) ਨੂੰ ਕੰਪਾਇਲ ਕਰਨ ਲਈ ਮੈਨੂੰ ਦੁਬਾਰਾ ਟਿੰਕਰ ਕਰਨਾ ਪਿਆ। ਸਭ ਕੁਝ ਤਿਆਰ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਜੋ ਕੁਝ ਬਚਿਆ ਸੀ ਉਹ ਸਿਰਫ਼ ਲੋੜੀਂਦੀ ਜਾਣਕਾਰੀ ਲਈ wmic ਦੁਆਰਾ ਲੋੜੀਂਦੇ ਨੋਡਾਂ ਨੂੰ ਪੋਲ ਕਰਨਾ ਸੀ। WMI ਦੁਆਰਾ ਤੁਸੀਂ ਵਿੰਡੋਜ਼ ਕੰਪਿਊਟਰ ਤੋਂ ਲਗਭਗ ਕੋਈ ਵੀ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਇਸ ਤੋਂ ਇਲਾਵਾ, ਤੁਸੀਂ ਇਸਦੇ ਦੁਆਰਾ ਕੰਪਿਊਟਰ ਨੂੰ ਨਿਯੰਤਰਿਤ ਵੀ ਕਰ ਸਕਦੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ, ਇਸਨੂੰ ਰੀਬੂਟ ਕਰਨ ਲਈ ਭੇਜੋ। ਇਸ ਤਰ੍ਹਾਂ ਸਾਡੇ ਸਿਸਟਮ ਵਿੱਚ ਵਿੰਡੋਜ਼ ਸਟੇਸ਼ਨਾਂ ਅਤੇ ਸਰਵਰਾਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਦਾ ਸੰਗ੍ਰਹਿ ਪ੍ਰਗਟ ਹੋਇਆ। ਇਸ ਤੋਂ ਇਲਾਵਾ ਮੌਜੂਦਾ ਸਿਸਟਮ ਲੋਡ ਸੂਚਕਾਂ ਬਾਰੇ ਵੀ ਜਾਣਕਾਰੀ ਦਿੱਤੀ ਗਈ। ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਵਧੇਰੇ ਵਾਰ ਬੇਨਤੀ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਹਾਰਡਵੇਅਰ ਬਾਰੇ ਜਾਣਕਾਰੀ ਘੱਟ ਅਕਸਰ. ਇਸ ਤੋਂ ਬਾਅਦ ਆਡਿਟਿੰਗ ਥੋੜੀ ਹੋਰ ਮਜ਼ੇਦਾਰ ਹੋ ਗਈ।

ਸਾਫਟਵੇਅਰ ਵੰਡ ਦਾ ਫੈਸਲਾ

ਅਸੀਂ ਖੁਦ ਸਿਸਟਮ ਨੂੰ ਹਰ ਰੋਜ਼ ਵਰਤਦੇ ਹਾਂ, ਅਤੇ ਇਹ ਹਰ ਤਕਨੀਕੀ ਕਰਮਚਾਰੀ ਲਈ ਹਮੇਸ਼ਾ ਖੁੱਲ੍ਹਾ ਹੁੰਦਾ ਹੈ। ਅਤੇ ਅਸੀਂ ਸੋਚਿਆ ਕਿ ਅਸੀਂ ਦੂਜਿਆਂ ਨਾਲ ਸਾਂਝਾ ਕਰ ਸਕਦੇ ਹਾਂ ਜੋ ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਹੈ. ਸਿਸਟਮ ਅਜੇ ਵੰਡਣ ਲਈ ਤਿਆਰ ਨਹੀਂ ਸੀ। ਬਹੁਤ ਕੁਝ ਦੁਬਾਰਾ ਕੰਮ ਕਰਨਾ ਪਿਆ ਤਾਂ ਜੋ ਸਥਾਨਕ ਸੰਸਕਰਣ SaaS ਵਿੱਚ ਬਦਲ ਜਾਵੇ। ਇਹਨਾਂ ਵਿੱਚ ਸਿਸਟਮ ਦੇ ਵੱਖ-ਵੱਖ ਤਕਨੀਕੀ ਪਹਿਲੂਆਂ (ਰਿਮੋਟ ਕਨੈਕਸ਼ਨ, ਸਹਾਇਤਾ ਸੇਵਾ), ਲਾਇਸੈਂਸਿੰਗ ਲਈ ਮੋਡਿਊਲਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ, ਗਾਹਕ ਡੇਟਾਬੇਸ ਦੀ ਸ਼ਾਰਡਿੰਗ, ਹਰੇਕ ਸੇਵਾ ਦੀ ਸਕੇਲਿੰਗ, ਅਤੇ ਸਾਰੇ ਹਿੱਸਿਆਂ ਲਈ ਆਟੋ-ਅੱਪਡੇਟ ਪ੍ਰਣਾਲੀਆਂ ਦਾ ਵਿਕਾਸ ਸ਼ਾਮਲ ਹੈ। ਪਰ ਇਹ ਲੇਖ ਦਾ ਦੂਜਾ ਹਿੱਸਾ ਹੋਵੇਗਾ.

ਅੱਪਡੇਟ

ਦੂਜਾ ਹਿੱਸਾ

ਸਰੋਤ: www.habr.com