A pregunta "como implementar devops" leva anos, pero non hai moitos bos materiais. Ás veces é vítima de anuncios de consultores non tan intelixentes que necesitan vender o seu tempo, non importa como. Ás veces son palabras vagas e extremadamente xerais sobre como as naves das megacorporacións aran as extensións do universo. Xorde a pregunta: que nos importa isto? Estimado autor, podes formular claramente as túas ideas nunha lista?
Todo isto deriva do feito de que non se acumularon moitas prácticas e comprensións reais do resultado das transformacións da cultura da empresa. Os cambios na cultura son cousas a longo prazo, cuxos resultados non aparecerán nunha semana ou nun mes. Necesitamos alguén da idade suficiente para ver como se construíron e fracasaron as empresas ao longo dos anos.
John Willis - un dos pais de DevOps. John ten décadas de experiencia traballando con un gran número de empresas. Recentemente, John comezou a notar patróns específicos que teñen lugar ao traballar con cada un deles. Usando estes arquetipos, John guía ás empresas polo verdadeiro camiño da transformación de DevOps. Lea máis sobre estes arquetipos na tradución do seu informe da conferencia DevOops 2018.
Sobre o orador:
Máis de 35 anos na xestión informática, participou na creación do antecesor de OpenCloud en Canonical, participou en 10 startups, dúas das cales foron vendidas a Dell e Docker. Actualmente é vicepresidente de DevOps e Prácticas Dixitais en SJ Technologies.
A continuación é a historia dende o punto de vista de Xoán.
Chámome John Willis e o lugar máis sinxelo para atoparme é en Twitter. . Teño o mesmo alias en Gmail e GitHub. A podes atopar gravacións en vídeo dos meus informes e presentacións para eles.
Teño moitas reunións con CIOs de varias grandes empresas. Moitas veces quéixanse de que non entenden o que é DevOps e todos os que intentan explicarllo están falando de algo diferente. Outra queixa habitual é que DevOps non funciona, aínda que parece que os directores están facendo todo segundo lles explicaron. Estamos a falar de grandes empresas que teñen máis de cen anos. Despois de falar con eles, cheguei á conclusión de que para moitos problemas, non é a alta tecnoloxía a máis adecuada, senón as solucións de tecnoloxía relativamente baixa. Durante semanas só falei con xente de diferentes departamentos. O que vedes na primeira imaxe da publicación é o meu último proxecto, así quedou a sala despois de tres días de traballo.
Que é DevOps?
De feito, se preguntas a 10 persoas diferentes, estas darán 10 respostas diferentes. Pero aquí está o interesante: as dez destas respostas serán correctas. Non hai unha resposta incorrecta aquí. Estiven bastante metido no DevOps, durante uns 10 anos, e fun o primeiro estadounidense no primeiro DevOpsDay. Non direi que son máis intelixente que todos os que participan en DevOps, pero case non hai ninguén que teña dedicado tanto esforzo. Creo que o DevOps ocorre cando o capital humano e a tecnoloxía se unen. Moitas veces esquecémonos da dimensión humana, aínda que falamos moito de todo tipo de culturas.
Agora temos moitos datos, cinco anos de investigación académica, probas de teorías a escala industrial. O que nos din estes estudos é que se combinas algúns patróns de comportamento nunha cultura organizativa, podes conseguir unha aceleración de 2000 veces. Esta aceleración correspóndese cunha mellora igual na estabilidade. Esta é unha medida cuantitativa do beneficio que DevOps pode aportar a calquera empresa. Hai un par de anos, falaba de DevOps co CEO dunha empresa Fortune 5000. Cando me preparaba para a presentación, estaba moi nervioso porque tiña que resumir os meus anos de experiencia en 5 minutos.
Ao final dei o seguinte Definición de DevOps: É un conxunto de prácticas e patróns que posibilitan a transformación do capital humano en capital organizativo de alto rendemento. Un exemplo é a forma en que Toyota funcionou nos últimos 50 ou 60 anos.
(A partir de agora, tales diagramas non se ofrecen como material de referencia, senón como ilustracións. O seu contido será diferente para cada nova empresa. Non obstante, a imaxe pódese ver por separado e ampliada).
Unha das prácticas deste tipo de máis éxito é cartografía de fluxo de valor. Escribíronse varios bos libros sobre isto, os máis exitosos dos cales son de Karen Martin. Pero durante o ano pasado, cheguei á conclusión de que mesmo este enfoque é demasiado avanzado. Seguro que ten moitas vantaxes e useino moito. Pero cando o CEO che pregunta por que a súa empresa non pode cambiar a novos carrís, é demasiado cedo para falar de mapeo de fluxo de valor. Hai moitas preguntas máis fundamentais que primeiro deben ser respondidas.
Creo que o erro que cometen moitos dos meus compañeiros é que simplemente dan á empresa unha guía de cinco puntos e despois volven seis meses despois a ver que pasou. Incluso un bo esquema como a cartografía de fluxos de valor ten, digamos, puntos cegos. Despois de centos de entrevistas con directores de varias empresas, desenvolvín un determinado patrón que nos permite dividir o problema nos seus compoñentes, e agora comentaremos cada un destes compoñentes por orde. Antes de aplicar calquera solución tecnolóxica, uso este patrón e, como resultado, todas as miñas paredes están cubertas de diagramas. Recentemente estiven traballando cun fondo mutuo e acabei con 100-150 esquemas deste tipo.
A mala cultura come bos enfoques para almorzar
A idea principal é esta: ningunha cantidade de Lean, Agile, SAFE e DevOps axudará se a propia cultura da organización é mala. É como mergullarse a profundidade sen equipo de submarinismo ou operar sen unha radiografía. Noutras palabras, parafraseando a Drucker e Deming: unha mala cultura organizativa tragará calquera bo sistema sen atragantarse con el.
Para resolver este problema principal, cómpre seguir os seguintes pasos:
- Facer todo o traballo visible: cómpre facer visible todo o traballo. Non no sentido de que necesariamente debe mostrarse nalgunha pantalla, senón no sentido de que debe ser observable.
- Sistemas de xestión de traballo consolidados: deben consolidarse os sistemas de xestión. No problema do coñecemento “tribal” e do coñecemento institucional, en 9 casos de cada 10 o pescozo de botella son as persoas. No libro o problema foi cunha soa persoa, Brent, que fixo que o proxecto se atrasase tres anos. E atópome con estes "Brents" por todas partes. Para resolver estes pescozos de botella, uso os dous seguintes elementos da nosa lista.
- Metodoloxía da teoría de restricións: teoría das restricións.
- Hacks de colaboración: hacks de colaboración.
- Toyota Kata (): Non vou falar moito do Toyota Kata. Se che interesa, no meu github sobre case todos estes temas.
- Organización orientada ao mercado: organización orientada ao mercado.
- Auditores de quenda á esquerda: auditoría nas primeiras fases do ciclo.
Comezo a traballar cunha organización de xeito moi sinxelo: vou á empresa e falo cos empregados. Como podes ver, non hai alta tecnoloxía. Todo o que necesitas é algo no que escribir. Reúno varios equipos nunha sala e analizo o que me din dende a perspectiva dos meus 7 arquetipos. E despois doulles eles mesmos un rotulador e pídolles que anoten no encerado todo o que dixeron en voz alta ata agora. Normalmente neste tipo de reunións hai unha persoa que o anota todo, e ao mellor pode anotar o 10% da discusión. Co meu método, esta cifra pódese elevar a un 40%.
(Esta ilustración pódese ver por separado )
O meu enfoque baséase no traballo de William Schneider. ). O enfoque baséase na idea de que calquera organización pode dividirse en catro cadrados. Este esquema para min adoita ser o resultado de traballar con eses centos doutros esquemas que xorden ao analizar unha organización. Supoñamos que temos unha organización cun alto nivel de control, pero con pouca competencia. Esta é unha opción moi indesexable: cando todo o mundo está a seguir a liña, pero ninguén sabe que facer.
Unha opción un pouco mellor é aquela cun alto nivel de control e competencia. Se tal empresa é rendible, quizais non necesite DevOps. O máis interesante é traballar cunha empresa que teña un alto nivel de control, escasa competencia e cooperación, pero ao mesmo tempo un alto nivel de cultura (cultivo). Isto significa que a empresa ten moita xente á que lle gusta traballar e a rotación laboral é baixa.
(Esta ilustración pódese ver por separado )
A min paréceme que os métodos con pautas ríxidas acaban obstaculizando a consecución da verdade. No mapeo de fluxos de valor en particular, hai moitas regras sobre como se debe estruturar a información. Nas primeiras fases do traballo, das que falo agora, ninguén precisa destas regras. Se unha persoa cun marcador nas mans describe a situación real da empresa no consello, esta é a mellor forma de entender o estado das cousas. Dita información non chega aos directores. Neste momento, é estúpido interromper a persoa e dicir que debuxou algún tipo de frecha incorrectamente. Nesta fase, é mellor usar regras sinxelas, por exemplo: a abstracción de varios niveis pódese crear simplemente usando marcadores de varias cores.
Repito, sen alta tecnoloxía. O marcador negro representa a realidade obxectiva de como funciona todo. Cun marcador vermello, a xente marca o que non lle gusta do estado actual das cousas. É importante que escriban isto, non eu. Cando vou ao CIO despois dunha reunión, non ofrezo unha lista de 10 cousas que hai que arranxar. Esfórzome por atopar conexións entre o que di a xente da empresa e os patróns comprobados existentes. Finalmente, un marcador azul suxire posibles solucións ao problema.
(Esta ilustración pódese ver por separado )
Un exemplo deste enfoque está agora representado arriba. A principios deste ano traballei cun banco. A xente de seguridade alí estaba convencida de que non debían acudir a revisións de deseño e requisitos.
(Esta ilustración pódese ver por separado )
E despois falamos con xente doutros departamentos e resultou que hai uns 8 anos, os desenvolvedores de software despediron aos traballadores de seguridade porque estaban a ralentizar o traballo. E entón converteuse nunha prohibición, que se daba por feito. Aínda que en realidade non houbo prohibición.
A nosa reunión transcorreu dun xeito extremadamente confuso: durante unhas tres horas cinco equipos diferentes non me puideron explicar o que estaba a pasar entre o código e a montaxe. E isto parecería ser o máis sinxelo. A maioría dos consultores de DevOps asumen de antemán que todo o mundo xa o sabe.
Entón o responsable da gobernanza informática, que levaba catro horas en silencio, de súpeto cobrou vida cando chegamos ao seu tema, e ocupounos durante moito tempo. Ao final pregunteille que pensaba da reunión, e nunca esquecerei a súa resposta. El dixo: "Adoitaba pensar que o noso banco só tiña dúas formas de entregar software, pero agora sei que hai cinco e nin sequera sabía de tres".
(Esta ilustración pódese ver por separado )
A última reunión neste banco foi co equipo de software de investimento. Foi con ela que resultou que escribir diagramas cun rotulador nunha folla de papel é mellor que nunha pizarra, e incluso mellor que nunha pizarra intelixente.
As fotos que ves son o aspecto da sala de conferencias do hotel no cuarto día da nosa reunión. E utilizamos estes esquemas para buscar patróns, é dicir, arquetipos.
Entón, fago preguntas aos traballadores, escriben as respostas con rotuladores de tres cores (negro, vermello e azul). Analizo as súas respostas para arquetipos. Agora imos discutir todos os arquetipos en orde.
1. Facer visible todo o traballo: facer visible o traballo
A maioría das empresas coas que traballo teñen unha porcentaxe moi alta de traballo descoñecido. Por exemplo, é cando un empregado chega a outro e simplemente pide que faga algo. Nas grandes organizacións, pode haber un 60% de traballo non planificado. E ata o 40% do traballo non está documentado de ningún xeito. Se fose Boeing, nunca volvería a subir ao seu avión na miña vida. Se só se documenta a metade do traballo, non se sabe se este traballo se está a facer correctamente ou non. Todos os demais métodos resultan inútiles: non ten sentido intentar automatizar nada, porque o 50% coñecido pode ser a parte máis coherente e clara do traballo, cuxa automatización non dará grandes resultados, e o peor. as cousas están na metade invisible. A falta de documentación, é imposible atopar todo tipo de hacks e traballos ocultos, non atopar colos de botella, eses mesmos “Brents” dos que xa falei. Hai un libro marabilloso de Dominica DeGrandis . Ela revela cinco "fugas de tempo" diferentes (ladróns do tempo):
- Demasiado traballo en proceso (WIP)
- Dependencias descoñecidas
- Traballo non planificado
- Prioridades conflitivas
- Traballo descoidado
Esta é unha análise moi valiosa e o libro é xenial, pero todos estes consellos son inútiles se só o 50% dos datos son visibles. Os métodos propostos por Dominica pódense utilizar se se consegue unha precisión superior ao 90%. Falo de situacións nas que un xefe dálle a un subordinado unha tarefa de 15 minutos, pero leva tres días; pero o xefe non sabe moi ben que este subordinado depende doutras catro ou cinco persoas.
O Proxecto Fénix é unha historia marabillosa sobre un proxecto que tardou tres anos. Un dos personaxes enfróntase ao despedimento por iso, e atópase con outro personaxe que se presenta como unha especie de Sócrates. Axuda a descubrir que foi exactamente mal. Resulta que a empresa ten un administrador do sistema, cuxo nome é Brent, e todo o traballo pasa dalgún xeito. Nunha das reunións pregúntase a un dos subordinados: por que cada tarefa de media hora leva unha semana? A resposta é unha presentación moi simplificada da teoría da cola e da lei de Little, e nesta presentación resulta que ao 90% de ocupación, cada hora de traballo leva 9 horas. Cada tarefa debe ser enviada a outras sete persoas, polo que esa hora pasa a ser 63 horas, 7 veces 9. O que estou dicindo é que para usar a Lei de Little ou calquera teoría complexa de filas, polo menos cómpre ter datos.
Entón, cando falo de visibilidade, non quero dicir que todo estea na pantalla, senón que polo menos tes datos. Cando o fan, moitas veces resulta que hai unha cantidade moi grande de traballo non planificado que, dalgún xeito, se envía a Brent cando non hai necesidade del. E Brent é un gran tipo, nunca dirá que non, pero non lle di a ninguén como fai o seu traballo.
Cando o traballo é visible, os datos pódense clasificar ordenadamente (é o que fai Dominique na foto), pódese aplicar a abstracción das fugas de cinco tempos e aplicarse a automatización.
2. Consolidar os sistemas de xestión do traballo: xestión de tarefas
Os arquetipos dos que falo son unha especie de pirámide. Se o primeiro está feito correctamente, entón o segundo xa é unha especie de complemento. Moitos destes non funcionan para startups, hai que telos en conta para empresas máis grandes como Fortune 5000. A última empresa para a que traballei tiña 10 sistemas de billetes. Un equipo tiña Remedy, outro escribiu algún tipo de sistema propio, un terceiro usou Jira e algúns se conformaron co correo electrónico. O mesmo problema xorde se a empresa ten 30 canalizacións diferentes, pero non teño tempo para discutir todos estes casos.
Comento coa xente exactamente como se crean as entradas, o que lles pasa a continuación e como se evitan. O máis interesante é que a xente das nosas reunións fala con bastante sinceridade. Pregunteille cantas persoas poñen "impacto menor / sen impacto" nas entradas ás que realmente se debería dar "impacto importante". Resultou que case todo o mundo fai isto. Non me dedico á denuncia e intento de todas as formas posibles non identificar á xente. Cando me confesan algo sinceramente, non regalo a persoa. Pero cando case todo o mundo ignora o sistema, significa que toda a seguridade é esencialmente un escaparatismo. Polo tanto, non se poden extraer conclusións dos datos deste sistema.
Para resolver o problema do billete, cómpre escoller un sistema principal. Se usas Jira, consérvao Jira. Se hai algunha alternativa, que sexa a única. A conclusión é que as entradas deben verse como un paso máis no proceso de desenvolvemento. Cada acción debe ter un ticket, que debe fluír polo fluxo de traballo de desenvolvemento. As entradas son enviadas ao equipo, que as publica no guión gráfico e logo asume a responsabilidade delas.
Isto aplícase a todos os departamentos, incluíndo infraestruturas e operacións. Neste caso, é posible formar polo menos unha idea plausible do estado das cousas. Unha vez establecido este proceso, de súpeto faise doado identificar quen é o responsable de cada aplicación. Porque agora non recibimos o 50%, senón o 98% dos novos servizos. Se este proceso principal funciona, entón a precisión mellora en todo o sistema.
Canalización de servizos
Isto de novo só se aplica ás grandes corporacións. Se es unha empresa nova nun campo novo, arremanga as mangas e traballa co teu Travis CI ou CircleCI. Cando se trata de empresas Fortune 5000, un caso concreto que ocorreu no banco onde eu traballaba. Google chegou a eles e mostráronlles diagramas de antigos sistemas IBM. Os mozos de Google preguntaron confusos: onde está o código fonte para isto? Pero non hai código fonte, nin sequera unha GUI. Esta é a realidade coa que teñen que facer fronte as grandes organizacións: os rexistros bancarios de 40 anos nun antigo mainframe. Un dos meus clientes usa contedores de Kubernetes con patróns Circuit Breaker, ademais de Chaos Monkey, todo para a aplicación KeyBank. Pero estes contedores finalmente conéctanse a unha aplicación COBOL.
Os mozos de Google estaban completamente seguros de que resolverían todos os problemas do meu cliente, e entón comezaron a facer preguntas: que é IBM datapipe? Dinlles: este é un conector. A que se conecta? Ao sistema Sperry. E iso que é? Etcétera. A primeira vista parece: que tipo de DevOps pode haber? Pero, de feito, é posible. Existen sistemas de entrega que permiten entregar o fluxo de traballo aos equipos de entrega.
3. Teoría das restricións: teoría das restricións
Pasemos ao terceiro arquetipo: o coñecemento institucional/“tribal”. Como regra xeral, en calquera organización hai varias persoas que o saben todo e xestionan todo. Estes son os que máis tempo levan na organización e que coñecen todas as solucións.
Cando isto aparece no diagrama, rodeo específicamente a esas persoas cun marcador: por exemplo, resulta que un certo Lou está presente en todas as reunións. E teno claro: este é o Brent local. Cando o CIO escolle entre min cunha camiseta e zapatillas deportivas e o tipo de IBM cun traxe, son elixido porque podo dicirlle ao director cousas que o outro non lle dirá e que quizais non lle guste escoitar. . Dígolles que o pescozo de botella na súa compañía é alguén chamado Fred e alguén chamado Lou. Hai que desatar este pescozo de botella, hai que obter deles o seu coñecemento dun xeito ou doutro.
Para resolver este tipo de problemas, podo, por exemplo, suxerir o uso de Slack. Un director intelixente preguntará: por que? Normalmente, nestes casos, os consultores de DevOps responden: porque todo o mundo o está facendo. Se o director é realmente intelixente, dirá: e que? E aquí remata o diálogo. E a miña resposta a isto é: porque hai catro embotellamentos na empresa, Fred, Lou, Susie e Jane. Para institucionalizar o seu coñecemento, primeiro hai que introducir Slack. Todos os teus wikis son unha tontería total porque ninguén sabe da súa existencia. Se o equipo de enxeñería está implicado no desenvolvemento front-end e back-end e todo o mundo precisa saber que poden contactar co equipo de desenvolvemento front-end ou co equipo de infraestrutura con preguntas. É entón cando Lou ou Fred probablemente terán tempo para unirse á wiki. E entón en Slack alguén pode preguntar por que, por exemplo, o paso 5 non funciona. E entón Lou ou Fred corrixirán as instrucións na wiki. Se estableces este proceso, moitas cousas encadrarán por si só.
Este é o meu punto principal: para recomendar calquera alta tecnoloxía, primeiro debes poñerlles en orde as bases, e isto pódese facer coas solucións de baixa tecnoloxía que acabamos de describir. Se comezas con altas tecnoloxías e non explicas por que son necesarias, entón, por regra xeral, isto non acaba ben. Un dos nosos clientes usa Azure ML, unha solución moi barata e sinxela. Ao redor do 30% das súas preguntas foron respondidas pola propia máquina de autoaprendizaxe. E esta cousa foi escrita por operadores que non estaban involucrados na ciencia de datos, a estatística ou as matemáticas. Isto é significativo. O custo desta solución é mínimo.
4. Hacks de colaboración: Hacks de colaboración
O cuarto arquetipo é a necesidade de combater o illamento. A maioría da xente xa o sabe: o illamento xera hostilidade. Se cada departamento está no seu propio piso e as persoas non se cruzan de ningún xeito, excepto no ascensor, entón a hostilidade entre eles xorde moi facilmente. Pero se, pola contra, a xente está no mesmo cuarto entre si, ela marcha inmediatamente. Cando alguén lanza algunha acusación xeral, por exemplo, tal interface nunca funciona, non hai nada máis fácil deconstruír tal acusación. Os programadores que escribiron a interface só precisan comezar a facer preguntas específicas, e pronto quedará claro que, por exemplo, o usuario simplemente estaba a usar a ferramenta de forma incorrecta.
Hai moitas formas de superar o illamento. Unha vez pedíronme que consultara un banco en Australia, pero negueime a facelo porque teño dous fillos e unha muller. O único que puiden facer para axudalos foi recomendarlles a narración gráfica. Isto é algo que está demostrado que funciona. Outra forma interesante son as reunións de café magro. Nunha organización grande, esta é unha excelente opción para difundir coñecemento. Ademais, pode realizar devopsdays internos, hackathons, etc.
5. Adestrar Kata
Como advertín ao principio, hoxe non vou falar disto. Se estás interesado, podes botarlle unha ollada .
Tamén hai unha boa charla sobre este tema de Mike Rother:
6. Market Oriented: organización orientada ao mercado
Aquí hai diferentes problemas. Por exemplo, persoas "I", persoas "T" e persoas "E". As persoas "eu" son as que só fan unha cousa. Normalmente existen en organizacións con departamentos illados. "T" é cando unha persoa é boa nunha cousa pero tamén é boa noutras cousas. "E" ou incluso "peite" é cando unha persoa ten moitas habilidades.
A lei de Conway funciona aquí (), que na forma máis simplificada pódese afirmar do seguinte xeito: se no compilador traballan tres equipos, o resultado será un compilador de tres partes. Polo tanto, se hai un alto nivel de illamento dentro dunha organización, incluso Kubernetes, Circuit breaker, extensibilidade da API e outras cousas elegantes nesta organización organizaranse do mesmo xeito que a propia organización. Estrictamente segundo Conway e para malestar todos os mozos frikis.
A solución a este problema foi descrita moitas veces. Hai, por exemplo, arquetipos organizativos descritos por Fernando Fernández. Esa arquitectura problemática da que acabo de falar, con illamento, é unha arquitectura orientada a funcións. O segundo tipo é o peor, a arquitectura matricial, un desorde dos outros dous. O terceiro é o que se ve na maioría das startups, e as grandes empresas tamén intentan igualar este tipo. É unha organización orientada ao mercado. Aquí optimizamos para conseguir a resposta máis rápida ás solicitudes dos clientes. Isto ás veces chámase organización plana.
Moita xente describe esta estrutura de diferentes xeitos, gústame a redacción crear/dirixir equipos, en Amazon chámanlle dous equipos de pizza. Nesta estrutura, todas as persoas do tipo "I" agrúpanse ao redor dun servizo e, aos poucos, achéganse ao tipo "T", e se existe a xestión adecuada, poden chegar a converterse en "E". O primeiro contraargumento aquí é que tal estrutura ten elementos innecesarios. Por que necesitas un probador en cada departamento se podes ter un departamento especial de probadores? Ao que contesto: os custos adicionais neste caso son o prezo para que toda a organización pase a ser tipo "E" no futuro. Nesta estrutura, o probador aprende aos poucos sobre redes, arquitectura, deseño, etc. Como resultado, cada participante da organización é plenamente consciente de todo o que acontece na organización. Se queres saber como funciona este esquema na industria, le .
7. Auditores de quenda á esquerda: auditoría no inicio do ciclo. Cumprimento das normas de seguridade expostas
Isto é cando as túas accións non pasan a proba do olfacto, por así dicir. A xente que traballa para ti non é parva. Se, como no exemplo anterior, estableceron un impacto menor ou nulo en todas partes, isto durou tres anos e ninguén se decatou de nada, entón todo o mundo sabe perfectamente que o sistema non funciona. Ou outro exemplo: un consello consultivo de cambio, onde os informes deben enviarse todos os mércores, por exemplo. Alí traballa un grupo de persoas (non moi ben remuneradas, por certo) que, en teoría, deberían saber como funciona o sistema no seu conxunto. E durante os últimos cinco anos, probablemente notaches que os nosos sistemas son incriblemente complexos. E cinco ou seis persoas teñen que tomar unha decisión sobre un cambio que non fixeron e do que non saben nada.
Por suposto, este enfoque non funciona. Teño que desfacerme de tales cousas porque esta xente non protexe o sistema. A decisión debe ser tomada polo propio equipo, porque o equipo debe ser responsable dela. En caso contrario, xorde unha situación paradoxal cando un xestor que nunca escribiu código na súa vida dille ao programador canto tempo debería tardar en escribir código. Unha empresa coa que traballei tiña 7 consellos diferentes que revisaban cada cambio, incluíndo un consello de arquitectura, un panel de produtos, etc. Incluso houbo un período de espera obrigatorio, aínda que un empregado díxome que en dez anos de traballo ninguén rexeitara nunca un cambio que fixera esta persoa durante este período obrigatorio.
Hai que invitar aos auditores a unirse a nós, e non desfacerse deles. Dilles que escribes contedores binarios inmutables que, se pasan todas as probas, permanecen inmutables para sempre. Dígalles que tes unha canalización como código e explícalles o que significa. Móstralles o seguinte esquema: un binario de só lectura inmutable nun contedor que supera todas as probas de vulnerabilidade; e entón non só ninguén o toca, nin sequera toca o sistema que crea a canalización, xa que tamén se crea de forma dinámica. Teño clientes, Capital One, que están usando Vault para crear algo así como unha cadea de bloques. O auditor non precisa mostrar "receitas" de Chef, abonda con mostrar a cadea de bloques, da que se desprende que pasou co ticket Jira en produción e quen é o responsable.
Conforme , creado en 2018 por Sonatype, houbo 2017 millóns de solicitudes de descarga de OSS en 87.
As perdas ocasionadas por vulnerabilidades son prohibitivas. Ademais, as cifras que agora ves arriba non inclúen os custos de oportunidade. Que é DevSecOps en poucas palabras? Déixeme dicir de inmediato que non me interesa falar do éxito que ten este nome. A cuestión é que, dado que DevOps tivo tanto éxito, debemos tentar engadir seguridade a esa canalización.
Un exemplo desta secuencia:
Esta non é unha recomendación para produtos específicos, aínda que me gustan todos. Citeinos como exemplo para demostrar que DevOps, que inicialmente se baseaba no paradigma organizativo da industria, permite automatizar cada etapa do traballo nun produto.
E non hai razón para que non poidamos adoptar o mesmo enfoque da seguridade.
Total
Como conclusión, vou dar algúns consellos para DevSecOps. Debe incluír auditores no proceso de creación dos seus sistemas e dedicar tempo a educalos. Debes cooperar cos auditores. A continuación, cómpre librar unha loita absolutamente desapiadada contra os falsos positivos. Incluso coa ferramenta de dixitalización de vulnerabilidades máis cara, podes acabar creando hábitos moi malos entre os teus desenvolvedores se non sabes cal é a túa relación sinal-ruído. Os desenvolvedores quedarán abrumados con eventos e simplemente eliminarános. Se escoitou falar da historia de Equifax, iso é practicamente o que pasou alí, onde se ignorou o nivel de alerta máis alto. Ademais, as vulnerabilidades deben explicarse de forma que quede claro como afectan ao negocio. Por exemplo, podería dicir que esta é a mesma vulnerabilidade que na historia de Equifax. As vulnerabilidades de seguridade deben tratarse do mesmo xeito que outros problemas de software, é dicir, deben incluírse no proceso global de DevOps. Debes traballar con eles a través de Jira, Kanban, etc. Os desenvolvedores non deben pensar que outra persoa fará isto; pola contra, todos deberían facelo. Finalmente, cómpre gastar enerxía en formar persoas.
Ligazóns útiles
Aquí tes algunhas charlas da conferencia DevOops que che poden resultar útiles:
- Sergey Berdnikov, Artyom Kalichkin - Historia de éxito ou "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps a escala: unha traxedia grega en tres actos (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Bota unha ollada a DevOops 2020 Moscova - Tamén hai moitas cousas interesantes alí.
Fonte: www.habr.com