Internet alberga innumerables peligros: ataques perpetrados por hackers malintencionados, capaces de tomar control de nuestros equipos y robar nuestros secretos; pérdidas económicas causadas por virus, gusanos, troyanos y demás malware; ciberbullying y grooming sufrido por menores en redes sociales; spam que inunda nuestro buzón con anuncios basura, timos y fraudes, como los dañinos mensajes de phishing; software espía que se hace con nuestros datos financieros; pornografía y contenidos inadecuados para menores; pérdida de la intimidad personal y del anonimato; la lista podría prolongarse sin fin.
Cómo protegernos de los peligros de Internet, un libro de seguridad informática que podria leer tu madre.
¿Desea publicar una oferta de trabajo en el área IT?
Consúltanos
08 noviembre 2009
¿Cómo protegernos de los peligros de Internet?
Translate to English
04 octubre 2009
Samba, samba, samba..!!!!
Al mas puro estilo de Steve Ballmer
Os recuerdo que samba es un software Open Source/Free que proporciona servicios de fichero e impresión a clientes SMB/CIFS. Permite la interoperabillidad entre servidores Linux/Unix y clientes Windows.
Samba nos proporciona a los administradores de sistemas flexibilidad y libertad en términos de configuración y elección de nuestros sistemas y equipamiento.
¿Gritarían en la conferencia SAMBA, SAMBA, SAMBA!!!!!?
30 septiembre 2009
Las 10 mejores prácticas de adopción estratégica del Open Source en la empresa (Software Libre)
El Open Source es un tema recurrente en este blog, por eso me he alegrado cuando he conocido la campaña del Software Legal impulsada por el ministerio de Industria, Turismo y Comercio dentro del plan Avanza 2, con el fin de concienciar a los distribuidores, empresarios y usuarios finales sobre los beneficios del uso y distribución del software legal. Por ello, este post va dirigido a empresarios que a través de ella (o la actual situación económica), les haya saltado esa chispa y esten pensando en la migración de sus sistemas, ya sea empezando por una simple suite ofimática o cualquier servicio central de la organización.
Los administradores de sistemas y en especial el Director de Sistemas son los principales responsables de gestionar las migraciones a sistemas abiertos de la manera más transparente posible para la organización.
Toda empresa que este pensando en adoptar las bondades del Open Source debería considerar un enfoque estratégico siguiendo un conjunto de "buenas prácticas":
- Elige el componente correcto para el nivel adecuado de la infraestructura tecnológica.
- Realiza un cálculo del TCO.
- Define tu estrategia de soporte preferida del Open Source.
- Mejora las capacidades de administración del ciclo de vida de las aplicaciones.
- Analiza los proyectos para identificar riesgos en las licencias.
- Evalua el Open Source antes de seleccionar opciones comerciales.
- Integra e industrializa la administración de los despliegues de Open Source.
- Adopta prácticas de desarrollo ágil en conjunción con el Open Source.
- Define una política consistente del Open Source en la compañía.
- Participa en comunidades clave del Open Source.
Estudio elaborado por Forrester.
Leer Mas......
02 septiembre 2009
Como crear un buen entorno de administradores de sistemas
A través del blog mmejiav descubro el artículo "There is no 'I' in a great system administration team" que merece la pena leer para todos los que os paseeis por este blog.
Traducido también al castellano.
13 agosto 2009
Impulsa tu carrera contribuyendo en un proyecto Open Source
"Qué tu objetivo principal sea contribuir al proyecto, y no progresar en tu carrera. Cuando te des cuenta de la primera opción, la segunda vendrá de manera natural."
(http://theworkinggeek.com)
(http://theworkinggeek.com)
En relación al post que escribí hace meses "No hagas de becario, participa en un proyecto Open Source". Os dejo con esta interesante lectura; cómo impulsar tu carrera contribuyendo en proyectos Open Source.
Leer Mas......
31 julio 2009
30 junio 2009
sysadmin VS developers
Desde el día en que empece mi carrera como administrador de sistemas, poco a poco he ido observando como el temor amén de otros más, es uno de los sentimientos qué no te puedes quitar. Como administrador de sistemas eres el guardian de todo el parque tecnológico, servidores, equipos de usuario, eres como un proxy a todos los recursos informáticos allá donde trabajes, tienes que aguantar cientos de peticiones simultáneas y mantener el tipo en grandes picos de carga de trabajo y todo ello mientras dejas un log de todo lo que haces.
Pero no estoy solo. Hay quien siente y padece igual que nosotros, nos gusta aprender entre nosotros, y conocer nuevas vías de hacer tareas que hasta entonces hacías de otro modo. Es un sitio de sysadmins, un lugar donde compartir tus experiencias y dudas, un sitio exclusivo donde te comprenden, llamémosle House of Sysadmins.
Fuera de él, y lejos de tus compañeros de equipo, huele a hostilidad e incomprensión por ambas partes. Departamentos comerciales que debes quitarles permisos y no entienden por qué. Equipos de desarrollo cuyas necesidades crecen más que un log descontrolado. Por razones políticas o prácticas, la tecnología y nuestros colegas pueden sufrir de nuestros prejuicios, para bien o
para mal, estos prejuicios afectan en la manera que realizamos nuestro trabajo.
Pero no estoy solo. Hay quien siente y padece igual que nosotros, nos gusta aprender entre nosotros, y conocer nuevas vías de hacer tareas que hasta entonces hacías de otro modo. Es un sitio de sysadmins, un lugar donde compartir tus experiencias y dudas, un sitio exclusivo donde te comprenden, llamémosle House of Sysadmins.
Fuera de él, y lejos de tus compañeros de equipo, huele a hostilidad e incomprensión por ambas partes. Departamentos comerciales que debes quitarles permisos y no entienden por qué. Equipos de desarrollo cuyas necesidades crecen más que un log descontrolado. Por razones políticas o prácticas, la tecnología y nuestros colegas pueden sufrir de nuestros prejuicios, para bien o
para mal, estos prejuicios afectan en la manera que realizamos nuestro trabajo.
Ahora, con la perspectiva que da una dilatada experiencia, veo las cosas de otra manera. Los departamentos de sistemas por lo general estan vistos como áreas de costes que no aportan un beneficio directo a los objetivos de la empresa. Por ello, los administradores de sistemas estamos forzados a mostrar continuamente el valor de nuestro trabajo. Más a menudo de lo que nos gustaría, las matemáticas no juegan a nuestro favor para los departamentos financieros de nuestra empresa y nos convertimos en una nueva unidad integrada dentro de otra en la empresa, intentando camuflar ese costo necesario. En una de estas, muchos lo conocereis, nos vemos en la dura misión de dar soporte a "los desarrolladores".
Los desarrolladores (aka programadores) provienen de la misma familia geek que nosotros, pero no siempre nos integramos bien. Hubo un tiempo en el cual los programadores tuvieron que ser sus propios sysadmins y nosotros los sysadmins eramos desarrolladores de nuestras pequeñas herramientas.
Luego, ambos, escribíamos código para que las cosas funcionasen, pero estos días ya han pasado. Los tiempos han cambiado y ahora hacemos el trabajo que define nuestras profesiones. Aunque ambos grupos compartimos esas intensas guerras, donde a veces las cosas se tornan un poco tensas y otras estamos en periodos de calma.
Así que, ahora cabe preguntarnos, ¿qué podemos hacer al respecto?, ¿qué hemos aprendido en todos estos años en la administración de sistemas?
El punto más obvio es que "no queremos resolver más de 2 veces el mismo problema". En lugar de adoptar nuestra vieja y no productiva actitud de confrontación, podemos encararlo con maduridad. Deja atrás esas guerras del pasado intentando demostrar tú productividad. Tú sabes lo que haces y cómo lo haces, no gastes el tiempo demostrándolo a la gente.
Un componente importante en el soporte a los desarrolladores es la empatía. Recuerda que los desarrolladores no tienen la visibilidad que nosotros tenemos de todos los sistemas que administramos, cómo están las redes, accesos...
Un ejemplo: hace poco cuando intentaba solucionar un problema de directorios en un servidor apache, pregunté al desarrollador los aliases que necesitaba mapear a qué directorios. Ni se me ocurrio pensar que este usuario ni siquiera tenía login en la máquina, por lo que no sabía ni lo que era el httpd.conf. Todavía le hice la misma pregunta unas tres veces hasta que me dí cuenta de que no respondía a mi pregunta no porque no quisiera, sino porque no tenía ni idea de lo que le estaba hablando. Ten empatía con tus desarrolladores.
Cuando te enfrentes a un problema hazlo de manera elegante y encuentra la solución más práctica, entonces impleméntalo. No gastes mucho tiempo divagando sobre aspectos que al final no son importantes. Ir por el camino largo por seguir nuestros principos es ridículo.
Por ejemplo, si te gusta el Open Source, perfecto. Pero si no encaja en un proyecto, sigue y elige la solución más adecuada aún si es una solución propietaria. Tus desarrolladores tienen diferentes fechas de entrega que tú. Tienen fechas de entrega muy estrictas para sus proyectos y ellos no tienen la suerte de usar el enfoque ZEN que tenemos nosotros, todos sabeis de lo que hablo. Ellos apreciarán que tu trabajo sea rápido y efectivo.
Y esto nos lleva a otro punto, los desarrolladores son nuestros clientes. Somos tan responsables de ellos como lo es un camarero de sus clientes. Les damos la información correcta de lo que está y no está disponible. Conseguimos aquello que necesitan e intentamos que sea con una buena experiencia. Se trata de un servicio al consumidor.
En un bar, si tienes un mal servicio no volverás. Pero nuestros desarrolladores no tienen elección. OK, OK, estupendo puedes buscar las razones para no proporcionarles un buen servicio al consumidor, es muy tentativo pero existen unos pequeños problemas con este argumento:
Los desarrolladores (aka programadores) provienen de la misma familia geek que nosotros, pero no siempre nos integramos bien. Hubo un tiempo en el cual los programadores tuvieron que ser sus propios sysadmins y nosotros los sysadmins eramos desarrolladores de nuestras pequeñas herramientas.
Luego, ambos, escribíamos código para que las cosas funcionasen, pero estos días ya han pasado. Los tiempos han cambiado y ahora hacemos el trabajo que define nuestras profesiones. Aunque ambos grupos compartimos esas intensas guerras, donde a veces las cosas se tornan un poco tensas y otras estamos en periodos de calma.
Así que, ahora cabe preguntarnos, ¿qué podemos hacer al respecto?, ¿qué hemos aprendido en todos estos años en la administración de sistemas?
El punto más obvio es que "no queremos resolver más de 2 veces el mismo problema". En lugar de adoptar nuestra vieja y no productiva actitud de confrontación, podemos encararlo con maduridad. Deja atrás esas guerras del pasado intentando demostrar tú productividad. Tú sabes lo que haces y cómo lo haces, no gastes el tiempo demostrándolo a la gente.
Un componente importante en el soporte a los desarrolladores es la empatía. Recuerda que los desarrolladores no tienen la visibilidad que nosotros tenemos de todos los sistemas que administramos, cómo están las redes, accesos...
Un ejemplo: hace poco cuando intentaba solucionar un problema de directorios en un servidor apache, pregunté al desarrollador los aliases que necesitaba mapear a qué directorios. Ni se me ocurrio pensar que este usuario ni siquiera tenía login en la máquina, por lo que no sabía ni lo que era el httpd.conf. Todavía le hice la misma pregunta unas tres veces hasta que me dí cuenta de que no respondía a mi pregunta no porque no quisiera, sino porque no tenía ni idea de lo que le estaba hablando. Ten empatía con tus desarrolladores.
Cuando te enfrentes a un problema hazlo de manera elegante y encuentra la solución más práctica, entonces impleméntalo. No gastes mucho tiempo divagando sobre aspectos que al final no son importantes. Ir por el camino largo por seguir nuestros principos es ridículo.
Por ejemplo, si te gusta el Open Source, perfecto. Pero si no encaja en un proyecto, sigue y elige la solución más adecuada aún si es una solución propietaria. Tus desarrolladores tienen diferentes fechas de entrega que tú. Tienen fechas de entrega muy estrictas para sus proyectos y ellos no tienen la suerte de usar el enfoque ZEN que tenemos nosotros, todos sabeis de lo que hablo. Ellos apreciarán que tu trabajo sea rápido y efectivo.
Y esto nos lleva a otro punto, los desarrolladores son nuestros clientes. Somos tan responsables de ellos como lo es un camarero de sus clientes. Les damos la información correcta de lo que está y no está disponible. Conseguimos aquello que necesitan e intentamos que sea con una buena experiencia. Se trata de un servicio al consumidor.
En un bar, si tienes un mal servicio no volverás. Pero nuestros desarrolladores no tienen elección. OK, OK, estupendo puedes buscar las razones para no proporcionarles un buen servicio al consumidor, es muy tentativo pero existen unos pequeños problemas con este argumento:
- Es una respuesta particularmente no productiva. La conversación ni el trabajo avanza. Haz el trabajo en lugar de quejarte de como se deberían hacer.
- Además, te estás hiriendo a tí mismo. Tendrás que trabajar con esa persona durante días, meses y posiblemente años. Adoptar un enfoque de confrontación sólo te devolverá la misma actitud. Tendrás una mala experiencia cada vez que tengas que tratar con ese usuario o su equipo.
- Mas allá de todo esto, es tu responsabilidad. Nosotros los administradores de sistemas tenemos clientes internos y externos. Existen muchos roles dentro del campo de IT . Cuando nuestros clientes están satisfechos ganaremos en reputación y proporcionaremos todo lo necesario para aportar verdadero valor a la empresa que paga por nuestros servicios.
Nos guste o no, la palabra "social" forma parte de las descripciónes de trabajo de un administrador de sistemas. Podemos ser unos genios pero necesitamos reorientarnos hacia un servicio experto al cliente. Necesitamos reorientar nuestros objetivos, cuidar los sistemas, ayudar a la gente de la que somos responsables y todo ello mientras mantenemos nuestra profesionalidad.
No sigais nunca el ejemplo de este video:
No sigais nunca el ejemplo de este video:
Tenemos que aprender que renunciar al control puede llevarnos a mejores y caminos más creativos. Debemos construir puentes con los desarrolladores, analistas de bases de datos y gente no-técnica a quien damos soporte porque en algún punto, tendremos que cruzar puentes juntos y dependeremos de la relación que tengamos con toda esa gente que cada día se cruza en nuestro camino.
Artículo original.
Leer Mas......
Suscribirse a:
Entradas (Atom)
