Aínda que as solucións PaaS (Platform as a Service) por si soas non poden cambiar a forma en que os individuos e os equipos interactúan, moitas veces serven como catalizador para o cambio organizativo en resposta á maior axilidade das TI.
De feito, o máximo retorno dos investimentos en PaaS a miúdo só se pode conseguir cambiando os roles organizativos, as responsabilidades (tarefas) e as relacións. Afortunadamente, as solucións PaaS como OpenShift Container Platform son o suficientemente flexibles como para permitir que cada organización de TI determine a velocidade e escala do cambio en relación ás persoas implicadas e aos procesos que se producen.
Na primeira fase da contenerización empresarial, a principal prioridade é a implementación da plataforma de contedores como un novo sistema de implantación de aplicacións. Neste punto, as organizacións vinculan traballos coñecidos con roles coñecidos para responder ás solicitudes estándar dos equipos de desenvolvemento sobre cuestións como sistemas de almacenamento, contornos de implantación, etc. En fases posteriores de contenerización xa estamos a falar de automatización ou de dotar de capacidades de autoservizo aos desenvolvedores para reducir a carga dos administradores de sistemas e levar a un nivel superior a autonomía e a eficiencia dos desenvolvedores. Así é como unha organización comeza a avanzar cara a DevOps. Na fase final da contenerización, a empresa chega a un modelo DevOps máis puro e canónico, dentro do cal moitas das tarefas e traballos anteriores pasan ao control de equipos multifuncionais que se agrupan non por plataformas ou tecnoloxías, senón desde o punto de vista de vista de garantir o funcionamento de aplicacións ou servizos de aplicacións.
Nesta publicación, proporcionaremos orientación sobre como facer os cambios organizativos necesarios e como están cambiando os roles tradicionais de TI coa adopción de tecnoloxías de contedores na empresa.
Vinculación de novos postos de traballo aos antigos
Na súa forma inicial básica, o modelo organizativo PaaS está deseñado para asignar recursos de TI ás aplicacións de forma máis flexible e rápida como un ambiente de execución. Aínda que isto proporciona certas vantaxes para os administradores do sistema, os desenvolvedores normalmente non obteñen ningún beneficio significativo nin novas capacidades, xa que nesta fase, unha empresa pode prescindir facilmente da automatización, o autoservizo ou a mellora radical da canle de despregamento. Aínda que ten un impacto mínimo nos procesos de desenvolvemento nesta fase, PaaS aumenta a axilidade do sistema de TI, o que permite aos administradores atender mellor as solicitudes dos desenvolvedores. Por exemplo, mentres que anteriormente se creaba un ambiente de desenvolvemento a partir de varios máquinas virtuais Mentres que a creación e o despregamento de volumes de almacenamento podían levar días ou incluso semanas, o que requiría a participación de varios administradores diferentes, en PaaS todo se fai moito máis rápido e por un só administrador. Noutras palabras, os equipos de desenvolvemento envían solicitudes como antes, pero o traballo para implementalas agora realízase segundo un novo modelo.
Cara a unha organización DevOps
Ao lanzar PaaS e facer a transición de especialistas en operacións de TI e desenvolvedores de aplicacións a el, a organización pode seguir implementando a metodoloxía DevOps, que, entre outros, inclúe os seguintes principios básicos:
- Divide o traballo en pequenos pasosrecibir retroalimentación temprana, reducir riscos e evitar a parálise da análise;
- Automatizar as operacións suficientementepara evitar a creación de obstáculos ou colos de botella no proceso de implantación da aplicación;
- Intercambio de coñecemento - a clave para crear confianza;
- Paga regularmente as débedas técnicas, destinando un tempo determinado en cada ciclo de traballo para melloras sistemáticas.
Na segunda fase da adopción da tecnoloxía de contedores, os equipos de desenvolvemento comezan naturalmente a ver oportunidades de mellora e a empresa aposta por un modelo DevOps máis tradicional. O mecanismo tradicional de envío e cumprimento de solicitudes de servizo agora percíbese como un pescozo de botella, polo que a organización busca automatizar accións repetitivas e proporcionar capacidades de autoservizo aos desenvolvedores. Ademais, estas capacidades de programador dentro dunha determinada aplicación ven determinadas polos esforzos conxuntos dos especialistas informáticos que operan as plataformas e dos responsables de entregar as aplicacións. Noutras palabras, os administradores do sistema, que realizan accións a petición dos desenvolvedores, están a ser substituídos polas dúas categorías de empregados mencionadas anteriormente, que se encargan de describir e aplicar as políticas que regulan o que os desenvolvedores poden facer exactamente por si mesmos. Os procedementos automatizados axudan a garantir o cumprimento dos requisitos especificados e coordinan as accións cando unha situación queda fóra do ámbito das políticas existentes.
Pasando a un calendario iterativo, no que o ambiente de TI e o modelo operativo experimentan cambios iterativos ao longo do tempo, é un fito fundamental para lograr unha empresa DevOps madura. O grao de adopción da metodoloxía DevOps depende da tolerancia ao cambio de cada organización individual e cales son os cambios que traen máis beneficios. Por exemplo, se a necesidade de crear novos ambientes ou aplicacións ocorre con pouca frecuencia, a optimización das actividades correspondentes será menos importante que aumentar o control do programador sobre o ciclo de vida da aplicación.
Novos retos que xorden nas organizacións de TI ao migrar a OpenShift
Nesta sección, analizaremos os roles e tarefas que as organizacións que adoptaron OpenShift adoitan utilizar para acelerar a automatización e o autoservizo mediante tecnoloxía e PaaS.
A seguinte táboa enumera as principais tarefas de nivel superior que existen en calquera organización que implementou OpenShift, con exemplos de traballos e habilidades relacionados. Esta lista de tarefas non debe confundirse cunha estrutura de desagregación de traballo ou unha estrutura de equipo, senón cun conxunto de tarefas que deben ser completadas polos responsables de dar soporte ao/s entorno/s de TI para a implantación exitosa dunha plataforma de contedores. De feito, demostraremos ademais que a introdución de tecnoloxías de contedores crea os requisitos previos para a formación dunha estratexia DevOps máis madura na empresa, o que á súa vez aumenta o grao de funcionalidade cruzada dos equipos e reduce os riscos de especialización estreita no sector. nivel individual e por equipos.
Táboa 1. Definicións de tarefas de OpenShift
tarefas
Habilidades necesarias
Automatización e aprovisionamento de infraestruturas informáticas
Obras:
- Deseño e construción de solucións hardware
- Organización e apoio á automatización da configuración inicial
- Deseño e automatización de VM e preparación do host
- Deseño e implantación de centros de datos
- Administración do sistema Linux
- Escenarios de automatización
- Coñecemento de sistemas de almacenamento
- Coñecementos de deseño e implantación de redes
- Безопасность
Instalación e xestión da plataforma OpenShift
Obras:
- Realización dunha instalación de cluster
- Xestión do servizo de infraestruturas
- Xestión de escalado da plataforma
- Autenticación e autorización a nivel de plataforma
- Administración do sistema Linux
- Coñecemento das tecnoloxías de rede
- Scripts de automatización (Ansible)
- Coñecemento de sistemas de almacenamento
- Coñecemento de tecnoloxías e arquitecturas de contedores
- Coñecemento das arquitecturas Kubernetes e OpenShift
- Seguridade da plataforma
- Seguimento da integración
Xestionar a preparación de contornas de clientes (aprovisionamento de inquilinos), illamento das capacidades informáticas
Obras:
- Creación de usuarios e equipos dentro da plataforma
- Deseño e xestión de cotas
- Deseño e Implantación de RBAC
- Coñecemento das arquitecturas Kubernetes e OpenShift
- Coñecemento de tecnoloxías e arquitecturas de contedores
- Escenarios de automatización
- Bo coñecemento de proxectos, cotas, asignacións de roles e traballo con planificadores
Creación e xestión de imaxes base
Obras:
- Desenvolvemento dun fluxo de traballo de modificación de imaxes
- Desenvolvemento de imaxes baseado en estándares
- Administración do sistema Linux
- Escenarios de automatización
- Configuración de compoñentes de aplicacións en tempo de execución e middleware
- Coñecemento de arquitecturas de contedores
- Marcos de creación de aplicacións
- Bos coñecementos de imaxes, fluxo de imaxes e modelos
Deseñar e xestionar canalizacións de implantación
Obras:
- Deseño e documentación de normas de transporte
- Desenvolvemento de guías rápidas e modelos
- Formación para desenvolvedores
- Xestión do código fonte
- Deseño e implementación de aplicacións
- Escenarios de automatización
- Probas automatizadas
- Probas de calidade do código
- Coñecemento de arquitecturas de contedores
- Coñecemento de infraestruturas inmutables
- Seguridade: xestionar o acceso ás fases do pipeline, aprobar fluxos de traballo, etc.
- Bos coñecementos de modelos OpenShift, compoñentes buildconfigs, deploymentconfigs, servizos, rutas, configmaps
Desenvolvemento de aplicacións e probas
Obras:
- Codificación da aplicación
- Desenvolvemento de probas automatizadas
- Responder aos fallos das probas durante a canalización de implantación
- Resposta aos fallos da aplicación
- Probas de aceptación de usuarios
- Deseño e implementación de aplicacións
- Probas automatizadas
- Xestión do código fonte
- Seguimento da aplicación
- Coñecemento de arquitecturas de aplicacións nativas na nube
Seguimento operativo e xestión de aplicacións
Obras:
- Deseño de aplicacións no contexto da actuación
- Monitorización de aplicacións en tempo de execución
- Escalado de aplicacións (ou autoescalado)
- Xestión da dispoñibilidade de aplicacións
- Solicitar cotas e límites de xestión de recursos
- Probas de rendemento e capacidade de TI
- Deseño e implementación do rendemento da aplicación
- Seguimento do rendemento da aplicación
- Probas de rendemento e carga
Probas de aceptación de usuarios
Obras:
- Probas de IU (deseño e experiencia de usuario)
- Desenvolvemento de probas automatizadas
- Deseñar e probar interfaces de usuario
- Patróns de probas automatizadas
- Marcos de proba
- Patróns de deseño de aplicacións
Novos roles que xorden nunha organización de TI ao migrar a OpenShift
A medida que pasas a un modelo organizativo centrado en DevOps, a cantidade de especialización de roles tende a diminuír e, á súa vez, o número de equipos e roles transversais aumenta para maximizar a eficiencia da colaboración. Este é o que pensamos que é a lista de postos clave nunha organización de TI que usa OpenShift:
- Enxeñeiro de Operacións de Aplicacións OU Enxeñeiro de Fiabilidade do Sitio. Anteriormente, esta posición puido chamarse "Administrador do servidor de aplicacións".
- Desenvolvedor de aplicacións/Desenvolvedor de software/Enxeñeiro de software.
- Administrador da plataforma de clústeres/aplicacións. Anteriormente, este rol podía chamarse "Administrador do sistema" ou "Administrador" Linux-plataformas".
- Xestor de versións/Enxeñeiro de construción.
Matriz de roles e tarefas RACI
Finalmente, pasamos a comparar as posicións e tarefas comentadas anteriormente para dar unha idea xeral de como debería ser a estrutura dunha organización que implementa DevOps na plataforma OpenShift. Inicialmente, os seguintes roles poden ser ocupados por diferentes ramas da antiga estrutura organizativa tradicional. Pero co paso do tempo, prodúcese a consolidación e constrúense novos equipos en torno a aplicacións que asumen a maioría ou mesmo todas as tarefas que se indican a continuación.
tarefas
Papeis
Enxeñeiro de operacións de aplicacións / Enxeñeiro de fiabilidade do sitio
Desenvolvedor de aplicacións / Desenvolvedor de software / Enxeñeiro de software
Administrador de Clúster/Plataforma de Aplicacións
Xestor de versións de software/Enxeñeiro de montaxe
Automatización e aprovisionamento de infraestruturas informáticas
I
I
R / A
C
Instalación e xestión da plataforma OpenShift
C
I
R / A
C
Deseñar e xestionar canalizacións de implantación
C
C
I
R / A
Xestione o aprovisionamento dos inquilinos, o illamento e a capacidade de TI
C
I
R / A
I
Creación e xestión de imaxes base
R
C
R / A
C
Desenvolvemento de aplicacións e probas
C
R / A
I
I
Seguimento operativo e xestión de aplicacións
R / A
C
C
I
Probas de aceptación de usuarios
C
R
I
I
Convencións na matriz RACI
Fonte:
- Responsable – O intérprete é quen fai o necesario para completar a tarefa.
- Responsable – Responsable: un empregado que é o último responsable da execución correcta e exhaustiva dunha tarefa ou da consecución dun resultado; e tamén a única que pode delegar o traballo en intérpretes.
- Consultado – Consultores: normalmente son expertos na materia cuxo asesoramento se solicita; Mantense con eles a comunicación bidireccional.
- Informado - Informado: persoas que se mantén informadas dos acontecementos (e ás veces só despois de completar unha tarefa ou lograr un resultado); reciben información unilateralmente.
Como traballan os equipos nunha organización DevOps
A adquisición de recursos tradicional normalmente implica un ciclo de solicitudes de recursos que despois son executadas por varios equipos. En definitiva, todos os recursos necesarios son asignados e confirmados pola parte solicitante. Moitas veces, estes procesos son parcial ou totalmente manuais e requiren interaccións frecuentes e múltiples entre os equipos para procesar con éxito cada solicitude.
Figura 1. Organización informática tradicional
O diagrama anterior ilustra as relacións típicas entre os equipos nunha organización de TI tradicional. Neste esquema, algúns equipos póñense en contacto con outros equipos para solicitar a realización do traballo necesario, utilizando medios de comunicación máis ou menos formais, como un sistema de tickets ou correo electrónico. Estas peticións entran en fila e agardan nas bandas, con longas esperas que adoitan levar a un empeoramento, ou mesmo a exacerbación, das relacións entre os equipos. Engádese á tensión o feito de que os membros de diferentes equipos raramente se reúnen en persoa e tenden a compartir só a mínima información necesaria.
Figura 2: Organización de TI de DevOps
Este diagrama mostra como funciona a colaboración nunha organización DevOps. Aquí, os mesmos equipos do diagrama anterior abandonaron as comunicacións ineficaces que reforzaban os silos e substituíronas por contactos persoais, creando así canles constantes de interacción entre os equipos. Estas canles fomentan un conxunto de habilidades híbridas que axudan aos empregados a comprender e visualizar mellor as necesidades, desafíos e oportunidades dos equipos aos que representan. Os equipos facultan mutuamente para completar o traballo a través de portais de autoservizo automatizados, en lugar de xestionar manualmente as solicitudes de cambio doutras persoas, como era o caso no pasado. E grazas á presenza de canles de interacción, estes sistemas de autoservizo poden adaptarse rapidamente ás necesidades dos equipos para os que están deseñados. Para lograr unha maior comprensión e intercambio de coñecementos dentro da organización, os membros do equipo rotan periódicamente os roles para adquirir experiencia interactuando con diferentes equipos e comprender mellor o panorama xeral dos sistemas de TI que admiten, aumentando así o seu nivel de funcionalidade e utilidade cruzadas.
Resumo
Nesta publicación, discutimos como a adopción de solucións PaaS pode mover unha organización cara a DevOps, cambiando os roles e tarefas tradicionais como parte do proceso. É por iso que enumeramos os principais desafíos informáticos aos que se enfronta unha organización ao migrar a OpenShift, así como as habilidades necesarias para completalos. Tamén proporcionamos un conxunto básico de roles organizativos que xorden cando se crean equipos de DevOps multifuncionais e unha matriz RACI que vincula novos roles con novas tarefas. Finalmente, discutimos como a plataforma OpenShift e a súa metodoloxía DevOps asociada poden cambiar a estrutura organizativa das organizacións a medida que pasan das xerarquías e sistemas de tickets tradicionais a equipos multifuncionais cun maior nivel de comunicación persoal.
Fonte: www.habr.com
