Compartilhar via

Considerações sobre como atualizar uma solução multilocatário

  • Artigo

Um dos benefícios da tecnologia de nuvem é o aprimoramento contínuo e a evolução. Como provedor de serviços, você precisa aplicar atualizações à sua solução: talvez seja necessário fazer alterações na infraestrutura do Azure, no código/aplicativos, nos esquemas do banco de dados ou em qualquer outro componente. É importante planejar como você atualiza seus ambientes. Em uma solução multilocatário, é particularmente importante ser claro sobre sua política de atualização, pois alguns de seus locatários podem estar relutantes em permitir alterações em seus ambientes, ou eles podem ter requisitos que limitam as condições em que você pode atualizar seu serviço.

Ao planejar uma estratégia para atualizar sua solução, você precisa:

  • Identificar os requisitos de seus locatários.
  • Esclarecer seus próprios requisitos para operar seu serviço.
  • Encontrar um equilíbrio que você e seus locatários possam aceitar.
  • Comunicar sua estratégia claramente aos seus locatários e outras partes interessadas.

Neste artigo, fornecemos diretrizes para os tomadores de decisões técnicas sobre as abordagens que você pode considerar para atualizar o software de seus locatários e as compensações envolvidas.

Requisitos de seus clientes

Considere as seguintes perguntas:

  • Expectativas e requisitos: seus clientes têm expectativas ou requisitos sobre quando podem ser atualizados? Eles podem ser formalmente comunicados a você em contratos ou contratos de nível de serviço, ou podem ser informais.
  • Janelas de manutenção: seus clientes esperam janelas de manutenção definidas pelo serviço ou até mesmo autodefinidas? Talvez eles precisem se comunicar com seus próprios clientes sobre possíveis interrupções.
  • Regulamentos: seus clientes têm alguma preocupação regulatória que exija aprovação adicional antes que as atualizações possam ser aplicadas? Por exemplo, se você fornecer uma solução de integridade que inclua componentes de IoT, talvez seja necessário obter aprovação da FDA (Food and Drug Administration) do Estados Unidos antes de aplicar uma atualização.
  • Sensibilidade: algum de seus clientes é particularmente sensível ou resistente a ter atualizações aplicadas? Tente entender por quê. Por exemplo, se eles executam uma loja física ou um site de varejo, talvez queiram evitar atualizações em torno da Black Friday, pois os riscos são maiores do que os benefícios potenciais.
  • Histórico: qual é o seu histórico de conclusão de atualizações com êxito sem nenhum impacto para seus clientes? Você deve seguir boas práticas de DevOps, teste, implantação e monitoramento para reduzir a probabilidade de interrupções e para garantir que você identifique rapidamente os problemas que as atualizações apresentam. Se seus clientes souberem que você é capaz de atualizar seus ambientes sem problemas, eles são menos propensos a se opor.
  • Reversão: os clientes desejarão reverter as atualizações se houver uma alteração significativa?

Seus requisitos

Você também precisa considerar as seguintes perguntas de sua própria perspectiva:

  • Controle que você está disposto a fornecer: é aceitável que seus clientes tenham controle sobre quando as atualizações serão aplicadas? Se você estiver criando uma solução usada por grandes clientes corporativos, a resposta poderá ser sim. No entanto, se você estiver criando uma solução focada no consumidor, é improvável que você dê qualquer controle sobre como atualizar ou operar sua solução.
  • Versões: quantas versões de sua solução você pode manter razoavelmente ao mesmo tempo? Lembre-se de que, se você encontrar um bug e precisar afixá-lo, talvez seja necessário aplicar o hotfix a todas as versões em uso.
  • Consequências de versões antigas: quais é o impacto de permitir que os clientes fiquem muito atrás da versão atual? Se você lançar novos recursos regularmente, as versões antigas ficarão obsoletas rapidamente? Além disso, dependendo da estratégia de atualização e dos tipos de alterações, talvez seja necessário manter infraestruturas separadas para cada versão da sua solução. Portanto, pode haver custos operacionais e financeiros, pois você mantém o suporte para versões mais antigas.
  • Reversão: sua estratégia de implantação pode dar suporte a reversões para versões anteriores? Isso é algo que você quer habilitar?

Observação

Considere se você precisa colocar sua solução offline para atualizações ou manutenção. Em geral, as janelas de interrupção são vistas como uma prática desatualizada e as práticas modernas do DevOps e as tecnologias de nuvem permitem evitar o tempo de inatividade durante atualizações e manutenção. No entanto, você precisa criar implantações sem tempo de inatividade, portanto, é importante considerar o processo de atualização ao planejar sua arquitetura de solução.

Mesmo que você não planeje interrupções durante o processo de atualização, ainda poderá considerar definir uma janela de manutenção regular. Uma janela pode ajudar a comunicar aos seus clientes que as alterações acontecem durante horários específicos.

Para obter mais informações sobre como alcançar implantações sem tempo de inatividade, consulte Eliminar o tempo de inatividade por meio de atualizações de serviço com versão.

Localizar um saldo

Se você deixar a cadência de suas atualizações de serviço inteiramente a critério de seus locatários, eles poderão optar por nunca atualizar. É importante permitir que você atualize sua solução, considerando quaisquer preocupações ou restrições razoáveis que seus clientes possam ter. Por exemplo, se um cliente é particularmente sensível às atualizações em uma sexta-feira, pois esse é o dia mais movimentado da semana, você pode adiar facilmente as atualizações para segundas-feiras, sem afetar sua solução?

Uma abordagem que pode funcionar bem é implantar atualizações em uma base locatário por locatário, usando uma das abordagens descritas abaixo. Dê ao cliente um aviso sobre as atualizações planejadas. Permitir que os clientes optem temporariamente por sair, mas não para sempre; coloque um limite razoável sobre quando você exigirá que a atualização seja aplicada.

Além disso, considere permitir a si mesmo a capacidade de implantar patches de segurança ou outros hotfixes críticos, com aviso prévio mínimo ou nenhum aviso prévio.

Outra abordagem pode ser permitir que os locatários iniciem suas próprias atualizações, em um momento de sua escolha. Novamente, você deve fornecer um prazo, momento em que aplicará a atualização em nome deles.

Aviso

Tenha cuidado ao permitir que os locatários iniciem suas próprias atualizações. Isso é complexo de implementar e exigirá um esforço significativo de desenvolvimento e teste para entregar e manter.

O que quer que você faça, verifique se você tem um processo para monitorar a integridade de seus locatários, especialmente antes e depois que as atualizações são aplicadas. Geralmente, incidentes críticos de produção (também chamados de incidentes de site dinâmico) ocorrem após atualizações de código ou configuração. Portanto, é importante que você monitore proativamente e responda a quaisquer problemas para manter a confiança do cliente. Para obter mais informações sobre o monitoramento, confira Monitoramento do DevOps.

Comunicar-se com seus clientes

A comunicação clara é fundamental para criar a confiança dos clientes. É importante explicar os benefícios das atualizações regulares, incluindo novos recursos, correções de bugs, resolução de vulnerabilidades de segurança e melhorias de desempenho. Um dos benefícios de uma solução moderna hospedada na nuvem é a entrega contínua de recursos e atualizações.

Considere as seguintes perguntas:

  • Você notificará os clientes sobre as próximas atualizações?
  • Se você fizer isso, solicitará permissão implicitamente fornecendo um processo de exclusão, e quais são os limites para exclusão?
  • Você tem uma janela de manutenção agendada que usa quando aplica atualizações?
  • E se você tiver uma atualização de emergência, como um patch de segurança crítico? Você pode forçar atualizações nessas situações?
  • Se você não puder notificar proativamente o cliente sobre as próximas atualizações, você poderá fornecer notificações retrospectivas? Por exemplo, você pode atualizar uma página em seu site com a lista de atualizações aplicadas?
  • Quantas versões separadas do seu sistema você manterá em produção?

Comunique-se com sua equipe de suporte ao cliente

É importante que sua própria equipe de suporte tenha visibilidade total das atualizações que foram aplicadas a cada locatário. Os representantes de suporte ao cliente devem ser capazes de responder facilmente às seguintes perguntas:

  • As atualizações foram aplicadas recentemente à infraestrutura de um locatário?
  • Qual era a natureza dessas atualizações?
  • Qual era a versão anterior?
  • Com que frequência as atualizações são aplicadas a esse locatário?

Se um de seus clientes tiver um problema devido a uma atualização, você precisará garantir que sua equipe de suporte ao cliente tenha as informações necessárias para entender o que mudou.

Estratégias de implantação para dar suporte a atualizações

Considere como você implantará atualizações em sua infraestrutura. Isso é fortemente influenciado pelo modelo de locação que você usa. Três abordagens comuns para implantar atualizações são selos de implantação, sinalizadores de recursos e anéis de implantação. Você pode usar essas abordagens de forma independente ou combiná-las para atender a requisitos mais complexos.

Em todos os casos, verifique se você tem relatórios e visibilidade suficientes, para que você saiba para qual versão da infraestrutura, software ou recurso cada locatário está ativado, para o que eles estão qualificados para migrar e quaisquer dados relacionados ao tempo associados a esses estados.

Padrão de Carimbos de Implantação

Muitos aplicativos multilocatário são adequados para o padrão Selos de Implantação, no qual você implanta várias cópias do aplicativo e outros componentes. Dependendo dos requisitos de isolamento, você pode implantar um selo para cada locatário ou selos compartilhados que executam cargas de trabalho de vários locatários.

Os selos são uma ótima maneira de fornecer isolamento entre locatários. Eles também oferecem flexibilidade para o processo de atualização, pois você pode distribuir atualizações progressivamente entre selos, sem afetar outras pessoas.

Sinalizadores de recurso

Os sinalizadores de recursos permitem que você adicione funcionalidade à sua solução, expondo apenas essa funcionalidade a um subconjunto de seus clientes ou locatários.

Considere usar sinalizadores de recursos se uma destas situações se aplicar a você:

  • Você implanta atualizações regularmente, mas deseja evitar mostrar a nova funcionalidade até que ela esteja totalmente implementada.
  • Você deseja evitar aplicar alterações no comportamento até que um cliente aceite.

Você pode inserir suporte ao sinalizador de recurso em seu aplicativo escrevendo código por conta própria ou usando um serviço como Configuração de Aplicativos do Azure.

Anéis de implantação

Os anéis de implantação permitem que você implemente progressivamente atualizações em um conjunto de locatários ou selos de implantação. Você pode atribuir um subconjunto de locatários a cada anel.

Você pode determinar quantos anéis criar e o que cada anel significa para sua própria solução. Comumente, as organizações usam os seguintes anéis:

  • Canário: um anel canário inclui seus próprios locatários de teste e clientes que desejam ter atualizações assim que estiverem disponíveis, com a compreensão de que eles podem receber atualizações mais frequentes, e que as atualizações podem não ter sido através de um processo de validação tão abrangente quanto em outras coisas.
  • Usuário pioneiro: um anel de usuário pioneiro contém locatários um pouco mais avessos ao risco, mas que ainda estão preparados para receber atualizações regulares.
  • Usuários: a maioria dos locatários pertencerá ao anel de usuários, que recebe atualizações menos frequentes e mais testadas.

Versões de API

Se o serviço expor uma API externa, considere que todas as atualizações aplicadas podem afetar a forma como clientes ou parceiros se integram à sua plataforma. Em particular, você precisa estar consciente de alterações interruptivas em suas APIs. Considere usar uma estratégia de controle de versão da API para atenuar o risco de atualizações para sua API.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

  • John Downs | Engenheiro principal de atendimento ao cliente, FastTrack for Azure

Outros colaboradores:

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas