ਕੀ ਨਿਗਰਾਨੀ ਮਰ ਗਈ ਹੈ? - ਲੰਬੀ ਲਾਈਵ ਨਿਗਰਾਨੀ

2008 ਤੋਂ, ਸਾਡੀ ਕੰਪਨੀ ਮੁੱਖ ਤੌਰ 'ਤੇ ਵੈੱਬ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਪ੍ਰਬੰਧਨ ਅਤੇ ਚੌਵੀ ਘੰਟੇ ਤਕਨੀਕੀ ਸਹਾਇਤਾ ਵਿੱਚ ਰੁੱਝੀ ਹੋਈ ਹੈ: ਸਾਡੇ ਕੋਲ 400 ਤੋਂ ਵੱਧ ਗਾਹਕ ਹਨ, ਜੋ ਕਿ ਰੂਸੀ ਈ-ਕਾਮਰਸ ਦਾ ਲਗਭਗ 15% ਹੈ। ਇਸ ਅਨੁਸਾਰ, ਇੱਕ ਬਹੁਤ ਹੀ ਵਿਭਿੰਨ ਆਰਕੀਟੈਕਚਰ ਸਮਰਥਿਤ ਹੈ. ਜੇਕਰ ਕੁਝ ਡਿੱਗਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਇਸਨੂੰ 15 ਮਿੰਟਾਂ ਦੇ ਅੰਦਰ ਠੀਕ ਕਰਨ ਲਈ ਮਜਬੂਰ ਹਾਂ। ਪਰ ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਇੱਕ ਦੁਰਘਟਨਾ ਵਾਪਰੀ ਹੈ, ਤੁਹਾਨੂੰ ਪ੍ਰੋਜੈਕਟ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਅਤੇ ਘਟਨਾਵਾਂ ਦਾ ਜਵਾਬ ਦੇਣ ਦੀ ਲੋੜ ਹੈ. ਇਹ ਕਿਵੇਂ ਕਰਨਾ ਹੈ?

ਮੇਰਾ ਮੰਨਣਾ ਹੈ ਕਿ ਇੱਕ ਸਹੀ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਵਿੱਚ ਇੱਕ ਸਮੱਸਿਆ ਹੈ. ਜੇਕਰ ਕੋਈ ਸਮੱਸਿਆ ਨਾ ਹੁੰਦੀ, ਤਾਂ ਮੇਰੇ ਭਾਸ਼ਣ ਵਿੱਚ ਇੱਕ ਥੀਸਿਸ ਸ਼ਾਮਲ ਹੁੰਦਾ: "ਕਿਰਪਾ ਕਰਕੇ ਪ੍ਰੋਮੀਥੀਅਸ + ਗ੍ਰਾਫਾਨਾ ਅਤੇ ਪਲੱਗਇਨ 1, 2, 3 ਨੂੰ ਸਥਾਪਿਤ ਕਰੋ।" ਬਦਕਿਸਮਤੀ ਨਾਲ, ਇਹ ਹੁਣ ਇਸ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਨਹੀਂ ਕਰਦਾ। ਅਤੇ ਮੁੱਖ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਹਰ ਕੋਈ ਅਜਿਹੀ ਚੀਜ਼ ਵਿੱਚ ਵਿਸ਼ਵਾਸ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦਾ ਹੈ ਜੋ 2008 ਵਿੱਚ ਮੌਜੂਦ ਸੀ, ਸਾਫਟਵੇਅਰ ਭਾਗਾਂ ਦੇ ਰੂਪ ਵਿੱਚ.

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

ਅਸੀਂ ਸਾਰਿਆਂ ਨੇ ਹੇਠ ਲਿਖੀਆਂ ਕਹਾਣੀਆਂ ਦਾ ਸਾਹਮਣਾ ਕੀਤਾ ਹੈ: ਇੱਕ ਖਾਸ ਡਿਵੋਪਸ, ਇੱਕ ਖਾਸ ਪ੍ਰਬੰਧਕ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਇੱਕ ਵਿਕਾਸ ਟੀਮ ਉਹਨਾਂ ਕੋਲ ਆਉਂਦੀ ਹੈ ਅਤੇ ਕਹਿੰਦੀ ਹੈ - "ਸਾਨੂੰ ਰਿਹਾ ਕੀਤਾ ਗਿਆ ਹੈ, ਹੁਣ ਨਿਗਰਾਨੀ ਕਰੋ।" ਕੀ ਨਿਗਰਾਨੀ? ਕਿਦਾ ਚਲਦਾ?

ਠੀਕ ਹੈ. ਅਸੀਂ ਪੁਰਾਣੇ ਢੰਗ ਨਾਲ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹਾਂ. ਅਤੇ ਇਹ ਪਹਿਲਾਂ ਹੀ ਬਦਲ ਰਿਹਾ ਹੈ, ਅਤੇ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਸੇਵਾ A ਦੀ ਨਿਗਰਾਨੀ ਕੀਤੀ ਹੈ, ਜੋ ਸੇਵਾ B ਬਣ ਗਈ, ਜੋ ਸੇਵਾ C ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਦੀ ਹੈ। ਪਰ ਵਿਕਾਸ ਟੀਮ ਤੁਹਾਨੂੰ ਦੱਸਦੀ ਹੈ: "ਸਾਫਟਵੇਅਰ ਸਥਾਪਤ ਕਰੋ, ਇਸ ਨੂੰ ਹਰ ਚੀਜ਼ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ!"

ਤਾਂ ਕੀ ਬਦਲਿਆ ਹੈ? - ਸਭ ਕੁਝ ਬਦਲ ਗਿਆ ਹੈ!

2008 ਸਭ ਕੁਝ ਠੀਕ ਹੈ

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

ਜੇ ਅਸੀਂ ਨਿਗਰਾਨੀ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਪ੍ਰਸ਼ਾਸਕ ਦੁਆਰਾ ਕੀਤੇ ਗਏ ਕੰਮ ਦੀ ਮਾਤਰਾ ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਇਸਦਾ 98% ਆਟੋਮੈਟਿਕ ਸੀ: ਨਿਗਰਾਨੀ ਕਰਨ ਵਾਲੇ ਵਿਅਕਤੀ ਨੂੰ ਇਹ ਸਮਝਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਜ਼ੈਬਿਕਸ ਨੂੰ ਕਿਵੇਂ ਸਥਾਪਿਤ ਕਰਨਾ ਹੈ, ਇਸਨੂੰ ਕਿਵੇਂ ਸੰਰਚਿਤ ਕਰਨਾ ਹੈ ਅਤੇ ਚੇਤਾਵਨੀਆਂ ਨੂੰ ਕਿਵੇਂ ਸੰਰਚਿਤ ਕਰਨਾ ਹੈ। ਅਤੇ 2% - ਬਾਹਰੀ ਜਾਂਚਾਂ ਲਈ: ਕਿ ਸਾਈਟ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਅਤੇ ਡੇਟਾਬੇਸ ਨੂੰ ਬੇਨਤੀ ਕਰਦੀ ਹੈ, ਕਿ ਨਵੇਂ ਆਰਡਰ ਆ ਗਏ ਹਨ।

2010 ਭਾਰ ਵਧ ਰਿਹਾ ਹੈ

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

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

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

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

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

ਪਰ ਸ਼ਾਇਦ ਹੀ ਕੋਈ 10 ਸਾਲਾਂ ਲਈ ਕਿਸੇ ਪ੍ਰੋਜੈਕਟ ਦੇ ਨਾਲ ਜਾਂਦਾ ਹੈ।

ਮਾਨੀਟਰਿੰਗਮੈਨ ਦਾ ਰੈਜ਼ਿਊਮੇ

