ਡਿਵੈਲਪਰ ਮੰਗਲ ਤੋਂ ਹਨ, ਪ੍ਰਸ਼ਾਸਕ ਵੀਨਸ ਤੋਂ ਹਨ

ਇਤਫ਼ਾਕ ਬੇਤਰਤੀਬੇ ਹਨ, ਅਤੇ ਅਸਲ ਵਿੱਚ ਇਹ ਕਿਸੇ ਹੋਰ ਗ੍ਰਹਿ 'ਤੇ ਸੀ ...

ਮੈਂ ਇਸ ਬਾਰੇ ਤਿੰਨ ਸਫਲਤਾ ਅਤੇ ਅਸਫਲਤਾ ਦੀਆਂ ਕਹਾਣੀਆਂ ਸਾਂਝੀਆਂ ਕਰਨਾ ਚਾਹਾਂਗਾ ਕਿ ਕਿਵੇਂ ਇੱਕ ਬੈਕਐਂਡ ਡਿਵੈਲਪਰ ਪ੍ਰਬੰਧਕਾਂ ਦੇ ਨਾਲ ਇੱਕ ਟੀਮ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ।

ਕਹਾਣੀ ਇੱਕ.
ਵੈੱਬ ਸਟੂਡੀਓ, ਕਰਮਚਾਰੀਆਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਇੱਕ ਹੱਥ ਨਾਲ ਗਿਣਿਆ ਜਾ ਸਕਦਾ ਹੈ. ਅੱਜ ਤੁਸੀਂ ਇੱਕ ਲੇਆਉਟ ਡਿਜ਼ਾਈਨਰ ਹੋ, ਕੱਲ੍ਹ ਤੁਸੀਂ ਇੱਕ ਬੈਕਐਂਡਰ ਹੋ, ਕੱਲ੍ਹ ਤੁਸੀਂ ਇੱਕ ਐਡਮਿਨ ਹੋ। ਇੱਕ ਪਾਸੇ, ਤੁਸੀਂ ਬਹੁਤ ਵਧੀਆ ਅਨੁਭਵ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ। ਦੂਜੇ ਪਾਸੇ ਸਾਰੇ ਖੇਤਰਾਂ ਵਿੱਚ ਯੋਗਤਾ ਦੀ ਘਾਟ ਹੈ। ਮੈਨੂੰ ਅਜੇ ਵੀ ਕੰਮ ਦਾ ਪਹਿਲਾ ਦਿਨ ਯਾਦ ਹੈ, ਮੈਂ ਅਜੇ ਵੀ ਹਰਾ ਹਾਂ, ਬੌਸ ਕਹਿੰਦਾ ਹੈ: "ਓਪਨ ਪੁਟੀ," ਪਰ ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਇਹ ਕੀ ਹੈ। ਪ੍ਰਸ਼ਾਸਕਾਂ ਨਾਲ ਸੰਚਾਰ ਨੂੰ ਬਾਹਰ ਰੱਖਿਆ ਗਿਆ ਹੈ, ਕਿਉਂਕਿ ਤੁਸੀਂ ਖੁਦ ਐਡਮਿਨ ਹੋ। ਆਓ ਇਸ ਸਥਿਤੀ ਦੇ ਫਾਇਦੇ ਅਤੇ ਨੁਕਸਾਨਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰੀਏ.

+ ਸਾਰੀ ਸ਼ਕਤੀ ਤੁਹਾਡੇ ਹੱਥ ਵਿੱਚ ਹੈ।
+ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚ ਲਈ ਕਿਸੇ ਤੋਂ ਭੀਖ ਮੰਗਣ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ।
+ ਸਾਰੀਆਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਤੇਜ਼ ਪ੍ਰਤੀਕ੍ਰਿਆ ਸਮਾਂ.
+ ਹੁਨਰਾਂ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੁਧਾਰਦਾ ਹੈ.
+ ਉਤਪਾਦ ਆਰਕੀਟੈਕਚਰ ਦੀ ਪੂਰੀ ਸਮਝ ਰੱਖੋ।

- ਉੱਚ ਜ਼ਿੰਮੇਵਾਰੀ.
- ਉਤਪਾਦਨ ਨੂੰ ਤੋੜਨ ਦਾ ਜੋਖਮ.
- ਸਾਰੇ ਖੇਤਰਾਂ ਵਿੱਚ ਇੱਕ ਚੰਗਾ ਮਾਹਰ ਬਣਨਾ ਮੁਸ਼ਕਲ ਹੈ।

ਕੋਈ ਦਿਲਚਸਪੀ ਨਹੀਂ, ਆਓ ਅੱਗੇ ਵਧੀਏ

ਦੂਜੀ ਕਹਾਣੀ।
ਵੱਡੀ ਕੰਪਨੀ, ਵੱਡਾ ਪ੍ਰੋਜੈਕਟ. 5-7 ਕਰਮਚਾਰੀ ਅਤੇ ਕਈ ਵਿਕਾਸ ਗਰੁੱਪਾਂ ਵਾਲਾ ਪ੍ਰਸ਼ਾਸਨ ਵਿਭਾਗ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਅਜਿਹੀ ਕੰਪਨੀ ਵਿੱਚ ਕੰਮ ਕਰਨ ਆਉਂਦੇ ਹੋ, ਤਾਂ ਹਰ ਐਡਮਿਨ ਸੋਚਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਥੇ ਕਿਸੇ ਉਤਪਾਦ 'ਤੇ ਕੰਮ ਕਰਨ ਨਹੀਂ ਆਏ, ਬਲਕਿ ਕੁਝ ਤੋੜਨ ਲਈ ਆਏ ਹੋ। ਨਾ ਤਾਂ ਦਸਤਖਤ ਕੀਤੇ ਐਨਡੀਏ ਅਤੇ ਨਾ ਹੀ ਇੰਟਰਵਿਊ ਵਿੱਚ ਚੋਣ ਹੋਰ ਸੰਕੇਤ ਕਰਦੀ ਹੈ। ਨਹੀਂ, ਇਹ ਆਦਮੀ ਸਾਡੇ ਚੁੰਮਣ ਦੇ ਉਤਪਾਦਨ ਨੂੰ ਬਰਬਾਦ ਕਰਨ ਲਈ ਆਪਣੇ ਗੰਦੇ ਛੋਟੇ ਹੱਥਾਂ ਨਾਲ ਇੱਥੇ ਆਇਆ ਸੀ। ਇਸ ਲਈ, ਅਜਿਹੇ ਵਿਅਕਤੀ ਨਾਲ ਤੁਹਾਨੂੰ ਘੱਟੋ ਘੱਟ ਸੰਚਾਰ ਦੀ ਜ਼ਰੂਰਤ ਹੈ; ਬਹੁਤ ਘੱਟ ਤੋਂ ਘੱਟ, ਤੁਸੀਂ ਜਵਾਬ ਵਿੱਚ ਇੱਕ ਸਟਿੱਕਰ ਸੁੱਟ ਸਕਦੇ ਹੋ. ਪ੍ਰੋਜੈਕਟ ਆਰਕੀਟੈਕਚਰ ਬਾਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਨਾ ਦਿਓ। ਇਹ ਸਲਾਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਜਦੋਂ ਤੱਕ ਟੀਮ ਲੀਡ ਨਹੀਂ ਪੁੱਛਦੀ ਉਦੋਂ ਤੱਕ ਪਹੁੰਚ ਨਾ ਦਿੱਤੀ ਜਾਵੇ। ਅਤੇ ਜਦੋਂ ਉਹ ਮੰਗਦਾ ਹੈ, ਤਾਂ ਉਹ ਇਸ ਨੂੰ ਉਹਨਾਂ ਨਾਲੋਂ ਘੱਟ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰਾਂ ਦੇ ਨਾਲ ਵਾਪਸ ਦੇਵੇਗਾ ਜੋ ਉਹਨਾਂ ਨੇ ਮੰਗਿਆ ਸੀ। ਅਜਿਹੇ ਪ੍ਰਬੰਧਕਾਂ ਨਾਲ ਲਗਭਗ ਸਾਰਾ ਸੰਚਾਰ ਵਿਕਾਸ ਵਿਭਾਗ ਅਤੇ ਪ੍ਰਸ਼ਾਸਨ ਵਿਭਾਗ ਦੇ ਵਿਚਕਾਰ ਕਾਲੇ ਮੋਰੀ ਦੁਆਰਾ ਲੀਨ ਹੋ ਜਾਂਦਾ ਹੈ। ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਤੁਰੰਤ ਹੱਲ ਕਰਨਾ ਅਸੰਭਵ ਹੈ। ਪਰ ਤੁਸੀਂ ਵਿਅਕਤੀਗਤ ਤੌਰ 'ਤੇ ਨਹੀਂ ਆ ਸਕਦੇ - ਪ੍ਰਸ਼ਾਸਕ 24/7 ਬਹੁਤ ਵਿਅਸਤ ਹਨ। (ਤੁਸੀਂ ਹਰ ਸਮੇਂ ਕੀ ਕਰ ਰਹੇ ਹੋ?) ਕੁਝ ਪ੍ਰਦਰਸ਼ਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ:

• ਉਤਪਾਦਨ ਲਈ ਔਸਤ ਤੈਨਾਤੀ ਸਮਾਂ 4-5 ਘੰਟੇ ਹੈ
• ਉਤਪਾਦਨ ਵਿੱਚ ਅਧਿਕਤਮ ਤੈਨਾਤੀ ਸਮਾਂ 9 ਘੰਟੇ
• ਇੱਕ ਡਿਵੈਲਪਰ ਲਈ, ਉਤਪਾਦਨ ਵਿੱਚ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਬਲੈਕ ਬਾਕਸ ਹੈ, ਜਿਵੇਂ ਕਿ ਉਤਪਾਦਨ ਸਰਵਰ ਆਪਣੇ ਆਪ ਵਿੱਚ। ਕੁੱਲ ਕਿੰਨੇ ਹਨ?
• ਰੀਲੀਜ਼ਾਂ ਦੀ ਘੱਟ ਕੁਆਲਿਟੀ, ਅਕਸਰ ਗਲਤੀਆਂ
• ਡਿਵੈਲਪਰ ਰੀਲੀਜ਼ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਹਿੱਸਾ ਨਹੀਂ ਲੈਂਦਾ

ਖੈਰ, ਮੈਂ ਕੀ ਉਮੀਦ ਕੀਤੀ ਸੀ, ਬੇਸ਼ਕ, ਨਵੇਂ ਲੋਕਾਂ ਨੂੰ ਉਤਪਾਦਨ ਵਿੱਚ ਆਗਿਆ ਨਹੀਂ ਹੈ. ਠੀਕ ਹੈ, ਧੀਰਜ ਹਾਸਲ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਦੂਜਿਆਂ ਦਾ ਭਰੋਸਾ ਹਾਸਲ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹਾਂ। ਪਰ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ, ਪ੍ਰਸ਼ਾਸਕਾਂ ਨਾਲ ਚੀਜ਼ਾਂ ਇੰਨੀਆਂ ਸਰਲ ਨਹੀਂ ਹਨ।

ਐਕਟ 1. ਐਡਮਿਨ ਅਦਿੱਖ ਹੈ।
ਰਿਲੀਜ਼ ਦਿਨ, ਡਿਵੈਲਪਰ ਅਤੇ ਐਡਮਿਨ ਸੰਚਾਰ ਨਹੀਂ ਕਰਦੇ ਹਨ। ਪ੍ਰਸ਼ਾਸਕ ਕੋਲ ਕੋਈ ਸਵਾਲ ਨਹੀਂ ਹਨ। ਪਰ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਸਮਝਦੇ ਹੋ ਕਿ ਕਿਉਂ. ਪ੍ਰਸ਼ਾਸਕ ਇੱਕ ਸਿਧਾਂਤਕ ਵਿਅਕਤੀ ਹੈ, ਉਸ ਕੋਲ ਮੈਸੇਂਜਰ ਨਹੀਂ ਹਨ, ਕਿਸੇ ਨੂੰ ਆਪਣਾ ਫ਼ੋਨ ਨੰਬਰ ਨਹੀਂ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਸੋਸ਼ਲ ਨੈਟਵਰਕਸ 'ਤੇ ਕੋਈ ਪ੍ਰੋਫਾਈਲ ਨਹੀਂ ਹੈ। ਉਸ ਦੀ ਕਿਤੇ ਵੀ ਫੋਟੋ ਨਹੀਂ ਹੈ, ਤੁਸੀਂ ਕਿਹੋ ਜਿਹੇ ਲੱਗ ਰਹੇ ਹੋ ਯਾਰ? ਅਸੀਂ ਇਸ ਵੋਏਜਰ 15 ਨਾਲ ਸੰਚਾਰ ਸਥਾਪਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋਏ, ਘਬਰਾਹਟ ਵਿੱਚ ਲਗਭਗ 1 ਮਿੰਟ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਮੈਨੇਜਰ ਨਾਲ ਬੈਠਦੇ ਹਾਂ, ਫਿਰ ਕਾਰਪੋਰੇਟ ਈਮੇਲ ਵਿੱਚ ਇੱਕ ਸੁਨੇਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਜੋ ਉਸਨੇ ਪੂਰਾ ਕਰ ਲਿਆ ਹੈ। ਕੀ ਅਸੀਂ ਡਾਕ ਰਾਹੀਂ ਪੱਤਰ ਵਿਹਾਰ ਕਰਨ ਜਾ ਰਹੇ ਹਾਂ? ਕਿਉਂ ਨਹੀਂ? ਸੁਵਿਧਾਜਨਕ, ਹੈ ਨਾ? ਠੀਕ ਹੈ, ਆਓ ਠੰਡਾ ਕਰੀਏ। ਪ੍ਰਕਿਰਿਆ ਪਹਿਲਾਂ ਹੀ ਚੱਲ ਰਹੀ ਹੈ, ਪਿੱਛੇ ਮੁੜਨ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ। ਸੁਨੇਹੇ ਨੂੰ ਦੁਬਾਰਾ ਪੜ੍ਹੋ। "ਮੈਂ ਖਤਮ ਕਰ ਦਿੱਤਾ". ਤੁਸੀਂ ਕੀ ਖਤਮ ਕੀਤਾ? ਕਿੱਥੇ? ਮੈਂ ਤੁਹਾਨੂੰ ਕਿੱਥੇ ਲੱਭਾਂ? ਇੱਥੇ ਤੁਸੀਂ ਸਮਝਦੇ ਹੋ ਕਿ ਰਿਲੀਜ਼ ਲਈ 4 ਘੰਟੇ ਆਮ ਕਿਉਂ ਹਨ. ਸਾਨੂੰ ਵਿਕਾਸ ਦਾ ਝਟਕਾ ਮਿਲਦਾ ਹੈ, ਪਰ ਅਸੀਂ ਰਿਲੀਜ਼ ਨੂੰ ਖਤਮ ਕਰਦੇ ਹਾਂ. ਛੱਡਣ ਦੀ ਹੁਣ ਕੋਈ ਇੱਛਾ ਨਹੀਂ ਰਹੀ।

ਐਕਟ 2. ਉਹ ਸੰਸਕਰਣ ਨਹੀਂ।
ਅਗਲੀ ਰਿਲੀਜ਼। ਅਨੁਭਵ ਪ੍ਰਾਪਤ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਪ੍ਰਬੰਧਕਾਂ ਲਈ ਸਰਵਰ ਲਈ ਲੋੜੀਂਦੇ ਸੌਫਟਵੇਅਰ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਸੂਚੀ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ, ਕੁਝ ਦੇ ਸੰਸਕਰਣਾਂ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹੋਏ. ਹਮੇਸ਼ਾ ਵਾਂਗ, ਸਾਨੂੰ ਇੱਕ ਕਮਜ਼ੋਰ ਰੇਡੀਓ ਸਿਗਨਲ ਮਿਲਦਾ ਹੈ ਕਿ ਪ੍ਰਸ਼ਾਸਕ ਨੇ ਉੱਥੇ ਕੁਝ ਪੂਰਾ ਕਰ ਲਿਆ ਹੈ। ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇੱਕ ਘੰਟਾ ਲੱਗਦਾ ਹੈ। ਸਭ ਕੁਝ ਕੰਮ ਕਰ ਰਿਹਾ ਜਾਪਦਾ ਹੈ, ਪਰ ਇੱਕ ਗੰਭੀਰ ਬੱਗ ਹੈ। ਮਹੱਤਵਪੂਰਨ ਕਾਰਜਕੁਸ਼ਲਤਾ ਕੰਮ ਨਹੀਂ ਕਰਦੀ। ਅਗਲੇ ਕੁਝ ਘੰਟੇ ਡੱਬੂਆਂ ਨਾਲ ਨੱਚ ਰਹੇ ਸਨ, ਕੌਫੀ ਦੇ ਮੈਦਾਨਾਂ 'ਤੇ ਭਵਿੱਖ-ਦੱਸ ਰਹੇ ਸਨ, ਅਤੇ ਕੋਡ ਦੇ ਹਰੇਕ ਹਿੱਸੇ ਦੀ ਵਿਸਤ੍ਰਿਤ ਸਮੀਖਿਆ ਸੀ। ਐਡਮਿਨ ਕਹਿੰਦਾ ਹੈ ਕਿ ਉਸਨੇ ਸਭ ਕੁਝ ਕੀਤਾ ਹੈ। ਟੇਢੇ ਡਿਵੈਲਪਰਾਂ ਦੁਆਰਾ ਲਿਖੀ ਗਈ ਐਪਲੀਕੇਸ਼ਨ ਕੰਮ ਨਹੀਂ ਕਰਦੀ, ਪਰ ਸਰਵਰ ਕੰਮ ਕਰਦਾ ਹੈ. ਉਸ ਲਈ ਕੋਈ ਸਵਾਲ? ਇੱਕ ਘੰਟੇ ਦੇ ਅੰਤ ਵਿੱਚ, ਅਸੀਂ ਪ੍ਰਸ਼ਾਸਕ ਨੂੰ ਉਤਪਾਦਨ ਸਰਵਰ 'ਤੇ ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਸੰਸਕਰਣ ਨੂੰ ਚੈਟ ਅਤੇ ਬਿੰਗੋ ਵਿੱਚ ਭੇਜਣ ਲਈ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ - ਇਹ ਉਹ ਨਹੀਂ ਹੈ ਜਿਸਦੀ ਸਾਨੂੰ ਲੋੜ ਹੈ। ਅਸੀਂ ਪ੍ਰਬੰਧਕ ਨੂੰ ਲੋੜੀਂਦੇ ਸੰਸਕਰਣ ਨੂੰ ਸਥਾਪਤ ਕਰਨ ਲਈ ਕਹਿੰਦੇ ਹਾਂ, ਪਰ ਜਵਾਬ ਵਿੱਚ ਅਸੀਂ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ ਕਿ ਉਹ OS ਪੈਕੇਜ ਮੈਨੇਜਰ ਵਿੱਚ ਇਸ ਸੰਸਕਰਣ ਦੀ ਅਣਹੋਂਦ ਕਾਰਨ ਅਜਿਹਾ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਥੇ, ਉਸਦੀ ਯਾਦਦਾਸ਼ਤ ਦੇ ਵਿਗਾੜਾਂ ਤੋਂ, ਮੈਨੇਜਰ ਨੂੰ ਯਾਦ ਹੈ ਕਿ ਇੱਕ ਹੋਰ ਪ੍ਰਸ਼ਾਸਕ ਨੇ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਹੱਥ ਨਾਲ ਲੋੜੀਂਦੇ ਸੰਸਕਰਣ ਨੂੰ ਇਕੱਠਾ ਕਰਕੇ ਹੱਲ ਕਰ ਦਿੱਤਾ ਸੀ। ਪਰ ਨਹੀਂ, ਸਾਡਾ ਅਜਿਹਾ ਨਹੀਂ ਹੋਵੇਗਾ। ਨਿਯਮ ਮਨਾਹੀ ਕਰਦੇ ਹਨ। ਕਾਰਲ, ਅਸੀਂ ਇੱਥੇ ਕਈ ਘੰਟਿਆਂ ਤੋਂ ਬੈਠੇ ਹਾਂ, ਸਮਾਂ ਸੀਮਾ ਕੀ ਹੈ ?! ਸਾਨੂੰ ਇੱਕ ਹੋਰ ਝਟਕਾ ਮਿਲਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਤਰ੍ਹਾਂ ਰੀਲੀਜ਼ ਨੂੰ ਪੂਰਾ ਕਰਦੇ ਹਾਂ.

