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

ਇੱਕ ਸੇਵਾ, ਤਿੰਨ ਰਿਕਾਰਡ

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

RecordAnswersGoes stale when
Intended serviceWho may reach whatA contract changes and nobody edits the record
Deployed configurationWhat the gateway was toldA device is edited by hand
Observed sessionWhat is running nowTelemetry stops or a session ends

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

ਕਿਰਾਏਦਾਰ ਦਰਜ ਕਰੋ, ਇੰਟਰਫੇਸ ਨਹੀਂ

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

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

ਤਿਆਰ ਕੀਤੀ ਸੰਰਚਨਾ ਦਾ ਮਾਲਕ ਅਤੇ ਸੰਸਕਰਣ ਹੁੰਦਾ ਹੈ

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

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

ਸੈਸ਼ਨ ਸਬੂਤ ਹਨ, ਆਗਿਆ ਨਹੀਂ

ਜਿੱਥੇ ਤੈਨਾਤੀ RADIUS ਲੇਖਾ ਵਰਤਦੀ ਹੈ, ਉੱਥੇ RFC 2866 ਕੰਮ ਕਰਨ ਲਈ ਠੋਸ ਖੇਤਰ ਦਿੰਦਾ ਹੈ। Acct-Status-Type ਸ਼ੁਰੂਆਤ ਨੂੰ ਰੁਕਣ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ, ਅਤੇ ਇੱਕੋ ਸੈਸ਼ਨ ਦੇ ਰਿਕਾਰਡ ਇੱਕ Acct-Session-Id ਸਾਂਝਾ ਕਰਦੇ ਹਨ। ਉਹ ਖੇਤਰ ਡੈਸ਼ਬੋਰਡ ਦੇ ਸਾਰ 'ਤੇ ਭਰੋਸਾ ਕੀਤੇ ਬਿਨਾਂ ਸੈਸ਼ਨ ਕਦੋਂ ਸ਼ੁਰੂ ਅਤੇ ਕਦੋਂ ਖਤਮ ਹੋਇਆ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦਿੰਦੇ ਹਨ।

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

ਹਟਾਉਣਾ ਵੀ ਉਹੀ ਜੋੜ ਵਰਤਦਾ ਹੈ

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

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

ਸੰਬੰਧਿਤ ਲੇਖ