ਮੰਨ ਲਓ ਕਿ ਤੁਸੀਂ ਇੱਕ ਨਵੇਂ ਸਟਾਰਟਅਪ 'ਤੇ ਆਏ ਹੋ ਜਿਸ ਨੇ ਤੁਰੰਤ 20 ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਨਿਯੁਕਤ ਕੀਤਾ, 15 ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਲਿਖੀਆਂ, ਅਤੇ ਤੁਸੀਂ ਇੱਕ ਐਡਮਿਨ ਹੋ ਜਿਸ ਨੂੰ ਕਿਹਾ ਗਿਆ ਹੈ: "CI/CD ਬਣਾਓ। ਕ੍ਰਿਪਾ." ਤੁਸੀਂ CI/CD ਬਣਾਈ ਹੈ ਅਤੇ ਅਚਾਨਕ ਤੁਸੀਂ ਸੁਣਦੇ ਹੋ: "ਸਾਡੇ ਲਈ "ਘਣ" ਵਿੱਚ ਉਤਪਾਦਨ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ, ਇਹ ਸਮਝੇ ਬਿਨਾਂ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਇਸ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰੇਗੀ। ਸਾਨੂੰ ਉਸੇ "ਕਿਊਬ" ਵਿੱਚ ਇੱਕ ਸੈਂਡਬੌਕਸ ਬਣਾਓ।
ਤੁਸੀਂ ਇਸ ਘਣ ਵਿੱਚ ਇੱਕ ਸੈਂਡਬੌਕਸ ਬਣਾਉ। ਉਹ ਤੁਰੰਤ ਤੁਹਾਨੂੰ ਦੱਸਦੇ ਹਨ: "ਅਸੀਂ ਇੱਕ ਪੜਾਅ ਡੇਟਾਬੇਸ ਚਾਹੁੰਦੇ ਹਾਂ ਜੋ ਉਤਪਾਦਨ ਤੋਂ ਹਰ ਰੋਜ਼ ਅੱਪਡੇਟ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਜੋ ਅਸੀਂ ਸਮਝ ਸਕੀਏ ਕਿ ਇਹ ਡੇਟਾਬੇਸ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਉਸੇ ਸਮੇਂ ਉਤਪਾਦਨ ਡੇਟਾਬੇਸ ਨੂੰ ਖਰਾਬ ਨਾ ਕਰੋ."

ਤੁਸੀਂ ਇਸ ਸਭ ਵਿੱਚ ਰਹਿੰਦੇ ਹੋ। ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ 2 ਹਫ਼ਤੇ ਬਾਕੀ ਹਨ, ਉਹ ਤੁਹਾਨੂੰ ਦੱਸਦੇ ਹਨ: "ਆਓ ਹੁਣ ਇਸ ਸਭ ਦੀ ਨਿਗਰਾਨੀ ਕਰੀਏ..." ਯਾਨੀ. ਕਲੱਸਟਰ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ, ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਆਰਕੀਟੈਕਚਰ ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ, ਬਾਹਰੀ ਸੇਵਾਵਾਂ ਦੇ ਨਾਲ ਕੰਮ ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ...

ਅਤੇ ਮੇਰੇ ਸਾਥੀ ਆਮ ਸਕੀਮ ਨੂੰ ਆਪਣੇ ਸਿਰਾਂ ਤੋਂ ਬਾਹਰ ਕੱਢ ਲੈਂਦੇ ਹਨ ਅਤੇ ਕਹਿੰਦੇ ਹਨ: “ਠੀਕ ਹੈ, ਇੱਥੇ ਸਭ ਕੁਝ ਸਪੱਸ਼ਟ ਹੈ! ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਸਥਾਪਿਤ ਕਰੋ ਜੋ ਇਸ ਸਭ ਦੀ ਨਿਗਰਾਨੀ ਕਰੇਗਾ।" ਹਾਂ, ਹਾਂ: Prometheus + Grafana + ਪਲੱਗਇਨ।
ਅਤੇ ਉਹ ਜੋੜਦੇ ਹਨ: "ਤੁਹਾਡੇ ਕੋਲ ਦੋ ਹਫ਼ਤੇ ਹਨ, ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਸਭ ਕੁਝ ਸੁਰੱਖਿਅਤ ਹੈ।"

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

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

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

ਪਰ ਇਸਦੀ ਕਿਸੇ ਤਰ੍ਹਾਂ ਨਿਗਰਾਨੀ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ...

