ਹਾਈਲੋਡ ਆਈਟੀ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਸੰਚਾਲਨ ਅਤੇ ਸਮਰਥਨ ਦੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿੱਚ ਪੰਜ ਸਮੱਸਿਆਵਾਂ

ਹੈਲੋ, ਹੈਬਰ! ਮੈਂ ਦਸ ਸਾਲਾਂ ਤੋਂ ਹਾਈਲੋਡ ਆਈਟੀ ਸਿਸਟਮ ਦਾ ਸਮਰਥਨ ਕਰ ਰਿਹਾ ਹਾਂ। ਮੈਂ ਇਸ ਲੇਖ ਵਿੱਚ 1000+ RPS ਮੋਡ ਜਾਂ ਹੋਰ ਤਕਨੀਕੀ ਚੀਜ਼ਾਂ ਵਿੱਚ ਕੰਮ ਕਰਨ ਲਈ nginx ਸਥਾਪਤ ਕਰਨ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਨਹੀਂ ਲਿਖਾਂਗਾ. ਮੈਂ ਅਜਿਹੀਆਂ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਸਮਰਥਨ ਅਤੇ ਸੰਚਾਲਨ ਵਿੱਚ ਪੈਦਾ ਹੋਣ ਵਾਲੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਆਪਣੇ ਨਿਰੀਖਣ ਸਾਂਝੇ ਕਰਾਂਗਾ।

ਨਿਗਰਾਨੀ

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

ਸਥਿਤੀ ਦਾ ਕੀ ਕਰਨਾ ਹੈ ਜਦੋਂ ਇੱਕ ਔਨਲਾਈਨ ਸਟੋਰ ਦਾ ਬਾਕੀ ਸਾਮਾਨ ERP ਸਿਸਟਮ ਤੋਂ ਨਹੀਂ ਆਉਂਦਾ? ਜਾਂ ਕੀ CRM ਸਿਸਟਮ ਜੋ ਗਾਹਕਾਂ ਲਈ ਛੋਟਾਂ ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ, ਨੇ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੱਤਾ ਹੈ? ਸਾਈਟ ਕੰਮ ਕਰਦੀ ਜਾਪਦੀ ਹੈ। ਕੰਡੀਸ਼ਨਲ ਜ਼ੈਬਿਕਸ ਨੂੰ ਇਸਦਾ 200 ਜਵਾਬ ਮਿਲਦਾ ਹੈ। ਡਿਊਟੀ ਸ਼ਿਫਟ ਨੂੰ ਨਿਗਰਾਨੀ ਤੋਂ ਕੋਈ ਸੂਚਨਾ ਨਹੀਂ ਮਿਲੀ ਹੈ ਅਤੇ ਉਹ ਗੇਮ ਆਫ ਥ੍ਰੋਨਸ ਦੇ ਨਵੇਂ ਸੀਜ਼ਨ ਦੇ ਪਹਿਲੇ ਐਪੀਸੋਡ ਨੂੰ ਖੁਸ਼ੀ ਨਾਲ ਦੇਖ ਰਿਹਾ ਹੈ।

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

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

ਬਾਹਰੀ ਸਿਸਟਮ ਦੇ ਨਾਲ ਪਰਸਪਰ ਪ੍ਰਭਾਵ

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

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

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

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

ਬੋਟਲਨੇਕ ਮੈਨ

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

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

ਸਹਾਇਕ ਸਟਾਫ ਦੀ ਯੋਗਤਾ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀ

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

ਜੇ ਅਸੀਂ ਇੱਕ ਵੱਡੇ ਔਨਲਾਈਨ ਸਟੋਰ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਤਾਂ ਹਰ ਘੰਟੇ ਦੇ ਡਾਊਨਟਾਈਮ ਦੀ ਕੀਮਤ ਇੱਕ ਐਨੀਕੀ ਪ੍ਰਸ਼ਾਸਕ ਦੀ ਮਹੀਨਾਵਾਰ ਤਨਖਾਹ ਨਾਲੋਂ ਵੱਧ ਹੁੰਦੀ ਹੈ. ਆਉ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਦੇ ਤੌਰ 'ਤੇ ਸਾਲਾਨਾ ਟਰਨਓਵਰ ਦੇ 1 ਬਿਲੀਅਨ ਰੂਬਲ ਲੈਂਦੇ ਹਾਂ। ਇਹ ਰੇਟਿੰਗ ਤੋਂ ਕਿਸੇ ਵੀ ਔਨਲਾਈਨ ਸਟੋਰ ਦਾ ਨਿਊਨਤਮ ਟਰਨਓਵਰ ਹੈ 100 ਲਈ ਚੋਟੀ ਦੇ 2018. ਇਸ ਰਕਮ ਨੂੰ ਪ੍ਰਤੀ ਸਾਲ ਘੰਟਿਆਂ ਦੀ ਗਿਣਤੀ ਨਾਲ ਵੰਡੋ ਅਤੇ ਸ਼ੁੱਧ ਘਾਟੇ ਦੇ 100 ਰੂਬਲ ਤੋਂ ਵੱਧ ਪ੍ਰਾਪਤ ਕਰੋ। ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਰਾਤ ਦੇ ਘੰਟਿਆਂ ਦੀ ਗਿਣਤੀ ਨਹੀਂ ਕਰਦੇ, ਤਾਂ ਤੁਸੀਂ ਸੁਰੱਖਿਅਤ ਰੂਪ ਨਾਲ ਰਕਮ ਨੂੰ ਦੁੱਗਣਾ ਕਰ ਸਕਦੇ ਹੋ।

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

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

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

ਵਿਕਾਸ ਟੀਮ ਨਾਲ ਗੱਲਬਾਤ

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

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

ਸਧਾਰਣ ਜਾਂ ਘੱਟ ਤਰਜੀਹ ਵਾਲੇ ਮੁੱਦੇ ਰੀਲੀਜ਼ ਤੋਂ ਰੀਲੀਜ਼ ਤੱਕ ਚਲੇ ਜਾਂਦੇ ਹਨ। ਇਸ ਸਵਾਲ ਲਈ "ਕਦੋਂ ਕੰਮ ਪੂਰਾ ਹੋਵੇਗਾ?" ਤੁਸੀਂ ਇਸ ਸ਼ੈਲੀ ਵਿੱਚ ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰੋਗੇ: "ਮਾਫ਼ ਕਰਨਾ, ਇਸ ਸਮੇਂ ਬਹੁਤ ਸਾਰੇ ਕੰਮ ਹਨ, ਆਪਣੀ ਟੀਮ ਦੇ ਲੀਡਜ਼ ਜਾਂ ਰੀਲੀਜ਼ ਮੈਨੇਜਰ ਨੂੰ ਪੁੱਛੋ।"

ਉਤਪਾਦਕਤਾ ਸਮੱਸਿਆਵਾਂ ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਬਣਾਉਣ ਨਾਲੋਂ ਉੱਚ ਪਹਿਲ ਦਿੰਦੀਆਂ ਹਨ। ਮਾੜੀਆਂ ਸਮੀਖਿਆਵਾਂ ਆਉਣ ਵਿੱਚ ਜ਼ਿਆਦਾ ਦੇਰ ਨਹੀਂ ਹੋਣਗੀਆਂ ਜੇਕਰ ਉਪਭੋਗਤਾ ਲਗਾਤਾਰ ਬੱਗਾਂ 'ਤੇ ਠੋਕਰ ਖਾਂਦੇ ਹਨ। ਖਰਾਬ ਹੋਈ ਸਾਖ ਨੂੰ ਬਹਾਲ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ।

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

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

ਸਰੋਤ: www.habr.com