¿Deben los programadores tener acceso a producción?
Hoy quiero reflexionar, y me gustaría conocer vuestras opiniones al respecto, sobre si los equipos de desarrollo deben tener o no acceso al entorno productivo de un sistema informático. Como soy muy puntilloso en lo que a terminología se refiere (y los que me conocen lo saben muy bién), empezaré con un poco de introducción para fijar conceptos.
Entendemos por entorno como el conjunto de servidores necesarios para que nuestras aplicaciones funcionen. Es decir, en una aplicación web de tres capas, cada entorno lo formarían el servidor de base de datos, el servidor de aplicaciones y el servidor web.
Los sistemas medianamente complejos suelen disponer de vários. Típicamente, tres:
- Desarrollo: sobre el que los programadores realizan los cambios.
- Preproducción: que suele usarse para la integración de los cambios de los diferentes equipos, pero puede usarse también para pruebas de despliegue (deployment) y para pruebas de QA.
- Producción: al que los usuarios se conectan para usar las aplicaciones. Este es el entorno en el que se produce el negocio y por tanto el más crítico.
Al disponer de estos entornos, cualquier cambio suele pasar por los tres: se programa en desarrollo, se comprueba en preproducción y finalmente se despliega en el productivo para ponerlo a disposición de los usuarios.
Una vez introducidos los conceptos, mi opinión es que si los desarrolladores tienen acceso al entorno productivo, es posible que puedan sentirse tentados a realizar cambios directamente en él, saltándose el ciclo normal del cambio, debido a la presión de los usuarios y es posible que pueda provocar problemas en un entorno que debería ser, por encima de ninguna otra cosa, estable. Estoy seguro que si un cambio provocara un problema, sería de forma involuntaria, pero errar es humano.
Por otra parte, es cierto que el proceso de resolución de incidencias puede complicarse ya que el desarrollador no puede monitorizar el sistema mientras reproduce la incidencia. Pero creo que los entornos de preproducción, correctamente mantenidos, se podrían usar para esto. Además, soy de la opinión de que los ficheros de log, correctamente usados, pueden ser de gran ayuda para la resolución de incidencias. Lo complicado está en determinar qué es necesario registrar: si loggueamos de más, el seguimiento y estudio puede complicarse por la cantidad de “ruido” que hay; y si nos quedamos cortos no dispondremos de la información suficiente para diagnosticar el problema.
He aquí el dilema: por la estabilidad del entorno productivo es mejor que no tengan acceso, pero esto puede dificultar la resolución de incidencias. Personalmente opino que las ventajas de que no tengan acceso superan con creces los inconvenientes, pero soy consciente de que por mi trabajo como administrador de sistemas puedo tener una visión sesgada del problema. 
Y vosotros, ¿que opináis? ¿Deben o no tener los equipos de desarrollo acceso a producción?
No, A mi parecer el equipo de desarrollo NUNCA debería tener acceso a producción. Precisamente es el problema típico de una mara organización de proyectos.
Si un desarrollador tiene la posibilidad de tocar en el servidor de producción, la tentación de “probar” o incluso la buena intención de querer solverntar rápido un problema, puede causar GRAVES pérdidas de funcionalidad, tiempo y efectividad de la empresa.
Más todavía si hablamos de proyectos grandes, donde la comunicación entre distintos equipos de desarrollo es, digamos que escasa, y si a unos les da por arreglar una cosa, al día siguiente machacan los cambios otros con su versión congelada y ya volvemos a empezar con los expedientes X de “esto yo lo arregle ayer y ahora vuelve a estar mal”.
Definitivamente, un control de versiones y entornos perfectamente separados de desarrollo, preproducción y producción son imprescindibles para tener un proyecto mediano/grande bien organizado y sin más incidencias que las generadas por el curso natural de su implementación.
Pero, también otra cosa interesante, ¿deben los BOFHs ser los responsables de las migraciones de un entorno a otro? ¿Hasta que punto un BOFH debe asegurarse de que una aplicación es lo suficientemente estable o limpia de errores como para pasar a producción?
Home, les coses no han de ser ni blanques ni negres.
Definitivament, un membre d’un equip no hauria de poder prendre la decissió d’atacar un sisema en producció.
Podria ser que un representant de l’equip fos l’únic que, sota la seva responsabilitat, tengués accés a aquest entorn.
Pel meu gust la solució ideal consisteix en:
- Un entorn de producció funcionalment idèntic al de producció.
- Accés completament denegat a l’equip de desenvolupament a l’entorn de pre-producció
- Un protocol ràpid i eficient per a fer una còpia idèntica de l’entorn de producció al de proves en calent. Probablement, autoritzat per un sol membre de cada equip de desenvolupament.
El problema de que un membre d’un equip de deenvolupament es vegi temptat a fer feina dirèctament sobre l’entorn de producció ve motivat per la impossibilitat que té en un moment donat de resoldre una incidència que només es pot reproduïr a l’entorn de producció.
Per aquest motiu és molt important que existeixin procediements formals i àgils que permetin que cada entorn s’usi pel que ha estat creat.
Meam, no sé què cony m’ha passat però el que volia dir era:
- Un entorn de pre-producció funcionalment idèntic al de producció.
- Accés completament denegat a l’equip de desenvolupament a l’entorn de producció
- Un protocol ràpid i eficient per a fer una còpia idèntica de l’entorn de producció al de pre-producció o a un tercer en calent. Probablement, autoritzat per un sol membre de cada equip de desenvolupament.
Idem de @Suki_
A pesar de que muchas veces querría “ese poder” para mis desarrollos, reconozco que eso nunca podría terminar bien.
Como bien dice Eduard, somos humanos, y estamos demasiado presionados por la resolución de errores… Por tanto, mejor tener varios entornos.
Ahora, eso sí, como también dice, es imprescindible que esos entornos se parezcan a producción, o al menos, en uno de ellos, se puedan hacer las pruebas pertinentes sin tener luego “sustos” en producción. Desgraciadamente, este punto suele darse a menudo, y nos encontramos con entornos con errores, o muy alejados del de producción, y claro, luego “pasa lo que pasa”… Jejeje
Bon post míster!
Jo estic en la línia de Paco de que les coses no són totalment blanques o negres. Es a dir, en condicions normals un desenvolupador no ha de tenir accés a producció per a instal·lar-hi coses però tot té excepcions i depèn fins i tot de la tecnologia que es faci servir, per exemple:
* Programari amb PL o equivalent. Normalment no està sota un control de versions estricte i es fa molt difícils saber que s’ha tocat i qui ho ha fet. Aquí l’accés ha d’estar molt restringit i l’accés a producció per a *depuració* hauria d’estar controlat, i mai deixant que una sola persona faci els canvis. El tema del pair programing per a evitar temptacions.
* Programari Java, python, php, etc. amb control de versions. En aquest cas basta normalment tenir accés als logs. Quan l’error afecta a les dades pot ser factible apuntar les aplicacions a les bases de dades de producció, està clar que hi ha un cert risc que el programador la cagui i faci un borrat massiu o coses semblants, però és el mateix risc que si hi deixa el codi i aquest es passa a producció. Es necessita control i assegurar-se que tothom que té les claus de producció en coneix les implicacions, però el risc, encara que existent no és comparable al cas anterior.
El que s’ha de distingir es el concepte de desenvolupament del de depuració. En desenvolupament no és necessari accedir a producció si es tenen uns bons jocs de dades, això com diuen altres companys implica tenir còpies amb totes les restriccions que vulguis de l’entorn de producció. Quan s’està corregint un error que sols es dóna a producció per les raons que siguin (diferent volum de dades, d’índexos a les bases de dades, configuració de maquinari, ètc. s’hi ha de poder accedir de manera controlada, vetar-ne totalment l’accés fa que un error pugui torbar moltíssim més en ser resolt i els errors que sols afecten a producció solen implicar pèrdues de diners, amb la qual cosa tardar més implica també perdre més.
Nosaltres, que tenim denegat l’acces a producció a tothom excepte als administradors, tenim es un entorn adicional que es una copia del productiu però del día anterior. No crec que aquest “delay” tengui gran impacte perque entre que l’usuari detecta la incidencia, la obri i el desenvolupador l’agafa per començar a fer feina, pasaran unes quantes hores i habitualment es pot esperar al dia següen. Els desenvolupadors tenen acces lliure a aquest entorn que està pensat justament per a la resolució d’incidencies. Pero el que pasa es que l’empren per altres coses, perdent-se la igualtat amb producció.
En situacions de incidencies greus que necesiten resolució inmediata, els equips de desenvolupament sempre compten amb l’ajuda dels administradors. Ambues parts haurien de fer feina plegats i jo a la meva gent la tenc molt concienciada al respecte. De la part de desenvolupament, hi ha equips que també ho tenen mol assumit pero n’hi ha que no. I son aquets darrers els que es queixen ja que els hi agradaría tenir el control total.
Eduard, jo el que veig és que:
- Hi ha un problema amb l’ús incorrecte de l’entorn de pre-producció. Potser necessitau un entorn explícitament creat per a la ressolució d’incidències. És un problema de l’equip de desenvolupament que ha de fer-ne bon ús. Potser cal revisar com s’alimenta l’entorn de desenvolupament.
- 24h per a la ressolució d’una incidència em pareix un temps absurdament llarg. Potser simplement calia tocar una coma.
- Teniu un problema de protocol per incidències urgents: “Els adminsitradors estan davora els desenvolupadors” no és formal.
Jo crearia un quart entorn per a la ressolució d’incidències i un mini-protocol segons el qual davant una petició d’un cap de projecte o similar els adminsitradors crein una còpia idèntica de l’entorn de producció al de ressolució d’incidències en temps “real” o en pocs minuts.
Addicionalment, per a les BDs, pots fer una còpia en calent fent servir els redo logs a una 2ª BD i així els developers sempre tenen accés a una còpia idèntica de les dades de producció.
El fet de que hi hagi una falta de formalitat i que existeixi l’excepció acaba duguent a discusions innecessàries en moments de tensió. Si tothom té clar quin és el procediment i és un procediment *útil i eficaç* (si no ho és, el resultat és el contrari del que es pretén) no hi ha problemes mentre totes les parts compleixin amb el que els toca.
NOTA Addicional: l’ús de màquines virtuals lliures i gratuites com ara VirtualBox és excel·lent per a la replicació instantània d’entorns de proves i pre-producció. Un adminsitrador pot crear n instàncies com a xurros en el que tarda el disc en fer una còpia.
Paco, pot ser no m’hagi explicat be:
- L’entorn al que he fet referencia al comentari es independent del de pre-producció i només es per a incidencies, pero la gent l’utilitza per altres coses. De fet, a la casa tenim set (set, sí, 7) entorns permanents.
- Lo de les 24 hores es la diferencia en temps que hi ha entre les dades de l’entorn productiu i el de “resolució d’incidencies”. El temps que tardi el desenvolupador en solucionar la incidencia, no hi te res a veure. Llavors, a no ser que la incidencia tengui que veure amb dades introduïdes per usuaris, el delay no te cap impacte. I si hi te que veure, es pot reproduir insertant les dades a mà.
En quan a lo de actualitzar davant una petició d’un cap de projecte: nosaltres mantenim l’entorn d’incidencies actualitzat aplicant archive logs i en un sistema amb un carrega transaccional tan alta com el nostre no es una cosa que es fagi en qüestió de minuts. Cada vespre es necesiten varies hores en aplicar els archive logs del día anterior.
Por ser el protocol no sigui gaire formal, pero es”útil i eficaç” per gaire bé tot el departament. Només hi ha un conjunt de persones descontentes, les que estaven acostumbrades a fer i desfer a producció i no s’han sabut adaptar a la nova situació.
Com que no m’agrada parlar de la feina pel blog (es el meu blog personal, no profesional, i el post era una pregunta genèrica), si vols, en podem acabar de parlar un dia d’aquests fent una cervesa. Amb aixó no vull dir que no vagi a contestar més comentaris, de fet esper que n’hi hagi més
, però en cap cas faré més referencies a la meva feina.
A part, Paco, se te vou un poc el “plumero” de desenvolupador
Amb tot això que planteges i tal com està muntat, potser la pregunta adequada no hauria de ser si els programadors han de tenir accés a les BD de producció, sinó si la gent que fa mal ús dels entorns de preproducció hauria de ser a l’empresa.
Amb tot el que comptes ja no es tracta de que es tengui accés per depurar, sinó del mal us que se’n fa de les eines que hi ha a disposició del desenvolupament (el perquè s’hauria d’estudiar). Que es pugui accedir a producció de manera controlada no és el mateix que poder fer i desfer a l’entorn de producció com a un li vengui en gana. Els entorns PL en són molt sensibles a això, un dia les coses deixen de funciona i ningú ha tocat res. És una de les coses que fan que cada cop estigui més en contra de posar lògica de negoci a la BD. La pau d’esperit que dóna un sistema de control de versions no té preu.
Cita: “potser la pregunta adequada no hauria de ser si els programadors han de tenir accés a les BD de producció, sinó si la gent que fa mal ús dels entorns de preproducció hauria de ser a l’empresa”. Antoni Aloy.
Estoy por enmarcar esa frase y ponerla en el tablón de anuncios de nuestro departamento.
Sigo pensando que la suma de un buen control de versiones más una buena estructura de producción, pre-producción y desarrollo es ideal para trabajar en medianos y grandes proyectos.
Si alguien considera que “necesita” acceso a producción por algo, quizá le falte algo de formación, para que entienda el sistema montado y sepa sacarle partido (sobre todo si tenéis 7 “SIETE” entornos montados.
)
[...] « ¿Deben los programadores tener acceso a producción? Protegiendo el correo con Fail2Ban [...]
X’-DDD Se me veu el plumero? De veres?
Jo crec que no
però, bé, està clar que no ho havia entès bé. Així com ho expliques pareix clar que el temps és més que acceptable i només excepcionalment caldria fer una còpia en calent de les dades actuals per a poder solucionar un problema urgent immediatament.
Jo estic bastant acostumat a que els protocols de pas a producció i a pre-producció siguin els que són i només de tan en tant et trobes amb un bofh (per cert, ara tenc un bulmero que es porta d’allò més bé sempre) que et fa la vida més fàcil.
En el meu cas els protocols són molt rígids i estrictes i al final qui paga les conseqüències d’una sovint innecessària burocratització és el client final.
A més, fixa’t que en cap moment he considerat necessari que un programador/desenvolupador/picador/master of the known tengui accés DIRECTE a les dades de producció només he dit que l’hauria de poder tenir immediat d’alguna manera. Però pareix que es tractava d’un malentès i que això ja és possible així com ho tens montat.
Lo de la cervessa en voler
Sempre és un plaer i ja fa molt de temps que no passa No ho trobes? 
Com aniria a principis de Desembre?
Estic encantat de que ultimament li hagis donat una mica de vidilla a aquest blog
No, no se te veu. Era per a ficar-me un poc amb tu
Donç a principis de decembre t’enviare un mail i quedam.