У кого-либо есть хорошие примеры runbooks, который они используют при внесении Производственных изменений?

Что я делаю:

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

Большая часть конфигурации была реализована вручную в системе тестирования (часто образ виртуальной машины или просто экземпляр EC2), и затем рецепт конфигурации, записанный для покрытия всех различных компонентов изменений. Обновление рабочего процесса среды проходит примерно так:

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

Режим работы шеф-повара состоит в том, чтобы перестать работать, если существует проблема, выполняющая клиент, как то, если пакет не существует, или шаблонный файл не найден, или много других проблем. Устраните проблему, документ в билете, и затем повторно выполните клиент.

Человек с бизнес-требованием для изменения проверяет, что это было успешно, и они закрывают билет.

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

Я предпочитаю сценарии с комментариями и печатью.
У них есть двойное преимущество документирования и автоматизации.

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

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

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

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

Вот является старая Microsoft Technet SQL Server runbook страницей для ловли универсальных идей.

Для действительно критических и чувствительных изменений у меня обычно будет текстовый файл с фактическими командами, которые я буду использовать с #comments, объясняющим, что продолжается. Тем путем я могу cut-n-paste их в терминал быстро.

Я был бы второй основная идея behing сообщение jtimberman, при этом марионетка была бы моим предпочтительным инструментом.