Водичи

Како да направите страница за статус: компоненти, инциденти и проверки на достапност

Страницата за статус им кажува на вашите корисници, на едно место, дали вашата услуга работи. За да ја направите, ви требаат список на компоненти (веб-сајт, API, плаќања, испорака на е-пошта), тековен статус за секоја, инциденти со ажурирања со време, историја на минатите инциденти и, по желба, претплата за да дознаат за проблемите без да проверуваат. Самата страница е едноставна. Важната одлука е каде работи: страницата за статус мора да остане достапна кога вашата апликација не е, па затоа не треба да дели хостинг, база на податоци или процес на објавување со она што го известува.

За што служи страницата за статус

Кога нешто ќе се расипе, корисниците сакаат да знаат три работи: дали проблемот е само кај нив, дали сте свесни за него и кога ќе биде поправен. Страницата за статус на сите три одговара без поплава од барања до поддршката. Исто така, гради доверба со текот на времето, бидејќи видливата историја на инциденти со искрени објаснувања покажува како ги решавате проблемите.

Тоа не е список на промени. Новите функции одат на страница со промени; прекините и одржувањето се објавуваат овде.

Што му треба на страницата

Податоци

ТабелаГлавни полиња
КомпонентиИме (веб-апликација, API, Плаќања, Испорака на е-пошта), опис, тековен статус, редослед на прикажување, група
ИнцидентиНаслов, влијание (мало, големо, критично), статус (Истражуваме, Идентификувано, Следиме, Решено), погодени компоненти, време на почеток, време на решавање
Ажурирања на инцидентИнцидент, порака, статус во тој момент, објавено во, објавил
Прозорци за одржувањеНаслов, погодени компоненти, планиран почеток и крај, порака
ПретплатнициЕ-пошта, потврдено да/не, компоненти што ги следат, токен за откажување

Статусите на компонентите обично се кратка фиксна листа: Работи, Деградирани перформанси, Делумен прекин, Голем прекин, Во одржување.

Страници

  • Јавна страница за статус: општ банер („Сите системи работат“ или најлошиот тековен статус), секоја компонента со својот статус, секој активен инцидент со ажурирањата, најавено одржување и лента со историја од 90 дена ако имате податоци од проверки.
  • Страница за инцидент: целосна временска линија на ажурирања за еден инцидент, со сопствена URL-адреса за да може поддршката да ја спомне.
  • Историја: минатите инциденти по месеци.
  • Претплата: пријава со е-пошта, потврда и поставки по компонента.
  • Администрација: создавање инцидент, објавување ажурирања, промена на статусите на компонентите, заказување одржување.

Дозволи

Јавноста ги гледа сите објавени информации. Само вашиот тим може да објавува. Ако можете, одвојте го админ-најавувањето од системот за најава на вашата главна апликација, за да не ве заклучи од сопствената страница за статус прекин кај даватели на автентикација.

Клучната одлука: остани независен

Тука најчесто пропаѓаат домашно направените страници за статус. Ако вашата страница за статус:

  • работи на истиот сервер или хостинг-сметка со апликацијата,
  • чита од истата база на податоци,
  • е зад истите поставки на домен или CDN,
  • или се објавува преку истиот процес,

тогаш многу прекини ќе ја симнат и неа, точно кога луѓето ја бараат. Практични чекори:

  • Одделен хостинг. Различен проект или провајдер од главната апликација.
  • Сопствен поддомен, како status.example.com, поставен одвоено во DNS. Погледнете како функционираат доменот и DNS.
  • Сопствени податоци. Инцидентите живеат во сопственото складиште на страницата за статус, а не во базата на вашата апликација.
  • Статичка резерва. Некои тимови ја прават јавната страница статична и ја обновуваат при секое ажурирање, па скоро нема што да се расипе.

Рачни ажурирања или автоматски проверки

Рачно (започнете овде)

Вашиот тим објавува инциденти и ги менува статусите на компонентите рачно од админ-страницата. Така работат многу страници за статус во пракса, бидејќи човечката проценка („плаќањата се бавни за некои типови картички“) е покорисна од автоматска црвена точка.

За брзо дознавање за проблемите користете надворешен мониторинг на достапноста што ја проверува вашата апликација на секоја минута или така и ве известува по е-пошта, SMS или порака во канал. Многу услуги за мониторинг имаат бесплатни планови.

Автоматски

Автоматизацијата значи дека нешто редовно ја проверува секоја компонента и го ажурира нејзиниот статус. За тоа е потребен код што работи по распоред, однадвор од инфраструктурата на вашата главна апликација. Два чести обрасци:

  • Надворешен мониторинг ја повикува вашата страница за статус преку webhook кога проверката ќе падне или ќе се врати, а страницата за статус ја ажурира компонентата.
  • Заказана задача на хостингот на самата страница за статус ја пингува секоја компонента и го бележи резултатот. Проверете како вашиот хостинг работи со заказани задачи пред да се потпрете на тоа; нашиот водич за работа со позадински задачи ги објаснува опциите.

Автоматските промени може да трепкаат (горе, долу, горе) на бавна мрежа. Барајте две или три неуспешни проверки пред да се промени статусот, и нека човек потврди пред да се објави голем прекин.

Како да пишувате ажурирања за инцидент

  • Објавете рано. „Истражуваме пријави за неуспешни најавувања“ во рок од неколку минути е подобро од совршена порака еден час подоцна.
  • Кажете што корисниците забележуваат, а не што внатрешно се расипало.
  • Ветете кога ќе биде следното ажурирање и држете се до тоа.
  • Завршете со кратко резиме кога ќе се реши: што се случи, колку траеше, што менувате.

Прв prompt што функционира

Направи самостојна страница за статус за нашата апликација Parcelio, хостирана одвоено на status.parcelio.com. Компоненти: Веб-сајт, Tracking API, Известувања, Плаќања, секоја со статус Работи, Деградирани перформанси, Делумен прекин, Голем прекин или Во одржување. Јавната страница прикажува општ банер со најлошиот тековен статус, секоја компонента со статус, активните инциденти со ажурирања со време, најавено одржување и список на минати инциденти по месеци. Секој инцидент има своја страница. Додај админ-страница заштитена со лозинка за создавање инциденти (наслов, влијание, погодени компоненти), објавување ажурирања (порака и статус: Истражуваме, Идентификувано, Следиме, Решено), промена на статусите на компонентите и заказување одржување. Додај крајна точка POST /api/check-result што прима име на компонента и up/down од надворешен мониторинг, заштитена со тајен токен, и ја означува компонентата како Деградирана само по три последователни down. Сè складирај во сопствената база на оваа апликација. Едноставен, смирен дизајн што брзо се вчитува на телефони.

Чекори за изградба

  1. Јавна страница и админ со рачни инциденти. Само ова е веќе работечка страница за статус.
  2. Хостирајте ја одвоено и поврзете поддомен со неа.
  3. Страници за инциденти и историја.
  4. Прозорци за одржување.
  5. Претплати. Пријава со е-пошта со двојна потврда и известувања за нови инциденти и ажурирања. Е-поштата бара провајдер; видете како да испраќате е-пошта од вашата апликација.
  6. Webhook за мониторинг, ако сакате автоматски промени на статусот.
  7. Направете проба. Креирајте лажен инцидент, објавете ажурирања, решете го, проверете ги е-поштите, па избришете го.

Чести грешки

  • Хостирање заедно со апликацијата. Најчестата и најсериозната грешка.
  • Страница што секогаш вели „Сите системи работат“. Ако никогаш не покажува проблеми, корисниците престануваат да ѝ веруваат.
  • Нема времиња или временска зона. Секогаш прикажувајте време со зоната.
  • Потпирање на најавата на главната апликација за админ-страницата.
  • Тишина меѓу ажурирањата. „Нема промена, сè уште работиме на тоа“ е валидно ажурирање.
  • Трепкачки автоматски статуси. Барајте повторени неуспеси пред промена.

Кога е подобар избор услуга за страница за статус во облак

Услугите за страници за статус во облак се изградени околу проблемот на независноста: работат на посебна инфраструктура, се грижат за известувања на претплатниците по е-пошта и SMS и често вклучуваат мониторинг и интеграции со алатки за инциденти. Ако достапноста е дел од она за што клиентите плаќаат или имате договорни обврски да пријавувате инциденти, посветената услуга обично вреди. Многу имаат бесплатни или евтини планови за мали тимови, па проверете пред да градите.

Градете сопствена кога сакате целосна контрола над дизајнот и формулациите, кога вашите потреби се едноставни (неколку компоненти, рачни ажурирања) или кога страницата за статус е дел од производ што го градите за други.

Градење со Mythex

Во Mythex страницата за статус можете да ја направите како посебен проект, одвоен од главната апликација, што ѝ дава посебен хостинг и своја база на податоци. Опишете ја во разговорот, проверете ја во живиот преглед, па објавете ја и поврзете поддомен како status.vashdomen.com (сопствени домени се во Pro). Имајте предвид дека објавените апликации и нивните бази на Mythex спијат кога се неактивни и се будат при следната посета, па првото вчитување по мирен период може да биде побавно; едноставна, лесна страница помага.

Mythex не документира заказани задачи, па за автоматски проверки користете надворешен мониторинг на достапноста што повикува webhook крајна точка на вашата страница за статус (видете го рецептот за webhook). Е-пошта за известувања на претплатниците минува преку вашиот провајдер, а клучот се чува како тајна на проектот (рецепт за испраќање е-пошта).

Прашања

Што е страница за статус?

Јавна страница што покажува дали секој дел од вашата услуга работи, ги наведува тековните и минатите инциденти со ажурирања со време и често овозможува претплата за известувања. Ја намалува работата на поддршката за време на прекини.

Дали страницата за статус треба да биде хостирана заедно со апликацијата?

Не. Ако дели хостинг, поставки на домен или база на податоци со апликацијата, може да падне во истиот прекин што треба да го пријави. Хостирајте ја одвоено, на поддомен како status.vashdomen.com.

Дали ми е потребен автоматски мониторинг?

Помага, но не е задолжителен за почеток. Многу мали тимови ги објавуваат инцидентите рачно и користат надворешен мониторинг на достапноста за да се известат. Автоматските промени на статусот можат да дојдат подоцна.

Што треба да каже ажурирањето за инцидент?

Што е погодено, што корисниците ќе забележат, што правите и кога ќе биде следното ажурирање. Кратко, јасно и со време, дури и ако ажурирањето е „сè уште истражуваме“.

Mythex · Pricing · Градете што било со AI · Шаблони за веб-страници и апликации · Mythex во споредба · Речник за градење апликации со AI · Бесплатни алатки за градење апликации со AI · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)