DevOps ਕੌਣ ਹਨ?

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

ਅਸੀਂ ਅਜੇ ਵੀ ਸਹਿਕਰਮੀਆਂ ਦੀ ਭਾਲ ਕਰ ਰਹੇ ਹਾਂ, ਕਿਉਂਕਿ DevOps ਲੇਬਲ ਦੇ ਪਿੱਛੇ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੇ ਇੰਜੀਨੀਅਰਾਂ ਦੀ ਇੱਕ ਬਹੁਤ ਵੱਡੀ ਪਰਤ ਛੁਪੀ ਹੋਈ ਹੈ।

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

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

ਤਾਂ DevOps ਇੰਜੀਨੀਅਰ ਕੌਣ ਹਨ?

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

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

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

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

ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਸਰੋਤ ਦੇ ਮਾਹਰ ਗਿਆਨ ਦੇ ਪੱਧਰ ਵਿੱਚ ਇਸੇ ਤਰ੍ਹਾਂ ਦੇ “ਝੂਠ” ਅੱਜ ਵੀ ਜਾਰੀ ਹਨ। ਪਰ ਅਸੀਂ ਥੋੜਾ ਜਿਹਾ ਧਿਆਨ ਖਿੱਚਦੇ ਹਾਂ, ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ ਨੁਕਤੇ ਹਨ ਜੋ ਉਜਾਗਰ ਕਰਨ ਯੋਗ ਹਨ.

ਬਿਲਡ ਇੰਜੀਨੀਅਰ/ਰਿਲੀਜ਼ ਇੰਜੀਨੀਅਰ

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

ਓਪਸ ਬਹੁਤ ਵੱਖਰੇ ਹਨ

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

• TechOps - enikey ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ ਉਰਫ ਹੈਲਪਡੈਸਕ ਇੰਜੀਨੀਅਰ
• LiveOps - ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ ਮੁੱਖ ਤੌਰ 'ਤੇ ਉਤਪਾਦਨ ਦੇ ਵਾਤਾਵਰਣ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹਨ
• CloudOps - ਜਨਤਕ ਕਲਾਉਡਜ਼ Azure, AWS, GCP, ਆਦਿ ਵਿੱਚ ਮਾਹਰ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ।
• PlatOps/InfraOps/SysOps - ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ।
• NetOps - ਨੈੱਟਵਰਕ ਪ੍ਰਸ਼ਾਸਕ
• SecOps - ਜਾਣਕਾਰੀ ਸੁਰੱਖਿਆ ਵਿੱਚ ਮਾਹਰ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ - PCI ਪਾਲਣਾ, CIS ਪਾਲਣਾ, ਪੈਚਿੰਗ, ਆਦਿ।

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

ਇਸ ਕਿਸਮ ਦੇ ਕੰਮ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨੂੰ ਨਿਭਾਉਣ ਲਈ, ਇਸ ਵਿਅਕਤੀ ਕੋਲ ਨਾ ਸਿਰਫ ਵਿਕਾਸ ਅਤੇ ਟੈਸਟਿੰਗ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੇ ਸਾਧਨ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਸਗੋਂ ਉਤਪਾਦ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਪ੍ਰਬੰਧਨ ਦੇ ਨਾਲ-ਨਾਲ ਸਰੋਤ ਯੋਜਨਾਬੰਦੀ ਵੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਸ ਸਮਝ ਵਿੱਚ DevOps ਜਾਂ ਤਾਂ IT ਵਿੱਚ, ਜਾਂ R&D ਵਿੱਚ, ਜਾਂ PMO ਵਿੱਚ ਵੀ ਸਥਿਤ ਨਹੀਂ ਹੋ ਸਕਦੇ ਹਨ; ਇਸਦਾ ਇਹਨਾਂ ਸਾਰੇ ਖੇਤਰਾਂ ਵਿੱਚ ਪ੍ਰਭਾਵ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ - ਕੰਪਨੀ ਦੇ ਤਕਨੀਕੀ ਨਿਰਦੇਸ਼ਕ, ਮੁੱਖ ਤਕਨੀਕੀ ਅਧਿਕਾਰੀ।

ਕੀ ਇਹ ਤੁਹਾਡੀ ਕੰਪਨੀ ਵਿੱਚ ਸੱਚ ਹੈ? - ਮੈਨੂੰ ਸ਼ਕ. ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਇਹ ਜਾਂ ਤਾਂ IT ਜਾਂ R&D ਹੈ।

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

DevOps ਸਰੋਤ ਮਾਰਕੀਟ

ਆਓ ਵੱਖ-ਵੱਖ ਕੰਪਨੀਆਂ ਤੋਂ DevOps ਅਹੁਦਿਆਂ ਲਈ ਕਈ ਖਾਲੀ ਅਸਾਮੀਆਂ ਨੂੰ ਵੇਖੀਏ।

ਅਸੀਂ ਤੁਹਾਡੇ ਨਾਲ ਮਿਲਣ ਲਈ ਤਿਆਰ ਹਾਂ ਜੇਕਰ ਤੁਸੀਂ:

1. ਤੁਸੀਂ ਜ਼ੈਬਿਕਸ ਦੇ ਮਾਲਕ ਹੋ ਅਤੇ ਜਾਣਦੇ ਹੋ ਕਿ ਪ੍ਰੋਮੀਥੀਅਸ ਕੀ ਹੈ;
2. iptables;
3. BASH ਪੀਐਚਡੀ ਵਿਦਿਆਰਥੀ;
4. ਪ੍ਰੋਫੈਸਰ ਜਵਾਬਦੇਹ;
5. ਲੀਨਕਸ ਗੁਰੂ;
6. ਜਾਣੋ ਕਿ ਡੀਬਗਿੰਗ ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰਨੀ ਹੈ ਅਤੇ ਡਿਵੈਲਪਰਾਂ (php/java/python) ਨਾਲ ਮਿਲ ਕੇ ਐਪਲੀਕੇਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਕਿਵੇਂ ਲੱਭਣਾ ਹੈ;
7. ਰੂਟਿੰਗ ਤੁਹਾਨੂੰ ਸਨਕੀ ਨਹੀਂ ਬਣਾਉਂਦਾ;
8. ਸਿਸਟਮ ਸੁਰੱਖਿਆ ਲਈ ਮਹੱਤਵਪੂਰਨ ਧਿਆਨ ਦਿਓ;
9. “ਕੁਝ ਵੀ ਅਤੇ ਹਰ ਚੀਜ਼” ਦਾ ਬੈਕਅੱਪ ਲਓ, ਅਤੇ ਇਸ “ਕੁਝ ਵੀ ਅਤੇ ਹਰ ਚੀਜ਼” ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਰੀਸਟੋਰ ਕਰੋ;
10. ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਸਿਸਟਮ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਕਿਵੇਂ ਸੰਰਚਿਤ ਕਰਨਾ ਹੈ ਕਿ ਘੱਟੋ ਘੱਟ ਤੋਂ ਵੱਧ ਤੋਂ ਵੱਧ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ;
11. Postgres ਅਤੇ MySQL 'ਤੇ ਸੌਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈਟ ਅਪ ਕਰੋ;
12. CI/CD ਨੂੰ ਸੈਟ ਅਪ ਕਰਨਾ ਅਤੇ ਐਡਜਸਟ ਕਰਨਾ ਤੁਹਾਡੇ ਲਈ ਨਾਸ਼ਤੇ/ਲੰਚ/ਡਿਨਰ ਵਾਂਗ ਜ਼ਰੂਰੀ ਹੈ।
13. AWS ਨਾਲ ਅਨੁਭਵ ਹੈ;
14. ਕੰਪਨੀ ਨਾਲ ਵਿਕਸਤ ਕਰਨ ਲਈ ਤਿਆਰ;

ਇਸ ਤਰ੍ਹਾਂ:

• 1 ਤੋਂ 6 ਤੱਕ - ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ
• 7 - ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਨੈੱਟਵਰਕ ਪ੍ਰਸ਼ਾਸਨ, ਜੋ ਕਿ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ, ਮੱਧ ਪੱਧਰ ਵਿੱਚ ਵੀ ਫਿੱਟ ਹੁੰਦਾ ਹੈ
• 8 - ਥੋੜ੍ਹੀ ਜਿਹੀ ਸੁਰੱਖਿਆ, ਜੋ ਕਿ ਇੱਕ ਮੱਧ ਪੱਧਰੀ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ ਲਈ ਲਾਜ਼ਮੀ ਹੈ
• 9-11 - ਮੱਧ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ
• 12 — ਨਿਰਧਾਰਤ ਕਾਰਜਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਜਾਂ ਤਾਂ ਮਿਡਲ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ ਜਾਂ ਬਿਲਡ ਇੰਜੀਨੀਅਰ
• 13 - ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ - ਮਿਡਲ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ, ਜਾਂ ਅਖੌਤੀ CloudOps, ਫੰਡਾਂ ਦੀ ਕੁਸ਼ਲ ਵਰਤੋਂ ਅਤੇ ਰੱਖ-ਰਖਾਅ 'ਤੇ ਭਾਰ ਘਟਾਉਣ ਲਈ, ਕਿਸੇ ਖਾਸ ਹੋਸਟਿੰਗ ਸਾਈਟ ਦੀਆਂ ਸੇਵਾਵਾਂ ਦਾ ਉੱਨਤ ਗਿਆਨ।

ਇਸ ਅਸਾਮੀ ਦਾ ਸਾਰ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ ਮਿਡਲ/ਸੀਨੀਅਰ ਸਿਸਟਮ ਐਡਮਿਨਿਸਟ੍ਰੇਟਰ ਮੁੰਡਿਆਂ ਲਈ ਕਾਫੀ ਹੈ।

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

ਆਉ ਇੱਕ ਹੋਰ ਖਾਲੀ ਥਾਂ ਤੇ ਵਿਚਾਰ ਕਰੀਏ:

1. ਉੱਚ-ਲੋਡ ਸਿਸਟਮ ਬਣਾਉਣ ਵਿੱਚ ਅਨੁਭਵ;
2. ਲੀਨਕਸ OS, ਜਨਰਲ ਸਿਸਟਮ ਸਾਫਟਵੇਅਰ ਅਤੇ ਵੈੱਬ ਸਟੈਕ (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK) ਦਾ ਸ਼ਾਨਦਾਰ ਗਿਆਨ;
3. ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਸਿਸਟਮ (KVM, VMWare, LXC/Docker) ਦੇ ਨਾਲ ਅਨੁਭਵ;
4. ਸਕ੍ਰਿਪਟਿੰਗ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਮੁਹਾਰਤ;
5. ਨੈਟਵਰਕ ਪ੍ਰੋਟੋਕੋਲ ਨੈਟਵਰਕ ਦੇ ਓਪਰੇਟਿੰਗ ਸਿਧਾਂਤਾਂ ਦੀ ਸਮਝ;
6. ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਨਿਰਮਾਣ ਦੇ ਸਿਧਾਂਤਾਂ ਦੀ ਸਮਝ;
7. ਸੁਤੰਤਰਤਾ ਅਤੇ ਪਹਿਲਕਦਮੀ;

ਆਓ ਦੇਖੀਏ:

• 1 - ਸੀਨੀਅਰ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ
• 2 - ਇਸ ਸਟੈਕ ਵਿੱਚ ਰੱਖੇ ਗਏ ਅਰਥ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ - ਮੱਧ/ਸੀਨੀਅਰ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ
• 3 - ਕੰਮ ਦਾ ਤਜਰਬਾ, ਸਮੇਤ, ਦਾ ਮਤਲਬ ਹੋ ਸਕਦਾ ਹੈ - "ਕਲੱਸਟਰ ਨੇ ਨਹੀਂ ਵਧਾਇਆ, ਪਰ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਨੂੰ ਬਣਾਇਆ ਅਤੇ ਪ੍ਰਬੰਧਿਤ ਕੀਤਾ, ਇੱਕ ਡੌਕਰ ਹੋਸਟ ਸੀ, ਕੰਟੇਨਰਾਂ ਤੱਕ ਪਹੁੰਚ ਉਪਲਬਧ ਨਹੀਂ ਸੀ" - ਮਿਡਲ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ
• 4 - ਜੂਨੀਅਰ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ - ਹਾਂ, ਇੱਕ ਪ੍ਰਸ਼ਾਸਕ ਜੋ ਮੂਲ ਆਟੋਮੇਸ਼ਨ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਕਿਵੇਂ ਲਿਖਣਾ ਨਹੀਂ ਜਾਣਦਾ, ਭਾਸ਼ਾ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ, ਇੱਕ ਪ੍ਰਬੰਧਕ ਨਹੀਂ - ਐਨੀਕੀ।
• 5 - ਮਿਡਲ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ
• 6 - ਸੀਨੀਅਰ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ

ਸੰਖੇਪ ਕਰਨ ਲਈ - ਮੱਧ/ਸੀਨੀਅਰ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ

ਇੱਕ ਹੋਰ:

1. ਵਿਕਾਸ ਅਨੁਭਵ;
2. CI/CD ਪ੍ਰਕਿਰਿਆਵਾਂ ਬਣਾਉਣ ਲਈ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਉਤਪਾਦਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਅਨੁਭਵ। Gitlab CI ਇੱਕ ਫਾਇਦਾ ਹੋਵੇਗਾ;
3. ਕੰਟੇਨਰਾਂ ਅਤੇ ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਨਾਲ ਕੰਮ ਕਰਨਾ; ਜੇ ਤੁਸੀਂ ਡੌਕਰ ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਤਾਂ ਚੰਗਾ, ਪਰ ਜੇ ਤੁਸੀਂ k8s ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਤਾਂ ਵਧੀਆ!
4. ਇੱਕ ਚੁਸਤ ਟੀਮ ਵਿੱਚ ਕੰਮ ਕਰਨ ਦਾ ਅਨੁਭਵ;
5. ਕਿਸੇ ਵੀ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ ਦਾ ਗਿਆਨ;

ਚਲੋ ਵੇਖਦੇ ਹਾਂ:

• 1 - ਹਮ... ਮੁੰਡਿਆਂ ਦਾ ਕੀ ਮਤਲਬ ਹੈ? =) ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਉਹ ਖੁਦ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਇਸਦੇ ਪਿੱਛੇ ਕੀ ਛੁਪਿਆ ਹੋਇਆ ਹੈ
• 2 - ਇੰਜੀਨੀਅਰ ਬਣਾਓ
• 3 - ਮਿਡਲ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ
• 4 - ਨਰਮ ਹੁਨਰ, ਅਸੀਂ ਇਸ 'ਤੇ ਫਿਲਹਾਲ ਵਿਚਾਰ ਨਹੀਂ ਕਰਾਂਗੇ, ਹਾਲਾਂਕਿ ਚੁਸਤ ਇਕ ਹੋਰ ਚੀਜ਼ ਹੈ ਜਿਸਦੀ ਵਿਆਖਿਆ ਇਸ ਤਰੀਕੇ ਨਾਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜੋ ਸੁਵਿਧਾਜਨਕ ਹੈ।
• 5 - ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਰਬੋਜ਼ - ਇਹ ਇੱਕ ਸਕ੍ਰਿਪਟਿੰਗ ਭਾਸ਼ਾ ਜਾਂ ਇੱਕ ਸੰਕਲਿਤ ਭਾਸ਼ਾ ਹੋ ਸਕਦੀ ਹੈ। ਮੈਂ ਹੈਰਾਨ ਹਾਂ ਕਿ ਕੀ ਸਕੂਲ ਵਿਚ ਪਾਸਕਲ ਅਤੇ ਬੇਸਿਕ ਵਿਚ ਲਿਖਣਾ ਉਨ੍ਹਾਂ ਦੇ ਅਨੁਕੂਲ ਹੋਵੇਗਾ? =)

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

ਇੱਕ ਵਾਰ, ਮੈਂ ਇੱਕ ਵਿਅਕਤੀ ਦੀ ਇੰਟਰਵਿਊ ਕੀਤੀ ਜਿਸਨੇ ਓਪਨਸਟੈਕ ਦੇ ਸਿਖਰ 'ਤੇ ਆਪਣੇ ਕੰਮ ਵਿੱਚ k8s ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਅਤੇ ਉਸਨੇ ਇਸ ਬਾਰੇ ਗੱਲ ਕੀਤੀ ਕਿ ਉਸਨੇ ਇਸ 'ਤੇ ਸੇਵਾਵਾਂ ਕਿਵੇਂ ਤਾਇਨਾਤ ਕੀਤੀਆਂ, ਹਾਲਾਂਕਿ, ਜਦੋਂ ਮੈਂ ਓਪਨਸਟੈਕ ਬਾਰੇ ਪੁੱਛਿਆ, ਤਾਂ ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਇਹ ਪ੍ਰਬੰਧਿਤ ਕੀਤਾ ਗਿਆ ਸੀ, ਨਾਲ ਹੀ ਸਿਸਟਮ ਦੁਆਰਾ ਉਭਾਰਿਆ ਗਿਆ ਸੀ. ਪ੍ਰਬੰਧਕ। ਕੀ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਸੋਚਦੇ ਹੋ ਕਿ ਇੱਕ ਵਿਅਕਤੀ ਜਿਸਨੇ ਓਪਨਸਟੈਕ ਸਥਾਪਤ ਕੀਤਾ ਹੈ, ਭਾਵੇਂ ਉਹ ਆਪਣੇ ਪਿੱਛੇ ਕਿਹੜਾ ਪਲੇਟਫਾਰਮ ਵਰਤਦਾ ਹੈ, ਉਹ k8s ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੈ? =)
ਇਹ ਬਿਨੈਕਾਰ ਅਸਲ ਵਿੱਚ ਇੱਕ DevOps ਨਹੀਂ ਹੈ, ਪਰ ਇੱਕ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ ਹੈ ਅਤੇ, ਵਧੇਰੇ ਸਟੀਕ ਹੋਣ ਲਈ, ਇੱਕ Kubernetes ਪ੍ਰਸ਼ਾਸਕ ਹੈ।

ਆਉ ਇੱਕ ਵਾਰ ਫਿਰ ਸੰਖੇਪ ਕਰੀਏ - ਮਿਡਲ/ਸੀਨੀਅਰ ਸਿਸਟਮ ਐਡਮਿਨਿਸਟ੍ਰੇਟਰ ਉਹਨਾਂ ਲਈ ਕਾਫੀ ਹੋਵੇਗਾ।

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

ਦਰਸਾਏ ਗਏ ਅਸਾਮੀਆਂ ਲਈ ਪ੍ਰਸਤਾਵਿਤ ਤਨਖਾਹਾਂ ਦੀ ਰੇਂਜ 90k-200k ਹੈ
ਹੁਣ ਮੈਂ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕਾਂ ਅਤੇ DevOps ਇੰਜੀਨੀਅਰਾਂ ਦੇ ਮੁਦਰਾ ਇਨਾਮਾਂ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਸਮਾਨਤਾ ਖਿੱਚਣਾ ਚਾਹਾਂਗਾ।

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

ਇੱਕ ਤਜਰਬਾ:

1. 3 ਸਾਲ ਤੱਕ - ਜੂਨੀਅਰ
2. 6 ਸਾਲ ਦੀ ਉਮਰ ਤੱਕ - ਮੱਧ
3. 6 ਤੋਂ ਵੱਧ - ਸੀਨੀਅਰ

ਕਰਮਚਾਰੀ ਖੋਜ ਸਾਈਟ ਪੇਸ਼ਕਸ਼ ਕਰਦੀ ਹੈ:
ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ:

1. ਜੂਨੀਅਰ - 2 ਸਾਲ - 50k ਰਬ.
2. ਮੱਧ - 5 ਸਾਲ - 70k ਰਬ.
3. ਸੀਨੀਅਰ - 11 ਸਾਲ - 100k ਰਬ.

DevOps ਇੰਜੀਨੀਅਰ:

1. ਜੂਨੀਅਰ - 2 ਸਾਲ - 100k ਰਬ.
2. ਮੱਧ - 3 ਸਾਲ - 160k ਰਬ.
3. ਸੀਨੀਅਰ - 6 ਸਾਲ - 220k ਰਬ.

"DevOps" ਦੇ ਤਜਰਬੇ ਦੇ ਅਨੁਸਾਰ, ਤਜਰਬੇ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਗਈ ਸੀ ਕਿ ਘੱਟੋ ਘੱਟ ਕਿਸੇ ਤਰ੍ਹਾਂ SDLC ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ ਗਿਆ ਸੀ.

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

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

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

ਤਾਂ ਉਹ ਕੌਣ ਹਨ? DevOps ਜਾਂ ਲਾਲਚੀ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ? =)

ਕਿਵੇਂ ਜੀਣਾ ਜਾਰੀ ਰੱਖਣਾ ਹੈ?

ਰੁਜ਼ਗਾਰਦਾਤਾਵਾਂ ਨੂੰ ਲੋੜਾਂ ਨੂੰ ਵਧੇਰੇ ਸਹੀ ਢੰਗ ਨਾਲ ਤਿਆਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਬਿਲਕੁਲ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਲੇਬਲਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਨਾ ਸੁੱਟੋ। ਤੁਸੀਂ ਨਹੀਂ ਜਾਣਦੇ ਕਿ DevOps ਕੀ ਕਰਦੇ ਹਨ - ਤੁਹਾਨੂੰ ਉਸ ਸਥਿਤੀ ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

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

ਸਰੋਤ: www.habr.com