DevOpsDays ਮਾਸਕੋ ਕਾਨਫਰੰਸ ਦੀ ਸੰਖੇਪ ਜਾਣਕਾਰੀ: 6 ਰਿਪੋਰਟਾਂ ਤੋਂ ਸੂਝ

ਤੀਜੀ ਕਾਨਫਰੰਸ 7 ਦਸੰਬਰ ਨੂੰ ਹੋਈ DevOpsDays ਮਾਸਕੋ, Mail.ru Cloud Solutions ਦੇ ਸਮਰਥਨ ਨਾਲ ਮਾਸਕੋ DevOps ਭਾਈਚਾਰੇ ਦੁਆਰਾ ਆਯੋਜਿਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਪ੍ਰਮੁੱਖ DevOps ਪ੍ਰੈਕਟੀਸ਼ਨਰਾਂ ਦੁਆਰਾ ਪੇਸ਼ਕਾਰੀਆਂ ਤੋਂ ਇਲਾਵਾ, ਭਾਗੀਦਾਰ ਛੋਟੀਆਂ ਪ੍ਰੇਰਿਤ ਕਰਨ ਵਾਲੀਆਂ ਲਾਈਟਨਿੰਗ ਟਾਕਸ, ਵਰਕਸ਼ਾਪਾਂ ਅਤੇ ਖੁੱਲ੍ਹੀਆਂ ਥਾਵਾਂ 'ਤੇ ਸੰਚਾਰ ਕਰ ਸਕਦੇ ਹਨ।

ਅਸੀਂ ਛੇ ਭਾਸ਼ਣਾਂ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕੀਤੀ ਅਤੇ ਰਿਪੋਰਟਾਂ ਪਿੱਛੇ ਕੀ ਬਚਿਆ ਹੈ ਇਹ ਜਾਣਨ ਲਈ ਕਈ ਬੁਲਾਰਿਆਂ ਨਾਲ ਇੰਟਰਵਿਊਆਂ ਕੀਤੀਆਂ।

ਅੰਦਰ:

1. ਬਾਰੂਚ ਸਡੋਗੁਰਸਕੀ, ਜੇਫਰੋਗ: “ਸਾਫਟਵੇਅਰ ਨੂੰ ਵਿਕਰੇਤਾ ਤੋਂ ਉਪਭੋਗਤਾ ਤੱਕ ਤਰਲ ਵਾਂਗ ਵਹਿਣ ਦਿਓ”
2. ਪਾਵੇਲ ਸੇਲੀਵਾਨੋਵ, ਸਾਊਥਬ੍ਰਿਜ: "ਦੇਵ ਅਤੇ ਓਪਸ ਦਾ ਇੱਕ ਸਾਂਝਾ ਕੰਮ ਹੈ - ਇੱਕ ਉਤਪਾਦ ਬਣਾਉਣਾ ਜੋ ਕੰਮ ਕਰਦਾ ਹੈ"
3. ਵਲਾਦੀਮੀਰ ਉਤਰਾਟੇਂਕੋ, ਐਕਸ 5 ਰਿਟੇਲ ਗਰੁੱਪ: "ਐਂਟਰਪ੍ਰਾਈਜ਼ ਵਿੱਚ ਡਿਵੋਪਸ ਦਰਦ ਅਤੇ ਅੱਗ ਤੋਂ ਬਿਨਾਂ ਵਿਕਾਸ ਹੈ"
4. ਸੇਰਗੇਈ ਪੁਜ਼ੀਰੇਵ, ਫੇਸਬੁੱਕ: "ਪ੍ਰੋਡਕਸ਼ਨ ਇੰਜੀਨੀਅਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੇਵਾ ਦੀ ਪਰਵਾਹ ਕਰਦਾ ਹੈ: ਤਾਂ ਜੋ ਉਪਭੋਗਤਾਵਾਂ ਅਤੇ ਡਿਵੈਲਪਰਾਂ ਦੋਵਾਂ ਦਾ ਚੰਗਾ ਸਮਾਂ ਹੋਵੇ"
5. ਮਿਖਾਇਲ ਚਿਨਕੋਵ, AMBOSS: "ਇੱਕ ਵਿਭਾਗ DevOps ਮਾਰਗ ਦੀ ਪਾਲਣਾ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਪੂਰੀ ਕੰਪਨੀ ਨੂੰ ਇਸਦਾ ਪਾਲਣ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ"
6. ਰੋਸਬੈਂਕ ਦੇ DevOps ਉਤਸ਼ਾਹੀ: "ਇੱਕ ਖੂਨੀ ਉਦਯੋਗ ਵਿੱਚ DevOps ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ 1000 ਦਿਨ"

1. ਬਾਰੂਚ ਸਡੋਗੁਰਸਕੀ, ਜੇਫਰੋਗ: “ਸਾਫਟਵੇਅਰ ਨੂੰ ਵਿਕਰੇਤਾ ਤੋਂ ਉਪਭੋਗਤਾ ਤੱਕ ਤਰਲ ਵਾਂਗ ਵਹਿਣ ਦਿਓ”

ਸੌਫਟਵੇਅਰ ਅੱਪਡੇਟ ਅਸਫਲਤਾਵਾਂ ਹਰ ਘੰਟੇ ਅਤੇ ਹਰੇਕ ਲਈ ਹੁੰਦੀਆਂ ਹਨ। ਭਾਸ਼ਣ ਤੋਂ ਇੱਥੇ ਸਿਰਫ ਇੱਕ ਡਰਾਉਣੀ ਕਹਾਣੀ ਹੈ: ਇੱਕ ਅਸਫਲ ਅਪਡੇਟ ਤੋਂ ਬਾਅਦ ਇੱਕ ਘੰਟੇ ਵਿੱਚ ਨਾਈਟ ਕੈਪੀਟਲ ਨੇ $440 ਮਿਲੀਅਨ ਦਾ ਨੁਕਸਾਨ ਕੀਤਾ।

ਬਾਰੂਚ ਨੇ ਲਗਾਤਾਰ ਅਪਡੇਟਾਂ ਦੇ DevOps ਪੈਟਰਨਾਂ ਬਾਰੇ ਗੱਲ ਕੀਤੀ ਜੋ ਅਸਫਲਤਾਵਾਂ ਅਤੇ ਉਪਭੋਗਤਾ ਨਫ਼ਰਤ ਤੋਂ ਬਚਣ ਵਿੱਚ ਮਦਦ ਕਰਨਗੇ:

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

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

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

ਸਵੈਚਲਿਤ ਤੈਨਾਤੀ - ਲੋਕਾਂ ਨੂੰ ਮਸ਼ੀਨਾਂ ਨਾਲ ਬਦਲੋ, ਕਿਉਂਕਿ ਲੋਕ ਰੁਟੀਨ ਕਿਰਿਆਵਾਂ ਕਰਨ ਵਿੱਚ ਮਾੜੇ ਹਨ।

ਵਾਰ-ਵਾਰ ਅੱਪਡੇਟ - ਇੱਕ ਆਦਤ ਵਿਕਸਿਤ ਕਰਨ ਅਤੇ ਡਰ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਉਣ ਵਿੱਚ ਤੁਹਾਡੀ ਮਦਦ ਕਰੋ। ਦੁਰਲੱਭ ਅੱਪਡੇਟ ਸੰਕਟਕਾਲੀਨ ਘਟਨਾਵਾਂ ਵਿੱਚ ਬਦਲ ਜਾਂਦੇ ਹਨ।

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

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

ਅਣਉਪਲਬਧਤਾ ਦੇ ਬਿਨਾਂ ਅੱਪਡੇਟ — ਗਾਹਕਾਂ ਨੂੰ ਸਿਰਫ਼ ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵੱਲ ਧਿਆਨ ਦੇਣ ਦਿਓ, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਕੋਈ ਅੱਪਡੇਟ ਰੋਲ ਆਊਟ ਕਰਦੇ ਹੋ ਤਾਂ ਕਈ ਹਫ਼ਤਿਆਂ ਤੱਕ ਸੇਵਾ ਤੋਂ ਬਿਨਾਂ ਨਾ ਛੱਡੋ।

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

2. ਪਾਵੇਲ ਸੇਲੀਵਾਨੋਵ, ਸਾਊਥਬ੍ਰਿਜ: "ਦੇਵ ਅਤੇ ਓਪਸ ਦਾ ਇੱਕ ਸਾਂਝਾ ਕੰਮ ਹੈ - ਇੱਕ ਉਤਪਾਦ ਬਣਾਉਣਾ ਜੋ ਕੰਮ ਕਰਦਾ ਹੈ"

ਕੁਬਰਨੇਟਸ ਨੂੰ ਲਾਗੂ ਕਰਨਾ DevOps ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ, ਅਤੇ ਇਸਦੇ ਉਲਟ, ਇਹ ਸਭ ਕੁਝ ਤੋੜ ਸਕਦਾ ਹੈ. ਪਾਵੇਲ ਨੇ ਸਮਝਾਇਆ ਕਿ ਕਿਉਂ ਤਕਨਾਲੋਜੀ (ਇੱਥੋਂ ਤੱਕ ਕਿ ਸਭ ਤੋਂ ਵਧੀਆ) ਤੁਹਾਡੀਆਂ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦੀ:

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

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

ਹਾਲਾਂਕਿ, ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਬਦਲਾਅ ਸਵੀਕਾਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ. ਸਥਿਤੀ ਜਦੋਂ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਨਹੀਂ ਪਤਾ ਹੁੰਦਾ ਕਿ ਪ੍ਰਸ਼ਾਸਕ ਕੀ ਕਰ ਰਹੇ ਹਨ, ਅਤੇ ਪ੍ਰਸ਼ਾਸਕਾਂ ਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਡਿਵੈਲਪਰਾਂ ਨਾਲ ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ।

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

DevOps ਅਤੇ Kubernetes ਦੇ ਆਗਮਨ ਨਾਲ, ਵਿਕਾਸ ਵਿੱਚ ਬਹੁਤ ਕੁਝ ਬਦਲ ਜਾਵੇਗਾ. Devs ਨੂੰ ਓਪਸ ਵਿੱਚ ਸਮਰੱਥ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇਸਦੇ ਉਲਟ। ਇਹਨਾਂ ਮਾਹਿਰਾਂ ਦੇ ਆਪਣੇ ਖਾਸ ਹੁਨਰ ਹੁੰਦੇ ਹਨ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਦੂਜੇ ਦੇ ਕੰਮ ਤੋਂ ਜਾਣੂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ. ਕੁਬਰਨੇਟਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੇਵ ਅਤੇ ਓਪਸ ਨੂੰ ਦੋਸਤ ਬਣਨ ਦੀ ਲੋੜ ਹੈ, ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਜੋ ਵੀ ਹੈ ਉਸ ਨੂੰ ਤੋੜ ਦਿਓਗੇ।

ਪਾਵੇਲ ਸੇਲੀਵਾਨੋਵ ਨੇ ਇਸ ਬਾਰੇ ਦੱਸਿਆ ਕਿ 5 ਸਾਲਾਂ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਦਾ ਕੀ ਹੋਵੇਗਾ ਅਤੇ ਇੱਕ ਆਧੁਨਿਕ ਸਟਾਰਟਅੱਪ ਨੂੰ ਇੱਕ ਟੈਕਨਾਲੋਜੀ ਸਟੈਕ ਕੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ - ਇੰਟਰਵਿਊ ਦੇਖੋ:

3. ਵਲਾਦੀਮੀਰ ਉਤਰਾਟੇਨਕੋ, ਐਕਸ 5 ਰਿਟੇਲ ਗਰੁੱਪ: "ਐਂਟਰਪ੍ਰਾਈਜ਼ ਵਿੱਚ DevOps ਦਰਦ ਅਤੇ ਅੱਗ ਤੋਂ ਬਿਨਾਂ ਵਿਕਾਸ ਹੈ"

ਕੰਪਨੀਆਂ DevOps ਪਰਿਵਰਤਨ ਤੇ ਆਉਂਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹਨਾਂ ਨੂੰ ਇਹ ਅਹਿਸਾਸ ਹੁੰਦਾ ਹੈ ਕਿ ਵਿਕਾਸ ਬਹੁਤ ਹੌਲੀ ਹੈ ਅਤੇ ਅਸਲੀਅਤਾਂ ਨੂੰ ਪੂਰਾ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਉਹਨਾਂ ਕੋਲ ਬਿਹਤਰ ਵਿਕਾਸ ਕਰਨ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਰੋਲ ਆਊਟ ਕਰਨ ਦੀ ਇੱਛਾ ਹੁੰਦੀ ਹੈ।

ਵਲਾਦੀਮੀਰ ਨੇ ਦੱਸਿਆ ਕਿ ਇਹ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ ਅਤੇ ਕੈਚ ਕੀ ਹੈ:

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

ਮੈਂ ਕੀ ਕਰਾਂ? ਇੱਕ ਅਸਥਾਈ DevOps ਟੀਮ ਨੂੰ ਹਾਇਰ ਕਰੋ ਜੋ DevOps ਪਰਿਵਰਤਨ ਨੂੰ ਲਾਗੂ ਕਰਨ, ਅਭਿਆਸਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ, ਇੱਕ ਵਿਕਾਸ ਸੱਭਿਆਚਾਰ ਅਤੇ ਇੱਕ ਤਕਨੀਕੀ ਸੱਭਿਆਚਾਰ ਪੈਦਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇਗੀ।

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

ਵਲਾਦੀਮੀਰ ਉਤਰਾਟੇਂਕੋ ਨੇ ਸਾਨੂੰ ਦੱਸਿਆ ਕਿ ਇੱਕ ਉੱਦਮ ਵਿੱਚ "ਖੂਨੀ" DevOps ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਹੈ ਅਤੇ ਵੱਡੇ ਪ੍ਰਚੂਨ ਵਿੱਚ ਅਭਿਆਸਾਂ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ - ਇੰਟਰਵਿਊ ਦੇਖੋ:

4. ਸੇਰਗੇਈ ਪੁਜ਼ੀਰੇਵ, ਫੇਸਬੁੱਕ: "ਉਤਪਾਦਨ ਇੰਜੀਨੀਅਰ ਸੇਵਾ ਦੀ ਪੂਰੀ ਪਰਵਾਹ ਕਰਦਾ ਹੈ: ਤਾਂ ਜੋ ਉਪਭੋਗਤਾਵਾਂ ਅਤੇ ਵਿਕਾਸਕਰਤਾਵਾਂ ਦੋਵਾਂ ਦਾ ਸਮਾਂ ਵਧੀਆ ਰਹੇ"

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

ਸੇਰਗੇਈ ਨੇ ਦੱਸਿਆ ਕਿ ਇੱਕ ਪ੍ਰੋਡਕਸ਼ਨ ਇੰਜੀਨੀਅਰ ਫੇਸਬੁੱਕ 'ਤੇ ਕੀ ਕਰਦਾ ਹੈ:

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

5. ਮਿਖਾਇਲ ਚਿਨਕੋਵ, AMBOSS: "ਇੱਕ ਵਿਭਾਗ DevOps ਮਾਰਗ ਦੀ ਪਾਲਣਾ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਪੂਰੀ ਕੰਪਨੀ ਨੂੰ ਇਸਦਾ ਪਾਲਣ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ"

ਮਿਖਾਇਲ ਦਾ ਮੰਨਣਾ ਹੈ ਕਿ DevOps ਨਿਰੰਤਰ ਵਿਕਾਸ ਹੈ. ਤੁਸੀਂ ਕੁਝ ਟੂਲ ਪੇਸ਼ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਉੱਥੇ ਰੁਕ ਸਕਦੇ ਹੋ। ਕਿਹੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਕੰਪਨੀਆਂ ਨੂੰ DevOps ਬਣਨ ਤੋਂ ਰੋਕਦੀਆਂ ਹਨ ਅਤੇ ਅਭਿਆਸਾਂ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨਾ ਹੈ?

DevOps ਨੂੰ ਸਮਝਣ ਵਿੱਚ ਅੰਤਰ. ਕੈਨੋਨੀਕਲ ਡਿਵੋਪਸ, ਜਿਵੇਂ ਕਿ ਪ੍ਰਚਾਰਕ ਇਸਨੂੰ ਦੇਖਦੇ ਹਨ, 5 ਥੰਮ੍ਹਾਂ 'ਤੇ ਟਿਕੇ ਹੋਏ ਹਨ:

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

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

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

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

ਇੱਕ ਕੰਪਨੀ ਵਿੱਚ DevOps ਵਿਕਾਸ ਦੇ ਪੜਾਅ:

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

ਆਦਰਸ਼ ਯੋਜਨਾ ਇਹ ਹੈ ਕਿ ਹਰੇਕ ਕੋਲ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਤੱਕ ਇੱਕੋ ਜਿਹੀ ਪਹੁੰਚ ਹੈ, ਸਾਰੇ ਇੰਜੀਨੀਅਰਾਂ ਕੋਲ ਉਤਪਾਦ ਤੱਕ ਪਹੁੰਚ ਹੈ ਅਤੇ ਉਹ ਸਮਝਦੇ ਹਨ ਕਿ ਉਹ ਕੀ ਕਰ ਰਹੇ ਹਨ।

ਸਾਰੇ ਸੱਭਿਆਚਾਰਕ ਅਤੇ ਤਕਨੀਕੀ ਜੈਸਟਲਟਸ ਨੂੰ ਬੰਦ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਕੰਪਨੀ ਦੇ DevOps ਪਰਿਵਰਤਨ ਕਾਰੋਬਾਰ ਅਤੇ ਪਲੇਟਫਾਰਮ ਮੈਟ੍ਰਿਕਸ ਤੋਂ ਫੀਡਬੈਕ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖੇਗਾ।

6. ਰੋਸਬੈਂਕ ਦੇ DevOps ਉਤਸ਼ਾਹੀ: “ਇੱਕ ਖੂਨੀ ਉਦਯੋਗ ਵਿੱਚ DevOps ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ 1000 ਦਿਨ”

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

ਇੱਥੇ ਪ੍ਰਾਪਤ ਕੀਤੇ ਨਤੀਜੇ ਹਨ:

ਉਤਪਾਦ ਟੀਮਾਂ ਲਈ ਨਤੀਜੇ: 30 ਗੁਣਾ ਤੇਜ਼ ਅਸੈਂਬਲੀ, 6 ਗੁਣਾ ਤੇਜ਼ ਇੰਸਟਾਲੇਸ਼ਨ, ਪੂਰੇ ਚੱਕਰ 'ਤੇ 30% ਤੱਕ ਦੀ ਬਚਤ। ਸਾਡੇ ਕੋਲ ਹੁਣ ਉਤਪਾਦਕਤਾ 'ਤੇ ਜਾਣ ਲਈ ਇੱਕ ਬਟਨ ਦਬਾਉਣ ਦੀ ਸਮਰੱਥਾ ਹੈ

ਪਲੇਟਫਾਰਮ ਕਮਾਂਡਾਂ ਲਈ ਨਤੀਜੇ: 10 ਗੁਣਾ ਤੇਜ਼ ਅਸੈਂਬਲੀ ਅਤੇ ਇੰਸਟਾਲੇਸ਼ਨ, 87% ਸਥਾਪਨਾਵਾਂ ਦੀ ਵਧੀ ਹੋਈ ਸੰਖਿਆ, 46% ਆਟੋਟੈਸਟ ਕਵਰੇਜ। ਏਕੀਕਰਣ ਟੀਮ ਹੁਣ ਕੋਈ ਰੁਕਾਵਟ ਨਹੀਂ ਹੈ

ਇਸ ਲਈ, ਇੱਕ ਖੂਨੀ ਉਦਯੋਗ ਵਿੱਚ DevOps ਅਭਿਆਸਾਂ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨਾ ਹੈ?

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

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

ਪਾਇਲਟ ਦੇ ਬਾਅਦ, ਇੱਕ ਸਫਲ ਹੱਲ ਨੂੰ ਸਕੇਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ.

1. ਪਾਈਪਲਾਈਨ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ "ਸਿੱਧਾ" ਕਰਨਾ, ਇਸ ਤੋਂ ਬੇਲੋੜੇ ਲਿੰਕਾਂ ਨੂੰ ਖਤਮ ਕਰਨਾ, ਮੁੱਲ ਪ੍ਰਦਾਤਾਵਾਂ ਨੂੰ ਉਜਾਗਰ ਕਰਨਾ, ਅਤੇ ਬਾਕੀ ਬਚੇ ਭਾਗਾਂ ਨੂੰ ਹਟਾਉਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇੰਟਰਮੀਡੀਏਟ ਐਂਟੀਪੈਟਰਨ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਰੋਸਬੈਂਕ ਵਿਖੇ, ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਨੇ ਅੰਦਰੂਨੀ ਵਿਕਾਸ ਨਹੀਂ ਕੀਤਾ, ਸਿਰਫ ਬਾਹਰੀ ਵਿਕਾਸ ਨੂੰ ਛੱਡ ਕੇ. ਇਸ ਨਾਲ ਇੱਕ ਸਮਰਪਿਤ DevOps ਟੀਮ ਦਾ ਉਭਾਰ ਹੋਇਆ, ਜਿਸ ਨੇ ਕੋਡ ਨੂੰ ਬਾਹਰੀ ਤੋਂ ਅੰਦਰੂਨੀ ਡਿਵੈਲਪਰਾਂ ਤੱਕ ਟ੍ਰਾਂਸਫਰ ਕਰਨਾ ਯਕੀਨੀ ਬਣਾਇਆ। ਬਾਹਰੀ ਵਿਕਾਸ ਨੂੰ CI/CD ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ ਕਰਕੇ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕੀਤਾ ਗਿਆ ਸੀ, ਤਾਂ ਜੋ ਉਹ ਕੋਡ ਨੂੰ ਆਪਣੇ ਆਪ ਤੋਂ ਬੈਂਕ ਵਿੱਚ ਤਬਦੀਲ ਨਹੀਂ ਕਰਨਗੇ, ਸਗੋਂ ਇਸਦੀ ਸਫਲਤਾ ਲਈ ਵੀ ਜ਼ਿੰਮੇਵਾਰ ਹੋਣਗੇ।
2. ਪਰਿਪੱਕਤਾ ਮਾਡਲ ਵਿੱਚ DevOps ਅਭਿਆਸਾਂ, ਸੂਚੀਬੱਧ ਟੂਲਜ਼ ਦੇ ਤੱਤ ਸ਼ਾਮਲ ਸਨ, ਅਤੇ ਬਾਹਰੀ ਸਪਲਾਇਰਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਿਆ ਗਿਆ ਸੀ - ਭਵਿੱਖ ਵਿੱਚ, ਇਸ ਨੇ ਨਵੀਆਂ ਟੀਮਾਂ ਵਿੱਚ ਲਾਗੂ ਕਰਨ ਵੇਲੇ ਕਾਰਜਾਂ ਦੇ ਬੈਕਲਾਗ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਘਟਾਉਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ।
3. ਸਾਨੂੰ ਨਰਮ ਕੰਟਰੋਲ ਅਤੇ ਸਿਫ਼ਾਰਸ਼ਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਸ਼ਾਸਨ ਦੀ ਲੋੜ ਹੈ। ਇੱਕ DevOps ਹੈਂਡਬੁੱਕ ਜੋ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ ਉਹ ਸੰਗਠਨਾਤਮਕ ਅਤੇ ਟੂਲਿੰਗ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ ਜੋ ਪਲੇਟਫਾਰਮ ਦੀ ਸਹੀ ਵਰਤੋਂ ਕਰਨ ਵਿੱਚ ਟੀਮਾਂ ਦੀ ਮਦਦ ਕਰਦੀ ਹੈ।
4. ਤੁਹਾਨੂੰ ਤੁਰੰਤ ਸੱਭਿਆਚਾਰ ਵੱਲ ਧਿਆਨ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, ਫਿਰ ਬਹੁਤ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਤੇਜ਼ ਅਤੇ ਆਸਾਨ ਹੋ ਜਾਣਗੀਆਂ. ਆਪਣੇ ਅੰਦਰੂਨੀ ਭਾਈਚਾਰੇ ਨੂੰ ਵਧਾਓ, ਮੀਟਿੰਗਾਂ, ਤਕਨੀਕੀ ਵਰਕਸ਼ਾਪਾਂ, ਸਿਖਲਾਈਆਂ, ਅਤੇ ਮਜ਼ੇਦਾਰ ਗਤੀਵਿਧੀਆਂ ਕਰੋ। ਇਹ ਫਲ ਦਿੰਦਾ ਹੈ: ਲੋਕ ਅਭਿਆਸਾਂ ਨੂੰ ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਦੇਖੋ ਕਿ ਕਿਸ ਨੇ ਕੀ ਕੀਤਾ, ਜਾਣੋ ਕਿ ਕਿੱਥੇ ਜਾਣਾ ਹੈ, ਕੰਪਨੀ ਦੇ ਅੰਦਰ ਹਾਈਪ ਅਤੇ ਸਿਹਤਮੰਦ ਮੁਕਾਬਲਾ ਹੈ।
5. ਉਹਨਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੈ ਜੋ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਹਨ, ਉਹਨਾਂ ਟੀਮਾਂ ਦੇ ਨਾਲ ਜੋ ਪਰਿਪੱਕ ਨਹੀਂ ਹੋਏ ਹਨ, ਦਿਲਚਸਪੀ ਰੱਖਣ ਵਾਲੀਆਂ ਟੀਮਾਂ ਅਤੇ ਵਫ਼ਾਦਾਰ ਲੋਕਾਂ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰਨਾ ਬਿਹਤਰ ਹੈ.
6. ਚੁਣਿਆ ਹੋਇਆ ਹੱਲ ਉਹਨਾਂ ਇੰਜੀਨੀਅਰਾਂ ਲਈ ਸੁਵਿਧਾਜਨਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਇਸਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।
7. ਬਾਹਰੀ ਵਿਕਾਸ ਕੋਈ ਬਲੌਕਰ ਨਹੀਂ ਹੈ, ਅਭਿਆਸਾਂ ਨੂੰ ਉੱਥੇ ਵੀ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਟੀਮ ਦੀ ਖੁਦ ਦੀ ਇੱਛਾ ਹੈ.

