🥇Shtatë arketipe të transformimit sipas parimeve DevOps

Pyetja "si të implementojmë DevOps" ka disa vite që diskutohet, por materialet e mira janë të pakta. Ndonjëherë bëheni pre e reklamave të këshilltarëve jo aq të mençur, të cilët duan të shesin kohën e tyre, pa rëndësi si. Ndonjëherë, ato janë fjalë të paqarta dhe shumë të përgjithshme për mënyrën se si anijet e megakorporatave udhëtojnë përmes hapësirës. Lind pyetja: çfarë do të fitojmë ne nga kjo? Autor i nderuar, mund të sintetizoni idetë tuaja në një listë të qartë?

I gjithë ky informacion vjen nga fakti se praktika reale dhe kuptimi i rezultateve të transformimeve kulturore janë akumuluar jo aq shumë. Ndryshimet në kulturë janë procese afatgjata, rezultatet e të cilave nuk do shfaqen për një javë e as një muaj. Na nevojitet dikush mjaft i vjetër, i cili ka parë si janë ndërtuar dhe shkatërruar kompanitë gjatë shumë viteve.

John Willis — një nga baballarët e DevOps. John ka qenë për shumë vite duke punuar me një numër të madh kompanish. Kohët e fundit, ai ka filluar të vërejë modele specifike që janë të pranishme në punën me secilën prej tyre. Duke përdorur këto arketipa, John e udhëzon kompanitë në rrugën e duhur për transformimin DevOps. Më shumë rreth këtyre arketipave mund të gjeni në përkthimin e fjalimit të tij nga konference DevOops 2018.

Rreth folësit:

Më shumë se 35 vjet në menaxhimin IT, ka ndihmuar në krijimin e paraardhësit të OpenCloud në Canonical, ka marrë pjesë në 10 startupe, dy prej të cilave i shiti Dell dhe Docker. Tani është Zv.president i DevOps dhe Praktikave Digjitale në SJ Technologies.

Më pas, një tregim nga këndvështrimi i John.

Unë quhem John Willis, dhe më lehtë mund të më gjeni në Twitter, @botchagalupe. Ky është gjithashtu pseudonimi im në Gmail dhe GitHub. Ndërsa në këtë link mund të gjeni videot e fjalimeve të mia dhe prezantimet e lidhura me to.

Kam shumë takime me CIO të kompanive të mëdha. Ato shpesh ankohen se nuk kuptojnë se çfarë është DevOps, dhe çdo kush që përpiqet t'ua shpjegojë, flet për diçka tjetër. Një ankesë tjetër e zakonshme është se DevOps nuk funksionon, ndonëse duket se drejtuesit po bëjnë gjithçka siç u është shpjeguar. Bëhet fjalë për kompani të mëdha, të cilat janë mbi njëqind vjeçare. Pas bisedave me ta, arrita në përfundimin se për shumë probleme, zgjidhjet më të mira nuk janë teknologjitë e larta, por zgjidhje relativisht me teknologji të ulët. Për disa javë, thjesht bisedova me njerëz nga departamente të ndryshme. Ajo që shihni në imazhin e parë në postim — është projekti im më i fundit, dhoma dukej kështu pas tre ditësh pune.

Çfarë është DevOps?

Në të vërtetë, nëse i kërkon 10 persona të ndryshëm, ata do të japin 10 përgjigje të ndryshme. Por ja që është interesante: të gjitha këto dhjetë përgjigje do të jenë të sakta. Nuk ka përgjigje të gabuara këtu. Unë jam angazhuar thellë në DevOps për rreth 10 vjet, isha amerikan i parë në DevOpsDay të parë. Nuk do të thosha se jam më i zgjuar se të gjithë ata që merren me DevOps, por nuk mendoj se ka ndonjë që ka investuar aq shumë energji. Mendoj se DevOps ndodh kur bashkohen kapitali njerëzor dhe teknologjia. Shpesh e harrojmë dimensionin njerëzor, ndonëse flasim shumë për lloje të ndryshme kulturash.

Aktualisht, ne kemi shumë të dhëna, pesë vjet hulumtime akademike, dhe verifikim teorish të vendosur në shkallë industriale. Këto hulumtime na tregojnë se: nëse në kulturën organizative kombinohen disa modele sjelljeje, mund të arrihet një shpejtësi 2000 herë më të lartë. Kjo shpejtësi korrespondon me një përmirësim të ngjashëm në qëndrueshmëri. Ky është një matës kuantitativ i avantazhit që DevOps mund t'i japë çdo kompanie. Disa vite më parë, i tregova DevOps një direktori të një kompanie në listën e Fortune 5000. Kur po përgatitesha për prezantimin, isha shumë i nervozuar sepse duhej të paraqisja përvojën time të shumëvjeçare brenda 5 minutash.

