Share via

Compromissos de Excelência Operacional

  • Artigo

A Excelência Operacional proporciona qualidade da carga de trabalho através da implementação de padrões de equipa claros, responsabilidade e responsabilidade compreendidas, atenção aos resultados dos clientes e coesão da equipa. A implementação destes objetivos está enraizada no DevOps, que recomenda minimizar a variância do processo, reduzir o erro humano e, em última análise, aumentar o retorno do valor para a carga de trabalho. Esse valor não é medido apenas em relação aos requisitos funcionais servidos pelos componentes da carga de trabalho. Também é medido pelo valor que a equipa oferece na luta por melhorias.

Durante a fase de conceção de uma carga de trabalho e ao longo do seu ciclo de vida, à medida que são realizados passos de melhoria contínua, é importante considerar como as decisões baseadas nos princípios de design de Excelência Operacional e as recomendações na lista de verificação de revisão de design para Excelência Operacional podem influenciar os objetivos e otimizações de outros pilares. Determinadas decisões podem beneficiar alguns pilares, mas constituem compromissos para outros. Este artigo descreve as desvantagens de exemplo que uma equipa de carga de trabalho pode encontrar ao conceber a arquitetura e as operações da carga de trabalho.

Compromissos de Excelência Operacional com Fiabilidade

Desvantagem: maior complexidade. A fiabilidade prioriza a simplicidade, uma vez que o design simples minimiza a configuração incorreta e reduz interações inesperadas.

  • Muitas vezes, as estratégias de implementação segura requerem alguma compatibilidade entre a lógica da aplicação e os dados na carga de trabalho. Esta complexidade adicional aumenta a carga de teste e pode levar a problemas de complexidade ou integridade com os dados da carga de trabalho.

  • A infraestrutura altamente em camadas, modularizada ou parametrizada como código pode aumentar a probabilidade de uma configuração incorreta acidental devido à complexidade da interação entre os componentes de código.

  • Por vezes, os padrões de conceção da cloud que beneficiam as operações exigem a introdução de componentes adicionais, por exemplo, a utilização de um arquivo de configuração externo ou a coordenação de implementações de sidecar numa plataforma de aplicações em contentores. Os componentes adicionais aumentam os pontos de interação no sistema, aumentando a área da superfície para avarias ou configuração incorreta.

  • Os componentes da carga de trabalho concebidos para evoluir de forma independente para suportar o desenvolvimento ágil e o alojamento introduzem dependências na deteção de serviços ou mesmo no DNS como uma camada de indireção. A deteção de serviços pode não ter capacidade de resposta para alterar e o mau funcionamento pode ser difícil de diagnosticar.

Compromisso: Aumento das actividades potencialmente desestabilizadoras. O pilar Fiabilidade incentiva a prevenção de atividades ou escolhas de conceção que podem desestabilizar um sistema e levar a interrupções, interrupções ou avarias.

  • A implementação de pequenas alterações incrementais é uma técnica para mitigar o risco, mas também se espera que essas pequenas alterações sejam fornecidas à produção com mais frequência. As implementações podem desestabilizar um sistema, pelo que, à medida que a taxa de implementação aumenta, este risco também aumenta.

  • Uma cultura que se mede com métricas de velocidade como implementações por semana e utiliza automatização que pode facilitar a introdução de alterações a um ritmo mais rápido também é susceptível de realizar mais implementações num período mais curto.

  • Aumentar a densidade para simplificar as operações ao reduzir o número de superfícies de controlo e observabilidade também pode levar a um aumento do risco de disponibilidade porque o mau funcionamento ou a configuração incorreta aumenta o raio de impacto de um evento desestabilizador.

Compromissos de Excelência Operacional com a Segurança

Desvantagem: área de superfície aumentada. O pilar Segurança recomenda uma área de superfície de carga de trabalho reduzida em termos de componentes e exposição a operações. Esta redução minimiza os vetores de ataque e produz um âmbito mais pequeno para controlo e teste de segurança.

  • Os componentes que rodeiam a carga de trabalho e suportam as respetivas operações, como a automatização ou um plano de controlo personalizado, também têm de estar no âmbito de proteção e teste de segurança regulares.

  • As operações de rotina, ad hoc e de emergência aumentam os pontos de contacto com a carga de trabalho. Uma abordagem de confiança zero requer que estes processos sejam considerados vetores de ataque e têm de ser incluídos nos controlos de segurança e na validação da carga de trabalho.

  • A plataforma de observabilidade do sistema recolhe registos e métricas sobre a carga de trabalho, o que pode ser uma fonte valiosa de divulgação de informações. Por conseguinte, a segurança da carga de trabalho tem de ser alargada para proteger os sinks de dados contra ameaças internas e externas.

  • Os agentes de compilação, a configuração externa e os arquivos de alternar de funcionalidades e as abordagens de implementação lado a lado aumentam a área de superfície da aplicação que requer segurança.

  • Uma maior frequência de implementação causada por pequenas alterações incrementais ou pelos esforços "ficar atualizado, manter-se atualizado" resulta em mais testes de segurança no ciclo de vida de desenvolvimento de software.

Compensação: maior desejo de transparência. Uma carga de trabalho segura baseia-se em designs que protegem a confidencialidade dos dados que fluem através dos componentes do sistema.

As plataformas de observabilidade ingerem dados de todos os tipos para obter informações sobre o estado de funcionamento e o comportamento de uma carga de trabalho. À medida que as equipas tentam obter maior fidelidade nos dados de observabilidade, existe um risco acrescido de os controlos de classificação de dados, como a máscara de dados, dos sistemas de origem não se estenderem aos registos e sinks de registo da plataforma de observabilidade.

Desvantagem: segmentação reduzida. Uma abordagem de segurança fundamental para isolar o acesso e a função é conceber uma estratégia de segmentação forte. Esta estrutura é implementada através do isolamento de recursos e controlos de identidade.

  • A colocalização de componentes de aplicações diferentes em recursos de computação, rede e dados partilhados para facilitar a gestão inverte a segmentação ou dificulta a obtenção da segmentação baseada em funções. Os componentes colocalizados também podem precisar de partilhar uma identidade de carga de trabalho, o que pode levar à sobreaplicação de permissões ou à falta de rastreabilidade.

  • Recolher todos os registos de todo o sistema num sink de registo unificado pode facilitar a consulta e a criação de alertas. No entanto, fazê-lo também pode tornar mais difícil ou impossível fornecer segurança baseada em linhas para tratar dados confidenciais com os controlos de auditoria necessários.

  • Simplificar a gestão da segurança baseada em atributos ou baseada em funções ao reduzir a granularidade das funções e respetivas atribuições pode levar a permissões inadequadamente amplas.

Compromissos de Excelência Operacional com a Otimização de Custos

O pilar Excelência Operacional nunca recomenda atividades que reduzam a produtividade ou comprometam o retorno de uma carga de trabalho sobre o investimento. As recomendações que parecem mudar o foco das atividades de entrega têm em conta os melhores interesses a longo prazo para a carga de trabalho e a equipa. Se a sua carga de trabalho estiver a aproximar-se da data do pôr-do-sol, provavelmente não faz sentido investir altamente em recomendações que desencadeiem estas desvantagens.

Desvantagem: aumento das despesas com recursos. Um fator de custo importante para uma carga de trabalho é o custo dos respetivos recursos. A implementação de menos recursos, o dimensionamento correto dos recursos e a redução do consumo geralmente ajudam a manter os custos baixos.

  • A implementação de práticas de implementação segura, mesmo que as alterações sejam relativamente pequenas, pode levar a um aumento do número de recursos implementados em simultâneo. Estes padrões requerem a implementação de várias instâncias simultâneas da aplicação ou componente de infraestrutura para que o tráfego possa ser deslocado de forma controlada. Este aumento é mais pronunciado numa carga de trabalho que utiliza uma abordagem de infraestrutura imutável.

  • A equipa poderá ter de introduzir componentes de carga de trabalho adicionais para implementar padrões de conceção da cloud ou automatização de cargas de trabalho operacionalmente alinhados. Por exemplo, para suportar a agilidade da implementação, podem adicionar um componente de encaminhamento de gateway. Para suportar uma melhor gestão da configuração, podem adicionar um arquivo de configuração externo. Para suportar eventos de ciclo de vida do inquilino, podem criar um plano de controlo. Estes recursos também influenciam os custos dos ambientes de pré-produção.

  • Aumentar o número de ambientes de pré-produção para melhorar a experiência de desenvolvimento e teste através do isolamento também aumenta o número de recursos. Estes recursos, que não são utilizados para fornecer oferta face à procura de produção, aumentam o custo da solução.

  • Aumentar a paridade dos ambientes de pré-produção com o ambiente de produção, em termos de contagem de recursos, SKUs e volumes de dados, melhora o processo de garantia de qualidade. O custo aumenta à medida que a paridade aumenta.

  • Embora os dados telemétricos não sejam diretamente um recurso, para permitir a eficácia das plataformas de observabilidade, estes dados têm de ser mantidos. A maioria dos arquivos de dados operacionais tem preços baseados numa combinação de taxas de ingestão e volume. Geralmente, à medida que a quantidade de telemetria de baixa latência e de alta diversidade aumenta, os custos também aumentam. Para implementações de várias regiões, espera-se que estes sinks de dados operacionais sejam implementados por região, pelo que todos os custos por recurso se tornam um fator.

Compromisso: diminuição do foco nas atividades de entrega. Os membros da equipa de cargas de trabalho fornecem um maior valor de carga de trabalho ao realizarem tarefas alinhadas com as respetivas capacidades de forma eficiente.

  • As equipas de cargas de trabalho que passam tempo a criar e refinar uma estrutura de suporte e resposta a incidentes em bom estado de funcionamento e responsável estão a fornecer um serviço valioso aos utilizadores da carga de trabalho. À medida que o esforço de suporte aumenta (por exemplo, rotações formais de chamadas), normalmente devido a uma alteração da importância da empresa, os custos destas atividades aumentam. Este aumento de custos pode ser o resultado de um aumento de pessoal ou pode ser incorrido indiretamente sob a forma de atenção que passou de atividades de entrega para funções de suporte.

  • A formação é uma parte fundamental do processo de melhoramento contínuo pessoal de uma equipa de carga de trabalho. Esta formação pode ser formal ou auto-direcionada durante o tempo de melhoramento pessoal. À medida que a quantidade de tempo de preparação aumenta, a quantidade de tempo disponível para o desenvolvimento direto da carga de trabalho diminui. O investimento na formação diminui quando a formação não é baseada em funções ou é especificamente relevante para a carga de trabalho ou o seu futuro.

  • As tarefas operacionais de rotina padronizadas para proteger a fiabilidade, a segurança e a eficiência de desempenho de uma carga de trabalho demoram algum tempo a definir, refinar e executar. Este tempo não é gasto diretamente na entrega. Alguns exemplos destas tarefas são análise abrangente de impacto de alterações, processos de controlo de alterações, testes minuciosos e gestão de patches aumentada. À medida que a frequência, a integralidade ou a carga operacional destas tarefas aumentam, o tempo investido também aumenta.

Desvantagem: aumento das exigências de ferramentas e diversidade. O pilar Otimização de Custos recomenda a redução da expansão de ferramentas, a consolidação de fornecedores e uma abordagem de tamanho certo para todas as compras de ferramentas.

Uma equipa de carga de trabalho compra ferramentas e hardware para suportar atividades que são executadas durante todo o ciclo de vida de desenvolvimento de software (SDLC), incluindo planeamento e design, desenvolvimento e testes e monitorização. O marketplace para ferramentas neste espaço está a crescer. As ferramentas são oferecidas a vários pontos de preço que normalmente correspondem às funcionalidades e capacidades das ferramentas. Com exceção das ofertas gratuitas, estas ferramentas incorrem em custos iniciais de licenciamento, que podem ser por assento ou site. Muitas vezes, também necessitam de contratos de manutenção contínuos. Poderão ter de ser estabelecidas novas relações de fornecedor. Eis alguns exemplos de ferramentas ou despesas de hardware esperadas que estão associadas aos princípios de excelência operacional:

  • Requisitos e gestão de atrasos
  • Ferramentas de design de arquitetura
  • Ferramentas de estrutura da IU/UX
  • Alojamento de código e recursos
  • Ambientes de desenvolvimento de código e pouco código
  • Ferramentas de automatização
  • Estações de trabalho de desenvolvimento e garantia de qualidade
  • Pipelines de desenvolvimento e implementação
  • Teste a execução e o controlo
  • Ferramentas de observabilidade

Compromissos de Excelência Operacional com Eficiência de Desempenho

Desvantagem: aumento da utilização de recursos. O pilar Eficiência de Desempenho recomenda a alocação do máximo possível de computação e rede disponíveis para os requisitos da carga de trabalho.

  • A arquitetura de observabilidade de uma carga de trabalho requer que os componentes na arquitetura atribuam tempo e recursos para criar, recolher e transmitir registos e métricas. Estes pontos de dados ajudam a garantir que os alertas e a monitorização eficazes são possíveis para fiabilidade, segurança e desempenho. À medida que o nível de instrumentação aumenta, a pressão sobre os recursos do sistema também pode aumentar.

  • Alguns modelos de implementação, como a implementação azul/verde, que uma carga de trabalho pode utilizar para uma implementação segura, podem introduzir implementações lado a lado na plataforma de aplicações de produção. Estas implementações requerem dimensionamento preventivo para fornecer oferta suficiente para satisfazer a procura futura ou deixar uma implementação quase inativa durante um período de tempo para suportar a reversão.

Desvantagem: aumento da latência. Para criar cargas de trabalho de desempenho, as equipas procuram formas de reduzir o tempo e os recursos que as cargas de trabalho consomem para realizar as suas tarefas.

  • Muitos modelos de implementação requerem a utilização de padrões de acesso de encaminhamento de gateway, o que pode introduzir latência. Esta latência baseia-se no orçamento de destino de desempenho para os fluxos relacionados.

  • Alguns padrões de conceção da cloud que suportam abordagens de "alteração independente ao longo do tempo" para suportar os ideais de melhoria incremental podem introduzir latência devido ao percurso de componentes adicionais. Esta latência pode ser introduzida por gateways, mediadores de mensagens ou camadas anti-corrupção.

Explore as vantagens dos outros pilares: