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

[Wagner Elias]

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
>