ਅਸੀਂ ਗੁਣਵੱਤਾ ਨੂੰ ਨਾ ਗੁਆਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋਏ ਸਮਰਥਨ ਨੂੰ ਸਸਤਾ ਬਣਾਉਂਦੇ ਹਾਂ

ਫਾਲਬੈਕ ਮੋਡ (ਜਿਸ ਨੂੰ IPKVM ਵੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ), ਜੋ ਤੁਹਾਨੂੰ ਹਾਈਪਰਵਾਈਜ਼ਰ ਲੇਅਰ ਤੋਂ ਸਿੱਧੇ RDP ਤੋਂ ਬਿਨਾਂ VPS ਨਾਲ ਜੁੜਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਪ੍ਰਤੀ ਹਫ਼ਤੇ 15-20 ਮਿੰਟ ਬਚਾਉਂਦਾ ਹੈ।

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

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

ਹੁਣ ਮੈਂ ਤੁਹਾਨੂੰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਬਾਰੇ ਥੋੜਾ ਹੋਰ ਦੱਸਾਂਗਾ - ਅਤੇ ਉਹਨਾਂ ਨਾਲ ਅਟੱਲ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ।

ਲੋਕਾਂ ਨੂੰ #1 ਤੋਂ ਪਰੇਸ਼ਾਨ ਨਾ ਕਰੋ

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

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

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

ਲੋਕਾਂ ਨੂੰ #2 ਤੋਂ ਪਰੇਸ਼ਾਨ ਨਾ ਕਰੋ

ਦੂਜੀ ਗੱਲ ਜੋ ਬਰਾਬਰੀ ਨਾਲ ਦਿਮਾਗ ਨੂੰ ਖੋਲ੍ਹਦੀ ਹੈ ਉਹ ਹੈ ਜਦੋਂ ਕੋਈ ਵੀ ਲੰਬੇ ਸਮੇਂ ਲਈ ਟਿਕਟ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ. ਯੂਰਪ ਵਿੱਚ, ਇਹ ਸਹਾਇਤਾ ਵਿਵਹਾਰ ਆਮ ਹੈ: ਕਿਸੇ ਘਟਨਾ ਨੂੰ ਕੰਮ ਲਈ ਸਵੀਕਾਰ ਕੀਤੇ ਜਾਣ ਤੋਂ ਤਿੰਨ ਦਿਨ ਪਹਿਲਾਂ ਆਮ ਨਾਲੋਂ ਵੱਧ ਹੈ। ਭਾਵੇਂ ਤੁਸੀਂ ਬਹੁਤ ਜ਼ਰੂਰੀ ਹੋ ਅਤੇ ਕੁਝ ਬਲ ਰਿਹਾ ਹੈ - ਕੋਈ ਸੋਸ਼ਲ ਨੈਟਵਰਕ ਨਹੀਂ, ਕੋਈ ਫੋਨ ਨਹੀਂ, ਕੋਈ ਮੈਸੇਂਜਰ ਨਹੀਂ, ਬੱਸ ਈਮੇਲ ਕਰੋ ਅਤੇ ਆਪਣੀ ਵਾਰੀ ਦੀ ਉਡੀਕ ਕਰੋ। ਰੂਸ ਵਿੱਚ ਇਹ ਬਹੁਤ ਘੱਟ ਆਮ ਹੈ, ਪਰ ਕੁਝ ਟਿਕਟਾਂ ਅਜੇ ਵੀ "ਭੁੱਲੀਆਂ" ਹਨ। ਕੰਮ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ, ਅਸੀਂ 15 ਮਿੰਟ ਦੇ ਪਹਿਲੇ ਜਵਾਬ ਲਈ ਇੱਕ SLA ਸੈੱਟ ਕੀਤਾ ਹੈ। ਅਤੇ ਇਹ 24/7 ਇਮਾਨਦਾਰ ਹੈ. ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਜਦੋਂ VDS ਹੋਸਟਿੰਗ ਵੱਡੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਇਹ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ. ਪਰ ਸ਼ੱਕੀ ਸੇਵਾ ਪ੍ਰਦਾਤਾਵਾਂ ਕੋਲ ਅਜਿਹਾ ਨਹੀਂ ਹੈ। ਅਤੇ ਅਸੀਂ ਸ਼ੁਰੂ ਵਿਚ ਸਿਰਫ ਸ਼ੱਕੀ ਸੀ ਅਤੇ ਉਦੋਂ ਹੀ ਘੱਟ ਜਾਂ ਘੱਟ ਵੱਡੇ ਬਣ ਗਏ. ਠੀਕ ਹੈ, ਵੱਧ ਜਾਂ ਘੱਟ ਔਸਤ।

ਪਹਿਲੀ ਲਾਈਨ ਓਪਰੇਟਰ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਕ੍ਰਿਪਟਾਂ ਦਿੱਤੀਆਂ ਗਈਆਂ ਸਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਆਮ ਸਥਿਤੀਆਂ 'ਤੇ ਪ੍ਰਤੀਕ੍ਰਿਆ ਕਰਨਾ ਸਿਖਾਇਆ ਗਿਆ ਸੀ। ਉਹ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਜਲਦੀ ਹੱਲ ਕਰਦੇ ਹਨ ਅਤੇ 15 ਮਿੰਟਾਂ ਦੇ ਅੰਦਰ ਜਾਂ ਤਾਂ ਇੱਕ ਆਮ ਕਾਰਵਾਈ ਨਾਲ ਜਵਾਬ ਦੇਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਜਾਂ ਰਿਪੋਰਟ ਕਰਦੇ ਹਨ ਕਿ ਟਿਕਟ ਪ੍ਰਗਤੀ ਵਿੱਚ ਹੈ ਅਤੇ ਇਸਨੂੰ ਦੂਜੀ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕਰੋ।

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

ਅਰਜ਼ੀਆਂ ਦੀ ਗਿਣਤੀ ਘਟਾਓ

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

ਜੇਕਰ ਤੁਹਾਨੂੰ ਸਮਰਥਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਤਾਂ ਉਹ ਇੱਕ ਚੰਗਾ ਕੰਮ ਕਰ ਰਹੀ ਹੈ।

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

ਜੇ ਗਿਆਨ ਅਧਾਰ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਸੌਫਟਵੇਅਰ ਬਾਰੇ ਕੋਈ ਚੀਜ਼ ਬਹੁਤ ਮਸ਼ਹੂਰ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਮਾਰਕੀਟਪਲੇਸ ਵਿੱਚ ਵੰਡ ਨੂੰ ਜੋੜ ਸਕਦੇ ਹੋ ਤਾਂ ਜੋ ਸੇਵਾ "ਇਸ ਪਹਿਲਾਂ ਤੋਂ ਸਥਾਪਤ ਸਰਵਰ ਨਾਲ ਸੈਟ ਅਪ ਕਰੋ" ਦਿਖਾਈ ਦੇਵੇ। ਅਸਲ ਵਿੱਚ, ਡੌਕਰ ਨਾਲ ਅਜਿਹਾ ਹੀ ਹੋਇਆ ਹੈ, ਅਤੇ ਇਹ ਉਹੀ ਹੈ ਜੋ ਮਾਇਨਕਰਾਫਟ ਸਰਵਰ ਨਾਲ ਹੋਇਆ ਹੈ। ਦੁਬਾਰਾ ਫਿਰ, ਇੰਟਰਫੇਸ ਵਿੱਚ ਇੱਕ "ਡੂ ਮੀ ਗੁੱਡ" ਬਟਨ ਇੱਕ ਸਾਲ ਵਿੱਚ ਸੈਂਕੜੇ ਟਿਕਟਾਂ ਦੀ ਬਚਤ ਕਰਦਾ ਹੈ।

ਐਮਰਜੈਂਸੀ ਮੋਡ

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

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

ਇਸ ਲਈ, ਅਸੀਂ ਸਾਰੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਐਮਰਜੈਂਸੀ ਮੋਡ ਤੱਕ ਪਹੁੰਚ ਦਿੱਤੀ ਹੈ, ਪਰ ਇਹ ਨਿਰੰਤਰ ਵਰਤੋਂ ਦੀ ਮਿਆਦ ਦੇ ਰੂਪ ਵਿੱਚ ਸੀਮਿਤ ਹੈ। ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਜਿਵੇਂ ਕਿ ਅਭਿਆਸ ਦਿਖਾਉਂਦਾ ਹੈ, ਇਹ ਸਮਾਂ ਰੀਬੂਟ ਕਰਨ ਅਤੇ ਕੁਝ ਠੀਕ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਹੈ.

ਨਤੀਜਾ ਹੋਰ ਵੀ ਘੱਟ ਸਮਰਥਨ ਟਿਕਟਾਂ ਹੈ। ਅਤੇ ਜਿੱਥੇ ਐਡਮਿਨ ਖੁਦ ਟਿਕਟ ਨੂੰ ਠੀਕ ਕਰ ਸਕਦਾ ਹੈ, ਸਹਾਇਤਾ ਨੂੰ ਅੰਦਰ ਜਾਣ ਅਤੇ ਇਸਦਾ ਪਤਾ ਲਗਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

ਬਾਕੀ ਸਮੱਸਿਆਵਾਂ

