SysAdmin & Developer: Responsabilidades [fechado]

Quando se trata de algo como um servidor Web de produção, qual é a melhor prática para responsabilidades do administrador de sistemas e desenvolvedor? Especificamente, estou pensando em atualizar / instalar software. (No meu entender, o desenvolvedor não deve ter acesso root no servidor de produção.)

Portanto, um servidor da web de produção está executando o Wordpress e precisa ser atualizado para a versão mais recente. Quem é responsável por mantê-lo atualizado?

E se os desenvolvedores tiverem plugins hackeados personalizados ou arquivos principais personalizados no aplicativo (neste exemplo, WP)?

Descobri que, na maioria dos casos, se você é o responsável pelo servidor físico, é melhor NÃO dar acesso root aos desenvolvedores.

Este é um pouco de um debate sobre "guerra santa", pois tenho certeza que você encontrará desenvolvedores que discordam. Eu pessoalmente estive nos dois lados desse debate.

Meu principal raciocínio para não conceder acesso root aos desenvolvedores (mesmo que sejam 100% confiáveis) é porque, na maioria das vezes, há algum pacote necessário para que o XYZ funcione corretamente. Eles vão em frente e instalam ... ou reconfiguram algo que já está no lugar para que funcione ... ou ... bem ... você entendeu.

Os meses se passam ... o servidor precisa ser reinstalado ou recriado ... e de repente ninguém sabe por que "Ele funciona no servidor antigo, mas não no novo".

A resposta, é claro, é que a documentação que você está vendo não inclui todos os pequenos pacotes e ajustes que os desenvolvedores fizeram para fazer o sistema funcionar pela primeira vez.

Pode ser complicado para os dois lados ... mas se o administrador do sistema for responsável pelo servidor, pelos pacotes e pela documentação ... e o desenvolvedor for responsável pelo desenvolvimento e pelo software ... acho que você ' Vou achar que valeu a pena no final.

Se o desenvolvedor precisar de um plug-in, módulo, configuração, ajustes personalizados ... não há problema ... faça isso por eles ... mas DOCUMENTE-O para que você possa reproduzi-lo da próxima vez.

Regra de Ouro : Não deixe que os não-administradores toquem em algo que não deseja violar e pelo qual será responsabilizado.

Os desenvolvedores devem ter acesso a um ambiente de teste. Quando o trabalho estiver pronto para ser colocado na máquina de produção, ele deverá ser entregue ao administrador do sistema. Se os desenvolvedores tiverem feito seu trabalho e documentado adequadamente o procedimento, tudo correrá bem. Caso contrário, eles precisam de chutes nas costas para não testar adequadamente.

Eu estive nessa batalha também. Minha resposta é que quem é responsável pelo tempo de atividade do servidor é quem deve ser responsável por todas as atualizações, alterações, etc., etc. Ninguém mais deve ter a capacidade de executar esses tipos de funções no servidor. Se é seu trabalho garantir que o servidor esteja em funcionamento e se o chefe o responsabilizar e responder pelo servidor, é sua responsabilidade mantê-lo e protegê-lo.

A maioria dos desenvolvedores dirá que eles precisam de acesso no nível de administrador ao servidor e a maioria deles discordará de mim, mas sou eu quem precisa reiniciá-lo às 2 da manhã quando ele desligar, precisa reconstruí-lo depois uma falha na atualização, o tempo de inatividade é cobrado do meu departamento etc. etc. Tenho que responder ao CIO por qualquer coisa que afete nosso SLA; portanto, sou o único que obtém acesso no nível de administrador ao servidor e eu ' m responsável por todos os componentes, atualizações, alterações, etc.

Eu concordo 100%. Os desenvolvedores, na maioria das vezes, não sabem como as coisas do syadmin funcionam. Se eles precisam de alguma coisa, perguntam, é tudo. Você pensa em como e quando e entrega a eles um pacote utilizável. (como eles precisam enviar e-mails, é você quem deve configurar o postfix). Além disso, eles tendem a pensar que, na maioria das vezes, o acesso root fará as coisas funcionarem se não conseguirem fazê-lo com acesso normal. Eu concordo com outras pessoas aqui, elas não estarão com você às 2 da manhã quando você perceber um problema. Eu tive o caso há algumas semanas, um desenvolvedor queria atualizar seu wordpress. Eu disse para o changelog RTF, para ele, que era inútil, o processo de atualização é feito através de uma interface bonita. Bem, a atualização não funcionou, eu tinha seu aplicativo salvo, fiz o script de backup não ele. Sem mim, ele não poderia restaurar o site.

