1. Время на проверку
Я долго наблюдаю за разработкой электроники и пока точно не знаю. Есть продукт, но как его сделали таким стабильным? Ведь время и различные условия показывают на сколько устройство хорошее. Хотя на сколько можно знать чужой продукт, чтобы видеть все его недостатки? Есть ли через полгода какие-то нарекания по работе в течение следующих 10 лет?
Но кто сказал, что новый смартфон это совсем другое устройство, а не постепенное улучшение продукта. И ведь каждый дом не на столько уникален, чтобы один был из семечек, а второй и сахарной пудры. Это круговой процесс.
2. Как приблизиться к безотказности устройства
Основные наработки по нарастанию безотказности устройства:
- команда и её мотивация, зависящая от руководства;
- использование уже протестированного много раз однотипного узла;
- заранее тестирование новых узлов в текущих проектах, где они избыточны;
- дублирование узлов в регулируемую избыточность;
- проведение тестирований устройства в различных режимах и условиях работы;
- длительная наработка часов у разных клиентов со сбором обратной связи;
- самодиагностика с определением мероприятий ТО;
- перенос бОльшей неопределённости на начало проекта;
- постоянное улучшение процессов разработки;
- меньшее использование новых/непроверенных узлов.
И каждый из этих пунктов имеет за собой определенную цену как в виде денежных, умственных, так и временных затрат.
3. Порядок показателей
Порядок отказоустойчивости определяется конкретным значением. И к авиационной электронике за полет предъявляются следующие требования к возможной вероятности:
- сложной ситуации – не более 1 ситуации на миллион,
- аварийной ситуации – 1 на 10 миллионов и
- катастрофической ситуации – 1 на 1 миллиард полетов
И эта разница колоссальна. Но мы же не должны допустить как разработчики и, наконец, люди, таких ситуаций в принципе?! Похоже невозможно полностью избавиться от рисков, но как приблизиться к этому?
Физика устроена по своим законам и день за днем им следует. Её нельзя убедить за конфетку, что «там» все хорошо, в отличие от человека). Мир, конечно, меняется, но константы, на которых он устроен, мне верится нет
4. Кого мы знаем из современных инженеров?
В рассудке всплывают какие-то пепе персоны, где, как всегда, на виду. При этом обычному люду инженеры, конечно, приятны глазу, но разве они могут рассмешить? А могут! но от этого не становятся более весомыми. Ирония в том, что комику нечем стоящим поделиться, а инженер не считает смешным рассказывать о своей деятельности. Но они оба лучшие в своем, либо таковых можно обнаружить
Наши соседи инженеры всегда в тени, но и исторически за свои умения можно было создать неприятностей. При этом я бы различал контент мейкеров и тех, кто сталкивается с конкретными задачами и проблемами, а не теориями. Но чем делиться, когда кажется все специфичным, скучным и сложным? А главное, какова цель?
5. Мотивация
Мотивация для меня пОшло с популярной точки зрения. Поднять жопу с дивана и смотивироваться, конечно, прекрасно. Но в чем ключевая разница, чтобы зимой быстрее добраться домой и, тем, чтобы зимой добраться домой, когда сзади бежит собака? Чем мы рискуем, занимая должность рядового инженера по поеданию печенек на кофе-брейках, когда можем в любой момент уволиться?
Проблема мне видится в том, что оказывается нам не нужна отказоустойчивость. Ведь у устройства есть куча других свойств. И выигрывая в одном, влияешь на другое. Если даже она нам так нужна, то достигнув её на сколько это нужно было продукту?
6. Не хочет или не моожет?
Кто погружен в различные этапы разработки более эмпатичен к косякам чужих систем. Например, если не работает сайт налоговой, или запись к врачу. Для большинства это сразу, что государство не хочет возвратить нам вычет. Так ещё и хочет вас угробить, чтобы вы не получили медицинскую помощь и стояли в очереди.
Никогда не работал в подобных непростых системах, но мне удивительно как это так хорошо работает. И дело не в том, что программисты лентяи на тяп-ляп (не, ну может быть и так). Мне верится, что нужны десятилетия на разработку, потому что мы сами точно не знаем, что хотим, и определяем свою истину. А создавать проблем на ровном месте, мы уже давно умеем.
7. Инженер нафантазировал, а кому чинить?
Тут есть разные сторон баррикад: пользователь, ремонтник и инженер (а существуют ещё?) Инженер сам себе напридумывал, у него было мало времени все проверить. Пользователь недоволен, что-то работает не так как нужно. Кто всех спасет?)
Тот, кто не знает, как должно быть, но знает как к этому прийти. Кто не виноват, что это не работает и наживается ещё! Кто не спит, пытается понять как устроена вселенная («эта штуковина») и весь в грязи. Кто потом безжалостно кроет матом (возможно в мыслях) что “какого это создали?” Спойлеры: этот тот рукастый мужик.
8. Проблема умных домов
И мы живем в наших «умных домах». Но мы на столько глупы, чтобы это все правильно настроить и понимать, когда что-то идет не так. Да и сама электроника глупа, но мне легче работать с глупой электроникой. Чем дать ей возможность включать неподобающие песни не по моему распущенному желанию. Дело отчасти в том, что я хочу попасть к себе домой даже при отключенном вайфае, свете, газе, даже если все батарейки погибнут. Не то что отказоустойчивость, здесь нет здравого смысла.
Но мы постепенно усложняем жизнь, создавая более сложные системы, и это уже неизбежно.
9. Что мы хотим получить?
Поэтому электроника достаточна сложна и безумна, а мы недальновидны и злы. Так что пока отказоустойчивость можно добиться только в простых системах, но скорее проверенных временем. И то, если нам действительно это нужно и это требуется выше других приоритетов.
Представьте 10 стаканов с характеристиками и у вас графин воды. Вы наполняете каждый из стаканов устройства по своему виденью: Сколько у вас осталось? Как лучше распределить? Вопросы, не имеющие однозначного ответа, пока нет опыта. Это как при наряжании елки какие именно использовать игрушки? Но позже, когда продукт уже есть, можно постепенно смещать характеристики.