ਇੱਕ ਵਾਰ ਫਿਰ DevOps ਅਤੇ SRE ਬਾਰੇ

ਚੈਟ ਵਿੱਚ ਹੋਈ ਚਰਚਾ ਦੇ ਆਧਾਰ 'ਤੇ AWS ਮਿੰਸਕ ਕਮਿਊਨਿਟੀ

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

prehistory

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

DevOps ਅਭਿਆਸਾਂ ਦਾ ਜਨਮ

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

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

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

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

ਸਭ ਕੁਝ ਫਿਰ ਠੀਕ ਨਹੀਂ ਰਹਿੰਦਾ।

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

ਗੂਗਲ ਵੱਲੋਂ ਐਸ.ਆਰ.ਈ.

ਗੂਗਲ ਆਇਆ, ਸਭ ਤੋਂ ਵੱਡਾ ਕੈਕਟੀ ਖਾਧਾ, ਅਤੇ ਫੈਸਲਾ ਕੀਤਾ: ਸਾਨੂੰ ਇਸਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਸਾਨੂੰ ਭਰੋਸੇਯੋਗਤਾ ਦੀ ਲੋੜ ਹੈ। ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਅਤੇ ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਨੇ ਫੈਸਲਾ ਕੀਤਾ: ਸਾਨੂੰ ਮਾਹਿਰਾਂ ਦੀ ਲੋੜ ਹੈ ਜੋ ਭਰੋਸੇਯੋਗਤਾ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਗੇ। ਉਨ੍ਹਾਂ ਨੇ ਉਨ੍ਹਾਂ ਨੂੰ SREs ਕਿਹਾ ਅਤੇ ਕਿਹਾ, ਤੁਸੀਂ ਜਾਓ, ਇਸਨੂੰ ਹਮੇਸ਼ਾ ਵਾਂਗ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਰੋ। ਇੱਥੇ ਤੁਹਾਡਾ SLI ਹੈ, ਇੱਥੇ ਤੁਹਾਡਾ SLO ਹੈ, ਇੱਥੇ ਤੁਹਾਡੀ ਨਿਗਰਾਨੀ ਹੈ। ਅਤੇ ਉਨ੍ਹਾਂ ਨੇ ਆਪਣੇ ਨੱਕ ਆਪਰੇਸ਼ਨਾਂ ਵਿੱਚ ਧੱਕ ਦਿੱਤੇ। ਅਤੇ ਉਨ੍ਹਾਂ ਨੇ ਆਪਣੇ "ਭਰੋਸੇਯੋਗ DevOps" SRE ਨੂੰ ਬੁਲਾਇਆ। ਸਭ ਕੁਝ ਠੀਕ ਜਾਪਦਾ ਹੈ, ਪਰ ਇੱਕ ਗੰਦੀ ਚਾਲ ਹੈ ਜੋ Google ਬਰਦਾਸ਼ਤ ਕਰ ਸਕਦਾ ਹੈ: SRE ਅਹੁਦਿਆਂ ਲਈ ਲੋਕਾਂ ਨੂੰ ਨਿਯੁਕਤ ਕਰਨਾ ਜਿਨ੍ਹਾਂ ਕੋਲ ਡਿਵੈਲਪਰ ਯੋਗਤਾਵਾਂ ਸਨ ਅਤੇ ਥੋੜ੍ਹਾ ਜਿਹਾ ਹੋਮਵਰਕ ਵੀ ਕੀਤਾ ਸੀ, ਲਾਈਵ ਸਿਸਟਮ ਦੇ ਕੰਮਕਾਜ ਨੂੰ ਸਮਝਣਾ। ਗੂਗਲ ਨੂੰ ਖੁਦ ਅਜਿਹੇ ਲੋਕਾਂ ਨੂੰ ਨਿਯੁਕਤ ਕਰਨ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਹਨ, ਮੁੱਖ ਤੌਰ 'ਤੇ ਕਿਉਂਕਿ ਇਹ ਆਪਣੇ ਆਪ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰ ਰਿਹਾ ਹੈ - ਆਖ਼ਰਕਾਰ, ਇਸਨੂੰ ਕਾਰੋਬਾਰੀ ਤਰਕ ਦਾ ਵਰਣਨ ਕਰਨ ਲਈ ਕਿਸੇ ਦੀ ਲੋੜ ਹੈ। ਡਿਲਿਵਰੀ ਰਿਲੀਜ਼ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਸੌਂਪੀ ਗਈ ਹੈ, ਜਦੋਂ ਕਿ SR ਇੰਜੀਨੀਅਰ ਭਰੋਸੇਯੋਗਤਾ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦੇ ਹਨ (ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਨਹੀਂ, ਪਰ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਕੇ, ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਬਦਲ ਕੇ, ਤਬਦੀਲੀਆਂ ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਦੀ ਨਿਗਰਾਨੀ ਕਰਕੇ, ਅਤੇ ਘਟਨਾਵਾਂ ਨਾਲ ਨਜਿੱਠਣ ਦੁਆਰਾ)। ਵਧੀਆ, ਤੁਸੀਂ ਕਰ ਸਕਦੇ ਹੋ। ਕਿਤਾਬਾਂ ਲਿਖੋਪਰ ਕੀ ਹੋਵੇਗਾ ਜੇਕਰ ਤੁਸੀਂ ਗੂਗਲ ਨਹੀਂ ਹੋ, ਪਰ ਭਰੋਸੇਯੋਗਤਾ ਅਜੇ ਵੀ ਚਿੰਤਾ ਦਾ ਵਿਸ਼ਾ ਹੈ?

DevOps ਵਿਚਾਰਾਂ ਦਾ ਵਿਕਾਸ ਕਰਨਾ

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

SRE Google 'ਤੇ ਨਹੀਂ ਹੈ।

ਠੀਕ ਹੈ, ਅਸੀਂ ਡਿਲੀਵਰ ਕਰ ਦਿੱਤਾ ਹੈ, ਅਜਿਹਾ ਲੱਗਦਾ ਹੈ ਕਿ ਅਸੀਂ ਰਾਹਤ ਦਾ ਸਾਹ ਲੈ ਸਕਦੇ ਹਾਂ ਅਤੇ ਚੰਗੇ ਪੁਰਾਣੇ ਦਿਨਾਂ ਵਿੱਚ ਵਾਪਸ ਆ ਸਕਦੇ ਹਾਂ ਜਦੋਂ ਪ੍ਰਸ਼ਾਸਕ CPU ਲੋਡ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦੇ ਸਨ, ਸਿਸਟਮਾਂ ਨੂੰ ਟਿਊਨ ਕਰਦੇ ਸਨ, ਅਤੇ ਸ਼ਾਂਤੀ ਅਤੇ ਸ਼ਾਂਤੀ ਨਾਲ ਮੱਗ ਵਿੱਚੋਂ ਕੁਝ ਸਮਝ ਤੋਂ ਬਾਹਰ ਕੱਢਦੇ ਸਨ... ਉਡੀਕ ਕਰੋ। ਇਹ ਉਹ ਨਹੀਂ ਹੈ ਜਿਸ ਲਈ ਅਸੀਂ ਇਹ ਸਭ ਸ਼ੁਰੂ ਕੀਤਾ ਸੀ (ਬਹੁਤ ਬੁਰਾ!)। ਇਹ ਅਚਾਨਕ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਅਸੀਂ Google ਦੇ ਪਹੁੰਚ ਤੋਂ ਆਸਾਨੀ ਨਾਲ ਸ਼ਾਨਦਾਰ ਅਭਿਆਸਾਂ ਨੂੰ ਅਪਣਾ ਸਕਦੇ ਹਾਂ—ਇਹ CPU ਲੋਡ ਨਹੀਂ ਹੈ ਜੋ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ, ਜਾਂ ਅਸੀਂ ਕਿੰਨੀ ਵਾਰ ਡਰਾਈਵਾਂ ਨੂੰ ਬਦਲਦੇ ਹਾਂ, ਜਾਂ ਕੀ ਅਸੀਂ ਕਲਾਉਡ ਲਾਗਤਾਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਂਦੇ ਹਾਂ, ਪਰ ਵਪਾਰਕ ਮੈਟ੍ਰਿਕਸ—ਉਹੀ ਬਦਨਾਮ SLx। ਅਤੇ ਉਨ੍ਹਾਂ ਕੋਲ ਅਜੇ ਵੀ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਪ੍ਰਬੰਧਨ, ਘਟਨਾ ਦਾ ਹੱਲ, ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਡਿਊਟੀ ਸ਼ਿਫਟਾਂ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਸਿਖਰ 'ਤੇ ਰਹਿਣਾ ਹੈ। ਅਤੇ ਦੋਸਤੋ, ਇੱਕ ਚੰਗੇ ਪੱਧਰ 'ਤੇ ਪ੍ਰੋਗਰਾਮਿੰਗ ਸ਼ੁਰੂ ਕਰੋ, ਥੋੜ੍ਹਾ ਜਿਹਾ—Google ਤੁਹਾਡੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੈ।

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

ਸਰੋਤ: www.habr.com