Анатолий Левенчук – Системная инженерия – 2022 (страница 12)
Если где на конвейере завода неудачно выпадет винтик из-за того, что что-то там было плохо спроектировано, потом плохо смонтировано, поломка плохо диагностирована, может неожиданно остановиться весь завод. Ну, или работники завода могут забывать вести учёт изменений оборудования этого завода – и будет непонятно уже, какое там стоит оборудование, и как его ремонтировать. Это кажется не таким важным для автомобильного завода, но в США как-то была закрыта атомная станция из-за того, что состав оборудования «в жизни» через несколько лет работы стал существенно отличаться от состава оборудования «по документам»: никто не давал гарантии, что будет понятно, как быстро отреагировать на проблемную аварийную ситуацию, разобраться «по чертежам» уже стало невозможно, эксплуатацию сочли далее очень опасной, атомную станцию закрыли. Это проблема в организации труда инженерной бригады, и в конечном итоге это тоже проблема инженерии, но инженерии предприятия, называемой обычно «менеджментом» («организационным менеджментом» в части создания и модификации/модернизации организации, «операционным менеджментом» в части эксплуатации созданной организации).
Всё то же самое относится к «нежелезным» системам. Если вы работаете с генной инженерией, то используете вирусы. Это означает, что вам нужно соответствующим образом простроить работу исследовательской лаборатории, работу производственных мощностей, организовать работу с персоналом и ещё отвечать на многочисленные вопросы по биоэтике, а также делать это достаточно долго, всё не закончится первым же продуктом, будь он удачным или не очень удачным. То есть работать нужно отнюдь не только с самими вирусами! Это всё проблемы «системного инженера»:: роль (роль, а не «должность»! ). Такую роль могут выполнять десятки людей в большом проекте. Системный инженер держит все (и в окружении, и в цепочках создания) системы в проекте взаимоувязанными, ибо именно у него (или у них, если проект большой) в голове и компьютерах (основной инструмент – моделер для системного моделирования) практика раскладки всей сложной производственной системы в её окружении на уровни, а также раскладки рассмотрения разных интересов в рамках одного уровня на разные практики, многоуровневой оптимизации решений для удовлетворения всех интересов (конфликтов/противоречий между решениями разных уровней избежать нельзя, нужно проявлять изобретательность, и всё равно в результате будет неустроенность/неустаканенность в конструкции системы, будет проявляться субоптимальность в решении этих конфликтов). В помощь системным инженерам тут компьютеры, позволяющие удерживать всю эту сложность в усиленной компьютером памяти, проводить имитационное моделирование для экономии времени и материалов по сравнению с пробами и ошибками в реальной жизни. Компьютеры помогают удерживать коллективную собранность: проявлять коллективное внимание к каждой мелочи нижних уровней разбиения систем, не теряя коллективного внимания ко всему огромному целому на верхних уровнях, глубоко уходящих в окружение, и это коллективное внимание будет удерживаться компьютерами также и на этих верхних, надсистемных уровнях окружения, а также по необходимости на всех уровнях систем и их окружения по цепочке создания. Ответственный за организацию коллективного многоуровневого внимания к самым разным системам как раз системный инженер. «Системный» тут как раз отсылает к многоуровневости внимания, в отличие от внимания прикладных инженеров к одной предметной области какого-то одного системного уровня для систем какого-то одного вида.
Роль (системного) инженера
Все рассуждения про роли и агентов/IPU как актёров/деятелей/практиков:: «исполнителей ролей» полностью применимы к системным инженерам как деятелям/практикам, занимающимся практиками системной инженерии. Причём для системных инженеров как «деятелей/практиков вообще» будет два вида конкретизации, если нужно разбираться с ролями в жизни:
• Конкретизация по линии масштабов и видов систем в каждом масштабе.
• Конкретизация по линии разных видов инженерных практик для одного и того же сорта систем – и вот тут системные инженеры занимаются не столько разработкой (это делают прикладные инженеры-разработчики, часто разрабатывая отдельные модули системы, ответственные за реализацию отдельных функций, максимально независмо друг от друга), сколько архитектурой, которая позволяет трудам прикладных инженеров-разработчиков интегрироваться в надёжную, масштабируемую, производительную, легкодоступную, выдерживающую случайные отказы (это мы всё перечисляем разные предметы интереса архитектора, об этом будет отдельная глава нашего курса), также многочисленными практиками непрерывного ввода в эксплуатацию, начиная с управления конфигурацией и заканчивая организацией разворачивания результатов работы команд разработчиков и обеспечения доступа пользователей к системе (transfer, ввод в экслупатацию). Этих системных инженеров называют DevOps, о них тоже будет большая глава.
• У врачей тоже есть подобное разделение. Например, по типам практик вмешательства (стадия «изготовление»): терапевт (неинвазивные вмешательства и сборка разных других видов вмешательств в работающее целое, «ввод в эксплуатацию»), хирург (инвазивные вмешательства), врач функциональной диагностики (нет вмешательства, только диагностика как часть проектирования будущего вмешательства). И тут обычно обязательно будет добавляться вид системы, ибо вид вмешательства/изготовления существенно может отличаться в зависимости от вида целевой системы. Без того, с какой системой работаешь, о практике мало что можно сказать, хотя и тут можно вывести за скобки немало. Так, хирург лет двести назад ещё не был ярко выраженной подролью врача, это была просто одна из врачебных практик, лет пятьдесят назад хирургия была уже отдельной практикой, а сейчас практически независимо практикуется нейрохирургия и кардиохирургия, да и в целом уже не встретишь «хирурга общего профиля», кроме самых захудалых сельских больниц. Конечно, на какой-нибудь подводной лодке можно встретить даже «врача» по всем вопросам, а в деревне «фельдшера» (даже не совсем врача, но тоже по всем вопросам), но это уже не типичная ситуация, не отражает «лучших известных на сегодня практик»/state-of-the-art (SoTA). В инженерных проектах по созданию киберфизических систем можно встретить инженера-электротехника, инженера-теплотехника, инженера-электронщика, но в маленьком стартапе на трёх человек можно встретить и просто «инженера», а исполнитель этой роли ещё будет прихватывать и другие роли – продавца, проектного менеджера и даже уборщика помещения. Так и в системной инженерии бывает «просто системный инженер», а бывает системный архитектор или девопс (по-старинке иногда называемый системным администратором, хотя он давно уже ничего не администрирует, а создаёт «автоматического администратора»).
Всё разнообразие ролей, которые получаются конкретизацией по обеим линиям (масштабов и видов систем, а также видов инженерных практик) будет выполняться какими-то агентами (обычно людьми и их организациями), имеющими должности или составляющими какие-то оргзвенья. Не нужно думать, что системный инженер будет называться именно так. Он может быть на должности «ведущий инженер», может называться «завуч» в случае образовательных учреждений, может быть «координатором», смотреть нужно на содержание его деятельности/практики. Если это практика, описанная в нашем учебнике как архитектурная или DevOps, то она идёт с целой системой, так что это системный инженер.