🥇Shtatë arketipe të transformimit sipas parimeve DevOps

Pyetja "si të implementoni DevOps" është e pranishme për një kohë të gjatë, por materialet e mira nuk janë kaq të shumta. Ndonjëherë bëheni viktimë e reklamat të konsultantëve jo shumë të zgjuar, të cilët duan të shesin kohën e tyre, pa rëndësi sesi. Ndonjëherë, ato janë fjalë që nuk kuptohen, tepër të përgjithshme, për mënyrën se si anijet e mega-korporatave lundrojnë në hapësirën e universit. Lind pyetja: dhe ne çfarë përfitimi kemi nga kjo? Autori i nderuar, a mund të formuloni idetë tuaja në mënyrë më të qartë në një listë?

E gjithë kjo ndodh për shkak se praktika e vërtetë dhe kuptimi i rezultateve të transformimeve kulturore të kompanive nuk janë akumuluar shumë. Ndryshimet në kulturë janë gjëra afatgjata, rezultatet e të cilave nuk do të shfaqen brenda një jave ose një muaji. Na nevojitet dikush mjaft i moshuar, që ka parë se si janë krijuar dhe shkatërruar kompanitë për një periudhë të gjatë.

John Willis është një nga baballarët e DevOps. Pas tij qëndrojnë dhjetëra vite pune me një numër të madh kompanish. Kohët e fundit, John ka filluar të vë re disa modele specifike, të cilat janë të pranishme në punën me secilën prej tyre. Duke përdorur këto arketipe, John udhëzon kompanitë në rrugën e vërtetë të transformimit DevOps. Më shumë rreth këtyre arketipeve - në përkthimin e fjalimit të tij nga konferenca DevOops 2018.

Rreth folësit:

Më shumë se 35 vjet në menaxhimin e IT-së, ka marrë pjesë në krijimin e pararendësit të OpenCloud në Canonical, ka kontribuar në 10 startup-e, dy prej të cilave i ka shitur Dell dhe Docker. Aktualisht është Nënpresident i Praktikave DevOps dhe Digitale në SJ Technologies.

Më pas - një narracion nga perspektiva e John.

Më quajnë John Willis, dhe më lehtë është të më gjeni në Twitter, @botchagalupe. I njëjti pseudonim më përket edhe në Gmail dhe GitHub. Ndërsa në këtë lidhje mund të gjeni video regjistrimet e fjalimeve dhe prezantimeve të mia.

Kam kam shumë takime me CIO-të e kompanive të mëdha. Ata shpesh ankohet se nuk kuptojnë se çfarë është DevOps, dhe të gjithë ata që përpiqen ta shpjegojnë këtë flasin për diçka të tyre. Një ankesë tjetër e zakonshme është që DevOps nuk funksionon, megjithëse drejtorët duket se bëjnë gjithçka ashtu siç iu është shpjeguar. Bëhet fjalë për kompani të mëdha që kanë mbi njëqind vjet histori. Pas bisedave me ta, arrita në përfundimin se për shumë probleme, zgjidhjet më të mirë janë ato me teknologji më 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ëve pune.

Çfarë është DevOps?

Vërtet, nëse pyet 10 persona të ndryshëm, ata do të japin 10 përgjigje të ndryshme. Por ja, çfarë është interesante: të gjitha këto dhjetë përgjigje do të jenë të sakta. Nuk ka asnjë përgjigje të gabuar këtu. Kam punuar thellësisht me DevOps për rreth 10 vjet, isha amerikan i parë në DevOpsDay të parë. Nuk do të thosha që jam më i zgjuar se të gjithë ata që merren me DevOps, por me siguri nuk ka askush tjetër që të ketë shpenzuar kaq shumë energji për këtë. Unë mendoj se DevOps ndodh kur bashkohen kapitali njerëzor dhe teknologjia. Shpesh harrojmë dimensionin njerëzor, megjithëse flasim shumë për lloje të ndryshme kulturash.

Tanime kemi shumë të dhëna, pesë vjet hulumtime akademike, dhe teoritë e verifikuara në shkallë industriale. Këto hulumtime na tregojnë se nëse në kulturën organizative bashkohen disa modele të sjelljes, mund të arrijmë një përshpejtim deri në 2000 herë. Ky përshpejtim përputhet me një përmirësim të ngjashëm në qëndrueshmëri. Ky është një matje e saktë e atij avantazhi që DevOps mund t'i japë çdo kompanie. Para disa vitesh, i tregova për DevOps një CEO-je të një kompanie nga lista Fortune 5000. Kur po përgatitesha për prezantimin, isha shumë nervoz, sepse më duhej të përmbledhja përvojën time shumëvjeçare në 5 minuta.

Në fund i dha këtë definim për DevOps: është një set praktikash dhe modelet që lejojnë transformimin e kapitalit njerëzor në kapital organizativ me performancë të lartë. Një shembull është mënyra se si Toyota ka funksionuar gjatë 50 apo 60 viteve të fundit.

(Këtu dhe më tej, 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ë, mund të shikohet veçmas figura dhe të zmadhohet) (në këtë lidhje.)

Një nga praktikat më të suksesshme të tilla është hartimi i vlerës së fluksit. Për këtë janë shkruar disa libra të mirë, autori i atyre më të suksesshme është Karen Martin. Por gjatë vitit të fundit kam arritur në përfundimin se ky qasje është tepër teknologjike. Pa dyshim, ajo ka shumë virtyte dhe unë e kam përdorur shpesh. Por kur CEO-ja të pyet arsyen pse kompanitë e tij nuk mund ta ndërronin drejtimin, është ende herët të flasim për hartimin e vlerës së fluksit. Ka shumë pyetje shumë më thelbësore, për të cilat duhet të gjejmë përgjigje paraprakisht.

Më duket se gabimi i shumë kolegëve të mi është se thjesht u japin kompanive një udhëzues me pesë pika dhe më pas kthehen pas gjashtë muajsh për të parë se çfarë ka ndodhur. Edhe një skemë e mirë siç është hartimi i vlerës së fluksit ka, për të thënë ndryshe, zona të verbra (blind spots). Pas qindra intervistave me drejtorë të kompanive të ndryshme kam zhvilluar një model të caktuar që lejon të ndaj problemin në përbërës dhe tani do të diskutojmë rendin për çdo përbërës të këtyre. Para se të aplikoj ndonjë zgjidhje teknologjike, unë përdor këtë model dhe përfundimisht muret e mia përfundojnë të mbushura me skema. Së fundmi kam punuar me një fond të përbashkët dhe përfundimisht kam pasur 100-150 të tilla skema.

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

Mesazhi kryesor është: asnjë Lean, Agile, SAFE dhe DevOps nuk do të ndihmojnë nëse kultura e vetë organizatës është e keqe. Është si të zhytesh në thellësi pa akuafangu ose të operosh pa një foto me rëntgen. Me fjalë të tjera, duke përcjellë Druckerin dhe Demingun: kultura e organizatës së keqe do të konsumojë çdo sistem të mirë dhe nuk do të rrijë pa frymë.

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

Bëni të gjitha punët të dukshme: duhet të bëni të gjithë punën të dukshme. Jo në kuptimin që ajo duhet patjeter të shfaqet në ndonjë ekran, por në kuptim që ajo duhet të jetë e vëzhgueshme.
Konsolidoni sistemet e menaxhimit të punës: është e nevojshme të konsolidohen sistemet e menaxhimit. Në çështjen e njohurive "fise" dhe njohurive institucionale, në 9 raste nga 10 ngushtica janë njerëzit. Në libër «Phoenix Project» problemi ishte një person i vetëm, Brenti, për shkak të së cilit projekti u vonua për tri vjet. Dhe për këtë lloj "Brenti" haset në çdo vend. Për zgjidhjen e këtyre ngushticave unë përdor dy pikat e mëposhtme në listën tonë.
Metodologjia e Teorisë së Kufizimeve: teoria e kufizimeve.
Hakat e bashkëpunimit: hakat e bashkëpunimit.
Toyota Kata (Coaching Kata): në lidhje me Toyota Kata nuk do flas shumë. Nëse je i interesuar, në GitHub-in tim ka prezantime për pothuajse çdo një nga këto tema.
Organizata e Orientuar në Treg: organizata e orientuar në treg.
Auditorët shift-left: auditi në faza të hershme të ciklit.

Filloj punën me organizatën me një mënyrë shumë të thjeshtë: shkoj në kompaninë dhe bisedoj me punonjësit. Siç e shohim, nuk ka teknologji të larta. E gjithë që është e nevojshme është që të kem diçka për të shkruar. Unë mbledh disa ekipe në një dhomë dhe analizoj atë që më thonë, nga këndvështrimi i 7 arketipeve të mi. Pastaj u jap atyre një marker dhe kërkoj që të shkruajnë në tablonë e bardhë gjithçka që deri më tani kanë thënë me zë të lartë. Zakonisht në takime të tilla ka një person që gjithmonë shënon, dhe në rastin më të mirë ai arrin të regjistrojë 10% të diskutimit. Me metodën time ky tregues arrin të rritet deri diku 40%.

(Pjesërisht këtë ilustrafikë mund ta shikoni në lidhje)

Qasja ime bazohet në punën e William Schneider (William Schneider, The Reengineering Alternative). Në thelb, ky qasje ka idenë se çdo organizatë mund të ndahet në katër katrorë. Kjo skemë zakonisht është rezultati i punës me ato qindra skema të tjera që ndodhin 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. Kjo është një variant jashtëzakonisht e padëshiruar: kur të gjithë përshkohen rreptësisht, por askush nuk e di se çfarë duhet të bëjë.

Një variant disi më i mirë me një nivel të lartë të kontrollit dhe kompetencës. Nëse një kompani ka fitim, ndoshta DevOps 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 me një nivel të lartë kulture (cultivation). Kjo do të thotë që në kompani ka shumë njerëz që e pëlqejnë atë punë, dhe fluksi i punonjësve është i ulët.

(Pjesërisht këtë ilustrafikë mund ta shikoni në lidhje)

Më duket se metodat me rekomandime strikte përfundimisht pengojnë arritjen e së vërtetës. Në veçanti, në mapimin e vlerës, ka shumë rregulla në lidhje me mënyrën se si duhet të strukturohet informacioni. Në fazat e hershme të punës, për të cilat po flas tani, këto rregulla nuk i duhen askujt. Nëse një person me një marker në dorë përshkruan në një tabelë situatën reale në kompani — ky është mënyra më e mirë për të kuptuar gjendjen. Ky informacion nuk i arrin drejtorët. Në atë moment është e trashë të ndërpresësh dikë dhe të thuash se ka vizatuar gabim ndonjë стрелка. 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 markera me ngjyra.

Po e përsëris, asnjë teknologji e avancuar. Realiteti objektiv përshkruhet me një marker të zi, si funksionon gjithçka. Me marker të kuq, njerëzit shënojnë se çfarë nuk u pëlqen atyre në situatën ekzistuese. Është e rëndësishme që ata ta shkruajnë këtë, e jo unë. Kur pas mbledhjes shkoj te drejtori për teknologjitë informative, unë nuk ofroj një listë prej 10 gjërash që duhen rregulluar. Kam si synim të gjej lidhje midis asaj që thonë njerëzit nga kompania dhe modeleve ekzistuese të verifikuara. Së fundmi, me marker të blerë propozohen zgjidhje të mundshme për problemin.

(Pjesërisht këtë ilustrafikë mund ta shikoni në lidhje)

Një shembull i këtij qasja tani është përshkruar më sipër. Në fillim të këtij viti kam punuar me një bankë. Punonjësit nga departamenti i sigurisë ishin të bindur se nuk duhej të merrnin pjesë në rishikimin e kërkesave dhe të dizajnit (design and requirement reviews).

(Pjesërisht këtë ilustrafikë mund ta shikoni në lidhje)

Pastaj folëm me njerëz nga departamento të tjera dhe zbuluam se diku 8 vjet më parë, zhvilluesit e softuerit i kishin nxjerrë punonjësit e sigurisë, sepse ata ngadalësonin punën. Pastaj kjo u shndërrua në një ndalim që perceptohej si një e vërtetë e padiskutueshme. Megjithatë, në të vërtetë, nuk kishte ndalim.

Takimi takimi përpjekjeve janë shkuar, kompleksiteti na dha një pamje të qartë: për rreth tri orë, pesë ekipe të ndryshme nuk mundën të më shpjegonin se çfarë ndodhte midis kodit dhe ndërtimit. Dhe kjo përkthehet në diçka që do të dukej më e thjeshtë. Shumica e konsulentëve DevOps supozojnë paraprakisht se kjo ka kaluar tashmë në njohuri të zakonshme.

Më pas, njeriu që ishte përgjegjës për rregullimin e IT (IT governance), i cili kishte heshtur për katër orë, papritur u gjallërua kur arritëm në temën e tij dhe na zuri edhe për një periudhë të gjatë. Në fund, e pyeta se çfarë mendonte për takim dhe kurrë nuk do ta harroj përgjigjen e tij. Ai tha: «Më parë mendoja se ne në bankën tonë kishim vetëm dy metoda për zhvillimin e softuerit, por tani e di se janë pesë, dhe për tri nuk e dija fare».

(Pjesërisht këtë ilustrafikë mund ta shikoni në lidhje)

Takimi i fundit në këtë bankë ishte me ekipin që punonte me softuer për investime. Saktësisht me ta u kuptua se është më mirë të shkruajmë skemat me marker në një letër sesa në një tablo, madje më mirë sesa në një smartboard.

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

Pra, po bëj pyetje për punonjësit, ata i shkruajnë përgjigjet me markera të tre ngjyrave (të zeza, të kuqe dhe blu). Unë i analizoj përgjigjet për arketipet. Tani le të diskutojmë të gjitha arketipet sipas rendit.

1. Make All Work Visible: Bëni të gjithë punën të dukshme

Në shumicën e kompanive me të cilat punoj, ka një përqindje shumë të lartë të punës së panjohur. P.sh., kur një punonjës i kërkon një tjetri 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 aspak. Nëse do të ishte Boeing, nuk do të flija ndonjëherë më në ndonjë avion të tyre. Nëse vetëm gjysma e punës dokumentohet, nuk dihet nëse kjo punë përfundon siç duhet apo jo. Të gjithë metodat e tjera rezultojnë të jenë të padobishme - nuk ka asnjë kuptim të përpiqemi të automatizojmë ndonjë gjë, sepse 50% e njohura mund të jenë pjesa më e organizuar dhe e qartë e punës, automatizimi i së cilës nuk do të japë rezultate të mëdha, ndërsa më e këqija do të ndodhet në gjysmën e padukshme. Pa dokumentim është e pamundur të gjejmë çdo lloj haku dhe punë të fshehur, nuk mund të gjejmë ngushticat, ato «Making Work Visible». Ajo identifikon pesë "rrjedhjet e kohës" (thieves of time):

Too Much Work in Process (WIP)
Unknown Dependencies
Unplanned Work
Conflicting priorities
Neglected Work

Ky është një analizë shumë e vlefshme, dhe libri është i shkëlqyer, por të gjitha këto këshilla janë të padobishme nëse vetëm 50% e të dhënave janë të dukshme. Të aplikosh metodat e propozuara nga Dominica ka kuptim vetëm në rast se arrihet saktësia e mbi 90%. Po flas për situata ku një shef i jep një nënshënie një detyrë 15-minutëshe, por ajo merr tre ditë; por shefi në të vërtetë nuk e di se ky nënshënie varet nga katër ose pesë njerëz të tjerë.

Phoenix Project — është një tregim i mrekullueshëm për një projekt që u vonua tre vjet. Njëri prej heronjve rrezikon të humbasë punën për shkak të kësaj, dhe ai takohet me një karakter tjetër, i cili paraqitet si një lloj Sokrati. Ai ndihmon për të kuptuar se çfarë ka shkkuar keq. Rrëfehet se në kompani ka një administrator sistemi, i quajtur Brent, dhe puna kalon në çfarëdo forme përmes tij. Në një nga takimet, një nga nënshtruarit pyet: pse çdo detyrë gjysmëore merr një javë? Në përgjigje, jepet një përmbledhje shumë e thjeshtë e teorisë së radhëve dhe ligjit të Little, dhe në këtë përmbledhje tregohet se me një ngarkesë 90%, çdo orë pune zgjat 9 orë. Çdo detyrë duhet t'i dërgohet shtatë personave të tjerë, kështu që kjo orë kthehet në 63 orë, 7 herë 9. Po e them këtë për të shpjeguar se për të përdorur ligjin e Little ose ndonjë teori më të komplikuar të radhëve, është e nevojshme të kesh të paktën të dhëna.

Prandaj, kur flas për dukshmërinë, nuk kam parasysh që gjithçka të jetë në ekran, por është e nevojshme të kesh të paktën të dhëna. Kur ato janë të pranishme, shpesh zbulohet se ka një volum të madh pune të paparashikuar, e cila për ndonjë arsye dërgohet tek Brent, ndonëse nuk ka asnjë nevojë për këtë. Dhe Brent është një djalë i shkëlqyer, ai kurrë nuk do të thotë 'jo', por ai asnjëherë nuk u thotë të tjerëve se si e bën punën e tij.

Kur puna është e dukshme, është e mundur të klasifikosh të dhënat me kujdes (pikërisht këtë Dominika bën në foto), është e mundur të zbatosh abstraksionin e pesë rrjedhjeve të kohës dhe të automatizosh.

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

Arketipet që po flas për to, përbëjnë një lloj piramide. Nëse e para është kryer siç duhet, atëherë e dyta është një lloj ndërtese e sipërme. Shumë prej tyre nuk funksionojnë për startup-et, duhet t'i ki parasysh në rastin e kompanive të mëdha, si ato që shfaqen në listën Fortune 5000. Në kompaninë e fundit ku kam punuar, kishte 10 sisteme për ndjekjen e gabimeve (sistemi i biletave). Një ekip kishte Remedy, ekipi tjetër kishte shkruar një sistem të vetin, ekipi i tretë përdorte Jira, ndonjë prej tyre madje e kalonte me postë elektronike. E njëjta problematikë krijohet nëse kompania ka 30 pipeline të ndryshme, por nuk kam kohë të diskutoj për të gjitha këto raste.

Unë diskutoj me njerëzit se si krijohen biletat, çfarë ndodh më vonë me to dhe si i shmangen ato. E veçanta është se njerëzit në takimet tona flasin mjaft sinqerisht. E putha, sa njerëz damkosen "minor / no impact" për biletat që realisht do të duhej t'i jepnin "major impact". Doli se kështu veprojnë gati të gjithë. Unë nuk merrem me përcjellje dhe përpiqem të mos zbuloj njerëzit. Kur më pranojnë diçka me të vërtetë ngurruese, nuk e zbuloj personin. Por kur pothuajse të gjithë e shmangin sistemin, kjo do të thotë se tërë siguria, në thelb, është një dekor. Prandaj, nuk mund të bëhen asnjë përfundim 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. Çështja është se biletat duhet të merren si një tjetër fazë e procesit të zhvillimit. Çdo veprim duhet të ketë një biletë, e cila duhet të kalojë nëpër procesin e zhvillimit. Biletat dërgohen ekipit që i nxjerr ata në storyboard, dhe më pas merr përgjegjësinë për ta.

Kjo i përket të gjitha departamenteve, përfshirë infrastrukturën dhe operacionet. Në këtë rast, është e mundur të bëhet një paraqitje sa më të besueshme të situatës. Kur ky proces është i vendosur, papritmas del se mund të përcaktohet lehtësisht se kush është përgjegjës për çdo aplikacion. Sepse tani marrim jo 50%, por 98% të shërbimeve të reja. Nëse ky proces themelor funksionon, saktësia rritet në të gjithë sistemin.

Pipeline i shërbimeve

Kjo përsëri i përket 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 i spikatur është ai që ndodhi me bankën ku kam punuar. Ata u ngjitën nga Google dhe iu treguan grafikët me sistemet e vjetra IBM. Djemtë e Google pyesnin me habi — ku është kodin burimor për këtë? Nuk ka asnjë kod burimor, as GUI. Kjo është realiteti me të cilin përballen organizatat e mëdha: 40 vjetët e të dhënave bankare në një mainframe të vjetër. Një nga klientët e mi përdor kontejnerë Kubernetes me modelet Circuit Breaker, plus Chaos Monkey, dhe e gjithë kjo për aplikacionin KeyBank. Por këta kontejnerë lidhin përfundimisht me një aplikacion në COBOL.

Djemtë e Google ishin të bindur se do të zgjidhnin të gjitha problemet e klientit tim, por pastaj filluan të bëjnë pyetje: çfarë është IBM datapipe? U përgjigjen: ky është një konektor. Për çfarë lidhet? Me sistemin Sperry. Dhe kjo çfarë është? Dhe kështu me radhë. Në pamje të parë duket se: çfarë DevOps mund të ketë këtu? Por më të vërtetë, është e mundur. Ekzistojnë sisteme të shpërndarjes që lejojnë kalimin e procesit të punës në ekipet që merret me shpërndarjen.

3. Teoria e Kufizimeve: Teoria e kufizimeve

Le të kalojmë në arketipin e tretë: njohuri institucionale / "tribale". Në përgjithësi, në çdo organizatë ka disa njerëz që e dinë gjithçka dhe udhëheqin të gjithëve. Këta janë ata që janë më gjatë në organizatë dhe që dinë të gjitha rrugët e kaluara.

Kur kjo zbulohet në diagram, unë veçanërisht e veçoj këta njerëz me një theksues: për shembull, zbulon se një njeri si Lu merr pjesë në të gjitha takimet. Dhe për mua është e qartë: ky është vendi i famshëm. Kur drejtori i informacionit zgjidh midis meje në një majë dhe atlete dhe një djali të veshur me kostum nga IBM, më zgjedhin mua sepse mund t'i tregoj drejtorit për gjëra që ai, ai djalë tjetër, nuk do t'i tregojë dhe që drejtorit mund të mos i pëlqejnë të dëgjojë. Unë u tregoj atyre se në kompaninë e tyre ka një ngushticë, është një njeri me emrin Fred dhe një tjetër me emrin Lu. Kjo ngushticë duhet zgjidhur, njohuria e tyre duhet si ndonjëherë të merret prej tyre.

Për t'u përballur me një problem të tillë, mund, për shembull, të propozoj përdorimin e Slack. Një drejtor i zgjuar do të pyesë — përse? Zakonisht në raste të tilla, këshilltarët e DevOps përgjigjen: sepse të gjithë e bëjnë kështu. Nëse drejtorit do t’i thoshte se është i zgjuar, do të thoshte: dhe çfarë? Dhe dialogu do të përfundonte aty. Ndërsa unë do të përgjigjem: sepse në kompani ka katër ngushtica, Fred, Lu, Suzi dhe Jane. Për ta institucionalizuar njohurinë e tyre, së pari duhet të prezantojmë Slack. Të gjitha wiki-t tuaja janë një gjë totale, sepse askush nuk di për ekzistencën e tyre. Nëse ekipi i inxhinierëve merret me zhvillimin e brendshëm dhe të jashtëm dhe të gjithë duhet të dinë se mund të drejtohen në ekipin e zhvillimit të jashtëm ose te ekipi i infrastrukturës me pyetje. Vetëm atëherë, ndoshta Lu ose Fred do të kenë kohë për t'u lidhur me wiki-n. Pastaj në Slack dikush mund të pyesë pse një hap, le të themi, hapi 5, nuk funksionon. Dhe atëherë Lu ose Fred do të korrigjojnë udhëzimin në wiki. Nëse e vendosim këtë proces, shumë gjëra do të vendosen vetë pas kësaj.

Këtu është mendimi im kryesor: për të rekomanduar disa teknologji të avancuara, së pari duhet të organizojmë themelin për to, dhe kjo mund të bëhet me zgjidhjet e teknologjisë së ulët që sapo përmendëm. Nëse filloni me teknologjitë e avancuara dhe nuk shpjegoni përse janë të nevojshme, zakonisht kjo nuk përfundon mirë. Një nga klientët tanë përdor Azure ML, një zgjidhje shumë të lirë dhe të thjeshtë. Diku, rreth 30% e pyetjeve u përgjigjen nga vetë makina e vetë-mësimit. Dhe këtë e shkruan operatorë që nuk merreshin me data science, statistikë ose matematikë. Kjo është treguese. Kostoja e një zgjidhjeje të tillë është minimale.

4. Haket e bashkëpunimit: Hacks për bashkëpunim

Arketipi i katërt është se është e nevojshme të luftohet me izolimin. Pjesa më e madhe e njerëzve tashmë e dinë këtë: izolimi krijon armiqësi. Nëse çdo departament është në katin e vet, dhe njerëzit nuk kanë asnjë kontakt me njëri-tjetrin përveçse në ashensor, armiqësia midis tyre lind shumë lehtë. Nëse, përkundrazi, njerëzit ndodhen në të njëjtin dhomë, ajo largohet menjëherë. Kur dikush bën një akuzë të përgjithshme, për shembull, një ndërfaqe e tillë kurrë nuk funksionon - nuk ka asgjë më të lehtë se sa ta dekonstruktojmë atë akuzë. Programuesve që e kanë shkruar ndërfaqen, mjafton të fillojnë të bëjnë pyetje konkrete, dhe 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, unë e refuzova këtë, sepse kam dy f Children dhe një grua. Gjithçka që mund të ndihmoja ishte të rekomandoja storytelling grafik. Kjo është diçka që provon se funksionon. Një mënyrë tjetër interesante janë takimet në formatin lean coffee. Në një organizatë të madhe, kjo është një mundësi e shkëlqyer për shpërndarjen e dijes. Për më tepër, mund të organizohen devopsdays të brendshme, hackathone e kështu me radhë.

