Que coisas de administrador de sistema todos os programadores devem saber?

Como programador, tendemos a considerar os administradores de sistemas como garantidos. As poucas vezes em que estive sem um bom administrador de sistemas realmente me fizeram apreciar o que vocês fazem. Quando estamos nos aventurando em um ambiente sem administrador de sistema, que palavras de sabedoria você pode nos oferecer?

Eu começaria com:

1. Sempre tenha algum tipo de sistema de backup. Ainda melhor se tiver uma história.
2. Considere pontos únicos de falha e como lidar com eles, caso falhem.
3. Dependendo da quantidade de computadores envolvidos, procurar uma maneira de criar e criar uma imagem padrão entre os computadores facilitará a vida de todos - não "funciona na minha" porque eles têm esse e aquele programa normalmente não instalado.
4. Documentar tudo, se apenas porque você vai esquecer como você definir alguma coisa.
5. Mantenha-se a par das atualizações de segurança.

<insira isenção de responsabilidade de postagem grande aqui>

Algumas delas já foram ditas antes, mas vale a pena repetir.

Documentação:

• Documente tudo. Se você não tiver um, instale um wiki sob o radar, mas certifique-se de fazer o backup. Comece coletando fatos e, um dia, uma grande figura se formará.

• Crie diagramas para cada parte lógica e mantenha-os atualizados. Não pude contar o número de vezes que um mapa de rede ou diagrama de cluster preciso me salvou.

• Mantenha os logs de compilação para cada sistema, mesmo que sejam apenas comandos de copiar e colar para saber como compilá-lo.

• Ao criar seu sistema, instale e configure seus aplicativos, teste-o e execute seu teste comparativo. Agora, limpe os discos. A sério. 'dd' o primeiro megabyte na frente dos discos ou torne a caixa não inicializável. O tempo está passando: prove que sua documentação pode reconstruí-la do zero (ou, melhor ainda, prove que seu colega pode com nada além de sua documentação). Isso formará metade do seu plano de recuperação de desastres.

• Agora você tem a primeira metade do seu plano de recuperação de desastres, documente o restante; como recuperar o estado do seu aplicativo (restaurar arquivos da fita, recarregar bancos de dados a partir de despejos), detalhes do fornecedor / suporte, requisitos de rede, como e onde obter hardware de substituição - tudo o que você puder imaginar ajudará a recuperar o sistema.

Automação:

• Automatize o máximo que puder. Se você precisar fazer algo três vezes, verifique se o segundo é gasto no desenvolvimento de sua automação, para que o terceiro seja totalmente automatizado. Se você não pode automatizar, documente. Existem suítes de automação por aí - veja se você pode fazê-las funcionar para você.

Monitoramento:

• A instrumentação de aplicação é ouro puro. A capacidade de observar transações que passam pelo sistema facilita a depuração e a solução de problemas.

• Crie testes de ponta a ponta que comprovem não apenas que o aplicativo está ativo, mas realmente faz o que deveria. Os pontos são seus, se puderem ser conectados ao sistema de monitoramento para fins de alerta. Isso serve duplo dever; além de provar que o aplicativo funciona, ele facilita significativamente as atualizações do sistema (o sistema monitora os relatórios em verde, a atualização funciona, é hora de voltar para casa).

• Avalie, monitore e colete métricas sobre tudo o que é sensato para fazer isso. Os benchmarks dizem quando esperar que algo solte a fumaça mágica. O monitoramento informa quando é o caso. Métricas e estatísticas facilitam a obtenção do novo kit (com fumaça mágica fresca) através do gerenciamento.

• Se você não possui um sistema de monitoramento, implemente um. Pontos de bônus se você realmente realizar os testes de ponta a ponta acima.

Segurança:

• "chmod 777" (também conhecido como conceder todos os acessos / privilégios) nunca é a solução.

• Inscreva-se no princípio 'mínimo bit'; se não estiver instalado, copiado ou vivendo no disco, ele não poderá ser comprometido. A instalação de sistemas operacionais e de software "pia da cozinha" pode facilitar a vida durante a fase de construção, mas você acaba pagando por isso no futuro.

• Saiba para que servem todas as portas abertas de um servidor. Faça uma auditoria frequente para garantir que não sejam exibidas novas.

• Não tente limpar um servidor comprometido; ele precisa ser reconstruído do zero. Reconstrua em um servidor sobressalente com mídia recém-baixada, restaurando apenas os dados dos backups (pois os binários podem estar comprometidos) ou clonando o host comprometido em algum lugar isolado para análise, para que você possa reconstruir no mesmo kit. Há todo um pesadelo legal em torno disso, por isso erre no lado da preservação, caso você precise seguir caminhos legais. (Nota: IANAL).

Hardware:

• Nunca assuma que algo fará o que diz na caixa. Prove que ele faz o que você precisa, caso não o faça. Você se verá dizendo "quase funciona" com mais frequência do que o esperado.

• Não economize no gerenciamento de hardware remoto. O gerenciamento de consoles seriais e luzes apagadas deve ser considerado obrigatório. Pontos de bônus para réguas de energia controladas remotamente nos momentos em que você estiver sem opções.

(Além disso: existem duas maneiras de corrigir um problema às três da manhã, uma envolve estar quente, trabalhar em um laptop através de uma VPN em seu pijama, a outra envolve uma jaqueta grossa e uma unidade para o datacenter / escritório. Eu sei qual preferir.)

Gerenciamento de Projetos:

• Envolva as pessoas que manterão o sistema desde o primeiro dia do ciclo de vida do projeto. Os prazos de entrega do kit e do tempo do cérebro podem e irão surpreender, e não há dúvida de que eles terão (deveriam?) Padrões ou requisitos que se tornarão dependências do projeto.

• A documentação faz parte do projeto. Você nunca terá tempo para escrever a coisa toda depois que o projeto for encerrado e o sistema for movido para manutenção, portanto, verifique se isso está incluído como esforço no cronograma no início.

• Implemente a obsolescência planejada no projeto desde o primeiro dia e inicie o ciclo de atualização seis meses antes do dia de desativação especificado na documentação do projeto.

Os servidores têm uma vida útil definida quando são adequados para uso na produção. O final dessa vida útil é geralmente definido como sempre que o fornecedor começa a cobrar mais em manutenção anual do que custaria para atualizar o kit, ou em torno de três anos, o que for menor. Após esse período, eles são ótimos para ambientes de desenvolvimento / teste, mas você não deve confiar neles para administrar os negócios. Revisitar o ambiente em dois anos e meio dá a você tempo suficiente para percorrer as etapas necessárias de gerenciamento e financiamento para que o novo kit seja solicitado e implementar uma migração suave antes de enviar o kit antigo para o grande fornecedor no céu.

Desenvolvimento:

• Garanta que seus sistemas de desenvolvimento e teste se assemelhem à produção. As VMs ou outras técnicas de virtualização (zonas, LDOMs, vservers) facilitam clones de produção do mundo real em todos os sentidos, mas com desempenho.

Backups

• Dados que você não está fazendo backup são dados que você não deseja. Esta é uma lei imutável. Verifique se a sua realidade combina com isso.

• Os backups são mais difíceis do que parecem; alguns arquivos serão abertos ou bloqueados, enquanto outros precisam ser desativados para ter alguma esperança de recuperação, e todos esses problemas precisam ser resolvidos. Alguns pacotes de backup têm agentes ou outros métodos para lidar com arquivos abertos / bloqueados, outros não. Despejar bancos de dados em disco e fazer backup deles conta como uma forma de "desativação", mas não é o único método.

• Os backups são inúteis, a menos que sejam testados. A cada poucos meses, retire uma fita aleatória dos arquivos, verifique se ela realmente possui dados e se os dados são consistentes.

E o mais importante ...

Escolha seus modos de falha, ou Murphy irá ... e Murphy não funciona de acordo com sua programação.

Projete para falhas, documente os pontos fracos projetados de cada sistema, o que os aciona e como se recuperar. Fará toda a diferença quando algo der errado.

Não assuma que é fácil. Conheço muitos programadores que pensam que só porque podem configurar o IIS ou o Apache na caixa de desenvolvimento que podem executar um farm da web. Entenda o que o trabalho envolve e faça sua pesquisa e planejamento, não pense apenas que o trabalho do administrador de sistemas é a coisa mais fácil que você pode fazer em 10 minutos para implantar o aplicativo.

• Perceba que, para o bem ou para o mal, muitos dos servidores e / ou equipamentos de rede que eles tendem a parecer muito com crianças de uma segunda família. Estes são os bebês deles. Eles cuidam deles, ajudam-nos quando estão doentes e os monitoram vigilante quanto a problemas. Isso não deve ser assim, mas depois de muitos anos, geralmente é . Lembre-se disso ao comunicar a eles suas preocupações sobre o desempenho do equipamento ou as expectativas. E se você receber uma resposta que não entende, tente filtrá-la nessa visão de mundo.
• Seja em boas condições de trabalho. Parece cafona, mas vale seu peso em ouro. Algum dia, você precisará de um favor especial. E algum dia, esse administrador de sistemas ficará feliz em fazer o possível para tornar a vida um pouco mais fácil para você, apenas desta vez.
• Essa relação de trabalho é nos dois sentidos. Se o administrador do sistema estiver muito ocupado e você puder facilitar a vida escrevendo um pequeno script ou programa, faça-o! Eles vão gostar mais do que você imagina.
• Seja muito claro. "Isso é péssimo" não é tão claro quanto "ter uma conexão de rede intermitente é um pouco chato, tem alguma chance de você olhar?"
• Se você acha que seu aplicativo será dimensionado, pergunte ao administrador antes de assumir que sim. Eles podem "ver" algo que você não vê ou saber algo sobre os limites de desempenho do equipamento no qual você vai implantar.
• Se o seu aplicativo precisar de ajuste, mas não parecer um problema de código, pergunte bem sobre o desempenho dos servidores. Os administradores de sistemas cuidam de suas máquinas com carinho e não ficam satisfeitos quando estão "doentes" ou "se comportam mal". Pedir muito bem irá transformar uma máquina enferma (ou consertá-la / substituída).
• (como mencionado em outro lugar) documente as configurações que você usa e por que você as usa. Apenas "definir a caixa de seleção X" ou "descomentar a linha do arquivo de configuração Y" não ajuda. Você pode definir a opção que apaga todos os seus dados na próxima reinicialização, pelo que sabe.
• Se você não tiver tempo para documentar a configuração no papel, tente documentá-la no sistema, se possível. Com os arquivos de configuração, isso deve ser quase uma prática padrão - todas as alterações de configuração devem ter um carimbo de data, com as iniciais, o efeito esperado dessa configuração e o motivo pelo qual ela foi alterada (consulte o tópico anterior). Esse pequeno hábito salvou meu bacon mais de uma vez durante a crise. "Por que fizemos isso?" "Como determinamos a política X, e a configuração Y nos dá o comportamento que precisamos para a política X".
• Cerveja. Ou cola. Ou até água. As bebidas são sempre bem-vindas. Ser administrador de sistemas é um trabalho sedento.

Segurança não é uma reflexão tardia. Embora um aplicativo hackeado possa fazer com que o programador pareça incompetente, é (pelo menos) um fim de semana perdido gasto verificando, limpando e / ou restaurando a partir de backups para um administrador de sistema.

Por esse motivo, não trate os backups como controle de versão. Eles são para recuperação de desastres e não foram projetados para restaurar seu código, porque você esqueceu o que mudou.

E pare de culpar cegamente as atualizações do Windows por seu código estar quebrado. Não me importo que tenha funcionado antes, me diga por que não funciona agora - então podemos ver de quem é a culpa.

Como depurar problemas de rede e assistir seu programa ser executado com ferramentas sysadmin. Como programador que começou na administração de sistemas, fico impressionado com o quão impotentes muitos programadores se tornam quando a rede "simplesmente para".

• Wireshark , para assistir seu código ser executado de maneira caixa preta, pacote por pacote
• Ferramentas para conectar-se diretamente aos serviços de rede:
  • Telnet, netcat ou socat para conexões simples por TCP ou UDP
  • OpenSSL para a mesma coisa com criptografia (dica: tente openssl s_client -connect target-host:portalgum dia), para conectar manualmente aos serviços de rede
• dig (no pacote BIND 9) para depurar a resolução de nomes
• Ser capaz de dizer qual parte da pilha de rede falhou com base no tempo e outras características de uma conexão com falha
• Possivelmente HTTPFox e / ou Firebug

Saiba como solucionar problemas.

É muito fácil passar a bola (por exemplo, sua rede está hospedando minha comunicação com o banco de dados). Pode ser uma falha da rede, mas você deve ter logs de aplicativos com erros que, usando o Google ou o SO, possam revelar um problema na configuração de um aplicativo.

Todo mundo gosta de culpar o hardware, o SO ou a rede; portanto, se você praticar um pouco mais de diligência, você fará do administrador de sistemas uma pessoa feliz. Porque, se nada mais, você poderá apontá-los em uma direção específica sobre o que pode estar errado (em vez de dizer "sua rede é péssima" ou algo igualmente útil).

Documente tudo o que puder. Não posso dizer quantas vezes o último administrador de sistemas pensou que seria legal não documentar algo para 'segurança no emprego' ou alguém só queria entrar e sair. Assim como um programador deve deixar bons comentários, os administradores de sistemas devem documentar. Um diagrama da topologia também seria bom.

Plano B.

Sempre tenha em mente um plano de recuperação de desastre ao projetar e desenvolver uma solução. Reconheça pontos únicos de falha que podem levar a uma interrupção.

Documentação: não há necessidade de enlouquecer, mas como o aplicativo funciona, um diagrama mostrando como os bits se encaixam e maneiras de testar cada componente quando tudo der errado. Dados de amostra e saída são bons.

Requisitos: em quais módulos ele se baseia? Versões? OS?

Monitoramento: idealmente, os desenvolvedores incluem informações e testes de monitoramento com o aplicativo.

Falando em embalagem, EMBALAGEM! Nada pior que uma "implantação", que significa fazer check-out de uma nova revisão de um arquivo do VCS e copiá-lo para vários servidores. Frequentemente, os programadores não apreciam a complexidade da implantação de software: existem razões pelas quais o software empacotado e com versão de versão constitui a espinha dorsal da maioria dos sistemas operacionais.

Se um desenvolvedor viesse a mim com um RPM instalado pela primeira vez com documentação concisa e abrangente e alguns testes do Nagios, ele seria meu novo melhor amigo.

Estou surpreso que nenhuma das 17 respostas fornecidas aqui até agora inclua algo sobre como garantir que seu aplicativo seja executado quando conectado como usuário padrão.

Além do processo de instalação, o aplicativo deve funcionar bem quando conectado com uma conta de usuário padrão.

Backup Backup Backup .... Teste o backup ... Esteja sempre pronto para reverter

Isso pode se aplicar apenas aos programadores iniciantes, mas eu trato de algumas coisas em todos os projetos com alguns programadores.

1. "Funciona na minha máquina" nem sempre é uma declaração válida. É de responsabilidade do programador criar um programa de instalação para uso no servidor ou, pelo menos, documentar todas as conexões, dlls e suplementos necessários no servidor.

2. (Eu ouvi isso várias vezes, por isso não ria) Eu corro o exe no servidor da minha máquina e ele funciona. Mas, quando eu o executo no servidor (Citrix, Terminal Server, etc.), ele não funciona. Por favor, entenda DLLs e OCXs e qualquer outra coisa que seu programa exija, onde e como eles são registrados, e como seu programa os utiliza.

Isso pode parecer simples, mas eu lido com isso constantemente.

Brian

• converse com seu administrador, formal e informalmente, sobre o que você está fazendo. Eles geralmente estarão interessados ​​e podem expressar possíveis impactos sobre a produção desde o início. Você não precisa concordar, mas ajuda a identificar pontos problemáticos.
• Não, você não pode ter todo o servidor para si mesmo ... Se precisar, é uma decisão política, independentemente de quão tecnicamente seja. Se você quer trabalhar na política, vá em frente.
• O hardware de produção geralmente parece diferente do servidor de desenvolvimento e, mesmo dentro dos farms, as especificações das máquinas são diferentes.
• Saiba como a produção é configurada, porque você provavelmente não pode replicá-la na sua área de trabalho; isso impede que você faça suposições ruins.
• Só porque você pode armazenar em cache coisas na memória não significa que deveria, aguarde primeiro o gargalo (no teste de unidade ou no teste de desempenho de pré-produção)
• se você estiver colando dados em um banco de dados, pense em como você pode dividir os dados em dados somente leitura (que podem ser dimensionados horizontalmente) e dados de leitura e gravação (que geralmente são dimensionados verticalmente).
• se você estiver colando dados em um banco de dados, deve ser realmente um RDBMS? existem outros sistemas de pares de valores-chave que escalam melhor (netcache).
• Não pense que o AJAX é a solução definitiva, parece legal, mas limita as possibilidades de monitoramento e automação. Não estou dizendo para não usá-lo, apenas pense duas vezes.

OK, isso é um pouco ofensivo, mas:

a) Ao codificar, suponha que a infraestrutura subjacente possa falhar e não provenha de terra sempre feliz e feliz. Ou no Google.

b) Provavelmente não temos recursos para implementar algo como a infraestrutura sobre a qual você leu; portanto, fique tranquilo quando as coisas acontecerem. É provável que saibamos o que precisa ser feito, mas por qualquer motivo, isso ainda não aconteceu. Nós somos seus parceiros!

c) Como jhs disse acima, realmente ajudaria se você tivesse familiaridade com ferramentas para solucionar problemas de infraestrutura, como ping, traceroute (ou combinação de ambos - mtr), escavação, etc.

d) Se você programa um computador, realmente deve saber como ele se conecta à rede e o básico, como poder analisar a saída de ipconfig / all ou ifconfig. Você deve conseguir instalar sua conexão com a Internet com o mínimo de ajuda.

Caso contrário, acho que Avery acertou em cheio. Devs que praticam um pouco de sysadmin valem seu peso em ouro! Mas igualmente, administradores de sistema que entendem como os desenvolvedores lidam com as coisas (incluindo versão etc.) são praticamente essenciais nos dias de hoje.

Isso parece estar no ar no momento, notei mais discussões sobre o relacionamento de dev / ops em blogs - confira

Mantendo o Twitter Twitter

Partições e guerra

Teste primeiro nas operações

Que nenhum grupo ou função é 'melhor' que outro e que nenhum exige 'cérebros maiores' que o outro também. Eu já vi os dois lados ficarem prima-dona'ish na empresa do outro - todos estão tentando alcançar os mesmos objetivos - focar nessas semelhanças e não no fato de usar ferramentas diferentes.

O arquiteto de infraestrutura virou programador, mas pode querer reverter essa transação no futuro :)

1. Conversem entre si, cedo e com frequência. Analise os projetos com os funcionários que gerenciarão a infraestrutura em que seu aplicativo será implantado (se você souber quem será).
2. A perda zero de dados é possível, mas é uma responsabilidade compartilhada por desenvolvedores e administradores de sistemas. Mais uma vez, conversar um com o outro pode ajudar aqui.
3. Sua equipe de infraestrutura deveria estar envolvida na determinação dos requisitos não funcionais.
4. Organize cerveja (quando o trabalho estiver concluído) e pizza (enquanto estamos trabalhando). De alguma forma, a presença desse tipo de alimento afeta nossa capacidade de fazer com que nossas pequenas e agradáveis ​​caixas de 32 cpu façam o que você quiser: :)

Como alguém que foi administrador de sistemas para desenvolvedores e também desenvolvedor, o conselho dado aqui não é apenas ouro, mas deve fazer parte da documentação de contratação de novos desenvolvedores para empresas de todo o mundo.

Algo que eu não vi (ainda) expliquei é que os desenvolvedores realmente devem conhecer os produtos que usarão para criar os programas pelos quais são pagos. A quantidade de vezes que tive que explicar e configurar servidores apache, eclipse e instalações do Visual Studio e banco de dados em máquinas de desenvolvedor é um pouco preocupante.