Slurm SRE. Booking.com ਅਤੇ Google.com ਦੇ ਮਾਹਰਾਂ ਨਾਲ ਇੱਕ ਸੰਪੂਰਨ ਪ੍ਰਯੋਗ

ਸਾਡੀ ਟੀਮ ਪ੍ਰਯੋਗਾਂ ਨੂੰ ਪਿਆਰ ਕਰਦੀ ਹੈ। ਹਰੇਕ ਸਲਰਮ ਪਿਛਲੇ ਲੋਕਾਂ ਦੀ ਸਥਿਰ ਦੁਹਰਾਓ ਨਹੀਂ ਹੈ, ਪਰ ਅਨੁਭਵ ਦਾ ਪ੍ਰਤੀਬਿੰਬ ਹੈ ਅਤੇ ਚੰਗੇ ਤੋਂ ਬਿਹਤਰ ਵਿੱਚ ਤਬਦੀਲੀ ਹੈ। ਪਰ ਨਾਲ Slurm SRE ਅਸੀਂ ਇੱਕ ਬਿਲਕੁਲ ਨਵਾਂ ਫਾਰਮੈਟ ਲਾਗੂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ - ਭਾਗੀਦਾਰਾਂ ਨੂੰ "ਲੜਾਈ" ਲਈ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਸ਼ਰਤਾਂ ਦੇਣ ਲਈ।

ਜੇ ਅਸੀਂ ਸੰਖੇਪ ਰੂਪ ਵਿਚ ਦੱਸੀਏ ਕਿ ਅਸੀਂ ਤੀਬਰ ਕੋਰਸ ਦੌਰਾਨ ਕੀ ਕੀਤਾ: “ਅਸੀਂ ਬਣਾਉਂਦੇ ਹਾਂ, ਅਸੀਂ ਤੋੜਦੇ ਹਾਂ, ਅਸੀਂ ਮੁਰੰਮਤ ਕਰਦੇ ਹਾਂ,
ਅਸੀਂ ਪੜ੍ਹ ਰਹੇ ਹਾਂ।" ਸਿਰਫ਼ ਸਿਧਾਂਤ ਵਿੱਚ SRE ਦੀ ਕੀਮਤ ਬਹੁਤ ਘੱਟ ਹੈ - ਸਿਰਫ਼ ਅਭਿਆਸ, ਅਸਲ ਹੱਲ, ਅਸਲ ਸਮੱਸਿਆਵਾਂ।

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

ਭਾਗੀਦਾਰਾਂ ਨੂੰ ਚਾਰ ਸਲਾਹਕਾਰਾਂ ਦੁਆਰਾ ਸਮੱਸਿਆਵਾਂ, ਗਲਤੀਆਂ, ਬੱਗ ਅਤੇ ਕਾਰਜ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਸਨ। ਇਵਾਨ ਕ੍ਰੂਗਲੋਵ, Booking.com (ਨੀਦਰਲੈਂਡਜ਼) 'ਤੇ ਪ੍ਰਮੁੱਖ ਵਿਕਾਸਕਾਰ। ਬੈਨ ਟਾਈਲਰ, Booking.com (USA) 'ਤੇ ਪ੍ਰਮੁੱਖ ਵਿਕਾਸਕਾਰ। ਐਡਵਾਰਡ ਮੇਦਵੇਦੇਵ, ਟੰਗਸਟਨ ਲੈਬਜ਼ (ਜਰਮਨੀ) ਵਿਖੇ ਸੀ.ਟੀ.ਓ. Evgeniy Varavva, Google (San Francisco) ਦੇ ਜਨਰਲ ਡਿਵੈਲਪਰ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਭਾਗੀਦਾਰ ਟੀਮਾਂ ਵਿਚ ਵੰਡੇ ਹੋਏ ਹਨ ਅਤੇ ਇਕ ਦੂਜੇ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦੇ ਹਨ. ਦਿਲਚਸਪ?

ਇਵਾਨ, ਬੇਨ, ਐਡੁਆਰਡ ਅਤੇ ਇਵਗੇਨੀ ਮੁਕਾਬਲੇ ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਪਹਿਲਾਂ ਗਰੀਬ ਸਲਰਮ ਐਸਆਰਈ ਭਾਗੀਦਾਰਾਂ ਨੂੰ ਦਿਆਲੂ ਲੈਨਿਨਿਸਟ ਸਕੁਇੰਟਸ ਨਾਲ ਦੇਖਦੇ ਹਨ।

ਇਸ ਲਈ ਕੰਮ:

ਅਸੀਂ ਆਪਣੇ ਹਾਂ, ਨਵੀਂ ਦੁਨੀਆਂ ਬਣਾਵਾਂਗੇ...

ਇੱਕ ਮੂਵੀ ਟਿਕਟ ਐਗਰੀਗੇਟਰ ਵੈਬਸਾਈਟ ਹੈ। ਘਟਨਾਵਾਂ ਨੂੰ ਸਲਾਹਕਾਰਾਂ ਦੁਆਰਾ ਇੱਕ ਪੂਰਵ-ਕੰਮ ਕੀਤੇ ਦ੍ਰਿਸ਼ ਵਿੱਚ ਖੋਜਿਆ ਜਾਂਦਾ ਹੈ (ਹਾਲਾਂਕਿ ਕੋਈ ਵੀ ਖਾਸ ਤੌਰ 'ਤੇ ਸੂਝਵਾਨ ਅਤੇ ਧੋਖੇਬਾਜ਼ ਸੁਧਾਰ ਨੂੰ ਸ਼ਾਮਲ ਨਹੀਂ ਕਰਦਾ), ਸਾਈਟ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਵੱਖ-ਵੱਖ ਮੈਟ੍ਰਿਕਸ ਦੁਆਰਾ ਦਰਸਾਇਆ ਗਿਆ ਹੈ। ਸਮੱਸਿਆਵਾਂ ਬਹੁਤ ਵੱਖਰੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ: ਮੌਲਿਨ ਰੂਜ ਥੀਏਟਰ ਲਈ ਟਿਕਟਾਂ ਡੇਟਾਬੇਸ ਵਿੱਚ ਲੋਡ ਨਹੀਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ; ਫਿਲਮਾਂ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨਾਂ ਦੇ ਪੋਸਟਰ 10 ਸਕਿੰਟਾਂ ਤੋਂ ਵੱਧ ਸਮੇਂ ਵਿੱਚ ਡੇਟਾਬੇਸ ਵਿੱਚ ਲੋਡ ਕੀਤੇ ਜਾਂਦੇ ਹਨ; ਇੱਕ ਵਿਅਕਤੀਗਤ ਫਿਲਮ ਦਾ ਵੇਰਵਾ ਜੰਮ ਜਾਂਦਾ ਹੈ; 0,1% ਆਰਡਰ ਪਹਿਲਾਂ ਹੀ ਰਾਖਵੇਂ ਹਨ; ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਭੁਗਤਾਨ ਪ੍ਰਕਿਰਿਆ ਪ੍ਰਣਾਲੀ ਇੱਕ ਜਾਂ ਦੋ ਮਿੰਟਾਂ ਲਈ ਕਰੈਸ਼ ਹੋ ਜਾਂਦੀ ਹੈ। ਅਤੇ ਬਹੁਤ ਸਾਰੀਆਂ, ਬਹੁਤ ਸਾਰੀਆਂ, ਬਹੁਤ ਸਾਰੀਆਂ ਅਣਸੁਖਾਵੀਆਂ ਚੀਜ਼ਾਂ ਜੋ ਇੱਕ Slurm SRE ਭਾਗੀਦਾਰ ਨੂੰ ਉਸਦੀ ਅਸਲ ਨੌਕਰੀ ਤੇ ਆ ਸਕਦੀਆਂ ਹਨ.

ਅਸੀਂ ਹਰ ਕਿਸੇ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਤਿਆਰ ਹਾਂ...

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

ਤੀਬਰ ਸਾਈਟ ਲਈ, ਅਸੀਂ SLO, SLI, SLA ਸੂਚਕਾਂ, ਵਿਕਸਤ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਤਿਆਰ ਕੀਤਾ, ਸਾਈਟ ਨੂੰ ਤੈਨਾਤ ਕੀਤਾ, ਨਿਗਰਾਨੀ ਅਤੇ ਚੇਤਾਵਨੀ ਸਥਾਪਤ ਕੀਤੀ। ਅਤੇ ਅਸੀਂ ਚਲੇ ਜਾਂਦੇ ਹਾਂ.

SLO, SLI, SLA

SLI - ਸੇਵਾ ਪੱਧਰ ਦੇ ਸੂਚਕ। SLO ਸੇਵਾ ਪੱਧਰ ਦੇ ਟੀਚੇ ਹਨ। SLA - ਸੇਵਾ ਪੱਧਰ ਦੇ ਸਮਝੌਤੇ।

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

ਇੱਕ SLO ਇੱਕ ਸੇਵਾ ਪੱਧਰ ਦਾ ਉਦੇਸ਼ ਹੈ: ਸੇਵਾ ਪੱਧਰ ਲਈ ਇੱਕ ਟੀਚਾ ਮੁੱਲ ਜਾਂ ਮੁੱਲਾਂ ਦੀ ਰੇਂਜ ਜੋ SLI ਦੁਆਰਾ ਮਾਪੀ ਜਾਂਦੀ ਹੈ। SLO ਲਈ ਇੱਕ ਆਮ ਮੁੱਲ "SLI ≤ ਟਾਰਗੇਟ" ਜਾਂ "ਲੋਅਰ ਸੀਮਾ ≤ SLI ≤ ਉਪਰਲੀ ਸੀਮਾ" ਹੈ।

SLI ਇੱਕ ਸੇਵਾ ਪੱਧਰ ਦਾ ਸੂਚਕ ਹੈ — ਪ੍ਰਦਾਨ ਕੀਤੀ ਸੇਵਾ ਦੇ ਪੱਧਰ ਦੇ ਇੱਕ ਪਹਿਲੂ ਦਾ ਧਿਆਨ ਨਾਲ ਪਰਿਭਾਸ਼ਿਤ ਮਾਤਰਾਤਮਕ ਮਾਪ। ਜ਼ਿਆਦਾਤਰ ਸੇਵਾਵਾਂ ਲਈ, ਕੁੰਜੀ SLI ਨੂੰ ਬੇਨਤੀ ਲੇਟੈਂਸੀ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ - ਇੱਕ ਬੇਨਤੀ ਦਾ ਜਵਾਬ ਵਾਪਸ ਕਰਨ ਵਿੱਚ ਕਿੰਨਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ। ਹੋਰ ਆਮ SLIs ਵਿੱਚ ਗਲਤੀ ਦਰ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ, ਜੋ ਅਕਸਰ ਪ੍ਰਾਪਤ ਹੋਈਆਂ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਦੇ ਇੱਕ ਅੰਸ਼ ਵਜੋਂ ਦਰਸਾਈ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਸਿਸਟਮ ਥ੍ਰੋਪੁੱਟ, ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਤੀ ਸਕਿੰਟ ਬੇਨਤੀਆਂ ਵਿੱਚ ਮਾਪੀ ਜਾਂਦੀ ਹੈ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਜਹਾਜ਼ਾਂ ਨੂੰ ਤੋੜਾਂਗੇ, ਅਤੇ ਫਿਰ ਕੁੜੀਆਂ, ਅਤੇ ਫਿਰ ਕੁੜੀਆਂ ...

ਅੰਦਰੂਨੀ ਅਤੇ ਬਾਹਰੀ ਕਾਰਕ ਪਹਿਲੇ ਮਿੰਟਾਂ ਤੋਂ ਹੀ SLO ਨੂੰ "ਵਿਗਾੜਨਾ" ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹਨ। ਸਭ ਕੁਝ ਪ੍ਰਸ਼ਾਸਕਾਂ ਦੇ ਸਿਰਾਂ 'ਤੇ ਡਿੱਗਿਆ-ਵਿਕਾਸਕਰਤਾ ਦੀਆਂ ਗਲਤੀਆਂ, ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀਆਂ ਅਸਫਲਤਾਵਾਂ, ਦਰਸ਼ਕਾਂ ਦੀ ਭੀੜ, ਅਤੇ DDoS ਹਮਲੇ। ਹਰ ਚੀਜ਼ ਜੋ SLO ਨੂੰ ਵਿਗੜਦੀ ਹੈ.

"- ਪਿਆਰੇ ਭਾਗੀਦਾਰ, ਮੈਂ ਤੁਹਾਨੂੰ ਖੁਸ਼ ਕਰਨ ਲਈ ਕਾਹਲੀ ਕਰਦਾ ਹਾਂ, ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਤੁਸੀਂ ਅਸਫਲ ਹੋ ਜਾਂਦੇ ਹੋ ... ਸਭ ਕੁਝ!"

ਰਸਤੇ ਵਿੱਚ, ਬੁਲਾਰਿਆਂ ਨੇ ਸਥਿਰਤਾ, ਗਲਤੀ ਬਜਟ, ਟੈਸਟਿੰਗ ਅਭਿਆਸ, ਰੁਕਾਵਟਾਂ ਦੇ ਪ੍ਰਬੰਧਨ ਅਤੇ ਸੰਚਾਲਨ ਲੋਡ ਬਾਰੇ ਚਰਚਾ ਕੀਤੀ।

ਅਸੀਂ ਸਟੋਕਰ ਨਹੀਂ, ਤਰਖਾਣ ਨਹੀਂ ...

ਫਿਰ ਭਾਗੀਦਾਰਾਂ ਨੇ ਚੀਜ਼ਾਂ ਨੂੰ ਠੀਕ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ - ਮੁੱਖ ਗੱਲ ਇਹ ਸਮਝਣਾ ਹੈ ਕਿ ਪਹਿਲਾਂ ਕੀ ਫੜਨਾ ਹੈ.

"- ਪ੍ਰਭੂ, ਮੈਂ ਇਸਨੂੰ ਇਸ ਤਰ੍ਹਾਂ, ਇਸ ਰੂਪ ਅਤੇ ਅਜਿਹੀ ਸਥਿਤੀ ਵਿੱਚ ਕਦੇ ਨਹੀਂ ਵੇਖਿਆ!"

ਇਸ ਲਈ ਹਾਦਸਾ ਵਾਪਰ ਗਿਆ। ਭੁਗਤਾਨ ਪ੍ਰਕਿਰਿਆ ਸੇਵਾ ਬੰਦ ਹੈ। ਘੱਟ ਤੋਂ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਬਹਾਲ ਕਰਨ ਲਈ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਹੈ?

ਮਾਹਰ, ਭਾਗੀਦਾਰਾਂ ਨੂੰ ਪਿਆਰ ਨਾਲ ਦੇਖਦੇ ਹੋਏ, ਇਕ ਹੋਰ ਚਾਲ ਤਿਆਰ ਕਰ ਰਹੇ ਹਨ.

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

"ਕਿਹੋ ਜਿਹੀ ਦਹਿਸ਼ਤ ਸਾਹਮਣੇ ਆਈ ਹੈ?!"

ਸਾਹ ਛੱਡੋ... ਅਤੇ ਕਸਰਤ ਨੂੰ ਪੂਰਾ ਕਰੋ

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

“ਹੋਰ ਕੌਣ ਕਸ਼ਟ ਚਾਹੁੰਦਾ ਹੈ! - ਮੈਂ!"

ਟੀਮਾਂ ਦੀਆਂ ਸਫਲਤਾਵਾਂ ਨੂੰ ਇਲੈਕਟ੍ਰਾਨਿਕ ਸਕੋਰਬੋਰਡ 'ਤੇ ਸਖਤੀ ਨਾਲ ਅਤੇ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਦਰਜ ਕੀਤਾ ਗਿਆ ਸੀ।

ਪਹਿਲੇ ਸਥਾਨਾਂ ਲਈ - ਹਿੱਸੇਦਾਰਾਂ ਤੋਂ ਇੱਕ ਬੋਨਸ।

ਸਰੋਤ: www.habr.com