Olá Habr! E novamente Alexey Pristavko está em contato.

Ao contrário dos meus artigos anteriores, hoje falaremos sobre pessoas. Os heróis do dia são o serviço de operação, cujos interesses eu represento, e o serviço de desenvolvimento.

O trabalho coordenado desses serviços é a chave para um lançamento bem-sucedido e um "vôo" suave do serviço criado. Mas, como mostra minha experiência (e não apenas), praticamente nenhum projeto pode prescindir de conflitos e desacordos, cuja vítima é um serviço inocente.

Neste artigo, tentarei responder às seguintes perguntas:

• Como os métodos e processos de desenvolvimento afetam as operações?
• O que impulsiona cada lado do conflito?
• Qual é a causa raiz do desacordo?

Bem-vindo ao gato!

Quais são os desafios dos serviços

Conheceremos melhor os departamentos e começaremos com o serviço de operação (também é um serviço de suporte). Por que esse animal terrível é necessário, que tarefa ele executa e "para quem" ele funciona?

A principal tarefa do serviço operacional é gerenciar o nível de serviços, ou seja, manter a operação do sistema de TI dentro da estrutura do SLA.
A operação deve fornecer acesso constante ao serviço e seu correto funcionamento no âmbito de um contrato com o cliente - geralmente com a empresa.

Aqui está a solução para esse problema:

• Gerenciamento de incidentes: restaurando a função comercial durante um acidente;
  
• Gerenciamento de problemas: abordando as prováveis ​​causas de acidentes e incidentes;
  
• Gerenciamento de configuração: coleta de informações e análise de parâmetros de operação de software e infraestrutura;
  
• Gerenciamento de mudanças: minimizando o risco de problemas e acidentes durante as mudanças.
  

O papel do serviço de desenvolvimento também é compreensível - a criação inicial de um serviço de TI e a introdução de novas funcionalidades nele, a pedido do cliente.

Certamente, você já tem suspeitas sobre os pontos de atrito dos desenvolvedores e do suporte, porque onde há interseções de tarefas, há conflitos. Mas não se apresse em tirar conclusões. O eterno debate entre desenvolvedores e administradores está longe do epicentro das "batalhas".

Onde crescem as divergências

A “guerra” de programadores e administradores não é um confronto de interesses humanos, é um confronto de serviços.



O problema está nas prioridades e na motivação desses mesmos serviços. Na sua forma mais geral, isso pode ser descrito da seguinte maneira:

• A equipe de desenvolvimento deseja usar a tecnologia de primeira atualização (desenvolvimento profissional, interesse) e fazer o trabalho o mais rápido possível (motivação externa).
  

• A operação está interessada nas tecnologias mais estáveis ​​(seus problemas são conhecidos e geralmente aceitam soluções) e explicações detalhadas sobre o que fazer em caso de problemas no software desenvolvido (motivação externa para velocidade de solução de problemas).
  

Ao mesmo tempo, é importante entender que não apenas os desenvolvedores "viram" novas funcionalidades, mas nem sempre os administradores exclusivamente aumentam os problemas.

• Os administradores estão envolvidos ativamente no processo de desenvolvimento - na construção de esquemas de infraestrutura, tolerância a falhas e escalabilidade, na preparação de configurações iniciais e, idealmente, no processo de preparação de requisitos de software. Tudo isso é chamado de processo de desenvolvimento de solução (não confunda com a escrita direta de código!).
  

• Programadores estão ativamente envolvidos na operação. Eles corrigem erros de software, realizam otimizações do sistema e aprimoramentos técnicos para atender ao sistema SLA, ou seja, resolvem o problema de acessibilidade do serviço final de TI.
  

O conflito entre programadores e administradores cresce a partir da substituição de conceitos:

• desenvolvimento → codificação;
  
• suporte → administração de serviços de aplicativos.
  

Inclinar a estrutura de subordinação em uma base profissional (e não funcional) sempre leva a conflitos. Como regra, administradores e programadores trabalham em equipes completamente diferentes, e às vezes departamentos, e são motivados como operação e desenvolvimento, respectivamente.

Como resultado, programadores do departamento de desenvolvimento que são "forçados" a consertar bugs antigos ou, Deus permita, escrever documentação, ficam descontentes. Os administradores da operação também estão indignados, a quem é solicitado que jogue rapidamente um piano de cauda para criar um novo servidor para desenvolvedores ou ajudá-los com conselhos.

Cada uma das partes percebe isso não como uma solução conjunta para o problema, mas como uma distração de suas próprias tarefas, que não são visíveis mesmo sem esse fim.

Mas não devemos esquecer o cliente, porque ele, embora indiretamente, também é participante do conflito. Como regra, ele precisa obter um serviço estável e estabelecido. Um código simples, mesmo o melhor, é completamente inútil para o cliente fora do sistema. Ele basicamente tem uma imagem diferente do mundo:



Um cliente padrão não tem uma tarefa para criar, escrever ou, desculpe, Senhor, implementar. O cliente deseja resolver um problema de negócios usando o botão mágico "Faça tudo bem", enquanto a TI impõe que ele oferece uma solução específica.

Vamos dar uma olhada em todos os lados do conflito:



Obviamente, essa é apenas a parte mais comum dos requisitos funcionais e operacionais.

Então, descobrimos que ainda existem três partes no conflito : desenvolvimento, operação e cliente. Além disso, é o cliente que é em grande parte um "provocador", compartilhando a responsabilidade entre as equipes. Isso por si só não é ruim e, se não fosse a separação geralmente aceita de equipes e responsabilidades entre elas, seria um conflito gerenciável.

Mas já sabemos que ambos os serviços não são auto-suficientes. Eles são separados por uma barricada de "serviço" e, ao mesmo tempo, devem não apenas interagir entre si no campo da transferência de responsabilidade, de acordo com as etapas da vida do produto, mas também participar ativamente na solução dos problemas um do outro.

Outro aspecto da influência do cliente é sua estratégia e metodologia de desenvolvimento de negócios. Nesse caso, estou falando de não entender como é o processo de desenvolvimento de uma solução de TI específica. Sem essa compreensão, o cliente geralmente exige que um gato seja uma baleia e, em seguida, prenda asas nela. E sempre tudo é urgente. Às vezes, isso é justificado pela situação e pela inovação da ideia; às vezes, é uma consequência da disputa pelo líder de mercado e pela cópia apressada. Os motivos podem ser muito diferentes, mas o resultado é um.

O problema é que essa estratégia se traduz em experimentos constantes e na necessidade de obter resultados no menor tempo possível. Essa abordagem nos lança no abismo do desenvolvimento contínuo, em vez do trabalho que visa a um resultado específico. Em princípio, o último problema é resolvido pelos arquitetos corporativos, mas você não encontrará esses caras à tarde com fogo.

Processos de desenvolvimento

Finalmente, quase chegamos ao ponto em que tudo estava acontecendo. Qual é a chave para as operações de serviço?

1. Transparência das melhorias. Para gerenciar as mudanças, você precisa entender o que, como e por que isso foi feito.
   
2. Documentação sobre a lógica do trabalho e manutenção. Idealmente, na forma de instruções. A chave para a conformidade com o SLA não é apenas a confiabilidade, mas também um entendimento claro do que e como fazer, o que deve estar presente para todos os artistas. O “conhecimento oral” não é adequado aqui - muitas vezes as pessoas trabalham em turnos de operação, e é simplesmente impossível coletar tudo e explicar tudo. E a memória em uma situação estressante (e um acidente é sempre estresse) pode falhar.
   
3. Um procedimento de transferência claro em suporte à nova versão com teste de suas características operacionais e o correto funcionamento do funcional. De uma maneira simples - regressão e teste de estresse. A funcionalidade simples da nova funcionalidade excita o mínimo possível a operação: a própria equipe de desenvolvimento corrigirá a falha na liberação da garantia. Mas o erro introduzido na funcionalidade antiga, a operação deve, se não eliminar por conta própria, pelo menos processar, às vezes provar a culpa do desenvolvimento.
   
4. Uma oportunidade de transferir seus requisitos para o trabalho de um novo projeto. É o desenvolvimento que apresenta as características operacionais mais importantes. Por exemplo, se o software não souber trabalhar em um cluster, a operação não poderá torná-lo verdadeiramente confiável de forma independente.
   

O que é o serviço de operação e por que é importante para alguém como a equipe de desenvolvimento trabalha, descobrimos isso. Vamos para a parte mais interessante - analisaremos várias metodologias de desenvolvimento e seu impacto no serviço de operação.

Vamos começar com os clássicos: modelos em cascata.

Cachoeira

A Waterfall está focada em oferecer funcionalidade completa e sofisticada. O modelo de liberação é cíclico. O ciclo leva de várias semanas (extremamente raras) a trimestres e seis meses. Quase sempre há uma coleção consistente de requisitos, análise, desenvolvimento de uma arquitetura de solução, avaliação de sua duração, planejamento e testes de regressão completos no final.

A conformidade com os interesses da operação depende da implementação específica. Como as etapas necessárias geralmente são destacadas, o processo envolve levar em consideração todos os requisitos e procedimentos formais para a transferência para a operação, incluindo a documentação.

Os principais problemas do Waterfall para o cliente são a duração das iterações e a estabilização prolongada após o lançamento. Às vezes, o cliente é forçado a esperar vários meses antes que um produto apareça no produto que precisa de uma semana para ser criado.

Se o resultado estiver longe do esperado, o cliente terá que perseverar até o final de um novo ciclo, ou até dois. Regularmente em seu lugar é o serviço de operação. E a funcionalidade técnica costuma ser a última da fila.

Cada versão grande é acompanhada por uma pilha de erros, que são eliminados durante o período de estabilização. Geralmente isso se transforma em um inferno para todas as partes - o desenvolvimento é forçado a se envolver na exploração, a operação aceita incidentes e empurra seu desenvolvimento para garantir a eliminação por todos os meios, e o cliente, olhando para toda essa bagunça e dinheiro perdido, arranca seus cabelos.

Apesar de tudo isso, do ponto de vista da operação, o Waterfall é o processo metodológico mais uniforme e previsível no qual você pode integrar. Em geral, nem a duração do ciclo, nem a estabilização da operação estão particularmente preocupadas. Quanto mais tempo passa entre os lançamentos, mais tempo você pode trabalhar com calma - e isso é sempre uma vantagem. Além disso, quando há confiança de que nada mudará por mais seis meses, é muito mais fácil inserir seu trabalho no processo.

Infelizmente, muitas vezes os clientes se opõem à Waterfall e exigem acelerar o desenvolvimento do projeto. Para esse desejo, nascem metodologias mais flexíveis.

Ágil

Como você entende, o Waterfall é muito longo, formal e envolve toneladas de documentação, nas quais todos sempre traem . E o cliente exige tudo de uma vez. Como resposta a esses problemas, os programadores criaram um manifesto Agile:

● Pessoas e interação são mais importantes que processos e ferramentas.
É difícil argumentar com isso. Claro, as pessoas são mais importantes. Mas não se esqueça dos processos. São os processos que padronizam e regulam a interação. Além disso, apenas em público você não irá longe. No mínimo, as pessoas gostam de ficar doentes, relaxar e às vezes desistem.

● Um produto em funcionamento é mais importante que a documentação abrangente.
Isto também é verdade. Mas há outra pergunta: quão bem e por quanto tempo o produto funcionará sem documentação? Muito provavelmente, não muito tempo. Mas é bom ou não - não vai funcionar devido à falta da fonte. E então você terá que seguir as táticas pelas quais muitos se apaixonaram "Eu não consegui descobrir - reescrever do zero". Mas é sempre longo, caro e geralmente não é um fato que o resultado seja melhor.

● A colaboração com o cliente é mais importante do que negociar os termos do contrato.
E, novamente, sim, mais importante. Mas como, sem acordo com os termos do contrato, entenderemos o que e como fazer? De que outra maneira superar o mal-entendido mútuo, exceto como se comunicar e concordar através de um documento claramente definido? Obviamente, o contrato também não é uma panacéia, mas é muito mais confiável que o método dos anos 90:

- Vasya, você me entende?
- Bem, como sim, irmão.

● A preparação para a mudança é mais importante do que seguir o plano original.
Mas isso é verdade apenas em um caso: se o plano inicial era um log completo e o que eles planejavam criar, não era necessário. Você oferece um arquiteto corporativo em todas as mãos!

O resultado de seguir cegamente esse manifesto é que o próprio cliente da empresa precisa se transformar em um arquiteto corporativo (mas, na maioria das vezes, ele se transforma em uma abóbora). Não apenas isso não é um "funcional" inerente a ele, mas também é necessário entender a TI.

Scrum

O Scrum é uma das primeiras tentativas de adaptar a Cachoeira à ideologia do manifesto Agile.
As principais características do scrum:

• Trabalhe em sprints curtos. A composição do sprint após seu início não é editada;
  
• Planeje colocando Histórias de usuários individuais no registro de desejos do sprint. No proprietário do projeto - uma escolha no "log do projeto";
  
• Os interesses do cliente são representados pelo proprietário do projeto (Product Owner);
  
• A equipe de desenvolvimento é composta por especialistas de diferentes perfis: programadores, desenvolvedores, arquitetos, analistas. A equipe é responsável pelo resultado como um todo;
  
• Substituímos a documentação e a correspondência pelas discussões diárias do projeto por toda a equipe.
  

Em teoria, essa é uma abordagem bastante robusta e, de várias maneiras, se assemelha a uma versão em miniatura do Waterfall. Os problemas começam a surgir na fase de implementação. Infelizmente, o SCRUM, devido ao seu ciclo mais curto, provoca a divisão de toda a função em partes separadas e a entrega da função em partes, mesmo na fase de planejamento do sprint. Fico em silêncio sobre o fato de que, por esse motivo, tudo pode dar errado já durante a "corrida". Sprints curtos não deixam tempo para o estoque gerencial e torna-se extremamente difícil sair.

Como resultado da redefinição da prioridade constante de um recurso em sua forma finalizada, ele pode muito rapidamente entrar na produção. Além disso, na fase de criação da UserStory, é extremamente difícil avaliar o impacto da funcionalidade planejada no sistema final, pois seu estado não é conhecido antecipadamente no momento em que essa funcionalidade aparece.

