🥇 DRP ਦੀ ਤਿਆਰੀ - ਮੀਟੋਰੀਟ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਨਾ ਭੁੱਲੋ

ਕਿਸੇ ਆਫ਼ਤ ਦੌਰਾਨ ਵੀ, ਚਾਹ ਦੇ ਕੱਪ ਲਈ ਹਮੇਸ਼ਾ ਸਮਾਂ ਹੁੰਦਾ ਹੈ.

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

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

ਇਸ ਪੋਸਟ ਵਿੱਚ, ਮੈਂ ਇੱਕ DRP ਨੂੰ ਕਿਵੇਂ ਲਿਖਣਾ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਬਾਰੇ ਸਿਫ਼ਾਰਸ਼ਾਂ ਸਾਂਝੀਆਂ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ। ਅਸੀਂ ਹੇਠ ਲਿਖਿਆਂ ਨੂੰ ਵੀ ਦੇਖਾਂਗੇ:

ਖਲਨਾਇਕ ਵਾਂਗ ਸੋਚਣਾ ਸਿੱਖੋ।
ਆਓ ਆਪਾਕਾਲ ਦੌਰਾਨ ਚਾਹ ਦੇ ਕੱਪ ਦੇ ਫਾਇਦਿਆਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੀਏ।
ਇੱਕ ਸੁਵਿਧਾਜਨਕ DRP ਢਾਂਚੇ ਬਾਰੇ ਸੋਚੋ
ਆਓ ਦੇਖੀਏ ਕਿ ਇਸ ਨੂੰ ਕਿਵੇਂ ਪਰਖਣਾ ਹੈ

ਇਸ ਤੋਂ ਕਿਹੜੀਆਂ ਕੰਪਨੀਆਂ ਨੂੰ ਫਾਇਦਾ ਹੋ ਸਕਦਾ ਹੈ?

ਜਦੋਂ ਆਈ.ਟੀ. ਵਿਭਾਗ ਨੂੰ ਇਨ੍ਹਾਂ ਚੀਜ਼ਾਂ ਦੀ ਲੋੜ ਪੈਣ ਲੱਗਦੀ ਹੈ ਤਾਂ ਲਾਈਨ ਖਿੱਚਣੀ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ। ਮੈਂ ਕਹਾਂਗਾ ਕਿ ਤੁਹਾਨੂੰ DRP ਦੀ ਲੋੜ ਹੋਣ ਦੀ ਗਾਰੰਟੀ ਹੈ ਜੇਕਰ:

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

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

ਦਸਤਾਵੇਜ਼ ਮਹੱਤਵਪੂਰਨ ਹੈ

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

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

ਇੱਕ ਵਿਘਨਕਾਰੀ ਵਰਗੇ ਵਿਚਾਰ

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

ਆਮ ਤੌਰ 'ਤੇ, ਜ਼ਿਆਦਾਤਰ ਆਮ ਸੰਕਟਕਾਲਾਂ ਹੇਠ ਲਿਖੀਆਂ ਕਿਸਮਾਂ ਵਿੱਚ ਫਿੱਟ ਹੁੰਦੀਆਂ ਹਨ:

ਨੈੱਟਵਰਕ ਅਸਫਲਤਾ
OS ਸੇਵਾ ਅਸਫਲਤਾ
ਐਪਲੀਕੇਸ਼ਨ ਅਸਫਲਤਾ
ਲੋਹੇ ਦੀ ਅਸਫਲਤਾ
ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਅਸਫਲਤਾ

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

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

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

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

ਤੁਹਾਡੀ ਇਹ ਡੀਆਰਪੀ ਕੀ ਹੈ?!

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

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

ਐਮਰਜੈਂਸੀ ਵਿੱਚ ਸੋਚਣਾ ਔਖਾ ਹੈ! ਰੀੜ੍ਹ ਦੀ ਹੱਡੀ ਦੇ ਪਾਰਸਿੰਗ ਲਈ ਸਧਾਰਨ ਨਿਰਦੇਸ਼ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ.

ਇੱਕ ਚੰਗੀ DRP ਵਿੱਚ ਕੁਝ ਸਧਾਰਨ ਬਲਾਕ ਹੁੰਦੇ ਹਨ:

ਜਿਸ ਨੂੰ ਹਾਦਸੇ ਦੀ ਸ਼ੁਰੂਆਤ ਬਾਰੇ ਸੂਚਿਤ ਕੀਤਾ ਜਾਵੇ। ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਖ਼ਤਮ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਮਾਨਾਂਤਰ ਬਣਾਉਣ ਲਈ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਸਹੀ ਢੰਗ ਨਾਲ ਨਿਦਾਨ ਕਿਵੇਂ ਕਰਨਾ ਹੈ - ਅਸੀਂ ਟਰੇਸ ਕਰਦੇ ਹਾਂ, systemctl ਸਥਿਤੀ ਸੇਵਾ ਨਾਮ ਵਿੱਚ ਵੇਖਦੇ ਹਾਂ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਹੋਰ.
ਹਰ ਪੜਾਅ 'ਤੇ ਕਿੰਨਾ ਸਮਾਂ ਬਿਤਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ SLA ਸਮੇਂ ਦੌਰਾਨ ਆਪਣੇ ਹੱਥਾਂ ਨਾਲ ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ ਦਾ ਸਮਾਂ ਨਹੀਂ ਹੈ, ਤਾਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਨੂੰ ਕੱਲ੍ਹ ਦੇ ਬੈਕਅੱਪ ਤੋਂ ਮਾਰਿਆ ਅਤੇ ਰੋਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ.
ਇਹ ਕਿਵੇਂ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾਵੇ ਕਿ ਕਰੈਸ਼ ਖਤਮ ਹੋ ਗਿਆ ਹੈ।

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

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

ਸਹੀ ਢੰਗ ਨਾਲ ਟੈਸਟ ਕਿਵੇਂ ਕਰਨਾ ਹੈ

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

ਗਲਤ - "ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ 'ਤੇ ਜਾਓ ਅਤੇ ਡੈੱਡ ਨੋਡ ਨੂੰ ਰੀਬੂਟ ਕਰੋ"
ਸੱਜਾ - "ਵੈੱਬ ਇੰਟਰਫੇਸ ਰਾਹੀਂ virt.example.com ਨਾਲ ਜੁੜੋ, ਨੋਡ ਭਾਗ ਵਿੱਚ, ਨੋਡ ਨੂੰ ਮੁੜ ਲੋਡ ਕਰੋ ਜੋ ਗਲਤੀ ਦਾ ਕਾਰਨ ਬਣ ਰਿਹਾ ਹੈ।"

ਅਸਪਸ਼ਟਤਾ ਤੋਂ ਬਚੋ। ਡਰੇ ਹੋਏ ਇੰਟਰਨ ਨੂੰ ਯਾਦ ਰੱਖੋ.

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

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

ਮੁੱਖ ਨੁਕਤੇ

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

ਸਰੋਤ: www.habr.com

ਡੀਆਰਪੀ ਦੀ ਤਿਆਰੀ - ਉਲਕਾ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਨਾ ਭੁੱਲੋ