Compartilhar via

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

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

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

  • Identifique os requisitos dos locatários.
  • Esclareça seus próprios requisitos para operar seu serviço.
  • Encontre um saldo que você e seus locatários podem aceitar.
  • Comunique sua estratégia claramente aos seus locatários e a outros stakeholders.

Este artigo fornece diretrizes para tomadores de decisão técnicos sobre abordagens para atualizar o software do locatário e as compensações envolvidas.

Requisitos de seus clientes

Os clientes geralmente têm requisitos explícitos ou implícitos que podem afetar a forma como seu sistema é atualizado. Considere os seguintes aspectos para criar uma imagem de qualquer ponto de preocupação que os clientes possam gerar:

  • Expectativas e requisitos: Descubra quaisquer expectativas ou requisitos que os clientes possam ter sobre quando a solução pode ser atualizada. Essas expectativas ou requisitos podem ser formalmente comunicados a você em contratos ou contratos de nível de serviço, ou podem ser informais.

  • Janelas de manutenção: Entenda se os clientes esperam janelas de manutenção autodefinidas ou definidas pelo serviço. Talvez eles precisem se comunicar com seus usuários sobre possíveis interrupções. Eles também podem esperar testar aspectos importantes do serviço após a conclusão da atualização.

  • Regulamentos: Esclareça se os clientes têm alguma preocupação regulatória que exija aprovação extra antes que as atualizações possam ser aplicadas. Por exemplo, se você fornecer uma solução de saúde que inclua componentes de IoT, talvez seja necessário obter aprovação da Food and Drug Administration (FDA) dos Estados Unidos antes de aplicar uma atualização.

  • Sensibilidade: Entenda se algum de seus clientes é particularmente sensível ou resistente a ter atualizações aplicadas. Se estiverem, tente entender o porquê. Por exemplo, se eles executam uma loja física ou um site de varejo, talvez queiram evitar atualizações em torno da Black Friday, porque os riscos são maiores do que os benefícios potenciais.

  • História: Examine seu próprio 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 garantir que identifique rapidamente todos os problemas que as atualizações introduzem. Se seus clientes souberem que você é capaz de atualizar seus ambientes sem problemas, eles são menos propensos a se opor.

  • Reversão: Considere se os clientes desejam reverter as atualizações se houver uma alteração significativa e quem dispara essa solicitação de reversão.

Seus requisitos

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

  • Controle que você está disposto a fornecer: É razoável que seus clientes tenham controle sobre quando as atualizações são aplicadas? Se você estiver criando uma solução usada por clientes de grandes empresas, a resposta pode 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 da sua solução você pode manter razoavelmente ao mesmo tempo? Se você encontrar uma vulnerabilidade de bug ou segurança e precisar aplicar um hotfix, talvez seja necessário aplicá-lo a todas as versões atualmente em uso.

  • Consequências de versões antigas: Qual é 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 se tornarão obsoletas rapidamente? Além disso, dependendo da sua 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? Deseja habilitar essa funcionalidade?

Observação

Considere se você precisa colocar sua solução offline para atualizações ou manutenção. As janelas de interrupção geralmente são consideradas uma prática desatualizada para SaaS (software como serviço). As práticas modernas do DevOps e as tecnologias de nuvem permitem evitar tempo de inatividade durante atualizações e manutenção. No entanto, você precisa projetar para implantações com zero tempo de inatividade. É 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á definir uma janela de manutenção regular. Essa abordagem ajuda a comunicar aos clientes que as alterações ocorrem em horários específicos.

Para obter mais informações sobre como realizar implantações sem tempo de inatividade, consulte Eliminar o tempo de inatividade por meio de atualizações de serviço versionadas.

Localizar um equilíbrio

Se você deixar a cadência das 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 estiver particularmente sensível às atualizações em uma sexta-feira porque esse é o dia mais movimentado da semana, considere se você pode adiar facilmente as atualizações para segunda-feira 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 estratégias de implantação. Notifique seus clientes sobre atualizações planejadas. Permitir que os clientes optem temporariamente por sair, mas não permanentemente. Coloque um limite razoável sobre quando você exigirá que a atualização seja aplicada.

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 sem aviso prévio. Certifique-se de que os locatários entendam essa prática e sua importância na proteção de seus dados.

Outra abordagem pode ser permitir que os locatários iniciem suas próprias atualizações durante um tempo escolhido. 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. Esse processo é complexo de implementar e requer um esforço significativo de desenvolvimento e teste para entregar e manter.

Independentemente do que você fizer, 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. Incidentes críticos de produção, também conhecidos como incidentes de site ao vivo, geralmente ocorrem após alterações no código ou na configuração. Como resultado, é importante monitorar proativamente e responder a quaisquer problemas para manter a confiança do cliente. Para obter mais informações, consulte Gerenciamento de incidentes para cargas de trabalho de SaaS no Azure.

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á implicitamente a permissão fornecendo um processo de exclusão e quais são os limites para recusar?

  • Você tem uma janela de manutenção agendada que usa ao aplicar atualizações?

  • O que acontece 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?

Comunicar-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 à infraestrutura de 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 ou a componentes compartilhados?

  • 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 foi alterado.

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

Considere como implantar atualizações em sua infraestrutura. Sua estratégia de atualização depende muito do modelo de locação que você usa. Três estratégias comuns para implantar atualizações são selos de implantação, feature flags 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. Você precisa saber qual versão de infraestrutura, software ou recurso cada locatário utiliza, para qual eles estão elegíveis para migração, e quaisquer dados relacionados ao tempo que estejam relacionados a esses estados. Acompanhar essas informações geralmente é uma das responsabilidades de um plano de controle.

Padrão de Carimbos de Implantação

Muitos aplicativos multilocatários são adequados ao padrão Deployment Stamps. Nesse padrão, você implanta várias cópias do aplicativo e de 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 recursos

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 o uso de sinalizadores de recursos se qualquer um desses cenários se aplicar a você:

  • Você implanta atualizações regularmente, mas deseja evitar mostrar novas funcionalidades até que ela seja totalmente implementada.

  • Você deseja evitar a aplicação de alterações no comportamento até que um cliente aceite.

Você pode inserir o suporte ao sinalizador de recursos em seu aplicativo escrevendo o código por conta própria ou usando um serviço como a 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 na sequência de distribuição.

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

  • Canary: um anel Canary inclui seus próprios locatários de teste e clientes que desejam receber atualizações assim que estiverem disponíveis. Qualquer pessoa no anel canário deve entender que pode receber atualizações mais frequentes. Essas atualizações podem não ter passado por um processo de validação tão abrangente quanto as atualizações em outros anéis.

  • Adotante antecipado: Um anel de adotante inicial contém locatários que são um pouco mais avessos a riscos, mas ainda estão preparados para receber atualizações regulares.

  • Usuários: A maioria dos locatários pertence ao anel de usuários , que recebe atualizações menos frequentes e mais testadas.

Versões da 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 de API para atenuar o risco de atualizações em sua API.

Contribuidores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autor principal:

  • John Downs | Principal Engenheiro de Software, Padrões do Azure & Práticas

Outros colaboradores:

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

  • Last updated on