¿Cuáles son los signos y señales típicas de un equipo de DevOps que carece de personal suficiente? ¿Cómo justificaría / explicaría una solicitud de una nueva incorporación a un equipo?

Me encantaría mantener la pregunta genérica, pero aquí hay información adicional:

Actualmente contamos con 2 especialistas de DevOps que trabajan juntos como un equipo, pero las demandas y la cantidad y complejidad de los productos están creciendo. Estamos pensando en solicitar una nueva incorporación al equipo, pero tenemos algunas dificultades para explicar y demostrar por qué sería una buena idea.

Hay cuatro razones principales por las que puede sentir que su equipo no tiene suficiente personal:

1. Mala organización y planificación del trabajo.
2. Trabajando, alguien más debería estar haciendo
3. Hacer un trabajo que no debe hacerse en absoluto.
4. Estar realmente sin personal

Comience con una revisión de los primeros tres puntos. Lea el proyecto Phoenix sobre ideas sobre cómo hacer lo primero. Pregúntese por cada tarea con la que ayude a cualquier persona si debe hacerse y si es usted quien debe hacer la tarea o si simplemente debe permitir que quien lo necesite lo haga por sí mismo. Esto le dará cierta documentación sobre por qué es necesario todo el trabajo que realiza.

A continuación, revise los cuatro tipos de trabajo mencionados en el proyecto Phoenix:

1. Proyectos empresariales : lo que haces para otros equipos de la organización
2. Proyectos internos : qué hacer para facilitar su trabajo en el futuro
3. Mantenimiento programado : qué hacer para mantener las luces encendidas
4. Interrupciones no planificadas : lo que haces porque algo salió mal

Si el trabajo de su equipo es sostenible, pasará aproximadamente la misma cantidad de tiempo en cada uno de los cuatro. Si el trabajo no planificado comienza a aumentar cerca del 50% de su tiempo, es una señal de que definitivamente no tiene suficiente personal.

Debería poder contratar a una persona para adelantarse al trabajo no planificado que alcanza el 25% de su tiempo, de lo contrario, una persona que se vaya enviará a todo su equipo a una caída en picada de la que quizás nunca se recupere. El exceso de aprovisionamiento de personas y tecnología tiene los mismos motivos y beneficios.

Antecedentes: además de brindar soporte a nuestra infraestructura actual y a nuestros Desarrolladores, hacemos una planificación mensual como equipo de DevOps para lo que queremos lograr además de ayudar a los equipos de desarrollo dentro de los sprints y los nuevos proyectos que se lanzan. Sin embargo, durante el mes a menudo notamos cosas adicionales que deben hacerse y mejorarse, que luego agregamos a nuestra cartera de pedidos. También somos responsables y ayudamos con otras cosas que están más allá de nuestro alcance, pero ayudamos al negocio donde podamos :)

Respuesta : Tan pronto como se dé cuenta de que no está realizando o posponiendo muchas tareas, especialmente el mantenimiento, creo que es un buen indicador (por lo que he experimentado). Además, cuantos más nuevos proyectos y equipos de desarrollo se presenten, más delgado será el equipo de DevOps, más personas necesitará.

Es muy fácil quedar atrapado en el día a día completando tareas, pero creo que es muy importante (incluso una vez al mes) dar un paso atrás y evaluar esto.

De hecho, tomo una página del Manual SRE sobre este, que creo que es muy relevante. Las especialidades de DevOps no están destinadas a crecer horizontalmente con una organización. Más bien, si ve que las cosas no se están haciendo, entonces es una señal de que no está capacitando adecuadamente a los desarrolladores para el autoservicio.

Evalúe sus procesos y vea cómo se alinean con los Principios DevOps comúnmente aceptados y qué tan bien está siguiendo las mejores prácticas de la industria.

Supongo que este equipo de dos personas va de proyecto en proyecto y establece cosas de DevOps allí (creando canalizaciones de CI / CD, apoyando a los otros desarrolladores que crean Dockerfiles, o cualquier tecnología que esté usando). En otras palabras, escriba 3, 4, 5 o 6 según http://web.devopstopologies.com/ .

En este caso, una señal de escasez es simplemente demasiada carga de trabajo para esos dos; demasiados proyectos solicitando sus servicios; demasiados boletos; tiempo extraordinario; estrés, agotamiento. Estos factores deberían ser razones suficientes para que un liderazgo responsable agregue más capacidad. No veo un signo específico de DevOps en esto, es solo una función con poco personal.

Otra señal para cambiar algo es si le echas un buen vistazo y si notas que estás creando un "silo de DevOps", en el que todo el know-how de DevOps se concentra en esos dos chicos / chicas, y todos los demás simplemente se recuestan porque esos dos están "haciendo DevOps". Ese no es el punto de DevOps. Si este es el caso, piense en el aspecto cultural y modifíquelos para que sean más evangelistas / maestros / entrenadores para los otros equipos.

En ambos casos, la razón más profunda de por qué tener DevOps en primer lugar es algo bueno (lo bueno en general) debería estar claro para la alta dirección. Si no puede transmitir ese mensaje, reduzca la escala del trabajo que está haciendo su equipo, cambiándolo a los Devs / Ops regulares (como debería ser el caso, de todos modos).

Tenía la impresión de que DevSecOps era una mentalidad, no un equipo: si tienes un "equipo" de Dev (Sec) Ops, lo estás haciendo mal ... Estoy tratando de entender cómo poner a dos "Ingenieros de DevOps" juntos y llamándolos un "Equipo de DevOps".

Tenemos equipos de desarrollo, SCM, ingenieros de sistemas y seguridad de aplicaciones, todos trabajando en conjunto para un modelo de implementación / lanzamiento rápido para llevar el código y la configuración / cambios del sistema a un punto final dado, ya sea en etapas o en producción.

Esto no tiene nada que ver con ningún ingeniero "devOps", como tal.

Agrupación de tareas

Un enfoque que hemos usado en el pasado en situaciones similares es organizar el trabajo de un equipo en 4 grupos principales de tareas y asignar el equivalente a 2 FTE (equivalentes a tiempo completo) para (intentar) completar esas tareas. En nuestro caso, estaba relacionado con la ejecución de un servicio de asistencia SCM en un entorno mainframe, con unos 300 desarrolladores que solicitaron todo tipo de ayuda / intervenciones de esos 2 FTE. Los grupos de tareas se organizan en 4 posibles prioridades:

• Deben completarse las tareas de prioridad 1 y 2 (no es posible excusas / negociaciones)
• Las tareas de la Prioridad 3 deben completarse " tan pronto como el tiempo lo permita".
• Las tareas de la prioridad 4 deben completarse " si el tiempo lo permite".

Siga leyendo para obtener más detalles sobre el tipo de tareas en cada uno de esos 4 grupos ...

Descripciones de tareas

Prioridad 1 - Operar el servicio de asistencia

• Por expertos de fácil acceso y siempre disponibles.
• Por teléfono, correo electrónico o sistema de tickets durante el horario comercial.
• Cumple con los SLA predefinidos.
• Registro basado en ITIL de todas las llamadas al servicio de asistencia con informes periódicos de todas las llamadas.
• Aplique personalizaciones de emergencia (soluciones alternativas) para problemas críticos.

Prioridad 2 - Vigilar los servicios de guardia

• Disponibilidad 24 horas al día, 7 días a la semana.
• Cumple con los SLA predefinidos.
• Informe de todas las llamadas de guardia.
• Escalada de gestión donde sea necesario.

Prioridad 3: mantenimiento de rutina

• Administración.
• Solicitud de embarque.
• Limpieza interna.
• Mejoras de rendimiento.
• Administracion del espacio.
• Ajuste del consumo de recursos.
• Sugerir mejoras para las personalizaciones para reducir la cantidad de llamadas al servicio de asistencia y / o ver las intervenciones de servicio.

Prioridad 4: correcciones y mejoras

• Crear y mantener la documentación del usuario.
• Prueba de control de calidad de nuevas personalizaciones.
• Desarrollar e implementar solicitudes de mejora.
• Participe en las pruebas de DRP.

Evaluación

Si está utilizando un enfoque como se describió anteriormente, pueden comenzar a suceder varias cosas (¡lo harán!):

• Si el equipo no tiene suficiente personal, probablemente la mayoría de las veces irá a las tareas de prioridad 1 y 2, mientras que puede llevar un tiempo obtener las tareas de prioridad 3 ... y las tareas de prioridad 4 pueden sufrir hambre (parece que nunca habrá tiempo para esas tareas).
• Cuanto más haya (se convierta) en tiempo disponible para " invertir " en tareas de prioridad 4, se reducirá más tiempo necesario para las tareas de prioridad 1 y 2, de modo que se pueda "invertir" aún más tiempo (del presupuesto disponible de 2 ETC) "en prioridad 4 tareas.
• Te sorprenderá ver cómo, después de un tiempo, el número de tareas de prioridad 1 y 2 disminuirá. Y si hace un informe adecuado sobre esas tareas, eso es algo que a la gerencia le encanta escuchar. En nuestro caso, ese número bajó de aproximadamente 300 / mes a menos de 100 / mes ...
• Sin embargo, si parece que los 2 FTE nunca tienen (o apenas) tiempo para las tareas de prioridad 4, entonces tiene una explicación perfecta y prueba de su gestión ... de que no tiene suficiente personal.