ਵੈਬਿਨਾਰ ਦਾ ਟ੍ਰਾਂਸਕ੍ਰਿਪਸ਼ਨ "SRE - ਹਾਈਪ ਜਾਂ ਭਵਿੱਖ?"

ਵੈਬਿਨਾਰ ਵਿੱਚ ਖਰਾਬ ਆਡੀਓ ਹੈ, ਇਸਲਈ ਅਸੀਂ ਇੱਕ ਪ੍ਰਤੀਲਿਪੀ ਬਣਾਈ ਹੈ।

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

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

ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਸਾਡੇ ਕੋਲ DevOps ਦੀ ਸਪਸ਼ਟ ਪਰਿਭਾਸ਼ਾ ਅਤੇ DevOps ਦਾ ਸਪਸ਼ਟ ਲਾਗੂਕਰਨ ਨਹੀਂ ਹੈ। ਮੈਂ 2 ਸਾਲ ਪਹਿਲਾਂ ਯੇਕਾਟੇਰਿਨਬਰਗ ਵਿੱਚ ਇੱਕ ਕਾਨਫਰੰਸ ਵਿੱਚ ਗੱਲ ਕੀਤੀ ਸੀ, ਅਤੇ ਹੁਣ ਤੱਕ DevOps ਭਾਗ "DevOps ਕੀ ਹੈ" ਦੀ ਰਿਪੋਰਟ ਨਾਲ ਸ਼ੁਰੂ ਹੋਇਆ ਸੀ। 2017 ਵਿੱਚ, devops ਲਗਭਗ 10 ਸਾਲ ਪੁਰਾਣਾ ਹੈ, ਪਰ ਅਸੀਂ ਅਜੇ ਵੀ ਇਸ ਬਾਰੇ ਬਹਿਸ ਕਰ ਰਹੇ ਹਾਂ ਕਿ ਇਹ ਕੀ ਹੈ. ਅਤੇ ਇਹ ਇੱਕ ਬਹੁਤ ਹੀ ਅਜੀਬ ਸਥਿਤੀ ਹੈ ਜਿਸ ਨੂੰ ਗੂਗਲ ਨੇ ਕੁਝ ਸਾਲ ਪਹਿਲਾਂ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਸੀ.

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

ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ SRE ਟੀਮਾਂ ਵਿੱਚ DevOps ਪੈਰਾਡਾਈਮ ਨੂੰ ਇਸ ਤੱਥ ਦੁਆਰਾ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ ਕਿ ਇੱਥੇ SRE ਇੰਜੀਨੀਅਰ ਹਨ ਜੋ ਢਾਂਚਾਗਤ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਦੇ ਹਨ. ਇੱਥੇ ਇਹ ਹੈ, ਦੇਵ ਅਤੇ ਓਪਸ ਵਿਚਕਾਰ ਉਹੀ ਕੁਨੈਕਸ਼ਨ ਜਿਸ ਬਾਰੇ ਲੋਕ 8 ਸਾਲਾਂ ਤੋਂ ਗੱਲ ਕਰ ਰਹੇ ਹਨ। ਇੱਕ ਐਸਆਰਈ ਦੀ ਭੂਮਿਕਾ ਇੱਕ ਆਰਕੀਟੈਕਟ ਦੇ ਸਮਾਨ ਹੈ ਜਿਸ ਵਿੱਚ ਨਵੇਂ ਐਸਆਰਈ ਨਹੀਂ ਬਣਦੇ। ਆਪਣੇ ਕਰੀਅਰ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਲੋਕਾਂ ਕੋਲ ਅਜੇ ਤੱਕ ਕੋਈ ਤਜਰਬਾ ਨਹੀਂ ਹੈ ਅਤੇ ਗਿਆਨ ਦੀ ਲੋੜੀਂਦੀ ਚੌੜਾਈ ਨਹੀਂ ਹੈ. ਕਿਉਂਕਿ SRE ਨੂੰ ਅਸਲ ਵਿੱਚ ਕੀ ਅਤੇ ਕਦੋਂ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ ਬਾਰੇ ਇੱਕ ਬਹੁਤ ਹੀ ਵਧੀਆ ਗਿਆਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਸ ਲਈ, ਇੱਥੇ ਕਿਸੇ ਕਿਸਮ ਦੇ ਅਨੁਭਵ ਦੀ ਲੋੜ ਹੈ, ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ ਤੇ, ਕੰਪਨੀ ਦੇ ਅੰਦਰ ਅਤੇ ਬਾਹਰ ਦੋਵੇਂ.

ਉਹ ਪੁੱਛਦੇ ਹਨ ਕਿ ਕੀ SRE ਅਤੇ devops ਵਿਚਕਾਰ ਅੰਤਰ ਦੱਸਿਆ ਜਾਵੇਗਾ. ਉਸ ਨੂੰ ਹੁਣੇ ਹੀ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ. ਅਸੀਂ ਸੰਸਥਾ ਵਿੱਚ ਐਸਆਰਈ ਦੇ ਸਥਾਨ ਬਾਰੇ ਗੱਲ ਕਰ ਸਕਦੇ ਹਾਂ. ਕਲਾਸਿਕ DevOps ਪਹੁੰਚ ਦੇ ਉਲਟ, ਜਿੱਥੇ ਓਪਸ ਅਜੇ ਵੀ ਇੱਕ ਵੱਖਰਾ ਵਿਭਾਗ ਹੈ, SRE ਵਿਕਾਸ ਟੀਮ ਦਾ ਹਿੱਸਾ ਹੈ। ਉਹ ਉਤਪਾਦ ਦੇ ਵਿਕਾਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ. ਇੱਥੇ ਇੱਕ ਪਹੁੰਚ ਵੀ ਹੈ ਜਿੱਥੇ SRE ਇੱਕ ਭੂਮਿਕਾ ਹੁੰਦੀ ਹੈ ਜੋ ਇੱਕ ਡਿਵੈਲਪਰ ਤੋਂ ਦੂਜੇ ਨੂੰ ਜਾਂਦੀ ਹੈ। ਉਹ ਕੋਡ ਸਮੀਖਿਆਵਾਂ ਵਿੱਚ ਉਸੇ ਤਰ੍ਹਾਂ ਹਿੱਸਾ ਲੈਂਦੇ ਹਨ ਜਿਵੇਂ ਕਿ, ਉਦਾਹਰਨ ਲਈ, UX ਡਿਜ਼ਾਈਨਰ, ਖੁਦ ਡਿਵੈਲਪਰ, ਅਤੇ ਕਈ ਵਾਰ ਉਤਪਾਦ ਪ੍ਰਬੰਧਕ। SRE ਇਸੇ ਪੱਧਰ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ। ਸਾਨੂੰ ਉਹਨਾਂ ਦੀ ਪ੍ਰਵਾਨਗੀ ਦੀ ਲੋੜ ਹੈ, ਸਾਨੂੰ ਉਹਨਾਂ ਦੀ ਸਮੀਖਿਆ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਜੋ ਹਰੇਕ ਤੈਨਾਤੀ ਲਈ SRE ਕਹਿੰਦਾ ਹੈ: “ਠੀਕ ਹੈ, ਇਹ ਤੈਨਾਤੀ, ਇਹ ਉਤਪਾਦ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਨਕਾਰਾਤਮਕ ਤੌਰ 'ਤੇ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰੇਗਾ। ਅਤੇ ਜੇਕਰ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਕੁਝ ਸਵੀਕਾਰਯੋਗ ਸੀਮਾਵਾਂ ਦੇ ਅੰਦਰ ਹੋਵੇਗਾ।” ਅਸੀਂ ਇਸ ਬਾਰੇ ਵੀ ਗੱਲ ਕਰਾਂਗੇ.

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

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

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

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

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

ਇਹ ਸਭ ਗਲਤ ਹੈ, ਬੇਸ਼ਕ. ਅਤੇ ਇਹ ਲੋਕ ਅਕਸਰ ਅਭਿਆਸ ਵਿੱਚ ਇਸ ਕਿਸਮ ਦੇ ਕੋਡ ਦੁਆਰਾ ਦੁਖੀ ਹੁੰਦੇ ਹਨ, ਕਿਉਂਕਿ ਚੀਜ਼ਾਂ ਟੁੱਟ ਜਾਂਦੀਆਂ ਹਨ. ਚੀਜ਼ਾਂ ਕਦੇ-ਕਦੇ ਸਭ ਤੋਂ ਅਣਪਛਾਤੇ ਤਰੀਕਿਆਂ ਨਾਲ ਟੁੱਟ ਜਾਂਦੀਆਂ ਹਨ। ਕਈ ਵਾਰ ਲੋਕ ਕਹਿੰਦੇ ਹਨ ਕਿ ਨਹੀਂ, ਅਜਿਹਾ ਕਦੇ ਨਹੀਂ ਹੋਵੇਗਾ। ਅਤੇ ਇਹ ਅਜੇ ਵੀ ਵਾਪਰਦਾ ਹੈ. ਅਕਸਰ ਹੁੰਦਾ ਹੈ। ਅਤੇ ਇਸ ਲਈ ਕੋਈ ਵੀ ਕਦੇ ਵੀ 100% ਉਪਲਬਧਤਾ ਲਈ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਦਾ, ਕਿਉਂਕਿ 100% ਉਪਲਬਧਤਾ ਕਦੇ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਆਦਰਸ਼ ਹੈ. ਅਤੇ ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਜਦੋਂ ਅਸੀਂ ਸੇਵਾ ਦੀ ਉਪਲਬਧਤਾ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ ਤਾਂ ਅਸੀਂ ਹਮੇਸ਼ਾ ਨੌਂ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ। 2 ਨੌ, 3 ਨੌ, 4 ਨੌ, 5 ਨੌ। ਜੇਕਰ ਅਸੀਂ ਇਸਨੂੰ ਡਾਊਨਟਾਈਮ ਟਾਈਮ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਦੇ ਹਾਂ, ਤਾਂ, ਉਦਾਹਰਨ ਲਈ, 5 ਨਾਇਨਸ ਪ੍ਰਤੀ ਸਾਲ ਡਾਊਨਟਾਈਮ ਦੇ 5 ਮਿੰਟਾਂ ਤੋਂ ਥੋੜ੍ਹਾ ਵੱਧ ਹੈ, 2 ਨਾਇਨਸ ਡਾਊਨਟਾਈਮ ਦੇ 3,5 ਦਿਨ ਹਨ।

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

ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਬਾਕੀ ਦੇ ਭਾਗਾਂ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਕੀ ਹੈ. ਕਿਉਂਕਿ 4 ਭਰੋਸੇਯੋਗਤਾ ਵਾਲੇ ਨਾਇਨ ਵਾਲੇ ਸਮਾਰਟਫੋਨ 'ਤੇ 5 ਅਤੇ 2 ਨਾਇਨ ਦਾ ਫਰਕ ਨਜ਼ਰ ਨਹੀਂ ਆਵੇਗਾ। ਮੋਟੇ ਤੌਰ 'ਤੇ, ਜੇਕਰ ਸਾਲ ਵਿੱਚ 10 ਵਾਰ ਤੁਹਾਡੀ ਸੇਵਾ ਵਿੱਚ ਇੱਕ ਸਮਾਰਟਫੋਨ 'ਤੇ ਕੋਈ ਚੀਜ਼ ਟੁੱਟ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ OS ਸਾਈਡ 'ਤੇ 8 ਵਾਰ ਟੁੱਟਣ ਦੀ ਸੰਭਾਵਨਾ ਹੈ। ਉਪਭੋਗਤਾ ਇਸਦਾ ਆਦੀ ਹੈ, ਅਤੇ ਸਾਲ ਵਿੱਚ ਇੱਕ ਵਾਧੂ ਵਾਰ ਇਸ ਵੱਲ ਧਿਆਨ ਨਹੀਂ ਦੇਵੇਗਾ. ਵਧਦੀ ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਵਧ ਰਹੇ ਮੁਨਾਫੇ ਦੀ ਕੀਮਤ ਦੀ ਤੁਲਨਾ ਕਰਨੀ ਜ਼ਰੂਰੀ ਹੈ।
ਬਸ SRE 'ਤੇ ਕਿਤਾਬ ਵਿੱਚ 4 ਨਾਇਨਾਂ ਤੋਂ 3 ਨੌਂ ਤੱਕ ਵਧਾਉਣ ਦੀ ਇੱਕ ਵਧੀਆ ਉਦਾਹਰਣ ਹੈ। ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਉਪਲਬਧਤਾ ਵਿੱਚ ਵਾਧਾ 0,1% ਤੋਂ ਥੋੜ੍ਹਾ ਘੱਟ ਹੈ. ਅਤੇ ਜੇਕਰ ਸੇਵਾ ਦੀ ਆਮਦਨ $1 ਮਿਲੀਅਨ ਪ੍ਰਤੀ ਸਾਲ ਹੈ, ਤਾਂ ਮਾਲੀਆ ਵਾਧਾ $900 ਹੈ। ਜੇਕਰ ਨੌਂ ਦੁਆਰਾ ਉਪਲਬਧਤਾ ਵਧਾਉਣ ਨਾਲ ਸਾਡੇ ਲਈ ਪ੍ਰਤੀ ਸਾਲ $900 ਤੋਂ ਘੱਟ ਖਰਚ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਵਾਧਾ ਵਿੱਤੀ ਅਰਥ ਰੱਖਦਾ ਹੈ। ਜੇਕਰ ਇਸਦੀ ਲਾਗਤ $900 ਪ੍ਰਤੀ ਸਾਲ ਤੋਂ ਵੱਧ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਇਸਦਾ ਕੋਈ ਅਰਥ ਨਹੀਂ ਰਹਿ ਜਾਂਦਾ, ਕਿਉਂਕਿ ਮਾਲੀਏ ਵਿੱਚ ਵਾਧਾ ਸਿਰਫ਼ ਕਿਰਤ ਲਾਗਤਾਂ ਅਤੇ ਸਰੋਤ ਲਾਗਤਾਂ ਦੀ ਪੂਰਤੀ ਨਹੀਂ ਕਰਦਾ। ਅਤੇ 3 ਨੌਂ ਸਾਡੇ ਲਈ ਕਾਫੀ ਹੋਣਗੇ।

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

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

