Управљање хаосом: увођење реда уз помоћ технолошке мапе

Слика: Унспласх

Здраво свима! Ми смо инжењери аутоматизације из компаније Поситиве Тецхнологиес и пружамо подршку за развој производа компаније: подржавамо цео процес склапања од урезивања линије кода од стране програмера до објављивања готових производа и лиценци на серверима за ажурирање. Неформално, ми се зовемо ДевОпс инжењери. У овом чланку желимо да говоримо о технолошким фазама процеса производње софтвера, како их видимо и како их класификујемо.

Из материјала ћете научити о сложености координације развоја више производа, шта је технолошка мапа и како она помаже у организовању и реплицирању решења, од којих главних фаза и корака се састоји процес развоја, како су разграничене области одговорности између ДевОпс-а и тимова у нашој компанији.

О хаосу и ДевОпс-у

Да укратко напоменемо да концепт ДевОпс-а укључује развојне алате и услуге, као и методологије и најбоље праксе за њихову употребу. Истакнимо глобално циљ од имплементације ДевОпс идеја у нашој компанији: ово је доследно смањење трошкова производње и одржавања производа у квантитативном смислу (људски сати или машински сати, ЦПУ, РАМ, Диск итд.). Најједноставнији и најочигледнији начин да се смање укупни трошкови развоја на нивоу компаније је да минимизирање трошкова обављања типичних серијских задатака у свим фазама производње. Али које су то фазе, како се могу разликовати од општег процеса, од којих корака се састоје?

Када компанија развија један производ, све је мање-више јасно: обично постоји општа мапа пута и шема развоја. Али шта учинити када се линија производа прошири и има више производа? На први поглед, они имају сличне процесе и монтажне линије и почиње игра „пронађи Кс разлике“ у евиденцијама и скриптама. Шта ако већ постоји 5+ пројеката у активном развоју и потребна је подршка за неколико верзија развијених током неколико година? Да ли желимо да поново користимо што је могуће више решења у цевоводима производа или смо спремни да потрошимо новац на јединствен развој за свако од њих?

Како пронаћи равнотежу између јединствености и серијалности решења?

Ова питања су почела да се постављају пред нама све чешће од 2015. године. Број производа је растао, а ми смо настојали да наше одељење за аутоматизацију (ДевОпс), које је подржавало монтажне линије ових производа, проширимо на минимум. У исто време, желео сам да реплицирам што више решења између производа. Уосталом, зашто исту ствар у десет производа радити на различите начине?

Директор развоја: „Момци, можемо ли некако да проценимо шта ДевОпс ради за производе?“

Ми: „Не знамо, нисмо поставили ово питање, али које показатеље треба израчунати?“

Директор развоја: "Ко зна! Мисли..."

Као у оном чувеном филму: „Идем у хотел!..” – „Ух... Можеш ли ми показати пут?” Након размишљања, дошли смо до закључка да прво треба да одлучимо о коначним стањима производа; ово је постао наш први циљ.

Дакле, како можете анализирати десетак производа са прилично великим тимовима од 10 до 200 људи и одредити мерљиве метрике када реплицирате решења?

1:0 у корист Хаоса, или ДевОпс-а на оштрицама

Почели смо тако што смо покушали да применимо ИДЕФ0 дијаграме и различите дијаграме пословних процеса из БПвин серије. Забуна је почела након петог квадрата следеће фазе следећег пројекта, а ови квадрати за сваки пројекат могу се увући у реп дугог питона у 50+ корака. Осећао сам се тужно и желео сам да завијам на месец - никако ми није одговарало.

Типични производни задаци

Моделирање производних процеса је веома сложен и мукотрпан посао: потребно је прикупити, обрадити и анализирати много података из различитих одељења и производних ланаца. Више о томе можете прочитати у чланку „Моделирање производних процеса у ИТ компанији'.

Када смо започели моделирање нашег производног процеса, имали смо конкретан циљ – да сваком запосленом укљученом у развој производа наше компаније и пројект менаџерима пренесемо:

• како производи и њихове компоненте, почевши од урезивања линије кода, дођу до купца у облику инсталатера и ажурирања,
• који су ресурси обезбеђени у свакој фази производње производа,
• које су услуге укључене у свакој фази,
• како су области одговорности разграничене за сваку фазу,
• који уговори постоје на улазу и излазу сваке фазе.

Кликните на слику да бисте је отворили у пуној величини

Наш рад у компанији је подељен у неколико функционалних области. Инфраструктурно одељење се бави оптимизацијом рада свих хардверских ресурса одељења, као и аутоматизацијом распоређивања виртуелних машина и окружења на њима. Смер мониторинга обезбеђује контролу над обављањем услуга 24/7; Такође пружамо мониторинг као услугу за програмере. Правац тока посла пружа тимовима алате за управљање процесима развоја и тестирања, анализу статуса кода и добијање аналитике о пројектима. И коначно, вебдев правац обезбеђује објављивање издања на ГУС и ФЛУС серверима за ажурирање, као и лиценцирање производа помоћу услуге ЛиценсеЛаб. Да бисмо подржали производни процес, постављамо и одржавамо много различитих услуга подршке за програмере (можете слушати приче о некима од њих на старим окупљањима: Оп!ДевОпс! 2016 и Оп!ДевОпс! 2017). Такође развијамо интерне алате за аутоматизацију, укључујући решења отвореног кода.

У протеклих пет година у нашем раду нагомилало се доста сличних и рутинских операција, а тзв. типични задаци, чије је решење потпуно или делимично аутоматизовано, не изазива потешкоће извођачима и не захтева значајне количине посла. Заједно са водећим областима анализирали смо такве задатке и успели да идентификујемо поједине категорије рада, одн фазе производње, етапе су подељене у недељиве кораке, а неколико фаза се сабирају ланац производног процеса.

Најједноставнији пример технолошког ланца су фазе монтаже, постављања и тестирања сваког нашег производа у оквиру компаније. Заузврат, на пример, фаза израде се састоји од много одвојених стандардних корака: преузимање извора са ГитЛаб-а, припрема зависности и библиотека трећих страна, тестирање јединица и статичка анализа кода, извршавање скрипте за прављење на ГитЛаб ЦИ, објављивање артефаката у спремишту на Артифактура и генерисање белешки о издању преко нашег интерног ЦхангелогБуилдер алата.

Можете прочитати о типичним задацима ДевОпс-а у нашим другим чланцима на Хабре: “Лично искуство: како изгледа наш систем континуиране интеграције"И"Аутоматизација развојних процеса: како смо имплементирали ДевОпс идеје у Поситиве Тецхнологиес'.

Формирају се многи типични производни ланци производни процес. Стандардни приступ описивању процеса је коришћење функционалних ИДЕФ0 модела.

Пример моделирања производног ЦИ процеса

Посебну пажњу смо посветили изради стандардних пројеката за континуирани систем интеграције. То је омогућило да се постигне обједињавање пројеката, истичући тзв дијаграм издања са промоцијама.

Ево како то функционише. Сви пројекти изгледају типично: укључују конфигурацију склопова који иду у спремиште снимака на Артифацтори, након чега се постављају и тестирају на тестним столовима, а затим се промовишу у спремиште издања. Услуга Артифацтори је јединствена тачка за дистрибуцију свих артефаката изградње између тимова и других услуга.

Ако у великој мери поједноставимо и генерализујемо нашу шему издавања, она укључује следеће фазе:

• израда производа на више платформи,
• распоређивање на испитним столовима,
• покретање функционалних и других тестова,
• промоција тестираних склопова за издавање спремишта на Артифацтори,
• објављивање верзија издања за ажурирање сервера,
• испорука верзија и ажурирања за производњу,
• покретање инсталације и ажурирања производа.

Размотримо, као пример, технолошки модел ове типичне шеме ослобађања (у даљем тексту једноставно Модел) у облику функционалног ИДЕФ0 модела. Он одражава главне фазе нашег процеса ЦИ. ИДЕФ0 модели користе тзв ИЦОМ нотација (Инпут-Цонтрол-Оутпут-Мецханисм) да опише који се ресурси користе у свакој фази, на основу којих правила и захтева се рад обавља, који је резултат и који механизми, услуге или људи имплементирају одређену фазу.

Кликните на слику да бисте је отворили у пуној величини

По правилу, у функционалним моделима је лакше декомпоновати и детаљније описивати процесе. Али како број елемената расте, постаје све теже разумети нешто о њима. Али у стварном развоју постоје и помоћне фазе: праћење, сертификација производа, аутоматизација радних процеса и друго. Управо због проблема скалирања напустили смо овај опис.

Рођење наде

У једној књизи наишли смо на старе совјетске карте које описују технолошке процесе (које се, иначе, и данас користе у многим државним предузећима и универзитетима). Чекај, чекај, имамо и технолошки процес!.. Постоје фазе, резултати, метрике, захтеви, индикатори, итд, итд... Зашто не бисмо покушали да применимо технолошке мапе на нашим транспортерима производа? Постојао је осећај: „То је то! Пронашли смо праву нит, време је да је добро повучемо!"

У једноставној табели одлучили смо да производе евидентирамо по колонама, а технолошке фазе и кораке транспортне траке производа по редовима. Фазе су нешто велико, као што је фаза склапања производа. А кораци су нешто мање и детаљније, на пример, корак преузимања изворног кода на сервер за изградњу или корак компајлирања кода.

На пресецима редова и колона мапе постављамо статусе за одређену фазу и производ. Многе државе су дефинисане за статусе:

1. Нема информација - или непрактично. Потребно је анализирати потражњу за фазом у производу. Или је анализа већ урађена, али фаза тренутно није потребна или није економски оправдана.
2. Одложено - или није релевантно у овом тренутку. Ова фаза у плану је потребна, али нема енергије да се она спроведе ове године.
3. Планирано. Етапа је планирана за реализацију ове године.
4. Имплементирано. Фаза у цевоводу је спроведена у потребној мери.

Попуњавање табеле почело је пројекат по пројекат. Прво смо класификовали фазе и кораке једног пројекта и забележили њихов статус. Затим су узели следећи пројекат, забележили статусе у њему и додали фазе и кораке који су недостајали у претходним пројектима. Као резултат тога, добили смо фазе и кораке читавог нашег производног процеса и њихове статусе у конкретном пројекту. Резултат је нешто слично матрици компетенција за транспортер хране. Такву матрицу смо назвали технолошком мапом.

Уз помоћ технолошке карте, метролошки садржајно договарамо са тимовима планове рада за годину и циљеве које желимо заједно да постигнемо: које фазе додајемо пројекту ове године, а које остављамо за касније. Такође, док радимо, можда ћемо видети побољшања корака које смо обавили за само један производ. Затим проширујемо нашу мапу и уводимо ово побољшање као фазу или нови корак, затим спроводимо анализу за сваки производ и сазнајемо изводљивост реплицирања побољшања.

Они нам могу приговорити: „Ово је све добро, наравно, али временом ће број корака и фаза постати недовољно велики. Шта бих требао да урадим?

Увели смо стандардне и прилично потпуне описе захтева за сваку фазу и корак како би их у компанији сви разумели на исти начин. Временом, како се побољшања имплементирају, корак се може апсорбовати у другу фазу или корак - тада ће се срушити. Истовремено, сви захтеви и технолошке нијансе уклапају се у захтеве генерализујуће фазе или корака.

Како проценити ефекат реплицирања решења? Користимо крајње једноставан приступ: почетне капиталне трошкове за имплементацију нове фазе приписујемо годишњим општим трошковима производа, а затим их делимо на све приликом реплицирања.

Делови развоја се већ одражавају као фазе и кораци на мапи. На смањење трошкова производа можемо утицати увођењем аутоматизације за типичне фазе. Након тога израчунавамо промене у квалитативним карактеристикама, квантитативним метрикама и профиту који тимови добијају (у уштеђеним радним или машинским сатима).

Технолошка карта процеса производње

Ако предузмемо све наше фазе и кораке, кодирамо их ознакама и проширимо их у један ланац, онда ће се испоставити да је веома дугачак и неразумљив (тачно исти „питонов реп“ о коме смо говорили на почетку чланка) :

[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]

Ово су фазе склапања производа [Буилд], њиховог постављања на сервере за тестирање [Деплои], тестирања [Тест], промовисања склопова за ослобађање спремишта на основу резултата тестирања [Промоте], генерисања и објављивања лиценци [Лиценсе], објављивања [Публисх] на ГУС серверу за ажурирање и испорука ФЛУС ажурирања на сервере, инсталација и ажурирање компоненти производа на инфраструктури купца помоћу управљања конфигурацијом производа [Инсталл], као и прикупљање телеметрије [Телеметрија] са инсталираних производа.

Поред њих, можемо разликовати одвојене фазе: праћење стања инфраструктуре [ИнфМониторинг], управљање верзијама изворног кода [СоурцеЦодеЦонтрол], припремање окружења за склапање [Препаре], управљање пројектом [Воркфлов], обезбеђивање тимова комуникационим алатима [ Комуникација], сертификација производа [Цертификација] и обезбеђивање самодовољности ЦИ процеса [ЦИСелфСуффициенци] (на пример, независност склопова од Интернета). Нећемо чак ни разматрати десетине корака у нашим процесима, јер су они веома специфични.

Биће много лакше разумети и сагледати цео процес производње ако га замислите у форми технолошка карта; Ово је табела у којој су појединачне фазе производње и декомпоновани кораци Модела забележени у редовима, ау колонама опис онога што је урађено у свакој фази или кораку. Главни нагласак је на ресурсима који обезбеђују сваку фазу и на разграничењу области одговорности.

За нас је карта нека врста класификатора. Она одражава велике технолошке делове производње производа. Захваљујући томе, нашем тиму за аутоматизацију је постало лакше да комуницира са програмерима и заједнички планира имплементацију фаза аутоматизације, као и да разуме који ће трошкови рада и ресурси (људски и хардверски) бити потребни за то.

