В таком случае, это утверждение в общем случае неверно.
Это ложное утверждение.
Вы ничего не знаете про мою систему (что видно из ошибочного суждения "требует каждый раз изменения всего конфига"), поэтому ваше суждение необосновано.
Про то, что Вы написали при обсуждении, у меня сложилось впечатление, что ваша работа "носить воду в ступе".
Есть одна система многолетней эксплуатации, вы предлагаете другую. Что из этого вытекает? (Оставлю это Вам на размышление.)
"жизненного цикла" эксплуатации системы
Да ежедневно и ежечасно только и вносят изменения в конфиги из "нехватки" ресурсов.
Подражая Вам могу изречь следующее — у Вас плохая система, которая требует каждый раз изменения всего конфига. Теперь понятно, почему Вы постоянно боретесь с "ветряной мельницей"
С точки зрения системы — это именно именно велосипед. При этом — велосипеда, повышающего вероятность отказа системы!
Сравнили тоже версионность кода и конфига! Конфиг в течении жизненного цикла меняется не существенно. Изменения конфига редкая операция и, как правило, меняются какие то значения атрибутов, добавляются или удаляются какие строки.
Изменения исходника может затронуть весь файл. И таких файлов тьма тьмущая. И таких изменений может быть каждый день, несколько раз на дню.
Отключение одного узла системы, даже на длительное время — на работоспособности системы не отражается. Не сделали резервной копии и не сделали — нет трагедии.
готовое решение или нет, для системы это "изобретение велосипеда", который "в нужный момент" может оказаться не доступен — сломался, обслуживается, недоступен и т.д.
При передаче изменений, требующих внесения изменения в конфиг — есть стандартная рекомендация, сделать копию файла. Но если по каким либо причинам она не будет сделана, ни какой трагедии не произойдет. Система в целом останется в рабочем состоянии.
Автоматизировать можно все! Лететь на Марс можно хоть сейчас — только сейчас это очень дорого стоить!
Есть экономическая целесообразность. Если текущий процесс не требует затрат, зачем "изобретать велосипед" и вносить в системы еще один узел, который требует опять же какого резервирования, сам подвержен вероятным сбоям и за этим узлом кому то тоже нужно приглядывать?
Вам остается только поверить мне на слово. Архитектура система разработана так, что хранить копии конфигурационных файлов не нужно — восстановить предыдущую конфигурацию элементарно.
Так же как и ваше система версионности, создается копия файла. При желании могут вставляется соответствующий комментарий. Это не существенный вопрос и выходит за рамки темы.
Сменный персонал должен иметь возможность внести изменения в конфиг в случае какой то аварии, требующей вмешательства и то, если ему дали такую рекомендацию. ВСЕ! На этом его функции заканчиваются.
Да вас вообще даже близко подпускать к построению архитектуры нельзя!
Это не Вам судить.
В системе заложены функции самовосстановления после сбоя, система сама справляется со сбойными ситуациями и восстанавливает свою работу, когда это становиться возможным. Система сама принимает решения по переключению на дублирующие узлы.
Так что работает НАДЕЖНО и не требует постоянного "присмотра"
И совершенно не важно, как Вы доставляете конфигурацию до узла системы, Вы ее все равно будете корректировать в ручную — конфигурация каждого узла уникальна.
Давно ответил, в любом текстовом редакторе. Да, меняют руками. Я "за" более простые схемы эксплуатации, если можно не использовать в эксплуатации дополнительное ПО, то значит его НЕ НУЖНО использовать. Это понижает требования к сменному персоналу. В критической ситуации какой сотрудник будет ее устранять предсказать невозможно. У сменного персонала сотни разных систем в зоне ответственности.
Это ложное утверждение.
Это ложное утверждение.
Про то, что Вы написали при обсуждении, у меня сложилось впечатление, что ваша работа "носить воду в ступе".
Это ложное утверждение
Есть одна система многолетней эксплуатации, вы предлагаете другую. Что из этого вытекает? (Оставлю это Вам на размышление.)
"жизненного цикла" эксплуатации системы
Да ежедневно и ежечасно только и вносят изменения в конфиги из "нехватки" ресурсов.
Подражая Вам могу изречь следующее — у Вас плохая система, которая требует каждый раз изменения всего конфига. Теперь понятно, почему Вы постоянно боретесь с "ветряной мельницей"
Вот это уже с вашей стороны перебор.
С точки зрения системы — это именно именно велосипед. При этом — велосипеда, повышающего вероятность отказа системы!
Сравнили тоже версионность кода и конфига! Конфиг в течении жизненного цикла меняется не существенно. Изменения конфига редкая операция и, как правило, меняются какие то значения атрибутов, добавляются или удаляются какие строки.
Изменения исходника может затронуть весь файл. И таких файлов тьма тьмущая. И таких изменений может быть каждый день, несколько раз на дню.
жаль. что тут нет смайликов.
Отключение одного узла системы, даже на длительное время — на работоспособности системы не отражается. Не сделали резервной копии и не сделали — нет трагедии.
готовое решение или нет, для системы это "изобретение велосипеда", который "в нужный момент" может оказаться не доступен — сломался, обслуживается, недоступен и т.д.
При передаче изменений, требующих внесения изменения в конфиг — есть стандартная рекомендация, сделать копию файла. Но если по каким либо причинам она не будет сделана, ни какой трагедии не произойдет. Система в целом останется в рабочем состоянии.
Автоматизировать можно все! Лететь на Марс можно хоть сейчас — только сейчас это очень дорого стоить!
Есть экономическая целесообразность. Если текущий процесс не требует затрат, зачем "изобретать велосипед" и вносить в системы еще один узел, который требует опять же какого резервирования, сам подвержен вероятным сбоям и за этим узлом кому то тоже нужно приглядывать?
Вам остается только поверить мне на слово. Архитектура система разработана так, что хранить копии конфигурационных файлов не нужно — восстановить предыдущую конфигурацию элементарно.
Вы ушли от темы статьи.
При плановых изменениях все прописано — что делать, как откатывать. С этим нет проблем.
Так же как и ваше система версионности, создается копия файла. При желании могут вставляется соответствующий комментарий. Это не существенный вопрос и выходит за рамки темы.
Сменный персонал должен иметь возможность внести изменения в конфиг в случае какой то аварии, требующей вмешательства и то, если ему дали такую рекомендацию. ВСЕ! На этом его функции заканчиваются.
С версионностью нет проблем
Сменный персонал не лазит в конфиги от скуки
Это не Вам судить.
В системе заложены функции самовосстановления после сбоя, система сама справляется со сбойными ситуациями и восстанавливает свою работу, когда это становиться возможным. Система сама принимает решения по переключению на дублирующие узлы.
Так что работает НАДЕЖНО и не требует постоянного "присмотра"
И совершенно не важно, как Вы доставляете конфигурацию до узла системы, Вы ее все равно будете корректировать в ручную — конфигурация каждого узла уникальна.
работает
Давно ответил, в любом текстовом редакторе. Да, меняют руками. Я "за" более простые схемы эксплуатации, если можно не использовать в эксплуатации дополнительное ПО, то значит его НЕ НУЖНО использовать. Это понижает требования к сменному персоналу. В критической ситуации какой сотрудник будет ее устранять предсказать невозможно. У сменного персонала сотни разных систем в зоне ответственности.
Изменения, как правило не значительные, добавить строчку, удалить строчку или изменить значение атрибута.