ਗਾਹਕਾਂ ਨੂੰ ਡੇਟਾ ਰਿਹਾਇਸ਼ ਬਿਨਾਂ ਕਾਨੂੰਨੀ ਭਾਸ਼ਾ ਦੇ ਸਮਝਾਓ

ਜਦੋਂ ਗਾਹਕ ਡੇਟਾ ਰਿਹਾਇਸ਼ ਬਾਰੇ ਪੁੱਛਦਾ ਹੈ ਤਾਂ ਉਹ ਕੀ ਮੰਗਦੇ ਹਨ

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

ਜ਼ਿਆਦਾਤਰ ਲੋਕ ਇਕ ਕਾਨੂੰਨੀ ਪਰਿਭਾਸ਼ਾ ਨਹੀਂ ਮੰਗਦੇ। ਉਹ ਪੁੱਛ ਰਹੇ ਹਨ, “ਕੀ ਸਾਡਾ ਡੇਟਾ ਕਿਸੇ ਅਣਛਾਹੀ ਜਗ੍ਹਾ ਤੇ ਪਹੁੰਚੇਗਾ, ਅਤੇ ਕੀ ਅਸੀਂ ਇਸ 'ਤੇ ਕਾਬੂ ਰੱਖ ਸਕਦੇ ਹਾਂ?” ਏਹ ਚਿੰਤਾ ਖੁੱਲੀ ਤਰ੍ਹਾਂ ਨਾਮ ਲੈ ਕੇ ਦੱਸੋ — ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਮੂਲ ਸਵਾਲ ਨੂੰ ਸਮਝਦੇ ਹੋ।

ਜ਼ਿਆਦਾਤਰ ਰਿਹਾਇਸ਼ ਸਵਾਲਾਂ ਦੇ ਪਿੱਛੇ ਇਹ ਤਿੰਨ ਪ੍ਰੰਪਟ ਹੁੰਦੇ ਹਨ:

• ਸਾਡਾ ਡੇਟਾ ਕਿੱਥੇ ਸਟੋਰ ਹੁੰਦਾ ਹੈ (ਕਿਹੜਾ ਦੇਸ਼ ਜਾਂ ਰੀਜਨ)?
• ਕੌਣ ਇਸ ਨੂੰ ਐਕਸੈਸ ਕਰ ਸਕਦਾ ਹੈ (ਤੁਹਾਡਾ ਸਟਾਫ, ਵਿਕਰੇਤਾ, ਸਪੋਰਟ)?
• ਕੀ ਇਹ ਉਸ ਸਥਾਨ ਤੋਂ ਨਿਕਲ ਸਕਦਾ ਹੈ (ਬੈਕਅੱਪ, ਲਾਗ, ਐਨਾਲਿਟਿਕਸ, ਸਪੋਰਟ ਟੂਲਿੰਗ, AI ਪ੍ਰੋਸੈਸਿੰਗ)?

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

“ਮੈਂ ਸਾਡੇ ਕੰਟਰੋਲ ਅਤੇ ਆਮ ਡੇਟਾ ਫਲੋਜ਼ ਵਿਆਖਿਆ ਕਰ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ। ਤੁਹਾਡੇ ਕਾਨੂੰਨੀ ਸਲਾਹਕਾਰ ਇਸ ਨੂੰ ਤੁਹਾਡੇ ਨीतੀਆਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਕਿ ਨਹੀਂ, ਇਹ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹਨ।”

ਇਹ ਵੀ ਸਪਸ਼ਟ ਕਰੋ ਕਿ “ਰਿਹਾਇਸ਼” ਕੀ ਕਵਰ ਕਰਦੀ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ ਕਰਦੀ। ਰਿਹਾਇਸ਼ ਮੁੱਖ ਤੌਰ 'ਤੇ ਉਸ ਜਗ੍ਹਾ ਬਾਰੇ ਹੁੰਦੀ ਹੈ ਜਿੱਥੇ ਡੇਟਾ ਹੋਸਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਜਿੱਥੇ ਇਹ ਟ੍ਰਾਂਸਫਰ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਆਪਣੇ-आप ਵਿੱਚ ਹਰ ਚੀਜ਼ ਦਾ ਵਾਅਦਾ ਨਹੀਂ ਹੁੰਦੀ।

ਕੇਵਲ ਡੇਟਾ ਰਿਹਾਇਸ਼ ਇਹਨਾਂ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦੀ:

• ਡੇਟਾ ਰੀਟੈਂਸ਼ਨ (ਤੁਸੀਂ ਕਿੰਨਾ ਸਮਾਂ ਰੱਖਦੇ ਹੋ)
• ਡੇਟਾ ਮਾਲਕੀ ਅਤੇ IP ਸ਼ਰਤਾਂ
• ਸੁਰੱਖਿਆ ਗੁਣਵੱਤਾ (ਇਨਕ੍ਰਿਪਸ਼ਨ, ਮਾਨੀਟਰਿੰਗ, ਇੰਸਿਡੈਂਟ ਰਿਸਪਾਂਸ)
• ਯੂਜ਼ਰ ਜੋ ਖੁਦ ਅੱਪਲੋਡ ਜਾਂ ਸਾਂਝਾ ਕਰਦੇ ਹਨ
• ਜਦੋਂ ਗਾਹਕ ਡੇਟਾ ਨਿਰਯਾਤ ਕਰਦਾ ਹੈ ਤਾਂ ਬਾਅਦ ਕੀ ਹੁੰਦਾ ਹੈ

ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਡੇਟਾ ਰਿਹਾਇਸ਼ (ਅਤੇ ਇਹ ਕੀ ਨਹੀਂ ਹੈ)

ਡੇਟਾ ਰਿਹਾਇਸ਼ ਸਿਰਫ਼ ਉਹ ਦੇਸ਼ ਜਾਂ ਰੀਜਨ ਹੈ ਜਿੱਥੇ ਗਾਹਕ ਡੇਟਾ "at rest" ਹੁੰਦਾ ਹੈ — ਮਤਲਬ ਡੇਟਾਬੇਸ, ਫਾਇਲ ਸਟੋਰੇਜ ਅਤੇ ਬੈਕਅੱਪ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਗਿਆ ਡੇਟਾ।

ਜੇ ਕੋਈ ਗਾਹਕ ਡੇਟਾ ਰਿਹਾਇਸ਼ ਬਾਰੇ ਪੁੱਛਦਾ ਹੈ, ਉਹ ਇਹ ਸਪੱਸ਼ਟ ਜਵਾਬ ਚਾਹੁੰਦਾ ਹੈ: “ਸਾਡਾ ਡੇਟਾ ਰੋਜ਼ਾਨਾ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ?”

ਕੁਝ ਛੋਟੇ ਫਰਕ ਸਮਝਾਉਣ ਨਾਲ ਗੁੰਝਲਦਾਰੀ ਦੂਰ ਹੁੰਦੀ ਹੈ:

• ਡੇਟਾ ਰਿਹਾਇਸ਼ ਵਿਰੁੱਧ ਡੇਟਾ ਪ੍ਰਾਈਵੇਸੀ: ਪ੍ਰਾਈਵੇਸੀ ਇਸ ਗੱਲ ਬਾਰੇ ਹੈ ਕਿ ਡੇਟਾ ਕਿਵੇਂ ਵਰਤਿਆ ਜਾਂਦਾ ਅਤੇ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਕੌਣ ਦੇਖ ਸਕਦਾ ਹੈ, ਕਿਉਂ, ਅਤੇ ਕਿਹੜੇ ਸੁਰੱਖਿਆ ਉਪਾਅ ਹਨ), ਚਾਹੇ ਉਹ ਕਿਸੇ ਵੀ ਸਥਾਨ 'ਤੇ ਹੋਵੇ। ਰਿਹਾਇਸ਼ ਸਿਰਫ਼ ਸਥਾਨ ਬਾਰੇ ਹੈ।
• ਡੇਟਾ ਰਿਹਾਇਸ਼ ਵਿਰੁੱਝ ਡੇਟਾ ਸੋਵਰੇਨਟੀ: ਸੋਵਰੇਨਟੀ ਇਸ ਗੱਲ ਬਾਰੇ ਹੈ ਕਿ ਕਿਸ ਦੇਸ਼ ਦੇ ਕਾਨੂੰਨ ਡੇਟਾ 'ਤੇ दावा ਕਰਦੇ ਹਨ। ਰਿਹਾਇਸ਼ ਸਿਰਫ਼ ਸਟੋਰੇਜ ਸਥਾਨ ਹੈ।

ਕਿਉਂ 'ਰੀਜਨ' ਇੰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ? ਕਿਉਂਕਿ ਸਥਾਨ ਅਸਲੀ ਫਰਜ਼ਾਂ ਅਤੇ ਖਤਰੇ 'ਤੇ ਅਸਰ ਪਾਉਂਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਕਾਨੂੰਨ, ਠੇਕੇ ਦੀਆਂ ਵਚਨਾਂ, ਆਡਿਟ ਸਬੂਤ, ਡਿਜਾਸਟਰ ਰਿਕਵਰੀ ਡਿਜ਼ਾਈਨ, ਅਤੇ ਸਰਹੱਦੀ-ਪਾਰ ਟ੍ਰਾਂਸਫਰ ਕਾਇਦੇ।

ਜਦੋਂ ਤੁਸੀਂ ਰਿਹਾਇਸ਼ ਸਮਝਾਉਂਦੇ ਹੋ, ਤਠਸਥ ਹੋਵੋ। ਸਟੋਰੇਜ, ਬੈਕਅਪ, ਐਕਸੈਸ ਪਾਥ ਅਤੇ ਤੀਜੀਆਂ ਪਾਰਟੀਆਂ ਬਾਰੇ ਆਮ ਭਾਸ਼ਾ ਵਿੱਚ ਗੱਲ ਕਰੋ।

ਇੱਕ ਛੋਟਾ ਸਕ੍ਰਿਪਟ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਪੜ੍ਹ ਸਕਦੀ ਹੈ

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

ਗਾਹਕਾਂ ਦਾ ਡੇਟਾ ਕਿੱਥੇ-ਕਿੱਥੇ ਦਿਖ ਸਕਦਾ ਹੈ — 5 ਥਾਂ

ਰਿਹਾਇਸ਼ ਸਵਾਲ ਉਥੇ ਗੜਬੜ ਹੋ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਲੋਕ ਇਹ ਮਿਲਾ ਦਿੰਦੇ ਹਨ ਕਿ ਡੇਟਾ ਕਿੱਥੇ-ਕਿੱਥੇ ਨਜ਼ਰ ਆ ਸਕਦਾ ਹੈ। ਸਬ ਤੋਂ ਪਹਿਲਾਂ ਇਹ "ਠਿਕਾਣੇ" ਨਾਮ ਲੈਣਾ ਗੱਲ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ।

1) ਸਟੋਰੇਜ ("ਘਰ")

ਸਟੋਰੇਜ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਡੇਟਾ ਬੈਠਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਇਸਨੂੰ ਵਰਤ ਨਹੀਂ ਰਿਹਾ: ਡੇਟਾਬੇਸ, ਫਾਇਲ ਅੱਪਲੋਡ, ਆਬਜੈਕਟ ਸਟੋਰੇਜ (ਦਸਤਾਵੇਜ਼, ਚਿਤਰ), ਅਤੇ ਕਈ ਵਾਰ ਲਾਗ।

2) ਬੈਕਅੱਪ ਅਤੇ ਰੈਪਲਿਕਾ ("ਸੁਰੱਖਿਆ ਨਕਲਾਂ")

ਬੈਕਅੱਪ ਰਿਕਵਰੀ ਲਈ ਨਕਲਾਂ ਹਨ। ਰੈਪਲਿਕਾ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਉਪਲਬਧਤਾ ਲਈ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਰਿਹਾਇਸ਼ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ, ਕਿਸੇ ਹੋਰ ਰੀਜਨ ਵਿੱਚ ਨਕਲ ਵੀ ਵੀ ਗਾਹਕ ਡੇਟਾ ਹੀ ਹੈ।

3) ਪ੍ਰੋਸੈਸਿੰਗ ("ਵਰਕਬੈਂਚ")

ਪ੍ਰੋਸੈਸਿੰਗ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਰਿਕਵੇਸਟਾਂ ਹੇਠਾਂ ਮੁਕੰਮਲ ਹੁੰਦੇ ਹਨ: ਐਪ ਸਰਵਰ, ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ, API ਗੇਟਵੇ, ਅਤੇ ਛੋਟੇ ਅਰਥਕ ਕੈਸ਼। ਵਾਕ-ਕਾਲ ਦੇ ਦੌਰਾਨ ਡੇਟਾ ਸੰਖੇਪਕ ਰੂਪ ਵਿੱਚ ਮੈਮੋਰੀ ਜਾਂ ਅਸਥਾਈ ਫਾਇਲਾਂ ਵਿੱਚ ਹੋ ਸਕਦਾ ਹੈ।

4) ਐਡਮਿਨ ਐਕਸੈਸ ("ਲੋਕ-ਤਹ")

ਸਪੋਰਟ ਅਤੇ ਇੰਜੀਨੀਅਰ ਕਿਸੇ ਵੀ ਥਾਂ ਤੋਂ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਡੇਟਾ ਖੁਦ ਬਦਲ ਕੇ ਉਥੇ ਚਲਾ ਜਾਂਦਾ ਹੈ। ਗਾਹਕ ਜੋ ਅਸਲੀ ਸਵਾਲ ਪੁੱਛਦੇ ਹਨ ਉਹ ਇਹ ਹਨ: ਸਟਾਫ ਡੇਟਾ ਦੇਖ ਸਕਦਾ ਹੈ, ਕਿਹੜੇ ਨਿਯਮਾਂ ਦੇ ਤਹਿਤ, ਅਤੇ ਕਿਸ ਰਿਕਾਰਡਿੰਗ ਨਾਲ?

5) ਤੀਜੀਆਂ ਪਾਰਟੀਆਂ ("ਸਹਾਇਕ")

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

ਏਕ ਸਧਾਰਨ ਕਹਾਣੀ ਜ਼ਿਆਦਾਤਰ ਕੇਸ ਕਵਰ ਕਰਦੀ ਹੈ:

ਇਕ ਯੂਜ਼ਰ ਇੱਕ ਕਰਾਰ ਅੱਪਲੋਡ ਕਰਦਾ ਹੈ (ਸਟੋਰੇਜ), ਇਹ ਰਾਤ-ਦਰ-ਰਾਤ ਬੈਕਅੱਪ ਵਿੱਚ ਨਕਲ ਹੁੰਦਾ ਹੈ (ਬੈਕਅੱਪ), ਸਿਸਟਮ ਕੁੰਜੀ ਫੀਲਡ ਨਿਕਾਲਦਾ ਹੈ (ਪ੍ਰੋਸੈਸਿੰਗ), ਸਪੋਰਟ ਇੱਕ ਮਸਲੇ ਦੀ ਜਾਂਚ ਲਈ ਰੀਡ-ਓਨਲੀ ਐਕਸੈਸ ਵਰਤਦਾ ਹੈ (ਐਡਮਿਨ), ਅਤੇ ਇੱਕ ਐਰਰ ਰਿਪੋਰਟ ਜਿਸ ਵਿੱਚ ਇਕ ਛੋਟਾ ਟੁਕੜਾ ਹੋ ਸਕਦਾ ਹੈ, ਮਾਨੀਟਰਿੰਗ ਟੂਲ ਨੂੰ ਭੇਜੀ ਜਾਂਦੀ ਹੈ (ਤੀਜੀ-ਪਾਰਟੀ)।

ਇਸਨੂੰ ਸੁਪਸ਼ਟ ਬਣਾਓ: ਅਸੀਂ ਕਿਸ ਡੇਟਾ ਦੀ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ?

“ਸਾਡਾ ਡੇਟਾ ਕਿੱਥੇ ਸਟੋਰ ਹੁੰਦਾ ਹੈ?” ਦਾ ਅਰਥ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦਾ ਹੈ — ਇਹ ਗਾਹਕ ਦੇ ਅਪਲੋਡ ਕੀਤਾ ਸਮੱਗਰੀ, ਬਿਲਿੰਗ ਰਿਕਾਰਡ, ਲਾਗਜ਼, ਜਾਂ ਅਸਥਾਈ ਪ੍ਰੋਸੈਸਿੰਗ ਬਾਰੇ ਪੁੱਛ ਸਕਦੇ ਹਨ।

ਇੱਕ ਅਮਲੀ ਤਰੀਕਾ: ਡੇਟਾ ਨੂੰ ਤਿੰਨ ਬੱਕਟਾਂ ਵਿੱਚ ਵੰਡੋ:

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

ਲਿਖਤ ਵਿੱਚ ਆਸਾਨ ਤਰੀਕਾ

ਜਵਾਬ ਦਿੰਦੇ ਸਮੇਂ ਇਹ ਕ੍ਰਮ ਵਰਤੋ: (1) ਗਾਹਕ ਸਮੱਗਰੀ, (2) ਸੇਵਾ ਡੇਟਾ, (3) ਅਸਥਾਈ ਪ੍ਰੋਸੈਸਿੰਗ.

ਇੱਥੇ ਇੱਕ ਟੇਬਲ ਫਾਰਮੈਟ ਹੈ ਜੋ ਤੁਸੀਂ ਦਸਤਾਵੇਜ਼ ਜਾਂ ਈਮੇਲ ਵਿੱਚ ਦੁਹਰਾ ਸਕਦੇ ਹੋ:

ਉਦਾਹਰਨ ਸ਼ਬਦਾਵਲੀ:

“ਤੁਹਾਡੀ ਪ੍ਰੋਜੈਕਟ ਸਮੱਗਰੀ ਚੁਣੀ ਹੋਈ ਰੀਜਨ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ। ਬਿਲਿੰਗ ਅਤੇ ਖਾਤਾ ਰਿਕਾਰਡ ਸੇਵਾ ਡੇਟਾ ਹਨ ਅਤੇ ਵੱਖ-ਵੱਖ ਸਥਾਨਾਂ ਤੇ ਸਟੋਰ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਪ੍ਰੋਸੈਸਿੰਗ ਦੌਰਾਨ, ਕੁਝ ਅਸਥਾਈ ਡੇਟਾ ਮੈਮੋਰੀ ਜਾਂ ਕੈਸ਼ ਵਿੱਚ ਛੋਟੀ ਮਿਆਦ ਲਈ ਹੋ ਸਕਦਾ ਹੈ, ਫਿਰ ਇਹ ਮਿਟ ਜਾਂਦਾ ਹੈ।”

ਸਧਾਰਨ ਡਾਇਗ੍ਰਾਮ ਜੋ ਤੁਸੀਂ ਈਮੇਲ/ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਦੁਹਰਾ ਸਕਦੇ ਹੋ

ਇੱਕ ਛੋਟਾ ਡਾਇਗ੍ਰਾਮ ਅਕਸਰ ਇੱਕ ਪੈਰਾ ਤੋਂ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ ਰਿਹਾਇਸ਼ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਫੋਨ 'ਤੇ ਵੀ ਪੜ੍ਹਨਯੋਗ ਰੱਖੋ ਅਤੇ ਧਿਆਨ ਦਿਓ ਕਿ ਕਿਹੜੀ ਚੀਜ਼ ਕਿੱਥੇ ਸਟੋਰ ਹੈ ਅਤੇ ਕੀ ਹਿਲ ਸਕਦੀ ਹੈ।

ਡਾਇਗ੍ਰਾਮ 1: ਇਕ ਰੀਜਨ, ਮੁੱਖ ਡੇਟਾ "ਘਰ"

ਜਦੋਂ ਗਾਹਕ ਸਧਾਰਨ ਬਿਆਨ ਚਾਹੁੰਦਾ ਹੈ ਕਿ “ਸਭ ਕੁਝ Region A ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ।”

Customer
  |
  | use app
  v
[Region A]
  - App servers (process)
  - Database (store)
  - Backups (copy, store)

ਇਸ ਨੂੰ ਇੱਕ ਵਾਕ ਦੀ ਸਪਸ਼ਟੀਕਰਨ ਦੇ ਨਾਲ ਵਰਤੋਂ:

“ਸਾਰੇ ਗਾਹਕ ਸਮੱਗਰੀ Region A ਵਿੱਚ ਸਟੋਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਬੈਕਅੱਪ ਵੀ Region A ਵਿੱਚ ਰੱਖੇ ਜਾਂਦੇ ਹਨ।”

ਡਾਇਗ੍ਰਾਮ 2: ਦੋ ਰੀਜਨ (ਪ੍ਰਾਇਮਰੀ ਅਤੇ ਡਿਜਾਸਟਰ ਰਿਕਵਰੀ)

ਜਦੋਂ ਇੱਕ ਸਟੈਂਡਬਾਈ ਰੀਜਨ ਹੋਵੇ। ਤੀਰਾਂ ਆਪਣੇ-ਆਪਣੇ ਕਾਮ ਕਰਦੇ ਹਨ।

           normal use
Customer  ----------->  [Primary Region]
                             - App (process)
                             - DB (store)
                             - Backups (copy)
                                  |
                                  | encrypted copy
                                  v
                         [DR Region]
                             - Backup copy (store)
                             - Standby (no access unless failover)

ਜੇ ਗਾਹਕ ਟ੍ਰਾਂਸਫਰਾਂ ਲਈ ਸੰਵੇਦਨਸ਼ੀਲ ਹੈ ਤਾਂ ਤੀਰ 'ਤੇ ਇਹ ਲਿਖੋ ਕਿ ਕੀ ਹਿੰਡਦਾ ਹੈ (ਉਦਾਹਰਣ ਲਈ, “encrypted backup copy”) ਅਤੇ ਕਿੰਨੀ ਵਾਰ (ਉਦਾਹਰਣ ਲਈ, “ਰੋਜ਼ਾਨਾ”)।

ਡਾਇਗ੍ਰਾਮ 3: ਇੱਕ ਯੂਜ਼ਰ ਕਾਰਵਾਈ, ਟਚਪਾਇੰਟ ਦਰਸਾ ਕੇ

