Как 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

Задачи
Необходими умения

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

Работи:

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

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

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

Работи:

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

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

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

Работи:

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

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

Сглобяване и управление на базови изображения

Работи:

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

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

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

Работи:

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

• Управление на изходния код
• Проектиране и внедряване на приложения
• Сценарии за автоматизация
• Автоматизирано тестване
• Тестване на качеството на кода
• Познавателност на контейнерни архитектури
• Знания за неизменна инфраструктура
• Сигурност – управление на достъпа до етапите на конвейера, одобрение на работни процеси и др.
• Добро познаване на шаблони 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. Първоначално посочените по-долу роли могат да се изпълняват от различни клонове на старата, традиционна организационна структура. Но с времето настъпва консолидиране и се формират нови екипи, изградени около приложенията, които поемат повечето или дори всички посочени по-долу задачи.

Задачи
Роли

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

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