ਛੋਟੇ ਕਾਰੋਬਾਰ ਐਪਾਂ ਲਈ ਆਡਿਟ ਟਰੇਲ: ਕੀ ਲੌਗ ਅਤੇ ਕਿਵੇਂ ਪੁੱਛਗਿੱਛ

ਆਡਿਟ ਟਰੇਲ ਕੀ ਹੁੰਦੀ ਹੈ ਅਤੇ ਛੋਟੀ ਟੀਮਾਂ ਨੂੰ ਕਿਉਂ ਲੋੜ ਹੈ

ਆਡਿਟ ਟਰੇਲ ਤੁਹਾਡੇ ਐਪ ਵਿੱਚ ਹੋਈਆਂ ਮਹੱਤਵਪੂਰਨ ਕਾਰਵਾਈਆਂ ਦਾ ਇਤਿਹਾਸ ਹੁੰਦੀ ਹੈ, ਇਸ ਤਰੀਕੇ ਨਾਲ ਰਿਕਾਰਡ ਕੀਤੀ ਗਈ ਕਿ ਇਹ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇ ਸਕੇ: ਕਿਸ ਨੇ ਕੀਤਾ, ਕੀ ਬਦਲਾ, ਇਹ ਕਦੋਂ ਹੋਇਆ, ਅਤੇ ਇਸਦਾ ਪ੍ਰਭਾਵ ਕੀ ਸੀ। ਇਸਨੂੰ ਇੱਕ ਰਸੀਦ ਵਾਂਗ ਸੋਚੋ ਜੋ ਐਡਮਿਨ ਅਤੇ ਯੂਜ਼ਰ ਗਤੀਵਿਧੀ ਲਈ ਰੱਖੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਜੋ ਬਾਅਦ ਵਿੱਚ ਬਿਨਾਂ ਅਨੁਮਾਨ ਲਗਾਏ ਦੱਸ ਸਕੋ ਕਿ ਕੀ ਹੋਇਆ।

ਇਹ ਡੀਬੱਗ ਲੌਗ ਤੋਂ ਵੱਖਰਾ ਹੈ। ਡੀਬੱਗ ਲੌਗ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਬੱਗਸ ਠੀਕ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ (ਗਲਤੀਆਂ, ਸਟੈਕ ਟਰੇਸ, ਪ੍ਰਦਰਸ਼ਨ)। ਆਡਿਟ ਲੌਗ ਜ਼ਿੰਮੇਵਾਰੀ ਅਤੇ ਸਹਾਇਤਾ ਲਈ ਹੁੰਦੇ ਹਨ। ਇਹ ਇੱਕਸਾਰ, ਖੋਜਯੋਗ ਅਤੇ ਨਿਰਧਾਰਤ ਅੱਧੀਅਰ (retention) ਲਈ ਰੱਖੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ।

ਛੋਟੀ ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਲਾਜ਼ਮੀ ਕਾਰਨਾਂ ਕਰਕੇ ਆਡਿਟ ਟਰੇਲ ਸ਼ਾਮਲ ਕਰਦੀਆਂ ਹਨ:

• ਸਪੋਰਟ: “ਮੈਂ ਇਸ ਪ੍ਰੋਜੈਕਟ ਤੱਕ ਕਿਉਂ ਪਹੁੰਚ ਨਹੀਂ ਕਰ ਸਕਦਾ?” ਜਾਂ “ਇੰਵੇਸ ਟੇਸਟ ਦੀ ਸਥਿਤੀ ਕਿਸਨੇ ਬਦਲੀ?”
• ਵਿਵਾਦ: ਇਹ ਸਾਬਤ ਕਰਨ ਲਈ ਕਿ ਕੋਈ ਕਾਰਵਾਈ ਹੋਈ ਸੀ ਅਤੇ ਕਿਸਨੇ ਕੀਤੀ
• ਗਲਤੀਆਂ: ਕੁਝ ਟੁੱਟਣ ਤੋਂ ਪਹਿਲਾਂ ਆਖਰੀ ਸਹੀ ਸੈਟਿੰਗ ਤੇਜ਼ੀ ਨਾਲ ਲੱਭਣ ਲਈ
• ਬੁਨਿਆਦੀ ਨਿਯੰਤਰਣ: ਗਾਹਕ ਦੀਆਂ ਉਮੀਦਾਂ, ਸਧਾਰਨ ਸੁਰੱਖਿਆ ਸਮੀਖਿਆਵਾਂ, ਅੰਤਰ-ਪਾਰਟੀ ਜਵਾਬਦੇਹੀ
• ਵਿਜ਼ੀਬਿਲਟੀ: ਰੋਲ ਬਦਲਣਾਂ ਅਤੇ ਐਕਸਪੋਰਟ ਵਰਗੀਆਂ ਐਡਮਿਨ ਕਾਰਵਾਈਆਂ ਦੀ ਟਰੈਕਿੰਗ

ਆਡਿਟ ਟਰੇਲ ਆਪਣੇ ਆਪ ਵਿੱਚ ਕੋਈ ਸੁਰੱਖਿਆ ਟੂਲ ਨਹੀਂ ਹੈ। ਇਹ ਬੁਰੇ ਕਿਰਦਾਰ ਨੂੰ ਰੋਕੇਗਾ ਨਹੀਂ, ਅਤੇ ਆਪਣੇ ਆਪ ਧੋਖਾਧੜੀ ਪਤਾ ਨਹੀਂ ਲਗਾਵੇਗਾ। ਜੇ ਤੁਹਾਡੇ ਅਧਿਕਾਰ ਗਲਤ ਹਨ, ਲੌਗ ਸਿਰਫ਼ ਦਰਸਾਏਗਾ ਕਿ ਗਲਤ ਗੱਲ ਹੋਈ। ਅਤੇ ਜੇ ਕੋਈ ਲੌਗਾਂ ਨੂੰ ਸੋਧ ਜਾਂ ਮਿਟਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਉਨ੍ਹਾਂ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ ਐਕਸੈੱਸ ਕੰਟਰੋਲ ਅਤੇ ਆਡਿਟ ਡਾਟਾ ਦੀ ਰੱਖਿਆ ਦੀ ਲੋੜ ਹੈ।

ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਕੀਤੇ ਜਾਣ 'ਤੇ, ਇੱਕ ਆਡਿਟ ਟਰੇਲ ਤੁਹਾਨੂੰ ਠੰਢੇ ਮਨ ਨਾਲ ਤੇਜ਼ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਕੁਝ ਗਲਤ ਹੁੰਦਾ ਹੈ, ਬਿਨਾਂ ਹਰ ਘਟਨਾ ਨੂੰ ਟੀਮ-ਵਿਆਪਕ ਜਾਂਚ ਵਿੱਚ ਬਦਲੇ।

ਉਹ ਸਵਾਲ ਜਿਨ੍ਹਾਂ ਦਾ ਤੁਹਾਡੇ ਆਡਿਟ ਟਰੇਲ ਨੂੰ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ

ਆਡਿਟ ਟਰੇਲ ਹੀ ਉਪਯੋਗੀ ਹੈ ਜੇ ਇਹ ਅਸਲ ਸਵਾਲਾਂ ਦਾ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੇਵੇ। ਕੁਝ ਵੀ ਲੌਗ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ ਸਵਾਲ ਲਿਖੋ ਜੋ ਤੁਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਪੁੱਛੋਗੇ ਜਦੋਂ ਕੁੱਝ ਟੁੱਟੇ, ਗਾਹਕ ਸ਼ਿਕਾਇਤ ਕਰੇ, ਜਾਂ ਸੁਰੱਖਿਆ ਸਮੀਖਿਆ ਆਵੇ।

ਉਸ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਉਹ ਕਾਰਵਾਈਆਂ ਚੁਣ ਕੇ ਜੋ ਖਤਰਾ ਜਾਂ ਗਲਬ੍ਰਹਮ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ। ਪੈਸੇ, ਪਹੁੰਚ, ਡੇਟਾ ਜਾਂ ਭਰੋਸੇ ਨਾਲ ਜੁੜੀਆਂ ਘਟਨਾਵਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ। ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਹਮੇਸ਼ਾ ਹੋਰ ਜੋੜ ਸਕਦੇ ਹੋ, ਪਰ ਤੁਸੀਂ ਉਸ ਇਤਿਹਾਸ ਨੂੰ ਮੁੜ ਬਣਾਉ ਨਹੀਂ ਸਕਦੇ ਜੋ ਤੁਸੀਂ ਕਦੇ ਕੈਪਚਰ ਨਹੀਂ ਕੀਤਾ।

ਇਕ ਵਹੀਵਟ ਸ਼ੁਰੂਆਤੀ ਸੈੱਟ ਆਮਤੌਰ 'ਤੇ شامل ਹੁੰਦਾ ਹੈ:

• ਸਾਈਨ-ਇਨ ਗਤੀਵਿਧੀ (ਲੌਗਇਨ/ਲੌਗਆਉਟ, ਅਸਫਲ ਲੌਗਿਨ ਕੋਸ਼ਿਸ਼ਾਂ)
• ਅਧਿਕਾਰ ਅਤੇ ਰੋਲ ਬਦਲਾਅ
• ਮੁੱਖ ਰਿਕਾਰਡਾਂ ਦਾ ਬਣਾਉ/ਅਪਡੇਟ/ਮਿਟਾਉ (ਗਾਹਕ, ਇਨਵੌਇਸ, ਆਰਡਰ)
• ਐਕਸਪੋਰਟ, ਡਾਊਨਲੋਡ ਅਤੇ API ਕੀ ਬਦਲਾਅ
• ਬਿਲਿੰਗ ਅਤੇ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਬਦਲਾਅ

ਅਗਲੇ ਕਦਮ ਵਿੱਚ, ਫੈਸਲਾ ਕਰੋ ਕਿ ਰਿਕਾਰਡ ਕਿੰਨਾ ਮਜ਼ਬੂਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਕੁਝ ਘਟਨਾਵਾਂ ਮੁੱਖ ਰੂਪ ਵਿੱਚ ਟ੍ਰਬਲਸ਼ੂਟਿੰਗ ਲਈ ਹੁੰਦੀਆਂ ਹਨ (ਜਿਵੇਂ ਯੂਜ਼ਰ ਨੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਸੈਟਿੰਗ ਬਦਲੀ)। ਹੋਰਾਂ ਨੂੰ ਛੇੜਛਾੜ-ਸਬੂਤਯੋਗ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹ ਵਿੱਤੀਆ ਜਾਂ ਕਾਨੂੰਨੀ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੇ ਹਨ (ਐਡਮਿਨ ਐਕਸੇਸ ਦੇਣਾ, ਪੇਆਊਟ ਵੇਰਵੇ ਬਦਲਣਾ)। ਛੇੜਛਾੜ-ਸਬੂਤਯੋਗ ਹੋਣਾ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਜਟਿਲ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ, ਪਰ ਇਹ ਇੱਕ ਸੋਚ-ਵਿਚਾਰ ਕੇ ਚੁਣਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਆਖ਼ਿਰਕਾਰ, ਪਾਠਕ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ। ਸਪੋਰਟ ਰੋਜ਼ਾਨਾ ਲੌਗ ਚੈੱਕ ਕਰ ਸਕਦਾ ਹੈ। ਐਡਮਿਨ ਸੰਭਵਤ: ਸਿਰਫ਼ ਕਿਸੇ ਸੰਕਟ ਦੇ ਵੇਲੇ ਹੀ ਉਨ੍ਹਾਂ ਨੂੰ ਖੋਲ੍ਹਦੇ ਹਨ। ਇੱਕ ਆਡੀਟਰ ਸਾਲ ਵਿੱਚ ਇੱਕ ਵਾਰੀ ਫਿਲਟਰੇਡ ਰਿਪੋਰਟ ਮੰਗ ਸਕਦਾ ਹੈ। ਇਹ ਘਟਨਾ ਨਾਮਕਰਨ, ਕਿੰਨਾ ਸੰਦਰਭ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ, ਅਤੇ ਕਿਹੜੇ ਫਿਲਟਰ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਇਸ 'ਤੇ ਅਸਰ ਪਾਂਦਾ ਹੈ।

ਮੁੱਖ ਫੀਲਡ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: ਕਿਸਨੇ, ਕੀ, ਕਦੋਂ, ਅਤੇ ਕਿਉਂ

ਜੇ ਤੁਸੀਂ ਚਾਰ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਨੂੰ ਸਟੈਂਡਰਡ ਕਰੋ - ਕਿਸਨੇ ਕੀਤਾ, ਉਨ੍ਹਾਂ ਨੇ ਕੀ ਕੀਤਾ, ਕਦੋਂ ਹੋਇਆ, ਅਤੇ ਕਿਉਂ ਕੀਤਾ - ਤਾਂ ਤੁਸੀਂ ਵਿਭਿੰਨ ਫੀਚਰਾਂ ਵਿੱਚ ਲੋਗ ਇਕਸਾਰ ਰੱਖ ਸਕਦੇ ਹੋ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਖੋਜ ਕਰ ਸਕਦੇ ਹੋ।

ਕਿਸ (ਐਕਟਰ)

ਕਾਰਵਾਈ ਪਿੱਛੇ ਖੜਾ ਵਿਅਕਤੀ (ਜਾਂ ਸਿਸਟਮ) ਕੈਪਚਰ ਕਰੋ। ਡਿਸਪਲੇ ਨਾਂ ਦੀਵਾਣੀ ਨਾ ਲਵੋ; ਸਥਿਰ IDs ਵਰਤੋ।

ਸ਼ਾਮਲ ਕਰੋ:

• ਯੂਜ਼ਰ ID ਅਤੇ ਕਾਰਵਾਈ ਦੇ ਸਮੇਂ ਰੋਲ
• ਵਰਕਸਪੇਸ/ਅਕاؤنਟ/ਕਿਰਾਏਦਾਰ ID (ਤਾਂ ਜੋ ਘਟਨਾਵਾਂ ਗਾਹਕਾਂ ਵਿੱਚ ਮਿਲੇ ਨਾ)
• ਇੰਪერსੋਨੇਸ਼ਨ ਫਲੈਗ (ਅਤੇ ਕਿਸਨੇ ਸ਼ੁਰੂ ਕੀਤਾ), ਜੇ ਐਡਮਿਨ ਕਿਸੇ ਹੋਰ ਲਈ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ
• ਐਕਟਰ ਦਾ ਟਾਈਪ (ਮਾਨਵ, API ਕੁੰਜੀ, ਆਟੋਮੇਟਿਡ ਜੌਬ), ਜਦੋ ਲਾਗੂ ਹੋਵੇ

ਕੀ (ਇਵੈਂਟ)

ਕਾਰਵਾਈ ਨੂੰ ਇੱਕ ਨਿਰਧਾਰਤ ਢੰਗ ਨਾਲ ਵੇਰਵਾ ਕਰੋ। ਇੱਕ ਚੰਗਾ ਪੈਟਰਨ ਹੈ: ਕਾਰਵਾਈ ਦਾ ਨਾਮ + ਟਾਰਗੇਟ ਕਿਸਮ + ਟਾਰਗੇਟ ID।

ਇਸ ਦੇ ਨਾਲ ਇਹ ਵੀ ਦਰਜ ਕਰੋ ਕਿ ਇਹ ਕਿੱਥੇ ਹੋਇਆ ਤਾਂ ਸਪੋਰਟ ਸੋਰਸ ਨੂੰ ਟਰੇਸ ਕਰ ਸਕੇ:

• ਕਾਰਵਾਈ ਦਾ ਨਾਮ (ਉਦਾਹਰਣ ਲਈ, user.invite, billing.plan.change, project.delete)
• ਟਾਰਗੇਟ ਕਿਸਮ ਅਤੇ ਟਾਰਗੇਟ ID
• ਫੀਚਰ ਜਾਂ ਸਕਰੀਨ ਦਾ ਨਾਮ (ਜੋ ਐਡਮਿਨ ਪਛਾਣਦਾ ਹੈ)
• ਏਂਡਪੌਇੰਟ ਜਾਂ ਇੰਟਰਨਲ ਹੈਂਡਲਰ ਨਾਮ (UI ਕਾਰਵਾਈਆਂ ਨੂੰ ਕੋਡ ਪਾਥਾਂ ਨਾਲ ਜੋੜਨ ਵਿੱਚ ਮਦਦ)

ਕਦੋਂ (ਸਮਾਂ ਅਤੇ ਟਰੇਸਬਿਲਿਟੀ)

ਇੱਕ ਹੀ ਕੈਨੋਨਿਕ ਟਾਈਮਸਟੈਂਪ ਸਟੋਰ ਕਰੋ (ਆਮ ਤੌਰ 'ਤੇ UTC) ਤਾਂ ਜੋ ਸੋਰਟਿੰਗ ਕੰਮ ਕਰੇ, ਫਿਰ UI ਵਿੱਚ ਐਡਮਿਨ ਦੀ ਲੋਕਲ ਟਾਈਮਜ਼ੋਨ ਵਿੱਚ ਦਿਖਾਓ।

ਸੰਬੰਧਿਤ ਘਟਨਾਵਾਂ ਨੂੰ ਜੋੜਨ ਲਈ ਇੱਕ ਆਈਡੈਂਟਿਫਾਇਰ ਸ਼ਾਮਲ ਕਰੋ:

• ਰਿਕਵੇਸਟ ID ਜਾਂ ਕੋਰੇਲੇਸ਼ਨ ID (ਉਹੀ ID ਇੱਕ ਬੇਨਤੀ ਨਾਲ ਜੁੜੇ ਸਾਰੇ ਲੌਗ ਐਂਟਰੀਜ਼ ਵਿੱਚ)

ਕਿਉਂ (ਇਰਾਦਾ)

ਕਈ ਐਪ ਇਸਨੂੰ ਸਕਿੱਪ ਕਰ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਵਿਵਾਦ ਦੇ ਦੌਰਾਨ ਪਛਤਾਉਂਦੇ ਹਨ। ਇਸਨੂੰ ਹਲਕਾ ਰੱਖੋ:

• ਕਾਰਨ ਕੋਡ (ਛੋਟੀ ਫਿਕਸਡ ਲਿਸਟ ਜਿਵੇਂ “security”, “customer request”, “cleanup”, “billing”)
• ਵਿਕਲਪਿਕ ਨੋਟ ਫੀਲਡ ਲਈ ਛੋਟਾ ਸੰਦਰਭ (ਨਾਜੁਕ ਜਾਣਕਾਰੀ ਤੋਂ ਬਚੋ)
• ਵਿਕਲਪਿਕ ਟਿਕਟ ਜਾਂ ਰੈਫਰੰਸ ID (ਸਪੋਰਟ ਗੱਲਬਾਤ ਨਾਲ ਜੋੜਨ ਲਈ)

ਉਦਾਹਰਨ: ਇੱਕ ਐਡਮਿਨ ਕਿਸੇ ਯੂਜ਼ਰ ਦਾ ਰੋਲ ਬਦਲਦਾ ਹੈ। “ਕਿਸ” ਵਿੱਚ ਐਡਮਿਨ ਦਾ ਯੂਜ਼ਰ ID ਅਤੇ ਰੋਲ, ਨਾਲ ਵਰਕਸਪੇਸ ID। “ਕੀ” ਹੈ role.change ਉੱਤੇ user:123। “ਕਦੋਂ” ਇੱਕ UTC ਟਾਈਮਸਟੈਂਪ ਅਤੇ ਰਿਕਵੇਸਟ ID। “ਕਿਉਂ” ਹੈ “security” ਨਾਲ ਛੋਟੀ ਨੋਟ “requested by account owner” ਅਤੇ ਇੱਕ ਅੰਦਰੂਨੀ ਟਿਕਟ ਨੰਬਰ।

ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਬਿਨਾਂ ਲੀਕ ਕੀਤੇ ਬਦਲਾਅ ਲੌਗ ਕਰੋ

ਚੰਗੇ ਆਡਿਟ ਟਰੇਲ ਦੱਸਦੇ ਹਨ ਕਿ ਕੀ ਬਦਲਿਆ, ਪਰ ਉਹ ਗੁਪਤ ਡੇਟਾ ਨਾਲ ਭਰਿਆ ਹੋਇਆ ਦੂਜਾ ਡੈਟਾਬੇਸ ਨਹੀਂ ਬਣਨਾ ਚਾਹੀਦਾ। ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਨਿਯਮ ਸਧਾਰਨ ਹੈ: ਕਾਰਵਾਈ ਨੂੰ ਸਮਝਾਉਣ ਲਈ ਕਾਫ਼ੀ ਲੌਗ ਕਰੋ, ਨਜ਼ੀਕੀਆਨੁਕੂਲ ਨਿੱਜੀ ਡੇਟਾ ਮੁੜ ਬਣਾਉਣ ਲਈ ਨਹੀਂ।

ਮਹੱਤਵਪੂਰਨ ਅਪਡੇਟਾਂ ਲਈ, ਸਿਰਫ਼ ਉਹ ਫੀਲਡਾਂ ਜੋ ਮਾਮਲੇ ਲਈ ਗੱਲ ਬਣਦੀਆਂ ਹਨ, ਉਨ੍ਹਾਂ ਦਾ ਬੀਫੋਰ ਅਤੇ ਆਫਟਰ ਸ્નੈਪਸ਼ਾਟ ਲਓ। ਜੇ ਕਿਸੇ ਰਿਕਾਰਡ ਵਿੱਚ 40 ਫੀਲਡ ਹਨ, ਤਾਂ ਅਕਸਰ ਤੁਹਾਨੂੰ ਸਾਰੇ 40 ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਉਹ ਛੋਟਾ ਸੈਟ ਚੁਣੋ ਜੋ ਸਵਾਲ "ਇਸ ਕਾਰਵਾਈ ਨੇ ਕੀ ਪ੍ਰਭਾਵ ਕੀਤਾ?" ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੋਵੇ। ਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ ਇੱਕ ਐਡਮਿਨ ਇਕਾਊਂਟ ਅਪਡੇਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਸਿਰਫ਼ ਸਥਿਤੀ, ਰੋਲ ਅਤੇ ਯੋਜਨਾ ਲੌਗ ਕਰੋ, ਨਾ ਕਿ ਪੂਰਾ ਪ੍ਰੋਫ਼ਾਈਲ।

ਐਂਟਰੀ ਪੜ੍ਹਨਯੋਗ ਬਣਾਓ। ਇੱਕ ਛੋਟੀ ਡਿਫ ਸੰਖੇਪ ਜਿਵੇਂ “status changed: trial -> active” ਜਾਂ “email updated” ਸਪੋਰਟ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਕੈਨ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਜਦਕਿ ਸੰਰਚਿਤ ਵੇਰਵੇ ਫਿਲਟਰਿੰਗ ਅਤੇ ਜਾਂਚ ਲਈ ਉਪਲਬਧ ਰਹਿੰਦੇ ਹਨ।

ਇਸਦੇ ਨਾਲ-ਨਾਲ ਬਦਲਾਅ ਦਾ ਸਰੋਤ ਦਰਜ ਕਰੋ। ਓਹੀ ਅਪਡੇਟ ਵੱਖਰੇ ਮਤਲਬ ਰੱਖਦੀ ਹੈ ਜੇ ਉਹ UI ਤੋਂ ਆਈ ਹੋਵੇ ਜਾਂ API ਕੁੰਜੀ ਜਾਂ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਤੋਂ ਆਈ ਹੋਵੇ।

ਸੰਵੇਦਨਸ਼ੀਲ ਫੀਲਡਾਂ ਨੂੰ ਵੱਖਰਾ ਧਿਆਨ ਚਾਹੀਦਾ ਹੈ। ਖਤਰੇ ਦੇ ਅਨੁਸਾਰ ਇਹਨਾਂ ਪੈਟਰਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਰਤੋ:

• ਰਾ ਵੈਲਿਉਜ਼ ਸਿਕ੍ਰੈਟਾਂ (ਪਾਸਵਰਡ, ਟੋਕਨ, ਪ੍ਰਾਈਵੇਟ ਕੀ) ਲਈ ਲੌਗ ਕਰਨ ਤੋਂ ਬਚੋ
• ਪਹਿਚਾਣ ਲਈ ਹਿੱਸੇਵਾਰ ਮਾਸਕ (ਜਿਵੇਂ ਕਾਰਡ last4, ਫੋਨ ਦੇ ਅਖੀਰਲੇ ਅੰਕ)
• ਜਦੋਂ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਮਿਲਾਣੀ ਦੀ ਲੋੜ ਹੋਵੇ ਤਾਂ ਹੈਸ਼ ਕਰੋ ("ਉਹੀ ਵੈਲਿ ਉੱਤੇ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ" ਲਈ)
• ਜਦੋਂ ਵੈਲਿਊ ਦੀ ਲੋੜ ਨਾ ਹੋਵੇ ਤਾਂ “changed: true” ਲੌਗ ਕਰੋ

ਉਦਾਹਰਨ: ਇੱਕ ਗਾਹਕ ਦਾ ਪੇਆਊਟ ਅਕਾਊਂਟ ਅਪਡੇਟ ਹੁੰਦਾ ਹੈ। ਆਡਿਟ ਐਂਟ੍ਰੀ ਕਹਿ ਸਕਦੀ ਹੈ “payout_method changed” ਅਤੇ ਪ੍ਰੋਵਾਈਡਰ ਦਾ ਨਾਮ ਸਟੋਰ ਕਰ ਸਕਦੀ ਹੈ, ਪਰ ਪੂਰਾ ਅਕਾਊਂਟ ਨੰਬਰ ਨਹੀਂ।

ਐਡਮਿਨ ਅਤੇ ਸਪੋਰਟ ਲਈ ਲੌਗ ਪੜ੍ਹਨਯੋਗ ਬਨਾਓ

ਆਡਿਟ ਟਰੇਲ ਤਦ ਹੀ ਫਾਇਦੇਮੰਦ ਹੈ ਜਦੋਂ ਕੋਈ ਗੈਰ-ਟੈਕਨੀਕਲ ਐਡਮਿਨ ਇਸਨੂੰ ਸਕਿੰਡਾਂ ਵਿੱਚ ਸਕੈਨ ਕਰਕੇ ਸਮਝ ਸਕੇ। ਜੇ ਲੌਗ ਅੰਦਰੂਨੀ ਕੋਡ ਅਤੇ ਰਾ JSON ਵਾਂਗ ਪੜ੍ਹਾਈ ਦੇਵੇ, ਤਾਂ ਸਪੋਰਟ ਅਜੇ ਵੀ ਯੂਜ਼ਰ ਤੋਂ ਸਕਰੀਨਸ਼ਾਟ ਮੰਗੇਗਾ।

ਐਕਸ਼ਨ ਨਾਮ ਐਸੇ ਹੋਣ چاہੀਦੇ ਹਨ ਜੋ ਵਾਕਾਂ ਦੀ ਤਰ੍ਹਾਂ ਪੜ੍ਹੇ ਜਾਣ: “Invoice approved” ਤੁਰੰਤ ਸਪਸ਼ਟ ਹੈ। “INV_APPR_01” ਨਹੀਂ। ਕਾਰਵਾਈ ਨੂੰ ਹੈਡਲਾਈਨ ਸਮਝੋ, ਫਿਰ ਵੇਰਵੇ ਹੇਠਾਂ ਰੱਖੋ।

ਸਧਾਰਨ ਪੈਟਰਨ ਜੋ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ: ਇੱਕੋ ਘਟਨਾ ਦੀ ਦੋ ਰੂਪਾਂ ਨੂੰ ਸਟੋਰ ਕਰੋ: ਇੱਕ ਛੋਟਾ ਮਨੁੱਖੀ ਸੰਖੇਪ ਅਤੇ ਇੱਕ ਸੰਰਚਿਤ ਪੇਲੋਡ। ਸੰਖੇਪ ਤੇਜ਼ ਪੜ੍ਹਨ ਲਈ ਹੈ। ਪੇਲੋਡ ਫਿਲਟਰਿੰਗ ਅਤੇ ਜਾਂਚ ਲਈ ਹੈ।

ਨਾਂ ਸੰਗਤ ਰੱਖੋ। ਜੇ ਇਕੱਠੇ ਹੀ ਸਥਾਨ 'Customer' ਕਹਿੰਦੇ ਹੋ ਅਤੇ ਦੂਜੇ 'Client', ਤਾਂ ਖੋਜ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਗੁੰਝਲਦਾਰ ਹੋ ਜਾਵੇਗੀ।

ਪਰਯਾਪਤ ਸੰਦਰਭ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਜੋ ਸਪੋਰਟ ਬਿਨਾਂ ਲੰਬੀ ਵਾਪਸੀ ਦੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇ ਸਕੇ: ਵਰਕਸਪੇਸ/ਅਕਾਉਂਟ, ਯੋਜਨਾ ਜਾਂ ਟੀਅਰ, ਫੀਚਰ ਖੇਤਰ, ਐਨਟੀਟੀ ਨਾਂ, ਅਤੇ ਇੱਕ ਸਪੱਸ਼ਟ ਨਤੀਜਾ (“Succeeded” ਜਾਂ “Failed”, ਛੋਟੀ ਕਾਰਨ ਸਮੇਤ)।

ਐਡਮਿਨ ਵਿਊ ਵਿੱਚ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਕਾਰਵਾਈ, ਐਕਟਰ, ਸਮਾਂ ਅਤੇ ਟਾਰਗੇਟ ਦਿਖਾਓ। ਐਡਮਿਨਜ਼ ਵੇਰਵੇ ਲਈ ਵਿਸਥਾਰ ਖੋਲ੍ਹ ਸਕਦੇ ਹਨ। ਰੋਜ਼ਾਨਾ ਕੰਮ ਸਾਫ਼ ਰਹਿੰਦਾ ਹੈ, ਪਰ ਡੇਟਾ ਜਦੋਂ ਗਲਤ ਹੁੰਦਾ ਹੈ ਤਾਂ ਉਹ ਮਜ਼ਬੂਤ ਰਹਿੰਦਾ ਹੈ।

ਐਡਮਿਨ ਰੋਜ਼ਾਨਾ ਆਡਿਟ ਲੌਗ ਕਿਵੇਂ ਪੁੱਛਾਂਗੇ

ਜਦੋਂ ਕੁਝ ਗਲਤ ਲੱਗਦਾ ਹੈ: ਇੱਕ ਸੈਟਿੰਗ ਬਦਲੀ, ਇਨਵੌਇਸ ਟੋਟਲ ਹਿਲਿਆ, ਜਾਂ ਕਿਸੇ ਯੂਜ਼ਰ ਨੇ ਪਹੁੰਚ ਗੁਆ ਦਿੱਤੀ, ਤਾਂ ਐਡਮਿਨ ਆਡਿਟ ਲੌਗ ਖੋਲ੍ਹਦੇ ਹਨ। ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ ਇੱਕ ਛੋਟੇ ਫਿਲਟਰ ਸੈੱਟ ਤੋਂ ਲੰਘਦਾ ਹੈ ਜੋ ਉਹ ਸਵਾਲਾਂ ਮਿਲਦੇ ਹਨ।

ਡਿਫਾਲਟ ਵਿਊ ਨੂੰ ਸਧਾਰਨ ਰੱਖੋ: ਨਵੀਆਂ ਐਂਟ੍ਰੀ ਪਹਿਲਾਂ, ਸਪੱਸ਼ਟ ਟਾਈਮਸਟੈਂਪ (ਟਾਈਮਜ਼ੋਨ ਸ਼ਾਮਲ) ਅਤੇ ਇੱਕ ਛੋਟੀ ਸੰਖੇਪ ਲਾਈਨ। ਲਗਾਤਾਰ ਸੋਰਟਿੰਗ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਐਡਮਿਨ ਅਕਸਰ ਰਿਫ੍ਰੈਸ਼ ਕਰਕੇ ਦੇਖਦੇ ਹਨ ਅਤੇ ਪਿਛਲੇ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਕੀ ਬਦਲਿਆ ਤੁਲਣਾ ਕਰਦੇ ਹਨ।

ਇਕ ਵਹੀਵਟ ਰੋਜ਼ਾਨਾ ਫਿਲਟਰ ਸੈੱਟ ਛੋਟਾ ਪਰ ਪੇਸ਼ਾਨਾ ਹੈ:

• ਯੂਜ਼ਰ (ਕਿਸਨੇ ਕੀਤਾ)
• ਤਾਰੀਖ ਦਰਿਅਾ (ਆਖਰੀ ਘੰਟਾ, 24 ਘੰਟੇ, ਕਸਟਮ)
• ਕਾਰਵਾਈ (bana, update, delete, login, permission change)
• ਟਾਰਗੇਟ (ਕਿਸਮ + ID, ਜਿਵੇਂ Invoice #1842)

ਸੰਖੇਪਾਂ 'ਤੇ ਹਲਕੀ ਟੈਕਸਟ ਖੋਜ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਐਡਮਿਨ “password”, “domain”, ਜਾਂ “refund” ਲੱਭ ਸਕਣ। ਇਸ ਨੂੰ ਸਕੋਪਡ ਰੱਖੋ: ਸੰਖੇਪਾਂ ਅਤੇ ਕੁੰਜੀ ਫੀਲਡਾਂ 'ਤੇ ਖੋਜ ਰੱਖੋ, ਵੱਡੇ ਪੇਲੋਡਾਂ 'ਤੇ ਨਹੀਂ। ਇਸ ਨਾਲ ਖੋਜ ਤੇਜ਼ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਸਟੋਰੇਜ/ਇੰਡექსਿੰਗ ਖਰਚੇ ਤੋਂ ਬਚਾਵ ਹੁੰਦਾ ਹੈ।

ਪੇਜੀਨੇਸ਼ਨ ਨਿਰਾਸਕ ਅਤੇ ਭਰੋਸੇਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਪੇਜ ਸਾਈਜ਼, ਸਮਭਵ ਹੋਵੇ ਤਾਂ ਟੋਟਲ ਨਤੀਜੇ ਦਿਖਾਓ, ਅਤੇ "ID 'ਤੇ ਜੰਪ ਕਰੋ" ਚੋਈਸ ਰੱਖੋ ਤਾਂ ਸਪੋਰਟ ਟਿਕਟ ਤੋਂ ਇੱਕ ਇਵੈਂਟ ID ਪੇਸਟ ਕਰਕੇ ਸਿੱਧੇ ਉਸ ਰਿਕਾਰਡ 'ਤੇ ਪਹੁੰਚ ਸਕੇ।

ਜਦੋਂ ਮਾਮਲੇ ਕਈ ਦਿਨਾਂ 'ਤੇ ਫੈਲਦੇ ਹਨ ਤਾਂ ਐਕਸਪੋਰਟ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ। ਐਡਮਿਨ ਨੂੰ ਚੁੱਕੀ ਹੋਈ ਤਾਰੀਖ ਰੇਂਜ ਐਕਸਪੋਰਟ ਕਰਨ ਦਿਓ ਅਤੇ ਸਕ੍ਰੀਨ 'ਤੇ ਵਰਤੇ ਫਿਲਟਰ ਮੈਚ ਕਰਨ, ਤਾਂ ਫਾਇਲ ਉਹੀ ਚੀਜ਼ ਹੋਵੇ ਜੋ ਉਨ੍ਹਾਂ ਨੇ ਵੇਖੀ।

ਮੌਜੂਦਾ ਐਪ ਵਿੱਚ ਆਡਿਟ ਟਰੇਲ ਕਦਮ ਦਰ ਕਦਮ ਸ਼ਾਮਲ ਕਰੋ

ਛੋਟੀ ਸ਼ੁਰੂ ਕਰੋ। ਤੁਹਾਨੂੰ ਹਰ ਕਲਿੱਕ ਕੈਪਚਰ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਉਹ ਕਾਰਵਾਈਆਂ ਕੈਪਚਰ ਕਰੋ ਜੋ ਜ਼ਿਆਦਾ नुकਸਾਨ ਪਹੁੰਚਾ ਸਕਦੀਆਂ ਹਨ ਜੇ ਕੁਝ ਗਲਤ ਹੋ ਜਾਵੇ ਜਾਂ ਗਾਹਕ ਪੁੱਛੇ "ਇਸਨੂੰ ਕਿਸਨੇ ਬਦਲਿਆ?"।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਉੱਚ-ਖਤਰੇ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਦੀ ਸੂਚੀ ਬਣਾਓ। ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਸਾਈਨ-ਇਨ, ਬਿਲਿੰਗ, ਅਧਿਕਾਰ ਅਤੇ ਨੁਕਸਾਨ-ਕਰੀਆਂ ਕਾਰਵਾਈਆਂ (ਜਿਵੇਂ deletes ਜਾਂ exports) ਨਾਲ ਸਬੰਧਤ ਹੁੰਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਨिश्चਿਤ ਨਹੀਂ ਹੋ, ਤਾਂ ਪੁੱਛੋ: "ਜੇ ਇਹ ਹੋਵੇ ਅਤੇ ਅਸੀਂ ਇਸਨੂੰ ਸਪਸ਼ਟ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਕੀ ਇਹ ਗੰਭੀਰ ਸਮੱਸਿਆ ਹੋਵੇਗੀ?"

ਅਗਲੇ, ਇੱਕ ਸਧਾਰਨ ਇਵੈਂਟ ਸਕੀਮਾ ਡਿਜ਼ਾਈਨ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਇੱਕ API ਵਾਂਗ ਵਰਤੋ: ਇਸਨੂੰ ਵਰਜ਼ਨ ਕਰੋ। ਇਸ ਤਰੀਕੇ ਨਾਲ, ਜੇ ਤੁਸੀਂ ਫੀਲਡਾਂ ਨੂੰ ਿਪਹਲਾਂ ਰੀਨੇਮ ਕਰੋ ਜਾਂ ਨਵੇਂ ਜੋੜੋ, ਤਾਂ ਪੁਰਾਣੀਆਂ ਐਂਟ੍ਰੀਜ਼ ਅਜੇ ਵੀ ਸਮਝਦਾਰ ਰਹਿਣਗੀਆਂ ਅਤੇ ਤੁਹਾਡੇ ਐਡਮਿਨ ਸਕ੍ਰੀਨ ਟੁਟਣਗੇ ਨਹੀਂ।

ਇੱਕ ਪ੍ਰਾਇਗਮੈਟਿਕ ਬਣਾਵਟ ਕ੍ਰਮ:

• 10-20 ਉੱਚ-ਖਤਰੇ ਕਾਰਵਾਈਆਂ ਚੁਣੋ ਅਤੇ ਸਥਿਰ ਇਵੈਂਟ ਨਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ।
• ਇਕ ਵਾਰ ਇਵੈਂਟ ਫੀਲਡ ਤਯਾਰ ਕਰੋ (ਐਕਟਰ, ਟਾਰਗੇਟ, ਐਕਸ਼ਨ, ਸਮਾਂ, ਕਾਰਨ, ਰਿਕਵੇਸਟ ID, ਨਤੀਜਾ) ਅਤੇ ਇੱਕ ਸਕੀਮਾ ਵਰਜ਼ਨ ਜੋੜੋ।
• ਇੱਕ ਆਡਿਟ ਲੌਗਿੰਗ ਹੈਲਪਰ ਜੋ ਜੋ ਉਹਨਾਂ ਉੱਚ-ਖਤਰੇ ਕਾਰਵਾਈਆਂ ਤੋਂ ਬੁਲਾਇਆ ਜਾਵੇ, ਬਣਾਓ; ਹਰ ਥਾਂ ਵੱਖ-ਵੱਖ ਕਸਟਮ ਲੌਗਿੰਗ ਛਾਂਟਣ ਦੇ ਬਦਲੇ ਇੱਕ ਸcentral helper ਰੱਖੋ।
• ਇਵੈਂਟਾਂ ਨੂੰ ਇੱਕ ਮੁੱਖ ਟੇਬਲ ਜਾਂ ਲੌਗ ਸਟੋਰ ਵਿੱਚ ਸਟੋਰ ਕਰੋ, ਫਿਰ ਇੱਕ ਬੇਸਿਕ ਐਡਮਿਨ ਵਿਊਅਰ ਬਣਾਓ ਜਿਸ ਵਿੱਚ ਯੂਜ਼ਰ, ਤਾਰੀਖ ਰੇਂਜ ਅਤੇ ਇਵੈਂਟ ਟਾਈਪ ਦੁਆਰਾ ਖੋਜ ਹੋਵੇ।
• ਭਰੋਸਾ ਹੋਣ ਤੋਂ ਬਾਅਦ صرف ਕੁਝ ਮਹੱਤਵਪੂਰਨ ਇਵੈਂਟਾਂ ਲਈ ਅਲਰਟ ਜੋੜੋ।

ਹੈਲਪਰ ਨੂੰ ਕਠੋਰ ਅਤੇ ਨਿਰਾਸਕ ਰੱਖੋ। ਇਹ ਜਾਣੇ-ਪਛਾਣੇ ਇਵੈਂਟ ਨਾਮ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ, ਲਾਜ਼ਮੀ ਫੀਲਡਾਂ ਦੀ ਜਾਂਚ ਕਰੇ, ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਮੁੱਲਾਂ ਨੂੰ ਰੀਡੈਕਟ ਕਰੇ। ਅਪਡੇਟਾਂ ਲਈ, ਜੋ ਬਦਲਿਆ ਉਹ ਮਨੁੱਖੀ ਤਰੀਕੇ ਨਾਲ ਲੌਗ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ, “role: member -> admin”), ਨਾ ਕਿ ਰਿਕਾਰਡ ਦਾ ਪੂਰਾ ਡੰਪ।

ਉਦਾਹਰਨ: ਜਦੋਂ ਕਿਸੇ ਨੇ ਪੇਆਊਟ ਬੰਕ ਅਕਾਊਂਟ ਬਦਲਿਆ, ਤਾਂ ਐਕਟਰ, ਪ੍ਰਭਾਵਤ ਅਕਾਊਂਟ, ਸਮਾਂ, ਅਤੇ ਕਾਰਨ (ਜਿਵੇਂ "ਗਾਹਕ ਦੀ ਮੰਗ" ) ਲੌਗ ਕਰੋ। ਸਿਰਫ਼ ਆਖਰੀ 4 ਅੰਕਾਂ ਜਾਂ ਟੋਕਨ ਸਟੋਰ ਕਰੋ, ਪੂਰਾ ਅਕਾਊਂਟ ਨੰਬਰ ਨਹੀਂ।

ਆਮ ਗਲਤੀਆਂ ਜੋ ਆਡਿਟ ਟਰੇਲ ਨੂੰ ਬੇਕਾਰ ਬਣਾਉਂਦੀਆਂ ਹਨ

ਅਧਿਕਤਮ ਆਡਿਟ ਟਰੇਲ ਸਧਾਰਨ ਕਾਰਨਾਂ ਲਈ ਅਸਫਲ ਹੁੰਦੇ ਹਨ: ਟੀਮਾਂ ਜਾਂ ਤਾਂ ਸਭ ਕੁਝ ਲੌਗ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਸ਼ੋਰ ਵਿੱਚ ਡੁੱਬ ਜਾਂਦੀਆਂ ਹਨ, ਜਾਂ ਉਹ ਬਹੁਤ ਘੱਟ ਲੌਗ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਇਕੋ ਜੇਹੀ ਮਹੱਤਵਪੂਰਨ ਘਟਨਾ ਖੋ ਜਾਂਦੀ ਹੈ।

ਇੱਕ ਆਮ ਫੰਦ ਇਹ ਹੈ ਕਿ ਹਰ ਛੋਟੀ ਸਿਸਟਮ ਘਟਨਾ ਲੌਗ ਕੀਤੀ ਜਾਵੇ। ਜੇ ਐਡਮਿਨ ਇੱਕ ਬਟਨ ਕਲਿੱਕ ਲਈ ਦਰਜਨਾਂ ਐਂਟ੍ਰੀਜ਼ ਵੇਖਦੇ ਹਨ (autosaves, background sync, retries), ਉਹ ਦੇਖਣਾ ਛੱਡ ਦੇਂਦੇ ਹਨ। ਇਸ ਦੀ ਬਜਾਏ, ਯੂਜ਼ਰ ਦੀ ਇਰਾਦਾ ਅਤੇ ਨਤੀਜੇ ਲੌਗ ਕਰੋ। “Invoice status changed from Draft to Sent” ਲਾਭਦਾਇਕ ਹੈ। “PATCH /api/invoices/123 200” ਆਮ ਤੌਰ 'ਤੇ ਨਹੀਂ।

ਉਲਟਾ ਗਲਤ ਹੈ ਉੱਚ-ਖਤਰੇ ਘਟਨਾਵਾਂ ਨੂੰ ਛੱਡ ਦੇਣਾ। ਟੀਮਾਂ ਅਕਸਰ deletes, exports, login ਮੇਥਡ ਬਦਲਾਅ, ਰੋਲ/ਪਰਮੀਸ਼ਨ ਸੰਸ਼ੋਧਨ, ਅਤੇ API ਕੁੰਜੀ ਬਣਾਉਣ ਨੂੰ ਭੁੱਲ ਜਾਂਦੀਆਂ ਹਨ। ਇਹ ਉਹੀ ਕਾਰਵਾਈਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਤੁਹਾਨੂੰ ਵਿਵਾਦ ਜਾਂ ਸੰਭਾਲੀ ਗਿਆਨਹੀਣ ਖਾਤਾ ਸੰਭਾਵੀ ਹੋਣ 'ਤੇ ਲੋੜ ਪੈਂਦੀ ਹੈ।

ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਨਾਲ ਸਾਵਧਾਨ ਰਹੋ। ਆਡਿਟ ਲੌਗ ਕੋਈ ਸੁਰੱਖਿਅਤ ਥਾਂ ਨਹੀਂ ਹੈ ਪੂਰੇ ਪੇਲੋਡਾਂ ਨੂੰ ਡੰਪ ਕਰਨ ਲਈ। ਪਾਸਵਰਡ, ਐਕਸੈੱਸ ਟੋਕਨ, ਜਾਂ ਰਾ ਗਾਹਕ PII ਨੂੰ ਸਧੇ ਸਪੱਠ ਵਿੱਚ ਸਟੋਰ ਕਰਨਾ ਇੱਕ ਜ਼ਿੰਮੇਵਾਰੀ ਨੂੰ LIABILITY ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਪਹਿਚਾਣ ਅਤੇ ਸੰਖੇਪ ਲੌਗ ਕਰੋ, ਅਤੇ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਫੀਲਡਾਂ ਰੀਡੈਕਟ ਕਰੋ।

ਅਸੰਗਤ ਕਾਰਵਾਈ ਨਾਮ ਫਿਲਟਰਿੰਗ ਨੂੰ ਵੀ ਮਾਰਦਾ ਹੈ। ਜੇ ਇਕ ਹਿੱਸਾ user.update ਲਿਖਦਾ ਹੈ, ਦੂਜਾ UpdateUser, ਤੇ ਤੀਜਾ profile_changed, ਤਾਂ ਤੁਹਾਡੀਆਂ ਕੁਐਰੀਜ਼ ਘਟਨਾਵਾਂ ਨੂੰ ਚੁੱਕ ਨਹੀਂ ਪਾਉਂਦੀਆਂ। ਛੋਟੀ ਕਮਿੰਗ-ਸੈੱਟ ਵਰਬਲਿਸਟ ਚੁਣੋ ਅਤੇ ਉਸਤੇ ਟਿੱਕੇ ਰਹੋ।

ਜਦੋਂ ਰਿਟੇਨਸ਼ਨ ਦੀ ਯੋਜਨਾ ਨਾ ਹੋਵੇ ਤਾਂ ਖ਼ਰਚੇ ਵਧਦੇ ਹਨ। ਲੌਗਸ ਸਸਤੇ ਲੱਗਦੇ ਹਨ ਜਦ ਤੱਕ ਉਹ ਮਹਿੰਗੇ ਨਹੀਂ ਹੋ ਜਾਂਦੇ।

ਇੱਕ ਤੇਜ਼ ਪਰਖ: ਕੀ ਕੋਈ ਗੈਰ-ਟੈਕਨੀਕਲ ਐਡਮਿਨ ਇੱਕ ਐਂਟ੍ਰੀ ਪੜ੍ਹ ਕੇ ਸਮਝ ਸਕਦਾ ਹੈ ਕਿ ਕਿਸਨੇ ਕੀ ਕੀਤਾ, ਕਦੋਂ, ਅਤੇ ਕੀ ਬਦਲਿਆ? ਜੇ ਨਹੀਂ, ਤਾਂ ਫਿਰ ਫਿਰ ਸੋਚੋ।

ਰਿਟੇਨਸ਼ਨ ਅਤੇ ਟੀਅਰਾਂ ਨਾਲ ਸਟੋਰੇਜ ਖਰਚੇ ਕੰਟਰੋਲ ਵਿੱਚ ਰੱਖੋ

ਆਡਿਟ ਟਰੇਲ ਮਹਿੰਗੇ ਹੋ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਲੌਗ ਚੁਪਚਾਪ ਵੱਧਦੇ ਹਨ ਅਤੇ ਕੋਈ ਸੈਟਿੰਗ ਰੀਵੀਜ਼ਨ ਨਹੀਂ ਕਰਦਾ। ਹੱਲ ਸਿੱਧਾ ਹੈ: ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਰੱਖਣਾ ਹੈ, ਕਿੰਨੇ ਸਮੇਂ ਲਈ, ਅਤੇ ਕਿਸ ਡੀਟੇਲ ਦੇ ਨਾਲ।

ਇਵੈਂਟ ਕਿਸਮ ਅਨੁਸਾਰ ਵੱਖ-ਵੱਖ ਰਿਟੇਨਸ਼ਨ ਵਿਕਲਪ ਸੈੱਟ ਕਰੋ। ਸੁਰੱਖਿਆ ਅਤੇ ਅਧਿਕਾਰ ਸੰਬੰਧੀ ਇਵੈਂਟ ਆਮ ਤੌਰ 'ਤੇ ਰੋਜ਼ਾਨਾ ਗਤੀਵਿਧੀ ਨਾਲੋਂ ਲੰਬਾ ਰਿਟੇਨ ਹੋਣ ਯੋਗ ਹਨ। ਲੌਗਿਨ, ਰੋਲ ਬਦਲਾਅ, API ਕੀ ਇਵੈਂਟ, ਅਤੇ ਡੇਟਾ ਐਕਸਪੋਰਟ ਇਵੈਂਟ ਨੂੰ “ਦੇਖਿਆ” ਵਰਗੀਆਂ ਘਟਨਾਵਾਂ ਤੋਂ ਲੰਬਾ ਰੱਖੋ।

ਇਕ ਪ੍ਰਾਇਗਮੈਟਿਕ ਤਰੀਕਾ ਟੀਅਰ ਵਰਤਣ ਦੀ ਹੈ ਤਾਂ ਕਿ ਹਾਲੀਆ ਜਾਂਚ ਤੇਜ਼ ਰਹੇ ਅਤੇ ਪੁਰਾਣੀ ਇਤਿਹਾਸ ਸਸਤਾ ਰਹੇ:

• Hot (0 ਤੋਂ 30 ਦਿਨ): ਪੂਰਾ ਇवੈਂਟ ਡੀਟੇਲ, ਤੇਜ਼ ਫਿਲਟਰ, ਤੇਜ਼ ਖੋਜ
• Warm (31 ਤੋਂ 180 ਦਿਨ): ਪੂਰਾ ਡੀਟੇਲ ਪਰ ਕੰਪ੍ਰੈਸਡ ਅਤੇ ਧੀਮੀ ਕੁਏਰੀਜ਼
• Cold (6 ਤੋਂ 12 ਮਹੀਨੇ): ਸਾਰ ਸੰਖੇਪ ਇਵੈਂਟ (ਕਿਸਨੇ ਕਿਸ ਚੀਜ਼ ਨੂੰ ਕੀ ਕੀਤਾ, ਨਾਲ ਗਿਣਤੀ)
• Archive (12+ ਮਹੀਨੇ): ਕੇਵਲ ਕਾਂਪਲਾਇੰਸ ਲਈ ਸਟੋਰਡ, ਲੋੜ ਹੋਣ 'ਤੇ ਬੈਚ ਵਿੱਚ ਖਿੱਚਿਆ ਜਾਵੇ

ਆਕਾਰ ਘਟਾਉਣ ਲਈ ਵੱਡੇ ਪੇਲੋਡਾਂ ਦੀ ਨਕਲ ਕਰਨ ਤੋਂ ਬਚੋ। ਪੂਰੇ “ਬੀਫੋਰ” ਅਤੇ “ਆਫਟਰ” ਰਿਕਾਰਡ ਲੌਗ ਕਰਨ ਦੀ ਥਾਂ, ਸਿਰਫ਼ ਬਦਲੇ ਗਏ ਫੀਲਡ ਅਤੇ ਇੱਕ ਸਥਿਰ ਰੈਫਰੰਸ (ਰੀਕਾਰਡ ID, ਵਰਜ਼ਨ ID, ਸਨੈਪਸ਼ਾਟ ID, ਜਾਂ ਐਕਸਪੋਰਟ ਜੌਬ ID) ਸਟੋਰ ਕਰੋ। ਜੇ ਤੁਹਾਨੂੰ ਸਬੂਤ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਚੈਕਸਮ ਜਾਂ ਉਹਨਾਂ ਵਰਜ਼ਨ ਕੀਤੇ ਡਾਟਾ ਵਲ ਪੌਇੰਟਰ ਸਟੋਰ ਕਰੋ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਰੱਖਦੇ ਹੋ।

ਅਖੀਰਕਾਰ, ਗ੍ਰੋਥ ਅਨੁਮਾਨ ਲਗਾਓ ਤਾਂ ਜੋ ਚੁੱਕੇ ਨੰਬਰ ਤੁਹਾਨੂੰ ਅਚਾਨਕ ਵਾਧੇ ਤੋਂ ਪਹਿਲਾਂ ਚਿਤਾਵਨੀ ਦੇ ਸਕਣ: ਹਰ ਰੋਜ਼ ਘਟਨਾਵਾਂ x ਔਸਤ ਘਟਨਾ ਆਕਾਰ x ਦਿਨ ਰਿਟੇਨ ਕੀਤੇ ਗਏ। ਭੁੱਲ-ਭੁਲਾਇਆਂ ਅੰਕ ਤੇ ਵੀ ਤੁਹਾਨੂੰ “30 ਦਿਨ ਲਈ ਪੂਰੇ ਡੀਟੇਲ” ਅਤੇ “180 ਦਿਨ ਲਈ ਪੂਰੇ ਡੀਟੇਲ” ਵਿੱਚ ਚੋਣ ਕਰਨ ਵਿੱਚ ਮਦਦ ਮਿਲਦੀ ਹੈ।

ਇੱਕ ਹਕੀਕਤੀ ਉਦਾਹਰਨ: ਇੱਕ ਸੰਵੇਦਨਸ਼ੀਲ ਬਦਲਾਅ ਦੀ ਟ੍ਰੈਕਿੰਗ

ਪੇਰੋਲ ਸੈਟਿੰਗਾਂ ਆਮ ਤੌਰ 'ਤੇ “ਉੱਚ ਖਤਰਾ, ਘੱਟ ਮਾਲਿਕੀ” ਬਦਲਾਅ ਹੁੰਦੀਆਂ ਹਨ। ਇੱਕ ਆਮ ਮਾਮਲਾ: ਇੱਕ ਕਰਮਚਾਰੀ ਆਪਣਾ ਬੈਂਕ ਅਕਾਊਂਟ ਵੇਰਵਾ ਅਪਡੇਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਇੱਕ ਐਡਮਿਨ ਨੂੰ ਪੁਸ਼ਟੀ ਕਰਨੀ ਪੈਂਦੀ ਹੈ ਕਿ ਕਿਸਨੇ ਅਤੇ ਕਦੋਂ ਇਹ ਬਦਲਾਅ ਕੀਤਾ।

ਲੌਗ ਐਂਟਰੀ ਕਿਵੇਂ ਲੱਗਣੀ ਚਾਹੀਦੀ ਹੈ

ਇੱਕ ਚੰਗੀ ਸਰਗਰਮੀ ਲਾਈਨ ਖੁੱਲ੍ਹੇ ਵਿਊ ਵਿੱਚ ਪੜ੍ਹਨਯੋਗ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ:

"2026-01-09 14:32 UTC - Jane Admin (admin) updated Employee #482 payout bank account - reason: 'Employee requested update' - ticket: PAY-1834"

ਜਦ ਤੁਸੀਂ ਐਂਟ੍ਰੀ ਖੋਲ੍ਹਦੇ ਹੋ, ਤਾਂ ਵੇਰਵੇ ਇੱਕ ਕਸਰ-ਬੀਫੋਰ/ਆਫਟਰ ਡਿਫ ਦਿਖਾਂਦੇ ਹਨ (ਕੇਵਲ ਬਦਲੀਆਂ ਗਈਆਂ ਫੀਲਡਾਂ ਲਈ):

entity: employee
entity_id: 482
action: update
actor: user_id=17, name="Jane Admin", role="admin"
changed_fields:
  bank_account_last4: "0421" -> "7789"
  bank_routing_last4: "1100" -> "2203"
reason: "Employee requested update"
reference: "PAY-1834"

ਨਜ਼ਰ ਵਿੱਚ ਰਹਿਣ ਵਾਲੀ ਚੀਜ਼ਾਂ: ਕੋਈ ਪੂਰਾ ਅਕਾਊਂਟ ਨੰਬਰ ਨਹੀਂ, ਕੋਈ ਪੂਰਾ ਰਾਊਟਿੰਗ ਨੰਬਰ ਨਹੀਂ, ਕੋਈ ਅਪਲੋਡ ਕੀਤੇ ਦਸਤਾਵੇਜ਼ ਨਹੀਂ। ਤੁਸੀਂ ਇਹ ਲੌਗ ਇਸ ਗੱਲ ਨੂੰ ਸਾਬਤ ਕਰਨ ਲਈ ਲਿਖਦੇ ਹੋ ਕਿ ਕੀ ਹੋਇਆ, ਬਿਨਾਂ ਸਿਕ੍ਰੈਟਾਂ ਨੂੰ ਸਟੋਰ ਕੀਤੇ।

ਐਡਮਿਨ ਇਸਨੂੰ ਸਕਿੰਡਾਂ ਵਿੱਚ ਕਿਵੇਂ ਲੱਭਦਾ ਹੈ

ਵੱਡੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਫਿਲਟਰ ਨਾਲ ਤੰਗ ਕਰੋ:

• ਤਾਰੀਖ ਰੇਂਜ: ਆਖਰੀ 7 ਦਿਨ
• ਕਾਰਵਾਈ: “update”
• ਖੇਤਰ: “Payroll” (ਜਾਂ entity = employee)
• ਟਾਰਗੇਟ: Employee ID 482 (ਜਾਂ ਨਾਂ ਦੁਆਰਾ ਖੋਜ)
• ਫੀਲਡ: “bank_account” (ਵਿਕਲਪਿਕ)

ਜੋ ਮਿਲ ਜਾਵੇ, ਐਡਮਿਨ ਇੱਕ ਛੋਟੀ ਨੋਟ ਜੋੜ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਨ: "ਕਾਲ 'ਤੇ ਕਰਮਚਾਰੀ ਨਾਲ ਪੁਸ਼ਟੀ ਕੀਤੀ") ਜਾਂ ਅੰਦਰੂਨੀ ਟਿਕਟ/ਰੈਫਰੰਸ ID ਲਗਾ ਸਕਦਾ ਹੈ। ਕਾਰੋਬਾਰੀ ਕਾਰਨ ਨਾਲ ਇਹ ਲਿੰਕ ਭਵਿੱਖ ਦੀ ਸਮੀਖਿਆ ਨੂੰ ਅਨੁਮਾਨ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।

ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਤੇਜ਼ ਚੈੱਕਲਿਸਟ

ਉਤਪਾਦਨ ਵਿੱਚ ਆਡਿਟ ਟਰੇਲ ਚਾਲੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਹਕੀਕਤੀ ਐਡਮਿਨ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ ਤੇਜ਼ ਜਾਂਚ ਕਰੋ: ਕੋਈ ਵਿਆਸਤ, ਗੈਰ-ਟੈਕਨੀਕਲ ਵਿਅਕਤੀ ਜੋ ਤੇਜ਼ ਜਵਾਬ ਲੱਭਦਾ ਹੈ।

• ਉੱਚ-ਖਤਰੇ ਘਟਨਾਵਾਂ ਕਵਰ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ: ਪਹੁੰਚ ਜਾਂ ਰੋਲ ਬਦਲਾਅ, ਰਿਕਾਰਡ ਹਟਾਏ ਜਾਣ, ਡੇਟਾ ਐਕਸਪੋਰਟ, ਭੁਗਤਾਨ ਜਾਂ ਯੋਜਨਾ ਕਾਰਵਾਈਆਂ, ਅਤੇ ਸਾਈਨ-ਇਨ ਕਿਰਿਆਵਾਂ (ਫੇਲਿਅਰ ਸਮੇਤ)।
• ਇੱਕ ਐਡਮਿਨ ਕਹਾਣੀ ਤੇਜ਼ੀ ਨਾਲ ਲੱਭ ਸਕਦਾ ਹੈ: ਐਕਟਰ ਅਤੇ ਪ੍ਰਭਾਵਤ ਚੀਜ਼ ਦੁਆਰਾ ਫਿਲਟਰ ਕਰਨ ਤੇ ਤੇਜ਼ ਨਤੀਜੇ ਆਉਣ।
• ਸੰਵੇਦਨਸ਼ੀਲ ਵੇਰਵੇ ਸੁਰੱਖਿਅਤ ਹਨ: ਪਾਸਵਰਡ, ਟੋਕਨ, ਪੂਰਾ ਕਾਰਡ ਡੇਟਾ, ਅਤੇ ਸਿਕ੍ਰੈਟ ਕਦੇ ਪ੍ਰਗਟ ਨਹੀਂ; ਨਿੱਜੀ ਫੀਲਡ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਰੀਡੈਕਟ ਕੀਤੀਆਂ ਜਾਣ।
• “ਕਾਰਨ” ਫੀਲਡ ਵਿਕਲਪਿਕ ਪਰ ਮਾਰਗਦਰਸ਼ਿਤ ਹੈ: ਪ੍ਰੋੰਪਟ ਲੋਕਾਂ ਨੂੰ ਉਪਯੁਕਤ ਨੋਟ ਛੱਡਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ (ਉਦਾਹਰਨ "ਗਾਹਕ ਦੀ ਬੇਨਤੀ", "ਪਾਲਸੀ ਅਪਡੇਟ", "ਬੱਗ ਫਿਕਸ") ਬਿਨਾਂ ਇਸ ਨੂੰ ਜ਼ੋਰ-ਲਾਗੂ ਕੀਤੇ।
• ਰਿਟੇਨਸ਼ਨ ਅਤੇ ਐਕਸਪੋਰਟ ਤਿਆਰ ਹਨ: ਐਕਸਪੋਰਟ ਸਕ੍ਰੀਨ ਫਿਲਟਰਾਂ ਦੇ ਅਨੁਕੂਲ ਹੋਣ, ਅਤੇ ਰਿਟੇਨਸ਼ਨ ਨਿਯਮ ਹੁਣ ਸੈਟ ਕੀਤੇ ਗਏ ਹਨ (ਤਿਕਤੀਕ ਵਾਰੀ ਸਮੀਖਿਆ ਦੀ یاد ਦਿਓ)।

ਅਗਲੇ ਕਦਮ: ਇੱਕ ਸਧਾਰਨ ਰੋਲਆਉਟ ਯੋਜਨਾ

ਜੇ ਤੁਸੀਂ ਉਹ ਆਡਿਟ ਟਰੇਲ ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਲੋਕ ਵਾਕਈ ਵਰਤਣ, ਤਾਂ ਛੋਟੇ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਇੱਕ ਹਫਤੇ ਵਿੱਚ ਕੁਝ ਯੂਜ਼ਫੁਲ ਸ਼ਿਪ ਕਰੋ। ਲਕੜੀ ਮਕਸਦ ਹਰ ਚੀਜ਼ ਨੂੰ ਲੌਗ ਕਰਨ ਦਾ ਨਹੀਂ; ਮਕਸਦ ਇਹ ਜਵਾਬ ਦੇਣਾ ਹੈ "ਕਿਸਨੇ ਕੀ ਅਤੇ ਕਦੋਂ ਬਦਲਿਆ" ਬਿਨਾਂ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਨੂੰ ਜੰਕ ਡ੍ਰਾਇਰ ਵਿੱਚ ਬਦਲੇ।

ਆਪਣੇ ਪਹਿਲੇ ਕਾਰਵਾਈਆਂ ਚੁਣੋ। ਇਕ ਬਹਿਤਰੀਨ ਸ਼ੁਰੂਆਤੀ ਸੈੱਟ ਲੱਗਭਗ 10 ਇवੈਂਟਾਂ ਦਾ ਹੈ ਜੋ ਪੈਸਾ, ਪਹੁੰਚ, ਅਤੇ ਸੈਟਿੰਗਾਂ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹਨ। ਹਰ ਇੱਕ ਨੂੰ ਇੱਕ ਸਪੱਸ਼ਟ, ਸਥਿਰ ਨਾਮ ਦਿਓ ਜੋ ਇੱਕ ਸਾਲ ਬਾਅਦ ਵੀ ਸਿੰਝਲਾ ਰਹੇ।

ਫਿਰ ਇੱਕ ਸਧਾਰਨ ਇਵੈਂਟ ਸਕੀਮਾ ਫਿਕਸ ਕਰੋ ਅਤੇ ਇਸ 'ਤੇ ਟਿੱਕੇ ਰਹੋ। ਹਰ ਕਾਰਵਾਈ ਲਈ ਇੱਕ ਨਿਯਤ ਉਦਾਹਰਨ ਲਿਖੋ ਜਿਸ ਵਿੱਚ ਹਕੀਕਤੀ ਮੁੱਲ ਹੋਣ। ਇਹ ਸ਼ੁਰੂ ਵਿੱਚ ਫੈਸਲੇ ਜ਼ੋਰ ਦੇਂਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਇਸ ਗੱਲ 'ਤੇ ਕਿ ਤੁਹਾਡੇ ਐਪ ਵਿੱਚ "ਕਿਉਂ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ (ਸਪੋਰਟ ਟਿਕਟ, ਯੂਜ਼ਰ ਬੇਨਤੀ, ਸਮਾਂ-ਸੂਚਿਤ ਨੀਤੀ, ਐਡਮਿਨ ਸੁਧਾਰ)।

ਇਕ ਪ੍ਰੈਕਟਿਕਲ ਰੋਲਆਉਟ ਯੋਜਨਾ ਜੋ ਜ਼ਮੀਨੀ ਰਹੀਏ:

• 10 ਉੱਚ-ਮੁੱਲ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਚੁਣੋ ਅਤੇ ਇਵੈਂਟ ਨਾਮ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ।
• ਮੁੱਖ ਫੀਲਡ ਤਯਾਰ ਕਰੋ (ਐਕਟਰ, ਟਾਰਗੇਟ, ਟਾਈਮਸਟੈਂਪ, ਐਕਸ਼ਨ, ਸੰਖੇਪ, ਕਾਰਨ, request_id) ਅਤੇ ਹਰ ਇਵੈਂਟ ਲਈ ਇੱਕ ਨਮੂਨਾ ਬਣਾਓ।
• ਇੱਕ ਬੇਸਿਕ ਐਡਮਿਨ ਵਿਊਰ ਬਣਾਓ: ਤਾਰੀਖ ਰੇਂਜ, ਐਕਟਰ, ਕਾਰਵਾਈ ਕਿਸਮ, ਅਤੇ ਸਧਾਰਨ-ਭਾਸ਼ਾ ਸੰਖੇਪ ਲਾਈਨ।
• ਹੁਣ ਹੀ ਰਿਟੇਨਸ਼ਨ ਸੈੱਟ ਕਰੋ ਅਤੇ ਨਮੂਨਾ ਡੇਟਾ ਨਾਲ ਗ੍ਰੋਥ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਓ।
• ਇੱਕ ਟੈਸਟ ਹਫ਼ਤਾ ਚਲਾਓ: ਨਿਸ਼ਚਿਤ ਕਰੋ ਕਿ ਸੰਖੇਪ ਵਧੀਆ ਪੜ੍ਹ ਰਹੇ ਹਨ, ਕੁਐਰੀਜ਼ ਤੇਜ਼ ਹਨ, ਅਤੇ ਕੋਈ ਸੰਵੇਦਨਸ਼ੀਲ ਚੀਜ਼ ਲੀਕ ਨਹੀਂ ਹੋ ਰਹੀ।

ਜੇ ਤੁਸੀਂ Koder.ai (Koder.ai) ਵਰਗੇ ਚੈਟ-ਚਲਾਏ ਪਲੇਟਫਾਰਮ ਰਾਹੀਂ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਆਡਿਟ ਇਵੈਂਟਸ ਅਤੇ ਐਡਮਿਨ ਵਿਊਅਰ ਨੂੰ ਮੂਲ ਯੋਜਨਾ ਦਾ ਹਿੱਸਾ ਮੰਨੋ ਤਾਂ ਜੋ ਉਹ ਤੁਹਾਡੇ ਫੀਚਰਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਬਣਾਏ ਜਾਣ, ਬਜਾਏ ਕਿ ਬਾਅਦ ਵਿੱਚ ਪੈਚ ਕੀਤੇ ਜਾਣ।

ਪਹਿਲੀ ਰਿਲੀਜ਼ ਤੋਂ ਬਾਅਦ, ਸਿਰਫ਼ ਉਹਨਾਂ ਇਵੈਂਟਾਂ ਨੂੰ ਜੋੜੋ ਜਦੋਂ ਤੁਸੀਂ ਨਾਂ ਸਕਦੇ ਹੋ ਕਿ ਉਹ ਕਿਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ। ਇਸ ਨਾਲ ਲੌਗ ਪੜ੍ਹਨਯੋਗ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਸਟੋਰੇਜ ਖਰਚੇ ਅਨੁਮਾਨਯੋਗ ਰਹਿੰਦੇ ਹਨ।