Este documento descreve o apoio técnico de software e a política de descontinuação do Google Distributed Cloud (GDC) com isolamento de ar.
O GDC vai enviar um aviso com uma antecedência mínima de um ano relativamente a qualquer alteração que possa causar problemas. Este aviso pode ser emitido em qualquer altura após um serviço ou uma funcionalidade ficar geralmente disponível (GA), mas a alteração em si só entra em vigor após o período de aviso de um ano. Se for emitido um aviso de descontinuação imediatamente após um serviço ficar geralmente disponível, haverá um período de um ano antes de o serviço ser desativado.
O GDC vai fornecer apoio técnico durante um ano para cada versão secundária de qualquer funcionalidade ou serviço que esteja geralmente disponível(DG). O período de apoio técnico começa quando a funcionalidade do componente ou uma versão secundária é lançada oficialmente como parte de um lançamento da GDC e publicada, e não quando é implementada pelo utilizador. Determinadas funcionalidades podem estar disponíveis durante um período de tolerância adicional específico do serviço após o fim do período de apoio técnico oficial e antes de a versão da funcionalidade ser desativada. Durante este período de tolerância, as versões não suportadas dos componentes de software não vão receber patches nem suporte técnico. No entanto, o software e a documentação vão continuar disponíveis para permitir que os utilizadores atualizem para uma versão suportada.
A GDC reserva-se o direito de pedir aos utilizadores que migrem para uma funcionalidade mais recente ou uma versão secundária para mitigar o risco de vulnerabilidades de segurança críticas que não podem ser corrigidas em funcionalidades ou versões secundárias mais antigas. Esta situação é rara, mas, por vezes, não é possível aplicar patches de segurança a versões antigas de funcionalidades ou versões secundárias de componentes. Por isso, é importante tomar medidas para proteger os dados e as cargas de trabalho dos utilizadores.
Os patches de segurança são fornecidos de acordo com os objetivos ao nível do serviço (SLOs) aplicáveis para as funcionalidades de pré-visualização e disponibilidade geral (GA). No entanto, os compromissos do contrato de nível de serviço (SLA) do GDC não são aplicáveis às funcionalidades de pré-visualização. Os SLAs aplicam-se apenas às funcionalidades do GA.
As funcionalidades que existem apenas na pré-visualização podem ser descontinuadas ou removidas sem aviso prévio. A retrocompatibilidade pode não ser mantida quando as funcionalidades passam de uma versão de pré-visualização para outra ou para diferentes versões da API de pré-visualização. Os lançamentos de funcionalidades de pré-visualização são encerrados quando as respetivas capacidades chegam ao canal estável.
As versões GDC (funcionalidade, secundária e patch) têm de ser aplicadas pelos operadores de infraestrutura (IOs) à implementação e às organizações associadas assim que possível. A versão de lançamento da GDC é uma versão interna e só é visível para os OIs.
Uma nova funcionalidade do GDC ou uma versão secundária tem de ser aplicada no prazo de 60 dias após a publicação do lançamento e, o mais tardar, no prazo de 120 dias (período de tolerância), salvo indicação em contrário da equipa do GDC.
Tem de aplicar uma nova versão de patch do GDC assim que possível, especialmente se a versão de lançamento contiver correções críticas necessárias para a segurança e a conformidade. As versões de patches do GDC podem ser ignoradas para ficar a par da versão mais recente. No entanto, não é possível ignorar a funcionalidade ou as versões secundárias, e todas as versões têm de ser aplicadas.
Os administradores da plataforma (PAs) são responsáveis por fornecer janelas de manutenção (MW) adequadas para a organização ou a plataforma, para que o operador e a automatização possam aplicar atualizações e patches prontamente.
Os operadores de infraestrutura (IOs) têm de atualizar para a versão de patch mais recente disponível para cada funcionalidade ou uma versão secundária, a menos que a GDC indique explicitamente o contrário, para evitar a perda de correções de segurança e de erros.