Вы сказали, что заказчику нужно говорить про уровни. Поэтому и был мой коммент. Мб это подразумевало «про уровни в понятных ему терминах» - тогда да

Ну тогда мы поймем, сколько он готов заплатить (как высоко он ценит надёжность), а не какая ему нужна

А уровень "Б" это шторм, капец и метеорит в датацентр, но бизнесу все норм, продолжаем продавать - это вот 500 рублей

И тогда будет понятно за что они платят

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

Вообще крупные фирмы в стратегии определяют для систем уровни mission critical, buisness critical и т.д. и уже от это отталкиваются в СЛА и надёжности систем

согласен, в принципе, может потом повлечь конфликты типа "но мы думали, что будет нормально". с другой стороны, это все-таки бизнес, "нету ручек - нет конфеток"

В большинстве случаев нам потом с этим заказчиком ещё раз общаться
Если у него создастся впечатление, что мы его наебали, будет грустновато.

Заказчик - тоже человек. И тема "надежность" ему не всегда понятна. Поэтому каждый раз надо искать баланс между объяснением на языке заказчика и  профессиональным(непонятным для него) видением. При этом задача минимум - исключить неверное толкование со стороны заказчика и тем самым защитить себя от издержек. Можно попробовать договориться о присутствии эксперта со стороны заказчика, это переложит часть ответственности.

Чем больше встреч на начальном этапе, тем меньше нервов и подгоревших ягодиц потом.

Ну наверное не просто встреч, а открытого и отслеживаемого обмена инфой, понятной обеим сторонам

Да, конечно

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

я вообще не предлагаю никого наебывать. но дело в том, что "более красивое" решение обычно стоит дороже. это похоже на (раз уж у нас тема надежности) контрацепцию. можно купить пакетик целофановый за 1р., можно гусарский за 10 рублей, можно дюрекс за 50, а можно сагами за 300.
если честно, три последних варианта мне кажутся одинаковыми (говорят, что типа дешевые делаются там-же, где и средние), но при этом у меня чувства "наеба" не возникает.

Иногда случается ситуация, что ты вроде не наебываешь, а контрагент именно так видит)
Собственно одна из функций аналитика - избегать таких ситуаций

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

Если быть честным, то, что вы обсуждаете, на самом деле не очень классическая  ответственность аналитика. Где-то тут должен присутствовать тех.архитектор и инфраструктурщик, так как аналитику зачастую (если это только не аналитик, который находится в этом поле специально: аналитики на проектах по разработке решений типа PAAS, SAAS и некоторых других) не хватит компетенций и знаний техническо характера, особенностей платформ, инфраструктуры, чтобы вырабатывать решения и предложения. Что касается стоимостей и обсуждения оных с заказчиком, то это часто тоже лежит вне поля компетенций IT аналитика. В чистом виде, если работник, ведущий  аналитику, не исполняет другие роли, то углубление в (1) особенности организации DR, обсуждение подходов к репликации данных, обеспечение бесперебойности работы, а также (2) обсуждение с заказчиком конкретных стоимостей работ или оборудования чего бы то ни было на проекте - это не вопросы аналитика. Например, по TOGAF первое выделено в строго определённый уровень архитектуры, а второе - это вооьще уровень продаж и контрактов. Хорошо, когда есть люди, понимающие и знающие всё вышеперечисленное, и плохо, когда один человек занимается всем и сразу.
Для чего я это написал?
Наверное, чтобы напомнить о границах того, что мы обычно называем аналитикой в ИТ в общем понимании, а что чаще всего относится к компетенциям других ролей.

Аналитикам чаще всего достаточно просто знать существующий SLA по системе и опираться на него.

И ещё у меня плохое настроение из-за полсотни прочитанных резюме аналитиков за последние полторы недели, где я вижу в основном финансистов, продажников и ПМов вместо аналитиков. У меня уже крик души скоро будет на тему того, что заколебали портить ИТ аналитиков проджект менеджментом и продажами.
Сидишь потом и стопками CV в мусор отправляешь из-за отсутствия достаточного уровня технического опыта на позицию синиор-аналитика и абсолютного преобладания "менеджеров". Один коллега мне как-то заявил, что если ты не менеджер к 35 годам и не директор к 40, то ты лох. Чел не особо умный был, но всё время рвался в ПМ-ы. В итоге ушёл в скрам-мастера (nuff said). В такие моменты я вспоминаю "Страну Оз", где Ник Дровосек из-за широты души и большого сердца всем подряд давал в армии  своей повышения. В итоге у него была толпа генералов и один солдат, которым все командовали. Ровно это я наблюдаю сейчас на рынке труда аналитиков. Аналитики, пожалуйста, растите в своей области компетенций! Это обеспечит большую вариативность и стабильность трудоустройства, чем переход ПМ-ы. Если хочется расти куда-то дальше аналитики, то растите в архитектуру!

Нет, всё-таки крик души вырвался...