HighLoad++, Evgeniy Kuzovlev (EcommPay IT): ਕੀ ਕਰਨਾ ਹੈ ਜਦੋਂ ਇੱਕ ਮਿੰਟ ਦੇ ਡਾਊਨਟਾਈਮ ਦੀ ਕੀਮਤ $100000 ਹੁੰਦੀ ਹੈ

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

ਅਗਲੀ ਹਾਈਲੋਡ++ ਕਾਨਫਰੰਸ 6 ਅਤੇ 7 ਅਪ੍ਰੈਲ, 2020 ਨੂੰ ਸੇਂਟ ਪੀਟਰਸਬਰਗ ਵਿੱਚ ਹੋਵੇਗੀ। ਲਈ ਵੇਰਵੇ ਅਤੇ ਟਿਕਟਾਂ ਲਿੰਕ ਨੂੰ. ਨਵੰਬਰ 9, 18:00. ਹਾਈਲੋਡ++ ਮਾਸਕੋ 2018, ਦਿੱਲੀ + ਕੋਲਕਾਤਾ ਹਾਲ। ਥੀਸਸ ਅਤੇ ਪੇਸ਼ਕਾਰੀ.

Evgeniy Kuzovlev (ਇਸ ਤੋਂ ਬਾਅਦ - EC): - ਦੋਸਤੋ, ਹੈਲੋ! ਮੇਰਾ ਨਾਮ ਕੁਜ਼ੋਵਲੇਵ ਇਵਗੇਨੀ ਹੈ। ਮੈਂ EcommPay ਕੰਪਨੀ ਤੋਂ ਹਾਂ, ਇੱਕ ਖਾਸ ਡਿਵੀਜ਼ਨ EcommPay IT ਹੈ, ਕੰਪਨੀਆਂ ਦੇ ਸਮੂਹ ਦਾ IT ਡਿਵੀਜ਼ਨ। ਅਤੇ ਅੱਜ ਅਸੀਂ ਡਾਊਨਟਾਈਮ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ - ਉਹਨਾਂ ਤੋਂ ਕਿਵੇਂ ਬਚਣਾ ਹੈ, ਉਹਨਾਂ ਦੇ ਨਤੀਜਿਆਂ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਕਿਵੇਂ ਕਰਨਾ ਹੈ ਜੇਕਰ ਇਸ ਤੋਂ ਬਚਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ ਹੈ। ਵਿਸ਼ੇ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦੱਸਿਆ ਗਿਆ ਹੈ: "ਜਦੋਂ ਇੱਕ ਮਿੰਟ ਦੇ ਡਾਊਨਟਾਈਮ ਦੀ ਕੀਮਤ $100 ਹੈ ਤਾਂ ਕੀ ਕਰਨਾ ਹੈ"? ਅੱਗੇ ਦੇਖਦੇ ਹੋਏ, ਸਾਡੇ ਨੰਬਰ ਤੁਲਨਾਤਮਕ ਹਨ.

EcommPay IT ਕੀ ਕਰਦਾ ਹੈ?

ਅਸੀਂ ਕੌਣ ਹਾਂ? ਮੈਂ ਇੱਥੇ ਤੁਹਾਡੇ ਸਾਹਮਣੇ ਕਿਉਂ ਖੜ੍ਹਾ ਹਾਂ? ਮੈਨੂੰ ਇੱਥੇ ਤੁਹਾਨੂੰ ਕੁਝ ਦੱਸਣ ਦਾ ਅਧਿਕਾਰ ਕਿਉਂ ਹੈ? ਅਤੇ ਅਸੀਂ ਇੱਥੇ ਹੋਰ ਵਿਸਥਾਰ ਵਿੱਚ ਕਿਸ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ?

ਕੰਪਨੀਆਂ ਦਾ EcommPay ਸਮੂਹ ਇੱਕ ਅੰਤਰਰਾਸ਼ਟਰੀ ਪ੍ਰਾਪਤਕਰਤਾ ਹੈ। ਅਸੀਂ ਪੂਰੀ ਦੁਨੀਆ ਵਿੱਚ ਭੁਗਤਾਨਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦੇ ਹਾਂ - ਰੂਸ, ਯੂਰਪ, ਦੱਖਣ-ਪੂਰਬੀ ਏਸ਼ੀਆ (ਸਾਰੀ ਦੁਨੀਆ ਵਿੱਚ)। ਸਾਡੇ ਕੋਲ 9 ਦਫਤਰ ਹਨ, ਕੁੱਲ ਮਿਲਾ ਕੇ 500 ਕਰਮਚਾਰੀ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਅੱਧੇ ਤੋਂ ਵੀ ਘੱਟ IT ਮਾਹਰ ਹਨ। ਹਰ ਚੀਜ਼ ਜੋ ਅਸੀਂ ਕਰਦੇ ਹਾਂ, ਹਰ ਚੀਜ਼ ਜਿਸ ਤੋਂ ਅਸੀਂ ਪੈਸਾ ਕਮਾਉਂਦੇ ਹਾਂ, ਅਸੀਂ ਆਪਣੇ ਆਪ ਕੀਤਾ।

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

6 ਸਾਲ ਪਹਿਲਾਂ ਇਹ ਅਜਿਹਾ ਸਟਾਰਟਅੱਪ ਸੀ ਜਦੋਂ ਮੁੰਡੇ ਕਾਰੋਬਾਰ ਦੇ ਨਾਲ ਆਏ ਸਨ। ਉਹ ਇੱਕ ਵਿਚਾਰ ਦੁਆਰਾ ਇੱਕਜੁੱਟ ਹੋ ਗਏ ਸਨ (ਇੱਕ ਵਿਚਾਰ ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਕੁਝ ਨਹੀਂ ਸੀ), ਅਤੇ ਅਸੀਂ ਦੌੜ ਗਏ। ਕਿਸੇ ਵੀ ਸ਼ੁਰੂਆਤ ਵਾਂਗ, ਅਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਦੌੜੇ... ਸਾਡੇ ਲਈ, ਗਤੀ ਗੁਣਵੱਤਾ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਸੀ।

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

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

ਡਾਊਨਟਾਈਮ। ਕਾਰਵਾਈ ਦੇ ਹੁਕਮ.

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

ਜਦੋਂ ਅਸੀਂ ਆਪਣੀ ਪਹੁੰਚ ਨੂੰ ਬਦਲਣਾ ਸ਼ੁਰੂ ਕੀਤਾ, ਅਸੀਂ 4 ਹੁਕਮਾਂ ਦਾ ਗਠਨ ਕੀਤਾ। ਮੈਂ ਉਹਨਾਂ ਨੂੰ ਸਲਾਈਡਾਂ 'ਤੇ ਪੇਸ਼ ਕੀਤਾ ਹੈ:

ਇਹ ਹੁਕਮ ਕਾਫ਼ੀ ਸਧਾਰਨ ਹਨ:

• ਜਲਦੀ ਸਮੱਸਿਆ ਦੀ ਪਛਾਣ ਕਰੋ।
• ਇਸ ਤੋਂ ਵੀ ਜਲਦੀ ਛੁਟਕਾਰਾ ਪਾਓ।
• ਕਾਰਨ ਨੂੰ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰੋ (ਬਾਅਦ ਵਿੱਚ, ਡਿਵੈਲਪਰਾਂ ਲਈ)।
• ਅਤੇ ਪਹੁੰਚ ਨੂੰ ਮਿਆਰੀ ਬਣਾਓ।

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

ਸਮੱਸਿਆ ਨਿਪਟਾਰਾ: ਉਹ ਕਦੋਂ ਵਾਪਰਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਬਾਰੇ ਕੀ ਕਰਨਾ ਹੈ?

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

ਇਹਨਾਂ ਲੋੜਾਂ ਨੂੰ ਤਿਆਰ ਕਰਨ ਲਈ, ਅਸੀਂ ਆਪਣੇ ਆਪ ਤੋਂ ਇਹ ਸਵਾਲ ਪੁੱਛਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ: “ਸਾਨੂੰ ਸਮੱਸਿਆਵਾਂ ਕਦੋਂ ਆਉਂਦੀਆਂ ਹਨ”? ਅਤੇ ਸਮੱਸਿਆਵਾਂ, ਜਿਵੇਂ ਕਿ ਇਹ ਨਿਕਲਿਆ, ਚਾਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਵਾਪਰਦਾ ਹੈ:

• ਹਾਰਡਵੇਅਰ ਅਸਫਲਤਾ।
• ਬਾਹਰੀ ਸੇਵਾਵਾਂ ਅਸਫਲ ਰਹੀਆਂ।
• ਸਾਫਟਵੇਅਰ ਸੰਸਕਰਣ ਨੂੰ ਬਦਲਣਾ (ਉਹੀ ਤੈਨਾਤੀ)।
• ਵਿਸਫੋਟਕ ਲੋਡ ਵਾਧਾ.

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

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

ਫਿਰ ਕੀ ਕਰੀਏ? ਇੱਥੇ ਦੋ ਵਿਕਲਪ ਹਨ. ਪਹਿਲਾਂ, ਜੇ ਤੁਸੀਂ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਸ ਸੇਵਾ ਨੂੰ ਕਿਸੇ ਤਰੀਕੇ ਨਾਲ ਡੁਪਲੀਕੇਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਅਸੀਂ ਕਰ ਸਕਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਇੱਕ ਸੇਵਾ ਤੋਂ ਦੂਜੀ ਸੇਵਾ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਟ੍ਰਾਂਸਫਰ ਕਰਦੇ ਹਾਂ: ਉਦਾਹਰਨ ਲਈ, Sberbank ਦੁਆਰਾ ਕਾਰਡਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ ਗਈ ਸੀ, Sberbank ਨੂੰ ਸਮੱਸਿਆਵਾਂ ਆ ਰਹੀਆਂ ਹਨ - ਅਸੀਂ ਟ੍ਰੈਫਿਕ ਨੂੰ [ਸ਼ਰਤ ਅਨੁਸਾਰ] Raiffeisen ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕਰਦੇ ਹਾਂ। ਦੂਜੀ ਚੀਜ਼ ਜੋ ਅਸੀਂ ਕਰ ਸਕਦੇ ਹਾਂ ਉਹ ਹੈ ਬਾਹਰੀ ਸੇਵਾਵਾਂ ਦੀ ਅਸਫਲਤਾ ਨੂੰ ਬਹੁਤ ਜਲਦੀ ਨੋਟਿਸ ਕਰਨਾ, ਅਤੇ ਇਸ ਲਈ ਅਸੀਂ ਰਿਪੋਰਟ ਦੇ ਅਗਲੇ ਹਿੱਸੇ ਵਿੱਚ ਜਵਾਬ ਦੀ ਗਤੀ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ.

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

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

ਅਸੀਂ ਇੱਕ ਥੋੜੀ ਗੈਰ-ਰਵਾਇਤੀ ਕੰਪਨੀ ਹਾਂ। ਇੱਥੇ ਹਰ ਕੋਈ “ਕੁਬਰਨੇਟਸ” ਬਾਰੇ ਗੱਲ ਕਰ ਰਿਹਾ ਹੈ, ਬੱਦਲਾਂ ਬਾਰੇ - ਸਾਡੇ ਕੋਲ ਨਾ ਤਾਂ “ਕੁਬਰਨੇਟਸ” ਹਨ ਅਤੇ ਨਾ ਹੀ ਬੱਦਲ। ਪਰ ਸਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਡੇਟਾ ਸੈਂਟਰਾਂ ਵਿੱਚ ਹਾਰਡਵੇਅਰ ਦੇ ਰੈਕ ਹਨ, ਅਤੇ ਅਸੀਂ ਇਸ ਹਾਰਡਵੇਅਰ 'ਤੇ ਰਹਿਣ ਲਈ ਮਜਬੂਰ ਹਾਂ, ਅਸੀਂ ਇਸ ਸਭ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੋਣ ਲਈ ਮਜਬੂਰ ਹਾਂ। ਇਸ ਲਈ, ਅਸੀਂ ਇਸ ਸੰਦਰਭ ਵਿੱਚ ਗੱਲ ਕਰਾਂਗੇ. ਇਸ ਲਈ, ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ. ਪਹਿਲੇ ਦੋ ਬਰੈਕਟਾਂ ਵਿੱਚੋਂ ਕੱਢੇ ਗਏ ਸਨ।

ਸਾਫਟਵੇਅਰ ਸੰਸਕਰਣ ਨੂੰ ਬਦਲਣਾ. ਆਧਾਰ

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

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

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

ਸਾਫਟਵੇਅਰ ਸੰਸਕਰਣ ਨੂੰ ਬਦਲਣ ਲਈ ਲੋੜਾਂ

ਇੱਥੇ ਤਿੰਨ ਲੋੜਾਂ ਹਨ:

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

  
  
  ਇਹ ਬਹੁਤ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ, ਅਸੀਂ ਕਦੇ ਵੀ ਇਸਦੀ ਖੋਜ ਨਹੀਂ ਕੀਤੀ - ਇਹ ਨੀਲਾ/ਹਰਾ ਤੈਨਾਤੀ ਹੈ। ਇਹ ਕੀ ਹੈ? ਤੁਹਾਡੇ ਕੋਲ ਸਰਵਰਾਂ ਦੇ ਹਰੇਕ ਸਮੂਹ ਲਈ ਇੱਕ ਕਾਪੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜਿਸ 'ਤੇ ਤੁਹਾਡੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਸਥਾਪਤ ਹਨ। ਕਾਪੀ "ਨਿੱਘੀ" ਹੈ: ਇਸ 'ਤੇ ਕੋਈ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਹੈ, ਪਰ ਕਿਸੇ ਵੀ ਸਮੇਂ ਇਸ ਟ੍ਰੈਫਿਕ ਨੂੰ ਇਸ ਕਾਪੀ 'ਤੇ ਭੇਜਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਕਾਪੀ ਵਿੱਚ ਪਿਛਲਾ ਸੰਸਕਰਣ ਸ਼ਾਮਲ ਹੈ। ਅਤੇ ਤੈਨਾਤੀ ਦੇ ਸਮੇਂ, ਤੁਸੀਂ ਕੋਡ ਨੂੰ ਇੱਕ ਅਕਿਰਿਆਸ਼ੀਲ ਕਾਪੀ ਵਿੱਚ ਰੋਲ ਆਊਟ ਕਰਦੇ ਹੋ। ਫਿਰ ਤੁਸੀਂ ਟ੍ਰੈਫਿਕ ਦੇ ਕੁਝ ਹਿੱਸੇ (ਜਾਂ ਸਾਰੇ) ਨੂੰ ਨਵੇਂ ਸੰਸਕਰਣ ਵਿੱਚ ਬਦਲਦੇ ਹੋ. ਇਸ ਤਰ੍ਹਾਂ, ਪੁਰਾਣੇ ਸੰਸਕਰਣ ਤੋਂ ਨਵੇਂ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਪ੍ਰਵਾਹ ਨੂੰ ਬਦਲਣ ਲਈ, ਤੁਹਾਨੂੰ ਸਿਰਫ ਇੱਕ ਕਾਰਵਾਈ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ: ਤੁਹਾਨੂੰ ਅਪਸਟ੍ਰੀਮ ਵਿੱਚ ਬੈਲੇਂਸਰ ਨੂੰ ਬਦਲਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਦਿਸ਼ਾ ਬਦਲਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ - ਇੱਕ ਅੱਪਸਟ੍ਰੀਮ ਤੋਂ ਦੂਜੇ ਤੱਕ। ਇਹ ਬਹੁਤ ਸੁਵਿਧਾਜਨਕ ਹੈ ਅਤੇ ਤੇਜ਼ ਸਵਿਚਿੰਗ ਅਤੇ ਤੇਜ਼ ਰੋਲਬੈਕ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ।

  ਇੱਥੇ ਦੂਜੇ ਸਵਾਲ ਦਾ ਹੱਲ ਨਿਊਨਤਮ ਹੈ: ਤੁਸੀਂ ਆਪਣੇ ਟ੍ਰੈਫਿਕ ਦਾ ਸਿਰਫ ਇੱਕ ਹਿੱਸਾ ਇੱਕ ਨਵੀਂ ਲਾਈਨ ਤੇ, ਇੱਕ ਨਵੇਂ ਕੋਡ ਵਾਲੀ ਇੱਕ ਲਾਈਨ ਵਿੱਚ ਭੇਜ ਸਕਦੇ ਹੋ (ਉਦਾਹਰਣ ਵਜੋਂ, 2%)। ਅਤੇ ਇਹ 2% 100% ਨਹੀਂ ਹਨ! ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਅਸਫਲ ਤੈਨਾਤੀ ਦੇ ਕਾਰਨ ਆਪਣਾ 100% ਟ੍ਰੈਫਿਕ ਗੁਆ ਦਿੱਤਾ ਹੈ, ਤਾਂ ਇਹ ਡਰਾਉਣਾ ਹੈ; ਜੇਕਰ ਤੁਸੀਂ ਆਪਣੇ ਟ੍ਰੈਫਿਕ ਦਾ 2% ਗੁਆ ਦਿੱਤਾ ਹੈ, ਤਾਂ ਇਹ ਕੋਝਾ ਹੈ, ਪਰ ਇਹ ਡਰਾਉਣਾ ਨਹੀਂ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਉਪਭੋਗਤਾ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਇਸ ਵੱਲ ਧਿਆਨ ਨਹੀਂ ਦੇਣਗੇ, ਕਿਉਂਕਿ ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ (ਸਾਰੇ ਨਹੀਂ) ਇੱਕੋ ਉਪਭੋਗਤਾ, F5 ਨੂੰ ਦਬਾਉਣ ਨਾਲ, ਦੂਜੇ, ਕਾਰਜਸ਼ੀਲ ਸੰਸਕਰਣ 'ਤੇ ਲਿਜਾਇਆ ਜਾਵੇਗਾ।

  ਨੀਲਾ/ਹਰਾ ਤੈਨਾਤੀ। ਰੂਟਿੰਗ

  ਹਾਲਾਂਕਿ, ਸਭ ਕੁਝ ਇੰਨਾ ਸਰਲ ਨਹੀਂ ਹੈ "ਨੀਲਾ/ਹਰਾ ਤੈਨਾਤ"... ਸਾਡੇ ਸਾਰੇ ਭਾਗਾਂ ਨੂੰ ਤਿੰਨ ਸਮੂਹਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ:

  • ਇਹ ਫਰੰਟਐਂਡ ਹੈ (ਭੁਗਤਾਨ ਪੰਨੇ ਜੋ ਸਾਡੇ ਗਾਹਕ ਦੇਖਦੇ ਹਨ);
  • ਪ੍ਰੋਸੈਸਿੰਗ ਕੋਰ;
  • ਭੁਗਤਾਨ ਪ੍ਰਣਾਲੀਆਂ (ਬੈਂਕਾਂ, ਮਾਸਟਰਕਾਰਡ, ਵੀਜ਼ਾ...) ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਅਡਾਪਟਰ।

  ਅਤੇ ਇੱਥੇ ਇੱਕ ਸੂਖਮਤਾ ਹੈ - ਸੂਖਮ ਲਾਈਨਾਂ ਦੇ ਵਿਚਕਾਰ ਰੂਟਿੰਗ ਵਿੱਚ ਹੈ. ਜੇਕਰ ਤੁਸੀਂ ਸਿਰਫ਼ 100% ਟਰੈਫ਼ਿਕ ਨੂੰ ਬਦਲਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਹ ਸਮੱਸਿਆਵਾਂ ਨਹੀਂ ਹਨ। ਪਰ ਜੇ ਤੁਸੀਂ 2% ਨੂੰ ਬਦਲਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸਵਾਲ ਪੁੱਛਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹੋ: "ਇਹ ਕਿਵੇਂ ਕਰਨਾ ਹੈ?" ਸਭ ਤੋਂ ਸਧਾਰਨ ਗੱਲ ਸਿੱਧੀ ਅੱਗੇ ਹੈ: ਤੁਸੀਂ ਰਾਊਂਡ ਰੌਬਿਨ ਨੂੰ ਬੇਤਰਤੀਬ ਚੋਣ ਦੁਆਰਾ nginx ਵਿੱਚ ਸੈੱਟ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਖੱਬੇ ਪਾਸੇ 2%, ਸੱਜੇ ਪਾਸੇ 98% ਹੈ। ਪਰ ਇਹ ਹਮੇਸ਼ਾ ਢੁਕਵਾਂ ਨਹੀਂ ਹੁੰਦਾ.

  ਉਦਾਹਰਨ ਲਈ, ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਇੱਕ ਉਪਭੋਗਤਾ ਇੱਕ ਤੋਂ ਵੱਧ ਬੇਨਤੀਆਂ ਨਾਲ ਸਿਸਟਮ ਨਾਲ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ। ਇਹ ਆਮ ਹੈ: 2, 3, 4, 5 ਬੇਨਤੀਆਂ - ਤੁਹਾਡੇ ਸਿਸਟਮ ਇੱਕੋ ਜਿਹੇ ਹੋ ਸਕਦੇ ਹਨ। ਅਤੇ ਜੇਕਰ ਇਹ ਤੁਹਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਦੀਆਂ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਉਸੇ ਲਾਈਨ 'ਤੇ ਆਉਂਦੀਆਂ ਹਨ ਜਿਸ 'ਤੇ ਪਹਿਲੀ ਬੇਨਤੀ ਆਈ ਸੀ, ਜਾਂ (ਦੂਜੇ ਬਿੰਦੂ) ਉਪਭੋਗਤਾ ਦੀਆਂ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਸਵਿੱਚ ਤੋਂ ਬਾਅਦ ਨਵੀਂ ਲਾਈਨ 'ਤੇ ਆਉਂਦੀਆਂ ਹਨ (ਉਹ ਪਹਿਲਾਂ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਸੀ. ਸਿਸਟਮ, ਸਵਿੱਚ ਤੋਂ ਪਹਿਲਾਂ), - ਫਿਰ ਇਹ ਬੇਤਰਤੀਬ ਵੰਡ ਤੁਹਾਡੇ ਲਈ ਢੁਕਵੀਂ ਨਹੀਂ ਹੈ। ਫਿਰ ਹੇਠਾਂ ਦਿੱਤੇ ਵਿਕਲਪ ਹਨ:

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

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

  ਇਹ ਸਾਡੇ ਲਈ ਅਨੁਕੂਲ ਨਹੀਂ ਸੀ ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਨਿਯਮਤ nginx ਸੀ. nginx+ 'ਤੇ ਸਵਿਚ ਕਰਨਾ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਇਹ ਮਹਿੰਗਾ ਹੈ, ਇਹ ਸਿਰਫ ਇਹ ਹੈ ਕਿ ਇਹ ਸਾਡੇ ਲਈ ਕੁਝ ਦਰਦਨਾਕ ਸੀ ਅਤੇ ਬਹੁਤ ਸਹੀ ਨਹੀਂ ਸੀ। ਉਦਾਹਰਨ ਲਈ, “ਸਟਿਕਸ ਸੈਸ਼ਨ” ਸਾਡੇ ਲਈ ਇਸ ਸਧਾਰਨ ਕਾਰਨ ਕਰਕੇ ਕੰਮ ਨਹੀਂ ਕਰਦੇ ਹਨ ਕਿ “ਸਟਿਕਸ ਸੈਸ਼ਨ” “Either-or” ਦੇ ਅਧਾਰ ਤੇ ਰੂਟਿੰਗ ਦੀ ਆਗਿਆ ਨਹੀਂ ਦਿੰਦੇ ਹਨ। ਉੱਥੇ ਤੁਸੀਂ ਨਿਸ਼ਚਿਤ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਅਸੀਂ "ਸਟਿਕਸ ਸੈਸ਼ਨ" ਕੀ ਕਰਦੇ ਹਾਂ, ਉਦਾਹਰਨ ਲਈ, IP ਐਡਰੈੱਸ ਜਾਂ IP ਐਡਰੈੱਸ ਅਤੇ ਕੂਕੀਜ਼ ਦੁਆਰਾ ਜਾਂ ਪੋਸਟਪੈਰਾਮੀਟਰ ਦੁਆਰਾ, ਪਰ "ਜਾਂ ਜਾਂ" ਉੱਥੇ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਹੈ।

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

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

  ਨੀਲਾ/ਹਰਾ ਤੈਨਾਤੀ। ਫਾਇਦੇ ਅਤੇ ਨੁਕਸਾਨ

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

  
  
  ਇਸ ਲਈ, ਇਹ ਸਾਡੇ ਲਈ ਕੰਮ ਨਹੀਂ ਕੀਤਾ - ਅਸੀਂ ਖੁੱਲ੍ਹੇਆਮ ਕੰਮ ਕੀਤਾ. ਇਸ ਅਨੁਸਾਰ, ਰੂਟਿੰਗ ਦੇ ਨਾਲ ਸਾਨੂੰ ਕੁਝ ਅਜਿਹਾ ਮਿਲਿਆ:

  ਨੀਲੀ/ਹਰੇ ਤੈਨਾਤੀ ਦੇ, ਇਸਦੇ ਅਨੁਸਾਰ, ਮੈਂ ਦੱਸੇ ਫਾਇਦੇ ਅਤੇ ਨੁਕਸਾਨ ਹਨ।

  ਦੋ ਨੁਕਸਾਨ:

  • ਤੁਹਾਨੂੰ ਰੂਟਿੰਗ ਨਾਲ ਪਰੇਸ਼ਾਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ;
  • ਦੂਜਾ ਮੁੱਖ ਨੁਕਸਾਨ ਖਰਚਾ ਹੈ।

  ਤੁਹਾਨੂੰ ਦੁੱਗਣੇ ਸਰਵਰਾਂ ਦੀ ਲੋੜ ਹੈ, ਤੁਹਾਨੂੰ ਇਸ ਤੋਂ ਦੁੱਗਣੇ ਸੰਚਾਲਨ ਸਰੋਤਾਂ ਦੀ ਲੋੜ ਹੈ, ਤੁਹਾਨੂੰ ਇਸ ਪੂਰੇ ਚਿੜੀਆਘਰ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਲਈ ਦੁੱਗਣਾ ਮਿਹਨਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

  ਤਰੀਕੇ ਨਾਲ, ਫਾਇਦਿਆਂ ਵਿੱਚ ਇੱਕ ਹੋਰ ਚੀਜ਼ ਹੈ ਜਿਸਦਾ ਮੈਂ ਪਹਿਲਾਂ ਜ਼ਿਕਰ ਨਹੀਂ ਕੀਤਾ ਹੈ: ਲੋਡ ਵਾਧੇ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਰਿਜ਼ਰਵ ਹੈ. ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਲੋਡ ਵਿੱਚ ਵਿਸਫੋਟਕ ਵਾਧਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਉਪਭੋਗਤਾ ਹਨ, ਫਿਰ ਤੁਸੀਂ 50 ਤੋਂ 50 ਵੰਡ ਵਿੱਚ ਸਿਰਫ਼ ਦੂਜੀ ਲਾਈਨ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦੇ ਹੋ - ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਤੁਰੰਤ ਤੁਹਾਡੇ ਕਲੱਸਟਰ ਵਿੱਚ x2 ਸਰਵਰ ਹਨ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਹੋਰ ਸਰਵਰ ਹੋਣ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਨਹੀਂ ਕਰਦੇ.

  ਇੱਕ ਤੇਜ਼ ਤੈਨਾਤੀ ਕਿਵੇਂ ਕਰੀਏ?

  ਅਸੀਂ ਇਸ ਬਾਰੇ ਗੱਲ ਕੀਤੀ ਕਿ ਘੱਟ ਤੋਂ ਘੱਟ ਅਤੇ ਤੇਜ਼ ਰੋਲਬੈਕ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਕਿਵੇਂ ਹੱਲ ਕੀਤਾ ਜਾਵੇ, ਪਰ ਸਵਾਲ ਇਹ ਰਹਿੰਦਾ ਹੈ: "ਛੇਤੀ ਨਾਲ ਕਿਵੇਂ ਤਾਇਨਾਤ ਕੀਤਾ ਜਾਵੇ?"

  
  
  ਇਹ ਇੱਥੇ ਛੋਟਾ ਅਤੇ ਸਧਾਰਨ ਹੈ।

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

    ਆਰਟੀਫੈਕਟ ਕੀ ਹੈ? ਇੱਕ ਆਰਟੀਫੈਕਟ ਇੱਕ ਅਸੈਂਬਲ ਬਿਲਡ ਹੁੰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਸਾਰੇ ਅਸੈਂਬਲੀ ਹਿੱਸੇ ਪਹਿਲਾਂ ਹੀ ਮੁਕੰਮਲ ਹੋ ਚੁੱਕੇ ਹੁੰਦੇ ਹਨ। ਅਸੀਂ ਇਸ ਆਰਟੀਫੈਕਟ ਨੂੰ ਆਰਟੀਫੈਕਟ ਸਟੋਰੇਜ ਵਿੱਚ ਸਟੋਰ ਕਰਦੇ ਹਾਂ। ਇੱਕ ਸਮੇਂ ਅਸੀਂ ਦੋ ਅਜਿਹੇ ਸਟੋਰੇਜ਼ ਵਰਤੇ - ਇਹ Nexus ਅਤੇ ਹੁਣ jFrog Artifactory ਸੀ। ਅਸੀਂ ਸ਼ੁਰੂ ਵਿੱਚ "Nexus" ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਕਿਉਂਕਿ ਅਸੀਂ ਜਾਵਾ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਇਸ ਪਹੁੰਚ ਦਾ ਅਭਿਆਸ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ (ਇਹ ਇਸ ਦੇ ਅਨੁਕੂਲ ਸੀ)। ਫਿਰ ਉਹਨਾਂ ਨੇ ਉੱਥੇ PHP ਵਿੱਚ ਲਿਖੀਆਂ ਕੁਝ ਐਪਲੀਕੇਸ਼ਨਾਂ ਪਾ ਦਿੱਤੀਆਂ; ਅਤੇ "Nexus" ਹੁਣ ਢੁਕਵਾਂ ਨਹੀਂ ਸੀ, ਅਤੇ ਇਸਲਈ ਅਸੀਂ jFrog Artefactory ਨੂੰ ਚੁਣਿਆ, ਜੋ ਲਗਭਗ ਹਰ ਚੀਜ਼ ਨੂੰ ਕਲਾਤਮਕ ਬਣਾ ਸਕਦਾ ਹੈ। ਅਸੀਂ ਇਸ ਬਿੰਦੂ 'ਤੇ ਵੀ ਆ ਗਏ ਹਾਂ ਕਿ ਇਸ ਆਰਟੀਫੈਕਟ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਅਸੀਂ ਆਪਣੇ ਖੁਦ ਦੇ ਬਾਈਨਰੀ ਪੈਕੇਜਾਂ ਨੂੰ ਸਟੋਰ ਕਰਦੇ ਹਾਂ ਜੋ ਅਸੀਂ ਸਰਵਰਾਂ ਲਈ ਇਕੱਤਰ ਕਰਦੇ ਹਾਂ।

  ਵਿਸਫੋਟਕ ਲੋਡ ਵਾਧਾ

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

  ਅਸੀਂ ਇੱਕ ਨਵੀਂ ਪ੍ਰਣਾਲੀ ਲਿਖੀ ਹੈ - ਇਹ ਸੇਵਾ-ਮੁਖੀ, ਫੈਸ਼ਨੇਬਲ, ਸੁੰਦਰ, ਹਰ ਜਗ੍ਹਾ ਕਾਮੇ, ਹਰ ਜਗ੍ਹਾ ਕਤਾਰਾਂ, ਹਰ ਜਗ੍ਹਾ ਅਸਿੰਕ੍ਰੋਨੀ ਹੈ। ਅਤੇ ਅਜਿਹੇ ਸਿਸਟਮ ਵਿੱਚ, ਡਾਟਾ ਵੱਖ-ਵੱਖ ਪ੍ਰਵਾਹ ਦੁਆਰਾ ਵਹਿ ਸਕਦਾ ਹੈ. ਪਹਿਲੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲਈ, 1, 3, 10 ਵੇਂ ਕਰਮਚਾਰੀ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਦੂਜੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲਈ - 2, 4, 5 ਵੀਂ। ਅਤੇ ਅੱਜ, ਮੰਨ ਲਓ, ਸਵੇਰੇ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਡੇਟਾ ਪ੍ਰਵਾਹ ਹੁੰਦਾ ਹੈ ਜੋ ਪਹਿਲੇ ਤਿੰਨ ਕਰਮਚਾਰੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਅਤੇ ਸ਼ਾਮ ਨੂੰ ਇਹ ਨਾਟਕੀ ਢੰਗ ਨਾਲ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਹਰ ਚੀਜ਼ ਬਾਕੀ ਤਿੰਨ ਕਰਮਚਾਰੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ।

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

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

  ਇਹ ਸਾਡੇ ਲਈ ਇੱਕ ਸਮੱਸਿਆ ਕਿਉਂ ਹੈ? ਆਓ ਥੋੜਾ ਪਿੱਛੇ ਮੁੜੀਏ। ਹੁਣ ਸਾਡੇ ਪਿੱਛੇ ਲਗਭਗ 70 ਭੁਗਤਾਨ ਪ੍ਰਣਾਲੀਆਂ ਹਨ। ਸਵੇਰ ਨੂੰ, ਟ੍ਰੈਫਿਕ Sberbank ਦੁਆਰਾ ਜਾਂਦਾ ਹੈ, ਫਿਰ Sberbank ਡਿੱਗ ਗਿਆ, ਉਦਾਹਰਨ ਲਈ, ਅਤੇ ਅਸੀਂ ਇਸਨੂੰ ਕਿਸੇ ਹੋਰ ਭੁਗਤਾਨ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਬਦਲਦੇ ਹਾਂ। ਸਾਡੇ ਕੋਲ Sberbank ਤੋਂ ਪਹਿਲਾਂ 100 ਕਰਮਚਾਰੀ ਸਨ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਸਾਨੂੰ ਕਿਸੇ ਹੋਰ ਭੁਗਤਾਨ ਪ੍ਰਣਾਲੀ ਲਈ 100 ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਵਧਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਅਤੇ ਇਹ ਸਭ ਕੁਝ ਮਨੁੱਖੀ ਭਾਗੀਦਾਰੀ ਤੋਂ ਬਿਨਾਂ ਹੋਣਾ ਫਾਇਦੇਮੰਦ ਹੈ। ਕਿਉਂਕਿ ਜੇਕਰ ਮਨੁੱਖੀ ਭਾਗੀਦਾਰੀ ਹੈ, ਤਾਂ ਉੱਥੇ ਇੱਕ ਇੰਜੀਨੀਅਰ 24/7 ਬੈਠਣਾ ਚਾਹੀਦਾ ਹੈ, ਜੋ ਸਿਰਫ ਇਹ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਅਜਿਹੀਆਂ ਅਸਫਲਤਾਵਾਂ, ਜਦੋਂ 70 ਸਿਸਟਮ ਤੁਹਾਡੇ ਪਿੱਛੇ ਹੁੰਦੇ ਹਨ, ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਵਾਪਰਦੇ ਹਨ.

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

  ਅਜੇ ਤੱਕ ਅਸੀਂ ਇਸ ਨੂੰ ਓਪਨ ਸੋਰਸ ਨਹੀਂ ਕੀਤਾ ਹੈ, ਪਰ ਜੇ ਅਚਾਨਕ ਰਿਪੋਰਟ ਤੋਂ ਬਾਅਦ, ਇਹ ਮਹਿਸੂਸ ਕਰਨ ਤੋਂ ਬਾਅਦ ਕਿ ਤੁਹਾਨੂੰ ਅਜਿਹੀ ਚੀਜ਼ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਤੁਹਾਨੂੰ ਇਸਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਮੇਰੇ ਸੰਪਰਕ ਆਖਰੀ ਸਲਾਈਡ ਵਿੱਚ ਹਨ - ਕਿਰਪਾ ਕਰਕੇ ਮੈਨੂੰ ਲਿਖੋ. ਜੇਕਰ ਘੱਟੋ-ਘੱਟ 3-5 ਲੋਕ ਹਨ, ਤਾਂ ਅਸੀਂ ਇਸ ਨੂੰ ਸਪਾਂਸਰ ਕਰਾਂਗੇ।

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

  ਜੇਕਰ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਤਾਂ ਇਸ ਤਸਵੀਰ 'ਚ ਇਕ ਗੜਬੜ ਹੈ। ਚੋਟੀ ਦੇ ਚਾਰਟ 'ਤੇ, ਚਾਰਟ ਵਿੱਚੋਂ ਇੱਕ 45 ਸਕਿੰਟਾਂ ਵਿੱਚ ਕ੍ਰੈਸ਼ ਹੋ ਗਿਆ - ਭੁਗਤਾਨ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੇਠਾਂ ਚਲਾ ਗਿਆ। ਤੁਰੰਤ, ਟ੍ਰੈਫਿਕ ਨੂੰ 2 ਮਿੰਟਾਂ ਵਿੱਚ ਲਿਆਂਦਾ ਗਿਆ ਅਤੇ ਇੱਕ ਹੋਰ ਭੁਗਤਾਨ ਪ੍ਰਣਾਲੀ 'ਤੇ ਕਤਾਰ ਵਧਣੀ ਸ਼ੁਰੂ ਹੋ ਗਈ, ਜਿੱਥੇ ਕੋਈ ਕਰਮਚਾਰੀ ਨਹੀਂ ਸਨ (ਅਸੀਂ ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ - ਇਸਦੇ ਉਲਟ, ਅਸੀਂ ਸਰੋਤ ਦਾ ਸਹੀ ਢੰਗ ਨਾਲ ਨਿਪਟਾਰਾ ਕੀਤਾ)। ਅਸੀਂ ਗਰਮੀ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ - ਇੱਥੇ ਇੱਕ ਘੱਟੋ ਘੱਟ ਗਿਣਤੀ ਸੀ, ਲਗਭਗ 5-10 ਕਰਮਚਾਰੀ, ਪਰ ਉਹ ਇਸਦਾ ਮੁਕਾਬਲਾ ਨਹੀਂ ਕਰ ਸਕੇ।

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

  ਨਿਗਰਾਨੀ. ਸਮੱਸਿਆ ਦੀ ਜਲਦੀ ਪਛਾਣ ਕਿਵੇਂ ਕਰੀਏ?

  ਹੁਣ ਪਹਿਲਾ ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ "ਸਮੱਸਿਆ ਦੀ ਜਲਦੀ ਪਛਾਣ ਕਿਵੇਂ ਕਰੀਏ?" ਨਿਗਰਾਨੀ! ਸਾਨੂੰ ਕੁਝ ਚੀਜ਼ਾਂ ਨੂੰ ਜਲਦੀ ਸਮਝਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਾਨੂੰ ਕਿਹੜੀਆਂ ਗੱਲਾਂ ਜਲਦੀ ਸਮਝ ਲੈਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ?

  
  
  ਤਿੰਨ ਚੀਜ਼ਾਂ!

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

  ਮੈਂ ਸ਼ਾਇਦ ਤੁਹਾਨੂੰ ਇੱਥੇ ਕੁਝ ਵੀ ਨਹੀਂ ਦੱਸਾਂਗਾ ਜੋ ਵਧੀਆ ਹੈ। ਮੈਂ ਕੈਪਟਨ ਸਪੱਸ਼ਟ ਹੋਵਾਂਗਾ। ਅਸੀਂ ਉਸ ਚੀਜ਼ ਦੀ ਭਾਲ ਕੀਤੀ ਜੋ ਮਾਰਕੀਟ ਵਿੱਚ ਸੀ। ਸਾਡੇ ਕੋਲ ਇੱਕ "ਮਜ਼ੇਦਾਰ ਚਿੜੀਆਘਰ" ਹੈ। ਇਹ ਸਾਡੇ ਕੋਲ ਹੁਣ ਚਿੜੀਆਘਰ ਦੀ ਕਿਸਮ ਹੈ:

  
  
  ਅਸੀਂ ਜ਼ੈਬਿਕਸ ਦੀ ਵਰਤੋਂ ਹਾਰਡਵੇਅਰ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ, ਸਰਵਰਾਂ ਦੇ ਮੁੱਖ ਸੂਚਕਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ ਡੇਟਾਬੇਸ ਲਈ ਓਕਮੀਟਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ “Grafana” ਅਤੇ “Prometheus” ਦੀ ਵਰਤੋਂ ਹੋਰ ਸਾਰੇ ਸੂਚਕਾਂ ਲਈ ਕਰਦੇ ਹਾਂ ਜੋ ਪਹਿਲੇ ਦੋ ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦੇ, ਕੁਝ “Grafana” ਅਤੇ “Prometheus” ਨਾਲ, ਅਤੇ ਕੁਝ “Grafana” ਨਾਲ “Influx” ਅਤੇ Telegraf।

  ਇੱਕ ਸਾਲ ਪਹਿਲਾਂ ਅਸੀਂ ਨਿਊ ਰੀਲੀਕ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ। ਵਧੀਆ ਚੀਜ਼, ਇਹ ਸਭ ਕੁਝ ਕਰ ਸਕਦਾ ਹੈ. ਪਰ ਜਿੰਨਾ ਉਹ ਸਭ ਕੁਝ ਕਰ ਸਕਦੀ ਹੈ, ਓਨੀ ਹੀ ਮਹਿੰਗੀ ਹੈ। ਜਦੋਂ ਅਸੀਂ 1,5 ਹਜ਼ਾਰ ਸਰਵਰਾਂ ਦੀ ਮਾਤਰਾ ਵਿੱਚ ਵਾਧਾ ਕੀਤਾ, ਤਾਂ ਇੱਕ ਵਿਕਰੇਤਾ ਸਾਡੇ ਕੋਲ ਆਇਆ ਅਤੇ ਕਿਹਾ: "ਆਓ ਅਗਲੇ ਸਾਲ ਲਈ ਇੱਕ ਸਮਝੌਤਾ ਕਰੀਏ।" ਅਸੀਂ ਕੀਮਤ ਨੂੰ ਦੇਖਿਆ ਅਤੇ ਕਿਹਾ ਕਿ ਨਹੀਂ, ਅਸੀਂ ਅਜਿਹਾ ਨਹੀਂ ਕਰਾਂਗੇ। ਹੁਣ ਅਸੀਂ New Relic ਨੂੰ ਛੱਡ ਰਹੇ ਹਾਂ, ਸਾਡੇ ਕੋਲ New Relic ਦੀ ਨਿਗਰਾਨੀ ਹੇਠ ਲਗਭਗ 15 ਸਰਵਰ ਬਚੇ ਹਨ। ਕੀਮਤ ਬਿਲਕੁਲ ਜੰਗਲੀ ਨਿਕਲੀ.

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

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

  ਨਿਗਰਾਨੀ ਲਈ ਕਿਹੜੇ ਸੂਚਕ ਮਹੱਤਵਪੂਰਨ ਹਨ?

  ਅਸੀਂ ਮੁੱਖ ਤੌਰ 'ਤੇ ਕੀ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹਾਂ? ਸਾਡੇ ਲਈ ਕਿਹੜੇ ਸੂਚਕ ਮਹੱਤਵਪੂਰਨ ਹਨ?

  
  

  • ਮੋਰਚਿਆਂ 'ਤੇ ਜਵਾਬ ਸਮਾਂ / RPS ਇੱਕ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਸੂਚਕ ਹੈ। ਉਹ ਤੁਰੰਤ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਨਾਲ ਕੁਝ ਗਲਤ ਹੈ.
  • ਸਾਰੀਆਂ ਕਤਾਰਾਂ ਵਿੱਚ ਸੰਸਾਧਿਤ ਸੁਨੇਹਿਆਂ ਦੀ ਸੰਖਿਆ।
  • ਵਰਕਰਾਂ ਦੀ ਗਿਣਤੀ।
  • ਮੂਲ ਸ਼ੁੱਧਤਾ ਮਾਪਕ।

  ਆਖਰੀ ਬਿੰਦੂ "ਕਾਰੋਬਾਰ", "ਕਾਰੋਬਾਰ" ਮੈਟ੍ਰਿਕ ਹੈ। ਜੇ ਤੁਸੀਂ ਇੱਕੋ ਚੀਜ਼ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਜਾਂ ਦੋ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਜੋ ਤੁਹਾਡੇ ਲਈ ਮੁੱਖ ਸੂਚਕ ਹਨ। ਸਾਡਾ ਮੈਟ੍ਰਿਕ ਥ੍ਰੁਪੁੱਟ ਹੈ (ਇਹ ਕੁੱਲ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਪ੍ਰਵਾਹ ਦੇ ਸਫਲ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਦੀ ਸੰਖਿਆ ਦਾ ਅਨੁਪਾਤ ਹੈ)। ਜੇ 5-10-15 ਮਿੰਟਾਂ ਦੇ ਅੰਤਰਾਲ 'ਤੇ ਇਸ ਵਿੱਚ ਕੁਝ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਾਨੂੰ ਸਮੱਸਿਆਵਾਂ ਹਨ (ਜੇ ਇਹ ਮੂਲ ਰੂਪ ਵਿੱਚ ਬਦਲਦਾ ਹੈ)।

  ਇਹ ਸਾਡੇ ਲਈ ਕੀ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਸਾਡੇ ਬੋਰਡਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਹੈ:

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

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

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

  ਅਤੇ ਮਾਨੀਟਰਿੰਗ ਗਲਤੀਆਂ ਦੀ ਤੀਜੀ ਸ਼੍ਰੇਣੀ ਜੋ ਮੌਜੂਦ ਹੈ ਉਹ ਹੈ ਲਾਜ਼ੀਕਲ ਨਿਗਰਾਨੀ।

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

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

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

  ਇਹ ਸਮੱਸਿਆ ਨੂੰ ਜਲਦੀ ਪਛਾਣਨ ਦੇ ਤਰੀਕੇ ਬਾਰੇ ਸੀ।

  ਤੈਨਾਤੀ ਦੇ ਕਾਰਨਾਂ ਨੂੰ ਕਿਵੇਂ ਨਿਰਧਾਰਤ ਕਰਨਾ ਹੈ

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

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

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

  ਅਸੀਂ ਇੱਕ ਸਾਲ ਪਹਿਲਾਂ ਇਹ ਸੋਚਿਆ, ਸਾਡਾ ਧਿਆਨ ਮਾਰਕੀਟ ਵੱਲ ਮੋੜਿਆ, ਅਤੇ ਉੱਥੇ ਦੋ ਟੂਲ ਸਨ - “ਜ਼ਿਪਕਿਨ” ਅਤੇ “ਜੇਗਰ”। “ਜਾਗਰ” ਅਸਲ ਵਿੱਚ ਇੱਕ ਅਜਿਹਾ ਵਿਚਾਰਧਾਰਕ ਵਾਰਸ ਹੈ, “ਜ਼ਿਪਕਿਨ” ਦਾ ਇੱਕ ਵਿਚਾਰਧਾਰਕ ਉੱਤਰਾਧਿਕਾਰੀ। ਜ਼ਿਪਕਿਨ ਵਿੱਚ ਸਭ ਕੁਝ ਵਧੀਆ ਹੈ, ਸਿਵਾਏ ਇਸ ਤੋਂ ਇਲਾਵਾ ਕਿ ਇਹ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਕਿਵੇਂ ਇਕੱਠਾ ਕਰਨਾ ਹੈ, ਇਹ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਟਰੇਸ ਵਿੱਚ ਲੌਗਸ ਨੂੰ ਕਿਵੇਂ ਸ਼ਾਮਲ ਕਰਨਾ ਹੈ, ਸਿਰਫ ਸਮਾਂ ਟਰੇਸ. ਅਤੇ "ਜੇਗਰ" ਨੇ ਇਸਦਾ ਸਮਰਥਨ ਕੀਤਾ।

  ਅਸੀਂ “ਜੇਗਰ” ਨੂੰ ਦੇਖਿਆ: ਤੁਸੀਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਇੰਸਟਰੂਮੈਂਟ ਕਰ ਸਕਦੇ ਹੋ, ਤੁਸੀਂ ਐਪੀ ਵਿੱਚ ਲਿਖ ਸਕਦੇ ਹੋ (ਉਸ ਸਮੇਂ PHP ਲਈ ਏਪੀਆਈ ਸਟੈਂਡਰਡ, ਹਾਲਾਂਕਿ, ਮਨਜ਼ੂਰ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ - ਇਹ ਇੱਕ ਸਾਲ ਪਹਿਲਾਂ ਸੀ, ਪਰ ਹੁਣ ਇਹ ਪਹਿਲਾਂ ਹੀ ਮਨਜ਼ੂਰ ਹੋ ਚੁੱਕਾ ਹੈ), ਪਰ ਉੱਥੇ ਬਿਲਕੁਲ ਕੋਈ ਗਾਹਕ ਨਹੀਂ ਸੀ। "ਠੀਕ ਹੈ," ਅਸੀਂ ਸੋਚਿਆ, ਅਤੇ ਸਾਡੇ ਆਪਣੇ ਗਾਹਕ ਨੂੰ ਲਿਖਿਆ। ਸਾਨੂੰ ਕੀ ਮਿਲਿਆ? ਇਹ ਲਗਭਗ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

  
  
  ਜੈਗਰ ਵਿੱਚ, ਹਰੇਕ ਸੰਦੇਸ਼ ਲਈ ਸਪੈਨ ਬਣਾਏ ਗਏ ਹਨ। ਭਾਵ, ਜਦੋਂ ਇੱਕ ਉਪਭੋਗਤਾ ਸਿਸਟਮ ਖੋਲ੍ਹਦਾ ਹੈ, ਉਹ ਹਰੇਕ ਆਉਣ ਵਾਲੀ ਬੇਨਤੀ ਲਈ ਇੱਕ ਜਾਂ ਦੋ ਬਲਾਕ ਵੇਖਦਾ ਹੈ (1-2-3 - ਉਪਭੋਗਤਾ ਤੋਂ ਆਉਣ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ, ਬਲਾਕਾਂ ਦੀ ਗਿਣਤੀ)। ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਇਸਨੂੰ ਆਸਾਨ ਬਣਾਉਣ ਲਈ, ਅਸੀਂ ਲੌਗਸ ਅਤੇ ਟਾਈਮ ਟਰੇਸ ਵਿੱਚ ਟੈਗ ਸ਼ਾਮਲ ਕੀਤੇ ਹਨ। ਇਸ ਅਨੁਸਾਰ, ਇੱਕ ਗਲਤੀ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਲੌਗ ਨੂੰ ਉਚਿਤ ਐਰਰ ਟੈਗ ਨਾਲ ਚਿੰਨ੍ਹਿਤ ਕਰੇਗੀ। ਤੁਸੀਂ ਗਲਤੀ ਟੈਗ ਦੁਆਰਾ ਫਿਲਟਰ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਸਿਰਫ ਉਹ ਸਪੈਨ ਦਿਖਾਈ ਦੇਣਗੇ ਜਿਸ ਵਿੱਚ ਇੱਕ ਗਲਤੀ ਵਾਲਾ ਇਹ ਬਲਾਕ ਸ਼ਾਮਲ ਹੈ। ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਜੇਕਰ ਅਸੀਂ ਮਿਆਦ ਨੂੰ ਵਧਾਉਂਦੇ ਹਾਂ:

  
  
  ਸਪੈਨ ਦੇ ਅੰਦਰ ਟਰੇਸ ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ. ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਇਹ ਤਿੰਨ ਟੈਸਟ ਟਰੇਸ ਹਨ, ਅਤੇ ਤੀਜਾ ਟਰੇਸ ਸਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਇੱਕ ਗਲਤੀ ਆਈ ਹੈ। ਇਸ ਦੇ ਨਾਲ ਹੀ, ਇੱਥੇ ਅਸੀਂ ਇੱਕ ਟਾਈਮ ਟਰੇਸ ਦੇਖਦੇ ਹਾਂ: ਸਾਡੇ ਕੋਲ ਸਿਖਰ 'ਤੇ ਇੱਕ ਸਮਾਂ ਪੈਮਾਨਾ ਹੈ, ਅਤੇ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਇਹ ਜਾਂ ਉਹ ਲੌਗ ਕਿਸ ਸਮੇਂ ਦੇ ਅੰਤਰਾਲ 'ਤੇ ਰਿਕਾਰਡ ਕੀਤਾ ਗਿਆ ਸੀ।

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

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

  ਕਾਰਪੋਰੇਟ ਮਿਆਰ

  ਅਸੀਂ ਤਿੰਨ ਹੁਕਮਾਂ ਬਾਰੇ ਗੱਲ ਕੀਤੀ। ਚੌਥਾ ਹੁਕਮ ਪਹੁੰਚ ਨੂੰ ਮਿਆਰੀ ਬਣਾਉਣਾ ਹੈ। ਇਹ ਕਿਸ ਬਾਰੇ ਹੈ? ਇਹ ਇਸ ਬਾਰੇ ਹੈ:

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

  
  

  • ਸਾਡੇ ਕੋਲ ਤਾਇਨਾਤੀ ਦੇ ਨਿਯਮ ਹਨ। ਅਸੀਂ ਉਸ ਤੋਂ ਬਿਨਾਂ ਕਿਤੇ ਵੀ ਨਹੀਂ ਜਾ ਰਹੇ ਹਾਂ, ਅਸੀਂ ਨਹੀਂ ਕਰ ਸਕਦੇ. ਅਸੀਂ ਹਫ਼ਤੇ ਵਿੱਚ ਲਗਭਗ 60 ਵਾਰ ਤੈਨਾਤ ਕਰਦੇ ਹਾਂ, ਯਾਨੀ ਅਸੀਂ ਲਗਭਗ ਲਗਾਤਾਰ ਤੈਨਾਤ ਕਰਦੇ ਹਾਂ। ਇਸਦੇ ਨਾਲ ਹੀ, ਸਾਡੇ ਕੋਲ, ਉਦਾਹਰਨ ਲਈ, ਤੈਨਾਤੀ ਨਿਯਮਾਂ ਵਿੱਚ ਸ਼ੁੱਕਰਵਾਰ ਨੂੰ ਤੈਨਾਤੀਆਂ 'ਤੇ ਪਾਬੰਦੀ ਹੈ - ਸਿਧਾਂਤ ਵਿੱਚ, ਅਸੀਂ ਤੈਨਾਤ ਨਹੀਂ ਕਰਦੇ ਹਾਂ।
  • ਸਾਨੂੰ ਦਸਤਾਵੇਜ਼ ਦੀ ਲੋੜ ਹੈ. ਇੱਕ ਵੀ ਨਵਾਂ ਭਾਗ ਉਤਪਾਦਨ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦਾ ਜੇਕਰ ਇਸਦੇ ਲਈ ਕੋਈ ਦਸਤਾਵੇਜ਼ ਨਹੀਂ ਹਨ, ਭਾਵੇਂ ਇਹ ਸਾਡੇ RnD ਮਾਹਰਾਂ ਦੀ ਕਲਮ ਹੇਠ ਪੈਦਾ ਹੋਇਆ ਹੋਵੇ। ਸਾਨੂੰ ਉਹਨਾਂ ਤੋਂ ਤੈਨਾਤੀ ਨਿਰਦੇਸ਼ਾਂ, ਇੱਕ ਨਿਗਰਾਨੀ ਨਕਸ਼ੇ ਅਤੇ ਇੱਕ ਮੋਟਾ ਵੇਰਵਾ (ਜਿਵੇਂ ਕਿ ਪ੍ਰੋਗਰਾਮਰ ਲਿਖ ਸਕਦੇ ਹਨ) ਦੀ ਲੋੜ ਹੈ ਕਿ ਇਹ ਕੰਪੋਨੈਂਟ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਸ ਨੂੰ ਕਿਵੇਂ ਹੱਲ ਕਰਨਾ ਹੈ।
  • ਅਸੀਂ ਸਮੱਸਿਆ ਦਾ ਕਾਰਨ ਨਹੀਂ, ਬਲਕਿ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕਰਦੇ ਹਾਂ - ਜੋ ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਕਿਹਾ ਹੈ. ਉਪਭੋਗਤਾ ਨੂੰ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਬਚਾਉਣਾ ਸਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ।
  • ਸਾਡੇ ਕੋਲ ਮਨਜ਼ੂਰੀਆਂ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਇਸਨੂੰ ਡਾਊਨਟਾਈਮ ਨਹੀਂ ਮੰਨਦੇ ਹਾਂ ਜੇਕਰ ਅਸੀਂ ਦੋ ਮਿੰਟਾਂ ਦੇ ਅੰਦਰ 2% ਟ੍ਰੈਫਿਕ ਗੁਆ ਦਿੰਦੇ ਹਾਂ. ਇਹ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸਾਡੇ ਅੰਕੜਿਆਂ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਹੈ। ਜੇਕਰ ਇਹ ਪ੍ਰਤੀਸ਼ਤ ਦੇ ਰੂਪ ਵਿੱਚ ਵੱਧ ਹੈ ਜਾਂ ਅਸਥਾਈ ਹੈ, ਤਾਂ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਗਿਣਦੇ ਹਾਂ।
  • ਅਤੇ ਅਸੀਂ ਹਮੇਸ਼ਾ ਪੋਸਟਮਾਰਟਮ ਲਿਖਦੇ ਹਾਂ। ਸਾਡੇ ਨਾਲ ਜੋ ਵੀ ਵਾਪਰਦਾ ਹੈ, ਕੋਈ ਵੀ ਸਥਿਤੀ ਜਿੱਥੇ ਕਿਸੇ ਨੇ ਉਤਪਾਦਨ ਵਿੱਚ ਅਸਧਾਰਨ ਵਿਵਹਾਰ ਕੀਤਾ ਹੈ, ਪੋਸਟਮਾਰਟਮ ਵਿੱਚ ਪ੍ਰਤੀਬਿੰਬਿਤ ਹੋਵੇਗਾ। ਪੋਸਟਮਾਰਟਮ ਇੱਕ ਦਸਤਾਵੇਜ਼ ਹੈ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਲਿਖਦੇ ਹੋ ਕਿ ਤੁਹਾਡੇ ਨਾਲ ਕੀ ਹੋਇਆ, ਇੱਕ ਵਿਸਤ੍ਰਿਤ ਸਮਾਂ, ਤੁਸੀਂ ਇਸਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਕੀ ਕੀਤਾ ਅਤੇ (ਇਹ ਇੱਕ ਲਾਜ਼ਮੀ ਬਲਾਕ ਹੈ!) ਤੁਸੀਂ ਭਵਿੱਖ ਵਿੱਚ ਅਜਿਹਾ ਹੋਣ ਤੋਂ ਰੋਕਣ ਲਈ ਕੀ ਕਰੋਗੇ। ਇਹ ਲਾਜ਼ਮੀ ਹੈ ਅਤੇ ਬਾਅਦ ਦੇ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਜ਼ਰੂਰੀ ਹੈ।

  ਡਾਊਨਟਾਈਮ ਕੀ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ?

  
  
  ਇਹ ਸਭ ਕਿਸ ਕਾਰਨ ਹੋਇਆ?

  ਇਹ ਇਸ ਤੱਥ ਵੱਲ ਅਗਵਾਈ ਕਰਦਾ ਹੈ ਕਿ (ਸਾਨੂੰ ਸਥਿਰਤਾ ਨਾਲ ਕੁਝ ਸਮੱਸਿਆਵਾਂ ਸਨ, ਇਹ ਨਾ ਤਾਂ ਗਾਹਕਾਂ ਜਾਂ ਸਾਡੇ ਲਈ ਅਨੁਕੂਲ ਨਹੀਂ ਸੀ) ਪਿਛਲੇ 6 ਮਹੀਨਿਆਂ ਵਿੱਚ ਸਾਡਾ ਸਥਿਰਤਾ ਸੂਚਕ 99,97 ਸੀ। ਅਸੀਂ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ ਇਹ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਹੀਂ ਹੈ. ਹਾਂ, ਸਾਡੇ ਕੋਲ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਲਈ ਕੁਝ ਹੈ। ਇਸ ਸੂਚਕ ਵਿੱਚੋਂ, ਲਗਭਗ ਅੱਧਾ ਸਥਿਰਤਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਇਹ ਸਾਡੀ ਨਹੀਂ, ਪਰ ਸਾਡੀ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ ਫਾਇਰਵਾਲ ਦੀ ਹੈ, ਜੋ ਸਾਡੇ ਸਾਹਮਣੇ ਖੜ੍ਹੀ ਹੈ ਅਤੇ ਇੱਕ ਸੇਵਾ ਵਜੋਂ ਵਰਤੀ ਜਾਂਦੀ ਹੈ, ਪਰ ਗਾਹਕ ਇਸ ਦੀ ਪਰਵਾਹ ਨਹੀਂ ਕਰਦੇ।

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

  ਇਹ ਸਭ ਹੈ! ਤੁਹਾਡੇ ਸਵਾਲ।

  
  

  ਬੈਲੇਂਸਰਾਂ ਅਤੇ ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ ਬਾਰੇ

  ਸਰੋਤਿਆਂ ਤੋਂ ਸਵਾਲ (ਇਸ ਤੋਂ ਬਾਅਦ - ਬੀ): - ਸ਼ੁਭ ਸ਼ਾਮ। ਅਜਿਹੀ ਐਡਮਿਨ ਰਿਪੋਰਟ ਲਈ ਤੁਹਾਡਾ ਬਹੁਤ ਬਹੁਤ ਧੰਨਵਾਦ! ਤੁਹਾਡੇ ਬੈਲੇਂਸਰਾਂ ਬਾਰੇ ਇੱਕ ਛੋਟਾ ਸਵਾਲ। ਤੁਸੀਂ ਜ਼ਿਕਰ ਕੀਤਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ WAF ਹੈ, ਭਾਵ, ਜਿਵੇਂ ਕਿ ਮੈਂ ਇਸਨੂੰ ਸਮਝਦਾ ਹਾਂ, ਤੁਸੀਂ ਕਿਸੇ ਕਿਸਮ ਦੇ ਬਾਹਰੀ ਸੰਤੁਲਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ...

  EK: - ਨਹੀਂ, ਅਸੀਂ ਆਪਣੀਆਂ ਸੇਵਾਵਾਂ ਨੂੰ ਬੈਲੇਂਸ ਵਜੋਂ ਵਰਤਦੇ ਹਾਂ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, WAF ਸਿਰਫ਼ ਸਾਡੇ ਲਈ ਇੱਕ DDoS ਸੁਰੱਖਿਆ ਸਾਧਨ ਹੈ।

  ਏ ਟੀ: - ਕੀ ਤੁਸੀਂ ਬੈਲੇਂਸਰਾਂ ਬਾਰੇ ਕੁਝ ਸ਼ਬਦ ਕਹਿ ਸਕਦੇ ਹੋ?

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

  ਏ ਟੀ: - ਇੱਕ ਸਧਾਰਨ ਸਵਾਲ ਵੀ. ਇੱਥੇ ਨੀਲਾ/ਹਰਾ ਤੈਨਾਤੀ ਹੈ। ਤੁਸੀਂ ਕੀ ਕਰਦੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ, ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨਾਲ?

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

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

  ਏ ਟੀ: - ਸਤ ਸ੍ਰੀ ਅਕਾਲ. ਰਿਪੋਰਟ ਲਈ ਧੰਨਵਾਦ। ਸਵਾਲ ਇਹ ਹੈ। ਤੁਸੀਂ ਭੁਗਤਾਨਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਉਹਨਾਂ ਸੇਵਾਵਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹੋ ਜਿਨ੍ਹਾਂ ਨਾਲ ਤੁਸੀਂ ਸੰਚਾਰ ਕਰਦੇ ਹੋ... ਪਰ ਤੁਸੀਂ ਕਿਵੇਂ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹੋ ਕਿ ਕੋਈ ਵਿਅਕਤੀ ਕਿਸੇ ਤਰ੍ਹਾਂ ਤੁਹਾਡੇ ਭੁਗਤਾਨ ਪੰਨੇ 'ਤੇ ਆਇਆ, ਭੁਗਤਾਨ ਕੀਤਾ, ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਨੇ ਉਸਨੂੰ ਪੈਸੇ ਦੇ ਕੇ ਕ੍ਰੈਡਿਟ ਕੀਤਾ? ਭਾਵ, ਤੁਸੀਂ ਕਿਵੇਂ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹੋ ਕਿ ਮਾਰਚੈਂਟ ਉਪਲਬਧ ਹੈ ਅਤੇ ਉਸ ਨੇ ਤੁਹਾਡੀ ਕਾਲਬੈਕ ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਲਿਆ ਹੈ?

  EK: - ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਸਾਡੇ ਲਈ “ਵਪਾਰੀ” ਭੁਗਤਾਨ ਪ੍ਰਣਾਲੀ ਦੇ ਰੂਪ ਵਿੱਚ ਬਿਲਕੁਲ ਉਹੀ ਬਾਹਰੀ ਸੇਵਾ ਹੈ। ਅਸੀਂ ਵਪਾਰੀ ਦੇ ਜਵਾਬ ਦੀ ਗਤੀ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹਾਂ।

  ਡਾਟਾਬੇਸ ਇਨਕ੍ਰਿਪਸ਼ਨ ਬਾਰੇ

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

  
  
  EK: - ਸ਼ਾਨਦਾਰ ਸਵਾਲ! ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਕਤਾਰਾਂ ਵਿੱਚ ਪੈਨ ਸਟੋਰ ਨਹੀਂ ਕਰਦੇ ਹਾਂ। ਸਾਡੇ ਕੋਲ ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ, ਸਪੱਸ਼ਟ ਰੂਪ ਵਿੱਚ ਕਿਤੇ ਵੀ ਪੈਨ ਨੂੰ ਸਟੋਰ ਕਰਨ ਦਾ ਅਧਿਕਾਰ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਅਸੀਂ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ (ਅਸੀਂ ਇਸਨੂੰ "ਕੇਡੇਮੋਨ" ਕਹਿੰਦੇ ਹਾਂ) - ਇਹ ਇੱਕ ਅਜਿਹੀ ਸੇਵਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਇੱਕ ਕੰਮ ਕਰਦੀ ਹੈ: ਇਹ ਇੱਕ ਸੁਨੇਹਾ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ ਅਤੇ ਭੇਜਦੀ ਹੈ। ਇੱਕ ਇਨਕ੍ਰਿਪਟਡ ਸੁਨੇਹਾ ਬਾਹਰ. ਅਤੇ ਅਸੀਂ ਇਸ ਐਨਕ੍ਰਿਪਟਡ ਸੰਦੇਸ਼ ਨਾਲ ਹਰ ਚੀਜ਼ ਨੂੰ ਸਟੋਰ ਕਰਦੇ ਹਾਂ। ਇਸ ਅਨੁਸਾਰ, ਸਾਡੀ ਕੁੰਜੀ ਦੀ ਲੰਬਾਈ ਇੱਕ ਕਿਲੋਬਾਈਟ ਦੇ ਹੇਠਾਂ ਹੈ, ਤਾਂ ਜੋ ਇਹ ਗੰਭੀਰ ਅਤੇ ਭਰੋਸੇਮੰਦ ਹੋਵੇ।

  ਏ ਟੀ: - ਕੀ ਤੁਹਾਨੂੰ ਹੁਣ 2 ਕਿਲੋਬਾਈਟ ਦੀ ਲੋੜ ਹੈ?

  EK: - ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਜਿਵੇਂ ਕੱਲ੍ਹ ਇਹ 256 ਸੀ... ਖੈਰ, ਹੋਰ ਕਿੱਥੇ?!

  ਇਸ ਅਨੁਸਾਰ, ਇਹ ਪਹਿਲਾ ਹੈ. ਅਤੇ ਦੂਜਾ, ਜੋ ਹੱਲ ਮੌਜੂਦ ਹੈ, ਇਹ ਰੀ-ਏਨਕ੍ਰਿਪਸ਼ਨ ਪ੍ਰਕਿਰਿਆ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ - ਇੱਥੇ "ਕੇਕ" (ਕੁੰਜੀਆਂ) ਦੇ ਦੋ ਜੋੜੇ ਹਨ, ਜੋ "ਡੈੱਕ" ਦਿੰਦੇ ਹਨ ਜੋ ਐਨਕ੍ਰਿਪਟ ਕਰਦੇ ਹਨ (ਕੁੰਜੀਆਂ ਕੁੰਜੀਆਂ ਹਨ, ਡੀਕ ਉਹਨਾਂ ਕੁੰਜੀਆਂ ਦੇ ਡੈਰੀਵੇਟਿਵ ਹਨ ਜੋ ਐਨਕ੍ਰਿਪਟ ਕਰਦੇ ਹਨ) . ਅਤੇ ਜੇਕਰ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ (ਇਹ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਹੁੰਦਾ ਹੈ, 3 ਮਹੀਨਿਆਂ ਤੋਂ ± ਕੁਝ ਤੱਕ), ਅਸੀਂ "ਕੇਕ" ਦੀ ਇੱਕ ਨਵੀਂ ਜੋੜੀ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਅਸੀਂ ਡੇਟਾ ਨੂੰ ਮੁੜ-ਇਨਕ੍ਰਿਪਟ ਕਰਦੇ ਹਾਂ। ਸਾਡੇ ਕੋਲ ਵੱਖਰੀਆਂ ਸੇਵਾਵਾਂ ਹਨ ਜੋ ਸਾਰੇ ਡੇਟਾ ਨੂੰ ਬਾਹਰ ਕੱਢਦੀਆਂ ਹਨ ਅਤੇ ਇਸਨੂੰ ਨਵੇਂ ਤਰੀਕੇ ਨਾਲ ਐਨਕ੍ਰਿਪਟ ਕਰਦੀਆਂ ਹਨ; ਡੇਟਾ ਨੂੰ ਉਸ ਕੁੰਜੀ ਦੇ ਪਛਾਣਕਰਤਾ ਦੇ ਅੱਗੇ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਿਸ ਨਾਲ ਇਸਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਸ ਅਨੁਸਾਰ, ਜਿਵੇਂ ਹੀ ਅਸੀਂ ਨਵੀਆਂ ਕੁੰਜੀਆਂ ਨਾਲ ਡੇਟਾ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕਰਦੇ ਹਾਂ, ਅਸੀਂ ਪੁਰਾਣੀ ਕੁੰਜੀ ਨੂੰ ਮਿਟਾ ਦਿੰਦੇ ਹਾਂ।

  ਕਈ ਵਾਰ ਭੁਗਤਾਨ ਹੱਥੀਂ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ...

  ਏ ਟੀ: - ਭਾਵ, ਜੇਕਰ ਕਿਸੇ ਕਾਰਵਾਈ ਲਈ ਰਿਫੰਡ ਆ ਗਿਆ ਹੈ, ਤਾਂ ਕੀ ਤੁਸੀਂ ਇਸਨੂੰ ਪੁਰਾਣੀ ਕੁੰਜੀ ਨਾਲ ਡੀਕ੍ਰਿਪਟ ਕਰੋਗੇ?

  EK: - ਹਾਂ।

  ਏ ਟੀ: - ਫਿਰ ਇੱਕ ਹੋਰ ਛੋਟਾ ਸਵਾਲ. ਜਦੋਂ ਕਿਸੇ ਕਿਸਮ ਦੀ ਅਸਫਲਤਾ, ਗਿਰਾਵਟ ਜਾਂ ਘਟਨਾ ਵਾਪਰਦੀ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਹੱਥੀਂ ਲੈਣ-ਦੇਣ ਨੂੰ ਅੱਗੇ ਵਧਾਉਣਾ ਜ਼ਰੂਰੀ ਹੁੰਦਾ ਹੈ। ਅਜਿਹੀ ਸਥਿਤੀ ਹੈ।

  EK: - ਹਾਂ, ਕਈ ਵਾਰ।

  ਏ ਟੀ: - ਤੁਸੀਂ ਇਹ ਡੇਟਾ ਕਿੱਥੋਂ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ? ਜਾਂ ਕੀ ਤੁਸੀਂ ਖੁਦ ਇਸ ਸਟੋਰੇਜ ਸਹੂਲਤ 'ਤੇ ਜਾਂਦੇ ਹੋ?

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

  
  
  ਏ ਟੀ: - ਮੇਰੇ ਕੋਲ ਕੁਝ ਸਵਾਲ ਹਨ। ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ PCI DSS ਜ਼ੋਨ ਦੀ ਨਿਰੰਤਰਤਾ ਹੈ: ਤੁਸੀਂ ਉਹਨਾਂ ਦੇ ਸਰਕਟ ਨੂੰ ਕਿਵੇਂ ਲੌਗ ਕਰਦੇ ਹੋ? ਇਹ ਸਵਾਲ ਹੈ ਕਿਉਂਕਿ ਡਿਵੈਲਪਰ ਲੌਗਸ ਵਿੱਚ ਕੁਝ ਵੀ ਪਾ ਸਕਦਾ ਸੀ! ਦੂਜਾ ਸਵਾਲ: ਤੁਸੀਂ ਹੌਟਫਿਕਸ ਨੂੰ ਕਿਵੇਂ ਰੋਲ ਆਊਟ ਕਰਦੇ ਹੋ? ਡੇਟਾਬੇਸ ਵਿੱਚ ਹੈਂਡਲ ਇੱਕ ਵਿਕਲਪ ਹੈ, ਪਰ ਇੱਥੇ ਮੁਫਤ ਹਾਟ-ਫਿਕਸ ਹੋ ਸਕਦੇ ਹਨ - ਉੱਥੇ ਪ੍ਰਕਿਰਿਆ ਕੀ ਹੈ? ਅਤੇ ਤੀਜਾ ਸਵਾਲ ਸ਼ਾਇਦ RTO, RPO ਨਾਲ ਸਬੰਧਤ ਹੈ। ਤੁਹਾਡੀ ਉਪਲਬਧਤਾ 99,97 ਸੀ, ਲਗਭਗ ਚਾਰ ਨੌ, ਪਰ ਜਿਵੇਂ ਕਿ ਮੈਂ ਇਸਨੂੰ ਸਮਝਦਾ ਹਾਂ, ਤੁਹਾਡੇ ਕੋਲ ਦੂਜਾ ਡੇਟਾ ਸੈਂਟਰ, ਤੀਜਾ ਡੇਟਾ ਸੈਂਟਰ, ਅਤੇ ਪੰਜਵਾਂ ਡੇਟਾ ਸੈਂਟਰ ਹੈ... ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ ਕਰਦੇ ਹੋ, ਉਹਨਾਂ ਨੂੰ ਦੁਹਰਾਉਂਦੇ ਹੋ, ਅਤੇ ਹੋਰ ਸਭ ਕੁਝ?

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

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

  ਏ ਟੀ: - ਜੇ ਤੁਹਾਨੂੰ ਦੂਜਾ ਮਿਲਿਆ, ਤਾਂ ਤੁਹਾਨੂੰ ਤੀਜਾ ਕਿਉਂ ਨਹੀਂ ਮਿਲਿਆ? ਕਿਉਂਕਿ ਅਜੇ ਤੱਕ ਕਿਸੇ ਦਾ ਦਿਮਾਗ ਨਹੀਂ ਟੁੱਟਿਆ...

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

  ਏ ਟੀ: - ਸਤ ਸ੍ਰੀ ਅਕਾਲ. ਰਿਪੋਰਟ ਲਈ ਧੰਨਵਾਦ। ਤੁਸੀਂ ਆਪਣੇ ਡੀਬਗਰ ਬਾਰੇ ਗੱਲ ਕੀਤੀ, ਜੋ ਉਤਪਾਦਨ ਵਿੱਚ ਕੁਝ ਟੈਸਟ ਲੈਣ-ਦੇਣ ਚਲਾਉਂਦਾ ਹੈ। ਪਰ ਸਾਨੂੰ ਟੈਸਟ ਲੈਣ-ਦੇਣ ਬਾਰੇ ਦੱਸੋ! ਇਹ ਕਿੰਨੀ ਡੂੰਘਾਈ ਵਿੱਚ ਜਾਂਦਾ ਹੈ?

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

  ਏ ਟੀ: -ਤੁਸੀਂ ਇਸ ਨੂੰ ਕਿੱਥੇ ਕੱਟਦੇ ਹੋ? ਇੱਥੇ ਕੋਰ ਭੇਜਿਆ ਗਿਆ ...

  EK: - ਅਸੀਂ ਟੈਸਟ ਲੈਣ-ਦੇਣ ਲਈ ਇਸ ਮਾਮਲੇ ਵਿੱਚ "ਕੋਰ" ਦੇ ਪਿੱਛੇ ਹਾਂ... ਸਾਡੇ ਕੋਲ ਰੂਟਿੰਗ ਵਰਗੀ ਚੀਜ਼ ਹੈ: "ਕੋਰ" ਜਾਣਦਾ ਹੈ ਕਿ ਕਿਸ ਭੁਗਤਾਨ ਪ੍ਰਣਾਲੀ ਨੂੰ ਭੇਜਣਾ ਹੈ - ਅਸੀਂ ਇੱਕ ਜਾਅਲੀ ਭੁਗਤਾਨ ਪ੍ਰਣਾਲੀ ਨੂੰ ਭੇਜਦੇ ਹਾਂ, ਜੋ ਸਿਰਫ਼ ਇੱਕ HTTP ਸਿਗਨਲ ਦਿੰਦਾ ਹੈ ਅਤੇ ਇਹ ਸਭ ਹੈ.

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

  EK: - ਸਾਡੇ ਕੋਲ ਇੱਕ ਮੋਨੋਲਿਥ ਨਹੀਂ ਹੈ, ਬੇਸ਼ਕ, ਸਾਡੇ ਕੋਲ ਇੱਕ ਸੇਵਾ-ਅਧਾਰਿਤ ਐਪਲੀਕੇਸ਼ਨ ਹੈ। ਅਸੀਂ ਮਜ਼ਾਕ ਕਰਦੇ ਹਾਂ ਕਿ ਸਾਡੀ ਸੇਵਾ ਮੋਨੋਲੀਥਾਂ ਦੀ ਬਣੀ ਹੋਈ ਹੈ - ਉਹ ਅਸਲ ਵਿੱਚ ਕਾਫ਼ੀ ਵੱਡੇ ਹਨ. ਇਸ ਨੂੰ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਕਹਿਣਾ ਔਖਾ ਹੈ, ਪਰ ਇਹ ਉਹ ਸੇਵਾਵਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਦੇ ਅੰਦਰ ਵੰਡੀਆਂ ਮਸ਼ੀਨਾਂ ਦੇ ਵਰਕਰ ਕੰਮ ਕਰਦੇ ਹਨ।

  ਜੇਕਰ ਸਰਵਰ 'ਤੇ ਸੇਵਾ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤਾ ਗਿਆ ਹੈ...

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

  
  
  EK: - ਹਾਂ, ਜ਼ਰੂਰ। ਸੁਰੱਖਿਆ ਲੋੜਾਂ ਕਾਫ਼ੀ ਗੰਭੀਰ ਹਨ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਸਾਡੇ ਕੋਲ ਖੁੱਲੇ ਡੇਟਾ ਅੰਦੋਲਨ ਹਨ, ਅਤੇ ਪੋਰਟ ਕੇਵਲ ਉਹ ਹਨ ਜਿਨ੍ਹਾਂ ਦੁਆਰਾ ਅਸੀਂ ਪਹਿਲਾਂ ਤੋਂ ਟ੍ਰੈਫਿਕ ਦੀ ਆਵਾਜਾਈ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਾਂ. ਜੇਕਰ ਕੋਈ ਕੰਪੋਨੈਂਟ 5-4-3-2 ਰਾਹੀਂ ਡੇਟਾਬੇਸ (ਮਸਕੂਲ ਨਾਲ ਕਹੋ) ਨਾਲ ਸੰਚਾਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਸਿਰਫ਼ 5-4-3-2 ਇਸ ਲਈ ਖੁੱਲ੍ਹਾ ਹੋਵੇਗਾ, ਅਤੇ ਹੋਰ ਪੋਰਟਾਂ ਅਤੇ ਹੋਰ ਆਵਾਜਾਈ ਦਿਸ਼ਾਵਾਂ ਉਪਲਬਧ ਨਹੀਂ ਹੋਣਗੀਆਂ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਤੁਹਾਨੂੰ ਇਹ ਸਮਝਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਸਾਡੇ ਉਤਪਾਦਨ ਵਿੱਚ ਲਗਭਗ 10 ਵੱਖ-ਵੱਖ ਸੁਰੱਖਿਆ ਲੂਪਸ ਹਨ. ਅਤੇ ਭਾਵੇਂ ਐਪਲੀਕੇਸ਼ਨ ਨਾਲ ਕਿਸੇ ਤਰ੍ਹਾਂ ਸਮਝੌਤਾ ਕੀਤਾ ਗਿਆ ਸੀ, ਰੱਬ ਨਾ ਕਰੇ, ਹਮਲਾਵਰ ਸਰਵਰ ਪ੍ਰਬੰਧਨ ਕੰਸੋਲ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵੇਗਾ, ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਵੱਖਰਾ ਨੈੱਟਵਰਕ ਸੁਰੱਖਿਆ ਜ਼ੋਨ ਹੈ।

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

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

  ਵੀਜ਼ਾ, ਮਾਸਟਰਕਾਰਡ ਅਤੇ ਸਬਰਬੈਂਕ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ

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

  EK: - ਇਹ ਮਿਸ਼ਰਣ ਤੋਂ ਪਹਿਲਾਂ ਹੈ. ਸਾਡੇ ਮਿਸ਼ਰਣ ਇੱਕੋ ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ ਸਥਿਤ ਹਨ।

  ਏ ਟੀ: - ਮੋਟੇ ਤੌਰ 'ਤੇ, ਕੀ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਕੁਨੈਕਸ਼ਨ ਪੁਆਇੰਟ ਹੈ?

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

  ਏ ਟੀ: - ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਰਾਖਵਾਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ? ਮੈਂ ਜਾਣਦਾ ਹਾਂ ਕਿ ਵੀਜ਼ਾ ਸਿਧਾਂਤ ਵਿੱਚ ਸਿਰਫ ਇੱਕ ਕੁਨੈਕਸ਼ਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ!

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

  ਏ ਟੀ: - ਤਾਂ ਸਟੈਂਡ ਉਹਨਾਂ ਦੇ ਕਨੈਕਟਸ ਔਰੇਂਜ ਦਾ ਹੈ? ..

  EK: - ਹਾਂ।

  ਏ ਟੀ: - ਪਰ ਇਸ ਕੇਸ ਬਾਰੇ ਕੀ: ਜੇਕਰ ਤੁਹਾਡਾ ਡੇਟਾ ਸੈਂਟਰ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਵਰਤਣਾ ਜਾਰੀ ਰੱਖ ਸਕਦੇ ਹੋ? ਜਾਂ ਕੀ ਟ੍ਰੈਫਿਕ ਸਿਰਫ ਰੁਕਦਾ ਹੈ?

  EK: - ਨਹੀਂ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਅਸੀਂ ਟ੍ਰੈਫਿਕ ਨੂੰ ਕਿਸੇ ਹੋਰ ਚੈਨਲ ਵਿੱਚ ਬਦਲ ਦੇਵਾਂਗੇ, ਜੋ ਕਿ, ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਸਾਡੇ ਲਈ ਵਧੇਰੇ ਮਹਿੰਗਾ ਹੋਵੇਗਾ ਅਤੇ ਸਾਡੇ ਗਾਹਕਾਂ ਲਈ ਵਧੇਰੇ ਮਹਿੰਗਾ ਹੋਵੇਗਾ। ਪਰ ਟ੍ਰੈਫਿਕ ਵੀਜ਼ਾ, ਮਾਸਟਰਕਾਰਡ ਨਾਲ ਸਾਡੇ ਸਿੱਧੇ ਕਨੈਕਸ਼ਨ ਰਾਹੀਂ ਨਹੀਂ ਜਾਵੇਗਾ, ਪਰ ਸ਼ਰਤੀਆ Sberbank (ਬਹੁਤ ਹੀ ਅਤਿਕਥਨੀ) ਦੁਆਰਾ।

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

  
  
  

  ਕੁਝ ਵਿਗਿਆਪਨ 🙂

  ਸਾਡੇ ਨਾਲ ਰਹਿਣ ਲਈ ਤੁਹਾਡਾ ਧੰਨਵਾਦ। ਕੀ ਤੁਹਾਨੂੰ ਸਾਡੇ ਲੇਖ ਪਸੰਦ ਹਨ? ਹੋਰ ਦਿਲਚਸਪ ਸਮੱਗਰੀ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ? ਆਰਡਰ ਦੇ ਕੇ ਜਾਂ ਦੋਸਤਾਂ ਨੂੰ ਸਿਫਾਰਸ਼ ਕਰਕੇ ਸਾਡਾ ਸਮਰਥਨ ਕਰੋ, $4.99 ਤੋਂ ਡਿਵੈਲਪਰਾਂ ਲਈ ਕਲਾਉਡ VPS, ਪ੍ਰਵੇਸ਼-ਪੱਧਰ ਦੇ ਸਰਵਰਾਂ ਦਾ ਇੱਕ ਵਿਲੱਖਣ ਐਨਾਲਾਗ, ਜਿਸਦੀ ਖੋਜ ਸਾਡੇ ਦੁਆਰਾ ਤੁਹਾਡੇ ਲਈ ਕੀਤੀ ਗਈ ਸੀ: VPS (KVM) E5-2697 v3 (6 ਕੋਰ) 10GB DDR4 480GB SSD 1Gbps ਤੋਂ $19 ਜਾਂ ਸਰਵਰ ਨੂੰ ਕਿਵੇਂ ਸਾਂਝਾ ਕਰਨਾ ਹੈ ਬਾਰੇ ਪੂਰੀ ਸੱਚਾਈ? (RAID1 ਅਤੇ RAID10 ਦੇ ਨਾਲ ਉਪਲਬਧ, 24 ਕੋਰ ਤੱਕ ਅਤੇ 40GB DDR4 ਤੱਕ)।

  ਡੈਲ R730xd ਐਮਸਟਰਡਮ ਵਿੱਚ ਈਕੁਇਨਿਕਸ ਟੀਅਰ IV ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ 2 ਗੁਣਾ ਸਸਤਾ? ਇੱਥੇ ਹੀ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ਟੀਵੀ $199 ਤੋਂ ਨੀਦਰਲੈਂਡ ਵਿੱਚ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 ਤੋਂ! ਬਾਰੇ ਪੜ੍ਹੋ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਕਾਰਪੋਰੇਸ਼ਨ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾਵੇ ਡੇਲ R730xd E5-2650 v4 ਸਰਵਰਾਂ ਦੀ ਵਰਤੋਂ ਨਾਲ ਕਲਾਸ 9000 ਯੂਰੋ ਦੀ ਕੀਮਤ ਦੇ ਇੱਕ ਪੈਸੇ ਲਈ?

ਸਰੋਤ: www.habr.com