Що таке сторінка статусу і що на ній має бути

Що розміщують на сторінці статусу

Сторінка статусу має три шари, і більшість цінності - в перших двох.

Верхній шар - поточний стан кожного компонента, який ви перелічуєте. Компоненти - це частини, які клієнт може розрізнити: вебсайт, API, панель керування, вхід у систему, потік оплати, бекенд мобільного застосунку. Стан зазвичай задається короткою шкалою, а не бінарно, тож ви можете сказати "деградація" для сервісу, що повільний, але відповідає, замість вибору між зеленою галочкою, яка неправдива, і червоним хрестиком, який ще гірший.

Середній шар - стрічка інцидентів. Кожен інцидент - це короткий запис із часом початку, простим описом того, що помітять клієнти, і оновленнями, які додаються в міру розвитку ситуації, завершуючись поміткою про вирішення. Минулі інциденти лишаються видимими, і саме це перетворює сторінку на журнал, а не на просто перемикач.

Нижній шар - історія: аптайм за останні 30 чи 90 днів для кожного компонента. Це найменш термінова частина і водночас та, яку найчастіше читають люди, що вас оцінюють.

Публічна чи приватна

Публічна сторінка статусу відкрита будь-кому за посиланням, і це правильний вибір, коли ваші клієнти - широка публіка або коли ви публікуєте SLA. Вона також бере на себе трафік під час збою від людей, які взагалі не є клієнтами.

Приватна сторінка статусу обмежена авторизованими клієнтами чи внутрішньою аудиторією. Команди використовують її, коли список компонентів розкривав би внутрішню архітектуру, коли інциденти стосуються названих корпоративних клієнтів, або коли сторінка охоплює внутрішні системи, які сторонній не повинен бачити переліченими. Компроміс у тому, що кожен, хто не може до неї дістатися, натомість звернеться в підтримку.

Хоч би що ви обрали, розміщуйте сторінку окремо від інфраструктури, про яку вона звітує. Сторінка статусу, що падає разом із сервісом, гірша за відсутність сторінки статусу взагалі, бо її мовчання під час збою читається як твердження, що все гаразд.

Як писати інцидент

Запис інциденту пишуть для клієнта, а не для інженерів, що його виправляють. Це означає: спершу симптом, причина - пізніше, якщо взагалі.

1. Відкрийте інцидент, щойно підтвердили проблему, навіть якщо ще не знаєте причини. "Ми розслідуємо повідомлення про помилки під час оформлення замовлення", опубліковане на другій хвилині, варте більше, ніж повне пояснення на дев'яносто першій.
2. Скажіть, що побачить клієнт і що він може з цим зробити, включно з обхідним рішенням, якщо воно є.
3. Оновлюйте із заявленим наперед ритмом і публікуйте оновлення, навіть коли це "поки без змін". Мовчання читається як покинутість.
4. Завершіть часом вирішення і, для всього тривалого чи серйозного, коротким записом про те, що сталося потім.

Узгоджуйте стан компонента з інцидентом. Відкритий інцидент на компоненті, що досі показує зелений колір, - найшвидший спосіб втратити довіру до сторінки. Якщо в основі збою - сервер, що відмовляє в запитах, 503 Service Unavailable - та відповідь, яку ваші клієнти найімовірніше вам і цитуватимуть.

Заплановане обслуговування

Заплановані роботи мають місце на тій самій сторінці, анонсовані заздалегідь із вікном і очікуваним впливом. Публікація наперед перетворює збій на заплановану зустріч: клієнти, що бачили анонс, не подаватимуть тікети, а ті, хто не бачив, принаймні знайдуть пояснення, поки це відбувається.

Відрізняйте обслуговування від інциденту візуально і в записі, і тримайте анонсоване вікно чесним. Вікно обслуговування, що регулярно затягується, привчає людей ігнорувати наступне.

Чому це знижує навантаження на підтримку

Під час збою черга підтримки заповнюється одним і тим самим питанням, заданим багато разів. Сторінка статусу відповідає на нього один раз, за адресою, на яку можна вказати з автовідповідача підтримки, стану помилки у вашому застосунку і ваших соціальних акаунтів. Це перетворює годину одноманітного розбору звернень на одне посилання.

Другорядний ефект - на довіру. Публікація інцидентів коштує менше, ніж здається, бо клієнти, які помітили збій, і так уже знають, що він стався. Вони оцінюють насправді те, чи ви їм про це сказали.

Звідки береться статус

Сторінка статусу настільки хороша, наскільки хороший моніторинг за нею. Якщо людина має спершу помітити збій, перш ніж сторінка зміниться, сторінка завжди відставатиме від клієнтів, що її читають, тож стани компонентів мають визначати перевірки, що працюють безперервно ззовні вашої мережі. HostTracker розміщує сторінки статусу, що живляться від власного моніторингу, який перевіряє з понад 300 контрольних точок у 158 містах у 13 типах моніторів, тож стан компонента слідує за результатами перевірок, а не за тим, чи хтось згадав його оновити. Про те, як виглядають такі перевірки, читайте в посібнику з HTTP-перевірки, а решта розділу про поняття моніторингу охоплює суміжні терміни.