Slika:
Pozdravljeni vsi skupaj! Smo inženirji avtomatike iz podjetja in zagotavljamo podporo za razvoj izdelkov podjetja: podpiramo celoten montažni proces od objave vrstice kode s strani razvijalcev do objave končnih izdelkov in licenc na strežnikih za posodabljanje. Neuradno se imenujemo inženirji DevOps. V tem članku želimo govoriti o tehnoloških stopnjah proizvodnega procesa programske opreme, kako jih vidimo in kako jih razvrščamo.
Iz gradiva boste spoznali kompleksnost usklajevanja večproizvodnega razvoja, kaj je tehnološki zemljevid in kako pomaga organizirati in posnemati rešitve, iz katerih glavnih stopenj in korakov je sestavljen razvojni proces, kako so razmejena področja odgovornosti. med DevOps in ekipami v našem podjetju.
O Chaosu in DevOps
Naj na kratko opozorimo, da koncept DevOps vključuje razvojna orodja in storitve ter metodologije in najboljše prakse za njihovo uporabo. Izpostavimo globalno namen od implementacije DevOps idej v našem podjetju: to je dosledno zniževanje stroškov proizvodnje in vzdrževanja izdelkov v kvantitativnem smislu (človeške ure ali strojne ure, CPE, RAM, Disk itd.). Najenostavnejši in najbolj očiten način za zmanjšanje skupnih stroškov razvoja na ravni celotnega podjetja je zmanjšanje stroškov izvajanja tipičnih serijskih nalog v vseh fazah proizvodnje. Toda kaj so te faze, kako jih je mogoče razlikovati od splošnega procesa, iz katerih korakov so sestavljene?
Ko podjetje razvija en izdelek, je vse bolj ali manj jasno: običajno obstaja splošen načrt in razvojna shema. Toda kaj storiti, ko se linija izdelkov razširi in je izdelkov več? Na prvi pogled imata podobne procese in tekoče linije in igra "poišči X razlik" v dnevnikih in skriptih se začne. Kaj pa, če je v aktivnem razvoju že 5+ projektov in je potrebna podpora za več različic, razvitih več let? Ali želimo ponovno uporabiti čim več rešitev v proizvodnih programih ali smo pripravljeni porabiti denar za edinstven razvoj za vsako?
Kako najti ravnotežje med edinstvenostjo in serijskostjo rešitev?
Ta vprašanja so se pred nami začela vse pogosteje porajati od leta 2015 naprej. Število izdelkov je raslo, naš oddelek za avtomatizacijo (DevOps), ki je podpiral montažne linije teh izdelkov, smo poskušali razširiti na minimum. Hkrati sem želel prenesti čim več rešitev med izdelki. Konec koncev, zakaj narediti isto stvar v desetih izdelkih na različne načine?
Direktor razvoja: "Fantje, ali lahko nekako ocenimo, kaj DevOps naredi za izdelke?"
Mi: "Ne vemo, tega vprašanja nismo zastavili, ampak katere kazalnike je treba izračunati?"
Direktor razvoja: "Kdo ve! Pomisli ..."
Kot v tistem znanem filmu: "Grem v hotel!.." - "Uh ... Mi lahko pokažeš pot?" Po razmišljanju smo prišli do zaključka, da se moramo najprej odločiti za končna stanja izdelkov; to je postal naš prvi cilj.
Torej, kako lahko analizirate ducat izdelkov z dokaj velikimi ekipami od 10 do 200 ljudi in določite merljive meritve pri podvajanju rešitev?
1:0 v korist Chaosa, oziroma DevOps na rezilih
Začeli smo s poskusom uporabe diagramov IDEF0 in različnih diagramov poslovnih procesov iz serije BPwin. Zmeda se je začela po petem kvadratu naslednje stopnje naslednjega projekta in te kvadrate za vsak projekt je mogoče potegniti v rep dolgega pitona v 50+ korakih. Počutil sem se žalosten in hotel sem zajokati na luno - sploh se ni ujemalo.
Tipična proizvodna opravila
Modeliranje proizvodnih procesov je zelo zapleteno in mukotrpno delo: zbrati, obdelati in analizirati morate veliko podatkov iz različnih oddelkov in proizvodnih verig. Več o tem si lahko preberete v članku “".
Ko smo začeli z modeliranjem našega proizvodnega procesa, smo imeli točno določen cilj – vsem zaposlenim, ki sodelujejo pri razvoju izdelkov našega podjetja in vodjem projektov, sporočiti:
- kako izdelki in njihove komponente, začenši z izdajo vrstice kode, dosežejo stranko v obliki namestitvenih programov in posodobitev,
- kateri viri so zagotovljeni na vsaki stopnji proizvodnje izdelka,
- katere storitve so vključene v posamezni fazi,
- kako so področja odgovornosti razmejena za vsako stopnjo,
- kakšne pogodbe obstajajo na vhodu in izhodu vsake stopnje.
Kliknite na sliko, da se odpre v polni velikosti
Naše delo v podjetju je razdeljeno na več funkcionalnih področij. Infrastrukturni oddelek se ukvarja z optimizacijo delovanja vseh strojnih virov oddelka ter avtomatizacijo postavitve virtualnih strojev in okolja na njih. Monitoring direkcija zagotavlja nadzor nad izvajanjem storitev 24/7; Ponujamo tudi spremljanje kot storitev za razvijalce. Smer delovnega toka zagotavlja ekipam orodja za upravljanje procesov razvoja in testiranja, analiziranje stanja kode in pridobivanje analitike projektov. In končno, smer webdev zagotavlja objavo izdaj na strežnikih za posodobitev GUS in FLUS ter licenciranje izdelkov z uporabo storitve LicenseLab. Za podporo produkcijskemu cevovodu vzpostavimo in vzdržujemo veliko različnih podpornih storitev za razvijalce (zgodbe o nekaterih od njih lahko poslušate na starih srečanjih: и). Razvijamo tudi interna orodja za avtomatizacijo, vključno z .
V preteklih petih letih se je pri našem delu nabralo veliko podobnih in rutinskih operacij ter t.i tipične naloge, katerega rešitev je v celoti ali delno avtomatizirana, izvajalcem ne povzroča težav in ne zahteva večjih količin dela. Skupaj z vodilnimi področji smo tovrstne naloge analizirali in lahko identificirali posamezne kategorije dela, oz proizvodne faze, stopnje so razdeljene na nedeljive korake, več stopenj pa se sešteva veriga proizvodnega procesa.
Najenostavnejši primer tehnološke verige so faze montaže, uvajanja in testiranja vsakega od naših izdelkov znotraj podjetja. Po drugi strani je na primer stopnja gradnje sestavljena iz številnih ločenih standardnih korakov: prenos virov iz GitLaba, priprava odvisnosti in knjižnic tretjih oseb, testiranje enot in analiza statične kode, izvajanje gradbenega skripta na GitLab CI, objavljanje artefaktov v repozitorij na Artifactory in ustvarjanje opomb ob izdaji prek našega internega orodja ChangelogBuilder.
O tipičnih nalogah DevOps lahko preberete v naših drugih člankih na Habréju: “"In"".
Oblikuje se veliko tipičnih proizvodnih verig proizvodni proces. Standardni pristop k opisovanju procesov je uporaba funkcionalnih modelov IDEF0.
Primer modeliranja proizvodnega CI procesa
Posebno pozornost smo namenili razvoju tipskih projektov za sistem kontinuirane integracije. S tem je bilo mogoče doseči poenotenje projektov, s poudarkom na t.i diagram izdaje gradenj s promocijami.
Evo, kako to deluje. Vsi projekti so videti tipični: vključujejo konfiguracijo sklopov, ki gredo v repozitorij posnetkov v Artifactory, nato pa so uvedeni in preizkušeni na preskusnih mizah, nato pa napredovani v repozitorij za izdajo. Storitev Artifactory je enotna točka za distribucijo vseh gradbenih artefaktov med ekipami in drugimi storitvami.
Če močno poenostavimo in posplošimo našo shemo izdaje, vključuje naslednje stopnje:
- izdelava izdelkov na več platformah,
- namestitev na preskusne mize,
- zagon funkcionalnih in drugih testov,
- promocija preizkušenih sestavov za sprostitev repozitorijev na Artifactory,
- objavljanje gradenj izdaje za posodobitev strežnikov,
- dostava gradenj in posodobitev v produkcijo,
- zagon namestitve in posodobitev izdelka.
Kot primer si oglejmo tehnološki model te tipične sheme izdaje (v nadaljevanju preprosto model) v obliki funkcionalnega modela IDEF0. Odraža glavne faze našega procesa KI. Modeli IDEF0 uporabljajo t.i ICOM zapis (Input-Control-Output-Mechanism), da opišete, kateri viri se uporabljajo na vsaki stopnji, na podlagi katerih pravil in zahtev se delo izvaja, kakšen je rezultat in kateri mehanizmi, storitve ali ljudje izvajajo določeno stopnjo.
Kliknite na sliko, da se odpre v polni velikosti
V funkcionalnih modelih je praviloma lažje razstaviti in podrobno opisati procese. Ko pa število elementov raste, postaja vse težje razumeti nekaj o njih. Toda v realnem razvoju obstajajo tudi pomožne faze: spremljanje, certificiranje izdelkov, avtomatizacija delovnih procesov in druge. Ravno zaradi problema s skaliranjem smo ta opis opustili.
Rojstvo upanja
V neki knjigi smo naleteli na stare sovjetske zemljevide, ki opisujejo tehnološke procese (ki se, mimogrede, še danes uporabljajo v številnih državnih podjetjih in na univerzah). Čakaj, čakaj, imamo tudi tehnološki proces!.. Obstajajo stopnje, rezultati, metrike, zahteve, indikatorji itd., itd... Zakaj ne bi poskusili uporabiti tehnološke karte na naših proizvodnih tekočih trakovih? Bil je občutek: "To je to! Našli smo pravo nit, čas je, da jo dobro potegnemo!«
V preprosto tabelo smo se odločili, da izdelke evidentiramo po stolpcih, tehnološke faze in korake proizvodnega transporterja pa po vrsticah. Faze so nekaj velikega, na primer faza sestavljanja izdelka. In koraki so nekaj manjšega in bolj podrobnega, na primer korak prenosa izvorne kode na gradbeni strežnik ali korak prevajanja kode.
Na presečiščih vrstic in stolpcev zemljevida postavimo statuse za določeno stopnjo in izdelek. Za statuse je bilo definiranih veliko stanj:
- Ni informacij - ali nepraktično. Treba je analizirati povpraševanje po stopnji v izdelku. Ali je bila analiza že opravljena, vendar faza trenutno ni potrebna ali pa ni ekonomsko upravičena.
- Odloženo - ali trenutno ni relevantno. Ta faza v načrtu je potrebna, vendar ni energije za izvedbo letos.
- Načrtovano. Etapa je predvidena za izvedbo v letošnjem letu.
- Izvedeno. Faza v cevovodu je izvedena v zahtevanem obsegu.
Izpolnjevanje tabele se je začelo projekt za projektom. Najprej smo razvrstili faze in korake enega projekta in zabeležili njihove statuse. Nato so vzeli naslednji projekt, zabeležili statuse v njem in dodali faze in korake, ki so manjkali v prejšnjih projektih. Tako smo prejeli faze in korake našega celotnega proizvodnega toka in njihove statuse v konkretnem projektu. Rezultat je nekaj podobnega matriki kompetenc za tekoči trak hrane. Takšno matriko smo poimenovali tehnološka karta.
S pomočjo tehnološke karte se z ekipami meroslovno vsebinsko dogovorimo o planih dela za leto in ciljih, ki jih želimo skupaj doseči: katere faze projektu dodajamo letos in katere pustimo za kasneje. Poleg tega bomo med delom morda opazili izboljšave korakov, ki smo jih izvedli samo za en izdelek. Nato razširimo naš zemljevid in uvedemo to izboljšavo kot stopnjo ali nov korak, nato izvedemo analizo za vsak izdelek in ugotovimo izvedljivost ponovitve izboljšave.
Morda nam bodo ugovarjali: »To je seveda vse dobro, a sčasoma bo število korakov in stopenj postalo pregrešno veliko. Kaj naj naredim?
Uvedli smo standardne in dokaj popolne opise zahtev za posamezno fazo in korak, tako da so jih v podjetju razumeli vsi enako. Sčasoma, ko se izvajajo izboljšave, se lahko korak absorbira v drugo stopnjo ali korak - potem se bodo zrušili. Hkrati se vse zahteve in tehnološke nianse ujemajo z zahtevami generalizacijske stopnje ali koraka.
Kako ovrednotiti učinek repliciranja rešitev? Uporabljamo izjemno preprost pristop: začetne kapitalske stroške za izvedbo nove etape pripišemo letnim splošnim stroškom produkta, nato pa jih pri repliciranju razdelimo med vse.
Deli razvoja se že odražajo kot stopnje in koraki na zemljevidu. Na znižanje stroškov izdelkov lahko vplivamo z uvedbo avtomatizacije tipskih faz. Po tem izračunamo spremembe kvalitativnih značilnosti, kvantitativnih metrik in dobička, ki ga prejmejo ekipe (v prihranjenih delovnih ali strojnih urah).
Tehnološki zemljevid proizvodnega procesa
Če vzamemo vse svoje stopnje in korake, jih kodiramo z oznakami in razširimo v eno verigo, potem se bo izkazalo, da je zelo dolgo in nerazumljivo (točno isti "pitonov rep", o katerem smo govorili na začetku članka) :
[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]To so faze sestavljanja izdelkov [Build], njihove umestitve na testne strežnike [Deploy], testiranja [Test], spodbujanja sklopov za sprostitev repozitorijev na podlagi rezultatov testiranja [Promote], generiranja in objave licenc [License], objave [Publish] na strežniku za posodabljanje GUS in dostava posodobitev FLUS na strežnike, namestitev in posodabljanje komponent izdelka na strankini infrastrukturi z uporabo upravljanja konfiguracije izdelka [Namestitev], kot tudi zbiranje telemetrije [Telemetrija] iz nameščenih izdelkov.
Poleg njih ločimo še ločene stopnje: spremljanje stanja infrastrukture [InfMonitoring], upravljanje različic izvorne kode [SourceCodeControl], priprava okolja za montažo [Prepare], vodenje projekta [Workflow], zagotavljanje komunikacijskih orodij ekipam [ Komunikacija], certificiranje izdelkov [Certification] in zagotavljanje samozadostnosti CI procesov [CISelfSufficiency] (na primer neodvisnost sklopov od interneta). V naših procesih ne bomo niti upoštevali več deset korakov, ker so zelo specifični.
Celoten proizvodni proces si boste veliko lažje razumeli in si ogledali, če si ga boste predstavljali v obliki tehnološki zemljevid; To je tabela, v kateri so v vrsticah zapisane posamezne proizvodne faze in razčlenjeni koraki Modela, v stolpcih pa opis opravljenega na posamezni stopnji oz. Glavni poudarek je na virih, ki zagotavljajo posamezno stopnjo in razmejitvi področij odgovornosti.
Za nas je zemljevid nekakšen klasifikator. Odraža velike tehnološke dele proizvodnje izdelka. Zahvaljujoč temu je naši ekipi za avtomatizacijo postalo lažje komunicirati z razvijalci in skupaj načrtovati izvedbo stopenj avtomatizacije ter razumeti, kakšni stroški dela in viri (človeški in strojna oprema) bodo za to potrebni.
V našem podjetju je zemljevid samodejno ustvarjen iz predloge jinja kot običajna datoteka HTML in nato naložen na strežnik GitLab Pages. Ogledate si lahko posnetek zaslona s primerom popolnoma ustvarjenega zemljevida .
Kliknite na sliko, da se odpre v polni velikosti
Skratka, tehnološki zemljevid je posplošena slika proizvodnega procesa, ki odraža jasno razvrščene bloke s standardno funkcionalnostjo.
Struktura našega tehnološkega zemljevida
Zemljevid je sestavljen iz več delov:
- Območje naslova - tukaj je splošen opis zemljevida, predstavljeni so osnovni koncepti ter opredeljeni glavni viri in rezultati proizvodnega procesa.
- Informacijska plošča - tukaj lahko upravljate prikaz podatkov za posamezne izdelke, naveden je povzetek izvedenih faz in korakov na splošno za vse izdelke.
- Tehnološki zemljevid - tabelarični opis tehnološkega procesa. Na zemljevidu:
- podane so vse stopnje, koraki in njihove kode;
- podani so kratki in popolni opisi stopenj;
- navedeni so vhodni viri in storitve, ki se uporabljajo na vsaki stopnji;
- navedeni so rezultati vsake stopnje in posameznega koraka;
- navedeno je področje odgovornosti za vsako stopnjo in korak;
- določeni so tehnični viri, na primer HDD (SSD), RAM, vCPU in delovne ure, potrebne za podporo delu v tej fazi, tako trenutno – dejstvo, kot v prihodnosti – načrt;
- za vsak izdelek je navedeno, katere tehnološke faze oziroma koraki zanj so bili izvedeni, predvideni za izvedbo, nepomembni ali neizvedeni.
Odločanje na podlagi tehnološke karte
Ko preučite zemljevid, lahko izvedete nekaj dejanj, odvisno od vloge zaposlenega v podjetju (vodja razvoja, produktni vodja, razvijalec ali preizkuševalec):
- razumeti, katere faze manjkajo v realnem izdelku ali projektu in oceniti potrebo po njihovi izvedbi;
- razmejite področja odgovornosti med več oddelki, če delajo na različnih stopnjah;
- pogajanja o pogodbah za vložke in izhode stopenj;
- vključite svojo fazo dela v celoten razvojni proces;
- natančneje oceniti potrebo po virih za podporo posamezni stopnji.
Če povzamem vse zgoraj navedeno
Tehnološki zemljevid je vsestranski, razširljiv in enostaven za vzdrževanje. V tej obliki je veliko lažje razviti in vzdrževati opise procesov kot v strogem akademskem modelu IDEF0. Poleg tega je tabelarični opis preprostejši, bolj znan in bolje strukturiran kot funkcionalni model.
Za tehnično izvedbo korakov skrbi posebno interno orodje CrossBuilder - orodje za razslojevanje med CI sistemi, storitvami in infrastrukturo. Razvijalcu ni treba rezati: v našem sistemu CI je dovolj, da zaženete enega od skriptov (tako imenovano nalogo) orodja CrossBuilder, ki ga bo pravilno izvedel ob upoštevanju značilnosti naše infrastrukture.
Rezultati
Članek se je izkazal za precej dolgega, vendar je to neizogibno pri opisovanju modeliranja kompleksnih procesov. Na koncu bi rad na kratko predstavil naše glavne ideje:
- Cilj uvajanja DevOps idej v našem podjetju je dosledno zniževanje stroškov proizvodnje in vzdrževanja produktov podjetja v kvantitativnem smislu (človeške ure ali strojne ure, vCPU, RAM, Disk).
- Način za zmanjšanje skupnih stroškov razvoja je minimiziranje stroškov izvajanja standardnih serijskih nalog: stopenj in korakov tehnološkega procesa.
- Tipična naloga je naloga, katere rešitev je v celoti ali delno avtomatizirana, izvajalcem ne povzroča težav in ne zahteva večjih stroškov dela.
- Proizvodni proces je sestavljen iz stopenj, ki so razdeljene na nedeljive korake, ki predstavljajo tipična opravila različnih obsegov in obsegov.
- Od izoliranih standardnih nalog smo prišli do kompleksnih tehnoloških verig in večnivojskih modelov proizvodnega procesa, ki jih lahko opišemo s funkcionalnim IDEF0 modelom ali enostavnejšim tehnološkim zemljevidom.
- Diagram poteka je tabelarični prikaz stopenj in korakov proizvodnega procesa. Najpomembnejša stvar: zemljevid vam omogoča, da vidite celoten proces v celoti, v velikih delih z možnostjo detajliranja.
- Na podlagi tehnološke karte lahko ocenite potrebo po izvedbi faz v posameznem izdelku, razmejite področja odgovornosti, dogovorite pogodbe za vložke in izhode faz ter natančneje ocenite potrebe po virih.
V naslednjih člankih bomo podrobneje govorili o tem, katera tehnična orodja se uporabljajo za izvajanje določenih tehnoloških faz na našem zemljevidu.
Avtorji članka:
- — Vodja oddelka za avtomatizacijo (DevOps) pri Positive Technologies
- - namestnik Vodja oddelka za avtomatizacijo (DevOps) pri Positive Technologies
Vir: www.habr.com