12 ਅਕਤੂ 2025·8 ਮਿੰਟ
ਡੇਟਾ ਰਹਾਇਸ਼ ਲਈ ਬਹੁ-ਖੇਤਰ ਹੋਸਟਿੰਗ: ਖੇਤਰ, ਲੇਟੈਂਸੀ, ਦਸਤਾਵੇਜ਼
ਜਾਣੋ ਕਿ ਡੇਟਾ ਰਹਾਇਸ਼ ਲਈ ਬਹੁ-ਖੇਤਰ ਹੋਸਟਿੰਗ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ: ਕਿਹੜੇ ਖੇਤਰ ਚੁਣੋ, ਲੇਟੈਂਸੀ ਕਿਵੇਂ ਸਮਭਾਲੀਏ, ਅਤੇ ਆਡੀਟ/ਗਾਹਕ ਸਮੀਖਿਆ ਲਈ ਡੇਟਾ ਫਲੋ ਦਸਤਾਵੇਜ਼ ਕਿਵੇਂ ਤਿਆਰ ਕਰੋ।
ਜਾਣੋ ਕਿ ਡੇਟਾ ਰਹਾਇਸ਼ ਲਈ ਬਹੁ-ਖੇਤਰ ਹੋਸਟਿੰਗ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ: ਕਿਹੜੇ ਖੇਤਰ ਚੁਣੋ, ਲੇਟੈਂਸੀ ਕਿਵੇਂ ਸਮਭਾਲੀਏ, ਅਤੇ ਆਡੀਟ/ਗਾਹਕ ਸਮੀਖਿਆ ਲਈ ਡੇਟਾ ਫਲੋ ਦਸਤਾਵੇਜ਼ ਕਿਵੇਂ ਤਿਆਰ ਕਰੋ।
ਡੇਟਾ ਰਹਾਇਸ਼ ਵਾਲੇ ਸਵਾਲ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਧਾਰਨ ਗਾਹਕ ਦੇ ਪੁੱਛਨ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ: “ਕੀ ਤੁਸੀਂ ਸਾਡਾ ਡੇਟਾ ਸਾਡੇ ਦੇਸ਼ ਵਿੱਚ ਰੱਖ ਸਕਦੇ ਹੋ?” ਮੁਸ਼ਕਲ ਇਹ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਦੇ ਯੂਜ਼ਰ, ਐਡਮਿਨ, ਅਤੇ ਸਪੋਰਟ ਟੀਮਾਂ ਗਲੋਬਲ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਬਹੁ-ਖੇਤਰ ਹੋਸਟਿੰਗ ਇਸ ਤਰ੍ਹਾਂ ਹੈ ਜੋ ਤੁਸੀਂ ਸਥਾਨਕ ਸਟੋਰੇਜ ਦੀਆਂ ਲੋੜਾਂ ਪੂਰੀਆਂ ਕਰ ਸਕੋ ਬਿਨਾਂ ਰੋਜ਼ਾਨਾ ਕੰਮ ਨੂੰ ਰੋਕੇ।
ਇਹ ਚੋਣ ਤਿੰਨ ਵਿਹਾਰਕ ਫੈਸਲਿਆਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ:
ਜੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਤੱਤ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਖੇਤਰ ਤੋਂ ਬਾਹਰ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਮੁੱਖ ਡੇਟਾਬੇਸ “ਲੋਕਲ” ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਵੀ ਤੁਸੀਂ ਕ੍ਰਾਸ-ਬੋਰਡਰ ਟ੍ਰਾਂਸਫਰ ਕਰ ਸਕਦੇ ਹੋ।
ਬਹੁ-ਖੇਤਰ ਸੈਟਅਪਾਂ ਨਾਲ ਅਨੁਕੂਲਤਾ ਵਿੱਚ ਮਦਦ ਮਿਲਦੀ ਹੈ, ਪਰ ਇਹ ਮੁਫ਼ਤ ਨਹੀਂ। ਤੁਸੀਂ ਸਧਾਰਣਤਾ ਨੂੰ ਨਿਯੰਤਰਣ ਲਈ ਤਿਆਗ ਕਰਦੇ ਹੋ। ਖਰਚ ਵੱਧਦੇ ਹਨ (ਵਧੇ ਹੋਏ ਢਾਂਚੇ ਅਤੇ ਨਿਗਰਾਨੀ)। ਜਟਿਲਤਾ ਵੀ ਵੱਧਦੀ ਹੈ (ਰੀਪਲੀਕੇਸ਼ਨ, ਫੇਲਓਵਰ, ਖੇਤਰ-ਨਿਰਧਾਰਿਤ ਕਨਫਿਗਰੇਸ਼ਨ)। ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ ਵੀ ਅਸਰ ਪੈ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਤੁਾਨੂੰ ਬੇਹੱਦ ਕਰਨਾ ਪੈ ਸਕਦਾ ਹੈ ਕਿ ਬੇਨਤੀ ਅਤੇ ਪ੍ਰੋਸੈਸਿੰਗ ਖੇਤਰ ਦੇ ਅੰਦਰ ਹੀ ਰਹਿਣ।
ਇੱਕ ਆਮ ਉਦਾਹਰਨ: ਇੱਕ EU ਗਾਹਕ EU-ਸਿਰਫ਼ ਸਟੋਰੇਜ ਚਾਹੁੰਦਾ ਹੈ, ਪਰ ਉਨ੍ਹਾਂ ਦੀਆੰਅਧੀ ਕੰਮਦਾਰੀਆਂ US ਵਿੱਚ ਹਨ। ਜੇ US-ਆਧਾਰਿਤ ਐਡਮਿਨ ਲੌਗਇਨ ਕਰਕੇ ਐਕਸਪੋਰਟ ਚਲਾਉਂਦੇ ਹਨ, ਤਾਂ ਇਹ ਐਕਸੈੱਸ ਅਤੇ ਟ੍ਰਾਂਸਫਰ ਸਵਾਲ ਉਠਾਉਂਦਾ ਹੈ। ਸਾਫ਼ ਸੈਟਅਪ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕੀ EU ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਕੀ ਦੂਰੋਂ ਐਕਸੈੱਸ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਿਹੜੀਆਂ ਸੁਰੱਖਿਆਆਂ ਲਾਗੂ ਹਨ।
ਜਿਆਦਾਤਰ ਟੀਮਾਂ ਹੋਸਟਿੰਗ ਖੇਤਰਾਂ ਨੂੰ ਤਬ ਤੱਕ ਮੁੜ-ਵਿਚਾਰ ਦੇਂਦੀਆਂ ਹਨ ਜਦੋਂ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਚੀਜ਼ ਆਉਂਦੀ ਹੈ:
ਡੇਟਾ ਰਹਾਇਸ਼ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਤੁਹਾਡਾ ਡੇਟਾ "ਅਟ-ਰੇਸਟ" ਸਟੋਰ ਹੁੰਦਾ ਹੈ। ਸੋਚੋ ਡੇਟਾਬੇਸ ਫਾਈਲਾਂ, ਆਬਜੈਕਟ ਸਟੋਰੇਜ ਅਤੇ ਡਿਸਕਾਂ 'ਤੇ ਬੈਕਅਪ।
ਲੋਕ ਅਕਸਰ ਰਹਾਇਸ਼ ਨੂੰ ਡੇਟਾ ਐਕਸੈੱਸ ਅਤੇ ਡੇਟਾ ਟ੍ਰਾਂਸਫਰ ਨਾਲ ਮਿਲਾ ਦਿੰਦੇ ਹਨ। ਐਕਸੈੱਸ ਇਹ ਹੈ ਕਿ ਕੌਣ ਡੇਟਾ ਨੂੰ ਪੜ੍ਹ ਸਕਦਾ ਜਾਂ ਬਦਲ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਕਿਸੇ ਹੋਰ ਦੇਸ਼ ਵਿੱਚ ਸਪੋਰਟ ਇੰਜੀਨੀਅਰ)। ਟ੍ਰਾਂਸਫਰ ਇਹ ਹੈ ਕਿ ਡੇਟਾ ਕਿੱਧਰ ਯਾਤਰਾ ਕਰਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ API ਕਾਲ ਜੋ ਸਰਹੱਦ ਲਾਂਘਦੀ ਹੈ)। ਤੁਸੀਂ ਰਹਾਇਸ਼ ਨਿਯਮ ਪੂਰੇ ਕਰ ਸਕਦੇ ਹੋ ਪਰ ਅਜੇ ਵੀ ਟ੍ਰਾਂਸਫਰ ਨਿਯਮ ਤੋੜ ਸਕਦੇ ਹੋ ਜੇ ਡੇਟਾ ਰੁਟੀਨ ਤੌਰ 'ਤੇ ਕਿਸੇ ਹੋਰ ਖੇਤਰ ਨੂੰ ਭੇਜਿਆ ਜਾ ਰਿਹਾ ਹੋਵੇ (ਐਨਾਲਿਟਿਕਸ, ਮਾਨੀਟਰੀਂਗ, ਸਪੋਰਟ)।
ਪ੍ਰੋਸੈਸਿੰਗ ਦਾ ਮਤਲਬ ਹੈ ਤੁਹਾਡੀ ਡੇਟਾ ਨਾਲ ਕੀ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ: ਸਟੋਰ ਕਰਨਾ, ਇੰਡੈਕਸ ਕਰਨਾ, ਖੋਜਣਾ, ਟ੍ਰੇਨ ਕਰਨਾ, ਜਾਂ ਰਿਪੋਰਟ ਤਿਆਰ ਕਰਨਾ। ਪ੍ਰੋਸੈਸਿੰਗ ਸਟੋਰੇਜ ਨਾਲ ਵੱਖਰੀ ਥਾਂ 'ਤੇ ਹੋ ਸਕਦੀ ਹੈ, ਇਸ ਲਈ ਅਕਸਰ ਕੰਪਲਾਇੰਸ ਟੀਮਾਂ ਦੋਹਾਂ ਦੀ ਮੰਗ ਕਰਦੀਆਂ ਹਨ।
ਇਹ ਗੱਲਾਂ ਨੂੰ ਠੋਸ ਬਣਾਉਣ ਲਈ, ਆਪਣਾ ਡੇਟਾ ਕੁਝ ਆਮ ਬੱਕੇਟਾਂ ਵਿੱਚ ਗਰੁੱਪ ਕਰੋ: ਗਾਹਕ ਸਮੱਗਰੀ (ਫਾਇਲਾਂ, ਸੁਨੇਹੇ, ਅਪਲੋਡ), ਖਾਤਾ ਅਤੇ ਬਿੱਲਿੰਗ ਡੇਟਾ, ਮੇਟਾ ਡੇਟਾ (IDs, ਟਾਈਮਸਟੈਂਪ, ਕਾਨਫ਼ਿਗ), ਓਪਰੇਸ਼ਨਲ ਡੇਟਾ (ਲੌਗ ਅਤੇ ਸੁਰੱਖਿਆ ਘਟਨਾਵਾਂ), ਅਤੇ ਰਿਕਵਰੀ ਡੇਟਾ (ਬੈਕਅਪ ਅਤੇ ਰੇਪਲਿਕਾ)।
ਸਮੀਖਿਆ ਦੌਰਾਨ, ਤੁਹਾਨੂੰ ਜ਼ਰੂਰ ਦੋ ਚੀਜ਼ਾਂ ਪੁੱਛੀਆਂ ਜਾਣਗੀਆਂ: ਹਰ ਬੱਕੇਟ ਕਿੱਥੇ ਸਟੋਰ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇਹ ਕਿੱਥੇ ਜਾ ਸਕਦੀ ਹੈ। ਗਾਹਕ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਵੀ ਪੁੱਛ ਸਕਦੇ ਹਨ ਕਿ ਮਨੁੱਖੀ ਐਕਸੈੱਸ ਕਿਵੇਂ ਨਿਯੰਤਰਿਤ ਹੁੰਦੀ ਹੈ।
ਇੱਕ ਵਿਹਾਰਕ ਉਦਾਹਰਨ: ਤੁਹਾਡਾ ਪ੍ਰਿੰਸੀਪਲ ਡੇਟਾਬੇਸ ਜਰਮਨੀ ਵਿੱਚ ਹੈ (ਸਟੋਰੇਜ), ਪਰ ਤੁਹਾਡੀ ਐਰਰ ਟ੍ਰੈਕਿੰਗ US ਵਿੱਚ ਹੈ (ਟ੍ਰਾਂਸਫਰ)। ਗਾਹਕ ਸਮੱਗਰੀ ਜੇ ਜਰਮਨੀ ਨੂੰ ਕਦੇ ਨਹੀਂ ਛੱਡਦੀ, ਫਿਰ ਵੀ ਲੌਗਾਂ ਵਿੱਚ ਯੂਜ਼ਰ IDs ਜਾਂ ਰਿਕਵੇਸਟ ਸਿ੍ਨਿਪੈਟ ਹੋ ਸਕਦੇ ਹਨ ਜੋ ਬਾਹਰ ਜਾ ਰਹੇ ਹੋਣ। ਇਸ ਲਈ ਲੌਗ ਅਤੇ ਐਨਾਲਿਟਿਕਸ ਦਾ ਅਲੱਗ ਉਲੇਖ ਤੁਹਾਡੀ ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਦਸਤਾਵੇਜ਼ ਬਣਾਉਂਦੇ ਸਮੇਂ, ਇਹਨਾਂ ਸਵਾਲਾਂ ਦਾ ਉੱਤਰ ਦਿਓ:
ਸਾਫ਼ ਸ਼ਬਦ ਅੱਗੇ ਰੱਖਣ ਨਾਲ ਬਾਅਦ ਵਿੱਚ ਸਮਾਂ ਬਚਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਗਾਹਕ ਇੱਕ ਸਰਲ, ਭਰੋਸੇਯੋਗ ਵਿਆਖਿਆ ਚਾਹੁੰਦੇ ਹੋਣ।
ਖੇਤਰਾਂ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ, ਆਪਣਾ ਡੇਟਾ ਅਤੇ ਸਿਸਟਮਾਂ ਦੀ ਗ੍ਰਿਫਤ ਲਿਖੋ ਕਿ ਡੇਟਾ ਤੁਹਾਡੇ ਸਟੈਕ ਨੂੰ ਕਿੱਥੇ-ਕਿੱਥੇ ਛੂੰਹਦਾ ਹੈ। ਇਹ ਬੁਨਿਆਦੀ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਹ "ਸੋਚਿਆ ਸੀ ਕਿ ਇਹ ਇਨ-ਰੀਜਨ ਰਹਿੰਦਾ ਹੈ" ਵਾਲੀਆਂ ਤਰਫ਼ੀਆਂ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਡੇਟਾ ਕਿਸਮਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਕਾਨੂੰਨਾਂ ਨਾਲ ਨਹੀਂ। ਜ਼ਿਆਦਾਤਰ ਪ੍ਰੋਡਕਟ ਮਿਲੇ-ਜੁਲੇ ਡੇਟਾ ਹੰਢਲ ਕਰਦੇ ਹਨ: ਗਾਹਕ ਖਾਤਾ ਵੇਰਵੇ (PII), ਭੁਗਤਾਨ ਰਿਕਾਰਡ, ਸਹਾਇਤਾ ਗੱਲਬਾਤਾਂ, ਅਤੇ ਪੈਦਾਇਸ਼ਕ ਟੈਲੀਮੇਟਰੀ ਜਿਵੇਂ ਲੌਗ ਅਤੇ ਇਵੈਂਟ। ਡੈਰੀਵਡ ਡੇਟਾ ਵੀ ਸ਼ਾਮਿਲ ਕਰੋ, ਜਿਵੇਂ ਰਿਪੋਰਟ, ਐਨਾਲਿਟਿਕਸ ਟੇਬਲ ਅਤੇ AI-ਤਿਆਰ ਸੰਖੇਪ।
ਫਿਰ ਹਰ ਉਹ ਸਿਸਟਮ ਲਿਖੋ ਜੋ ਉਸ ਡੇਟਾ ਨੂੰ ਦੇਖ ਸਕਦਾ ਜਾਂ ਸਟੋਰ ਕਰ ਸਕਦਾ ਹੈ: ਐਪ ਸਰਵਰ, ਡੇਟਾਬੇਸ, ਅਪਲੋਡ ਲਈ ਆਬਜੈਕਟ ਸਟੋਰੇਜ, ਈਮੇਲ ਅਤੇ SMS ਪ੍ਰੋਵਾਈਡਰ, ਏਰਰ ਮਾਨੀਟਰੀਂਗ, ਗਾਹਕ ਸਹਾਇਤਾ ਟੂਲ, ਅਤੇ CI/CD ਜਾਂ ਐਡਮਿਨ ਕੰਸੋਲ। ਜੇ ਤੁਸੀਂ ਸਨੇਪਸ਼ਾਟ, ਬੈਕਅਪ, ਜਾਂ ਐਕਸਪੋਰਟ ਵਰਤਦੇ ਹੋ, ਉਹਨਾਂ ਨੂੰ ਵੱਖਰੇ ਡੇਟਾ ਸਟੋਰ ਵਜੋਂ ਮੰਨੋ।
ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਡੇਟਾ ਦਾ ਲਾਈਫਸਾਇਕਲ ਕੈਪਚਰ ਕਰੋ: ਡੇਟਾ ਕਿਵੇਂ ਇਕੱਠਾ ਹੁੰਦਾ ਹੈ, ਕਿੱਥੇ ਸਟੋਰ ਹੁੰਦਾ ਹੈ, ਕੀ ਪ੍ਰੋਸੈਸ ਹੁੰਦਾ ਹੈ (ਸਰਚ, ਬਿੱਲਿੰਗ, ਮਾਡਰੇਸ਼ਨ), ਕਿਸ ਨਾਲ ਸਾਂਝਾ ਹੁੰਦਾ ਹੈ (ਵੇਂਡਰ, ਅੰਦਰੂਨੀ ਟੀਮ), ਕਿੰਨਾ ਸਮਾਂ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਡਿਲੀਸ਼ਨ ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ (ਬੈਕਅਪ ਸਮੇਤ)।
ਇਨਵੇਂਟਰੀ ਵਰਤਣਯੋਗ ਰੱਖੋ। ਇੱਕ ਛੋਟੀ ਚੈਕਲਿਸਟ ਕਾਫ਼ੀ ਹੁੰਦੀ ਹੈ: ਡੇਟਾ ਕਿਸਮ, ਸਿਸਟਮ, ਖੇਤਰ (ਸਟੋਰੇਜ ਅਤੇ ਪ੍ਰੋਸੈਸਿੰਗ), ਕੀ ਚੀਜ਼ ਹਿਲਾਉਂਦੀ ਹੈ (ਯੂਜ਼ਰ ਕਾਰਵਾਈ, ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ, ਸਪੋਰਟ ਰਿਕਵੇਸਟ), ਅਤੇ ਰੈਟੇਨਸ਼ਨ।
ਖੇਤਰ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਸਧਾਰਣ ਤਸਵੀਰ ਬਣਾਓ ਕਿ ਡੇਟਾ ਅਸਲ ਵਿੱਚ ਕਿੱਦਾਂ ਜਾਂਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਪਰਸਾਧਿਕ ਤਰੀਕੇ ਨਾਲ ਨਿਯਮਾਂ ਦਾ ਸਪਸ਼ਟ ਵੇਰਵਾ ਨਹੀਂ ਦੇ ਸਕਦੇ ਤਾਂ ਰੀਜਨ ਯੋਜਨਾ ਕੇਵਲ ਕਾਗਜ਼ੀ ਵਿਫਲ ਹੋ ਸਕਦੀ ਹੈ।
ਇੱਕ ਸਧਾਰਨ-ਭਾਸ਼ਾ ਆਰੇਖ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇਕ ਪੰਨਾ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ। ਇਸਨੂੰ ਇੱਕ ਕਹਾਣੀ ਵਾਂਗ ਲਿਖੋ: ਯੂਜ਼ਰ ਸਾਈਨ-ਇਨ ਕਰਦਾ ਹੈ, ਐਪ ਵਰਤਦਾ ਹੈ, ਡੇਟਾ ਸਟੋਰ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਸਹਾਇਕ ਸਿਸਟਮ ਕੀ ਦਰਜ ਕਰਦੇ ਹਨ। ਫਿਰ ਹਰ ਕਦਮ ਨੂੰ ਦੋ ਗੱਲਾਂ ਨਾਲ ਲੇਬਲ ਕਰੋ: ਕਿੱਥੇ ਚੱਲਦਾ ਹੈ (ਖੇਤਰ ਜਾਂ ਦੇਸ਼), ਅਤੇ ਕੀ ਡੇਟਾ ਅਟ-ਰੇਸਟ ਹੈ (ਸਟੋਰ) ਜਾਂ ਇਨ-ਟ੍ਰਾਂਜ਼ਿਟ ਹੈ (ਹਿਲ ਰਿਹਾ)।
ਖੁਸ਼-ਮਾਰਗ ਤੱਕ ਹੀ ਨਾ ਰੁੱਕੋ। ਜਿਹੜੇ ਫਲੋ ਅਕਸਰ ਲੋਕਾਂ ਨੂੰ ਹੈਰਾਨ ਕਰਦੇ ਹਨ ਉਹ ਓਪਰੇਸ਼ਨਲ ਹਨ: ਸਪੋਰਟ ਟਿਕਟ ਵਿੱਚ ਸਕ੍ਰੀਨਸ਼ੌਟ ਖੋਲ੍ਹਣਾ, ਇਨਸਿਡੈਂਟ ਰਿਸਪਾਂਸ ਸੈਸ਼ਨ ਵਿੱਚ ਅਸਥਾਈ ਐਕਸੈੱਸ, ਡੇਟਾਬੇਸ ਰੀਸਟੋਰ ਬੈਕਅਪ ਤੋਂ, ਜਾਂ ਗਾਹਕ ਲਈ ਐਕਸਪੋਰਟ।
ਨਕਸ਼ੇ ਨੂੰ ਸਚਾਈ ਨਾਲ ਰੱਖਣ ਦਾ ਇੱਕ ਤੇਜ਼ ਤਰੀਕਾ ਇਹ ਕਵਰ ਕਰਨਾ ਹੈ:
ਤੀਜੇ-ਪੱਖੀਆਂ ਨੂੰ ਵੀ ਸ਼ਾਮਿਲ ਕਰੋ, ਭਾਵੇਂ ਉਹ ਛੋਟੇ ਲੱਗਣ। ਭੁਗਤਾਨ, ਈਮੇਲ ਡਿਲਿਵਰੀ, ਐਨਾਲਿਟਿਕਸ, ਅਤੇ ਗਾਹਕ ਸਹਾਇਤਾ ਟੂਲ ਅਕਸਰ শনਾਖਤਾਂ ਪ੍ਰੋਸੈਸ ਕਰਦੇ ਹਨ। ਦਰਜ ਕਰੋ ਕਿ ਉਹ ਕਿਹੜਾ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ, ਕਿੱਥੇ ਪ੍ਰੋਸੈਸ ਕਰਦੇ ਹਨ, ਅਤੇ ਕੀ ਤੁਸੀਂ ਉਹਨਾਂ ਦਾ ਖੇਤਰ ਚੁਣ ਸਕਦੇ ਹੋ।
ਜਦ ਨਕਸ਼ਾ ਸਪਸ਼ਟ ਹੋ ਜਾਵੇ, ਤਾਂ ਖੇਤਰ ਚੋਣ ਮੈਚਿੰਗ ਬਣ ਜਾਂਦੀ ਹੈ, ਅਨੁਮਾਨ ਨਹੀਂ।
ਕਲਾਉਡ ਨਕਸ਼ੇ ਤੋਂ ਪਹਿਲਾਂ ਨਿਯਮ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਪੁੱਛੋ ਕਿ ਤੁਹਾਡੇ ਗਾਹਕ ਜਾਂ ਨਿਯੰਤਰਕ ਅਸਲ ਵਿੱਚ ਕੀ ਮੰਗਦੇ ਹਨ: ਡੇਟਾ ਕਿਸ ਦੇਸ਼ (ਜਾਂ ਦੇਸ਼ਾਂ ਦੇ ਸਮੂਹ) ਵਿੱਚ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਹੜੇ ਸਥਾਨ ਖਾਸ ਤੌਰ 'ਤੇ ਮਨ੍ਹੂਰ ਨਹੀਂ, ਅਤੇ ਕੀ ਕੋਈ ਸੰਕੁਚਿਤ ਛੋਟ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਹੋਰ ਦੇਸ਼ ਤੋਂ ਸਪੋਰਟ ਐਕਸੈੱਸ ਦੀ ਆਗਿਆ)।
ਇੱਕ ਮੁੱਖ ਫੈਸਲਾ ਇਹ ਹੈ ਕਿ ਸਰਹੱਦ ਕਿੰਨੀ ਸਖ਼ਤ ਹੈ। ਕੁਝ ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ ਇੱਕ-ਦੇਸ਼ ਹੀ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ: ਸਟੋਰੇਜ, ਬੈਕਅਪ, ਅਤੇ ਐਡਮਿਨ ਐਕਸੈੱਸ ਇੱਕ ਹੀ ਦੇਸ਼ ਵਿੱਚ। ਹੋਰਾਂ ਨੂੰ ਵੱਡੇ ਖੇਤਰ (ਜਿਵੇਂ ਇੱਕ ਆਰਥਿਕ ਜੋਨ) ਦੀ ਆਗਿਆ ਹੋ ਸਕਦੀ ਹੈ, ਬੱਸ ਤੁਸੀਂ ਦੱਸ ਸਕਦੇ ਹੋ ਕਿ ਡੇਟਾ ਕਿੱਥੇ ਹੈ ਅਤੇ ਕੌਣ ਪਹੁੰਚਦਾ ਹੈ।
ਕਿਸੇ ਵੀ ਖੇਤਰ ਨੂੰ ਫਾਇਨਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹਰੇਕ ਉਮੀਦਵਾਰ ਖੇਤਰ ਨੂੰ ਇਹਨਾਂ ਵਿਰੱਧ ਜਾਚੋ:
ਨਜ਼ਦੀਕੀ ਅਜੇ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਪਰ ਇਹ ਦੂਜਾ ਕਦਮ ਹੈ। ਉਪਭੋਗਤਿਆਂ ਲਈ ਪ੍ਰਦਰਸ਼ਨ ਵਾਸਤੇ ਸਭ ਤੋਂ ਨੇੜਲਾ ਅਨੁਕੂਲ ਖੇਤਰ ਚੁਣੋ, ਫਿਰ ਓਪਰੇਸ਼ਨ ਨੂੰ ਪ੍ਰਕਿਰਿਆ ਅਤੇ ਐਕਸੈੱਸ ਕੰਟਰੋਲ ਨਾਲ ਸੰਭਾਲੋ (ਰੋਲ-ਅਧਾਰਿਤ ਐਕਸੈੱਸ, ਮੰਜ਼ੂਰੀਆਂ, break-glass ਖਾਤੇ)।
ਆਖ਼ਿਰ ਵਿੱਚ, ਫੈਸਲਾ ਲਿਖੋ: ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਸੀਮਾ, ਚੁਣੇ ਖੇਤਰ, ਫੇਲਓਵਰ ਯੋਜਨਾ, ਅਤੇ ਜੋ ਡੇਟਾ ਛੱਡ ਸਕਦਾ/ਸੱਕਦੀ ਹੈ (ਜੇ ਕੋਈ)। ਉਹ ਇਕ-ਪੰਨਾ ਬਹੁ ਘੰਟਿਆਂ ਦੀ ਪ੍ਰਸ਼ਨਾਵਲੀਆਂ ਨੂੰ ਬਚਾ ਸਕਦਾ ਹੈ।
ਲੇਟੈਂਸੀ ਅਕਸਰ ਭੌਤਿਕੀ ਦੂਰੀ ਅਤੇ ਬਾਰ-ਬਾਰ ਡੇਟਾ ਲਈ ਪੁੱਛਣ ਦੀ ਗਿਣਤੀ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ। ਦੂਰੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਪਰ ਵੱਧ ਡੀਬੀ ਰਾਊਂਡ-ਟ੍ਰਿਪ, ਨੈੱਟਵਰਕ ਰੂਟਿੰਗ, ਅਤੇ ਸਕੇਲ ਹੋਣ 'ਤੇ ਸਲੋ ਸਟਾਰਟ ਵੀ ਪ੍ਰਭਾਵ ਪਾਉਂਦੇ ਹਨ।
ਕੋਸ਼ਿਸ਼ ਕਰੋ ਮਾਪਣ ਤੋਂ ਪਹਿਲਾਂ ਕਦੇ ਵੀ ਬਦਲਾਅ ਨਾ ਕਰੋ। 3-5 ਮੁੱਖ ਯੂਜ਼ਰ ਐਕਸ਼ਨਾਂ (ਲੌਗਇਨ, ਡੈਸ਼ਬੋਰਡ ਲੋਡ, ਆਰਡਰ ਬਣਾਉ, ਖੋਜ, ਐਕਸਪੋਰਟ) ਨੂੰ ਚੁਣੋ ਅਤੇ ਉਨ੍ਹਾਂ ਦਾ p50 ਅਤੇ p95 ਟ੍ਰੈਕ ਕਰੋ। ਇਹ ਨੰਬਰ ਰਿਲੀਜ਼ਾਂ ਵਿੱਚ ਤੁਲਨਾ ਲਈ ਰੱਖੋ।
ਸਧਾਰਨ ਨਿਯਮ: ਸੰਰੱਖਿਆ ਕੀਤੇ ਡੇਟਾ ਅਤੇ ਉਹ ਰਾਸਤੇ ਜੋ ਉਨ੍ਹਾਂ ਨੂੰ ਛੂਹਦੇ ਹਨ, ਸਥਾਨਕ ਰੱਖੋ, ਫਿਰ ਬਾਕੀ ਸਭ ਨੂੰ ਗਲੋਬਲ-ਫ੍ਰੈਂਡਲੀ ਬਣਾਓ। ਸਭ ਤੋਂ ਵੱਡੀਆਂ ਪ੍ਰਦ eਸ਼ਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਕਸਰ cross-region ਚੈਟਰ ਘਟਾ ਕੇ ਮਿਲਦੀਆਂ ਹਨ।
ਜੇ ਜਰਮਨੀ ਵਿੱਚ ਇੱਕ ਯੂਜ਼ਰ ਦਾ ਡੇਟਾ EU ਵਿੱਚ ਰਹਿਣਾ ਜਰੂਰੀ ਹੈ, ਤਾਂ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਕਿ ਉਸ ਟੇਨੈਂਟ ਲਈ ਐਪ ਸਰਵਰ, ਪ੍ਰਾਇਮਰੀ ਡੇਟਾਬੇਸ, ਅਤੇ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ EU ਵਿੱਚ ਹੀ ਚੱਲਣ। ਹਰ ਰਿਕਵੇਸਟ 'ਤੇ ਦੂਜੇ ਖੇਤਰ ਨੂੰ ਬਾਉਂਸ ਕਰਕੇ ਆਥ/ਸੈਸ਼ਨ ਚੈੱਕ ਨਾ ਕਰੋ। ਇਕ ਪੇਜ ਲਈ ਡੇਟਾਬੇਸ ਕਾਲਾਂ ਘਟਾਓ।
ਕੈਸ਼ਿੰਗ ਮਦਦ ਕਰਦੀ ਹੈ, ਪਰ ਦੇਖਭਾਲ ਕਰੋ ਕਿ ਕੈਸ਼ ਕਿੱਥੇ ਰੱਖਦੇ ਹੋ। ਜਨਤਕ ਜਾਂ ਗੈਰ-ਸੰਵੇਦਨਸ਼ੀਲ ਸਮੱਗਰੀ ਗਲੋਬਲੀ ਸਰਵ ਕਰੋ। ਟੇਨੈਂਟ-ਖਾਸ ਜਾਂ ਨਿਯਮਤ ਡੇਟਾ ਨੂੰ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਖੇਤਰ ਵਿੱਚ ਰੱਖੋ। ਬੈਚ ਪ੍ਰੋਸੈਸਿੰਗ ਵੀ ਮਦਦਗਾਰ ਹੋ ਸਕਦੀ ਹੈ: ਇੱਕ ਸ਼ੈਡਿਊਲ ਅਪਡੇਟ ਦਰਜਨਾਂ ਛੋਟੀਆਂ cross-region ਬੇਨਤੀਆਂ ਨਾਲੋਂ ਬਿਹਤਰ ਹੁੰਦੀ ਹੈ।
ਹਰ ਚੀਜ਼ ਨੂੰ ਇੱਕੋ ਹੀ ਗਤੀ ਦੀ ਲੋੜ ਨਹੀਂ। ਲੌਗਇਨ ਅਤੇ ਕੋਰ ਸੇਵ ਕਾਰਵਾਈਆਂ ਨੂੰ “ਫੌਰਨ-ਫੀਲ” ਕਰਵਾਉਣ ਵਾਂਗ ਰੱਖੋ। ਰਿਪੋਰਟ, ਐਕਸਪੋਰਟ, ਅਤੇ ਐਨਾਲਿਟਿਕਸ ਨੂੰ ਦੂਜੀ ਪੋਰਟੀ ਦੇ ਰੂਪ ਵਿੱਚ ਧੀਮਾ ਰੱਖ ਸਕਦੇ ਹੋ ਜੇ ਉਮੀਦਾਂ ਸੈੱਟ ਕੀਤੀਆਂ ਜਾਣ।
ਸਟੇਟਿਕ ਐਸੈਟ ਆਮ ਤੌਰ ਤੇ ਸਹੀ ਜਗ੍ਹਾ ਹਨ: ਜਾਵਾਸਕ੍ਰਿਪਟ ਬੰਡਲ ਅਤੇ ਚਿੱਤਰ ਯੂਜ਼ਰਾਂ ਦੇ ਨੇੜੇ ਗਲੋਬਲ ਤੌਰ 'ਤੇ ਸਰਵ ਕਰੋ, ਜਦਕਿ APIs ਅਤੇ ਨਿੱਜੀ ਡੇਟਾ ਰਹਾਇਸ਼ ਖੇਤਰ ਵਿੱਚ ਰੱਖੋ।
ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਸ਼ੁਰੂਆਤ ਇਹ ਹੈ ਕਿ ਗਾਹਕ ਡੇਟਾ ਇੱਕ ਖੇਤਰ ਨਾਲ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਐਂਕਰ ਕੀਤਾ ਹੋਵੇ, ਫਿਰ ਵੀ ਆਪਾਤਕਾਲੀ ਬਹਾਲੀ ਲਈ ਰਸਤਾ ਹੋਵੇ।
Active-passive ਅਕਸਰ ਆਡੀਟਰਾਂ ਅਤੇ ਗਾਹਕਾਂ ਨੂੰ ਸਮਝਾਉਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਖੇਤਰ ਟੇਨੈਂਟ ਲਈ ਪ੍ਰਾਈਮਰੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਦੂਸਰਾ ਸਿਰਫ ਫੇਲਓਵਰ ਜਾਂ ਸੰਯਮਤ ਡੀਐਸਆਰ ਲਈ।
Active-active ਡਾਉਨਟਾਈਮ ਘਟਾ ਸਕਦਾ ਹੈ ਅਤੇ ਸਥਾਨਕ ਗਤੀ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਮੁੱਛ ਪਲੇਸ਼ਾਂ ਖੜੀਆਂ ਕਰਦਾ ਹੈ: ਕਿਹੜਾ ਖੇਤਰ ਸਚਾਈ ਦਾ ਸਰੋਤ ਹੈ, ਡ੍ਰਿਫਟ ਕਿਵੇਂ ਰੋਕੀ ਜਾਵੇ, ਅਤੇ ਕੀ ਰੀਪਲੀਕੇਸ਼ਨ ਖੁਦ ਟ੍ਰਾਂਸਫਰ ਮਾਨੀ ਜਾਵੇਗੀ?
ਪ੍ਰਯੋਗਾਤਮਕ ਚੁਣਾਅ:
ਡੇਟਾਬੇਸਾਂ ਲਈ, ਪ੍ਰਤੀ-ਟੇਨੈਂਟ ਰੀਜਨਲ ਡੇਟਾਬੇਸ ਸਭ ਤੋਂ ਸਾਫ-ਸੁਧਰ ਹੁੰਦੇ ਹਨ: ਹਰ ਟੇਨੈਂਟ ਦਾ ਡੇਟਾ ਇੱਕ ਰੀਜਨਲ Postgres ਉਦਾਹਰਣ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਕ੍ਰਾਸ-ਟੇਨੈਂਟ ਕਵੇਰੀਆਂ ਮੁਸ਼ਕਿਲ ਬਣ ਜਾਂਦੀਆਂ ਹਨ।
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਛੋਟੇ ਟੇਨੈਂਟ ਹਨ, ਤਾਂ ਪਾਰਟੀਸ਼ਨ ਕੰਮ ਕਰ ਸਕਦੀ ਹੈ, ਪਰ ਕੇਵਲ ਉਸ ਵੇਲੇ ਜੇ ਤੁਸੀਂ ਯਕੀਨ ਦੇ ਸਕੋ ਕਿ ਪਾਰਟੀਸ਼ਨ ਕਦੇ ਵੀ ਖੇਤਰ ਤੋਂ ਬਾਹਰ ਨਹੀਂ ਜਾਵੇਗੀਆਂ ਅਤੇ ਤੁਹਾਡੇ ਟੂਲਿੰਗ ਨਾਲ ਅਕਸਮਾਤ ਕ੍ਰਾਸ-ਰੀਜਨ ਕਵੇਰੀ ਨਹੀਂ ਚੱਲ ਸਕਦੀਆਂ। ਟੇਨੈਂਟ ਜਾਂ ਭੂਗੋਲ ਆਧਾਰਿਤ ਸ਼ਾਰਡਿੰਗ ਅਕਸਰ ਮਿੱਡਲ ਪਾਥ ਹੈ।
ਬੈਕਅਪ ਅਤੇ ਡਿਜ਼ਾਸਟਰ ਰਿਕਵਰੀ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਨੀਅਮ ਲੋੜੀਂਦਾ ਹੈ। ਜੇ ਬੈਕਅਪ ਇਨ-ਰੀਜਨ ਰਹਿੰਦੇ ਹਨ, ਤਾਂ ਰੀਸਟੋਰ ਸਬੂਤ ਦੇਣਾ ਸੌਖਾ ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਬੈਕਅਪ ਨੂੰ ਕਿਸੇ ਹੋਰ ਖੇਤਰ ਵਿੱਚ ਕਾਪੀ ਕਰਦੇ ਹੋ, ਤਾਂ ਕਾਨੂੰਨੀ ਅਧਾਰ, ਇਨਕ੍ਰਿਪਸ਼ਨ, ਕੀਆਂ ਦੀ ਸਥਿਤੀ, ਅਤੇ ਕਿਸ ਨੂੰ ਰੀਸਟੋਰ ਕਰਨਾ ਆਗਿਆ ਹੈ ਇਹ ਦਸਤਾਵੇਜ਼ ਕਰੋ।
ਲੌਗ ਅਤੇ ਅਬਜ਼ਰਵੇਬਿਲਿਟੀ ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ ਅਕਸਮਾਤ ਟ੍ਰਾਂਸਫਰ ਹੁੰਦਾ ਹੈ। ਮੈਟ੍ਰਿਕਸ ਆਮ ਤੌਰ 'ਤੇ ਕੇਂਦਰੀਕ੍ਰਿਤ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ ਜੇ ਉਹggregated ਅਤੇ ਘੱਟ-ਖਤਰੇ ਵਾਲੀਆਂ ਹਨ। ਰਾ ਲੌਗ, ਟ੍ਰੇਸ, ਅਤੇ ਏਰਰ ਪੇਲੋਡ ਨਿੱਜੀ ਡੇਟਾ ਰੱਖ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਨੂੰ ਰੀਜਨਲ ਰੱਖੋ ਜਾਂ ਜ਼ੋਰਦਾਰ ਤੌਰ ਤੇ ਰੈਡੈਕਟ ਕਰੋ।
ਬਹੁ-ਖੇਤਰ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਇੱਕ ਪ੍ਰੋਡਕਟ ਰਿਲੀਜ਼ ਵਾਂਗ ਹੀ ਸਲਹ ਕਰੋ, ਨਾ ਕਿ ਪਿਛੋਕੜ ਦੀ ਇੱਕ ਛੋਟੀ ਇੰਫਰਾਸਟ੍ਰੱਕਚਰ ਬਦਲਾਅ। ਲਿਖਤੀ ਫੈਸਲੇ, ਇੱਕ ਛੋਟਾ ਪਾਇਲਟ, ਅਤੇ ਵੇਖਣਯੋਗ ਸਬੂਤ ਤੁਸੀਂ ਇੱਕ ਸਮੀਖਿਆ ਵਿੱਚ ਦਿਖਾ ਸਕੋ ਇਹ ਚਾਹੀਦਾ ਹੈ।
ਜੋ ਨਿਯਮ ਤੁਸੀਂ ਮੰਨਣੇ ਹਨ ਉਹ ਕੈਪਚਰ ਕਰੋ: ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਸਥਾਨ, ਸਕੋਪ ਵਿੱਚ ਆਉਣ ਵਾਲੇ ਡੇਟਾ ਪ੍ਰਕਾਰ, ਅਤੇ “ਚੰਗਾ” ਕੀ ਹੈ। ਸਫਲਤਾ ਮਾਪਦੰਡ ਸ਼ਾਮिल ਕਰੋ, ਜਿਵੇਂ ਮਨਜ਼ੂਰ ਲੇਟੈਂਸੀ, ਰੀਕਵਰੀ ਉੱਪਲਬਧਤਾ, ਅਤੇ ਕਿਹੜੀ ਕ੍ਰਾਸ-ਬੋਰਡਰ ਐਕਸੈੱਸ ਮਨਜ਼ੂਰ ਹੈ (ਉਦਾਹਰਨ: ਸਪੋਰਟ ਲੌਗਇਨ)।
ਫੈਸਲਾ ਕਰੋ ਕਿ ਹਰ ਗਾਹਕ ਨੂੰ ਖੇਤਰ ਵਿੱਚ ਕਿਵੇਂ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਸ ਚੋਣ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਜਾਵੇਗਾ। ਸਾਦਾ ਰੱਖੋ: ਨਵੇਂ ਟੇਨੈਂਟ ਲਈ ਡਿਫਾਲਟ, ਮੌਜੂਦਾ ਟੇਨੈਂਟ ਲਈ ਇਕ ਸਪਸ਼ਟ ਐਸਾਈਨਮੈਂਟ, ਅਤੇ ਛੋਟੀਆਂ ਛੂਟ ਲਈ ਮਨਜ਼ੂਰੀ। ਯਕੀਨ ਕਰੋ ਕਿ ਰਾਊਟਿੰਗ ਐਪ ਟ੍ਰੈਫਿਕ, ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ, ਅਤੇ ਕਿੱਥੇ ਬੈਕਅਪ/ਲੌਗ ਜਾ ਰਹੇ ਹਨ ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ।
ਹਰ ਖੇਤਰ ਲਈ ਪੂਰਾ ਸਟੈਂਡ-ਅਪ ਕਰੋ: ਐਪ, ਡੇਟਾਬੇਸ, ਸੀਕਰੇਟਸ, ਮਾਨੀਟਰੀਂਗ, ਅਤੇ ਬੈਕਅਪ। ਫਿਰ ਇੱਕ ਪਾਇਲਟ ਟੇਨੈਂਟ ਨੂੰ ਸਮੂਹਕ ਤਰੀਕੇ ਨਾਲ ਮਾਈਗ੍ਰੇਟ ਕਰੋ, ਇਤਿਹਾਸਕ ਡੇਟਾ ਸਮੇਤ। ਮਾਈਗ੍ਰੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਨੇਪਸ਼ਾਟ ਲਓ ਤਾਂ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਸਾਫ਼ ਰਿਵਰਟ ਕਰਨ ਦੀ ਸ਼ਕਲ ਹੋਵੇ।
ਅਸਲ ਵਰਤੋਂ ਦੀ ਮਿਲਦੀ-ਜੁਲਦੀ ਟੈਸਟ ਚਲਾਓ ਅਤੇ ਨਤੀਜੇ ਰੱਖੋ:
ਟੇਨੈਂਟਾਂ ਨੂੰ ਛੋਟੇ ਬੈਚਾਂ ਵਿੱਚ ਖਿਸਕਾਓ, ਚੇਂਜ ਲਾਗ ਰੱਖੋ, ਅਤੇ ਐਰਰ ਰੇਟ ਅਤੇ ਸਪੋਰਟ ਵਾਲੀਅਮ ਨੂੰ ਨਿਗਰਾਨੀ ਕਰੋ। ਹਰ ਮਾਈਗ੍ਰੇਸ਼ਨ ਲਈ ਇੱਕ ਪਹਿਲਾਂ-ਮੰਜ਼ੂਰ ਰੋਲਬੈਕ ਟ੍ਰਿਗਰ (ਉਦਾਹਰਨ: 15 ਮਿੰਟ ਲਈ ਬੜ੍ਹੀ ਐਰਰ ਰੇਟ) ਅਤੇ ਇੱਕ ਅਭਿਆਸ ਕੀਤਾ ਪਰਤੀ ਪਰਤ ਰਾਹ ਰੱਖੋ।
ਚੰਗੀ ਹੋਸਟਿੰਗ ਡਿਜ਼ਾਈਨ ਭੀ ਅਗਰ ਤੁਸੀਂ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਸਮਝਾ ਨਾ ਸਕੋ ਤਾਂ ਇੱਕ ਕੰਪਲਾਇੰਸ ਸਮੀਖਿਆ ਵਿੱਚ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ। ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ ਨੂੰ ਸਿਸਟਮ ਦਾ ਹਿੱਸਾ ਸਮਝੋ: ਛੋਟੀ, ਸਹੀ, ਅਤੇ ਅਪ-ਟੂ-ਡੇਟ ਰੱਖਣ ਲਾਇਕ।
ਇੱਕ-ਪੰਨੇ ਦਾ ਸਾਰ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਗੈਰ-ਟੈਕਨੀਕਲ ਸਮੀਖਿਆਕਾਰ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਪੜ੍ਹ ਸਕੇ। ਦੱਸੋ ਕਿ ਕਿਹੜਾ ਡੇਟਾ ਇਨ-ਰੀਜਨ ਰਹਿਣਾ ਹੈ, ਕੀ ਬਾਹਰ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਿਉਂ (ਬਿੱਲਿੰਗ, ਈਮੇਲ ਡਿਲਿਵਰੀ, ਖ਼ਤਰਾ ਪਛਾਣ, ਆਦਿ)। ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਆਪਣਾ ਡਿਫਾਲਟ ਦਰਜ ਕਰੋ: ਗਾਹਕ ਸਮੱਗਰੀ ਇਨ-ਰੀਜਨ ਰਹਿੰਦੀ ਹੈ ਜਦ ਤੱਕ ਕੋਈ ਸਪਸ਼ਟ, ਦਸਤਾਵੇਜ਼ ਕੀਤੀ ਛੋਟ ਨਹੀਂ।
ਫਿਰ ਦੋ ਸਹਾਇਕ ਆਟਿਫੈਕਟ ਅਪ-ਟੂ-ਡੇਟ ਰੱਖੋ:
ਇੱਕ ਛੋਟਾ ਓਪਰੇਸ਼ਨ ਨੋਟ ਸ਼ਾਮਿਲ ਕਰੋ ਜੋ ਬੈਕਅਪ ਅਤੇ ਰੀਸਟੋਰ (ਕਿੱਥੇ ਬੈਕਅਪ ਰਹਿੰਦੇ ਹਨ, ਰੈਟੇਨਸ਼ਨ, ਕੌਣ ਰੀਸਟੋਰ ਟਰਿਗਰ ਕਰ ਸਕਦਾ ਹੈ) ਅਤੇ ਇਨਸਿਡੈਂਟ/ਸਪੋਰਟ ਐਕਸੈੱਸ ਪ੍ਰੋਸੈਸ (ਮੰਜ਼ੂਰੀ, ਲੌਗਿੰਗ, ਸਮੇਂ-ਬੱਧ ਐਕਸੈੱਸ, ਅਤੇ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਗਾਹਕ ਨੂੰ ਸੂਚਿਤ ਕਰਨਾ) ਨੂੰ ਕਵਰ ਕਰੇ।
ਭਾਸ਼ਾ ਗਾਹਕ-ਤਿਆਰ ਰੱਖੋ। ਇੱਕ ਮਜ਼ਬੂਤ ਨਮੂਨਾ ਇਹ ਹੈ: “Stored in X, processed in Y, transfers controlled by Z.” ਉਦਾਹਰਨ: “ਯੂਜ਼ਰ-ਜੈਨਰੇਟਿਡ ਸਮੱਗਰੀ EU ਰੀਜਨ ਵਿੱਚ ਸਟੋਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਸਪੋਰਟ ਐਕਸੈੱਸ ਟਿਕਟ ਮਨਜ਼ੂਰੀ ਨਾਲ ਹੁੰਦਾ ਅਤੇ ਲੱਗ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਅਗ੍ਰਿਗੇਟਡ ਮੈਟ੍ਰਿਕਸ ਬਾਹਰ EU 'ਤੇ ਪ੍ਰੋਸੈਸ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ ਪਰ ਉਹ ਗਾਹਕ ਸਮੱਗਰੀ ਨਹੀਂ ਰੱਖਦੀਆਂ।”
ਸਬੂਤ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਨੇੜੇ ਰੱਖੋ। ਖੇਤਰ ਕਨਫਿਗਰੇਸ਼ਨ ਸਕ੍ਰੀਨਸ਼ਾਟ, ਮੂਲ ਵਾਤਾਵਰਣ ਸੈਟਿੰਗ, ਅਤੇ ਆਡਿਟ ਲੌਗ ਦਾ ਇੱਕ ਛੋਟਾ ਐਕਸਪੋਰਟ ਸੰਭਾਲ ਕੇ ਰੱਖੋ ਜੋ ਐਕਸੈੱਸ ਮੰਜ਼ੂਰੀਆਂ ਅਤੇ ਕਿਸੇ ਵੀ ਕ੍ਰਾਸ-ਰੀਜਨ ਟ੍ਰੈਫਿਕ ਕੰਟਰੋਲ ਨੂੰ ਦਰਸ਼ਾਉਂਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਸਮੱਸਿਆਵਾਂ ਮੁੱਖ ਡੇਟਾਬੇਸ ਬਾਰੇ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਉਹ ਉਸਦੇ ਆਸ-ਪਾਸ ਦੀ ਚੀਜ਼ਾਂ (ਅਬਜ਼ਰਵੇਬਿਲਿਟੀ, ਬੈਕਅਪ, ਅਤੇ ਮਨੁੱਖੀ ਐਕਸੈੱਸ) ਵਿੱਚ ਉभरਦੀਆਂ ਹਨ। ਇਹ ਖੇਤਰ ਗਾਹਕ ਅਤੇ ਆਡੀਟਰ ਪਹਿਲਾਂ ਪੁੱਛਦੇ ਹਨ।
ਆਮ ਜਾਲ: ਲੌਗ, ਮੈਟ੍ਰਿਕਸ, ਅਤੇ ਟਰੇਸ ਨੂੰ ਨਿਰਦੋਸ਼ ਸਮਝ ਕੇ ਉਨ੍ਹਾਂ ਨੂੰ ਡੀਫਾਲਟ ਗਲੋਬਲ ਖੇਤਰ ਵਿੱਚ ਭੇਜ ਦੇਣਾ। ਉਹਨਾਂ ਵਿੱਚ ਅਕਸਰ ਯੂਜ਼ਰ IDs, IPs, ਜਾਂ ਰਿਕਵੇਸਟ ਸਿ੍ਨਿਪੈਟ ਹੁੰਦੇ ਹਨ। ਜੇ ਐਪ ਡੇਟਾ ਨੂੰ ਦੇਸ਼ ਅੰਦਰ ਰੱਖਣਾ ਹੈ, ਤਾਂ ਅਬਜ਼ਰਵੇਬਿਲਿਟੀ ਡੇਟਾ ਨੂੰ ਵੀ ਇੱਕੋ ਨਿਯਮ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਜ਼ੋਰਦਾਰ ਤੌਰ ਤੇ ਰੈਡੈਕਟ ਕਰੋ।
ਦੂਜਾ ਮੁਕੱਦਮਾ ਬੈਕਅਪ ਅਤੇ ਡੀਹ। ਟੀਮਾਂ ਪ੍ਰੋਡਕਸ਼ਨ ਦੇ ਆਧਾਰ 'ਤੇ ਰਹਾਇਸ਼ ਦਾ ਦਾਅਵਾ ਕਰਦੀਆਂ ਹਨ ਪਰ ਸਨੇਪਸ਼ਾਟ, ਰੇਪਲਿਕਾ, ਅਤੇ ਰੀਸਟੋਰ ਟੈਸਟ ਭੁੱਲ ਜਾਂਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ EU ਪ੍ਰਾਇਮਰੀ ਅਤੇ US ਬੈਕਅਪ “ਸਿਰਫ਼ ਕੇਸ ਵਾਸਤੇ” ਰੱਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਟ੍ਰਾਂਸਫਰ ਪੈਦਾ ਕੀਤੀ ਹੈ। ਬੈਕਅਪ ਸਥਾਨ, ਰੈਟੇਨਸ਼ਨ ਪੀਰੀਅਡ, ਅਤੇ ਰੀਸਟੋਰ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਉਸੇ ਵਾਅਦੇ ਦੇ ਅਨੁਕੂਲ ਰੱਖੋ।
ਐਕਸੈੱਸ ਦੂਜਾ ਕਮਜ਼ੋਰ ਬਿੰਦੂ ਹੈ। ਗਲੋਬਲ ਅਡਮਿਨ ਖਾਤੇ ਬਿਨਾਂ ਸਖ਼ਤ ਨਿਯੰਤ੍ਰਣ ਦੇ ਰਹਾਇਸ਼ ਨੂੰ ਅਮਲ ਵਿੱਚ ਤੋੜ ਸਕਦੇ ਹਨ। Least-privilege ਰੋਲ, ਖੇਤਰ-ਸਕੋਪਡ ਐਕਸੈੱਸ ਜਿੱਥੇ ਸੰਭਵ, ਅਤੇ ਆਡਿਟ ਟਰੇਲ ਵਰਤੋਂ ਜੋ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਕਿਸ ਨੇ ਕਿੰਨ੍ਹੇ ਸਮੇਂ ਤੇ ਕੀ ਕੀਤਾ।
ਹੋਰ ਆਮ ਮੁੱਦੇ: ਵੱਖ-ਵੱਖ ਰਹਾਇਸ਼ ਲੋੜਾਂ ਵਾਲੇ ਟੇਨੈਂਟਾਂ ਨੂੰ ਇਕੱਠੇ ਇੱਕ ਡੇਟਾਬੇਸ ਜਾਂ ਸੇਰਚ ਇੰਡੈਕਸ ਵਿੱਚ ਮਿਲਾਉਣਾ, active-active ਡਿਜ਼ਾਈਨ ਨੂੰ ਬਿਨਾਂ ਆਪਰੇਟ ਕਰਨ ਦੀ ਯੋਗਤਾ ਦੇ ਅੱਗੇ ਬਣਾਉਣਾ, ਅਤੇ “ਬਹੁ-ਖੇਤਰ” ਨੂੰ ਇੱਕ ਨਾਰਾ ਸਮਝਣਾ ਨਾ ਕਿ ਲਾਗੂ ਨੀਤੀਆਂ।
ਪੂਰਕ ਜਾਣਾਂ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਫਾਸਟ-ਪਾਸ ਕਰੋ ਜੋ ਦੋਹਾਂ: ਕੰਪਲਾਇੰਸ ਅਤੇ ਅਸਲੀ ਦੁਨੀਆ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਦੋ ਸਵਾਲਾਂ ਦਾ ਭਰੋਸੇਯੋਗ ਉੱਤਰ ਦੇਣਾ ਹੋਵੇਗਾ: ਨਿਯੰਤ੍ਰਿਤ ਡੇਟਾ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਕੁਝ ਤੂਟਣ ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ।
ਹਰ ਫੈਸਲੇ ਨੂੰ ਤੁਹਾਡੇ ਇਨਵੇਂਟਰੀ ਅਤੇ ਡੇਟਾ ਫਲੋ ਨਕਸ਼ੇ ਨਾਲ ਜੋੜੋ:
ਜੇ ਤੁਸੀਂ ਨਾ ਦੱਸ ਸਕਦੇ "ਕੀ ਸਪੋਰਟ ਕਦੇ ਪ੍ਰੋਡਕਸ਼ਨ ਡੇਟਾ ਵੇਖਦਾ ਹੈ, ਅਤੇ ਕਿੱਥੋਂ?" ਤਾਂ ਤੁਸੀਂ ਗਾਹਕ ਪ੍ਰਸ਼ਨਾਵਲੀ ਲਈ ਤਿਆਰ ਨਹੀਂ ਹੋ। ਸਪੋਰਟ ਐਕਸੈੱਸ ਪ੍ਰਕਿਰਿਆ (ਭੂਮਿਕਾਵਾਂ, ਮਨਜ਼ੂਰੀ, ਸਮੇਂ ਦੀ ਸੀਮਾ, ਲੌਗਿੰਗ) ਲਿਖੋ ਤਾਂ ਜੋ ਇਹ ਦੁਹਰਾਉਣਯੋਗ ਹੋਵੇ।
ਇੱਕ ਗਾਹਕ ਪ੍ਰੋਫਾਈਲ ਚੁਣੋ ਅਤੇ ਵਿਆਪਕ ਰੋਲਆਊਟ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟਾ ਪਾਇਲਟ ਚਲਾਓ। ਉਹ ਪ੍ਰੋਫਾਈਲ ਇੱਕ ਆਮ ਅਤੇ ਸਪਸ਼ਟ ਰਹਾਇਸ਼ ਨਿਯਮ ਵਾਲਾ ਹੋਵੇ (ਉਦਾਹਰਨ: “EU ਗਾਹਕ ਜਿਸਨੂੰ EU-ਸਿਰਫ਼ ਸਟੋਰੇਜ ਚਾਹੀਦੀ ਹੈ”)। ਸਬੂਤ ਇਕੱਠੇ ਕਰੋ ਜੋ ਤੁਸੀਂ ਮੁੜ-ਵਰਤ ਸਕੋ: ਖੇਤਰ ਸੈਟਿੰਗ, ਐਕਸੈੱਸ ਲੌਗ, ਅਤੇ ਫੇਲਓਵਰ ਟੈਸਟ ਨਤੀਜੇ।
ਜੇ ਤੁਸੀਂ ਤਾਜ਼ੀ ਤੌਰ 'ਤੇ ਡਿਪਲੋਇਮੈਂਟ ਅਤੇ ਖੇਤਰ ਚੋਣਾਂ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਇਤਰੈੱਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai (koder.ai) ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਹੈ ਜੋ ਚੈਟ ਤੋਂ ਐਪ ਬਣਾਉਣ ਅਤੇ ਤੈਨਾਤ ਕਰਨ ਦੀ ਸਹਾਇਤਾ ਕਰਦਾ ਹੈ; ਇਹ ਸੋర్స్ ਕੋਡ ਐਕਸਪੋਰਟ, ਸਨੇਪਸ਼ਾਟ/ਰੋਲਬੈਕ ਵਰਗੀਆਂ ਫੀਚਰਾਂ ਦੀ ਸਹਾਇਤਾ ਕਰਦਾ ਹੈ, ਜੋ ਖੇਤਰ ਮੁਵਾਂਦਾਂ ਦੌਰਾਨ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਾਅ ਜਾਂ ਰਿਕਵਰੀ ਟੈਸਟ ਕਰਨ ਵਿੱਚ ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ।
ਡੇਟਾ ਰਹਾਇਸ਼ ਉਸ ਥਾਂ ਨੂੰ ਕਹਿੰਦੇ ਹਨ ਜਿੱਥੇ ਡੇਟਾ ਅਟ-ਰੇਸਟ ਸਟੋਰ ਹੁੰਦਾ ਹੈ (ਡੇਟਾਬੇਸ, ਆਬਜੈਕਟ ਸਟੋਰੇਜ, ਬੈਕਅਪ)। ਡੇਟਾ ਟ੍ਰਾਂਸਫਰ ਉਹ ਹੈ ਜਦੋਂ ਡੇਟਾ ਟਰਾਂਜ਼ਿਟ ਵਿੱਚ ਸਰਹੱਦ ਲਾਂਘਦਾ ਹੈ (API ਕਾਲਾਂ, ਰੀਪਲੀਕੇਸ਼ਨ, ਐਕਸਪੋਰਟ)। ਡੇਟਾ ਐਕਸੈੱਸ ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਕੌਣ ਅਤੇ ਕਿੱਥੋਂ ਡੇਟਾ ਵੇਖ ਸਕਦਾ ਜਾਂ ਬਦਲ ਸਕਦਾ ਹੈ।
ਤੁਸੀਂ ਰਹਾਇਸ਼ ਦੀਆਂ ਸ਼ਰਤਾਂ ਪੂਰੀਆਂ ਕਰ ਸਕਦੇ ਹੋ ਪਰ ਫਿਰ ਵੀ ਟ੍ਰਾਂਸਫਰ ਜਾਂ ਐਕਸੈੱਸ ਦੇ ਨਿਯਮ ਭੰਗ ਹੋ ਸਕਦੇ ਹਨ (ਉਦਾਹਰਨ ਵਜੋਂ ਲੌਗਾਂ ਨੂੰ ਕਿਸੇ ਹੋਰ ਖੇਤਰ ਵਿੱਚ ਭੇਜਨਾ)।
ਇੱਕ ਡਿਫਾਲਟ “ਇੱਕ ਖੇਤਰ ਵਿੱਚ ਰਿਹਾ” ਸੈਟਅਪ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਕੇਵਲ ਉਸ ਵੇਲੇ ਹੋਰ ਖੇਤਰ ਸ਼ਾਮਿਲ ਕਰੋ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਸਪਸ਼ਟ ਲਾਜ਼ਮੀਅਤ ਹੋ (ਠੇਕਾ, ਰੈਗੂਲੇਟਰ, ਪਬਲਿਕ ਸੈਕਟਰ ਨਿਯਮ, ਜਾਂ ਕੋਈ ਗ੍ਰਾਹਕ ਖੰਡ ਜੋ ਤੁਸੀਂ ਬੇਚ ਨਹੀਂ ਸਕਦੇ)।
ਬਹੁ-ਖੇਤਰ ਖਰਚ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਕੰਮ ਵਧਾਉਂਦਾ ਹੈ (ਰੀਪਲੀਕੇਸ਼ਨ, ਮਾਨੀਟਰੀਂਗ, ਇੰਸੀਡੈਂਟ ਰਿਸਪਾਂਸ), ਇਸ ਲਈ ਇਹ ਆਮ ਤੌਰ ‘ਤੇ ਤਦ ਹੀ ਲੋੜੀਂਦਾ ਹੁੰਦਾ ਜਦੋਂ ਇਹ ਰੇਵਨਿਊ ਜਾਂ ਫਰਮਾ-ਵਾਰ ਅਨੁਕੂਲੀ ਲੋੜ ਨਾਲ ਜੁੜਿਆ ਹੋਵੇ।
ਇਸਨੂੰ ਇੱਕ ਇਨਵੇਂਟਰੀ ਸਮੱਸਿਆ ਵਜੋਂ ਲਵੋ, ਅਨੁਮਾਨ ਨਹੀਂ। ਆਪਣੇ ਡੇਟਾ ਬੱਕੇਟਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ ਅਤੇ ਹਰ ਇੱਕ ਲਈ ਫੈਸਲਾ ਕਰੋ ਕਿ ਉਹ ਕਿੱਥੇ ਸਟੋਰ ਅਤੇ ਪ੍ਰੋਸੈਸ ਹੁੰਦਾ ਹੈ:
ਫਿਰ ਹਰ ਸਿਸਟਮ ਦੀ ਜਾਂਚ ਕਰੋ ਜੋ ਇਹਨਾਂ ਬੱਕੇਟਾਂ ਨੂੰ ਛੂਹਦਾ ਹੈ (ਐਪ ਸਰਵਰ, ਬੈਕਗ੍ਰਾਉਂਡ ਜੌਬ, ਐਨਾਲਿਟਿਕਸ, ਮਾਨੀਟਰੀਂਗ, ਈਮੇਲ/ਐਸਐਮਐਸ, ਸਪੋਰਟ ਟੂਲ)।
ਲੌਗ ਬਹੁਤ ਵਾਰ ਅਕਸਮਾਤ ਕ੍ਰਾਸ-ਬਾਰਡਰ ਟ੍ਰਾਂਸਫਰ ਦਾ ਸਰੋਤ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹਨਾਂ ਵਿੱਚ ਯੂਜ਼ਰ IDs, IP ਐਡਰੈੱਸ, ਜਾਂ ਰਿਕਵੇਸਟ ਸਿ੍ਨਿਪੈਟ ਹੋ ਸਕਦੇ ਹਨ।
ਚੰਗੇ ਡਿਫਾਲਟ:
ਐਕਸੈੱਸ ਨੀਤੀਆਂ ਸਪਸ਼ਟ ਅਤੇ ਲਾਗੂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ:
ਅੱਗੇ ਤੋਂ ਇਹ ਵੀ ਫੈਸਲਾ ਕਰੋ ਕਿ ਹੋਰ ਦੇਸ਼ਾਂ ਤੋਂ ਰਿਮੋਟ ਐਕਸੈੱਸ ਦੀ ਆਗਿਆ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ਕਿਹੜੇ ਸੁਰਖਿਆ ਰੱਖੇ ਜਾਣਗੇ।
ਬੈਕਅਪ ਅਤੇ ਡਿਜ਼ਾਸਟਰ ਰਿਕਵਰੀ ਰਹਾਇਸ਼ ਵਾਅਦੇ ਦਾ ਹਿੱਸਾ ਹਨ। ਜੇ ਤੁਸੀਂ ਬੈਕਅਪ ਜਾਂ ਰੇਪਲਿਕਾ ਨੂੰ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਖੇਤਰ ਦੇ ਬਾਹਰ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਟ੍ਰਾਂਸਫਰ ਪੈਦਾ ਕਰ ਰਹੇ ਹੋ।
ਵਿਹਾਰਕ ਦ੍ਰਿਸ਼ਟੀਕੋਣ:
Active-passive ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਸਧਾਰਨ ਹੈ: ਹਰ ਟੇਨੈਂਟ ਲਈ ਇੱਕ ਪ੍ਰਾਥਮਿਕ ਖੇਤਰ ਅਤੇ ਫੇਲਓਵਰ ਜਾਂ ਕੰਟਰੋਲਡ ਡੀਐਸਆਰ ਲਈ ਇੱਕ ਸੈਕੰਡਰੀ।
Active-active ਅੱਛਾ ਅਪਟਾਈਮ ਅਤੇ ਸਥਾਨਕ ਪ੍ਰਦਰਸ਼ਨ ਵਧਾਉਂ ਸਕਦਾ ਹੈ, ਪਰ ਇਸ ਨਾਲ ਕਾਂਫਲਿਕਟ-ਹੈਂਡਲਿੰਗ, ਕਨਸਿਸਟੈਂਸੀ ਅਤੇ ਰੀਪਲੀਕੇਸ਼ਨ-ਬੇਸਡ ਟ੍ਰਾਂਸਫਰ ਲਈ ਕਠਿਨਾਈ ਆਉਂਦੀ ਹੈ।
ਜਨਰਲ ਸਲਾਹ:
ਸੰਵੇਦਨਸ਼ੀਲ ਰਾਹਾਂ ਨੂੰ ਸਥਾਨਕ ਰੱਖੋ ਅਤੇ ਖੇਤਰ-ਵਿੱਚਕਾਰ ਚਰਚਾ ਘਟਾਓ:
ਸਭ ਤੋਂ ਵੱਡੀ ਪ੍ਰਗਟਿ ਆਮ ਤੌਰ 'ਤੇ ਕਈ ਛੋਟੀਆਂ ਕਾਲਾਂ ਨੂੰ ਕੱਟ ਕੇ ਮਿਲਦੀ ਹੈ—ਕਈ ਛੋਟੀਆਂ cross-region ਕਾਲਾਂ ਵੱਧ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ।
ਸੰਖੇਪ ਕਦਮ:
ਇੱਕ ਛੋਟਾ ਪਾਇਲਟ ਚਲਾਉਣ ਨੂੰ ਤਰਜੀਹ ਦਿਓ—ਉਹ ਸਬੂਤ ਦੇਣ ਵਿੱਚ ਤੇਜ਼ ਅਤੇ ਘੱਟ ਖਰਚੀਲਾ ਹੁੰਦਾ ਹੈ।
ਚੰਗੀ ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ ਹੇਠਾਂ-ਦਿੱਤੀ ਚੀਜ਼ਾਂ ਤੇ ਖੁੱਲ੍ਹੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ:
ਇੱਕ-ਪੰਨੇ ਦਾ ਸਾਰ, ਇੱਕ ਸਟੈਂਡਰਡ ਡੇਟਾ-ਫਲੋ ਨਕਸ਼ਾ, ਅਤੇ ਇੱਕ ਸਰਲ ਸਿਸਟਮ ਟੇਬਲ ਆਮ ਤੌਰ 'ਤੇ ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ।