La demando "kiel efektivigi devopojn" ekzistas de jaroj, sed ne ekzistas multaj bonaj materialoj. Kelkfoje vi viktimiĝas de reklamoj de ne tiom inteligentaj konsultistoj, kiuj bezonas vendi sian tempon, kiel ajn. Foje ĉi tiuj estas neklaraj, ekstreme ĝeneralaj vortoj pri kiel la ŝipoj de megakorporacioj plugas la vastaĵojn de la universo. Estiĝas la demando: kion tio gravas al ni? Kara aŭtoro, ĉu vi povas klare formuli viajn ideojn en listo?
Ĉio ĉi devenas de la fakto, ke ne amasiĝis multe da reala praktiko kaj kompreno de la rezulto de transformoj de la kulturo de la kompanio. Ŝanĝoj en kulturo estas longdaŭraj aferoj, kies rezultoj ne aperos post semajno aŭ monato. Ni bezonas iun sufiĉe maljunan por esti vidinta kiel kompanioj estis konstruitaj kaj fiaskis tra la jaroj.
John Willis - unu el la patroj de DevOps. John havas jardekojn da sperto laboranta kun grandega nombro da kompanioj. Lastatempe, Johano komencis rimarki specifajn ŝablonojn, kiuj okazas kiam oni laboras kun ĉiu el ili. Uzante ĉi tiujn arketipojn, Johano gvidas kompaniojn sur la vera vojo de DevOps-transformo. Legu pli pri ĉi tiuj arketipoj en la traduko de lia raporto de la DevOops 2018-konferenco.
Pri la parolanto:
Pli ol 35 jaroj en IT-administrado, partoprenis en la kreado de la antaŭulo de OpenCloud ĉe Canonical, partoprenis en 10 noventreprenoj, du el kiuj estis venditaj al Dell kaj Docker. Nuntempe li estas Vicprezidanto de DevOps kaj Ciferecaj Praktikoj ĉe SJ Technologies.
Sekva estas la rakonto el la vidpunkto de Johano.
Mia nomo estas John Willis kaj la plej facila loko por trovi min estas en Twitter, . Mi havas la saman kaŝnomon en Gmail kaj GitHub. A vi povas trovi videoregistraĵojn de miaj raportoj kaj prezentoj por ili.
Mi havas multajn renkontiĝojn kun CIO-oj de diversaj grandaj kompanioj. Ili tre ofte plendas, ke ili ne komprenas, kio estas DevOps, kaj ĉiuj, kiuj provas klarigi ĝin al ili, parolas pri io malsama. Alia ofta plendo estas, ke DevOps ne funkcias, kvankam ŝajnas, ke la direktoroj faras ĉion kiel klarigite al ili. Ni parolas pri grandaj kompanioj, kiuj aĝas pli ol cent jarojn. Parolinte kun ili, mi alvenis al la konkludo, ke por multaj problemoj, ne alta teknologio plej taŭgas, sed relative malaltteknikaj solvoj. Dum semajnoj mi nur parolis kun homoj el diversaj fakoj. Kion vi vidas en la unua bildo en la afiŝo estas mia lasta projekto, jen kiel aspektis la ĉambro post tri tagoj da laboro.
Kio estas DevOps?
Efektive, se vi demandas 10 malsamajn homojn, ili donos 10 malsamajn respondojn. Sed jen la interesa afero: ĉiuj dek ĉi tiuj respondoj estos ĝustaj. Ne estas malĝusta respondo ĉi tie. Mi estis sufiĉe profunde en DevOps, dum ĉirkaŭ 10 jaroj, kaj estis la unua usonano ĉe la unua DevOpsDay. Mi ne diros, ke mi estas pli inteligenta ol ĉiuj implikitaj en DevOps, sed apenaŭ estas iu, kiu elspezis tiom da penado por ĝi. Mi kredas, ke DevOps okazas kiam homa kapitalo kaj teknologio kuniĝas. Ni ofte forgesas pri la homa dimensio, kvankam ni multe parolas pri ĉiaj kulturoj.
Nun ni havas multajn datumojn, kvin jarojn da akademia esplorado, testadon de teorioj en industria skalo. Kion ĉi tiuj studoj diras al ni, estas, ke se vi kombinas iujn kondutajn ŝablonojn en organiza kulturo, vi povas atingi 2000x-rapidecon. Ĉi tiu akcelo estas egalita per egala plibonigo en stabileco. Ĉi tio estas kvanta mezurado de la avantaĝo, kiun DevOps povas alporti al iu ajn kompanio. Antaŭ kelkaj jaroj, mi parolis pri DevOps al la CEO de kompanio Fortune 5000. Kiam mi prepariĝis por la prezento, mi estis tre nervoza ĉar mi devis resumi miajn jarojn da sperto en 5 minutoj.
Fine mi donis la jenon Difino de DevOps: Ĝi estas aro de praktikoj kaj ŝablonoj kiuj ebligas la transformon de homa kapitalo en alt-efikecan organizan kapitalon. Ekzemplo estas la maniero kiel Toyota funkciis dum la lastaj 50 aŭ 60 jaroj.
(Ĉi-poste tiaj diagramoj estas provizitaj ne kiel referencmaterialo, sed kiel ilustraĵoj. Ilia enhavo malsamas por ĉiu nova firmao. Tamen, la bildo estas rigardebla aparte kaj pligrandigita.
Unu el la plej sukcesaj tiaj praktikoj estas valora rivereto. Pluraj bonaj libroj estis verkitaj pri tio, la plej sukcesaj el kiuj estas de Karen Martin. Sed dum la pasinta jaro, mi venis al la konkludo, ke eĉ ĉi tiu aliro estas tro altteknologia. Ĝi certe havas multajn avantaĝojn kaj mi multe uzis ĝin. Sed kiam la CEO demandas vin, kial lia kompanio ne povas ŝanĝi al novaj reloj, estas tro frue por paroli pri mapado de valorfluoj. Estas multaj pli fundamentaj demandoj, kiuj unue devas esti responditaj.
Mi pensas, ke la eraro multaj el miaj kolegoj faras estas, ke ili simple donas al la kompanio kvin-punktan gvidilon kaj poste revenas ses monatojn poste kaj vidu kio okazis. Eĉ bona skemo kiel mapado de valorfluo havas, ni diru, blindpunktojn. Post centoj da intervjuoj kun direktoroj de diversaj kompanioj, mi evoluigis certan ŝablonon, kiu permesas al ni malkonstrui la problemon en ĝiajn komponantojn, kaj nun ni diskutos ĉiun el ĉi tiuj komponantoj en ordo. Antaŭ ol apliki ajnajn teknologiajn solvojn, mi uzas ĉi tiun ŝablonon, kaj kiel rezulto, ĉiuj miaj muroj estas kovritaj per diagramoj. Lastatempe mi laboris kun reciproka fonduso kaj mi finis kun 100-150 tiaj skemoj.
Malbona kulturo manĝas bonajn alirojn por matenmanĝo
La ĉefa ideo estas ĉi tio: neniu kvanto da Lean, Agile, SAFE kaj DevOps helpos se la kulturo de la organizo mem estas malbona. Ĝi estas kiel plonĝado ĝis profundo sen skubo-ilaro aŭ funkcii sen radiografio. Alivorte, parafrazi Drucker kaj Deming: malbona organiza kulturo englutos ajnan bonan sistemon sen sufoki ĝin.
Por solvi ĉi tiun ĉefan problemon, vi devas fari la jenajn paŝojn:
- Faru Ĉian Laboron Videbla: vi devas vidigi la tutan laboron. Ne en la senco, ke ĝi nepre devas esti montrata sur iu ekrano, sed en la senco, ke ĝi devas esti observebla.
- Plifirmigitaj Laboraj Administradaj Sistemoj: mastrumaj sistemoj devas esti firmigitaj. En la problemo de "triba" scio kaj institucia scio, en 9 kazoj el 10 la botelkolo estas homoj. En la libro la problemo estis kun unu ununura persono, Brent, kiu igis la projekton esti tri jarojn malantaŭ horaro. Kaj mi renkontas ĉi tiujn "Brent'ojn" ĉie. Por solvi ĉi tiujn botelojn, mi uzas la sekvajn du erojn en nia listo.
- Metodologio de Teorio de Limoj: teorio de limoj.
- Kunlaboraj hakoj: kunlaboraj hakoj.
- Toyota Kata (): Mi ne multe parolos pri la Toyota Kata. Se interesiĝas, sur mia github pri preskaŭ ĉiu el ĉi tiuj temoj.
- Merkata Orientita Organizo: merkat-orientita organizo.
- Ŝanĝ-maldekstremaj revizoroj: revizio en fruaj stadioj de la ciklo.
Mi komencas labori kun organizo tre simple: mi iras al la firmao kaj parolas kun la dungitoj. Kiel vi povas vidi, neniu alta teknologio. Vi nur bezonas ion por skribi. Mi kolektas plurajn teamojn en unu ĉambro kaj analizas tion, kion ili diras al mi el la perspektivo de miaj 7 arketipoj. Kaj poste mi mem donas al ili markilon kaj petas ilin noti sur la tabulon ĉion, kion ili ĝis nun laŭte diris. Kutime en ĉi tiaj renkontiĝoj estas unu homo, kiu skribas ĉion, kaj plej bone li povas noti 10% de la diskuto. Kun mia metodo, ĉi tiu cifero povas esti altigita al ĉirkaŭ 40%.
(Ĉi tiu ilustraĵo videblas aparte )
Mia aliro baziĝas sur la laboro de William Schneider. ). La aliro baziĝas sur la ideo, ke iu ajn organizo povas esti dividita en kvar kvadratojn. Ĉi tiu skemo por mi kutime estas la rezulto de laboro kun tiuj centoj da aliaj skemoj, kiuj aperas kiam oni analizas organizon. Supozu, ke ni havas organizon kun alta nivelo de kontrolo, sed kun malalta kompetenteco. Ĉi tio estas ege nedezirinda opcio: kiam ĉiuj iras al la linio, sed neniu scias kion fari.
Iom pli bona elekto estas unu kun alta nivelo de kaj kontrolo kaj kompetenteco. Se tia kompanio estas profita, tiam eble ĝi ne bezonas DevOps. Plej interese estas labori kun kompanio, kiu havas altan nivelon de kontrolo, malaltan kompetentecon kaj kunlaboron, sed samtempe altnivelan de kulturo (kultivado). Ĉi tio signifas, ke la kompanio havas multajn homojn, kiuj ŝatas labori tie kaj la laborŝanĝo estas malalta.
(Ĉi tiu ilustraĵo videblas aparte )
Ŝajnas al mi, ke metodoj kun rigidaj gvidlinioj finas malhelpante atingi la veron. En valorflua mapado precipe, ekzistas multaj reguloj pri kiel informoj devus esti strukturitaj. En la fruaj stadioj de laboro, pri kiu mi nun parolas, neniu bezonas ĉi tiujn regulojn. Se persono kun markilo en siaj manoj priskribas la realan situacion en la kompanio sur la tabulo, ĉi tiu estas la plej bona maniero kompreni la staton de aferoj. Tiaj informoj ne atingas direktorojn. En ĉi tiu momento, estas stulte interrompi la personon kaj diri, ke li desegnis ian sagon malĝuste. En ĉi tiu etapo, estas pli bone uzi simplajn regulojn, ekzemple: plurnivela abstraktado povas esti kreita simple uzante multkolorajn markilojn.
Mi ripetas, neniu alta teknologio. La nigra signo prezentas la objektivan realecon de kiel ĉio funkcias. Per ruĝa signo, homoj markas tion, kion ili ne ŝatas pri la nuna stato. Gravas, ke ili skribu ĉi tion, ne mi. Kiam mi iras al la CIO post kunveno, mi ne proponas liston de 10 aferoj, kiujn oni devas ripari. Mi strebas trovi ligojn inter tio, kion diras homoj en la kompanio kaj ekzistantaj pruvitaj ŝablonoj. Fine, blua signo sugestas eblajn solvojn al la problemo.
(Ĉi tiu ilustraĵo videblas aparte )
Ekzemplo de ĉi tiu aliro nun estas prezentita supre. Komence de ĉi tiu jaro mi laboris kun unu banko. La sekurecaj homoj tie estis konvinkitaj, ke ili ne devus veni al revizioj pri dezajno kaj postulo.
(Ĉi tiu ilustraĵo videblas aparte )
Kaj tiam ni parolis kun homoj de aliaj fakoj kaj montriĝis, ke antaŭ ĉirkaŭ 8 jaroj, programistoj maldungis sekurecajn laboristojn ĉar ili malrapidigis laboron. Kaj tiam ĝi fariĝis malpermeso, kiu estis akceptita. Kvankam fakte ne estis malpermeso.
Nia renkontiĝo daŭris en ekstreme konfuza maniero: dum ĉirkaŭ tri horoj, kvin malsamaj teamoj ne povis klarigi al mi kio okazis inter la kodo kaj la asembleo. Kaj ĉi tio ŝajnus esti la plej simpla afero. Plej multaj DevOps-konsultistoj supozas, ke ĉiuj jam scias ĉi tion.
Tiam la respondeculo pri IT-regado, kiu silentis dum kvar horoj, subite reviviĝis, kiam ni alvenis al lia temo, kaj tre longe okupis nin. Fine mi demandis lin, kion li pensas pri la renkontiĝo, kaj mi neniam forgesos lian respondon. Li diris: "Mi antaŭe pensis, ke nia banko havas nur du manierojn liveri programaron, sed nun mi scias, ke estas kvin el ili, kaj mi eĉ ne sciis pri tri."
(Ĉi tiu ilustraĵo videblas aparte )
La lasta renkontiĝo ĉe ĉi tiu banko estis kun la investa programaro teamo. Estis ĉe ŝi, ke montriĝis, ke skribi diagramojn per markilo sur paperfolio estas pli bona ol sur tabulo, kaj eĉ pli bone ol sur smartboard.
La fotoj, kiujn vi vidas, estas kiel la hotela konferenca ĉambro aspektis en la kvara tago de nia renkontiĝo. Kaj ni uzis ĉi tiujn skemojn por serĉi ŝablonojn, tio estas, arketipojn.
Do, mi demandas al la laboristoj, ili skribas la respondojn per markiloj de tri koloroj (nigra, ruĝa kaj blua). Mi analizas iliajn respondojn por arketipoj. Nun ni diskutu ĉiujn arketipojn en ordo.
1. Faru Ĉian Laboron Videbla: Vidigu laboron
Plej multaj kompanioj kun kiuj mi laboras havas tre altan procenton de nekonata laboro. Ekzemple, ĉi tio estas kiam unu dungito venas al alia kaj simple petas fari ion. En grandaj organizoj povas esti 60% neplanita laboro. Kaj ĝis 40% de la laboro neniel estas dokumentita. Se ĝi estus Boeing, mi neniam surirus ilian aviadilon denove en mia vivo. Se nur duono de la laboro estas dokumentita, tiam oni ne scias ĉu tiu laboro estas farita ĝuste aŭ ne. Ĉiuj aliaj metodoj montriĝas senutilaj - ne utilas provi aŭtomatigi ion, ĉar la konata 50% eble estas la plej kohera kaj klara parto de la laboro, kies aŭtomatigo ne donos grandajn rezultojn, kaj plej malbonan. aferoj estas en la nevidebla duono. Manke de dokumentado, estas neeble trovi ĉiajn hakojn kaj kaŝitajn laborojn, ne trovi botelojn, tiujn tre "Brent-ojn", pri kiuj mi jam parolis. Estas mirinda libro de Dominica DeGrandis . Ŝi malkaŝas kvin malsamaj "tempaj likoj" (ŝtelistoj de tempo):
- Tro da Laboro en Procezo (WIP)
- Nekonataj Dependecoj
- Neplanita Laboro
- Konfliktantaj prioritatoj
- Neglektita Laboro
Ĉi tio estas tre valora analizo kaj la libro estas bonega, sed ĉiuj ĉi konsiloj estas senutilaj se nur 50% de la datumoj estas videblaj. La metodoj proponitaj de Dominiko povas esti uzataj se precizeco de super 90% estas atingita. Mi parolas pri situacioj, kie estro donas al subulo 15-minutan taskon, sed necesas al li tri tagoj; sed la estro ne vere scias, ke tiu ĉi subulo dependas de kvar aŭ kvin aliaj homoj.
La Phoenix Project estas mirinda rakonto pri projekto kiu estis tri jaroj tro malfrue. Unu el la karakteroj renkontas maldungon pro tio, kaj li renkontiĝas kun alia karaktero kiu estas prezentita kiel speco de Sokrato. Li helpas eltrovi kio precize misfunkciis. Montriĝas, ke la kompanio havas unu sisteman administranton, kies nomo estas Brent, kaj ĉiu laboro iel trairas lin. Ĉe unu el la kunvenoj oni demandas al unu el la subuloj: kial ĉiu duonhora tasko daŭras semajnon? La respondo estas tre simpligita prezento de vica teorio kaj la leĝo de Little, kaj en ĉi tiu prezento rezultas, ke ĉe 90% da okupado, ĉiu horo da laboro daŭras 9 horojn. Ĉiu tasko devas esti sendita al sep aliaj homoj, tiel ke tiu horo fariĝas 63 horoj, 7 oble 9. La punkto, kiun mi diras, estas, ke por uzi la Leĝon de Etulo aŭ ajnan kompleksan teorion pri vico, oni almenaŭ bezonas havi datumojn.
Do kiam mi parolas pri videbleco, mi ne volas diri, ke ĉio estas sur la ekrano, sed ke vi almenaŭ havas datumojn. Kiam ili faras, ofte montriĝas, ke estas tre granda kvanto da neplanita laboro, kiu estas iel sendita al Brent kiam ne necesas. Kaj Brent estas bonega ulo, li neniam diros ne, sed li rakontas al neniu kiel li faras sian laboron.
Kiam la laboro estas videbla, la datumoj povas esti bonorde klasitaj (tion Dominika faras en la foto), la abstraktado de la kvin-fojaj likoj povas esti aplikita, kaj aŭtomatigo povas esti aplikita.
2. Plifirmigi Laborajn Administrajn Sistemojn: Task-Administrado
La arketipoj pri kiuj mi parolas estas ia piramido. Se la unua estas farita ĝuste, tiam la dua jam estas speco de aldonaĵo. Multaj el ĉi tiuj ne funkcias por noventreprenoj, ili devas esti konservitaj en menso por pli grandaj kompanioj kiel la Fortune 5000. La lasta kompanio, por kiu mi laboris, havis 10 biletajn sistemojn. Unu teamo havis Remedy, alia skribis ian propran sistemon, tria uzis Jira, kaj kelkaj kontentiĝis per retpoŝto. La sama problemo ekestas se la kompanio havas 30 malsamajn duktojn, sed mi ne havas tempon por diskuti ĉiujn tiajn kazojn.
Mi diskutas kun homoj ĝuste kiel biletoj estas kreitaj, kio okazas al ili poste, kaj kiel ili estas evititaj. La plej interesa afero estas, ke homoj ĉe niaj kunvenoj parolas sufiĉe sincere. Mi demandis, kiom da homoj metas "negravan/sen efikon" al biletoj al kiuj efektive oni devus doni "gravan efikon". Montriĝis, ke preskaŭ ĉiuj faras tion. Mi ne okupiĝas pri denunco kaj provas ĉiumaniere ne identigi homojn. Kiam ili sincere konfesas ion al mi, mi ne fordonas la personon. Sed kiam preskaŭ ĉiuj preterpasas la sistemon, tio signifas, ke ĉiu sekureco estas esence fenestra vestaĵo. Tial, neniuj konkludoj povas esti tiritaj de la datumoj de ĉi tiu sistemo.
Por solvi la biletan problemon, vi devas elekti unu ĉefan sistemon. Se vi uzas Jira, konservu ĝin Jira. Se ekzistas ia alternativo, ĝi estu la sola. La fundo estas, ke biletoj devas esti rigardataj kiel alia paŝo en la evoluprocezo. Ĉiu ago devas havi bileton, kiu devas flui tra la evolua laborfluo. Biletoj estas senditaj al la teamo, kiu afiŝas ilin sur la rakonttabulo kaj tiam prenas respondecon por ili.
Ĉi tio validas por ĉiuj fakoj, inkluzive de infrastrukturo kaj operacioj. En ĉi tiu kazo, eblas formi almenaŭ ian kredeblan ideon pri la stato de la aferoj. Post kiam ĉi tiu procezo estas establita, subite fariĝas facile identigi, kiu respondecas pri ĉiu aplikaĵo. Ĉar nun ni ricevas ne 50%, sed 98% de novaj servoj. Se ĉi tiu kernprocezo funkcias, tiam precizeco pliboniĝas tra la sistemo.
Servodukto
Ĉi tio denove validas nur por grandaj korporacioj. Se vi estas nova kompanio en nova kampo, rulu viajn manikojn kaj laboru kun via Travis CI aŭ CircleCI. Kiam temas pri Fortune 5000 kompanioj, ekzemplo kiu okazis ĉe la banko kie mi laboris. Guglo venis al ili kaj oni montris al ili diagramojn de malnovaj IBM-sistemoj. La uloj de Guglo demandis konfuzite - kie estas la fontkodo por tio? Sed ne ekzistas fontkodo, eĉ ne GUI. Jen la realo, kiun grandaj organizoj devas trakti: 40-jaraj bankaj registroj sur antikva ĉefkomputilo. Unu el miaj klientoj uzas Kubernetes-ujojn kun Circuit Breaker-ŝablonoj, plus Chaos Monkey, ĉio por la aplikaĵo KeyBank. Sed ĉi tiuj ujoj finfine konektas al COBOL-aplikaĵo.
La uloj de Guglo estis tute certaj, ke ili solvos ĉiujn problemojn de mia kliento, kaj tiam ili komencis demandi demandojn: kio estas IBM-datupo? Oni diras al ili: ĉi tio estas konektilo. Al kio ĝi konektas? Al la Sperry-sistemo. Kaj kio estas tio? Kaj tiel plu. Unuavide ŝajnas: kia DevOps povas esti? Sed fakte, ĝi eblas. Estas liveraj sistemoj, kiuj permesas vin transdoni la laborfluon al la liveraj teamoj.
3. Teorio de Limoj: Teorio de Limoj
Ni transiru al la tria arketipo: institucia/"triba" scio. Kiel regulo, en iu ajn organizo estas pluraj homoj, kiuj scias ĉion kaj administras ĉion. Ĉi tiuj estas tiuj, kiuj estis en la organizo plej longe kaj kiuj konas ĉiujn solvojn.
Kiam ĉi tio aperas sur la diagramo, mi specife rondiras tiajn homojn per markilo: ekzemple, evidentiĝas, ke certa Lou ĉeestas ĉe ĉiuj kunvenoj. Kaj estas klare al mi: ĉi tio estas loka Brent. Kiam la CIO elektas inter mi en T-ĉemizo kaj sneakers kaj la ulo de IBM en vestokompleto, mi estas elektita ĉar mi povas rakonti al la direktoro aferojn, kiujn la alia ulo ne rakontos kaj ke la direktoro eble ne ŝatus aŭdi. . Mi diras al ili, ke la proplemkolo en ilia kompanio estas iu nomata Fred kaj iu nomata Lou. Ĉi tiu botelkolo devas esti malligita, ilia scio devas esti akirita de ili iel aŭ alie.
Por solvi tian problemon, mi povas, ekzemple, sugesti uzi Slack. Saĝa direktoro demandos - kial? Tipe, en tiaj kazoj, DevOps-konsultistoj respondas: ĉar ĉiuj faras ĝin. Se la direktoro estas vere saĝa, li diros: do kio. Kaj ĉi tie finiĝas la dialogo. Kaj mia respondo al ĉi tio estas: ĉar estas kvar proplempunktoj en la firmao, Fred, Lou, Susie kaj Jane. Por instituciigi ilian scion, oni devas unue enkonduki Slack. Ĉiuj viaj vikioj estas tute sensencaĵo ĉar neniu scias pri ilia ekzisto. Se la inĝenieristiko estas implikita en antaŭa kaj malantaŭa disvolviĝo kaj ĉiuj devas scii, ke ili povas kontakti la antaŭan disvolvan teamon aŭ la infrastrukturan teamon kun demandoj. Tiam Lu aŭ Fred verŝajne havos tempon por aliĝi al la vikio. Kaj tiam en Slack iu povus demandi kial, ekzemple, paŝo 5 ne funkcias. Kaj tiam Lou aŭ Fred korektos la instrukciojn en la vikio. Se vi establas ĉi tiun procezon, tiam multaj aferoj ekfunkcios memstare.
Ĉi tio estas mia ĉefa punkto: por rekomendi iujn ajn altajn teknologiojn, vi unue devas ordigi la fundamenton por ili, kaj ĉi tio povas esti farita per la ĵus priskribitaj solvoj de malalta teknologio. Se vi komencas per altaj teknologioj kaj ne klarigas kial ili estas bezonataj, tiam, kiel regulo, ĉi tio ne finiĝas bone. Unu el niaj klientoj uzas Azure ML, tre malmultekosta kaj simpla solvo. Ĉirkaŭ 30% de iliaj demandoj estis responditaj de la memlernanta maŝino mem. Kaj ĉi tiu afero estis skribita de telefonistoj, kiuj ne okupiĝis pri datuma scienco, statistiko aŭ matematiko. Ĉi tio estas signifa. La kosto de tia solvo estas minimuma.
4. Kunlaboraj hakoj: Kunlaboraj hakoj
La kvara arketipo estas la bezono batali izoladon. Plej multaj homoj jam scias ĉi tion: izoliteco naskas malamikecon. Se ĉiu fako estas sur sia propra etaĝo, kaj homoj neniel intersekcas unu kun la alia, krom en la lifto, tiam malamikeco inter ili estiĝas tre facile. Sed se, male, homoj estas en la sama ĉambro unu kun la alia, ŝi tuj foriras. Kiam iu elĵetas iun ĝeneralan akuzon, ekzemple, tia kaj tia interfaco neniam funkcias, estas nenio pli facila por malkonstrui tian akuzon. La programistoj, kiuj skribis la interfacon, bezonas nur komenci demandi specifajn demandojn, kaj baldaŭ evidentiĝos, ke ekzemple la uzanto simple uzis la ilon malĝuste.
Estas multaj manieroj venki izoladon. Iam oni petis min konsulti por banko en Aŭstralio, sed mi rifuzis fari tion ĉar mi havas du infanojn kaj edzinon. Ĉio, kion mi povis fari por helpi ilin, estis rekomendi grafikan rakontadon. Ĉi tio estas io pruvita funkcii. Alia interesa maniero estas sveltaj kafaj renkontiĝoj. En granda organizo, ĉi tio estas bonega eblo por disvastigi scion. Krome, vi povas fari internajn devopsdays, hackatons, ktp.
5. Trejnado de Kata
Kiel mi avertis ĉe la komenco, mi ne parolos pri tio hodiaŭ. Se vi interesiĝas, vi povas rigardi .
Ankaŭ estas bona parolado pri ĉi tiu temo de Mike Rother:
6. Market Oriented: merkat-orientita organizo
Estas malsamaj problemoj ĉi tie. Ekzemple, "I" homoj, "T" homoj kaj "E" homoj. "Mi" homoj estas tiuj, kiuj faras nur unu aferon. Tipe ili ekzistas en organizoj kun izolitaj fakoj. "T" estas kiam homo estas bona pri unu afero sed ankaŭ bona pri iuj aliaj aferoj. "E" aŭ eĉ "kombilo" estas kiam homo havas multajn kapablojn.
La leĝo de Conway funkcias ĉi tie (), kiu en la plej simpligita formo povas esti konstatita jene: se tri teamoj laboras sur la kompililo, tiam la rezulto estos kompililo de tri partoj. Sekve, se ekzistas alta nivelo de izolado ene de organizo, tiam eĉ Kubernetes, Circuit breaker, API-etensebleco kaj aliaj luksaj aferoj en ĉi tiu organizo estos aranĝitaj same kiel la organizo mem. Strikte laŭ Conway kaj por ĉagreni vin ĉiuj junaj geeks.
La solvo de ĉi tiu problemo estis priskribita multfoje. Ekzistas, ekzemple, organizaj arketipoj priskribitaj de Fernando Fernandez. Tiu problema arkitekturo, pri kiu mi ĵus parolis, kun izoliteco, estas funkcio-orientita arkitekturo. La dua tipo estas la plej malbona, matrica arkitekturo, malordo de la aliaj du. La tria estas tio, kio vidiĝas en la plej multaj noventreprenoj, kaj grandaj kompanioj ankaŭ provas egali ĉi tiun tipon. Ĝi estas merkat-orientita organizo. Ĉi tie ni optimumigas por atingi la plej rapidan respondon al klientaj petoj. Ĉi tio foje estas nomita plata organizo.
Multaj homoj priskribas ĉi tiun strukturon en malsamaj manieroj, mi ŝatas la vortumon konstrui/kuri teamojn, ĉe Amazono ili nomas ĝin du picteamoj. En ĉi tiu strukturo, ĉiuj tipo "I" homoj estas grupigitaj ĉirkaŭ unu servo, kaj iom post iom ili iĝas pli proksimaj al tipo "T", kaj se la ĝusta administrado estas en loko, ili eĉ povas iĝi "E". La unua kontraŭargumento ĉi tie estas, ke tia strukturo havas nenecesajn elementojn. Kial vi bezonas testilon en ĉiu fako, se vi povas havi specialan fakon de testistoj? Al kio mi respondas: la kromkostoj en ĉi tiu kazo estas la prezo por la tuta organizo fariĝos tipo "E" estonte. En ĉi tiu strukturo, la testinto iom post iom lernas pri retoj, arkitekturo, dezajno ktp. Kiel rezulto, ĉiu partoprenanto en la organizo estas plene konscia pri ĉio, kio okazas en la organizo. Se vi volas scii kiel ĉi tiu skemo funkcias en industrio, legu .
7. Shift-maldekstraj revizoroj: revizio frue en la ciklo. Konformo al sekurecaj reguloj sur ekrano
Jen kiam viaj agoj ne trapasas la odorteston, por tiel diri. La homoj, kiuj laboras por vi, ne estas stultaj. Se, kiel en la supra ekzemplo, ili metis malgravan/nenian efikon ĉie, tio daŭris tri jarojn, kaj neniu rimarkis ion, tiam ĉiuj scias perfekte, ke la sistemo ne funkcias. Aŭ alia ekzemplo - ŝanĝa konsila komisiono, kie raportoj devas esti prezentitaj ĉiun, ekzemple, merkredon. Tie laboras grupo da homoj (cetere ne tre bone pagataj), kiuj teorie devus scii kiel funkcias la sistemo entute. Kaj dum la lastaj kvin jaroj, vi verŝajne rimarkis, ke niaj sistemoj estas nekredeble kompleksaj. Kaj kvin aŭ ses homoj devas decidi pri ŝanĝo, kiun ili ne faris kaj pri kiu ili scias nenion.
Kompreneble, ĉi tiu aliro ne funkcias. Mi devas forigi tiajn aferojn, ĉar ĉi tiuj homoj ne protektas la sistemon. La decido devas esti farita de la teamo mem, ĉar la teamo devas respondeci pri ĝi. Alie, paradoksa situacio ekestas kiam administranto, kiu neniam skribis kodon en sia vivo, diras al la programisto kiom da tempo necesas por skribi kodon. Unu firmao kun kiu mi laboris havis 7 malsamajn estrarojn, kiuj reviziis ĉiun ŝanĝon, inkluzive de arkitektura tabulo, produkta tabulo, ktp. Ekzistis eĉ deviga atendoperiodo, kvankam unu dungito diris al mi, ke en dek jaroj da laboro, neniu neniam malakceptis ŝanĝon faritan de tiu ĉi persono dum tiu ĉi deviga periodo.
Revizoroj devas esti invititaj aliĝi al ni, kaj ne forigi ilin. Diru al ili, ke vi skribas neŝanĝeblajn binarajn ujojn, kiuj, se ili trapasas ĉiujn provojn, restas neŝanĝeblaj por ĉiam. Diru al ili, ke vi havas dukton kiel kodon kaj klarigu kion tio signifas. Montru al ili la sekvan skemon: neŝanĝebla nurlegebla binaro en ujo, kiu trapasas ĉiujn provojn pri vundebleco; kaj tiam ne nur neniu tuŝas ĝin, ili eĉ ne tuŝas la sistemon kiu kreas la dukto, ĉar ĝi ankaŭ estas kreita dinamike. Mi havas klientojn, Capital One, kiuj uzas Vault por krei ion kiel blokĉenon. La revizoro ne bezonas montri "receptojn" de Chef; sufiĉas montri la blokĉenon, el kiu estas klare, kio okazis al la bileto Jira en produktado kaj kiu respondecas pri ĝi.
Laŭ , kreita en 2018 de Sonatype, estis 2017 miliardoj da OSS-elŝutaj petoj en 87.
La perdoj faritaj pro vundeblecoj estas malpermesaj. Krome, la ciferoj, kiujn vi nun vidas supre, ne inkluzivas oportunajn kostojn. Kio estas DevSecOps resume? Mi diru tuj, ke mi ne interesas paroli pri kiom sukcesa estas ĉi tiu nomo. La punkto estas, ke ĉar DevOps estis tiel sukcesa, ni devus provi aldoni sekurecon al tiu dukto.
Ekzemplo de ĉi tiu sekvenco:
Ĉi tio ne estas rekomendo por specifaj produktoj, kvankam mi ŝatas ĉiujn. Mi citis ilin kiel ekzemplon por montri, ke DevOps, kiu estis komence bazita sur la organiza paradigmo en industrio, permesas vin aŭtomatigi ĉiun etapon de laboro sur produkto.
Kaj ne ekzistas kialo kial ni ne povus preni la saman aliron al sekureco.
La rezulto
Kiel konkludo, mi donos kelkajn konsiletojn por DevSecOps. Vi devas inkluzivi revizorojn en la procezo de kreado de viaj sistemoj kaj pasigi tempon por eduki ilin. Vi devas kunlabori kun revizoroj. Poste, vi devas fari absolute senkompatan batalon kontraŭ falsaj pozitivoj. Eĉ kun la plej multekosta skanilo de vundebleco, vi povas fini krei ege malbonajn kutimojn inter viaj programistoj se vi ne scias, kio estas via signalo-bruo-proporcio. Programistoj estos superŝutitaj de eventoj kaj simple forigos ilin. Se vi aŭdis pri la rakonto de Equifax, tio estas preskaŭ kio okazis tie, kie la plej alta atentiga nivelo estis ignorita. Krome, vundeblecoj devas esti klarigitaj en maniero, kiu klarigas kiel ili influas la komercon. Ekzemple, vi povus diri, ke ĉi tio estas la sama vundebleco kiel en la rakonto de Equifax. Sekurecaj vundeblecoj devas esti traktataj same kiel aliaj programaraj problemoj, tio estas, ili devus esti inkluzivitaj en la ĝenerala procezo de DevOps. Vi devas labori kun ili per Jira, Kanban, ktp. Programistoj ne pensu, ke iu alia faros tion - male, ĉiuj devus fari tion. Fine, vi devas elspezi energion por trejni homojn.
utilaj ligoj
Jen kelkaj paroladoj de la DevOops-konferenco, kiujn vi eble trovos utilaj:
- Sergey Berdnikov, Artyom Kalichkin - Sukceshistorio, aŭ "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps en skalo: greka tragedio en tri aktoj (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Rigardu DevOops 2020 Moskvo — tie estas ankaŭ multaj interesaj aferoj.
fonto: www.habr.com