Picture:
Баарына салам! Биз компаниянын автоматташтыруу боюнча инженерлерибиз жана биз компаниянын өнүмдөрүн өнүктүрүүгө колдоо көрсөтөбүз: биз иштеп чыгуучулар тарабынан коддун линиясын тапшыргандан баштап, даяр продукцияны жана жаңыртуу серверлериндеги лицензияларды жарыялоого чейинки бүтүндөй монтаждык түтүктү колдойбуз. Бейрасмий түрдө бизди DevOps инженерлери деп аташат. Бул макалада биз программалык камсыздоону өндүрүү процессинин технологиялык этаптары, аларды кантип көрөбүз жана аларды кантип классификациялайбыз.
Материалдан сиз көп продуктуну иштеп чыгууну координациялоонун татаалдыгы, технологиялык карта деген эмне жана ал чечимдерди уюштурууга жана кайталоого кантип жардам берет, иштеп чыгуу процессинин негизги этаптары жана этаптары эмнеден турганы, жоопкерчилик чөйрөлөрү кантип бөлүнгөнү жөнүндө биле аласыз. DevOps жана биздин компаниянын командаларынын ортосунда.
Chaos жана DevOps жөнүндө
Кыскача белгилеп кетели, DevOps концепциясы иштеп чыгуу куралдарын жана кызматтарын, ошондой эле аларды колдонуу боюнча методологияларды жана мыкты тажрыйбаларды камтыйт. Глобалдыкты баса белгилейли цель DevOps идеяларын биздин компанияда ишке ашыруудан: бул продукцияны өндүрүүгө жана тейлөөгө кеткен чыгымдардын ырааттуу түрдө сандык жактан төмөндөшү (адам-саат же машина-саат, CPU, RAM, Диск ж.б.). Компаниянын деңгээлинде иштеп чыгуунун жалпы баасын төмөндөтүүнүн эң жөнөкөй жана эң айкын жолу типтүү сериялык милдеттерди аткаруу үчүн чыгымдарды азайтуу өндүрүштүн бардык этаптарында. Бирок бул этаптар кандай, аларды жалпы процесстен кантип айырмалоого болот, алар кандай баскычтардан турат?
Компания бир продуктуну иштеп жатканда, баары аздыр-көптүр түшүнүктүү болот: адатта жалпы жол картасы жана өнүгүү схемасы бар. Бирок продукт линиясы кеңейип, товарлар көбөйгөндө эмне кылуу керек? Бир караганда, алар окшош процесстерге жана конвейерлерге ээ жана журналдарда жана скрипттерде "X айырмачылыктарды табуу" оюну башталат. Эгер активдүү иштеп чыгууда 5+ долбоорлор бар болсо жана бир нече жыл бою иштелип чыккан бир нече версияларды колдоо керек болсочы? Биз продукт түтүктөрүндө мүмкүн болушунча көп чечимдерди кайра колдонгубуз келеби же ар бири үчүн уникалдуу өнүгүүгө акча коротууга даярбызбы?
Чечимдердин уникалдуулугу менен сериялуулугунун ортосундагы балансты кантип табууга болот?
Бул суроолор биздин алдыбызда 2015-жылдан баштап көбүрөөк пайда боло баштады. Продукциялардын саны өстү жана биз бул буюмдарды конвейердик линияларды колдогон автоматташтыруу бөлүмүн (DevOps) минималдуу кеңейтүүгө аракет кылдык. Ошол эле учурда мен өнүмдөрдүн ортосунда мүмкүн болушунча көп чечимдерди кайталагым келди. Кантсе да, эмне үчүн он буюмда бир эле нерсени ар кандай жолдор менен жасашат?
өнүктүрүү директору: "Балдар, биз DevOps өнүмдөр үчүн эмне кылып жатканын баалай алабызбы?"
биз: "Биз билбейбиз, биз бул суроону берген жокпуз, бирок кандай көрсөткүчтөрдү эсептөө керек?"
өнүктүрүү директору: "Ким билет! Ойлон..."
Ошол атактуу тасмадагыдай: “Мен мейманканага баратам!..” – “Эх... Мага жол көрсөтө аласызбы?” Ойлонуп отуруп, биз адегенде продукциянын акыркы абалын чечишибиз керек деген жыйынтыкка келдик; бул биздин биринчи максатыбыз болуп калды.
Ошентип, 10дон 200гө чейин адамдардан турган бир топ чоң командалар менен ондогон продуктыларды кантип талдап, чечимдерди кайталоодо өлчөнүүчү көрсөткүчтөрдү кантип аныктоого болот?
1:0 Chaos пайдасына, же бычактагы DevOps
Биз BPwin сериясынан IDEF0 диаграммаларын жана ар кандай бизнес процесстеринин диаграммаларын колдонууга аракет кылуу менен баштадык. Башаламандык кийинки долбоордун кийинки этабынын бешинчи квадратынан кийин башталды жана ар бир долбоор үчүн бул квадраттарды 50+ кадам менен узун питондун куйругун тартса болот. Мен капаланып, айга ыйлагым келди - ал такыр туура келген жок.
Типтүү өндүрүштүк милдеттери
Өндүрүш процесстерин моделдөө - бул абдан татаал жана түйшүктүү иш: ар кандай бөлүмдөрдөн жана өндүрүш чынжырларынан көптөгөн маалыматтарды чогултуу, иштеп чыгуу жана талдоо керек. Бул тууралуу кененирээк макаладан окуй аласыз "«.
Өндүрүш процессибизди моделдештирип баштаганда, биз белгилүү бир максатты койдук - биздин компаниянын продукциясын иштеп чыгууга катышкан ар бир кызматкерге жана долбоордун менеджерлерине жеткирүү:
- өнүмдөр жана алардын компоненттери, коддун сызыгынан баштап, орнотуучулар жана жаңыртуулар түрүндө кардарга кантип жетет,
- продукт өндүрүүнүн ар бир этабында кандай ресурстар менен камсыз кылынат,
- ар бир этапта кандай кызматтар тартылган,
- ар бир этап үчүн жоопкерчилик чөйрөлөрү кантип бөлүнгөн,
- ар бир этаптын киришинде жана чыгышында кандай келишимдер бар.
Толук өлчөмдө ачуу үчүн сүрөттү басыңыз
Биздин компаниядагы ишибиз бир нече функционалдык багыттарга бөлүнөт. Инфраструктура бөлүмү бөлүмдүн бардык аппараттык ресурстарынын иштешин оптималдаштыруу, ошондой эле виртуалдык машиналарды жана аларга айлана-чөйрөнү жайгаштырууну автоматташтыруу менен алектенет. Мониторинг багыты 24/7 кызматтардын аткарылышын көзөмөлдөөнү камсыз кылат; Биз ошондой эле иштеп чыгуучулар үчүн кызмат катары мониторингди камсыз кылабыз. Иш агымынын багыты командаларды иштеп чыгуу жана тестирлөө процесстерин башкаруу, коддун абалын талдоо жана долбоорлор боюнча аналитика алуу үчүн куралдар менен камсыз кылат. Акырында, webdev багыты GUS жана FLUS жаңыртуу серверлеринде релиздерди жарыялоону, ошондой эле LicenseLab кызматын колдонуу менен өнүмдөрдү лицензиялоону камсыздайт. Өндүрүш түтүгүн колдоо үчүн биз иштеп чыгуучулар үчүн көптөгөн ар кандай колдоо кызматтарын орнотуп, тейлейбиз (сиз алардын айрымдары тууралуу окуяларды эски жолугушууларда уга аласыз: и). Биз ошондой эле ички автоматташтыруу куралдарын, анын ичинде иштеп чыгуу .
Акыркы беш жылдын ичинде биздин ишибизде көптөгөн окшош жана көнүмүш операциялар топтолду жана типтүү милдеттери, анын чечилиши толук же жарым-жартылай автоматташтырылган, аткаруучулар үчүн кыйынчылык туудурбайт жана олуттуу жумушту талап кылбайт. Алдынкы участоктор менен бирдикте мындай милдеттерди талдап чыгып, иштин айрым категорияларын аныктай алдык, же өндүрүш этаптары, этаптар бөлүнгүс кадамдарга бөлүнөт жана бир нече этап кошулат өндүрүш процессинин чынжыры.
Технологиялык чынжырдын эң жөнөкөй мисалы - бул компаниянын ичиндеги ар бир продуктуну чогултуу, жайылтуу жана сыноо этаптары. Өз кезегинде, мисалы, куруу этабы көптөгөн өзүнчө стандарттык кадамдардан турат: GitLab'дан булактарды жүктөө, көз карандылыктарды жана 3-тараптык китепканаларды даярдоо, бирдикти тестирлөө жана статикалык кодду талдоо, GitLab CIде куруу скриптин аткаруу, артефакттарды репозиторийге жарыялоо. Биздин ички ChangelogBuilder куралыбыз аркылуу жасалма жана релиз эскертүүлөрүн түзүү.
Сиз Habré боюнча башка макалаларыбыздан типтүү DevOps тапшырмалары жөнүндө окуй аласыз: ""Ал эми"«.
Көптөгөн типтүү өндүрүш чынжырлары пайда болот өндүрүш процесси. Процесстерди сүрөттөөгө стандарттуу ыкма IDEF0 функционалдуу моделдерин колдонуу болуп саналат.
Өндүрүш CI процессин моделдөөнүн мисалы
Биз үзгүлтүксүз интеграциялык система үчүн типтүү долбоорлорду иштеп чыгууга өзгөчө көңүл бурдук. Бул деп аталгандарды баса белгилеп, долбоорлорду унификациялоого жетишүүгө мүмкүндүк берди жарнамалар менен куруулардын релиз диаграммасы.
Бул жерде кантип иштейт. Бардык долбоорлор типтүү көрүнөт: алар Artifactoryдеги көз ирмемдик репозиторийге баруучу ассамблеялардын конфигурациясын камтыйт, андан кийин алар жайгаштырылган жана сыноо стенддеринде сыналат, андан кийин релиз репозиторийине көтөрүлөт. Artifactory кызматы командалар жана башка кызматтар арасында бардык куруу артефакттарын бөлүштүрүү үчүн бирдиктүү чекит.
Эгерде биз чыгаруу схемабызды абдан жөнөкөйлөтүп жана жалпылай турган болсок, анда ал төмөнкү этаптарды камтыйт:
- кайчылаш-платформа продукт куруу,
- сыноо стенддерин жайгаштыруу,
- функционалдык жана башка сыноолорду ишке киргизүү,
- Artifactory репозиторийлерин чыгаруу үчүн сыналган ассамблеяларды жылдыруу,
- серверлерди жаңыртуу үчүн релиздерди жарыялоо,
- курулуштарды жана жаңыртууларды өндүрүшкө жеткирүү,
- орнотуу жана продукт жаңыртууларды ишке киргизүү.
Мисал катары, функционалдык IDEF0 модели түрүндөгү бул типтүү чыгаруу схемасынын технологиялык моделин (мындан ары жөн гана Модель деп аталат) карап көрөлү. Ал биздин CI процессибиздин негизги этаптарын чагылдырат. IDEF0 моделдери деп аталганды колдонушат ICOM белгиси (Киргизүү-башкаруу-чыгарма-механизм) ар бир этапта кандай ресурстар колдонулуп жатканын сүрөттөп берүү, кандай эрежелердин жана талаптардын негизинде иш аткарылат, кандай чыгарылат жана кандай механизмдер, кызматтар же адамдар белгилүү бир баскычты ишке ашырат.
Толук өлчөмдө ачуу үчүн сүрөттү басыңыз
Эреже катары, функционалдык моделдерде процесстердин сүрөттөлүшүн майдалоо жана деталдаштыруу оңой. Бирок элементтердин саны өскөн сайын алар жөнүндө бир нерсени түшүнүү барган сайын кыйындай берет. Бирок реалдуу өнүгүүдө көмөкчү этаптар да бар: мониторинг, продукцияны сертификациялоо, иш процесстерин автоматташтыруу жана башкалар. Дал масштабдуу көйгөйдөн улам биз бул сүрөттөөдөн баш тарттык.
Үмүттүн төрөлүшү
Бир китептен технологиялык процесстерди баяндаган эски советтик карталарды кезиктирдик (айтмакчы, алар азыркы кезде да кептеген мамлекеттик ишканаларда жана жогорку окуу жайларында колдонулат). Күтө туруңуз, күтө туруңуз, бизде да технологиялык процесс бар!.. Этаптар, жыйынтыктар, метрикалар, талаптар, көрсөткүчтөр ж.б.у.с. бар.... Эмне үчүн биздин продукциянын конвейерлерине технологиялык карталарды колдонууга аракет кылбайт? Бир сезим пайда болду: «Мына! Биз туура жипти таптык, аны жакшы тартууга убакыт келди!”
Жөнөкөй таблицада биз азыктарды мамычалар боюнча, ал эми технологиялык этаптарды жана продукт конвейеринин кадамдарын катарлар боюнча жазууну чечтик. Этаптар - бул чоң нерсе, мисалы, буюмду чогултуу. Ал эми кадамдар кичинекей жана деталдуураак нерсе, мисалы, баштапкы кодду куруу серверине жүктөө кадамы же кодду түзүү кадамы.
Картанын саптарынын жана мамычаларынын кесилишинде биз белгилүү бир этап жана продукт үчүн статустарды коёбуз. Статустар үчүн көптөгөн штаттар аныкталган:
- Эч кандай маалымат жок - же практикалык эмес. Продукциянын этабына суроо-талапты талдоо зарыл. Же талдоо жүргүзүлгөн, бирок этап учурда кереги жок же экономикалык жактан негиздүү эмес.
- Кийинкиге калтырылды - же учурда тиешеси жок. Бул куурдагы этап керек, бирок быйыл аны ишке ашырууга күч жок.
- Пландалган. Этапты быйыл ишке ашыруу пландалууда.
- Аткарылган. Трубопроводдогу этап керектуу елчемде ишке ашырылып жатат.
Таблицаны толтуруу долбоор боюнча башталды. Биринчиден, биз бир долбоордун этаптарын жана кадамдарын классификациялап, алардын статустарын жаздык. Андан кийин алар кезектеги долбоорду алып, андагы статустарды жаздырып, мурунку долбоорлордо жок болгон этаптарды жана кадамдарды кошушту. Натыйжада, биз бүт өндүрүш түтүгүбүздүн этаптарын жана кадамдарын жана алардын статустарын белгилүү бир долбоордо алдык. Натыйжада тамак-аш конвейери үчүн компетенттүүлүк матрицасына окшош нерсе. Мындай матрицаны технологиялык карта деп атадык.
Технологиялык картанын жардамы менен биз бригадалар менен жылдын иш пландарын жана биргелешип жетишүүнү каалаган максаттарды метрологиялык жактан олуттуу түрдө макулдашабыз: быйыл долбоорго кайсы этаптарды кошобуз жана кайсынысын кийинчерээк калтырабыз. Ошондой эле, биз иштеп жатканда, биз бир гана продукт үчүн аяктаган кадамдардын жакшыруусун көрүшүбүз мүмкүн. Андан кийин биз картабызды кеңейтип, бул жакшыртууну этап же жаңы кадам катары киргизебиз, андан кийин ар бир продукт үчүн анализ жүргүзүп, жакшыртууну кайталоонун максатка ылайыктуулугун табабыз.
Алар бизге каршы болушу мүмкүн: «Албетте, мунун баары жакшы, бирок убакыттын өтүшү менен кадамдардын жана этаптардын саны өтө чоң болуп калат. Мен эмне кылышым керек?
Биз ар бир этап жана кадам үчүн талаптардын стандарттуу жана толук сүрөттөлүшүн киргиздик, ошентип компаниянын ичинде аларды бардыгы бирдей түшүнөт. Убакыттын өтүшү менен, жакшыртуулар ишке ашырылган сайын, бир кадам башка баскычка же кадамга сиңиши мүмкүн - андан кийин алар кыйрап калат. Ошол эле учурда, бардык талаптар жана технологиялык нюанстар жалпылоочу баскычтын же кадамдын талаптарына туура келет.
Репликациялоочу чечимдердин таасирин кантип баалоого болот? Биз өтө жөнөкөй ыкманы колдонобуз: жаңы этапты ишке ашыруу үчүн баштапкы капиталдык чыгымдарды продукциянын жылдык жалпы чыгымдарына кошуп, андан кийин аларды кайталоодо ар кимге бөлүштүрөбүз.
Өнүгүү бөлүктөрү картада этаптар жана кадамдар катары чагылдырылган. Биз типтүү этаптар үчүн автоматташтырууну киргизүү аркылуу продукциянын өздүк наркынын төмөндөшүнө таасир эте алабыз. Андан кийин биз сапаттык мүнөздөмөлөрдүн, сандык көрсөткүчтөрдүн өзгөрүшүн жана бригадалар алган пайданы (адам-саат же үнөмдөлгөн машина-саат менен) эсептейбиз.
Өндүрүш процессинин технологиялык картасы
Эгерде биз бардык этаптарыбызды жана кадамдарыбызды алып, аларды тегдер менен коддоп, аларды бир чынжырга кеңейтсек, анда ал абдан узун жана түшүнүксүз болуп калат (так эле биз макаланын башында айткан "питон куйругу") :
[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], монтаждоо чөйрөсүн даярдоо [Даярдоо], долбоорду башкаруу [Иш агымы], командаларды байланыш куралдары менен камсыздоо [ Байланыш], продукцияны сертификациялоо [Сертификация] жана CI процесстеринин өзүн-өзү камсыз кылуу [CISelfSufficiency] (мисалы, жыйындардын Интернеттен көз карандысыздыгы). Биз процесстерибизде ондогон кадамдарды эске албайбыз, анткени алар абдан конкреттүү.
Эгерде сиз аны формада элестетсеңиз, бүт өндүрүш процессин түшүнүү жана карап көрүү бир топ жеңил болот технологиялык карта; Бул Моделдин жеке өндүрүш этаптары жана ыдыраган кадамдары саптарга жазылган таблица, ал эми ар бир этапта же кадамда жасалган иштердин сүрөттөлүшү мамычаларда. Негизги басым ар бир этапты камсыз кылган ресурстарга жана жоопкерчилик чөйрөлөрүнүн делимитациясына бурулат.
Биз үчүн карта классификатордун бир түрү. Ал продукция чыгаруунун ири технологиялык бөлүктөрүн чагылдырат. Анын аркасында биздин автоматташтыруу тобубуз үчүн иштеп чыгуучулар менен өз ара аракеттенүү жана автоматташтыруу этаптарын ишке ашырууну биргелешип пландаштыруу, ошондой эле бул үчүн кандай эмгек чыгымдары жана ресурстар (адам жана аппаратура) талап кылынарын түшүнүү оңой болуп калды.
Биздин компаниянын ичинде карта автоматтык түрдө jinja шаблонунан кадимки HTML файлы катары түзүлүп, андан кийин GitLab Pages серверине жүктөлөт. Толук түзүлгөн картанын мисалы менен скриншотту көрүүгө болот .
Толук өлчөмдө ачуу үчүн сүрөттү басыңыз
Кыскача айтканда, технологиялык карта стандарттык функционалдуулугу менен ачык классификацияланган блокторду чагылдырган өндүрүш процессинин жалпыланган сүрөтү.
Биздин технологиялык картанын структурасы
Карта бир нече бөлүктөн турат:
- Рубрика аймагы - бул жерде картанын жалпы сүрөттөлүшү, негизги түшүнүктөр киргизилет, өндүрүш процессинин негизги ресурстары жана натыйжалары аныкталат.
- Маалымат панели - бул жерде сиз жеке өнүмдөр боюнча маалыматтардын дисплейин көзөмөлдөй аласыз; бардык продуктылар үчүн жалпысынан ишке ашырылган этаптардын жана кадамдардын кыскача маалыматы берилген.
- Технологиялык карта – технологиялык процесстин таблица түрүндө сүрөттөлүшү. Картада:
- бардык этаптары, кадамдары жана алардын коддору берилет;
- этаптарынын кыскача жана толук сүрөттөлүшү берилет;
- ар бир этапта колдонулган киргизүү ресурстары жана кызматтар көрсөтүлөт;
- ар бир этаптын жана жеке кадамдын натыйжалары көрсөтүлөт;
- ар бир этап жана кадам үчүн жоопкерчилик чөйрөсү көрсөтүлөт;
- техникалык ресурстар аныкталды, мисалы HDD (SSD), RAM, vCPU жана ушул этапта ишти колдоо үчүн зарыл болгон адам-саат, азыркы учурда да - факты, ошондой эле келечекте - план;
- ар бир продукт үчүн кайсы технологиялык этаптар же кадамдар ишке ашырылгандыгы, ишке ашыруу пландаштырылганы, тиешеси жок же аткарылбай калгандыгы көрсөтүлөт.
Технологиялык картанын негизинде чечим кабыл алуу
Картаны изилдеп чыккандан кийин, сиз кызматкердин компаниядагы ролуна жараша (иштеп чыгуу менеджери, продукт менеджери, иштеп чыгуучу же сыноочу) кээ бир аракеттерди жасай аласыз:
- реалдуу продуктта же долбоордо кайсы этаптар жок экенин түшүнүү жана аларды ишке ашыруунун зарылдыгын баалоо;
- бир нече бөлүмдөрдүн ортосундагы жоопкерчилик чөйрөсүн чектөө;
- этаптарды киргизүү жана чыгаруу боюнча келишимдерди талкуулоо;
- ишиңиздин этабын жалпы өнүгүү процессине интеграциялоо;
- ар бир этапты колдоо үчүн ресурстардын зарылчылыгын такыраак баалоо.
Жогоруда айтылгандардын бардыгын жалпылап
Технологиялык карта ар тараптуу, кеңейтилүүчү жана тейлөөгө оңой. Катуу академиялык IDEF0 моделине караганда бул формада процесстин сыпаттамаларын иштеп чыгуу жана колдоо алда канча оңой. Мындан тышкары, таблицадагы сүрөттөмө функционалдык моделге караганда жөнөкөй, тааныш жана жакшыраак структураланган.
Кадамдарды техникалык ишке ашыруу үчүн биз CrossBuilder деп аталган атайын ички курал үчүн жооптуубуз - CI системалары, кызматтары жана инфраструктурасынын ортосундагы катмарлоочу курал. Иштеп чыгуучу өзүнүн велосипедин кесүүнүн кереги жок: биздин CI тутумубузда CrossBuilder куралынын скрипттеринин бирин (милдет деп аталган) иштетүү жетиштүү, ал биздин инфраструктуранын өзгөчөлүктөрүн эске алуу менен аны туура аткарат.
натыйжалары
Макала абдан узун болуп чыкты, бирок татаал процесстерди моделдештирүү сүрөттөлгөндө бул сөзсүз болот. Акырында мен негизги идеяларыбызды кыскача айткым келет:
- DevOps идеяларын биздин компанияга киргизүүнүн максаты - компаниянын продукциясын өндүрүүгө жана тейлөөгө кеткен чыгымдарды сандык мааниде (адам-саат же машина-саат, vCPU, RAM, Disk) ырааттуу түрдө төмөндөтүү.
- Иштеп чыгуунун жалпы наркын төмөндөтүүнүн жолу стандарттык сериялык тапшырмаларды аткарууга кеткен чыгымдарды минималдаштыруу болуп саналат: технологиялык процесстин этаптары жана кадамдары.
- Типтүү тапшырма - бул толугу менен же жарым-жартылай автоматташтырылган, аткаруучулар үчүн кыйынчылык туудурбаган жана олуттуу эмгек чыгымдарын талап кылбаган тапшырма.
- Өндүрүш процесси этаптардан турат, этаптар ар кандай масштабдагы жана көлөмдөгү типтүү тапшырмаларды чагылдырган бөлүнгүс кадамдарга бөлүнөт.
- Бөлүнгөн стандарттык тапшырмалардан биз татаал технологиялык чынжырларга жана өндүрүш процессинин көп баскычтуу моделдерине келдик, аларды функционалдуу IDEF0 модели же жөнөкөй технологиялык карта менен сүрөттөөгө болот.
- Агым диаграммасы - бул өндүрүш процессинин этаптарынын жана кадамдарынын таблицадагы көрүнүшү. Эң негизгиси: карта бүт процессти толугу менен, аларды майдалоо мүмкүнчүлүгү менен чоң бөлүктөрдө көрүүгө мүмкүндүк берет.
- Технологиялык картанын негизинде белгилүү бир продуктта этаптарды ишке ашыруунун зарылдыгын баалоого, жоопкерчилик чөйрөсүн чектөөгө, этаптарды киргизүү жана чыгарууга келишимдерди макулдашууга жана ресурстарга болгон муктаждыкка так баа берүүгө болот.
Кийинки макалаларда биздин картада айрым технологиялык этаптарды ишке ашыруу үчүн кандай техникалык каражаттар колдонулары жөнүндө кененирээк сүйлөшөбүз.
Макаланын авторлору:
- — Positive Technologies компаниясынын автоматташтыруу бөлүмүнүн (DevOps) башчысы
- - депутат Positive Technologies компаниясынын автоматташтыруу бөлүмүнүн (DevOps) башчысы
Source: www.habr.com