Pirsa "çawa pêkanîna devops" bi salan e li dora xwe ye, lê gelek materyalên baş tune. Carinan hûn dibin qurbaniya reklamên şêwirmendên ne-aqilmend ên ku hewce ne ku wextê xwe bifroşin, çawa be jî. Carinan ev peyvên nezelal, zehf gelemperî ne ku ka keştiyên megakorporan çawa berbehiyên gerdûnê dişoxilînin. Pirs derdikeve holê: ev ji bo me çi girîng e? Nivîskarê hêja, tu dikarî ramanên xwe di lîsteyê de bi zelalî formule bikî?
Hemî ev ji vê yekê derdikeve ku pir pratîk û têgihîştina encamên veguherînên çanda pargîdanî berhev nebûye. Guhertinên di çandê de tiştên demdirêj in, ku encamên wan di hefteyek an mehekê de xuya nakin. Pêdiviya me bi kesek têra xwe heye ku bibîne ka bi salan pargîdanî çawa hatine avakirin û têkçûn.
John Willis - yek ji bavê DevOps. John xwedan ezmûnek dehsalan e ku bi hejmareke mezin a pargîdaniyan re dixebite. Di van demên dawî de, Yûhenna dest pê kir ku qalibên taybetî yên ku dema ku bi her yek ji wan re dixebitîn pêk tê. Bi karanîna van arketîpan, John pargîdaniyan li ser riya rastîn a veguherîna DevOps rêber dike. Di wergera rapora wî ya ji konferansa DevOops 2018 de li ser van archetypes bêtir bixwînin.
Li ser axaftvan:
Zêdetirî 35 sal di rêveberiya IT-ê de, beşdarî afirandina pêşekên OpenCloud li Canonical bû, beşdarî 10 destpêkan bû, du ji wan ji Dell û Docker re hatin firotin. Niha ew Cîgirê Serokê DevOps û Pratîkên Dîjîtal li SJ Technologies e.
Piştre çîrok ji nêrîna Yûhenna ye.
Navê min John Willis e û cîhê herî hêsan ku min bibîne li ser Twitter e, . Li ser Gmail û GitHub heman navên min hene. YEK hûn dikarin qeydên vîdyoyê yên rapor û pêşkêşiyên min ji wan re bibînin.
Gelek hevdîtinên min bi CIO yên gelek pargîdaniyên mezin re hene. Ew pir caran gilî dikin ku ew fêm nakin DevOps çi ye, û her kesê ku hewl dide ku wê ji wan re rave bike li ser tiştek cûda diaxive. Giliyek din a hevpar ev e ku DevOps nexebite, her çend wusa dixuye ku derhêner her tiştî wekî ku ji wan re hatî diyar kirin dikin. Em behsa şirketên mezin dikin ku ji sed salî zêdetir in. Piştî ku ez bi wan re axivîm, ez gihîştim wê encamê ku ji bo gelek pirsgirêkan, ne teknolojiya bilind e ku çêtirîn e, lê ji bilî çareseriyên kêm-teknolojî. Bi hefteyan ez tenê bi kesên ji beşên cuda re axivîm. Tiştê ku hûn di wêneya yekem a postê de dibînin projeya min a paşîn e, ev e ku jûr piştî sê rojên xebatê xuya bû.
DevOps çi ye?
Bi rastî, heke hûn ji 10 kesên cûda bipirsin, ew ê 10 bersivên cûda bidin. Lê tişta balkêş ev e: van her deh bersivan dê rast bin. Li vir bersivek xelet tune. Ez bi qasî 10 salan di nav DevOps de pir kûr bûm, û di yekem DevOpsDay de yekem Amerîkî bûm. Ez ê nebêjim ku ez ji her kesê ku di DevOps-ê de beşdar e jîrtir im, lê çu kes tune ku ewqas hewil li ser xerc kiriye. Ez bawer dikim ku DevOps dema ku sermayeya mirovî û teknolojiyê li hev dicivin pêk tê. Em gelek caran pîvana mirovî ji bîr dikin, her çend em pir li ser her cûre çandan diaxivin.
Naha gelek daneyên me hene, pênc sal lêkolînên akademîk, ceribandina teoriyan li ser pîvanek pîşesaziyê. Tiştê ku van lêkolînan ji me re vedibêjin ev e ku heke hûn di çandek rêxistinî de hin şêwazên behrê tevbigerin, hûn dikarin bilezek 2000x bi dest bixin. Ev lezbûn bi başbûnek wekhev a aramiyê re tê hev kirin. Ev pîvanek mîqdar a feydeya ku DevOps dikare ji her pargîdanî re bîne ye. Çend sal berê, min ji CEO ya pargîdaniyek Fortune 5000 re li ser DevOps diaxivî. Dema ku min ji bo pêşkêşiyê amade dikir, ez pir aciz bûm ji ber ku diviya bû ku ez ezmûna xwe ya salan di 5 hûrdeman de kurt bikim.
Di dawiyê de min evên jêrîn da Pênaseya DevOps: Komek ji kiryar û şêweyan e ku veguhertina sermaya mirovî bo sermayeya rêxistinî ya bi performansa bilind pêk tîne. Mînak awayê xebitandina Toyota ya 50 an 60 salên dawî ye.
(Ji vir şûnde, xêzên weha ne wekî materyalê referansê, lê wekî nîgar têne pêşkêş kirin. Naveroka wan dê ji bo her pargîdaniyek nû cûda bibe. Lêbelê, wêne dikare cûda were dîtin û mezin kirin.
Yek ji van pêkanînên herî serkeftî jî ev e nirxê valahiya mapping. Li ser vê yekê çend pirtûkên baş hatine nivîsandin, ya herî serkeftî ya Karen Martin e. Lê di sala borî de, ez gihîştim wê encamê ku ev nêzîkatî jî pir teknolojî ye. Bê guman gelek avantajên wê hene û min ew pir bikar aniye. Lê gava ku CEO ji we dipirse çima pargîdaniya wî nikare veguhezîne rêlên nû, pir zû ye ku meriv li ser nexşeya nirxê biaxive. Pir pirsên pir bingehîn hene ku divê pêşî werin bersivandin.
Ez difikirim ku xeletiya ku gelek hevkarên min dikin ev e ku ew tenê rêbernameyek pênc xalî didin pargîdaniyê û dûv re şeş meh şûnda vedigerin û dibînin ka çi bûye. Tewra nexşeyek baş a mîna nexşeya çemê nirxê jî, em bibêjin, xalên kor hene. Piştî bi sedan hevpeyivînên bi rêvebirên pargîdaniyên cihêreng re, min şêwazek diyar kir ku rê dide me ku em pirsgirêkê li pêkhateyên wê veqetînin, û naha em ê her yek ji van pêkhateyan bi rêz nîqaş bikin. Berî ku ez çareseriyên teknolojîk bicîh bikim, ez vê nimûneyê bikar tînim, û di encamê de, hemî dîwarên min bi diagraman têne nixumandin. Di van demên dawî de ez bi foneke hevpar re dixebitim û min 100-150 planên wiha qedand.
Çanda xerab ji bo taştê nêzîkatiyên baş dixwe
Fikra sereke ev e: heke çanda rêxistinê bixwe xirab be, ti qas Lean, Agile, SAFE û DevOps dê alîkariyê neke. Ew mîna ku di kûrahiyê de bêyî alavên scuba an xebitandina bêyî rontgenê ye. Bi gotineke din, ji bo Drucker û Deming paraphrase: çandek rêxistinî ya xirab dê her pergalê baş daqurtîne bêyî ku li ser wê bixeniqîne.
Ji bo çareserkirina vê pirsgirêka sereke, hûn hewce ne ku gavên jêrîn bavêjin:
- Hemî Karê Xuya Bikin: hûn hewce ne ku hemî karan diyar bikin. Ne bi wateya ku pêdivî ye ku ew li ser ekranek were xuyang kirin, lê di vê wateyê de ku divê were dîtin.
- Pergalên Rêvebiriya Karê Hevgirtî: pêdivî ye ku pergalên rêveberiyê bêne yek kirin. Di pirsgirêka zanîna “eşîrî” û zanîna sazûmanî de, di 9 bûyeran de ji 10 bûyeran de astengî li ser gel e. Di pirtûkê de Pirsgirêk bi yek kesî re bû, Brent, ku bû sedem ku proje sê sal paşde bimîne. Û ez li her derê van "Brents" diçim. Ji bo çareserkirina van tengasiyan, ez du tiştên din ên di navnîşa me de bikar tînim.
- Methodolojiya Teoriya Destûran: teoriya astengiyan.
- Hestên hevkariyê: hacks hevkariyê.
- Toyota Kata (): Ez ê zêde qala Toyota Kata nekim. Ger eleqedar be, li ser github min hema hema li ser her yek ji van mijaran.
- Rêxistina Bazar Oriented: rêxistina bazargeh.
- Çavdêrên Shift-çep: kontrolkirina di qonaxên destpêkê yên çerxê de.
Ez bi rêxistinek re pir hêsan dest bi xebatê dikim: Ez diçim pargîdaniyê û bi karmendan re diaxivim. Wekî ku hûn dikarin bibînin, teknolojiya bilind tune. Tiştê ku hûn hewce ne tiştek e ku hûn li ser binivîsin. Ez çend tîm li yek jûreyek kom dikim û tiştên ku ew ji min re ji perspektîfa 7 arketîpên min vedibêjin analîz dikim. Û paşê ez bi xwe nîşangirekê didim wan û ji wan dipirsim ku her tiştê ku heta nuha bi dengekî bilind gotine li ser tabloyê binivîsin. Bi gelemperî di van celeb civînan de kesek heye ku her tiştî dinivîse, û herî baş ew dikare %10 nîqaşan binivîse. Bi rêbaza min, ev hejmar dikare bi qasî 40% zêde bibe.
(Ev nîgar dikare cuda were dîtin )
Nêzîkatiya min li ser bingeha xebata William Schneider e. ). Nêzîkatî li ser vê fikrê ye ku her rêxistin dikare li çar çargoşan were dabeş kirin. Ev pîlan ji bo min bi gelemperî encama xebata bi wan bi sedan pîlanên din ên ku dema analîzkirina rêxistinek derdikevin holê ye. Bifikirin ku me rêxistinek xwedî asteke bilind a kontrolê ye, lê bi jêhatîbûna kêm. Ev vebijarkek pir nexwestî ye: dema ku her kes li ser rêzê ye, lê kes nizane çi bike.
Vebijarkek hinekî çêtir yek e ku hem kontrol û hem jî jêhatîbûnek bilind e. Ger pargîdaniyek wusa sûdmend be, wê hingê dibe ku ew ne hewceyî DevOps be. Pir balkêş e ku meriv bi pargîdaniyek re bixebite ku xwedan astek bilind a kontrolê, jêhatîbûn û hevkariyê kêm e, lê di heman demê de kulturek (çandî) bilind e. Ev tê vê wateyê ku pargîdanî gelek kesên ku hez dikin li wir bixebitin hene û gera kedê kêm e.
(Ev nîgar dikare cuda were dîtin )
Ji min re dixuye ku rêbazên bi rêwerzên hişk dikevin rê li ber gihandina rastiyê. Bi taybetî di nexşeya nirxê nirxê de, di derbarê ka agahdarî çawa were avakirin de gelek rêgez hene. Di qonaxên destpêkê yên xebatê de, ku ez niha behs dikim, hewcedariya tu kesî bi van rêbazan tune. Ger kesek bi nîşankerek di destên xwe de rewşa rastîn a pargîdaniyê li ser panelê vedibêje, ev awayê çêtirîn e ku meriv rewşa karûbar fam bike. Agahiyên wiha nagihîjin derhêneran. Di vê gavê de, bêaqilî ye ku meriv dev jê berde û bibêje ku wî cûreyek tîr bi xeletî kişandiye. Di vê qonaxê de, çêtir e ku meriv qaîdeyên hêsan bikar bîne, mînakî: abstrakasyona pir-ast dikare bi tenê bi karanîna nîşankerên pir-reng were afirandin.
Ez dubare dikim, teknolojiya bilind tune. Nîşana reş rastiya objektîf ya ku her tişt çawa dixebite destnîşan dike. Bi nîşankerek sor, mirov tiştê ku ew ji rewşa heyî hez nakin nîşan didin. Girîng e ku ew vê binivîsin, ne ez. Dema ku ez piştî civînekê diçim CIO, ez navnîşek 10 tiştên ku divê bêne sererast kirin pêşkêşî nakim. Ez hewl didim ku têkiliya di navbera tiştên ku di pargîdaniyê de dibêjin û qalibên pejirandî yên heyî de bibînim. Di dawiyê de, nîşankerek şîn çareseriyên mimkun ên pirsgirêkê pêşniyar dike.
(Ev nîgar dikare cuda were dîtin )
Nimûneyek ji vê nêzîkbûnê niha li jor xuya dike. Di destpêka vê salê de ez bi bankek re xebitîm. Kesên ewlehiyê yên li wir piştrast bûn ku divê ew neyên lêkolînên sêwiran û hewcedariyê.
(Ev nîgar dikare cuda were dîtin )
Û paşê em bi kesên ji beşên din re axivîn û derket holê ku nêzî 8 sal berê, pêşdebirên nermalavê xebatkarên ewlehiyê ji kar derxistin ji ber ku wan kar hêdî dikirin. Û paşê ew veguherî qedexeyek, ku ji bo xwerû hate girtin. Tevî ku di rastiyê de qedexe nebû.
Civîna me bi rengekî pir tevlihev derbas bû: bi qasî sê saetan, pênc tîmên cihê nikarîbûn ji min re rave bikin ka di navbera kod û meclîsê de çi diqewime. Û ev xuya dike ku tiştek herî hêsan e. Piraniya şêwirmendên DevOps di pêş de texmîn dikin ku her kes jixwe vê yekê dizane.
Dûre berpirsê rêveberiya IT’ê ku çar saetan bêdeng mabû, dema ku em gihîştin ser mijara wî, ji nişka ve jiyana xwe ji dest da û demek dirêj em mijûl kirin. Di dawiyê de min jê pirsî ka ew li ser hevdîtinê çi difikire, û ez tu carî bersiva wî ji bîr nakim. Wî got: "Berê min difikirî ku banka me tenê du awayên radestkirina nermalavê hene, lê naha ez dizanim ku pênc ji wan hene, û min bi sêyan jî nizanibû."
(Ev nîgar dikare cuda were dîtin )
Civîna paşîn li vê bankê bi tîmê nermalava veberhênanê re bû. Bi wê re derket holê ku nivîsandina diagraman bi nîşankerek li ser kaxezek ji li ser tabloyê çêtir e, û hêj ji ya jîrtir çêtir e.
Wêneyên ku hûn dibînin di roja çaremîn a civîna me de jûreya konferansê ya otêlê çawa xuya dike. Û me van nexşeyan bikar anî ji bo lêgerîna nimûneyan, ango arketîp.
Ji ber vê yekê, ez pirsan ji karkeran dikim, ew bersivan bi nîşankerên sê rengan (reş, sor û şîn) dinivîsin. Ez bersivên wan ji bo arketîp analîz dikim. Naha werin em bi rêz li ser hemî archetîp nîqaş bikin.
1. Hemî Xebatê Bikin: Karê xuya bikin
Piraniya pargîdaniyên ku ez pê re dixebitim rêjeyek pir zêde ya xebata nenas heye. Mînakî, ev gava ku karmendek tê cem yekî din û bi tenê daxwaz dike ku tiştek bike. Di rêxistinên mezin de, dibe ku ji% 60 karek bêplan hebe. Û heta %40ê xebatê bi tu awayî nayê belgekirin. Ger Boeing bûya, ez ê di jiyana xwe de careke din li balafira wan siwar nebim. Heger tenê nîvê xebatê bi belge be, wê demê nayê zanîn ku ev kar rast tê kirin yan na. Hemî rêbazên din bêkêr derdikevin - çu xalek tune ku hewl bidin ku tiştek otomatîk bikin, ji ber ku% 50-ê tê zanîn dibe ku beşa herî hevgirtî û zelal a xebatê be, ku otomatîkkirina wê dê encamên mezin nede, û ya herî xirab. tişt di nîvê nedîtbar de ne. Di nebûna belgeyan de, ne mimkûn e ku meriv her cûre hack û karên veşartî bibîne, neyên dîtina kelûpelan, ew pir "Brents" ku min berê qala wan kir. Pirtûkek hêja ya Dominica DeGrandis heye . Ew eşkere dike pênc cuda "leaks dem" (dizên demê):
- Xebata Zêde Di Pêvajoyê de (WIP)
- Girêdanên Nenas
- Karê neplankirî
- Pêşîniyên nakok
- Karê paşguh kirin
Ev analîzek pir hêja ye û pirtûk pir xweş e, lê hemî ev şîret bêkêr in heke tenê 50% ji daneyan xuya bibin. Rêbazên ku ji hêla Dominica ve têne pêşniyar kirin heke rastiyek ji jor 90% were bidestxistin dikare were bikar anîn. Ez behsa wan rewşan dikim ku serek 15 deqe peywirek dide bindest, lê sê rojan jê re lazim e; lê patron bi rastî nizane ku ev bindest bi çar-pênc kesên din ve girêdayî ye.
Projeya Phoenix çîrokek ecêb e li ser projeyek ku sê sal pir dereng mabû. Yek ji karakteran ji ber vê yekê bi karekterek din re rû bi rû dimîne ku wekî celebek Sokrates tê pêşandan. Ew alîkarî dike ku fêm bike ka çi bi rastî xelet çû. Derket holê ku pargîdanî yek rêveberê pergalê heye, navê wî Brent e, û hemî kar bi rengekî wî derbas dibe. Di yek ji civînan de, ji yek ji bindestan tê pirsîn: çima her karê nîv saetê hefteyekê digire? Bersiv pêşandanek pir hêsan a teoriya rêzê û qanûna Little ye, û di vê pêşkêşiyê de derdikeve ku di 90% dagîrbûnê de, her demjimêrek kar 9 demjimêran digire. Pêdivî ye ku her karek ji heft kesên din re were şandin, da ku ew demjimêr bibe 63 demjimêr, 7 carî 9. Xala ku ez destnîşan dikim ev e ku ji bo ku hûn Qanûna Little's an teoriyek tevlihev a rêzê bikar bînin, bi kêmanî hûn hewce ne ku daneyan hebin.
Ji ber vê yekê gava ku ez qala xuyabûnê dikim, mebesta min ne ew e ku her tişt li ser ekranê ye, lê bi kêmî ve daneyên we hene. Dema ku ew dikin, pir caran derdikeve holê ku hejmareke pir mezin a xebata bêplan heye ku bi rengekî ji Brent re tê şandin dema ku hewcedariya wê tune be. Û Brent xortekî hêja ye, ew ê tu carî nebêje na, lê ew ji kesî re nabêje ka ew çawa karê xwe dike.
Gava ku kar xuya dibe, dane dikarin bi rengek xweş werin dabeş kirin (ya ku Dominika di wêneyê de dike ev e), abstrakasyona pênc deqên demê dikare were sepandin, û otomasyon dikare were sepandin.
2. Pergalên Rêvebiriya Karê yekgirtî: Rêvebiriya Peywiran
Arketîpên ku ez behsa wan dikim celebek pîramîd in. Ger ya yekem rast were çêkirin, wê hingê ya duyemîn jixwe celebek pêvekek e. Gelek ji van ji bo destpêkan kar nakin, pêdivî ye ku ew ji bo pargîdaniyên mezin ên mîna Fortune 5000 li ber çavan werin girtin. Pargîdaniya paşîn a ku ez lê dixebitim 10 pergalên bilêtê hebûn. Tîmek Remedy hebû, yekî din cûreyek pergala xwe nivîsand, yekî sêyemîn Jira bikar anî, û hinan jî bi e-nameyê ve mijûl kirin. Heman pirsgirêk derdikeve heke pargîdanî 30 boriyên cûda hebin, lê wextê min tune ku ez hemî dozên weha nîqaş bikim.
Ez bi mirovan re tam nîqaş dikim ka bilêt çawa têne çêkirin, paşê çi tê serê wan, û ew çawa têne dorpêç kirin. Tişta herî balkêş jî ew e ku kesên di civînên me de ji dil û can diaxivin. Min pirsî ka çend kes "bandorek piçûk / bêbandor" li bilêtên ku divê bi rastî "bandorek mezin" were dayîn danîn. Derket holê ku hema hema her kes vê yekê dike. Ez xwe naxebitim û bi her awayî hewl didim ku mirovan nas nekim. Dema ku ew ji dil tiştekî ji min re îtîraf dikin, ez wî kesî nadim. Lê gava ku hema her kes pergalê derbas dike, ev tê vê wateyê ku hemî ewlehî bi bingehîn cilê pencereyê ye. Ji ber vê yekê, ji daneyên vê pergalê tu encam nayên derxistin.
Ji bo çareserkirina pirsgirêka bilêtê, hûn hewce ne ku yek pergala sereke hilbijêrin. Heke hûn Jira bikar tînin, wê Jira biparêzin. Ger alternatîfek hebe, bila yekane be. Xeta jêrîn ev e ku divê bilêtan di pêvajoya pêşkeftinê de wekî gavek din were dîtin. Pêdivî ye ku her kiryar bilêtek hebe, ku divê di nav xebata pêşkeftinê de derbas bibe. Bilêt ji tîmê re têne şandin, ku wan li ser çîrokan diweşîne û dûv re berpirsiyariya wan digire.
Ev ji bo hemî beşan, tevî binesaziyê û operasyonan, derbas dibe. Di vê rewşê de, mimkun e ku bi kêmanî ramanek maqûl a rewşa karan çêbibe. Dema ku ev pêvajo hate damezrandin, ji nişkê ve hêsan dibe ku meriv nas bike ka kî berpirsiyarê her serîlêdanê ye. Ji ber ku niha em ne %50, lê %98 xizmetên nû distînin. Ger ev pêvajoya bingehîn bixebite, wê hingê rastbûn li seranserê pergalê baştir dibe.
Xizmetên boriyê
Ev dîsa tenê ji bo pargîdaniyên mezin derbas dibe. Ger hûn di qadek nû de pargîdaniyek nû ne, lingên xwe hildin û bi Travis CI an CircleCI-ya xwe re bixebitin. Dema ku dor tê ser pargîdaniyên Fortune 5000, bûyerek ku li banka ku ez lê dixebitim qewimî. Google ji wan re hat û wan diagramên pergalên kevn ên IBM-ê nîşan dan. Zarokên ji Google-ê bi tevlihevî pirsîn - koda çavkaniyê ji bo vê li ku ye? Lê koda çavkaniyê tune, ne jî GUI. Ev rastiya ku rêxistinên mezin neçar in ku pê re mijûl bibin ev e: tomarên bankê yên 40-salî li ser bingehek kevnar. Yek ji xerîdarên min konteynerên Kubernetes bi qalibên Circuit Breaker, plus Chaos Monkey, hemî ji bo serîlêdana KeyBank bikar tîne. Lê van konteyneran di dawiyê de bi serîlêdanek COBOL ve girêdidin.
Xortên Google bi tevahî pê bawer bûn ku ew ê hemî pirsgirêkên muwekîlê min çareser bikin, û dûv re dest bi pirsan kirin: IBM datapipe çi ye? Ji wan re tê gotin: ev girêdanek e. Ew bi çi ve girêdayî ye? Ji bo pergala Sperry. Û ew çi ye? Wate ya vê çîye. Di nihêrîna pêşîn de wusa dixuye: çi celeb DevOps dikare hebe? Lê di rastiyê de, ew gengaz e. Pergalên radestkirinê hene ku destûrê didin we ku hûn xebata xebatê radestî tîmên radestkirinê bikin.
3. Teoriya Destûran: Teoriya Destûra
Em herin ser arketîpa sêyem: zanîna sazî/eşîrtî. Wekî qaîdeyek, di her rêxistinekê de çend kes hene ku her tiştî dizanin û her tiştî birêve dibin. Yên ku herî dirêj di nav rêxistinê de ne û hemî rêgezan dizanin ev in.
Dema ku ev li ser diagramê derdikeve, ez bi taybetî bi nîşankerek wusa mirovên weha radigihînim: Mînakî, derdikeve holê ku hin Lou di hemî civînan de amade ye. Û ji min re zelal e: ev Brent herêmî ye. Gava ku CIO di navbera min bi t-shirt û sneakers û zilamê ji IBM-ê bi kincek hildibijêre, ez tê hilbijartin ji ber ku ez dikarim ji derhêner re tiştên ku zilamê din nabêje û ku derhêner hez nake bibihîze ji derhêner re bibêjim. . Ez ji wan re vedibêjim ku di pargîdaniya wan de kelekek bi navê Fred û kesek bi navê Lou ye. Pêwîste ev kelem ji holê bê rakirin, bi vî awayî zanîna wan ji wan bê girtin.
Ji bo çareserkirina vî rengî pirsgirêkê, ez dikarim, mînakî, pêşniyar bikim ku Slack bikar bînin. Derhênerek jîr dê bipirse - çima? Bi gelemperî, di rewşên weha de, şêwirmendên DevOps bersiv didin: ji ber ku her kes wiya dike. Ger derhêner bi rastî jîr be, dê bibêje: îcar çi. Û li vir diyalog bi dawî dibe. Û bersiva min ji vê yekê re ev e: ji ber ku di pargîdaniyê de çar tengahî hene, Fred, Lou, Susie û Jane. Ji bo sazûmankirina zanîna wan, divê mirov pêşî Slack bide nasîn. Hemî wîkiyên we bêwate ne ji ber ku kes bi hebûna wan nizane. Ger tîmê endezyariyê di pêşkeftina pêş-end û paşîn de têkildar be û pêdivî ye ku her kes zanibe ku ew dikarin bi pirsan bi tîmê pêşkeftina pêşîn an tîmê binesaziyê re têkilî daynin. Wê demê Lou an Fred belkî wext hebe ku beşdarî wiki bibin. Û paşê di Slack de kesek dikare bipirse ka çima, bêje, gava 5 nexebite. Û paşê Lou an Fred dê rêwerzên li ser wiki rast bikin. Ger hûn vê pêvajoyê saz bikin, wê hingê dê gelek tişt bi serê xwe biqewimin.
Ev xala min a sereke ye: ji bo ku hûn teknolojiyên bilind pêşniyar bikin, divê hûn pêşî bingehê wan bi rêkûpêk bikin, û ev dikare bi çareseriyên kêm-teknolojiya ku tenê hatine destnîşan kirin were kirin. Ger hûn bi teknolojiyên bilind dest pê bikin û rave nekin ka çima ew hewce ne, wê hingê, wekî qaîdeyek, ev baş bi dawî nabe. Yek ji xerîdarên me Azure ML, çareseriyek pir erzan û hêsan bikar tîne. Nêzîkî 30% ji pirsên wan ji hêla makîneya xwe-fêrbûnê bixwe ve hatin bersivandin. Û ev tişt ji hêla operatorên ku ne di zanistiya daneyê, statîstîk an matematîkê de ne hatine nivîsandin. Ev girîng e. Mesrefa çareseriyek weha hindik e.
4. Hevkarî hak: Hevkarî
Arketîpa çaremîn hewcedariya têkoşîna li dijî tecrîdê ye. Pir kes jixwe vê yekê dizanin: îzolasyon dijminatiyê çêdike. Ger her dezgehek li qata xwe be, û mirov bi ti awayî bi hev re nekevin hev, ji bilî di asansorê de, wê hingê dijminatî di navbera wan de pir bi hêsanî çêdibe. Lê heke, berevajî, mirov bi hev re di heman odeyê de bin, ew tavilê derdikeve. Gava ku kesek hin sûcdarkirina gelemperî derdixe, mînakî, têkiliyek wusa û wusa qet naxebite, tiştek hêsan tune ku meriv sûcdariyek wusa hilweşîne. Bernamesazên ku navbeynkar nivîsandine tenê hewce ne ku dest bi pirsên taybetî bikin, û di demek nêzîk de dê diyar bibe ku, mînakî, bikarhêner bi tenê amûrê bi xeletî bikar aniye.
Ji bo derbaskirina tecrîdê gelek rê hene. Carekê ji min hat xwestin ku ez ji bo bankek li Avusturalya şêwir bikim, lê min ev yek red kir ji ber ku du zarokên min û jinek min hene. Tiştê ku min dikaribû alîkariya wan bikim ev bû ku çîrokbêjiya grafîkî pêşniyar bikim. Ev tiştek e ku îsbat dike ku kar dike. Rêyek din a balkêş civînên qehweya bêhêz e. Di rêxistinek mezin de, ev ji bo belavkirina zanînê vebijarkek hêja ye. Wekî din, hûn dikarin devopsdayên navxweyî, hackathon, û hwd.
5. Coaching Kata
Wekî ku min di destpêkê de hişyar kir, ez ê îro li ser vê neaxivim. Heke hûn eleqedar in, hûn dikarin lê binêrin .
Li ser vê mijarê ji Mike Rother jî axaftinek baş heye:
6. Bazar Oriented: Rêxistinbûna bazarê
Li vir pirsgirêkên cuda hene. Mînak, mirovên "ez", mirovên "T" û mirovên "E". Mirovên “ez” ew in ku tenê tiştekî dikin. Bi gelemperî ew di rêxistinên bi beşên veqetandî de hene. "T" ew e ku mirov di tiştekî de lê di hin tiştên din de jî baş be. "E" an jî "kom" ew e ku meriv gelek jêhatîbûnên xwe hebe.
Qanûna Conway li vir dixebite (), ku di forma herî hêsankirî de dikare wiha were gotin: heke sê tîm li ser berhevkerê bixebitin, wê hingê dê encam bibe berhevkarek ji sê beşan. Ji ber vê yekê, heke di hundurê rêxistinek de astek bilind a îzolasyonê hebe, wê hingê tewra Kubernetes, Circuit breaker, berfirehbûna API û tiştên din ên xweşik ên di vê rêxistinê de dê bi heman rengî wekî rêxistin bixwe bêne saz kirin. Bi tundî li gorî Conway û li hember hûn hemî geekên ciwan.
Çareseriya vê pirsgirêkê gelek caran hatiye vegotin. Mînakî, arketîpên rêxistinî yên ku ji hêla Fernando Fernandez ve hatine vegotin hene. Ew mîmariya pirsgirêkî ya ku min tenê behs kir, bi veqetandinê re, mîmariyek fonksiyon-oriented e. Cûreya duyemîn, mîmariya matrixê ya herî xirab e, tevliheviya her du yên din. Ya sêyem ya ku di pir destpêkek de tê dîtin e, û pargîdaniyên mezin jî hewl didin ku bi vî rengî li hev bikin. Ew rêxistinek bazarê ye. Li vir em xweşbîn dikin ku bigihîjin bersiva herî bilez a daxwazên xerîdar. Ji vê yekê re carinan rêxistinek daîre tê gotin.
Gelek kes vê avahiyê bi awayên cûda diyar dikin, ez ji peyvê hez dikim tîmên ava bike / bimeşîne, li Amazonê jê re dibêjin du tîmên pizza. Di vê avahîsaziyê de, hemû kesên tîpa “I” li dora yek servîsê têne kom kirin, û hêdî hêdî ew nêzikî tîpa “T” dibin, û ger rêvebirina rast hebe, ew dikarin bibin “E” jî. Di vir de dijberiya yekem ev e ku avahiyek weha hêmanên nepêwîst hene. Ma hûn çima di her beşê de ceribandinek hewce ne heke hûn dikarin dezgehek taybetî ya ceribandinan hebin? Ya ku ez bersivê didim: lêçûnên zêde di vê rewşê de ji bo tevahiya rêxistinê biha ye ku di pêşerojê de bibe tîpa "E". Di vê avahiyê de, ceribandin hêdî hêdî li ser toran, mîmarî, sêwiran, hwd fêr dibe. Di encamê de, her beşdarê rêxistinê bi tevahî ji her tiştê ku di rêxistinê de diqewime haydar e. Heke hûn dixwazin bizanin ka ev plan di pîşesaziyê de çawa dixebite, bixwînin .
7. Kontrolkerên guheztin-çep: di destpêka dewreyê de kontrol bikin. Lihevhatina bi qaîdeyên ewlehiyê yên li ser ekranê
Ev gava ku kiryarên we ceribandina bîhnê derbas nakin, da ku biaxivin. Kesên ku ji bo we dixebitin ne ehmeq in. Ger, wekî mînaka li jor, wan li her derê bandorek piçûk / bê bandor danîne, ev sê sal dom kir, û kesî tiştek ferq nekir, wê hingê her kes baş dizane ku pergal naxebite. An jî mînakek din - lijneyek şêwirdar a guheztinê, ku pêdivî ye ku rapor her, bêje, çarşem were şandin. Komek mirovên li wir dixebitin (bi awayê, ne pir baş têne dayîn) ku, di teoriyê de, divê zanibin ku pergal bi tevahî çawa dixebite. Û di van pênc salên borî de, we belkî dît ku pergalên me pir tevlihev in. Pênc-şeş kes jî divê li ser guhertineke ku wan nekiriye û li ser tiştek nizanin biryarek bidin.
Helbet ev nêzîkatî bi ser nakeve. Ji ber ku ev kes pergalê naparêzin divê ez ji tiştên wiha xilas bibim. Divê tîm bi xwe biryarê bide, ji ber ku divê tîm jê berpirsyar be. Wekî din, rewşek paradoksîk derdikeve holê dema ku rêveberek ku di jiyana xwe de qet kod nenivîsandiye ji bernameçêker re dibêje ka ji bo nivîsandina kodê çiqas dem divê. Pargîdanek ku ez pê re xebitîm 7 panelên cihêreng hebûn ku her guhertin dinirxînin, di nav de panelek mîmarî, panelek hilber û hwd. Tewra heyamek bendewariyê ya mecbûrî jî hebû, her çend karmendek ji min re got ku di deh salên xebatê de, tu carî guhertina vî kesî di vê heyama mecbûrî de red nekir.
Pêdivî ye ku çavdêr werin vexwendin ku beşdarî me bibin, û ji wan xilas nebin. Ji wan re bêjin ku hûn konteynerên binary ên neguhêrbar binivîsin ku, ger ew hemî ceribandinan derbas bikin, her û her neguhêrbar bimînin. Ji wan re bêjin ku we wekî kodek boriyek heye û rave bikin ka ev tê çi wateyê. Pîlana jêrîn nîşanî wan bide: binaryek tenê-xwendewar a neguhêrbar di konteynir de ku hemî ceribandinên lawazbûnê derbas dike; û wê demê ne tenê kes dest nade wê, ew jî dest nade pergala ku boriyê diafirîne, ji ber ku ew jî bi dînamîk tê afirandin. Xerîdarên min hene, Capital One, ku Vault bikar tînin da ku tiştek mîna blokek biafirînin. Ne hewce ye ku auditor "reçeteyên" ji Chef nîşan bide; bes e ku meriv zincîra blokê nîşan bide, ku jê diyar e ka di hilberînê de çi hatiye serê bilêta Jira û kî berpirsiyar e.
Li gorî , ku di sala 2018-an de ji hêla Sonatype ve hatî afirandin, di sala 2017-an de 87 mîlyar daxwazên dakêşana OSS hebûn.
Ziyanên ku ji ber bêhêziyan çêdibin qedexe ne. Wekî din, hejmarên ku hûn niha li jor dibînin lêçûnên derfetê nagirin. DevSecOps bi kurtî çi ye? Bihêle ez tavilê bibêjim ku ez ne eleqedar im ku biaxivim ka ev nav çiqasî serketî ye. Mesele ev e ku ji ber ku DevOps ew qas serfiraz bûye, divê em hewl bidin ku ewlehiyê li wê boriyê zêde bikin.
Mînakek ji vê rêzê:
Ev ne pêşniyarek ji bo hilberên taybetî ye, her çend ez ji wan hemî hez dikim. Min wan wekî mînakek destnîşan kir da ku destnîşan bikim ku DevOps, ku di destpêkê de li ser bingeha paradîgmaya rêxistinî ya di pîşesaziyê de bû, dihêle hûn her qonaxa xebatê li ser hilberek otomatîk bikin.
Û tu sedem tune ku em nikaribin heman nêzîkatiya ewlehiyê bigirin.
Encam
Wekî encamek, ez ê ji bo DevSecOps hin serişteyan bidim. Pêdivî ye ku hûn di pêvajoya afirandina pergalên xwe de auditoran tevbigerin û wextê xwe bi perwerdekirina wan derbas bikin. Pêdivî ye ku hûn bi çavdêran re hevkariyê bikin. Dûv re, hûn hewce ne ku li dijî erênîyên derewîn têkoşînek bêkêmasî ya bêrehm bidin meşandin. Tewra bi amûra şopandina qelsbûnê ya herî biha, hûn dikarin di nav pêşdebirên xwe de adetên pir xirab biafirînin heke hûn nizanin rêjeya weya sînyala-dengê çi ye. Pêşdebir dê bi bûyeran re serûbin bibin û dê bi tenê wan jêbirin. Ger we li ser çîroka Equifax bihîst, ew pir tişt li wir qewimî, ku asta hişyariya herî bilind hate paşguh kirin. Wekî din, pêdivî ye ku qelsî bi rengek ku eşkere bike ka ew çawa bandorê li karsaziyê dikin. Mînakî, hûn dikarin bibêjin ku ev heman qelsî ye ku di çîroka Equifax de ye. Pêdivî ye ku qelsiyên ewlehiyê wekî pirsgirêkên nermalava din bêne derman kirin, ango, divê ew di pêvajoya tevdeya DevOps de werin girtin. Pêdivî ye ku hûn bi wan re bi Jira, Kanban, hwd re bixebitin. Pêdivî ye ku pêşdebir nefikirin ku kesek din dê wiya bike - berevajî, divê her kes vê yekê bike. Di dawiyê de, hûn hewce ne ku enerjiyê li ser perwerdekirina mirovan xerc bikin.
Girêdanên bikarhêner
Li vir çend axaftinên ji konferansa DevOops hene ku hûn dikarin kêrhatî bibînin:
- Sergey Berdnikov, Artyom Kalichkin - Çîroka Serkeftinê, an "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps li ser pîvanê: trajediyek Yewnanî di sê çalakiyan de (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Berî xwe bidê DevOops 2020 Moskow — Li wir jî gelek tiştên balkêş hene.
Source: www.habr.com