ਤੁਸੀਂ ਬੁਨਿਆਦੀ ਢਾਂਚੇ 'ਤੇ ਕਿੰਨਾ ਖਰਚ ਕਰਦੇ ਹੋ? ਅਤੇ ਤੁਸੀਂ ਇਸ 'ਤੇ ਪੈਸੇ ਕਿਵੇਂ ਬਚਾ ਸਕਦੇ ਹੋ?

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

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

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

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

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

FinOps ਕੌਣ ਹੈ

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

ਇਸ ਲਈ ਕੀ ਕਰਨਾ ਹੈ - ਧੀਰਜ ਨਾਲ ਸਲੇਟੀ ਕਰਨਾ ਜਾਰੀ ਰੱਖੋ, ਇਸ ਉੱਤੇ ਪੇਂਟ ਕਰੋ, ਜਾਂ ਭੁਗਤਾਨ ਵਿੱਚ ਇਹਨਾਂ ਬਹੁਤ ਸਾਰੇ ਭਿਆਨਕ ਜ਼ੀਰੋ ਦੀ ਦਿੱਖ ਦੇ ਕਾਰਨਾਂ ਦਾ ਪਤਾ ਲਗਾਓ?

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

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

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

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

ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਬਾਰੇ ਇੱਕ ਛੋਟਾ ਜਿਹਾ

ਬੱਦਲ. ਮੁਕਾਬਲਤਨ ਸਸਤੇ ਅਤੇ ਬਹੁਤ ਹੀ ਸੁਵਿਧਾਜਨਕ. ਪਰ ਇਹ ਹੱਲ ਸਸਤੇ ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਹੈ ਜਦੋਂ ਸਰਵਰਾਂ ਦੀ ਗਿਣਤੀ ਦੋਹਰੇ ਜਾਂ ਤਿੰਨ ਅੰਕਾਂ ਤੱਕ ਪਹੁੰਚ ਜਾਂਦੀ ਹੈ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕਲਾਉਡ ਵੱਧ ਤੋਂ ਵੱਧ ਸੇਵਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸੰਭਵ ਬਣਾਉਂਦੇ ਹਨ ਜੋ ਪਹਿਲਾਂ ਅਣਉਪਲਬਧ ਸਨ: ਇਹ ਇੱਕ ਸੇਵਾ (ਐਮਾਜ਼ਾਨ AWS, Azure ਡਾਟਾਬੇਸ), ਸਰਵਰ ਰਹਿਤ ਐਪਲੀਕੇਸ਼ਨ (AWS Lambda, Azure ਫੰਕਸ਼ਨ) ਅਤੇ ਹੋਰ ਬਹੁਤ ਸਾਰੇ ਡੇਟਾਬੇਸ ਹਨ। ਉਹ ਸਾਰੇ ਬਹੁਤ ਵਧੀਆ ਹਨ ਕਿਉਂਕਿ ਉਹ ਵਰਤਣ ਵਿੱਚ ਆਸਾਨ ਹਨ - ਖਰੀਦੋ ਅਤੇ ਜਾਓ, ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ। ਪਰ ਜਿੰਨੀ ਡੂੰਘੀ ਕੰਪਨੀ ਅਤੇ ਇਸਦੇ ਪ੍ਰੋਜੈਕਟ ਬੱਦਲਾਂ ਵਿੱਚ ਡੁੱਬ ਜਾਂਦੇ ਹਨ, CFO ਦੀ ਨੀਂਦ ਓਨੀ ਹੀ ਬਦਤਰ ਹੁੰਦੀ ਹੈ। ਅਤੇ ਜਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਜਨਰਲ ਸਲੇਟੀ ਹੋ ​​ਜਾਂਦਾ ਹੈ।

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

ਤਾਂ ਇਸ ਸਥਿਤੀ ਵਿੱਚ FinOps ਕੀ ਕਰਦਾ ਹੈ:

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

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

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

ਤਰੀਕੇ ਨਾਲ, ਛੋਟ ਬਾਰੇ

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

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

ਉਸੇ ਸਮੇਂ, ਤੁਹਾਨੂੰ ਇਹ ਯਾਦ ਰੱਖਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਰੋਸ਼ਨੀ AWS ਜਾਂ Azure 'ਤੇ ਇੱਕ ਪਾੜਾ ਵਾਂਗ ਇਕਸਾਰ ਨਹੀਂ ਹੋਈ ਸੀ। ਬੇਸ਼ੱਕ, ਤੁਹਾਡੇ ਆਪਣੇ ਸਰਵਰ ਰੂਮ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਦਾ ਕੋਈ ਸਵਾਲ ਨਹੀਂ ਹੈ - ਪਰ ਦੈਂਤ ਦੇ ਇਹਨਾਂ ਦੋ ਕਲਾਸਿਕ ਹੱਲਾਂ ਦੇ ਵਿਕਲਪ ਹਨ.

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

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

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

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

ਅੰਤ ਵਿੱਚ ਕੀ?

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

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

ਸਰੋਤ: www.habr.com