Де­сять прин­ци­пов непре­рыв­но­го раз­вер­ты­ва­ния ПО

Otkrytye sistemy. SUBD. - - СОДЕРЖАНИЕ - Крис Пар­нин, Ло­ри Ви­льямс

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

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

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

За шесть лет чис­ло про­грам­ми­стов в Facebook вы­рос­ло в 20 раз, а раз­мер ко­до­вой ба­зы — в 50 раз [1], од­на­ко про­дук­тив­ность тру­да раз­ра­бот­чи­ков, из­ме­ря­е­мая чис­лом строк в еди­ни­цу вре­ме­ни, со­хра­ня­ет­ся на неиз­мен­ном уровне. В Facebook счи­та­ют это до­сти­же­ни­ем, свя­зы­вая его с при­ме­не­ни­ем ме­то­ди­ки непре­рыв­но­го раз­вер­ты­ва­ния(continuous Deployment), суть ко­то­рой — в ав­то­ма­ти­за­ции те­сти­ро­ва­ния ин­кре­мен­таль­ных из­ме­не­ний про­грамм­но­го обес­пе­че­ния и в опе­ра­тив­ном раз­вер­ты­ва­нии об­нов- лен­ных вер­сий на ра­бо­чей плат­фор­ме. При ра­бо­те в та­ком ре­жи­ме из­ме­не­ния, вно­си­мые про­грам­ми­ста­ми, мо­гут по­па­дать к кли­ен­там за счи­тан­ные дни или да­же ча­сы.

Пе­ре­ход на но­вые прин­ци­пы при­вел к мас­штаб­ным пе­ре­ме­нам в ми­ре раз­ра­бот­ки ПО, ока­зав силь­ное вли­я­ние на кор­по­ра­тив­ную куль­ту­ру, вос­тре­бо­ван­ные на­вы­ки со­труд­ни­ков и са­ми прин­ци­пы ра­бо­ты в ор­га­ни­за­ци­ях. Сов­мест­ное ис­сле­до­ва­ние этих из­ме­не­ний про­ве­ли спе­ци­а­ли­сты ком­па­ний Cisco, Facebook, Google, IBM, Lexisnexis, Microsoft, Mozilla, Netflix, Red Hat и SAS. В этот ряд во­шли как пер­во­про­ход­цы непре­рыв­но­го раз­вер­ты­ва­ния, на се­год­ня уже рас­по­ла­га­ю­щие со­от­вет­ству­ю­щи­ми зре­лы­ми про­цес­са­ми, так и ком­па­нии, ко­то­рым с уче­том их ар­хи­тек­тур­но­го бал­ла­ста по­тре­бу­ют­ся го­ды на ре­а­ли­за­цию со­от­вет­ству­ю­щих ини­ци­а­тив. Тем­пы раз­вер­ты­ва­ния ПО в пе­ре­чис­лен­ных ком­па­ни­ях раз­нят­ся от ты­ся­чи раз за день до двух раз за год, но все они стре­мят­ся уско­рять этот про­цесс, что­бы быст­рее предо­став­лять вы­со­ко­ка­че­ствен­ное ПО кли­ен­там. Для это­го при­ме­ня­ют­ся ме­то­ды слож­ной ана­ли­ти­ки, с по­мо­щью ко­то­рых во­до­па­ды дан­ных те­ле­мет­рии пре­об­ра­зу­ют­ся в по­лез­ную ин­фор­ма­цию, поз­во­ля­ю­щую со­вер­шен­ство­вать про­грамм­ные про­дук­ты.

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

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

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

КАЖ­ДАЯ ФУНК­ЦИЯ — ЭТО ЭКСПЕРИМЕНТ

В ос­но­ве бе­реж­ли­во­го про­из­вод­ства ле­жит эксперимент. Ес­ли нет дан­ных, оправ­ды­ва­ю­щих су­ще­ство­ва­ние той или иной функ­ции, то она дол­го не «про­жи­вет», и ее от­бра­сы­ва­ют, по­счи­тав эксперимент неудач­ным. Тра­ди­ци­он­но вы­бор функ­ци­о­на­ла про­ис­хо­дил по­сле тща­тель­ной пред­ва­ри­тель­ной оцен­ки: вы­бран­ные функ­ции умо­зри­тель­но про­ек­ти­ро­ва­лись, за­тем ре­а­ли­зо­вы­ва­лись и сда­ва­лись в экс­плу­а­та­цию, при этом ре­ше­ния ред­ко ос­но­вы­ва­лись на ре­аль­ных дан­ных. В усло­ви­ях непре­рыв­но­го раз­вер­ты­ва­ния раз­ра­бот­чи­ки от­но­сят­ся к каж­дой пла­ни­ру­е­мой функ­ции как к экс­пе­ри­мен­ту, и неко­то­рые уже вы­пу­щен­ные функ­ции впо­след­ствии от­ми­ра­ют. На­при­мер, ес­ли на сай­те Netflix до­ста­точ­ное чис­ло поль­зо­ва­те­лей не за­дер­жат­ся на но­вом эле­мен­те ин­тер­фей­са, то в рам­ках по­сле­ду­ю­щих экс­пе­ри­мен­тов его мо­гут пе­ре­ме­стить в дру­гое ме­сто экра­на или во­об­ще убрать. Как пра­ви­ло, в ком­па­ни­ях со­би­ра­ют ста­ти­сти­ку о всех ас­пек­тах вы­пус­ка­е­мо­го про­грамм­но­го обес­пе­че­ния. В част­но­сти, ре­ги­стри­ру­ют­ся по­ка­за­те­ли про­из­во­ди­тель­но­сти и ста­биль­но­сти ра­бо­ты, та­кие как вре­мя рен­де­рин­га стра­ниц, ча­сто­та до­сту­па к столб­цам ба­зы дан­ных, ис­клю­че­ния и ко­ды оши­бок, вре­мя от­кли­ка и ча­сто­та вы­зо­ва ме­то­дов API. Для сбо­ра этих све­де­ний ар­хи­тек­ту­ра раз­ра­ба­ты­ва­е­мо­го ПО долж­на быть из­на­чаль­но рас­счи­та­на на пе­ре­да­чу те­ле­мет­рии. Вме­сто ло­каль­но­го хра­не­ния жур­на­лов про­из­во­ди­тель­но­сти и оши­бок на сер­ве­ре со­от­вет­ству­ю­щие по­ка­за­те­ли по­то­ком пе­ре­да­ют­ся в цен­траль­ное хра­ни­ли­ще и сра­зу об­ра­ба­ты­ва­ют­ся в па­мя­ти. Кро­ме то­го, для нужд ана­ли­ти­ки в неко­то­рых ком­па­ни­ях со­дер­жат об­шир­ный штат спе­ци­а­ли­стов по дан­ным — до 30% от чис­лен­но­сти раз­ра­бот­чи­ков ПО. В та­ких ком­па­ни­ях со­зда­ет­ся и при­ме­ня­ет­ся ши­ро­кий спектр ин­стру­мен­тов ис­сле­до­ва­ния дан­ных, в том чис­ле са­мо­сто­я­тель­но раз­ра­бо­тан­ные язы­ки за­про­сов. При этом мно­гие ор­га­ни­за­ции стал­ки­ва­ют­ся с труд­но­стя­ми, свя­зан­ны­ми со стре­ми­тель­ным ис­чер­па­ни­ем воз­мож­но­стей ин­фра­струк­ту­ры для хра­не­ния дан­ных те­ле­мет­рии. Так, в Netflix вна­ча­ле ре­ги­стри­ро­ва­ли 1,2 млн раз­лич­ных по­ка­за­те­лей по служ­бам по­точ­ной пе­ре­да­чи ви­део, но уже ско­ро их чис­ло до­стиг­ло мил­ли­ар­да. Ре­сур­сов хра­ни­ли­ща уже не хва­та­ло, при­хо­ди­лось бо-

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

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

СТО­И­МОСТЬ ИЗ­МЕ­НЕ­НИЯ Не РАС­ТЕТ

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

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

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

ТОРОПИТЕСЬ С РАЗ­ВЕР­ТЫ­ВА­НИ­ЕМ, А Не С ВЫПУСКОМ

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

До­пу­стим, в Instagram ре­ши­ли ре­а­ли­зо­вать нов­ше­ство — ветв­ле­ние дис­кус­сий в ком­мен­та­ри­ях к по­стам. Мож­но вне­сти со­от­вет­ству­ю­щий код в ра­бо­чую си­сте­му, но предо­ста­вить до­ступ к но­вой функ­ции лишь уз­кой груп­пе поль­зо­ва­те­лей для те­сти­ро­ва­ния и оцен­ки. Это на­зы­ва­ют «тем­ным за­пус­ком» (dark launch), ко­то­рый поз­во­ля­ет раз­ра­бот­чи­ку нето­роп­ли­во раз­вер­ты­вать и до­ра­ба­ты­вать неболь­шие фраг­мен­ты ко­да в ра­бо­чей сре­де, не ока­зы­вая вли­я­ния на об­слу­жи­ва­ние поль­зо­ва­те­лей. По­сле ста­би­ли­за­ции ко­да мож­но уже ак­ти­ви­ро­вать функ­цию и вы­пу­стить ее в про­мыш­лен­ную экс­плу­а­та­цию.

В Instagram «тем­ный за­пуск» при­ме­ня­ет­ся до­воль­но ча­сто, при­чем функ­ции пе­ред офи­ци­аль­ным ре­ли­зом мо­гут до­ра­ба­ты­вать до по­лу­го­да. В Microsoft ре­гу­ляр­но раз­вер­ты­ва­ют круп­ные ар­хи­тек­тур­ные из­ме­не­ния, при­бе­гая к «тем­но­му за­пус­ку» в со­че­та­нии с флаж­ка­ми функ­ций (feature flag). Флаж­ки поз­во­ля­ют раз­вер­ты­вать функ­ции в ра­бо­чей си­сте­ме, но от­клю­чать их до тех пор, по­ка они не бу­дут го­то­вы к вы­пус­ку; от­клю­че­ние и вклю­че­ние вы­пол­ня­ют­ся че­рез сер­вер кон­фи­гу­ра­ции. Поль­зу­ясь эти­ми при­е­ма­ми, в Microsoft из­бе­га­ют про­блем, свя­зан­ных с ин­те­гра­ци­ей и дол­го­сроч­ным со­про­вож­де­ни­ем функ­ци­о­наль­ных вет­вей. Ран­нее и ча­стое раз­вер­ты­ва­ние из­ме­не­ний в ра­бо­чей сре­де в це­лом поз­во­ля­ет сни­зить уро­вень слож­но­сти со­от­вет­ству­ю­щих про­це­дур.

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

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

ВКЛАДЫВАЙТЕСЬ В ВЫЖИВАНИЕ

Что­бы вы­жить в усло­ви­ях со­вре­мен­но­го рын­ка, необ­хо­ди­мо ин­ве­сти­ро­вать в ин-

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

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

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

ЗА ПОД­ДЕРЖ­КУ ОТ­ВЕ­ЧА­ЕТ САМ РАЗ­РА­БОТ­ЧИК

При непре­рыв­ном раз­вер­ты­ва­нии раз­ра­бот­чи­ки име­ют воз­мож­ность и пра­во вно­сить из­ме­не­ния в ра­бо­чую си­сте­му, од­на­ко боль­ше вла­сти озна­ча­ет и боль­ше от­вет­ствен­но­сти. Ес­ли код в ра­бо­чем ре­жи­ме даст сбой, кто за это от­ве­ча­ет — раз­ра­бот­чи­ки или спе­ци­а­ли­сты по экс­плу­а­та­ции? Тра­ди­ци­он­ные ме­то­ды раз­ра­бот­ки ПО не поз­во­ля­ют на­ве­сти по­ря­док в рас­пре­де­ле­нии от­вет­ствен­но­сти: раз­ра­бот­чи­ки «пе­ре­бра­сы­ва­ют код че­рез сте­ну» в от­дел кон­тро­ля ка­че­ства, а там, в свою оче­редь, мо­гут «пе­ре­ки­ды­вать» его даль­ше спе­ци­а­ли­стам по экс­плу­а­та­ции. Ряд участ­ни­ков опро­са по­жа­ло­ва­лись на раз­ра­бот­чи­ков, ко­то­рые не утруж­да­ют се­бя тем, что­бы вни­ма­тель­но озна­ко­мить­ся с тре­бо­ва­ни­я­ми к со­зда­ва­е­мо­му ПО, от­кли­ка­ми поль­зо­ва­те­лей и воз­мож­но­стя­ми ра­бо­чей сре­ды.

Ко­гда раз­ра­бот­чик яв­ля­ет­ся вла­дель­цем функ­ции или из­ме­не­ния ко­да на всем цик­ле от ре­а­ли­за­ции до раз­вер­ты­ва­ния, на нем ле­жит и весь груз от­вет­ствен­но­сти. Это озна­ча­ет, что при непо­лад­ках имен­но он по­лу­ча­ет за­прос о под­держ­ке и обя­зан устра­нить про­бле­му неза­ви­си­мо от вре­ме­ни су­ток. В этом слу­чае тра­ди­ци­он­ная струк­ту­ра ра­бо­че­го кол­лек­ти­ва ста­но­вит­ся уже неак­ту­аль­ной. В Netflix, на­при­мер, во­об­ще нет спе­ци­аль­ных групп, от­ве­ча­ю­щих за экс­плу­а­та­цию. Функ­ци­о­наль­ные ро­ли, та­кие как кон­троль ка­че­ства и экс­плу­а­та­ция, по-преж­не­му есть, но за их вы­пол­не­ние от­ве­ча­ют са­ми раз­ра­бот­чи­ки: фор­ми­ру­ют­ся сот­ни сла­бо свя­зан­ных, но жест­ко ко­ор­ди­ни­ру­е­мых ко­манд. От­дель­ных струк­тур, за­ни­ма­ю­щих­ся кон­тро­лем ка­че­ства, экс­плу­а­та­ци­ей и раз­ра­бот­кой, нет, но в каж­дой груп­пе есть спе­ци­а­ли­сты всех со­от­вет­ству­ю­щих про­фи­лей. В Instagram при­шли к вы­во­ду, что оп­ти­маль­ны груп­пы, участ­ни­ки ко­то­рых спе­ци­а­ли­зи­ру­ют­ся в раз­ных об­ла­стях, но при этом яв­ля­ют­ся вла­дель­ца­ми опре­де­лен­ных функ­ций си­сте­мы на про­тя­же­нии все­го их жиз­нен­но­го цик­ла. В Instagram и Red Hat прак­ти­ку­ют ро­та­цию обя­зан­но­стей, ко­гда каж­дый участ­ник груп­пы часть сво­е­го вре­ме­ни тра­тит на тех­ни­че­скую под­держ­ку, что поз­во­ля­ет рав­но­мер­но рас­пре­де­лять со­от­вет­ству­ю­щую на­груз­ку.

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

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

КОНФИГУРАЦИЯ — ЭТО КОД

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

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

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

Со­вре­мен­ные сред­ства кон­фи­гу­ра­ци­он­но­го управ­ле­ния, та­кие как Ansible, Puppet, Chef и Salt, поз­во­ля­ют ав­то­ма­ти­зи­ро­вать со­от­вет­ству­ю­щие за­да­чи и обес­пе­чи­вать их ор­кест­ров­ку на всех сер­ве­рах с по­мо­щью скрип­тов.

Се­год­ня нор­мой ста­ли про­цес­сы кон­фи­гу­ра­ци­он­но­го управ­ле­ния, ана­ло­гич­ные управ­ле­нию функ­ци­я­ми и ко­дом. В Netflix, к при­ме­ру, при каж­дой фик­са­ции ко­да в про­цес­се сбор­ки со­зда­ет­ся па­кет Debian, в ко­то­ром ука­за­ны все необ­хо­ди­мые за­ви­си­мо­сти, а за­тем все они уста­нав­ли­ва­ют­ся на но­вый об­раз вир­ту­аль­ной ма­ши­ны Amazon Web Services. Участ­ни­ки опро­са из Facebook и Netflix от­ме­ти­ли, что да­же при на­ли­чии необ­хо­ди­мой оснаст­ки из­ме­не­ния кон­фи­гу­ра­ции мо­гут вы­звать труд­ные в от­лад­ке ошиб­ки. В Netflix вно­сят по­ряд­ка 60 тыс. из­ме­не­ний в день, но си­сте­мы от­сле­жи­ва­ния и кон­тро­ля из­ме­не­ний у ком­па­нии нет. Как след­ствие, ком­па­ния неред­ко «са­ма стре­ля­ет се­бе в но­гу». В Red Hat, в свою оче­редь, вы­яс­ни­ли, что, как и в слу­чае с об­шир­ны­ми ко­до­вы­ми ба­за­ми, об­шир­ные кон­фи­гу­ра­ци­он­ные ба­зы мо­гут вы­хо­дить из-под кон­тро­ля.

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

УСПОКАИВАЙТЕ ЗА­КАЗ­ЧИ­КОВ, ВЗАИМОДЕЙСТВУЯ С НИ­МИ

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

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

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

ОГЛЯДЫВАЙТЕСЬ НА­ЗАД, ЧТО­БЫ ПРОДВИГАТЬСЯ ВПЕ­РЕД

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

Для ана­ли­за по­доб­ных сбо­ев во всех ком­па­ни­ях про­во­дят ре­тро­спек­тив­ные со­бра­ния («вскры­тия»), на ко­то­рых участ­ни­ки груп­пы об­суж­да­ют при­чи­ны и по­след­ствия непред­ви­ден­ных про­сто­ев и неудач­ных раз­вер­ты­ва­ний, а так­же из­ме­не­ния про­цес­сов. Ряд ре­спон­ден­тов рас­ска­за­ли о соб­ствен­ном опы­те уча­стия в ре­тро­спек­тив­ных со­бра­ни­ях. В Netflix раз­ра­бот­чик со­об­ща­ет о пе­ре­бо­ях в си­сте­ме уче­та про­блем, ста­вя оцен­ку уров­ня их се­рьез­но­сти. Ре­ги­стри­руя пе­ре­бои, раз­ра­бот­чи­ки за­тем мо­гут вы­пол­нять ме­та­а­на­лиз на­коп­лен­ных дан­ных, что поз­во­ля­ет об­на­ру­жи­вать тен­ден­ции и си­сте­ма­ти­че­ские недо­че­ты в ор­га­ни­за­ции про­цес­са раз­ра­бот­ки. Се­рьез­ные пе­ре­бои об­суж­да­ют­ся на еже­не­дель­ных ре­тро­спек­тив­ных со­бра­ни­ях с уча­сти­ем пред­ста­ви­те­лей мно­же­ства групп.

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

смысл пред­ло­жить ви­нов­ни­ку сбоя во­об­ще не участ­во­вать в со­ве­ща­нии. Так или ина­че, в ря­де ком­па­ний от­ме­ти­ли су­ще­ствен­ное сни­же­ние ко­ли­че­ства оши­бок по­сле на­ча­ла про­ве­де­ния «вскры­тий».

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

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

БЕЗ­ОПАС­НОСТЬ И КОН­ФИ­ДЕН­ЦИ­АЛЬ­НОСТЬ — ЧАСТЬ ОБ­ЩЕ­ГО ПРО­ЦЕС­СА

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

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

В Facebook из­ме­не­ния ко­да, спо­соб­ные по­вли­ять на кон­фи­ден­ци­аль­ность, про­хо­дят бо­лее дли­тель­ный про­цесс вы­пус­ка, чем стан­дарт­ный, за­ни­ма­ю­щий обыч­но день. Кро­ме то­го, от­дель­ная груп­па ин­же­не­ров за­ни­ма­ет­ся раз­ра­бот­кой слоя до­сту­па ко всем дан­ным и сред­ствам управ­ле­ния, на ко­то­ром вы­пол­ня­ет­ся кон­троль со­блю­де­ния нор­ма­тив­ных тре­бо­ва­ний и кон­фи­ден­ци­аль­но­сти. В Google при­ме­ня­ют ме­ры кон­тро­ля без­опас­но­сти раз­вер­ты­ва­ния: вве­ли обя­за­тель­ную ав­то­ри­за­цию поль­зо­ва­те­лей, пе­ре­да­ю­щих код для раз­вер­ты­ва­ния, про­во­дят стро­гий кон­троль до­сту­па и про­вер­ку кон­троль­ных сумм дво­ич­ных фай­лов. Кро­ме то­го, в ком­па­нии обес­пе­чи­ва­ют на­деж­ную изо­ля­цию ра­бо­чей се­ти от кор­по­ра­тив­ной; в част­но­сти, ра­бо­чая сеть со­сто­ит толь­ко из сер­ве­ров — от­сут­ствие ра­бо­чих стан­ций сни­жа­ет ве­ро­ят­ность зло­на­ме­рен­но­го вме­ша­тель­ства в уже раз­вер­ну­тый код.

НО­ВАЯ ЭПО­ХА НА­СТУ­ПА­ЕТ НЕЗА­ВИ­СИ­МО ОТ ВА­ШЕЙ ГО­ТОВ­НО­СТИ

Ва­ши кон­ку­рен­ты по­сто­ян­но со­вер­шен­ству­ют свои про­дук­ты. А вы? Все участ­ни­ки ис­сле­до­ва­ния при­зна­ли, что се­год­ня для со­хра­не­ния кон­ку­рен­то­спо­соб­но­сти необ­хо­ди­мо обес­пе­чить быст­рый вы­пуск все но­вой функ­ци­о­наль­но­сти. Опрос, про­ве­ден­ный ком­па­ни­ей CA Technologies еще в 2015 го­ду, по­ка­зал, что 88% ре­спон­ден- тов уже внед­ри­ли кон­цеп­цию Devops, име­ю­щую схо­жие ме­то­ды с непре­рыв­ным раз­вер­ты­ва­ни­ем, а неко­то­рые да­же нефор­маль­но при­рав­ни­ва­ют их. В Puppet Labs про­ве­ли ан­ке­ти­ро­ва­ние с уча­сти­ем 4976 ре­спон­ден­тов, со­глас­но ре­зуль­та­там ко­то­ро­го, в Ит-служ­бах, взяв­ших на во­ору­же­ние Devops, бы­ло в 60 раз мень­ше сбо­ев, а ча­сто­та раз­вер­ты­ва­ний ока­за­лась в 30 раз вы­ше. В пя­тер­ку об­ла­стей, где Devops ис­поль­зу­ет­ся ши­ре все­го, вхо­дят ИТ, раз­ра­бот­ка веб-при­ло­же­ний, финансы и связь. Ро­сту по­пу­ляр­но­сти Devops спо­соб­ству­ет вклю­че­ние в чис­ло клю­че­вых по­ка­за­те­лей про­из­во­ди­тель­но­сти та­ких фак­то­ров, как рост кли­ен­ту­ры, вза­и­мо­дей­ствие меж­ду от­де­ла­ми, улуч­ше­ние ка­че­ства и функ­ци­о­наль­но­сти ПО, а так­же уско­ре­ние тех­ни­че­ско­го об­слу­жи­ва­ния.

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

ЛИТЕРАТУРА ***

1. T. Savor et al. Continuous Deployment at Facebook and OANDA, Proc. 38th Int’l Conf. Software Eng. Companion. — 2016. — P. 21–30.

2. M. Marschall. Transforming a Six Month Release Cycle to Continuous Flow, Proc. 2007 Agile Conf. (Agile 07). — 2007. — P. 395–400. 3. R. Torkar, P. Minoves, J. Garrigos. Adopting Free/libre/open Source Software Practices, Techniques and Methods for Industrial Use // J. Assoc. for Information Systems. — 2011. Vol. 12, N. 1, article 1.

Крис Пар­нин (cjparnin@ncsu.edu),

Ло­ри Ви­льямс (lawilli3@ncsu.edu) — со­труд­ни­ки Уни­вер­си­те­та шта­та Се­вер­ная Ка­ро­ли­на, воз­глав­ля­ю­щие кол­лек­тив ав­то­ров ста­тьи из ком­па­ний IBM, Red Hat, Cisco Systems, Mozilla, Netflix, SAS, Google, Lexisnexis, Microsoft, Facebook.

Ча­сто­та ис­поль­зо­ва­ния 11 ме­то­дов непре­рыв­но­го раз­вер­ты­ва­ния

Newspapers in Russian

Newspapers from Russia

© PressReader. All rights reserved.