Cómo comprar Open-AudIT Professional

01/08/2019 |

Obtener Open-AudIT Professional nunca ha sido tan fácil.

El software de descubrimiento y auditoría que se utiliza en el 95% del mundo puede ser suyo con unos sencillos pasos.

Esta guía asume que usted tiene Open-AudIT instalado y funcionando, si aún no está en esa etapa, estos enlaces le ayudarán:

Una vez que tenga instalado Open-AudIT, puede ir a la opción de menú "Actualizar licencias" y hacer clic en "Comprar más licencias".

Esto mostrará la lista de características y precios de Open-AudIT. Haga clic en la cuenta de nodos que se adapte a sus necesidades.

Actualmente, sólo se puede adquirir una licencia profesional en línea, si desea adquirir una licencia de empresa, puede solicitar un presupuesto a nuestro equipo.

La siguiente pantalla confirmará tu selección y podrás pasar a la caja.

Rellene todos los datos que desea asociar a la cuenta, la dirección de correo electrónico se utilizará para crear una cuenta que es necesaria para acceder a las licencias/soporte.

Una vez procesado el pago, nuestro equipo le enviará por correo electrónico una confirmación y una clave de licencia para el software. Para añadirla, vuelva a la opción de menú 'Actualizar licencias', esta vez haciendo clic en 'Restaurar mis licencias'.N.B. La licencia se añadirá automáticamente a su cuenta si tiene una cuenta de usuario de Opmantek -. ¡inscríbase aquí!

Haz clic en el botón "Introducir la clave de licencia" y aparecerá un cuadro de texto en el que podrás pegar la clave de licencia y añadirla a tu perfil.

Después, tendrá acceso completo a Open-AudIT Professional.

Sin categoría

Un manual sobre el análisis de la causa raíz

12/21/2018 |

Lo hemos visto una y otra vez, un ticket llega a la mesa de ayuda, un cliente se queja de una aplicación lenta o de una mala calidad de voz durante una llamada. Empezamos a investigar el problema, tal vez sacamos algunos registros, tomamos algunos datos de rendimiento del NMS. Todo lo que encontramos no es concluyente, y cuando volvemos a consultar al cliente los síntomas han pasado. El problema ha desaparecido y hay otro ticket en la cola, así que seguimos adelante, sin saber qué causó el problema, sabiendo que volverá a aparecer.

El proceso de llegar al núcleo o raíz de un fallo o problema se denomina Análisis de Causa Raíz (ACR). El Análisis de la Causa Raíz no es un proceso único y estricto, sino un conjunto de pasos, a menudo organizados específicamente por tipo de problema o industria, que pueden personalizarse para un problema concreto. Cuando se trata de identificar la causa raíz de un suceso relacionado con las TI, puede emplearse una combinación de análisis basado en procesos y en fallos. Aplicando un proceso de ACR y corrigiendo los problemas para evitar que se produzcan en el futuro, los equipos de ingeniería reactivos pueden transformarse en proactivos, que resuelven los problemas antes de que se produzcan o se agraven.

En este artículo intentaré esbozar un proceso general para la resolución de problemas relacionados con la red, es decir, aquellos problemas que afectan directamente al rendimiento de una red informática o de una aplicación y que tienen un impacto negativo en la experiencia del usuario. Aunque utilizaré las soluciones de Opmantek en los ejemplos, estos pasos pueden aplicarse a cualquier colección de herramientas NMS.

Introducción al análisis de la causa raíz

Describir el proceso del ACR es como pelar una cebolla. Cada paso del proceso se compone a su vez de varios pasos. A continuación se incluyen los tres pasos principales del proceso de ACR. Los dos primeros pasos suelen completarse en tándem, ya sea por un individuo o por un equipo en una reunión de revisión de incidentes post-mortem.

Identificar correcta y completamente el evento o problema,
Establezca un calendario desde el funcionamiento normal hasta el evento,
Separar las causas fundamentales de los factores causales

Identificar el evento o el problema

La identificación completa y precisa del problema o evento es quizás la parte más fácil del ACR cuando se trata de problemas de red.

Así es, he dicho más fácil.

Es fácil porque todo lo que tienes que hacer es preguntarte ¿Por qué? Cuando tengas una respuesta a la pregunta Por qué, pregúntate por qué ha ocurrido esa cosa. Sigue preguntándotepor qué hasta que ya no puedas hacerlo más, lo que suele ocurrir entre 4 y 5 veces. Este proceso se conoce a menudo como los 5 porqués.

