DevOps ਅਤੇ ਅਰਾਜਕਤਾ: ਇੱਕ ਵਿਕੇਂਦਰੀਕ੍ਰਿਤ ਸੰਸਾਰ ਵਿੱਚ ਸੌਫਟਵੇਅਰ ਡਿਲਿਵਰੀ

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

ਅਸੀਂ ਰਿਪੋਰਟ ਦਾ ਇੱਕ ਟੈਕਸਟ ਸੰਸਕਰਣ ਤਿਆਰ ਕੀਤਾ ਹੈ।

ਸ਼ੁਭ ਸਵੇਰੇ

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

ਆਪਣੇ ਹੱਥ ਉਠਾਓ ਜੋ ਸੋਚਦੇ ਹਨ ਕਿ DevOps ਪਹਿਲਾਂ ਹੀ 2018 ਵਿੱਚ ਇੱਕ ਪੇਸ਼ਾ ਹੈ? ਅਜਿਹੇ ਹਨ। ਕੀ ਕਮਰੇ ਵਿੱਚ ਕੋਈ DevOps ਇੰਜਨੀਅਰ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਨੌਕਰੀ ਦਾ ਵੇਰਵਾ “DevOps ਇੰਜੀਨੀਅਰ” ਕਹਿੰਦਾ ਹੈ? ਕੀ ਕਮਰੇ ਵਿੱਚ ਕੋਈ DevOps ਪ੍ਰਬੰਧਕ ਹਨ? ਅਜਿਹਾ ਕੋਈ ਨਹੀਂ ਹੈ। DevOps ਆਰਕੀਟੈਕਟ? ਨਾਲ ਹੀ ਨੰ. ਕਾਫ਼ੀ ਨਹੀ. ਕੀ ਇਹ ਸੱਚਮੁੱਚ ਸੱਚ ਹੈ ਕਿ ਕੋਈ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਉਹ ਇੱਕ DevOps ਇੰਜੀਨੀਅਰ ਹਨ?

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

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

ਅਸੀਂ ਰਚਨਾਤਮਕ ਲੋਕ ਹਾਂ, ਅਸੀਂ ਸਿਰਫ਼ ਆਰਾਮ ਨਹੀਂ ਕਰਦੇ। ਅਸੀਂ ਕਹਿੰਦੇ ਹਾਂ: DevOps ਇੱਕ ਵਿਆਪਕ ਕਾਫ਼ੀ ਸ਼ਬਦ ਨਹੀਂ ਹੈ; ਇਸ ਵਿੱਚ ਅਜੇ ਵੀ ਵੱਖ-ਵੱਖ, ਦਿਲਚਸਪ ਤੱਤਾਂ ਦੀ ਘਾਟ ਹੈ। ਅਤੇ ਅਸੀਂ ਆਪਣੀਆਂ ਗੁਪਤ ਪ੍ਰਯੋਗਸ਼ਾਲਾਵਾਂ ਵਿੱਚ ਜਾਂਦੇ ਹਾਂ ਅਤੇ ਦਿਲਚਸਪ ਪਰਿਵਰਤਨ ਪੈਦਾ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.

ਤਰਕ ਲੋਹਾ ਹੈ, ਠੀਕ ਹੈ? ਸਾਡਾ ਡਿਲੀਵਰੀ ਸਿਸਟਮ ਕਾਰਜਸ਼ੀਲ ਨਹੀਂ ਹੈ, ਸਾਡੇ ਸਿਸਟਮ ਅਸਥਿਰ ਹਨ ਅਤੇ ਸਾਡੇ ਉਪਭੋਗਤਾ ਅਸੰਤੁਸ਼ਟ ਹਨ, ਸਾਡੇ ਕੋਲ ਸਮੇਂ 'ਤੇ ਸੌਫਟਵੇਅਰ ਨੂੰ ਰੋਲ ਆਊਟ ਕਰਨ ਦਾ ਸਮਾਂ ਨਹੀਂ ਹੈ, ਅਸੀਂ ਬਜਟ ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦੇ। ਅਸੀਂ ਇਹ ਸਭ ਕਿਵੇਂ ਹੱਲ ਕਰਨ ਜਾ ਰਹੇ ਹਾਂ? ਅਸੀਂ ਇੱਕ ਨਵਾਂ ਸ਼ਬਦ ਲੈ ਕੇ ਆਵਾਂਗੇ! ਇਹ "ਓਪਸ" ਨਾਲ ਖਤਮ ਹੋ ਜਾਵੇਗਾ ਅਤੇ ਸਮੱਸਿਆ ਹੱਲ ਹੋ ਜਾਵੇਗੀ।

ਇਸ ਲਈ ਮੈਂ ਇਸ ਪਹੁੰਚ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹਾਂ - "ਓਪਸ, ਅਤੇ ਸਮੱਸਿਆ ਹੱਲ ਹੋ ਗਈ ਹੈ।"

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

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

ਸਿਸਟਮ ਕੀ ਹੈ?

ਅਤੇ ਜੇਕਰ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਸਿਸਟਮਾਂ ਦੀ ਸੋਚ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਤਾਂ ਆਓ ਆਪਣੇ ਆਪ ਨੂੰ ਯਾਦ ਕਰਾਈਏ ਕਿ ਸਿਸਟਮ ਕੀ ਹੈ।

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

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

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

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

ਵਿਹਾਰਕ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਇਕ ਹੋਰ ਦਿਲਚਸਪ ਤੱਥ ਹੈ. ਸਿਸਟਮ ਕੁਝ ਅਜਿਹਾ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਇਸ ਦਾ ਕੋਈ ਵੀ ਅੰਗ ਨਹੀਂ ਕਰ ਸਕਦਾ।

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

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

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

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

ਅਰਾਜਕਤਾ ਸਿਧਾਂਤ

ਹਫੜਾ-ਦਫੜੀ ਦਾ ਅਧਿਐਨ ਕਰਨ ਵਾਲੇ ਲੋਕ ਆਪਣੇ ਆਪ ਨੂੰ ਅਰਾਜਕਤਾਵਾਦੀ ਕਹਿੰਦੇ ਹਨ।

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

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

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

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

ਦੋ ਹੋਰ ਦਿਲਚਸਪ ਖੋਜਾਂ ਹਨ.


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

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

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

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

ਅਤੇ ਬੇਬੁਨਿਆਦ ਨਾ ਹੋਣ ਲਈ, ਆਓ ਦੇਖੀਏ ਕਿ ਸਾਡੇ ਦੁਆਰਾ ਬਣਾਏ ਗਏ ਸਿਸਟਮ ਕਿਵੇਂ ਬਦਲ ਰਹੇ ਹਨ।

ਤੁਸੀਂ ਇਸ ਸ਼ਬਦ ਦੀ ਉਡੀਕ ਕਰ ਰਹੇ ਸੀ, ਮੈਂ ਸਮਝ ਗਿਆ. ਅਸੀਂ ਇੱਕ DevOps ਕਾਨਫਰੰਸ ਵਿੱਚ ਹਾਂ, ਅੱਜ ਇਹ ਸ਼ਬਦ ਲਗਭਗ ਇੱਕ ਲੱਖ ਵਾਰ ਸੁਣਿਆ ਜਾਵੇਗਾ ਅਤੇ ਫਿਰ ਅਸੀਂ ਰਾਤ ਨੂੰ ਇਸ ਬਾਰੇ ਸੁਪਨੇ ਦੇਖਾਂਗੇ.

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

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

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

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

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

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

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

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

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

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

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

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

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

ਅਰਾਜਕਤਾ ਇੰਜੀਨੀਅਰਿੰਗ

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

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

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

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

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

ਡਿਸਟਰੀਬਿਊਟਡ ਸਿਸਟਮ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਪ੍ਰੋਟੋਕੋਲ

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

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

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

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

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

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

ਇਹ ਸਾਰੇ ਪ੍ਰੋਜੈਕਟ ਨੌਜਵਾਨ ਹਨ, ਇਹਨਾਂ ਸਾਰਿਆਂ ਨੂੰ ਸਾਡੇ ਪਿਆਰ, ਸਾਡੀ ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਲੋੜ ਹੈ। ਇਹ ਸਭ ਓਪਨ ਸੋਰਸ, ਸਾਡੀ ਟੈਸਟਿੰਗ, ਸਾਡਾ ਲਾਗੂਕਰਨ ਹੈ। ਉਹ ਸਾਨੂੰ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਤਕਨਾਲੋਜੀ ਕਿੱਥੇ ਜਾ ਰਹੀ ਹੈ।

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

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

ਫਿਰ ਇੱਕ ਬਹੁਤ ਲੰਮਾ ਸਮਾਂ ਸੀ - ਇੱਕ ਕਾਲਾ ਸਮਾਂ ਜਦੋਂ ਭਰੋਸਾ ਕੇਂਦਰੀਕਰਨ ਕੀਤਾ ਗਿਆ ਸੀ, ਜਦੋਂ ਅਸੀਂ ਉਨ੍ਹਾਂ ਲੋਕਾਂ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ ਜਿਨ੍ਹਾਂ ਨੂੰ ਅਸੀਂ ਇਸ ਤੱਥ ਦੇ ਆਧਾਰ 'ਤੇ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਅਸੀਂ ਉਸੇ ਜਨਤਕ ਜਾਂ ਰਾਜ ਸੰਸਥਾ ਨਾਲ ਸਬੰਧਤ ਹਾਂ।

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

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

DevOps ਸੰਗਠਨ ਦੇ ਬੁਨਿਆਦੀ ਤੱਤ

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

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

ਇਹ DevOps ਸੰਸਥਾਵਾਂ ਦਾ ਆਧਾਰ ਹੈ: ਜਾਣਕਾਰੀ ਪਾਰਦਰਸ਼ਤਾ, ਅਸਿੰਕ੍ਰੋਨਸ ਸੰਚਾਰ, ਪਰਿਵਰਤਨਸ਼ੀਲ ਲੀਡਰਸ਼ਿਪ, ਵਿਕੇਂਦਰੀਕਰਣ।

ਸੜਨਾ

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

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

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

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

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

ਕੈਓਸ ਬਾਂਦਰ ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਕੀ ਹੈ?

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

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

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

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

ਇਸ ਲਈ, DevOps ਫ਼ਲਸਫ਼ੇ ਵਿੱਚ, ਮਾਈਕ੍ਰੋਸੇਵਾਵਾਂ ਅਜਿਹੀ ਚੰਗੀ ਚੀਜ਼ ਨਹੀਂ ਹਨ?

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

ਫਿਰ ਵੀ, ਵਧੇਰੇ ਜ਼ੋਰ ਕੀ ਹੈ: ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਨੂੰ ਸਰਲ ਬਣਾਉਣ ਜਾਂ ਭਾਗਾਂ ਨੂੰ ਸਰਲ ਬਣਾਉਣ 'ਤੇ?

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

ਕੀ ਇਹ ਸੱਚ ਹੈ ਕਿ ਜੋ ਵੀ ਤੁਸੀਂ ਕਿਹਾ ਹੈ ਉਹ ਬਿਨਾਂ ਮੁਕਾਬਲੇ ਦੇ ਸੰਸਾਰ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਉੱਥੇ ਦੀ ਹਫੜਾ-ਦਫੜੀ ਬਹੁਤ ਦਿਆਲੂ ਹੈ, ਅਤੇ ਇਸ ਹਫੜਾ-ਦਫੜੀ ਦੇ ਅੰਦਰ ਕੋਈ ਵਿਰੋਧਾਭਾਸ ਨਹੀਂ ਹੈ, ਕੋਈ ਵੀ ਕਿਸੇ ਨੂੰ ਖਾਣਾ ਜਾਂ ਮਾਰਨਾ ਨਹੀਂ ਚਾਹੁੰਦਾ ਹੈ? ਮੁਕਾਬਲਾ ਅਤੇ DevOps ਦਾ ਕਿਰਾਇਆ ਕਿਵੇਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ?

ਖੈਰ, ਇਹ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਅਸੀਂ ਕਿਸ ਕਿਸਮ ਦੇ ਮੁਕਾਬਲੇ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ. ਕੀ ਇਹ ਕੰਮ ਵਾਲੀ ਥਾਂ ਜਾਂ ਕੰਪਨੀਆਂ ਵਿਚਕਾਰ ਮੁਕਾਬਲੇਬਾਜ਼ੀ ਬਾਰੇ ਹੈ?

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

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

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

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

ਇਸ ਸਾਲ ਦੀ ਕਾਨਫਰੰਸ DevOpsDays ਮਾਸਕੋ 7 ਦਸੰਬਰ ਨੂੰ ਟੈਕਨੋਪੋਲਿਸ ਵਿਖੇ ਹੋਵੇਗੀ। ਅਸੀਂ 11 ਨਵੰਬਰ ਤੱਕ ਰਿਪੋਰਟਾਂ ਲਈ ਅਰਜ਼ੀਆਂ ਸਵੀਕਾਰ ਕਰ ਰਹੇ ਹਾਂ। ਲਿਖੋ ਜੇਕਰ ਤੁਸੀਂ ਬੋਲਣਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਸਾਨੂੰ।

ਭਾਗੀਦਾਰਾਂ ਲਈ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਖੁੱਲੀ ਹੈ, ਟਿਕਟਾਂ ਦੀ ਕੀਮਤ 7000 ਰੂਬਲ ਹੈ। ਸਾਡੇ ਨਾਲ ਸ਼ਾਮਲ!

ਸਰੋਤ: www.habr.com