Şəkil:
Hamıya salam! Biz şirkətin avtomatlaşdırma mühəndisləriyik və biz şirkətin məhsullarının inkişafını dəstəkləyirik: biz tərtibatçılar tərəfindən kod xəttinin verilməsindən tutmuş hazır məhsulların və yeniləmə serverlərində lisenziyaların nəşrinə qədər bütün montaj boru kəmərini dəstəkləyirik. Bizi qeyri-rəsmi olaraq DevOps mühəndisləri adlandırırlar. Bu yazıda proqram təminatının istehsalı prosesinin texnoloji mərhələləri, onları necə gördüyümüz və necə təsnif etdiyimiz haqqında danışmaq istəyirik.
Materialdan siz çox məhsulun inkişafının əlaqələndirilməsinin mürəkkəbliyi, texnoloji xəritənin nə olduğu və həllərin sadələşdirilməsinə və təkrarlanmasına necə kömək etdiyini, inkişaf prosesinin əsas mərhələləri və addımlarının nədən ibarət olduğunu, məsuliyyət sahələrinin necə olduğunu öyrənəcəksiniz. DevOps və şirkətimizdəki komandalar arasında.
Xaos və DevOps haqqında
Qısaca desək, DevOps konsepsiyasına inkişaf alətləri və xidmətləri, həmçinin onlardan istifadə üçün metodologiyalar və ən yaxşı təcrübələr daxildir. Qlobal olanı ayırd edək qol şirkətimizdə DevOps ideyalarının həyata keçirilməsindən: bu, kəmiyyət baxımından məhsulların istehsalı və saxlanması xərclərinin ardıcıl azalmasıdır (insan-saat və ya maşın saatları, CPU, RAM, Disk və s.). Bütün şirkət səviyyəsində inkişafın ümumi dəyərini azaltmağın ən asan və ən bariz yolu tipik seriyalı tapşırıqların yerinə yetirilməsi xərclərini minimuma endirmək istehsalın bütün mərhələlərində. Bəs bu mərhələlər hansılardır, onları ümumi prosesdən necə ayırmaq olar, hansı addımlardan ibarətdir?
Şirkət bir məhsul hazırlayanda hər şey az-çox aydın olur: adətən ümumi yol xəritəsi və inkişaf sxemi mövcuddur. Bəs məhsul xətti genişləndikdə və daha çox məhsul olduqda nə etməli? İlk baxışdan onların oxşar prosesləri və montaj xətləri var və loglarda və skriptlərdə “X fərqləri tap” oyunu başlayır. Bəs aktiv inkişafda olan 5+ layihə varsa və bir neçə il ərzində hazırlanmış bir neçə versiyaya dəstək tələb olunursa? Məhsul boru kəmərlərində mümkün olan maksimum sayda həlli təkrar istifadə etmək istəyirik, yoxsa hər biri üçün unikal inkişafa pul xərcləməyə hazırıq?
Unikallıq və serial həllər arasında tarazlığı necə tapmaq olar?
Bu suallar 2015-ci ildən qarşımızda getdikcə daha tez-tez yaranmağa başladı. Məhsulların sayı artdı və biz bu məhsulların montaj xətlərini dəstəkləyən avtomatlaşdırma şöbəmizi (DevOps) minimuma endirməyə çalışdıq. Eyni zamanda, məhsullar arasında mümkün qədər çox həll yolu təkrarlamaq istədik. Axı niyə on məhsulda eyni şeyi müxtəlif üsullarla edirsiniz?
İnkişaf direktoru: "Uşaqlar, biz bir şəkildə DevOps-un məhsullar üçün nə etdiyini qiymətləndirə bilərikmi?"
Biz: "Bilmirik, biz belə bir sual verməmişik, amma hansı göstəricilərə diqqət edilməlidir?"
İnkişaf direktoru: "Kim bilir! Düşünün…”
O məşhur filmdəki kimi: "Mən oteldəyəm!.." - "Uh... Mənə yol göstərə bilərsənmi?" Düşündükdə belə qənaətə gəldik ki, ilk növbədə məhsulların son vəziyyətləri barədə qərar verməliyik; bu bizim ilk hədəfimiz oldu.
Beləliklə, 10-dan 200 nəfərə qədər kifayət qədər böyük komandalarla bir çox məhsulu necə təhlil edirsiniz və həlləri təkrarlayarkən ölçülə bilən ölçüləri necə müəyyənləşdirirsiniz?
1:0 xaos və ya çiyin bıçaqlarında DevOps lehinə
Biz BPwin seriyasından IDEF0 diaqramlarını və müxtəlif iş prosesi diaqramlarını tətbiq etməyə çalışmaqla başladıq. Qarışıqlıq növbəti layihənin növbəti mərhələsinin beşinci kvadratından sonra başladı və hər bir layihə üçün bu kvadratlar 50+ addım altında uzun pitonun quyruğunda çəkilə bilər. Kədərləndim və aya qışqırmaq istədim - bu ümumiyyətlə uyğun deyildi.
Tipik istehsal vəzifələri
İstehsal proseslərinin modelləşdirilməsi çox mürəkkəb və əziyyətli işdir: müxtəlif şöbələrdən və istehsal zəncirlərindən çoxlu məlumat toplamaq, emal etmək və təhlil etmək lazımdır. Bu barədə daha ətraflı məqalədə oxuya bilərsiniz ".
İstehsal prosesimizi modelləşdirməyə başlayanda qarşımızda konkret məqsəd var idi - şirkətimizin məhsullarının hazırlanmasında iştirak edən hər bir işçiyə və layihə menecerlərinə çatdırmaq:
- məhsullar və onların komponentləri, bir kod xəttinin verilməsindən başlayaraq, quraşdırıcılar və yeniləmələr şəklində müştəriyə necə çatır,
- məhsulların istehsalının hər bir mərhələsi üçün hansı resurslar təmin edilir,
- hər mərhələdə hansı xidmətlər iştirak edir,
- hər bir mərhələ üçün məsuliyyət sahələrinin necə ayrılması,
- hər bir mərhələnin giriş və çıxışında hansı müqavilələr mövcuddur.
Şəklin üzərinə kliklədikdə onu tam ölçüdə açacaq.
Şirkətdəki işimiz bir neçə funksional sahəyə bölünür. İnfrastrukturun istiqaməti idarənin bütün “dəmir” resurslarının işinin optimallaşdırılması, eləcə də virtual maşınların və onlarda mühitin yerləşdirilməsinin avtomatlaşdırılması ilə məşğuldur. Monitorinq istiqaməti 24/7 xidmətin icrasına nəzarəti təmin edir; biz həmçinin tərtibatçılar üçün bir xidmət kimi monitorinq təqdim edirik. İş axını istiqaməti komandaları inkişaf və sınaq proseslərini idarə etmək, kodun vəziyyətini təhlil etmək və layihələr üzrə analitika əldə etmək üçün alətlər təqdim edir. Və nəhayət, webdev istiqaməti GUS və FLUS yeniləmə serverlərində buraxılışların nəşrini, həmçinin LicenseLab xidmətindən istifadə edən məhsulların lisenziyalaşdırılmasını təmin edir. İstehsal boru kəmərini dəstəkləmək üçün biz tərtibatçılar üçün çoxlu müxtəlif dəstək xidmətləri qurduq və onlara xidmət göstərdik (köhnə görüşlərdə onlardan bəziləri haqqında hekayələri dinləyə bilərsiniz: и). Biz həmçinin daxili avtomatlaşdırma vasitələrini, o cümlədən .
Son beş il ərzində işimiz eyni tipli və gündəlik əməliyyatların çoxunu topladı və digər şöbələrdən olan tərtibatçılarımız əsasən sözdə olanlardan gəlirlər. tipik vəzifələr, həlli tam və ya qismən avtomatlaşdırılmışdır, ifaçılar üçün çətinlik yaratmır və əhəmiyyətli miqdarda iş tələb etmir. Aparıcı sahələrlə birlikdə biz bu cür vəzifələri təhlil etdik və işin ayrı-ayrı kateqoriyalarını müəyyən edə bildik və ya istehsal addımları, mərhələlər bölünməz addımlara bölündü və bir neçə mərhələ toplanır istehsal prosesi zənciri.
Texnoloji zəncirin ən sadə nümunəsi şirkət daxilində məhsullarımızın hər birinin yığılması, yerləşdirilməsi və sınaqdan keçirilməsi mərhələləridir. Öz növbəsində, məsələn, qurma mərhələsi bir çox ayrı tipik addımlardan ibarətdir: GitLab-dan mənbələrin yüklənməsi, asılılıqların və 3-cü tərəf kitabxanalarının hazırlanması, vahid testi və statik kodun təhlili, GitLab CI-də qurma skriptinin icrası, repozitoriyada artefaktların dərc edilməsi. Daxili ChangelogBuilder alətimiz vasitəsilə artefakt və buraxılış qeydlərinin yaradılması.
Tipik DevOps tapşırıqları haqqında Habré haqqındakı digər məqalələrimizdə oxuya bilərsiniz: ""Və".
Bir çox tipik istehsal zəncirləri əmələ gəlir istehsal prosesi. Prosesləri təsvir etmək üçün standart yanaşma funksional IDEF0 modellərindən istifadə etməkdir.
İstehsal CI prosesinin modelləşdirilməsinə bir nümunə
Biz davamlı inteqrasiya sistemi üçün standart layihələrin hazırlanmasına xüsusi diqqət yetirmişik. Bu, sözdə olanı vurğulayaraq layihələrin birləşməsinə nail olmağa imkan verdi promosyonlarla qurma sxemini buraxın.
Bu necə işləyir. Bütün layihələr tipik görünür: bunlara Artifactory-də snapshot repozitoriyasına düşən montajların konfiqurasiyası daxildir, bundan sonra onlar yerləşdirilir və sınaq skamyalarında sınaqdan keçirilir və sonra buraxılış deposuna yüksəldilir. Artifactory xidməti komandalar və digər xidmətlər arasında bütün qurma artefaktları üçün vahid paylama nöqtəsidir.
Buraxılış sxemimizi çox sadələşdirsək və ümumiləşdirsək, o, aşağıdakı addımları ehtiva edir:
- çarpaz platforma məhsul montajı,
- sınaq stendlərinə yerləşdirmə,
- funksional və digər testlərin aparılması,
- Artifactory-də depoları buraxmaq üçün sınaqdan keçirilmiş quruluşları təşviq etmək,
- yeniləmə serverlərində buraxılışların nəşri,
- montajların və yeniliklərin istehsala çatdırılması,
- məhsulun quraşdırılmasına və yenilənməsinə başlamaq.
Məsələn, funksional IDEF0 modeli şəklində bu tipik buraxılış sxeminin (bundan sonra sadəcə Model) texnoloji modelini nəzərdən keçirin. O, bizim CI prosesimizin əsas mərhələlərini əks etdirir. IDEF0 modelləri sözdə istifadə edirlər ICOM notasiyası (Giriş-Nəzarət-Çıxış-Mexanizm) hər mərhələdə hansı resurslardan istifadə edildiyini, hansı qayda və tələblərə əsaslanaraq işin yerinə yetirildiyini, nəticənin nə olduğunu və hansı mexanizmlərin, xidmətlərin və ya insanların müəyyən bir mərhələni həyata keçirdiyini təsvir etmək.
Şəklin üzərinə kliklədikdə onu tam ölçüdə açacaq.
Bir qayda olaraq, funksional modellərdə proseslərin təsvirini parçalamaq və detallaşdırmaq daha asandır. Amma elementlərin sayı artdıqca onlarda nəyisə başa düşmək getdikcə çətinləşir. Ancaq real inkişafda köməkçi mərhələlər də var: monitorinq, məhsulun sertifikatlaşdırılması, iş axınının avtomatlaşdırılması və s. Məhz miqyas probleminə görə bu təsviri tərk etdik.
Ümidin doğulması
Bir kitabda texnoloji prosesləri (yeri gəlmişkən, bu gün də bir çox dövlət müəssisələrində və universitetlərdə istifadə olunur) təsvir edən köhnə sovet xəritələrinə rast gəldik. Gözləyin, gözləyin, çünki bizim də iş axınımız var!.. Mərhələlər, nəticələr, ölçülər, tələblər, göstəricilər və sair var... Nə üçün axın cədvəllərini məhsul boru kəmərlərimizə də tətbiq etməyə çalışmayaq? Bir hiss var idi: “Budur! Düzgün ipi tapdıq, onu yaxşı çəkməyin vaxtı gəldi!
Sadə bir cədvəldə məhsulları sütunlar, texnoloji mərhələləri və məhsul boru kəməri addımlarını sətirlər üzrə qeyd etməyə qərar verdik. Mərhələlər məhsulun qurulması addımı kimi böyük bir şeydir. Və addımlar daha kiçik və daha təfərrüatlı bir şeydir, məsələn, mənbə kodunu quraşdırma serverinə endirmə addımı və ya kodun tərtibi addımı.
Xəritənin sətir və sütunlarının kəsişmə nöqtələrində müəyyən bir mərhələ və məhsul üçün statuslar qoyuruq. Statuslar üçün bir sıra dövlətlər müəyyən edilmişdir:
- Məlumat yoxdur - və ya uyğunsuz. Məhsulda bir mərhələyə olan tələbi təhlil etmək lazımdır. Ya təhlillər artıq aparılıb, lakin hazırda mərhələyə ehtiyac yoxdur, ya da iqtisadi cəhətdən əsaslandırılmayıb.
- Təxirə salındı - ya da hazırda aktual deyil. Kəmərdə mərhələ lazımdır, lakin bu il həyata keçirmək üçün heç bir qüvvə yoxdur.
- Planlaşdırılıb. Mərhələnin bu il həyata keçirilməsi planlaşdırılır.
- Həyata keçirilən. Boru kəmərindəki mərhələ tələb olunan həcmdə həyata keçirilir.
Cədvəlin doldurulması layihə üzrə başladı. Əvvəlcə bir layihənin mərhələləri və mərhələləri təsnif edilib və onlar üçün statuslar qeydə alınıb. Sonra növbəti layihəni götürdülər, oradakı statusları düzəltdilər və əvvəlki layihələrdə çatışmayan mərhələləri, addımları əlavə etdilər. Nəticədə biz bütün hasilat boru kəmərimizin mərhələlərini və mərhələlərini və konkret layihədə onların statuslarını əldə etdik. Məhsul boru kəməri səriştəsi matrisinə bənzər bir şey ortaya çıxdı. Biz belə bir matrisi texnoloji xəritə adlandırdıq.
Texnoloji xəritənin köməyi ilə biz ilin iş planlarını və birlikdə nail olmaq istədiyimiz hədəfləri komandalarla əsaslı şəkildə əlaqələndiririk: bu il layihəyə hansı mərhələləri əlavə edirik, hansını isə sonraya buraxırıq. Həmçinin, iş zamanı yalnız bir məhsul üçün tamamladığımız mərhələlərdə təkmilləşdirmələrimiz ola bilər. Sonra xəritəmizi genişləndiririk və bu təkmilləşdirməni bir mərhələ və ya yeni bir addım kimi təqdim edirik, sonra hər bir məhsul üçün təhlil edirik və təkmilləşdirmənin təkrarlanmasının mümkünlüyünü öyrənirik.
Onlar bizə etiraz edə bilərlər: “Bu, əlbəttə ki, yaxşıdır, yalnız zaman keçdikcə addımların və mərhələlərin sayı həddindən artıq çoxalacaq. Necə olmaq?
Biz hər bir mərhələ və addım üçün tələblərin standart və kifayət qədər tam təsvirlərini təqdim etdik ki, onlar şirkət daxilindəki hər kəs tərəfindən eyni şəkildə başa düşülsün. Zamanla, təkmilləşdirmələr tətbiq olunduqca, bir addım başqa bir mərhələyə və ya addıma hopdurula bilər və sonra onlar "yıxılacaq". Eyni zamanda, bütün tələblər və texnoloji nüanslar ümumiləşdirmə mərhələsinin və ya addımının tələblərinə uyğundur.
Təkrarlanan həllərin təsirini necə qiymətləndirmək olar? Biz son dərəcə sadə bir yanaşmadan istifadə edirik: yeni mərhələnin həyata keçirilməsi üçün ilkin kapital xərclərini illik ümumi məhsul məsrəflərinə aid edirik, sonra isə təkrarlama zamanı hamıya bölürük.
İnkişafın hissələri artıq xəritədə mərhələlər və addımlar kimi göstərilir. Biz tipik mərhələlər üçün avtomatlaşdırmanın tətbiqi ilə məhsulun maya dəyərinin aşağı salınmasına təsir göstərə bilərik. Bundan sonra biz keyfiyyət xüsusiyyətlərindəki dəyişiklikləri, kəmiyyət göstəricilərini və komandalar tərəfindən əldə edilən mənfəəti (qənaətdə adam-saat və ya maşın-saat) nəzərdən keçiririk.
İstehsal prosesinin texnoloji xəritəsi
Bütün mərhələlərimizi və addımlarımızı atsaq, onları etiketlərlə şifrələsək və bir zəncirə genişləndirsək, o, çox uzun və anlaşılmaz olacaq (yalnız məqalənin əvvəlində danışdığımız "piton quyruğu") :
[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]Bunlar məhsulların qurulması [Yaratmaq], onların sınaq serverlərinə yerləşdirilməsi [Yerləşdirmə], sınaqdan keçirilməsi [Test], sınaqların nəticələrinə əsasən depoları buraxmaq üçün qurulmaların təşviqi [Təqdim et], lisenziyaların yaradılması və dərc edilməsi [Lisenziya], nəşr [ Yayımla] GUS yeniləmə serverində və FLUS yeniləmə serverlərinə çatdırılma, Məhsul Konfiqurasiya İdarəetmə [Quraşdırma] istifadə edərək müştərinin infrastrukturunda məhsul komponentlərinin quraşdırılması və yenilənməsi, həmçinin quraşdırılmış məhsullardan telemetriya [Telemetri] kolleksiyası.
Bunlara əlavə olaraq, ayrı-ayrı mərhələləri ayırd etmək olar: infrastruktur vəziyyətinin monitorinqi [InfMonitoring], mənbə kodunun versiyalaşdırılması [SourceCodeControl], ətraf mühitin qurulması [Hazırla], layihənin idarə edilməsi [İş axını], komandaların kommunikasiya vasitələri ilə təmin edilməsi [Rabitə], məhsulun sertifikatlaşdırılması [ sertifikatlaşdırma] və CI proseslərinin özünü təmin etməsi [CISelfSufficiency] (məsələn, montajların İnternetdən müstəqilliyi). Proseslərimizdə onlarla addım hətta nəzərə alınmayacaq, çünki onlar çox konkretdir.
Formada təqdim olunarsa, bütün istehsal prosesini başa düşmək və baxmaq çox asan olacaq texnoloji xəritə; bu, Modelin ayrı-ayrı istehsal mərhələlərinin və parçalanmış addımlarının sətirlərdə, sütunlarda isə hər mərhələdə və ya addımda görülən işlərin təsvirinin yazıldığı cədvəldir. Əsas vurğu hər bir mərhələni təmin edən resurslara və məsuliyyət sahələrinin sərhədlərinin müəyyənləşdirilməsinə yönəldilir.
Xəritə bizim üçün bir növ təsnifatdır. O, məhsulların istehsalının böyük texnoloji hissələrini əks etdirir. Bunun sayəsində avtomatlaşdırma komandamızın tərtibatçılarla qarşılıqlı əlaqəsi və avtomatlaşdırma mərhələlərinin həyata keçirilməsini birgə planlaşdırması, həmçinin bunun üçün hansı əmək xərcləri və resursların (insan və aparat) tələb olunacağını anlamaq asanlaşdı.
Şirkətimizin daxilində xəritə avtomatik olaraq jinja şablonundan adi HTML faylı kimi yaradılır və sonra GitLab Səhifələr serverinə yüklənir. Tam yaradılmış xəritə nümunəsi ilə ekran görüntüsünə baxıla bilər .
Şəklin üzərinə kliklədikdə onu tam ölçüdə açacaq.
Bir sözlə, texnoloji xəritə tipik funksionallığı olan aydın təsnifləşdirilmiş blokları əks etdirən istehsal prosesinin ümumiləşdirilmiş mənzərəsidir.
Yol xəritəmizin strukturu
Xəritə bir neçə hissədən ibarətdir:
- Başlıq sahəsi - burada xəritənin ümumi təsviri verilir, əsas anlayışlar təqdim olunur, istehsal prosesinin əsas resursları və nəticələri müəyyən edilir.
- Dashboard - burada ayrı-ayrı məhsullar üçün məlumatların göstərilməsinə nəzarət edə bilərsiniz, həyata keçirilən mərhələlərin və ümumilikdə bütün məhsullar üçün addımların xülasəsi verilir.
- Texnoloji xəritə - texnoloji prosesin cədvəl təsviri. Xəritədə:
- bütün mərhələlər, addımlar və onların kodları verilir;
- mərhələlərin qısa və tam təsviri verilir;
- hər mərhələdə istifadə olunan giriş resursları və xidmətlər göstərilir;
- hər bir mərhələnin və ayrıca addımın nəticələri göstərilir;
- hər bir mərhələ və addım üçün məsuliyyət sahəsi göstərilir;
- HDD (SSD), RAM, vCPU kimi texniki resurslar və bu mərhələdə işi dəstəkləmək üçün lazım olan işçi saatları, həm indiki anda - fakt, həm də gələcəkdə - plan müəyyən edilmişdir;
- hər bir məhsul üçün onun üçün hansı texnoloji mərhələlərin və ya addımların həyata keçirildiyi, həyata keçirilməsi planlaşdırıldığı, aidiyyətinin olmadığı və ya həyata keçirilmədiyi göstərilir.
Texnoloji xəritə əsasında qərarların qəbulu
Xəritəni araşdırdıqdan sonra bəzi tədbirlər görmək mümkündür - işçinin şirkətdəki rolundan asılı olaraq (inkişaf meneceri, məhsul meneceri, tərtibatçı və ya sınaqçı):
- real məhsulda və ya layihədə hansı mərhələlərin çatışmadığını anlamaq və onların həyata keçirilməsi ehtiyacını qiymətləndirmək;
- müxtəlif mərhələlərdə işləyirlərsə, bir neçə şöbə arasında məsuliyyət sahələrini məhdudlaşdırın;
- mərhələlərin giriş və çıxışlarında müqavilələri razılaşdırmaq;
- iş mərhələnizi ümumi inkişaf prosesinə inteqrasiya edin;
- mərhələlərin hər birini təmin edən resurslara ehtiyacı daha dəqiq qiymətləndirmək.
Yuxarıda göstərilənlərin hamısını ümumiləşdirərək
Marşrutlama çox yönlüdür, genişlənir və saxlanılması asandır. Bu formada proseslərin təsvirini hazırlamaq və saxlamaq ciddi akademik IDEF0 modelindən daha asandır. Bundan əlavə, cədvəl təsviri funksional modeldən daha sadə, daha tanış və daha yaxşı strukturlaşdırılmışdır.
Addımların texniki həyata keçirilməsi üçün bizim xüsusi daxili alətimiz var - CrossBuilder - CI sistemləri, xidmətləri və infrastrukturu arasında təbəqə aləti. Tərtibatçının velosipedini kəsməsinə ehtiyac yoxdur: CI sistemimizdə, infrastrukturumuzun xüsusiyyətlərini nəzərə alaraq onu düzgün yerinə yetirəcək CrossBuilder alətinin skriptlərindən birini (sözdə vəzifə) işə salmaq kifayətdir. .
Nəticələri
Məqalə kifayət qədər uzun oldu, lakin mürəkkəb proseslərin modelləşdirilməsini təsvir edərkən bu qaçılmazdır. Sonda əsas fikirlərimizi qısaca qeyd etmək istərdim:
- Şirkətimizdə DevOps ideyalarının həyata keçirilməsində məqsəd şirkət məhsullarının istehsal və texniki xidmət xərclərini kəmiyyət baxımından (insan-saat və ya maşın saatı, vCPU, RAM, Disk) ardıcıl olaraq azaltmaqdır.
- İnkişafın ümumi dəyərini azaltmağın yolu tipik seriyalı tapşırıqların yerinə yetirilməsi xərclərini minimuma endirməkdir: texnoloji prosesin mərhələləri və addımları.
- Tipik bir tapşırıq həlli tam və ya qismən avtomatlaşdırılmış, ifaçılar üçün çətinlik yaratmayan və əhəmiyyətli əmək xərcləri tələb etməyən bir vəzifədir.
- İstehsal prosesi mərhələlərdən ibarətdir, mərhələlər müxtəlif miqyaslı və əhatəli tipik vəzifələr olan bölünməz addımlara bölünür.
- Fərqli tipik tapşırıqlardan biz funksional IDEF0 modeli və ya daha sadə texnoloji xəritə ilə təsvir edilə bilən mürəkkəb texnoloji zəncirlərə və istehsal prosesinin çoxsəviyyəli modellərinə gəldik.
- Texnoloji xəritə istehsal prosesinin mərhələ və mərhələlərinin cədvəl şəklində təsviridir. Ən vacibi: xəritə bütün prosesi bütövlükdə, onları təfərrüatlandırmaq imkanı ilə böyük parçalarda görməyə imkan verir.
- Texnoloji xəritə əsasında konkret məhsulda mərhələlərin tətbiqi zərurətini qiymətləndirmək, məsuliyyət sahələrini müəyyənləşdirmək, mərhələlərin giriş və çıxışlarında müqavilələri razılaşdırmaq və resurslara olan tələbatı daha dəqiq qiymətləndirmək mümkündür.
Növbəti məqalələrdə xəritəmizdə müəyyən texnoloji mərhələləri həyata keçirmək üçün hansı texniki vasitələrdən istifadə edildiyini daha ətraflı təsvir edəcəyik.
Məqalə müəllifləri:
- — Positive Technologies-də Avtomatlaşdırma (DevOps) rəhbəri
- - Müavin Positive Technologies-də Avtomatlaşdırma Departamentinin (DevOps) rəhbəri
Mənbə: www.habr.com