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

ਸਰੋਤ

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

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

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

"ਸਮੱਸਿਆ ਦਾ ਗਠਨ"

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

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

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

ਕੰਮ ਨੂੰ ਦੋ ਭਾਗਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ:

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

ਮੈਟ੍ਰਿਕਸ ਦੀ ਨਿਗਰਾਨੀ ਅਤੇ ਇਕੱਤਰ ਕਰਨ ਲਈ ਸੰਦ

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

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

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

ਸਰੋਤ. ਸਿਸਟਮ ਦੇ ਭਾਗਾਂ ਵਿਚਕਾਰ ਸਾਰੀਆਂ ਨਿਰਭਰਤਾਵਾਂ ਦਾ ਆਟੋਮੈਟਿਕ ਨਿਰਮਾਣ

ਸਰੋਤ. ਆਟੋਮੈਟਿਕ ਖੋਜ ਅਤੇ ਸੇਵਾ ਸੰਚਾਲਨ ਮਾਰਗ ਦਾ ਨਿਰਮਾਣ

ਸਾਨੂੰ ਇਹ ਵੀ ਯਾਦ ਹੈ ਕਿ ਸਾਨੂੰ ਵੱਖ-ਵੱਖ ਆਟੋਮੇਸ਼ਨ ਟੂਲਸ ਨਾਲ ਏਕੀਕ੍ਰਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਇੱਥੇ ਹੱਲ ਵਿੱਚ ਇੱਕ ਸੁਵਿਧਾਜਨਕ API ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਵੱਖ-ਵੱਖ ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਇਵੈਂਟਾਂ ਨੂੰ ਭੇਜਣ ਅਤੇ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

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

ਟਾਸਕ 1. ਟੈਸਟਿੰਗ ਪੜਾਅ 'ਤੇ ਅਸੈਂਬਲੀਆਂ ਦੇ ਗੁਣਵੱਤਾ ਨਿਯੰਤਰਣ ਦਾ ਸਵੈਚਾਲਨ

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

ਆਉ ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਅਤੇ ਇਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰਨ ਦੇ ਤਰੀਕੇ ਬਾਰੇ ਇੱਕ ਕਦਮ-ਦਰ-ਕਦਮ ਦੇਖੀਏ:

ਸਰੋਤ

ਚਿੱਤਰ ਸਵੈਚਲਿਤ ਸੌਫਟਵੇਅਰ ਗੁਣਵੱਤਾ ਜਾਂਚ ਦੇ ਕਦਮਾਂ ਦੇ ਪ੍ਰਵਾਹ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ:

1. ਇੱਕ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਦੀ ਤਾਇਨਾਤੀ (ਏਜੰਟਾਂ ਦੀ ਸਥਾਪਨਾ);
2. ਤੁਹਾਡੇ ਸੌਫਟਵੇਅਰ (ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਥ੍ਰੈਸ਼ਹੋਲਡ ਮੁੱਲ) ਦੀ ਗੁਣਵੱਤਾ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ ਲਈ ਘਟਨਾਵਾਂ ਦੀ ਪਛਾਣ ਕਰਨਾ;
3. ਲੋਡ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਟੈਸਟਾਂ ਦੀ ਪੀੜ੍ਹੀ;
4. ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਉਪਲਬਧਤਾ ਡੇਟਾ ਇਕੱਠਾ ਕਰਨਾ;
5. ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਤੋਂ CI/CD ਸਿਸਟਮ ਵਿੱਚ ਸਾਫਟਵੇਅਰ ਗੁਣਵੱਤਾ ਮੁਲਾਂਕਣ ਇਵੈਂਟਾਂ ਦੇ ਅਧਾਰ ਤੇ ਟੈਸਟ ਡੇਟਾ ਦਾ ਤਬਾਦਲਾ। ਅਸੈਂਬਲੀਆਂ ਦਾ ਆਟੋਮੈਟਿਕ ਵਿਸ਼ਲੇਸ਼ਣ.

ਕਦਮ 1. ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਦੀ ਤੈਨਾਤੀ

ਪਹਿਲਾਂ ਤੁਹਾਨੂੰ ਆਪਣੇ ਟੈਸਟ ਵਾਤਾਵਰਨ ਵਿੱਚ ਏਜੰਟਾਂ ਨੂੰ ਸਥਾਪਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਉਸੇ ਸਮੇਂ, ਡਾਇਨਾਟ੍ਰੈਸ ਹੱਲ ਵਿੱਚ ਇੱਕ ਵਧੀਆ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ - ਇਹ ਯੂਨੀਵਰਸਲ ਏਜੰਟ OneAgent ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਜੋ ਇੱਕ OS ਉਦਾਹਰਣ (ਵਿੰਡੋਜ਼, ਲੀਨਕਸ, ਏਆਈਐਕਸ) 'ਤੇ ਸਥਾਪਤ ਹੁੰਦਾ ਹੈ, ਤੁਹਾਡੀਆਂ ਸੇਵਾਵਾਂ ਨੂੰ ਆਪਣੇ ਆਪ ਖੋਜਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ 'ਤੇ ਨਿਗਰਾਨੀ ਡੇਟਾ ਇਕੱਠਾ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਹਰੇਕ ਪ੍ਰਕਿਰਿਆ ਲਈ ਵੱਖਰੇ ਏਜੰਟ ਦੀ ਸੰਰਚਨਾ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਸਥਿਤੀ ਕਲਾਉਡ ਅਤੇ ਕੰਟੇਨਰ ਪਲੇਟਫਾਰਮਾਂ ਲਈ ਸਮਾਨ ਹੋਵੇਗੀ। ਇਸ ਦੇ ਨਾਲ ਹੀ, ਤੁਸੀਂ ਏਜੰਟ ਦੀ ਸਥਾਪਨਾ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਵੀ ਸਵੈਚਾਲਿਤ ਕਰ ਸਕਦੇ ਹੋ। ਡਾਇਨੈਟਰੇਸ "ਕੋਡ ਦੇ ਰੂਪ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚੇ" ਸੰਕਲਪ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਫਿੱਟ ਹੈ (ਕੋਡ ਜਾਂ IaC ਦੇ ਰੂਪ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚਾ): ਸਾਰੇ ਪ੍ਰਸਿੱਧ ਪਲੇਟਫਾਰਮਾਂ ਲਈ ਤਿਆਰ ਸਕ੍ਰਿਪਟਾਂ ਅਤੇ ਨਿਰਦੇਸ਼ ਹਨ। ਤੁਸੀਂ ਏਜੰਟ ਨੂੰ ਆਪਣੀ ਸੇਵਾ ਦੀ ਸੰਰਚਨਾ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਦੇ ਹੋ, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਤੈਨਾਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਤੁਰੰਤ ਇੱਕ ਪਹਿਲਾਂ ਤੋਂ ਕੰਮ ਕਰਨ ਵਾਲੇ ਏਜੰਟ ਨਾਲ ਇੱਕ ਨਵੀਂ ਸੇਵਾ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ।

ਕਦਮ 2: ਆਪਣੇ ਸੌਫਟਵੇਅਰ ਗੁਣਵੱਤਾ ਸਮਾਗਮਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ

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

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

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

ਆਉ ਅਜਿਹੀ JSON ਫਾਈਲ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਵੇਖੀਏ. Dynatrace API ਤੋਂ ਵਸਤੂਆਂ ਨੂੰ ਕੁੰਜੀ/ਮੁੱਲ ਜੋੜਿਆਂ ਵਜੋਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ (API ਵਰਣਨ ਇੱਥੇ ਪਾਇਆ ਜਾ ਸਕਦਾ ਹੈ Dynatrace API).

{
    "timeseries": [
    {
      "timeseriesId": "service.ResponseTime",
      "aggregation": "avg",
      "tags": "Frontend",
      "severe": 250000,
      "warning": 1000000
    },
    {
      "timeseriesId": "service.ResponseTime ",
      "aggregation": "avg",
      "tags": "Backend",
      "severe": 4000000,
      "warning": 8000000
    },
    {
      "timeseriesId": "docker.Container.Cpu",
      "aggregation": "avg",
      "severe": 50,
      "warning": 70
    }
  ]
}