Como isso ameaça a exploração? Nem sempre é claro o que deve funcionar, o que não deve e, se funcionar, quando. Consequentemente, há uma substituição do teste do sistema pelo teste da função, pois a regressão normal levará muito tempo. Isso adiciona bugs ao produto e atrasa sua solução.

Para operação normal, a operação deve:

• Participar de reuniões do SCRUM;
  
• Constantemente ciente das situações de trabalho do desenvolvimento;
  
• Conheça os planos de desenvolvimento e libere status.
  

Caso contrário, será impossível ganhar tempo com a aceitação ou fazer comentários. Obviamente, a exploração é extremamente rara em seguir todos esses pontos e, se o fizer, leva a uma escalada do conflito. Mesmo um proprietário do produto durante uma reunião do SCRUM pode ignorar míope os interesses de suporte.

Kanban

O próximo passo na evolução das metodologias de desenvolvimento é o Kanban. Os já curtos ciclos de SCRUM também pareciam muito longos para os negócios. Você pode entender o cliente: você sempre quer ser o primeiro a obter o chip mais bacana. Sim, e mudar de plano é ineficiente, resulta um pouco "indireto".
Então, como dizem os construtores, é mais fácil "esculpir no lugar".

Kanban é uma implementação de TI da metodologia japonesa de manufatura enxuta. Mas há uma nuance: na Toyota, usando o Kanban, os carros são montados a partir de peças pré-projetadas, enquanto o desenvolvimento é principalmente o design. Na programação, as funções de peça são simplesmente copiadas; elas não precisam ser constantemente "produzidas".

O Kanban geralmente anda de mãos dadas com os processos de CI / CD. Não há sprints aqui, as tarefas são entregues continuamente quando estão prontas, há restrições estritas no tamanho de tais tarefas. Por esse motivo, funcionalidades complexas de forma integral quase nunca são entregues, uma vez que não se encaixam no tamanho da tarefa.

Nessas condições, a documentação para o sistema realmente se torna obsoleta antes de ser escrita e perde todo o sentido, pois é impossível fixar algum estado do sistema produzido (ou seja, produzido, mas não desenvolvido) no qual isso seria verdade.

Para operação, isso significa a incapacidade de fornecer SLA: não há documentação e ninguém sabe como o sistema funciona e como deve funcionar.

Previsibilidade e garantia de operação contínua são a base da implementação do SLA.

No entanto, com essa abordagem, geralmente não há serviço operacional, apenas uma equipe de desenvolvimento que é periodicamente distraída por reparos e (às vezes) por “dívida técnica”. Mas ninguém está preocupado por causa disso, pois os planos não quebram. É difícil atrapalhar o que não é.

Conforme estabelecido pelos autores do processo original, o Kanban é ideal para operações nas quais o planejamento é substituído por uma resposta a estímulos. Por exemplo, é assim que o trabalho com incidentes se assemelha; se ele quebrar, nós o corrigiremos. Na maioria dos casos, por um procedimento conhecido. No entanto, o Kanban é completamente inadequado para o desenvolvimento, pois implica mal o resultado final. A escolha dessa metodologia o condenará a um processo interminável - "construímos, construímos e ainda estamos construindo". Não faça isso!

Devops

Obviamente, o DevOps não é uma metodologia de desenvolvimento, mas não posso deixar de inserir meus cinco copeques e não falar sobre a tentativa mais comum de resolver um conflito de operação e desenvolvimento.

Em teoria, o DevOps é um conjunto de práticas destinadas à interação ativa de especialistas em desenvolvimento com especialistas em tecnologia da informação e à integração mútua de seus processos de trabalho entre si.

O DevOps é baseado na ideia de estreita interdependência do desenvolvimento e operação de software e visa ajudar as organizações a criar e atualizar rapidamente produtos e serviços de software. Novamente sobre criação e atualização rápidas. Mas explorar esses problemas não existe.

Como resultado, o DevOps se torna um meio de tornar a equipe de desenvolvimento independente do serviço de operação, completando o link de desenvolvimento necessário. Obviamente, essa solução em si é unilateral e resolve o problema para apenas uma das partes - o desenvolvimento. Geralmente, isso só agrava o conflito, permitindo que o desenvolvimento ignore completamente a operação do serviço.

Na prática, na maioria das vezes me deparei com duas implementações:

• A equipe de administradores de operações é mantida e engajada em produtiva.
  

-, . , , , , , .

• , « — ».
  

. . DevOps-, , — . , .

, DevOps — , , , , , . . , SLA . () .

— . , . , .
DevOps , , , . - , , .

?

: , .
: -. - — , - .
: , , . , , .

DevOps — , . , , .

. !