As operações, como disciplina, são difíceis. Não só existe a questão geralmente não resolvida de como gerir bem os sistemas, mas também as melhores práticas que funcionam são altamente dependentes do contexto e estão longe de serem amplamente adotadas. Há também a questão, em grande parte não respondida, de como gerir bem as equipes de operações. Pensa-se que a análise detalhada destes tópicos tem geralmente origem na Investigação Operacional dedicada à melhoria dos processos e dos resultados nas forças armadas Aliadas durante a Segunda Guerra Mundial, mas na realidade, temos pensado em como operar melhor as coisas por milênios.
No entanto, apesar de todo este esforço e pensamento, as operações de produção confiáveis permanecem elusivas – especialmente nos domínios da tecnologia da informação e da operacionalidade do software. O mundo empresarial, por exemplo, trata frequentemente as operações como um centro de custos, o que torna as melhorias significativas nos resultados difíceis, se não mesmo impossíveis. A tremenda miopia desta abordagem ainda não é amplamente compreendida, mas a insatisfação com ela deu origem a uma revolução na forma de organizar o que fazemos em TI.
Essa revolução decorreu da tentativa de resolver um conjunto comum de problemas. As mais recentes soluções para estes problemas são chamadas por dois nomes distintos – DevOps e Engenharia de Confiabilidade do Site (SRE). Embora falemos deles individualmente como se fossem reações totalmente separadas à mentalidade empresarial que acabamos de descrever, esperamos persuadi-lo de que, de fato, são muito mais parecidos, e os profissionais de cada um têm muito mais em comum, do que se poderia supor.
Mas primeiro, alguns antecedentes sobre os princípios fundamentais de cada um.
Antecedentes sobre DevOps
DevOps é um conjunto disperso de práticas, diretrizes, e cultura projetado para quebrar silos no desenvolvimento de TI, operações, redes e segurança. Articulado por John Willis, Damon Edwards, e Jez Humble, CA(L)MS – que significa Cultura, Automação, Lean (como na gestão Lean; ver também entrega contínua), Medição, e Partilha – é um acrônimo útil para lembrar os pontos-chave da filosofia DevOps. O compartilhamento e a colaboração estão na vanguarda desse movimento. Em uma abordagem DevOps, você melhora algo (geralmente automatizando-o), mede os resultados e compartilha esses resultados com colegas para que toda a organização possa melhorar. Todos os princípios do CALMS são facilitados por uma cultura de apoio.
DevOps, Agile, e uma variedade de outras técnicas de reengenharia empresarial e de software são todos exemplos de uma visão geral do mundo sobre a melhor forma de fazer negócios no mundo moderno. Nenhum dos elementos da filosofia DevOps é facilmente separável uns dos outros, e isto é essencialmente por padrão. Existem, no entanto, algumas ideias-chave que podem ser discutidas em relativo isolamento.
Não mais Silos
A primeira ideia chave é não mais silos. Esta é uma reação a algumas ideias:
O arranjo historicamente popular, mas agora cada vez mais antiquado de operações e equipes de desenvolvimento separadas
O fato de que a siloização extrema do conhecimento, os incentivos à otimização puramente local e a falta de colaboração terem sido, em muitos casos, ativamente prejudiciais para os negócios
Acidentes são normais
A segunda ideia-chave é que os acidentes não resultam apenas das ações isoladas de um indivíduo, mas resultam da falta de salvaguardas para quando as coisas inevitavelmente dão errado. Por exemplo, uma interface ruim inadvertidamente incentiva a ação errada sob pressão; um mau funcionamento do sistema torna a falha inevitável se as circunstâncias erradas (não articuladas) ocorrerem; um monitoramento falho torna impossível saber se algo está errado, não importa o que está errado. Algumas empresas mais tradicionais possuem o instinto cultural para erradicar o autor do erro e puni-los. Mas fazer isso tem suas próprias consequências: mais obviamente, cria incentivos para confundir questões, esconder a verdade, e culpar outros, tudo isto são, em última análise, distrações não lucrativas. Por conseguinte, é mais rentável concentrar-se em acelerar a recuperação do que em prevenir acidentes.
A mudança deve ser gradual
A terceira ideia-chave é que a mudança é melhor quando é pequena e frequente. Em ambientes onde os comitês de mudança se reúnem mensalmente para discutir planos minuciosamente documentados para fazer alterações à configuração do mainframe, esta é uma ideia radical. Contudo, esta não é uma ideia nova. A noção de que todas as mudanças devem ser consideradas por seres humanos experientes e agrupadas para consideração eficiente acaba por ser mais ou menos o oposto das melhores práticas. A mudança é arriscada, é verdade, mas a resposta correta é dividir as suas mudanças em subcomponentes menores sempre que possível. Em seguida, cria-se um pipeline estável de alterações de baixo risco a partir da saída regular de alterações de produto, design e infraestrutura. Essa estratégia, juntamente com o teste automático de alterações menores e a reversão confiável de alterações ruins, leva a abordagens de gerenciamento de integração (CI) e entrega ou implantação contínua (CD).
Ferramentas e Cultura Estão Interrelacionadas
As ferramentas são um componente importante do DevOps, particularmente dada a ênfase na gestão correta da mudança, a gestão da mudança depende de ferramentas altamente específicas. No entanto, em geral, os defensores do DevOps enfatizam fortemente a cultura organizacional – em vez de ferramentas – como a chave do sucesso na adoção de uma nova forma de trabalhar. Uma boa cultura pode trabalhar em torno de ferramentas quebradas, mas o oposto raramente se aplica. Como diz o ditado, a cultura come a estratégia no café da manhã. Tal como as operações, a própria mudança é difícil.
A Medição é Crucial
Finalmente, a medição é particularmente crucial no contexto empresarial global de, por exemplo, quebra de silos e resolução de incidentes. Em cada um desses ambientes, você estabelece a realidade do que está acontecendo por meio de medição objetiva, verifica se está mudando a situação conforme o esperado, e cria uma base objetiva para conversas em que as diferentes funções concordam. (Isto aplica-se tanto em contextos empresariais como em outros contextos, tais como o de plantão).
Antecedentes de SRE
Engenharia de confiabilidade do site (SRE) é um termo (e função de trabalho associado) cunhado por Ben Treynor Sloss, um VP de engenharia no Google. Como podemos ver na seção anterior, DevOps é um amplo conjunto de princípios sobre a colaboração em todo o ciclo de vida entre operações e desenvolvimento de produtos. SRE é uma função de trabalho, um conjunto de práticas (descritas a seguir) que encontramos para funcionar, e algumas crenças que animam essas práticas. Se pensarmos no DevOps como uma filosofia e uma abordagem de trabalho, podemos argumentar que o SRE implementa parte da filosofia que o DevOps descreve, e está um pouco mais próximo de uma definição concreta de um trabalho ou função do que, digamos, “engenheiro DevOps “. Então, de certa forma, a classe SRE implementa a interface DevOps.
Ao contrário do movimento DevOps, que teve origem em colaborações entre líderes e profissionais de várias empresas, o SRE no Google herdou grande parte da sua cultura da empresa adjacente antes do termo SRE ter se tornado amplamente popular em toda a indústria. Dada essa trajetória, a disciplina como um todo atualmente não coloca em primeiro plano a mudança cultural por padrão tanto quanto o DevOps. (Isso não implica em nada sobre se a mudança cultural é necessária para fazer o SRE em uma organização arbitrária, é claro).
O SRE é definido pelos seguintes princípios concretos.
As operações são um problema de softwar
O princípio básico do SRE é que fazer bem as operações é um problema de software. Por conseguinte, o SRE deveria utilizar abordagens de engenharia de software para resolver esse problema. Isto abrange um amplo campo de visão, abrangendo tudo, desde processos e mudanças empresariais até problemas de software igualmente complicados, mas mais tradicionais, tais como reescrever uma pilha para eliminar pontos únicos de falha na lógica empresarial.
Gerenciar por Objetivos de Nível de Serviço (SLOs)
O SRE não tenta dar a tudo 100% de disponibilidade. Como discutido no nosso primeiro livro, Engenharia de confiabilidade do site, este é o alvo errado por uma série de razões. Em vez disso, a equipe de produto e a equipe SRE selecionam um alvo de disponibilidade adequado para o serviço e a sua base de usuários, e o serviço é gerenciado para esse SLO. Decidir sobre tal alvo requer uma forte colaboração por parte da empresa. Os SLOs têm também implicações culturais: como decisões de colaboração entre as partes interessadas, as violações do SLO trazem as equipes de volta à mesa de projeto, sem culpa.
Trabalho para Minimizar a Labuta
Para o SRE, qualquer tarefa operacional manual e estruturalmente obrigatória é abominável. (Isso não significa que não tenhamos tais operações: temos muitas delas. Simplesmente, não gostamos delas). Acreditamos que se uma máquina pode realizar uma operação desejada, então uma máquina deve frequentemente realizá-la. Isto é uma distinção (e um valor) que não se vê muitas vezes noutras organizações, onde a labuta é o trabalho, e é isso que se paga a uma pessoa para fazer. Para o SRE no contexto do Google, a labuta não é o trabalho – não pode ser. Qualquer tempo gasto em tarefas operacionais significa tempo não gasto em trabalho de projeto – e trabalho de projeto é como tornamos os nossos serviços mais confiáveis e escaláveis.
A execução de tarefas operacionais, no entanto, pela “sabedoria da produção”, fornece informações vitais para as decisões. Este trabalho mantém-nos fundamentados, fornecendo feedback em tempo real de um determinado sistema. As fontes de trabalho têm de ser identificáveis para que se possa minimizá-las ou eliminá-las. No entanto, se se encontrar numa posição de sobrecarga operacional, talvez seja necessário enviar novos recursos e mudanças com mais frequência para que os engenheiros permaneçam familiarizados com o funcionamento do serviço ao qual você dá suporte.
A Sabedoria da Produção
Uma nota sobre “a sabedoria da produção”: por esta frase, entendemos a sabedoria que se obtém de algo em produção – os detalhes confusos de como realmente se comporta, e como o software deve realmente ser projetado, em vez de uma visão de quadro branco de um serviço isolado dos fatos reais. Todas as páginas que recebe, os tickets que a equipe recebe, etc., são uma ligação direta com a realidade que deve informar melhor o design e o comportamento do sistema.
Automatizar o trabalho deste ano
O verdadeiro trabalho nesta área é determinar o que automatizar, sob que condições, e como automatizá-lo.
O SRE, tal como é praticado no Google, tem um limite rígido de quanto tempo um membro da equipe pode gastar em labuta, em oposição a uma engenharia que produz valor duradouro: 50%. Muitas pessoas pensam neste limite como uma delimitação. De fato, é muito mais útil pensar nele como uma garantia – uma declaração explícita, e um mecanismo de habilitação, para se adotar uma abordagem aos problemas baseada em engenharia, em vez de se limitar a trabalhar neles repetidamente.
Existe uma interação pouco intuitiva e interessante entre esta referência e a forma como ela se desenrola quando pensamos em automação e labuta. Com o tempo, uma equipe SRE acaba por automatizar tudo o que pode para um serviço, deixando para trás coisas que não podem ser automatizadas (o efeito Murphy-Beyer). Sendo as outras coisas iguais, isso passa a dominar o que uma equipe de SRE faz, a menos que outras ações sejam tomadas. No ambiente do Google, você tende a adicionar mais serviços, até um limite que ainda suporta 50% do tempo de engenharia, ou é tão bem-sucedido em sua automação que pode fazer outra coisa completamente diferente.
Avançar rapidamente reduzindo o custo da falha
Um dos principais benefícios do envolvimento do SRE não é necessariamente o aumento da confiabilidade, embora obviamente isso aconteça; na realidade, é a melhoria da produção de desenvolvimento do produto. Por quê? Bem, um tempo médio de reparação reduzido (MTTR) por falhas comuns resulta num aumento da velocidade do desenvolvedor do produto, uma vez que os engenheiros não têm que perder tempo e concentrar-se na limpeza após estas questões. Isto decorre do fato bem conhecido de que quanto mais tarde no ciclo de vida do produto for descoberto um problema, mais caro será repará-lo. Os SREs são especificamente encarregados de melhorar a descoberta indesejável de problemas tardiamente, produzindo benefícios para a empresa como um todo.
Compartilhe a propriedade com os desenvolvedores
As fronteiras rígidas entre “desenvolvimento de aplicações” e “produção” (por vezes chamadas programadores e operadores) são contraproducentes. Isto é especialmente verdade se a segregação de responsabilidades e a classificação das operações como centro de custos levar a desequilíbrios de poder ou discrepâncias na estima ou na remuneração.
Os SREs tendem a concentrar-se mais nos problemas de produção do que nos problemas de lógica empresarial, mas como a sua abordagem traz ferramentas de engenharia de software para lidar com o problema, partilham conjuntos de competências com equipes de desenvolvimento de produtos. Em geral, um SRE tem competências específicas em relação à disponibilidade, latência, desempenho, eficiência, gestão da mudança, monitoramento, resposta de emergência e planejamento da capacidade do(s) serviço(s) que estão cuidando. Essas competências específicas (e geralmente bem definidas) são a base do que o SRE faz para um produto e para a equipe de desenvolvimento de produto associada. Idealmente, tanto as equipes de desenvolvimento de produto como as equipes SRE deveriam ter uma visão holística da pilha – o frontend, backend, bibliotecas, armazenamento, kernels e máquina física – e nenhuma equipe deveria possuir zelosamente componentes únicos. Acontece que você pode fazer muito mais se “desfocar as linhas ” e se tiver o instrumento SREs JavaScript, ou os criadores de produtos que qualifiquem os kernels: o conhecimento de como fazer alterações e a autoridade para o fazer são muito mais generalizados, e os incentivos para proteger zelosamente qualquer função em particular são removidos.
Em Engenharia de Confiabilidade do Site, não deixamos suficientemente claro que as equipes de desenvolvimento de produtos no Google são proprietárias de seus serviços por padrão. O SRE não está disponível nem garantido para a maioria dos serviços, embora os princípios do SRE ainda informem como os serviços são gerenciados em todo o Google. O modelo de propriedade quando uma equipe SRE trabalha com uma equipe de desenvolvimento de produto é também, em última análise, um modelo compartilhado.
Use as mesmas ferramentas, independentemente da função ou cargo
O conjunto de ferramentas é um determinante incrivelmente importante do comportamento, e seria ingênuo supor que a eficácia do SRE no contexto do Google não tem nada a ver com a base de código unificada amplamente acessível, a vasta gama de ferramentas de software e sistemas, a pilha de produção altamente otimizada e proprietária, e assim por diante. No entanto, compartilhamos este pressuposto absoluto com DevOps: as equipes que se ocupam de um serviço devem utilizar as mesmas ferramentas, independentemente do seu papel na organização. Não há uma boa forma de gerir um serviço que tenha uma ferramenta para os SREs e outra para os desenvolvedores de produtos, comportando-se de forma diferente (e potencialmente catastrófica) em situações diferentes. Quanto mais divergência tiver, menos a sua empresa se beneficia de cada esforço para melhorar cada ferramenta individual.
Comparar e Contrastar
Olhando para os princípios anteriores, vemos imediatamente muita uniformidade nos pontos delineados
DevOps e SRE dependem da aceitação de que a mudança é necessária para melhorar. Sem isso, não há muito espaço para manobras.
A colaboração está na frente e no centro do trabalho de DevOps. Um modelo eficaz de propriedade compartilhada e relações de equipe de parceiros são necessários para que o SRE funcione. Tal como DevOps, o SRE também tem fortes valores compartilhados por toda a organização, o que pode tornar a escalada de silos baseados em equipes ligeiramente mais fácil.
O gerenciamento de mudanças é melhor perseguido como ações pequenas e contínuas, a maioria das quais é idealmente testada e aplicada automaticamente. A interação crítica entre a mudança e a confiabilidade torna isto especialmente importante para o SRE.
As ferramentas certas são extremamente importantes, e as ferramentas até certo ponto determinam o alcance dos seus atos. No entanto, não devemos nos concentrar demais em saber se algo é alcançado usando algum conjunto específico de ferramentas; no final das contas, a orientação da API para gerenciamento do sistema é uma filosofia mais importante que durará mais que qualquer implementação específica dela.
A medição é absolutamente fundamental para o funcionamento do DevOps e do SRE. Para o SRE, os SLOs são dominantes na determinação das ações tomadas para melhorar o serviço. É claro que não se podem ter SLOs sem medição (assim como debate entre equipes – idealmente entre produto, infraestrutura/SRE e o negócio). Para DevOps, o ato de medição é frequentemente utilizado para compreender quais são os resultados de um processo, qual é a duração dos loops de feedback, e assim por diante. Tanto os DevOps como os SRE são coisas orientadas para os dados, quer sejam profissões ou filosofias.
A realidade bruta da gestão dos serviços de produção significa que coisas más acontecem ocasionalmente, e é preciso falar sobre os motivos. O SRE e o DevOps praticam postmortems sem culpa para compensar as reações inúteis e carregadas de adrenalina.
Em última análise, a implementação do DevOps ou SRE é um ato holístico; ambos esperam tornar toda a equipe (ou unidade, ou organização) melhor, em função de trabalharem juntos de uma forma altamente específica. Tanto para o DevOps como para o SRE, o resultado deve ser uma melhor velocidade.
Como pode ver, existem muitas áreas de uniformização entre DevOps e SRE.
No entanto, existem também diferenças significativas. O DevOps é, em certo sentido, uma filosofia e cultura mais ampla. Porque afeta mudanças mais amplas do que o SRE, o DevOps é mais sensível ao contexto. O DevOps é relativamente silencioso sobre como gerir operações a um nível detalhado. Por exemplo, não é prescritivo em torno da gestão precisa dos serviços. Em vez disso, ele prefere se concentrar em derrubar barreiras na organização mais ampla. Isso tem muito valor.
O SRE, por outro lado, tem responsabilidades relativamente definidas e o seu mandato é geralmente orientado para os serviços (e para o usuário final) em vez de orientado a todo o negócio. Como resultado, traz um quadro intelectual com opiniões (incluindo conceitos como orçamentos de erro) para o problema de como gerir sistemas eficazmente. Embora o SRE esteja, como profissão, altamente consciente dos incentivos e dos seus efeitos, por sua vez é relativamente silencioso em tópicos como a siloização e as barreiras de informação. Apoiaria a IC e o CD não necessariamente devido ao caso comercial, mas devido às melhores práticas operacionais envolvidas. Ou, dito de outra forma, o SRE acredita nas mesmas coisas que o DevOps, mas por razões ligeiramente diferentes.
Contexto Organizacional e Promoção da Adoção bem sucedida
DevOps e SRE têm uma sobreposição conceitual muito grande na forma como funcionam. Como seria de esperar, eles também têm um conjunto semelhante de condições que precisam ser verdadeiras dentro da organização para que a) possam ser implementados em primeiro lugar, e b) obtenham o máximo benefício dessa implementação. Como Tolstói quase, mas nunca disse, as abordagens de operações eficazes são todas iguais, enquanto que as abordagens quebradas são todas quebradas à sua própria maneira. Os incentivos podem em parte explicar porque é que isso acontece.
Se a cultura de uma organização valoriza os benefícios de uma abordagem DevOps e está disposta a arcar com esses custos – normalmente expressos como dificuldades na contratação, a energia necessária para manter a fluidez nas equipes e responsabilidades, e o aumento dos recursos financeiros dedicados a compensar um conjunto de competências que é necessariamente mais raro – então essa organização deve também certificar-se de que os incentivos estão corretos a fim de obter todos os benefícios dessa abordagem.
Especificamente, o seguinte deve ser válido tanto no contexto do DevOps como no do SRE.
Incentivos estreitos e rígidos restringem o seu sucesso
Muitas empresas definem acidentalmente incentivos formais que prejudicam o desempenho coletivo. Para evitar este erro, não estruture os incentivos para estarem estreitamente ligados a resultados relacionados com o lançamento ou com a confiabilidade. Como qualquer economista pode lhe dizer, se houver uma medida numérica, as pessoas encontrarão uma maneira de jogá-la para um efeito ruim, às vezes até de uma maneira completamente bem intencionada. Em vez disso, deve dar ao seu povo a liberdade de encontrar as soluções de compromisso certas. Como discutido anteriormente, DevOps ou SRE podem atuar como um acelerador para a sua equipe de produtos em geral, permitindo que o resto da organização de software envie funcionalidades aos clientes de uma forma contínua e confiável. Tal dinâmica também resolve um problema persistente com a abordagem tradicional e divergente dos sistemas/grupos de software: a falta de um ciclo de feedback entre o design e a produção. Um sistema com envolvimento antecipado do SRE (idealmente, no momento do design) funciona tipicamente melhor na produção após a implementação, independentemente de quem é responsável pela gestão do serviço. (Nada atrasa o desenvolvimento de funcionalidades como a perda de dados do usuário).
É Melhor Consertar Você Mesmo; Não culpe outra pessoa
Além disso, evite quaisquer incentivos para transferir a culpa por incidentes de produção ou falhas do sistema para outros grupos. Em muitos aspectos, a dinâmica de transferir a culpa é o problema central do modelo tradicional para operações de engenharia, uma vez que a separação entre operações e equipes de software permite o surgimento de incentivos separados. Em vez disso, considere a adoção das seguintes práticas para combater a atribuição de culpas a nível organizacional:
Não apenas permita, mas incentive ativamente os engenheiros a alterar o código e a configuração quando necessário para o produto. Permita também que estas equipes sejam radicais dentro dos limites da sua missão, eliminando assim os incentivos para avançar mais lentamente.
Apoie postmortems sem culpa. Fazer isso elimina os incentivos para minimizar ou encobrir um problema. Este passo é crucial para compreender plenamente o produto e otimizar efetivamente o seu desempenho e funcionalidade, e conta com a sabedoria da produção mencionada anteriormente.
Permita que o apoio se afaste de produtos que são irremediavelmente difíceis em termos operacionais. A ameaça de retirada do apoio motiva o desenvolvimento do produto para resolver problemas tanto no período de preparação para o apoio como quando o próprio produto é apoiado, poupando tempo a todos. O que significa ser “irremediavelmente difícil operacionalmente” pode diferir dependendo do seu contexto – a dinâmica aqui deve ser de responsabilidades mutuamente compreendidas. O regresso a outras organizações pode ser mais suave: “Pensamos que há utilizações de maior valor do tempo das pessoas com este conjunto de competências”, ou enquadrado dentro do limite de: “Essas pessoas vão desistir se receberem tarefas muito operacionais e não lhes for dada a oportunidade de utilizar o seu conjunto de competências de engenharia”. No Google, a prática de retirar o apoio a tais produtos tornou-se institucional.
Considere o Trabalho de Confiabilidade como uma função Especializada
No Google, SRE e o desenvolvimento de produtos são organizações separadas. Cada grupo tem o seu próprio foco, prioridades e gestão, e não precisa fazer a licitação do outro. Contudo, as equipes de desenvolvimento de produto financiam efetivamente o crescimento do SRE com novas contratações quando um produto é bem sucedido. Desta forma, o desenvolvimento de produtos tem um interesse no sucesso das equipes SRE, assim como os SREs têm interesse no sucesso das equipes de desenvolvimento de produtos. O SRE tem também a sorte de receber apoio de alto nível da gerência, o que garante que as objeções das equipes de engenharia ao apoio de serviços “à maneira SRE” são geralmente de curta duração. Não é preciso ter um organograma para fazer as coisas de forma diferente – é preciso apenas uma comunidade de prática diferente para emergir.
Independentemente de você bifurcar seu organograma ou usar mecanismos mais informais, é importante reconhecer que a especialização cria desafios. Os praticantes de DevOps e SRE se beneficiam de ter uma comunidade de colegas para suporte e desenvolvimento de carreira, e escalas de trabalho que os recompensam pelas habilidades e perspectivas únicas que trazem para a mesa.
É importante notar que a estrutura organizacional empregada pelo Google, bem como alguns dos incentivos acima mencionados, está de certa forma dependente de uma organização de grande dimensão. Por exemplo, se sua startup de 20 pessoas tiver apenas um produto (comparativamente pequeno), não há muito sentido em permitir a retirada do apoio operacional. Ainda é possível adotar uma abordagem ao estilo DevOps, mas a capacidade de melhorar um produto operacionalmente ruim é prejudicada se literalmente tudo o que se pode fazer é ajudá-lo a crescer. Normalmente, porém, as pessoas têm mais opções do que imaginam sobre como satisfazer essas necessidades de crescimento versus a taxa na qual a dívida técnica se acumula.
Quando pode substituir Se
No entanto, quando a sua organização ou produto cresce além de um certo tamanho, você pode exercer mais latitude sobre que produtos apoiar, ou como priorizar esse apoio. Se for claro que o apoio ao sistema X vai acontecer muito mais cedo do que o apoio ao sistema Y, a condicionalidade implícita pode desempenhar o mesmo papel que a escolha de não apoiar serviços no mundo SRE.
No Google, a forte parceria do SRE com o desenvolvimento de produtos provou ser criticamente importante: se tal relação existir na sua organização, então a decisão de retirar (ou fornecer) apoio pode basear-se em dados objetivos sobre características operacionais comparativas, evitando assim conversas de outro modo não produtivas.
Uma relação produtiva entre o SRE e o desenvolvimento de produto também ajuda a evitar o anti-padrão organizacional no qual uma equipe de desenvolvimento de produto precisa enviar um produto ou funcionalidade antes de este estar completamente pronto. Em vez disso, o SRE pode trabalhar com uma equipe de desenvolvimento para melhorar o produto antes que a carga de manutenção se afaste das pessoas com mais conhecimentos para o reparar.
Esforce-se pela Paridade de Estima: Carreira e Finanças
Por fim, certifique-se de que os incentivos de carreira para fazer a coisa certa estejam no lugar: queremos que a nossa organização DevOps/SRE tenha a mesma estima que os seus colegas de desenvolvimento de produtos. Por conseguinte, os membros de cada equipe devem ser avaliados aproximadamente pelos mesmos métodos e ter os mesmos incentivos financeiros.
Conclusão
Em muitos aspectos, DevOps e SRE situam-se, tanto na prática como na filosofia, muito próximos um do outro no cenário geral das operações de TI.
Tanto o DevOps como o SRE requerem discussão, apoio de gestão, e a adesão das pessoas que realmente fazem o trabalho para fazer progressos sérios. A implementação de qualquer um deles é uma jornada e não uma solução rápida: a prática de renomear e expor é uma prática vazia, com pouca probabilidade de gerar benefícios. Por se tratar de uma implementação mais opinativa de como realizar as operações, o SRE tem sugestões mais concretas sobre como alterar as suas práticas de trabalho mais cedo nessa jornada, embora exigindo uma adaptação específica. DevOps, tendo um foco mais amplo, é algo mais difícil de raciocinar e traduzir em passos concretos, mas precisamente devido a esse foco mais amplo, é provável que encontre uma resistência inicial mais fraca.
Mas os profissionais de cada um deles utilizam muitas das mesmas ferramentas, as mesmas abordagens para gerenciamento de mudanças e a mesma mentalidade de tomada de decisão baseada em dados. No fim das contas, todos nós enfrentamos o mesmo problema persistente: produção e melhoria – não importa como somos chamados.
Para os interessados na leitura posterior, as seguintes sugestões devem ajudá-lo a desenvolver uma compreensão mais ampla dos fundamentos culturais, comerciais e técnicos da revolução das operações que está ocorrendo agora:
Engenharia de confiabilidade do site
DevOps Eficaz
O projeto Fênix
A Prática da Administração do Sistema em Nuvem: DevOps e Práticas SRE para Serviços Web, Volume 2
As operações, como disciplina, são difíceis. Não só existe a questão geralmente não resolvida de como gerir bem os sistemas, mas também as melhores práticas que funcionam são altamente dependentes do contexto e estão longe de serem amplamente adotadas. Há também a questão, em grande parte não respondida, de como gerir bem as equipes de operações. Pensa-se que a análise detalhada destes tópicos tem geralmente origem na Investigação Operacional dedicada à melhoria dos processos e dos resultados nas forças armadas Aliadas durante a Segunda Guerra Mundial, mas na realidade, temos pensado em como operar melhor as coisas por milênios.
No entanto, apesar de todo este esforço e pensamento, as operações de produção confiáveis permanecem elusivas – especialmente nos domínios da tecnologia da informação e da operacionalidade do software. O mundo empresarial, por exemplo, trata frequentemente as operações como um centro de custos, o que torna as melhorias significativas nos resultados difíceis, se não mesmo impossíveis. A tremenda miopia desta abordagem ainda não é amplamente compreendida, mas a insatisfação com ela deu origem a uma revolução na forma de organizar o que fazemos em TI.
Essa revolução decorreu da tentativa de resolver um conjunto comum de problemas. As mais recentes soluções para estes problemas são chamadas por dois nomes distintos – DevOps e Engenharia de Confiabilidade do Site (SRE). Embora falemos deles individualmente como se fossem reações totalmente separadas à mentalidade empresarial que acabamos de descrever, esperamos persuadi-lo de que, de fato, são muito mais parecidos, e os profissionais de cada um têm muito mais em comum, do que se poderia supor.
Mas primeiro, alguns antecedentes sobre os princípios fundamentais de cada um.
Antecedentes sobre DevOps
DevOps é um conjunto disperso de práticas, diretrizes, e cultura projetado para quebrar silos no desenvolvimento de TI, operações, redes e segurança. Articulado por John Willis, Damon Edwards, e Jez Humble, CA(L)MS – que significa Cultura, Automação, Lean (como na gestão Lean; ver também entrega contínua), Medição, e Partilha – é um acrônimo útil para lembrar os pontos-chave da filosofia DevOps. O compartilhamento e a colaboração estão na vanguarda desse movimento. Em uma abordagem DevOps, você melhora algo (geralmente automatizando-o), mede os resultados e compartilha esses resultados com colegas para que toda a organização possa melhorar. Todos os princípios do CALMS são facilitados por uma cultura de apoio.
DevOps, Agile, e uma variedade de outras técnicas de reengenharia empresarial e de software são todos exemplos de uma visão geral do mundo sobre a melhor forma de fazer negócios no mundo moderno. Nenhum dos elementos da filosofia DevOps é facilmente separável uns dos outros, e isto é essencialmente por padrão. Existem, no entanto, algumas ideias-chave que podem ser discutidas em relativo isolamento.
Não mais Silos
A primeira ideia chave é não mais silos. Esta é uma reação a algumas ideias:
O arranjo historicamente popular, mas agora cada vez mais antiquado de operações e equipes de desenvolvimento separadas
O fato de que a siloização extrema do conhecimento, os incentivos à otimização puramente local e a falta de colaboração terem sido, em muitos casos, ativamente prejudiciais para os negócios
Acidentes são normais
A segunda ideia-chave é que os acidentes não resultam apenas das ações isoladas de um indivíduo, mas resultam da falta de salvaguardas para quando as coisas inevitavelmente dão errado. Por exemplo, uma interface ruim inadvertidamente incentiva a ação errada sob pressão; um mau funcionamento do sistema torna a falha inevitável se as circunstâncias erradas (não articuladas) ocorrerem; um monitoramento falho torna impossível saber se algo está errado, não importa o que está errado. Algumas empresas mais tradicionais possuem o instinto cultural para erradicar o autor do erro e puni-los. Mas fazer isso tem suas próprias consequências: mais obviamente, cria incentivos para confundir questões, esconder a verdade, e culpar outros, tudo isto são, em última análise, distrações não lucrativas. Por conseguinte, é mais rentável concentrar-se em acelerar a recuperação do que em prevenir acidentes.
A mudança deve ser gradual
A terceira ideia-chave é que a mudança é melhor quando é pequena e frequente. Em ambientes onde os comitês de mudança se reúnem mensalmente para discutir planos minuciosamente documentados para fazer alterações à configuração do mainframe, esta é uma ideia radical. Contudo, esta não é uma ideia nova. A noção de que todas as mudanças devem ser consideradas por seres humanos experientes e agrupadas para consideração eficiente acaba por ser mais ou menos o oposto das melhores práticas. A mudança é arriscada, é verdade, mas a resposta correta é dividir as suas mudanças em subcomponentes menores sempre que possível. Em seguida, cria-se um pipeline estável de alterações de baixo risco a partir da saída regular de alterações de produto, design e infraestrutura. Essa estratégia, juntamente com o teste automático de alterações menores e a reversão confiável de alterações ruins, leva a abordagens de gerenciamento de integração (CI) e entrega ou implantação contínua (CD).
Ferramentas e Cultura Estão Interrelacionadas
As ferramentas são um componente importante do DevOps, particularmente dada a ênfase na gestão correta da mudança, a gestão da mudança depende de ferramentas altamente específicas. No entanto, em geral, os defensores do DevOps enfatizam fortemente a cultura organizacional – em vez de ferramentas – como a chave do sucesso na adoção de uma nova forma de trabalhar. Uma boa cultura pode trabalhar em torno de ferramentas quebradas, mas o oposto raramente se aplica. Como diz o ditado, a cultura come a estratégia no café da manhã. Tal como as operações, a própria mudança é difícil.
A Medição é Crucial
Finalmente, a medição é particularmente crucial no contexto empresarial global de, por exemplo, quebra de silos e resolução de incidentes. Em cada um desses ambientes, você estabelece a realidade do que está acontecendo por meio de medição objetiva, verifica se está mudando a situação conforme o esperado, e cria uma base objetiva para conversas em que as diferentes funções concordam. (Isto aplica-se tanto em contextos empresariais como em outros contextos, tais como o de plantão).
Antecedentes de SRE
Engenharia de confiabilidade do site (SRE) é um termo (e função de trabalho associado) cunhado por Ben Treynor Sloss, um VP de engenharia no Google. Como podemos ver na seção anterior, DevOps é um amplo conjunto de princípios sobre a colaboração em todo o ciclo de vida entre operações e desenvolvimento de produtos. SRE é uma função de trabalho, um conjunto de práticas (descritas a seguir) que encontramos para funcionar, e algumas crenças que animam essas práticas. Se pensarmos no DevOps como uma filosofia e uma abordagem de trabalho, podemos argumentar que o SRE implementa parte da filosofia que o DevOps descreve, e está um pouco mais próximo de uma definição concreta de um trabalho ou função do que, digamos, “engenheiro DevOps “. Então, de certa forma, a classe SRE implementa a interface DevOps.
Ao contrário do movimento DevOps, que teve origem em colaborações entre líderes e profissionais de várias empresas, o SRE no Google herdou grande parte da sua cultura da empresa adjacente antes do termo SRE ter se tornado amplamente popular em toda a indústria. Dada essa trajetória, a disciplina como um todo atualmente não coloca em primeiro plano a mudança cultural por padrão tanto quanto o DevOps. (Isso não implica em nada sobre se a mudança cultural é necessária para fazer o SRE em uma organização arbitrária, é claro).
O SRE é definido pelos seguintes princípios concretos.
As operações são um problema de softwar
O princípio básico do SRE é que fazer bem as operações é um problema de software. Por conseguinte, o SRE deveria utilizar abordagens de engenharia de software para resolver esse problema. Isto abrange um amplo campo de visão, abrangendo tudo, desde processos e mudanças empresariais até problemas de software igualmente complicados, mas mais tradicionais, tais como reescrever uma pilha para eliminar pontos únicos de falha na lógica empresarial.
Gerenciar por Objetivos de Nível de Serviço (SLOs)
O SRE não tenta dar a tudo 100% de disponibilidade. Como discutido no nosso primeiro livro, Engenharia de confiabilidade do site, este é o alvo errado por uma série de razões. Em vez disso, a equipe de produto e a equipe SRE selecionam um alvo de disponibilidade adequado para o serviço e a sua base de usuários, e o serviço é gerenciado para esse SLO. Decidir sobre tal alvo requer uma forte colaboração por parte da empresa. Os SLOs têm também implicações culturais: como decisões de colaboração entre as partes interessadas, as violações do SLO trazem as equipes de volta à mesa de projeto, sem culpa.
Trabalho para Minimizar a Labuta
Para o SRE, qualquer tarefa operacional manual e estruturalmente obrigatória é abominável. (Isso não significa que não tenhamos tais operações: temos muitas delas. Simplesmente, não gostamos delas). Acreditamos que se uma máquina pode realizar uma operação desejada, então uma máquina deve frequentemente realizá-la. Isto é uma distinção (e um valor) que não se vê muitas vezes noutras organizações, onde a labuta é o trabalho, e é isso que se paga a uma pessoa para fazer. Para o SRE no contexto do Google, a labuta não é o trabalho – não pode ser. Qualquer tempo gasto em tarefas operacionais significa tempo não gasto em trabalho de projeto – e trabalho de projeto é como tornamos os nossos serviços mais confiáveis e escaláveis.
A execução de tarefas operacionais, no entanto, pela “sabedoria da produção”, fornece informações vitais para as decisões. Este trabalho mantém-nos fundamentados, fornecendo feedback em tempo real de um determinado sistema. As fontes de trabalho têm de ser identificáveis para que se possa minimizá-las ou eliminá-las. No entanto, se se encontrar numa posição de sobrecarga operacional, talvez seja necessário enviar novos recursos e mudanças com mais frequência para que os engenheiros permaneçam familiarizados com o funcionamento do serviço ao qual você dá suporte.
A Sabedoria da Produção
Uma nota sobre “a sabedoria da produção”: por esta frase, entendemos a sabedoria que se obtém de algo em produção – os detalhes confusos de como realmente se comporta, e como o software deve realmente ser projetado, em vez de uma visão de quadro branco de um serviço isolado dos fatos reais. Todas as páginas que recebe, os tickets que a equipe recebe, etc., são uma ligação direta com a realidade que deve informar melhor o design e o comportamento do sistema.
Automatizar o trabalho deste ano
O verdadeiro trabalho nesta área é determinar o que automatizar, sob que condições, e como automatizá-lo.
O SRE, tal como é praticado no Google, tem um limite rígido de quanto tempo um membro da equipe pode gastar em labuta, em oposição a uma engenharia que produz valor duradouro: 50%. Muitas pessoas pensam neste limite como uma delimitação. De fato, é muito mais útil pensar nele como uma garantia – uma declaração explícita, e um mecanismo de habilitação, para se adotar uma abordagem aos problemas baseada em engenharia, em vez de se limitar a trabalhar neles repetidamente.
Existe uma interação pouco intuitiva e interessante entre esta referência e a forma como ela se desenrola quando pensamos em automação e labuta. Com o tempo, uma equipe SRE acaba por automatizar tudo o que pode para um serviço, deixando para trás coisas que não podem ser automatizadas (o efeito Murphy-Beyer). Sendo as outras coisas iguais, isso passa a dominar o que uma equipe de SRE faz, a menos que outras ações sejam tomadas. No ambiente do Google, você tende a adicionar mais serviços, até um limite que ainda suporta 50% do tempo de engenharia, ou é tão bem-sucedido em sua automação que pode fazer outra coisa completamente diferente.
Avançar rapidamente reduzindo o custo da falha
Um dos principais benefícios do envolvimento do SRE não é necessariamente o aumento da confiabilidade, embora obviamente isso aconteça; na realidade, é a melhoria da produção de desenvolvimento do produto. Por quê? Bem, um tempo médio de reparação reduzido (MTTR) por falhas comuns resulta num aumento da velocidade do desenvolvedor do produto, uma vez que os engenheiros não têm que perder tempo e concentrar-se na limpeza após estas questões. Isto decorre do fato bem conhecido de que quanto mais tarde no ciclo de vida do produto for descoberto um problema, mais caro será repará-lo. Os SREs são especificamente encarregados de melhorar a descoberta indesejável de problemas tardiamente, produzindo benefícios para a empresa como um todo.
Compartilhe a propriedade com os desenvolvedores
As fronteiras rígidas entre “desenvolvimento de aplicações” e “produção” (por vezes chamadas programadores e operadores) são contraproducentes. Isto é especialmente verdade se a segregação de responsabilidades e a classificação das operações como centro de custos levar a desequilíbrios de poder ou discrepâncias na estima ou na remuneração.
Os SREs tendem a concentrar-se mais nos problemas de produção do que nos problemas de lógica empresarial, mas como a sua abordagem traz ferramentas de engenharia de software para lidar com o problema, partilham conjuntos de competências com equipes de desenvolvimento de produtos. Em geral, um SRE tem competências específicas em relação à disponibilidade, latência, desempenho, eficiência, gestão da mudança, monitoramento, resposta de emergência e planejamento da capacidade do(s) serviço(s) que estão cuidando. Essas competências específicas (e geralmente bem definidas) são a base do que o SRE faz para um produto e para a equipe de desenvolvimento de produto associada. Idealmente, tanto as equipes de desenvolvimento de produto como as equipes SRE deveriam ter uma visão holística da pilha – o frontend, backend, bibliotecas, armazenamento, kernels e máquina física – e nenhuma equipe deveria possuir zelosamente componentes únicos. Acontece que você pode fazer muito mais se “desfocar as linhas ” e se tiver o instrumento SREs JavaScript, ou os criadores de produtos que qualifiquem os kernels: o conhecimento de como fazer alterações e a autoridade para o fazer são muito mais generalizados, e os incentivos para proteger zelosamente qualquer função em particular são removidos.
Em Engenharia de Confiabilidade do Site, não deixamos suficientemente claro que as equipes de desenvolvimento de produtos no Google são proprietárias de seus serviços por padrão. O SRE não está disponível nem garantido para a maioria dos serviços, embora os princípios do SRE ainda informem como os serviços são gerenciados em todo o Google. O modelo de propriedade quando uma equipe SRE trabalha com uma equipe de desenvolvimento de produto é também, em última análise, um modelo compartilhado.
Use as mesmas ferramentas, independentemente da função ou cargo
O conjunto de ferramentas é um determinante incrivelmente importante do comportamento, e seria ingênuo supor que a eficácia do SRE no contexto do Google não tem nada a ver com a base de código unificada amplamente acessível, a vasta gama de ferramentas de software e sistemas, a pilha de produção altamente otimizada e proprietária, e assim por diante. No entanto, compartilhamos este pressuposto absoluto com DevOps: as equipes que se ocupam de um serviço devem utilizar as mesmas ferramentas, independentemente do seu papel na organização. Não há uma boa forma de gerir um serviço que tenha uma ferramenta para os SREs e outra para os desenvolvedores de produtos, comportando-se de forma diferente (e potencialmente catastrófica) em situações diferentes. Quanto mais divergência tiver, menos a sua empresa se beneficia de cada esforço para melhorar cada ferramenta individual.
Comparar e Contrastar
Olhando para os princípios anteriores, vemos imediatamente muita uniformidade nos pontos delineados
DevOps e SRE dependem da aceitação de que a mudança é necessária para melhorar. Sem isso, não há muito espaço para manobras.
A colaboração está na frente e no centro do trabalho de DevOps. Um modelo eficaz de propriedade compartilhada e relações de equipe de parceiros são necessários para que o SRE funcione. Tal como DevOps, o SRE também tem fortes valores compartilhados por toda a organização, o que pode tornar a escalada de silos baseados em equipes ligeiramente mais fácil.
O gerenciamento de mudanças é melhor perseguido como ações pequenas e contínuas, a maioria das quais é idealmente testada e aplicada automaticamente. A interação crítica entre a mudança e a confiabilidade torna isto especialmente importante para o SRE.
As ferramentas certas são extremamente importantes, e as ferramentas até certo ponto determinam o alcance dos seus atos. No entanto, não devemos nos concentrar demais em saber se algo é alcançado usando algum conjunto específico de ferramentas; no final das contas, a orientação da API para gerenciamento do sistema é uma filosofia mais importante que durará mais que qualquer implementação específica dela.
A medição é absolutamente fundamental para o funcionamento do DevOps e do SRE. Para o SRE, os SLOs são dominantes na determinação das ações tomadas para melhorar o serviço. É claro que não se podem ter SLOs sem medição (assim como debate entre equipes – idealmente entre produto, infraestrutura/SRE e o negócio). Para DevOps, o ato de medição é frequentemente utilizado para compreender quais são os resultados de um processo, qual é a duração dos loops de feedback, e assim por diante. Tanto os DevOps como os SRE são coisas orientadas para os dados, quer sejam profissões ou filosofias.
A realidade bruta da gestão dos serviços de produção significa que coisas más acontecem ocasionalmente, e é preciso falar sobre os motivos. O SRE e o DevOps praticam postmortems sem culpa para compensar as reações inúteis e carregadas de adrenalina.
Em última análise, a implementação do DevOps ou SRE é um ato holístico; ambos esperam tornar toda a equipe (ou unidade, ou organização) melhor, em função de trabalharem juntos de uma forma altamente específica. Tanto para o DevOps como para o SRE, o resultado deve ser uma melhor velocidade.
Como pode ver, existem muitas áreas de uniformização entre DevOps e SRE.
No entanto, existem também diferenças significativas. O DevOps é, em certo sentido, uma filosofia e cultura mais ampla. Porque afeta mudanças mais amplas do que o SRE, o DevOps é mais sensível ao contexto. O DevOps é relativamente silencioso sobre como gerir operações a um nível detalhado. Por exemplo, não é prescritivo em torno da gestão precisa dos serviços. Em vez disso, ele prefere se concentrar em derrubar barreiras na organização mais ampla. Isso tem muito valor.
O SRE, por outro lado, tem responsabilidades relativamente definidas e o seu mandato é geralmente orientado para os serviços (e para o usuário final) em vez de orientado a todo o negócio. Como resultado, traz um quadro intelectual com opiniões (incluindo conceitos como orçamentos de erro) para o problema de como gerir sistemas eficazmente. Embora o SRE esteja, como profissão, altamente consciente dos incentivos e dos seus efeitos, por sua vez é relativamente silencioso em tópicos como a siloização e as barreiras de informação. Apoiaria a IC e o CD não necessariamente devido ao caso comercial, mas devido às melhores práticas operacionais envolvidas. Ou, dito de outra forma, o SRE acredita nas mesmas coisas que o DevOps, mas por razões ligeiramente diferentes.
Contexto Organizacional e Promoção da Adoção bem sucedida
DevOps e SRE têm uma sobreposição conceitual muito grande na forma como funcionam. Como seria de esperar, eles também têm um conjunto semelhante de condições que precisam ser verdadeiras dentro da organização para que a) possam ser implementados em primeiro lugar, e b) obtenham o máximo benefício dessa implementação. Como Tolstói quase, mas nunca disse, as abordagens de operações eficazes são todas iguais, enquanto que as abordagens quebradas são todas quebradas à sua própria maneira. Os incentivos podem em parte explicar porque é que isso acontece.
Se a cultura de uma organização valoriza os benefícios de uma abordagem DevOps e está disposta a arcar com esses custos – normalmente expressos como dificuldades na contratação, a energia necessária para manter a fluidez nas equipes e responsabilidades, e o aumento dos recursos financeiros dedicados a compensar um conjunto de competências que é necessariamente mais raro – então essa organização deve também certificar-se de que os incentivos estão corretos a fim de obter todos os benefícios dessa abordagem.
Especificamente, o seguinte deve ser válido tanto no contexto do DevOps como no do SRE.
Incentivos estreitos e rígidos restringem o seu sucesso
Muitas empresas definem acidentalmente incentivos formais que prejudicam o desempenho coletivo. Para evitar este erro, não estruture os incentivos para estarem estreitamente ligados a resultados relacionados com o lançamento ou com a confiabilidade. Como qualquer economista pode lhe dizer, se houver uma medida numérica, as pessoas encontrarão uma maneira de jogá-la para um efeito ruim, às vezes até de uma maneira completamente bem intencionada. Em vez disso, deve dar ao seu povo a liberdade de encontrar as soluções de compromisso certas. Como discutido anteriormente, DevOps ou SRE podem atuar como um acelerador para a sua equipe de produtos em geral, permitindo que o resto da organização de software envie funcionalidades aos clientes de uma forma contínua e confiável. Tal dinâmica também resolve um problema persistente com a abordagem tradicional e divergente dos sistemas/grupos de software: a falta de um ciclo de feedback entre o design e a produção. Um sistema com envolvimento antecipado do SRE (idealmente, no momento do design) funciona tipicamente melhor na produção após a implementação, independentemente de quem é responsável pela gestão do serviço. (Nada atrasa o desenvolvimento de funcionalidades como a perda de dados do usuário).
É Melhor Consertar Você Mesmo; Não culpe outra pessoa
Além disso, evite quaisquer incentivos para transferir a culpa por incidentes de produção ou falhas do sistema para outros grupos. Em muitos aspectos, a dinâmica de transferir a culpa é o problema central do modelo tradicional para operações de engenharia, uma vez que a separação entre operações e equipes de software permite o surgimento de incentivos separados. Em vez disso, considere a adoção das seguintes práticas para combater a atribuição de culpas a nível organizacional:
Não apenas permita, mas incentive ativamente os engenheiros a alterar o código e a configuração quando necessário para o produto. Permita também que estas equipes sejam radicais dentro dos limites da sua missão, eliminando assim os incentivos para avançar mais lentamente.
Apoie postmortems sem culpa. Fazer isso elimina os incentivos para minimizar ou encobrir um problema. Este passo é crucial para compreender plenamente o produto e otimizar efetivamente o seu desempenho e funcionalidade, e conta com a sabedoria da produção mencionada anteriormente.
Permita que o apoio se afaste de produtos que são irremediavelmente difíceis em termos operacionais. A ameaça de retirada do apoio motiva o desenvolvimento do produto para resolver problemas tanto no período de preparação para o apoio como quando o próprio produto é apoiado, poupando tempo a todos. O que significa ser “irremediavelmente difícil operacionalmente” pode diferir dependendo do seu contexto – a dinâmica aqui deve ser de responsabilidades mutuamente compreendidas. O regresso a outras organizações pode ser mais suave: “Pensamos que há utilizações de maior valor do tempo das pessoas com este conjunto de competências”, ou enquadrado dentro do limite de: “Essas pessoas vão desistir se receberem tarefas muito operacionais e não lhes for dada a oportunidade de utilizar o seu conjunto de competências de engenharia”. No Google, a prática de retirar o apoio a tais produtos tornou-se institucional.
Considere o Trabalho de Confiabilidade como uma função Especializada
No Google, SRE e o desenvolvimento de produtos são organizações separadas. Cada grupo tem o seu próprio foco, prioridades e gestão, e não precisa fazer a licitação do outro. Contudo, as equipes de desenvolvimento de produto financiam efetivamente o crescimento do SRE com novas contratações quando um produto é bem sucedido. Desta forma, o desenvolvimento de produtos tem um interesse no sucesso das equipes SRE, assim como os SREs têm interesse no sucesso das equipes de desenvolvimento de produtos. O SRE tem também a sorte de receber apoio de alto nível da gerência, o que garante que as objeções das equipes de engenharia ao apoio de serviços “à maneira SRE” são geralmente de curta duração. Não é preciso ter um organograma para fazer as coisas de forma diferente – é preciso apenas uma comunidade de prática diferente para emergir.
Independentemente de você bifurcar seu organograma ou usar mecanismos mais informais, é importante reconhecer que a especialização cria desafios. Os praticantes de DevOps e SRE se beneficiam de ter uma comunidade de colegas para suporte e desenvolvimento de carreira, e escalas de trabalho que os recompensam pelas habilidades e perspectivas únicas que trazem para a mesa.
É importante notar que a estrutura organizacional empregada pelo Google, bem como alguns dos incentivos acima mencionados, está de certa forma dependente de uma organização de grande dimensão. Por exemplo, se sua startup de 20 pessoas tiver apenas um produto (comparativamente pequeno), não há muito sentido em permitir a retirada do apoio operacional. Ainda é possível adotar uma abordagem ao estilo DevOps, mas a capacidade de melhorar um produto operacionalmente ruim é prejudicada se literalmente tudo o que se pode fazer é ajudá-lo a crescer. Normalmente, porém, as pessoas têm mais opções do que imaginam sobre como satisfazer essas necessidades de crescimento versus a taxa na qual a dívida técnica se acumula.
Quando pode substituir Se
No entanto, quando a sua organização ou produto cresce além de um certo tamanho, você pode exercer mais latitude sobre que produtos apoiar, ou como priorizar esse apoio. Se for claro que o apoio ao sistema X vai acontecer muito mais cedo do que o apoio ao sistema Y, a condicionalidade implícita pode desempenhar o mesmo papel que a escolha de não apoiar serviços no mundo SRE.
No Google, a forte parceria do SRE com o desenvolvimento de produtos provou ser criticamente importante: se tal relação existir na sua organização, então a decisão de retirar (ou fornecer) apoio pode basear-se em dados objetivos sobre características operacionais comparativas, evitando assim conversas de outro modo não produtivas.
Uma relação produtiva entre o SRE e o desenvolvimento de produto também ajuda a evitar o anti-padrão organizacional no qual uma equipe de desenvolvimento de produto precisa enviar um produto ou funcionalidade antes de este estar completamente pronto. Em vez disso, o SRE pode trabalhar com uma equipe de desenvolvimento para melhorar o produto antes que a carga de manutenção se afaste das pessoas com mais conhecimentos para o reparar.
Esforce-se pela Paridade de Estima: Carreira e Finanças
Por fim, certifique-se de que os incentivos de carreira para fazer a coisa certa estejam no lugar: queremos que a nossa organização DevOps/SRE tenha a mesma estima que os seus colegas de desenvolvimento de produtos. Por conseguinte, os membros de cada equipe devem ser avaliados aproximadamente pelos mesmos métodos e ter os mesmos incentivos financeiros.
Conclusão
Em muitos aspectos, DevOps e SRE situam-se, tanto na prática como na filosofia, muito próximos um do outro no cenário geral das operações de TI.
Tanto o DevOps como o SRE requerem discussão, apoio de gestão, e a adesão das pessoas que realmente fazem o trabalho para fazer progressos sérios. A implementação de qualquer um deles é uma jornada e não uma solução rápida: a prática de renomear e expor é uma prática vazia, com pouca probabilidade de gerar benefícios. Por se tratar de uma implementação mais opinativa de como realizar as operações, o SRE tem sugestões mais concretas sobre como alterar as suas práticas de trabalho mais cedo nessa jornada, embora exigindo uma adaptação específica. DevOps, tendo um foco mais amplo, é algo mais difícil de raciocinar e traduzir em passos concretos, mas precisamente devido a esse foco mais amplo, é provável que encontre uma resistência inicial mais fraca.
Mas os profissionais de cada um deles utilizam muitas das mesmas ferramentas, as mesmas abordagens para gerenciamento de mudanças e a mesma mentalidade de tomada de decisão baseada em dados. No fim das contas, todos nós enfrentamos o mesmo problema persistente: produção e melhoria – não importa como somos chamados.
Para os interessados na leitura posterior, as seguintes sugestões devem ajudá-lo a desenvolver uma compreensão mais ampla dos fundamentos culturais, comerciais e técnicos da revolução das operações que está ocorrendo agora:
Engenharia de confiabilidade do site
DevOps Eficaz
O projeto Fênix
A Prática da Administração do Sistema em Nuvem: DevOps e Práticas SRE para Serviços Web, Volume 2
