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

ਪਹਿਲਾ, ਕੀ ਸਵਾਲ ਫੈਸਲਾ ਹੈ ਜਾਂ ਇੱਛਾ

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

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

ਜੇ ਜਵਾਬ ਕੋਈ ਨਹੀਂ ਹੈ ਤਾਂ ਇੱਥੇ ਰੁਕੋ, ਕਿਉਂਕਿ ਮਾਲਕ ਤੋਂ ਬਿਨਾਂ ਫੈਸਲਾ ਸਭ ਤੋਂ ਉੱਚੀ ਆਵਾਜ਼ ਵਿੱਚ ਸ਼ਿਕਾਇਤ ਕਰਨ ਵਾਲਾ ਦੁਬਾਰਾ ਬਣਾਏਗਾ। ਇਹ ਡਿਜ਼ਾਈਨ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ, ਸ਼ਾਸਨ ਦੀ ਸਮੱਸਿਆ ਹੈ।

ਦੂਜਾ, ਵਹਾਅ ਅਤੇ ਇਨਕਾਰ ਦੇ ਨਾਂ ਦੱਸੋ

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

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

ਕਲਾਇੰਟ ਅਤੇ ਉਨ੍ਹਾਂ ਦੀ ਪ੍ਰਬੰਧਨ ਸਥਿਤੀ ਵੀ ਨੋਟ ਕਰੋ, ਕਿਉਂਕਿ ਏਜੰਟ ਵਾਲਾ ਪ੍ਰਬੰਧਿਤ ਯੰਤਰ ਉਹ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਆਪਣਾ ਲਿਆਇਆ ਲੈਪਟਾਪ ਨਹੀਂ ਕਰ ਸਕਦਾ।

ਸੂਚੀ ਨੂੰ ਪਰਖਣ ਲਈ ਕਾਫ਼ੀ ਛੋਟੀ ਰੱਖੋ। ਜੋ ਦਸ ਵਹਾਅ ਤੁਸੀਂ ਜਾਂਚ ਸਕਦੇ ਹੋ ਉਹ ਉਨ੍ਹਾਂ ਚਾਲੀ ਨਾਲੋਂ ਬਿਹਤਰ ਹਨ ਜੋ ਨਹੀਂ ਜਾਂਚ ਸਕਦੇ।

ਜਾਂਚ 3: ਤੱਥਾਂ ਨੂੰ ਧਾਰਨਾਵਾਂ ਤੋਂ ਵੱਖ ਕਰੋ

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

ਇੱਕ ਉਦਾਹਰਨ ਨੈੱਟਵਰਕ ਉਦੋਂ ਤੱਕ ਠੀਕ ਹੈ ਜਦੋਂ ਤੱਕ ਉਸ ਉੱਤੇ ਲੇਬਲ ਹੋਵੇ। ਸਮੱਸਿਆ ਉਹ ਕਾਲਪਨਿਕ ਸ਼ਾਖਾ ਹੈ ਜੋ ਚੁੱਪਚਾਪ ਦੂਜਾ ਉੱਪਰੀ ਲਿੰਕ ਜਾਂ ਜਨਤਕ ਪਤਾ ਬਲਾਕ ਪ੍ਰਾਪਤ ਕਰ ਲੈਂਦੀ ਹੈ ਜੋ ਉਸ ਕੋਲ ਕਦੇ ਨਹੀਂ ਸੀ।

ਸਮੀਖਿਆ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਧਾਰਨਾ ਜਾਂਚੋ ਜੋ ਤੁਸੀਂ ਜਾਂਚ ਸਕਦੇ ਹੋ, ਕਿਉਂਕਿ ਇੱਕ ਮਾਪਿਆ ਤੱਥ ਚਰਚਾ ਦੀ ਪੂਰੀ ਸ਼ਾਖਾ ਹਟਾ ਦਿੰਦਾ ਹੈ।

ip route get 10.50.0.10
traceroute -n -m 6 10.50.0.10
nc -vz 10.50.0.10 443

ਚੌਥਾ, ਅਸਫਲਤਾ ਸਮਝੌਤਾ ਲਿਖੋ

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

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

ਰਿਕਵਰੀ ਟੀਚਾ ਸਰਲ ਭਾਸ਼ਾ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ, ਜਿਵੇਂ ਕਿ ਸਾਈਟ ਕਿੰਨਾ ਸਮਾਂ ਗਿਰੀ ਹੋਈ ਹਾਲਤ ਵਿੱਚ ਚੱਲ ਸਕਦੀ ਹੈ ਅਤੇ ਘਟਨਾ ਦਾ ਐਲਾਨ ਕੌਣ ਕਰਦਾ ਹੈ।

ਜਾਂਚ 5 ਅਤੇ 6: ਸੀਮ ਚੁਣੋ ਅਤੇ ਬਦਲਾਅ ਦਰਜ ਕਰੋ

ਬਹਿਸ ਲਈ ਇੱਕ ਸੀਮ ਚੁਣੋ, ਕਿਉਂਕਿ ਸਭ ਕੁਝ ਸੁਲਝਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਵਾਲੀ ਸਮੀਖਿਆ ਕੁਝ ਨਹੀਂ ਸੁਲਝਾਉਂਦੀ। ਰੂਟਿੰਗ, ਅਧਿਕਾਰ ਅਤੇ ਐਨਕ੍ਰਿਪਸ਼ਨ ਤਿੰਨ ਵੱਖਰੀਆਂ ਸੀਮਾਂ ਹਨ, ਅਤੇ ਬ੍ਰੀਫ਼ ਨੂੰ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਸਵਾਲ ਕਿਸ ਬਾਰੇ ਹੈ। RFC 4301 ਇੱਥੇ ਲਾਹੇਵੰਦ ਯਾਦ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਨੀਤੀ ਫੈਸਲਿਆਂ, ਸੁਰੱਖਿਅਤ ਟ੍ਰੈਫਿਕ ਅਤੇ ਸੁਰੱਖਿਆ ਸੰਗਠਨਾਂ ਨੂੰ ਇੱਕ ਵਸਤੂ ਨਾ ਮੰਨ ਕੇ ਵੱਖ ਕਰਦਾ ਹੈ।

ਫਿਰ ਫੈਸਲੇ ਤੋਂ ਬਾਅਦ ਕੀ ਬਦਲਿਆ ਦਰਜ ਕਰੋ, ਸੋਧੀਆਂ ਧਾਰਨਾਵਾਂ ਸਮੇਤ। ਉਹੀ ਰਿਕਾਰਡ ਅਗਲੀ ਸਮੀਖਿਆ ਨੂੰ ਛੋਟਾ ਬਣਾਉਂਦਾ ਹੈ।

git diff --stat design/vpn-brief.md
grep -n 'assumption' design/vpn-brief.md
ip route get 10.50.0.10

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

ਸੰਬੰਧਿਤ ਲੇਖ