ਨਤੀਜਾ ਕੀ ਨਿਕਲਿਆ? ਨਤੀਜੇ ਵਜੋਂ, ਇੱਕ ਵਿਅਕਤੀ ਹੈ ਜੋ ਹਰ ਚੀਜ਼ ਦੇ ਨਾਲ ਆਉਂਦਾ ਹੈ ਜੋ ਡਿਵੈਲਪਰਾਂ ਦੀ ਪੂਰੀ ਟੀਮ ਨਹੀਂ ਸਮਝ ਸਕਦੀ, ਅਤੇ ਉਸੇ ਸਮੇਂ ਉਸਨੂੰ ਇਹ ਵੀ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਉਹ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਅਸੀਂ ਉੱਪਰ ਦਰਸਾਏ ਹਨ - ਹਾਰਡਵੇਅਰ ਬੁਨਿਆਦੀ ਢਾਂਚਾ, ਕੁਬਰਨੇਟਸ ਬੁਨਿਆਦੀ ਢਾਂਚਾ, ਆਦਿ।

ਮੈਂ ਕੀ ਕਹਿ ਸਕਦਾ ਹਾਂ... ਹਿਊਸਟਨ, ਸਾਨੂੰ ਸਮੱਸਿਆਵਾਂ ਹਨ।

ਇੱਕ ਆਧੁਨਿਕ ਸਾਫਟਵੇਅਰ ਪ੍ਰੋਜੈਕਟ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨਾ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇੱਕ ਸਾਫਟਵੇਅਰ ਪ੍ਰੋਜੈਕਟ ਹੈ

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

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

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

ਇਸ ਲਈ ਸ਼ੁਰੂ ਤੋਂ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੇ ਪ੍ਰੋਜੈਕਟ ਦੀ ਨਿਗਰਾਨੀ ਕਿਵੇਂ ਕਰੀਏ, ਅਤੇ ਕੀ ਕਰਨਾ ਹੈ ਜੇਕਰ ਤੁਹਾਨੂੰ ਕੋਈ ਅਜਿਹਾ ਪ੍ਰੋਜੈਕਟ ਮਿਲਦਾ ਹੈ ਜਿਸਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਕਿੱਥੇ ਸ਼ੁਰੂ ਕਰਨਾ ਹੈ?

ਪਹਿਲੀ, ਤੁਹਾਨੂੰ ਯੋਜਨਾ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ.

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

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

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

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

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

ਪੱਧਰਾਂ ਦੁਆਰਾ ਹਰ ਚੀਜ਼

ਇਸ ਤਰ੍ਹਾਂ ਮੈਂ ਇੱਕ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਦੇ ਸੰਗਠਨ ਨੂੰ ਵੇਖਦਾ ਹਾਂ.

1) ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰ:

• ਨਿਗਰਾਨੀ ਐਪਲੀਕੇਸ਼ਨ ਕਾਰੋਬਾਰੀ ਤਰਕ;
• ਸੇਵਾਵਾਂ ਦੇ ਸਿਹਤ ਮਾਪਦੰਡਾਂ ਦੀ ਨਿਗਰਾਨੀ;
• ਏਕੀਕਰਣ ਨਿਗਰਾਨੀ.

2) ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਪੱਧਰ:

• ਆਰਕੈਸਟਰੇਸ਼ਨ ਪੱਧਰ ਦੀ ਨਿਗਰਾਨੀ;
• ਸਿਸਟਮ ਸਾਫਟਵੇਅਰ ਨਿਗਰਾਨੀ;
• ਲੋਹੇ ਦੇ ਪੱਧਰ ਦੀ ਨਿਗਰਾਨੀ.

3) ਦੁਬਾਰਾ ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰ - ਪਰ ਇੱਕ ਇੰਜੀਨੀਅਰਿੰਗ ਉਤਪਾਦ ਵਜੋਂ:

• ਐਪਲੀਕੇਸ਼ਨ ਲੌਗਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ ਅਤੇ ਨਿਗਰਾਨੀ ਕਰਨਾ;
• APM;
• ਟਰੇਸਿੰਗ

4) ਚੇਤਾਵਨੀ:

• ਇੱਕ ਚੇਤਾਵਨੀ ਸਿਸਟਮ ਦਾ ਸੰਗਠਨ;
• ਇੱਕ ਡਿਊਟੀ ਸਿਸਟਮ ਦਾ ਸੰਗਠਨ;
• ਇੱਕ "ਗਿਆਨ ਅਧਾਰ" ਦਾ ਸੰਗਠਨ ਅਤੇ ਘਟਨਾ ਦੀ ਪ੍ਰਕਿਰਿਆ ਲਈ ਵਰਕਫਲੋ।

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

ਐਪਲੀਕੇਸ਼ਨ ਲੇਅਰ - ਕਾਰੋਬਾਰੀ ਤਰਕ ਨਿਗਰਾਨੀ

ਇੱਥੇ ਅਸੀਂ ਇਸ ਤੱਥ ਦੀ ਜਾਂਚ ਕਰਨ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਉਪਭੋਗਤਾ ਲਈ ਕੰਮ ਕਰਦੀ ਹੈ.

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

ਜਦੋਂ ਅਕਸਰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਹੋਮ ਪੇਜ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਕਿ ਸਾਈਟ ਕੰਮ ਕਰ ਰਹੀ ਹੈ, ਤਾਂ ਪ੍ਰੋਗਰਾਮਰ ਇੱਕ ਹੈਂਡਲ ਦਿੰਦੇ ਹਨ ਜੋ ਹਰ ਵਾਰ ਖਿੱਚਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜਦੋਂ ਉਹਨਾਂ ਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਲੋੜ ਹੁੰਦੀ ਹੈ ਕਿ API ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਅਤੇ ਇਸ ਸਮੇਂ ਪ੍ਰੋਗਰਾਮਰ ਅਜੇ ਵੀ /api/test/helloworld ਲੈਂਦੇ ਹਨ ਅਤੇ ਲਿਖਦੇ ਹਨ
ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦਾ ਇੱਕੋ ਇੱਕ ਤਰੀਕਾ ਹੈ ਕਿ ਸਭ ਕੁਝ ਕੰਮ ਕਰਦਾ ਹੈ? - ਨਹੀਂ!

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

ਤਕਨੀਕੀ ਸੁਝਾਅ:

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

ਐਪਲੀਕੇਸ਼ਨ ਪਰਤ - ਸਿਹਤ ਮੈਟ੍ਰਿਕਸ ਦੀ ਨਿਗਰਾਨੀ

ਹੁਣ ਅਸੀਂ ਸੇਵਾਵਾਂ ਦੇ ਬਾਹਰੀ ਸਿਹਤ ਮਾਪਦੰਡਾਂ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ।

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

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

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

ਐਪਲੀਕੇਸ਼ਨ ਲੇਅਰ - ਏਕੀਕਰਣ ਨਿਗਰਾਨੀ

ਏਕੀਕਰਣ ਨਿਗਰਾਨੀ ਵਪਾਰ-ਨਾਜ਼ੁਕ ਪ੍ਰਣਾਲੀਆਂ ਵਿਚਕਾਰ ਸੰਚਾਰਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੈ।

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

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

ਮੈਂ ਕੀ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹਾਂ:

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

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

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

ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਪੱਧਰ

ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਨਿਗਰਾਨੀ ਉਹ ਚੀਜ਼ ਹੈ ਜਿਸ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਆਪਣੇ ਆਪ ਨੂੰ ਨਿਗਰਾਨੀ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ.

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

ਬਿਜ਼ਨਸ ਯੂਨਿਟ ਦੇ ਤੌਰ 'ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰ

ਮੁੱਖ ਨੁਕਤੇ:

• ELK. ਇਹ ਉਦਯੋਗ ਦਾ ਮਿਆਰ ਹੈ. ਜੇਕਰ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਤੁਸੀਂ ਲੌਗਸ ਨੂੰ ਇਕੱਠਾ ਨਹੀਂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਰੰਤ ਅਜਿਹਾ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੋ।
• ਏ.ਪੀ.ਐਮ. ਐਪਲੀਕੇਸ਼ਨ ਨਿਗਰਾਨੀ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਬੰਦ ਕਰਨ ਦੇ ਤਰੀਕੇ ਵਜੋਂ ਬਾਹਰੀ APM (NewRelic, BlackFire, Datadog)। ਤੁਸੀਂ ਇਸ ਚੀਜ਼ ਨੂੰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਸਥਾਪਤ ਕਰ ਸਕਦੇ ਹੋ ਤਾਂ ਕਿ ਘੱਟੋ-ਘੱਟ ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਤੁਹਾਡੇ ਨਾਲ ਕੀ ਹੋ ਰਿਹਾ ਹੈ।
• ਟਰੇਸਿੰਗ। ਦਰਜਨਾਂ ਮਾਈਕ੍ਰੋਸਰਵਿਸਾਂ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਹਰ ਚੀਜ਼ ਨੂੰ ਟਰੇਸ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਬੇਨਤੀ ਹੁਣ ਆਪਣੇ ਆਪ ਨਹੀਂ ਰਹਿੰਦੀ। ਬਾਅਦ ਵਿੱਚ ਜੋੜਨਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ, ਇਸਲਈ ਵਿਕਾਸ ਵਿੱਚ ਟਰੇਸਿੰਗ ਨੂੰ ਤੁਰੰਤ ਤਹਿ ਕਰਨਾ ਬਿਹਤਰ ਹੈ - ਇਹ ਡਿਵੈਲਪਰਾਂ ਦਾ ਕੰਮ ਅਤੇ ਉਪਯੋਗਤਾ ਹੈ. ਜੇਕਰ ਤੁਸੀਂ ਅਜੇ ਤੱਕ ਇਸਨੂੰ ਲਾਗੂ ਨਹੀਂ ਕੀਤਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਲਾਗੂ ਕਰੋ! ਜੇਗਰ/ਜ਼ਿਪਕਿਨ ਦੇਖੋ

ਚੇਤਾਵਨੀ

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

ਤਕਨਾਲੋਜੀ ਸਟੈਕ

ਚਲੋ ਕਲਪਨਾ ਕਰੀਏ ਕਿ ਸਾਡਾ ਸਟੈਕ ਇਸ ਤਰ੍ਹਾਂ ਹੈ:

• ਡਾਟਾ ਸੰਗ੍ਰਹਿ - ਪ੍ਰੋਮੀਥੀਅਸ + ਗ੍ਰਾਫਾਨਾ;
• ਲੌਗ ਵਿਸ਼ਲੇਸ਼ਣ - ELK;
• APM ਜਾਂ ਟਰੇਸਿੰਗ ਲਈ - ਜੈਗਰ (ਜ਼ਿਪਕਿਨ)।

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

ਕੁਝ ਤਕਨੀਕੀ ਨੁਕਤੇ ਜੋ ਮੈਂ ਹਾਲ ਹੀ ਵਿੱਚ ਹਰ ਥਾਂ ਵੇਖਦਾ ਹਾਂ:

ਪ੍ਰੋਮੀਥੀਅਸ ਨੂੰ ਕੁਬਰਨੇਟਸ ਦੇ ਅੰਦਰ ਧੱਕਿਆ ਜਾ ਰਿਹਾ ਹੈ - ਇਸ ਨਾਲ ਕੌਣ ਆਇਆ?! ਜੇਕਰ ਤੁਹਾਡਾ ਕਲੱਸਟਰ ਕਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਕੀ ਕਰੋਗੇ? ਜੇਕਰ ਤੁਹਾਡੇ ਅੰਦਰ ਇੱਕ ਗੁੰਝਲਦਾਰ ਕਲੱਸਟਰ ਹੈ, ਤਾਂ ਕਲੱਸਟਰ ਦੇ ਅੰਦਰ ਕੁਝ ਕਿਸਮ ਦੀ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਕੁਝ ਬਾਹਰ, ਜੋ ਕਿ ਕਲੱਸਟਰ ਦੇ ਅੰਦਰੋਂ ਡਾਟਾ ਇਕੱਠਾ ਕਰੇਗੀ।

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

ਸਿੱਟਾ

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

ਇਹ ਸੇਂਟ ਹਾਈਲੋਡ++ ਕਾਨਫਰੰਸ ਵਿੱਚ ਰਿਪੋਰਟ ਦਾ ਇੱਕ ਵਿਸਤ੍ਰਿਤ ਸੰਸਕਰਣ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਅਤੇ ਸੰਬੰਧਿਤ ਵਿਸ਼ਿਆਂ 'ਤੇ ਮੇਰੇ ਵਿਚਾਰਾਂ ਅਤੇ ਵਿਚਾਰਾਂ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇੱਥੇ ਕਰ ਸਕਦੇ ਹੋ ਚੈਨਲ ਪੜ੍ਹੋ 🙂

ਸਰੋਤ: www.habr.com