ਰੋਲਬੈਕ ਡ੍ਰਿੱਲ ਪਲੇਬੁੱਕ: 5 ਮਿੰਟ ਵਿੱਚ ਟੁੱਟੀ ਰੀਲੀਜ਼ ਰੀਸਟੋਰ ਕਰੋ

ਰੋਲਬੈਕ ਕਿਉਂ ਡਰਾਉਣਾ ਲੱਗਦਾ ਹੈ (ਅਤੇ ਅਭਿਆਸ ਕਿਵੇਂ ਮਦਦ ਕਰਦਾ ਹੈ)

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

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

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

ਇਨਸੀਡੈਂਟ ਦੌਰਾਨ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੀ ਕੀਮਤ ਹੋਂਦੀ ਹੈ। ਤੁਸੀਂ ਸਮਾਂ ਗਵਾਉਂਦੇ ਹੋ, ਯੂਜ਼ਰਾਂ ਦਾ ਭਰੋਸਾ ਘਟਦਾ ਹੈ, ਅਤੇ ਤੁਰੰਤ ਕੀਤੇ ਗਏ ਬੇਹਦਰੇ ਬਦਲਾਅ ਦੂਜਾ ਆਊਟੇਜ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ। ਇੰਜਨੀਅਰ ਵੀ ਬਹੁਤ ਸਾਰੀਆਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਖਿੱਚੇ ਜਾਂਦੇ ਹਨ: ਡੀਬੱਗਿੰਗ, ਸੰਦੇਸ਼ਾ ਭੇਜਣ ਅਤੇ ਫੈਸਲੇ ਲੈਣ।

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

ਜੇ ਤੁਹਾਡੀ ਡਿਪਲੋਇਮੈਂਟ ਸੈਟਅੱਪ ਪਹਿਲਾਂ ਤੋਂ ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਰੀਸਟੋਰ ਸਮਰਥਨ ਕਰਦੀ ਹੈ (ਕੁਝ ਪਲੇਟਫਾਰਮ, ਜਿਵੇਂ Koder.ai, ਇਸਨੂੰ ਰੀਲੀਜ਼ ਫਲੋ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਦੇ ਹਨ), ਤਾਂ ਡ੍ਰਿੱਲ ਆਸਾਨ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ "ਜਾਣਿਆ-ਚੰਗਾ ਤੇ ਵਾਪਸ ਜਾਓ" ਇੱਕ ਆਮ ਕਾਰਵਾਈ ਬਣ ਜਾਂਦੀ ਹੈ, ਨਾਂ ਕਿ ਇੱਕ ਐਮਰਜੈਂਸੀ ਪ੍ਰਕਿਰਿਆ। ਕਿਸੇ ਵੀ ਹਾਲਤ ਵਿੱਚ, ਮਨੋਰਥ ਇੱਕੋ ਹੀ ਹੈ: ਜਦੋਂ ਲੋੜ ਹੋਵੇ, ਕਿਸੇ ਨੂੰ ਵੀ ਇੰਪਰੀਵਾਇਜ਼ ਕਰਨ ਦੀ ਲੋੜ ਨਾ ਪਵੇ।

“5 ਮਿੰਟ ਵਿੱਚ ਰੀਸਟੋਰ” ਦਾ ਅਸਲ ਮਤਲਬ

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

ਸੇਵਾ ਪਹਿਲਾਂ, ਫਿਕਸ ਬਾਅਦ ਵਿੱਚ। ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਸੇਵਾ ਰੀਸਟੋਰ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਅਸਲੀ ਬੱਗ ਲੱਭਣ ਲਈ ਸ਼ਾਂਤ ਸਮਾਂ ਖਰੀਦ ਲੈਂਦੇ ਹੋ।

5 ਮਿੰਟ ਕਾਰਵਾਈ ਲਈ ਹਨ, ਚਰਚਾ ਲਈ ਨਹੀਂ

ਟਾਈਮਰ ਉਸ ਵੇਲੇ ਚਲਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਮੰਨ ਲੈਂਦੇ ਹੋ: “ਅਸੀਂ ਰੋਲਬੈਕ ਕਰ ਰਹੇ ਹਾਂ।” ਇਸ ਵਿੱਚ Lambੜੀ ਚਰਚਾ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦੀ ਕਿ ਸ਼ਾਇਦ ਚੀਜ਼ਾਂ ਖੁਦ ਠੀਕ ਹੋ ਜਾਣ।

ਆਪਣੇ ਰੋਲਬੈਕ ਟ੍ਰਿਗਰ ਅੱਗੇ ਹੀ ਫੈਸਲੋ। ਉਦਾਹਰਣ ਲਈ: “ਜੇ ਡਿਪਲੋਇ ਤੋਂ ਬਾਅਦ 3 ਮਿੰਟਾਂ ਲਈ ਚੈਕਆਉਟ ਦੀਆਂ ਗਲਤੀਆਂ X% ਤੋਂ ਉੱਪਰ ਰਹਿੰਦੀਆਂ ਹਨ ਤਾਂ ਅਸੀਂ ਰੋਲਬੈਕ ਕਰਦੇ ਹਾਂ।” ਜਦੋਂ ਟ੍ਰਿਗਰ ਲੱਗਦਾ ਹੈ, ਤੁਸੀਂ ਸਕ੍ਰਿਪਟ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹੋ।

“ਰੀਸਟੋਰਡ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ

“ਰੀਸਟੋਰਡ” ਉਹ ਛੋਟਾ ਸੈੱਟ ਸਿਗਨਲਾਂ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਤੋਂ ਪਤਾ ਲੱਗੇ ਕਿ ਯੂਜ਼ਰ ਸੁਰੱਖਿਅਤ ਹਨ ਅਤੇ ਸਿਸਟਮ ਸਥਿਰ ਹੈ। ਇਸਨੂੰ ਤੰਗ ਅਤੇ ਚੈੱਕ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਰੱਖੋ:

