ਇਸ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਤਿਆਰੀ ਚੈਕਲਿਸਟ ਨੂੰ ਵਰਤੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਆਪਣੇ ਉਤਪਾਦ ਨੂੰ ਵੱਡੇ ਗਾਹਕਾਂ ਲਈ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਸਕੇਲ ਕਰ ਸਕੋ—ਸਿੱਧੀਆਂ, ਕਾਰਜਕਾਰੀ ਸਿਖਲਾਈਆਂ Diane Greene ਅਤੇ VMware ਤੋਂ ਪ੍ਰੇਰਿਤ।
ਛੋਟੀ ਟੀਮਾਂ ਨੂੰ ਵੇਚਣਾ ਅਕਸਰ ਫੀਚਰਾਂ ਅਤੇ ਗਤੀ ਬਾਰੇ ਹੁੰਦਾ ਹੈ। ਐਂਟਰਪ੍ਰਾਈਜ਼ਾਂ ਨੂੰ ਵੇਚਣਾ “ਵਧੀਆ” ਦੀ ਪਰਿਭਾਸ਼ਾ ਬਦਲ ਦੇਂਦਾ ਹੈ। ਇੱਕ ਆਉਟੇਜ਼, ਇੱਕ ਭੁੱਲ-ਭਰਿਆ ਪਰਮਿਸ਼ਨ ਬੱਗ, ਜਾਂ ਇੱਕ ਗੁੰਮ ਸ਼ੁਦਾ ਆਡੀਟ ਟ੍ਰੇਲ ਮਹੀਨਿਆਂ ਦਾ ਭਰੋਸਾ ਉਲਟ ਸਕਦਾ ਹੈ।
ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਭਰੋਸੇਯੋਗਤਾ ਦਾ ਮਤਲਬ ਤਿੰਨ ਚੀਜ਼ਾਂ ਹਨ: ਐਪ ਚੱਲੀ ਰਹੇ, ਡੇਟਾ ਸੁਰੱਖਿਅਤ ਰਹੇ, ਅਤੇ ਵਿਹਾਰ ਪੇਸ਼ ਗੋਲੇ ਨਿਰਧਾਰਿਤ ਹੋਵੇ। ਆਖਰੀ ਹਿੱਸਾ ਜਿੰਨਾ ਲੱਗਦਾ ਹੈ ਉਸ ਤੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਕ ਹੈ। ਐਂਟਰਪ੍ਰਾਈਜ਼ ਯੂਜ਼ਰ ਤੁਹਾਡੇ ਸਿਸਟਮ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਕੰਮ ਯੋਜਨਾ ਬਣਾਉਂਦੇ ਹਨ। ਉਹ ਉਮੀਦ ਕਰਦੇ ਹਨ ਕਿ ਅੱਜ, ਅਗਲੇ ਹਫ਼ਤੇ ਅਤੇ ਅਗਲੇ ਅਪਡੇਟ ਦੇ ਬਾਅਦ ਵੀ ਨਤੀਜਾ ਇਕੋ ਜਿਹਾ ਹੋਵੇ।
ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲਾਂ ਟੁੱਟਦਾ ਹੈ, ਉਹ ਇੱਕ ਇਕੱਲਾ ਸਰਵਰ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਓਹ ਖਾਈ ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਕੁਝ ਯੂਜ਼ਰਾਂ ਲਈ ਬਣਾਇਆ ਸੀ ਅਤੇ ਜੋ ਵੱਡੇ ਗਾਹਕ ਮੰਨਦੇ ਹਨ ਕਿ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੈ, ਉਸ ਵਿਚਕਾਰ ਹੈ। ਉਹ ਹੋਰ ਟ੍ਰੈਫਿਕ, ਹੋਰ ਰੋਲ, ਹੋਰ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਅਤੇ ਸੁਰੱਖਿਆ ਅਤੇ ਅਨੁਕੂਲਤਾ ਵੱਲੋਂ ਵਧੀਕ ਜਾਂਚ ਲਿਆਉਂਦੇ ਹਨ।
ਸ਼ੁਰੂਆਤੀ ਤਣਾਅ ਦੇ ਨੁਕਤੇ ਅਨੁਮਾਨਯੋਗ ਹਨ। ਉਪਲਬਧਤਾ ਦੀਆਂ ਉਮੀਦਾਂ “ਅਕਸਰ ਠੀਕ” ਤੋਂ “ਨਿਰਾਸਤਕ ਰੂਪ ਵਿੱਚ ਸਥਿਰ ਹੋਣੀ ਚਾਹੀਦੀ” ਤੱਕ ਛਾਲ ਮਾਰਦੀਆਂ ਹਨ, ਸਾਫ਼ ਇੰਸੀਡੈਂਟ ਹੈਂਡਲਿੰਗ ਨਾਲ। ਡੇਟਾ ਸੁਰੱਖਿਆ ਬੋਰਡ-ਸਤਰ ਦੀ ਚਿੰਤਾ ਬਣ ਜਾਂਦੀ ਹੈ: ਬੈਕਅੱਪਸ, ਰਿਕਵਰੀ, ਐਕਸਸ ਲੌਗ ਅਤੇ ਮਲਕੀਅਤ। ਪਰਮਿਸ਼ਨ ਤੇਜ਼ੀ ਨਾਲ ਜਟਿਲ ਹੋ ਜਾਂਦੀਆਂ ਹਨ: ਵਿਭਾਗ, ਠੇਕੇਦਾਰ ਅਤੇ ਘੱਟ-ਹੱਕ ਪ੍ਰਵੇਸ਼। ਬਦਲਾਅ ਖਤਰਨਾਕ ਬਣ ਜਾਂਦਾ ਹੈ: ਰਿਲੀਜ਼ ਨੂੰ ਰੋਲਬੈਕ ਲੋੜੀਂਦਾ ਹੈ ਅਤੇ ਅਚਾਨਕ ਵਿਹਾਰ ਨੂੰ ਰੋਕਣ ਦਾ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ। ਸਪੋਰਟ “ਮਦਦਗਾਰ” ਬਣ ਕੇ ਪ੍ਰੋਡਕਟ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦੀ ਹੈ, ਜਿੰਨ੍ਹਾਂ ਵਿੱਚ ਜਵਾਬ ਦੇਣ ਦਾ ਸਮਾਂ ਅਤੇ ਐਸਕਲੈਸ਼ਨ ਪੱਥ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ।
ਇੱਕ ਸਟਾਰਟਅਪ ਗਾਹਕ ਦੋ ਘੰਟੇ ਦਾ ਆਉਟੇਜ਼ ਅਤੇ ਇੱਕ ਤੇਜ਼ ਮਾਫੀ ਖਰਚ ਸਕਦਾ ਹੈ। ਇੱਕ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਗਾਹਕ ਨੂੰ ਰੂਟ ਕਾਰਨ ਸਾਰ, ਦਿਖਾਵਾ ਕਿ ਇਹ ਮੁੜ ਨਹੀਂ ਹੋਵੇਗਾ, ਅਤੇ ਇੱਕ ਯੋਜਨਾ ਲੋੜੀਂਦੀ ਹੋ ਸਕਦੀ ਹੈ।
ਐਂਟਰਪ੍ਰਾਈਜ਼ ਤਿਆਰੀ ਚੈਕਲਿਸਟ “ਪਰਫੈਕਟ ਸਾਫਟਵੇਅਰ” ਬਾਰੇ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਭਰੋਸਾ ਟੁੱਟੇ ਬਿਨਾਂ ਸਕੇਲ ਕਰਨ ਬਾਰੇ ਹੈ—ਉਤਪਾਦ ਡਿਜ਼ਾਈਨ, ਟੀਮ ਦੀਆਂ ਆਦਤਾਂ ਅਤੇ ਰੋਜ਼ਮਰਾ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਇਕੱਠੇ ਅੱਪਗ੍ਰੇਡ ਕਰਕੇ।
Diane Greene ਨੇ VMware ਦੀ ਸਥਾਪਨਾ ਉਸ ਸਮੇਂ ਕੀਤੀ ਜਦੋਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ IT ਨੂੰ ਇੱਕ ਦਰਦਨਾਕ ਟਰੇਡ-ਆਫ਼ ਦਾ ਸਾਹਮਣਾ ਸੀ: ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧੋ ਤੇ ਆਉਟੇਜ ਦਾ ਜੋਖਮ ਲਓ, ਜਾਂ ਠਹਿਰੋ ਅਤੇ ਧੀਮੀ ਤਬਦੀਲੀ ਸਵੀਕਾਰ ਕਰੋ। VMware ਦੀ ਮਹੱਤਤਾ ਇਸ ਲਈ ਸੀ ਕਿ ਇਸ ਨੇ ਸਰਵਰਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਨਿਰਮਾਣ ਇਕਾਈਆਂ ਵਾਂਗ ਵਰਤਣਯੋਗ ਬਣਾਇਆ। ਇਸ ਨਾਲ ਕਨਸੋਲੀਡੇਸ਼ਨ, ਸੇਫ਼ਰ ਅਪਗ੍ਰੇਡ ਅਤੇ ਤੇਜ਼ ਰਿਕਵਰੀ ਮੁਮਕਿਨ ਹੋਈ, ਬਿਨਾਂ ਹਰ ਐਪ ਟੀਮ ਨੂੰ ਸਭ ਕੁਝ ਦੁਬਾਰਾ ਲਿਖਣ ਨੂੰ ਕਹਿਣ ਦੇ।
ਐਂਟਰਪ੍ਰਾਈਜ਼ ਦਾ ਮੂਲ ਵਾਅਦਾ ਸਾਦਾ ਹੈ: ਪਹਿਲਾਂ ਸਥਿਰਤਾ, ਫੀਚਰ ਬਾਅਦ ਵਿੱਚ। ਐਂਟਰਪ੍ਰਾਈਜ਼ ਨਵੀਆਂ ਖੂਬੀਆਂ ਚਾਹੁੰਦੇ ਹਨ, ਪਰ ਉਹ ਚਾਹੁੰਦੇ ਹਨ ਕਿ ਉਹਨਾਂ ਨੂੰ ਐਸੇ ਸਿਸਟਮ ਉੱਤੇ ਮਿਲੇ ਜੋ ਪੈਚਿੰਗ, ਸਕੇਲਿੰਗ ਅਤੇ ਰੋਜ਼ਾਨਾ ਦੀਆਂ ਗਲਤੀਆਂ ਦੌਰਾਨ ਵੀ ਚਲਦਾ ਰਹੇ। ਜਦੋਂ ਇਕ ਉਤਪਾਦ ਬਿਜ਼ਨਸ-ਕ੍ਰਿਟੀਕਲ ਬਣਦਾ ਹੈ, "ਅਸੀਂ ਅਗਲੇ ਹਫ਼ਤੇ ਠੀਕ ਕਰਾਂਗੇ" ਲਾਭ ਘਟਾਂ, ਮਿਆਦਾਂ ਦੇ ਚੂਕਣ ਅਤੇ ਅਨੁਕੂਲਤਾ ਸਮੱਸਿਆਵਾਂ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ।
ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਇੱਕ ਵਰਤੋ-ਯੋਗ ਭਰੋਸੇਯੋਗਤਾ ਸੰਦ ਸੀ, ਸਿਰਫ਼ ਲਾਗਤ ਬਚਾਉਣ ਵਾਲਾ ਨਹੀਂ। ਇਸ ਨੇ ਅਲੱਗ-ਅਲੱਗ ਇਲਾਕੇ ਬਣਾਏ। ਇਕ ਵਰਕਲੋਡ ਡਿੱਗ ਸਕਦਾ ਸੀ ਬਿਨਾਂ ਪੂਰੇ ਮਸ਼ੀਨ ਨੂੰ ਲਿਆਉਣ ਦੇ। ਇਹ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਵੀ ਵੱਧ ਦੁਹਰਾਉਣਯੋਗ ਬਣਾਇਆ: ਜੇ ਤੁਸੀਂ ਵਰਕਲੋਡ ਨੂੰ ਸਨੇਪਸ਼ਾਟ, ਕਲੋਨ ਅਤੇ ਮੂਵ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਤਬਦੀਲੀਆਂ ਦੀ ਜਾਂਚ ਅਤੇ ਗਲਤੀ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਤੇਜ਼ ਰਿਕਵਰੀ ਕਰ ਸਕਦੇ ਹੋ।
ਇਹ ਸੋਚ ਅਜੇ ਵੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ: ਬਿਨਾਂ ਡਾਊਨਟਾਈਮ ਦੇ ਬਦਲਾਅ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ। ਮੰਨੋ ਕਿ ਕੰਪੋਨੈਂਟ ਅਮਰ ਨਹੀਂ ਹਨ, ਲੋੜਾਂ ਬਦਲਣਗੀਆਂ, ਅਤੇ ਅਪਗ੍ਰੇਡ ਰੀਅਲ ਲੋਡ ਹੇਠਾਂ ਹੋਣਗੇ। ਫਿਰ ਉਹ ਆਦਤਾਂ ਬਣਾਓ ਜੋ ਬਦਲਾਅ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੀਆਂ ਹਨ।
VMware ਦੀ ਸੋਚ ਨੂੰ ਇੱਕ ਛੋਟੀ ਪਰਿਭਾਸ਼ਾ ਨਾਲ ਵਰਣਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ: ਫੇਲਿਯਰ ਨੂੰ ਅਲੱਗ ਰੱਖੋ ਤਾਂ ਕਿ ਇੱਕ ਸਮੱਸਿਆ ਫੈਲੇ ਨਾ, ਅਪਗ੍ਰੇਡ ਨੂੰ ਰੋਜ਼ਮਰਾ ਬਣਾਉ, ਰੋਲਬੈਕ ਤੇਜ਼ ਬਣਾਓ, ਅਤੇ ਚਤੁਰ ਹਰਕਤਾਂ ਤੋਂ ਬਹੁਤ ਪਿਛਾੜਿਆ ਹੋਇਆ ਪੇਸ਼ਬੀਨੀਯੋਗ ਵਿਹਾਰ ਪਸੰਦ ਕਰੋ। ਭਰੋਸਾ ਰੋਜ਼ਾਨਾ ਬੋਰਿੰਗ ਭਰੋਸੇਯੋਗਤਾ ਰਾਹੀਂ ਬਣਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਆਧੁਨਿਕ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ (ਜਾਂ Koder.ai ਵਰਗੇ ਟੂਲ ਨਾਲ ਐਪ ਜਨਰੇਟ ਕਰਦੇ ਹੋ), ਇਹ ਸਬਕ ਠੀਕ ਬੈਠਦਾ ਹੈ: ਫੀਚਰਾਂ ਤਦ ਹੀ ਸ਼ਿਪ ਕਰੋ ਜਦ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਐਸੇ ਤਰੀਕੇ ਨਾਲ ਤੈਨਾਤ, ਮਾਨੀਟਰ ਅਤੇ ਵਾਪਸ ਲੈ ਸਕੋ ਬਿਨਾਂ ਗਾਹਕ ਦੀਆਂ ਕਾਰਜਵਾਹੀਆਂ ਨੂੰ ਤੋੜੇ।
VMware ਇੱਕ ਪੈਕਡ ਸਾਫਟਵੇਅਰ ਦੁਨੀਆਂ ਵਿੱਚ ਵਧਿਆ ਜਿੱਥੇ "ਇੱਕ ਰਿਲੀਜ਼" ਵੱਡਾ ਇਵੈਂਟ ਹੁੰਦਾ ਸੀ। ਕਲਾਉਡ ਪਲੇਟਫਾਰਮਾਂ ਨੇ ਰਿਥਮ ਨੂੰ पलਟ ਦਿੱਤਾ: ਛੋਟੇ ਬਦਲਾਅ ਅਕਸਰ ਛਪਦੇ ਹਨ। ਇਹ ਸੁਰੱਖਿਅਤ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਸਿਰਫ਼ ਜਦ ਤੁਸੀਂ ਬਦਲਾਅ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹੋ।
ਚਾਹੇ ਤੁਸੀਂ ਬਾਕਸਡ ਇੰਸਟਾਲਰ ਸ਼ਿਪ ਕਰੋ ਜਾਂ ਕਲਾਉਡ ਡਿਪਲੋਯ, ਬਹੁਤ ਸਾਰੇ ਆਉਟੇਜ ਇਕੋ ਢੰਗ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ: ਇੱਕ ਤਬਦੀਲੀ ਆਉਂਦੀ ਹੈ, ਇੱਕ ਛੁਪੀ ਹੋਈ ਧਾਰਨਾ ਟੁੱਟਦੀ ਹੈ, ਅਤੇ ਬਲਾਸਟ ਰੇਡਿਅਸ ਉਮੀਦ ਤੋਂ ਵੱਡਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਤੇਜ਼ ਰਿਲੀਜ਼ ਜੋਖਮ ਹਟਾਉਂਦੇ ਨਹੀਂ; ਜਦੋਂ ਤੁਸੀਂ ਗਾਰਡਰੇਲਸ ਨਹੀਂ ਰੱਖਦੇ ਤਾਂ ਉਹ ਇਹ ਜੋਖਮ ਵਧਾਉਂਦੇ ਹਨ।
ਜੋ ਟੀਮਾਂ ਭਰੋਸੇਯੋਗੀ ਤਰੀਕੇ ਨਾਲ ਸਕੇਲ ਕਰਦੀਆਂ ਹਨ ਉਹ ਮੰਨਦੀਆਂ ਹਨ ਕਿ ਹਰ ਰਿਲੀਜ਼ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ ਉਹ ਸਿਸਟਮ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਕਰਨ ਯੋਗ ਬਣਾਦੇ ਹਨ।
ਇਕ ਸਧਾਰਨ ਉਦਾਹਰਣ: ਇੱਕ "ਨਿਰਦੋਸ਼" ਡੇਟਾਬੇਸ ਇੰਡੈਕਸ ਬਦਲਾਅ ਸਟੇਜਿੰਗ ਵਿੱਚ ਠੀਕ ਲੱਗਦਾ ਹੈ, ਪਰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਇਸ ਨਾਲ ਲਿਖਣ ਦੀ ਲੇਟੈਂਸੀ ਵਧ ਜਾਂਦੀ ਹੈ, ਰੀਕਵੇਸ੍ਟ ਕਤਾਰ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਟਾਈਮਆਉਟ ਨੈੱਟਵਰਕ ਦੀਆਂ ਬੇਕਾਰੀਆਂ ਵਾਂਗ ਦਿੱਖਦੇ ਹਨ। ਬਾਰੰਬਾਰ ਰਿਲੀਜ਼ ਤੁਹਾਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਅਚਾਨਕ ਫਰਕ ਲਿਆਉਣ ਦੇ ਹੋਰ ਮੌਕੇ ਦਿੰਦੇ ਹਨ।
ਕਲਾਉਡ ਯੁੱਗ ਦੀਆਂ ਐਪਸ ਅਕਸਰ ਕਈ ਗਾਹਕਾਂ ਨੂੰ ਸਾਂਝੇ ਸਿਸਟਮ 'ਤੇ ਸਰਵ ਕਰਦੀਆਂ ਹਨ। ਮਲਟੀ-ਟੇਨੈਂਸੀ ਨਵੇਂ ਸਮੱਸਿਆਵਾਂ ਲਿਆਉਂਦੀ ਹੈ ਜੋ ਹਾਲੇ ਵੀ ਉਸੇ ਸਿਧਾਂਤ 'ਤੇ ਮਾਪਦੇ ਹਨ: ਫੇਲਟਾਂ ਨੂੰ ਅਲੱਗ ਕਰੋ।
Noisy neighbor ਸਮੱਸਿਆਵਾਂ (ਇੱਕ ਗਾਹਕ ਦਾ spike ਹੋਰਾਂ ਨੂੰ ਧੀਮਾ ਕਰ ਦੇਂਦਾ) ਅਤੇ ਸਾਂਝੀ ਫੇਲਿਯਰ (ਕੁਝ ਖਰਾਬ ਡਿਪਲੋy ਸਾਰਿਆਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ) ਆਧੁਨਿਕ ਵਰਜ਼ਨ ਹਨ "ਇੱਕ ਬੱਗ ਕਲੱਸਟਰ ਡਾਊਨ ਕਰ ਦਿੰਦੀ" ਦਾ। ਕੰਟਰੋਲ ਪਰਚੀਤ ਹਨ, ਸਿਰਫ਼ ਨਿਰਤੰਤ ਤਰ੍ਹਾਂ ਲਾਗੂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ: ਦਰੜੀ ਰੋਲਆਉਟ, ਪ੍ਰਤੀ-ਟੇਨੈਂਟ ਨਿਯੰਤਰਣ, ਸਰੋਤ ਸੀਮਾਵਾਂ (ਕੋਟਾ, ਰੇਟ ਲਿਮਿਟ, ਟਾਈਮਆਉਟ), ਅਤੇ ਅਜਿਹੇ ਡਿਜ਼ਾਈਨ ਜੋ ਅੰਸ਼ਕ ਫੇਲਿਯਰ ਨੂੰ ਸਹੰਨ ਕਰਦੇ ਹਨ।
Observability ਵੀ ਇੱਕ ਹੋਰ ਸਥਿਰ ਚੀਜ਼ ਹੈ। ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਦੇਖ ਸਕਦੇ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ ਤਾਂ ਤੁਸੀਂ ਭਰੋਸੇਯੋਗਤਾ ਦੀ ਰੱਖਿਆ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਚੰਗੇ ਲੌਗ, ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਟਰੇਸ ਤੁਹਾਨੂੰ ਰੋਲਆਉਟ ਦੌਰਾਨ ਰੈਗ੍ਰੈਸ਼ਨ ਤੇਜ਼ੀ ਨਾਲ ਪਛਾਣਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।
ਰੋਲਬੈਕ ਹੁਣ ਇੱਕ ਅਪਵਾਦੀ ਐਮਰਜੈਂਸੀ ਚਾਲ ਨਹੀਂ ਰਹਿ ਗਿਆ। ਇਹ ਇੱਕ ਨਾਰਮਲ ਸੰਦ ਹੈ। ਕਈ ਟੀਮਾਂ ਰੋਲਬੈਕ ਨੂੰ ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਡਿਪਲੋਯ ਕਦਮਾਂ ਨਾਲ ਜੋੜਦੀਆਂ ਹਨ। ਪਲੇਟਫਾਰਮਾਂ ਜਿਵੇਂ Koder.ai ਵਿੱਚ ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਸ਼ਾਮਲ ਹਨ, ਜੋ ਟੀਮਾਂ ਨੂੰ risky ਬਦਲਾਅ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਵਾਪਸ ਲੈਣ 'ਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਵੱਡੀ ਗੱਲ ਸੱਭਿਆਚਾਰਕ ਹੈ: ਰੋਲਬੈਕ ਅਭਿਆਸ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਉਦਯੋਗਕ ਨਹੀਂ।
ਜੇ ਤੁਸੀਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਦੀ ਸੌਦਾ-ਪੇਸ਼ਕਸ਼ ਹੋਣ ਤੱਕ ਭਰੋਸੇਯੋਗਤਾ ਦੇ ਟਾਰਗੇਟ ਨਹੀਂ ਨਿਰਧਾਰਤ ਕਰਦੇ, ਤਾਂ ਤੁਹਾਡੀ بحث ਭਾਵਨਾਵਾਂ 'ਤੇ ਆਧਾਰਿਤ ਹੋਵੇਗੀ: "ਲੱਗਦਾ ਹੈ ਠੀਕ ਹੈ"। ਵੱਡੇ ਗਾਹਕ ਸਾਫ਼ ਵਾਅਦੇ ਚਾਹੁੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਉਹ ਆਪਣੇ ਅੰਦਰ ਦੁਹਰਾ ਸਕਦੇ ਹਨ, ਜਿਵੇਂ "ਐਪ ਚੱਲਦਾ ਰਹਿੰਦਾ ਹੈ" ਅਤੇ "ਪੇਕ ਦੇ ਸਮੇਂ ਪੇਜ ਤੇਜ਼ ਲੋਡ ਹੁੰਦੇ ਹਨ"।
ਛੋਟੀ-ਸੀ ਲਿਸਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੀ ਹੋਵੇ। ਦੋ ਜੋ ਜ਼ਿਆਦਾ ਟੀਮ ਤੇਜ਼ੀ ਨਾਲ ਸਹਿਮਤ ਹੋ ਸਕਦੇ ਹਨ, ਉਹ ਹਨ ਉਪਲਬਧਤਾ (ਕਿੰਨੀ ਵਾਰੀ ਸਰਵਿਸ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ) ਅਤੇ ਜਵਾਬੀ ਸਮਾਂ (ਮੁੱਖ ਕਾਰਵਾਈਆਂ ਕਿੰਨੀ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ)। ਟਾਰਗੇਟ ਨੂੰ ਉਪਭੋਗਤਾਕਾਰ ਪ੍ਰਭਾਵ ਨਾਲ ਜੋੜੋ, ਇਕ ਇਕੱਲੇ ਸਰਵਰ ਮੈਟਰਿਕ ਨਾਲ ਨਹੀਂ।
ਇੱਕ ਐਰਰ ਬਜਟ ਇਹ ਟਾਰਗੇਟ ਦਿਨ-ਪ੍ਰਤੀਦਿਨ ਵਰਤੋਂਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਉਸ ਸਮੇਂ ਦੀ ਮਾਤਰਾ ਹੈ ਜੋ ਤੁਸੀਂ ਕਿਸੇ ਸਮੇਂ-ਜਾਲ ਵਿੱਚ "ਖਰਚ" ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਫਿਰ ਵੀ اپنا ਵਾਅਦਾ ਪੂਰਾ ਕਰ ਸਕਦੇ ਹੋ। ਜਦ ਤੁਸੀਂ ਬਜਟ ਅੰਦਰ ਹੋ, ਤੁਸੀਂ ਹੋਰ ਡਿਲਿਵਰੀ ਜੋਖਮ ਲੈ ਸਕਦੇ ਹੋ। ਜਦ ਤੁਸੀਂ ਇਸ ਨੂੰ ਖਤਮ ਕਰ ਲੈਂਦੇ ਹੋ, ਭਰੋਸੇਯੋਗਤਾ ਦਾ ਕੰਮ ਨਵੀਆਂ ਫੀਚਰਾਂ ਉੱਤੇ ਪ੍ਰਾਥਮਿਕਤਾ ਲੈ ਲੈਂਦਾ ਹੈ।
ਟਾਰਗੇਟ ਨੂੰ ਇਮਾਨਦਾਰ ਰੱਖਣ ਲਈ, ਕੁਝ ਸੰਕੇਤ ਟਰੈਕ ਕਰੋ ਜੋ ਅਸਲ ਪ੍ਰਭਾਵ ਨਾਲ ਜੁੜਦੇ ਹੋਣ: ਮੁੱਖ ਕਾਰਵਾਈਆਂ 'ਤੇ ਲੈਟੈਂਸੀ, ਐਰਰ (ਫੇਲਡ ਰਿਕਵੇਸਟ, ਕਰੈਸ਼, ਟੁੱਟੇ ਫਲੋ), ਸੰਤ੍ਰਿਪਤੀ (CPU, ਮੈਮੋਰੀ, ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨਾਂ, ਕਿਊਜ਼) ਅਤੇ ਐੰਡ-ਟੂ-ਐੰਡ-critial-path ਉਪਲਬਧਤਾ।
ਟਾਰਗੇਟ ਸੈੱਟ ਹੋਣ ਤੋਂ ਬਾਅਦ ਉਹ ਫੈਸਲਿਆਂ ਨੂੰ ਬਦਲਦੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਜੇ ਇੱਕ ਰਿਲੀਜ਼ ਨੇ ਐਰਰ ਵਧਾ ਦਿੱਤੇ, ਤਾਂ ਵਾਦ-ਵਿਚਾਰ ਨਾ ਕਰੋ। ਰੋਕੋ, ਠੀਕ ਕਰੋ, ਜਾਂ ਰੋਲਬੈਕ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਲਈ Koder.ai ਵਰਗਾ vibe-coding ਪਲੇਟਫਾਰਮ ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਟਾਰਗੇਟਾਂ ਹੋਰ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਗਤੀ ਸਿਰਫ਼ ਤਾਂ ਫਾਇਦਾ مند ਹੈ ਜਦ ਇਹ ਭਰੋਸੇਯੋਗਤਾ ਵਾਲੇ ਵਾਅਦਾਂ ਨਾਲ ਬੰਧੀ ਹੋਵੇ ਜਿਸਨੂੰ ਤੁਸੀਂ ਰੱਖ ਸਕੋ।
"ਸਾਡੀ ਟੀਮ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ" ਤੋਂ "Fortune 500 ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ" ਤਕ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਦੀ ਛਾਲ ਅਕਸਰ ਆਰਕੀਟੈਕਚਰ ਦੀ ਹੈ। ਮੁੱਖ ਸੋਚ ਸਧਾਰਨ ਹੈ: ਦਿਨ-ਦੌਰਾਨ ਹਿੱਸੇ ਫੇਲ ਹੋਣਗੇ, ਨਾ ਕੇਵਲ ਵੱਡੇ ਆਉਟੇਜ ਦੇ ਦੌਰਾਨ।
ਅਨੁਭਵ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ ਕਿ ਨਿਰਭਰਤਾਵਾਂ ਜਿੱਥੇ ਸੰਭਵ ਹੋ ਨਿਰੋਧਕ ਹੋਣ। ਜੇ ਤੁਹਾਡਾ ਬਿਲਿੰਗ ਪ੍ਰਦਾਤਾ, ਈਮੇਲ ਸੇਵਾ ਜਾਂ ਐਨਾਲਿਟਿਕਸ ਪਾਈਪਲਾਈਨ ধੀਮਾ ਹੋ ਜਾਏ, ਤਾਂ ਤੁਹਾਡੀ ਕੋਰ ਐਪ ਫਿਰ ਵੀ ਲੋਡ ਹੋਵੇ, ਲੌਗਇਨ ਹੋਵੇ, ਅਤੇ ਲੋਕਾਂ ਨੂੰ ਮੁੱਖ ਕੰਮ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇਸੋਲੇਸ਼ਨ ਬਾਊਂਡਰੀਜ਼ ਤੁਹਾਡੇ ਸਭ ਤੋਂ ਵਧੀਆ ਦੋਸਤ ਹਨ। ਕੋਰਿਕਲ ਪਾਥ (ਲੌਗਿਨ, ਕੋਰ ਵਰਕਫਲੋ, ਮੁੱਖ ਡੇਟਾਬੇਸ ਨੂੰ ਲਿਖਣਾ) ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰੋ ਅਤੇ ਨਿਸ਼ਾਕੀ-ਫੀਚਰਾਂ (ਸਿਫਾਰਸ਼ਾਂ, ਐਕਟਿਵਿਟੀ ਫੀਡ, ਐਕਸਪੋਰਟ) ਤੋਂ ਵੱਖਰੋ। ਜਦ ਵਿਕਲਪਿਕ ਹਿੱਸੇ ਟੁੱਟਣ, ਉਹ ਬੰਦ ਹੋ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ ਬਿਨਾਂ ਕੋਰ ਨੂੰ ਖਿੱਚਣ ਦੇ।
ਕੁਝ ਆਦਤਾਂ ਜੋ ਅਮਲ ਵਿੱਚ cascading ਫੇਲਿਯਰ ਰੋਕਦੀਆਂ ਹਨ:
ਡੇਟਾ ਸੁਰੱਖਿਆ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ "ਅਸੀਂ ਬਾਅਦ ਵਿੱਚ ਠੀਕ ਕਰ ਲਵਾਂਗੇ" ਡਾਊਨਟਾਈਮ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ। ਬੈਕਅੱਪਸ, ਸਕੀਮਾ ਬਦਲਾਅ ਅਤੇ ਰਿਕਵਰੀ ਦੀ ਯੋਜਨਾ ਸਾਡੇ ਤਰੀਕੇ ਨਾਲ ਬਣਾਓ, ਕਿਉਂਕਿ ਤੁਹਾਨੂੰ ਇਸ ਦੀ ਲੋੜ ਪਏਗੀ। ਰਿਕਵਰੀ ਡ੍ਰਿਲਜ਼ ਚਲਾਉ ਜਿਵੇਂ ਤੁਸੀਂ ਅੱਗ-ਡ੍ਰਿਲ ਚਲਾਉਂਦੇ ਹੋ।
ਉਦਾਹਰਣ: ਇੱਕ ਟੀਮ ਇੱਕ React ਐਪ, ਇੱਕ Go API ਅਤੇ PostgreSQL ਦੇ ਨਾਲ ਸ਼ਿਪ ਕਰਦੀ ਹੈ। ਇੱਕ ਨਵਾਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਗਾਹਕ 5 ਮਿਲੀਅਨ ਰਿਕਾਰਡ ਇੰਪੋਰਟ ਕਰਦਾ ਹੈ। ਬਾਊਂਡਰੀਜ਼ ਨਾ ਹੋਣ 'ਤੇ, ਇੰਪੋਰਟ ਸਧਾਰਨ ਟ੍ਰੈਫਿਕ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦਾ ਹੈ ਅਤੇ ਹਰ ਚੀਜ਼ ਧੀਮੀ ਹੋ ਜਾਂਦੀ ਹੈ। ਸਹੀ ਗਾਰਡਰੇਲਸ ਨਾਲ, ਇੰਪੋਰਟ ਇੱਕ ਕਿਊ ਰਾਹੀਂ ਦੌੜਦਾ, ਬੈਚਿਸ ਵਿੱਚ ਲਿਖਦਾ, ਟਾਈਮਆਉਟ ਅਤੇ ਸੇਫ਼ ਰੀਟ੍ਰਾਈ ਵਰਤਦਾ, ਅਤੇ ਦਿਨ-ਪਰ ਦਿਨ ਯੂਜ਼ਰਾਂ 'ਤੇ ਪ੍ਰਭਾਵ ਬਿਨਾਂ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਬਣਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਜਨਰੇਟ ਕੀਤੇ ਕੋਡ ਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਚਿਕਤੀ ਦਿਓ: ਅਸਲ ਗਾਹਕਾਂ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਤੇ ਨਿਰਭਰ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਇਨ੍ਹਾਂ ਗਾਰਡਰੇਲਸ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ।
ਇੰਸੀਡੈਂਟ ਤਿਆਗ ਤੁਹਾਡੇ ਫੇਲ ਹੋਣ ਦਾ ਪ੍ਰਮਾਣ ਨਹੀਂ। ਇਹ ਅਸਲ ਗਾਹਕਾਂ ਲਈ ਰੀਅਲ ਸਾਫਟਵੇਅਰ ਚਲਾਉਣ ਦੀ ਇੱਕ ਆਮ ਲਾਗਤ ਹਨ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਵਰਤੋਂ ਵੱਧਦੀ ਹੈ ਅਤੇ ਡਿਪਲੋਇਆਂ ਵਧਦੇ ਹਨ। ਫਰਕ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੀ ਟੀਮ ਠੰਢੀ ਰਫਤਾਰ ਨਾਲ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਦੀ ਹੈ ਅਤੇ ਕਾਰਨ ਨੂੰ ਠੀਕ ਕਰਦੀ ਹੈ, ਜਾਂ ਭੱਜਦੀ ਹੈ ਅਤੇ ਅਗਲੇ ਮਹੀਨੇ ਉਹੀ ਆਉਟੇਜ ਦੋਰ੍ਹਾਉਂਦੀ ਹੈ।
ਸ਼ੁਰੂ ਵਿੱਚ, ਕਈ ਉਤਪਾਦ ਕੁਝ ਲੋਕਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਜੋ "ਸਿਰਫ਼ ਜਾਣਦੇ" ਹਨ ਕਿ ਕੀ ਕਰਨਾ ਹੈ। ਐਂਟਰਪ੍ਰਾਈਜ਼ ਉਹ ਜਿਸਨੂੰ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰਨਗੇ। ਉਹ ਨਿਰਧਾਰਿਤ ਜਵਾਬ, ਸਾਫ਼ ਸੰਚਾਰ, ਅਤੇ ਗਵਾਹੀ ਚਾਹੁੰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਫੇਲਿਯਰ ਤੋਂ ਸਿੱਖਦੇ ਹੋ।
ਆਨ-ਕਾਲ ਹੀਰੋਵਿਕਤਾ ਬਾਰੇ ਨਹੀਂ, ਬਲਕਿ ਰਾਤ 2 ਵਜੇ ਨਿਰਦਿਸ਼ਟਤਾ ਹਟਾਉਣ ਬਾਰੇ ਹੈ। ਇੱਕ ਸਧਾਰਨ ਸੈਟਅਪ ਜ਼ਿਆਦਾਤਰ ਚੀਜ਼ਾਂ ਕਵਰ ਕਰਦਾ ਹੈ ਜੋ ਵੱਡੇ ਗਾਹਕ ਚਾਹੁੰਦੇ ਹਨ:
ਜੇ ਸਾਰੇ ਦਿਨ ਅਲਾਰਟ ਬਜਦੇ ਰਹਿਣ ਤਾਂ ਲੋਕ ਉਹਨਾਂ ਨੂੰ ਮਿਊਟ ਕਰਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਅਸਲੀ ਘਟਨਾ ਖੋਹੀ ਜਾ ਜਾਂਦੀ ਹੈ। ਅਲਾਰਟ ਨੂੰ ਉਪਭੋਗਤਾ ਪ੍ਰਭਾਵ ਨਾਲ ਜੋੜੋ: ਸਾਈਨ-ਇਨ ਫੇਲ, ਐਰਰ ਦਰ ਵਧਣਾ, ਲੈਟੈਂਸੀ ਇੱਕ ਸਪੱਸ਼ਟ ਸੀਮਾ ਪਾਰ ਕਰ ਲੈਣਾ, ਜਾਂ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬਾਂ ਦਾ ਬੈਕਲੌਗ ਹੋਣਾ।
ਇੱਕ ਘਟਨਾ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਸਮੀਖਿਆ ਕਰੋ ਜੋ ਦੋਸ਼-ਖੋਜ ਤੇ ਨਹੀਂ, ਸਧਾਰਨਾਂ ਤੇ ਧਿਆਨ ਦਿੰਦੀ ਹੋਵੇ। ਕੀ ਹੋਇਆ, ਕਿਹੜੇ ਸੰਕੇਤ ਗੁੰਮ ਸਨ, ਅਤੇ ਕਿਹੜੇ ਗਾਰਡਰੇਲਸ ਬਲਾਸਟ ਰੇਡਿਅਸ ਘਟਾ ਸਕਦੇ ਸਨ। ਉਸ ਨੂੰ ਇੱਕ ਜਾਂ ਦੋ ਵਿਹਾਰਕ ਤਬਦੀਲੀਆਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰੋ, ਮਾਲਕ ਨਿਰਧਾਰਤ ਕਰੋ, ਅਤੇ ਮਿਆਦ ਦਿਓ।
ਇਹ ਆਪਰੇਸ਼ਨਲ ਬੁਨਿਆਦੀਆਂ ਹੀ ਅੰਤਰ ਪੈਂਦੇ ਹਨ "ਕੰਮ ਕਰ ਰਹੀ ਐਪ" ਅਤੇ ਇਕ ਸੇਵਾ ਜੋ ਗਾਹਕਾਂ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹਨ ਦੇ ਵਿਚਕਾਰ।
ਵੱਡੇ ਗਾਹਕ ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲਾਂ ਨਵੇਂ ਫੀਚਰਾਂ ਦੀ ਮੰਗ ਨਹੀਂ ਕਰਦੇ। ਉਹ ਪੁੱਛਦੇ ਹਨ, "ਕੀ ਅਸੀਂ ਹਰ ਰੋਜ਼ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਇਸ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹਾਂ?" ਇੰਝ ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੇਣ ਦਾ ਤਰੀਕਾ ਇੱਕ ਹਾਰਡਨਿੰਗ ਯੋਜਨਾ ਦੀ ਪਾਲਣਾ ਅਤੇ ਸਬੂਤ ਨਿਕਲਣਾ ਹੈ, ਵਾਅਦ ਨਹੀਂ।
ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਪੂਰਾ ਕਰਦੇ ਹੋ ਅਤੇ ਜੋ ਗੁੰਮ ਹੈ ਉਹ ਲਿਖੋ। ਉਹ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਉਮੀਦਾਂ ਨੋਟ ਕਰੋ ਜੋ ਤੁਸੀਂ ਅੱਜ ਸੱਚਮੁੱਚ ਸਹਾਇਤ ਕਰ ਸਕਦੇ ਹੋ (ਉਪਲਬਧਤਾ ਟਾਰਗੇਟ, ਐਕਸੈਸ ਕੰਟਰੋਲ, ਆਡੀਟ ਲੌਗ, ਡੇਟਾ ਰਿਟੇੰਸ਼ਨ, ਡੇਟਾ ਰਿਹਾਇਸ਼, SSO, ਸਪੋਰਟ ਘੰਟੇ)। ਹਰ ਇੱਕ ਨੂੰ ready, partial, ਜਾਂ not yet ਦੇ ਤੌਰ 'ਤੇ ਨਿਸ਼ਾਨ ਲਗਾਓ। ਇਹ ਅਣਜ਼ਰਾ ਖਿੱਚ ਨੂੰ ਇੱਕ ਛੋਟੇ ਬੈਕਲੌਗ ਵਿੱਚ ਬਦਲ ਦੇਵੇਗਾ।
ਜੇ ਹੋਰ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਰਿਲੀਜ਼ ਸੁਰੱਖਿਆ ਸ਼ਾਮਲ ਕਰੋ। ਐਂਟਰਪ੍ਰਾਈਜ਼ ਨੂੰ ਇਹ ਘੱਟ ਪਰੇਸ਼ਾਨੀ ਹੁੰਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿੰਨੀ ਵਾਰੀ ਡਿਪਲੋਯ ਕਰਦੇ ਹੋ, ਅਤੇ ਵੱਧ ਇਹ ਕਿ ਤੁਸੀਂ ਬਿਨਾਂ ਘਟਨਾ ਦੇ ਡਿਪਲੋਯ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਨਹੀਂ। ਪ੍ਰੋਡਕਸ਼ਨ-ਜੈਸਾ ਸਟੇਜਿੰਗ ਵਰਤੋ। ਖਤਰਨਾਕ ਤਬਦੀਲੀਆਂ ਲਈ feature flags ਵਰਤੋਂ, gradual canary releases ਕਰੋ, ਅਤੇ ਇੱਕ ਤੇਜ਼ ਰੋਲਬੈਕ ਯੋਜਨਾ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ ਜੋ ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ (Koder.ai) ਸਹਾਇਤਾ ਕਰਦਾ ਹੈ, ਇੱਕ ਪਿਛਲਾ ਵਰਜ਼ਨ ਰੀਸਟੋਰ ਕਰਨ ਦਾ ਅਭਿਆਸ ਕਰੋ ਤਾਂ ਜੋ ਇਹ ਮਾਸਲ ਮੈਮੋਰੀ ਬਣ ਜਾਵੇ।
ਡੇਟਾ ਰੱਖਿਆ ਨੂੰ ਸਾਬਤ ਕਰੋ, ਫਿਰ ਦੁਬਾਰਾ ਸਾਬਤ ਕਰੋ। ਬੈਕਅੱਪਸ ਇਕ ਚੈਕਬਾਕਸ ਨਹੀਂ ਹਨ। ਆਟੋਮੇਟਿਕ ਬੈਕਅੱਪ ਸ਼ੈਡਿਊਲ ਕਰੋ, ਰਿਟੇੰਸ਼ਨ ਨਿਰਧਾਰਤ ਕਰੋ, ਅਤੇ ਇੱਕ ਕੈਲੇਂਡਰ 'ਤੇ ਰੀਸਟੋਰ ਟੈਸਟ ਚਲਾਓ। ਮਹੱਤਵਪੂਰਣ ਕਾਰਵਾਈਆਂ ਲਈ ਆਡੀਟ ਟਰੇਲ ਸ਼ਾਮਲ ਕਰੋ (ਐਡਮਿਨ ਬਦਲਾਅ, ਡੇਟਾ ਐਕਸਪੋਰਟ, ਪਰਮਿਸ਼ਨ ਸੋਧ) ਤਾਂ ਕਿ ਗਾਹਕ ਮੁਆਇਨੇ ਲਈ ਪੂਰਾ ਪਾਥ ਹੋਵੇ ਅਤੇ ਕੰਪਲਾਇੰਸ ਲੋੜਾਂ ਪੂਰੀਆਂ ਹੋਣ।
ਸਪੋਰਟ ਅਤੇ ਇੰਸੀਡੈਂਟ ਪ੍ਰਤੀਕਿਰਿਆ ਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ ਕਰੋ। ਇੱਕ ਇੱਕ-ਪੰਨੇ ਦਾ ਵਾਅਦਾ ਲਿਖੋ: ਘਟਨਾ ਰਿਪੋਰਟ ਕਰਨ ਦਾ ਤਰੀਕਾ, ਉਮੀਦਵਾਰ ਜਵਾਬ ਸਮੇਂ, ਕੌਣ ਅੱਪਡੇਟ ਕਰੇਗਾ, ਅਤੇ ਪੋਸਟ-ਇੰਸੀਡੈਂਟ ਰਿਪੋਰਟਿੰਗ ਕਿਵੇਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।
ਇੱਕ ਤਿਆਰ-ਚਕ ਕਰਨ ਵਾਲੀ ਸਮੀਖਿਆ ਚਲਾਓ ਜਿਸ ਵਿੱਚ ਹਕੀਕਤ-ਨੁਮਾ ਲੋਡ ਟੈਸਟ ਯੋਜਨਾ ਹੋ। ਇਕ ਐਂਟਰਪ੍ਰਾਈਜ਼-ਜੇਹੀ ਸਥਿਤੀ ਚੁਣੋ ਅਤੇ ਇਸ ਨੂੰ ਅੰਤ-ਤੱਕ ਟੈਸਟ ਕਰੋ: ਚੋਟੀ ਦਾ ਟ੍ਰੈਫਿਕ, ਧੀਮਾ ਡੇਟਾਬੇਸ, ਇੱਕ ਫੇਲ ਨੋਡ, ਅਤੇ ਇੱਕ ਰੋਲਬੈਕ। ਉਦਾਹਰਨ: ਇੱਕ ਨਵਾਂ ਗਾਹਕ ਸੋਮਵਾਰ ਸਵੇਰੇ 5 ਮਿਲੀਅਨ ਰਿਕਾਰਡ ਇੰਪੋਰਟ ਕਰਦਾ ਹੈ ਜਦੋਂ 2,000 ਯੂਜ਼ਰ ਲੌਗਇਨ ਅਤੇ ਰਿਪੋਰਟ ਚਲ ਰਹੇ ਹਨ। ਜੋ ਟੁੱਟਦਾ ਹੈ ਉਸ ਨੂੰ ਮਾਪੋ, ਸਭ ਤੋਂ ਵੱਡਾ ਬੋਤਲਨੈਕ ਠੀਕ ਕਰੋ, ਅਤੇ ਦੁਹਰਾਓ।
ਇਹ ਪੰਜ ਕਦਮ ਕਰੋ ਅਤੇ ਸੇਲਜ਼ ਗੱਲਬਾਤਾਂ ਆਸਾਨ ਹੋ ਜਾਣਗੀਆਂ ਕਿਉਂਕਿ ਤੁਸੀਂ ਆਪਣਾ ਕੰਮ ਦਿਖਾ ਸਕਦੇ ਹੋ।
ਇੱਕ ਮਿਡ-ਮਾਰਕੀਟ SaaS ਐਪ ਕੋਲ ਕੁਝ ਸੌ ਕਸਟਮਰ ਅਤੇ ਛੋਟੀ ਟੀਮ ਹੁੰਦੀ ਹੈ। ਫਿਰ ਇਹ ਆਪਣਾ ਪਹਿਲਾ ਨਿਯਮਤ ਗਾਹਕ ਦستخਤ ਕਰਦਾ ਹੈ: ਇੱਕ ਖੇਤਰੀ ਬੈਂਕ। ਕੰਟ੍ਰੈਕਟ ਵਿੱਚ ਖ਼ਾਸ ਉਪਲਬਧਤਾ ਤਰਜੀحات, ਕਸਕਡ-ਐਕਸੈਸ ਕੰਟਰੋਲ ਅਤੇ ਸੁਰੱਖਿਆ ਸਵਾਲਾਂ ਦੇ ਤੇਜ਼ ਜਵਾਬ ਦੀ ਗਰੰਟੀ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ। ਉਤਪਾਦ ਦੇ ਮੁੱਖ ਫੀਚਰਾਂ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ, ਪਰ ਚਲਾਉਣ ਦੇ ਨਿਯਮ ਬਦਲ ਜਾਂਦੇ ਹਨ।
ਪਹਿਲੇ 30 ਦਿਨਾਂ ਵਿੱਚ, ਟੀਮ "ਅਦ੍ਰਿਸ਼ਟ" ਅੱਪਗਰੇਡ ਕਰਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਦਾ ਅਸਰ ਗਾਹਕ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ। ਮਾਨੀਟਰਿੰਗ "ਕੀ ਅਸੀਂ ਚੱਲ ਰਹੇ ਹਾਂ?" ਤੋਂ "ਕੀ ਟੁੱਟਿਆ, ਕਿੱਥੇ, ਅਤੇ ਕਿਸ ਲਈ?" ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ। ਉਹ ਪ੍ਰਤੀ-ਸਰਵਿਸ ਡੈਸ਼ਬੋਰਡ ਸ਼ਾਮਲ ਕਰਦੇ ਹਨ ਅਤੇ ਉਪਭੋਗਤਾ ਪ੍ਰਭਾਵ ਨਾਲ ਜੁੜੇ ਅਲਾਰਟ ਬਣਾਉਂਦੇ ਹਨ, ਨਾ ਕਿ CPU ਸ਼ੋਰ ਨਾਲ। ਐਕਸੈਸ ਕੰਟਰੋਲ ਰਸਮੀ ਹੋ ਜਾਂਦੇ ਹਨ: ਐਡਮਿਨ ਕਾਰਵਾਈਆਂ ਲਈ ਮਜ਼ਬੂਤ ਪ੍ਰਮਾਣਿਕਤਾ, ਸਮੀਖਿਆ ਕੀਤੀ ਰੋਲ, ਅਤੇ ਲੌਗ ਕੀਤੀ ਗਈ, ਸਮੇਂ-ਸੀਮਿਤ ਪ੍ਰੋਡਕਸ਼ਨ ਪਹੁੰਚ। ਆਡੀਟਬਿਲਟੀ ਇੱਕ ਉਤਪਾਦ ਲੋੜ ਬਣ ਜਾਂਦੀ ਹੈ, ਲੌਗ ਨੂੰ ਲਗਾਤਾਰ ਲੌਗਇਨ ਫੇਲਯਰ, ਪਰਮਿਸ਼ਨ ਸੋਧ, ਡੇਟਾ ਐਕਸਪੋਰਟ ਅਤੇ ਸੰਰਚਨਾ ਸੋਧਾਂ ਲਈ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ।
ਦੋ ਹਫ਼ਤੇ ਬਾਅਦ, ਇੱਕ ਰਿਲੀਜ਼ ਗਲਤ ਹੋ ਜਾਂਦੀ ਹੈ। ਇੱਕ DB ਮਾਈਗਰੇਸ਼ਨ ਉਮੀਦ ਤੋਂ ਲੰਮਾ ਚੱਲਦੀ ਹੈ ਅਤੇ ਕੁਝ ਯੂਜ਼ਰਾਂ ਲਈ ਰਿਕਵੇਸਟ ਟਾਈਮਆਉਟ ਹੋਣ ਲੱਗਦੇ ਹਨ। ਜੋ ਸ਼ੀਅਰਲੈਸ ਬਹੁ-ਦਿਨੀ ਘਟਨਾ ਬਣਨ ਤੋਂ ਰੋਕਦਾ ਹੈ ਉਹ ਹੈ ਬੁਨਿਆਦੀ ਅਨੁਸ਼ਾਸਨ: ਇੱਕ ਸਪੱਸ਼ਟ ਰੋਲਬੈਕ ਯੋਜਨਾ, ਇੱਕ ਇਕੱਲਾ ਇੰਸੀਡੈਂਟ ਲੀਡ, ਅਤੇ ਇੱਕ ਸੰਚਾਰ ਸਕ੍ਰਿਪਟ।
ਉਹ ਰੋਲਆਉਟ ਰੋਕਦੇ ਹਨ, ਸਲੋ ਪਾਥ ਤੋਂ ਟ੍ਰੈਫਿਕ ਹਟਾਉਂਦੇ ਹਨ, ਅਤੇ ਪਿਛਲੇ ਜਾਣੇ-ਮਾਨੇ ਚੰਗੇ ਵਰਜ਼ਨ 'ਤੇ ਰੋਲਬੈਕ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਹਾਡਾ ਪਲੇਟਫਾਰਮ snapshots ਅਤੇ rollback (Koder.ai) ਸਹਾਇਤਾ ਕਰਦਾ ਹੈ, ਇਹ ਜ਼ਿਆਦਾ ਤੇਜ਼ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ ਹੌਲੀ-ਹੌਲੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਰਿਕਵਰੀ ਦੌਰਾਨ, ਉਹ ਹਰ 30 ਮਿੰਟ 'ਤੇ ਛੋਟੇ ਅਪਡੇਟ ਭੇਜਦੇ ਹਨ: ਕੀ ਪ੍ਰਭਾਵਤ ਹੈ, ਕੀ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ, ਅਤੇ ਅਗਲੀ ਚੈਕ-ਇਨ ਦਾ ਸਮਾਂ।
ਇੱਕ ਮਹੀਨੇ ਬਾਅਦ, "ਸਫਲਤਾ" ਸਭ ਤੋਂ ਚੰਗੀ ਤਰ੍ਹਾਂ ਬੋਰਿੰਗ ਲੱਗਦੀ ਹੈ। ਅਲਾਰਟ ਘੱਟ ਪਰ ਅਤੇ ਜ਼ਿਆਦਾ ਮਾਇਨਿੰਗ ਵਾਲੇ ਹੋ ਜਾਂਦੇ ਹਨ। ਰਿਕਵਰੀ ਤੇਜ਼ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਮਲਕੀਅਤ ਸਪੱਸ਼ਟ ਹੈ: ਇੱਕ ਵਿਅਕਤੀ on-call, ਇੱਕ ਵਿਅਕਤੀ ਸਹਿਯੋਜਕ, ਅਤੇ ਇੱਕ ਵਿਅਕਤੀ ਸੰਚਾਰ ਲਈ। ਬੈਂਕ ਹੁਣ ਨਹੀਂ ਪੁੱਛਦੀ "ਕੀ ਤੁਸੀਂ ਕਾਬੂ ਵਿੱਚ ਹੋ?" ਸਗੋਂ ਪੁੱਛਦੀ ਹੈ "ਅਸੀਂ ਕਦੋਂ ਵੱਡਾ ਰੋਲਆਉਟ ਕਰ ਸਕਦੇ ਹਾਂ?"
ਵਿਕਾਸ ਨੇ ਨਿਯਮ ਬਦਲ ਦਿਤੇ। ਵੱਧ ਯੂਜ਼ਰ, ਵੱਧ ਡੇਟਾ, ਅਤੇ ਵੱਡੇ ਗਾਹਕ ਮਤਲਬ ਕਿ ਛੋਟੇ ਫੁਟਕੇ ਆਉਟੇਜ, ਸ਼ੋਰ-ਭਰੇ ਇੰਸੀਡੈਂਟ ਜਾਂ ਲੰਬੇ ਸਪੋਰਟ ਥਰੇਡ ਬਣ ਜਾਂਦੇ ਹਨ। ਇਹਨਾਂ ਚੀਜ਼ਾਂ ਦਾ ਅਹਿਸਾਸ "ਠੀਕ" ਤੱਕ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਆਪਣਾ ਪਹਿਲਾ ਵੱਡਾ ਕੰਟ੍ਰੈਕਟ ਸਾਈਨ ਨਹੀਂ ਕਰ ਲੈਂਦੇ।
ਅਕਸਰ ਆਉਣ ਵਾਲੀਆਂ ਫਸਲਾਂ:
ਇੱਕ ਸਧਾਰਣ ਉਦਾਹਰਣ: ਇੱਕ ਟੀਮ ਇੱਕ ਵੱਡੇ ਗਾਹਕ ਲਈ ਕਸਟਮ ਇੰਟੇਗ੍ਰੇਸ਼ਨ ਜੋੜਦੀ ਹੈ ਅਤੇ ਸ਼ੁੱਕਰਵਾਰ ਰਾਤ ਨੂੰ ਹੋਟਫਿਕਸ ਵਜੋਂ ਡਿਪਲੋਯ ਕਰ ਦਿੰਦੀ ਹੈ। ਕੋਈ ਤੇਜ਼ ਰੋਲਬੈਕ ਨਹੀਂ, ਅਲਾਰਟ ਪਹਿਲਾਂ ਹੀ ਸ਼ੋਰ ਨਾਲ ਭਰੇ ਹੋਏ, ਅਤੇ on-call ਵਿਅਕਤੀ ਅਨੁਮਾਨ ਲਾ ਰਿਹਾ ਹੈ। ਬੱਗ ਛੋਟੀ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਰਿਕਵਰੀ ਘੰਟਿਆਂ ਲਈ ਖਿੱਚਦੀ ਹੈ ਕਿਉਂਕਿ ਰੀਸਟੋਰ ਰਾਹ ਕਦੇ ਟੈਸਟ ਨਹੀਂ ਕੀਤਾ ਗਿਆ।
ਜੇ ਤੁਹਾਡੀ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਤਿਆਰੀ ਚੈਕਲਿਸਟ ਵਿੱਚ ਸਿਰਫ਼ ਤਕਨੀਕੀ ਆਈਟਮ ਹਨ, ਤਾਂ ਇਸਨੂੰ ਵਧਾਓ। ਰੋਲਬੈਕ, ਰੀਸਟੋਰ ਡ੍ਰਿਲਜ਼, ਅਤੇ ਇੱਕ ਸੰਚਾਰ ਯੋਜਨਾ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਸਪੋਰਟ ਇੰਜੀਨੀਅਰਿੰਗ ਦੇ ਬਿਨਾਂ ਚਲਾ ਸਕੇ।
ਜਦੋਂ ਵੱਡੇ ਗਾਹਕ ਪੁੱਛਦੇ ਹਨ "ਕੀ ਤੁਸੀਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਲਈ ਤਿਆਰ ਹੋ?", ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਗੱਲ ਪੁੱਛ ਰਹੇ ਹੁੰਦੇ ਹਨ: ਕੀ ਅਸੀਂ ਪ੍ਰੋਡਕਸ਼ਨ 'ਤੇ ਇਸਤੇਮਾਲ ਕਰਕੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹਾਂ? ਵਿਕਰੀ-ਕਾਲ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਆਪ ਨੂੰ ਸੰਖੇਪ ਸਵੈ-ਅਡਿਟ ਲਈ ਇਹ ਵਰਤੋਂ।
ਡੈਮੋ ਦਿਖਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਐਸਾ ਸਬੂਤ ਇਕੱਠਾ ਕਰੋ ਜੋ ਤੁਸੀਂ ਬਿਨਾਂ ਹਲਕਾ-ਫਿਰਕਾ ਦਿਖਾ ਸਕੋ: ਮਾਨੀਟਰਿੰਗ ਸਕਰੀਨਸ਼ਾਟ ਜੋ ਐਰਰ ਦਰ ਅਤੇ ਲੈਟੈਂਸੀ ਦਿਖਾਉਂਦੇ ਹਨ, ਇੱਕ ਰੈਡੈਕਟ ਕੀਤੇ ਹੋਏ ਆਡੀਟ ਲੌਗ ਉਦਾਹਰਨ ("ਕਿਸਨੇ ਕੀ ਕੀਤਾ, ਕਦੋਂ"), ਇੱਕ ਛੋਟਾ ਰੀਸਟੋਰ ਡ੍ਰਿਲ ਨੋਟ (ਤੁਸੀਂ ਕੀ ਰੀਸਟੋਰ ਕੀਤਾ ਅਤੇ ਕਿੰਨਾ ਸਮਾਂ ਲੱਗਾ), ਅਤੇ ਇੱਕ ਇੱਕ-ਪੰਨੇ ਦਾ ਰਿਲੀਜ਼ ਅਤੇ ਰੋਲਬੈਕ ਨੋਟ।
ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਐਪ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਨ੍ਹਾਂ ਚੈੱਕਸ ਨੂੰ ਇਕੋ ਤਰੀਕੇ ਨਾਲ ਵਿਚਾਰੋ। ਟਾਰਗੇਟ, ਸਬੂਤ, ਅਤੇ ਦੁਹਰਾਏ ਜਾਓ-ਯੋਗ ਆਦਤਾਂ ਸੋਝੀ ਤੋਂ ਮੁੱਖ ਹਨ, ਨਾ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ ਟੂਲ ਵਰਤਿਆ।
ਐਂਟਰਪ੍ਰਾਈਜ਼ ਤਿਆਰੀ ਇੱਕ ਇਕ-ਵਾਰ ਦਾ ਧੱਕਾ ਨਹੀਂ ਹੈ ਪਹਿਲਾਂ ਕਿਸੇ ਵੱਡੇ ਸੌਦੇ ਤੋਂ ਪਹਿਲਾਂ। ਇਸਨੂੰ ਇੱਕ ਰੋਜ਼ਾਨਾ ਰੁਟੀਨ ਬਣਾਓ ਜੋ ਤੁਹਾਡੇ ਉਤਪਾਦ ਨੂੰ ਦਬਾਅ ਹੇਠਾਂ ਠੰਢਾ ਰੱਖੇ, ਚਾਹੇ ਟੀਮਾਂ, ਟ੍ਰੈਫਿਕ ਅਤੇ ਗਾਹਕ ਉਮੀਦਾਂ ਵੱਧ ਰਹੀਆਂ ਹੋਣ।
ਆਪਣੀ ਚੈਕਲਿਸਟ ਨੂੰ ਇੱਕ ਛੋਟੀ ਕਾਰਵਾਈ ਯੋਜਨਾ ਵਿੱਚ ਬਦਲੋ। ਸਭ ਤੋਂ ਵੱਧ ਜੋਖਮ ਪੈਦਾ ਕਰਨ ਵਾਲੇ 3 ਗੈਪ ਚੁਣੋ, ਉਨ੍ਹਾਂ ਨੂੰ ਵਿਜ਼ੀਬਲ ਬਣਾਓ, ਅਤੇ ਮਾਲਕ ਮੁਕੱਦਰ ਮਿਤੀਆਂ ਨਾਲ ਨਿਯੁਕਤ ਕਰੋ। "ਕਿਆ ਹੋਇਆ" ਨੂੰ ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ (ਉਦਾਹਰਨ: "ਅਲਾਰਟ 5 ਮਿੰਟ ਵਿੱਚ ਟ੍ਰਿਗਰ ਹੋਣਾ" ਜਾਂ "ਰੀਸਟੋਰ ਐਂਡ-ਟੂ-ਐਂਡ ਟੈਸਟ ਕੀਤਾ ਗਿਆ"). ਐਂਟਰਪ੍ਰਾਈਜ਼ ਬਲਾਕਰਾਂ ਲਈ ਆਪਣੀ ਬੈਕਲੌਗ ਵਿੱਚ ਇੱਕ ਛੋਟਾ ਲੇਨ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਰੰਤ ਕੰਮ ਸੋਚਿਆ ਨਹੀਂ ਜਾਵੇ। ਜਦ ਤੁਸੀਂ ਕੋਈ ਗੈਪ ਬੰਦ ਕਰੋ, ਲਿਖੋ ਕਿ ਕੀ ਬਦਲਿਆ ਤਾਂ ਜੋ ਨਵੇਂ ਸਾਥੀ ਦੁਬਾਰਾ ਕਰ ਸਕਣ।
ਹਰ ਵੱਡੇ ਪ੍ਰੋਸਪੈਕਟ ਲਈ ਇੱਕ ਅੰਦਰੂਨੀ ਤਿਆਰ-ਦਸਤਾਵੇਜ਼ ਬਣਾਓ ਜੋ ਤੁਸੀਂ ਦੁਹਰਾਓ। ਇਹ ਛੋਟਾ ਰੱਖੋ, ਅਤੇ ਹਰ ਗੰਭੀਰ ਗਾਹਕ ਗੱਲਬਾਤ ਤੋਂ ਬਾਅਦ ਅਪਡੇਟ ਕਰੋ। ਇੱਕ ਸਧਾਰਨ ਫਾਰਮੈਟ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ: ਭਰੋਸੇਯੋਗਤਾ ਟਾਰਗੇਟ, ਸੁਰੱਖਿਆ ਮੁਢਲੀਆਂ, ਡੇਟਾ ਹੈਂਡਲਿੰਗ, ਡਿਪਲੋਯਮੈਂਟ ਅਤੇ ਰੋਲਬੈਕ, ਅਤੇ ਕੌਣ on-call ਹੈ।
ਭਰੋਸੇਯੋਗਤਾ ਸਮੀਖਿਆਵਾਂ ਨੂੰ ਮਹੀਨੇਵਾਰ ਆਦਤ ਬਣਾਓ ਜੋ ਅਸਲ ਘਟਨਾਵਾਂ ਨਾਲ ਜੁੜੀਆਂ ਹੋਣ, ਰਾਇਆਂ ਨਾਲ ਨਹੀਂ। ਇਨਸੀਡੈਂਟ ਅਤੇ ਨਿਰਵਚਨਾਲੇ ਧਪਕਾਂ ਨੂੰ ਆਪਣੀ ਏਜੰਡਾ ਬਣਾਓ: ਕੀ ਫੇਲ ਹੋਇਆ, ਤੁਸੀਂ ਕਿਵੇਂ ਪਛਾਣਿਆ, ਤੁਸੀਂ ਕਿਵੇਂ ਰਿਕਵਰ ਕੀਤਾ, ਅਤੇ ਕੀ ਰੋਕੇਗਾ ਕਿ ਇਹ ਫੇਰ ਦੁਹਰਾਏ।
ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, readiness ਨੂੰ ਆਪਣੇ ਸ਼ਿਪਿੰਗ ਤਰੀਕੇ ਵਿੱਚ ਬੁਣ ਦਿਓ। Planning Mode ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਵਰਤੋ ਤਾਂ ਕਿ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਲੋੜਾਂ ਨੂੰ ਬਿਲਡ ਤੱਕ ਜਾਦੋਂ ਪੱਕਾ ਕੀਤਾ ਜਾ ਸਕੇ, ਅਤੇ ਰਿਲੀਜ਼ ਦੌਰਾਨ snapshots ਅਤੇ rollback 'ਤੇ ਭਰੋਸਾ ਕਰੋ ਤਾਂ ਕਿ ਸਾਫਟਵੇਅਰ ਠੀਕ ਰਹਿਣ ਜਦੋਂ ਤੁਹਾਡੀ ਪ੍ਰਕਿਰਿਆ ਪੱਕੀ ਹੋ ਰਹੀ ਹੋਵੇ। ਜੇ ਤੁਸੀਂ ਇਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਕੇਂਦਰਿਤ ਕਰਨ ਲਈ ਇੱਕ ਹੀ ਥਾਂ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ koder.ai ਚੈਟ ਰਾਹੀਂ ਬਣਾਉਣ ਅਤੇ ਦੁਹਰਾਉਣ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਦੋਂ ਕਿ πραਯੋਗਿਕ ਨਿਯੰਤਰਣ ਜਿਵੇਂ ਸੋਰਸ ਐਕਸਪੋਰਟ, ਡਿਪਲੋਯਮੈਂਟ ਅਤੇ ਰੋਲਬੈਕ ਵੀ ਐਸੇ ਹੀ ਨਾਜ਼ੁਕ ਤਰੀਕੇ ਨਾਲ ਪਹੁੰਚਯੋਗ ਹਨ।
ਹਣੇ ਸੌਦੇ ਤੱਕ ਨਹੀਂ — ਪਹਿਲਾਂ ਸ਼ੁਰੂ ਕਰੋ। ਦੋ ਤਿੰਨ ਮਾਪੇ ਜਾ ਸਕਣ ਵਾਲੇ ਟਾਰਗੇਟ ਚੁਣੋ (ਉਪਲਬਧਤਾ, ਮੁੱਖ ਕਾਰਵਾਈਆਂ ਲਈ ਲੈਟੈਂਸੀ, ਅਤੇ ਮਨਜ਼ੂਰਤ ਤਰੁੱਟੀ ਦਰ), ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਰੱਖਣ ਲਈ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਬਣਾਓ: ਉਪਭੋਗਤਾ ਪ੍ਰਭਾਵ ਨਾਲ ਜੁੜੀ ਮਾਨੀਟਰਿੰਗ, ਤੇਜ਼ੀ ਨਾਲ ਅਮਲ ਕਰਨ ਯੋਗ ਰੋਲਬੈਕ ਰਾਸ਼ਤਾ, ਅਤੇ ਟੈਸਟ ਕੀਤੀਆਂ ਰੀਸਟੋਰਸ।
ਜੇ ਤੁਸੀਂ ਇੰਤਜ਼ਾਰ ਕਰੋ گے ਜਦੋਂ ਪ੍ਰੋਕਿਊਰਮੈਂਟ ਪੁੱਛੇਗਾ, ਤਾਂ ਤੁਹਾਨੂੰ ਗੈਰ-ਰੂਪ ਵਾਲੀਆਂ ਵਾਦਿਆਂ ਉਤੇ ਜਵਾਬ ਦੇਣਾ ਪਏਗਾ ਜਿਹੜੇ ਤੁਸੀਂ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦੇ।
ਕਿਉਂਕਿ ਐਂਟਰਪ੍ਰਾਈਜ਼ਾਂ ਦਾ ਧਿਆਨ ਪੇਸ਼ਗੀਅੰਦਾਜ਼ੀ ਚਲਾਉਣ ਤੇ ਹੁੰਦਾ ਹੈ, ਨਾ ਕੇਵਲ ਫੀਚਰਾਂ 'ਤੇ। ਇੱਕ ਛੋਟੀ ਟੀਮ ਛੋਟੇ ਬਰੇਕ ਅਤੇ ਤੁਰੰਤ ਮੁਰੰਮਤ ਨੂੰ ਬਰਦਾਸ਼ਤ ਕਰ ਸਕਦੀ ਹੈ; ਪਰ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਅਕਸਰ ਮੰਗਦੇ ਹਨ:
ਭਰੋਸਾ ਉਸ ਸਮੇਂ ਟੁੱਟਦਾ ਹੈ ਜਦ ਵਿਹਾਰ ਹੈਰਾਨੀਜਨਕ ਹੁੰਦਾ ਹੈ, ਭਾਵੇਂ ਬੱਗ ਛੋਟਾ ਹੋਵੇ।
ਇੱਕ ਛੋਟੀ ਸੀ ਲਿਸਟ ਵਰਤੋਂ ਜੋ ਉਪਭੋਗਤਾ-ਸਮ੍ਹਣ ਵਾਲੀਆਂ ਵਚਨਾਂ 'ਤੇ ਧਿਆਨ ਦੇਵੇ:
ਫਿਰ ਇੱਕ ਐਰਰ ਬਜਟ ਬਣਾਓ ਕਿਸੇ ਸਮੇਂ-ਖਿੜਕੀ ਲਈ। ਜਦ ਤੁਸੀਂ ਬਜਟ ਖਰਚ ਕਰ ਲੈਂਦੇ ਹੋ ਤਾਂ ਘੜੀਆਂ ਖੋਜੋ ਅਤੇ ਪਹਿਲਾਂ ਭਰੋਸੇਯੋਗਤਾ ਮਾਮਲੇ ਸਾਂਭੋ।
ਚੇਨਬਦਲੀ ਨੂੰ ਮੁੱਖ ਜੋਖਮ ਮੰਨੋ:
ਜੇ ਤੁਹਾਡਾ ਪਲੇਟਫਾਰਮ snapshots ਅਤੇ rollback (ਉਦਾਹਰਣ ਲਈ Koder.ai) ਸਹਾਇਤਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹ ਵਰਤੋ — ਪਰ ਮਨੁੱਖੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਰਿਹਰਸਲ ਫਿਰ ਵੀ ਜ਼ਰੂਰੀ ਹੈ।
ਬੈਕਅੱਪਸ ਸਿਰਫ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਡੇਟਾ ਕਿਤੇ ਨਕਲ ਕੀਤਾ ਗਿਆ ਸੀ। ਐਂਟਰਪ੍ਰਾਈਜ਼ ਪੁੱਛਣਗੇ ਕਿ ਤੁਸੀਂ ਜਾਣ-ਬੁਝ ਕੇ ਰੀਸਟੋਰ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਇਹ ਕਿੰਨਾ ਸਮਾਂ ਲਵੇਗਾ।
ਘੱਟੋ-ਘੱਟ ਵਰਤੀ ਜਾਂਦੀ ਕਾਰਵਾਈਆਂ:
ਜੇ ਤੁਸੀਂ ਕਦੇ ਰੀਸਟੋਰ ਨਹੀਂ ਕੀਤਾ, ਤਾਂ ਬੈਕਅੱਪ ਧਾਰਨਾ ਹੈ, ਕਾਬਲੀਅਤ ਨਹੀਂ।
ਸਧਾਰਨ ਅਤੇ ਜ਼ਰੂਰੀ ਨਿਯਮ:
ਪ੍ਰਤੱਖਤਾ ਦੀ ਉਮੀਦ ਰੱਖੋ: ਵਿਭਾਗਾਂ, ਠੇਕੇਦਾਰਾਂ, ਅਸਥਾਇੀ ਐਕਸੈੱਸ ਅਤੇ "ਕੌਣ ਡੇਟਾ ਐਕਸਪੋਰਟ ਕਰ ਸਕਦਾ ਹੈ?" ਵਰਗੇ ਸਵਾਲ ਜਲਦੀ ਜਟਿਲ ਹੋ ਜਾਂਦੇ ਹਨ।
ਸੰਵੇਦਨਸ਼ੀਲ ਘਟਨਾਵਾਂ ਲਈ “ਕਿਸਨੇ ਕਦੋਂ ਕੀ ਕੀਤਾ ਅਤੇ ਕਿੱਥੋਂ” ਦਾ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਕਾਰਵਾਈਆਂ ਲੌਗ ਕਰੋ:
ਲੌਗ ਤਾੜ-ਬਰਦਾਸ਼ਤ (tamper-resistant) ਰੱਖੋ ਅਤੇ ਰੀਟੇੰਸ਼ਨ ਗਾਹਕ ਦੀਆਂ ਉਮੀਦਾਂ ਦੇ ਅਨੁਸਾਰ ਰੱਖੋ।
ਘੱਟ-ਜ਼ਿਆਦਾ ਅਲਾਰਮ ਲਈ ਉਦੇਸ਼ ਰੱਖੋ:
ਉਤੇਜਕ ਅਲਾਰਮ ਟੀਮਾਂ ਨੂੰ ਇੱਕ-ਅਹਮ ਪੇਜ ਨੂੰ ਅਣਦੇਖਾ ਕਰਨ ਲਈ ਸਿਖਾਉਂਦੇ ਹਨ।
ਵੱਖ-ਵੱਖ ਗਾਹਕ ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਘੱਟ ਕਰਨ ਲਈ ਅਲੱਗ-ਅਲੱਗ ਕੰਟਰੋਲ:
ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਇੱਕ ਗਾਹਕ ਦੀ ਸਮੱਸਿਆ ਸਾਰੇ ਗਾਹਕਾਂ ਦਾ ਆਉਟੇਜ ਨਾ ਬਣੇ।
ਇਕ ਯਥਾਰਥਪੂਰਕ ਸਿਨਾਰਿਓ ਅੰਤ-ਤੱਕ ਚਲਾਓ:
ਰੋਕਣ ਵਾਲੀਆ ਚੀਜ਼ਾਂ (ਲੈਟੈਂਸੀ, ਟਾਈਮਆਉਟ, ਕਿਊ ਡੇੱਪਥ) ਨੂੰ ਮੈਜ਼ਰ ਕਰੋ, ਸਭ ਤੋਂ ਵੱਡਾ ਬੋਤਲਨੈਕ ਸਧਾਰੋ, ਅਤੇ ਦੁਹਰਾਓ। ਇੱਕ ਆਮ ਟੈਸਟ ਇੱਕ ਵੱਡਾ ਇੰਪੋਰਟ ਹੈ ਜੋ ਆਮ ਟ੍ਰੈਫਿਕ ਨਾਲ ਇੱਕਠੇ ਚੱਲਦਾ ਹੈ ਪਰ ਬੈਚਿੰਗ ਅਤੇ ਕਿਊਜ਼ ਰਾਹੀਂ ਅਲੱਗ ਕੀਤਾ ਗਿਆ ਹੈ।
