Обсуждение

А мне вот странно, как у нас, без наличия формальной (целостной, описанной, измеряемой) модели, работают атомные станции и прочие критически стремные объекты. Надеюсь что придерживаются принципа - "не трогать то что работает" )). Но это пока оно само не развалится от старости, а дальше, а завтра ? Читал на днях "введение в системотехнику", так там промелькнула строчка о том что обратная связь систем в 10 раз увеличивает эффективность. А это ж краеугольный камень, формальная, актуальная модель того что делается. Наверно потому так часто на видео заседаниях инкозе слышно слово моделе-ориентированная си.

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

Когда я слышу что "100 руб на счету - это конфигурационные данные" - реально режет слух. Пример "100 руб у провайдера" реально плохой, потому что он про ИТ. В ИТ Управление Конфигурациями занимается совсем другими вещами. "100 руб на счету" в ИТ - типичные трансакционные данные.

Анатолий, в плане управления конфигурацией у программистов тоже все не очень гладко, современные инструменты, такие как chef и puppet хотя и решают проблему управления конфигурацией, но требуют много ненужной работы от инженеров. Можете ли вы порекомендовать, на что стоит обратить внимание и что будет трендом в ближайшем будущем? На первый взгляд кажется, что формальное описание компьютерной системы может быть собранно практически в автоматическом режиме, но беглое гугление ничего не дало.

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

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

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

Да, термин "конфигурационные данные" слух немного режет. Если я правильно уловил смысл, то для аналогичного мы используем "актуальные данные". "Поддержка актуальности" - всем понятна.

Разные инженеры имеют разный опыт оценки нужности работы по управлению конфигурацией: на девять "ненужных проверок" обязательно находится одна сработавшая проверка, которая спасает проект и цена предотвращённого провала закрывает все расходы на те девять несработавших проверок (замечу, что "двойная итальянская бухгалтерия" как управление конфигурацией тоже ведь избыточна! Она же "двойная" по определению! ;-) Если честно, то я не понял, что вы спрашиваете: какие тренды у управлении конфигурацией софта при разработке приложений? При сборке приложений в корпоративную систему из софта разных вендоров? CMDB в ITIL? Это всё разные вселенные -- но все они про управление конфигурацией, в том числе и софта. Последний тренд -- это связь систем архитектуры предприятия с конфигурационными базами данных службы поддержки IT-инфраструктуры. Но вы ведь не про это? У айтишников ведь самые разные системы, и поэтому самое разное управление конфигурацией.

Конфигурации бывают разные -- исторические, плановые, актуальные (то есть текущие). Данные по всем им -- это конфигурационные данные. Вчера на счету было 300 рублей, а сегодня 100 рублей. Это две конфигурации счёта: вчерашняя и сегодняшняя. Вчера насос был фирмы А, а сегодня поломался и к вечеру насос стал фирмы Б. Текущая конфигурация поменялась, но вчерашняя конфигурация от этого не перестала быть конфигурацией.

Я об этом классе систем http://en.wikipedia.org/wiki/Comparison_of_open_source_configuration_management_software, из них сейчас самые развивающиеся - это Chef (сейчас внедрена в Facebook) и Puppet. Моя идея в том, что все сервера и сетевое оборудование - достаточно детерменированные объекты и информацию о них можно собирать в автоматическом режиме. Обладая формальной онтологией можно было бы многие изменения конфигурации проверять не на тестовом стенде, а еще на этапе модели, что значительно бы ускорило внедрение этих изменений. Но мое знакомство с онтологиями крайне поверхностно, поэтому нагуглить ничего не удалось, а системы, приведенные выше, об этом даже и не "думают". Более того, сейчас во всех этих системах, например, порт, на который надо повесить какой-то сервис, это просто какая-то цифра, которую надо вписать в настройки самого сервиса, всех его клиентов и, например, файрвола. И именно об этом "дурном дублировании" я писал выше. Этого дублирование еще можно частично избежать, но, например, на вопрос "покажи мне все используемые порты", они в принципе, не могут ответить.

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

Вы очень точно подтверждаете основной тезис моего софта: в России и слова-то такого не знают, что уж говорить о лучших практиках, обмене опытом, профессиональном образовании, профессиональной ассоциации и т.д.

Спасибо, всё верно. Для меня с Распределение по-марксистски соразмерно Обмену, Потреблению и Производству (Рукописи 57 -58 гг), потому нюансы "перераспределения" или просто стыдливого дистрибутива пока не значимы. Один френд у меня каментах предлагает вообще рассматривать с помощью социальной гидрофизики ("давление", "потоки") все эти моменты. А идиотизм и отвращение к системе как-то "заложено" внутрь гос.управления-:) ЗЫ насчёт последних Чтений: Я кста удивился, что ни Христенко, ни участники первого коллоквиума вообще не вспомнили про австрийскую школу, хотя соотв. книг уже переиздано немало, а близость госуправления и промполитики не только теоретическая, но практически несётся самим Христенко

Первый коллоквиум мне оказался совсем неинтересен, я не пойму смысла доложенных интеллектуальных свершений и как эти интеллектуальные свершения чему-то там такому сильно помогли. Австрийскую школу впервые вдруг Пётр (после многих лет наших с ним споров) порекомендовал методологам читать в Светлогорске-2009 (вот как выяснилось, что методологи про неё не знают -- http://ailev.livejournal.com/717483.html, на следующий день им рассказали про существование праксиологии -- http://ailev.livejournal.com/717743.html, а ещё через день так вообще разрекламировали -- http://ailev.livejournal.com/717932.html). Так что до группы Христенко это тайное знание группы Щедровицкого ещё просто не докатилось.

А почему просто не использовать термин "состояние" ? "состояние системы" "состояние счёта" Звучит вполне и по-русски и по-разработчески.

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

Не согласен с тем, что у нас в России тема управления конфигурацией совсем неизвестна. Приведу пример из области проектирования (зданий, сооружений, атомных станций и т.д.). Регламентирующими документами (в частности ГОСТ 21.1101) определен порядок внесения изменений в проектную документацию. Т.е. описан и формализован порядок изменения конфигурации системы. В том числе четко выделены все типы данных ( справочные данные, конфигурационные данные, трансакционные данные). В частности проектная документация содержит в себе таблицу регистрации изменений, в которую как раз и вносятся данные об изменениях (дата изменения, что изменено и т.д.), выпускает лист регистрации изменений (описывающий причины и суть изменений). Даже при полном аннулировании какого-либо документа и его полной замены, предыдущая версия не удаляется из проекта (перечеркивается и храниться в составе проекта). Тоже относится и к эксплуатационным документам. Да термины используются другие, но суть и процесс тот же самый. Проблема в нашей стране не отсутствие подхода или учебников, а в недостаточной квалификации специалистов, вызванной разрывом инженерных поколений и в просто лени (т.е. люди просто не соблюдают регламенты и правила).

Тема известна, описанный вами процесс сугубо бумажен ("перечеркивается"), по факту если и соблюдается, то не как основная технология, а "задним числом" (для соблюдения соответствия стандарту, приведение отчётности в порядок). Квалификации специалистов не хватает, это правда. Ужас в том, что при отсутствии понятия конфигурации, каждый раз при выхватывании из проекта какого-то фрагмента люди с трудом отвечают на вопросы, что же это за фрагмент, какой его статус, чему в реальном мире он соответствует -- это я встречал и в атомной отрасли, и во многих других местах. На Западе так было лет тридцать назад: на лучших производствах всё налажено, а на худших примерно так же, как у нас в России сейчас. Но сегодня на Западе управление конфигурацией существует на уровне спинномозговых рефлексов, а у нас не слишком-то улучшилось -- соблюдение регламентов и правил (ввиду многолетнего полного безумия регламентов и правил и их несоответствия наблюдаемой жизни) не является на большинстве производств важным, ибо эти регламенты и правила писаны разными чиновниками, а не "кровью".

В каких-то контекстах "состояние" наверняка подойдет. Но в целом мне кажется, что "состояние системы" более узкое понятие, чем вкладываемый здесь смысл в "конфигурационные данные". То есть часть конфигурационных данных образует состояние системы, а часть - нет. Если грубо на пальцах - положение ручного тормоза входит в понятие "состояние автомобиля", а цвет бампера - вряд ли.