ESCENARIOS: MIGRACIÓN Para un administrador de sistemas, uno de los primeros retos será la migración de cargas de trabajo de infraestructuras físicas y virtualizadas de un centro de datos privado (onsite) a un proveedor de nube pública. Onsite --> Localización propia de la organización, frente a una ubicación offsite, a la que la organización tiene acceso por red. Ejemplo de entorno offsite tradicionasl: centro de datos o una parte de un centro de datos subalquilado a un proveedor. La solución más sencilla para poder crear una imagen del sistema existenque que ofree el 80% más de funcionalidad seria hacer una copia del sistema, que consiste en copiarla al proveedor de la nube y arrancarla en la nueva ubicación. La copia del sistema permite à delegar la administración de la infraestructura física y virtual al proveedor y mantener el funcionamiento familiar al que están acostumbrados los administradores. No permite gestionar el ciclo de vida de las aplicaciones existentes. Entorno DevOps à se debería apostar por automatizar el despliegue, al menos, de todas las aplicaciones nuevas y, en lo posible, de las existentes, para poder disfrutar de todas las ventajas de un entorno de nube.
ESCENARIOS: ENTORNOS HÍBRIDOS DevOps --> Tendrá que combinar sus conocimientos de desarrollo y administración con conocimientos de red para poder establecer las conexiones adecuadas. Estos recursos de red serán en muchos casos virtuales y, por lo tanto, también deberán ser automatizados.
ESCENARIOS: APROVISIONAMIENTO Impartición del cloud computing à permite que DevOps dispongan de recursos renovables, reciclables y fáciles de proveer. Crear un nuevo servidor es tan simple como hacer unos clics en una consola web. El reemplazo de un servidor existente es sencillo si está automatizado su despliegue y configuración. Aprovisionamiento mucho más rápido en la nube. Si la carga de un servidor es muy alta, hay dos opciones: Lanzar más instancias Lanzar un servidor nuevo de mayor tamaño utilizando las automatizaciones Los DevOps deben ahora vigilar el coste de funcionamiento del entorno. Los costes de hardware se han reemplazado por el pago por uso, a veces, pero no siempre, con el coste de licencia incluido. Los contratos de soporte se han trasladado de los proveedores de hardware a los proveedores de infraestructura. Este equilibrio ayudará a los DevOps a trabajar con otros para construir una solución rentable y confiable
ESCENARIOS: SEGURIDAD Los proveedores son responsables de asegurar el acceso físico al hardware, pero la infraestructura debe ser accedida de forma remota por definición. Los DevOps deben estar familiarizados con el modelo de seguridad de su proveedor de nube. Los roles, grupos, usuarios y políticas tienen mecanismos comunes para otorgar y restringir el acceso. Permitir o bloquear el acceso a red es un trabajo tradicionalmente de los administradores de red. En la nube es habitual que este trabajo recaiga en los DevOps, que aprovecharán la automatización para reducir los riesgos de seguridad de red.
1.5 ESCENARIOS: DISPONIBILIDAD Disponibilidad (uptime) cercana al 100 %. Las máquinas en la nube a veces necesitan ser movidas para tareas de mantenimiento o incluso apagadas por parte del proveedor. La única forma de garantizar la disponibilidad es contar con mecanismos que permitan desplegar flotas de servidores autogestionados. Flota --> Grupo de autoescalado en AWS (Amazon Web Services) o en un despliegue en Kubernetes, por citar algunos. Los objetivos detrás de un grupo de servidores autogestionados son: Ser posible realizar las siguientes acciones sin intervención humana: Apagar un servidor que ha dejado de funcionar. Añadir un servidor nuevo. Poder actualizar el sistema de forma incremental sin que se produzca una caída del mismo. Paradigma de las mascotas y el ganado --> Los servidores aparecen y desaparecen sin intervención humana. Los servidores tradicionales eran tratados como mascotas: provisionar uno llevaba mucho tiempo y los administradores hacían lo posible para mantenerlo funcionando todo el tiempo. Los servidores modernos en la nube se parecen más al ganado: es posible tener tantos que no merece la pena preocuparse por cada uno en particular. La automatización es la base sobre la que se construyen las aplicaciones de escalado y de despliegue.
SERVIDORES VS EQUIPOS DE ESCRITORIOS El concepto de servidor se limita al de una instalación de un sistema operativo pensado para ejecutar aplicaciones para clientes. Los sistemas operativos usados como servidores no son muy diferentes de los que ejecutan los ordenadores de sobremesa o los portátiles. Ambos tipos tienen un núcleo, una arquitectura de sobremesa o los portátiles. Ambos tipos tienen también un núcleo, una arquitectura de procesador habitualmente compatible, controladores de hardware y utilizades de software. Muchos de los ejemplos descritos pueden ejecutarse en un entorno de escritorio sin cambio alguno.
LINUX VS WINDOWS La elección de uno u otro debe estar marcada por las necesidades de la aplicación, la organización y los usuarios. Linux à Es una buena opción para una aplicación nueva, diseñada con una arquitectura nativa en la nube, gracias al soporte nativo de contenedores. Windows à Parte con la ventaja de facilitar la administración de políticas de seguridad de manera centralizada.
TAREAS TRADICIONALES Cada organización define los roles y las responsabilidades de sus administradores. El ámbito de las tareas cambia de una organización a otra y también cambia según evoluciona la organización; pero hay algunas tareas que cualquier administrador tiene: Instalación de servidores y clientes. Instalación y mantenimiento de aplicaciones Creación de usuarios y grupos. Soporte a usuarios. Copias de seguridad y recuperación frente a desastres Seguridad. Automatización de tareas Instalación de periféricos como impresoras. Gestión de cambios. Configuración de equipos de red local. Muchos grupos de soporte de TIC dividen las tareas en roles, donde cada uno de ellos crea una base de conocimiento profunda para resolver problemas y ejecutar tareas. Una separación de tareas en roles podría ser en servicios de usuario, administrador de servidores y seguridad de las TIC: Servicios de usuario: Nivel 2 de soporte a usuario Instalación de periféricos. Instalación y mantenimiento de aplicaciones. Instalación de equipos de usuario. Administración de servidores: Instalación de servidores. Creación de usuarios y grupos. Copias de seguridad y recuperación frente a desastres. Automatización de tareas. Seguridad de las TIC: Soporte de red Gestión de cambios. Las tareas se separan en tres roles, que facilitan la separación de responsabilidades y, por tanto, las operaciones y la resolución de problemas. Esto, a su vez, incrementa las habilidades y el entrenamiento técnico del personal en cada rol. Las organizaciones más pequeñas suelen unir estos roles. Una manera de optimizar las horas de un equipo pequeño es estandarizar el despliegue de equipos, ya sean servidores o de escritorio. Cuanto más se parecen los servidores entre sí, más fácil es resolver los problemas que puedan aparecer en el día a día. Esto, además, facilita el soporte y mejora su calidad. OPERACIONES Estos procesos están integrados en aplicaciones de soporte y enlazan tanto aspectos operacionales como procesos clave de la administración del servicio, como gestión de cambios, control de configuración, inventario, catálogo de servicios, gestión de incidencias, etc. Estas aplicaciones son complejas y caras, y requieren un conocimiento avanzado de los procesos de negocio y de la naturaleza técnica del mismo. En departamentos pequeños, un administrador puede usar una lista diaria o semanal para gestionar sus tareas, además de coordinarse con otros equipos para asegurarse de que todos los sistemas funcionan correctamente. COMUNICACIÓN La información debe fluir en dos sentidos. Los administradores reciben peticiones de soporte y se ven obligados a cerrarlas rápido, penalizando la calidad del soporte, debido a las métricas con las que se les evalúa a final de año. Esto limita la involucración del usuario que inició la comunicación, así como del resto de los individuos que han formado parte de la resolución. La documentación de estas soluciones se suele llevar a cabo en un knowledge base (KB), o base o biblioteca de conocimiento. Incluso algunas organizaciones publican estos KB al exterior (bien públicamente o al menos a un sector interno más amplio que el propio equipo de TIC) para facilitar la resolución proactiva de problemas. Esto último enlaza con la necesidad de educar e informar al usuario. Si los usuarios finales reciben información sobre la resolución de sus problemas, a largo plazo facilitan el trabajo de los equipos de soporte. También ayuda hacer que todos estén al tanto de las tareas del día a día y el mantenimiento preventivo. Un objetivo de los departamentos es tener una política 90-8-2: Los usuarios resuelven por sí mismos el 90 % de las incidencias. Los grupos de soporte intermedios se encargan de resolver un 8 %, que serán situaciones más complicadas; pero normalmente documentadas y en las que no hay que involucrar a un experto. Los administradores solo reciben un 2 % de los problemas. Así se pueden dedicar a tareas en las que añaden valor a la organización. INVESTIGACIÓN Estar al tanto de las novedades en IT ayuda a ser proactivo con posibles problemas externos. Hay muchas revistas técnicas gratuitas (Information Week, Redmond Magazine, Information Security Magazine), así como excelentes sitios de investigación en la web (Whatis.com, EventID.net, Tech Republic). Ampliar los conocimientos con este tipo de recursos mejora la sensibilidad operacional. FORMACIÓN Las certificaciones hacen que los administradores y la operativa de IT sean más respetadas por sus clientes y, en algunos casos, es un requisito para optar a un contrato. Proporciona experiencia interna reconocida por la industria y asegura a quienes utilizan sus servicios que la organización cumple con los estándares. Además, facilita el networking y no en el sentido técnico, sino en cuanto a las relaciones profesionales con otros individuos del sector. CONFIANZA Un sistema bien administrado permite que las organizaciones lleven a cabo sus negocios de manera estable, sin necesidad de que los usuarios de las aplicaciones tengan que comprender ni su arquitectura ni la operativa necesaria. Cuando se consiguen estos objetivos, se promueve la confianza de la organización y de los usuarios en el equipo de IT y viceversa. ¿QUÉ HAY QUE CAMBIAR? Un equipo DevOps aplicará muchos de estos principios en su día a día: deberá organizar sus tareas, probablemente se especializarán en roles en función de sus fortalezas y, en cierta medida, estarán involucrados en tareas de soporte. Quizás no sigan ITIL a rajatabla, pero eso no impide que documenten sus procesos o estandaricen sus roles, tareas y herramientas.
TAREAS EN LA NUBE Término nube à idea de servicios informáticos y de aplicaciones escalables a demanda, en lugar de servicios «basados» en la nube, como Google Mail. Las economías de escala están constantemente bajando el precio de los servicios en la nube. Para las empresas, la nube abre nuevas vías de flexibilidad. Los equipos tecnológicos pueden hacer cosas que hubieran sido prohibitivamente caras hace solo unos años. Los juegos y las aplicaciones que tienen la suerte de convertirse en éxitos desbocados a menudo requieren una gran cantidad de capacidad de cómputo. Provisionar esta capacidad en horas en lugar de semanas permite a estas compañías responder rápidamente al éxito, sin entrar en inversiones y compromisos de gasto por varios años o gastos iniciales de capital. Para los DevOps los desarrolladores y la dirección saben lo importante que es iterar y mejorar rápidamente el código de aplicación. Los servicios de los proveedores de nube permiten tratar la infraestructura de la misma manera, permitiendo que un equipo relativamente pequeño administre infraestructuras de aplicaciones masivamente escalables.
Want to create your own Notes for free with GoConqr? Learn more.