Ինչպես ստեղծել status page. բաղադրիչներ, միջադեպեր և uptime ստուգումներ

Status page-ը մեկ տեղում ցույց է տալիս օգտատերերին, աշխատում է արդյոք ձեր ծառայությունը։ Այն ստեղծելու համար ձեզ պետք է բաղադրիչների ցանկ (կայք, API, վճարումներ, էլ. փոստի առաքում), յուրաքանչյուրի ընթացիկ կարգավիճակը, ժամանակի նշումով թարմացումներով միջադեպեր, նախկին միջադեպերի պատմություն և ըստ ցանկության՝ բաժանորդագրություններ, որպեսզի մարդիկ իմանան խնդիրների մասին առանց ստուգելու։ Էջն ինքնին պարզ է։ Կարևոր որոշումը այն է, թե որտեղ է այն աշխատում. status page-ը պետք է մնա հասանելի, երբ ձեր հավելվածն անջատված է, ուստի այն չպետք է կիսի հոսթինգը, տվյալների բազան կամ deploy գործընթացը այն բանի հետ, ինչի մասին հաղորդում է։

Ինչի համար է status page-ը

Խափանման ժամանակ օգտատերերը երեք բան են ուզում իմանալ. արդյո՞ք խնդիրը միայն իմ մոտ է, գիտե՞ք արդյոք դուք, և ե՞րբ կշտկվի։ Status page-ը պատասխանում է բոլոր երեք հարցին առանց աջակցության հարյուրավոր հարցումների։ Ժամանակի ընթացքում այն նաև վստահություն է ստեղծում, քանի որ տեսանելի միջադեպերի պատմությունը և անկեղծ նկարագրությունները ցույց են տալիս, ինչպես եք գործում խնդիրների դեպքում։

Դա changelog չէ։ Նոր ֆունկցիաները գնում են changelog էջ, իսկ խափանումներն ու սպասարկումը՝ այստեղ։

Ինչ պետք է ունենա էջը

Տվյալներ

Բաղադրիչների կարգավիճակները սովորաբար կարճ, ֆիքսված ցանկ են. Operational, Degraded performance, Partial outage, Major outage, Under maintenance։

Էջեր

• Հրապարակային status page. Ընդհանուր banner («All systems operational» կամ ամենավատ ընթացիկ կարգավիճակը), յուրաքանչյուր բաղադրիչ իր կարգավիճակով, ցանկացած ակտիվ միջադեպ իր թարմացումներով, առաջիկա սպասարկումը և 90-օրյա պատմության շերտ, եթե ունեք ստուգման տվյալներ։
• Միջադեպի էջ. Մեկ միջադեպի թարմացումների ամբողջական ժամանակագրություն՝ սեփական URL-ով, որպեսզի աջակցությունը կարողանա հղում տալ դրան։
• Պատմություն. Նախկին միջադեպերը ամիսների գծով։
• Բաժանորդագրություն. Էլ. փոստով գրանցում՝ հաստատմամբ և յուրաքանչյուր բաղադրիչի նախընտրություններով։
• Ադմինիստրատոր. Միջադեպ ստեղծել, թարմացումներ գրել, բաղադրիչների կարգավիճակ փոխել, սպասարկում պլանավորել։

Թույլտվություններ

Հանրությունը տեսնում է ամեն ինչ, ինչ հրապարակված է։ Գրել կարող է միայն ձեր թիմը։ Եթե հնարավոր է, ադմինի մուտքը պահեք առանձին ձեր հիմնական հավելվածի մուտքի համակարգից, որպեսզի ձեր auth մատակարարի խափանումը ձեզ չփակի ձեր սեփական status page-ից։

Հիմնական որոշումը. պահեք անկախ

Սա այն տեղն է, որտեղ ինքնուրույն ստեղծված status page-ների մեծ մասը ձախողվում է։ Եթե ձեր status page-ը՝

• աշխատում է նույն սերվերի կամ հոսթինգ հաշվի վրա, ինչ ձեր հավելվածը,
• կարդում է նույն տվյալների բազան,
• գտնվում է նույն դոմենի կարգավորման կամ CDN կոնֆիգուրացիայի հետևում,
• կամ deploy է լինում նույն գործընթացով,

ապա շատ խափանումներ կանջատեն և այն, հենց այն ժամանակ, երբ մարդկանց ամենից շատ պետք է։ Գործնական քայլեր.

• Առանձին հոսթինգ. Այլ նախագիծ կամ մատակարար, քան հիմնական հավելվածը։
• Սեփական ենթադոմեն, օրինակ՝ status.example.com, DNS-ում առանձին կապված։ Տես ինչպես են աշխատում դոմենները և DNS-ը։
• Սեփական տվյալներ. Միջադեպերը պահվում են status page-ի սեփական պահոցում, ոչ թե ձեր հավելվածի տվյալների բազայում։
• Ստատիկ պահեստային տարբերակ. Ոմանք հրապարակային էջը դարձնում են ստատիկ և յուրաքանչյուր թարմացումից հետո վերակառուցում, որպեսզի գրեթե ոչինչ չկա, որ կարող է կոտրվել։

