Get best of the week

Sete arquétipos de transformação do DevOps

A questão "como implementar uma devopae" não é o primeiro ano, mas não existem tantos materiais bons. Às vezes você se torna vítima de publicidade de consultores não muito inteligentes que precisam vender seu tempo, não importa como. Às vezes, essas são palavras obscuras e extremamente genéricas sobre como navios de megacorporações exploram as extensões do universo. Surge a pergunta: e nós? Caro autor, você pode formular claramente suas idéias com uma lista?

Tudo isso advém do fato de não haver muita prática real acumulada e entendimento do resultado das transformações da cultura da empresa. Mudanças na cultura são coisas de longa duração, cujos resultados não aparecerão em uma semana e nem em um mês. Precisamos de alguém antigo o suficiente para ver como as empresas foram criadas e entraram em colapso ao longo dos anos.



John Willis- Um dos pais do DevOps. Atrás de John - dezenas de anos de trabalho com um grande número de empresas. Recentemente, John começou a notar por si próprio padrões específicos que ocorrem no trabalho com cada um deles. Usando esses arquétipos, John orienta as empresas no verdadeiro caminho da transformação do DevOps. Leia mais sobre esses arquétipos na tradução de seu relatório da conferência DevOops 2018.



Sobre o palestrante:

Mais de 35 anos em gerenciamento de TI, participou da criação do antecessor do OpenCloud na Canonical, participou de 10 startups, duas das quais foram vendidas pela Dell e Docker. Atualmente, ele é vice-presidente de DevOps e práticas digitais da SJ Technologies.

A seguir, a narrativa em nome de John.

Meu nome é John Willis e a maneira mais fácil de me encontrar no Twitter é @botchagalupe . Eu tenho o mesmo alias no Gmail e GitHub. E neste link, você pode encontrar vídeos dos meus relatórios e apresentações para eles.

Tenho muitas reuniões com CIOs de várias grandes empresas. Com frequência, eles reclamam que não entendem o que é DevOps e todos que tentam explicar isso estão falando de outra coisa. Outra queixa comum é que o DevOps não funciona, embora pareça que os diretores estejam fazendo tudo conforme explicado a eles. Estamos falando de grandes empresas com mais de cem anos. Depois de conversar com eles, cheguei à conclusão de que, para muitos problemas, não são de alta tecnologia, mas de soluções relativamente de baixa tecnologia são mais adequadas. Durante semanas, conversei com pessoas de diferentes departamentos. O que você vê na primeira foto do post é o meu último projeto, a sala ficou assim depois de três dias de trabalho.

O que é o DevOps?


De fato, se você perguntar a 10 pessoas diferentes, elas darão 10 respostas diferentes. Mas o que é interessante: todas essas dez respostas estarão corretas. Não há resposta errada aqui. Estudei DevOps profundamente, por cerca de 10 anos, foi o primeiro americano no primeiro DevOpsDay. Não direi que sou mais esperto do que todos os envolvidos no DevOps, mas dificilmente há alguém que tenha gasto tanto esforço nisso. Acredito que o DevOps surge quando o capital humano e a tecnologia são combinados. Muitas vezes esquecemos a dimensão humana, embora falemos muito sobre todos os tipos de culturas.



Agora temos muitos dados, cinco anos de pesquisa acadêmica, a verificação de teorias foi estabelecida em escala industrial. Esses estudos nos dizem o seguinte: se você combinar alguns padrões comportamentais em uma cultura organizacional, poderá obter uma aceleração de 2000 vezes. Essa aceleração corresponde à mesma melhoria na estabilidade. Essa é uma medida quantitativa dos benefícios que o DevOps pode trazer para qualquer empresa. Há alguns anos, conversei sobre o DevOps com um CEO da Fortune 5000. Quando estava me preparando para a apresentação, fiquei muito nervoso porque precisava estabelecer meus muitos anos de experiência em 5 minutos.

Acabei dando a seguinte definição de DevOps: Este é um conjunto de práticas e padrões que tornam possível transformar o capital humano em capital organizacional altamente produtivo. Um exemplo é como a Toyota trabalha há 50 ou 60 anos.



(A seguir, esses esquemas são apresentados não como material de referência, mas como ilustração. Seu conteúdo será diferente para cada nova empresa. No entanto, a imagem pode ser vista e ampliada separadamente por este link.)

Uma das práticas mais bem-sucedidas é o fluxo de valor mapeamento. Vários bons livros foram escritos sobre isso, o autor dos mais bem sucedidos deles é Karen Martin. Mas, no ano passado, cheguei à conclusão de que mesmo essa abordagem é de alta tecnologia. Ele certamente tem muitas vantagens, eu o usei bastante. Mas quando o CEO pergunta por que sua empresa não pode seguir para novas pistas, é muito cedo para falar sobre o mapeamento do fluxo de valor. Há muitas questões muito mais fundamentais que precisam ser respondidas primeiro.

Parece-me que o erro de muitos de meus colegas é que eles simplesmente dão à empresa um guia de cinco pontos e depois voltam seis meses depois e olham o que aconteceu. Mesmo um bom circuito como o mapeamento do fluxo de valor tem, digamos, pontos cegos. Após centenas de entrevistas com diretores de várias empresas, elaborei um certo padrão que nos permite decompor o problema em componentes, e agora discutiremos cada um desses componentes em ordem. Antes de aplicar qualquer solução tecnológica, eu uso esse padrão e, como resultado, tenho todas as paredes penduradas com padrões. Recentemente, trabalhei com um fundo mútuo e acabei com 100-150 desses esquemas.

A má cultura toma boas abordagens no café da manhã


A idéia principal é a seguinte: nenhum Lean, Agile, SAFE e DevOps ajudarão se a cultura da organização for ruim. É o mesmo que mergulhar nas profundezas sem equipamento de mergulho ou operar sem raio-X. Em outras palavras, parafraseando Drucker e Deming: uma cultura organizacional ruim engolirá qualquer bom sistema e não sufocará.

Para resolver esse problema principal, você deve executar as seguintes etapas:

  1. Tornar todo o trabalho visível: torne todo o trabalho visível. Não no sentido de que deve ser exibido em qualquer tela, mas no sentido de que deve ser observável.
  2. Consolidate Work Management Systems: . «» 9 10 . «Phoenix Project» - , , - . «» . c .
  3. Theory of Constraints Methodology: .
  4. Collaboration hacks: .
  5. Toyota Kata (Coaching Kata): Toyota Kata . , .
  6. Market Oriented Organization: .
  7. Shift-left auditors: .




Começo a trabalhar com a organização de maneira muito simples: vou à empresa e converso com os funcionários. Como você pode ver, não há alta tecnologia. Tudo o que é necessário é escrever. Coleciono várias equipes em uma sala e analiso o que elas me dizem do ponto de vista dos meus 7 arquétipos. E então eu mesmo dou o marcador e peço que escrevam no quadro escrevendo tudo o que disseram até agora em voz alta. Normalmente, nessas reuniões, há uma pessoa que escreve tudo e, na melhor das hipóteses, ele pode gravar 10% da discussão. Com o meu método, esse número pode ser aumentado para cerca de 40%.



(Para uma ilustração separada, veja o link )

Minha abordagem é baseada no trabalho de William Schneider, The Reengineering Alternative) A abordagem é baseada na ideia de que qualquer organização pode ser decomposta em quatro quadrados. Esse esquema para mim geralmente é o resultado de trabalhar com centenas de outros esquemas que surgem ao analisar uma organização. Suponha que tenhamos uma organização com um alto nível de controle, mas com baixa competência. Esta é uma opção extremamente indesejável: quando todos andam ao longo da linha, mas ninguém sabe o que fazer.

Uma opção ligeiramente melhor com um alto nível de controle e competência. Se uma empresa desse tipo tiver lucro, talvez não precise de DevOps. É mais interessante trabalhar com uma empresa que possui um alto nível de controle, baixa competência e cooperação, mas ao mesmo tempo um alto nível de cultura (cultivo). Isso significa que a empresa tem muitas pessoas que gostam de trabalhar lá, a rotatividade de mão-de-obra é baixa.



(Você pode ver esta ilustração separadamente no link )

Parece-me que métodos com recomendações codificadas permanecem interferindo no alcance da verdade. Em particular, o mapeamento do fluxo de valor possui muitas regras sobre como estruturar informações. Nos estágios iniciais do trabalho sobre o qual estou falando agora, ninguém precisa dessas regras. Se uma pessoa com um marcador nas mãos descrever a situação real na empresa no quadro, essa é a melhor maneira de entender a situação. Essas informações não chegam aos diretores. Neste momento, é estúpido cortar uma pessoa e dizer que ele desenhou uma flecha errada. Nesse estágio, é melhor usar regras simples, por exemplo: uma abstração de vários níveis pode ser criada simplesmente usando marcadores coloridos.

Repito, sem alta tecnologia. Um marcador preto mostra a realidade objetiva, como tudo funciona. As pessoas marcam com um marcador vermelho o que exatamente elas não gostam no estado atual das coisas. É importante que eles escrevam, não eu. Quando vou ao Diretor de Tecnologia da Informação após a reunião, não proponho uma lista de 10 coisas que precisam ser corrigidas. Esforço-me para encontrar uma conexão entre o que as pessoas na empresa dizem e os padrões existentes e comprovados. Finalmente, um marcador azul sugere possíveis soluções para o problema.



(Separadamente, esta ilustração pode ser visualizada no link )

Um exemplo dessa abordagem está agora descrito acima. No início deste ano, trabalhei com um banco. Os funcionários do departamento de segurança de lá estavam convencidos de que não deveriam verificar os requisitos e o design (revisões de projeto e requisitos).



(Você pode ver esta ilustração separadamente no link ).

E então conversamos com pessoas de outros departamentos e, por volta de 8 anos atrás, os desenvolvedores de software expulsaram os trabalhadores de segurança porque diminuíam a velocidade. E então se transformou em uma proibição, que foi tomada como certa. Embora de fato não houvesse proibição.

Nossa reunião foi uma ação extremamente confusa: por cerca de três horas, cinco equipes diferentes não puderam me explicar o que estava acontecendo entre o código e a assembléia. E isso, ao que parece, é a coisa mais simples. A maioria dos consultores de DevOps assume antecipadamente que todos já sabem disso.

Então, o responsável pela governança de TI, que ficou em silêncio por quatro horas, de repente ganhou vida quando chegamos ao assunto e nos ocupou por muito tempo. No final, perguntei o que ele acha da reunião e nunca esquecerei sua resposta. Ele disse: "Eu pensava que havia apenas duas maneiras de fornecer software em nosso banco, e agora sei que existem cinco delas e nem suspeitei de três".



(Separadamente, esta ilustração pode ser visualizada no link )

A última reunião deste banco foi com a equipe de software de investimento. Foi com ela que descobriu que escrever circuitos de marcador com marcador em uma folha é melhor do que escrever em um quadro e ainda melhor do que escrever em um quadro inteligente.



As fotografias que você vê são como era a sala de conferências do hotel no quarto dia da nossa reunião. E usamos esses padrões para procurar padrões, ou seja, arquétipos.

Então, faço perguntas aos funcionários, eles escrevem respostas com marcadores de três cores (preto, vermelho e azul). Analiso suas respostas para arquétipos. Agora vamos discutir todos os arquétipos em ordem.

1. Tornar todo o trabalho visível: torne o trabalho visível.


A maioria das empresas com as quais trabalho tem uma porcentagem muito alta de empregos desconhecidos. Por exemplo, é quando um funcionário chega a outro e apenas pede para fazer alguma coisa. Nas grandes organizações, pode haver 60% do trabalho não planejado. E até 40% do trabalho não é documentado de forma alguma. Se fosse um Boeing, na minha vida nunca mais teria embarcado no avião deles. Se apenas metade do trabalho estiver documentada, não se sabe se esse trabalho foi realizado corretamente ou não. Todos os outros métodos acabam sendo inúteis - não há sentido em tentar automatizar algo, porque os 50% conhecidos podem ser apenas a parte mais coerente e clara do trabalho, cuja automação não dará grandes resultados, e os mais terríveis - na metade invisível. Na ausência de documentação, é impossível encontrar todos os tipos de hacks e trabalhos ocultos, não encontrar gargalos,aqueles mesmos "Brents" sobre os quais eu já falei. Há um belo livro de Dominica De Grandis (Dominica DeGrandis)"Tornando o trabalho visível . " Ele identifica cinco " ladrões do tempo" diferentes:

  • Muito trabalho em processo (WIP)
  • Dependências desconhecidas
  • Trabalho não planejado
  • Prioridades conflitantes
  • Trabalho Negligenciado


Esta é uma análise muito valiosa, e o livro é maravilhoso, mas todas essas dicas são inúteis se apenas 50% dos dados estiverem visíveis. Você pode aplicar os métodos propostos pela Dominica se a precisão for alcançada acima de 90%. Estou falando de situações em que o chefe dá ao subordinado uma tarefa de 15 minutos e leva três dias; mas o chefe realmente não sabe que esse subordinado depende de quatro ou cinco outras pessoas.



O Projeto Phoenix é uma ótima história sobre um projeto atrasado três anos. Um dos heróis está ameaçado de demissão por causa disso, e ele se encontra com outro personagem que é apresentado como uma espécie de Sócrates. Ele ajuda a descobrir o que exatamente deu errado. Acontece que a empresa tem um administrador de sistema, cujo nome é Brent, e todo o trabalho de alguma forma passa por ele. Em uma das reuniões, um dos subordinados é perguntado: por que cada tarefa de meia hora demora uma semana? Em resposta, segue-se uma exposição muito simplificada da teoria das filas e da lei de Little, e nessa exposição ocorre que 90% do emprego a cada hora de trabalho leva 9 horas. Cada tarefa precisa ser enviada para outras sete pessoas, portanto, esta hora se transforma em 63 horas, 7 vezes 9. Eu digo isso,Para usar a lei de Little ou qualquer teoria complicada de filas, você precisa ter pelo menos dados.

Portanto, quando falo de visibilidade, não quero dizer que tudo estava na tela, mas que é necessário pelo menos ter dados. Quando estão, geralmente ocorre uma quantidade muito grande de trabalho não planejado, que por algum motivo é enviado ao Brent, embora isso não seja necessário. E Brent é um cara legal, ele nunca diz não, mas ele não conta a ninguém como ele faz o trabalho.



Quando o trabalho está visível, você pode classificar com precisão os dados (é o que Dominika faz na foto), pode aplicar a abstração de cinco vazamentos de tempo e automatizá-los.

2. Consolidar sistemas de gerenciamento de trabalho: gerenciamento de tarefas


Os arquétipos de que estou falando são uma espécie de pirâmide. Se o primeiro for feito corretamente, o segundo já é um tipo de complemento. Muitos deles não trabalham para startups, mas devem ser lembrados no caso de grandes empresas, como as que estão na lista da Fortune 5000. A última empresa em que trabalhei tinha 10 sistemas de emissão de bilhetes. O remédio estava em uma equipe, outro escreveu algum tipo de sistema próprio, um terceiro usou o Jira e alguém se deu bem com o e-mail. O mesmo problema surge se a empresa tiver 30 canais diferentes, mas não tenho tempo para discutir todos esses casos.

Discuto com as pessoas exatamente como os tickets são criados, o que acontece com eles a seguir, como eles são contornados. O mais interessante é que as pessoas em nossas reuniões falam sinceramente. Perguntei quantas pessoas configuraram “menor / nenhum impacto” para tickets que realmente deveriam ter sido designados como “maior impacto”. Acabou que quase todo mundo faz isso. Não me envolvo em denúncias e, de todas as formas, tento não identificar pessoas. Quando eles sinceramente me admitem algo, eu não traí uma pessoa. Mas quando quase todo mundo ignora o sistema, isso significa que toda segurança, em essência, é uma decoração. Portanto, nenhuma conclusão pode ser tirada dos dados deste sistema.

Para resolver o problema com tickets, você precisa selecionar um sistema principal. Se você usa Jira, seja apenas Jira. Se houver alguma alternativa, seja apenas isso. O ponto principal é que os tickets precisam ser considerados como outra etapa do processo de desenvolvimento. Qualquer ação deve ter um ticket que deve passar pelo fluxo de trabalho de desenvolvimento. Os ingressos são enviados para a equipe, que os coloca no storyboard e, em seguida, é responsável por eles.

Isso se aplica a todos os departamentos, incluindo infraestrutura e operações. Nesse caso, você pode inventar pelo menos uma idéia plausível da situação. Quando esse processo é estabelecido, acontece repentinamente que você pode estabelecer facilmente quem é responsável por cada aplicativo. Porque agora não temos 50%, mas 98% de novos serviços. Se esse processo básico funcionar, a precisão melhora em todo o sistema.

