ਕੋਈ DevOps ਇੰਜੀਨੀਅਰ ਨਹੀਂ ਹਨ। ਫਿਰ ਕੌਣ ਮੌਜੂਦ ਹੈ, ਅਤੇ ਇਸ ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ?

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

ਇਸ ਪੋਸਟ ਵਿੱਚ ਮੈਂ ਇਸ ਬਾਰੇ ਥੋੜਾ ਜਿਹਾ ਗੱਲ ਕਰਨਾ ਚਾਹਾਂਗਾ ਕਿ ਅਸੀਂ ਜ਼ਿੰਦਗੀ ਦੇ ਇਸ ਮੋੜ 'ਤੇ ਕਿਵੇਂ ਪਹੁੰਚੇ, DevOps ਅਸਲ ਵਿੱਚ ਕੀ ਹੈ ਅਤੇ ਹੁਣ ਇਸ ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ।

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

ਸਭਿਆਚਾਰ ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਬਾਰੇ

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

ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ ਅਤੇ ਸੇਵਾ ਪ੍ਰਬੰਧਨ ਲਈ ਇੱਕ SRE ਪਹੁੰਚ ਵਿੱਚ ਅੰਤਰ ਦਾ ਵਰਣਨ ਕਰਨਾ ਮਸ਼ਹੂਰ Google SRE ਬੁੱਕ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ. ਦੇ ਅੰਦਰ ਦਿਲਚਸਪ ਅਧਿਐਨ ਕੀਤੇ ਗਏ ਹਨ DORA ਸਰਵੇਖਣ - ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਸਭ ਤੋਂ ਵਧੀਆ ਡਿਵੈਲਪਰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਇੱਕ ਘੰਟੇ ਵਿੱਚ ਇੱਕ ਵਾਰ ਤੋਂ ਵੱਧ ਤੇਜ਼ੀ ਨਾਲ ਉਤਪਾਦਨ ਵਿੱਚ ਨਵੀਆਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦਾ ਪ੍ਰਬੰਧ ਕਰਦੇ ਹਨ। ਉਹ ਆਪਣੇ ਹੱਥਾਂ ਨਾਲ 10% ਤੋਂ ਵੱਧ ਨਹੀਂ ਟੈਸਟ ਕਰਦੇ ਹਨ (ਇਸ ਤੋਂ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਪਿਛਲੇ ਸਾਲ ਦੇ DORA). ਉਹ ਇਹ ਕਿਵੇਂ ਕਰਦੇ ਹਨ? ਰਿਪੋਰਟ ਦੇ ਸਿਰਲੇਖਾਂ ਵਿੱਚੋਂ ਇੱਕ "ਐਕਸਲ ਜਾਂ ਮਰੋ" ਕਹਿੰਦਾ ਹੈ। ਟੈਸਟਿੰਗ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਇਹਨਾਂ ਅੰਕੜਿਆਂ ਦੀ ਵਿਸਤ੍ਰਿਤ ਚਰਚਾ ਲਈ, ਤੁਸੀਂ ਬਾਰੂਚ ਸਡੋਗੁਰਸਕੀ ਦੇ ਮੁੱਖ ਭਾਸ਼ਣ ਦਾ ਹਵਾਲਾ ਦੇ ਸਕਦੇ ਹੋ “ਸਾਡੇ ਕੋਲ DevOps ਹਨ। ਆਉ ਸਾਰੇ ਟੈਸਟਰਾਂ ਨੂੰ ਬਰਖਾਸਤ ਕਰੀਏ।" ਸਾਡੀ ਦੂਜੀ ਕਾਨਫਰੰਸ, ਹੇਜ਼ਨਬੱਗ ਵਿਖੇ।

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

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

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

ਦੁਸ਼ਟ ਚੱਕਰ

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

