06 ਨਵੰ 2025·8 ਮਿੰਟ
ਇਨਸੀਡੈਂਟ ਟ੍ਰੈਕਿੰਗ ਅਤੇ ਪੋਸਟਮੋਰਟਮ ਲਈ ਵੈੱਬ ਐਪ ਕਿਵੇਂ ਬਣਾਈਏ
ਇਨਸੀਡੈਂਟ ਟ੍ਰੈਕਿੰਗ ਅਤੇ ਪੋਸਟਮੋਰਟਮ ਲਈ ਵੈੱਬ ਐਪ ਡਿਜ਼ਾਈਨ, ਬਣਾਉਣ ਅਤੇ ਲਾਂਚ ਕਰਨ ਦੀ ਵਰਤੋਂਯੋਗ ਯੋਜਨਾ — ਵਰਕਫਲੋ ਤੋਂ ਡਾਟਾ ਮਾਡਲਿੰਗ ਅਤੇ UX ਤੱਕ।
ਇਨਸੀਡੈਂਟ ਟ੍ਰੈਕਿੰਗ ਅਤੇ ਪੋਸਟਮੋਰਟਮ ਲਈ ਵੈੱਬ ਐਪ ਡਿਜ਼ਾਈਨ, ਬਣਾਉਣ ਅਤੇ ਲਾਂਚ ਕਰਨ ਦੀ ਵਰਤੋਂਯੋਗ ਯੋਜਨਾ — ਵਰਕਫਲੋ ਤੋਂ ਡਾਟਾ ਮਾਡਲਿੰਗ ਅਤੇ UX ਤੱਕ।
ਸਕ੍ਰੀਨ ਡਰਾਫ਼ਟ ਕਰਨ ਜਾਂ ਡੇਟਾਬੇਸ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਤਹਿ ਕਰੋ ਕਿ ਤੁਹਾਡੀ ਟੀਮ "ਇਨਸੀਡੈਂਟ ਟ੍ਰੈਕਿੰਗ ਵੈੱਬ ਐਪ" ਨਾਲ ਕੀ ਮੰਨਦੀ ਹੈ—ਅਤੇ "ਪੋਸਟਮੋਰਟਮ ਪ੍ਰਬੰਧਨ" ਦਾ ਕੀ ਉਦੇਸ਼ ਹੈ। ਟੀਮਾਂ ਅਕਸਰ ਇਕੋ ਸ਼ਬਦ ਨੂੰ ਵੱਖ-ਵੱਖ ਢੰਗ ਨਾਲ ਵਰਤਦੀਆਂ ਹਨ: ਇੱਕ ਗਰੁੱਪ ਲਈ ਇਨਸੀਡੈਂਟ ਕੋਈ ਵੀ ਗਾਹਕ-रਿਪੋਰਟ ਕੀਤੀ ਸਮੱਸਿਆ ਹੋ ਸਕਦੀ ਹੈ; ਦੂਜੇ ਲਈ ਸਿਰਫ਼ Sev-1 ਆਊਟੇਜ ਜਿਸ 'ਤੇ on-call ਏਸਕਲੇਸ਼ਨ ਹੋਇਆ ਹੋਵੇ।
ਛੋਟੀ ਪਰਿਭਾਸ਼ਾ ਲਿਖੋ ਜੋ ਜਵਾਬ ਦਿੰਦੀ ਹੋਵੇ:
ਇਹ ਪਰਿਭਾਸ਼ਾ ਤੁਹਾਡੇ ਇਨਸੀਡੈਂਟ ਰਿਸਪਾਂਸ ਵਰਕਫਲੋ ਨੂੰ ਚਲਾਏਗੀ ਅਤੇ ਐਪ ਨੂੰ ਬਹੁਤ ਕਠੋਰ (ਕੋਈ ਇਸਨੂੰ ਵਰਤਦਾ ਨਹੀਂ) ਜਾਂ ਬਹੁਤ ਲੂਜ਼ (ਡਾਟਾ ਗੈਰ-ਸੰਕਲਿਤ) ਹੋਣ ਤੋਂ ਬਚਾਏਗੀ।
ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਸੰਸਥਾ ਵਿੱਚ ਪੋਸਟਮੋਰਟਮ ਕੀ ਹੈ: ਹਰ ਇਨਸੀਡੈਂਟ ਲਈ ਇੱਕ ਹਲਕਾ ਸੰਖੇਪ, ਜਾਂ ਸਿਰਫ਼ ਉੱਚ-ਸੇਵ ਸਮੱਸਿਆਵਾਂ ਲਈ ਪੂਰਾ RCA। ਇਹ ਵੀ ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਉਦੇਸ਼ ਸਿੱਖਣਾ ਹੈ, ਅਨੁਕੂਲਤਾ ਪੂਰਾ ਕਰਨਾ ਹੈ, ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਇਨਸੀਡੈਂਟ ਘਟਾਉਣਾ ਹੈ ਜਾਂ ਇਹਨਾਂ ਤਿੰਨਾਂ ਦਾ ਮਿਲਾਪ।
ਇੱਕ ਲਾਭਦਾਇਕ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹੋ ਕਿ ਪੋਸਟਮੋਰਟਮ ਬਦਲਾਅ ਲਿਆਏਗਾ, ਤਾਂ ਤੁਹਾਡੇ ਟੂਲ ਨੂੰ ਐਕਸ਼ਨ ਆਈਟਮ ਟ੍ਰੈਕਿੰਗ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਸਿਰਫ਼ ਦਸਤਾਵੇਜ਼ ਸਟੋਰੇਜ ਨਹੀਂ।
ਜਿਆਦਾਤਰ ਟੀਮਾਂ ਇਹ ਤਰ੍ਹਾਂ ਦਾ ਐਪ ਇਸਲਈ ਬਣਾਉਂਦੀਆਂ ਹਨ ਤਾਂ ਕਿ ਕੁਝ ਮੁੜ-ਆਉਂਦੀਆਂ ਦਰਦ-ਬਿੰਦੂ ਠੀਕ ਕੀਤੀਆਂ ਜਾ ਸਕਣ:
ਇਸ ਸੂਚੀ ਨੂੰ ਘੱਟ ਰੱਖੋ। ਤੁਸੀਂ ਜੋ ਵੀ ਫੀਚਰ ਜੋੜਦੇ ਹੋ, ਉਹ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਸਮੱਸਿਆ ਨਾਲ ਮੈਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਕੁਝ ਮੈਟਰਿਕ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਆਪਣੇ ਐਪ ਦੇ ਡਾਟਾ ਮਾਡਲ ਤੋਂ ਆਪੋ-ਆਪ ਮਾਪ ਸਕੋ:
ਇਹ ਤੁਹਾਡੇ ਆਪਰੇਸ਼ਨਲ ਮੈਟਰਿਕਸ ਤੇ ਪਹਿਲੀ ਰਿਲੀਜ਼ ਲਈ "ਡone ਨਿਯਮ" ਬਣਣਗੇ।
ਉਹੀ ਐਪ ਵੱਖ-ਵੱਖ ਭੂਮਿਕਾਵਾਂ ਦੀ ਸੇਵਾ ਕਰਦੀ ਹੈ ਆਨ-ਕਾਲ ਓਪਰੇਸ਼ਨ ਵਿੱਚ:
ਜੇ ਤੁਸੀਂ ਸਭਨਾਂ ਲਈ ਇਕੱਠੇ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇਕ ਭៀੜ UI ਬਣਾਉਗੇ। ਇਸਦੀ ਬਜਾਏ, v1 ਲਈ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਯੂਜ਼ਰ ਚੁਣੋ—ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਬਾਕੀ ਹਰ ਕੋਈ ਬਾਅਦ ਵਿੱਚ ਟੇਲਰ ਕੀਤੇ ਵਿਉਜ਼, ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਪਰਮੀਸ਼ਨ ਰਾਹੀਂ ਉਹ ਸਬ ਕੁਝ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ।
ਇੱਕ ਸਾਫ਼ ਵਰਕਫਲੋ ਦੋ ਆਮ ਫੇਲ੍ਯਰ ਮੋਡਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ: ਇਨਸੀਡੈਂਟ ਜਿਹੜੇ ਰੁਕ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਕੋਈ "ਅਗਲਾ ਕੀ ਹੈ" ਨਹੀਂ ਜਾਣਦਾ, ਅਤੇ ਇਨਸੀਡੈਂਟ ਜਿਹੜੇ "ਮੁਕੰਮਲ" ਦਿਖਦੇ ਹਨ ਪਰ ਕਦੇ ਸਿੱਖਿਆ ਨਹੀਂ ਲੈਂਦੇ। ਅੰਤ ਤੋਂ ਅੰਤ ਆਪਣੀ ਲਾਈਫਸਾਈਕਲ ਨਕਸ਼ਾ ਬਣਾਓ ਅਤੇ ਫਿਰ ਹਰ ਕਦਮ ਨਾਲ ਭੂਮਿਕਾਵਾਂ ਅਤੇ ਪਰਮੀਸ਼ਨਾਂ ਜੋੜੋ।
ਜਿਆਦਾਤਰ ਟੀਮਾਂ ਇੱਕ ਸਧਾਰਣ ਆਰਕ ਦੀ ਪਾਲਣਾ ਕਰਦੀਆਂ ਹਨ: detect → triage → mitigate → resolve → learn. ਤੁਹਾਡਾ ਐਪ ਇਸਨੂੰ ਇੱਕ ਛੋਟੇ, ਪੇਸ਼ਗੀ ਕੀਤੇ ਗਏ ਕਦਮਾਂ ਨਾਲ ਦਰਸਾਵੇ, ਨਾ ਕਿ ਬੇਅੰਤ ਵਿਕਲਪਾਂ ਦੇ ਮੀਨੂ ਨਾਲ।
ਹਰ ਸਟੇਜ ਲਈ "ਡਨ" ਕੀ ਹੋਣਾ ਹੈ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਉਦਾਹਰਨ ਲਈ, ਮਿਟੀਗੇਸ਼ਨ ਦਾ ਮਤਲਬ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਗਾਹਕ ਪ੍ਰਭਾਵ ਰੁਕ ਗਿਆ, ਭਾਵੇਂ ਮੂਲ ਕਾਰਨ ਅਜੇ ਵੀ ਅਣਜਾਣ ਹੋਵੇ।
ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਸਪਸ਼ਟ ਰੱਖੋ ਤਾਂ ਕਿ ਲੋਕ ਬਿਨਾਂ ਮੀਟਿੰਗ ਦੇ ਦੀਰ ਘੜੀ ਬਿਨਾਂ ਕਾਰਵਾਈ ਕਰ ਸਕਣ:
ਤੁਹਾਡੇ UI ਨੂੰ ਵਰਤਮਾਨ ਮਾਲਕ ਨੂੰ ਦਰਸਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡਾ ਵਰਕਫਲੋ ਡੈਲੀਗੇਸ਼ਨ (ਰੀਅਸਾਈਨ, ਰਿਸਪਾਂਡਰ ਜੋੜਨਾ, ਕਮਾਂਡਰ ਰੋਟੇਸ਼ਨ) ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਲਾਜ਼ਮੀ ਸਟੇਟਸ ਅਤੇ ਮਨਜ਼ੂਰ ਹੋਏ ਟ੍ਰਾਂਜੀਸ਼ਨ ਚੁਣੋ, ਜਿਵੇਂ Investigating → Mitigated → Resolved. ਗਾਰਡਰੇਲ ਸ਼ਾਮਲ ਕਰੋ:
ਅੰਦਰੂਨੀ ਅਪਡੇਟ (ਤੇਜ਼, ਰਣਨੀਤਿਕ, ਗੰਦ ਹੋ ਸਕਦੇ) ਅਤੇ ਹਿੱਸੇਦਾਰ-ਸਮਰਥ ਅਪਡੇਟ (ਸਪਸ਼ਟ, ਸਮੇਂ-ਟਿਕੇ, ਸੰਭਾਲੇ ਹੋਏ) ਨੂੰ ਵੱਖ ਕਰੋ। ਦੋ ਅਪਡੇਟ ਸਟਰੀਮ ਬਣਾਓ ਜਿਨ੍ਹਾਂ ਦੇ ਵੱਖ-ਵੱਖ ਟੈਂਪਲੇਟ, ਵਿਖਾਈ ਅਤੇ ਮਨਜ਼ੂਰੀ ਨਿਯਮ ਹੋਣ—ਅਕਸਰ ਕਮਾਂਡਰ ਹੀ ਹਿੱਸੇਦਾਰ ਅਪਡੇਟ ਪਬਲਿਸ਼ ਕਰਦਾ ਹੈ।
ਇਕ ਚੰਗਾ ਇਨਸੀਡੈਂਟ ਟੂਲ UI ਵਿੱਚ "ਸਰਲ" ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਅਧੀਨ ਡਾਟਾ ਮਾਡਲ ਲਾਜ਼ਮੀ ਅਤੇ ਸਥਿਰ ਹੁੰਦਾ ਹੈ। ਸਕ੍ਰੀਨ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕਿਹੜੇ ਆਬਜੈਕਟ ਮੌਜੂਦ ਹਨ, ਉਹ ਕਿਵੇਂ ਜੁੜਦੇ ਹਨ, ਅਤੇ ਕਿਹੜੀ ਜਾਣਕਾਰੀ ਇਤਿਹਾਸਕ ਰੂਪ ਵਿੱਚ ਸਹੀ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ।
ਛੋਟੇ ਸੈੱਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਜਿਆਦਾਤਰ ਸੰਬੰਧ ਇੱਕ-ਤੋਂ-ਅਨੇਕ ਹਨ:
ਇਨਸੀਡੈਂਟ ਅਤੇ ਇਵੈਂਟਸ ਲਈ ਸਥਿਰ ਆਈਡੀ (UUIDs) ਵਰਤੋਂ। ਮਨੁੱਖਾਂ ਲਈ ਇੱਕ ਦੋਸਤਾਨਾ ਕੀ ਵਰਗਾ INC-2025-0042 ਪੈਦਾ ਕਰੋ ਜੋ ਤ੍ਰਤੀਬ ਤੋਂ ਬਣ ਸਕਦਾ ਹੈ।
ਇਨ੍ਹਾਂ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਮਾਡਲ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਫਿਲਟਰ, ਖੋਜ ਅਤੇ ਰਿਪੋਰਟ ਕਰ ਸਕੋ:
ਇਨਸੀਡੈਂਟ ਡਾਟਾ ਸੰਵੇਦਨਸ਼ੀਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਅਕਸਰ ਬਾਅਦ ਵਿੱਚ ਸਮੀਖਿਆ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸੰਪਾਦਨ ਨੂੰ ਡਾਟਾ ਵਜੋਂ ਤਾਂਲੋ—ਓਵਰਰਾਈਟ ਨਾ ਕਰੋ:\n\n- ਹਰ ਰਿਕਾਰਡ 'ਤੇ created_at/created_by ਸਟੋਰ ਕਰੋ।\n- ਸੋਧਾਂ ਲਈ ਇੱਕ ਆਡੀਟ ਲੌਗ ਰੱਖੋ (ਫੀਲਡ ਬਦਲਾਅ + ਕਰਮਕਾਰੀ + ਟਾਈਮਸਟੈਂਪ), ਜਾਂ ਮੁਹੱਤਵਪੂਰਨ ਦਸਤਾਵੇਜ਼ਾਂ (postmortem, updates) ਦੇ ਵਰਜਨ ਰੱਖੋ।\n- ਰੀਟੇਨਸ਼ਨ ਪਹਿਲਾਂ ਹੀ ਫੈਸਲਾ ਕਰੋ (ਉਦਾਹਰਨ, ਇਨਸੀਡੈਂਟ ਹਰ ਵੇਲੇ ਰੱਖੋ, ਚੈਟ ਟਰਾਂਸਕ੍ਰਿਪਟ N ਦਿਨ ਬਾਅਦ ਮਿਟਾਓ)।
ਇਹ ਬਣਤਰ ਬਾਅਦ ਵਿੱਚ ਖੋਜ, ਮੈਟਰਿਕਸ ਅਤੇ ਪਰਮੀਸ਼ਨਜ਼ ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਬਿਨਾਂ ਰੀਵਰਕ ਦੇ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ।
ਜਦ ਕੁੱਝ ਖਰਾਬ ਹੁੰਦਾ ਹੈ, ਐਪ ਦਾ ਕੰਮ ਟਾਈਪਿੰਗ ਘਟਾਉਣਾ ਅਤੇ ਸਪਸ਼ਟਤਾ ਵਧਾਉਣਾ ਹੈ। ਇਹ ਭਾਗ "ਲਿਖਣ ਦਾ ਰਾਸ্তা" ਕਵਰ ਕਰਦਾ ਹੈ: ਲੋਕ ਕਿਵੇਂ ਇੱਕ ਇਨਸੀਡੈਂਟ ਬਣਾਉਂਦੇ ਹਨ, ਇਸਨੂੰ ਅਪਡੇਟ ਰੱਖਦੇ ਹਨ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਕੀ ਹੋਇਆ ਉਸਦੀ ਪੁਨਰ-ਰਚਨਾ ਕਰਦੇ ਹਨ।
ਇਨਟੇਕ ਫਾਰਮ ਇਤਨਾ ਛੋਟਾ ਰੱਖੋ ਕਿ ਤੁਸੀਂ ਟਰਬਲਸ਼ੂਟਿੰਗ ਦੌਰਾਨ ਵੀ ਮੁਕੰਮਲ ਕਰ ਸਕੋ। ਇੱਕ ਚੰਗੇ ਡਿਫਾਲਟ ਲਾਜ਼ਮੀ ਫੀਲਡਾਂ ਦਾ ਸੈੱਟ ਹੈ:
ਬਾਕੀ ਸਭ ਕ੍ਰੀਏਸ਼ਨ ਸਮੇਂ ਵਿਕਲਪਿਕ ਹੋਣ ਚਾਹੀਦਾ ਹੈ (ਪ੍ਰਭਾਵ, ਗਾਹਕ ਟਿਕਟ ਲਿੰਕ, ਸ਼ੱਕੀ ਕਾਰਨ). ਸਮਝਦਾਰ ਡਿਫਾਲਟ ਵਰਤੋਂ: start time ਨੂੰ "ਹੁਣ" 'ਤੇ ਸੈੱਟ ਕਰੋ, ਯੂਜ਼ਰ ਦੀ on-call team ਪ੍ਰੀ-ਸਿਲੈਕਟ ਕਰੋ, ਅਤੇ ਇੱਕ ਇਕ-ਟੈਪ "Create & open incident room" ਕਾਰਵਾਈ ਦਿਓ।
ਤੁਹਾਡੀ ਅਪਡੇਟ UI ਨੂੰ ਦੁਹਰਾਉਣਯੋਗ, ਛੋਟੇ ਸੋଧਾਂ ਲਈ ਅਨੁਕੂਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਕੰਪੈਕਟ ਅਪਡੇਟ ਪੈਨਲ ਦਿਓ ਜਿਸ ਵਿੱਚ:
ਅਪਡੇਟਾਂ ਨੂੰ ਐਪੇਂਡ-ਫ੍ਰੈਂਡਲੀ ਬਣਾਓ: ਹਰ ਅਪਡੇਟ ਇੱਕ ਟਾਈਮਸਟੈਂਪ ਕੀਤੀ ਐਂਟਰੀ ਬਣ ਜਾਂਦੀ ਹੈ, ਪਿਛਲੇ ਟੈਕਸਟ ਦੇ ਓਵਰਰਾਈਟ ਦੀ ਨਹੀਂ।
ਇੱਕ ਟਾਈਮਲਾਈਨ ਬਣਾਓ ਜੋ ਮਿਲਾਵਟ ਕਰਦੀ ਹੋਵੇ:
ਇਹ ਇਕ ਭਰੋਸੇਯੋਗ ਕਹਾਣੀ ਬਣਾਉਂਦਾ ਹੈ ਬਿਨਾਂ ਲੋਕਾਂ ਨੂੰ ਹਰ ਕਲਿੱਕ ਲੌਗ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਕੀਤਾ।
ਆਊਟੇਜ ਦੌਰਾਨ ਬਹੁਤ ਸਾਰੇ ਅਪਡੇਟ ਫੋਨ ਤੋਂ ਹੁੰਦੇ ਹਨ। ਇੱਕ ਤੇਜ਼, ਘੱਟ-ਘਰਾਫਾ ਸਕ੍ਰੀਨ ਤਰਜੀਹ ਦਿਓ: ਵੱਡੇ ਟੱਚ ਟਾਰਗੇਟ, ਇੱਕ ਸਕ੍ਰੋਲਿੰਗ ਪੰਨਾ, ਆਫਲਾਈਨ-ਫਰੈਂਡਲੀ ਡਰਾਫਟ, ਅਤੇ ਇਕ-ਟੈਪ ਕਾਰਵਾਈਆਂ ਜਿਵੇਂ "Post update" ਅਤੇ "Copy incident link"।
Severity ਇਨਸੀਡੈਂਟ ਰਿਸਪਾਂਸ ਦਾ "ਸਪੀਡ ਡਾਇਲ" ਹੈ: ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਲੋਕ ਕਿਸ ਤਰ੍ਹਾਂ ਜ਼ਰੂਰੀ ਤੌਰ ਤੇ ਕੰਮ ਕਰਨ, ਕਿੰਨੀ ਵਿਆਪਕ ਤੌਰ ਤੇ ਸੁਚਿਤ ਕਰਨ ਅਤੇ ਕਿਹੜੀਆਂ ਤਰਜੀحات ਸਵੀਕਾਰਯੋਗ ਹਨ।
ਧੁੰਦਲੇ ਲੇਬਲਾਂ ਜਿਵੇਂ "ਹਾਈ/ਮੀਡੀਅਮ/ਲੋ" ਤੋਂ ਬਚੋ। ਹਰ severity ਪੱਧਰ ਨੂੰ ਸਪਸ਼ਟ ਓਪਰੇਸ਼ਨਲ ਉਮੀਦਾਂ ਨਾਲ ਜੋੜੋ—ਖਾਸ ਕਰਕੇ ਜਵਾਬ ਦਾ ਸਮਾਂ ਅਤੇ ਸੰਚਾਰ ਕੈਡੈਂਸ।
ਉਦਾਹਰਨ:
ਜਿੱਥੇ ਵੀ severity ਚੁਣੀ ਜਾ ਰਹੀ ਹੋਵੇ UI ਵਿੱਚ ਇਹ ਨੀਤੀਆਂ ਦਿੱਖਾਓ ਤਾਂ ਜੋ ਰਿਸਪਾਂਡਰਾਂ ਨੂੰ ਬਾਹਰੀ ਡੌਕਸ ਵਿੱਚ ਤਲਾਸ਼ ਨਾ ਕਰਨੀ ਪਏ।
ਚੈੱਕਲਿਸਟ ਲੋਕਾਂ ਦੀ ਮਾਨਸਿਕ ਭਾਰ ਘਟਾਉਂਦੇ ਹਨ ਜਦ ਉਹ ਤਣਾਅ ਵਿੱਚ ਹੁੰਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਛੋਟਾ, ਕਾਰਵਾਈਯੋਗ ਅਤੇ ਭੂਮਿਕਾ-ਨਿਰਧਾਰਿਤ ਰੱਖੋ।
ਇੱਕ ਉਪਯੋਗੀ ਪੈਟਰਨ ਕੁਝ ਵਿਭਾਗਾਂ ਦਾ ਹੁੰਦਾ ਹੈ:
ਚੈੱਕਲਿਸਟ ਆਈਟਮਾਂ ਨੂੰ ਟਾਈਮਸਟੈਂਪ ਅਤੇ ਅਟਰੀਬਿਊਟ ਕੀਤਾ ਜਾਵੇ ਤਾਂ ਜੋ ਉਹ ਇਨਸੀਡੈਂਟ ਰਿਕਾਰਡ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਣ।
ਇਨਸੀਡੈਂਟ ਕਦੇ ਵੀ ਇਕ ਟੂਲ ਵਿੱਚ ਨਹੀਂ ਰਹਿੰਦੇ। ਤੁਹਾਡਾ ਐਪ ਰਿਸਪਾਂਡਰਾਂ ਨੂੰ ਇਹ ਆਸਾਨੀ ਦੇਵੇ ਕਿ ਉਹ ਲਿੰਕ ਜੋੜ ਸਕਣ:
"ਟਾਈਪਡ" ਲਿੰਕ ਪਸੰਦ ਕਰੋ (ਉਦਾਹਰਨ, Runbook, Ticket) ਤਾਂ ਕਿ ਉਹ ਬਾਅਦ ਵਿੱਚ ਫਿਲਟਰ ਕੀਤੇ ਜਾ ਸਕਣ।
ਜੇ ਤੁਹਾਡੀ ਸੰਸਥਾ ਰਿਲਾਇਬਿਲਟੀ ਟਾਰਗਟ ਟ੍ਰੈਕ ਕਰਦੀ ਹੈ, ਤਾਂ ਹਲਕਾ ਫੀਲਡ ਜਿਵੇਂ SLO affected (yes/no), ਅੰਦਾਜ਼ਾ error budget burn, ਅਤੇ ਗਾਹਕ SLA ਰਿਸਕ ਸ਼ਾਮਲ ਕਰੋ। ਉਨ੍ਹਾਂ ਨੂੰ ਵਿਕਲਪਿਕ ਰੱਖੋ—ਪਰ ਇਨਸੀਡੈਂਟ ਦੌਰਾਨ ਜਾਂ ਬਾਅਦ ਜਦ ਵੇਰਵੇ ਤਾਜ਼ੇ ਹੋਣ ਤਾਂ ਅਸਾਨੀ ਨਾਲ ਭਰਨਾ ਹੋਵੇ।
ਇੱਕ ਚੰਗਾ ਪੋਸਟਮੋਰਟਮ ਸ਼ੁਰੂ ਕਰਨ ਵਿੱਚ ਆਸਾਨ, ਭੁੱਲਣਾ ਮੁਸ਼ਕਿਲ ਅਤੇ ਟੀਮਾਂ ਵਿੱਚ ਲਗਾਤਾਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਭ ਤੋਂ ਸਧਾਰਣ ਰਸਤਾ ਇਹ ਹੈ ਕਿ ਇੱਕ ਡਿਫ਼ਾਲਟ ਟੈਂਪਲੇਟ ਪ੍ਰਦਾਨ ਕੀਤਾ ਜਾਵੇ (ਕੋਮਲ ਲਾਜ਼ਮੀ ਫੀਲਡਾਂ ਨਾਲ) ਅਤੇ ਇਨਸੀਡੈਂਟ ਰਿਕਾਰਡ ਤੋਂ ਆਟੋ-ਭਰ ਦਿੱਤਾ ਜਾਵੇ ਤਾਂ ਲੋਕ ਸਮਾਂ ਸੋਚਣ ਵਿੱਚ ਲਗਾਉਣ—ਦੁਹਰਾਉਣ ਵਿੱਚ ਨਹੀਂ।
ਤੁਹਾਡਾ ਬਿਲਟ-ਇਨ ਟੈਂਪਲੇਟ ਸੰਰਚਨਾ ਅਤੇ ਲਚੀਲਾਪਣ ਵਿਚ ਸੰਤੁਲਨ ਰੱਖੇ:
ਜੇ ਤੁਸੀਂ ਜਲਦੀ ਪਬਲਿਸ਼ਿੰਗ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਸ਼ੁਰੂਆਤੀ ਦੌਰ ਵਿੱਚ "Root cause" ਨੂੰ ਵਿਕਲਪਿਕ ਰੱਖੋ—but ਅंतਿਮ ਮਨਜ਼ੂਰੀ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਲਾਜ਼ਮੀ ਕਰੋ।
ਪੋਸਟਮੋਰਟਮ ਇੱਕ ਵੱਖਰਾ ਦਸਤਾਵੇਜ਼ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਜੋ ਅੰਦਰ-ਬਾਹਰ ਤੈਰ ਰਿਹਾ ਹੋਵੇ। ਜਦ ਇੱਕ ਪੋਸਟਮੋਰਟਮ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਜੁੜੇ:
ਇਹਨਾਂ ਨੂੰ ਪੋਸਟਮੋਰਟਮ ਸੈਕਸ਼ਨਾਂ ਨੂੰ ਪ੍ਰੀ-ਫਿਲ ਕਰਨ ਲਈ ਵਰਤੋਂ। ਉਦਾਹਰਨ ਵਜੋਂ, "Impact" ਬਲਾਕ ਇਨਸੀਡੈਂਟ ਦੇ ਸ਼ੁਰੂ/ਅੰਤ ਸਮਿਆਂ ਅਤੇ ਵਰਤਮਾਨ ਸਮੀਕਰਨ ਨਾਲ ਸ਼ੁਰੂ ਹੋ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ "What we did" ਟਾਈਮਲਾਈਨ ਐਂਟਰੀਜ਼ ਤੋਂ ਖਿੱਚਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਇਕ ਹਲਕਾ ਵਰਕਫਲੋ ਜੋ ਪੋਸਟਮੋਰਟਮਾਂ ਨੂੰ ਫੱਸਣ ਤੋਂ ਰੋਕੇ ਸ਼ਾਮਲ ਕਰੋ:
ਹਰ ਕਦਮ 'ਤੇ ਫੈਸਲਾ ਨੋਟਸ ਕੈਪਚਰ ਕਰੋ: ਕੀ ਬਦਲਿਆ, ਕਿਉਂ ਬਦਲਿਆ, ਅਤੇ ਕਿਸ ਨੇ ਮਨਜ਼ੂਰ ਕੀਤਾ। ਇਹ "ਚੁੱਪ ਚੇਤਾਵਨੀ ਸੋਧਾਂ" ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ ਅਤੇ ਭਵਿੱਖ ਦੀ ਸਮੀਖਿਆ ਲਈ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ UI ਸਧਾਰਾ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਸਮੀਖਿਆ ਨੂੰ ਕਮੈਂਟਸ ਵਾਂਗTreat ਕਰੋ ਜਿਨ੍ਹਾਂ ਦੇ ਵਿਸ਼ੇਸ਼ ਨਤੀਜੇ (Approve / Request changes) ਹੋਣ ਅਤੇ ਆਖਰੀ ਮਨਜ਼ੂਰੀ ਨੂੰ ਅਪਰਿਵਰਤਨੀ ਰਿਕਾਰਡ ਵਜੋਂ ਸਟੋਰ ਕਰੋ।
ਟîmਾਂ ਲਈ ਜੋ ਇਸਦੀ ਲੋੜ ਹੈ, "Published" ਨੂੰ ਆਪਣੇ ਸਥਿਤੀ ਅਪਡੇਟ ਵਰਕਫਲੋ ਨਾਲ ਜੋੜੋ (ਦੇਖੋ /blog/integrations-status-updates) ਬਿਨਾ ਸਮੱਗਰੀ ਨੂੰ ਹੱਥੋਂ-ਹੱਥ ਕਾਪੀ ਕੀਤੇ।
ਪੋਸਟਮੋਰਟਮ ਸਿਰਫ਼ ਦਸਤਾਵੇਜ਼ ਰੱਖ ਕੇ ਭਵਿੱਖ ਦੇ ਇਨਸੀਡੈਂਟ ਘਟਾਉਣ ਵਿੱਚ ਸਹਾਇਕ ਨਹੀਂ ਹੁੰਦੇ—ਫਾਲੋ-ਅਪ ਕੰਮ ਹਕੀਕਤ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਐਕਸ਼ਨ ਆਈਟਮਾਂ ਨੂੰ ਤੁਹਾਡੇ ਐਪ ਵਿੱਚ ਪਹਿਲ-ਸ਼੍ਰੇਣੀ ਆਬਜੈਕਟਾਂ ਵਜੋਂ ਸਮਝੋ—ਨਾ ਕਿ ਦਸਤਾਵੇਜ਼ ਦੇ ਅੰਤ ਵਿੱਚ ਇੱਕ ਪੈਰਾ।
ਹਰ ਐਕਸ਼ਨ ਆਈਟਮ ਕੋਨਸਿਸਟੈਂਟ ਫੀਲਡਾਂ ਨਾਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਕਿ ਇਹ ਟਰੈਕ ਅਤੇ ਮਾਪਿਆ ਜਾ ਸਕੇ:\n\n- Owner (ਇੱਕ ਜ਼ਿੰਮੇਵਾਰ ਵਿਅਕਤੀ)\n- Due date (ਅਤੇ ਵਿਕਲਪਕ "start not before")\n- Priority (ਉਦਾਹਰਨ: P0–P3 ਜਾਂ High/Medium/Low)\n- Status (Open, In progress, Blocked, Done, Won’t do)\n- Verification criteria (ਕਿਵੇਂ ਪਤਾ ਲੱਗੇਗਾ ਕਿ ਫਿਕਸ ਕੰਮ ਕਰ ਗਿਆ)
ਛੋਟੇ ਪਰ ਉਪਯੋਗੀ ਮੈਟਾਡੇਟਾ ਜੋੜੋ: tags (ਜਿਵੇਂ "monitoring", "docs"), component/service, ਅਤੇ "created from" (incident ID ਅਤੇ postmortem ID)।
ਐਕਸ਼ਨ ਆਈਟਮਾਂ ਨੂੰ ਇੱਕ ਹੀ ਪੋਸਟਮੋਰਟਮ ਪੇਜ ਵਿੱਚ ਫੜ ਨਾ ਰੱਖੋ। ਇਹ ਦਿਓ:
ਇਹ ਫਾਲੋ-ਅਪ ਨੂੰ ਇਕ ਆਪਰੇਸ਼ਨਲ ਕਿਊ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ ਨਾ ਕਿ ਫੈਲੇ ਹੋਏ ਨੋਟਸ ਵਿੱਚ।
ਕੁਝ ਟਾਸਕ ਦੁਹਰਾਏ ਜਾਂਦੇ ਹਨ (ਤਰਮਾਤਮਕ game days, ਰਨਬੁਕ ਰਿਵਿਊਜ਼). ਇੱਕ ਰਿਕਰਿੰਗ ਟੈਂਪਲੇਟ ਸਹਾਇਤਾ ਜਨਕੋ ਜੋ ਨਿਰਧਾਰਿਤ ਸਮਾਂ-ਅਨੁਸਾਰ ਨਵੇਂ ਆਈਟਮ ਬਣਾਉਂਦਾ ਹੈ, ਪਰ ਹਰ ਇਕ ਘਟਨਾ ਅਲੱਗ-ਅਲੱਗ ਟ੍ਰੈਕਿੰਗ ਯੋਗ ਰਹਿੰਦੀ ਹੈ।
ਜੇ ਟੀਮ ਪਹਿਲਾਂ ਹੀ ਕਿਸੇ ਹੋਰ ਟ੍ਰੈਕਰ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੀ ਹੈ, ਤਾਂ ਇੱਕ ਐਕਸ਼ਨ ਆਈਟਮ ਵਿੱਚ ਇਕ ਬਾਹਰੀ ਹਵਾਲਾ ਲਿੰਕ ਅਤੇ ਬਾਹਰੀ ID ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿਓ, ਜਦਕਿ ਤੁਹਾਡਾ ਐਪ ਇਨਸੀਡੈਂਟ ਲਿੰਕੇਜ ਅਤੇ ਵੇਰੀਫਿਕੇਸ਼ਨ ਲਈ ਸਰੋਤ ਬਣਿਆ ਰਹੇ।
ਹਲਕੇ ਨਰੜ: ਮਾਲਕਾਂ ਨੂੰ ਡਿਊ ਡੇਟ ਨੇੜੇ ਨੋਟੀਫਾਈ ਕਰੋ, ਆਦਤਕ ਠਹਿਰੇ ਹੋਏ ਆਈਟਮਾਂ ਨੂੰ ਟੀਮ ਲੀਡ ਨੂੰ ਫਲੈਗ ਕਰੋ, ਅਤੇ ਰਿਪੋਰਟਾਂ ਵਿੱਚ ਚਿਰ-ਆਓ ਵਾਢੇ ਪੈਟਰਨ ਦਿਖਾਓ। ਨਿਯਮਾਂ ਨੂੰ ਬਦਲਣਯੋਗ ਰੱਖੋ ਤਾਂ ਕਿ ਟੀਮਾਂ ਆਪਣੀ ਆਨ-ਕਾਲ ਓਪਰੇਸ਼ਨ ਅਤੇ ਕੰਮ ਦੇ ਹਕੀਕਤ ਨਾਲ ਮੇਲ ਖਾ ਸਕਨ।
ਇਨਸੀਡੈਂਟ ਅਤੇ ਪੋਸਟਮੋਰਟਮ ਅਕਸਰ ਸੰਵੇਦਨਸ਼ੀਲ ਵੇਰਵੇ ਰੱਖਦੇ ਹਨ—ਗਾਹਕ ਪਹਿਚਾਣ, ਅੰਦਰੂਨੀ IP, ਸੁਰੱਖਿਆ ਖੋਜ, ਜਾਂ ਵੈਂਡਰ ਮੁੱਦੇ। ਸਪਸ਼ਟ ਪਹੁੰਚ ਨਿਯਮ ਟੂਲ ਨੂੰ ਸਹਿਯੋਗੀ ਰੱਖਦੇ ਹਨ ਬਿਨਾਂ ਇਸਨੂੰ ਡਾਟਾ ਲੀਕ ਬਣਨ ਦੇ।
ਛੋਟੇ, ਸਮਝਣਯੋਗ ਰੋਲ ਸੈੱਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਕਈ ਟੀਮਾਂ ਹਨ, ਤਾਂ ਰੋਲਾਂ ਨੂੰ ਸੇਵਾ/ਟੀਮ ਮੁਤਾਬਕ ਸਕੋਪ ਕਰੋ (ਉਦਾਹਰਨ, “Payments Editors”) ਬਦਲੇ ਵਿੱਚ ਫੈਲੇ ਹੋਏ ਗਲੋਬਲ ਐਕਸੈਸ ਦੇਣ ਦੇ।
ਆਦਤਾਂ ਪਹਿਲਾਂ ਤੋਂ ਕਲੈਸੀਫਾਈ ਕਰੋ ਤਾਂ ਕਿ ਲੋਕ ਆਦਤਾਂ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਤਹਿ ਫੈਸਲਾ ਕਰ ਸਕਣ:
ਇੱਕ ਵਿਆਹਦਾਰ ਪੈਟਰਨ ਹੈ ਕਿ ਸੈਕਸ਼ਨਾਂ ਨੂੰ Internal ਜਾਂ Shareable ਮਾਰਕ ਕਰੋ ਅਤੇ ਨਿਰਯਾਤਾਂ ਅਤੇ ਸਥਿਤੀ ਪੰਨਿਆਂ ਵਿੱਚ ਇਸਨੂੰ ਲਾਗੂ ਕਰੋ। ਸੁਰੱਖਿਆ ਘਟਨਾਵਾਂ ਲਈ ਇੱਕ ਵੱਖਰਾ ਇਨਸੀਡੈਂਟ ਕਿਸਮ ਹੋ ਸਕਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਕਠੋਰ ਡਿਫ਼ਾਲਟ ਹੋਣ।
ਇਨਸੀਡੈਂਟ ਅਤੇ ਪੋਸਟਮੋਰਟਮ ਵਿੱਚ ਹਰ ਸੋਧ ਲਈ ਦਰਜ ਕਰੋ: ਕਿਸਨੇ ਸੋਧ ਕੀਤੀ, ਕੀ ਸੋਧਿਆ, ਅਤੇ ਕਦੋਂ। ਸੇਵਾਵਾਂ, ਸਮੀਕਰਨ, ਪ੍ਰਭਾਵ ਅਤੇ "ਅੰਤਿਮ" ਮਨਜ਼ੂਰੀਆਂ ਦੀਆਂ ਸੋਧਾਂ ਸ਼ਾਮਲ ਕਰੋ। ਆਡੀਟ ਲੌਗ ਖੋਜਯੋਗ ਅਤੇ ਅੰਪੇਢ ਰੱਖੋ (non-editable)।
ਬਾਕਸ ਤੋਂ ਬਾਹਰ ਮਜ਼ਬੂਤ ਪ੍ਰਮਾਣੀਕਰਨ ਸੱਪੋਰਟ ਕਰੋ: ਈਮੇਲ + MFA ਜਾਂ ਮੈਜਿਕ ਲਿੰਕ, ਅਤੇ ਜੇ ਉਮੀਦ ਹੋਵੇ ਤਾਂ SSO (SAML/OIDC) ਸ਼ਾਮਲ ਕਰੋ। ਛੋਟੇ-ਮਿਆਦੀ ਸੈਸ਼ਨ, ਸੁਰੱਖਿਅਤ ਕੁਕੀਜ਼, CSRF ਸੁਰੱਖਿਆ, ਅਤੇ ਰੋਲ ਬਦਲਣ ਤੇ ਸੈਸ਼ਨ ਰਿਵੋਕੇਸ਼ਨ ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਵਰਤੋਂ। ਵਧੇਰੇ ਰੋਲਆਊਟ ਵਿਚਾਰਾਂ ਲਈ ਦੇਖੋ /blog/testing-rollout-continuous-improvement।
ਜਦ ਇੱਕ ਇਨਸੀਡੈਂਟ ਚਾਲੂ ਹੈ, ਲੋਕ ਸਕੈਨ ਕਰਦੇ ਹਨ—ਪੂਰਾ ਪੜ੍ਹਦੇ ਨਹੀਂ। ਤੁਹਾਡੀ UX ਨੂੰ ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ ਵਰਤਮਾਨ ਸਥਿਤੀ ਸਪਸ਼ਟ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਜਦਕਿ ਰਿਸਪਾਂਡਰਾਂ ਨੂੰ ਵਿਸਥਾਰ ਵਿੱਚ ਡ੍ਰਿਲ ਕਰਨ ਦੀ ਆਸਾਨੀ ਹੋਵੇ।
ਤਿੰਨ ਸਕ੍ਰੀਨਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਵੱਧਤਰ ਵਰਕਫਲੋ ਕਵਰ ਕਰਦੀਆਂ ਹਨ:
ਇੱਕ ਸਰਲ ਨਿਯਮ: ਇਨਸੀਡੈਂਟ ਡੀਟੇਲ ਪੇਜ਼ 'ਤੇ ਸਿਖਰ 'ਤੇ ਇਹ ਸੰਬੋਧਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ "ਹੁਣ ਕੀ ਹੋ ਰਿਹਾ ਹੈ?" ਅਤੇ ਹੇਠਾਂ "ਅਸੀਂ ਇੱਥੇ ਕਿਵੇਂ ਪਹੁੰਚੇ?"।
ਇਨਸੀਡੈਂਟ ਤੇਜ਼ੀ ਨਾਲ ਇਕੱਤਰ ਹੋ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਖੋਜ ਤੇਜ਼ ਅਤੇ ਦਰਦ-ਰਹਿਤ ਬਣਾਓ:
My open incidents ਜਾਂ Sev-1 this week ਵਰਗੀਆਂ ਸੇਵ ਕੀਤੀਆਂ ਵਿਊਜ਼ ਦਿਓ ਤਾਂ ਕਿ on-call engineers ਹਰ ਸ਼ਿਫਟ ਦੌਰਾਨ ਫਿਲਟਰ ਮੁੜ ਬਣਾਉਣ ਤੋਂ ਬਚ ਸਕਣ।
ਐਪ ਵਿੱਚ ਇਕੋ ਹੀ, ਰੰਗ-ਸੁਰੱਖਿਅਤ ਬੈਜ ਵਰਤੋਂ (ਤੇਨਸ਼ਨ ਵਾਲੇ ਛੋਟੇ ਰੰਗਾਂ ਤੋਂ ਬਚੋ). ਸਾਰੇ ਸਥਾਨਾਂ 'ਤੇ ਇਕੋ ਹੀ ਸਥਿਤੀ ਸ਼ਬਦਾਵਲੀ ਰੱਖੋ: ਲਿਸਟ, ਡੀਟੇਲ ਹੈਡਰ, ਅਤੇ ਟਾਈਮਲਾਈਨ ਇਵੈਂਟਸ।
ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ, ਰਿਸਪਾਂਡਰਾਂ ਨੂੰ ਦਿਖਾਈ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ:
ਸਕੈਨੇਬਲਿਟੀ ਨੂੰ ਤਰਜੀਹ ਦਿਓ:\n\n- ਵੱਡੇ ਟਾਈਮਸਟੈਂਪ ਅਤੇ ਸਪਸ਼ਟ ਸੈਕਸ਼ਨ ਹੈਡਰ\n- ਸਕ੍ਰੋਲ ਕਰਨ ਸਮੇਂ ਚਿਪਕਣ ਵਾਲਾ ਇਨਸੀਡੈਂਟ ਹੈਡਰ\n- ਸ਼ੋਰ ਵਾਲੇ ਡਾਟਾ (ਰਾਅ ਅਲਾਰਟਸ, ਲੰਬੇ ਲੌਗ) ਲਈ ਕੋਲੈਪਸਿਬਲ ਸੈਕਸ਼ਨ\n- ਕੀਬੋਰਡ-ਮਿੱਤਰ ਨੈਵੀਗੇਸ਼ਨ (/, n/p ਅਗਲਾ/ਪਿਛਲਾ ਇਨਸੀਡੈਂਟ)
ਸਭ ਤੋਂ ਖਰਾਬ ਪਲ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ: ਜੇ ਕੋਈ ਨੀਂਦ-ਰਹਿਤ ਹੈ ਅਤੇ ਆਪਣੇ ਫੋਨ ਤੋਂ ਪੇਜਿੰਗ ਕਰ ਰਿਹਾ ਹੈ, UI ਫਿਰ ਵੀ ਉਨ੍ਹਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਹੀ ਕਾਰਵਾਈ ਵੱਲ ਰਹਿਨੁਮਾਈ ਕਰੇ।
ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਉਸ ਚੀਜ਼ ਨੂੰ ਬਣਾ ਦਿੰਦੇ ਹਨ ਜੋ ਇਨਸੀਡੈਂਟ ਟ੍ਰੈਕਰ ਨੂੰ "ਨੋਟਸ ਰੱਖਣ ਦੀ ਥਾਂ" ਤੋਂ ਉਹ ਸਿਸਟਮ ਬਣਾਉਂਦੇ ਹਨ ਜਿਸ 'ਤੇ ਤੁਹਾਡੀ ਟੀਮ ਅਸਲ ਵਿੱਚ ਇਨਸੀਡੈਂਟ ਚਲਾਉਂਦੀ ਹੈ। ਪਹਿਲਾਂ ਉਹ ਸਿਸਟਮਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ ਜਿਨ੍ਹਾਂ ਨਾਲ ਤੁਸੀਂ ਜੁੜਨਾ ਲਾਜ਼ਮੀ ਸਮਝਦੇ ਹੋ: monitoring/observability (PagerDuty/Opsgenie, Datadog, CloudWatch), chat (Slack/Teams), email, ticketing (Jira/ServiceNow), ਅਤੇ ਇੱਕ status page।
ਜਿਆਦਾਤਰ ਟੀਮਾਂ ਇਕ ਮਿਕਸ ਨਾਲ ਖਤਮ ਹੁੰਦੀਆਂ ਹਨ:
ਅਲਰਟ ਅਸ਼ਾਂਤ ਹੁੰਦੇ, ਰੀਟ੍ਰਾਈ ਹੁੰਦੇ ਅਤੇ ਅਕਸਰ ਕ੍ਰਮ ਬਦਲ ਜਾਂਦਾ ਹੈ। ਹਰ ਪ੍ਰੋਵਾਇਡਰ ਇਵੈਂਟ ਲਈ ਇੱਕ ਸਥਿਰ idempotency key ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ (ਉਦਾਹਰਨ: provider + alert_id + occurrence_id), ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਯੂਨੀਕ ਸੰਕਲਪ ਨਾਲ ਸਟੋਰ ਕਰੋ। ਡੈਡਪਲੀਕੇਸ਼ਨ ਲਈ ਨੀਤੀਆਂ ਫੈਸਲਾ ਕਰੋ ਜਿਵੇਂ "ਉਹੀ ਸੇਵਾ + ਉਹੀ ਸਿਗਨੇਚਰ 15 ਮਿੰਟ ਵਿੱਚ" ਮੌਜੂਦਾ ਇਨਸੀਡੈਂਟ ਵਿੱਚ ਜੋੜਿਆ ਜਾਵੇ ਨਾ ਕਿ ਨਵਾਂ ਬਣਾਇਆ ਜਾਵੇ।
ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਤੁਹਾਡਾ ਐਪ ਕੀ ਜ਼ਿੰਮੇਵਾਰੀ ਲੈਂਦਾ ਹੈ ਅਤੇ ਕੀ ਸੋਰਸ ਟੂਲ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ:\n\n- ਤੁਹਾਡਾ ਐਪ ਇਨਸੀਡੈਂਟ ਰਿਕਾਰਡ, ਟਾਈਮਲਾਈਨ, ਭੂਮਿਕਾਵਾਂ, ਅਤੇ ਪੋਸਟਮੋਰਟਮ ਦਾ ਮਾਲਕ ਹੋ ਸਕਦਾ ਹੈ।\n- ਟਿਕਟ ਸਿਸਟਮ ਕੰਮ ਦੀ ਕਾਰਵਾਈ ਅਤੇ ਮਨਜ਼ੂਰੀਆਂ ਦਾ ਮਾਲਕ ਹੋ ਸਕਦਾ ਹੈ।
ਜਦ ਇੱਕ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਫੇਲ ਹੋਵੇ, gracefully degrade ਕਰੋ: retries ਕਿਊ ਕਰੋ, ਇਨਸੀਡੈਂਟ 'ਤੇ ਇੱਕ ਚੇਤਾਵਨੀ ਦਿਖਾਓ ("Slack posting delayed"), ਅਤੇ ਸਦਾਂ ਆਪਰੇਟਰਾਂ ਨੂੰ ਮੈਨੁਅਲ ਜਾਰੀ ਰੱਖਣ ਦੀ ਆਗਿਆ ਦਿਓ।
ਸਤਿਤੀ ਅਪਡੇਟ ਨੂੰ ਇੱਕ ਪਹਿਲ-ਸ਼੍ਰੇਣੀ ਆਉਟਪુਟ ਸਮਝੋ: UI ਵਿੱਚ ਇੱਕ ਸੰਰਚਿਤ "Update" ਕਾਰਵਾਈ ਚੈਟ ਨੂੰ ਪਬਲਿਸ਼ ਕਰ ਸਕਦੀ ਹੈ, ਇਨਸੀਡੈਂਟ ਟਾਈਮਲਾਈਨ ਵਿੱਚ ਜੋੜ ਸਕਦੀ ਹੈ, ਅਤੇ ਵਿਕਲਪਿਕ ਤੌਰ 'ਤੇ ਸਟੇਟਸ ਪੇਜ਼ ਨਾਲ ਸਮੱਕ ਕਰ ਸਕਦੀ ਹੈ—ਬਿਨਾਂ ਰਿਸਪਾਂਡਰ ਨੂੰ ਵਾਰ-ਵਾਰ ਉਹੀ ਸੁਨੇਹਾ ਲਿਖਣ ਲਈ ਮਾਂਗਣ ਦੇ।
ਤੁਹਾਡਾ ਇਨਸੀਡੈਂਟ ਟੂਲ "ਆਊਟੇਜ ਦੌਰਾਨ" ਸਿਸਟਮ ਹੈ, ਇਸ ਲਈ ਸਾਦਗੀ ਅਤੇ ਭਰੋਸਾ ਤਰਜੀਹ ਦਿਓ। ਸਭ ਤੋਂ ਵਧੀਆ ਸਟੈਕ ਅਕਸਰ ਉਹ ਹੈ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਦੇ ਲੋਕ ਸ਼ਾਮਿਲ ਕਰਕੇ ਚਲਾ ਸਕਦੇ ਹਨ ਅਤੇ 2 ਵਜੇ ਸਵੇਰੇ ਭਰੋਸੇ ਨਾਲ ਡੀਬੱਗ ਕਰ ਸਕਦੇ ਹਨ।
ਉਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਤੁਹਾਡੇ ਇੰਜੀਨੀਅਰ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਡੈਪਲੌਇ ਕਰਦੇ ਹਨ। ਇੱਕ ਮেইਨਸਟਰੀਮ ਵੈੱਬ ਫਰੇਮਵਰਕ (Rails, Django, Laravel, Spring, Express/Nest, ASP.NET) ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਨਵੇਂ ਫਰੇਮਵਰਕ ਨਾਲੋਂ ਜੋ ਸਿਰਫ਼ ਇਕ ਵਿਅਕਤੀ ਸਮਝਦਾ ਹੋਵੇ, ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਚੋਣ ਹੁੰਦਾ ਹੈ।
ਡਾਟਾ ਸਟੋਰੇਜ ਲਈ, ਰਿਸ਼ਤੇਦਾਰ ਡੈਟਾਬੇਸ (PostgreSQL/MySQL) ਇਨਸੀਡੈਂਟ ਰਿਕਾਰڈਾਂ ਲਈ ਚੰਗੇ ਮਿਲਦੇ ਹਨ: incidents, updates, participants, action items, ਅਤੇ postmortems ਸਭ ਲੈਣ-ਦੈਨ ਅਤੇ ਸਾਫ਼ ਸੰਬੰਧਾਂ ਤੋਂ ਫਾਇਦਾ ਲੈਂਦੇ ਹਨ। Redis ਸਿਰਫ਼ ਤਦ ਜੋੜੋ ਜਦੋਂ ਤੁਹਾਨੂੰ caching, queues, ਜਾਂ ephemeral locks ਦੀ ਅਸਲ ਲੋੜ ਹੋਵੇ।
ਹੋਸਟਿੰਗ ਇੱਕ ਮੈਨੇਜਡ ਪਲੇਟਫਾਰਮ (Render/Fly/Heroku-like) ਜਾਂ ਤੁਹਾਡੇ ਮੌਜੂਦਾ ਕਲਾਉਡ (AWS/GCP/Azure) 'ਤੇ ਵੀ ਸਾਦੀ ਹੋ ਸਕਦੀ ਹੈ। ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਮੈਨੇਜਡ ਡੇਟਾਬੇਸ ਅਤੇ ਮੈਨੇਜਡ ਬੈਕਅਪ ਲੋ।
ਸਰਗਰਮ ਇਨਸੀਡੈਂਟਸ ਰੀਅਲ-ਟਾਈਮ ਅਪਡੇਟਸ ਨਾਲ ਵਧੀਆ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ, ਪਰ ਦਿਨ ਇੱਕ 'ਤੇ ਹਮੇਸ਼ਾਂ ਤੁਹਾਨੂੰ websockets ਦੀ ਲੋੜ ਨਹੀਂ।
ਇੱਕ ਪ੍ਰਯੋਗਾਤਮਕ ਵਿਚਾਰ: API/events ਇੰਝ ਡਿਜ਼ਾਈਨ ਕਰੋ ਕਿ ਤੁਸੀਂ polling ਤੋਂ ਸ਼ੁਰੂ ਕਰ ਸਕੋ ਅਤੇ ਬਾਅਦ ਵਿੱਚ websockets 'ਤੇ ਅਪਡੇਟ ਕਰਨ ਬਿਨਾਂ UI ਨੂੰ ਮੁੜ-ਲਿਖੇ।
ਜੇ ਇਹ ਐਪ ਇੱਕ ਇਨਸੀਡੈਂਟ ਦੌਰਾਨ ਫੇਲ ਹੋ ਜਾਵੇ, ਤਾਂ ਇਹ ਖੁਦ ਇੱਕ ਇਨਸੀਡੈਂਟ ਬਣ ਜਾਂਦਾ ਹੈ। ਇਸ ਲਈ ਸ਼ਾਮਲ ਕਰੋ:
ਇਸਨੂੰ ਇੱਕ ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਸਟਮ ਵਾਂਗ ਇਲਾਜ ਕਰੋ:\n\n- ਆਟੋਮੈਟਿਕ ਦੈਨਿਕ ਬੈਕਅਪ (ਅਤੇ ਨਿਯਮਤ ਰੀਸਟੋਰ ਟੈਸਟ)\n- ਸੁਰੱਖਿਅਤ ਸਕੀਮਾ ਮਾਈਗ੍ਰੇਸ਼ਨ (expand/contract ਪੈਟਰਨ, migration CI ਚੈੱਕ)\n- ਇੱਕ ਘੱਟੋ-ਘੱਟ DR ਯੋਜਨਾ: ਨਵੀਂ ਰੀਜਨ/ਅਕਾਊਂਟ ਵਿੱਚ ਕਿਵੇਂ ਲੈ ਕੇ ਆਉਣਾ ਹੈ, ਅਤੇ ਪ੍ਰਾਇਮਰੀ ਪਰਿਵੇਸ਼ ਡਾਊਨ ਹੋਣ 'ਤੇ ਡਾਟਾ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚ ਕਰਨੀ ਹੈ
ਜੇ ਤੁਸੀਂ ਵਰਕਫਲੋ ਅਤੇ ਸਕ੍ਰੀਨਸ ਨੂੰ ਵੈਧ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਬਿਨਾਂ ਪੂਰੀ ਬਿਲਡ ਵਿੱਚ ਨਿਵੇਸ਼ ਕੀਤੇ, ਤਾਂ ਇੱਕ vibe-coding ਤਰੀਕਾ ਚੰਗਾ ਰਹਿ ਸਕਦਾ ਹੈ: ਇੱਕ ਵਿਸਥਾਰਪੂਰਕ ਚੈਟ ਵਰਣਨ ਤੋਂ Koder.ai ਵਰਗੇ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਕਾਰਜਕਾਰੀ ਪ੍ਰੋਟੋਟਾਈਪ ਤਿਆਰ ਕਰੋ, ਫਿਰ tabletop exercises ਦੌਰਾਨ ਰਿਸਪਾਂਡਰਾਂ ਨਾਲ ਇਸ਼ਤਿਹਾਰ ਕਰੋ। ਕਿਉਂਕਿ Koder.ai ਅਸਲ React frontends ਨਾਲ Go + PostgreSQL ਬੈਕਐਂਡ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ (ਅਤੇ ਸਰੋਤ ਕੋਡ ਐਕਸਪੋਰਟ ਸਪੋਰਟ ਕਰਦਾ ਹੈ), ਤੁਸੀਂ ਸ਼ੁਰੂਆਤੀ ਵਰਜਨ ਨੂੰ "ਛੱਡਣਯੋਗ ਪ੍ਰੋਟੋਟਾਈਪ" ਜਾਂ ਉਸਨੂੰ ਹਾਰਡਨ ਕਰਨ ਲਈ ਸ਼ੁਰੂਆਤ ਵਜੋਂ ਵਰਤ ਸਕਦੇ ਹੋ—ਬਿਨਾਂ ਉਹ ਸਿੱਖਿਆ ਖੋ ਦੇ।
ਇਨਸੀਡੈਂਟ ਟ੍ਰੈਕਿੰਗ ਐਪ ਨੂੰ ਬਿਨਾਂ ਰਿਹਰਸਲ ਦੇ ਸ਼ਿਪ ਕਰਨਾ ਇੱਕ ਜੋਖਮ ਹੈ। ਸਭ ਤੋਂ ਵਧੀਆ ਟੀਮਾਂ ਇਸ ਟੂਲ ਨੂੰ ਕਿਸੇ ਹੋਰ ਓਪਰੇਸ਼ਨਲ ਸਿਸਟਮ ਵਾਂਗ ਟੈਸਟ ਕਰਦੀਆਂ ਹਨ: ਮੁੱਖ ਰਸਤੇ ਟੈਸਟ ਕਰੋ, ਹਕੀਕਤੀ ਡਰਿੱਲ ਚਲਾਓ, ਅਹਿਸਾਸੀ ਰੂਪ ਵਿੱਚ ਹੌਲੀ ਰੋਲਆਊਟ ਕਰੋ, ਅਤੇ ਅਸਲ ਵਰਤੋਂ ਦੇ ਆਧਾਰ 'ਤੇ ਟਿਊਨ ਕਰਦੇ ਰਹੋ।
ਉਹ ਫਲੋਜ਼ ਪਹਿਲਾਂ ਟੈਸਟ ਕਰੋ ਜੋ ਲੋਕ ਤਣਾਅ ਹੇਠਾਂ ਭਰੋਸਾ ਕਰਦੇ ਹਨ:\n\n- ਇਨਸੀਡੈਂਟ ਬਣਾਓ, ਸਮੀਕਰਨ ਨਿਰਧਾਰਤ ਕਰੋ, ਅਤੇ ਰਿਸਪਾਂਡਰਾਂ ਨੂੰ ਨੋਟੀਫਾਈ ਕਰੋ\n- ਅਪਡੇਟ ਪੋਸਟ ਕਰੋ (ਸਥਿਤੀ ਬਦਲਾਅ ਸਮੇਤ), ਇਨਸੀਡੈਂਟ ਟਾਈਮਲਾਈਨ ਵਿੱਚ ਆਰਡਰਿੰਗ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ ਸੋਧਾਂ ਨੂੰ ਸਪਸ਼ਟ ਚਿੰਨ੍ਹਿਤ ਕਰੋ\n- ਇਨਸੀਡੈਂਟ ਹੱਲ ਕਰੋ ਅਤੇ ਬੰਦ ਕਰੋ, ਫਿਰ ਆਖਰੀ ਸਥਿਤੀ ਤੋਂ ਇੱਕ پੋਸਟਮੋਰਟਮ ਤਿਆਰ ਕਰੋ\n- ਲਿੰਕਸ ਅਤੇ ਹਵਾਲੇ (ਸੇਵਾਵਾਂ, ਮਾਲਕ, ਟਿਕਟ, ਚੈਟ ਧਾਗੇ) ਸਾਰੇ ਸਮੇਂ ਦੌਰਾਨ ਅਖੰਡ ਰਹਿੰਦੇ ਹਨ ਇਹ ਯਕੀਨੀ ਕਰੋ
Regressions ਲਈ ਟੈਸਟ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਨਹੀ ਟੁੱਟਣੇ ਚਾਹੀਦੇ: ਟਾਈਮਸਟੈਂਪ, ਸਮੇਂ-ਜ਼ੋਨ, ਅਤੇ ਇਵੈਂਟ ਆਰਡਰਿੰਗ। ਇਨਸੀਡੈਂਟ ਨੈਰਾਟਿਵ ਹੁੰਦੇ—ਜੇ ਟਾਈਮਲਾਈਨ ਗਲਤ ਹੋਵੇ, ਰੁਝਾਨ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ।
ਪਰਮੀਸ਼ਨ ਬੱਗ ਆਪਰੇਸ਼ਨਲ ਅਤੇ ਸੁਰੱਖਿਆ ਜੋਖਮ ਹਨ। ਟੈਸਟ ਲਿਖੋ ਜੋ ਸਾਬਿਤ ਕਰਦੇ ਹੋਣ:
ਇਨ੍ਹਾਂ "near misses" ਨੂੰ ਵੀ ਟੈਸਟ ਕਰੋ, ਜਿਵੇਂ ਕਿ ਯੂਜ਼ਰ ਮਿਡ-ਇਨਸੀਡੈਂਟ ਪਹੁੰਚ ਗੁਆ ਚੁੱਕੇ, ਜਾਂ ਟੀਮ ਰੀ-ਆਰਗ ਰੂਪ ਵਿੱਚ ਗਰੁੱਪ ਮੈਂਬਰਸ਼ਿਪ ਬਦਲ ਗਈ।
ਵਿਆਪਕ ਰੋਲਆਊਟ ਤੋਂ ਪਹਿਲਾਂ, tabletop ਸਿਮੂਲੇਸ਼ਨਾਂ ਚਲਾਓ ਜਿੱਥੇ ਤੁਹਾਡਾ ਐਪ ਸੱਚੇ ਤੌਰ 'ਤੇ ਸਤਿਆਪਿਤ ਕੰਮ ਕਰਨ ਵਾਲਾ ਸੋਰਸ ਬਣੇ। ਉਹ ਸਿਨੇਰਿਓ ਚੁਣੋ ਜੋ ਤੁਹਾਡੀ ਸੰਸਥਾ ਪਛਾਣਦੀ ਹੈ (ਉਦਾਹਰਨ, ਅੰਸ਼ਿਕ ਆਊਟੇਜ, ਡੇਟਾ ਡਿਲੇ, ਤੀਜੀ-ਪੱਖੀ ਫੇਲ). friction ਦੇ ਲਈ ਦੇਖੋ: ਗੁੰਝਲਦਾਰ ਫੀਲਡ, ਗੁੰਮ ਸੰਦਰਭ, ਬਹੁਤ ਜ਼ਿਆਦਾ ਕਲਿੱਕ, ਅਸਪਸ਼ਟ ਮਾਲਕੀ।
ਤੁਰੰਤ ਫੀਡਬੈਕ ਕੈਪਚਰ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਛੋਟੀ, ਤੇਜ਼ ਸੁਧਾਰਾਂ ਵਿੱਚ ਬਦਲੋ।
ਇੱਕ ਪਾਇਲਟ ਟੀਮ ਅਤੇ ਕੁਝ ਪ੍ਰੀ-ਬਿਲਟ ਟੈਂਪਲੇਟ (ਇਨਸੀਡੈਂਟ ਕਿਸਮਾਂ, ਚੈੱਕਲਿਸਟ, ਪੋਸਟਮੋਰਟਮ ਫਾਰਮੈਟ) ਦੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਛੋਟੀ ਟ੍ਰੇਨਿੰਗ ਅਤੇ ਇੱਕ ਪੰਨਾ "ਕਿਵੇਂ ਅਸੀਂ ਇਨਸੀਡੈਂਟ ਚਲਾਉਂਦੇ ਹਾਂ" ਦੀ ਗਾਈਡ ਐਪ ਵਿੱਚ ਲਿੰਕ ਕਰਕੇ ਦੇਵੋ (dekhо /docs/incident-process).\n ਅਪਣਾਉ ਮੈਟਰਿਕ ਟਰੈਕ ਕਰੋ ਅਤੇ friction ਪਟਰਨਾਂ 'ਤੇ iteration ਕਰੋ: time-to-create, % incidents with updates, postmortem completion rate, ਅਤੇ action-item closure time। ਇਨ੍ਹਾਂ ਨੂੰ product metrics ਵਜੋਂ ਸਲੂਕੀ ਕਰੋ—ਅਤੇ ਹਰ ਰਿਲੀਜ਼ ਵਿੱਚ ਸੁਧਾਰ ਕਰਦੇ ਰਹੋ।
ਆਪਣੇ ਆਰਗਨਾਈਜ਼ੇਸ਼ਨ ਲਈ ਇੱਕ ठोस ਪਰਿਭਾਸ਼ਾ ਲਿਖੋ:
ਉਹ ਪਰਿਭਾਸ਼ਾ ਸਿੱਧਾ ਤੁਹਾਡੇ ਵਰਕਫਲੋ ਸਟੇਟਸ ਅਤੇ ਲਾਜ਼ਮੀ ਫੀਲਡਾਂ ਨਾਲ ਜੋੜੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਕਿ ਡਾਟਾ ਬਿਨਾਂ ਝੰਜਟ ਦੇ ਲਗਾਤਾਰ ਅਤੇ ਸੰਗਠਿਤ ਰਹੇ।
ਪੋਸਟਮੋਰਟਮ ਨੂੰ ਇੱਕ ਦਸਤਾਵੇਜ਼ ਵਜੋਂ ਨਹੀਂ, ਸਗੋਂ ਇੱਕ ਵਰਕਫਲੋ ਵਜੋਂ ਵਰਤੋ:
ਜੇ ਤੁਸੀਂ ਬਦਲੀ ਦੀ ਉਮੀਦ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਸੰਭਾਲਣ ਨਹੀਂ, ਬਲਕਿ ਐਕਸ਼ਨ-ਆਈਟਮ ਟ੍ਰੈਕਿੰਗ ਅਤੇ ਰੀਮਾਈਂਡਰ ਚਾਹੀਦੇ ਹੋਣਗੇ।
ਇਕ ਪ੍ਰਯੋਗਾਤਮਕ v1 ਸੈੱਟ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਉੱਚ-ਸੁਝਾਅ ਵਾਲੀਆਂ ਆਟੋਮੇਸ਼ਨ ਤੁਹਾਨੂੰ ਤਬ ਤੱਕ ਨਹੀਂ ਚਾਹੀਦੀਆਂ ਜਦ ਤੱਕ ਇਹ ਮੂਲ ਫਲੋ ਸਟਰੈੱਸ ਹੇਠਾਂ ਠੀਕ ਤਰ੍ਹਾਂ ਕੰਮ ਨਹੀਂ ਕਰਦੇ।
ਛੋਟੇ ਅਤੇ ਪੂਰਣਯੋਗ ਸਟੇਜ ਵਰਤੋਂ ਜੋ ਟੀਮਾਂ ਅਮਲ ਵਿੱਚ ਵਰਤਦੀਆਂ ਹਨ:
ਹਰ ਸਟੇਜ ਲਈ “ਕੀ ਹੋ ਗਿਆ” ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਫਿਰ ਗਾਰਡਰੇਲ ਸ਼ਾਮਲ ਕਰੋ:
ਇਸ ਨਾਲ ਫੱਸੇ ਹੋਏ ਇਨਸੀਡੈਂਟਾਂ ਤੋਂ ਬਚਾਅ ਹੁੰਦਾ ਹੈ ਅਤੇ ਬਾਅਦ ਦੀ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਗੁਣਵੱਤਾ ਬਿਹਤਰ ਹੁੰਦੀ ਹੈ।
ਕੁਝ ਸਾਫ਼ ਰੋਲ ਮਾਡਲ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਅਧਿਕਾਰਾਂ ਨਾਲ ਜੋੜੋ:
UI ਵਿੱਚ ਵਰਤਮਾਨ ਮਾਲਕ/ਕਮਾਂਡਰ ਸਪਸ਼ਟ ਦਿਖਾਈ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਡੈਲੀਗੇਸ਼ਨ (ਰਿਅਸਾਈਨ, ਕਮਾਂਡਰ ਰੋਟੇਸ਼ਨ) ਦੀ ਸਹਾਇਤਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਛੋਟਾ ਪਰ ਸਰਚਿਰਚਿਤ ਡਾਟਾ ਮਾਡਲ ਰੱਖੋ:
Stable identifiers (UUIDs) ਵਰਤੋਂ ਅਤੇ ਇੱਕ ਮਨੁੱਖ-ਪ੍ਰੀਤ ਸੂਚਕ (ਜਿਵੇਂ INC-2025-0042) ਰੱਖੋ। ਸੰਪਾਦਨ ਨੂੰ ਇਤਿਹਾਸ ਵਜੋਂ ਸੁਰੱਖਿਅਤ ਕਰੋ—ਹਰ ਰਿਕਾਰਡ ਤੇ created_at/created_by ਅਤੇ ਇੱਕ ਆਡੀਟ ਲੌਗ ਰੱਖੋ।
ਅੰਦਰੂਨੀ ਨੋਟਸ ਅਤੇ ਹਿੱਸੇਦਾਰ-ਮੁੱਖ ਸਥਿਤੀ ਅਲੱਗ ਰੱਖੋ:
ਦੋਨੋਂ ਨੂੰ ਇਨਸੀਡੈਂਟ ਰਿਕਾਰਡ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਰੱਖੋ ਤਾਂ ਕਿ ਫੈਸਲੇ ਬਾਅਦ ਵਾਪਸੀ ਤੇ ਵੀ ਦੁਹਰਾਏ ਨਾ ਜਾਣ ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ ਲੀਕ ਨਾ ਹੋਵੇ।
Severity ਲਈ ਸਪਸ਼ਟ ਉਮੀਦਾਂ ਪਰिभਾਸ਼ਿਤ ਕਰੋ (ਜਿਵੇਂ ਜਵਾਬ ਦੀ ਤਜਵੀਜ਼ ਅਤੇ ਸੰਚਾਰ ਕੈਡੈਂਸ). ਉਦਾਹਰਣ ਲਈ:
ਜਿੱਥੇ ਸਮੀਕਰਨ ਚੁਣਿਆ ਜਾ ਰਿਹਾ ਹੈ ਉਥੇ UI ਵਿੱਚ ਨਿਯਮ ਦਿਖਾਓ ਤਾਂ ਜੋ ਰਿਸਪਾਂਡਰਾਂ ਨੂੰ ਬਾਹਰੀ ਡੌਕਸ ਦੀ ਲੋੜ ਨਾ ਪਏ।
ਕਾਰਵਾਈ ਆਈਟਮਾਂ ਨੂੰ ਸਰਚਿਰਚਿਤ ਰਿਕਾਰਡ ਬਣਾਓ, ਨਿੱਲੇ ਟੈਕਸਟ ਨਹੀਂ:
ਫਿਰ ਗਲੋਬਲ ਵਿਉਜ਼ ਦਿਓ (overdue, due this week, by owner/service) ਅਤੇ ਸਧਾਰੇ ਨੋਟਿਸ/ਏਸਕੇਲੈਸ਼ਨ ਇਸਤਰੇਨ ਜਿਹੜੇ ਫਾਲੋ-ਅਪ ਨੂੰ ਗਾਇਬ ਹੋਣ ਤੋਂ ਰੋਕਦੇ ਹਨ।
ਪ੍ਰੋਵਾਇਡਰ-ਨਿਰਧਾਰਤ idempotency ਕੀਜ਼ ਅਤੇ ਡੈਡਪਲੀਕੇਸ਼ਨ ਨੀਤੀਆਂ ਵਰਤੋਂ:
provider + alert_id + occurrence_idਜਦੋਂ APIs ਨਾਕਾਰ ਹੋਣ, ਹਮੇਸ਼ਾ ਮੈਨੁਅਲ ਲਿੰਕਿੰਗ ਨੂੰ ਇਕ ਫਾਲਬੈਕ ਵਜੋਂ ਛੱਡੋ।