ਚੋਟੀ ਦੇ fakapov ਸਿਆਨ

ਸਾਰਾ ਚੰਗਾ! 

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

ਪ੍ਰਸਤਾਵਨਾ

ਬਹੁਤ ਸਮਾਂ ਪਹਿਲਾਂ, ਜਦੋਂ Cian ਵਿੱਚ ਮੋਨੋਲਿਥਸ ਸ਼ਾਮਲ ਸਨ, ਅਤੇ ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ ਦੇ ਕੋਈ ਸੰਕੇਤ ਨਹੀਂ ਸਨ, ਅਸੀਂ 3-5 ਪੰਨਿਆਂ ਦੀ ਜਾਂਚ ਕਰਕੇ ਇੱਕ ਸਰੋਤ ਦੀ ਉਪਲਬਧਤਾ ਨੂੰ ਮਾਪਿਆ। 

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

ਸਾਈਟ ਦੇ ਮੁੱਖ ਪੰਨੇ ਜਾਂ ਅਸੀਂ ਇਹ ਕਿਵੇਂ ਸਮਝਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਹੇਠਾਂ ਮਾਰਿਆ ਹੈ

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

ਮੰਨ ਲਓ ਕਿ ਸਾਨੂੰ ਪਤਾ ਲੱਗਾ ਹੈ ਕਿ ਸਾਈਟ ਦੇ ਬਹੁਤ ਸਾਰੇ ਅਤਿ-ਮਹੱਤਵਪੂਰਨ ਭਾਗ ਹਨ ਜੋ ਮੁੱਖ ਸੇਵਾ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹਨ - ਇਸ਼ਤਿਹਾਰਾਂ ਨੂੰ ਖੋਜਣਾ ਅਤੇ ਜਮ੍ਹਾਂ ਕਰਨਾ. ਜੇਕਰ ਫੇਲ ਹੋਣ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ 1% ਤੋਂ ਵੱਧ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ਨਾਜ਼ੁਕ ਘਟਨਾ ਹੈ। ਜੇਕਰ ਪ੍ਰਾਈਮ ਟਾਈਮ ਦੌਰਾਨ 15 ਮਿੰਟਾਂ ਦੇ ਅੰਦਰ ਗਲਤੀ ਦਰ 0,1% ਤੋਂ ਵੱਧ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਵੀ ਇੱਕ ਗੰਭੀਰ ਘਟਨਾ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਇਹ ਮਾਪਦੰਡ ਜ਼ਿਆਦਾਤਰ ਘਟਨਾਵਾਂ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ; ਬਾਕੀ ਇਸ ਲੇਖ ਦੇ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਹਨ।

ਚੋਟੀ ਦੀਆਂ ਵਧੀਆ ਘਟਨਾਵਾਂ Cian

ਇਸ ਲਈ, ਅਸੀਂ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਇਸ ਤੱਥ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨਾ ਸਿੱਖਿਆ ਹੈ ਕਿ ਇੱਕ ਘਟਨਾ ਵਾਪਰੀ ਹੈ. 

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

ਜੇ ਤੁਸੀਂ ਪਿਛਲੇ ਕੁਝ ਸਾਲਾਂ ਦੀਆਂ ਸਾਰੀਆਂ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਆਗੂ ਹਨ: 

• mssql ਸਬੰਧਤ ਘਟਨਾਵਾਂ;
• ਬਾਹਰੀ ਕਾਰਕਾਂ ਕਰਕੇ ਵਾਪਰੀਆਂ ਘਟਨਾਵਾਂ;
• ਪ੍ਰਬੰਧਕ ਗਲਤੀਆਂ।

ਆਉ ਪ੍ਰਸ਼ਾਸਕਾਂ ਦੀਆਂ ਗਲਤੀਆਂ ਦੇ ਨਾਲ-ਨਾਲ ਕੁਝ ਹੋਰ ਦਿਲਚਸਪ ਅਸਫਲਤਾਵਾਂ 'ਤੇ ਹੋਰ ਵਿਸਥਾਰ ਵਿੱਚ ਵੇਖੀਏ.

ਪੰਜਵਾਂ ਸਥਾਨ - "ਡੀਐਨਐਸ ਵਿੱਚ ਚੀਜ਼ਾਂ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਰੱਖਣਾ"

ਮੰਗਲਵਾਰ ਨੂੰ ਤੂਫਾਨੀ ਦਿਨ ਸੀ। ਅਸੀਂ DNS ਕਲੱਸਟਰ ਵਿੱਚ ਆਰਡਰ ਬਹਾਲ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ। 

ਮੈਂ ਅੰਦਰੂਨੀ DNS ਸਰਵਰਾਂ ਨੂੰ ਬਾਈਡ ਤੋਂ powerdns ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ, ਇਸਦੇ ਲਈ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੇ ਸਰਵਰ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹੋਏ, ਜਿੱਥੇ DNS ਤੋਂ ਇਲਾਵਾ ਕੁਝ ਨਹੀਂ ਹੈ. 

ਅਸੀਂ ਆਪਣੇ DCs ਦੇ ਹਰੇਕ ਟਿਕਾਣੇ ਵਿੱਚ ਇੱਕ DNS ਸਰਵਰ ਰੱਖਿਆ ਹੈ, ਅਤੇ ਜ਼ੋਨ ਨੂੰ ਬਾਈਡ ਤੋਂ powerdns ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ ਅਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਨਵੇਂ ਸਰਵਰਾਂ ਵਿੱਚ ਬਦਲਣ ਦਾ ਪਲ ਆ ਗਿਆ ਹੈ। 

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

ਸਿੱਟਾ:

ਜੇ ਪਹਿਲਾਂ ਅਸੀਂ ਕੰਮ ਦੀ ਤਿਆਰੀ ਦੌਰਾਨ ਬਾਹਰੀ ਕਾਰਕਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤਾ ਸੀ, ਤਾਂ ਹੁਣ ਉਹ ਵੀ ਉਸ ਸੂਚੀ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ ਜਿਸਦੀ ਅਸੀਂ ਤਿਆਰੀ ਕਰ ਰਹੇ ਹਾਂ। ਅਤੇ ਹੁਣ ਅਸੀਂ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ ਕਿ ਸਾਰੇ ਹਿੱਸੇ n-2 ਰਾਖਵੇਂ ਹਨ, ਅਤੇ ਕੰਮ ਦੇ ਦੌਰਾਨ ਅਸੀਂ ਇਸ ਪੱਧਰ ਨੂੰ n-1 ਤੱਕ ਘਟਾ ਸਕਦੇ ਹਾਂ।

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

ਚੌਥਾ ਸਥਾਨ - "ਨਿਗਿੰਕਸ ਵਿੱਚ ਚੀਜ਼ਾਂ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਰੱਖਣਾ"

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

Nginx ਬਣਤਰ

├── access
│   ├── allow.list
...
│   └── whitelist.conf
├── geobase
│   ├── exclude.conf
...
│   └── geo_ip_to_region_id.conf
├── geodb
│   ├── GeoIP.dat
│   ├── GeoIP2-Country.mmdb
│   └── GeoLiteCity.dat
├── inc
│   ├── error.inc
...
│   └── proxy.inc
├── lists.d
│   ├── bot.conf
...
│   ├── dynamic
│   └── geo.conf
├── lua
│   ├── cookie.lua
│   ├── log
│   │   └── log.lua
│   ├── logics
│   │   ├── include.lua
│   │   ├── ...
│   │   └── utils.lua
│   └── prom
│       ├── stats.lua
│       └── stats_prometheus.lua
├── map.d
│   ├── access.conf
│   ├── .. 
│   └── zones.conf
├── nginx.conf
├── robots.txt
├── server.d
│   ├── cian.ru
│   │   ├── cian.ru.conf
│   │   ├── ...
│   │   └── my.cian.ru.conf
├── service.d
│   ├── ...
│   └── status.conf
└── upstream.d
    ├── cian-mcs.conf
    ├── ...
    └── wafserver.conf

ਇਹ ਬਹੁਤ ਵਧੀਆ ਹੋ ਗਿਆ ਹੈ, ਪਰ ਸੰਰਚਨਾਵਾਂ ਦਾ ਨਾਮ ਬਦਲਣ ਅਤੇ ਵੰਡਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ, ਉਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਦੀ ਗਲਤ ਐਕਸਟੈਂਸ਼ਨ ਸੀ ਅਤੇ ਉਹਨਾਂ ਨੂੰ *.conf ਡਾਇਰੈਕਟਿਵ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ। ਨਤੀਜੇ ਵਜੋਂ, ਕੁਝ ਮੇਜ਼ਬਾਨ ਅਣਉਪਲਬਧ ਹੋ ਗਏ ਅਤੇ ਮੁੱਖ ਪੰਨੇ 'ਤੇ 301 ਵਾਪਸ ਆ ਗਏ। ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਕਿ ਜਵਾਬ ਕੋਡ 5xx/4xx ਨਹੀਂ ਸੀ, ਇਸ ਨੂੰ ਤੁਰੰਤ ਦੇਖਿਆ ਨਹੀਂ ਗਿਆ ਸੀ, ਪਰ ਸਿਰਫ ਸਵੇਰੇ. ਉਸ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਹਿੱਸਿਆਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਟੈਸਟ ਲਿਖਣੇ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੇ।

ਸਿੱਟਾ: 

• ਆਪਣੇ ਸੰਰਚਨਾ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਢਾਂਚਾ ਕਰੋ (ਸਿਰਫ nginx ਹੀ ਨਹੀਂ) ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਦੇ ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ 'ਤੇ ਬਣਤਰ ਬਾਰੇ ਸੋਚੋ। ਇਸ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਟੀਮ ਲਈ ਵਧੇਰੇ ਸਮਝਣ ਯੋਗ ਬਣਾਉਗੇ, ਜਿਸ ਨਾਲ ਟੀ.ਟੀ.ਐਮ.
• ਕੁਝ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਭਾਗਾਂ ਲਈ ਟੈਸਟ ਲਿਖੋ। ਉਦਾਹਰਨ ਲਈ: ਇਹ ਜਾਂਚ ਕਰਨਾ ਕਿ ਸਾਰੇ ਕੁੰਜੀ ਸਰਵਰ_ਨਾਮ ਸਹੀ ਸਥਿਤੀ + ਜਵਾਬ ਸਰੀਰ ਦਿੰਦੇ ਹਨ। ਇਹ ਸਿਰਫ ਕੁਝ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਹੱਥ ਵਿੱਚ ਰੱਖਣਾ ਕਾਫ਼ੀ ਹੋਵੇਗਾ ਜੋ ਕੰਪੋਨੈਂਟ ਦੇ ਬੁਨਿਆਦੀ ਫੰਕਸ਼ਨਾਂ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ, ਤਾਂ ਜੋ ਸਵੇਰੇ 3 ਵਜੇ ਇਹ ਯਾਦ ਨਾ ਰਹੇ ਕਿ ਹੋਰ ਕੀ ਜਾਂਚ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। 

ਤੀਜਾ ਸਥਾਨ - "ਕੈਸੈਂਡਰਾ ਵਿੱਚ ਅਚਾਨਕ ਜਗ੍ਹਾ ਖਤਮ ਹੋ ਗਈ"

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

ਇੱਕ ਤੂਫਾਨੀ ਦਿਨ ਕਲੱਸਟਰ ਲਗਭਗ ਇੱਕ ਪੇਠਾ ਵਿੱਚ ਬਦਲ ਗਿਆ, ਅਰਥਾਤ:

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

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

ਸਿੱਟਾ:

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

ਦੂਸਰਾ ਸਥਾਨ - "ਕੌਂਸਲ ਕੁੰਜੀ-ਮੁੱਲ ਸਟੋਰੇਜ ਤੋਂ ਡੇਟਾ ਗਾਇਬ ਹੋ ਗਿਆ"

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

ਸਿੱਟਾ:

• ਬਿਨਾਂ ਕਿਸੇ ਅਧਿਕਾਰ ਦੇ ਸੇਵਾਵਾਂ ਵਿੱਚ ਸਾਈਟ ਦੇ ਸੰਚਾਲਨ ਲਈ ਮਹੱਤਵਪੂਰਨ ਡੇਟਾ ਸ਼ਾਮਲ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ES ਵਿੱਚ ਅਧਿਕਾਰ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਹ ਬਿਹਤਰ ਹੋਵੇਗਾ ਕਿ ਨੈੱਟਵਰਕ ਪੱਧਰ 'ਤੇ ਹਰ ਉਸ ਥਾਂ ਤੋਂ ਪਹੁੰਚ ਤੋਂ ਇਨਕਾਰ ਕਰਨਾ ਜਿੱਥੇ ਇਸਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਸਿਰਫ਼ ਲੋੜੀਂਦੇ ਨੂੰ ਛੱਡੋ, ਅਤੇ action.destructive_requires_name: true ਵੀ ਸੈੱਟ ਕਰੋ।
• ਆਪਣੇ ਬੈਕਅੱਪ ਅਤੇ ਰਿਕਵਰੀ ਵਿਧੀ ਦਾ ਪਹਿਲਾਂ ਤੋਂ ਅਭਿਆਸ ਕਰੋ। ਉਦਾਹਰਨ ਲਈ, ਪਹਿਲਾਂ ਤੋਂ ਇੱਕ ਸਕ੍ਰਿਪਟ ਬਣਾਓ (ਉਦਾਹਰਨ ਲਈ, ਪਾਈਥਨ ਵਿੱਚ) ਜੋ ਬੈਕਅੱਪ ਅਤੇ ਰੀਸਟੋਰ ਕਰ ਸਕਦੀ ਹੈ।

ਪਹਿਲਾ ਸਥਾਨ - "ਕੈਪਟਨ ਅਨੋਬਵਿਅਸ" 

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

ਸਿੱਟਾ:

ਇਸ ਬੱਗ ਦੀ ਪੜਚੋਲ ਕਰਨਾ ਬਹੁਤ ਦਿਲਚਸਪ ਅਤੇ ਦਿਲਚਸਪ ਸੀ)। 

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

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

ਸਰੋਤ: www.habr.com