Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях

На данный момент, чтобы встроить сложное коммерческое готовое программное обеспечение (commercial off-the-shelf, COTS; например SAP, IBM WebSphere, Oracle WebLogic) в систему контроля версий, придется, возможно, прекратить использовать графические инструменты установки, предоставляемые поставщиком. Для этого нужно разобраться, что именно делает установщик. Возможно, потребуется сделать установку на чистый образ сервера, сравнить файловые системы и ввести добавленные файлы в систему контроля версий. Файлы, не меняющиеся в зависимости от среды, помещаются в одно место («базовая установка»), тогда как специфичные для разных сред помещаются в отдельные папки («тест» или «эксплуатация»). Так установка программ становится просто операцией в системе контроля версий. Прозрачность, повторяемость и скорость операций улучшаются.

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

Приложение 8

Совещания для послеаварийной ретроспективы

Ниже приведен простой план совещания по разбору для послеаварийной ретроспективы.

• В самом начале руководитель встречи или координатор произносит небольшую вступительную речь, подчеркивая, что сегодня никто не будет искать виноватых, сосредоточиваться на прошедших событиях или рассуждать о том, что могло бы или должно было быть. Координатор может прочитать главную директиву разбора ошибок (Retrospective Prime Directive)[184] с сайта Retrospective.com.

Кроме того, координатор должен напомнить всем, что у контрмер должен быть конкретный исполнитель. Если по окончании совещания контрмера не оказывается приоритетной, то это не контрмера (так делается, чтобы не создавать длинный список хороших идей, которые никогда не воплотятся в жизнь).

• Участники встречи должны составить единую картину того, в каком порядке происходили события во время сбоя: кто и когда обнаружил неполадку, как она была обнаружена (например, с помощью автоматического мониторинга, контроля вручную, письма клиента), когда работоспособность сервиса была восстановлена и так далее. В последовательную цепочку событий также нужно внести все внешние коммуникации во время инцидента.

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

• Далее команда создает список всех факторов, приведших к инциденту: и человеческих, и технических. Потом их можно распределить по категориям, например «проектировочное решение», «восстановление», «фиксация наличия проблемы» и так далее. Команда может использовать такие методики, как мозговой штурм и «бесконечные “как”», чтобы вскрыть более глубокие причины проблемы, если в этом есть необходимость. При этом все точки зрения должны восприниматься уважительно — никто не должен возражать или спорить с реальностью фактора, предложенного кем-то другим. Очень важно, чтобы координатор выделил достаточно времени на эту часть совещания и чтобы команда не пыталась свести все к одной-двум «главным причинам».

• На следующем этапе участники совещания должны определиться со списком корректирующих действий, которые нужно будет выполнить как можно быстрее. Чтобы составить список, полезно устроить мозговой штурм. По итогам необходимо выбрать наилучшие действия для предотвращения таких ошибок в будущем или хотя бы для их более быстрого обнаружения. Туда можно включить и другие способы улучшить рабочие системы.

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

Также нужно составить другой список — менее приоритетных идей — и назначить ответственного за него. Если в будущем возникнут похожие проблемы, список может послужить отправной точкой возможных решений.

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

Тяжесть инцидента: насколько серьезной была проблема? Этот показатель непосредственно связан с влиянием на сервис и на клиентов.

Время простоя: как долго клиенты не могли пользоваться сервисом?

Время обнаружения: сколько времени потребовалось на то, чтобы заметить, что есть проблема?

Время устранения проблемы: сколько времени потребовалось на то, чтобы восстановить работу сервиса после того, как мы обнаружили сбой?