સ્ટેટસ પેજ કેવી રીતે બનાવવું: કમ્પોનન્ટ, ઇન્સિડન્ટ અને અપટાઇમ ચેક

સ્ટેટસ પેજ તમારા વપરાશકર્તાઓને એક જ જગ્યાએ બતાવે છે કે તમારી સેવા કામ કરે છે કે નહીં. તે બનાવવા માટે તમને કમ્પોનન્ટની યાદી (વેબસાઇટ, API, પેમેન્ટ, ઈમેલ), દરેકની વર્તમાન સ્થિતિ, સમયચિહ્નિત અપડેટ સાથેના ઇન્સિડન્ટ, ભૂતકાળના ઇન્સિડન્ટનો ઇતિહાસ અને વૈકલ્પિક રીતે સબ્સ્ક્રિપ્શનની જરૂર પડે છે, જેથી લોકોને તપાસ્યા વિના સમસ્યાની જાણ થાય. પેજ પોતે સરળ છે. મહત્વનો નિર્ણય એ છે કે તે ક્યાં ચાલશે: સ્ટેટસ પેજ ત્યારે પણ ચાલુ રહેવું જોઈએ જ્યારે તમારી એપ બંધ હોય, એટલે તેણે જે વસ્તુની જાણ કરે છે તેની સાથે હોસ્ટિંગ, ડેટાબેઝ કે ડિપ્લોય પાઇપલાઇન શેર ન કરવી જોઈએ.

સ્ટેટસ પેજ શા માટે છે

કંઈક તૂટે ત્યારે વપરાશકર્તાઓને ત્રણ વાત જાણવી હોય છે: શું આ માત્ર મારી સાથે છે, શું તમને ખબર છે, અને તેનું સમારકામ ક્યારે થશે. સ્ટેટસ પેજ સપોર્ટ ટિકિટોના ઢગલા વિના આ ત્રણેયના જવાબ આપે છે. સમય જતાં તે વિશ્વાસ પણ બાંધે છે, કારણ કે દેખાતો ઇન્સિડન્ટ ઇતિહાસ અને પ્રામાણિક અહેવાલ બતાવે છે કે તમે સમસ્યાઓ કેવી રીતે સંભાળો છો.

તે ચેન્જલોગ નથી. નવી સુવિધાઓ ચેન્જલોગ પેજ પર જાય છે; આઉટેજ અને જાળવણી અહીં જાય છે.

પેજને શું જોઈએ

ડેટા

કમ્પોનન્ટની સ્થિતિઓ સામાન્ય રીતે ટૂંકી નિશ્ચિત યાદી હોય છે: Operational, Degraded performance, Partial outage, Major outage, Under maintenance.

પેજ

• સાર્વજનિક સ્ટેટસ પેજ: એકંદર બેનર ("All systems operational" અથવા વર્તમાન સૌથી ખરાબ સ્થિતિ), દરેક કમ્પોનન્ટ તેની સ્થિતિ સાથે, કોઈ સક્રિય ઇન્સિડન્ટ તેના અપડેટ સાથે, આવનારી જાળવણી, અને ચેક ડેટા હોય તો 90-દિવસની ઇતિહાસ પટ્ટી.
• ઇન્સિડન્ટ પેજ: એક ઇન્સિડન્ટના અપડેટની સંપૂર્ણ ટાઇમલાઇન, તેના પોતાના URL સાથે જેથી સપોર્ટ તેને લિંક કરી શકે.
• ઇતિહાસ: મહિના પ્રમાણે ભૂતકાળના ઇન્સિડન્ટ.
• સબ્સ્ક્રાઇબ: પુષ્ટિ સાથે ઈમેલ સાઇન-અપ અને દરેક કમ્પોનન્ટ માટે પસંદગીઓ.
• એડમિન: ઇન્સિડન્ટ બનાવો, અપડેટ પોસ્ટ કરો, કમ્પોનન્ટની સ્થિતિ બદલો, જાળવણી શેડ્યૂલ કરો.

પરવાનગીઓ

જનતા પ્રકાશિત થયેલું બધું જુએ છે. ફક્ત તમારી ટીમ પોસ્ટ કરી શકે છે. શક્ય હોય તો એડમિન લોગિન તમારી મુખ્ય એપના લોગિન સિસ્ટમથી અલગ રાખો, જેથી તમારા ઓથ પ્રોવાઇડરમાં આઉટેજ થાય તો તમે તમારા જ સ્ટેટસ પેજથી બહાર ન રહી જાઓ.

મુખ્ય નિર્ણય: તેને સ્વતંત્ર રાખો

ઘરે બનાવેલાં મોટા ભાગનાં સ્ટેટસ પેજ અહીં નિષ્ફળ જાય છે. જો તમારું સ્ટેટસ પેજ:

• તમારી એપના જ સર્વર અથવા હોસ્ટિંગ ખાતામાં ચાલે,
• તે જ ડેટાબેઝમાંથી વાંચે,
• તે જ ડોમેન સેટઅપ કે CDN કન્ફિગરેશન પાછળ હોય,
• અથવા તે જ પાઇપલાઇનથી ડિપ્લોય થાય,

તો ઘણા આઉટેજ તેને પણ બંધ કરી દેશે, ઠીક ત્યારે જ જ્યારે લોકોને તેની જરૂર હોય. વ્યવહારુ પગલાં:

• અલગ હોસ્ટિંગ. મુખ્ય એપથી અલગ પ્રોજેક્ટ અથવા પ્રોવાઇડર.
• પોતાનો સબડોમેન, જેમ કે status.example.com, DNS માં અલગથી પોઇન્ટ કરેલો. ડોમેન અને DNS કેવી રીતે કામ કરે છે તે જુઓ.
• પોતાનો ડેટા. ઇન્સિડન્ટ સ્ટેટસ પેજના પોતાના સ્ટોરેજમાં રહે, તમારા એપ ડેટાબેઝમાં નહીં.
• સ્ટેટિક ફોલબેક. કેટલીક ટીમો સાર્વજનિક પેજને સ્ટેટિક બનાવે છે અને દરેક અપડેટ પર ફરીથી બિલ્ડ કરે છે, જેથી તૂટવા જેવું લગભગ કંઈ ન રહે.

જાતે અપડેટ કે ઓટોમેટેડ ચેક

જાતે (અહીંથી શરૂ કરો)

તમારી ટીમ એડમિન પેજ પરથી જાતે ઇન્સિડન્ટ પોસ્ટ કરે છે અને કમ્પોનન્ટની સ્થિતિ બદલે છે. વ્યવહારમાં ઘણાં સ્ટેટસ પેજ આ રીતે ચાલે છે, કારણ કે માનવીનો નિર્ણય ("કેટલાક કાર્ડ પ્રકારો માટે પેમેન્ટ ધીમા છે") ઓટોમેટેડ લાલ બિંદુ કરતાં વધુ ઉપયોગી હોય છે.

સમસ્યાઓ ઝડપથી જાણવા માટે બહારનું અપટાઇમ મોનિટર વાપરો, જે તમારી એપને દર મિનિટ કે તેની આસપાસ તપાસે અને ઈમેલ, SMS અથવા ચેટ દ્વારા ચેતવે. ઘણી મોનિટરિંગ સેવાઓમાં મફત ટિયર હોય છે.

ઓટોમેટેડ

ઓટોમેશનનો અર્થ છે કે કંઈક નિયમિત રીતે દરેક કમ્પોનન્ટ તપાસે અને તેની સ્થિતિ અપડેટ કરે. તેના માટે શેડ્યૂલ પર ચાલતો કોડ જોઈએ, જે તમારી મુખ્ય એપના ઇન્ફ્રાસ્ટ્રક્ચરની બહારથી ચાલે. બે સામાન્ય પેટર્ન:

• બહારનું મોનિટર તમારા સ્ટેટસ પેજને કૉલ કરે webhook દ્વારા, જ્યારે ચેક નિષ્ફળ થાય કે પાછો ઠીક થાય, અને સ્ટેટસ પેજ કમ્પોનન્ટ અપડેટ કરે.
• સ્ટેટસ પેજના પોતાના હોસ્ટિંગમાં શેડ્યૂલ કરેલું જોબ દરેક કમ્પોનન્ટને પિંગ કરે અને પરિણામ નોંધે. આના પર આધાર રાખતા પહેલાં તમારું હોસ્ટિંગ શેડ્યૂલ કરેલા કાર્યો કેવી રીતે સંભાળે તે તપાસો; બૅકગ્રાઉન્ડ જોબ ચલાવવા વિશેની અમારી ગાઇડ વિકલ્પો સમજાવે છે.

ધીમા નેટવર્ક પર ઓટોમેટેડ બદલાવ ફ્લૅપ (up, down, up) થઈ શકે છે. સ્ટેટસ બદલતા પહેલાં બે કે ત્રણ નિષ્ફળ ચેક જરૂરી રાખો, અને મોટા આઉટેજની જાહેરાત થાય તે પહેલાં માનવીને પુષ્ટિ કરવા દો.

ઇન્સિડન્ટ અપડેટ કેવી રીતે લખવા

• વહેલું પોસ્ટ કરો. "અમે લોગિન નિષ્ફળ થવાના અહેવાલો તપાસી રહ્યા છીએ" મિનિટોમાં લખવું, કલાક પછી પરફેક્ટ સંદેશ કરતાં વધુ સારું છે.
• વપરાશકર્તાઓને શું દેખાય છે તે કહો, આંતરિક રીતે શું તૂટ્યું તે નહીં.
• આગલા અપડેટનો સમય વચન આપો, અને તેને પાળો.
• ઉકેલાયા પછી ટૂંકો સારાંશ આપો: શું થયું, કેટલો સમય, તમે શું બદલી રહ્યા છો.

એક પહેલો પ્રોમ્પ્ટ જે કામ કરે છે

Parcelio નામની અમારી એપ માટે એક સ્વતંત્ર સ્ટેટસ પેજ બનાવો, જે status.parcelio.com પર અલગથી હોસ્ટ થશે. કમ્પોનન્ટ: Website, Tracking API, Notifications, Payments, દરેકની સ્થિતિ Operational, Degraded performance, Partial outage, Major outage અથવા Under maintenance. સાર્વજનિક પેજ વર્તમાન સૌથી ખરાબ સ્થિતિ વાપરીને એકંદર બેનર, દરેક કમ્પોનન્ટ તેની સ્થિતિ સાથે, કોઈ પણ સક્રિય ઇન્સિડન્ટ નવા અપડેટ પહેલાં સમયચિહ્ન સાથે, આવનારી જાળવણી, અને મહિના પ્રમાણે ભૂતકાળના ઇન્સિડન્ટની યાદી બતાવે. દરેક ઇન્સિડન્ટનું પોતાનું પેજ હોય. પાસવર્ડથી સુરક્ષિત એડમિન પેજ ઉમેરો જેમાં ઇન્સિડન્ટ બનાવી શકાય (શીર્ષક, અસર, પ્રભાવિત કમ્પોનન્ટ), અપડેટ પોસ્ટ થઈ શકે (સંદેશ અને સ્થિતિ: Investigating, Identified, Monitoring, Resolved), કમ્પોનન્ટની સ્થિતિ બદલી શકાય અને જાળવણી શેડ્યૂલ થઈ શકે. બહારના મોનિટર તરફથી કમ્પોનન્ટનું નામ અને up/down સ્વીકારતો POST /api/check-result એન્ડપોઇન્ટ ઉમેરો, જે સિક્રેટ ટોકન વડે સુરક્ષિત હોય, અને કમ્પોનન્ટને ત્રણ સતત down પછી જ Degraded ગણે. બધું આ એપના પોતાના ડેટાબેઝમાં સ્ટોર કરો. સરળ, શાંત ડિઝાઇન જે ફોન પર ઝડપથી લોડ થાય.

બિલ્ડ સ્ટેપ્સ

1. સાર્વજનિક પેજ અને જાતે ઇન્સિડન્ટ સાથેનું એડમિન. આટલું પણ એક કામ કરતું સ્ટેટસ પેજ છે.
2. તેને અલગથી હોસ્ટ કરો અને સબડોમેનને તેના પર પોઇન્ટ કરો.
3. ઇન્સિડન્ટ પેજ અને ઇતિહાસ.
4. જાળવણી વિન્ડો.
5. સબ્સ્ક્રિપ્શન. ડબલ ઓપ્ટ-ઇન ઈમેલ સાઇન-અપ અને નવા ઇન્સિડન્ટ તથા અપડેટ પર નોટિફિકેશન. ઈમેલ માટે પ્રોવાઇડર જોઈએ; તમારી એપમાંથી ઈમેલ કેવી રીતે મોકલવા તે જુઓ.
6. મોનિટર webhook, જો તમને ઓટોમેટેડ સ્ટેટસ બદલાવ જોઈએ.
7. ડ્રીલ ચલાવો. નકલી ઇન્સિડન્ટ બનાવો, અપડેટ પોસ્ટ કરો, ઉકેલો, ઈમેલ તપાસો, પછી તેને કાઢી નાખો.

સામાન્ય ભૂલો

• એપ સાથે હોસ્ટ કરવું. સૌથી સામાન્ય અને સૌથી ગંભીર ભૂલ.
• એવું પેજ જે હંમેશાં "All systems operational" કહે. જો તે ક્યારેય સમસ્યા ન બતાવે, તો વપરાશકર્તાઓ તેના પર વિશ્વાસ કરવાનું બંધ કરે છે.
• સમયચિહ્ન કે ટાઇમ ઝોન નહીં. હંમેશાં ઝોન સાથે સમય બતાવો.
• એડમિન પેજ માટે તમારી મુખ્ય એપના લોગિન પર આધાર.
• અપડેટ વચ્ચે મૌન. "કોઈ ફેરફાર નથી, હજી કામ ચાલુ છે" પણ માન્ય અપડેટ છે.
• ફ્લૅપ થતી ઓટોમેટેડ સ્થિતિઓ. બદલાવ પહેલાં વારંવારની નિષ્ફળતા જરૂરી રાખો.

ક્યારે હોસ્ટેડ સ્ટેટસ પેજ સેવા વધુ સારી પસંદગી છે

હોસ્ટેડ સ્ટેટસ પેજ સેવાઓ સ્વતંત્રતાની સમસ્યા માટે બનેલી છે: તેઓ અલગ ઇન્ફ્રાસ્ટ્રક્ચર પર ચાલે છે, ઈમેલ અને SMS દ્વારા સબ્સ્ક્રાઇબર નોટિફિકેશન સંભાળે છે, અને ઘણી વાર મોનિટરિંગ તથા ઇન્સિડન્ટ ટૂલ સાથે સંકલન આપે છે. જો અપટાઇમ એ એવું છે જેના માટે ગ્રાહકો ચૂકવે છે, અથવા તમારી પાસે ઇન્સિડન્ટ જાહેર કરવાની કરારીય જવાબદારી છે, તો સમર્પિત સેવા સામાન્ય રીતે યોગ્ય છે. ઘણાં પાસે નાની ટીમો માટે મફત કે ઓછી કિંમતના ટિયર હોય છે, તેથી બનાવતા પહેલાં તપાસો.

જ્યારે તમને ડિઝાઇન અને શબ્દરચના પર પૂરું નિયંત્રણ જોઈએ, જ્યારે તમારી જરૂરિયાત સરળ હોય (થોડા કમ્પોનન્ટ, જાતે અપડેટ), અથવા જ્યારે બીજાઓ માટે બનાવતા ઉત્પાદનનો ભાગ સ્ટેટસ પેજ હોય, ત્યારે જાતે બનાવો.

Mythex સાથે તે બનાવવું

Mythex પર તમે સ્ટેટસ પેજને તમારી મુખ્ય એપથી અલગ પોતાના પ્રોજેક્ટ તરીકે બનાવી શકો છો, જે અલગ હોસ્ટિંગ અને પોતાનો ડેટાબેઝ આપે છે. ચેટમાં તેનું વર્ણન કરો, લાઇવ પ્રિવ્યૂમાં તપાસો, પછી પ્રકાશિત કરો અને status.yourdomain.com જેવો સબડોમેન જોડો (કસ્ટમ ડોમેન Pro પર ઉપલબ્ધ છે). ધ્યાન રાખો કે પ્રકાશિત Mythex એપ અને તેના ડેટાબેઝ નિષ્ક્રિય હોય ત્યારે સૂઈ જાય છે અને આગલી મુલાકાતે જાગે છે, તેથી શાંત સમય પછીનો પહેલો લોડ ધીમો હોઈ શકે છે; સરળ, હલકું પેજ મદદ કરે છે.

Mythex શેડ્યૂલ કરેલા જોબ્સ દસ્તાવેજીકૃત કરતું નથી, તેથી ઓટોમેટેડ ચેક માટે બહારનું અપટાઇમ મોનિટર વાપરો, જે તમારા સ્ટેટસ પેજમાંના webhook એન્ડપોઇન્ટને કૉલ કરે (webhooks રેસિપી જુઓ). સબ્સ્ક્રાઇબરને ઈમેલ ચેતવણીઓ તમારા પોતાના પ્રોવાઇડર દ્વારા જાય છે, જેની કી પ્રોજેક્ટ સિક્રેટ તરીકે સાચવેલી હોય (ઈમેલ મોકલવાની રેસિપી).

પ્રશ્નો