Você tem acesso aos servidores de produção?
Pergunto isso porque no cliente em que atuo eu não possuo NENHUM tipo de acesso às maquinas de produção e homologação.
Então quando aparece um erro e me perguntam: “o que aconteceu?”, eu fico com cara de pastel e peço para alguem abrir um chamado para (2 horas depois) me mandaram o log de erros.
É muito improdutivo, mas enfim.
Como é na sua empresa ou cliente?
Olá
É possível que seu cliente seja da área financeira onde já vi acontecer isto.
O grande problema para o desenvolvedor é que quando chegam os logs as vezes vem um arquivão imenso que dá um enorme trabalho de analisar e o desenvolvedor precisa ficar até de madrugada para descobrir que eles mandaram os logs errados. Já passei por isto e o SLA indo para o brejo com o downtime.
[]s
Luca
trabalho em terminal unix (nextstep), usuário comum, a minha parte de desenvolvimento não usa bd. Os releases são ultramente protegidos contra todos, os binarios podem ser usados por qualquer um nos computadores apropriados.
Como disse o Luca, isso é muito comum em bancos. Como 100% dos clientes que passei nos últimos 7 anos são bancos, já estou até acostumado. Pra dizer a verdade, acho estranho quando chego em algum cliente e os servidores de produção podem ser acessados “livremente”.
Eu não direto aos servidores de produção e homologação.
Porém temos aqui acesso total aos logs e contadores de monitoração de todos servidores de homologação e produção.
Isso resolve o problema para a grande maioria dos casos, além de ter o fator didático, que eduta os desenvolvedores a colocarem log de forma inteligente na aplicação. Não tá logando coisa útil - vai sofrer cedo ou tarde por conta disso.
Nao acho que a falta de acesso aos servidores de producao te torne um ‘sofredor’: muito pelo contrario, eu diria.
Nao ter que encostar em nada relacionado a producao eh, geralmente, bem mais prazeroso do que se preocupar com isso 
Nos 3 últimos projetos (transportes aéreos, financeiro e telecom), só tinha acesso aos servidores de homologação (só aos APPServers). Em outros lugares, o nível de acesso era semelhante. Deve ser prática comum, ainda bem 
Votei no mais ou menos mas era pra votar em nenhum… ¬_¬
Na empresa que estou atualmente eu não tenho nenhum acesso aos servidores de produção, mas isso não representa nenhum problema pro meu dia-a-dia.
Problema sim eu tinha na última empresa que eu trabalhei, antes da atual, onde volta e meia eu precisava ficar um tempo dentro da Petrobras para resolver problemas. Eu resolvia pepinos em aplicações em Java, Asp e Php, e em todos os ambientes havia trocentos intermediários até chegar em produção. Nem os funcionários da Petrobras que “interfaceavam” comigo tinham acesso. E o pior é que lá dentro existia a cultura do “vou tirar o meu da reta” (não sei se só no setor que eu trabalhava), coisa que causava algumas situações no mínimo lamentáveis, chegando ao ponto de, por exemplo, uma aplicação Asp que funcionava perfeitamente em teste, mas não funcionava de jeito nenhum em produção, e o pessoal de infra que cuidava da produção jurava de pé juntos que os dois servidores eram idênticos e que eu tinha que me virar. Simples assim. Mas, como dá pra comprovar algo sem ter nenhum acesso? Só na “palavra” deles? Depois de todo o mal estar criado por isso, depois de muita briga, depois de muita água rolando, descobrimos que, é claro, os servidores eram beeem diferentes… enfim, tem milhões de casos do tipo…
Não estou trabalhando no momento, mas já tive acesso (ou falta de acesso) de todos os tipos da enquete. Sempre dependendo do cliente e/ou projeto.
Acho que o Carlos tem razão. Se há uma entidade cuidando da produção e eles fazem um bom trabalho (inclusive te entregam as informações que você precisa), uma vez que você se acostuma com a situação, fica até legal.
Deus me livre de ter a responsabilidade de administrar os servidores.
O problema é que quando algum destes servidores, por obra dos administradores (principalmente terceiros), tem alguma config diferente ou algo faltando, ai sofremos para descobrir onde está o problema, sendo que em desenvolvimento ou homologação tudo funciona bem.
E o cara nunca vai falar que o problema é dele. Até que você prove o contrário!
ps: não trabalho com instituição financeira. mas é uma empresa líder do setor de publicações.
Estatisticamente, ele tem razão. 90% dos problemas enfrentados pelo pessoal de produção são causados por aplicações mal escritas e/ou com dependências de runtime que não são claramente informadas.
Fora outros “detalhes”, tais como gerenciamento de logs, gestão de dados, ausência de pontos de controle/observação, que fazem a diferença…
Cadê a estatística? Claro que problemas acontecem dos dois lados, mas 90% é no mínimo exagero.
Nos casos que eu passei (e em muitos outros que eu já vi) os problemas eram sempre causados por confusão do pessoal de produção em arrumar o ambiente mínimo necessário para rodar a aplicação e equiparar esse com o ambiente de teste. E aí, como o Daniel falou, ninguém nunca assume o erro, até que você prove que eles estão errados. Só que o problema é que muitas vezes vc não tem como provar, justamente por vc não ter nenhum acesso a produção. E aí ficar aquele jogo de empurra: em teste tudo funciona, mas em produção não. De quem é a responsabilidade? Vc diz que é deles e eles dizem que é sua. Como eles geralmente são “acobertados” pelo próprio cliente, a culpa toda vai pra cima de vc, e aí se vira pra resolver.
E olha que eu não estou falando de empresas pequenas e eu dei um só exemplo que eu vivi na pele.
Exatamente.
Ja passei por esse tipo de situacao e minha opiniao eh: o problema nao eh nao ter acesso a producao (isso eh normal, compreensivo e totalmente saudavel). O problema eh o maldito ambiente de homologacao nao refletir o de producao. Teoricamente voce deveria homologar e, uma vez homologado, colocar em producao numa boa. Mas sabe como eh - sempre tem um detalhezinho a mais ou a menos para ajudar.
Pra piorar, em certos ambientes o cara que implanta a aplicacao deve (por politica da empresa) comportar-se como um simples “operador”. Ou seja, se tem uma virgula fora do lugar de um ambiente pra outro, ele nada pode fazer.
Enfim, juntando tudo isso o resultado eh stress garantido para o desenvolvedor.
Marcio Kuchma
Pior ainda é quando existe um numreo razoavel de pessoas envolvidas com o sistema que você está mantendo, a velha estória do problema passar na mão de mil pessoas antes de chegar até você. Isso é um caos, se não houver controle do histórico das mensagens que foi passada acaba virando um telefone sem fio =S
[quote=kuchma]
Ja passei por esse tipo de situacao e minha opiniao eh: o problema nao eh nao ter acesso a producao (isso eh normal, compreensivo e totalmente saudavel). O problema eh o maldito ambiente de homologacao nao refletir o de producao. Teoricamente voce deveria homologar e, uma vez homologado, colocar em producao numa boa. Mas sabe como eh - sempre tem um detalhezinho a mais ou a menos para ajudar.
Pra piorar, em certos ambientes o cara que implanta a aplicacao deve (por politica da empresa) comportar-se como um simples “operador”. Ou seja, se tem uma virgula fora do lugar de um ambiente pra outro, ele nada pode fazer.
Enfim, juntando tudo isso o resultado eh stress garantido para o desenvolvedor.
Marcio Kuchma[/quote]
Marcio, vale lembrar que nem sempre é possivel ter um ambiente de homologação igual ao de produção. Principalmente quando o parte de máquinas é grande, não dá para justificar ter em homologação um cluster com 200 máquinas, ou então um servidor com 32cpus e 100gigas de ram.
[quote=“louds”]Marcio, vale lembrar que nem sempre é possivel ter um ambiente de homologação igual ao de produção.[/quote]O problema não é esse. O problema é quando os responsáveis pela produção juram de pé juntos que os dois servidores são idênticos (e não são) e o que está acontecendo de errado com a sua aplicação é problema seu.
Quando isso acontece, toda uma carga de estresse associada ao nome da sua empresa (ou o seu próprio) vem pra cima de vc, quer dizer, “por padrão” o desenvolvedor está errado, porque ninguém assume culpa. E aí, quando finalmente, depois de sofrer como se tivesse percorrido um deserto, vc prova por A+B que o cliente é que estava errado o tempo todo, todo mundo abafa, faz que não viu, deixa pra lá etc. Só que a má impressão continua, mesmo vc tendo provado que era “inocente”.
Correto. Especificando um pouco mais, como o Marcio Tavares comentou: o problema eh ter ambientes diferentes mas politica inadequada para isso (agir como se fossem iguais quando nao sao).
Marcio Kuchma
Sim, acesso ao banco e ao sistema de desenvolvimento, homologação e produção. Mas quem realmente trabalha na atualização da produção não sou eu.
[quote=MarcioTavares]Cadê a estatística? Claro que problemas acontecem dos dois lados, mas 90% é no mínimo exagero.
[/quote]
Experiência própria e de colegas que já estiveram e estão dos dois lados.
O número é chutado, claro - mas para o lado certo. A idéia foi chamar a atenção mesmo, já que por aqui dificilmente vejo alguem dando opiniões que levem em conta a visão do pessoal de produção.
E em todos os casos em que vi isto acontecer, o desenvolvimento não foi capaz de informar corretamente o que era o “ambiente” para a aplicação e/ou não levou em conta a realidade da produção, resultando em um ambiente de homologação inconsistente. Simplesmente assumem determinadas premissas que se mostram incorretas e jogam a culpa no ambiente.
Ora, se o ambiente é crítico, deve-se ter um validador do mesmo, certo ? Conto nos dedos de uma mão presidencial digitalmente prejudicada as aplicações que vi fazendo isto. Neste caso, se o ambiente estiver bixado, o checklist inicial deve mostrar claramente em logs o que está errado.
E falando em ambiente, lembre-se que os operadores fazem parte do ambiente de produção !. Se sua aplicação precisa de um operador que seja capaz de intepretar o log de startup do JBoss para saber se a aplicação subiu corretamente ou não, isto tem que estar claro.
É um pouco como naquela história sobre as montadoras americanas reclamando que os japoneses não importavam carros “made in usa”, e exigiam a imposição de retaliações comerciais: O japoneses tinham lá seus motivos, entre eles, o fato de os carros que os americanos queriam exportar tinham a direção do lado esquerdo do carro…
Veja bem, se seu log mostra “deu erro” e nada mais (ou um lindo stack trace, que só faz sentido para voce, desenvolvedor), vai ser jogo de empurra mesmo, e a culpa disto acontecer será do desenvolvimento.
Não espere que a turma da produção, que normalmente tem dúzias de aplicações em diversas tecnologias, tenha tempo/competência para analisar um log com mensagens do tipo “passei aqui !” e dizer algo de útil, e muito menos assuma um erro que ele não tem como saber que cometeu.
Este é a desculpa mais antiga que conheço de desenvolvedores. Toda vez que um dos meus colaboradores me vem com esta lenga-lenga eu rejeito na hora - e olha que hoje em dia sou desenvolvimento. O cliente não está nem aí se roda em teste. Ele quer que rode em produção ! Meu ponto é : se sua aplicação não é capaz de dar um diagnóstico razoável do problema encontrado, não está pronta para entrar em produção.
Isto apenas para ficar no caso mais simples, que é a aplicação dar um erro sistemático em produção. O argumento é mais frágil ainda quando se trata de algo intermitente ou relacionado a performance: por definição, a produção será sempre diferente de testes e homologação, os quais são estágios necessários para testes funcionais e de carga, mas nunca são capazes de reproduzir 100% o que acontece no primeiro.
Quanto ao acobertamento, não duvido que possa existir, mas o “geralmente” (90%? prefiro meu “palpite educado”) parece-me exagero.
O que vejo é o cliente que paga a conta p* da vida querendo que a p* do sistema entre no ar.
E vai viver outros mais. É parte do negócio ;^)
Muito bom seu post! Realmente existem pouquíssimos ou nenhum relato do lado de produção se defendendo. Mas vamos lá…
[quote=“psevestre”]E em todos os casos em que vi isto acontecer, o desenvolvimento não foi capaz de informar corretamente o que era o “ambiente” para a aplicação e/ou não levou em conta a realidade da produção, resultando em um ambiente de homologação inconsistente. Simplesmente assumem determinadas premissas que se mostram incorretas e jogam a culpa no ambiente.[/quote]Nos casos que eu passei e vi, não era dessa forma. O cliente já disponibilizava um ambiente pronto. Bastava trabalhar em cima.
[quote=“psevestre”]Quanto ao acobertamento, não duvido que possa existir, mas o “geralmente” (90%? prefiro meu “palpite educado”) parece-me exagero.[/quote]Infelizmente nos casos que passei não foi exagero 
[quote=“psevestre”]Este é a desculpa mais antiga que conheço de desenvolvedores. Toda vez que um dos meus colaboradores me vem com esta lenga-lenga eu rejeito na hora… Meu ponto é : se sua aplicação não é capaz de dar um diagnóstico razoável do problema encontrado, não está pronta para entrar em produção.[/quote][quote=“psevestre”]Veja bem, se seu log mostra “deu erro” e nada mais (ou um lindo stack trace, que só faz sentido para voce, desenvolvedor), vai ser jogo de empurra mesmo, e a culpa disto acontecer será do desenvolvimento.[/quote]E se seu log mostra o erro corretamente, vc argumenta cheio de razão, vê que a causa do problema está mais do que clara e o time de produção singelamente tira o corpo fora? E ainda com o aval da sua gerência? Sim, vc pode dizer que isso é muito estranho, que é surreal (e é mesmo), que se o log está mostrando o erro, é erro e ponto final… Sim, vc pensa assim, eu penso assim, todos pensam assim, mas me parece que às vezes os interesses de uns e outros sobrepõem a lógica óbvia e ululante. É coisa de louco mesmo. Costumo falar com colegas de trabalho que se essas histórias fossem contadas em livros, ninguém acreditaria que são verdadeiras.
Como eu falei antes, nessa empresa eu trabalhei não só com Java, mas também com Asp e Php. E um dos casos que aconteceu com um dos sistemas em Asp era justamente um erro que aparecia em determinada parte, algo relacionado a permissões, e o cliente simplesmente bateu o pé e disse que era culpa nossa. Essa história não aconteceu em alguns dias. Foram meses. Não foi simplesmente: cliente: “olha, tá com erro aqui!”; desenvolvedor (hipoteticamente sem saber o que falar): “a culpa é do ambiente de produção!”. Muita água rolou. Não vou entrar em detalhes aqui, senão meu post vira um testamento, mas no final das contas foi provado que os ambientes eram sim significativamente diferentes, e o cliente teve que engolir a culpa. Pra vc ter uma idéia mínima, uma das coisas que aconteceu: o servidor de testes era win2000srv e o de produção era win2003srv, que têm diferenças consideráveis entre os IISs, e o cliente jurava de pés juntos que era o mesmo sistema operacional. Não faço a menor idéia do porque terem falado isso, mas aconteceu. Não é novela.
Como eu disse antes, eu tenho vários outros exemplos desse tipo de situação. Alguns também são bem surreais. Outros nem tanto. Outros foram resolvidos rapidamente, mas nunca sem passar por um estresse mínimo, e é claro que eu e o time de desenvolvimento que participava também cometeu seus erros. Só que como eu falei, sempre “por padrão” a culpa era do fornecedor e aquela imagem arranhada ficava fixada, mesmo com a situação resolvida. Muitas vezes o cliente nem sabia qual era o erro, simplesmente já chegava atirando pedras. Isso só causa estresse porque o cliente se aproveita da sua posição hierárquica para jogar outros na reta.
Acho que o grande ponto problemático dessa história é que todo mundo age defensivamente, cada um querendo defender o seu: o “culpado” e o “inocente”. Essas palavras já são usadas logo de cara quando algo acontece e todo mundo quer achar um culpado pra tudo, ao invés de resolverem os problemas de uma forma construtiva e coletiva, um ajudando o outro. Infelizmente o mercado de trabalho é assim. É uma selva onde vc tem que estar atento o tempo todo pros ataques. Mas não deveria ser assim.