Muchos ingenieros recomiendan utilizar un diagrama de Ishikawa o de espina de pescado para ayudar a organizar las respuestas a los 5 porqués. A mí me gusta esto, y a menudo utilizo una pizarra y notas adhesivas mientras trabajo en el problema. Si prefieres utilizar una herramienta de diagramación de software, está bien, pero utiliza lo que te resulte más cómodo.

Ejemplo - El poder del porqué

Este es un ejemplo del mundo real que el equipo de Servicios Profesionales de Opmantek encontró mientras realizaba una formación in situ sobre el funcionamiento del sistema. Un usuario interno llamó a la mesa de ayuda del cliente e informó de una mala calidad de audio durante una GoToMeeting con un cliente potencial.

¿Por qué? - Un usuario informó de la mala calidad de la voz durante una GoToMeeting (primer motivo)
¿Por qué? - La interfaz del router que da servicio al escritorio del usuario experimenta un alto ifOutUtil (segundo motivo)
¿Por qué? - Las copias de seguridad del servidor se realizan durante el horario laboral (tercera razón)
¿Por qué? - El trabajo cron que ejecuta los scripts de copia de seguridad está configurado para que se ejecute a las 21:00 horas de la zona horaria local (cuarta razón)
¿Por qué? - El servidor que ejecuta el trabajo cron está configurado en UTC (quinta razón)

El equipo comenzó con el problema inicial, tal y como se informó, y se preguntó por qué estaba ocurriendo esto. A partir de ahí, rápidamente se plantearon varias comprobaciones puntuales y sacaron datos de rendimiento del conmutador al que estaba conectado el escritorio del usuario y del router de subida de ese conmutador; esto identificó un cuello de botella de ancho de banda en el router y nos dio nuestra segunda razón.

Una vez identificado el cuello de botella del ancho de banda, los ingenieros utilizaron nuestras soluciones para identificar de dónde procedía el tráfico a través de la interfaz del router. Esto les dio el servidor de copia de seguridad, y una rápida comprobación de las tareas en ejecución identificó el trabajo de copia de seguridad - y allí se identificó el tercer Porqué.

Las copias de seguridad del sistema eran gestionadas por una tarea cron, que estaba programada para las 9 de la noche. Un comentario en la tarea cron sugería que se trataba de las 21:00 horas de la zona horaria local (EST) de la ubicación física del servidor. Esto le dio al equipo la cuarta razón.

Una comprobación de la fecha y la hora del servidor indicaba que el servidor estaba configurado para UTC, lo que nos daba el quinto Porqué.

No todos los análisis de problemas serán tan sencillos o directos. Al organizar sus preguntas sobre el porqué y sus respuestas en un diagrama de espina de pescado, identificará las causas (y los factores causales) que conducen a la definición del problema y a la causa raíz. En resumen, siga preguntando por qué hasta que no pueda seguir preguntando: ahí es donde suele empezar el problema.

Establecer un calendario

Al establecer una línea de tiempo es importante investigar tanto lo micro (la ocurrencia de este evento) como lo macro (si este evento ocurrió en el pasado). Pensando en las matemáticas de la escuela primaria, dibujo una línea de tiempo, una línea horizontal, a través de mi pizarra. En el centro coloco un punto: es T0 (tiempo cero), cuando ocurrió el acontecimiento.

A la derecha de T0_añadomarcas para cuando se descubrieron detalles adicionales, cuando el usuario informó del problema y cuando recogimos información de rendimiento o NetFlow. También añado marcas para cuando se produjeron o se informaron otros síntomas, y para cualquier evento adicional del NMS.

A la izquierda del T0, coloco todo lo que hemos aprendido al preguntarnos el Por qué: ¿cuándo empezaron las copias de seguridad, cuándo deberían haber empezado? También reviso mi NMS en busca de eventos que conduzcan al problema de rendimiento; ¿la utilización de la interfaz fue aumentando lentamente o se disparó de forma espectacular?

Una vez que he trazado la micro-línea de tiempo para esta ocurrencia, empiezo a mirar hacia atrás a través de mis datos. Aquí es donde resulta útil disponer de una buena cantidad de información de rendimiento relacionada con el tiempo. El sistema de información de gestión de redes (NMIS) de Opmantek puede almacenar datos de sondeo detallados de forma indefinida, lo que permite un rápido análisis visual de los eventos recurrentes basados en el tiempo.

Ejemplo - El poder del tiempo

A medida que los ingenieros trabajaban en sus preguntas del porqué y construían un diagrama de espina de pescado, también creaban una línea de tiempo del evento.

Empezaron definiendo T0 como el momento en que se notificó el suceso, pero a medida que fueron recopilando datos lo ajustaron al momento en que empezó realmente el impacto en la red.

A la derecha de T0_,añadieron cuándo el usuario informó del problema, cuándo iniciaron el análisis de eventos, cuándo se recopilaron los datos de rendimiento del conmutador y el enrutador, y la información de NetFlow del recopilador de NetFlow. También añadieron en las marcas cuando otros usuarios informaron de impactos en el rendimiento, y cuando NMIS levantó eventos para el aumento de ifOutUtil en las interfaces del router y del servidor de respaldo.

A la izquierda de T0_,añadieron cuándo se iniciaron las copias de seguridad, así como cuándo deberían haberse iniciado. Revisaron NMIS y encontraron los eventos iniciales menores, mayores y de advertencia para el aumento de ifIOutUtil en la interfaz del router.

Una vez que se completó la línea de tiempo, el equipo de ingenieros pasó a buscar sucesos anteriores de este evento. Ampliando la escala de los gráficos de la interfaz del router, los ingenieros pudieron ver al instante que esta interfaz había estado informando de un elevado ifOutUtil a la misma hora todos los días de la semana durante varias semanas. Este comportamiento cíclico sugería que se trataba de un proceso cronometrado y no de un evento único relacionado con el usuario.

Causas fundamentales frente a factores causales

A medida que vaya construyendo y respondiendo a sus preguntas de por qué, inevitablemente descubrirá varios puntos finales posibles, cada uno de ellos una causa raíz potencial. Sin embargo, algunos de estos puntos serán simplemente un problema causado por la causa raíz -un factor causal- y no la causa raíz en sí.

Para mejorar el rendimiento de la red a largo plazo, es fundamental que estos factores causales se identifiquen como lo que son, y no se presenten erróneamente como la causa principal.

Ejemplo - Distraído por un factor causal

El equipo de ingenieros se dio cuenta rápidamente de que todos los servidores habían sido configurados, en algún momento del pasado, para las zonas horarias locales y sólo recientemente se habían estandarizado a UTC. Aunque se había establecido un proceso para identificar los horarios, como este trabajo cron, y actualizarlos para el cambio a UTC, este se había pasado por alto.

Algunos miembros del equipo querían detenerse aquí y arreglar la programación del cron. Sin embargo, el grupo más amplio preguntó: ¿Por qué un trabajo cron para un proceso crítico, en un servidor crítico, se perdió en el proceso de actualización?

Al extraer la lista de procesos y expedientes de los registros del equipo de actualización, se comprobó que este expediente HABÍA sido identificado y actualizado, y que las pruebas se habían completado y verificado. Esto trajo la siguiente pregunta: ¿Por qué se cambió el trabajo cron actualizado, por quién/qué proceso?

Aunque se pueden abordar los factores causales, a menudo son sólo una solución temporal para el problema mayor. A veces esto es todo lo que se puede hacer en ese momento, pero si no se identifica y se aborda completamente la causa raíz, cualquier solución temporal que se aplique a los factores causales se romperá con el tiempo.

Ejemplo - Encontrar la causa raíz

Al investigar más a fondo, los ingenieros descubrieron que la tarea cron se había actualizado correctamente, pero una versión archivada más antigua de la tarea cron se había copiado en el servidor a través de un proceso de DevOps. Se reunió un Equipo Tigre para investigar el archivo DevOps y determinar el alcance del problema. El equipo Tiger informó al grupo de ingeniería al día siguiente; se encontraron otros archivos de programación obsoletos y también se corrigieron. El equipo de ingeniería trabajó con los ingenieros de DevOps para poner en marcha un proceso que mantuviera actualizado el archivo de archivos de DevOps.

Clausura del evento

En este punto, ha completado el Análisis de Causa Raíz y ha identificado el problema principal que causa la degradación del rendimiento reportada. Dado que ha abordado la causa raíz, este problema no debería volver a producirse. Sin embargo, no puede detenerse aquí: hay dos pasos de seguimiento que son críticos para su futuro éxito como organización de ingeniería

Documentar el problema
Me gusta utilizar un wiki centralizado, como Confluence de Atlassian, para capturar el conocimiento de mi organización en un repositorio central disponible para todo el equipo de ingeniería. Aquí documentaré todo el evento, lo que fue reportado por el usuario, la información de rendimiento que capturamos, el proceso de RCA y el resultado final - cómo y qué hicimos para evitar que esto suceda de nuevo. Utilizando herramientas como Opmantek's opEvents, puedo relacionar esta entrada del wiki con el servidor, el router, las interfaces y el evento ifOutUtil, de modo que si se repite, los futuros ingenieros tendrán esta referencia disponible.

Seguimiento
Se ha identificado la causa raíz, se ha puesto un remedio y se ha desarrollado un proceso para evitar que vuelva a ocurrir. Sin embargo, esto no significa que hayamos terminado con la resolución de problemas. Hay veces en las que lo que suponemos que es la causa raíz es, de hecho, sólo un factor causal. Si ese es el caso, este problema se reafirmará de nuevo, ya que la solución sólo sería una solución para el verdadero problema. La solución es poner en marcha un proceso, normalmente a través de un grupo de trabajo o una reunión del equipo de ingeniería, para discutir los eventos que impactan al usuario y determinar si se relacionan con los procesos RCA abiertos o remediados.

Lo que he presentado aquí es un proceso simplificado de análisis de la causa raíz. Hay otros pasos que pueden darse en función del tipo de equipo o proceso de que se trate, pero si se empieza por aquí siempre se puede hacer crecer el proceso a medida que el equipo vaya asimilando el proceso y la metodología.

Lo mejor,

Sin categoría

Remediación automatizada y dormir bien

12/20/2018 |

Un importante proveedor de PaaS que ofrece una plataforma de computación ininterrumpida necesitaba automatizar su forma de evitar los problemas recurrentes para seguir garantizando sus SLA de pérdida y recuperación de datos en milisegundos, dándoles tiempo para diagnosticar y eliminar los problemas subyacentes.

La otra semana asistí a uno de los ingenieros de un importante proveedor de PaaS para que pudiera volver a dormir bien.

La empresa para la que trabaja ofrece una plataforma informática IBM Power PC sin interrupciones y necesitaba automatizar las actividades que realizaban sus ingenieros para poder seguir garantizando los SLA de pérdida y recuperación de datos en milisegundos para los que fue diseñada. Sabían que necesitaban tiempo para diagnosticar y eliminar los problemas subyacentes, por lo que necesitaban una forma rápida y fiable de solucionar los problemas a medida que se producían mientras tanto.

Este blog describe lo que se hizo en este entorno especializado, pero proporciona un gran ejemplo de aplicación de la automatización de la remediación en cualquier entorno. Este proveedor de servicios ofrece una plataforma IBM PowerPC como servicio a bancos, empresas de servicios públicos, empresas de telecomunicaciones y similares, utilizando dos clústeres en dos centros de datos, la replicación entre sitios proporciona alta disponibilidad y cero pérdida de datos. Los ingenieros utilizan NMIS, opEvents y opConfig para gestionar todo el entorno. NMIS se utiliza para recopilar estadísticas, estados y eventos de las instancias del clúster IBM Power PC, NMIS también recoge datos de los servidores miembros, la conmutación Fibre Channel y Ethernet y la SAN. Disponer de NMIS significa tener visibilidad en todo el entorno y hasta el estado del sistema operativo, en particular los demonios subyacentes, los servicios, etc. en el clúster de Power PC. En este caso, se utilizó la gestión de servicios de NMIS y las capacidades de los complementos para supervisar los sistemas de IBM.

El equipo estaba haciendo uso de las funciones de gestión de servidores de NM IS para recopilar datos de estado y rendimiento de varios plugins de Nagios para los servidores PowerPC. NMIS y opEvents alertaban al equipo de que la replicación de SVC fallaba ocasionalmente enviando notificaciones por SMS y correo electrónico a los equipos adecuados. El equipo respondía a estas notificaciones siguiendo un proceso para reiniciar el servicio SVC en las máquinas, por supuesto, esto era generalmente en medio de la noche. Necesitaban una manera de automatizar esta tarea de remediación rápidamente, así que esto es lo que hicieron en unos 20 minutos para completar el trabajo y sin gastar dinero.

Primero leen los documentos sobre la automatización de acciones de eventos en opEvents

