Hola Habr! Y nuevamente Alexey Pristavko está en contacto.

A diferencia de mis artículos anteriores, hoy hablaremos de personas. Los héroes del día son el servicio de operaciones, cuyos intereses represento, y el servicio de desarrollo.

El trabajo coordinado de estos servicios es la clave para un lanzamiento exitoso y un "vuelo" fluido del servicio creado. Pero, como lo demuestra mi experiencia (y no solo), prácticamente ningún proyecto puede prescindir de conflictos y desacuerdos, cuya víctima es un servicio inocente.

En este artículo intentaré responder las siguientes preguntas:

• ¿Cómo afectan los procesos y los métodos de desarrollo a las operaciones?
• ¿Qué impulsa a cada lado del conflicto?
• ¿Cuál es la causa raíz del desacuerdo?

¡Bienvenido a cat!

¿Cuáles son los desafíos que enfrentan los servicios?

Conoceremos mejor los departamentos y comenzaremos con el servicio de operación (también es un servicio de soporte). ¿Por qué se necesita esta terrible bestia, qué tarea realiza y "para quién" funciona?

La tarea principal del servicio operativo es administrar el nivel de servicios, es decir, mantener el funcionamiento del sistema de TI dentro del marco de SLA.
La operación debe proporcionar acceso constante al servicio y su correcto funcionamiento en el marco de un acuerdo con el cliente, generalmente con el negocio.

Aquí está la solución a este problema:

• Gestión de incidentes: restauración de la función comercial durante un accidente;
  
• Gestión de problemas: abordar las causas probables de accidentes e incidentes;
  
• Gestión de configuración: recopilación de información y análisis de software y parámetros de operación de infraestructura;
  
• Gestión del cambio: minimizando el riesgo de problemas y accidentes durante los cambios.
  

El papel del servicio de desarrollo también es comprensible: la creación inicial de un servicio de TI y la introducción de nuevas funcionalidades a pedido del cliente.

Seguramente, ya tiene sospechas sobre los puntos de fricción de los desarrolladores y el soporte, porque donde hay intersecciones de tareas, hay conflictos. Pero no se apresure a sacar conclusiones. El eterno debate entre desarrolladores y administradores está lejos del epicentro de las "batallas".

¿Dónde crecen los desacuerdos?

La "guerra" de programadores y administradores no es una confrontación de intereses humanos, es una confrontación de servicios.



El problema radica en las prioridades y la motivación de estos mismos servicios. En su forma más general, esto se puede describir de la siguiente manera:

• El equipo de desarrollo quiere usar la tecnología de primera frescura (desarrollo profesional, interés) y hacer el trabajo lo más rápido posible (motivación externa).
  

• La operación está interesada en las tecnologías más estables (sus problemas son conocidos y tienen soluciones generalmente aceptadas) y explicaciones detalladas de qué hacer en caso de problemas en el software desarrollado (motivación externa para la velocidad de la resolución de problemas).
  

Al mismo tiempo, es importante comprender que no solo los desarrolladores "vieron" nuevas funcionalidades y no siempre los administradores exclusivamente elevaron a los caídos.

• Los administradores participan activamente en el proceso de desarrollo: en la construcción de infraestructura, tolerancia a fallas y esquemas de escalabilidad, en la preparación de configuraciones iniciales e idealmente en el proceso de preparación de requisitos de software. Todo esto se llama un proceso de desarrollo de soluciones (¡no lo confunda con la escritura directa de código!).
  

• Los programadores participan activamente en la operación. Corrigen errores de software, realizan optimizaciones del sistema y mejoras técnicas para cumplir con el sistema SLA, es decir, resuelven el problema de accesibilidad del servicio de TI final.
  

El conflicto entre programadores y administradores surge de la sustitución de conceptos:

• desarrollo → codificación;
  
• soporte → administración de servicios de aplicaciones.
  

La inclinación de la estructura de subordinación sobre una base profesional (en lugar de una base funcional) siempre conduce a conflictos. Como regla general, los administradores y programadores trabajan en equipos completamente diferentes, y a veces departamentos, y están motivados como operación y desarrollo, respectivamente.

Como resultado, los programadores del departamento de desarrollo que están "obligados" a corregir errores antiguos o, Dios no lo quiera, escribir documentación, no están contentos. Los administradores de la operación también están indignados, a quienes se les pide que arrojen rápidamente un piano de cola para crear un nuevo servidor para desarrolladores o ayudarlos con consejos.

Cada una de las partes percibe esto no como una solución conjunta al problema, sino como una distracción de sus propias tareas, que no son visibles incluso sin ese fin.

Pero no debemos olvidarnos del cliente, porque él, aunque indirectamente, también es un participante en el conflicto. Como regla, necesita obtener un servicio establecido y estable. Un código simple, incluso el mejor, es completamente inútil para el cliente fuera del sistema. Básicamente tiene una imagen diferente del mundo:



Un cliente estándar no tiene una tarea para crear, escribir o, lo siento, Señor, implementar. El cliente quiere resolver un problema de negocios usando el botón mágico "Hacer todo bien", mientras que TI impone que ofrece una solución específica.

Echemos un vistazo a todos los lados del conflicto:



Por supuesto, esta es solo la parte más común de los requisitos funcionales y operativos.

Entonces, descubrimos que todavía hay tres partes en el conflicto : desarrollo, operación y el cliente. Además, es el cliente quien es en gran medida un "provocador", que comparte la responsabilidad entre los equipos. Esto en sí mismo no es malo, y si no fuera por la separación generalmente aceptada de los equipos y las responsabilidades entre ellos, sería un conflicto manejable.

Pero ya sabemos que ambos servicios no son autosuficientes. Están separados por una barricada de "servicio" y, al mismo tiempo, no solo deben interactuar entre ellos en el campo de la transferencia de responsabilidad de acuerdo con las etapas de la vida del producto, sino que también deben participar activamente para resolver los problemas de los demás.

Otro aspecto de la influencia del cliente es su estrategia y metodología de desarrollo empresarial. En este caso, estoy hablando de no entender cómo es el proceso de desarrollo de una solución de TI específica. Sin tal comprensión, el cliente a menudo exige hacer de un gato una ballena y luego colocarle alas. Y siempre todo es urgente. A veces esto se justifica por la situación y la innovación de la idea, a veces es consecuencia de la carrera por el líder del mercado y la copia apresurada. Las razones pueden ser muy diferentes, pero el resultado es uno.

El problema es que dicha estrategia se traduce en experimentos constantes y la necesidad de obtener resultados en el menor tiempo posible. Este enfoque nos arroja al abismo del desarrollo continuo en lugar del trabajo dirigido a un resultado específico. En principio, el último problema lo resuelven los arquitectos empresariales, pero no los encontrarás por la tarde con fuego.

Procesos de desarrollo

Finalmente, casi llegamos al punto en que todo estaba a la altura. ¿Cuál es la clave para las operaciones de servicio?

1. Transparencia de las mejoras. Para gestionar el cambio, debe comprender qué, cómo y por qué se hizo.
   
2. Documentación sobre la lógica de trabajo y mantenimiento. Idealmente, en forma de instrucciones. La clave para cumplir con el SLA no es solo la confiabilidad, sino también una comprensión clara de qué y cómo hacer, que debe estar presente para todos los artistas. El "conocimiento oral" no es adecuado aquí: muy a menudo las personas trabajan en turnos de operación, y es simplemente imposible recopilar todo y explicar todo. Y la memoria en una situación estresante (y un accidente siempre es estrés) puede fallar.
   
3. Un claro procedimiento de transferencia en apoyo de la nueva versión con pruebas de sus características operativas y el correcto funcionamiento de la funcional. De manera simple: regresión y pruebas de estrés. La funcionalidad simple de la nueva funcionalidad estimula la operación en la menor medida: el equipo de desarrollo en sí mismo solucionará el lanzamiento fallido de la garantía. Pero el error introducido en la funcionalidad anterior, la operación debería, si no eliminar por sí sola, y al menos procesar, a veces probar la culpabilidad del desarrollo.
   
4. Una oportunidad para transferir sus requisitos al trabajo de un nuevo proyecto. Es el desarrollo el que establece las características operativas más importantes. Por ejemplo, si el software no sabe cómo trabajar en un clúster, la operación no podrá hacerlo de forma independiente realmente confiable.
   

¿Cuál es el servicio de operación y por qué es importante para alguien cómo funciona el equipo de desarrollo? Pasemos a la parte más interesante: analizaremos las diversas metodologías de desarrollo y su impacto en el servicio operativo.

Comencemos con los clásicos: modelos de cascada.

Cascada

Waterfall se centra en ofrecer una funcionalidad completa y sofisticada. El modelo de lanzamiento es cíclico. El ciclo lleva desde varias semanas (extremadamente raro) hasta trimestres y seis meses. Casi siempre hay una colección consistente de requisitos, su análisis, desarrollo de una arquitectura de solución, evaluación de su duración, planificación y pruebas de regresión completas al final.

El cumplimiento de los intereses de operación depende de la implementación específica. Dado que las etapas necesarias generalmente se destacan, el proceso implica tener en cuenta todos los requisitos y procedimientos formales para la transferencia a la operación, incluida la documentación.

Los principales problemas La cascada para el cliente es la duración de las iteraciones y la larga estabilización después del lanzamiento. A veces, el cliente se ve obligado a esperar varios meses antes de que aparezca un producto en el producto que necesita una semana para crearse.

Si el resultado está lejos de lo esperado, el cliente tendrá que aguantar hasta el final de un nuevo ciclo, o incluso dos. Regularmente en su lugar está el servicio de operación. Y la funcionalidad técnica suele ser la última en la línea.

Cada lanzamiento grande se acompaña de una pila de errores, que se eliminan durante el período de estabilización. Por lo general, se convierte en un infierno para todas las partes: el desarrollo se ve obligado a participar en la explotación, la operación acepta incidentes y empuja su desarrollo para garantizar la eliminación por todos los medios, y el cliente, al mirar todo este desastre y perder dinero, se arranca el pelo.

A pesar de todo esto, desde el punto de vista de la operación, Waterfall es el proceso metodológico más uniforme y predecible en el que puede integrarse. En general, ni la duración del ciclo, ni la estabilización de la operación están particularmente preocupados. Cuanto más tiempo pase entre lanzamientos, más tiempo podrá trabajar con calma, y ​​esto siempre es una ventaja. Además, cuando existe la confianza de que nada cambiará durante otros seis meses, es mucho más fácil ingresar su trabajo en el proceso.

Desafortunadamente, muy a menudo los clientes se oponen a Waterfall y exigen acelerar el desarrollo del proyecto. En aras de este deseo, nacen metodologías más flexibles.

Ágil

Como comprenderá, Waterfall es mucho tiempo, formalmente y conlleva toneladas de documentación, en la que todos siempre hacen trampa . Y el cliente requiere todo a la vez. Como respuesta a estos problemas, a los programadores se les ocurrió un manifiesto ágil:

● Las personas y la interacción son más importantes que los procesos y las herramientas.
Es difícil discutir con eso. Por supuesto, las personas son más importantes. Pero no te olvides de los procesos. Son los procesos que estandarizan y regulan la interacción. Además, solo en público no irás lejos. Como mínimo, a las personas les gusta estar enfermas, relajarse y, a veces, dejar de fumar.

● Un producto que funciona es más importante que la documentación completa.
Esto también es verdad. Pero hay otra pregunta: ¿qué tan bien y por cuánto tiempo funcionará el producto sin documentación? Lo más probable, no muy largo. Pero es bueno o no, no funcionará debido a la falta de la fuente. Y luego tendrás que seguir las tácticas de las que muchos se han enamorado: "No pude resolverlo, reescribir desde cero". Pero siempre es largo, costoso y, en general, no es un hecho que el resultado resulte mejor.

● La colaboración con el cliente es más importante que el acuerdo sobre los términos del contrato.
Y de nuevo, sí, más importante. Pero, ¿cómo sin un acuerdo sobre los términos del contrato entenderemos qué y cómo hacer? ¿De qué otra manera superar los malentendidos mutuos, excepto cómo comunicarse y ponerse de acuerdo a través de un documento claramente definido? Por supuesto, el contrato tampoco es una panacea, pero es mucho más confiable que el método de los años noventa:

- Vasya, ¿me entiendes?
- Bueno, como si, hermano.

● La preparación para el cambio es más importante que seguir el plan original.
Pero esto es cierto solo en un caso: si el plan inicial era un registro completo y lo que planeaban construir, resultó que nadie lo necesitaba. ¡Le das un arquitecto empresarial en cada mano!

El resultado de seguir ciegamente este manifiesto es que el cliente comercial tiene que convertirse en un arquitecto empresarial (pero la mayoría de las veces, se convierte en una calabaza). No solo no es un "funcional" inherente a él, también es necesario comprenderlo.

Scrum

Scrum es uno de los primeros intentos de adaptar Waterfall a la ideología del manifiesto Agile.
Las principales características de scrum:

• Trabaja en carreras cortas. La composición del sprint después de su inicio no se edita;
  
• Planificación al poner historias de usuarios individuales en el registro de deseos de sprint. En el propietario del proyecto: una opción del "registro del proyecto";
  
• Los intereses del cliente están representados por el propietario del proyecto (Propietario del producto);
  
• El equipo de desarrollo está formado por especialistas de diferentes perfiles: programadores, desarrolladores, arquitectos, analistas. El equipo es responsable del resultado en su conjunto;
  
• Reemplazamos la documentación y la correspondencia con discusiones diarias del proyecto por todo el equipo.
  

En teoría, este es un enfoque bastante robusto, y en muchos aspectos se asemeja a una versión en miniatura de Waterfall. Los problemas comienzan a surgir en la etapa de implementación. Desafortunadamente, SCRUM, debido a su ciclo más corto, provoca la división de la función completa en partes separadas y la entrega de la función en partes, incluso en la etapa de planificación del sprint. Estoy en silencio sobre el hecho de que por esta razón todo puede salir mal durante la "carrera". Los sprints cortos no dejan tiempo para el stock administrativo y se vuelve extremadamente difícil salir.

Como resultado de la constante re-priorización de una característica en su forma final, muy pronto puede entrar en producción. Además, en la etapa de escribir UserStory es extremadamente difícil evaluar el impacto de la funcionalidad planificada en el sistema final, ya que su estado no se conoce de antemano en el momento en que aparece esta funcionalidad.

¿Cómo amenaza esto la explotación? No siempre está claro qué debería funcionar, qué no, y si funciona, cuándo. En consecuencia, hay una sustitución de las pruebas del sistema por las pruebas de función, ya que la regresión normal tomará mucho tiempo. Esto agrega errores al producto y retrasa su solución.

Para el funcionamiento normal, el funcionamiento debe:

• Participar en las reuniones SCRUM;
  
• Constantemente consciente de las situaciones laborales del desarrollo;
  
• Conozca los planes de desarrollo y los estados de lanzamiento.
  

De lo contrario, será imposible ganar tiempo con la aceptación o hacer comentarios. Por supuesto, la explotación es extremadamente rara para seguir todos estos puntos, y si lo hace, conduce a una escalada del conflicto. Incluso un propietario de producto durante una reunión SCRUM puede ignorar miope los intereses de soporte.

Kanban

El siguiente paso en la evolución de las metodologías de desarrollo es Kanban. Los ciclos SCRUM ya cortos también parecían demasiado largos para el negocio. Puedes entender al cliente: siempre quieres ser el primero en obtener el chip más genial. Sí, y cambiar de plan es ineficiente, resulta demasiado "sobrecarga".
Entonces, como dicen los constructores, es más fácil "esculpir en el lugar".

Kanban es una implementación de TI de la metodología japonesa de fabricación ajustada. Pero hay un matiz: en Toyota, usando Kanban, los automóviles se ensamblan a partir de piezas prefabricadas, mientras que el desarrollo es principalmente diseño. En la programación, las funciones parciales simplemente se copian, no necesitan ser constantemente "producidas".

Kanban generalmente va de la mano con los procesos de CI / CD. Aquí no hay sprints, las tareas se entregan de forma continua ya que están listas, hay restricciones estrictas sobre el tamaño de dichas tareas. Debido a esto, la funcionalidad compleja en una forma integral casi nunca se entrega, ya que no se ajusta al tamaño de la tarea.

En tales condiciones, la documentación para el sistema realmente se vuelve obsoleta antes de que se escriba, y pierde todo sentido, ya que es imposible arreglar algún estado del sistema producido (es decir, producido, pero no desarrollado) en el que sería cierto.

Para la operación, esto significa la incapacidad de proporcionar SLA: no hay documentación y nadie sabe cómo funciona el sistema y cómo debería funcionar.

La previsibilidad y la garantía de operación continua son la base de la implementación de SLA.

Sin embargo, con este enfoque, generalmente no hay servicio operativo, solo un equipo de desarrollo que se distrae periódicamente por reparaciones y (a veces) por “deuda técnica”. Pero nadie está preocupado por esto, ya que los planes no se rompen. Es difícil interrumpir lo que no es.

Según lo establecido por los autores del proceso original, Kanban es ideal para operaciones en las que la planificación se reemplaza por una respuesta a los estímulos. Por ejemplo, así es como se ve el trabajo con incidentes: si se rompe, lo solucionaremos. En la mayoría de los casos, por un procedimiento conocido. Sin embargo, Kanban es completamente inadecuado para el desarrollo, ya que implica poco el resultado final. La elección de esta metodología lo condenará a un proceso interminable: "construimos, construimos y aún estamos construyendo". ¡No hagas eso!

Devops

Por supuesto, DevOps no es una metodología de desarrollo como tal, pero no puedo evitar insertar mis 5 kopecks y no hablar sobre el intento más común de resolver un conflicto de operación y desarrollo.

En teoría, DevOps es un conjunto de prácticas destinadas a la interacción activa de especialistas en desarrollo con especialistas en tecnología de la información y la integración mutua de sus procesos de trabajo entre sí.

DevOps se basa en la idea de una estrecha interdependencia del desarrollo y la operación del software y tiene como objetivo ayudar a las organizaciones a crear y actualizar rápidamente productos y servicios de software. Nuevamente sobre creación y actualización rápidas. Pero explotar estos problemas no existe en absoluto.

Como resultado, DevOps se convierte en un medio para hacer que el equipo de desarrollo sea independiente del servicio de operación completando el enlace de desarrollo necesario. Obviamente, esta solución en sí misma es unilateral y resuelve el problema solo para una de las partes: el desarrollo. A menudo, esto solo exacerba el conflicto, permitiendo que el desarrollo ignore por completo la operación del servicio.

En la práctica, a menudo encuentro dos implementaciones:

• El equipo de administradores de operaciones se mantiene y se dedica a la productividad.
  

-, . , , , , , .

• , « — ».
  

. . DevOps-, , — . , .

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

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

?

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

DevOps — , . , , .

. !