Monitoring i status

Почти каждая страница статуса, на которую вы попадаете, показывает красивые числа. 100 процентов аптайма, всё зелёное, ни царапины. Проблема в том, что эти числа чаще всего означают не "всё работало", а "никто не смотрел". Отсутствие данных засчитывается как успех, и клиент получает красивую картинку без покрытия в реальности.

Мы построили мониторинг, который делает нечто более трудное, чем красивый график: он говорит правду, даже когда правда неудобна. Когда мы не знаем, как работала услуга, результат должен звучать "не знаю", а не "всё хорошо". К этому добавляются публичная страница статуса с честной историей и ведение инцидентов там, где команда и так сидит. Это исследование о том, как считать доступность, не обманывая самого себя.

Механизм типичной лжи страницы статуса банален. Если за данный период зонд не собрал ни одной пробы, а вы всё равно засчитываете этот период как исправный, ваш аптайм всегда будет выглядеть отлично. Чем реже вы смотрите, тем лучше выглядите, что абсурдно: инструмент для слежения за доступностью награждает вас за то, что вы не следите.

Эффект удобен и неправдив. Зелёный график успокаивает команду и клиента, хотя под ним мог быть час, о котором никто ничего не знает. Мы хотели ровно противоположной позиции: "не знаю" должно значить "не знаю", а не быть тихо округлённым до "всё работает".

Вся честность этого мониторинга берётся из одного решения: у пробы три возможных состояния, а не два. Не только "up" и "down", но и "unknown" на время, в которое наблюдения просто не было. Это различие - сердце всего остального.

В доступность входят исключительно фактически собранные пробы, то есть "up" и "down". Состояния "unknown" откладываются в сторону, потому что их нельзя изображать ни в одну, ни в другую сторону. Если за данный период не было ни одного наблюдения, результат не 100 процентов и не ноль. Результат пуст, и именно так его показывает страница статуса.

Отдельная ловушка - запланированные перерывы. Заманчиво считать окно обслуживания исправным временем, ведь "это был запланированный перерыв, а не авария". Только тогда график снова лжёт, лишь тоньше: он делает вид, что услуга работала, когда её намеренно не было.

Мы пошли серединой, которая честна в обе стороны. Окна обслуживания помечены отдельно и не считаются простоем, потому что это не авария. Но и не делают вид, что в это время всё работало. На графике видна пауза, помеченная как обслуживание, а не искусственный зелёный фон. Это тот же принцип, который правит всем проектом: мы не округляем в свою сторону.

Мониторинг, который только считает, - это половина работы. Вторая половина начинается в момент, когда что-то действительно падает. Тут совершают классическую ошибку: ведение инцидента заталкивают в отдельный инструмент, в который никто не хочет входить в разгар пожара. Мы пошли туда, где команда и так есть, то есть в Discord.

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

Число на странице значит ровно то, что говорит. Когда там стоит 99.5 процента, это 99.5 процента из фактических наблюдений, а не артефакт того, что зонд спал полдня. Клиент смотрит на страницу статуса и видит честную историю: доступность, простои и окна обслуживания разделены, а не вечная зелень, которая ничего не значит.

Когда что-то падает, команда ведёт инцидент из места, где и так находится, без входа в очередной инструмент в наихудший из возможных моментов. Всё держится на одном принципе, который выглядит скромно, а встречается редко: мониторинг, которому можно верить, потому что он признаёт то, чего не знает, вместо того чтобы закрашивать пробелы зелёным.