До­ро­га к Devops

Otkrytye sistemy. SUBD. - - СОДЕРЖАНИЕ - Эрик Дер­нен­бург

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

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

Клю­че­вые сло­ва: Devops, ин­те­гра­ция раз­ра­бот­ки и экс­плу­а­та­ции Keywords: Designops, Agile, Integration of development and operation

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

Пе­ре­ме­ны на­ча­лись с мас­со­во­го пе­ре­хо­да на Agile-раз­ра­бот­ку, а про­дол­жи­лись внед­ре­ни­ем прин­ци­пов Devops и Designops. В со­вре­мен­ной ком­па­нии ИТ — это сфе­ра кол­лек­тив­ной от­вет­ствен­но­сти. Хо­тя про­фес­си­о­на­лы с об­шир­ны­ми тех­ни­че­ски­ми по­зна­ни­я­ми по-преж­не­му необ­хо­ди­мы, нуж­но фо­ку­си­ро­вать вни­ма­ние на том, как ор­га­ни­зо­вать эф­фек­тив­ную сов­мест­ную ра­бо­ту пред­ста­ви­те­лей всех спе­ци­аль­но­стей.

ТЕХ­НО­ЛО­ГИИ НА ВТО­РЫХ РО­ЛЯХ

В 1960-х го­дах, на за­ре при­ме­не­ния ИТ в биз­не­се, они ча­ще иг­ра­ли «ро­ли вто­ро­го пла­на»: Ит-си­сте­мы обыч­но внед­ря­ли для уско­ре­ния или сни­же­ния сто­и­мо­сти уже су­ще­ству­ю­щих про­цес­сов. Глав­ной за­да­чей бы­ло по­вы­ше­ние до­хо­да, а це­лью — улуч­ше­ние опе­ра­ци­он­ной эф­фек­тив­но­сти.

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

Вме­сте с ПК по­яви­лось еще од­но нов­ше­ство — па­ке­ты офис­ных при­ло­же­ний: тек­сто­вые про­цес­со­ры, элек­трон­ные таб­ли­цы и т. п. Бла­го­да­ря мак­ро­сам, встро­ен­ным сред­ствам про­грам­ми­ро­ва­ния и ме­ха­низ­мам ин­те­гра­ции та­кие па­ке­ты ста­ли мощ­ной плат­фор­мой, на ко­то­рой биз­нес-поль­зо­ва­те­ли са­ми на­ча­ли со­зда­вать слож­ные ре­ше­ния. Од­ним из глав­ных сти­му­лов, по­буж­да­ю­щих биз­нес к это­му, ста­ла негиб­кость со­здан­ных от­де­ла­ми ИТ про­цес­сов, что от­би­ва­ло охо­ту к вза­и­мо­дей­ствию, хо­тя в ре­аль­но­сти тре­бо­ва­лось бо­лее тес­ное со­труд­ни­че­ство. По­сте­пен­но со­зда­ние ав­то­ма­ти­зи­ро­ван­ных си­стем вне от­де­ла ИТ ста­ло на­столь­ко рас­про­стра­нен­ной прак­ти­кой, что для них да­же при­ду­ма­ли на­зва­ние — «те­не­вые ИТ», ко­то­рые, с од­ной сто­ро­ны, спо­соб­ству­ют улуч­ше­нию вза­и­мо­дей­ствия, а с дру­гой, об­хо­дят­ся неде­ше­во. Со­глас­но ре­зуль­та­там ис­сле­до­ва­ний, на те­не­вые ИТ мо­жет тра­тить­ся от 30 до 50% об­ще­го Ит­бюд­же­та ор­га­ни­за­ции, а кро­ме то­го, они со­зда­ют зна­чи­тель­ный риск для биз­не­са [1].

ТЕХ­НО­ЛО­ГИИ СТА­НО­ВЯТ­СЯ БИЗ­НЕ­СОМ

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

С рас­цве­том эко­но­ми­ки до­тко­мов эта тен­ден­ция еще бо­лее уси­ли­лась: по­яви­лись ком­па­нии, для ко­то­рых тех­но­ло­гии и бы­ли биз­не­сом. Они не про­сто обес­пе­чи­ва­ли ры­ноч­ную диф­фе­рен­ци­а­цию пу­тем ис­поль­зо­ва­ния тех­но­ло­гий, а су­ще­ство­ва­ли толь­ко бла­го­да­ря им (см. ри­су­нок).

В глазах ком­па­ний, где к от­де­лу ИТ ста­ли от­но­сить­ся как к парт­не­ру, пре­об­ла­дав­ший то­гда про­ект­ный подход к раз­ра­бот­ке ПО про­явил свои недо­стат­ки [2], и в неко­то­рых ор­га­ни­за­ци­ях на­ча­ли экс­пе­ри­мен­ти­ро­вать с дру­ги­ми под­хо­да­ми, ко­то­рые в 2001 го­ду бы­ли обоб­ще­ны в «Ма­ни­фе­сте ско­рой раз­ра­бот­ки ПО».

Од­на из от­рас­лей, где ра­но уви­де­ли но­вый по­тен­ци­ал ИТ, — ин­ве­сти­ци­он­но-бан­ков­ский биз­нес. В ми­ре тор­гов тех­но­ло­гии — важ­ней­ший от­ли­чи­тель­ный фак­тор, и, как след­ствие, мно­гие по­став­щи­ки Ит­си­стем, пред­на­зна­чен­ных для вза­и­мо­дей­ствия с кли­ен­та­ми, в на­ча­ле 2000-х го­дов внед­ри­ли у се­бя ско­рые ме­то­ды раз­ра­бот­ки.

Еще один сег­мент, в ко­то­ром при­ме­ня­ли подход, ос­но­ван­ный на вза­и­мо­дей­ствии и ори­ен­та­ции на про­дукт, — это ин­тер­нет-ком­па­нии пе­ри­о­да бу­ма до­тко­мов. Ра­зу­ме­ет­ся, их по­сле­ду­ю­щий мас­со­вый крах и пуб­ли­ка­ции о ха­о­тич­ных ме­то­дах раз­ра­бот­ки и экс­плу­а­та­ции в зна­чи­тель­ной сте­пе­ни дис­кре­ди­ти­ро­ва­ли со­от­вет­ству­ю­щие прин­ци­пы, но все-та­ки, огля­ды­ва­ясь на­зад, мож­но прий­ти к вы­во­ду, что не так уж они бы­ли и непра­вы.

ДЛИТЕЛЬНОСТЬ ЦИК­ЛА — КЛЮ­ЧЕ­ВОЙ ФАК­ТОР

Ко­гда ком­па­ния ис­поль­зу­ет тех­но­ло­гии для по­лу­че­ния кон­ку­рент­но­го от­ли­чия или ко­гда тех­но­ло­гии — это ос­но­ва биз­не­са, важ­ней­шим фак­то­ром ста­но­вит­ся длительность цик­ла раз­ра­бот­ки. Чем быст­рее ком­па­ния мо­жет при­нять но­вую идею и пре­вра­тить ее в ра­бо­чую вер­сию ПО, тем луч­ше.

Рань­ше в ор­га­ни­за­ци­ях в первую оче­редь фо­ку­си­ро­ва­лись на двух фак­то­рах: на­деж­но­сти про­цес­са со­зда­ния ра­бо­че­го ПО для вы­пол­не­ния биз­нес-тре­бо­ва­ний и про­пуск­ной спо­соб­но­сти (воз­мож­но­сти ре­а­ли­зо­вать мак­си­маль­ное ко­ли­че­ство функ­ций си­ла­ми име­ю­щей­ся груп­пы раз­ра­бот­чи­ков). Здесь умест­но упо­мя­нуть вы­ска­зы­ва­ние «нель­зя недо­оце­ни­вать про­пуск­ную спо­соб­ность фур­го­на, пе­ре­во­зя­ще­го го­ру лен­точ­ных кар­три­джей»: вы­со­кая про­пуск­ная спо­соб­ность не имеет свя­зи с ма­лой дли­тель­но­стью цик­ла. На са­мом де­ле во мно­гих ор­га­ни­за­ци­ях улуч­ши­ли или пы­та­лись улуч­шить на­деж­ность и про­пуск­ную спо­соб­ность, за­пла­тив за это уве­ли­че­ни­ем дли­тель­но­сти цик­ла. И на­обо­рот: ор­га­ни­за­ции, со­сре­до­то­чив­ши­е­ся на дли­тель­но­сти цик­ла, не мо­гут про­сто иг­но­ри­ро­вать на­деж­ность и про­пуск­ную спо­соб­ность, то есть они вы­нуж­де­ны ис­кать подход, поз­во­ля­ю­щий улуч­шить все три ха­рак­те­ри­сти­ки. Ос­но­ва та­ко­го под­хо­да — тес­ное вза­и­мо­дей­ствие.

