Como iniciar a transformação do DevOps

Se você não entende o que é o DevOps, aqui está uma pequena dica. O DevOps é um conjunto de práticas que reduzem os medos dos engenheiros e reduzem o número de falhas na produção de software. Como regra, eles também reduzem o tempo de colocação no mercado - o período entre a ideia e a entrega do produto final aos clientes, o que permite realizar rapidamente experimentos de negócios .

Como iniciar a transformação do DevOps? Em resumo: selecionamos o serviço a partir do qual iniciaremos o processo, identificamos aqueles que estão relacionados ao serviço, construímos o Mapa do Fluxo de Valor, criamos uma equipe temporária que lidará com a transformação pela primeira vez e definirá uma tarefa. Repetimos o ciclo quantas vezes for necessário.


Um plano detalhado de transformação do DevOps, com exemplos e instruções, está na decodificação do relatório de Andrei Alexandrov , engenheiro do Express42, que aconselha a germinação do DevOps, acelerando esse processo, porque ele já criou um mapa de rake. Se lhe parecer que você não precisa da transformação ou se possui detalhes específicos que as práticas de DevOps não são adequadas, use o relatório como uma instrução para encontrar e eliminar restrições.

Se você está preocupado com o problema da transformação do DevOps, possui uma empresa grande e precisa gradualmente escalonar esse processo para toda a estrutura. Desde que seja necessário transformar a equipe ou remover algum tipo de restrição, o algoritmo abaixo pode ser repetido.

Seleção de serviço

Delineamos um plano, comece com o primeiro passo - escolhendo um serviço. O primeiro critério é a vida útil : existem serviços antigos - herdados e novos. Você pode começar com esses e outros.

É lógico escolher um serviço jovem . É novo, não há um processo bem estabelecido de trabalhar em uma equipe que lide com isso. Ao seu redor, não há montes de dívidas técnicas, nem necessidade de repará-lo o tempo todo. Podemos fazer o que quisermos com ele.

No caso do serviço antigo, há problemas associados ao fato de que é sempre difícil mudar . Já existe um conjunto de restrições sérias, mas talvez as pessoas que estão prontas para estragar tudo estejam fazendo isso - elas estão cansadas e querem fazer algo diferente, porque dói.

Trabalhar com o serviço antigo cria um precedente poderoso em sua empresa - você pode mudar alguma coisa. Se você alterar um novo serviço, ele rola para produzir 100 vezes por hora, e está tudo bem, então as pessoas na sua empresa podem dizer:

- Este é um novo serviço! Tudo era simples lá, tente fazer algo com nossas coisas cafetonas.

Faz sentido transformar um serviço Legacy em uma transformação quando você faz isso com alguém, por exemplo, se você convidou um consultor externo. Sejamos honestos, a transformação escalonará tudo o que for possível . Você está experimentando e não sabe de onde virá, quais tecnologias e por que usará, onde e quais armadilhas surgirão nos processos. Portanto, uma nova mudança é mais fácil.

Se você faz tudo sozinho, mas a empresa não possui competência séria, tomamos um novo serviço. Se você conhece um consultor externo e há fundos - escolha o antigo.

Existem serviços que são apenas uma interface para os usuários, por exemplo, um site simples ou um aplicativo móvel. Mas há coisas sérias no espírito da cobrança. Se algo der errado com o faturamento, será difícil entender. Aqui também temos uma escolha.

Trabalhamos com um serviço crítico , mas já sofremos por causa dele, ele cria restrições ou trabalhamos com a interface . Este é o segundo critério de seleção. Da mesma forma, é possível atrair um consultor experiente - trabalhamos com uma opção difícil.

Mas mesmo neste caso, eu não recomendaria fazê-lo, porque, embora não haja entendimento sobre o que trabalhar e como transformar, pegar uma coisa crítica e sacudi-la não é uma boa ideia. Portanto, neste caso, preferimos trabalhar com uma interface cuja falha não é crítica.

Em seguida, considere o comando service . Com aqueles que estão envolvidos neste serviço, teremos que trabalhar constantemente e interagir em contato muito próximo.

As pessoas da equipe são condicionalmente divididas em duas categorias: conservadores - eles vivem no mundo antigo ou simplesmente não sabem nada sobre o DevOps e inovadores que adotam todas as práticas da moda. Os últimos nem sempre entendem o tópico, mas pelo menos estão prontos para isso.