• ਮੁੱਖ ਯੂਜ਼ਰ ਐਕਸ਼ਨ ਦੁਬਾਰਾ ਕੰਮ ਕਰਦਾ ਹੈ (login, checkout, search ਜਾਂ ਤੁਹਾਡੇ ਐਪ ਦੀ ਉਹ ਇਕ ਜ਼ਰੂਰੀ ਚੀਜ਼)
• ਗਲਤੀ ਦਰ ਕਰੀਬ-ਕਰੀਬ ਨਾਰਮਲ ਤੇ ਆ ਜਾਂਦੀ ਹੈ
• ਲੇਟੈਂਸੀ ਸਵੀਕਾਰਯੋਗ ਹੱਦ ਵਿੱਚ ਵਾਪਸ ਆ ਜਾਂਦੀ ਹੈ
• ਕੋਈ ਕ੍ਰੈਸ਼ ਲੂਪ ਜਾਂ ਰੀਸਟਾਰਟ ਸਟਾਰਮ ਨਹੀਂ

ਜਦੋਂ ਇਹ ਸੰਕੇਤ ਠੀਕ ਲੱਗਣ, 5 ਮਿੰਟ ਦਾ ਟਾਈਮਰ ਬੰਦ ਕਰੋ। ਹੋਰ ਸਭ ਕੁਝ ਬਾਅਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਡ੍ਰਿੱਲ ਸੱਚਾ ਰੱਖਣ ਲਈ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦਰਜ ਕਰੋ ਕਿ 5 ਮਿੰਟ ਦੇ ਰਾਹ ਵਿੱਚ ਤੁਸੀਂ ਕੀ ਨਹੀਂ ਕਰ ਰਹੇ: ਡੀਪ ਡੀਬੱਗਿੰਗ, ਕੋਡ ਬਦਲਾਅ ਜਾਂ ਹਾਟਫਿਕਸ ਰੀਲੀਜ਼, ਅਤੇ ਕੋਈ ਵੀ ਐਸਾ ਕੰਮ ਜੋ ਇੰਜਨੀਅਰਿੰਗ ਦਾ ਕੰਮ ਬਣ ਜਾਵੇ।

ਉਹ ਰੋਲਬੈਕ ਅਪ੍ਰੋਚ ਚੁਣੋ ਜੋ ਟੀਮ ਦੁਹਰਾਇਆ ਕਰ ਸਕੇ

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

ਤੁਹਾਡੀ ਡ੍ਰਿੱਲ ਚਾਰ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇਵੇ:

• ਅਸੀਂ ਰੋਲਬੈਕ ਕਰੀਏ ਜਾਂ ਹਾਟਫਿਕਸ?
• ਅਸੀਂ ਕਿਸ ਨੂੰ ਰੋਲਬੈਕ ਕਰ ਰਹੇ ਹਾਂ?
• ਰੋਲਬੈਕ ਦਾ ਟ੍ਰਿੱਗਰ ਕੀ ਹੈ?
• ਕੌਣ ਆਦਿ-ਕਹਿੰਦਾ "ਕਰ ਦਿਓ"?

ਰੋਲਬੈਕ ਵర్సਸ ਹਾਟਫਿਕਸ: ਡੀਫੌਲਟ ਚੁਣੋ

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

ਇੱਕ ਸਧਾਰਣ ਡੀਫੌਲਟ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ: ਜੇ ਯੂਜ਼ਰ ਮੁੱਖ ਐਕਸ਼ਨ ਨਹੀਂ ਪੂਰਾ ਕਰ ਸਕਦੇ (checkout, login, signup) ਜਾਂ ਗਲਤੀ ਦਰ ਵੱਧ ਜਾਂਦੀ ਹੈ, ਪਹਿਲਾਂ ਰੋਲਬੈਕ ਕਰੋ ਅਤੇ ਬਾਅਦ 'ਚ ਠੀਕ ਕਰੋ। ਅਣਅਨੰਦਕ ਮਸਲਿਆਂ ਲਈ ਹਾਟਫਿਕਸ ਰੱਖੋ।

ਰੋਲਬੈਕ ਟਾਰਗਿਟ ਚੁਣੋ

ਤੁਹਾਡਾ "ਟਾਰਗਿਟ" ਕੁਝ ਏਸਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਟੀਮ ਫਟਾਫਟ ਚੁਣ ਸਕੇ, ਬਿਨਾਂ ਵਿਚਾਰ-ਵਿਮਰਸ਼ ਦੇ। ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਤਿੰਨ ਆਮ ਟਾਰਗਿਟ ਵਰਤਦੀਆਂ ਹਨ:

• ਪਹਿਲਾ ਪਿਛਲਾ ਵਰਜ਼ਨ (ਆਖ਼ਰੀ ਰੀਲੀਜ਼ ਜੋ ਚੈੱਕ ਪਾਸ ਕਰ ਚੁੱਕੀ ਸੀ)
• ਇੱਕ ਡਿਪਲੋਇਮੈਂਟ ਸਨੇਪਸ਼ਾਟ ਜੋ ਤੁਸੀਂ ਰੀਸਟੋਰ ਕਰ ਸਕਦੇ ਹੋ
• ਸਿਰਫ਼ ਕੰਫਿਗ ਰੋਲਬੈਕ (ਫੀਚਰ ਫਲੈਗ ਜਾਂ env ਬਦਲਾਅ)

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

ਇਹ ਵੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਕਿ "ਪਿਛਲਾ ਚੰਗਾ" ਕੀ ਮੰਨਿਆ ਜਾਵੇ। ਇਹ ਉਹ ਸਭ ਤੋਂ ਹਾਲੀਆ ਰੀਲੀਜ਼ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜਿਸ ਨੇ ਮਾਨੀਟਰਿੰਗ ਚੈੱਕ ਪਾਸ ਕੀਤੇ ਹੋਣ ਅਤੇ ਜਿਸ 'ਤੇ ਕੋਈ ਸਰਗਰਮ ਇਨਸਿਡੈਂਟ ਨਾ ਹੋਵੇ—ਨਾ ਕਿ "ਉਹ ਜੋ ਲੋਕ ਯਾਦ ਰੱਖਦੇ ਹਨ"।

ਟ੍ਰਿਗਰ ਅਤੇ ਅਥਾਰਟੀ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ

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

ਫਿਰ ਫੈਸਲੋ ਕਿ ਕੌਣ ਰੋਲਬੈਕ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇ ਸਕਦਾ ਹੈ। ਇੱਕ ਭੂਮਿਕਾ ਚੁਣੋ (incident lead ਜਾਂ on-call), ਅਤੇ ਇੱਕ ਬੈਕਅਪ। ਹੋਰ ਸਾਰੇ ਸਲਾਹ ਦੇ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਰੁਕਾਵਟ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਜਦੋਂ ਟ੍ਰਿਗਰ ਲੱਗੇ ਅਤੇ ਅਪਰੂਵਰ ਕਹੇ "ਰੋਲਬੈਕ", ਟੀਮ ਹਰ ਵਾਰੀ ਇੱਕੋ ਹੀ ਕਦਮ ਚਲਾਏਗੀ।

ਹਰ ਰੀਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਸਨੇਪਸ਼ਾਟ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ

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

ਕੈਪਚਰ ਕਰਨ ਲਈ ਪੰਜ ਚੀਜ਼ਾਂ

ਹਰ ਰੀਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਇਹਨਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਬਿਨਾਂ ਚੈਟ ਲੌਗ ਖੋਜੇ ਪਕੜਨ ਯੋਗ ਬਣਾਓ:

• ਜੋ ਐਪ ਬਿਲਡ ਤੁਸੀਂ ਭੇਜਿਆ: commit hash, version number, ਅਤੇ build artifact (container tag, bundle ਜਾਂ package).
• ਡੇਟਾਬੇਸ ਸਥਿਤੀ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਯੋਜਨਾ: ਕਿਹੜੀਆਂ migrations ਲਾਗੂ ਕੀਤੀਆਂ ਗਈਆਂ ਅਤੇ ਕੀ ਉਹ ਵਾਪਸ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਖਤਰਨਾਕ ਬਦਲਾਅ ਲਈ ਤੇਜ਼ ਬੈਕਅਪ ਜਾਂ ਸਨੇਪਸ਼ਾਟ ਲਵੋ।
• ਡਿਪਲੋਇ ਸਮੇਂ ਦੀ ਕੰਫਿਗਰੇਸ਼ਨ: ਫੀਚਰ ਫਲੈਗ, environment variables, third-party endpoints, ਅਤੇ ਕੀ ਬਦਲਿਆ। secrets ਸੁਰੱਖਿਅਤ ਸਿਸਟਮ ਵਿੱਚ ਰੱਖੋ, ਪਰ ਤਬ ਵੀ ਬਦਲਾਵਾਂ ਦਾ ਵਰਜ਼ਨ ਕੀਤਾ ਰਿਕਾਰਡ ਚਾਹੀਦਾ ਹੈ।
• ਇੰਫਰਾਸਟ੍ਰੱਕਚਰ ਅਤੇ ਰਾਊਟਿੰਗ ਸੈਟਿੰਗਜ਼: ਡੋਮੇਨ, ਸਰਟੀਫਿਕੇਟ, ਲੋਡ ਬੈਲੇਂਸਰ ਨਿਯਮ, ਅਤੇ ਕੋਈ ਵੀ "ਟ੍ਰੈਫਿਕ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ" ਸਵਿੱਚ।
• ਇੱਕ ਛੋਟੀ ਰੀਲੀਜ਼ ਨੋਟ: ਇੱਕ ਵਾਕ ਵਿੱਚ ਕੀ ਬਦਲਿਆ ਅਤੇ ਇਕ ਵਾਕ ਵਿੱਚ ਰੋਲਬੈਕ ਸਫਲਤਾ ਕਿਵੇਂ ਵੇਰਿਫਾਈ ਕਰਨੀ ਹੈ।

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

ਸਨੇਪਸ਼ਾਟਾਂ ਦਾ ਨਾਮ ਏਸ ਤਰ੍ਹਾਂ ਰੱਖੋ ਕਿ ਤੁਸੀਂ ਸਕਿੰਟਾਂ ਵਿੱਚ ਲੱਭ ਸਕੋ

ਹਰ ਜਗ੍ਹਾ ਇੱਕ ਨਾਂਕਰਨ ਨਿਯਮ ਵਰਤੋ ਅਤੇ ਇਸਨੂੰ sortable ਬਣਾਓ:

prod-2026-01-09-1420-v1.8.3-commitA1B2C3

ਵਾਤਾਵਰਨ, timestamp, ਵਰਜ਼ਨ ਅਤੇ commit ਸ਼ਾਮਿਲ ਕਰੋ। ਜੇ ਤੁਹਾਡੇ ਟੂਲਾਂ ਵਿੱਚ UI ਵਿੱਚ ਸਨੇਪਸ਼ਾਟ ਸਹਾਇਤਾ ਹੈ, ਉੱਥੇ ਵੀ ਇਹੀ ਨਾਂਕਰਨ ਨਿਯਮ ਵਰਤੋ ਤਾਂ ਕਿ ਕੋਈ ਵੀ ਜਦੋਂ ਇਨਸੀਡੈਂਟ ਹੋਵੇ ਤੇਜ਼ੀ ਨਾਲ ਠੀਕ ਰੀਸਟੋਰ ਪਾਇੰਟ ਲੱਭ ਸਕੇ।

ਰੋਲਸ: ਕੌਣ ਕੀ ਕਲਿੱਕ ਕਰਦਾ ਹੈ (ਅਤੇ ਕੌਣ ਸਿਰਫ਼ ਵੇਖਦਾ ਹੈ)

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

ਛੋਟੀ ਅਤੇ ਮੱਧਮ ਆਕਾਰ ਦੀਆਂ ਟੀਮਾਂ ਲਈ ਇਹ ਭੂਮਿਕਾਵਾਂ ਵਧੀਆ ਕੰਮ ਕਰਦੀਆਂ ਹਨ (ਇੱਕ ਵਿਅਕਤੀ ਦੋ-ਹੈਟ ਪਹਿਨ ਸਕਦਾ ਹੈ, ਪਰ ਡ੍ਰਿੱਲ ਦੌਰਾਨ Deployer ਅਤੇ Verifier ਨੂੰ ਇਕੱਠੇ ਨਾ ਜੋੜੋ):

• Incident lead (ਟਾਈਮਕੀਪਰ ਅਤੇ ਫੈਸਲਾ ਕਰਨ ਵਾਲਾ): ਸਫਲਤਾ ਟਾਰਗਿਟ ਦੱਸਦਾ ਅਤੇ ਰੋਲਬੈਕ ਕਹਿੰਦਾ ਹੈ।
• Deployer (ਹੱਥ ਕੰਮ ਤੇ): ਬਿਲਕੁਲ ਲਿਖੇ ਕਦਮ ਅਨੁਸਾਰ ਰੋਲਬੈਕ ਕਰਦਾ ਅਤੇ ਜੋ ਕਰ ਰਿਹਾ ਹੈ ਉਸਨੂੰ ਬਿਆਨ ਕਰਦਾ।
• Verifier (ਇਸਦਾ ਸਬੂਤ): ਜ਼ਰੂਰੀ ਚੈਕ ਚਲਾਂਦਾ ਅਤੇ ਕੁੰਜੀ ਸੰਕੇਤਾਂ ਨੂੰ ਦੇਖਦਾ।
• Communicator (ਬਾਹਰਲਾ ਇੱਕ ਢੰਗ): ਸੰਖੇਪ, ਨਿਯਮਤ ਅਪਡੇਟ ਸਟੇਕਹੋਲਡਰ ਅਤੇ ਸਪੋਰਟ ਨੂੰ ਪੋਸਟ ਕਰਦਾ।

ਪ੍ਰਵਾਨਗੀਆਂ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀਆਂ ਹਨ ਕਿ ਇਹ ਯੋਜਨਾ ਅਸਲ ਹੈ ਜਾਂ ਸਿਰਫ਼ ਇੱਕ ਸੋਹਣਾ ਦਸਤਾਵੇਜ਼। ਡ੍ਰਿੱਲ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਕੌਣ ਪ੍ਰੋਡਕਸ਼ਨ ਰੋਲਬੈਕ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਐਮਰਜੈਂਸੀਜ਼ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ।

ਇਕ ਸਧਾਰਣ ਸੈਟਅੱਪ:

• Deployer ਨੂੰ on-call ਘੁੰਮਣ ਵਾਲੀ ਜ਼ਿੰਮੇਵਾਰੀ ਜਾਂ ਨਿਰਧਾਰਿਤ ਡ੍ਰਿੱਲ ਵਿਂਡੋ ਦੌਰਾਨ ਰੋਲਬੈਕ ਹੱਕ ਦਿਓ।
• Incident lead ਨੂੰ ਕਾਰਵਾਈ ਮਨਜ਼ੂਰ ਕਰਨ ਦਿਓ (ਭਾਵੇਂ ਉਸ ਕੋਲ ਬਟਨ ਨਾ ਹੋਵੇ)।
• Verifier ਨੂੰ ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਲੌਗ ਲਈ read-only ਪਹੁੰਚ ਦਿਓ।
• ਇੱਕ break-glass ਵਿਕਲਪ ਸੈੱਟ ਕਰੋ (audited, ਸਮੇਂ-ਸੀਮਿਤ ਪਹੁੰਚ)।
• ਡ੍ਰਿੱਲ ਸੈਟਅੱਪ ਦੌਰਾਨ ਪਹੁੰਚ ਦੀ ਟੈਸਟਿੰਗ ਕਰੋ, ਨਾ ਕਿ 5-ਮਿੰਟ ਟਾਈਮਰ ਦੌਰਾਨ।

ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਪਲੇਟਫਾਰਮ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ ਜੋ snapshots ਅਤੇ rollback ਸਮਰੱਥ ਕਰਦਾ ਹੈ (ਜਿਵੇਂ Koder.ai), ਤਾਂ ਪਤਾ ਕਰੋ ਕਿ ਕੌਣ snapshots ਬਣਾਉਂਦਾ, ਕੌਣ ਉਨ੍ਹਾਂ ਨੂੰ ਰੀਸਟੋਰ ਕਰ ਸਕਦਾ, ਅਤੇ ਉਹ ਕਾਰਵਾਈ ਕਿੱਥੇ ਦਰਜ ਹੁੰਦੀ ਹੈ।

ਕਦਮ-ਦਰ-ਕਦਮ: ਰੋਲਬੈਕ ਡ੍ਰਿੱਲ ਰਨਬੁੱਕ

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

ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ

ਇੱਕ ਸਪਸ਼ਟ ਟ੍ਰਿਗਰ ਚੁਣੋ ਅਤੇ ਜਦੋਂ ਡ੍ਰਿੱਲ ਸ਼ੁਰੂ ਕਰੋ ਤਾਂ ਉਹ ਜ਼ੋਰ ਨਾਲ ਕਹੋ। ਉਦਾਹਰਣ: “ਚੈਕਆਉਟ 1 ਮਿੰਟ ਤੋਂ ਵੱਧ 500 ਵਾਪਸ ਕਰ ਰਿਹਾ ਹੈ” ਜਾਂ “ਡਿਪਲੋਇ ਦੇ ਤੁਰੰਤ ਬਾਅਦ error rate ਸਧਾਰਨ ਦਾ 5x ਹੈ।” ਇਸਨੂੰ ਉੱਚ ਆਵਾਜ਼ ਵਿੱਚ ਕਹਿਣ ਨਾਲ ਟੀਮ ਟਰਬਲਸ਼ੂਟਿੰਗ ਮੋਡ ਵਿੱਚ ਨਹੀਂ ਭਟਕੇਗੀ।

ਰਨਬੁੱਕ ਦੇ ਕੋਲ ਇੱਕ ਛੋਟਾ ਤਿਆਰ ਕਰਨ ਵਾਲੀ ਚੈੱਕਲਿਸਟ ਰੱਖੋ:

• ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਸੀਂ ਲਾਈਵ ਹੈਲਥ ਸਿਗਨਲ (uptime, error rate, key user flow) ਵੇਖ ਸਕਦੇ ਹੋ
• ਆਖ਼ਰੀ ਜਾਣਿਆ-ਚੰਗਾ ਵਰਜ਼ਨ ਈਡੈਂਟੀਫਾਇਰ (tag, build, snapshot name) ਪੁਸ਼ਟੀ ਕਰੋ
• ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਰੋਲਬੈਕ ਕਿੱਥੇ ਕੀਤਾ ਜਾਂਦਾ (CI/CD, hosting console, platform UI)
• ਨਵੇਂ ਡਿਪਲੋਇਸ ਨੂੰ ਰੋਕਣ ਦਾ ਤਰੀਕਾ ਪੁਸ਼ਟੀ ਕਰੋ
• ਪੱਕਾ ਕਰੋ ਕਿ ਕੌਣ timestamp ਰਿਕਾਰਡ ਕਰ ਰਿਹਾ ਹੈ

5-ਮਿੰਟ ਰਨਬੁੱਕ

1. ਟਾਈਮਰ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ ਵਿਅਕਤੀ ਟ੍ਰਿਗਰ ਅਤੇ ਫੈਸਲਾ ਬਿਆਨ ਕਰਦਾ: “ਅਸੀਂ ਹੁਣ ਰੋਲਬੈਕ ਕਰ ਰਹੇ ਹਾਂ।”

2. ਚੇਂਜਜ਼ ਨੂੰ ਫ੍ਰੀਜ਼ ਕਰੋ। ਨਵੇਂ ਡਿਪਲੋਇ ਰੋਕੋ ਅਤੇ ਨਾ-ਜ਼ਰੂਰੀ ਸੋਧਾਂ ਰੋਕੋ ਜੋ ਰੋਲਬੈਕ ਦੌਰਾਨ ਸਿਸਟਮ ਬਦਲ ਸਕਦੀਆਂ ਹਨ।

3. ਆਖ਼ਰੀ-ਮੌਕੇ ਸਨੇਪਸ਼ਾਟ ਲਵੋ (ਜੇ ਸੁਰੱਖਿਅਤ ਅਤੇ ਤੇਜ਼ ਹੋ ਸਕੇ)। ਇਹ ਤੁਰੰਤ ਸੁਰੱਖਿਆ ਹੈ ਕਿ ਜੇ ਤੁਹਾਨੂੰ ਬਾਅਦ ਵਿੱਚ ਖਰਾਬ ਸਥਿਤੀ ਦੁਬਾਰਾ ਬਣਾਉਣੀ ਹੋਵੇ। ਇਸਨੂੰ ਸਾਫ਼ ਨਾਂ ਦਿਓ ਅਤੇ ਅੱਗੇ ਵਧੋ।

4. ਰੋਲਬੈਕ ਕਾਰਵਾਈ ਨੂੰ ਬਿਲਕੁਲ ਦਸਤਾਵੇਜ਼ ਅਨੁਸਾਰ ਚਲਾਓ। ਇੰਪਰੋਵਾਈਜ਼ ਨ ਕਰੋ। ਪੁਸ਼ਟੀ ਪ੍ਰੋੰਪਟਾਂ ਨੂੰ ਉੱਚ ਆਵਾਜ਼ ਵਿੱਚ ਪੜ੍ਹੋ ਤਾਂ ਕਿ ਰਿਕਾਰਡਰ ਜੋ ਹੋਇਆ ਉਸਨੂੰ ਲਿਖ ਸਕੇ।

5. ਇੱਕ ਭਰੋਸੇਯੋਗ ਥਾਂ 'ਤੇ ਰੋਲਬੈਕ ਪੂਰਾ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਹਰ ਵਾਰੀ ਇੱਕ ਸਕਰੀਨ ਅਤੇ ਇੱਕ ਸਿਗਨਲ ਵਰਤੋ (deployment history view, “current version” ਲੇਬਲ, ਜਾਂ ਕੋਈ ਸਪਸ਼ਟ status indicator)।

ਕਾਰਵਾਈ ਤੋਂ ਬਾਅਦ ਤੁਰੰਤ ਉਹ ਚੀਜ਼ਾਂ ਕੈਪਚਰ ਕਰੋ ਜੋ ਤਾਜ਼ਾ ਯਾਦ ਰਹਿੰਦੀਆਂ ਹਨ:

• ਫੈਸਲੇ ਦਾ ਸਮਾਂ (ਟ੍ਰਿਗਰ ਬਿਆਨ)
• ਰੋਲਬੈਕ ਸ਼ੁਰੂ ਸਮਾਂ (ਪਹਿਲੀ ਕਲਿੱਕ/ਕਮਾਂਡ)
• ਰੋਲਬੈਕ ਪੂਰਾ ਸਮਾਂ (ਪਿਛਲਾ ਵਰਜ਼ਨ ਸਰਗਰਮ ਹੋਇਆ)
• ਪਹਿਲੀ ਹਰੀ ਵੈਰੀਫਿਕੇਸ਼ਨ ਸਮਾਂ (ਮੁੱਖ ਚੈੱਕ ਪਾਸ)
• ਕੋਈ ਹੈਰਾਨੀ (ਖਰਾਬ ਪਰਮਿਸ਼ਨ, ਅਸਪੱਸ਼ਟ ਬਟਨ, ਢੀਲਾ ਕਦਮ)

ਜੇ ਰੋਲਬੈਕ 5 ਮਿੰਟ ਤੋਂ ਵੱਧ ਲੈਂਦਾ ਹੈ, ਇਸਨੂੰ ਨ ਬਰਦਾਸਤ ਕਰੋ। ਦੇਖੋ ਕਿ ਕਿਹੜਾ ਕਦਮ ਸੌ ਕਦਮ ਲੰਮਾ ਹੋ ਰਿਹਾ ਹੈ, ਰਨਬੁੱਕ ਨੂੰ ਠੀਕ ਕਰੋ ਅਤੇ ਡ੍ਰਿੱਲ ਦੁਹਰਾਓ।

ਰੋਲਬੈਕ ਤੋਂ ਬਾਅਦ ਕੀ ਵੇਰੀਫਾਈ ਕਰਨਾ ਹੈ

ਰੋਲਬੈਕ ਤਦੋਂ ਹੀ "ਕਾਮਯਾਬ" ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਮਹਿਸੂਸ ਹੋਵੇ ਕਿ ਉਹ ਵਾਪਸ ਆ ਗਏ ਹਨ। ਤੁਸੀਂ ਇਹ ਸਾਬਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰ ਰਹੇ ਕਿ ਪੁਰਾਣਾ ਵਰਜ਼ਨ ਡਿਪਲੋਇ ਹੋ ਗਿਆ—ਤੁਸੀਂ ਸਾਬਤ ਕਰ ਰਹੇ ਹੋ ਕਿ ਸੇਵਾ ਮੁੜ ਵਰਤਣਯੋਗ ਅਤੇ ਸਥਿਰ ਹੋ ਗਈ ਹੈ।

ਵੈਰੀਫਿਕੇਸ਼ਨ ਛੋਟੀ ਅਤੇ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਰੱਖੋ। ਜੇ ਲਿਸਟ ਪੰਜ ਤੋਂ ਵੱਧ ਹੋਵੇਗੀ ਤਾਂ ਲੋਕ ਤਣਾਵ ਵਿੱਚ ਰਹਿ ਕੇ ਕੁਝ ਛੱਡ ਦੇਣਗੇ।

3-5 ਜ਼ਰੂਰੀ ਚੈੱਕ

ਉਹ ਚੈਕ ਵਰਤੋਂ ਜੋ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਚਲਾ ਸਕੋ, ਸਪਸ਼ਟ ਪਾਸ/ਫੇਲ ਹੋਣ:

• ਯੂਜ਼ਰ ਲੌਗਇਨ (ਜਾਂ ਸਾਈਨਅੱਪ) ਕਰਕੇ ਘਰ ਸਕ੍ਰੀਨ ਤੱਕ ਬਿਨਾਂ ਗਲਤੀ ਦੇ ਪਹੁੰਚ ਸਕੇ
• ਕੋਰ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਕੰਮ ਕਰਦਾ (checkout, booking, form submit)
• ਇੱਕ ਮੁੱਖ API endpoint 200 ਵਾਪਸ ਕਰਦਾ ਅਤੇ ਰਿਸਪੌਂਸ ਨਾਰਮਲ ਦਿੱਸਦਾ ਹੈ
• ਐਡਮਿਨ/ਸਪੋਰਟ ਇੱਕ ਸੰਕਟਿਕ ਕਾਰਵਾਈ ਕਰ ਸਕਦੇ (refund, cancel, update status)
• ਇੱਕ ਅਕਸਰ ਟੁੱਟਣ ਵਾਲਾ ਏਜ ਫਲੋ ਤਾਂ ਵੀ ਚੱਲ ਰਿਹਾ ਹੋਵੇ (password reset, file upload, search)

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

ਉਹ ਵੀ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਘੁਮਣ-ਫਿਰਣ ਵਾਲੇ ਹਿੱਸੇ ਮੁੜ ਚੱਲ ਰਹੇ ਹਨ। ਬੈਕਗ੍ਰਾਉਂਡ ਜੌਬ ਪ੍ਰੋਸੈਸ ਹੋ ਰਹੇ ਹੋਣ ਅਤੇ ਕਿਊਜ਼ ਘਟ ਰਹੀਆਂ ਹੋਣ; ਨਾ ਵਧ ਰਹੀਆਂ। ਡੇਟਾਬੇਸ ਚੈੱਕ ਤੇਜ਼ ਅਤੇ ਸਧਾਰਣ ਹੋਣ: ਕਨੈਕਸ਼ਨ ਸਥਿਰ, ਕਿਸੇ ਵੱਡੇ ਲੌਕ ਪਾਈਪਅੱਪ ਨਹੀਂ, ਅਤੇ ਐਪ ਲਿਖ ਸਕਦੀ ਹੈ।

ਅੰਤ ਵਿੱਚ, ਬਾਹਰੀ ਸੰਸਾਰ ਨੂੰ ਟੈਸਟ ਕਰੋ ਜੇ ਤੁਸੀਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕਰ ਸਕੋ: ਇੱਕ ਪੇਮੈਂਟ ਟੈਸਟ ਚਲਾਓ, ਬਤਾਓ ਕਿ ਈਮੇਲ ਡਿਲਿਵਰੀ ਬਾਉਂਸ ਨਹੀਂ ਹੋ ਰਹੀ, ਅਤੇ ਵੇਖੋ ਕਿ webhook ਸਵੀਕਾਰ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ (ਜਾਂ ਘੱਟੋ-ਘੱਟ ਫੇਲ ਨਹੀਂ ਹੋ ਰਹੇ)।

“ਆਲ ਕਲਿਅਰ” ਵਾਕਾਂਸ਼ ਦਾ ਫੈਸਲਾ ਕਰੋ

ਇੱਕ ਪੰਗਤ ਪਹਿਲਾਂ ਹੀ ਲਿਖੋ ਤਾਂ ਕਿ ਕੋਈ ਵਿਅਕਤੀ ਇੰਮੀਪ੍ਰੋਵਾਈਜ਼ ਨਾ ਕਰੇ:

“Rollback complete. Core flows verified (login + checkout). Error rate and latency back to normal. Monitoring for 30 minutes. Next update at 14:30.”

ਉਦਾਹਰਣ: ਇੱਕ ਟੁੱਟੀ ਹੋਈ ਰੀਲੀਜ਼ ਅਤੇ ਸਾਫ਼ 5-ਮਿੰਟ ਰੀਸਟੋਰ

ਇੱਕ ਮੰਗਲਵਾਰ ਨੂੰ 10:02 ਵਜੇ. ਨਵੀਂ ਰੀਲੀਜ਼ ਨਿਕਲਦੀ ਹੈ, ਅਤੇ ਇਕ ਮਿੰਟ ਦੇ ਅੰਦਰ ਕੁਝ ਯੂਜ਼ਰ ਲੌਗਇਨ ਨਹੀਂ ਕਰ ਸਕ ਰਹੇ। ਕੁਝ ਨੂੰ “invalid session” ਮਿਲਦਾ ਹੈ, ਦੂਜੇ ਨੂੰ ਸਪਿਨਰ ਜੋ ਕਦੇ ਦੇਸ ਨਹੀਂ ਹੁੰਦਾ। ਸਾਈਨਅੱਪ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਮੁੱਦਾ ਸ਼ੁਰੂ ਵਿੱਚ ਛੁਪਿਆ ਰਹਿ ਸਕਦਾ ਹੈ।

ਪਹਿਲੀ ਸਿਗਨਲ ਆਮ ਤੌਰ 'ਤੇ ਡਰਾਉਣਾ outage ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਇੱਕ ਚੁਪਚਾਪ spike ਹੁੰਦਾ ਹੈ: ਸਪੋਰਟ ਟਿਕਟਾਂ, ਸਫਲ ਲੌਗਇਨਾਂ ਵਿੱਚ ਡਿੱਪ, ਅਤੇ ਕੁਝ ਗੁੱਸੇਵਾਲੇ ਸੁਨੇਹੇ। ਓਨ-ਕਾਲ ਨੂੰ “login success rate down 18% in 5 minutes” ਦਾ ਅਲਰਟ ਮਿਲਦਾ ਹੈ, ਅਤੇ ਸਪੋਰਟ ਪੁਸਟ ਕਰਦਾ ਹੈ: “3 users can’t log in after the update.”

5-ਮਿੰਟ ਰੀਸਟੋਰ (ਇਸ ਤਰ੍ਹਾਂ ਦਿਖ ਸਕਦਾ ਹੈ)

ਕਿਉਂਕਿ ਟੀਮ ਨੇ ਅਭਿਆਸ ਕੀਤਾ ਹੁੰਦਾ ਹੈ, ਉਹ ਜ਼ਿਆਦਾ ਚਰਚਾ ਨਹੀਂ ਕਰਦੇ। ਉਹ ਪੁਸ਼ਟੀ ਕਰਦੇ, ਫੈਸਲਾ ਕਰਦੇ, ਅਤੇ ਕਾਰਵਾਈ ਕਰਦੇ ਹਨ।

• 10:03: On-call ਪੁਸ਼ਟੀ ਕਰਦਾ ਅਤੇ incident lead ਨਿਯੁਕਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
• 10:04: ਰੋਲਬੈਕ ਦਾ ਫੈਸਲਾ। ਨੀਤੀ: ਜੇ login ਟੁੱਟਿਆ ਹੋਇਆ ਹੈ ਅਤੇ 2 ਮਿੰਟ ਵਿੱਚ ਕੋਈ ਸੁਰੱਖਿਅਤ ਫਿਕਸ ਨਹੀਂ ਹੈ, ਤਾਂ ਰੋਲਬੈਕ ਕਰੋ।
• 10:05: Deployer ਪਿਛਲੇ ਜਾਣਿਆ-ਚੰਗੇ ਸਨੇਪਸ਼ਾਟ 'ਤੇ ਰੋਲਬੈਕ ਟਰਿਗਰ ਕਰਦਾ।
• 10:06: ਟ੍ਰੈਫਿਕ ਪਿਛਲੇ ਵਰਜ਼ਨ 'ਤੇ ਵਾਪਸ ਆ ਜਾਂਦੀ ਹੈ। ਟੀਮ ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ 'ਤੇ ਲੌਗਇਨ ਨੂੰ ਮੁੜ-ਟੈਸਟ ਕਰਦੀ ਹੈ।
• 10:07: Incident lead ਪੋਸਟ ਕਰਦਾ “Login restored, monitoring for 10 minutes” ਅਤੇ support ਨੂੰ ਪ੍ਰਭਾਵਤ ਯੂਜ਼ਰਾਂ ਨੂੰ ਜਵਾਬ ਦੇਣ ਨੂੰ ਕਹਿੰਦਾ ਹੈ।

