ਬਿਟ੍ਰਿਕਸ 24: "ਜੋ ਜਲਦੀ ਉਭਾਰਿਆ ਜਾਂਦਾ ਹੈ ਉਸਨੂੰ ਡਿੱਗਿਆ ਨਹੀਂ ਮੰਨਿਆ ਜਾਂਦਾ"

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

“ਅਸੀਂ 24 ਸਾਲ ਪਹਿਲਾਂ Bitrix7 ਨੂੰ SaaS ਵਜੋਂ ਲਾਂਚ ਕੀਤਾ ਸੀ। ਮੁੱਖ ਮੁਸ਼ਕਲ ਸ਼ਾਇਦ ਹੇਠਾਂ ਦਿੱਤੀ ਗਈ ਸੀ: ਸਾਸ ਦੇ ਰੂਪ ਵਿੱਚ ਜਨਤਕ ਤੌਰ 'ਤੇ ਲਾਂਚ ਕੀਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਉਤਪਾਦ ਬਸ ਇੱਕ ਡੱਬੇ ਵਾਲੇ ਹੱਲ ਦੇ ਰੂਪ ਵਿੱਚ ਮੌਜੂਦ ਸੀ। ਗਾਹਕਾਂ ਨੇ ਇਸਨੂੰ ਸਾਡੇ ਤੋਂ ਖਰੀਦਿਆ, ਇਸਨੂੰ ਆਪਣੇ ਸਰਵਰਾਂ 'ਤੇ ਹੋਸਟ ਕੀਤਾ, ਇੱਕ ਕਾਰਪੋਰੇਟ ਪੋਰਟਲ ਸਥਾਪਤ ਕੀਤਾ - ਕਰਮਚਾਰੀ ਸੰਚਾਰ, ਫਾਈਲ ਸਟੋਰੇਜ, ਟਾਸਕ ਮੈਨੇਜਮੈਂਟ, CRM ਲਈ ਇੱਕ ਆਮ ਹੱਲ, ਬਸ ਇੰਨਾ ਹੀ ਹੈ। ਅਤੇ 2012 ਤੱਕ, ਅਸੀਂ ਫੈਸਲਾ ਕੀਤਾ ਕਿ ਅਸੀਂ ਇਸਨੂੰ SaaS ਦੇ ਤੌਰ 'ਤੇ ਲਾਂਚ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਇਸਦਾ ਪ੍ਰਬੰਧਨ ਖੁਦ ਕਰਨਾ, ਗਲਤੀ ਸਹਿਣਸ਼ੀਲਤਾ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ। ਅਸੀਂ ਰਸਤੇ ਵਿੱਚ ਅਨੁਭਵ ਪ੍ਰਾਪਤ ਕੀਤਾ, ਕਿਉਂਕਿ ਉਦੋਂ ਤੱਕ ਸਾਡੇ ਕੋਲ ਇਹ ਨਹੀਂ ਸੀ - ਅਸੀਂ ਸਿਰਫ਼ ਸੌਫਟਵੇਅਰ ਨਿਰਮਾਤਾ ਸੀ, ਸੇਵਾ ਪ੍ਰਦਾਤਾ ਨਹੀਂ।

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

ਬਿਟ੍ਰਿਕਸ.24 SaaS

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

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

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

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

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

ਜੋ ਉਹ ਚਾਹੁੰਦੇ ਸਨ, ਉਹੀ ਮਿਲ ਗਿਆ...

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

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

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

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

ਕੀ ਅਸੀਂ ਸਭ ਕੁਝ ਰਾਖਵਾਂ ਕਰ ਲਿਆ ਹੈ?

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

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

ਦੂਜਾ "ਪਰ": ਇਸ ਤਸਵੀਰ ਵਿੱਚ ਅਜੇ ਤੱਕ ਕੀ ਰਾਖਵਾਂ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ? ਸੰਤੁਲਨ ਖੁਦ ਹੀ! ਖੇਤਰ ਦੁਆਰਾ ਸਾਡੇ ਗਾਹਕਾਂ ਦੀ ਵੰਡ ਨੂੰ ਬਹੁਤ ਸਰਲ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਸਾਡੇ ਕੋਲ bitrix24.ru, bitrix24.com, .de - ਹੁਣ 13 ਵੱਖ-ਵੱਖ ਡੋਮੇਨ ਹਨ, ਜੋ ਵੱਖ-ਵੱਖ ਜ਼ੋਨਾਂ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਨ। ਅਸੀਂ ਨਿਮਨਲਿਖਤ 'ਤੇ ਆਏ ਹਾਂ: ਹਰੇਕ ਖੇਤਰ ਦੇ ਆਪਣੇ ਬੈਲੰਸਰ ਹਨ। ਇਹ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਨੈੱਟਵਰਕ 'ਤੇ ਪੀਕ ਲੋਡ ਕਿੱਥੇ ਹੈ, ਖੇਤਰਾਂ ਵਿੱਚ ਵੰਡਣਾ ਵਧੇਰੇ ਸੁਵਿਧਾਜਨਕ ਬਣਾਉਂਦਾ ਹੈ। ਜੇ ਇਹ ਇੱਕ ਸਿੰਗਲ ਬੈਲੇਂਸਰ ਦੇ ਪੱਧਰ 'ਤੇ ਇੱਕ ਅਸਫਲਤਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਸਿਰਫ਼ ਸੇਵਾ ਤੋਂ ਹਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਡੀਐਨਐਸ ਤੋਂ ਹਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ. ਜੇਕਰ ਬੈਲੇਂਸਰਾਂ ਦੇ ਸਮੂਹ ਵਿੱਚ ਕੁਝ ਸਮੱਸਿਆ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਦੂਜੀਆਂ ਸਾਈਟਾਂ 'ਤੇ ਬੈਕਅੱਪ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਵਿਚਕਾਰ ਸਵਿਚਿੰਗ ਉਸੇ ਰੂਟ53 ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਕਿਉਂਕਿ ਛੋਟੇ ਟੀਟੀਐਲ ਦੇ ਕਾਰਨ, ਸਵਿਚਿੰਗ ਵੱਧ ਤੋਂ ਵੱਧ 2, 3, 5 ਮਿੰਟ ਦੇ ਅੰਦਰ ਹੁੰਦੀ ਹੈ। .

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