Há uma tendência para embaçar a distinção entre operações e desenvolvimento. Torne seus desenvolvedores sysadmins e sysadmins.

Nesse sentido, o wordpress poderia se beneficiar de algum trabalho sobre provisionamento automatizado (e programático) de blog. Muitos usuários do wordpress mantêm mais do que algumas instâncias WP / WPMU e atualizá-las em tempo hábil é no mínimo complicado.

Você pode encontrar uma boa (e divertida) visão geral da filosofia nos slides do Agile Infrastructure no Agile 2009

Os desenvolvedores não devem ter raiz na produção; todos, exceto os desenvolvedores, concordam com isso. Mas os desenvolvedores podem ter seu bolo e comê-lo também. Estou um pouco surpreso que ninguém tenha mencionado explicitamente isso:

Um dos meus clientes de muito tempo para pequenas empresas possui um site com uma instalação Drupal, vários sites WordPress, um fórum SMF e alguns outros aplicativos pequenos e aleatórios da Web. Eu sou o administrador do sistema do contrato (e, por razões históricas, também atualizo / hackeado o WordPress e o SMF quando necessário) e meu cliente tem seu próprio contrato com os desenvolvedores do Drupal. O ambiente é de várias máquinas virtuais da VMware em um provedor de nuvem pública.

Os desenvolvedores realmente querem ter acesso root e meio que precisam dele. É responsabilidade deles escrever as regras de reescrita do nginx para fazer com que todo o material Drupal personalizado funcione, por exemplo. Mas de jeito nenhum eu estou dando a eles acesso root no servidor de produção, e meu cliente concorda comigo nisso.

Por isso, comprometemo-nos: eles obtêm acesso root no servidor da Web de teste (que geralmente é idêntico à produção, exceto pelo endereço IP e está na mesma nuvem). Que, como a produção, possui o etckeeper para que eu possa ver as alterações necessárias e os pacotes instalados. Posso então colocar as alterações em produção ou dizer a elas o que há de errado com o que elas querem fazer. E se eles realmente estragaram tudo (ainda não o fizeram, graças a Deus), posso reverter facilmente as alterações.

Eles não têm acesso ao servidor de banco de dados de produção; eles nem têm logins de usuário. Somente eu e meu cliente.

(O aplicativo da Web em si, eles implantam diretamente com o git e, se o quebram, podem corrigi-lo e explicar ao meu cliente por que eles devem continuar sendo seus desenvolvedores. rir deles ou facepalm.)

Raiz == Administrador do sistema.

Usuários == Desenvolvedores, DBAs ou Usuários.

A raiz não dorme quando um servidor está inoperante, a raiz protege os usuários de si mesmos, a raiz protege os dados dos usuários da rede, a raiz coloca a saúde do servidor acima de todos os usuários. O rabo da raiz está em jogo quando o servidor está offline. Servidor feliz, raiz feliz!

Motivos comuns para tempo de inatividade não programado: usuários, alterações não documentadas no ambiente e retroescavadeiras. Os servidores fazem exatamente o que lhes dizem que não quebram aleatoriamente. Hackers que você pergunta, não é se, é quando ... daí a necessidade de uma "raiz".

00:33 CDT você sabe onde estão seus documentos de backup e recuperação de desastre? :-p

Os administradores de sistemas devem ter acesso de administrador (como o título diz). Ninguém mais precisa acessar servidores de produção. Se os desenvolvedores precisarem solucionar um problema em um sistema de produção, esse problema deverá ser reproduzível no ambiente de desenvolvimento. Caso contrário, eles podem se sentar com o administrador do sistema e examinar o sistema.

Os desenvolvedores não gostam de não poder tocar na produção, mas isso não existe. O trabalho é escrever o software e entregá-lo aos administradores de sistemas para uma liberação de produção. Se eles documentaram tudo (e lembre-se de que na maioria das lojas a documentação é uma palavra suja) corretamente, os lançamentos devem ser bons.

Nas empresas públicas aqui nos EUA, você tem SOX, HIPPA etc. para lidar. A maioria desses regulamentos esquecidos por Deus realmente ajuda nesse argumento. O SOX determina a separação de tarefas, o que exige que os desenvolvedores mantenham as mãos longe dos sistemas de produção.