Введение в DevOps

Боронин Сергей Сергеевич ©

Что такое DevOps и откуда оно взялось?
Термином «DevOps» обычно называют возникшее профессиональное
движение, которое выступает за совместные рабочие отношения между
разработчиками и ИТ-подразделением, в результате получая более
быстрое выполнение планируемых работ (например, высокие темпы
развертывания), одновременно увеличивая надежность, стабильность,
устойчивость и безопасность production-среды. Почему разработчики и
ИТ-подразделения (далее для краткости админы)? Потому что, как
правило, поток ценностей (value stream) находится между бизнесом (где
определяются требования) и заказчиком (куда поставляется результат).
 Чем DevOps отличаются от Agile?
Одним из принципов Agile является предоставление рабочего программного
обеспечения меньшими и более частыми релизами, в отличие от подхода
«большого взрыва», который присущ водопадной методологии. Так что Agile
стремятся иметь потенциально готовый продукт в конце каждого спринта (как
правило, раз в две недели).
Высокие темпы развертывания приводят к тому, что перед админами
накапливается большая гора задач. Clyde Logue, основатель StreamStep, говорит
об этом так: «Agile сыграл важную роль в разработке для восстановлению
доверия у бизнеса, но он нечаянно оставил IT Operations позади. DevOps это
способ восстановления доверия ко всей ИТ-организации в целом ».
 Чем DevOps отличаются от Agile?
DevOps особенно хорошо дополняет Agile, так как он расширяет и дополняет процессы
непрерывной интеграции и выпуска продукта, давая уверенность в том, что код готов к
выпуску и несет ценность для клиента.
DevOps позволяет сформировать гораздо более непрерывный поток работы в ИТ-
подраздедение. Если код не поставляется в продакшн, в том виде как он был разработан
(например, разработчики поставляют код каждые две недели, но развертывается он
только один раз в два месяца), операции по установке будут накапливаться перед
админами, клиенты не получат важный функционал для себя и сам процесс установки в
таком случае приводит к хаосу и дезорганизации.
DevOps, в том числе, изменяет культуру, так же как изменяет процессы и метрике
разработчиков и админов.
 Чем DevOps отличается от ITIL и ITSM?
Хотя многие люди считают, что DevOps это реакция на ITIL (IT Infrastructure Library) и ITSM (IT
Service Management), есть и другая точка зрения. ITIL и ITSM по-прежнему являются лучшей
кодификацией бизнес-процессов, лежащих в основе ИТ подразделения, так как на самом деле
описыват многие вещи, необходимые для того, чтобы ИТ команда могда работать в формате
DevOps.
Непрерывная интеграция и релизы являются результатом работы разработчиков, что в свою
очередь является материалом для работы админов. Для того чтобы уложится в более быстрый ритм
релизов, существующий в DevOps, многие процессы ITIL требуют автоматизации, в частности,
связанные с изменением конфигурации и релизов в целом.
Цель DevOps не столько увеличение скорости выдачи нового функционала, сколько
развертывания этого функционала в производстве, без хаоса и нарушения работы уже
запущенного приложение, а так же быстрое обнаружение и исправление проблем, если они все же
происходят.
 Каковы принципы DevOps?
В DevOps Cookbook и The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business
Win, описаны принципы, с помощью которых все DevOps паттерны могут быть получены с
помощью подхода «Три пути». Они описывают ценности и философию, которые являются
основой процессов, процедур, практик, а также обязательных шагов.
Первый Путь подчеркивает производительность всей системы в целом, в отличие от
производительности отдельного звена или отдела — это может быть как большое подразделение
(например, разработка или ИТ отдел) так и отдельные люди (например, разработчик, системный
администратор).
В центре внимания находится все бизнес-потоки по созданию ценности, которые включены в IT.
Другими словами, он начинается тогда, когда определяются основные требования (например, для
бизнес или ИТ), они закончены в разработке, а затем перешли в ИТ-отдел, в которых ценность
сервиса затем и доставляется заказчику в виде сервиса.
 Каковы принципы DevOps?
