ਉਦੇਸ਼ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੇ ਉਪਭੋਗਤਾ ਤੁਹਾਨੂੰ ਦੱਸਣ ਤੋਂ ਪਹਿਲਾਂ ਤੁਸੀਂ ਜਾਣ ਲਓ ਕਿ ਤੁਹਾਡਾ ਸਿਸਟਮ ਅਸਥਿਰ ਹੈ। ਚੰਗੀ observability ਤੁਹਾਨੂੰ ਉਹ ਸਵਾਲ ਪੁੱਛਣ ਦੇ ਸਮਰੱਥ ਬਣਾਏ ਜੋ ਤੁਸੀਂ ਅਨੁਮਾਨ ਨਹੀਂ ਕਰ ਸਕੇ, ਨਾ ਕਿ ਸਿਰਫ ਇੱਕ ਨਿਰਧਾਰਿਤ ਡੈਸ਼ਬੋਰਡ ਦਾ ਜਾਂਚ ਕਰਨਾ। ਇੱਕ tech lead ਦੇ ਤੌਰ ਤੇ, ਤੁਸੀਂ ਇਸ ਨੂੰ ਘਟਨਾ ਤੋਂ ਪਹਿਲਾਂ ਸਥਾਪਤ ਕਰਦੇ ਹੋ, ਨਾ ਕਿ ਇਸ ਦੌਰਾਨ।
ਉਪਭੋਗਤਾ ਜੋ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ ਉਸ ਤੇ ਪੰਨਾ ਕਰੋ, ਅੰਦਰੂਨੀ jitter ਤੇ ਨਹੀਂ। SLOs ਤੇ alerts ਨੂੰ anchor ਕਰੋ: error rate, latency (p95/p99), ਅਤੇ availability। CPU ਵਿਚ ਇੱਕ spike ਘਟਨਾ ਨਹੀਂ ਹੈ; 2% ਉਪਭੋਗਤਾਵਾਂ ਲਈ checkout ਫਸ ਜਾਣਾ ਹੈ।
| Alert on | ਪੰਨਾ ਨਾ ਕਰੋ |
|---|---|
| Error rate SLO ਨੂੰ ਭੰਗ ਕਰਦੀ ਹੈ | ਸਿੰਗਲ CPU spike |
| p99 latency ਬਜਟ ਤੋਂ ਵੱਧ | ਇੱਕ ਹੌਲੀ ਬੇਨਤੀ |
| Failed health checks | Disk 60% ਤੇ |
ਹਰ alert ਜ਼ਰੂਰੀ, ਵਾਸਤਵਿਕ, ਅਤੇ ਕਾਰਜਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ — ਇਹ ਆਖਦਾ ਹੈ ਕਿ ਕੀ ਗਲਤ ਹੈ ਅਤੇ ਅਗਲੀ ਪੜਾਈ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। Alerts ਜੋ ਲਗਾਤਾਰ ਆਉਂਦੇ ਹਨ ਉਹ ਟੀਮ ਨੂੰ ਉਹਨਾਂ ਨੂੰ ਨਿਰਲੱਖ ਕਰਨ ਲਈ ਸਿਖਾਉਂਦੇ ਹਨ; alert fatigue ਉਹ ਹੈ ਜਿਸ ਤਰਾਂ ਅਸਲੀ ਘਟਨਾਵਾਂ ਮਿੱਸ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। Health checks ਅਤੇ dashboards ਜੋਡ਼ੋ ਜੋ ਇੱਕ ਨਜ਼ਰ ਵਿਚ golden signals ਦਿਖਾਉਂਦੇ ਹਨ।
ਟੀਮਾਂ ਜੋ ਸਿਰਫ ਘਟਨਾ ਤੋਂ ਬਾਅਦ ਅਵਲੋਕਨ ਕਰਦੀਆਂ ਹਨ ਅੰਧੇ ਉਡਣ ਹਨ: ਉਹ ਗੁੱਸੇ ਕਸਟਮਾਂ ਤੋਂ outages ਬਾਰੇ ਸਿਖਦੀਆਂ ਹਨ ਅਤੇ ਅਨੁਮਾਨ ਦੇ ਨਾਲ debug ਕਰਦੀਆਂ ਹਨ। ਅਗਾਂਮ observability ਵਿਚ ਨਿਵੇਸ਼ 3 a.m. ਦੇ ਰਹੱਸਿਆਂ ਨੂੰ 5-ਮਿੰਟ ਦਾ diagnosis ਬਣਾ ਦਿੰਦਾ ਹੈ, downtime ਨੂੰ ਸੁੰਗੜਦਾ ਹੈ, ਅਤੇ ਟੀਮ ਨੂੰ firefight ਦੀ ਬਜਾਏ ship ਕਰਨ ਲਈ ਅਜ਼ਾਦ ਕਰਦਾ ਹੈ।