Como a Microsoft opera sistemas confiáveis com o DevOps

A Microsoft opera plataformas online complexas desde os primeiros dias da Internet comercial. Ao longo do caminho, evoluímos um conjunto substancial de práticas para manter os sistemas disponíveis, íntegros e seguros. Essas práticas fazem parte de uma iniciativa maior para manter e melhorar uma cultura de site ao vivo.

Cultura de site ao vivo

A cultura do site ao vivo é o foco de uma organização para priorizar a experiência e a confiabilidade do site ao vivo em relação a tudo o resto. Afinal, os clientes podem se mover entre provedores de serviços facilmente hoje em dia com os serviços baseados em nuvem e na Internet, ampliando consideravelmente a importância da confiança do cliente. O site ao vivo sempre deve estar disponível e executar conforme prometido aos clientes.

Há vários fatores que contribuem para uma cultura de site ao vivo bem-sucedida.

Site ao vivo primeiro

Colocar a experiência de site ao vivo em primeiro lugar é essencial para uma plataforma de sucesso. As equipes não podem colocar todo o foco em recursos novos e brilhantes e desconsiderar a avenida na qual esses recursos são apresentados aos usuários. Contamos com práticas de implantação seguras que ajudam a garantir que nossos clientes aproveitem o acesso ininterrupto à plataforma. Isso pode ficar especialmente complicado quando se trata de lançar atualizações de serviço com versão sem tempo de inatividade.

Controlar a exposição por meio de sinalizadores de recursos

À medida que implantamos por meio de nossas camadas e estágios, controlando a exposição com sinalizadores de recursos, ocasionalmente descobrimos um problema na produção. Apesar de todas as nossas automações e revisões, às vezes as coisas ainda acontecem. Como dizem, não há lugar como produção!

Normalmente, o monitoramento de integridade e a telemetria nos alertam quando algo não está certo. Um desenvolvedor pode criar uma ramificação desativada main, fazer uma correção e efetuar pull da solicitação para main. Manter o mesmo fluxo de trabalho geral significa que os desenvolvedores não precisam alternar de contexto ou aprender um processo diferente para uma alteração de código diferente.

Para resolver uma implantação de hotfix, mais uma etapa é necessária, que é escolher a alteração no branch de lançamento. Executamos uma implantação de hotfix fora do branch de lançamento atual a cada manhã do dia da semana, embora também possamos fazer isso sob demanda para correções urgentes. A correção atinge primeiro a produção do branch de lançamento. Mas, como desenvolvemos em main primeiro lugar, sabemos que ele não regredirá o próximo sprint quando um novo branch de lançamento for criado a partir de main.

As versões de produtos locais são praticamente as mesmas, embora sem as camadas de implantação e os estágios. Além disso, como fazemos mais testes manuais em diferentes configurações e formas de dados, há uma cauda mais longa entre cortar o branch de lançamento e colocar o produto nas mãos dos clientes.

A segurança deve ser levada para o lado pessoal

O foco é tornar as vulnerabilidades reais e pessoais. Isso garante que as pessoas realmente se importem. Também fazemos uso extensivo de jogos de guerra para encontrar e resolver riscos de segurança em todo o sistema, seja no código ou não. Quando a equipe vermelha pode mostrar que entrou no código transformando uma caixa de diálogo de cabeça para baixo, isso realmente motiva o proprietário do código a resolver o problema e garantir que isso não aconteça novamente em nenhum outro lugar. Esse tipo de competição é muito mais real e pessoal do que um aviso de análise estática sobre um potencial risco XSS. Criamos esse tipo de cultura e dinâmica através de jogos de guerra e outros exercícios de segurança. As pessoas se orgulham de invadir o código uns dos outros ou ser capazes de bloquear as tentativas. Isso incute uma cultura de código segura.

Não podemos planejar cada vetor de ataque, mas o que podemos fazer é assumir que haverá uma violação, e planejar a rapidez com que podemos reagir a essa violação. Muito do trabalho de segurança tem sido em torno disso para nossas equipes.

Finalmente, os humanos cometem erros. Às vezes, eles ficam lentos e fazem coisas como armazenar senhas em compartilhamentos de arquivos. Podemos dizer-lhes para não fazê-lo e podemos enviá-los para o treinamento de segurança e podemos fazer todos os tipos de outras coisas. A maioria das pessoas aprende, mas só é preciso uma pessoa para quebrar o sistema. Você pode ter todos os tipos de listas de práticas recomendadas, mas a menos que você esteja tornando isso real, você tem que assumir que as pessoas vão cometer erros. Isso requer um certo nível de supervisão para garantir que os processos críticos estejam sendo seguidos.

A engenharia é mais do que um parceiro de operações

Aprendemos cedo a tornar o site ao vivo uma parte importante das responsabilidades da equipe de engenharia. Isso foi enorme para nós porque, no passado, uma pessoa poderia ir implantar algo, sair para o fim de semana e voltar segunda-feira para encontrar 900 problemas de clientes com os quais as equipes de suporte ao cliente e operações estavam lidando durante todo o fim de semana. É importante que a engenharia pague o preço por problemas de site ao vivo. Caso contrário, não haverá incentivo para criar sistemas que evitem esses problemas. Quando você é chamado às 2 da manhã para consertar algo que você quebrou, você se lembra.

À medida que evoluímos essa responsabilidade, o site ao vivo é a coisa mais importante que fazemos tornou-se o mantra de toda a equipe. É a experiência do cliente que eles têm agora e não é apenas um imposto. Na verdade, é algo que as pessoas contam conosco e nos orgulhamos disso. Ele precisa ser um recurso diferencial do nosso produto.

A telemetria de produção é a pulsação do serviço

Para sobreviver no mundo em ritmo acelerado, onde praticamente qualquer coisa pode dar errado, precisamos de ótimos sistemas de alerta. Alertas inacionáveis, alertas redundantes ou volumes de alertas avassaladores fazem você ignorar todos os alertas. É fácil criar muitos alertas, então o processo realmente destila até uma pergunta simples: esse alerta é acionável? Isso garante que estamos nos envolvendo nos problemas certos do cliente e lidando com eles o mais rápido possível.

Como a equipe de engenharia zerou em alertas acionáveis, eles notaram que muitos problemas que surgem, especialmente no meio da noite, tendem a ter correções semelhantes, pelo menos temporariamente. Isso resultou em um foco em sistemas que eram melhores em fazer failover e auto-cura. Agora os problemas acontecem, geram alertas e, em seguida, se consertam bem o suficiente para que a equipe de engenharia aguarde até a manhã para corrigir. Isso não teria acontecido se a equipe de engenharia apenas empurrasse pedaços que mantinham outras pessoas acordadas à noite. Agora eles trabalham para equilibrar essas melhorias como parte não apenas da velocidade do recurso, mas da velocidade de melhoria da engenharia.

Resumo

A adoção de uma cultura de site ao vivo tem afetado a maneira como a Microsoft cria e fornece software. Ao tornar as equipes de engenharia uma parte fundamental da segurança e das operações, a qualidade do nosso código e da experiência do usuário final melhoraram drasticamente. Ser um participante completo das operações tornou a engenharia um dos principais stakeholders, resultando em sistemas projetados para operações melhores.