ਐਕਟ 3, ਛੋਟਾ
ਜ਼ਰੂਰੀ ਟਿਕਟ, ਕੁੰਜੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਉਤਪਾਦਨ ਵਿੱਚ ਉਪਭੋਗਤਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਲਈ ਕੰਮ ਨਹੀਂ ਕਰਦੀ। ਅਸੀਂ ਕੁਝ ਘੰਟੇ ਟੋਕਣ ਅਤੇ ਜਾਂਚ ਕਰਨ ਵਿਚ ਬਿਤਾਉਂਦੇ ਹਾਂ. ਵਿਕਾਸ ਦੇ ਮਾਹੌਲ ਵਿੱਚ, ਸਭ ਕੁਝ ਕੰਮ ਕਰਦਾ ਹੈ. ਇੱਕ ਸਪੱਸ਼ਟ ਸਮਝ ਹੈ ਕਿ php-fpm ਲੌਗਸ ਨੂੰ ਦੇਖਣਾ ਇੱਕ ਚੰਗਾ ਵਿਚਾਰ ਹੋਵੇਗਾ। ਉਸ ਸਮੇਂ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ELK ਜਾਂ Prometheus ਵਰਗੇ ਕੋਈ ਲੌਗ ਸਿਸਟਮ ਨਹੀਂ ਸਨ। ਅਸੀਂ ਪ੍ਰਸ਼ਾਸਨ ਵਿਭਾਗ ਨੂੰ ਇੱਕ ਟਿਕਟ ਖੋਲ੍ਹਦੇ ਹਾਂ ਤਾਂ ਜੋ ਉਹ ਸਰਵਰ 'ਤੇ php-fpm ਲੌਗਸ ਤੱਕ ਪਹੁੰਚ ਦੇ ਸਕਣ। ਇੱਥੇ ਤੁਹਾਨੂੰ ਇਹ ਸਮਝਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਅਸੀਂ ਇੱਕ ਕਾਰਨ ਕਰਕੇ ਪਹੁੰਚ ਦੀ ਮੰਗ ਕਰ ਰਹੇ ਹਾਂ, ਕੀ ਤੁਹਾਨੂੰ ਬਲੈਕ ਹੋਲ ਅਤੇ ਪ੍ਰਬੰਧਕਾਂ ਦੇ 24/7 ਵਿਅਸਤ ਰਹਿਣ ਬਾਰੇ ਯਾਦ ਨਹੀਂ ਹੈ? ਜੇਕਰ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਲੌਗਸ ਨੂੰ ਖੁਦ ਦੇਖਣ ਲਈ ਕਹਿੰਦੇ ਹੋ, ਤਾਂ ਇਹ "ਇਸ ਜੀਵਨ ਵਿੱਚ ਨਹੀਂ" ਤਰਜੀਹ ਵਾਲਾ ਕੰਮ ਹੈ। ਟਿਕਟ ਬਣਾਈ ਗਈ ਸੀ, ਸਾਨੂੰ ਪ੍ਰਸ਼ਾਸਨ ਵਿਭਾਗ ਦੇ ਮੁਖੀ ਤੋਂ ਤੁਰੰਤ ਜਵਾਬ ਮਿਲਿਆ: "ਤੁਹਾਨੂੰ ਉਤਪਾਦਨ ਲੌਗਸ ਤੱਕ ਪਹੁੰਚ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ, ਬਗ ਤੋਂ ਬਿਨਾਂ ਲਿਖੋ।" ਇੱਕ ਪਰਦਾ.