ਫਾਈਲ ਟਾਈਮ ਸੀਰੀਜ਼ ਪਰਿਭਾਸ਼ਾਵਾਂ ਦੀ ਇੱਕ ਐਰੇ ਹੈ:

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

ਹੇਠਲਾ ਚਿੱਤਰ ਅਜਿਹੇ ਥ੍ਰੈਸ਼ਹੋਲਡ ਦੀ ਵਰਤੋਂ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਦਿਖਾਉਂਦਾ ਹੈ।

ਸਰੋਤ

ਕਦਮ 3: ਲੋਡ ਜਨਰੇਸ਼ਨ

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

Dynatrace ਦੀ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਤੁਹਾਨੂੰ ਤੁਹਾਡੇ ਟੈਸਟਾਂ ਤੋਂ ਵੱਖ-ਵੱਖ ਮੈਟਾਡੇਟਾ ਹਾਸਲ ਕਰਨ ਅਤੇ ਇਹ ਪਛਾਣ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ ਕਿ ਕਿਹੜੇ ਟੈਸਟ ਕਿਹੜੇ ਰੀਲੀਜ਼ ਚੱਕਰ ਅਤੇ ਕਿਹੜੀ ਸੇਵਾ ਨਾਲ ਸਬੰਧਤ ਹਨ। HTTP ਟੈਸਟ ਬੇਨਤੀਆਂ ਵਿੱਚ ਵਾਧੂ ਸਿਰਲੇਖ ਜੋੜਨ ਦੀ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਹੇਠਾਂ ਦਿੱਤਾ ਚਿੱਤਰ ਇੱਕ ਉਦਾਹਰਨ ਦਿਖਾਉਂਦਾ ਹੈ ਜਿੱਥੇ, ਵਾਧੂ ਸਿਰਲੇਖ X-Dynatrace-Test ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਸੰਕੇਤ ਦਿੰਦੇ ਹਾਂ ਕਿ ਇਹ ਟੈਸਟ ਕਾਰਟ ਵਿੱਚ ਇੱਕ ਆਈਟਮ ਨੂੰ ਜੋੜਨ ਦੇ ਸੰਚਾਲਨ ਦੀ ਜਾਂਚ ਨਾਲ ਸਬੰਧਤ ਹੈ।

ਸਰੋਤ

ਜਦੋਂ ਤੁਸੀਂ ਹਰੇਕ ਲੋਡ ਟੈਸਟ ਨੂੰ ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ CI/CD ਸਰਵਰ ਤੋਂ ਇਵੈਂਟ API ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਡਾਇਨਾਟ੍ਰੇਸ ਨੂੰ ਵਾਧੂ ਪ੍ਰਸੰਗਿਕ ਜਾਣਕਾਰੀ ਭੇਜਦੇ ਹੋ। ਇਸ ਤਰ੍ਹਾਂ, ਸਿਸਟਮ ਵੱਖ-ਵੱਖ ਟੈਸਟਾਂ ਵਿਚਕਾਰ ਫਰਕ ਕਰ ਸਕਦਾ ਹੈ।

ਸਰੋਤ. ਲੋਡ ਟੈਸਟਿੰਗ ਦੀ ਸ਼ੁਰੂਆਤ ਬਾਰੇ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਇਵੈਂਟ

ਕਦਮ 4-5। ਪ੍ਰਦਰਸ਼ਨ ਡੇਟਾ ਇਕੱਠਾ ਕਰੋ ਅਤੇ ਸੀਆਈ/ਸੀਡੀ ਸਿਸਟਮ ਵਿੱਚ ਡੇਟਾ ਟ੍ਰਾਂਸਫਰ ਕਰੋ

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

ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਨੂੰ ਭੇਜਣ ਲਈ CI/CD ਸਰਵਰ 'ਤੇ ਤਿਆਰ ਕੀਤੇ ਸੌਫਟਵੇਅਰ ਦੀ ਗੁਣਵੱਤਾ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਬਾਰੇ ਘਟਨਾ

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

