Управување со хаосот: Поставување на работите во ред со помош на технолошка карта

Слика: Unsplash

Здраво на сите! Ние сме инженери за автоматизација од компанијата Позитивни технологии и го поддржуваме развојот на производите на компанијата: го поддржуваме целиот цевковод за склопување, од запишување на линија код од страна на програмерите до објавување на готови производи и лиценци на серверите за ажурирање. Неформално, ние се нарекуваме инженери на DevOps. Во оваа статија сакаме да зборуваме за технолошките фази на процесот на производство на софтвер, како ги гледаме и како ги класифицираме.

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

За Хаос и DevOps

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

Кога една компанија развива еден производ, сè е повеќе или помалку јасно: обично постои заеднички патоказ и развојна шема. Но, што да се прави кога линијата на производи се прошири и има повеќе производи? На прв поглед, тие имаат слични процеси и линии на склопување и започнува играта „најди ги X разлики“ во дневници и скрипти. Но, што ако веќе има 5+ проекти во активен развој и потребна е поддршка за неколку верзии развиени во текот на неколку години? Дали сакаме повторно да го искористиме максималниот можен број решенија во нафтоводите на производи или сме подготвени да потрошиме пари на уникатен развој за секој?

Како да се најде баланс помеѓу уникатноста и сериските решенија?

Овие прашања почнаа да се појавуваат пред нас се почесто од 2015 година. Бројот на производи се зголеми и се обидовме да го прошириме нашиот оддел за автоматизација (DevOps), кој ги поддржуваше линиите за склопување на овие производи, на минимум. Во исто време, сакавме да реплицираме што е можно повеќе решенија помеѓу производите. На крајот на краиштата, зошто го правиме истото во десет производи на различни начини?

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

Ние: „Не знаеме, не поставивме такво прашање, но кои индикатори треба да се земат предвид?

Директор за развој: "Кој знае! Размислете…”

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

Значи, како да анализирате десетина производи со прилично големи тимови од 10 до 200 луѓе и да одредите мерливи метрики при реплицирање решенија?

1:0 во корист на Хаос, или DevOps на лопатките

Започнавме со обид да примениме IDEF0 дијаграми и различни дијаграми за деловни процеси од серијата BPwin. Конфузијата започна по петтиот квадрат од следната фаза на следниот проект, а овие квадрати за секој проект може да се нацртаат во опашката на долг питон под 50+ чекори. Се чувствував тажно и сакав да завивам на Месечината - воопшто не одговараше.

Типични задачи за производство

Моделирањето на производните процеси е многу сложена и макотрпна работа: треба да соберете, обработите и анализирате многу податоци од различни оддели и синџири на производство. Можете да прочитате повеќе за ова во статијата "Моделирање на производствени процеси во ИТ компанија".

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

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

Со кликнување на сликата ќе се отвори во целосна големина

Нашата работа во компанијата е поделена на неколку функционални области. Насоката на инфраструктурата е ангажирана во оптимизација на работата на сите „железни“ ресурси на одделот, како и автоматизација на распоредувањето на виртуелните машини и околината на нив. Насоката на мониторинг обезбедува 24/7 контрола на перформансите на услугата; ние исто така обезбедуваме мониторинг како услуга за програмерите. Насоката на работниот тек им обезбедува на тимовите алатки за управување со процесите на развој и тестирање, за анализа на состојбата на кодот и за добивање аналитика на проекти. И, конечно, насоката webdev обезбедува објавување на изданија на серверите за ажурирање GUS и FLUS, како и лиценцирање на производи со користење на услугата LicenseLab. За да го поддржиме производството, поставуваме и одржуваме многу различни услуги за поддршка за програмери (можете да слушате приказни за некои од нив на старите состаноци: Op!DevOps! 2016 година и Op!DevOps! 2017 година). Ние, исто така, развиваме алатки за внатрешна автоматизација, вклучувајќи решенија со отворен код.

Во текот на изминатите пет години, нашата работа има акумулирано многу од ист тип и рутински операции, а нашите програмери од другите оддели главно доаѓаат од т.н. типични задачи, чие решение е целосно или делумно автоматизирано, не предизвикува потешкотии за изведувачите и не бара значителни количини на работа. Заедно со водечките области, ги анализиравме таквите задачи и успеавме да идентификуваме поединечни категории на работа, или фази на производство, фазите беа поделени на неделиви чекори, а се собираат неколку фази синџир на производствени процеси.

Наједноставниот пример за технолошки синџир се фазите на склопување, распоредување и тестирање на секој од нашите производи во рамките на компанијата. За возврат, на пример, фазата на изградба се состои од многу одделни типични чекори: преземање извори од GitLab, подготовка на зависности и библиотеки од трета страна, тестирање на единици и статичка анализа на кодот, извршување на скрипта за градење на GitLab CI, објавување артефакти во складиштето на Артифакторност и генерирање белешки за ослободување преку нашата внатрешна алатка ChangelogBuilder.

Можете да прочитате за типични задачи на DevOps во нашите други написи на Habré:Лично искуство: како изгледа нашиот систем за континуирана интеграција"И"Автоматизација на развојните процеси: како ги имплементиравме идеите за DevOps во Positive Technologies".

Се формираат многу типични производни синџири производствен процес. Стандардниот пристап за опишување на процесите е да се користат функционални IDEF0 модели.

Пример за моделирање на производствен CI процес

Посветивме посебно внимание на развојот на стандардни проекти за континуиран систем за интеграција. Ова овозможи да се постигне обединување на проектите, истакнувајќи т.н ослободување на изградба шема со промоции.

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

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

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

На пример, разгледајте го технолошкиот модел на оваа типична шема за ослободување (во натамошниот текст едноставно Модел) во форма на функционален модел IDEF0. Ги одразува главните фази на нашиот процес на CI. IDEF0 моделите користат т.н ICOM нотација (Влез-контрола-излез-механизам) да опише кои ресурси се користат во секоја фаза, врз основа на кои правила и барања се извршува работата, каков е излезот и кои механизми, услуги или луѓе спроведуваат одредена фаза.

Со кликнување на сликата ќе се отвори во целосна големина

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

Раѓање на надежта

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

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

На пресеците на редовите и колоните на картата, ги ставаме статусите за одредена фаза и производ. За статусите, беше дефиниран сет на состојби:

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]

Ова се фази на градење производи [Изградба], нивно распоредување на сервери за тестирање [Распореди], тестирање [Тест], промовирање на градби за објавување складишта врз основа на резултатите од тестирањето [Промовирање], генерирање и објавување лиценци [Лиценца], објавување [ Објавување] на серверот за ажурирање на GUS и испорака до серверите за ажурирање FLUS, инсталација и ажурирање на компонентите на производот на инфраструктурата на клиентот користејќи Управување со конфигурација на производи [Инсталирај], како и собирање телеметрија [Телеметрија] од инсталираните производи.

Покрај нив, може да се разликуваат одделни фази: следење на состојбата на инфраструктурата [InfMonitoring], верзија на изворниот код [SourceCodeControl], подготовка на околина за градење [Подготви], управување со проекти [Workflow], обезбедување на тимови со алатки за комуникација [Комуникација], сертификација на производи [ Сертификација] и обезбедување на самодоволност на CI процесите [CISelfSufficiency] (на пример, независност на склоповите од Интернет). Десетици чекори во нашите процеси нема ни да се разгледуваат, бидејќи се многу специфични.

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

Картата за нас е еден вид класификатор. Тоа ги одразува големите технолошки делови на производството на производи. Благодарение на него, на нашиот тим за автоматизација му стана полесно да комуницира со програмерите и заеднички да планира имплементација на фазите на автоматизација, како и да разбере какви трошоци и ресурси за работна сила (човечки и хардвер) ќе бидат потребни за ова.

Во нашата компанија, мапата автоматски се генерира од шаблонот jinja како обична HTML-датотека, а потоа се поставува на серверот GitLab Pages. Може да се прегледа скриншот со пример на целосно генерирана карта по ссылке.

Со кликнување на сликата ќе се отвори во целосна големина

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

Структура на нашата патна карта

Картата се состои од неколку делови:

1. Област на наслов - тука е општ опис на картата, се воведуваат основни концепти, се дефинираат главните ресурси и резултати од производниот процес.
2. Контролна табла - овде можете да го контролирате прикажувањето на податоците за поединечни производи, даден е резиме на имплементираните фази и чекори воопшто за сите производи.
3. Технолошка карта - табеларен опис на технолошкиот процес. На мапата:
   • дадени се сите фази, чекори и нивните кодови;
   • дадени се кратки и целосни описи на фазите;
   • се наведени влезните ресурси и услугите што се користат во секоја фаза;
   • се наведени резултатите од секоја фаза и посебен чекор;
   • означена е областа на одговорност за секоја фаза и чекор;
   • утврдени се техничките ресурси, како што се HDD (SSD), RAM, vCPU и работните часови потребни за поддршка на работата во оваа фаза, како во моменталниот момент - факт, така и во иднина - план;
   • за секој производ се посочува кои технолошки фази или чекори за него се имплементирани, планирани за имплементација, ирелевантни или неимплементирани.

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

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

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

Сумирајќи ги сите горенаведени

Рутирањето е разноврсно, растегливо и лесно се одржува. Многу е полесно да се развие и одржи опис на процесите во оваа форма отколку во строг академски модел IDEF0. Дополнително, табеларниот опис е поедноставен, попознат и подобро структуриран од функционалниот модел.

За техничка имплементација на чекорите, имаме посебна внатрешна алатка CrossBuilder - алатка за слоеви помеѓу CI системите, услугите и инфраструктурата. Инвеститорот не треба да го пресече својот велосипед: во нашиот CI систем, доволно е да извршите една од скриптите (т.н. задача) на алатката CrossBuilder, која правилно ќе ја изврши, земајќи ги предвид карактеристиките на нашата инфраструктура .

Резултатите од

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

• Целта на имплементацијата на идеите за DevOps во нашата компанија е постојано да се намалуваат трошоците за производство и одржување на производите на компанијата во квантитативна смисла (човечки часови или машински часови, vCPU, RAM, Disk).
• Начинот на намалување на вкупните трошоци за развој е да се минимизираат трошоците за извршување на типични сериски задачи: фази и чекори на технолошкиот процес.
• Типична задача е задача чие решение е целосно или делумно автоматизирано, не предизвикува тешкотии за изведувачите и не бара значителни трошоци за работна сила.
• Процесот на производство се состои од фази, фазите се поделени на неделиви чекори, кои се типични задачи од различен обем и обем.
• Од различни типични задачи, дојдовме до сложени технолошки синџири и модели на повеќе нивоа на производниот процес, кои можат да се опишат со функционален IDEF0 модел или поедноставна технолошка карта.
• Технолошката карта е табеларен приказ на фазите и чекорите на производниот процес. Најважно: мапата ви овозможува да го видите целиот процес во целост, во големи парчиња со можност за нивно детализирање.
• Врз основа на технолошката карта, можно е да се процени потребата да се воведат фази во одреден производ, да се разграничат областите на одговорност, да се договорат договори на влезните и излезните фази и попрецизно да се процени потребата од ресурси.

Во следните статии подетално ќе опишеме кои технички алатки се користат за имплементација на одредени технолошки фази на нашата карта.

Автори на статијата:

• Александар Паздников - Раководител за автоматизација (DevOps) во Позитивни технологии
• Тимур Гилмулин - заменик Раководител на Одделот за автоматизација (DevOps) во Позитивни технологии

Извор: www.habr.com