Sabe-se que a competência do CTO é testada apenas na segunda vez que ele desempenha essa função. Porque uma coisa é trabalhar vários anos numa empresa, evoluir com ela e, estando no mesmo contexto cultural, receber gradualmente mais responsabilidades. E outra bem diferente é ir direto para o cargo de diretor técnico em uma empresa com uma bagagem herdada e um monte de problemas cuidadosamente varridos para debaixo do tapete.

Neste sentido, a experiência de Leon Fire, que partilhou no DevOpsConf, não que seja diretamente único, mas multiplicado pela sua experiência e pela quantidade de funções diferentes que conseguiu exercer ao longo de 20 anos, é muito útil. Abaixo do corte está uma cronologia dos acontecimentos ao longo de 90 dias e muitas histórias das quais é divertido rir quando acontecem com outra pessoa, mas que não são tão divertidas de enfrentar pessoalmente.

Leon fala russo de maneira muito colorida, então se você tiver 35-40 minutos, recomendo assistir ao vídeo. Versão em texto para economizar tempo abaixo.

A primeira versão do relatório continha uma descrição bem estruturada do trabalho com pessoas e processos, contendo recomendações úteis. Mas ela não transmitiu todas as surpresas que encontrou ao longo do caminho. Por isso, mudei o formato e apresentei os problemas que surgiram diante de mim como um boneco de surpresa na nova empresa, e métodos para resolvê-los em ordem cronológica.

Um mês antes

Como muitas boas histórias, esta começou com o álcool. Estávamos sentados com amigos em um bar e, como esperado entre os especialistas em TI, todos choravam por causa de seus problemas. Um deles tinha acabado de mudar de emprego e falava sobre seus problemas com a tecnologia, com as pessoas e com a equipe. Quanto mais eu ouvia, mais percebia que ele deveria simplesmente me contratar, porque esses são os tipos de problemas que venho resolvendo nos últimos 15 anos. Eu disse isso a ele e no dia seguinte nos encontramos em um ambiente de trabalho. A empresa se chamava Estratégias de Ensino.

A Teaching Strategies é líder de mercado em currículo para crianças muito pequenas, do nascimento aos três anos de idade. A tradicional empresa de “papel” já tem 40 anos e a versão digital SaaS da plataforma tem 10. Há relativamente pouco tempo, iniciou-se o processo de adaptação da tecnologia digital aos padrões da empresa. A “nova” versão foi lançada em 2017 e era quase igual à antiga, só que funcionava pior.

O mais interessante é que o tráfego desta empresa é muito previsível - dia a dia, ano a ano, é possível prever com muita clareza quantas pessoas virão e quando. Por exemplo, entre 13h e 15h, todas as crianças dos jardins de infância vão para a cama e os professores começam a inserir informações. E isso acontece todos os dias, exceto finais de semana, porque quase ninguém trabalha nos finais de semana.

Olhando um pouco para frente, noto que comecei meu trabalho no período de maior tráfego anual, o que é interessante por vários motivos.

A plataforma, que parecia ter apenas 2 anos, tinha uma pilha peculiar: ColdFusion e SQL Server de 2008. ColdFusion, se você não conhece, e provavelmente não sabe, é um PHP corporativo que surgiu em meados dos anos 90 e, desde então, nunca ouvi falar dele. Também havia: Ruby, MySQL, PostgreSQL, Java, Go, Python. Mas o monólito principal foi executado no ColdFusion e no SQL Server.

Problemas

Quanto mais conversava com os funcionários da empresa sobre o trabalho e quais os problemas encontrados, mais percebia que os problemas não eram apenas de natureza técnica. Ok, a tecnologia é antiga – e não funcionavam nela, mas houve problemas com a equipe e com os processos, e a empresa começou a entender isso.

Tradicionalmente, seus técnicos sentavam-se em um canto e faziam algum tipo de trabalho. Mas cada vez mais negócios começaram a passar pela versão digital. Portanto, no último ano antes de começar a trabalhar, surgiram novos na empresa: conselho de administração, CTO, CPO e diretor de QA. Ou seja, a empresa passou a investir no setor de tecnologia.

Os vestígios de um legado pesado não estavam apenas nos sistemas. A empresa tinha processos legados, pessoas legadas, cultura legada. Tudo isso teve que ser mudado. Achei que definitivamente não seria chato e decidi tentar.

Dois dias antes

Dois dias antes de começar um novo trabalho, cheguei ao escritório, preenchi a última papelada, conheci a equipe e descobri que a equipe estava enfrentando um problema naquele momento. Foi que o tempo médio de carregamento da página saltou para 4 segundos, ou seja, 2 vezes.

A julgar pelo gráfico, algo aconteceu claramente e não está claro o quê. Descobriu-se que o problema era a latência da rede no data center: a latência de 5 ms no data center se transformou em 2 s para os usuários. Eu não sabia por que isso aconteceu, mas de qualquer forma soube-se que o problema estava no data center.

Um dia

Dois dias se passaram e no meu primeiro dia de trabalho descobri que o problema não havia desaparecido.

Durante dois dias, as páginas dos usuários carregaram em média 4 segundos. Eu pergunto se eles descobriram qual é o problema.

- Sim, abrimos um ticket.
- e?
- Bem, eles ainda não nos responderam.

Então percebi que tudo o que me contaram antes era apenas uma pequena ponta do iceberg que eu tinha que lutar.

Há uma boa citação que se encaixa muito bem nisso:

“Às vezes, para mudar a tecnologia, é preciso mudar a organização.”

Mas como comecei a trabalhar na época mais movimentada do ano, tive que olhar para as duas opções para resolver o problema: rápida e a longo prazo. E comece com o que é crítico agora.

Dia três

Assim, o carregamento dura 4 segundos, sendo de 13 a 15 os maiores picos.

No terceiro dia desse período, a velocidade de download ficou assim:

Do meu ponto de vista, nada funcionou. Do ponto de vista de todos os outros, estava um pouco mais lento que o normal. Mas simplesmente não acontece assim – é um problema sério.

Tentei convencer a equipe, ao que eles responderam que simplesmente precisavam de mais servidores. Esta é, obviamente, uma solução para o problema, mas nem sempre é a única e mais eficaz. Perguntei por que não havia servidores suficientes, qual era o volume de tráfego. Extrapolei os dados e descobri que temos aproximadamente 150 solicitações por segundo, o que, em princípio, está dentro de limites razoáveis.

Mas não devemos esquecer que antes de obter a resposta certa, é preciso fazer a pergunta certa. Minha próxima pergunta foi: quantos servidores frontend temos? A resposta “me deixou um pouco perplexo” - tínhamos 17 servidores frontend!

— Tenho vergonha de perguntar, mas 150 dividido por 17 dá cerca de 8? Você está dizendo que cada servidor permite 8 solicitações por segundo, e se amanhã houver 160 solicitações por segundo, precisaremos de mais 2 servidores?

Claro, não precisávamos de servidores adicionais. A solução estava no próprio código e na superfície:

var currentClass = classes.getCurrentClass();
return currentClass;

Havia uma função getCurrentClass(), porque tudo no site funciona no contexto de uma aula - isso mesmo. E para esta função em cada página havia Mais de 200 solicitações.

A solução dessa forma foi muito simples, você nem precisou reescrever nada: basta não pedir novamente as mesmas informações.

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

Fiquei muito feliz porque decidi que logo no terceiro dia havia encontrado o problema principal. Por mais ingênuo que eu fosse, esse era apenas um dos muitos problemas.

Mas resolver este primeiro problema derrubou o gráfico muito mais abaixo.

Ao mesmo tempo, estávamos fazendo outras otimizações. Havia muitas coisas à vista que poderiam ser consertadas. Por exemplo, no mesmo terceiro dia descobri que afinal havia um cache no sistema (a princípio pensei que todas as solicitações vinham diretamente do banco de dados). Quando penso em cache, penso em Redis ou Memcached padrão. Mas fui o único que pensou assim, porque aquele sistema usava MongoDB e SQL Server para cache - o mesmo de onde os dados acabaram de ser lidos.

