Второй путь DevOps: усиление циклов обратной связи

Первый Путь DevOps, про который я писал ранее, описывает принципы, которые обеспечивают быстрый поток работы “слева направо”, Второй путь Путь описывает принципы, которые обеспечивают взаимную, быструю и постоянную обратную связь “справа налево” на всех этапах потока создания ценности.

Адаптированный перевод третьей главы DevOps Handbook.

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

Мы делаем нашу систему работы безопаснее, создавая быстрый и высококачественный поток информации по всему нашему потоку создания ценности и организации в целом, что включает в себя прямую и обратную связь.

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

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

Безопасная работа в комплексных окружениях

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

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

Комплексная работа управляется таким образом, чтобы проблемы в дизайне и эксплуатации становились видными

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

Доктор Питер Сенге в своей книге “Пятая дисциплина” характеризует циклы обратной связи как критическая часть для обучения организации.

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

Циклы обратной связи не только обеспечивают быстрое обнаружение и устранение проблем, также мы можем принять меры чтобы предотвратить повторное возникновение этих проблем в будущем.

Сотрудники свормятся и решают проблемы накапливая знания

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

Образец этого принципа - это шнур “andon” из Toyota: над каждым рабочим местом на производственном заводе Toyota установлен шнур, который каждый работник должен потянуть, в случае если что-то идет не так. Например, когда обнаружена дефектная деталь, когда требуемая деталь недоступна или даже когда работа занимает больше времени, чем должна.

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

Такое радикальный подход к дефектам поддерживает непрерывную интеграцию и развертывание (CI/CD), что представляет собой, по своей сути, однопоточную разработку (single-piece flow) в технологическом процессе создания ценности. Все изменения, прошедшие непрерывную сборку и интеграционные тесты, развертываются в боевую среду, в то время как, любые изменения, вызывающие сбой в тестах, активируют наш шнур “andon” и решаются коллективными усилиями.

Постоянное смещение точки контроля качества ближе к источнику работы (shift left)

Мы можем ненамеренно поддерживать небезопасные для работы системы из-за того, как мы реагируем на происшествия и инциденты. В комплексных системах добавление дополнительных шагов и проверок, на самом деле, увеличивает вероятность будущих сбоев. Эффективность процессов проверок снижается пропорционально с их “отдалением” от места выполнения работы. Мы хотим, чтобы каждый участник нашего потока создания ценности находил и устранял проблемы в своей сфере контроля как часть своей повседневной работы.

Мы используем peer review предлагаемых изменений - взаимный просмотр изменений кода, тестов и т.д. в команде или между командами для того чтобы убедиться в том, что наши изменения будут работать так, как задумано.

Вместо того чтобы запрашивать проведение тестирования в соседнем отделе контроля качества, мы создаём автотесты - автоматизируем как можно больше проверок качества кода и системы в целом. Это позволяет разработчикам быстро тестировать свой же собственный код и даже развертывать эти изменения в производственную среду самим. Тем самым мы встраиваем качество в наш продукт.

Наделение команд ответственностью за качество систем, которые они создают, не только улучшает результаты, но также ускоряет обучение. Это особенно важно для разработчиков, поскольку они часто удалены от клиента. Как говорит Гэри Грувер: "Для разработчика невозможно чему-либо учиться, когда на него кричат из-за того, что он сломал что-то полгода назад - вот почему нам нужно давать обратную связь всем как можно быстрее, в течение минут, а не месяцев."

Оптимизация для рабочих центров “ниже” по потоку создания ценности

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

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

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

Заключение

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

В следующем посте мы рассмотрим последний, Третий путь DevOps: культура экспериментов и обучения.

Published by

Сергей Лобин

Тему DevOps и другие темы профессиональной разработки в Скраме мы разбираем на нашем тренинге Applying Professional Scrum for Software Development (APS-SD)