Comments 18
Что, наработка на отказ у распредщита и автомата меньше, чем у циски ASR? Вы сами в это верите?
Интересный вопрос. Смотря какой производитель.
В таблице для расчетов приведены стандартные данные, ABB обычно выдает mtbf 15 лет, шнайдер 100 лет.
Про щиток еще проще — плата там такая в поставке встречается, что часто бывает нужно допаивать контакты.
В таблице для расчетов приведены стандартные данные, ABB обычно выдает mtbf 15 лет, шнайдер 100 лет.
Про щиток еще проще — плата там такая в поставке встречается, что часто бывает нужно допаивать контакты.
Какой то странный "стандартный" расчёт, который каждый раз выдаёт неправильный результат. И почему вы не показываете структуру схему? Ведь именно от неё и зависят ваши разные реальные случаи. А то вы говорите, что мол к.г. для лохов, неправильно считает, а сами только половину работы показываете.
У вас в тексте указан ASR9000v. Но в таблицах я его не увидел. Так задумано?
Вендор нечасто публикует значение MTBF в особенности для компонент сложных систем. Поэтому вопрос, откуда Вы взяли эти цифры, очень интересен. Фраза: «являются оценочными», к сожалению, на него в полной мере не отвечает. Хотелось бы увидеть выкладки (методику оценки, входные данные и пр.). А без этого трудно верить итоговым результатам.
Не совсем, понятно, почему Вы решили ещё ввести «Restart\Shutdown procedure». Ведь точкой отчёта является уже готовая, работающая система. Проектирование, настройка, ввод в эксплуатацию явно выходят за рамки.
(*) – исходные данные по параметру MTBF являются оценочными, предоставленными по данным позициям оборудования производителя или их аналогам.
Вендор нечасто публикует значение MTBF в особенности для компонент сложных систем. Поэтому вопрос, откуда Вы взяли эти цифры, очень интересен. Фраза: «являются оценочными», к сожалению, на него в полной мере не отвечает. Хотелось бы увидеть выкладки (методику оценки, входные данные и пр.). А без этого трудно верить итоговым результатам.
Не совсем, понятно, почему Вы решили ещё ввести «Restart\Shutdown procedure». Ведь точкой отчёта является уже готовая, работающая система. Проектирование, настройка, ввод в эксплуатацию явно выходят за рамки.
У вас в тексте указан ASR9000v. Но в таблицах я его не увидел. Так задумано?
в таблицах это поз.13 и поз.12 в крайней табличке.
Вендор нечасто публикует значение MTBF в особенности для компонент сложных систем. Поэтому вопрос, откуда Вы взяли эти цифры, очень интересен.
Эти данные обычно запрашиваются напрямую у вендора на оборудование после процедур квотирования, оформления закупки и поставки и т.д. В открытом доступе их сейчас нет. В публикации приведены близкие к реальным параметрам данные.
The Cisco ASR 9000 Series Routers are designed to have high Mean Time Between Failures (MTBF) and low Mean Time To Resolve (MTTR) rates, thus providing a reliable platform that minimizes outages or downtime and maximizes availability. The MTBF is calculated based on the Ground Benign condition. The values may be adjusted based on the different router usage.
в таблицах это поз.13 и поз.12 в крайней табличке.
Вендор нечасто публикует значение MTBF в особенности для компонент сложных систем. Поэтому вопрос, откуда Вы взяли эти цифры, очень интересен.
Эти данные обычно запрашиваются напрямую у вендора на оборудование после процедур квотирования, оформления закупки и поставки и т.д. В открытом доступе их сейчас нет. В публикации приведены близкие к реальным параметрам данные.
The Cisco ASR 9000 Series Routers are designed to have high Mean Time Between Failures (MTBF) and low Mean Time To Resolve (MTTR) rates, thus providing a reliable platform that minimizes outages or downtime and maximizes availability. The MTBF is calculated based on the Ground Benign condition. The values may be adjusted based on the different router usage.
У меня всего два вопроса.
1. При существующей стоимости ASR-9006, является ли критичной экономия на еще одном шкафу телекоммуникационном.
2. Зачем вы на КДПВ сожгли колобка в пентаграмме?
1. При существующей стоимости ASR-9006, является ли критичной экономия на еще одном шкафу телекоммуникационном.
2. Зачем вы на КДПВ сожгли колобка в пентаграмме?
И два ответа.
1. Подобный расчет делается при расчете количества ЗИПа при очень большом количестве оборудования, уровня Hetzner и прочих Akamai.
В отдельно стоящей стойке с количеством цисок равным 2 — вероятность равна 33%.
Или откажет только одна, или обе, или будет работать.
2. На КПДВ изображен инженер-эксплуатационщик, которого поджаривают за простой, потому что проектанты прикрылись подобным расчетом, но в силу протекшего потолка/кондиционера/пожара/срабатывания пиропатрона/техуборщицы/бракованной партии/чегоугодно оно поломалось все и сразу, не смотря на MTBF.
1. Подобный расчет делается при расчете количества ЗИПа при очень большом количестве оборудования, уровня Hetzner и прочих Akamai.
В отдельно стоящей стойке с количеством цисок равным 2 — вероятность равна 33%.
Или откажет только одна, или обе, или будет работать.
2. На КПДВ изображен инженер-эксплуатационщик, которого поджаривают за простой, потому что проектанты прикрылись подобным расчетом, но в силу протекшего потолка/кондиционера/пожара/срабатывания пиропатрона/техуборщицы/бракованной партии/чегоугодно оно поломалось все и сразу, не смотря на MTBF.
1. Смотря какая скидка у поставщика при закупке. У меня был вариант монтажа в одном шкафу 9006 и 9006, 9006 и 9010. Две 9010 в один шкаф не ставили пока что никогда — в публикации отражен идеальный случай, но с монтажом будет сложно при таком шкафе даже. Два шкафа это еще квадрат площади в цод и игры с патчами — между шкафами без перегородки или под фальшполом…
2. Это продакшин-колобок и он в теме.
2. Это продакшин-колобок и он в теме.
1. Смотря какая скидка у поставщика при закупке.
Битый эксплуатационщик никогда не сложит яйца в одну… корзину, если она находится в том же здании. Никакая скидка не компенсирует форс-мажор.
2. Это продакшин-колобок и он в теме.
Как менеджер менеджера — я вас прекрасно понимаю.
Но если эксплуатационщиков долго бить и унижать — из них течет кровь.
Они тоже, внезапно, люди.
И ещё интересный момент — производитель грубо говоря берет все тривиальные компоненты электросхемы (транзисторы, кодеры и тд), загоняет в специальную прогу и считает в ней итоговую наработку на отказ. Для измерения надежности элементарных компонент есть возможности (f.e. Камеры искусственного старения). Но как учесть этот показатель для софта? Даётся ли какая-нибудь табличка по вероятности нахождения баг различного уровня? Думаю, вопрос риторический.
Таблички вероятности бага (публичной) нет, хотя внутренние исследования по этой теме проводили наверное многие из тех кто софт разрабатывает.
Конкретно по сетевому оборудованию и софту есть, например, такие данные:
источник, если не ошибаюсь, то метод получения этих цифр дан в книге High Availability Network Fundamentals (Cisco Press, 2001)
Конкретно по сетевому оборудованию и софту есть, например, такие данные:
источник, если не ошибаюсь, то метод получения этих цифр дан в книге High Availability Network Fundamentals (Cisco Press, 2001)
Это очень интересно. То есть грубо говоря, чем старее софт, тем в нем меньше необнаруженных багов и тем он надежнее, и таким образом надежность оборудования тем больше, чем стабильнее используемая версия софта. А значит надо поставить самую стабильную сборку и отключить все автоматические апдейты нафиг, чтобы MTBF софта не влияла на MTBF системы.
Но это же противоречит с концепцией постоянных апдейтов для той же кибербезопасности, например. Что делать?
Сиско тут пишет не о сборках, а скорее о ветках ПО, причём параллельно находящихся в продакшне (так получены данные, из которых выведены цифры MTBF).
Т.е. более старая актуальная ветка (например, IOS XE 3.6.x) более стабильна, чем более новая (IOS XE 3.9.x).
Это не значит, что сборка 3.6.3 более стабильна, чем 3.6.7. Очевидно, что в пределах одной ветки в самой последней сборке (ожидаемо) закрыто больше багов.
Т.е. более старая актуальная ветка (например, IOS XE 3.6.x) более стабильна, чем более новая (IOS XE 3.9.x).
Это не значит, что сборка 3.6.3 более стабильна, чем 3.6.7. Очевидно, что в пределах одной ветки в самой последней сборке (ожидаемо) закрыто больше багов.
Однозначного ответа нет. С одной стороны, обновление — шанс нарваться на новый баг. С другой, оставаясь на старой стабильной ветке, в один прекрасный момент получить отказ устройства из-за уязвимости.
Если нет каких-то требований со стороны внешних регулирующих органов(организаций), зачастую обновляют софт на устройствах внутри периметра сети только при острой необходимости (появившийся баг, требования новой функциональности). Тут стабильность в приоритете.
С устройствами на внешнем периметре ситуация чуточку другая. В этом случае вопрос безопасности становится острее.
Если нет каких-то требований со стороны внешних регулирующих органов(организаций), зачастую обновляют софт на устройствах внутри периметра сети только при острой необходимости (появившийся баг, требования новой функциональности). Тут стабильность в приоритете.
С устройствами на внешнем периметре ситуация чуточку другая. В этом случае вопрос безопасности становится острее.
И ещё интересный момент — производитель грубо говоря берет все тривиальные компоненты электросхемы (транзисторы, кодеры и тд), загоняет в специальную прогу и считает в ней итоговую наработку на отказ.
Так обычно делается для систем, для которых очень трудно собрать реальную статистику отказов — например выпускаемые в единственном экземпляре. Расчетное значение обычно получается очень консервативным, поэтому данная методика не очень популярная.
Но как учесть этот показатель для софта? Даётся ли какая-нибудь табличка по вероятности нахождения баг различного уровня?
Считается, что баги в софте будут рано или поздно вылезаны, поэтому для софта вероятность отказов не будет постоянной во времени и как тут считать наработку на отказ?
Sign up to leave a comment.
Примеры расчета «коэффициента готовности» для комплектов сетевого оборудования