Результаты следования Первому Пути на практике состоят в том, что известные баги никогда не
передаются на следующий этап работ, никогда не развивается локальная оптимизация, приводящая
к созданию глобальной деградации, происходит непрерывное улучшение и стремление достичь
глубокого понимания системы (в соответствии с Демингом).
Второй Путь заключается в создании петли обратной связи идущей справа налево. Целью
практически любой инициативы по совершенствования процесса является сокращение и усиление
обратной связь, чтобы необходимые поправки могли внедряться постоянно.
Итоги Второго Пути: понимание и реакция на всех клиентов, как внутренних так и внешних,
сокращение и усиление всех петель обратной связи, и углубление знаний о среде там, где это
нужно.
 Каковы принципы DevOps?
Третий путь заключается в создании культуры, которая влияет на две вещи: постоянное
экспериментирование, которое требует принятия рисков и извлечение уроков из успехов и неудач,
а также понимание того, что повторения и практики являются предпосылкой к мастерству.
Нам нужны оба этих принципа в равной мере. Эксперименты и принятие рисков, является тем, что
гарантирует, что мы продолжим улучшения, даже если это означает, что мы можем зайти в
слишком опасные дебри. И мы должны учиться навыками, которые могут помочь нам выйти из
опасной зоны, когда мы зашли слишком далеко.
Итоги Третьего Пути включают выделение времени для улучшения повседневной работы,
создание ритуалов, которые поощряют команду в принятии рисков и возможному созданию
неисправностей в системе с целью повышения устойчивости в перспективе.
 Области внедрения DevOps
Модель 1: Углубление процессов разработки в поставку: это включает расширение
непрерывной интеграции и выпуска на боевые сервера, интеграция тестирования и
информзащиты в рабочие процессы, что дает готовый к поставке код, настроенные
среды, и так далее.
Модель 2: Создание обратной связи от прода до разработки: включает создание полной
хронологии событий в разработке и администрировании, с целью помощи в
разрешении проблем, а так же предоставление доступа команде разработки к анализу
проблем на проде, одновременно с созданием разработчиками сервисов
самообслуживания, везде где это возможно, и создание информационных радиаторов,
показывающих изменение в поведении системы при вносе изменений.
 Области внедрения DevOps
Модель 3: Объединение разработки и администрирования: состоит во включении
команды разработки в цепочку разрешения проблем, назначение разработчиков на
разрешение проблем на проде, а так же взаимные тренинги между разработчиками и
администраторами, чтобы уменьшить количество эскалаций.
Модель 4: Включение ИТ команды в разработку: состоит во включении или тесной
связью между IT и разработкой, создание многоэтапных пользовательских историй
(включая развертывание, управление кодом в производстве и т.д.), и определение
нефункциональных требования, которые могут быть использованы во всех проектах.
 В чем ценность DevOps?
Есть три бизнес преимущества, которые организации получают от перехода на DevOps:
быстрый выход на рынок (например, сокращение времени цикла и более высокие темпы
развертывания), повышение качества (например, повышение доступности, меньше сбоев
и т.д.), и увеличение организационной эффективности (например, больше времени
тратится на деятельность связанную с увеличением ценности продукта по сравнению с
потерями, увеличение количества функционала, переданного заказчику).
Без сомнения, если я работаю в организации, где я могу сделать только одно
развертывание каждые девять месяцев, и мой конкурент может сделать 10 установок в
день, у меня есть значительные, структурные конкурентные недостатки.
 Что такое методология DevOps?
Простыми словами: DevOps — это понятие, обозначающее группу разработки и группу
эксплуатации систем, которые более тесно сотрудничают между собой. В так
называемом конвейере развертывания (от исходного программного кода до эксплуатации
в производственной среде) разработчики автоматизируют какие-либо действия группы
эксплуатации. Группа эксплуатации имеет возможность отслеживать действия
разработчиков и оказывать на них некоторое влияние. При этом цель заключается в
ускорении развертывания и внедрения программного обеспечения. Объединение
группы эксплуатации (Ops) и разработчиков (Dev) (фактически в виде команды,
использующей методы Agile) позволяет реализовать подход, который можно назвать
«эксплуатация, основанная на методах Agile» (Agile Operations).
 Что такое методология DevOps?
Очевидный результат успешного внедрения методологии DevOps заключается в
сокращении количества времени, которое необходимо на то, чтобы изменение
программного обеспечения прошло все стадии от идеи до эксплуатации в
производственной среде. Когда разработчик говорит, что изменение программного
обеспечения «сделано», переход к использованию этого изменения в производственной
среде выполняется с помощью всеобъемлющей автоматизации. Автоматизированные
средства и процессы используются при конфигурировании системы, в процессе сборки,
при тестировании, развертывании в тестовой, промежуточной и производственной
среде, при проведении мониторинга после завершения развертывания, при оценке и
эксплуатации.
 Итак, DevOps — это просто инструменты?
С одной стороны, цель методологии DevOps заключается в ликвидации узких мест в
конвейере развертывания за счет использования автоматизации. Но автоматизацией
многостадийных процессов все равно необходимо управлять. Многие
автоматизированные процессы на самом деле не являются автономными — они не могут
выполняться без вмешательства человека (для выполнения технического обслуживания и
обработки нестандартных ситуаций). Полностью автоматизированный процесс DevOps
не имеет смысла без учета влияния человеческого фактора. Несмотря на то что средства
автоматизации выполняют много черновой работы, именно люди, управляющие
процессом, обеспечивают его успешное (или неуспешное) выполнение.
 DevOps — это просто разработчики (Dev) и группа
эксплуатации (Ops), тесно сотрудничающие с
использованием средств автоматизации?
Передача управления между автоматизированными процессами часто включает в себя
другие процессы — обычно тестирование того или иного рода. Автоматизированные
тесты создаются разработчиками и тестировщиками. Результаты этих тестов нацелены
на предоставление достаточной информации, необходимой для выполнения других
процессов или, что бывает чаще, необходимой людям, которые выполняют переход от
одной стадии конвейера к другой. Тестировщики и разработчики, которые
осуществляют тестирование, обеспечивают успешное и надежное выполнение процесса
DevOps.
 Тесты, автоматизация и доверие
1) проверки, которые могут быть автоматизированы разработчиками в составе
покомпонентных проверок и процессов непрерывной интеграции;
2) проверки, которые можно автоматизировать (обычно силами профессиональных
тестировщиков) для выполнения транзакций на уровне API, линий связи или всей
системы;
3) тесты, включающие проверки совместимости и позволяющие продемонстрировать
совместимость с браузерами, операционными системами и платформами;
4) тесты, которые может выполнить только человек.
 На что следует обратить внимание?
1. Если это возможно, ручные проверки, которые могут быть выполнены на уровне компонентов, должны быть
возложены на разработчиков. Как тестировщик, вы можете предложить выполнить эти тесты во время сеансов парной
или коллективной работы. Вы можете написать их сами и включить их в режим непрерывной интеграции.
2. Для тестирования пользовательского интерфейса и комплексного тестирования может потребоваться использование
автоматизированных средств. Такое тестирование следует свести к минимуму, так как оно долго выполняется, является
нестабильным и часто требует обслуживания. Подумайте о том, нужно ли его выполнять при каждой проверке
программного кода или можно отложить для использования только на крупных, менее частых релизах.
3. Какие неавтоматизируемые тесты можно выполнять на компонентах, которые еще не интегрированы в
предвыпускную версию? Можно ли выполнять ручное тестирование в сеансах парной работы с разработчиками?
Существуют ли альтернативы такому тестированию? Можно ли выполнять проверки пользовательского интерфейса
на макетах или каркасных конструкциях?
4. Какие проверки необходимо выполнять только вручную в отличие от проверок, которые требуется оставить для
регрессионного тестирования (они являются кандидатами для автоматизированного тестирования)?
 Практика, мониторинг и
совершенствование
Когда программное обеспечение выпускается в производство, обнаруживаются проблемы. Одной из ключевых
дисциплин методологии DevOps с точки зрения эксплуатации является более глубокий мониторинг.
Мониторинг на каждом уровне — от компонентов и простых транзакций в приложениях до интеграции и обмена
сообщениями и, конечно, самой инфраструктуры. Одна из целей мониторинга заключается в том, чтобы формировать
сообщения об отказах до того, как пользователи испытают на себе их последствия. Это довольно амбициозное
утверждение, но оно определяет конечную цель.
Когда проблемы встречаются в производственной среде, то задача заключается в том, чтобы использовать
аналитическую информацию, полученную при выполнении мониторинга для того, чтобы не только отследить
причину и устранить ее, но и для уточнения процесса тестирования (автоматизированного или ручного) и снижения
вероятности возникновения подобных проблем в будущем.
Можно назвать автоматизированное тестирование процесса DevOps мониторингом. Когда мониторинг объединен с
производственной средой, можно сказать, что мониторинг на протяжении всего процесса DevOps с заходом в
производство расширяет сферу применения тестирования.
 Консерватизм трехуровневой системы