Si përfundim, unë ofrova këtë përkufizim të DevOps: është një grup praktikash dhe modeleve që lejojnë shndërrimin e kapitalit njerëzor në kapital organizativ me performancë të lartë. Një shembull është mënyra se si Toyota punon për 50 ose 60 vitet e fundit.

(Këtu dhe më pas, këto skema janë dhënë jo si materiale referuese, por si ilustruese. Përmbajtja e tyre do të ndryshojë për çdo kompani të re. Megjithatë, imazhin mund ta shihni veçmas dhe ta zmadhojeni në këtë lidhje.)

Një nga praktikat më të suksesshme të tilla është hartimi i vlerës së rrjedhës. Për këtë janë shkruar disa libra të mirë, autori i më të suksesshëmve është Karen Martin. Por gjatë vitit të fundit kam arritur në përfundimin se edhe ky qasje është shumë teknologjike. Pa dyshim, ka shumë avantazhe, unë i kam përdorur ata shumë. Por kur CEO-i pyet se pse kompanisë së tij nuk i pëlqen të kalojë në binarë të rinj, është ende herët të flasim për hartimin e vlerës së rrjedhës. Ka shumë pyetje thelbësore, për të cilat duhet të gjejmë fillimisht përgjigje.

Mendoj se gabimi i shumë kolegëve të mi është se ata thjesht i japin kompanisë një udhëzues me pesë pika dhe pastaj kthehen pas gjashtë muajsh për të parë se çfarë ndodhi. Edhe një skemë e mirë siç është hartimi i vlerës ka, të themi, zona të vdekur (blind spots). Pas qindra intervistash me drejtues të kompanive të ndryshme, kam zhvilluar një model të caktuar që lehtëson ndarjen e problemit në përbërës, dhe tani do të diskutojmë radhazi çdo një nga këta përbërës. Para se të zbatoj ndonjë zgjidhje teknologjike, unë përdor këtë model, dhe si rezultat, të gjitha muret e mia janë mbushur me skema. Së fundmi, kam punuar me një fond të përbashkët, dhe në fund kam pasur 100-150 të tilla skema.

Kultura e keqe gërryen qasje të mira për mëngjes.

Mesazhi kryesor është ky: asnjë Lean, Agile, SAFE dhe DevOps nuk do të ndihmojnë, nëse kultura e organizatës është e keqe. Kjo është njësoj si të zhytësh pët thellësi pa një aparat respiratori ose të operosh pa një снимanje radiografike. Në të tjera fjalë, duke e riparafrazuar Druckerin dhe Demingun: kultura e organizatës së keqe do të gëlltitë çdo sistem të mirë dhe nuk do të kapet.

Për të zgjidhur këtë problem kryesor, është e nevojshme të ndërmerren hapat e mëposhtëm:

Bëni të gjithë punën të dukshme: duhet të bëhet e gjithë puna e dukshme. Jo në kuptimin që ajo duhet patjetër të shfaqet në ndonjë ekran, por në kuptimin që ajo duhet të jetë e vëzhgueshme.
Konsolidoni sistemet e menaxhimit të punës: është e nevojshme të konsolidohen sistemet e menaxhimit. Në problemin e dijes «tribale» dhe dijes institucionale, në 9 raste nga 10 pika e ngadalësimit janë njerëzit. Në librin «Projekti Phoenix» problemi ishte te një person i vetëm, Brenti, i cili e çoi projektin në vonesë prej tre vitesh. Dhe tek këta «Brentë» hasem kudo. Për të shfuqizuar këto ngadalësime, unë përdor dy pikë në listën tonë.
Metodologjia e Teorisë së Kufizimeve: teoria e kufizimeve.
Hakat e bashkëpunimit: hakat e bashkëpunimit.
Toyota Kata (Kata Trajnimi): në lidhje me Toyota Kata nuk do të flas shumë. Nëse jeni të interesuar, në GitHub-in tim ka prezantime për pothuajse çdo një nga këto tema.
Organizata e Orientuar ndaj Tregut: organizata e orientuar ndaj tregut.
Auditorët e shift-it të majtë: auditi në fazat e hershme të ciklit.

Të fillosh të punosh me një organizatë është shumë e thjeshtë: shkoj në kompani dhe bisedoj me punonjësit. Siç e shohim, nuk është e nevojshme ndonjë teknologji e avancuar. E vetmja gjë që kërkohet është një vend për të shkruar. Grumbulloj disa ekipe në një dhomë dhe analizoj atë që ata më thonë në lidhje me 7 arketipet e mi. Pastaj, u jap atyre një marker dhe kërkoj që të shkruajnë në tabllo gjithçka që deri tani kanë thënë me zë të lartë. Zakonisht në takime të tilla ka një person që e regjistron gjithçka, dhe në më të mirën e rasteve arrin të shkruajë 10% të diskutimit. Me metodën time, ky tregues arrin deri në 40%.

(Separat këtë ilustrim mund ta shihni në lidhje)

Qasja ime bazohet në punën e William Schneider (William Schneider, The Reengineering Alternative). Në thelb të qasjes është mendimi se çdo organizatë mund të ndahen në katër katrorë. Ky skemë zakonisht është rezultat i punës time me ato qindra skema të tjera që shfaqen gjatë analizës së organizatës. Le të supozojmë se kemi një organizatë me një nivel të lartë kontrolli, por me një kompetencë të ulët. Ky është një variant jashtëzakonisht i padëshiruar: kur të gjithë ecin sipas rregullave, por askush nuk e di se çfarë duhet të bëjë.

Pak më mirë është varianti me nivel të lartë kontrolli dhe kompetence. Nëse një kompani e tillë ka fitim, ndoshta DevOps-i nuk i nevojitet. Më interesante është të punosh me një kompani që ka një nivel të lartë kontrolli, kompetencë të ulët dhe bashkëpunim, por njëkohësisht një kulturë të lartë (cultivation). Kjo do të thotë se kompania ka shumë njerëz që e pëlqejnë të punojnë aty, dhe shkalla e turnover-it të fuqisë punëtore është e ulët.

(Separat këtë ilustrim mund ta shihni në lidhje)

Më duket se metodat me rekomandime te rrepta në fund të fundit pengojnë arritjen e të vërtetës. Në veçanti, në hartimin e fluxit të vlerës ka shumë rregulla se si duhet strukturuar informacioni. Në fazat e hershme të punës, për të cilat po flas tani, këto rregulla askujt nuk i nevojiten. Nëse një person me një marker në dorë përshkruan në tabllo një situatë reale në kompani, ky është mënyra më e mirë për të kuptuar situatën. Këto informacione nuk arrijnë deri te drejtorët. Në këtë moment është qesharake të ndërpresësh një person dhe të thuash se ai e ka vizatuar gabim një arrow. Në këtë fazë është më mirë të përdoren rregulla të thjeshta, për shembull: një abstraksion me shumë nivele mund të krijohet thjesht duke përdorur markerë të shumëngjyrshëm.

Po e përsëris, asnjë teknologji e lartë. Me ngjyrë të zezë paraqitet realiteti objektiv, sesi funksionon gjithçka. Me ngjyrë të kuqe, njerëzit shënojnë atë që nuk u pëlqen në situatën aktuale. E rëndësishme është që ata e shkruajnë këtë dhe jo unë. Kur pas mbledhjes shkoj te drejtori i teknologjive të informacionit, nuk ofroj një listë prej 10 gjërash që duhen rregulluar. Synoj të gjej lidhjet mes asaj që thonë njerëzit nga kompanitë dhe modeleve ekzistuese të provuara. Fundja, me ngjyrë të blu sugjerohen zgjidhje të mundshme për problemin.

(Separat këtë ilustrim mund ta shihni në lidhje)

Një shembull i këtij qasjeje tani paraqitet më sipër. Në fillim të këtij viti kam punuar me një bankë. Punonjësit nga departamenti i sigurisë atje ishin të bindur se nuk mund të merrnin pjesë në kontrollet e kërkesave dhe projektimit.

(Separat këtë ilustrim mund ta shihni në lidhje)

Pastaj biseduam me njerëzit nga departamente të tjera dhe zbulova se diku 8 vjet më parë zhvilluesit e softuerit përjashtuan punonjësit e sigurisë, sepse ata ngadalësuan punën. Pastaj kjo u shndërrua në një ndalim që perceptohej si një fakt i vendosur. Megjithatë, në të vërtetë nuk kishte ndalim.

Takimi ynë kaloi në një rrjedhë shumë të ndërlikuar: për rreth tre orë pesë grupe të ndryshme nuk mundën të më shpjegonin se çfarë ndodhte midis kodit dhe ndërtimit. Dhe kjo, dukshëm, është gjëja më e thjeshtë. Shumica e këshilltarëve të DevOps mendojnë paraprakisht se kjo është diçka e njohur për të gjithë.

Më pas, njeriu që përgjigjej për rregullimin e IT (IT governance), i cili kishte qëndruar në heshtje për katër orë, papritmas u aktivizua kur arritëm në temën e tij dhe na mbajti për një kohë të gjatë. Në fund e pyesa se çfarë mendonte për takimin, dhe nuk do ta harroj kurrë përgjigjen e tij. Ai tha: "Më parë mendoja se në bankën tonë kishte vetëm dy mënyra për të dorëzuar softin, ndërsa tani e di se janë plot pesë, dhe për tre nga to nuk kisha asnjë ide."