ਕਲਪਨਾ ਕਰੋ: ਕੱਲ੍ਹ ਤੁਸੀਂ ਖਿਮਕੀ ਵਿੱਚ ਸ਼ਵਾਰਮਾ ਬਣਾ ਰਹੇ ਸੀ, ਅਤੇ ਅੱਜ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਵੱਡੇ ਆਦਮੀ, ਇੱਕ ਸੀਨੀਅਰ ਭਰਤੀ ਹੋ। ਉਮੀਦਵਾਰਾਂ ਦੀ ਖੋਜ ਅਤੇ ਚੋਣ ਕਰਨ ਦੀ ਪੂਰੀ ਪ੍ਰਕਿਰਿਆ ਹੈ, ਸਭ ਕੁਝ ਆਸਾਨ ਨਹੀਂ ਹੈ, ਤੁਹਾਨੂੰ ਸਮਝਣ ਦੀ ਲੋੜ ਹੈ। ਮੰਨ ਲਓ ਕਿ ਇੱਕ ਵਿਭਾਗ ਦਾ ਮੁਖੀ ਕਹਿੰਦਾ ਹੈ: X ਵਿੱਚ ਇੱਕ ਮਾਹਰ ਲੱਭੋ। ਅਸੀਂ X ਨੂੰ "ਇੰਜੀਨੀਅਰ" ਸ਼ਬਦ ਸੌਂਪਦੇ ਹਾਂ, ਅਤੇ ਅਸੀਂ ਪੂਰਾ ਕਰ ਲਿਆ। ਲੀਨਕਸ ਦੀ ਲੋੜ ਹੈ? ਖੈਰ, ਇਹ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਇੱਕ ਲੀਨਕਸ ਇੰਜੀਨੀਅਰ ਹੈ, ਜੇ ਤੁਸੀਂ DevOps ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇੱਕ DevOps ਇੰਜੀਨੀਅਰ. ਖਾਲੀ ਥਾਂ ਵਿੱਚ ਨਾ ਸਿਰਫ਼ ਇੱਕ ਸਿਰਲੇਖ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ, ਸਗੋਂ ਅੰਦਰ ਕੁਝ ਟੈਕਸਟ ਵੀ ਦਰਜ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਤੁਹਾਡੀ ਕਲਪਨਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਗੂਗਲ ਤੋਂ ਕੀਵਰਡਸ ਦਾ ਇੱਕ ਸੈੱਟ ਦਾਖਲ ਕਰਨਾ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਹੈ। DevOps ਵਿੱਚ ਦੋ ਸ਼ਬਦ ਹੁੰਦੇ ਹਨ - “Dev” ਅਤੇ “Ops”, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਾਨੂੰ ਡਿਵੈਲਪਰਾਂ ਅਤੇ ਪ੍ਰਸ਼ਾਸਕਾਂ ਨਾਲ ਸਬੰਧਤ ਕੀਵਰਡਾਂ ਨੂੰ ਇਕੱਠੇ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਸਾਰੇ ਇੱਕ ਢੇਰ ਵਿੱਚ। ਇਸ ਤਰ੍ਹਾਂ 42 ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਮੁਹਾਰਤ ਅਤੇ ਕੁਬਰਨੇਟਸ ਅਤੇ ਸਵਰਮ ਦੀ ਇੱਕੋ ਸਮੇਂ ਵਰਤੋਂ ਕਰਨ ਦੇ 20 ਸਾਲਾਂ ਬਾਰੇ ਖਾਲੀ ਅਸਾਮੀਆਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ। ਕਾਰਜਕਾਰੀ ਚਿੱਤਰ।

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

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

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

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

ਲੋਕ DevOps ਵਿੱਚ ਕੀ ਕਰਦੇ ਹਨ (ਅਸਲ ਵਿੱਚ)

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

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

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

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

ਬੇਸ਼ੱਕ, ਮੁੱਦੇ ਦਾ ਇੱਕ ਤਕਨੀਕੀ ਹਿੱਸਾ ਵੀ ਹੈ. ਜੇਕਰ ਤੁਹਾਡਾ ਨਵਾਂ ਕੋਡ ਇੱਕ ਮਹੀਨੇ ਵਿੱਚ ਟੈਸਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਇੱਕ ਸਾਲ ਬਾਅਦ ਹੀ ਜਾਰੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਸਦੀ ਗਤੀ ਵਧਾਉਣਾ ਸਰੀਰਕ ਤੌਰ 'ਤੇ ਅਸੰਭਵ ਹੈ, ਤਾਂ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਚੰਗੇ ਅਭਿਆਸਾਂ ਨੂੰ ਪੂਰਾ ਨਾ ਕਰੋ। ਚੰਗੇ ਅਭਿਆਸਾਂ ਦਾ ਸਮਰਥਨ ਚੰਗੇ ਸਾਧਨਾਂ ਦੁਆਰਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਰੂਪ ਵਿੱਚ-ਕੋਡ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਤੁਸੀਂ AWS CloudFormation ਅਤੇ Terraform ਤੋਂ Chef-Ansible-puppet ਤੱਕ ਕੁਝ ਵੀ ਵਰਤ ਸਕਦੇ ਹੋ। ਤੁਹਾਨੂੰ ਇਹ ਸਭ ਕੁਝ ਜਾਣਨ ਅਤੇ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਅਤੇ ਇਹ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਇੰਜੀਨੀਅਰਿੰਗ ਅਨੁਸ਼ਾਸਨ ਹੈ। ਕਾਰਨ ਨੂੰ ਪ੍ਰਭਾਵ ਨਾਲ ਉਲਝਾਉਣਾ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ: ਪਹਿਲਾਂ ਤੁਸੀਂ SRE ਦੇ ਸਿਧਾਂਤਾਂ ਦੇ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦੇ ਹੋ ਅਤੇ ਕੇਵਲ ਤਦ ਹੀ ਇਹਨਾਂ ਸਿਧਾਂਤਾਂ ਨੂੰ ਕੁਝ ਖਾਸ ਤਕਨੀਕੀ ਹੱਲਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਲਾਗੂ ਕਰਦੇ ਹੋ। ਇਸ ਦੇ ਨਾਲ ਹੀ, SRE ਇੱਕ ਬਹੁਤ ਹੀ ਵਿਆਪਕ ਕਾਰਜਪ੍ਰਣਾਲੀ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਇਹ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਜੇਨਕਿਨਸ ਨੂੰ ਕਿਵੇਂ ਸਥਾਪਤ ਕਰਨਾ ਹੈ, ਪਰ ਪੰਜ ਬੁਨਿਆਦੀ ਸਿਧਾਂਤ:

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

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

SRE ਅਨੁਸ਼ਾਸਨ ਵਿੱਚ, ਸਾਧਨਾਂ ਦੀ ਵਰਤੋਂ ਸਫਲਤਾ ਦਾ ਇੱਕ ਹਿੱਸਾ ਹੈ, ਹਾਲਾਂਕਿ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਸਾਨੂੰ ਲਗਾਤਾਰ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਵਿਕਾਸ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਇਹ ਦੇਖਣਾ ਹੈ ਕਿ ਸੰਸਾਰ ਵਿੱਚ ਕੀ ਹੋ ਰਿਹਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਸਾਡੇ ਕੰਮ ਵਿੱਚ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

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

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

ਇਸ ਸਭ ਦਾ ਕੀ ਕਰਨਾ ਹੈ

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

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

• ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਸੱਭਿਆਚਾਰ;
• ਸਾਈਟ ਭਰੋਸੇਯੋਗਤਾ ਇੰਜੀਨੀਅਰਿੰਗ;
• ਕਲਾਉਡ ਨੇਟਿਵ;

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

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

ਬੱਸ ਇਹ ਸਮਝਣਾ ਬਾਕੀ ਹੈ ਕਿ ਕੀ ਕਰਨਾ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ DevOps ਇੰਜੀਨੀਅਰ ਹੋ! ਪਹਿਲਾਂ, ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਕਿ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦੇ ਹੋ. ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਇਸ ਸ਼ਬਦ ਨੂੰ ਕਾਲ ਕਰਨਾ ਪਸੰਦ ਕਰਦੇ ਹਨ:

