Да ли је тешко схватити главну поенту када говоримо о ДевОпс-у? Прикупили смо за вас живописне аналогије, упечатљиве формулације и савете стручњака који ће чак и неспецијалистима помоћи да дођу до ствари. На крају, бонус је сопствени ДевОпс запослених у Ред Хату.
Термин ДевОпс настао је пре 10 година и од хасхтаг-а на Твитеру постао је моћан културни покрет у ИТ свету, истинска филозофија која подстиче програмере да ствари раде брже, експериментишу и понављају. ДевОпс је постао нераскидиво повезан са концептом дигиталне трансформације. Али као што се често дешава са ИТ терминологијом, у протеклих десет година ДевОпс је стекао многе дефиниције, тумачења и погрешне представе о себи.
Стога често можете чути питања о ДевОпс-у као што је, да ли је то исто што и агиле? Или је ово нека посебна методологија? Или је то само још један синоним за реч „сарадња“?
ДевОпс укључује много различитих концепата (континуирана испорука, континуирана интеграција, аутоматизација, итд.), тако да откривање онога што је важно може бити изазов, посебно када сте страствени у вези са том темом. Међутим, ова вештина је веома корисна, без обзира да ли покушавате да своје идеје пренесете надређенима или једноставно некоме из породице или пријатеља говорите о свом послу. Стога, оставимо по страни терминолошке нијансе ДевОпс-а за сада и фокусирамо се на ширу слику.
Шта је ДевОпс: 6 дефиниција и аналогија
Замолили смо стручњаке да што једноставније и краће објасне суштину ДевОпс-а како би његова вредност постала јасна читаоцима са било којим нивоом техничког знања. На основу резултата ових разговора, одабрали смо најупечатљивије аналогије и упечатљиве формулације које ће вам помоћи да изградите своју причу о ДевОпс-у.
1. ДевОпс је културни покрет
„ДевОпс је културни покрет у којем обе стране (програмери софтвера и стручњаци за операције ИТ система) препознају да софтвер не доноси стварне користи док неко не почне да га користи: купци, клијенти, запослени, а не поента,“ каже Евелине Оехрлицх, виши истраживач аналитичар на ДевОпс институту. „Стога, обе ове стране заједно обезбеђују брзу и квалитетну испоруку софтвера.
2. ДевОпс се односи на оснаживање програмера.
„ДевОпс омогућава програмерима да поседују апликације, покрећу их и управљају испоруком од почетка до краја.“
„Обично се о ДевОпс-у говори као о начину да се убрза испорука апликација у производњу изградњом и имплементацијом аутоматизованих процеса“, каже Јаи Сцхниепп, директор ДевОпс платформи у осигуравајућој компанији Либерти Мутуал. "Али за мене је то много фундаменталнија ствар." ДевОпс омогућава програмерима да поседују апликације или одређене делове софтвера, покрећу их и управљају њиховом испоруком од почетка до краја. ДевОпс елиминише конфузију у вези са одговорношћу и води све који су укључени у креирање аутоматизоване инфраструктуре коју воде програмери.”
3. ДевОпс се односи на сарадњу у креирању и испоруци апликација.
„Једноставно речено, ДевОпс је приступ производњи и испоруци софтвера где сви раде заједно“, каже Гур Стаф, председник и шеф аутоматизације дигиталног пословања у БМЦ-у.
4. ДевОпс је цевовод
„Састављање транспортера је могуће само ако се сви делови уклапају заједно.“
„Упоредио бих ДевОпс са линијом за склапање аутомобила“, наставља Гур Стафф. – Идеја је да се сви делови дизајнирају и направе унапред како би се потом могли саставити без индивидуалног прилагођавања. Монтажа транспортера је могућа само ако се сви делови уклапају заједно. Они који пројектују и праве мотор морају да размисле како да га монтирају на каросерију или оквир. Они који праве кочнице морају да мисле на точкове итд. Исто би требало да важи и за софтвер.
Програмер који креира пословну логику или кориснички интерфејс мора размишљати о бази података у којој се чувају информације о клијентима, безбедносним мерама за заштиту корисничких података и како ће све ово функционисати када услуга почне да служи великој, можда чак и вишемилионској корисничкој публици ."
„Натерати људе да сарађују и размишљају о деловима посла које други раде, уместо да се фокусирају само на сопствене задатке, највећа је препрека коју треба превазићи. Ако то можете да урадите, имате одличне шансе за дигиталну трансформацију“, додаје Гур Стафф.
5. ДевОпс је права комбинација људи, процеса и аутоматизације
Џејн Грол, извршна директорка ДевОпс института, понудила је одличну аналогију да објасни ДевОпс. Према њеним речима, „ДевОпс је као рецепт са три главне категорије састојака: људи, процес и аутоматизација. Већина ових састојака може се преузети из других области и извора: Леан, Агиле, СРЕ, ЦИ/ЦД, ИТИЛ, лидерство, култура, алати. Тајна ДевОпс-а, као и сваког доброг рецепта, је како да добијете праве пропорције и мешавину ових састојака да бисте повећали брзину и ефикасност креирања и пуштања апликација.”
6. ДевОпс је када програмери раде као тим Формуле 1
„Трка није планирана од почетка до краја, већ напротив, од циља до старта.
„Када говорим о томе шта да очекујем од ДевОпс иницијативе, мислим на тркачки тим НАСЦАР или Формуле 1 као пример“, каже Цхрис Схорт, виши менаџер маркетинга платформи у облаку у Ред Хат-у и издавач ДевОпс-овог билтена. – Вођа таквог тима има један циљ: да заузме што је могуће више место на крају трке, узимајући у обзир ресурсе који су тиму на располагању и изазове који су га задесили. У овом случају, трка се планира не од почетка до краја, већ напротив, од циља до старта. Прво се поставља амбициозан циљ, а затим се одређују начини за његово постизање. Затим се деле на подзадатке и делегирају члановима тима."
„Тим проведе целу недељу пре трке усавршавајући пит стоп. Ради тренинге снаге и кардио да би остао у форми за напоран дан трке. Вежбе радећи заједно на решавању проблема који се могу појавити током трке. Исто тако, развојни тим треба да тренира вештину честог објављивања нових верзија. Ако имате такве вештине и систем безбедности који добро функционише, пуштање нових верзија у производњу такође се дешава чешће. У овом погледу на свет, повећана брзина значи већу безбедност“, каже Схорт.
„Не ради се о томе да урадите ’праву ствар‘“, додаје Схорт, „већ о елиминисању што више ствари које стоје на путу до жељеног исхода. Сарађујте и прилагођавајте се на основу повратних информација које добијате у реалном времену. Будите спремни на аномалије и радите на побољшању квалитета како бисте смањили њихов утицај на напредак ка вашем циљу. То је оно што нас чека у свету ДевОпс-а.”
Како скалирати ДевОпс: 10 савета стручњака
Само што су ДевОпс и масовни ДевОпс потпуно различите ствари. Рећи ћемо вам како да превазиђете препреке на путу од првог до другог.
За многе организације, путовање до ДевОпс-а почиње лако и пријатно. Стварају се мали страствени тимови, стари процеси се замењују новим, а први успеси не чекају дуго.
Авај, ово је само лажни сјај, илузија напретка, каже Бен Гриннел, генерални директор и шеф дигиталног сектора у консултантској кући Нортх Хигхланд. Ране победе су свакако охрабрујуће, али не помажу у постизању крајњег циља широког усвајања ДевОпс-а у целој организацији.
Лако је видети да је резултат култура поделе између „нас“ и „њих“.
„Организације често покрећу ове пионирске пројекте мислећи да ће утрти пут за маинстреам ДевОпс, не размишљајући о томе да ли ће други моћи или ће хтети да следе тај пут“, објашњава Бен Гриннел. – Тимови за реализацију оваквих пројеката обично се регрутују од самоуверених „Варага” који су већ урадили нешто слично на другим местима, али су нови у вашој организацији. Истовремено, они се охрабрују да крше и униште правила која остају обавезујућа за све остале. Лако је видети да је резултат култура „нас“ и „њих“ која кочи пренос знања и вештина.
„А овај културни проблем је само један од разлога зашто је ДевОпс тешко скалирати. ДевОпс тимови се суочавају са повећаним техничким изазовима који су типични за брзо растуће ИТ компаније“, рекао је Стив Њуман, оснивач и председник компаније Сцалир.
„У савременом свету услуге се мењају чим се за то укаже потреба. Сјајно је стално имплементирати и имплементирати нове функције, али координација овог процеса и елиминисање проблема који се појављују је права главобоља, додаје Стив Њуман. – У организацијама које се веома брзо развијају, инжењери у тимовима са више функција се боре да одрже видљивост промена и каскадних ефеката које она ствара на нивоу зависности. Штавише, инжењери нису срећни када су лишени ове могућности и, као резултат тога, постаје им теже да схвате суштину проблема који се појављују.”
Како превазићи ове горе описане изазове и прећи на масовно усвајање ДевОпс-а у великој организацији? Стручњаци позивају на стрпљење, чак и ако је ваш крајњи циљ да убрзате циклус развоја софтвера и пословне процесе.
1. Запамтите да промена културе захтева време.
Јаине Гролл, извршни директор, ДевОпс институт: „По мом мишљењу, проширење ДевОпс-а треба да буде инкрементално и итеративно као и агилни развој (и да се подједнако дотиче културе). Агиле и ДевОпс наглашавају мале тимове. Али како ови тимови расту у броју и интеграцији, на крају имамо све више људи који усвајају нове начине рада, а као резултат тога долази до огромне културне трансформације.”
2. Проведите довољно времена планирајући и бирајући платформу
Еран Кинсбрунер, водећи технички еванђелиста у Перфецто: „Да би скалирање функционисало, ДевОпс тимови прво морају да науче да комбинују традиционалне процесе, алате и вештине, а затим да полако негују и стабилизују сваку појединачну фазу ДевОпс-а. Све почиње пажљивим планирањем корисничких прича и токова вредности, након чега следи писање софтвера и контрола верзија коришћењем развоја заснованог на трунковима или других приступа који су најприкладнији за гранање и спајање кода.“
„Онда долази фаза интеграције и тестирања, где је већ потребна скалабилна платформа за аутоматизацију. Овде је важно да ДевОпс тимови одаберу праву платформу која одговара њиховом нивоу вештина и крајњим циљевима пројекта.
Следећа фаза је имплементација у производњу и ово би требало да буде потпуно аутоматизовано помоћу алата за оркестрацију и контејнера. Важно је имати виртуелизована окружења у свим фазама ДевОпс-а (симулатор производње, КА окружење и стварно производно окружење) и увек користити само најновије податке за тестове да би се добили релевантни закључци. Аналитика мора бити паметна и способна да обрађује велике податке са брзим повратним информацијама.
3. Скините кривицу из одговорности.
Гордон Хаф, РедХат Еванђелиста: „Креирање система и атмосфере који дозвољавају и подстичу експериментисање омогућава оно што је познато као успешни неуспеси у агилном развоју софтвера. То не значи да нико други није одговоран за неуспехе. У ствари, идентификовање ко је одговоран постаје још лакше, пошто „бити одговоран“ више не значи „изазвати несрећу“. Односно, суштина одговорности се квалитативно мења. Четири фактора постају критична: обим поремећаја, приступи, производни процеси и подстицаји.” (Више о овим факторима можете прочитати у чланку Гордона Хафа „ДевОпс лекције: 4 аспекта здравих експеримената.“)
4. Очистите пут напред
Бен Гриннелл, генерални директор и шеф дигиталног сектора у консултантској кући Нортх Хигхланд: „Да би се постигао обим, препоручујем покретање програма „чишћења пута” заједно са пионирским пројектима. Циљ овог програма је да очисти ђубре које пионири ДевОпс-а остављају за собом, попут застарелих правила и сличних ствари, тако да пут напред остане јасан.”
„Дајте људима организациону подршку и замах кроз комуникацију која превазилази пионирску групу тако што ћете нашироко славити успехе нових начина рада. Обучите људе који су укључени у следећи талас ДевОпс пројеката и који су нервозни због првог коришћења ДевОпс-а. И запамтите да се ови људи веома разликују од пионира.”
5. Демократизовати алате
Стеве Невман, оснивач и председник Сцалир-а: „Алати не би требало да буду сакривени од људи и требало би да буду релативно лаки за учење за свакога ко жели да уложи време. Ако је могућност упита дневника ограничена на три особе „сертификоване“ за коришћење алата, увек ћете имати највише три особе на располагању за решавање проблема, чак и ако имате веома велико рачунарско окружење. Другим речима, овде постоји уско грло које може довести до озбиљних (пословних) последица.”
6. Створити идеалне услове за тимски рад
Том Кларк, шеф заједничке платформе на ИТВ: „Можете све, али не све одједном. Зато поставите велике циљеве, почните с малим и идите напред у брзим итерацијама. Временом ћете развити репутацију за обављање ствари, тако да ће и други желети да користе ваше методе. И не брините о изградњи веома ефикасног тима. Уместо тога, обезбедите људима идеалне услове за рад и ефикасност ће уследити.”
7. Не заборавите на Конвејев закон и Канбан табле
Логан Даигле, директор испоруке софтвера и ДевОпс стратегије у ЦоллабНетВерсионОне: „Важно је разумети последице Конвејевог закона. У мојој лабавој парафрази, овај закон каже да производи које креирамо и процеси које користимо за то, укључујући ДевОпс, изгледају структурирани на исти начин као и наша организација.
„Ако у организацији постоји много силоса, а контрола много пута мења руке приликом планирања, изградње и издавања софтвера, ефекат скалирања ће бити нула или ће бити краткотрајан. Ако организација гради међуфункционалне тимове око производа који се финансирају са тржишним фокусом, онда се шансе за успех драматично повећавају.”
„Још један важан аспект скалирања је приказивање свих радова у току (ВИП, воркинпрогресс) на Канбан плочама. Када организација има место где људи могу да виде ове ствари, то у великој мери подстиче сарадњу, што има позитиван утицај на скалирање."
8. Потражите старе ожиљке
Мануел Паис, ДевОпс консултант и коаутор Топологије тима: „Преузимање ДевОпс пракси изван самих Дев и Опс-а и покушај да их примените на друге функције тешко да је оптималан приступ. Ово ће сигурно имати неког утицаја (на пример, аутоматизацијом ручне контроле), али много више се може постићи ако почнемо са разумевањем процеса испоруке и повратних информација.
„Ако постоје стари ожиљци у ИТ систему организације – процедуре и механизми управљања који су примењени као резултат прошлих инцидената, али су изгубили на важности (због промена у производима, технологијама или процесима) – онда их свакако треба уклонити или изглађен, уместо да аутоматизује неефикасне или непотребне процесе."
9. Не узгајајте ДевОпс опције
Ентони Едвардс, директор операција у Еггплант: „ДевОпс је веома нејасан термин, тако да сваки тим на крају има своју верзију ДевОпс-а. И нема ништа горе када организација одједном има 20 варијанти ДевОпс-а који се не слажу баш најбоље заједно. Немогуће је да сваки од три развојна тима има свој, посебан интерфејс између развоја и управљања производом. Производи такође не би требало да имају сопствена јединствена очекивања за руковање повратним информацијама када се пренесу на симулатор производње. У супротном, никада нећете моћи да скалирате ДевОпс."
10. Проповедајте пословну вредност ДевОпс-а
Стеве Невман, оснивач и председник Сцалир-а: „Радите на препознавању вредности ДевОпс-а. Научите и слободно причајте о предностима онога што радите. ДевОпс је невероватна уштеда времена и новца (само помислите: мање застоја, краће средње време до опоравка), а ДевОпс тимови морају неуморно да наглашавају (и проповедају) важност ових иницијатива за пословни успех. На овај начин можете проширити круг присталица и повећати утицај ДевОпс-а у организацији.”
БОНУС
На Наш сопствени ДевОпс стиже 13. септембра - да, Ред Хат, као произвођач софтвера, има своје ДевОпс тимове и праксе.
Наш инжењер Марк Биргер, који развија услуге интерне аутоматизације за друге групе у целој организацији, испричаће своју причу на јасном руском – како је Ред Хат ДевОпс тим мигрирао апликације из виртуелних окружења Хат Виртуализатион којима управља Ансибле у пуноправни формат контејнера на платформа ОпенСхифт.
Али то није све:
Једном када организације пребаце радна оптерећења у контејнере, традиционалне методе праћења апликација можда неће радити. У другом говору ћемо објаснити нашу мотивацију за промену начина евидентирања и показати наставак пута који нас је довео до савремених метода евидентирања и праћења.
Извор: ввв.хабр.цом