ਇੱਕ ਵਿਹਾਰਕ ਰੂਪਰੇਖਾ ਸਿੱਖੋ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਇੱਕ ਵੈੱਬ ਐਪ ਬਣਾਉ ਸਕੋ ਜੋ SLA ਟਾਈਮਰਾਂ ਨੂੰ ਟ੍ਰੈਕ ਕਰਦਾ ਹੈ, ਉਲੰਘਣ ਤੁਰੰਤ ਪਛਾਣਦਾ ਹੈ, ਟੀਮਾਂ ਨੂੰ ਅਲਰਟ ਕਰਦਾ ਹੈ ਅਤੇ ਰੀਅਲ‑ਟਾਈਮ ਵਿੱਚ ਪਾਲਣਾ ਦਿਖਾਉਂਦਾ ਹੈ।
ਸਕ੍ਰੀਨ ਡਿਜ਼ਾਈਨ ਜਾਂ ਡਿਟੈਕਸ਼ਨ ਲਾਜਿਕ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ, ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਤੁਹਾਡੀ ਐਪ ਕੀ ਰੋਕਣਾ ਚਾਹੁੰਦੀ ਹੈ। “SLA ਨਿਗਰਾਨੀ” ਕਿਸੇ ਦੈਨਿਕ ਰਿਪੋਰਟ ਤੋਂ ਲੈ ਕੇ ਸਕਿੰਡ-ਬਾਇ-ਸਕਿੰਡ ਬਰੀਚ ਪੂਰਵਅਨੁਮਾਨ ਤੱਕ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਦਾ ਅਰਥ ਹੋ ਸਕਦਾ ਹੈ—ਇਹਨਾਂ ਦਾ ਆਰਕੀਟੈਕਚਰ ਬਹੁਤ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ।
ਆਪਣੀ ਟੀਮ ਦੁਆਰਾ ਵਾਸਤਵਿਕ ਤੌਰ 'ਤੇ ਨਿਭਾਇਆ ਜਾ ਸਕਣ ਵਾਲੇ ਰਿਆਕਸ਼ਨ ਵਿੰਡੋ 'ਤੇ ਸਹਿਮਤੀ ਕਰੋ।
ਜੇ ਤੁਹਾਡੀ ਸਪੋਰਟ ਸੰਚਾਲਨਾ 5–10 ਮਿੰਟ ਚੱਕਰਾਂ 'ਚ ਚੱਲਦੀ ਹੈ (ਟ੍ਰਾਇਐਜ ਕਿਊਜ਼, ਪੇਜਿੰਗ ਰੋਟੇਸ਼ਨ), ਤਾਂ “ਰੀਅਲ-ਟਾਈਮ” ਦਾ ਮਤਲਬ ਹਰ ਮਿਲੀ ਵਿੱਚ ਡੈਸ਼ਬੋਰਡ ਅੱਪਡੇਟਸ ਅਤੇ 2 ਮਿੰਟਾਂ ਵਿੱਚ ਅਲਰਟ ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਉੱਚ-ਗੰਭੀਰਤਾ ਘਟਨਾਵਾਂ ਨਾਲ ਨਿਪਟਦੇ ਹੋ ਜਿੱਥੇ ਮਿੰਟ ਅਹੰਕਾਰਪੂਰਨ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ 10–30 ਸਕਿੰਟ ਦੀ ਡਿਟੈਕਸ਼ਨ-ਅਤੇ-ਅਲਰਟ ਲੂਪ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।
ਇਸ ਨੂੰ ਇੱਕ ਮਾਪਯੋਗ ਲਕਸ਼ ਵਜੋਂ ਲਿਖੋ, ਉਦਾਹਰਣ ਲਈ: “60 ਸਕਿੰਟ ਵਿੱਚ ਸੰਭਵ ਬਰੀਚਾਂ ਪਛਾਣੋ ਅਤੇ 2 ਮਿੰਟਾਂ ਵਿੱਚ on-call ਨੂੰ ਸੂਚਿਤ ਕਰੋ।” ਇਹ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਲਾਗਤ ਵਿੱਚ ਆਉਣ ਵਾਲੇ ਫੈਸਲਿਆਂ ਲਈ ਗਾਰਡਰੇਲ ਬਣ ਜਾਵੇਗਾ।
ਕਿਸੇ-ਕਿਸੇ ਵਾਅਦੇ ਦੀ ਸੂਚੀ ਬਣਾਓ ਜੋ ਤੁਸੀਂ ਟ੍ਰੈਕ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਹਰ ਇੱਕ ਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਪਰਿਭਾਸ਼ਤ ਕਰੋ:
ਇਹ ਵੀ ਨੋਟ ਕਰੋ ਕਿ ਇਹ ਤੁਹਾਡੇ ਆਰਗੈਨਾਈਜ਼ੇਸ਼ਨ ਵਿੱਚ SLO ਅਤੇ SLA ਪਰਿਭਾਸ਼ਾਵਾਂ ਨਾਲ ਕਿਵੇਂ ਸੰਬੰਧਿਤ ਹਨ। ਜੇ ਤੁਹਾਡਾ ਅੰਦਰੂਨੀ SLO ਗਾਹਕ-ਸਾਮ੍ਹਣੇ SLA ਤੋਂ ਵੱਖਰਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ ਐਪ ਦੋਹਾਂ ਨੂੰ ਟ੍ਰੈਕ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ: ਇੱਕ ਓਪਰੇਸ਼ਨਲ ਸੁਧਾਰ ਲਈ, ਦੂਜਾ ਠੇਕੇਦਾਰ ਨੁਕਸਾਨ-ਰਿਸਕ ਲਈ।
ਉਹ ਗਰੁੱਪ ਨਾਂ ਲਿਖੋ ਜੋ ਸਿਸਟਮ ਨੂੰ ਵਰਤਣਗੇ ਜਾਂ ਉਸ 'ਤੇ ਨਿਰਭਰ ਹੋਣਗੇ: ਸਪੋਰਟ, ਇੰਜੀਨੀਅਰਿੰਗ, ਕਸਟਮਰ ਸਫਲਤਾ, ਟੀਮ ਲੀਡ/ਮੈਨੇਜਰ ਅਤੇ ਇਨਸੀਡੈਂਟ ਰੈਸਪਾਂਸ/on-call।
ਹਰ ਗਰੁੱਪ ਲਈ ਉਹ ਫੈਸਲੇ ਦਰਜ ਕਰੋ ਜੋ ਉਹ ਤੁਰੰਤ ਲੈਣਗੇ: “ਕੀ ਇਹ ਟਿਕਟ ਖਤਰੇ ਵਿੱਚ ਹੈ?”, “ਇਸਦਾ ਮਾਲਿਕ ਕੌਣ ਹੈ?”, “ਸਾਨੂੰ ਏਸਕਲੇਸ਼ਨ ਦੀ ਲੋੜ ਹੈ?” ਇਹ ਤੁਹਾਡੇ ਡੈਸ਼ਬੋਰਡ, ਅਲਰਟ ਰੂਟਿੰਗ ਅਤੇ ਪਰਮੀਸ਼ਨ ਨੂੰ ਸ਼ੇਪ ਦੇਵੇਗਾ।
ਤੁਹਾਡਾ ਲਕਸ਼ ਸਿਰਫ ਵਿਜ਼ੀਬਿਲਟੀ ਨਹੀਂ—ਇਹ ਸਮੇਂ ਉੱਤੇ ਕਾਰਵਾਈ ਹੈ। ਫੈਸਲਾ ਕਰੋ ਕਿ ਜਦੋਂ ਰਿਸਕ ਵਧੇ ਜਾਂ ਬਰੀਚ ਹੋਵੇ ਤਾਂ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਇੱਕ ਚੰਗਾ ਨਤੀਜਾ ਬਿਆਨ: “ਸਾਡੇ ਸਹਿਮਤ ਰਿਆਕਸ਼ਨ ਵਿੰਡੋ ਦੇ ਅੰਦਰ ਬਰੀਚ ਪਛਾਣ ਅਤੇ ਇਨਸੀਡੈਂਟ ਰੈਸਪਾਂਸ ਯੋਗ ਕਰਕੇ SLA ਬਰੀਚਾਂ ਘਟਾਓ।”
ਡਿਟੈਕਸ਼ਨ ਲਾਜਿਕ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਬਿਲਕੁਲ ਲਿਖੋ ਕਿ ਤੁਹਾਡੀ ਸੇਵਾ ਲਈ “ਚੰਗਾ” ਅਤੇ “ਮੰਦਾ” ਕੀ ਹੁੰਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ SLA ਮਾਨੀਟਰਨਿੰਗ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਤਕਨੀਕੀ ਨਹੀਂ—ਉਹ ਪਰਿਭਾਸ਼ਾ ਸਮੱਸਿਆਵਾਂ ਹੁੰਦੀਆਂ ਹਨ।
SLA (Service Level Agreement) ਗਾਹਕਾਂ ਦੇ ਲਈ ਇੱਕ ਵਾਅਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਨਤੀਜੇ (ਕ੍ਰੈਡਿਟ, ਜੁਰਮਾਨੇ, ਕਾਂਟ੍ਰੈਕਟ ਸ਼ਰਤਾਂ) ਦੇ ਨਾਲ। SLO (Service Level Objective) ਇੱਕ ਅੰਦਰੂਨੀ ਲਕਸ਼ ਹੈ ਜੋ ਤੁਸੀਂ SLA ਤੋਂ ਉੱਤੇ ਰਹਿਣ ਲਈ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋ। KPI (Key Performance Indicator) ਕੋਈ ਵੀ ਮੈਟ੍ਰਿਕ ਹੈ ਜੋ ਤੁਸੀਂ ਟ੍ਰੈਕ ਕਰਦੇ ਹੋ (ਮਦਦਗਾਰ, ਪਰ ਹਰ ਵਾਰੀ ਵਾਅਦੇ ਨਾਲ ਜੁੜਿਆ ਨਹੀਂ)।
ਉਦਾਹਰਣ: SLA = “1 ਘੰਟੇ ਦੇ ਅੰਦਰ ਜਵਾਬ।” SLO = “30 ਮਿੰਟਾਂ ਦੇ ਅੰਦਰ ਜਵਾਬ।” KPI = “ਔਸਤ ਪਹਿਲਾ ਜਵਾਬ ਸਮਾਂ।”
ਉਹ ਹਰ ਬਰੀਚ ਕਿਸਮ ਲਿਖੋ ਜਿਸ ਨੂੰ ਤੁਹਾਨੂੰ ਪਛਾਣਣ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਉਹ ਘਟਨਾ ਜਿਸ ਨਾਲ ਟਾਈਮਰ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ।
ਆਮ ਬਰੀਚ ਸ਼੍ਰੇਣੀਆਂ:
ਸਪਸ਼ਟ ਹੋਵੋ ਕਿ “ਰਿਸਪਾਂਸ” ਵਿੱਚ ਕੀ ਗਿਣਤੀ ਹੁੰਦੀ ਹੈ (ਪਬਲਿਕ ਰੇਪਲਾਈ ਬਨਾਮ ਅੰਦਰੂਨੀ ਨੋਟ) ਅਤੇ “ਰਿਜ਼ੋਲੂਸ਼ਨ” ਕੀ ਹੈ (resolved ਬਨਾਮ closed), ਅਤੇ ਕੀ ਮੁੜ-ਖੋਲ੍ਹਣਾ ਟਾਈਮਰ ਨੂੰ ਰੀਸੈਟ ਕਰਦਾ ਹੈ।
ਬਹੁਤ ਸਾਰੇ SLA ਸਿਰਫ ਕਾਰੋਬਾਰੀ ਘੰਟਿਆਂ ਦੇ ਦੌਰਾਨ ਸਮਾਂ ਗਿਣਦੇ ਹਨ। ਕੈਲੰਡਰ ਪਰਿਭਾਸ਼ਤ ਕਰੋ: ਕੰਮ ਦੇ ਦਿਨ, ਛੁੱਟੀਆਂ, ਸ਼ੁਰੂ/ਖ਼ਤਮ ਸਮੇ ਅਤੇ ਗਣਨਾ ਲਈ ਵਰਤੀ ਜਾਣ ਵਾਲੀ ਟਾਈਮਜ਼ੋਨ (ਗਾਹਕ ਦੀ, ਕੰਟਰੈਕਟ ਦੀ, ਜਾਂ ਟੀਮ ਦੀ)। ਇਹ ਵੀ ਫੈਸਲਾ ਕਰੋ ਕਿ ਜਦੋਂ ਕੰਮ ਸਰਹੱਦਾਂ ਨੂੰ ਲੰਘਦਾ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ (ਉਦਾਹਰਣ: 16:55 'ਤੇ 30 ਮਿੰਟ ਦਾ ਜਵਾਬ SLA ਆਉਂਦਾ)।
ਉਹ ਹਾਲਤਾਂ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਜਦੋਂ SLA ਘੜੀ ਰੁਕ ਜਾਂਦੀ ਹੈ, ਉਦਾਹਰਣ:
ਇਹਨਾਂ ਨੂੰ ਨਿਯਮਾਂ ਵਜੋਂ ਲਿਖੋ ਜੋ ਤੁਹਾਡੀ ਐਪ ਲਗਾਤਾਰ ਲਾਗੂ ਕਰ ਸਕੇ, ਅਤੇ ਮੁਸ਼ਕਲ ਮਾਮਲਿਆਂ ਦੇ ਉਦਾਹਰਣ ਬਾਅਦ ਟੈਸਟਿੰਗ ਲਈ ਰੱਖੋ।
ਤੁਹਾਡਾ SLA ਮੋਨਿਟਰ ਉਸ ਡਾਟਾ ਦੇਵੋਂ ਹੀ ਭਰੋਸੇਯੋਗ ਹੋਵੇਗਾ ਜੋ ਉਸਨੂੰ ਮਿਲਦੀ ਹੈ। ਹਰ SLA ਘੜੀ ਲਈ “systems of record” ਪਛਾਣੋ। ਕਈ ਟੀਮਾਂ ਲਈ ਟਿਕਟਿੰਗ ਟੂਲ ਫੁਟਕਾਰਟਾਈਮਸਟੈਂਪ ਦਾ ਸਰੋਤ ਹੁੰਦਾ ਹੈ, ਜਦਕਿ ਮਾਨੀਟਰਨਿੰਗ ਅਤੇ ਲੌਗ ਸੰਦ ਬਿਆਨ ਕਰਦੇ ਹਨ ਕਿ “ਕਿਉਂ” ਕੁਝ ਹੋਇਆ।
ਜ਼ਿਆਦਾਤਰ ਰੀਅਲ-ਟਾਈਮ SLA ਸੈਟਅਪ ਕੁਝ ਮੁੱਖ ਸਿਸਟਮਾਂ ਤੋਂ ਖਿੱਚਦੇ ਹਨ:
ਜੇ ਦੋ ਸਿਸਟਮ ਵਿੱਛੋਂ ਅਸਮਤੋਲਤਾ ਹੋਵੇ ਤਾਂ ਪਹਿਲਾਂ ਤੋਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕਿਸ ਫੀਲਡ ਲਈ ਕਿਹੜਾ ਜਿੱਤਦਾ ਹੈ (ਉਦਾਹਰਣ: “ServiceNow ਤੋਂ ticket status, CRM ਤੋਂ customer tier”)।
ਘੱਟੋ-ਘੱਟ, ਉਹ ਘਟਨਾਵਾਂ ਟ੍ਰੈਕ ਕਰੋ ਜੋ SLA ਟਾਈਮਰ ਨੂੰ ਸ਼ੁਰੂ, ਰੋਕ ਜਾਂ ਬਦਲਦੀਆਂ ਹਨ:
Operational events ਵੀ ਸੋਚੋ: ਬਿਜ਼ਨੇਸ ਘੰਟੇ ਕੈਲੰਡਰ ਬਦਲਾਅ, ਗਾਹਕ ਟਾਈਮਜ਼ੋਨ ਅਪਡੇਟ, ਅਤੇ ਛੁੱਟੀ ਸਕੇਜੂਲ ਬਦਲਾਅ।
ਨਜ਼ਦੀਕੀ-ਰੀਅਲ-ਟਾਈਮ ਅਪਡੇਟ ਲਈ webhooks ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਜੇ webhooks ਉਪਲਬਧ ਨਹੀਂ ਹਨ ਤਾਂ polling ਵਰਤੋ। ਸਮਰੂਪਤਾ ਲਈ API exports/backfills ਰੱਖੋ (ਜਿਵੇਂ ਰਾਤ ਦੀ ਨੌਕਰੀਆਂ ਜੋ ਗੈਪ ਭਰਦੀਆਂ ਹਨ)। ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਇੱਕ ਹਾਈਬਰੀਡ ਨਾਲ ਖਤਮ ਹੁੰਦੀਆਂ ਹਨ: ਤੇਜ਼ੀ ਲਈ webhook ਅਤੇ ਸੁਰੱਖਿਆ ਲਈ ਨਿਯਤੀ polling।
ਅਸਲੀ ਸਿਸਟਮ ਗੰਦੇ ਹੋ ਸਕਦੇ ਹਨ। ਉਮੀਦ ਰੱਖੋ:
ਇਹਨਾਂ ਨੂੰ “ਏਜ ਕੇਸ” ਨਾ ਸਮਝੋ—ਇਹ ਉਤਪਾਦ ਲੋੜਾਂ ਹਨ। ਤੁਹਾਡੀ ਬਰੀਚ ਡਿਟੈਕਸ਼ਨ ਇਹਨਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।
ਇੱਕ ਚੰਗੀ SLA ਮਾਨੀਟਰਨਿੰਗ ਐਪ तब ਹੀ ਬਣਾਉਣਾ ਅਤੇ ਰਖਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਆਰਕੀਟੈਕਚਰ ਸਪਸ਼ਟ ਅਤੇ ਜਾਣਬੂਝ ਕੇ ਸਧਾਰਨ ਹੋਵੇ। ਉੱਚ-ਸਤਰੀਆ 'ਤੇ, ਤੁਸੀਂ ਇੱਕ ਪਾਈਪਲਾਈਨ ਬਣਾ ਰਹੇ ਹੋ ਜੋ ਕੱਚੇ ਓਪਰੇਸ਼ਨਲ ਸਿਗਨਲਾਂ ਨੂੰ “SLA ਸਟੀਟ” ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਫਿਰ ਉਸ ਸਟੀਟ ਨੂੰ ਅਲਰਟ ਕਰਨ ਅਤੇ ਡੈਸ਼ਬੋਰਡ ਚਲਾਉਣ ਲਈ ਵਰਤਦਾ ਹੈ।
ਪੰਜ ਬਲੌਕ ਸੋਚੋ:
ਇਹ ਵੰਡ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨੂੰ ਸਾਫ਼ ਰੱਖਦੀ ਹੈ: ingest ਵਿੱਚ SLA ਲਾਜਿਕ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ ਅਤੇ ਡੈਸ਼ਬੋਰਡ ਭਾਰੀ ਗਣਨਾਵਾਂ ਨਹੀਂ ਚਲਾਉਣੇ ਚਾਹੀਦੇ।
ਆਪਣੀ ਲੋੜ ਅੱਗੇ ਕਿ “ਕਿੰਨਾ ਰੀਅਲ-ਟਾਈਮ” ਤੁਸੀਂ ਵਾਕਈ ਚਾਹੁੰਦੇ ਹੋ, ਉਸ ਦਾ ਫ਼ੈਸਲਾ ਜਲਦੀ ਕਰੋ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਦ੍ਰਿਸ਼ਟੀਕੋਣ: ਇੱਕ ਜਾਂ ਦੋ SLA ਨਿਯਮਾਂ ਲਈ ਮੁੜ-ਗਣਨਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਉੱਚ ਪ੍ਰਭਾਵ ਵਾਲੇ ਨਿਯਮ ਸਟ੍ਰੀਮਿੰਗ 'ਤੇ ਲਿਜਾਓ।
ਸ਼ੁਰੂ ਵਿੱਚ ਮਲਟੀ-ਰਿਆਇਓਨ ਅਤੇ ਮਲਟੀ-ਇਨਵਾਇਰਨਮੈਂਟ ਜਟਿਲਤਾ ਤੋਂ ਬਚੋ। ਇੱਕ ਇਕੱਲੇ ਰੀਜਨ, ਇੱਕ ਪ੍ਰੋਡਕਸ਼ਨ ਵਾਤਾਵਰਣ ਅਤੇ ਇੱਕ ਘੱਟੋ-ਘੱਟ ਸਟੇਜਿੰਗ ਸੈੱਟਅਪ ਆਮ ਤੌਰ 'ਤੇ ਕਾਫੀ ਹੁੰਦੇ ਹਨ ਜਦ ਤੱਕ ਤੁਸੀਂ ਡਾਟਾ ਗੁਣਵੱਤਾ ਅਤੇ ਅਲਰਟ ਉਪਯੋਗਿਤਾ ਦੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕਰ ਲੈਂਦੇ।
ਜੇ ਤੁਸੀਂ ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਵਰਕਫ਼ਲੋਜ਼ ਦਾ ਪਹਿਲਾ ਵਰਕਿੰਗ ਵਰਜ਼ਨ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai ਵਰਗਾ vibe-coding ਪਲੇਟਫਾਰਮ ਤੁਹਾਨੂੰ ਗੱਲ-ਵਾਰ ਸਪੈੱਕ ਤੋਂ React-आਧਾਰਿਤ UI ਅਤੇ Go + PostgreSQL ਬੈਕਐਂਡ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ scaffold ਕਰਕੇ ਸਕ੍ਰੀਨ ਅਤੇ ਫਿਲਟਰਾਂ 'ਤੇ ਇਟਰੇਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ।
ਇਹਨਾਂ ਨੂੰ ਇੰਪਲੀਮੈਂਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ:
ਇਵੈਂਟ ਇੰਜੈਸ਼ਨ ਹੀ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਤੁਹਾਡਾ SLA ਮਾਨੀਟਰਨਿੰਗ ਸਿਸਟਮ ਭਰੋਸੇਯੋਗ ਬਣਦਾ ਜਾਂ ਸ਼ੋਰ ਅਤੇ ਗ਼ਲਤ ਹੋ ਜਾਂਦਾ ਹੈ। ਲਕਸ਼ ਸਧਾਰਨ ਹੈ: ਕਈ ਟੂਲਾਂ ਤੋਂ ਇਵੈਂਟ ਲਵੋ, ਉਹਨਾਂ ਨੂੰ ਇਕ ਏਕ “ਟ੍ਰੂਥੀ” ਫਾਰਮੈਟ ਵਿੱਚ ਬਦਲੋ, ਅਤੇ ਕਾਫ਼ੀ ਸੰਦਰਭ ਸਟੋਰ ਕਰੋ ਤਾਂ ਜੋ ਹਰ SLA ਫੈਸਲੇ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਸਮਝਾਇਆ ਜਾ ਸਕੇ।
ਉਪਰਲੇ ਸਿਸਟਮ ਵੱਖ-ਵੱਖ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਇੱਕ “SLA-ਸੰਬੰਧੀ ਇਵੈਂਟ” ਕੀ ਦਿਸਦਾ ਹੈ, ਇਹ ਮਿਆਰ ਬਣਾਓ। ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਬੇਸਲਾਈਨ ਸਕੀਮਾ ਵਿੱਚ ਸ਼ਾਮਿਲ ਹੋ ਸਕਦਾ ਹੈ:
ticket_id (ਜਾਂ case/work item ID)timestamp (ਕਦੋਂ ਬਦਲਾਅ ਹੋਇਆ, ਨਾ ਕਿ ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਪ੍ਰਾਪਤ ਕੀਤਾ)status (opened, assigned, waiting_on_customer, resolved, ਆਦਿ)priority (P1–P4 ਜਾਂ ਸਮਾਨ)customer (account/tenant identifier)sla_plan (ਕਿਹੜੇ SLA ਨਿਯਮ ਲਾਗੂ ਹੁੰਦੇ)ਸਕੀਮਾ ਨੂੰ ਵਰਜਨ ਕਰੋ (ਉਦਾਹਰਣ: schema_version) ਤਾਂ ਜੋ ਤੁਸੀਂ ਫੀਲਡ ਅਪਡੇਟ ਕਰ ਸਕੋ ਬਿਨਾਂ ਪੁਰਾਣੇ ਪ੍ਰੋਡਿਊਸਰ ਟੁੱਟੇ।
ਵੱਖ-ਵੱਖ ਸਿਸਟਮ ਇੱਕੋ ਹੀ ਚੀਜ਼ ਨੂੰ ਵੱਖਰੇ ਨਾਂ ਨਾਲ ਦੱਸਦੇ ਹਨ: “Solved” vs “Resolved,” “Urgent” vs “P1,” ਟਾਈਮਜ਼ੋਨ ਫਰਕ, ਜਾਂ ਗੁੰਮ ਪ੍ਰਾਇਰਿਟੀ। ਇੱਕ ਛੋਟਾ ਨਾਰਮਲਾਈਜ਼ੇਸ਼ਨ ਲੇਅਰ ਬਣਾਓ ਜੋ:
is_customer_wait ਜਾਂ is_pause) ਜੋ ਬਾਅਦ ਵਿੱਚ ਬਰੀਚ ਲਾਜਿਕ ਸਧਾਰਨ ਬਣਾਉਂਦੇ ਹਨਇੰਟਿਗ੍ਰੇਸ਼ਨਾਂ ਪੁਨਰਕੋਸ਼ਿਸ਼ ਕਰਦੀਆਂ ਹਨ। ਤੁਹਾਡੀ ਇੰਜੈਸ਼ਨ idempotent ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਕਿ ਦੁਹਰਾਏ ਹੋਏ ਇਵੈਂਟ ਡੁਪਲਿਕੇਟ ਨਾ ਬਣਾਉਣ। ਆਮ ਨਜ਼ਰੀਏ:
event_id ਦੀ ਮੰਗ ਕਰੋ ਅਤੇ duplicates reject ਕਰੋticket_id + timestamp + status) ਅਤੇ upsert ਕਰੋਜਦੋਂ ਕੋਈ ਪੁੱਛਦਾ ਹੈ “ਅਸੀਂ ਕਿਉਂ ਅਲਰਟ ਕੀਤਾ?” ਤੁਹਾਨੂੰ ਇੱਕ ਪੇਪਰ ਟਰੇਲ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਹਰ ਸੁਵੀਕਾਰ ਕੀਤਾ ਰਾ ਇਵੈਂਟ ਅਤੇ ਹਰ ਨਾਰਮਲਾਈਜ਼ਡ ਇਵੈਂਟ ਨੂੰ ਸਟੋਰ ਕਰੋ, ਨਾਲ ਹੀ ਇਹ ਕਿ ਕਿਸਨੇ/ਕੀ ਚੀਜ਼ ਨੇ ਇਸਨੂੰ ਬਦਲਿਆ। ਇਹ ਆਡੀਟ ਇਤਿਹਾਸ ਗਾਹਕ ਸੰਵਾਦ ਅਤੇ ਅੰਦਰੂਨੀ ਸਮੀਖਿਆ ਲਈ ਜ਼ਰੂਰੀ ਹੈ।
ਕੁਝ ਇਵੈਂਟ parsing ਜਾਂ validation 'ਚ fail ਹੋਣਗੇ। ਉਹਨਾਂ ਨੂੰ ਖਾਮੋਸ਼ੀ ਨਾਲ ਨਾ ਡਰੌਪ ਕਰੋ। ਉਨ੍ਹਾਂ ਨੂੰ dead-letter queue/table 'ਚ ਰਾਊਟ ਕਰੋ ਜਿਸ ਵਿੱਚ error ਕਾਰਨ, ਮੂਲ payload, ਅਤੇ retry ਗਿਣਤੀ ਹੋਵੇ, ਤਾਂ ਜੋ ਤੁਸੀਂ mappings ਠੀਕ ਕਰਕੇ replay ਕਰ ਸਕੋ।
ਤੁਹਾਡੀ SLA ਐਪ ਨੂੰ ਦੋ ਵੱਖ-ਵੱਖ “ਯਾਦਾਂ” ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਹੁਣ ਦਾ ਸੱਚ (ਅਲਰਟ ਟਰਿਗਰ ਕਰਨ ਲਈ) ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਕੀ ਹੋਇਆ (ਸਬੂਤ ਅਤੇ ਵਿਵਾਦਾਂ ਲਈ)।
ਮੌਜੂਦਾ ਸਟੀਟ ਹਰ ਵਰਕ ਆਈਟਮ (ਟਿਕਟ/ਇਨਸੀਡੈਂਟ/ਆਰਡਰ) ਦੀ ਆਖ਼ਰੀ ਜਾਣਕਾਰੀ ਅਤੇ ਉਸਦੀ ਸਰਗਰਮ SLA ਟਾਈਮਰਾਂ (ਸ਼ੁਰੂ ਸਮਾਂ, pauzed ਸਮਾਂ, due time, ਬਾਕੀ ਮਿੰਟ, ਮੌਜੂਦਾ ਮਾਲਿਕ) ਹੁੰਦੀ ਹੈ।
ਇਕ ਐਸਾ ਸਟੋਰ ਚੁਣੋ ਜੋ ID ਅਨੁਸਾਰ ਤੇਜ਼ ਪੜ੍ਹਨ/ਲਿਖਣ ਲਈ ਅਨੁਕੂਲ ਹੋਵੇ ਅਤੇ ਸਧਾਰਨ ਫਿਲਟਰੇਸ਼ਨ ਕਰ ਸਕੇ। ਆਮ ਵਿਕਲਪ Postgres/MySQL ਜਾਂ Redis/DynamoDB ਹਨ। ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਲਈ Postgres ਕਾਫੀ ਹੁੰਦਾ ਹੈ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਸਧਾਰਨ ਰੱਖਦਾ ਹੈ।
ਸਟੇਟ ਮਾਡਲ ਨੂੰ ਛੋਟਾ ਅਤੇ ਕੁਐਰੀ-ਫ੍ਰੈਂਡਲੀ ਰੱਖੋ। ਤੁਸੀਂ ਲਗਾਤਾਰ ਇਸਨੂੰ “ਬਰੀਚ ਹੋਣ ਵਾਲੇ” ਵਿਊਜ਼ ਲਈ ਪੜ੍ਹੋਗੇ।
ਇਤਿਹਾਸ ਹਰ ਬਦਲਾਅ ਨੂੰ ਇੱਕ ਅਟੂਟ ਰਿਕਾਰਡ ਵਜੋਂ ਕੈਪਚਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: created, assigned, priority changed, status updated, customer replied, on-hold started/ended ਆਦਿ।
ਇੱਕ append-only ਇਵੈਂਟ ਟੇਬਲ (ਜਾਂ ਇਵੈਂਟ ਸਟੋਰ) ਆਡੀਟ ਅਤੇ ਰੀਪਲੇ ਲਈ ਯੋਗ ਬਣਾਉਂਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਕਿਸੇ ਬਗ ਨੂੰ ਪਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇਵੈਂਟਸ ਨੂੰ ਦੁਬਾਰਾ ਪ੍ਰੋਸੈਸ ਕਰਕੇ ਸਟੇਟ ਰੀਬਿਲਡ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਨਤੀਜੇ ਤੁਲਨਾ ਕਰ ਸਕਦੇ ਹੋ।
ਪ੍ਰਯੋਗਿਕ ਪੈਟਰਨ: ਪਹਿਲਾਂ ਉਸੇ ਡੇਟਾਬੇਸ ਵਿੱਚ state table + events table; ਜੇ ਵਾਲੀਅਮ ਵੱਧੇ ਤਾਂ ਬਾਅਦ ਵਿੱਚ ਵੱਖਰੇ ਐਨਾਲਿਟਿਕਸ ਸਟੋਰੇਜ 'ਤੇ ਗ੍ਰੈਜੂਏਟ ਕਰੋ।
ਉਦੇਸ਼ ਦੇ ਆਧਾਰ 'ਤੇ ਰਿਟੇਨਸ਼ਨ ਨਿਰਧਾਰਤ ਕਰੋ:
ਮਹੀਨੇ/ਕੁਆਰਟਰ ਨਾਲ partitions ਵਰਤੋ ਤਾਂ ਕਿ ਆਰਕਾਈਵ ਅਤੇ ਡਿਲੀਟਸ ਪ੍ਰਿਡਿਕਟੇਬਲ ਹੋਣ।
ਉਸ ਸਵਾਲਾਂ ਲਈ ਯੋਜਨਾ ਬਣਾਓ ਜੋ ਤੁਹਾਡਾ ਡੈਸ਼ਬੋਰਡ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਪੁੱਛੇਗਾ:
due_at ਅਤੇ status 'ਤੇ ਇੰਡੈਕਸ (ਅਤੇ ਸੰਭਵ ਤੌਰ 'ਤੇ queue/team)।breached_at (ਜਾਂ ਕਮਪਿਊਟ ਕੀਤਾ breach flag) ਅਤੇ date 'ਤੇ ਇੰਡੈਕਸ।(customer_id, due_at) ਵਰਗੇ ਕੰਪੋਜ਼ਿਟ ਇੰਡੈਕਸ।ਪ੍ਰਦਰਸ਼ਨ ਇੱਥੇ ਜਿੱਤਦਾ ਹੈ: ਆਪਣੇ ਟੌਪ 3–5 ਵਿਊਜ਼ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਸਟੋਰੇਜ ਬਣਾਓ, ਨਾ ਕਿ ਹਰ ਸੰਭਵ ਰਿਪੋਰਟ ਲਈ।
ਰੀਅਲ-ਟਾਈਮ ਬਰੀਚ ਡਿਟੈਕਸ਼ਨ ਬਹੁਤ ਹੱਦ ਤੱਕ ਇਹ ਗੱਲ ਹੈ: ਮਨੁੱਖੀ ਵਰਕਫਲੋਜ਼ (assigned, waiting on customer, reopened, transferred) ਨੂੰ ਏਸੇ ਤਰ੍ਹਾਂ SLA ਟਾਈਮਰ ਵਿੱਚ ਤਬਦੀਲ ਕਰੋ ਜੋ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹੋ।
ਪਹਿਲਾਂ ਉਹ ਘਟਨਾਵਾਂ ਪਰਿਭਾਸ਼ਤ ਕਰੋ ਜੋ ਹਰ ਟਿਕਟ ਜਾਂ ਰਿਕਵੇਸਟ ਟਾਈਪ ਲਈ SLA ਘੜੀ ਨੂੰ ਕੰਟਰੋਲ ਕਰਦੀਆਂ ਹਨ। ਆਮ ਪੈਟਰਨ:
ਇਨ੍ਹਾਂ ਘਟਨਾਵਾਂ ਤੋਂ ਇੱਕ due time ਦੀ ਗਣਨਾ ਕਰੋ। ਸਖ਼ਤ SLA ਲਈ ਇਹ “created_at + 2 hours” ਹੋ ਸਕਦਾ ਹੈ। ਕਾਰੋਬਾਰੀ ਘੰਟਿਆਂ ਵਾਲੇ SLA ਲਈ ਇਹ “2 business hours” ਹੋਵੇਗਾ, ਜਿਸ ਲਈ ਕੈਲੰਡਰ ਦੀ ਲੋੜ ਪਏਗੀ।
ਇੱਕ ਛੋਟਾ ਕੈਲੰਡਰ ਮੋਡੀਊਲ ਬਣਾਓ ਜੋ ਲਗਾਤਾਰ ਦੋ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਵੇ:
ਛੁੱਟੀਆਂ, ਕੰਮ ਦੇ ਘੰਟੇ ਅਤੇ ਟਾਈਮਜ਼ੋਨ ਇੱਕ ਹੀ ਥਾਂ 'ਤੇ ਰੱਖੋ ਤਾਂ ਕਿ ਹਰ SLA ਨਿਯਮ ਇੱਕੋ ਲਾਜਿਕ ਵਰਤੇ।
ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ due time ਹੋਵੇ, ਤਾਂ time remaining ਸਧਾਰਨ ਹੈ: due_time - now (ਜੇ ਲਾਗੂ ਹੋਵੇ ਤਾਂ ਬਿਜ਼ਨੇਸ ਮਿੰਟਾਂ ਵਿੱਚ)। ਫਿਰ ਬਰੀਚ ਰਿਸਕ ਥ੍ਰੈਸ਼ਹੋਲਡ ਪਰਿਭਾਸ਼ਤ ਕਰੋ ਜਿਵੇਂ “15 ਮਿੰਟਾਂ ਵਿੱਚ ਬਾਕੀ” ਜਾਂ “SLA ਦਾ <10% ਬਾਕੀ।” ਇਹ urgency ਬੈਜ ਅਤੇ ਅਲਰਟ ਰੂਟਿੰਗ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ।
ਤੁਸੀਂ ਕਰ ਸਕਦੇ ਹੋ:
ਪ੍ਰਯੋਗਿਕ ਹਾਈਬ੍ਰਿਡ: ਸਹੀਗਤੀ ਲਈ ਇਵੈਂਟ-ਡ੍ਰਿਵਨ ਅਪਡੇਟ ਅਤੇ ਸਮਾਂ-ਅਧਾਰਤ ਥ੍ਰੈਸ਼ਹੋਲਡ ਕੈਚ ਕਰਨ ਲਈ ਇੱਕ ਮਿੰਟ-ਸਤਰੀਅਕ ਟਿਕ।
ਅਲਰਟ ਉਹ ਸਥਾਨ ਹੈ ਜਿੱਥੇ ਤੁਹਾਡੀ SLA ਨਿਗਰਾਨੀ ਕਾਰਵਾਈ ਬਣਦੀ ਹੈ। ਲਕਸ਼ “ਵਧੇਰੇ ਨੋਟੀਫਿਕੇਸ਼ਨ” ਨਹੀਂ—ਇਹ ਸਹੀ ਵਿਅਕਤੀ ਨੂੰ ਸਹੀ ਕਾਰਵਾਈ ਕਰਨ ਲਈ ਸਮੇਤਲਿਕ ਤੌਰ 'ਤੇ ਲੈ ਜਾਣਾ ਹੈ।
ਛੋਟੇ ਸੈੱਟ ਦੇ ਅਲਰਟ ਟਾਈਪ ਵਰਤੋ ਜਿਨ੍ਹਾਂ ਦਾ ਸਪਸ਼ਟ ਉਦੇਸ਼ ਹੋਵੇ:
ਹਰ ਟਾਈਪ ਨੂੰ ਵੱਖ-ਵੱਖ urgency ਅਤੇ ਡਿਲਿਵਰੀ ਚੈਨਲ (ਚੈਟ ਲਈ warnings, paging ਲਈ confirmed breaches) ਨਾਲ ਮੈਪ ਕਰੋ।
ਰੂਟਿੰਗ ਡੇਟਾ-ਚਲਿਤ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ഹਾਰਡ-ਕੋਡ ਨਹੀਂ। ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ ਟੇਬਲ ਵਰਤੋਂ ਜਿਵੇਂ: service → owning team, ਫਿਰ ਸੋਧ ਲਗਾਓ:
ਇਸ ਨਾਲ “ਸਭ ਨੂੰ ਬਰਾਡਕਾਸਟ” ਕਰਨ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਮਲਿਕੀਅਤ ਦਿੱਸਦੀ ਰਹਿੰਦੀ ਹੈ।
ਇਨਸੀਡੈਂਟ ਰੈਸਪਾਂਸ ਦੌਰਾਨ SLA ਸਟੀਟ ਤੇਜ਼ੀ ਨਾਲ ਫਲਿੱਪ ਹੋ ਸਕਦੀ ਹੈ। ਡਿਡੁਪਲੀਕੇਟ ਲਈ ਇੱਕ ਸਥਿਰ ਕੀ ਵਰਤੋ ਜਿਵੇਂ (ticket_id, sla_rule_id, alert_type) ਅਤੇ ਲਗਾਓ:
ਇਕੱਠੇ ਹੋਏ ਕਈ warnings ਨੂੰ ਇੱਕ ਨਿਯਤ ਸਮੇਂ-ਵਾਰ ਸਾਰੰਸ਼ ਵਿੱਚ ਬੰਡਲ ਕਰਨ ਬਾਰੇ ਵੀ ਸੋਚੋ।
ਹਰ ਨੋਟੀਫਿਕੇਸ਼ਨ ਨੇ “ਕੀ, ਕਦੋਂ, ਕੌਣ, ਹੁਣ ਕੀ” ਦਾ ਜਵਾਬ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਜੇ ਕੋਈ 30 ਸਕਿੰਟਾਂ ਦੇ ਅੰਦਰ ਪੜ੍ਹ ਕੇ ਕਾਰਵਾਈ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਤਾਂ ਅਲਰਟ ਵਿੱਚ ਹੋਰ ਸੰਦਰਭ ਦੀ ਲੋੜ ਹੈ।
ਇੱਕ ਚੰਗਾ SLA ਡੈਸ਼ਬੋਰਡ ਚਾਰਟਾਂ ਬਾਰੇ ਘੱਟ ਅਤੇ ਕਿਸੇ ਨੂੰ ਇੱਕ ਮਿੰਟ ਵਿੱਚ ਫੈਸਲਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨ ਬਾਰੇ ਵੱਧ ਹੈ। UI ਤਿੰਨ سوالਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਡਿਜ਼ਾਈਨ ਕਰੋ: ਕੀ ਖਤਰੇ ਵਿੱਚ ਹੈ? ਕਿਉਂ? ਮੈਨੂੰ ਕੀ ਕਰਣਾ ਚਾਹੀਦਾ ਹੈ?
ਚਾਰ ਸਧਾਰਨ ਵਿਊਜ਼ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਹਰ ਇਕ ਦਾ ਸਪਸ਼ਟ ਉਦੇਸ਼ ਹੋਵੇ:
ਡਿਫਾਲਟ ਵਿਊ “breaching soon” 'ਤੇ ਧਿਆਨ ਰੱਖੋ, ਕਿਉਂਕਿ ਰੋਕਥਾਮ ਇਥੇ ਹੁੰਦੀ ਹੈ।
ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਕੁਝ ਛੋਟੇ ਪਰ ਵਾਸਤਵਿਕ ਫਿਲਟਰ ਦਿਓ:
ਫਿਲਟਰ ਹਰ ਯੂਜ਼ਰ ਲਈ sticky ਬਣਾਓ ਤਾਂ ਉਹ ਹਰ ਵਾਰੀ ਵਾਪਸ ਨਾ ਬਦਲਣਾ ਪਏ।
“breaching soon” ਦੇ ਹਰ ਰੋ ਵਿੱਚ ਇੱਕ ਛੋਟੀ, ਸਧਾਰਨ-ਅੰਗਰੇਜ਼ੀ ਵਿਆਖਿਆ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਉਦਾਹਰਣ:
ਇੱਕ “Details” ਡਰੌਅਰ ਜੋ SLA ਸਟੀਟ ਬਦਲਣਾਂ ਦੀ ਟਾਈਮਲਾਈਨ (started, paused, resumed, breached) ਦਿਖਾਏ, ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਗਣਨਾ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕੇ ਬਿਨਾਂ ਸ਼ੱਕ ਕੀਤੇ।
ਡਿਫਾਲਟ ਵਰਕਫਲੋ ਨੂੰ ਬਣਾਓ: review → open → act → confirm।
ਹਰ ਆਈਟਮ ਵਿੱਚ ਐਕਸ਼ਨ ਬਟਨ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਜੋ ਸੱਚਾਈ ਦੇ ਸਰੋਤ ਤੇ ਛੱਡਦੇ ਹਨ:
ਜੇ ਤੁਸੀਂ quick actions (assign, change priority, add note) ਸਹਾਇਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਸਿਰਫ ਓਥੇ ਦਿਖਾਓ ਜਿੱਥੇ ਤੁਸੀਂ ਨਿਰੰਤਰ ਤੌਰ 'ਤੇ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਬਦਲਾਅ ਦੀ ਆਡਿਟ ਲਿਖੋ।
ਇੱਕ ਰੀਅਲ-ਟਾਈਮ SLA ਮਾਨੀਟਰਨਿੰਗ ਐਪ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰਦਰਸ਼ਨ, ਇਨਸੀਡੈਂਟ ਅਤੇ ਗਾਹਕ ਪ੍ਰਭਾਵ ਲਈ ਸਿਸਟਮ ਆਫ਼ ਰਿਕਾਰਡ ਬਣ ਜਾਂਦੀ ਹੈ। ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਇਸਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ-ਗ੍ਰੇਡ ਸਮਝੋ: ਕਿਸੇ ਨੂੰ ਕੀ ਕਰਨ ਦੀ ਆਗਿਆ ਹੈ ਸੀਮਾ ਕਰੋ, ਗਾਹਕ ਡਾਟਾ ਦੀ ਰੱਖਿਆ ਕਰੋ, ਅਤੇ ਇਹ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਕਿ ਡਾਟਾ ਕਿਵੇਂ ਸਾਂਭਿਆ ਅਤੇ ਹਟਾਇਆ ਜਾਂਦਾ ਹੈ।
ਸਧਾਰਨ, ਸਪਸ਼ਟ ਪਰਮੀਸ਼ਨ ਮਾਡਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਲੋੜ 'ਤੇ ਹੀ ਵਧਾਓ। ਆਮ ਸੈਟਅਪ:
ਪਰਮੀਸ਼ਨ ਨੂੰ ਵਰਕਫਲੋਜ਼ ਨਾਲ ਮਿਲਾਉ। ਉਦਾਹਰਣ: ਇਕ ਓਪਰੇਟਰ incident status ਅਪਡੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਸਿਰਫ ਐਡਮਿਨ SLA ਟਾਈਮਰ ਜਾਂ ਐਸਕਲੇਸ਼ਨ ਨਿਯਮ ਬਦਲ ਸਕਦਾ ਹੈ।
SLA ਮਾਨੀਟਰਨਿੰਗ ਵਿੱਚ ਅਕਸਰ ਗਾਹਕ ਪਛਾਣकर्ता, ਕੰਟਰੈਕਟ ਟੀਅਰ ਅਤੇ ਟਿਕਟ ਸਮੱਗਰੀ ਸ਼ਾਮਿਲ ਹੁੰਦੀ ਹੈ। ਨਜ਼ਰ ਘਟਾਓ:
ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਅਕਸਰ ਕਮਜ਼ੋਰ ਪਾਸਾ ਹੁੰਦੇ ਹਨ:
ਸਿਸਟਮ 'ਤੇ ਮਹੀਨਿਆਂ ਦਾ ਇਤਿਹਾਸ ਇਕੱਠਾ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਨੀਤੀਆਂ ਲਿਖੋ:
ਇਹ ਨਿਯਮ ਦਰਜ ਕਰੋ ਅਤੇ UI ਵਿੱਚ ਦਰਸਾਓ ਤਾਂ ਟੀਮ ਨੂੰ ਪਤਾ ਹੋਵੇ ਕਿ ਸਿਸਟਮ ਕੀ ਰੱਖਦਾ ਹੈ—ਅਤੇ ਕਿੰਨੀ ਦੇਰ ਤਕ।
SLA ਮਾਨੀਟਰਨਿੰਗ ਐਪ ਦੀ ਟੈਸਟਿੰਗ "UI ਲੋਡ ਹੁੰਦੀ ਹੈ" ਵਾਲੀ ਜਾਂਚ ਤੋਂ ਘੱਟ ਤੇ "ਕੀ ਟਾਈਮਰ, ਪਾਜ਼, ਤੇ ਥ੍ਰੈਸ਼ਹੋਲਡ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਹਰ ਵਾਰੀ ਗਣੇ ਜਾਂਦੇ ਹਨ" ਵਾਲੀ ਜਾਂਚ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇੱਕ ਛੋਟੀ ਗਲਤੀ (ਟਾਈਮਜ਼ੋਨ, ਕਾਰੋਬਾਰੀ ਘੰਟੇ, ਗੁੰਮ ਇਵੈਂਟ) ਸ਼ੋਰ ਵਾਲੇ ਅਲਰਟ ਜਾਂ ਗੰਭੀਰਤਾ ਨਾਲ ਬਰੀਚ ਹੋਣ ਜਿਹੀ ਗਲਤੀ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ।
ਆਪਣੀਆਂ SLA ਨੀਤੀਆਂ ਨੂੰ ਸਪਸ਼ਟcenarioਾਂ ਵਿੱਚ ਬਦਲੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ end-to-end ਸਿਮੁਲੇਟ ਕਰ ਸਕੋ। ਸਮਾਨ ਅਤੇ ਔਖੇ ਏਜ ਕੇਸ ਸ਼ਾਮਿਲ ਕਰੋ:
ਪ੍ਰਮਾਣੀਕ ਬਣਾਓ ਕਿ ਤੁਹਾਡੀ ਬਰੀਚ ਡਿਟੈਕਸ਼ਨ ਲਾਜਿਕ ਸਾਫ਼-ਸੁਥਰੇ ਡੈਮੋ ਡੇਟਾ ਤੋਂ ਇਲਾਵਾ ਹਕੀਕਤੀ ਓਪਰੇਸ਼ਨਲ ਗੰਦਗੀ ਹੇਠ ਵੀ ਸਥਿਰ ਰਹਿੰਦੀ ਹੈ।
ਰੀਪਲੇਅਬਲ ਇਵੈਂਟ ਫਿਕਸਚਰ ਬਣਾਓ: ਛੋਟਾ ਲਾਇਬਰੇਰੀ “ਇਨਸੀਡੈਂਟ ਟਾਈਮਲਾਈਨ” ਜੋ ਤੁਸੀਂ ingestion ਅਤੇ calculation ਦੇ ਰਾਹੋਂ ਦੁਬਾਰਾ ਚਲਾ ਸਕੋ ਜਦੋਂ ਵੀ ਤੁਸੀਂ ਲਾਜਿਕ ਬਦਲਦੇ ਹੋ। ਇਹ ਸਮੇਂ-ਸਮੀਖਿਆ ਦੀ ਪੁਸ਼ਟੀ ਅਤੇ ਰਿਗ੍ਰੈਸ਼ਨ ਰੋਕਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਫਿਕਸਚਰ ਨੂੰ Git ਵਿੱਚ ਵਰਜਨ ਕਰੋ ਅਤੇ ਉਮੀਦ ਕੀਤੇ ਨਤੀਜਿਆਂ ਨੂੰ ਸ਼ਾਮਿਲ ਕਰੋ: ਕਮਪਿਊਟ ਕੀਤਾ ਗਿਆ remaining time, breach moment, pause windows, ਅਤੇ alert triggers।
SLA ਮਾਨੀਟਰ ਨੂੰ ਕਿਸੇ ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਸਟਮ ਦੀ ਤਰ੍ਹਾਂ ਮਾਨੋ ਅਤੇ ਆਪਣੇ ਸਵੈ-ਹੈਲਥ ਸਿਗਨਲ ਜੋੜੋ:
ਜੇ ਤੁਹਾਡਾ ਡੈਸ਼ਬੋਰਡ “ਗ੍ਰੀਨ” ਦਿਖਾ ਰਿਹਾ ਹੈ ਪਰ ਇਵੈਂਟਜ਼ ਫਸੇ ਹੋਏ ਹਨ, ਤਾਂ ਭਰੋਸਾ ਤੇਜ਼ੀ ਨਾਲ ਘਟ ਜਾਵੇਗਾ।
ਆਮ ਫੇਲ ਮੋਡ ਲਈ ਇੱਕ ਛੋਟਾ, ਸਪਸ਼ਟ ਰਨਬੁੱਕ ਲਿਖੋ: stuck consumers, schema changes, upstream outages, ਅਤੇ backfills। ਉਸ ਵਿੱਚ ਇਹ ਵੀ ਲਿਖੋ ਕਿ ਇਵੈਂਟਸ ਨੂੰ ਸਰਵਿੰਞ-ਤਰੀਕੇ ਨਾਲ ਕਿਵੇਂ ਦੁਬਾਰਾ ਚਲਾਇਆ ਅਤੇ ਟਾਈਮਰ ਨੂੰ ਮੁੜ-ਗਣਨਾ (ਕਿਹੜਾ ਅੰਤਰਾਲ, ਕਿਹੜੇ ਟੇਨੈਂਟ, ਅਤੇ ਡਬਲ-ਅਲਰਟਿੰਗ ਤੋਂ ਬਚਣ ਦੇ ਕਦਮ)। ਇਸਨੂੰ ਆਪਣੀ ਅੰਦਰੂਨੀ ਡੌਕਸ ਹੱਬ ਜਾਂ ਇੱਕ ਸਧਾਰਨ ਪੇਜ /runbooks/sla-monitoring 'ਤੇ ਲਿੰਕ ਕਰੋ।
SLA ਮਾਨੀਟਰਿੰਗ ਐਪ ਸ਼ਿਪ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਉਤਪਾਦ ਵਜੋਂ ਟ੍ਰੀਟ ਕਰੋ, ਇੱਕ ਇਕ-ਵਾਰੀ ਪ੍ਰੋਜੈਕਟ ਵਜੋਂ ਨਹੀਂ। ਇੱਕ ਮਿਨੀਮਲ ਵਾਇਬਲ ਰਿਲੀਜ਼ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ end-to-end ਲੂਪ ਨੂੰ ਸਾਬਿਤ ਕਰੇ: ingest → evaluate → alert → ਇਸਦਾ ਫਾਇਦਾ ਵਿਅਕਤੀ ਨੇ ਲਿਆ।
ਇੱਕ ਡਾਟਾ ਸਰੋਤ, ਇੱਕ SLA ਕਿਸਮ, ਅਤੇ ਬੁਨਿਆਦੀ ਅਲਰਟ ਚੁਣੋ। ਉਦਾਹਰਣ ਲਈ: single ticketing system feed ਦੀ ਵਰਤੋਂ ਕਰਕੇ “first response time” ਮਾਨੀਟਰ ਕਰੋ, ਅਤੇ ਟਾਇਮਰ ਦੋ ਬਾਰੇ ਖ਼ਤਰਾ ਹੋਣ 'ਤੇ ਅਲਰਟ ਭੇਜੋ (ਸਿਰਫ ਬਰੀਚ ਹੋਣ ਤੋਂ ਬਾਅਦ ਨਹੀਂ)। ਇਹ ਸਕੋਪ ਤੰਗ ਰੱਖਦਾ ਹੈ ਅਤੇ ਮੁਸ਼ਕਲ ਹਿੱਸਿਆਂ ਨੂੰ ਵੈਰੀਫਾਈ ਕਰਨ ਦੇ ਸਮੇਂ-ਸਿਖਣ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ: ਟਾਈਮਸਟੈਂਪ, ਟਾਈਮ ਵਿਂਡੋ, ਅਤੇ ਮਲਿਕੀਅਤ।
MVP ਸਥਿਰ ਹੋਣ 'ਤੇ, ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ ਵਧਾਓ: ਦੂਜਾ SLA ਕਿਸਮ ਜੋੜੋ (ਉਦਾਹਰਣ: resolution), ਫਿਰ ਦੂਜਾ ਡਾਟਾ ਸਰੋਤ, ਫਿਰ ਰਹਿਣ ਵਾਲੇ ਵਰਕਫ਼ਲੋਜ਼।
ਸ਼ੁਰੂ ਵਿੱਚ dev, staging, ਅਤੇ production ਸੈਟਅਪ ਕਰੋ। ਸਟੇਜਿੰਗ ਨੇ ਪ੍ਰੋਡਕਸ਼ਨ ਕੰਫਿਗਰੇਸ਼ਨ (ਇੰਟਿਗ੍ਰੇਸ਼ਨ, ਸ਼ੈਡਿਊਲ, ਐਸਕਲੇਸ਼ਨ ਪਾਥ) ਨੂੰ ਮਿਰਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਪਰ ਅਸਲੀ ਰਿਸਪੋੰਡਰਾਂ ਨੂੰ ਸੂਚਿਤ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ।
Feature flags ਵਰਤੋ:
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਬਨਾਉਂਦੇ ਹੋ, ਤਾਂ snapshots ਅਤੇ rollback ਇੱਥੇ ਲਾਭਦਾਇਕ ਹੁੰਦੇ ਹਨ: ਤੁਸੀਂ UI ਅਤੇ ਨਿਯਮ ਬਦਲਾਅ ਨੂੰ ਪਾਇਲਟ ਤੇ ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਜੇ ਅਲਰਟ ਸ਼ੋਰ ਕਰਨ ਲੱਗਣ ਤਾਂ ਤੇਜ਼ੀ ਨਾਲ ਵਾਪਸ ਲੈ ਸਕਦੇ ਹੋ।
ਛੋਟੀਆਂ, ਪ੍ਰਾਇੋਗਿਕ ਸੈਟਅਪ ਡੌਕਸ ਲਿਖੋ: “ਡਾਟਾ ਸਰੋਤ ਜੁੜੋ”, “SLA ਬਣਾਓ”, “ਅਲਰਟ ਟੈਸਟ ਕਰੋ”, “ਤੁਸੀਂ ਸੂਚਿਤ ਹੋਣ 'ਤੇ ਕੀ ਕਰੋ।” ਉਨ੍ਹਾਂ ਨੂੰ ਪ੍ਰੋਡਕਟ ਦੇ ਨੇੜੇ ਰੱਖੋ, ਜਿਵੇਂ ਅੰਦਰੂਨੀ ਪੇਜ /docs/sla-monitoring।
ਇਨਿਸ਼ੀਅਲ ਗ੍ਰਹਿਣ ਤੋਂ ਬਾਅਦ, ਉਹ ਸੁਧਾਰ ਤਰਜੀਹ ਦੇਵੋ ਜੋ ਭਰੋਸਾ ਵਧਾਉਂਦੇ ਅਤੇ ਸ਼ੋਰ ਘਟਾਉਂਦੇ:
ਅਸਲ ਇਨਸੀਡੈਂਟਾਂ 'ਤੇ ਆਧਾਰਿਤ ਇਟਰੇਟ ਕਰੋ: ਹਰ ਅਲਰਟ ਤੁਹਾਨੂੰ ਦੱਸੇਗਾ ਕਿ ਕੀ ਆਟੋਮੇਟ ਕਰਨਾ ਹੈ, ਕੀ ਸਪਸ਼ਟ ਕਰਨਾ ਹੈ, ਜਾਂ ਕੀ ਹਟਾਉਣਾ ਹੈ।
ਇੱਕ SLA ਮਾਨੀਟਰਨਿੰਗ ਲਕਸ਼ ਇੱਕ ਮਾਪਯੋਗ ਬਿਆਨ ਹੁੰਦਾ ਹੈ ਜੋ ਇਸ ਗੱਲ ਨੂੰ ਪਰਿਭਾਸ਼ਤ ਕਰਦਾ ਹੈ:
ਇਸਨੂੰ ਅਜਿਹੇ ਉਦੇਸ਼ ਵਜੋਂ ਲਿਖੋ ਜੋ ਪਰਖੇ ਜਾ ਸਕਣ: “ਪੌਟੇਂਸ਼ਲ ਬਰੀਚਾਂ ਨੂੰ X ਸਕਿੰਟਾਂ ਵਿੱਚ ਪਛਾਣੋ ਅਤੇ on-call ਨੂੰ Y ਮਿੰਟਾਂ ਵਿੱਚ ਸੂਚਿਤ ਕਰੋ।”
“ਰੀਅਲ-ਟਾਈਮ” ਨੂੰ ਤਕਨੀਕੀ ਸਮਰੱਥਾ ਦੀ ਬਜਾਏ ਆਪਣੀ ਟੀਮ ਦੀ ਰਿਸਪਾਂਸ ਸਮਰੱਥਾ ਦੇ ਆਧਾਰ 'ਤੇ ਪਰਿਭਾਸ਼ਤ ਕਰੋ.
ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇੱਕ (ਇਵੈਂਟ → ਗਣਨਾ → ਅਲਰਟ/ਡੈਸ਼ਬੋਰਡ) ਤਿਆਰ ਕਰੋ ਅਤੇ ਉਸ ਦੁਆਰਾ ਡਿਜ਼ਾਈਨ ਕਰੋ।
ਉਹ ਗਾਹਕ-ਮੁੱਖ ਵਾਅਦੇ ਟ੍ਰੈਕ ਕਰੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਬਰੀਚ ਕਰ ਸਕਦੇ ਹੋ (ਅਤੇ ਸ਼ਾਇਦ ਕਰੈਡਿਟ ਦੇ ਜ਼ੁਰੀਮੇ ਹੋ ਸਕਦੇ ਹਨ), ਆਮ ਤੌਰ 'ਤੇ:
ਅਕਸਰ ਟੀਮਾਂ ਇੱਕ ਆਮ ਅੰਦਰੂਨੀ ਵੀ ਟ੍ਰੈਕ ਕਰਦੀਆਂ ਹਨ ਜੋ SLA ਤੋਂ ਕਠੋਰ ਹੁੰਦੀ ਹੈ। ਜੇ ਦੋਹਾਂ ਹਨ, ਤਾਂ ਦੋਹਾਂ ਨੂੰ ਸਟੋਰ ਤੇ ਡਿਸਪਲੇ ਕਰੋ ਤਾਂ ਕਿ ਓਪਰੇਟਰ ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਕਾਰਵਾਈ ਕਰਨ ਲਈ ਸੂਚਿਤ ਕਰ ਸਕਣ ਪਰ ਕਾਂਟ੍ਰੈਕਚੁਅਲ ਪਾਲਣਾ ਵੀ ਸਹੀ ਰਿਪੋਰਟ ਹੋਵੇ।
SLA ਫੇਲ੍ਹ ਆਮ ਤੌਰ 'ਤੇ ਪਰਿਭਾਸ਼ਾ ਦੀ ਗਲਤੀ ਹੁੰਦੇ ਹਨ। ਸਪਸ਼ਟ ਕਰੋ:
ਫਿਰ ਇਹਨਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਨਿਯਮਾਂ ਵਜੋਂ ਐਨਕੋਡ ਕਰੋ ਅਤੇ ਉਦਾਹਰਣ ਟਾਈਮਲਾਈਨ ਦੀ ਲਾਇਬਰੇਰੀ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਦੀ ਟੈਸਟਿੰਗ ਕਰ ਸਕੋ।
SLA ਗਣਨਾਵਾਂ ਵਿੱਚ ਇੱਕ ਸਥਿਰ ਕੈਲੰਡਰ ਨਿਯਮ ਸੈੱਟ ਪਰਿਭਾਸ਼ਤ ਕਰੋ:
ਇੱਕ ਦੁਬਾਰਾ-ਉਪਯੋਗ ਕੈਲੰਡਰ ਮੋਡੀਊਲ ਬਣਾਓ ਜੋ ਇਹ ਦੋ ਸਵਾਲ ਜਵਾਬ ਦੇ ਸਕੇ:
ਹਰੇਕ ਖੇਤਰ ਲਈ ਇਕ “system of record” ਚੁਣੋ ਅਤੇ ਫੈਸਲਾ ਕਰੋ ਕਿ ਜਦੋਂ ਸਿਸਟਮ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ ਤਾਂ ਕਿਹੜਾ ਜਿੱਤਦਾ ਹੈ।
ਆਮ ਸਰੋਤ:
ਨੀਅਰ-ਰੀਅਲ-ਟਾਈਮ ਲਈ ਨੂੰ ਤਰਜੀਹ ਦਿਓ; ਮਿਲਾਪ ਲਈ ਜੋੜੋ।
ਅਘੋਜ, ਉਹ ਘਟਨਾਂ ਕੈਪਚਰ ਕਰੋ ਜੋ SLA ਘੜੀ ਨੂੰ ਸ਼ੁਰੂ, ਰੋਕ ਜਾਂ ਬਦਲਦੀਆਂ ਹਨ:
ਨਾਲ ਹੀ ਐਸੇ “ਲੋਕ ਭੁਲ ਜਾਂਦੇ” ਇਵੈਂਟ ਵੀ ਯੋਦ ਰੱਖੋ ਜਿਵੇਂ ਕਿ ਬਿਜ਼ਨੇਸ ਕੈਲੰਡਰ ਅਪਡੇਟ, ਟਾਈਮਜ਼ੋਨ ਬਦਲਾਅ ਅਤੇ ਛੁੱਟੀਆਂ—ਇਹ ਬਿਨਾਂ ਕਿਸੇ ਟਿਕਟ ਐਕਟਿਵਿਟੀ ਦੇ ਵੀ due times ਨੂੰ ਬਦਲ ਸਕਦੇ ਹਨ।
ਇੱਕ ਸਧਾਰਣ ਪੰਜ-ਬਲੌਕ ਪਾਈਪਲਾਈਨ ਵਰਤੋ:
ਇੰਜੈਸਟ ਵਿੱਚ SLA ਲਾਜਿਕ ਨਾ ਰੱਖੋ ਅਤੇ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਭਾਰੀ ਗਣਨਾਵਾਂ ਨਾ ਚਲਾਓ। ਡੇਟਾ ਗੁਣਵੱਤਾ ਅਤੇ ਅਲਰਟ ਉਪਯੋਗਿਤਾ ਤੇ ਭਰੋਸਾ ਹੋਣ ਤੱਕ ਸਧਾਰਨ ਡਿਪਲੋਇਮੈਂਟ ਰੱਖੋ।
ਉਭਰਦੇ ਤੇ ਮੋਟੇ ਤੌਰ 'ਤੇ ਦੋ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਹਨ:
ਪ੍ਰਯੋਗਿਕ ਰਵੱਈਆ: ਸ਼ੁਰੂਆਤ 'ਤੇ N ਮਿੰਟਾਂ ਵਾਲੀ ਰੀਕੈਲਕੁਲੇਸ਼ਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੇ ਨਿਯਮ ਸਟ੍ਰੀਮਿੰਗ 'ਤੇ ਲਿਜਾਓ।
ਅਲਰਟਿੰਗ ਨੂੰ ਇੱਕ ਵਰਕਫ਼ਲੋ ਵਜੋਂ ਦੇਖੋ, ਫਾਇਰਹੋਜ਼ ਨਹੀਂ:
(work_item_id, sla_rule_id, alert_type) ਉੱਤੇ ਡਿਡੁਪਲੀਕੇਟ ਕਰੋ ਅਤੇ ਸਿਰਫ ਸਟੇਟ ਟ੍ਰਾਂਜ਼ਿਸ਼ਨਾਂ 'ਤੇ ਸੂਚਿਤ ਕਰੋ, ਇੱਕ ਛੋਟੀ cooldown ਵਿੰਡੋ ਲਗਾਓ.ਹਰ ਅਲਰਟ ਵਿੱਚ ਸਮਾ, ਮਾਲਿਕ/ഓਨ-ਕਾਲ, ਨਿਕਟਮਤ ਕਾਰਵਾਈ ਅਤੇ /tickets/{id} ਅਤੇ /sla/tickets/{id} ਵਰਗੇ ਗੱਲਾਂ ਸ਼ਾਮਿਲ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।