ਥੋੜਾ ਹੋਰ ਫਾਇਦਾ

ਐਲੇਗਜ਼ੈਂਡਰ ਚਿਸਤਿਆਕੋਵ, vdsina.ru ਤੋਂ, DevOps ਵਿੱਚ ਉਹਨਾਂ ਲਈ ਪੜ੍ਹਨ ਯੋਗ ਕਿਤਾਬਾਂ ਦੀ ਸੂਚੀ:

1. ਇਰੀਨਾ ਯਾਕੁਟੇਨਕੋ "ਇੱਛਾ ਅਤੇ ਸੰਜਮ।"
2. ਡੈਨੀਅਲ ਕਾਹਨੇਮੈਨ "ਸੋਚਣਾ, ਤੇਜ਼ ਅਤੇ ਹੌਲੀ"
3. ਬਾਰਬਰਾ ਓਕਲੇ "ਨੰਬਰਾਂ ਲਈ ਇੱਕ ਮਨ"।
4. ਮੈਕਸਿਮ ਡੋਰੋਫੀਵ "ਜੇਡੀ ਤਕਨੀਕਾਂ".
5. ਵਿਕਟਰ ਫਰੈਂਕਲ "ਅਰਥ ਲਈ ਮਨੁੱਖ ਦੀ ਖੋਜ"।

ਵੇਖਦੇ ਰਹੇ

ਅਸੀਂ DevOps ਨੂੰ ਵੀ ਪਿਆਰ ਕਰਦੇ ਹਾਂ। ਲੜੀਵਾਰ ਘੋਸ਼ਣਾਵਾਂ ਦੀ ਪਾਲਣਾ ਕਰੋ @DevOps ਅਤੇ @Kubernetes, ਅਤੇ ਨਾਲ ਹੀ ਹੋਰ Mail.ru ਕਲਾਉਡ ਸੋਲਿਊਸ਼ਨ ਇਵੈਂਟਸ, ਸਾਡੇ ਟੈਲੀਗ੍ਰਾਮ ਚੈਨਲ ਵਿੱਚ: t.me/k8s_mail

ਸਰੋਤ: www.habr.com