техподдержки
Уровень 1. Это находящаяся в непосредственном контакте с пользователями — обычно по телефону —
служба технической поддержки (Service Desk). Нацелена на предоставление техподдержки среднего
уровня по неспециализированным вопросам. Основная задача — поддержание стабильного качества
услуг при условии решения большинства поступающих запросов здесь же, на первом уровне.
Уровень 2. Обычно тесно связан с первым, но подразумевает более глубокие общие или специальные
знания и навыки сотрудников. Специалисты второго уровня, например, могут проходить
дополнительное обучение по поддержке распространенных операционных систем (таких как Microsoft
Windows) или аппаратного обеспечения, получая необходимые навыки для решения более сложных
проблем.
Уровень 3. Здесь находятся команды, специализирующиеся на конкретных технологиях или
приложениях. Компании, самостоятельно разрабатывающие программное обеспечение, часто
организуют отдельные команды поддержки для определенных приложений и сервисов.
 Преимущества трехуровневой системы
техподдержки
• Клиентам предоставлен единый канал общения с техподдержкой
независимо от природы проблемы.
• На рынке труда легко найти специалистов с техническими навыками,
необходимыми для работы на первых двух уровнях поддержки. Это
также облегчает передачу задачи на аутсорс, что делается достаточно
часто.
• Специалисты по конкретным вопросам и областям изолируются от
общения с клиентами и получают на выполнение задачи, относящиеся
только к сферам их компетенции.
Преимущества трехуровневой системы
техподдержки
 Преимущества трехуровневой системы
техподдержки
Специалисты второго уровня обычно обрабатывают меньше заявок, чем их коллеги с
первого, но это более сложные задачи, в среднем требующие больше времени на
решение.
Тикеты, добравшиеся до третьего уровня (эскалированные со второго или отправленные
напрямую с первого), обычно составляют небольшую часть всех поступивших
обращений. Но это самые сложные задачи, решение которых требует высокого
мастерства специалистов и значительных временных затрат.
Было предпринято немало попыток рассчитать сравнительную стоимость решения
проблемы на каждом из уровней поддержки. Например, средняя стоимость закрытия
тикета на первом уровне оценивается в 22 $, на втором — в 62 $, а на третьем — в 85 $.
 Проблемы трехуровневой модели
Многоуровневая поддержка подразумевает несколько очередей. Поскольку первый
уровень стремится решать проблемы максимально быстро, все, что не удалось исправить
сразу, ставится в очередь. Фактический статус проблемы меняется, и она переходит из
разряда текущих в отложенные. По существу уровни 2 и 3 являются складами задач,
находящихся в процессе выполнения (Work in Progress), что является проблемой в
рамках философии, которая лежит в основе DevOps. Успешное внедрение DevOps
требует решительных шагов по сокращению незавершенки (Work in Progress). Уже
только эта проблема является существенным сдерживающим фактором прихода DevOps
в техническую поддержку.
 Проблемы трехуровневой модели
Многоуровневая поддержка может заблокировать путь к нужному специалисту. DevOps
ратует за увеличение самостоятельности и вовлеченности сотрудников. Поощряется
поддержка кода самими разработчиками. Компаниям, практикующим DevOps, удается
достичь более высоких скоростей обработки обращений пользователей (согласно отчету
«Состояние DevOps» (State of DevOps) за 2016 год в 24 раза быстрее). Но от этого нет
никакой пользы, если тикет должен прорваться через несколько очередей, прежде чем
попасть к нужному специалисту.
Почему мы помещаем наших лучших людей в конце цепочки?
Проблемы трехуровневой модели
 Проблемы трехуровневой модели
Многоуровневая поддержка приводит к «отфутболиванию» обращений. В
многоуровневой техподдержке задача в одностороннем порядке назначается
исполнителю. Это может быть сделано на предшествующем уровне или в другой
команде специалистов. Исполнитель впервые видит заявку в том момент, когда она
появляется в его очереди задач. К сожалению, тикет часто отправляется назад, поскольку
либо специалистам нужна дополнительная информация, либо назначение оказалось
ошибочным. DevOps основан на сотрудничестве между профессионалами:
разработчиками, тестировщиками, специалистами служб эксплуатации и т. д.
Вертикальные и горизонтальные барьеры между подразделениями, присущие
многоуровневой поддержке, а также пассивная (без участия принимающей стороны)
передача задач совершенно не соответствуют духу междисциплинарного взаимодействия
и сотрудничества.
Проблемы трехуровневой модели
 Проблемы трехуровневой модели
Многоуровневая поддержка не решает проблему перегруженности специалистов-экспертов (Subject
Matter Experts). Хотя многоуровневая поддержка и решает проблему передачи экспертам слишком
легких для них вопросов, она не защищает их от заваливания сложными задачами. «Герои» —
настоящий бич Управления ИТ-сервисами (ITSM). Это умные люди, которые, как кажется на первый
взгляд, приносят ощутимую пользу организации и регулярно творят чудеса, решая сложные проблемы.
На самом деле такие герои — перегруженная работой единая точка отказа. Они вольно или невольно
являются хранителями жизненно важных для организации знаний и склонны к выгоранию.
Многоуровневая поддержка, будучи линейной и изолирующей структурой, не делает ничего, чтобы
предотвратить культ Героя, и, пожалуй, даже поддерживает его. В процессе смещения традиционного
бизнеса в сторону DevOps мы видим сохранение такой схемы работы, когда ключевые члены команды
DevOps помещаются в конце цепочки эскалации. Ущерб в DevOps-сценарии, возможно, еще больший:
ключевые разработчики отстраняются от новаторства и вынуждены заниматься решением
эскалированных и уже потерявших время обращений пользователей.
Проблемы трехуровневой модели
 Swarming в качестве альтернативы
Концепция Swarming была предложена в конце прошлого десятилетия в качестве новой платформы для
организации технической поддержки. Она в явном виде отвергает консервативную многоуровневую
структуру в пользу модели сетевого взаимодействия:
 Swarming в качестве альтернативы
Ключевой компанией, которая первой начала внедрять эту систему, была Cisco. В 2008
году в документе под названием Digital Swarming она представила «Модель
распределенного сотрудничества и принятия решений». Концепция была впоследствии
принята организацией Consortium for Service Innovation, трансформировавшись в
Intelligent Swarming. Некоторые из ее принципов гласят:
• Не должно быть разделенных на уровни групп поддержки.
• Не должно быть эскалации от одной группы к другой.
• Задача должна передаваться напрямую тому сотруднику, который наверняка сможет ее
решить.
• Человек, принявший обращение, отвечает за него до конца.
 Swarming на практике: пример структуры
для DevOps
У Swarming нет единственной четко определенной структуры. Отчасти это объясняется новизной и, соответственно,
малой распространенностью. Swarming начинается при появлении проблемы, которую невозможно решить сразу в
момент получения обращения от пользователя. Быстрая первичная сортировка задачи заканчивается ее отправкой в
одну из двух групп (Swarms):
 “Severity 1” Swarm (Группа по работе с
инцидентами первой степени тяжести)

• Три сотрудника, работающие в условиях запланированной еженедельной ротации.

• Основное внимание: предоставить незамедлительный ответ, решить задачу как можно
быстрее.
Эта группа нацелена на решение самых серьезных проблем. Ее участники
координируют реакцию на сложные ситуации, подключают нужных людей, стараются
организовать максимально быстрое решение критических проблем. Этот процесс не
сильно отличается от процедуры реакции на серьезные происшествия (Major Incident),
применяемой в традиционной многоуровневой модели.
 Dispatch Swarm (Группа диспетчеризации)

• Проводит встречи каждые 60–90 минут.

• Сфокусирована на регионах и продуктовых линейках.
• Основное внимание: «схватить вишенку» (в первую очередь браться за то, что можно исправить очень быстро).
• Вторичная задача: проверка обращений перед их отправкой командам поддержки продуктовых линеек.
Этот тип групп появился в качестве ответа на основную проблему многоуровневой поддержки: множество обращений,
которые могли быть решены очень быстро при попадании к правильному специалисту, теряются в списках
незавершенных задач. Таким образом, решение пятиминутного вопроса может растягиваться на дни.
Участников этой группы буквально подталкивают к тому, чтобы «хватать вишенки», не обращая внимания на
проблемы, которые нельзя исправить мгновенно. Таким образом, время, затрачиваемое на решение значительного
количества типов задач, может быть сильно сокращено.
 Dispatch Swarm (Группа диспетчеризации)
Есть и дополнительная выгода. Включение в состав неопытных сотрудников приводит к
тому, что они получают знания, доступ к которым в многоуровневой модели появился бы
только при переводе в узкоспециализированную команду. В то же время
высококвалифицированные специалисты третьего уровня поддержки оказываются ближе к
клиенту.
Использование Dispatch Swarming приводит к быстрому решению значительного числа
задач (в BMC их количество составляет примерно 30%), а оставшиеся обращения попадают в
очереди более привычных команд поддержки, которые занимаются отдельными линейками
продуктов. Здесь многие задачи будут знакомы и понятны рядовым членам команды, поэтому
их решение не должно вызывать трудностей. При этом еще одна часть обращений
(возможно, около 30%) могут оказаться достойны внимания лучших специалистов службы
поддержки независимо от их структурной принадлежности.
 Backlog Swarm (Группа работы с
накопившимися задачами)

• Проводит встречи регулярно, обычно ежедневно.

• Основное внимание: решение сложных задач, полученных от команд поддержки
продуктовых линеек.
• Вторичная задача: замена одиночных экспертов.
Для решения наиболее сложных проблем Backlog Swarm объединяет группы опытных и
квалифицированных инженеров, невзирая на географические и структурные границы. Они
получают задачи от специалистов на местах, которым теперь запрещено напрямую
обращаться к экспертам индивидуально. Вместо этого они должны передавать задачи в
соответствующий Backlog Swarm.
Статистика DevOpS
Swarming-движение начало атаку на модель многоуровневой
поддержки, но прогресс в управлении ИТ-сервисами
традиционных компаний идет медленно, поскольку он ограничен
рамками использования лишь в нескольких дальновидных
организациях. Однако близость основных элементов Swarming и
DevOps сложно отрицать, и поэтому они имеют схожие проблемы
внедрения, решение которых делает проще использование обеих
систем.
Таким образом, существует необходимость переосмысления
модели многоуровневой поддержки. Новая методология должна
использовать преимущества DevOps, сохраняя работоспособность
и эффективность в масштабах крупных компаний.
 Автоматизация, автоматизация и ещё раз
автоматизация
Непрерывная поставка ПО — это один из наиболее важных наборов практик
DevOps. В своей лучшей реализации она выглядит так: каждый раз, когда
разработчик коммитит (commits) код, он включается в билд (gets build), тестируется,
разворачивается (если он соответствует всем критериям релиза) практически без
участия человека. Отсутствие ручного труда не только ускоряет релизы, но также
улучшает его качество убирая вероятность ошибки из-за человеческого фактора.
Первый шаг команды на пути автоматизации процесса — это его анализ на предмет
наличия работ не несущих дополнительной ценности. В то же время
пересматривается архитектура приложения. В результате может появиться новый
бэклог задач, целью которых является переработка приложения и устранение
технического долга.
 Автоматизация, автоматизация и ещё раз
автоматизация
Простые процессы — лучше всего. Избавляйтесь от переусложненных процессов.
Начинайте с начала и с конца процесса и двигайтесь к его середине. Юнит-тесты и
разворачивание на продукционную среду, пожалуй, являются наиболее
подходящими областями, чтобы начать писать скрипты.
Автоматизация должна быть естественной частью работы команд разработчиков.
Эти команды должны работать вместе с эксплуатацией, чтобы быть уверенным, что
всё, что делается, может быть использовано, как в разворачивании ПО, так и в
продукционной среде.
 Профессионализм в разработке
программного обеспечения
• Введите ученичество, наставничество, обучение на примерах практики личностного развития.
• Вознаграждайте команды, а не отдельных людей. В большинстве организаций существует мало направлений,
где человек может чего-то достичь в одиночку. Большое количество разных людей должны работать вместе, чтобы
принести больше пользы потребителю. Большинство инициатив, которые завязаны на одного человека —
неуместны, а персональные поощрения противоречат тому факту, что результат очень редко достигается в
одиночку.
• Вознаграждайте людей за реальные достижения, а не просто за то, что они чем-то заняты. Фокусируйтесь
на том, чтобы увеличивать полезность для покупателя и устранении ненужной работы, а не на том, чтобы держать
людей занятыми, насколько это возможно. Покуда человеческий ресурс дорог, никто не выигрывает от того, что
занятые люди выдают неверное решение. А поддержание постоянно занятыми людей, навыки которых являются
дефицитными, попросту означает, что много кому другому придётся ждать.
• Делайте эти ценности такими же важными, как и результат работы. Как часто вы слышали кого-то, кто
говорил: "Да, ему удалось завершить разработку, но это была кровавая баня"? Такой героический подход к
разработке иногда работает, но его результат непредсказуем и уничтожает организацию, приводя к выгоранию
людей.
 Профессионализм в эксплуатации
программного обеспечения
• Реструктуризация поддерживаемых сервисов с целью группировки вокруг клиентов/продуктов. Первый шаг — это
стремление работать с заявками в привязке к бизнесу, и реструктуризация исходя из бизнес-результатов и продуктов, а не
основываясь на процессах и навыках специалистов.
• Удаление очередей из системы. Когда команда разработчиков не может делать работу самостоятельно, не заставляйте её
ждать кого-то ещё для получения помощи; сделайте так, чтобы помощь была доступна в любой момент, когда она нужна.
Предоставляйте сервисы самообслуживания везде, где это возможно, или набирайте людей на вакансии "экспертов" таким
образом, чтобы их было достаточное количество для того, чтобы обеспечить командам помощь, как только она
потребуется. В любом случае критичным является устранение преград на пути рабочего процесса.
• Предоставляйте услуги службы эксплуатации командам разработчиков. Наличие раздельных команд разработки и
эксплуатации может быть неизбежным, но всегда должны быть доступны специалисты, готовые выполнять запросы
разработчиков.
• Автоматизируйте, автоматизируйте и ещё раз автоматизируйте. Для многих команд эксплуатации единственным способом
начать доверять командам разработчиков — это либо стать частью команды, либо автоматизировать её работу, чтобы
исключить ошибки. С этой стороны автоматизация — это жизненно важная часть обеспечения того, что целостный
подход к циклу поставки продукта является применимым.
 Профессионализм в эксплуатации
программного обеспечения
• Внедрение поддержки среды для измерений и аналитики. Анализ среды разработки и самого ПО, требует
внедрения технологий, которая могла бы поддерживать как учёт показателей, так и их хранение и анализ
данных.
• Создание общих информационных панелей (dashboards), которые содержат важные для конечного
пользователя показатели успешности разработки. Очень часто команды эксплуатации и разработки
используют разные информационные панели, чтобы показывать информацию о прогрессе, успехе или
неудаче. Создавая информационную панель, которая содержит информацию, важную для обеих команд, вы
создаёте коммуникационную среду, которая способствует эффективному сотрудничеству.
• Обеспечение того, что вопросы, возникшие на ретроспективе спринта, будут учтены при проведении
мероприятий, связанных с DevOps. В процессе разработки возникает большое количество моментов, когда
проводятся проверка и доработка. Ретроспектива спринта — это лучшее событие, чтобы проверить, как
работает команда. Из этой ретроспективы проистекают возможности для улучшения. Многие из
направлений улучшений связаны с процессом управления релизами (release management), безопасностью и
эксплуатацией. Тем более важным становится участие команд эксплуатации в проходящих ретроспективах
спринта и использование их (ретроспектив) как части работ по улучшению.
 Дополнительные материалы
• http://www.facebook.com/groups/feedme.ru
• http://www.facebook.com/groups/1418742661718580
• http://devopsdeflope.ru
• http://telegram.me/devops_deflope
• http://eksmo.ru/book/proekt-feniks-roman-o-tom-kak-devops-menyaet-
biznes-k-luchshemu-ITD583259