Мне всегда интересно, как ИТ-отделы подходят к планированию изменений в производстве. Обычно мы используем рабочие книги для описания ключевых шагов изменения, а также планов отката. Мне интересно узнать, можем ли мы поучиться у других и как лучше всего документировать рабочие книги.
решение1
Я предпочитаю сценарии с комментариями и распечатками.
Они имеют двойное преимущество документирования и автоматизации.
Но если использовать более целостный подход, то обычно приходится отслеживать множество вещей,
а сценарии предназначены только для тех действий, которые необходимо выполнять в определенной последовательности.
Когда требуется много заметок, я предпочитаю локально размещенную Wiki (личныйилигруппа).
Его можно использовать для
- ссылайтесь на свои инструменты и пишите краткие заметки
- перечислить контакты и ссылки на эскалацию
- документируйте экстренные действия на основе ключевых слов
- места резервного копирования и последовательности восстановления
- размещайте доступную для поиска запись регулярных требований и решений; чтобы люди обращались к вам после того, как они это проверят
Но просто сохраните это место в тайне — вы же не хотите, чтобы данные оказались недоступны в чрезвычайной ситуации.
Вот старыйMicrosoft Technet SQL Server runbookстраница для сбора общих идей.
решение2
Что я делаю:
Все конфигурации сервера, которые необходимо изменить по сравнению с базовой версией установленной ОС, управляются Chef и хранятся в модулях (называемых кулинарными книгами), которые затем сохраняются в системе контроля версий через Git.
Большая часть конфигурации была сделана вручную на тестовой системе (часто образ VM или просто экземпляр EC2), а затем рецепт конфигурации был написан для покрытия всех различных компонентов изменений. Рабочий процесс обновления среды выглядит примерно так:
- Создайте тикет в соответствующей системе о необходимости внесения изменений.
- Задокументируйте все причины и следствия изменений.
- Отредактируйте рецепт(ы) конфигурации, шаблоны, файлы и т. д., необходимые для внесения изменений в целевую систему или системы.
- Зафиксируйте изменения в локальном репозитории и отправьте на главный сервер контроля версий.
- Обновите заявку для экспертной оценки изменений.
- Изменения подписываются, и они развертываются на сервере Chef, чтобы он знал об обновленных битах.
- Запустите Chef вручную на клиентах или позвольте ему запуститься автоматически в зависимости от требований изменения. (Я бы не стал запускать его вручную более чем на полудюжине систем).
Режим работы Chef заключается в сбое, если возникает проблема с запуском клиента, например, если пакет не существует, или файл шаблона не найден, или много других проблем. Исправьте проблему, задокументируйте в тикете, а затем перезапустите клиент.
Лицо, ответственное за бизнес-требования к изменению, проверяет, что оно прошло успешно, и закрывает тикет.
Chef-специфичный, потому что я им пользуюсь. Замените соответствующий инструмент для вашей среды, и если вы не используете инструмент управления конфигурацией, вам нужно что-то посмотреть, потому что это делает весь этот процесс намного более надежным и прочным. Не говоря уже о масштабируемости.
решение3
Для действительно критических и чувствительных изменений я обычно создаю текстовый файл с реальными командами, которые я буду использовать, с #комментариями, объясняющими, что происходит. Таким образом, я могу быстро копировать и вставлять их в терминал.
решение4
Я бы поддержал основную идею, лежащую в основе поста jtimberman, при этом моим инструментом выбора является puppet.