Понятие конфигурации системы
Конфигурация**/**configuration системы — это текущее актуальное состояние системы (воплощения системы: всех частей на всех системных уровнях) и её описаний в их соответствии. Онтологически это сама система, но по факту — темпоральная часть, отвечающая какому-то состоянию её конструкции в плане наличия тех или иных версий конструктивов. Обычно в ходе разных проектов порождается (если «в металле», то даже изготавливается) множество самых разных вариантов возможных частей воплощения системы разной степени неудачности, и только одна из них находит своё место в целевой системе в момент эксплуатации, остальные так и остаются вне системы — или запчастями, или просто выкидываются за моральным старением. Может существовать и много вполне удачных воплощений для подсистем, но в целевой системе использованы не все (например, насосов было изготовлено десяток, но в насосную станцию попал только один из них — остальные были изготовлены, но часть проданы, а часть лежит на складе как возможная замена насосу, который сейчас работает в составе станции, если тот насос поломается).
А ещё в ходе проектирования обычно разрабатывается множество вариантов самых разных видов описаний системы и её частей, относящихся к разным моментам времени, эти разработки делаются самыми разными агентами. В проекте нужно понимать: какие варианты изо всех изготовленных частей системы в конце концов вошли в текущее воплощение системы, а также какие варианты описания являются актуальными для текущей. Ведь отнюдь не все изготовленные части будущей системы идут в дело, некоторые остаются неиспользованными. Отнюдь не все варианты описаний системы идут в реализацию: некоторые отвергаются в пользу других, подходящих для успешности системы, дающих системы более функциональные, более надёжные, более дешёвые, более быстрые в изготовлении и т.д. Если вы прошивку телефона к прошлой версии примените к модели телефона следующей версии — не факт, что она будет работать. Такие конфигурационные коллизии не должны происходить, все версии как частей системы, так и описаний системы должны соответствовать друг другу. Поэтому понятие конфигурации как состояния версий самой системы распространяется и на описания — нам нужны только те описания, которые описывают текущую конфигурацию системы, возможно, только будущей системы (это иногда отдельно называют конфигурацией описания системы).
В современном производстве принята эволюционная идея, при которой о системе думают как о виде систем: примерно так же, как об эволюционирующем виде животных или растений.
Во-первых, вид систем или животных (это множество, тип) представлен экземплярами (уникальными физическими объектами), которые все генетически немного разные, но принадлежат одному виду. Скажем, система Boeing-737::система при этом мыслится как «вид» из множества экземпляров слегка разных уникальных экземпляров физических авиалайнеров. Как определить, системой называют «вид» или «конкретный самолёт с бортовым номером»? Из контекста, по-другому никак. Если вы говорите о компьютере Dell XPS 13, то вы говорите о нём как обо всех компьютерах серии Dell XPS 13 и их развитии (они будут довольно разные конструктивно, модели каждого года имеют весьма различающиеся конфигурации), или о текущем компьютере с серийным номером, но и тут могут различаться тип центрального процессора, объём памяти, разрешение экрана — это можно выбрать при покупке. И всё это будет Dell XPS 13, в чём-то эти компьютеры будут схожи. То же самое — операционная система Windows, софт в вашем компьютере. Это или все похожие друг на друга версии системы Windows в их отличии от, например, iOS, или же конкретная версия какого-то года, или даже конкретная уникальная версия в вашем компьютере. Как узнать, о чём идёт речь? Из контекста, а если непонятно — переспросить!
Во-вторых отдельно думают о мемоме (все описания системы, они живут и развиваются в организациях-создателях, аналогично геному животных, который содержится в каждой клетке организма животного) и отдельно о феноме (совокупность свойств разработанных и воплощённых систем, у животных это совокупность свойств взрослого организма). В инженерии принят сегодня принцип «непрерывного всего»/ «continuous everything». Прежде всего это «непрерывная разработка»/«continuous delivery», которая не останавливается с выпуском воплощения первой версии системы в качестве MVP, minimal viable product, но главное — «непрерывное введение в эксплуатацию»/«continuousdelivery**»**, не путайтесь тут с переводом, это не просто «поставка клиенту», это всё-таки ещё и прошедшее уже разворачивание у клиента, «непрерывное разворачивание»/«continuous deployment» и далее непрерывные испытания/тестирование»/«continuous testing». Непрерывное введение в эксплуатацию означает, что создаются последовательно разные версии системы с разными её конфигурациями (наборами физических материальных частей и соответствующих им описаний, проходящие какие-то альтернативные маршруты по инструментам создателей — какую-то версию на одном станке делали, какую-то на другом), а ещё эти версии имеют разные описания. Понятно, что свойства всех систем получаются при этом разные. И даже эти вроде как конечные описания ещё и изменяются каждое по нескольку раз после доработок, исправлений ошибок, добавления новых возможностей/features в описываемую систему.
Как определить, какие из версий этих описаний должны быть использованы изготовителями для воплощения системы? А если часть изготовителей изменили воплощение системы так, что она уже не соответствует этим описаниям, а часть изготовителей работает «как договаривались» — можно ли быть уверенным, что из изготовленных частей можно будет собрать работающую систему? И какой именно экземпляр работающей системы? Автомобили Tesla разрабатывают сейчас в рамках производственного процесса, где разработчики и завод работают на одной производственной площадке, изменения в конструкцию вносятся без перерывания выпуска, операция на заводе может проводиться в двух альтернативных вариантах по образцу A|B testing[1], только сравниваются не два варианта всего автомобиля, а множество раз по паре вариантов в разных местах конвейера. Каждый автомобиль Tesla тем самым имеет уникальную конфигурацию, он не похож на другие автомобили той же марки, различаясь во множестве мест. Впрочем, и авиалайнеры делаются так же — чуть разные модификации двигателей, чуть разные конфигурации кресел, чуть разные системы управления, но нет двух одинаковых Boeing-747 в небе. При этом учитываем, что конфигурация системы это одно из конкретных состояний в плане версий частей системы самой «системы как вида» — эта «конфигурация» бегает по дорогам в случае автомобилей Tesla и летает в воздухе в случаях Boeing, это не описание конфигурации, которое не бегает или летает, а документировано в базе данных. Ближайшее к ней приближение — это пока ещё не бегающие и не летающие автомобиль или самолёт, которые уже собраны и проверенные стоят на заводе, они «в металле», но ещё не в эксплуатации. Это только программисты путают конфигурацию своей «проектной документации» (их исходных кодов) с конфигурацией самой системы (их уже работающей в машинных кодах программы). Инженеры «железных» систем точно должны понимать, что конфигурация системы, а то, что там есть ещё и описания без конфигурационных коллизий — это очень хорошо, но недостаточно для разговора о конфигурации, конфигурация описаний системы — это не конфигурация системы в момент её эксплуатации.
Ошибки, связанные с тем, что некоторые части системы и их описания не известны, или даже известны, но не соответствуют в своих текущих версиях друг другу, весьма распространены — эти ошибки и называют конфигурационными коллизиями (на инженерном сленге конфигурация с такими ошибками называется «разваленной конфигурацией», это очень неприятная ситуация, у «железных» инженеров обычно говорят «система не собирается», ибо все детали изготовлены — но собрать из них систему невозможно, «вот это круглое в одной части не лезет вот в это квадратное в другой части — непонятно, как такое получилось»).
Конфигурация системы — это сами части воплощённой системы и их описания, в современной инженерии конфигурации каждого экземпляра уникальны. Сама конфигурация может быть описана (defined) и, соответственно, документирована (described). Документация конфигурации (configuration description, иногда говорят и «конфигурационное описание») в речи часто сокращают до просто «конфигурация» — и разницу между конфигурацией (составом самой системы) и документацией конфигурации нужно определять из контекста так же, как разницу между архитектурой и архитектурной документацией, когда для обеих используют слово «архитектура».
Управление конфигурацией (configuration management) — отслеживание, что конфигурация воплощения системы и описания системы известны и соответствуют друг другу. Эта дисциплина лежит посредине между менеджерскими и прикладными инженерными дисциплинами. Конфигурация составляется из конфигурационных единиц (configuration item) — самых мелких частей, на которые делится система в части её логистики. Речь идёт о единицах передачи частей системы и описаний этих частей от одного исполнителя работ к другому, от одной обработки к другой.
Инженеры целевой системы часто имеют более детальные описания частей системы, чем это требуется для организации перемещения рабочих продуктов. Например, каждый из многих миллиардов транзисторов на чипе уникален, но конфигурационной единицей в цеху электроники служит сам чип, а не эти транзисторы, ибо отдельно транзисторы никому не передаются.
Чтобы не потерять эти конфигурационные единицы при учёте, иметь возможность на них сослаться в разговоре и различных описаниях системы, им даются индивидуальные обозначения (designations). Стандарт IEC 81346[2] представляет собой стандарт, в котором предлагается типовой способ такого описания, учитывающий системный подход — наличие нескольких альтернативных структур системы (функциональной, модульной/продуктовой, размещений, стоимостной и т.д.).
Версия (version) системы — это её конфигурация по состоянию на какой-то момент времени. Версии системы дают имя. Отслеживание смены версий в результате изменений (changes) нужно для того, чтобы точно указывать, какая из многочисленных возникающих и исчезающих по ходу проекта конфигураций системы имеется в виду. То, что не из любых версий можно собрать работоспособную систему, часто называют конфигурационными зависимостями/dependances.
В программной инженерии тоже есть варианты стандартов описания конфигураций, но они обычно не учитывают системный подход и опираются главным образом на идею о версиях исходного кода. Популярны «системы именования» частей кода Semantic Versioning[3], где делается попытка менять имена версии на основании того, большие изменения вносятся в исходный код, или это маленькие изменения, но потихоньку выясняется, что и большие, и маленькие изменения могут поломать систему в случае коллизии одинаково, поэтому предложили вариант попроще и понадёжнее: Calendar Versioning[4], где просто отмечается дата последнего изменения версии — так что можно по имени версии сразу сориентироваться, давно ли что-то в ней менялось.
Документация системы (сегодня практически 100% это электронные форматы, часто даже не классические «документы», а базы данных) всегда является документацией каких-то конфигурационных единиц (читаем: описания — это всегда описания каких-то систем или описания содержания, а иногда и формы других документов, версии документации — это версии описаний каких-то версий систем, версий других документов), и её обозначения обычно создаются путём приписывания к названию конфигурационной единицы вида описания. Если для каких-то целей вдруг потребовалось описать три или четыре конфигурационных единицы, то скорее всего речь идёт об описании какой-то системы из этих единиц и нужно просто создать из них новую конфигурационную единицу, которой и будет соответствовать описание.
Базис (baseline, конфигурационный базис) — это проверенная на целостность и утверждённая административно версия, но всё чаще и чаще этот термин считают свидетельством анахронизма в разработке: проверки на целостность происходят сейчас буквально для каждой версии, а административного утверждения версии при выпуске нескольких версий продукта в день — нет.
Управление изменениями (change management) часто включают в состав управления конфигурацией. Так и пишут: «управление конфигурацией и изменениями», но обычно это отдельная дисциплина. Её не нужно путать с управлением организационными изменениями — как нужно менять организацию, чтобы это не вызывало сопротивления людей и вело к положительным результатам. Инженерное управление изменениями — это про то, как принимать решения по изменению конфигурации, чтобы минимизировать конфигурационные ошибки. Для этого в конфигурации раньше различали 1. обычные рабочие версии с более простыми внесениями изменений, и 2. базисы, внесение изменений в которые связано с дополнительными инженерными и административными проверками на целостность конфигурации. Сегодня это седая старина, используют другие подходы к управлению изменениями, например, trunk-based development[5] (trunk/ствол — только ствол дерева версий, без ветвлений). Появилось много интересных наблюдений, например, что качество систем, для изменений базисов которых собирался какой-то совет по внесению изменений по факту не отличалось от качества систем, для которых базис не проходил какой-то коллективной оценки: любое «замораживание конфигурации» замедляло разработку, но не приводило к улучшению качества. Скажем, «заморозить внесение новых фич в конфигурацию, но не заморозить исправление в ней багов» повышало качество, но вот чтобы что-то там «замораживалось» в части описаний или самой конструкции — вот это оказалось вредным. Всё живое, всё меняется к (потенциально, не всегда получается) лучшему, а если ошиблись — это покажет интенсивное тестирование, которое проводится буквально для каждого экземпляра системы (один экземпляр — одна версия системы, как мы говорили), каждой версии каждого описания.
В любом случае, у вас должно быть налажено управление конфигурацией, вы в любой момент должны понимать, какие именно (из всех возможных вариантов) части системы стоят в изготовленной системе, по каким описаниям они производились — и тут важно, чтобы все они были без коллизий, в них не было ошибок и противоречий при объединении частей системы в систему и частных описаний в системное описание. Очень нехорошо получается, когда команда А разрабатывает свою часть системы с учётом результатов совещания, где размер части был принят 220 мм, а команда Б продолжает разрабатывать корпус, где для этой части предусмотрен старый размер 180 мм — ибо про совещание эта команда ничего не знала. Потом при сборке эта части встретятся: вот она, конфигурационная коллизия: ожидаемый корпусом размер части и размер изготовленной части не совпадают на 40 мм, система «не собирается». Лучше бы это найти до того момента, когда команда А уже изготовила эту часть системы, а команда Б — изготовила корпус. Вот этим и занимается управление конфигурацией и изменениями, чтобы такого в принципе не могло бы получиться.
IEC 81346-1:2022, Industrial systems, installations and equipment and industrial products — Structuring principles and reference designations — Part 1: Basic rules, https://www.iso.org/standard/82229.html ↩︎