ਅਤੇ S3 ਡਿੱਗ ਸਕਦਾ ਹੈ - ਇਹ ਇੱਕ ਵਾਰ ਹੋਇਆ. ਇਸ ਲਈ, ਅਸੀਂ ਹੇਠ ਲਿਖੀ ਸਕੀਮ 'ਤੇ ਆਏ: ਕੁਝ ਸਾਲ ਪਹਿਲਾਂ ਰੂਸ ਵਿੱਚ ਕੋਈ ਗੰਭੀਰ ਜਨਤਕ ਵਸਤੂ ਸਟੋਰੇਜ ਸੁਵਿਧਾਵਾਂ ਨਹੀਂ ਸਨ, ਅਤੇ ਅਸੀਂ ਆਪਣਾ ਕੁਝ ਕਰਨ ਦੇ ਵਿਕਲਪ 'ਤੇ ਵਿਚਾਰ ਕੀਤਾ... ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਅਸੀਂ ਅਜਿਹਾ ਕਰਨਾ ਸ਼ੁਰੂ ਨਹੀਂ ਕੀਤਾ, ਕਿਉਂਕਿ ਅਸੀਂ ਸਾਡੇ ਕੋਲ ਉਹ ਮੁਹਾਰਤ ਹੈ ਜੋ ਸਾਡੇ ਕੋਲ ਨਹੀਂ ਹੈ, ਅਤੇ ਸ਼ਾਇਦ ਗੜਬੜ ਹੋ ਜਾਵੇਗੀ। ਹੁਣ Mail.ru ਕੋਲ s3-ਅਨੁਕੂਲ ਸਟੋਰੇਜ ਹੈ, Yandex ਕੋਲ ਹੈ, ਅਤੇ ਕਈ ਹੋਰ ਪ੍ਰਦਾਤਾਵਾਂ ਕੋਲ ਇਹ ਹੈ। ਅਸੀਂ ਆਖਰਕਾਰ ਇਸ ਵਿਚਾਰ 'ਤੇ ਆਏ ਕਿ ਅਸੀਂ ਚਾਹੁੰਦੇ ਸੀ, ਪਹਿਲਾਂ, ਬੈਕਅੱਪ, ਅਤੇ ਦੂਜਾ, ਸਥਾਨਕ ਕਾਪੀਆਂ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਯੋਗਤਾ। ਖਾਸ ਤੌਰ 'ਤੇ ਰੂਸੀ ਖੇਤਰ ਲਈ, ਅਸੀਂ Mail.ru Hotbox ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਜੋ ਕਿ s3 ਦੇ ਅਨੁਕੂਲ API ਹੈ। ਸਾਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅੰਦਰ ਕੋਡ ਵਿੱਚ ਕਿਸੇ ਵੱਡੇ ਸੋਧਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ, ਅਤੇ ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੀ ਵਿਧੀ ਬਣਾਈ ਹੈ: s3 ਵਿੱਚ ਅਜਿਹੇ ਟਰਿਗਰ ਹਨ ਜੋ ਵਸਤੂਆਂ ਨੂੰ ਬਣਾਉਣ/ਮਿਟਾਉਣ ਨੂੰ ਟਰਿੱਗਰ ਕਰਦੇ ਹਨ, ਐਮਾਜ਼ਾਨ ਕੋਲ ਲਾਂਬਡਾ ਨਾਮ ਦੀ ਇੱਕ ਸੇਵਾ ਹੈ - ਇਹ ਕੋਡ ਦੀ ਇੱਕ ਸਰਵਰ ਰਹਿਤ ਲਾਂਚ ਹੈ ਜੋ ਕਿ ਕੁਝ ਖਾਸ ਟਰਿੱਗਰ ਸ਼ੁਰੂ ਹੋਣ 'ਤੇ ਹੀ ਲਾਗੂ ਕੀਤਾ ਜਾਵੇਗਾ।

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

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

ਓਹ, ਅਤੇ ਐਮਾਜ਼ਾਨ ਭੱਜ ਗਿਆ ...

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

ਜੇ ਕੰਪਨੀ ਗਲੋਬਲ ਹੈ ਅਤੇ ਰੂਸ ਇਸਦੇ ਲਈ ਇੱਕ ਬਹੁਤ ਛੋਟਾ ਹਿੱਸਾ ਹੈ, 3-5% - ਠੀਕ ਹੈ, ਇੱਕ ਤਰੀਕੇ ਨਾਲ ਜਾਂ ਕੋਈ ਹੋਰ, ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਕੁਰਬਾਨ ਕਰ ਸਕਦੇ ਹੋ.

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

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

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

ਅਤੇ 2019 ਵਿੱਚ, ਅਸੀਂ ਅਜੇ ਵੀ ਬਲਾਕਿੰਗ ਦੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਰਹਿੰਦੇ ਹਾਂ। ਮੈਂ ਪਿਛਲੀ ਰਾਤ ਦੇਖਿਆ: ਲਗਭਗ ਇੱਕ ਮਿਲੀਅਨ ਆਈਪੀ ਬਲੌਕ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ। ਇਹ ਸੱਚ ਹੈ ਕਿ ਐਮਾਜ਼ਾਨ ਨੂੰ ਲਗਭਗ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਨਬਲੌਕ ਕੀਤਾ ਗਿਆ ਸੀ, ਇਸਦੇ ਸਿਖਰ 'ਤੇ ਇਹ 20 ਮਿਲੀਅਨ ਪਤਿਆਂ 'ਤੇ ਪਹੁੰਚ ਗਿਆ ਸੀ... ਆਮ ਤੌਰ 'ਤੇ, ਅਸਲੀਅਤ ਇਹ ਹੈ ਕਿ ਇੱਥੇ ਤਾਲਮੇਲ, ਚੰਗੀ ਤਾਲਮੇਲ ਨਹੀਂ ਹੋ ਸਕਦਾ ਹੈ। ਅਚਾਨਕ. ਇਹ ਤਕਨੀਕੀ ਕਾਰਨਾਂ ਕਰਕੇ ਮੌਜੂਦ ਨਹੀਂ ਹੋ ਸਕਦਾ - ਅੱਗ, ਖੁਦਾਈ ਕਰਨ ਵਾਲੇ, ਇਹ ਸਭ। ਜਾਂ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਦੇਖਿਆ ਹੈ, ਪੂਰੀ ਤਰ੍ਹਾਂ ਤਕਨੀਕੀ ਨਹੀਂ. ਇਸ ਲਈ, ਕੋਈ ਵੱਡਾ ਅਤੇ ਵੱਡਾ, ਆਪਣੇ ਖੁਦ ਦੇ AS ਦੇ ਨਾਲ, ਸ਼ਾਇਦ ਇਸ ਨੂੰ ਹੋਰ ਤਰੀਕਿਆਂ ਨਾਲ ਪ੍ਰਬੰਧਿਤ ਕਰ ਸਕਦਾ ਹੈ - ਸਿੱਧਾ ਕਨੈਕਟ ਅਤੇ ਹੋਰ ਚੀਜ਼ਾਂ ਪਹਿਲਾਂ ਹੀ l2 ਪੱਧਰ 'ਤੇ ਹਨ. ਪਰ ਇੱਕ ਸਧਾਰਨ ਸੰਸਕਰਣ ਵਿੱਚ, ਸਾਡੇ ਵਰਗਾ ਜਾਂ ਇਸ ਤੋਂ ਵੀ ਛੋਟਾ, ਤੁਸੀਂ, ਕਿਸੇ ਹੋਰ ਥਾਂ 'ਤੇ ਸਰਵਰਾਂ ਦੇ ਪੱਧਰ 'ਤੇ ਰਿਡੰਡੈਂਸੀ ਹੋ ਸਕਦੇ ਹੋ, ਪਹਿਲਾਂ ਤੋਂ ਸੰਰਚਿਤ vpn, ਪ੍ਰੌਕਸੀ, ਉਹਨਾਂ ਹਿੱਸਿਆਂ ਵਿੱਚ ਕੌਂਫਿਗਰੇਸ਼ਨ ਨੂੰ ਉਹਨਾਂ ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਣ ਦੀ ਸਮਰੱਥਾ ਦੇ ਨਾਲ। ਜੋ ਤੁਹਾਡੀ ਕਨੈਕਟੀਵਿਟੀ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਇਹ ਸਾਡੇ ਲਈ ਇੱਕ ਤੋਂ ਵੱਧ ਵਾਰ ਕੰਮ ਆਇਆ, ਜਦੋਂ ਐਮਾਜ਼ਾਨ ਦੀ ਬਲਾਕਿੰਗ ਸ਼ੁਰੂ ਹੋਈ; ਸਭ ਤੋਂ ਮਾੜੀ ਸਥਿਤੀ ਵਿੱਚ, ਅਸੀਂ ਉਹਨਾਂ ਦੁਆਰਾ ਸਿਰਫ S3 ਟ੍ਰੈਫਿਕ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ, ਪਰ ਹੌਲੀ ਹੌਲੀ ਇਹ ਸਭ ਹੱਲ ਹੋ ਗਿਆ।

ਇੱਕ ਪੂਰੇ ਪ੍ਰਦਾਤਾ ਨੂੰ ਕਿਵੇਂ ਰਿਜ਼ਰਵ ਕਰਨਾ ਹੈ?

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

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

ਆਟੋਮੇਸ਼ਨ ਬਾਰੇ ਕੁਝ ਸ਼ਬਦ

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

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

ਸਿੱਟਾ

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

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

ਇਹ ਟੈਕਸਟ ਕਾਨਫਰੰਸ ਵਿੱਚ ਅਲੈਗਜ਼ੈਂਡਰ ਡੇਮੀਡੋਵ ਦੀ ਰਿਪੋਰਟ ਦਾ ਇੱਕ ਅਪਡੇਟ ਕੀਤਾ ਅਤੇ ਵਿਸਤ੍ਰਿਤ ਰੂਪ ਹੈ ਅਪਟਾਈਮ ਦਿਨ 4.

ਸਰੋਤ: www.habr.com