Instructivo - Tickets de Cambio - V1.0

h

2013

Grupo Santander Jamilis, Eduardo

Enero

Gestión de Cambios Ingreso de solicitudes de cambio

Pág. 1

Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban

Gestión de Cambios – Ingreso de solicitudes de Cambio

Índice

Índice ............................................................................................................................................................. 1

Introducción .................................................................................................................................................. 2

Ambientes ..................................................................................................................................................... 6

Producción ................................................................................................................................................ 6

Ambientes previos .................................................................................................................................... 6

Selección del circuito en Producción ............................................................................................................ 6

Planilla de circuitos ................................................................................................................................... 6

Ejemplo de Creación de un Cambio .......................................................................................................... 7

Datos básicos y asignación de nivel de riesgo ...................................................................................... 8

Clasificación y Clase de Cambio .......................................................................................................... 10

Información de Trabajo ....................................................................................................................... 11

Tareas .................................................................................................................................................. 11

Asignación ........................................................................................................................................... 13

Relación con otros tickets ................................................................................................................... 13

Fechas ................................................................................................................................................. 15

Datos Requeridos ................................................................................................................................ 15

Selección del circuito en Ambientes previos .............................................................................................. 18

Aviso Importante – Impacto en Producción ........................................................................................... 18

Criterio .................................................................................................................................................... 18

Solicitudes al área Administración de Ambientes .................................................................................. 21

PIR (Post Implementation Review) ............................................................................................................. 22

Preguntas Frecuentes ................................................................................................................................. 25

Pág. 2


Introducción

El proceso de Gestión de Cambios tiene tiene como principal objetivo la evaluación y

planificación del proceso de cambio para asegurar que, si éste se lleva a cabo, se haga de la

forma más eficiente, siguiendo los procedimientos formales establecidos y asegurando en todo

momento la calidad y continuidad del servicio TI.

Esto implica que deben cumplirse los estándares, procesos y procedimientos de

implementación establecidos. Y es área de Gestión de Cambios de Produban la encargada de

verificar su cumplimiento, en tiempo y forma.

Es por esto que no puede impactarse en Producción NINGÚN cambio sin un pedido de cambio

asociado. No es válido hacer los cambios pedidos informalmente, y LUEGO ingresar un pedido

para regularizarlo.

Todos los cambios deben ser ingresados al sistema de Gestión (en Remedy) con la anticipación

mínima requerida, según el caso. A estos cambios los clasificamos como normales y son

analizados en primera instancia por los especialistas, verificando la factibilidad de su ejecución

y luego por un CAB (Change Advisory Board o Comité de Cambios) con participación de todos

los involucrados, Isban, Produban y Banco Santander Río, que evalúan el riesgo y acuerdan la

realización del mismo, o lo rechazan fundadamente, ya sea por la naturaleza del cambio o por

la ventana escogida para su realización.

No es admisible el ingreso de un ticket solicitando la implementación de un componente, si el

mismo no está terminado y en condiciones de funcionamiento, a la fecha de ingreso del ticket.

El plazo de 10 días de anticipación en el pedido de un cambio normal es necesario para realizar

un adecuado análisis de impacto y poder garantizar la integridad del proceso, pero NO DEBE NI

PUEDE usarse para “ganar tiempo” pidiendo implementaciones antes de contar con el

componente. Eso de algún modo implicaría para el CAB aprobar un “cheque en blanco” sin

saber qué es exactamente lo que ese componente hará en su forma final.

Cuando por alguna razón un cambio NO PUEDE o NO DEBE esperar el plazo establecido para un

cambio normal, puede pedirse un cambio como emergencia. En este caso, ese cambio que debe

ser adecuadamente fundamentado (no sólo es su necesidad, sino también respecto a su

urgencia) debe ser analizado por el ECAB (Emergency CAB o Comité para Cambios de

Emergencia) que es el órgano designado para autorizar la aplicación de estos cambios.

En estos casos, se debe enviar oportunamente la siguiente información con el detalle de los

cambios a tratar en el comité ECAB como se describe a continuación:

Pág. 3


1. Enviar antes de la hora del comité 11hs, de lunes a viernes 2. mail: [email protected] (CASILLA GESTION DE CAMBIOS) 3. Utilizar la siguiente planilla

PLANILLA MODELO

----------------------------------------------------------------------------------------------------------

Nro de CRQ:

Solicitante:

Participantes del ECAB:

------------------------------------------------------------------------------------------- ---------------

Motivo de la Emergencia:

Genera corte de Servicio: Cuanto dura el corte de servicio:

Aplicativos y/o recursos afectados:

---------------------------

---------------------------

Detalle:

Plan de Implementación:

Plan de Pruebas:

Plan de Vuelta atrás:

Fecha Inicio:

Fecha Fin:

EJEMPLO PLANILLA CON DATOS

----------------------------------------------------------------------------------------------------------

Nro de CRQ : CRQ000000059576

Solicitante: Miguel Duffy

Participantes del ECAB: Miguel Duffy

mailto:[email protected]

Pág. 4


Motivo de la Emergencia: Se realizó una revisión proactiva del servicio de PPRC donde

se detectaron errores en 3 LUNs.

Para mitigar este problema se deben migrar los datos a nuevas LUNs en modo PPRC para

estar preparados ante un DRP producto de Falla en producción.

Genera corte de Servicio: NO Cuanto dura el corte de servicio: N/A

Aplicativos y/o recursos afectados:

---------------------------

CRQ000000054612 - Reasignacion de LUN para PPRC

---------------------------

Detalle: Por problemas en el PPRC se procederá a migrar los datos de las LUN existentes

a una nueva LUN en modo PPRC. Las bases que están afectadas son

RIO57 >El FS comprometido es /RIO57/data14 -->

RIO2 >FS comprometidos > /RIO2/data07 y /RIO2/index04 --> 3hs

Plan de Implementación: Se migrara los datos de las LUN actuales a una nueva, en

modo PPRC. Esto no requiere corte de servicio.

Plan de Pruebas: verificar la asignación de LUN, y consultar con storage que estén en

modo PPRC, antes de comenzar la tarea.

Plan de Vuelta atrás: Ante cualquier problema no mover los datos a las nuevas LUN y

frenar el cambio.

Fecha Inicio: 2012-09-21 19:00:00

Fecha Fin: 2012-09-22 10:00:00

Una vez impactados los cambios (implementaciones, configuraciones, instalaciones, etc.) el

solicitante o alguien de su grupo debe evaluar dicho cambio. Esa es la finalidad del PIR (Post

Implementation Review o Revisión post Implementación). Esa evaluación es fundamental para

evaluar la calidad de los cambios que se aplican y proceder al mejoramiento de la calidad en

caso que se detecten deficiencias en el proceso.

Pág. 5


Es importante que quienes lean este instructivo hayan leído antes el documento:

Código: ARG-SPA-INT-003-MYO

Título: Instructivo Gestión de Cambios Isban

Objetivo: Describir en forma detallada las actividades del proceso a realizar por Isban para solicitar una implementación o cambios en la infraestructura del ambiente productivo gestionado por Produban según su proceso de Gestión de Cambios corporativo de Produban.

Vigencia inicial: 28 / 09 / 2012

Última revisión: 28 / 11 / 2012

Vigencia hasta: 28 / 11 / 2014

Dirigir Consultas a mail: [email protected]

Es importante tener claros los conceptos expuestos en dicho documento, distribuido por

Arquitectura y Metodología de Isban a todo el personal de Isban Argentina, y que aplica sólo a

los pedidos para el ambiente de Producción.

Es necesario también que tengan conocimiento de lo establecido en la guía del usuario de

cambios http://remedyweb.ar.bsch:9080/arsys/shared/Manuales/7.pdf.

Dependiendo del ambiente del que se trate, los pedidos a la fecha se ingresan por sistemas

diferentes, tal como veremos a continuación.

http://remedyweb.ar.bsch:9080/arsys/shared/Manuales/7.pdf

Pág. 6


Ambientes

Producción

Los pedidos de cambio para ambientes productivos se ingresan forma de tickets en Remedy.

Ambientes previos

Los pedidos de cambio para ambientes previos (Desarrollo, Test, Homologación, Pre-

Producción) se ingresan en el sistema de Requerimientos Internos (RI).

Selección del circuito en Producción

Planilla de circuitos

Dentro de la documentación provista hay una planilla, en

http://remedyweb.ar.bsch:9080/arsys/shared/Manuales/2.xls, en la que se muestran los

circuitos posibles. Verificar en 2.xls que NO HAYAN flitros que nos impidan ver el circuito que

necesitamos.

Esta planilla debe abrirse desde la web ante cada nuevo uso, dado que la misma puede sufrir

modificaciones en cualquier momento.

Cuando el solicitante ingresa un ticket, usualmente conoce exactamente cuál es el grupo

resolutor para ese tipo de pedido. En caso de desconocer el grupo implantador y si el mismo

corresponde a IBM, deberá hacer la consulta previamente con la gente de IBM SRIO Cambios

([email protected]), quienes informarán cuáles son los grupos involucrados (uno o más).

En consecuencia, lo que debe hacerse es filtrar la planilla por grupo resolutor, y luego elegir el

circuito más adecuado para el tipo de pedido que estamos haciendo. Ej: si vamos a solicitar la

implementación de un nuevo job en Control-M DS en servidor Unix, NO PODEMOS cargarlo

como corrida de job en control-M , más allá de que eventualmente el grupo resolutor sea el

mismo.

Concretamente la líneas aludidas serían:

http://remedyweb.ar.bsch:9080/arsys/shared/Manuales/2.xls


Pág. 7


Es importante que cada cambio sea tipificado y clasificado adecuadamente ya que de esto

depende que cumpla con el ciclo completo de aprobaciones y sea asignado de manera correcta.

Una vez seleccionado el circuito apropiado, se ingresa a la herramienta Remedy siguiendo las

instrucciones de la guía http://remedyweb.ar.bsch:9080/arsys/shared/Manuales/7.pdf del

usuario de cambios y se carga el ticket correspondiente.

Ejemplo de Creación de un Cambio

Vemos a continuación un ejemplo referido a una solicitud de Catalogación de un nuevo Job en

Control-M DS (distribuido) a correr en el servidor Unix SRVxxxx (primer ejemplo mostrado

arriba).

http://remedyweb.ar.bsch:9080/arsys/shared/Manuales/7.pdf

Pág. 8


Para realizar la carga de una solicitud de cambio debe primeramente hacerse clic en la opción “Crear” desde la consola de gestión de cambios, ver ilustración siguiente:

o

Datos básicos y asignación de nivel de riesgo

Luego de hacer clic en la opción “Crear”‖ tal como se muestra en la ilustración anterior, el sistema abrirá una nueva ventana que contiene los datos a cargar en una solicitud de cambio tal como muestra a continuación:

Pág. 9


Tal como puede verse en la ilustración, se puede visualizar en la parte superior a la barra que

indica el estado en el flujo del proceso (ver recuadro rojo), y algo más abajo (ver recuadro

verde) puede identificarse a la lista de datos denominados ”Datos Básicos”‖ que deben

completarse. Los que tienen asteriscos son obligatorios. Aquí es donde se asigna el nivel de

Riesgo (N1, N2, N3), el impacto, la prioridad y la urgencia.

Cambios N3 requieren menos días para su ejecución (72 hs. entre la fecha de petición de

autorización y la fecha programada de Inicio en lugar de 240 hs. como lo requiere un ticket N2-

Normal) porque se sabe que son de riesgo acotado y no requieren análisis de impacto. Eso NO

IMPLICA que puedan ejecutarse en menos de 72 horas. Si se requiere que sean ejecutados

antes de las 72 horas, deben ser ingresados como N2 de emergencia y ser tratados en el

respectivo comité diario (ECAB) de las 11 horas del día siguiente, previo envío de la planilla con

la información adecuada.

Las solapas disponibles cambian según la fase del ciclo de vida que se esté transitando.

Algunas solapas (por ejemplo “Aprobadores”) no estarán disponibles hasta que se avance a una

fase determinada.

Como vemos los datos del solicitante vienen precargados. En el campo Empresa, para

empleados de Isban, debe decir ISBAN ARG. Si no es así, por favor informar a Administración

ITSM ([email protected]) para corregir los datos del usuario.

ARG


Pág. 10


Clasificación y Clase de Cambio

Luego se ingresan los datos de Clasificación (que determinan en qué bandeja caerán para ser

programados y ejecutados), así como también la Clase (Normal o Emergencia) y el Motivo del

