16 ਅਗ 2025·8 ਮਿੰਟ
ਰੋਲਬੈਕ ਡ੍ਰਿੱਲ ਪਲੇਬੁੱਕ: 5 ਮਿੰਟ ਵਿੱਚ ਟੁੱਟੀ ਰੀਲੀਜ਼ ਰੀਸਟੋਰ ਕਰੋ
ਇਸ ਰੋਲਬੈਕ ਡ੍ਰਿੱਲ ਨਾਲ ਅਭਿਆਸ ਕਰੋ ਕਿ 5 ਮਿੰਟ ਵਿੱਚ ਟੁੱਟੀ ਰੀਲੀਜ਼ ਨੂੰ ਕਿਵੇਂ ਰੀਸਟੋਰ ਕਰਨਾ ਹੈ: ਕੀ ਸਨੇਪਸ਼ਾਟ ਕਰਨੇ ਹਨ, ਕੀ ਵੇਰੀਫਾਈ ਕਰਨਾ ਹੈ, ਅਤੇ ਡ੍ਰਿੱਲ ਦੌਰਾਨ ਕੌਣ ਕੀ ਕਲਿੱਕ ਕਰਦਾ ਹੈ।
ਇਸ ਰੋਲਬੈਕ ਡ੍ਰਿੱਲ ਨਾਲ ਅਭਿਆਸ ਕਰੋ ਕਿ 5 ਮਿੰਟ ਵਿੱਚ ਟੁੱਟੀ ਰੀਲੀਜ਼ ਨੂੰ ਕਿਵੇਂ ਰੀਸਟੋਰ ਕਰਨਾ ਹੈ: ਕੀ ਸਨੇਪਸ਼ਾਟ ਕਰਨੇ ਹਨ, ਕੀ ਵੇਰੀਫਾਈ ਕਰਨਾ ਹੈ, ਅਤੇ ਡ੍ਰਿੱਲ ਦੌਰਾਨ ਕੌਣ ਕੀ ਕਲਿੱਕ ਕਰਦਾ ਹੈ।
ਟੈਸਟਿੰਗ ਵਿੱਚ ਇੱਕ ਰੀਲੀਜ਼ ਠੀਕ ਲੱਗ ਸਕਦੀ ਹੈ, ਫਿਰ ਅਸਲੀ ਟ੍ਰੈਫਿਕ ਦੇ ਪਹਿਲੇ ਪੰਜ ਮਿੰਟਾਂ ਵਿੱਚ ਟੁੱਟ ਸਕਦੀ ਹੈ। ਡਰਾਉਣੀ ਗੱਲ ਆਮ ਤੌਰ 'ਤੇ ਬੱਗ ਨਹੀਂ ਹੁੰਦੀ। ਡਰਾਉਣੀ ਗੱਲ ਅਣਊਂਝ ਹੈ: ਕੀ ਬਦਲਿਆ, ਕੀ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਵਾਪਸ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੀ ਰੋਲਬੈਕ ਕਰਕੇ ਹਾਲਤ ਹੋਰ ਬਧਰ ਸਕਦੀ ਹੈ।
ਰਿਲੀਜ਼ ਦੇ ਬਾਅਦ ਫੇਲਿਅਰ ਆਮ ਤੌਰ 'ਤੇ ਸੁਝਾਵਨਯੋਗ ਅਤੇ ਸਾਫ਼ ਦਿੱਖਦੇ ਹਨ। ਨਵਾਂ ਬਟਨ ਮੋਬਾਈਲ 'ਤੇ ਪੇਜ ਨੂੰ ਕ੍ਰੈਸ਼ ਕਰ ਸਕਦਾ ਹੈ। ਬੈਕਐਂਡ ਚੇਂਜ ਗਲਤ ਡੇਟਾ ਆਕਾਰ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ ਜਿਸ ਕਰਕੇ ਚੈਕਆਉਟ ਫੇਲ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਛੋਟੀ ਕੰਫਿਗ ਟਵੀਕ ਲਾਗਇਨ, ਇਮੇਲ ਜਾਂ ਪੇਮੈਂਟ ਤੱਕ ਤੋੜ ਸਕਦੀ ਹੈ। ਭਾਵੇਂ ਠੀਕ ਕਰਨ ਦੀ ਗੱਲ ਆਸਾਨ ਹੋਵੇ, ਯੂਜ਼ਰ ਦੇ ਨਜ਼ਰਾਂ ਵਿੱਚ ਦਬਾਅ ਵਧ ਜਾਂਦਾ ਹੈ ਅਤੇ ਹਰ ਮਿੰਟ ਮਹਿੰਗੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ।
ਪੈਨਿਕ ਉਸ ਵੇਲੇ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਰੋਲਬੈਕ ਦਾ ਰਸਤਾ ਅਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ। ਲੋਕ ਇੱਕੋ-ਜਿਹੇ ਸਵਾਲ ਇਕੱਠੇ ਪੁੱਛਦੇ ਹਨ: ਕੀ ਸਾਡੇ ਕੋਲ ਸਨੇਪਸ਼ਾਟ ਹੈ? ਆਖ਼ਰੀ ਚੰਗਾ ਵਰਜ਼ਨ ਕਿਹੜਾ ਸੀ? ਅਸੀਂ ਐਪ ਰੋਲਬੈਕ ਕਰੀਏ ਤਾਂ ਡੇਟਾਬੇਸ ਦਾ ਕੀ ਹੋਏਗਾ? ਕਿਸ ਕੋਲ ਇਸ ਦੀ ਪਹੁੰਚ ਹੈ? ਜੇ ਇਹ ਜਵਾਬ ਪਹਿਲਾਂ ਤੋਂ ਲਿਖੇ ਨਹੀਂ ਹੋਣਗੇ ਤਾਂ ਟੀਮ ਸੇਵਾ ਬਹਾਲ ਕਰਨ ਦੀ ਬਜਾਏ ਚਰਚਾ ਕਰਦੀ ਰਹੇਗੀ।
ਇਨਸੀਡੈਂਟ ਦੌਰਾਨ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੀ ਕੀਮਤ ਹੋਂਦੀ ਹੈ। ਤੁਸੀਂ ਸਮਾਂ ਗਵਾਉਂਦੇ ਹੋ, ਯੂਜ਼ਰਾਂ ਦਾ ਭਰੋਸਾ ਘਟਦਾ ਹੈ, ਅਤੇ ਤੁਰੰਤ ਕੀਤੇ ਗਏ ਬੇਹਦਰੇ ਬਦਲਾਅ ਦੂਜਾ ਆਊਟੇਜ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ। ਇੰਜਨੀਅਰ ਵੀ ਬਹੁਤ ਸਾਰੀਆਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਖਿੱਚੇ ਜਾਂਦੇ ਹਨ: ਡੀਬੱਗਿੰਗ, ਸੰਦੇਸ਼ਾ ਭੇਜਣ ਅਤੇ ਫੈਸਲੇ ਲੈਣ।
ਇੱਕ ਅਭਿਆਸ ਦੌੜ ਮੂਡ ਬਦਲ ਦਿੰਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਅਣਊਂਝ ਨੂੰ ਮਾਸਲ ਮੈਮੋਰੀ ਨਾਲ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਵਧੀਆ ਰੋਲਬੈਕ ਡ੍ਰਿੱਲ ਸਿਰਫ਼ "ਕੋਡ ਵਾਪਸ ਕਰ ਸਕਦੇ ਹਾਂ" ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਇੱਕ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਰੂਟੀਨ ਹੁੰਦੀ ਹੈ: ਕੀ ਤੁਸੀਂ ਸਨੇਪਸ਼ਾਟ ਲੈਂਦੇ ਹੋ, ਕੀ ਰੀਸਟੋਰ ਕਰਦੇ ਹੋ, ਕੀ ਜाँचਦੇ ਹੋ ਅਤੇ ਕੌਣ ਕਾਰਵਾਈ ਕਰਨ ਦੀ ਆਗਿਆ ਰੱਖਦਾ ਹੈ। ਕੁਝ ਡ੍ਰਿੱਲਾਂ ਦੇ ਬਾਅਦ ਰੋਲਬੈਕ ਨੁਕਸਾਨ ਦੀ ਭਾਵਨਾ ਨਾ ਰੱਖ ਕੇ ਇੱਕ ਸੁਰੱਖਿਆ ਉਪਕਰਣ ਵਰਗਾ ਲੱਗਣ ਲੱਗਦਾ ਹੈ।
ਜੇ ਤੁਹਾਡੀ ਡਿਪਲੋਇਮੈਂਟ ਸੈਟਅੱਪ ਪਹਿਲਾਂ ਤੋਂ ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਰੀਸਟੋਰ ਸਮਰਥਨ ਕਰਦੀ ਹੈ (ਕੁਝ ਪਲੇਟਫਾਰਮ, ਜਿਵੇਂ Koder.ai, ਇਸਨੂੰ ਰੀਲੀਜ਼ ਫਲੋ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਦੇ ਹਨ), ਤਾਂ ਡ੍ਰਿੱਲ ਆਸਾਨ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ "ਜਾਣਿਆ-ਚੰਗਾ ਤੇ ਵਾਪਸ ਜਾਓ" ਇੱਕ ਆਮ ਕਾਰਵਾਈ ਬਣ ਜਾਂਦੀ ਹੈ, ਨਾਂ ਕਿ ਇੱਕ ਐਮਰਜੈਂਸੀ ਪ੍ਰਕਿਰਿਆ। ਕਿਸੇ ਵੀ ਹਾਲਤ ਵਿੱਚ, ਮਨੋਰਥ ਇੱਕੋ ਹੀ ਹੈ: ਜਦੋਂ ਲੋੜ ਹੋਵੇ, ਕਿਸੇ ਨੂੰ ਵੀ ਇੰਪਰੀਵਾਇਜ਼ ਕਰਨ ਦੀ ਲੋੜ ਨਾ ਪਵੇ।
“5 ਮਿੰਟ ਵਿੱਚ ਰੀਸਟੋਰ” ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਹਰ ਚੀਜ਼ ਵਾਪਸ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪਰਫੈਕਟ ਹੋ ਗਈ ਹੈ। ਇਹ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਨ ਵਾਲੇ ਵਰਜ਼ਨ 'ਤੇ ਵਾਪਸ ਲਿਆ ਸਕਦੇ ਹੋ, ਭਾਵੇਂ ਨਵੀਂ ਰੀਲੀਜ਼ ਅਜੇ ਵੀ ਖ਼ਰਾਬ ਹੋਵੇ।
ਸੇਵਾ ਪਹਿਲਾਂ, ਫਿਕਸ ਬਾਅਦ ਵਿੱਚ। ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਸੇਵਾ ਰੀਸਟੋਰ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਅਸਲੀ ਬੱਗ ਲੱਭਣ ਲਈ ਸ਼ਾਂਤ ਸਮਾਂ ਖਰੀਦ ਲੈਂਦੇ ਹੋ।
ਟਾਈਮਰ ਉਸ ਵੇਲੇ ਚਲਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਮੰਨ ਲੈਂਦੇ ਹੋ: “ਅਸੀਂ ਰੋਲਬੈਕ ਕਰ ਰਹੇ ਹਾਂ।” ਇਸ ਵਿੱਚ Lambੜੀ ਚਰਚਾ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦੀ ਕਿ ਸ਼ਾਇਦ ਚੀਜ਼ਾਂ ਖੁਦ ਠੀਕ ਹੋ ਜਾਣ।
ਆਪਣੇ ਰੋਲਬੈਕ ਟ੍ਰਿਗਰ ਅੱਗੇ ਹੀ ਫੈਸਲੋ। ਉਦਾਹਰਣ ਲਈ: “ਜੇ ਡਿਪਲੋਇ ਤੋਂ ਬਾਅਦ 3 ਮਿੰਟਾਂ ਲਈ ਚੈਕਆਉਟ ਦੀਆਂ ਗਲਤੀਆਂ X% ਤੋਂ ਉੱਪਰ ਰਹਿੰਦੀਆਂ ਹਨ ਤਾਂ ਅਸੀਂ ਰੋਲਬੈਕ ਕਰਦੇ ਹਾਂ।” ਜਦੋਂ ਟ੍ਰਿਗਰ ਲੱਗਦਾ ਹੈ, ਤੁਸੀਂ ਸਕ੍ਰਿਪਟ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹੋ।
“ਰੀਸਟੋਰਡ” ਉਹ ਛੋਟਾ ਸੈੱਟ ਸਿਗਨਲਾਂ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਤੋਂ ਪਤਾ ਲੱਗੇ ਕਿ ਯੂਜ਼ਰ ਸੁਰੱਖਿਅਤ ਹਨ ਅਤੇ ਸਿਸਟਮ ਸਥਿਰ ਹੈ। ਇਸਨੂੰ ਤੰਗ ਅਤੇ ਚੈੱਕ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਰੱਖੋ:
ਜਦੋਂ ਇਹ ਸੰਕੇਤ ਠੀਕ ਲੱਗਣ, 5 ਮਿੰਟ ਦਾ ਟਾਈਮਰ ਬੰਦ ਕਰੋ। ਹੋਰ ਸਭ ਕੁਝ ਬਾਅਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਡ੍ਰਿੱਲ ਸੱਚਾ ਰੱਖਣ ਲਈ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦਰਜ ਕਰੋ ਕਿ 5 ਮਿੰਟ ਦੇ ਰਾਹ ਵਿੱਚ ਤੁਸੀਂ ਕੀ ਨਹੀਂ ਕਰ ਰਹੇ: ਡੀਪ ਡੀਬੱਗਿੰਗ, ਕੋਡ ਬਦਲਾਅ ਜਾਂ ਹਾਟਫਿਕਸ ਰੀਲੀਜ਼, ਅਤੇ ਕੋਈ ਵੀ ਐਸਾ ਕੰਮ ਜੋ ਇੰਜਨੀਅਰਿੰਗ ਦਾ ਕੰਮ ਬਣ ਜਾਵੇ।
ਇੱਕ ਰੋਲਬੈਕ ਤਦ ਹੀ ਤੇਜ਼ ਖਿਆਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਫੈਸਲਾ ਜ਼ਿਆਦातर ਪਹਿਲਾਂ ਹੀ ਬਣਿਆ ਹੋਵੇ। ਇੱਕ ਅਪ੍ਰੋਚ ਚੁਣੋ ਜੋ ਜ਼ਿਆਦਾਤਰ ਇਨਸਿਡੈਂਟਾਂ ਲਈ ਕੰਮ ਕਰਦੀ ਹੈ, ਫਿਰ ਇਸਨੂੰ ਅਭਿਆਸ ਕਰੋ ਜਦੋਂ ਤੱਕ ਇਹ ਬੋਰਨਿੰਗ ਨਾ ਲੱਗੇ।
ਤੁਹਾਡੀ ਡ੍ਰਿੱਲ ਚਾਰ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇਵੇ:
ਜਦੋਂ ਨਵੀਂ ਰੀਲੀਜ਼ ਯੂਜ਼ਰਾਂ ਜਾਂ ਡਾਟਾ ਨੂੰ ਨੁਕਸਾਨ ਪੁਚਾ ਰਹੀ ਹੋਵੇ ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਜਾਣਿਆ-ਚੰਗਾ ਵਰਜ਼ਨ ਹੈ, ਤਾਂ ਰੋਲਬੈਕ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ। ਜਦੋਂ ਪ੍ਰਭਾਵ ਛੋਟਾ ਹੋਵੇ, ਬਦਲਾਅ ਇੱਕੋ ਥਾਂ ਸੀਮਤ ਹੋਵੇ ਅਤੇ ਤੁਸੀਂ ਨਿਰਭਰ ਹੋ ਕੇ ਪੈਚ ਕਰ ਸਕੋ, ਤਾਂ ਹਾਟਫਿਕਸ ਵਧੀਆ ਹੈ।
ਇੱਕ ਸਧਾਰਣ ਡੀਫੌਲਟ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ: ਜੇ ਯੂਜ਼ਰ ਮੁੱਖ ਐਕਸ਼ਨ ਨਹੀਂ ਪੂਰਾ ਕਰ ਸਕਦੇ (checkout, login, signup) ਜਾਂ ਗਲਤੀ ਦਰ ਵੱਧ ਜਾਂਦੀ ਹੈ, ਪਹਿਲਾਂ ਰੋਲਬੈਕ ਕਰੋ ਅਤੇ ਬਾਅਦ 'ਚ ਠੀਕ ਕਰੋ। ਅਣਅਨੰਦਕ ਮਸਲਿਆਂ ਲਈ ਹਾਟਫਿਕਸ ਰੱਖੋ।
ਤੁਹਾਡਾ "ਟਾਰਗਿਟ" ਕੁਝ ਏਸਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਟੀਮ ਫਟਾਫਟ ਚੁਣ ਸਕੇ, ਬਿਨਾਂ ਵਿਚਾਰ-ਵਿਮਰਸ਼ ਦੇ। ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਤਿੰਨ ਆਮ ਟਾਰਗਿਟ ਵਰਤਦੀਆਂ ਹਨ:
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਭਰੋਸੇਯੋਗ ਡਿਪਲੋਇਮੈਂਟ ਸਨੇਪਸ਼ਾਟ ਹਨ, ਉਨ੍ਹਾਂ ਨੂੰ ਡੀਫੌਲਟ ਬਣਾਓ ਕਿਉਂਕਿ ਇਹ ਦਬਾਅ ਹੇਠ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਹੈ। ਸਿਰਫ਼ ਕਾਨਫਿਗ-ਆਧਾਰਿਤ ਰੋਲਬੈਕ ਨੂੰ ਵੱਖਰਾ ਰਾਹ ਰੱਖੋ ਜੇ ਕੋਡ ਠੀਕ ਹੋ ਪਰ ਸੈਟਿੰਗ ਗਲਤ ਹੋ।
ਇਹ ਵੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਕਿ "ਪਿਛਲਾ ਚੰਗਾ" ਕੀ ਮੰਨਿਆ ਜਾਵੇ। ਇਹ ਉਹ ਸਭ ਤੋਂ ਹਾਲੀਆ ਰੀਲੀਜ਼ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜਿਸ ਨੇ ਮਾਨੀਟਰਿੰਗ ਚੈੱਕ ਪਾਸ ਕੀਤੇ ਹੋਣ ਅਤੇ ਜਿਸ 'ਤੇ ਕੋਈ ਸਰਗਰਮ ਇਨਸਿਡੈਂਟ ਨਾ ਹੋਵੇ—ਨਾ ਕਿ "ਉਹ ਜੋ ਲੋਕ ਯਾਦ ਰੱਖਦੇ ਹਨ"।
ਇਨਸੀਡੈਂਟ ਦੌਰਾਨ ਮੀਟਿੰਗ ਦਾ ਇੰਤਜ਼ਾਰ ਨਾ ਕਰੋ। ਉਹ ਟ੍ਰਿੱਗਰ ਲਿਖ ਕੇ ਰੱਖੋ ਜੋ ਰੋਲਬੈਕ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਦੀ ਪਾਲਣਾ ਕਰੋ। ਆਮ ਟ੍ਰਿਗਰ ਵਿੱਚ ਸ਼ਾਮਿਲ ਹਨ: ਮੁੱਖ ਫਲੋ ਕੁਝ ਮਿੰਟਾਂ ਤੋਂ ਵੱਧ ਖਰਾਬ ਰਹਿਣਾ, ਗਲਤੀ ਦਰ ਜਾਂ ਲੇਟੈਂਸੀ ਨੇ ਤਹਿ ਪਾਰ ਕਰ ਲੈਣਾ, ਡਾਟਾ ਖ਼ਤਰਾ (ਗਲਤ ਲਿਖਤ, ਡੁਪਲਿਕੇਟ ਚਾਰਜ), ਅਤੇ ਕੋਈ ਵੀ ਸੁਰੱਖਿਆ ਜਾਂ ਪ੍ਰਾਈਵੇਸੀ ਸੰਬੰਧੀ ਚਿੰਤਾ।
ਫਿਰ ਫੈਸਲੋ ਕਿ ਕੌਣ ਰੋਲਬੈਕ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇ ਸਕਦਾ ਹੈ। ਇੱਕ ਭੂਮਿਕਾ ਚੁਣੋ (incident lead ਜਾਂ on-call), ਅਤੇ ਇੱਕ ਬੈਕਅਪ। ਹੋਰ ਸਾਰੇ ਸਲਾਹ ਦੇ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਰੁਕਾਵਟ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਜਦੋਂ ਟ੍ਰਿਗਰ ਲੱਗੇ ਅਤੇ ਅਪਰੂਵਰ ਕਹੇ "ਰੋਲਬੈਕ", ਟੀਮ ਹਰ ਵਾਰੀ ਇੱਕੋ ਹੀ ਕਦਮ ਚਲਾਏਗੀ।
ਰੋਲਬੈਕ ਡ੍ਰਿੱਲ ਸਿਰਫ਼ ਤਦ ਹੀ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਜਾਣਿਆ-ਚੰਗਾ ਸਥਿਤੀ 'ਤੇ ਵਾਪਸ ਜਾ ਸਕੋ। ਸਨੇਪਸ਼ਾਟ ਸਿਰਫ਼ "ਚੰਗੇ ਹੋਣ ਲਈ" ਨਹੀਂ ਹਨ—ਉਹ ਰਸੀਦਾਂ ਹਨ ਜੋ ਸਾਬਤ ਕਰਦੀਆਂ ਹਨ ਕਿ ਕਿਹੜਾ ਕੋਡ ਚੱਲ ਰਿਹਾ ਸੀ, ਕੀ ਬਦਲਿਆ ਅਤੇ ਵਾਪਸ ਕਿਵੇਂ ਜਾਣਾ ਹੈ।
ਹਰ ਰੀਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਇਹਨਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਬਿਨਾਂ ਚੈਟ ਲੌਗ ਖੋਜੇ ਪਕੜਨ ਯੋਗ ਬਣਾਓ:
ਡੇਟਾਬੇਸ ਸੁਰੱਖਿਆ ਆਮ ਫਸਲ ਹੈ। ਤੇਜ਼ ਐਪ ਰੋਲਬੈਕ ਬੇਕਾਰ ਹੈ ਜੇ ਡੇਟਾਬੇਸ ਹੁਣ ਨਵੀਂ ਸਕੀਮਾ ਦੀ ਉਮੀਦ ਕਰ ਰਿਹਾ ਹੋਵੇ। ਖਤਰਨਾਕ migrations ਲਈ ਦੋ-ਕਦਮ ਰੀਲੀਜ਼ ਦੀ ਯੋਜਨਾ ਬਣਾਓ (ਪਹਿਲਾਂ ਨਵੇਂ ਫੀਲਡ ਜੋੜੋ, ਬਾਅਦ ਵਿੱਚ ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਤੋ) ਤਾਂ ਜੋ ਰੋਲਬੈਕ ਸੰਭਵ ਰਹੇ।
ਹਰ ਜਗ੍ਹਾ ਇੱਕ ਨਾਂਕਰਨ ਨਿਯਮ ਵਰਤੋ ਅਤੇ ਇਸਨੂੰ sortable ਬਣਾਓ:
prod-2026-01-09-1420-v1.8.3-commitA1B2C3
ਵਾਤਾਵਰਨ, timestamp, ਵਰਜ਼ਨ ਅਤੇ commit ਸ਼ਾਮਿਲ ਕਰੋ। ਜੇ ਤੁਹਾਡੇ ਟੂਲਾਂ ਵਿੱਚ UI ਵਿੱਚ ਸਨੇਪਸ਼ਾਟ ਸਹਾਇਤਾ ਹੈ, ਉੱਥੇ ਵੀ ਇਹੀ ਨਾਂਕਰਨ ਨਿਯਮ ਵਰਤੋ ਤਾਂ ਕਿ ਕੋਈ ਵੀ ਜਦੋਂ ਇਨਸੀਡੈਂਟ ਹੋਵੇ ਤੇਜ਼ੀ ਨਾਲ ਠੀਕ ਰੀਸਟੋਰ ਪਾਇੰਟ ਲੱਭ ਸਕੇ।
ਜਦੋਂ ਹਰ ਕੋਈ ਆਪਣੀ ਲਾਈਨ ਜਾਣਦਾ ਹੈ ਤਾਂ ਰੋਲਬੈਕ ਡ੍ਰਿੱਲ ਤੇਜ਼ ਅਤੇ ਸ਼ਾਂਤ ਹੁੰਦੀ ਹੈ। ਮਕਸਦ "ਹਰ ਕੋਈ ਛਾਲ ਮਾਰੇ" ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਵਿਅਕਤੀ ਦਾ ਫੈਸਲਾ, ਇੱਕ ਵਿਅਕਤੀ ਦੀ ਕਾਰਵਾਈ, ਇੱਕ ਵਿਅਕਤੀ ਦੀ ਪੜਤਾਲ ਅਤੇ ਇੱਕ ਵਿਅਕਤੀ ਦੀ ਜਾਣਕਾਰੀ ਦੇਣ ਵਾਲੀ ਭੂਮਿਕਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਛੋਟੀ ਅਤੇ ਮੱਧਮ ਆਕਾਰ ਦੀਆਂ ਟੀਮਾਂ ਲਈ ਇਹ ਭੂਮਿਕਾਵਾਂ ਵਧੀਆ ਕੰਮ ਕਰਦੀਆਂ ਹਨ (ਇੱਕ ਵਿਅਕਤੀ ਦੋ-ਹੈਟ ਪਹਿਨ ਸਕਦਾ ਹੈ, ਪਰ ਡ੍ਰਿੱਲ ਦੌਰਾਨ Deployer ਅਤੇ Verifier ਨੂੰ ਇਕੱਠੇ ਨਾ ਜੋੜੋ):
ਪ੍ਰਵਾਨਗੀਆਂ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀਆਂ ਹਨ ਕਿ ਇਹ ਯੋਜਨਾ ਅਸਲ ਹੈ ਜਾਂ ਸਿਰਫ਼ ਇੱਕ ਸੋਹਣਾ ਦਸਤਾਵੇਜ਼। ਡ੍ਰਿੱਲ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਕੌਣ ਪ੍ਰੋਡਕਸ਼ਨ ਰੋਲਬੈਕ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਐਮਰਜੈਂਸੀਜ਼ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ।
ਇਕ ਸਧਾਰਣ ਸੈਟਅੱਪ:
ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਪਲੇਟਫਾਰਮ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ ਜੋ snapshots ਅਤੇ rollback ਸਮਰੱਥ ਕਰਦਾ ਹੈ (ਜਿਵੇਂ Koder.ai), ਤਾਂ ਪਤਾ ਕਰੋ ਕਿ ਕੌਣ snapshots ਬਣਾਉਂਦਾ, ਕੌਣ ਉਨ੍ਹਾਂ ਨੂੰ ਰੀਸਟੋਰ ਕਰ ਸਕਦਾ, ਅਤੇ ਉਹ ਕਾਰਵਾਈ ਕਿੱਥੇ ਦਰਜ ਹੁੰਦੀ ਹੈ।
ਰੋਲਬੈਕ ਡ੍ਰਿੱਲ ਸਭ ਤੋਂ ਵਧੀਆ ਉਸ ਵੇਲੇ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇਹ ਫਾਇਰ ਡ੍ਰਿੱਲ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋਵੇ: ਇਕੋ ਕਦਮ, ਇਕੋ ਸ਼ਬਦ, ਇਕੋ ਥਾਂ ਤੇ ਕਲਿੱਕ ਕਰਨ ਦੀ ਜਗ੍ਹਾ। ਮਕਸਦ ਪਰਫੈਕਸ਼ਨ ਨਹੀਂ—ਇਹ ਕਿ ਕਿਸੇ ਵੀ on-call ਵਿਅਕਤੀ ਲਈ ਆਖ਼ਰੀ ਜਾਣਿਆ-ਚੰਗਾ ਵਰਜ਼ਨ ਤੇਜ਼ੀ ਨਾਲ ਰੀਸਟੋਰ ਕਰਨ ਯੋਗ ਹੋਵੇ, ਬਿਨਾਂ ਵਿਕਲਪਾਂ 'ਤੇ ਵਿਚਾਰ-ਵਿਮਰਸ਼ ਕੀਤੇ।
ਇੱਕ ਸਪਸ਼ਟ ਟ੍ਰਿਗਰ ਚੁਣੋ ਅਤੇ ਜਦੋਂ ਡ੍ਰਿੱਲ ਸ਼ੁਰੂ ਕਰੋ ਤਾਂ ਉਹ ਜ਼ੋਰ ਨਾਲ ਕਹੋ। ਉਦਾਹਰਣ: “ਚੈਕਆਉਟ 1 ਮਿੰਟ ਤੋਂ ਵੱਧ 500 ਵਾਪਸ ਕਰ ਰਿਹਾ ਹੈ” ਜਾਂ “ਡਿਪਲੋਇ ਦੇ ਤੁਰੰਤ ਬਾਅਦ error rate ਸਧਾਰਨ ਦਾ 5x ਹੈ।” ਇਸਨੂੰ ਉੱਚ ਆਵਾਜ਼ ਵਿੱਚ ਕਹਿਣ ਨਾਲ ਟੀਮ ਟਰਬਲਸ਼ੂਟਿੰਗ ਮੋਡ ਵਿੱਚ ਨਹੀਂ ਭਟਕੇਗੀ।
ਰਨਬੁੱਕ ਦੇ ਕੋਲ ਇੱਕ ਛੋਟਾ ਤਿਆਰ ਕਰਨ ਵਾਲੀ ਚੈੱਕਲਿਸਟ ਰੱਖੋ:
ਟਾਈਮਰ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ ਵਿਅਕਤੀ ਟ੍ਰਿਗਰ ਅਤੇ ਫੈਸਲਾ ਬਿਆਨ ਕਰਦਾ: “ਅਸੀਂ ਹੁਣ ਰੋਲਬੈਕ ਕਰ ਰਹੇ ਹਾਂ।”
ਚੇਂਜਜ਼ ਨੂੰ ਫ੍ਰੀਜ਼ ਕਰੋ। ਨਵੇਂ ਡਿਪਲੋਇ ਰੋਕੋ ਅਤੇ ਨਾ-ਜ਼ਰੂਰੀ ਸੋਧਾਂ ਰੋਕੋ ਜੋ ਰੋਲਬੈਕ ਦੌਰਾਨ ਸਿਸਟਮ ਬਦਲ ਸਕਦੀਆਂ ਹਨ।
ਆਖ਼ਰੀ-ਮੌਕੇ ਸਨੇਪਸ਼ਾਟ ਲਵੋ (ਜੇ ਸੁਰੱਖਿਅਤ ਅਤੇ ਤੇਜ਼ ਹੋ ਸਕੇ)। ਇਹ ਤੁਰੰਤ ਸੁਰੱਖਿਆ ਹੈ ਕਿ ਜੇ ਤੁਹਾਨੂੰ ਬਾਅਦ ਵਿੱਚ ਖਰਾਬ ਸਥਿਤੀ ਦੁਬਾਰਾ ਬਣਾਉਣੀ ਹੋਵੇ। ਇਸਨੂੰ ਸਾਫ਼ ਨਾਂ ਦਿਓ ਅਤੇ ਅੱਗੇ ਵਧੋ।
ਰੋਲਬੈਕ ਕਾਰਵਾਈ ਨੂੰ ਬਿਲਕੁਲ ਦਸਤਾਵੇਜ਼ ਅਨੁਸਾਰ ਚਲਾਓ। ਇੰਪਰੋਵਾਈਜ਼ ਨ ਕਰੋ। ਪੁਸ਼ਟੀ ਪ੍ਰੋੰਪਟਾਂ ਨੂੰ ਉੱਚ ਆਵਾਜ਼ ਵਿੱਚ ਪੜ੍ਹੋ ਤਾਂ ਕਿ ਰਿਕਾਰਡਰ ਜੋ ਹੋਇਆ ਉਸਨੂੰ ਲਿਖ ਸਕੇ।
ਇੱਕ ਭਰੋਸੇਯੋਗ ਥਾਂ 'ਤੇ ਰੋਲਬੈਕ ਪੂਰਾ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਹਰ ਵਾਰੀ ਇੱਕ ਸਕਰੀਨ ਅਤੇ ਇੱਕ ਸਿਗਨਲ ਵਰਤੋ (deployment history view, “current version” ਲੇਬਲ, ਜਾਂ ਕੋਈ ਸਪਸ਼ਟ status indicator)।
ਕਾਰਵਾਈ ਤੋਂ ਬਾਅਦ ਤੁਰੰਤ ਉਹ ਚੀਜ਼ਾਂ ਕੈਪਚਰ ਕਰੋ ਜੋ ਤਾਜ਼ਾ ਯਾਦ ਰਹਿੰਦੀਆਂ ਹਨ:
ਜੇ ਰੋਲਬੈਕ 5 ਮਿੰਟ ਤੋਂ ਵੱਧ ਲੈਂਦਾ ਹੈ, ਇਸਨੂੰ ਨ ਬਰਦਾਸਤ ਕਰੋ। ਦੇਖੋ ਕਿ ਕਿਹੜਾ ਕਦਮ ਸੌ ਕਦਮ ਲੰਮਾ ਹੋ ਰਿਹਾ ਹੈ, ਰਨਬੁੱਕ ਨੂੰ ਠੀਕ ਕਰੋ ਅਤੇ ਡ੍ਰਿੱਲ ਦੁਹਰਾਓ।
ਰੋਲਬੈਕ ਤਦੋਂ ਹੀ "ਕਾਮਯਾਬ" ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਮਹਿਸੂਸ ਹੋਵੇ ਕਿ ਉਹ ਵਾਪਸ ਆ ਗਏ ਹਨ। ਤੁਸੀਂ ਇਹ ਸਾਬਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰ ਰਹੇ ਕਿ ਪੁਰਾਣਾ ਵਰਜ਼ਨ ਡਿਪਲੋਇ ਹੋ ਗਿਆ—ਤੁਸੀਂ ਸਾਬਤ ਕਰ ਰਹੇ ਹੋ ਕਿ ਸੇਵਾ ਮੁੜ ਵਰਤਣਯੋਗ ਅਤੇ ਸਥਿਰ ਹੋ ਗਈ ਹੈ।
ਵੈਰੀਫਿਕੇਸ਼ਨ ਛੋਟੀ ਅਤੇ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਰੱਖੋ। ਜੇ ਲਿਸਟ ਪੰਜ ਤੋਂ ਵੱਧ ਹੋਵੇਗੀ ਤਾਂ ਲੋਕ ਤਣਾਵ ਵਿੱਚ ਰਹਿ ਕੇ ਕੁਝ ਛੱਡ ਦੇਣਗੇ।
ਉਹ ਚੈਕ ਵਰਤੋਂ ਜੋ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਚਲਾ ਸਕੋ, ਸਪਸ਼ਟ ਪਾਸ/ਫੇਲ ਹੋਣ:
ਫੰਕਸ਼ਨਲ ਚੈੱਕ ਤੋਂ ਬਾਅਦ, ਉਸ ਸਿਮਪਲ ਸਿਸਟਮ ਹੈਲਥ ਸਿਗਨਲ 'ਤੇ ਇਕ ਨਜ਼ਰ ਮਾਰੋ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰਦੇ ਹੋ। ਤੁਸੀਂ ਇਹ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਗਲਤੀ ਦਰ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਵਾਪਸ ਨਾਰਮਲ ਤੇ ਆ ਰਹੀ ਹੈ ਅਤੇ ਲੇਟੈਂਸੀ ਨਹੀਂ ਚੜ੍ਹ ਰਹੀ।
ਉਹ ਵੀ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਘੁਮਣ-ਫਿਰਣ ਵਾਲੇ ਹਿੱਸੇ ਮੁੜ ਚੱਲ ਰਹੇ ਹਨ। ਬੈਕਗ੍ਰਾਉਂਡ ਜੌਬ ਪ੍ਰੋਸੈਸ ਹੋ ਰਹੇ ਹੋਣ ਅਤੇ ਕਿਊਜ਼ ਘਟ ਰਹੀਆਂ ਹੋਣ; ਨਾ ਵਧ ਰਹੀਆਂ। ਡੇਟਾਬੇਸ ਚੈੱਕ ਤੇਜ਼ ਅਤੇ ਸਧਾਰਣ ਹੋਣ: ਕਨੈਕਸ਼ਨ ਸਥਿਰ, ਕਿਸੇ ਵੱਡੇ ਲੌਕ ਪਾਈਪਅੱਪ ਨਹੀਂ, ਅਤੇ ਐਪ ਲਿਖ ਸਕਦੀ ਹੈ।
ਅੰਤ ਵਿੱਚ, ਬਾਹਰੀ ਸੰਸਾਰ ਨੂੰ ਟੈਸਟ ਕਰੋ ਜੇ ਤੁਸੀਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕਰ ਸਕੋ: ਇੱਕ ਪੇਮੈਂਟ ਟੈਸਟ ਚਲਾਓ, ਬਤਾਓ ਕਿ ਈਮੇਲ ਡਿਲਿਵਰੀ ਬਾਉਂਸ ਨਹੀਂ ਹੋ ਰਹੀ, ਅਤੇ ਵੇਖੋ ਕਿ webhook ਸਵੀਕਾਰ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ (ਜਾਂ ਘੱਟੋ-ਘੱਟ ਫੇਲ ਨਹੀਂ ਹੋ ਰਹੇ)।
ਇੱਕ ਪੰਗਤ ਪਹਿਲਾਂ ਹੀ ਲਿਖੋ ਤਾਂ ਕਿ ਕੋਈ ਵਿਅਕਤੀ ਇੰਮੀਪ੍ਰੋਵਾਈਜ਼ ਨਾ ਕਰੇ:
“Rollback complete. Core flows verified (login + checkout). Error rate and latency back to normal. Monitoring for 30 minutes. Next update at 14:30.”
ਇੱਕ ਮੰਗਲਵਾਰ ਨੂੰ 10:02 ਵਜੇ. ਨਵੀਂ ਰੀਲੀਜ਼ ਨਿਕਲਦੀ ਹੈ, ਅਤੇ ਇਕ ਮਿੰਟ ਦੇ ਅੰਦਰ ਕੁਝ ਯੂਜ਼ਰ ਲੌਗਇਨ ਨਹੀਂ ਕਰ ਸਕ ਰਹੇ। ਕੁਝ ਨੂੰ “invalid session” ਮਿਲਦਾ ਹੈ, ਦੂਜੇ ਨੂੰ ਸਪਿਨਰ ਜੋ ਕਦੇ ਦੇਸ ਨਹੀਂ ਹੁੰਦਾ। ਸਾਈਨਅੱਪ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਮੁੱਦਾ ਸ਼ੁਰੂ ਵਿੱਚ ਛੁਪਿਆ ਰਹਿ ਸਕਦਾ ਹੈ।
ਪਹਿਲੀ ਸਿਗਨਲ ਆਮ ਤੌਰ 'ਤੇ ਡਰਾਉਣਾ outage ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਇੱਕ ਚੁਪਚਾਪ spike ਹੁੰਦਾ ਹੈ: ਸਪੋਰਟ ਟਿਕਟਾਂ, ਸਫਲ ਲੌਗਇਨਾਂ ਵਿੱਚ ਡਿੱਪ, ਅਤੇ ਕੁਝ ਗੁੱਸੇਵਾਲੇ ਸੁਨੇਹੇ। ਓਨ-ਕਾਲ ਨੂੰ “login success rate down 18% in 5 minutes” ਦਾ ਅਲਰਟ ਮਿਲਦਾ ਹੈ, ਅਤੇ ਸਪੋਰਟ ਪੁਸਟ ਕਰਦਾ ਹੈ: “3 users can’t log in after the update.”
ਕਿਉਂਕਿ ਟੀਮ ਨੇ ਅਭਿਆਸ ਕੀਤਾ ਹੁੰਦਾ ਹੈ, ਉਹ ਜ਼ਿਆਦਾ ਚਰਚਾ ਨਹੀਂ ਕਰਦੇ। ਉਹ ਪੁਸ਼ਟੀ ਕਰਦੇ, ਫੈਸਲਾ ਕਰਦੇ, ਅਤੇ ਕਾਰਵਾਈ ਕਰਦੇ ਹਨ।
ਕੀ ਰੋਲਬੈਕ ਕੀਤਾ ਗਿਆ: ਵੈੱਬ ਅਤੇ API ਸਰਵਿਸਿਜ਼ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਅਤੇ ਕੰਫਿਗ। ਕੀ ਜਿਵੇਂ ਦਾ-ਹੈ: ਡੇਟਾਬੇਸ ਅਤੇ ਯੂਜ਼ਰ ਡੇਟਾ।
ਜੇ ਰੀਲੀਜ਼ ਵਿੱਚ ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ ਸ਼ਾਮਿਲ ਸੀ, ਡ੍ਰਿੱਲ ਨੀਤੀ ਸਧਾਰਣ ਹੈ: 5-ਮਿੰਟ ਪਾਥ ਵਿੱਚ ਕਦੇ ਵੀ ਡੇਟਾਬੇਸ ਰੋਲਬੈਕ ਨਾ ਕਰੋ। ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਬੈਕਵਰਡ ਕੰਪੈਟਿਬਲ ਰੱਖੋ, ਜਾਂ ਡਿਪਲੋਇ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੂਜੇ ਨੇਜ਼ ਦੀ ਦੀਖ ਲਓ।
ਰੋਲਬੈਕ ਦੌਰਾਨ, incident lead ਹਰ ਕੁਝ ਮਿੰਟਾਂ 'ਚ ਛੋਟੀ ਅਪਡੇਟ ਪੋਸਟ ਕਰਦਾ: ਯੂਜ਼ਰਾਂ ਨੂੰ ਕੀ ਦਿਖ ਰਿਹਾ ਹੈ, ਕਿਹੜੀ ਕਾਰਵਾਈ ਹੋ ਰਹੀ ਹੈ, ਅਤੇ ਅਗਲਾ ਅਪਡੇਟ ਕਦੋਂ ਹੋਏਗਾ। ਉਦਾਹਰਣ: “ਅਸੀਂ ਆਖ਼ਰੀ ਰੀਲੀਜ਼ ਰੋਲਬੈਕ ਕਰ ਰਹੇ ਹਾਂ ਤਾਂ ਕਿ ਲੌਗਇਨ ਵਾਪਸ ਲਿਆ ਜਾਵੇ। ਅਗਲਾ ਅਪਡੇਟ 2 ਮਿੰਟ ਵਿੱਚ।”
ਰੋਲਬੈਕ ਤੋਂ ਬਾਅਦ, ਉਹ ਲੂਪ ਬੰਦ ਕਰਦੇ ਹਨ: “Login wapis normal hai. Root cause review chal raha hai. Asi vadde vichaar te badlav saanjhe karange.”
ਰੋਲਬੈਕ ਡ੍ਰਿੱਲ ਨੂੰ ਬੋਰਿੰਗ ਮਹਿਸੂਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਇਹ ਤਣਾਅਪੂਰਕ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਡ੍ਰਿੱਲ ਵਾਸਤਵ ਵਿੱਚ ਅਸਲ ਖਾਮੀਆਂ ਨੂੰ ਸਾਹਮਣਾ ਕਰਵਾ ਰਹੀ ਹੈ: ਪਹੁੰਚ, ਗੁੰਝਲਦਾਰ ਸਨੇਪਸ਼ਾਟ, ਜਾਂ ਉਹ ਕਦਮ ਜੋ ਸਿਰਫ਼ ਕਿਸੇ ਦੇ ਦਿਮਾਗ ਵਿੱਚ ਹਨ।
ਤੁਸੀਂ ਅਭਿਆਸ ਅਸਲੀ ਪਹੁੰਚ ਨਾਲ ਨਹੀਂ ਕਰਦੇ। ਲੋਕ ਇਨਸੀਡੈਂਟ ਦੌਰਾਨ ਪਤਾ ਲਗਾਉਂਦੇ ਹਨ ਕਿ ਉਹ deploy ਨਹੀਂ ਕਰ ਸਕਦੇ, ਕੰਫਿਗ ਬਦਲ ਨਹੀਂ ਸਕਦੇ, ਜਾਂ ਡੈਸ਼ਬੋਰਡ ਤੱਕ ਨਹੀਂ ਪੁੱਜ ਸਕਦੇ। ਸੁਧਾਰ: ਅਸਲ ਖਾਤਿਆਂ ਅਤੇ ਰੋਲਾਂ ਨਾਲ ਡ੍ਰਿੱਲ ਚਲਾਓ।
ਸਨੇਪਸ਼ਾਟ ਮੌਜੂਦ ਹਨ, ਪਰ ਉਹ ਅਧੂਰੇ ਜਾਂ ਢੂੰਢਣ ਵਿੱਚ ਔਖੇ ਹਨ। ਟੀਮ ਐਪ ਦਾ ਸਨੇਪਸ਼ਾਟ ਲੈਂਦੀ ਹੈ ਪਰ env ਬਦਲਾਅ, ਫੀਚਰ ਫਲੈਗ ਜਾਂ ਰਾਊਟਿੰਗ ਭੁੱਲ ਜਾਂਦੀ ਹੈ। ਜਾਂ ਸਨੇਪਸ਼ਾਟ ਨਾਮ अर्थ ਨਹੀਂ ਦਿੰਦਾ। ਸੁਧਾਰ: ਸਨੇਪਸ਼ਾਟ ਬਣਾਉਣਾ ਇੱਕ ਰੀਲੀਜ਼ ਕਦਮ ਬਣਾਓ, ਨਾਂਕਰਨ ਨਿਯਮ ਲਾਓ ਅਤੇ ਡ੍ਰਿੱਲਾਂ ਦੌਰਾਨ ਸਾਬਤ ਕਰੋ ਕਿ ਸਨੇਪਸ਼ਾਟ ਵੇਖਣਯੋਗ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਰੀਸਟੋਰ ਕਰਨਯੋਗ ਹੈ।
ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਰੋਲਬੈਕ ਨੂੰ ਅਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਬੈਕਵਰਡ-ਅਨਕੰਪੈਟਿਬਲ ਸਕੀਮਾ ਤੁਰੰਤ ਰੋਲਬੈਕ ਨੂੰ ਡਾਟਾ ਸਮੱਸਿਆ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਸੁਧਾਰ: additive migrations ਪਸੰਦ ਕਰੋ। ਜੇ ਇੱਕ breaking change ਅਣਟੱਲੀਏਬਲ ਹੈ, ਅੱਗੇ ਦੀ ਫਿਕਸ ਯੋਜਨਾ ਬਣਾਓ ਅਤੇ ਰੀਲੀਜ਼ ਨੂੰ ਸਪਸ਼ਟ ਲੇਬਲ ਦਿਓ: "rollback allowed: yes/no"।
ਤੁਸੀਂ ਉਸ ਤੋਂ ਪਹਿਲਾਂ ਸਫਲਤਾ ਐਲਾਨ ਕਰ ਦਿੰਦੇ ਹੋ ਜਦੋਂ ਯੂਜ਼ਰ ਮਹਿਸੂਸ ਨਹੀਂ ਕਰਦੇ। ਐਪ ਡਿਪਲੋਇ ਹੋ ਗਿਆ, ਪਰ ਲਾਗਇਨ ਅਜੇ ਵੀ ਟੁੱਟਾ ਹੋਇਆ ਹੈ ਜਾਂ ਜੌਬ ਰੁਕੇ ਹੋਏ ਹਨ। ਸੁਧਾਰ: ਵੈਰੀਫਿਕੇਸ਼ਨ ਛੋਟੀ ਪਰ ਅਸਲੀ ਰੱਖੋ, ਅਤੇ ਇਸਨੂੰ ਟਾਈਮਬਾਕਸ ਕਰੋ।
ਡ੍ਰਿੱਲ ਦੁਹਰਾਉਣ ਯੋਗ ਨਹੀਂ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਟੂਲ, ਬਹੁਤ ਸਾਰੇ ਚੈੱਕ, ਬਹੁਤ ਸਾਰੇ ਸੂਰੇ। ਸੁਧਾਰ: ਡ੍ਰਿੱਲ ਨੂੰ ਇੱਕ ਪੰਨਾ ਤੇ ਅਤੇ ਇੱਕ ਮਾਲਕ ਨਾਲ ਘਟਾ ਦਿਓ। ਜੇ ਇਹ ਇਕ ਸਿੰਗਲ ਰਨਬੁੱਕ ਅਤੇ ਇਕ ਸੰਚਾਰ ਚੈਨਲ ਤੋਂ ਨਾਹ ਕੀਤਾ ਜਾ ਸਕੇ, ਤਾੱਨੋਂ ਦਬਾਅ ਹੇਠ ਇਹ ਨਹੀਂ ਹੋਵੇਗਾ।
ਇੱਕ ਵਧੀਆ ਰੋਲਬੈਕ ਡ੍ਰਿੱਲ ਇੱਕ ਆਦਤ ਹੈ, ਹੀਰੋਈਕ ਪ੍ਰਦਰਸ਼ਨ ਨਹੀਂ। ਜੇ ਤੁਸੀਂ ਸ਼ਾਂਤ ਤਰੀਕੇ ਨਾਲ ਖਤਮ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਕਦਮ ਘਟਾਓ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਕਰ ਸਕੋ, ਫਿਰ ਕੇਵਲ ਉਹੀ ਚੀਜ਼ ਜੋ ਸੱਚਮੁੱਚ ਜੋਖਮ ਘਟਾਉਂਦੀ ਹੈ ਸ਼ਾਮਿਲ ਕਰੋ।
ਰੋਲਬੈਕ ਡ੍ਰਿੱਲ ਸਾਰੇ ਇੱਕ-ਸਫ਼ੇ ਚੈੱਕਲਿਸਟ ਦੀ ਪਾਲਣਾ ਕਰਨ 'ਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ। ਇਸਨੂੰ ਉਸ ਥਾਂ ਪਿਨ ਕਰੋ ਜਿੱਥੇ ਤੁਹਾਡੀ ਟੀਮ ਅਸਲ ਵਿੱਚ ਵੇਖਦੀ ਹੈ।
ਇੱਕ ਸੰਕੁਚਿਤ ਵਰਜਨ ਜੋ ਤੁਸੀਂ 10 ਮਿੰਟ ਤੋਂ ਘੱਟ ਵਿੱਚ ਚਲਾ ਸਕਦੇ ਹੋ (ਸੈਟਅੱਪ ਅਤੇ ਵੈਰੀਫਿਕੇਸ਼ਨ ਸਹਿਤ):
ਡ੍ਰਿੱਲਾਂ ਇਨ੍ਹਾ ਹੱਦ ਤੱਕ ਅਕਸਰ ਚਲਾਓ ਕਿ ਕਦਮ ਆਮ ਹੋ ਜਾਣ। ਮਹੀਨਾਵਾਰੀ ਇੱਕ ਚੰਗਾ ਡੀਫੌਲਟ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਉਤਪਾਦ ਹਰ ਰੋਜ਼ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਹਰ ਦੋ ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਚਲਾਓ, ਪਰ ਵੈਰੀਫਿਕੇਸ਼ਨ ਨੂੰ ਮੂਖੀ ਯੂਜ਼ਰ ਪਾਥ 'ਤੇ ਕੇਂਦਰਿਤ ਰੱਖੋ।
ਹਰ ਡ੍ਰਿੱਲ ਤੋਂ ਬਾਅਦ ਰਨਬੁੱਕ ਉਸੀ ਦਿਨ ਅੱਪਡੇਟ ਕਰੋ ਜਦ ਤੱਕ ਯਾਦ ਤਾਜ਼ਾ ਹੈ। ਇਸਨੂੰ ਰੀਲੀਜ਼ ਨੋਟਸ ਨਾਲ ਸਟੋਰ ਕਰੋ, ਅਤੇ ਇੱਕ ਦਿਤੀ ਹੋਈ "last tested" ਲਾਈਨ ਜੋੜੋ ਤਾਂ ਕਿ ਕੋਈ ਵੀ ਜੰਗੀ ਪ੍ਰਕਿਰਿਆ 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੇ।
ਕੇਵਲ ਉਹੀ ਮਾਪੋ ਜੋ ਤੁਹਾਨੂੰ ਸੁਧਾਰ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇ:
ਜੇ ਤੁਹਾਡੀ ਟੀਮ Koder.ai 'ਤੇ ਨਿਰਭਰ ਹੈ, ਤਾਂ snapshots ਅਤੇ rollback ਨੂੰ ਆਦਤ ਬਣਾਓ: ਸਨੇਪਸ਼ਾਟਾਂ ਨੂੰ ਲਗਾਤਾਰ ਨਾਂ ਦਿਓ, ਉਸੇ ਇੰਟਰਫੇਸ ਵਿੱਚ restores rehearse ਕਰੋ ਜੋ ਤੁਸੀਂ on-call ਵਰਤੋਗੇ, ਅਤੇ verifier ਸਟੈਪਾਂ ਵਿੱਚ ਤੇਜ਼ custom-domain ਅਤੇ ਇੰਟੇਗਰੇਸ਼ਨ ਚੈੱਕ ਸ਼ਾਮਿਲ ਕਰੋ। ਰਨਬੁੱਕ ਵਿੱਚ ਇਸਦਾ ਜ਼ਿਕਰ ਰੱਖੋ ਤਾਂ ਕਿ ਡ੍ਰਿੱਲ ਉਹੀ ਢੰਗ ਹੋ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ship ਕਰਦੇ ਹੋ।
A rollback drill ਉਹ ਅਭਿਆਸ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਖਰਾਬ ਰੀਲੀਜ਼ ਦੀ ਨਕਲ ਕਰਦੇ ਹੋ ਅਤੇ ਲਿਖਤੀ ਰੂਟੀਨ ਦੇ ਨਾਲ ਅਖੀਰ ਦੇ ਜਾਣੇ-ਚੰਗੇ ਵਰਜ਼ਨ ਨੂੰ ਰੀਸਟੋਰ ਕਰਦੇ ਹੋ।
ਮਕਸਦ "ਜਲਦੀ ਡੀਬੱਗ ਕਰਨਾ" ਨਹੀਂ—ਇਹ ਦਬਾਅ ਹੇਠਾਂ ਸੇਵਾ ਨੂੰ ਦੋਹਰਾਉਣਯੋਗ ਅਤੇ ਸ਼ਾਂਤ ਢੰਗ ਨਾਲ ਰੀਸਟੋਰ ਕਰਨ ਲਈ ਹੈ।
ਇਕ ਪ੍ਰੀ-ਸੈਟ ਟ੍ਰਿੱਗਰ ਵਰਤੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਘੜੀ ਦੇ ਵੇਲੇ ਵਿਚ ਵਿਚਾਰ-ਵਿਮਰਸ਼ ਨਾ ਕਰੋ। ਆਮ ਨੀਤੀ-ਅਸੂਲ:
ਜੇ ਟ੍ਰਿੱਗਰ ਮੱਲਿਆ ਤਾਂ ਪਹਿਲਾਂ ਰੋਲਬੈਕ ਕਰੋ, ਫਿਰ ਯੂਜ਼ਰ ਸੁਰੱਖਿਅਤ ਹੋਣ ਉਪਰੰਤ ਜ਼ਾਂਚ ਕਰੋ।
ਇਸਦਾ ਅਰਥ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲੇ ਵਰਜ਼ਨ 'ਤੇ ਵਾਪਸ ਲਿਆ ਸਕਦੇ ਹੋ—ਭਾਵੇਂ ਨਵੀਂ ਰੀਲੀਜ਼ ਅਜੇ ਵੀ ਖ਼ਰਾਬ ਹੋਵੇ।
ਅਮਲ ਵਿੱਚ, “ਰੈਸਟੋਰਡ” ਤਦੋਂ ਮੰਨੀ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਕੁਝ ਘੱਟ ਸੰਕੇਤ ਸੁਧਰ ਜਾਂਦੇ ਹਨ (ਮੁੱਖ ਯੂਜ਼ਰ ਐਕਸ਼ਨ ਚੱਲਦਾ ਹੈ, ਗਲਤੀ ਦਰ ਅਤੇ ਲੇਟੈਂਸੀ ਨੇੜੇ-ਨਿਰਧਾਰਤ ਸਥਿਤੀ 'ਤੇ ਆ ਜਾਂਦੇ ਹਨ, ਕੋਈ ਕ੍ਰੈਸ਼ ਲੂਪ ਨਹੀਂ)।
ਉਸ ਟਾਰਗਿਟ ਨੂੰ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਟੀਮ ਲਈ ਸੈਕਿੰਡਾਂ ਵਿੱਚ ਚੁਣਿਆ ਜਾ ਸਕੇ, ਬਿਨਾਂ ਵਿਚਾਰ-ਵਿਮਰਸ਼ ਦੇ:
“ਪਿਛਲਾ ਚੰਗਾ” ਉਸ ਰੀਲੀਜ਼ ਨੂੰ ਕਹੋ ਜੋ ਆਖ਼ਰੀ ਵਾਰੀ ਮਾਨੀਟਰਿੰਗ ਨਾਰਮਲ ਸੀ ਅਤੇ ਜਿਸ 'ਤੇ ਕੋਈ ਸਰਗਰਮ ਇਨਸਿਡੈਂਟ ਨਹੀਂ ਸੀ—"ਜੋ ਲੋਕ ਯਾਦ ਰੱਖਦੇ ਹਨ" ਨਹੀਂ।
ਘੱਟੋ-ਘੱਟ ਇਹਨਾਂ ਨੂੰ ਹਰ ਰੀਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਕੈਪਚਰ ਕਰੋ:
ਡੇਟਾਬੇਸ ਬਦਲਾਅ ਆਮ ਤਰ੍ਹਾਂ ਫਸਾਉਂਦੇ ਹਨ—ਜੇ ਸਕੀਮਾ ਅਣਕੰਪੈਟਿਬਲ ਹੋਵੇ ਤਾਂ ਐਪ ਰੋਲਬੈਕ ਕਾਰਗਰ ਨਹੀਂ ਰਹੇਗਾ।
ਇन्हਾਂ ਨੂੰ ਐਸਾ ਨਾਮ ਦਿਓ ਜੋ sort ਹੋ ਜਾਵੇ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਮਿਲ ਜਾਏ, ਉਦਾਹਰਣ:
prod-YYYY-MM-DD-HHMM-vX.Y.Z-commitABC123Environment + timestamp + version + commit ਸ਼ਾਮਿਲ ਕਰੋ। ਲਗਾਤਾਰ ਨਾਂਕਰਨ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਬਨਿਸਬਤ ਕਿ ਕਿਸੇ ਖਾਸ ਫਾਰਮੈਟ ਦੇ।
ਛੋਟੀ ਟੀਮਾਂ ਲਈ ਇੱਕ ਸਧਾਰਣ, ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਵੰਡ:
ਅਭਿਆਸ ਦੌਰਾਨ Deployer ਅਤੇ Verifier ਇਕੱਠੇ ਨਾ ਹੋਣ – ਤੁਸੀਂ ਇੱਕ ਸਵੈਤੰਤ੍ਰ "ਸੱਚਮੁੱਚ ਹੋਇਆ" ਚੈੱਕ ਚਾਹੁੰਦੇ ਹੋ।
ਇਹ ਛੋਟਾ ਅਤੇ ਪਾਸ/ਫੇਲ ਹੋਣਯੋਗ ਰੱਖੋ। ਵਧੀਆ must-pass ਚੈਕ:
ਫਿਰ error rate ਅਤੇ latency ਦੇਖੋ ਕਿ ਨਾਰਮਲ ਵੱਲ ਵਾਪਸ ਆ ਰਹੇ ਹਨ, ਅਤੇ queues/jobs ਨੂੰ ਪਿੱਛੇ ਨਹੀਂ ਛੱਡ ਰਹੇ।
5-ਮਿੰਟ ਪਾਥ 'ਚ ਡੇਟਾਬੇਸ ਨੂੰ ਰੋਲਬੈਕ ਕਰਨਾ ਸ਼ਾਮਲ ਨਾ ਕਰੋ। ਇਸ ਦੀ ਜਗ੍ਹਾ:
ਇਸ ਨਾਲ ਤੇਜ਼ ਰੋਲਬੈਕ ਰਾਹ ਸੁਰੱਖਿਅਤ ਅਤੇ ਅਨੁਮਾਨਯੋਗ ਰਹਿੰਦੀ ਹੈ।
ਜੇ ਤੁਹਾਡਾ ਪਲੇਟਫਾਰਮ snapshots ਅਤੇ restore ਰੀਲੀਜ਼ ਫਲੋ ਦਾ ਹਿੱਸਾ ਹੈ ਤਾਂ ਡ੍ਰਿੱਲ ਆਸਾਨ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ “ਜਾਣਿਆ-ਚੰਗਾ ਤੇ ਵਾਪਸ ਜਾਓ” ਇੱਕ ਨਾਰਮਲ ਕਿਰਿਆ ਹੋ ਜਾਂਦੀ ਹੈ।
Koder.ai 'ਤੇ ਖ਼ਾਸ ਤੌਰ 'ਤੇ, ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ:
ਉਸ ਫਿਰ ਵੀ, ਡ੍ਰਿੱਲ ਲਈ ਕਿਰਦਾਰ, ਟ੍ਰਿੱਗਰ ਅਤੇ ਛੋਟੀ ਵੈਰੀਫਿਕੇਸ਼ਨ ਲਿਸਟ ਲਾਜ਼ਮੀ ਹੈ—ਟੂਲ ਰੁਟੀਨ ਦੀ ਜਗ੍ਹਾ ਨਹੀਂ ਲੈਂਦੇ।