5. Coaching Kata

Siç e paralajmërova në fillim, sot nuk do të flas për këtë. Nëse jeni të interesuar, mund të shihni disa nga prezantimet e mia.

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

6. Market Oriented: organizatë e orientuar drejt tregut

Këtu janë disa probleme të ndryshme. Për shembull, njerëz "I", njerëz "T" dhe njerëz "E". Njerëzit "I" janë ata që merren vetëm me një gjë. Zakonisht ata ekzistojnë pikërisht në organizatat me njësi të izoluar. "T" është nëse një person e njeh mirë diçka të vetme, por gjithashtu i shkon mirë edhe në disa gjëra të tjera. "E" ose madje "ghega" është kur një njeri ka shumë aftësi.

Këtu vepron ligji i Conway-it (Conway’s law), i cili në formën e tij më të thjeshtë mund të përmblidhet kështu: nëse tre ekipe merren me një kompilator, në fund do të dalë një kompilator me tre pjesë. Prandaj, nëse brenda organizatës ka një nivel të lartë izolimi, madje edhe Kubernetes, Circuit breaker, API extensibility dhe gjëra të tjera moderne në këtë organizatë do të krijohen ashtu si organizata vetë. Saktësisht sipas Conway-it dhe për t'i bërë nënkuptim të gjithëve ju, të rinjtë geek.

Kjo çështje është përshkruar shumë herë. Ka, për shembull, arketipet organizative të përshkruara nga Fernando Fernandez. Arkitektura problematike, për të cilën flisja pak më parë, me izolimin — është një arkitekturë funksionale. Lloji i dytë — më i keqi, arkitektura matricore, është një përzierje e dy llojeve të tjera. Të tretin — e shohim në shumicën e startupeve, dhe kompanitë e mëdha gjithashtu përpiqen t'i përmbahen këtij lloji. Ky është një organizim i orientuar nga tregu. Këtu bëhet optimizimi për të arritur përgjigjen më të shpejtë ndaj kërkesave të klientëve. Ndonjëherë këtë e quajnë organizatë të sheshtë.

Strukturën e tillë shumëkush e përshkruan ndryshe, mua më pëlqen formulimi teams build/run, në Amazon e quajnë ekipet dy pizzave. Në këtë strukturë, të gjithë njerëzit e tipit «I» grumbullohen rreth një shërbimi, dhe gradualisht ata e përmirësojnë veten në tipin «T», dhe nëse menaxhmenti është i duhur, mund të bëhen madje edhe «E». Argumenti i parë kundër këtu — në një strukturë të tillë ka elemente të tepërta. Pse është e nevojshme të ketë një tester në çdo degë, nëse mund të kemi një departament të veçantë testimi? Për të cilin unë përgjigjem: shpenzimet e tepërta në këtë rast janë çmimi për të bërë që në të ardhmen gjithë organizata të bëhet tip «E». Në një strukturë të tillë, testeri gradualisht mëson për rrjetat, arkitekturën, dizajnimin etj. Në fund, çdo pjesëmarrës në organizatë është plotësisht i informuar për gjithçka që ndodh në organizatë. Nëse dëshironi të dini si funksionon kjo skemë në industri, lexoni Mike Rother, Toyota Kata.

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

Kjo është kur veprimet tuaja nuk kalojnë, kështu të thuash, testin e erës. Njerëzit që punojnë për ju nuk janë të stupid. Nëse ata, si në shembullin e mësipërm, e shënuan gjithandej ndikim të vogël/nuk ka ndikim, kjo vazhdoi për tre vjet, dhe askush nuk vuri re asgjë, atëherë të gjithë e dinë mirë se sistemi nuk funksionon. Ose një shembull tjetër — këshillat për ndryshime, ku çdo të mërkurë, duhet të dorëzohen raporte. Atje punon një grup njerëzish (për të theksuar, jo shumë të paguar mirë), të cilët në teori duhet të dinë se si funksionon sistemi në tërësi. Dhe për pesë vitet e fundit, ndoshta e keni vënë re se sistemet tona janë jashtëzakonisht të komplikuara. Dhe pesë-gjashtë persona duhet të marrin një vendim mbi një ndryshim, që nuk e kanë bërë ata dhe për të cilin nuk dinë asgjë.

