22 ਅਪ੍ਰੈ 2025·8 ਮਿੰਟ
Samsung SDS ਅਤੇ ਉਦਯੋਗੀ IT ਦਾ ਵਿਸਥਾਰ — ਜਿੱਥੇ ਉਪਟਾਈਮ ਹੀ ਉਤਪਾਦ ਹੈ
ਇਕ ਵਿਹੰਗਮਦਰਸ਼ਨ ਕਿ Samsung SDS-ਸਟਾਈਲ ਉਦਯੋਗੀ ਪŁੈਟਫ਼ਾਰਮ ਭਰੋਸੇਯੋਗਤਾ, ਚੇਂਜ ਕੰਟਰੋਲ ਅਤੇ ਵਿਸ਼ਵਾਸ ਨੂੰ ਮੁੱਖ ਉਤਪਾਦ ਵਜੋਂ ਕਿਵੇਂ ਸਕੇਲ ਕਰਦੇ ਹਨ।
ਇਕ ਵਿਹੰਗਮਦਰਸ਼ਨ ਕਿ Samsung SDS-ਸਟਾਈਲ ਉਦਯੋਗੀ ਪŁੈਟਫ਼ਾਰਮ ਭਰੋਸੇਯੋਗਤਾ, ਚੇਂਜ ਕੰਟਰੋਲ ਅਤੇ ਵਿਸ਼ਵਾਸ ਨੂੰ ਮੁੱਖ ਉਤਪਾਦ ਵਜੋਂ ਕਿਵੇਂ ਸਕੇਲ ਕਰਦੇ ਹਨ।
ਜਦੋਂ ਇੱਕ ਉਦਯੋਗ ਵਿੱਤੀ, ਉਤਪਾਦਨ, ਲਾਜ਼ਿਸਟਿਕਸ, HR ਅਤੇ ਗਾਹਕ ਚੈਨਲ ਚਲਾਉਣ ਲਈ ਸਾਂਝੇ ਪŁੈਟਫ਼ਾਰਮਾਂ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਉਪਟਾਈਮ ਇੱਕ “ਵਾਧੂ ਸੁਵਿਧਾ” ਨਹੀਂ ਰਹਿੰਦੀ। ਇਹ ਉਹ ਚੀਜ਼ ਬਣ ਜਾਂਦੀ ਹੈ ਜੋ ਵੇਚੀ ਜਾ ਰਹੀ ਹੈ। ਕਿਸੇ ਸੰਸਥਾ ਲਈ ਜਿਵੇਂ Samsung SDS—ਇੱਕ ਵੱਡੇ ਪੱਧਰ ਦੇ ਉਦਯੋਗੀ IT ਸੇਵਾ ਅਤੇ ਪŁੈਟਫ਼ਾਰਮ ਪ੍ਰਦਾਤਾ—ਭਰੋਸੇਯੋਗਤਾ ਸੇਵਾ ਦੀ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ; ਇਹ ਸੇਵਾ ਖੁਦ ਹੈ.
ਉਪਭੋਗਤਾ ਐਪ ਵਿੱਚ ਇੱਕ ਛੋਟੀ ਰੁਕਾਵਟ ਰੁਕਾਵਟ ਵਾਲੀ ਹੋ ਸਕਦੀ ਹੈ। ਉਦਯੋਗੀ ਇਕੋਸਿਸਟਮਾਂ ਵਿੱਚ ਇਹ ਰੇਵਿਨਿਊ ਰਿਕਾਗਨਾਈਸ਼ਨ ਰੋਕ ਸਕਦੀ ਹੈ, ਸ਼ਿਪਮੈਂਟ ਦੇਰੀ ਕਰ ਸਕਦੀ ਹੈ, ਕੰਪਲਾਇੰਸ ਰਿਪੋਰਟਿੰਗ ਟੁੱਟ ਸਕਦੀ ਹੈ ਜਾਂ ਸਹਿਮਤੀ ਅਨੁਸਾਰ ਸਜ਼ਾਂ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀ ਹੈ। “ਭਰੋਸੇਯੋਗਤਾ ਹੀ ਉਤਪਾਦ” ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਸਫਲਤਾ ਨਵੇਂ ਫੀਚਰਾਂ ਨਾਲ ਘੱਟ ਤੇ ਨਤੀਜਿਆਂ ਨਾਲ ਜ਼ਿਆਦਾ ਮਾਪੀ ਜਾਂਦੀ ਹੈ, ਉਦਾਹਰਨ ਵਜੋਂ:
ਇਸਦਾ ਮਤਲਬ ਇਹ ਵੀ ਹੈ ਕਿ ਇੰਜੀਨੀਅਰਿੰਗ ਅਤੇ ਓਪਰੇਸ਼ਨ ਵੱਖਰੇ “ਚਰਣ” ਨਹੀਂ ਹਨ। ਉਹ ਇੱਕੋ ਪ੍ਰਤੀਜੈ ਦਾ ਹਿੱਸਾ ਹਨ: ਗਾਹਕ ਅਤੇ ਅੰਦਰੂਨੀ ਹਿੱਸੇਦਾਰ ਤਰ੍ਹਾਂ-ਥਰ੍ਹਾਂ ਦੇਣ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ—ਮੁਸਲਸਲ, ਮਾਪਯੋਗ, ਅਤੇ ਤਣਾਅ ਹੇਠਾਂ।
ਉਦਯੋਗੀ ਭਰੋਸੇਯੋਗਤਾ ਆਮ ਤੌਰ 'ਤੇ ਇਕੱਲੇ ਐਪਲੀਕੇਸ਼ਨ ਬਾਰੇ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਨਿਰਭਰਤਾਵਾਂ ਦੇ ਇੱਕ ਜਾਲ ਬਾਰੇ ਹੁੰਦਾ ਹੈ ਜੋ:
ਏਹ ਆਪਸੀ ਜੁੜਾਅ ਫੇਲਿਆਵ ਦਾ ਪ੍ਰਧਾਨ ਵਿਆਪੀ ਹੋ ਸਕਦਾ ਹੈ: ਇੱਕ ਘਟਿਆ ਹੋਇਆ ਸੇਵਾ ਦਰਜਨਾਂ ਡਾਊਨਸਟ੍ਰੀਮ ਸਿਸਟਮਾਂ ਅਤੇ ਬਾਹਰੀ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਵਿੱਚ ਕੈਸਕੇਡ ਕਰ ਸਕਦੀ ਹੈ।
ਇਹ ਪੋਸਟ ਉਦਾਹਰਣਾਂ ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਨਮੂਨਿਆਂ 'ਤੇ ਕੇਂਦਰਿਤ ਹੈ—ਅੰਦਰੂਨੀ ਜਾਂ ਗੁਪਤ ਵਿਸਥਾਰਾਂ 'ਤੇ ਨਹੀਂ। ਤੁਸੀਂ ਸਿੱਖੋਂਗੇ ਕਿ ਉਦਯੋਗਿਕ ਸੰਸਥਾਵਾਂ ਇਕਚਲਾਉਣ ਮਾਡਲ (ਕੌਣ ਕੀ ਮਾਲਕੀ ਰਖਦਾ ਹੈ), ਪŁੈਟਫ਼ਾਰਮ ਫੈਸਲੇ (ਸਟੈਂਡਰਡਾਈਜ਼ੇਸ਼ਨ ਜੋ ਡਿਲਿਵਰੀ ਗਤੀ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦਾ ਹੈ) ਅਤੇ ਮੈਟ੍ਰਿਕਸ (SLOs, ਇੰਸੀਡੈਂਟ ਪ੍ਰਦਰਸ਼ਨ, ਅਤੇ ਕਾਰੋਬਾਰ-ਸੰਬੰਧੀ ਟੀਚੇ) ਰਾਹੀਂ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਕਿਵੇਂ ਹਾਸਲ ਕਰਦੀਆਂ ਹਨ।
ਅਖੀਰ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਉਹੇ ਖਿਆਲ ਆਪਣੇ ਮਾਹੌਲ ਨਾਲ ਮੇਲ ਖਾਣ ਯੋਗ ਹੋਣਗੇ—ਭਾਵੇਂ ਤੁਸੀਂ ਇੱਕ ਕੇਂਦਰੀ IT ਸੰਗਠਨ ਚਲਾ ਰਹੇ ਹੋ, ਇੱਕ ਸ਼ੇਅਰਡ ਸਰਵਿਸਿਜ਼ ਟੀਮ, ਜਾਂ ਇੱਕ ਪŁੈਟਫ਼ਾਰਮ ਗਰੁੱਪ ਜੋ ਨਿਰਭਰ ਕਾਰੋਬਾਰਾਂ ਦੇ ਇਕੋਸਿਸਟਮ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੋਵੇ।
Samsung SDS ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਜਟਿਲ ਉਦਯੋਗੀ IT ਨੂੰ ਚਲਾਉਣ ਅਤੇ ਅਧੁਨਿਕ ਕਰਨ ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ: ਉਹ ਸਿਸਟਮ ਜੋ ਵੱਡੀਆਂ ਸੰਸਥਾਵਾਂ ਨੂੰ ਦਿਨ-ਪ੍ਰਤੀ ਦਿਨ ਚਲਾਉਂਦੇ ਰਹਿਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ। ਇਕੱਲੇ ਐਪ ਜਾਂ ਉਤਪਾਦ ਲਾਈਨ 'ਤੇ ਧਿਆਨ ਦੇਣ ਦੀ ਥਾਂ, ਇਹ ਕੰਮ ਉਦਯੋਗ ਦੀ “ਪਲੰਬਿੰਗ” ਨਜ਼ਦੀਕ ਹੁੰਦਾ ਹੈ—ਪŁੈਟਫ਼ਾਰਮ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ, ਓਪਰੇਸ਼ਨ, ਅਤੇ ਉਹ ਸੇਵਾਵਾਂ ਜੋ ਕਾਰੋਬਾਰੀ-ਆਵਸ਼ਯਕ ਵਰਕਫਲੋਜ਼ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਅਮਲ ਵਿੱਚ, ਇਹ ਅਕਸਰ ਕਈ ਸ਼੍ਰੇਣੀਆਂ 'ਚ ਫੈਲਦਾ ਹੈ ਜੋ ਬਹੁਤ ਸਾਰੀਆਂ ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਨੂੰ ਇਕੱਠੇ ਲੋੜੀਦੀਆਂ ਹੋਂਦੀਆਂ ਹਨ:
ਪੱਧਰ ਸਿਰਫ਼ ਟ੍ਰੈਫਿਕ ਵਾਲੀ ਗੱਲ ਨਹੀਂ ਹੈ। ਅੰਦਰੂਨੀ ਬਹੁਤ ਸਾਰੇ ਵਪਾਰਿਕ ਯੂਨਿਟਾਂ, ਵੱਖ-ਵੱਖ ਅਨੁਕੂਲਤਾ ਨਿਯਮਾਂ, ਕਈ ਭੂਗੋਲਿਕ ਖੇਤਰ ਅਤੇ ਆਧੁਨਿਕ ਕਲਾਉਡ ਸੇਵਾਵਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਲੇਗਸੀ ਸਿਸਟਮਾਂ ਦਾ ਮਿਲਾਪ ਇਹਨਾਂ পরিবেশਾਂ ਵਿੱਚ “ਚੌੜਾਈ” ਬਣਾਂਦਾ ਹੈ।
ਇਹ ਚੌੜਾਈ ਇੱਕ ਵੱਖਰਾ ਆਪਰੇਟਿੰਗ ਹਕੀਕਤ ਪੈਦਾ ਕਰਦੀ ਹੈ:
ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਸੀਮਾਬੰਦੀ ਨਿਰਭਰਤਾ ਕੁੜੀ ਹੈ। ਜਦੋਂ ਕੋਰ ਪŁੈਟਫ਼ਾਰਮ ਸਾਂਝੇ ਹੁੰਦੇ ਹਨ—identity, ਨੈੱਟਵਰਕ, ਡੇਟਾ ਪਾਈਪਲਾਈਨ, ERP, ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਮਿਡਲਵੇਅਰ—ਅਗਲੇ-ਚੋਟੀਆਂ ਸਮੱਸਿਆਵਾਂ ਆਉਟਵਰਡ ਰਿਪਲ ਕਰਨ ਲੱਗਦੀਆਂ ਹਨ। ਇੱਕ ਸਲੋ authentication ਸੇਵਾ “ਐਪ ਡਾਉਨ” ਵਾਂਗ ਲੱਗ ਸਕਦੀ ਹੈ। ਇੱਕ ਡੇਟਾ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਦੇਰੀ ਰਿਪੋਰਟਿੰਗ, ਫੋਰਕਾਸਟਿੰਗ ਜਾਂ ਕੰਪਲਾਇੰਸ ਜਮ੍ਹਾਂ ਨੂੰ ਰੋਕ ਸਕਦੀ ਹੈ।
ਇਸ ਲਈ Samsung SDS ਵਰਗੇ ਉਦਯੋਗੀ ਪ੍ਰਦਾਤਾਵਾਂ ਨੂੰ ਅਕਸਰ ਫੀਚਰਾਂ ਨਾਲ ਨਹੀਂ, ਨਤੀਜਿਆਂ ਨਾਲ ਅੰਕਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ: ਕਿਵੇਂ ਸਾਂਝੇ ਸਿਸਟਮ hazaaron ਡਾਊਨਸਟ੍ਰੀਮ ਵਰਕਫਲੋਜ਼ ਨੂੰ ਲਗਾਤਾਰ ਚਲਾਉਂਦੇ ਰਹਿੰਦੇ ਹਨ।
ਉਦਯੋਗੀ ਪŁੈਟਫ਼ਾਰਮ ਅਕਸਰ ਅਲੱਗ-ਅਲੱਗ ਤੌਰ 'ਤੇ ਫੇਲ ਨਹੀਂ ਹੁੰਦੇ। Samsung SDS-ਸਟਾਈਲ ਇਕੋਸਿਸਟਮ ਵਿੱਚ, ਇੱਕ ਸੇਵਾ ਅੰਦਰ ਇੱਕ “ਛੋਟੀ” ਆਊਟੇਜ ਸਪਲਾਇਰਾਂ, ਲਾਜਿਸਟਿਕਸ ਭਾਗੀਦਾਰਾਂ, ਅੰਦਰੂਨੀ ਬਿਜ਼ਨਸ ਯੂਨਿਟਾਂ ਅਤੇ ਗਾਹਕ-ਸਾਮ੍ਹਣੇ ਚੈਨਲਾਂ 'ਤੇ ਕੈਸਕੇਡ ਕਰ ਸਕਦਾ ਹੈ—ਕਿਉਂਕਿ ਹਰ ਇੱਕ ਹੀ ਇੱਕੋ ਸਾਂਝੇ ਨਿਰਭਰਤਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਹੈ।
ਬਹੁਤ ਸਾਰੇ ਉਦਯੋਗੀ ਯਾਤਰਾ ਇੱਕ ਜਾਣੀ-ਪਹਿਚਾਣੀ ਲੜੀ ਰਾਹੀਂ ਜਾਂਦੀਆਂ ਹਨ:
ਜਦੋਂ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਇੱਕ ਘਟ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਕਈ “ਹੈਪੀ ਪਾਥਸ” ਇਕੱਠੇ ਰੋਕ ਸਕਦਾ ਹੈ—ਚੈਕਆਊਟ, ਸ਼ਿਪਮੈਂਟ ਬਣਾਉਣਾ, ਰਿਟਰਨ, ਇਨਵੌਇਸਿੰਗ, ਜਾਂ ਭਾਗੀਦਾਰ ਆਨਬੋਰਡਿੰਗ।
ਇਕੋਸਿਸਟਮ ਵੱਖ-ਵੱਖ “ਪਾਈਪਾਂ” ਰਾਹੀਂ ਇੰਟੀਗ੍ਰੇਟ ਹੁੰਦੇ ਹਨ, ਹਰ ਇੱਕ ਦਾ ਆਪਣੇ ਫੇਲਿਓਰ ਪੈਟਰਨ ਹੁੰਦਾ ਹੈ:
ਇੱਕ ਮੁੱਖ ਜੋਖਮ ਕੋਰੈਲੇਟਿਡ ਫੇਲਿਊਰ ਹੈ: ਕਈ ਭਾਗੀਦਾਰ ਇੱਕੋ ਐਂਡਪੌਇੰਟ, ਇੱਕੋ ਆਈਡੈਂਟੀਟੀ ਪ੍ਰਦਾਤਾ, ਜਾਂ ਇੱਕੋ ਸਾਂਝਾ ਡੇਟਾ ਸੈੱਟ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ—ਇਸ ਤਰ੍ਹਾਂ ਇਕ ਫਾਲਟ ਬਹੁਤ ਸਾਰੇ ਇੰਸੀਡੈਂਟ ਬਣ ਜਾਂਦਾ ਹੈ।
ਇਕੋਸਿਸਟਮ ਉਹ ਸਮੱਸਿਆਵਾਂ ਲਿਆਉਂਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਇਕ ਕੰਪਨੀ-ਅਧਾਰਿਤ ਸਿਸਟਮਾਂ ਵਿੱਚ ਨਹੀਂ ਵੇਖਦੇ:
ਬਲਾਸਟ ਰੇਡੀਅਸ ਘਟਾਉਣ ਦੀ ਸ਼ੁਰੂਆਤ ਨਿਰਭਰਤਾਵਾਂ ਅਤੇ ਭਾਗੀਦਾਰ ਯਾਤਰਾਵਾਂ ਦਾ ਸਪੱਸ਼ਟ ਨਕਸ਼ਾ ਬਣਾਉਣ ਨਾਲ ਹੁੰਦੀ ਹੈ, ਫਿਰ ਇੰਟੀਗ੍ਰੇਸ਼ਨਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਜਾਵੇ ਕਿ ਉਹ ਗਰੇਸਫੁੱਲੀ ਡੀਗਰੇਡ ਹੋਣ ਬਜਾਏ ਇੱਕ ਵੱਡੇ ਫੇਲ ਦੁਲ੍ਹਨ (ਦੇਖੋ ਵੀ /blog/reliability-targets-slos-error-budgets)।
ਸਟੈਂਡਰਡਾਈਜ਼ੇਸ਼ਨ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਮਦਦ ਕਰਦੀ ਹੈ ਜਦੋਂ ਇਹ ਟੀਮਾਂ ਨੂੰ ਤੇਜ਼ ਬਣਾਏ। ਵੱਡੇ ਉਦਯੋਗੀ ਇਕੋਸਿਸਟਮਾਂ ਵਿੱਚ, ਪŁੈਟਫ਼ਾਰਮ ਬੁਨਿਆਦੀਆਂ ਉਹਨਾਂ ਵੇਲੇ ਸਫਲ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਫੈਸਲਿਆਂ (ਅਤੇ ਦੁਹਰਾਏ ਗਏ ਗਲਤੀਆਂ) ਨੂੰ ਹਟਾ ਦਿੰਦੀਆਂ ਹਨ ਪਰ ਫਿਰ ਵੀ ਪ੍ਰੋਡਕਟ ਟੀਮਾਂ ਨੂੰ ਸ਼ਿਪ ਕਰਨ ਲਈ ਜਗ੍ਹਾ ਦਿੰਦੀਆਂ ਹਨ।
ਪŁੈਟਫ਼ਾਰਮ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਪਰਤਾਂ ਵਜੋਂ ਸੋਚਣਾ ਵਰਤਣਯੋਗ ਹੈ, ਹਰ ਇੱਕ ਦੀ ਇੱਕ ਵੱਖਰੀ ਕੰਟਰੈਕਟ ਹੋਵੇ:
ਇਹ ਵਿਭਾਜਨ “ਐਨਟਰਪ੍ਰਾਈਜ਼-ਗਰੇਡ” ਲੋੜਾਂ (ਸੁਰੱਖਿਆ, ਉਪਲਬਧਤਾ, ਆਡੀਟਬਿਲਟੀ) ਨੂੰ ਪŁੈਟਫ਼ਾਰਮ ਵਿੱਚ ਤਿਆਰ ਰੱਖਦੀ ਹੈ ਨਾਂ ਕਿ ਹਰ ਐਪ ਦੁਆਰਾ ਦੁਬਾਰਾ ਨਿਰਮਿਤ ਕੀਤਾ ਜਾਵੇ।
ਗੋਲਡਨ ਪਾਥਸ ਮਨਜ਼ੂਰ ਕੀਤੇ ਹੋਏ ਟੈਂਪਲੇਟ ਅਤੇ ਵਰਕਫਲੋ ਹਨ ਜੋ ਸੁਰੱਖਿਅਤ, ਭਰੋਸੇਯੋਗ ਵਿਕਲਪ ਨੂੰ ਸਭ ਤੋਂ ਆਸਾਨ ਵਿਕਲਪ ਬਣਾਉਂਦੇ ਹਨ: ਇੱਕ ਮਿਆਰੀ ਸੇਵਾ ਸਕੈਫੋਲਡ, ਪ੍ਰੀ-ਕੋਨਫਿਗਰਡ ਪਾਈਪਲਾਈਨ, ਡਿਫਾਲਟ ਡੈਸ਼ਬੋਰਡ, ਅਤੇ ਜਾਣੇ-ਪਹਿਚਾਣੇ-ਚੰਗੇ ਸਟੈਕ। ਟੀਮਾਂ ਲੋੜ ਹੋਣ 'ਤੇ ਹਟ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਉਹ ਇਸ ਨੂੰ ਇਰਾਦੇ ਨਾਲ ਕਰਦੀਆਂ ਹਨ ਤੇ ਵਧੇਰੇ ਜਟਿਲਤਾ ਲਈ ਸਪਸ਼ਟ ਮਾਲਕੀ ਲੈਂਦੀਆਂ ਹਨ।
ਇੱਕ ਵਧਦਾ ਰੁਝਾਨ ਇਹ ਹੈ ਕਿ ਇਹਨਾਂ ਗੋਲਡਨ ਪਾਥਸ ਨੂੰ ਉਤਪਾਦੀਕ੍ਰਤ ਸਟਾਰਟਰ ਕਿੱਟਾਂ ਵਾਂਗ ਦੇਖਿਆ ਜਾਵੇ—ਸਕੇਫੋਲਡਿੰਗ, ਵਾਤਾਵਰਣ ਬਣਾਉਣਾ, ਅਤੇ “ਡੇ-2” ਡਿਫਾਲਟ (ਹੈਲਥ ਚੈਕ, ਡੈਸ਼ਬੋਰਡ, ਅਲਰਟ ਨਿਯਮ)। ਪŁੈਟਫ਼ਾਰਮਾਂ ਜਿਵੇਂ Koder.ai, ਟੀਮਾਂ ਨੂੰ ਚੈਟ-ਡ੍ਰਾਈਵਨ ਵਰਕਫਲੋ ਰਾਹੀਂ ਕੰਮ ਕਰਨ ਦੀ ਯੋਗਤਾ ਦੇਕੇ ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲੀ ਐਪ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਹੋਰ ਅੱਗੇ ਲੈ ਜਾਣ ਦੀ ਛੂਟ ਦਿੰਦੀਆਂ ਹਨ—ਫਿਰ planning mode, snapshots, ਅਤੇ rollback ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਦਲਾਅ ਵਾਪਸੀਯੋਗ ਰੱਖਦੇ ਹਨ ਅਤੇ ਤੇਜ਼ੀ ਨੂੰ ਬਣਾਈ ਰੱਖਦੇ ਹਨ। ਮਕਸਦ ਟੂਲਿੰਗ ਦਾ ਬ੍ਰੈਂਡ ਨਹੀਂ, ਪਰ ਭਰੋਸੇਯੋਗ ਰਾਹ ਨੂੰ ਸਭ ਤੋਂ ਘੱਟ ਰੁਕਾਵਟ ਵਜੋਂ ਬਣਾਉਣਾ ਹੈ।
ਮਲਟੀ-ਟੇਨੰਟ ਪŁੈਟਫ਼ਾਰਮ ਲਾਗਤ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਆਨਬੋਰਡਿੰਗ ਤੇਜ਼ ਕਰਦੇ ਹਨ, ਪਰ ਉਹ ਮਜ਼ਬੂਤ ਗਾਰਡਰੇਲ (ਕੁਆਟਾ, noisy-neighbor ਨਿਯੰਤਰਣ, ਸਪਸ਼ਟ ਡੇਟਾ ਸੀਮਾਵਾਂ) ਲ 요구 ਕਰਦੇ ਹਨ। ਡੈਡੀਕੇਟਿਡ ਵਾਤਾਵਰਣ ਮਹਿੰਗੇ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਕੰਪਲਾਇੰਸ, ਪਰਫਾਰਮੈਂਸ ਆਈਸੋਲੇਸ਼ਨ, ਅਤੇ ਗਾਹਕ-ਨਿਰਧਾਰਤ ਚੇਂਜ ਵਿੰਡੋਜ਼ ਨੂੰ ਸਧਾਰਨ ਕਰ ਸਕਦੇ ਹਨ।
ਚੰਗੀਆਂ ਪŁੈਟਫ਼ਾਰਮ ਚੋਣਾਂ ਰੋਜ਼ਾਨਾ ਫੈਸਲਿਆਂ ਦੀ ਗਿਣਤੀ ਘਟਾਉਂਦੀਆਂ ਹਨ: "ਕਿਹੜੀ ਲੋਗਿੰਗ ਲਾਇਬ੍ਰੇਰੀ?", "ਸੀਕ੍ਰੇਟ ਕਿਵੇਂ ਰੋਟੇਟ ਕਰੀਏ?", "ਡੀਪਲੋਇਮੈਂਟ ਪੈਟਰਨ ਕੀ ਹੈ?" ਵਰਗੀਆਂ ਗੱਲਾਂ ਘੱਟ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਟੀਮਾਂ ਕਾਰੋਬਾਰੀ ਲੌਜਿਕ ਤੇ ਧਿਆਨ ਦੇ ਸਕਦੀਆਂ ਹਨ ਜਦ ਪŁੈਟਫ਼ਾਰਮ ਚੁਪਚਾਪ ਅਨੁਸਾਰਤਾ ਲਾਗੂ ਕਰਦਾ ਹੈ—ਅਤੇ ਇਹ ਹੀ ਸਟੈਂਡਰਡਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਡਿਲਿਵਰੀ ਗਤੀ ਤੇਜ਼ ਕਰਨ ਦੀ ਤਰ੍ਹਾਂ ਬਣਾਉਂਦਾ ਹੈ ਨਾ ਕਿ ਉਦਾਸੀ।
ਉਦਯੋਗੀ IT ਪ੍ਰਦਾਤੇ "ਭਰੋਸੇਯੋਗਤਾ" ਨੂੰ ਇੱਕ ਵਾਧੂ ਕਾਰਜ ਵਜੋਂ ਨਹੀਂ ਕਰਦੇ—ਭਰੋਸੇਯੋਗਤਾ ਉਹਦਾ ਹਿੱਸਾ ਹੈ ਜੋ ਗਾਹਕ ਖਰੀਦਦੇ ਹਨ। ਇਸ ਨੂੰ ਹਕੀਕਤ ਬਣਾਉਣ ਦਾ ਪ੍ਰਯੋਗਾਤਮਕ ਤਰੀਕਾ ਉਮੀਦਾਂ ਨੂੰ ਮਾਪਯੋਗ ਟੀਚਿਆਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨਾ ਹੈ ਜੋ ਹਰ ਕੋਈ ਸਮਝ ਸਕੇ ਅਤੇ ਪ੍ਰਬੰਧਨ ਕਰ ਸਕੇ।
SLI (Service Level Indicator) ਇੱਕ ਮਾਪ ਹੈ (ਉਦਾਹਰਨ: "ਚੈਕਆਊਟ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਾਂ ਦਾ ਪ੍ਰਤੀਸ਼ਤ ਜੋ ਸਫਲ ਰਹੇ")। SLO (Service Level Objective) ਉਸ ਮਾਪ ਲਈ ਟੀਚਾ ਹੈ (ਉਦਾਹਰਨ: "30 ਦਿਨਾਂ ਵਿੱਚ 99.9% ਚੈਕਆਊਟ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਸਫਲ ਰਹਿਣ").
ਕਿਉਂ ਧਿਆਨ ਨੂੰ ਲਾਉਣਾ ਹੈ: ਠੋਸ ਪਰਿਭਾਸ਼ਾਵਾਂ ਬਿਨਾਂ, ਟੀਮਾਂ ਇੱਕ ਇੰਸੀਡੈਂਟ ਬਾਅਦ ਇਹ ਬਹਿਸ ਕਰਦੀਆਂ ਹਨ ਕਿ “ਚੰਗਾ” ਕੀ ਸੀ। ਪਰ ਇਹਨਾਂ ਨਾਲ ਤੁਸੀਂ ਸੇਵਾ ਡਿਲਿਵਰੀ, ਸਪੋਰਟ, ਅਤੇ ਭਾਗੀਦਾਰ ਨਿਰਭਰਤਾਵਾਂ ਨੂੰ ਇਕੋ ਸਕੋਰਬੋਰਡ 'ਤੇ ਮਿਲਾ ਸਕਦੇ ਹੋ।
ਹਰ ਸੇਵਾ ਨੂੰ ਸਿਰਫ਼ ਉਪਲਬਧਤਾ ਨਾਲ ਨਹੀਂ ਤੌਲਿਆ ਜਾਣਾ ਚਾਹੀਦਾ। ਆਮ ਉਦਯੋਗੀ-ਲਾਗੂ ਟੀਚਿਆਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਡੇਟਾ ਪŁੈਟਫ਼ਾਰਮਾਂ ਲਈ, "99.9% ਉਪਟਾਈਮ" ਵੀ ਮਾਨਿਆ ਜਾ ਸਕਦਾ ਹੈ ਪਰ ਜੇ ਮੁੱਖ ਡੈਟਾਸੈੱਟ ਦੇਰੀ ਨਾਲ ਆਉਂ ਰਹੇ ਹਨ ਜਾਂ ਗਲਤ ਹਨ ਤਾਂ ਮਹੀਨਾ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ। ਸਹੀ ਇੰਡਿਕੇਟਰ ਚੁਣਕੇ ਗਲਤ ਆਤਮ-ਵਿਸ਼ਵਾਸ ਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਐਰਰ ਬਜਟ SLO ਦੁਆਰਾ ਮਨਜ਼ੂਰ ਕੀਤੇ "ਖਰਾਬੀ" ਦੀ ਇਜਾਜ਼ਤ ਹੈ (ਡਾਊਨਟਾਈਮ, ਫੇਲ ਰਿਕੁਏਸਟ, ਦੇਰ ਵਾਲੇ ਪਾਈਪਲਾਈਨ)। ਇਹ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਇੱਕ ਫੈਸਲਾ ਸੰਦ ਬਣਾਉਂਦਾ ਹੈ:
ਇਸ ਨਾਲ ਉਦਯੋਗੀ ਪ੍ਰਦਾਤਿਆਂ ਨੂੰ ਡਿਲਿਵਰੀ ਵਚਨਾਂ ਅਤੇ ਉਪਟਾਈਮ ਉਮੀਦਾਂ ਵਿਚਕਾਰ ਸੰਤੁਲਨ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ—ਬਿਨਾਂ ਰਾਏ ਜਾਂ ਹਿਯਰਾਰਕੀ 'ਤੇ ਨਿਰਭਰ ਰਹੇ।
ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਰਿਪੋਰਟਿੰਗ ਨੂੰ ਲਕੜੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ:
ਮਕਸਦ ਵਧੇਰੇ ਡੈਸ਼ਬੋਰਡ ਨਹੀਂ—ਇਹ ਲਗਾਤਾਰ, ਕਾਂਟ੍ਰੈਕਟ-ਅਨੁਕੂਲ ਵਿਸ਼ਬਿਲਟੀ ਹੈ ਕਿ ਕੀ ਭਰੋਸੇਯੋਗਤਾ ਨਤੀਜੇ ਕਾਰੋਬਾਰ ਨੂੰ ਸਹਾਇਕ ਹਨ ਜਾਂ ਨਹੀਂ।
ਜਦੋਂ ਉਪਟਾਈਮ ਉਹਦਾ ਹਿੱਸਾ ਹੋ ਜਦ customers ਖਰੀਦਦੇ ਹਨ, ਤਾਂ ਅਬਜ਼ਰਵੇਬਿਲਟੀ ਪਿੱਛੇ ਦਾ ਕੰਮ ਨਹੀਂ ਰਹਿ ਸਕਦੀ। ਉਦਯੋਗੀ ਪੱਧਰ 'ਤੇ—ਖਾਸ ਕਰਕੇ ਭਾਗੀਦਾਰਾਂ ਅਤੇ ਸਾਂਝੇ ਪŁੈਟਫ਼ਾਰਮਾਂ ਵਾਲੇ ਇਕੋਸਿਸਟਮਾਂ ਵਿੱਚ—ਚੰਗੀ ਇੰਸੀਡੈਂਟ ਰਿਸਪਾਂਸ ਦੀ ਸ਼ੁਰੂਆਤ ਇਹੋ ਨਾਲ ਹੁੰਦੀ ਹੈ ਕਿ ਅਪਰੇਟਰ ਸਿਸਟਮ ਨੂੰ ਅਖੀਰ-ਤੱਕ ਓਸੇ ਢੰਗ ਨਾਲ ਵੇਖ ਸਕਣ: end-to-end।
ਉੱਚ-ਕਾਰਗਰ ਟੀਮਾਂ ਲੌਗ, ਮੈਟਰਿਕਸ, ਟਰੇਸ, ਅਤੇ ਸਿੰਥੇਟਿਕ ਚੈਕ ਨੂੰ ਇੱਕ ਸੰਗਠਿਤ ਸਿਸਟਮ ਵਜੋਂ ਮੰਨਦੀਆਂ ਹਨ:
ਹੋਟਲ-ਉਦੇਸ਼ ਤੇਜ਼ ਜਵਾਬ ਹਾਸਲ ਕਰਨ ਲਈ: “ਕੀ ਇਹ ਯੂਜ਼ਰ-ਪ੍ਰਭਾਵਤ ਹੈ?”, “ਬਲਾਸਟ ਰੇਡੀਅਸ ਕਿੰਨਾ ਵੱਡਾ ਹੈ?”, ਅਤੇ “ਹਾਲ ਹੀ ਵਿੱਚ ਕੀ ਬਦਲਿਆ?”
ਉਦਯੋਗੀ ਵਾਤਾਵਰਣ ਅਨੰਤ ਸੰਕੇਤ ਉਤਪੰਨ ਕਰਦੇ ਹਨ। ਉਪਯੋਗੀ ਅਤੇ ਅਣਉਪਯੋਗ ਅਲਰਟ ਵਿਚਕਾਰ ਫ਼ਰਕ ਇਹ ਹੈ ਕਿ ਕੀ ਅਲਰਟਾਂ ਗਾਹਕ-ਮੁਖੀ ਲੱਛਣਾਂ ਅਤੇ ਸਪಷ್ಟ ਸੀਮਾਵਾਂ ਨਾਲ ਜੁੜੀਆਂ ਹਨ। SLO-ਸਟਾਈਲ ਇੰਡਿਕੇਟਰ (ਐਰਰ ਰੇਟ, p95 ਲੈਟੈਂਸੀ) 'ਤੇ ਅਲਰਟਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਔਰ ਅੰਦਰੂਨੀ ਕਾਊਂਟਰਾਂ 'ਤੇ ਨਹੀਂ। ਹਰ ਪੇਜ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਪ੍ਰਭਾਵਤ ਸੇਵਾ, ਸੰਭਾਵਿਤ ਪ੍ਰਭਾਵ, ਮੁੱਖ ਨਿਰਭਰਤਾਵਾਂ, ਅਤੇ ਪਹਿਲਾ ਨਿਰਿਧਾਰਿਤ ਡਾਇਗਨੋਸਟਿਕ ਕਦਮ।
ਇਕੋਸਿਸਟਮ ਸੀਮਾਵਾਂ 'ਤੇ ਫੇਲ ਹੁੰਦੇ ਹਨ। ਉਹਨਾਂ ਨਿਰਭਰਤਾਵਾਂ ਨੂੰ ਦਿਖਾਉਂਦੇ ਹੋਏ ਸਰਵਿਸ ਮੈਪ ਰੱਖੋ—ਅੰਦਰੂਨੀ ਪŁੈਟਫ਼ਾਰਮ, ਵੇਂਡਰ, ਆਈਡੈਂਟੀਟੀ ਪ੍ਰਦਾਤਾ, ਨੈੱਟਵਰਕ—ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਇੰਸੀਡੈਂਟ ਚੈਨਲਾਂ 'ਚ ਦਿੱਖਦਾ ਕਰੋ। ਭਾਵੇਂ ਭਾਗੀਦਾਰ ਟੈਲੀਮੇਟ੍ਰੀ ਸੀਮਿਤ ਹੋਵੇ, ਤੁਸੀਂ ਫਿਰ ਵੀ ਐਜ ਸਿੰਥੇਟਿਕ ਚੈਕ, ਐਡਜ ਮੈਟਰਿਕਸ, ਅਤੇ ਸਾਂਝੇ অনুরোধ IDs ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਨਿਰਭਰਤਾਵਾਂ ਨੂੰ ਮਾਡਲ ਕਰ ਸਕਦੇ ਹੋ।
ਦੋਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਕਾਰਵਾਈਆਂ (rollback, feature flag disable, traffic shift) ਨੂੰ ਆਟੋਮੇਟ ਕਰੋ ਜਿਹੜੇ_TIME-ਟੂ-ਮਿਟਿਗੇਟ ਘਟਾਉਂਦੇ ਹਨ। ਜਿਨ੍ਹਾਂ ਫੈਸਲਿਆਂ ਵਿੱਚ ਜੱਜਮੈਂਟ ਲੋੜੀਦੀ ਹੈ (ਗਾਹਕ ਸੰਚਾਰ, ਐਸਕਲੇਸ਼ਨ ਪਾਥ, ਭਾਗੀਦਾਰ ਕੋਆਰਡੀਨੇਸ਼ਨ), ਉਹਨਾਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਚੰਗਾ ਰਨਬੁਕ ਛੋਟਾ, ਅਸਲੀ ਇੰਸੀਡੈਂਟਾਂ ਦੌਰਾਨ ਟੈਸਟ ਕੀਤਾ ਹੋਇਆ ਅਤੇ ਪੋਸਟ-ਇੰਸੀਡੈਂਟ ਫਾਲੋ-ਅੱਪ ਵਿੱਚ ਅਪਡੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
Samsung SDS-ਕਿਸਮ ਦੇ ਇਕੋਸਿਸਟਮਾਂ ਵਿੱਚ “ਸੁਰੱਖਿਅਤ” ਅਤੇ “ਤੇਜ਼” ਵਿਚੋਂ ਚੁਣਣਾ ਨਹੀਂ ਹੋ ਸਕਦਾ। ਟ੍ਰਿਕ ਇਹ ਹੈ ਕਿ ਚੇਂਜ ਕੰਟਰੋਲ ਨੂੰ ਇੱਕ ਭਰੋਸੇਯੋਗ ਪ੍ਰਣਾਲੀ ਬਣਾਇਆ ਜਾਵੇ: ਘੱਟ-ਜੋਖਮ ਵਾਲੇ ਬਦਲਾਅ ਤੇਜ਼ੀ ਨਾਲ ਵਹਿ ਜਾਣ, ਜਦਕਿ ਉੱਚ-ਜੋਖਮ ਵਾਲੇ ਬਦਲਾਅ ਉਹ ਧਿਆਨ ਪਾਉਣ ਜੋਗੇ।
ਵੱਡੇ-ਬੈਂਗ ਰੀਲੀਜ਼ ਵੱਡੇ-ਬੈਂਗ ਆਊਟੇਜ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਟੀਮਾਂ ਉਪਟਾਈਮ ਉੱਚੀ ਰੱਖਣ ਲਈ ਛੋਟੇ ਟੁਟਕਿਆਂ ਵਿੱਚ ਸ਼ਿਪ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਇਕੇ ਵਾਰੀ ਘੱਟ ਚੀਜ਼ਾਂ ਜੋ ਗਲਤ ਹੋ ਸਕਦੀਆਂ ਹਨ ਨੂੰ ਘਟਾਉਂਦੀਆਂ ਹਨ।
ਫੀਚਰ ਫਲੈਗਸ “ਡਿਪਲੋਇ” ਨੂੰ “ਰੀਲੀਜ਼” ਤੋਂ ਅਲাদা ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ, ਤਾਂ ਕਿ ਕੋਡ ਪ੍ਰੋਡਕਸ਼ਨ ਤਕ ਪਹੁੰਚ ਸਕੇ ਬਿਨਾਂ ਤੁਰੰਤ ਉਪਭੋਗਤਿਆਂ 'ਤੇ ਪ੍ਰਭਾਵ ਪਏ। ਕੰਨਰੀ ਡਿਪਲੋਇਮੈਂਟ (ਸਿਰਫ਼ ਇੱਕ ਛੋਟਾ ਸੈਟ 'ਤੇ ਰਿਲੀਜ਼) ਪਹਿਲਾਂ ਸੂਚਨਾ ਦਿੰਦਾ ਹੈ ਕਿ ਬਦਲਾਅ ਹਰ ਇੱਕ ਕਾਰੋਬਾਰੀ ਯੂਨਿਟ, ਭਾਗੀਦਾਰ ਇੰਟੀਗ੍ਰੇਸ਼ਨ, ਜਾਂ ਖੇਤਰ ਨੂੰ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ।
ਰੀਲੀਜ਼ ਗਵਰਨੈਂਸ ਸਿਰਫ਼ ਕਾਗਜ਼ਾਤ ਨਹੀਂ—ਇਹ ਉਦਯੋਗਾਂ ਨੂੰ ਸੰਕਟੀਂ ਸੁਰੱਖਿਅਤ ਕਰਨ ਅਤੇ ਨਿਯੰਤਰਣ ਸਬੂਤ ਪੇਸ਼ ਕਰਨ ਦਾ ਤਰੀਕਾ ਹੈ। ਇੱਕ ਪ੍ਰਯੋਗਾਤਮਕ ਮਾਡਲ ਵਿੱਚ ਸ਼ਾਮਲ ਹੈ:
ਲਕੜੀ ਮਿਸ਼ਨ ਇਹ ਹੈ ਕਿ “ਸਹੀ ਤਰੀਕਾ” ਆਸਾਨ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਵਿੱਚ ਆਵੇ: ਮਨਜ਼ੂਰੀਆਂ ਅਤੇ ਸਬੂਤ ਤੇਜ਼ੀ ਨਾਲ ਕੈਪਚਰ ਕਰ ਲਏ ਜਾਣ, ਨਾ ਕਿ ਬਾਦ ਵਿੱਚ ਇਕੱਠੇ ਕੀਤੇ ਜਾਣ।
ਇਕੋਸਿਸਟਮਾਂ ਦੇ ਪੇਸ਼ਗੀ ਦਬਾਅ ਬਿੰਦੂ ਹੋਂਦੇ ਹਨ: ਮਹੀਨੇ ਦੇ ਅੰਤ ਦੀ ਫਾਇਨੈਂਸ ਕਲੋਜ਼, ਪੀਕ ਰੀਟੇਲ ਇਵੈਂਟ, ਸਾਲਾਨਾ ਐਨਰੋਲਮੈਂਟ, ਜਾਂ ਮੁੱਖ ਭਾਗੀਦਾਰ ਕਟਓਵਰ। ਚੇਂਜ ਵਿੰਡੋਜ਼ ਉਹਨਾਂ ਦੌਰਾਂ ਨੂੰ ਸਮਾਈਕਿਤ ਕਰਦੀਆਂ ਹਨ।
ਬਲੈਕਆਊਟ ਅਵਧੀਆਂ ਸਪਸ਼ਟ ਅਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਤਾਂ ਜੋ ਟੀਮਾਂ ਪਹਿਲਾਂ ਤੋਂ ਯੋਜਨਾ ਬਣਾਉਣ ਅਤੇ ਫ੍ਰੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਖਤਰਨਾਕ ਕੰਮ ਨੂੰ ਲੰਘਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰਨ।
ਹਰ ਬਦਲਾਅ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਵਾਪਸ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ—ਖਾਸ ਕਰਕੇ ਸਕੀਮਾ ਬਦਲਾਵਾਂ ਜਾਂ ਕ੍ਰਾਸ-ਕੰਪਨੀ ਇੰਟੀਗ੍ਰੇਸ਼ਨਾਂ ਲਈ। ਮਜ਼ਬੂਤ ਚੇਂਜ ਕੰਟਰੋਲ ਲਈ ਪਹਿਲਾਂ ਤੋਂ ਨਿਰਧਾਰਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਜਦ ਟੀਮਾਂ ਇਹ ਰਸਤੇ ਪਹਿਲਾਂ ਤੋਂ ਨਿਰਧਾਰਤ ਕਰ ਲੈਂਦੀਆਂ ਹਨ, ਤਾਂ ਇੰਸੀਡੈਂਟ ਲੰਮੀ-ਅਵਧੀ improvisation ਦੀ ਥਾਂ ਨਿਯੰਤਰਿਤ ਸੁਧਾਰ ਬਣ ਜਾਂਦੇ ਹਨ।
ਰੇਜ਼ੀਲਿਆੰਸ ਇੰਜੀਨੀਅਰਿੰਗ ਇੱਕ ਸਧਾਰਨ ਧਾਰਨਾ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ: ਕੁਝ ਟੁਟੇਗਾ—ਇੱਕ ਅੱਪਸਟਰੀਮ API, ਇੱਕ ਨੈੱਟਵਰਕ ਸੈਗਮੈਂਟ, ਇੱਕ ਡੇਟਾਬੇਸ ਨੋਡ, ਜਾਂ ਕੋਈ ਤੀਜੀ-ਪਾਰਟੀ ਨਿਰਭਰਤਾ ਜਿਨ੍ਹਾਂ 'ਤੇ ਤੁਹਾਡਾ ਕਾਬੂ ਨਹੀਂ। ਉਦਯੋਗੀ ਇਕੋਸਿਸਟਮਾਂ ਵਿੱਚ (Jithe Samsung SDS-ਟਾਇਪ ਪ੍ਰਦਾਤਾ ਬਹੁਤ ਸਾਰੇ ਬਿਜ਼ਨਸ ਯੂਨਿਟਾਂ ਅਤੇ ਭਾਗੀਦਾਰਾਂ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ), ਟੀਚਾ "ਕੋਈ ਫੇਲਿਊਰ ਨਹੀਂ" ਨਹੀਂ ਹੁੰਦਾ, ਬਲਕਿ ਨਿਯੰਤ੍ਰਿਤ ਫੇਲਿਊਰ ਜਿਨ੍ਹਾਂ ਦੀ ਰਿਕਵਰੀ ਪੂਰਵ-ਅਨੁਮਾਨਯੋਗ ਹੋਵੇ।
ਕੁਝ ਪੈਟਰਨ ਜੋ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹਨ:
ਕੁੰਜੀ ਇਹ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਯਾਤਰਾਵਾਂ "ਜਰੂਰੀ ਬਚਾਈਆਂ" ਜਾਣੀਆਂ ਹਨ ਅਤੇ ਉਹਨਾਂ ਲਈ ਖਾਸ fallback ਤਯਾਰ ਕਰਨਾ।
ਡਿਜਾਸਟਰ ਰਿਕਵਰੀ ਦੀ ਯੋਜਨਾ ਪ੍ਰਯੋਗਾਤਮਕ ਬਣ ਜਾਂਦੀ ਹੈ ਜਦ ਹਰ ਸਿਸਟਮ ਲਈ ਨਿਰਧਾਰਤ ਟੀਚੇ ਹੋਣ:
ਹਰੇਕ ਚੀਜ਼ ਨੂੰ ਇੱਕੋ ਨੰਬਰਾਂ ਦੀ ਲੋੜ ਨਹੀਂ। ਇਕ ਗਾਹਕ ਆਈਡੈਂਟੀਟੀ ਸੇਵਾ ਲਈ ਮਿੰਟਾਂ ਦਾ RTO ਅਤੇ near-zero RPO ਲੋੜਦੀ ਹੋ ਸਕਦੀ ਹੈ, ਜਦਕਿ ਇਕ ਅੰਦਰੂਨੀ ਐਨੇਲਿਟਿਕਸ ਪਾਈਪਲਾਈਨ ਘੰਟਿਆਂ ਨੂੰ ਬਰਦਾਸ਼ਤ ਕਰ ਸਕਦੀ ਹੈ। RTO/RPO ਨੂੰ ਕਾਰੋਬਾਰਕ ਪ੍ਰਭਾਵ ਨਾਲ ਮਿਲਾ ਕੇ ਖਰਚ ਸਾਬਤ ਕਰਨ ਤੋਂ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਜਰੂਰੀ ਚੀਜ਼ਾਂ ਦੀ ਰੱਖਿਆ ਹੋ ਸਕਦੀ ਹੈ।
ਮਹੱਤਵਪੂਰਨ ਵਰਕਫਲੋਜ਼ ਲਈ replication ਚੋਣਾਂ ਮਾਇਨੇ ਰੱਖਦੀਆਂ ਹਨ। synchronous replication ਡੇਟਾ ਲੋਸ ਨੂੰ ਘਟਾ ਸਕਦੀ ਹੈ ਪਰ ਲੈਟੈਂਸੀ ਵਧਾ ਸਕਦੀ ਹੈ ਜਾਂ ਨੈੱਟਵਰਕ ਸਮੱਸਿਆਵਾਂ ਦੌਰਾਨ ਉਪਲਬਧਤਾ ਘਟਾ ਸਕਦੀ ਹੈ। asynchronous replication ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਉਪਲਬਧਤਾ ਸੁਧਾਰਦੀ ਹੈ ਪਰ ਨਵੀਂ ਲਿਖਤਾਂ ਖੋ ਸਕਦੀ ਹੈ। ਚੰਗੀਆਂ ਡਿਜ਼ਾਈਨਾਂ ਇਹਨਾਂ ਟਰੇਡ-ਆਫ਼ਸ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਪ੍ਰਭਾਵਸ਼ੀਲ ਨਿਯੰਤਰਣ (idempotency, reconciliation jobs, ਜਾਂ "pending" ਸੂਚਨਾਵਾਂ) ਸ਼ਾਮਿਲ ਕਰਦੀਆਂ ਹਨ।
ਰੇਜ਼ੀਲਿਆੰਸ ਗਿਣਤੀ ਖਾਤਰ ਹੈ ਜੇਕਰ ਇਸਨੂੰ ਅਭਿਆਸ ਕੀਤਾ ਨਾ ਜਾਵੇ:
ਇਹਨਾਂ ਨੂੰ ਨਿਯਮਤ ਰੂਪ ਵਿੱਚ ਚਲਾਓ, ਰਿਕਵਰੀ ਦਾ ਸਮਾਂ ਟ੍ਰੈਕ ਕਰੋ, ਅਤੇ ਨਤੀਜਿਆਂ ਨੂੰ ਪŁੈਟਫ਼ਾਰਮ ਮਿਆਰ ਅਤੇ ਸੇਵਾ ਮਾਲਕੀ ਵਿੱਚ ਫੀਡ ਕਰੋ।
ਸੁਰੱਖਿਆ ਫੇਲਿਊਰ ਅਤੇ ਅਨੁਕੂਲਤਾ ਦੀਆਂ ਘਾਟੀਆਂ ਸਿਰਫ਼ ਜੋਖਮ ਪੈਦਾ ਨਹੀਂ ਕਰਦੀਆਂ—ਉਹ ਡਾਊਨਟਾਈਮ ਵੀ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਉਦਯੋਗੀ ਇਕੋਸਿਸਟਮਾਂ ਵਿੱਚ, ਇੱਕ ਗਲਤ ਸੰਰਚਿਤ ਖਾਤਾ, ਅਨਪੈਚਡ ਸਰਵਰ, ਜਾਂ ਗੁੰਮ ਆਡਿਟ ਟਰੇਲ ਸਿਸਟਮ ਨੂੰ ਫ੍ਰੀਜ਼ ਕਰ ਸਕਦੇ ਹਨ, ਐਮਰਜੈਂਸੀ ਚੇਂਜਾਂ ਅਤੇ ਗਾਹਕ-ਪ੍ਰਭਾਵਤ ਆਊਟੇਜਾਂ ਦਾ ਕਾਰਨ ਬਣਦੇ ਹਨ। ਸੁਰੱਖਿਆ ਅਤੇ ਅਨੁਕੂਲਤਾ ਨੂੰ ਭਰੋਸੇਯੋਗਤਾ ਦਾ ਹਿੱਸਾ ਮੰਨ ਕੇ "ਚੱਲਦੇ ਰਹਿਣ" ਸਾਰਥਕ ਲਕੜੀ ਬਣ ਜਾਂਦੀ ਹੈ।
ਜਦ ਕਈ ਸਬਸਿਡੀਅਰੀਜ਼, ਭਾਗੀਦਾਰ, ਅਤੇ ਵੇਂਡਰ ਇਕੋ ਸੇਵਾਵਾਂ ਨਾਲ ਜੁੜਦੇ ਹਨ ਤਾਂ ਆਈਡੈਂਟੀਟੀ ਇੱਕ ਭਰੋਸੇਯੋਗਤਾ ਨਿਯੰਤਰਣ ਬਣ ਜਾਂਦਾ ਹੈ। SSO ਅਤੇ ਫੈਡਰੇਸ਼ਨ ਪਾਸਵਰਡ-ਸਪਲਾਈ ਅਤੇ ਖ਼ਤਰਨਾਕ ਵਰਕਏਰਾਊਂਡ ਘਟਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਬਿਨਾਂ ਜ਼ਿਆਦਾ ਘਟਨਾ ਦੇ ਪਹੁੰਚ ਮਿਲਦੀ ਹੈ। ਥੋੜ੍ਹਾ-ਅਧਿਕਾਰ (least privilege) ਵੀ ਮੁੱਖ ਹੈ: ਪਹੁੰਚ ਸਮੇਂ-ਬੱਧ, ਭੂਮਿਕਾ ਆਧਾਰਤ ਅਤੇ ਨਿਯਮਤ ਸਮੀਖਿਆ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਕਿ ਸਮਝੋਤਾ ਕੀਤੇ ਖਾਤੇ ਨਾਲ ਕੋਰ ਸਿਸਟਮ ਡਾਊਨ ਨਾ ਹੋ ਸਕਣ।
ਸੁਰੱਖਿਆ ਓਪਰੇਸ਼ਨ ਇੰਸੀਡੈਂਟਾਂ ਨੂੰ ਰੋਕ ਸਕਦੀਆਂ ਹਨ—ਜਾਂ ਗੈਰ-ਯੋਜਿਤ ਵਿੱਥ-ਕਾਰਵਾਈ ਕਰਕੇ ਇੰਸੀਡੈਂਟ ਪੈਦਾ ਵੀ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਸੁਰੱਖਿਆ ਕੰਮ ਨੂੰ ਓਪਰੇਸ਼ਨਲ ਭਰੋਸੇਯੋਗਤਾ ਨਾਲ ਜੋੜੋ:
ਅਨੁਕੂਲਤਾ ਦੀਆਂ ਲੋੜਾਂ (ਰੀਟੈਨਸ਼ਨ, ਪਰਾਈਵੇਸੀ, ਆਡਿਟ ਟਰੇਲ) ਪŁੈਟਫ਼ਾਰਮਾਂ ਵਿੱਚ ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੋਣ 'ਤੇ ਸਭ ਤੋਂ ਆਸਾਨ ਪੂਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਕੇਂਦਰੀ ਲੋਗਿੰਗ ਨਾਲ ਇੱਕਸਰ ਖੇਤਰ, ਲਾਗ ਫੀਲਡਾਂ ਦੀ ਅਨੁਸਾਰੀ, ਅਤੇ ਪਹੁੰਚ-ਕਾਬੂ ਐਕਸਪੋਰਟ ਆਡਿਟਾਂ ਨੂੰ ਅੱਗ-ਬਹਿਲ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ—ਅਤੇ "ਸਿਸਟਮ ਫ੍ਰੀਜ਼" ਵਾਲੇ ਪਲਾਂ ਨੂੰ ਰੋਕਦੇ ਹਨ ਜੋ ਡਿਲਿਵਰੀ ਨੂੰ ਰੋਕ ਸਕਦੇ ਹਨ।
ਭਾਗੀਦਾਰ ਇੰਟੀਗ੍ਰੇਸ਼ਨਾਂ ਸਮਰੱਥਾ ਅਤੇ ਬਲਾਸਟ ਰੇਡੀਅਸ ਵਧਾਉਂਦੀਆਂ ਹਨ। ਤੀਜੀ-ਪਾਰਟੀ ਜੋਖਮ ਨੂੰ ਘਟਾਓ: ਐਕਸਪਲਿਸਿਟ ਸੁਰੱਖਿਆ ਬੇਸਲਾਈਨ, ਵਰਜਨ ਕੀਤਾ API, ਸਾਫ਼ ਡੇਟਾ-ਹੈਂਡਲਿੰਗ ਨਿਯਮ, ਅਤੇ ਨਿਰਭਰਤਾ ਸਿਹਤ ਦੀ ਲਗਾਤਾਰ ਨਿਗਰਾਨੀ। ਜੇ ਕਿਸੇ ਭਾਗੀਦਾਰ ਫੇਲ ਕਰਦਾ ਹੈ, ਤੁਹਾਡੀ ਪ੍ਰਣਾਲੀ ਗ੍ਰੇਸਫੁੱਲੀ ਡੀਗਰੇਡ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਬਜਾਏ ਅਣਪੇਸ਼ਵਾਗ਼ਤ ਫੇਲ ਹੋਣ ਦੇ।
ਜਦ ਉਦਯੋਗੀ ਲੋਕ ਉਪਟਾਈਮ ਦੀ ਗੱਲ ਕਰਦੇ ਹਨ, ਉਹ ਅਕਸਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਅਤੇ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਮੱਨ ਲੈਂਦੇ ਹਨ। ਪਰ ਬਹੁਤ ਸਾਰੇ ਇਕੋਸਿਸਟਮ ਵਰਕਫਲੋਜ਼—ਬਿਲਿੰਗ, ਫਲਫਿਲਮੈਂਟ, ਰਿਸਕ, ਰਿਪੋਰਟਿੰਗ—ਲਈ ਡੇਟਾ ਸਹੀਤਾ ਵੀ ਉਪਰੇਸ਼ਨਲ ਤੌਰ 'ਤੇ ਐੱਕੋ-ਉਤਪਾਦਕ ਹੁੰਦੀ ਹੈ। ਇੱਕ "ਸਫਲ" ਬੈਚ ਜੋ ਗਲਤ ਗਾਹਕ ਪਛਾਣ ਛਾਪਦਾ ਹੈ, ਭਾਗੀਦਾਰਾਂ ਵਿੱਚ ਘੰਟਿਆਂ ਦੇ downstream ਇੰਸੀਡੈਂਟ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ।
ਮਾਸਟਰ ਡੇਟਾ (ਗਾਹਕ, ਉਤਪਾਦ, ਵੇਂਡਰ) ਉਹ ਰੈਫ਼ਰੰਸ ਹੁੰਦਾ ਹੈ ਜਿਸ 'ਤੇ ਹਰ ਚੀਜ਼ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਇਸਨੂੰ ਭਰੋਸੇਯੋਗਤਾ ਦੀ ਸਤਹ ਸਮਝ ਕੇ ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ "ਚੰਗਾ" ਕੀ ਹੈ (ਪੂਰਨਤਾ, ਵਿਲੱਖਣਤਾ, ਸਮੇਂ-ਸਮੇਂ ਤੇ ਤਾਜ਼ਗੀ) ਅਤੇ ਇਸਨੂੰ ਲਗਾਤਾਰ ਮਾਪੋ।
ਇੱਕ ਪ੍ਰਯੋਗਾਤਮਕ ਤਰੀਕਾ ਛੋਟੇ ਕਾਰੋਬਾਰ-ਮੁੱਖ ਗੁਣਵੱਤਾ ਸੰਕੇਤਕਾਂ ਨੂੰ ਟ੍ਰੈਕ ਕਰਨਾ ਹੈ (ਉਦਾਹਰਨ: "% ਆਰਡਰ ਜੋ ਇੱਕ ਵੈਧ ਗਾਹਕ ਨਾਲ ਮੈਪ ਕੀਤੇ ਗਏ") ਅਤੇ ਜਦੋਂ ਉਹ ਡਿ੍ਰਫਟ ਕਰਨ, ਅਲਰਟ ਕਰੋ—ਤਾਂ ਜੋ ਡਾਊਨਸਟ੍ਰੀਮ ਸਿਸਟਮ ਫੇਲ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਮਸਲੇ ਦਿਖਾਈ ਦੇਣ।
ਬੈਚ ਪਾਈਪਲਾਈਨ ਨਿਯਮਤ ਰਿਪੋਰਟਿੰਗ ਵਿੰਡੋਜ਼ ਲਈ ਉਚਿਤ ਹਨ; ਸਟ੍ਰੀਮਿੰਗ ਨਜ਼ਦੀਕੀ-ਰਿਆਲ-ਟਾਈਮ ਕਾਰੋਬਾਰ ਲਈ ਬਿਹਤਰ। ਸਕੇਲ 'ਤੇ, ਦੋਹਾਂ ਨੂੰ ਗਾਰਡਰੇਲ ਦੀ ਲੋੜ ਹੈ:
ਭਰੋਸਾ ਵਧਦਾ ਹੈ ਜਦ ਟੀਮ ਤਿੰਨ ਸਵਾਲਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੇ ਸਕਦੀ ਹੈ: ਇਹ ਫੀਲਡ ਕਿੱਥੋਂ ਆਇਆ? ਕੌਣ ਇਸਨੂੰ ਵਰਤਦਾ ਹੈ? ਬਦਲਾਅ ਕੌਣ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ?
ਲਾਈਨਿਜ਼ ਅਤੇ ਕੈਟਾਲੋਗਿੰਗ "ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ ਪ੍ਰੋਜੈਕਟ" ਨਹੀਂ ਹਨ—ਉਹ ਆਪਰੇਸ਼ਨਲ ਟੂਲ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਸਪਸ਼ਟ ਸਟੀਵਰਡਸ਼ਿਪ ਨਾਲ ਜੋੜੋ: ਮਹੱਤਵਪੂਰਨ ਡੈਟਾਸੈੱਟਾਂ ਲਈ ਨਾਮਜ਼ਦ ਮਾਲਕ, ਪਰਿਭਾਸ਼ਤ ਪਹੁੰਚ ਨੀਤੀਆਂ, ਅਤੇ ਉੱਚ-ਪ੍ਰਭਾਵ ਬਦਲਾਵਾਂ ਲਈ ਹਲਕੀ-ਫੁਲਕੀ ਸਮੀਖਿਆ।
ਇਕੋਸਿਸਟਮ ਸਰਹੱਦਾਂ 'ਤੇ ਫੇਲ ਹੁੰਦੇ ਹਨ। ਭਾਗੀਦਾਰ-ਸੰਬੰਧੀ ਇੰਸੀਡੈਂਟ ਘਟਾਉਣ ਲਈ ਡੇਟਾ ਕਾਂਟ੍ਰੈਕਟ ਲਗਾਓ: ਵਰਜ਼ਨ ਕੀਤੇ ਸਕੀਮੇ, ਵੈਰਿਫਿਕੇਸ਼ਨ ਨਿਯਮ, ਅਤੇ ਕੰਪੈਟਬਿਲਟੀ ਉਮੀਦਾਂ। ਇੰਧਨ ਤੇ ਸਹੀਤੇ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਵੈਰੀਫਾਈ ਕਰੋ, ਖ਼ਰਾਬ ਰਿਕਾਰਡਾਂ ਨੂੰ quarantine ਕਰੋ, ਅਤੇ ਸਪਸ਼ਟ ਐਰਰ ਫੀਡਬੈਕ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ ਤਾ ਕਿ ਸਮੱਸਿਆਵਾਂ ਸਰੋਤ 'ਤੇ ਠੀਕ ਕੀਤੀਆਂ ਜਾਣ, ਡਾਊਨਸਟ੍ਰੀਮ 'ਤੇ ਪੈਚ ਕਰਨ ਦੀ ਥਾਂ।
ਉਦਯੋਗੀ ਪੱਧਰ 'ਤੇ ਭਰੋਸੇਯੋਗਤਾ ਸਭ ਤੋਂ ਵੱਧ ਅਕਸਰ ਟੀਮਾਂ, ਵੇਂਡਰਾਂ, ਅਤੇ "ਚਲਾਉ" ਅਤੇ "ਬਨਾਓ" ਦੇ ਦੂਰੇ ਵਿਕਲਪਾਂ ਦੇ ਦਰਮਿਆਨ ਦੇ ਖਾਈ ਵਿੱਚ ਫੇਲ ਹੁੰਦੀ ਹੈ। ਗਵਰਨੈਂਸ ਬੇਕਾਰ ਬਿਊਰੋਕਰੇਸੀ ਨਹੀਂ—ਇਹ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਮਾਲਕੀ ਸਪਸ਼ਟ ਬਣਾਉਂਦੇ ਹੋ ਤਾਂ ਜੋ ਇੰਸੀਡੈਂਟ ਘੰਟਿਆਂ ਦੀ ਬਹਿਸ ਨਾ ਬਣਨ।
ਦੋ ਆਮ ਮਾਡਲ ਹਨ:
ਬਹੁਤ ਸਾਰੀਆਂ ਸੰਸਥਾਵਾਂ ਹਾਈਬ੍ਰਿਡ 'ਤੇ ਆਉਂਦੀਆਂ ਹਨ: ਪŁੈਟਫ਼ਾਰਮ ਟੀਮਾਂ ਪ paved roads ਪ੍ਰਦਾਨ ਕਰਦੀਆਂ ਹਨ, ਜਦਕਿ ਪ੍ਰੋਡਕਟ ਟੀਮਾਂ ਜੋ ਉਹ ਨਹੀਂ ਸ਼ਿਪ ਕਰਦੀਆਂ ਉਹਨਾਂ ਲਈ ਭਰੋਸੇਯੋਗਤਾ ਦੀ ਮਾਲਕੀ ਰੱਖਦੀਆਂ ਹਨ।
ਇੱਕ ਭਰੋਸੇਯੋਗ ਸੰਗਠਨ ਇੱਕ ਸੇਵਾ ਕੈਟਾਲੋਗ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜੋ ਪ੍ਰਸ਼ਨ ਦਾ ਜਵਾਬ ਦਿੰਦਾ: ਇਹ ਸੇਵਾ ਕੌਣ ਚਲਾਂਦਾ ਹੈ? ਸਹਾਇਤਾ ਘੰਟੇ ਕਿਹੜੇ ਹਨ? ਮੁੱਖ ਨਿਰਭਰਤਾਵਾਂ ਕੀ ਹਨ? ਐਸਕਲੇਸ਼ਨ ਪਾਥ ਕੀ ਹੈ?
ਉਮੀਦ ਕੀਤੀ ਜਾਣ ਵਾਲੀ ਵਸਤੂਆਂ ਵਿੱਚ ਮਾਲਕੀ ਸੀਮਾਵਾਂ ਵੀ ਹਨ: ਕਿਹੜੀ ਟੀਮ ਡੇਟਾਬੇਸ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਮਿਡਲਵੇਅਰ, ਆਈਡੈਂਟੀਟੀ, ਨੈੱਟਵਰਕ ਨਿਯਮ, ਅਤੇ ਮਾਨੀਟਰਨਿੰਗ ਦੀ ਮਾਲਕੀ ਰੱਖਦੀ ਹੈ। ਜਦੋਂ ਸੀਮਾਵਾਂ ਅਸਪਸ਼ਟ ਹੁੰਦੀਆਂ ਹਨ, ਇੰਸੀਡੈਂਟ ਟੈਕਨਿਕਲ ਸਮੱਸਿਆਵਾਂ ਦੀ ਥਾਂ ਕੋਆਰਡੀਨੇਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਬਣ ਜਾਂਦੇ ਹਨ।
ਇਕੋਸਿਸਟਮ-ਭਾਰੀ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ, ਭਰੋਸੇਯੋਗਤਾ ਦਾ ਨਿਰਭਰ SLAs ਤੇ ਹੈ। SLAs ਗਾਹਕ-ਮੁਖੀ ਵਚਨਬੱਧਤਾਵਾਂ ਲਈ, OLAs ਅੰਦਰੂਨੀ ਹੈਂਡਅਫ਼ਸ ਲਈ, ਅਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਕਾਂਟ੍ਰੈਕਟ ਵਰਜਨਿੰਗ, ਰੇਟ ਲਿਮਿਟ, ਚੇਂਜ ਵਿੰਡੋਜ਼, ਅਤੇ ਰੋਲਬੈਕ ਉਮੀਦਾਂ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ—ਤਾਂ ਜੋ ਭਾਗੀਦਾਰ ਤੁਹਾਨੂੰ ਬੇਉਕੂਫੀ ਨਾਲ ਭੰਗ ਨਾ ਕਰ ਸਕਣ।
ਗਵਰਨੈਂਸ ਨੂੰ ਸਿੱਖਣ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ:
ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੀਤੀ ਗਈ ਗਵਰਨੈਂਸ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ “ਹਰ ਕਿਸੇ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ” ਤੋਂ ਇਕ ਮਾਪਯੋਗ, ਮਾਲਕ ਬਣਾਉਂਦੀ ਹੈ।
ਤੁਹਾਨੂੰ "Samsung SDS ਬਣਨ" ਦੀ ਲੋੜ ਨਹੀਂ ਕਿ ਤੁਸੀਂ ਇਕੋ ਹੀ ਆਪਰੇਟਿੰਗ ਨੀਤੀਆਂ ਤੋਂ ਲਾਭ ਪ੍ਰਾਪਤ ਕਰੋ। ਮਕਸਦ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਇੱਕ ਪ੍ਰਬੰਧਿਤ ਸਮਰੱਥਾ ਬਣਾਉਣਾ ਹੈ: ਵਿਖਾਈ ਦੇਣਯੋਗ, ਮਾਪਯੋਗ, ਅਤੇ ਛੋਟੇ, ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਕਦਮਾਂ ਵਿੱਚ ਸੁਧਾਰਯੋਗ।
ਹਫ਼ਤੇ ਦੇ ਅੰਦਰ ਵਰਤੋਂਯੋਗ ਹੋਣ ਵਾਲੀ ਇੱਕ ਸੇਵਾ ਇਨਵੈਂਟਰੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ—ਪਰਫੈ਼ਕਟ ਨਹੀਂ।
ਇਹ ਪ੍ਰਾਥਮਿਕਤਾ ਨਿਰਧਾਰਨ, ਇੰਸੀਡੈਂਟ ਰਿਸਪਾਂਸ, ਅਤੇ ਚੇਂਜ ਕੰਟਰੋਲ ਲਈ ਬੁਨਿਆਦ ਬਣ ਜਾਂਦੀ ਹੈ।
ਵੱਖ-ਵੱਖ ਜੋਖਮ ਖੇਤਰਾਂ ਵਿੱਚ 2–4 ਉੱਚ- ਪ੍ਰਭਾਵ SLOs ਚੁਣੋ (ਉਪਲਬਧਤਾ, ਲੈਟੈਂਸੀ, ਤਾਜ਼ਗੀ, ਸਹੀਤਾ)। ਉਦਾਹਰਨ:
ਐਰਰ ਬਜਟ ਟ੍ਰੈਕ ਕਰੋ ਅਤੇ ਉਹ ਫੈਸਲੇ ਕਰਨ ਲਈ ਵਰਤੋਂ: ਫੀਚਰ ਕੰਮ ਰੋਕਣਾ, ਚੇਂਜ ਵਾਲਿਊਮ ਘਟਾਉਣਾ, ਜਾਂ ਸੁਧਾਰ ਵਿੱਚ ਨਿਵੇਸ਼।
ਟੂਲਸ ਦੀ ਭਰਮਭੇਰੀ ਅਕਸਰ ਮੂਢੀ ਖਾਮੀਆਂ ਛੁਪਾਉਂਦੀ ਹੈ। ਪਹਿਲਾਂ ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ "ਚੰਗੀ ਵਿਜ਼ੀਬਿਲਿਟੀ" ਦਾ ਕੀ ਅਰਥ ਹੈ:
ਜੇ ਤੁਸੀਂ ਕMinutes ਵੀ ਨਹੀਂ ਵਿੱਚ “ਕੀ ਟੁੱਟਿਆ, ਕਿੱਥੇ, ਅਤੇ ਕੌਣ ਮਾਲਕ ਹੈ?” ਦਾ ਜਵਾਬ ਦੇ ਸਕਦੇ, ਤਾਂ ਪਹਿਲਾਂ ਸਾਫ਼-ਹੋਰ ਬਣਾਓ ਅਤੇ ਫਿਰ ਨਵੇਂ ਵੇਂਡਰ ਸੋਚੋ।
ਇਕੋਸਿਸਟਮ ਸਰਹੱਦਾਂ ਤੇ ਫੇਲ ਹੁੰਦੇ ਹਨ। ਭਾਗੀਦਾਰ-ਸਮਾਂਧੀ ਤਬਦੀਲੀਆਂ ਨੂੰ ਘਟਾਉਣ ਲਈ ਦੱਸੋ:
ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਮਿਆਰ ਨੂੰ ਇੱਕ ਉਤਪਾਦ ਵਜੋਂ ਚਾਰਿਤ ਕਰੋ: ਦਸਤਾਵੇਜ਼ੀਕ੍ਰਤ, ਸਮੀਖਿਆ ਕੀਤੀ, ਅਤੇ ਅਪਡੇਟ ਕੀਤੀ ਜਾਂਦੀ।
3–5 ਸੇਵਾਵਾਂ 'ਤੇ 30 ਦਿਨਾਂ ਪਾਇਲਟ ਚਲਾਓ, ਫਿਰ ਫੈਲਾ ਕਰੋ। ਹੋਰ ਟੈਂਪਲੇਟ ਅਤੇ ਉਦਾਹਰਣਾਂ ਲਈ, ਵੇਖੋ /blog.
ਜੇ ਤੁਸੀਂ ਟੀਮਾਂ ਨੂੰ ਨਵੀਕਰਨ ਕਰ ਰਹੇ ਹੋ—ਜੋ ਬਣਾਉਂਦੀਆਂ ਅਤੇ ਚਲਾਉਂਦੀਆਂ ਦੋਹਾਂ ਹਨ—ਤਾਂ ਰਨਟਾਈਮ ਅਤੇ ਅਬਜ਼ਰਵੇਬਿਲਟੀ ਨੂੰ ਸਾਲਿਡ ਕਰਨ ਦੇ ਨਾਲ-ਨਾਲ ਬਣਾਉਣ ਵਾਲੇ ਵਰਕਫਲੋ ਨੂੰ ਵੀ ਸਟੈਂਡਰਡਾਈਜ਼ ਕਰਨਾ ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ। ਪŁੈਟਫ਼ਾਰਮਾਂ ਜਿਵੇਂ Koder.ai (ਇਕ ਚੈਟ-ਡ੍ਰਾਈਵਨ “vibe-coding” ਪŁੈਟਫ਼ਾਰਮ) ਡਿਲਿਵਰੀ ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦੇ ਹਨ ਤੇ ਏਂਟਰਪ੍ਰਾਈਜ਼ ਕੰਟਰੋਲ ਨੂੰ nazar ਵਿੱਚ ਰੱਖਦੇ ਹਨ—ਉਦਾਹਰਨ ਲਈ planning mode ਤੋਂ ਪਹਿਲਾਂ ਬਦਲਾਅ ਸੋਚੋ, ਅਤੇ ਜ਼ਾਂਚ/rollback ਲਈ snapshots 'ਤੇ ਨਿਰਭਰ ਰਹੋ। ਜੇ ਤੁਸੀਂ ਮੇਨੇਜਡ ਸਹਾਇਤਾ ਜਾਂ ਪŁੈਟਫ਼ਾਰਮ ਸਹਾਇਤਾ ਦਾ ਮੁਲਾਂਕਣ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ /pricing 'ਤੇ ਸੀਮਾਵਾਂ ਅਤੇ ਨਤੀਜਿਆਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ (ਕੋਈ ਵਚਨ ਨਹੀਂ—ਸਿਰਫ਼ ਵਿਕਲਪਾਂ ਨੂੰ ਫ੍ਰੇਮ ਕਰਨ ਦਾ ਤਰੀਕਾ)।
ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਹਿੱਸੇਦਾਰ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਮੁੱਖ ਮੁੱਲ ਵਜੋਂ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ: ਕਾਰੋਬਾਰੀ ਪ੍ਰਕ੍ਰਿਆਵਾਂ ਸਮੇਂ 'ਤੇ ਮੁਕੰਮਲ ਹੋਣ, ਇੰਟੀਗ੍ਰੇਸ਼ਨਾਂ ਦੀ ਸਿਹਤ ਠੀਕ ਰਹਿਣ, ਚੋਟੀ ਦੇ ਸਮੇਂ predictable ਪਰਫਾਰਮੈਂਸ ਅਤੇ ਕਿਸੇ ਬਿੱਲੀ ਘੜੀ ਵਿੱਚ ਤੇਜ਼ ਰਿਕਵਰੀ। ਉਦਯੋਗੀ ਇਕੋਸਿਸਟਮਾਂ ਵਿੱਚ ਛੋਟੀ ਡੀਗਰੇਡੇਸ਼ਨ ਵੀ ਬਿਲਿੰਗ, ਸ਼ਿਪਿੰਗ, ਪੇਰੋਲ ਜਾਂ ਕੰਪਲਾਇੰਸ ਰਿਪੋਰਟਿੰਗ ਰੋਕ ਸਕਦੀ ਹੈ—ਇਸ ਲਈ ਭਰੋਸੇਯੋਗਤਾ ਪਰਦੇ ਪਿੱਛੇ ਦੀ ਗੁਣਵੱਤਾ ਨਹੀਂ ਰਹਿੰਦੀ, ਬਲਕਿ ਮੁੱਖ ਡਿਲਿਵਰੇਬਲ ਬਣ ਜਾਂਦੀ ਹੈ।
ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਉਦਯੋਗੀ ਵਰਕਫਲੋਜ਼ ਆਮ ਤੌਰ 'ਤੇ ਸਾਂਝੇ ਪŁੈਟਫ਼ਾਰਮਾਂ (ਜਿਵੇਂ identity, ERP, ਡੇਟਾ ਪਾਈਪਲਾਈਨ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਮਿਡਲਵੇਅਰ) ਨਾਲ ਬੜੀ ਤਰ੍ਹਾਂ ਜੁੜੇ ਹੁੰਦੇ ਹਨ। ਇੱਕ ਛੋਟੀ ਖਰਾਬੀ ਵੀ ਬਲਾਕ ਹੋਏ ਆਰਡਰ, ਡੀਲੇ ਕੀਤੀ ਫਾਇਨੈਂਸ ਕਲੋਜ਼, ਟੁਟਿਆ ਹੋਇਆ ਭਾਗੀਦਾਰ ਆਨਬੋਰਡਿੰਗ ਜਾਂ ਸੰਵਿਧਾਨਕ ਜੁਰਮਾਨਿਆਂ ਤੱਕ ਲੈ ਜਾ ਸਕਦੀ ਹੈ।ਫੇਲ ਹੋਣ ਵਾਲੇ ਕੰਪੋਨੈਂਟ ਦੇ ਮੁਕਾਬਲੇ ‘ਬਲਾਸਟ ਰੇਡੀਅਸ’ ਜ਼ਿਆਦਾ ਵੱਡਾ ਹੁੰਦਾ ਹੈ।
ਜੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਘਟ ਜਾਂਦਾ ਹੈ ਤਾਂ ਕਈ ਡਾਊਨਸਟ੍ਰੀਮ ਐਪ ਇੱਕੋ ਸਮੇਂ "ਡਾਉਨ" ਲੱਗ ਸਕਦੇ ਹਨ, ਭਾਵੇਂ ਉਹ ਦਰਅਸਲ ਸਿਹਤਮੰਦ ਹੀ ਹੋਣ।
ਇੱਕ “ਪਰਿਯਾਪਤ” ਇਨਵੈਂਟਰੀ ਅਤੇ ਨਿਰਭਰਤਾਵਾਂ ਦਾ ਨਕਸ਼ਾ ਵਰਤੋ:
ਇਹ SLOs, ਅਲਰਟਿੰਗ ਅਤੇ ਚੇਂਜ ਕਨਟਰੋਲ ਲਈ ਪ੍ਰਾਇਰਟੀਜ਼ੇਸ਼ਨ ਦੀ ਆਧਾਰ ਰਚਨਾ ਬਣ ਜਾਂਦੀ ਹੈ।
ਉਦਾਹਰਣ ਲਈ ਕੁਝ ਸੰਕੇਤਕ SLOs ਜੋ ਕਾਰੋਬਾਰਕ ਪ੍ਰਭਾਵ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ:
ਸ਼ੁਰੂ ਵਿੱਚ 2–4 SLOs ਚੁਣੋ ਜੋ ਕਾਰੋਬਾਰ ਸਮਝ ਸਕੇ ਅਤੇ ਜਦੋਂ ਟੀਮਾਂ ਮਾਪਣ ਤੇ ਭਰੋਸਾ ਕਰਨ, ਫੈੱਲਾਓ।
ਇਹ SLO ਵੱਲੋਂ ਮਨਜ਼ੂਰ ਕੀਤਾ ਗਿਆ “ਮਾਨਯੋਗ ਖਰਾਬੀ” ਹੈ (ਫੇਲ ਹੋਏ ਰਿਕੁਏਸਟ, ਡਾਊਨਟਾਈਮ, ਦੇਰ ਵਾਲੇ ਪਾਈਪਲਾਈਨ)। ਨੀਤੀ ਵਜੋਂ ਇਸਦੀ ਵਰਤੋਂ:
ਇਸ ਨਾਲ ਭਰੋਸੇਯੋਗਤਾ ਸਮੇਤ ਫੈਸਲੇ ਨੂੰ ਇਕ ਸਪਸ਼ਟ ਨਿਯਮ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
ਸਧਾਰਨ ਪਰਤਵਾਰਤਨਾ ਇਹ ਹੈ:
ਇਸ ਤਰ੍ਹਾਂ ਐਨਟਰਪ੍ਰਾਈਜ਼-ਗਰੇਡ ਲੋੜਾਂ ਪŁੈਟਫ਼ਾਰਮ 'ਚ ਬਿਲਟ ਹੋਕੇ ਹਰ ਐਪ ਟੀਮ ਵੱਲੋਂ ਦੁਹਰਾਈ ਨਹੀਂ ਹੁੰਦੀਆਂ।
ਸੇਵਾ-ਮੈਪਾਂ ਵਿੱਚ ਭਾਗੀਦਾਰਾਂ/ਵੇਂਡਰਾਂ ਅਤੇ ਮੁੱਖ ਸਾਂਝੀਆਂ ਨਿਰਭਰਤਾਵਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਇੰਸੀਡੈਂਟ ਚੈਨਲਾਂ 'ਚ ਦਿਖਾਓ। ਭਲੇ ਭਾਗੀਦਾਰ ਟੈਲੀਮੇਟ੍ਰੀ ਸੀਮਿਤ ਹੋ, ਤੁਸੀਂ ਸਿਨਥੇਟਿਕ ਚੈਕ, ਐਜ ਮੈਟਰਿਕਸ ਅਤੇ ਸਾਂਝੇ ਰਿਕੁਏਸਟ ਆਈ.ਡੀ. ਦੇ ਨਾਲ ਨਿਰਭਰਤਾਵਾਂ ਦੀ ਮਾਡਲਿੰਗ ਕਰ ਸਕਦੇ ਹੋ।