Por um lado, os conservadores são pessoas experientes: estão na empresa há muito tempo, entendem completamente, mas não conhecem apenas práticas. Por outro lado, há inovadores que ouviram alguma coisa, mas provavelmente trabalharam para a empresa há não muito tempo. Com qual deles é melhor trabalhar?

De qualquer forma, você terá que interagir com os conservadores, pois esse é o serviço deles. Teremos que nos comunicar com eles, descobrir as especificidades do serviço, o que pode ser feito dessa maneira e o que é diferente. Dependemos de seus conselhos. Certamente eles terão que confiar algo, porque conhecem melhor seus serviços. Portanto, é importante com qual equipe entraremos em contato.

É lógico escolher uma equipe inovadora, porque os conservadores podem colocar um porco.

Na prática, muitas vezes acontece que pessoas conservadoras têm uma experiência significativa, mas não há entendimento de como viver. Eles simplesmente têm medo de que, após a transformação e alteração do serviço, sejam descartados como desnecessários. Às vezes, simplesmente por falta de entendimento do que está acontecendo, eles sabotam o trabalho.

Tive um caso em que um cara de uma equipe reparou alguma coisa, porque é supostamente mais crítico do que o que estamos fazendo agora. Nós estabelecemos a tarefa: realizar esta peça hoje - não, há um incêndio do outro lado do mundo, vamos consertá-la. É difícil trabalhar com essas pessoas.

As pessoas da equipe conservadora costumam entupir as tarefas ou adiar até a última. E se John Willis salvou você, você cometeu um erro e os pendurou no KPI pelo número de tarefas concluídas, e por alguma razão algumas delas não foram incluídas no KPI, elas não farão nada. Em geral, eles terão razão, porque perderão o bônus.

É mais fácil com os inovadores - eles são mais leais . Eles já ouviram algo, querem ir a algum lugar, para ajudarem. Precisamos de pessoas prontas para sofrer pela primeira vez: se o serviço mudar, todos os cones e ancinhos serão capturados pelos inovadores como pioneiros. Os inovadores querem o mais novo e o mais elegante, e sofrem.

Conservadores podem mais tarde ser convertidos. Quando você mostra que mudou uma peça e tudo funciona bem, provavelmente eles também querem tentar adotar a nova religião do DevOps.

Para resumir. Se fizermos toda a transformação em nossa empresa, escolheremos: um novo serviço, de preferência uma interface simples, para não sofrer muito com a quebra, e uma equipe de inovadores.

Se for possível ligar para um consultor externo, em vez de um novo, prestamos o serviço antigo, pelo qual já estamos sofrendo. Pessoas que estão envolvidas na transformação há bastante tempo em empresas diferentes já viram casos diferentes e já entendem como fazer isso da maneira certa e que caminho seguir em geral.

Quem está envolvido?

Em geral, precisamos encontrar todos que tenham pelo menos algo a ver com o serviço: desenvolvedores, testadores, administradores, guardas de segurança, gerentes e possivelmente Proprietários de Produtos. Apesar do fato de os Product Owners não serem técnicos, eles estão relacionados ao serviço: tomar uma decisão, definir uma tarefa.

Todo mundo que toma pelo menos algumas decisões e influencia o que está acontecendo com o serviço precisa encontrar, conhecer e conversar.

O que eles são para nós? Saber com quem negociar . Durante a transformação, quando o princípio usual de trabalhar com o serviço mudar, ele tremerá de qualquer maneira. Haverá falhas por um tempo enquanto testamos novas abordagens. As pessoas devem estar preparadas para isso e concordar com isso.

Então você precisa criar um mapa do fluxo de valor e, sem essas pessoas, não pode construí-lo, porque somente todos eles sabem o que está acontecendo. Uma pessoa nunca sabe tudo o que acontece com o serviço.

Eles aconselharão as pessoas da equipe e, posteriormente, discutiremos por que uma equipe separada é necessária. Terá de levar pessoas de departamentos existentes. Aqueles que estão relacionados ao serviço poderão recomendar colegas que pensam em nossa direção, que podem nos ajudar e ter a competência no que precisamos.

Depois, reunimos todas essas pessoas de diferentes departamentos em uma sala e começamos a criar um Mapa do Fluxo de Valor.

