ਅਨਾਥ ਸੇਵਾਵਾਂ: (ਮਾਈਕ੍ਰੋ) ਸਰਵਿਸ ਆਰਕੀਟੈਕਚਰ ਦਾ ਨਨੁਕਸਾਨ

Banki.ru ਪੋਰਟਲ ਦੇ ਸੰਚਾਲਨ ਦੇ ਨਿਰਦੇਸ਼ਕ ਆਂਦਰੇ ਨਿਕੋਲਸਕੀ ਨੇ ਪਿਛਲੇ ਸਾਲ ਦੀ ਕਾਨਫਰੰਸ ਵਿੱਚ ਗੱਲ ਕੀਤੀ DevOpsDays ਮਾਸਕੋ ਅਨਾਥ ਸੇਵਾਵਾਂ ਬਾਰੇ: ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਅਨਾਥ ਦੀ ਪਛਾਣ ਕਿਵੇਂ ਕਰਨੀ ਹੈ, ਅਨਾਥ ਸੇਵਾਵਾਂ ਕਿਉਂ ਮਾੜੀਆਂ ਹਨ, ਉਹਨਾਂ ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ, ਅਤੇ ਜੇਕਰ ਕੁਝ ਵੀ ਮਦਦ ਨਹੀਂ ਕਰਦਾ ਤਾਂ ਕੀ ਕਰਨਾ ਹੈ।

ਕੱਟ ਦੇ ਹੇਠਾਂ ਰਿਪੋਰਟ ਦਾ ਇੱਕ ਟੈਕਸਟ ਸੰਸਕਰਣ ਹੈ।

ਹੈਲੋ ਸਾਥੀਓ! ਮੇਰਾ ਨਾਮ ਐਂਡਰੀ ਹੈ, ਮੈਂ Banki.ru 'ਤੇ ਕੰਮ ਕਰਦਾ ਹਾਂ।

ਸਾਡੇ ਕੋਲ ਵੱਡੀਆਂ ਸੇਵਾਵਾਂ ਹਨ, ਇਹ ਅਜਿਹੀਆਂ ਮੋਨੋਲਿਥਿਕ ਸੇਵਾਵਾਂ ਹਨ, ਵਧੇਰੇ ਕਲਾਸੀਕਲ ਅਰਥਾਂ ਵਿੱਚ ਸੇਵਾਵਾਂ ਹਨ, ਅਤੇ ਬਹੁਤ ਛੋਟੀਆਂ ਹਨ। ਮੇਰੀ ਮਜ਼ਦੂਰ-ਕਿਸਾਨ ਪਰਿਭਾਸ਼ਾ ਵਿੱਚ, ਮੈਂ ਕਹਿੰਦਾ ਹਾਂ ਕਿ ਜੇ ਕੋਈ ਸੇਵਾ ਸਧਾਰਨ ਅਤੇ ਛੋਟੀ ਹੈ, ਤਾਂ ਉਹ ਮਾਈਕਰੋ ਹੈ, ਅਤੇ ਜੇ ਇਹ ਬਹੁਤ ਸਾਧਾਰਨ ਅਤੇ ਛੋਟੀ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ਸੇਵਾ ਹੈ।

ਸੇਵਾਵਾਂ ਦੇ ਫਾਇਦੇ

ਮੈਂ ਜਲਦੀ ਹੀ ਸੇਵਾਵਾਂ ਦੇ ਫਾਇਦਿਆਂ 'ਤੇ ਜਾਵਾਂਗਾ।

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

ਦੂਜਾ, ਅਲੱਗ-ਥਲੱਗ ਵਿਕਾਸ, ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਕਈ ਵਿਕਾਸ ਟੀਮਾਂ ਹੁੰਦੀਆਂ ਹਨ, ਹਰੇਕ ਟੀਮ ਵਿੱਚ ਕਈ ਵੱਖ-ਵੱਖ ਵਿਕਾਸਕਾਰ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਹਰੇਕ ਟੀਮ ਆਪਣੀ ਸੇਵਾ ਵਿਕਸਿਤ ਕਰਦੀ ਹੈ।

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

ਤਸਵੀਰ ਦੇਖੋ: ਇਹ ਇੱਕ ਚੰਗਾ ਵਿਕਾਸਕਾਰ ਹੈ, ਉਸਦੇ ਵੱਡੇ ਹੱਥ ਹਨ, ਉਹ ਬਹੁਤ ਕੁਝ ਕਰ ਸਕਦਾ ਹੈ. ਮੁੱਖ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਇਹ ਹੱਥ ਕਿੱਥੋਂ ਆਉਂਦੇ ਹਨ।

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

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

ਉਦਾਹਰਨ ਲਈ, ਤੁਹਾਡੇ ਕੋਲ 20 ਸੇਵਾਵਾਂ ਹਨ ਅਤੇ ਤੁਹਾਨੂੰ ਹੱਥਾਂ ਨਾਲ ਤੈਨਾਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤੁਹਾਡੇ ਕੋਲ 20 ਕੰਸੋਲ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਇੱਕ ਨਿੰਜਾ ਵਾਂਗ "ਐਂਟਰ" ਦਬਾਉਂਦੇ ਹੋ। ਇਹ ਬਹੁਤ ਵਧੀਆ ਨਹੀਂ ਹੈ।

ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਟੈਸਟਿੰਗ ਤੋਂ ਬਾਅਦ ਕੋਈ ਸੇਵਾ ਹੈ (ਜੇ ਟੈਸਟਿੰਗ ਹੈ, ਬੇਸ਼ਕ), ਅਤੇ ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ ਇਸ ਨੂੰ ਇੱਕ ਫਾਈਲ ਨਾਲ ਪੂਰਾ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਤਾਂ ਜੋ ਇਹ ਉਤਪਾਦਨ ਵਿੱਚ ਕੰਮ ਕਰੇ, ਮੇਰੇ ਕੋਲ ਤੁਹਾਡੇ ਲਈ ਬੁਰੀ ਖ਼ਬਰ ਹੈ.

ਜੇ ਤੁਸੀਂ ਖਾਸ ਐਮਾਜ਼ਾਨ ਸੇਵਾਵਾਂ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹੋ ਅਤੇ ਰੂਸ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹੋ, ਤਾਂ ਦੋ ਮਹੀਨੇ ਪਹਿਲਾਂ ਤੁਹਾਡੇ ਕੋਲ ਵੀ "ਆਸ-ਪਾਸ ਹਰ ਚੀਜ਼ ਨੂੰ ਅੱਗ ਲੱਗੀ ਹੋਈ ਹੈ, ਮੈਂ ਠੀਕ ਹਾਂ, ਸਭ ਕੁਝ ਠੰਡਾ ਹੈ।"

ਅਸੀਂ ਤੈਨਾਤੀ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰਨ ਲਈ Ansible, ਕਨਵਰਜੈਂਸ ਲਈ ਕਠਪੁਤਲੀ, ਤੈਨਾਤੀ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰਨ ਲਈ Bamboo, ਅਤੇ ਕਿਸੇ ਤਰ੍ਹਾਂ ਇਸ ਸਭ ਦਾ ਵਰਣਨ ਕਰਨ ਲਈ Confluence ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।

ਮੈਂ ਇਸ 'ਤੇ ਵਿਸਤਾਰ ਨਾਲ ਨਹੀਂ ਬੋਲਾਂਗਾ, ਕਿਉਂਕਿ ਰਿਪੋਰਟ ਇੰਟਰੈਕਸ਼ਨ ਅਭਿਆਸਾਂ ਬਾਰੇ ਜ਼ਿਆਦਾ ਹੈ, ਨਾ ਕਿ ਤਕਨੀਕੀ ਲਾਗੂ ਕਰਨ ਬਾਰੇ।

ਉਦਾਹਰਨ ਲਈ, ਸਾਨੂੰ ਸਮੱਸਿਆਵਾਂ ਆਈਆਂ ਹਨ ਜਿੱਥੇ ਸਰਵਰ 'ਤੇ ਕਠਪੁਤਲੀ ਰੂਬੀ 2 ਨਾਲ ਕੰਮ ਕਰਦੀ ਹੈ, ਪਰ ਕੁਝ ਐਪਲੀਕੇਸ਼ਨ ਰੂਬੀ 1.8 ਲਈ ਲਿਖੀ ਗਈ ਹੈ, ਅਤੇ ਉਹ ਇਕੱਠੇ ਕੰਮ ਨਹੀਂ ਕਰਦੇ ਹਨ। ਉਥੇ ਕੁਝ ਗਲਤ ਹੋ ਜਾਂਦਾ ਹੈ। ਅਤੇ ਜਦੋਂ ਤੁਹਾਨੂੰ ਇੱਕ ਮਸ਼ੀਨ 'ਤੇ ਰੂਬੀ ਦੇ ਕਈ ਸੰਸਕਰਣਾਂ ਨੂੰ ਚਲਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਸਮੱਸਿਆਵਾਂ ਆਉਣੀਆਂ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।

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

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

ਖੈਰ, ਇੱਥੇ ਵਿਵਾਦਪੂਰਨ ਨਿਰਭਰਤਾਵਾਂ ਹਨ, ਜਦੋਂ ਪ੍ਰੋਜੈਕਟ ਦਾ ਇੱਕ ਟੁਕੜਾ ਇੱਕ ਸੰਸਕਰਣ ਦੀ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਪ੍ਰੋਜੈਕਟ ਦਾ ਇੱਕ ਹੋਰ ਟੁਕੜਾ ਕਿਸੇ ਹੋਰ ਸੰਸਕਰਣ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਇਕੱਠੇ ਸਥਾਪਤ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਸਾਡੇ ਕੋਲ PHP 5.6 ਵਿੱਚ ਸਾਈਟਾਂ ਅਤੇ ਸੇਵਾਵਾਂ ਹਨ, ਅਸੀਂ ਉਹਨਾਂ ਤੋਂ ਸ਼ਰਮਿੰਦਾ ਹਾਂ, ਪਰ ਅਸੀਂ ਕੀ ਕਰ ਸਕਦੇ ਹਾਂ? ਇਹ ਸਾਡੀ ਇੱਕ ਸਾਈਟ ਹੈ. PHP 7 'ਤੇ ਸਾਈਟਾਂ ਅਤੇ ਸੇਵਾਵਾਂ ਹਨ, ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹੋਰ ਵੀ ਹਨ, ਅਸੀਂ ਉਨ੍ਹਾਂ ਤੋਂ ਸ਼ਰਮਿੰਦਾ ਨਹੀਂ ਹਾਂ। ਅਤੇ ਹਰੇਕ ਡਿਵੈਲਪਰ ਦਾ ਆਪਣਾ ਅਧਾਰ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ ਉਹ ਖੁਸ਼ੀ ਨਾਲ ਆਰੀ ਕਰਦਾ ਹੈ.

ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਕੰਪਨੀ ਵਿੱਚ ਇੱਕ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖਦੇ ਹੋ, ਤਾਂ ਪ੍ਰਤੀ ਡਿਵੈਲਪਰ ਤਿੰਨ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਆਮ ਲੱਗਦੀਆਂ ਹਨ। ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਵੱਖ-ਵੱਖ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਹਨ, ਤਾਂ ਸਥਿਤੀ ਹੋਰ ਵਿਗੜ ਜਾਂਦੀ ਹੈ।

ਤੁਹਾਡੇ ਕੋਲ ਇਸ 'ਤੇ ਸਾਈਟਾਂ ਅਤੇ ਸੇਵਾਵਾਂ ਹਨ, ਇਸ 'ਤੇ, ਫਿਰ ਗੋ ਲਈ ਇਕ ਹੋਰ ਸਾਈਟ, ਰੂਬੀ ਲਈ ਇਕ ਸਾਈਟ, ਅਤੇ ਸਾਈਡ 'ਤੇ ਕੁਝ ਹੋਰ ਰੈਡਿਸ ਹਨ। ਨਤੀਜੇ ਵਜੋਂ, ਇਹ ਸਭ ਸਮਰਥਨ ਲਈ ਇੱਕ ਵੱਡੇ ਖੇਤਰ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਹਰ ਸਮੇਂ ਇਸ ਵਿੱਚੋਂ ਕੁਝ ਟੁੱਟ ਸਕਦਾ ਹੈ।

ਇਸ ਲਈ, ਅਸੀਂ ਵੱਖ-ਵੱਖ ਫਰੇਮਵਰਕ ਦੀ ਵਰਤੋਂ ਨਾਲ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ ਦੇ ਫਾਇਦਿਆਂ ਨੂੰ ਬਦਲ ਦਿੱਤਾ ਹੈ, ਕਿਉਂਕਿ PHP ਫਰੇਮਵਰਕ ਬਹੁਤ ਵੱਖਰੇ ਹਨ, ਉਹਨਾਂ ਕੋਲ ਵੱਖਰੀਆਂ ਸਮਰੱਥਾਵਾਂ, ਵੱਖੋ-ਵੱਖਰੇ ਭਾਈਚਾਰੇ ਅਤੇ ਵੱਖੋ-ਵੱਖਰੇ ਸਮਰਥਨ ਹਨ। ਅਤੇ ਤੁਸੀਂ ਇੱਕ ਸੇਵਾ ਲਿਖ ਸਕਦੇ ਹੋ ਤਾਂ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇਸ ਲਈ ਕੁਝ ਤਿਆਰ ਹੋਵੇ।

ਹਰ ਸੇਵਾ ਦੀ ਆਪਣੀ ਟੀਮ ਹੁੰਦੀ ਹੈ

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

ਤੁਸੀਂ ਸਹਾਇਤਾ ਤੋਂ ਆਸਾਨੀ ਨਾਲ ਕੰਮ ਸਪੁਰਦ ਕਰ ਸਕਦੇ ਹੋ। ਉਦਾਹਰਨ ਲਈ, ਬੀਮਾ ਸੇਵਾ ਟੁੱਟ ਗਈ। ਅਤੇ ਤੁਰੰਤ ਬੀਮੇ ਨਾਲ ਨਜਿੱਠਣ ਵਾਲੀ ਟੀਮ ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਜਾਂਦੀ ਹੈ।

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

ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਆਪਣੀ ਸੇਵਾ ਨੂੰ ਤੋੜਦੇ ਹੋ, ਅਤੇ ਇਹ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਵਾਪਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਦੂਜੇ ਲੋਕਾਂ ਦੀਆਂ ਸੇਵਾਵਾਂ ਨੂੰ ਪ੍ਰਭਾਵਤ ਨਹੀਂ ਕੀਤਾ, ਅਤੇ ਹੋਰ ਟੀਮਾਂ ਦੇ ਵਿਕਾਸਕਾਰ ਤੁਹਾਡੇ ਕੋਲ ਬਿੱਟਾਂ ਨਾਲ ਨਹੀਂ ਆਉਂਦੇ ਅਤੇ ਕਹਿੰਦੇ ਹਨ: "ਐ-ਏ, ਅਜਿਹਾ ਨਾ ਕਰੋ।"

ਹਮੇਸ਼ਾ ਵਾਂਗ, ਸੂਖਮਤਾਵਾਂ ਹਨ. ਸਾਡੇ ਕੋਲ ਸਥਿਰ ਟੀਮਾਂ ਹਨ, ਪ੍ਰਬੰਧਕ ਟੀਮ ਨਾਲ ਜੁੜੇ ਹੋਏ ਹਨ। ਸਪੱਸ਼ਟ ਦਸਤਾਵੇਜ਼ ਹਨ, ਪ੍ਰਬੰਧਕ ਹਰ ਚੀਜ਼ ਦੀ ਨੇੜਿਓਂ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹਨ. ਪ੍ਰਬੰਧਕ ਦੇ ਨਾਲ ਹਰੇਕ ਟੀਮ ਵਿੱਚ ਕਈ ਸੇਵਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਯੋਗਤਾ ਦਾ ਇੱਕ ਖਾਸ ਬਿੰਦੂ ਹੁੰਦਾ ਹੈ।

ਜੇਕਰ ਟੀਮਾਂ ਤੈਰ ਰਹੀਆਂ ਹਨ (ਅਸੀਂ ਕਈ ਵਾਰ ਇਸਦੀ ਵਰਤੋਂ ਵੀ ਕਰਦੇ ਹਾਂ), ਤਾਂ "ਸਟਾਰ ਮੈਪ" ਨਾਮਕ ਇੱਕ ਵਧੀਆ ਤਰੀਕਾ ਹੈ।

ਤੁਹਾਡੇ ਕੋਲ ਸੇਵਾਵਾਂ ਅਤੇ ਲੋਕਾਂ ਦੀ ਸੂਚੀ ਹੈ। ਇੱਕ ਤਾਰੇ ਦਾ ਅਰਥ ਹੈ ਕਿ ਵਿਅਕਤੀ ਇਸ ਸੇਵਾ ਵਿੱਚ ਮਾਹਰ ਹੈ, ਇੱਕ ਕਿਤਾਬ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਵਿਅਕਤੀ ਇਸ ਸੇਵਾ ਦਾ ਅਧਿਐਨ ਕਰ ਰਿਹਾ ਹੈ। ਵਿਅਕਤੀ ਦਾ ਕੰਮ ਤਾਰੇ ਲਈ ਪੁਸਤਿਕਾ ਨੂੰ ਬਦਲਣਾ ਹੈ। ਅਤੇ ਜੇ ਸੇਵਾ ਦੇ ਅੱਗੇ ਕੁਝ ਨਹੀਂ ਲਿਖਿਆ ਗਿਆ, ਤਾਂ ਸਮੱਸਿਆਵਾਂ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਜਿਸ ਬਾਰੇ ਮੈਂ ਅੱਗੇ ਗੱਲ ਕਰਾਂਗਾ.

ਅਨਾਥ ਸੇਵਾਵਾਂ ਕਿਵੇਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ?

ਪਹਿਲੀ ਸਮੱਸਿਆ, ਤੁਹਾਡੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਅਨਾਥ ਸੇਵਾ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਪਹਿਲਾ ਤਰੀਕਾ ਹੈ ਲੋਕਾਂ ਨੂੰ ਅੱਗ ਲਾਉਣਾ। ਕੰਮਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਕਦੇ ਕਿਸੇ ਨੇ ਵਪਾਰਕ ਸਮਾਂ ਸੀਮਾਵਾਂ ਨੂੰ ਪੂਰਾ ਕੀਤਾ ਹੈ? ਕਈ ਵਾਰ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ ਕਿ ਡੈੱਡਲਾਈਨ ਤੰਗ ਹੁੰਦੀ ਹੈ ਅਤੇ ਦਸਤਾਵੇਜ਼ਾਂ ਲਈ ਕਾਫ਼ੀ ਸਮਾਂ ਨਹੀਂ ਹੁੰਦਾ. "ਸਾਨੂੰ ਸੇਵਾ ਨੂੰ ਉਤਪਾਦਨ ਲਈ ਸੌਂਪਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਫਿਰ ਅਸੀਂ ਇਸਨੂੰ ਜੋੜਾਂਗੇ।"

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

ਉਸੇ ਸਮੇਂ, ਸਹਾਇਤਾ ਅਤੇ ਕਾਰੋਬਾਰ ਤੋਂ ਕੰਮ ਅਲੋਪ ਨਹੀਂ ਹੁੰਦੇ; ਉਹ ਬੈਕਲਾਗ ਵਿੱਚ ਖਤਮ ਹੁੰਦੇ ਹਨ. ਜੇ ਸੇਵਾ ਦੇ ਵਿਕਾਸ ਦੌਰਾਨ ਕੋਈ ਆਰਕੀਟੈਕਚਰਲ ਗਲਤੀਆਂ ਸਨ, ਤਾਂ ਉਹ ਬੈਕਲਾਗ ਵਿੱਚ ਵੀ ਖਤਮ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਸੇਵਾ ਹੌਲੀ-ਹੌਲੀ ਵਿਗੜ ਰਹੀ ਹੈ।

ਅਨਾਥ ਦੀ ਪਛਾਣ ਕਿਵੇਂ ਕਰੀਏ?

ਇਹ ਸੂਚੀ ਸਥਿਤੀ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਬਿਆਨ ਕਰਦੀ ਹੈ। ਉਨ੍ਹਾਂ ਦੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਬਾਰੇ ਕਿਸ ਨੇ ਕੁਝ ਸਿੱਖਿਆ?

ਦਸਤਾਵੇਜ਼ੀ ਕੰਮ ਦੇ ਆਲੇ ਦੁਆਲੇ: ਇੱਥੇ ਇੱਕ ਸੇਵਾ ਹੈ ਅਤੇ, ਆਮ ਤੌਰ 'ਤੇ, ਇਹ ਕੰਮ ਕਰਦੀ ਹੈ, ਇਸਦੇ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਹੈ ਇਸ ਬਾਰੇ ਦੋ-ਪੰਨਿਆਂ ਦਾ ਮੈਨੂਅਲ ਹੈ, ਪਰ ਕੋਈ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਇਹ ਅੰਦਰ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ।

ਜਾਂ, ਉਦਾਹਰਨ ਲਈ, ਇੱਥੇ ਕੁਝ ਕਿਸਮ ਦਾ ਲਿੰਕ ਸ਼ਾਰਟਨਰ ਹੈ. ਉਦਾਹਰਨ ਲਈ, ਸਾਡੇ ਕੋਲ ਵਰਤਮਾਨ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਸੇਵਾਵਾਂ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਉਦੇਸ਼ਾਂ ਲਈ ਵਰਤੋਂ ਵਿੱਚ ਤਿੰਨ ਲਿੰਕ ਸ਼ਾਰਟਨਰ ਹਨ। ਇਹ ਸਿਰਫ ਨਤੀਜੇ ਹਨ.

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

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

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

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

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

ਮੈਂ ਕਪਤਾਨੀ ਕਰਨਾ ਜਾਰੀ ਰੱਖਾਂਗਾ। ਆਊਟਸੋਰਸਡ ਸੇਵਾ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਇੱਕ ਲਾਜ਼ਮੀ ਪ੍ਰਕਿਰਿਆ ਹੈ। ਕੀ ਕਦੇ ਕਿਸੇ ਕੋਲ ਆਊਟਸੋਰਸਡ ਸੇਵਾ ਆਈ ਹੈ ਅਤੇ ਕਿਤੇ ਵੀ ਸਵੀਕਾਰ ਨਹੀਂ ਕੀਤੀ ਗਈ ਹੈ? ਇਹ ਇੱਕ ਅਨਾਥ ਸੇਵਾ ਦੇ ਰੂਪ ਵਿੱਚ, ਬੇਸ਼ਕ, ਪ੍ਰਸਿੱਧ ਨਹੀਂ ਹੈ, ਪਰ ਫਿਰ ਵੀ.

ਸੇਵਾ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਸੇਵਾ ਦੀ ਸਮੀਖਿਆ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਪਾਸਵਰਡ ਬਦਲਣ ਦੀ ਲੋੜ ਹੈ। ਸਾਡੇ ਕੋਲ ਇੱਕ ਕੇਸ ਸੀ ਜਦੋਂ ਉਹਨਾਂ ਨੇ ਸਾਨੂੰ ਇੱਕ ਸੇਵਾ ਦਿੱਤੀ ਸੀ, ਉੱਥੇ ਇੱਕ ਐਡਮਿਨ ਪੈਨਲ ਹੁੰਦਾ ਹੈ "ਜੇ ਲੌਗਇਨ == 'ਐਡਮਿਨ' && ਪਾਸਵਰਡ == 'ਐਡਮਿਨ'...", ਇਹ ਕੋਡ ਵਿੱਚ ਲਿਖਿਆ ਹੋਇਆ ਹੈ। ਅਸੀਂ ਬੈਠ ਕੇ ਸੋਚਦੇ ਹਾਂ, ਅਤੇ ਲੋਕ ਇਹ 2018 ਵਿੱਚ ਲਿਖਦੇ ਹਨ?

ਸਟੋਰੇਜ ਸਮਰੱਥਾ ਦੀ ਜਾਂਚ ਵੀ ਜ਼ਰੂਰੀ ਚੀਜ਼ ਹੈ। ਤੁਹਾਨੂੰ ਇਹ ਦੇਖਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਇੱਕ ਲੱਖ ਰਿਕਾਰਡਾਂ 'ਤੇ ਕੀ ਹੋਵੇਗਾ, ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਇਸ ਸੇਵਾ ਨੂੰ ਕਿਤੇ ਉਤਪਾਦਨ ਵਿੱਚ ਪਾਓ।

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

ਸਾਡੇ ਕੋਲ ਇੱਕ ਕੇਸ ਸੀ ਜਦੋਂ ਅਸੀਂ ਇੱਕ ਪਾਇਲਟ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਆਊਟਸੋਰਸ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਸੀ।

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

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

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

ਅਨਾਥਾਂ ਨਾਲ ਕੀ ਸਮੱਸਿਆ ਹੈ?

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

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

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

ਅਨਾਥ ਸੇਵਾਵਾਂ ਖ਼ਤਰਨਾਕ ਕਿਉਂ ਹਨ:

• ਸੇਵਾ ਅਚਾਨਕ ਟੁੱਟ ਸਕਦੀ ਹੈ।
• ਸੇਵਾ ਦੀ ਮੁਰੰਮਤ ਵਿੱਚ ਲੰਬਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ ਜਾਂ ਬਿਲਕੁਲ ਵੀ ਮੁਰੰਮਤ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ।
• ਸੁਰੱਖਿਆ ਸਮੱਸਿਆਵਾਂ।
• ਸੁਧਾਰਾਂ ਅਤੇ ਅੱਪਡੇਟਾਂ ਨਾਲ ਸਮੱਸਿਆਵਾਂ।
• ਜੇ ਕੋਈ ਮਹੱਤਵਪੂਰਨ ਸੇਵਾ ਟੁੱਟ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਕੰਪਨੀ ਦੀ ਸਾਖ ਨੂੰ ਨੁਕਸਾਨ ਹੁੰਦਾ ਹੈ।

ਅਨਾਥ ਸੇਵਾਵਾਂ ਦਾ ਕੀ ਕਰਨਾ ਹੈ?

ਮੈਂ ਦੁਹਰਾਵਾਂਗਾ ਕਿ ਕੀ ਕਰਨਾ ਹੈ। ਪਹਿਲਾਂ, ਦਸਤਾਵੇਜ਼ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ. Banki.ru 'ਤੇ 7 ਸਾਲਾਂ ਨੇ ਮੈਨੂੰ ਸਿਖਾਇਆ ਕਿ ਟੈਸਟਰਾਂ ਨੂੰ ਡਿਵੈਲਪਰਾਂ ਦੀ ਗੱਲ ਨਹੀਂ ਲੈਣੀ ਚਾਹੀਦੀ, ਅਤੇ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਹਰ ਕਿਸੇ ਦੀ ਗੱਲ ਨਹੀਂ ਲੈਣੀ ਚਾਹੀਦੀ। ਸਾਨੂੰ ਜਾਂਚ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

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

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

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

ਕਿਸੇ ਅਨਾਥ ਸੇਵਾ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਓ

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

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

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

ਭਾਵ, ਤੁਸੀਂ ਸੇਵਾ ਲਈ ਲੋੜਾਂ ਨੂੰ ਨਵੇਂ ਸਿਰਿਓਂ ਲੈਂਦੇ ਹੋ ਅਤੇ ਇੱਕ ਨਵੀਂ ਸੇਵਾ ਲਿਖਦੇ ਹੋ, ਬਿਹਤਰ, ਇੱਕ ਬਿਹਤਰ ਪਲੇਟਫਾਰਮ 'ਤੇ, ਅਜੀਬ ਤਕਨੀਕੀ ਹੱਲਾਂ ਦੇ ਬਿਨਾਂ। ਅਤੇ ਤੁਸੀਂ ਲੜਾਈ ਵਿੱਚ ਇਸ ਵੱਲ ਪਰਵਾਸ ਕਰਦੇ ਹੋ।

ਸਾਡੇ ਕੋਲ ਅਜਿਹੀ ਸਥਿਤੀ ਸੀ ਜਦੋਂ ਅਸੀਂ Yii 1 'ਤੇ ਇੱਕ ਸੇਵਾ ਲਈ ਅਤੇ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਅਸੀਂ ਇਸਨੂੰ ਹੋਰ ਵਿਕਸਤ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਡਿਵੈਲਪਰਾਂ ਦੀ ਕਮੀ ਸੀ ਜੋ Yii 1 'ਤੇ ਵਧੀਆ ਲਿਖ ਸਕਦੇ ਸਨ। ਸਾਰੇ ਡਿਵੈਲਪਰ Symfony XNUMX 'ਤੇ ਵਧੀਆ ਲਿਖਦੇ ਹਨ। ਮੈਂ ਕੀ ਕਰਾਂ? ਅਸੀਂ ਸਮਾਂ ਨਿਰਧਾਰਤ ਕੀਤਾ, ਇੱਕ ਟੀਮ ਨਿਰਧਾਰਤ ਕੀਤੀ, ਇੱਕ ਮੈਨੇਜਰ ਨਿਰਧਾਰਤ ਕੀਤਾ, ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਿਆ ਅਤੇ ਆਵਾਜਾਈ ਨੂੰ ਸੁਚਾਰੂ ਰੂਪ ਵਿੱਚ ਬਦਲਿਆ।

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

ਇਹ ਉਹੀ ਹੈ ਜਿਸ ਬਾਰੇ ਮੈਂ ਗੱਲ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ, ਮੈਂ ਚਰਚਾ ਕਰਨ ਲਈ ਤਿਆਰ ਹਾਂ, ਵਿਸ਼ਾ ਹੋਲੀਵਰ ਹੈ, ਬਹੁਤ ਸਾਰੇ ਇਸ ਵਿੱਚ ਤੈਰ ਗਏ ਹਨ।

ਸਲਾਈਡਾਂ ਨੇ ਕਿਹਾ ਕਿ ਤੁਸੀਂ ਭਾਸ਼ਾਵਾਂ ਨੂੰ ਏਕੀਕ੍ਰਿਤ ਕੀਤਾ ਹੈ। ਇੱਕ ਉਦਾਹਰਣ ਤਸਵੀਰਾਂ ਦਾ ਆਕਾਰ ਬਦਲਣਾ ਸੀ। ਕੀ ਇਸ ਨੂੰ ਇੱਕ ਭਾਸ਼ਾ ਤੱਕ ਸੀਮਤ ਕਰਨਾ ਸੱਚਮੁੱਚ ਜ਼ਰੂਰੀ ਹੈ? ਕਿਉਂਕਿ PHP ਵਿੱਚ ਚਿੱਤਰ ਦਾ ਆਕਾਰ ਬਦਲਣਾ, ਅਸਲ ਵਿੱਚ ਗੋਲੰਗ ਵਿੱਚ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ.

ਅਸਲ ਵਿੱਚ, ਇਹ ਸਾਰੇ ਅਭਿਆਸਾਂ ਵਾਂਗ ਵਿਕਲਪਿਕ ਹੈ। ਸ਼ਾਇਦ, ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਇਹ ਅਣਚਾਹੇ ਵੀ ਹੈ. ਪਰ ਤੁਹਾਨੂੰ ਇਹ ਸਮਝਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ 50 ਲੋਕਾਂ ਦੀ ਇੱਕ ਕੰਪਨੀ ਵਿੱਚ ਤਕਨੀਕੀ ਵਿਭਾਗ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਵਿੱਚੋਂ 45 PHP ਮਾਹਰ ਹਨ, ਹੋਰ 3 ਡਿਵੋਪ ਹਨ ਜੋ Python, Ansible, Puppet ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਕੋਈ ਚੀਜ਼ ਜਾਣਦੇ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਕੁਝ ਵਿੱਚ ਲਿਖਦਾ ਹੈ। ਭਾਸ਼ਾ ਦੀ ਕਿਸਮ। ਕੁਝ ਗੋ ਇਮੇਜ ਰੀਸਾਈਜ਼ਿੰਗ ਸੇਵਾ, ਫਿਰ ਜਦੋਂ ਇਹ ਛੱਡਦੀ ਹੈ, ਮਹਾਰਤ ਇਸਦੇ ਨਾਲ ਜਾਂਦੀ ਹੈ। ਅਤੇ ਉਸੇ ਸਮੇਂ, ਤੁਹਾਨੂੰ ਇੱਕ ਮਾਰਕੀਟ-ਵਿਸ਼ੇਸ਼ ਡਿਵੈਲਪਰ ਦੀ ਭਾਲ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੋਏਗੀ ਜੋ ਇਸ ਭਾਸ਼ਾ ਨੂੰ ਜਾਣਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜੇ ਇਹ ਬਹੁਤ ਘੱਟ ਹੈ. ਭਾਵ, ਸੰਗਠਨਾਤਮਕ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਇਹ ਸਮੱਸਿਆ ਵਾਲਾ ਹੈ. ਵਿਕਾਸ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਪਲੇਬੁੱਕਾਂ ਦੇ ਕੁਝ ਤਿਆਰ-ਕੀਤੇ ਸੈੱਟਾਂ ਨੂੰ ਕਲੋਨ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਵੇਗੀ ਜੋ ਤੁਸੀਂ ਸੇਵਾਵਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਵਰਤਦੇ ਹੋ, ਪਰ ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਾ ਪਵੇਗਾ।

ਅਸੀਂ ਵਰਤਮਾਨ ਵਿੱਚ Node.js 'ਤੇ ਇੱਕ ਸੇਵਾ ਬਣਾ ਰਹੇ ਹਾਂ, ਅਤੇ ਇਹ ਇੱਕ ਵੱਖਰੀ ਭਾਸ਼ਾ ਵਾਲੇ ਹਰੇਕ ਵਿਕਾਸਕਾਰ ਲਈ ਨੇੜੇ ਦਾ ਇੱਕ ਪਲੇਟਫਾਰਮ ਹੋਵੇਗਾ। ਪਰ ਅਸੀਂ ਬੈਠੇ ਅਤੇ ਸੋਚਿਆ ਕਿ ਖੇਡ ਮੋਮਬੱਤੀ ਦੀ ਕੀਮਤ ਸੀ. ਯਾਨੀ ਇਹ ਤੁਹਾਡੇ ਲਈ ਬੈਠ ਕੇ ਸੋਚਣ ਦਾ ਸਵਾਲ ਹੈ।

ਤੁਸੀਂ ਆਪਣੀਆਂ ਸੇਵਾਵਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਿਵੇਂ ਕਰਦੇ ਹੋ? ਤੁਸੀਂ ਲੌਗਸ ਨੂੰ ਕਿਵੇਂ ਇਕੱਠਾ ਅਤੇ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹੋ?

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

ਇੱਕੋ ਮਾਹੌਲ ਵਿੱਚ ਕਠਪੁਤਲੀ ਅਤੇ ਜਵਾਬਦੇਹ ਨਾਲ ਕਿਵੇਂ ਰਹਿਣਾ ਹੈ?

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

ਤੁਸੀਂ ਅਨੁਕੂਲਤਾ ਕਿਵੇਂ ਬਣਾਈ ਰੱਖਦੇ ਹੋ? ਕੀ ਤੁਹਾਡੇ ਕੋਲ ਜਵਾਬੀ ਅਤੇ ਕਠਪੁਤਲੀ ਦੋਵਾਂ ਵਿੱਚ ਸੰਰਚਨਾ ਹਨ?

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

ਪੇਸ਼ਕਾਰੀ ਰੂਬੀ ਦੇ ਵੱਖ-ਵੱਖ ਸੰਸਕਰਣਾਂ ਬਾਰੇ ਸੀ। ਕੀ ਹੱਲ?

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

ਇਸ ਸਾਲ ਦੀ ਕਾਨਫਰੰਸ DevOpsDays ਮਾਸਕੋ 7 ਦਸੰਬਰ ਨੂੰ ਟੈਕਨੋਪੋਲਿਸ ਵਿਖੇ ਹੋਵੇਗੀ। ਅਸੀਂ 11 ਨਵੰਬਰ ਤੱਕ ਰਿਪੋਰਟਾਂ ਲਈ ਅਰਜ਼ੀਆਂ ਸਵੀਕਾਰ ਕਰ ਰਹੇ ਹਾਂ। ਲਿਖੋ ਜੇਕਰ ਤੁਸੀਂ ਬੋਲਣਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਸਾਨੂੰ।

ਭਾਗੀਦਾਰਾਂ ਲਈ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਖੁੱਲੀ ਹੈ, ਸਾਡੇ ਨਾਲ ਜੁੜੋ!

ਸਰੋਤ: www.habr.com