Como a Microsoft opera sistemas confiáveis com DevOps

A Microsoft opera plataformas online complexas desde os primórdios da internet comercial. Ao longo do caminho, desenvolvemos um conjunto substancial de práticas para manter os sistemas disponíveis, saudáveis e seguros. Essas práticas fazem parte de uma iniciativa maior para manter e melhorar a cultura de um site ao vivo.

Cultura do 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 sobre todo o resto. Afinal, hoje em dia, os clientes podem transitar entre provedores de serviços com bastante facilidade com os serviços baseados em nuvem e internet, ampliando muito a importância da confiança do cliente. O site ao vivo deve estar sempre disponível e funcionar conforme prometido aos clientes.

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

Site ao vivo primeiro

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

Controle a exposição através de sinalizadores de recursos

À medida que implantamos em nossos níveis e estágios, controlando a exposição com sinalizadores de recursos, ocasionalmente descobrimos um problema na produção. Apesar de toda a nossa automação e análises, as coisas às vezes ainda acontecem. Como se costuma dizer, não há lugar como a produção!

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

Para resolver uma implantação de hotfix, é necessária mais uma etapa, que é escolher a alteração para a ramificação de versão. Executamos uma implantação de hotfix fora da ramificação de lançamento atual todos os dias da semana pela manhã, embora também possamos fazer isso sob demanda para correções urgentes. A correção realmente atinge a produção fora do ramo de lançamento primeiro. Mas como desenvolvemos em main primeiro lugar, sabemos que ele não irá regredir no próximo sprint quando uma nova ramificação de lançamento for criada a partir de main.

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

A segurança deve ser levada pessoalmente

O foco é tornar as vulnerabilidades reais e pessoais. Isso garante que as pessoas realmente se importam. Também fazemos uso extensivo de jogos de guerra para encontrar e abordar riscos de segurança em todo o sistema, seja em código ou não. Quando a equipe vermelha pode mostrar que entrou no código virando 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 ele não aconteça novamente em nenhum outro lugar. Esse tipo de competição é muito mais real e pessoal do que uma análise estática alertando sobre um potencial risco de XSS. Criamos este tipo de cultura e dinâmica através de jogos de guerra e outros exercícios de segurança. As pessoas se orgulham de hackear o código umas das outras ou de serem capazes de bloquear as tentativas. Isso incute uma cultura de código segura.

Não podemos planejar todos os vetores 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 as nossas equipas.

Finalmente, os seres humanos cometem erros. Às vezes, eles ficam preguiçosos e fazem coisas como armazenar senhas em compartilhamentos de arquivos. Podemos dizer-lhes que não o façam e podemos enviá-los para formação em segurança e podemos fazer todo o tipo de outras coisas. A maioria das pessoas aprende, mas basta uma pessoa para quebrar o sistema. Você pode ter todos os tipos de listas de melhores práticas, mas a menos que você esteja tornando isso real, você tem que assumir que as pessoas vão cometer erros. Tal exige um certo nível de supervisão para garantir que os processos críticos estão a ser seguidos.

A Engineering é mais do que um parceiro operacional

Aprendemos desde 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 podia implantar algo, sair para o fim de semana e voltar na 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 no local ao vivo. Caso contrário, não há incentivo para construir sistemas que evitem esses problemas. Quando você é chamado às 2 da manhã para consertar algo que quebrou, você se lembra.

À medida que fomos evoluindo nesta responsabilidade, o Live site é a coisa mais importante que fazemos tornou-se o mantra de toda a equipa. É a experiência do cliente que eles têm agora e não é apenas um imposto. Na verdade, é algo com que as pessoas contam connosco e temos orgulho nisso. Precisa ser uma característica diferenciadora do nosso produto.

A telemetria de produção é o coração do seu serviço

Para sobreviver no mundo acelerado, onde praticamente tudo pode dar errado, precisamos de grandes sistemas de alerta. Alertas não acionáveis, alertas redundantes ou volumes de alertas avassaladores fazem com que você ignore todos os alertas. É fácil criar muitos alertas, então o processo realmente se resume a uma pergunta simples: esse alerta é acionável? Isso garante que estamos nos envolvendo com os problemas certos dos clientes e lidando com eles o mais rápido possível.

À medida que a equipe de engenharia se concentrava 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 falhar e auto-cura. Agora os problemas acontecem, levantam alertas e, em seguida, corrigem-se bem o suficiente para a equipe de engenharia esperar até de 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 afetou 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 a experiência do usuário final melhoraram drasticamente. Ser um participante pleno nas operações tornou a engenharia uma parte interessada chave, resultando em sistemas que são projetados para melhores operações.