ਕੈਓਸ ਇੰਜੀਨੀਅਰਿੰਗ: ਜਾਣਬੁੱਝ ਕੇ ਵਿਨਾਸ਼ ਦੀ ਕਲਾ. ਭਾਗ 2

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

"ਜੇ ਤੁਸੀਂ ਇੱਕ ਯੋਜਨਾ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਅਸਫਲ ਹੋਣ ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦੇ ਹੋ." - ਬੈਂਜਾਮਿਨ ਫਰੈਂਕਲਿਨ

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

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

ਮਹਾਨ ਸਵਾਲ! ਹਾਲਾਂਕਿ, ਉਹ ਇਸ ਪਾਂਡਾ ਤੋਂ ਖਾਸ ਤੌਰ 'ਤੇ ਪਰੇਸ਼ਾਨ ਨਹੀਂ ਜਾਪਦਾ ...

ਹਫੜਾ-ਦਫੜੀ ਵਾਲੇ ਪਾਂਡਾ ਨਾਲ ਗੜਬੜ ਨਾ ਕਰੋ!

ਛੋਟਾ ਜਵਾਬ: ਬੇਨਤੀ ਮਾਰਗ ਦੇ ਨਾਲ ਮਹੱਤਵਪੂਰਨ ਸੇਵਾਵਾਂ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਓ।

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

1. ਦੇਖੋ ਕਰੈਸ਼ ਇਤਿਹਾਸ ਅਤੇ ਪੈਟਰਨਾਂ ਦੀ ਪਛਾਣ ਕਰੋ;
2. 'ਤੇ ਫੈਸਲਾ ਕਰੋ ਨਾਜ਼ੁਕ ਨਿਰਭਰਤਾ;
3. ਅਖੌਤੀ ਵਰਤੋ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਿਸ਼ਵਾਸ ਪ੍ਰਭਾਵ.

ਇਹ ਮਜ਼ਾਕੀਆ ਹੈ, ਪਰ ਇਸ ਹਿੱਸੇ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ "ਸਵੈ-ਖੋਜ ਅਤੇ ਗਿਆਨ ਦੀ ਯਾਤਰਾ". ਇਸ ਵਿੱਚ ਅਸੀਂ ਕੁਝ ਵਧੀਆ ਯੰਤਰਾਂ ਨਾਲ "ਵਜਾਉਣਾ" ਸ਼ੁਰੂ ਕਰਾਂਗੇ।

1. ਜਵਾਬ ਅਤੀਤ ਵਿੱਚ ਪਿਆ ਹੈ

ਜੇਕਰ ਤੁਹਾਨੂੰ ਯਾਦ ਹੈ, ਪਹਿਲੇ ਭਾਗ ਵਿੱਚ ਮੈਂ ਗਲਤੀਆਂ ਨੂੰ ਸੁਧਾਰਨ (COE) ਦੀ ਧਾਰਨਾ ਪੇਸ਼ ਕੀਤੀ ਸੀ - ਇੱਕ ਵਿਧੀ ਜਿਸ ਦੁਆਰਾ ਅਸੀਂ ਆਪਣੀਆਂ ਗਲਤੀਆਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੇ ਹਾਂ - ਤਕਨਾਲੋਜੀ, ਪ੍ਰਕਿਰਿਆ ਜਾਂ ਸੰਗਠਨ ਵਿੱਚ ਗਲਤੀਆਂ - ਉਹਨਾਂ ਦੇ ਕਾਰਨਾਂ ਨੂੰ ਸਮਝਣ ਅਤੇ ਰੋਕਣ ਲਈ ਭਵਿੱਖ ਵਿੱਚ ਆਵਰਤੀ. ਆਮ ਤੌਰ 'ਤੇ, ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਤੁਹਾਨੂੰ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

"ਵਰਤਮਾਨ ਨੂੰ ਸਮਝਣ ਲਈ, ਤੁਹਾਨੂੰ ਅਤੀਤ ਨੂੰ ਜਾਣਨ ਦੀ ਲੋੜ ਹੈ." - ਕਾਰਲ ਸਾਗਨ

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

