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

Въпреки че самите решения PaaS ("Платформа като услуга") не могат да променят начина на индивидуално и екипно взаимодействие, те често служат като катализатор за организационни промени в отговор на увеличената гъвкавост на ИТ-технологиите.

В действителност, максималната възвръщаемост на инвестиции в PaaS често е възможна само при условие за промени в организационните роли, отговорности и схеми на взаимодействие. За щастие, решенията PaaS, като OpenShift Container Platform, притежават достатъчна гъвкавост, за да позволят на всяка ИТ организация самостоятелно да определя скоростта и мащабите на промените спрямо включените хора и протичащите процеси.

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

В този пост ще представим ръководство за провеждане на необходимите организационни промени и ще разкажем как традиционните ИТ роли се променят с внедряването на контейнерни технологии в предприятието.

Свързването на нови работи със стари роли

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

На пътя към DevOps организацията

След стартиране на PaaS и прехвърляне на специалистите по експлоатация на ИТ системите и разработчиците на приложения, организацията може да продължи внедряването на методологията DevOps, която включва сред другите основни принципи:

• Разбиване на работата на малки етапи, за да получавате обратна връзка на ранните етапи, да намалявате рисковете и да избягвате "анализаторския паралич";
• Автоматизиране на операциите в достатъчна степен, за да не създавате препятствия или тесни места в процеса на разгръщане на приложението;
• Обмен на знания – ключът към изграждането на доверие;
• Редовно плащане на технически дългове, отдалечавайки определено време за систематични подобрения във всеки цикъл на работа.

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

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

Нови предизвикателства, които възникват в ИТ-организациите при преминаването към OpenShift

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

В таблицата по-долу са изброени основните задачи на високо ниво, които съществуват във всяка организация, внедрила OpenShift, с примери за съответните работи и умения. Този списък с задачи не трябва да се бърка със схемата за разделение на труда или с организационната структура на екипа; това е само набор от задачи, които трябва да бъдат изпълнени от лица, отговорни за поддръжката на IT средите, за да се осигури успешно внедряване на контейнерната платформа. Всъщност по-късно ще покажем, че внедряването на контейнерни технологии създава предпоставки за формирането на по-зряла DevOps стратегия в предприятието, което от своя страна увеличава степента на крос-функционалност на екипите и намалява рисковете от прекомерна специализация както на индивидуални служители, така и на екипи.

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

Задачи
Изисквани умения

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

Работи:

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

• Проектиране и реализация на дата центрове
• Системна администрация на Linux
• Сценарии за автоматизация
• Знание за системи за съхранение
• Знание в областта на проектирането и реализирането на мрежи
• Сигурност

Инсталиране и управление на платформата OpenShift

Работи:

• Изпълнение на инсталация на клъстера
• Управление на инфраструктурните услуги
• Управление на мащабирането на платформата
• Проверка на автентичността и авторизация на ниво платформа

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

Управление на подготвянето на клиентски среди (tenant provisioning), изолация с IT ресурси

Работи:

• Създаване на потребители и екипи в рамките на платформата
• Проектиране и управление на квоти
• Проектиране и реализиране на RBAC

• Знание за архитектури на Kubernetes и OpenShift
• Знание за контейнерни технологии и архитектури
• Сценарии за автоматизация
• Добри познания в областта на проекти, квоти, привързване на роли и работа с планировчици

Създаване и управление на основни образи

Работи:

• Разработка на работен поток за промяна на образи
• Разработка на образи съгласно стандарти

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

Проектиране и управление на вериги за разгръщане

Работи:

• Проектиране и документиране на стандартите за вериги
• Разработка на кратки ръководства и шаблони
• Обучение на разработчиците

• Управление на изходния код
• Проектиране и изпълнение на приложения
• Сценарии за автоматизация
• Автоматизирано тестване
• Тестване на качеството на кода
• Знание за контейнерни архитектури
• Знания за неизменяема инфраструктура
• Сигурност – управление на достъпа до етапите на веригата, одобрение на работни потоци и т.н.
• Добри познания по шаблони на OpenShift, компоненти buildconfigs, deploymentconfigs, услуги, маршрути, configmaps

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

Работи:

• Кодиране на приложения
• Разработка на автоматизирани тестове
• Реакция на провали на тестовете по време на веригата за разгръщане
• Реакция на откази на приложения
• Потребителско приемно тестване

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

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

Работи:

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

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

Потребителско приемно тестване

Работи:

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

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

Нови роли, които се появяват в ИТ-организацията при прехода към OpenShift

С увеличаването на прехода към DevOps-ориентирана организационна структура, специализацията на ролите обикновено намалява, докато броят на кросфункционалните екипи и роли нараства, за да се максимизира ефективността на сътрудничеството. Ето как изглежда списъкът на основните позиции в ИТ-организация, използваща OpenShift:

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

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

Накрая преминаваме към съпоставяне на разгледаните по-горе позиции и задачи, за да дадем общо представление за това как трябва да изглежда структурата на организация, реализираща DevOps на платформата OpenShift. Първоначално посочените по-долу роли могат да се изпълняват от различни клонове на старата, традиционна организационна структура. Но с времето настъпва консолидация и възникват нови, изградени около приложения екипи, които поемат повечето или дори всички посочени по-долу задачи.

Задачи
Роли

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

Автоматизация и подготовка (provisioning) на IT инфраструктури
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

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

Как е организирана съвместната работа на екипите в DevOps организация

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

Фигура 1. Традиционна ИТ организация

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

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

На тази диаграма е показана как функционира съвместната работа в организация DevOps. Тук същите екипи от предишната диаграма са се отказали от неефективната комуникация, която е засилвала разделението, и я ​​заменили с лични контакти, създавайки по този начин постоянни канали за взаимодействие между екипите. Тези канали способстват за формированието на хибриден набор от умения, които помагат на служителите по-добре да разбират и представят нуждите, проблемите и възможностите на тези екипи, които представляват. Екипите дават една на друга възможност да извършват необходимите работи чрез автоматизирани портали за самообслужване вместо да обработват ръчно чуждите искания за промени, както е било преди. И благодарение на наличието на канали за взаимодействие, тези системи за самообслужване могат бързо да се адаптират към нуждите на екипите, за които са създадени. За постигането на още по-голямо взаимно разбирателство и обмен на знания в рамките на организацията, членовете на екипите периодично изпълняват ротация на ролите, за да получат опит в взаимодействието с различни екипи и по-добре да разбират общата картина на ИТ системите, които обслужват, повишавайки по този начин своята крос-функционалност и полезност.

В обобщение

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

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