DBAs, un sacerdocio no más

Nota: Esta publicación de ingeniería fue escrita por nuestra DBA, Silvia Botros y apareció originalmente en el blog de Sysadvent en diciembre de 2016.

Las empresas han tenido y necesitado Administradores de Base de Datos durante años. Los datos son uno de los activos más importantes de una empresa. Eso significa que muchas empresas, una vez que crecen hasta el punto en que deben poder escalar rápidamente, necesitan a alguien que se asegure de que el activo esté bien administrado, tenga el rendimiento para las necesidades del producto y esté disponible para restaurar en caso de desastres.

En un sentido tradicional, el trabajo del DBA significa que es la única persona con acceso a los servidores que alojan los datos, la persona a quien acudir para crear un nuevo clúster de base de datos para nuevas funciones, la persona que diseña nuevos esquemas y la única persona de contacto cuando algo relacionado con la base de datos se rompe en un entorno de producción.

Debido a que los DBA tradicionalmente tienen roles tan únicos, su tiempo es muy escaso, se vuelve más difícil pensar en el panorama general cuando las tareas del día a día son abrumadoras. Es típico recurrir a herramientas frágiles como bash para todo tipo de tareas operativas en DBA land. ¿Necesita una nueva configuración de base de datos desde una instalación limpia del sistema operativo? ¿Tomar, validar o restaurar copias de seguridad? ¿Rotar particiones o datos obsoletos? Cuando su herramienta más utilizada es bash scripting, todo parece un clavo. Estoy seguro de que muchos lectores están preparando tweets para decirme qué tan poderoso es bash, pero por favor esperen su comentario hasta después de evaluar mi razonamiento.

¿Todo esto suena como la descripción de su trabajo como DBA? ¿La descripción del trabajo habla en detalle sobre la actualización de servidores, la creación y prueba de copias de seguridad y la supervisión? La mayoría de las publicaciones de trabajo típicas de DBA se asegurarán de decir que tiene que configurar y configurar 'múltiples' servidores de bases de datos (porque la expectativa es que los DBA los fabriquen a mano) y automatizar las tareas de administración de bases de datos con scripts (hechos a mano).

¿Es ese realmente un enfoque escalable para lo que a menudo es un equipo de uno en una organización en crecimiento y acelerada?

Estoy aquí para argumentar que su trabajo no es realizar y administrar copias de seguridad, crear y administrar bases de datos u optimizar consultas. Hará todas estas cosas en el lapso de su trabajo, pero el objetivo principal es hacer que los datos de su empresa sean accesibles y escalables. Esto no es solo para que la empresa ejecute el producto actual, sino también para crear nuevas funciones y brindar valor a los clientes.

Por qué

Es posible que desee preguntar, ¿por qué haría algo de esto? Hay un argumento para continuar ejecutando el rol de DBA tradicionalmente: seguridad laboral, ¿verdad? Muchas organizaciones tecnológicas hoy en día hacen una o más de las siguientes cosas:

• Están formados por muchos equipos más pequeños.
• Proporcionan funciones mediante la creación de muchos microservicios en lugar de uno o unos pocos servicios más grandes.
• Adoptan metodologías ágiles para acelerar la entrega de funciones.
• Combinan operaciones e ingeniería bajo un solo liderazgo.
• Integran a los ingenieros de operaciones con los desarrolladores lo antes posible en el proceso de diseño.
• Un silo de DBA dentro de las operaciones significa que el equipo de operaciones tiene menos poder para ayudar a depurar problemas de producción en su propia pila, a veces no puede responder y solucionar problemas sin ayuda y, francamente, es menos creíble al exigir colaboraciones más cercanas y tempranas con los equipos de ingeniería si son No practicar lo que predican dentro de Tech Ops.

Entonces, ¿qué se puede hacer para romper ese silo y facilitar que otras personas depuren, ayudar a escalar la capa de la base de datos y capacitar a los ingenieros para diseñar servicios que puedan escalar? La mayoría de las tiendas emergentes tienen como máximo un DBA interno. ¿Puede el único DBA estar 'presente' en todas las reuniones de diseño, aprobar cada cambio de esquema y estar de guardia para una base de datos en expansión y en constante crecimiento?

Los DBA ya no pueden ser porteros o magos. Un DBA puede y debe ser una fuente de conocimiento y experiencia para los ingenieros de una organización. Debería ayudar a los equipos de entrega no solo a entregar funciones, sino también a entregar productos que se escalen y les permitan no temer a la base de datos. Pero, ¿cómo puede un DBA lograr eso mientras realiza el trabajo diario de administrar la capa de datos? Hay varias formas en que usted, el DBA, puede prepararse para la excelencia.

Gestión de la configuración

Esta es una muy importante. Los DBA tienden a preferir las herramientas de la vieja escuela como bash para la configuración de la base de datos. Mencioné esto antes y no tengo nada en contra de usar bash. Lo uso mucho, en realidad. Pero no es la herramienta adecuada para la configuración de clústeres. Especialmente si el resto de operaciones NO usa Bash para administrar el resto de la arquitectura. Es cierto que los ingenieros de operaciones también conocen Bash, pero si están administrando el resto de la infraestructura con una herramienta como Chef o Puppet y las bases de datos se administran principalmente mediante scripts hechos a mano escritos por el DBA, les está imponiendo un obstáculo para proporcionar ayuda cuando se necesita un cambio urgente.

Más aún, se vuelve más difícil ayudar a los equipos de ingeniería a autoservicio y apropiarse de la creación de los nuevos clústeres que necesitan para la nueva función `foo`. Usted se convierte en el 'bloqueador' para completar el trabajo. Familiarizarse con la gestión de la configuración en su empresa también es un beneficio bidireccional. A medida que se familiariza con la forma en que se administra la infraestructura, conoce los estándares del equipo, se familiariza más con la pila y puede colaborar en los cambios que, en última instancia, afectan la escala del producto.

Un DBA que esté sintonizado con el producto y la infraestructura de la organización de ingeniería en su conjunto es invaluable.

Manuales

Este es técnicamente un subconjunto de la documentación que debe escribir, pero en mi experiencia ha demostrado ser mucho más útil que siento que debe señalarse por separado. Cuando digo runbooks, me refiero específicamente a un documento escrito para una audiencia que NO es un DBA. Hay muchos problemas de bases de datos de producción que podemos encontrar como administradores de bases de datos que son fáciles de depurar y resolver para nosotros. Tendemos a subestimar esa memoria muscular y caemos en el patrón de 'solo envíame la página' y nosotros 'nos encargamos de las cosas'.

Si su equipo de operaciones es como el mío, donde usted es el único DBA, probablemente significa que alguien más en el equipo es la primera línea de defensa cuando se registra un evento relacionado con DB. Cierta documentación simple sobre cómo realizar la depuración inicial, la recopilación de datos, puede contribuir en gran medida a que el resto del equipo de operaciones se sienta cómodo con la capa de la base de datos y esté más familiarizado con la forma en que la supervisamos y la depuramos. Incluso si ese evento aún resulta en la paginación del DBA, de manera lenta pero segura, el runbook se convierte en un lugar para que todos agreguen el conocimiento adquirido.

Además, agrego un enlace a la sección del runbook relacionado (¡use anclas!) a las descripciones de la página que van al buscapersonas. Esto es increíblemente útil para alguien que es llamado por un host de base de datos a las 3 AM para encontrar un lugar para comenzar. Estas cosas pueden parecer pequeñas, pero en mi experiencia han recorrido un largo camino para romper las barreras mentales para mi equipo de operaciones que trabaja en la capa de la base de datos cuando es necesario.

Como preferencia personal, los escribo como documentos de descuento dentro de los repositorios de libros de cocina de mi chef. Esto encaja a la perfección en un patrón de solicitud de extracción, revisión y fusión, y se convierte en una parte integral del patrón de libros de cocina de las bases de datos. A medida que los equipos de ingeniería comienzan a crear los suyos propios, los runbooks se convierten en una plantilla familiar a medida que surgen nuevos clústeres de bases de datos por todas partes.

Visibilidad

Nos gustan las pantallas de nuestros terminales. Nosotros los amamos. Las herramientas más populares en MySQL land siguen siendo herramientas de terminal que viven directamente en los hosts de db y que necesitan un conocimiento previo de ellas y cómo usarlas. Estoy hablando de cosas como innotop y MySQL shell. Estos están bien y siguen siendo útiles, pero están creados para administradores de bases de datos. Si no desea ser el guardián de preguntas como "¿hay retraso en la replicación en este momento?" necesita tener mejores herramientas para hacer que el estado de cualquier clúster, actual e históricamente, esté disponible y sea fácil de entender para todos los miembros del equipo. Tengo algunos ejemplos en este campo:

orquestador

Usamos réplicas de lectura para distribuir esa carga fuera del principal, lo que significa que una vez que el retraso alcanza cierto umbral, se convierte en un evento de atención al cliente. Es importante facilitar que cualquier miembro de la empresa sepa en cualquier momento si algún clúster está experimentando retrasos, qué servidores hay en ese clúster y si alguno de los hosts se ha caído. Orchestrator es una gran herramienta en ese sentido porque hace que la visualización de clústeres y su estado estén a una ventana del navegador de distancia.

Grafana/Grafito

Las métricas para la capa de base de datos deben vivir en el mismo lugar que las métricas para el resto de la infraestructura. Es importante que el equipo pueda yuxtaponer estas métricas una al lado de la otra. Y es importante tener una manera fácil de ver las métricas históricas de cualquier clúster de base de datos. Si bien es posible que tenga una preferencia personal por cactus o munin, o plantillas artesanales que haya escrito a lo largo de los años, si las métricas que usa para investigar problemas no están en el mismo lugar que el resto de las métricas de infraestructura, se establece una barrera para otros ingenieros ocupados, y estarán menos inclinados a usar sus herramientas en lugar de las que se usan en otros lugares. Graphite se usa ampliamente para la ingesta de métricas en los equipos de infraestructura modernos, y Grafana es una interfaz de panel de control ampliamente utilizada para métricas y análisis.

Rendimiento de consultas

Usamos VividCortex para rastrear nuestras consultas en clústeres críticos y aunque este artículo no pretende ser un anuncio de un servicio pago, diré que debe tener la capacidad de inspeccionar el efecto de las implementaciones y los cambios de código en la ejecución de consultas y consultar el rendimiento algo que no necesita acceso especial a los registros y procesarlos manualmente. Si VividCortex no es una posibilidad (aunque, en serio, ¡son geniales!), hay otros productos y herramientas de código abierto que pueden capturar incluso el registro lento y ponerlo en una página web fácil de leer para que los no DBA puedan inspeccionar y ver el efecto de su código. El punto importante aquí es que si proporciona los medios para ver los datos, los ingenieros utilizarán esos datos y harán todo lo posible para mantener la eficiencia. Pero es parte de su trabajo hacer que ese acceso esté disponible y no un truco especial de DBA.

Combate la fatiga del buscapersonas

Muchas organizaciones no incluyen el escalado de la capa de la base de datos como un imperativo muy temprano en el diseño de su pila, y no deberían hacerlo. En los primeros días de una empresa, no debe preocuparse por cómo acelerará las llamadas a la API si nadie está usando la API todavía. Pero es apropiado considerar unos años más tarde, cuando el producto haya cobrado fuerza, y esa llamada a la API que estaba llegando a una tabla de unos pocos miles de filas por parte de un puñado de clientes ahora es una tabla de varios millones de filas, y un par de clientes han creado trabajos cron que inundan esa API todas las mañanas a las 6 a.m. en su zona horaria.

Se necesita mucho trabajo para cambiar la capa de aplicación de cualquier producto para proteger la infraestructura y, mientras tanto, permitir que la actividad de la base de datos espuria provoque la fatiga del buscapersonas es un gran peligro tanto para usted como para el resto de la organización de operaciones. Familiarícese con herramientas como pt-kill que se pueden usar en un abrir y cerrar de ojos para evitar que un host de base de datos tenga un tiempo de inactividad importante debido a un volumen no planificado. Dé a conocer el uso de esa herramienta y comunique la acción y su efecto al equipo de ingeniería de participación, pero no es saludable tratar de absorber el dolor de algo que directamente no puede cambiar y, en última instancia, no será beneficioso para ayudar a los equipos de ingeniería. ' aprender a lidiar con los dolores de crecimiento.

Hay muchas formas en que el trabajo de un DBA es exclusivo de su función en comparación con el resto del equipo de operaciones, pero eso no significa que tenga que ser un sacerdocio mágico al que nadie pueda acercarse. Estos pasos contribuyen en gran medida a que su trabajo sea transparente, pero lo más importante es abordar su trabajo no como un guardián de un jardín dorado de host de base de datos, sino como un experto en la materia que puede brindar asesoramiento y ayudar a hacer crecer a los ingenieros con los que trabaja y brindar más. valor para el negocio que las copias de seguridad y el ajuste de consultas (¡pero eso también es divertido!).

Un agradecimiento especial al maravilloso equipo de operaciones de Sendgrid que continúa enseñándome muchas cosas, y a Charity Majors por acuñar el título de esta publicación. Y vea más publicaciones sobre DBA aquí.