Области надёжности и ненадёжности Опции

[Александр Вакуров]

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

Области ненадёжности располагаются:

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

[Александр Вакуров]

Продолжение:

[info]__link

2010-04-21 11:49 (местное)

(212.92.244.109)
Я - с другой стороны прилавка. Да, именно в таких ситуациях меня часто оценивали по параметру "надежность". Более того, чем более интересными и нетривиальными (и потенциально выгодными фирме) вещами я занимался, тем более шатким становилось мое положение. Полагаю, что в любой другой фирме дело обстоит так же или хуже.

Начальник думает: вот у меня сидят веб-программисты - вот они надежны, они не подведут! Вон какую фенечку красивую к нашему сайту прикрутили. Обещали - и сделали. А этот умник, что ядро системы пишет - он и мнется, и не обещает ничего, и объяснить не может, зачем ему еще раз переписывать то, что уже работает... Сколько новых функций провалил и затянул - не счесть! (Вообще говоря, умный шеф наполовину понимает, что занятия "чепухой" очень нужны; что проваленные и затянутые новые возможности системы были провалены-затянуты не без причин. Но, в любом случае, доверия к программисту это не добавляет.)


Как правило, программист может оценить реализуемость и трудоемкость той или иной функциональной возможности. Но иногда... Иногда невозможно что-то обещать. Более того, невозможно заранее определить, когда это невозможно. Описанная ситуация возникает не часто, но обязательно возникает у любого программиста. Она практически не возникает, если мы пишем интерфейсы пользователя. Она почти обязательно возникает, когда мы пытаемся отвечать на вопросы, на которые пока еще никто не ответил.

[info]__link

2010-04-21 12:55 (местное) Выбрать: Удалить Скрыть Заморозить Track This

(212.92.244.109)
Дальше. Тема инженерной надежности глубока и необозрима. Если ограничиться программными системами, при прочих равных надежнее будет система, в которой:

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

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



Еще один аспект надежности, скорее, из электроники - это когда ошибка, проходя по системе вместе с основной информацией, не усиливается.