Describiendo SRE y DevOps en 5 puntos clave
La división de responsabilidades entre un SRE y un DevOps es muy borrosa, si bien hay muchos que defienden que DevOps no es un cargo, es una cultura, o una metodología de trabajo, cada vez vemos más anuncios de “Se Solicita DevOps”. Cargo que termina ocupando alguien que viene de ser SysAdmin, Desarrollador, Redes o hasta un implementador de Telecomunicaciones.
Tan novedoso es que se confunde la responsabilidad a tomar, por eso paso por acá a resaltar los principios básicos de un SRE/DevOps, reflejándolo en 5 pilares:
1.Reducir Silos Organizacionales: El concepto de “silos” en las empresas y organizaciones se entiende como la incapacidad para trabajar eficientemente entre las áreas o unidades de negocio que las integran. La ausencia de una buena comunicación, de un feedback claro y frecuente, o una escasa orientación por parte del líder y del equipo puede traer no solo un mal ambiente laboral sino que los procesos no sean eficientes y las expectativas no sean cumplidas. Podemos reducir estos silos rompiendo barreras entre los equipos y resaltar la colaboración de unos con los otros.
No somos competencia entre nosotros, somos un equipo, si a ti te va bien, a mi también. Pues tanto el departamento de Infraestructura como los desarrolladores y mercadeo compartimos el éxito del producto final.Todos debemos tener la misma visión y enfoque al trabajar en producción.
La metodología DevOps está muy relacionada con las metodologias Ágiles, de hecho, DevOps es una metodología ágil aplicada más allá del equipo IT. En scrum, cada retrospectiva es una oportunidad para mejorar las prácticas y las herramientas. Pero si el equipo no aprovecha esas oportunidades para solucionar problemas técnicos tanto a corto como a largo plazo, simplemente optarán por reemplazar al personal que consideran ineficiente, sin encontrar realmente la causa raíz. eso no solucionará nada.
2. Aceptar accidentes y fallas como normales: Las computadoras son poco confiables, no puedes esperar la perfección, además cuando introducimos humanos en el sistema debemos esperar más imperfección aún. Cuando hay fallas (que siempre las habrá) en vez de culpar a la persona que presionó el botón o corrió el script, se deben revisar los procesos, si la persona siguió el procedimiento que tenía en mano y el script funcionó perfectamente en otras instancias, entonces el error no es de la persona, ni en el script, es del procedimiento que dejó a esa instancia sin mantenimiento y fuera de soporte. por decir un ejemplo.
Independientemente de lo que descubramos, entendemos y verdaderamente creemos que todos hicieron el mejor trabajo posible con base en lo que se sabía en el momento, los recursos disponibles y la situación dada.
Podemos hacer un análisis de causa raís (RCA) o post mortem sin castigar culpables. Sino que nos aseguramos que los accidentes o fallas no pasen de la misma manera exacta más de una vez. Y si hay fallas que se toman como normales pues se maneja un presupuesto de error dentro del cual es aceptable una caída del sistema.
3. Implementar Cambios Gradualmente: No son solo cambios pequeños e incrementales que serían más fáciles de revisar, sino además en caso de que cause una interrupción de servicio en producción nos tomará menos tiempo recuperar el servicio y hacer un rollback pequeño y simple.
Evitar el “BigBang deployment” y preferir implementaciones graduales como Canary o Blue-Green deployment.
Todos necesitamos al menos 3 o 4 ambientes, llámese lab, desarrollo, staging y producción, cada uno es más estricto que el anterior, así como los cambios deben ser graduales, tambien deben moverse de a poco de un ambiente al siguiente para evitar interrupciones o disminución de la calidad de servicio.
4.Usar herramientas y automatizar: Tratamos de eliminar el trabajo manual y repetitivo lo más posible. Revisamos cuanto trabajo en emergencia (toil) tenemos y tratamos de automatizar estas tareas con scripts de Bash, Ansible, Gitlab CI, Jenkins, levantar contenedores automáticamente con kubernetes o cualquier otra herramienta.
Hoy en día no hay razón para tener un grupo de ingenieros las 24 horas del día, los 7 días de la semana, reiniciando o escalando manualmente los contenedores de Docker cuando tenemos Kubernetes.
Kubernetes es un software libre que gestiona los contenedóres Docker atomáticamente via Liveness, Readiness and Startup Probes y HPA, por ejemplo. Todas estas tareas recurrentes se pueden reemplazar por una herramienta que haga ese trabajo sin intervención humana.
5. Medir Todo: las métricas del sistema y del talento humano son un indicador fundamental para el éxito, de nada sirve tomar las métricas y no evaluarlas. Sin una manera de medir la evolución de los cuatro pilares anteriores no vamos a tener manera de saber como va. Debemos medir el tiempo de falla, la escalabilidad, la cantidad de trabajo del personal y salud de los sistemas.
En los equipos Scrum, se usan dos conjuntos de métricas, La primera refiere a la calidad, medida por los recuentos de defectos y el número de tickets de producción emitidos. El segundo es el desempeño del trabajo, medido en velocidad.
Si no usamos las metodologías Scrum, no vamos a tener una base clara de calidad/velocidad del trabajo, sólo nos queda la impresión personal subjetiva, no-objetiva sin evidencias.
Conclusión
SRE y DevOps son dos caras de una misma moneda, además la entrega continua a la que se refiere CI/CD se aplica fundamentalmente al principio de la metodología ágil “Nuestra máxima prioridad es la satisfacción del cliente mediante la entrega temprana y continua de software de gran valor.”
El objetivo común es derribar barreras organizacionales y entregar un mejor Software más rápido.
Si pensamos en DevOps como una filosofía, el objetivo del SRE es llevar a cabo esa filosofía, el SRE implementa DevOps y no necesariamente se implementan las cosas de la misma manera exacta de como lo hacen en otras organizaciones.
HD De León Barrios
Fuente: https://www.youtube.com/watch?v=uTEL8Ff1Zvk
