Arquivo Discussoes de Programacao e Tecnologia 
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
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
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.
Marcio, vale lembrar que nem sempre é possivel ter um ambiente de homologação igual ao de produção.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.
Cadê a estatística? Claro que problemas acontecem dos dois lados, mas 90% é no mínimo exagero.
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á…
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.Nos casos que eu passei e vi, não era dessa forma. O cliente já disponibilizava um ambiente pronto. Bastava trabalhar em cima.
Quanto ao acobertamento, não duvido que possa existir, mas o “geralmente” (90%? prefiro meu “palpite educado”) parece-me exagero.Infelizmente nos casos que passei não foi exagero
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.
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.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.
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.
Por “ambiente”, estou me referindo a um pouco mais do que apenas SO/AppServer/etc. É tambem toda configuração do mesmo que é necessário para uma aplicação rodar: datasources, diretórios específicos, parâmetros de configuração, etc.
A infra básica realmente costuma ser uma condição de contorno, e, via de regra, é razoavelmente conhecida do desenvolvedor tb. (vai ser oracle ou sqlserver ? Java ou PHP ou ASP ?)
Isto não isenta o desenvolvedor de passar o as informações de configuração específicas da aplicação para a produção e, neste contexto, já vi muita besteira sendo feita por programadores que colocavam senhas, endereço de servidor, diretórios, etc, travados no código, só para citar um erro comum.
Estava claro para você. Será que estava claro para um leigo ? Mesmo que estivesse, seres humanos nem sempre respeitam a lógica. Nestas horas você deve ser menos analista e mais terapeuta de sistemas ;^).
Seu caso apenas reforça minha tese. Um checklist de ambiente embutido na aplicação certamente teria poupado horas e horas de discussão inútil. Se a aplicação assumia 2K e está rodando em 2K3, e este ambiente não foi homologado, era obrigação da aplicação recusar-se a rodar, dando uma mensagem bem berrante: “Esta aplicação não pode ser executada neste ambiente. Motivo: O sistema operacional para o qual foi homologado é W2K. Sistema operacional atual: W2K3. Cabeção.”. Tudo bem, eu tiraria na versão final o “Cabeção” ;^).
Isto não isenta o desenvolvedor de passar o as informações de configuração específicas da aplicação para a produção e, neste contexto, já vi muita besteira sendo feita por programadores que colocavam senhas, endereço de servidor, diretórios, etc, travados no código, só para citar um erro comum.Concordo.
Estava claro para você. Será que estava claro para um leigo ? Mesmo que estivesse, seres humanos nem sempre respeitam a lógica.Como eu falei antes, os problemas que eu passei não aconteceram de um dia pro outro. Não foi um só problema. E quem lidava com os servidores de produção não eram leigos não. Eu entendo a sua questão de generalizar a situação pra mostrar que a vida de quem “vive em produção” não é fácil. Ninguém disse o contrário. Como eu falei, eu mesmo já cometi muitos erros, já vi muita gente cometendo erros, mas isso não significa que só existam santos no time de suporte. Pelo contrário.
Nestas horas você deve ser menos analista e mais terapeuta de sistemas ;^).Pois é, foi o que eu falei do costume de sempre tentarem achar um culpado pra tudo. Antes de mais nada temos de ter um acusado. Ninguém assume nada e o outro está sempre errado. Da mesma forma que eu deveria ser mais “terapeuta”, quem lida com fornecedores poderia ser só um pouco menos estúpido. Já melhoraria muito.
Seu caso apenas reforça minha tese. Um checklist de ambiente embutido na aplicação certamente teria poupado horas e horas de discussão inútil. Se a aplicação assumia 2K e está rodando em 2K3, e este ambiente não foi homologado, era obrigação da aplicação recusar-se a rodar, dando uma mensagem bem berrante: “Esta aplicação não pode ser executada neste ambiente. Motivo: O sistema operacional para o qual foi homologado é W2K. Sistema operacional atual: W2K3. Cabeção.”. Tudo bem, eu tiraria na versão final o “Cabeção” ;^).Tese? Que tese? Leia o meu post anterior novamente com mais atenção. No caso que eu exemplifiquei ninguém fazia idéia de que o sistema operacional de produção era win2003. Até mesmo boa parte dos intermediários de dentro do cliente não sabiam. O próprio pessoal técnico do cliente dizia que o sistema era win2000. E mesmo assim, só foram “descobrir” o problema meses depois de esgotarmos todas as possibilidades. Como eu falei, não foi com uma empresa pequena que isso aconteceu e não foi com gente inexperiente. E sim, eles tiveram que enfiar o rabo entre as pernas e assumir a culpa.
Olá
Se o servidor de produção está dentro da empresa que eu trabalho então ainda posso tentar mudar alguma coisa. Mas se está no cliente que paga meu projeto e se a diretoria da empresa em que eu trabalho aceitou este modo de trabalhar, só resta me adaptar.
Acho que esta discussão acaba inóqua porque não vai fazer o desenvolvedor entender as dificuldades do operador e nem o operador perceber a necessidade de alterar o modo de trabalhar que aprendeu nos treinamentos.
Quando um programador tem algum problema para implantar alguma coisa em um ambiente de homologação ou de produção, basta colocar ppr escrito suas dificuldades e passar a bola para quem tem mais condições de resolver. Só não pode criar stress com o cliente.
[]s
Luca
mas isso não significa que só existam santos no time de suporte. Pelo contrário.
Nem santos nem demônios. Apenas gente, e certamente falível, como no “outro lado”.
Mesmo face a atitudes estúpidas, é a forma como se apresenta a situação e a postura, que sempre deve ser colaborativa e não majestática, que pode contribuir para a solução.
É delicado, pois o cenário típico envolve três atores distintos: o time de produção, desenvolvimento e o cliente de negócio, que paga a conta dos dois.
Pressionando por resultados, a tendência do cliente é suspeitar, e muito, do desenvolvimento, especialmente se ele não tiver perfil técnico e tiver participado do projeto desde sua concepção.
Explico: a produção é vista como algo mais próximo da realidade concreta. Afinal, o cliente vê servidores, equipamentos de rede, etc e tem impressão de uma certa “robustez”. Software, por outro lado, é algo meio esotérico, imaterial e - principalmente - caro.
Ah, sem contar que 75% dos projetos de software não atendem às necessidades do cliente e estouram em 100% o tempo estimado, entre outras estatísticas desagradáveis (gg: Software Crisis).
A tese de que a aplicação tem que estar preparada para um ambiente “hostil”. No seu caso, a aplicação seria capaz e, em minha opinião, teria o dever de informar claramente que o ambiente estava incorreto.
Nesta linha, sugiro uma pesquisa em alguns casos bem documentados de prejuízos gigantescos causados por software.
Como contra exemplo, tem um que gosto de citar para meu pessoal, que é o do computador de bordo da 1a nave que pousou na lua. Pelo que li, (uma DDJ, se não me engano), uma determinada rotina responsável pelo cálculo da quantidade de potência a aplicar nos retrofoguetes usava uma fórmula qualquer que incluia uma divisão. A especificação da rotina não falava nada sobre o tratamento a dar em caso de divisão por zero. O programador, por conta própria, resolveu colocar um tratamento. Resultado: na aproximação final, aconteceu a divisão por zero e, se não fosse o tratamento colocado, a nave abriria mais uma cratera na lua…
O estigma existe entre os desenvolvedores, e garanto que é recíproco por parte da produção - até aí dá empate ;^).
Nos níveis superiores, onde as áreas convergem, o que chega são os números, e estes não são muito favoráveis para o desenvolvimento.
Eu sei que são disciplinas diferentes e que não se pode medir as duas áreas da mesma maneira, afinal a produção de TI pode ser tratada com o ferramental clássico de engenharia de processos por ser mais “quadrada” (e tem que ser !). Já o desenvolvimento de software ainda é algum um tanto - como direi ? - imprevisível.