admin

Desde que abrí mi cuenta de paypal hace casi 10 años, ya van unas cinco veces que me la limitan por razones varias. principalmente me pasó por comprar servicios de dominios a chinos e hindués (onlinenic / directi ), pero ahora me tocó una revisión random por haber hecho tres pagos desde el servidor en houston.

El caso es que ahora, a pesar de tener confirmads varias cuentas de banco, me pide confirmar una nueva tarjeta de débito, y estarésin usar esa cuenta por casi un mes.

Una de las cosas que muchas personas no entienden de resellerone y de srsplus, es justamente la maravilal de no recibir paypal; si bien tienes que habilitarlos con 100-1000 usd y la otra con 250 usd, pero tendré que usar esos métodos.

A esperar el estado de cuenta de la de débito que quiere paypal que confirme.

Estos son dos correos que mande el 1 de febrero, mas de seguimiento a los respaldos. Aviso que edito el nombre de las soluciones (A) y (B), y que el sistema de tickets es un software propietario, que no hice yo, y del que dije en junio del año pasado que consume muchísima memoria.

El usuario root2 no se llama así pero el problema es real.

Por mail masivos son notificaciones, cientos al día, a clientes de nuestro SAAS.

=========================================================
El respaldo de la base de datos, en condiciones óptimas, se tarda poco mas de 5 horas y media con una conexión amplia. Debemos pasar parte de su material a otra base de datos, otro dominio, y otro server porque el riesgo va creciendo, sumandolo al consumo de memoria reportado anteriormente.

Si de mi dependiera:
a ) manejaría un servidor extra para hacer las pruebas de respaldos en frio.
b ) Pasaria el sistema de tickets a otro dominio (¿ el mx?) en el servidor de la empresa C. Este server no puede manejar ftps mas ssh de root2 mas usuarios de ticktes mas mail masivos.
c ) Crecería el servidor actual. Estamos llamando al desastre.

Me parece prioritario el hacer un plan de continuidad de negocio o un simulacro. Se necesita mas material a nivel de socios, porque no podemos arreglar con curitas un problema que sigue creciendo de manera exponencial. Esto incluye los planes de respaldo que hice en el 2010, no solo de abuelo hijo nieto, sino de respaldos externos en las oficinas de
la empresa B o casa de uno de los socios, que evidentemente ya no caben en un usb, ni siquiera la base de datos compactada.
================================================

Aunque subimos de tamaño el servidor a un plan mayor, no fue la solución que sugerí que cuesta * USD mensuales.

Por el uso de tickets y las sesiones de ftp estamos manejando un load de 13, 16, 15, variable en diversos momentos del día. Tenemos los siguientes síntomas de problemas:

1 ) Nuestro tráfico de ftp son 300-3000 gb mensuales. Eso no creo que lo soporte el server pedido por fuera de XX mil al mes.
2 ) La memoria actual de giga y medio se está viendo saturada ya , principalmente por dos factores que comento mas adelante. Esto causa lentitud en la salida, que nos lleva a que fabiola o yo no podamos a veces abrir siquiera la base de datos en phpmyadmin, o ni siquiera entrar a cpanel.
3 ) Tenemos un mensaje por hora de uso excesivo de recursos por el usuario root2, que por lo que se es el que se conectan desde las maquinas virtuales. Pueden consultar los correos al respecto en la cuenta de correo del server +++++++++++++ en el servidor ************, la ultima vez que vi eran miles de mensajes.

Por la proyección de uso de memoria y el tamaño actual de nuestro server, , solamente podemos seguir con l esquema actual de memoria para subir un 15% de memoria por **+ usd mas, lo cual significa que si tenemos mas personas revisando tickets, o mas usuarios ftp, simplemente el servidor va a tronar como ejote. No puedo decir que, pero si que 15% es nuesa opción de crecimiento si no consideramos tickets.

La alternativa es la opción B que nos da un margen de aproximadamente 40%, no son datos duros.

Los dos principales consumos actuales de memoria son el usuario root2, y el sistema de tickets.

En cuanto a los espaldos, como mencioné en noviembre del 2010 y en varias oportunidades en medio, necesitamos hacer una prueba de respaldos en frio, y sacar respaldos de una manera mas normal.

Corolarios:

1 ) No podemos sacar respaldos de servidor a servidor por el usuo de memoria y cpu, y nuestro server ya esta justo de espacio para un respaldo, incluso despues de borrados los temporales.
2 ) No es posible implementar sistemas nuevos en este servidor, porque tiramos el cpu. No pueden evaluarse de manera correcta funcionalidades de software en elserver, estando el server en las condiciones de uso en que está por el uso de cpu y ftps diversos.

========================================

Como dato idiota, uno de los destinatarios se enojó pero nadie ha hecho nada. Estamos llamando al desastre. (y ayer vi algo peor pero en software, luego comento.)

Desde que nos cambiamos a esta oficina, coincidiendo con la entrada «operativa» de una persona, noté que nuestra red estaba siendo altamente inestable. Noté también serios problemas en cuanto a la latencia, y al conectarme al servidor de la empresa a los dos minutos me botaba, o sea que tratar de hacer cambios «en vivo» tenía problemas extras por el exceso de ftps. No puedes subir archivos por FTP a un servidor sin conexiones , porque clientes agotaron los FTP (conexiones agotadas) y menos si tu propia red está saturada por Youtube/facebook

En su momento decidí aplicar un wireshark para verificar que paquetes estaban siendo interceptados y encontré varios de conexiones con youtube (sitio que deberían de bloquear de todos los centros de trabajo relacionados con seguridad), pero no le dí mayor importancia.

