O Engenheiro de Escalação (Escalation Engineer)
Por: Roberto Alexis Farah
Pretendo, com esse artigo, explicar o que é a posição de Engenheiro de Escalação e como trabalhamos. Também gostaria que futuros candidatos a vagas na Microsoft saibam da existência dessa posição.
O Escalation Engineer e Support Escalation Engineer é uma espécie de detetive de software e certamente muitos aqui na Microsoft nos vêem desse jeito.
Já para as pessoas de fora da Microsoft, como alguns clientes, amigos, parceiros, etc... isso não é muito claro.
Ok, reconheço que minhas explicações devem ter sido muito mais vagas do que sucintas, portanto, coloco aqui todos os detalhes para esclarecer o que é ser Engenheiro de Escalação.
Em números há muito menos Escalation Engineers aqui que Software Design Engineer in Test e Software Design Engineer, entretanto, as 3 posições requerem, em algum grau, conhecimento de desenvolvimento, teste e depuração, mas enquanto o SDE tem foco em desenvolver features dos produtos e especificações, o SDET em desenvolver ferramentas para testes para automatizar os testes de código, o EE/SEE tem foco em depurar código e criar ferramentas de troubleshooting, trabalhando diretamente com nossos clientes. Além disso, os SDE/SDET trabalham durante o desenvolvimento do produto e nós, os EEs, trabalhamos quando o produto foi completamente desenvolvido e já está sendo utilizado pelos usuários.
Quando um desenvolvedor está criando código, imagine que ele está dando o melhor de si e criando o melhor código possível para resolver um problema específico. Muitas vezes este código pode ter falhas não detectadas pelo desenvolvedor nem pelo testador, indo ao mercado com defeito de código (ou bug) . Se o desenvolvedor e o testador deram o melhor que puderam para fazer um código excelente e ainda assim o código apresenta um problema, quem é que entra no circuito com conhecimento de código e técnicas avançadas de depuração, adicionalmente a um conhecimento abrangente do produto? Se você disse “Escalation Engineer” ou “Support Escalation Engineer”, acertou J.
A posição de Engenheiro de Escalação não é uma posição comum em outras empresas, portanto, é compreensível que seja pouco conhecida.
A função dos Engenheiros de Escalação é de isolar complexos problemas que nos chegam por Engenheiros de Suporte (Support Engineers) ou diretamente por clientes em incidentes críticos onde o ambiente de produção do cliente está sendo severamente impactado. Utilizamos, para isso, ferramentas de troubleshooting e depuradores.
Basicamente a maior diferença entre um SEE e um EE é que o EE trabalha em incidentes onde comprovadamente há um defeito no código. Nesse caso, ele reproduz o sintoma em laboratório e depura nossas aplicações. É o EE quem conversa com os times de produtos sobre falhas e ajuda a definir as próximas versões de produtos baseado no feedback de anomalias ou falhas identificadas, facilidade de troubleshooting, etc...
O SEE trabalha no incidente para definir se é uma anomalia em nossos produtos ou não. Se comprovado que é algo nos nossos produtos, o incidente é redirecionado para o EE e se é uma falha ou anomalia na aplicação do cliente então o SEE continua com o incidente.
A natureza do trabalho é investigativa e passamos a maior parte do tempo usando ferramentas de troubleshooting (muitas desenvolvidas por nós mesmos!) para coletar logs e depurando aplicações ou dumps de aplicações.
No restante do texto não farei distinção entre SEE e EE visto que EE é uma espécia de SEE com mais especialização por produto e mais responsabilidades.
PERFIL DO ENGENHEIRO DE ESCALAÇÃO
O Escalation Engineer tem, de um modo geral, as seguintes habilidades, que variam um pouco conforme o foco em Platforms (Windows, SMS, MOM), Messaging (Exchange, Outlook, Security ISA, WSUS, etc) ou Developer Support (Suporte a Desenvolvimento, IIS, SQL Server):
- Forte conhecimento de depuração usando o WinDbg, nosso mais potente depurador.
- Habilidade para depurar em cenários onde pode não haver acesso ao código fonte ou símbolos, como no caso de algumas aplicações de clientes ou de fornecedores dos clientes.
- Habilidade de fazer engenharia reversa quando necessário, baseando-se no código disassemblado.
- Conhecimento dos detalhes internos de arquivos executáveis (PE), dlls, produtos e sistema operacional.
- Habilidade para isolar problemas partindo-se do código binário até chegar no código fonte.
- Habilidade de entender cenários complexos de integração de produtos e tecnologias de modo a elaborar uma hipótese coerente que possa explicar o sintoma apresentado e direcionar a investigação para tentar comprová-la.
- Proeficiência em C/C++ e Assembly para poder ler nosso código fonte que é feito, na sua maioria, em C++, C e Assembly e a entender código disassemblado quando analisando dumps de aplicações.
- Habilidade de depurar código gerenciado (.NET) usando WinDbg e as extensões do depurador para .NET.
- Especialização de troubleshooting por produto/tecnologia: MSMQ, Exchange, SQL Server, IIS, Windows, Sharepoint, etc...
- Alguns EE´s desenvolvem software utilitário para troubleshooting, de uso interno ou público, durante o tempo livre. De fato, muitos utilitários que podem ser baixados do nosso website ou que estão em sites públicos foram desenvolvidos por Engenheiros de Escalação nas suas horas vagas!
- Conhecimento de otimização de código e/ou produtos de modo a atuar em cenários onde há problemas de performance, que é uma área onde também atuamos muito.
Aqui algo mais sobre a posição de EE encontrada em blogs de colegas de profissão:
https://msexchangeteam.com/archive/2004/02/16/73971.aspx
https://blogs.msdn.com/jasperk/archive/2005/02/08/369528.aspx
https://blogs.msdn.com/dgoldman/articles/157513.aspx
https://blogs.msdn.com/jeremyk/default.aspx
https://blogs.gotdotnet.com/tess/archive/2005/11/25/496895.aspx
https://members.microsoft.com/careers/epdb/profileDetailPage.aspx?profileID=30
https://blogs.msdn.com/ausjobblog/archive/2005/01/27/361150.aspx
https://msexchangeteam.com/archive/2004/04/13/112450.aspx
https://blogs.msdn.com/jamesche/
METODOLOGIA USADA PARA ISOLAR PROBLEMAS
Eis um excelente artigo no blog do meu gerente que explica a metodologia que usamos para isolar problemas. É uma abordagem científica que pode ser usada em diferentes domínios.
The Problem Resolution Framework
https://blogs.msdn.com/deomel/archive/2006/03/14/551537.aspx
UMA BREVE DESCRIÇÃO SOBRE INCIDENTES DE SUPORTE
What is a support incident?
https://blogs.msdn.com/deomel/archive/2004/10/21/246128.aspx
Basicamente um incidente ou “caso” como nos referimos aqui é um chamado de cliente que foi direcionado ou escalado para nós. Trabalhamos com diversos incidentes ao mesmo tempo; enquanto enviamos Plano de Ação para um cliente, analisamos dumps de outro cliente, logs de outro, etc... Como parte do trabalho está no lado do cliente que deve implementar nossos Planos de Ações, temos tempo para atender diferentes chamados.
O modo como priorizamos esse chamado se baseia em Severidade e Prioridade que são duas medidas que usamos para identificar a criticidade de um incidente.
Basicamente, o pior cenário, considerado um caso de Severidade A é quando temos o ambiente de produção de um cliente severamente impactado. Nesse cenário trabalhamos apenas com esse incidente até que a situação seja amenizada ou normalizada.
PERCEPÇÕES PESSOAIS
Aqui na Microsoft as pessoas amam o que fazem, então todos nós temos a tendência a achar que nossa posição é a mais legal. Obviamente eu também acho isso e, como realmente adoro meu trabalho, vou colocar aqui as principais razões pela qual tenho paixão pelo que faço:
- Estou sempre aprendendo coisas novas. E quanto mais aprendo mais vejo o quanto faltam coisas para aprender. (ok, as vezes isso é frustrante J )
- Gosto da natureza investigativa do trabalho. Se assemelha a um trabalho de detetive ou de polícia forense.
- Gosto da idéia de fazer software pequeno, onde participo da arquitetura, teste e desenvolvimento, mais do que fazer uma parte específica de um software grande. Gosto de saber que posso criar o utilitário que quiser, sozinho ou em um pequeno time, e que ser for bem sucedido será vastamente utilizado. Que, mesmo sendo algo pequeno, pode impactar positivamente o trabalho de muitos usuários e engenheiros.
- Gosto de entender como as coisas funcionam internamente, exatamente o que consigo quando depurando uma aplicação. Entender os “porques”. E geralmente para entender os “porques” precisamos de entender o software no baixo nível, na raiz.
- Gosto da sensação de realização quando superamos a expectativa de um cliente ao isolar um complexo problema. É gratificante!
- Gosto do desafio que o trabalho proporciona, onde temos que isolar problemas que muitas vezes outros tentaram resolver e não foram bem sucedidos.
- Gosto do desafio de achar uma solução simples para um problema complexo.
VAGAS DE SEE/EE NA MICROSOFT
Acredito que após ler esse artigo muitos devem ter achado a posição excitante, outros surpresos por desconhecerem a existência dessa posição. Foi exatamente isso que senti anos atrás!
Se você acredita ter perfil para ser Engenheiro de Escalação consulte o link acima constantemente para saber das vagas em aberto.
Caso deseje se preparar melhor para a posição, no caso de ser entrevistado, aqui vão algumas dicas:
- Leia sempre nosso blog! J Sim, é sério! Colocamos aqui informação que usamos diariamente e que podem ser usadas ao entrevistar candidatos.
- Melhore seu conhecimento de troubleshooting do produto com que deseja trabalhar. Por exemplo, se você pensa em ser SEE/EE de SQL Server é desejável que saiba como identificar problemas de performance, otimizar stored procedures, etc... O foco maior deve ser em como fazer troubleshooting do produto. Mesma coisa para IIS, Exchange, etc...
- Se seu objetivo é trabalhar com escalação em Platforms, tente saber algo de Kernel Debug. O Driver Development Kit e o help do WinDbg são uma boa referência para Kernel Debug.
- Leia livros como: Windows Internals, Debugging Applications for .NET and Windows, Code Complete 2, Effective C++, More Effective C++, Writing Secure Code 2, The Art Of Assembly Language e outros que tratam do tema de programação, depuração de código, hackers e exploração de falhas de software, assembly e engenharia reversa. Embora nosso foco não seja trabalhar com falhas de segurança ou vírus esse é um bom meio de se saber mais sobre detalhes internos de aplicações e bugs.
- Leia blogs de Escalation Engineers.
- Leia artigos sobre WinDbg e tente aprender algo sobre ele. Familiarize-se com o DebugDiag e os relatórios de análises automatizadas.
- Treine programação em C#/C/C++ para se sentir confortável lendo código nessas linguagens de programação e, eventualmente, criar utilitários para ajudá-lo no trabalho.
- Use a feature de disassembly do Visual Studio para ver o código disassemblado junto com o código fonte, de modo a melhorar seu entendimento de código disassemblado. Lembre-se, muitas vezes você não terá acesso ao código fonte!
- Procure entender mais sobre os contadores e medidas usadas no Performance Monitor. Usamos o Performance Monitor na grande maioria das vezes.
- Procure conhecer e saber como usar as ferramentas de troubleshooting para determinado produto e as ferramentas do Visual Studio e Debugging Tools For Windows.
- Crie ferramentas, isto é, software utilitário usado para fazer troubleshooting de algo. A linguagem de programação usada é o que menos importa, o que vale é a idéia!
Se você seguir as dicas acima, com o tempo você vai adquirir um certo feeling, digo, um olhar treinado para identificar problemas de software que será muito útil na profissão. É mais ou menos como ver o código fonte de uma aplicação e visualizar, de modo natural, potenciais bugs. Ou como lidar com a baixa performance de uma grande aplicação e identificar potenciais gargalos olhando o desenho da arquitetura da solução. As vezes essa percepção se manifesta quando vendo uma call stack a partir de um dump de aplicação e visualizando, de imediato, a potencial causa raiz. Enfim, a idéia é, num primeiro instante, melhorar sua percepção para reconhecer padrões relacionados a problemas de software, cujos sintomas se manifestam sob a forma de hang, crash, memory/handle leak e performance, juntamente com suas habilidades de elaborar hipóteses para direcionar a investigação de modo a diagnosticar a causa raiz. Posteriormente você terá que trabalhar as habilidades de depuração e troubleshooting.
Para aqueles que tiverem perguntas sobre a posição de Engenheiro de Escalação é só postar aquí.
Será um prazer responder! J