𝗧𝗵𝗲 𝗕𝗹𝗮𝗺𝗲𝗹𝗲𝘀𝘀 𝗣𝗼𝘀𝘁𝗺𝗼𝗿𝘁𝗲𝗺 𝗧𝗵𝗮𝘁 𝗦𝘁𝗶𝗹𝗹 𝗕𝗹𝗮𝗺𝗲𝘀 𝗬𝗼𝘂
ਤੁਸੀਂ ਇੱਕ ਮੀਟਿੰਗ ਵਿੱਚ ਬੈਠੇ ਹੋ। ਸਲਾਈਡ ਉੱਤੇ ਲਿਖਿਆ ਹੈ ਕਿ ਇਹ ਇੱਕ blameless postmortem ਹੈ। ਫੈਸੀਲੀਟੇਟਰ ਤੁਹਾਨੂੰ ਲੋਕਾਂ ਦੀ ਬਜਾਏ ਸਿਸਟਮਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਨ ਲਈ ਕਹਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਸਿਰ ਹਿਲਾਉਂਦੇ ਹੋ। ਫਿਰ ਵੀ ਤੁਹਾਨੂੰ ਅਜਿਹਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਜਿਵੇਂ ਤੁਹਾਨੂੰ ਸਜ਼ਾ ਦਿੱਤੀ ਜਾ ਰਹੀ ਹੋਵੇ।
ਕੰਪਨੀਆਂ 'psychological safety' ਦੀ ਭਾਸ਼ਾ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ। ਕੋਈ ਵੀ ਇਹ ਨਹੀਂ ਪੁੱਛਦਾ ਕਿ ਸਿਸਟਮ ਕਿਸ ਨੇ ਤੋੜਿਆ। ਉਹ ਪੁੱਛਦੇ ਹਨ ਕਿ ਕਿਸ ਚੀਜ਼ ਨੇ ਇਸ ਅਸਫਲਤਾ ਨੂੰ ਹੋਣ ਦਿੱਤਾ। ਇਹ ਸੁਣਨ ਵਿੱਚ ਚੰਗਾ ਲੱਗਦਾ ਹੈ। ਪਰ ਅਸਲ ਵਿੱਚ, ਇਹ ਅਕਸਰ ਨਿਗਰਾਨੀ (surveillance) ਵਾਂਗ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।
ਇੰਸੀਡੈਂਟ ਟਾਈਮਲਾਈਨ (incident timeline) ਇੱਕ ਸਾਂਝੇ ਫੋਲਡਰ ਵਿੱਚ ਪਾ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਥ੍ਰੈਡ ਵਿੱਚ ਇੱਕ ਸਵਾਲ ਆਉਂਦਾ ਹੈ। ਕੀ ਤੁਸੀਂ ਅਲਰਟ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਸੀ? ਇਹ ਇੱਕ ਤੱਥ-ਅਧਾਰਤ ਸਵਾਲ ਵਾਂਗ ਲੱਗਦਾ ਹੈ। ਪਰ ਅਸਲ ਵਿੱਚ, ਇਹ ਤੁਹਾਡੇ ਨਾਮ ਦੇ ਨਾਲ ਇੱਕ ਟਾਈਮਸਟੈਂਪ (timestamp) ਹੈ। ਤੁਹਾਡਾ ਮੈਨੇਜਰ ਤੁਹਾਡੇ ਤਿਮਾਹੀ ਰਿਵਿਊ (quarterly review) ਲਈ ਇਸ ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।
ਸਿਸਟਮ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਉਂਗਲ ਨਹੀਂ ਚੁੱਕਦਾ। ਇਹ ਸਿਰਫ ਇਹ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ ਕਿ ਕਿਸਨੇ ਕੀ ਅਤੇ ਕਦੋਂ ਕੀਤਾ। ਇਹ ਤੁਹਾਡੀਆਂ ਗਲਤੀਆਂ ਦਾ ਇੱਕ ਕਾਗਜ਼ੀ ਰਿਕਾਰਡ (paper trail) ਤਿਆਰ ਕਰ ਦਿੰਦਾ ਹੈ।
ਟੀਮਾਂ ਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਵਿਸਤ੍ਰਿਤ postmortems ਭਵਿੱਖ ਦੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਰੋਕਦੇ ਹਨ। ਉਹ ਮੰਨਦੇ ਹਨ ਕਿ ਉਹਨਾਂ ਨੂੰ ਇਹ ਜਾਣਨ ਦੀ ਲੋੜ ਹੈ ਕਿ ਕਿਸਨੇ ਲੌਗਇਨ ਕੀਤਾ ਅਤੇ ਕਿਸਨੇ ਕੋਡ ਮਰਜ (merge) ਕੀਤਾ। ਇਹ ਇੱਕ ਪੈਟਰਨ ਬਣਾਉਂਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਡਾ ਨਾਮ ਕਈ ਟਾਈਮਲਾਈਨਾਂ ਵਿੱਚ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਲੀਡਰਸ਼ਿਪ ਤੁਹਾਨੂੰ ਇੱਕ ਖ਼ਤਰੇ ਵਜੋਂ ਦੇਖਦੀ ਹੈ। ਉਹ ਤੁਹਾਨੂੰ ਉਸ ਵਿਅਕਤੀ ਵਜੋਂ ਨਹੀਂ ਦੇਖਦੇ ਜਿਸਨੇ ਬੱਗ (bug) ਨੂੰ ਠੀਕ ਕੀਤਾ ਜਾਂ ਮਦਦ ਕਰਨ ਲਈ ਦੇਰ ਰਾਤ ਤੱਕ ਜਾਗਿਆ।
ਸਮਝਦਾਰ ਇੰਜੀਨੀਅਰ ਆਪਣੇ ਆਪ ਨੂੰ ਬਚਾਉਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹਨ। ਉਹ ਕਨਫਿਗਰੇਸ਼ਨ ਚੇਂਜ (config change) ਕਰਨ ਵਾਲੇ ਆਖਰੀ ਵਿਅਕਤੀ ਬਣਨ ਤੋਂ ਬਚਦੇ ਹਨ। ਉਹ ਇੰਸੀਡੈਂਟ ਕਮਾਂਡਰ (incident commander) ਦੀ ਭੂਮਿਕਾ ਤੋਂ ਬਚਦੇ ਹਨ। ਉਹ ਅਸਪਸ਼ਟ action items ਲਿਖਦੇ ਹਨ ਤਾਂ ਜੋ ਕੋਈ ਇੱਕ ਵਿਅਕਤੀ ਉਹਨਾਂ ਦਾ ਜ਼ਿੰਮੇਵਾਰ ਨਾ ਹੋਵੇ। ਇਹ ਆਲਸ ਨਹੀਂ ਹੈ। ਇਹ ਬਚਾਅ (survival) ਹੈ।
ਜਦੋਂ blameless culture ਫੇਲ੍ਹ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇੰਜੀਨੀਅਰ on-call ਰੋਟੇਸ਼ਨਾਂ ਲਈ ਵਲੰਟੀਅਰ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ। ਉਹ ਫਿਕਸ (fix) ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਲੈਣਾ ਛੱਡ ਦਿੰਦੇ ਹਨ। ਉਹ ਸਿਸਟਮ ਦੀ ਪਰਵਾਹ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ ਅਤੇ ਆਪਣੀ ਸਾਖ (reputation) ਦੀ ਪਰਵਾਹ ਕਰਨ ਲੱਗ ਜਾਂਦੇ ਹਨ।
ਤੁਸੀਂ ਸਮੱਸਿਆ ਨੂੰ ਉਦੋਂ ਦੇਖ ਸਕਦੇ ਹੋ ਜਦੋਂ ਲੀਡਰਸ਼ਿਪ ਇੱਕ ਸੀਨੀਅਰ ਇੰਜੀਨੀਅਰ ਦੇ on-call ਛੱਡਣ ਨੂੰ ਮੋਟੀਵੇਸ਼ਨ ਦੀ ਸਮੱਸਿਆ ਵਜੋਂ ਦੇਖਦੀ ਹੈ। ਅਸਲ ਵਿੱਚ ਇਹ ਵਿਸ਼ਵਾਸ (trust) ਦੀ ਸਮੱਸਿਆ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਉਦੋਂ ਦੇਖਦੇ ਹੋ ਜਦੋਂ action items ਆਟੋਮੇਸ਼ਨ ਬਣਾਉਣ ਦੀ ਬਜਾਏ ਤੁਹਾਨੂੰ ਕੋਚਿੰਗ ਦੇਣ 'ਤੇ ਕੇਂਦਰਿਤ ਹੁੰਦੀਆਂ ਹਨ।
ਇੱਕ ਅਸਲੀ blameless culture ਇੱਕ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ: ਇਹ ਇੰਸੀਡੈਂਟ ਟਾਈਮਲਾਈਨਾਂ ਨੂੰ ਪਰਫਾਰਮੈਂਸ ਰਿਵਿਊ (performance reviews) ਵਿੱਚ ਬਦਲਣ ਤੋਂ ਇਨਕਾਰ ਕਰਦਾ ਹੈ।
ਅਸਲੀ blameless culture ਦਾ ਮਤਲਬ ਹੈ: • Postmortems ਉਸ ਵਿਅਕਤੀ ਦਾ ਸਨਮਾਨ ਕਰਦੇ ਹਨ ਜੋ ਗੜਬੜ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਆਉਂਦਾ ਹੈ। • Action items ਆਟੋਮੇਸ਼ਨ ਅਤੇ circuit breakers 'ਤੇ ਕੇਂਦਰਿਤ ਹੁੰਦੀਆਂ ਹਨ। • ਫੀਡਬੈਕ ਟੂਲਜ਼ 'ਤੇ ਕੇਂਦਰਿਤ ਹੁੰਦਾ ਹੈ, ਨਾ ਕਿ ਵਿਅਕਤੀ ਤੋਂ ਵਿਅਕਤੀ ਦੀ ਕੋਚਿੰਗ 'ਤੇ।
ਉਦੋਂ ਤੱਕ, 'blameless' ਸ਼ਬਦ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਲਈ ਸਿਰਫ ਇੱਕ ਮਾਸਕ ਹੈ।
ਸਰੋਤ: https://dev.to/omieee_24/the-blameless-postmortem-that-still-blames-you-3bdc