Solución:
El puesto requiere un amplio espectro de conocimientos. desde el desarrollo hasta la administración del sistema e incluso la gestión. Un DBA no solo debe saber sobre respaldo, recuperación, operaciones internas, memoria y seguridad, sino también cómo comunicarse con los desarrolladores y la administración. Un DBA podría estar dando una presentación de alto nivel a la administración, ayudando a un desarrollador a ajustar una consulta, aprovisionando espacio en disco para un nuevo sistema y restaurando los datos de la copia de seguridad, todo en la misma hora. Estas responsabilidades requieren una gran cantidad de conocimientos con poca superposición.
Las consecuencias de una falla suelen ser mayores para un DBA que un desarrollador. Los DBA a menudo admiten docenas, incluso cientos de aplicaciones y sistemas diferentes, la mayoría de los cuales son vitales para el éxito de la empresa. Una brecha de seguridad, un fallo de recuperación o un problema de rendimiento podrían tener ramificaciones devastadoras y de gran alcance. Esto requiere un nivel de conocimiento y experiencia que no se puede adquirir en poco tiempo.
Cuanto mejor haga su trabajo un DBA, menos visibilidad tendrá. Un DBA con una base de datos segura, recuperable, disponible y con un buen desempeño carecerá de reconocimiento. Los administradores de bases de datos se notan cuando hay problemas. No solo se notan cuando sus problemas son autoinfligidos, sino que también se les culpa cuando la base de datos tiene problemas debido a una codificación deficiente, una configuración de red incorrecta o un almacenamiento configurado incorrectamente.
Pasé de desarrollador a DBA cuando tenía 29 años. Para mí, las cosas que hacen que ser DBA sea difícil también lo hacen gratificante. Disfruto absorbiendo y usando un amplio espectro de conocimientos, y la mayor oportunidad de fracasar hace que evitarlo sea más significativo, ya sea que los demás lo vean o no.
Convertirse en un DBA en realidad requiere una gran experiencia, pero básicamente puede provenir de solo cuatro caminos diferentes:
- Ser desarrollador y hacer una transición a un DBA
- Ser desarrollador y ser redactado como DBA
- Entrenando directamente desde la universidad / escuela de oficios para convertirse en un DBA
- Ser un administrador de sistemas y hacer una transición o realizar una doble función como administrador de bases de datos
Ser desarrollador y hacer la transición a un DBA
En otra pregunta que se hizo en este sitio, ¿Cómo podrían los administradores de bases de datos ser más “amigables para los programadores”, mencioné que fui desarrollador durante 16 años y trabajé con administradores de bases de datos. El haber trabajado con ellos me hizo darme cuenta de que, en la medida en que su experiencia incluía teoría de bases de datos, matemáticas discretas y experiencia en programación, en esa medida podían ver cómo debería funcionar una base de datos y cómo debería ejecutarse una consulta.
Tener un DBA con esas cosas en sus antecedentes me hizo sentir que todavía estaba en la universidad aprendiendo de un profesor adjunto, pero que realmente sabía lo que hacía. Siempre que el DBA estuviera dispuesto a compartir lo que sabía, sin enseñorearse de ti, podrían convertirse en su mentor en términos de desarrollo de declaraciones SQL (SQL es, en sí mismo, un lenguaje de programación sensible al contexto) que son lo más eficientes posible. Claro, existen otras partes mundanas, como realizar instalaciones, hacer copias de seguridad, realizar actualizaciones de software, monitorear métricas de desempeño, generar informes, etc. Pero como desarrollador, si se enfoca en las bases de datos y el SQL que se ejecuta en esas bases de datos, con el tiempo se volverá tan experto en SQL que será una segunda naturaleza y podrá concentrarse en el desarrollo de aplicaciones.
Las demandas de un desarrollador pueden ser exigentes, pero también lo puede hacer el DBA. El desarrollador que voluntariamente hace la transición al rol de DBA cambia el enfoque del desarrollo y la codificación a las cosas mundanas que mencioné antes. A la luz de esto, el DBA trabajando en estrecha colaboración con los programadores crea la oportunidad para que el DBA haga contribuciones creativas a cualquier proyecto, lo que hace que el papel de un DBA sea mucho más interesante.
Ser desarrollador y ser redactado como DBA
Para la mayoría de los desarrolladores que no ven más que desarrollar y codificar por el resto de su vida, esto podría ser como elegir estar en el reality show Sobreviviente o el programa de juegos Limpiar. El nuevo DBA pasa su tiempo interactuando con esa Black Box (conocida por todos nosotros simplemente como la base de datos) que han contactado para obtener datos a lo largo de los años.
El nuevo DBA ahora puede crear sus propias tablas e índices. Esto podría parecerse a dejar que un Hibachi japonés cocine en un restaurante italiano. El cocinero puede preparar cualquier cosa, pero debe darse cuenta de que hay nuevas recetas, utensilios de cocina, cubiertos, carnes, especias, verduras y muchas otras cosas mundanas a las que adaptarse (saneamiento, inventario, hora de inicio, horas de trabajo, etc.). Este no es solo un momento de transición, sino también un momento para superar una gran curva de aprendizaje. Se debe aprender y desarrollar un nuevo nivel de experiencia a pesar de la cocina japonesa experta a lo largo de los años. En este aspecto, los Desarrolladores deben reeducarse para pensar como un DBA.
Entrenando directamente desde la universidad / escuela de oficios para convertirse en un DBA
Esta es, con mucho, la forma más letal de convertirse en un DBA. Este es también el camino más raro; de hecho, es prácticamente inaudito. Ahora estamos hablando de dejar entrar a alguien de McDonald’s o Burger King en ese mismo restaurante italiano.
Están involucradas tres curvas de aprendizaje:
- Aplicar habilidades de la universidad / escuela de oficios en el rol de DBA,
- Interactuar con el RDBMS particular (PostgreSQL, Oracle, MySQL, DB2, Sybase, Ingres) y,
- Interacción con desarrolladores (¿Un futuro DBA que aprenda habilidades sociales decentes directamente después de la escuela? ¡Sí, claro!).
En esto, los desarrolladores tendrán la ventaja sobre los DBA durante años. Los DBA deben aprender a adaptarse rápidamente a las necesidades de los desarrolladores en sus primeros años como DBA. Quizás un DBA podría tener un salario inicial decente, pero es más difícil crecer sin desarrollarse en estas tres áreas de aprendizaje.
Ser un administrador de sistemas y hacer una transición o realizar una doble función como administrador de bases de datos
Como ex desarrollador y ahora DBA, una cosa que no debe darse por sentada es el rol del SysAdmin.
Tener el rol de SysAdmin / DBA es un poco inspirador para mí. En la empresa de alojamiento de mi empleador, tenemos un tipo que es SysAdmin / DBA (SCMDBA). Está tan abrumado con proyectos de infraestructura además de sus propios trabajos internos en MySQL. No lo envidio, lo felicito. Honestamente, dado que la verdadera mente de un SysAdmin / DBA me es ajena, Dejo a discreción de SysAdmin / DBA actualizar este párrafo (o reemplazarlo por completo) para describir esta ruta.
Conclusión
Independientemente del camino que elija, el papel de un DBA puede ser distinguido o repugnante, dependiendo de cuán dispuesto esté a ser asesorado (o torturado) al principio y cuán dispuesto esté a trabajar con otros en el tiempo. Solo entonces se puede decir que disfruta siendo un DBA.
Por cierto, da la casualidad de que experimenté las dos primeras rutas de DBA a partir de agosto de 2004 a la edad de 39 años. Los dos años de experiencia que tuve en el puesto de DBA redactado hicieron que la transición a un DBA de tiempo completo fuera muy agradable y cómoda. .
¿Mi consejo para los administradores de bases de datos de 28 a 29 años? Trabaje con la gente tan bien como lo es con el RDBMS. Si crece en ambas áreas, puede convertirse en un DBA en los próximos años.
La administración de la base de datos es difícil por dos razones
Retroalimentación lenta
Si uno toma una mala decisión en el papel de arquitecto de software, generalmente se necesita más tiempo para obtener comentarios negativos en comparación con un programador. El programador a menudo puede darse cuenta del error durante la compilación o durante la ejecución de pruebas, lo que significa que el ciclo de aprendizaje es bastante rápido. Un administrador de base de datos que comete un error al diseñar una base de datos podría recibir comentarios cuando descubra cómo los usuarios finales realmente usarán el software. Esto significa que podrían pasar años antes de recibir la retroalimentación de que el diseño de la base de datos era defectuoso y debe rehacerse. Por lo tanto, se necesitan años para adquirir experiencia, en lugar de minutos (a veces) para los programadores.
Errores costosos
Esta es también la razón por la que los directores ejecutivos de las grandes empresas suelen tener más de 50 años.