ਸਟੇਟਸ ਪੇਜ ਕਿਵੇਂ ਬਣਾਈਏ: ਕੰਪੋਨੈਂਟ, ਇਨਸੀਡੈਂਟ ਅਤੇ ਅੱਪਟਾਈਮ ਜਾਂਚਾਂ

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

ਸਟੇਟਸ ਪੇਜ ਕਿਸ ਲਈ ਹੈ

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

ਇਹ ਚੇਂਜਲੌਗ ਨਹੀਂ ਹੈ। ਨਵੇਂ ਫੀਚਰ ਚੇਂਜਲੌਗ ਪੇਜ 'ਤੇ ਜਾਂਦੇ ਹਨ; ਆਊਟੇਜ ਅਤੇ ਮੇਨਟੇਨੈਂਸ ਇੱਥੇ ਜਾਂਦੇ ਹਨ।

ਪੇਜ ਨੂੰ ਕੀ ਚਾਹੀਦਾ ਹੈ

ਡੇਟਾ

ਕੰਪੋਨੈਂਟ ਸਟੇਟਸ ਆਮ ਤੌਰ 'ਤੇ ਛੋਟੀ ਜਿਹੀ ਤੈਅ ਸੂਚੀ ਹੁੰਦੇ ਹਨ: Operational, Degraded performance, Partial outage, Major outage, Under maintenance।

ਪੇਜ

• ਜਨਤਕ ਸਟੇਟਸ ਪੇਜ: ਇੱਕ ਸਮੁੱਚਾ ਬੈਨਰ ("All systems operational" ਜਾਂ ਸਭ ਤੋਂ ਮਾੜਾ ਮੌਜੂਦਾ ਸਟੇਟਸ), ਹਰ ਕੰਪੋਨੈਂਟ ਆਪਣੇ ਸਟੇਟਸ ਨਾਲ, ਕੋਈ ਵੀ ਚੱਲ ਰਿਹਾ ਇਨਸੀਡੈਂਟ ਆਪਣੇ ਅੱਪਡੇਟਾਂ ਨਾਲ, ਆਉਣ ਵਾਲੀ ਮੇਨਟੇਨੈਂਸ, ਅਤੇ ਜੇ ਚੈੱਕ ਡੇਟਾ ਹੈ ਤਾਂ 90 ਦਿਨਾਂ ਦੀ ਹਿਸਟਰੀ ਸਟ੍ਰਿਪ।
• ਇਨਸੀਡੈਂਟ ਪੇਜ: ਇੱਕ ਇਨਸੀਡੈਂਟ ਦੇ ਸਾਰੇ ਅੱਪਡੇਟਾਂ ਦੀ ਪੂਰੀ ਟਾਈਮਲਾਈਨ, ਆਪਣੇ URL ਨਾਲ ਤਾਂ ਜੋ ਸਪੋਰਟ ਇਸਦਾ ਲਿੰਕ ਦੇ ਸਕੇ।
• ਹਿਸਟਰੀ: ਪਿਛਲੇ ਇਨਸੀਡੈਂਟ ਮਹੀਨੇ ਅਨੁਸਾਰ।
• ਸਬਸਕ੍ਰਾਈਬ: ਪੁਸ਼ਟੀ ਅਤੇ ਕੰਪੋਨੈਂਟ ਅਨੁਸਾਰ ਪਸੰਦਾਂ ਨਾਲ ਈਮੇਲ ਸਾਈਨ-ਅੱਪ।
• ਐਡਮਿਨ: ਇਨਸੀਡੈਂਟ ਬਣਾਉਣਾ, ਅੱਪਡੇਟ ਪੋਸਟ ਕਰਨਾ, ਕੰਪੋਨੈਂਟ ਸਟੇਟਸ ਬਦਲਣਾ, ਮੇਨਟੇਨੈਂਸ ਤੈਅ ਕਰਨਾ।

ਇਜਾਜ਼ਤਾਂ

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

ਸਭ ਤੋਂ ਅਹਿਮ ਫੈਸਲਾ: ਇਸਨੂੰ ਆਜ਼ਾਦ ਰੱਖੋ

ਘਰੇਲੂ ਸਟੇਟਸ ਪੇਜ ਅਕਸਰ ਇੱਥੇ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ। ਜੇ ਤੁਹਾਡਾ ਸਟੇਟਸ ਪੇਜ:

• ਤੁਹਾਡੀ ਐਪ ਵਾਲੇ ਸਰਵਰ ਜਾਂ ਹੋਸਟਿੰਗ ਖਾਤੇ 'ਤੇ ਚੱਲਦਾ ਹੈ,
• ਉਸੇ ਡੇਟਾਬੇਸ ਤੋਂ ਪੜ੍ਹਦਾ ਹੈ,
• ਉਸੇ ਡੋਮੇਨ ਸੈੱਟਅੱਪ ਜਾਂ CDN ਕੌਂਫਿਗਰੇਸ਼ਨ ਪਿੱਛੇ ਹੈ,
• ਜਾਂ ਉਸੇ ਪਾਈਪਲਾਈਨ ਨਾਲ ਡਿਪਲੌਏ ਹੁੰਦਾ ਹੈ,

ਤਾਂ ਬਹੁਤ ਸਾਰੀਆਂ ਆਊਟੇਜਾਂ ਇਸਨੂੰ ਵੀ ਡਾਊਨ ਕਰ ਦੇਣਗੀਆਂ, ਠੀਕ ਉਸ ਵੇਲੇ ਜਦੋਂ ਲੋਕਾਂ ਨੂੰ ਇਸਦੀ ਸਭ ਤੋਂ ਵੱਧ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਵਿਹਾਰਕ ਕਦਮ:

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

ਹੱਥੀਂ ਅੱਪਡੇਟ ਜਾਂ ਆਟੋਮੇਟਿਡ ਜਾਂਚਾਂ

ਹੱਥੀਂ (ਇੱਥੋਂ ਸ਼ੁਰੂ ਕਰੋ)

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

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

ਆਟੋਮੇਟਿਡ

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

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

ਹੌਲੀ ਨੈੱਟਵਰਕ 'ਤੇ ਆਟੋਮੇਟਿਡ ਬਦਲਾਅ ਫਲੈਪ ਕਰ ਸਕਦੇ ਹਨ (ਉੱਪਰ, ਹੇਠਾਂ, ਫਿਰ ਉੱਪਰ)। ਸਟੇਟਸ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋ-ਤਿੰਨ ਲਗਾਤਾਰ ਫੇਲ੍ਹ ਮੰਗੋ, ਅਤੇ ਵੱਡੀ ਆਊਟੇਜ ਐਲਾਨਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿਸੇ ਮਨੁੱਖ ਤੋਂ ਪੁਸ਼ਟੀ ਕਰਵਾਓ।

ਇਨਸੀਡੈਂਟ ਅੱਪਡੇਟ ਕਿਵੇਂ ਲਿਖੋ

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

ਇੱਕ ਪਹਿਲਾ ਪ੍ਰੋਂਪਟ ਜੋ ਕੰਮ ਕਰਦਾ ਹੈ

Parcelio ਐਪ ਲਈ ਇੱਕ ਸੁਤੰਤਰ ਸਟੇਟਸ ਪੇਜ ਬਣਾਓ, ਜੋ status.parcelio.com 'ਤੇ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਹੋਸਟ ਹੋਵੇ। ਕੰਪੋਨੈਂਟ: Website, Tracking API, Notifications, Payments, ਹਰ ਇੱਕ ਦਾ ਸਟੇਟਸ Operational, Degraded performance, Partial outage, Major outage ਜਾਂ Under maintenance। ਜਨਤਕ ਪੇਜ ਸਭ ਤੋਂ ਮਾੜੇ ਮੌਜੂਦਾ ਸਟੇਟਸ ਵਾਲਾ ਸਮੁੱਚਾ ਬੈਨਰ, ਹਰ ਕੰਪੋਨੈਂਟ ਆਪਣੇ ਸਟੇਟਸ ਨਾਲ, ਕੋਈ ਵੀ ਚੱਲ ਰਿਹਾ ਇਨਸੀਡੈਂਟ ਟਾਈਮਸਟੈਂਪ ਵਾਲੇ ਅੱਪਡੇਟਾਂ ਨਾਲ (ਸਭ ਤੋਂ ਨਵਾਂ ਉੱਪਰ), ਆਉਣ ਵਾਲੀ ਮੇਨਟੇਨੈਂਸ, ਅਤੇ ਮਹੀਨੇ ਅਨੁਸਾਰ ਪਿਛਲੇ ਇਨਸੀਡੈਂਟਾਂ ਦੀ ਸੂਚੀ ਦਿਖਾਏ। ਹਰ ਇਨਸੀਡੈਂਟ ਦਾ ਆਪਣਾ ਪੇਜ ਹੋਵੇ। ਇੱਕ ਪਾਸਵਰਡ-ਸੁਰੱਖਿਅਤ ਐਡਮਿਨ ਪੇਜ ਜੋੜੋ ਜੋ ਇਨਸੀਡੈਂਟ ਬਣਾਏ (ਸਿਰਲੇਖ, ਪ੍ਰਭਾਵ, ਪ੍ਰਭਾਵਿਤ ਕੰਪੋਨੈਂਟ), ਅੱਪਡੇਟ ਪੋਸਟ ਕਰੇ (ਸੁਨੇਹਾ ਅਤੇ ਸਟੇਟਸ: Investigating, Identified, Monitoring, Resolved), ਕੰਪੋਨੈਂਟ ਸਟੇਟਸ ਬਦਲੇ ਅਤੇ ਮੇਨਟੇਨੈਂਸ ਤੈਅ ਕਰੇ। ਇੱਕ POST /api/check-result ਐਂਡਪੁਆਇੰਟ ਜੋੜੋ ਜੋ ਬਾਹਰੀ ਮਾਨੀਟਰ ਤੋਂ ਕੰਪੋਨੈਂਟ ਦਾ ਨਾਮ ਅਤੇ up/down ਲਵੇ, ਇੱਕ ਸੀਕ੍ਰੇਟ ਟੋਕਨ ਨਾਲ ਸੁਰੱਖਿਅਤ ਹੋਵੇ, ਅਤੇ ਕੰਪੋਨੈਂਟ ਨੂੰ ਸਿਰਫ਼ ਤਿੰਨ ਲਗਾਤਾਰ downs ਤੋਂ ਬਾਅਦ Degraded ਕਰੇ। ਸਭ ਕੁਝ ਇਸ ਐਪ ਦੇ ਆਪਣੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸੰਭਾਲੋ। ਸਧਾਰਨ, ਸ਼ਾਂਤ ਡਿਜ਼ਾਈਨ ਜੋ ਫ਼ੋਨਾਂ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਲੋਡ ਹੋਵੇ।

ਬਿਲਡ ਦੇ ਕਦਮ

1. ਜਨਤਕ ਪੇਜ ਅਤੇ ਹੱਥੀਂ ਇਨਸੀਡੈਂਟਾਂ ਵਾਲਾ ਐਡਮਿਨ। ਇੰਨਾ ਹੀ ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲਾ ਸਟੇਟਸ ਪੇਜ ਹੈ।
2. ਇਸਨੂੰ ਵੱਖਰਾ ਹੋਸਟ ਕਰੋ ਅਤੇ ਇੱਕ ਸਬਡੋਮੇਨ ਇਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰੋ।
3. ਇਨਸੀਡੈਂਟ ਪੇਜ ਅਤੇ ਹਿਸਟਰੀ।
4. ਮੇਨਟੇਨੈਂਸ ਵਿੰਡੋ।
5. ਸਬਸਕ੍ਰਿਪਸ਼ਨਾਂ। ਡਬਲ ਓਪਟ-ਇਨ ਈਮੇਲ ਸਾਈਨ-ਅੱਪ ਅਤੇ ਨਵੇਂ ਇਨਸੀਡੈਂਟਾਂ ਅਤੇ ਅੱਪਡੇਟਾਂ 'ਤੇ ਸੂਚਨਾਵਾਂ। ਈਮੇਲ ਲਈ ਇੱਕ ਪ੍ਰਦਾਤਾ ਚਾਹੀਦਾ ਹੈ; ਦੇਖੋ ਐਪ ਤੋਂ ਈਮੇਲ ਕਿਵੇਂ ਭੇਜੀਏ।
6. ਮਾਨੀਟਰ ਵੈਬਹੁੱਕ, ਜੇ ਤੁਸੀਂ ਆਟੋਮੇਟਿਡ ਸਟੇਟਸ ਬਦਲਾਅ ਚਾਹੁੰਦੇ ਹੋ।
7. ਇੱਕ ਡ੍ਰਿੱਲ ਚਲਾਓ। ਇੱਕ ਨਕਲੀ ਇਨਸੀਡੈਂਟ ਬਣਾਓ, ਅੱਪਡੇਟ ਪੋਸਟ ਕਰੋ, ਠੀਕ ਕਰੋ, ਈਮੇਲਾਂ ਚੈੱਕ ਕਰੋ, ਫਿਰ ਮਿਟਾ ਦਿਓ।

ਆਮ ਗਲਤੀਆਂ

• ਇਸਨੂੰ ਐਪ ਨਾਲ ਹੋਸਟ ਕਰਨਾ। ਸਭ ਤੋਂ ਆਮ ਅਤੇ ਸਭ ਤੋਂ ਗੰਭੀਰ ਗਲਤੀ।
• ਇੱਕ ਪੇਜ ਜੋ ਹਮੇਸ਼ਾ "All systems operational" ਕਹੇ। ਜੇ ਇਹ ਕਦੇ ਸਮੱਸਿਆ ਨਹੀਂ ਦਿਖਾਉਂਦਾ, ਤਾਂ ਯੂਜ਼ਰ ਇਸ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਛੱਡ ਦਿੰਦੇ ਹਨ।
• ਕੋਈ ਟਾਈਮਸਟੈਂਪ ਜਾਂ ਟਾਈਮ ਜ਼ੋਨ ਨਹੀਂ। ਸਮਾਂ ਹਮੇਸ਼ਾ ਜ਼ੋਨ ਸਮੇਤ ਦਿਖਾਓ।
• ਐਡਮਿਨ ਪੇਜ ਲਈ ਆਪਣੀ ਮੁੱਖ ਐਪ ਦੇ ਲੌਗਇਨ 'ਤੇ ਨਿਰਭਰ ਹੋਣਾ।
• ਅੱਪਡੇਟਾਂ ਵਿਚਕਾਰ ਚੁੱਪ। "ਕੋਈ ਬਦਲਾਅ ਨਹੀਂ, ਅਜੇ ਵੀ ਕੰਮ ਕਰ ਰਹੇ ਹਾਂ" ਇੱਕ ਠੀਕ ਅੱਪਡੇਟ ਹੈ।
• ਆਟੋਮੇਟਿਡ ਸਟੇਟਸ ਦਾ ਫਲੈਪ ਹੋਣਾ। ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਵਾਰ-ਵਾਰ ਫੇਲ੍ਹ ਮੰਗੋ।

ਕਦੋਂ ਹੋਸਟਡ ਸਟੇਟਸ ਪੇਜ ਸੇਵਾ ਬਿਹਤਰ ਹੈ

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

ਆਪਣਾ ਬਣਾਓ ਜਦੋਂ ਤੁਸੀਂ ਡਿਜ਼ਾਈਨ ਅਤੇ ਸ਼ਬਦਾਵਲੀ ਦਾ ਪੂਰਾ ਕੰਟਰੋਲ ਚਾਹੁੰਦੇ ਹੋ, ਜਦੋਂ ਤੁਹਾਡੀਆਂ ਲੋੜਾਂ ਸਧਾਰਨ ਹਨ (ਕੁਝ ਕੰਪੋਨੈਂਟ, ਹੱਥੀਂ ਅੱਪਡੇਟ), ਜਾਂ ਜਦੋਂ ਸਟੇਟਸ ਪੇਜ ਕਿਸੇ ਉਤਪਾਦ ਦਾ ਹਿੱਸਾ ਹੈ ਜੋ ਤੁਸੀਂ ਦੂਜਿਆਂ ਲਈ ਬਣਾ ਰਹੇ ਹੋ।

Mythex ਨਾਲ ਬਣਾਉਣਾ

Mythex 'ਤੇ ਤੁਸੀਂ ਸਟੇਟਸ ਪੇਜ ਨੂੰ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟ ਵਜੋਂ ਬਣਾ ਸਕਦੇ ਹੋ, ਆਪਣੀ ਮੁੱਖ ਐਪ ਤੋਂ ਵੱਖਰਾ, ਜਿਸਨੂੰ ਵੱਖਰੀ ਹੋਸਟਿੰਗ ਅਤੇ ਆਪਣਾ ਡੇਟਾਬੇਸ ਮਿਲਦਾ ਹੈ। ਚੈਟ ਵਿੱਚ ਦੱਸੋ, ਲਾਈਵ ਪ੍ਰੀਵਿਊ ਵਿੱਚ ਜਾਂਚੋ, ਫਿਰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ ਅਤੇ status.yourdomain.com ਵਰਗਾ ਸਬਡੋਮੇਨ ਜੋੜੋ (ਕਸਟਮ ਡੋਮੇਨ Pro ਵਿੱਚ ਹਨ)। ਯਾਦ ਰੱਖੋ ਕਿ ਪ੍ਰਕਾਸ਼ਿਤ Mythex ਐਪਾਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਡੇਟਾਬੇਸ ਖਾਲੀ ਹੋਣ 'ਤੇ ਸੌਂ ਜਾਂਦੇ ਹਨ ਅਤੇ ਅਗਲੀ ਫੇਰੀ 'ਤੇ ਜਾਗਦੇ ਹਨ, ਇਸ ਲਈ ਸ਼ਾਂਤ ਸਮੇਂ ਤੋਂ ਬਾਅਦ ਪਹਿਲੀ ਵਾਰ ਲੋਡ ਹੋਣ ਵਿੱਚ ਵੱਧ ਸਮਾਂ ਲੱਗ ਸਕਦਾ ਹੈ; ਸਧਾਰਨ ਅਤੇ ਹਲਕਾ ਪੇਜ ਇਸ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।

Mythex ਆਪਣੇ ਆਪ ਸ਼ਡਿਊਲਡ ਜੌਬਾਂ ਦਾ ਦਸਤਾਵੇਜ਼ ਨਹੀਂ ਦਿੰਦਾ, ਇਸ ਲਈ ਆਟੋਮੇਟਿਡ ਜਾਂਚਾਂ ਲਈ ਬਾਹਰੀ ਅੱਪਟਾਈਮ ਮਾਨੀਟਰ ਵਰਤੋ ਜੋ ਤੁਹਾਡੇ ਸਟੇਟਸ ਪੇਜ ਦੇ ਵੈਬਹੁੱਕ ਐਂਡਪੁਆਇੰਟ ਨੂੰ ਕਾਲ ਕਰੇ (ਦੇਖੋ ਵੈਬਹੁੱਕ ਰੈਸਿਪੀ)। ਸਬਸਕ੍ਰਾਈਬਰਾਂ ਨੂੰ ਈਮੇਲ ਅਲਰਟ ਤੁਹਾਡੇ ਆਪਣੇ ਪ੍ਰਦਾਤਾ ਰਾਹੀਂ ਜਾਂਦੇ ਹਨ, ਕੀ ਪ੍ਰੋਜੈਕਟ ਸੀਕ੍ਰੇਟ ਵਜੋਂ ਸੰਭਾਲੀ ਕੁੰਜੀ ਨਾਲ (ਈਮੇਲ ਭੇਜਣ ਦੀ ਰੈਸਿਪੀ)।

ਸਵਾਲ