Ao projetar sistemas de IoT, por exemplo, compartilhamento de carros, é muito importante considerar possíveis falhas. Caso contrário, você encontrará uma carga crítica no suporte técnico e na insatisfação do cliente.
Estacionamento "Skolkovskaya"Falhas acontecem em todos os lugares. Mas no mundo da "Internet das coisas", esse é um estado permanente. Ao trabalhar com redes e hardware móveis, as falhas ocorrem com muito mais frequência do que no desenvolvimento da Web ou móvel.
A confiabilidade dos sistemas sofre por várias razões, incluindo prazos apertados e orçamentos de desenvolvimento limitados. Mas a IoT pode funcionar se possíveis falhas não forem negadas, mas aceitas e tentar resolver o problema. Se estiver interessado, há um
artigo interessante sobre métodos para aumentar a tolerância a falhas, mas agora está mais próximo do assunto.
Você abre o carro pelo telefone, o que poderia dar errado?
As etapas podem depender da arquitetura do sistema, mas o cenário geralmente é este:
Você clica no botão "Reserve agora". Um comando é enviado ao servidor. Ela pode ou não andar.
Você clica no botão "Abrir carro". Um comando é enviado ao servidor. Ela pode ou não andar. O servidor envia um comando para a máquina. Ela pode ou não andar. O dispositivo de bordo está tentando executar o comando. Pode ou não ser cumprido.
Você clica no botão "Iniciar viagem". Um comando é enviado ao servidor. Ela pode ou não andar. O servidor envia um comando para a máquina. Ela pode ou não andar. O dispositivo de bordo está tentando executar o comando. Pode ou não ser cumprido.
Sim, isso é uma quantidade superficial e de fato uma quantidade insana de problemas, mas agora vamos considerar apenas esses.
Suponha que todas as equipes tenham alcançado e todos os atuadores tenham funcionado - sucesso! Isso pode ser demonstrado aos investidores.
Algo deu errado
Mas o que acontece se, por exemplo, o comando "Portas abertas" não chegar ao carro?
Em primeiro lugar, o servidor deve descobrir isso. Para que o estado real da máquina seja sincronizado com o servidor, geralmente é usado o reconhecimento de comando (ACK). E mais uma confirmação da execução da equipe. Afinal, “a equipe não foi entregue” e “a equipe não foi executada” são eventos diferentes e envolvem diferentes tentativas de solução.
Em segundo lugar, (se o problema não puder ser resolvido, por exemplo, reenviando o comando), é necessário relatar o erro ao usuário e não colocá-lo no estado "trip".
No Delimobile, você começará a viagem.
E uma conversa com o operador do suporte técnico.
A história
Eu trabalho em Skolkovo. Devido às dificuldades com a acessibilidade no transporte, como muitos colegas, fui trabalhar e voltar todos os dias no compartilhamento de carros. Mas há 3 dias, na zona de estacionamento, a conexão se deteriorou. Por que há problemas com as comunicações móveis no Centro de Inovação é outra questão, mas essa situação deu origem a um problema interessante: os usuários de Delimobile que reservaram um carro estavam realmente presos.
Na noite fria de 24 de setembro, eu estava voltando para casa. Ele reservou um carro e veio até ela.
Clicou em "Iniciar inspeção", mas as portas não se abriram.
- Bem, provavelmente, novamente, uma falha de comunicação. Eu levo outro. Além disso, existem tantos!
Clicou em "Concluir aluguel" - "Você está fora da zona de estacionamento"
Eu chamo de apoio, descrevo a situação. O operador está tentando abrir a porta. Falha. A musica Portas abertas. Obrigada
- Provavelmente os servidores falharam. Ok, vamos lá. Aperto "Start the trip" - o aplicativo começou a contar o dinheiro.
Não inicia.
Eu chamo de apoio, descrevo a situação. O operador está tentando permitir a partida do mecanismo. Falha. "Não há conexão com a máquina."
- Ok, vamos fechá-lo manualmente. Abaixe o vidro, saia, pressione o botão de travamento central, feche o vidro.
O vidro não cai. Aparentemente, sem um comando do servidor, o carro não liga a ignição. Mas não há conexão.
- Então você precisa esperar pelo mecânico. 1-1,5 horas.
"Mas está frio aqui." Existem 3-4 pessoas a mais nos carros Delimobile com telefones. Talvez as peles já tenham sido enviadas a eles ...
<portas do carro fechadas de repente>
Ah, é isso. Obrigada Vou de microônibus.
Como os outros resolvem esse problema
Primeiro, se não houver comunicação com a máquina, talvez ela não deva ser exibida no mapa.
Em segundo lugar, se o servidor soubesse que o comando para abrir as portas não havia sido executado, não teria me transferido para o modo de aluguel. Então, em vez de 40 minutos no frio e uma carga adicional no suporte técnico, eu veria apenas uma mensagem de erro.
Em terceiro lugar, você pode criar um canal de comunicação de backup - um segundo modem com outra operadora (eu tinha Internet no telefone). Ou Bluetooth, como é feito no Squirrel e no YouDrive. (Talvez essa opção não seja para a Delimobile, pois aumentará os custos de desenvolvimento e suporte, e o DM é o mais barato entre as massas)
Enquanto isso, a Delimobil salva os carros "fechados manualmente" e carrega seu suporte técnico devido à falta de confirmação da entrega das equipes de controle. Ao mesmo tempo, carros sem comunicação são visíveis no mapa e estão disponíveis para reserva.
Esse é um problema mais amplo.
Tenho certeza que os engenheiros da Delimobile são ótimos. Eles resolveram um mar de problemas. Sério. De fato, além do equipamento e do próprio sistema, ainda é necessário construir os processos de comissionamento, manutenção, desativação, etc. Freqüentemente, esses processos também exigem o desenvolvimento de hardware e software.
Mas por que então poderia surgir tal situação? Na minha opinião, existem duas razões prováveis.
O primeiro problema provável são contratados diferentes para o aplicativo, servidores e equipamentos sem o design de nível superior de alta qualidade de todo o sistema. Todo mundo pode ter feito seu trabalho bem, mas a arquitetura geral tem problemas.
A segunda razão provável é inerente a muitos projetos em princípio. O fato é que, para demonstrar (por exemplo, para investidores), não é difícil fazer um protótipo. Talvez isso seja suficiente por várias semanas ou até dias. No entanto, o design e o desenvolvimento de um sistema confiável pode levar um mês ou até anos. Infelizmente, nem todos os gerentes eficazes entendem isso.
Freqüentemente, a liderança eficaz pode exigir novos recursos que eles acreditam aumentar a receita da empresa. Ao mesmo tempo, eles não veem potencial comercial em aumentar a confiabilidade.
O que fazer
Localmente, a Delimobil precisa resolver o problema do estacionamento em Skolkovo. Muitos carros estão ociosos lá. É improvável que eles consigam concordar com uma operadora de celular para melhorar a qualidade da comunicação. Portanto, o resultado mais provável me parece que eles proibirão o estacionamento e transportarão veículos para Moscou por conta própria. Resultado triste :( Você acha que é possível resolver esse problema de uma maneira diferente?
Globalmente, os gerentes técnicos devem defender a necessidade de aumentar a confiabilidade. Pelo menos em Delimobile, eles agora têm uma discussão.
PS Agradecimentos especiais aos caras de suporte técnico atormentados. Eles são educados e tentam resolver o problema.