ਇੱਕ ਬਿਲਡ ਗੁਣਵੱਤਾ ਜਾਂਚ ਦੀ ਸ਼ੁਰੂਆਤ ਬਾਰੇ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਇਵੈਂਟ। ਸਰੋਤ

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

CI/CD ਸਰਵਰ 'ਤੇ ਅਸੈਂਬਲੀਆਂ ਦੇ ਅੰਕੜਿਆਂ ਦਾ ਨਤੀਜਾ। ਸਰੋਤ

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

CI/CD ਸਰਵਰ 'ਤੇ ਅਸੈਂਬਲੀਆਂ ਦੇ ਵਿਸਤ੍ਰਿਤ ਅੰਕੜੇ ਵੇਖੋ। ਸਰੋਤ

ਦੋ ਅਸੈਂਬਲੀਆਂ ਦੀ ਵਿਸਤ੍ਰਿਤ ਤੁਲਨਾ

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

ਡਾਇਨਟ੍ਰੈਸ ਵਿੱਚ ਬਿਲਡ ਅੰਕੜਿਆਂ ਦੀ ਤੁਲਨਾ। ਸਰੋਤ
 
ਸਿੱਟਾ

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

ਟਾਸਕ 2. ਇੱਕ ਉਤਪਾਦਨ ਵਾਤਾਵਰਣ ਵਿੱਚ ਸਾਫਟਵੇਅਰ ਗੁਣਵੱਤਾ ਨਿਯੰਤਰਣ ਦਾ ਆਟੋਮੇਸ਼ਨ

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

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

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

ਕੋਡ ਦੇ ਤੌਰ 'ਤੇ ਸਵੈਚਲਿਤ ਕਰੋ

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

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

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

ਤੁਹਾਡੀ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਤੋਂ ਕੋਈ ਵੀ ਮੈਟ੍ਰਿਕ ਸਕ੍ਰਿਪਟ ਨੂੰ ਲਾਂਚ ਕਰਨ ਲਈ ਇੱਕ ਟਰਿੱਗਰ ਵਜੋਂ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ, ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਹ ਮੈਟ੍ਰਿਕਸ ਸਹੀ ਢੰਗ ਨਾਲ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਸਭ ਕੁਝ ਬੁਰਾ ਹੈ, ਕਿਉਂਕਿ ਤੁਸੀਂ ਇੱਕ ਉਤਪਾਦਕ ਵਾਤਾਵਰਣ ਵਿੱਚ ਗਲਤ ਸਕਾਰਾਤਮਕ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰਨਾ ਚਾਹੋਗੇ।

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

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਐਪਲੀਕੇਸ਼ਨ ਓਪਰੇਸ਼ਨ ਦੇ ਰੂਪ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਨਾਲ ਸਬੰਧਤ ਸਭ ਕੁਝ ਹੈ. ਹੱਲ ਵੱਖ-ਵੱਖ ਪੱਧਰਾਂ 'ਤੇ ਸੈਂਕੜੇ ਮੈਟ੍ਰਿਕਸ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਵਰਤੋਂ ਤੁਸੀਂ ਟਰਿਗਰ ਵਜੋਂ ਕਰ ਸਕਦੇ ਹੋ:

• ਉਪਭੋਗਤਾ ਪੱਧਰ (ਬ੍ਰਾਊਜ਼ਰ, ਮੋਬਾਈਲ ਐਪਲੀਕੇਸ਼ਨ, ਆਈਓਟੀ ਡਿਵਾਈਸਾਂ, ਉਪਭੋਗਤਾ ਵਿਹਾਰ, ਪਰਿਵਰਤਨ, ਆਦਿ);
• ਸੇਵਾ ਅਤੇ ਕਾਰਜਾਂ ਦਾ ਪੱਧਰ (ਪ੍ਰਦਰਸ਼ਨ, ਉਪਲਬਧਤਾ, ਗਲਤੀਆਂ, ਆਦਿ);
• ਐਪਲੀਕੇਸ਼ਨ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਪੱਧਰ (ਹੋਸਟ OS ਮੈਟ੍ਰਿਕਸ, JMX, MQ, ਵੈੱਬ-ਸਰਵਰ, ਆਦਿ);
• ਪਲੇਟਫਾਰਮ ਪੱਧਰ (ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ, ਕਲਾਉਡ, ਕੰਟੇਨਰ, ਆਦਿ)।

ਡਾਇਨਾਟ੍ਰੈਸ ਵਿੱਚ ਨਿਗਰਾਨੀ ਪੱਧਰ. ਸਰੋਤ

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

ਹੇਠਾਂ Ansible ਨਾਲ ਗੱਲਬਾਤ ਕਰਨ ਲਈ ਇੱਕ ਉਦਾਹਰਨ ਹੈ।

ਸਰੋਤ

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

1. ਖਰਾਬ ਤੈਨਾਤ - ਵਰਜਨ ਰੋਲਬੈਕ

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

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

ਤੈਨਾਤੀ ਤੋਂ ਬਾਅਦ ਸੰਚਾਲਨ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਗਿਰਾਵਟ। ਸਰੋਤ

2. 100% 'ਤੇ ਸਰੋਤ ਲੋਡਿੰਗ - ਰੂਟਿੰਗ ਵਿੱਚ ਇੱਕ ਨੋਡ ਸ਼ਾਮਲ ਕਰੋ

ਨਿਮਨਲਿਖਤ ਉਦਾਹਰਨ ਵਿੱਚ, ਨਿਗਰਾਨੀ ਸਿਸਟਮ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਇੱਕ ਭਾਗ 100% CPU ਲੋਡ ਦਾ ਅਨੁਭਵ ਕਰ ਰਿਹਾ ਹੈ।

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

ਇੱਕ ਘਟਨਾ ਤੋਂ ਬਾਅਦ ਸਕੇਲਿੰਗ

3. ਹਾਰਡ ਡਰਾਈਵ 'ਤੇ ਜਗ੍ਹਾ ਦੀ ਘਾਟ - ਡਿਸਕ ਦੀ ਸਫਾਈ

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

ਡਿਸਕ ਲੋਡ 100%
 
4. ਘੱਟ ਉਪਭੋਗਤਾ ਗਤੀਵਿਧੀ ਜਾਂ ਘੱਟ ਪਰਿਵਰਤਨ - ਨੀਲੇ ਅਤੇ ਹਰੇ ਸ਼ਾਖਾਵਾਂ ਵਿਚਕਾਰ ਬਦਲਣਾ

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

ਸਾਫਟਵੇਅਰ ਸ਼ਾਖਾਵਾਂ ਦੇ ਵਿਚਕਾਰ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਪਰਿਵਰਤਨ ਦਰ ਘਟਦੀ ਹੈ। ਸਰੋਤ

ਆਟੋਮੈਟਿਕ ਸਮੱਸਿਆ ਖੋਜ ਲਈ ਵਿਧੀ

ਅੰਤ ਵਿੱਚ, ਮੈਂ ਤੁਹਾਨੂੰ ਇੱਕ ਹੋਰ ਉਦਾਹਰਨ ਦੇਵਾਂਗਾ ਕਿ ਮੈਨੂੰ ਡਾਇਨਟ੍ਰੈਸ ਸਭ ਤੋਂ ਵੱਧ ਕਿਉਂ ਪਸੰਦ ਹੈ।

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

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

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

ਅਸਫਲਤਾ ਦੇ ਮੂਲ ਕਾਰਨ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਇੱਕ ਉਦਾਹਰਣ। ਸਰੋਤ

ਹੇਠ ਦਿੱਤੀ ਤਸਵੀਰ ਇੱਕ ਘਟਨਾ ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਤੁਹਾਡੀ ਅਰਜ਼ੀ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ।

ਉਹਨਾਂ 'ਤੇ ਸਾਰੇ ਭਾਗਾਂ ਅਤੇ ਘਟਨਾਵਾਂ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਨਾਲ ਇੱਕ ਉਭਰ ਰਹੀ ਸਮੱਸਿਆ ਦਾ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ

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

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

ਸਿੱਟਾ

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

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

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

ਸਰੋਤ

ਸਰੋਤ: www.habr.com