Как рассчитать доступность приложения (SLA)

Question

У меня есть стандартный проект ASP.NET MVC, и мне нужно рассчитать доступность приложения, чтобы узнать наш уровень SLA . Итак, мне нужно получить что-то подобное для нашего веб-приложения.

Информация от моего хостинг-провайдера

System Availability: 99.9860%
Total Uptime: 30d 10h:22m:44s
Total Downtime: 0d 0h:6m:9s
Total Reboots: 3
Mean Time Between Reboots: 10.15 days

Но мне нужно рассчитать доступность для приложения. Итак, вопрос

Как правильно рассчитать доступность приложения ASP.NET MVC?

Может быть, кто-то уже реализовал это, или любые предложения, как это сделать, оценят любую помощь.

С чего начать?

Первое, о чем я думаю, это Application Insights и тест доступности . Проблема в том, что минимальное значение частоты испытаний составляет 5 минут. Мне нужны более точные измерения.

Затем создайте какой-нибудь инструмент, который будет вызывать мое приложение каждую секунду и собирать информацию. Результат: очень большое количество запросов.

Кроме того, получите несколько перфорированных счетчиков в IIS или что-то в этом роде. Нужно расследовать, если это возможно.

Я знаю, что возможный вопрос слишком широк, но я не нашел никакой информации о реализации доступности приложений. Что вы думаете об этом?

Answer 1

Потребовалось бы много времени, если бы я объяснил все, что можно сделать, поэтому я буду кратким.

Обычно вы определяете все эти детали в Соглашении об уровне обслуживания, где вы также определяете цель доступности (то есть 99%), которая также включает запланированное время простоя. Цель доступности 99% состоит в том, чтобы приложение и его функциональные возможности работали, как описано в документе, максимум с прибл. 87,6 ч в год. Вот калькулятор времени работы SLA .

Обычный интервал составляет 5 минут, как вы говорите, но с помощью внешнего сайта / службы вы можете доказать, что поставщики не соответствуют требованиям, вы рассчитываете свой убыток (потеря дохода, затраты на рабочую силу и т. Д.) И требуете деньги от них. У вас уже есть Анализ влияния на бизнес (BIA). Думаю, в противном случае вам следует это сделать.

Хорошо, теперь к части программирования / DevOps. Я обычно разрабатываю приложения / сервисы с учетом этого и сообщаю о своем статусе сторонним сервисам, таким как NewRelic, Uptrends или аналогичным. В качестве примера я также использую самодельный сервис для этого, потому что точные требования для доставки данных по крайней мере раз в секунду с жестким сроком. В своем решении я использую WebSockets для отправки данных в обоих направлениях, следуя расписанию, событию или при необходимости. Преимущество этого заключается в том, что вы можете отправлять статус (хороший или плохой), скажем, каждые 500 мс, и в течение одной секунды вы будете знать, если приложение не работает (≈ 499 мс + 500 мс).

Используя такой сервис, вы можете измерить время безотказной работы, интересующие вас события и возможные ошибки в течение секунды и тонны других показателей. Обычно в течение 5-100 мс, но WCET / WCRT трудно оценить.

Чтобы ответить на ваш вопрос , вы не можете рассчитать доступность приложения с таким небольшим количеством точек измерения, один раз каждые 5 минут покрывает ок. 12 секунд в час, и вы не можете рассчитывать на это. Вы можете предположить, что между точками измерения все было в порядке, но это называется догадкой. Я сделал реализации, которые имеют 14 400 точек измерения в час, чтобы обеспечить точность 500 мс (Банки).

Я надеюсь, что вы получили ответ, который поможет вам решить вашу проблему.