A continuación, se examinaron los eventos de replicación de SVC en opEvents mirando la pestaña de detalles de uno de los eventos anteriores. Se decidió que sólo querían que se activara si la alerta era "Servicio caído" en lugar de "Servicio degradado" y que sólo querían que ocurriera si el servicio estaba caído en el sitio primario, no si estaba caído en el sitio secundario. En la pestaña de detalles del evento se anotaron los siguientes atributos del evento:
event => Service Down element => svc_lun_inservice host => primary_cluster.example.com
A continuación probaron un script de shell que habían utilizado para reiniciar el servicio svc de forma remota, esto era simplemente tres comandos ssh remotos que habían estado emitiendo a mano, lo colocaron en el servidor NMIS en:
/usr/local/nmis8/bin/restart_svc.sh
La última pieza del rompecabezas era llamar al script cuando los detalles del evento coincidían.

Así que editando el archivo EventActions.nmis
/usr/local/omk/conf/EventActions.nmis
Se añadió lo siguiente:

1. Una acción de script - añadido a la sección 'script' de EventActions.nmis (copiando uno de los scripts de ejemplo como ejemplo) crearon lo siguiente:
'script' => { 'restart_svc' => { arguments => 'node.host', # this script takes the nodes IP or hostname exec => '/usr/local/nmis8/bin/restart_svc.sh', output => 'save', # save a copy of the script's stdout which echos what it is doing stderr => "save", exitcode => "save", max_tries => 2, },
2. Una regla de coincidencia - añadida cerca de la parte superior de EventActions.nmis en la ubicación apropiada (de nuevo lo más fácil fue copiar y editar una de las entradas existentes).
'20' => { IF => ' event.event eq "Service Down" and event.element eq "svc_lun_inservice" and node.host eq "primary_node.example.com" ' , THEN => 'script.restart_svc ()', # note this name matches the the name in the script section above BREAK => 'false' },
Finalmente, necesitaban una forma de probarlo sin hacer nada ni romper nada. Así que primero editaron el script de reinicio ligeramente para que sólo se hiciera eco de los comandos clave que emitiría en el servidor. Luego encontraron una copia del evento de caída del servicio en /usr/local/nmis/logs/event.log, la copiaron en el portapapeles, cambiaron la fecha (epoch) a ahora y la añadieron al registro.
"echo {the editied event line} >> event.log"
y observado opEvents para que el evento aparezca.

Luego miraron la sección de acciones del evento en la GUI y pudieron ver que el script se había disparado y pudieron ver todo lo que el script había hecho, desde su salida hasta su código de salida y sus mensajes stderr.

Finalmente cambiaron el script para que realmente ejecutara los comandos y se fuera a casa.

Esa noche falló la replicación del servicio, pero no se les envió un correo electrónico ni un mensaje de texto, ya que el sistema se reparó por sí solo inmediatamente y antes de que pasara el tiempo de escalamiento de 5 minutos. Trabajo realizado.

Mientras tanto, después de un mes de diagnósticos adicionales con el operador de la red, el proveedor del centro de datos, el proveedor de SAN y un equipo de otras personas, encontraron el problema subyacente de la replicación de LUN, un problema de tiempo de espera relacionado con el canal de fibra entre sitios y las cargas adicionales de copia de seguridad que se producen por la noche. Se cambiaron un par de temporizadores y todo fue bien.

Consiga el libro electrónico aquí

Sin categoría

Por qué los proveedores de servicios gestionados deberían considerar una solución RMM autoalojada en lugar de un software como servicio

12/18/2018 |

Con una creciente dependencia de Internet, muchas organizaciones pequeñas y medianas están optando por no gestionar sus propias redes y entregar las riendas a los proveedores de servicios gestionados. Los servicios gestionados son un sector de rápido crecimiento que se espera que alcance los 193.340 millones de dólares con una tasa de crecimiento anual del 12,5% en 2019 y Opmantek ha sido reconocido desde hace tiempo como un proveedor líder de software RMM autoalojado para algunos de los principales actores del sector.

En los últimos tiempos, se ha producido un cambio en el mercado hacia la compra de software como servicio (SaaS) y muchos proveedores ofrecen ahora soluciones basadas en la nube como un juego de software "sencillo" para los MSP. Sin embargo, nos hemos dado cuenta de que nuestros clientes necesitan flexibilidad, y la nube es un servicio de talla única que no es capaz de dar soporte a todos los dispositivos de red. Cada día recibimos más consultas de MSP que desean recuperar el control de su red volviendo a ser propietarios de su sistema de gestión de red.

Estas son las principales razones por las que nuestros clientes prefieren el software Opmantek alojado en las instalaciones o en la nube privada en lugar de SaaS.

100% de visibilidad y control

Los sistemas de gestión remota basados en SaaS suelen ser una buena opción para los micro MSP debido a la facilidad de despliegue y a los pagos mensuales de suscripción por cada instancia supervisada que facilitan el presupuesto hasta que su base de clientes comienza a crecer. Los dispositivos gestionados se vuelven más oscuros a medida que aumenta el tamaño de las redes que gestiona. Es entonces cuando se empieza a perder la visibilidad de la red, los datos de eventos, salud y rendimiento empiezan a perder calidad y empiezan a surgir costes de licencia adicionales asociados a arquitecturas de red más complejas.

El software de Opmantek puede desplegarse en la nube o en las instalaciones, pero como usted conserva la propiedad de la base de datos y tiene acceso al código fuente en el núcleo de NMIS, mantiene el control de la arquitectura, los dispositivos y los costes.

Integración flexible

Es poco probable que una empresa implemente un software de gestión de redes por primera vez cuando busque una solución. Es muy probable que ya disponga de varios productos que realizan diferentes funciones en su entorno de red y que no quiera o pueda sustituirlos todos a la vez.

Opmantek admite una enorme gama de opciones de integración a través de las API REST (HTTP(S)), operaciones por lotes, información proporcionada en archivos JSON o formularios CSV.

La integración de la API de Service Now ha sido probada en ambas direcciones para la alimentación de incidentes y también para la alimentación de activos de la CMDB.

Opmantek ofrece soluciones integrales, puede implementarlas por etapas (o sólo implementar algunas de las características) y tener la seguridad de que, independientemente de las otras plataformas con las que esté trabajando, tendrá la capacidad de integrar y alimentar datos entre sus sistemas y mantener una visibilidad completa en sus tableros de Opmantek.

Requisitos empresariales a medida y propiedad de los datos

Una talla única rara vez funciona para grandes entornos de red, pero es este enfoque de sistema de corte de galletas el que es estándar con los proveedores de software SaaS RMM.

"La configuración por encima de la personalización" ha sido durante mucho tiempo un valor fundamental de nuestro equipo de desarrollo: en lugar de crear nuevas versiones de software para clientes individuales, co-creamos características de software con nuestros clientes y las hacemos disponibles y configurables para los cientos de miles de organizaciones que han utilizado el software de Opmantek a lo largo de los años. Prácticamente todos los requisitos empresariales imaginables se satisfacen mediante configuraciones. La configuración de fallos, por ejemplo, puede ajustarse de forma enormemente flexible con nuestro motor de políticas de modelado, que permite hacer uso de cualquier metadato sobre un dispositivo para aplicar selectivamente la gestión de fallos y rendimiento. opEvents permite configurar de forma infinitamente flexible la gestión de eventos, la correlación, el escalado, la automatización de la remediación de la red y la automatización del análisis de fallos de la red para adaptarse a la diferencia del cliente y a su NOC.

Escalabilidad ilimitada

Con el número de dispositivos conectados dentro de cada organización aumentando exponencialmente en los últimos años, la capacidad de crecer y escalar para satisfacer las necesidades de un negocio, sin erosionar los beneficios para los proveedores de servicios gestionados es cada vez más crítica. A medida que los negocios de servicios gestionados crecen, muchos proveedores de SaaS obligan a sus usuarios a comprometer la riqueza de los datos y las capacidades de resolución de problemas solicitando actualizaciones de pago para almacenar más datos históricos.

En Opmantek proporcionamos una escalabilidad y una facilidad de escalado sin precedentes.

Somos muy eficientes en nuestro sondeo para que usted obtenga el máximo provecho de cada sondeador con miles de dispositivos por instancia de servidor, incluso con el sondeo con todas las funciones. También le permitimos utilizar tantos pollers como desee utilizando opHA, no hemos visto un límite de cuántos dispositivos o elementos se pueden gestionar en un solo sistema. MongoDB proporciona un almacenamiento rentable de tantos datos como decida almacenar, lo que hace que la información de tendencias y las capacidades de aprendizaje automático sean mucho más eficaces.

Se nos pide regularmente que sustituyamos los productos de otros proveedores importantes porque no pueden escalar, porque son enormemente costosos de escalar o porque pierden funcionalidad al hacerlo.

¿Quiere saber más sobre cómo las soluciones RMM de Opmantek pueden aumentar la visibilidad de su red, ofrecer una automatización inigualable y ahorrar dinero a su organización de servicios gestionados? Haga clic aquí para solicitar una demostración personalizada de uno de nuestros ingenieros hoy mismo.

Sin categoría

Mejora de la gestión de eventos con datos del mundo real

12/17/2018 |

Resumen

Cuando se trata de miles de eventos que llegan a su NOC desde muchos lugares y diferentes clientes, los operadores confían en obtener información útil que les ayude a dar sentido a los eventos que pasan por el NOC.

Utilizando opEvents, es relativamente fácil incorporar casi cualquier fuente de datos a su fuente de eventos para que el equipo de operaciones tenga un mejor contexto de lo que está sucediendo y, en última instancia, cuál podría ser la causa raíz de la interrupción de la red que están investigando actualmente.

Uso de los feeds de Twitter para la gestión de eventos

Si investigas en Twitter, encontrarás que muchos gobiernos y otras organizaciones utilizan Twitter para emitir alertas y hacer anuncios. Buscando un poco en Google, he encontrado algunas fuentes de Twitter excelentes para el tiempo severo, el tiempo general y los tweets de terremotos. Al monitorear estos en opEvents, el resultado es que usted tiene tweets visualizados en su vista general de Gestión de Eventos.

Feeds de Twitter útiles

Malas condiciones meteorológicas

Tiempo Tweet

Terremoto Tweet

@earthquakeBot

Escuchar los feeds de Twitter

Hay varias formas de escuchar los feeds de Twitter. La más rápida para mí fue utilizar Node-RED, algo que utilizo para la automatización del hogar y aplicaciones similares a IoT. Configurar Node-RED con los datos de la alimentación anterior y luego crear un evento opEvents JSON fue muy sencillo.

Vista de configuración del nodo rojo - 700

El código incluido en el nodo "Make Event" está abajo. Crea un documento JSON con la carga útil correcta que es un evento JSON compatible con opEvents (que son una forma realmente genial de tratar los eventos), y luego lo escribe en el archivo:

if ( msg.lang === "en" ) {

// initialise payload to be an object.

details = msg.payload;

event = msg.topic;

timenow = Date.now();

msg.filename = "/data/json-events/event-"+timenow+".json";

msg.payload = {

node: "twitter",

event: event,

element: "Sentiment: " + msg.sentiment.score,

details: details,

sentiment_score: msg.sentiment.score

};

return msg;

}

Cómo introducir los eventos de Twitter en opEvents

Ahora tenemos un documento JSON bien formado con los campos necesarios, opEvents lo consumirá una vez que se le diga en qué directorio debe buscar.

Añadí lo siguiente al opCommon.nmis en la sección opevents_logs y reinicié el demonio opEvents, opeventsd.

'nmis_json_dir' => [

'/data/json-events'

],

El resultado se puede ver bien en opEvents cuando se profundiza en el nodo "twitter" (por supuesto, se puede llamar a este nodo como se quiera, por ejemplo, "tiempo" o "terremoto").

Al hacer clic en uno de los fenómenos meteorológicos con una alta puntuación de sentimiento (más sobre esto en un segundo), puedes ver más detalles sobre este evento y el impacto que podría tener. Desgraciadamente, en estos momentos tenemos un ciclón tropical en el norte de Queensland; esperemos que nadie resulte herido.

Enriquecer el tuit con una puntuación de sentimiento

La puntuación del sentimiento es una heurística que calcula cuán positivo o negativo es un texto, es decir, cuál es el sentimiento de ese texto. El análisis del texto busca palabras clave y calcula una puntuación, y luego, en opEvents, utilizamos esta puntuación para establecer la prioridad del evento, de modo que podamos ver mejor los eventos meteorológicos más críticos porque el sentimiento de esos tuits será negativo.

En los opEvents, EventActions.nmis incluí alguna política de eventos para establecer la prioridad de los mismos basada en la puntuación de sentimiento, que era una propiedad de los eventos que se transmite desde Node-RED. Esto se traslada al resto de opEvents de forma automática.

'15' => {

IF => 'event.sentiment_score =~ /\d+/',

THEN => {

'5' => {

IF => 'event.sentiment_score > 0',

THEN => 'priority(2)',

BREAK => 'false'

},

'10' => {

IF => 'event.sentiment_score == -1',

THEN => 'priority(3)',

BREAK => 'false'

},

'20' => {

IF => 'event.sentiment_score == -2',

THEN => 'priority(4)',

BREAK => 'false'

},

'30' => {

IF => 'event.sentiment_score == -3',

THEN => 'priority(5)',

BREAK => 'false'

},

'40' => {

IF => 'event.sentiment_score < -3',

THEN => 'priority(8)',

BREAK => 'false'

},

},

BREAK => 'false'

},

Dado que opEvents utiliza varias técnicas para facilitar la integración, pude introducir los tweets en el sistema en menos de una hora (originalmente estaba monitorizando tweets sobre el Tour de Francia), luego pasé un poco más de tiempo buscando tweets interesantes sobre el tiempo y refinando cómo se veían los eventos (otra hora más o menos).

Resumen

Si desea un sistema de gestión de eventos que pueda integrarse fácilmente con cualquier tipo de datos de prácticamente cualquier fuente en su flujo de trabajo, entonces opEvents podría ser la solución adecuada para usted. Como ventaja, puede observar la popularidad de eventos deportivos mundiales como el Tour de Francia.

Seguimiento de los tuits del Tour de Francia con opEvents

Sin categoría

La filtración de datos de Marriott: llamada de atención para las empresas que almacenan datos de clientes

12/07/2018 |

Cómo el uso del modelo CARTA de ciberseguridad de Gartner puede ayudar a proteger los datos de los clientes

La revelación por parte de la cadena hotelera Marriott de que los datos personales de hasta 500 millones de huéspedes podrían haber estado en peligro es una llamada de atención en materia de ciberseguridad para las empresas que almacenan datos de sus clientes, incluso en la nube.

El posible robo de millones de datos de pasaportes ̶ denunciado el viernes 30 de noviembre ̶ podría resultar caro. Según la revista estadounidense Fortune, Marriott se ofrecerá a reembolsar a los clientes el coste, si se ha cometido un fraude y los clientes necesitan nuevos pasaportes.

Para las empresas que almacenan los datos financieros y personales de sus clientes, la brecha pone de manifiesto dos cuestiones clave que deben abordarse en las políticas de ciberseguridad de las empresas.

En primer lugar, la ciberprevención requiere vigilancia. La brecha de Marriott se detectó más de dos años después de que se produjera por primera vez. Este es un pensamiento aleccionador para los directores de información. El hecho de que sus sistemas y su personal no hayan detectado una brecha, no garantiza que ésta no se haya producido.

La segunda cuestión es la agilidad. La ciberseguridad es una carrera armamentística continua entre los profesionales de la ciberseguridad y los atacantes. La nube está ampliando esa carrera armamentística a nuevas dimensiones. Para mantenerse seguras, las empresas tienen que ser rápidas y mantenerse proactivas. Esto implica un cambio de mentalidad.

La mentalidad proactiva es la clave de la ciberprevención

Pero, ¿qué medidas prácticas debe tomar su empresa para evitar una brecha similar? Lo más importante es que no espere a que se produzca una alerta de ciberseguridad: busque nuevas formas de detectar cualquier infracción que pueda haberse producido ya.

Y no se quede tranquilo. Si usted es una empresa importante, lo más seguro es asumir que está siendo atacada constantemente, y que algunos ataques tendrán éxito.

Proceso de cuatro pasos para mitigar el riesgo

Para mitigar y gestionar riesgos de ciberseguridad similares, recomendamos un proceso de ciberrespuesta construido en torno a cuatro pasos clave:

Prevención. Revise los cortafuegos y actualice los controles para cumplir con las últimas evaluaciones de amenazas. Esto incluye una evaluación rigurosa de la seguridad de los sistemas en la nube.
Detección. Comprenda las herramientas de control que identifican los ataques y revíselas continuamente a medida que traslada más funciones y datos a la nube.
Remediación. Piense ahora en cómo va a responder si descubre una brecha. Esto incluye una estrategia de comunicación con el cliente.
Restauración. Averigüe cómo puede restaurar un entorno seguro rápidamente si descubre que sus datos ̶ o los de sus clientes ̶ se han visto comprometidos.

Este proceso de cuatro pasos se basa en una metodología elaborada por Gartner, denominada "Evaluación Adaptativa Continua de Riesgos y Confianza" (CARTA). Gartner ofrece una magnífica introducción de 60 minutos a este enfoque, a la que se puede acceder previa inscripción.

Sin embargo, para mantenerse seguro, la clave será siempre la vigilancia. A medida que las empresas trasladen más funciones y bases de datos a la nube, los diseñadores de malware perfeccionarán sus ataques. Una reevaluación continua de las tácticas de prevención cibernética demostrará ser la estrategia más eficaz en esta continua carrera armamentística cibernética. Hable con Roger y su equipo de expertos hoy mismo en el teléfono +61 2 9409 7000 para saber más sobre la protección de su empresa.

Sin categoría

más nuevo

mayor