Tips para un inminente primer paso a producción

entretenida charla/tutorial!

Pa la próxima podrían hablar también de las distintas estrategias para pasos a producción.

Pasar PRD y pedir vacaciones....,

cuando me toca el ethical hacking y el pmo /jp me solicitan carta de riesgo... hahaha no pasaran!

frosstatx dijo:

Pasar PRD y pedir vacaciones....,

Haz clic para expandir...

Veo que eres un hombre de cultura

Yo hacia lo mismo, aunque no era forzado... Se retrasaba la salida a Prod hasta el momento que coincidía con las vacaciones. Me inventaba que ya tenía comprado los pasajes y el hotel (algunas veces sí fue así) para no tener que postergarlas

A propósito de pasos a Prod... Entendería que con CI/CD no debería ser tan pesado el tema. Seguro siguen habiendo cambios con el suficiente nivel de impacto para usar las cartas de riesgo. Pero mucho cambio chico e incremental se deploya todos los días. No sé qué opinan los que utilizan DevOps en sus empresas.

Enviado desde mi SM-S901E mediante Tapatalk

frosstatx dijo:

Pasar PRD y pedir vacaciones....,

Haz clic para expandir...

Gracias por su feedback, y sobre todo por la idea de pedir vacaciones antes de un paso a producción!! xD

En el canal hay más tips, como por ejemplo como crear una reunión en teams donde no asista nadie.

Bueno eso, saludos cordiales

schyzo dijo:

Veo que eres un hombre de cultura

Yo hacia lo mismo, aunque no era forzado... Se retrasaba la salida a Prod hasta el momento que coincidía con las vacaciones. Me inventaba que ya tenía comprado los pasajes y el hotel (algunas veces sí fue así) para no tener que postergarlas

A propósito de pasos a Prod... Entendería que con CI/CD no debería ser tan pesado el tema. Seguro siguen habiendo cambios con el suficiente nivel de impacto para usar las cartas de riesgo. Pero mucho cambio chico e incremental se deploya todos los días. No sé qué opinan los que utilizan DevOps en sus empresas.

Enviado desde mi SM-S901E mediante Tapatalk

Haz clic para expandir...

por cierto, pero también mencionamos que pasa cuando falla esa herramienta, si falla el bamboo en pleno paso a producción, y nos ha pasado y es terrible, o que se caiga el bitbucket y no pueda descargar el branch para subir.. un desastre a las 1:00 AM..

Paso a producción los fines de semana. Por lo general no se hacen porque involucra un movimiento de personas mas complejo que si fuera en un día normal. Mas cuando son fuera de horario laboral. Pero en algunos casos cuando hay usuarios que usan la plataforma en días de semana se opta por esa opción porque te da un par de días de holgura para corrección de errores antes de que los usuarios "vuelvan".

Y ya metido hasta las masas en un paso a producción fallido muchos se dan cuenta de la importancia de la homologación de los ambientes de trabajo (QA-PRD por ej) y el QA antes y después del paso. Es impresionante la cantidad de empresas que tienen la zoo entre ambientes y que ni siquiera tienen considerado el QA dentro de sus procesos.

Sobre el RFC: Estuve en un cliente donde a partir de un "RFC" (así le decían ellos) armaban TODO un proyecto. Cuando preguntaba la documentación, decían "ahí esta, en el RFC", abro archivo, una plana. Sin definiciones de nada, sin criterios de aceptación, etc.

Par de tips tener la disponibilidad de los responsables de distintos temas relacionados con el paso a producción, por ej DB, redes, etc. Son como el en caso de emergencia rompa el vidrio. Y que todo quede respaldado con mails, lo que se hizo, lo que se detecto, si algo no se hizo la razón.

donde chucha trabajan wn?

Sago7 dijo:

Sobre el RFC: Estuve en un cliente donde a partir de un "RFC" (así le decían ellos) armaban TODO un proyecto. Cuando preguntaba la documentación, decían "ahí esta, en el RFC", abro archivo, una plana. Sin definiciones de nada, sin criterios de aceptación, etc.

Haz clic para expandir...

Lo peor de la situación que describes es que la rueda ya está inventada para esos casos, por ejemplo implantar la práctica de habilitación de cambios (ex Gestión de Cambios) a partir de lo que recomienda ITIL, COBIT o ISO 20000. Y eso que ni siquiera hablo de implementar un software para la documentación y gestión de los RFC, hablo de tener la práctica definida, en marcha y socializada con todos los participantes.


Enviado desde mi SM-S901E mediante Tapatalk

schyzo dijo:

Lo peor de la situación que describes es que la rueda ya está inventada para esos casos, por ejemplo implantar la práctica de habilitación de cambios (ex Gestión de Cambios) a partir de lo que recomienda ITIL, COBIT o ISO 20000. Y eso que ni siquiera hablo de implementar un software para la documentación y gestión de los RFC, hablo de tener la práctica definida, en marcha y socializada con todos los participantes.


Enviado desde mi SM-S901E mediante Tapatalk

Haz clic para expandir...

Ese cliente tiene una mentalidad de hacer todo a medias y si funciona siguen con eso. Cuando llegue, se supone que podía ofrecer un montón de soluciones. Hice harto trabajo con unas plataformas para seguimiento de defectos, carga de evidencias, etc. Todo para que al final siguieran con una planilla de excel. Porque si proponias algo, los que andan a la vuelta de la rueda se quejaban y ponían peros.

Buen video.

En mi caso trabajo con algoritmos y uno de los pasos mas importantes son los "Accuracy and Scalability" tests.

No voy a citar entidades por que es info altamente confidencial.

Por lo general, gerencia autorizaba horas extras y 3 pisos se quedaban trabajando el tiempo que hiciera falta por turnos continuados de +12 horas. El área comercial instruía al personal de atención a clientes para que pudieran esperar una cantidad grandota de reclamos, y se informaba al área de control de medios para que no saliera en la radio, en la tv o el tema escalara mucho en redes sociales.

Típicamente uno no se podía excusar, nadie tomaba vacaciones, se suspendían pruebas, exámenes, clases, y la empresa corría con los gastos necesarios. Para cuando la súper intendencia se enteraba de las cagadas, habían pasado semanas o meses, y se tenían los gastos de las multas respectivas ya conversados con las autoridades.

Hubieron ocaciones especiales en donde se autorizaron horas extras a 3 pisos para los casi 200 analistas comerciales tambien, y se les asignó una porción de datos a cada uno para realizar pega manual. (así de cagados estabamos).

La empresa salío a producción con un histórico de 1 año por cada cliente, y se instruyó al personal de atención al cliente para que cada caso que lo requiriera fuera tratado por el área comercial, y se contubiera al cliente el mayor tiempo posible, mientras reportería (TI) extraía la info y la cargaba en la versión nueva del sistema comercial.

Hasta se capacitó a los analistas comerciales para que aprendieran SQL y así depender menos de los TI.

Dicha empresa era y es un parto para todo.
Fué mi primer paso a producción cototo.

Pal resto solo hago respaldos, y trabajamos en la noche. Lo otro que he hecho es una recolección de datos en algunas partes críticas para ir probando cierta versión en tiempo real e ir sacándole parches antes de pasar a marcha blanca.