The post has been translated automatically. Original language: Russian
Every online service calls itself reliable. Much less often, it shows data that can be used to verify this.
The word "reliable" is found on SaaS product websites so often that it has almost lost its meaning. It usually has general promises behind it: fault-tolerant infrastructure, constant monitoring, and high availability. The user must take the company's word for it.
But there is no absolute reliability. Errors appear in the code, data centers lose connection, databases switch between nodes, unsuccessful releases have to be rolled back. Even if each component of the system is designed correctly, external dependencies and the human factor remain.
Therefore, trust in reliability does not begin with a promise that there will be no failures. It starts with a willingness to measure them and show results.
What exactly do we call reliability?
The phrase "the service was available 99.9% of the time" looks concrete, but without a measurement technique, it still doesn't say much.
What is considered accessibility: the response of the main page, the successful login to the personal account, or the ability to perform the main operation? Is the service considered available if it responds but takes 30 seconds to do so? What happens when there is a failure in only one region? Are planned works taken into account? For what period is the indicator calculated?
To answer these questions, Site Reliability Engineering uses three related concepts:
- SLI, Service Level Indicator — a measurable indicator of service performance. For example, the percentage of requests processed correctly or the percentage of requests completed faster than the specified time.
- SLO, Service Level Objective — the target value of this indicator. For example, at least 99.9% of requests processed correctly in 30 days.
- SLA, Service Level Agreement — an agreement with the client, which sets out the obligations, the period and method of calculation, exceptions and consequences of non-fulfillment of the promised level.
This separation is important. SLA is not just a beautiful percentage and not the probability of an accidental server crash. This is a contractual promise, the meaning of which is determined by the measurement method and the terms of the agreement. A detailed explanation of these terms can be found, for example, in the Google book on Site Reliability Engineering.
Why is the difference in hundredths so great?
It is convenient to consider accessibility through the unavailability budget — the time or proportion of requests that the system may lose if it does not exceed the selected goal.
If, for simplicity, we consider time availability, without exceptions, and for a typical year of 365 days, we get the following values:
- 99%: 3 days, 15 hours, 36 minutes
- 99.9%: 8 hours, 45 minutes, 36 seconds
- 99.99%: about 52 minutes 34 seconds
Between 99% and 99.99% is only 0.99 percentage points. However, the allowable unavailability is reduced by a factor of 100: from 5,256 to 52.56 minutes per year.
These additional nines require more than just more powerful servers. Redundancy, secure updates, observability, verifiable recovery, on-call, and incident review processes are needed. Therefore, a higher level of accessibility usually costs significantly more.
However, the percentage itself does not yet describe the consequences. Five minutes of unavailability at night and five minutes during mass ticket payment formally look the same, but have a completely different effect on users. For a webhook system, even a short glitch can coincide with a payment notification, order change, or other request that cannot be lost unnoticed.
Observability seems to be optional — until the first failure.
While the application is running, monitoring can easily be perceived as a secondary task. Users are not complaining, the server is responding, and the team is busy with functions that have a more noticeable effect on the product. It seems that in case of a problem, it will be enough to open the logs.
Let's imagine that the payment service sent a webhook, but the end application did not process it. By the time of the check, all components are responding normally again. Without pre-collected measurements, the team does not know whether the request was accepted, whether it was saved, whether it was delayed in the queue, whether delivery did not work, or whether the error was returned by the end application itself. The logs of individual services may contain parts of the response, but first they still need to be linked by time and a specific request.
Monitoring helps you notice a known deviation: an increase in errors, an unavailable component, or a response that takes too long. Observability helps to restore a picture of what is happening using metrics, logs, and traces. Their value becomes obvious at the first failure, but it is no longer possible to add the missing data retroactively. Therefore, observability needs to be built before it is first needed.
One green indicator is not enough
The public status page answers a simple and important question: is the service working now?
One common indicator is not enough for this. If the main page opens, but the API does not accept requests, the user will not call the service available. If the problem occurred in only one region, the global green status will hide useful information.
A good status page divides the system into components that correspond to real user scenarios. It can show separately:
- public website and control panel
- API or request acceptance
- queue handling
- data storage
- delivery to external systems
- the state of individual regions
A short statistics window complements this picture: the user can see not only the current status, but also recent deviations. However, even a 24-hour history still does not prove reliability for a month, quarter, or year. The green indicator for today and the green indicator for the previous day do not indicate how many incidents occurred in the previous three months.
This requires a history: the start and end time of the incident, the affected components and regions, the impact on users, the recovery process, and the final analysis. And the accumulated percentage of availability makes sense only together with the period and calculation rules.
In other words, the current status answers the question "what is happening now", short statistics — "what happened recently", and the history of incidents and indicators over a long period — "how the service worked before".
Automate measurement, not responsibility
If the team manually decides which failures will be included in the statistics, sooner or later it is tempting to ignore a short or isolated event. A few seconds seem insignificant, especially when the problem affected few users and quickly disappeared.
But it is precisely such decisions that gradually make statistics unreliable. First, one inconvenient episode is excluded, then another, and eventually the published indicator ceases to describe the user experience.
Therefore, the collection of initial data should be automatic. The checks are run constantly, the results are saved regardless of whether it is convenient to publish them, and the indicator is calculated according to predefined rules.
This does not mean that every failed inspection should be immediately declared a major incident. One request may fail due to the local network route, DNS, or the error of the verifying node itself. Automation requires thresholds, repeated checks, and comparing results from different locations.
It is useful to separate the two levels:
- Measurements. Automatic checks and metrics capture events without manual selection.
- Communication. The team explains the scale of the impact, the cause, the course of recovery, and measures that will reduce the likelihood of a repeat.
Automation reduces the opportunity to embellish the numbers, but it does not relieve the team of responsibility for a clear explanation of what happened.
What should an honest status page contain?
The address/status itself does not create transparency yet. The user needs information based on which to make a decision.
The minimally useful page should show:
- status of significant components and regions
- last update time
- open incidents and their impact
- the history of completed incidents
- clear statuses: complete unavailability, partial unavailability, performance degradation, scheduled work
- the methodology for calculating accessibility
- the period for which the indicator was published
For serious incidents, postmortem analysis is useful without looking for the culprits. It should describe the sequence of events, the impact on users, the method of detection, recovery, and specific changes to the system or processes.
Measurement boundaries are especially important. Checking the technical health endpoint may say that the process is running, but it does not prove that the user is capable of performing the basic operation. The closer the check is to the actual user path, the more useful its result is.
How we started doing it in Adal
Adal accepts and delivers webhooks, so accessibility is not an abstract characteristic for us. If the system cannot accept an incoming request, the external service may receive an error. If delivery is disrupted, the request may remain pending or require a second attempt. If the control panel is unavailable, the user loses the opportunity to see what is happening.
We have opened a public Adal status page. It shows the status separately for the regions in Almaty, Stockholm and Nuremberg. Within each region, public services are separated — the web interface, socket server, and request acceptance -and infrastructure components, including a regional database, queue, and storage connection.
The page shows not only the current state of the system. For each region, we publish hourly statistics for the last 24 hours in UTC, from the earliest interval to the current one. The unfinished hour is marked separately: the checks are still ongoing, so its final status may change.
These statistics are based on automatic checks with dynamic frequency. In normal mode, each service in each region is checked once every 30 seconds. If the check detects an error, the monitoring of this service in the relevant region switches to a second-by-second mode to confirm the incident and monitor the recovery. After a confirmed recovery, the interval increases again to 30 seconds. The system keeps a history of detected errors, and the page combines the data into user-friendly time intervals. Therefore, a short glitch does not disappear just because the service is working again by the time the page is opened.
The page also separates the status received from the Adal infrastructure from the accessibility check from the user's browser. This distinction is important: a local DNS, VPN, firewall, CORS, or network route can affect the result of an external check, even when the component itself is running.
However, a single verification error does not necessarily mean a user incident. We plan to analyze the saved history: compare errors between components and regions, determine the real impact on users, and publish information about confirmed incidents. For serious cases, such a publication should explain not only the duration, but also the cause, consequences, and measures taken after recovery.
But we don't even consider the current status, along with 24-hour statistics, to be proof of the SLA that has already been achieved. To assess availability for a month or a year, you need an appropriate observation period, a history of confirmed incidents, and pre-published calculation rules. It would be strange to write about transparency and at the same time give a short window of observations as statistical evidence of long-term reliability.
Failure doesn't necessarily destroy trust.
The user usually understands that a complex system can fail. Uncertainty and silence destroy trust much more: it is unclear whether the team sees a problem, which functions are affected, whether the data is saved and when to wait for the next update.
Honest communication does not make the service less reliable. It allows the user to assess the risk, take temporary measures and see how the team is dealing with errors.
The most revealing moment for a status page doesn't come when everything is green. Its value becomes visible during a real incident: how quickly the information appeared, how accurately the impact was described, and whether a useful analysis was published after the recovery.
Reliability cannot be confirmed with a single phrase on a landing page. You have to measure it over time — and be ready to show the result, including those minutes that you don't want to be proud of.
Каждый онлайн-сервис называет себя надёжным. Гораздо реже он показывает данные, по которым это можно проверить.
Слово «надёжный» встречается на сайтах SaaS-продуктов так часто, что почти потеряло смысл. Обычно за ним стоят общие обещания: отказоустойчивая инфраструктура, постоянный мониторинг, высокая доступность. Пользователь при этом должен поверить компании на слово.
Но абсолютной безотказности не существует. Ошибки появляются в коде, дата-центры теряют связь, базы данных переключаются между узлами, неудачные релизы приходится откатывать. Даже если каждый компонент системы спроектирован правильно, остаются внешние зависимости и человеческий фактор.
Поэтому доверие к надёжности начинается не с обещания, что сбоев не будет. Оно начинается с готовности измерять их и показывать результат.
Что именно мы называем надёжностью
Фраза «сервис был доступен 99,9% времени» выглядит конкретно, но без методики измерения она всё ещё мало о чём говорит.
Что считается доступностью: ответ главной страницы, успешный вход в личный кабинет или возможность выполнить основную операцию? Считается ли сервис доступным, если он отвечает, но делает это 30 секунд? Что происходит при сбое только в одном регионе? Учитываются ли плановые работы? За какой период вычисляется показатель?
Чтобы ответить на эти вопросы, в Site Reliability Engineering используют три связанных понятия:
- SLI, Service Level Indicator — измеряемый показатель работы сервиса. Например, доля корректно обработанных запросов или доля запросов, выполненных быстрее заданного времени.
- SLO, Service Level Objective — целевое значение этого показателя. Например, не менее 99,9% корректно обработанных запросов за 30 дней.
- SLA, Service Level Agreement — соглашение с клиентом, в котором зафиксированы обязательства, период и методика расчёта, исключения и последствия невыполнения обещанного уровня.
Такое разделение важно. SLA — не просто красивый процент и не вероятность случайного падения сервера. Это договорное обещание, смысл которого определяется способом измерения и условиями соглашения. Подробное объяснение этих терминов можно найти, например, в книге Google по Site Reliability Engineering.
Почему разница в сотых долях так велика
Доступность удобно рассматривать через бюджет недоступности — время или долю запросов, которые система может потерять, не выйдя за выбранную цель.
Если для простоты считать доступность по времени, без исключений и за обычный год из 365 дней, получатся такие значения:
- 99%: 3 дня 15 часов 36 минут
- 99,9%: 8 часов 45 минут 36 секунд
- 99,99%: около 52 минут 34 секунд
Между 99% и 99,99% — всего 0,99 процентного пункта. Однако допустимая недоступность уменьшается в 100 раз: с 5 256 до 52,56 минуты в год.
Эти дополнительные «девятки» требуют не только более мощных серверов. Нужны резервирование, безопасные обновления, наблюдаемость, проверяемое восстановление, дежурство и процессы разбора инцидентов. Поэтому более высокий уровень доступности обычно стоит заметно дороже.
При этом сам процент ещё не описывает последствия. Пять минут недоступности ночью и пять минут во время массовой оплаты билетов формально выглядят одинаково, но имеют совершенно разное влияние на пользователей. Для системы вебхуков даже короткий сбой может совпасть с уведомлением об оплате, изменением заказа или другим запросом, который нельзя незаметно потерять.
Наблюдаемость кажется необязательной — до первого сбоя
Пока приложение работает, мониторинг легко воспринимать как второстепенную задачу. Пользователи не жалуются, сервер отвечает, а команда занята функциями, которые заметнее влияют на продукт. Кажется, что в случае проблемы будет достаточно открыть логи.
Представим, что платёжный сервис отправил вебхук, но конечное приложение его не обработало. К моменту проверки все компоненты снова отвечают нормально. Без заранее собранных измерений команда не знает, был ли запрос принят, сохранился ли он, задержался ли в очереди, не работала ли доставка или ошибку вернуло само конечное приложение. Логи отдельных сервисов могут содержать части ответа, но сначала их ещё нужно связать по времени и конкретному запросу.
Мониторинг помогает заметить известное отклонение: рост ошибок, недоступный компонент или слишком долгий ответ. Наблюдаемость помогает восстановить картину происходящего по метрикам, журналам и трассировкам. Их ценность становится очевидной при первом сбое, но добавить недостающие данные задним числом уже невозможно. Поэтому наблюдаемость нужно строить до того, как она впервые понадобится.
Одного зелёного индикатора недостаточно
Публичная страница статуса отвечает на простой и важный вопрос: работает ли сервис сейчас?
Для этого недостаточно одного общего индикатора. Если главная страница открывается, но API не принимает запросы, пользователь не назовёт сервис доступным. Если проблема возникла только в одном регионе, глобальный зелёный статус скроет полезную информацию.
Хорошая страница статуса разделяет систему на компоненты, которые соответствуют реальным пользовательским сценариям. Она может отдельно показывать:
- публичный сайт и панель управления
- API или приём запросов
- обработку очередей
- хранение данных
- доставку во внешние системы
- состояние отдельных регионов
Короткое окно статистики дополняет эту картину: пользователь может увидеть не только состояние в текущую минуту, но и недавние отклонения. Однако даже история за 24 часа ещё не доказывает надёжность за месяц, квартал или год. Зелёный индикатор сегодня и зелёные предыдущие сутки ничего не говорят о том, сколько инцидентов произошло за предыдущие три месяца.
Для этого нужна история: время начала и завершения инцидента, затронутые компоненты и регионы, влияние на пользователей, ход восстановления и итоговый разбор. А накопленный процент доступности имеет смысл только вместе с периодом и правилами расчёта.
Иными словами, текущий статус отвечает на вопрос «что происходит сейчас», короткая статистика — «что происходило недавно», а история инцидентов и показатели за длительный период — «как сервис работал раньше».
Автоматизировать измерение, а не ответственность
Если команда вручную решает, какие сбои попадут в статистику, рано или поздно возникает соблазн не учитывать короткое или единичное событие. Несколько секунд кажутся несущественными — особенно когда проблема затронула мало пользователей и быстро исчезла.
Но именно такие решения постепенно делают статистику недостоверной. Сначала исключается один неудобный эпизод, затем другой, а в итоге опубликованный показатель перестаёт описывать пользовательский опыт.
Поэтому сбор исходных данных должен быть автоматическим. Проверки запускаются постоянно, результаты сохраняются независимо от того, удобно ли их публиковать, а показатель рассчитывается по заранее определённым правилам.
Это не означает, что каждую неудачную проверку нужно немедленно объявлять крупным инцидентом. Один запрос может не пройти из-за локального сетевого маршрута, DNS или ошибки самого проверяющего узла. Автоматике нужны пороги, повторные проверки и сравнение результатов из разных точек.
Полезно разделить два уровня:
- Измерения. Автоматические проверки и метрики фиксируют события без ручного отбора.
- Коммуникация. Команда объясняет масштаб влияния, причину, ход восстановления и меры, которые снизят вероятность повторения.
Автоматизация уменьшает возможность приукрасить цифры, но не снимает с команды ответственность за понятное объяснение произошедшего.
Что должна содержать честная страница статуса
Сам по себе адрес /status ещё не создаёт прозрачность. Пользователю нужна информация, на основании которой можно принять решение.
Минимально полезная страница должна показывать:
- состояние значимых компонентов и регионов
- время последнего обновления
- открытые инциденты и их влияние
- историю завершённых инцидентов
- понятные статусы: полная недоступность, частичная недоступность, деградация производительности, плановые работы
- методику расчёта доступности
- период, за который опубликован показатель
Для серьёзных инцидентов полезен postmortem — разбор без поиска виноватых. В нём стоит описать последовательность событий, влияние на пользователей, способ обнаружения, восстановление и конкретные изменения в системе или процессах.
Особенно важны границы измерения. Проверка технического health endpoint может сказать, что процесс запущен, но не доказать, что пользователь способен выполнить основную операцию. Чем ближе проверка к реальному пользовательскому пути, тем полезнее её результат.
Как мы начали делать это в Adal
Adal принимает и доставляет вебхуки, поэтому для нас доступность — не абстрактная характеристика. Если система не может принять входящий запрос, внешний сервис может получить ошибку. Если нарушена доставка, запрос может остаться в ожидании или потребовать повторной попытки. Если недоступна панель управления, пользователь теряет возможность увидеть, что происходит.
Мы открыли публичную страницу статуса Adal. На ней состояние показано отдельно для регионов в Алматы, Стокгольме и Нюрнберге. Внутри каждого региона разделены публичные сервисы — веб-интерфейс, socket server и приём запросов — и инфраструктурные компоненты, включая региональную базу данных, очередь и подключение к хранилищу.
Страница показывает не только состояние системы в текущий момент. Для каждого региона мы публикуем почасовую статистику за последние 24 часа в UTC — от самого раннего интервала до текущего. Незавершённый час отмечен отдельно: проверки ещё продолжаются, поэтому его итоговый статус может измениться.
В основе этой статистики лежат автоматические проверки с динамической частотой. В штатном режиме каждый сервис каждого региона проверяется раз в 30 секунд. Если проверка обнаруживает ошибку, мониторинг этого сервиса в соответствующем регионе переходит на ежесекундный режим, чтобы подтвердить инцидент и проследить за восстановлением. После подтверждённого восстановления интервал снова увеличивается до 30 секунд. Система сохраняет историю обнаруженных ошибок, а страница объединяет данные в понятные пользователю часовые интервалы. Поэтому короткий сбой не исчезает только потому, что к моменту открытия страницы сервис снова работает.
Страница также отделяет статус, полученный от инфраструктуры Adal, от проверки доступности из браузера пользователя. Это различие важно: локальный DNS, VPN, firewall, CORS или сетевой маршрут могут влиять на результат внешней проверки, даже когда сам компонент работает.
При этом отдельная ошибка проверки ещё не обязательно означает пользовательский инцидент. Мы планируем анализировать сохранённую историю: сопоставлять ошибки между компонентами и регионами, определять реальное влияние на пользователей и публиковать информацию о подтверждённых инцидентах. Для серьёзных случаев такая публикация должна объяснять не только длительность, но и причину, последствия и меры, принятые после восстановления.
Но мы не считаем даже текущий статус вместе с 24-часовой статистикой доказательством уже достигнутого SLA. Для оценки доступности за месяц или год нужны соответствующий период наблюдений, история подтверждённых инцидентов и заранее опубликованные правила расчёта. Было бы странно писать о прозрачности и одновременно выдавать короткое окно наблюдений за статистическое доказательство долгосрочной надёжности.
Сбой не обязательно разрушает доверие
Пользователь обычно понимает, что сложная система может отказать. Гораздо сильнее доверие разрушают неопределённость и молчание: непонятно, видит ли команда проблему, какие функции затронуты, сохраняются ли данные и когда ждать следующего обновления.
Честная коммуникация не делает сервис менее надёжным. Она позволяет пользователю оценить риск, принять временные меры и увидеть, как команда работает с ошибками.
Самый показательный момент для страницы статуса наступает не тогда, когда всё зелёное. Её ценность становится видна во время реального инцидента: насколько быстро появилась информация, насколько точно описано влияние и был ли после восстановления опубликован полезный разбор.
Надёжность нельзя подтвердить одной фразой на лендинге. Её приходится измерять на протяжении времени — и быть готовым показать результат, включая те минуты, которыми не хочется гордиться.
Share
