DevOps ਬਨਾਮ DevSecOps: ਇਹ ਇੱਕ ਬੈਂਕ ਵਿੱਚ ਕਿਹੋ ਜਿਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਸੀ

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

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

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

ਸਧਾਰਨ ਖੁਲਾਸਾ ਕਿ ਠੇਕੇਦਾਰ ਨੂੰ ਉਤਪਾਦ ਕੋਡ ਤੱਕ ਪੂਰੀ ਪਹੁੰਚ ਸੀ, ਨੇ ਪਹਿਲਾਂ ਹੀ ਉਹਨਾਂ ਦੀ ਦੁਨੀਆ ਨੂੰ ਉਲਟਾ ਦਿੱਤਾ ਸੀ.

ਇਸ ਸਮੇਂ, DevSecOps ਦੀ ਕਹਾਣੀ ਸ਼ੁਰੂ ਹੋਈ, ਜਿਸ ਬਾਰੇ ਮੈਂ ਤੁਹਾਨੂੰ ਦੱਸਣਾ ਚਾਹੁੰਦਾ ਹਾਂ.

ਬੈਂਕ ਨੇ ਇਸ ਸਥਿਤੀ ਤੋਂ ਕਿਹੜੇ ਵਿਹਾਰਕ ਸਿੱਟੇ ਕੱਢੇ ਹਨ?

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

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

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

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

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

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

ਕੀ ਬਦਲ ਗਿਆ ਹੈ

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

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

• ਸੀਆਈ: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
• CD: ਜਵਾਬਦੇਹ, ਕਠਪੁਤਲੀ, TeamCity, Gitlab TFS, Liquidbase.
• ਟੈਸਟ: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Center, MF UFT, Atacama.
• ਪੇਸ਼ਕਾਰੀ (ਰਿਪੋਰਟਿੰਗ, ਸੰਚਾਰ): ਗ੍ਰਾਫਾਨਾ, ਕਿਬਾਨਾ, ਜੀਰਾ, ਸੰਗਮ, ਰਾਕੇਟਚੈਟ।
• ਓਪਰੇਸ਼ਨ (ਸੰਭਾਲ, ਪ੍ਰਬੰਧਨ): ਜਵਾਬਦੇਹ, ਜ਼ੈਬਿਕਸ, ਪ੍ਰੋਮੀਥੀਅਸ, ਇਲਾਸਟਿਕ + ਲੌਗਸਟੈਸ਼, ਐਮਐਫ ਸਰਵਿਸ ਮੈਨੇਜਰ, ਜੀਰਾ, ਸੰਗਮ, ਐਮਐਸ ਪ੍ਰੋਜੈਕਟ।

ਚੁਣਿਆ ਸਟੈਕ:

• ਗਿਆਨ ਅਧਾਰ - ਐਟਲਸੀਅਨ ਸੰਗਮ;
• ਟਾਸਕ ਟਰੈਕਰ - ਐਟਲਸੀਅਨ ਜੀਰਾ;
• ਆਰਟੀਫੈਕਟ ਰਿਪੋਜ਼ਟਰੀ - "Nexus";
• ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਪ੍ਰਣਾਲੀ - “ਗਿਟਲੈਬ ਸੀਆਈ”;
• ਨਿਰੰਤਰ ਵਿਸ਼ਲੇਸ਼ਣ ਪ੍ਰਣਾਲੀ - "ਸੋਨਾਰਕਿਊਬ";
• ਐਪਲੀਕੇਸ਼ਨ ਸੁਰੱਖਿਆ ਵਿਸ਼ਲੇਸ਼ਣ ਪ੍ਰਣਾਲੀ - "ਮਾਈਕਰੋ ਫੋਕਸ ਫੋਰਟੀਫਾਈ";
• ਸੰਚਾਰ ਪ੍ਰਣਾਲੀ - "GitLab Mattermost";
• ਸੰਰਚਨਾ ਪ੍ਰਬੰਧਨ ਸਿਸਟਮ - "ਜਵਾਬ";
• ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ - “ELK”, “ਟਿਕ ਸਟੈਕ” (“InfluxData”)।

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

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

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

ਅੱਗੇ ਸਰਕਟ ਦੀ ਰਚਨਾ ਹੈ - ਸੌਫਟਵੇਅਰ ਦੀ ਸਥਾਪਨਾ, ਸੰਰਚਨਾ. ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਤੈਨਾਤੀ ਅਤੇ ਪ੍ਰਬੰਧਨ ਲਈ ਸਕ੍ਰਿਪਟਾਂ ਦਾ ਵਿਕਾਸ। ਅੱਗੇ ਕਨਵੇਅਰ ਸਪੋਰਟ ਲਈ ਤਬਦੀਲੀ ਆਉਂਦੀ ਹੈ।

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

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

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

ਕਦਮ ਦਰ ਕਦਮ

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

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

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

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

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

ਪੜਾਅ 3. ਸਾਰੇ ਸਬ-ਸਿਸਟਮ ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਸੈਟਿੰਗਾਂ ਦਾ ਨਵੇਂ PAC ਵਿੱਚ ਮਾਈਗਰੇਸ਼ਨ। ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਆਟੋਮੇਸ਼ਨ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਿਆ ਗਿਆ ਸੀ, ਅਤੇ DSO ਸਬ-ਸਿਸਟਮ ਦਾ ਮਾਈਗ੍ਰੇਸ਼ਨ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਵੈਚਾਲਿਤ ਮੋਡ ਵਿੱਚ ਪੂਰਾ ਕੀਤਾ ਗਿਆ ਸੀ। ਵਿਕਾਸ ਟੀਮਾਂ ਦੀਆਂ ਪਾਈਪਲਾਈਨਾਂ ਦੁਆਰਾ IP ਵਿਕਾਸ ਦੇ ਰੂਪਾਂ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਇਆ ਗਿਆ ਸੀ।

ਪੜਾਅ 4. ਐਪਲੀਕੇਸ਼ਨ ਸੌਫਟਵੇਅਰ ਸਥਾਪਨਾ ਦਾ ਸਵੈਚਾਲਨ. ਇਹ ਕਾਰਜ ਨਵੀਆਂ ਟੀਮਾਂ ਦੀ ਟੀਮ ਲੀਡ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੀਤੇ ਗਏ ਸਨ।

ਪੜਾਅ 5. ਸ਼ੋਸ਼ਣ.

ਰਿਮੋਟ ਪਹੁੰਚ

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

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

1. ਬੈਂਕ ਵਿੱਚ ਪਹਿਲਾਂ ਤੋਂ ਉਪਲਬਧ ਤਕਨੀਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ।
2. ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਮੌਜੂਦਾ ਡੋਮੇਨ ਕੰਟਰੋਲਰਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਉਤਪਾਦਕ ਖਾਤਾ ਵਸਤੂਆਂ ਦੇ ਰਿਕਾਰਡਾਂ ਨੂੰ ਸਟੋਰ ਕਰਦੇ ਹਨ।
3. ਪਹੁੰਚ ਸਿਰਫ਼ ਉਹਨਾਂ ਸਰੋਤਾਂ ਤੱਕ ਸੀਮਿਤ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਕਿਸੇ ਖਾਸ ਟੀਮ ਦੁਆਰਾ ਲੋੜੀਂਦੇ ਹਨ (ਤਾਂ ਕਿ ਇੱਕ ਉਤਪਾਦ ਟੀਮ ਦੂਜੀ ਟੀਮ ਦੇ ਸਰੋਤਾਂ ਤੱਕ ਪਹੁੰਚ ਨਾ ਕਰ ਸਕੇ)।
4. ਸਿਸਟਮਾਂ ਵਿੱਚ RBAC ਉੱਤੇ ਅਧਿਕਤਮ ਨਿਯੰਤਰਣ।

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

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

VM ਟੈਂਪਲੇਟ ਪ੍ਰਬੰਧਨ

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

ਵਿਕਾਸ ਦੇ ਦੌਰਾਨ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਅਤੇ ਸੁਰੱਖਿਆ ਲੋੜਾਂ ਨੂੰ ਵੀ ਧਿਆਨ ਵਿੱਚ ਰੱਖਿਆ ਗਿਆ ਸੀ - ਚਿੱਤਰਾਂ ਨੂੰ ਅਪ ਟੂ ਡੇਟ ਰੱਖਣਾ (ਪੈਚ, ਆਦਿ), SIEM ਨਾਲ ਏਕੀਕਰਣ, ਬੈਂਕ ਦੇ ਮਿਆਰਾਂ ਅਨੁਸਾਰ ਸੁਰੱਖਿਆ ਸੈਟਿੰਗਾਂ।

ਨਤੀਜੇ ਵਜੋਂ, ਉਹਨਾਂ ਨੂੰ ਅੱਪ ਟੂ ਡੇਟ ਰੱਖਣ ਦੀ ਲਾਗਤ ਨੂੰ ਘੱਟ ਕਰਨ ਲਈ ਘੱਟੋ-ਘੱਟ ਚਿੱਤਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਗਿਆ ਸੀ। POPPO ਦੇ ਨਵੇਂ ਸੰਸਕਰਣਾਂ ਲਈ ਹਰੇਕ ਚਿੱਤਰ ਨੂੰ ਪੈਚ ਕਰਨ ਨਾਲੋਂ ਬੇਸ OS ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ ਬਹੁਤ ਸੌਖਾ ਹੈ।

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

ਇੰਟਰਨੈੱਟ ਤੱਕ ਪਹੁੰਚ

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

1. ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਪਹੁੰਚ.
2. ਡਿਵੈਲਪਰ ਪਹੁੰਚ।

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

ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਕਾਰਨਾਂ (ਸਟੈਕਓਵਰਫਲੋ) ਲਈ ਇੰਟਰਨੈਟ ਤੱਕ ਪਹੁੰਚ ਦੀ ਲੋੜ ਸੀ। ਅਤੇ ਹਾਲਾਂਕਿ ਸਾਰੀਆਂ ਕਮਾਂਡਾਂ, ਜਿਵੇਂ ਕਿ ਉੱਪਰ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਦੀ ਸਰਕਟ ਤੱਕ ਰਿਮੋਟ ਪਹੁੰਚ ਸੀ, ਇਹ ਹਮੇਸ਼ਾਂ ਸੁਵਿਧਾਜਨਕ ਨਹੀਂ ਹੁੰਦਾ ਜਦੋਂ ਤੁਸੀਂ IDE ਵਿੱਚ ਬੈਂਕ ਵਿੱਚ ਡਿਵੈਲਪਰ ਦੇ ਕੰਮ ਵਾਲੀ ਥਾਂ ਤੋਂ ctrl+v ਨਹੀਂ ਕਰ ਸਕਦੇ ਹੋ।

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

Результаты

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

ਅਲੈਗਜ਼ੈਂਡਰ ਸ਼ੁਬਿਨ, ਸਿਸਟਮ ਆਰਕੀਟੈਕਟ।

ਸਰੋਤ: www.habr.com