Tiempo de lectura estimado: 5 minutos.
En particular me sucede en forma reiterada que un evento (problema, situación resuelta, artículo leído, etc.) dispara en mi cabeza algunas ideas que muchas veces siento necesario plasmar, en este caso en nuestro blog.
Al leer el artículo de la excelente profesional Ember Crooks, The DBA is Dead? No, the DBA as Gatekeeper is Dead!, se me presentó la situación antes comentada.
Al terminar de leer el artículo, tuve esa sensación de satisfacción (tan humana) cuando alguien respetado profesionalmente tiene las mismas ideas que nosotros mismos con respecto a un tema. Quizás esa inseguridad que se nos presenta cuando los cambios van tan rápido que apenas podemos comprenderlos y controlarlos es de alguna forma mitigada al encontrar un referente en la materia que maneja conceptos que reafirman nuestras propias ideas.
Junto con las ideas a comentar, llego a mi cabeza la frase ¡El rey ha muerto, larga vida al rey!, que uso como título de este artículo. Este lema, usado en el ritual de la sucesión de monarquías en el reino de Francia y corona británica, tenía el sentido de despedir vitoreando al rey fallecido y dar fidelidad al nuevo rey que asumía. La referencia es clara respecto a que quien “muere” es el DBA legacy (aplica igual para el sysadmin) y el nuevo rey es el DBA en un ambiente DevOps heterogéneo. Por supuesto es una metáfora, tenemos claro no tener una corona sobre la cabeza, es bastante más real que próximo a nuestra cabeza tenemos muchas veces un elemento, para continuar con las referencias históricas, muy usado en la revolución francesa.
Con aproximadamente 20 años de haber co-fundado Know-How y cumpliendo varias tareas dentro de la organización, pero asociado de forma invariable con la administración de las bases de datos relacionales y el rol de DBA Sr. (Database Administrator Senior), en varios servicios puedo notar el modo acelerado con el que las cosas van cambiando.
Desde que me inicié en mis tareas de Administrador de Base de Datos Relacionales Junior como pasante en IBM Uruguay, nunca fue de mi agrado ser el responsable de decir que no. Busqué siempre ser conciliador. En general pertenecemos a una “casta“ dentro de las organizaciones que está identificada con actitudes o frases tales como “no está permitido”, “no lo hiciste bien”, “no funciona lo suficientemente rápido, revisalo”, “ese problema no es de base de datos”, “consulta con el área de infraestructura”, entre otras. En términos generales seguimos trabajando de forma individual, considerando a sectores de desarrollo de software como el “enemigo”. Y puedo asegurar que en muchos casos el sentimiento es recíproco.
En ciertas ocasiones el equipo de DBA’s es percibido como el equipo negativo y se deja de lado el hecho de que es el último eslabón en una cadena que puede impedir un problema grave para el servicio que se intenta brindar. Ni hablar cuando el equipo de DBA’s no aparece en el ciclo de vida del software hasta 5 minutos antes de ponerlo en producción. La “negatividad” queda reflejada en diferentes casos. A continuación presento tres elegidos al azar:
- Impedir un deploy (que eliminaría registros que no correspondía). El conocimiento del negocio y tomarse el tiempo para leer los reléase notes del deploy permitió detener lo que hubiese sido un grave problema.
- “Sugerir” parar una obra civil que implicaba mejoras edilicias en un data center. Esta acción obligaba pasar a contingencia todas las bases de datos sin haber completado/probado/aprobado el plan de contingencia de la organización de forma previa.
- Detener una puesta en producción para sugerir a desarrollo usar tablas particionadas en lugar de programar una tarea de depuración diaria de un conjunto de tablas.
Finalmente fuimos absueltos de estos cargos de “negatividad”, pero con un costo alto para quitarnos el estigma del equipo NO. En Know-How intentamos torcer esa visión y debemos admitir que, parafraseando a un colega, muchas veces “fracasamos con total éxito”.
A mí me gusta pensar que en los 20 años que he trabajado relacionado a las bases de datos específicamente, Know-How siempre ha intentado hacerlo en un tono más conciliador, abierto e incluso didáctico (en mi caso quizás herencia de una madre maestra). Ejemplo de esto último es que muchos de nuestros colaboradores comparten conceptos de los motores de base de datos sin haber trabajado directamente con ellos o leído un artículo al respecto. Se trata de una transferencia de información/conocimiento desde Know-How a los clientes de forma no buscada directamente (dictado de curso por ejemplo), pero aprovechado y muy positivo para todos.
Coincido con el articulo citado que si los DBA’s no modifican su forma de trabajo habitual se convertirán en dinosaurios, en tiendas de Blockbuster, una desaparición producto de los cambios tecnológicos.
Por lo tanto, siempre que se presenta un desafío, el DBA debe aportar su conocimiento, experiencia y creatividad en intentar colaborar y ser parte de la solución en lugar de desentenderse (es de desarrollo de software, es de infraestructura, y así puedo continuar repartiendo culpas). La clave se encuentra en no aislarse en el mundo de las bases de datos, sino abrirse a la arquitectura del servicio para encontrar la causa del problema.
No debemos considerar increíble que un Ingeniero de Software (en su rol de arquitecto de sistemas como ejemplo), modelando un sistema con microservicios, consulte al equipo de DBA’s sobre dónde almacenar sus datos. Al contrario, debemos acercarnos y tratar de recordarle que esta arquitectura está pensada para que pequeñas piezas de software hagan sus tareas de la mejor manera posible y almacenar la información en el mejor medio para hacerlo. Esto no siempre es una base de datos relacional. Debemos aceptar que el desarrollador de software puede no saber lo que le generó su framework de persistencia y no atarnos al modelo presentado por Edgard F. Codd en 1969 (aunque lo tengamos en lo más profundo de nuestro corazón).
Todo lo comentado anteriormente es un desafío para todos los que trabajamos en Know-How. Y no es un camino sencillo, ya que hace falta contar con una actitud más que positiva e integradora. Se debe tener un sustento, es decir, conocimientos adquiridos ya sea por la vía de la experiencia o por la vía de la capacitación (y por supuesto el mejor caso, usar ambas).
Es por esto por lo que es muy satisfactorio para todos los integrantes de esta organización aportar a la solución de un problema que supera el dominio estricto de la base de datos y aprender (generar experiencia) de nuestros colegas de otras áreas.
En la parte 2 de este artículo comentaré de forma más amena mi experiencia personal sobre los pasos dados para intentar mantenerme como un actor positivo asociado a los servicios involucrados. No solo con la forma de pararse ante los problemas, sino también con la capacitación a seguir y la forma integral de encarar los retos mencionados. Asimismo, mencionaré las listas de tareas habituales que los DBA tradicionales tienen asignados y los desafíos que nos generan las bases de datos “subidas” al cloud (las creencias y realidades), todo apuntando a ese “renacer” remarcado en el título del artículo.
Como punto medular comentaré el modo en que desde ya hace mucho tiempo en Know-How dichas listas de tareas manejan puntos adicionales muy diferentes a los planteados de forma teórica. Estas tareas, más asociadas a un rol de DBA moderno e integrado al ecosistema, se nos asignan o solicitan por diversos motivos, los cuales también integrarán el contenido de la segunda parte de este artículo.
Quizás sea satisfactorio para todos los que conformamos Know-How pensar que las responsabilidades adicionales al perfil tradicional de un DBA que se nos asignan por parte de nuestros clientes sea por considerarnos simplemente gente sensata, capacitada y confiable.
Autor: Ing. Leonardo Mardero, Director de Know-How Uruguay y DBA Sr
