Webinar Encora DBA as a Service:
DBA as a Service: Administramos tus bases de datos
Roberto Carrancio – Líder de la línea de negocio DBA as a Service de Encora.
Bienvenidos a este Encora webinar donde presentaremos la unidad de negocio DBA as a Service. Nos encargamos de administrar vuestras bases de datos de manera eficiente y profesional.
Antes de nada, aunque Josep ha hecho una pequeña introducción sobre mí, ¿quién soy yo?
0:25
Líder del área DBA as a Service en Encora
Yo soy Roberto Carrancio, soy el líder de esta nueva área de DBA as a Service en Encora. Y para que tengáis un poquito una idea de mi bagaje en esto de SQL Server:
Administrador SQL Server desde hace más de 14 años
Llevo pues casi 15 años ya trabajando con SQL Server, administrando SQL Server, trabajando con SQL Server, algo más.
Ponente eventos nacionales e internacionales
Soy normalmente ponente en eventos tanto nacionales como internacionales. Intento hablar de SQL Server allí donde me dejan, en eventos técnicos.
Creador del blog y canal de YouTube SoyDBA
También soy creador del blog y del canal de YouTube Soy DBA, donde imparto enseñanzas y comparto todo lo que sé de SQL Server.
Líder de comunidad Azure y Microsoft Fabric
Esto me lleva también a ser un líder de comunidad tanto de Azure como de la parte de Microsoft Fabric, que es lo que Microsoft considera que tiene la parte de SQL Server. Tenemos líder de grupos de usuario en Azure y en Microsoft Fabric con otra compañera MVP.
Autor del libro: “SQL Server: La NO guía práctica de optimización”
También he escrito un libro sobre SQL Server, sobre optimización de SQL Server, que sepáis que está disponible.
Microsoft MVP
Todo esto me ha llevado, como os ha comentado antes Josep, al reconocimiento MVP por parte de Microsoft. Este es un reconocimiento que otorga Microsoft a los miembros de la comunidad que más aportan. Y yo desde hace un par de años tengo este reconocimiento.
Y ahora que ya sabemos un poquito quién soy yo, vamos a ver de qué es lo que vamos a hablar.
Vamos a enfocar esta esta charla de la siguiente manera. Vamos a hablar de los principales problemas que suelen tener las compañías con SQL Server y cómo vamos a afrontarlos desde el servicio de DBA as a Service.
02:13
Agenda
Rendimiento
Entonces, el principal problema del que vamos a hablar son temas de rendimiento. Es algo que normalmente os preocupa a todos, así que vamos a empezar por ahí.
Disponibilidad
Lo siguiente es la disponibilidad en DBA as a Service, porque el rendimiento sin disponibilidad no nos sirve de nada.
Seguridad
Por supuesto, también vamos a hablar de seguridad en DBA as a Service.
También hablaremos de cómo la falta de mantenimiento puede llevar a problemas de disponibilidad que afectan directamente a las operaciones de negocio.
Vamos a hablar de auditoría y cumplimiento normativo en DBA as a Service.
Mantenimiento
Vamos a hablar de mantenimientos en DBA as a Service.
Mejora continua
Vamos a hablar de mejora continua en DBA as a Service.
Metodología
Por supuesto, luego veremos ya en lo que es nuestro servicio, cómo va a ser nuestra metodología de trabajo en DBA as a Service.
Servicios de Encora
Qué servicios ofrecemos de DBA as a Service.
Y con esto pues tendremos una visión global de lo que es esta nueva línea de negocio de DBA as a Service.
02:54
Introducción
DBA as a Service
Entonces, antes de empezar,
Tenemos problemas de rendimiento
¿A quién le suena o quiénes de los que estáis aquí os suena esta frase? “Tenemos problemas de rendimiento”. Esto es una de las cosas que más me encuentro como DBA, que los clientes que nos comentan, los problemas de rendimiento son uno de los principales dolores de cabeza en DBA as a Service.
Es crucial que las empresas entiendan que la administración efectiva de bases de datos es esencial para el éxito en el entorno digital actual.
Es crucial que las empresas entiendan que la administración efectiva de bases de datos es esencial para el éxito en el entorno digital actual.
Estamos aquí para ayudar a las empresas a superar estos desafíos mediante nuestro enfoque proactivo.
Nuestra base de datos es el core de nuestro negocio
Estamos aquí para ayudar a las empresas a superar estos desafíos mediante nuestro enfoque proactivo.
Otra de las cosas que se suman a esto es que normalmente la base de datos es el core del negocio. Hoy en día hay muy pocos negocios que puedan funcionar sin sus datos. Hagas lo que hagas, necesitas tu base de datos de clientes, como mínimo. Necesitas una serie de datos de facturación.
Toda empresa requiere de una base de datos y normalmente en mayor o menor medida es algo crítico en DBA as a Service.
No podemos permitirnos una parada de servicio
Entonces esto nos lleva a que no podemos permitirnos una parada de servicio.
Pues para esto es para lo que ha nacido esta unidad de negocio de DBA as a Service.
Como os decía, nos basaremos en seis pilares fundamentales. A medida que avancemos, iremos revisando los puntos de dolor que suelen aparecer en la administración de bases de datos.
04:05
Rendimiento
DBA as a Service
El primero, como os decía, es el rendimiento. Es el que normalmente pues los clientes más necesitan.
Consultas lentas, bloqueos, timeouts y consumo elevado
- Analizamos la carga, esperas, consultas, planes, índices, estadísticas y concurrencia para proponer mejoras de rendimiento.
Entonces, cuando hablamos de rendimiento, hablamos de consultas lentas, hablamos de bloqueos, hablamos de timeouts o hablamos de consumo elevado de recursos.
¿Qué es lo que vamos a hacer nosotros para esto? Bueno, pues vamos a analizar la carga, los tiempos de espera, porque no es lo mismo que una consulta tarde mucho en ejecutarse, que se ejecute inmediatamente, pero tarde mucho en responder porque está esperando antes de poder ejecutarse a otras cosas.
Analizamos las consultas, sus planes de ejecución, vemos a ver cómo están de índices, estadísticas, incluso la concurrencia, porque ya sabéis que hay una frase que dice un uno de mis referentes, que es Fernando Guerrero en el mundo de SQL, que dice que las bases de datos son maravillosas hasta que les metes datos y usuarios.
Pues la concurrencia está ahí, tenemos un gran volumen de datos, tenemos un gran volumen de usuarios y debemos tenerlo en cuenta en DBA as a Service.
La solución no siempre es ampliar recursos
- Separamos los problemas de código, configuración y capacidad antes de recomendar mayor inversión
Y obviamente la solución no siempre va a ser ampliar recursos. Ampliar recursos es una cosa que está ahí. Siempre lo vamos a poder hacer, pero no es la solución. Y como entenderéis tiene un coste.
Entonces, lo que tenemos que hacer es separar lo que son problemas de código, de configuración de lo que es un problema de capacidad del servidor.
Nosotros, en DBA as a Service, siempre antes de recomendaros una mayor inversión en hardware, en licenciamiento, vamos a analizar la causa raíz del problema y vamos a realmente ver si hay un problema de código o hay un problema de configuración.
Normalmente los problemas de configuración se solucionan de manera sencilla y los problemas de código depende, porque muchas veces me decís vosotros, «No, es que yo dependo de una aplicación de terceros donde el proveedor me da esta aplicación con su código y no puedo hacer nada.»
Bueno, no puedo hacer nada, es relativo, por supuesto, si no tenéis un DBA, no podéis o vais a poder hacer muy poco, pero cuando tenemos un DBA que está monitorizando las consultas, sobre todo monitorizando las consultas y capturándolas, podemos ir al proveedor con evidencias de que una consulta está mal.
Obviamente, si no tenemos esa evidencia y no tenemos a nadie que sepa analizar esa consulta, no vamos a poder decirle al proveedor más que “esto me va lento” y el proveedor va a decir, «Es que es así” y no vamos a poder hacer más.
La clave para una gestión exitosa es tener un plan claro y un equipo comprometido que trabaje continuamente en la mejora del rendimiento.
Cuando tenemos evidencias, cuando tenemos un DBA que analiza la consulta que verifica que el problema está ahí, pues vamos a poder ir al proveedor a decirle que lo solucione.
Entonces, antes de ampliar los recursos, vamos a ver qué es lo que podemos hacer en DBA as a Service. Luego ya entraremos o valoraremos si nos sale a cuenta optimizar o refactorizar todo nuestro código o nos cuenta ampliar el servidor.
La clave para una gestión exitosa es tener un plan claro y un equipo comprometido que trabaje continuamente en la mejora del rendimiento.
Eso ya es una decisión que cada empresa debe tomar, pero siempre sabiendo que la ampliación no deja de ser limitada hasta cierto punto por el presupuesto y la refactorización, pues lleva tiempo, que también es dinero, pero puede ser una solución.
Satisfacción de los usuarios
- Detectamos regresiones, tendencias, priorizamos acciones y comprobamos su evolución antes de que el problema llegue al usuario.
Y al final lo que buscamos es la satisfacción de los usuarios, porque un servicio de DBA as a Service de lo que va a ser capaz y con las herramientas con las que vamos a trabajar lo que vamos a ser capaces es de detectar esas regresiones, esas tendencias.
Por lo tanto, vamos a mantener una vigilancia constante para asegurar que nuestros sistemas funcionen optimamente y que cualquier problema se aborde antes de que afecte a los usuarios.
Esto al final no solo es satisfacción de nuestros usuarios internos que usan la aplicación, sino cuando tenemos una web, por ejemplo, o una tienda online, lo que sea a lo que acceden nuestros clientes, al final a nuestra base de datos a través de algún algo intermedio, es imagen de marca y es reputación para nosotros.
Entonces, vamos a analizar todas esas tendencias en DBA as a Service, vamos a priorizar las acciones y vamos a ver y a solucionar el problema antes de que llegue al usuario.
Sobre sobre este tema del rendimiento también os quería contar alguna cosita más. Porque muchas veces, tenemos que saber que no es buscar qué consulta tarda más y optimizarla. Muchas veces sí el problema está una consulta lenta, pero muchas veces yo me he encontrado con que ese no es el problema.
Tú analizas tu servidor y no hay consultas lentas y el problema que te encuentras pues puede ser que hay una consulta relativamente rápida, pero que se está ejecutando muchas veces.
Entonces, todas esas cosas tenemos que verlas, trabajar codo con codo con vuestros equipos de desarrollo o en cualquier caso generar una evidencia para trabajar con el proveedor de la aplicación, con los desarrolladores del código, sean internos o externos, y poder solucionar esto.
Y ¿cómo lo hacemos? Bueno, pues lo hacemos con herramientas de monitorización que nos da SQL Server, el propio SQL Server nos da, por ejemplo, Query Store, nos da vistas de sistema, lo que se llaman DMVs, que almacena cierta información y aparte vamos a trabajar con otras herramientas específicas de monitorización para poder localizar todo esto.
Entonces, vamos a estar continuamente vigilando y quedaros con una cosa. Voy a profundizar mucho sobre ello. No se trata de optimizar una consulta y olvidarse. Esto es algo cíclico. La optimización y cuando hablamos del rendimiento nunca termina.
DBA as a Service siempre tenemos que estar pendientes porque en cualquier momento un cambio de estadísticas nos provoca, un cambio de plan de ejecución, nos provoca una regresión o simplemente cambia el volumen de los datos o hay mayor concurrencia por lo que sea o hay algún problema de latencia, lo que sea que nos provoca que tenemos que estar continuamente pendientes de esto.
Eso es lo que de cara al rendimiento vamos a hacer en la unidad de negocio DBA as a Service.
10:09
Disponibilidad
DBA as a Service
Vamos a pasar al siguiente punto, muy importante también, que es la disponibilidad.
Como os decía, de nada nos sirve tener el sistema más rápido del universo si no está disponible la mayor parte del tiempo.
Entonces desde esta nueva línea de negocio de DBA as Service, lo que vamos a intentar es garantizaros la disponibilidad. ¿Cómo hacemos eso?
Backups
- Analizamos la mejor estrategia, retención, ubicación y pruebas de integridad y restauración para cada uno de tus servicios.
Bueno, en DBA as a Service principalmente vamos a prestar muchísima atención a las copias de seguridad, no solo que se estén haciendo, también vamos a analizar la estrategia, la retención, dónde están ubicadas, vamos a hacer pruebas de integridad, vamos a restaurarlas.
De nada sirve tener una copia de seguridad si no la hemos probado. Porque una copia de seguridad sin probar es como un boleto de lotería, te puede tocar o no.
Tú para tener una copia de seguridad que sepas que vas a poder restaurar, tienes que periódicamente hacer una prueba. Obviamente no pruebas todos tus backups todos los días cuando estás en un entorno inmenso. Muchas veces no es posible, pero sí que aleatoriamente seleccionas algunos y los vas probando cada cierto tiempo.
RPO y RTO
- Relacionamos la arquitectura, procedimientos y pruebas con los objetivos del negocio.
Todo esto teniendo en mente dos conceptos que, seguro que os suenan, que son el RPO y el RTO.
Si no suenan estas siglas, RPO significa, son siglas en inglés, que significa el objetivo del punto de recuperación. Ante un fallo, ¿cuánto tiempo de datos puedo perder?
Por ejemplo, si mi objetivo de punto de recuperación es, yo puedo perder un día, yo tengo backup todas las noches y ante un fallo, pues restauro el backup de por la noche y he perdido un día de trabajo, pero lo puedo recuperar, o no mi negocio es crítico. Yo estoy trabajando en un sistema que tiene mucha interacción, muy crítica y tengo un plazo de 15 minutos de objetivo de recuperación. No me puedo permitir más que eso.
Obviamente todo se puede y podemos garantizar muy poco tiempo de recuperación, incluso casi cero.
Todo es cuestión de costes, de arquitectura, como todo. Nosotros vamos a ver para cada uno de vuestros servidores, porque no todos los servidores SQL tienen el mismo punto de recuperación objetivo, vamos a ir viendo para cada uno de ellos con vosotros qué punto de recuperación objetivo y qué arquitectura tenemos que diseñar para eso y que encaje en el presupuesto.
El tema del RTO, si estábamos hablando antes del objetivo del punto objetivo de recuperación, ahora hablamos del tiempo objetivo de recuperación.
Yo no pierdo ni un segundo de datos, pero ¿cuánto tardo en recuperarme? Una vez caído, ¿cuánto tiempo de caída voy a tener hasta que sea capaz de recuperarme? Como siempre hay distintas estrategias que podemos aplicar para tener mayor o menor tiempo de recuperación.
Ahora quiero que antes de seguir os hagáis la pregunta ¿Vosotros en vuestro sistema SQL sabéis responder qué RPO y qué RTO tenéis actualmente? Cuántos datos perderíais y cuánto tiempo tardaríais en volver estar operativos.
¿Lo sabéis? Eso es una de las cosas que vamos a hablar con vosotros, vamos a hacer todo lo necesario para que esto lo tengamos controlado y sobre todo se cumpla, se cumpla y seamos capaces de haberlo probado porque el papel lo aguanta todo, pero hay que probarlo.
Si yo te digo que tengo una pérdida de datos cero, no pierdo datos y que tengo un tiempo de recuperación objetivo cercano a 2 segundos, tengo que ser capaz de demostrártelo.
Para eso se hacen, por ejemplo, las pruebas de Disaster Recovery, para ser capaz de demostrar que mi estrategia funciona con mi arquitectura, con mi hardware, con mis datos, con todo. Y sobre todo eso, alinear esto con los objetivos de negocio y con el presupuesto.
Alta disponibilidad
- Always On, Clúster de instancias, Log Shipping, Database, Mirroring, Replication, etc.
Y lo último de lo que quería hablaros de la disponibilidad, es algo que cada vez es más común, aunque no todas las empresas disponen de ello y es la alta disponibilidad.
SQL Server, DBA as a Service, nos ofrece muchas opciones con mayor o menor solución de alta disponibilidad, pero con mayor y menor RPO y RTO que tenemos que verlas.
Tenemos el Always on, que es la más avanzada de todas. Podemos tener un clúster de instancias, podemos tener Log Shipping, Database Mirroring ya cada vez se usa menos es lo que había antes de Always On hace muchos años, pero bueno, sigue estando ahí. Tenemos replicación.
Tenemos una serie de opciones en DBA as a Service, incluso luego tenemos ya por fuera, alta disponibilidad a nivel de las máquinas, a nivel de máquinas virtuales o lo que sea.
¿Cuál de estas soluciones de DBA as a Service es para ti? ¿Realmente necesitas alta disponibilidad? ¿Y cuál de estas soluciones para ti? Y no tiene por qué ser la respuesta solo una, puede ser una combinación de varias.
Una vez que hemos definido una estrategia de alta disponibilidad en DBA as a Service, en caso de ser necesaria, que se nos ajuste a nuestras necesidades y a nuestro presupuesto, lo siguiente es no dejar de revisar nunca esta alta disponibilidad.
Esta alta disponibilidad hay que estar supervisándola porque en el momento que haya algún problema y esta alta disponibilidad deja de replicar con los servidores secundarios en caso de caída, pues lo que nos vamos a encontrar es que nuestro punto objetivo de recuperación, que resulta que era un segundo con la alta disponibilidad que habíamos diseñado, pues lleva caído 2 días.
Entonces el punto de recuperación son dos días de pérdida y que el tiempo de recuperación pues que era cero porque estaba ya recuperado en el servidor secundario, pues ahora resulta que es más porque tenemos que recuperar un backup porque la alta disponibilidad no está funcionando.
Entonces, esto hay que estar supervisando continuamente las latencias, que los nuevos estén operativos, que siga habiendo quórum. Y esto estamos hablando tanto en entornos on premis, tanto en vuestros SQL, en vuestras máquinas, en vuestros servidores como entornos cloud.
Tenemos estrategias dentro de Azur SQL, por ejemplo, donde tenemos esta alta disponibilidad entre instancias.
Incluso SQL Server nos ofrece la posibilidad de hacer esta replicación entre entornos on premis y una nube, una nube en Azure, por ejemplo. O podemos tener una estrategia multinube y tener algo en Azure, algo en Amazon, por ejemplo, en AWS y tener una replicación entre esos servidores.
Tenemos distintas estrategias para diferentes casos de uso. Todo esto, como os digo, es algo que tiene que estar muy alineado tanto con los departamentos de desarrollo, pero sobre todo con los de negocio.
Porque al final estos no deja de ser unos objetivos de negocio. También, muchas veces con el departamento legal porque hay que cumplir obligaciones legales de disponibilidad.
Entonces, todo esto tiene que estar coordinado entre distintos departamentos. No os creáis que es una decisión solo técnica. Es un trabajo conjunto entre departamentos donde el DBA, en este caso nosotros como la unidad de negocio de DBA a Service de Encora, estaremos trabajando con vuestras organizaciones, con los distintos departamentos para definir esta estrategia.
Ahora tenemos nuestro sistema que ya va rápido y que ya siempre está disponible. ¿Qué es lo siguiente en DBA as a Service?
17:38
Seguridad
DBA as a Service
La seguridad, por supuesto, tenemos que mantener la seguridad. No puede llegar cualquiera, entrar y hacernos un estropicio en la base de datos.
Privilegios elevados, cuentas compartidas y usuarios
- Analizaremos inicios de sesión y usuarios con sus roles y permisos así como cunetas de servicio siempre bajo la política de privilegios mínimos.
Lo primero que analizamos en DBA as a Service en este sentido es vamos a llegar y vamos a auditar qué privilegios elevados existen. Si existen cuentas compartidas o usuarios que están compartidos.
Vamos a analizar esos usuarios, esos inicios de sesión, esos usuarios de base de dato, cada uno con sus permisos. También vamos a ver las cuentas de servicio y vamos a aplicar una política de privilegios mínimos.
No por nada, sino porque muchas veces es un error lo que nos provoca la caída, no es una mala intencionalidad, no es un usuario con mala intención que se dedica a borrar datos o un actor externo con mala intención que viene a borrar datos, sino que es un error humano y si el usuario no hubiese tenido permisos, no hubiese cometido ese error.
Versiones sin soporte y parches de seguridad
- Identificamos el ciclo de vida de los productos y los incorporamos al roadmap técnico. Diseñamos la estrategia de actualizaciones.
Por supuesto, el fabricante detecta incidentes de seguridad como todos en todas las aplicaciones y va sacando parches de seguridad. Una de las cosas que nosotros tenemos que controlar desde la unidad de DBA as a Service y vamos a controlar es qué versión de SQL Server tenéis, qué parche de seguridad tenéis aplicado sobre esa versión.
Vamos a ver cómo está dentro del ciclo de vida de productos, si tiene o no tiene soporte, Si no tiene soporte es un riesgo. Por ejemplo, sabemos que SQL Server 2016 este mes pasado ha dejado de tener soporte. Ya no salen nuevos parches de seguridad. Si se descubre una vulnerabilidad, ya estamos expuestos. Pues todo eso diseñamos el plan para que se pueda solucionar ese tipo de problema de versiones sin soportes.
Los parches de seguridad son muy importantes. No solo incidencias a nivel funcionamiento, sino también de seguridad. Debemos tenerlo siempre en mente que van saliendo regularmente parches. Esto no es como las actualizaciones de Windows, que sabéis que salen un día del mes y ese día es el día de parcheos de seguridad.
En SQL Server no va así, no salen todos los meses. Hay meses que han salido dos. Tenemos que estar continuamente pendientes de esos parches e ir poniéndolos.
Luego también esos parches hay que analizarlos. Primero hay que ponerlos en un entorno de test, probarlos, ver qué problemas conocidos tienen, porque muchas veces con los parches de seguridad no suele pasar, pero sí que con las actualizaciones acumulativas que solucionan incidencias, a veces te solucionan cinco incidencias, pero te crean una nueva.
Entonces, todo eso hay que probarlo, hay que ver la compatibilidad con vuestro sistema, con las funciones que utilizáis y que no utilizáis y ver si se aplica o se espera a un siguiente parche que solucione la incidencia.
Cifrado, autenticación y exposición
- Contrastamos la configuración con el riesgo y las capacidades de cada pataforma.
Por último, muy importante, cifrados, autenticación y exposición. ¿Vosotros tenéis cifradas vuestras bases de datos? Es muy importante. Estamos garantizando del todo la seguridad por acceso, pero luego llega alguien, coge un backup que tenemos almacenado ahí y lo puede restaurar.
Bueno, pues para eso SQL Server, por ejemplo, implementa un mecanismo que solo se puede restaurar con un certificado. Si el servidor tiene certificado, puedo restaurar el backup. Backup está cifrado con certificado. También se cifra las conexiones. Hay distintos tipos de cifrados que tenemos que ver.
Lo mismo, vamos a ver la configuración que tenéis, la vamos a contrastar con el riesgo y con las capacidades de cada plataforma. No es lo mismo hoy en día, no es lo mismo las capacidades que nos da Amazon AWS, que las capacidades que nos da Azure SQL, que lo que nos da SQL Server, pero en cada uno de los casos tenemos métodos de cifrado, tenemos y no solo de cifrado de los backup, como decíamos, sino de cifrado de los datos.
A lo mejor un usuario no tiene que acceder a un dato o lo tiene que ver ofuscado. Bueno, pues para eso también existen métodos que podemos aplicar a nivel creación de las tablas y configuración más o menos estrictos.
Incluso podemos llegar al más extremo que sería el Always encrypted, que es un método de cifrado en el que ni los administradores de sistema tienen permiso para ver los datos, ni siquiera el DBA con mayor permiso puede ver los datos si no tiene el certificado que hace falta para ver esos datos.
Entonces, entre todos los extremos, entre no tener nada cifrado, cifrar las conexiones, cifrar los backups y los archivos de base de datos, hasta el cifrado ese de datos pasando por ofuscación y por distintos tipos, hay varios tipos de cifrado que vamos a ir viendo con vosotros en función de vuestras necesidades.
Sobre todo, aquí lo que quiero destacar es que vamos a valorar el riesgo porque al final como todos sabéis la seguridad tiene que ir de la mano de la usabilidad también. Entonces hay ciertas concesiones que hacemos por usabilidad, pero siempre conociendo el riesgo.
Lo que nosotros nos queremos asegurar es que vosotros seáis conscientes del riesgo que hay y podáis tomar las decisiones de una manera más informada, no solo viendo lo que implica un coste de desarrollo, cifrar una columna con Always Encripted, por ejemplo.
Entonces, hay que ver riesgo contra el beneficio o el coste.
Esto en cuanto a en cuanto a seguridad, ya tenemos la mitad de los puntos que vamos a ver.
23:22
Auditoría y Compliance
DBA as a Service
Vamos a hablar ahora de lo que es la auditoría y el cumplimiento normativo, Compliance.
¿Qué es lo primero que vamos a hacer?
Documentación VS escenario real
- Desde el minuto uno generamos documentación actualizada que registra el escenario completo: arquitectura, configuración, riesgos…
Lo primero que vamos a hacer en DBA as a Service en sentido es verificar qué documentación existe de estos servidores SQL y generar una documentación actualizada.
¿Cuántas veces os ha pasado que la documentación se crea cuando se despliega el servicio y luego no se actualiza con los cambios que se van haciendo? Eso es lo más común del mundo, o directamente no existe documentación.
Pues nosotros desde el servicio de DBA as a Service vamos a generar esa documentación, a mantenerla actualizada para que siempre pueda ser el punto al que ir a mirar cómo está la arquitectura, qué configuraciones tenemos, qué riesgos estamos asumiendo.
En caso de que tengamos, por ejemplo, que montar un servidor nuevo y queramos replicar la configuración, ya tenemos todo documentado como está. En caso de que tengamos una auditoría, pues podemos justificar lo que ha pasado.
Trazabilidad de decisiones, excepciones y acciones
- Mantenemos evidencias, backlog, responsables y registro de riesgos aceptados.
También en DBA as a Service vamos a llevar esa trazabilidad de las decisiones, las excepciones y qué vamos a hacer. No solo vamos a documentar cómo están las cosas, sino que vamos a tener esas evidencias de cómo están.
Vamos a guardar esa evidencia, vamos a llevar el registro de los cambios que se hacen y sobre todo el registro de los cambios que no se hacen. Cuando nosotros detectemos algo que no está bien y os lo comuniquemos, puede ser que no sea una buena práctica en la industria, pero que para vuestro caso de uso particular sea o tenga que ser así.Porque seamos sinceros, si todo el mundo necesitase lo mismo, no sería una cosa configurable.
Auditoría
- No esperamos a que llegue un auditor para preparar la documentación. Configuramos las herramientas nativas de SQL Server o de terceros necesarias para llegar control técnico y operativo de todo lo que ocurre en la base de datos.
Entonces siempre hay excepciones. Esas excepciones dejarlas documentadas en DBA as a Service. ¿Para qué? Para que el día que tengáis una auditoría no haya que esperar a que llegue el auditor para empezar a preparar la documentación.
A través de las propias herramientas que nos da SQL Server para auditar lo que pasa en SQL y a través de herramientas de terceros vamos a llevar ese control técnico y operativo de todo lo que hacemos en la base de datos.
También podemos hablar de auditoría de cambios en los datos. Muchas veces no solo necesitamos esa auditoría de permisos, no solo necesitamos esa auditoría de cambios que hace el servicio de DBA as a Service en este caso, sino que queremos implementar quién ha modificado un dato, en DBA as a Service queremos tener ese control ¿Quién se conecta? ¿Quién no se conecta? ¿Quién cambia un dato?
Todo eso podemos usar las herramientas que tiene ese SQL server para para auditarlo y que tengáis ese control. ¿En base a qué? Pues esto normalmente se hace en base a regulaciones de cada sector o de cada empresa se tenga que acoger.
Normalmente hay empresas que dicen, «No, yo quiero tener el control de absolutamente todos los cambios porque me apetece, porque quiero verlo.» También puede darse el caso, pero normalmente estos controles se dan porque hay una regulación para tu sector que te obliga a tener este tipo de auditoría y este tipo de auditoría pues hay que diseñarla en función de cuánto espacio va a ocupar, cuántos recursos va a consumir.
No es llegar a activar la auditoría de SQL Server que está ahí en seguridad de auditoría. Le doy a activar y ahora a registrar todo. No tenemos recursos para todo lo que se puede registrar.
Entonces, ¿Cuánto tiempo vas a almacenar esos registros? ¿Qué registros vas a auditar? Todo eso es lo que tenemos que ir viendo en DBA as a Service. Aquí nuevamente entran en juego otros departamentos de vuestras organizaciones en comunicación constante con nosotros para poder diseñar estas auditorías.
Todo lo que estamos hablando, pero sobre todo esto de la auditoría, no es exclusivo de SQL Server on premis. Todo esto lo vamos a poder hacer tanto en un SQL que tengáis en un servidor vuestro, en vuestro servidor físico, como en máquinas virtuales que tengáis en un proveedor de hosting o de lo que sea. Como en Azure, instancias en Azure, bases de datos sin servidor en Azure o lo mismo en Amazon AWS.
Todas las opciones las podemos hacerlo en mayor o menor medida. Siempre hay cosas que no podemos auditar en función de porque no están dentro de los servicios en la nube, pero muchas veces en la medida de lo posible lo vamos a poder adaptar.
28:10
Mantenimiento
En conclusión, DBA as a Service es la solución integral que ofrece Encora para la administración efectiva de bases de datos, asegurando rendimiento, disponibilidad y seguridad.
DBA as a Service
Mantenimiento, tenemos todo funcionando, pero ahora hay que mantenerlo. ¿Qué pasa con el mantenimiento?
DBA as a Service o las organizaciones normalmente tienen sus procesos, sus jobs en SQL Server, sus backups y eso está ahí ejecutándose, pero rara vez se comprueba que eso está fallando.
Jobs, backups o comprobaciones que fallan sin alertar
- Implementamos una solución de observabilidad para no pasar nada por alto. Revisamos el estado, duración, solapamiento, notificaciones y fallos de las tareas programadas.
¿Qué vamos a hacer? En DBA as a Service vamos a implementar una solución de observabilidad para que nada de lo que pase tanto con los jobs como con las copias de seguridad como con las comprobaciones de integridad de la base de datos, todo eso no pase por alto.
Si un job falla, levantaremos la mano y diremos, «Oye, este proceso ha fallado.» Muchas veces no estará en nuestro lado esa solución, por supuesto, porque muchas veces serán procesos de vuestros propios aplicativos, pero tendréis esa alerta de que eso está fallando antes de que llegue el usuario y se dé cuenta.
Por ejemplo, caso real que me ha pasado: Un cliente se queja de que una tabla no está actualizada y resulta que esa tabla se estaba cargando con datos que se cogían de otro servidor con una ETL, esa ETL falla y a los 3 días fallando el usuario se da cuenta que los datos no se actualizan, pero ha entregado a dirección dos días unos reportes sin actualizar porque no había una alerta que eso estaba fallando.
Bueno, pues en ese sentido nosotros en DBA as a Service vamos a implementar esas alertas, Para que esto no pasen por alto. Lo mismo con las copias de seguridad. Las copias de seguridad no dejan de ser otra tarea programada más, mucho más crítica, por supuesto, pero otra tarea más, hay que revisar cómo están.
En el caso de las copias de seguridad, pues podemos ver también si han terminado correctas, que tengan un tamaño consistente. Lo que podamos.
En cuanto a los jobs en DBA as a Service también podemos vigilar la duración. Solapamientos entre ellos, que no tengamos dos jobs a la vez corriendo, que nos tumban el rendimiento o en una hora que no es la hora adecuada para tener esos procesos corriendo.
La duración, pues si un job tarda todos los días 5 minutos y hoy lleva 25, aunque termine sin error, algo ha pasado. Hay que ver qué ha pasado.
Si normalmente un proceso afecta a 1000 filas y hoy ha afectado a 100.000, oye, no ha dado error, pero ¿qué está pasando aquí? Querremos revisarlo.
Obviamente, muchas veces, repito, no serán cosas que estén del lado del administrador de base de datos del DBA as a Service, pero será el que levante la mano y os diga, «Oye, aquí está pasando algo.»
Crecimiento descontrolado
- Analizaremos el crecimiento de datos y ficheros de base de datos, capacidad de almacenamiento y tendencias de consumo para prevenir problemas de almacenamiento.
Lo mismo con el crecimiento de los ficheros de base de datos. En DBA as a Service analizaremos el crecimiento de los datos y de los ficheros para anticiparnos a problemas de capacidad. Analizaremos la tendencia de crecimiento y veremos a 1, 2, 3 años vista cuánto espacio necesitamos si todo sigue como está pensado para no tener ese tipo de problemas.
Cuántas veces nos ha pasado que tenemos una alerta en nuestra monitorización que nos avisa cuando queda un 10% de espacio en el disco, pero no tenemos que llegar a recibir esa alerta. Lo suyo sería nosotros saber qué crecimiento tenemos año a año y tener pues dimensionado ya el espacio necesario para lo que necesitamos a corto medio plazo. Para asumir un pico.
Lo mismo, con la monitorización vamos a poder decir, «Oye, la base de datos estaba creciendo 100 megas al día y ayer creció 2 GB ¿Es que alguien se ha dejado un log con más detalle o es que hay un proceso escribiendo en bucle?
Bueno, pues todo eso podemos verlo, luego podemos irnos a la monitorización, que vamos a tener nosotros y vamos a poder ver lo que ha crecido esta tabla, han crecido tantas filas en esta tabla porque controlamos todos los días ese tipo de cosas y vuestros equipos de desarrollo o vuestro proveedor de la aplicación va a poder ir al problema a decir, «Efectivamente, aquí ha habido un problema en esta tabla o es porque habéis metido un cliente nuevo y se están sincronizando todas sus facturas”, lo que sea, pero entender qué es lo que ha pasado ante un crecimiento anómalo.
Pues todo eso se consigue con monitorización. La monitorización nos lleva a tener una línea base y una tendencia y cuando hay algo que sale de esa tendencia o de esa línea base, esa discrepancia, pues podemos localizarlo. Si no tenemos este servicio que está todos los días mirando, no vamos a ser capaces de detectar este tipo de problemas.
Planes de mantenimiento
- Automatizamos revisiones de la integridad de las bases de datos, mantenimiento de índices y estadísticas, copias de seguridad y tareas de limpieza para un rendimiento óptimo de tus bases de datos.
Por último, algo que nos habéis preguntado también en las preguntas que hicisteis cuando os registrasteis en este webinar: Los planes de mantenimiento.
En SQL Server podemos crear unos planes y automatizar una serie de procesos. Hay procesos muy críticos, como son la revisión de integridad de las bases de datos, que muchas veces en muchos sistemas si no hay un administrador de base de datos, esto no se ha implementado nunca.
La revisión de integridad de las bases de datos es capaz de detectar un problema antes de que una base de datos se corrompa y se quede inoperativa. A veces no, a veces la base de datos se corrompe en un momento dado y la corrupción es tanta que deja de estar operativa de golpe.
Pero muchas veces tener un proceso recurrente de chequeo de integridad nos permite adelantarnos al problema y no perder datos.
Entonces este proceso es crítico. Debería haber un chequeo de integridad periódico en nuestra base de datos, en mayor o menor medida, en función de la ventana de mantenimiento que tengamos, podemos tenerlo completo todos los días o podemos solo chequear la integridad física entre semana y el fin de semana ya hacemos un chequeo completo de los datos.
En mayor o menor medida, en función de nuestra ventana de mantenimiento, pero siempre hay que tener un chequeo de integridad para en caso de problema adelantarnos a que la base de datos se ponga en estado de emergencia, no se puede acceder y la única forma de recuperar sea perder datos. Entonces, esto es imprescindible.
Antes de seguir, una duda que muchas veces veo y que es imprescindible, la alta disponibilidad “yo tengo alta disponibilidad, no me hace falta backup” Una cosa es la alta disponibilidad y otra cosa es la copia de seguridad.
Porque yo tengo alta disponibilidad que replica entre dos servidores en tiempo real, pero si un usuario me borra una tabla, necesito el backup.
Tampoco sustituye la alta disponibilidad al chequeo de integridad. Que yo tenga una copia secundaria no significa que no tenga que detectar si mi base de datos primaria está o no íntegra.
Y este chequeo de integridad lo tengo que hacer por separado, tanto en la réplica principal como en todas las secundarias.
Porque si yo tengo una alta disponibilidad con un servidor secundario donde nunca he chequeado la integridad de la base de datos, igual esa base de datos en el servidor secundario está corrupta y el día que yo tenga un problema en mi servidor principal y balancee con total confianza mi servidor secundario, creyendo que tengo ahí una alta disponibilidad, resulta que no está disponible.
Entonces este chequeo de integridad hay que hacerlo también en las réplicas secundarias y por temas de licenciamiento muchas veces en el tema de Always On, me estoy desviando un poco, pero esto quiero dejarlo claro.
A nosotros nos dicen que el servidor secundario si no accedemos a él, si está solo para el momento que balanceemos para la réplica, ese servidor es gratis, pero hay una serie de excepciones de cosas que sí que podemos hacer en el servidor secundario y una de ellas es el chequeo de integridad.
Aunque el servidor sea de solo lectura, ese chequeo de integridad sí que está permitido hacerse y es que es imprescindible.
Porque ya os digo, tener una alta disponibilidad si no estoy comprobando que el destino mantiene la integridad de la base de datos, pues podemos tener un problema el día que balanceemos. Entonces, la alta disponibilidad no sustituye a ninguno de estos mantenimientos.
El mantenimiento de índices y estadísticas, por ejemplo, sí que se hace solo una vez en la en la base de datos principal porque se replica, porque no deja de ser datos, pero lo que es chequeo de integridad, eso hay que hacerlo en las dos.
Entonces, seguimos. Ahora sí, planes de mantenimiento de DBA as a Service. Aquí hay una polémica cada vez mayor con el mantenimiento de índices. Hay quien te dice que el mantenimiento de índices ya no es necesario. Hay quien te dice que el mantenimiento de índices sigue siendo necesario.
Yo soy partidario de esta segunda opción, por lo menos de momento, mientras la compactación automática de índices nueva que ha sacado Microsoft para Azure SQL no llegue a los entornos on premis, por supuesto, y sobre todo que siguen preview.
En resumidas cuentas, el mantenimiento de índices lo que nos va a hacer es una compactación de esos índices, con lo cual vamos a poder meter más datos en una página de datos, que es como se almacenan los datos, nos van a caber más datos en memoria, va a ser todo más eficiente.
Entonces, igual no es tan necesario hacerlo diariamente como cuando teníamos esos discos mecánicos que sí que penalizaba mucho el acceso secuencial o el acceso aleatorio a los datos. El acceso aleatorio penalizaba frente al secuencial. Ahí sí que el mantenimiento era imprescindible para que los datos estuviesen lo más ordenados posibles.
Ahora que ya no tenemos discos mecánicos en la mayoría de los casos y que cuando los tenemos están en cabinas, hay volúmenes que agrupan varios discos que no sabes realmente dónde estás, en qué sector estás escribiendo, no es tan necesario en ese sentido, pero sí en el sentido de que la compactación hace que nos entren más datos en memoria.
Y luego tenemos las estadísticas. Las estadísticas son un histograma que guarda SQL de los datos que tienen nuestras tablas y es en lo que se basa para luego calcular qué recursos necesita para resolver una consulta y cuál es la mejor manera de resolver esa consulta.
Por tanto, estas estadísticas son clave para el rendimiento de SQL y hay que mantenerlas actualizadas.
Por que aunque hay una opción en SQL que veis que las estadísticas se actualizan automáticamente, eso no significa que con cada operación de escritura se vayan a actualizar y muchas veces nos encontramos con estadísticas desactualizadas y ese es el único problema de rendimiento del servidor.
Muchas veces un simple plan de mantenimiento de índices y estadísticas, yo te diría que en servidores que no hay un DBA, el 90% de los problemas de rendimiento pueden venir por ahí.
Pero no se trata de hacerlo una vez, se trata de programarlo, de verificarlo, de comprobar que encaja en nuestra ventana de mantenimiento, que es el ideal para nosotros.
Adaptarlo por base de datos, porque yo puedo tener una base de datos histórico donde no se consulta normalmente, donde no se escribe mucho porque una vez al mes se pasan los datos y esa base de datos ocupa 10 teras, por poneros un ejemplo, y mi ventana de mantenimiento nocturna no me da para hacer mantenimiento de esa base de datos, pero es que tampoco hace falta.
DBA as a Service hay que adaptar los planes de mantenimiento a las necesidades, no de cada cliente, sino de cada servicio, de cada una de las bases de datos de cada servidor.
Copias de seguridad, por supuesto, y luego tareas de limpieza. Y cuando hablo de tareas de limpieza, en este caso, hablo de las tareas de limpieza internas de SQR Server.
Por supuesto, soy consciente de que hay tareas de limpieza de datos, pero eso no cae del lado del de DBA as a Service, eso siempre cae del lado del desarrollador, que es capaz de saber qué datos se pueden borrar y qué datos no.
¿Qué limpieza de datos cae del lado nuestro, en este caso del de la unidad de negocio de DBA as a service de Encora? Bueno, pues todos estos historiales de las copias de seguridad, todo eso va dejando log, como hemos dicho. Nosotros dejamos log de todo, pero ese log hay que limpiarlo frecuentemente.
Entonces, el propio SQL funcionando deja una serie de logs que tenemos que limpiar y que tenemos que ser conscientes tanto en ficheros en el disco duro como en tablas dentro de SQL. Todo eso hay que limpiarlo.
40:34
Mejora continua
DBA as a Service
Vamos con el último de los puntos, la mejora continua ¿Qué vamos a ver aquí?
Despliegues
- Revisamos los cambios en los objetos de base de datos, impacto, compatibilidad y plan de revisión antes de las ejecuciones para garantizar la integridad de los servicios.
Lo primero en DBA as a Service es revisar los despliegues.
Cuando vosotros vayáis a realizar un despliegue nuevo, voy a crear estas tablas, voy a cambiar este procedimiento almacenado, voy a crear esta función, lo que sea, nosotros vamos a poder revisar el impacto que va a tener eso y si eso es mejorable en cuanto, por ejemplo, a optimización del código antes de que eso llegue a producción.
De manera, que el rendimiento no se vea afectado.
Ciclo de vida
- Te ayudamos a diseñar el roadmap de actualización, capacidad y modernización de tus sistemas SQL Server.
Por otro lado, como ya hemos dicho, en DBA as a Service vamos a seguir el ciclo de vida de los productos de SQL Server y vamos a diseñar ese roadmap de actualización y de modernización de los sistemas.
Cada vez que salga un incidente de seguridad que afecte a uno de vuestros SQL, DBA as a Service os lo notificará. Cada vez que una versión acaba su ciclo de vida, os lo notificaremos y vamos a tener siempre el plan diseñado para que podáis seguirlo de cómo actualizar.
Ground to Cloud
Y por supuesto, la migración a la nube. La migración a la nube no es coger una base de datos que tengo, hacerle un backup y restaurarla en la nube.
No funciona así. El rendimiento en on premis no es igual que el rendimiento en la nube. Hay que adaptar y dimensionar los servicios en la nube para que funcionen o sigan funcionando igual de bien que nos funcionan en on premis.
La seguridad no se gestiona igual en la nube que en un premis. El mantenimiento no es el mismo. Entonces, el modelo de recuperación no es igual o muchas veces no es lo mismo. Todo eso hay que tenerlo en cuenta.
Hasta aquí esos seis grupos de puntos de dolor y problemas que normalmente tienen las empresas y cómo lo solucionamos en DBA as a Service.
42:29
Metodología DBA as a Service
DBA as a Service
Ahora vamos a entrar a hablar de nuestra metodología dentro de la línea de negocio de DBA as a Service de Encora.
Tenemos cinco fases en DBA as a Service y vamos a trabajar siempre en cinco fases.
FASE 1 DBA as a Service – Recopilar
Una primera fase de recopilación. Vamos a capturar datos y evidencias del entorno, no solo en una primera fase, sino que esto lo vamos a hacer de forma recurrente. Pero quedaros ahora con una primera fase de recopilación.
FASE 2 DBA as a Service – Analizar
Con esta recopilación de evidencias y de datos vamos a pasar a analizarlos. Esa información técnica la vamos a convertir en riesgos, en traducir en incidencias, en tendencias, en algo que vosotros seáis capaces de entender.
No os voy a pasar en ningún caso o si lo queréis os lo pasaré, pero no os va a llegar todas las evidencias que salen de SQL, sino que eso estará traducido a un lenguaje que podamos hablar.
FASE 3 DBA as a Service – Priorizar
Vamos a priorizar cada uno de esos hallazgos en función de su impacto, la urgencia y el esfuerzo que tenga y una vez que los tengamos priorizados, hagamos ese triaje de lo de los findings que hemos encontrado, Vamos a diseñar el plan para aplicarlos desde el lado de DBA as a Service.
FASE 4 DBA as a Service – Aplicar o acompañar
Acompañar a los equipos que tengan que aplicarlo. Porque muchas veces, pues a lo mejor es acompañar al equipo de desarrollo o notificar al proveedor, lo que os decía, pues vamos a llegar a eso, pero aquí no nos quedamos. Lo importante es que el servicio es cíclico.
FASE 5 DBA as a Service – Verificar
Nosotros vamos a verificar que todo sigue funcionando una vez que hemos aplicado los cambios y volvemos a recopilar datos, volvemos a analizar, volvemos a priorizar. Esto es una rueda, nunca para, es algo que ya os he ido diciendo durante el webinar, pero es muy importante.
No se trata de hacer algo y dejarlo ahí que ya está hecho, no, hay que verificar continuamente que esto sigue funcionando. Y entonces, ¿cómo podéis vosotros contratar este servicio?
44:34
Servicios de Encora DBA as a Service
DBA as a Service
Vamos a tener tres modalidades de servicio de DBA as a Service.
DBA as a Service Essential
Vamos a tener un servicio Essential de DBAS a Service, donde vamos a tener visibilidad y prevención. Vamos a mirar la salud del servidor, los backup, los trabajos, la capacidad, el dimensionamiento del servidor, la configuración y la seguridad básica.
DBA as a Service Advanced
Luego vamos a ir a un plan advanced, donde vamos a tener todo lo esencial, pero aparte tenemos ese análisis de rendimiento y esa mejora recurrente. Vamos a tener un mayor análisis de la seguridad. Aquí ya vamos a poder analizar vuestros despliegues.
Eso que os decía, nos compartís el SQL que vais a subir a producción y antes de que suba producción lo analizamos.
Aparte vamos a trabajar con vosotros para diseñar esos roadmap de trabajo en los distintos ámbitos de DBA as a Service y vais a tener dentro de este plan Advanced 15 horas de formación al año.
DBA as a Service Enterprise
Existe también o va a existir un plan de DBA as Service, que se va a llamar Enterprise, que va a tener todo lo de Advanced, pero aparte va a permitirnos en esos servidores donde tenemos alta disponibilidad o recuperación ante desastres que nosotros actuemos y además en vez de 15 horas de formación va a tener 20.
46:00
Otros servicios de la unidad de negocio DBA as a Service
Esto en cuanto a servicios recurrentes de DBA as a Service, pero también vamos a tener servicios puntuales como son: Auditorías, como son formaciones, como es el diseño de la arquitectura, un Health Check que nos digáis.
«Oye, quiero un chequeo de salud de mi servidor puntual, el diseño de un plan de recuperación ante desastres, plan de migración a la nube, el diseño de base de datos, migraciones tanto en on premis como a la nube, ya lo hemos dicho, y el acompañamiento a desarrolladores en algún punto que necesiten.
Esto como servicios puntuales aparte de los planes de DBA as a service.
46:48
Conclusión
DBA as a Service es un servicio que ofrecemos porque muchos clientes no tienen a DBA en su equipo que velen 24×7 por la madurez e integridad de sus BD de SQL Server. Desde Encora os queremos ayudar.
Con esto voy a pasar a una pequeña conclusión de DBA as a Service y ya me paso a responder a vuestras preguntas.
La conclusión de todo lo que hemos hablado para mí sería que la pregunta no es si SQL nos está funcionando ahora mismo.
La pregunta es, ¿qué riesgos conocemos y cuáles estamos dejando que crezcan como una bola de nieve? Y recordad que desde Encora os podemos acompañar en cualquiera de las áreas que necesitéis en el servicio completo de DBA as a Service.
Y hasta aquí nuestra presentación de la Unidad de Negocio de Encora DBA as a Service. Espero que os haya gustado. Nos vemos en el siguiente Encora Webinar.
