Хоць самі па сабе рашэнні 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
Крыніца:
- Адказны - Выканаўца - той, хто робіць неабходнае для выканання задачы.
- падсправаздачны - адказны - супрацоўнік, які ў канчатковым выніку адказвае за правільнае і стараннае выкананне задачы або дасягненне выніку; а таксама адзіны, хто можа дэлегаваць працу выканаўцам.
- раіўся - Кансультанты - як правіла, гэта эксперты ў прадметнай вобласці, чыя рада запытваецца; з імі падтрымліваецца двухбаковая камунікацыя.
- інфармаваныя - інфармаваныя - людзі, якіх трымаюць у курсе падзей (прычым, часам толькі па завяршэнні задачы або дасягненні выніку); яны атрымліваюць інфармацыю ў аднабаковым парадку.
Як уладкованая сумесная праца каманд у DevOps-арганізацыі
Традыцыйная схема атрымання рэсурсаў, як правіла, уяўляе сабой цыкл запытаў на выдзяленне рэсурсаў, якія затым выконваюцца некалькімі камандамі. У канчатковым выніку ўсе неабходныя рэсурсы вылучаюцца і пацвярджаюцца запытальным бокам. Часцяком гэтыя працэсы часткова, а то і цалкам здзяйсняюцца ўручную і патрабуюць частых і шматлікіх узаемадзеянняў паміж камандамі для паспяховай апрацоўкі кожнага запыту.
Малюнак 1. Традыцыйная ІТ-арганізацыя
Дыяграма вышэй ілюструе тыпавыя ўзаемаадносіны паміж камандамі ў традыцыйнай ІТ-арганізацыі. У рамках гэтай схемы адны каманды звяртаюцца да іншых каманд з запытам на выкананне неабходных прац, выкарыстаючы больш ці меней фармалізаваныя сродкі камунікацыі, накшталт сістэмы тыкетаў ці электроннай пошты. Затым гэтыя запыты трапляюць у чаргу і чакаюць сваёй гадзіны, прычым доўгае чаканне часта прыводзіць да пагаршэння, а то і да абвастрэння адносін паміж камандамі. Напружанне пагаршаецца яшчэ і тым, што чальцы розных каманд рэдка сустракаюцца сябар з сябрам асабіста і, як правіла, дзеляцца толькі мінімальна неабходнай інфармацыяй.
Малюнак 2. ІТ-арганізацыя DevOps
На гэтай дыяграме паказана, як уладкованая сумесная праца ў арганізацыі DevOps. Тут тыя ж самыя каманды з папярэдняй дыяграмы адмовіліся ад неэфектыўных камунікацый, якія ўзмацнялі раз'яднанасць, і замянілі іх на персанальныя кантакты, стварыўшы тым самым пастаянныя каналы ўзаемадзеяння паміж камандамі. Гэтыя каналы спрыяюць фармаванню гібрыднага набору навыкаў, які дапамагае супрацоўнікам лепш разумець і прадстаўляць патрэбы, праблемы і магчымасці тых каманд, якія яны прадстаўляюць. Каманды даюць адна адной магчымасць выконваць неабходныя работы праз аўтаматызаваныя парталы самаабслугоўвання замест таго, каб уручную адпрацоўваць чужыя запыты на змены, як гэта было раней. І дзякуючы наяўнасці каналаў узаемадзеяння гэтыя сістэмы самаабслугоўвання здольныя хутка адаптавацца да запатрабаванняў каманд, для якіх яны створаны. Для дасягнення яшчэ большага паразумення і абмену ведамі ў рамках арганізацыі чальцы каманд перыядычна выконваюць ратацыю роляў, каб атрымаць досвед узаемадзеяння з рознымі камандамі і лепш разумець агульную карціну ІТ-сістэм, якія яны абслугоўваюць, падвышаючы тым самым свой узровень крос-функцыянальнасці і карыснасці.
Падводзячы вынік
У гэтым пасце мы распавялі, як укараненне рашэнняў PaaS можа падштурхнуць арганізацыю на ўкараненне метадалогіі DevOps, прычым у рамках гэтага працэсу змене падвяргаюцца традыцыйныя ролі і задачы. Таму мы пералічылі асноўныя ІТ-задачы, якія ўзнікаюць у арганізацыі з пераходам на OpenShift, а таксама навыкі, неабходныя для іх выканання. Мы таксама прывялі асноўны набор арганізацыйных роляў, які ўзнікае пры пабудове крос-функцыянальных каманд DevOps, і матрыцу RACI, якая ўвязвае новыя ролі з новымі задачамі. І нарэшце, мы распавялі, як платформа OpenShift і злучаная з ёй метадалогія DevOps могуць змяніць аргструктуру арганізацыі пры пераходзе ад традыцыйнай іерархіі і сістэм апрацоўкі заявак да крос-функцыянальных каманд з больш высокім узроўнем персанальных камунікацый.
Крыніца: habr.com