Construindo um mapa de fluxo de valor

Mapa do Fluxo de Valor é um diagrama ou mapa que mostra o fluxo de valores para o cliente . Esse é todo o processo, desde a invenção de uma idéia até sua implementação, incluindo todos os estágios intermediários e como o valor finalmente chega aos nossos clientes.

O Mapa do Fluxo de Valor é necessário para visualizar todos os estágios do desenvolvimento , localizar problemas através de medições que estão no processo atual e começar a eliminar esses problemas e definir uma meta inicial . Este é o lugar onde começaremos a realmente fazer alguma coisa.

Métricas

Existem muitas métricas diferentes descritas na literatura do Mapa do fluxo de valor, mas para iniciantes, precisamos apenas de três.

Lead Time - delay / wait - o tempo em que esperamos por algo. Por exemplo, o testador espera até que o suporte de teste seja liberado e não pode fazer nada no momento.

Tempo de valor agregado - o tempo de trabalho útil - aquele que gastamos nesse momento para criar o valor final para o usuário. Por exemplo, um testador executou seu teste e começou a testar algo. Este é o momento do trabalho útil em que realmente fazemos algo pelo produto. É para isso que os clientes pagam - por um software de qualidade.

% C / A - porcentagem de trabalho aceito. Temos um estágio - desenvolvimento, o segundo estágio - teste. Quantos recursos os testadores utilizaram dos desenvolvedores e existe essa porcentagem.

É assim que nosso mapa se parece.



Pode parecer diferente dependendo da estrutura da organização, do número de departamentos e do que você faz. Mas, no caso geral, o mapa terá dois estágios: uma ideia e uma análise . Nesse momento, os dados são esperados, por exemplo, Lead Time 2 semanas e Value Added Time 2 dias.

As métricas cobrem absolutamente todas as etapas.

Lista de pendências - quantas tarefas existem depois que os analistas as criaram.

Desenvolvimento - há quantas semanas os desenvolvedores aguardam esclarecimentos sobre tarefas, estandes ou equipamentos - isso não importa, mas eles estão esperando por algo. Por exemplo, eles implementam um recurso por 4 dias. A métrica% C / A aparece aqui. Os desenvolvedores executaram apenas 80% das tarefas do Backlog. Eles acreditam que os 20% restantes não possuem TK claro e os enviaram para revisão.

Teste . No esquema LT, quatro dias são definidos. Por exemplo, os testadores aguardavam a liberação do banco de testes, VA por 2 dias, eles realmente estão testando alguma coisa e% C / A = 40%. - apenas 40% do código ou recursos enviados pelos desenvolvedores foram considerados adequados pelos testadores. Eles não gostaram do resto por algum motivo.

Não vou me debruçar sobre como realizar essas medições. No final do artigo, recomendarei literatura a partir da qual você pode aprender sobre elas.

A única coisa que aconselho é não acreditar nas pessoas que irão compor o mapa do fluxo de valor com você. Eles representam quanto tempo os diferentes processos levam, mas essas estimativas nem sempre são corretas; portanto, é melhor medir a si mesmo.

Tivemos um caso quando chegamos ao departamento de Operações e perguntamos quanto tempo leva para entregar um novo recurso à produção. Eles responderam 10 minutos e pensamos: por que viemos a esta empresa? Acontece que 10 minutos é o tempo de execução do script, que pega o código e o entrega ao servidor. Porém, antes disso, a versão fica três dias no servidor e apenas acumula poeira - no Backlog está a tarefa que precisa ser implantada. Acontece que, antes do estágio de implantação, há um estágio de espera quando o projeto simplesmente se encontra. Se não tivéssemos ido com um caderno, não tivéssemos visto uma tarefa em Jira e não tivéssemos começado a rastreá-lo em etapas, teríamos pensado que tudo era maravilhoso e não havia problema.

Portanto, as medições ainda terão que ser feitas por você mesmo, de preferência mais de uma vez, a fim de ter uma representação próxima da realidade. Dependendo do mapa do fluxo de valor, você decidirá por onde começar e o que corrigir primeiro.

Equipe temporária

Muitas empresas que decidiram introduzir o DevOps criam uma equipe, não apenas temporária, mas existente há vários anos. Se você for ao serviço de desculpas do DevOps, que descreve os diferentes padrões para criar uma estrutura organizacional no DevOps, entenderá que esse é um antipadrão.

Quando a equipe do DevOps existe continuamente há vários anos, isso é um grande erro, porque o DevOps é sobre comunicação entre departamentos, velocidade e eficiência.

Se existe uma equipe entre departamentos, apenas para fazer outra coisa separada e existe por um longo tempo, isso cria uma barreira extra. Agora, em vez de ir diretamente ao administrador, o programador precisa primeiro entrar em contato com o departamento de DevOps e ele irá além.

Portanto, para começar, você precisa criar uma equipe temporária . Ele permanecerá por um período suspenso de seis meses, no máximo um ano, dependendo da tarefa, apenas para eliminar uma limitação que escolhemos. Então ela vai morrer. Se escolhermos o próximo ponto em que dói muito e entendermos que também precisamos de uma equipe separada para isso, então o criaremos novamente. Mas essas equipes não deveriam existir "de forma permanente" - então elas apenas interrompem a comunicação e assumem tarefas separadas em geral, apenas para fazer alguma coisa. Essas tarefas podem não estar relacionadas ao DevOps ou à transformação. Por que não entregamos essa tarefa aos departamentos existentes?

Por que você precisa de uma equipe temporária

Conflito com os processos atuais . A transformação do DevOps é uma mudança não apenas das tecnologias e ferramentas que usamos, mas também do processo de trabalho, pensamento e valores. Se a equipe trabalha como costumava, não poderá tentar outras abordagens.

Essas pessoas devem viver de acordo com regras diferentes: ignore todos os KPIs da empresa, porque eles tentam trabalhar de maneira diferente. As equipes temporárias não preencherão os aplicativos para obter um servidor, mas irão diretamente para o departamento que os gerencia, exigindo que sejam os primeiros a fornecer o que precisam, porque essa é uma tarefa prioritária e porque eles tentam viver de maneira diferente. A equipe tem um conflito completo com todos os processos atuais. Para que os métodos de trabalho existentes não interfiram com eles agora e eles não interfiram com os outros, isolamos essas pessoas destacando-as como uma equipe separada.

Evitando a burocracia em experimentos . Não há burocracia nas equipes temporárias; elas não preenchem relatórios sobre o horário de trabalho; elas não se reportam aos gerentes. Este é um mundo completamente separado, no qual as pessoas vivem e pensam de maneira diferente, e fazem coisas completamente diferentes. Não os incomode mais uma vez.

Trabalho sem parar no serviço . No primeiro parágrafo, escolhemos algo para experimentar. Experimentar e encontrar maneiras de trabalhar melhor é bom, mas também queremos fazer recursos. Se toda a equipe se engajar na transformação em vez de nos recursos, começaremos a perder receita, os bugs travarão por muito tempo - não precisamos disso. Criar uma equipe temporária permite experimentar sem interromper o trabalho no produto.

Não perca tempo com tarefas de trabalho . Isso é novamente sobre o produto. Leva muito tempo para a equipe experimentar outras ferramentas e outras coisas. Para que as pessoas dominem as ferramentas, comecem a implementá-las e a utilizá-las normalmente, levará pelo menos seis meses. Se eles também lidam com o produto - seis meses se estendem cosmicamente. Se as pessoas estão envolvidas em um produto, elas novamente trabalham com processos antigos - não precisamos disso.

Portanto, separamos pessoas de departamentos diferentes em uma equipe separada que lidará com a transformação do serviço. Como resultado, o serviço funciona, continua a se desenvolver e, ao mesmo tempo, colocamos algumas experiências nele.

A equipe temporária está envolvida apenas na transformação do DevOps - eliminando a restrição que encontramos e nada mais.

A equipe é composta por pessoas universais . Isso significa que pegamos não apenas desenvolvedores. Não fomos ao serviço e não levamos meia equipe de lá - não, levamos pessoas de diferentes departamentos . Alguns pontos atrás, encontramos diferentes departamentos e funcionários diferentes relacionados ao serviço de transformação. Destes, estamos recrutando uma equipe, porque ela deve ser universal - mudaremos o processo de teste, o processo de desenvolvimento e o processo de manutenção do serviço. São necessárias competências diferentes.

Em geral, contratamos condicionalmente um desenvolvedor, testador e engenheiro - cada um de cada vez e, juntos, criamos uma solução que permite que você viva de maneira diferente.

É desejável que essas pessoas tenham autoridade na organização . Você pode ter que tomar um conservador, embora não queira. Se tivermos uma empresa grande, nem todo mundo acreditará em nosso empreendimento, e alguém pode colocar palitos nas rodas, por exemplo, para não destacar uma posição. Aqui você precisará de "autoridade" - uma pessoa respeitada com vasta experiência, que merece uma boa atitude dos colegas. A autoridade do funcionário da equipe simplificará a tarefa e o trabalho da equipe temporária. As pessoas vão pensar:

- Sim, esse cara legal que todos conhecemos e amamos se encaixa - aparentemente, o DevOps tem algo que vale a pena olhar!

Estabelecemos uma meta

Reunimos pessoas, escolhemos um serviço, analisamos as restrições, determinamos em quais pessoas influenciaremos. Agora você precisa definir uma meta e ela deve estar certa na SMART - é tudo o que amamos.

Específico - específico .

Mensurável - mensurável . Este é um ponto muito importante da SMART. Se você não pode medir algo, não pode mudá-lo e entender o que e como você fez melhor ou pior.

Realizável é realizável . Ajuste para suas especificidades. Se você é uma empresa corporativa com um longo histórico e um grande fardo de responsabilidades, que libera uma versão do produto uma vez por ano, não poderá obter o lançamento de novas versões do produto a cada hora em seis meses. Não vai funcionar dessa maneira. Portanto, defina uma meta real que seja alcançável em um período aceitável.

Relevante - Relevante. Apenas eliminamos a limitação que realmente persegue nossos objetivos atuais.

Tempo Limitado - tempo limitado . Se não houver prazo, a equipe fará qualquer coisa: tente 15 tecnologias em vez de 3, escreva relatórios enormes, faça pesquisas inúteis, liquefeita sua implementação quando o objetivo já for alcançado.

Assumimos o objetivo com a ajuda do Mapa do Fluxo de Valor - novamente coletamos todas as pessoas e desenhamos. Mas só agora, com base no mapa anterior do fluxo de valor, desenhamos o que queremos obter.



Destacamos uma limitação que vamos eliminar agora - é isso que a equipe fará. Como exemplo, tomei a expectativa de uma versão finalizada para sua implantação na produção - essa é a limitação mais comum que as pessoas recorrem aos consultores.

Com base nisso, definimos a tarefa: queremos que a espera entre um lançamento pronto e a entrada em ação seja de no máximo uma hora.

Exemplos de tarefas.

• Reduza o teste do lead time de 4 dias para 1 hora.
• Reduza o tempo de valor agregado para testes de 2 dias para 3 horas.
• Reduza a implantação do lead time de 5 horas para 10 minutos.
• Aumente o C / A de 50% para 95%, ou seja, aumente o número de recursos aceitos pelos testadores, ou seja, melhore a qualidade dos desenvolvedores.

Exemplos de tarefas não são retirados da cabeça - eles são baseados nas medições que fizemos ao desenvolver o Mapa do Fluxo de Valor.

Estabelecemos uma tarefa semelhante à nossa equipe e um limite de tempo. , , . , , , .

, , , . — : - , , .

, moving-moving , , , . : , , , , , .

.

- : , , , — ? , , : , - . 1-2 .

- , — , - . : , DevOps, . , .

Porque , , , , , , , DevOps. , .

, , — , ! , , - . , , , , . , , , - .

, — . , - .

, — , . , - Value Stream Map , , .

, . Value Stream Map , , . , . SMART — , , .

, .

.

, DevOps .

«»

— «The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win». DevOps — , , . :

— , , .

« “”. , DevOps » — , , . , — . , .

DevOps

. «The DevOps Handbook How to create world‑class agility, reliability, and security in Technology organizations», . handbook — : , Value Stream Map , , . , . , .

, , Value Stream Map , , , , . , , , , . : Value Stream Map , .

Accelerate

: «Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations». — . , . — Nicole Forsgren, Jez Humble Gene Kim — , , .

, , Value Stream Map, , , , . . , , , . , «Accelerate». , , , , , — , .

— DevOps . - , , DevOpsConf , – QaulityConf . ++ Whale Rider — . 27 28 , .