Ձեռքով թարմացումներ կամ ավտոմատ ստուգումներ

Ձեռքով (սկսեք այստեղից)

Թիմը ձեռքով գրանցում է միջադեպերը և փոխում բաղադրիչների կարգավիճակները ադմինի էջից։ Գործնականում շատ status page-ներ այսպես են աշխատում, քանի որ մարդու դատողությունը («վճարումները դանդաղ են որոշ քարտերի համար») ավելի օգտակար է, քան ավտոմատ կարմիր կետը։

Խնդիրները արագ իմանալու համար օգտագործեք արտաքին uptime մոնիտոր, որը ստուգում է ձեր հավելվածը մոտ յուրաքանչյուր րոպե և ծանուցում է էլ. փոստով, SMS-ով կամ չատում։ Շատ մոնիտորինգի ծառայություններ ունեն անվճար շերտեր։

Ավտոմատ

Ավտոմատացումը նշանակում է, որ ինչ-որ բան պարբերաբար ստուգում է յուրաքանչյուր բաղադրիչ և թարմացնում է դրա կարգավիճակը։ Դրա համար պետք է կոդ, որն աշխատում է ժամանակացույցով՝ ձեր հիմնական հավելվածի ենթակառուցվածքից դուրս։ Երկու սովորական մոտեցում.

• Արտաքին մոնիտոր webhook-ով կանչում է ձեր status page-ը, երբ ստուգումը ձախողվում կամ վերականգնվում է, և status page-ը թարմացնում է բաղադրիչը։
• Ժամանակացույցով աշխատանք ձեր status page-ի սեփական հոսթինգում ստուգում է յուրաքանչյուր բաղադրիչ և գրանցում արդյունքը։ Նախքան դրան հույս դնելը ստուգեք, թե ինչպես է ձեր հոսթինգը վարում ժամանակացույցով աշխատանքները. մեր ֆոնային աշխատանքների գործարկման ուղեցույցը բացատրում է տարբերակները։

Ավտոմատ փոփոխությունները կարող են թարթել (վեր, ներքև, վեր) դանդաղ ցանցում։ Նախքան կարգավիճակը փոխելը պահանջեք երկու կամ երեք ձախողված ստուգում, և թույլ տվեք մարդուն հաստատել, նախքան մեծ խափանումը հայտարարվի։

Ինչպես գրել միջադեպի թարմացումներ

• Գրեք շուտ. «Հետաքննում ենք մուտքի ձախողումների մասին հաղորդումները» րոպեների ընթացքում ավելի լավ է, քան կատարյալ հաղորդագրությունը մեկ ժամ անց։
• Ասեք, ինչ են նկատում օգտատերերը, ոչ թե ինչ է ներքին առումով կոտրվել։
• Խոստացեք հաջորդ թարմացման ժամը և պահեք այն։
• Փակեք կարճ ամփոփմամբ, երբ լուծվի. ինչ եղավ, որքան տևեց, ինչ եք փոխելու։

Աշխատող առաջին հուշում

Ստեղծիր առանձնացված status page մեր Parcelio հավելվածի համար, առանձին հոստված status.parcelio.com հասցեում։ Բաղադրիչներ՝ Website, Tracking API, Notifications, Payments, յուրաքանչյուրը Operational, Degraded performance, Partial outage, Major outage կամ Under maintenance կարգավիճակով։ Հրապարակային էջը ցույց է տալիս ընդհանուր banner՝ ամենավատ ընթացիկ կարգավիճակով, յուրաքանչյուր բաղադրիչ իր կարգավիճակով, ակտիվ միջադեպեր ժամանակի նշումով թարմացումներով՝ նորագույնը առաջինը, առաջիկա սպասարկում և նախկին միջադեպերի ցանկ ամիսների գծով։ Յուրաքանչյուր միջադեպ ունի սեփական էջ։ Ավելացրու գաղտնաբառով պաշտպանված ադմինի էջ՝ միջադեպեր ստեղծելու (վերնագիր, ազդեցություն, ազդված բաղադրիչներ), թարմացումներ գրելու (հաղորդագրություն և կարգավիճակ՝ Investigating, Identified, Monitoring, Resolved), բաղադրիչների կարգավիճակները փոխելու և սպասարկում պլանավորելու համար։ Ավելացրու POST /api/check-result endpoint, որը ընդունում է բաղադրիչի անունը և up/down արդյունքը արտաքին մոնիտորից, պաշտպանված գաղտնի token-ով, և բաղադրիչը նշում է Degraded միայն երեք անընդմեջ down ստուգումից հետո։ Ամեն ինչ պահիր այս հավելվածի սեփական տվյալների բազայում։ Պարզ, հանգիստ դիզայն, որը արագ է բացվում հեռախոսներում։

Կառուցման քայլեր

1. Հրապարակային էջ և ադմին ձեռքով միջադեպերով. Սա արդեն աշխատող status page է։
2. Հոսթեք այն առանձին և ենթադոմենը կապեք դրան։
3. Միջադեպերի էջեր և պատմություն.
4. Սպասարկման պատուհաններ.
5. Բաժանորդագրություններ. Կրկնակի հաստատումով էլ. փոստի գրանցում և ծանուցումներ նոր միջադեպերի ու թարմացումների մասին։ Էլ. փոստի համար պետք է մատակարար. տես ինչպես ուղարկել էլ. նամակներ ձեր հավելվածից։
6. Monitor webhook, եթե ուզում եք ավտոմատ կարգավիճակի փոփոխություններ։
7. Փորձարկեք. Ստեղծեք կեղծ միջադեպ, գրեք թարմացումներ, լուծեք այն, ստուգեք էլ. նամակները, հետո ջնջեք։

Սովորական սխալներ

• Հոսթել այն հավելվածի հետ միասին։ Ամենատարածված և ամենալուրջ սխալը։
• Էջ, որը միշտ ասում է «All systems operational»։ Եթե այն երբեք խնդիրներ չի ցույց տալիս, օգտատերերը դադարում են վստահել դրան։
• Ժամանակի նշումների կամ ժամային գոտու բացակայություն։ Միշտ ցույց տվեք ժամերը գոտու հետ։
• Ադմինի էջի համար հիմնական հավելվածի մուտքի վրա հույս դնելը։
• Լռություն թարմացումների միջև։ «Փոփոխություն չկա, դեռ աշխատում ենք դրա վրա» վավեր թարմացում է։
• Ավտոմատ կարգավիճակների թարթում։ Փոփոխությունից առաջ պահանջեք կրկնվող ձախողումներ։

Երբ պատրաստի status page ծառայությունն ավելի լավ ընտրություն է

Հոսթված status page ծառայությունները կառուցված են անկախության խնդրի շուրջ. դրանք աշխատում են առանձին ենթակառուցվածքի վրա, կառավարում են բաժանորդների ծանուցումները էլ. փոստով և SMS-ով և հաճախ ներառում են մոնիտորինգ և ինտեգրացիաներ միջադեպերի գործիքների հետ։ Եթե uptime-ը մասն է այն բանի, ինչի համար վճարում են ձեր հաճախորդները, կամ ունեք պայմանագրային պարտավորություն միջադեպերը հաղորդելու, հատուկ ծառայությունը սովորաբար արժե։ Շատերն ունեն անվճար կամ էժան շերտեր փոքր թիմերի համար, ուստի նախքան կառուցելը ստուգեք։

Ստեղծեք սեփականը, երբ ուզում եք լրիվ վերահսկել դիզայնը և բառակապակցությունները, երբ ձեր կարիքները պարզ են (մի քանի բաղադրիչ, ձեռքով թարմացումներ), կամ երբ status page-ը ուրիշների համար կառուցվող արտադրանքի մաս է։

Կառուցել Mythex-ով

Mythex-ում status page-ը կարող եք ստեղծել որպես առանձին նախագիծ՝ առանձին հոսթինգով և սեփական տվյալների բազայով։ Նկարագրեք այն չատում, ստուգեք կենդանի նախադիտման մեջ, հետո հրապարակեք և միացրեք ենթադոմեն, օրինակ՝ status.yourdomain.com (սեփական դոմեններն Pro-ում են)։ Հիշեք, որ հրապարակված Mythex հավելվածները և դրանց տվյալների բազաները անգործության ժամանակ քնում են և արթնանում հաջորդ այցի ժամանակ, ուստի հանգիստ ժամանակաշրջանից հետո առաջին բեռնումը կարող է դանդաղ լինել. պարզ, թեթև էջը օգնում է։

Mythex-ը ժամանակացույցով աշխատանքները առանձին չի փաստաթղթավորում, ուստի ավտոմատ ստուգումների համար օգտագործեք արտաքին uptime մոնիտոր, որը կանչում է ձեր status page-ի webhook endpoint-ը (տես webhooks ուղեցույցը)։ Բաժանորդներին էլ. փոստով ծանուցումները գնում են ձեր սեփական մատակարարի միջոցով, բանալին պահված է որպես նախագծի գաղտնիք (էլ. փոստի ուղարկման ուղեցույց)։

Հարցեր