PMM ( Plataforma Merdeka Mengajar ) é um superaplicativo para professores desenvolvido pela GovTech Edu. Possui muitos recursos para apoiar o processo de ensino dos professores e aumentar a qualidade. No momento da redação deste artigo, temos mais de 2 milhões de downloads, centenas de milhares de DAU, um pequeno tamanho de download (4 MB), uma classificação de 4,7+ na Play Store com mais de 60 mil avaliações e uma taxa diária sem falhas de 99,97% para usuários. Temos 11 engenheiros Android que trabalham remotamente em diferentes cidades do país. Você pode ler mais sobre o PMM aqui .

Todos esses bons números são apenas “números”; a verdadeira questão é, como fazemos isso? Nesta postagem, queremos compartilhar algumas dicas/práticas que fizemos no GovTech Edu que nos mantêm mantendo este aplicativo no mais alto nível, especificamente em usuários sem falhas. A taxa sem falhas é uma das métricas de desempenho vitais mais críticas, mostrando a estabilidade do desempenho de seus aplicativos. Uma taxa sem falhas de 99,97% é impressionante para superaplicativos com mais de 1,3 milhão de MAUs, especialmente considerando que a referência padrão para a indústria de tecnologia é de cerca de 99,00%. Ok, chega de conversa fiada☺️ Vamos pular para a primeira prática abaixo.

Teste seu código

Bem, isso parece clichê (e não tão simples assim), mas é verdade. Bem, pode estar correlacionado indiretamente, em qualquer caso. Ao testar seu código, você deve repensar a lógica e evitar cometer um bug bobo (que pode desencadear uma falha). Nossos engenheiros da GovTech Edu têm sérias preocupações sobre isso. Concordamos em escrever estritamente um teste de unidade, teste e2e e teste de interface do usuário (pirâmide de teste). Temos um pipeline para verificar quando a cobertura caiu e também nos comprometemos com um determinado número como cobertura mínima. A equipe da plataforma de controle de qualidade oferece suporte a esse ecossistema na criação de ferramentas e pipelines de teste.

Alternar tudo

À medida que crescemos e desenvolvemos mais e mais recursos, às vezes ele simplesmente quebra na produção. Não importa quanta cobertura de teste você fez em seus códigos, sh * t acontece. Você escolhe, seja acionado por um servidor com falha ou carga útil de notificação. É por isso que sempre colocamos uma alternância quase em nossos recursos. Os aplicativos móveis têm um problema problemático com a taxa de adoção (ao contrário da web). Você deve fazer mais do que fazer uma atualização e esperar que todos instalem a versão mais recente. Sempre que detectamos uma taxa de falha incomum em um recurso específico, nós a desativamos enquanto tentamos corrigir o problema. Na maioria das vezes, ele não requer nenhuma nova versão, pois é resolvido no back-end, para que possamos ativá-lo após a implantação corrigida. A configuração remota do Firebase é uma ferramenta de alternância gratuita e gratuita.

Aplicativos de plantão

Lembre-se do termo: “Quando todos são responsáveis, ninguém é responsável”. É verdade, pelo menos para nossa equipe da GovTech Edu. Concordamos em agendar uma pessoa de plantão a cada semana para se dedicar ao monitoramento, resposta rápida e qualquer outra operação operacional. A princípio, pensamos que isso era desnecessário, pois os aplicativos não são lançados todos os dias ou mesmo em uma semana. Devemos ter notado que o fator acionado não vem apenas dos próprios aplicativos, mas também pode ser externo, como implantação de serviço, alterações de alternância e atualizações de provisionamento, afetando diretamente os aplicativos.

Quando ocorrem acidentes, o plantão é a primeira pessoa a responder, decidindo a estratégia de conserto ou pedindo ajuda a outras pessoas. O plantão também não é um robô; eles precisam de ferramentas para mantê-lo. Temos um alerta visual e público postado em nosso canal slack, para que o alerta notifique rapidamente o plantão. Um simples alerta do firebase com um webhook slack é o que usamos. Sabemos que existe uma opção de alerta melhor, como o opsgenie, mas é bom o suficiente para nossa equipe. A estratégia a seguir é ajustar o alerta. Você deve evitar fazer o alerta como um alarme falso que todos acabarão ignorando. Como você ajusta o alerta depende de seus aplicativos e equipe: quantos usuários você tem, qual é a média atual sem falhas que você tem, há alguma falha recente que você teme. Pense nisso, discuta com todos os membros relacionados e você encontrará a melodia certa.

Seja exigente ao escolher uma biblioteca.

O erro na biblioteca às vezes é inevitável. Às vezes você acha que seus códigos são perfeitos, você passou no teste e, de repente, ele trava no código da biblioteca. Nós encontramos isso muitas vezes. Devemos ser mais cuidadosos ao escolher qual biblioteca é melhor do que outras. Portanto, a primeira coisa a fazer é verificar o número de problemas em aberto. Se o número for relativamente alto, devemos evitá-lo. Em seguida, use a biblioteca kotlin em vez de java. Descobrimos que a estabilidade melhorou após a migração da biblioteca java para a versão kotlin. Encontre uma biblioteca com excelente reputação com base no número de colaboradores e na última atualização. Devemos evitar bibliotecas que estão inativas há mais de 2 a 3 anos. Ele potencialmente não sincroniza com a atualização mais recente do sistema operacional. Você pode encontrar esses três critérios separadamente,

Estratégia de lançamento

Somos convenientes, a Google Play Store tem um recurso de lançamento gradual. É altamente recomendável lançar aplicativos com um lançamento gradual. É um procedimento defensivo mortalmente simples para evitar grandes colisões em potencial. Normalmente, iniciamos um lançamento abaixo de 10%. Por que este número? Porque é o melhor número para obter uma amostra inicial sem afetar muitos usuários. Depois de um ou dois dias após o lançamento, podemos ver as tendências de falha. Nesse estado, você deve responder a estas perguntas: Alguma nova falha foi encontrada? Essas falhas são potencialmente generalizadas? Temos que lançar um hotfix para corrigir esta falha recente? Essas questões devem ser decididas em conjunto pelos gerentes, QAs e engenheiros. A desvantagem sempre está relacionada a um tempo de lançamento mais longo. Portanto, certifique-se de que seu hotfix valha a pena. Você deseja evitar corrigir uma pequena falha e perder o lançamento de destino,

Vários testes de fabricação de sistemas operacionais e dispositivos

Você encontrou alguns bugs ou travamentos que ocorrem apenas em dispositivos ou sistemas operacionais específicos? Tenho certeza que todos nós temos. É uma boa ideia testar seus aplicativos em diferentes fabricantes de sistemas operacionais e dispositivos. Podemos fazer um teste de fumaça em todos os alvos do sistema operacional e escolher os 10 principais modelos de dispositivos com base na adoção do usuário. Ele está dando mais atenção a um modelo de dispositivo “problemático”, que costuma produzir travamentos. Assim que fizemos isso, evitamos o grande travamento antes do lançamento da produção. Será mais gerenciável assim que pudermos pagar um farm de dispositivos. O laboratório de teste do Firebase tem um farm de dispositivos gratuito, mas limitado; você poderia começar a partir daí. Atualmente, também existem muitos farms de dispositivos baseados em nuvem pagos com preços muito razoáveis.

Alcance-o claramente através de OKR

Por fim, toda a sua organização deve estar ciente e apoiar sua equipe para atingir esse objetivo. Uma das ferramentas padrão para alinhar os objetivos da equipe é usar um OKR. Você pode ler mais sobre OKR aqui . Por que isso é importante? Porque para atingir 99,9x% sem falhas, você precisa de ajuda e suporte de outras pessoas para fazer isso. Quando está no OKR, outros pensariam que significa muito severo. Eles vão notar você, perceber seu objetivo e começar a ajudá-lo. Ele irá catalisar sua estrada esburacada. Seu OKR também deve estar progredindo. Defina-o no mínimo no início, como 99% livre de falhas no primeiro trimestre, depois aumente para 99,3% no segundo trimestre e assim por diante até mantê-lo no nível mais alto possível.