Летом в отпуске положено читать книги. Книг по системному анализу вообще мало. А художественных почти и нет. Но я неожиданно нашел! "Парк Юрского периода" - уже не помню, что там в фильме, а книга-то вся про системный анализ, с небольшими вкраплениями динозавров, просто для антуража.
Там же весь набор:
- эксперты не выдают ключевую информацию, потому что считают её несущественной/ошибочной/редким частным случаем (эксперты вообще склонны рассказывать про типовой опыт, а не про отклонения -- хотя именно отклонения и частные случаи "убьют" вашу систему. В книге про это тоже есть - "вы исследуете не систему, как она есть на самом деле, а систему, как вы её ожидали увидеть", говорит персонаж-математик);
- заказчики не выдают полной картины назначения и использования системы, а только частные ТЗ на отдельные модули - и пытаются из этого собрать работающую целостную систему, с предсказуемым результатом;
- потом те же заказчики требуют от программиста всё бесплатно доделать, и думают, что им за это ничего не будет;
- нанимают системного аналитика, а потом игнорируют его рекомендации - классика!
Отличный план для реализации сложной системы!
Какие ещё являения описаны очень жизненно:
во-первых, сочетания множества безобидных факторов, приводящих к катастрофе. Ну там: работы на центральном пульте управления, баг в управляющем контуре, одновременно с этим начинается гроза, одновременно с этим по каналам связи передается большой объем данных, одновременно с этим один сотрудник случайно пропустил нужный поворот, одновременно от ветра падает дерево... ну, понятно, заканчивается это тем, что кого-то съели. Я смотрел анализ крупных катастроф - они почти все были результатом сочетания многих факторов. Очень часто вмешивается природный или какой-то внешний фактор: ночь, дождь, туман, гроза, снегопад, или наоборот жара; повышение потребления, высокий трафик или наоборот - резкое падение... Мой однокурсник делал знаменитую пятерку новостей (ещё до закручивания гаек, когда всё было по-честному) - и рассказывал, что они очень быстро вычистили все часто встречающиеся ошибки - ну, вероятность которых больше 0,00001% - то есть, происходят на главной Яндекса по нескольку раз в день. Уже на вероятностях 0,001% это были сочетания трех-четырех маловероятных факторов. Дальше пошли сочетания 6-7 крайне маловероятных факторов - то есть, человек вообще про такие штуки редко думает, а уж представить, что будет при их сочетании заранее очень сложно. Между тем, в современных высоконагруженных системах такие события происходят гораздо чаще, чем мы ожидаем. В книге это очень достоверно показано.
во-вторых, создатели парка явно не изучали методические документы ФСТЭК по безопасности, поэтому у них там куча дыр и с точки зрения защищенности (чтобы защитить свои данные и ноу-хау), и собственно в безопасности (чтобы снизить вред для пользователей, операторов и окружающей среды). Например, в книге очень ярко показано, что может натворить внутренний нарушитель с высоким потенциалом и со следующими возможными целями (мотивами): "Причинение имущественного ущерба путем мошенничества или иным преступным путем. Любопытство или желание самореализации (подтверждение статуса). Месть за ранее совершенные действия. Выявление уязвимостей с целью их дальнейшей продажи и получения финансовой выгоды. Непреднамеренные, неосторожные или неквалифицированные действия".
в-третьих, создатель парка впадает в типичную ловушку всех визионеров: пытаться одновременно внедрить сразу несколько инноваций. Чувак, у тебя и так уже динозавры, чего ещё?! Но нет - ещё мы сделаем уникальную систему автоматического управления, чтобы людей поменьше нанимать, и впихнем в неё системы распознавания образов, автономные автомобили и сложный BI, завязанный на безопасность. Кто реально занимался сложными системами, знает железное правило: одно инновационное изменение за раз! Иначе будет невозможно локализовать проблему.
Там же весь набор:
- эксперты не выдают ключевую информацию, потому что считают её несущественной/ошибочной/редким частным случаем (эксперты вообще склонны рассказывать про типовой опыт, а не про отклонения -- хотя именно отклонения и частные случаи "убьют" вашу систему. В книге про это тоже есть - "вы исследуете не систему, как она есть на самом деле, а систему, как вы её ожидали увидеть", говорит персонаж-математик);
- заказчики не выдают полной картины назначения и использования системы, а только частные ТЗ на отдельные модули - и пытаются из этого собрать работающую целостную систему, с предсказуемым результатом;
- потом те же заказчики требуют от программиста всё бесплатно доделать, и думают, что им за это ничего не будет;
- нанимают системного аналитика, а потом игнорируют его рекомендации - классика!
Отличный план для реализации сложной системы!
Какие ещё являения описаны очень жизненно:
во-первых, сочетания множества безобидных факторов, приводящих к катастрофе. Ну там: работы на центральном пульте управления, баг в управляющем контуре, одновременно с этим начинается гроза, одновременно с этим по каналам связи передается большой объем данных, одновременно с этим один сотрудник случайно пропустил нужный поворот, одновременно от ветра падает дерево... ну, понятно, заканчивается это тем, что кого-то съели. Я смотрел анализ крупных катастроф - они почти все были результатом сочетания многих факторов. Очень часто вмешивается природный или какой-то внешний фактор: ночь, дождь, туман, гроза, снегопад, или наоборот жара; повышение потребления, высокий трафик или наоборот - резкое падение... Мой однокурсник делал знаменитую пятерку новостей (ещё до закручивания гаек, когда всё было по-честному) - и рассказывал, что они очень быстро вычистили все часто встречающиеся ошибки - ну, вероятность которых больше 0,00001% - то есть, происходят на главной Яндекса по нескольку раз в день. Уже на вероятностях 0,001% это были сочетания трех-четырех маловероятных факторов. Дальше пошли сочетания 6-7 крайне маловероятных факторов - то есть, человек вообще про такие штуки редко думает, а уж представить, что будет при их сочетании заранее очень сложно. Между тем, в современных высоконагруженных системах такие события происходят гораздо чаще, чем мы ожидаем. В книге это очень достоверно показано.
во-вторых, создатели парка явно не изучали методические документы ФСТЭК по безопасности, поэтому у них там куча дыр и с точки зрения защищенности (чтобы защитить свои данные и ноу-хау), и собственно в безопасности (чтобы снизить вред для пользователей, операторов и окружающей среды). Например, в книге очень ярко показано, что может натворить внутренний нарушитель с высоким потенциалом и со следующими возможными целями (мотивами): "Причинение имущественного ущерба путем мошенничества или иным преступным путем. Любопытство или желание самореализации (подтверждение статуса). Месть за ранее совершенные действия. Выявление уязвимостей с целью их дальнейшей продажи и получения финансовой выгоды. Непреднамеренные, неосторожные или неквалифицированные действия".
в-третьих, создатель парка впадает в типичную ловушку всех визионеров: пытаться одновременно внедрить сразу несколько инноваций. Чувак, у тебя и так уже динозавры, чего ещё?! Но нет - ещё мы сделаем уникальную систему автоматического управления, чтобы людей поменьше нанимать, и впихнем в неё системы распознавания образов, автономные автомобили и сложный BI, завязанный на безопасность. Кто реально занимался сложными системами, знает железное правило: одно инновационное изменение за раз! Иначе будет невозможно локализовать проблему.