У нас есть достаточно хорошая документация для нашей среды (в формате AsciiDoc), которая недавно позволила другому человеку воссоздать всю установку с нуля менее чем за 30 минут.
Однако я заметил, что после первоначальной настройки легко случаются небольшие изменения, вносимые в систему (скажем: inetd отключается, мой сервер IMAP прослушивает дополнительный порт для соединений ManageSieve, в конфигурацию exim добавляется новый маршрутизатор). не попадают в документацию сразу (если вообще).
Моя идея заключалась в том, чтобы избежать этой проблемы путем (частично?) Создания документации из файлов конфигурации и комментариев к ним - одним из способов реализации этого может быть размещение /etc и /usr/local/etc в какую-нибудь систему управления исходным кодом (скажем, - git), а затем запустите сценарий, который восстанавливает документацию при каждой фиксации. Однако я не уверен, будет ли это чрезмерным и / или слишком сложным для правильного выполнения (в конце концов, мне нужны не полные копии исходных файлов в моей документации, а просто различия).
Как другие люди избегают устаревания документации сервера - есть ли хороший способ автоматически синхронизировать их, или у вас просто есть дисциплина, чтобы обновлять документацию одновременно с изменением системы?
Если вы администрируете только одну или две небольшие системы, установка большой системы управления конфигурацией, такой как puppet или chef, кажется излишним. (Хотя, если вы планируете иметь больше систем в будущем, сделайте это сейчас!)
Для такой небольшой настройки я бы рекомендовал использовать что-то вроде etckeeper, программа, которая ставит /etc в git репозиторий и предоставляет несколько полезных функций, таких как автоматическая фиксация при установке, обновлении или удалении пакета.
Вы никогда не откажетесь от какой-то документации, но, как вы намекнули, есть системы, которые можно интегрировать в ваш процесс изменений, чтобы охватить большую часть из них.
Таким образом, документация нижнего уровня, которую мы все обычно пропускаем (или не беспокоимся), обеспечивается путем хранения этой информации о развертывании в элементах конфигурации или коде как части системы, в которую вы вносите изменения. Это также дает дополнительный бонус - процесс становится более повторяемым в будущем.
Внешняя документация все еще нуждается в обновлении, но она становится очень высокоуровневой с указателями на «развернуть x» или «развернуть y» вместо длинных списков команд / файлов. Это дополнительно снижает частоту и упрощает внесение изменений в документацию, что также означает, что это с большей вероятностью будет выполнено.
Также перед тем, как пойти домой, заварить марионетку, наверное, кто-то уже написано что-то управлять тем, что вы хотите.
Вам просто нужно обновлять документацию каждый раз, когда вы вносите изменения в систему. AKA Change Management.
Тот факт, что большинство компаний внедряют управление изменениями таким смехотворным образом, что делает его хуже, чем ничего, не должен умалять полезности базовой концепции или мешать вам делать ее правильно.
Я использовал html или какая-то вики, чтобы отслеживать все мои конфиги. Сейчас я работаю в магазине Windows с (содрогаться) SharePoint, поэтому теперь я использую «шаблоны» документов Word, которые я создал, чтобы отслеживать каждую имеющуюся у меня систему и каждое изменение конфигурации, которое я вношу, что не так плохо, как кажется, учитывая, что многие системы являются просто копиями других. все это можно объединить в один документ. (И я храню локальные копии всех своих материалов, документирующих мой жесткий диск, на самом деле организованные разумным образом, в дополнение к тому, что помещаю их в неорганизованную кучу, которая является чьим-либо сайтом SharePoint.)
Самая большая проблема - найти время для документирования, что я делаю, добавляя время на документацию как часть времени для внесения изменений. Так что на самом деле не так уж и сложно, особенно если вы немного придурок и не против сказать людям отвалить и ждать в очереди, потому что вы сейчас слишком заняты для их проблемы.