(Separat këtë ilustrim mund ta shihni në lidhje)

Takimi fundit në këtë bankë ishte me ekipin që merret me softin për investime. Atje u zbulua se është më mirë të shkruash skemat me marker në letër sesa në tabelë, dhe madje më mirë sesa në smartboard.

Fotografitë që shihni janë se si dukej salla e konferencave të hotelit në ditën e katërt të takimit tonë. Dhe këto skema i përdorëm për të gjetur modele, pra arketipe.

Pra ndaj unë bëj pyetje punonjësve, ata regjistrojnë përgjigjet me tre ngjyra markerësh (të zezë, të kuqe dhe blu). Unë i analizoj përgjigjet e tyre për arketipe. Tani le të diskutojmë të gjitha arketipat një për një.

1. Bëni të gjitha punët të dukshme: Bëni punën të dukshme

Në shumicën e kompanive me të cilat punoj, përqindja e punës së paidentifikuar është shumë e lartë. Për shembull, kur një punonjës i kërkon një tjetër të bëjë diçka. Në organizatat e mëdha, mund të ketë deri në 60% punë të paplanifikuar. Dhe deri në 40% e punës nuk dokumentohet kurrë. Nëse do të isha te Boeing, nuk do të ulesha kurrë më në avionin e tyre. Nëse dokumentohet vetëm gjysma e punës, atëherë nuk dihet nëse kjo punë po kryhet siç duhet apo jo. Të gjitha metodat e tjera janë të pavlera — nuk ka kuptim të përpiqesh të automatizosh diçka, sepse ato 50% të njohura mund të jenë pikërisht ajo pjesë e punës që punon më mirë dhe më qartë, automatizimi i së cilës nuk do të japë rezultate të mëdha, ndërsa gjithçka më e tmerrshme është në gjysmën e padukshme. Pa dokumentacion, është e pamundur të gjesh çdo lloj hacks dhe punën e fshehur, si dhe të identifikosh ngushticat, ata 'Brent' që kam përmendur më herët. Ka një libër të shkëlqyer nga Dominika De Grandis «Making Work Visible». Ajo identifikon pesë "rrjedhje kohe" (thieves of time):

Puna në Proces të Tepërt (WIP)
Varësitë e Panjohura
Puna e Paplanifikuar
Prioritetet në Konflikt
Puna e Neglizhuar

Ky është një analizë shumë e vlefshme, dhe libri është i mrekullueshëm, por këto këshilla janë të padobishme nëse janë të dukshme vetëm 50% të të dhënave. Metodat e propozuara nga Dominika mund të aplikohen në rast se arrihet një saktësi mbi 90%. Po flas për situata kur shefi i jep një detyrë 15-minutëshe në nënështet, dhe ajo zgjat tre ditë; por shefi në të vërtetë nuk e di që ky nënështet varet edhe nga katër ose pesë persona të tjerë.

Projekti Phoenix — është një tregim fantastik për një projekt që ka vonuar tre vjet. Një nga heronjtë rrezikon të shkarkohet për këtë arsye, dhe ai takohet me një personazh tjetër, i cili paraqitet si një lloj Sokrati. Ai ndihmon që të kuptohet se çfarë ka shkuar keq. Zbulon se në kompani ka një sistem administrator të quajtur Brent, dhe e gjithë puna kalon përmes tij në një mënyrë ose një tjetër. Në një nga takimet, një nga nënordinarët pyetet: pse çdo detyrë gjysmë-orëshe zgjat një javë? Në përgjigje jepet një përmbledhje shumë e thjeshtëzuar e teorisë së radhëve dhe ligjit të Littles, dhe në këtë përmbledhje del se me 90% të angazhimit çdo orë pune zgjat 9 orë. Çdo detyrë duhet dërguar te shtatë njerëz të tjerë, kështu që kjo orë kthehet në 63 orë, 7 të shumëzuar me 9. Po e them këtë për të theksuar se për të përdorur ligjin e Littles ose ndonjë teori më të komplikuar të radhëve, duhet të kesh të paktën të dhëna.

Prandaj, kur flas për dukshmëri, kam parasysh jo që gjithçka të jetë në ekran, por që është e nevojshme të kemi të paktën të dhëna. Kur ato janë të pranishme, shpesh zbulohet se ka një volum të madh të punës së paplanifikuar që në njëfarë mënyre i dërgohet Brent-it, ndonëse nuk ka nevojë për të. Dhe Brent është një djalë i shkëlqyer, ai kurrë nuk do të thotë "jo", por nuk i tregon askujt se si e bën punën e tij.

Kur puna është e dukshme, mund të klasifikosh me kujdes të dhënat (kjo është pikërisht ajo që Dominika po bën në foto), mund të aplikosh abstraksionin e pesë rrjedhjeve të kohës dhe të automatizosh.

2. Konsolidoni Sistemet e Menaxhimit të Punës: Menaxhimi i detyrave

Archetipet për të cilat po flas përfaqësojnë një lloj piramide. Nëse i pari është realizuar siç duhet, atëherë i dyti është një lloj ndërtese mbi të. Shumica prej tyre nuk funksionojnë për startupe, duhet të merren parasysh në rast të kompanive të mëdha, si ato që kalojnë në listën Fortune 5000. Në kompaninë e fundit ku kam punuar, kishte 10 sisteme për ndjekjen e gabimeve (sistemi i ticketing). Një ekip përdorte Remedy, një tjetër kishte shkruar një sistem të vetin, të tretët përdornin Jira, dhe dikush thjesht e kishte me email. E njëjta problematikë ndodh nëse në kompani ka 30 pipeline të ndryshme, por nuk kam kohë për të diskutuar të gjitha këto raste.

Po diskutoj me njerëzit se si krijohen biletat, çfarë ndodh më pas me to, si i evitojnë ata. E gjitha është shumë interesante sepse njerëzit në takimet tona flasin mjaft sinqerisht. Unë pyeta se sa njerëz shënojnë 'minor / no impact' për biletat, të cilëve realisht do të duhej t'u jepej 'major impact'. Doli se kështu veprojnë pothuajse të gjithë. Unë nuk merrem me denoncime dhe përpiqem sa më shumë të mos identifikoj njerëzit. Kur dikush më beson sinqerisht, unë nuk e zbuloj atë. Por kur pothuajse të gjithë evitojnë sistemin, do të thotë që e gjithë siguria, në thelb, është vetëm një dekoratë. Prandaj, nuk mund të bëhen përfundime nga të dhënat e këtij sistemi.

Për të zgjidhur problemin me biletat, është e nevojshme të zgjidhni një sistem kryesor. Nëse përdorni Jira, le të jetë vetëm Jira. Nëse ka ndonjë alternativë, le të jetë vetëm ajo. Esenca është se biletat duhet të merren në konsideratë si një tjetër fazë e procesit të zhvillimit. Çdo veprim duhet të ketë një biletë, e cila duhet të kalojë përmes procesit të punës së zhvillimit. Biletat dërgohen në ekipin që i vendos ato në storyboard, dhe më pas merr përgjegjësi për to.

Kjo i përket të gjitha departamenteve, përfshirë atë të infrastrukturës dhe operacioneve. Në këtë rast, mund të krijohet një paraqitje e besueshme e situatës. Kur ky proces të funksionojë, papritmas del që është e lehtë të përcaktohet kush është përgjegjës për çdo aplikacion. Sepse tani po marrim jo 50%, por 98% të shërbimeve të reja. Nëse ky proces kryesor funksionon, atëherë saktësia rritet në të gjithë sistemin.

Pipeline i shërbimeve

Kjo sërisht i takon vetëm korporatave të mëdha. Nëse jeni një kompani e re në një fushë të re — ngjiteni mëngët dhe punoni me Travis CI ose CircleCI. Sa i përket kompanive Fortune 5000, një rast interesant ndodhi me bankën ku kam punuar. Ata morën vizita nga Google, të cilët u treguan grafikët me sistemet e vjetra IBM. Njerëzit nga Google, me mospërputhje, pyetën — ku është kodi burimor për këtë? Por nuk ka asnjë kod burimor, as nuk ka GUI. Kjo është realiteti me të cilin duhet të punojnë organizatat e mëdha: regjistrimet bankare të 40 viteve më parë në një mainframe të lashtë. Një nga klientët e mi përdor kontejnerë Kubernetes me modelet e Circuit Breaker, plus Chaos Monkey, gjithçka është për aplikacionin KeyBank. Por këta kontejnerë lidhen përfundimisht me një aplikacion në COBOL.

Djemtë nga Google ishin plotësisht të sigurt se do të zgjidhnin të gjitha problemet e klientit tim, dhe pastaj filluan të bëjnë pyetje: çfarë është IBM datapipe? Ata përgjigjen: është një konektues. Më çfarë lidhet? Me sistemin Sperry. E çfarë është kjo? Dhe kështu me radhë. Në shikim të parë duket: çfarë DevOps-i mund të ketë këtu? Por në të vërtetë, kjo është e mundur. Ekzistojnë sisteme shpërndarjeje që lejojnë kalimin e procesit të punës te ekipet që merren me shpërndarjen.

3. Teoria e Kufizimeve: Teoria e Kufizimeve

Të kalojmë te arketipi i tretë: njohuria institucionale / «tribale». Në përgjithësi, në çdo organizatë ekzistojnë disa njerëz që dinë gjithçka dhe drejtojnë të gjithë. Këta janë ata që kanë punuar më gjatë në organizatë dhe që njohin të gjitha rrugët alternative.

Kur kjo shfaqet në diagram, unë veçanërisht e rrethoj një person të tillë me një marker: për shembull, zbulohet se njëfarë Lou është në të gjitha takimet. Dhe për mua është e qartë: ai është Brent-i lokal. Kur drejtori i teknologjive të informacionit zgjidh ndërmjet meje në T-shirt dhe atleteve dhe djaloshit në kostum nga IBM, më zgjedhin sepse mund të i tregoj drejtorit për gjëra që ai, ai djaloshi tjetër, nuk do i tregojë dhe për të cilat drejtori mund të ndiejë pak keq. Unë u them atyre se në kompaninë e tyre ka një ngushticë, është një person që quhet Fred dhe një tjetër që quhet Lou. Kjo ngushticë duhet zgjidhur, njohuritë e tyre duhet nxjerrë përndryshe.

Për të zgjidhur këtë lloj problemi, unë mund të propozoj përdorimin e Slack. Një drejtor i zgjuar do të pyesë — pse? Zakonisht në këto raste, konsultantët e DevOps përgjigjen: sepse të gjithë bëjnë kështu. Nëse drejtorja është vërtet i zgjuar, ai do të thotë: mirë e çfarë. Dhe dialogu do të përfundojë atje. Dhe unë përgjigjem: sepse në kompani ka katër ngujime, Fred, Lu, Suzi dhe Džejn. Për të bërë njohuritë e tyre të institucionalizuara, e para duhet të prezantohet Slack. Të gjitha wiki-t tuaja janë tërësisht të kota, sepse askush nuk di për ekzistencën e tyre. Nëse skuadra e inxhinierëve merret me zhvillimin e brendshëm dhe të jashtëm, të gjithë duhet të dinë se mund të drejtohen te ekipi i zhvillimit të jashtëm ose te ekipi i infrastrukturës me pyetje. Në atë moment, ndoshta Lu ose Fred do të kenë kohë për të u lidhur me wiki-n. Më pas, në Slack, dikush mund të pyesë pse, le të themi, hapi 5 nuk funksionon. Dhe atëherë Lu ose Fred do ta korigjojnë udhëzimin në wiki. Nëse ky proces vendoset, shumë gjëra më pas do të veniten në vendin e tyre.

Këtu është mendimi im kryesor: për të rekomanduar disa teknologji të avancuara, së pari duhet të rregullojmë bazën për to, dhe kjo mund të bëhet me zgjidhje të ulëta teknologjike që u përmendën më parë. Nëse fillojmë me teknologjitë e avancuara dhe nuk shpjegojmë përse janë të nevojshme, zakonisht nuk përfundon mirë. Një nga klientët tanë përdor Azure ML, një zgjidhje shumë të lirë dhe të thjeshtë. Rreth 30% e pyetjeve atyre i përgjigjej vetë makina e vetë-mësuar. Dhe këtë e shkruajnë operatorë që nuk kishin bërë data science, statistikë ose matematikë. Kjo është shumë domethënëse. Kostoja e një zgjidhjeje të tillë është minimale.

4. Collab drejtimet: Hacks për bashkëpunim

Arketipi i katërt ka të bëjë me nevojën për të luftuar izolimin. Shumica e njerëzve tashmë e dinë këtë: izolimi krijon armiqësi. Nëse çdo departament ndodhet në katin e tij, dhe njerëzit nuk kanë ndonjë lidhje me njëri-tjetrin përveçse në ashensor, armiqësia mes tyre lind shumë lehtë. Por, nëse përkundrazi, njerëzit ndodhen në të njëjtin ambient, ajo zhduket menjëherë. Kur dikush hedh një akuzë të përbashkët, për shembull, në këtë ndërfaqe nuk funksionon kurrë — nuk ka asgjë më të lehtë se sa të dekonstruosh një akuzë të tillë. Programuesve që kanë shkruar ndërfaqen, mjafton të fillojnë të bëjnë pyetje konkrete, dhe shumë shpejt do të zbulohet se, për shembull, përdoruesi thjesht e ka përdorur gabim mjetin.

Ka shumë mënyra për të tejkaluar izolimin. Njëherë më kërkuan të konsultoja një bankë në Australi, por refuzova ta bëj, sepse kam dy fëmijë dhe një grua. E vetmja gjë që mund t'u ndihmoja ishte t’u rekomandoja storytelling grafik. Kjo është diçka që provokohet të funksionojë. Një mënyrë tjetër interesante është takimet në formatin lean coffee. Në një organizatë të madhe, kjo është një mundësi e shkëlqyer për shpërndarjen e njohurive. Për më tepër, mund të organizoni devopsdays të brendshme, hackathon-e dhe të tjera.

5. Coaching Kata

Siç e kam paralajmëruar në fillim, sot nuk do ta diskutoj këtë. Nëse jeni të interesuar, mund të shihni disa nga prezantimet e mia.

Ka gjithashtu një raport të mirë mbi këtë temë nga Mike Rother:

6. Market Oriented: organizatë e orientuar ndaj tregut

Këtu ka probleme të ndryshme. Për shembull, njerëzit 'I', njerëzit 'T' dhe njerëzit 'E'. Njerëzit 'I' janë ata që merrem vetëm me një gjë. Zakonisht they ekzistojnë në organizatat me njësi të izoluara. 'T' do të thotë që një person di shumë për një temë të vetme, por gjithashtu është i suksesshëm në disa gjëra të tjera. 'E' ose madje 'gërshërë' është kur një person ka shumë aftësi.

Këtu funksionon ligji i Conway (Conway’s law), e cila mund të përshkruhet në një mënyrë maksimalisht të thjeshtuar: nëse tri ekipe merren me kompilatorin, përfundimisht do të krijohet një kompilator prej tre pjesësh. Pra, nëse brenda organizatës ka një nivel të lartë izolimi, atëherë edhe Kubernetes, Circuit breaker, API extensibility dhe gjëra të tjera të modës në këtë organizatë do të jenë të organizuara ashtu si vetë organizata. Strikhtësisht sipas Conway dhe në kundërshtim me ju, të rinjtë geek.

Zgjidhja e këtij problemi është përshkruar shumë herë. Ka, për shembull, arketipe organizative të përshkruara nga Fernando Fernandez. Arkitektura problematike, për të cilën sapo flisja, me izolim — është një arkitekturë funksionale. Lloji i dytë — më i keqi, është arkitektura matricore, aty është një kaos nga dy të tjera. Tretë — është ajo që vërehet në shumicën e startup-eve, dhe kompanitë e mëdha gjithashtu përpiqen të përputhen me këtë lloj. Kjo është një organizatë e orientuar nga tregu. Këtu bëhet optimizimi për të arritur një përgjigje sa më të shpejtë ndaj kërkesave të klientëve. Nd sometimes quhet organizatë e sheshtë.

Struktura e kësaj shumë është përshkruar ndryshe nga shumë njerëz, më pëlqen formulimi build/run teams, në Amazon e quajnë dy dy ekipet e pizzës. Në këtë strukturë, të gjithë njerëzit e tipit «I» grupohen rreth një shërbimi, dhe gradualisht ata bëhen më afër tipit «T», dhe nëse menaxhimi është i duhur, ata mund të bëhen madje «E». Kundërargumenti i parë këtu është se në një strukturë të tillë ka elementë të panevojshëm. Pse nevojitet një testues në çdo departament, nëse mund të kemi një departament të posaçëm për testuesit? Për këtë, unë përgjigjem: shpenzimet e panevojshme në këtë rast janë çmimi që na duhet të paguajmë, për që në të ardhmen e gjithë organizata të bëhet tip «E». Në një strukturë të tillë, testuesi gradualisht mëson rreth rrjeteve, arkitekturës, projektimit, etj. Në përfundim, çdo pjesëmarrës i organizatës është plotësisht i informuar rreth gjithçkaje që ndodh në organizatë. Nëse dëshironi të dini se si funksionon kjo skemë në industri, lexoni Mike Rother, Toyota Kata.

7. Auditorët shift-left: auditimi në etapat e hershme të ciklit. Respektimi i rregullave të sigurisë në mënyrë të dukshme

Kjo ndodh kur veprimet tuaja nuk kalojnë, për ta thënë ndryshe, provimin e erës. Njerëzit që punojnë për ju nuk janë të paditur. Nëse ata, siç përmendet më lart, shpesh raportojnë ndikim të vogël/pa ndikim, kjo ka vazhduar për tre vjet, dhe askush nuk ka vënë re asgjë, atëherë të gjithë e dinë mirë që sistemi nuk funksionon. Ose një shembull tjetër — këshilli për ndryshime, ku çdo të mërkurë, duhet të dorëzohen raportet. Aty punon një grup njerëzish (të thoshim, jo shumë të paguar mirë), që teoretikisht duhet të dinë si funksionon sistemi në përgjithësi. Dhe gjatë pesë viteve të fundit, ndoshta keni vënë re se sistemet tona janë jashtëzakonisht të komplikuara. Dhe pesë deri në gjashtë njerëz duhet të marrin një vendim në lidhje me një ndryshim që ata nuk e kanë bërë dhe për të cilin ata nuk dinë asgjë.

