Historicamente tem havido uma tensão natural entre as operações (ops) e os desenvolvedores. A missão das Ops é manter os sistemas estáveis e em funcionamento. Para a maioria dos sistemas, se nada mudar com o sistema, ele tenderá a comportar-se como no passado. Os desenvolvedores, no entanto, são tipicamente incentivados a aumentar o uso do sistema, o que significa, seja bom ou ruim, mais recursos. Novas características resultam em rápidas mudanças no sistema e algum nível de instabilidade e risco é introduzido no sistema. Estes incentivos opostos criam uma imensa tensão entre as duas equipas. Isto resulta em operações removendo o acesso às máquinas e assim a liberdade de fazer qualquer operação relacionada. Isto põe um fim a novas idéias como micro-serviços dentro da organização porque a infra-estrutura é sempre necessária para colocar novos serviços e a nova infra-estrutura requer uma colaboração profunda com outra equipe. Esta tensão não é boa e cria uma divisão dentro de suas equipes de engenharia que não leva a nenhum progresso porque as duas equipes se recusam a ajudar uma à outra. Isto não só prejudica a produtividade mas, em última análise, a felicidade dos seus funcionários e eles começarão a sair. Se eu aprendi alguma coisa como líder de engenharia é o seguinte: se você quer manter seus funcionários felizes, você tem que ter certeza de que eles são produtivos. Feliz significa conviver com outras equipes de engenharia e unificar a cultura em vez de criar uma cultura divisória.

"Com Grande Poder Vem Grande Responsabilidade"

Como equipe somos todos responsáveis pelo software que colocamos em produção, e não apenas pelas operações ou desenvolvedores. Isto significa que temos de criar uma estrutura de incentivo que dê tanto às operações como aos programadores um objectivo comum. Devops tem muitos significados para diferentes pessoas, mas para nós no ShareThis significa que há uma alta sobreposição entre as áreas funcionais de operações, desenvolvimento e QA. Portanto, para que os desenvolvedores ganhem o poder de fazer mudanças na produção, eles têm que ser responsáveis por suas ações. É por isso que acreditamos que é fundamental que os desenvolvedores tenham uma rotação de plantão caso algo dê errado. Os desenvolvedores devem experimentar o que é ser alertados quando seu código causa problemas inesperados. Isto compartilha o fardo de resolver problemas nas horas de folga em toda a equipe e não apenas nos ombros das operações ou em uma única equipe.

SLA e SLA Permissão

Uma das atividades mais importantes é a definição de um SLA para serviços. Isso define as expectativas de estabilidade em um sistema para os clientes, desenvolvedores e operações. Mas o objetivo nunca deve ser ter 100% de tempo de atividade porque isso pode significar que você está se movendo muito devagar e não está assumindo riscos suficientes. Um startup tem tudo a ver com correr riscos calculados e mover-se rapidamente. Quanto a ser mais quantitativo sobre os riscos, usamos as permissões de SLA. Nós podemos calcular nossa tolerância ao risco tomando o SLA e subtraindo 1. Assim, se você tiver um SLA de 99,9% de tempo de atividade, podemos calcular uma tolerância de SLA pelo seguinte 1 - 0,999 = .001, que é a nossa tolerância de SLA. Isto significa que o site pode ter 43m de tempo de inatividade antes de você ter esgotado o tempo de atividade acordado. Ao usar isso, os desenvolvedores podem implantar com a freqüência desejada desde que não atinjam suas permissões de SLA. Uma vez que o façam, nenhum recurso novo pode ser implantado e, em vez disso, a equipe deve se concentrar na estabilidade. Isto coloca uma ênfase em testes e monitoramento automatizados para verificar que seus aplicativos não causarão problemas na produção. Isto também coloca um equilíbrio saudável entre velocidade e tolerância ao risco que pode ser acordado de antemão. Por todo o escritório estamos construindo painéis de controle que podem rapidamente mostrar quaisquer anomalias para que possamos reverter quaisquer alterações antes que causem violações de SLA.

Os Resultados

Desde que trabalhamos na cultura "DevOps" temos visto um aumento dramático da colaboração entre as equipas e também um aumento da produtividade. A propriedade total das aplicações desde o desenvolvimento até a produção se espalhou por toda a equipe e agora somos capazes de obter servidores e infra-estrutura em segundos versus semanas. Para os nossos clientes isto significa novas funcionalidades e estabilidade do serviço. Para as nossas partes interessadas internas isto significa linhas de tempo previsíveis. Mais importante ainda, para a nossa equipa, estas mudanças dão-lhes um sentido de propriedade e produtividade.

Se este tipo de ambiente de trabalho é algo que lhe interessa, por favor visite a nossa página de oportunidades:
https://sharethis.com/careers/