17 ਮਾਰਚ 2025·8 ਮਿੰਟ
VMware ਅਤੇ Broadcom: ਜਦੋਂ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਕੰਟਰੋਲ ਪਲੇਨ ਬਣ ਜਾਂਦੀ ਹੈ
ਸਾਦੀ ਭਾਸ਼ਾ ਵਿੱਚ ਵੇਖਿਆ ਕਿ VMware ਕਿਵੇਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਆਈਟੀ ਦਾ ਕੰਟਰੋਲ ਪਲੇਨ ਬਣ ਗਿਆ, ਅਤੇ Broadcom ਦੀ ਮਾਲਕੀਅਤ ਬਜਟ, ਟੂਲ ਅਤੇ ਟੀਮਾਂ ਲਈ ਕੀ-ਕੀ ਬਦਲ ਸਕਦੀ ਹੈ।
ਸਾਦੀ ਭਾਸ਼ਾ ਵਿੱਚ ਵੇਖਿਆ ਕਿ VMware ਕਿਵੇਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਆਈਟੀ ਦਾ ਕੰਟਰੋਲ ਪਲੇਨ ਬਣ ਗਿਆ, ਅਤੇ Broadcom ਦੀ ਮਾਲਕੀਅਤ ਬਜਟ, ਟੂਲ ਅਤੇ ਟੀਮਾਂ ਲਈ ਕੀ-ਕੀ ਬਦਲ ਸਕਦੀ ਹੈ।
ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ, ਆਮ ਭਾਸ਼ਾ ਵਿੱਚ, ਇੱਕ ਢੰਗ ਹੈ ਜਿਥੇ ਇਕ ਹੀ ਫਿਜ਼ੀਕਲ ਮਸ਼ੀਨ 'ਤੇ ਬਹੁਤ ਸਾਰੇ "ਵਰਚੁਅਲ" ਸਰਵਰ ਚਲਾਏ ਜਾਂਦੇ ਹਨ—ਇਸ ਤਰ੍ਹਾਂ ਇੱਕ ਬਕਸਾ ਕਈ ਢੰਗਾਂ ਨਾਲ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕਈ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ ਕੰਟਰੋਲ ਪਲੇਨ ਉਹ ਟੂਲ ਅਤੇ ਨੀਤੀਆਂ ਦੇ ਸੈੱਟ ਹਨ ਜੋ ਕਿਸੇ ਸਿਸਟਮ ਨੂੰ ਦੱਸਦੇ ਹਨ ਕਿ ਕੀ ਕਿੱਥੇ ਚੱਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਕੌਣ ਇਹ ਬਦਲ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਕਿਵੇਂ ਨਿਗਰਾਨੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਜੇ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਇੰਜਣ ਹੈ, ਤਾਂ ਕੰਟਰੋਲ ਪਲੇਨ ਡੈਸ਼ਬੋਰਡ, ਸਟੀਅਰਿੰਗ-ਵ੍ਹੀਲ ਅਤੇ ਟ੍ਰੈਫਿਕ ਕਾਨੂੰਨ ਹਨ।
VMware ਸਿਰਫ਼ ਸੰਗਠਨਾਂ ਨੂੰ ਘੱਟ ਸਰਵਰ ਖਰੀਦਣ ਵਿੱਚ ਮਦਦ ਨਹੀਂ ਕਰਦਾ। ਸਮੇਂ ਦੇ ਨਾਲ, vSphere ਅਤੇ vCenter ਉਹ ਥਾਂ ਬਣ ਗਏ ਜਿੱਥੇ ਟੀਮਾਂ:
ਇਸ ਲਈ VMware ਸਿਰਫ਼ "VMs ਚਲਾਉਣ" ਤੋਂ ਅੱਗੇ ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ। ਕਈ ਐਂਟਰਪ੍ਰਾਈਜ਼ਾਂ ਵਿੱਚ, ਇਹ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਨਾਲ ਇੰਫਰਾਸਟ੍ਰਕਚਰ ਲਈ ਓਪਰੇਟਿੰਗ ਲੇਅਰ ਬਣ ਗਿਆ—ਉਹ ਪੋਇੰਟ ਜਿੱਥੇ ਫੈਸਲੇ ਲਾਗੂ ਅਤੇ ਆਡਿਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
ਇਹ ਲੇਖ ਵੇਖਦਾ ਹੈ ਕਿ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਕਿਵੇਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਕੰਟਰੋਲ ਪਲੇਨ ਬਣ ਗਿਆ, ਇਹ ਸਥਿਤੀ ਰਣਨੀਤਿਕ ਤੌਰ 'ਤੇ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਅਤੇ ਮਲਕੀਅਤ ਅਤੇ ਉਤਪਾਦ ਰਣਨੀਤੀ ਬਦਲਣ 'ਤੇ ਕੀ-ਕੀ ਤਬਦੀਲੀਆਂ ਆਮ ਤੌਰ 'ਤੇ ਹੁੰਦੀਆਂ ਹਨ। ਅਸੀਂ ਸੰਖੇਪ ਇਤਿਹਾਸ ਵੇਖਾਂਗੇ ਅਤੇ ਫਿਰ ਆਈਟੀ ਟੀਮਾਂ ਲਈ ਪ੍ਰਯੋਗਿਕ ਪ੍ਰਭਾਵਾਂ 'ਤੇ ਧਿਆਨ ਦੇਵਾਂਗੇ: ਓਪਰੇਸ਼ਨ, ਬਜਟਿੰਗ ਸਿਗਨਲ, ਜੋਖਮ, ਇਕੋਸਿਸਟਮ ਨਿਰਭਰਤਾਵਾਂ, ਅਤੇ 6–18 ਮਹੀਨਿਆਂ ਵਿੱਚ ਰਹਿਣ/ਵਿਭਿੰਨ / ਮਾਈਗ੍ਰੇਟ ਕਰਨ ਦੇ ਵਾਸਤਵਿਕ ਵਿਕਲਪ।
ਅਸੀਂ ਗੁਪਤ ਰੋਡਮੈਪਾਂ 'ਤੇ ਅਨੁਮਾਨ ਨਹੀਂ ਲਗਾਊਂਗੇ ਅਤੇ ਨਿਸ਼ਚਿਤ ਵਪਾਰਕ ਕਦਮਾਂ ਦੀ ਭਵਿੱਖਬਾਣੀ ਨਹੀਂ ਕਰਾਂਗੇ। ਬਜਾਏ, ਅਸੀਂ ਦੇਖਣਯੋਗ ਪੈਟਰਨਾਂ 'ਤੇ ਧਿਆਨ ਦੇਵਾਂਗੇ: ਇੱਕ ਅਧਿਗ੍ਰਹਨ ਤੋਂ ਬਾਅਦ ਪਹਿਲਾਂ ਆਮ ਤੌਰ 'ਤੇ ਕੀ ਬਦਲਦਾ ਹੈ (ਪੈਕੇਜਿੰਗ, ਲਾਇਸੰਸਿੰਗ, ਸਪੋਰਟ ਮੋਸ਼ਨ), ਉਹ ਬਦਲਾਅ ਰੋਜ਼ਾਨਾ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ, ਅਤੇ ਅੱਧੂਰੀ ਜਾਣਕਾਰੀ ਨਾਲ ਕਿਵੇਂ ਫੈਸਲੇ ਲਏ ਜਾਣ—ਬਿਨਾਂ ਢਿੱਗਣ ਜਾਂ ਜ਼ਿਆਦਾ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਨ ਦੇ।
ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਇੱਕ ਮਹਾਨ "ਪਲੇਟਫਾਰਮ" ਵਿਚਾਰ ਵਜੋਂ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਈ। ਇਹ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਹੱਲ ਵਜੋਂ ਆਇਆ: ਬਹੁਤ ਸਾਰੇ ਘੱਟ ਵਰਤੇ ਹੋਏ ਸਰਵਰ, ਹਾਰਡਵੇਅਰ ਫੈਲਾਅ, ਅਤੇ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਪੂਰੇ ਫਿਜ਼ੀਕਲ ਬਾਕਸ 'ਤੇ ਮਾਲਕੀ ਕਾਰਨ ਹੋਣ ਵਾਲੀਆਂ ਬਹੁਤ ਰਾਤੀਆਂ ਦੀਆਂ ਖਰਾਬੀਆਂ।
ਸ਼ੁਰੂ ਵਿੱਚ ਪੀਚ ਸਿੱਧਾ ਸੀ—ਕਈ ਵਰਕਲੋਡ ਇਕ ਹੋਸਟ 'ਤੇ ਚਲਾਓ ਅਤੇ ਇੰਨੀ ਜ਼ਿਆਦਾ ਸਰਵਰ ਖਰੀਦਣਾ ਬੰਦ ਕਰੋ। ਇਹ ਜਲਦੀ ਹੀ ਇੱਕ ਓਪਰੇਸ਼ਨਲ ਆਦਤ ਬਣ ਗਿਆ।
ਜਦੋਂ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਆਮ ਹੋ ਗਿਆ, ਸਭ ਤੋਂ ਵੱਡੀ ਜਿੱਤ ਸਿਰਫ਼ "ਅਸੀਂ ਹਾਰਡਵੇਅਰ 'ਤੇ ਪੈਸਾ ਬਚਾਇਆ" ਨਹੀਂ ਸੀ। ਇਹ ਸੀ ਕਿ ਟੀਮਾਂ ਹਰ ਜਗ੍ਹਾ ਇੱਕੋ ਜਿਹੇ ਪੈਟਰਨ ਦੁਹਰਾ ਸਕਦੀਆਂ ਸਨ।
ਹਰ ਸਥਾਨ ਵਿੱਚ ਇੱਕ ਵਿਲੱਖਣ ਸਰਵਰ ਸੈੱਟਅੱਪ ਹੋਣ ਦੀ ਬਜਾਏ, ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਇੱਕ ਸਤੰਭੀਕ ਬੇਸਲਾਈਨ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦੀ ਸੀ: ਸਮਾਨ ਹੋਸਟ ਬਿਲਡ, ਆਮ ਟੈਮਪਲੇਟ, ਪੇਸ਼ਗੋਈਯੋਗ ਕੈਪੈਸਿਟੀ ਯੋਜਨਾ, ਅਤੇ ਪੈਚਿੰਗ ਅਤੇ ਰਿਕਵਰੀ ਲਈ ਸਾਂਝੀ ਪ੍ਰੈਕਟਿਸ। ਇਹ ਸਾਂਝੀਅਤੋਂ ਮਹੱਤਵਪੂਰਨ ਸੀ:
ਚਾਹੇ ਨੀਵੀਂ ਹਾਰਡਵੇਅਰ ਵੱਖਰੀ ਹੋਵੇ, ਓਪਰੇਸ਼ਨਲ ਮਾਡਲ ਵੱਧ-ਤਰ ਇੱਕੋ ਜਿਹਾ ਰਹਿ ਸਕਦਾ ਸੀ।
ਜਿਵੇਂ-ਜਿਵੇਂ ਵਾਤਾਵਰਨ ਵਧੇ, ਗੁਰੁਤਵਾਕਰਸ਼ਣ ਇਕੱਲੇ ਹੋਸਟਾਂ ਤੋਂ ਕੇਂਦਰੀਕ੍ਰਿਤ ਮੈਨੇਜਮੈਂਟ ਵੱਲ ਵਧਿਆ। vCenter ਵਰਗੇ ਟੂਲ ਸਿਰਫ਼ "ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਦਿੰਭਾਲਦੇ" ਨਹੀਂ—ਉਹ ਓਥੇ ਬਣ ਗਏ ਜਿੱਥੇ ਐਡਮਿਨਿਸਟ੍ਰੇਟਰ ਰੋਜ਼ਮਰਰਾ ਦਾ ਕੰਮ ਕਰਦੇ ਹਨ: ਐਕਸੈਸ ਕੰਟਰੋਲ, ਇਨਵੈਂਟਰੀ, ਅਲਾਰਮ, ਕਲਸਟਰ ਸਿਹਤ, ਰਿਸੋਰਸ ਅਲੋਕੇਸ਼ਨ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਮੇਂਟੇਨੈਂਸ ਵਿੰਡੋ।
ਕਈ ਸੰਗਠਨਾਂ ਵਿੱਚ, ਜੇ ਇਹ ਮੈਨੇਜਮੈਂਟ ਕੰਸੋਲ ਵਿੱਚ ਦਿੱਖ ਨਹੀਂ ਸੀ, ਤਾਂ ਉਹ ਵਾਸਤਵ ਵਿੱਚ ਮੈਨੇਜਬਲ ਨਹੀਂ ਮੰਨਿਆ ਜਾਂਦਾ ਸੀ।
ਇੱਕ ਇੱਕੋ ਪਲੇਟਫਾਰਮ ਜਦ ਤੁਲਨਾਤਮਕ ਤੌਰ 'ਤੇ ਦੁਹਰਾਅਯੋਗਤਾ ਨੂੰ ਮਹੱਤਵ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਬੇਸਰੇਜ਼ ਟੂਲਾਂ ਦੇ ਜਥੇਬੰਦੀ ਨਾਲ ਜ਼ਿਆਦਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋ ਸਕਦਾ ਹੈ। "ਹਰ ਥਾਂ کافی" ਅਕਸਰ ਇਸਦੇ ਮਤਲਬ ਹੁੰਦਾ ਹੈ:
ਇਸ ਤਰ੍ਹਾਂ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਨੇ ਲਾਗਤ-ਬਚਤ ਤਕਨੀਕ ਤੋਂ ਸਟੈਂਡਰਡ ਪ੍ਰੈਕਟਿਸ ਤੱਕ ਕਦਮ ਚੁੱਕਿਆ—ਅਤੇ ਇਹ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਕੰਟਰੋਲ ਪਲੇਨ ਬਣਨ ਦਾ ਮੰਚ ਤਿਆਰ ਕੀਤਾ।
ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਮੁੱਖਤੌਰ 'ਤੇ ਜ਼ਿਆਦਾ ਵਰਕਲੋਡਾਂ ਨੂੰ ਘੱਟ ਸਰਵਰਾਂ 'ਤੇ ਚਲਾਉਣ ਦਾ ਇੱਕ ਤਰੀਕਾ ਸੀ। ਪਰ ਜਦ ਜ਼ਿਆਦਾਤਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਇੱਕ ਸਾਂਝੇ ਵਰਚੁਅਲ ਪਲੇਟਫਾਰਮ 'ਤੇ ਆ ਗਈਆਂ, ਤਾਂ "ਜਿਸ ਥਾਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਕਲਿੱਕ ਕਰਦੇ ਹੋ" ਓਥੇ ਫੈਸਲੇ ਲਾਗੂ ਹੋਣਾ ਸ਼ੁਰੂ ਹੋ ਗਿਆ। ਇਸੀ ਤਰ੍ਹਾਂ ਇੱਕ ਹਾਇਪਰਵਾਈਜ਼ਰ ਸਟੈਕ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਕੰਟਰੋਲ ਪਲੇਨ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ।
ਆਈਟੀ ਟੀਮਾਂ ਸਿਰਫ਼ "ਕੰਪਿਊਟ" ਹੀ ਨਹੀਂ ਮੈਨੇਜ ਕਰਦੀਆਂ। ਰੋਜ਼ਾਨਾ ਓਪਰੇਸ਼ਨ ਇਹਨਾਂ ਖੇਤਰਾਂ 'ਤੇ ਫੈਲਦਾ ਹੈ:
ਜੇ ਇਹ ਪਰਤਾਂ ਇੱਕ ਕੰਸੋਲ ਤੋਂ ਸੰਗਠਿਤ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਅਮਲੀ ਰੂਪ ਵਿੱਚ ਓਪਰੇਸ਼ਨਾਂ ਦਾ ਕੇਂਦਰ ਬਣ ਜਾਂਦਾ ਹੈ—ਭਾਵੇਂ ਹਾਰਡਵੇਅਰ ਵੱਖਰਾ ਹੋਵੇ।
ਇੱਕ ਮੁੱਖ ਬਦਲਾਅ ਇਹ ਹੈ ਕਿ ਪ੍ਰੋਵੀਜ਼ਨਿੰਗ ਨੀਤੀ-ਚਲਿਤ ਹੋ ਜਾਂਦੀ ਹੈ। "ਸਰਵਰ ਬਣਾਓ" ਦੀ ਥਾਂ, ਟੀਮਾਂ ਗਾਰਡਰੇਲ ਬਣਾਉਂਦੀਆਂ ਹਨ: ਮਨਜ਼ੂਰ ਟੀਮਪਲੇਟ, ਸਾਈਜ਼ ਲਿਮਿਟ, ਨੈੱਟਵਰਕ ਜੋਨ, ਬੈਕਅੱਪ ਨਿਯਮ, ਅਤੇ ਅਨੁਮਤੀਆਂ। ਬੇਨਤੀਆਂ ਸਟੈਂਡਰਡ ਨਤੀਜਿਆਂ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀਆਂ ਹਨ।
ਇਸੇ ਕਾਰਨ vCenter ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਡੇਟਾ ਸੈਂਟਰ ਲਈ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਵਰਗੇ ਕੰਮ ਕਰਨ ਲੱਗਦੇ ਹਨ: ਨਹੀਂ ਕਿਉਂਕਿ ਉਹ ਤੁਹਾਡੇ ਐਪ ਚਲਾਉਂਦੇ ਹਨ, ਬਲਕਿ ਕਿਉਂਕਿ ਉਹ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਐਪ ਕਿਵੇਂ ਬਣੇ, ਕਿੱਥੇ ਰੱਖੇ, ਸੁਰੱਖਿਅਤ ਕੀਤੇ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਕੀਤੇ ਜਾਣ।
ਟੈਮਪਲੇਟ, ਗੋਲਡਨ ਇਮੇਜ, ਅਤੇ ਆਟੋਮੇਸ਼ਨ ਪਾਈਪਲਾਈਨ ਚੁਪਚਾਪ ਵਿਹਾਰਾਂ ਨੂੰ ਲਾਕ ਕਰ ਦਿੰਦੀਆਂ ਹਨ। ਜਦ ਟੀਮਾਂ ਇੱਕ VM ਟੈਮਪਲੇਟ, ਟੈਗਿੰਗ ਸਕੀਮ, ਜਾਂ ਪੈਚਿੰਗ/ਰਿਕਵਰੀ ਲਈ ਵਰਕਫਲੋ 'ਤੇ ਸਟੈਂਡਰਡ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਇਹ ਵਿਭਾਗਾਂ 'ਚ ਫੈਲ ਜਾਂਦਾ ਹੈ। ਸਮੇਂ ਦੇ ਨਾਲ, ਪਲੇਟਫਾਰਮ ਸਿਰਫ਼ ਵਰਕਲੋਡ ਹੋਸਟ ਨਹੀਂ ਕਰ ਰਿਹਾ—ਇਹ ਓਪਰੇਟਿੰਗ ਆਦਤਾਂ ਨੂੰ ਗਿਆਤੀ ਵਿੱਚ ਰੱਖ ਰਿਹਾ ਹੈ।
ਜਦ ਇੱਕ ਕੰਸੋਲ "ਸਭ ਕੁਝ" ਚਲਾਉਂਦਾ ਹੈ, ਤਾਂ ਕੇਂਦਰ ਸਰਵਰਾਂ ਤੋਂ ਗਵਰਨੈਂਸ ਵੱਲ ਮੁੜ ਜਾਂਦਾ ਹੈ: ਮਨਜ਼ੂਰੀਆਂ, ਅਨੁਕੂਲਤਾ ਸਬੂਤ, ਫਰਜ਼ਾਂ ਦਾ ਵਰਤਾਅ ਵਿਭਾਜਨ, ਅਤੇ ਚੇਂਜ ਕਨਟਰੋਲ। ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਮਲਕੀਅਤ ਜਾਂ ਰਣਨੀਤੀ ਬਦਲਣ ਨਾਲ ਸਿਰਫ਼ ਕੀਮਤ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਹੁੰਦੀ—ਇਹ ਇਸ ਗੱਲ ਨੂੰ ਵੀ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ ਕਿ ਆਈਟੀ ਕਿਵੇਂ ਚੱਲਦੀ ਹੈ, ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੇ ਸਕਦੀ ਹੈ, ਅਤੇ ਕਿਵੇਂ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਬਦਲ ਕਰ ਸਕਦੀ ਹੈ।
ਜਦ ਲੋਕ VMware ਨੂੰ "ਕੰਟਰੋਲ ਪਲੇਨ" ਕਹਿੰਦੇ ਹਨ, ਉਹ ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਲੈਂਦੇ ਕਿ ਇਹ ਸਿਰਫ਼ VM ਚਲਾਉਂਦਾ ਹੈ। ਉਹ ਇਸਦਾ ਮਤਲਬ ਇਹ ਲੈਂਦੇ ਹਨ ਕਿ ਇਹ ਓਥੇ ਹੈ ਜਿੱਥੇ ਰੋਜ਼ਾਨਾ ਕੰਮ ਸੁਚਾਰੂ ਹੁੰਦਾ ਹੈ: ਕੌਣ ਕੀ ਕਰ ਸਕਦਾ ਹੈ, ਕੀ ਬਦਲਣਾ ਸੁਰੱਖਿਅਤ ਹੈ, ਅਤੇ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਕਿਵੇਂ ਖੋਜਿਆ ਅਤੇ ਠੀਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਆਈਟੀ ਦੀ ਕੋਸ਼ਿਸ਼ ਮੁੱਖ ਤੌਰ 'ਤੇ ਮੁੱਖ ਡਿਪਲੋਇਮੈਂਟ ਤੋਂ ਬਾਅਦ ਹੁੰਦੀ ਹੈ। ਇੱਕ VMware ਵਾਤਾਵਰਨ ਵਿੱਚ, ਕੰਟਰੋਲ ਪਲੇਨ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ Day‑2 ਓਪਰੇਸ਼ਨ ਵੱਸਦੇ ਹਨ:
ਕਿਉਂਕਿ ਇਹ ਕੰਮ ਕੇਂਦਰੀਕ੍ਰਿਤ ਹਨ, ਟੀਮਾਂ ਇਨ੍ਹਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੁਹਰਾਯੋਗ ਰਨਬੁੱਕ ਬਣਾਉਂਦੀਆਂ ਹਨ—ਚੇਂਜ ਵਿੰਡੋ, ਮਨਜ਼ੂਰੀ ਕਦਮ, ਅਤੇ "ਪਛਾਣੇ ਹੋਏ ਚੰਗੇ" ਸੀਕੁਐਂਸ।
ਸਮੇਂ ਦੇ ਨਾਲ, VMware ਦੀ ਜਾਣਕਾਰੀ ਓਪਰੇਸ਼ਨਲ ਮਾਨਸਿਕ ਯਾਦ ਰੂਪ ਹੋ ਜਾਂਦੀ ਹੈ: ਨਾਮਕਰਨ ਮਿਆਰ, ਕਲਸਟਰ ਡਿਜ਼ਾਈਨ ਪੈਟਰਨ, ਅਤੇ ਰਿਕਵਰੀ ਡ੍ਰਿੱਲ। ਇਹ ਬਦਲਣਾ ਮੁਸ਼ਕਲ ਹੈ—ਨਾ ਕਿ ਇਸ ਲਈ ਕਿ ਵਿਕਲਪ ਨਹੀਂ ਹਨ, ਪਰ ਇਸ ਲਈ ਕਿ ਸਥਿਰਤਾ ਜੋਖਮ ਘਟਾਉਂਦੀ ਹੈ। ਨਵਾਂ ਪਲੇਟਫਾਰਮ ਆਮ ਤੌਰ 'ਤੇ ਐਜ ਕੇਸਾਂ, ਰਨਬੁੱਕਸ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਅਤੇ ਦਬਾਅ ਹੇਠਾਂ ਧਾਰਨਾਵਾਂ ਨੂੰ ਦੁਬਾਰਾ ਵੈਰੀਫਾਈ ਕਰਨ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ।
ਆਊਟੇਜ ਦੌਰਾਨ, ਰਿਸਪਾਂਡਰ ਕੰਟਰੋਲ ਪਲੇਨ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ:
ਜੇ ਇਹ ਵਰਕਫਲੋ ਬਦਲਦੇ ਹਨ, ਤਾਂ ਮੀਨ ਟਾਈਮ ਟੂ ਰਿਕਵਰੀ (MTTR) ਵੀ ਬਦਲ ਸਕਦਾ ਹੈ।
ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਅਕਸਰ ਅਕੇਲਾ ਨਹੀਂ ਹੁੰਦੀ। ਬੈਕਅੱਪ, ਮਾਨੀਟਰਨਿੰਗ, ਡੀਜ਼ਾਸਟਰ ਰਿਕਵਰੀ, ਕੰਫਿਗਰੇਸ਼ਨ ਮੈਨੇਜਮੈਂਟ, ਅਤੇ ਟਿਕਟਿੰਗ ਸਿਸਟਮ vCenter ਅਤੇ ਉਸ ਦੀਆਂ APIs ਨਾਲ ਘਣੀ ਤਰ੍ਹਾਂ ਇੰਟੀਗਰੇਟ ਕਰਦੇ ਹਨ। DR ਯੋਜਨਾਵਾਂ ਖਾਸ ਰੀਪਲੀਕੇਸ਼ਨ ਵਰਤਾਵ ਦੀ ਉਮੀਦ ਰੱਖ ਸਕਦੀਆਂ ਹਨ; ਬੈਕਅੱਪ ਕੰਮ ਸਨੇਪਸ਼ੌਟ 'ਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦਾ ਹੈ; ਮਾਨੀਟਰਨਿੰਗ ਟੈਗਸ ਅਤੇ ਫੋਲਡਰਾਂ 'ਤੇ ਆਧਾਰਿਤ ਹੋ ਸਕਦੀ ਹੈ। ਜਦੋਂ ਕੰਟਰੋਲ ਪਲੇਨ ਬਦਲਦਾ ਹੈ, ਇਹ ਇੰਟੀਗਰੇਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਪਹਿਲਾਂ "ਹੈਰਾਨੀ" ਹੁੰਦੇ ਹਨ—ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਦਾ ਇਨਵੈਂਟਰੀ ਅਤੇ ਟੈਸਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਜਦ ਕੋਈ ਐਸਾ ਪਲੇਟਫਾਰਮ ਜਿਸਦਾ ਕੇਂਦਰਾ ਹੈ vSphere/ vCenter ਮਾਲਕ ਬਦਲਦਾ ਹੈ, ਤਕਨੀਕ ਇੱਕ ਰਾਤ ਵਿੱਚ ਟੁੱਟਦੀ ਨਹੀਂ। ਜੋ ਪਹਿਲਾਂ ਬਦਲਦਾ ਹੈ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਵਪਾਰਕ ਲਪੇਟ ਹੁੰਦੀ ਹੈ: ਤੁਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਖਰੀਦਦੇ ਹੋ, ਕਿਵੇਂ ਰੀਨਿਊ ਕਰਦੇ ਹੋ, ਅਤੇ "ਆਮ" ਕੀ ਹੁੰਦਾ ਹੈ।
ਕਈ ਟੀਮਾਂ vSphere ਅਤੇ vCenter ਤੋਂ ਵੱਡਾ ਓਪਰੇਸ਼ਨਲ ਮੁੱਲ ਹਾਸਲ ਕਰਦੀਆਂ ਹਨ—ਸਟੈਂਡਰਡਾਇਜ਼ਡ ਪ੍ਰੋਵੀਜ਼ਨਿੰਗ, ਸਥਿਰ ਓਪਰੇਸ਼ਨ, ਅਤੇ ਜਾਣੂ ਟੂਲਚੇਨ। ਇਹ ਮੁੱਲ ਜ਼ਿਆਦਾਤਰ ਵਿੱਚ ਸਥਿਰ ਰਹਿ ਸਕਦਾ ਹੈ ਭਾਵੇਂ ਵਪਾਰਕ ਸ਼ਰਤ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਣ।
ਇਸਨੂੰ ਦੋ ਵੱਖਰੇ ਗੱਲ-ਬਾਤਾਂ ਵਜੋਂ ਸੋਚੋ:
ਨਵੀਂ ਮਲਕੀਅਤ ਅਕਸਰ ਕੈਟਲੌਗ ਨੂੰ ਸਧਾਰਨ ਕਰਨ, ਔਸਤ ਕਰਾਰ ਮੁੱਲ ਵਧਾਉਣ, ਜਾਂ ਗਾਹਕਾਂ ਨੂੰ ਘੱਟ ਬੰਡਲਾਂ ਵਿੱਚ ਭੇਜਣ ਦਾ ਮੰਗ ਕਰਦੀ ਹੈ। ਇਹ ਬਦਲਾਅ ਤਰ੍ਹਾਂ-ਤਰ੍ਹਾਂ ਵਿੱਚ ਪ੍ਰਗਟ ਹੋ ਸਕਦਾ ਹੈ:
ਸਭ ਤੋਂ ਪ੍ਰਯੋਗਿਕ ਚਿੰਤਾ ਆਮ ਤੌਰ 'ਤੇ ਬੋoring ਪਰ ਅਸਲੀ ਹੁੰਦੀ ਹੈ: "ਅਗਲੇ ਸਾਲ ਇਹ ਕੀ ਖ਼ਰਚ ਹੋਏਗਾ?" ਅਤੇ "ਕੀ ਅਸੀਂ ਬਹੁ-ਸਾਲੀ ਪੇਸ਼ਗੀ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਾਂ?" ਫਾਇਨੈਂਸ ਨੂੰ ਸਥਿਰ ਅਨੁਮਾਨ ਚਾਹੀਦਾ ਹੈ; ਆਈਟੀ ਨੂੰ ਇਹ ਯਕੀਨ ਚਾਹੀਦਾ ਹੈ ਕਿ ਰੀਨਿਊਅਲ ਕਿਸੇ ਤੁਰੰਤ ਆਰਕੀਟੈਕਚਰਲ ਫੈਸਲੇ ਨੂੰ ਮਜ਼ਬੂਰ ਨਹੀਂ ਕਰੇਗਾ।
ਨੰਬਰਾਂ 'ਤੇ ਗੱਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਸਾਫ਼ ਫੈਕਟ-ਬੇਸ ਬਣਾਓ:
ਇਸ ਨਾਲ ਤੁਸੀਂ ਸਪਸ਼ਟਤਾ ਤੋਂ ਨਿਗੋਸ਼ੀਏਟ ਕਰ ਸਕਦੇ ਹੋ—ਚਾਹੇ ਤੁਹਾਡਾ ਯੋਜਨਾ ਰਹਿਣੀ ਹੋ, ਵਿਭਿੰਨ ਕਰਨੀ ਹੋ, ਜਾਂ ਮਾਈਗ੍ਰੇਟ ਦੀ ਤਿਆਰੀ।
ਜਦੋਂ ਇੱਕ ਪਲੇਟਫਾਰਮ ਵਿੱਕਰੇਤਾ ਆਪਣੀ ਰਣਨੀਤੀ ਬਦਲਦਾ ਹੈ, ਪਹਿਲਾ ਅਸਰ ਕਈ ਟੀਮਾਂ ਨੂੰ ਨਵੀਂ ਫੀਚਰ ਨਹੀਂ, ਪਰ ਨਵਾਂ ਖਰੀਦਣ ਅਤੇ ਯੋਜਨਾ ਬਣਾਉਣ ਦਾ ਤਰੀਕਾ ਹੋਵੇਗਾ। VMware ਗਾਹਕ ਜੋ Broadcom ਦੀ ਦਿਗਦੀਸ਼ਾ ਨੂੰ ਦੇਖ ਰਹੇ ਹਨ, ਉਹਨਾਂ ਲਈ ਅਮਲੀ ਪ੍ਰਭਾਵ ਅਕਸਰ ਬੰਡਲਸ, ਰੋਡਮੈਪ ਪ੍ਰਾਇਓਰਟੀਜ਼, ਅਤੇ ਕਿਹੜੇ ਉਤਪਾਦ ਨੂੰ ਵੱਧ ਧਿਆਨ ਮਿਲਦਾ ਹੈ—ਇਨ੍ਹਾਂ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ।
ਬੰਡਲ ਕਈ ਵਾਰ ਸਹਾਇਕ ਹੋ ਸਕਦੇ ਹਨ: ਘੱਟ SKUs, ਘੱਟ ਡਿੱਦ-ਕਿਆ ਅਸੀਂ ਸਹੀ ਐਡ-ਆਨ ਖਰੀਦੇ? ਗੱਲਬਾਤਾਂ, ਅਤੇ ਟੀਮਾਂ ਵਿੱਚ ਵੱਧ ਸਟੈਂਡਰਡਾਈਜ਼ੇਸ਼ਨ।
ਟਰੇਡ-ਆਫ਼ ਲਚੀਲਾਪਨ ਹੈ। ਜੇ ਬੰਡਲ ਵਿੱਚ ਉਹ ਹਿੱਸੇ ਸ਼ਾਮਲ ਹਨ ਜੋ ਤੁਸੀਂ ਵਰਤਦੇ ਨਹੀਂ (ਜਾਂ ਜਿਹਨਾਂ 'ਤੇ ਸਟੈਂਡਰਡ ਹੋਣਾ ਨਹੀਂ ਚਾਹੁੰਦੇ), ਤਾਂ ਤੁਸੀਂ ਸ਼ੈਲਫਵੇਅਰ ਲਈ ਭੁਗਤਾਨ ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ ਇੱਕ "ਇੱਕ ਆਕਾਰ ਸਭ ਲਈ" ਆਰਕੀਟੈਕਚਰ ਵੱਲ ਧਕੇ ਜਾ ਸਕਦੇ ਹੋ। ਬੰਡਲ ਜ਼ਰੀਏ ਆਹਰ ਅਲਟਰਨੇਟਿਵ ਪਾਈਲਟਾਂ ਨੂੰ ਧੀਰੇ ਲੈ ਕੇ ਅਪਣਾਉਣਾ ਮੁਸ਼ਕਲ ਕਰ ਸਕਦੇ ਹਨ—ਕਿਉਂਕਿ ਹੁਣ ਤੁਸੀਂ ਸਿਰਫ਼ ਉਹ ਟੁਕੜਾ ਨਹੀਂ ਖਰੀਦ ਰਹੇ।
ਉਤਪਾਦ ਰੋਡਮੈਪ ਆਮ ਤੌਰ 'ਤੇ ਉਨ੍ਹਾਂ ਗਾਹਕ ਸੈਗਮੈਂਟਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹਨ ਜੋ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਆਮਦਨ ਅਤੇ ਰੀਨਿਊਅਲ ਲਿਆਉਂਦੇ ਹਨ। ਇਸਦਾ ਮਤਲਬ ਹੋ ਸਕਦਾ ਹੈ:
ਇਸ ਵਿੱਚ ਕੋਈ ਕੁਝ ਮਾੜਾ ਨਹੀਂ—ਪਰ ਇਹ ਬਦਲਾਅ ਇਹ ਤੁਹਾਡੇ ਅੱਪਗਰੇਡ ਅਤੇ ਨਿਰਭਰਤਾਵਾਂ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣ ਦੇ ਤਰੀਕੇ ਨੂੰ ਬਦਲ ਦੇਣਗੇ।
ਜੇ ਕੁਝ ਸਮਰੱਥਾਵਾਂ ਦੀ ਪ੍ਰਾਥਮਿਕਤਾ ਘੱਟ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਗੈਪ ਭਰਨ ਲਈ ਪੋਇੰਟ ਸੋਲੂਸ਼ਨਾਂ ਨਾਲ ਭਰ ਜਾਂਦੀਆਂ ਹਨ (ਬੈਕਅੱਪ, ਮਾਨੀਟਰਨਿੰਗ, ਸੁਰੱਖਿਆ, ਆਟੋਮੇਸ਼ਨ)। ਇਹ ਤੁਰੰਤ ਸਮੱਸਿਆ ਹੱਲ ਕਰ ਸਕਦਾ ਹੈ ਪਰ ਲੰਬੇ ਸਮੇਂ ਵਿੱਚ ਟੂਲ ਸਪ੍ਰਾਲ ਬਣਾਉਂਦਾ ਹੈ: ਹੋਰ ਕਨਸੋਲ, ਹੋਰ ਠੇਕੇ, ਹੋਰ ਇੰਟੀਗਰੇਸ਼ਨ ਜਿਸ ਨੂੰ ਮੇਂਟੇਨ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਅਤੇ ਹੋਰ ਥਾਂਆਂ ਜਿੱਥੇ ਘਟਨਾਵਾਂ ਛੁਪ ਸਕਦੀਆਂ ਹਨ।
ਸਪਸ਼ਟ ਵਚਨ ਅਤੇ ਸਰਹੱਦਾਂ ਮੰਗੋ:
ਇਹ ਉੱਤਰ "रणਨੀਤੀ ਬਦਲਾਅ" ਨੂੰ ਬਜਟ, ਸਟਾਫ਼ਿੰਗ ਅਤੇ ਜੋਖਮ ਲਈ ਵਿਸ਼ੇਸ਼ ਯੋਜਨਾਵਾਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰਦੇ ਹਨ।
ਜਦ VMware ਨੂੰ ਕੰਟਰੋਲ ਪਲੇਨ ਵਜੋਂ ਤੋਲਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਲਾਇਸੰਸ ਜਾਂ ਪੈਕੇਜਿੰਗ ਦਾ ਬਦਲਾਅ ਸਿਰਫ਼ ਪ੍ਰਕੁਰਮੈਂਟ ਤੱਕ ਨਾ ਰਹਿੰਦਾ। ਇਹ ਆਈਟੀ ਵਿੱਚ ਵਰਕ ਫਲੋਅ ਨੂੰ ਬਦਲਦਾ ਹੈ: ਕੌਣ ਚੇਂਜ ਮਨਜ਼ੂਰ ਕਰ ਸਕਦਾ ਹੈ, ਵਾਤਾਵਰਨ ਕਿਵੇਂ ਤੇਜ਼ੀ ਨਾਲ ਮੁਹੱਈਆ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਟੀਮਾਂ ਵਿੱਚ "ਸਟੈਂਡਰਡ" ਦਾ ਮਤਲਬ ਕੀ ਹੈ।
ਪਲੇਟਫਾਰਮ ਐਡਮਿਨਿਸਟ੍ਰੇਟਰ ਪਹਿਲੇ ਪ੍ਰਭਾਵ ਦਾ ਅਹਿਸਾਸ ਕਰਦੇ ਹਨ। ਜੇ ਅਧਿਕਾਰ ਇੱਕੋ-ਦਰਜੇ ਬੰਡਲ ਵਿੱਚ ਸਧਾਰਨ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਦਿਨ-ਚਰਿਆ ਓਪਰੇਸ਼ਨ ਘੱਟ ਲਚੀਲੇ ਹੋ ਸਕਦੇ ਹਨ: ਉਹ ਫੀਚਰ ਜਿਸ ਨੂੰ ਪਹਿਲਾਂ "ਉੱਥੇ ਹੀ" ਸਮਝਿਆ ਜਾਂਦਾ ਸੀ, ਹੁਣ ਵਾਲੀ ਕੁਝ ਅੰਦਰੂਨੀ ਮਨਜ਼ੂਰੀ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ, ਜਾਂ ਤੁਹਾਡੇ ਕੋਲ ਘੱਟ ਕਨਫਿਗਰੇਸ਼ਨ ਤੇ ਸਟੈਂਡਰਡ ਹੋ ਸਕਦੇ ਹਨ।
ਇਹ ਆਡਮਿਨ ਵਰਕਲੋਡ ਵਧ ਜਾਣ ਦੇ ਰੂਪ ਵਿੱਚ ਦਿਖਾਈ ਦੇ ਸਕਦਾ ਹੈ—ਲਾਇਸੈਂਸ ਚੈੱਕ ਪ੍ਰਾਜੈਕਟ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ, ਅਪਗਰੇਡ ਸੰਗਠਿਤ ਕਰਨ ਲਈ ਤੇਜ਼ ਚੇਂਜ ਵਿੰਡੋ, ਅਤੇ ਪੈਚਿੰਗ ਅਤੇ ਕਨਫਿਗਰੇਸ਼ਨ ਡ੍ਰਿਫਟ 'ਤੇ ਸੁਰੱਖਿਆ ਅਤੇ ਐਪ ਟੀਮਾਂ ਨਾਲ ਵੱਧ ਸਹਯੋਗ।
ਐਪ ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਉਪਟਾਈਮ 'ਤੇ ਮਾਪੇ ਜਾਂਦੇ ਹਨ, ਪਰ ਪਲੇਟਫਾਰਮ ਬਦਲਾਅ ਮੂਲ ਧਾਰਣਾਵਾਂ ਬਦਲ ਸਕਦਾ ਹੈ। ਜੇ ਕਲਸਟਰ ਰੀਬੈਲੈਂਸ ਹੋਦੇ ਹਨ, ਹੋਸਟ ਗਿਣਤੀ ਬਦਲਦੀ ਹੈ, ਜਾਂ ਨਵੇਂ ਅਧਿਕਾਰਾਂ ਦੇ ਮੁਤਾਬਿਕ ਫੀਚਰ ਵਰਤੋਂ ਨੂੰ ਢਾਲਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਐਪ ਮਾਲਕਾਂ ਨੂੰ ਸਮਭਵ ਹੈ ਕਿ ਉਹ ਮਿਲਾਪਤਾ ਦੁਬਾਰਾ ਟੈਸਟ ਕਰਨ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਦੁਬਾਰਾ ਬੇਸਲਾਈਨ ਕਰਨ।
ਇਹ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਵਰਕਲੋਡਾਂ ਲਈ ਸਚ ਹੈ ਜੋ ਖਾਸ ਸਟੋਰੇਜ਼, ਨੈੱਟਵਰਕਿੰਗ, ਜਾਂ HA/DR ਵਰਤਾਵ ਤੇ ਨਿਰਭਰ ਹਨ। ਪ੍ਰਯੋਗਿਕ ਨਤੀਜਾ: ਵੱਧ ਸਰਚਨਾ ਵਾਲੇ ਟੈਸਟ ਸਾਈਕਲ ਅਤੇ "ਇਸ ਐਪ ਨੂੰ ਕੀ ਲੋੜ ਹੈ" ਦੀ ਸਪਸ਼ਟ ਦਸਤਾਵੇਜ਼ੀਕਰਨ।
ਜੇ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਲੇਅਰ ਤੁਹਾਡਾ ਸਿਗਮੈਂਟੇਸ਼ਨ, ਪ੍ਰਿਵਿਲੇਜਡ ਪਹੁੰਚ, ਅਤੇ ਆਡਿਟ ਟਰੇਲ ਲਾਗੂ ਕਰਨ ਦਾ ਬਿੰਦੂ ਹੈ, ਤਾਂ ਕੋਈ ਵੀ ਟੂਲਿੰਗ ਜਾਂ ਸਥਿਰ-ਕਨਫਿਗਰੇਸ਼ਨ ਬਦਲਾਅ ਅਨੁਕੂਲਤਾ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।
ਸੁਰੱਖਿਆ ਟੀਮਾਂ ਵੱਧ ਸਪਸ਼ਟ ਫਰਜ਼-ਵੰਡ, ਲਾਗ ਰੱਖਣ ਦੇ ਸਮੇਂ, ਅਤੇ ਘੱਟ "ਅਪਵਾਦ" ਕੰਫਿਗਰੇਸ਼ਨਾਂ ਦੀ ਮੰਗ ਕਰਨਗੀਆਂ। ਆਈਟੀ ਟੀਮਾਂ ਨੂੰ ਵੱਧ ਰਸਮੀਕ੍ਰਿਤ ਐਕਸੈਸ ਸਮੀਖਿਆਆਂ ਅਤੇ ਚੇਂਜ ਰਿਕਾਰਡ ਦੀ ਉਮੀਦ ਰੱਖਣੀ ਚਾਹੀਦੀ ਹੈ।
ਭਾਵੇਂ ਟਿੱਪਣੀ ਕੀਮਤ ਮੁੱਖ ਕਾਰਣ ਹੋਵੇ, ਪ੍ਰਭਾਵ ਓਪਰੇਸ਼ਨਲ ਹੁੰਦਾ ਹੈ: ਚਾਰਜੇਬੈਕ/ਸ਼ੋਅਬੈਕ ਮਾਡਲ ਅਪਡੇਟ ਹੋ ਸਕਦੇ ਹਨ, ਲਾਗਤ ਕੇਂਦਰ ਉਹ ਚੀਜ਼ਾਂ ਮੁੜ-ਵਿਵਹਾਰ ਕਰ ਸਕਦੇ ਹਨ ਜੋ ਉਹ "ਸ਼ਾਮਲ" ਮੰਨਦੇ ਸਨ, ਅਤੇ ਅਨੁਮਾਨ ਸੰਯੋਜਨ ਪਲੇਟਫਾਰਮ ਟੀਮਾਂ ਨਾਲ ਸਹਯੋਗ ਬਣਾਉਣਾ ਬਣ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਚੰਗਾ ਸੰਕੇਤ ਕਿ ਤੁਸੀਂ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਕੰਟਰੋਲ ਪਲੇਨ ਵਜੋਂ ਸਮਝਦੇ ਹੋ, ਉਹ ਹੈ ਕਿ ਆਈਟੀ ਅਤੇ ਫਾਈਨੈਂਸ ਮਿਲ ਕੇ ਯੋਜਨਾ ਬਣਾਉਂਦੇ ਹਨ, ਨਾ ਕਿ ਰੀਨਿਊਅਲ ਦੇ ਬਾਅਦ ਹੈਰਾਨੀ ਕਰਦੇ ਹਨ।
ਜਦੋ ਇੱਕ ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ VMware ਮਲਕੀਅਤ ਅਤੇ ਰਣਨੀਤੀ ਬਦਲਦਾ ਹੈ, ਸਭ ਤੋਂ ਵੱਡੇ ਜੋਖਮ ਆਮ ਤੌਰ 'ਤੇ IT ਦੇ "ਸ਼ਾਂਤ" ਹਿੱਸਿਆਂ ਵਿੱਚ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ: ਲਗਾਤਾਰਤਾ ਯੋਜਨਾਵਾਂ, ਸਪੋਰਟ ਉਮੀਦਾਂ, ਅਤੇ ਦਿਨ-ਪ੍ਰਤੀ-ਦਿਨ ਓਪਰੇਸ਼ਨਲ ਸੁਰੱਖਿਆ। ਭਾਵੇਂ ਕੁਝ ਤੁਰੰਤ ਟੁੱਟੇ ਨਾਂ, ਉਹ ਧਾਰਣਾਵਾਂ ਜਿਨ੍ਹਾਂ ਉੱਤੇ ਤੁਸੀਂ ਸਾਲਾਂ ਤੱਕ ਨਿਰਭਰ ਕਰਦੇ ਆਏ ਹੋ, ਬਦਲ ਸਕਦੀਆਂ ਹਨ।
ਇੱਕ ਵੱਡਾ ਪਲੇਟਫਾਰਮ ਬਦਲਾਅ ਬੈਕਅੱਪ, ਡੀਜ਼ਾਸਟਰ ਰਿਕਵਰੀ, ਅਤੇ ਰਿਟੇੰਸ਼ਨ 'ਤੇ ਸੁਇਚ-ਅਸਰ ਛੱਡ ਸਕਦਾ ਹੈ। ਬੈਕਅੱਪ ਉਤਪਾਦ ਖਾਸ APIs, vCenter ਅਨੁਮਤੀਆਂ, ਜਾਂ ਸਨੇਪਸ਼ੌਟ ਵਿਵਹਾਰ 'ਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦੇ ਹਨ। DR ਰਨਬੁੱਕ ਅਕਸਰ ਕੁਝ ਕਲਸਟਰ ਫੀਚਰ, ਨੈੱਟਵਰਕ ਨਿਰਧਾਰ, ਅਤੇ ਆਰਕੀਸਟ੍ਰੇਸ਼ਨ ਕਦਮਾਂ ਦੀ ਉਮੀਦ ਰੱਖਦੇ ਹਨ। ਜੇ ਸਟੋਰੇਜ਼ ਇੰਟੀਗਰੇਸ਼ਨਾਂ ਜਾਂ ਆਰਕਾਈਵ ਵਰਕਫਲੋ ਬਦਲਦੇ ਹਨ, ਤਾਂ ਰਿਟੇੰਸ਼ਨ ਯੋਜਨਾ ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦੀ ਹੈ।
ਕਰਮਾਤਮਕ ਨਤੀਜਾ: ਆਪਣੀਆਂ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਸਿਸਟਮਾਂ (ਟੀਅਰ 0 ਆਈਡੈਂਟੀਟੀ, ਮੈਨੇਜਮੈਂਟ ਟੂਲਿੰਗ, ਅਤੇ ਮੁੱਖ ਕਾਰੋਬਾਰੀ ਐਪਸ) ਲਈ ਏੰਡ-ਟੂ-ਏੰਡ ਰੀਸਟੋਰ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਵੈਰੀਫਾਈ ਕਰੋ—ਸਿਰਫ਼ ਬੈਕਅੱਪ ਸਫਲਤਾ ਨਹੀਂ।
ਆਮ ਜੋਖਮ ਖੇਤਰ ਠੇਕੇਦਾਰੀ ਦੀਆਂ ਲਗਾਤਾਰ ਚੀਜ਼ਾਂ ਹਨ, ਨਾਂ ਕੇਵਲ ਠੇਕੇ ਦੀਆਂ ਰੀਕਤੀ:
ਪ੍ਰਯੋਗਿਕ ਜੋਖਮ "ਅਣ-ਅਣਜਾਣੀਆਂ" ਤੋਂ ਡਾਉਨਟਾਈਮ ਹੈ, ਸਿਰਫ਼ ਵਧੀਕ ਲਾਗਤ ਨਹੀਂ।
ਜਦ ਇੱਕ ਪਲੇਟਫਾਰਮ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤੌਰ 'ਤੇ ਵਿਆਪਕ ਹੋ ਜਾਂਦਾ ਹੈ, ਤੁਸੀਂ ਸਟੈਂਡਰਡਾਈਜ਼ੇਸ਼ਨ, ਘੱਟ ਸਕਿਲਸ ਫੁੱਟਪ੍ਰਿੰਟ, ਅਤੇ ਇਕਸਾਰ ਟੂਲਿੰਗ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ। ਟਰੇਡ-ਆਫ਼ ਨਿਰਭਰਤਾ ਹੈ: ਜੇ ਲਾਇਸੰਸਿੰਗ, ਸਪੋਰਟ, ਜਾਂ ਉਤਪਾਦ ਧਿਆਨ ਬਦਲੇ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਬਚਣ ਲਈ ਘੱਟ ਰਸਤੇ ਹੁੰਦੇ ਹਨ। ਜਦ VMware ਨਿਰਭਰਤਾ ਨਾਂ ਸਿਰਫ਼ ਵਰਕਲੋਡਾਂ 'ਤੇ, ਬਲਕਿ ਆਈਡੈਂਟੀਟੀ, ਬੈਕਅੱਪ, ਲੌਗਿੰਗ, ਅਤੇ ਆਟੋਮੇਸ਼ਨ 'ਤੇ ਵੀ ਹੋਵੇ, ਤਾਂ ਇਕਾਗ੍ਰਤਾ ਜੋਖਮ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਵਧ ਜਾਂਦਾ ਹੈ।
ਤੁਸੀਂ ਜੋ ਕੁਝ ਚਲਾਉਂਦੇ ਹੋ ਉਸਦਾ ਦਸਤਾਵੇਜ਼ ਬਣਾਓ (ਵਰਜਨ, ਨਿਰਭਰਤਾਵਾਂ, ਅਤੇ ਇੰਟੀਗਰੇਸ਼ਨ ਪਾਇੰਟ), vCenter/ਐਡਮਿਨ ਰੋਲਸ ਲਈ ਐਕਸੈਸ ਸਮੀਖਿਆਆਂ ਤੰਗ ਕਰੋ, ਅਤੇ ਇੱਕ ਟੈਸਟਿੰਗ ਕੈਡੈਂਸ ਸੈੱਟ ਕਰੋ: ਤਿਮਾਹੀ ਰਿਕਵਰ ਟੈਸਟ, ਅੱਧ-ਸਾਲਿਕ DR ਅਭਿਆਸ, ਅਤੇ ਪ੍ਰੀ-ਅਪਗਰੇਡ ਵੈਰੀਫਿਕੇਸ਼ਨ ਚੈਕਲਿਸਟ ਜਿਸ ਵਿੱਚ ਹਾਰਡਵੇਅਰ ਸਮਰਥਨ ਅਤੇ ਤੀਸਰੇ-ਪਾਰਟੀ ਵਿੰਨ੍ਯਾਨਾਂ ਦੀ ਪੁਸ਼ਟੀ ਸ਼ਾਮਲ ਹੋਵੇ।
ਇਹ ਕਦਮ ਓਪਰੇਸ਼ਨਲ ਜੋਖਮ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ, ਚਾਹੇ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਦਿਸ਼ਾ 'ਚ ਜਾਓ।
VMware ਅਕਸਰ ਅਕੇਲਾ ਕੰਮ ਨਹੀਂ ਕਰਦਾ। ਬਹੁਤ ਸਾਰੇ ਵਾਤਾਵਰਨ ਇੱਕ ਜਾਲੀਦਾਰ ਹਾਰਡਵੇਅਰ ਵਿਕਰੇਤਾ, MSPs, ਬੈਕਅੱਪ ਪਲੇਟਫਾਰਮ, ਮਾਨੀਟਰਨਿੰਗ ਟੂਲ, ਸੁਰੱਖਿਆ ਏਜੰਟਸ, ਅਤੇ DR ਸੇਵਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਜਦ ਮਲਕੀਅਤ ਅਤੇ ਉਤਪਾਦ ਰਣਨੀਤੀ ਬਦਲਦੀ ਹੈ, ਤਾਂ "ਬਲਾਸਟ ਰੇਡੀਅਸ" ਆਮ ਤੌਰ 'ਤੇ ਇੱਕੋਸਿਸਟਮ ਵਿੱਚ ਪਹਿਲਾਂ ਦਿਖਦਾ ਹੈ—ਕਈ ਵਾਰੀ vCenter ਦੇ ਅੰਦਰ ਅਪਣੇ ਆਪ ਨੂੰ ਨੋਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ।
ਹਾਰਡਵੇਅਰ ਵਿਕਰੇਤਾ, MSPs, ਅਤੇ ISVs ਖਾਸ ਵਰਜਨਾਂ, ਐਡੀਸ਼ਨਾਂ, ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਪੈਟਰਨਾਂ ਨਾਲ ਆਪਣੇ ਸਪੋਰਟ ਨੂੰ ਮਿਲਾਉਂਦੇ ਹਨ। ਉਹਨਾਂ ਦੇ ਪ੍ਰਮਾਣੀਕਰਨ ਅਤੇ ਸਮਰਥਨ ਮੈਟਰਿਕਸ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਉਹ ਕੀ ਸੁਧਾਰ ਕਰਨਗੇ—ਅਤੇ ਕੀ ਨਹੀਂ।
ਇੱਕ ਲਾਇਸੈਂਸਿੰਗ ਜਾਂ ਪੈਕੇਜਿੰਗ ਬਦਲਾਅ ਅਣੋਖੇ ਤਰੀਕੇ ਨਾਲ ਅਪਗਰੇਡਾਂ ਨੂੰ ਜ਼ੋਰ ਦੇ ਸਕਦਾ ਹੈ (ਜਾਂ ਰੋਕ ਸਕਦਾ ਹੈ), ਜੋ ਫਿਰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਸਰਵਰ ਮਾਡਲ, HBA, NIC, ਸਟੋਰੇਜ਼ ਅਰੇ, ਜਾਂ ਬੈਕਅੱਪ ਪ੍ਰਾਕਸੀ ਸਮਰਥਿਤ ਸੂਚੀ 'ਚ ਰਹਿੰਦੇ ਹਨ ਜਾਂ ਨਹੀਂ।
ਕਈ ਤੀਸਰੇ-ਪਾਰਟੀ ਟੂਲ ਹਮੇਸ਼ਾ "ਪਰ ਸਾਕਟ", "ਪਰ ਹੋਸਟ", ਜਾਂ "ਪਰ VM" ਆਧਾਰ ਤੇ ਕੀਮਤ ਜਾਂ ਪੈਕੇਜ ਕੀਤਾ ਜਾਂਦੇ ਸਨ। ਜੇ ਪਲੇਟਫਾਰਮ ਦੀ ਵਪਾਰਕ ਮਾਡਲ ਬਦਲਦੀ ਹੈ, ਉਹ ਟੂਲ ਵੀ ਆਪਣੀ ਗਿਣਤੀ, ਫੀਚਰ-ਰਿਕੁਆਇਰਮੈਂਟ, ਜਾਂ ਸ਼ਾਮਲ ਇੰਟੀਗਰੇਸ਼ਨ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹਨ।
ਸਪੋਰਟ ਉਮੀਦਾਂ ਵੀ ਬਦਲ ਸਕਦੀਆਂ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਕੋਈ ISV ਨਿਰਧਾਰਤ API ਐਕਸੇਸ, ਪਲੱਗਇਨ ਅਨੁਕੂਲਤਾ, ਜਾਂ ਘੱਟੋ-ਘੱਟ vSphere/vCenter ਵਰਜਨ ਦੀ ਲੋੜ ਰੱਖ ਸਕਦਾ ਹੈ। ਸਮੇਂ ਦੇ ਨਾਲ, "ਇਹ ਪਹਿਲਾਂ ਕੰਮ ਕਰਦਾ ਸੀ" ਬਣ ਜਾਂਦਾ ਹੈ "ਇਹ ਇਸ ਵਰਜਨ ਤੇ ਅਤੇ ਇਸ ਟੀਅਰ ਤੇ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ"।
ਕੰਟੇਨਰ ਅਤੇ Kubernetes ਬਹੁਤ ਸਥਾਨਾਂ 'ਤੇ VM ਸਪ੍ਰਾਲ 'ਤੇ ਦਬਾਅ ਘਟਾ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਬਹੁਤ ਸਾਰੀਆਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ਾਂ ਵਿੱਚ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਦੀ ਲੋੜ ਖ਼ਤਮ ਨਹੀਂ ਕਰਦੇ। ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ VMs 'ਤੇ Kubernetes ਚਲਾਉਂਦੀਆਂ ਹਨ, ਵਰਚੁਅਲ ਨੈੱਟਵਰਕਿੰਗ ਅਤੇ ਸਟੋਰੇਜ਼ ਨੀਤੀਆਂ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਮੌਜੂਦਾ ਬੈਕਅੱਪ/DR ਪੈਟਰਨਾਂ ਵਰਤਦੀਆਂ ਹਨ।
ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕੰਟੇਨਰ ਟੂਲਿੰਗ ਅਤੇ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਲੇਅਰ ਵਿਚਕਾਰ ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ ਅਜੇ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ—ਖਾਸ ਕਰਕੇ ਪਹਿਚਾਣ, ਨੈੱਟਵਰਕਿੰਗ, ਸਟੋਰੇਜ਼, ਅਤੇ ਨਿਰੀਖਣ ਦੇ ਚਿਹਰਿਆਂ 'ਤੇ।
"ਰਹਿਣ, ਵਿਭਿੰਨ, ਜਾਂ ਮਾਈਗ੍ਰੇਟ" ਦੇ ਫੈਸਲੇ 'ਤੇ ਫ਼ੈਸਲਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ ਇੰਟੀਗਰੇਸ਼ਨ ਜੋ ਤੁਸੀਂ ਨਿਰਭਰ ਕਰਦੇ ਹੋ—ਬੈਕਅੱਪ, DR, ਮਾਨੀਟਰਨਿੰਗ, CMDB, ਵੇਲਨਰੇਬਿਲਿਟੀ ਸਕੈਨਿੰਗ, MFA/SSO, ਨੈੱਟਵਰਕ/ਸੁਰੱਖਿਆ ਓਵਰਲੇਜ਼, ਸਟੋਰੇਜ਼ ਪਲੱਗਇਨ, ਅਤੇ MSP ਰਨਬੁੱਕ—ਇਨਾਂ ਦੀ ਇੱਕ ਇਨਵੈਂਟਰੀ ਬਣਾਓ।
ਫਿਰ ਤਿੰਨ ਚੀਜ਼ਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ: ਅੱਜ ਕੀ ਸਮਰਥਿਤ ਹੈ, ਤੁਹਾਡੇ ਅੱਗਲੇ ਅਪਗਰੇਡ 'ਤੇ ਕੀ ਸਮਰਥਿਤ ਰਹੇਗਾ, ਅਤੇ ਕੀ ਅਣ-ਸਮਰਥਿਤ ਹੋ ਜਾਵੇਗਾ ਜੇ ਪੈਕੇਜਿੰਗ/ਲਾਇਸੰਸਿੰਗ ਬਦਲਾਅ ਤੁਸੀਂ ਡਿਪਲੋਇਮੈਂਟ ਜਾਂ ਮੈਨੇਜਮੈਂਟ ਦਾ ਤਰੀਕਾ ਬਦਲ ਦਿੰਦੇ ਹਨ।
ਜਦ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਤੁਹਾਡਾ ਦਿਨ-ਪ੍ਰਤੀ-ਦਿਨ ਕੰਟਰੋਲ ਪਲੇਨ ਹੈ, ਤਾਂ ਬਦਲਾਅ ਨੂੰ ਸਿਰਫ਼ ਇੱਕ "ਪਲੇਟਫਾਰਮ ਸਵੈਪ" ਨਹੀਂ ਮੰਨਿਆ ਜਾ ਸਕਦਾ। ਜ਼ਿਆਦਾਤਰ ਸੰਗਠਨ ਕਿਸੇ ਨਾ ਕਿਸੇ ਰਾਹ 'ਤੇ ਜਾਂਦੇ ਹਨ—ਅਕਸਰ ਇੱਕ ਨਾਲ-ਦੂਜੇ ਮਿਲਦੇ ਹਨ। ਆਮ ਤੌਰ 'ਤੇ ਚਾਰ ਰਾਹ ਹਨ—ਕਈ ਵਾਰੀ ਮਿਲ ਕੇ।
ਰਹਿਣਾ "ਕੁਝ ਵੀ ਨਹੀਂ ਕਰਨ" ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਆਮ ਤੌਰ 'ਤੇ ਇਨਵੈਂਟਰੀ ਤੰਗ ਕਰਨਾ, ਕਲਸਟਰ ਡਿਜ਼ਾਈਨ ਸਟੈਂਡਰਡ ਕਰਨਾ, ਅਤੇ Accidental sprawl ਦੂਰ ਕਰਨਾ ਤਾਂ ਕਿ ਤੁਸੀਂ ਜੋ ਕੁਝ ਚਲਾ ਰਹੇ ਹੋ ਉਸ ਦਾ ਹੀ ਭੁਗਤਾਨ ਕਰ ਰਹੇ ਹੋ।
ਜੇ ਤੁਹਾਡਾ ਮੁੱਖ ਲਕੜੀ ਲਾਗਤ ਨਿਯੰਤਰਣ ਹੈ, ਤਾਂ ਹੋਸਟਾਂ ਨੂੰ ਰਾਈਟ-ਸਾਈਜ਼ ਕਰਨਾ, ਘੱਟ ਵਰਤੇ ਕਲਸਟਰ ਘਟਾਉਣਾ, ਅਤੇ ਅਸਲ ਵਿੱਚ ਜਿਹੜੀਆਂ ਫੀਚਰਾਂ ਦੀ ਲੋੜ ਹੈ ਉਹ ਵੈਰੀਫਾਈ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੋ। ਜੇ ਲਕੜੀ ਲਚੀਲਾਪਨ ਹੈ, ਤਾਂ ਓਪਰੇਸ਼ਨਲ ਸਫਾਈ 'ਤੇ ਧਿਆਨ ਦਿਓ: ਪੈਚਿੰਗ ਕੈਡੈਂਸ, ਬੈਕਅੱਪ ਟੈਸਟਿੰਗ, ਅਤੇ ਦਸਤਾਵੇਜ਼ੀਕ੍ਰਿਤ ਰਿਕਵਰੀ ਕਦਮ।
ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਸਭ ਤੋਂ ਆਮ ਦਰਜ਼ੇ ਦਾ ਨਜ਼ਰੀਆ ਹੈ ਕਿਉਂਕਿ ਇਹ ਜੋਖਮ ਘਟਾਉਂਦਾ ਅਤੇ ਸਮਾਂ ਖ਼ਰੀਦਦਾ ਹੈ। ਆਮ ਕਾਰਵਾਈਆਂ ਵਿੱਚ ਪ੍ਰਬੰਧਕੀ ਡੋਮੇਨਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ, ਟੈਮਪਲੇਟ/ਸਨੇਪਸ਼ੌਟ ਸਾਫ਼ ਕਰਨਾ, ਅਤੇ ਸਟੋਰੇਜ਼/ਨੈੱਟਵਰਕ ਮਿਆਰਾਂ ਨੂੰ ਲਾਈਨ ਅਪ ਕਰਨਾ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ ਤਾਂ ਕਿ ਭਵਿੱਖੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਘੱਟ ਦਰਦਨਾਕ ਹੋਵੇ।
ਵਿਭਿੰਨਤਾ ਸਭ ਤੋਂ ਵਧੀਆ ਤਤਕਾਲ ਜ਼ੋਨਾਂ 'ਤੇ ਕੰਮ ਕਰਦੀ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਇਕ ਹੋਰ ਸਟੈਕ ਨੂੰ ਬਿਨਾਂ ਸਭ ਕੁਝ ਰੀ-ਪਲੇਟਫਾਰਮ ਕੀਤੇ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹੋ। ਆਮ ਰੂਪ ਵਿੱਚ ਇਹਨਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਲਕੜੀ ਆਮ ਤੌਰ 'ਤੇ ਵਿਕਰੇਤਾ ਵਿਭਿੰਨਤਾ ਜਾਂ ਚੁਸਤਤਾ ਹੁੰਦੀ ਹੈ—ਫੌਰੀ ਬਦਲ ਨਹੀਂ।
"ਮਾਈਗ੍ਰੇਟ" ਦਾ ਮਤਲਬ ਸਿਰਫ਼ VMs ਨੂੰ ਹਿਲਾਉਣਾ ਨਹੀਂ ਹੈ। ਪੂਰੇ ਬੰਡਲ ਦੀ ਯੋਜਨਾ ਬਣਾਓ: ਵਰਕਲੋਡ, ਨੈੱਟਵਰਕ (VLANs, ਰਾਊਟਿੰਗ, ਫਾਇਰਵਾਲ, ਲੋਡ ਬੈਲੈਂਸਰ), ਸਟੋਰੇਜ਼ (ਡੇਟਾਸਟੋਰ, ਰੀਪਲੀਕੇਸ਼ਨ), ਬੈਕਅੱਪ, ਮਾਨੀਟਰਨਿੰਗ, ਪਹਿਚਾਣ/ਪਹੁੰਚ, ਅਤੇ—ਅਕਸਰ ਅਨਮਾਨਿਤ—ਕੌਸ਼ਲ ਅਤੇ ਓਪਰੇਟਿੰਗ ਪ੍ਰਕਿਰਿਆਵਾਂ।
ਸ਼ੁਰੂ ਵਿੱਚ ਸਪਸ਼ਟ ਲਕੜੀਆਂ ਰੱਖੋ: ਕੀ ਤੁਸੀਂ ਕੀਮਤ, ਡਿਲਿਵਰੀ ਦੀ ਤੇਜ਼ੀ, ਜੋਖਮ ਘਟਾਉਣਾ, ਜਾਂ ਰਣਨੀਤਿਕ ਲਚੀਲਾਪਨ ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦੇ ਰਹੇ ਹੋ? ਸਾਫ਼ ਪ੍ਰਾਥਮਿਕਤਾਵਾਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਅਨੰਤ ਪੁਨਰ-ਨਿਰਮਾਣ ਵਿੱਚ ਨਹੀਂ ਬਦਲਣ ਦੇਂਦੀਆਂ।
ਜੇ VMware ਤੁਹਾਡਾ ਓਪਰੇਸ਼ਨਲ ਕੰਟਰੋਲ ਪਲੇਨ ਹੈ, ਤਾਂ VMware/Broadcom ਰਣਨੀਤੀ ਬਦਲਣ ਬਾਰੇ ਫੈਸਲੇ ਵਿਕਰੇਤਾ ਦੇ ਪ੍ਰੈਸ ਰਿਲੀਜ਼ ਨਾਲ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ—ਉਹ ਤੁਹਾਡੇ ਵਾਤਾਵਰਨ ਨਾਲ ਸ਼ੁਰੂ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਅਗਲੇ 6–18 ਮਹੀਨੇ ਵਿੱਚ, ਧਿਆਨ ਇਹ ਹੋਵੇ ਕਿ ਧਾਰਣਾਵਾਂ ਨੂੰ ਮਾਪੇ-ਯੋਗ ਤੱਥਾਂ ਨਾਲ ਬਦਲੋ, ਫਿਰ ਜੋਖਮ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਮਿਲਾਪ ਅਨੁਸਾਰ ਰਾਹ ਚੁਣੋ।
ਇੱਕ ਇਨਵੈਂਟਰੀ ਬਣਾਓ ਜਿਸ 'ਤੇ ਤੁਹਾਡੇ ਓਪਰੇਸ਼ਨ ਟੀਮ ਕਿਸੇ ਘਟਨਾ ਦੌਰਾਨ ਭਰੋਸਾ ਕਰ ਸਕਦੀ ਹੈ, ਨਾ ਕਿ ਕੇਵਲ ਪ੍ਰਕਿਊਰਮੈਂਟ ਲਈ ਬਣੀ ਛਾਂਹ।
ਇਹ ਇਨਵੈਂਟਰੀ ਸਮਝਣ ਦੀ ਨੀਂਹ ਹੈ ਕਿ vCenter ਓਪਰੇਸ਼ਨਾਂ ਵਾਸਤਵ ਵਿੱਚ ਕੀ-enable ਕਰਦੇ ਹਨ—ਅਤੇ ਕਿਨ੍ਹਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਦੁਸਰੇ ਥਾਂ ਮੁੜ-ਉਤਪਾਦ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੋਵੇਗਾ।
vSphere ਲਾਇਸੰਸਿੰਗ ਜਾਂ ਵਿਕਲਪਾਂ 'ਤੇ ਚਰਚਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਆਪਣੀ ਬੇਸਲਾਈਨ ਦਾ ਮਾਪ ਲਵੋ ਅਤੇ ਸਪਸ਼ਟ ਬੇਕਾਰ ਖਤਮ ਕਰੋ।
ਧਿਆਨ ਰੱਖੋ:
ਰਾਈਟ-ਸਾਈਜ਼ਿੰਗ ਤੁਰੰਤ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਖਰਚ ਘਟਾ ਸਕਦੀ ਹੈ ਅਤੇ ਕਿਸੇ ਵੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਯੋਜਨਾ ਨੂੰ ਵੱਧ ਸਹੀ ਬਣਾਉਂਦੀ ਹੈ।
ਆਪਣੇ ਫੈਸਲੇ ਮਾਪਦੰਡ ਲਿਖੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਵਜ਼ਨ ਦਿਓ। ਆਮ ਸ਼੍ਰੇਣੀਆਂ:
ਇੱਕ ਪ੍ਰਤੀਨਿਧੀ ਵਰਕਲੋਡ ਚੁਣੋ (ਸੋਧ-ਸਥਿਤੀ ਨਾ) ਅਤੇ ਪਾਇਲਟ ਚਲਾਓ ਜਿਸ ਵਿੱਚ:
ਪਾਇਲਟ ਨੂੰ Day‑2 ਓਪਰੇਸ਼ਨਾਂ ਲਈ ਇੱਕ ਅਭਿਆਸ ਸਮਝੋ—ਕੇਵਲ ਮਾਈਗ੍ਰੇਸ਼ਨ ਡੈਮੋ ਨਹੀਂ।
ਵਾਸਤਵਿਕ ਵਾਤਾਵਰਨਾਂ ਵਿੱਚ, ਕੰਟਰੋਲ ਪਲੇਨ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਛੋਟੀ-ਛੋਟੀ ਪ੍ਰਣਾਲੀਆਂ ਦਾ ਸੈੱਟ ਹੁੰਦਾ ਹੈ: ਇਨਵੈਂਟਰੀ ਟ੍ਰੈਕਰ, ਰੀਨਿਊਅਲ ਡੈਸ਼ਬੋਰਡ, ਐਕਸੈਸ ਸਮੀਖਿਆ ਵਰਕਫਲੋ, ਰਨਬੁੱਕ ਚੈਕਲਿਸਟ, ਅਤੇ ਚੇਂਜ-ਵਿੰਡੋ ਕੋਆਰਡੀਨੇਸ਼ਨ।
ਜੇ ਤੁਹਾਨੂੰ ਜਲਦੀ ਇਹ ਟੂਲ ਬਣਾਉਣੇ ਹਨ, ਤਾਂ ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਟੀਮਾਂ ਨੂੰ ਗੱਲ-ਬਾਤ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਲਾਈਟਵੇਟ ਅੰਦਰੂਨੀ ਵੈਬ ਐਪ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ (ਪਲੈਨਿੰਗ ਮੋਡ, ਸਨੈਪਸ਼ਾਟ/ਰੋਲਬੈਕ, ਅਤੇ ਸਰੋਤ ਕੋਡ ਨਿਰਯਾਤ ਸਮੇਤ)। ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਇੱਕ vCenter ਇੰਟੀਗਰੇਸ਼ਨ ਇਨਵੈਂਟਰੀ ਐਪ ਜਾਂ ਇੱਕ ਰੀਨਿਊਅਲ ਤਿਆਰੀ ਡੈਸ਼ਬੋਰਡ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰ ਸਕਦੇ ਹੋ (React front end, Go + PostgreSQL back end), ਇੱਕ ਕਸਟਮ ਡੋਮੇਨ 'ਤੇ ਹੋਸਟ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਜਰੂਰਤ ਮੁਤਾਬਕ ਤੇਜ਼ੀ ਨਾਲ ਦੁਬਾਰਾ ਤਬਦੀਲ ਕਰ ਸਕਦੇ ਹੋ—ਪੂਰੇ ਵਿਕਾਸ ਚੱਕਰ ਦੀ ਉਡੀਕ ਕੀਤੇ ਬਿਨਾਂ।
ਤੁਹਾਨੂੰ ਇੱਕ ਮੁਕੰਮਲ "ਪਲੇਟਫਾਰਮ ਰਣਨੀਤੀ" ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ ਤਾਂ ਕਿ ਤਰੱਕੀ ਕਰੋ। ਇਸ ਹਫ਼ਤੇ ਦਾ ਉਦੇਸ਼ ਅਣਿਸ਼ਚਿਤਤਾ ਘਟਾਉਣਾ ਹੈ: ਆਪਣੀਆਂ ਤਾਰੀਖਾਂ ਜਾਣੋ, ਆਪਣੀ ਕਵਰੇਜ਼ ਜਾਣੋ, ਅਤੇ ਜਾਣੋ ਕਿ ਫੈਸਲੇ ਆਉਣ 'ਤੇ ਕੌਣ ਮੌਜੂਦ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਸਭ ਚੀਜ਼ਾਂ ਨੂੰ ਮੀਟਿੰਗ ਵਿੱਚ ਦਿਖਾਉਣ ਯੋਗ ਤੱਥਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ।
ਮਲਕੀਅਤ ਅਤੇ ਲਾਇਸੰਸਿੰਗ ਬਦਲਾਅ ਅਕਸਰ ਹੈਰਾਨੀਆਂ ਪੈਦਾ ਕਰਦੇ ਹਨ ਜਦ ਵੱਖ-ਵੱਖ ਟੀਮਾਂ ਕੋਲ ਉਸਦੇ ਟੁਕੜੇ ਹੁੰਦੇ ਹਨ।
ਛੋਟੀ ਵਰਕਿੰਗ ਗਰੁੱਪ ਨੂੰ ਇਕੱਠਾ ਕਰੋ: ਪਲੇਟਫਾਰਮ/ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ, ਸੁਰੱਖਿਆ, ਐਪ ਮਾਲਕ, ਅਤੇ ਫਾਈਨੈਂਸ/ਪ੍ਰੋਕਿਊਰਮੈਂਟ। ਇਹਨਾਂ ਤੇ ਰਾਜ਼ੀ ਹੋਵੋ:
"ਲਾਗਤ ਅਤੇ ਜੋਖਮ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਲਈ ਕਾਫੀ ਚੰਗਾ" ਹੇਠਾਂ ਲੱਖੋ, ਨਾ ਕਿ ਪੂਰਨ ਇਨਵੈਂਟਰੀ।
ਇਸਨੂੰ ਇੱਕ ਚਲਦੀ-ਫਿਰਦੀ ਪ੍ਰਬੰਧਨ ਚੱਕਰ ਸਮਝੋ, ਇੱਕ ਵਾਰ ਦੀ ਘਟਨਾ ਨਹੀਂ। ਤਿਮਾਹੀ ਸਮੀਖਿਆ 'ਤੇ ਰੱਖੋ: ਵਿਕਰੇਤਾ ਰੋਡਮੈਪ/ਲਾਇਸੰਸ ਅੱਪਡੇਟ, ਰੰਨ-ਰੇਟ ਖਰਚਾਂ ਬਨਾਮ ਬਜਟ, ਅਤੇ ਓਪਰੇਸ਼ਨਲ KPI (ਘਟਨਾ ਆਕਾਰ, ਪੈਚ ਸਹਮਤੀ, ਰਿਕਵਰੀ ਟੈਸਟ ਨਤੀਜੇ)। ਨਤੀਜੇ ਆਪਣੇ ਅਗਲੇ ਰੀਨਿਊਅਲ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਯੋਜਨਾ ਨੋਟਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ।
ਹਾਇਪਰਵਾਈਜ਼ਰ VMs ਚਲਾਉਂਦਾ ਹੈ। ਇੱਕ ਕੰਟਰੋਲ ਪਲੇਨ ਉਹ ਫੈਸਲਾ-ਅਤੇ-ਗਵਰਨੈਂਸ ਲੇਅਰ ਹੈ ਜੋ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ:
ਬਹੁਤ ਸਾਰੀਆਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸੰਰਚਨਾਵਾਂ ਵਿੱਚ, ਜਿੱਥੇ ਪਹਿਲਾਂ ਕਲਿੱਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ—ਉਹੀ ਥਾਂ ਨਿਰਣая ਲੈਂਦੀ ਹੈ। ਇਸੀ ਲਈ vCenter ਸਿਰਫ਼ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਟੂਲ ਨਹੀਂ, ਇੱਕ ਕੰਟਰੋਲ ਪਲੇਨ ਵਾਂਗ ਕੰਮ ਕਰਦਾ ਹੈ।
ਕਿਉਂਕਿ ਕਾਰਗੁਜ਼ਾਰੀ ਦਾ ਅਸਲ ਫ਼ਾਇਦਾ ਸਤੰਬੀਕਰਨ ਅਤੇ ਦੁਹਰਾਅਯੋਗਤਾ ਵਿੱਚ ਘਟਦਾ ਹੈ, ਸਿਰਫ਼ ਸਰਵਰਾਂ ਦੀ ਕਮਾਈ ਨਹੀਂ। vSphere/vCenter ਅਕਸਰ ਇੱਕ ਆਮ ਸਰਫੇਸ ਬਣ ਜਾਂਦੇ ਹਨ ਜਿਸ 'ਤੇ:
ਇਹ ਆਦਤਾਂ ਜਦ ਧਾਰ੍ਹੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਪਲੇਟਫਾਰਮ ਬਦਲਣਾ Day‑2 ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਵੀ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ, ਨਾ ਕੇਵਲ VM ਦੇ ਚਲਣ ਦੀ ਥਾਂ ਨੂੰ।
Day‑2 ਓਪਰੇਸ਼ਨ ਉਹ ਮੁੜ-ਮੁੜ ਆਉਣ ਵਾਲੇ ਕੰਮ ਹਨ ਜੋ ਮੁੱਖ ਡਿਪਲੋਇਮੈਂਟ ਤੋਂ ਬਾਅਦ ਕੈਲੇਂਡਰ ਭਰਦੇ ਹਨ। ਇੱਕ VMware-ਕੇਂਦ੍ਰਿਤ ਵਾਤਾਵਰਨ ਵਿੱਚ ਇਨ੍ਹਾਂ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ:
ਜੇ ਤੁਹਾਡੇ ਰਨਬੁੱਕਸ ਇਨ੍ਹਾਂ ਵਰਕਫਲੋਅਜ਼ 'ਤੇ ਨਿਰਭਰ ਹਨ, ਤਾਂ ਮੈਨੇਜਮੈਂਟ ਲੇਅਰ ਵਾਸਤਵ ਵਿੱਚ ਤੁਹਾਡੇ ਓਪਰੇਸ਼ਨਲ ਸਿਸਟਮ ਦਾ ਹਿੱਸਾ ਹੈ।
ਉਹ ਦੇ ਕਾਰਨ ਜੋ ਅਕਸਰ ਅਣਦੇਖੇ ਰਹਿ ਜਾਂਦੇ ਹਨ ਅਤੇ ਧਾਰਨਾਵਾਂ ਬਦਲਣ 'ਤੇ ਪਹਿਲਾਂ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ। ਆਮ ਹੋਏ ਨਿਰਭਰਤਾ ਇਨ੍ਹਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਇਹਨਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਇਨਵੈਂਟਰੀ ਵਿੱਚ ਲਿਆਓ ਅਤੇ ਅਪਗਰੇਡ ਜਾਂ ਪਾਇਲਟ ਦੌਰਾਨ ਟੈਸਟ ਕਰੋ, ਨਾਹ ਕਿ ਰੀਨਿਊਅਲ ਦੇ ਬਾਅਦ ਜਦ ਟਾਈਮਲਾਈਨ ਸਖ਼ਤ ਹੋ ਜਾਏ।
ਅਕਸਰ ਤਕਨੀਕ ਫੋਟੋ-ਵਾਤਾਵਰਨ ਤੁਰੰਤ ਟੁੱਟਦੀ ਨਹੀਂ—ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਜੋ ਬਦਲਦਾ ਹੈ ਉਹ ਹੈ ਵਪਾਰਕ ਲਪੇਟ: ਖਰੀਦਣ ਦਾ ਢੰਗ, ਰੀਨਿਊਅਲ, ਅਤੇ ਕਿ “ਸਧਾਰਨ” ਕੀ ਹੈ। ਟੀਮਾਂ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਅਨੁਭਵ ਕਰਦੀਆਂ ਹਨ:
ਇਸਨੂੰ ਦੋ ਟ੍ਰੈਕਾਂ ਵਜੋਂ ਦੇਖੋ: ਉਤਪਾਦ ਮੁੱਲ ਨੂੰ ਓਪਰੇਸ਼ਨਲ ਰੂਪ ਵਿੱਚ ਬਣਾਈ ਰੱਖੋ, ਅਤੇ ਵਪਾਰਕ ਅਨਿਸ਼ਚਿਤਤਾ ਨੂੰ ਠੰਢੇ ਸਿਰਖੇ ਢੰਗ ਨਾਲ ਘਟਾਓ।
ਇੱਕ ਫੈਕਟ-ਬੇਸ ਬਣਾਓ ਤਾਂ ਕਿ ਖਰੀਦ-ਫਰੋਖਤ ਗੱਲਬਾਤ ਅਣਗਲਤ ਨਾ ਹੋਵੇ:
ਇਸ ਨਾਲ ਤੁਸੀਂ ਸਪਸ਼ਟਤਾ ਨਾਲ ਮੱਲ-ਤੌਰ ਉੱਤੇ ਗੱਲਬਾਤ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਵਿਕਲਪਾਂ ਦਾ ਠੀਕ ਮੁਲਾਂਕਣ ਕਰ ਸਕਦੇ ਹੋ।
ਇਸ ਨਾਲ ਰਿਕਵਰੀ ਦੀ ਗਤੀ ਸੁਸਤ ਹੋ ਸਕਦੀ ਹੈ ਕਿਉਂਕਿ ਰਿਸਪਾਂਡਰ ਕੰਟਰੋਲ ਪਲੇਨ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ:
ਜੇ ਟੂਲਿੰਗ, ਰੋਲਸ ਜਾਂ ਵਰਕਫਲੋਅਜ਼ ਬਦਲਦੇ ਹਨ, ਤਾਂ MTTR ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਲਈ ਰਿਟਰੇਨਿੰਗ, ਰੋਲ ਡਿਜ਼ਾਈਨ ਅਤੇ ਅਪਡੇਟ ਰਨਬੁੱਕਸ ਦੀ ਯੋਜਨਾ ਬਣਾਓ।
ਬੰਡਲ ਹਮੇਸ਼ਾਂ ਖਰਾਬ ਨਹੀਂ ਹੁੰਦੇ—ਉਹ ਓਪਰੇਸ਼ਨਸ ਨੂੰ ਸਧਾਰਨ ਵੀ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਵਪਾਰਕ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਟਰੇਡ-ਆਫ਼ ਹਨ:
ਪ੍ਰਯੋਗਿਕ ਕਦਮ: ਹਰ ਬੰਡਲ ਕੰਪੋਨੈਂਟ ਨੂੰ ਨਕਸ਼ਾ ਕਰੋ ਅਤੇ ਇਹ ਪਵਾ ਕਰੋ ਕਿ ਉਹ ਸੰਚਾਲਨਕ ਜ਼ਰੂਰਤ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਫਿਰ ਹੀ ਬੰਡਲ ਸਵੀਕਾਰ ਕਰੋ।
ਅਣਿਸ਼ਚਿਤਤਾ ਘੱਟ ਕਰੋ ਅਤੇ ਸਮਾਂ ਖ਼ਰੀਦੋ:
ਇਹ ਕਦਮ ਰਹਿਣ, ਵੱਖ-ਵਿੱਖ करਣ ਜਾਂ ਮਾਈਗ੍ਰੇਟ ਕਰਨ ਤੋਂ ਬਿਨਾਂ ਤੁਹਾਡੇ ਖਤਰੇ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ।
ਨਿਮਨਲਿਖਤ ਨਿਯੰਤਰਿਤ ਪਾਇਲਟ ਨੂੰ ਵਰਤੋ ਜੋ ਸਿਰਫ਼ ਮਾਈਗ੍ਰੇਸ਼ਨ ਮਕੈਨਿਕਸ ਨਹੀਂ, ਬਲਕਿ ਓਪਰੇਸ਼ਨਜ਼ ਨੂੰ ਵੀ ਟੈਸਟ ਕਰੇ:
ਪਾਇਲਟ ਨੂੰ ਇੱਕ Day‑2 ਓਪਰੇਸ਼ਨ ਰਿਹਰਸਲ ਵੱਜੋਂ ਸਮਝੋ—ਪੈਚਿੰਗ, ਮਾਨੀਟਰਨਿੰਗ, ਬੈਕਅੱਪ ਅਤੇ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਵੀ ਟੈਸਟ ਕਰਨ।