Sigurisht, një qasje e till nuk ndihmon. Unë duhet të heq dorë nga këto gjëra, sepse këta njerëz nuk e mbrojnë sistemin. Vendimi duhet të merret nga vetë ekipi, sepse ekipi duhet të jetë përgjegjës për të. Nëse ndryshe, ndodh një situatë paradoksale, ku menaxheri, i cili kurrë në jetën e tij nuk ka shkruar kod, i thotë programuesit se sa kohë duhet të marrë shkruarja e kodit. Në një kompani ku kam punuar, kishte 7 këshilla të ndryshme që shqyrtonin çdo ndryshim, përfshirë këshillin për arkitekturën, për produktet etj. Madje ekzistonte një periudhë e pritjes së obligueshme, megjithatë një punonjës më tha se për dhjetë vjet punë, askush kurrë nuk e kishte refuzuar ndryshimet e propozuara nga ai gjatë kësaj periudhe të obligueshme.

Auditorët duhet të ftohen te ju, e jo t'i largoni ata. Tregoni atyre se po shkruani kontejnerë binarë të pavarur, të cilët, nëse kalojnë të gjitha testet, mbeten të pandryshueshëm përgjithmonë. Tregoni atyre se keni pipeline as code dhe shpjegoni se çfarë do të thotë kjo. Tregoni atyre diagramin e mëposhtëm: binari i pavarur vetëm për lexim në një kontejner që kalon të gjitha testet për vulnerabilitetet; dhe më tej jo vetëm që askush nuk prek atë — as nuk prek as sistemi që krijon pipeline-in, sepse ai gjithashtu krijohet në mënyrë dinamike. Kam klientë, si Capital One, të cilët me ndihmën e Vault krijojnë një lloj blockchain-i. Auditorit nuk i nevojitet të tregoni "recetat" nga Chef, mjafton të tregoni blockchain-in, nga i cili është e qartë se çfarë ndodhi me tiketën Jira në prodhim dhe kush është përgjegjës për të.

Sipas raporti, i krijuar në vitin 2018 Sonatype, në vitin 2017 kishte 87 miliardë kërkesa për shkarkim OSS.

Dëmet që shkaktohen nga dobësitë ndonjëherë rezultojnë të jenë jashtëzakonisht të larta. Ndërkohë, shifrat që shihni tani nuk përfshijnë kostot alternative. Një përmbledhje e shkurtër mbi atë çfarë është DevSecOps. Dua ta nënvizoj që nuk më interesojnë diskutimet mbi sa bukur është ky emër. Kjo ka kuptim sepse, pasi DevOps ishin shumë të suksesshëm, duhet provuar të shtohet siguria në këtë pipeline.

Një shembull i tillë i sekuencës:

Kjo nuk është një rekomandim për produkte të caktuara, megjithëse të gjitha më pëlqejnë. I kam përmendur si shembuj për të treguar se si DevOps, të cilat janë bazuar në fillim në paradigmat e organizatës industriale, lejojnë automatizimin e çdo etape të punës mbi produktin.

Dhe nuk ka asnjë arsye përse ne nuk mund të aplikojmë të njëjtin qasje për sigurinë.

Përfundimi

Në përfundim, do të jap disa këshilla për DevSecOps. Është e rëndësishme të përfshihen auditorët në procesin e krijimit të sistemeve tuaja dhe të investoni kohë në edukimin e tyre. Duhet të bashkëpunoni me auditorët. Më pas, duhet të luftoni pa mëshirë kundër sulmeve të rreme. Edhe me mjetet më të shtrenjta për skanimin e dobësive, mund të krijoni zakone të dëmshme te zhvilluesit tuaj nëse nuk e dini marrëdhënien mes sinjalit dhe zhurmës. Zhvilluesit do të ngarkohen me ngjarje dhe do të fillojnë t'i fshijnë ato. Nëse keni dëgjuar për historinë e Equifax, kjo ndodhi aty, ku u injorua sinjali më i lartë i rrezikut. Për më tepër, duhet të shpjegoni dobësitë në mënyrë që të jetë e qartë se si ato ndikojnë në biznes. Për shembull, mund të thoni se kjo është e njëjta dobësi si në historinë me Equifax. Dobësitë që lidhen me sigurinë duhet të trajtohen si çdo problem tjetër me softuerin, duke i përfshirë në procesin e përgjithshëm DevOps. Ato duhet të trajtohen përmes Jira, Kanban, etj. Zhvilluesit nuk duhet të mendojnë se dikush tjetër do ta bëjë atë — përkundrazi, duhet të angazhohen të gjithë. Përfundimisht, duhet të investoni energji në edukimin e njerëzve.