"ਕੀ ਇਸਦੀ ਭਵਿੱਖਬਾਣੀ ਕੀਤੀ ਜਾ ਸਕਦੀ ਸੀ ਅਤੇ ਇਸ ਲਈ ਨੁਕਸ ਟੀਕੇ ਦੁਆਰਾ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਸੀ?"

ਮੈਨੂੰ ਆਪਣੇ ਕਰੀਅਰ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਇੱਕ ਅਸਫਲਤਾ ਯਾਦ ਹੈ. ਇਸ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਸੀ ਜੇਕਰ ਅਸੀਂ ਕੁਝ ਸਧਾਰਨ ਹਫੜਾ-ਦਫੜੀ ਵਾਲੇ ਪ੍ਰਯੋਗ ਕੀਤੇ ਹੁੰਦੇ:

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

ਹਾਲਾਂਕਿ, ਕੁਝ ਸਮੇਂ ਲਈ ਸਭ ਕੁਝ ਠੀਕ ਸੀ.

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

ਅਚਾਨਕ, ਹੋਰ ਸਾਰੀਆਂ ਉਦਾਹਰਣਾਂ ਵੀ ਸਿਹਤ ਜਾਂਚ ਵਿੱਚ ਫੇਲ ਹੋਣ ਲੱਗੀਆਂ।

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

ਫਿਰ ਅਸੀਂ ਹਮੇਸ਼ਾ ਲਈ ਹੇਠਾਂ ਦਿੱਤੇ ਨੁਕਤਿਆਂ ਨੂੰ ਸਮਝ ਲਿਆ:

• ਨਵੀਂ ਉਦਾਹਰਣ ਬਣਾਉਂਦੇ ਸਮੇਂ ਸੌਫਟਵੇਅਰ ਸਥਾਪਤ ਕਰਨ ਵਿੱਚ ਲੰਮਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ; ਅਟੱਲ ਪਹੁੰਚ ਨੂੰ ਤਰਜੀਹ ਦੇਣਾ ਬਿਹਤਰ ਹੈ ਅਤੇ ਗੋਲਡਨ AMI.
• ਗੁੰਝਲਦਾਰ ਸਥਿਤੀਆਂ ਵਿੱਚ, ਸਿਹਤ-ਜਾਂਚਾਂ ਅਤੇ ELBs ਦੇ ਜਵਾਬਾਂ ਨੂੰ ਪਹਿਲ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ - ਆਖਰੀ ਚੀਜ਼ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਉਹ ਬਾਕੀ ਦੇ ਮਾਮਲਿਆਂ ਲਈ ਜੀਵਨ ਨੂੰ ਗੁੰਝਲਦਾਰ ਬਣਾਉਣਾ ਹੈ।
• ਸਿਹਤ ਜਾਂਚਾਂ ਦੀ ਸਥਾਨਕ ਕੈਸ਼ਿੰਗ ਬਹੁਤ ਮਦਦ ਕਰਦੀ ਹੈ (ਭਾਵੇਂ ਕੁਝ ਸਕਿੰਟਾਂ ਲਈ ਵੀ)।
• ਇੱਕ ਮੁਸ਼ਕਲ ਸਥਿਤੀ ਵਿੱਚ, ਕ੍ਰੋਨ ਟਾਸਕ ਅਤੇ ਹੋਰ ਗੈਰ-ਨਾਜ਼ੁਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਨਾ ਚਲਾਓ - ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਕੰਮਾਂ ਲਈ ਸਰੋਤ ਬਚਾਓ.
• ਆਟੋਸਕੇਲਿੰਗ ਕਰਦੇ ਸਮੇਂ, ਛੋਟੀਆਂ ਉਦਾਹਰਣਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ। 10 ਛੋਟੇ ਨਮੂਨਿਆਂ ਦਾ ਸਮੂਹ 4 ਵੱਡੇ ਨਮੂਨਿਆਂ ਦੇ ਸਮੂਹ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ; ਜੇਕਰ ਇੱਕ ਉਦਾਹਰਣ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਪਹਿਲੇ ਕੇਸ ਵਿੱਚ 10% ਟ੍ਰੈਫਿਕ 9 ਪੁਆਇੰਟਾਂ ਉੱਤੇ ਵੰਡਿਆ ਜਾਵੇਗਾ, ਦੂਜੇ ਵਿੱਚ - 25% ਟ੍ਰੈਫਿਕ ਤਿੰਨ ਪੁਆਇੰਟਾਂ ਤੋਂ ਵੱਧ।

ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ, ਕੀ ਇਹ ਪਹਿਲਾਂ ਹੀ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਸੀ, ਅਤੇ ਇਸ ਲਈ ਸਮੱਸਿਆ ਨੂੰ ਪੇਸ਼ ਕਰਕੇ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਸੀ?

ਜੀ, ਅਤੇ ਕਈ ਤਰੀਕਿਆਂ ਨਾਲ।

ਪਹਿਲਾਂ, ਸੰਦਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਉੱਚ CPU ਵਰਤੋਂ ਦੀ ਨਕਲ ਕਰਕੇ ਜਿਵੇਂ ਕਿ stress-ng ਜ cpuburn:

❯ stress-ng --matrix 1 -t 60s

ਤਣਾਅ-ਐਨਜੀ

ਦੂਜਾ, ਨਾਲ ਉਦਾਹਰਨ ਨੂੰ ਓਵਰਲੋਡ ਕਰਕੇ wrk ਅਤੇ ਹੋਰ ਸਮਾਨ ਉਪਯੋਗਤਾਵਾਂ:

❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health

ਪ੍ਰਯੋਗ ਮੁਕਾਬਲਤਨ ਸਧਾਰਨ ਹਨ, ਪਰ ਅਸਲ ਅਸਫਲਤਾ ਦੇ ਤਣਾਅ ਵਿੱਚੋਂ ਲੰਘੇ ਬਿਨਾਂ ਸੋਚਣ ਲਈ ਕੁਝ ਵਧੀਆ ਭੋਜਨ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੇ ਹਨ।

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

ਕੀ ਇਹ ਇੱਕ ਸੁਪਨਾ ਸੀ, ਜਾਂ ਕੀ ਇਹ ਸੱਚਮੁੱਚ ਹੋਇਆ ਸੀ?

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

ਫਿਰ ਸਭ ਤੋਂ ਵੱਡੀ ਰੇਂਜ ਦੇ ਨਾਲ ਸਭ ਤੋਂ ਆਮ ਪੈਟਰਨਾਂ 'ਤੇ ਸਵਿਚ ਕਰੋ।

2. ਨਿਰਭਰਤਾ ਦਾ ਨਕਸ਼ਾ ਬਣਾਓ

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

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

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

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

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

ਸਾਰੇ API ਦੁਆਰਾ ਜਾ ਕੇ ਸ਼ੁਰੂ ਕਰੋ। ਸਭ ਤੋਂ ਵੱਧ ਹਾਈਲਾਈਟ ਕਰੋ ਮਹੱਤਵਪੂਰਨ ਅਤੇ ਨਾਜ਼ੁਕ. ਲਓ ਨਿਰਭਰਤਾ ਕੋਡ ਰਿਪੋਜ਼ਟਰੀ ਤੋਂ, ਇਸ ਦੀ ਜਾਂਚ ਕਰੋ ਕੁਨੈਕਸ਼ਨ ਲਾਗ, ਫਿਰ ਵੇਖੋ ਦਸਤਾਵੇਜ਼ (ਬੇਸ਼ਕ, ਜੇ ਇਹ ਮੌਜੂਦ ਹੈ - ਨਹੀਂ ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਅਜੇ ਵੀ ਹੈоਵੱਡੀਆਂ ਸਮੱਸਿਆਵਾਂ). ਲਈ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰੋ ਪਰੋਫਾਈਲਿੰਗ ਅਤੇ ਟਰੇਸਿੰਗ, ਬਾਹਰੀ ਕਾਲਾਂ ਨੂੰ ਫਿਲਟਰ ਕਰੋ।

ਵਰਗੇ ਪ੍ਰੋਗਰਾਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ netstat - ਇੱਕ ਕਮਾਂਡ ਲਾਈਨ ਸਹੂਲਤ ਜੋ ਸਿਸਟਮ ਵਿੱਚ ਸਾਰੇ ਨੈਟਵਰਕ ਕਨੈਕਸ਼ਨਾਂ (ਐਕਟਿਵ ਸਾਕਟਾਂ) ਦੀ ਸੂਚੀ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਸਾਰੇ ਮੌਜੂਦਾ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸੂਚੀਬੱਧ ਕਰਨ ਲਈ, ਟਾਈਪ ਕਰੋ:

❯ netstat -a | more 

AWS ਵਿੱਚ ਤੁਸੀਂ ਵਰਤ ਸਕਦੇ ਹੋ ਵਹਾਅ ਲਾਗ (ਫਲੋ ਲੌਗ) VPC ਇੱਕ ਢੰਗ ਹੈ ਜੋ ਤੁਹਾਨੂੰ VPC ਵਿੱਚ ਨੈੱਟਵਰਕ ਇੰਟਰਫੇਸ 'ਤੇ ਜਾਂ ਉਸ ਤੋਂ ਜਾਣ ਵਾਲੇ IP ਟ੍ਰੈਫਿਕ ਬਾਰੇ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਅਜਿਹੇ ਲੌਗ ਹੋਰ ਕੰਮਾਂ ਵਿੱਚ ਵੀ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ - ਉਦਾਹਰਨ ਲਈ, ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਲੱਭਣਾ ਕਿ ਕੁਝ ਟ੍ਰੈਫਿਕ ਉਦਾਹਰਨ ਤੱਕ ਕਿਉਂ ਨਹੀਂ ਪਹੁੰਚਦਾ।

ਤੁਸੀਂ ਵੀ ਵਰਤ ਸਕਦੇ ਹੋ AWS ਐਕਸ-ਰੇ. ਐਕਸ-ਰੇ ਤੁਹਾਨੂੰ ਵਿਸਤ੍ਰਿਤ, "ਅੰਤਮ" ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ (ਅੰਤ-ਤੋਂ-ਅੰਤ) ਬੇਨਤੀਆਂ ਦੀ ਸੰਖੇਪ ਜਾਣਕਾਰੀ ਜਿਵੇਂ ਕਿ ਉਹ ਐਪਲੀਕੇਸ਼ਨ ਰਾਹੀਂ ਅੱਗੇ ਵਧਦੀਆਂ ਹਨ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅੰਡਰਲਾਈੰਗ ਭਾਗਾਂ ਦਾ ਨਕਸ਼ਾ ਵੀ ਬਣਾਉਂਦਾ ਹੈ। ਬਹੁਤ ਸੁਵਿਧਾਜਨਕ ਜੇਕਰ ਤੁਹਾਨੂੰ ਨਿਰਭਰਤਾ ਦੀ ਪਛਾਣ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

AWS ਐਕਸ-ਰੇ ਕੰਸੋਲ

ਇੱਕ ਨੈੱਟਵਰਕ ਨਿਰਭਰਤਾ ਨਕਸ਼ਾ ਸਿਰਫ ਇੱਕ ਅੰਸ਼ਕ ਹੱਲ ਹੈ। ਹਾਂ, ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਐਪਲੀਕੇਸ਼ਨ ਕਿਸ ਨਾਲ ਸੰਚਾਰ ਕਰਦੀ ਹੈ, ਪਰ ਹੋਰ ਨਿਰਭਰਤਾਵਾਂ ਹਨ।

ਬਹੁਤ ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨਿਰਭਰਤਾਵਾਂ ਨਾਲ ਜੁੜਨ ਲਈ DNS ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ, ਜਦੋਂ ਕਿ ਹੋਰ ਸੰਰਚਨਾ ਫਾਈਲਾਂ ਵਿੱਚ ਸੇਵਾ ਖੋਜ ਜਾਂ ਇੱਥੋਂ ਤੱਕ ਕਿ ਹਾਰਡ-ਕੋਡ ਵਾਲੇ IP ਪਤਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਨ (ਉਦਾ. /etc/hosts).

ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਬਣਾ ਸਕਦੇ ਹੋ DNS ਬਲੈਕਹੋਲ ਦੀ ਸਹਾਇਤਾ ਨਾਲ iptables ਅਤੇ ਦੇਖੋ ਕਿ ਕੀ ਟੁੱਟਦਾ ਹੈ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਹੇਠ ਦਿੱਤੀ ਕਮਾਂਡ ਦਿਓ:

❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"

DNS ਬਲੈਕ ਹੋਲ

ਜੇ ਅੰਦਰ /etc/hosts ਜਾਂ ਹੋਰ ਸੰਰਚਨਾ ਫਾਈਲਾਂ, ਤੁਹਾਨੂੰ IP ਐਡਰੈੱਸ ਮਿਲਣਗੇ ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਤੁਸੀਂ ਕੁਝ ਨਹੀਂ ਜਾਣਦੇ ਹੋ (ਹਾਂ, ਬਦਕਿਸਮਤੀ ਨਾਲ, ਅਜਿਹਾ ਵੀ ਹੁੰਦਾ ਹੈ), ਤੁਸੀਂ ਦੁਬਾਰਾ ਬਚਾਅ ਲਈ ਆ ਸਕਦੇ ਹੋ iptables. ਮੰਨ ਲਓ ਕਿ ਤੁਸੀਂ ਖੋਜਿਆ ਹੈ 8.8.8.8 ਅਤੇ ਇਹ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਇਹ Google ਦਾ ਜਨਤਕ DNS ਸਰਵਰ ਪਤਾ ਹੈ। ਵਰਤ ਕੇ iptables ਤੁਸੀਂ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਕਮਾਂਡਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸ ਪਤੇ 'ਤੇ ਆਉਣ ਵਾਲੇ ਅਤੇ ਜਾਣ ਵਾਲੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੋਕ ਸਕਦੇ ਹੋ:

❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"

ਪਹੁੰਚ ਬੰਦ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ

ਪਹਿਲਾ ਨਿਯਮ Google ਦੇ ਜਨਤਕ DNS ਤੋਂ ਸਾਰੇ ਪੈਕੇਟ ਛੱਡ ਦਿੰਦਾ ਹੈ: ping ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਪੈਕੇਟ ਵਾਪਸ ਨਹੀਂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਦੂਜਾ ਨਿਯਮ ਤੁਹਾਡੇ ਸਿਸਟਮ ਤੋਂ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੇ ਸਾਰੇ ਪੈਕੇਟਾਂ ਨੂੰ Google ਦੇ ਜਨਤਕ DNS ਵੱਲ ਛੱਡ ਦਿੰਦਾ ਹੈ - ਦੇ ਜਵਾਬ ਵਿੱਚ ping ਸਾਨੂੰ ਪ੍ਰਾਪਤ ਓਪਰੇਸ਼ਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੈ.

ਨੋਟ: ਇਸ ਖਾਸ ਕੇਸ ਵਿੱਚ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨਾ ਬਿਹਤਰ ਹੋਵੇਗਾ whois 8.8.8.8, ਪਰ ਇਹ ਸਿਰਫ਼ ਇੱਕ ਉਦਾਹਰਨ ਹੈ।

