Вопрос

Фон:

Некоторое время назад я построил систему записи и классификации сбоев приложений для одной из наших внутренних программ.В то время я использовал комбинацию частоты и совокупного потерянного времени (времени между запуском программы и сбоем) для определения приоритетности типов сбоев.Это сработало достаточно хорошо.

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

Вопрос:

Существуют ли какие-либо устоявшиеся методы расчета реальной стоимости сбоев приложений?Или, если это не удастся, опубликованные исследования, спекулирующие на таких издержках?


Консенсус

Точность невозможна, но оценки, основанной на времени безотказной работы, должно быть достаточно, если она применяется последовательно и ее ограничения четко задокументированы.Спасибо, Мэтт, Орион, что нашли время ответить на этот вопрос.

Это было полезно?

Решение

Я не видел никаких исследований, но разумная эвристика была бы примерно такой:

(Время с момента последнего сохранения приложения в момент сбоя + Время перезапуска приложения) * Средняя почасовая ставка оператора приложения.

Оценка становится более сложной, если сбои оказывают какое-то влияние на внешних клиентов или могут задержать другие события (т.создать узкое место, так что другой человек будет сидеть и ждать, потому что какое-то другое приложение вышло из строя).

Тем не менее, ваши «представители власти» вполне могут быть довольны очень грубой оценкой, если она применяется последовательно и они могут видеть, как она меняется с течением времени.

Другие советы

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

Я хочу полететь на своем воздушном шаре на Марс, но это не значит, что такое возможно.

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

Что-то вроде: «На самом деле мы не можем подсчитать, сколько это стоит.У нас ДЕЙСТВИТЕЛЬНО есть данные о том, как долго идут дела, и так далее, но единственный способ привязать затраты — это сделать вид, что Х минут равно Х долларов, даже если это не имеет под собой никаких реальных оснований».

Если вы просто создадите какой-то чушь-алгоритм расчета затрат и вообще НЕ будете сопротивляться, вам придется винить только себя, когда руководство развернется и использует это произвольное выдуманное число, чтобы сделать что-то глупое, например, пожарные, или решит не исправлять какие-либо сбои и вместо этого сосредоточьтесь на использовании их синергии с порталом Sharepoint, сервером обмена веб-страницами в Интернете, 2013 г.

Обновлять: Чтобы внести ясность, я не говорю, что вы должны полагаться только на статистику со 100% точностью и просто отказаться от всего остального.
Я считаю важным то, что вы знаете, что измеряете.На самом деле вы измеряете не затраты, а время безотказной работы.Таким образом, вы должны быть откровенны об этом.Если вы хотите оценить стоимость, это нормально, но я считаю, что вам нужно это прояснить.

Если бы я выпустил такой отчет, я бы назвал его «отчетом о разборе аварии» и, возможно, имел вторичное поле, называемое «расчетная стоимость в зависимости от 5 долларов в минуту». Менеджеры получают свою оценку затрат, но ясно, что фактический отчет основан на времени безотказной работы, и стоимость является лишь оценкой, и как работает оценка.

Здесь не хватает фактора..у большинства приложений есть фактор «выпучивания», когда сбои внезапно начинают «стоить» намного дороже, потому что люди теряют уверенность в услуге, которую предоставляет ваше приложение.Как только это произойдет, тогда это может быть очень вернуть пользователям доверие к системе и ее использование обходится дорого.

Это зависит...

С точки зрения стоимости, только важно то, влияние на бизнес сбоя, так что это скорее зависит от типа приложения.

Для некоторых приложений может оказаться невозможным определить влияние на бизнес.Для других могут быть значимые меры.

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

Стоимость ремонта также может оказаться полезной.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top