ਬਹੁਤ ਅਕਸਰ, ਉਪਭੋਗਤਾ ਸੋਚਦੇ ਹਨ ਕਿ ਸਮਰਥਨ ਉਹਨਾਂ 'ਤੇ ਕੁਝ ਧੱਕ ਰਿਹਾ ਹੈ. ਬਦਕਿਸਮਤੀ ਨਾਲ, ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (ਜਾਂ ਅਸੀਂ ਕੁਝ ਵੀ ਨਹੀਂ ਲਿਆ ਹੈ)। ਦੋ ਸਭ ਤੋਂ ਆਮ ਉਦਾਹਰਨਾਂ ਹਨ ਸਰੋਤ ਸੀਮਾਵਾਂ ਅਤੇ DDoS ਸੁਰੱਖਿਆ।

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

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

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

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

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

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

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

ਓ ਹਾਂ. ਸਾਲ ਦੀ ਸਾਡੀ ਸਭ ਤੋਂ ਵਧੀਆ ਬੇਨਤੀ ਹੈ: "ਕੀ ਮੈਂ ਖਰੀਦਣ ਤੋਂ ਪਹਿਲਾਂ 30 ਰੂਬਲ ਪ੍ਰਤੀ ਮਹੀਨਾ ਦੀ ਦਰ ਨਾਲ ਕੁਝ ਦਿਨਾਂ ਲਈ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦਾ ਹਾਂ?"

ਨਤੀਜਾ

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

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

ਅਸੀਂ ਅਜਿਹਾ ਬਹੁਤ ਘੱਟ ਹੀ ਕਰਦੇ ਹਾਂ ਅਤੇ ਅਸੀਂ ਅਜਿਹੇ ਕੰਮ ਨੂੰ ਸਿਰਫ਼ ਸਭ ਤੋਂ ਵਧੀਆ ਨੂੰ ਸੌਂਪਦੇ ਹਾਂ, ਕਿਉਂਕਿ ਅਸੀਂ ਗਾਰੰਟੀ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ ਉਪਭੋਗਤਾ ਡੇਟਾ ਨੂੰ ਨੁਕਸਾਨ ਨਹੀਂ ਹੋਵੇਗਾ। ਸਭ ਤੋਂ ਵਧੀਆ ਸਹਾਇਤਾ ਦੀ ਦੂਜੀ ਲਾਈਨ ਹੈ।

ਪਹਿਲੀ ਲਾਈਨ ਵਿੱਚ ਇੱਕ ਗਿਆਨ ਅਧਾਰ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਗੁੰਝਲਦਾਰ ਚੀਜ਼ਾਂ ਨੂੰ ਦੇਖਣ ਲਈ ਭੇਜ ਸਕਦੇ ਹੋ।

ਫੰਕਸ਼ਨਾਂ ਨਾਲ ਭਰਪੂਰ ਇੱਕ ਨਿੱਜੀ ਖਾਤਾ ਅਤੇ ਇੱਕ ਗਿਆਨ ਅਧਾਰ - ਅਤੇ ਹੁਣ ਅਸੀਂ ਔਸਤਨ ਪ੍ਰਤੀ ਕਲਾਇੰਟ ਪ੍ਰਤੀ ਸਾਲ 1–1,5 ਤੱਕ ਬੇਨਤੀਆਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਘਟਾਉਣ ਦੇ ਯੋਗ ਸੀ।

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

ਦੂਜੀ ਲਾਈਨ ਵਿੱਚ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਕਿੱਟਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਅਤੇ ਆਟੋਮੇਸ਼ਨ ਸਕ੍ਰਿਪਟਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਹੈ। ਲੋੜ ਅਨੁਸਾਰ ਦੋਵਾਂ ਨੂੰ ਅਪਡੇਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

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

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

ਆਮ ਤੌਰ 'ਤੇ, ਤੁਸੀਂ ਕਦੇ ਨਹੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਸਮਰਥਨ ਦੇ ਨਾਲ ਇੱਕ ਸੰਵਾਦ ਦਾ ਸਕ੍ਰੀਨਸ਼ੌਟ ਕਿੱਥੇ ਖਤਮ ਹੋਵੇਗਾ, ਅਤੇ ਜੇਕਰ ਕੋਈ ਵਿਅਕਤੀ ਸਮਰਥਨ ਲਈ ਖੜਕਾਉਂਦਾ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਇੱਕ ਸਮੱਸਿਆ ਹੈ। ਤੁਸੀਂ ਆਪਣਾ ਰਵੱਈਆ ਸੁਧਾਰ ਸਕਦੇ ਹੋ। ਘੱਟੋ ਘੱਟ ਕੋਸ਼ਿਸ਼ ਕਰੋ.

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

ਸਰੋਤ: www.habr.com