Ме­то­ды Agile-раз­ра­бот­ки ос­но­ва­ны на вза­и­мо­дей­ствии и вво­дят ко­рот­кие цик­лы об­рат­ной свя­зи на мно­гих эта­пах про­ек­та. Вы­пус­кая ре­лиз ПО, ко­то­рый еще не за­вер­шен, но уже при­го­ден для при­ме­не­ния, вы по­лу­ча­е­те от­зы­вы от ре­аль­ных поль­зо­ва­те­лей и кли­ен­тов. Эти от­зы­вы ис­поль­зу­ют­ся раз­ра­бот­чи­ка­ми, что поз­во­ля­ет уве­ли­чить на­деж­ность го­то­во­го про­дук­та. Про­пуск­ная спо­соб­ность то­же по­вы­ша­ет­ся, по­сколь­ку не тра­тят­ся уси­лия на ре­а­ли­за­цию ненуж­ных функ­ций. Эту кон­цеп­цию неред­ко на­зы­ва­ют ми­ни­ми­за­ци­ей от­хо­дов, ис­поль­зуя тер­мин, по­за­им­ство­ван­ный из бе­реж­ли­во­го про­из­вод­ства [3].

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

БОЛЬ­ШЕ ЧЕМ AGILE-РАЗ­РА­БОТ­КА

По­сле мно­го­чис­лен­ных внед­ре­ний прин­ци­пов Agile, при­мер­но в 2008 го­ду, ста­ло яс­но, что про­цесс раз­ра­бот­ки ПО по-преж­не­му имеет недо­стат­ки, ко­то­рые необ­хо­ди­мо устра­нить, что­бы умень­шить длительность цик­ла. С од­ной сто­ро­ны, хо­ро­шо про­те­сти­ро­ван­ное непре­рыв­но ин­те­гри­ру­е­мое ПО, на­хо­дясь толь­ко в си­сте­ме управ­ле­ния вер­си­я­ми, не при­но­сит поль­зы биз­не­су — ПО долж­но на­хо­дить­ся в ра­бо­чей экс­плу­а­та­ции, при­чем путь к ней дол­жен быть ко­рот­ким и сво­бод­ным от пре­пят­ствий, что обыч­но бы­ло не так. С дру­гой сто­ро­ны, пред­ста­ви­те­ли биз­не­са ча­сто не бы­ли спо­соб­ны опи­сать раз­ра­бот­чи­кам тре­бо­ва­ния к си­сте­ме, ко­то­рая им нужна, неза­ви­си­мо от то­го, при­ме­ня­ет­ся Agile или нет.

Он­лайн-стар­та­пы, часть из ко­то­рых уже вы­рос­ли в ги­ган­тов рын­ка, на­учи­ли то­му, что нуж­но пе­ре­хо­дить от про­ект­ной ори­ен­та­ции к ори­ен­та­ции на про­дукт. Жиз­нен­ный цикл ПО уже не де­лит­ся на чет­ко очер­чен­ные эта­пы, за каж­дый из ко­то­рых от­ве­ча­ет от­дель­ная груп­па: гра­ни­цы групп из­ме­ни­лись, од­на и та же груп­па несет ответственность за непре­рыв­ную эво­лю­цию ПО и его экс­плу­а­та­цию. Вер­нер Фо­гельс, ди­рек­тор по тех­но­ло­ги­ям Amazon, обоб­щил этот прин­цип так: за­пус­кай­те сра­зу по­сле сбор­ки. Кросс-функ­ци­о­наль­ные груп­пы обыч­но ком­пакт­ны (8–12 участ­ни­ков), что поз­во­ля­ет им со­хра­нять фо­кус на кон­крет­ном ас­пек­те со­зда­ва­е­мо­го про­дук­та. Од­ной из пер­вых ком­па­ний, внед­рив­ших эти кон­цеп­ции и взяв­ших­ся за по­иск стра­те­гий их мас­шта­би­ро­ва­ния, ста­ла Spotify.

Ес­ли стар­та­пам сле­до­ва­ние этим прин­ци­пам да­ва­лось от­но­си­тель­но лег­ко, то круп­ные пред­при­я­тия за­дер­жа­лись с пе­ре­хо­дом в но­вую эпо­ху, ведь осва­и­вать Agile-раз­ра­бот­ку бы­ло непро­сто. За­ме­на ко­манд, сфор­ми­ро­ван­ных по прин­ци­пу спе­ци­а­ли­за­ции (на­при­мер, в об­ла­сти баз дан­ных, поль­зо­ва­тель­ских ин­тер­фей­сов и сер­вер­ной ча­сти), на кросс-функ­ци­о­наль­ные груп­пы встре­ча­ла со­про­тив­ле­ние. Объ­еди­не­ние раз­ра­бот­ки и экс­плу­а­та­ции да­ва­лось ис­клю­чи­тель­но труд­но, по­сколь­ку во мно­гих слу­ча­ях они бы­ли стро­го раз­де­ле­ны, и до­хо­ди­ло до то­го, что за тот и дру­гой про­цесс мог­ли от­ве­чать разные по­став­щи­ки, воз­мож­но, на­хо­дя­щи­е­ся на разных кон­ти­нен­тах.

DEVOPS И DESIGNOPS

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

жа­ли уро­вень вза­и­мо­дей­ствия и удли­ня­ли длительность цик­ла.

Как и в случае Agile-ме­то­дов раз­ра­бот­ки, внед­ре­ние прин­ци­пов Devops бы­ло ини­ци­и­ро­ва­но са­ми­ми прак­ти­ка­ми и имен­но для раз­ре­ше­ния упо­мя­ну­тых кон­флик­тов. Важ­ную роль в этом сыг­ра­ли кон­фе­рен­ции се­рии Devopsdays, ко­то­рые на­ча­ли про­во­дить в 2009 го­ду. С од­ной сто­ро­ны, про­бле­му хо­ро­шо по­ни­ма­ли, с дру­гой, прак­ти­че­ских ре­ше­ний бы­ло ма­ло. Тем не ме­нее прак­ти­ки на­ча­ли ис­кать воз­мож­но­сти пе­ре­хо­да на мо­дель, ко­то­рая не толь­ко бы до­пус­ка­ла, но и спо­соб­ство­ва­ла вза­и­мо­дей­ствию меж­ду груп­па­ми раз­ра­бот­ки и экс­плу­а­та­ции.

Сред­ства Devops, а имен­но на­бор ме­то­дов и ин­стру­мен­тов непре­рыв­ной по­став­ки ПО, по­мог­ли рас­чи­стить путь к про­мыш­лен­ной экс­плу­а­та­ции. В луч­ших слу­ча­ях от­дель­ные бло­ки функ­ци­о­наль­но­сти, опи­сан­ные в «поль­зо­ва­тель­ских ис­то­ри­ях», мож­но раз­ра­бо­тать и вве­сти в ра­бо­чую экс­плу­а­та­цию все­го за день-два, а не за неде­ли и ме­ся­цы. Се­год­ня об­шир­ные от­де­лы ИТ, со­сто­я­щие из мно­гих про­дук­то­вых групп, спо­соб­ны каждую неде­лю за­пус­кать в ра­бо­чую экс­плу­а­та­цию сот­ни ре­ли­зов свя­зан­ных эле­мен­тов про­грамм­ных си­стем. Воз­мож­ность ра­ди­каль­но­го со­кра­ще­ния дли­тель­но­сти цик­ла по­бу­ди­ла мно­гие ор­га­ни­за­ции к внед­ре­нию Devops. На­при­мер, в от­че­те State of Devops 2014 го­да при­во­дят­ся дан­ные, под­твер­жда­ю­щие, что вы­со­кая про­из­во­ди­тель­ность от­де­ла ИТ кор­ре­ли­ру­ет с вы­со­кой ре­зуль­та­тив­но­стью биз­не­са.

