best practices… not

Um dos podcasts que acompanho regularmente é o hanselminutes de scott hanselman. neste último episódio ele conversou com o codinghorror jeff atwood acerca do site stackoverflow.

Conversa interessante sobre tecnologia e tal, asp.net mvc, sql, sigla para aqui sigla para ali, mas a parte mais interessante é mesmo quando se começa a falar do dia-a-dia de desenvolvimento e se percebe a forma como a equipa stackoverflow trabalha é, no mínimo, ágil demais.

Pelos vistos o scott hanselman já participou no desenvolvimento de aplicações para o sector financeiro e num ambiente em que a segurança era levada muito a sério (não como algumas estórias que ouvi sobre o desenvolvimento de alguns homebankings nacionais), assim quando o jeff atwood diz coisas como o servidor web e o servidor de base de dados estão na mesma máquina, ou que fazem o acompanhamento live via remote desktop no próprio servidor de alguns queries para perceber onde podem aumentar a performance, quase que se houve o scott hanselmann a engolir em seco.

É de facto dificil perceber ás vezes onde está a linha entre o pragmatismo e a irresponsabilidade quando se ignoram assim tantas normas que têm como objectivo mitigar potenciais questões de segurança ou outras como escalabilidade.

Num nível parecido lembro-me que faz agora um ano em que também tive o meu momento quase ridiculo no que diz respeito a desenvolvimento de software e infraestruturas de IT. Foi um projecto que me deu muito gozo porque me permitiu voltar ao desenvolvimento web que já não fazia há uns anos, mas também deu muito trabalho (basicamente uma semana de 7diasx12horas) porque era bastante ambicioso nos objectivos e nas tecnologias utilizadas.

Conseguimos ter uma aplicação suficiente para entrar em produção, mas a verdade é que de um momento para o outro começamos a ter imensos problemas, basicamente imensos acessos ao site tinham como resposta um timeout e o pior era quando a meio da utilização do mesmo, de um momento para o outro, ele dava erro. Depois de muitas tentativas para demonstrar que o problema não era da aplicação nem do servidor conseguimos convencer os responsaveis pela infraestrutura que a questão era mesmo a largura de banda disponivel que não era suficiente. Assumida essa questão passou-se para o ponto seguinte, como aumentar essa largura de banda. Como não era possível em tempo útil disponibilizar a largura de banda necessária já que os prazos para isso não se coadunavam com o previsivel (e depois confirmado) pico de utilização do site a decisão foi mesmo levar mudar o servidor de instalações fisicas.

Claro que podíamos ter decido pela instalação de todo o software (IIS, SQL, aplicação e outras configurações) numa máquina já instalada nas novas instalações mas isso ía fazer subir o potencial de novos problemas, daí que tivessemos optado por levar mesmo o servidor para o novo local. Não consigo deixar de sorrir quando penso no técnico que tratou disso, e que eu acompanhei, a desligar o servidor (um blade da dell) retira-lo do rack, pô-lo (com alguma dificuldade) debaixo do braço e levar o servidor até à mala do seu carro, onde “com muito cuidado” o pousou, depois disso foram uns 15/30 minutos pela cidade do porto até ao novo local onde se repetiu a mesma história em modo inverso… tira o servidor da mala, vamos até ao edificio, carrega no botão do elevador… espera…espera… subimos para o andar da sala de servidores… espera…espera… eh pah isto é pesado… deixa pousar o servidor aqui neste sofazito enquanto não nos abrem a porta da sala dos servidores e lá ficou esse servidor que depois serviu (e bem) durante cerca de um mês uma população de cerca de quatro mil utiizadores.

Mas é mesmo caso para dizer e pur si muove porque a verdade

por Vitor Silva



Leave a Reply