Partilhar via

Considerações para atualizar uma solução multi-inquilino

  • Artigo

Uma das vantagens da tecnologia da cloud é a melhoria e evolução contínuas. Enquanto fornecedor de serviços, tem de aplicar atualizações à sua solução: poderá ter de fazer alterações à sua infraestrutura do Azure, ao código/aplicações, aos esquemas da base de dados ou a qualquer outro componente. É importante planear a forma como atualiza os seus ambientes. Numa solução multi-inquilino, é particularmente importante que fique claro sobre a sua política de atualização, porque alguns dos seus inquilinos podem estar relutantes em permitir alterações aos respetivos ambientes ou podem ter requisitos que limitam as condições em que pode atualizar o respetivo serviço.

Ao planear uma estratégia para atualizar a sua solução, tem de:

  • Identifique os requisitos dos inquilinos.
  • Esclareça os seus próprios requisitos para operar o seu serviço.
  • Encontre um saldo que o utilizador e os inquilinos possam aceitar.
  • Comunique claramente a sua estratégia aos inquilinos e a outros intervenientes.

Neste artigo, fornecemos orientações para os decisores técnicos sobre as abordagens que pode considerar para atualizar o software dos inquilinos e as desvantagens envolvidas.

Requisitos dos seus clientes

Considere as perguntas seguintes:

  • Expetativas e requisitos: Os seus clientes têm expectativas ou requisitos sobre quando podem ser atualizados? Estes podem ser formalmente comunicados em contratos ou contratos de nível de serviço ou podem ser informais.
  • Janelas de manutenção: Os seus clientes esperam janelas de manutenção definidas pelo serviço ou até mesmo autodefinidas? Poderão ter de comunicar com os seus próprios clientes sobre eventuais interrupções.
  • Regulamentos: Os seus clientes têm alguma preocupação regulamentar que exija aprovação adicional antes de as atualizações poderem ser aplicadas? Por exemplo, se fornecer uma solução de estado de funcionamento que inclua componentes IoT, poderá ter de obter a aprovação do Estados Unidos Food and Drug Administration (FDA) antes de aplicar uma atualização.
  • Sensibilidade: Algum dos seus clientes é particularmente sensível ou resistente a ter atualizações aplicadas? Tente perceber porquê. Por exemplo, se executarem uma loja física ou um site de retalho, poderão querer evitar atualizações em torno da Black Friday, uma vez que os riscos são superiores aos potenciais benefícios.
  • Histórico: Qual é o seu registo de conclusão com êxito de atualizações sem qualquer impacto para os seus clientes? Deve seguir boas práticas de devOps, teste, implementação e monitorização para reduzir a probabilidade de interrupções e para garantir que identifica rapidamente quaisquer problemas que as atualizações introduzam. Se os seus clientes souberem que consegue atualizar os respetivos ambientes sem problemas, são menos propensos a oporem-se.
  • Reversão: Os clientes vão querer reverter as atualizações se houver uma alteração interruptivo?

Os seus requisitos

Também tem de considerar as seguintes perguntas do seu ponto de vista:

  • Controlo que está disposto a fornecer: É razoável que os seus clientes tenham controlo sobre quando as atualizações são aplicadas? Se estiver a criar uma solução utilizada por grandes clientes empresariais, a resposta poderá ser sim. No entanto, se estiver a criar uma solução focada no consumidor, é improvável que dê qualquer controlo sobre a forma como atualiza ou opera a sua solução.
  • Versões: Quantas versões da sua solução pode manter de uma só vez? Lembre-se de que, se encontrar um erro e precisar de o corrigir, poderá ter de aplicar a correção a todas as versões em utilização.
  • Consequências de versões antigas: Qual é o impacto de permitir que os clientes fiquem muito atrás da versão atual? Se lançar novas funcionalidades regularmente, as versões antigas tornar-se-ão rapidamente obsoletas? Além disso, dependendo da sua estratégia de atualização e dos tipos de alterações, poderá ter de manter infraestruturas separadas para cada versão da sua solução. Assim, poderão existir custos operacionais e financeiros, uma vez que mantém o suporte para versões mais antigas.
  • Reversão: A sua estratégia de implementação pode suportar reversões para versões anteriores? É algo que pretende ativar?

Nota

Considere se precisa de colocar a sua solução offline para atualizações ou manutenção. Geralmente, as janelas de indisponibilidade são vistas como uma prática desatualizada e as práticas modernas do DevOps e das tecnologias da cloud permitem-lhe evitar períodos de indisponibilidade durante atualizações e manutenção. No entanto, tem de criar implementações de tempo de inatividade zero, pelo que é importante considerar o seu processo de atualização quando planear a arquitetura da solução.

Mesmo que não planeie 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 ocorrem em horas específicas.

Para obter mais informações sobre como alcançar implementações de tempo de inatividade zero, veja Eliminar o tempo de inatividade através de atualizações de serviço com versões.

Localizar um saldo

Se deixar a cadência das atualizações de serviço inteiramente à discrição dos inquilinos, estes poderão optar por nunca atualizar. É importante permitir que atualize a sua solução, ao mesmo tempo que considera quaisquer preocupações ou restrições razoáveis que os seus clientes possam ter. Por exemplo, se um cliente for particularmente sensível às atualizações numa sexta-feira, porque esse é o dia mais movimentado da semana, pode diferir facilmente as atualizações para as segundas-feiras, sem afetar a sua solução?

Uma abordagem que pode funcionar bem é implementar atualizações numa base inquilino a inquilino, utilizando uma das abordagens descritas abaixo. Dê um aviso ao cliente sobre as atualizações planeadas. Permitir que os clientes optem temporariamente por não participar, mas não para sempre; coloque um limite razoável em quando irá exigir que a atualização seja aplicada.

Além disso, considere permitir-se a capacidade de implementar patches de segurança ou outras correções críticas, com aviso prévio ou mínimo.

Outra abordagem pode ser permitir que os inquilinos iniciem as suas próprias atualizações, num momento à sua escolha. Mais uma vez, deve indicar um prazo, altura em que aplica a atualização em nome deles.

Aviso

Tenha cuidado ao permitir que os inquilinos iniciem as suas próprias atualizações. Isto é complexo de implementar e exigirá um esforço significativo de desenvolvimento e teste para fornecer e manter.

Faça o que fizer, certifique-se de que tem um processo para monitorizar o estado de funcionamento dos seus inquilinos, especialmente antes e depois de serem aplicadas atualizações. Muitas vezes, os incidentes de produção críticos (também denominados incidentes em direto do site) ocorrem após atualizações ao código ou à configuração. Por conseguinte, é importante monitorizar proativamente e responder a quaisquer problemas para manter a confiança dos clientes. Para obter mais informações sobre a monitorização, veja Monitorização do DevOps.

Comunicar com os seus clientes

A comunicação clara é fundamental para aumentar a confiança dos seus clientes. É importante explicar os benefícios das atualizações regulares, incluindo novas funcionalidades, correções de erros, resolução de vulnerabilidades de segurança e melhorias de desempenho. Uma das vantagens de uma solução moderna alojada na cloud é a entrega contínua de funcionalidades e atualizações.

Considere as perguntas seguintes:

  • Irá notificar os clientes das atualizações futuras?
  • Se o fizer, pedirá implicitamente permissão ao fornecer um processo de opt-out e quais são os limites para optar ativamente por não participar?
  • Tem uma janela de manutenção agendada que utiliza quando aplica atualizações?
  • E se tiver uma atualização de emergência, como um patch de segurança crítico? Pode forçar atualizações nessas situações?
  • Se não conseguir notificar proativamente o cliente das atualizações futuras, pode fornecer notificações retrospetivas? Por exemplo, pode atualizar uma página no seu site com a lista de atualizações que aplicou?
  • Quantas versões separadas do seu sistema irá manter em produção?

Comunicar com a equipa de suporte ao cliente

É importante que a sua própria equipa de suporte tenha visibilidade total sobre as atualizações que foram aplicadas a cada inquilino. Os representantes do suporte ao cliente devem conseguir responder facilmente às seguintes perguntas:

  • As atualizações foram aplicadas recentemente à infraestrutura de um inquilino?
  • Qual foi a natureza dessas atualizações?
  • Qual era a versão anterior?
  • Com que frequência são aplicadas atualizações a este inquilino?

Se um dos seus clientes tiver um problema devido a uma atualização, tem de garantir que a equipa de suporte ao cliente tem as informações necessárias para compreender o que mudou.

Estratégias de implementação para suportar atualizações

Considere como irá implementar atualizações na sua infraestrutura. Isto é fortemente influenciado pelo modelo de inquilino que utiliza. Três abordagens comuns para implementar atualizações são selos de implementação, sinalizadores de funcionalidades e anéis de implementação. Pode utilizar estas abordagens de forma independente ou pode combiná-las em conjunto para cumprir requisitos mais complexos.

Em todos os casos, certifique-se de que tem relatórios e visibilidade suficientes, para que saiba em que versão da infraestrutura, software ou funcionalidade cada inquilino se encontra, o que é elegível para migrar e quaisquer dados relacionados com o tempo associados a esses estados.

Padrão de Selos de Implementação

Muitas aplicações multi-inquilino são uma boa opção para o padrão Selos de Implementação, no qual implementa várias cópias da sua aplicação e de outros componentes. Dependendo dos seus requisitos de isolamento, pode implementar um selo para cada inquilino ou selos partilhados que executam as cargas de trabalho de vários inquilinos.

Os selos são uma excelente forma de proporcionar isolamento entre inquilinos. Também lhe fornecem flexibilidade para o seu processo de atualização, uma vez que pode lançar atualizações progressivamente entre selos, sem afetar outras pessoas.

Sinalizadores de funcionalidades

Os sinalizadores de funcionalidades permitem-lhe adicionar funcionalidades à sua solução, ao mesmo tempo que expõe apenas essa funcionalidade a um subconjunto dos seus clientes ou inquilinos.

Considere utilizar sinalizadores de funcionalidades se qualquer uma destas situações se aplicar a si:

  • Implementa atualizações regularmente, mas quer evitar mostrar novas funcionalidades até que esta esteja totalmente implementada.
  • Quer evitar aplicar alterações de comportamento até que um cliente opte por participar.

Pode incorporar o suporte de sinalizador de funcionalidades na sua aplicação ao escrever código por si próprio ou através de um serviço como Azure App Configuration.

Anéis de implementação

Os anéis de implementação permitem-lhe lançar progressivamente atualizações num conjunto de inquilinos ou selos de implementação. Pode atribuir um subconjunto de inquilinos a cada cadência.

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

  • Canário: Uma cadência canary inclui os seus próprios inquilinos de teste e clientes que pretendem ter atualizações assim que estiverem disponíveis, com a compreensão de que podem receber atualizações mais frequentes e que as atualizações podem não ter passado por um processo de validação tão abrangente como noutros aspetos.
  • Adotador precoce: Uma cadência adotada antecipada contém inquilinos ligeiramente mais avessos ao risco, mas que ainda estão preparados para receber atualizações regulares.
  • Utilizadores: A maioria dos inquilinos pertencerá à cadência dos utilizadores , que recebe atualizações menos frequentes e mais testadas.

Versões da API

Se o seu serviço expor uma API externa, considere que quaisquer atualizações que aplicar poderão afetar a forma como os clientes ou parceiros se integram na sua plataforma. Em particular, tem de estar consciente das alterações interruptivas às suas APIs. Considere utilizar uma estratégia de controlo de versões de API para mitigar o risco de atualizações à sua API.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuintes.

Autor principal:

  • John Downs | Engenheiro Principal de Clientes, FastTrack para o Azure

Outros contribuidores:

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

Passos seguintes