Как профессиональный системный администратор, какие элементы конфигурации вы считаете важным отслеживать для правильной настройки или управления изменениями?
Например, в Windows вы отслеживаете изменения реестра в дополнение к аппаратному или программному обеспечению? В Linux вы различаете файлы конфигурации?
РЕДАКТИРОВАТЬ: Для пояснения я ищу, что конкретно отслеживать (или не отслеживать) - если вы хотите порекомендовать инструменты к тому же к элементам, которые, по вашему мнению, стоит отслеживать, продолжайте.
С точки зрения приложения очень важно задокументировать
Примечание. В ответ на комментарий романд в вопросе я знаю, что это не совсем один элемент, но в данном случае я считаю, что весь документ является одним элементом.
[В первую очередь предвзятость Unix / Linux, я не работаю в системах Windows :-)]
Все, что после изменения изменяет состояние работающей системы, необходимо отслеживать. Конфигурация должна храниться в репозитории, который поддерживает полную историю изменений, например Git или Subversion, и ее необходимо развертывать автоматически, например с помощью Шеф-повар Opscode или Кукла Reductive Labs '.
Несколько примеров элементов, изменяющих состояние системы:
Такое отслеживание необходимо осуществлять с помощью автоматизированных инструментов, обеспечивающих достаточную регистрацию для аудита изменений. История репозитория программного обеспечения покажет, эм, историю изменений в файлах конфигурации, хранящихся в указанном репозитории. В инструментах декларативной конфигурации, таких как Chef или Puppet, каждый файл конфигурации представляет собой набор ресурсов, таких как пользователи, пакеты или службы, и история репозитория будет указывать изменения в них.
Для Windows вам не нужно «отслеживать» уровни исправлений ОС, так как это можно запросить в любое время через WMI. Если вы следуете управлению изменениями, вы можете выполнить глобальный запрос до и после изменения, чтобы проверить результаты исправления ОС. (убедитесь, что установлен поставщик MSI)
Обновления драйверов должны отслеживаться (wmi можно использовать для их запроса, но не стоит пытаться поймать их все) Обновления программного обеспечения должны храниться в CMDB, но (за исключением первоначального) должны поступать из управления изменениями, если вы действительно этого хотите для отслеживания изменений реестра установите групповую политику, разрешающую доступ к файлам и объектам, и выберите ключи для аудита (http://support.microsoft.com/kb/324739). Это не для CMDB, но позволит вам отслеживать, кто вносит изменения.
Вот что люди обычно хотят отслеживать в CMDB, и почему иногда это не очень хорошая идея, так что же должно быть в CMDB. Ответ в зависимости от обстоятельств. CMDB, определенная ITIL, может или не может заботиться о конфигурациях машины, если эта конкретная конфигурация машины не относится к службе. ACMDB может также содержать решение для отслеживания активов (для таких вещей, как расположение конфигурации оборудования и информация о гарантии), но это больше касается отношений конкретного элемента конфигурации с другим CI. Отношения включают в себя такие вещи, как «отвечает за», «связан с», «зависит от» и (более сложно, но во многих случаях более важно) «требуется для уровня SLA_». Короче говоря, запишите, что требуется для воссоздания службы, а не сервера.
Например. Если бы электронная почта была услугой, я бы перечислил такие вещи, как:
Аппаратное обеспечение: 64-битный ЦП, 3 ГБ оперативной памяти (на основе количества пользователей в @today) 7 ГБ пространства для установки сервера, 100 ГБ хранилища для баз данных обмена и восстановления (на основе использования на @today), DVD-ROM.
Программное обеспечение: Server 2003 R2, Exchange 2007 SP2, драйверы MPIO для SAN
и т.д...
CMDB обычно не используются администратором сервера. Администраторы будут намного счастливее с решением для управления активами.
Уровень исправления ОС. Что могло означать многое. В идеале вы отслеживаете, какие отдельные исправления есть на каких машинах, в матрице. Версия для бедняков - это «дата последнего обновления» для каждого сервера (что предполагает, что вы каждый раз просто загружаете все обновления оптом).
Для UNIX / Linux я делю файлы конфигурации на две группы: те, которые предоставляются ОС, и те, которые являются частью наших пользовательских приложений.
Все файлы конфигурации приложения хранятся в нашем исходном репозитории. У меня есть разные стандартные копии для каждой установки (dev, QA, production, pre-production, demo ...). Когда мы определяем, что нам нужно внести изменение в любой из них, изменение сначала происходит в исходной копии репо, а затем развертывается на необходимых серверах. Мы также открываем соответствующий запрос на изменение в системе отслеживания проблем.
Для файлов конфигурации типа ОС мы можем иметь или не иметь их в исходном репо. Если да, то воспользуемся описанным выше процессом. Если нет, мы поместим их в репо, если количество изменений достигнет определенного произвольного порога. А пока мы по крайней мере открываем тикет в системе отслеживания проблем, чтобы отслеживать это изменение.
Кроме того, отличной особенностью нашего трекера ошибок является возможность индексировать коммиты исходного репо. Он очень хорошо связывает ваши билеты с изменениями конфигурации.
Для сетевых устройств, таких как коммутаторы Cisco, мне нравится собирать и отслеживать их запуск и рабочие конфигурации в системе контроля версий. Если возможно, я сохраняю имя пользователя, который также редактировал.
Обычно я использую Perl-скрипт, если у меня нет возможности автоматически отслеживать журналы и запускать сбор конфигурации из данных журнала.
Для сетевых устройств идеально подходит RANCID (автоматический сборщик конфигурации).
Для серверов комбинация чего-то вроде etckeeper (сохранение / etc / в VCS) и марионетки (с его конфигурацией в VCS).
Windows: