Как записать изменения сервера?

Таким образом, у всех нас, вероятно, была такая ситуация: вы отлаживали какую-то проблему, только чтобы понять, что она была вызвана изменением конфигурации, которое вы сделали шесть месяцев назад, и вы не можете вспомнить, почему вы это сделали. Итак, вы отмените это и исправите проблему, и теперь возвращается другая проблема. Ах да, сейчас я помню! Тогда вы исправите это правильно.

Это потому, что ты не делал надлежащие записи, дурак! Но какой хороший способ сделать это?

В разработке у нас есть множество программного обеспечения, предназначенного для того, чтобы помочь нам обнаруживать и отслеживать изменения. Контроль исходного кода, проверка кода и так далее. Каждое изменение отслеживается, каждое изменение требует комментария относительно того, что это такое. А типичные инженерные отделы нуждаются в хороших комментариях, чтобы через шесть месяцев, когда вы выяснили, почему вы так его сломали, вы можете использовать историческую функцию «вины» или двоичные сборки поиска, чтобы точно определить проблему. Эти инструменты являются очень эффективными инструментами коммуникации и историческими записями.

Но на сервере у нас есть 500 различных сервисов, каждый из которых имеет различные способы их настройки. И они не всегда имеют текстовый формат (рассмотрите возможность установки разрешений для папки или изменения местоположения файла подкачки), хотя они могут иметь текстовое представление.

В нашей среде мы проверяем, какие конфигурационные файлы мы можем использовать в Perforce, но их очень мало. Не могу точно проверить в БД Active Directory .. хотя, возможно, дамп, который мог бы быть разным ...

В прошлом я пытался вести журнал изменений вручную в нашей вики, но очень трудно поддерживать дисциплину, чтобы сделать это (я знаю, не очень хорошее оправдание, но это действительно сложно).

МОЙ ВОПРОС: Какие стратегии и инструменты вы используете, чтобы справиться с этой проблемой отслеживания изменений конфигурации на ваших серверах?

-- Обновить --

Примечание: я не ищу инструменты для создания общих заметок (я знаком с OneNote и т. Д.), А скорее автоматизированные инструменты, специально предназначенные для помощи в отслеживании изменений на сервере. Не существует комплексного инструмента для отслеживания изменений конфигурации сервера, но, возможно, есть некоторые для конкретных приложений, таких как объекты групповой политики.

Также меня очень интересуют конкретные стратегии, которые вы считаете полезными. «Мы делимся заметками в Sharepoint» довольно расплывчато. Как вы поддерживаете дисциплину? Какой формат вы используете для отслеживания ваших изменений? Как вы организуете свои изменения данных? Я бы очень хотел примеры и идеи.

На земле Linux люди преследуют несколько разных стратегий:

• Системы ограничения конфигурации , такие как cfengine или puppet или chef . Они похожи на Windows GPO. Дело в том, что вся конфигурация сервера намеренно задокументирована в одном месте, и вы знаете, с какой степенью детализации (серверная комната, группа, конкретный сервер) принята политика. Это не совсем спасет вас от того, «что, черт возьми, отличалось шесть месяцев назад?» но это позволяет просто обнулить конфигурацию сервера и перестроить ее с нуля. Вы можете поставить политики cfengine и puppet под контроль версий, чтобы ответить на этот вопрос.
• Контроль версий / и т . Д. Как правило, программы Linux хранят свою конфигурацию в одном месте / etc. Дерзкие начинают писать сценарии для включения / etc в систему контроля версий. Одна из таких известных мне программ - etckeeper :

Описание: хранить / etc в git, mercurial, bzr или darcs
 Программа etckeeper - это инструмент, позволяющий хранить / etc в git, mercurial,
 бзр или даркс репозиторий. Он подключается к APT для автоматической фиксации изменений
 сделано в / etc во время обновления пакета. Отслеживает метаданные файла той версии
 Системы управления обычно не поддерживают, но это важно для
 как разрешения / etc / shadow. Это довольно модульный и настраиваемый, в то время как
 также прост в использовании, если вы понимаете основы работы с версией
 контроль.

Одна из проблем в этой ситуации заключается в том, что на самом деле это сочетание бизнес-процесса и технологической проблемы. И это определенно больше, чем просто отслеживание изменений, внесенных администратором. Вам также необходимо следить за непредвиденными изменениями и хорошей координацией между администраторами или подразделениями, чтобы изменение в контроллере AD не нарушало настройку разрешений базы данных на каком-либо ведомственном сервере. Т.е. ваш вопрос - гигантская банка червей :)

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

Что касается технологической стороны, я могу говорить только о парнях из Unix / Linux, так как я не имею дело с Windows. Компания Reductive Labs внедрила Puppet для управления конфигурацией всех этих систем. Проще говоря, это система клиент / сервер, где каждый определяет конфигурацию машины на сервере, и клиент использует эти шансы очень часто (по умолчанию 30 минут). Кроме того, если есть какие-либо шансы для локально управляемых файлов, то они также возвращаются обратно в это время. Мы используем его для управления запущенными сервисами, настройками брандмауэра, авторизацией пользователей и т. Д.

Я также рекомендовал бы изучить что-то вроде TippingPoint. Это клиентская служба, которая следит за конфигурацией системы и отправляет уведомления об изменениях. Это делает нас, люди безопасности, наиболее счастливыми. Он в основном используется для отслеживания вредоносных или неопубликованных изменений.

Я был в 4 или 5 компаниях, теперь я действительно не помню.

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

Sharepoint / вики / Evernote / Штифты

• Sharepoint
  • стонать все, что вы хотите ... у него есть некоторые очень хорошие функции списка.
  • Списки IP-адресов
  • инвентарь
  • обслуживание учетных записей и использование
  • изменить журналы уведомлений
• Wiki
  • Как-к
  • долгосрочные списки задач
• Evernote
  • мой партнер и я использую это, чтобы поместить все, что мы не хотим в вики
  • больше практических советов, которые носят технический характер
  • записки, которые мы оба должны увидеть
  • задание учета за неделю
  • списки задач подрядчика
  • Evernote Clipper позволяет легко снимать скриншоты AD / настройки прав
  • доступно везде
• PINs
  • Хранилище паролей

Возможно, для некоторых из них есть лучшие инструменты, но это то, что мы используем:

• Отслеживайте изменения конфигурации и обновления / исправления для каждого сервера в частной вики
• Также храните инструкции и записи о проблемах / решениях в вики.
• Используйте Sharepoint или Google Docs, чтобы хранить авторитетные копии таких вещей, как статические списки IP
• использовать Subversion для отслеживания изменений в файлах конфигурации

Для Windows ознакомьтесь с серией Microsoft's System Center или другими конкурентами в области конфигурации и управления службами для этой платформы.

Изменения необходимо направлять через приличную процедуру управления изменениями, которая сама одобряет и регистрирует их, прежде чем они действительно будут сделаны. Это может быть 100% руководство для начинающих. С помощью некоторых из лучших интегрированных инструментов вы можете попросить инструмент внести реальные изменения и получить «автоматический» выход из него в базу данных центральной конфигурации, а не переходить «голыми руками» в консоль отдельного сервера, просматривая настройки вручную, чтобы Попробуй исправить проблему в ковбойском стиле.

У вас обязательно должен быть процесс управления изменениями, особенно если есть несколько человек, которые имеют возможность / доступ вносить изменения на уровне системы в вашей среде. Это также дает возможность руководству подписать потенциальные изменения, однако недостатком является задержка в процессе изменений, если вы не можете вносить изменения на лету.

Некоторые способы отслеживания изменений могут включать в себя проверку событий в вашей SEM (при условии, что у вас есть менеджер событий безопасности) или такие инструменты, как Nessus (с большим трудом можно провести аудит вашей среды, чтобы найти изменения).

Это более локализованный * nix-ответ. Я не нашел хороших инструментов для эмуляции под Windows.

Есть несколько способов реализовать это ... и поймать это, когда вы забудете.

Системы контроля версий, такие как subversion, git, cvs или RCS, являются хорошим способом отслеживания истории файла конфигурации. Если вы не хотите устанавливать систему контроля версий на свои производственные серверы, хранение каталогов файлов конфигурации локально или удаленно с использованием чего-то вроде rsnapshot даст вам большинство преимуществ RCS, но вы потеряете возможность аудита или выхода из коммита. журналы (хотя это можно обойти с комментариями внутри самих файлов).

Чтобы помочь вам вспомнить журнал изменений, автоматизированной отчетности изменений конфигурации через ночные, cron'ed натяжного пробег начало хорошее. После создания базы данных tripwire о текущем состоянии файлов любое изменение в них приведет к получению электронного письма во время следующего запуска. Вы будете продолжать получать это письмо до тех пор, пока база данных не будет обновлена, таким образом, «сбрасывая» tripwire.

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

Вики может быть полезна для документирования текущей настройки, но ее легко устареть - и, кажется, требуется больше усилий для обновления IMO.

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

Я думаю, что это просто вопрос хорошей политики, инструментов с низким уровнем барьера и дисциплины.

Мы создали что-то домашнее, чтобы отслеживать изменения в нашей среде; в этом нет ничего сверхсложного, и он работает довольно хорошо.

• Политика самоконтроля - это настройка, согласно которой любое изменение, которое, по вашей оценке, отклоняется от стандартной настройки или может вызвать проблемы, должно быть задокументировано в системе изменений.
  • Противоположная сторона этой «монеты» - если вы устраняете проблему, ищите последние или связанные записи в журнале изменений.
• Войдите в систему и выберите сервер, сервис или аппаратный компонент, который вы меняете
  • компоненты ранее вводились в одну и ту же систему с базовой «демографической» информацией (местонахождение, поставщик, серийный номер, ответственный отдел)
• Выберите из выпадающего списка основных категорий
  • Незапланированное время простоя
  • Заделка
  • Обслуживание оборудования
  • Установка программы
• Подробно опишите, что вы сделали, увидели, наблюдали
• копия отправляется ответственному лицу и сохраняется в виде XML-файлов, которые индексируются поисковым устройством.
• прибыль

Как я уже сказал, ничего особенного. Он использует PERL CGI (был написан миллиард лет назад) и Google Search Appliance для индексации.

Недостатки:

• С группами служб сложно работать, например, вы просто добавили один и тот же патч для всех 25 ваших контроллеров домена; у нас нет группы «Контроллер домена», поэтому мы должны вручную выбрать их все
• Не интегрируется с отчетами об ошибках оборудования, программного обеспечения или журнала событий, что помогает при устранении неполадок
• соответственно, ручной ввод данных для всех «демографических» данных, как я уже говорил выше

Во всяком случае, если после всего этого вас заинтересует код, дайте мне знать, и я, вероятно, смогу достать его, чтобы поделиться.

Как уже говорилось, это часто является культурной проблемой - в конце концов, некоторые магазины разработчиков уже не беспокоятся о комментариях (самодокументируемый код - модное модное слово сегодня!), А некоторые используют систему контроля версий как священный грааль исторических записей. Очевидно, они не идеальны.

Таким образом, единственный верный способ исправить это - сделать это культурным решением. Убедитесь, что все причины изменений зарегистрированы в системе отслеживания ошибок (или базе знаний, или вики), и убедитесь, что все изменения зарегистрированы в системе управления изменениями.

У нас есть клиенты службы экстренной помощи, каждое изменение, которое происходит с их системой, регистрируется, и каждый раз, когда мы входим в их систему, мы должны регистрировать это. Для некоторых из них мы должны сначала позвонить за разрешением (и я думаю, они тоже это регистрируют!). Каждое изменение регистрируется, и изменение системы клиента без регистрации будет дисциплинарным нарушением.

Звучит обременительно, но это не так. Вы быстро получаете привычку добавлять себя в журнал доступа и журнал изменений - это не хуже, чем писать комментарий при проверке изменения кода.

Я рекомендую использовать багтрекер в качестве журнала контроля изменений, поскольку его обычно легко обновлять (я использую Mantis).

Если вы ищете «корпоративное решение» (т. Е. У вас больше денег, чем у бога, и вы хотите иметь действительно крутой инструмент), то инструмент, который я использовал для поддержки и обеспечения работы на месте, делает это одной из его многочисленных функций.

Не знаю, какова базовая цена, но до того, как HP купила Opsware, она составляла ~ 350 000 долларов США (без поддержки, и поверьте мне - вы нуждались в поддержке, когда я начинал с Opsware).

Несколько клиентов, которые у нас были, когда я работал там, использовали конфигурацию приложения и функции снимков в сочетании с Tripwire .

Конечно, если у вас нет бюджета - это плохой выбор ™ :)

И, между прочим, объявление, которое появилось в верхней части этой страницы для меня, когда я перезагрузил его, было для spiceworks . Выглядит очень похоже на HPSA :)

Если все, что вы хотите сделать, это отслеживать изменения, а не управлять всем процессом (например, через Chef или Puppet), просто rsyncваш etcкаталог (где бы он ни находился) в локальном git-репо.

for HOST in alpha bravo charlie delta ...; do

    rsync -avz --exclude-from=exclusions -e ssh admin@$HOST:/opt/local/etc/ ./$HOST

done

Вы можете, конечно, добавлять другие источники по мере необходимости.