DevOps ਮੈਟ੍ਰਿਕਸ - ਗਣਨਾਵਾਂ ਲਈ ਡੇਟਾ ਕਿੱਥੇ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੈ

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

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

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

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

ਇਹ ਇਵਾਨ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਪੱਸ਼ਟ ਸੀ ਕਿ ਨਵਾਂ ਮੈਟ੍ਰਿਕ ਉਸੇ ਤਰ੍ਹਾਂ ਚੁੱਪਚਾਪ ਇੱਕ ਹਨੇਰੇ ਕੋਨੇ ਵਿੱਚ ਮਰ ਜਾਵੇਗਾ.

ਦਰਅਸਲ, ਇਵਾਨ ਨੇ ਸੋਚਿਆ, ਨੰਬਰ ਜਾਣ ਕੇ ਕਿਸੇ ਨੂੰ ਵੀ ਕੁਝ ਨਹੀਂ ਦੱਸਿਆ। 200 ਦਿਨ ਜਾਂ 2 ਦਿਨ - ਕੋਈ ਫਰਕ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਨੰਬਰ ਦੁਆਰਾ ਕਾਰਨ ਨਿਰਧਾਰਤ ਕਰਨਾ ਅਤੇ ਇਹ ਸਮਝਣਾ ਅਸੰਭਵ ਹੈ ਕਿ ਇਹ ਚੰਗਾ ਹੈ ਜਾਂ ਮਾੜਾ।

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

ਇਵਾਨ ਲਈ, ਇਹ ਇੱਕ ਪਾਸ ਪੜਾਅ ਸੀ. ਉਹ ਸਮਝ ਗਿਆ ਮੈਟ੍ਰਿਕਸ ਸਿਰਫ਼ ਇੱਕ ਆਮ ਲੱਕੜ ਦੇ ਸ਼ਾਸਕ ਹਨ ਮਾਪ ਲਈ, ਅਤੇ ਸਾਰੇ ਭੇਦ ਖੋਜੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ ਪ੍ਰਭਾਵ ਦੀ ਵਸਤੂ, i.e. ਇਹ ਹੈ ਕਿ ਇਹ ਮੈਟ੍ਰਿਕ ਬਣਦਾ ਹੈ।

ਇੱਕ ਔਨਲਾਈਨ ਸਟੋਰ ਲਈ, ਪ੍ਰਭਾਵ ਦਾ ਉਦੇਸ਼ ਇਸਦੇ ਗਾਹਕ ਹੋਣਗੇ ਜੋ ਪੈਸਾ ਲਿਆਉਂਦੇ ਹਨ, ਅਤੇ DevOps ਲਈ, ਇਹ ਉਹ ਟੀਮਾਂ ਹੋਣਗੀਆਂ ਜੋ ਇੱਕ ਪਾਈਪਲਾਈਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਬਣਾਉਂਦੀਆਂ ਅਤੇ ਰੋਲ ਆਊਟ ਕਰਦੀਆਂ ਹਨ।

ਇੱਕ ਦਿਨ, ਹਾਲ ਵਿੱਚ ਇੱਕ ਆਰਾਮਦਾਇਕ ਕੁਰਸੀ 'ਤੇ ਬੈਠੇ, ਇਵਾਨ ਨੇ ਧਿਆਨ ਨਾਲ ਸੋਚਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਕਿ ਉਹ DevOps ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਕਿਵੇਂ ਦੇਖਣਾ ਚਾਹੁੰਦਾ ਹੈ, ਇਸ ਤੱਥ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਕਿ ਪ੍ਰਭਾਵ ਦਾ ਉਦੇਸ਼ ਟੀਮਾਂ ਹਨ।

DevOps ਮੈਟ੍ਰਿਕਸ ਦਾ ਉਦੇਸ਼

ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਹਰ ਕੋਈ ਡਿਲੀਵਰੀ ਸਮਾਂ ਘਟਾਉਣਾ ਚਾਹੁੰਦਾ ਹੈ. 200 ਦਿਨ, ਬੇਸ਼ੱਕ, ਕੋਈ ਚੰਗਾ ਨਹੀਂ ਹੈ।

ਪਰ ਕਿਵੇਂ, ਇਹ ਸਵਾਲ ਹੈ?

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

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

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

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

DevOps ਲਈ ਡਿਲਿਵਰੀ ਸਮੇਂ ਦੀ ਗਣਨਾ ਕਿਵੇਂ ਕਰੀਏ

ਇਸਦੀ ਗਣਨਾ ਕਰਨ ਲਈ, DevOps ਪ੍ਰਕਿਰਿਆ ਅਤੇ ਇਸ ਦੇ ਸਾਰ ਨੂੰ ਜਾਣਨਾ ਜ਼ਰੂਰੀ ਸੀ।

ਕੰਪਨੀ ਸੀਮਤ ਗਿਣਤੀ ਵਿੱਚ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ, ਅਤੇ ਜਾਣਕਾਰੀ ਕੇਵਲ ਉਹਨਾਂ ਤੋਂ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ ਅਤੇ ਹੋਰ ਕਿਤੇ ਨਹੀਂ।