Una de las cosas que empecé a hacer era guardar los datos en mi propia pc, y a través de un mecanismo de encriptación y desempaquetado subir un archivos al server de nuestra empresa, que por medida de seguridad solo permite que e conecten clienttes de México, asi qye otras redes externas ( las famosas de prueba tipo 127.0.0.1 de redes privadas), tampoco pasan.

Hoy, por cosas que no venian al caso decidí desactivar mi VPN normal (la que establezco para investigaciones y para mis propios servidores), y me pasé a la red wireless de nosotros, corporativo. En lo personal estoy empezando a hartarme de la nula conexión de internet. Me conecté a la segunda wireless por la urgencia, hice lo que tenía que hacer, y oh sorpresa, en cuanto esta persona se levantó de su lugar, cerrando su computadora la conexión se restableció magicamente.

El problema entonces, dejando de lado del ancho de banda consumido por elk sujeto, es que por lo visto una red saturada es mas susceptible a tirar VPNs con SSL.

De todos modos mi impresión general es la correcta:

Para todo lo que no es de nuestro servidor, conectarme a través del tunel ssl a uno de mis servidores en Houston, y de ahí verificar lo que tengo que hacer.

Lo malo del asunto es que el rendimiento de la red del corporativo se va a pique por mientras. Afortunadamente como por estructura dependo de la otra unidad de negocio, quizá deba de estar usando la Wireless que no está relacionada con mi «subproyecto» principal.

Y las clases de español para definición de objetivos, para esa unidad, quedan en el tintero.

Una de las cosas que me obliga a tomar todas mis reservas de paciencia, es el desconocimiento de las personas que el desarrollo es una mezcla de tres factores: Tiempo, alcance y recursos.

La semana pasada en el viaje a Oaxaca noté que la Laptop Inspiron 1525 se estaba sobrecalentando nuevamente, y por lo visto mañana tendré que formatear y revisarla a fondo, pero mejor lo haré en casa aunque es justificable el hacerlo en horas de trabajo, sobre todo si es mi computadora, que presto al trabajo.

El problema de otros asuntos, es que el control de tiempo por el timer de cocina puede hacerse cuando se busca trabajar, pero se que si lo uso en mi trabajo normal, demuestro mayor rendimiento que otras personas, lo que suele no dejar a la gente muy contenta, y eso que mis labores son mas amplias.

En estos días se dio el caso de uno de los programadores de otra unidad, quizá el menos novato de ellos, y después de la junta del martes con todos sus detalles de falta de control, no me extrañaría que esté pensando en irse. El problema es que lo que el hace es el core, que en su momento le delegué, y ahora que quieren usar tres de mis subsistemas como punta de lanza de un revamp insustentable, veo el peligro del desconocimiento del core. Creo que el futuro de esa unidad de trabajo, está en entre dicho, no solo por el hosting INUTIL de 20 mil pesos mensuales que pagan para tratar de sacar una certificación que no es posible desde hace mas de dos años, sino que por una «actitud positiva» están creando en esa unidad un problema de las empresas grandes, sin ninguna de sus ventajas.

Ya ofrecí dos ideas de negocio, pero estan demasido interesados en lo que parece ser un cambio de apariencia gráfica de un formulario php que por definición lleva unos 120 campos en uno de los masu usados, sin pensar que la estructura vertical es obligatoria, para formularios como el derivado de AMECE que por definición son 40 renglones de 10 a 15 campos, sin tomar en cuenta nada mas que la parte detalle del formulario.

Por un lado dan ganas de reirse, y por otra, entiendo que en la junta del martes dijeran de los tres proyectos que quieren que se hagan, en pocas palabras, que lo que hice por fuera sea el punto de venta del desastre que hicieron desde Noviembre del 2010.

Ok. No me gusta decir se los dije pero es obvio que está pasando.

Muy bien, y los otros «programadores» de la junta, que se supone saben mas que yo del core de negocio ?

Algo esta mal si hacen perder el tiempo a esos otros, que no tenían nada mas que decir de estos 3 proyectos, que por lo visto no conocen sino de manera superficial al querer «cambiarlos» para hacerlo punta de lanza. Es como tratar de meter lo que funciona de un coche funcionando a uno descompuesto: A la larga se tienen dos coches inservibles.

Además, si un coche funciona, con tres subsistemas diferentes, y quieren usarlo de punta de lanza, es evidente primero que funciona (muy a su pesar), y que si algo sale mal, el equipo de una persona que tiene esos proyectos funcionando, o sease yo, tiene mayor idea que la otra unidad , que necesita como punta de lanza aquello en lo que no tuvieron que ver.

El equipo del coche funcionando, le pueden pedir que haga un trailer, pero parece la misma historia de siempre : dos o mas timoneles y un solo remero. Y además los timonles tienen prisa de subirse a un coche encendido, pero eso no hace que el camino que el coche descompuesto destruyó, vaya a repararse.

Será un año de tarugadas en sistemas, parece.

En muy poco tiempo me ha tocado ver demasiadas tarugadas relacionadas con sistemas… espero que sea solo uan temporada y no todo el año vaya a ser así.

1 ) la cliente que no puede abrir su correo
2 ) El cliente del cliente del corporativo que me da derechos de ver la existencia de la tabla en oracle pero no de select
3 ) El soporte de servint que no entendió que el powerpanel estaba fallando y que queria yo restaurar un archivo que estaba en x lugar, y no restablecer todo el servidor a dias atras ( menos mal que lo pude parar … me dan ganas de dejar servint)
4 ) el proveedor de dominios que puso aumento oculto de precios y que detecté al hacer mi nueva lista de precios.

Demasiado para aguantar todo un año a ese tipo de idiotas codiciosos.