На что обратить внимание для повышения устойчивости информационных систем?

могу сказать что без юзкейса этой самой ис это не мозговой штурм, а зайчатки маразма

+1

и вот еще такой риск: система написана, но конечные пользователи отказываются с ней работать, потому что проще и быстрее сделать в legacy-интерфейсе мейнфрейма, чем клацать по красивеньким кнопочкам в web-интерфейсе - ей богу, видел такое два раза: операции занимавшие в старой системе 40 минут, надо было делать 4 (!) дня в новомодной супер-энтерпрайз мега-веб-два-ноль системе.

это классика, щас сам шевелю мозгами как сделать так чтобы было удобно не мне, а неким пользователям которые на вопрос «как вам удобнее» мычат и мотают головой метлю пебиуса.

В голову тебе пришли не риски, а TODO.

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

P.S. риски, вообще говоря, касаются не архитектуры, а среды, в которой «живет» твой бизнес, и процесса, который ты организовал для создания и вывода продукта на рынок.

первая это бизнес риск, топикстартер на менеджера не тянет ему это не надо.

все риски так или иначе - «бизнес», потому что они связаны с событиями, которые могут произойти с некотрой вероятностью и неким образом повлиять на финансовый результат.

есть еще риск: риск неверно оценить риски :-)

топикстартер, тебе вообще-то не риски надо, а то что называется «план проекта» - чем более подробный он у тебя будет, тем более вероятно, что ты сделаешь ту ИС, которую задумал.
когда у тебя будет подробный план, риски сможешь вот так оценить - берешь любую ветку/подветку плана и задаешь себе вопросы:
1. что может помешать сделать работы в этой ветке в срок/в рамках бюджета
2. каким будет финансовый результат, если это произойдет
3. какая вероятность, что это может случиться
4. что надо сделать, что бы снизить вероятность данного события
5. что надо сделать, что бы снизить его стоимость

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

мотают головой метлю пебиуса

В цитатник!

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

то что называется «план проекта»

Техническим заданием это называется.

Меня интересуют именно эксплуатационные риски.

потому что проще и быстрее сделать в legacy-интерфейсе мейнфрейма

Спс, кстати.

С тудушкой кагбэ всё понятно, именно риски волнуют мою душу по состоянию на теперь.

Опять двадцать пять, kvitaliy очень хорошо про риски написал.

Твой топик должен называться как-то так «Что можно сделать для повышения устойчивости ИС» или «Что может зафакапиться в ИС?».

эксплуатационные риски: риски связанные со средой, в которой живет ИС, с интерфейсами, через которые происходит обмен информацией, с квалификацией тех, кто эксплуатирует, с качеством процесса получения обратной связи от последних (надо знать, где удобно/неудобно и, самое главное, как часто этим пользуются и на сколько неудобно/удобно), риски невосстановеления из резервных копий после сбоя, риски восстановления устаревших состояний (потеря данных), риск связанный с ситуацией «мусор на входе, мусор на выходе».

Риски еще можно так искать - «смотришь» на систему и перебираешь все места, в которых ты точно уверен, что с ними не может быть проблем - вот в них и надо искать риски. Если получится найти что-то в стабильных частях, то с остальными точно справишься.

Спасибо за развёрнутый комментарий.

Защита от ошибок в собственном коде — сегфолты, зависания, утечки ресурсов (дескрипторов, дискового пространства, оперативы, etc)

Защита от злого умысла — намеренно сформированные некорректные входные данные, приводящие к: переполнению буферов, коллизиям в хеш-таблицах, чрезмерному потреблению ресурсов, разрушению хранимых данных.

пожалуйста

ИС = искусственный спутник или интегральная схема, неясно?

Информационная система

Бегло взглянув на теги, прочитал как «морозоустойчивое проектирование». А вроде трезвый...

Иди, готовься к выходным, товарищ)))