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

ਗੱਲਬਾਤ ਚਰਚਾ 'ਤੇ ਆਧਾਰਿਤ AWS ਮਿੰਸਕ ਕਮਿਊਨਿਟੀ

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

prehistory

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

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

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

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

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

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

ਇਹ ਸਭ ਕੁਝ ਦੁਬਾਰਾ ਚੰਗਾ ਨਹੀਂ ਹੈ, ਰੱਬ ਦਾ ਧੰਨਵਾਦ

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

ਗੂਗਲ ਦੁਆਰਾ ਐਸ.ਆਰ.ਈ

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

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

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

SRE Google 'ਤੇ ਨਹੀਂ ਹੈ

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

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

ਸਰੋਤ: www.habr.com