ਇੰਜੀਨੀਅਰ ਐਪਲੀਕੇਸ਼ਨ ਨਿਗਰਾਨੀ ਦੀ ਪਰਵਾਹ ਕਿਉਂ ਨਹੀਂ ਕਰਦੇ?

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

ਨਿਗਰਾਨੀ ਹੈ ਸਿਰਫ. ਇਹ ਜਾਣਿਆ-ਪਛਾਣਿਆ ਤੱਥ ਹੈ। Nagios ਨੂੰ ਲਿਆਓ, ਰਿਮੋਟ ਸਿਸਟਮ 'ਤੇ NRPE ਚਲਾਓ, NRPE TCP ਪੋਰਟ 5666 'ਤੇ Nagios ਨੂੰ ਕੌਂਫਿਗਰ ਕਰੋ ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਨਿਗਰਾਨੀ ਹੈ।

ਇਹ ਇੰਨਾ ਆਸਾਨ ਹੈ ਕਿ ਇਹ ਦਿਲਚਸਪ ਨਹੀਂ ਹੈ। ਹੁਣ ਤੁਹਾਡੇ ਕੋਲ CPU ਸਮਾਂ, ਡਿਸਕ ਸਬ-ਸਿਸਟਮ, RAM ਲਈ ਮੂਲ ਮੈਟ੍ਰਿਕਸ ਹਨ, ਜੋ ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ Nagios ਅਤੇ NRPE ਨੂੰ ਸਪਲਾਈ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਪਰ ਇਹ ਅਸਲ ਵਿੱਚ "ਨਿਗਰਾਨੀ" ਨਹੀਂ ਹੈ। ਇਹ ਤਾਂ ਸ਼ੁਰੂਆਤ ਹੈ।

(ਆਮ ਤੌਰ 'ਤੇ ਉਹ PNP4Nagios, RRDtool ਅਤੇ Thruk ਨੂੰ ਸਥਾਪਿਤ ਕਰਦੇ ਹਨ, ਸਲੈਕ ਵਿੱਚ ਸੂਚਨਾਵਾਂ ਸੈਟ ਅਪ ਕਰਦੇ ਹਨ ਅਤੇ ਸਿੱਧੇ ਨਾਗਿਓਸੈਕਸਚੇਂਜ 'ਤੇ ਜਾਂਦੇ ਹਨ, ਪਰ ਚਲੋ ਇਸ ਨੂੰ ਹੁਣੇ ਛੱਡ ਦਿਓ)।

ਚੰਗੀ ਨਿਗਰਾਨੀ ਅਸਲ ਵਿੱਚ ਕਾਫ਼ੀ ਗੁੰਝਲਦਾਰ ਹੈ, ਤੁਹਾਨੂੰ ਅਸਲ ਵਿੱਚ ਉਸ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅੰਦਰੂਨੀ ਭਾਗਾਂ ਨੂੰ ਜਾਣਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਜਿਸਦੀ ਤੁਸੀਂ ਨਿਗਰਾਨੀ ਕਰ ਰਹੇ ਹੋ।

ਕੀ ਨਿਗਰਾਨੀ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ?

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

ਫੋਟੋ ਦੇ ਲੇਖਕ ਲੂਕਾ ਚੈਸਰ 'ਤੇ Unsplash

(ਮੈਂ ਚਾਹੁੰਦਾ ਹਾਂ ਕਿ ਮੇਰੇ ਡੈਸ਼ਬੋਰਡ ਨੀਓਨ ਨੀਲੇ ਹੁੰਦੇ - ਸੁਪਨੇ ਨਾਲ ਹੱਸਦੇ ਹੋਏ -... ਹੰਮ...)

ਕੋਈ ਵੀ ਸੌਫਟਵੇਅਰ ਜੋ ਸੇਵਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਕੋਲ ਮੈਟ੍ਰਿਕਸ ਇਕੱਤਰ ਕਰਨ ਲਈ ਇੱਕ ਵਿਧੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਅਪਾਚੇ ਦਾ ਇੱਕ ਮੋਡੀਊਲ ਹੈ mod-status, ਸਰਵਰ ਸਥਿਤੀ ਪੰਨਾ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰ ਰਿਹਾ ਹੈ। Nginx ਕੋਲ - stub_status. Tomcat ਕੋਲ JMX ਜਾਂ ਕਸਟਮ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ ਹਨ ਜੋ ਮੁੱਖ ਮੈਟ੍ਰਿਕਸ ਦਿਖਾਉਂਦੇ ਹਨ। MySQL ਕੋਲ "ਗਲੋਬਲ ਸਥਿਤੀ ਦਿਖਾਓ" ਆਦਿ ਕਮਾਂਡ ਹੈ।
ਤਾਂ ਫਿਰ ਡਿਵੈਲਪਰ ਉਹਨਾਂ ਦੁਆਰਾ ਬਣਾਏ ਗਏ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਸਮਾਨ ਵਿਧੀ ਕਿਉਂ ਨਹੀਂ ਬਣਾਉਂਦੇ?

ਕੀ ਸਿਰਫ ਡਿਵੈਲਪਰ ਹੀ ਅਜਿਹਾ ਕਰ ਰਹੇ ਹਨ?

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

ਫੋਟੋ ਦੇ ਲੇਖਕ ਟਿਮ ਗੌਅ 'ਤੇ Unsplash

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

ਮੈਟ੍ਰਿਕਸ ਦੀ ਜ਼ਰੂਰਤ ਦੇ ਸੰਬੰਧ ਵਿੱਚ ਸੋਚ ਵਿੱਚ ਇੱਕ ਤਬਦੀਲੀ ਨਾ ਸਿਰਫ ਡਿਵੈਲਪਰਾਂ ਵਿੱਚ, ਬਲਕਿ ਸਿਸਟਮ ਇੰਜੀਨੀਅਰਾਂ ਵਿੱਚ ਵੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

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

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

ਇਹ ਚੀਜ਼ ਨੂੰ ਵਿਗਾੜਦਾ ਹੈ

ਡਿਵੋਪਸ ਮਾਨਸਿਕਤਾ ਵਿਕਾਸ (ਦੇਵ) ਅਤੇ ਓਪਰੇਸ਼ਨ (ਓਪਸ) ਸੋਚ ਵਿਚਕਾਰ ਤਾਲਮੇਲ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ। ਕੋਈ ਵੀ ਕੰਪਨੀ ਜੋ "ਡੂਓਪਜ਼" ਕਰਨ ਦਾ ਦਾਅਵਾ ਕਰਦੀ ਹੈ:

1. ਉਹ ਗੱਲਾਂ ਕਹਿਣ ਜੋ ਉਹ ਸ਼ਾਇਦ ਨਹੀਂ ਕਰਦੇ (ਰਾਜਕੁਮਾਰੀ ਬ੍ਰਾਈਡ ਮੇਮ ਦਾ ਹਵਾਲਾ ਦਿੰਦੇ ਹੋਏ - "ਮੈਨੂੰ ਨਹੀਂ ਲੱਗਦਾ ਕਿ ਇਸਦਾ ਮਤਲਬ ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ ਇਸਦਾ ਮਤਲਬ ਹੈ!")
2. ਨਿਰੰਤਰ ਉਤਪਾਦ ਸੁਧਾਰ ਦੇ ਰਵੱਈਏ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰੋ।

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

ਖੱਬੇ ਪਾਸੇ ਸ਼ਿਫਟ ਕਰੋ, ਖੱਬੇ ਪਾਸੇ, ਮੈਂ ਕਿਹਾ ਲੀਈ-

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

ਫੋਟੋ ਦੇ ਲੇਖਕ ਮੇਕਰਜ਼ ਦੁਆਰਾ NESA 'ਤੇ Unsplash

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

ਸੰਖੇਪ ਵਿੱਚ

