6 ша­гов на пу­ти к успе­ху DevOps

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

Direktor informatsionnoj sluzhby - - СОДЕРЖАНИЕ - АДАМ БЕРТРАМ

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

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

ЧТО ПРЕД­СТАВ­ЛЯ­ЕТ СО­БОЙ DEVOPS?

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

ПУТЬ К DEVOPS

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

При пе­ре­строй­ке про­цент от­ка­зов ни­же, но ре­а­ли­за­ция слож­нее из-за ис­поль­зо­ва­ния ме­то­до­ло­гий па­рал­лель­но­го раз­вер­ты­ва­ния.

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

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

1. Под­го­тов­ка к куль­тур­ным пе­ре­ме­нам

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

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

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

2. Фор­ми­ро­ва­ние про­цес­са непре­рыв­ной ин­те­гра­ции, плат­фор­мы непре­рыв­но­го предо­став­ле­ния

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

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

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

Вот как это ра­бо­та­ет:

■ при из­ме­не­нии ко­да си­сте­ма управ­ле­ния вер­си­я­ми за­пус­ка­ет нуж­ный про­цесс на сер­ве­ре сбор­ки;

■ этот про­цесс ком­пи­ли­ру­ет код, объ­еди­няя все необ­хо­ди­мые для раз­вер­ты­ва­ния ре­сур­сы в па­ке­ты;

■ по­лу­чен­ные па­ке­ты ав­то­ма­ти­че­ски те­сти­ру­ют­ся для га­ран­тии ка­че­ства ко­да и его вы­пол­не­ния в со­от­вет­ствии с ожи­да­ни­я­ми;

■ ес­ли этап фик­са­ции за­вер­шил­ся успеш­но, при­ло­же­ние раз­вер­ты­ва­ет­ся в те­сто­вой сре­де, где изу­ча­ет­ся груп­пой кон­тро­ля ка­че­ства;

■ на­ко­нец, ко­гда при­ло­же­ние бу­дет одоб­ре­но, ре­лиз на­прав­ля­ет­ся непо­сред­ствен­но в про­из­вод­ство.

3. Со­зда­ние сре­ды непре­рыв­но­го те­сти­ро­ва­ния

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

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

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

К непре­рыв­но­му те­сти­ро­ва­нию при­ме­ни­мы сле­ду­ю­щие ре­ко­мен­да­ции:

■ ав­то­ма­ти­зи­руй­те про­це­ду­ры и эта­пы те­сти­ро­ва­ния в мак­си­маль­но воз­мож­ной сте­пе­ни (те­сти­ро­ва­ние вруч­ную необ­хо­ди­мо лишь при про­вер­ке удоб­ства ис­поль­зо­ва­ния и проб­ных ис­пы­та­ни­ях);

■ вы­де­ляй­те на­бо­ры те­стов для про­стых и быст­рых про­це­дур (раз­ра­бот­чи­ки мо­гут быст­ро вы­пол­нять по­блоч­ные те­сты пе­ред фик­са­ци­ей, а ин­те­гра­ци­он­ные те­сты мож­но вы­пол­нять на сер­ве­рах сбор­ки);

■ ве­ди­те рас­ши­рен­ные жур­на­лы;

■ начинайте те­сти­ро­ва­ние рань­ше и про­во­ди­те его ча­ще;

■ убе­ди­тесь в том, что вы ис­поль­зу­е­те до­ста­точ­ное чис­ло ме­то­дов кон­тро­ля ка­че­ства.

4. Внед­ре­ние си­сте­мы непре­рыв­но­го раз­вер­ты­ва­ния

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

По­сколь­ку про­вер­ка вруч­ную пе­ред раз­вер­ты­ва­ни­ем ко­да не вы­пол­ня­ет­ся, непрерывное раз­вер­ты­ва­ние вы­гля­дит несколь­ко пу­га­ю­ще.

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

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

При пра­виль­но ор­га­ни­зо­ван­ном кон­вей­е­ре до­став­ки си­сте­ма ав­то­ма­ти­че­ски ре­ша­ет, что и ко­гда фик­си­ро­вать в ре­по­зи­то­рии, что и ко­гда за­пус­кать в про­из­вод­ство и т. д.

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

5. Ис­поль­зо­ва­ние но­во­го и ста­ро­го раз­вер­ты­ва­ния

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

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

6. Не­пре­рыв­ный мо­ни­то­ринг про­из­во­ди­тель­но­сти

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

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

Раз­вер­ты­ва­ние. Ес­ли про­це­ду­ра ав­то­ма­ти­че­ско­го раз­вер­ты­ва­ния за­вер­ша­ет­ся неуда­чей, ну­жен ин­стру­мент, ко­то­рый пре­ду­пре­дит об этом со­от­вет­ству­ю­щих спе­ци­а­ли­стов. Боль­шин­ство сер­ве­ров непре­рыв­ной ин­те­гра­ции ав­то­ма­ти­че­ски пе­ре­сы­ла­ют со­об­ще­ния на сер­ве­ры ча­тов в слу­чае сбоя про­це­дур раз­вер­ты­ва­ния или сбор­ки. Уяз­ви­мо­сти. По­сле пе­ре­да­чи ко­да в про­из­вод­ство управ­ле­ние уяз­ви­мо­стя­ми сле­ду­ет осу­ществ­лять ав­то­ма­ти­че­ски. Не­важ­но, идет ли речь об из­вест­ных уяз­ви­мо­стях (при­сут­ству­ю­щих в National Vulnerability Database) или неиз­вест­ных (воз­ник­ших в ре­зуль­та­те небез­опас­ных дей­ствий), в лю­бом слу­чае си­сте­ма обя­за­на их об­на­ру­жи­вать и ми­ни­ми­зи­ро­вать по­след­ствия.

Со­сто­я­ние сер­ве­ров. Мо­ни­то­ринг сер­ве­ров име­ет важ­ное зна­че­ние прак­ти­че­ски для лю­бо­го ти­па ин­фра­струк­ту­ры, не толь­ко при ис­поль­зо­ва­нии DevOps. Про­из­во­ди­тель­ность и со­гла­ше­ния об уровне об­слу­жи­ва­ния (servicelevel agreements, SLA) си­сте­мы за­ви­сят от со­сто­я­ния сер­ве­ра. Есть несколь­ко ин­стру­мен­тов, по­мо­га­ю­щих ре­шать эту за­да­чу. Сле­ду­ет так­же осу­ществ­лять мо­ни­то­ринг ин­фра­струк­ту­ры. Про­из­во­ди­тель­ность при­ло­же­ний.

Для опре­де­ле­ния клю­че­вых мо­мен­тов про­из­во­ди­тель­но­сти и ре­грес­са при­ло­же­ний необ­хо­ди­мо сле­дить за их функ­ци­о­ни­ро­ва­ни­ем и свое­вре­мен­но при­ни­мать необ­хо­ди­мые ре­ше­ния. По­мо­жет вам в этом це­лый ряд ин­стру­мен­тов, в том чис­ле AppDynamics и New Relic. Ин­стру­мен­ты мо­ни­то­рин­га про­из­во­ди­тель­но­сти при­ло­же­ний (application performance monitoring, APM) предо­став­ля­ют до­пол­ни­тель­ную ин­фор­ма­цию о ха­рак­те­ре ис­поль­зо­ва­ния при­ло­же­ний и их про­из­во­ди­тель­но­сти.

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

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

КЛЮ­ЧЕ­ВЫЕ ИН­СТРУ­МЕН­ТЫ DEVOPS

Хо­тя во мно­гом успех DevOps за­ви­сит от ба­зо­вых куль­тур­ных сдви­гов, важ­ная роль от­во­дит­ся и ин­стру­мен­там. Вот крат­кий пе­ре­чень ин­стру­мен­тов, ко­то­рые, как пра­ви­ло, ис­поль­зу­ют­ся в сре­де DevOps:

■ ре­по­зи­то­рий ис­ход­но­го ко­да (Git, CloudForce, TFS, Subversion);

■ сер­вер сбор­ки (SonarQube, Jenkins, Artifactory);

■ управ­ле­ние кон­фи­гу­ра­ци­ей (Puppet, Ansible, Salt, Chef);

■ ав­то­ма­ти­за­ция те­сти­ро­ва­ния (Selenium, Water);

■ вир­ту­аль­ная ин­фра­струк­ту­ра (Amazon Web Services, Microsoft Azure, VMware vCloud).

***

Пе­ре­ход от тра­ди­ци­он­ной раз­ра­бот­ки про­грамм­но­го обес­пе­че­ния к DevOps – непро­стая за­да­ча, тре­бу­ю­щая зна­чи­тель­ных из­ме­не­ний внут­ри ор­га­ни­за­ции. Глав­ное здесь – пра­виль­но рас­пре­де­лить лю­дей меж­ду про­цес­са­ми и осна­стить их пра­виль­ны­ми ин­стру­мен­та­ми. И в слу­чае успеш­но­го при­ме­не­ния пе­ре­до­во­го опы­та при со­зда­нии ка­на­лов предо­став­ле­ния сер­ви­сов с непре­рыв­ной ин­те­гра­ци­ей, непре­рыв­ны­ми те­сти­ро­ва­ни­ем и раз­вер­ты­ва­ни­ем пе­ре­клю­че­ние на DevOps обе­ща­ет при­не­сти ва­шей ор­га­ни­за­ции не­ма­лую вы­го­ду.

Newspapers in Russian

Newspapers from Russia

© PressReader. All rights reserved.