ਰੂਸ 2020 ਵਿੱਚ DevOps ਦੀ ਸਥਿਤੀ

ਕਿਸੇ ਚੀਜ਼ ਦੀ ਸਥਿਤੀ ਨੂੰ ਕਿਵੇਂ ਸਮਝਣਾ ਹੈ?

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

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

ਆਪਣੀ ਰਿਪੋਰਟ ਵਿੱਚ, ਇਗੋਰ ਅਤੇ ਵਿਟਾਲੀ ਨੇ ਦੱਸਿਆ ਕਿ ਖੋਜ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਕਿਹੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਸਨ, ਉਹਨਾਂ ਨੇ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਹੱਲ ਕੀਤਾ, ਨਾਲ ਹੀ ਕਿਵੇਂ DevOps ਖੋਜ ਸਿਧਾਂਤ ਵਿੱਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਐਕਸਪ੍ਰੈਸ 42 ਨੇ ਆਪਣੇ ਆਪ ਨੂੰ ਚਲਾਉਣ ਦਾ ਫੈਸਲਾ ਕਿਉਂ ਕੀਤਾ। ਉਨ੍ਹਾਂ ਦੀ ਰਿਪੋਰਟ ਦੇਖੀ ਜਾ ਸਕਦੀ ਹੈ ਇੱਥੇ.

DevOps ਖੋਜ

ਗੱਲਬਾਤ ਇਗੋਰ ਕੁਰੋਚਕਿਨ ਦੁਆਰਾ ਸ਼ੁਰੂ ਕੀਤੀ ਗਈ ਸੀ.

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

ਇੱਥੇ ਸਾਡੇ ਕੋਲ ਪਹਿਲੀ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਇਸਦੇ ਬਾਅਦ ਦੋ ਹੋਰ:

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

ਆਓ ਇੱਕ ਨਜ਼ਰ ਮਾਰੀਏ ਕਿ ਦੁਨੀਆ ਭਰ ਵਿੱਚ DevOps ਰਾਜ ਦੇ ਵਿਸ਼ਲੇਸ਼ਣ ਕਿਵੇਂ ਕੀਤੇ ਗਏ ਹਨ।

ਇਤਿਹਾਸਕ ਪਿਛੋਕੜ

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

2013 ਵਿੱਚ, IT ਕ੍ਰਾਂਤੀ ਪ੍ਰਗਟ ਹੋਈ, DevOps 'ਤੇ ਸਾਰੀਆਂ ਪ੍ਰਮੁੱਖ ਕਿਤਾਬਾਂ ਦਾ ਪ੍ਰਕਾਸ਼ਕ। ਕਠਪੁਤਲੀ ਦੇ ਨਾਲ ਮਿਲ ਕੇ, ਉਨ੍ਹਾਂ ਨੇ ਪਹਿਲਾ ਸਟੇਟ ਆਫ਼ ਡਿਵੋਪਸ ਪ੍ਰਕਾਸ਼ਨ ਤਿਆਰ ਕੀਤਾ, ਜਿੱਥੇ ਪਹਿਲੀ ਵਾਰ 4 ਮੁੱਖ ਮੈਟ੍ਰਿਕਸ ਪ੍ਰਗਟ ਹੋਏ। ਅਗਲੇ ਸਾਲ, ਥੌਟਵਰਕਸ, ਉਦਯੋਗ ਦੇ ਅਭਿਆਸਾਂ ਅਤੇ ਸਾਧਨਾਂ 'ਤੇ ਨਿਯਮਤ ਤਕਨਾਲੋਜੀ ਰਾਡਾਰਾਂ ਲਈ ਜਾਣੀ ਜਾਂਦੀ ਇੱਕ ਸਲਾਹਕਾਰ ਫਰਮ, ਸ਼ਾਮਲ ਹੋ ਗਈ। ਅਤੇ 2015 ਵਿੱਚ, ਵਿਧੀ ਵਾਲਾ ਇੱਕ ਭਾਗ ਜੋੜਿਆ ਗਿਆ ਸੀ, ਅਤੇ ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਉਹ ਵਿਸ਼ਲੇਸ਼ਣ ਕਿਵੇਂ ਕਰਦੇ ਹਨ।

2016 ਵਿੱਚ, ਅਧਿਐਨ ਦੇ ਲੇਖਕਾਂ ਨੇ ਆਪਣੀ ਖੁਦ ਦੀ ਕੰਪਨੀ DORA (DevOps ਰਿਸਰਚ ਐਂਡ ਅਸੈਸਮੈਂਟ) ਬਣਾਈ, ਇੱਕ ਸਾਲਾਨਾ ਰਿਪੋਰਟ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤੀ। ਅਗਲੇ ਸਾਲ, DORA ਅਤੇ ਕਠਪੁਤਲੀ ਨੇ ਆਪਣੀ ਆਖਰੀ ਸਾਂਝੀ ਰਿਪੋਰਟ ਜਾਰੀ ਕੀਤੀ।

ਅਤੇ ਫਿਰ ਕੁਝ ਦਿਲਚਸਪ ਸ਼ੁਰੂ ਹੋਇਆ:

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

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

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

ਰੂਸ ਵਿਚ ਚੀਜ਼ਾਂ ਕਿਵੇਂ ਹਨ?

ਅਸੀਂ DevOps ਖੋਜ ਨਹੀਂ ਕੀਤੀ ਹੈ। ਅਸੀਂ ਕਾਨਫਰੰਸਾਂ ਵਿੱਚ ਗੱਲ ਕੀਤੀ, ਹੋਰ ਲੋਕਾਂ ਦੀਆਂ ਖੋਜਾਂ ਨੂੰ ਦੁਬਾਰਾ ਦੱਸਣਾ, ਅਤੇ Raiffeisenbank ਨੇ 2019 ਲਈ "State of DevOps" ਦਾ ਅਨੁਵਾਦ ਕੀਤਾ (ਤੁਸੀਂ Habré 'ਤੇ ਉਹਨਾਂ ਦੀ ਘੋਸ਼ਣਾ ਲੱਭ ਸਕਦੇ ਹੋ), ਉਹਨਾਂ ਦਾ ਬਹੁਤ ਧੰਨਵਾਦ। ਅਤੇ ਇਹ ਸਭ ਹੈ.

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

ਖੋਜ ਪ੍ਰਕਿਰਿਆ

ਰਿਪੋਰਟ ਸਿਰਫ ਅੰਤਮ ਹਿੱਸਾ ਹੈ. ਸਮੁੱਚੀ ਖੋਜ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਚਾਰ ਮੁੱਖ ਕਦਮ ਹੁੰਦੇ ਹਨ:

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

ਹਿੱਸਾ ਲੈਣ

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

ਐਕਸਲੇਰੇਟ ਸਟੇਟ ਆਫ਼ DevOps 2019 ਰਿਪੋਰਟ ਤੋਂ ਨਕਸ਼ਾ:

ਸਾਡੇ ਅਧਿਐਨ ਵਿੱਚ, ਅਸੀਂ 889 ਲੋਕਾਂ ਦੀ ਇੰਟਰਵਿਊ ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਹੋਏ - ਇਹ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੈ (ਡੋਰਾ ਇਸ ਦੀਆਂ ਰਿਪੋਰਟਾਂ ਵਿੱਚ ਸਾਲਾਨਾ ਇੱਕ ਹਜ਼ਾਰ ਲੋਕਾਂ ਬਾਰੇ ਪੋਲ) ਅਤੇ ਇੱਥੇ ਅਸੀਂ ਟੀਚਾ ਪ੍ਰਾਪਤ ਕੀਤਾ ਹੈ:

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

ਉਦਯੋਗ ਅਤੇ ਅਹੁਦੇ

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

ਦੋ ਵਿੱਚੋਂ ਇੱਕ ਇੱਕ ਮੱਧਮ ਆਕਾਰ ਦੀ ਕੰਪਨੀ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ। ਹਰ ਤੀਜਾ ਵਿਅਕਤੀ ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ 9 ਲੋਕਾਂ ਤੱਕ ਦੀਆਂ ਟੀਮਾਂ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਨ। ਵੱਖਰੇ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਮੁੱਖ ਗਤੀਵਿਧੀਆਂ ਬਾਰੇ ਪੁੱਛਿਆ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਨਾਲ ਸੰਚਾਲਨ ਨਾਲ ਸਬੰਧਤ ਹਨ, ਅਤੇ ਲਗਭਗ 40% ਵਿਕਾਸ ਵਿੱਚ ਲੱਗੇ ਹੋਏ ਹਨ:

ਇਸ ਲਈ ਅਸੀਂ ਵੱਖ-ਵੱਖ ਉਦਯੋਗਾਂ, ਕੰਪਨੀਆਂ, ਟੀਮਾਂ ਦੇ ਪ੍ਰਤੀਨਿਧਾਂ ਦੀ ਤੁਲਨਾ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕੀਤੀ। ਮੇਰੇ ਸਹਿਯੋਗੀ Vitaly Khabarov ਵਿਸ਼ਲੇਸ਼ਣ ਬਾਰੇ ਦੱਸਣਗੇ.

ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਤੁਲਨਾ

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

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

ਮੁੱਖ ਮੈਟ੍ਰਿਕਸ

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

ਮੁੱਖ ਮਾਪਦੰਡ:

1. ਤੈਨਾਤੀ ਬਾਰੰਬਾਰਤਾ। ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਇੱਕ ਨਵਾਂ ਸੰਸਕਰਣ ਉਤਪਾਦਨ ਵਾਤਾਵਰਣ ਵਿੱਚ ਕਿੰਨੀ ਵਾਰ ਤੈਨਾਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਯੋਜਨਾਬੱਧ ਤਬਦੀਲੀਆਂ, ਹੌਟਫਿਕਸ ਅਤੇ ਘਟਨਾ ਪ੍ਰਤੀਕਿਰਿਆ ਨੂੰ ਛੱਡ ਕੇ)?
2. ਅਦਾਇਗੀ ਸਮਾਂ. ਤਬਦੀਲੀ ਕਰਨ (ਕੋਡ ਵਜੋਂ ਕਾਰਜਸ਼ੀਲਤਾ ਲਿਖਣਾ) ਅਤੇ ਉਤਪਾਦਨ ਵਾਤਾਵਰਣ ਵਿੱਚ ਤਬਦੀਲੀ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਵਿਚਕਾਰ ਔਸਤ ਸਮਾਂ ਕੀ ਹੈ?
3. ਰਿਕਵਰੀ ਟਾਈਮ. ਕਿਸੇ ਘਟਨਾ, ਸੇਵਾ ਵਿੱਚ ਗਿਰਾਵਟ, ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਵਾਲੇ ਬੱਗ ਦੀ ਖੋਜ ਤੋਂ ਬਾਅਦ ਇੱਕ ਪ੍ਰੋਡਕਸ਼ਨ ਵਾਤਾਵਰਣ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਰੀਸਟੋਰ ਕਰਨ ਵਿੱਚ ਔਸਤਨ ਕਿੰਨਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ?
4. ਅਸਫ਼ਲ ਤਬਦੀਲੀਆਂ। ਉਤਪਾਦਨ ਦੇ ਵਾਤਾਵਰਣ ਵਿੱਚ ਤੈਨਾਤੀਆਂ ਦੀ ਕਿੰਨੀ ਪ੍ਰਤੀਸ਼ਤ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਗਿਰਾਵਟ ਜਾਂ ਘਟਨਾਵਾਂ ਦਾ ਕਾਰਨ ਬਣਦੀ ਹੈ ਅਤੇ ਉਪਚਾਰ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (ਬਦਲਾਵਾਂ ਦਾ ਰੋਲਬੈਕ, ਇੱਕ ਹੌਟਫਿਕਸ ਜਾਂ ਪੈਚ ਦਾ ਵਿਕਾਸ)?

DORA ਨੇ ਆਪਣੀ ਖੋਜ ਵਿੱਚ ਇਹਨਾਂ ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਸੰਗਠਨਾਤਮਕ ਪ੍ਰਦਰਸ਼ਨ ਵਿਚਕਾਰ ਇੱਕ ਸਬੰਧ ਪਾਇਆ ਹੈ। ਅਸੀਂ ਆਪਣੇ ਅਧਿਐਨ ਵਿੱਚ ਵੀ ਇਸ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਾਂ।

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

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

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

ਇੱਥੇ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਸਾਨੂੰ ਡਿਲੀਵਰੀ ਦੇ ਸਮੇਂ, ਰਿਕਵਰੀ ਸਮੇਂ, ਅਤੇ ਤੈਨਾਤੀ ਬਾਰੰਬਾਰਤਾ ਵਿਚਕਾਰ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਸਬੰਧ ਮਿਲਿਆ ਹੈ। ਇਸ ਲਈ, ਅਸੀਂ ਉੱਤਰਦਾਤਾਵਾਂ ਨੂੰ ਪ੍ਰਦਰਸ਼ਨ ਸਮੂਹਾਂ ਵਿੱਚ ਵੰਡਣ ਲਈ ਇਹਨਾਂ ਤਿੰਨ ਮਾਪਦੰਡਾਂ ਨੂੰ ਲਿਆ।

ਗ੍ਰਾਮ ਵਿੱਚ ਕਿੰਨਾ ਵਜ਼ਨ ਕਰਨਾ ਹੈ?

ਅਸੀਂ ਲੜੀਵਾਰ ਕਲੱਸਟਰ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਵਰਤੋਂ ਕੀਤੀ:

• ਅਸੀਂ ਉੱਤਰਦਾਤਾਵਾਂ ਨੂੰ ਇੱਕ n-ਅਯਾਮੀ ਸਪੇਸ ਵਿੱਚ ਵੰਡਦੇ ਹਾਂ, ਜਿੱਥੇ ਹਰੇਕ ਉੱਤਰਦਾਤਾ ਦਾ ਤਾਲਮੇਲ ਉਹਨਾਂ ਦੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਹੁੰਦਾ ਹੈ।
• ਹਰੇਕ ਉੱਤਰਦਾਤਾ ਨੂੰ ਇੱਕ ਛੋਟਾ ਸਮੂਹ ਘੋਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
• ਅਸੀਂ ਇੱਕ ਦੂਜੇ ਦੇ ਸਭ ਤੋਂ ਨੇੜੇ ਦੇ ਦੋ ਕਲੱਸਟਰਾਂ ਨੂੰ ਇੱਕ ਵੱਡੇ ਕਲੱਸਟਰ ਵਿੱਚ ਜੋੜਦੇ ਹਾਂ।
• ਅਸੀਂ ਕਲੱਸਟਰਾਂ ਦਾ ਅਗਲਾ ਜੋੜਾ ਲੱਭਦੇ ਹਾਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਵੱਡੇ ਸਮੂਹ ਵਿੱਚ ਜੋੜਦੇ ਹਾਂ।

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

ਪਰ ਇੱਥੇ ਇੱਕ ਲੁਕਵੀਂ ਸਮੱਸਿਆ ਹੈ: ਸਾਡੇ ਕੋਲ ਕਲੱਸਟਰਾਂ ਦੀ ਗਿਣਤੀ 'ਤੇ ਕੋਈ ਪਾਬੰਦੀ ਨਹੀਂ ਹੈ - ਅਸੀਂ 2, 3, 4, 10 ਕਲੱਸਟਰ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਾਂ। ਅਤੇ ਪਹਿਲਾ ਵਿਚਾਰ ਸੀ - ਕਿਉਂ ਨਾ ਸਾਡੇ ਸਾਰੇ ਉੱਤਰਦਾਤਾਵਾਂ ਨੂੰ 4 ਸਮੂਹਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾਵੇ, ਜਿਵੇਂ ਕਿ DORA ਕਰਦਾ ਹੈ। ਪਰ ਅਸੀਂ ਪਾਇਆ ਕਿ ਇਹਨਾਂ ਸਮੂਹਾਂ ਵਿਚਕਾਰ ਅੰਤਰ ਮਾਮੂਲੀ ਬਣ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਅਸੀਂ ਇਹ ਯਕੀਨੀ ਨਹੀਂ ਕਰ ਸਕਦੇ ਕਿ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਅਸਲ ਵਿੱਚ ਉਸਦੇ ਸਮੂਹ ਨਾਲ ਸਬੰਧਤ ਹੈ, ਨਾ ਕਿ ਗੁਆਂਢੀ ਨਾਲ। ਅਸੀਂ ਅਜੇ ਵੀ ਰੂਸੀ ਮਾਰਕੀਟ ਨੂੰ ਚਾਰ ਸਮੂਹਾਂ ਵਿੱਚ ਵੰਡ ਨਹੀਂ ਸਕਦੇ. ਇਸ ਲਈ, ਅਸੀਂ ਤਿੰਨ ਪ੍ਰੋਫਾਈਲਾਂ 'ਤੇ ਸੈਟਲ ਹੋ ਗਏ ਜਿਨ੍ਹਾਂ ਵਿਚਕਾਰ ਅੰਕੜਾਤਮਕ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਅੰਤਰ ਹੈ:

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

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

ਫਿਰ ਸਵਾਲ ਉੱਠਦਾ ਹੈ: ਇਹ ਸਭ ਕਿਵੇਂ ਵਰਤਣਾ ਹੈ?

ਕਿਵੇਂ ਵਰਤਣਾ ਹੈ

ਜੇ ਅਸੀਂ ਕਿਸੇ ਵੀ ਟੀਮ, 4 ਮੁੱਖ ਮੈਟ੍ਰਿਕਸ ਲੈਂਦੇ ਹਾਂ ਅਤੇ ਇਸਨੂੰ ਸਾਰਣੀ ਵਿੱਚ ਲਾਗੂ ਕਰਦੇ ਹਾਂ, ਤਾਂ 85% ਮਾਮਲਿਆਂ ਵਿੱਚ ਸਾਨੂੰ ਪੂਰਾ ਮੈਚ ਨਹੀਂ ਮਿਲੇਗਾ - ਇਹ ਸਿਰਫ਼ ਇੱਕ ਔਸਤ ਭਾਗੀਦਾਰ ਹੈ, ਅਤੇ ਅਸਲ ਵਿੱਚ ਕੀ ਨਹੀਂ ਹੈ. ਅਸੀਂ ਸਾਰੇ (ਅਤੇ ਹਰ ਟੀਮ) ਥੋੜੇ ਵੱਖਰੇ ਹਾਂ।

ਅਸੀਂ ਜਾਂਚ ਕੀਤੀ: ਅਸੀਂ ਆਪਣੇ ਉੱਤਰਦਾਤਾਵਾਂ ਅਤੇ DORA ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਲਿਆ, ਅਤੇ ਦੇਖਿਆ ਕਿ ਕਿੰਨੇ ਉੱਤਰਦਾਤਾ ਇਸ ਜਾਂ ਉਸ ਪ੍ਰੋਫਾਈਲ ਦੇ ਅਨੁਕੂਲ ਹਨ। ਅਸੀਂ ਪਾਇਆ ਕਿ ਸਿਰਫ 16% ਉੱਤਰਦਾਤਾਵਾਂ ਨੇ ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਪ੍ਰੋਫਾਈਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਡਿੱਗਿਆ. ਬਾਕੀ ਸਾਰੇ ਵਿਚਕਾਰ ਕਿਤੇ ਖਿੰਡੇ ਹੋਏ ਹਨ:

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

• DORA ਕੈਲਕੁਲੇਟਰ
• ਕੈਲਕੁਲੇਟਰ ਐਕਸਪ੍ਰੈਸ 42* (ਵਿਕਾਸ ਵਿੱਚ)
• ਆਪਣਾ ਵਿਕਾਸ (ਤੁਸੀਂ ਆਪਣਾ ਅੰਦਰੂਨੀ ਕੈਲਕੁਲੇਟਰ ਬਣਾ ਸਕਦੇ ਹੋ)।

ਉਹਨਾਂ ਦੀ ਕੀ ਲੋੜ ਹੈ? ਨੂੰ ਸਮਝਣ ਲਈ:

• ਕੀ ਸਾਡੀ ਸੰਸਥਾ ਦੇ ਅੰਦਰ ਟੀਮ ਸਾਡੇ ਮਾਪਦੰਡਾਂ ਦੇ ਅਨੁਸਾਰ ਹੈ?
• ਜੇ ਨਹੀਂ, ਤਾਂ ਕੀ ਅਸੀਂ ਇਸਦੀ ਮਦਦ ਕਰ ਸਕਦੇ ਹਾਂ, ਸਾਡੀ ਕੰਪਨੀ ਦੀ ਮੁਹਾਰਤ ਦੇ ਢਾਂਚੇ ਦੇ ਅੰਦਰ ਇਸ ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦੇ ਹਾਂ?
• ਜੇ ਹਾਂ, ਤਾਂ ਕੀ ਅਸੀਂ ਹੋਰ ਵੀ ਵਧੀਆ ਕਰ ਸਕਦੇ ਹਾਂ?

ਤੁਸੀਂ ਇਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕੰਪਨੀ ਦੇ ਅੰਦਰ ਅੰਕੜੇ ਇਕੱਠੇ ਕਰਨ ਲਈ ਵੀ ਕਰ ਸਕਦੇ ਹੋ:

• ਸਾਡੇ ਕੋਲ ਕਿਹੜੀਆਂ ਟੀਮਾਂ ਹਨ?
• ਟੀਮਾਂ ਨੂੰ ਪ੍ਰੋਫਾਈਲਾਂ ਵਿੱਚ ਵੰਡੋ;
• ਵੇਖੋ: ਓਹ, ਇਹ ਕਮਾਂਡਾਂ ਘੱਟ ਪ੍ਰਦਰਸ਼ਨ ਕਰ ਰਹੀਆਂ ਹਨ (ਉਹ ਥੋੜਾ ਬਾਹਰ ਨਹੀਂ ਕੱਢਦੀਆਂ), ਪਰ ਇਹ ਵਧੀਆ ਹਨ: ਉਹ ਹਰ ਰੋਜ਼ ਤੈਨਾਤ ਕਰਦੇ ਹਨ, ਬਿਨਾਂ ਕਿਸੇ ਗਲਤੀ ਦੇ, ਉਹਨਾਂ ਦਾ ਇੱਕ ਘੰਟੇ ਤੋਂ ਵੀ ਘੱਟ ਸਮਾਂ ਹੁੰਦਾ ਹੈ।

