Cómo dejamos la subcontratación y creamos nuestro propio equipo DevOps eficaz / Sudo Null IT News

Mi nombre es Kirill Shagin, dirijo los equipos SRE, DevOps y DBA en Vi.Tech, una subsidiaria de VI.ru. En nuestras soluciones de TI utilizamos una pila moderna, tenemos 4 clusters K8S y más de un millón de pipelines por mes.

En este artículo, comparto mi experiencia sobre cómo construimos nuestro equipo DevOps eficaz y gradualmente dejamos de subcontratar la mayoría de nuestros servicios. Por supuesto, no fue posible construir los procesos en un día y ni siquiera en el primer intento. Adoptamos una variedad de enfoques para lograr nuestros objetivos de desempeño. Como resultado, algunos fueron abandonados, mientras que otros se implementaron y todavía se utilizan hasta el día de hoy. Lea todo sobre esto debajo del corte.

Cómo llegamos a la subcontratación

Cuando la empresa era pequeña, implementamos versiones con la ayuda de varios equipos, pero esto no duró mucho a medida que el negocio y la infraestructura crecían. En algún momento nos dimos cuenta de que era necesario implementar prácticas de DevOps. Implementamos un clúster de Kubernetes y colocamos en él todos los servicios existentes en ese momento. Sin embargo, no teníamos suficiente experiencia para configurar adecuadamente todo el sistema. En este punto, decidimos buscar ayuda de especialistas con experiencia.

Los ingenieros subcontratados configuraron “cubos”, canalizaciones de CI/CD y comenzaron a implementar prácticas modernas de DevOps. Como resultado, identificamos 2 tareas permanentes que se realizaban mediante subcontratación:

1. Ayudando a los desarrolladores con los problemas actuales (de turno).

2. Resolver tareas planificadas por los equipos de desarrollo (“expandir”, “elevar”).

Tres años después comenzaron los problemas…

A medida que la empresa crecía, aumentaba el número de desarrolladores y, junto con esto, crecía el número de nuevos servicios y tareas planificadas. Para continuar haciendo el trabajo de manera efectiva, tendríamos que ampliar nuestro equipo de subcontratación, lo que requeriría fondos adicionales que no teníamos.

El resultado son tareas atrasadas, desarrolladores y objetivos fallidos. Para salir de alguna manera de la situación, el equipo de desarrollo comenzó a realizar algunas de las tareas por sí mismo. Esto llevó a todo un zoológico de tecnologías, ya que los desarrolladores no profundizaron en las prácticas de DevOps y completaron las tareas rápidamente, dependiendo de cómo se busque en Google.

Le quitamos las tareas rutinarias a un subcontratista

Cuando decidimos asumir las funciones de servicio, teníamos los siguientes datos de entrada:

1. Un equipo de seis personas (5 ingenieros y 1 jefe de equipo).

2. Todos los ingenieros deben estar de servicio.

3. No existen procesos obligatorios, por lo que hay que “seguir el sentimiento”.

Los procesos no estaban regulados, las tareas se distribuían caóticamente y no se respetaba la cola, por lo que se perdían algunas tareas. Además, los tiempos de respuesta y resolución de problemas no cumplieron con las expectativas del cliente.

Para resolver la situación, describimos el proceso de turno, según el cual el ingeniero realiza las siguientes acciones:

1. Asume una tarea.

2. Establece el estado en “en trabajo”.

3. Resuelve el problema.

4. Lo que no tuvo tiempo de hacer lo completa al siguiente día hábil.

5. Después de resolver el problema, actualiza la documentación.

Utilizando Grafana OnCall y Slack, automatizamos el proceso de contacto con el oficial de turno. El desarrollador escribió al canal Slack y el bot envió al oficial de servicio un mensaje que contenía el texto de la tarea y un enlace al hilo.

¿Está funcionando bien el nuevo proceso de obligaciones?

Después de introducir el nuevo proceso de deberes, analizamos su efectividad. Como resultado, se identificaron los siguientes problemas:

• la automatización no registra aplicaciones;

• no estaba claro cómo transferir solicitudes entre turnos de trabajo;

• y nuevamente, las expectativas de los clientes no coincidieron con la realidad. Por ejemplo, un desarrollador podría conectarse el domingo y pedir ayuda, pero nadie le respondió.

Para resolver estos problemas, primero que nada, mejoramos el bot. Lo conectamos con sistemas de aplicaciones: Jira SM y YouTrack. Las solicitudes creadas para el oficial de turno provinieron de Jira y las tareas planificadas se registraron en YouTrack. También prescribimos regulaciones para trabajar con tareas, que contenían 10 reglas. Una de estas reglas: el oficial de guardia responde solo a las solicitudes del bot en las que el cliente ha indicado prioridad. Cuando un cliente creaba una tarea en Slack, aparecían botones: “incidente” o “programado”.