• ਡਿਵੈਲਪਰ ਜੋ ਬੁਨਿਆਦੀ ਢਾਂਚੇ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ। SRE ਅਤੇ Cloud Native ਬਾਰੇ ਰਿਪੋਰਟਾਂ ਦੇ ਸਮੂਹ ਤੁਹਾਡੇ ਲਈ ਸਭ ਤੋਂ ਢੁਕਵੇਂ ਹਨ।
• ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ। ਇਹ ਇੱਥੇ ਹੋਰ ਗੁੰਝਲਦਾਰ ਹੈ. DevOops ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਨ ਬਾਰੇ ਨਹੀਂ ਹੈ। ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਨ ਦੇ ਵਿਸ਼ੇ 'ਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਸ਼ਾਨਦਾਰ ਕਾਨਫਰੰਸਾਂ, ਕਿਤਾਬਾਂ, ਲੇਖ, ਇੰਟਰਨੈਟ ਤੇ ਵੀਡੀਓ ਆਦਿ ਹਨ. ਦੂਜੇ ਪਾਸੇ, ਜੇਕਰ ਤੁਸੀਂ ਸੱਭਿਆਚਾਰ ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਸਮਝਣ, ਕਲਾਉਡ ਟੈਕਨਾਲੋਜੀ ਅਤੇ ਕਲਾਉਡ ਨੇਟਿਵ ਨਾਲ ਜੀਵਨ ਦੇ ਵੇਰਵਿਆਂ ਬਾਰੇ ਸਿੱਖਣ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਆਪਣੇ ਆਪ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਅਸੀਂ ਤੁਹਾਨੂੰ ਮਿਲਣਾ ਪਸੰਦ ਕਰਾਂਗੇ! ਇਸ ਬਾਰੇ ਸੋਚੋ: ਤੁਸੀਂ ਪ੍ਰਸ਼ਾਸਨ ਕਰ ਰਹੇ ਹੋ, ਅਤੇ ਫਿਰ ਤੁਸੀਂ ਕੀ ਕਰੋਗੇ? ਅਚਾਨਕ ਆਪਣੇ ਆਪ ਨੂੰ ਇੱਕ ਅਣਸੁਖਾਵੀਂ ਸਥਿਤੀ ਵਿੱਚ ਲੱਭਣ ਤੋਂ ਬਚਣ ਲਈ, ਤੁਹਾਨੂੰ ਹੁਣੇ ਸਿੱਖਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇੱਕ ਹੋਰ ਵਿਕਲਪ ਹੈ: ਤੁਸੀਂ ਕਾਇਮ ਰਹਿੰਦੇ ਹੋ ਅਤੇ ਦਾਅਵਾ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਹੋ ਖਾਸ ਤੌਰ 'ਤੇ ਇੱਕ DevOps ਇੰਜੀਨੀਅਰ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ, ਜੋ ਵੀ ਇਸਦਾ ਮਤਲਬ ਹੈ। ਫਿਰ ਸਾਨੂੰ ਤੁਹਾਨੂੰ ਨਿਰਾਸ਼ ਕਰਨਾ ਪਵੇਗਾ, DevOops DevOps ਇੰਜੀਨੀਅਰਾਂ ਲਈ ਇੱਕ ਕਾਨਫਰੰਸ ਨਹੀਂ ਹੈ!

ਤੋਂ ਸਲਾਈਡ ਕਰੋ Konstantin Diener ਦੁਆਰਾ ਰਿਪੋਰਟ ਮ੍ਯੂਨਿਚ ਵਿੱਚ

DevOops 2020 ਮਾਸਕੋ ਵਿੱਚ 29-30 ਅਪ੍ਰੈਲ ਨੂੰ ਮਾਸਕੋ ਵਿੱਚ ਆਯੋਜਿਤ ਕੀਤਾ ਜਾਵੇਗਾ, ਟਿਕਟਾਂ ਪਹਿਲਾਂ ਹੀ ਉਪਲਬਧ ਹਨ ਸਰਕਾਰੀ ਵੈਬਸਾਈਟ 'ਤੇ ਖਰੀਦੋ.

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਤੁਸੀਂ ਕਰ ਸਕਦੇ ਹੋ ਆਪਣੀ ਰਿਪੋਰਟ ਦਰਜ ਕਰੋ 8 ਫਰਵਰੀ ਤੱਕ ਕਿਰਪਾ ਕਰਕੇ ਨੋਟ ਕਰੋ ਕਿ ਫਾਰਮ ਭਰਨ ਵੇਲੇ, ਤੁਹਾਨੂੰ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਟੀਚਾ ਦਰਸ਼ਕ ਚੁਣਨਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਤੁਹਾਡੀ ਰਿਪੋਰਟ (ਸੂਚੀ ਦੇ ਅੰਦਰ ਇੱਕ ਹੈਰਾਨੀ ਦੱਬੀ ਹੋਈ ਹੈ).

ਸਰੋਤ: www.habr.com