Tot i que les solucions PaaS (Platform as a Service) per si soles no poden canviar la manera com els individus i els equips interactuen, sovint serveixen com a catalitzador del canvi organitzatiu en resposta a l'augment de l'agilitat informàtica.
De fet, sovint només es pot aconseguir el màxim rendiment de les inversions en PaaS canviant els rols organitzatius, les responsabilitats (tasques) i les relacions. Afortunadament, les solucions PaaS com la plataforma de contenidors OpenShift són prou flexibles com per permetre a cada organització informàtica determinar la velocitat i l'escala del canvi en relació amb les persones implicades i els processos que es produeixen.
En la primera etapa de la contenidorització empresarial, la prioritat principal és la implementació de la plataforma de contenidors com a nou sistema de desplegament d'aplicacions. En aquest punt, les organitzacions lliguen feines familiars a rols coneguts per respondre a les sol·licituds estàndard dels equips de desenvolupament sobre qüestions com ara sistemes d'emmagatzematge, entorns de desplegament, etc. En les etapes posteriors de la contenidorització, ja estem parlant d'automatització o de dotar de capacitats d'autoservei als desenvolupadors per tal de reduir la càrrega dels administradors de sistemes i portar l'autonomia i l'eficiència dels desenvolupadors a un nivell superior. Així és com una organització comença a avançar cap a DevOps. En l'etapa final de la contenidorització, l'empresa arriba a un model de DevOps més pur i canònic, dins del qual moltes de les tasques i treballs anteriors passen sota el control d'equips multifuncionals que s'agrupen no per plataformes o tecnologies, sinó des del punt de vista de visió de garantir el funcionament d'aplicacions o serveis d'aplicacions.
En aquesta publicació, oferirem orientació sobre com fer els canvis organitzatius necessaris i com estan canviant els rols de TI tradicionals amb l'adopció de tecnologies de contenidors a l'empresa.
Vincular nous llocs de treball amb antics rols
En la seva forma bàsica inicial, el model organitzatiu PaaS està dissenyat per assignar recursos informàtics a les aplicacions de manera més flexible i ràpida com a entorn d'execució. Si bé això proporciona certs avantatges per als administradors de sistemes, els desenvolupadors normalment no obtenen cap benefici significatiu ni noves capacitats, ja que en aquesta etapa, una empresa pot prescindir fàcilment de l'automatització, l'autoservei o de la millora radical del pipeline de desplegament. Tot i que té un impacte mínim en els processos de desenvolupament en aquesta etapa, PaaS augmenta l'agilitat del sistema informàtic, permetent als administradors atendre millor les sol·licituds dels desenvolupadors. Per exemple, mentre que anteriorment es creava un entorn de desenvolupament a partir de diversos màquines virtuals Mentre que la creació i el desplegament de volums d'emmagatzematge poden trigar dies o fins i tot setmanes, i requereixen la participació de diversos administradors, en PaaS tot es fa molt més ràpid i només ho fa un administrador. En altres paraules, els equips de desenvolupament envien sol·licituds com abans, però el treball per implementar-les ara es duu a terme segons un nou model.
Cap a una organització DevOps
Mitjançant el llançament de PaaS i la transició d'especialistes en operacions de TI i desenvolupadors d'aplicacions, l'organització pot continuar implementant la metodologia DevOps, que, entre d'altres, inclou els següents principis bàsics:
- Desglosseu el treball en petits passosrebre retroalimentació primerenca, reduir riscos i evitar la paràlisi de l'anàlisi;
- Automatitzar prou les operacionsper evitar la creació d'obstacles o colls d'ampolla en el procés de desplegament de l'aplicació;
- Intercanvi de coneixements – la clau per generar confiança;
- Pagar regularment els deutes tècnics, destinant un temps determinat en cada cicle de treball per a millores sistemàtiques.
En la segona fase d'adopció de tecnologia de contenidors, els equips de desenvolupament comencen a veure oportunitats de millora, i l'empresa s'inclina cap a un model DevOps més tradicional. El mecanisme tradicional d'enviament i compliment de sol·licituds de servei ara es percep com un coll d'ampolla, de manera que l'organització busca automatitzar accions repetitives i oferir capacitats d'autoservei als desenvolupadors. A més, aquestes capacitats de desenvolupador dins d'una aplicació determinada estan determinades pels esforços conjunts dels especialistes informàtics que operen les plataformes i els responsables de lliurar les aplicacions. En altres paraules, els administradors de sistemes, que realitzen accions a petició dels desenvolupadors, estan sent substituïts per les dues categories d'empleats esmentades anteriorment que s'encarreguen de descriure i aplicar les polítiques que regulen el que els desenvolupadors poden fer per si mateixos. Els procediments automatitzats ajuden a garantir el compliment dels requisits especificats i a coordinar les accions quan una situació queda fora de l'abast de les polítiques existents.
Passar a un calendari iteratiu, en el qual l'entorn informàtic i el model operatiu pateixen canvis iteratius al llarg del temps, és una fita crítica per aconseguir una empresa DevOps madura. El grau d'adopció de la metodologia DevOps depèn de la tolerància al canvi de cada organització individual i quins canvis aporten més beneficis. Per exemple, si la necessitat de crear nous entorns o aplicacions es produeix amb poca freqüència, l'optimització de les activitats corresponents serà menys important que augmentar el control del desenvolupador sobre el cicle de vida de l'aplicació.
Nous reptes que sorgeixen a les organitzacions de TI en migrar a OpenShift
En aquesta secció, analitzarem els rols i les tasques que solen utilitzar les organitzacions que han adoptat OpenShift per accelerar l'automatització i l'autoservei mitjançant tecnologia i PaaS.
La taula següent enumera les principals tasques de primer nivell que existeixen a qualsevol organització que hagi implementat OpenShift, amb exemples de feines i habilitats relacionades. Aquesta llista de tasques no s'ha de confondre amb una estructura de desglossament del treball o una estructura d'equip, sinó amb un conjunt de tasques que han de completar els responsables de donar suport a l'entorn o entorns informàtics per a la implementació satisfactòria d'una plataforma de contenidors. De fet, mostrarem a més que la introducció de tecnologies de contenidors crea els requisits previs per a la formació d'una estratègia DevOps més madura a l'empresa, que al seu torn augmenta el grau de funcionalitat creuada dels equips i redueix els riscos d'una especialització estreta a nivell empresarial. nivell tant individual com per equips.
Taula 1. Definicions de tasques OpenShift
tasques
Habilitats requerides
Automatització i subministrament d'infraestructures informàtiques
Obres:
- Disseny i construcció de solucions de maquinari
- Organització i suport de l'automatització de la configuració inicial
- Disseny i automatització de VM i preparació de l'amfitrió
- Disseny i implantació de centres de dades
- Administració del sistema Linux
- Escenaris d'automatització
- Coneixement de sistemes d'emmagatzematge
- Coneixements de disseny i implementació de xarxes
- Безопасность
Instal·lació i gestió de la plataforma OpenShift
Obres:
- Realització d'una instal·lació de clúster
- Gestió del servei d'infraestructures
- Gestió de l'escala de la plataforma
- Autenticació i autorització a nivell de plataforma
- Administració del sistema Linux
- Coneixement de tecnologies de xarxa
- Scripts d'automatització (Ansible)
- Coneixement de sistemes d'emmagatzematge
- Coneixement de tecnologies i arquitectures de contenidors
- Coneixements de les arquitectures Kubernetes i OpenShift
- Seguretat de la plataforma
- Monitorització de la integració
Gestió de la preparació dels entorns de client (provisionament de llogaters), aïllament de les capacitats TI
Obres:
- Creació d'usuaris i equips dins de la plataforma
- Disseny i gestió de quotes
- Disseny i Implementació RBAC
- Coneixements de les arquitectures Kubernetes i OpenShift
- Coneixement de tecnologies i arquitectures de contenidors
- Escenaris d'automatització
- Bon coneixement de projectes, quotes, assignacions de rols i treball amb planificadors
Construcció i gestió d'imatges base
Obres:
- Desenvolupament d'un flux de treball de modificació d'imatges
- Desenvolupament d'imatges basat en estàndards
- Administració del sistema Linux
- Escenaris d'automatització
- Configuració de components d'aplicacions en temps d'execució i middleware
- Coneixements d'arquitectures de contenidors
- Frameworks de creació d'aplicacions
- Bons coneixements d'imatges, flux d'imatges i plantilles
Dissenyar i gestionar canalitzacions de desplegament
Obres:
- Disseny i documentació d'estàndards de transportadors
- Desenvolupament de guies ràpides i plantilles
- Formació de desenvolupadors
- Gestió del codi font
- Disseny i implementació d'aplicacions
- Escenaris d'automatització
- Proves automatitzades
- Proves de qualitat del codi
- Coneixements d'arquitectures de contenidors
- Coneixement d'infraestructures immutables
- Seguretat: gestió de l'accés a les etapes del pipeline, aprovació de fluxos de treball, etc.
- Bons coneixements de plantilles OpenShift, components buildconfigs, deploymentconfigs, serveis, rutes, configuracions
Desenvolupament d'aplicacions i proves
Obres:
- Codificació de l'aplicació
- Desenvolupament de proves automatitzades
- Resposta als errors de les proves durant la canalització de desplegament
- Resposta als errors de l'aplicació
- Prova d'acceptació d'usuaris
- Disseny i implementació d'aplicacions
- Proves automatitzades
- Gestió del codi font
- Seguiment d'aplicacions
- Coneixement d'arquitectures d'aplicacions natives del núvol
Supervisió operativa i gestió d'aplicacions
Obres:
- Disseny d'aplicacions en el context del rendiment
- Monitorització d'aplicacions en temps d'execució
- Escalat de l'aplicació (o autoescalat)
- Gestió de la disponibilitat d'aplicacions
- Sol·licitar quotes i límits de gestió de recursos
- Proves de rendiment i capacitat informàtica
- Disseny i implementació de rendiment d'aplicacions
- Supervisió del rendiment de l'aplicació
- Proves de rendiment i càrrega
Prova d'acceptació d'usuaris
Obres:
- Proves d'IU (disseny i experiència d'usuari)
- Desenvolupament de proves automatitzades
- Dissenyar i provar interfícies d'usuari
- Patrons de prova automatitzats
- Marcs de prova
- Patrons de disseny d'aplicacions
Nous rols que sorgeixen en una organització de TI en migrar a OpenShift
A mesura que passeu a un model organitzatiu centrat en DevOps, la quantitat d'especialització de rols tendeix a disminuir i, al seu torn, augmenta el nombre d'equips i rols multifuncionals per maximitzar l'eficiència de la col·laboració. Aquest és el que pensem que és la llista de llocs clau en una organització informàtica que utilitza OpenShift:
- Enginyer d'operacions d'aplicacions O Enginyer de fiabilitat del lloc. Anteriorment, aquesta posició podria haver estat anomenada "Administrador del servidor d'aplicacions".
- Desenvolupador d'aplicacions/Desenvolupador de programari/Enginyer de programari.
- Administrador de la plataforma de clústers/aplicacions. Anteriorment, aquest rol es podia anomenar "Administrador del sistema" o "Administrador" Linux-plataformes".
- Gestor de llançaments/Enginyer de construcció.
Matriu de rols i tasques RACI
Finalment, passem a comparar les posicions i tasques comentades anteriorment per donar una idea general de com hauria de ser l'estructura d'una organització que implementa DevOps a la plataforma OpenShift. Inicialment, els rols següents poden ser ocupats per diferents branques de l'estructura organitzativa antiga i tradicional. Però amb el temps, es produeix la consolidació i es creen nous equips al voltant d'aplicacions que assumeixen la majoria o fins i tot totes les tasques que s'enumeren a continuació.
tasques
Funcions
Enginyer d'operacions d'aplicacions / Enginyer de fiabilitat del lloc
Desenvolupador d'aplicacions / Desenvolupador de programari / Enginyer de programari
Administrador de clúster/plataforma d'aplicacions
Gestor de llançaments de programari/Enginyer de muntatge
Automatització i subministrament d'infraestructures informàtiques
I
I
R / A
C
Instal·lació i gestió de la plataforma OpenShift
C
I
R / A
C
Dissenyar i gestionar canalitzacions de desplegament
C
C
I
R / A
Gestioneu l'aprovisionament, l'aïllament i la capacitat informàtica dels inquilins
C
I
R / A
I
Construcció i gestió d'imatges base
R
C
R / A
C
Desenvolupament d'aplicacions i proves
C
R / A
I
I
Supervisió operativa i gestió d'aplicacions
R / A
C
C
I
Prova d'acceptació d'usuaris
C
R
I
I
Convencions a la matriu RACI
Font:
- Responsable – L'intèrpret és qui fa el necessari per completar la tasca.
- Responsable - Responsable: un empleat que és l'últim responsable de l'execució correcta i completa d'una tasca o l'assoliment d'un resultat; i també l'únic que pot delegar la feina als intèrprets.
- Consultat – Consultors: normalment es tracta d'experts en la matèria l'assessorament dels quals es demana; Es manté una comunicació bidireccional amb ells.
- Informat – Informat: persones que es mantenen informades dels esdeveniments (i de vegades només després de completar una tasca o aconseguir un resultat); reben informació unilateralment.
Com treballen els equips en una organització DevOps
L'adquisició de recursos tradicional és normalment un cicle de sol·licituds de recursos que després són executades per diversos equips. Finalment, tots els recursos necessaris són assignats i confirmats per la part sol·licitant. Sovint, aquests processos són parcialment o totalment manuals i requereixen interaccions freqüents i múltiples entre equips per processar amb èxit cada sol·licitud.
Figura 1. Organització informàtica tradicional
El diagrama anterior il·lustra les relacions típiques entre els equips d'una organització de TI tradicional. En aquest esquema, alguns equips es posen en contacte amb altres equips amb la sol·licitud de realitzar la feina necessària, utilitzant mitjans de comunicació més o menys formals, com un sistema de tickets o un correu electrònic. Aquestes peticions passen a la cua i esperen de banda, amb llargues esperes que sovint porten a l'empitjorament, o fins i tot a l'exacerbació, de les relacions entre els equips. A la tensió s'afegeix el fet que els membres dels diferents equips poques vegades es troben en persona i tendeixen a compartir només la informació mínima necessària.
Figura 2: organització de TI de DevOps
Aquest diagrama mostra com funciona la col·laboració en una organització DevOps. Aquí, els mateixos equips del diagrama anterior van abandonar les comunicacions ineficaces que reforçaven les sitges i les substituïen per contactes personals, creant així canals constants d'interacció entre equips. Aquests canals fomenten un conjunt d'habilitats híbrids que ajuda els empleats a comprendre i visualitzar millor les necessitats, els reptes i les oportunitats dels equips que representen. Els equips s'autoritzen mútuament per completar el treball mitjançant portals d'autoservei automatitzats, en lloc de gestionar manualment les sol·licituds de canvi d'altres persones, com era el cas en el passat. I gràcies a la presència de canals d'interacció, aquests sistemes d'autoservei poden adaptar-se ràpidament a les necessitats dels equips per als quals estan dissenyats. Per aconseguir una millor comprensió i intercanvi de coneixements dins de l'organització, els membres de l'equip van rotant periòdicament els rols per obtenir experiència interactuant amb diferents equips i comprendre millor la imatge general dels sistemes informàtics als quals admeten, augmentant així el seu nivell de funcionalitat i utilitat transversal.
En resum
En aquesta publicació, vam parlar de com l'adopció de solucions PaaS pot moure una organització cap a DevOps, canviant els rols i les tasques tradicionals com a part del procés. És per això que hem enumerat els principals reptes informàtics als quals s'enfronta una organització quan migra a OpenShift, així com les habilitats necessàries per completar-los. També vam proporcionar un conjunt bàsic de rols organitzatius que sorgeixen en crear equips de DevOps multifuncionals i una matriu RACI que vincula els nous rols amb les noves tasques. Finalment, vam parlar de com la plataforma OpenShift i la seva metodologia DevOps associada poden canviar l'estructura organitzativa de les organitzacions a mesura que passen de les jerarquies i sistemes de tickets tradicionals a equips multifuncionals amb un nivell més alt de comunicació personal.
Font: www.habr.com
