29 ਸਤੰ 2025·8 ਮਿੰਟ
Werner Vogels ਦੀ “ਤੁਸੀਂ ਬਣਾਉਂਦੇ ਹੋ, ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ” ਦੀ ਵਿਆਖਿਆ
ਜਾਣੋ ਕਿ Werner Vogels ਨੇ 'ਤੁਸੀਂ ਬਣਾਉਂਦੇ ਹੋ, ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ' ਨਾਲ ਕੀ ਮਤਲਬ ਰੱਖਿਆ ਅਤੇ ਇਸਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਜਾਵੇ: ਮਲਕੀਅਤ, on-call, SLOs, ਘਟਨਾ-ਜਵਾਬ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਰਿਲੀਜ਼।
ਜਾਣੋ ਕਿ Werner Vogels ਨੇ 'ਤੁਸੀਂ ਬਣਾਉਂਦੇ ਹੋ, ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ' ਨਾਲ ਕੀ ਮਤਲਬ ਰੱਖਿਆ ਅਤੇ ਇਸਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਜਾਵੇ: ਮਲਕੀਅਤ, on-call, SLOs, ਘਟਨਾ-ਜਵਾਬ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਰਿਲੀਜ਼।
“ਤੁਸੀਂ ਬਣਾਉਂਦੇ ਹੋ, ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ” ਇੱਕ ਐਵੀਆਂ ਲਾਈਨਾਂ ਵਿੱਚੋਂ ਹੈ ਜੋ ਸਿੱਧੀ ਅਤੇ ਯਾਦ ਰਹਿਣ ਵਾਲੀ ਹੈ। ਇਹ ਮੋਟਿਵੇਸ਼ਨ ਪੋਸਟਰਾਂ ਜਾਂ “ਹੁਣ ਹੋਰ DevOps ਬਣੋ” ਦੀ ਗੱਲ ਨਹੀਂ—ਇਹ ਜ਼ਿੰਮੇਵਾਰੀ ਬਾਰੇ ਇੱਕ ਸਪਸ਼ਟ ਬਿਆਨ ਹੈ: ਜੋ ਟੀਮ ਸੇਵਾ ਨੂੰ ਰਿਲੀਜ਼ ਕਰਦੀ ਹੈ, ਉਹ ਹੀ ਉਸ ਸੇਵਾ ਦੀ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿਹਾਰ ਲਈ ਜਵਾਬਦੇਹ ਰਹਿੰਦੀ ਹੈ।
ਅਮਲ ਵਿੱਚ, ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਉਹੀ ਪ੍ਰੋਡਕਟ ਟੀਮ ਜੋ ਫੀਚਰ ਡਿਜ਼ਾਈਨ ਕਰਦੀ ਅਤੇ ਕੋਡ ਲਿਖਦੀ ਹੈ, ਉਹ ਵੀ:
ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਹਰ ਕੋਈ ਇੱਕ ਦਿਨ ਵਿੱਚ ਇੰਫਰਾਸਟ੍ਰਕਚਰ ਐਕਸਪերտ ਬਣ ਜਾਵੇ। ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਫੀਡਬੈਕ ਲੂਪ ਹਕੀਕਤ ਹੁੰਦਾ ਹੈ: ਜੇ ਤੁਸੀਂ ਕੁਝ ਰਿਲੀਜ਼ ਕਰਦੇ ਹੋ ਜੋ ਆਊਟੇਜ, ਪੇਜ਼ਰ ਨੌਇਜ਼ ਜਾਂ ਗਾਹਕ ਦਰਦ ਵਧਾਉਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ ਟੀਮ ਇਸਨੂੰ ਸਿੱਧਾ ਮਹਿਸੂਸ ਕਰਦੀ—ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖਦੀ ਹੈ।
ਇਹ ਫ਼ਿਲਾਸਫੀ ਆਸਾਨੀ ਨਾਲ ਦੋਹਰਾਈ ਜਾਂਦੀ ਹੈ ਪਰ ਲਾਗੂ ਕਰਨੀ ਮੁਸ਼ਕਲ ਹੁੰਦੀ ਹੈ ਜੇ ਤਸੀਂ ਇਸਨੂੰ ਇੱਕ ਆਪਰੇਟਿੰਗ ਮਾਡਲ ਸਮਝ ਕੇ ਸਪਸ਼ਟ ਉਮੀਦਾਂ ਨਹੀਂ ਬਣਾਉਂਦੇ। “ਚਲਾਉਣਾ” ਆਮ ਤੌਰ 'ਤੇ ਕਈ ਚੀਜ਼ਾਂ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ: ਆਨ-ਕਾਲ ਹੋਣਾ (ਕਿਸੇ ਰੂਪ ਵਿੱਚ), ਘਟਨਾ ਜਵਾਬ ਦੀ ਮਲਿਕੀਅਤ, ਰਨਬੁੱਕਸ ਲਿਖਨਾ, ਡੈਸ਼ਬੋਰਡ ਬਨਾਓਣਾ, ਅਤੇ ਸੇਵਾ ਨੂੰ ਲਗਾਤਾਰ ਸੁਧਾਰਨਾ।
ਇਸਦਾ ਇਹ ਵੀ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਟੀਮਾਂ ਨੂੰ “ਚਲਾਉਣ” ਲਈ ਬਿਨਾਂ ਉਪਕਰਨਾਂ, ਪਹੁੰਚ ਅਤੇ ਅਧਿਕਾਰ ਦੇ ਨਹੀਂ ਪੁੱਛ ਸਕਦੇ—ਅਤੇ ਨਾ ਹੀ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਦੇ ਰੋਡਮੈਪ ਵਿੱਚ ਕੰਮ ਲਈ ਸਮਾਂ ਨਹੀਂ ਦਿੰਦੇ।
“ਤੁਸੀਂ ਬਣਾਉਂਦੇ ਹੋ, ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ” ਤੋਂ ਪਹਿਲਾਂ ਕਈ ਕੰਪਨੀਆਂ ਸਾਫਟਵੇਅਰ ਕੰਮ ਨੂੰ ਇੱਕ ਰਿਲੇ ਰੇਸ ਵਾਂਗ ਸੰਭਾਲਦੀਆਂ ਸਨ: ਡਿਵੈਲਪਰ ਕੋਡ ਲਿਖਦੇ, ਫਿਰ ਟੋਸ ਕੇ ops ਟੀਮ ਨੂੰ ਦੇ ਦਿੰਦੇ।
ਉਹ ਹੱਥ-ਬਦਲਾਅ ਇੱਕ ਰੋਕਥਾਮ ਹੱਲ ਕਰਦੇ—ਕਿਸੇ ਤਜਰਬੇਕਾਰ ਨੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵੇਖ ਰਿਹਾ ਸੀ—ਪਰ ਇਹ ਵੱਡੇ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਦਾ।
ਜਦੋਂ ਇੱਕ ਅਲੱਗ ops ਟੀਮ ਪ੍ਰੋਡਕਸ਼ਨ ਦੀ ਮਲਕੀਅਤ ਰੱਖਦੀ ਹੈ, ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਮੁੱਦੇ ਦੇ ਬਾਰੇ ਦੇਰ ਨਾਲ (ਜਾਂ ਕਦੇ ਨਹੀਂ) ਪਤਾ ਲੱਗਦਾ। ਬੱਗ ਦੇ ਕਈ ਵਾਰ vague ਟਿਕਟ ਵਜੋਂ ਦਿਨਾਂ ਬਾਅਦ ਆ ਸਕਦੀ ਹੈ: “ਸੇਵਾ ਸਲੋ ਹੈ” ਜਾਂ “CPU ਉੱਚਾ ਹੈ।” ਉਸ ਵੇਲੇ ਪ੍ਰਸੰਗ ਘੱਟ ਹੋ ਜਾਂਦਾ ਹੈ, ਲੌਗ ਰੋਟੇਟ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਜਿਹੜੇ ਲੋਕ ਬਦਲਾਅ ਕੀਤੇ ਉਹ ਹੁਣ ਹੋਰ ਬੰਦ ਹੋ ਚੁੱਕੇ ਹੁੰਦੇ ਹਨ।
ਹੱਥ-ਬਦਲਾਅ ownership ਨੂੰ ਵੀ ਧੁੰਦਲਾ ਕਰ ਦਿੰਦਾ ਹੈ। ਜੇ ਆਊਟੇਜ ਹੁੰਦੀ ਹੈ, dev ਸੋਚ ਸਕਦਾ ਹੈ "ops ਇਸਨੂੰ ਫੰਗਡਨਗੇ," ਜਦਕਿ ops ਸੋਚਦੀ ਹੈ "dev ਨੇ ਕੁਝ ਖਤਰਨਾਕ ਰਿਲੀਜ਼ ਕੀਤਾ।" ਨਤੀਜਾ ਲੰਬੀ ਘਟਨਾ ਨਿਵਾਰਨ, ਦੁਹਰਾਉਂਦੇ ਫੇਲਿਊਰ ਮੋਡ ਅਤੇ ਇੱਕ ਐਸਾ ਸਭਿਆਚਾਰ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ ਟੀਮਾਂ ਗ੍ਰਾਹਕ ਅਨੁਭਵ ਲਈ ਨਹੀਂ, ਬਲਕਿ ਆਪਣੀ ਲੋਕਲ ਭਲਾਈ ਲਈ optimize ਕਰਦੀਆਂ ਹਨ।
“ਤੁਸੀਂ ਬਣਾਉਂਦੇ ਹੋ, ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ” ਲੂਪ ਨੂੰ ਤੰਗ ਕਰਦਾ ਹੈ। ਉਹੀ ਟੀਮ ਜੋ ਇੱਕ ਬਦਲਾਅ ਸ਼ਿਪ ਕਰਦੀ ਹੈ, ਪ੍ਰੋਡਕਸ਼ਨ ਵਿਚ ਉਸਦੇ ਵਿਹਾਰ ਲਈ ਜਵਾਬਦੇਹ ਹੁੰਦੀ ਹੈ। ਇਹ ਪ੍ਰਯੋਗਸ਼ੀਲ ਸੁਧਾਰਾਂ ਨੂੰ upstream ਧੱਕਦਾ: ਵਧੀਆ alerts, ਸੇਫਰ rollouts, ਵਧੀਆ ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਉਹ ਕੋਡ ਜੋ ਚਲਾਉਣਾ ਆਸਾਨ ਹੋਵੇ।
ਪੈਰਾਡਾਕਸਿਕਲੀ, ਇਹ ਅਕਸਰ ਤੇਜ਼ ਡਿਲਿਵਰੀ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ ਟੀਮਾਂ ਆਪਣੇ ਰਿਲੀਜ਼ ਪ੍ਰਕਿਰਿਆ 'ਤੇ ਭਰੋਸਾ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿਹਾਰ ਨੂੰ ਸਮਝਦੀਆਂ ਹਨ, ਉਹ ਛੋਟੇ ਬਦਲਾਅ ਵੱਧ ਅਕਸਰ ਕਰ ਸਕਦੀਆਂ ਹਨ—ਇਸ ਨਾਲ ਗਲਤੀਆਂ ਦਾ blast radius ਘੱਟ ਹੁੰਦਾ ਅਤੇ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਡਾਇਗਨੋਜ਼ ਕਰਨਾ ਅਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
ਹਰ ਸੰਸਥਾ ਇਕੋ ਜਿਹੀ ਸਟਾਫਿੰਗ, ਕੰਪਲਾਇੰਸ ਮੰਗਾਂ ਜਾਂ ਲੇਗਸੀ ਸਿਸਟਮਾਂ ਨਾਲ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਫ਼ਿਲਾਸਫੀ ਇੱਕ ਦਿਸ਼ਾ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਸਵਿੱਚ। ਕਈ ਟੀਮਾਂ ਹੌਲੀ-ਹੌਲੀ ਅਪਣਾਉਂਦੀਆਂ ਹਨ—ਰਿਸ਼ਤਿਆਂ ਵਾਲੀ ਆਨ-ਕਾਲ ਸ਼ੇਅਰ ਕਰਕੇ, ਵਧੀਆ ਓਬਜ਼ਰਵੇਬਿਲਟੀ ਤੋਂ ਲੈ ਕੇ ਸੇਵਾ ਬਾਊਂਡਰੀਜ਼ ਤੱਕ—ਫਿਰ ਪੂਰੀ end-to-end ਮਲਕੀਅਤ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ।
Werner Vogels, Amazon ਦੇ CTO, ਨੇ "ਤੁਸੀਂ ਬਣਾਉਂਦੇ ਹੋ, ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ" ਵਿੱਚ ਇਸ ਵਿਚਾਰ ਨੂੰ ਲੋਕਪ੍ਰਿਯ ਕੀਤਾ, ਜਦੋਂ ਉਹ ਵਰਣਨ ਕਰ ਰਹੇ ਸਨ ਕਿ Amazon (ਅਤੇ ਬਾਅਦ ਵਿੱਚ AWS) ਟੀਮਾਂ ਨੂੰ ਸਾਫਟਵੇਅਰ ਬਾਰੇ ਕਿਵੇਂ ਸੋਚਣਾ ਚਾਹੀਦਾ: ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਵਜੋਂ ਨਹੀਂ ਜੋ ਤੁਸੀਂ ਹੱਥੋਂ-ਹੱਥ ਦੇ ਦਿਓ, ਬਲਕਿ ਇੱਕ ਸੇਵਾ ਵਜੋਂ ਜੋ ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ।
ਕੁੰਜੀ ਬਦਲਾਅ ਤਕਨੀਕੀ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਮਨੋਵੈਜ਼ਾਨਕ ਸੀ। ਜਦੋਂ ਇੱਕ ਟੀਮ ਨੂੰ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ ਉਹ ਫੇਲ੍ਹ ਹੋਣ 'ਤੇ ਪੇਜ ਕੀਤਾ ਜਾਵੇਗਾ, ਡਿਜ਼ਾਈਨ ਫ਼ੈਸਲੇ ਬਦਲ ਜਾਂਦੇ ਹਨ। ਤੁਸੀਂ ਸਹੀ ਡਿਫਾਲਟਸ, ਸਪਸ਼ਟ alerting, graceful degradation, ਅਤੇ ਉਹ deployment ਰਸਤੇ ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਤੁਸੀਂ rollback ਕਰ ਸਕੋ। ਹੋਰ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਬਣਾਉਣਾ ਅਸਲ ਵਿੱਚ ਜ਼ਿੰਦਗੀ ਦੇ ਗੜਬੜ ਭਾਗਾਂ ਦੀ ਯੋਜਨਾ ਕਰਨਾ ਵੀ ਸ਼ਾਮਲ ਹੈ।
AWS-ਯੁੱਗ ਦੇ ਸੇਵਾ ਸੋਚ ਨੇ ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਗਤੀ ਨੂੰ ਗੈਰ-ਬਰਤੋਂਯੋਗ ਬਣਾਇਆ। ਕਲਾਉਡ ਗਾਹਕ ਉਮੀਦ ਕਰਦੇ ਹਨ ਕਿ APIs ਚੌਵੀ ਘੰਟੇ ਉਪਲਬਧ ਰਹਿਣ ਅਤੇ ਸੁਧਾਰ ਲਗਾਤਾਰ ਮਿਲਦੇ ਰਹਿਣ—ਕੋਈ ਤਿਮਾਹੀ ਵਾਲੀ "ਵੱਡੀ ਰਿਲੀਜ਼" ਦੀ ਉਡੀਕ ਨਹੀਂ।
ਇਸ ਦਬਾਅ ਨੇ ਉਤਸ਼ਾਹਿਤ ਕੀਤਾ:
ਇਹ ਫ਼ਿਲਾਸਫੀ ਵੱਡੇ DevOps ਹਿਲਚਲ ਨਾਲ ਓਵਰਲੈਪ ਕਰਦੀ ਹੈ: "dev" ਅਤੇ "ops" ਦੇ ਵਿਚਕਾਰ ਦੀ ਖਾਈ ਘਟਾਉਣਾ, ਹੱਥ-ਬਦਲਾਅ ਘਟਾਉਣਾ, ਅਤੇ ਨਤੀਜਿਆਂ (ਉਪਲਬਧਤਾ, ਲੈਟੰਸੀ, ਸਹਾਇਤਾ ਭਾਰ) ਨੂੰ ਵਿਕਾਸ ਲੂਪ ਦਾ ਹਿੱਸਾ ਬਣਾਉਣਾ। ਇਹ ਛੋٹی ਇੱਕਾਂਤ ਟੀਮਾਂ ਦੇ ਵਿਚਾਰ ਨਾਲ ਵੀ ਮਿਲਦੀ ਹੈ ਜੋ ਸੁਤੰਤਰ ਪਛਾਣ ਨਾਲ ਅਜ਼ਾਦੀ ਨਾਲ ਰਿਲੀਜ਼ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਇਹ ਆਸਾਨ ਹੈ ਕਿ Amazon ਦੇ ਢਾਂਚੇ ਨੂੰ ਬਿਲਕੁਲ ਨਕਲ ਕਰ ਲਿਆ ਜਾਵੇ। ਪਰ "You Build It, You Run It" ਇਕ ਦਿਸ਼ਾ ਹੈ, ਸਖ਼ਤ ਆਰਗ ਚਾਰਟ ਨਹੀਂ। ਤੁਹਾਡੇ ਟੀਮ ਦਾ ਆਕਾਰ, ਨਿਯਮ-ਕਾਇਦੇ, ਉਤਪਾਦ ਦੀ ਪੱਕਿਆਈ ਅਤੇ uptime ਮੰਗਾਂ ਅਨੁਸਾਰ ਪਰਿਵਰਤਨ ਲਿਆ ਜਾ ਸਕਦਾ—ਸ਼ੇਅਰਡ ਆਨ-ਕਾਲ ਰੋਟੇਸ਼ਨ, ਪਲੇਟਫਾਰਮ ਸਹਾਇਤਾ, ਜਾਂ ਕਦਮ-ਦਰ-কਦਮ ਅਪਣਾਉਣਾ।
ਜੇ ਤੁਸੀਂ ਮਨੋਵ੍ਰਿਤੀ ਨੂੰ ਕਾਰਜ ਵਿੱਚ ਬਦਲਣ ਲਈ ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ ਤਰੀਕਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ /blog/how-to-adopt-you-build-it-you-run-it-step-by-step ਨੂੰ ਦੇਖੋ।
"ਤੁਸੀਂ ਬਣਾਉਂਦੇ ਹੋ, ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ" ਅਸਲ ਵਿੱਚ ਮਲਕੀਅਤ ਬਾਰੇ ਇੱਕ ਬਿਆਨ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਇੱਕ ਸੇਵਾ ਨੂੰ ਰਿਲੀਜ਼ ਕਰਦੀ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ ਟੀਮ ਸੇਵਾ ਦੇ ਅਸਲ ਸੰਸਾਰ ਵਿੱਚ ਵਿਹਾਰ ਲਈ ਜਵਾਬਦੇਹ ਹੁੰਦੀ ਹੈ—ਸਿਰਫ਼ ਰਿਲੀਜ਼ ਦੇ ਦਿਨ ਟੈਸਟਾਂ ਪਾਸ ਹੋਣ ਦੀ ਗੱਲ ਨਹੀਂ।
ਸੇਵਾ ਚਲਾਉਣਾ ਨਿਰੰਤ ਉਸ ਅੰਤ-ਤੱਕ ਨਤੀਜਿਆਂ ਦੀ ਪਰਵਾਹ ਕਰਨ ਦਾ ਮਤਲਬ ਹੈ:
ਆਮ ਹਫਤੇ 'ਚ, “ਚਲਾਉਣਾ” ਹੀਰੋਈਕਸ ਬਾਰੇ ਘੱਟ ਅਤੇ ਰੁਟੀਨਲ ਓਪਰੇਸ਼ਨਾਂ ਬਾਰੇ ਵੱਧ ਹੁੰਦਾ ਹੈ:
ਇਹ ਮਾਡਲ ਤਬ ਹੀ ਕੰਮ ਕਰਦਾ ਜਦੋਂ ਜਵਾਬਦੇਹੀ ਦਾ ਮਤਲਬ "ਅਸੀਂ ਮੁਅੱਮਲਾ ਠੀਕ ਕਰਾਂਗੇ" ਹੋਵੇ, ਨਾ ਕਿ "ਅਸੀਂ ਕਿਸੇ ਵਿਅਕਤੀ ਨੂੰ ਦੋਸ਼ ਲਗਾਂਗੇ।" ਜਦੋਂ ਕੁਝ ਟੁੱਟਦਾ ਹੈ, ਲਕਸ਼ਯ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਸਿਸਟਮ ਵਿੱਚ ਕੀ ਗੱਲ ਐਸੀ ਸੀ ਜਿਸ ਨੇ ਇਸਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਆਉਣ ਦਿੱਤਾ—ਘੱਟ alerts, ਅਸਪਸ਼ਟ ਲਿਮਿਟ, ਖਤਰਨਾਕ ਡਿਪਲੋਇ—ਅਤੇ ਉਹ ਹਾਲਤਾਂ ਸੁਧਾਰੀਆਂ ਜਾਣ।
ਜਦੋਂ ਸੇਵਾਵਾਂ fuzzy ਹੁੰਦੀਆਂ ਹਨ ਤਾਂ ਮਲਕੀਅਤ ਗੁੰਝਲਦਾਰ ਹੋ ਜਾਂਦੀ ਹੈ। ਸੇਵਾ ਹੱਦਾਂ ਨਿਰਧਾਰਤ ਕਰੋ (ਇਹ ਕੀ ਕਰਦੀ ਹੈ, ਇਹ ਕਿਸ 'ਤੇ ਨਿਰਭਰ ਹੈ, ਇਹ ਕੀ ਵਾਅਦਾ ਕਰਦੀ ਹੈ) ਅਤੇ ਨਾਮਵਾਰ ਮਾਲਕ ਟੀਮ ਵਾਰ ਕਰ ਦਿਓ। ਇਹ ਸਪਸ਼ਟਤਾ ਹੱਥ-ਬਦਲਾਅ ਘਟਾਉਂਦੀ, ਘਟਨਾ ਜਵਾਬ ਤੇਜ਼ ਕਰਦੀ, ਅਤੇ ਜਦੋਂ ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਫੀਚਰ ਮੁਕਾਬਲਾ ਕਰਨ ਤਾਂ ਪ੍ਰਾਥਮਿਕਤਾਵਾਂ ਸਪਸ਼ਟ ਬਣਾਉਂਦੀ ਹੈ।
On-call “You Build It, You Run It” ਦਾ ਕੇਂਦਰੀ ਹਿੱਸਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਫੀਡਬੈਕ ਲੂਪ ਨੂੰ ਬੰਦ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਜੋ ਟੀਮ ਇੱਕ ਬਦਲਾਅ ਸ਼ਿਪ ਕਰਦੀ ਹੈ, ਉਹੀ ਆਨ-ਕਾਲ ਵੀ ਹੁੰਦੀ ਹੈ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਅਸਰ (ਲੈਟੰਸੀ spike, failed deploys, ਗਾਹਕ ਸ਼ਿਕਾਇਤ) ਨੂੰ ਮਹਿਸੂਸ ਕਰਦੀ ਹੈ, ਤਦ ਪ੍ਰਾਥਮਿਕਤਾਵਾਂ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦੀਆਂ ਹਨ: ਭਰੋਸੇਯੋਗਤਾ ਕੰਮ “ਕਿਸੇ ਹੋਰ ਦੀ ਸਮੱਸਿਆ” ਨਹੀਂ ਰਹਿੰਦਾ, ਅਤੇ ਜ਼ਿਆਦਾ ਸ਼ਿਪ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਅਕਸਰ ਸਿਸਟਮ ਨੂੰ ਸ਼ਾਂਤ ਕਰਨਾ ਹੁੰਦਾ ਹੈ।
ਸਿਹਤਮੰਦ on-call ਜ਼ਿਆਦਾ ਤਰ predictability ਅਤੇ support ਬਾਰੇ ਹੈ।
Severity ਪੱਧਰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਤਾਂ ਕਿ ਸਿਸਟਮ ਹਰ ਛੋਟੀ ਨਾ-ਨੂੰ ਪੇਜ ਨਾ ਕਰੇ۔
ਸਧਾਰਨ ਨਿਯਮ: ਜੇ ਕਿਸੇ ਨੂੰ ਜਗਾਉਣਾ ਨਤੀਜੇ ਨੂੰ ਬਦਲਣ ਵਾਲਾ ਨਹੀਂ, ਤਾਂ ਇਹ ਟਿਕਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਪੇਜ ਨਹੀਂ।
On-call ਸਜ਼ਾ ਨਹੀਂ; ਇਹ ਇੱਕ ਸੰਕੇਤ ਹੈ। ਹਰ noisy alert, ਦੁਹਰਾਉਂਦਾ ਫੇਲ੍ਹ ਜਾਂ ਮੈਨੂਅਲ ਫਿਕਸ ਨੂੰ ਇੰਜੀਨੀਅਰਿੰਗ ਕੰਮ ਵਿੱਚ ਫੀਡ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ: ਵਧੀਆ alerts, ਆਟੋਮੇਸ਼ਨ, ਸੇਫਰ ਰਿਲੀਜ਼, ਅਤੇ ਸਿਸਟਮ ਬਦਲਾਅ ਜੋ ਪੇਜ ਕਰਨ ਦੀ ਲੋੜ ਹੀ ਮਿਟਾ ਦੇਂ।
ਜੇ “ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ” ਸੱਚਮੁਚ ਹੈ, ਟੀਮਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗਤਾ ਬਾਰੇ ਵਿਚਾਰ ਕਰਨ ਲਈ ਸਾਂਝਾ ਤਰੀਕਾ ਚਾਹੀਦਾ। SLIs, SLOs, ਅਤੇ error budgets ਇਹ ਦਿੰਦੇ ਹਨ: ਸਪਸ਼ਟ ਟਾਰਗਟ ਅਤੇ ਤੇਜ਼ਾ ਅਤੇ ਸਥਿਰਤਾ ਵਿਚਕਾਰ ਇੱਕ ਵਾਜਿਬ ਵਪਾਰ।
ਯਾਦ ਰੱਖਣ ਦਾ ਇੱਕ ਉਪਯੋਗੀ ਤਰੀਕਾ: SLI = ਮੈਟ੍ਰਿਕ, SLO = ਟਾਰਗਟ, SLA = ਬਾਹਰੀ ਵਚਨ।
ਛੋਟੇ ਅਤੇ ਯੂਜ਼ਰ ਅਨੁਭਵ ਨਾਲ ਜੁੜੇ SLIs ਵਧੀਆ ਹੁੰਦੇ ਹਨ, ਜਿਵੇਂ:
Error budget ਉਹ ਮਾਤਰਾ ਹੈ ਜੋ ਤੁਸੀਂ SLO ਪੂਰਾ ਰੱਖਦੇ ਹੋਏ “ਖਰਾਬੀ” ਲਈ ਵਰਤ ਸਕਦੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, ਜੇ SLO 99.9% ਉਪਲਬਧਤਾ ਹੈ, ਤਾਂ ਮਹੀਨੇ ਦਾ error budget 0.1% downtime ਹੈ)।
ਜਦੋਂ ਸੇਵਾ ਸਿਹਤਮੰਦ ਹੈ ਅਤੇ ਤੁਸੀਂ budget ਦੇ ਅੰਦਰ ਹੋ, ਟੀਮਾਂ ਜ਼ਿਆਦਾ ਡਿਲਿਵਰੀ ਰਿਸਕ ਲੈ ਸਕਦੀਆਂ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਬਜਟ ਤੇਜ਼ੀ ਨਾਲ ਜ਼ਰ੍ਹ ਰਹੇ ਹੋ, ਤਾਂ ਭਰੋਸੇਯੋਗਤਾ ਕੰਮ ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਮਿਲਦੀ ਹੈ।
SLOs reliability ਨੂੰ ਯੋਜਨਾ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰ ਦਿੰਦੇ ਹਨ। ਜੇ ਤੁਹਾਡਾ error budget ਘੱਟ ਹੈ, ਅਗਲਾ ਸਪ੍ਰਿੰਟ rate limiting, safer rollouts, ਜਾਂ flaky ਡਿਪੈਂਡੇੰਸੀਜ਼ ਠੀਕ ਕਰਨ 'ਤੇ ਧਿਆਨ ਦੇ ਸਕਦਾ—ਕਿਉਂਕਿ SLO ਗੁੰਮ ਹੋਣ ਦਾ ਸਪਸ਼ਟ ਲਾਗਤ ਹੈ। ਜੇ ਬਜਟ ਵਧੀਆ ਹੈ, ਤੁਸੀਂ ਨਿਰਭਯਤਾਪੂਰਵਕ product ਕੰਮ ਨੂੰ ਤਰਜੀਹ ਦੇ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਇਹ ਅਟਕਦੇ ਹੋਏ ਕਿ "ops ਠੀਕ ਰਹੇਗਾ"।
“It works” ਉਹੋ ਸਮਾਂ ਹੋਵੇ ਜਦੋਂ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਸ਼ਿਪਿੰਗ ਰੁਟੀਨ ਹੋਵੇ—ਨ ਕਿ ਇੱਕ ਉੱਚ-ਭਾਰ ਵਾਲੀ ਘਟਨਾ। ਲਕਸ਼ਯ uncertainty ਨੂੰ ਘਟਾਉਣਾ ਅਤੇ ਰਿਲੀਜ਼ ਬਾਅਦ blast radius ਨੂੰ ਸੀਮਿਤ ਕਰਨਾ ਹੈ।
ਇੱਕ ਸੇਵਾ ਨੂੰ “ਤਿਆਰ” ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ, ਟੀਮਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਓਪਰੇਸ਼ਨਲ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਲਗਾ ਦਿਓ:
ਸਭ ਕੁਝ ਇਕੱਠੇ ਹੀ ਸਾਰੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਰਿਲੀਜ਼ ਕਰਨ ਦੀ ਥਾਂ, progressive delivery ਪ੍ਰਭਾਵ ਨੂੰ ਸੀਮਿਤ ਕਰਦਾ:
ਜੇ ਟੀਮ rollback ਨੂੰ standardize ਕਰ ਰਹੀ ਹੈ ਤਾਂ ਇਸਨੂੰ ਪਹਿਲ ਦਰਜੇ ਦੀ ਯੋਗਤਾ ਮੰਨੋ: ਜਿੰਨੀ ਤੇਜ਼ ਤੁਸੀਂ ਸੇਫ਼ ਲਹਿਰ ਤੌਰ 'ਤੇ revert ਕਰ ਸਕਦੇ ਹੋ, ਉਤੀ ਹੀ "ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ" ਜ਼ਿਆਦਾ ਹਕੀਕਤ ਬਣਦੀ ਹੈ।
ਦੋ ਟੈਸਟ "unknown unknowns" ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ:
ਇਸਨੂੰ ਹਾਈ-ਲੈਟੇਨਸੀ ਨਾ ਰੱਖੋ: ਆਪਣੇ ਰਿਪੋ ਜਾਂ ਟਿਕਟ ਟੈਮਪਲੇਟ 'ਚ ਇਕ ਸਫ਼ੇ ਦੀ ਚੈਕਲਿਸਟ ਰੱਖੋ (ਉਦਾਹਰਣ: "Observability," "On-call readiness," "Data protection," "Rollback plan," "Capacity tested," "Runbooks linked"). "Not ready" ਨੂੰ ਸਧਾਰਨ ਸਥਿਤੀ ਬਣਾਓ—ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਸਿੱਖਣ ਦੀ ਥਾਂ ਨਹੀਂ।
ਘਟਨਾਵਾਂ ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ “ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ” ਅਸਲ ਬਣਦਾ ਹੈ: ਇੱਕ ਸੇਵਾ ਘਟਿਤ ਹੋ ਜਾਂਦੀ ਹੈ, ਗਾਹਕ ਨੋਟਿਸ ਕਰਦੇ ਹਨ, ਅਤੇ ਟੀਮ ਨੂੰ ਤੇਜ਼ੀ ਅਤੇ ਸਪਸ਼ਟਤਾ ਨਾਲ ਜਵਾਬ ਦੇਣਾ ਪੈਂਦਾ ਹੈ। ਲਕਸ਼ਯ ਹੀਰੋਈਕਸ ਨਹੀਂ—ਇੱਕ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲਾ workflow ਜੋ ਪ੍ਰਭਾਵ ਘਟਾਉਂਦਾ ਅਤੇ ਸੁਧਾਰ ਲਿਆਉਂਦਾ ਹੈ।
ਅਕਸਰ ਟੀਮ ਇੱਕੋ ਹੀ ਫੇਜ਼ਾਂ 'ਤੇ ਆਉਂਦੀਆਂ ਹਨ:
ਇਸ ਪ੍ਰਵਾਹ ਲਈ ਇੱਕ ਹਲਕਾ ਚੈਕਲਿਸਟ ਰੱਖਣਾ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ (ਦੇਖੋ /blog/incident-response-checklist)।
ਬਲੈਮਲੈੱਸ postmortem ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ "ਕਿਸੇ ਨੇ ਗਲਤੀ ਨਹੀਂ ਕੀਤੀ"। ਇਸਦਾ ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਘਟਨਾ ਨੂੰ ਪ੍ਰਣਾਲੀ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਦੀ ਨਜ਼ਰ ਨਾਲ ਵੇਖੋ, ਨਾ ਕਿ ਵਿਅਕਤੀਆਂ ਨੂੰ ਸਜਾਏ ਜਾਣ। ਇਹ ਲੋਕਾਂ ਨੂੰ ਵੇਰਵੇ early ਸਾਂਝੇ ਕਰਨ ਲਈ ਪ੍ਰੋਤਸਾਹਿਤ ਕਰਦਾ ਹੈ, ਜੋ ਸਿੱਖਣ ਲਈ ਜ਼ਰੂਰੀ ਹੈ।
ਦਸਤਾਵੇਜ਼ ਕਰੋ:
ਚੰਗੇ postmortems concrete, ਮਾਲਕ-ਦਾਰ follow-ups ਨਾਲ ਖਤਮ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਆਮ ਤੌਰ 'ਤੇ ਚਾਰ ਬਕਸਿਆਂ ਵਿੱਚ: ਟੂਲਿੰਗ ਸੁਧਾਰ (ਵਧੀਆ alerts/ਡੈਸ਼ਬੋਰਡ), ਟੈਸਟ (ਰੈਗਰੈਸ਼ਨ/ਐਜ ਕੇਸ), ਆਟੋਮੇਸ਼ਨ (ਸੇਫ਼ deploy/rollback, ਗਾਰਡਰੇਲ), ਅਤੇ ਦਸਤਾਵੇਜ਼ (runbooks, ਸਪਸ਼ਟ ਓਪਰੇਸ਼ਨਲ ਕਦਮ). ਇਕ owner ਅਤੇ ਨਿਸ਼ਚਿਤ ਮਿਆਦ ਨਿਰਧਾਰਤ ਕਰੋ—ਨਹੀਂ ਤਾਂ ਸਿੱਖਣਾ ਸਿਧਾਂਤਕ ਹੀ ਰਹਿ ਜਾਵੇਗਾ।
ਟੂਲਿੰਗ ਉਹ leverage ਹੈ ਜੋ “You Build It, You Run It” ਨੂੰ ਭਾਰਤਯੋਗ ਬਣਾਉਂਦਾ—ਪਰ ਇਹ ਅਸਲੀ ਮਲਕੀਅਤ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈ ਸਕਦੀ। ਜੇ ਟੀਮ ਓਪਰੇਸ਼ਨਸ ਨੂੰ "ਕਿਸੇ ਹੋਰ ਦੀ ਸਮੱਸਿਆ" ਸਮਝਦੀ ਹੈ, ਤਾੰ ਸਭ ਤੋਂ ਵਧੀਆ ਡੈਸ਼ਬੋਰਡ ਵੀ ਉਸ ਹਲਚਲ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰੇਗਾ। ਚੰਗੇ ਟੂਲ friction ਘਟਾਉਂਦੇ ਹਨ: ਸਹੀ ਚੀਜ਼ ਨੂੰ ਕਰਨ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ।
ਸੇਵਾ ਮਾਲਕਾਂ ਨੂੰ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਸਥਿਰ ਤਰੀਕਾ ਚਾਹੀਦੀ ਹੈ ਜਿਸ ਨਾਲ ਉਹ ਆਪਣੀ ਸਾਫਟਵੇਅਰ ਕੀ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਕੀ ਕਰ ਰਹੀ ਹੈ ਵੇਖ ਸਕਣ ਅਤੇ ਜਦੋਂ ਕੁਝ ਗਲਤ ਹੋਵੇ ਤਾਂ ਤੁਰੰਤ ਕਾਰਵਾਈ ਕਰ ਸਕਣ।
ਜੇ आपका monitoring ਕਹਾਣੀ ਫਰੈਗਮੈਂਟਡ ਹੈ, ਟੀਮਾਂ ਵਧੇਰੇ ਸਮਾਂ hunting 'ਚ ਗੁਜ਼ਾਰਦੀਆਂ ਹਨ। ਇੱਕ unified observability ਦ੍ਰਿਸ਼ਟੀ ਮਦਦ ਕਰਦੀ ਹੈ (ਵੇਖੋ /product/observability)।
ਜਿਵੇਂ-ਜਿਵੇਂ ਸੰਗਠਨ ਵਧਦਾ ਹੈ, "ਕੌਣ ਇਸਦਾ ਮਾਲਕ ਹੈ?" ਇੱਕ ਭਰੋਸੇਯੋਗਤਾ ਖ਼ਤਰਾ ਬਣ ਜਾਂਦਾ ਹੈ। ਇੱਕ service catalog (ਅੰਦਰੂਨੀ developer portal) ਇਸਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ: ਮਾਲਕੀਅਤ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਸੰਦਰਭ ਇਕਥੇ ਰੱਖ ਕੇ—ਟੀਮ ਨਾਮ, on-call ਰੋਟੇਸ਼ਨ, ਐਸਕਲੇਸ਼ਨ ਪਾਥ, runbooks, ਡੈਪੈਂਡੇਨਸੀਜ਼, ਅਤੇ ਡੈਸ਼ਬੋਰਡ ਲਿੰਕ।
ਕੁੰਜੀ ਹੈ ownership metadata ਜੋ ਅਪ-ਟੂ-ਡੇਟ ਰਹੇ। ਇਸਨੂੰ ਵਰਕਫਲੋ ਦਾ ਹਿੱਸਾ ਬਣਾਓ: ਨਵੀਂ ਸੇਵਾਵਾਂ ਲਾਈਵ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਮਾਲਕ ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੋਵੇ, ਅਤੇ ਮਲਕੀਅਤ ਦੇ ਬਦਲਾਅ ਕੋਡ ਬਦਲਾਅ ਵਾਂਗ review ਅਤੇ ਟਰੈਕ ਕੀਤੇ ਜਾਣ।
ਸਭ ਤੋਂ ਵਧੀਆ ਸੈਟਅਪ ਟੀਮਾਂ ਨੂੰ ਸਿਹਤਮੰਦ ਵਰਤਾਰਾਂ ਵੱਲ ਧੱਕਦੇ ਹਨ: runbook ਲਈ ਟੈਂਪਲੇਟ, SLOs ਨਾਲ ਜੁੜੇ ਆਟੋਮੈਟਿਕ alerts, ਅਤੇ ਡੈਸ਼ਬੋਰਡ ਜੋ ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ “ਕੀ ਯੂਜ਼ਰ ਪ੍ਰਭਾਵਿਤ ਹਨ?” ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ। ਪਰ ਮਨੁੱਖੀ ਪ੍ਰਣਾਲੀ ਫਿਰ ਵੀ ਮਾਇਨ ਕਰਦੀ ਹੈ—ਟੀਮਾਂ ਨੂੰ ਇਹ ਟੂਲ ਵਰਤ ਕੇ ਰੱਖਣ, alerts prune ਕਰਨ ਅਤੇ ਆਪਣੇ ਸੇਵਾ ਚਲਾਉਣ ਦੇ ਢੰਗ ਨੂੰ ਲਗਾਤਾਰ ਸੁਧਾਰਨ ਲਈ ਸਮਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਪਲੇਟਫਾਰਮ ਟੀਮਾਂ “You Build It, You Run It” ਨੂੰ ਜੀਉਂਦਾ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ। ਉਨਾਂ ਦਾ ਕੰਮ ਹਰ ਕਿਸੇ ਲਈ ਪ੍ਰੋਡਕਸ਼ਨ ਚਲਾਉਣਾ ਨਹੀਂ—ਇਹ ਪ੍ਰੋਡਕਟ ਟੀਮਾਂ ਲਈ “ਚਮਤਕਾਰ-ਸਿੱਧਾ ਰਸਤਾ” (paved roads) ਪ੍ਰਦਾਨ ਕਰਨਾ ਹੈ ਤਾਂ ਜੋ ਟੀਮਾਂ ਹਰ ਸਪ੍ਰਿੰਟ 'ਤੇ ops ਦੁਬਾਰਾ ਨਾਂ ਬਣਾਨ।
ਚੰਗਾ ਪਲੇਟਫਾਰਮ defaults ਦਿੰਦਾ ਹੈ ਜੋ ਗਲਤੀ ਕਰਨਾ ਮੁਸ਼ਕਲ ਅਤੇ ਅਪਣਾਉਣਾ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ:
Guardrails risky ਵਰਤਾਰਾ ਨੂੰ ਰੋਕਣਗੇ ਬਗੈਰ shipping ਨੂੰ ਰੋਕੇ। “ਸੁਰੱਖਿਅਤ ਡੀਫਾਲਟ” ਸੋਚੋ ਨਾ ਕਿ “ਟਿਕਟ ਖੋਲੋ ਅਤੇ ਉਡੀਕ ਕਰੋ।”
ਪਲੇਟਫਾਰਮ ਟੀਮਾਂ shared services ਚਲਾ ਸਕਦੀਆਂ ਹਨ—ਪਰ product services ਦੀ ਮਲਕੀਅਤ ਲੈਣ ਦੇ ਬਜਾਏ।
ਸੀਮਾ ਸਧਾਰਨ ਹੈ: ਪਲੇਟਫਾਰਮ ਟੀਮ ਪਲੇਟਫਾਰਮ ਦੀ uptime ਅਤੇ ਸਹਾਇਤਾ ਦੀ ਮਲਕੀਅਤ ਰੱਖਦੀ ਹੈ; ਪ੍ਰੋਡਕਟ ਟੀਮਾਂ ਇਹ ਨਿਰਧਾਰਨ ਕਰਦੀਆਂ ਹਨ ਕਿ ਉਹ ਇਸਨੂੰ ਕਿਵੇਂ ਵਰਤਦੀਆਂ ਹਨ।
ਜਦੋਂ ਟੀਮਾਂ ਨੂੰ ਦਿਨ-ਇੱਕ 'ਤੇ CI/CD, auth, ਜਾਂ secrets ਵਿੱਚ ਨਵਾਂ ਵਿਸ਼ੇਸ਼ ਗਿਆਨ ਨਾਹੀ ਲੱਗਣਾ ਪੈਂਦਾ, ਉਹ ਸੇਵਾ ਵਿਹਾਰ ਅਤੇ ਯੂਜ਼ਰ ਪ੍ਰਭਾਵ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਉਦਾਹਰਣ ਜੋ busywork ਘਟਾਉਂਦੇ ਹਨ:
ਨਤੀਜਾ ਤੇਜ਼ ਡਿਲਿਵਰੀ ਹੈ ਘੱਟ “custom ops snowflakes” ਨਾਲ, ਪਰ ਮੁੱਖ ਵਾਅਦਾ ਅਟੁੱਟ ਰਹਿੰਦਾ ਹੈ: ਜੋ ਟੀਮ ਸੇਵਾ ਬਣਾਉਂਦੀ ਹੈ, ਉਹੀ ਚਲਾਉਂਦੀ ਹੈ।
“ਤੁਸੀਂ ਬਣਾਉਂਦੇ ਹੋ, ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ” ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਗਤੀ ਦੋਹਾਂ ਨੂੰ ਬਿਹਤਰ ਕਰ ਸਕਦੀ—ਪਰ ਕੇਵਲ ਜੇ ਸੰਗਠਨ ਟੀਮ ਦੇ ਆਸ-ਪਾਸ ਦੀਆਂ ਹਾਲਤਾਂ ਬਦਲ ਦਿੰਦਾ। ਕਈ ਨਾਕਾਮੀਆਂ ਇਸੀ ਤਰ੍ਹਾਂ ਦਿਖਦੀਆਂ ਹਨ ਕਿ ਨਾਅਰਾ ਅਪਣਾਇਆ ਗਿਆ ਪਰ ਸਹਾਇਕ ਆਦਤਾਂ ਨਹੀਂ।
ਕੁਝ ਪੈਟਰਨ ਮੁੜ ਮੁੜ ਆਉਂਦੇ ਹਨ:
ਕੁਝ ਵਾਤਾਵਰਣ ਇੱਕ ਟੇਲਰ ਕੀਤੇ ਤਰੀਕੇ ਦੀ ਮੰਗ ਕਰਦੇ ਹਨ:
ਇਹ ਫ਼ਿਲਾਸਫੀ ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਨਾਕਾਮ ਹੁੰਦੀ ਹੈ ਜਦੋਂ reliability ਕੰਮ ਨੂੰ "ਵਾਧੂ" ਮਨਿਆ ਜਾਂਦਾ। ਲੀਡਰਸ਼ਿਪ ਨੂੰ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਓਪਰੇਸ਼ਨਲ ਕਰਜ਼ਾ ਘਟਾਉਣ, ਦੁਹਰਾਉਂਦੇ ਕਾਰਨਾਂ ਨੂੰ ਠੀਕ ਕਰਨ, ਅਤੇ ਖਤਰਨਾਕ ਡਿਪੈਂਡੇਨਸੀਜ਼ ਨੂੰ ਘਟਾਉਣ ਲਈ ਸਮਾਂ ਰਾਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਬਿਨਾਂ ਇਹ ਸੁਰੱਖਿਆ, on-call ਇੱਕ ਟੈਕਸ ਬਣ ਜਾਂਦਾ—ਨਾ ਕਿ ਇੱਕ ਫੀਡਬੈਕ ਲੂਪ ਜੋ ਸਿਸਟਮ ਨੂੰ ਸੁਧਾਰਦਾ ਹੈ।
ਇਸਨੂੰ ਰੋਲ-ਆਉਟ ਕਰਨਾ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਇੱਕ ਕਦਮ-ਦਰ-ਕਦਮ ਬਦਲਾਅ ਹੋ ਕੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਕੰਪਨੀ-ਵਿਆਪਕ ਐਲਾਨ। ਛੋਟੀ ਸ਼ੁਰੂ ਕਰੋ, ਮਲਕੀਅਤ ਦਿੱਖਾਓ, ਅਤੇ ਫਿਰ ਵਧਾਓ।
ਇਕ ਵਧੀਆ-ਬਉਂਡਡ ਸੇਵਾ ਚੁਣੋ (ਅਸਲ ਯੂਜ਼ਰ ਅਤੇ ਸੰਭਾਲਣ ਯੋਗ ਜੋਖਮ ਵਾਲੀ)।
ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ:
ਕੁੰਜੀ: ਜੋ ਟੀਮ ਬਦਲਾਅ ਸ਼ਿਪ ਕਰਦੀ ਹੈ, ਉਹ ਸੇਵਾ ਲਈ ਓਪਰੇਸ਼ਨਲ ਨਤੀਜਿਆਂ ਦੀ ਮਲਕੀਅਤ ਵੀ ਰੱਖਦੀ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਹੋਰ ਸੇਵਾਵਾਂ ਵਿੱਚ ਵਧਦੇ ਹੋ, ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਪਾਇਲਟ ਟੀम ਬਿਨਾਂ ਹੀਰੋਈਕਸ ਦੇ ਚਲ ਸਕਦੀ:
ਛੋਟੀ ਸੰਖਿਆਵਾਰ ਵਰਤੋ ਜੋ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ownership ਸ਼ਿਪਿੰਗ ਅਤੇ ਸਥਿਰਤਾ ਨੂੰ ਸੁਧਾਰ ਰਹੀ ਹੈ:
ਜੇ ਤੁਸੀਂ “ਤੁਸੀਂ ਬਣਾਉਂਦੇ ਹੋ, ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ” ਅਪਣਾਉਂਦੇ ਹੋ ਅਤੇ ਡਿਲਿਵਰੀ ਵੀ ਤੇਜ਼ ਕਰਨੀ ਹੈ, ਤਾਂ ਬੋਟਲਨੈਕ ਅਕਸਰ ਇੱਕੋ ਹੀ ਹੁੰਦਾ: ਵਿਚਾਰ → ਪ੍ਰੋਡਕਸ਼ਨ-ਰੈਡੀ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਵਿੱਚ ਸਮਾਂ ਲੱਗਣਾ ਜਿਸਦੇ ਨਾਲ ਸਪਸ਼ਟ ਮਲਕੀਅਤ ਅਤੇ ਸੇਫ਼ rollback ਦੀ ਯੋਜਨਾ ਹੋਵੇ।
Koder.ai ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਹੈ ਜੋ ਟੀਮਾਂ ਨੂੰ ਚੈਟ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਵੈੱਬ, ਬੈਕਐਂਡ, ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਣ ਵਿੱਚ ਸਹਾਇਤਾ ਕਰਦਾ (React ਵੈੱਬ ਲਈ, Go + PostgreSQL ਬੈਕਐਂਡ ਲਈ, Flutter ਮੋਬਾਈਲ ਲਈ)। ਸੇਵਾ ਮਲਕੀਅਤ ਵਲ ਝੁਕਦੇ ਟੀਮਾਂ ਲਈ ਕੁਝ ਫੀਚਰ operating ਮਾਡਲ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਮੇਲ ਖਾਂਦੇ ਹਨ:
ਇਸ ਹਫ਼ਤੇ ਆਪਣੀ ਪਾਇਲਟ ਸੇਵਾ ਚੁਣੋ ਅਤੇ ਪਹਿਲਾ SLO, on-call ਰੋਟੇਸ਼ਨ, ਅਤੇ runbook ਮਾਲਕ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ 60 ਮਿੰਟ ਦਾ kickoff ਸ਼ੈਡਿਊਲ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਉਪਕਰਨਾਂ ਦੀ ਮੁਲਾਂਕਣ ਕਰ ਰਹੇ ਹੋ ਜੋ ਇਸਨੂੰ ਸਮਰਥਨ ਦੇ ਸਕਦੇ ਹਨ (shipping, rollback, ਅਤੇ ਮਲਕੀਅਤ-ਆਸੂ-ਗੇਤ workflows), ਤਾੰ Koder.ai ਦੇ /pricing ਨੂੰ ਦੇਖੋ ਤਾਂ ਜੋ free, pro, business, ਅਤੇ enterprise tiyars ਅਤੇ hosting, deployment, ਅਤੇ custom domains ਜ਼ੈਸੀਆਂ ਵਿਕਲਪਾਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਮਿਲੇ।
ਇਸਦਾ ਮਤਲਬ ਏਹ ਹੈ ਕਿ ਜੋ ਟੀਮ ਸੇਵਾ ਡਿਜ਼ਾਈਨ, ਬਣਾਉਂਦੀ ਅਤੇ ਡਿਪਲੋਏ ਕਰਦੀ ਹੈ ਉਹ ਜ਼ਿੰਮੇਵਾਰ ਵੀ ਰਹਿੰਦੀ ਹੈ ਕਿ ਲਾਈਵ ਹੋਣ ਤੋਂ ਬਾਅਦ ਕੀ ਹੁੰਦਾ ਹੈ: ਮਾਨੀਟਰਿੰਗ, ਆਨ-ਕਾਲ ਜਵਾਬ, ਘਟਨਾ ਦੇ ਫੋਲੋ-ਅਪ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਵਿੱਚ ਸੁਧਾਰ।
ਇਹ ਇੱਕ ਜ਼ਿੰਮੇਵਾਰੀ ਮਾਡਲ ਹੈ (ਸਾਫ਼ ਮਲਕੀਅਤ), ਕੋਈ ਸਿਰਫ ਇੱਕ ਟੂਲ ਚੋਣ ਜਾਂ ਨੌਕਰੀ ਦਾ ਸਿਰਫ਼ ਸਿਰਲੇਖ ਬਦਲਣਾ ਨਹੀਂ।
ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਹਰ ਇੰਜੀਨੀਅਰ ਨੂੰ ਪੂਰੇ ਸਮੇਂ ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਨਿਪੁੰਨ ਬਣਨਾ ਪਏਗਾ।
ਇਸਦਾ ਮਤਲਬ ਹੈ:
ਅਲੱਗ ops ਟੀਮ ਨਾਲ, ਫੀਡਬੈਕ ਦੇਰੀ ਨਾਲ ਮਿਲਦਾ ਹੈ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀ ਧੁੰਦਲੀ ਹੋ ਜਾਂਦੀ ਹੈ: ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਦਰਦ ਮਹਿਸੂਸ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ops ਕੋਲ ਹਾਲੀਆ ਬਦਲਾਵਾਂ ਦਾ ਸੰਦਰਭ ਨਹੀਂ ਹੁੰਦਾ।
ਏਂਡ-ਟੂ-ਏਂਡ ਮਲਕੀਅਤ ਆਮ ਤੌਰ 'ਤੇ ਸੁਧਾਰ ਲਿਆਉਂਦੀ ਹੈ:
“Run it” ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ:
ਮਨੁੱਖੀ ਤੌਰ 'ਤੇ ਠੀਕ on-call ਬਣਾਉਣ ਲਈ ਬਹੁਤ ਕੁਝ ਪੇਸ਼ਗੀ ਅਤੇ ਸਮਰਥਨ ਬਾਰੇ ਹੈ।
ਅਸਲ ਲਕਸ਼্য: ਅਗਲੇ ਮਹੀਨੇ ਘੱਟ ਪੇਜ ਹੋਣ—on-call ਨੂੰ ਇਕ ਸਜ਼ਾ ਨਹੀਂ ਬਣਣ ਦੇਣਾ।
ਸਧਾਰਨ ਨਿਯਮ: ਜੇ ਕਿਸੇ ਨੂੰ ਜਗਾਉਣਾ ਨਤੀਜੇ ਨੂੰ ਬਦਲਣ ਵਾਲਾ ਨਹੀਂ, ਤਾਂ ਇਹ ਟਿਕਟ ਬਣਾਉ, ਪੇਜ ਨਹੀਂ।
ਅਮਲੀ ਤੌਰ 'ਤੇ:
ਇਹ ਉਨ੍ਹਾਂ ਨੂੰ ਸਾਂਝਾ, ਮਾਪਯੋਗ ਭਰੋਸੇਯੋਗਤਾ ਟਾਰਗਟ ਦਿੰਦੇ ਹਨ:
ਜਦੋਂ ਬਜਟ ਜ਼ਿਆਦਾ ਖਰਚ ਹੋ ਰਿਹਾ ਹੋਵੇ, ਉੱਪਰਤਾ ਕੰਮ ਪ੍ਰਾਥਮਿਕਤਾ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ; ਜਦੋਂ ਬਜਟ ਸਿਹਤਮੰਦ ਹੋਵੇ ਤਦ ਟੀਮ ਜ਼ਿਆਦਾ ਫੀਚਰ ਰਿਸਕ ਲੈ ਸਕਦੀ ਹੈ।
ਉਹ ਰੀਲਜ਼ ਅਮਲੀਆਂ ਜੋ ਅਣਜਾਣੀ ਅਸਰ ਘਟਾਉਂਦੀਆਂ ਹਨ:
ਘਟਨਾਵਾਂ ਉਹ ਜਗ੍ਹਾ ਹਨ ਜਿੱਥੇ “ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ” ਅਸਲ ਬਣਦਾ ਹੈ: ਸੇਵਾ ਖਰਾਬ ਹੁੰਦੀ ਹੈ, ਗਾਹਕ ਨੋਟਿਸ ਕਰਦੇ ਹਨ, ਅਤੇ ਟੀਮ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਸਾਫ਼ ਜਵਾਬ ਦੇਣਾ ਪੈਂਦਾ ਹੈ। ਲਕਸ਼্য ਹੀਰੋਈਕਸ ਨਹੀਂ—ਇੱਕ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲਾ ਵਰਕਫਲੋ ਹੈ ਜੋ ਅਸਰ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਸੁਧਾਰ ਲਿਆਉਂਦਾ ਹੈ।
ਸਧਾਰਨ ਘਟਨਾ ਵਰਕਫਲੋ:
ਬ্লੇਮਲੈੱਸ ਪੋਸਟਮੋਰਟਮ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ “ਕਿਸੇ ਨੇ ਗਲਤੀ ਨਹੀਂ ਕੀਤੀ।” ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸ ਗੱਲ 'ਤੇ ਧਿਆਨ ਦਿੰਦੇ ਹੋ ਕਿ ਸਿਸਟਮ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਨੇ ਗਲਤੀ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਣ ਦਿੱਤਾ—ਨ ਕਿ ਵਿਅਕਤੀ ਨੂੰ ਸ਼ਰਮਿੰਦਾ ਕਰਨ 'ਤੇ। ਇਸ ਨਾਲ ਲੋਕ ਜਲਦੀ ਵਿਸਥਾਰ ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਜੋ ਸਿੱਖਣ ਲਈ ਲਾਜ਼ਮੀ ਹੈ।
ਦਸਤਾਵੇਜ਼:
ਟੂਲਿੰਗ ਉਹ leverage ਹੈ ਜੋ “You Build It, You Run It” ਨੂੰ ਟਿਕਾਊ ਬਣਾਉਂਦੀ—ਪਰ ਇਹ ਅਸਲੀ ਮਲਕੀਅਤ ਦੀ ਜਗ੍ਹਾ ਨਹੀਂ ਲੈ ਸਕਦੀ। ਚੰਗੇ ਟੂਲ friction ਘਟਾਉਂਦੇ ਹਨ: ਸਹੀ ਚੀਜ਼ (ਨਿਰੀਖਣ, ਜਵਾਬ, ਸਿੱਖਣਾ) ਕਰਨ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣ ਲਈ।
ਹਰ ਟੀਮ ਲਈ ਘੱਟੋ-ਘੱਟ:
ਪਲੇਟਫਾਰਮ ਟੀਮਾਂ “You Build It, You Run It” ਨੂੰ ਜਿਉਂਦਾ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ। ਉਨ੍ਹਾਂ ਦਾ ਕੰਮ ਹਰ ਕਿਸੇ ਲਈ ਪ੍ਰੋਡਕਸ਼ਨ ਚਲਾਉਣਾ ਨਹੀਂ—ਬਲਕਿ ਇੱਕ ਚੰਗਾ ਰਸਤਾ ਮੁਹੱਈਆ ਕਰਵਾਉਣਾ ਹੈ ਤਾਂ ਜੋ ਪ੍ਰੋਡਕਟ ਟੀਮਾਂ ਹਰ ਸਪ੍ਰਿੰਟ 'ਚ ops ਦੁਬਾਰਾ ਖੋਜਣ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਪੈਂਦੀ।
ਅਭਿਆਸ:
ਬਾਊਂਡਰੀ: ਪਲੇਟਫਾਰਮ ਟੀਮ ਪਲੇਟਫਾਰਮ ਦੀ uptime ਅਤੇ ਸਹਾਇਤਾ ਦੀ ਮਲਕੀਅਤ ਰੱਖੇ; ਪ੍ਰੋਡਕਟ ਟੀਮਾਂ ਆਪਣੀਆਂ ਸੇਵਾਵਾਂ ਦੀ reliability/ਪ੍ਰਦਰਸ਼ਨ/ਲਾਗਤ ਦੀ ਮਲਕੀਅਤ ਰੱਖਣ।
ਕਈ ਵਾਰ ਨੀਤੀਆਂ ਅਪਣਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ ਪਰ ਸਹਾਇਕ ਆਦਤਾਂ ਨਹੀਂ—ਇਸ ਕਰਕੇ ਨਾਕਾਮੀ ਹੁੰਦੀ ਹੈ। ਕੁਝ ਆਮ ਨੁਕਸ:
ਅਨੁਕੂਲਨ:
ਇੱਕ ਪ੍ਰਯੋਗਸ਼ੀਲ ਟੈਂਪਲੇਟ ਲਈ ਹਲਕਾ ਚੈਕਲਿਸਟ ਰੱਖੋ (ਵੇਖੋ /blog/incident-response-checklist).
ਚੰਗੇ postmortems concrete follow-ups ਨਾਲ ਖਤਮ ਹੋਣ: ਟੂਲਿੰਗ ਸੁਧਾਰ, ਟੈਸਟ, ਆਟੋਮੇਸ਼ਨ, ਅਤੇ ਦਸਤਾਵੇਜ਼ (runbooks), ਹਰ ਇਕ ਆਈਟਮ ਇੱਕ ਮਾਲਕ ਅਤੇ ਨਤੀਜੇ ਲਈ ਮਿਆਦ ਨਾਲ।
ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ ownership ਦਿੱਖਾਉਣ ਲਈ ਇੱਕ service catalog/ਅੰਦਰੂਨੀ developer portal ਰੱਖੋ: ਟੀਮ ਨਾਮ, on-call ਰੋਟੇਸ਼ਨ, ਐਸਕਲੇਸ਼ਨ ਪਾਥ, runbooks, ਡੈਪੈਂਡਨਸੀਜ਼ ਅਤੇ ਡੈਸ਼ਬੋਰਡ ਲਿੰਕ।
ਲੀਡਰਸ਼ਿਪ ਦਾ ਕੰਮ: reliability ਲਈ ਸਮਰੱਥਾ ਨੂੰ ਰੱਖਣਾ—ਓਪਰੇਸ਼ਨਲ ਕਰਜ਼ਾ ਘਟਾਉਣ, ਦੁਹਰਾਉਂਦੇ ਕਾਰਨਾਂ ਨੂੰ ਠੀਕ ਕਰਨ ਅਤੇ ਖਤਰਨਾਕ ਡਿਪੈਂਡੇਨਸੀਜ਼ ਨੂੰ ਘਟਾਉਣ ਲਈ ਸਮਾਂ ਰੱਖੋ।