Header Ads Widget

Ticker

6/recent/ticker-posts

¿Qué es la ingeniería de confiabilidad del sitio (SRE)?

 



El funcionamiento de una organización es tan importante como la propia empresa. La forma en que se estructuran los equipos y los métodos que emplean para llevar a cabo su trabajo es vital para el producto final. Para mejorar la eficacia, la eficiencia y la calidad, las empresas de software adoptan enfoques como DevOps y Site Reliability Engineering , dos paradigmas que se emplean actualmente en toda la industria.

Hoy, veremos estos paradigmas. Haremos una inmersión profunda en la Ingeniería de confiabilidad del sitio ( SRE ) e identificaremos algunas diferencias y similitudes centrales con DevOps. Finalmente, veremos algunas situaciones específicas en las que cualquiera es apropiado.

¿Qué es la ingeniería de confiabilidad del sitio?

SRE se acuñó por primera vez en 2003 en Google como un impulso hacia la confiabilidad . Cuando Google pidió a sus ingenieros de software que dieran prioridad a la confiabilidad mientras trabajaban colectivamente hacia los objetivos de eficiencia y escalabilidad, se necesitaban nuevos enfoques para resolver las debilidades subyacentes en los paradigmas tradicionales. Con el tiempo, estos enfoques se fusionaron en la Ingeniería de confiabilidad del sitio como práctica general, con un enfoque principal en el aprovechamiento de la automatización , las herramientas y los procesos.

A medida que SRE evolucionó, se agregaron al libro de jugadas de SRE soluciones como el monitoreo de guardia , la automatización para la planificación y el escalado de la capacidad y la planificación de la respuesta a desastres . Estos y un concepto general de automatización hacia las resoluciones se convirtieron en facetas centrales del enfoque de SRE. En términos básicos, SRE se trata de mejorar la confiabilidad y eficiencia operativa. Ben Traynor, vicepresidente de ingeniería de Google y fundador de Google SRE, señaló la esencia del rol de SRE en esta entrevista :

“Básicamente, SRE está realizando un trabajo que históricamente ha sido realizado por un equipo de operaciones, pero utilizando ingenieros con experiencia en software y confiando en el hecho de que estos ingenieros están predispuestos inherentemente y tienen la capacidad de sustituir el trabajo humano por la automatización. En general, un equipo de SRE es responsable de la disponibilidad, la latencia, el rendimiento, la eficiencia, la gestión de cambios, la supervisión, la respuesta a emergencias y la planificación de la capacidad ".

Idealmente, los SRE deberían automatizar su trabajo : el estándar de oro de un SRE. SRE, como práctica general, también combina confiabilidad con empatía : el equipo debe ser empático y consciente de los otros grupos, deseando trabajar junto a ellos para lograr los objetivos de ambos equipos y mejorar el sistema en su conjunto.

¿Dónde se encuentra la SRE en una organización?

En paradigmas más antiguos, los desarrolladores se centraban principalmente en la agilidad y pasaban su código a través de una barrera a los operadores, que se centraban en la estabilidad. Por lo tanto, las operaciones habían reducido la comprensión del código base y el desarrollo tenía poco conocimiento de las operaciones, lo que provocó tensión. DevOps, como principio, fue diseñado para romper este ciclo a través de un enfoque en la colaboración, cambios graduales, el desarrollo de herramientas y ofertas de automatización y mediciones útiles. Si bien esto fue útil, todavía se centró en la facilitación de la comunicación entre dos fuerzas distintas y opuestas.

SRE, por otro lado, está destinado a ser el siguiente paso de DevOps que supere este proceso de pensamiento. Google ve SRE como una implementación de DevOps: en este enfoque, Desarrollo y Operaciones son lo mismo, y su co-funcionalidad se trata más de alineación que de facilitación. Primero, utilizan canarios para realizar pruebas en una base de usuarios más pequeña, emplean la automatización y desarrollan métodos y prácticas adicionales para una medición más eficiente . En última instancia, SRE es una forma más avanzada y pensada de DevOps que pretende resolver las trampas tradicionales de DevOps.

Debido a que los grupos a menudo implementan SRE como un híbrido entre Desarrollo y Operaciones, en la mayoría de las organizaciones, aquí es donde se encuentra. Sin embargo, en la práctica, SRE puede existir en varios lugares. Puede vivir como parte de diversos órganos de proyectos, como su propio departamento o incluso como un proceso de gestión de alto nivel. La SRE puede ocupar cualquier lugar de la organización siempre que esta ubicación no interfiera con las tareas básicas del rol que supervisa.

Debemos señalar que existe una realidad tácita que viene con la aplicación de la SRE a cada aspecto de la organización. Si bien estas aplicaciones de base amplia se pueden encontrar en adopciones instintivas, terminan colocando tanto Desarrollo, Operaciones y SRE al mismo nivel. Dependiendo de la implementación, esto puede causar los mismos problemas que se suponía que SRE debía resolver. Si el esfuerzo es adecuadamente colaborativo, esto es un problema menor, pero aún es algo a considerar cuando se considera la asignación práctica de SRE en la organización.

La SRE puede tener enfoques variados. Infrastructure SRE, por ejemplo, tiende a centrarse casi por completo en mejorar las herramientas y los procesos de infraestructura, los equipos de productos se limitan a un segmento comercial y una oferta de empresa muy limitados, los equipos de herramientas se centran casi por completo en el desarrollo de software en torno a la confiabilidad, etc. La realidad es que La SRE no debe verse como una opción de gestión de equipos plug and play, sino como un espíritu y un paradigma.

Beneficios de SRE

SRE ofrece importantes beneficios organizativos y prácticos. En primer lugar, SRE se centra casi obsesivamente en la confiabilidad : está en el nombre. Este enfoque en la confiabilidad en toda la implementación significa que se minimizan los gastos operativos, se alivian y mitigan los puntos de falla y se automatizan las funciones repetidas que desperdician tiempo y recursos. Todo esto junto da como resultado un gran ahorro económico .

Aquí se pueden obtener incluso mayores ganancias en precisión y eficiencia , especialmente porque el factor humano para tareas repetidas se elimina y se reemplaza con procesamiento automatizado. Una ventaja importante de la implementación de SRE es el cambio cultural hacia la resolución de fallas . La SRE se preocupa mucho más por identificar las causas de falla desde el principio que por abordar los síntomas y mitigarlos de manera integral.

La confiabilidad se convierte en el rey en lugar de la funcionalidad y, como tal, el enfoque se vuelve mucho más en la entrega que en el producto. Estos problemas pueden resolverse mucho antes de que se conviertan en un problema dentro de la SRE. El sistema debe entenderse necesariamente antes de que cualquier cosa pueda automatizarse y, como tal, los problemas a menudo se encuentran y mitigan antes de que ocurran; incluso cuando ocurren, las soluciones de mitigación se identifican y preparan, lo que permite una respuesta rápida y una función altamente confiable.

Otro gran beneficio de SRE es la capacidad de ofrecer propiedad y distribuir la experiencia de manera efectiva. Un ejemplo de esto se puede encontrar en los esfuerzos realizados por Poppulo . Al escalar, Poppulo encontró una preocupación común en el crecimiento del producto distribuido en una base constante de experiencia:

“Hasta ahora, el trabajo requerido para crear y mantener nuestra plataforma y nuestras responsabilidades de confiabilidad se repartía entre nuestros equipos. A medida que escalamos, descubrimos que la experiencia se distribuye demasiado en todo el departamento ".

Al difundir su experiencia en un mayor número de ofertas de productos en lugar de centrarse en las preocupaciones fundamentales subyacentes de la confiabilidad y la eficiencia, estos atributos se ven afectados negativamente; más aún, hace que los equipos no puedan realmente tomar posesión de su producto o aprovechar su talentos en una dirección positiva general. Al tener que usar tantos sombreros en una amplia franja, todo el conjunto se ve afectado negativamente. Poppulo resolvió esto adoptando enfoques organizacionales de SRE:

Nuestros equipos de productos seguirán siendo responsables de implementar sus propios servicios, monitorearlos y ejecutarlos en producción. Este es el mejor lugar para vivir esta responsabilidad. Sin embargo, a medida que crecemos, concentrar nuestra experiencia en confiabilidad y desarrollo de plataformas nos permitirá desarrollar ambos de manera más efectiva. La confiabilidad y nuestra plataforma son preocupaciones de primera clase y deben ser tratadas con el respeto que merecen.

Todo esto se suma a una confiabilidad significativamente mayor. Una mayor confiabilidad significa menos tiempo de inactividad, personal adicional disponible, la capacidad de reducir las llamadas fuera del horario de atención (al mismo tiempo que lo respalda de manera efectiva a través de la automatización), etc. Esto no solo tiene importantes beneficios económicos, sino que también genera una mejor moral en la empresa y una mayor confianza en la marca.

Inconvenientes de SRE

Sin embargo, existen algunos inconvenientes en el enfoque de SRE. Quizás el más grande es que todavía es un concepto relativamente no probado. DevOps, por el contrario, es una opción bien probada y endurecida que es tan común como se entiende. SRE, por otro lado, es todavía relativamente reciente y tiene una tasa de adopción más baja. Como tal, no está tan probado y las correcciones a las múltiples grietas potenciales pueden no ser obvias.

La SRE también tiene una debilidad en su requisito de una gestión fuerte y directiva. Debido a que SRE tiene una línea muy delgada en términos de implementación y lógica de negocios, es muy fácil para un equipo de SRE "salirse del camino", por así decirlo. La única solución a esto es un órgano de administración más fuerte, que puede resultar en microgestión y pérdida de eficiencia.

También hay una gran preocupación en que SRE sea una posición de hundimiento de habilidades. Querer todo en una sola persona o equipo significa que el listón se establece ridículamente alto para esos puestos y, como tal, hace que la contratación sea mucho más difícil. Si bien esto es un problema menor para un equipo que pasa de un proceso establecido a SRE, donde es probable que los conjuntos de habilidades ya existan y simplemente estén esperando ser combinados, los nuevos equipos deben cumplir con esta alta meta desde el primer día.

SRE vs DevOps: elegir un paradigma

Todo esto se reduce a una simple pregunta: ¿qué opción es mejor para una organización determinada? SRE y DevOps son opciones valiosas y no existe una rúbrica realmente clara mediante la cual una organización pueda elegir una sobre la otra.

Por supuesto, debe considerarse que la adopción de SRE significará más gestión, nuevos procesos y, en general, un liderazgo divergente. Esto tiene su propio costo en términos de oportunidad, pero también puede requerir una nueva contratación. Esto puede afectar los objetivos presupuestarios y, como tal, cualquier adopción de este tipo deberá considerarse dentro de ese contexto.

Gran parte de la naturaleza de SRE y DevOps requiere una comprensión de dónde se encuentra realmente la organización en sus operaciones diarias. Debido a que SRE es un gran cambio cultural, a menudo es mejor que lo adopten nuevas organizaciones u organizaciones que no se han hundido en sus respectivas posiciones de DevOps. Del mismo modo, DevOps es una buena opción para las organizaciones que aún tienen que elegir, pero que ya están gravitando hacia una relación similar a DevOps.

Quizás la métrica más fácil para juzgar la idoneidad de cualquiera de las soluciones es el resultado deseado. SRE se centra principalmente en la confiabilidad, por lo que las soluciones de interfaz de usuario activa a largo plazo se beneficiarán al máximo de SRE. Los resultados impulsados ​​por productos o con un solo propósito se benefician más de DevOps.

Conclusión

En última instancia, la elección entre SRE y DevOps es una elección de idoneidad para el resultado final. El resultado determinará la opción que elija, aunque debe tenerse en cuenta que existen costos asociados, tanto en términos monetarios como en términos de productividad y eficiencia, que deben abordarse independientemente de la opción elegida.

También debe tenerse en cuenta aquí que la SRE a menudo se considera una implementación de "moda" - si bien puede ser cierto que la SRE a menudo se adopta como una reacción instintiva al paradigma de jure, la realidad es que tiene un gran valor en el derecho situación, y se puede aprovechar para entregar ese valor a una organización preparada para cosecharlo. Como tal, las organizaciones deben tener cuidado de no tratar la SRE como una moda pasajera, ya sea negativa o positivamente, y en su lugar pensar en ella como una herramienta más en la gran caja de herramientas API. ¿Qué opinas de SRE? ¿Su valor es exagerado? Háganos saber en los comentarios a continuación.

Publicar un comentario

0 Comentarios