En el artículo anterior nos hicimos una idea de como partir organizando nuestras tareas como DBA. Ahora vamos por el detalle de algunas de esas tareas.
Crear una lista de servidores
El nombre lo dice todo, pero siempre es bueno tener una idea de lo que se supone que tenemos que administrar. Lógicamente esta lista no va estar completa el primer día, pero nos va a dar una muy buena idea de que es lo que tenemos directamente a cargo. Si alguna vez, los van a visitar a su escritorio y les preguntan: “¿Sabes si el WINSRV2K8R2-PROD12 esta replicando a alguna parte?” y no tienen idea de que ese servidor existía, no se preocupen; eso suele pasar. Pero tengan claro que los van a mirar con cara de “Como no lo conoce si esta instalado hace mas de 6 meses, yo lo uso siempre y el es el DBA…”
Pongan mucho esfuerzo en recopilar la mayor cantidad de información posible apenas puedan. Así ya van a saber a que se enfrentan y les será mas fácil cuando lleguen al punto de generar un plan de acción.
La pregunta lógica en este punto es: ¿De donde saco la información?. Bueno, la respuesta es: De todas partes. Partan por preguntarle a su superior y de ahí vean donde los conduce el camino amarillo… Seguramente pasarán por Administradores de Red, de Sistemas, de Aplicaciones, Desarrolladores, etc. Luego averigüen si hay un sistema de administración de ambientes de TI (MS SCOM, Quest Spotlight, etc.) y si no los conocen o no tienen acceso aun, pídanle a los administradores que les den los reportes lo mas actualizado posible. Un consejo: NUNCA se queden con una sola versión de la historia (Herramientas vs Personas). He visto varios casos de servidores con el “DESA” en su nombre y que resultan siendo de producción, pero alguien olvido cambiarle el nombre.
Otro punto MUY importante es el de los servidores que NO deben administrar. Puede tocarles el caso de servidores de bases de datos que sean de aplicaciones de clientes o que tengan un contrato de soporte con un tercero (generalmente proveedor de alguna aplicación). Si alguien les dice que no son responsables de un servidor, les aconsejo que lo pidan de manera formal (correo, por ejemplo). Así en caso de algún problema con ese servidor especifico, ya saben a quien recurrir y que la culpa no es de ustedes.
Como ultimo tip. Traten de mantener un listado histórico. Eso les servirá para revisar si su carga de trabajo a aumentado, disminuido o se ha mantenido en el tiempo. ¿Tengo mas bases de datos o menos? ¿Funcionan los respaldos? ¿Como andan los jobs? Con eso, van a poder demostrar su valor para la empresa en algún momento de su vida laboral. Además de tener argumentos para una futura reunión con su jefe y les pregunten: “¿Y en que has estado?” (Créanme se los van a preguntar mas de una vez).
Saludos,
En mi último artículo les hablé de lo que es (a grandes rasgos) un DBA.
Recibí un par de comentarios pidiéndome más información sobre el tema así que
acá vamos.
Lo primero que necesitamos es averiguar por donde comenzamos. Suena bastante
obvio, pero a veces es más difícil de lo que parece. Si tienes la suerte de
entrar a una empresa donde no eres su primer DBA, gran parte de la
documentación, tareas de rutina y procedimientos de contingencia ya existirán
(la mayor parte del tiempo es así). Pero ¿y si no es así? ¿Cuáles son las Bases
de Datos “más importantes”? ¿Cuántos servidores tengo a cargo? ¿Cuantos son de
desarrollo, testeo y producción? ¿A quién llamo para coordinar tareas fuera de
horario?… Y la lista de preguntas sigue, pero para que asustarlos más… Acá van
algunos consejos.
Checklist Inicial
Son las 09:00 AM y ya estas sentado en tu puesto, con tu taza (jarro) de
café, mirando la pantalla. Ya conociste a tus compañeros de trabajo, organizaste
(brevemente) tu escritorio, revisaste tu correo electrónico (aunque no tienes
nada en la bandeja de entrada, llevas apenas 5 minutos en la empresa) y estas
listo para iniciar tu trabajo como DBA.
Lo PRIMERO que debes hacer es una lista de los servidores y sistemas que
debes administrar. Si no tienes eso, créeme que tu trabajo será un “poco”
complicado.
Un consejo es separar ese Checklist en partes. ¿Para qué? Bueno, a algunos
(como yo), les ayuda para organizar más fácil las cosas.
Mi Checklist suele tener 3 partes. La primera es para “mis cosas”. La segunda
para “los clientes”. La tercera es para los planes de acción. Mi recomendación
es tratar enfocar los primeros esfuerzos en esas tres tareas durante el primer
día.
Un Checklist inicial (en mi caso) suele tener la siguiente información:
- Lista de Servidores.
- Revisión de tareas de respaldo.
- Revisión de recuperación desde esos respaldos.
- Lista de clientes.
- Lista de Bases de Datos criticas.
- Lista de proyectos o entregables con fecha de cierre próxima.
- Baselines iniciales
- Revisión de Servidores.
- Revisión de Bases de Datos.
- Plan de recuperación (no confundir con Plan de Respaldos).
Yo se que están pensando… ¿Como puedo hacer un Plan de recuperación el primer
día? Bueno, no lo hagan… Pero COMIENCEN a hacerlo. Créanme, es bueno estar
preparados.
Si algún DBA con algunos años de experiencia esta leyendo esto, seguramente
dirá: ¿Y los índices? ¿Y el plan de mejoras de rendimiento? ¿Y la revisión de
logs? Calma… recuerden que esto es solo el primer día. Van a tener muuuucho
tiempo para preocuparse de esas otras tareas (créanme… muuuuuucho tiempo).
Un punto importante: Recuerden avisarle a su superior lo que están haciendo,
como lo están haciendo y PORQUE lo están haciendo. Mostrar preocupación por
conocer el ambiente al que llegamos además, de preocupación e iniciativa,
demuestra que no quieren imponer su visión de las cosas; sino conocer lo que
existe y como USTEDES se van a adaptar y lo van a mejorar. En lugar de llegar a
cambiar todo lo que existe hasta la fecha.
Más adelante, vamos a comenzar a explorar con un poco de detalle cada uno de
los puntos del Checklist.
Como siempre, sus preguntas y comentarios son bienvenidos. Y me gustaría que
otros DBAs pudieran aportar con sus consejos o experiencias en su primer
día.
Saludos,