ਮੰਨ ਲਓ ਕਿ SLA ਇਸ ਤਰ੍ਹਾਂ ਹੋ ਸਕਦਾ ਹੈ। ਸੇਵਾ ਪੂਰੇ ਸਾਲ ਦੌਰਾਨ 99,95% ਵਾਰ ਉਪਲਬਧ ਹੁੰਦੀ ਹੈ। ਜਾਂ 99 ਗੰਭੀਰ ਤਕਨੀਕੀ ਸਹਾਇਤਾ ਟਿਕਟਾਂ ਪ੍ਰਤੀ ਤਿਮਾਹੀ 3 ਘੰਟੇ ਦੇ ਅੰਦਰ ਬੰਦ ਹੋ ਜਾਣਗੀਆਂ। ਜਾਂ 85% ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਹਰ ਮਹੀਨੇ 1,5 ਸਕਿੰਟਾਂ ਦੇ ਅੰਦਰ ਦਿੱਤੇ ਜਾਣਗੇ। ਯਾਨੀ, ਅਸੀਂ ਹੌਲੀ-ਹੌਲੀ ਸਮਝਦੇ ਜਾ ਰਹੇ ਹਾਂ ਕਿ ਗਲਤੀਆਂ ਅਤੇ ਅਸਫਲਤਾਵਾਂ ਬਿਲਕੁਲ ਆਮ ਹਨ। ਇਹ ਇੱਕ ਸਵੀਕਾਰਯੋਗ ਸਥਿਤੀ ਹੈ, ਅਸੀਂ ਇਸ ਲਈ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹਾਂ, ਅਸੀਂ ਕੁਝ ਹੱਦ ਤੱਕ ਇਸ 'ਤੇ ਭਰੋਸਾ ਵੀ ਕਰ ਰਹੇ ਹਾਂ। ਭਾਵ, ਐਸਆਰਈ ਅਜਿਹੇ ਸਿਸਟਮ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਗਲਤੀਆਂ ਕਰ ਸਕਦੇ ਹਨ, ਜੋ ਗਲਤੀਆਂ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਅਤੇ ਜੇਕਰ ਸੰਭਵ ਹੋਵੇ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਗਲਤੀਆਂ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਜਾਂ ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਨਾ ਦੇਵੇ, ਜਾਂ ਉਹਨਾਂ ਨੂੰ ਨੋਟਿਸ ਕਰੇ, ਪਰ ਕੁਝ ਕਿਸਮ ਦਾ ਹੱਲ ਹੈ ਤਾਂ ਜੋ ਸਭ ਕੁਝ ਪੂਰੀ ਤਰ੍ਹਾਂ ਟੁੱਟ ਨਾ ਜਾਵੇ।

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

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

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

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

ਮੈਨੂੰ ਸਮਝਾਉਣ ਦਿਓ. ਜੇਕਰ ਪ੍ਰਤੀ ਤਿਮਾਹੀ SLO ਸਮਾਂ ਵੱਧ ਗਿਆ ਹੈ, ਜੇਕਰ ਡਾਊਨਟਾਈਮ 13 ਮਿੰਟ ਨਹੀਂ, ਪਰ 15 ਸੀ, ਤਾਂ ਇਸ ਲਈ ਕੌਣ ਦੋਸ਼ੀ ਹੋ ਸਕਦਾ ਹੈ? ਬੇਸ਼ੱਕ, SRE ਗਲਤੀ 'ਤੇ ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਸ ਨੇ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਕੁਝ ਮਾੜੀ ਪ੍ਰਤੀਬੱਧਤਾ ਜਾਂ ਤੈਨਾਤੀ ਕੀਤੀ ਹੈ। ਡਾਟਾ ਸੈਂਟਰ ਪ੍ਰਸ਼ਾਸਕ ਇਸ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੋ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਉਸ ਨੇ ਕੁਝ ਅਣ-ਨਿਯਤ ਰੱਖ-ਰਖਾਅ ਕੀਤਾ ਹੋ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਡੇਟਾ ਸੈਂਟਰ ਪ੍ਰਸ਼ਾਸਕ ਨੂੰ ਇਸ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਠਹਿਰਾਇਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਓਪਸ ਤੋਂ ਵਿਅਕਤੀ SLO 'ਤੇ ਸਹਿਮਤ ਹੋਣ ਵੇਲੇ ਰੱਖ-ਰਖਾਅ ਦੀ ਗਣਨਾ ਨਾ ਕਰਨ ਲਈ ਵੀ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਇਹ ਪ੍ਰਬੰਧਕ, ਤਕਨੀਕੀ ਨਿਰਦੇਸ਼ਕ, ਜਾਂ ਕਿਸੇ ਅਜਿਹੇ ਵਿਅਕਤੀ ਦਾ ਕਸੂਰ ਹੈ ਜਿਸ ਨੇ ਡਾਟਾ ਸੈਂਟਰ ਦੇ ਇਕਰਾਰਨਾਮੇ 'ਤੇ ਹਸਤਾਖਰ ਕੀਤੇ ਹਨ ਅਤੇ ਇਸ ਤੱਥ ਵੱਲ ਧਿਆਨ ਨਹੀਂ ਦਿੱਤਾ ਕਿ ਡਾਟਾ ਸੈਂਟਰ SLA ਲੋੜੀਂਦੇ ਡਾਊਨਟਾਈਮ ਲਈ ਤਿਆਰ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਸ ਅਨੁਸਾਰ, ਹਰ ਕੋਈ ਇਸ ਸਥਿਤੀ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ. ਅਤੇ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਸ ਸਥਿਤੀ ਲਈ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਕਿਸੇ 'ਤੇ ਦੋਸ਼ ਲਗਾਉਣ ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੈ. ਪਰ ਬੇਸ਼ੱਕ ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ. ਇਸੇ ਲਈ ਪੋਸਟਮਾਰਟਮ ਮੌਜੂਦ ਹਨ। ਅਤੇ ਜੇ ਤੁਸੀਂ ਪੜ੍ਹਦੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ, GitHub ਪੋਸਟਮਾਰਟਮ, ਅਤੇ ਇਹ ਹਰ ਇੱਕ ਖਾਸ ਕੇਸ ਵਿੱਚ ਹਮੇਸ਼ਾਂ ਇੱਕ ਬਹੁਤ ਹੀ ਦਿਲਚਸਪ, ਛੋਟੀ ਅਤੇ ਅਚਾਨਕ ਕਹਾਣੀ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਸ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ ਕਿ ਕੋਈ ਵੀ ਕਦੇ ਇਹ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਇਹ ਖਾਸ ਵਿਅਕਤੀ ਦੋਸ਼ੀ ਸੀ. ਦੋਸ਼ ਹਮੇਸ਼ਾ ਖਾਸ ਕਮੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ 'ਤੇ ਲਗਾਇਆ ਜਾਂਦਾ ਹੈ।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ਸਲਰਮ ਐਸਆਰਈ ਇੱਕ ਤਿੰਨ-ਦਿਨ ਦਾ ਤੀਬਰ ਕੋਰਸ ਹੈ ਜੋ ਲਗਭਗ ਉਸ ਬਾਰੇ ਕਵਰ ਕਰੇਗਾ ਜਿਸ ਬਾਰੇ ਮੈਂ ਹੁਣ ਗੱਲ ਕਰ ਰਿਹਾ ਹਾਂ, ਪਰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਡੂੰਘਾਈ ਦੇ ਨਾਲ, ਅਸਲ ਕੇਸਾਂ ਦੇ ਨਾਲ, ਅਭਿਆਸ ਦੇ ਨਾਲ, ਪੂਰੀ ਤੀਬਰਤਾ ਦਾ ਉਦੇਸ਼ ਵਿਹਾਰਕ ਕੰਮ ਹੈ। ਲੋਕਾਂ ਨੂੰ ਟੀਮਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾਵੇਗਾ। ਤੁਸੀਂ ਸਾਰੇ ਅਸਲ ਕੇਸਾਂ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹੋਵੋਗੇ। ਇਸ ਅਨੁਸਾਰ, ਸਾਡੇ ਕੋਲ Booking.com ਇਵਾਨ ਕ੍ਰੂਗਲੋਵ ਅਤੇ ਬੇਨ ਟਾਈਲਰ ਦੇ ਇੰਸਟ੍ਰਕਟਰ ਹਨ। ਸਾਡੇ ਕੋਲ ਸਾਨ ਫ੍ਰਾਂਸਿਸਕੋ ਤੋਂ, Google ਤੋਂ ਇੱਕ ਸ਼ਾਨਦਾਰ Evgeniy Varabbas ਹੈ। ਅਤੇ ਮੈਂ ਤੁਹਾਨੂੰ ਵੀ ਕੁਝ ਦੱਸਾਂਗਾ। ਇਸ ਲਈ ਸਾਨੂੰ ਮਿਲਣ ਆਉਣਾ ਯਕੀਨੀ ਬਣਾਓ।
ਇਸ ਲਈ, ਹਵਾਲੇ ਦੀ ਇੱਕ ਸੂਚੀ. SRE 'ਤੇ ਲਿੰਕ ਹਨ। ਪਹਿਲਾ ਉਸੇ ਕਿਤਾਬ 'ਤੇ, ਜਾਂ Google ਦੁਆਰਾ ਲਿਖੀਆਂ SRE ਬਾਰੇ 2 ਕਿਤਾਬਾਂ 'ਤੇ। ਇੱਕ ਹੋਰ SLA, SLI, SLO 'ਤੇ ਛੋਟਾ ਲੇਖ, ਜਿੱਥੇ ਸ਼ਰਤਾਂ ਅਤੇ ਉਹਨਾਂ ਦੀ ਅਰਜ਼ੀ ਨੂੰ ਥੋੜਾ ਹੋਰ ਵਿਸਥਾਰ ਵਿੱਚ ਸਮਝਾਇਆ ਗਿਆ ਹੈ। ਅਗਲੀਆਂ 3 ਵੱਖ-ਵੱਖ ਕੰਪਨੀਆਂ ਵਿੱਚ SRE ਬਾਰੇ ਰਿਪੋਰਟਾਂ ਹਨ। ਪਹਿਲਾਂ - SRE ਦੀਆਂ ਕੁੰਜੀਆਂ, ਇਹ ਗੂਗਲ ਤੋਂ ਬੈਨ ਟ੍ਰੇਨਰ ਦਾ ਮੁੱਖ ਨੋਟ ਹੈ। ਦੂਜਾ - Dropbox 'ਤੇ SRE. ਤੀਜੇ ਬਾਰੇ ਫਿਰ ਹੈ Google 'ਤੇ SRE. ਤੋਂ ਚੌਥੀ ਰਿਪੋਰਟ Netflix 'ਤੇ SRE, ਜਿਸ ਕੋਲ 5 ਦੇਸ਼ਾਂ ਵਿੱਚ ਸਿਰਫ਼ 190 ਮੁੱਖ SRE ਕਰਮਚਾਰੀ ਹਨ। ਇਸ ਸਭ ਨੂੰ ਦੇਖਣਾ ਬਹੁਤ ਦਿਲਚਸਪ ਹੈ, ਕਿਉਂਕਿ ਜਿਸ ਤਰ੍ਹਾਂ DevOps ਦਾ ਮਤਲਬ ਵੱਖ-ਵੱਖ ਕੰਪਨੀਆਂ ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਵੱਖ-ਵੱਖ ਟੀਮਾਂ ਲਈ ਬਹੁਤ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਹਨ, SRE ਦੀਆਂ ਬਹੁਤ ਵੱਖਰੀਆਂ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਹਨ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਸਮਾਨ ਆਕਾਰ ਦੀਆਂ ਕੰਪਨੀਆਂ ਵਿੱਚ ਵੀ।

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

ਦਿਲਚਸਪ ਲੇਖ: ਇੱਕ ਜੀਵਨ ਵਿਕਲਪ ਵਜੋਂ SRE

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

PS: ਉਹਨਾਂ ਲਈ ਜੋ ਪੜ੍ਹਨਾ ਪਸੰਦ ਕਰਦੇ ਹਨ, ਐਡਵਾਰਡ ਨੇ ਹਵਾਲਿਆਂ ਦੀ ਇੱਕ ਸੂਚੀ ਪ੍ਰਦਾਨ ਕੀਤੀ. ਜੋ ਇਸ ਨੂੰ ਅਭਿਆਸ ਵਿੱਚ ਸਮਝਣ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹਨ, ਉਹਨਾਂ ਦਾ ਸਵਾਗਤ ਹੈ Slurme SRE.

ਸਰੋਤ: www.habr.com