[SQL Server] Replicando acessos administrativos para usuários em um SQL Server gerenciado em Cloud

Recentemente tive a necessidade de inserir algumas instancias SQL Server que administro no Hashicorp Vault para que ele gerencia-se a criação de usuários de forma segura e auditada (posteriormente farei um post sobre como efetuar esta integração).

O Vault trabalha com o conceito de roles, cada role possui um comando de criação de usuário e um comando de remoção deste usuário, isso por que um usuário criado pelo Vault tem tempo para existir, isso é uma boa prática de segurança que deve ser observada.

Dado o contexto do Vault, qual o intuito deste post? Simples, o Vault executa um comando SQL para criar o usuário, mas e quando precisamos criar um usuário administrativo em uma instancia de banco de dados gerenciada em Cloud? Pois é. Os serviços gerenciados de bancos de dados em Cloud Pública restringem acessos dos usuários, mesmos dos usuários administrativos\master da instancia.

Outro exemplo de uso dessas procedures é quando não queremos que o usuário tenha permissões de SYSADMIN na instancia, limitando assim o nível de acesso a componentes e features internos da instancia como AlwaysOn, Resource Governor, etc.

Abaixo deixo 2 exemplos de procedures que podem ser criadas para conceder acesso a usuários de forma dinâmica de forma simples.

CREATE PROCEDURE sp_create_user (
        @user_name VARCHAR(100)
        ,@user_password NVARCHAR(512)
        ,@user_type VARCHAR(5) -- admin ou read
)
AS
BEGIN

    SET XACT_ABORT ON
    SET NOCOUNT ON

    DECLARE @command NVARCHAR(MAX)
        , @database_name VARCHAR(50)
        , @cont INT = 1

    SET @command = '
        USE master;

        CREATE LOGIN [' + @user_name +'] WITH PASSWORD=''' + @user_password + ''' , DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF; 

        ALTER SERVER ROLE [PROCESSADMIN] ADD MEMBER [' + @user_name + '];

        ALTER SERVER ROLE [SETUPADMIN] ADD MEMBER [' + @user_name + '];
    '

    EXEC sp_executesql @command;

    IF @user_type = 'admin'
    BEGIN

        WHILE @cont <= (SELECT MAX(database_id) FROM sys.databases)
        BEGIN

            SET @database_name = DB_NAME(@cont)

            IF @database_name IS NOT NULL AND @database_name NOT IN ('master','model','tempdb','Distribuition','rdsadmin','ReportServer','ReportServerTempDB')
            BEGIN

                SET @command = 'USE [' + @database_name + ']; CREATE USER [' + @user_name + '] FOR LOGIN [' + @user_name + '] WITH DEFAULT_SCHEMA=[dbo];'

                EXEC sp_executesql @command;

                IF @database_name NOT IN ('msdb')
                BEGIN

                    SET @command = 'USE [' + @database_name + ']; ALTER ROLE [DB_OWNER] ADD MEMBER [' + @user_name + '];' 

                    EXEC sp_executesql @command;
                
                END

            END

            SET @cont += 1

        END

        SET @command = '
            USE master;

            GRANT ALTER ANY EVENT SESSION TO [' +  @user_name + '] WITH GRANT OPTION;
            GRANT ADMINISTER BULK OPERATIONS TO [' +  @user_name + '] WITH GRANT OPTION;
            GRANT ALTER ANY SERVER AUDIT TO [' +  @user_name + '] WITH GRANT OPTION;
            GRANT ALTER ANY CONNECTION TO [' +  @user_name + '] WITH GRANT OPTION;
            GRANT ALTER LOGIN TO [' +  @user_name + '] WITH GRANT OPTION;
            GRANT ALTER ANY LINKED SERVER TO [' +  @user_name + '] WITH GRANT OPTION;
            GRANT ALTER ANY SERVER ROLE TO [' +  @user_name + '] WITH GRANT OPTION;
            GRANT ALTER SERVER STATE TO [' +  @user_name + '] WITH GRANT OPTION;
            GRANT ALTER TRACE TO [' +  @user_name + '] WITH GRANT OPTION;
            GRANT CREATE ANY DATABASE TO [' +  @user_name + '] WITH GRANT OPTION;
            GRANT VIEW ANY DEFINITION TO [' +  @user_name + '] WITH GRANT OPTION;
            GRANT VIEW ANY DATABASE TO [' +  @user_name + '] WITH GRANT OPTION;
            GRANT VIEW SERVER STATE TO [' +  @user_name + '] WITH GRANT OPTION;
        '

        EXEC sp_executesql @command;

        SET @command = '
            USE msdb; 
            EXEC sp_addrolemember [SQLAgentUserRole],[' + @user_name + ']; 
            GRANT ALTER ANY USER ON DATABASE::[msdb] TO [' + @user_name + '] WITH GRANT OPTION;
            GRANT ALTER ON ROLE::[SQLAgentOperatorRole] TO [' + @user_name + '];   
        '

        EXEC sp_executesql @command; 

    END
    ELSE IF @user_type = 'read'
    BEGIN

        WHILE @cont <= (SELECT MAX(database_id) FROM sys.databases)
        BEGIN

            SET @database_name = DB_NAME(@cont)

            IF @database_name IS NOT NULL AND @database_name NOT IN ('master','model','msdb','tempdb','Distribuition','rdsadmin','ReportServer','ReportServerTempDB')
            BEGIN

                SET @command = '
                    USE [' + @database_name + ']; 
                    CREATE USER [' + @user_name + '] FOR LOGIN [' + @user_name + '] WITH DEFAULT_SCHEMA=[dbo]; 
                    ALTER ROLE [db_datareader] ADD MEMBER [' + @user_name + '];
                '

                EXEC sp_executesql @command;

            END

            SET @cont += 1

        END

    END

END

A procedure a seguir remove o usuário após o tempo especificado no Vault:

CREATE PROCEDURE sp_drop_user (
    @user_name VARCHAR(100)
)
AS
BEGIN

    DECLARE 
        @command NVARCHAR(MAX)
        ,@database_name VARCHAR(50)
        ,@cont INT  = 1

    -- Encerra todas as conexoes do usuario
    IF EXISTS(SELECT 1 FROM sys.dm_exec_sessions WHERE login_name = @user_name)
    BEGIN

        SET @command = (SELECT TOP 1 N'KILL ' + CONVERT(NVARCHAR(11), session_id) + N';' FROM sys.dm_exec_sessions WHERE login_name = @user_name);

        EXEC sp_executesql @command;

    END

    -- Remove o usuario de todos os bancos de dados
    WHILE @cont <= (SELECT MAX(database_id) FROM sys.databases)
    BEGIN

        SET @database_name = DB_NAME(@cont)

        IF @database_name IS NOT NULL AND @database_name NOT IN ('master','model','msdb','tempdb','Distribuition','rdsadmin','ReportServer','ReportServerTempDB')
        BEGIN

            SET @command = '
                USE [' + @database_name + ']; 
                CREATE USER [' + @user_name + '] FOR LOGIN [' + @user_name + '] WITH DEFAULT_SCHEMA=[dbo]; 
                ALTER ROLE [db_datareader] ADD MEMBER [' + @user_name + '];
            '

            EXEC sp_executesql @command;

        END

        SET @cont += 1

    END


    SET @command = 'USE [master]; DROP LOGIN [' + @user_name + '];'

    EXEC sp_executesql @command;

END

É isso gente, em breve faço um post fazendo essa implementação no Hashicorp Vault.

Até a próxima!

O papel do DBRE – Introdução

Fala galera!

Nesta série iremos discutir sobre o que um Database Reliability Engineer faz, quais as diferenças dessa função para o DBA tradicional e o papel que ele desempenha dentro de times de engenharia de confiabilidade ou SRE.

Muito do que será discutido aqui tem haver com minha experiencia de mercado e as práticas discutidas nos livros SRE do Google e DBRE, deixarei as referencias no final de cada post.

Práticas SRE

O livro Database Reliability Engineer dos autores Laine Campbell e Charity Majors descreve já no capitulo introdutório certos principios que todo DBRE deveria práticar, esses são:

  • Proteção de Dados
  • Padrões para Ganho de Escala
  • Eliminação de Tarefas Repetitivas (Toil)
  • Tratar os servidores de bancos de dados mais como gado e menos como pet
  • Aproximação entre Software e Operações (DevOps)
  • Operação como Core dentro dos times de engenharia
  • Declaração de Prioridades
  • Seguro e Funcionando em primeiro lugar, depois vem a Escalabilidade
  • Invista no empoderamento dos times e não em Guard Rails
  • Observabilidade e Estrumentação
  • Auto remediação (Self-Healing ou Self-Actualization como esta no livro)

Vou tentar ser objetivo em cada tópico, resumindo em poucas palavras.

Proteção de Dados

Uma das primeiras coisas que todo DBA em inicio de carreira aprende é como efetuar Backup e Restore de um banco de dados, logo, uma das primeiras coisas que aprendemos é que todo bom ambiente precisa ter uma rotina de backup implementada e ajustada às necessidades de negócio, com RTO e RPO bem definidos. Raro de ver, mas quando vemos um ambiente que efetua Restores constantes é coisa linda de ver.

Outras questões que tocam em proteção são um bom processo de concessão de acessos que de preferencia não permite a criação de usuários nominais no banco de dados, ferramentas que apoiam na concessão de acessos, criando usuários temporários no banco de dados apenas quando necessário. Processos de auditoria implementados são importantes aqui para auxiliar em momentos de troubleshooting junto da área de Sec.

Processo de mudança, controle de configuração e um CMDB bem atualizado e detalhado podem evitar dores de cabeça.

Padrões para Ganho de Escala

No mundo OnPremise automatizar a criação e gestão de infraestrutura pode ser bem complexo dado a característica diversa de hardwares, softwares e afins. Já no mundo Cloud isso não acontece pois as plataformas abstraem a camada de hardware e software e te entregam uma interface facilitada para criação de infra.

Dado este cenário de Cloud, ter padrões pode te ajudar muito no dia a dia, como padrões de nomenclatura, tags, configurações, capacity, ambientes e afins. Quando eu vejo um ambiente bem padronizado fica fácil de identificar os ambientes e até mesmo construir automações e infraestruturas escaláveis dado a facilidade com que identificamos nossa infraestrutura e a entregamos para a camada de sistemas.

Eliminação de Tarefas Repetitivas (Toil)

Se você trabalha em ambientes pequenos, talvez não veja necessidade de automatizar tarefas maçantes, já para quem tem que lidar com dezenas, centenas e até milhares de instancias de bancos de dados, ainda mais em um ambiente que possui escalabilidade horizontal de instancias terá problemas graves se não construir automações.

Essas automações começam ao agendar tarefas administrativas como Reindex e Update Statics\Analyze, passando por extração de dados do ambiente e até a escalabilidade de replicas de leitura para atender a alta demanda das aplicações em determinados momentos do dia.

Creio que todo DBA aprende intrinsecamente a automatizar suas tarefas, dado que certos procedimentos acabam impactando a performance sistêmica das aplicações e precisam ser feitas fora do horário comercial, logo, para não ter que ficar gastando tempo de folga executando rotinas na mão, automatizar este tipo de trabalho é primordial.

Pet vs Catle

Quem nunca quis colocar ou até colocou um nome de Transformers, Vingadores ou Pokemons em seus servidores? Pois é, eu vejo isso até hoje!

Após o nascimento das Clouds e o avanço da virtualização, criar e apagar infraestruturas ficou cada vez mais comum, logo, ter padrões como falamos num tópico anterior é essencial bem como infraestrutura como código, versionada e armazenada em um repositório Git, que é provisionada por uma pipeline tornou-se cada vez mais comum, principalmente para infras distribuídas e que necessitam escalar.

Cada vez mais vemos opções de bancos de dados distribuídos nascendo, seja dentro dos provedores de Cloud ou fora e que oferecem escalabilidade horizontal de verdade, seja sobre Bare Metal, IaaS ou Kubernetes. Dado este cenário, utilizar o conceito de tratar maquinas como gado, que é algo que já acontece com maquinas de aplicação, também poderá ser utilizado para ambientes de bancos de dados.

Vale lembrar que essas novas tecnologias de bancos de dados distribuídos funcionam com replicação de dados em larga escala e com baixa latência, aonde podemos ter mais de um node de um cluster recebendo tanto leitura como escrita e o mesmo resolve conflitos internamente com sucesso. Logo, a aplicação deste conceito para ambientes de bancos de dados será cada vez mais comum onde existir ambientes com apetite por alta escalabilidade com alta disponibilidade.

Aproximação entre Software e Operações (DevOps)

Quanto mais o tempo passa, mais vemos o profissional de T.I. mudando, principalmente o profissional de operações, pois, este, que sempre esteve mais ligado ao hardware, servidores, datacenters e afins viu seu mundo virar código e ser abstraído pelas Clouds. Isso quer dizer que o profissional de operações\infra irá morrer? Claro que não, mas uma coisa é fato: se este profissional não aprender a codificar e se acostumar a transformar sua infraestrutura em código provavelmente irá perder boas oportunidades em boas empresas.

Esse contexto também vale para os DBA’s tradicionais, mas acredito que para este mundo as mudanças não afetarão tanto pois o DBA já tende a estar proximo do desenvolvedor, otimizando sistemas a partir da camada do banco de dados. Todo sistema que armazena dados precisa executar queries, logo, um bom DBA tende a lidar de forma sistêmica e pelo menos com a linguagem SQL, que é o seu core.

O que irá diferenciar os DBA’s tradicionais dos DBRE’s serão as práticas do mundo DevOps, como: Infra As Code, gestão de configuração, observability na camada do banco de dados, coleta de métricas e traceability para rastreabilidade, centralização de logs (Principalmente para ambientes distribuídos), automação além do SQL com linguagens como Python e GO, lidar com ambientes gerencias em Cloud Publica, implementação de Auto Healing, pipelines de infraestrutura e migration, testes, entre outras práticas que vem do mundo de desenvolvimento e DevOps.

Verdade seja dita, mesmo antes do termo DevOps surgir, DBA’s já construíam automações, seja por shell scripts ou PowerShell e até mesmo SQL, principalmente aqueles que precisavam lidar com ambientes médios a grandes. Ter um DBA dentro de uma empresa muitas vezes é visto como luxo, pois são recursos considerados caros e apenas são considerados necessários quando problemas de escala já estão acontecendo, com os DBRE’s não será diferente, logo, saber lidar tanto com o mundo tradicional de operações ao qual o DBA já existia unindo às práticas novas de automação levará a atingir outro patamar na carreira.

Operação como Core dentro dos times de engenharia

No item anterior falei muito sobre o perfil Ops do DBA e como o profissional de operações precisa lidar com o mundo novo e saber codificar, pois bem, o oposto também é verdadeiro.

Acho legal certos termos como: “You Build It, You Run It”. Ou literalmente, você desenvolve, você sustenta. Na teoria parece algo que faz muito sentido, unir desenvolvimento e operações com o intuito de entregar seus produtos de software com a melhor experiencia possível para seus clientes.

Na prática ja vi times de engenharia serem formados com este intuito, os times que deram certo viraram referencia de entrega de software, muito mais robustos, com menos problemas indo para produção, com muito mais agilidade. Mas a realidade é que a maioria dos demais times tiveram dificuldade, por que? Simples, culturalmente o desenvolvedor tende a não se preocupar muito com a infraestrutura ou operações por que entende que há áreas\pessoas especializadas para tal, logo, na maioria dos casos, engenheiros de software terão menos afinidade e menos interesse em desenvolver hard skills de operações.

Quanto mais eu convivo dentro de áreas de SRE mais eu vejo a necessidade de esta função ser muito mais ligada a engenharia de software do que operações em si, porém, se já esta difícil conseguir bons desenvolvedores para entregar apenas software, tão mais difícil será encontrar no mercado engenheiros de confiabilidade com bases fortes nas duas pontas.

Acredito que isso apenas mudará com o investimento pesado das empresas em: primeiro – desenvolver sua própria cultura SRE e segundo – formando seus próprios engenheiros de confiabilidade. Mas aonde o DBA entra nisso tudo? Para um DBA se tornar um DBRE ele terá que ir além da camada de banco de dados, conhecendo mais sobre arquitetura de software, cloud computing, escalabilidade, disponibilidade e práticas DevOps, quanto mais ele estiver próximo de como as aplicações funcionam, mais ele entenderá qual a melhor ferramenta para um determinado cenário serviço ou software.

Declaração de Prioridades

Aqui não irei me prolongar pois é algo obvio: se você entrega ambientes de bancos de dados para sistemas e não se preocupa na entrada com backup, lifecycle dos dados (expurgo), gestão de configuração, monitoração e segurança, logo, seu ambiente esta em risco e consequentemente errado.

Existem certas prioridades no funcionamento de bons ambientes de bancos de dados que não podem ficar para depois, caso isso aconteça provavelmente você terá um problema grande por negligenciar estas atividades, logo, nenhuma prioridade deverá ser maior do que as descritas acima.

Seguro e Funcionando em primeiro lugar, depois vem a Escalabilidade

Distribuir dados? Particionamento de tabelas? Escalabilidade Horizontal? Sharding? Todas essas técnicas podem melhorar muito a disponibilidade e performance das aplicações, mas de adianta ter todas essas coisas se não tivermos um procedimento de backup bem montado com múltiplas copias dos dados, se não fazemos testes de restore, replicar os dados por múltiplas localidades e ter um failover seguro podem diminuir muito a chances de corrupção de dados e aumentar a garantia e consistência destes.

Pensar em escalabilidade no dia 0 pode ser um erro pois muitas vezes não se tem a real visibilidade do quão rápido um sistema ou serviço podem crescer no tempo, por conta disso pense simples: garanta backup, replicação de dados e um ambiente alto disponível.

Invista no empoderamento dos times e não em Guard Rails

A cultura DevOps traz à luz a colaboração entre desenvolvedores e operadores, simples assim, logo, o DBRE deve investir em conhecimento das equipes de desenvolvimento e infraestrutura para que em conjunto possam construir sistemas melhores, com as melhores práticas.

A colaboração leva a perfeição (ou o mais perto dela), trabalhando de forma colaborativa cada vez menos teremos a necessidade de inserir mecanismos de controle como guard-rails para impedir que façam coisas erradas nos ambientes.

Utilizar práticas modernas como a utilização de Infra-as-code auxilia neste processo pois coloca a disponibilização de ambientes de bancos de dados mais próxima do processo de desenvolvimento de software pois torna a infraestrutura em código e possibilita testes e outras boas práticas de desenvolvimento de software.

Observabilidade e Estrumentação

Todo ambiente sistêmico precisa ser monitorado, isso é um fato, mas como podemos ir além da monitoração? Simples, com observability e um bom APM (Application Performance Managament).

Observability te da a capacidade de enxergar uma infinidade de pontos de seus sistemas baseado em diversas métricas, o mais importante aqui é conseguir identificar e criar alertas que te avisem sobre problemas que estão acontecendo e também o comportamento que estão tomando, com isso você ganha a um poder de resposta e predição de problemas, atuando antes que uma degradação ou paralização aconteça, impactando assim a disponibilidade de seu ambiente.

Instrumentalizar seu sistema o auxilia a ter tempestividade para encontrar o RCA (Root Cause Analysis) de um determinado problema que esteja acontecendo. Falamos em tempestividade pois a visibilidade tanto da integração entre os sistemas como da comunicação interna entre os componentes da infraestrutura fica muito mais clara e gráfica, diminuindo muito o tempo de analise e identificação de um problema e aumenta a assertividade nas ações de resolução deste.

A instrumentalização também traz a capacidade de inserir feature flags e outros mecanismos que dão a capacidade de ligar e desligar funcionalidades de seu sistema como a utilização de replicas de leitura de um banco de dados, por exemplo.

Ter uma KB (Knowledge Base) bem construída com procedimentos minimamente bem descritos pode ajudar os times a atuar sem a necessidade de um DBA, como times de operação por exemplo e desta forma o DBRE consegue continuar atuando em melhorias e automações que melhorem ainda mais a disponibilidade dos ambientes de bancos de dados.

Auto remediação

A capacidade de se auto regenerar de um problema é uma capacidade que poucos tem, para sistemas e infraestrutura não é diferente. Construir sistemas que conseguem contornar adversidades de forma automática é uma arte que pouco se vê ainda em tempos atuais e que as grandes de tecnologia procuram incessantemente.

Investir em automação de verdade, indo além do script, trabalhando em conjunto com os sistemas citados anteriormente como APM’s, Observabilidade, CMDB e outros podemos desenvolver mecanismos que aprendem com as mudanças de comportamento constantes que acontecem durante a utilização dos softwares para tomadas de decisão cada vez mais precisas, transformando ambientes de bancos de dados cada vez mais resilientes e robustos.

Chegar até aqui envolve uma grande maturidade e conhecimento do sistema administrado, da stack que esta executando as aplicações, desta forma, o desenvolvimento de uma auto remediação deve ser considerado apenas após a estabilização e experiencia adquiridas no tempo.

Conclusão

Bom gente, chega ao fim aqui este resumo do primeiro capitulo do livro sobre os pontos que estão descritos direta ou indiretamente neste, meu intuito aqui é tentar trazer um pouco do meu dia a dia atuando nesta função que não é muito diferente de um DBA tradicional mas que vejo muitos DBAs não conhecendo muitas dessas práticas descritas acima.

Se você já atua assim mas não se considera um DBRE, não tem problema, é mais uma buzz word neste mundo infinito de jargões tecnológicos. Se ficaram com alguma dúvida ou se gostariam de discutir algum ponto acima, fiquem a vontade de colocar um comentário ou enviar um e-mail que terei o prazer imenso de responder.

Este ano serei muito mais frequente aqui no blog, então fique ligado(a)!

Vlw galera! Até o próximo post!

Comece pela base

Fala galera! Mais de 1 ano desde que criei este blog e não parei para escrever aqui, bora começar então, espero ser bem ativo por aqui trazendo muito conteúdo técnico e de carreira para vocês!

Conforme descrevi em meu primeiro post aqui no blog, comecei cedo na área de tecnologia, por volta de 2005 quando tinha apenas 15 anos. Hoje, com mais do dobro disso, quero passar para vocês um pouco do que foi essencial para meu inicio lá atrás e me acompanha até hoje na profissão: a base!

O que eu tenho mais visto nesses últimos tempos tem sido empresas e\ou profissionais da área vendendo cursos com discurso: faça este curso e esteja preparado para o mercado de trabalho! (Aqueles cursos de 6 meses que prometem salários de 5 mil reais pra cima)

Serei um pouco repetitivo mas acredito que será importante para o contexto. Quando fiz meu primeiro curso na área que foi Montagem e Manutenção de Microcomputadores no SENAI eu me apaixonei já no inicio, eu sou uma pessoa muito visual e tátil, gosto de pegar nas coisas (Por isso gosto de livros em papel, por exemplo) e por conta disso eu fiquei deslumbrado em abrir um gabinete de computador, tocar em uma placa mãe, memória, disco rígido, etc. Ali eu não só aprendi a montar e desmontar um computador (Coisa que faço até hoje, pra mim e para minha familia e amigos) mas também a entender como um computador funciona, que não existia só Windows como Sistema Operacional, o que era Linux, softwares Open Source, redes de computadores e muitas outras matérias fundamentais.

Depois disso minha curiosidade aflorou, comecei a montar e desmontar meu próprio computador, formatar, usar outros sistemas operacionais e a pesquisar coisas relacionadas na internet, experimentar coisas novas. Com 17 anos comecei a fazer Técnico em Informática em uma escola próxima de casa e la aprendi e reforcei muitas outras matérias base como Sistemas Operacionais, Redes de Computadores, Lógica de Programação, Matemática e Estatística, Inglês Básico, Elétrica, etc. Pouco depois comecei a fazer cursos profissionalizantes fornecidos pelo CIEE e o principal foi o preparatório para a certificação CCNA da CISCO. Neste curso aprendi toda a base de Redes que mais uma vez, carrego até hoje em minha carreira principalmente depois do surgimento das Clouds Publicas.

Praticamente junto deste curso da Cisco iniciei na graduação de Engenharia da Computação e logo depois comecei a estagiar na área e sabe quais eram minhas principais funções?

  • Montagem e Manutenção de Notebooks, Computadores e Servidores;
  • Instalação e Configuração de Sistemas Operacionais Windows XP, Vista, Server NT, 2000, 2003 e 2008;
  • Montagem e Configuração de Redes;
  • Instalação e Configuração Sistemas Java e .Net\C#;
  • Instalação e Configuração de Bancos de Dados SQL Server;
  • Desenvolvimento de scripts de atualização e configuração.

Vejam, tudo que estudei e me preparei desde lá de trás eu utilizei em meu primeiro emprego na área e pasmem, eu uso até hoje! Dei todo esse contexto para vocês para elencar algumas matérias que acredito ser essenciais para todo profissional de Tecnologia da Informação, sendo você de Infraestrutura\Operação, Desenvolvedor de Software, Administrador de Banco de Dados (Assim como eu) e outras áreas:

Redes de Computadores

Não importa de qual área você seja, sério, não importa, você PRECISA saber o que é um IP, um protocolo TCP\UDP, Modelo OSI, calcular uma sub-rede, domínios de broadcast e rede, tabela de roteamento. Essas são algumas coisas que toda pessoa de tecnologia precisaria aprender, por que? Por que tudo trafega pela rede! Quase toda aplicação existente atualmente trabalha na internet ou no mínimo em rede, logo, você precisa saber qual o tamanho do pacote que sua aplicação trafega pois banda de internet ainda é limitada, talvez com o 5G veremos menos problemas de aplicativos de celular quebrando por não ter banda o suficiente para trafegar seus pacotes, porém, ainda sim será importante este tipo de noção pois isso impactará diretamente na performance da sua aplicação\aplicativo.

Se você não for um Analista de Redes, que precisa saber de cabo a rabo como uma rede funciona, os conceitos básicos de rede iram te auxiliar muito a entender como toda sua infraestrutura esta funcionando, principalmente na Cloud, sério, a base de qualquer Cloud Computing é redes, você precisa começar pela rede. “A Will, más eu crio uma conta no Azure, AWS ou GCP e ela já me da toda rede pronta, eu já saio criando meus recursos sem precisar me preocupar com isso”. Verdade, de fato as principais Clouds te dão uma VPC (Virtual Private Cloud) já configurada, saindo para internet, já configurada. Para um ambiente de testes e laboratório, ou até mesmo para começar um pequeno negócio essa infra já criada vai te ajudar, mas não irá resolver se o negócio escalar muito, rapidamente você terá problemas como esgotamento de IP’s e conflitos de sub-rede por exemplo.

Tem uma máxima que vocês vão me escutar falar bastante aqui no Blog: Se esta fácil demais, esta errado! Mesmo que já esteja pronto é importante saber como funciona. Por isso estude Redes de Computadores, a base deste conhecimento vai te ajudar por toda sua vida em T.I.

Indico aqui o conteúdo que me ajudou lá atrás: Cisco e seu material para a certificação CCNA. Tem um livro muito bom sobre essa certificação em português escrito pelo Marco Aurélio Filippetti, CCNA 6.0 – Guia completo de estudo.

Lógica de Programação e Estrutura de Dados

Quando entrei na faculdade, ja no primeiro semestre eu peguei um exame, adivinhem em qual matéria? Sim, isso mesmo, Lógica de Programação. Grande parte da minha sala pegou, inclusive. Naquela época o termo DevOps estava nascendo, a AWS ainda estava começando com pouquíssimos serviços, o SysAdmin reinava, o Dev só codava e a vida seguia.

Por que citei toda essa história acima? Lembra que eu falei que sou uma pessoa de infra desde o principio? Então, eu nunca precisei tocar num código na vida, no curso técnico que eu havia feito não ensinaram lógica de programação, já saíram ensinando Visual Basic, arrastando caixinha, programando ações na tela sem explicar muito como tudo de fato funcionava e eu pouco me interessei na época também, falha minha, por que anos depois eu não teria pego exame em lógica, rsrs.

Mas hoje, mesmo ainda me considerando muito mais Ops do que Dev a lógica de programação me ajuda diariamente, seja para dar manutenção em uma Procedures ou Functions no banco de dados, seja para desenvolver scripts e Infra como Código ou até mesmo para ajudar os Devs a resolver algum problema na camada da aplicação a lógica de programação me acompanha. Esse livro aqui embaixo foi o que me salvou na aula de Lógica de Programação, depois de ler e praticar muito com ele eu e alguns de meus amigos conseguimos passar bonito:

Mas e a Estrutura de Dados que citei junto? Quando tive essa matéria na faculdade fiquei maravilhado! Por que é com ela que você aprende como alocar apenas os recursos que realmente precisam na memória, a desenvolver algoritmos de fila e pilhas e muitos outros conceitos avançados que todo o Dev precisaria saber. Naquela época os recursos de hardware eram limitados, não era comum ter mais de 4 ou 8GB de memória no servidor, as linguagens de programação mais conhecidas de hoje como Java e C# por exemplo, ainda tinham que ter suas configs otimizadas para não esbarrar na limitação de recursos para rodar, por conta disso um sistema bem construído em termos de utilização de recursos raramente dava problema de estouro de memória no servidor (Nossa! Quantas vezes me peguei reconfigurando JVM por causa de config errada de Tomcat ou sistemas estourando stack overflow).

Dois livros que aconselho a muitos lerem, mesmo quem já é mais experiente é o Algoritmos Teoria e Prática de Thomas H. Cormen e o A Common-Sense Guide to Data Structures and Algorithms, Second Edition: Level Up Your Core Programming Skills De Jay Wengrow.

Sistemas Operacionais

Neste tópico não me estenderei muito, mas quero citar Sistemas Operacionais aqui para que vocês possam entender que: Linux domina. “Mas Will, eu uso Windão\Mac e eles me atendem super bem, preciso migrar para o Linux?”, a resposta é simple: Não! O que eu quero passar aqui é que distribuições Linux dominam a camada de servidores hoje, ou seja, você esta ai construindo um sistema Java, Python, Javascript, Go, entre outros, o melhor ecosistema para executar suas aplicações é o Linux, seja por que ele é mais modular, aberto e aceita muitas alterações até a camada do seu Kernel.

Hoje falamos muito sobre containers e olha só, containers (na sua melhor forma) só rodam sobre o kernel Linux. Em algum outro post quero entrar mais a dentro em containers com foco em bancos de dados, por isso falaremos mais profundamente sobre containers depois blz?

Mas independente do S.O. com o qual você irá trabalhar busque entender mais profundamente como ele funciona, principalmente aquele para o qual você esta desenvolvendo sua aplicação, seja ele Windows, Linux, IOS, Android, Unix. Isso irá te ajudar em momentos de problema, quanto mais você mergulhar no sistema operacional melhor irá entender como as coisas funcionam.

Já para desenvolver, ai pode utilizar qualquer sistema operacional, qualquer um mesmo, todos tem seus prós e contras, escolha o que melhor te atende.

O canal do mestre Akita on Rails tem muitos vídeos fantasticos sobre os temas que comentei acima e muito mais, inclusive ele tem videos explicando as diferenças entre os principais S.Os de mercado hoje. Nessa lista ele reune os videos sobre Sistemas Operacionais:

Bancos de Dados

Por fim, mas não menos importante eu trago o tema ao qual venho me especializando e trabalhando nos últimos anos que é Banco de Dados.

Qualquer sistema que precisa armazenar dados de forma eficiente dependerá de um banco de dados, logo, saber linguagem SQL (Structured Query Language) é essencial.

O que mais vejo hoje são sistemas sendo desenvolvidos sobre ORM (Object-Reletional Mapping) para lidar com a camada de banco de dados sem precisar lidar com a linguagem SQL, ou seja, você esta lá mandando bronca no seu Javão, C Sharpzão, Pythtão, Javascriptzão e utiliza algumas bibliotecas para te ajudar a não lidar com banco de dados. Vou te contar duas máximas da vida de T.I.: “Se esta fácil, esta errado.” e ”Uma hora a conta chega.”.

“Nossa Will, mas meu código funciona, eu rodo em desenvolvimento e homologação e executa tudo muito rápido mas quando vai para produção não roda , o sistema cai, tudo fica lento”. Poise, tudo no começo é uma maravilha, por que? Por que você quase não tem dados, logo, tudo vai executar rápido, então se você não cria indices nas tabelas no dia 1, quando seu código vai para o ar, se você não se preocupa em saber como o seu ORM esta formando as queries, se você não se preocupa com a estrutura da suas tabelas, la na frente, daqui 3 ou 6 meses ou até mesmo 1 ou 2 anos, quando seu sistema do dia pra noite ficar lento e você ver que é o banco de dados, não culpe a tecnologia falando: ”Nossa, por que fui escolher um banco de dados relacional, deveria ter ido para o MongoDB ou Cassandra, lá eu não ia ter problemas” vai por mim, eu já ouvi muito isso, você não imagina como sua vida estaria hoje utilizando tecnologias NoSQL de forma errada, muito antes deste momento você já estaria chorando sentado num canto escuro.

Este é um tema que quero trazer para vocês com mais detalhes lá na frente pois toca em conceitos de escalabilidade e elasticidade de aplicações que são conceitos mais avançados e necessários quando já se sabe a volumetria (Número de usuários simultâneos, volume de acessos, etc.) ao qual seu sistema será submetido ou quando já esta se tendo problemas dessa natureza em seu ambiente.

O que eu quero passar aqui para vocês é que a camada de banco de dados precisa ser respeitada pois cedo ou tarde você terá problemas, seja você um Dev ou Ops e muitas vezes não terá um DBA por perto para ajudar, então ter os conceitos de banco de dados bem solidificados, saber qual é a melhor tecnologia para um determinado cenário sistemico, conhecer bem a linguagem SQL e conhecer bem uma tecnologia de banco de dados relacional é essencial para que você evite dores de cabeça futuras ou para te ajudar no troubleshooting da sua aplicação.

Trago aqui dois livros para quem esta começando e quer saber mais sobre a base deste tema que é Sistemas de Bancos de Dados e NoSQL Essencial: um Guia Conciso Para o Mundo Emergente da Persistência Poliglota.

Conclusão

Este foi um compilado de temas os quais eu me baseio desde o inicio da minha carreira e acredito fortemente que, seja você de Dev ou Ops, saber esses tópicos com certa profundidade irá te ajudar muito no seu dia a dia na área de tecnologia, se você mira se tornar um profissional mais completo e se destacar, vai por mim, aprenda e tenham essa base sólida, revisando constantemente esses tópicos.

Posso ter deixado algo passar, num futuro trago uma revisão deste post por que esse mundo é muito dinâmico, mas posso te dizer que desde o inicio da minha carreira à 15 anos atrás eu trago muito desses temas comigo até hoje e vejo que muitos não possuem essa base e muitas vezes acabam sofrendo para resolver determinados problemas.

No mais, qualquer dúvida, crítica (construtiva) e sugestões são extremamente bem vindas, este é o lugar aonde quero trazer minha experiencia, ensinar e aprender com todos vocês.

Desde já, muito obrigado! Tamo junto!

whoami

Apaixonado por tecnologia desde os 8 anos de idade quando teve contato com um Compaq Presario em 1998. Iniciou em TI aos 15 anos em um curso de Montagem e Manutenção de Microcomputadores pelo Senai onde definiu ali que cursaria Engenharia da Computação na Faculdade, 3 anos depois foi o que aconteceu. Aos 16 começou a dar aulas de Inclusão Digital para jovens de 16 a 20 anos e para idosos utilizando tecnologia Open Source com Kurumin 7 e aos 18 começou a estagiar em empresas com atividades focadas em Infraestrutura de Redes, Sistemas Operacionais e Servidores.

A 10 anos venho focando em tecnologias de bancos de dados de forma agnóstica já tendo administrado ambientes de pequeno e médio porte com MySQL, PostgreSQL, SQL Server e MongoDB. Atualmente trabalho como Administrador de Banco de Dados no maior banco da América Latina administrando ambientes de grande porte e altíssima criticidade, com foco em operações CloudOps e perfil SRE venho trabalhando com equipes de sustentação de banco de dados e Comunidade Cloud na fundação de ambientes de bancos de dados em Cloud Pública utilizando AWS.

Sou apaixonado pelo empreendedorismo, por conta disso ajudei a fundar duas empresas as quais sou ativo até hoje: Flapper e Data Tuning. Na Flapper fui incumbido de criar e gerenciar toda infraestrutura na empresa que desde sua fundação utiliza serviço da AWS, onde rodamos todos nossos produtos e serviços. Já na Data Tuning, como consultor, atuo como Cloud Solutions Architect em AWS e Azure com foco em tecnologias de bancos de dados sobre IaaS ou PaaS como SQL Server (Azure SQL, Hyperscale, Managed Instances, RDS, etc), PostgreSQL (Azure Database for, Hyperscale, RDS, Aurora, etc) e MySQL (Azure Database for, RDS, Aurora, etc).

Queria dedicar este blog a esse cara da foto, Marcel Inowe. Se hoje eu contribuo para comunidade, principalmente por meio de palestras é por conta deste cara. Com ele aprendo muito, seja performance em SQL Server, seja construindo uma palestra ou fazendo um bom churrasco, é o meu mestre e um amigo querido. Mestre, tamo junto sempre!

Este sou eu gente, neste blog você verá muito conteúdo sobre infraestrutura que é minha paixão, minha jornada aprendendo a codificar e distribuindo conteudo sobre bancos de dados que é minha especialidade bem como Cloud Coputing.

Fico aberto a críticas construtivas e melhorias sempre! Então se você achar qualquer erro ou algo no qual não concorda me mostre e vamos concertar juntos. Desde já agradeço a todos que acompanham este blog.

“Stay hungry, stay foolish”. Whole Earth Catalog