As dores das startups: como desenvolver correctamente a infraestrutura informática

Se cres estatísticas, só o 1% das startups sobreviven. Non imos discutir as razóns deste nivel de mortalidade; este non é o noso asunto. Preferimos dicirche como aumentar a probabilidade de supervivencia mediante unha xestión competente da infraestrutura de TI.

As dores das startups: como desenvolver correctamente a infraestrutura informática

No artigo:

  • erros típicos das startups en TI;
  • como enfoque de TI xestionado axuda a evitar estes erros;
  • exemplos instrutivos da práctica.

Que ten de malo TI para startups?

Cabe aclarar que por startups non entendemos unha cafetería ou un insectario nun centro comercial. Estamos sobre as startups tecnolóxicas, sobre aqueles que están perseguidos polo éxito de GitHub, Uber, Slack, Miro, etc.

As startups sempre teñen moitos problemas que lles impiden despegar: desde investimentos insuficientes ata un modelo de negocio sen desenvolver. Na mesma liña, curiosamente, está o problema dos primeiros éxitos.

Os primeiros éxitos son malos para as startups que sobreestiman as súas capacidades, especialmente financeiras e de persoal. Despois de pechar os primeiros casos exitosos, estes optimistas teñen o desexo de expandirse inmediatamente: alugar outra oficina, contratar novos vendedores e desenvolvedores para o equipo e, ao mesmo tempo, escalar o backend (e cunha marxe). Aquí é onde aparece inmediatamente o problema número 1.

A xente dunha startup fai cousas que non saben facer.

E non fan o necesario para desenvolver unha startup. Déixame explicar.

Cada startup debe ter polo menos tres funcións:

  • especialista en informática (ou tecnólogo);
  • vendedor (ou comerciante);
  • un visionario (ou un emprendedor que tamén adoita ser investidor).

Moitas veces estes papeis son mesturados. Por exemplo, unha startup é un especialista en informática que, ademais, vese obrigado a vender. Nunca vendeu e faino como pode. Tal inicio é unha especie de equipo multifuncional maligno.

Pero digamos que a startup ten sorte: hai alguén a quen vender e o especialista en informática está a ocuparse dos seus propios negocios. Non obstante, é raro que un especialista en TI combine diferentes cualificacións: desenvolvedor, probador, administrador, enxeñeiro arquitecto. E aínda que se combine, é pouco probable que sexa igual de bo. Pode que entenda o middleware, pero non tanto cos servizos na nube e o software de virtualización.

As dores das startups: como desenvolver correctamente a infraestrutura informática

Cando o backend se expande, a carga do especialista en TI aumenta. Algo comeza a "caerse". O peor é se esta é unha área crítica para a posta en marcha, como o desenvolvemento de produtos. E agora unha persoa ten que facer horas extras, e ás veces todo o día.

A sobrecarga por falta de persoas e cualificacións é unha característica da maioría das startups, consecuencia do feito de que a xente está a facer o mal.

Todos os servizos están implantados nunha máquina virtual

As startups adoitan, baseándose nas súas propias ideas sobre o aforro, colocan contornas de desenvolvemento, bases de datos, un servidor web, monitorización, etc., nunha máquina virtual. Ao principio, todo este negocio funciona de forma máis ou menos tolerable. Os problemas comezan cando precisa escalar.

As startups adoitan escalar verticalmente. É dicir, simplemente aumentan o número de CPU, a cantidade de RAM, discos, etc. Este é un enfoque monolítico clásico, cuxo efecto negativo nalgún momento faise irreversible. Se unha empresa nova crece, nunha determinada etapa o prezo do aumento dos recursos salta a un nivel inaccesible. Neste caso, só hai unha forma de optimizar a infraestrutura: remontala.

Como axuda a TI xestionada

Para este tipo de proxectos contamos cun servizo de clase de servizos xestionados - DevOps xestionado.

O cliente recibe fóra da caixa:

  • preparando os ambientes necesarios para o traballo: dev, test, prod;
  • procesos CI/CD configurados;
  • ferramentas preparadas para o traballo en equipo: rastreadores de tarefas, sistemas de control de versións, despregamento, probas, etc.

A nivel de infraestrutura e ferramentas, todas as startups necesitan aproximadamente as mesmas cousas. Se comparas o mercado de risco coa minería de ouro, Managed Services Provider (MSP) ofrece ferramentas novas e de alta calidade: picos e carros que non se rompen, mapas que non menten. O buscador só ten que escoller un lugar onde cavar.

Pros das TI xestionadas

A TI xestionada é un servizo integral que cobre unha serie de necesidades obrigatorias.

  • Ao principio, proporcionamos os recursos necesarios e personalizados para traballar, crecer e probar hipóteses.
  • Podemos dicir exactamente como aumentará o custo ao escalar, porque sabemos que a métrica clave é a converxencia da economía da startup.
  • Ofrecemos consultas para aforrar ás startups unha cantidade significativa de horas de traballo. Tamén podemos axudar cos cálculos da economía unitaria do proxecto.
  • Compartimos as mellores prácticas do mercado. A xente de ITGLOBAL.COM traballou con bastantes startups. Moitas destas startups son mensualmente. Isto permítenos reunir os mellores (e peores) exemplos e compartir as nosas experiencias cos clientes.

Dous casos da práctica

Segundo a NDA, non podemos nomear empresas concretas, pero o alcance e o produto, si.

Esfera: fintech/retail

Descrición: mercado

Problemas:

  • Non houbo probas na cadea CI/CD. Engadir probadores remotos só fixo que o proceso de construción fose máis complexo.
  • Os desenvolvedores traballaron simultaneamente nun servidor de desenvolvemento sen ambientes dedicados en contedores.
  • O 70 % do tempo dos desenvolvedores dedicouse ás mesmas accións dende o lanzamento ata o lanzamento. A velocidade de desenvolvemento foi moi lenta.
  • A infraestrutura implantouse nunha empresa de hospedaxe de baixo custo en Alemaña (é dicir, sen velocidade, sen fiabilidade).

Isto, por certo, obsérvase en cada primeiro proxecto.

A solución é xestionada por DevOps: implementamos procesos CI/CD, configuramos probas e monitorizacións correctas, intervimos no desenvolvemento a nivel de procesos de negocio e transferimos a infraestrutura a servidores produtivos nun centro de datos Tier III.

Resultado:

  • aumentou a eficiencia do desenvolvemento: as novas funcións e actualizacións comezaron a saír máis rápido con menos traballo;
  • como resultado, o custo do proceso de desenvolvemento no seu conxunto diminuíu;
  • a infraestrutura fíxose flexible: o cliente pode escalar rapidamente tanto cara arriba como para baixar;
  • os custos de DevOps xestionados, segundo o cliente, pagaron nun prazo de seis meses.

Esfera: publicidade web

Descrición: Plataforma de IA para automatizar campañas publicitarias

Problemas:

  • backend en hardware antigo, nun centro de datos cun baixo nivel de tolerancia a fallos;
  • falta de copias de seguridade regulares;
  • infraestrutura monolítica.

A solución foi xestionada por TI: transferimos a infraestrutura a hardware de gama alta, configuramos o clúster de Galera para a escala horizontal, mostramos como se distribuiría a carga na máquina virtual, configuramos copias de seguridade e monitorización. Agora, ademais do mantemento, consultamos activamente, incluso en DevOps.

Resultado:

  • a infraestrutura converteuse en microservizo: o custo da expansión diminuíu significativamente e a capacidade de escalar, ao mesmo custo, aumentou;
  • aumentou a fiabilidade e seguridade da infraestrutura;
  • os desenvolvedores cambiaron dun modelo de construción en cascada a CI/CD, o que axudou a reducir custos;
  • Os beneficios financeiros das TI xestionadas, segundo o cliente, fixéronse inmediatamente obvios.

Conclusión

A supervivencia das startups depende en gran medida da sorte. Unha startup pode gastar diñeiro en equipos caros e non obter nada del. Outro terá éxito mesmo cunha pésima infraestrutura informática, do mesmo xeito que un mineiro de ouro atopa unha mina de ouro cun vello pico.

Non obstante, as ferramentas modernas, as prácticas e o persoal profesional que ofrece un provedor de TI xestionado reducen significativamente a probabilidade de falla.

Fonte: www.habr.com

Engadir un comentario