ਐਕਟ 4 ਅਤੇ ਇਸ ਤੋਂ ਅੱਗੇ
ਅਸੀਂ ਅਜੇ ਵੀ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੇ ਵੱਖ-ਵੱਖ ਸੰਸਕਰਣਾਂ, ਗੈਰ-ਸੰਰਚਿਤ ਸੌਫਟਵੇਅਰ, ਅਣ-ਤਿਆਰ ਸਰਵਰ ਲੋਡ, ਅਤੇ ਹੋਰ ਸਮੱਸਿਆਵਾਂ ਦੇ ਕਾਰਨ ਉਤਪਾਦਨ ਵਿੱਚ ਦਰਜਨਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰ ਰਹੇ ਹਾਂ। ਬੇਸ਼ੱਕ, ਇੱਥੇ ਕੋਡ ਬੱਗ ਵੀ ਹਨ, ਅਸੀਂ ਸਾਰੇ ਪਾਪਾਂ ਲਈ ਪ੍ਰਬੰਧਕਾਂ ਨੂੰ ਦੋਸ਼ੀ ਨਹੀਂ ਠਹਿਰਾਵਾਂਗੇ, ਅਸੀਂ ਉਸ ਪ੍ਰੋਜੈਕਟ ਲਈ ਸਿਰਫ਼ ਇੱਕ ਹੋਰ ਆਮ ਕਾਰਵਾਈ ਦਾ ਜ਼ਿਕਰ ਕਰਾਂਗੇ। ਸਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਪਿਛੋਕੜ ਵਾਲੇ ਕਰਮਚਾਰੀ ਸਨ ਜੋ ਸੁਪਰਵਾਈਜ਼ਰ ਦੁਆਰਾ ਲਾਂਚ ਕੀਤੇ ਗਏ ਸਨ, ਅਤੇ ਕੁਝ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਕ੍ਰੋਨ ਵਿੱਚ ਜੋੜਨਾ ਪਿਆ ਸੀ। ਕਈ ਵਾਰ ਇਹੀ ਕਾਮੇ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ। ਕਤਾਰ ਸਰਵਰ 'ਤੇ ਲੋਡ ਬਿਜਲੀ ਦੀ ਗਤੀ ਨਾਲ ਵਧਿਆ, ਅਤੇ ਉਦਾਸ ਉਪਭੋਗਤਾ ਸਪਿਨਿੰਗ ਲੋਡਰ ਵੱਲ ਵੇਖ ਰਹੇ ਸਨ. ਅਜਿਹੇ ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਜਲਦੀ ਠੀਕ ਕਰਨ ਲਈ, ਉਹਨਾਂ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨਾ ਕਾਫ਼ੀ ਸੀ, ਪਰ ਦੁਬਾਰਾ, ਸਿਰਫ ਇੱਕ ਪ੍ਰਬੰਧਕ ਹੀ ਅਜਿਹਾ ਕਰ ਸਕਦਾ ਹੈ. ਜਦੋਂ ਅਜਿਹਾ ਮੁੱਢਲਾ ਆਪ੍ਰੇਸ਼ਨ ਕੀਤਾ ਜਾ ਰਿਹਾ ਸੀ, ਤਾਂ ਪੂਰਾ ਦਿਨ ਲੰਘ ਸਕਦਾ ਸੀ। ਇੱਥੇ, ਬੇਸ਼ੱਕ, ਇਹ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ ਟੇਢੇ ਪ੍ਰੋਗਰਾਮਰਾਂ ਨੂੰ ਕਾਮਿਆਂ ਨੂੰ ਲਿਖਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਉਹ ਕਰੈਸ਼ ਨਾ ਹੋਣ, ਪਰ ਜਦੋਂ ਉਹ ਡਿੱਗ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਇਹ ਸਮਝਣਾ ਚੰਗਾ ਹੋਵੇਗਾ ਕਿ ਕਿਉਂ, ਜੋ ਕਿ ਉਤਪਾਦਨ ਤੱਕ ਪਹੁੰਚ ਦੀ ਘਾਟ ਕਾਰਨ ਕਈ ਵਾਰ ਅਸੰਭਵ ਹੁੰਦਾ ਹੈ, ਕੋਰਸ, ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ ਡਿਵੈਲਪਰ ਤੋਂ ਲੌਗਸ ਦੀ ਘਾਟ.

ਪਰਿਵਰਤਨ.
ਇਹ ਸਭ ਕੁਝ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਸਹਿਣ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਟੀਮ ਦੇ ਨਾਲ ਮਿਲ ਕੇ ਉਸ ਦਿਸ਼ਾ ਵੱਲ ਵਧਣਾ ਸ਼ੁਰੂ ਕੀਤਾ ਜੋ ਸਾਡੇ ਲਈ ਵਧੇਰੇ ਸਫਲ ਸੀ। ਸੰਖੇਪ ਵਿੱਚ, ਸਾਨੂੰ ਕਿਹੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਮ੍ਹਣਾ ਕਰਨਾ ਪਿਆ?

• ਡਿਵੈਲਪਰਾਂ ਅਤੇ ਪ੍ਰਸ਼ਾਸਨ ਵਿਭਾਗ ਵਿਚਕਾਰ ਗੁਣਵੱਤਾ ਸੰਚਾਰ ਦੀ ਘਾਟ
• ਪ੍ਰਸ਼ਾਸਕ, ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ(!), ਇਹ ਬਿਲਕੁਲ ਨਹੀਂ ਸਮਝਦੇ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਬਣਤਰ ਕਿਵੇਂ ਹੈ, ਇਸ ਵਿੱਚ ਕੀ ਨਿਰਭਰਤਾ ਹੈ ਅਤੇ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ।
• ਡਿਵੈਲਪਰ ਇਹ ਨਹੀਂ ਸਮਝਦੇ ਕਿ ਉਤਪਾਦਨ ਵਾਤਾਵਰਣ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ, ਸਮੱਸਿਆਵਾਂ ਦਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦਾ।
• ਤੈਨਾਤੀ ਪ੍ਰਕਿਰਿਆ ਬਹੁਤ ਲੰਮਾ ਸਮਾਂ ਲੈਂਦੀ ਹੈ।
• ਅਸਥਿਰ ਰੀਲੀਜ਼।

ਅਸੀਂ ਕੀ ਕੀਤਾ ਹੈ?
ਹਰੇਕ ਰੀਲੀਜ਼ ਲਈ, ਰੀਲੀਜ਼ ਨੋਟਸ ਦੀ ਇੱਕ ਸੂਚੀ ਤਿਆਰ ਕੀਤੀ ਗਈ ਸੀ, ਜਿਸ ਵਿੱਚ ਕੰਮ ਦੀ ਇੱਕ ਸੂਚੀ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ ਜੋ ਕੰਮ ਕਰਨ ਲਈ ਅਗਲੀ ਰੀਲੀਜ਼ ਲਈ ਸਰਵਰ 'ਤੇ ਕੀਤੇ ਜਾਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਸੂਚੀ ਵਿੱਚ ਕਈ ਭਾਗ ਸਨ, ਉਹ ਕੰਮ ਜੋ ਪ੍ਰਸ਼ਾਸਕ, ਰੀਲੀਜ਼ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਵਿਅਕਤੀ ਅਤੇ ਵਿਕਾਸਕਾਰ ਦੁਆਰਾ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ। ਡਿਵੈਲਪਰਾਂ ਨੇ ਸਾਰੇ ਉਤਪਾਦਨ ਸਰਵਰਾਂ ਤੱਕ ਗੈਰ-ਰੂਟ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕੀਤੀ, ਜਿਸ ਨਾਲ ਆਮ ਤੌਰ 'ਤੇ ਵਿਕਾਸ ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨ ਵਿੱਚ ਤੇਜ਼ੀ ਆਈ। ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਇਹ ਵੀ ਸਮਝ ਹੈ ਕਿ ਉਤਪਾਦਨ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਸਨੂੰ ਕਿਹੜੀਆਂ ਸੇਵਾਵਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ, ਕਿੱਥੇ ਅਤੇ ਕਿੰਨੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੀ ਕੀਮਤ ਹੈ। ਲੜਾਈ ਦੇ ਕੁਝ ਲੋਡ ਸਪੱਸ਼ਟ ਹੋ ਗਏ ਹਨ, ਜੋ ਬਿਨਾਂ ਸ਼ੱਕ ਕੋਡ ਦੀ ਗੁਣਵੱਤਾ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦੇ ਹਨ. ਰੀਲੀਜ਼ ਪ੍ਰਕਿਰਿਆ ਦੇ ਦੌਰਾਨ ਸੰਚਾਰ ਤੁਰੰਤ ਸੰਦੇਸ਼ਵਾਹਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੀ ਗੱਲਬਾਤ ਵਿੱਚ ਹੋਇਆ ਸੀ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਸਾਡੇ ਕੋਲ ਸਾਰੀਆਂ ਕਾਰਵਾਈਆਂ ਦਾ ਇੱਕ ਲੌਗ ਸੀ, ਅਤੇ ਦੂਜਾ, ਸੰਚਾਰ ਇੱਕ ਨਜ਼ਦੀਕੀ ਮਾਹੌਲ ਵਿੱਚ ਹੋਇਆ ਸੀ. ਕਾਰਵਾਈਆਂ ਦੇ ਇਤਿਹਾਸ ਨੇ ਇੱਕ ਤੋਂ ਵੱਧ ਵਾਰ ਨਵੇਂ ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਹੱਲ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਹੈ। ਇਹ ਇੱਕ ਵਿਰੋਧਾਭਾਸ ਹੈ, ਪਰ ਇਸ ਨੇ ਅਕਸਰ ਪ੍ਰਸ਼ਾਸਕਾਂ ਦੀ ਮਦਦ ਕੀਤੀ। ਮੈਂ ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਕਹਿਣਾ ਨਹੀਂ ਸ਼ੁਰੂ ਕਰਾਂਗਾ, ਪਰ ਇਹ ਮੈਨੂੰ ਜਾਪਦਾ ਹੈ ਕਿ ਪ੍ਰਬੰਧਕਾਂ ਨੇ ਇਹ ਸਮਝਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ ਹੈ ਕਿ ਪ੍ਰੋਜੈਕਟ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਇਹ ਕਿਵੇਂ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ. ਕਈ ਵਾਰ ਅਸੀਂ ਇੱਕ ਦੂਜੇ ਨਾਲ ਕੁਝ ਵੇਰਵੇ ਵੀ ਸਾਂਝੇ ਕੀਤੇ। ਔਸਤ ਰੀਲਿਜ਼ ਸਮਾਂ ਇੱਕ ਘੰਟੇ ਤੱਕ ਘਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਕਈ ਵਾਰ ਅਸੀਂ 30-40 ਮਿੰਟਾਂ ਵਿੱਚ ਹੋ ਜਾਂਦੇ ਹਾਂ। ਬੱਗਾਂ ਦੀ ਗਿਣਤੀ ਵਿੱਚ ਕਾਫ਼ੀ ਕਮੀ ਆਈ ਹੈ, ਜੇਕਰ ਦਸ ਗੁਣਾ ਨਹੀਂ। ਬੇਸ਼ੱਕ, ਹੋਰ ਕਾਰਕਾਂ ਨੇ ਵੀ ਰੀਲੀਜ਼ ਦੇ ਸਮੇਂ ਵਿੱਚ ਕਮੀ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ, ਜਿਵੇਂ ਕਿ ਆਟੋਟੈਸਟ. ਹਰ ਰੀਲੀਜ਼ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਪਿਛਾਖੜੀ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। ਤਾਂ ਜੋ ਪੂਰੀ ਟੀਮ ਨੂੰ ਪਤਾ ਹੋਵੇ ਕਿ ਨਵਾਂ ਕੀ ਹੈ, ਕੀ ਬਦਲਿਆ ਗਿਆ ਹੈ, ਅਤੇ ਕੀ ਹਟਾਇਆ ਗਿਆ ਹੈ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਪ੍ਰਸ਼ਾਸਕ ਹਮੇਸ਼ਾ ਉਹਨਾਂ ਕੋਲ ਨਹੀਂ ਆਉਂਦੇ, ਖੈਰ, ਪ੍ਰਸ਼ਾਸਕ ਰੁੱਝੇ ਹੋਏ ਹਨ... ਇੱਕ ਡਿਵੈਲਪਰ ਵਜੋਂ ਮੇਰੀ ਨੌਕਰੀ ਦੀ ਸੰਤੁਸ਼ਟੀ ਬਿਨਾਂ ਸ਼ੱਕ ਵੱਧ ਗਈ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਲਗਭਗ ਕਿਸੇ ਵੀ ਸਮੱਸਿਆ ਨੂੰ ਜਲਦੀ ਹੱਲ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਤੁਹਾਡੀ ਯੋਗਤਾ ਦੇ ਖੇਤਰ ਵਿੱਚ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸਿਖਰ 'ਤੇ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ। ਬਾਅਦ ਵਿੱਚ, ਮੈਂ ਸਮਝਾਂਗਾ ਕਿ ਕੁਝ ਹੱਦ ਤੱਕ ਅਸੀਂ ਇੱਕ ਡਿਵੋਪਸ ਸੱਭਿਆਚਾਰ ਪੇਸ਼ ਕੀਤਾ ਹੈ, ਬਿਲਕੁਲ ਨਹੀਂ, ਬੇਸ਼ੱਕ, ਪਰ ਤਬਦੀਲੀ ਦੀ ਸ਼ੁਰੂਆਤ ਵੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸੀ।

ਕਹਾਣੀ ਤਿੰਨ
ਸ਼ੁਰੂ ਕਰਣਾ. ਇੱਕ ਪ੍ਰਸ਼ਾਸਕ, ਛੋਟਾ ਵਿਕਾਸ ਵਿਭਾਗ। ਪਹੁੰਚਣ 'ਤੇ ਮੈਂ ਪੂਰਾ ਜ਼ੀਰੋ ਹਾਂ, ਕਿਉਂਕਿ... ਮੈਨੂੰ ਡਾਕ ਤੋਂ ਇਲਾਵਾ ਕਿਤੇ ਵੀ ਪਹੁੰਚ ਨਹੀਂ ਹੈ। ਅਸੀਂ ਪ੍ਰਸ਼ਾਸਕ ਨੂੰ ਲਿਖਦੇ ਹਾਂ ਅਤੇ ਪਹੁੰਚ ਦੀ ਮੰਗ ਕਰਦੇ ਹਾਂ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਜਾਣਕਾਰੀ ਹੈ ਕਿ ਉਹ ਨਵੇਂ ਕਰਮਚਾਰੀ ਅਤੇ ਲੌਗਿਨ/ਪਾਸਵਰਡ ਜਾਰੀ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਤੋਂ ਜਾਣੂ ਹੈ। ਉਹ ਰਿਪੋਜ਼ਟਰੀ ਅਤੇ VPN ਤੋਂ ਪਹੁੰਚ ਦਿੰਦੇ ਹਨ। ਵਿਕੀ, ਟੀਮਸਿਟੀ, ਰਨਡੈਸਕ ਤੱਕ ਪਹੁੰਚ ਕਿਉਂ ਦਿੱਤੀ ਜਾਵੇ? ਇੱਕ ਵਿਅਕਤੀ ਲਈ ਬੇਕਾਰ ਚੀਜ਼ਾਂ ਜਿਸਨੂੰ ਪੂਰਾ ਬੈਕਐਂਡ ਹਿੱਸਾ ਲਿਖਣ ਲਈ ਬੁਲਾਇਆ ਗਿਆ ਸੀ। ਸਮੇਂ ਦੇ ਨਾਲ ਹੀ ਅਸੀਂ ਕੁਝ ਸਾਧਨਾਂ ਤੱਕ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ। ਆਮਦ, ਬੇਸ਼ੱਕ, ਅਵਿਸ਼ਵਾਸ ਨਾਲ ਮੁਲਾਕਾਤ ਕੀਤੀ ਗਈ ਸੀ. ਮੈਂ ਹੌਲੀ-ਹੌਲੀ ਇਹ ਮਹਿਸੂਸ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹਾਂ ਕਿ ਪ੍ਰੋਜੈਕਟ ਦਾ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਚੈਟਾਂ ਅਤੇ ਪ੍ਰਮੁੱਖ ਪ੍ਰਸ਼ਨਾਂ ਦੁਆਰਾ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਅਸਲ ਵਿੱਚ ਮੈਂ ਕੁਝ ਵੀ ਨਹੀਂ ਪਛਾਣਦਾ। ਉਤਪਾਦਨ ਪਹਿਲਾਂ ਵਾਂਗ ਹੀ ਬਲੈਕ ਬਾਕਸ ਹੈ। ਪਰ ਇਸ ਤੋਂ ਵੱਧ, ਟੈਸਟਿੰਗ ਲਈ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਸਟੇਜ ਸਰਵਰ ਵੀ ਇੱਕ ਬਲੈਕ ਬਾਕਸ ਹਨ. ਅਸੀਂ ਉੱਥੇ ਗਿਟ ਤੋਂ ਬ੍ਰਾਂਚ ਤਾਇਨਾਤ ਕਰਨ ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਕੁਝ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਅਸੀਂ ਆਪਣੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ .env ਫਾਈਲਾਂ ਵਾਂਗ ਕੌਂਫਿਗਰ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹਾਂ। ਅਜਿਹੇ ਓਪਰੇਸ਼ਨਾਂ ਲਈ ਪਹੁੰਚ ਨਹੀਂ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਤੁਹਾਨੂੰ ਟੈਸਟ ਸਰਵਰ 'ਤੇ ਆਪਣੀ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਸੰਰਚਨਾ ਵਿੱਚ ਇੱਕ ਲਾਈਨ ਬਦਲਣ ਲਈ ਬੇਨਤੀ ਕਰਨੀ ਪਵੇਗੀ। (ਇੱਥੇ ਇੱਕ ਸਿਧਾਂਤ ਹੈ ਕਿ ਪ੍ਰਸ਼ਾਸਕਾਂ ਲਈ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਆਪਣੇ ਆਪ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਮਹਿਸੂਸ ਕਰਨਾ ਬਹੁਤ ਜ਼ਰੂਰੀ ਹੈ; ਜੇ ਉਹਨਾਂ ਨੂੰ ਸੰਰਚਨਾਵਾਂ ਵਿੱਚ ਲਾਈਨਾਂ ਨੂੰ ਬਦਲਣ ਲਈ ਨਹੀਂ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਵੇਗੀ)। ਖੈਰ, ਹਮੇਸ਼ਾ ਵਾਂਗ, ਕੀ ਇਹ ਸੁਵਿਧਾਜਨਕ ਨਹੀਂ ਹੈ? ਇਹ ਜਲਦੀ ਬੋਰਿੰਗ ਹੋ ਜਾਂਦਾ ਹੈ, ਐਡਮਿਨ ਨਾਲ ਸਿੱਧੀ ਗੱਲਬਾਤ ਤੋਂ ਬਾਅਦ ਸਾਨੂੰ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਡਿਵੈਲਪਰ ਮਾੜੇ ਕੋਡ ਨੂੰ ਲਿਖਣ ਲਈ ਪੈਦਾ ਹੋਏ ਸਨ, ਸੁਭਾਅ ਵਿੱਚ ਅਯੋਗ ਵਿਅਕਤੀ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਉਤਪਾਦਨ ਤੋਂ ਦੂਰ ਰੱਖਣਾ ਬਿਹਤਰ ਹੈ। ਪਰ ਇੱਥੇ ਵੀ ਟੈਸਟ ਸਰਵਰਾਂ ਤੋਂ, ਸਿਰਫ ਮਾਮਲੇ ਵਿੱਚ. ਝਗੜਾ ਤੇਜ਼ੀ ਨਾਲ ਵਧ ਰਿਹਾ ਹੈ। ਐਡਮਿਨ ਨਾਲ ਕੋਈ ਸੰਚਾਰ ਨਹੀਂ ਹੈ। ਸਥਿਤੀ ਇਸ ਤੱਥ ਤੋਂ ਵਿਗੜ ਗਈ ਹੈ ਕਿ ਉਹ ਇਕੱਲਾ ਹੈ. ਹੇਠ ਦਿੱਤੀ ਇੱਕ ਆਮ ਤਸਵੀਰ ਹੈ. ਜਾਰੀ ਕਰੋ। ਕੁਝ ਕਾਰਜਕੁਸ਼ਲਤਾ ਕੰਮ ਨਹੀਂ ਕਰਦੀ। ਇਹ ਪਤਾ ਲਗਾਉਣ ਵਿੱਚ ਸਾਨੂੰ ਲੰਮਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਡਿਵੈਲਪਰਾਂ ਦੇ ਵੱਖੋ-ਵੱਖਰੇ ਵਿਚਾਰ ਚੈਟ ਵਿੱਚ ਸੁੱਟੇ ਜਾਂਦੇ ਹਨ, ਪਰ ਅਜਿਹੀ ਸਥਿਤੀ ਵਿੱਚ ਐਡਮਿਨ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਮੰਨਦਾ ਹੈ ਕਿ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਜ਼ਿੰਮੇਵਾਰ ਠਹਿਰਾਇਆ ਜਾਂਦਾ ਹੈ। ਫਿਰ ਉਹ ਚੈਟ ਵਿੱਚ ਲਿਖਦਾ ਹੈ, ਉਡੀਕ ਕਰੋ, ਮੈਂ ਉਸਨੂੰ ਠੀਕ ਕੀਤਾ। ਜਦੋਂ ਸਮੱਸਿਆ ਬਾਰੇ ਜਾਣਕਾਰੀ ਦੇ ਨਾਲ ਇੱਕ ਕਹਾਣੀ ਪਿੱਛੇ ਛੱਡਣ ਲਈ ਕਿਹਾ ਗਿਆ, ਤਾਂ ਸਾਨੂੰ ਜ਼ਹਿਰੀਲੇ ਬਹਾਨੇ ਮਿਲਦੇ ਹਨ। ਜਿਵੇਂ, ਆਪਣੀ ਨੱਕ ਨੂੰ ਨਾ ਚਿਪਕਾਓ ਜਿੱਥੇ ਇਹ ਸਬੰਧਤ ਨਹੀਂ ਹੈ। ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਕੋਡ ਲਿਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਅਜਿਹੀ ਸਥਿਤੀ ਜਦੋਂ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਸਰੀਰ ਦੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਗਤੀਵਿਧੀਆਂ ਇੱਕ ਸਿੰਗਲ ਵਿਅਕਤੀ ਦੁਆਰਾ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਸਿਰਫ ਉਸ ਕੋਲ ਓਪਰੇਸ਼ਨ ਕਰਨ ਦੀ ਪਹੁੰਚ ਹੁੰਦੀ ਹੈ ਜਿਸਦੀ ਹਰ ਕਿਸੇ ਨੂੰ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਅਜਿਹਾ ਵਿਅਕਤੀ ਇੱਕ ਭਿਆਨਕ ਰੁਕਾਵਟ ਹੈ। ਜੇਕਰ Devops ਦੇ ਵਿਚਾਰ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਮਾਰਕੀਟ ਨੂੰ ਘਟਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਤਾਂ ਅਜਿਹੇ ਲੋਕ Devops ਵਿਚਾਰਾਂ ਦੇ ਸਭ ਤੋਂ ਵੱਡੇ ਦੁਸ਼ਮਣ ਹਨ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਪਰਦਾ ਇੱਥੇ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ.