Унутар наше компаније, мапа се аутоматски генерише из јиња шаблона као обична ХТМЛ датотека, а затим се отпрема на сервер ГитЛаб Пагес. Може се видети снимак екрана са примером потпуно генерисане мапе по ссылке.

Кликните на слику да бисте је отворили у пуној величини

Укратко, технолошка мапа је генерализована слика производног процеса, која одражава јасно класификоване блокове са стандардном функционалношћу.

Структура наше технолошке карте

Мапа се састоји од неколико делова:

1. Подручје наслова - овде је општи опис карте, представљени су основни концепти и дефинисани су главни ресурси и резултати процеса производње.
2. Информациони панел - овде можете да контролишете приказ података за појединачне производе; дат је сажетак спроведених фаза и корака уопште за све производе.
3. Технолошка карта – табеларни опис технолошког процеса. На мапи:
   • дати су сви кораци, кораци и њихови кодови;
   • дати су кратки и потпуни описи фаза;
   • назначени су улазни ресурси и услуге које се користе у свакој фази;
   • приказани су резултати сваке фазе и појединачног корака;
   • назначена је област одговорности за сваку фазу и корак;
   • утврђени су технички ресурси, на пример ХДД (ССД), РАМ, вЦПУ и радни сати неопходни за подршку рада у овој фази, како тренутно – чињеница, тако и у будућности – планом;
   • за сваки производ је назначено које су технолошке фазе или кораци за њега спроведени, планирани за имплементацију, ирелевантни су или нису реализовани.

Доношење одлука на основу технолошке карте

Након проучавања мапе, можете предузети неке радње, у зависности од улоге запосленог у компанији (менаџер развоја, менаџер производа, програмер или тестер):

• разумети које фазе недостају у стварном производу или пројекту и проценити потребу за њиховом имплементацијом;
• разграничити области одговорности између неколико одељења ако раде у различитим фазама;
• преговарати о уговорима за улазе и излазе фаза;
• интегрисати своју фазу рада у укупни развојни процес;
• прецизније проценити потребу за ресурсима за подршку свакој фази.

Сумирајући све наведено

Технолошка мапа је разноврсна, проширива и лака за одржавање. Много је лакше развити и одржавати описе процеса у овом облику него у строгом академском ИДЕФ0 моделу. Поред тога, табеларни опис је једноставнији, познатији и боље структуриран од функционалног модела.

Специјални интерни алат, ЦроссБуилдер, одговоран је за техничку имплементацију корака – алат за слојеве између ЦИ система, услуга и инфраструктуре. Програмер не треба да исече свој бицикл: у нашем ЦИ систему довољно је да покрене једну од скрипти (тзв. задатак) алатке ЦроссБуилдер, која ће га исправно извршити, узимајући у обзир карактеристике наше инфраструктуре.

Резултати

Испоставило се да је чланак прилично дугачак, али то је неизбежно када се описује моделовање сложених процеса. На крају, желео бих укратко да изнесем наше главне идеје:

• Циљ увођења ДевОпс идеја у нашу компанију је доследно смањење трошкова производње и одржавања производа компаније у квантитативном смислу (радни сати или машински сати, вЦПУ, РАМ, диск).
• Начин да се смање укупни трошкови развоја је минимизирање трошкова извршавања стандардних серијских задатака: фаза и корака технолошког процеса.
• Типичан задатак је задатак чије је решавање потпуно или делимично аутоматизовано, не изазива потешкоће извођачима и не захтева значајне трошкове рада.
• Производни процес се састоји од фаза, фазе су подељене на недељиве кораке, који представљају типичне задатке различитих размера и обима.
• Од изолованих стандардних задатака дошли смо до сложених технолошких ланаца и вишеслојних модела производног процеса, који се могу описати функционалним ИДЕФ0 моделом или једноставнијом технолошком мапом.
• Дијаграм тока је табеларни приказ фаза и корака производног процеса. Оно што је најважније: мапа вам омогућава да видите цео процес у целини, у великим деловима са могућношћу детаљног детаљисања.
• На основу технолошке мапе можете проценити потребу за имплементацијом фаза у одређеном производу, разграничити области одговорности, договорити уговоре за улазе и излазе фаза и прецизније проценити потребу за ресурсима.

У наредним чланцима ћемо детаљније говорити о томе који технички алати се користе за имплементацију одређених технолошких фаза на нашој мапи.

Аутори чланка:

• Александар Паздников — Шеф одељења за аутоматизацију (ДевОпс) у компанији Поситиве Тецхнологиес
• Тимур Гилмуллин - заменик Шеф одељења за аутоматизацију (ДевОпс) у компанији Поситиве Тецхнологиес

Извор: ввв.хабр.цом