Get best of the week

Lista de verificação para um arquiteto

Neste artigo, você aprenderá como organizar o processo de construção de um desenvolvimento eficaz em uma empresa digital distribuída, como fazer isso por meio de comunicação especializada e como isso acontece com o exemplo do MTS.

O MTS, como muitas outras empresas modernas, passou pela chamada transformação digital. Em termos simples, o lançamento de processos e produtos digitais se tornou nossa prioridade.

Para mim, como técnico, isso significa que a direção dos negócios na empresa depende inteiramente da qualidade dos sistemas de TI e de sua capacidade de evoluir rapidamente.

Obviamente, essa é uma definição errada, e os profissionais de marketing podem discutir comigo - e até argumentar! Mas para tudo o que você lê abaixo, é o suficiente.



Menos burocracia - desenvolvimento mais fácil


O que mudou: antes de tudo, o modelo de gestão da empresa. Se antes os caras da arquitetura corporativa centralizada (arquitetura corporativa) verificavam cada projeto, agora publicam uma política técnica (um documento grande e inteligente) e treinam arquitetos nela. E como aplicá-lo já é uma questão pessoal de cada arquiteto de produto de mais de cem equipes.
 
Por um lado, isso é bom - menos burocracia, o que simplifica muito o desenvolvimento. Por outro lado, todos os produtos interagem entre si de uma maneira ou de outra, e um erro em um deles pode afetar o outro.

Por exemplo, em Arquitetura de sistemas de software: trabalhando com partes interessadas usando pontos de vista e perspectivas, Eoin Woods e Nick Rozanski escrevem sobre o princípio básico de segurança - proteja o elo mais fraco. Isso significa que, se o seu cenário de TI tiver pelo menos um sistema de TI fracamente protegido, todo o cenário de TI estará em risco. Só porque um atacante hipotético pode trabalhar com impunidade em nome desse sistema.

Existem muitos outros exemplos em que é útil ter qualidade e consistência garantidas no design e desenvolvimento de sistemas de TI.

Especialistas Introvertidos


O que criamos: criar uma comunidade para compartilhar conhecimento e disseminar as melhores práticas. A ideia não é nova e não é muito revolucionária, mas atende aos requisitos e especificidades do desenvolvimento de produtos digitais.

  • — DevOps- support-;
  • , . , , ;
  • - , — . . -, ; -, ; -, ;
  • , ;
  • Organização da rotação em uma equipe de “auditores” para que o maior número possível de representantes da equipe tenha a oportunidade de compartilhar conhecimento e experiência.

Para iniciar o processo, reunimos uma equipe de entusiastas, desenvolvemos uma lista de tópicos de discussão para cada uma das funções e treinamos a equipe de nossos auditores improvisados. A propósito, o treinamento foi o estágio mais difícil, porque muitas vezes bons especialistas em nosso campo também são ótimos introvertidos :-)

Qual é o resultado?




  • O processo de pesquisa de equipes de produtos tem sido bastante lento. Em média, leva cerca de 31 dias para uma equipe. Durante esse período, conseguimos nos comunicar com representantes de todas as áreas de atividades da equipe, elaborar um relatório de memorando e explicá-lo ao proprietário do produto para que ele possa planejá-lo para ação;
  • O resultado do trabalho é muito dependente do especialista. Portanto, é importante que haja várias para cada função: dois analistas, dois arquitetos, etc; onde um já realizou uma série de entrevistas e o outro está envolvido apenas na comunicação;
  • Também é necessário adaptar constantemente a metodologia da entrevista, pois alguns tópicos perdem sua relevância e, em seu lugar, há perguntas que ninguém havia pensado antes.

Por exemplo, vejamos os resultados de um estudo na direção de "Arquitetura".
 
O que nos fizemos:

  • Comunicado com 20 equipes;
  • Cada um passou uma média de 31 dias. Como interagimos simultaneamente com várias equipes, todo o processo levou seis meses;
  • Revelou 180 riscos associados à arquitetura.

 Dentro de nossas equipes, os riscos foram divididos da seguinte forma:


Risco 1: projeto

É importante entender que todos os sistemas de software que estudamos passam por um controle de qualidade de saída bastante rigoroso (por exemplo, os sistemas de telecomunicações têm um período de monitoramento mais longo que o período de desenvolvimento), mas não há limites para perfeição e eficiência .

Para entender o que consideramos riscos, vejamos o TOP-3 com exemplos.

Para equipes de produtos jovens, a situação é bastante normal quando a arquitetura do software é desenvolvida de forma residual. A princípio, parece que tudo é simples, e o tempo dos projetos raramente oferece uma oportunidade para pensar seriamente sobre a organização da arquitetura. E então o método de design de baixo para cima entra em ação - quando desenvolvemos os componentes individuais da solução, após o que os reunimos em um único todo.

Por exemplo, decidimos fabricar um produto digital para telemedicina. O que é necessário para isso?

  • Provavelmente precisamos de um componente para videochamadas entre o paciente e o médico - fazemos um componente para chamadas;
  • Às vezes, você precisa de um bate-papo regular - isso significa que fazemos um componente para o bate-papo;
  • Precisamos tirar o histórico médico de sistemas médicos automatizados - criamos o componente apropriado;
  • Precisamos manter uma agenda de médicos de plantão - fazemos um componente para isso também.

Etc.

Tudo parece simples até começarmos a juntar tudo. E aqui há problemas com a duplicação de funções - por exemplo, chamadas de bate-papo e vídeo são aplicações muito próximas (pelo menos do ponto de vista do contexto da interação médico-paciente). Essa. o risco é que temos que refazer nosso aplicativo de maneira bastante significativa devido à grande quantidade de código duplicado.

Ou problemas com o modelo de dados. Cada componente, por padrão, fornece interfaces nesse modelo, o que é conveniente para armazenar e processar esse componente específico, e não o aplicativo como um todo.
 
Portanto, vale lembrar uma série de regras simples:

  • O método de design de baixo para cima é bom para pequenos projetos com baixa complexidade técnica, equipes pequenas e requisitos voláteis;
  • Para grandes projetos e equipes, o método de design é de cima para baixo, ou seja, quando projetamos a imagem como um todo e depois prosseguimos para a codificação.

Portanto, antes de mergulhar de cabeça em um novo projeto, faça a si mesmo a pergunta: a que tipo pertence?
 

Risco 2: Segurança

Parecia que a segurança está sendo pensada com muita seriedade nos dias de hoje. Todo mundo se lembra de banalidades como necessidade:

  • Autenticar usuários
  • autorizá-los a realizar ações;
  • cumprir o princípio de menos privilégios;
  • manter a confidencialidade dos dados;
  • mantenha um log da auditoria das ações do usuário.

Mas aqui está uma surpresa! Para equipes que prestam serviços para automação interna, isso não é tão óbvio quanto para todos os outros. Parece que, se o aplicativo já está sendo executado na rede corporativa interna, por que protegê-lo ainda? De fato, é necessário, especialmente se os dados com os quais o aplicativo trabalha são classificados como pessoais. Sim, a probabilidade de um invasor penetrar na rede interna é muito pequena, mas não há muita proteção.
 
E com aplicações externas, nuances também podem surgir. Considere um exemplo de aplicativo da Web simples, puramente hipotético, que autentica um usuário com uma senha. Que problemas podem existir:

  • O aplicativo pode permitir que você digite senhas muito simples, que são fáceis de serem capturadas;
  • O aplicativo pode não estar protegido das próprias senhas de força bruta (não há captcha ou algo parecido);
  • . , - ;
  • URL- HTTP- ;
  • -, . , MD5 ;
  • - ;
  • - , . , , -;
  • - : , ..;
  • - HTTP-:

  1. - session tokens , ;
  2. - session fixation- (. . session token );
  3. - HttpOnly Secure browser cookies, session tokens;
  4. - .


Portanto, o risco aqui é que alguém tenha acesso a dados que não se destinam a ele. E isso pode levar a problemas no aplicativo. 
Estes são apenas exemplos do que você pode falar no campo de segurança. Obviamente, a opção ideal seria implementar o processo do Ciclo de Vida do Desenvolvimento Seguro, por exemplo, como recomendado pela Microsoft .


Risco 3: desempenho
 
Um dos desafios da criação rápida de equipes de produtos é uma palavra de três letras. Este é um MVP ou produto valioso mínimo. Essas equipes se esforçam para criar um aplicativo o mais rápido possível, o que começará a gerar receita para a empresa e, como haverá muito poucos usuários no início do aplicativo, eles geralmente pensam nos parâmetros de desempenho no último momento. Mas se o aplicativo criado de repente se tornar popular, você precisará pensar no que fazer a seguir.

As recomendações aqui são simples: o desempenho do aplicativo é inversamente proporcional ao número de solicitações de recursos lentos. Assim, todas as táticas visam reduzir o número de solicitações ou acelerar os próprios recursos. Nesse caso, os recursos são entendidos como um processador, memória, rede, discos; Às vezes, também é conveniente considerar um banco de dados ou servidor de aplicativos como um recurso.
 
  • Primeiro, examinamos se é possível fazer um cache de cliente em um aplicativo distribuído, para que cada vez que não solicitemos / calculemos os dados necessários. Se isso for possível, economizamos em solicitações de rede, carregando recursos do servidor e tudo o que ele faz lá.
  • Mas é muito raro ter sorte, então estamos procurando ver se podemos fazer um cache do servidor. Com isso, o princípio é o mesmo que com o cliente, mas o ganho de desempenho é um pouco menor, porque as solicitações de rede ainda vão;
  • , . , , , , (load balancer);
  • , . — My SQL Cluster Grid Edition Apache Ignite (Gridgain).

Bem, é claro, devemos lembrar que o próprio cache resolve o problema de acesso aos dados, mas cria um novo problema com o algoritmo para invalidação e pré-carregamento. E em alguns sistemas, o armazenamento em cache pode ser completamente inútil. Por exemplo, nos sistemas CRM (Customer Relationship Management), raramente é possível armazenar em cache os dados do cliente com eficiência. Um especialista que trabalha no escritório muda muito rapidamente de um cliente para outro e o cache simplesmente não é usado.

Portanto, o risco aqui é que, sem pensar primeiro na estratégia de como "overclockaremos" nosso aplicativo, poderemos ter custos muito altos para reescrevê-lo no futuro.

Resumindo


Neste artigo, tentei falar sobre como você pode organizar o processo de construção de um desenvolvimento eficaz em uma empresa digital distribuída por meio de comunicação especializada. Em nosso tempo de desenvolvimento remoto, esses processos se tornam especialmente relevantes. Eles permitem que você destrua a lei de Conway , ou pelo menos a minimize.
 
Se você decidir criar suas próprias listas de verificação, recomendo não fazer tudo do zero, mas tirar algo da literatura existente. Por exemplo, na arquitetura, o material de revisão Manual do arquiteto de software de Joseph Ingeno ISBN é muito útil: 9781788624060

Meu relatório pode ser encontrado aqui

Autor do artigo: Dmitry Dzyuba, chefe do centro de P&D
 

More articles:


All Articles