Dia dez

Na primeira semana lidei com problemas que precisavam ser resolvidos agora. Em algum momento da segunda semana, cheguei ao stand-up pela primeira vez para me comunicar com a equipe, para ver o que estava acontecendo e como estava indo todo o processo.

Algo interessante foi descoberto novamente. A equipe era composta por: 18 desenvolvedores; 8 testadores; 3 gerentes; 2 arquitetos. E todos participavam de rituais comuns, ou seja, mais de 30 pessoas vinham ao stand-up todas as manhãs e contavam o que faziam. É claro que a reunião não durou 5 ou 15 minutos. Ninguém deu ouvidos a ninguém porque todos trabalham em sistemas diferentes. Nesta forma, 2 a 3 ingressos por hora para uma sessão de aliciamento já era um bom resultado.

A primeira coisa que fizemos foi dividir a equipe em diversas linhas de produtos. Para diferentes seções e sistemas, alocamos equipes separadas, que incluíam desenvolvedores, testadores, gerentes de produto e analistas de negócios.

Como resultado obtivemos:

• Reduzindo stand-ups e comícios.
• Conhecimento do assunto do produto.
• Um senso de propriedade. Quando as pessoas costumavam mexer nos sistemas o tempo todo, elas sabiam que provavelmente outra pessoa teria que resolver seus bugs, mas não elas mesmas.
• Colaboração entre grupos. Escusado será dizer que o controle de qualidade não se comunicava muito com os programadores antes, o produto fazia suas próprias coisas, etc. Agora eles têm um ponto comum de responsabilidade.

Focamos principalmente na eficiência, produtividade e qualidade – esses são os problemas que tentamos resolver com a transformação da equipe.

Dia onze

No processo de mudança da estrutura da equipe, descobri como contar HistóriaPoints. 1 SP equivalia a um dia, e cada ticket continha SP tanto para desenvolvimento quanto para QA, ou seja, no mínimo 2 SP.

Como descobri isso?

Encontramos um bug: em um dos relatórios, onde são inseridas as datas de início e término do período para o qual o relatório é necessário, o último dia não é levado em consideração. Ou seja, em algum lugar da solicitação não havia <=, mas simplesmente <. Disseram-me que são três Story Points, ou seja 3 dias.

Depois disso nós:

• O sistema de classificação de Story Points foi revisado. Agora, correções para pequenos bugs que podem ser passados ​​rapidamente pelo sistema chegam ao usuário com mais rapidez.
• Começamos a mesclar tickets relacionados para desenvolvimento e teste. Anteriormente, cada ticket, cada bug era um ecossistema fechado, não vinculado a mais nada. Alterar três botões em uma página poderia significar três tickets diferentes com três processos de controle de qualidade diferentes, em vez de um teste automatizado por página.
• Começamos a trabalhar com desenvolvedores em uma abordagem para estimar os custos trabalhistas. Três dias para trocar um botão não é engraçado.

Dia vigésimo

Em algum momento no meio do primeiro mês a situação se estabilizou um pouco, descobri o que basicamente estava acontecendo e já comecei a olhar para o futuro e pensar em soluções de longo prazo.

Metas de longo prazo:

• Plataforma gerenciada. Centenas de solicitações em cada página não são sérias.
• Tendências previsíveis. Ocorreram picos de tráfego periódicos que, à primeira vista, não se correlacionavam com outras métricas - precisávamos entender por que isso acontecia e aprender a prever.
• Expansão da plataforma. O negócio está em constante crescimento, cada vez mais usuários chegam e o tráfego está aumentando.

Antigamente dizia-se muitas vezes: “Vamos reescrever tudo em [linguagem/estrutura], tudo funcionará melhor!”

Na maioria dos casos isso não funciona, é bom que a reescrita funcione. Portanto, precisávamos criar um roteiro – uma estratégia específica que ilustrasse passo a passo como os objetivos de negócios serão alcançados (o que faremos e por quê), que:

• reflete a missão e os objetivos do projeto;
• prioriza os objetivos principais;
• contém um cronograma para alcançá-los.

Antes disso, ninguém havia conversado com a equipe sobre o propósito das alterações que estavam sendo feitas. Isso requer as métricas de sucesso corretas. Pela primeira vez na história da empresa definimos KPIs para o grupo técnico, e esses indicadores foram atrelados aos organizacionais.

Ou seja, os KPIs organizacionais são suportados por equipes e os KPIs de equipes são suportados por KPIs individuais. Caso contrário, se os KPIs tecnológicos não coincidirem com os organizacionais, todos se cobrem.

Por exemplo, um dos KPIs organizacionais é aumentar a quota de mercado através de novos produtos.

Como você pode apoiar a meta de ter mais produtos novos?

• Primeiro, queremos gastar mais tempo desenvolvendo novos produtos em vez de consertar defeitos. Esta é uma solução lógica e fácil de medir.
• Em segundo lugar, queremos apoiar um aumento do volume de transações, porque quanto maior for a quota de mercado, mais utilizadores e, consequentemente, mais tráfego.

Então os KPIs individuais que podem ser executados dentro do grupo estarão, por exemplo, no local de onde vêm os principais defeitos. Se você se concentrar especificamente nesta seção, poderá ter certeza de que há muito menos defeitos e, então, o tempo para desenvolver novos produtos e novamente para apoiar os KPIs organizacionais aumentará.

Assim, cada decisão, incluindo a reescrita do código, deve apoiar os objetivos específicos que a empresa nos estabeleceu (crescimento organizacional, novas funcionalidades, recrutamento).

Durante esse processo, veio à tona uma coisa interessante, que virou novidade não só para os técnicos, mas em geral na empresa: todos os tickets devem estar focados em pelo menos um KPI. Ou seja, se um produto diz que quer fazer um novo recurso, a primeira pergunta deve ser feita: “Qual KPI esse recurso suporta?” Se não, desculpe - parece um recurso desnecessário.

Dia trinta

No final do mês, descobri outra nuance: ninguém da minha equipe de operações jamais viu os contratos que firmamos com os clientes. Você pode perguntar por que precisa ver os contatos.

• Primeiro, porque os SLAs são especificados em contratos.
• Em segundo lugar, os SLAs são todos diferentes. Cada cliente veio com suas próprias necessidades e o departamento de vendas assinou sem olhar.

Outra nuance interessante é que o contrato com um dos maiores clientes estabelece que todas as versões de software suportadas pela plataforma devem ser n-1, ou seja, não a versão mais recente, mas a penúltima.

Fica claro o quão longe estávamos do número 1 se a plataforma fosse baseada em ColdFusion e SQL Server 2008, que não tinha mais suporte em julho.

Dia quarenta e cinco

Por volta de meados do segundo mês, tive tempo suficiente para sentar e fazer valortransmitir canaismapeamento completamente durante todo o processo. Estas são as etapas necessárias que devem ser executadas, desde a criação de um produto até a entrega ao consumidor, e precisam ser descritas com o máximo de detalhes possível.

Você divide o processo em pequenos pedaços e vê o que está demorando muito, o que pode ser otimizado, melhorado, etc. Por exemplo, quanto tempo leva para uma solicitação de produto passar pela preparação, quando chega a um ticket que um desenvolvedor pode receber, controle de qualidade, etc. Então você analisa cada etapa individual detalhadamente e pensa no que pode ser otimizado.

Quando fiz isso, duas coisas me chamaram a atenção:

• alta porcentagem de tickets devolvidos do controle de qualidade aos desenvolvedores;
• as revisões da solicitação pull demoraram muito.

O problema é que essas conclusões eram do tipo: Parece levar muito tempo, mas não temos certeza de quanto tempo.

"Você não pode melhorar o que não pode medir."

Como justificar a gravidade do problema? Perde dias ou horas?

Para medir isso, adicionamos algumas etapas ao processo Jira: “pronto para desenvolvimento” e “pronto para controle de qualidade” para medir quanto tempo cada ticket espera e quantas vezes ele retorna a uma determinada etapa.

Também adicionamos “em revisão” para saber quantos ingressos estão em média para revisão, e a partir disso você pode começar a dançar. Tínhamos métricas de sistema, agora adicionamos novas métricas e começamos a medir:

• Eficiência do processo: desempenho e planejado/entregue.
• Qualidade do processo: número de defeitos, defeitos do controle de qualidade.

Realmente ajuda a entender o que está indo bem e o que não está indo bem.

Quinquagésimo dia

Tudo isto é, claro, bom e interessante, mas no final do segundo mês aconteceu algo que, em princípio, era previsível, embora eu não esperasse tal escala. As pessoas começaram a sair porque a alta administração havia mudado. Novas pessoas entraram na gestão e começaram a mudar tudo, e as antigas desistiram. E geralmente em uma empresa que já existe há vários anos, todos são amigos e todos se conhecem.

Isto era esperado, mas a escala das demissões foi inesperada. Por exemplo, em uma semana, dois líderes de equipe apresentaram simultaneamente suas demissões por vontade própria. Portanto, tive que não apenas esquecer outros problemas, mas focar criando uma equipe. Este é um problema longo e difícil de resolver, mas teve que ser resolvido porque eu queria salvar as pessoas que restaram (ou a maioria delas). Era preciso reagir de alguma forma à saída de pessoas para manter o moral da equipe.

Em tese, isso é bom: entra uma pessoa nova que tem carta branca completa, que pode avaliar as competências da equipe e substituir pessoal. Na verdade, você não pode simplesmente trazer novas pessoas por vários motivos. O equilíbrio é sempre necessário.

• Velho e novo. Precisamos manter idosos que possam mudar e apoiar a missão. Mas, ao mesmo tempo, precisamos trazer sangue novo, falaremos disso um pouco mais tarde.
• Experiência. Conversei muito com bons juniores que estavam ansiosos e queriam trabalhar conosco. Mas não pude aceitá-los porque não havia veteranos suficientes para apoiar os juniores e atuar como mentores para eles. Foi necessário recrutar primeiro os topos e só depois os jovens.
• Cenoura e pau.

Não tenho uma boa resposta para a questão de qual é o equilíbrio certo, como mantê-lo, quantas pessoas manter e quanto forçar. Este é um processo puramente individual.

Dia cinquenta e um

Comecei a olhar atentamente para a equipe para entender quem eu tinha, e mais uma vez lembrei:

“A maioria dos problemas são problemas de pessoas.”

Descobri que a equipe como tal - tanto de Desenvolvimento quanto de Operações - tem três grandes problemas:

• Satisfação com a situação atual.
• Falta de responsabilidade - porque ninguém jamais trouxe os resultados do trabalho dos executores para influenciar o negócio.
• Medo da mudança.

A mudança sempre tira você da sua zona de conforto, e quanto mais jovens são, mais eles não gostam de mudanças porque não entendem o porquê e não entendem como. A resposta mais comum que ouvi é: “Nunca fizemos isso”. Além disso, chegou ao absurdo total - as menores mudanças não poderiam ocorrer sem que alguém se indignasse. E por mais que as mudanças afetassem o seu trabalho, as pessoas diziam: “Não, por quê? Isso não vai funcionar."

Mas você não pode melhorar sem mudar nada.

Tive uma conversa absolutamente absurda com um funcionário, contei a ele minhas ideias de otimização, ao que ele me disse:
- Ah, você não viu o que tivemos no ano passado!
- Então o que?
“Agora está muito melhor do que era.”
- Então não pode melhorar?
Por que?

Boa pergunta - por quê? É como se agora estivesse melhor do que era, então tudo está bom o suficiente. Isto leva a uma falta de responsabilidade, o que é absolutamente normal em princípio. Como eu disse, o grupo técnico ficou um pouco à margem. A empresa acreditava que eles deveriam existir, mas ninguém nunca estabeleceu os padrões. O suporte técnico nunca viu o SLA, então era bastante “aceitável” para o grupo (e isso me impressionou mais):

• Carregamento de 12 segundos;
• Tempo de inatividade de 5 a 10 minutos em cada versão;
• A solução de problemas críticos leva dias e semanas;
• falta de pessoal de plantão 24 horas por dia, 7 dias por semana / plantão.

Ninguém jamais tentou perguntar por que não fazemos melhor, e ninguém jamais percebeu que não precisa ser assim.

Como bônus, havia mais um problema: falta de experiência. Os seniores partiram e a restante equipa jovem cresceu sob o regime anterior e foi envenenada por ele.

Além de tudo isso, as pessoas também tinham medo de falhar e parecerem incompetentes. Isto se expressa no fato de que, em primeiro lugar, eles em nenhuma circunstância pediu ajuda. Quantas vezes conversamos em grupo e individualmente e eu disse: “Faça uma pergunta se não souber fazer alguma coisa”. Estou confiante em mim mesmo e sei que posso resolver qualquer problema, mas isso levará tempo. Portanto, se eu puder perguntar a alguém que saiba resolver em 10 minutos, eu perguntarei. Quanto menos experiência você tiver, mais medo terá de perguntar porque acha que será considerado incompetente.

Esse medo de fazer perguntas se manifesta de maneiras interessantes. Por exemplo, você pergunta: “Como você está realizando esta tarefa?” - “Faltam algumas horas, já estou terminando.” No dia seguinte você pergunta novamente, você recebe a resposta que está tudo bem, mas teve um problema, com certeza estará pronto no final do dia. Mais um dia se passa, e até você ficar preso na parede e ser forçado a falar com alguém, isso continua. Uma pessoa quer resolver um problema sozinha; ela acredita que se não resolver sozinha, será um grande fracasso.

É por isso os desenvolvedores inflacionaram as estimativas. Foi aquela mesma anedota, quando estavam discutindo uma determinada tarefa, me deram um número tão grande que fiquei muito surpreso. Ao que me disseram que nas estimativas do desenvolvedor, o desenvolvedor inclui o tempo que o ticket será devolvido do QA, pois lá encontrarão erros, e o tempo que o PR levará, e o tempo enquanto as pessoas que devem revisar estará ocupado - ou seja, tudo, o que for possível.

Em segundo lugar, as pessoas que têm medo de parecer incompetentes analisar demais. Quando você diz o que exatamente precisa ser feito, começa: “Não, e se pensarmos nisso aqui?” Neste sentido, a nossa empresa não é única; este é um problema padrão dos jovens.

Em resposta, apresentei as seguintes práticas:

• Regra 30 minutos. Se você não conseguir resolver o problema em meia hora, peça ajuda a alguém. Isto funciona com graus variados de sucesso, porque as pessoas ainda não perguntam, mas pelo menos o processo já começou.
• Elimine tudo menos a essência, ao estimar o prazo para conclusão de uma tarefa, ou seja, conte apenas quanto tempo levará para escrever o código.
• Formação contínua para aqueles que analisam demais. É apenas um trabalho constante com as pessoas.

Sexagésimo dia

Enquanto eu fazia tudo isso, era hora de definir o orçamento. Claro, encontrei muitas coisas interessantes sobre onde gastamos nosso dinheiro. Por exemplo, tínhamos um rack inteiro em um data center separado com um servidor FTP usado por um cliente. Acontece que “... mudamos, mas ele ficou assim, não trocamos”. Foi há 2 anos.

De particular interesse foi a conta dos serviços em nuvem. Acredito que o principal motivo da alta conta da nuvem sejam os desenvolvedores que têm acesso ilimitado aos servidores pela primeira vez na vida. Eles não precisam perguntar: “Por favor, me dê um servidor de teste”, eles próprios podem fazer isso. Além disso, os desenvolvedores sempre querem construir um sistema tão legal que o Facebook e a Netflix ficarão com inveja.

Mas os desenvolvedores não têm experiência na compra de servidores e habilidade para determinar o tamanho necessário dos servidores, porque antes não precisavam disso. E geralmente não entendem muito bem a diferença entre escalabilidade e desempenho.

Resultados do inventário:

• Saímos do mesmo data center.
• Rescindimos o contrato com 3 serviços de log. Porque tínhamos 5 deles - cada desenvolvedor que começou a brincar com algo pegou um novo.
• 7 sistemas AWS foram desligados. Mais uma vez, ninguém interrompeu os projetos mortos; todos continuaram a funcionar.
• Custos de software reduzidos em 6 vezes.

Dia setenta e cinco

O tempo passou e em dois meses e meio tive que me reunir com a diretoria. Nosso conselho de administração não é melhor nem pior que os outros; como todos os conselhos de administração, quer saber tudo. As pessoas investem dinheiro e querem entender até que ponto o que fazemos se enquadra nos KPIs definidos.

A diretoria recebe muitas informações todos os meses: o número de usuários, seu crescimento, quais serviços utilizam e como, desempenho e produtividade e, por fim, velocidade média de carregamento das páginas.

O único problema é que acredito que a média é pura maldade. Mas é muito difícil explicar isso ao conselho de administração. Eles estão acostumados a operar com números agregados, e não, por exemplo, com a distribuição dos tempos de carregamento por segundo.

Houve alguns pontos interessantes nesse sentido. Por exemplo, eu disse que precisamos dividir o tráfego entre servidores web separados, dependendo do tipo de conteúdo.

Ou seja, o ColdFusion passa pelo Jetty e pelo nginx e lança as páginas. E imagens, JS e CSS passam por um nginx separado com configurações próprias. Esta é uma prática bastante padrão da qual estou falando escreveu alguns anos atrás. Como resultado, as imagens carregam muito mais rápido e... a velocidade média de carregamento aumentou 200 ms.

Isso aconteceu porque o gráfico é construído com base nos dados que acompanham o Jetty. Ou seja, o conteúdo rápido não entra no cálculo – o valor médio saltou. Isso ficou claro para nós, rimos, mas como explicar ao conselho de administração porque fizemos algo e as coisas pioraram 12%?

Dia oitenta e cinco

No final do terceiro mês, percebi que havia uma coisa com a qual não contava: o tempo. Tudo o que falei leva tempo.

Este é o meu verdadeiro calendário semanal - apenas uma semana de trabalho, não muito ocupada. Não há tempo suficiente para tudo. Portanto, novamente, você precisa recrutar pessoas que o ajudem a lidar com os problemas.

Conclusão

Isso não é tudo. Nessa história ainda nem falei como trabalhamos com o produto e tentamos nos sintonizar com a onda geral, nem como integramos o suporte técnico, nem como resolvemos outros problemas técnicos. Por exemplo, aprendi por acaso que nas maiores tabelas do banco de dados não usamos SEQUENCE. Temos uma função autoescrita nextID, e não é usado em uma transação.

Havia mais um milhão de coisas semelhantes sobre as quais poderíamos conversar por muito tempo. Mas a coisa mais importante que ainda precisa ser dita é a cultura.

É a cultura ou a falta dela que leva a todos os outros problemas. Estamos tentando construir uma cultura onde as pessoas:

• não têm medo do fracasso;
• aprender com os erros;
• colaborar com outras equipes;
• tomar iniciativa;
• tomar responsabilidade;
• acolher o resultado como uma meta;
• comemorando o sucesso.

Com isso todo o resto virá.

Leão Fogo no twitter, Facebook e média.

Existem duas estratégias em relação ao legado: evitar a todo custo trabalhar com ele ou superar corajosamente as dificuldades associadas. Nós c DevOpsConf Estamos seguindo o segundo caminho, mudando processos e abordagens. Junte-se a nós em Youtube, Boletim de Notícias и telegramae juntos implementaremos uma cultura DevOps.

Fonte: habr.com