Buenas tardes a todos!
La intensidad de nuestros lanzamientos varía de mes a mes. Antes de que los estudiantes de septiembre terminaran el segundo mes del curso
"Devops - Prácticas y herramientas" , estamos abriendo la próxima secuencia. Así que estamos nuevamente listos para compartir materiales útiles sobre el tema con usted y estamos esperando
lecciones abiertas no menos útiles.
Hoy veremos la primera parte del artículo sobre cómo la documentación permite a los equipos de SRE administrar servicios nuevos y existentes.
SRE (ingeniería de confiabilidad del sitio, traducida aproximadamente como "garantizar la confiabilidad de los sistemas de información", los especialistas en este campo llevan la misma abreviatura): una disciplina especial, pensamiento y un conjunto de enfoques técnicos destinados a garantizar el buen funcionamiento de los productos y servicios web. SRE se encuentra en la encrucijada del desarrollo de software y la ingeniería de sistemas, resuelve problemas operativos y desarrolla soluciones escalables, confiables y eficientes para el diseño, creación y operación de sistemas distribuidos a gran escala.
Los principales objetivos de SRE:
- Monitorear y recopilar métricas : determinar el comportamiento deseado del servicio, estudiar el comportamiento real del servicio y eliminar las diferencias.
- Respuesta a incidentes : detección y respuesta efectiva a fallas del servicio para mantener la disponibilidad del servicio consistente con su SLA (acuerdo de nivel de servicio).
- Planificación de la capacidad : pronostica la demanda futura y proporciona la cantidad necesaria de recursos informáticos en las ubicaciones adecuadas para satisfacer esta demanda.
- Escalado de servicios : implementación predecible y eliminación de la potencia informática de un servicio en un centro de datos, a menudo como resultado de la planificación de la capacidad.
- Gestión del cambio: cambiar el comportamiento de un servicio sin perder su fiabilidad.
- Rendimiento : diseño, desarrollo e ingeniería relacionados con el escalado, el aislamiento, la latencia, el rendimiento y la eficiencia.
El enfoque de SRE está en el ciclo de vida del servicio: desde la idea y el diseño hasta la implementación, la operación, la mejora del rendimiento y, en última instancia, el desmantelamiento.
Antes de comenzar el servicio SRE, lo apoyan consultando en el campo de la arquitectura del sistema, desarrollan plataformas de software, marcos y planes de capacidad, y realizan una revisión de lanzamiento.
Cuando un servicio ya se está ejecutando, los SRE lo admiten de la siguiente manera:
- Miden y controlan la disponibilidad, la latencia y el estado general del sistema.
- Verifique los cambios planificados del sistema.
- Escalan la estabilidad del sistema utilizando algunos mecanismos, por ejemplo, la automatización.
- Mejore el sistema promoviendo cambios destinados a aumentar la fiabilidad y la velocidad.
- Realizar respuesta a incidentes y autopsia "inocente".
Cuando la vida de un servicio está a punto de finalizar, el SRE lo desmantelará de manera predecible con una explicación clara y documentación completa.
Un equipo SRE maduro siempre tiene documentación completa para cada función SRE. Si administra un equipo SRE o planea organizarlo, este artículo lo ayudará a comprender los tipos de documentación que su equipo necesita, lo que lo ayudará a planificar y priorizar el trabajo en la documentación en paralelo con otras tareas del equipo.
Historia de SRE
Antes de discutir los matices de la documentación de SRE, veamos un día en la vida de Zoe, el SRE recién creado.
El segundo cambio de Zoe en el rol de SRE está en marcha en el proyecto insignia de AcmeSale en Acme Inc. Si bien solo se está adaptando al equipo, observa el trabajo de sus colegas y toma notas. Pero ahora ella todavía tiene un buscapersonas.
Por suerte, el localizador llama a las 2:30 de la mañana. El mensaje dice "Job Ragnarok se echó hacia atrás", Zoe no tiene idea de lo que eso significa. Hojea sus notas y encuentra un enlace a la página principal del tablero. Todo se ve bien. Ella trata de encontrar algún documento que haga referencia a Ragnarok en la intranet de Acme, y después de unos minutos preciosos encuentra un documento desactualizado en la arquitectura de servicio, que resulta ser una dependencia crítica para AcmeSale.
Afortunadamente, hay un enlace a la página "Ragnarok Ops" en la discoteca, que encontró un enlace a un tablero con gráficos útiles. La página también menciona el script ragtool, probablemente capaz de ayudar a resolver el problema, pero Zoe se entera al respecto por primera vez. Por lo tanto, envía una solicitud de ayuda de buscapersonas a otro SRE con muchos años de experiencia en este servicio y herramientas. Lamentablemente, no hay respuesta. Zoe revisa el correo y ve un mensaje de que su colega está desconectado durante una hora debido a problemas de salud. Después de sopesar todos los pros y los contras, llama a su técnico, pero la llamada va al correo de voz. Todo sugiere que tienes que resolver este problema tú mismo.
Después de pasar un tiempo buscando información sobre el misterioso script de ragtool, encuentra un documento con una breve descripción de los parámetros de la línea de comandos, así como dónde se puede encontrar. Lanza una herramienta de trapo, se reinicia y cruza los dedos con esperanza. Nada cambia, el tráfico cae aún más. Ella mira desesperadamente el resto de las opciones de la línea de comando, pero no está segura de que no dañarán aún más. Finalmente, decide usar ragtool –balanceo e - dc = atlanta, porque de los gráficos se desprende que el problema es especialmente notable en el centro de datos de Atlanta. El gráfico de tráfico comienza a avanzar lentamente, y Zoe se regocija en la victoria. MTTR (tiempo medio de reparación) es de 45 minutos.
Al día siguiente, Zoe lleva a cabo una discusión post mortem del incidente. Esto se debe a que el problema resultó ser especialmente grande y resultó en una pérdida de ingresos, además el gerente solicita más sesiones post mortem. Ella le pregunta al equipo cómo el resto de los participantes resolverían este problema, y escucha tres enfoques diferentes. Resulta que un solo proceso de solución de problemas simplemente no existe. Sus colegas también admiten que la notificación "se echó hacia atrás" no es el mejor nombre, y la falla ocurrió debido a un error conocido que simplemente no era una prioridad.
Finalmente, Steve, su techlid, pregunta: "¿Qué versión de ragtool obtuviste?", Y luego observa que la versión utilizada es terriblemente antigua. Hace una semana se lanzó una nueva versión, junto con documentación completamente nueva que describe todas las características e incluso explica cómo resolver el problema "Job Ragnarok se echó atrás". Esta versión reduciría el MTTR a cinco minutos.
La existencia de una nueva versión de ragtool es una sorpresa para la mitad del equipo, mientras que la otra mitad es más o menos consciente de la nueva versión y guía. La última versión del script se encuentra en el directorio de inicio de Steve, obviamente en la carpeta bin /. Zoe agrega esto a sus notas para uso futuro, con la esperanza de refinar con calma el resto del turno. Se pregunta si el techlide o uno de los equipos se ocupará de los problemas discutidos en la autopsia, o si todos los SRE futuros tendrán que pasar por una experiencia tan dolorosa.
Más tarde ese día, Zoe participa en una reunión donde el equipo de SRE se comunica con el equipo de desarrollo sobre la transferencia del servicio. Steve dirige la reunión, hace varias de las preguntas planteadas anteriormente sobre los procedimientos operativos y el problema actual de la confiabilidad del servicio, y pide a los desarrolladores que realicen cambios antes de que el equipo de SRE pueda asumir la responsabilidad del servicio. Zoe ya ha asistido a varias manifestaciones organizadas por Steve y otros SRE de alto nivel. Ella entiende que las preguntas formuladas y las tareas distribuidas por los desarrolladores son muy diferentes, dependiendo de quién está llevando a cabo la reunión y qué problema trató el equipo de SRE la semana pasada.
Zoe secretamente sueña con estándares y procedimientos más consistentes, pero aún no comprende cómo alcanzar este objetivo. Más tarde, oye a dos desarrolladores que se ríen de la máquina de café, que muchas preguntas estaban poco relacionadas con el buscapersonas y, en general, no entienden de dónde provienen. Zoe quiere que los desarrolladores entiendan que SRE no solo lleva un localizador con ellos. Al regresar al lugar de trabajo, Zoe encuentra varios boletos que deben ser resueltos, y ya no piensa en ello.
Afortunadamente, todos los personajes y eventos de esta historia están compuestos. Sin embargo, piense si esto es similar a algo que ha encontrado en la realidad. La solución a los problemas de este equipo ficticio es muy obvia, y en la siguiente sección lo discutiremos con más detalle.
La importancia de la documentación.
En las primeras etapas de la existencia del equipo SRE, la organización depende en gran medida del trabajo de individuos altamente calificados dentro del equipo. El equipo almacena conceptos y principios importantes de explotación como partículas de "conocimiento tribal" que se transmiten verbalmente a los nuevos miembros del equipo. Si estos principios no están unificados y no están documentados, lo más probable es que, en algún momento, tengan que volver a ser dolorosamente enseñados por ensayo y error. A veces, los miembros del equipo realizan procedimientos operativos como una secuencia estricta de pasos definidos por sus predecesores en el pasado distante, sin siquiera comprender las relaciones causa-efecto de estos pasos. Si esto no se detiene, los procesos se fragmentan y degeneran, solo le cuesta al equipo comenzar a crecer para resolver nuevos problemas.
El equipo de SRE puede evitar este proceso creando documentación de alta calidad que sirva de base para el crecimiento de dichos equipos e introduciendo un enfoque sistemático para administrar servicios nuevos y desconocidos. Estos documentos preservan el conocimiento tribal en la forma en que es fácil de encontrar, mantener y buscar. Los nuevos miembros del equipo reciben capacitación a través de un programa sistemático y reflexivo. Estas son las características del equipo maduro de SRE.
El resto de este artículo describe los diversos tipos de documentos que SRE crea durante el ciclo de vida de un servicio compatible.
El fin
En la
siguiente parte, consideraremos todos estos tipos en detalle, pero por ahora estamos esperando sus comentarios y preguntas, y también lo invitamos a
una lección abierta .