Часто можно слышать от людей, которые выполняют операционные роли в ИТ-подразделении, жалобы на то, что DevOps – это только разработка, что большая часть важной работы, выполняемой ими в среде эксплуатации, на самом деле не включена в охват. И можно объяснить, почему это мнение так распространено. Практически вся деятельность DevOps в организации зависит от людей, которые приходят из среды разработки. Но если вы хотите, чтобы DevOps работал для всех, то все и должны участвовать. Это не означает, что людям из среды эксплуатации нужно присылать специальные приглашения и предлагать присоединиться к нововведениям. Это означает самостоятельное и активное принятие ими идей DevOps в том, как управлять ИТ в среде эксплуатации, и активное привлечение коллег из разработки для сотрудничества.

Как отмечает Стюарт Рэнс в своей заметке, очень часто этого просто не происходит. Поэтому необходимы усилия по наведению мостов между “Dev” и “Ops”. Справедливости ради следует сказать, что почти все активности DevOps были обеспечены и продолжают обеспечиваться специалистами из среды разработки. Их подход привел к серьезным улучшениям. Они создают ценное программное обеспечение намного быстрее, оно является более надежным и более ориентированным на потребности клиентов. Хотя в некоторых компаниях реализованы и аспекты из операционной среды, всё-таки двигателем этих изменений является сообщество разработчиков. При этом специалисты среды эксплуатации, скорее, сопротивляются им, полагая, что разработчики вторгаются в их экспертную область.

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

Для “наведения мостов”, как пишет Стюарт, понадобится обратиться к самим принципам DevOps, и затем разработать способы их применения в операционной среде.

Один из взглядов на DevOps заключается в том, что вы оптимизируете три направления: поток, обратная связь, эксперимент и обучение:

• Поток – понимание всего потока работы, частью которого вы являетесь, и знание о том, как оптимизировать его целиком, а не только вашу часть. Это включает в себя устранение очередей и узких мест по всей системе , чтобы максимизировать пропускную способность
• Обратная связь – создание контуров обратной связи. Не только для всего потока, но и для каждого этапа потока. Предлагайте устанавливать обратную связь людям, которые предоставляют вам информацию, и запрашивайте её от тех, на которых влияет ваша работа. Затем используйте обратную связь, чтобы понять, как улучшить поток
• Эксперимент и обучение – в безопасной среде обкатываются новые догадки, чтобы постоянно учиться и совершенствоваться. Не просто попробуйте новые вещи наугад – начните с формирования гипотезы о том, как вы могли бы улучшить что-то, а затем проведите эксперимент, чтобы увидеть, были ли вы правы. Если догадка сработала, тогда приступайте к реализации, иначе – вернитесь на исходные.

Другой подход к DevOps можно выразить аббревиатурой CALMS (Culture, Automation, Lean, Measurement, Sharing). Сосредоточение внимания на этих пяти важных аспектах DevOps приводит к оптимизации работы и повышению эффективности:

• Культура (Culture) – это сотрудничество и совместная работа по оптимизации ценности, которую мы создаем для наших клиентов. Культура вашей организации определяет, насколько хорошо вы управляете потоком, обратной связью и обучением, а также всем остальным, что вы делаете
• Автоматизация (Automation) устраняет расточительные ручные процессы и заменяет их надежными, повторяемыми, автоматическими. Наиболее распространённым примером DevOps является автоматизация набора инструментальных средств, который использует недавно разработанный код, интегрирует его с другим кодом, затем компилирует и тестирует полное программное решение, готовое к развертыванию
• Lean – это способ оптимизации работы. Он включает понимание того, что на самом деле происходит, где делается работа, создание потока ценности для понимания потока работы, устранение непроизводительных потерь и включение улучшений во всё, что вы делаете
• Измерение (Measurement) – это про то, что вы можете ожидать. Измеряйте, что вы делаете, какие результаты это приносит, отслеживайте эффект от изменений и улучшений
• Совместное использование (Sharing) подчеркивает важность того, чтобы делать работу видимой другим и сотрудничать. Принцип ратует за использование Канбан и других методологий визуализации, чтобы помочь каждому понять, на каком этапе сейчас находится работа, как её выполнение протекает через систему.

Как вовлечь отделы эксплуатации в DevOps? Самым важным шагом является принятие идей DevOps сотрудниками операционных ИТ-подразделений. Будь-то “три направления” или “CALMS” – главное, чтобы они разделяли и использовали эти принципы. Используя их в своей работе, сотрудники могут увеличить свой вклад в поток создания ценности для своих клиентов. Далее Стюарт приводит конкретные примеры использования принципов на практике.

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

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

Экспериментируйте и учитесь
В среде эксплуатации существуют много процессов, которые помогают обеспечить надежное предоставление услуг. Во многих организациях эти процессы являются статическими, они не адаптируются к изменяющимся обстоятельствам.
При этом действительно отличная ИТ-организация понимает, что эти процессы должны развиваться, чтобы идти в ногу с меняющимися потребностями бизнеса. Это не означает, что каждый процесс должен ежегодно проходить крупный пересмотр, что было бы очень неэффективно. Главное – это поощрять сотрудников выявлять возможности улучшения. Затем вы должны подумать о том, как вы можете проверить эти идеи, протестировав их в безопасной среде, не создавая серьезных рисков или сбоев. А затем уже – распространить на всю организацию.

Определённо, операционные ИТ-подразделения могут улучшить свою работу, используя принципы DevOps. Для самого DevOps это отличная возможность сместить фокус с текущего “Dev” больше в сторону “Ops”. Но при этом и сами люди из среды эксплуатации не должны сидеть сложа руки, ожидая, что кто-то сделает работу за них. Им самим нужно взять на себя ответственность и встроить свою “Ops”-деятельность в DevOps, заключает Стюарт.

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление поддержкой ИТ-услуг

Строим эффективную ИТ-поддержку, оптимизируем существующую