Centralización vs. Descentralización de los equipos de DBA

Como Gerente Técnico de Cuentas (TAM), he visto a muchos de nuestros clientes adoptar un equipo de DBA descentralizado. En muchos casos, este es un esfuerzo por alinear mejor al equipo de DBA con los equipos de desarrollo. Este es un objetivo admirable y lógico. Como suele ser el caso, a menudo cambias un conjunto de desafíos por otro.

Equipos de DBA centralizados

Primero, hablemos de los desafíos de un equipo de DBA centralizado. Aquí, los DBA están todos en un equipo que probablemente esté separado de la plataforma. Por lo tanto, a menudo tiene un equipo de MySQL, un equipo de Oracle, un equipo de SQL Server, etc. Estos equipos generalmente reportan a un gerente e incluso si actúan un poco independientemente de la plataforma, todavía hay un cierto nivel de estandarización en la documentación, la estructura de informes, el procedimiento. etc. Hay una serie de beneficios de este enfoque y algunos desafíos. Un beneficio es la estandarización en toda la empresa sobre cómo se documenta, implementa, administra, etc., una tecnología determinada. Por supuesto, esto también puede ser un factor limitante ya que hay pocas oportunidades de personalización. Todo tiende a volverse de naturaleza “vainilla” y todo se parece; desde una perspectiva positiva, esto es consistencia.

La consistencia puede ser muy útil. Cuando se agregan nuevos miembros al equipo, todos los servidores son esencialmente iguales. No importa cuál sea la aplicación, un nuevo miembro del equipo puede convertirse en maestro muy rápidamente en toda la infraestructura. Las lecciones aprendidas en un conjunto de servidores se traducen muy bien en otro conjunto de servidores que admiten una aplicación completamente diferente.

Sin embargo, como se señaló anteriormente, esto también es un desafío. ¿Qué sucede cuando una aplicación en particular necesita algo diferente? Romper la norma es la antítesis de la consistencia y la resistencia se encuentra con el liderazgo del equipo.

Otro desafío es que los administradores de bases de datos a menudo admiten tantas tecnologías diferentes que tienen el desafío de comprender completamente la aplicación y cómo funciona. Hay demasiadas aplicaciones para conocer íntimamente a todos. En este caso, los DBA suelen ser más receptivos que proactivos y se convierten en asesores de los equipos de desarrollo. Esto es bastante común en empresas más grandes que tienen muchas aplicaciones diferentes.

Equipos de DBA descentralizados

Para combatir esto, muchas empresas han adoptado el modelo descentralizado y han dividido los equipos de DBA en equipos más pequeños estrechamente alineados con el equipo de desarrollo. Esto parece tener mucho más sentido en muchos sentidos, ya que los administradores de bases de datos se centrarán en menos aplicaciones y trabajarán mucho más de cerca con los desarrolladores para garantizar una solución mejorada.

Entonces, ¿cuál es el problema con este enfoque? Siempre hay intercambios con cualquier enfoque. Si hubiera un ganador claro, todos lo usarían solos. Uno de los mayores desafíos que he visto como TAM con la descentralización ha sido la falta de estandarización. Cada equipo de DBA actúa prácticamente independientemente de cualquier otro equipo. Los problemas que una vez se resolvieron de una vez por todas pronto se enfrentan en paralelo por muchos equipos. Como resultado, los equipos suelen “reinventar la rueda” cada vez que se enfrentan a un desafío que quizás ya haya sido resuelto por otro equipo. Sin una comunicación interna sólida, los equipos pierden el tiempo buscando soluciones que ya se encuentran.

Este es uno de los aspectos más satisfactorios de mi función TAM. Están en la posición única de reunirse a menudo con varios equipos y socializar estas soluciones en equipos. A menudo me preguntan en las reuniones con mis clientes si he visto este problema con otro equipo o incluso con otro cliente. Si la respuesta es sí, la siguiente pregunta obviamente es sobre cómo resolverlo. La experiencia gana el curso aquí y proporciona una mejora significativa en el tiempo para resolver el problema.

Otro desafío que veo se refiere a la consistencia. En los equipos descentralizados, los DBA a veces pasan de un equipo a otro a medida que cambia la demanda de recursos. En tales casos, los nuevos miembros del equipo necesitan mucho tiempo para acercarse a los sistemas, ya que la coherencia se ha visto comprometida porque cada equipo hace las cosas de manera diferente. La instalación puede ser en varias carpetas o carpetas en los servidores, la documentación puede ser mejor o peor, etc. Sin una supervisión centralizada de los estándares, mudarse a un nuevo equipo puede ralentizar el proceso de acelerar la velocidad del DBA.

La comunicación es la clave

Ya sea que decida mantener un equipo de DBA centralizado o descentralizar el equipo, un cierto nivel de coherencia y comunicación es fundamental. Si elige descentralizar el equipo de DBA, asegúrese de que alguien actúe como un recurso centralizado, como un TAM, buscando modelos de problemas y trabajando para encontrar soluciones comprobadas.

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario