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, . I njëjti pseudonim më përket edhe në Gmail dhe GitHub. Ndërsa 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)
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 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 (): në lidhje me Toyota Kata nuk do flas shumë. Nëse je i interesuar, në GitHub-in tim 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 )
Qasja ime bazohet në punën e William Schneider (William Schneider, ). 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 )
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 )
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 )
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 )
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 . 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 .
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 (), 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 .
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 , 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.
Useful links
Këtu janë disa prezantime nga konferenca DevOops që mund t'ju duken të dobishme:
- Sergie Berdnikov, Artyom Kalichkin â Historia e suksesit, ose "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnik â DevOps nĂ« shkallĂ«: tragjedia greke nĂ« tri akte (, )
- AleksandĂ«r Titov, Kirill TolkachĂ«v â
- Timothy Lister â
Shikoni nĂ« DevOops 2020 MoskĂ« â atje ka gjithashtu shumĂ« gjĂ«ra interesante.
Burimi: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish