22 ਅਗ 2025·8 ਮਿੰਟ
ਮਾਰਗਰੇਟ ਹੈਮਿਲਟਨ ਦੀਆਂ ਅਪੋਲੋ ਸਿਖਿਆਵਾਂ: ਅੱਜ ਦੇ ਭਰੋਸੇਯੋਗ ਸੌਫਟਵੇਅਰ ਲਈ
ਅਪੋਲੋ ਦੀ ਇੰਜੀਨੀਅਰਿੰਗ ਤੋਂ ਸਿੱਖਿਆ: ਭਰੋਸੇਯੋਗਤਾ ਦੇ ਮੂਲ, ਸੁਰੱਖਿਅਤ ਟੈਸਟਿੰਗ, ਰਿਲੀਜ਼ ਤਿਆਰੀ ਅਤੇ Margaret Hamilton ਦੀ ਪ੍ਰੇਰਣਾ।
ਅਪੋਲੋ ਦੀ ਇੰਜੀਨੀਅਰਿੰਗ ਤੋਂ ਸਿੱਖਿਆ: ਭਰੋਸੇਯੋਗਤਾ ਦੇ ਮੂਲ, ਸੁਰੱਖਿਅਤ ਟੈਸਟਿੰਗ, ਰਿਲੀਜ਼ ਤਿਆਰੀ ਅਤੇ Margaret Hamilton ਦੀ ਪ੍ਰੇਰਣਾ।
Margaret Hamilton ਨੇ MIT ਦੀ Instrumentation Laboratory (ਜੋ ਬਾਅਦ ਵਿੱਚ Draper Laboratory ਬਣੀ) ਵਿੱਚ NASA ਦੇ Apollo ਮਿਸ਼ਨਾਂ ਲਈ ਬੋਰਡ-ਆਨ ਫ਼ਲਾਈਟ ਸੌਫਟਵੇਅਰ ਬਣਾਉਣ ਵਾਲੀ ਟੀਮ ਦੀ ਅਗਵਾਈ ਕੀਤੀ। ਉਹ ਇਕੱਲੀ ਵਿਅਕਤੀ ਵਜੋਂ ਆਧੁਨਿਕ ਸੌਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰਿੰਗ ਦਾ ਬਣਾਉਣ ਵਾਲਾ ਨਹੀਂ ਸੀ, ਪਰ ਉਹਦੀ ਕੰਮ ਅਤੇ ਨੇਤ੍ਰਿਤਵ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਕਿਵੇਂ ਅਨੁਸ਼ਾਸ਼ਤ ਅਭਿਆਸ ਪਰੇਸ਼ਾਨੀ ਦੇ ਸਮੇਂ ਵਿੱਚ ਜਟਿਲ ਸਿਸਟਮਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਰੱਖਦੇ ਹਨ।
ਸੌਫਟਵੇਅਰ ਭਰੋਸੇਯੋਗਤਾ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡਾ ਉਤਪਾਦ ਉਮੀਦਾਂ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦਾ ਹੈ—ਅਤੇ ਉਹਨਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਵੀ ਕੰਮ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦਾ ਹੈ ਜਦੋਂ ਹਾਲਤਾਂ ਗੜਬੜ ਹਨ: ਵੱਧ ਟ੍ਰੈਫਿਕ, ਖਰਾਬ ਇਨਪੁੱਟ, ਅੰਸ਼ਿਕ ਠਹਿਰਾਵ, ਮਨੁੱਖੀ ਗਲਤੀਆਂ, ਅਤੇ ਹੈਰਾਨ ਕਰਨ ਵਾਲੇ ਏਜ ਕੇਸ। ਇਹ ਸਿਰਫ "ਘੱਟ ਬੱਗ" ਨਹੀਂ; ਇਹ ਐਸਾ ਵਿਸ਼ਵਾਸ ਹੈ ਕਿ ਸਿਸਟਮ ਪੇਸ਼ ਕੋਈ ਅਚਾਨਕ ਵਿਹਾਰ ਨਹੀਂ ਕਰੇਗਾ, ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੋਵੇਗਾ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਵਾਪਸ ਆਵੇਗਾ।
ਅਪੋਲੋ ਦੇ ਪਾਬੰਧ ਨਹੀਂ ਦਿਨਦਾਰ ਸਾਫਲਤਾ ਲਈ ਦਿਸ਼ਾ ਸਪਸ਼ਟ ਕਰਦੇ ਸਨ: ਸੀਮਿਤ ਕંપਿੂਟਿੰਗ ਪਾਵਰ, ਮਿਡ-ਫਲਾਈਟ "ਹੌਟਫਿਕਸ" ਦੀ ਅਸਮਰਥਾ, ਅਤੇ ਨੁਕਸਾਨ ਦੇ ਤੁਰੰਤ ਤੇ ਭਾਰੀ ਨਤੀਜੇ। ਇਹ ਪਾਬੰਧ ਟੀਮਾਂ ਨੂੰ ਅਜਿਹੇ ਆਦਤਾਂ ਵੱਲ ਧੱਕਦੇ ਰਹੇ ਜੋ ਅਜੇ ਵੀ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ: ਨਿੱਕੀ-ਨਿੱਖਰੀਆਂ ਲੋੜਾਂ, ਧਿਆਨ ਨਾਲ ਚੇਂਜ ਕੰਟਰੋਲ, ਪਰਤਦਾਰ ਟੈਸਟਿੰਗ, ਅਤੇ "ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ" ਤੇ ਇਕ ਜੋਰ।
ਤੁਹਾਨੂੰ ਰਾਕੇਟ ਬਣਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਕਿ ਇਹ ਸਬਕ ਲਾਗੂ ਹੋਣ। ਆਧੁਨਿਕ ਟੀਮਾਂ ਹਰ ਰੋਜ਼ ऐसे ਸਿਸਟਮ ਛੱਡਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਤੇ ਲੋਕ ਨਿਰਭਰ ਕਰਦੇ ਹਨ—ਭੁਗਤਾਨ, ਹੈਲਥਕੇਅਰ ਪੋਰਟਲ, ਲੌਜਿਸਟਿਕਸ, ਕਸਟਮਰ ਸਪੋਰਟ ਟੂਲ, ਜਾਂ ਮਾਰਕੀਟਿੰਗ ਸਪੀਕ ਦੇ ਦੌਰਾਨ ਸਾਇਨਅਪ ਫਲੋ। ਦਾਅਵੇ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਪੈਟਰਨ ਇੱਕੋ ਹੈ: ਭਰੋਸੇਯੋਗਤਾ ਆਖਰੀ ਮਿੰਟ ਦਾ ਟੈਸਟ ਨਹੀਂ; ਇਹ ਇਕ ਇੰਜੀਨੀਅਰਿੰਗ ਦਾ ਢੰਗ ਹੈ ਜੋ ਚੰਗੇ ਨਤੀਜੇ ਦੁਹਰਾ ਸਕੇ।
ਅਪੋਲੋ ਸੌਫਟਵੇਅਰ ਸਬ ਤੋਂ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਸੇਫਟੀ-ਕ੍ਰਿਟੀਕਲ ਸੀ: ਇਹ ਸਿਰਫ ਕਿਸੇ ਬਿਜਨਸ ਪ੍ਰਕਿਆ ਨੂੰ ਸਹਾਇਤਾ ਨਹੀਂ ਕਰ ਰਿਹਾ ਸੀ—ਇਹ ਅਸਟਰੋਨੌਟਾਂ ਦੀ ਜ਼ਿੰਦਗੀ ਨਿਭਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਰਿਹਾ ਸੀ, ਜਦੋਂ ਕਿ ਵਾਹਨ ਨੂੰ ਨੈਵੀਗੇਟ, ਉਤਰਾਈ ਅਤੇ ਡਾਕਿੰਗ ਕਰਵਾਈ ਜਾਂਦੀ ਸੀ। ਇੱਕ ਗਲਤ ਮੁੱਲ, ਇੱਕ ਛੁੱਟਿਆ ਟਾਈਮਿੰਗ ਵਿੰਡੋ, ਜਾਂ ਇੱਕ ਗੁੰਝਲਦਾਰ ਡਿਸਪਲੇ ਇੱਕ ਛੋਟੀ ਗਲਤੀ ਨਹੀਂ ਸੀ; ਇਹ ਮਿਸ਼ਨ ਦੇ ਨਤੀਜੇ ਬਦਲ ਸਕਦਾ ਸੀ।
ਅਪੋਲੋ ਦੇ ਕੰਪਿਊਟਰਾਂ ਦੇ ਕੋਲ ਬਹੁਤ ਹੀ ਸੀਮਿਤ ਕੰਪਿਊਟਿੰਗ ਪਾਵਰ ਅਤੇ ਮੈਮੋਰੀ ਸੀ। ਹਰ ਫੀਚਰ ਕੰਗਾਲ ਰਿਸੋਰਸ ਲਈ ਮੁਕਾਬਲਾ ਕਰਦਾ ਸੀ, ਅਤੇ ਹਰ ਇਕ ਵਾਧੂ ਹਦਾਇਤ ਦੀ ਇੱਕ ਅਸਲੀ ਲਾਗਤ ਸੀ। ਟੀਮਾਂ ਇਨਫ਼ੀਸ਼ਨਸੀਜ਼ ਨੂੰ ਵੱਡੇ ਸਰਵਰ ਜਾਂ ਹੋਰ RAM ਨਾਲ ਛੁਪਾ ਨਹੀਂ ਸਕਦੀਆਂ ਸਨ।
ਇਸ ਤੋਂ ਵੀ ਮਹੱਤਵਪੂਰਣ, ਮਿਡ-ਫਲਾਈਟ ਪੈਚ ਕਰਨਾ ਆਮ ਵਿਕਲਪ ਨਹੀਂ ਸੀ। ਜਦੋਂ ਵਾਹਨ ਰਸਤੇ 'ਤੇ ਹੁੰਦਾ, ਅਪਡੇਟਸ ਖਤਰਨਾਕ ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ, ਕਮਿਊਨੀਕੇਸ਼ਨ ਸੀਮਾਵਾਂ, ਅਤੇ ਮਿਸ਼ਨ ਟਾਈਮਿੰਗ ਨਾਲ ਸੀਮਿਤ ਹੁੰਦੀਆਂ। ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਡਿਜ਼ਾਇਨ ਕਰਨਾ ਅਤੇ ਦਿਖਾਉਣਾ ਲਾਜ਼ਮੀ ਸੀ।
ਜਦੋਂ ਨੁਕਸਾਨ ਮਹਿੰਗਾ ਹੋਵੇ—ਮਾਨਵ ਸੁਰੱਖਿਆ, ਮਿਸ਼ਨ ਦੀ ਹਾਨੀ, ਅਤੇ ਰਾਸ਼ਟਰੀ ਭਰੋਸੇਯੋਗਤਾ ਵਿੱਚ—ਤਾਂ ਅਨੁਸ਼ਾਸ਼ਨ ਬੇ-ਵਿਕਲਪ ਹੋ ਜਾਂਦਾ ਹੈ। ਸਪਸ਼ਟ ਲੋੜਾਂ, ਧਿਆਨ ਨਾਲ ਚੇਂਜ ਕੰਟਰੋਲ, ਅਤੇ ਕੜੀ ਟੈਸਟਿੰਗ ਕੋਈ ਬਿਊਰੋਕਰੈਸੀ ਨਹੀਂ ਸਨ; ਇਹ ਅਨਿਸ਼ਚਿਤਤਾ ਘਟਾਉਣ ਲਈ ਵਾਜਿਬ ਔਜ਼ਾਰ ਸਨ।
ਅਪੋਲੋ ਟੀਮਾਂ ਨੂੰ ਇਹ ਵੀ ਮੰਨਨਾ ਪਿਆ ਕਿ ਤਣਾਅ ਹੇਠ ਮਨੁੱਖ ਸਿਸਟਮ ਨਾਲ ਅਣਉਮੀਦ ਤਰੀਕਿਆਂ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਨਗੇ। ਇਸ ਨੇ ਸੌਫਟਵੇਅਰ ਨੂੰ ਸਪਸ਼ਟ ਬਿਹੈਵੀਅਰ ਅਤੇ ਸੁਰੱਖਿਅਤ ਡੀਫਾਲਟ ਵੱਲ ਧੱਕਿਆ।
ਬਹੁਤ ਸਾਰੇ ਆਧੁਨਿਕ ਉਤਪਾਦ ਇੰਨੇ ਸੇਫਟੀ-ਕ੍ਰਿਟੀਕਲ ਨਹੀਂ ਹਨ, ਅਤੇ ਅਸੀਂ ਅਕਸਰ ਬਾਰ-ਬਾਰ ਅਪਡੇਟ ਡਿਪਲੌਏ ਕਰ ਸਕਦੇ ਹਾਂ। ਇਹ ਇੱਕ ਵੱਡਾ ਫਾਇਦਾ ਹੈ।
ਪਰ ਸਬਕ ਇਹ ਨਹੀਂ ਕਿ "ਹਰ ਐਪ ਨੂੰ ਅਪੋਲੋ ਸਮਝੋ।" ਸਬਕ ਇਹ ਹੈ ਕਿ ਪ੍ਰੋਡਕਸ਼ਨ ਨੂੰ ਉਹ ਵਾਤਾਵਰਣ ਮਾਨੋ ਜੋ ਗਣਨਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਆਪਣੇ ਅਨੁਸ਼ਾਸ਼ਨ ਨੂੰ ਆਪਣੇ ਰਿਸਕ ਦੇ ਅਨੁਸਾਰ ਮਿਲਾਓ। ਭੁਗਤਾਨ, ਹੈਲਥਕੇਅਰ, ਟਰਾਂਸਪੋਰਟੇਸ਼ਨ, ਜਾਂ ਢਾਂਚਾ ਵਾਲੀਆਂ ਸਰਵਿਸਜ਼ ਲਈ, ਅਪੋਲੋ-ਜਿਹੀ ਸਖ਼ਤੀ ਅਜੇ ਵੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ। ਘੱਟ-ਰਿਸਕ ਫੀਚਰਾਂ ਲਈ, ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧ ਸਕਦੇ ਹੋ ਪਰ ਉਹੀ ਮਨੋਭਾਵ ਰੱਖੋ: ਫੇਲ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਬਦਲਾਅ ਨਿਯੰਤਰਿਤ ਕਰੋ, ਅਤੇ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤਿਆਰੀ ਦਿਖਾਓ।
ਟੈਸਟਿੰਗ ਜ਼ਰੂਰੀ ਹੈ, ਪਰ ਇਹ ਅਖੀਰਲਾ ਨਿਸ਼ਾਨਾ ਨਹੀਂ ਹੈ। ਅਪੋਲੋ ਦਾ ਕੰਮ ਸanu ਯਾਦ ਦਲਵਾਂਦਾ ਹੈ ਕਿ ਅਸਲ ਮਕਸਦ ਹੈ ਪ੍ਰੋਡਕਸ਼ਨ ਰੈਡੀਨੈੱਸ: ਉਹ ਪਲ ਜਦੋਂ ਸੌਫਟਵੇਅਰ ਅਸਲ ਹਾਲਤਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰ ਸਕੇ—ਖਰਾਬ ਇਨਪੁੱਟ, ਅੰਸ਼ਿਕ ਠਹਿਰਾਵ, ਮਨੁੱਖੀ ਗਲਤੀਆਂ—ਅਤੇ ਫਿਰ ਵੀ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰੇ।
ਇੱਕ ਸਿਸਟਮ ਪ੍ਰੋਡਕਸ਼ਨ ਰੀਡੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਸਾਦੀ ਭਾਸ਼ਾ ਵਿੱਚ ਸਮਝਾ ਸਕਦੇ ਹੋ:
ਅਪੋਲੋ-ਯੁੱਗ ਦੀ ਅਨੁਸ਼ਾਸ਼ਨ ਪੇਸ਼ਗੀਯੋਗਤਾ ਲਈ ਸੀ: ਬਦਲਾਅ ਅਜਿਹੇ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ ਜੋ ਸਭ ਤੋਂ ਨੁਕਸਾਨਦਾਇਕ ਸਮੇਂ ਤੇ ਅਣਜਾਣ ਵਿਹਾਰ ਲੈ ਕੇ ਆਉਣ। "ਨੋ ਸਰਪ੍ਰਾਈਜ਼" ਰਿਲੀਜ਼ ਉਹ ਹੁੰਦੀ ਹੈ ਜਿੱਥੇ ਟੀਮ ਇਹ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਜਵਾਬ ਦੇ ਸਕਦੀ: ਕੀ ਬਦਲਿਆ? ਇਹ ਕਿਸ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰ ਸਕਦਾ ਹੈ? ਅਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਕਿਵੇਂ ਪਤਾ ਲਗਾਵਾਂਗੇ ਕਿ ਕੁਝ ਗਲਤ ਹੋ ਰਿਹਾ ਹੈ? ਜੇ ਇਹ ਜਵਾਬ ਅਸਪਸ਼ਟ ਹਨ, ਤਾਂ ਰਿਲੀਜ਼ ਤਿਆਰ ਨਹੀਂ ਹੈ।
ਮਜ਼ਬੂਤ ਟੈਸਟ ਸਿਟ ਵੀ ਵਾਸਤਵਿਕ ਗੈਪਾਂ ਨੂੰ ਛੁਪਾ ਸਕਦੇ ਹਨ:
ਪ੍ਰੋਡਕਸ਼ਨ ਰੈਡੀਨੈੱਸ ਟੈਸਟਿੰਗ ਨਾਲ਼ ਸਪਸ਼ਟਤਾ ਹੈ: ਸਪਸ਼ਟ ਲੋੜਾਂ, ਵਿਖਾਈ ਦੇਣ ਵਾਲਾ ਜੋਖਮ, ਅਤੇ ਸੁਰੱਖਿਆ ਵੱਲ ਵਾਪਸੀ ਲਈ ਅਭਿਆਸ ਕੀਤਾ ਰਸਤਾ।
"ਲੋੜਾਂ" ਤਕਨੀਕੀ ਲੱਗ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਖ਼ਿਆਲ ਸਧਾਰਨ ਹੈ: ਸਿਸਟਮ ਨੂੰ ਸਹੀ ਮੰਨਣ ਲਈ ਕੀ ਸੱਚ ਹੋਣਾ ਚਾਹੀਦਾ।
ਇੱਕ ਚੰਗੀ ਲੋੜ ਇਹ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਕਿਵੇਂ ਬਣਾਉਣਾ ਹੈ। ਇਹ ਇੱਕ ਦੇਖਣਯੋਗ ਨਤੀਜਾ ਦਸਦੀ ਹੈ—ਕੋਈ ਵਿਅਕਤੀ ਇਸਨੂੰ ਵੈਰੀਫਾਈ ਕਰ ਸਕੇ। ਅਪੋਲੋ ਦੇ ਪਾਬੰਧਾਂ ਨੇ ਇਹ ਸੋਚ ਮਜ਼ਬੂਤ ਕੀਤੀ ਕਿਉਂਕਿ ਤੁਸੀਂ ਉਡਾਣ ਵਿਚ ਵਾਹਨ ਨਾਲ ਬਹਿਸ ਨਹੀਂ ਕਰ ਸਕਦੇ: ਜਾਂ ਸਿਸਟਮ ਨਿਰਧਾਰਿਤ ਹਾਲਤਾਂ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ, ਜਾਂ ਨਹੀਂ।
ਅਸਪਸ਼ਟ ਲੋੜਾਂ ਖਤਰੇ ਨੂੰ ਸਧੇ ਤੌਰ 'ਤੇ ਛੁਪਾਉਂਦੀਆਂ ਹਨ। ਜੇ ਲੋੜ ਕਹਿੰਦੀ "ਐਪ ਨੂੰ ਤੇਜ਼ ਲੋਡ ਹੋਣਾ ਚਾਹੀਦਾ" ਤਾਂ "ਤੇਜ਼" ਦਾ ਕੀ ਮਤਲਬ—1 ਸਕਿੰਟ, 5 ਸਕਿੰਟ, ਧੀਮੀ Wi‑Fi 'ਤੇ, ਪੁਰਾਣੇ ਫੋਨ 'ਤੇ? ਟੀਮਾਂ ਅਣਜਾਣੇ ਤੌਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਭਾਵ ਭੇਜ ਦਿੰਦੀਆਂ ਹਨ, ਅਤੇ ਗੈਪ ਫੇਲ ਹੋ ਕੇ ਸਾਹਮਣੇ ਆ ਜਾਂਦੇ ਹਨ:
ਅਸਪਸ਼ਟਤਾ ਟੈਸਟਿੰਗ ਨੂੰ ਵੀ ਤੋੜ ਦਿੰਦੀ ਹੈ। ਜੇ ਕੋਈ ਨਹੀਂ ਕਹਿ ਸਕਦਾ ਕਿ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ, ਤਾਂ ਟੈਸਟਜ਼ ਸਿਰਫ ਰਾਏਆਂ ਦਾ ਸੰਗ੍ਰਹਿ ਬਣ ਜਾਂਦੇ ਹਨ।
ਤੁਹਾਨੂੰ ਭਾਰੀ ਦਸਤਾਵੇਜ਼ੀ ਲੋੜ ਨਹੀਂ। ਛੋਟੀਆਂ ਆਦਤਾਂ ਹੀ ਕਾਫ਼ੀ ਹਨ:
ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਬਣਾਉਣ ਜਾਂ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਭਰੋ:
User need:
Success condition (what must be true):
Failure condition (what must never happen, or what we do instead):
Notes / examples / edge cases:
ਜੇ ਤੁਸੀਂ "failure condition" ਭਰ ਨਹੀਂ ਪਾ ਰਹੇ, ਤਾਂ ਸੰਭਵ ਹੈ ਕਿ ਤੁਸੀਂ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ ਗੁਆ ਲਿਆ ਹੈ: ਹੇਪੀ ਪਾਥ ਨਾਲ ਸੱਚ ਨਾਂ ਮਿਲਣ 'ਤੇ ਸਿਸਟਮ ਨੂੰ ਕਿਵੇਂ ਵਿਵਹਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਅਪੋਲੋ-ਯੁੱਗ ਦਾ ਕੰਮ ਚੇਂਜ ਕੰਟਰੋਲ ਨੂੰ ਇਕ ਸੁਰੱਖਿਆ ਖਾਸੀਅਤ ਵਜੋਂ ਦੇਖਦਾ ਸੀ: ਬਦਲਾਅ ਛੋਟੇ ਰੱਖੋ, ਉਹਨਾਂ ਨੂੰ ਸਮੀਖਿਆਯੋਗ ਬਣਾਓ, ਅਤੇ ਉਹਨਾਂ ਦਾ ਪ੍ਰਭਾਵ ਜਾਣਯੋਗ ਬਣਾਓ। ਇਹ ਬਿਊਰੋਕਰੇਸੀ ਨਹੀਂ—ਇਹ ਇਹੋ ਤਰੀਕਾ ਹੈ ਕਿ "ਛੋਟੇ" ਸੰਪਾਦਨ ਮਿਸ਼ਨ-ਪੱਧਰੀ ਨੁਕਸਾਨ ਵਿਚ ਨਹੀਂ ਬਦਲਣ।
ਆਖਰੀ-ਮਿੰਟ ਬਦਲਾਅ ਖਤਰਨਾਕ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਵੱਡੇ (ਜਾਂ ਠੀਕ ਤਰ੍ਹਾਂ ਸਮਝੇ ਨਹੀਂ ਗਏ), ਜਲਦੀ ਰਿਵਿਊ ਕੀਤੇ ਜਾਂਦੇ, ਅਤੇ ਉਹ ਸਮਾਂ ਆਉਂਦੇ ਹਨ ਜਦੋਂ ਟੀਮ ਕੋਲ ਟੈਸਟ ਕਰਨ ਲਈ ਘੱਟ ਸਮਾਂ ਹੁੰਦਾ। ਤਰੱਕੀ ਨੂੰ ਪ੍ਰਬੰਧਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜੇ ਤੁਸੀਂ ਬਲਾਸਟ ਰੇਡੀਅਸ ਘਟਾ ਦਿਓ:
ਭਰੋਸੇਯੋਗ ਟੀਮਾਂ ਕਿਸੇ ਵੀ ਸਮੇਂ ਇਹ ਤਿੰਨ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇ ਸਕਦੀਆਂ ਹਨ: ਕੀ ਬਦਲਿਆ, ਕਿਉਂ ਬਦਲਿਆ, ਅਤੇ ਕਿਸਨੇ ਮਨਜ਼ੂਰ ਕੀਤਾ।
ਵਰਜਨਿੰਗ "ਕਿਆ" ਦਿੰਦੀ ਹੈ (ਰਿਲੀਜ਼ ਵਿੱਚ ਠੀਕ ਕੋਡ ਅਤੇ ਕਨਫਿਗਰੇਸ਼ਨ)। ਪੀਅਰ ਰਿਵਿਊ "ਕੀ ਇਹ ਸੁਰੱਖਿਅਤ ਹੈ?" ਦਾ ਦੂਜਾ ਨਜ਼ਰੀਆ ਦਿੰਦਾ ਹੈ। ਟਰੇਸੇਬਲ ਫੈਸਲੇ—ਚੇਂਜ ਨੂੰ ਟਿਕਟ, ਇੰਸੀਡੈਂਟ, ਜਾਂ ਲੋੜ ਨਾਲ ਲਿੰਕ ਕਰਨਾ—"ਕਿਉਂ" ਦਿਖਾਉਂਦੇ ਹਨ, ਜੋ ਬਾਅਦ ਵਿੱਚ ਰਿਗ੍ਰੈਸ਼ਨ ਜਾਂਚਣ ਵੇਲੇ ਜਰੂਰੀ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਨ ਨੀਅਮ ਮਦਦ ਕਰਦਾ: ਹਰ ਬਦਲਾਅ ਵਾਪਸ ਕਰਨਯੋਗ ਹੋਵੇ (ਰੋਲਬੈਕ, ਰੀਵਰਟ, ਜਾਂ ਫੀਚਰ ਫਲੈਗ ਰਾਹੀਂ) ਅਤੇ ਇਸ ਨੂੰ ਇੱਕ ਛੋਟੇ ਫੈਸਲਾ ਨੋਟ ਨਾਲ ਸਮਝਾਇਆ ਜਾਵੇ।
ਇੱਕ ਹਲਕਾ-ਫੁਲਕੀ branching ਰਣਨੀਤੀ ਬਿਨਾਂ ਨਟਕਾਂ ਦੇ ਅਨੁਸ਼ਾਸ਼ਨ ਲਾਗੂ ਕਰ ਸਕਦੀ:
ਉੱਚ-ਖਤਰੇ ਵਾਲੇ ਖੇਤਰਾਂ (ਭੁਗਤਾਨ, auth, ਡੇਟਾ ਮਾਈਗ੍ਰੇਸ਼ਨ, ਸੇਫਟੀ-ਕ੍ਰਿਟੀਕਲ ਲੋਜਿਕ) ਲਈ, ਵਾਧੂ ਮਨਜ਼ੂਰੀਆਂ ਸ਼ਾਮਿਲ ਕਰੋ:
ਮਕਸਦ ਸਧਾਰਨ ਹੈ: ਸੁਰੱਖਿਅਤ ਰਸਤਾ ਸਭ ਤੋਂ ਆਸਾਨ ਬਣੋ—ਤਾਂ ਜੋ ਭਰੋਸੇਯੋਗਤਾ ਤਕਨੀਕੀ ਨਹੀਂ, ਕਿਸੇ ਖ਼ਬਰਤੱਵ ਦੀ ਨਹੀਂ, ਪਰ ਡਿਫੌਲਟ ਹੋ ਕੇ ਹੋਵੇ।
ਅਪੋਲੋ ਟੀਮਾਂ "ਟੈਸਟਿੰਗ" ਨੂੰ ਆਖਰੀ ਵੱਡੇ ਇਵੈਂਟ ਵਜੋਂ ਨਹੀਂ ਲੈਂਦੀਆਂ। ਉਹ ਬਹੁਤ ਸਾਰੇ ਤਬਲੀਗੀ ਚੈੱਕਾਂ 'ਤੇ ਨਿਰਭਰ ਰਹੇ—ਹਰ ਇੱਕ ਵੱਖ-ਵੱਖ ਕਿਸਮ ਦੀ ਫੇਲ ਨੂੰ ਫੜਨ ਲਈ ਬਣਾਇਆ ਗਿਆ—ਕਿਉਂਕਿ ਹਰ ਪਰਤ ਵੱਖ-ਵੱਖ ਅਨਿਸ਼ਚਿਤਤਾ ਘਟਾਉਂਦੀ ਹੈ।
ਟੈਸਟਾਂ ਨੂੰ ਇੱਕ ਸਟੈਕ ਵਜੋਂ ਸੋਚੋ:
ਕੋਈ ਇਕ ਪਰਤ "ਸੱਚ" ਨਹੀਂ ਹੈ। ਇਕੱਠੇ ਹੋ ਕੇ, ਉਹ ਇੱਕ ਸੁਰੱਖਿਆ ਜਾਲ ਬਣਾਉਂਦੇ ਹਨ।
ਹਰ ਫੀਚਰ ਇੱਕੋ ਜਿਹੀ ਟੈਸਟਿੰਗ ਲਈ ਯੋਗ ਨਹੀਂ। ਰਿਸਕ-ਅਧਾਰਤ ਟੈਸਟਿੰਗ ਵਰਤੋ:
ਇਹ ਦ੍ਰਿਸ਼ਟੀ ਟੈਸਟਿੰਗ ਨੂੰ ਦਰਸਕਾਰੀ ਨਹੀਂ, ਹਕੀਕਤੀ ਬਣਾਉਂਦੀ ਹੈ।
ਟੈਸਟ ਉਤਨਾ ਹੀ ਚੰਗਾ ਹੈ ਜਿੰਨਾ ਕਿ ਉਹ ਕੀ ਸਿਮੂਲੇਟ ਕਰਦੇ ਹਨ। ਉਤਪਾਦਨ ਦੇ ਸਮਾਨ ਵਾਤਾਵਰਣ ਲਈ ਕੋਸ਼ਿਸ਼ ਕਰੋ (ਓਹੀ configs, ਮਿਲਦਾ ਜੁਲਦਾ scale, ਉਹੀ ਡਿਪੈਂਡੈਂਸੀ), ਪਰ ਸੈਨਿਟਾਈਜ਼ਡ ਜਾਂ ਸਿੰਥੇਟਿਕ ਡੇਟਾ ਵਰਤੋ। ਨਿੱਜੀ ਜਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਫੀਲਡ ਬਦਲੋ, ਪ੍ਰਤੀਨਿਧੀ ਡੇਟਾਸੈੱਟ ਬਣਾਓ, ਅਤੇ ਪਹੁੰਚ ਨੂੰ ਕਸਕੇ ਨਿਯੰਤਰਿਤ ਕਰੋ।
ਚੰਗੀ ਕਵਰੇਜ ਵੀ ਸੌਫਟਵੇਅਰ ਨੂੰ ਬੇਦੋਸ਼ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਪਰ ਇਹ ਕਰ ਸਕਦੀ ਹੈ:
ਇਹ ਮਨੋਭਾਵ ਟੀਮਾਂ ਨੂੰ ਇਮਾਨਦਾਰ ਰੱਖਦਾ: ਲਕੜੀ-ਨਿਸ਼ਾਨਾ ਘੱਟ ਸਰਪ੍ਰਾਈਜ਼, ਨਾ ਕਿ ਪੂਰਨ ਸਕੋਰਕਾਰਡ।
ਅਪੋਲੋ ਸੌਫਟਵੇਅਰ perfect ਹਾਲਤਾਂ ਮਨ ਕੇ ਨਹੀਂ ਚਲ ਸਕਦੇ: ਸੈਂਸਰ ਗਲਤੀਆਂ ਕਰਦੇ ਹਨ, ਸਵਿੱਚ ਬਾਊਂਸ ਕਰਦੇ ਹਨ, ਅਤੇ ਤਣਾਅ ਹੇਠ ਮਨੁੱਖ ਗਲਤੀਆਂ ਕਰਦੇ ਹਨ। Hamilton ਦੀ ਟੀਮਾਂ ਇੱਕ ਐਸਾ ਮਨੋਭਾਵ ਅਪਣਾਉਂਦੀਆਂ ਸਨ ਜੋ ਅੱਜ ਵੀ ਫ਼ਾਇਦੇਮੰਦ ਹੈ: ਸਿਸਟਮ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਇਨ ਕਰੋ ਜਿਵੇਂ ਕਿ ਇਹ ਹੈਰਾਨ ਕੀਤਾ ਜਾਵੇਗਾ—ਕਿਉਂਕਿ ਇਹ ਹੋਵੇਗਾ।
ਰੱਖਿਆਮੁਖੀ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਦਾ ਮਤਲਬ ਹੈ ਅਜਿਹਾ ਸੌਫਟਵੇਅਰ ਲਿਖਣਾ ਜੋ ਖਰਾਬ ਇਨਪੁੱਟ ਅਤੇ ਅਣਉਮੀਦ ਹਾਲਤਾਂ ਨੂੰ ਸਹਿਣਯੋਗ ਤਰੀਕੇ ਨਾਲ ਹਲ ਕਰੇ। ਹਰ-mੂੱਲ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਇਸ ਦੀ ਜਾਂਚ ਕਰੋ, ਇਸਨੂੰ ਸੁਰੱਖਿਅਤ ਸੀਮਾ ਵਿੱਚ ਰੱਖੋ, ਅਤੇ "ਇਹ ਕਦੇ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ" ਨੂੰ ਇੱਕ ਅਸਲ ਸਥਿਤੀ ਮੰਨੋ।
ਉਦਾਹਰਣ ਵਜੋਂ: ਜੇ ਐਪ ਨੂੰ ਖਾਲੀ ਪਤਾ ਮਿਲਦਾ ਹੈ, ਤਾਂ ਰੱਖਿਆਮੁਖੀ ਚੋਣ ਇਹ ਹੈ ਕਿ ਇਸਨੂੰ ਸਪਸ਼ਟ ਸੁਨੇਹੇ ਨਾਲ ਰਿਜੈਕਟ ਕਰੋ ਅਤੇ ਘਟਨਾ ਲੌਗ ਕਰੋ—ਨਾਹ ਕਿ ਖਾਮੋਸ਼ੀ ਨਾਲ ਗਲਤ ਡੇਟਾ ਸੇਵ ਕਰ ਦਿਓ ਜੋ ਬਾਅਦ ਵਿੱਚ ਬਿੱਲਿੰਗ ਨੂੰ ਤੋੜ ਦੇਵੇ।
ਜਦੋਂ ਕੁਝ ਗਲਤ ਹੁੰਦਾ, ਅੰਗ-ਭਾਅਗ ਸੇਵਾ ਆਮ ਤੌਰ 'ਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੰਦ ਹੋਣ ਨਾਲੋਂ ਵਧੀਆ ਹੁੰਦੀ ਹੈ। ਇਹ graceful degradation ਹੈ: ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਫੰਕਸ਼ਨ ਨੂੰ ਚਾਲੂ ਰੱਖੋ ਅਤੇ ਗੈਰ-ਲਾਜ਼ਮੀ ਫੀਚਰ ਨੂੰ ਸੀਮਿਤ ਜਾਂ ਬੰਦ ਕਰੋ।
ਜੇ ਤੁਹਾਡਾ ਸੁਝਾਅ ਇੰਜ਼ਿਨ ਫੇਲ ਕਰ ਜਾਦਾ, ਤਾਂ ਯੂਜ਼ਰ ਫਿਰ ਵੀ ਖੋਜ ਅਤੇ ਚੈੱਕਆਉਟ ਕਰ ਸਕਣ। ਜੇ ਪੇਮੈਂਟ ਪ੍ਰਦਾਤਾ ਹੌਲੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਨਵੇਂ ਭੁਗਤਾਨ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਰੋਕ ਸਕਦੇ ਹੋ ਪਰ ਗਾਹਕਾਂ ਨੂੰ ਬ੍ਰਾਊਜ਼ ਅਤੇ ਕਾਰਟ ਸੇਵ ਕਰਨ ਦਿਓ।
ਬਹੁਤ ਸਾਰੀਆਂ ਪ੍ਰੋਡਕਸ਼ਨ ਫੇਲ ਬੱਗਸ ਨਹੀਂ, ਬਲਕਿ ਸਿਸਟਮ ਬੇਇੰਤਜ਼ਾਰ ਇੰਤਜ਼ਾਰ ਕਰਨ ਜਾਂ ਬੇਤੁਕੀ ਕੋਸ਼ਿਸ਼ਾਂ ਕਰਨ ਕਰਕੇ ਹੁੰਦੀਆਂ ਹਨ।
ਜਦੋਂ ਤੁਸੀਂ ਅਣਜਾਣ ਹੋ, ਤੁਹਾਡੇ ਡੀਫਾਲਟ ਸੁਰੱਖਿਅਤ ਹੋਣੇ ਚਾਹੀਦੇ। "Fail-closed" ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਜੇ ਕੋਈ ਲਾਜ਼ਮੀ ਜਾਂਚ ਪੂਰੀ ਨਹੀਂ ਹੋ ਸਕਦੀ ਤਾਂ ਐਕਸ਼ਨ ਨੂੰ ਰੱਦ ਕਰ ਦਿਓ (ਸੁਰੱਖਿਆ ਅਤੇ ਭੁਗਤਾਨਾਂ ਲਈ ਆਮ)। "Fail-open" ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸੇਵਾ ਉਪਲੱਬਧ ਰਹੇ (ਕਈ ਗੈਰ-ਮਹੱਤਵਪੂਰਨ ਫੀਚਰਾਂ ਲਈ ਕਬੂਲਯੋਗ)।
ਅਪੋਲੋ ਸਬਕ ਇਹ ਹੈ ਕਿ ਇਹ ਵਰਤਾਰਾ ਪਹਿਲਾਂ ਹੀ ਨਿਰਧਾਰਤ ਕਰੋ—ਨਹੀਂ ਤਾਂ ਸੰਗਰਾਮ ਨੇ ਤੁਹਾਡੇ ਲਈ ਫੈਸਲਾ ਕਰ ਦੇਵੇਗਾ।
ਛੱਡਣਾ ਅਖੀਰਲਾ ਟੈਸਟ ਨਹੀਂ ਹੈ। ਰਿਲਾਇਬਿਲਟੀ ਰਿਲੀਜ਼ ਤੋਂ ਬਾਅਦ ਇਸ ਗੱਲ ਦਾ ਨਿਰੰਤਰ ਉੱਤਰ ਹੈ: ਕੀ ਯੂਜ਼ਰ ਅਜੇ ਵੀ ਸਫਲ ਹੋ ਰਹੇ ਹਨ? ਮਾਨੀਟਰਿੰਗ ਇਹ ਜਾਣਨ ਦਾ ਤਰੀਕਾ ਹੈ—ਅਸਲ ਪ੍ਰੋਡਕਸ਼ਨ ਤੋਂ ਸਿਗਨਲ ਵਰਤ ਕੇ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਕਿ ਸੌਫਟਵੇਅਰ ਅਸਲ ਟ੍ਰੈਫਿਕ, ਅਸਲ ਡੇਟਾ, ਅਤੇ ਅਸਲ ਗਲਤੀਆਂ ਹੇਠ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ।
Logs ਸੌਫਟਵੇਅਰ ਦੀ ਡਾਇਰੀ ਦੀ ਤਰ੍ਹਾਂ ਹਨ। ਉਹ ਦੱਸਦੇ ਹਨ ਕਿ ਕੀ ਹੋਇਆ ਅਤੇ ਕਿਉਂ (ਉਦਾਹਰਣ: "payment declined" ਅਤੇ ਰੀਜ਼ਨ ਕੋਡ)। ਚੰਗੇ ਲੌਗ ਨਾਂ-ਮਿੱਤ ਜਾਣ-ਪਛਾਣ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
Metrics ਸਕੋਰਕਾਰਡ ਹਨ। ਉਹ ਵਰਤਾਰਾ ਨੰਬਰਾਂ ਵਿੱਚ ਬਦਲਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਸਮੇਂ ਦੇ ਨਾਲ ਟਰੈਕ ਕਰ ਸਕਦੇ ਹੋ: error rate, response time, queue depth, sign-in success rate।
Dashboards ਕਾਕਪਿਟ ਹਨ। ਉਹ ਮੁੱਖ ਮੈਟਰਿਕ ਇਕ ਥਾਂ 'ਤੇ ਦਿਖਾਉਂਦੇ ਹਨ ਤਾਂ ਕਿ ਕੋਈ ਮਨੁੱਖ ਤੇਜ਼ੀ ਨਾਲ ਰੁਝਾਨ ਦੇਖ ਸਕੇ: "ਚੀਜ਼ਾਂ ਹੌਲੀ ਹੋ ਰਹੀਆਂ ਨੇ" ਜਾਂ "ਰਿਲੀਜ਼ ਤੋਂ ਬਾਅਦ errors spike ਹੋਏ।"
Alerts smoke alarm ਹਨ। ਉਹਨਾਂ ਨੂੰ ਸਿਰਫ ਐਸੇ ਸਮੇਂ ਜਗਾਉਣਾ ਚਾਹੀਦਾ ਜਦੋਂ ਅਸਲ ਜ਼ਰੂਰਤ ਹੋਵੇ—ਜਾਂ ਉੱਚ ਖਤਰੇ ਦਾ ਸੰਕੇਤ ਹੋਵੇ।
ਸ਼ੋਰ ਵਾਲੇ ਅਲਰਟ ਟੀਮਾਂ ਨੂੰ ਉਨਾਂ ਨੂੰ ਅਣਡਿੱਠਾ ਕਰਨਾ ਸਿੱਖਾਉਂਦੇ ਹਨ। ਇੱਕ ਚੰਗਾ ਅਲਰਟ:
ਜ਼ਿਆਦਾਤਰ ਉਤਪਾਦਾਂ ਲਈ, ਸ਼ੁਰੂ ਕਰੋ:
ਇਹ ਸਿਗਨਲ ਨਤੀਜਿਆਂ 'ਤੇ ਧਿਆਨ ਰੱਖਦੇ ਹਨ—ਬਿਲਕੁਲ ਓਹੀ ਜੋ ਭਰੋਸੇਯੋਗਤਾ ਬਾਰੇ ਹੈ।
ਭਰੋਸੇਯੋਗਤਾ ਸਿਰਫ ਟੈਸਟਾਂ ਨਾਲ ਨਹੀਂ ਦਰਸਾਈ ਜਾਂਦੀ; ਇਹ ਇਸ ਨਾਲ ਦਰਸਾਈ ਜਾਂਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਕਰਦੇ ਹੋ ਜਦੋਂ ਹਕੀਕਤ ਤੁਹਾਡੇ ਅਨੁਮਾਨਾਂ ਨਾਲ ਨਹੀਂ ਮਿਲਦੀ। ਅਪੋਲੋ-ਯੁੱਗ ਦੀ ਅਨੁਸ਼ਾਸ਼ਨ Anomalies ਨੂੰ ਉਮੀਦ ਵਾਲੇ ਘਟਨਾ ਵਜੋਂ ਦੇਖਦੀ ਸੀ ਜੋ ਠੰਡੇ ਦਿਮਾਗ ਅਤੇ ਲਗਾਤਾਰ ਤੱਤਾਂ ਨਾਲ ਸੰਭਾਲੇ ਜਾਣ। ਆਧੁਨਿਕ ਟੀਮਾਂ ਵੀ ਇਹੀ ਮਨੋਭਾਵ ਅਪਣਾ ਸਕਦੀਆਂ ਹਨ: ਇੰਸੀਡੈਂਟ ਰਿਸਪਾਂਸ ਨੂੰ ਇੱਕ ਪਹਿਲੀ ਦਰਜੇ ਦੀ ਇੰਜੀਨੀਅਰਿੰਗ ਪ੍ਰੈਕਟਿਸ ਬਣਾਉ—ਨਕਲੀ ਦੌੜ ਜਾਂ ਜਲਦੀ ਭੱਜਣ ਵਾਲੀ ਗੜਬੜ ਨਹੀਂ।
ਇੰਸੀਡੈਂਟ ਰਿਸਪਾਂਸ ਉਹ ਪਰਿਭਾਸ਼ਿਤ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਸਮੱਸਿਆ ਪਛਾਣਦੇ ਹੋ, ਮਾਲਕੀ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹੋ, ਪ੍ਰਭਾਵ ਸੀਮਿਤ ਕਰਦੇ ਹੋ, ਸੇਵਾ ਬਹਾਲ ਕਰਦੇ ਹੋ, ਅਤੇ ਨਤੀਜੇ ਤੋਂ ਸਿੱਖਦੇ ਹੋ। ਇਹ ਇੱਕ ਸਧਾਰਨ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ: ਜਦੋਂ ਚੀਜ਼ਾਂ ਟੁੱਟਦੀਆਂ ਹਨ ਤਾਂ ਕੌਣ ਕੀ ਕਰਦਾ?
ਯੋਜਨਾ ਤਦ ਹੀ ਕੰਮ ਕਰੇਗੀ ਜਦ ਇਹ ਤਣਾਅ ਹੇਠ ਵਰਤਣਯੋਗ ਹੋਵੇ। ਮੁਢਲੀਆਂ ਚੀਜ਼ਾਂ ਨਿਰਸ ਪਰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹਨ:
ਇੱਕ blameless postmortem ਨਿਜੀ ਦੋਸ਼ 'ਤੇ ਨਾ ਗਿਆਨ ਰੱਖਦੀ ਹੈ। ਮਕਸਦ ਹੈ ਯੋਗਦਾਨੀ ਕਾਰਕ (ਗਾਇਬ ਅਲਰਟ, ਅਸਪਸ਼ਟ ਮਾਲਕੀ, ਖਤਰਨਾਕ ਡੀਫਾਲਟ, ਗੁੰਝਲਦਾਰ ਡੈਸ਼ਬੋਰਡ) ਪਛਾਣ ਕੇ ਉਹਨਾਂ ਨੂੰ ਠੋਸ ਸੁਧਾਰਾਂ ਵਜੋਂ ਬਦਲਣਾ: ਚੰਗੇ ਚੈੱਕ, ਸੁਰੱਖਿਅਤ ਰੋਲਆਊਟ, ਸਪੱਸ਼ਟ ਰਨਬੁਕਸ, ਜਾਂ ਕਠੋਰ ਚੇਂਜ ਕੰਟਰੋਲ।
ਅਪੋਲੋ ਸੌਫਟਵੇਅਰ "ਬਾਅਦ ਵਿੱਚ ਪੈਚ ਕਰਾਂਗੇ" 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਆਧੁਨਿਕ ਅਨੁਵਾਦ ਇਹ ਨਹੀਂ ਕਿ "ਧੀਰੇ ਸ਼ਿਪ ਕਰੋ"—ਪਰ ਇਹ ਹੈ ਕਿ "ਜਾਣੂ-ਬੁਝ ਕੇ ਸੁਰੱਖਿਆ ਮਾਰਜਿਨ ਨਾਲ ਸ਼ਿਪ ਕਰੋ." ਇੱਕ ਰਿਲੀਜ਼ ਚੈੱਕਲਿਸਟ ਹੀ ਉਹ ਮਾਰਜਿਨ ਵਿਖਾਉਂਦੀ ਅਤੇ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਬਣਾਉਂਦੀ।
ਹਰੇਕ ਬਦਲਾਅ ਨੂੰ ਉਨ੍ਹਾਂ ਹੀ ਤੇਜ਼ੀ ਦਾ ਸਮਾਰੋਹ ਦੀ ਲੋੜ ਨਹੀਂ। ਚੈੱਕਲਿਸਟ ਨੂੰ ਇੱਕ ਕੰਟਰੋਲ ਪੈਨਲ ਵਜੋਂ ਸੋਚੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਡਾਇਲ ਕਰ ਸਕਦੇ ਹੋ:
ਚੰਗੀ ਚੈੱਕਲਿਸਟ ਉਹ ਸਵਾਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਜੋ ਲੋਕ ਜਵਾਬ ਦੇ ਸਕਣ:
ਉਹ ਮਿਕੈਨਿਜ਼ਮ ਵਰਤੋ ਜੋ ਬਲਾਸਟ ਰੇਡੀਅਸ ਸੀਮਿਤ ਕਰਦੇ ਹਨ:
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਵਿਚਾਰ ਦਿਨ-ਪਰ-ਦਿਨ ਟੀਮਾਂ ਦੇ ਕੰਮ ਨਾਲ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਮਿਲਦੇ ਹਨ: ਬਦਲਾਅ ਨੂੰ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਯੋਜਨਾ ਬਣਾਓ (Planning Mode), ਛੋਟੇ ਇੰਕਰੀਮੈਂਟ ਵਿਚ ਸ਼ਿਪ ਕਰੋ, ਅਤੇ snapshots ਅਤੇ rollback ਰਾਹੀਂ ਤੇਜ਼ ਬਚਾਉ ਰੱਖੋ। ਟੂਲ ਅਨੁਸ਼ਾਸ਼ਨ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ—ਪਰ ਇਹ "ਵਾਪਸ ਕਰਨਯੋਗ ਅਤੇ ਸਮਝਣਯੋਗ ਬਦਲਾਅ" ਨੂੰ ਲਗਾਤਾਰ ਅਭਿਆਸ ਕਰਨ ਨੂੰ ਆਸਾਨ ਬਣਾ ਸਕਦਾ ਹੈ।
ਕਾਰਵਾਈ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲਾ ਨਿਯਮ ਲਿਖੋ:
ਮਾਲਕੀ ਸਪਸ਼ਟ ਕਰੋ: ਕੌਣ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ, ਕੌਣ ਰੋਲਆਊਟ ਦੌਰਾਨ ਜ਼ਿੰਮੇਵਾਰ ਹੈ, ਅਤੇ ਕੌਣ ਰੋਲਬੈਕ ਨੂੰ ਬਿਨਾਂ ਝਗੜੇ ਟ੍ਰਿਗਰ ਕਰ ਸਕਦਾ ਹੈ।
ਅਪੋਲੋ-ਯੁੱਗ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਕਿਸੇ ਇਕ ਜਾਦੂਈ ਟੂਲ ਦਾ ਨਤੀਜਾ ਨਹੀਂ ਸੀ। ਇਹ ਇਕ ਸਾਂਝੀ ਆਦਤ ਸੀ: ਇੱਕ ਟੀਮ ਨੇ ਇਹ ਮੰਨਿਆ ਕਿ "ਚੰਗਾ-ਕਾਫੀ" ਕੋਈ ਭਾਵਨਾ ਨਹੀਂ—ਇਹ ਕੁਝ ਐਸਾ ਹੈ ਜੋ ਤੁਸੀਂ ਸਮਝਾ, ਚੈੱਕ, ਅਤੇ ਦੁਹਰਾਉ ਸਕੋ। Hamilton ਦੀਆਂ ਟੀਮਾਂ ਨੇ ਸੌਫਟਵੇਅਰ ਨੂੰ ਇੱਕ ਸਾਂਚਲਨਿਕ ਜ਼ਿੰਮੇਵਾਰੀ ਵਜੋਂ ਦੇਖਿਆ, ਸਿਰਫ਼ ਕੋਡ ਦਾ ਕੰਮ ਨਹੀਂ, ਅਤੇ ਇਹ ਮਨੋਭਾਵ ਆਧੁਨਿਕ ਭਰੋਸੇਯੋਗਤਾ ਨਾਲ ਸਾਫ਼ ਮੇਲ ਖਾਂਦਾ ਹੈ।
ਇੱਕ ਟੈਸਟ ਸੂਟ ਅਸਪਸ਼ਟ ਉਮੀਦਾਂ, ਤੁਰੰਤ ਹੱਥ-ਬਦਲ, ਜਾਂ ਸੁਨੇਹਰੇ ਧਾਰਣਾਂ ਦੀ ਮਕਸੂਲਤਾ ਨਹੀਂ ਭਰ ਸਕਦਾ। ਗੁਣਵੱਤਾ ਉਸ ਵੇਲੇ ਦੁਹਰਾਏ ਯੋਗ ਬਣਦੀ ਹੈ ਜਦੋਂ ਹਰ ਕੋਈ ਭਾਗ ਲੈਂਦਾ: ਪ੍ਰੋਡਕਟ ਦੱਸਦਾ ਕਿ "ਸੇਫ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ, ਇੰਜੀਨੀਅਰਿੰਗ ਰੇਲਗੇਟ ਬਣਾਉਂਦੀ, ਅਤੇ ਜੋ ਭਾਗ ਓਪਰੇਸ਼ਨਲ ਜ਼ਿੰਮੇਵਾਰੀ ਸੰਭਾਲਦਾ (SRE, ਪਲੇਟਫਾਰਮ, ਜਾਂ ਇੰਜੀਨੀਅਰਿੰਗ on-call) ਹਕੀਕਤੀ ਸਬਕ ਸਿਸਟਮ ਵਿੱਚ ਵਾਪਸ ਕਰਦਾ।
ਉਪਯੋਗੀ ਡੌਕ ਨੰਨੇ ਨਹੀਂ ਹੁੰਦੇ—ਉਹ ਕਾਰਵਾਈਯੋਗ ਹੁੰਦੇ ਹਨ। ਤਿੰਨ ਕਿਸਮਾਂ ਜ਼ਿਆਦਾ ਲਾਭਦਾਇਕ ਹਨ:
ਭਰੋਸੇਯੋਗਤਾ ਤਾਂ ਬਿਹਤਰ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਹਰ ਸਰਵਿਸ ਅਤੇ ਮਹੱਤਵਪੂਰਨ ਵਰਕਫਲੋ ਦਾ ਨਾਂ-ਤਹਕੀਕ ਮਾਲਿਕ ਹੋਵੇ: ਕੋਈ ਜਿਸਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੈ ਹੈਲਥ, ਬਦਲਾਅ, ਅਤੇ follow-through। ਮਾਲਕੀ ਦਾ ਅਰਥ ਇਕੱਲਾ ਕੰਮ ਨਹੀਂ—ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਜਦ ਕੁਝ ਟੁੱਟੇ ਤਾਂ ਕੋਈ ਗੁੰਝਲ ਨਾ ਹੋਵੇ।
ਰੁਟੀਨਾਂ ਹਲਕੀ ਪਰ ਲਗਾਤਾਰ ਰੱਖੋ:
ਇਹ ਆਦਤਾਂ ਗੁਣਵੱਤਾ ਨੂੰ ਇੱਕ ਇਕ-ਵਾਰੀ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਇੱਕ ਦੁਹਰਾਏ ਯੋਗ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ।
ਅਪੋਲੋ-ਯੁੱਗ ਦੀ ਅਨੁਸ਼ਾਸ਼ਨ ਜਾਦੂ ਨਹੀਂ ਸੀ—ਇਹ ਆਦਤਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਸੀ ਜੋ ਫੇਲ ਦੀ ਸੰਭਾਵਨਾ ਘਟਾਉਂਦਾ ਅਤੇ ਬਹਾਲੀ ਨੂੰ ਪੇਸ਼ਗੋਈਯੋਗ ਬਣਾਉਂਦਾ। ਇੱਥੇ ਇੱਕ ਆਧੁਨਿਕ ਚੈੱਕਲਿਸਟ ਹੈ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਨਕਲ ਅਤੇ ਅਡੈਪਟ ਕਰ ਸਕਦੀ ਹੈ।
ਰਿਲੀਜ਼ ਨੂੰ ਰੋਕਣ ਵਾਲੇ ਲਾਲ ਝੰਡੇ: ਅਣਜਾਣ ਰੋਲਬੈਕ ਰਸਤਾ, ਫੇਲ ਜਾਂ flaky tests, ਅਣ-ਰਿਵਿਉ ਕੀਤਾ schema change, ਮੁੱਖ paths ਲਈ ਮਾਨੀਟਰੀੰਗ ਦੀ ਘਾਟ, ਨਵਾਂ high-severity ਸੁਰੱਖਿਆ ਖਤਰਾ, ਜਾਂ "ਅਸੀਂ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਦੇਖਾਂਗੇ" ਦਾ ਮਨੋਭਾਵ।
ਅਪੋਲੋ-ਪ੍ਰੇਰਿਤ ਅਨੁਸ਼ਾਸ਼ਨ ਰੋਜ਼ਾਨਾ ਕੰਮ ਹੈ: ਫੇਲ ਨੂੰ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਪਰਤਦਾਰ ਚੈੱਕ ਬਣਾਓ, ਨਿਯੰਤਰਿਤ ਕਦਮਾਂ ਵਿੱਚ ਸ਼ਿਪ ਕਰੋ, ਅਤੇ ਮਾਨੀਟਰਿੰਗ ਅਤੇ ਜਵਾਬ ਦਿੰਨਾ ਉਤਪਾਦ ਦਾ ਹਿੱਸਾ ਬਣਾਓ—ਬਾਅਦ ਦੀ ਸੋਚ ਨਹੀਂ।
ਉਹ ਇਕ ਅਜਿਹਾ ਠੋਸ ਉਦਾਹਰਣ ਹਨ ਜਿੱਥੇ ਭਰੋਸੇਯੋਗਤਾ ਪਹਿਲਾਂ ਰੱਖ ਕੇ ਇੰਜੀਨੀਅਰਿੰਗ ਕੀਤੀ ਗਈ: ਘੱਟ ਕੰਪਿਊਟਿੰਗ ਰਿਸੋਰਸ, ਮਿਡ-ਫਲਾਈਟ ਪੈਚਿੰਗ ਮੁਸ਼ਕਲ, ਅਤੇ ਗਲਤੀ ਦੇ ਭਾਰੀ ਨਤੀਜੇ। ਓਹਦੇ ਤੋਂ ਲੈਣਯੋਗ ਸਬਕ ਇਹ ਨਹੀਂ ਕਿ ਹਰ ਐਪ ਨੂੰ ਰਾਕੇਟ ਵਾਂਗੋਂ ਸੌਂਪੋ—ਸਗੋਂ ਇਹ ਹੈ ਕਿ ਖਤਰੇ ਦੇ ਅਨੁਸਾਰ ਇੰਜੀਨੀਅਰਿੰਗ ਦੀ ਕਸਰਤ ਤੈਅ ਕਰੋ ਅਤੇ ਅੱਗੇ ਹੀ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਗਲਤੀ ਕਿਸ ਤਰ੍ਹਾਂ ਹੋਵੇਗੀ।
ਭਰੋਸੇਯੋਗਤਾ ਦਾ ਮਤਲਬ ਸਿਰਫ "ਘੱਟ ਬੱਗ" ਨਹੀਂ ਹੈ। ਇਹ ਭਰੋਸਾ ਹੈ ਕਿ ਪ੍ਰਣਾਲੀ ਅਸਲ ਹਾਲਤਾਂ ਵਿੱਚ ਵੀ ਪੇਸ਼ਗੀ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰੇਗੀ: ਖਰਾਬ ਇਨਪੁੱਟ, ਅੰਸ਼ਿਕ ਠਹਿਰਾਵ, ਮਨੁੱਖੀ ਗ਼ਲਤੀਆਂ ਅਤੇ ਲੋਡ ਵਿੱਚ ਹੋਣ ਵਾਲੇ ਧੱਕੇ। ਇਸ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੋਣਾ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਬਹਾਲ ਹੋਣਾ ਵੀ ਸ਼ਾਮਿਲ ਹੈ।
ਇਕ ਪ੍ਰਾਇਕਟਿਕਲ ਟੈਸਟ ਇਹ ਹੈ ਕਿ ਕੀ ਟੀਮ ਸਪੱਸ਼ਟ ਭਾਸ਼ਾ ਵਿੱਚ ਸਮਝਾ ਸਕਦੀ ਹੈ:
ਜੇ ਇਹ ਜਵਾਬ ਧੁੰਦਲੇ ਨੇ, ਤਾਂ "ਟੈਸਟ ਪਾਸ ਹੋ ਗਿਆ" ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ।
ਪਾਸ/ਫੇਲ ਨਤੀਜੇ ਵਾਰੀਆਂ ਤਰੀਕਿਆਂ ਨਾਲ ਲਿਖੋ ਅਤੇ ਫੇਲਿਅਰ ਹਾਲਤਾਂ ਸ਼ਾਮِل ਕਰੋ। ਇੱਕ ਹਲਕਾ ਝੰਪਾ ਟੈਂਪਲੇਟ:
ਇਸ ਨਾਲ ਟੈਸਟਿੰਗ ਅਤੇ ਮਾਨੀਟਰਿੰਗ ਮਾਪ ਜੋਗ ਬਣ ਜਾਂਦੇ ਹਨ ਨਾ ਕਿ ਸੁਝਾਵਾਂ।
ਚੇਂਜ ਕੰਟਰੋਲ ਨੂੰ ਇੱਕ ਸੁਰੱਖਿਆ ਵਿਸ਼ੇਸ਼ਤਾ ਸਮਝੋ:
ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਰਿਲੀਜ਼ ਸਮੇਂ "ਅਣਜਾਣ ਵਿਹਾਰ" ਘਟੇ।
ਅਲੱਗ-ਅਲੱਗ ਤਹਿ ਦੀਆਂ ਟੈਸਟਿੰਗ ਲੇਅਰਾਂ ਵਰਤੋ:
ਜਿੱਥੇ ਨੁਕਸਾਨ ਜ਼ਿਆਦਾ ਮਹਿੰਗਾ ਹੋਵੇ (ਭੁਗਤਾਨ, ਆਥੰਟੀਕੇਸ਼ਨ, ਡੇਟਾ ਇੰਟੇਗ੍ਰਿਟੀ), ਉਥੇ ਵੱਧ ਨਿਵੇਸ਼ ਕਰੋ।
ਅਸਲ ਤੇ ਯਥਾਰਥਕ ਡਿਜ਼ਾਇਨ:
ਗੁਰਦੇਸ: ਜਦੋਂ ਕੁਝ ਗਲਤ ਹੋਵੇ ਤਾਂ ਡਿਗਰੇਡੇਸ਼ਨ ਨਾਲ ਅਹੰਕਾਰ ਥੋੜ੍ਹਾ ਕੰਮ ਚਲਦਾ ਰਹੇ।
ਖਤਰੇ ਦੇ ਆਧਾਰ 'ਤੇ ਫੈਸਲਾ ਕਰੋ:
ਇਹ ਫੈਸਲਾ ਪਹਿਲਾਂ ਹੀ ਲਿਖੋ ਅਤੇ ਮਾਨੀਟਰੀੰਗ ਇਹ ਦਿਖਾਏ ਕਿ fallback ਮੋਡ ਕਦੋਂ ਸਰਗਰਮ ਹੈ।
ਸ਼ੁਰੂਆਤ ਲਈ ਯੂਜ਼ਰ-ਇੰਪੈਕਟ ਸਿਗਨਲ ਅਤੇ ਨੰਨੀ ਕੋਰ ਟੈਲੀਮੇਟਰੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਅਲਰਟ actionable ਤੇ ਅਨੁਕੂਲ ਹੋਣ ਚਾਹੀਦੇ ਹਨ; ਸ਼ੋਰ ਵਾਲੇ ਅਲਰਟ ਟੀਮ ਨੂੰ ਅਣਡਿੱਠਾ ਕਰਵਾਉਂਦੇ ਹਨ।
ਇਕ ਛੋਟੀ ਟੀਮ ਲਈ:
ਕਾਮਯਾਬੀ ਨੂੰ ਮਾਪੋ: ਪਤਾ ਲੱਗਣ ਦਾ ਸਮਾਂ, ਨਿਯੰਤ੍ਰਣ ਲਾਉਣ ਦਾ ਸਮਾਂ, ਅਤੇ ਕੀ ਸੋਧ ਦੁਹਰਾਈ ਨਹੀਂ ਹੁੰਦੀਆਂ।