ਜਦੋਂ ਗਾਹਕ ਪੁੱਛਦਾ ਹੈ “ਮੇਰੀ ਫਾਇਲ ਕਿੱਥੇ ਜਾਂਦੀ ਹੈ?” ਜਾਂ “ਮੈਨੂੰ ਸੇਵ 'ਤੇ ਕਲਿੱਕ ਕਰਨ 'ਤੇ ਕੁਝ ਰੀਜਨ ਤੋਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ?”

User uploads a file
  1) App server (process upload)
  2) Object storage (store file)
  3) Database (store metadata)
  4) Backup system (copy for recovery)
User views the file
  5) App server (read)
  6) Object storage (send)

ਲੇਬਲਿੰਗ ਦੇ ਨਿਯਮ ਜੋ ਤੁਹਾਨੂੰ ਮੁਸ਼ਕਿਲ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ:

• ਇਕਰੋਨਿਮਜ਼ ਤੋਂ ਬਚੋ। “ਡੇਟਾਬੇਸ” ਲਿਖੋ ਨਾ ਕਿ “DB,” “ਡਿਜਾਸਟਰ ਰਿਕਵਰੀ” ਲਿਖੋ ਨਾ ਕਿ “DR.”
• ਗਾਹਕਾਂ ਦੇ ਪਛਾਣ ਵਾਲੇ ਕਿਰਿਆ-ਸ਼ਬਦ ਵਰਤੋ: store, copy, process, send, delete.
• ਹਰ ਬਕਸੇ 'ਤੇ ਰੀਜਨ ਦਾ ਨਾਮ ਲਿਖੋ, ਸਿਰਫ਼ ਸਿਰਲੇਖ 'ਤੇ ਨਹੀਂ।
• ਜੇ ਕੁਝ ਰੀਜਨ ਤੋਂ ਬਾਹਰ ਜਾ ਸਕਦਾ ਹੈ, ਤੀਰ ਖਿੱਚੋ ਅਤੇ ਉਸਨੂੰ ਨਾਂ ਦਿਓ।
• ਜੇ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ (ਜਿਵੇਂ “ਕੋਈ analytics export ਨਹੀਂ”), ਤਾਂ ਡਾਇਗ੍ਰਾਮ ਦੇ ਨੇੜੇ ਇਸਨੂੰ ਸਪਸ਼ਟ ਕਰੋ।

ਕਿਵੇਂ ਕਦਮ-ਦਰ-ਕਦਮ ਸਮਝਾਓ (ਦੁਹਰਾਉਣ ਯੋਗ ਸਕ੍ਰਿਪਟ)

ਇੱਕ ਸ਼ਾਂਤ, ਦੁਹਰਾਉਣ ਯੋਗ ਸਕ੍ਰਿਪਟ ਤੁਹਾਨੂੰ ਕਾਨੂੰਨੀ ਭਾਸ਼ਾ ਤੋਂ ਦੂਰ ਰੱਖਦੀ ਹੈ ਅਤੇ ਅਨਿਸ਼ਚਿਤਤਾ ਘਟਾਉਂਦੀ ਹੈ।

ਕਿਸੇ ਵੀ ਕਾਲ ਜਾਂ ਈਮੇਲ 'ਤੇ ਵਰਤਣ ਲਈ ਸਕ੍ਰਿਪਟ

1. ਇੱਕ ਸਵਾਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: “ਤੁਸੀਂ ਕਿਹੜੇ ਨਿਯਮ ਪੂਰੇ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ — ਕੋਈ ਖਾਸ ਦੇਸ਼, ਇਕ ਰੀਜਨ (ਜਿਵੇਂ EU), ਜਾਂ ਇੱਕ ਅੰਦਰੂਨੀ ਨੀਤੀ?”

2. ਮਿਲਾਓ ਕਿ ਉਨ੍ਹਾਂ ਲਈ “ਡੇਟਾ” ਦਾ ਕੀ ਅਰਥ ਹੈ: “ਕੀ ਤੁਸੀਂ ਮਤਲਬ ਸਮੱਗਰੀ, ਯੂਜ਼ਰ ਖਾਤੇ, ਫਾਇਲਾਂ, ਲਾਗ, ਬੈਕਅੱਪ ਜਾਂ ਐਨਾਲਿਟਿਕਸ ਕਰ ਰਹੇ ਹੋ?”

3. ਮੁੱਖ ਸਥਾਨ ਇੱਕ ਵਾਕ ਵਿੱਚ ਬਿਆਨ ਕਰੋ: “ਨਾਮਾਤਰ ਤੁਹਾਡਾ ਐਪ ਡੇਟਾ ਉਸ ਰੀਜਨ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਜਿੱਥੇ ਤੁਹਾਡਾ ਵਾਤਾਵਰਨ ਡਿਪਲੋਇਡ ਹੈ।”

4. ਦੱਸੋ ਕਿ ਕੀ ਲਿਫਟ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਿਉਂ। ਅਮਲੀ ਰੂਪ ਵਿੱਚ: ਸਪੋਰਟ ਟ੍ਰਬਲਸ਼ੂਟਿੰਗ, ਰਿਕਵਰੀ ਡਿਜ਼ਾਇਨ (ਰਿ-ਸਟੋਰ/ਫੇਲਓਵਰ), ਅਤੇ ਤੀਜੀਆਂ ਪਾਰਟੀਆਂ। ਜੇ ਕੁਝ ਕਦੇ ਨਹੀਂ ਨਿਕਲਦਾ, ਤਾਂ ਇਹ ਦੱਸੋ। ਜੇ ਇਹ ਕੁਝ ਸ਼ਰਤਾਂ ਹੇਠਾਂ ਨਿਕਲ ਸਕਦਾ ਹੈ, ਉਹਨਾਂ ਸ਼ਰਤਾਂ ਨੂੰ ਨਾਂ ਦਿਓ।

5. ਉਹ ਕੰਟਰੋਲ ਦੱਸੋ ਜੋ ਗਾਹਕ ਚੁਣ ਸਕਦਾ ਹੈ। ਧਿਆਨ ਕੇਂਦਰਤ ਕਰੋ ਕਿ ਗਾਹਕ ਕੀ ਫੈਸਲਾ ਕਰ ਸਕਦਾ ਹੈ (ਰੀਜਨ ਚੋਣ, ਐਕਸੈਸ ਕੰਟਰੋਲ) ਅਤੇ ਉਹ ਖੁਦ ਕੀ ਕਰ ਸਕਦੇ ਹਨ (ਏਕਸਪੋਰਟ, ਰਿ-ਸਟੋਰ)।

ਫਿਰ ਇੱਕ ਸਾਫ਼ ਅਗਲਾ ਕਦਮ ਦਿਓ:

“ਮੈਂ ਇੱਕ ਛੋਟਾ ਲਿਖਤੀ ਸਾਰ ਭੇਜਾਂਗਾ ਜਿਸ ਵਿੱਚ ਦੱਸਿਆ ਹੋਵੇਗਾ ਕਿ ਕੀ ਰਹਿੰਦਾ ਹੈ, ਕੀ ਚੱਲ ਸਕਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਕੀ ਕਾਬੂ ਰੱਖ ਸਕਦੇ ਹੋ। ਜੇ ਕੋਈ ਸੋਧ ਹੋਵੇ ਤਾਂ ਜਵਾਬ ਦਿਓ।”

ਲਿਖਤੀ ਸੰਖੇਪ ਵਿੱਚ ਕੀ ਸ਼ਾਮਲ ਕਰਨਾ ਹੈ

ਇਸਨੂੰ ਪੰਜ ਲਾਈਨਾਂ ਤਕ ਰੱਖੋ:

• ਗਾਹਕ ਦੀ ਲੋੜ (ਦੇਸ਼/ਰੀਜਨ ਅਤੇ ਕਿਹੜੇ ਡੇਟਾ ਕਿਸਮਾਂ)
• ਸਟੋਰੇਜ ਸਥਾਨ (ਡਿਫੌਲਟ ਅਤੇ ਚੁਣੀ ਹੋਈ ਰੀਜਨ)
• ਮਨਜ਼ੂਰ ਟ੍ਰਾਂਸਫਰ (ਸਪੋਰਟ, ਰਿਕਵਰੀ, ਤੀਜੀਆਂ ਪਾਰਟੀਆਂ)
• ਗਾਹਕ ਕੰਟਰੋਲ (ਰੀਜਨ ਚੋਣ, ਐਕਸੈਸ, ਏਕਸਪੋਰਟ, ਸਨੇਪਸ਼ਾਟ)
• ਖੁੱਲ੍ਹੇ ਸਵਾਲ (ਜੋ ਕੁਝ ਤੁਸੀਂ ਅਜੇ ਵੀ ਪੁਸ਼ਟੀ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ)

ਸਪਸ਼ਟ ਸ਼ਬਦਾਂ ਦੇ ਡ੍ਰਾਫਟ ਜੋ ਤੁਸੀਂ ਕਾਪੀ-ਪੇਸਟ ਕਰ ਸਕਦੇ ਹੋ

ਗਾਹਕਾਂ ਨੂੰ ਦੋ ਜਵਾਬ ਚਾਹੀਦੇ ਹਨ: ਉਹਨਾਂ ਦਾ ਡੇਟਾ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਕੀ ਇਹ ਕਦੇ ਹਿਲਦਾ ਹੈ। ਇਹ ਦੋ ਗੱਲਾਂ ਨੂੰ ਵੱਖ ਕਰੋ:

“ਡੇਟਾ X ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ। ਇਹ Y ਤੱਕ ਸਿਰਫ਼ Z ਲਈ ਹੀ ਜਾ ਸਕਦਾ ਹੈ।”

“ਹਮੇਸ਼ਾਂ” ਅਤੇ “ਕਦੇ ਨਹੀਂ” ਵਰਤਣ ਵਿੱਚ ਸਾਵਧਾਨ ਰਹੋ। ਕੇਵਲ ਤਦ ਹੀ ਅਬਸੋਲਿਊਟ ਵਰਤੋ ਜਦੋਂ ਇਹ ਬੈਕਅੱਪ, ਆਊਟੇਜ ਅਤੇ ਸਪੋਰਟ ਕੰਮ ਦੇ ਸਭ ਪਾਸਿਆਂ 'ਤੇ ਟਿਕਦਾ ਹੋਵੇ।

ਤਿਆਰ-ਤੋਂ-ਭੇਜਣ ਲਈ 3 ਜਵਾਬ

• ਛੋਟਾ ਜਵਾਬ (ਈਮੇਲ ਜਾਂ ਚੈਟ) “ਤੁਹਾਡਾ ਗਾਹਕ ਡੇਟਾ [REGION/COUNTRY] ਵਿੱਚ ਸਾਡੇ ਕਲਾਊਡ ਢਾਂਚੇ 'ਤੇ ਰਹਿੰਦਾ ਹੈ। ਇਹ ਉਸ ਰੀਜਨ ਤੋਂ ਬਾਹਰ ਸਿਰਫ਼ [ਖਾਸ ਕਾਰਨ, ਉਦਾਹਰਣ ਵਜੋਂ ਡਿਜਾਸਟਰ ਰਿਕਵਰੀ ਜਾਂ ਮਨਜ਼ੂਰ ਸਪੋਰਟ] ਲਈ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਸਿਰਫ਼ ਹੇਠਾਂ ਲਿਖੇ ਕੰਟਰੋਲਾਂ ਦੇ ਤਹਿਤ।”

• ਵਿਸਤਾਰਿਤ ਜਵਾਬ (ਖਰੀਦ/IT ਲਈ) “ਨਾਮਾਤਰ, ਡੇਟਾ [REGION/COUNTRY] ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ: ਐਪਲੀਕੇਸ਼ਨ ਡੇਟਾ, ਡੇਟਾਬੇਸ ਰਿਕਾਰਡ, ਅਤੇ ਫ਼ਾਇਲ ਅੱਪਲੋਡ. ਬੈਕਅੱਪ [BACKUP REGION] ਵਿੱਚ ਰੱਖੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਰੱਖਾਈ [RETENTION] ਦੇ ਅਨੁਸਾਰ ਹੁੰਦੀ ਹੈ। ਡੇਟਾ ਤਬਦੀਲੀ-ਕਾਲੀਨ ਤੌਰ 'ਤੇ [SUPPORT/DIAGNOSTIC LOCATION] ਤੇ ਜਾ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕੋਈ ਮਸਲਾ ਹੱਲ ਕਰਨ ਲਈ ਲੋੜ ਹੋਵੇ, ਅਤੇ ਸਿਰਫ਼ ਸੀਮਿਤ ਐਕਸੈਸ ਹੁੰਦਾ ਹੈ। ਜੇ ਅਸੀਂ sub-processors ਵਰਤਦੇ ਹਾਂ (ਜਿਵੇਂ ਕਲਾਊਡ ਹੋਸਟਿੰਗ ਜਾਂ AI ਮਾਡਲ ਪ੍ਰਦਾਤਾ), ਅਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਅਤੇ ਉਹਨਾਂ ਦੇ ਰੀਜਨ ਨੂੰ ਦਰਜ ਕਰਦੇ ਹਾਂ।”

• ਸੁਰੱਖਿਆ ਸਮੀਖਿਆ ਜਵਾਬ (ਫਾਰਮਲ, ਪਰ ਫਿਰ ਵੀ ਆਮ ਭਾਸ਼ਾ) “ਸਾਡੀ ਰਿਹਾਇਸ਼ ਵਿਆਖਿਆ ਵਿੱਚ ਸ਼ਾਮਲ ਹੈ: (1) ਉਤਪਾਦਨ ਡੇਟਾ ਕਿੱਥੇ ਸਟੋਰ ਹੁੰਦਾ ਹੈ, (2) ਬੈਕਅੱਪ ਅਤੇ ਡਿਜਾਸਟਰ ਰਿਕਵਰੀ ਨਕਲਾਂ ਕਿੱਥੇ ਸਟੋਰ ਹੁੰਦੀਆਂ ਹਨ, (3) ਕੌਣ ਡੇਟਾ ਐਕਸੈਸ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕਿਵੇਂ ਐਕਸੈਸ ਲੌਗ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ (4) ਕਿਹੜੀਆਂ ਤੀਜੀਆਂ ਪਾਰਟੀਆਂ ਡੇਟਾ ਪ੍ਰੋਸੈਸ ਕਰ ਸਕਦੀਆਂ ਹਨ।”

ਡੌਕਸ ਵਿੱਚ ਰੱਖਣ ਲਈ ਭਰੋ-ਪੂਰਾ ਟੈਂਪਲੇਟ

ਇਸਨੂੰ ਇੱਕ ਸਿੰਗਲ ਸੋర్స్ ਆਫ਼ ਟ੍ਰੂਥ ਵਜੋਂ ਵਰਤੋ, ਫਿਰ ਜੋ ਸੈਕਸ਼ਨ ਲੋੜ ਹੋਵੇ ਉਨ੍ਹਾਂ ਨੂੰ ਜਵਾਬਾਂ ਵਿੱਚ ਕਾਪੀ ਕਰੋ:

• Region (production): [REGION/COUNTRY], [CLOUD], [TENANT SETUP]
• Backups: stored in [REGION], encrypted [AT REST/IN TRANSIT], retention [DAYS]
• Support access: [WHO], [WHEN], [APPROVAL NEEDED?], [LOGGING]
• Disaster recovery: [DISASTER RECOVERY REGION], “only used during outages”
• Sub-processors: [LIST], including any AI model providers if applicable

ਜੇ ਕੋਈ ਲਾਈਨ ਅਣਜਾਣ ਹੈ ਤਾਂ ਅਨੁਮਾਨ ਨਾ ਲਗਾਓ। ਜੋ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਉਹ ਦੱਸੋ, ਜੋ ਤੁਸੀਂ ਪੁਸ਼ਟੀ ਕਰ ਰਹੇ ਹੋ ਉਹ ਦੱਸੋ, ਅਤੇ ਕਦੋਂ ਫਾਲੋ-ਅਪ ਕਰੋਗੇ ਇਹ ਵੀ ਕਹੋ।

ਆਮ ਗਲਤੀਆਂ ਅਤੇ ਸ਼ਬਦਾਂ ਦੀਆਂ ਜਾਲ-ਚੁੱਕਾਂ ਤੋਂ ਬਚੋ

ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਭਰੋਸਾ ਘੱਟਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਆਤਮ ਵਿਸ਼ਵਾਸ ਨਾਲ ਪਰੰਤੂ ਅਸਪਸ਼ਟ ਬੋਲਦੇ ਹੋ। ਇਹ ਗਲਤੀਆਂ ਆਮ ਤੌਰ 'ਤੇ ਫਾਲੋ-ਅੱਪ ਈਮੇਲਾਂ ਅਤੇ ਲੰਬੀਆਂ ਸੁਰੱਖਿਆ ਸਮੀਖਿਆਵਾਂ ਨੂੰ ਜਨਮ ਦਿੰਦੀਆਂ ਹਨ।

ਸਭ ਤੋਂ ਆਮ ਗਲਤੀਆਂ

“ਅਸੀਂ ਕੰਪਲਾਇੰਟ ਹਾਂ” ਕਹਿ ਦੇਣਾ ਪਰ ਨਹੀਂ ਦੱਸਣਾ ਕਿ ਡੇਟਾ ਕਿੱਥੇ ਸਟੋਰ ਹੁੰਦਾ ਹੈ। ਗਾਹਕ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਧਾਰਨ ਵਾਕ ਚਾਹੁੰਦੇ ਹਨ: ਕੀ ਡੇਟਾ ਸਟੋਰ ਹੁੰਦਾ ਹੈ, ਕਿਹੜਾ ਦੇਸ਼ ਜਾਂ ਰੀਜਨ, ਅਤੇ ਕੀ ਇਹ ਸੰਰਚਨਾਤਮਕ ਤੌਰ 'ਤੇ ਕਨਫੀਗਰੇਬਲ ਹੈ।

ਕੰਪਿਊਟ ਸਥਾਨ ਨੂੰ ਸਟੋਰੇਜ ਸਥਾਨ ਨਾਲ ਮਿਲਾ ਦੇਣਾ। ਐਪ ਇਕ ਥਾਂ 'ਤੇ ਚੱਲ ਸਕਦੀ ਹੈ ਪਰ ਡੇਟਾਬੇਸ, ਫਾਇਲ ਸਟੋਰੇਜ ਜਾਂ ਐਨਾਲਿਟਿਕਸ ਕਿੱਥੇ ਹੋ ਸਕਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ “ਐਪ ਕਿੱਥੇ ਚੱਲਦੀ ਹੈ” ਬਾਰੇ ਗੱਲ ਕਰੋਗੇ ਤਾਂ ਗਲਤ ਫਹਿਮੀ ਪੈਦਾ ਹੋ ਸਕਦੀ ਹੈ।

“ਸਾਈਡ ਡੇਟਾ” ਨੂੰ ਭੁੱਲ ਜਾਣਾ। ਬੈਕਅੱਪ, ਲਾਗ, ਕਰੈਸ਼ ਰਿਪੋਰਟ ਅਤੇ ਸਪੋਰਟ ਟਿਕਟ ਮੁੱਖ ਡੇਟਾਬੇਸ ਦੇ ਬਰਾਬਰ ਮਹੱਤਵ ਰੱਖਦੇ ਹਨ।

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

ਇਹ ਮੰਨਣਾ ਕਿ ਕਲਾਊਡ “ਰੀਜਨ” ਸਵੈਚਾਲਿਤ ਤੌਰ 'ਤੇ “ਦੇਸ਼ਾਂ-ਦਰ-ਦੇਸ਼ ਐਕਸੈਸ ਨਾ ਹੋਵੇ” ਨੂੰ ਭਾਵੇ। ਭਾਵੇਂ ਡੇਟਾ ਇਕ ਰੀਜਨ ਵਿੱਚ ਸਟੋਰ ਹੋਵੇ, ਹੋ ਸਕਦਾ ਹੈ ਸਟਾਫ ਜਾਂ ਸਿਸਟਮ ਹੋਰ ਥਾਵਾਂ ਤੋਂ ਨਿਯੰਤਰਿਤ ਐਕਸੈਸ ਰੱਖਦੇ ਹੋਣ। ਗਾਹਕਾਂ ਲਈ ਇਹ ਫਰਕ ਅਕਸਰ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ।

ਸੁਰੱਖਿਅਤ ਸ਼ਬਦਨੁਮਾ ਉਦਾਹਰਣ:

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

ਗਾਹਕ ਨੂੰ ਜਵਾਬ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਇਕ ਛੋਟੀ ਚੈਕਲਿਸਟ

ਨੀਤੀ ਟੈਕਸਟ ਨਾਲ ਸ਼ੁਰੂ ਨਾ ਕਰੋ। ਪਹਿਲਾਂ ਕੁਝ ਤੱਥ ਦੱਸੋ ਜੋ ਤੁਸੀਂ ਇਕ-ਦੋ ਵਾਕਾਂ ਵਿੱਚ ਕਹਿ ਸਕਦੇ ਹੋ, ਫਿਰ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਵਿਸਥਾਰ ਦਿਓ।

ਪਹਿਲਾਂ ਕਰਨ ਲਈ 5 ਚੈਕ

• ਮੁੱਖ ਸਟੋਰੇਜ ਸਥਾਨ: ਗਾਹਕ ਦੀ ਮੁੱਖ ਡੇਟਾਬੇਸ ਅਤੇ ਫਾਇਲ ਸਟੋਰੇਜ ਕਿਸ ਦੇਸ਼/ਰੀਜਨ ਵਿੱਚ ਹੈ?
• ਬੈਕਅੱਪ ਅਤੇ ਰੀਟੈਂਸ਼ਨ: ਬੈਕਅੱਪ ਕਿੱਥੇ ਰੱਖੇ ਜਾਂਦੇ ਹਨ, ਕਿੰਨੀ ਦੇਰ ਲਈ, ਅਤੇ ਕੌਣ ਉਨਾਂ ਨੂੰ ਰੀਸਟੋਰ ਕਰ ਸਕਦਾ ਹੈ?
• ਰੈਪਲਿਕੇਸ਼ਨ ਅਤੇ ਫੇਲਓਵਰ: ਸਿਸਟਮ ਡੇਟਾ ਕਿਸੇ ਹੋਰ ਰੀਜਨ ਵਿੱਚ ਕਾਪੀ ਜਾਂ ਮੂਵ ਕਰ ਸਕਦਾ ਹੈ (ਪਰਫਾਰਮੈਂਸ, ਆਊਟੇਜ ਰਿਕਵਰੀ, ਮੈਨਟੇਨੈਨਸ)? ਕਿਹੜੀਆਂ ਸ਼ਰਤਾਂ 'ਤੇ?
• ਮਾਨਵ ਐਕਸੈਸ ਪਾਥ: ਕੌਣ ਗਾਹਕ ਡੇਟਾ ਐਕਸੈਸ ਕਰ ਸਕਦਾ ਹੈ, ਕਿੱਥੋਂ, ਅਤੇ ਕੀ ਮਨਜ਼ੂਰੀ/ਲੌਗਿੰਗ ਹੈ?
• ਡੇਟਾ ਹੱਥ ਲਗਾਉਣ ਵਾਲੀਆਂ ਤੀਜੀਆਂ ਪਾਰਟੀਆਂ: ਕਿਹੜੇ ਵੇਂਡਰ ਡੇਟਾ ਨੂੰ ਛੂੰਹਦੇ ਹਨ (ਕਲਾਊਡ ਹੋਸਟਿੰਗ, ਈਮੇਲ/SMS, ਐਨਾਲਿਟਿਕਸ, AI ਮਾਡਲ ਪ੍ਰਦਾਤਾ), ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕੀ ਮਿਲਦਾ ਹੈ?

ਇਸ ਤੋਂ ਬਾਅਦ, ਗਾਹਕ ਕੰਟਰੋਲ ਆਮ ਭਾਸ਼ਾ ਵਿੱਚ ਵੇਖਾਓ: ਉਹ ਕੀ ਚੁਣ ਸਕਦੇ ਹਨ (ਜਿਵੇਂ ਰੀਜਨ), ਉਹ ਖੁਦ ਕੀ ਕਰ ਸਕਦੇ ਹਨ (ਏਕਸਪੋਰਟ), ਅਤੇ ਉਹ ਕੀ ਮੰਗ ਸਕਦੇ ਹਨ।

ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਆਖਰੀ ਸਨੈਤੀ ਚੈੱਕ

ਪੱਕਾ ਕਰੋ ਕਿ ਤੁਹਾਡਾ ਜਵਾਬ ਇਹ ਤਿੰਨ ਸਵਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ:

• “ਮੇਰਾ ਡੇਟਾ ਰੋਜ਼ਾਨਾ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ?”
• “ਕੀ ਇਹ ਓਥੇੋਂ ਬਾਹਰ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਦੋਂ?”
• “ਅਣਚਾਹੇ ਐਕਸੈਸ ਜਾਂ ਟ੍ਰਾਂਸਫਰ ਨੂੰ ਰੋਕਣ ਲਈ ਕੀ ਰੋਕ ਹੈ?”

ਦੂਜੇ-ਦੰਦ ਵਾਕ ਜੋ ਤੁਸੀਂ ਦੁਹਰਾ ਸਕਦੇ ਹੋ:

“ਤੁਹਾਡਾ ਮੁੱਖ ਡੇਟਾ [region] ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਬੈਕਅੱਪ [region] ਵਿੱਚ [time] ਲਈ ਰੱਖੇ ਜਾਂਦੇ ਹਨ। ਡੇਟਾ ਸਿਰਫ਼ [failover/replication rule] ਹੋਣ 'ਤੇ ਦੂਜੇ ਰੀਜਨ ਨੂੰ ਚੱਲ ਸਕਦਾ ਹੈ। ਐਕਸੈਸ [roles] ਤੱਕ ਸੀਮਿਤ ਹੈ ਅਤੇ ਲੌਗ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸਾਡੇ subprocessors ਵਿੱਚ [vendors] ਸ਼ਾਮਲ ਹਨ ਜੋ [purpose] ਲਈ ਹਨ।”

ਉਦਾਹਰਨ: ਇੱਕ ਅਸਲ ਗਾਹਕ ਸਵਾਲ ਦਾ ਜਵਾਬ (ਸਧਾਰਣ ਪਰਿਦ੍ਰਿਸ਼)

ਗermanyਚ ਵਿੱਚ ਇੱਕ ਗਾਹਕ ਈਮੇਲ ਕਰਦਾ ਹੈ: “ਕੀ ਸਾਡਾ ਡੇਟਾ EU ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ? ਅਤੇ ਜੇ ਆਊਟੇਜ ਹੋਵੇ ਤਾਂ ਕੀ ਤੁਸੀਂ ਇਸਨੂੰ ਕਿਸੇ ਹੋਰ ਸਥਾਨ 'ਤੇ ਲੈ ਜਾਓਗੇ?”

3-ਵਾਕਾਂ ਦਾ ਜਵਾਬ (ਕਾਪੀ/ਪੇਸਟ)

ਹਾਂ — ਅਸੀਂ ਤੁਹਾਡਾ ਐਪ ਅਤੇ ਡੇਟਾਬੇਸ EU ਰੀਜਨ ਵਿੱਚ ਹੋਸਟ ਕਰ ਸਕਦੇ ਹਾਂ, ਇਸ ਲਈ ਤੁਹਾਡਾ ਸਟੋਰ ਕੀਤਾ ਗਾਹਕ ਡੇਟਾ ਉੱਥੇ ਰਹਿੰਦਾ ਹੈ।

ਆਊਟੇਜ ਦੌਰਾਨ, ਅਸੀਂ ਆਪਣੀ-ਆਪ ਤੋਂ ਤੁਹਾਡਾ ਡੇਟਾ ਕਿਸੇ ਹੋਰ ਦੇਸ਼ ਵਿੱਚ ਨਹੀਂ ਲੈਂਦਾ ਜਦ ਤੱਕ ਤੁਸੀਂ ਪਹਿਲਾਂ ਫੇਲਓਵਰ ਸੈਟਅਪ ਦੀ ਮਨਜ਼ੂਰੀ ਨਾ ਦਿਓ।

ਜੇ ਤੁਸੀਂ ਸਾਨੂੰ ਦੱਸੋ ਕਿ ਕਿਹੜੇ EU ਦੇਸ਼/ਰੀਜਨ ਮਨਜ਼ੂਰ ਹਨ (ਅਤੇ ਕਿਹੜੇ ਨਹੀਂ), ਅਸੀਂ ਤੁਹਾਡੇ ਖਾਤੇ ਲਈ ਨਿਰਦਿੱਟ ਹੋਸਟਿੰਗ ਸਥਾਨ ਪੁਸ਼ਟੀ ਕਰਾਂਗੇ ਅਤੇ ਇਹ ਦਰਜ ਕਰਾਂਗੇ।

ਵਿਕਲਪਿਕ ਐਪੈਂਡਿਕਸ (ਕੇਵਲ ਜੇ ਉਹ ਪੁੱਛਣ)

“ਸਾਨੂੰ ਜਦੋਂ ਅਸੀਂ ਕਹਿੰਦੇ ਹਾਂ ‘ਡੇਟਾ EU ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ,’ ਅਸੀਂ ਉਹਨਾਂ ਮੁੱਖ ਸਿਸਟਮਾਂ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ ਜੋ ਇਸਨੂੰ ਸਟੋਰ ਕਰਦੇ ਹਨ: ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਿਸ, ਡੇਟਾਬੇਸ, ਅਤੇ ਫਾਇਲ ਸਟੋਰੇਜ।

ਆਊਟੇਜ ਲਈ ਦੋ ਆਮ ਤਰੀਕੇ ਹਨ:

• ਇਕ EU ਰੀਜਨ ਹੀ ਰਹਿਣਾ: ਰਿਹਾਇਸ਼ ਲਈ ਸਭ ਤੋਂ ਸਧਾਰਨ, ਪਰ ਜੇ ਪੂਰੀ ਰੀਜਨ ਠੀਕ ਨਹੀਂ ਤਾਂ ਰਿਕਵਰੀ ਲੰਬਾ ਹੋ ਸਕਦਾ ਹੈ।
• EU ਤੋਂ EU ਫੇਲਓਵਰ: ਸੇਵਾ ਦੂਜੇ EU ਰੀਜਨ ਵਿੱਚ ਚਲ ਸਕਦੀ ਹੈ ਜੇ ਪ੍ਰਾਇਮਰੀ ਡਾਊਨ ਹੋਵੇ, ਜਿਸ ਨਾਲ ਉਪਲਬਧਤਾ ਵਧਦੀ ਹੈ ਪਰ ਇਸ ਦੌਰਾਨ ਡੇਟਾ ਦੂਜੇ EU ਰੀਜਨ ਵਿੱਚ ਪ੍ਰੋਸੈਸ ਹੋ ਸਕਦਾ ਹੈ।

ਗਾਹਕ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਗੱਲਾਂ ਚਿੰਤਾਉਂਦੇ ਹਨ:

• ਬੈਕਅੱਪ ਅਤੇ ਸਨੇਪਸ਼ਾਟ ਮਨਜ਼ੂਰ ਰੀਜਨ(ਜ਼) ਵਿੱਚ ਰੱਖੇ ਜਾਂਦੇ ਹਨ।
• ਸਪੋਰਟ ਐਕਸੈਸ ਨਿਯੰਤਰਿਤ ਅਤੇ ਸੀਮਿਤ ਹੈ; ਇਹ ਡੇਟਾ ਦੇ ਹੋਸਟਿੰਗ ਰੀਜਨ ਨੂੰ ਬਦਲਦਾ ਨਹੀਂ।
• ਜੇ ਤੁਸੀਂ ਡੇਟਾ ਜਾਂ ਸੋর্স ਕੋਡ ਨਿਰਿਆਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਸਿਰਫ਼ ਤੁਹਾਡੀ ਬੇਨਤੀ 'ਤੇ ਪਲੇਟਫਾਰਮ ਤੋਂ ਨਿਕਲਦਾ ਹੈ।

ਕਿਰਿਆ ਲਈ: ਉਨ੍ਹਾਂ ਨੂੰ ਪੁੱਛੋ ਕਿ ਕਿਹੜੇ ਰੀਜਨ ਮਨਜ਼ੂਰ ਹਨ (ਉਦਾਹਰਣ ਲਈ, “ਸਿਰਫ EU, ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਦੂਜੇ EU ਰੀਜਨ ਨਾਲ ਵਿਕਲਪਿਕ ਫੇਲਓਵਰ”), ਫਿਰ ਚੋਣ ਨੂੰ ਆਨਬੋਰਡਿੰਗ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਦਰਜ ਕਰੋ।

FAQ ਅਤੇ ਅਗਲੇ ਕਦਮ (ਤੁਹਾਡੀ ਟੀਮ ਅਤੇ ਗਾਹਕਾਂ ਲਈ)

FAQ: ਡੇਟਾ ਸਿਰਫ਼ ਕਿੱਥੇ ਸਟੋਰ ਹੁੰਦਾ ਹੈ (ਰੀਜਨ ਵਿਰੁੱਧ ਦੇਸ਼)? ਸਪਸ਼ਟ ਜਵਾਬ: ਡੇਟਾ ਇੱਕ ਚੁਣੀ ਹੋਈ ਕਲਾਊਡ ਰੀਜਨ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਰੀਜਨ ਇੱਕ ਭੂਗੋਲਿਕ ਖੇਤਰ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ, ਪਰ ਇਹ ਹਮੇਸ਼ਾਂ ਇੱਕ ਹੀ ਦੇਸ਼ ਨਹੀਂ ਹੁੰਦੀ। ਜੇ ਗਾਹਕ ਨੂੰ ਕਿਸੇ ਖਾਸ ਦੇਸ਼ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕਿਹੜਾ ਰੀਜਨ ਉਸ ਲੋੜ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ।

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

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

FAQ: ਲਾਗ, ਐਨਾਲਿਟਿਕਸ, ਅਤੇ ਈਮੇਲ ਨੋਟੀਫਿਕੇਸ਼ਨ ਬਾਰੇ ਕੀ? ਇੱਥੇ ਗਲਤਫਹਮੀ ਹੁੰਦੀ ਹੈ। ਭਾਵੇਂ ਮੁੱਖ ਡੇਟਾਬੇਸ ਇਕ ਸਥਾਨ ਵਿੱਚ ਰਹੇ, ਸਹਾਇਕ ਡੇਟਾ ਲਾਗ, ਪ੍ਰਦਰਸ਼ਨ ਮੈਟਰਿਕਸ, ਆਡਿਟ ਟਰੇਲ ਅਤੇ ਈਮੇਲ (ਜਿਵੇਂ ਪਾਸਵਰਡ ਰੀਸੈੱਟ) ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ। ਦੱਸੋ ਕਿ ਇਹ ਸੰਭਵ ਤੌਰ 'ਤੇ ਨਿੱਜੀ ਡੇਟਾ ਰੱਖ ਸਕਦੇ ਹਨ, ਉਹ ਕਿੱਥੇ ਸਟੋਰ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਗਾਹਕ ਕੀ ਕਨਫਿਗਰ ਕਰ ਸਕਦੇ ਹਨ।

FAQ: ਗਾਹਕ ਕਿਹੜੇ ਕੰਟਰੋਲ ਚਲਾ ਸਕਦੇ ਹਨ ਜਾਂ ਮੰਗ ਸਕਦੇ ਹਨ? ਉਹ ਕੁਝ ਕੰਟਰੋਲ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਸਮਰਥਨ ਕਰ ਸਕਦੇ ਹੋ, ਉਦਾਹਰਣ ਲਈ:

• ਸ਼ੁਰੂ ਵਿੱਚ ਡਿਪਲੋਇਮੈਂਟ ਰੀਜਨ ਚੁਣਨਾ
• ਟੀਮ ਐਕਸੈਸ ਸੀਮਿਤ ਕਰਨਾ (ਰੋਲ-ਆਧਾਰਿਤ ਐਕਸੈਸ, ਘੱਟ ਤੋਂ ਘੱਟ ਅਧਿਕਾਰ)
• ਡੇਟਾ, ਲਾਗ ਅਤੇ ਬੈਕਅੱਪ ਲਈ ਰੀਟੈਂਸ਼ਨ ਨੀਤੀਆਂ ਸੈਟ ਕਰਨਾ
• ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਦੀ ਵਰਤੋਂ ਜਿੱਥੇ ਰੀਟੈਂਸ਼ਨ ਨਿਯਮ ਸਪਸ਼ਟ ਹੋਣ
• ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਐਪ ਜਾਂ ਕੋਡ ਦਾ ਏਕਸਪੋਰਟ ਕਰਨਾ

ਅਗਲੇ ਕਦਮ ਐਸਟਰਿਆ ਵਾਰਤੋਂ (country, region, backups, support access) ਨੂੰ ਜਲਦੀ ਕੈਪਚਰ ਕਰੋ ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਤੋਂ ਪਹਿਲਾਂ ਇਹਨੂੰ ਲਿਖੋ।

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