A batalha pela velocidade é vencida na arena do DevOps

For software-intensive businesses, the fast, effective delivery of new offerings is not only a driver of competitive advantage but also a critical capability for long-term survival. This reality has prompted many companies to make substantial investments in DevOps , que inclui práticas, processos e ferramentas para melhorar a qualidade e a velocidade do ciclo de vida de desenvolvimento e integração de software. Infelizmente, até agora, esses investimentos não costumam se traduzir em resultados tangíveis que satisfazem as partes interessadas e clientes internos.

Em nosso trabalho com clientes, vimos em primeira mão os desafios que as empresas enfrentam ao aproveitar ao máximo seus investimentos em DevOps-e como esses esforços para melhorar o modelo operacional de entrega de software podem ter sucesso. O principal problema é que a maioria das empresas possui muitos silos e transferências no ciclo de vida do desenvolvimento (entre clientes e usuários, negócios, desenvolvimento, infraestrutura e operações e segurança) para atingir a velocidade necessária em seu desenvolvimento e integração de software. Para ajudar as empresas a investir efetivamente no DevOps, superar esses desafios e melhorar a velocidade para alcançar os resultados, sintetizamos nossa experiência em cinco princípios -chave para o sucesso.

Make Speed the Primary Metric

Broadly speaking, most companies invest in DevOps for three main reasons: Velocidade (às vezes emoldurado como tempo para o mercado), custo e qualidade. Mas, em nossa experiência, a velocidade é o fator mais crítico, porque, se bem feito, os outros dois se seguirão. A velocidade aumentada traz consigo agilidade e eficiência aprimoradas (que juntas reduzem os custos) e a capacidade de iterar e melhorar rapidamente (o que também aumenta a qualidade, desde que você tenha os processos de teste e feedback corretos). Uma definição melhor incorpora o tempo necessário para alcançar os resultados. Existem três princípios principais de velocidade:

Speed, or time to market, is sometimes too narrowly defined as time to deployment (meaning the time it takes to deploy a new feature in the market). A better definition incorporates the time needed to achieve outcomes. There are three core tenets of speed:

• Criando equipes persistentes orientadas a resultados que possuem esses resultados ao longo do tempo e são responsáveis ​​pelos ativos associados de ponta a ponta. Quando uma equipe está envolvida a longo prazo e é responsável, é mais provável que se concentre em metas de longo alcance, como melhorar a velocidade de entrega do produto. Outros princípios e corrimãos incluem a implementação da governança da arquitetura para manter o código atualizado (por exemplo, certificando o ciclo de vida de um componente para que nenhum componente passe por muito tempo sem refatorar), escolhendo quais ferramentas padronizarem em toda a cadeia de valor e determinar quanto depender o software como serviço (sAAS) para criar soluções. Pró. Outra vantagem é que, se um componente diminuir, ele não reduzirá todo o sistema, apenas um conjunto estreito de serviços ou recursos. Isso aumenta a velocidade do resultado, concentrando os controles de automação e confiabilidade nesses componentes, facilitando o gerenciamento do ciclo de vida; Ele também permite que diferentes equipes sejam implantadas em velocidades diferentes (em vez de serem limitadas pela parte mais lenta da cadeia). Além disso, é fundamental ativar e incentivar os desenvolvedores com uma variedade de práticas de treinamento e de desenvolvimento de DevOps (incluindo automação de testes, estratégia de ramificação adequada e alternância de recursos). Além disso, as empresas devem otimizar o modelo operacional para maximizar a qualidade e a velocidade das construções de recursos. Tudo isso requer governança eficaz e orientada a resultados.
• Developing principles and guardrails designed to increase productivity and ensure that problems don’t get baked into solutions early on. This requires introducing security, quality, and reliability engineering practices earlier in the development life cycle. Other principles and guardrails include putting architecture governance in place to keep code up to date (for example, by certifying the life cycle of a component so that no component goes too long without refactoring), choosing which tools to standardize throughout the value chain, and determining how much to rely on software as a service (SaaS) to craft solutions.
• Designing end-to-end services with self-contained components that individual teams can own. This enables a decoupled, microservices-style infrastructure and high degree of team-level autonomy and automation. Another advantage is that if a component goes down, it does not bring down the whole system, just a narrow set of services or capabilities. This drives speed to outcome by concentrating the automation and reliability controls within these components, making it easier to manage the life cycle; it also allows different teams to deploy at different speeds (rather than being limited by the slowest part of the chain).

To leverage these tenets and improve cycle time, companies must also provide tools and services that minimize waste during development (such as simplifying toolchains and adding self-serve DevOps capabilities). In addition, it’s critical to enable and incentivize developers with a variety of training and clear DevOps development practices (including test automation, proper branching strategy, and feature toggles). Moreover, companies should streamline the operating model to maximize the quality and speed of feature builds. All of this requires effective, outcome-oriented governance.

Focus on Continuous Learning and Improvement

DevOps should not be siloed in the Função de tecnologia . É um esforço de ponta a ponta que precisa incluir a participação tecnológica e da NOntech. O objetivo é melhorar os resultados dos negócios, integrando o aprendizado e a melhoria contínuos nas operações diárias em todas as funções e partes interessadas envolvidas no Ciclo de Vida de Desenvolvimento de Software (SDLC). A melhoria contínua é fundamental para qualquer empresa competir em velocidade e em escala - assim como uma equipe de pit de fórmula 1, deve melhorar constantemente o carro se a equipe tiver alguma esperança de vencer a corrida.

Para aplicar aprendizado contínuo à agilidade, eficiência e qualidade, a empresa deve elevar a importância de certos objetivos e os principais resultados (OKRs):

• Speed to improve business outcomes
• Costs spent on unnecessary or misaligned technology development
• Delivery quality, such as fewer bugs, lower security risk, and greater customer satisfaction

Uma boa maneira de medir se o compromisso de uma empresa com o aprendizado e a melhoria contínua é adequado é estudar o orçamento. Em nossa experiência, 10% a 20% do orçamento geral da tecnologia deve ser alocado para a melhoria contínua da produtividade da entrega. Esses investimentos do DevOps precisam se concentrar em três áreas principais:

• Aumentando os níveis de automação em todo o SDLC (Build, Teste, Implantar, Liberar, Monitoramento e Gerenciamento de Aplicativos ao vivo)
• Boosting the reusability of components and standardization of interfaces across the architecture
• Refactoring the architecture to make it more modular where necessary to improve speed to outcome

alcançar esse tipo de investimento focado, em nossa experiência, é muito desafiador se uma empresa ainda estiver trabalhando com um modelo de entrega centrado no projeto. Isso ocorre porque os projetos geralmente são financiados para o escopo, portanto, há um incentivo limitado para melhorar o modelo de entrega. Mas se as empresas não cometem o suficiente de seu orçamento de mudança para esses objetivos, não atingirão a velocidade prevista para o resultado necessário para competir no reino digital. As implicações são sentidas em toda parte.

Consider DevOps a Transformational Undertaking

DevOps done right is far more than a technology implementation involving processes and toolchains: it’s a transformational endeavor, involving the whole technology operation (and often the business), to improve the entire delivery model. The implications are felt far and wide.

Organization. A empresa deve decidir a melhor forma de apoiar e aumentar os recursos do DevOps. Isso significa determinar o que federar, certificando -se de que as equipes de desenvolvimento individuais tenham os recursos certos; E o que centralizar, garantindo que a função central tenha a capacidade de apoiar as equipes de desenvolvimento individuais, à medida que melhoram seus métodos de auto-serviço e auto-gerenciamento de seus ativos. O conceito -chave aqui é estabelecer o DevOps como uma plataforma, o que significa que as equipes centrais não são um serviço compartilhado. Em vez disso, eles se concentram na criação de recursos e serviços que as equipes de desenvolvimento individuais podem usar para aumentar sua produtividade (e, finalmente, o tempo do ciclo). Como resultado, o limite entre o desenvolvimento de aplicativos e as operações deve eventualmente quebrar e pertencer às equipes: “Você o constrói, você o executa; você o quebra, conserta -o.”

To a large extent, using DevOps to improve delivery productivity requires that companies manage the context of application development, management, deployment, and monitoring (instead of individual projects). By “context,” we mean all aspects that affect development, including management and leadership practices, the operating model, architectural guardrails, and tooling. Managing the context also allows for a more effective transfer of ownership and accountability so that it’s as close as possible to application development and operating teams, which in turn accelerates decision making—and fulfills the principles and promises of ágil.

Process. As empresas precisam simplificar sua estrutura de controle e governança para reduzir as transferências e pontos de contato ineficientes. Em vez de verificar e testar o código, os funcionários no ambiente DevOps devem gerenciar máquinas altamente automatizadas (que dependem de muitos ativos críticos de terceiros) que fornecem esses controles. Por exemplo, o modelo de engenharia de confiabilidade do site (SRE) possui regras claras, governança, práticas técnicas e operacionais para supervisionar a qualidade geral da pilha de tecnologia. (Veja a barra lateral, “Um banco global estabelece SRE”.) O desafio é gerenciar consistentemente os controles necessários em escala em uma pilha de aplicativos altamente fragmentada, incluindo qualidade geral (como modelos SRE), segurança (a “SEC” de DevSecops), bem como monitoramento contínuo da infraestrutura e aplicações vivas (AI para operações [AIOs], AIOs], para o Monitoring Continuous da Infraestrutura e Aplicações Livas (AI para operações [AII],

Applications and Infrastructure. As empresas precisam empurrar o desenvolvimento em uma pilha de tecnologia modular, pode ser implantada automaticamente e possui altos níveis de controles de qualidade automatizados (como os oferecidos pelos modernos provedores de nuvem de hoje). Isso requer forte coordenação e engajamento entre as equipes de desenvolvimento e operações para projetar e gerenciar a pilha de aplicativos e infraestrutura. As equipes de desenvolvimento assumem a responsabilidade de escolher e projetar a pilha, enquanto as equipes de operações se concentram mais em fornecer a pilha e seus elementos como uma capacidade de autoatendimento para as equipes de desenvolvimento.

Services and Capability Sourcing. É importante gerenciar a evolução de serviços de terceiros. Tomemos, por exemplo, quando uma empresa terceiriza a gestão da infraestrutura local ou suporte e manutenção de aplicativos. Nesses casos, a empresa e o parceiro de terceirização precisam desenvolver um plano para automatizar gradualmente esses serviços - e colocar os termos e incentivos contratuais para que isso aconteça, em vez de apenas espremê -los por custo. É também sobre dados. Orquestrar o fluxo de trabalho para gerenciar os pipelines de dados de IA complexos e aprendizado de máquina requer o mesmo rigor que o gerenciamento de código. Além disso, bons dados de teste são cruciais para garantir a eficácia do controle de qualidade em diferentes ambientes - incluindo a produção, as equipes de desenvolvimento, as equipes de teste e os usuários. Mas, em nossa experiência, os dados geralmente não recebem a atenção adequada nos esforços do DevOps focados no gerenciamento de configurações, na automação de testes e no desenvolvimento contínuo de software.

Don’t Leave Data Behind

DevOps is not just about code; it’s also about data. Orchestrating the workflow to manage complex AI and machine-learning data pipelines requires the same rigor as managing code. Moreover, good test data is crucial to ensure the effectiveness of quality control across different environments—including production, development teams, testing teams, and users. But in our experience, data often doesn’t get the proper attention in DevOps efforts focused on configuration management, testing automation, and continuous software development.

É importante alinhar melhorias no gerenciamento de dados com os DevOps e os esforços de arquitetura para garantir melhorias de ponta a ponta na velocidade. (Por exemplo, mesmo ao escolher pacotes comerciais de software no exterior que usam suas próprias lojas de dados para operar, as empresas precisam controlar seus próprios dados e não permitir que o fornecedor se torne o repositório mestre para dados do cliente.) Sem esse alinhamento, é difícil gerenciar dados de teste em diferentes ambientes de forma consistente. E se as equipes de dados forem forçadas a resolver esses problemas separadamente, o modelo de entrega se fragmentará. Por exemplo, às vezes os desenvolvedores são incertos sobre quais dados precisam ser registrados para fins de monitoramento de desempenho. Sua resposta é frequentemente se tornar excessivamente cautelosa sobre quais dados registrar-em alguns casos, sobrecarregar os serviços e a rede, criando problemas de latência e potencialmente instabilidade. Parceiros

DevOps guardrails and practices also have an impact on data. For example, developers are sometimes uncertain about what data needs to be logged for performance-monitoring purposes. Their response is often to become overly cautious about what data to log—in some cases, overloading the services and network, creating latency and potentially instability issues.

This is why it’s essential to consider early on how the end-to-end stack (architecture choices, data management, and tools to manage the stack) will work throughout the development life cycle and into live production.

Invest in People and Partners

Existe uma escassez geral de fortes talentos de engenharia (especialmente com os desenvolvedores modernos de desenvolvedores e nuvem). Mesmo quando as empresas podem encontrar um bom candidato externo, raramente encontram alguém que entende profundamente seu contexto de negócios, história e como impulsionar mudanças holísticas no modelo operacional da empresa. Portanto, além de lutar pelo talento externo certo, as empresas devem investir nas pessoas que já trabalham para elas, concentrando -se em treinamento e empoderamento.

Em nossa experiência, ter boas práticas de DevOps atrai talentos, enquanto a falta de um SDLC eficaz pode impulsionar o atrito. Trabalhamos com um cliente em que os desenvolvedores viram seu código entrar em contato com apenas uma semana e outro cliente, onde levou um ano. Não é de surpreender que o primeiro tenha conseguido contratar e reter talentos com muito mais facilidade. Infelizmente, esses contratos geralmente são gerenciados principalmente por custo. As empresas continuam pressionando as margens de seus fornecedores, reduzindo os incentivos de seus parceiros para investir ou cunhar em melhorias no modelo. Por exemplo, um fornecedor que fornece serviços de teste não tem incentivo inerente para automatizar esses serviços. Da mesma forma, se um parceiro fornecer manutenção e suporte de aplicativos, é provável que ganhe mais dinheiro quando a pilha funcionar mal. E se um fornecedor contratado para executar a infraestrutura for pago com base no uso, não estará inclinado a facilitar uma transição para serviços em nuvem ou racionalização de aplicativos, pois eles reduzirão o uso. O objetivo é criar progressivamente uma equipe que possa gerenciar a complexidade crescente (e às vezes pouco compreendida) das arquiteturas modulares e a infinidade de serviços e capacidades que vêm com a mudança para as paisagens de infraestrutura multicloud. É por isso que as transformações corporativas não podem tratar novas maneiras de trabalhar nos negócios e como empreendimentos separados. Empresas intensivas em software que implementam o AGILE sem um modelo operacional maduro de DevOps podem descobrir que sprints de duas semanas nos negócios podem ser prejudicadas por ciclos de liberação de software de nove meses. O DevOps é uma maneira de reunir negócios e tecnologia para realmente aumentar a velocidade do resultado, com a conseqüência sempre estimada de reduzir os custos e aumentar a qualidade. Andrew Agerbak

Companies also need to create incentives so that vendor partners will invest in continuous improvement—especially among the vendors supporting run services and managing legacy on-premises infrastructure. Unfortunately, these contracts are often managed primarily for cost. Companies keep pressuring their vendors’ margins, reducing their partners’ incentives to invest or coinvest in model improvements.

The service model itself can also discourage vendors from making these improvements. For example, a vendor providing testing services has no inherent incentive to automate these services. Similarly, if a partner provides application maintenance and support, it’s likely to make more money when the stack functions poorly. And if a vendor contracted to run the infrastructure is paid on the basis of usage, it won’t be inclined to facilitate a transition to cloud services or application rationalization since these will reduce usage.

Given these financial realities, companies need to think creatively about how to design contractual incentives to drive coinvestment in continuous improvement of the stack. The goal is to progressively create a team that can manage the increasing (and sometimes poorly understood) complexity of modular architectures and the plethora of services and capabilities that come with moving to multicloud infrastructure landscapes.

The delivery chain is only as fast as its slowest link. That’s why corporate transformations can’t treat new ways of working in business and IT as separate endeavors. Software-intensive businesses that implement agile without a mature DevOps-centric operating model may discover that two-week sprints in business can be hamstrung by nine-month software release cycles. DevOps is a way to bring business and technology together to truly boost speed to outcome, with the always-cherished consequence of reducing costs and increasing quality.