Políticas e protocolos
      Voltar para o início
      1. Central de Conhecimento
      2. Manuais e Artigos
      3. Políticas e protocolos

      Continuidade de Negócios

      O artigo evidencia que o myHotel possui planos de continuidade de negócios documentados, que seguem protocolos projetados para garantir a segurança da informação e a continuidade dos negócios para seus clientes.

      Extrato

      Este documento tem por objetivo evidenciar que myHotel possui planos de continuidade de negócios estabelecidos, que seguem determinados protocolos documentados, e que as políticas de tratamento da informação em torno desses protocolos são elaboradas de maneira a garantir 1) a segurança da informação e 2) a continuidade do negócio para os clientes.

       

      Esta documentación será dividida en seis partes:

      1. Medidas de contingencia
      2. Riscos e controles
      3. Tipos de cenários cobertos
      4. Planos de contingência para desastres
      5. Antecedentes de continuidade de negócios
      6. Processo de suporte e incidentes

      1.- MEDIDAS DE CONTINGÊNCIA

       

      O primeiro antecedente a ser compreendido é que o myHotel tem sua infraestrutura tecnológica hospedada na nuvem, em um único provedor de nuvem chamado "Amazon Web Services" (doravante AWS). É importante notar isso porque dentro do serviço do provedor AWS, existem uma série de medidas que se dividem de maneira diferente nas diferentes camadas da infraestrutura das aplicações, mas todas visam ter respaldadas as informações e configurações de cada uma das partes.

      Para explicar isso melhor, é importante compreender as diferentes camadas da aplicação para, em seguida, explicar as medidas de recuperação para cada uma delas:

       

       

      • Banco de Dados MySQL Aurora

      Esta primeira camada, e provavelmente a mais importante de todas para os propósitos desta documentação, é aquela que contém armazenada toda a informação com a qual os produtos myHotel operam.

      1. Réplica: existe uma réplica constante e instantânea das informações do banco de dados ao longo do tempo, garantindo que a informação não esteja armazenada em um único local, mas sim em dois.
      2. Multi Zona A-Z: o banco de dados está replicado em várias zonas de disponibilidade em nível mundial, gerando um backup de todas as informações do banco de dados globalmente. Isso proporciona um alto nível de segurança contra desastres mundiais, garantindo que, se uma ou várias zonas no mundo falharem em termos de AWS, ainda teremos todas as outras zonas para recuperar as informações.
      3. Snapshots: existe um conceito que a AWS chama de "snapshots", que consiste em uma cópia das informações do banco de dados até uma determinada data. myHotel tem snapshots configurados a cada hora, em um intervalo de datas dos "últimos 30 dias". Isso permite que, em caso de perda de informações (por qualquer motivo) dentro de 7 dias, myHotel seja capaz de recuperar o que estava disponível até aquele momento.

       

      Dado os pontos a, b e c, myHotel possui a capacidade absoluta de recuperar as informações do banco de dados diante praticamente qualquer evento, pois tem tudo respaldado por até 7 dias, distribuído globalmente, e ainda com uma cópia em tempo real em uma máquina diferente.

       

      • Camada de Cache

      Com o objetivo de fornecer um serviço melhor e mais eficiente, foi implementada uma camada de cache com REDIS usando o produto da AWS "Elasticache". Isso nos permite armazenar informações "estáticas" ou com baixa taxa de modificação (como as estruturas das pesquisas) e também consultas complexas de realizar (heavy queries). Por fim, os resultados são mantidos na memória por um tempo definido (conforme o caso) para evitar ter que consultar o banco de dados repetidamente, permitindo assim que sua capacidade seja utilizada para processos que realmente a necessitem. Além disso, há uma melhoria significativa no desempenho em comparação com consultas diretamente no banco de dados.

       

      • Back-end (orientado a microserviços)

      Esta segunda camada é onde está toda a lógica de negócios dos produtos myHotel. Para esta camada, é utilizado um balanceador de carga de aplicativos, que, por meio de rotas definidas, direciona o tráfego de entrada para o microserviço correspondente. Cada microserviço está hospedado em um serviço chamado Elastic Beanstalk, que finalmente gerencia uma "receita" de máquinas que são implantadas em instâncias EC2. Ele controla suas atualizações, patches de segurança, distribuição de carga e escalabilidade horizontal (em caso de muito tráfego, cada microserviço adiciona máquinas idênticas usando a receita para poder oferecer um serviço de qualidade em momentos de grande estresse).

      Em termos de informações armazenadas, não há informações dos clientes guardadas nesta camada, apenas a nível de banco de dados. Apenas as informações transitam por esta camada. O que é armazenado são os códigos das aplicações myHotel, os quais são respaldados das seguintes maneiras:

      • Repositórios: são os locais onde os códigos são armazenados. Esses são de natureza privada e estão hospedados em um repositório Git privado. Este provedor permite acessar todas as versões dos códigos que existiram desde que você começou a operar com eles, e myHotel começou a operar com eles desde 2016.
      • Versões: cada microserviço mantém um registro e backup de cada deploy realizado nele e, se necessário, permite reverter esses deploys em apenas alguns segundos. Além disso, essas versões são usadas pela receita para escalar horizontalmente ou substituir instâncias que precisam ser patcheadas ou substituídas sem afetar o serviço.

       

      • API Gateway

      Esta camada é fundamental para o monitoramento do tráfego e a segurança das APIs, pois controla o acesso a elas com metodologias de segurança próprias. Além disso, controla taxas de consumo por segundo/minuto/hora, protegendo assim as camadas mais profundas da infraestrutura. 

      Essa ferramenta da AWS é responsável por definir por quais rotas a camada de front-end e o back-end se comunicarão. Ela nos permite mapear quais endpoints queremos expor e quais queremos deixar para uso interno. Além disso, podemos manter um registro dos deploys realizados e voltar a uma versão específica em apenas alguns segundos.

       

      • Front-end en S3 con Cloudfront – Angular

      La camada de front-end de myHotel está hospedada em buckets chamados "S3" na AWS, os quais são replicados instantaneamente em todas as regiões do mundo onde a AWS tem presença (conforme configurado por myHotel). Cada vez que uma versão diferente do aplicativo é carregada no bucket, um registro dessa versão é mantido na AWS e é recuperável. Todas as versões históricas são armazenadas desde que myHotel opera com a AWS, o que, no caso, é desde 2015.

      Além disso, assim como o código do back-end, o código do front-end está hospedado em um repositório Git privado e, portanto, herda todos os mesmos benefícios de recuperação e versionamento mencionados na seção 2. Repositórios deste documento.



      2.- RISCOS E CONTROLES

       

      Esta seção busca enumerar todos os pontos de interação entre softwares que possam gerar alguma interrupção na continuidade do negócio e listar as medidas respectivas em cada um deles para entender as alternativas de contingência para cada software. Além disso, são mencionados os riscos associados à interação entre o software e os funcionários da myHotel que podem ter acesso a informações de clientes, e de que forma os processos garantem uma segurança adequada da informação.

       

      Riscos de software de fornecedores

      • Amazon Web Services (AWS)

      Este fornecedor é responsável por hospedar toda a infraestrutura do software próprio da myHotel na nuvem, tornando-se assim uma peça-chave a ser analisada quanto aos riscos para a continuidade do negócio. 

      A AWS tem demonstrado ano após ano uma média de disponibilidade de seus serviços acima de 99,9%, e muitos dos produtos contratados pela myHotel na AWS têm 100%. Finalmente, essa disponibilidade é diretamente transferida para a myHotel, prometendo assim uma disponibilidade de serviços acima de 99,9%.

       

      • Mailjet by Sinch

      Esta empresa fornece os serviços de envio de e-mails que estão presentes em muitos dos produtos da myHotel, como os envios de e-mails para hóspedes, alertas de pesquisas, avisos do Fidelity Desk, entre outros. Esta empresa tem uma média de disponibilidade de serviços nos últimos 3 anos de 100%, ou seja, nunca apresentou falhas nas entregas de e-mails.

       

      • Hubspot

      Este software é responsável por receber todas as solicitações de suporte dos clientes, tanto os tickets por e-mail quanto os tickets gerados diretamente na plataforma. Este provedor é de classe mundial e baseia sua infraestrutura em nosso provedor comum, a AWS, portanto, os riscos de baixa disponibilidade de seus serviços são, pelo menos, os mesmos da AWS, considerando que eles também têm medidas de contingência no caso de uma queda da AWS.

      Como software alternativo, myHotel possui licença no JIRA Service Desk, um software semelhante em termos dos serviços que oferece de registro de tickets para lidar com os casos de suporte. Em caso de um eventual desastre, este software é ativado em vez do Hubspot.

       

      • Lexalytics

      Este software é responsável por realizar os processamentos de análise semântica dos comentários criados no myHotel, assim como das análises coletadas nos diferentes canais. É importante observar que, embora a Lexalytics faça parte dos serviços fornecidos indiretamente pelo myHotel, não há grandes riscos de que este provedor tenha uma queda temporária, pois a imediatez dos resultados tem um intervalo de cerca de 10 minutos em cenários normais, dando tempo para reagir caso isso aconteça.



      Controles de acesso à informação dos clientes

      Na myHotel, existem funcionários com diferentes acessos à informação dos clientes, de acordo com as necessidades de cada área e/ou cargo. Em última análise, podemos dividir o acesso à informação dos clientes em duas grandes categorias:

      1. Acesso direto ao banco de dados (BBDD): nesta categoria, apenas os funcionários da myHotel da área de TI (desenvolvimento) que têm acesso ao ambiente "PROD" possuem acesso. Esses acessos são concedidos apenas aos chefes de área que realizam atualizações neste ambiente produtivo. A chave que decodifica a informação está armazenada em um local seguro na conta raiz da AWS, à qual apenas o CTO da empresa tem acesso, garantindo que nenhuma informação direta do banco de dados de nenhum cliente possa vazar por parte dos funcionários da myHotel na área de TI. No caso de um funcionário da área de TI ser desvinculado, geralmente não há grandes mudanças a serem feitas, pois eles têm acesso apenas ao banco de dados de desenvolvimento, e todos os outros acessos são controlados pelo Administrador do Google Suite. Em poucos cliques, o acesso a tudo que ele ou ela tem é removido, garantindo assim que no processo de saída da empresa não ocorram vazamentos de informações.

      2. Relatórios "Customizados": Nesta categoria, diferentes pessoas de diferentes áreas da empresa têm acesso para obter relatórios de usabilidade e desempenho dos clientes, a fim de acompanhar adequadamente o funcionamento dos produtos contratados e fornecer um serviço personalizado para cada cliente. A myHotel aproveita as sinergias do Google Suite e utiliza o Google Sheets para se conectar às bases de dados por meio de scripts e gerar relatórios personalizados para diferentes áreas. Eles podem autogerenciar o conteúdo conforme parâmetros, como data de início, data de término, tipos de clientes, etc.

        As informações contidas nesses relatórios nunca incluem informações sensíveis, como nomes de passageiros, números de telefone, e-mails, ou qualquer coisa pessoal de cada hóspede. Os relatórios contêm informações agrupadas de vários clientes e/ou mostram números gerais em relação ao desempenho da ferramenta.

        Por fim, como o Google Sheets possui por padrão um critério de permissões que pode ser autogerenciado pelo Administrador, sempre que funcionários são desvinculados, imediatamente perdem o acesso a esses relatórios ao desativar essa conta no Google Suite.

       

      3.- TIPOS DE CENÁRIOS COBERTOS

       

      • Cenários de desastres tipo COVID-19 (pandemias)

      Do lado dos funcionários, a empresa está preparada para operar 100% remotamente, de modo que em caso de surgimento de uma pandemia, ou mesmo de uma recorrência de COVID-19 no futuro, a myHotel está operando normalmente de forma remota, fornecendo a cada funcionário as ferramentas necessárias para realizar suas tarefas.

      Quanto à continuidade dos serviços de software, estamos protegidos por todas as frentes mencionadas na seção de Riscos e Controles, tendo alternativas para cada um dos provedores e, assim, garantindo um plano B para as diferentes funcionalidades principais.

       

      • Cenários de desastre de fornecedores chave

      Como mencionado na seção de Riscos e Controles, estamos preparados para mudar de fornecedores chave assim que ocorrer algum desastre ou queda no serviço de qualquer um deles. Vale ressaltar que o fornecedor mais importante é a Amazon Web Services (AWS), e no caso de uma falha global de seus serviços, isso afetaria uma grande porcentagem da população mundial, considerando que eles hospedam cerca de 70% das infraestruturas tecnológicas das empresas. Seria um evento prejudicial para muitos. Este é o mesmo risco compartilhado por muitos, o que também leva a AWS a ser o principal provedor, considerando todos os possíveis cenários catastróficos. Eles replicam suas infraestruturas em várias zonas, têm sistemas de Snapshots constantes e adotam muitas outras medidas de acordo com os mais altos padrões mundiais.

       

      • Cenários de redução de pessoal

      Una possibilidade de afetar os padrões dos serviços fornecidos pela myHotel é a ocorrência de uma redução de pessoal. É importante destacar que a myHotel, ao passar pela pandemia de COVID-19, enfrentou uma situação semelhante em que mais de 50% de seus funcionários foram reduzidos. Durante todo o ano de 2020, a empresa conseguiu se reorganizar para atender a todos os seus clientes da mesma forma. Em outras palavras, a pandemia obrigou a myHotel a reinventar muitos processos e estruturas internas, otimizando o uso de recursos e sendo capaz de atender a ainda mais clientes do que antes, com menos de 50% do pessoal. Isso demonstra uma organização robusta diante de cenários adversos.

      Dado que os responsáveis por declarar estados de desastre e executar o plano são o CEO e o CTO da empresa, estritamente falando, é necessário apenas que os dois estejam presentes na empresa em um cenário de desastre, pois são os encarregados de responder e liderar. A redução de pessoal em outras áreas, como Customer Success, Onboarding ou na área de TI, não é crítica para a execução de todos os planos de contingência.

       

      • Cenários de ciberataques

      Existem inúmeras possibilidades de como um ciberataque pode ser realizado em uma empresa de Software Web como a myHotel. Em geral, podemos dividir em 2 potenciais consequências de um ciberataque:

      1. Vazamento de informações de clientes: Como mencionado em outras seções, o Banco de Dados é muito bem protegido, e suas informações de pesquisa são criptografadas para proteger os dados. Além disso, toda interação com os usuários da plataforma ocorre por meio de protocolos de segurança (conexões via SSL, controle de acesso à rede, uso de tokens de usuários, etc.), e as informações são criptografadas em tokens de segurança fornecidos pelo Spring Security na camada de back-end, oferecendo um nível mais alto de segurança. A possibilidade de roubo de informações de um usuário válido e, através dele, o download de relatórios de um cliente é responsabilidade de cada um dos nossos clientes proteger suas credenciais e alterar senhas caso identifiquem um roubo. Tudo isso pode ser autogerenciado pela plataforma, tornando a myHotel um "processador" de informações, conforme regulamentação internacional GDPR, à qual a myHotel é compatível.

      2. Paralisação do serviço oferecido: Os ciberataques também buscam derrotar o sistema alvo (que seria o site myHotel) por meio de várias formas, sendo a força bruta a mais utilizada. Identificamos plenamente todos os pontos críticos onde poderiam explorar algum endpoint ou outro mecanismo para tentar sobrecarregar o sistema e fazê-lo "cair", e cada um desses pontos possui múltiplas medidas de segurança para consumi-los, com restrições por IP, domínio e VPC interno da AWS sendo as mais comuns, garantindo assim que apenas entidades "conhecidas" serão aquelas que interagem na troca de informações.

        A myHotel sofreu tentativas de ciberataques, muitos deles originados no continente asiático (China e Japão), e não conseguiram violar a segurança. Além disso, a infraestrutura da AWS demonstrou ser sólida em suas configurações de Security Groups, garantindo que apenas um grupo específico de máquinas seja identificado e possa se comunicar entre si, protegendo-nos assim contra os ataques de força bruta, que são bastante comuns.



      • Cenários de perda de informações armazenadas

      Como mencionado no primeiro ponto deste documento, myHotel possui uma série de medidas de contingência em diferentes camadas para recuperar informações. Em geral, é possível recuperar pelo menos os últimos 7 dias em qualquer momento, portanto, se for identificado a tempo, pode ser recuperado sem qualquer problema.

       

      4.- PLANOS DE CONTINGÊNCIA DIANTE DE DESASTRES

       

      O procedimento para situações de desastre contempla muitos aspectos que abordaremos um a um nesta seção, a fim de apresentar um plano prático de continuidade de negócios em caso de desastres de diferentes naturezas. A seguir, revisaremos todos esses pontos em ordem, de acordo com o que deve ser feito em caso de um desastre que comprometa a continuidade dos negócios:

       

      A. Ativação do Plano de Contingência

       

      "No evento de um desastre que comprometa qualquer um dos pontos mencionados no item 2 desta seção, Sebastian Giacoman, CEO da myHotel, deverá declarar um estado de 'desastre' na empresa e, em seguida, ele mesmo deverá tomar a decisão de ativar as fases de recuperação de acordo com as prioridades mencionadas no item 2 desta seção, conforme o caso de desastre."

       

      B. Prioridades de recuperação de funcionalidades do negócio

       

      Antes de executar o plano de contingência, é necessário ter um conjunto de prioridades definidas para as diferentes funcionalidades do negócio a serem recuperadas no caso de um desastre. Geralmente, nestes casos, não ocorre um desastre que envolva toda a infraestrutura de um negócio, mas sim alguns elementos, e geralmente é apenas um. Para recuperar a continuidade do negócio, deve-se proceder de acordo com esta ordem de prioridades de recuperação:

      1. Correo eletrônico, arquivos compartilhados e soluções de teleconferência compartilhados entre todos os funcionários da empresa: myHotel tem isso hospedado no Google Suite, portanto, segue os Acordos de Níveis de Serviço do Google, que prometem um tempo de atividade superior a 99,9%, com a garantia de que todas as informações estão replicadas em vários data centers globalmente para recuperação.
      2. CRM de Clientes: isso está hospedado em um único provedor chamado HubSpot, que possui Acordos de Níveis de Serviço e Recuperação semelhantes ao Google, no sentido de que as informações estão distribuídas globalmente e é possível recuperar as informações em caso de desastres.
      3. Software de Infraestrutura Tecnológica em Nuvem: neste caso, a myHotel utiliza a AWS, explicada na primeira seção deste documento, onde todas as camadas são detalhadas quanto à recuperação e todas as medidas existentes em cada uma delas para garantir a recuperação das informações.
      4. Software de Faturamento e Contabilidade: para esses fins, a myHotel utiliza um provedor chamado Xero, que, assim como os outros provedores em nuvem, promete tempo de atividade acima de 99,9% e réplicas das informações globalmente.
      5. Software de Gerenciamento de Projetos: neste caso, a myHotel utiliza o provedor JIRA para gerenciar projetos tecnológicos.
      6. Realocação do Domínio: myHotel opera sob o domínio myhotel.cl, onde todas as soluções para clientes estão direcionadas, assim como o site público. Além deste domínio, myHotel possui myhotel.com.es, fidelitycx.com e myhotel.io, qualquer um dos três poderia ser usado para redirecionar todo o negócio, se necessário.

       

      C. Procedimentos de Recuperação

       

      1. Ocorrência do 'desastre': nesta primeira fase, inicia-se com a ocorrência do evento que gera o desastre e continua até a decisão de ativar os planos de recuperação. Nesta fase, os líderes de cada área da empresa, sob a liderança do CEO, devem notificar as pessoas em suas equipes sobre o evento, fazer um diagnóstico preliminar dos danos causados, avaliar as repercussões nas atividades do negócio, ativar os planos de contingência e, finalmente, fazer a transição para o funcionamento das operações principais da empresa.
      2. Notificação do 'desastre': os líderes de cada equipe informam aos membros da equipe que ocorreu um desastre. Dependendo da natureza do desastre, as equipes receberão instruções sobre o que fazer.
      3. Diagnóstico preliminar dos danos: os líderes de cada equipe devem fornecer um relatório ao CEO da empresa sobre os danos causados que envolvem suas respectivas áreas.
      4. Diagnóstico das repercussões nas atividades do negócio: após um diagnóstico preliminar dos danos, o CEO da empresa, junto com todos os líderes das áreas, deve fazer uma análise da situação para decidir quais ações tomar para recuperar a continuidade do negócio.
      5. Ativação dos planos de contingência: nesta fase, os planos de continuidade de negócios são colocados em prática. Para a infraestrutura da aplicação de negócios hospedada na AWS, o procedimento seguirá o ponto 4 desta seção.
      6. Transição para as funções principais da empresa: nesta fase, são consideradas todas as atividades necessárias para retomar as funções principais da empresa, garantindo a continuidade dos negócios para seus clientes.

       

      D. Planos de contingência - Infraestrutura Cloud do Negócio


       

      Conforme explicado neste documento, é necessário abranger cada uma das camadas afetadas da infraestrutura com o objetivo de retomar as operações comerciais voltadas para o cliente. Portanto, para cada camada, é necessário restaurar até o último ponto de recuperação salvo:

      1. Base de Dados MySQL Aurora: dependendo do desastre, é possível redirecionar para a réplica do banco de dados, ou recuperar uma das instâncias replicadas em várias zonas A-Z, ou ainda, criar um novo banco de dados com as informações salvas no último snapshot que a AWS guardou antes do desastre.
      2. Back-end em JAVA: dependendo do desastre, é possível recuperar o código-fonte do repositório Git em sua última versão salva por esse provedor, ou recuperar um snapshot das aplicações afetadas pelo desastre na AWS, ou ainda recuperar uma das versões previamente guardadas na AWS para cada aplicação.
      3. API Gateway: dependendo do desastre, neste caso, é necessário recuperar o arquivo .YAML que está salvo na AWS para cada versão que foi enviada. Alternativamente, esses .YAML também estão salvos no Gitlab para cada aplicação, então também podem ser recuperados a nível de código.
      4. Front-end em S3 - Angular: dependendo do desastre, é possível recuperar a última versão salva no S3 da AWS, ou recuperar uma das réplicas em várias zonas A-Z também salvas na AWS, ou ainda recuperar a última versão do código do bucket no Gitlab e criar um novo bucket S3 com essa versão.

       

      5.- HISTÓRICO DE CONTINUIDADE DE NEGÓCIOS

       

      Nesta seção, busca-se documentar os antecedentes de continuidade do negócio, a fim de fornecer evidências de que o serviço prestado nos últimos 7 anos cumpriu com os Acordos de Níveis de Serviço prometidos nos contratos. Isso se concentra principalmente na disponibilidade da aplicação "Fidelity Suite", que abrange todos os produtos myHotel oferecidos. O myHotel opera com uma infraestrutura de alta disponibilidade, tendo réplicas dos buckets S3 em todas as zonas e réplica do banco de dados MySQL Aurora, sendo os principais fatores que afetam esse funcionamento.

       

      2018

      BBDD MySQL Aurora: Uptime/Disponibilidad 100%

      Buckets S3: Uptime/Disponibilidad 99.99%

      *NOTA: Houve um evento este ano que causou uma interrupção no produto "Followup" por cerca de 12 horas, resultando em uma disponibilidade de 99,99% para os buckets (foi apenas um dos cinco produtos).

       

      2019

      BBDD MySQL Aurora: Uptime/Disponibilidad 99%

      Buckets S3: Uptime/Disponibilidad 99%

      *NOTA: Houve um evento este ano que resultou em uma paralisação no banco de dados, que foi programada e comunicada a todos os clientes, por cerca de 4 horas em um domingo. Isso ocorreu devido a uma migração do banco de dados para uma versão aprimorada.

       

      2020

      BBDD MySQL Aurora: Uptime/Disponibilidad 100%

      Buckets S3: Disponibilidad 100%

      *NOTA: Não ocorreram eventos durante o ano de 2020 que tenham causado uma interrupção no serviço de nenhum dos produtos.

       

      2021

      BBDD MySQL Aurora: Uptime/Disponibilidad 100%

      Buckets S3: Disponibilidad 100%

      *NOTA: Não ocorreram eventos durante o ano de 2021 que tenham causado uma interrupção no serviço de nenhum dos produtos.

       

      2022

      BBDD MySQL Aurora: Uptime/Disponibilidad 100%

      Buckets S3: Disponibilidad 100%

      *NOTA: Não ocorreram eventos durante o ano de 2022 que tenham causado uma interrupção no serviço de nenhum dos produtos.

       

      2023

      BBDD MySQL Aurora: Uptime/Disponibilidad 100%

      Buckets S3: Disponibilidad 100%

      *NOTA: Não ocorreram eventos durante o ano de 2023 que tenham causado uma interrupção no serviço de nenhum dos produtos.

       

      2024 - YTD

      BBDD MySQL Aurora: Uptime/Disponibilidad 100%

      Buckets S3: Disponibilidad 100%

      *NOTA: Não houve eventos durante 2024 que tenham causado uma interrupção no serviço de nenhum dos produtos.

       

      6.- PROCESSO DE SUPORTE E INCIDENTES

       

      El processo de suporte é gerenciado pelo setor de Pós-venda (Customer Success), que é responsável por receber todos os tickets de suporte e, finalmente, fornecer uma resposta ao cliente. Em um cenário normal, não há interação entre desenvolvedores e clientes para criar um filtro prévio entre uma área de interação com os clientes e outra que não interage com o cliente final. Dessa forma, ocorre a seguinte interação: Cliente -> Pós-venda, Pós-venda -> Área de TI, Área de TI -> Pós-venda, e Pós-venda -> Cliente.

       

      A comunicação entre Cliente e Pós-venda é realizada por meio do software Hubspot, que nos fornece o formulário dentro da Fidelity Suite, assim como qualquer ticket enviado para suporte@myhotel.cl. Em seguida, dependendo do caso, a maioria dos tickets não exige interação com a Área de TI, pois não há questões técnicas. Nestes casos, eles respondem diretamente (geralmente são questões conceituais e relacionadas a indicadores e seus cálculos). No entanto, se for necessária a intervenção da Área de TI, é criado um ticket de suporte interno para resolução e, posteriormente, a resolução é comunicada em termos comerciais.

       

      Existem casos em que é necessária a interação entre desenvolvedores da myHotel e clientes. Para esses casos, são agendadas reuniões programadas sobre um tema específico e a questão é resolvida diretamente entre as duas partes. Isso ocorre raramente, geralmente em desenvolvimentos personalizados para grandes clientes ou situações particulares que fogem do escopo normal.

       

      Os Acordos de Nível de Serviço (SLA) fornecidos pela myHotel preveem uma resposta inicial em 24 horas úteis e uma média de 72 horas úteis para resolução. No último ponto, é importante destacar que o tempo é uma média, uma vez que a natureza dos tickets nem sempre é a mesma, e muitas vezes novos requisitos são confundidos com problemas existentes no sistema. Qualquer problema existente no sistema é tratado com extrema urgência dentro da Área de TI e deve ser resolvido "o mais rápido possível". Em outras palavras, há pessoal dedicado à Continuidade Operacional dentro da Área de TI, e assim que recebem um "bug" que está em ambiente produtivo, eles interrompem suas atividades para resolvê-lo o mais rápido possível, geralmente em questão de horas.