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

Страницата за статус казва на потребителите на едно място дали услугата ви работи. За да я създадете, ви трябват списък с компоненти (уебсайт, API, плащания, имейл доставка), текущ статус за всеки от тях, инциденти с времеви отметки към актуализациите, история на минали инциденти и по желание абонаменти, за да разберат хората за проблемите, без да проверяват сами. Самата страница е проста. Важното решение е къде работи: страницата за статус трябва да остава достъпна, когато приложението ви е недостъпно, затова не бива да споделя хостинг, база данни или процес на внедряване с нещото, за което докладва.

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

Когато нещо се счупи, потребителите искат да знаят три неща: дали проблемът е само при тях, дали сте в течение и кога ще бъде оправен. Страницата за статус отговаря на трите, без поток от заявки към поддръжката. С времето тя изгражда доверие, защото видимата история на инцидентите с честни описания показва как се справяте с проблемите.

Това не е списък с промени. Нови функции отиват в страницата с промени; сривовете и планираната поддръжка – тук.

Какво трябва да има страницата

Данни

Статусите на компонентите обикновено са кратък фиксиран списък: Работи, Влошена производителност, Частичен срив, Голям срив, В поддръжка.

Страници

• Публична страница за статус: общ банер („Всички системи работят“ или най-лошият текущ статус), всеки компонент със статуса си, активният инцидент с актуализациите му, предстояща поддръжка и лента с 90-дневна история, ако имате данни от проверки.
• Страница на инцидент: пълна хронология на актуализациите за един инцидент, със собствен адрес, за да може поддръжката да го препраща.
• История: минали инциденти по месеци.
• Абонирай се: регистрация с имейл, потвърждение и предпочитания по компонент.
• Администрация: създаване на инцидент, публикуване на актуализации, промяна на статусите на компонентите, планиране на поддръжка.

Права

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

Ключовото решение: да е независима

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

• работи на същия сървър или в същия хостинг профил като приложението,
• чете от същата база данни,
• стои зад същата конфигурация на домейна или CDN,
• или се внедрява от същия процес,

тогава много срививи ще я свалят заедно с приложението, точно когато хората я търсят. Практични стъпки:

• Отделен хостинг. Друг проект или доставчик, различен от основното приложение.
• Собствен поддомейн, например status.example.com, насочен отделно в DNS. Вижте как работят домейните и DNS.
• Собствени данни. Инцидентите се пазят в собственото хранилище на страницата, не в базата на приложението.
• Статичен резервен вариант. Някои екипи правят публичната страница статична и я генерират отново при всяка актуализация, така че почти нищо не може да се счупи.

Ръчни актуализации или автоматични проверки

Ръчно (започнете оттук)

Екипът ви публикува инциденти и променя статусите на компонентите ръчно от административната страница. Така работят много страници за статус на практика, защото човешка преценка („плащанията са бавни при някои типове карти“) е по-полезна от автоматичен червен индикатор.

За да разберете бързо за проблеми, използвайте външен монитор за работоспособност, който проверява приложението ви на всяка минута или така и ви известява по имейл, SMS или чат. Много услуги за мониторинг имат безплатни нива.

Автоматично

Автоматизацията означава, че нещо редовно проверява всеки компонент и обновява статуса му. Това изисква код, който работи по график, извън основната инфраструктура на приложението ви. Два често срещани модела:

• Един външен монитор извиква страницата ви за статус през уебхук, когато проверка се провали или възстанови, и страницата обновява компонента.
• Една планирана задача в собствения хостинг на страницата пингва всеки компонент и записва резултата. Проверете как вашият хостинг работи с планирани задачи, преди да разчитате на това; нашето ръководство за стартиране на фонови задачи описва вариантите.

Автоматичните промени могат да мигат (работи, не работи, работи) при бавна мрежа. Изисквайте две или три неуспешни проверки преди промяна на статус и оставете човек да потвърди, преди да обявите голям срив.

Как да пишете актуализации за инциденти

• Публикувайте рано. „Разследваме съобщения за неуспешни входове“ в рамките на минути е по-добре от перфектно съобщение час по-късно.
• Кажете какво забелязват потребителите, а не какво се е счупило вътрешно.
• Обещайте време за следващата актуализация и го спазвайте.
• Затворете с кратко резюме след решаването: какво се случи, колко продължи и какво променяте.

Първа подкана, която работи

Създай самостоятелна страница за статус за нашето приложение Parcelio, хоствана отделно на status.parcelio.com. Компоненти: Уебсайт, API за проследяване, Известия, Плащания, всеки със статус Работи, Влошена производителност, Частичен срив, Голям срив или В поддръжка. Публичната страница показва общ банер според най-лошия текущ статус, всеки компонент със статуса си, активните инциденти с времеви отметки в низходящ ред по време, предстояща поддръжка и списък с минали инциденти по месеци. Всеки инцидент има собствена страница. Добави защитена с парола административна страница за създаване на инциденти (заглавие, въздействие, засегнати компоненти), публикуване на актуализации (съобщение и статус: Разследва се, Идентифициран, Наблюдава се, Решен), промяна на статусите на компонентите и планиране на поддръжка. Добави крайна точка POST /api/check-result, която приема име на компонент и работи/не работи от външен монитор, защитена с таен токен, и маркира компонент като Влошен само след три поредни неуспеха. Съхранявай всичко в собствената база данни на това приложение. Проста, спокойна дизайн, която се зарежда бързо на телефони.

Стъпки за изграждане

1. Публична страница и администрация с ръчни инциденти. Само това вече е работеща страница за статус.
2. Хоствайте я отделно и насочете поддомейн към нея.
3. Страници за инциденти и история.
4. Периоди на поддръжка.
5. Абонаменти. Регистрация с двойно потвърждение по имейл и известия при нови инциденти и актуализации. Имейлът изисква доставчик; вижте как да изпращате имейли от приложението си.
6. Уебхук от монитора, ако искате автоматични промени на статуса.
7. Направете пробна тренировка. Създайте фалшив инцидент, публикувайте актуализации, решете го, проверете имейлите и после го изтрийте.

Чести грешки

• Хостване заедно с приложението. Най-честата и най-сериозната грешка.
• Страница, която винаги казва „Всички системи работят“. Ако никога не показва проблеми, потребителите спират да й вярват.
• Без времеви отметки или часова зона. Винаги показвайте часовете със зоната.
• Разчитане на входа на основното приложение за административната страница.
• Мълчание между актуализациите. „Без промяна, още работим по това“ е валидна актуализация.
• Мигащи автоматични статуси. Изисквайте повтарящи се неуспехи преди промяна.

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

Услугите за хостнати страници за статус са създадени около проблема с независимостта: работят на отделна инфраструктура, изпращат известия на абонатите по имейл и SMS и често включват мониторинг и интеграции с инструменти за инциденти. Ако работоспособността е част от това, за което клиентите плащат, или имате договорни задължения да докладвате инциденти, специализираната услуга обикновено си струва. Много от тях имат безплатни или евтини нива за малки екипи, затова проверете, преди да строите.

Създайте своя, когато искате пълен контрол над дизайна и формулировките, когато нуждите ви са прости (няколко компонента, ръчни актуализации) или когато страницата за статус е част от продукт, който създавате за други.

Създаване с Mythex

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

Mythex не документира планирани задачи, затова за автоматичните проверки използвайте външен монитор, който извиква уебхук крайна точка в страницата ви за статус (вижте рецептата за уебхукове). Имейлите до абонатите минават през собствения ви доставчик, като ключът се пази като тайна на проекта (рецепта за изпращане на имейл).

Въпроси