ਉਸੇ ਕਿਸਮ ਦੇ incident ਨੂੰ ਦੂਜੀ ਵਾਰ ਹੋਣ ਤੋਂ ਰੋਕਣ ਲਈ ਤੁਸੀਂ ਕੀ ਕਰਦੇ ਹੋ?

Question

Accepted Answer

ਇੱਕ **blameless postmortem** ਚਲਾਓ ਜੋ ਪ੍ਰਣਾਲੀਗਤ ਕਾਰਨ ਲੱਭੇ, ਫਿਰ ਇਸ ਨੂੰ **ਠੋਸ, ਮਾਲਕੀਅਤ ਵਾਲੇ, ਅਤੇ ਟਰੈਕ ਕੀਤੇ** action items ਵਿੱਚ ਬਦਲੋ — ਅਤੇ ਤਸਦੀਕ ਕਰੋ ਕਿ ਉਹ ਅਸਲ ਵਿੱਚ ship ਹੁੰਦੇ ਹਨ। ਟੀਚਾ ਇਹ ਲੱਭਣਾ ਨਹੀਂ ਕਿ ਕਿਸ ਨੂੰ ਦੋਸ਼ ਦੇਣਾ ਹੈ; ਇਹ ਸਿਸਟਮ ਨੂੰ ਬਦਲਣਾ ਹੈ ਤਾਂ ਜੋ ਅਸਫਲਤਾ ਦੀ ਉਹੀ ਸ਼੍ਰੇਣੀ ਅਸੰਭਵ ਜਾਂ ਸਵੈ-ਪਛਾਣਨਯੋਗ ਬਣ ਜਾਵੇ।

## ਮੁੱਖ loop

1. **Blameless postmortem।** ਇੱਕ ਇਮਾਨਦਾਰ timeline ਬਣਾਓ: ਕੀ ਹੋਇਆ, ਅਸੀਂ ਇਸ ਨੂੰ ਕਦੋਂ ਪਤਾ ਲਗਾਇਆ, ਅਸੀਂ ਕਿਵੇਂ ਜਵਾਬ ਦਿੱਤਾ, ਪ੍ਰਭਾਵ ਕੀ ਸੀ। ਦੋਸ਼ ਉਸ ਸੱਚ ਨੂੰ ਮਾਰ ਦਿੰਦਾ ਹੈ ਜਿਸ ਦੀ ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ।
2. **ਪ੍ਰਣਾਲੀਗਤ ਕਾਰਨ ਤੱਕ ਖੋਦੋ**, trigger ਤੱਕ ਨਹੀਂ। "ਇੱਕ engineer ਨੇ ਮਾੜੀ config push ਕੀਤੀ" ਇੱਕ trigger ਹੈ; "configs ਲਈ ਕੋਈ validation ਜਾਂ staged rollout ਨਹੀਂ ਸੀ" ਕਾਰਨ ਹੈ। **Five Whys** ਵਰਤੋ ਪਰ ਸਿਸਟਮ 'ਤੇ ਰੁਕੋ, ਕਦੇ ਕਿਸੇ ਵਿਅਕਤੀ 'ਤੇ ਨਹੀਂ।
3. **ਇੱਕ ਇਕੱਲੇ fix ਦੀ ਬਜਾਏ ਰੋਕਥਾਮ ਦੀਆਂ ਪਰਤਾਂ ਬਣਾਓ**:
   - **Prevent** — ਅਸਫਲਤਾ ਨੂੰ ਅਸੰਭਵ ਬਣਾਓ (validation, types, guardrails)।
   - **Detect** — ਇਸ ਨੂੰ ਜਲਦੀ ਫੜੋ (alerts, SLOs, synthetic checks)।
   - **Mitigate** — blast radius ਨੂੰ ਸੀਮਤ ਕਰੋ (rollback, flags, circuit breakers)।
4. **owners ਅਤੇ due dates ਸੌਂਪੋ।** ਬਿਨਾਂ owner ਦੇ ਇੱਕ action item ਇੱਕ ਇੱਛਾ ਹੈ। ਇਨ੍ਹਾਂ ਨੂੰ backlog ਵਿੱਚ ਅਸਲ ਕੰਮ ਵਾਂਗ ਟਰੈਕ ਕਰੋ।
5. **ਤਸਦੀਕ ਕਰੋ ਅਤੇ loop ਬੰਦ ਕਰੋ।** ਕੀ fix ship ਹੋਇਆ? ਕੀ ਇਹ ਮੂਲ ਨੂੰ ਫੜ ਲੈਂਦਾ? ਕੀ MTTR ਅਤੇ detection ਅਸਲ ਵਿੱਚ ਸੁਧਰੇ?

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

- **Postmortems ਜੋ documents ਪੈਦਾ ਕਰਦੇ ਹਨ, ਬਦਲਾਅ ਨਹੀਂ** — ਸਭ ਤੋਂ ਆਮ ਅਸਫਲਤਾ। ਕੋਈ follow-through ਨਾ ਹੋਣ ਦਾ ਮਤਲਬ ਹੈ ਤੁਸੀਂ ਉਸੇ incident ਨੂੰ ਮੁੜ ਮਿਲੋਗੇ।
- **ਖ਼ਾਸ ਲੱਛਣ ਨੂੰ ਜ਼ਿਆਦਾ-ਠੀਕ ਕਰਨਾ** ਜਦਕਿ bug ਦੀ ਸ਼੍ਰੇਣੀ ਖੁੱਲ੍ਹੀ ਰਹਿੰਦੀ ਹੈ। ਸਿਰਫ਼ ਇਸ ਮਿਸਾਲ ਨੂੰ ਨਹੀਂ, ਸ਼੍ਰੇਣੀ ਨੂੰ ਠੀਕ ਕਰੋ।
- ਬਿਨਾਂ tuning ਦੇ detection ਉੱਤੇ ਢੇਰ ਲਾਉਣ ਤੋਂ **alert fatigue**; ਰੌਲੇ ਵਾਲੇ alerts ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਅਗਲਾ incident ਖਿਸਕ ਜਾਂਦਾ ਹੈ।
- **Blame culture** reporting ਨੂੰ ਜ਼ਮੀਨਦੋਜ਼ ਕਰ ਦਿੰਦੀ ਹੈ; ਤੁਸੀਂ ਉਹ near-misses ਗੁਆ ਬੈਠਦੇ ਹੋ ਜੋ ਤੁਹਾਡੇ ਸਭ ਤੋਂ ਸਸਤੇ ਸਬਕ ਹਨ।
- **ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ incidents ਨੂੰ ਪ੍ਰਕਿਰਿਆ ਅਸਫਲਤਾ ਦੇ ਸੰਕੇਤ** ਵਜੋਂ ਸਮਝੋ, ਮਾੜੀ ਕਿਸਮਤ ਨਹੀਂ — ਮੁੜ-ਘਟਨਾ ਨੂੰ ਇੱਕ metric ਵਜੋਂ ਟਰੈਕ ਕਰੋ।

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

Incidents ਉਹ ਫ਼ੀਸ ਹਨ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਚੁਕਾ ਚੁੱਕੇ ਹੋ; ਇੱਕੋ ਬਰਬਾਦੀ ਉਨ੍ਹਾਂ ਤੋਂ ਨਾ ਸਿੱਖਣਾ ਹੈ। ਇੱਕ ਟੀਮ ਜੋ ਪ੍ਰਣਾਲੀਗਤ ਤੌਰ 'ਤੇ ਮੁੜ-ਘਟਨਾ ਨੂੰ ਰੋਕਦੀ ਹੈ ਹਰ ਤਿਮਾਹੀ ਵਧੇਰੇ ਭਰੋਸੇਯੋਗ ਹੁੰਦੀ ਜਾਂਦੀ ਹੈ, ਜਦਕਿ ਇੱਕ ਟੀਮ ਜੋ ਸਿਰਫ਼ firefighting ਕਰਦੀ ਹੈ ਉਹੀ outages ਨੂੰ ਹਮੇਸ਼ਾ ਮੁੜ ਜਿਉਂਦੀ ਹੈ। ਇਸ ਸਿੱਖਣ ਵਾਲੇ loop ਨੂੰ ਬਣਾਉਣਾ — ਅਤੇ ਇਸ ਵਿੱਚ ਇਮਾਨਦਾਰ ਹੋਣ ਦੀ ਸੁਰੱਖਿਆ — ਇੱਕ Tech Lead ਦੁਆਰਾ ਪਿੱਛੇ ਛੱਡੀਆਂ ਜਾ ਸਕਣ ਵਾਲੀਆਂ ਸਭ ਤੋਂ ਟਿਕਾਊ ਚੀਜ਼ਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ।