Gestão de confiabilidade

Embora os serviços de produção não estejam em uma assinatura de Dev/Test, você pode usar outras etapas na sua assinatura de Azure Dev/Test para garantir confiabilidade em produção.

Note

As assinaturas de Dev/Test do Azure são destinadas a testes e desenvolvimento em pré-produção e não possuem um SLA financiado. Antes de escolher uma assinatura de Dev/Test, revise as opções disponíveis de assinatura de Azure Dev/Test para determinar qual oferta melhor atende às suas necessidades de desenvolvimento e testes.

Recursos relacionados:

Ao usar as assinaturas de Desenvolvimento/Testes da sua organização, decida como irá:

  • Dados de controle
  • Controlar a segurança e o acesso
  • Gerencie o tempo de atividade do sistema de produção

Normalmente, há diferentes etapas de implantação que você passa antes da produção – compartilhada, QA, integração, staging e failover. Dependendo de como sua empresa define essas etapas, seu uso de uma assinatura de Dev/Test da organização pode mudar.

Se você está rodando serviços críticos para a missão, como aplicativos voltados para o cliente, não use uma assinatura de Dev/Test. As assinaturas de Desenvolvimento/Teste não têm um SLA com suporte financeiro. Essas assinaturas são para testes e desenvolvimento de pré-produção.

SRE (Engenharia de Confiabilidade do Site)

Para saber mais sobre engenharia e gerenciamento de confiabilidade, considere o gerenciamento de confiabilidade do site – uma disciplina de engenharia dedicada a ajudar as organizações a alcançar a confiabilidade apropriada em seus sistemas, serviços e produtos.

A diferença entre SRE e DevOps ainda está em discussão no campo. Algumas diferenças amplamente concordadas incluem:

  • SRE é uma disciplina de engenharia voltada para confiabilidade. DevOps é um movimento cultural que surgiu da ânsia de separar os silos associados às organizações de Desenvolvimento e Operações.
  • SRE pode ser o nome de uma função, como: sou engenheiro de confiabilidade de local (SRE). DevOps não pode.
  • SRE tende a ser prescritivo. DevOps é intencionalmente não prescritivo. A adoção quase universal da integração contínua/entrega contínua e os princípios do Agile são mais próximos ao DevOps.

Se você quiser saber mais sobre a prática de SRE, confira estes links:

Contratos de Nível de Serviço

O Desenvolvimento/Teste Enterprise é exclusivamente para o desenvolvimento e teste de seus aplicativos. O uso da assinatura não inclui um SLA com respaldo financeiro.

Saiba como usar diferentes tipos de Assinaturas de Desenvolvimento/Teste

Se você precisar de Créditos Mensais do Azure para assinantes do Visual Studio, Assinaturas de Desenvolvimento/Teste Enterprise ou Assinatura de Desenvolvimento/Teste PAYG (Pago Conforme o Uso), poderá encontrar facilmente ofertas que funcionam para indivíduos ou uma equipe.

Créditos Azure individuais são destinados a cenários individuais de desenvolvimento e testes, enquanto assinaturas de Desenvolvimento Empresarial/Teste estão disponíveis para desenvolvimento de equipes em grandes organizações. Revise as opções de assinatura disponíveis para determinar qual oferta melhor atende às suas necessidades de desenvolvimento e testes.

Gerenciar assinaturas individuais de crédito

Os créditos do Azure para Visual Studio são um benefício individual para desenvolvimento individual de Desenvolvimento/Teste e loop interno. Você não pode compartilhar créditos entre desenvolvedores. As assinaturas de crédito ainda são assinaturas do Azure, mas são uma oferta específica do Azure. Gerencie suas assinaturas de crédito da mesma maneira que gerencia outras assinaturas do Azure, para que você possa trabalhar entre grupos e equipes. Você pode eliminar limites individuais de gastos adicionando um cartão de crédito, ou se sua assinatura de Desenvolvimento/Teste empresarial for usada pelo método de compras escolhido pela sua empresa.

As atividades do "inner loop" de desenvolvimento frequentemente utilizam créditos, mas depois migram para assinaturas Desenvolvimento/Teste do Azure corporativas ou organizacionais, incluindo a modalidade de pagamento conforme o uso. Dessa forma, ao seguir os processos de DevOps, você pode usar o loop interno com sua assinatura de créditos individual. No loop externo do DevOps, os destinos de não produção estão no Desenvolvimento/Teste corporativo — a produção vai para a produção.

Gerencie suas assinaturas de crédito, assinaturas de Dev/Test empresariais e assinaturas de PAYG, e segmente seus desenvolvedores usando grupos de gestão que tenham uma hierarquia única.

Usando as ofertas de Desenvolvimento/Teste do Azure da sua organização

Se você precisar de uma assinatura de Desenvolvimento/Teste do Azure da organização, terá duas ofertas para escolher.

Cada opção vem com seu próprio conjunto de descontos e requer uma Assinatura do Visual Studio.

Cada oferta de assinatura permite que sua equipe comece a funcionar com ambientes de Dev/Test na nuvem usando máquinas virtuais pré-configuradas. Crie várias assinaturas do Azure e gerencie-as de uma conta. Você pode manter ambientes isolados e uma fatura separada para diferentes projetos ou equipes.

As Assinaturas de Desenvolvimento e Teste para Empresas exigem um EA (Acordo Empresarial). Assinaturas de Desenvolvimento/Teste Pago Conforme o Uso não exigem um EA, mas podem ser usadas com uma conta de contrato enterprise.

Por que usar ofertas PAYG em vez de ofertas de Desenvolvimento/Teste Corporativo?

Uma oferta de Desenvolvimento/Teste PAYG pode ser a melhor escolha para usar como assinante do Visual Studio. Ao contrário das assinaturas de crédito para uso individual, as ofertas de PAYG são ótimas para o desenvolvimento em equipe e permitem que você tenha vários usuários em uma assinatura. Uma oferta de Desenvolvimento/Teste PAYG poderá ser certa para você se:

  • Você não tem um contrato corporativo. Nesse caso, você só poderá criar uma conta PAYG com uma licença do Visual Studio.
  • Você está criando um acordo empresarial, mas precisa configurar uma assinatura que não use o acordo da sua organização. Você pode ter um projeto exclusivo que requer sua própria assinatura ou criar um ambiente isolado cobrado separadamente para projetos ou equipes.
  • Você prefere manter as identidades isoladas. Talvez você precise que determinadas identidades permaneçam separadas de outras para proteger o acesso a dados, recursos e aplicativos.
  • Last updated on