Serviços de Pipeline


Isso novamente se aplica apenas a grandes corporações. Se você é uma nova empresa em um novo campo, arregace as mangas e trabalhe com o Travis CI ou o CircleCI. Quanto às empresas da Fortune 5000, o caso que aconteceu com o banco em que trabalhei foi indicativo. Eles vieram do Google para eles e foram mostrados diagramas com os antigos sistemas IBM. Os caras do Google com um mal-entendido perguntaram - onde está o código fonte disso? E não há código fonte, nem mesmo uma GUI. Essa é a realidade com a qual as grandes organizações precisam trabalhar: registros bancários de 40 anos em um mainframe antigo. Um dos meus clientes usa contêineres Kubernetes com padrões de disjuntor, além do Chaos Monkey, todos para o KeyBank. Mas esses contêineres eventualmente se conectam ao aplicativo COBOL.

Os caras do Google estavam totalmente confiantes de que resolveriam todos os problemas do meu cliente e começaram a fazer perguntas: qual é o datapipe da IBM? Eles são respondidos: este é um conector. Com o que está se conectando? Para o sistema Sperry. E o que é isso? Etc. À primeira vista, parece: que tipo de DevOps pode ser? Mas, de fato, é possível. Existem sistemas de entrega que permitem transferir o fluxo de trabalho para as equipes de entrega.

3. Teoria das Restrições: Teoria das Restrições


Vamos para o terceiro arquétipo: conhecimento institucional / "tribal". Como regra, em qualquer organização existem várias pessoas que sabem tudo e gerenciam tudo. São aqueles que trabalham mais tempo na organização e que conhecem todas as soluções alternativas.



Quando isso é revelado no diagrama, desenhei especialmente um marcador em torno dessas pessoas: por exemplo, acontece que um certo Lou está presente em todas as reuniões. E para mim está claro: este é o Brent local. Quando o CIO escolhe entre mim de camiseta e tênis e um cara de terno da IBM, eles me escolhem porque eu posso contar ao diretor sobre coisas que o outro cara não conta e sobre as quais o diretor pode não gostar de ouvir. Eu digo a eles que há um gargalo na empresa deles, é alguém chamado Fred e alguém chamado Lu. Esse gargalo precisa ser desatado, seu conhecimento precisa ser obtido de uma maneira ou de outra.

Para resolver esse tipo de problema, posso sugerir, por exemplo, o uso do Slack. Um diretor inteligente pergunta por quê? Normalmente, nesses casos, os consultores de DevOps respondem: porque todos respondem. Se o diretor for realmente inteligente, ele dirá: e daí. E é aí que o diálogo termina. E eu respondo: porque a empresa tem quatro gargalos, Fred, Lou, Susie e Jane. Para tornar seu conhecimento institucionalizado, você deve primeiro apresentar o Slack. Todas as suas wikis são um absurdo completo, porque ninguém sabe da existência delas. Se a equipe de engenheiros estiver envolvida em desenvolvimento externo e interno, e todos deverão saber que você pode entrar em contato com a equipe de desenvolvimento externa ou a equipe de infraestrutura com perguntas. Nesse momento, provavelmente Lou ou Fred terão tempo para se conectar ao wiki. E então, no Slack, alguém pode perguntarpor que não funciona, digamos, na etapa 5. E então Lou ou Fred corrigem as instruções no wiki. Se você estabelecer esse processo, muita coisa se encaixará.

Esta é minha idéia principal: para recomendar algumas tecnologias de ponta, você deve primeiro ordenar a base delas e pode fazer isso com as soluções de baixa tecnologia descritas anteriormente. Se você começa com alta tecnologia e não explica por que eles são necessários, então, como regra, isso não termina com nada de bom. Um de nossos clientes usa o Azure ML, uma solução muito barata e fácil. Em algum lugar, 30% das perguntas foram respondidas pela própria máquina de auto-aprendizado. E operadores que não lidavam com ciência de dados, estatística ou matemática escreveram isso. Isso é indicativo. O custo dessa solução é mínimo.

4. Hacks de colaboração: Hacks de colaboração


O quarto arquétipo é a necessidade de combater o isolamento. A maioria das pessoas já sabe disso: o isolamento gera inimizade. Se cada departamento estiver em seu próprio andar e as pessoas não se cruzarem de maneira alguma, exceto no elevador, a hostilidade entre eles surgirá com muita facilidade. E se, pelo contrário, as pessoas estão na mesma sala, ela sai imediatamente. Quando alguém lança algum tipo de acusação geral, por exemplo, essa interface nunca funciona - não há nada mais fácil para desconstruir essa acusação. Basta que os programadores que escreveram a interface comecem a fazer perguntas específicas e logo fica claro que, por exemplo, o usuário simplesmente usou a ferramenta incorretamente.

Existem muitas maneiras de superar o isolamento. Uma vez me pediram para aconselhar um banco na Austrália, eu me recusei a fazer isso porque tenho dois filhos e uma esposa. Tudo o que eu poderia ajudá-los foi recomendar uma narrativa gráfica para eles. Isso é algo que provavelmente funciona. Outra maneira interessante são as reuniões em formato de café enxuto. Em uma organização grande, essa é uma ótima maneira de disseminar conhecimento. Além disso, você pode realizar feriados internos, hackathons e assim por diante.

5. Coaching Kata


Como eu já avisei no começo, hoje não vou falar sobre isso. Se estiver interessado, você pode ver algumas das minhas apresentações .

Há também um bom relatório sobre esse tópico de Mike Rother:



6. Orientada para o Mercado: Uma Organização Orientada para o Mercado


Existem vários problemas aqui. Por exemplo, pessoas "I", pessoas "T" e pessoas "E". As pessoas "eu" são aquelas que estão envolvidas em apenas uma coisa. Geralmente eles existem em organizações com unidades isoladas. "T" é se uma pessoa sabe bem uma coisa, mas também se destaca em outras. Um "E" ou mesmo um "pente" é quando uma pessoa tem muitas habilidades. A lei de Conway



funciona aqui , que da forma mais simplificada pode ser declarada da seguinte forma: se as três equipes estiverem envolvidas no compilador, o resultado será um compilador de três partes. Portanto, se a organização tiver um alto nível de isolamento, até o Kubernetes, o disjuntor, a extensibilidade da API e outras coisas da moda nessa organização serão organizados da mesma maneira que a própria organização. Estritamente de acordo com Conway e apesar de todos vocês, jovens nerds.

A solução para esse problema foi descrita várias vezes. Existem, por exemplo, arquétipos organizacionais descritos por Fernando Fernandez. A arquitetura do problema de que acabei de falar com isolamento é uma arquitetura orientada a funções. O segundo tipo é o pior, arquitetura matricial, há uma confusão dos outros dois. O terceiro é o que é visto na maioria das startups, e as grandes empresas também estão tentando igualar esse tipo. É uma organização orientada para o mercado. Aqui está a otimização para obter a resposta mais rápida às solicitações dos clientes. Isso às vezes é chamado de organização plana.

Muitas pessoas descrevem essa estrutura de maneiras diferentes, eu gosto da redação de equipes de criação / execução , na Amazon elas chamam de duas equipes de pizza. Nesta estrutura, todas as pessoas do tipo “I” são agrupadas em torno de um serviço e gradualmente se aproximam do tipo “T” e, se o gerenciamento correto for estabelecido, até o “E” poderá se tornar. O primeiro contra-argumento aqui é que existem elementos supérfluos nessa estrutura. Por que precisamos de um testador em cada departamento, se você pode ter um departamento especial de testadores? A que respondo: custos excessivos, neste caso, são o preço para garantir que, no futuro, toda a organização se torne do tipo "E". Nessa estrutura, o testador aprende gradualmente sobre redes, arquitetura, design etc. Como resultado, cada membro da organização está totalmente ciente de tudo o que acontece na organização. Se você quiser saber como esse circuito funciona na indústria, consulte Mike Rother, Toyota Kata .

7. Auditores de turno esquerdo: auditoria nos estágios iniciais de um ciclo. Cumprimento das normas de segurança


É quando suas ações não passam, por assim dizer, em um teste de odor. As pessoas que trabalham para você não são estúpidas. Se eles, como no exemplo acima, em todos os lugares exibiram pouco ou nenhum impacto, isso durou três anos e ninguém notou nada, todos sabem que o sistema não está funcionando. Ou outro exemplo é o conselho consultivo de mudanças, onde cada ambiente, digamos, precisa ser relatado. Um grupo de pessoas trabalha lá (a propósito, não é muito bem pago), que em teoria deveria saber como o sistema como um todo funciona. Nos últimos cinco anos, você provavelmente notou que nossos sistemas são incrivelmente complexos. E cinco ou seis pessoas devem decidir sobre uma mudança que não fizeram e que não sabem nada.

Obviamente, essa abordagem não funciona. Eu tenho que me livrar dessas coisas, porque essas pessoas não protegem o sistema. A decisão deve ser tomada pela própria equipe, porque a equipe deve ser responsável por ela. Caso contrário, uma situação paradoxal surge quando o gerente, que nunca escreveu código em sua vida, diz ao programador quanto tempo leva para escrever o código. Em uma empresa com a qual trabalhei, havia 7 dicas diferentes que analisavam cada alteração, incluindo arquitetura, produto e assim por diante. Houve até um período de espera obrigatório, embora um funcionário tenha me dito que, em dez anos de trabalho, ninguém nesse período obrigatório jamais havia rejeitado as alterações feitas por essa pessoa.

Os auditores devem ser chamados a si mesmos e não se livrar deles. Diga a eles que você está escrevendo contêineres binários imutáveis ​​que, se todos os testes forem aprovados, permanecerão inalterados para sempre. Diga a eles que você tem o pipeline como código e explique o que isso significa. Mostre a eles o seguinte diagrama: binário somente leitura imutável em um contêiner que passa em todos os testes de vulnerabilidade; e então, além de ninguém tocar, eles nem tocam o sistema que cria o pipeline, porque ele também é criado dinamicamente. Eu tenho clientes, o Capital One, que usam o Vault para criar algo como uma blockchain. Você não pode mostrar as “receitas” do Chef ao auditor, basta mostrar a blockchain, a partir da qual fica claro o que aconteceu com o ticket Jira em produção e quem é responsável por ele.



De acordo com o relatóriocriado pela Sonatype em 2018, houve 87 bilhões de solicitações de download de OSS em 2017.



As vulnerabilidades incorridas são proibitivas. Além disso, os números que você vê acima não incluem os custos de oportunidade. Em poucas palavras, sobre o que é DevSecOps. Quero dizer imediatamente que não estou interessado em falar sobre o sucesso desse nome. O ponto é que, como o DevOps teve muito sucesso, você precisa tentar adicionar segurança a esse pipeline.

Um exemplo dessa sequência:


essa não é uma recomendação para determinados produtos, mesmo que eu goste de todos. Eu os citei como um exemplo para mostrar que o DevOps, baseado inicialmente no paradigma da organização no setor, permite automatizar todas as etapas do trabalho em um produto.



E não há razão para que não possamos adotar a mesma abordagem de segurança.

Total


Como conclusão, darei algumas dicas para o DevSecOps. Você precisa incluir auditores no processo de criação de seus sistemas, dedicar tempo à educação deles. Precisamos trabalhar com auditores. Além disso, é necessário empreender uma luta absolutamente implacável contra falsos positivos. Mesmo com a ferramenta de verificação de vulnerabilidades mais cara, você pode criar hábitos extremamente ruins para seus desenvolvedores se não souber o que é a relação sinal / ruído. Os desenvolvedores ficarão sobrecarregados com eventos e eles simplesmente os excluirão. Se você ouviu falar sobre a história com a Equifax, foi o que aconteceu lá, o sinal do nível de perigo mais alto foi ignorado lá. Além disso, as vulnerabilidades precisam ser explicadas para que fique claro como elas afetam os negócios. Por exemplo, podemos dizer que essa é a mesma vulnerabilidade da história da Equifax. Vulnerabilidades de segurançaVocê precisa considerar da mesma maneira que outros problemas com o software, ou seja, eles precisam ser incluídos no processo geral do DevOps. Você precisa trabalhar com eles através de Jira, Kanban, etc. Os desenvolvedores não devem pensar que outra pessoa fará isso; pelo contrário, todos devem fazê-lo. Finalmente, você precisa gastar energia em educar as pessoas.

Links Úteis


Aqui estão algumas palestras da conferência DevOops que você pode achar úteis:



Dê uma olhada no programa DevOops 2020 em Moscou - também há muitas coisas interessantes lá.

More articles:


All Articles