PS ਲੋਕਾਂ ਨਾਲ ਗੱਲਬਾਤ ਵਿੱਚ ਡਿਵੈਲਪਰ ਬਨਾਮ ਪ੍ਰਸ਼ਾਸਕਾਂ ਬਾਰੇ ਥੋੜੀ ਗੱਲ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਉਨ੍ਹਾਂ ਲੋਕਾਂ ਨੂੰ ਮਿਲਿਆ ਜਿਨ੍ਹਾਂ ਨੇ ਮੇਰਾ ਦਰਦ ਸਾਂਝਾ ਕੀਤਾ। ਪਰ ਅਜਿਹੇ ਲੋਕ ਵੀ ਸਨ ਜਿਨ੍ਹਾਂ ਨੇ ਕਿਹਾ ਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਕਦੇ ਵੀ ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਕੋਈ ਚੀਜ਼ ਨਹੀਂ ਆਈ। ਇੱਕ ਡਿਵੋਪਸ ਕਾਨਫਰੰਸ ਵਿੱਚ, ਮੈਂ ਐਂਟੋਨ ਇਸਾਨਿਨ (ਅਲਫਾ ਬੈਂਕ) ਨੂੰ ਪੁੱਛਿਆ ਕਿ ਉਹਨਾਂ ਨੇ ਪ੍ਰਸ਼ਾਸਕਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਰੁਕਾਵਟ ਦੀ ਸਮੱਸਿਆ ਨਾਲ ਕਿਵੇਂ ਨਜਿੱਠਿਆ, ਜਿਸ ਲਈ ਉਸਨੇ ਕਿਹਾ: "ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਬਟਨਾਂ ਨਾਲ ਬਦਲ ਦਿੱਤਾ ਹੈ।" ਉਂਜ ਪੌਡਕਾਸਟ ਉਸ ਦੀ ਭਾਗੀਦਾਰੀ ਨਾਲ. ਮੈਂ ਵਿਸ਼ਵਾਸ ਕਰਨਾ ਚਾਹਾਂਗਾ ਕਿ ਦੁਸ਼ਮਣਾਂ ਨਾਲੋਂ ਬਹੁਤ ਸਾਰੇ ਚੰਗੇ ਐਡਮਿਨ ਹਨ. ਅਤੇ ਹਾਂ, ਸ਼ੁਰੂ ਵਿੱਚ ਤਸਵੀਰ ਇੱਕ ਅਸਲੀ ਪੱਤਰ ਵਿਹਾਰ ਹੈ.

ਸਰੋਤ: www.habr.com