cambios (Evolutivo, Correctivo (debe estar relacionado con un ticket de Incidencia ingresado

previamente), Auditoría, Normativo (debe tener el identificación de la norma a la cual hace

referencia) o Ejecutivo (debe que estar acompañado con un mail con las aprobaciones de los

Directores Generales de Isban y Produban y la del CIO del Banco).

Como pueden ver, esta información de categorización coincide EXACTAMENTE con la que

encontramos en la planilla publicada (columnas en azul), y que repetimos a continuación:

De este modo sabemos que el cambio está en el circuito correcto, y tendrá los controles,

aprobaciones y resolutores correctos para el tipo de tarea de que se trata.

Pág. 11


Información de Trabajo

En esta solapa se debe agregar toda información o comunicación relevante a la solicitud de cambio. Es posible indicar entre otras cosas información adicional relacionada a la implementación, comunicación con el solicitante, resultados de pruebas realizadas, información sobre los riesgos potenciales, datos necesarios para auditorías, etc.

Tareas

Si lo que se está pidiendo sólo requiere de una tarea, la solapa Tareas podría saltearse.

No obstante, se recomienda que siempre que se ingrese un pedido, se verifique la lista de

“Grupos de Tareas” predefinidos para ver si existe uno creado que sea apropiado para el tipo

de requerimiento que se va a hacer. Usándolos, nos aseguramos de que estén incluidas todas

Nota: no poner en ningún caso “llamar al solicitante”. Pueden consignarse

los datos del solicitante para que el implementador pueda contactarlo y

aclarar dudas sobre la tarea, pero las acciones específicas que se solicitan

deben estar completa y correctamente explícitas en el ticket.

Pág. 12


las tareas (una o más) necesarias para ese tipo de pedido, y de que el mismo no será rechazado

por no estar completo.

Entonces vamos a la solapa de tareas y hacemos esta verificación. Para ello seleccionamos

“Plantilla de Grupo de Tareas” en Tipo de petición (como se muestra en el gráfico de abajo),

presionamos “Relacionar” y se busca entre los grupos que se muestran en la ventana

emergente.

En este caso, se ve que la plantilla (como ejemplo) para “Creación de VIP de F5” tiene 3 tareas.

Si hubiera un grupo apropiado, lo seleccionamos de la lista y presionamos “Relacionar”.

Como no hay un grupo apropiado para la solicitud de “Correr un Query” como la que estamos

confeccionando, no necesitamos definir Tareas, y nos aseguramos de haber cargado TODO el

detalle de lo que se pide en la solapa “Información del Trabajo”, que vimos previamente.

Pág. 13


Asignación

Una vez completados los detalles del pedido (incluyendo las tareas si correspondiera) se pasa a

la solapa de Relaciones (para Cambios la solapa de Asignación se completa sola y no es

necesario revisarla).

Relación con otros tickets

Si es necesario relacionar este pedido con uno anterior, por ejemplo porque es un cambio

derivado de una incidencia reportada (y YA CARGADA en la Consola de Gestión de Incidencias)

o porque está vinculado a un cambio anterior mal ejecutado, en esta solapa se especifica con

qué otro ticket se relaciona.

Para ello:

Debe elegirse con qué tipo de ticket se va a relacionar, y al presionar “Buscar” se hace la

búsqueda y finalmente se establece la relación.

Pág. 14


En este ejemplo se especifica que el cambio que ingresamos corrige la incidencia especificada.

Luego se ingresa la fecha en la que pedimos el cambio o la tarea. Es importante recordar que

debe cumplir con los tiempos de anticipación establecidos, para permitir que las actividades

de verificación técnica, análisis de impacto, aprobación y planificación se ejecuten

normalmente. Para un cambio Normal (N2) se requieren 240 horas de anticipación (como en el

ejemplo de abajo) al inicio de la tarea, independientemente del tiempo que sea necesario para

ejecutar la misma. Para un cambio N3 se requieren 72 horas de anticipación.

Pág. 15


Fechas

Como en todas las demás solapas, sólo son obligatorios los campos marcados con (*).

Datos Requeridos

Finalmente se completa la solapa de Datos Requeridos. En esta solapa debe evitarse en lo

posible completar los distintos campos con “No Aplica” o “NA”. Debe brindarse toda la

información disponible para que el Remedy realmente sirva como una herramienta para hacer

el tracking de los cambios en Producción.

Sistemas Campo de selección, se debe seleccionar el aplicativo de

la lista provista por la herramienta. Dicha lista es la

resultante del vuelco de sistemas definidos en INVAP..

Número Proyecto GUIA Se debe indicar el código del ID de GUIA del Proyecto.

Este campo se deberá cargar siempre y cuando la

implementación esté relacionada con un proyecto.

ID Banco – Nombre de

Proyecto

Campo de selección por nombre de proyecto creado en

PPM

Banca de Negocio Completar con el negocio de banco asociado

Pág. 16


Pedido Menor Se debe indicar el código del RI del Pedido Menor. Este

campo se deberá cargar siempre y cuando la

implementación esté relacionada con un Pedido Menor.

# Expediente Changeman En el caso de una implementación Mainframe, y si

correspondiera, se deberá ingresar el aplicativo y nro. de

expediente Changeman que corresponda. Ej CTD3000015

Path Completo En caso de que ser una implementación Midrange y que

sea por contingencia (no se implementa por ClearQuest)

se debe informar la carpeta donde está el paquete a

implementar para que Implementaciones lo tome de allí

para realizar la tarea.

Versión En el caso que corresponda debe indicarse la versión del

aplicativo que se está implementando. En general aplica a

sistemas Midrange.

Canal Afectado Se debe detallar que canales pueden ser afectados por la

implementación. (Ej.: OBP, OBCM, etc)

Identificador Carpeta CQ/CI En caso de que ser una implementación Midrange y que

sea por el circuito normal (es decir utilizando ClearQuest),

se debe informar el ticket de ClearQuest que utilizará

Implementaciones para realizar la tarea. (Ej:.

BSCH0000004567). Este ticket de ClearQuest debe

contar con todas las aprobaciones previstas por el

proceso antes de ingresar el ticket en Remedy.

Es de suma importancia llenar adecuadamente los campos referidos a “Plan de

Implementación”, “Plan de Pruebas” y “Plan de Vuelta atrás”.

En “Plan de Implementación” es necesario especificar las Instrucciones de ejecución o realización

del cambio, pudiendo tratarse de tareas de configuración, análisis, verificación o comunicación (o sea,

los pasos a seguir para ejecutar la tarea).

En “Plan de Pruebas” hay que describir la forma en que el implementador puede confirmar que

su tarea fue realizada correctamente, sin tener que consultar al solicitante del cambio. Se trata

de tareas de control y revisión de resultados esperados del cambio. Se realizan luego del plan

de implementación y permiten determinar si el cambio cumplió sus objetivos (cambio exitoso)

o no (cambio fallido).

Pág. 17


En “Plan de Vuelta atrás” se describe qué hacer para volver a la situación original, previa al

cambio (obviamente cuando hubo cambios reales a la infraestructura: puede ponerse ”No

Aplica” en un caso como el del ejemplo en que se pide Información, y por lo tanto NO se han

llevado a cabo cambios de ninguna naturaleza).

Es buena práctica poner datos de contacto en los campos para que el implementador del

cambio pueda contactar en el mismo momento en que lo está ejecutando al solicitante, ante

alguna necesidad de aclaraciones.

Finalmente se presiona “Guardar” para que el sistema dé por ingresado el Borrador de Cambio

y verifique que se hayan ingresado todos los valores obligatorios, con valores que dan

integridad a la solicitud. Una vez hecho esto, se avanza el estado del ticket.

Nota: no poner en ningún caso “llamar al solicitante” en reemplazo de NINGUNO de los 3 planes

requeridos. Si consignan los datos del solicitante es para que el implementador pueda

contactarlo y aclarar dudas sobre la tarea, pero las acciones específicas que se solicitan deben

estar completa y correctamente explícitas en el ticket. Contar con estos datos es especialmente

útil para el implementador durante la ejecución del Plan de Pruebas o el de Vuelta Atrás.

Pág. 18


Selección del circuito en Ambientes previos

Aviso Importante – Impacto en Producción

Para ambientes previos la organización continuará utilizando la herramienta de Requerimientos

Internos hasta nuevo aviso.

Hay cambios que aunque sean para ambientes previos, IMPACTAN EN PRODUCCIÓN.

Por lo tanto habrá que gestionar los cambios relacionados con Storage, Balanceadores, Networking y Correo vía tickets de Remedy, siendo el objetivo no exponer la infraestructura productiva a riesgos innecesarios que puedan darse (debido a que hoy en día no se evaluando factibilidad técnica ni riesgos de los cambios que se gestionan a través de RI como se hace con los tickets en Remedy). Debemos tener en claro que más allá del uso que se le puede dar a estos componentes, los mismos son productivos y cualquier cambio sobre ellos implica un riesgo sobre los servicios del Banco.

Criterio

Los criterios de selección de Circuitos en Requerimientos Internos continúan siendo los que habitualmente usamos. Del menú de Producto:

Pág. 19


se selecciona la opción “Pedidos / Cambios”. En el de Sub-Producto lo más apropiado al tipo de cambio que se solicita:

Pág. 20


Por ejemplo: si estamos pidiendo una nueva instancia de servidor WebSphere: seleccionamos la opción “WEB” y eso nos lleva al combo de Concepto: Allí seleccionamos “Desarrollo” o “Test/Homo” según corresponda. Recordar que NO DEBE usase RI para pedidos de PRODUCCIÓN.

Y en Sub-Concepto seleccionamos “ABM de Instancia”.

Pág. 21


Solicitudes al área Administración de Ambientes

Si se requieren servicios del área Administración de Ambientes (siempre referidos a los ambientes de Homologación), NO ENVIAR dichos pedidos por mail, sino a través del siguiente circuito:

Estos pedidos de configuraciones, implementaciones, etcétera, serán atendidos por el grupo de Administración de Ambientes, o de considerarlo más apropiado, lo derivarán al grupo resolutor que corresponda.

Pág. 22


PIR (Post Implementation Review) El PIR o Revisión post Implementación es un paso fundamental en el circuito, y que apunta a mejorar la calidad de las implementaciones. Todos los tickets, una vez cumplidos, deben ser evaluados por el solicitante o un miembro de su grupo, especificando si el cambio ha sido implementado con Éxito, si tuvo fallas, si está mal implementado, o si sencillamente quedó sin implementar.

Los tickets que están esperando por una Revisión post Implementación están marcados con un “Si” en la columna PIR precedente. Eso las distingue de una “Autorización normal” previa a la ejecución de un cambio.

Nota: no seleccionar más de un ticket, ya que de este modo sólo se evalúa

el primero, y el resto quedan como implementados sin errores.

Pág. 23


Para cada uno de los tickets (que deben seleccionarse de a uno) debe hacerse la evaluación correspondiente. Si en el ejemplo anterior, queremos rechazar el cambio, lo seleccionamos (sólo al que estamos

evaluando), presionamos y cuando vemos el pop-up ponemos las razones:

Si lo vamos a Aprobar, porque entendemos que la tarea se hizo, presionamos y tenemos 2 opciones:

Con éxito: todo fue realizado como se pretendía y el resultado fue el esperado.

Éxito con problemas: sin bien los solicitado fue realizado, el resultado no es exactamente el esperado, quedaron parte de las tareas sin realizar o se cumplieron en forma incompleta.

Pág. 24


Si lo aceptamos como exitoso el trámite finaliza aquí. Si decimos que hubo problemas es necesario explicar las razones en el campo al efecto:

La correcta implementación de los cambios es crucial para lograr la mejor disponibilidad en Producción. Es por ello que la etapa de PIR es fundamental: es la única forma que tenemos de evaluar la calidad de las implementaciones, de encontrar errores en el proceso o actividades específicas y buscar las soluciones para mejorar la calidad general. De nada sirve reclamar por mail por implementaciones mal hechas, si en el PIR se evaluó el cambio como “exitoso”.

Pág. 25


Preguntas Frecuentes En paralelo con este manual, Produban está publicando en conjunto con IBM un nuevo documento de FAQ (Frequently Asked Questions) que será actualizado periódicamente. Sugerimos desde aquí echarle un vistazo periódicamente ya que las distintas consultas que vayamos recibiendo y entendamos que son de interés para un número grande de usuarios, serán incorporadas al mismo.

Instructivo - Tickets de Cambio - V1.0

Documents

Transcript of Instructivo - Tickets de Cambio - V1.0