1. ਆਪਣੇ ਘੋੜੇ ਨੂੰ ਪਾਣੀ ਵੱਲ ਲੈ ਜਾਓ. ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਦਿਖਾਓ ਕਿ ਉਹ ਆਪਣੇ ਲਈ ਕਿੰਨੀ ਮੁਸੀਬਤ ਤੋਂ ਬਚ ਸਕਦੇ ਹਨ, ਉਹਨਾਂ ਦੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਸਹੀ KPIs ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਦੀ ਪਛਾਣ ਕਰਨ ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਮਦਦ ਕਰੋ ਤਾਂ ਜੋ CTO ਦੁਆਰਾ ਚੀਕਣ ਵਾਲੇ ਉਤਪਾਦ ਦੇ ਮਾਲਕ ਤੋਂ ਘੱਟ ਰੌਲਾ ਪਵੇ। ਉਹਨਾਂ ਨੂੰ ਰੋਸ਼ਨੀ ਵਿੱਚ, ਹੌਲੀ ਅਤੇ ਸ਼ਾਂਤੀ ਨਾਲ ਲਿਆਓ। ਜੇਕਰ ਇਹ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਜਾਂ ਉਤਪਾਦ ਦੇ ਮਾਲਕ ਨੂੰ ਰਿਸ਼ਵਤ ਦਿਓ, ਧਮਕੀ ਦਿਓ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਜਲਦੀ ਤੋਂ ਜਲਦੀ ਐਪਲੀਕੇਸ਼ਨਾਂ ਤੋਂ ਇਹਨਾਂ ਮਾਪਦੰਡਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਲਾਗੂ ਕਰੋ, ਅਤੇ ਫਿਰ ਚਿੱਤਰਾਂ ਨੂੰ ਖਿੱਚੋ। ਇਹ ਮੁਸ਼ਕਲ ਹੋਵੇਗਾ ਕਿਉਂਕਿ ਇਸ ਨੂੰ ਤਰਜੀਹ ਵਜੋਂ ਨਹੀਂ ਦੇਖਿਆ ਜਾਵੇਗਾ ਅਤੇ ਉਤਪਾਦ ਰੋਡਮੈਪ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਮਾਲੀਆ ਪੈਦਾ ਕਰਨ ਵਾਲੇ ਪ੍ਰੋਜੈਕਟ ਪੈਂਡਿੰਗ ਹੋਣਗੇ। ਇਸ ਲਈ, ਤੁਹਾਨੂੰ ਉਤਪਾਦ ਵਿੱਚ ਨਿਗਰਾਨੀ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਖਰਚੇ ਗਏ ਸਮੇਂ ਅਤੇ ਖਰਚੇ ਨੂੰ ਜਾਇਜ਼ ਠਹਿਰਾਉਣ ਲਈ ਇੱਕ ਕਾਰੋਬਾਰੀ ਕੇਸ ਦੀ ਲੋੜ ਹੋਵੇਗੀ।
2. ਸਿਸਟਮ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਚੰਗੀ ਨੀਂਦ ਲੈਣ ਵਿੱਚ ਮਦਦ ਕਰੋ। ਉਹਨਾਂ ਨੂੰ ਦਿਖਾਓ ਕਿ ਜਾਰੀ ਕੀਤੇ ਜਾ ਰਹੇ ਕਿਸੇ ਵੀ ਉਤਪਾਦ ਲਈ "ਚਲੋ ਜਾਰੀ ਕਰੋ" ਚੈੱਕਲਿਸਟ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਚੰਗੀ ਗੱਲ ਹੈ। ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਕਿ ਉਤਪਾਦਨ ਵਿੱਚ ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਮੈਟ੍ਰਿਕਸ ਨਾਲ ਕਵਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਤੁਹਾਨੂੰ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਇਹ ਦੇਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇ ਕੇ ਰਾਤ ਨੂੰ ਬਿਹਤਰ ਸੌਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ ਕਿ ਕੀ ਗਲਤ ਅਤੇ ਕਿੱਥੇ ਹੋ ਰਿਹਾ ਹੈ। ਹਾਲਾਂਕਿ, ਕਿਸੇ ਵੀ ਡਿਵੈਲਪਰ, ਉਤਪਾਦ ਦੇ ਮਾਲਕ, ਜਾਂ ਸੀਟੀਓ ਨੂੰ ਪਰੇਸ਼ਾਨ ਕਰਨ ਅਤੇ ਨਿਰਾਸ਼ ਕਰਨ ਦਾ ਸਹੀ ਤਰੀਕਾ ਹੈ ਜਾਰੀ ਰਹਿਣਾ ਅਤੇ ਵਿਰੋਧ ਕਰਨਾ। ਇਹ ਵਿਵਹਾਰ ਕਿਸੇ ਵੀ ਉਤਪਾਦ ਦੀ ਰਿਲੀਜ਼ ਮਿਤੀ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰੇਗਾ ਜੇਕਰ ਤੁਸੀਂ ਦੁਬਾਰਾ ਆਖਰੀ ਮਿੰਟ ਤੱਕ ਉਡੀਕ ਕਰਦੇ ਹੋ, ਇਸ ਲਈ ਦੁਬਾਰਾ ਖੱਬੇ ਪਾਸੇ ਸ਼ਿਫਟ ਕਰੋ ਅਤੇ ਜਿੰਨੀ ਜਲਦੀ ਹੋ ਸਕੇ ਇਹਨਾਂ ਮੁੱਦਿਆਂ ਨੂੰ ਆਪਣੀ ਪ੍ਰੋਜੈਕਟ ਯੋਜਨਾ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ। ਜੇ ਜਰੂਰੀ ਹੋਵੇ, ਉਤਪਾਦ ਮੀਟਿੰਗਾਂ ਲਈ ਆਪਣਾ ਰਸਤਾ ਬਣਾਓ। ਨਕਲੀ ਮੁੱਛਾਂ ਪਾਓ ਅਤੇ ਮਹਿਸੂਸ ਕਰੋ ਜਾਂ ਕੁਝ, ਇਹ ਕਦੇ ਵੀ ਅਸਫਲ ਨਹੀਂ ਹੋਵੇਗਾ. ਆਪਣੀਆਂ ਚਿੰਤਾਵਾਂ ਨੂੰ ਸੰਚਾਰ ਕਰੋ, ਸਪਸ਼ਟ ਲਾਭਾਂ ਦਾ ਪ੍ਰਦਰਸ਼ਨ ਕਰੋ, ਅਤੇ ਪ੍ਰਚਾਰ ਕਰੋ।
3. ਇਹ ਸੁਨਿਸ਼ਚਿਤ ਕਰੋ ਕਿ ਵਿਕਾਸ (ਦੇਵ) ਅਤੇ ਸੰਚਾਲਨ (ਓਪਸ) ਦੋਵੇਂ ਲਾਲ ਜ਼ੋਨ ਵਿੱਚ ਜਾਣ ਵਾਲੇ ਉਤਪਾਦ ਮੈਟ੍ਰਿਕਸ ਦੇ ਅਰਥ ਅਤੇ ਨਤੀਜੇ ਨੂੰ ਸਮਝਦੇ ਹਨ। Ops ਨੂੰ ਉਤਪਾਦ ਦੀ ਸਿਹਤ ਦੇ ਇਕਮਾਤਰ ਸਰਪ੍ਰਸਤ ਵਜੋਂ ਨਾ ਛੱਡੋ, ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਡਿਵੈਲਪਰ ਵੀ ਸ਼ਾਮਲ ਹਨ (#productsquads)।
4. ਲੌਗ ਇੱਕ ਵਧੀਆ ਚੀਜ਼ ਹਨ, ਪਰ ਮੈਟ੍ਰਿਕਸ ਵੀ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਮਿਲਾਓ ਅਤੇ ਤੁਹਾਡੇ ਲੌਗਸ ਨੂੰ ਬੇਕਾਰ ਦੀ ਇੱਕ ਵੱਡੀ ਬਲਦੀ ਗੇਂਦ ਵਿੱਚ ਰੱਦੀ ਨਾ ਬਣਨ ਦਿਓ। ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਸਮਝਾਓ ਅਤੇ ਦਿਖਾਓ ਕਿ ਕੋਈ ਹੋਰ ਉਹਨਾਂ ਦੇ ਲੌਗਸ ਨੂੰ ਕਿਉਂ ਨਹੀਂ ਸਮਝੇਗਾ, ਉਹਨਾਂ ਨੂੰ ਦਿਖਾਓ ਕਿ ਸਵੇਰੇ 3:15 ਵਜੇ ਬੇਕਾਰ ਲੌਗਾਂ ਨੂੰ ਦੇਖਣਾ ਕਿਹੋ ਜਿਹਾ ਹੈ।

ਫੋਟੋ ਦੇ ਲੇਖਕ ਮਾਰਕੋ ਹੋਰਵਤ 'ਤੇ Unsplash

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

ਸਰੋਤ: www.habr.com