ਕੀ ਰੋਲਬੈਕ ਕੀਤਾ ਗਿਆ: ਵੈੱਬ ਅਤੇ 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 ਮਿੰਟ ਤੋਂ ਘੱਟ ਵਿੱਚ ਚਲਾ ਸਕਦੇ ਹੋ (ਸੈਟਅੱਪ ਅਤੇ ਵੈਰੀਫਿਕੇਸ਼ਨ ਸਹਿਤ):

• ਰੀਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ: ਰੋਲਬੈਕ ਪਾਇੰਟ (snapshot/version) ਪੁਸ਼ਟੀ ਕਰੋ, ਉਮੀਦ ਕੀਤੀ "ਚੰਗੀ" ਵਰਤੋਂ ਦਰਜ ਕਰੋ, ਰੋਲਜ਼ ਨਿਯੁਕਤ ਕਰੋ (deployer, verifier, comms).
• ਟ੍ਰਿਗਰ: "rollback starting" ਦਾ ਐਲਾਨ ਕਰੋ, ਟਾਈਮਰ ਚਲਾਓ, ਨਵੇਂ ਡਿਪਲੋਇਜ਼ ਫ੍ਰੀਜ਼ ਕਰੋ.
• ਰੋਲਬੈਕ ਕਾਰਵਾਈ: ਆਖਰੀ ਜਾਣਿਆ-ਚੰਗਾ ਰੀਲੀਜ਼ ਰੀਸਟੋਰ ਕਰੋ, ਜੋ-ਕਲਿੱਕ ਕੀਤਾ ਗਿਆ ਉਸਦਾ ਰਿਕਾਰਡ ਰੱਖੋ।
• ਵੈਰੀਫਾਈ: 2-3 ਮੂਲ ਚੈਕ ਚਲਾਓ (login, main workflow, ਇੱਕ ਇੰਟੇਗ੍ਰੇਸ਼ਨ ਜਾਂ API ਚੈਕ), error rates ਘਟਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
• ਬੰਦ ਕਰੋ: "ਸੇਵਾ ਸਥਿਰ" ਐਲਾਨ ਕਰੋ, ਤਿੰਨ ਨੋਟ ਲਿਖੋ (ਕੀ ਵਧੀਆ ਹੋਇਆ, ਕੀ ਨੇ ਤੁਹਾਨੂੰ ਦੇਰ ਕਰਵਾਇਆ, ਕੀ ਬਦਲਣਾ ਹੈ), ਡਿਪਲੋਇਜ਼ ਅਨਫ੍ਰੀਜ਼ ਕਰੋ।

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

ਹਰ ਡ੍ਰਿੱਲ ਤੋਂ ਬਾਅਦ ਰਨਬੁੱਕ ਉਸੀ ਦਿਨ ਅੱਪਡੇਟ ਕਰੋ ਜਦ ਤੱਕ ਯਾਦ ਤਾਜ਼ਾ ਹੈ। ਇਸਨੂੰ ਰੀਲੀਜ਼ ਨੋਟਸ ਨਾਲ ਸਟੋਰ ਕਰੋ, ਅਤੇ ਇੱਕ ਦਿਤੀ ਹੋਈ "last tested" ਲਾਈਨ ਜੋੜੋ ਤਾਂ ਕਿ ਕੋਈ ਵੀ ਜੰਗੀ ਪ੍ਰਕਿਰਿਆ 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੇ।

ਕੇਵਲ ਉਹੀ ਮਾਪੋ ਜੋ ਤੁਹਾਨੂੰ ਸੁਧਾਰ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇ:

• Time-to-rollback (ਘੋਸ਼ਣਾ ਤੋਂ ਰੀਸਟੋਰ ਤਕ)
• Time-to-verify (ਰੀਸਟੋਰ ਤੋਂ ਸਥਿਰ ਤਕ)
• ਭੂਮਿਕਾ ਸਪਸ਼ਟਤਾ (ਕਿੱਥੇ ਲੋਕ ਹਿਚਕਿਚਾਏ ਜਾਂ duplicate ਕੰਮ ਕੀਤਾ?)
• ਘੱਟ ਜਾਣਕਾਰੀ (ਕ੍ਰੈਡੈਂਸ਼ਿਯਲ, ਪਰਮਿਸ਼ਨ, ਸਨੇਪਸ਼ਾਟ ਸਥਾਨ)

ਜੇ ਤੁਹਾਡੀ ਟੀਮ Koder.ai 'ਤੇ ਨਿਰਭਰ ਹੈ, ਤਾਂ snapshots ਅਤੇ rollback ਨੂੰ ਆਦਤ ਬਣਾਓ: ਸਨੇਪਸ਼ਾਟਾਂ ਨੂੰ ਲਗਾਤਾਰ ਨਾਂ ਦਿਓ, ਉਸੇ ਇੰਟਰਫੇਸ ਵਿੱਚ restores rehearse ਕਰੋ ਜੋ ਤੁਸੀਂ on-call ਵਰਤੋਗੇ, ਅਤੇ verifier ਸਟੈਪਾਂ ਵਿੱਚ ਤੇਜ਼ custom-domain ਅਤੇ ਇੰਟੇਗਰੇਸ਼ਨ ਚੈੱਕ ਸ਼ਾਮਿਲ ਕਰੋ। ਰਨਬੁੱਕ ਵਿੱਚ ਇਸਦਾ ਜ਼ਿਕਰ ਰੱਖੋ ਤਾਂ ਕਿ ਡ੍ਰਿੱਲ ਉਹੀ ਢੰਗ ਹੋ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ship ਕਰਦੇ ਹੋ।