ਅਤੇ ਫਿਰ ਤੁਸੀਂ ਇਹ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹੋ ਕਿ ਸਾਡੀ ਕੰਪਨੀ ਦੇ ਅੰਦਰ ਉਹਨਾਂ ਟੀਮਾਂ ਲਈ ਲੋੜੀਂਦੀ ਮੁਹਾਰਤ ਅਤੇ ਸਾਧਨ ਹਨ ਜੋ ਅਜੇ ਤੱਕ ਬਰਾਬਰ ਨਹੀਂ ਹਨ।

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

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

ਆਓ ਸਭ ਤੋਂ ਮਿੱਠੇ - ਤੁਲਨਾ ਵੱਲ ਵਧੀਏ।

ਤੁਲਨਾ

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

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

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

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

• ਨਵੇਂ ਉਤਪਾਦਾਂ ਨੂੰ ਜਾਰੀ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ 1,5-2 ਗੁਣਾ ਜ਼ਿਆਦਾ,
• ਐਪਲੀਕੇਸ਼ਨ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ / ਜਾਂ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਦੀ ਸੰਭਾਵਨਾ 2 ਗੁਣਾ ਜ਼ਿਆਦਾ ਹੈ।

ਭਾਵ, ਉਹ ਯੋਗਤਾਵਾਂ ਜੋ ਉਹਨਾਂ ਨੇ ਪਹਿਲਾਂ ਹੀ ਉਹਨਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਵਿਕਸਤ ਕਰਨ, ਨਵੇਂ ਉਤਪਾਦ ਲਾਂਚ ਕਰਨ, ਮੌਜੂਦਾ ਉਤਪਾਦਾਂ ਨੂੰ ਸੋਧਣ, ਇਸ ਤਰ੍ਹਾਂ ਨਵੇਂ ਬਾਜ਼ਾਰਾਂ ਅਤੇ ਨਵੇਂ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਜਿੱਤਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ ਸੀ:

ਸਾਡੀਆਂ ਟੀਮਾਂ ਦੀ ਹੋਰ ਕਿਸ ਚੀਜ਼ ਨੇ ਮਦਦ ਕੀਤੀ?

ਇੰਜੀਨੀਅਰਿੰਗ ਅਭਿਆਸ

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

ਇੱਕ ਸੇਵਾ ਵਜੋਂ ਪਲੇਟਫਾਰਮ

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

ਕੋਡ ਦੇ ਤੌਰ 'ਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚਾ

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

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

ਏਕੀਕਰਣ ਅਤੇ ਡਿਲਿਵਰੀ

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

ਆਰਕੀਟੈਕਚਰ

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

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

ਅਸੀਂ ਇਹ ਸਭ ਕਿਵੇਂ ਖੋਜਿਆ?

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

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

ਇੱਕ ਤਬਦੀਲੀ ਲਈ, ਆਓ ਗੁੰਝਲਦਾਰ ਅੰਕੜਿਆਂ ਤੋਂ ਸਧਾਰਨ ਅੰਕੜਿਆਂ ਵਿੱਚ ਬਦਲੀਏ।

ਅਸੀਂ ਹੋਰ ਕੀ ਖੋਜਿਆ ਹੈ?

ਸੰਦ

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

ਆਰਕੈਸਟਰੇਟਰਾਂ ਵਿੱਚ, ਇਹ ਕਿਸੇ ਲਈ ਵੀ ਗੁਪਤ ਨਹੀਂ ਹੈ, ਕੁਬਰਨੇਟਸ ਲੀਡ ਵਿੱਚ ਹੈ (52%). ਅਗਲਾ ਇਨ ਲਾਈਨ ਆਰਕੈਸਟ੍ਰੇਟਰ ਡੌਕਰ ਸਵੈਰਮ (ਲਗਭਗ 12%) ਹੈ। ਸਭ ਤੋਂ ਪ੍ਰਸਿੱਧ CI ਸਿਸਟਮ ਜੇਨਕਿੰਸ ਅਤੇ ਗਿਟਲੈਬ ਹਨ। ਸਭ ਤੋਂ ਪ੍ਰਸਿੱਧ ਸੰਰਚਨਾ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀ ਜਵਾਬਦੇਹ ਹੈ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਸਾਡਾ ਪਿਆਰਾ ਸ਼ੈੱਲ ਹੈ।

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

ਮੈਂ ਇਗੋਰ ਨੂੰ ਮੰਜ਼ਿਲ ਪਾਸ ਕਰਦਾ ਹਾਂ, ਜੋ ਕੁਝ ਹੋਰ ਅੰਕੜੇ ਦੇਵੇਗਾ.

ਅਭਿਆਸਾਂ ਦਾ ਪ੍ਰਸਾਰ

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

ਚੁਸਤ ਅਤੇ DevOps

Agile ਅਤੇ DevOps ਵਿਚਕਾਰ ਸਬੰਧ ਦਾ ਸਵਾਲ ਅਕਸਰ ਉਦਯੋਗ ਵਿੱਚ ਚਰਚਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ. ਇਹ ਮੁੱਦਾ 2019/2020 ਦੀ ਸਟੇਟ ਆਫ਼ ਐਜੀਲ ਰਿਪੋਰਟ ਵਿੱਚ ਵੀ ਉਠਾਇਆ ਗਿਆ ਹੈ, ਇਸਲਈ ਅਸੀਂ ਤੁਲਨਾ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ ਕਿ ਕੰਪਨੀਆਂ ਵਿੱਚ Agile ਅਤੇ DevOps ਗਤੀਵਿਧੀਆਂ ਕਿਵੇਂ ਜੁੜੀਆਂ ਹਨ। ਅਸੀਂ ਪਾਇਆ ਹੈ ਕਿ ਐਗਾਇਲ ਤੋਂ ਬਿਨਾਂ DevOps ਬਹੁਤ ਘੱਟ ਹਨ। ਅੱਧੇ ਉੱਤਰਦਾਤਾਵਾਂ ਲਈ, ਐਗਾਇਲ ਦਾ ਫੈਲਣਾ ਬਹੁਤ ਪਹਿਲਾਂ ਸ਼ੁਰੂ ਹੋਇਆ ਸੀ, ਅਤੇ ਲਗਭਗ 20% ਨੇ ਇੱਕੋ ਸਮੇਂ ਦੀ ਸ਼ੁਰੂਆਤ ਨੂੰ ਦੇਖਿਆ, ਅਤੇ ਘੱਟ ਪ੍ਰੋਫਾਈਲ ਦੇ ਸੰਕੇਤਾਂ ਵਿੱਚੋਂ ਇੱਕ ਐਗਾਇਲ ਅਤੇ ਦੇਵਓਪਸ ਅਭਿਆਸਾਂ ਦੀ ਅਣਹੋਂਦ ਹੋਵੇਗੀ:

ਕਮਾਂਡ ਟੋਪੋਲੋਜੀ

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

ਅੱਧੇ ਉੱਤਰਦਾਤਾਵਾਂ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਟੀਮਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਵਿਕਾਸ, ਟੈਸਟਿੰਗ ਅਤੇ ਸੰਚਾਲਨ ਲਈ ਵੱਖਰੀਆਂ ਟੀਮਾਂ ਨੂੰ ਦੇਖਿਆ ਜਾਂਦਾ ਹੈ। ਵੱਖਰੇ DevOps ਟੀਮਾਂ ਨੇ 45% ਨੋਟ ਕੀਤਾ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਉੱਚ ਦੇ ਪ੍ਰਤੀਨਿਧ ਵਧੇਰੇ ਆਮ ਹਨ। ਅੱਗੇ ਕਰਾਸ-ਫੰਕਸ਼ਨਲ ਟੀਮਾਂ ਆਉਂਦੀਆਂ ਹਨ, ਜੋ ਹਾਈ 'ਤੇ ਵਧੇਰੇ ਆਮ ਹਨ। ਵੱਖਰੇ SRE ਕਮਾਂਡਾਂ ਉੱਚ, ਮੱਧਮ ਪ੍ਰੋਫਾਈਲਾਂ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ ਘੱਟ ਹੀ ਘੱਟ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ:

DevQaOps ਅਨੁਪਾਤ

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

2021 ਲਈ ਯੋਜਨਾਵਾਂ

ਅਗਲੇ ਸਾਲ ਦੀਆਂ ਯੋਜਨਾਵਾਂ ਵਿੱਚ, ਉੱਤਰਦਾਤਾਵਾਂ ਨੇ ਹੇਠ ਲਿਖੀਆਂ ਗਤੀਵਿਧੀਆਂ ਨੋਟ ਕੀਤੀਆਂ:

ਇੱਥੇ ਤੁਸੀਂ DevOps ਲਾਈਵ 2020 ਕਾਨਫਰੰਸ ਦੇ ਨਾਲ ਇੰਟਰਸੈਕਸ਼ਨ ਦੇਖ ਸਕਦੇ ਹੋ। ਅਸੀਂ ਧਿਆਨ ਨਾਲ ਪ੍ਰੋਗਰਾਮ ਦੀ ਸਮੀਖਿਆ ਕੀਤੀ:

• ਇੱਕ ਉਤਪਾਦ ਦੇ ਰੂਪ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚਾ
• DevOps ਪਰਿਵਰਤਨ
• DevOps ਅਭਿਆਸਾਂ ਦੀ ਵੰਡ
• DevSecOps
• ਕੇਸ ਕਲੱਬ ਅਤੇ ਚਰਚਾ

ਪਰ ਸਾਡੀ ਪੇਸ਼ਕਾਰੀ ਦਾ ਸਮਾਂ ਸਾਰੇ ਵਿਸ਼ਿਆਂ ਨੂੰ ਕਵਰ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ। ਪਰਦੇ ਪਿੱਛੇ ਛੱਡ ਦਿੱਤਾ:

• ਇੱਕ ਸੇਵਾ ਅਤੇ ਇੱਕ ਉਤਪਾਦ ਦੇ ਰੂਪ ਵਿੱਚ ਪਲੇਟਫਾਰਮ;
• ਕੋਡ, ਵਾਤਾਵਰਣ ਅਤੇ ਬੱਦਲਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚਾ;
• ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਅਤੇ ਡਿਲਿਵਰੀ;
• ਆਰਕੀਟੈਕਚਰ;
• DevSecOps ਪੈਟਰਨ;
• ਪਲੇਟਫਾਰਮ ਅਤੇ ਕਰਾਸ-ਫੰਕਸ਼ਨਲ ਟੀਮਾਂ।

ਰਿਪੋਰਟ ਸਾਨੂੰ ਇੱਕ ਵਿਸ਼ਾਲ, 50 ਪੰਨੇ ਮਿਲੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਇਸਨੂੰ ਹੋਰ ਵਿਸਥਾਰ ਵਿੱਚ ਦੇਖ ਸਕਦੇ ਹੋ।

ਸੰਖੇਪ

ਅਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹਾਂ ਕਿ ਸਾਡੀ ਖੋਜ ਅਤੇ ਰਿਪੋਰਟ ਤੁਹਾਨੂੰ ਵਿਕਾਸ, ਟੈਸਟਿੰਗ, ਅਤੇ ਸੰਚਾਲਨ ਲਈ ਨਵੀਆਂ ਪਹੁੰਚਾਂ ਦੇ ਨਾਲ ਪ੍ਰਯੋਗ ਕਰਨ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰੇਗੀ, ਨਾਲ ਹੀ ਤੁਹਾਨੂੰ ਨੈਵੀਗੇਟ ਕਰਨ, ਅਧਿਐਨ ਵਿੱਚ ਦੂਜੇ ਭਾਗੀਦਾਰਾਂ ਨਾਲ ਆਪਣੀ ਤੁਲਨਾ ਕਰਨ, ਅਤੇ ਉਹਨਾਂ ਖੇਤਰਾਂ ਦੀ ਪਛਾਣ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇਗੀ ਜਿੱਥੇ ਤੁਸੀਂ ਆਪਣੇ ਖੁਦ ਦੇ ਪਹੁੰਚ ਨੂੰ ਸੁਧਾਰ ਸਕਦੇ ਹੋ।

ਰੂਸ ਵਿੱਚ DevOps ਦੇ ਰਾਜ ਦੇ ਪਹਿਲੇ ਅਧਿਐਨ ਦੇ ਨਤੀਜੇ:

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

ਅਸੀਂ ਤੁਹਾਡੀ ਫੀਡਬੈਕ, ਕਹਾਣੀਆਂ, ਫੀਡਬੈਕ ਸੁਣਨਾ ਪਸੰਦ ਕਰਾਂਗੇ। ਅਸੀਂ ਅਧਿਐਨ ਵਿੱਚ ਹਿੱਸਾ ਲੈਣ ਵਾਲੇ ਹਰੇਕ ਵਿਅਕਤੀ ਦਾ ਧੰਨਵਾਦ ਕਰਦੇ ਹਾਂ ਅਤੇ ਅਗਲੇ ਸਾਲ ਤੁਹਾਡੀ ਭਾਗੀਦਾਰੀ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਾਂ।

ਸਰੋਤ: www.habr.com