Длительность цик­ла — это вре­мя меж­ду по­яв­ле­ни­ем идеи и ее во­пло­ще­ни­ем в ви­де про­грамм­но­го обес­пе­че­ния, вве­ден­но­го в ра­бо­чую экс­плу­а­та­цию. Поль­зо­ва­тель­ские ис­то­рии в Agile-раз­ра­бот­ке — это уже нечто го­раз­до боль­шее, чем идея, од­на­ко во мно­гих ор­га­ни­за­ци­ях, внед­рив­ших Agile, ис­пы­ты­ва­ют слож­но­сти с гра­мот­ным со­став­ле­ни­ем поль­зо­ва­тель­ских ис­то­рий. Неред­ко это при­во­дит к на­коп­ле­нию боль­шо­го объ­е­ма по­дроб­ных нере­а­ли­зо­ван­ных ис­то­рий, на­по­ми­на­ю­щих де­таль­ные тех­ни­че­ские за­да­ния из про­шлых вре­мен. Ре­ак­ци­ей на эту си­ту­а­цию ста­ли усо­вер­шен­ство­ва­ния, на­прав­лен­ные на из­на­чаль­ное улуч­ше­ние поль­зо­ва­тель­ских ис­то­рий.

Прак­ти­че­ски па­рал­лель­но с Devops по­яви­лось еще од­но дви­же­ние, свя­зан­ное с те­сти­ро­ва­ни­ем поль­зо­ва­тель­ских ин­тер­фей­сов не­по­сред­ствен­но в от­де­лах ИТ с рас­че­том на то, что­бы поль­зо­ва­тель­ские ис­то­рии от­ра­жа­ли ре­аль­ные по­треб­но­сти биз­не­са. Спе­ци­а­ли­сты по ин­тер­фей­сам при­внес­ли но­вые кон­цеп­ции, в том чис­ле ди­зайн-мыш­ле­ние и ис­сле­до­ва­ния по­тре­би­тель­ской ауди­то­рии, бла­го­да­ря ко­то­рым чис­ло цик­лов об­рат­ной свя­зи до­пол­ни­тель­но уве­ли­чи­лось. Кро­ме то­го, они внед­ри­ли прин­цип за­пи­си ги­по­тез о функ­ци­ях и их про­вер­ки с по­мо­щью дан­ных, со­бран­ных в про­цес­се ре­аль­но­го ис­поль­зо­ва­ния си­сте­мы, — этот ме­тод на­зва­ли «раз­ра­бот­кой с опо­рой на ги­по­те­зы» (hypothesis-driven development).

Се­год­ня, ак­тив­но пе­ре­ни­мая опыт Devops, ди­зай­не­ры про­дук­та и раз­ра­бот­чи­ки де­ла­ют ша­ги в на­прав­ле­нии бо­лее тес­но­го вза­и­мо­дей­ствия. Они ис­поль­зу­ют но­вые ин­стру­мен­ты, поз­во­ля­ю­щие им сов­мест­но ра­бо­тать над од­ни­ми и те­ми же тех­ни­че­ски­ми ар­те­фак­та­ми. Иногда этот прин­цип на­зы­ва­ют Designops. Он прак­ти­ку­ет­ся, в част­но­сти, в ком­па­нии Airbnb.

ОПОРНЫЕ МЕ­ТО­ДЫ И ТЕХ­НО­ЛО­ГИИ

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

Прин­ци­пы экс­тре­маль­но­го про­грам­ми­ро­ва­ния, осо­бен­но раз­ра­бот­ка с ори­ен­та­ци­ей на те­сти­ро­ва­ние (test-driven development), при­да­ли груп­пам раз­ра­бот­ки уве­рен­ность, необ­хо­ди­мую для ча­сто­го вы­пус­ка ре­ли­зов ПО, а от­сут­ствие непред­ска­зу­е­мых объ­еди­не­ний по­вы­си­ло на­деж­ность про­цес­са.

Сер­вис­ная ар­хи­тек­ту­ра, ко­то­рая позд­нее сме­ни­лась кон­цеп­ци­ей мик­ро­сер­ви­сов, предо­став­ля­ет воз­мож­ность неза­ви­си­мо­го раз­ви­тия ком­по­нен­тов. При ис­поль­зо­ва­нии та­кой ар­хи­тек­ту­ры неболь­шие кросс-функ­ци­о­наль­ные груп­пы мо­гут ра­бо­тать неза­ви­си­мо друг от дру­га над сво­ей ча­стью об­ще­го Ит-ре­ше­ния. Ме­то­ды те­сти­ро­ва­ния кон­трак­тов (consumerdriven-contract testing) и мик­рофрон­тен­дов (micro frontends) поз­во­ля­ют за­пус­кать сер­ви­сы в ра­бо­чую экс­плу­а­та­цию во­об­ще без те­сти­ро­ва­ния в сре­де ин­те­гра­ции. На са­мом де­ле у ор­га­ни­за­ций, ко­то­рые вы­пус­ка­ют ПО по мно­гу раз в день, про­сто нет воз­мож­но­сти вы­пол­нять об­сто­я­тель­ное ин­те­гра­ци­он­ное те­сти­ро­ва­ние в от­дель­ной сре­де.

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

Ко­гда раз­ра­бот­чи­ки и от­вет­ствен­ные за экс­плу­а­та­цию на­ча­ли тес­но со­труд­ни­чать, пер­вые ста­ли уве­ли­чи­вать сте­пень ав­то­ма­ти­за­ции. Руч­ная на­строй­ка сер­ве­ров усту­пи­ла ме­сто кон­цеп­ции «ин­фра­струк­ту­ры в ви­де ко­да». Скрип­ты, спо­соб­ные на­стро­ить всю ин­фра­струк­ту­ру раз­вер­ты­ва­ния, в том чис­ле про­грамм­но-кон­фи­гу­ри­ру­е­му­е­мую сеть, управ­ля­ют­ся по ана­ло­гии с ис­ход­ным ко­дом сер­ви­сов, ра­бо­та­ю­щих в та­кой ин­фра­струк­ту­ре. Ее пе­ре­строй­ка про­ис­хо­дит так же, как и вы­пуск но­вой вер­сии сер­ви­са, и ее мож­но вы­пол­нять с той же ско­ро­стью и на­деж­но­стью.

***

Ко­гда тех­но­ло­гия ста­но­вит­ся биз­не­сом или ко­гда биз­нес опи­ра­ет­ся на тех­но­ло­гии для вы­пус­ка на ры­нок ори­ги­наль­ной про­дук­ции, клю­че­вую роль на­чи­на­ют иг­рать прин­ци­пы вза­и­мо­дей­ствия. Се­год­ня про­изо­шел пе­ре­ход к неболь­шим кросс-функ­ци­о­наль­ным груп­пам, в ко­то­рых вза­и­мо­дей­ству­ют ин­же­не­ры раз­лич­ной спе­ци­а­ли­за­ции. Прин­ци­пы Devops и Designops обес­пе­чи­ва­ют бо­лее тес­ное со­труд­ни­че­ство меж­ду все­ми участ­ни­ка­ми жиз­нен­но­го цик­ла Ит-ре­ше­ния. В со­во­куп­но­сти с Agile-раз­ра­бот­кой они поз­во­ля­ют бо­лее эф­фек­тив­но вза­и­мо­дей­ство­вать биз­не­су и ИТ.

Ор­га­ни­за­ции, осво­ив­шие но­вые кон­цеп­ции, ис­поль­зу­ют свою Ит-сре­ду как циф­ро­вую плат­фор­му. Биз­нес-ори­ен­ти­ро­ван­ные сер­ви­сы, ко­то­рые мож­но быст­ро раз­ви­вать неза­ви­си­мо друг от дру­га, да­ют воз­мож­ность ча­сто выпускать на­деж­ные ре­ли­зы, что на­ко­нец сде­ла­ло ре­аль­но­стью дав­нюю меч­ту о ком­по­нен­тах, ко­то­рые мож­но ис­поль­зо­вать мно­го­крат­но и в раз­лич­ных со­че­та­ни­ях. Се­год­ня ор­га­ни­за­ции мо­гут раз­ви­вать­ся и внед­рять нов­ше­ства го­раз­до быст­рее, по­сколь­ку со­вре­мен­ный подход поз­во­ля­ет про­во­дить мас­штаб­ные экс­пе­ри­мен­ты.

Эво­лю­ция ро­ли ИТ на пред­при­я­тии: во мно­гих ком­па­ни­ях тех­но­ло­гии са­ми ста­ли биз­не­сом

Newspapers in Russian

Newspapers from Russia

© PressReader. All rights reserved.