Gestão da fiabilidade

Embora os serviços de produção não estejam numa subscrição de Dev/Test, pode usar outras fases na sua subscrição de Azure Dev/Test para garantir a fiabilidade em produção.

Note

As subscrições de Azure Dev/Test destinam-se a testes e desenvolvimento em pré-produção e não têm um SLA financiado. Antes de escolher uma subscrição Dev/Test, consulte as opções disponíveis de subscrição Azure Dev/Test para determinar qual a oferta que melhor se adequa aos seus requisitos de desenvolvimento e testes.

Recursos relacionados:

Ao usar as subscrições de Dev/Teste da sua organização, decida como irá:

  • Dados de controlo
  • Controle a segurança e o acesso
  • Gerencie o tempo de atividade desse sistema de produção

Normalmente, existem diferentes fases de implementação que se passam antes da produção – partilhado, QA, integração, staging e failover. Dependendo de como a sua empresa define estas fases, a sua utilização de uma subscrição de Desenvolvimento/Teste organizacional pode mudar.

Se estiveres a executar serviços críticos para a missão, como aplicações voltadas para clientes, não uses uma subscrição de Dev/Test. As assinaturas de desenvolvimento/teste não possuem um SLA apoiado financeiramente. Estas subscrições destinam-se a testes e desenvolvimento de pré-produção.

Engenharia de Confiabilidade do Site (SRE)

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

As diferenças entre SRE e DevOps continuam a ser debatidas na área. Algumas diferenças amplamente acordadas incluem:

  • SRE é uma disciplina de engenharia focada em confiabilidade. O DevOps é um movimento cultural que surgiu da vontade de quebrar os silos associados às organizações de Desenvolvimento e Operações.
  • SRE pode ser o nome de uma função, como: sou engenheiro de fiabilidade de local (SRE). DevOps não pode.
  • A SRE tende a ser prescritiva. DevOps intencionalmente não o é. A adoção quase universal da integração contínua/entrega contínua e dos princípios ágeis é aquilo de que o DevOps mais se aproxima.

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

Acordos de Nível de Serviços

O Enterprise Dev/Test destina-se exclusivamente ao desenvolvimento e teste das suas aplicações. A utilização da subscrição não inclui um SLA com garantias financeiras.

Aprenda a usar diferentes tipos de assinaturas de desenvolvimento/teste

Quer precise de Créditos mensais do Azure para subscritores do Visual Studio, Subscrições Dev/Test empresariais ou uma Subscrição Dev/Test pay-as-you-go (PAYG), pode encontrar facilmente ofertas adequadas tanto para indivíduos como para equipas.

Créditos Azure individuais destinam-se a cenários individuais de desenvolvimento e testes, enquanto subscrições de Desenvolvimento/Teste Empresarial estão disponíveis para desenvolvimento de equipas em grandes organizações. Revise as opções de subscrição disponíveis para determinar qual a oferta que melhor se adequa aos seus requisitos de desenvolvimento e testes.

Gerir subscrições de créditos individuais

Os créditos Azure do Visual Studio constituem um benefício individual para desenvolvimento individual de Dev/Test e desenvolvimento em ciclo interno. Não podes juntar créditos entre desenvolvedores. As subscrições de crédito continuam a ser subscrições do Azure, mas são uma oferta específica do Azure. Faça a gestão das suas subscrições de crédito da mesma forma que gere outras subscrições do Azure para poder trabalhar em grupos e equipas. Pode eliminar os limites de despesa individuais adicionando um cartão de crédito, ou se a sua subscrição de Desenvolvimento/Teste empresarial for usada pelo método de compras escolhido pela sua empresa.

As atividades do ciclo interno do programador utilizam frequentemente créditos, mas passam depois para subscrições Azure Dev/Test empresariais ou organizacionais, incluindo as de pagamento consoante a utilização. Dessa forma, ao seguir os processos de DevOps, você pode fazer um loop interno com sua assinatura de crédito individual. No loop externo do DevOps, os alvos que não são de produção estão em Dev/Test da empresa - prod vai para prod.

Gere as tuas subscrições de crédito, subscrições de desenvolvimento/teste empresariais e subscrições PAYG e segmenta os teus programadores usando grupos de gestão , cada um com uma hierarquia única.

Usando a sua organização as ofertas de Azure Dev/Test

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

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

Cada oferta de subscrição permite-lhe pôr a sua equipa a funcionar com ambientes de Dev/Teste na cloud, utilizando máquinas virtuais pré-configuradas. Crie várias assinaturas do Azure e gerencie-as a partir de uma conta. Você pode manter ambientes isolados e uma fatura separada para diferentes projetos ou equipes.

As Subscrições de Desenvolvimento/Teste Empresariais requerem um contrato Enterprise (EA). As Subscrições de Desenvolvimento/Teste Pré-pagas não requerem um EA, mas podem ser utilizadas com uma conta de contrato empresarial.

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

Uma oferta de desenvolvimento/teste PAYG pode ser a opção certa para usar como assinante do Visual Studio. Ao contrário das assinaturas de crédito para uso individual, as ofertas 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 pode ser ideal para si se:

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