Otra regla importante es que las solicitudes deben resolverse una por una, de las antiguas a las nuevas, para que no se pierdan tareas. También prescribimos regulaciones internas para ingenieros:

• el servicio se realiza todos los días de 09:00 a 09:00 del día siguiente;

• Un ingeniero no debería tener más de dos turnos seguidos;

• el oficial de guardia fue relevado de reuniones que no estuvieran relacionadas con los incidentes.

Para resolver el problema de la discrepancia entre las expectativas de los desarrolladores y el trabajo real de los encargados de las solicitudes, redactamos regulaciones externas. Contenía las siguientes condiciones:

• el oficial de servicio de lunes a viernes de 09:00 a 18:00 (hora de Moscú) resuelve las solicitudes que provienen de un bot en Slack;

• de lunes a viernes de 18:00 a 09:00 y los fines de semana, el oficial de guardia realiza tareas únicamente en respuesta a incidentes en el entorno del supermercado;

• por la noche, el oficial de servicio no descubre la raíz del problema, solo elimina el impacto del incidente;

• El deber se lleva a cabo en todos los entornos: producción y desarrollo.

Como resultado de las mejoras en el proceso, se resolvió el problema de la transferencia de solicitudes entre turnos. Cuando a un asistente le quedaba una hora en su turno, pasaba esas tareas al siguiente asistente de turno. También hay un recuento de solicitudes y su distribución en categorías. Ahora el deber no era un conjunto caótico de acciones, sino un proceso claro y consistente.

¿Qué más podría salir mal?

Había más gente en la empresa y al mismo tiempo aumentó el número de solicitudes. Recibimos 500 tareas por mes. Además, también aumentó la cantidad de especialistas en DevOps en nuestro equipo; necesitaban estar inmersos en la infraestructura, los procesos y la adaptación. Por lo tanto, era necesario compartir conocimientos.

Los clientes tienen mayores exigencias en cuanto a la calidad y velocidad de resolución de solicitudes. Y además, nos empezaron a llegar tareas que no estaban en nuestra área de responsabilidad. Por ejemplo, en lo que respecta a los problemas con el funcionamiento de VPN, esta es tarea de un departamento completamente diferente.

Respuestas a llamadas recientes

Para resolver estos problemas hicimos lo siguiente:

• Para compartir conocimientos, creamos un chat para los oficiales de servicio en Slack, donde un ingeniero puede encontrar respuestas en el historial o preguntar a sus colegas en línea;

• Para cumplir con los requisitos de los clientes en cuanto a calidad y rapidez en la resolución de problemas, introdujimos indicadores SLA: respuesta a un problema – 2 horas, solución – 1 hora;

• Para el correcto enrutamiento de aplicaciones de acuerdo con el área de responsabilidad, hemos modificado el bot. Ahora, usando un botón en Slack, el bot envió la aplicación a la primera línea, donde los especialistas pueden distribuir correctamente la aplicación.

• Para realizar un seguimiento de la eficiencia de los ingenieros, introdujimos las siguientes métricas:

  • tiempo dedicado a resolver la solicitud;

  • número de devoluciones al oficial de servicio dentro de una tarea;

  • Supervisamos los plazos de verificación de la solución del problema por parte de los solicitantes.

Ahora nos lleva 1 hora resolver el problema y el tiempo de reacción es menos de una hora.

Las últimas mejoras al proceso nos dieron los siguientes resultados:

• Ahora podemos prometer un tiempo de respuesta específico a las solicitudes durante el turno de trabajo;

• existen métricas verificadas para solicitudes de turnos de trabajo;

• entendemos los tipos de problemas que la gente nos presenta y qué se puede automatizar;

• vemos claramente puntos de crecimiento;

• Entendemos en qué momento es necesario aumentar el número de personas de guardia para que los indicadores de SLA no se vean afectados.

Le quitamos las tareas planificadas al subcontratista

Para asumir las tareas planificadas, necesitábamos resolver los siguientes problemas:

• cómo recopilar requisitos de los desarrolladores;

• cómo 5 ingenieros pueden atender a 20 equipos de desarrollo (más de 200 personas) con diferentes pilas;

• desmontar el zoológico a partir de tecnologías en tuberías, herramientas de montaje y entrega.

Implementamos sprints de dos semanas que se realizaron todos los miércoles. Dentro del sprint hay dos llamadas con clientes. En la primera llamada discutimos la prioridad de la tarea y en la segunda informamos sobre el progreso del sprint.

La pila quedó como un equipo subcontratado y se negaron a apoyar y desarrollar las herramientas que el equipo de desarrollo había acumulado.

A continuación, fue necesario recopilar comentarios sobre nuestro trabajo. Y luego nos encontramos con obstáculos inesperados.

Historias divertidas sobre la recopilación de sistemas operativos

Para recopilar comentarios, se tuvieron que responder las siguientes preguntas:

• ¿Qué preguntar?

• ¿A quién debo preguntar?

• ¿Qué formato de encuesta debo utilizar?

El líder de nuestro equipo desarrolló una encuesta detallada que cubrió todos nuestros casos. Decidimos involucrar a los jefes de departamento y direcciones como encuestados. Consideramos que los líderes son la fuente primaria de metas. Y de las metas, por regla general, surgen las tareas planificadas. La encuesta fue compilada en Google Forms.

La encuesta pedía calificar los siguientes indicadores en una escala del 1 al 10:

• La velocidad para completar las tareas planificadas.

• La calidad del cumplimiento de sus tareas planificadas.

• Nivel de información sobre el estado de tus tareas.

También fue necesario dar una respuesta detallada sobre lo que me gustaría mejorar en el trabajo del equipo DevOps.

Crearon una encuesta, ahora todos la tomarán y contarán todo.

Enviamos una encuesta, fijamos una fecha límite y comenzamos a esperar comentarios. Recordado periódicamente sobre cómo completar la encuesta. Pero al llegar a la fecha límite, sólo 2 personas completaron la encuesta. Era imposible realizar un análisis basado en una base de datos de este tipo. Por ejemplo, cuando se le preguntó sobre la velocidad con la que se completaban las tareas, un encuestado calificó con 2 y el segundo con 10.

Segundo intento de recopilar SO.

Tiramos los formularios de Google, nos armamos con un bolígrafo y una hoja de papel y acudimos personalmente a los líderes del equipo. Y se programaron reuniones en línea con los empleados que trabajan de forma remota. Como resultado de la conversación, no quedó más claro. Recibimos requisitos que no proporcionan detalles: “hazlo bien”, “hazlo bien” y “hazlo ayer”.

La evolución de la colección de SO.

Cerramos el tema con encuestas, que venimos desarrollando persistentemente durante 5 meses. Durante este tiempo, el departamento de DevOps ha crecido 3 veces. Por lo tanto, identificamos 3 áreas y asignamos un equipo de DevOps independiente a cada una:

• Dirección del grupo: personas mayores y líderes;

• Dirección de bancos de pruebas: medios;

• Dirección CI/CD: middles y juniors.

Decidimos que si la recopilación del sistema operativo de los clientes no funciona, recopilaremos datos basados ​​en estadísticas. Lo primero sobre lo que comenzamos a recopilar estadísticas fue el tiempo que la tarea pasó en estado. Para la medición, los estados se dividieron en 2 grupos: “influimos en el tiempo en el estado” y “no influyemos en el tiempo en el estado”. Escribimos un exportador en Go y utilizamos la API para capturar datos de YouTrack. La información recibida se recopiló en Victoria Metrics y se mostró en Grafana.

Para utilizar correctamente los datos recopilados, creamos contenedores de basura para las operaciones y “coloreamos” los gráficos. Esta vez obtuvimos una imagen real de nuestro trabajo. Y esto no nos hizo muy felices: todos los gráficos estaban en rojo.

Recibimos los siguientes indicadores de las aplicaciones:

• El camino desde la “solicitud creada” hasta la “evaluación aprobada”: 30 días, percentil 50;

• El camino de “en progreso” a “bloqueado en el cliente” es de 8,77 días, percentil 50 y 18,3 días, percentil 99;

• El camino desde la creación de la tarea hasta su finalización es de 47,5 días, percentil 50 y 354 días, percentil 99;

• El camino desde “en progreso” hasta “en espera de revisión” es de 14 días, percentil 99 y 7 días, percentil 50.

Trabajando en indicadores en la zona roja.

En primer lugar, comprobamos cómo se evaluaron las tareas. Descubrimos que los ingenieros de la dirección CI/CD, donde trabajaban los de nivel medio y junior, estaban dando una valoración incorrecta. También descubrimos un problema en la redacción de las tareas. Como antes, los desarrolladores establecieron tareas abstractas. Por ejemplo: “implemente de forma rápida y eficiente, con Postgres y en 3 DC”.

Dos problemas más son estados de tareas incorrectos y una gran cantidad de solicitudes en estado de Revisión de código. Es decir, la tarea está completada, pero se requiere la verificación del solicitante para cerrarla. Como sabes, a todo el mundo le encanta crear, pero a pocas personas les gusta probar. Como resultado, la mayoría de nuestras tareas permanecieron en estado de control y permanecieron sin realizar ninguna acción durante mucho tiempo.

Para solucionar estos problemas hemos tomado las siguientes medidas:

• Detalles agregados a los estados:

  • Expectativas del departamento del centro de datos;

  • Esperando pruebas por parte del desarrollo: estamos esperando la verificación de los desarrolladores;

  • Esperando una respuesta: estamos esperando respuestas a nuestras preguntas;

• Tomamos el control de Code Review. Diariamente recordamos personalmente quién debe comprobar qué tareas.

• Creamos un límite en la cantidad de tareas en el estado de Revisión de código. Si un cliente tiene 2 tareas con estado de verificación, sus nuevas solicitudes no se aceptan para trabajar hasta que complete estas verificaciones.

Métricas resumidas

Como resultado de la implementación de las últimas mejoras, recibimos las siguientes métricas:

¿Qué ha cambiado en los procesos?

• Recopilamos tareas en un sprint estrictamente hasta un tiempo determinado. Si los clientes quieren que sus tareas se incluyan en el sprint, deben preparar las tareas antes del viernes.

• Preparamos estimaciones para las tareas recopiladas el día antes del inicio del sprint. Para que no haya situaciones en las que los clientes vengan a priorizar, pero la tarea no tenga evaluación.

• Realizamos el trabajo preparatorio inmediatamente, en lugar de esperar a la planificación.

• Realizamos sincronizaciones de equipos 2 veces al día. Esto ayuda al líder del equipo a rastrear qué tareas establecieron los ingenieros al principio y qué objetivos establece el líder del equipo, y qué sucede al final del día. Esto acorta el ciclo de retroalimentación y permite tomar decisiones rápidas.

• Estaba prohibido cambiar de sprint sobre la marcha.

• Los tiempos de los sprints estaban estrictamente fijados.

• Dejaron la oportunidad de presentar una solicitud sin evaluación. Pero luego, de forma predeterminada, le asignamos una estimación: todo el sprint.

¿Qué fue automatizado?

• En “cubos” y en máquinas virtuales, creamos una medida de recursos asignados, en “camisetas” (s, m, l, xl, xxl). Ahora los equipos pueden entenderse fácilmente entre sí al nombrar las computadoras.

• Empaquetamos todo lo que estaba en el radar técnico en la función de Ansible.

• Creamos un generador de libros de jugadas. Le ayuda a convertir los roles de Ansible en manuales, lo que le permite implementar con solo cuatro botones.

• Plantillas de implementación creadas en Terraform. Ahora solo quedan archivos de configuración en los repositorios de servicios.

• Usamos el CDK de Terraform para brindar a los desarrolladores la configuración yml. Esto le permite limitar la imaginación de los desarrolladores para que no “cerquen” nada más allá de yml.

Resultados de la implementación de nuevos procesos

• El camino desde la creación de la solicitud hasta la evaluación es de 20 horas en lugar de 30 horas;

• Desde la evaluación hasta la implementación: 20 horas en lugar de 45 días;

• Realizar una revisión del código: 3,5 horas en lugar de 7 días.

Basado en mi experiencia, me gustaría dar el siguiente consejo:

1. Automatiza la interacción con tu equipo. De lo contrario tendrás que:

• Cada vez, explique al cliente todas las complejidades del proceso de trabajo con el departamento de DevOps: “vaya allí”, “haga clic aquí”, “haga esto”.

• controlar que el cliente cumpla con todas las partes del proceso;

• Corregir errores en las tareas asignadas para el cliente.

Ahora nuestro cliente sólo necesita presionar un botón para implementar el servicio. Al presionar un botón en DevOps, se crean automáticamente 4 tareas, que ya son asumidas por los ingenieros correspondientes.

2. Las encuestas solo funcionan junto con estadísticas que usted mismo debe recopilar.

3. Mida todas las etapas del trabajo en las tareas.

4. Céntrate en mejorar aquellas etapas sobre las que tienes influencia directa.

5. Las tareas que se descomponen lo más posible ayudan a estar siempre incluidas en la evaluación. Por ejemplo, si la tarea estimada es de 10 horas, significa que no está lo suficientemente descompuesta. Ahora nuestra tarea máxima en un sprint es de 6 horas.

6. La automatización es la clave para reducir las calificaciones. Porque eliminamos el factor humano, las repeticiones, la posibilidad de error y simplificamos la vida de nuestros compañeros.