Sigurisht, një qasje e tillë nuk funksionon. Më duhet të heq dorë nga këto gjëra, sepse këta njerëz nuk mbrojnë sistemin. Vendimin duhet ta marrë ekipi vetë, sepse ekipi duhet të jetë përgjegjës për të. Përndryshe ndodhet një situatë paradoksale, kur menaxheri, i cili nuk ka shkruar kurrë kod, i thotë programuesit se sa kohë duhet të zgjasë shkruarja e kodit. Në një kompani, me të cilën kam punuar, kishte 7 këshilla të ndryshme, të cilat shqyrtonin çdo ndryshim, duke përfshirë këshillin për arkitekturën, për produktet e kështu me radhë. Ekzistonte madje një periudhë e detyruar pritjeje, përderisa një punonjës më tha se në dhjetë vjet punë, askush nuk e kishte refuzuar ndonjëherë ndonjë ndryshim të propozuar nga ai gjatë kësaj periudhe të detyruar.

Auditorët duhet të thirren te ju, jo të hiqen prej tyre. Tregoni atyre se po shkruani konteinerë binarë të pandryshueshëm, të cilët, nëse kalojnë të gjitha testet, mbeten të pandryshueshëm përgjithmonë. Tregoni atyre se keni pipeline as code, dhe shpjegoni çfarë do të thotë kjo. Tregoni atyre diagramin e mëposhtëm: binari i pandryshueshëm vetëm për lexim në një konteiner që kalon të gjitha testet për vulnerabilitete; dhe më tej, jo vetëm që askush nuk e prek atë — as nuk prek sistemi që krijon pipeline-in, pasi ai gjithashtu krijohet dinamikisht. Kam klientë, Capital One, të cilët me ndihmën e Vault krijojnë diçka si një blockchain. Auditorit nuk i nevojitet të tregoheni "recetat" nga Chef, mjafton të tregoni blockchain-in, nga i cili është e qartë se çfarë ndodhi me ticket-in Jira në prodhim dhe kush është përgjegjës për të.

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

Shpenzimet e pësuara për shkak të vulnerabiliteteve janë tepër të larta. Për më tepër, shifrat që po shihni tani lart, nuk përfshijnë kostot alternative. Në dy fjalë për atë çfarë është DevSecOps. Menjëherë dua të them se nuk më interesojnë bisedat mbi sa e suksesshme është kjo emër. Kuptimi është se, nëse DevOps ishin shumë të suksesshëm, është e nevojshme të provohet të shtohet siguria në këtë pipeline.

Një shembull i tillë i sekuencës:

Kjo nuk është një rekomandim i produkteve të caktuara, megjithëse të gjitha më pëlqejnë. I kam përmendur si shembuj për të treguar se DevOps, i cili fillimisht është bazuar në paradigmat e organizatave industriale, lejon automatizimin e çdo faze të punës mbi produktin.

Dhe nuk ka asnjë arsye për të cilën ne nuk mund ta aplikojmë qasjen e njëjtë për sigurinë.

Përfundimi

Si përfundim, do të jap disa këshilla për DevSecOps. Duhet të përfshini auditorët në procesin e krijimit të sistemeve tuaja, të shpenzoni kohë për edukimin e tyre. Duhet të bashkëpunoni me auditorët. Më pas, duhet të bëni një luftë të ashpër kundër alarmeve false. Edhe me mjetin më të shtrenjtë për skanimin e dobësive, mund të krijoni zakone të dëmshme te zhvilluesit tuaj, nëse nuk e dini se çfarë është raporti i sinjalit ndaj zhurmës. Zhvilluesit do të mbingarkohen me ngjarje dhe do të fillojnë thjesht t'i fshijnë ato. Nëse keni dëgjuar për historinë e Equifax, atje ndodhi diçka e tillë, sinjali më i lartë i rrezikut u injorua. Përveç kësaj, dobësitë duhet të shpjegohen në mënyrë që të jetë e qartë se si ndikohet biznesi. P.sh., mund të thoni se kjo është e njëjta dobësi si në historinë me Equifax. Dobësitë që lidhen me sigurinë duhet të shqyrtohen po ashtu si çështje të tjera softuerike, pra ato duhet të përfshihen në procesin e përgjithshëm të DevOps. Duhet të punoni me to përmes Jira, Kanban, etj. Zhvilluesit nuk duhet të mendojnë se dikush tjetër do të merret me këtë — përkundrazi, duhet të merren me to të gjithë. Së fundi, duhet të shpenzoni energjinë për të trajnuar njerëzit.