Найти в Дзене

С чего начинается проектирование ИТ системы?

Абсолютное большинство проектов, что видел я - с некоторых технических требований, зачастую взятых с потолка, потому что заказчик так сказал или просто с потолка. Абсолютно большинство проектов идет путем "поковырялся в носу - делаем вот так - обосновали почему вот так подходит". Это подход не инженерный, а крафтовый или если хотите ремесленно-художественный. Хороший технический проект неразрывен и решает бизнес задачи. Ну какие технические требования вы ждете от заказчика? Если заказчик в состоянии правильно сформулировать тех требования, то и проектирование он тоже в состоянии сделать. Поэтому любой хороший проект начинается с формулирования бизнес требований и бизнес критериев, а документ "технические требования" разрабатывается на их основе. Что же за требования и критерии эти бизнесовые? 1. RPO - целевое предельное время потери данных (и стоимость потери в руб / час) 2. RTO - целевое предельное время восстановления сервиса (и стоимость простоя в руб / час) Иногда невозможно напря

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

Абсолютно большинство проектов идет путем "поковырялся в носу - делаем вот так - обосновали почему вот так подходит".

Это подход не инженерный, а крафтовый или если хотите ремесленно-художественный.

Хороший технический проект неразрывен и решает бизнес задачи. Ну какие технические требования вы ждете от заказчика? Если заказчик в состоянии правильно сформулировать тех требования, то и проектирование он тоже в состоянии сделать.

Поэтому любой хороший проект начинается с формулирования бизнес требований и бизнес критериев, а документ "технические требования" разрабатывается на их основе.

Что же за требования и критерии эти бизнесовые?

1. RPO - целевое предельное время потери данных (и стоимость потери в руб / час)

2. RTO - целевое предельное время восстановления сервиса (и стоимость простоя в руб / час)

Иногда невозможно напрямую измерить стоимость, но можно наложить ограничения в виде "потеря данных более 24 часов - уголовное дело".

Если у вас есть сформулированные RPO/RTO в деньгах - внезапно полностью уходит вопрос обоснования стоимости проекта и выбранной стратегии катастрофоустойчивости - меткрокластеров, геореплик и тп.

В случае с проектированием облачных решений (на базе облаков) важно понимать, что SLA читается в обратную сторону. Т.е. в первую очередь необходимо рассматривать ответственность провайдера, и лишь потом целевой уровень сервиса. Что вам толку от 30% скидки на месячную абон плату, если бизнес лежит трое суток и потери составили уже годовую стоимость облака?

Я уже писал о занимательной облачной арифметике в SLA - https://t.me/beerpanda/134

И внезапно оказывается, что задолго до написания первых требований по vCPU, MHz, GB RAM, IOPS уже полностью понятна высокоуровневая архитектура. И не просто понятна, а полностью обоснована и отметены альтернативы с железобетонной аргументацией. И все "облако же дешевле в 3 раза" можно не рассматривать ровно настолько же, насколько мы не рассматриваем, что Логан в 3 раза дешевле КАМАЗа.