Re: [GTER] "Faça um manual para que qualquer um possa resolver o problema."

[Alex Robertson]

Imaginemos o processo "instalar e configurar um servidor de hospedagem
para diversos sites".

Como distribuir e configurar as partições /var /home /htdocs /XXX?

Se estivesse documentado, eu não precisaria perguntar para o meu chefe
ou pensar tudo de novo...

O manual passo-a-passo ajuda muito e é necessário sim. Isso não
significa transformar os profissionais em robos. Significa economia de
tempo.

A necessidade de atualização dos profissionais deve ser observada
independente de documentação.

E sobre o "next - next - finish", esse seria o mundo ideal. Se o
passo-a passo estiver bem documentado, ele acaba virando um script que
apenas pede os parâmetros necessários. Mais ainda, se os parâmetros
puderem ser calculados / estimados / medidos, muito melhor!

Claro que exitirão as tarefas e incidentes que o "siga os passos" não
vai dar conta. - Graças a Deus, senão estaríamos todos desempregados
ou falidos!

[]s
Alex Robertson

Em 22/02/06, Wagner Elias<wagner.elias at gmail.com> escreveu:
> A visão de um chefe tapado que acha que pode substituir alguém não vai mudar
> pelo fato de ter documentado ou não. Quem faz isso vai fazer mesmo sem
> manual...
>
> E talvez o que não foi levantado é a importancia da documentação de
> procedimentos em um processo de recuperação de desastres, incidentes graves.
> Quando descrevemos um procedimento de recuperação fica bem claro um ponto
> fator crítico de sucesso.
>
> O que fazer: instalar o linux;
> Quando: quando a maquina não subir mais;
> Como: pegando o cd no local tal, colocar no cd, etc...;
> Quem: equipe de analista linux;
> FATOR CRÍTICO DE SUCESSO: analistas devem possuir habilidades e
> conhecimentos necessários para executar o procedimento.
>
> Abs.
> --
> Wagner Elias - OWASP Project Leader Brazil
> http://wagnerelias.blogspot.com/
> Xcorp Consulting do Brasil
>
> On 2/21/06, Rodrigo Ristow Branco <rrbranco at pobox.com> wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Isso colabora para a banalização do dia-a-dia, fazendo com que a
> > criação de soluções elaboradas e complexas que ocorreram após análise
> > detalhada e estudo de caso se transforme em "next, next, finish".
> >
> > Colabora também para o aumento do potencial de substituição de
> > qualquer um que seja, a qualquer tempo e hora.
> >
> > Concordo que deva existir documentação, mas fazer um manual que
> > informa que um conector DB-9 (mach) tem esse desenho / lay-out e o
> > mesmo cabo DB-9 (femea) é "ligeiramente diferente", incluindo fotos no
> > manual, já é exagero.  (Juro que vi isso).
> >
> > O executor dos procedimentos (o robô), fica com a falsa sensação de
> > que sabe solucionar problemas, o chefe pode acreditar nisso e ficar
> > tendencioso a tomar decisões equivocadas, como por exemplo avaliação
> > de necessidade de treinamento, avaliação de necessidade de projetos
> > para melhorar a infra-estrutura com a aquisição/implantação de
> > hardwares e/ou softwares novos no ambiente.
> >
> > Qual seria a justificativa de investir, já que tudo está funcionando
> > direito e o robô sabe consertar em caso de problemas ?
> >
> > Qual a necessidade de treinar o idealizador / designer da
> > infra-estrutura, se o que ele fez pode ser mantido por qualquer um ?
> >
> > O chefe pode pensar: "Já que é tão simples e trivial o que analista
> > fez (já que o técnico "espertinho" consegue consertar seguindo o
> > bê-á-bá) então desperdicei tempo e dinheiro quando ele foi para aquele
> > determinado treinamento ?"
> >
> > Quando tiver um probleminha mais complicado ou o robô apertar um botão
> > errado, como fica ?  O robô vai ser desmascarado ?  O analista vai ser
> > julgado como esconde jogo e que não documentou de propósito ?
> >
> > Novamente, concordo que a documentação é necessária, porém o público
> > alvo deste manual não é o robô, e sim outro analista com conhecimento
> > razoável para poder pensar no que está acontecendo e/ou acontecerá
> > quando de determinadas ações e comandos foram efetuados, antes de
> > começar a meter a mão na massa.
> >
> > Entendo que deva existir a necessidade de "colocar o
> > [equipamento|sistema|you name it] em funcionamento, caso"  *alguem*
> > "não esteja", por questões de SLA, multas, impacto, prejuízos de
> > financeiros e/ou na imagem, etc etc etc, mas isso não significa que
> > tenha que estar escrito : "verifique a a situação de um serviço do
> > Windows chamado XPTO" e instrua o robô da seguinte forma: "clique com
> > o botão da esquerda em Iniciar, painel de controle, ferramentas
> > administrativas, dois clics em serviços".   E se por acaso o for um
> > técnico ou analista com conhecimento e resolver fazer o seguinte:
> > clicar iniciar, executar, services.msc .  O próximo passo será
> > inexequivel ?
> >
> > E se o executor souber que não precisa ser feito localmente da
> > equipamento em questão, se ele souber pode ser feito pela rede,
> > poupando tempo de deslocamento desnecessário ?  Ele será elogiado por
> > que o serviço voltou a ser executado ou será penalisado por que não
> > seguiu a risca o manual ?
> >
> > Os méritos do serviço re-inicializado são do executor ou do escriba ?
> >
> > Os conhecimentos do técnico serão totalmente descartados e ele nunca
> > poderá ser avaliado corretamente visto que do ponto de vista do chefe,
> > ele só sabe ler papel e clicar ?
> >
> > E o técnico será para sempre técnico, já que sem curso e treinamento
> > ele dá conta do recado, então para que investir nele ?
> >
> > E em casos "fortuitos e/ou de força maior" ?  Aí o projeto foi mal
> > feito ? Mal documentado ?  Como prevêr todos os problemas e elaborar
> > soluções para cada um ?   E enquanto faz isso, então não consegue
> > planejar e implementar nada novo ?  A infra-estrutura ficará estatica
> > e não evoluirá mais ?
> >
> > Saudações a todos,
> >
> > Rodrigo Ristow Branco
> > rrbranco -AT- pobox.com
> >
> >
> >
> >
> >
> > MARLON BORBA wrote:
> > > Srs.,
> > >
> > > Não sei se é esta a melhor lista para a discussão que se segue, mas
> > decidi jogando u'a moeda para o alto: era a GTER ou a Masoch-L. Deve ser
> > "on-topic" porque o problema é vivido no dia-a-dia dos operadores da Rede.
> > >
> > > Nesta era de redes multiprotocolo, equipamentos distintos como
> > "switches", roteadores, WiFi e o escambal, existem chefes (eu conheço
> > diversos) que pedem aos seus técnicos-chaves (aqueles que no frigir dos
> > ovos resolvem as "encrencas") para "escrevem manuais" de forma que
> > "qualquer pessoa, seguindo os passos, possa colocar o
> > [equipamento|sistema|you name it] em funcionamento, caso você não esteja
> > aqui."
> > >
> > > Pergunto aos experientes profissionais da GTER: Tal pedido se sustenta
> > nesta era de configurações complexas, de incidentes de segurança
> > afetando milhares de máquinas (como, por exemplo, botnets), de
> > plataformas heterogêneas trocando informações? Não acham, como eu, que o
> > sujeito não pode, jamais, ser um completo robô seguidor de manuais, mas
> > ter um mínimo de conhecimento técnico, até para saber como lidar com
> > aqueles imprevistos não descritos nos textos?
> > >
> > > Como provar aos seus superiores, à saciedade, que os tempos mudaram e
> > que o mundo está muito mais complexo?
> > >
> > >
> > >
> > > Abraços,
> > > Marlon Borba, CISSP.
> > >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.0 (MingW32)
> >
> > iD8DBQFD+8EVZnfhsqseR3YRAtMyAJ9/QJ45fybJaj4s4nnqc8w4EhcW2ACfQ+59
> > qb+9EORsZ527LkDrFESq550=
> > =53Ba
> > -----END PGP SIGNATURE-----
> >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>