Управление на хаоса: Подреждане на нещата с помощта на технологична карта

Снимка: Unsplash

Здравейте всички! Ние сме инженери по автоматизация от компанията Позитивни технологии и ние подкрепяме разработването на продуктите на компанията: ние поддържаме целия процес на сглобяване от ангажимента на ред код от разработчиците до публикуването на готови продукти и лицензи на сървъри за актуализиране. Неформално ни наричат ​​DevOps инженери. В тази статия искаме да говорим за технологичните етапи на процеса на производство на софтуер, как ги виждаме и как ги класифицираме.

От материала ще научите за сложността на координирането на разработването на множество продукти, за това какво е технологична карта и как тя помага за рационализиране и възпроизвеждане на решения, какви са основните етапи и стъпки на процеса на разработка, как са зоните на отговорност между DevOps и екипите в нашата компания.

Относно Chaos и DevOps

Накратко, концепцията за DevOps включва инструменти за разработка и услуги, както и методологии и най-добри практики за тяхното използване. Нека отделим глобалното гол от внедряването на идеите на DevOps в нашата компания: това е последователно намаляване на разходите за производство и поддръжка на продуктите в количествено изражение (човекочасове или машиночасове, процесор, RAM, диск и др.). Най-лесният и очевиден начин за намаляване на общите разходи за разработка на ниво цялата компания е минимизиране на разходите за изпълнение на типични серийни задачи на всички етапи на производството. Но какви са тези етапи, как да ги отделим от общия процес, от какви стъпки се състоят?

Когато една компания разработва един продукт, всичко е повече или по-малко ясно: обикновено има обща пътна карта и схема за развитие. Но какво да правим, когато продуктовата линия се разшири и има повече продукти? На пръв поглед те имат сходни процеси и поточни линии и играта „намери X разлики“ в регистрационни файлове и скриптове започва. Но какво ще стане, ако вече има 5+ проекта в активно развитие и е необходима поддръжка за няколко версии, разработени в продължение на няколко години? Искаме ли да използваме повторно максималния възможен брой решения в продуктовите линии или сме готови да похарчим пари за уникална разработка за всяко?

Как да намерим баланс между уникалност и серийни решения?

Тези въпроси започнаха да възникват пред нас все по-често от 2015 г. Броят на продуктите нарасна и ние се опитахме да разширим нашия отдел за автоматизация (DevOps), който поддържаше монтажните линии на тези продукти, до минимум. В същото време искахме да копираме възможно най-много решения между продуктите. В крайна сметка, защо да правите едно и също нещо в десет продукта по различни начини?

Директор развитие: „Момчета, можем ли по някакъв начин да оценим какво прави DevOps за продуктите?“

Ние: „Не знаем, не сме задавали такъв въпрос, но какви показатели трябва да се имат предвид?“

Директор развитие: "Кой знае! Мисля…"

Както в онзи прочут филм: „Аз съм в хотел! ..“ – „Ъъъ... Можеш ли да ми покажеш пътя?“ След размисъл стигнахме до извода, че първо трябва да вземем решение за крайното състояние на продуктите; това стана първата ни цел.

И така, как да анализирате дузина продукти с доста големи екипи от 10 до 200 души и да определите измерими показатели при репликиране на решения?

1:0 в полза на Chaos, или DevOps на лопатките

Започнахме с опит да приложим IDEF0 диаграми и различни диаграми на бизнес процеси от серията BPwin. Объркването започна след петия квадрат на следващия етап от следващия проект и тези квадрати за всеки проект могат да бъдат начертани в опашката на дълъг питон под 50+ стъпки. Стана ми тъжно и исках да вия на луната - като цяло не се вписваше.

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

Моделирането на производствени процеси е много сложна и старателна работа: трябва да съберете, обработите и анализирате много данни от различни отдели и производствени вериги. Можете да прочетете повече за това в статията "Моделиране на производствени процеси в IT компания".

Когато започнахме да моделираме нашия производствен процес, имахме конкретна цел - да предадем на всеки служител, участващ в разработването на продуктите на нашата компания, както и на ръководителите на проекти:

• как продуктите и техните компоненти, като се започне от ангажирането на ред код, достигат до клиента под формата на инсталатори и актуализации,
• какви ресурси са предвидени за всеки етап от производството на продуктите,
• какви услуги са включени на всеки етап,
• как са разграничени областите на отговорност за всеки етап,
• какви договори съществуват на входа и изхода на всеки етап.

Щракването върху изображението ще го отвори в пълен размер

Работата ни във фирмата е разделена на няколко функционални направления. Дирекцията на инфраструктурата се занимава с оптимизирането на работата на всички "железни" ресурси на отдела, както и автоматизацията на разполагането на виртуални машини и околната среда върху тях. Дирекцията на мониторинг осигурява 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 нотация (Input-Control-Output-Mechanism), за да се опише какви ресурси се използват на всеки етап, въз основа на какви правила и изисквания се извършва работата, какъв е изходът и какви механизми, услуги или хора прилагат определен етап.

Щракването върху изображението ще го отвори в пълен размер