ਕੰਪਨੀ ਦੇ ਸਾਰੇ ਕੰਮ ਜੀਰਾ ਵਿੱਚ ਰਜਿਸਟਰਡ ਸਨ। ਜਦੋਂ ਕੋਈ ਕੰਮ ਲਿਆ ਗਿਆ ਸੀ, ਤਾਂ ਇਸਦੇ ਲਈ ਇੱਕ ਸ਼ਾਖਾ ਬਣਾਈ ਗਈ ਸੀ, ਅਤੇ ਲਾਗੂ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਬਿੱਟਬਕੇਟ ਅਤੇ ਪੁੱਲ ਬੇਨਤੀ ਲਈ ਇੱਕ ਵਚਨਬੱਧਤਾ ਕੀਤੀ ਗਈ ਸੀ। ਜਦੋਂ ਇੱਕ PR (ਖਿੱਚਣ ਦੀ ਬੇਨਤੀ) ਸਵੀਕਾਰ ਕੀਤੀ ਜਾਂਦੀ ਸੀ, ਤਾਂ ਇੱਕ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਆਟੋਮੈਟਿਕਲੀ ਬਣਾਈ ਜਾਂਦੀ ਸੀ ਅਤੇ Nexus ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਸਟੋਰ ਕੀਤੀ ਜਾਂਦੀ ਸੀ।

ਅੱਗੇ, ਰੋਲਆਊਟ, ਆਟੋਮੈਟਿਕ ਅਤੇ ਮੈਨੂਅਲ ਟੈਸਟਿੰਗ ਦੀ ਸ਼ੁੱਧਤਾ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਜੇਨਕਿਨਜ਼ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਕਈ ਸਟੈਂਡਾਂ 'ਤੇ ਵੰਡ ਨੂੰ ਰੋਲ ਆਊਟ ਕੀਤਾ ਗਿਆ ਸੀ:

ਇਵਾਨ ਨੇ ਦੱਸਿਆ ਕਿ ਕਿਹੜੇ ਸਿਸਟਮਾਂ ਤੋਂ ਸਟੈਂਡ 'ਤੇ ਸਮੇਂ ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ ਕਿਹੜੀ ਜਾਣਕਾਰੀ ਲਈ ਜਾ ਸਕਦੀ ਹੈ:

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

ਉਪਲਬਧ ਜਾਣਕਾਰੀ ਦੇ ਆਧਾਰ 'ਤੇ, ਹੇਠ ਲਿਖਿਆ ਚਿੱਤਰ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ:

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

ਇੱਥੇ DevOps ਮੈਟ੍ਰਿਕਸ ਹਨ ਜੋ ਇਵਾਨ ਦੇ ਨਾਲ ਸਮਾਪਤ ਹੋਏ:

• ਬਣਾਈਆਂ ਗਈਆਂ ਵੰਡਾਂ ਦੀ ਗਿਣਤੀ
• ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਦਾ ਸ਼ੇਅਰ ਜੋ ਸਟੈਂਡ 'ਤੇ "ਆਇਆ" ਅਤੇ ਸਟੈਂਡ ਨੂੰ "ਪਾਸ" ਕੀਤਾ
• ਸਟੈਂਡ 'ਤੇ ਬਿਤਾਇਆ ਸਮਾਂ (ਸਟੈਂਡ ਸਾਈਕਲ)
• ਪੂਰਾ ਚੱਕਰ (ਸਾਰੇ ਸਟੈਂਡਾਂ ਲਈ ਕੁੱਲ ਸਮਾਂ)
• ਨੌਕਰੀ ਦੀ ਮਿਆਦ
• ਸਟੈਂਡਾਂ ਵਿਚਕਾਰ ਡਾਊਨਟਾਈਮ
• ਇੱਕੋ ਸਟੈਂਡ 'ਤੇ ਨੌਕਰੀ ਦੀ ਸ਼ੁਰੂਆਤ ਦੇ ਵਿਚਕਾਰ ਡਾਊਨਟਾਈਮ

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

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

ਉਹ ਉਦਾਸ ਹੋ ਕੇ ਵਾਪਸ ਆਇਆ ਅਤੇ ਆਪਣੇ ਹੱਥ ਹੇਠਾਂ ਕਰ ਲਿਆ।

"ਇਹ ਇੱਕ ਅਸਫਲਤਾ ਹੈ, ਭਰਾ," ਵਿਅੰਗਾਤਮਕ ਸਾਥੀ ਨੇ ਮੁਸਕਰਾਇਆ ...

ਲੇਖ ਵਿੱਚ ਹੋਰ ਪੜ੍ਹੋ "ਕਿੰਨੇ ਤੇਜ਼ ਨਤੀਜਿਆਂ ਨੇ ਇਵਾਨ ਦੀ ਮਦਦ ਕੀਤੀ".

ਸਰੋਤ: www.habr.com