rollback ਅਤੇ hotfix ਵਿਚਕਾਰ ਫ਼ੈਸਲਾ ਕਰਨ ਲਈ ਤੁਸੀਂ ਕਿਹੜੇ ਮਾਪਦੰਡ ਵਰਤਦੇ ਹੋ?

Question

Accepted Answer

Default **rollback** ਵੱਲ ਹੋਵੋ — ਇਹ ਇੱਕ ਜਾਣੀ-ਪਛਾਣੀ-ਚੰਗੀ ਸਥਿਤੀ ਨੂੰ ਬਹਾਲ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼, ਸਭ ਤੋਂ ਭਰੋਸੇਯੋਗ ਤਰੀਕਾ ਹੈ। **hotfix** ਵੱਲ ਸਿਰਫ਼ ਉਦੋਂ ਵਧੋ ਜਦੋਂ rollback ਅਸੰਭਵ ਹੋਵੇ ਜਾਂ ਅੱਗੇ ਠੀਕ ਕਰਨ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਖ਼ਤਰਨਾਕ ਹੋਵੇ। ਇੱਕ ਸਰਗਰਮ incident ਵਿੱਚ, ਤਰਜੀਹ ਹੈ **ਪਹਿਲਾਂ ਖ਼ੂਨ ਵਹਿਣਾ ਰੋਕੋ**, ਨਿਦਾਨ ਬਾਅਦ ਵਿੱਚ।

## ਫ਼ੈਸਲੇ ਦੇ ਮਾਪਦੰਡ

- **ਕੀ rollback ਸੁਰੱਖਿਅਤ ਅਤੇ ਸੰਭਵ ਹੈ?** ਜੇ ਪਿਛਲਾ version ਜਾਣਿਆ-ਪਛਾਣਿਆ-ਚੰਗਾ ਹੈ ਅਤੇ ਕੁਝ ਵੀ ਨਾ-ਉਲਟਾਉਣਯੋਗ ਨਹੀਂ ਹੋਇਆ, ਤਾਂ roll back ਕਰੋ। ਇਹ ਆਮ ਜਵਾਬ ਹੈ।
- **ਕੀ ਮਾੜੇ release ਨੇ ਨਾ-ਉਲਟਾਉਣਯੋਗ state ਪੈਦਾ ਕੀਤਾ?** ਇੱਕ **database migration** ਜਾਂ data corruption rollback ਨੂੰ bug ਨਾਲੋਂ ਮਾੜਾ ਬਣਾ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਵਾਪਸ ਨਹੀਂ ਜਾ ਸਕਦੇ, ਤਾਂ ਤੁਹਾਨੂੰ ਅੱਗੇ ਠੀਕ ਕਰਨਾ ਪਵੇਗਾ।
- **ਕੀ ਅਸੀਂ fix ਨੂੰ ਸਮਝਦੇ ਹਾਂ?** rollback ਨੂੰ ਕੋਈ ਨਿਦਾਨ ਨਹੀਂ ਚਾਹੀਦਾ — ਇਹੀ ਇਸ ਦੀ ਤਾਕਤ ਹੈ। ਇੱਕ hotfix ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਸਮਝਦੇ incident ਨੂੰ ਡੂੰਘਾ ਕਰ ਸਕਦਾ ਹੈ; ਦਬਾਅ ਹੇਠ ਕਦੇ ਵੀ prod ਵਿੱਚ ਇੱਕ ਅੰਦਾਜ਼ਾ ship ਨਾ ਕਰੋ।
- **ਸੁਰੱਖਿਅਤ state ਤੱਕ ਸਮਾਂ।** ਜੋ ਵੀ ਰਾਹ ਸਭ ਤੋਂ ਘੱਟ ਜੋਖ਼ਮ ਨਾਲ ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਸਥਿਰਤਾ ਤੱਕ ਪਹੁੰਚੇ, ਉਹ ਚੁਣੋ। ਇੱਕ ਇੱਕ-ਲਾਈਨ, ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਮਝਿਆ hotfix ਇੱਕ ਗੁੰਝਲਦਾਰ rollback ਨੂੰ ਹਰਾ ਸਕਦਾ ਹੈ; ਇੱਕ ਜੋਖ਼ਮ ਭਰਿਆ forward-fix ਕਦੇ ਵੀ ਇੱਕ ਸਾਫ਼ revert ਨੂੰ ਨਹੀਂ ਹਰਾਉਂਦਾ।
- **Blast radius ਅਤੇ severity।** ਇੱਕ ਪੂਰਾ outage ਸਭ ਤੋਂ ਤੇਜ਼ ਸੰਭਵ restore ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ (ਆਮ ਤੌਰ 'ਤੇ rollback); ਇੱਕ ਮਾਮੂਲੀ degradation ਇੱਕ ਧਿਆਨ ਨਾਲ ਕੀਤੇ hotfix ਦੀ ਆਗਿਆ ਦੇ ਸਕਦਾ ਹੈ।

## ਇੱਕ ਤੇਜ਼ ਫ਼ੈਸਲਾ table

| ਸਥਿਤੀ | ਚੁਣੋ |
| --- | --- |
| ਪਿਛਲਾ version ਜਾਣਿਆ-ਚੰਗਾ, ਕੋਈ migration ਨਹੀਂ | Rollback |
| ਨਾ-ਉਲਟਾਉਣਯੋਗ DB migration ship ਹੋਇਆ | Hotfix / fix-forward |
| ਕਾਰਨ ਅਣਜਾਣ, ਗੰਭੀਰ ਪ੍ਰਭਾਵ | Rollback (ਸਮਾਂ ਖ਼ਰੀਦੋ) |
| ਮਾਮੂਲੀ, ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਮਝੀ one-liner | Hotfix |
| rollback ਖ਼ੁਦ ਜੋਖ਼ਮ ਭਰਿਆ/ਅਣ-ਟੈਸਟ ਕੀਤਾ | Hotfix |

## Trade-offs ਅਤੇ ਗ਼ਲਤੀਆਂ

- **Rollback** ਸੁਰੱਖਿਅਤ ਹੈ ਪਰ ਸਿਰਫ਼ ਲੱਛਣ ਦਾ ਇਲਾਜ ਕਰਦਾ ਹੈ — ਤੁਹਾਡੇ ਉੱਤੇ ਅਜੇ ਵੀ ਇੱਕ ਅਸਲ fix ਅਤੇ ਇੱਕ postmortem ਬਕਾਇਆ ਹੈ।
- **Hotfix** ਮੂਲ ਕਾਰਨ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਦਾ ਹੈ ਪਰ ਆਮ safety net ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ; hotfixes ਵਿੱਚ bugs ਆਮ ਹਨ ਠੀਕ ਇਸ ਲਈ ਕਿਉਂਕਿ ਉਹ ਕਾਹਲੀ ਵਿੱਚ ਹੁੰਦੇ ਹਨ।
- **ਅਣ-ਟੈਸਟ ਕੀਤਾ rollback path** ਇੱਕ ਜਾਲ ਹੈ — ਜੇ ਤੁਸੀਂ ਇਸ ਦੀ ਕਦੇ ਰਿਹਰਸਲ ਨਹੀਂ ਕੀਤੀ, ਤਾਂ ਜਦੋਂ ਤੁਹਾਨੂੰ ਇਸ ਦੀ ਸਭ ਤੋਂ ਵੱਧ ਲੋੜ ਹੋਵੇ ਇਹ ਅਸਫਲ ਹੋ ਸਕਦਾ ਹੈ। ਲੋੜ ਪੈਣ ਤੋਂ ਪਹਿਲਾਂ rollbacks ਦਾ ਅਭਿਆਸ ਕਰੋ।
- ਦਬਾਅ ਹੇਠ **production ਵਿੱਚ debugging** ਤੋਂ ਸਾਵਧਾਨ ਰਹੋ; ਜੇ ਤੁਸੀਂ ਇੱਕ ਭਰੋਸੇਯੋਗ fix ਤੋਂ ਕੁਝ ਮਿੰਟਾਂ ਤੋਂ ਵੱਧ ਦੂਰ ਹੋ, ਤਾਂ roll back ਕਰੋ ਅਤੇ ਸ਼ਾਂਤੀ ਨਾਲ ਜਾਂਚ ਕਰੋ।

## ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਇਹ ਫ਼ੈਸਲਾ ਸਭ ਤੋਂ ਮਾੜੇ ਸੰਭਵ ਪਲ 'ਤੇ ਹੁੰਦਾ ਹੈ — ਸਿਸਟਮ ਡਾਊਨ, ਘੜੀ ਚੱਲ ਰਹੀ, ਹਰ ਕੋਈ ਦੇਖ ਰਿਹਾ। ਇੱਕ Tech Lead ਜਿਸ ਕੋਲ ਇਸ ਲਈ ਇੱਕ ਸਪੱਸ਼ਟ, ਰਿਹਰਸਲ ਕੀਤਾ ਨਿਯਮ ਹੈ, MTTR ਨੂੰ ਨਾਟਕੀ ਢੰਗ ਨਾਲ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ incident ਦੇ ਵਿਚਕਾਰ ਚਲਾਕ ਬਣਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਕਲਾਸਿਕ ਗ਼ਲਤੀ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜਦੋਂ ਬੋਰਿੰਗ revert ਉੱਥੇ ਹੀ ਮੌਜੂਦ ਸੀ। ਪਹਿਲਾਂ ਬਹਾਲ ਕਰੋ, ਬਾਅਦ ਵਿੱਚ ਸਿਆਣੇ ਬਣੋ।

ਸਥਿਤੀ	ਚੁਣੋ
ਪਿਛਲਾ version ਜਾਣਿਆ-ਚੰਗਾ, ਕੋਈ migration ਨਹੀਂ	Rollback
ਨਾ-ਉਲਟਾਉਣਯੋਗ DB migration ship ਹੋਇਆ	Hotfix / fix-forward
ਕਾਰਨ ਅਣਜਾਣ, ਗੰਭੀਰ ਪ੍ਰਭਾਵ	Rollback (ਸਮਾਂ ਖ਼ਰੀਦੋ)
ਮਾਮੂਲੀ, ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਮਝੀ one-liner	Hotfix
rollback ਖ਼ੁਦ ਜੋਖ਼ਮ ਭਰਿਆ/ਅਣ-ਟੈਸਟ ਕੀਤਾ	Hotfix