Като правило е по-лесно да се декомпозира и детайлизира описанието на процесите във функционалните модели. Но с нарастването на броя на елементите става все по-трудно да се разбере нещо в тях. Но в реалното развитие има и спомагателни етапи: мониторинг, сертифициране на продукта, автоматизация на работния процес и други. Именно поради проблема с мащабирането изоставихме това описание.

Раждане на надежда

В една книга попаднахме на стари съветски карти, описващи технологичните процеси (които, между другото, се използват и днес в много държавни предприятия и университети). Чакай, чакай, защото ние също имаме работен процес!.. Има етапи, резултати, показатели, изисквания, индикатори и така нататък и така нататък... Защо не опитате да приложите технологични схеми и към нашите продуктови линии? Имаше чувството: „Това е! Намерихме точната нишка, време е да я дръпнем добре!

В проста таблица решихме да записваме продуктите по колони, а технологичните етапи и стъпките на продуктовия конвейер по редове. Основните етапи са нещо голямо, като например стъпка в изграждането на продукт. А стъпките са нещо по-малко и по-подробно, като например стъпката на изтегляне на изходния код на сървъра за изграждане или стъпката на компилиране на кода.

В пресечните точки на редовете и колоните на картата поставяме статусите за конкретен етап и продукт. За статусите беше дефиниран набор от състояния:

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]

Това са етапите на изграждане на продукти [Build], внедряването им за тестови сървъри [Deploy], тестване [Test], насърчаване на компилации за освобождаване на хранилища въз основа на резултатите от тестването [Promote], генериране и публикуване на лицензи [License], публикуване [ Публикуване] на сървъра за актуализиране на GUS и доставка до сървърите за актуализиране на FLUS, инсталиране и актуализиране на продуктови компоненти в инфраструктурата на клиента чрез управление на конфигурацията на продукта [Инсталиране], както и събиране на телеметрия [Telemetry] от инсталирани продукти.

В допълнение към тях могат да се разграничат отделни етапи: мониторинг на състоянието на инфраструктурата [InfMonitoring], версия на изходния код [SourceCodeControl], подготовка на среда за изграждане [Prepare], управление на проекти [Workflow], предоставяне на екипи с инструменти за комуникация [Communication], сертифициране на продукта [ Сертифициране] и осигуряване на самодостатъчност на CI процесите [CISelfSufficiency] (например независимост на сглобките от Интернет). Десетки стъпки в нашите процеси дори няма да бъдат разглеждани, защото са много специфични.

Ще бъде много по-лесно да разберете и разгледате целия производствен процес, ако е представен във формата технологична карта; това е таблица, в която отделните производствени етапи и декомпозирани стъпки на модела са записани в редове, а в колони описание на това, което се прави на всеки етап или стъпка. Основният акцент е поставен върху ресурсите, които осигуряват всеки етап, и разграничаването на зоните на отговорност.

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

В нашата компания картата се генерира автоматично от шаблона jinja като обикновен HTML файл и след това се качва на сървъра на GitLab Pages. Можете да видите екранна снимка с пример за напълно генерирана карта по ссылке.

Щракването върху изображението ще го отвори в пълен размер

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

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

Картата се състои от няколко части:

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

Вземане на решения на базата на технологичната карта

След разглеждане на картата е възможно да се предприемат някои действия - в зависимост от ролята на служителя в компанията (мениджър развитие, продуктов мениджър, разработчик или тестер):

• разбере какви етапи липсват в реален продукт или проект и прецени необходимостта от тяхното изпълнение;
• разграничете зоните на отговорност между няколко отдела, ако работят на различни етапи;
• съгласуват договори на входа и изхода на етапите;
• интегрирайте вашия етап на работа в цялостния процес на развитие;
• по-точно да оцени необходимостта от ресурси, които осигуряват всеки от етапите.

Обобщавайки всичко по -горе

Маршрутът е многофункционален, разширим и лесен за поддръжка. Много по-лесно е да се разработи и поддържа описание на процеси в тази форма, отколкото в строг академичен IDEF0 модел. В допълнение, табличното описание е по-просто, по-познато и по-добре структурирано от функционалния модел.

За техническата реализация на стъпките разполагаме със специален вътрешен инструмент CrossBuilder - инструмент за слоеве между CI системи, услуги и инфраструктура. Разработчикът не трябва да реже мотора си: в нашата CI система е достатъчно да изпълните един от скриптовете (така наречената задача) на инструмента CrossBuilder, който ще го изпълни правилно, като вземе предвид характеристиките на нашата инфраструктура .

Резултати от

Статията се оказа доста дълга, но това е неизбежно, когато се описва моделирането на сложни процеси. В заключение бих искал накратко да поправя нашите основни идеи:

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

В следващите статии ще опишем по-подробно какви технически инструменти се използват за изпълнение на определени технологични етапи на нашата карта.

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

• Александър Паздников — Ръководител отдел автоматизация (DevOps) в Positive Technologies
• Тимур Гилмулин - Депутат Ръководител на отдел Автоматизация (DevOps) в Positive Technologies

Източник: www.habr.com