ਮੈਂ ਇੱਕ SRE ਇੰਜੀਨੀਅਰ ਇੰਟਰਨ ਵਜੋਂ ਇੱਕ ਹਫ਼ਤਾ ਕਿਵੇਂ ਬਿਤਾਇਆ। ਇੱਕ ਸਾਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰ ਦੀ ਨਜ਼ਰ ਦੁਆਰਾ ਡਿਊਟੀ

ਐਸਆਰਈ ਇੰਜੀਨੀਅਰ - ਸਿਖਿਆਰਥੀ

ਪਹਿਲਾਂ, ਮੈਨੂੰ ਆਪਣੀ ਜਾਣ ਪਛਾਣ ਕਰਨ ਦਿਓ. ਮੈਂ - @tristan.read, ਗਰੁੱਪ ਵਿੱਚ ਫਰੰਟ-ਐਂਡ ਇੰਜੀਨੀਅਰ ਮਾਨੀਟਰ::ਸਿਹਤ GitLab. ਪਿਛਲੇ ਹਫ਼ਤੇ ਮੈਨੂੰ ਸਾਡੇ ਆਨ-ਕਾਲ SRE ਇੰਜੀਨੀਅਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨਾਲ ਇੰਟਰਨਿੰਗ ਕਰਨ ਦਾ ਸਨਮਾਨ ਮਿਲਿਆ। ਟੀਚਾ ਇਹ ਦੇਖਣਾ ਸੀ ਕਿ ਆਨ-ਡਿਊਟੀ ਅਫਸਰ ਰੋਜ਼ਾਨਾ ਦੀਆਂ ਘਟਨਾਵਾਂ ਪ੍ਰਤੀ ਕਿਵੇਂ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਦਾ ਹੈ ਅਤੇ ਨੌਕਰੀ 'ਤੇ ਅਸਲ-ਜੀਵਨ ਦਾ ਤਜਰਬਾ ਹਾਸਲ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ ਸਾਡੇ ਇੰਜੀਨੀਅਰ ਉਪਭੋਗਤਾ ਦੀਆਂ ਲੋੜਾਂ ਨੂੰ ਬਿਹਤਰ ਢੰਗ ਨਾਲ ਸਮਝਣ ਫੰਕਸ਼ਨ ਮਾਨੀਟਰ::ਸਿਹਤ।

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

ਘਟਨਾਵਾਂ

ਇੱਕ ਹਫ਼ਤੇ ਵਿੱਚ 2 ਘਟਨਾਵਾਂ ਹੋਈਆਂ।

1. ਕ੍ਰਿਪਟੋ ਮਾਈਨਰ

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

ਜੇਕਰ ਇਸ ਘਟਨਾ ਵੱਲ ਧਿਆਨ ਨਾ ਦਿੱਤਾ ਗਿਆ ਹੁੰਦਾ, ਤਾਂ ਇੱਕ ਆਟੋਮੇਟਿਡ ਟੂਲ ਨੇ ਇਸਨੂੰ ਫੜ ਲਿਆ ਹੁੰਦਾ, ਪਰ ਇਸ ਮਾਮਲੇ ਵਿੱਚ, SRE ਇੰਜੀਨੀਅਰ ਨੇ ਉਲੰਘਣਾ ਨੂੰ ਪਹਿਲਾਂ ਦੇਖਿਆ। ਇੱਕ ਘਟਨਾ ਟਾਸਕ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਪਰ ਇਸ ਬਾਰੇ ਜਾਣਕਾਰੀ ਬੰਦ ਹੈ।

2. ਕੈਨਰੀ ਅਤੇ ਮੁੱਖ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਗਿਰਾਵਟ

ਇਹ ਘਟਨਾ Gitlab.com 'ਤੇ ਕੈਨਰੀ ਅਤੇ ਮੁੱਖ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਸੁਸਤੀ ਅਤੇ ਗਲਤੀਆਂ ਦੀ ਵੱਧ ਰਹੀ ਬਾਰੰਬਾਰਤਾ ਕਾਰਨ ਹੋਈ ਸੀ। ਕਈ Apdex ਮੁੱਲਾਂ ਦੀ ਉਲੰਘਣਾ ਕੀਤੀ ਗਈ ਸੀ।

ਓਪਨ ਘਟਨਾ ਕਾਰਜ: https://gitlab.com/gitlab-com/gl-infra/production/issues/1442

ਕੁੰਜੀ ਖੋਜ

ਇੱਥੇ ਕੁਝ ਗੱਲਾਂ ਹਨ ਜੋ ਮੈਂ ਡਿਊਟੀ 'ਤੇ ਆਪਣੇ ਹਫ਼ਤੇ ਦੌਰਾਨ ਸਿੱਖੀਆਂ ਹਨ।

1. ਆਦਰਸ਼ ਤੋਂ ਭਟਕਣ ਦਾ ਪਤਾ ਲਗਾਉਣ ਵੇਲੇ ਚੇਤਾਵਨੀਆਂ ਸਭ ਤੋਂ ਵੱਧ ਉਪਯੋਗੀ ਹੁੰਦੀਆਂ ਹਨ।

ਚੇਤਾਵਨੀਆਂ ਨੂੰ ਕਈ ਕਿਸਮਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ:

• ਕਿਸੇ ਖਾਸ ਥ੍ਰੈਸ਼ਹੋਲਡ ਮੁੱਲ 'ਤੇ ਆਧਾਰਿਤ ਚੇਤਾਵਨੀਆਂ, ਜਿਵੇਂ ਕਿ "10 5xx ਤਰੁੱਟੀਆਂ ਪ੍ਰਤੀ ਸਕਿੰਟ ਆਈਆਂ।"
• ਚੇਤਾਵਨੀਆਂ ਜਿਸ ਵਿੱਚ ਥ੍ਰੈਸ਼ਹੋਲਡ ਇੱਕ ਪ੍ਰਤੀਸ਼ਤ ਮੁੱਲ ਹੈ ਜਿਵੇਂ ਕਿ "ਕਿਸੇ ਦਿੱਤੇ ਸਮੇਂ 'ਤੇ ਬੇਨਤੀਆਂ ਦੀ ਕੁੱਲ ਮਾਤਰਾ ਦੇ 5% ਪ੍ਰਤੀ 10xx ਗਲਤੀਆਂ ਦੀ ਬਾਰੰਬਾਰਤਾ।"
• ਇਤਿਹਾਸਕ ਔਸਤ 'ਤੇ ਆਧਾਰਿਤ ਚੇਤਾਵਨੀਆਂ ਜਿਵੇਂ ਕਿ "5ਵੇਂ ਪ੍ਰਤੀਸ਼ਤ 'ਤੇ 90xx ਗਲਤੀਆਂ"।

ਆਮ ਤੌਰ 'ਤੇ, ਕਿਸਮਾਂ 2 ਅਤੇ 3 ਡਿਊਟੀ 'ਤੇ SREs ਲਈ ਵਧੇਰੇ ਲਾਭਦਾਇਕ ਹਨ, ਕਿਉਂਕਿ ਉਹ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਆਦਰਸ਼ ਤੋਂ ਭਟਕਣਾ ਨੂੰ ਪ੍ਰਗਟ ਕਰਦੇ ਹਨ।

2. ਬਹੁਤ ਸਾਰੀਆਂ ਚੇਤਾਵਨੀਆਂ ਕਦੇ ਵੀ ਘਟਨਾਵਾਂ ਵੱਲ ਨਹੀਂ ਵਧਦੀਆਂ।

SR ਇੰਜੀਨੀਅਰ ਚੇਤਾਵਨੀਆਂ ਦੀ ਇੱਕ ਨਿਰੰਤਰ ਧਾਰਾ ਨਾਲ ਨਜਿੱਠਦੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਅਸਲ ਵਿੱਚ ਨਾਜ਼ੁਕ ਨਹੀਂ ਹਨ।

ਤਾਂ ਫਿਰ ਕਿਉਂ ਨਾ ਚੇਤਾਵਨੀਆਂ ਨੂੰ ਸਿਰਫ ਅਸਲ ਮਹੱਤਵਪੂਰਨ ਲੋਕਾਂ ਤੱਕ ਸੀਮਤ ਕਰੋ? ਇਸ ਪਹੁੰਚ ਦੇ ਨਾਲ, ਹਾਲਾਂਕਿ, ਤੁਸੀਂ ਇਸ ਦੇ ਸ਼ੁਰੂਆਤੀ ਲੱਛਣਾਂ ਨੂੰ ਨਹੀਂ ਪਛਾਣ ਸਕਦੇ ਹੋ ਕਿ ਕੀ ਇੱਕ ਅਸਲ ਸਮੱਸਿਆ ਵਿੱਚ ਬਰਫ਼ਬਾਰੀ ਹੋਵੇਗੀ ਜੋ ਵੱਡੇ ਨੁਕਸਾਨ ਦਾ ਖ਼ਤਰਾ ਹੈ।

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

ਵਿਸ਼ੇਸ਼ਤਾ ਸੁਝਾਅ: https://gitlab.com/gitlab-org/gitlab/issues/42633

3. ਡਿਊਟੀ 'ਤੇ ਸਾਡੇ SRE ਬਹੁਤ ਸਾਰੇ ਸਾਧਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।

ਅੰਦਰੂਨੀ:

• ਗਿੱਟਲੈਬ ਇਨਫਰਾ ਪ੍ਰੋਜੈਕਟ: ਰਨਬੁੱਕ ਇੱਥੇ ਲਾਈਵ, ਸ਼ਿਫਟ/ਹਫ਼ਤੇ ਅਸਾਈਨਮੈਂਟ, ਘਟਨਾ ਪ੍ਰਤੀਕਿਰਿਆ ਕਾਰਜ।
• GitLab ਮੁੱਦੇ: ਮੁੱਦਿਆਂ ਵਿੱਚ ਜਾਂਚ, ਸਮੀਖਿਆਵਾਂ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਨੂੰ ਵੀ ਟਰੈਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
• GitLab ਲੇਬਲ: ਆਟੋਮੇਸ਼ਨ ਟਾਸਕ ਖਾਸ ਲੇਬਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਾਂਚ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਜੋ ਬੋਟ ਟਾਸਕ ਗਤੀਵਿਧੀ ਨੂੰ ਟਰੈਕ ਕਰਨ ਲਈ ਵਰਤਦੇ ਹਨ।

ਬਾਹਰੀ:

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

ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਹੋਰ.

4. GitLab ਨਾਲ GitLab.com ਦੀ ਨਿਗਰਾਨੀ ਕਰਨਾ ਅਸਫਲਤਾ ਦਾ ਇੱਕ ਸਿੰਗਲ ਬਿੰਦੂ ਹੈ

ਜੇਕਰ GitLab.com ਨੂੰ ਇੱਕ ਵੱਡੀ ਸੇਵਾ ਆਊਟੇਜ ਦਾ ਅਨੁਭਵ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਨਹੀਂ ਚਾਹੁੰਦੇ ਕਿ ਇਹ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਸਾਡੀ ਯੋਗਤਾ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰੇ। ਇਸਨੂੰ GitLab.com ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ ਇੱਕ ਦੂਜੀ GitLab ਉਦਾਹਰਨ ਸ਼ੁਰੂ ਕਰਕੇ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਅਸਲ ਵਿੱਚ, ਇਹ ਸਾਡੇ ਲਈ ਪਹਿਲਾਂ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ: https://ops.gitlab.net/.

5. ਗਿੱਟਲੈਬ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨ ਬਾਰੇ ਵਿਚਾਰ ਕਰਨ ਲਈ ਕੁਝ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ

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

ਐਸਆਰਈ ਇੰਜਨੀਅਰਾਂ ਨੂੰ ਬਹੁਤ ਸਾਰੀਆਂ ਗੁੰਝਲਾਂ ਦੇ ਨਾਲ ਮੁਸ਼ਕਲ ਸਮਾਂ ਹੁੰਦਾ ਹੈ। ਇਹਨਾਂ ਮੁੱਦਿਆਂ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਦੇ ਹੋਏ ਹੋਰ GitLab ਉਤਪਾਦਾਂ ਨੂੰ ਦੇਖਣਾ ਬਹੁਤ ਵਧੀਆ ਹੋਵੇਗਾ. ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਉਤਪਾਦ ਵਿੱਚ ਕੁਝ ਜੋੜਾਂ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹਾਂ ਜੋ ਉੱਪਰ ਦੱਸੇ ਗਏ ਵਰਕਫਲੋ ਨੂੰ ਆਸਾਨ ਬਣਾ ਦੇਣਗੇ। 'ਤੇ ਉਪਲਬਧ ਵੇਰਵੇ ਓਪਸ ਉਤਪਾਦ ਵਿਜ਼ਨ ਸੈਕਸ਼ਨ.

ਅਸੀਂ ਇਹਨਾਂ ਸਾਰੀਆਂ ਸ਼ਾਨਦਾਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਇਕੱਠੇ ਲਿਆਉਣ ਲਈ 2020 ਵਿੱਚ ਟੀਮ ਦਾ ਵਿਸਤਾਰ ਕਰ ਰਹੇ ਹਾਂ। ਜੇਕਰ ਦਿਲਚਸਪੀ ਹੈ, ਤਾਂ ਕਿਰਪਾ ਕਰਕੇ ਚੈੱਕ ਆਊਟ ਕਰੋ ਖਾਲੀ ਅਸਾਮੀਆਂ, ਅਤੇ ਕਿਸੇ ਵੀ ਸਵਾਲ ਲਈ ਸਾਡੀ ਟੀਮ ਦੇ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਨਾਲ ਸੰਪਰਕ ਕਰਨ ਲਈ ਬੇਝਿਜਕ ਮਹਿਸੂਸ ਕਰੋ।

ਸਰੋਤ: www.habr.com