Руководство по DevOps (Ким, Уиллис) - страница 276
Рис. 48. Шнур-андон компании Тойота
На данный момент, чтобы встроить сложное коммерческое готовое программное обеспечение (commercial off-the-shelf, COTS; например SAP, IBM WebSphere, Oracle WebLogic) в систему контроля версий, придется, возможно, прекратить использовать графические инструменты установки, предоставляемые поставщиком. Для этого нужно разобраться, что именно делает установщик. Возможно, потребуется сделать установку на чистый образ сервера, сравнить файловые системы и ввести добавленные файлы в систему контроля версий. Файлы, не меняющиеся в зависимости от среды, помещаются в одно место («базовая установка»), тогда как специфичные для разных сред помещаются в отдельные папки («тест» или «эксплуатация»). Так установка программ становится просто операцией в системе контроля версий. Прозрачность, повторяемость и скорость операций улучшаются.
Также, вероятно, придется изменить настройки конфигурации приложений, чтобы они были в системе контроля версий. Например, можно преобразовать конфигурации приложений, хранящихся в базе данных, в XML-файлы, или наоборот.
Ниже приведен простой план совещания по разбору для послеаварийной ретроспективы.
• В самом начале руководитель встречи или координатор произносит небольшую вступительную речь, подчеркивая, что сегодня никто не будет искать виноватых, сосредоточиваться на прошедших событиях или рассуждать о том, что могло бы или должно было быть. Координатор может прочитать главную директиву разбора ошибок (Retrospective Prime Directive)[184] с сайта Retrospective.com.
Кроме того, координатор должен напомнить всем, что у контрмер должен быть конкретный исполнитель. Если по окончании совещания контрмера не оказывается приоритетной, то это не контрмера (так делается, чтобы не создавать длинный список хороших идей, которые никогда не воплотятся в жизнь).
• Участники встречи должны составить единую картину того, в каком порядке происходили события во время сбоя: кто и когда обнаружил неполадку, как она была обнаружена (например, с помощью автоматического мониторинга, контроля вручную, письма клиента), когда работоспособность сервиса была восстановлена и так далее. В последовательную цепочку событий также нужно внести все внешние коммуникации во время инцидента.
Используя выражение «цепочка событий», мы формируем в воображении образ линейной последовательности шагов: как формировалось понимание проблемы и как мы в итоге ее исправили. На самом деле, особенно в сложных системах, к сбою приводит много разных событий, и нужно вносить исправления по нескольким путям одновременно. На этом шаге следует отследить все события и все мнения участников и по возможности выдвинуть гипотезы о причинно-следственных связях.