ਅਸੀਂ ਖਰਗੋਸ਼ ਦੇ ਮੋਰੀ ਦੇ ਹੇਠਾਂ ਹੋਰ ਵੀ ਡੂੰਘੇ ਜਾ ਸਕਦੇ ਹਾਂ, ਕਿਉਂਕਿ TCP ਅਤੇ UDP ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੀ ਹਰ ਚੀਜ਼ ਅਸਲ ਵਿੱਚ IP 'ਤੇ ਵੀ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ, IP ਨੂੰ ARP ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ। ਫਾਇਰਵਾਲਾਂ ਬਾਰੇ ਨਾ ਭੁੱਲੋ ...

ਜੇ ਤੁਸੀਂ ਲਾਲ ਗੋਲੀ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਵੰਡਰਲੈਂਡ ਵਿੱਚ ਰਹੋਗੇ, ਅਤੇ ਮੈਂ ਤੁਹਾਨੂੰ ਦਿਖਾਵਾਂਗਾ ਕਿ ਖਰਗੋਸ਼ ਦਾ ਮੋਰੀ ਕਿੰਨਾ ਡੂੰਘਾ ਹੈ।"

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

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

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

3. ਜ਼ਿਆਦਾ ਆਤਮਵਿਸ਼ਵਾਸ ਤੋਂ ਸਾਵਧਾਨ ਰਹੋ

"ਜੋ ਕੋਈ ਵੀ ਸੁਪਨੇ ਲੈਂਦਾ ਹੈ, ਉਸ ਵਿੱਚ ਵਿਸ਼ਵਾਸ ਕਰਦਾ ਹੈ." - ਡੈਮੋਸਥੀਨੇਸ

ਕੀ ਤੁਸੀਂ ਕਦੇ ਸੁਣਿਆ ਹੈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਿਸ਼ਵਾਸ ਪ੍ਰਭਾਵ?

ਵਿਕੀਪੀਡੀਆ ਦੇ ਅਨੁਸਾਰ, ਓਵਰ-ਆਵਿਸ਼ਵਾਸ ਪ੍ਰਭਾਵ "ਇੱਕ ਬੋਧਾਤਮਕ ਪੱਖਪਾਤ ਹੈ ਜਿਸ ਵਿੱਚ ਇੱਕ ਵਿਅਕਤੀ ਦਾ ਉਹਨਾਂ ਦੇ ਕੰਮਾਂ ਅਤੇ ਫੈਸਲਿਆਂ ਵਿੱਚ ਵਿਸ਼ਵਾਸ ਉਹਨਾਂ ਫੈਸਲਿਆਂ ਦੀ ਉਦੇਸ਼ ਸ਼ੁੱਧਤਾ ਨਾਲੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੁੰਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਵਿਸ਼ਵਾਸ ਦਾ ਪੱਧਰ ਮੁਕਾਬਲਤਨ ਉੱਚਾ ਹੁੰਦਾ ਹੈ।"

ਸੁਭਾਅ ਅਤੇ ਅਨੁਭਵ ਦੇ ਆਧਾਰ 'ਤੇ...

ਮੇਰੇ ਤਜ਼ਰਬੇ ਵਿੱਚ, ਇਹ ਵਿਗਾੜ ਇਸ ਗੱਲ ਦਾ ਇੱਕ ਬਹੁਤ ਵੱਡਾ ਸੰਕੇਤ ਹੈ ਕਿ ਹਫੜਾ-ਦਫੜੀ ਦੀ ਇੰਜੀਨੀਅਰਿੰਗ ਕਿੱਥੇ ਸ਼ੁਰੂ ਕਰਨੀ ਹੈ।

ਜ਼ਿਆਦਾ ਆਤਮ-ਵਿਸ਼ਵਾਸ ਵਾਲੇ ਆਪਰੇਟਰ ਤੋਂ ਸਾਵਧਾਨ ਰਹੋ:

ਚਾਰਲੀ: "ਇਹ ਚੀਜ਼ ਪੰਜ ਸਾਲਾਂ ਵਿੱਚ ਨਹੀਂ ਡਿੱਗੀ, ਸਭ ਕੁਝ ਠੀਕ ਹੈ!"
ਕਰੈਸ਼: "ਉਡੀਕ ਕਰੋ... ਮੈਂ ਜਲਦੀ ਹੀ ਉੱਥੇ ਆਵਾਂਗਾ!"

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

ਸੰਖੇਪ

ਹਫੜਾ-ਦਫੜੀ ਇੰਜੀਨੀਅਰਿੰਗ ਲਈ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਦੀ ਖੋਜ ਹਮੇਸ਼ਾ ਉਮੀਦ ਤੋਂ ਵੱਧ ਨਤੀਜੇ ਲਿਆਉਂਦੀ ਹੈ, ਅਤੇ ਉਹ ਟੀਮਾਂ ਜੋ ਚੀਜ਼ਾਂ ਨੂੰ ਬਹੁਤ ਜਲਦੀ ਤੋੜਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੀਆਂ ਹਨ (ਹਫੜਾ-ਦਫੜੀ) ਦੇ ਵਧੇਰੇ ਗਲੋਬਲ ਅਤੇ ਦਿਲਚਸਪ ਤੱਤ ਦੀ ਨਜ਼ਰ ਗੁਆ ਦਿੰਦੀਆਂ ਹਨ।ਇੰਜੀਨੀਅਰਿੰਗ - ਰਚਨਾਤਮਕ ਵਰਤੋਂ ਵਿਗਿਆਨਕ ਢੰਗ и ਅਨੁਭਵੀ ਸਬੂਤ (ਸਾਫਟਵੇਅਰ) ਸਿਸਟਮਾਂ ਦੇ ਡਿਜ਼ਾਈਨ, ਵਿਕਾਸ, ਸੰਚਾਲਨ, ਰੱਖ-ਰਖਾਅ ਅਤੇ ਸੁਧਾਰ ਲਈ।

ਇਹ ਦੂਜੇ ਭਾਗ ਨੂੰ ਸਮਾਪਤ ਕਰਦਾ ਹੈ. ਕਿਰਪਾ ਕਰਕੇ ਸਮੀਖਿਆਵਾਂ ਲਿਖੋ, ਵਿਚਾਰ ਸਾਂਝੇ ਕਰੋ ਜਾਂ ਸਿਰਫ਼ ਤਾੜੀਆਂ ਵਜਾਓ ਦਰਮਿਆਨੇ. ਅਗਲੇ ਭਾਗ ਵਿੱਚ ਆਈ ਅਸਲ ਵਿੱਚ ਮੈਂ ਸਿਸਟਮਾਂ ਵਿੱਚ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਪੇਸ਼ ਕਰਨ ਲਈ ਸਾਧਨਾਂ ਅਤੇ ਤਰੀਕਿਆਂ 'ਤੇ ਵਿਚਾਰ ਕਰਾਂਗਾ। ਜਦ ਤੱਕ!

ਅਨੁਵਾਦਕ ਤੋਂ ਪੀ.ਐਸ

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «ਕੈਓਸ ਇੰਜੀਨੀਅਰਿੰਗ: ਜਾਣਬੁੱਝ ਕੇ ਵਿਨਾਸ਼ ਦੀ ਕਲਾ. ਭਾਗ 1";
• «ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਉੱਚ ਉਪਲਬਧਤਾ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾਵੇ";
• «ਨਿਗਰਾਨੀ ਅਤੇ ਕੁਬਰਨੇਟਸ (ਸਮੀਖਿਆ ਅਤੇ ਵੀਡੀਓ ਰਿਪੋਰਟ)";
• «Kubernetes ਵਿੱਚ kube-proxy ਅਤੇ ਨੋਡ ਦੀ ਅਣਉਪਲਬਧਤਾ ਦੇ ਨਾਲ ਪ੍ਰਯੋਗ ਕਰਨਾ".

ਸਰੋਤ: www.habr.com