Estas Semanas en Cloudflare en Español

Hola, bienvenidos a una emisión más de Estas semanas en Cloudflare en español. Mi nombre es Alex Mayorga Adame. Soy un ingeniero de soluciones de Cloudflare para América Latina. Hoy es 29 de marzo de 2024 y bueno, estamos cerrando el mes del empoderamiento femenino. Yo estoy en solidaridad con todas las mujeres. Para los que nos sintonizan por primera ocasión, un poco de logística en la parte baja de la transmisión. Pueden ver algunas formas de contactarse con nosotros por si desean hacer alguna pregunta o enviarnos algún comentario sobre cómo podemos mejorar este programa. Siempre se los agradeceremos. Como la primera parte del programa, lo que revisamos es las novedades en las soluciones y servicios de Cloudflare. Esto lo podemos revisar en Cloudflare.com diagonal watts guión medio new. Entonces comencemos revisando esta parte. Tenemos acá una novedad en cuanto a una Wave de Forrester en soluciones de seguridad en el borde para el primer trimestre de 2024, en donde Cloudflare fue reconocido como un competidor sólido en esta ola de Forrester. Pueden tener acceso al informe del analista haciendo clic en este enlace. Después tenemos un whitepaper o una guía que fue preparada por Cloudflare para saber cómo debemos evaluar justamente a proveedores de SASE cuando estamos en el mercado para estas soluciones. Esta guía la pueden igualmente descargar del enlace. Tenemos también el anuncio en donde Cloudflare comienza a participar en el espacio de un proveedor integrado de SASE para simplificar la seguridad de la red y de los frujos de trabajo de nuestras organizaciones, en donde podemos tener conectividad de sitio a sitio, redes de área amplia, redes de allá y redes punto a punto. Pueden igual tener acceso al anuncio directamente en este enlace. Después tenemos un informe de analista de GigaOM en su radar para CDN del año 2024, en donde Cloudflare ha sido reconocido como líder con rendimiento sobresaliente en este informe. Pueden de nuevo acceder al informe del analista directamente en el enlace. Tenemos un poco más de información sobre analistas, en donde Gartner en su voz del consumidor para soluciones de mitigación de ataques de negación de distribuidos, reconoce a Cloudflare como una de las opciones favoritas para los clientes. Igualmente el análisis está disponible para su consumo aquí. Tenemos un informe más que reconoce a Cloudflare, en este caso es otra ola de Forrester, en donde revisamos las plataformas de desarrollo en el borde para el cuarto trimestre del año pasado 2023, en donde Cloudflare es reconocida como una empresa líder en este segmento, recibiendo una de las puntuaciones más altas en 24 de los 33 criterios que evalúa este analista. Igualmente el informe está disponible para su consumo en el enlace. También tenemos un reporte de analista encargado por Cloudflare sobre cómo podemos recuperar control en Conectividad Cloud para tener control de seguridad de TI de nuestra organización. Pueden descargar este estudio igualmente en el enlace. Finalmente tenemos un reconocimiento más en la guía de mercado de Gartner de 2023 para protección de APIs y seguridad de aplicaciones web, en donde Cloudflare fue reconocido como un vendedor representativo en este informe de Gartner. Siguiendo con el próximo segmento de nuestro programa, tenemos una revisión rápida de lo que tenemos disponible en cuanto a webinars para que estén pendientes de los mismos. Esto lo pueden encontrar en Cloudflare.com diagonal webinars y aquí pueden encontrar tanto todos los recursos que estarán en vivo próximamente. Tenemos una sesión de la Semana de la Seguridad en donde actualizaremos a todos nuestros partners sobre las novedades en las ofertas de seguridad de Cloudflare. Esta ocurrirá el día 4 de abril y pueden registrarse desde ahora en este enlace. Después tenemos un webinar justamente sobre lo que mencionábamos del estudio de Forrester, en donde nos hablarán de cómo podemos recuperar el control de la complejidad que se crea al tratar de securizar las organizaciones. Bueno, como ya sabrán, distintos ambientes, distintas redes, ambientes multinube. Este webinar estará disponible el día 9 de abril e igualmente podemos registrarnos desde ya. Después tenemos un webinar en japonés que estará ocurriendo el día 17 de mayo, en donde se hablará sobre Cloudflare DNS y las herramientas de certificados TLS. Para este igualmente pueden registrarse desde ahora. También aquí recordarles que siempre tenemos disponibles los seminarios pasados que hayan ocurrido, en donde pueden observarlos bajo demanda en cualquier momento que consideren y que su agenda les permita. Tenemos aquí el archivo de todos los webinars que han ocurrido con anterioridad. Entonces, invitarles a que revisen este recurso para que puedan estar informados al tanto de las últimas novedades en Cloudflare y asimismo prepararse para responder de mejor manera a los riesgos de seguridad que hay allá afuera. Bueno, después de esto, seguimos con la tercera parte de este programa, en donde revisamos el blog de Cloudflare. Este lo pueden encontrar en blog.Cloudflare.com. Entonces, vayamos allá. Veamos qué tenemos el día de hoy. Tenemos para comenzar un blog de nuestra colega Mónica, en donde ella nos habla de cómo se está trabajando en Cloudflare para reducir el desgaste de los equipos que tienen que responder a alertas a través de una mejor observabilidad. Bueno, ahí Mónica nos comenta que quizá todos sabremos de este pequeño webcomic donde todo está bien, ¿no? Es el clásico meme que observamos cuando ocurre alguna incidencia en distintas cosas. Entonces acá Mónica nos cuenta que obviamente cuando el personal se encuentra en este tipo de roles, en donde reciben las alertas, pues es posible que si reciben muchas de ellas, esto les cause lo que se conoce comúnmente como alerta de fatigas, ¿no? En donde realmente al recibirse demasiadas, pues no hay claridad en cuál es la más importante o cuál es el paso correcto a seguir. Entonces ella nos habla de cómo asegurarnos de que estas alertas no tengan falsos positivos y sean precisas. Es crucial para evitar que el personal pierda sensibilidad al responder a estos. Entonces dentro de Cloudflare nos comenta muchos equipos, periódicamente realizan análisis de todas estas alertas que se reciben y se generan obviamente paneles para reportería y para mejorar la observabilidad de todas estas alertas. Lo que menciono aquí es que la observabilidad precisamente es refinar la data que se reciba para mejorar en ese aspecto. Y bueno, en este blog nos estará contando cómo se ha trabajado para mejorar estas alertas, utilizando mejores prácticas y herramientas open source para hacer esto más efectivo. Y bueno, aquí tenemos un pequeño diagrama de lo que decíamos, el burnout que se le conoce. Y bueno, nos comenta, obviamente al estar en un rol que recibe este tipo de alertas, pues hay potenciales impactos en las horas de descanso de las personas, en actividades sociales o algunas otras actividades de entretenimiento diferentes al trabajo. Y bueno, comenta ella que una de las razones de esto puede ser justamente el nivel excesivo de alertas que se están recibiendo, o si algunas de ellas en realidad no requieren alguna acción de nuestra parte. Para reducir este problema y obviamente evitar interrupciones innecesarias en la vida diaria del personal, pues se hacen revisiones periódicas y se recibe retroalimentación sobre la calidad de las mismas. Esto obviamente permite que ellos puedan tener un mejor control y generar reportes y estadísticas para obviamente evitar y mitigar este tipo de situaciones. Después nos cuenta un poco sobre la arquitectura técnica propiamente de esta tecnología que se llama Prometheus dentro de Cloudflare, en donde tenemos un manejador de alertas. Nos comenta que Cloudflare trabaja de manera importante con esta tecnología y obviamente, como quizás ya sepan, dado que Cloudflare tiene centros de datos en más de 310 ciudades en el mundo, pues cada uno de ellos obviamente tiene su instancia de esta tecnología. Menciona que existen más de 1.100 servidores de esta tecnología Prometheus y todas las alertas que esto genera se envían a un punto central conocido como alert manager. Y de ahí existen varias integraciones para enrutar estas alertas. Utilizando webhooks se almacenan todas ellas para hacer análisis de datos posterior. Después nos cuenta un poco el ciclo de vida de una de estas alertas. Esto se está revisando en intervalos periódicos, se ejecutan reglas o expresiones para disparar los resultados y esto pues obviamente generan diferentes tipos de alertas cuando ciertas condiciones se generan. Entonces tenemos aquí un pequeño diagrama de cómo Prometheus genera una alerta. Esto se envía al alert manager y después se decide si se deben inhibir, si se deben agrupar, silenciar o enrutar a alguna persona para tomar acción. Y bueno, también nos habla de las diferentes integraciones que tenemos, por ejemplo, hacia el sistema de mensajería instantánea, a Pay Your Duty o al sistema de registro de tickets. Y un poco las relaciones del estatus o el ciclo de vida de una de ellas. Por ejemplo, si se ha resuelto, si continúa disparando, si se ha silenciado o se inhibe o si algo ha expirado, obviamente se resuelve, como vemos en este diagrama. Una vez que se ha disparado una alerta, esta puede ser inhibida o silenciada o regresar al estado donde se vuelve a alertar. Nos cuenta un poco más sobre la tecnología que se utiliza, en donde tenemos una integración que envía esto a un índice de Elasticsearch para poder hacer más análisis y búsqueda de las alertas. Y bueno, esto, como menciona, puede tener algunas limitaciones y un poco quizá a veces confusión sobre qué alerta fue disparada o fue inhibida, por ejemplo. Entonces esto permite conectar a través de las APIs de Alert Manager el almacenamiento de estas alertas. Como vemos aquí, se conecta a través de webhooks y a través de la API. Después nos comenta un poco cómo comenzaron a desarrollar la solución para este tema. Menciona que se optó por hacer un agregado de todos los estados en el almacén de datos. Y también hacer un identificador único para cada una de las etiquetas de alertas. Aquí vemos un ejemplo de ese identificador único que mencionamos. Y también nos indica que se agregó más información, por ejemplo, quién silenció o quién inhibió alguna de las alertas. Esto va a estar ahí disponible. Y después se utiliza otra tecnología que es vector.dev para hacer las transformaciones de datos que se consideren pertinentes. Aquí vemos un poco estas relaciones entre Alert Manager, vector.dev y un almacenamiento de Clickhouse. Y bueno, nos menciona que también si no es Clickhouse se pueden utilizar otros tipos de bases de datos. Después aquí vemos un poco el esquema de estas tablas y un poco las columnas que se crearon para almacenar esta información. Tenemos, por ejemplo, algunas etiquetas que se utilizan, como puede ser la prioridad, la instancia, el nombre de la alerta, etcétera. Y bueno, esto, como menciona, se usó para reducir el uso de recursos. Y después a partir de ahí se generan distintos dashboards. Por ejemplo, tenemos una vista general de las alertas, un caso específico para revisión de los nombres de las alertas, para ver qué equipos o personas recibieron las alertas en específico y cuál ha sido el cambio del estatus a lo largo del tiempo. También aquellos que se enviaron al sistema de tickets y aquellos que fueron silenciados. Entonces tenemos, por ejemplo, aquí una captura de una vista de estos dashboards, en donde vemos todas aquellas vistas de los paneles. Después tenemos también, por ejemplo, una segmentación de los distintos componentes que están revisándose y obviamente este panel pues permite ver el conteo de algunas alertas en distintos sistemas. Estos, por ejemplo, muestran lo que se observa en cuanto a login, métricas, errores, etc. Y también tenemos lo que se mencionaba, el timeline o la vida a lo largo del tiempo de las alertas. Esto nos menciona que fue creado utilizando Grafana para los distintos receptores y permite ver, obviamente, qué tan ocupado con estas alertas está un cierto grupo que se encuentra a un call y los diferentes estados. En el caso del color rojo significa que hay una alerta que se está disparando. Una alerta activa se indica con el color naranja y después algo que ha sido resuelto se coloca en el color verde. También nos menciona que estas alertas por ejemplo están cambiando de estatus rápido a lo largo del tiempo. Y, bueno, menciona que esto puede ser debido a que la duración de la alerta quizá no tenga la mejor configuración. Justamente eso, ¿no? Si pasa un cierto periodo de tiempo en minutos, esta alerta puede volver a cambiar de estado. Después nos habla sobre los descubrimientos que se realizaron. Por ejemplo, algunas alertas que les faltaba una etiqueta de notificación. Pero esto indicaba que, obviamente, esa alerta quizá estuviese alertando, pero no se estuviese enrutando a algún equipo. Y, bueno, esto obviamente generaba exceso de utilización de recursos en Alert Manager. También indica que se encontraron algunos componentes que generaban algunas alertas o gran cantidad de alertas, pero que era equipo que se había decomisionado, pero no se había removido del sistema de alertamiento. Y, bueno, esto con los dashboards que se crearon, obviamente, crea mejor visibilidad y la posibilidad de hacer una mejor limpieza en este caso de situaciones. Después nos habla sobre la parte de la inhibición o supresión de alertas. Y, bueno, nos indica que descubrieron que Alert Manager, en este caso, no estaba inhibiendo correctamente en algunas ocasiones. Y nos muestra aquí un diagrama donde hay alertas que, a pesar de que se creía estaban inhibidas, igualmente estaban disparándose. Entonces, en este caso, alertas que se suponía debieran inhibirse, disparaban de igual forma. Bueno, una vez que esta información se almacenó en Clickhouse, pudieron ellos crear este tipo de búsquedas para identificar esas alertas que no se estaban inhibiendo de manera correcta. Después nos muestra aquí un par de paneles en donde podemos ver el número total de alertas en el primer panel y después las fallas en la inhibición de las mismas en el segundo caso. También después pudieron crear una partición de estas fallas en la inhibición de alertas y pudieron correlacionar esto con los servicios. Por ejemplo, en esto, servicio XYZ se inhibe esta alerta, pero esto tiene una relación con algún otro alertamiento en este caso. Después nos habla justo de silencios. Ahí vemos él. Indica que Alert Manager provee un mecanismo para silenciar las alertas cuando se están trabajando en ellas o se está alertando debido a un mantenimiento planeado. Entonces, este silencio puede detener las alertas por un periodo de tiempo utilizando expresiones regulares o si se encuentra una coincidencia exacta con alguna etiqueta o algún nombre. Y bueno, nos comenta que realizando este análisis se pudieron identificar alertas que se encontraban en tablas de silencio y también menciona que encontraron algunos silencios que estaban desactualizados, que fueron creados mucho tiempo antes y quizá no eran relevantes. Después tenemos un poco lo que revisaron en la creación de estas alertas. Esto básicamente es un enlace a un GitHub en donde podemos ver una demostración de cómo se implementa esta observabilidad y podemos utilizar Docker para crear varios contenedores de las tecnologías que mencionamos a lo largo de este blog, como puede ser Prometheus, Alert Manager, Vector, Clickhouse y Grafana, para ver un ejemplo en vivo de cómo funciona esto. Entonces invitarlos, si sus equipos tienen el mismo tipo de situaciones, a revisar este código para que puedan ver cómo se está resolviendo en Cloudflare. Y bueno, nos muestra que este dashboard muestra una demo de justamente estas alertas y cómo silenciar las mismas. Entonces, como parte de las conclusiones de Mónica, nos cuenta que el equipo de observabilidad pues obviamente tiene múltiples sistemas que se relacionan con este Alert Manager y obviamente es importante para ellos garantizar que las detecciones sean correctas. Y bueno, este análisis que realizaron les ha permitido mejorar la experiencia para los equipos y obviamente poder trabajar de manera más eficiente en las alertas. También nos menciona que esta observabilidad adicional que ganaron les ha permitido realizar la resolución de problemas o eventos de una manera mucho más efectiva e identificar, por ejemplo, por qué alertas no se dispararon o por qué se siguen disparando alertas que se creían silenciadas en este tipo de situaciones. Y obviamente estos paneles que pudieron crear les permiten realizar análisis más rápidos y obviamente ajustar para poder trabajar de una mejor manera en el equipo. También menciona que se crearon, obviamente, una mejor limpieza y agregación de estas alertas. Y obviamente ha permitido ayudar a crear una mejor configuración de los equipos que se encuentran on call para cambiar, por ejemplo, la cantidad de turnos que tienen cada uno de ellos o para evitar que tengan trabajo no planeado. Como conclusión, menciona Mónica, es importante tener una buena observabilidad para evitar, obviamente, el tema del burnout y las interrupciones innecesarias para que los equipos puedan responder de una mejor manera. Y bueno, también menciona que esto, obviamente, resulta en una mejor cultura de monitoreo más proactivo. Y finalmente nos menciona que en el equipo de observabilidad en Cloudflare, de hecho, están contratando personal. Entonces, si los temas de alertamiento y registros son de interés para ustedes, invitarles a aplicar a estos departamentos que tienen algunas posiciones disponibles para que se puedan unir al equipo de Cloudflare. Bueno, con esto llegamos al final de este blog y también nos acercamos al final de nuestro episodio. Voy a revisar si tenemos alguna pregunta que hayamos recibido. Al parecer no ha sido el caso en esta ocasión. Así es que no me queda más que agradecerles por sintonizarnos o por escuchar la grabación de este programa e invitarlos a sintonizarse nuevamente en aproximadamente un mes, en donde estaremos revisando nuevamente las novedades de Cloudflare. Este ha sido su segmento estas semanas en Cloudflare en Español con su amigo Alex Mayorga. Espero tengan un excelente resto del día y hasta la próxima.