Первый Путь DevOps рассматривает рабочий процесс “слева направо”, а Второй Путь говорит о быстрой и непрерывной обратной связи “справа налево”.
Этот принцип обеспечивает постоянное получение новых знаний отдельными людьми, которые затем превращаются в знания команды и организации.
Наша цель - создать культуру высокого доверия, подчеркивая идею, что мы все вечные ученики, которые должны брать на себя риск в своей повседневной работе. Применяя научный подход, как к улучшению процессов, так и к разработке продуктов, мы учимся на своих успехах и неудачах, отсеивая нерабочие идеи и закрепляя те, которые работают. Более того, все локальные знания быстро превращаются в глобальные улучшения, чтобы новые методики и практики могли быть использованы всей организацией.
Чтобы обеспечить принцип непрерывного улучшения мы вносим дополнительную нагрузку в наши системы, симулируем и вносим отказы в наши боевые сервисы в контролируемых условиях, чтобы увеличить нашу устойчивость.
Создавая эту непрерывную и динамичную систему обучения, мы позволяем командам быстро адаптироваться к постоянно изменяющейся среде, что в конечном итоге помогает нам побеждать на рынке.
Организационное обучение и создание культуры безопасности
При работе в комплексной системе невозможно точно предсказать все последствия какого-либо действия, то приводит к неожиданным или даже катастрофическим последствиям и происшествиям в нашей повседневной работе, даже если мы соблюдаем меры предосторожности. Важно, как в организации принято реагировать на такие инциденты.
Рон Веструм был одним из первых, кто обратил внимание на важность организационной культуры для безопасности и результативности. Он отметил, что в организациях здравоохранения наличие генеративной культуры было одним из основных пререквизитов безопасности пациентов.
Доктор Веструм определил три типа культуры из различия я приведу в таблице ниже:
Когда мы говорим о культуре DevOps, то мы устанавливаем основы генеративной культуры, стремясь создать безопасную систему работы. Когда происходят несчастные случаи и сбои, вместо того чтобы искать виновного, мы ищем способы перестроить систему так, чтобы проблема больше не повторилась.
Например, мы можем проводить безобвинительный постмортем (blameless post-mortem - ретроспектива без поиска виновных) после каждого инцидента, чтобы разобраться , из-за чего произошел сбой, и договориться о способах улучшения системы, предотвращения повторения проблемы и более быстрого обнаружения причины и восстановления работы системы.
Встраивайте улучшения в повседневную работу
Команды часто не способны или не желают улучшать процессы самостоятельно, они продолжают страдать от своих текущих проблем, которые со временем имеют тенденцию накапливаться и усиливаться.
Если команды не занимаются системным устранением технического долга, то со временем, его накопится такое количество, что они будут тратить основное время на его устранение, а не на создание новой функциональности.
Поэтому мы выделяем время для погашения технического долга, устранения дефектов, рефакторинга и улучшения проблемных мест нашего кода и окружения в каждом цикле разработки или планируя кайзен-блицы (см аналогичный скрам-паттерн Team Sprint), периоды, когда инженеры самоорганизуются для работы над устранением любой проблемы, которую они хотят решить.
Превращайте локальные открытия в глобальные улучшения
Команды или отдельные сотрудники приобретают опыт, на основе которого формируется экспертиза. Наша цель заключается в преобразовании этого неявного знания (т.е. знания, которое трудно передать другому человеку путем записи или устного изложения) в явное, закодированное знание, которое становится экспертизой для кого-то другого.
Благодаря этой практике, когда кто-то будет выполнять аналогичную работу, он воспользуется накопленным коллективным опытом. Примечательным примером превращения локальных знаний в глобальное является Программа Ядерного Привода ВМС США (также известная как "NR" для "Naval Reactors"), которая имеет более чем 5700 реактор-лет без единого происшествия, связанного с реактором, или выбросом радиации.
В технологическом потоке ценности мы должны создать аналогичные механизмы для формирования глобального знания. Мы можем сделать все наши постмортем-отчеты доступными для команд, которые пытаются решить аналогичные проблемы, а также создать общие репозитории исходного кода, доступные для всей организации. В них хранится общий код, библиотеки и конфигурация, воплощающие лучшее коллективное знание всей организации, и они могут легко переиспользоваться.
Все эти механизмы помогают преобразовать индивидуальную экспертизу в артефакты, доступные для всех.
Внедряйте паттерны устойчивости в работу
Высокопроизводительные организации достигают результатов путем улучшения повседневной деятельности, постоянно пробуя новые идеи для повышения производительности, а также инженерных решений по росту устойчивости своей системы.
Мы стремимся всегда сокращать время деплоя, увеличивать покрытие тестами, сокращать время их выполнения, и даже перестраивать архитектуру, если это необходимо, для повышения производительности труда разработчиков или надежности системы.
Мы также можем проводить упражнения типа "Игровой день", где мы репетируем крупномасштабные отказы, например, отключение одного или всех дата-центров. Или мы можем вводить все более масштабные сбои в боевую среду (как, например, знаменитый Chaos monkey от Netflix, который случайным образом останавливает процессы и сервисы), для того, чтобы убедиться, что мы действительно такие устойчивые, какими хотим быть.
Лидеры поддерживают культуру обучения
Современным лидерам необходимо повысить ценность обучения и дисциплинированного решения проблем. Это напоминает научный метод, где мы явно утверждаем наши истинные цели, такие как, например, "количество аварий должно быть равно 0" или "удвоить производительность в течение года".
Цели помогают провести научный эксперимент: мы явно указываем проблему, которую мы пытаемся решить, формируем гипотезу и предложение по противодействию, методы для проверки этой гипотезы, трактование результатов и использование полученных знаний для информирования следующей итерации экспериментов.
Этот научный итеративный подход направляет все наши внутренние процессы улучшения, а также то, как мы проводим эксперименты, чтобы убедиться, что продукты, которые мы создаем, действительно помогают нашим внутренним и внешним клиентам достигать своих целей.
Заключение
Третий Путь DevOps - это про необходимость ценить и создавать организационное обучение, обеспечивать высокий уровень доверия и пересечения границ между функциями, признание того, что ошибки всегда будут возникать комплексных системах, и создание условий для обсуждения проблем, чтобы мы могли создать безопасную систему работы. Третий Путь DevOps, тесно переплетен с Первым и Вторым Путями. Другими словами, улучшение потока и обратной связи требует итерационного и научного подхода, который включает формулирование целевого состояния, выдвижение гипотез о том, что поможет нам достичь этого, разработку и проведение экспериментов, и оценку результатов.
Результатом являются не только более высокая производительность, но также большая устойчивость, большее удовлетворение от работы и улучшенная адаптивность организации в целом.
Published by Сергей Лобин
Тему DevOps и другие темы профессиональной разработки в Скраме мы разбираем на нашем тренинге Applying Professional Scrum for Software Development (APS-SD)
Тему DevOps и другие темы профессиональной разработки в Скраме мы разбираем на нашем тренинге Applying Professional Scrum for Software Development (APS-SD)
