Pyetja "si të zbatohet devops" ekziston prej vitesh, por nuk ka shumë materiale të mira. Ndonjëherë ju bini viktimë e reklamave nga konsulentë jo shumë të zgjuar, të cilët duhet të shesin kohën e tyre, pavarësisht se si. Ndonjëherë këto janë fjalë të paqarta, jashtëzakonisht të përgjithshme për mënyrën se si anijet e megakorporatave lërojnë hapësirat e universit. Lind pyetja: çfarë rëndësie ka kjo për ne? I nderuar autor, a mund t'i formuloni qartë idetë tuaja në një listë?
E gjithë kjo buron nga fakti se nuk është grumbulluar shumë praktikë reale dhe kuptimi i rezultatit të transformimeve të kulturës së kompanisë. Ndryshimet në kulturë janë gjëra afatgjata, rezultatet e të cilave nuk do të shfaqen për një javë apo një muaj. Ne kemi nevojë për dikë mjaft të vjetër për të parë se si kompanitë janë ndërtuar dhe dështuar gjatë viteve.
John Willis - një nga baballarët e DevOps. John ka dekada përvojë pune me një numër të madh kompanish. Kohët e fundit, Gjoni filloi të vërejë modele specifike që ndodhin kur punoni me secilën prej tyre. Duke përdorur këto arketipe, John udhëzon kompanitë në rrugën e vërtetë të transformimit të DevOps. Lexoni më shumë rreth këtyre arketipave në përkthimin e raportit të tij nga konferenca DevOops 2018.
Rreth folësit:
Më shumë se 35 vjet në menaxhimin e IT-së, mori pjesë në krijimin e paraardhësit të OpenCloud në Canonical, mori pjesë në 10 startup, dy prej të cilave iu shitën Dell dhe Docker. Aktualisht ai është Zëvendës President i DevOps dhe praktikave dixhitale në SJ Technologies.
Më pas është historia nga këndvështrimi i Gjonit.
Emri im është John Willis dhe vendi më i lehtë për të më gjetur është në Twitter, . Unë kam të njëjtin pseudonim në Gmail dhe GitHub. A ju mund të gjeni regjistrime video të raporteve të mia dhe prezantime për to.
Kam shumë takime me CIO të kompanive të ndryshme të mëdha. Ata shumë shpesh ankohen se nuk e kuptojnë se çfarë është DevOps dhe të gjithë ata që përpiqen t'u shpjegojnë atë po flasin për diçka ndryshe. Një tjetër ankesë e zakonshme është se DevOps nuk funksionon, megjithëse duket se drejtorët po bëjnë gjithçka siç u është shpjeguar. Ne po flasim për kompani të mëdha që janë më shumë se njëqind vjet të vjetra. Pasi bisedova me ta, arrita në përfundimin se për shumë probleme, nuk është teknologjia e lartë ajo që është më e përshtatshme, por zgjidhjet relativisht të teknologjisë së ulët. Për javë të tëra kam folur vetëm me njerëz nga departamente të ndryshme. Ajo që shihni në foton e parë në postim është projekti im i fundit, kështu dukej dhoma pas tre ditësh punë.
Çfarë është DevOps?
Në të vërtetë, nëse pyet 10 njerëz të ndryshëm, ata do të japin 10 përgjigje të ndryshme. Por këtu është gjëja interesante: të dhjetë nga këto përgjigje do të jenë të sakta. Këtu nuk ka përgjigje të gabuar. Isha shumë thellë në DevOps, për rreth 10 vjet, dhe isha amerikani i parë në DevOpsDay të parë. Nuk do të them se jam më i zgjuar se të gjithë të përfshirë në DevOps, por vështirë se ka dikush që ka shpenzuar aq shumë përpjekje për të. Unë besoj se DevOps ndodh kur kapitali njerëzor dhe teknologjia bashkohen. Shpesh harrojmë dimensionin njerëzor, megjithëse flasim shumë për të gjitha llojet e kulturave.
Tani kemi shumë të dhëna, pesë vite kërkime akademike, testim të teorive në shkallë industriale. Ajo që na thonë këto studime është se nëse kombinoni disa modele të sjelljes në një kulturë organizative, mund të merrni një shpejtësi 2000 herë. Ky përshpejtim përputhet me një përmirësim të barabartë në stabilitet. Kjo është një matje sasiore e përfitimit që DevOps mund t'i sjellë çdo kompanie. Nja dy vjet më parë, po flisja për DevOps me CEO të një kompanie Fortune 5000. Kur po përgatitesha për prezantimin, isha shumë nervoz sepse duhej të përmbledhja vitet e mia të përvojës në 5 minuta.
Në fund dhashë sa vijon Përkufizimi i DevOps: Është një grup praktikash dhe modelesh që mundësojnë transformimin e kapitalit njerëzor në kapital organizativ me performancë të lartë. Një shembull është mënyra se si Toyota ka operuar për 50 ose 60 vitet e fundit.
(Në vijim, diagramet e tilla nuk ofrohen si material referimi, por si ilustrime. Përmbajtja e tyre do të ndryshojë për çdo kompani të re. Megjithatë, fotografia mund të shihet veçmas dhe të zmadhohet
Një nga praktikat më të suksesshme të tilla është Vlera e hartës lumë. Për këtë janë shkruar disa libra të mirë, ndër të cilët më të suksesshmit janë nga Karen Martin. Por gjatë vitit të kaluar, kam arritur në përfundimin se edhe kjo qasje është shumë e teknologjisë së lartë. Sigurisht që ka shumë përparësi dhe e kam përdorur shumë. Por kur CEO ju pyet pse kompania e tij nuk mund të kalojë në shina të reja, është shumë herët të flasim për hartën e rrjedhës së vlerës. Ka shumë pyetje shumë më thelbësore që së pari duhet të marrin përgjigje.
Unë mendoj se gabimi që bëjnë shumë nga kolegët e mi është se ata thjesht i japin kompanisë një udhëzues me pesë pika dhe pastaj kthehen gjashtë muaj më vonë dhe shohin se çfarë ndodhi. Edhe një skemë e mirë si harta e rrjedhës së vlerës ka, le të themi, pika të verbër. Pas qindra intervistave me drejtorë të kompanive të ndryshme, unë kam zhvilluar një model të caktuar që na lejon të zbërthejmë problemin në përbërësit e tij dhe tani do të diskutojmë secilin prej këtyre komponentëve me radhë. Para se të aplikoj ndonjë zgjidhje teknologjike, unë përdor këtë model, dhe si rezultat, të gjitha muret e mia janë të mbuluara me diagrame. Kohët e fundit punoja me një fond të përbashkët dhe përfundova me 100-150 skema të tilla.
Kultura e keqe ha qasje të mira për mëngjes
Ideja kryesore është kjo: asnjë sasi e Lean, Agile, SAFE dhe DevOps nuk do të ndihmojë nëse vetë kultura e organizatës është e keqe. Është si të zhytesh në thellësi pa pajisje skuba ose të operosh pa një rreze x. Me fjalë të tjera, për të parafrazuar Drucker dhe Deming: një kulturë e keqe organizative do të gëlltisë çdo sistem të mirë pa e mbytur atë.
Për të zgjidhur këtë problem kryesor, duhet të ndërmerrni hapat e mëposhtëm:
- Bëni të dukshme të gjitha punët: ju duhet ta bëni të dukshme të gjithë punën. Jo në kuptimin që duhet domosdoshmërisht të shfaqet në ndonjë ekran, por në kuptimin që duhet të jetë i vëzhgueshëm.
- Sistemet e konsoliduara të menaxhimit të punës: sistemet e menaxhimit duhet të konsolidohen. Në problemin e njohurive “fisnore” dhe njohurive institucionale, në 9 raste nga 10 pengesa janë njerëzit. Në libër problemi ishte me një person të vetëm, Brent, i cili bëri që projekti të ishte tre vjet prapa planit. Dhe ndeshem me këto "Brents" kudo. Për të zgjidhur këto pengesa, unë përdor dy artikujt e ardhshëm në listën tonë.
- Metodologjia e Teorisë së Kufizimeve: teoria e kufizimeve.
- Haketë e bashkëpunimit: hakimet e bashkëpunimit.
- Toyota Kata (): Nuk do të flas shumë për Toyota Kata. Nëse jeni të interesuar, në github tim pothuajse në secilën nga këto tema.
- Organizata e orientuar nga tregu: organizatë e orientuar nga tregu.
- Auditorët e zhvendosur majtas: auditimi në fazat e hershme të ciklit.
Unë filloj të punoj me një organizatë shumë thjesht: shkoj në kompani dhe flas me punonjësit. Siç mund ta shihni, nuk ka teknologji të lartë. Gjithçka që ju nevojitet është 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ë mia. Dhe pastaj u jap vetë një shënues dhe u kërkoj të shkruajnë në tabelë gjithçka që kanë thënë me zë të lartë deri më tani. Zakonisht në këto lloj takimesh ka një person që shkruan gjithçka dhe në rastin më të mirë mund të shkruajë 10% të diskutimit. Me metodën time, kjo shifër mund të rritet në rreth 40%.
(Ky ilustrim mund të shihet veçmas )
Qasja ime bazohet në punën e William Schneider. ). Qasja bazohet në idenë se çdo organizatë mund të ndahet në katër sheshe. Kjo skemë për mua është zakonisht rezultat i punës me ato qindra skema të tjera që lindin kur analizohet një organizatë. Supozoni se kemi një organizatë me një nivel të lartë kontrolli, por me kompetencë të ulët. Ky është një opsion jashtëzakonisht i padëshirueshëm: kur të gjithë janë duke ecur përpara, por askush nuk e di se çfarë të bëjë.
Një opsion pak më i mirë është ai me një nivel të lartë të kontrollit dhe kompetencës. Nëse një kompani e tillë është fitimprurëse, atëherë ndoshta nuk ka nevojë për DevOps. Është më interesante të punosh me një kompani që ka një nivel të lartë kontrolli, kompetencë dhe bashkëpunim të ulët, por në të njëjtën kohë një nivel të lartë kulture (kultivimi). Kjo do të thotë se kompania ka shumë njerëz që duan të punojnë atje dhe qarkullimi i fuqisë punëtore është i ulët.
(Ky ilustrim mund të shihet veçmas )
Më duket se metodat me udhëzime të ngurta përfundojnë duke penguar arritjen e së vërtetës. Në hartën e rrjedhës së vlerës në veçanti, 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ë cilën po flas tani, askush nuk ka nevojë për këto rregulla. Nëse një person me një shënues në duart e tij përshkruan situatën reale në kompani në bord, kjo është mënyra më e mirë për të kuptuar gjendjen e punëve. Një informacion i tillë nuk arrin tek drejtorët. Në këtë moment, është marrëzi të ndërpresësh personin dhe të thuash se ai tërhoqi një lloj shigjete gabimisht. Në këtë fazë, është më mirë të përdorni rregulla të thjeshta, për shembull: abstraksioni me shumë nivele mund të krijohet thjesht duke përdorur shënues me shumë ngjyra.
E përsëris, nuk ka teknologji të lartë. Shenja e zezë përshkruan realitetin objektiv se si funksionon gjithçka. Me një shënues të kuq, njerëzit shënojnë atë që nuk u pëlqen në lidhje me gjendjen aktuale të punëve. E rëndësishme është që ata ta shkruajnë këtë, jo unë. Kur shkoj në CIO pas një takimi, nuk ofroj një listë me 10 gjëra që duhet të rregullohen. Unë përpiqem të gjej lidhje midis asaj që njerëzit në kompani thonë dhe modeleve ekzistuese të provuara. Së fundi, një shënues blu sugjeron zgjidhje të mundshme për problemin.
(Ky ilustrim mund të shihet veçmas )
Një shembull i kësaj qasjeje është përshkruar tani më lart. Në fillim të këtij viti kam punuar me një bankë. Njerëzit e sigurisë atje ishin të bindur se ata nuk duhet të vinin për të rishikuar projektet dhe kërkesat.
(Ky ilustrim mund të shihet veçmas )
Dhe më pas biseduam me njerëz nga departamente të tjera dhe rezultoi se rreth 8 vjet më parë, zhvilluesit e softuerit pushuan punonjësit e sigurisë sepse po ngadalësonin punën. Dhe më pas u kthye në një ndalim, i cili u mor si i mirëqenë. Edhe pse në realitet nuk kishte asnjë ndalim.
Takimi ynë vazhdoi në një mënyrë jashtëzakonisht konfuze: për rreth tre orë, pesë ekipe të ndryshme nuk mundën të më shpjegonin se çfarë po ndodhte midis kodit dhe asamblesë. Dhe kjo do të duket të jetë gjëja më e thjeshtë. Shumica e konsulentëve të DevOps supozojnë që të gjithë tashmë e dinë këtë.
Më pas personi përgjegjës për qeverisjen e IT-së, i cili kishte heshtur për katër orë, papritur erdhi në jetë kur arritëm te tema e tij dhe na pushtoi për një kohë shumë të gjatë. Në fund e pyeta se çfarë mendonte për takimin dhe nuk do ta harroj kurrë përgjigjen e tij. Ai tha: “Më parë mendoja se banka jonë kishte vetëm dy mënyra për të ofruar softuer, por tani e di që janë pesë prej tyre dhe nuk dija as për tre”.
(Ky ilustrim mund të shihet veçmas )
Takimi i fundit në këtë bankë ishte me ekipin e softuerit të investimeve. Ishte me të që doli se shkrimi i diagrameve me një shënues në një fletë letre është më i mirë sesa në një tabelë, dhe madje edhe më mirë se në një smartfon.
Fotot që shihni janë se si dukej salla e konferencave të hotelit në ditën e katërt të takimit tonë. Dhe ne i përdorëm këto skema për të kërkuar modele, domethënë arketipe.
Kështu, unë u bëj pyetje punëtorëve, ata i shkruajnë përgjigjet me shënues të tre ngjyrave (e zezë, e kuqe dhe blu). Unë analizoj përgjigjet e tyre për arketipe. Tani le të diskutojmë të gjitha arketipet me radhë.
1. Bëni të gjitha punët të dukshme: Bëjeni punën të dukshme
Shumica e kompanive me të cilat punoj kanë një përqindje shumë të lartë të punës së panjohur. Për shembull, kjo është kur një punonjës vjen te një tjetër dhe thjesht kërkon të bëjë diçka. Në organizatat e mëdha, mund të ketë 60% punë të paplanifikuar. Dhe deri në 40% e punës nuk është e dokumentuar në asnjë mënyrë. Nëse do të ishte Boeing, nuk do të hipja më në aeroplanin e tyre në jetën time. Nëse dokumentohet vetëm gjysma e punës, atëherë nuk dihet nëse kjo punë është duke u bërë saktë apo jo. Të gjitha metodat e tjera rezultojnë të padobishme - nuk ka kuptim të përpiqeni të automatizoni asgjë, sepse 50% e njohur mund të jetë pjesa më koherente dhe e qartë e punës, automatizimi i së cilës nuk do të japë rezultate të shkëlqyera, dhe më e keqja. gjërat janë në gjysmën e padukshme. Në mungesë të dokumentacionit, është e pamundur të gjesh lloj-lloj hakerash dhe punësh të fshehura, të mos gjesh fyte të ngushta, pikërisht ato "Brents" për të cilat fola tashmë. Ekziston një libër i mrekullueshëm nga Dominica DeGrandis . Ajo zbulon pesë "rrjedhje kohore" të ndryshme (hajdutët e kohës):
- Shumë punë në proces (WIP)
- Varësi të panjohura
- Punë e paplanifikuar
- Prioritete kontradiktore
- Puna e lënë pas dore
Kjo është një analizë shumë e vlefshme dhe libri është i mrekullueshëm, por të gjitha këto këshilla janë të kota nëse vetëm 50% e të dhënave janë të dukshme. Metodat e propozuara nga Dominica mund të përdoren nëse arrihet një saktësi mbi 90%. E kam fjalën për situata kur një shef i jep një vartësi një detyrë 15-minutëshe, por atij i duhen tre ditë; por shefi nuk e di vërtet se ky vartës është i varur nga katër ose pesë persona të tjerë.
Projekti Phoenix është një histori e mrekullueshme për një projekt që ishte tre vjet shumë vonë. Njëri nga personazhet përballet me shkarkimin për këtë arsye dhe ai takohet me një personazh tjetër që paraqitet si një lloj Sokrati. Ai ndihmon për të kuptuar se çfarë saktësisht shkoi keq. Rezulton se kompania ka një administrator të sistemit, emri i të cilit është Brent, dhe e gjithë puna disi kalon përmes tij. Në një nga mbledhjet, një nga vartësit pyetet: pse çdo detyrë gjysmë ore zgjat një javë? Përgjigja është një prezantim shumë i thjeshtuar i teorisë së radhës dhe ligjit të Little-it, dhe në këtë prezantim rezulton se me zënie 90%, çdo orë pune merr 9 orë. Çdo detyrë duhet t'u dërgohet shtatë personave të tjerë, në mënyrë që ajo orë të bëhet 63 orë, 7 herë 9. Ajo që po them është se për të përdorur Ligjin e Little ose ndonjë teori komplekse të radhës, të paktën duhet të keni të dhëna.
Pra, kur flas për dukshmërinë, nuk dua të them që gjithçka është në ekran, por që të paktën keni të dhëna. Kur e bëjnë, shpesh rezulton se ka një sasi shumë të madhe pune të paplanifikuar që në njëfarë mënyre dërgohet në Brent kur nuk ka nevojë për të. Dhe Brent është një djalë i mrekullueshëm, ai kurrë nuk do të thotë jo, por ai nuk i tregon askujt se si e bën punën e tij.
Kur puna është e dukshme, të dhënat mund të klasifikohen mjeshtërisht (kështu po bën Dominika në foto), mund të aplikohet abstraksioni i pesë rrjedhjeve kohore dhe mund të aplikohet automatizimi.
2. Konsolidimi i Sistemeve të Menaxhimit të Punës: Menaxhimi i Detyrave
Arketipet për të cilat po flas janë një lloj piramide. Nëse e para është bërë si duhet, atëherë e dyta është tashmë një lloj shtesë. Shumë nga këto nuk funksionojnë për startup-et, ato duhet të mbahen parasysh për kompanitë më të mëdha si Fortune 5000. Kompania e fundit për të cilën kam punuar kishte 10 sisteme biletash. Një ekip kishte Remedy, një tjetër shkroi një lloj sistemi të tij, një i tretë përdori Jira dhe disa u mjaftuan me email. I njëjti problem lind nëse kompania ka 30 tubacione të ndryshme, por nuk kam kohë të diskutoj të gjitha këto raste.
Unë diskutoj me njerëzit saktësisht se si krijohen biletat, çfarë ndodh me ta më pas dhe si anashkalohen ato. Gjëja më interesante është se njerëzit në takimet tona flasin mjaft sinqerisht. Pyeta se sa njerëz vendosin "të vogël / pa ndikim" në biletat që në fakt duhet të kenë "ndikim të madh". Doli se pothuajse të gjithë e bëjnë këtë. Unë nuk merrem me denoncime dhe përpiqem në çdo mënyrë të mos identifikoj njerëzit. Kur ata më rrëfejnë sinqerisht diçka, unë nuk e jap atë person. Por kur pothuajse të gjithë anashkalojnë sistemin, kjo do të thotë se e gjithë siguria është në thelb veshje e dritares. Prandaj, nga të dhënat e këtij sistemi nuk mund të nxirren përfundime.
Për të zgjidhur problemin e biletave, duhet të zgjidhni një sistem kryesor. Nëse përdorni Jira, mbajeni Jira. Nëse ka ndonjë alternativë, le të jetë e vetmja. Në fund të fundit është se biletat duhet të shihen si një hap tjetër në procesin e zhvillimit. Çdo veprim duhet të ketë një biletë, e cila duhet të rrjedhë përmes rrjedhës së punës së zhvillimit. Biletat i dërgohen ekipit, i cili i poston në tabelën e tregimeve dhe më pas merr përgjegjësinë për to.
Kjo vlen për të gjitha departamentet, duke përfshirë infrastrukturën dhe operacionet. Në këtë rast, është e mundur të formohet të paktën një ide e besueshme për gjendjen e punëve. Pasi të vendoset ky proces, befas bëhet e lehtë për të identifikuar se kush është përgjegjës për çdo aplikim. Sepse tani ne marrim jo 50%, por 98% të shërbimeve të reja. Nëse ky proces thelbësor funksionon, atëherë saktësia përmirësohet në të gjithë sistemin.
Tubacioni i shërbimeve
Kjo përsëri vlen vetëm për korporatat e mëdha. Nëse jeni një kompani e re në një fushë të re, përveshni mëngët dhe punoni me Travis CI ose CircleCI. Kur bëhet fjalë për kompanitë e Fortune 5000, një rast i tillë që ndodhi në bankën ku punoja. Google erdhi tek ata dhe atyre iu shfaqën diagramet e sistemeve të vjetra IBM. Djemtë nga Google pyetën të hutuar - ku është kodi burim për këtë? Por nuk ka asnjë kod burimor, madje as një GUI. Ky është realiteti me të cilin duhet të përballen organizatat e mëdha: të dhënat bankare 40-vjeçare në një kompjuter të lashtë. Një nga klientët e mi përdor kontejnerë Kubernetes me modele Circuit Breaker, plus Chaos Monkey, të gjitha për aplikacionin KeyBank. Por këto kontejnerë përfundimisht lidhen me një aplikacion COBOL.
Djemtë nga Google ishin plotësisht të sigurt se do të zgjidhnin të gjitha problemet e klientit tim, dhe më pas filluan të bënin pyetje: çfarë është IBM datapipe? Atyre u thuhet: ky është një lidhës. Me çfarë lidhet? Tek sistemi Sperry. Dhe çfarë është kjo? Dhe kështu me radhë. Në pamje të parë duket: çfarë lloj DevOps mund të ketë? Por në fakt, është e mundur. Ka sisteme shpërndarjeje që ju lejojnë t'ia dorëzoni rrjedhën e punës ekipeve të dorëzimit.
3. Teoria e Kufizimeve: Teoria e Kufizimeve
Le të kalojmë te arketipi i tretë: njohuritë institucionale/“fisnore”. Si rregull, në çdo organizatë ka disa njerëz që dinë gjithçka dhe menaxhojnë gjithçka. Këta janë ata që kanë qenë më gjatë në organizatë dhe që i dinë të gjitha zgjidhjet.
Kur kjo del në diagram, unë i rrethoj në mënyrë specifike njerëz të tillë me një shënues: për shembull, rezulton se një Lou i caktuar është i pranishëm në të gjitha takimet. Dhe është e qartë për mua: ky është Brent lokal. Kur CIO zgjedh mes meje me bluzë dhe atlete dhe djalit nga IBM me kostum, unë zgjidhem sepse mund t'i tregoj drejtorit gjëra që djali tjetër nuk do t'i tregojë dhe që drejtorit mund të mos i pëlqejë t'i dëgjojë. . Unë u them atyre se pengesa në kompaninë e tyre është dikush me emrin Fred dhe dikush me emrin Lou. Kjo pengesë duhet të zgjidhet, njohuritë e tyre duhet të merren prej tyre në një mënyrë ose në një tjetër.
Për të zgjidhur këtë lloj problemi, unë, për shembull, mund të sugjeroj përdorimin e Slack. Një drejtor i zgjuar do të pyesë - pse? Në mënyrë tipike, në raste të tilla, konsulentët DevOps përgjigjen: sepse të gjithë po e bëjnë atë. Nëse drejtori është vërtet i zgjuar, ai do të thotë: pra çfarë. Dhe këtu përfundon dialogu. Dhe përgjigja ime për këtë është: sepse ka katër pengesa në kompani, Fred, Lou, Susie dhe Jane. Për të institucionalizuar njohuritë e tyre, së pari duhet të prezantohet Slack. Të gjitha wiki-t tuaja janë të pakuptimta sepse askush nuk e di për ekzistencën e tyre. Nëse ekipi inxhinierik është i përfshirë në zhvillimin e pjesëve të përparme dhe të pasme dhe të gjithë duhet të dinë se mund të kontaktojnë ekipin e zhvillimit të nivelit të përparmë ose ekipin e infrastrukturës me pyetje. Kjo është kur Lou ose Fred ndoshta do të kenë kohë për t'u bashkuar me wiki. Dhe pastaj në Slack dikush mund të pyesë pse, të themi, hapi 5 nuk po funksionon. Dhe më pas Lou ose Fred do të korrigjojnë udhëzimet në wiki. Nëse e vendosni këtë proces, atëherë shumë gjëra do të vendosen vetë.
Kjo është pika ime kryesore: për të rekomanduar çdo teknologji të lartë, së pari duhet të vendosni në rregull bazën për to, dhe kjo mund të bëhet me zgjidhjet e teknologjisë së ulët të përshkruara sapo. Nëse filloni me teknologji të larta dhe nuk shpjegoni pse nevojiten, atëherë, si rregull, kjo nuk përfundon mirë. Një nga klientët tanë përdor Azure ML, një zgjidhje shumë e lirë dhe e thjeshtë. Rreth 30% e pyetjeve të tyre u përgjigjën nga vetë makina e vetë-mësimit. Dhe kjo gjë është shkruar nga operatorë që nuk ishin të përfshirë në shkencën e të dhënave, statistikat apo matematikën. Kjo është domethënëse. Kostoja e një zgjidhjeje të tillë është minimale.
4. Hacks bashkëpunimi: Hacks bashkëpunimi
Arketipi i katërt është nevoja për të luftuar izolimin. Shumica e njerëzve tashmë e dinë këtë: izolimi ngjall armiqësi. Nëse çdo departament është në katin e vet, dhe njerëzit nuk kryqëzohen me njëri-tjetrin në asnjë mënyrë, përveç në ashensor, atëherë armiqësia midis tyre lind shumë lehtë. Por nëse, përkundrazi, njerëzit janë në të njëjtën dhomë me njëri-tjetrin, ajo largohet menjëherë. Kur dikush hedh një akuzë të përgjithshme, për shembull, kjo dhe ajo ndërfaqe nuk funksionon kurrë, nuk ka asgjë më të lehtë për të zbërthyer një akuzë të tillë. Programuesit që kanë shkruar ndërfaqen thjesht duhet të fillojnë të bëjnë pyetje specifike dhe së shpejti do të bëhet e qartë se, për shembull, përdoruesi thjesht po e përdorte mjetin gabimisht.
Ka shumë mënyra për të kapërcyer izolimin. Një herë më kërkuan të konsultohesha për një bankë në Australi, por nuk pranova ta bëja sepse kam dy fëmijë dhe një grua. Gjithçka që mund të bëja për t'i ndihmuar ata ishte t'u rekomandoja tregime grafike. Kjo është diçka që është vërtetuar se funksionon. Një mënyrë tjetër interesante janë takimet me kafe të dobët. Në një organizatë të madhe, ky është një mundësi e shkëlqyer për shpërndarjen e njohurive. Përveç kësaj, ju mund të kryeni devopsdays të brendshëm, hackathone, etj.
5. Kata stërvitore
Siç e paralajmërova që në fillim, nuk do të flas për këtë sot. Nëse jeni të interesuar, mund t'i hidhni një sy .
Ekziston gjithashtu një bisedë e mirë për këtë temë nga Mike Rother:
6. Orientuar në treg: organizim i orientuar nga tregu
Këtu ka probleme të ndryshme. Për shembull, njerëzit "Unë", njerëzit "T" dhe njerëzit "E". Njerëzit "unë" janë ata që bëjnë vetëm një gjë. Zakonisht ato ekzistojnë në organizata me departamente të izoluara. "T" është kur një person është i mirë në një gjë, por edhe i mirë në disa gjëra të tjera. "E" apo edhe "krehër" është kur një person ka shumë aftësi.
Ligji i Conway funksionon këtu (), e cila në formën më të thjeshtuar mund të thuhet si vijon: nëse tre ekipe punojnë në përpilues, atëherë rezultati do të jetë një përpilues prej tre pjesësh. Prandaj, nëse ka një nivel të lartë izolimi brenda një organizate, atëherë edhe Kubernetes, ndërprerësi i qarkut, shtrirja e API dhe gjëra të tjera të zbukuruara në këtë organizatë do të rregullohen në të njëjtën mënyrë si vetë organizata. Rreptësisht sipas Conway dhe për të keqardhur të gjithë ju geeks të rinj.
Zgjidhja e këtij problemi është përshkruar shumë herë. Ka, për shembull, arketipe organizative të përshkruara nga Fernando Fernandez. Ajo arkitekturë problematike për të cilën sapo fola, me izolim, është një arkitekturë e orientuar drejt funksionit. Lloji i dytë është arkitektura më e keqe, matricë, një rrëmujë e dy të tjerave. E treta është ajo që shihet në shumicën e startup-eve, dhe kompanitë e mëdha po përpiqen gjithashtu të përputhen me këtë lloj. Është një organizatë e orientuar drejt tregut. Këtu ne optimizojmë për të arritur përgjigjen më të shpejtë ndaj kërkesave të klientëve. Kjo nganjëherë quhet një organizatë e sheshtë.
Shumë njerëz e përshkruajnë këtë strukturë në mënyra të ndryshme, më pëlqen formulimi të ndërtojë/drejtojë ekipe, në Amazon e quajnë dy ekipe picash. Në këtë strukturë, të gjithë njerëzit e tipit “I” grupohen rreth një shërbimi dhe gradualisht afrohen me tipin “T” dhe nëse ekziston menaxhimi i duhur, ata mund të bëhen edhe “E”. Kundërargumenti i parë këtu është se një strukturë e tillë përmban elementë të panevojshëm. Pse keni nevojë për një testues në çdo departament nëse mund të keni një departament të veçantë testuesish? Për të cilën unë përgjigjem: kostot shtesë në këtë rast janë çmimi që e gjithë organizata të bëhet e tipit "E" në të ardhmen. Në këtë strukturë, testuesi mëson gradualisht për rrjetet, arkitekturën, dizajnin, etj. Si rezultat, çdo pjesëmarrës në organizatë është plotësisht i vetëdijshëm për gjithçka që ndodh në organizatë. Nëse dëshironi të dini se si funksionon kjo skemë në industri, lexoni .
7. Auditorët e zhvendosjes majtas: auditojnë në fillim të ciklit. Pajtueshmëria me rregullat e sigurisë në ekran
Kjo është kur veprimet tuaja nuk e kalojnë testin e nuhatjes, si të thuash. Njerëzit që punojnë për ju nuk janë budallenj. Nëse, si në shembullin e mësipërm, ata vendosën kudo ndikim të vogël/asnjë, kjo zgjati tre vjet dhe askush nuk vuri re asgjë, atëherë të gjithë e dinë shumë mirë që sistemi nuk funksionon. Ose një shembull tjetër - një bord këshillues ndryshimi, ku raportet duhet të dorëzohen çdo, le të themi, të mërkurën. Aty punon një grup njerëzish (meqë ra fjala, jo shumë të paguar) të cilët, në teori, duhet të dinë se si funksionon sistemi në tërësi. Dhe gjatë pesë viteve të fundit, ju ndoshta keni vënë re se sistemet tona janë tepër komplekse. Dhe pesë ose gjashtë persona duhet të marrin një vendim për një ndryshim që nuk e kanë bërë dhe për të cilin nuk dinë asgjë.
Sigurisht, kjo qasje nuk funksionon. Unë duhet të heq qafe gjëra të tilla sepse këta njerëz nuk po mbrojnë sistemin. Vendimi duhet të merret nga vetë ekipi, sepse ekipi duhet të jetë përgjegjës për të. Përndryshe, lind një situatë paradoksale kur një menaxher që nuk ka shkruar kurrë kod në jetën e tij i thotë programuesit se sa kohë duhet për të shkruar kodin. Një kompani me të cilën kam punuar kishte 7 borde të ndryshme që shqyrtonin çdo ndryshim, duke përfshirë një bord arkitekture, një bord produkti, etj. Kishte edhe një periudhë pritjeje të detyrueshme, megjithëse një punonjës më tha se në dhjetë vjet punë, askush nuk e kishte refuzuar një ndryshim të bërë nga ky person gjatë kësaj periudhe të detyrueshme.
Auditorët duhet të ftohen të bashkohen me ne dhe jo t'i heqin qafe. Tregojuni atyre që ju shkruani kontejnerë binare të pandryshueshme që, nëse i kalojnë të gjitha testet, mbeten të pandryshueshme përgjithmonë. Tregojuni atyre se keni një tubacion si kod dhe shpjegoni se çfarë do të thotë kjo. Tregojuni atyre skemën e mëposhtme: një binar i pandryshueshëm vetëm për lexim në një kontejner që kalon të gjitha testet e cenueshmërisë; dhe pastaj jo vetëm që nuk e prek askush, por as nuk e prek sistemin që krijon tubacionin, pasi ai është krijuar edhe në mënyrë dinamike. Unë kam klientë, Capital One, të cilët po përdorin Vault për të krijuar diçka si një blockchain. Auditori nuk ka nevojë të tregojë "receta" nga Chef, mjafton të tregojë blockchain, nga i cili është e qartë se çfarë ka ndodhur me biletën Jira në prodhim dhe kush është përgjegjës për të.
Sipas , krijuar në 2018 nga Sonatype, kishte 2017 miliardë kërkesa për shkarkim për OSS në 87.
Humbjet e shkaktuara për shkak të dobësive janë penguese. Për më tepër, shifrat që shihni tani më lart nuk përfshijnë kostot oportune. Çfarë është DevSecOps me pak fjalë? Më lejoni të them menjëherë se nuk më intereson të flas se sa i suksesshëm është ky emër. Çështja është se meqenëse DevOps ka qenë kaq i suksesshëm, ne duhet të përpiqemi të shtojmë sigurinë në atë tubacion.
Një shembull i kësaj sekuence:
Ky nuk është një rekomandim për produkte specifike, megjithëse më pëlqejnë të gjitha. I përmenda ato si shembull për të treguar se DevOps, i cili fillimisht bazohej në paradigmën organizative në industri, ju lejon të automatizoni çdo fazë të punës në një produkt.
Dhe nuk ka asnjë arsye pse ne nuk mund të kemi të njëjtën qasje ndaj sigurisë.
Total
Si përfundim, do të jap disa këshilla për DevSecOps. Ju duhet të përfshini auditorët në procesin e krijimit të sistemeve tuaja dhe të shpenzoni kohë duke i edukuar ata. Ju duhet të bashkëpunoni me auditorët. Tjetra, ju duhet të bëni një luftë absolutisht të pamëshirshme kundër pozitivëve të rremë. Edhe me mjetin më të shtrenjtë të skanimit të cenueshmërisë, mund të përfundoni duke krijuar zakone jashtëzakonisht të këqija midis zhvilluesve tuaj nëse nuk e dini se cili është raporti juaj sinjal-zhurmë. Zhvilluesit do të mbingarkohen me ngjarje dhe thjesht do t'i fshijnë ato. Nëse keni dëgjuar për historinë e Equifax, kjo është pothuajse ajo që ndodhi atje, ku niveli më i lartë i alarmit u injorua. Përveç kësaj, dobësitë duhet të shpjegohen në një mënyrë që ta bëjë të qartë se si ato ndikojnë në biznes. Për shembull, mund të thuash se kjo është e njëjta dobësi si në historinë e Equifax. Dobësitë e sigurisë duhet të trajtohen njësoj si çështjet e tjera të softuerit, domethënë ato duhet të përfshihen në procesin e përgjithshëm të DevOps. Ju duhet të punoni me ta përmes Jira, Kanban, etj. Zhvilluesit nuk duhet të mendojnë se dikush tjetër do ta bëjë këtë - përkundrazi, të gjithë duhet ta bëjnë këtë. Së fundi, ju duhet të shpenzoni energji për të trajnuar njerëzit.
Lidhje të dobishme
Këtu janë disa biseda nga konferenca DevOops që mund t'ju duken të dobishme:
- Sergey Berdnikov, Artyom Kalichkin - Histori suksesi, ose "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps në një shkallë: një tragjedi greke në tre akte (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Shiko në DevOops 2020 Moskë — aty ka edhe shumë gjëra interesante.
Burimi: www.habr.com