Итак, у всех нас, вероятно, была такая ситуация: вы отлаживаете какую-то проблему только для того, чтобы понять, что она вызвана изменением конфигурации, которое вы внесли шесть месяцев назад, и вы не можете вспомнить, почему вы это сделали. Итак, вы отменяете это и устраняете проблему, и теперь возвращается другая проблема. Ах да, теперь я вспомнил! Тогда вы исправите это как следует.
Это потому, что ты не сделал должных записей, дурак! Но как это сделать?
В области разработки у нас есть множество программного обеспечения, которое помогает нам обнаруживать и отслеживать изменения. Контроль версий, проверка кода и т. Д. Каждое изменение отслеживается, каждое изменение требует комментария относительно того, что это такое. И типичные инженерные отделы требуют хороших комментариев, чтобы через шесть месяцев, когда вы выясняете, почему вы это сломали, вы могли использовать историческую функцию «обвинения» или сборки двоичного поиска, чтобы точно определить проблему. Эти инструменты являются очень эффективными инструментами коммуникации и историческими записями.
Но в serverland у нас есть 500 различных сервисов, и все они имеют разные способы их настройки. И они не всегда имеют текстовый формат (рассмотрите возможность установки разрешений для папки или изменения местоположения файла подкачки), хотя они могут иметь текстовое представление.
В нашей среде мы проверяем, какие файлы конфигурации мы можем использовать в Perforce, но их очень мало. Не могу точно проверить в базе данных Active Directory ... хотя, возможно, дамп, который можно было бы различить ...
Раньше я пытался вести журнал изменений вручную в нашей вики, но очень сложно поддерживать дисциплину, чтобы делать это (я знаю, не очень хорошее оправдание, но это действительно сложно).
МОЙ ВОПРОС: Какие стратегии и инструменты вы используете, чтобы справиться с этой проблемой отслеживания изменений конфигурации ваших серверов?
-- Обновить --
Примечание. Мне нужны не инструменты для создания общих заметок (я знаком с OneNote и т. Д.), А автоматизированные инструменты, специально предназначенные для отслеживания изменений на сервере. Нет всеобъемлющего инструмента для отслеживания изменений конфигурации сервера, но, возможно, есть некоторые для конкретных приложений, таких как GPO.
Также меня очень интересует конкретные стратегии что вы сочли полезным. «Мы делимся заметками в Sharepoint» довольно расплывчато. Как вы поддерживаете дисциплину? Какой формат вы используете для отслеживания изменений? Как вы организуете свои данные об изменениях? Мне очень нужны примеры, а также идеи.
В мире Linux люди придерживаются нескольких разных стратегий:
Description: store /etc in git, mercurial, bzr or darcs The etckeeper program is a tool to let /etc be stored in a git, mercurial, bzr or darcs repository. It hooks into APT to automatically commit changes made to /etc during package upgrades. It tracks file metadata that version control systems do not normally support, but that is important for /etc, such as the permissions of /etc/shadow. It's quite modular and configurable, while also being simple to use if you understand the basics of working with version control.
Одна из проблем в этой ситуации заключается в том, что на самом деле это проблема комбинации бизнес-процесса и технологии. И это определенно больше, чем просто отслеживание изменений, внесенных администратором. Вам также необходимо следить за неожиданными изменениями и хорошей координацией между администраторами или подразделениями, чтобы изменение на контроллере AD не нарушало настройки разрешений базы данных на каком-либо сервере отдела. То есть ваш вопрос - гигантская банка червяков :)
В моей организации мы около года внедряем процессы и системы для решения этой проблемы. Для бизнес-процессов мы сформировали команду по управлению изменениями. Согласно СОП все изменения в производственной среде согласовываются через них. Они компилируют все изменения вместе с областью действия, затронутыми системами, затронутыми службами и т. Д. Обеспечьте хорошее документирование изменений, а также планы развертывания и отката. Организуйте еженедельные (открытые) собрания, чтобы обсудить предстоящие изменения среды, а затем рассылать электронные письма с подробным описанием всех этих изменений. Конечная цель этого процесса состоит в том, чтобы, по сути, все в ИТ знали обо всем остальном, что происходит. Это помогает решить проблему, например, с установкой системным администратором патча ядра и перезагрузкой системы, которая отключит базу данных таймера.
Что касается технологической стороны, я могу говорить только о парнях из Unix / Linux, поскольку я не занимаюсь Windows. Компания Reductive Labs развернула Puppet для управления конфигурацией всех этих систем. Проще говоря, это система клиент / сервер, в которой на сервере определяется конфигурация машины, и клиент время от времени использует эти возможности (по умолчанию 30 минут). Кроме того, если есть какие-либо возможности для локальных управляемых файлов, они также возвращаются обратно в это время. Мы используем его для управления запущенными службами, конфигурациями брандмауэра, авторизацией пользователей и т. Д.
Я бы также порекомендовал изучить что-нибудь вроде TippingPoint. Это клиентская служба, которая следит за конфигурацией системы и отправляет предупреждения об изменениях. Это очень радует нас, сотрудников службы безопасности. Он в основном используется для отслеживания вредоносных или неопубликованных изменений.
Я был в 4 или 5 компаниях, сейчас не особо помню.
У всех была эта проблема. Никто из нас не решил ее на 100 процентов, но в компании, в которой я работаю, у нас есть то, что я считаю лучшей стратегией на сегодняшний день.
Sharepoint / Wiki / Evernote / PIN-коды
Для некоторых из них, вероятно, есть инструменты получше, но вот что мы используем:
Что касается Windows, ознакомьтесь с серией Microsofts System Center или любым другим конкурентом по настройке и управлению услугами для этой платформы.
Изменения необходимо направить через приличную процедуру управления изменениями, которая сама по себе утверждает и регистрирует их до того, как они действительно будут сделаны. Для начинающих это может быть 100% руководство. С помощью некоторых из лучших интегрированных инструментов вы можете попросить инструмент внести фактические изменения и получить "автоматический" выход из него в центральную базу данных конфигурации, вместо того, чтобы идти голыми руками в консоль отдельного сервера, копаясь в настройках вручную, чтобы попробуй исправить проблему в ковбойском стиле.
У вас обязательно должен быть процесс управления изменениями, особенно если есть несколько человек, которые имеют возможность / доступ для внесения изменений на системном уровне в вашу среду. Это также дает возможность руководству подписаться на возможные изменения, однако, с другой стороны, это вызывает задержку в процессе изменения, если вы не можете вносить изменения на лету.
Некоторые способы отслеживания изменений могут включать в себя проверку событий в вашем SEM (при условии, что у вас есть диспетчер событий безопасности) или такие инструменты, как Nessus (с большим трудом можно проверить вашу среду, чтобы найти изменения).
Это более локализованный ответ, основанный на * nix. Я не нашел хороших инструментов для его эмуляции под Windows.
Есть несколько способов реализовать это ... и поймать это, когда вы забудете.
Системы контроля версий, такие как subversion, git, cvs или RCS, - хороший способ отслеживать историю файла конфигурации. Если вы не хотите устанавливать систему контроля версий на производственных серверах, сохраните каталоги файлов конфигурации локально или удаленно, используя что-то вроде rsnapshot даст вам большинство преимуществ RCS, но вы потеряете возможность аудита или выхода из журналов фиксации (хотя это можно обойти с помощью комментариев внутри самих файлов).
Чтобы помочь вам не забыть регистрировать изменения, автоматические отчеты об изменениях конфигурации через ночные часы cron'ed растяжка бег - хорошее начало. После создания базы данных tripwire о текущем состоянии файлов любое изменение в них приведет к отправке электронного письма во время следующего запуска. Вы будете получать это письмо до тех пор, пока база данных не будет обновлена, что приведет к "сбросу" tripwire.
Я бы использовал систему отслеживания проблем, такую как flyspray (подойдет любой, но мне нравится flyspray для вещей, не связанных с программированием). Прежде чем кто-либо коснется конфигурации, необходимо зарегистрировать улучшение / проблему. Когда вы его исправляете / внедряете, изменения вносятся в заявку.
Вики-сайт может быть хорошим документом для текущей настройки, но он легко устареет - и, похоже, требуется больше усилий для обновления IMO.
Вы не найдете что-то автоматизированное для этого - хотя вы, вероятно, могли бы настроить его так, чтобы изменения в определенных файлах конфигурации автоматически отправлялись по электронной почте в средство отслеживания проблем, если хотите.
Я думаю, это просто вопрос хорошей политики, инструментов с низким уровнем барьеров и дисциплины.
Мы создали что-то самодельное, чтобы отслеживать изменения в нашей среде; в нем нет ничего сверхсложного, и он работает довольно хорошо.
Как я уже сказал, ничего особенного. Он использует PERL CGI (был написан миллиард лет назад) и Google Search Appliance для индексирования.
Недостатки:
В любом случае, если после всего этого вам будет интересен код, дайте мне знать, и я, вероятно, смогу его взять и поделиться.
Как уже было сказано, это часто является культурной проблемой - в конце концов, некоторые компании-разработчики больше не беспокоятся о комментариях (самодокументирующий код - модное модное слово сегодня!), А некоторые используют систему контроля версий как святой Грааль исторических записей. Очевидно, это не идеально.
Итак, единственный верный способ исправить это - сделать это культурным решением. Убедитесь, что все причины изменения зарегистрированы в системе отслеживания ошибок (или в базе знаний, или в вики), и убедитесь, что все изменения регистрируются в системе контроля изменений.
У нас есть клиенты службы экстренной помощи, каждое изменение, которое происходит в их системе, регистрируется, и каждый раз, когда мы входим в их систему, мы должны регистрировать это. Некоторым из них нужно сначала позвонить, чтобы получить разрешение (и я думаю, они это тоже регистрируют!). Каждые изменение регистрируется, и изменение клиентской системы без его регистрации будет считаться дисциплинарным нарушением.
Звучит обременительно, но это не так. Вы быстро приобретаете привычку добавлять себя в журнал доступа и журнал изменений - это не хуже, чем писать комментарий при проверке изменения кода.
Я рекомендую программу отслеживания ошибок в качестве журнала причин контроля изменений, поскольку их обычно легко обновлять (я использую Mantis).
Если вы ищете «корпоративное решение» (т. Е. У вас больше денег, чем у Бога, и вы хотите иметь действительно крутой инструмент), инструмент, который я использовал для поддержки и обеспечения работы на месте, делает это как одну из своих многочисленных функций.
Не знаю, какова базовая цена, но до того, как HP купила Opsware, она составляла ~ 350 000 долларов США (без поддержки, и поверьте мне - когда я начинал с Opsware, вам нужна была поддержка).
Некоторые клиенты, которые у нас были, пока я там работал, использовали функции конфигурации приложения и моментальных снимков в сочетании с Tripwire.
Конечно, если у вас нет бюджета - это плохой выбор ™ :)
И, черт возьми, реклама, которая появилась в верхней части этой страницы для меня, когда я ее перезагрузила, была для пряности. Выглядит очень похоже на 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
Вы, конечно, можете добавлять другие источники по мере необходимости.