A questão “como implementar devops” existe há anos, mas não existem muitos materiais bons. Às vezes você é vítima de anúncios de consultores não tão inteligentes que precisam vender seu tempo, não importa como. Às vezes, essas são palavras vagas e extremamente gerais sobre como as naves das megacorporações exploram as extensões do universo. Surge a pergunta: o que isso importa para nós? Caro autor, você consegue formular claramente suas ideias em uma lista?
Tudo isso decorre do fato de que não se acumulou muita prática e compreensão reais do resultado das transformações da cultura da empresa. Mudanças na cultura são coisas de longo prazo, cujos resultados não aparecerão em uma semana ou em um mês. Precisamos de alguém com idade suficiente para ter visto como as empresas foram construídas e fracassaram ao longo dos anos.
John Willis - um dos pais do DevOps. John tem décadas de experiência trabalhando com um grande número de empresas. Recentemente, John começou a notar padrões específicos que ocorrem ao trabalhar 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 gestão de TI, participou da criação do antecessor do OpenCloud na Canonical, participou de 10 startups, sendo duas vendidas para Dell e Docker. Atualmente é Vice-Presidente de DevOps e Práticas Digitais da SJ Technologies.
A seguir está a história do ponto de vista de John.
Meu nome é John Willis e o lugar mais fácil para me encontrar é no Twitter, . Tenho o mesmo alias no Gmail e no GitHub. A você pode encontrar gravações de vídeo de meus relatórios e apresentações para eles.
Tenho muitas reuniões com CIOs de várias grandes empresas. Muitas vezes eles reclamam que não entendem o que é DevOps, e todos que tentam explicar isso estão falando sobre algo diferente. Outra reclamação comum é que o DevOps não funciona, embora pareça que os diretores estão fazendo tudo conforme lhes foi explicado. 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 é a alta tecnologia que é mais adequada, mas sim soluções de tecnologia relativamente baixa. Durante semanas, conversei com pessoas de diferentes departamentos. O que vocês veem logo na primeira foto do post é meu último projeto, era assim que a sala ficou depois de três dias de trabalho.
O que é DevOps?
Na verdade, se você perguntar a 10 pessoas diferentes, elas darão 10 respostas diferentes. Mas aqui está o interessante: todas essas dez respostas estarão corretas. Não há resposta errada aqui. Eu estive bastante envolvido com DevOps, por cerca de 10 anos, e fui o primeiro americano no primeiro DevOpsDay. Não direi que sou mais inteligente do que todos os envolvidos em DevOps, mas dificilmente alguém se esforçou tanto nisso. Acredito que o DevOps ocorre quando o capital humano e a tecnologia se unem. 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, testes de teorias em escala industrial. O que esses estudos nos dizem é que se você combinar alguns padrões comportamentais em uma cultura organizacional, poderá alcançar uma aceleração de 2000 vezes. Esta aceleração é acompanhada por uma melhoria igual na estabilidade. Esta é uma medida quantitativa do benefício que o DevOps pode trazer para qualquer empresa. Há alguns anos, eu estava conversando sobre DevOps com o CEO de uma empresa Fortune 5000. Quando estava me preparando para a apresentação, fiquei muito nervoso porque tive que resumir meus anos de experiência em 5 minutos.
No final eu dei o seguinte Definição de DevOps: É um conjunto de práticas e padrões que permitem a transformação do capital humano em capital organizacional de alto desempenho. Um exemplo é a forma como a Toyota tem operado nos últimos 50 ou 60 anos.
(Doravante, tais diagramas são fornecidos não como material de referência, mas como ilustrações. Seu conteúdo será diferente para cada nova empresa. No entanto, a imagem pode ser visualizada separadamente e ampliada
Uma das práticas de maior sucesso é mapeamento de fluxo de valor. Vários bons livros foram escritos sobre isso, dos quais os de maior sucesso são de Karen Martin. Mas, no ano passado, cheguei à conclusão de que mesmo esta abordagem é demasiado tecnológica. Certamente tem muitas vantagens e tenho usado muito. Mas quando o CEO pergunta por que a empresa dele não pode mudar para novos trilhos, é muito cedo para falar sobre mapeamento do fluxo de valor. Existem muitas outras questões fundamentais que devem primeiro ser respondidas.
Acho que o erro que muitos dos meus colegas cometem é simplesmente dar à empresa um guia de cinco pontos e voltar seis meses depois para ver o que aconteceu. Mesmo um bom esquema como o mapeamento do fluxo de valor tem, digamos, pontos cegos. Após centenas de entrevistas com diretores de diversas empresas, desenvolvi um certo padrão que nos permite dividir o problema em seus componentes, e agora discutiremos cada um desses componentes em ordem. Antes de aplicar qualquer solução tecnológica, utilizo esse padrão e, como resultado, todas as minhas paredes ficam cobertas de diagramas. Recentemente, eu estava trabalhando com um fundo mútuo e acabei com 100-150 desses esquemas.
A má cultura consome boas abordagens no café da manhã
A ideia principal é esta: nenhuma quantidade de Lean, Agile, SAFE e DevOps ajudará se a cultura da organização em si for ruim. É como mergulhar em profundezas sem equipamento de mergulho ou operar sem raio-x. Em outras palavras, parafraseando Drucker e Deming: uma má cultura organizacional engolirá qualquer bom sistema sem sufocá-lo.
Para resolver este problema principal, você precisa seguir os seguintes passos:
- Torne todo o trabalho visível: você precisa tornar todo o trabalho visível. Não no sentido de que deva necessariamente ser exibido em alguma tela, mas no sentido de que deve ser observável.
- Sistemas Consolidados de Gestão do Trabalho: os sistemas de gestão precisam ser consolidados. No problema do conhecimento “tribal” e do conhecimento institucional, em 9 entre 10 casos o gargalo são as pessoas. No livro o problema estava com uma única pessoa, Brent, que atrasou o projeto três anos. E encontro esses “Brents” em todos os lugares. Para resolver esses gargalos, utilizo os próximos dois itens da nossa lista.
- Metodologia da Teoria das Restrições: teoria das Restrições.
- Hacks de colaboração: hacks de colaboração.
- Toyota Kata (): Não vou falar muito sobre o Toyota Kata. Se estiver interessado, no meu github em quase todos esses tópicos.
- Organização Orientada para o Mercado: organização orientada para o mercado.
- Auditores shift-esquerdo: auditoria nas fases iniciais do ciclo.
Começo a trabalhar com uma organização de forma muito simples: vou até a empresa e converso com os funcionários. Como você pode ver, nenhuma alta tecnologia. Tudo que você precisa é de algo para escrever. Reúno várias equipes em uma sala e analiso o que elas me dizem sob a perspectiva dos meus 7 arquétipos. E então eu lhes dou um marcador e peço que escrevam no quadro tudo o que disseram em voz alta até agora. Normalmente neste tipo de reunião há uma pessoa que anota tudo e, na melhor das hipóteses, consegue anotar 10% da discussão. Com o meu método, esse número pode ser aumentado para cerca de 40%.
(Esta ilustração pode ser visualizada separadamente )
Minha abordagem é baseada no trabalho de William Schneider. ). A abordagem baseia-se na ideia de que qualquer organização pode ser dividida em quatro quadrados. Para mim, esse esquema geralmente é o resultado de trabalhar com centenas de outros esquemas que surgem ao analisar uma organização. Suponha que temos uma organização com alto nível de controle, mas com baixa competência. Esta é uma opção extremamente indesejável: quando todos estão seguindo os limites, mas ninguém sabe o que fazer.
Uma opção um pouco melhor é aquela com alto nível de controle e competência. Se tal empresa for lucrativa, talvez não precise de DevOps. O mais interessante é trabalhar com uma empresa que tenha alto nível de controle, baixa competência e cooperação, mas ao mesmo tempo alto nível de cultura (cultivo). Isso significa que a empresa tem muita gente que gosta de trabalhar lá e a rotatividade de mão de obra é baixa.
(Esta ilustração pode ser visualizada separadamente )
Parece-me que métodos com diretrizes rígidas acabam atrapalhando o alcance da verdade. Em particular no mapeamento do fluxo de valor, existem muitas regras sobre como a informação deve ser estruturada. Nas fases iniciais do trabalho, de que estou falando agora, ninguém precisa dessas regras. Se uma pessoa com um marcador nas mãos descreve no quadro a situação real da empresa, esta é a melhor forma de compreender a situação. Essas informações não chegam aos diretores. Nesse momento, é estúpido interromper a pessoa e dizer que ela desenhou algum tipo de flecha incorretamente. Nesta fase, é melhor usar regras simples, por exemplo: uma abstração multinível pode ser criada simplesmente usando marcadores multicoloridos.
Repito, nada de alta tecnologia. O marcador preto representa a realidade objetiva de como tudo funciona. Com um marcador vermelho, as pessoas marcam o que não gostam na situação atual. É importante que eles escrevam isso, não eu. Quando vou ao CIO após uma reunião, não ofereço uma lista de 10 coisas que precisam ser corrigidas. Eu me esforço para encontrar conexões entre o que as pessoas na empresa estão dizendo e os padrões comprovados existentes. Finalmente, um marcador azul sugere possíveis soluções para o problema.
(Esta ilustração pode ser visualizada separadamente )
Um exemplo dessa abordagem é agora descrito acima. No início deste ano trabalhei com um banco. O pessoal de segurança estava convencido de que não deveria fazer revisões de projeto e requisitos.
(Esta ilustração pode ser visualizada separadamente )
E então conversamos com pessoas de outros departamentos e descobrimos que, há cerca de 8 anos, os desenvolvedores de software demitiram funcionários de segurança porque estavam atrasando o trabalho. E então se transformou em uma proibição, que era tida como certa. Embora na realidade não houvesse proibição.
Nossa reunião transcorreu de forma extremamente confusa: durante cerca de três horas, cinco equipes diferentes não conseguiram me explicar o que estava acontecendo entre o código e a montagem. E isso parece ser a coisa mais simples. A maioria dos consultores de DevOps presumem de antemão 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-lhe o que pensava do encontro e nunca esquecerei a sua resposta. Ele disse: “Eu costumava pensar que nosso banco tinha apenas duas maneiras de entregar software, mas agora sei que existem cinco delas, e eu nem conhecia três”.
(Esta ilustração pode ser visualizada separadamente )
A última reunião neste banco foi com a equipe de software de investimento. Foi com ela que descobriu-se que escrever diagramas com marcador em uma folha de papel é melhor do que em um quadro e ainda melhor do que em um smartboard.
As fotos que você vê são como era a sala de conferências do hotel no quarto dia de nossa reunião. E utilizamos esses esquemas para buscar padrões, ou seja, arquétipos.
Então, faço perguntas aos trabalhadores, eles anotam as respostas com marcadores de três cores (preto, vermelho e azul). Eu analiso suas respostas em busca de arquétipos. Agora vamos discutir todos os arquétipos em ordem.
1. Torne todo o trabalho visível: torne o trabalho visível
A maioria das empresas com as quais trabalho tem uma porcentagem muito alta de trabalhos desconhecidos. Por exemplo, é quando um funcionário chega até outro e simplesmente pede para fazer alguma coisa. Em grandes organizações, pode haver 60% de trabalho não planejado. E até 40% do trabalho não é documentado de forma alguma. Se fosse a Boeing, eu nunca mais embarcaria no avião deles na minha vida. Se apenas metade do trabalho for documentado, não se sabe se esse trabalho está sendo feito corretamente ou não. Todos os outros métodos revelam-se inúteis - não adianta tentar automatizar nada, porque os 50% conhecidos podem ser a parte mais coerente e clara do trabalho, cuja automatização não dará grandes resultados, e tudo o pior as coisas estão na metade invisível. Na ausência de documentação, é impossível encontrar todo tipo de hacks e trabalhos ocultos, não encontrar gargalos, aqueles mesmos “Brents” de que já falei. Há um livro maravilhoso de Dominica DeGrandis . Ela revela cinco diferentes "vazamentos de tempo" (ladrões do tempo):
- 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 é ótimo, mas todos esses conselhos são inúteis se apenas 50% dos dados estiverem visíveis. Os métodos propostos pela Dominica podem ser utilizados se for alcançada uma precisão superior a 90%. Estou falando de situações em que um chefe dá a um subordinado uma tarefa de 15 minutos, mas ele leva três dias; mas o chefe não sabe realmente que esse subordinado depende de quatro ou cinco outras pessoas.
O Projeto Phoenix é uma história maravilhosa sobre um projeto que atrasou três anos. Um dos personagens é demitido por causa disso e 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, pergunta-se a um dos subordinados: por que cada tarefa de meia hora leva uma semana? A resposta é uma apresentação muito simplificada da teoria das filas e da lei de Little, e nesta apresentação verifica-se que com 90% de ocupação, cada hora de trabalho leva 9 horas. Cada tarefa precisa ser enviada para outras sete pessoas, de modo que a hora se torne 63 horas, 7 vezes 9. O que estou dizendo é que para usar a Lei de Little ou qualquer teoria complexa de filas, você precisa pelo menos ter dados.
Então quando falo em visibilidade não quero dizer que está tudo na tela, mas que pelo menos você tem dados. Quando o fazem, muitas vezes verifica-se que há uma grande quantidade de trabalho não planeado que, de alguma forma, está a ser enviado para Brent quando não há necessidade dele. E Brent é um cara legal, ele nunca vai dizer não, mas não conta a ninguém como faz seu trabalho.
Quando o trabalho está visível, os dados podem ser classificados de forma organizada (é o que Dominika está fazendo na foto), a abstração dos cinco vazamentos temporais pode ser aplicada e a automação pode ser aplicada.
2. Consolidar Sistemas de Gestão de Trabalho: Gestão 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á é uma espécie de complemento. Muitos deles não funcionam para startups; eles precisam ser lembrados para empresas maiores, como a Fortune 5000. A última empresa em que trabalhei tinha 10 sistemas de bilhetagem. Uma equipe tinha o Remedy, outra escreveu algum tipo de sistema próprio, uma terceira usou o Jira e algumas se contentaram com e-mail. O mesmo problema surge se a empresa tiver 30 pipelines 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 e como são contornados. O mais interessante é que as pessoas nas nossas reuniões falam com bastante sinceridade. Perguntei quantas pessoas colocam "menor/nenhum impacto" em tickets que deveriam, na verdade, ter "grande impacto". Acontece que quase todo mundo faz isso. Não faço denúncias e tento de todas as formas não identificar as pessoas. Quando eles me confessam algo com sinceridade, eu não entrego a pessoa. Mas quando quase todo mundo ignora o sistema, isso significa que toda a segurança é essencialmente uma fachada. Portanto, nenhuma conclusão pode ser tirada dos dados deste sistema.
Para resolver o problema do ticket, você precisa escolher um sistema principal. Se você usa Jira, mantenha-o Jira. Se houver alguma alternativa, que seja a única. O resultado final é que os tickets devem ser vistos como mais uma etapa no processo de desenvolvimento. Cada ação deve ter um ticket, que deve fluir pelo fluxo de trabalho de desenvolvimento. Os tickets são enviados para a equipe, que os publica no storyboard e então se responsabiliza por eles.
Isto se aplica a todos os departamentos, incluindo infraestrutura e operações. Nesse caso, é possível formar pelo menos alguma ideia plausível da situação. Uma vez estabelecido esse processo, torna-se fácil identificar quem é o responsável por cada aplicação. Porque agora recebemos não 50%, mas 98% dos novos serviços. Se esse processo central funcionar, a precisão melhorará em todo o sistema.
Pipeline de serviços
Novamente, isso se aplica apenas a grandes corporações. Se você é uma empresa nova em um novo campo, arregace as mangas e trabalhe com seu Travis CI ou CircleCI. Quando se trata de empresas Fortune 5000, um caso que aconteceu no banco onde trabalhei. O Google veio até eles e lhes mostraram diagramas de sistemas IBM antigos. Os caras do Google perguntaram confusos - onde está o código-fonte disso? Mas não existe código-fonte, nem mesmo uma GUI. Esta é a realidade com a qual as grandes organizações têm de lidar: registos bancários de 40 anos num mainframe antigo. Um dos meus clientes usa contêineres Kubernetes com padrões Circuit Breaker, além do Chaos Monkey, tudo para o aplicativo KeyBank. Mas, em última análise, esses contêineres se conectam a um aplicativo COBOL.
Os caras do Google estavam completamente confiantes de que resolveriam todos os problemas do meu cliente e então começaram a fazer perguntas: o que é o datapipe da IBM? Eles são informados: isto é um conector. A que ele se conecta? Para o sistema Sperry. E o que é isso? E assim por diante. À primeira vista parece: que tipo de DevOps pode existir? Mas, na verdade, é possível. Existem sistemas de entrega que permitem entregar o fluxo de trabalho às equipes de entrega.
3. Teoria das Restrições: Teoria das Restrições
Passemos ao terceiro arquétipo: o conhecimento institucional/“tribal”. Via de regra, em qualquer organização existem várias pessoas que sabem tudo e gerenciam tudo. São aqueles que estão há mais tempo na organização e conhecem todas as soluções alternativas.
Quando isso aparece no diagrama, eu circulo especificamente essas pessoas com um marcador: por exemplo, acontece que um certo Lou está presente em todas as reuniões. E está claro para mim: este é o Brent local. Quando o CIO escolhe entre eu de camiseta e tênis e o cara da IBM de terno, sou escolhido porque posso contar ao diretor coisas que o outro cara não contará e que o diretor talvez não goste de ouvir . Digo a eles que o gargalo na empresa é alguém chamado Fred e alguém chamado Lou. Esse gargalo precisa ser desfeito, o conhecimento deles precisa ser obtido deles de uma forma ou de outra.
Para resolver esse tipo de problema, posso, por exemplo, sugerir o uso do Slack. Um diretor inteligente perguntará - por quê? Normalmente, nesses casos, os consultores de DevOps respondem: porque todo mundo está fazendo isso. Se o diretor for muito esperto, ele dirá: e daí. E é aqui que o diálogo termina. E minha resposta para isso é: porque existem quatro gargalos na empresa, Fred, Lou, Susie e Jane. Para institucionalizar seu conhecimento, é necessário primeiro apresentar o Slack. Todos os seus wikis são um absurdo completo porque ninguém sabe de sua existência. Se a equipe de engenharia estiver envolvida no desenvolvimento front-end e back-end e todos precisarem saber disso, eles podem entrar em contato com a equipe de desenvolvimento front-end ou com a equipe de infraestrutura em caso de dúvidas. É quando Lou ou Fred provavelmente terão tempo para entrar na wiki. E então, no Slack, alguém pode perguntar por que, digamos, a etapa 5 não está funcionando. E então Lou ou Fred corrigirão as instruções no wiki. Se você estabelecer esse processo, muitas coisas se encaixarão por conta própria.
Este é o meu ponto principal: para recomendar quaisquer tecnologias de alta tecnologia, você deve primeiro colocar as bases para elas em ordem, e isso pode ser feito com as soluções de baixa tecnologia que acabamos de descrever. Se você começar com tecnologias de ponta e não explicar por que elas são necessárias, então, via de regra, isso não termina bem. Um de nossos clientes usa Azure ML, uma solução muito barata e simples. Cerca de 30% das dúvidas foram respondidas pela própria máquina de autoaprendizagem. E isso foi escrito por operadores que não estavam envolvidos em ciência de dados, estatística ou matemática. Isto é significativo. O custo desta 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 hostilidade. Se cada departamento estiver em seu próprio andar e as pessoas não se cruzarem de forma alguma, exceto no elevador, a hostilidade entre elas surge com muita facilidade. Mas se, pelo contrário, as pessoas estão na mesma sala, ela sai imediatamente. Quando alguém faz alguma acusação geral, por exemplo, tal ou qual interface nunca funciona, não há nada mais fácil de desconstruir tal acusação. Os programadores que escreveram a interface só precisam começar a fazer perguntas específicas, e logo ficará claro que, por exemplo, o usuário estava simplesmente usando a ferramenta de forma incorreta.
Existem muitas maneiras de superar o isolamento. Certa vez, fui solicitado a prestar consultoria para um banco na Austrália, mas recusei porque tenho dois filhos e uma esposa. Tudo que pude fazer para ajudá-los foi recomendar uma narrativa gráfica. Isso é algo que está comprovado que funciona. Outra forma interessante são as reuniões de café enxutas. Numa grande organização, esta é uma excelente opção para disseminar conhecimento. Além disso, você pode realizar devopsdays internos, hackathons e assim por diante.
5. Treinando Kata
Como avisei no início, não falarei sobre isso hoje. Se você estiver interessado, você pode dar uma olhada .
Há também uma boa palestra sobre este assunto de Mike Rother:
6. Orientada para o Mercado: organização orientada para o mercado
Existem problemas diferentes aqui. Por exemplo, pessoas “I”, pessoas “T” e pessoas “E”. Pessoas “eu” são aquelas que fazem apenas uma coisa. Normalmente eles existem em organizações com departamentos isolados. "T" é quando uma pessoa é boa em uma coisa, mas também em outras. “E” ou mesmo “pente” é quando uma pessoa possui muitas habilidades.
A lei de Conway funciona aqui (), que da forma mais simplificada pode ser enunciado da seguinte forma: se três equipes trabalharem no compilador, o resultado será um compilador de três partes. Portanto, se houver um alto nível de isolamento dentro de uma organização, até mesmo o Kubernetes, o disjuntor, a extensibilidade da API e outras coisas sofisticadas nesta organização serão organizados da mesma forma que a própria organização. Estritamente de acordo com Conway e para irritar todos vocês, jovens geeks.
A solução para este problema foi descrita muitas vezes. Existem, por exemplo, arquétipos organizacionais descritos por Fernando Fernandez. Essa arquitetura problemática de que acabei de falar, isoladamente, é uma arquitetura orientada a funções. O segundo tipo é o pior, arquitetura matricial, uma bagunça dos outros dois. O terceiro é o que se vê na maioria das startups, e grandes empresas também estão tentando se equiparar a esse tipo. É uma organização orientada para o mercado. Aqui otimizamos para obter a resposta mais rápida às solicitações dos clientes. Isso às vezes é chamado de organização plana.
Muitas pessoas descrevem esta estrutura de maneiras diferentes, gosto da expressão construir/administrar equipes, na Amazon eles chamam isso duas equipes de pizza. Nessa estrutura, todas as pessoas do tipo “I” são agrupadas em torno de um serviço, e aos poucos vão se aproximando do tipo “T”, e se houver a gestão adequada, podem até se tornar “E”. O primeiro contra-argumento aqui é que tal estrutura contém elementos desnecessários. Por que você precisa de um testador em cada departamento se pode ter um departamento especial de testadores? Ao que eu respondo: os custos extras neste caso são o preço para toda a organização se tornar do tipo “E” no futuro. Nessa estrutura, o testador aprende gradativamente sobre redes, arquitetura, design, etc. Como resultado, cada participante da organização está plenamente consciente de tudo o que acontece na organização. Se você quiser saber como esse esquema funciona na indústria, leia .
7. Auditores shift-left: auditam no início do ciclo. Cumprimento das regras de segurança em exposição
É quando suas ações não passam no teste do cheiro, por assim dizer. As pessoas que trabalham para você não são estúpidas. Se, como no exemplo acima, eles estabeleceram impacto menor/nenhum em todos os lugares, isso durou três anos e ninguém percebeu nada, então todos sabem perfeitamente que o sistema não funciona. Ou outro exemplo – um conselho consultivo de mudanças, onde os relatórios precisam ser apresentados todas as quartas-feiras, por exemplo. Tem um grupo de pessoas trabalhando lá (não muito bem remuneradas, aliás) que, em tese, deveria saber como funciona o sistema como um todo. E nos últimos cinco anos, você provavelmente notou que nossos sistemas são incrivelmente complexos. E cinco ou seis pessoas têm que tomar uma decisão sobre uma mudança que não fizeram e sobre a qual nada sabem.
É claro que esta abordagem não funciona. Tenho que me livrar dessas coisas porque essas pessoas não estão protegendo o sistema. A decisão deve ser tomada pela própria equipe, pois a equipe deve ser responsável por ela. Caso contrário, surge uma situação paradoxal quando um gerente que nunca escreveu código em sua vida diz ao programador quanto tempo deve levar para escrever o código. Uma empresa com a qual trabalhei tinha 7 conselhos diferentes que revisavam cada mudança, incluindo um conselho de arquitetura, um conselho de produto, etc. Houve até um período de carência obrigatório, embora um funcionário me tenha dito que em dez anos de trabalho ninguém nunca tinha rejeitado uma alteração feita por esta pessoa durante esse período obrigatório.
Os auditores precisam ser convidados a se juntar a nós e não se livrar deles. Diga a eles que você escreve contêineres binários imutáveis que, se passarem em todos os testes, permanecerão imutáveis para sempre. Diga a eles que você tem um pipeline como código e explique o que isso significa. Mostre a eles o seguinte esquema: um binário somente leitura imutável em um contêiner que passa em todos os testes de vulnerabilidade; e então ninguém toca nele, nem toca no sistema que cria o pipeline, já que ele também é criado dinamicamente. Tenho clientes, Capital One, que estão usando o Vault para criar algo como um blockchain. O auditor não precisa mostrar “receitas” do Chef, basta mostrar o blockchain, a partir do qual fica claro o que aconteceu com o ticket do Jira em produção e quem é o responsável por ele.
Conforme , criado em 2018 pela Sonatype, houve 2017 bilhões de solicitações de download de OSS em 87.
As perdas incorridas devido a vulnerabilidades são proibitivas. Além disso, os números que você vê acima não incluem custos de oportunidade. O que é DevSecOps em poucas palavras? Deixe-me dizer desde já que não estou interessado em falar sobre o sucesso desse nome. A questão é que, como o DevOps tem sido tão bem-sucedido, devemos tentar adicionar segurança a esse pipeline.
Um exemplo desta sequência:
Esta não é uma recomendação para produtos específicos, embora eu goste de todos eles. Citei-os como exemplo para mostrar que o DevOps, que inicialmente se baseou no paradigma organizacional da indústria, 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 em relação à segurança.
Total
Para finalizar, darei algumas dicas para DevSecOps. Você precisa incluir auditores no processo de criação de seus sistemas e dedicar tempo a educá-los. Você precisa cooperar com os auditores. Em seguida, você precisa travar uma luta absolutamente implacável contra os falsos positivos. Mesmo com a ferramenta de verificação de vulnerabilidades mais cara, você pode acabar criando hábitos extremamente ruins entre seus desenvolvedores se não souber qual é a sua relação sinal-ruído. Os desenvolvedores ficarão sobrecarregados com os eventos e simplesmente os excluirão. Se você ouviu falar da história da Equifax, foi exatamente isso que aconteceu lá, onde o nível de alerta mais alto foi ignorado. Além disso, as vulnerabilidades precisam ser explicadas de uma forma que deixe claro como elas impactam os negócios. Por exemplo, você poderia dizer que esta é a mesma vulnerabilidade da história da Equifax. As vulnerabilidades de segurança devem ser tratadas da mesma forma que outros problemas de software, ou seja, devem ser incluídas no processo geral de DevOps. Você precisa trabalhar com eles por meio de Jira, Kanban, etc. Os desenvolvedores não devem pensar que outra pessoa fará isso - pelo contrário, todos deveriam fazer isso. Finalmente, você precisa gastar energia treinando pessoas.
Links úteis
Aqui estão algumas palestras da conferência DevOops que podem ser úteis:
- Sergey Berdnikov, Artyom Kalichkin - História de sucesso, ou “Dev+DevOps+Ops” (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps em escala: uma tragédia grega em três atos (, )
- Alexander Titov, Kirill Tolkachev -
- Timóteo Lister
Investigar Devoops 2020 Moscou - também há muitas coisas interessantes lá.
Fonte: habr.com