Как OpenShift меняет организационную структуру ИТ-организации. Эволюция организационных моделей при переходе на PaaS

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

На деле максимальная отдача от инвестиций в PaaS зачастую возможна только при условии изменения организационных ролей, сфер ответственности (задач) и схем взаимоотношений. К счастью, решения PaaS, такие как OpenShift Container Platform, обладают достаточной гибкостью для того, чтобы каждая ИТ-организация могла самостоятельно определять скорость и масштабы перемен относительно вовлеченных людей и происходящих процессов.

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

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

Привязка новых работ к старым ролям

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

На пути к DevOps-организации

Запустив PaaS и переведя на нее специалистов по эксплуатации ИТ-систем и разработчиков приложений, организация может продолжить внедрение методологии DevOps, которая среди прочих включает в себя следующие основные принципы:

• Разбивать работу на мелкие этапы, чтобы получать обратную связь на ранних стадиях, снижать риски и избегать «аналитического паралича»;
• Автоматизировать операции в достаточной мере, чтобы не создавать препятствий или узких мест в процессе развертывания приложения;
• Обмен знаниями – ключ к построению доверия;
• Регулярно платить технически долги, выделяя в каждом цикле работ определенное время на систематические улучшения.

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

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

Новые задачи, которые возникают в ИТ-организациях при переходе на OpenShift

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

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

Таблица 1. Определения задач OpenShift

Задачи
Требуемые навыки

Автоматизация и подготовка (provisioning) ИТ-инфраструктур

Работы:

• Проектирование и построение аппаратных решений
• Организация и сопровождение автоматизации начальной настройки
• Проектирование и автоматизация подготовки ВМ и хостов

• Проектирование и реализация дата-центров
• Системное администрирование Linux
• Сценарии автоматизации
• Знание систем хранения
• Знание в области проектирования и реализации сетей
• Безопасность

Установка и управление платформой OpenShift

Работы:

• Выполнение установки кластера
• Управление инфраструктурными сервисами
• Управление масштабированием платформы
• Проверка подлинности и авторизация на уровне платформы

• Системное администрирование Linux
• Знание сетевых технологий
• Сценарии автоматизации (Ansible)
• Знание систем хранения
• Знание контейнерных технологий и архитектур
• Знание архитектур Kubernetes и OpenShift
• Безопасность платформ
• Интеграция мониторинга

Управление подготовкой клиентских сред (tenant provisioning), изоляцией ИТ-мощностями

Работы:

• Создание пользователей и команд в рамках платформы
• Проектирование и управление квотами
• Проектирование и реализация RBAC

• Знание архитектур Kubernetes и OpenShift
• Знание контейнерных технологий и архитектур
• Сценарии автоматизации
• Хорошие знания в области проектов, квот, привязки ролей и работы с планировщиками

Сборка и управление базовыми образами

Работы:

• Разработка рабочего процесса изменения образов
• Разработка образов на основе стандартов

• Системное администрирование Linux
• Сценарии автоматизации
• Конфигурирование runtime-компонентов приложений и middleware
• Знание контейнерных архитектур
• Фреймворки сборки приложений (application build frameworks)
• Хорошие знания в области образов, imagestream и шаблонов

Проектирование и управление конвейерами развертывания

Работы:

• Проектирование и документирование конвейерных стандартов
• Разработка кратких руководств и шаблонов
• Обучение разработчиков

• Управление исходным кодом
• Проектирование и реализация приложений
• Сценарии автоматизации
• Автоматизированное тестирование
• Тестирование качества кода
• Знание контейнерных архитектур
• Знание immutable инфраструктур
• Безопасность – управление доступом к этапам конвейера, утверждение рабочих процессов и т. п.
• Хорошее знание шаблонов OpenShift, компонентов buildconfigs, deploymentconfigs, services, routes, configmaps

Разработка приложений и тестов

Работы:

• Кодирование приложений
• Разработка автоматизированных тестов
• Реагирование на сбои тестов в ходе конвейера развертывания
• Реагирование на отказы приложений
• Пользовательское приемочное тестирование

• Проектирование и реализация приложений
• Автоматизированное тестирование
• Управление исходным кодом
• Мониторинг приложений
• Знание архитектур облачных (cloud native) приложений

Операционный мониторинг и управление приложениями

Работы:

• Проектирование приложений в контексте производительности
• Мониторинг приложений на стадии выполнения
• Масштабирование приложений (или автомасштабирование)
• Управление доступностью приложений
• Квоты на запросы и лимиты на управление ресурсами
• Тестирование производительности и ИТ-мощностей

• Проектирование и реализация производительности приложений
• Мониторинг производительности приложений
• Тестирование производительности и нагрузочное тестирование

Пользовательское приемочное тестирование

Работы:

• Тестирование UI (дизайн и взаимодействия с пользователем)
• Разработка автоматизированных тестов

• Проектирование и проверка пользовательских интерфейсов
• Шаблоны автоматизированного тестирования
• Фреймворки тестирования
• Шаблоны проектирования приложений

Новые роли, которые возникают в ИТ-организации при переходе на OpenShift

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

• Инженер по эксплуатации приложений (Application Operations Engineer) ИЛИ Инженер по надежности сайта (Site Reliability Engineer). Ранее эта позиция могла называться «Администратор сервера приложений».
• Разработчик приложений/разработчик ПО/инженер-программист.
• Администратор кластера/платформы приложений. Ранее эта роль могла называться «Системный администратор» или «Администратор Linux-платформ».
• Менеджер по выпуску ПО (Release Manager)/Инженер по сборке (Build Engineer).

Матрица ролей и задач RACI

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

Задачи
Роли

Инженер по эксплуатации приложений / Инженер по надежности сайта
Разработчик приложений/ Разработчик ПО / Инженер-программист
Администратор кластера/платформы приложений
Менеджер по выпуску ПО / Инженер по сборке

Автоматизация и подготовка (provisioning) ИТ-инфраструктур
I
I
R/A
C

Установка и управление платформой OpenShift
C
I
R/A
C

Проектирование и управление конвейерами развертывания
C
C
I
R/A

Управление подготовкой клиентских сред (tenant provisioning), изоляцией и ИТ-мощностями
C
I
R/A
I

Сборка и управление базовыми образами
R
C
R/A
C

Разработка приложений и тестов
C
R/A
I
I

Операционный мониторинг и управление приложениями
R/A
C
C
I

Пользовательское приемочное тестирование
C
R
I
I

Условные обозначения в матрице RACI
Источник: Wikipedia

• Responsible – Исполнитель – тот, кто делает необходимое для выполнения задачи.
• Accountable – Ответственный – сотрудник, который в конечном итоге отвечает за правильное и тщательное выполнение задачи или достижение результата; а также единственный, кто может делегировать работу исполнителям.
• Consulted – Консультанты – как правило, это эксперты в предметной области, чей совет запрашивается; с ними поддерживается двухсторонняя коммуникация.
• Informed – Информируемые – люди, которых держат в курсе событий (причем, иногда только по завершении задачи или достижении результата); они получают информацию в одностороннем порядке.

Как устроена совместная работа команд в DevOps-организации

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

Рисунок 1. Традиционная ИТ-организация

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

Рисунок 2. ИТ-организация DevOps

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

Подводя итог

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

Источник: habr.com