¿Qué tipos de fraude he encontrado en freelance y outsourcing?

Sé que a la gente le encantan las historias en las que el autor fue engañado o sobre eventos en el camino de convertirse. Así que espero que te interese.

El primer tipo de fraude que encontré en 2000, cuando recibí una orden para corregir un error de impresora. Cuando descubrí que el cliente tenía instalado Windows 95, tomé un conjunto estándar de disquetes para reparar / restaurar el sistema y conduje al infierno, ya que era una fábrica fuera de la ciudad.
Al llegar, completé rápidamente la búsqueda con un puesto de control, un conserje y un pase y finalmente llegué a la oficina del director. Lo que me convirtió en una computadora de aspecto antediluviano, en la que se alzaba orgullosamente ... ¡Windows 3.11!

Estaba completamente atónito, ya que estábamos hablando de Windows 95. Sí, y tenía un conjunto de disquetes (que por cierto ni siquiera cabía en el factor de forma) de Windows 95. Informé al director sobre eso.

A lo que dijo que no entendía nada en las versiones, es posible que haya confundido algo. Y le dio una caja de ocho discos de distribución. Habiendo encontrado los controladores de impresora allí y los reorganicé, lo que por supuesto no funcionó, sugerí intentar instalar Windows 95, donde probablemente resolvieron este problema.

A lo que el director dijo que esto es imposible: hay 286, mientras que Windows 95 requiere 386.

Hmm, ¿no es extraño que una persona que confunde versiones sepa tan bien sobre los requisitos del sistema?

En general, me fui por la noche, en un autobús de negocios, con hambre, porque ningún chamanismo me ayudó, no me pagaron nada, y el comedor funcionaba solo para los empleados de la fábrica, y no llevé ningún dinero conmigo, considerando que ¿por qué debería tomarlo si yo y entonces paga? (Sí, era joven y estúpido entonces).

Había muchas opciones para tal fraude, la más épica de las cuales fue la búsqueda de un administrador del sistema que pusiera el Administrador de ISP en el servidor. Lo más destacado fue que el servidor era una máquina virtual en el IBM System S390. Además, todo esto se ocultó cuidadosamente: la salida de / proc / cpuinfo fue falsificada por el archivo montado, algunas utilidades fueron reemplazadas o simplemente eliminadas. Por supuesto, el archivo ejecutable para la arquitectura i386 no funcionará en el sistema s390. Amigo, si lo lees ahora, escribe, ¿por qué empezaste todo esto?

La moraleja es simple: antes de comenzar a trabajar, debe pasar un tiempo auditando el entorno para asegurarse de que cumpla con los requisitos establecidos por el cliente.

El segundo tipo de fraude ha sido recientemente muy popular en el servicio Upwork Freelance. Como ahora, no sé, estos nerds me bloquearon, exigiendo un diploma de ingeniero de DevOps estándar del estado (¿lolshto?).

Por lo general, era un proyecto pequeño con un pequeño pago único, que puede resolverse en un máximo de un par de horas. Al mismo tiempo, el cliente pregunta de manera muy persistente su experiencia y los proyectos que ha decidido, que no son relevantes para este pedido y lo motiva con el hecho de que hay muchos artistas y quiere elegir lo mejor para sí mismo.

De acuerdo, el ejecutor está seleccionado, la tarea en sí misma es actualizar PHP, porque yum no funciona y arroja un error (la base de datos rpm se rompió, está bien). Y entonces sigues así y de repente sientes que algo está mal. De alguna manera todo es lento y rezagado. Usted ve el arranque del sistema, y ​​es 80% wa. Y en los registros: mensajes sobre problemas con el disco. Y tú eres así:
— , , ! - . , rpm, yum php.
— ! . yum, php? .
— ? , , .
— ? , ( , , ?) . php.
— . - php, …
— , php , .

Usted: actualice la versión de PHP simplemente descargando rpm y desempacando su contenido en el sistema, muestre el archivo phpinfo en el navegador de su sitio web y tome una captura de pantalla. Y en una hora
— , php !
— , ! !
— .
— ???
— . . . . php , — “”. .
— ! !
— … .
— , !
— php .
— ! !!! !!!

Sin embargo, al día siguiente regresó y se disculpó por lo de ayer, diciendo que estaba tan sorprendido por la noticia de que su disco se estaba muriendo. Y se ofreció a pagar extra por clonar el sistema. Insistí en que primero debemos hacer un cálculo para el trabajo ya realizado, ya que su proyecto se completó realmente. Después de medio día de reproches y excusas, finalmente cerró el proyecto como completado y arrojó dinero.
— , , ?
— , . .
— , ? ! paypal ( , paypal).
— paypal ( ).
— ! , Western Union.
— - , .
— , , .
— IP-KVM .
— ! !
— ???
— — , $200/. !
— . , , IP-KVM?
— . .
— ?
— , ?
— . IP-KVM, .
— , !
— $200 , .
— !!!
- UH no. Esta es la cantidad que le cobrará el proveedor por conectar IP-KVM, por lo que perderá este dinero en cualquier caso si hace un pedido a otra persona. Y en mi caso, esto será un incentivo adicional para hacer todo de manera eficiente y rápida.
Eso suena lógico. Esta bien hazlo.

Usted: coloque el sistema de recuperación en la partición de intercambio anterior, reinicie y monte los discos, sincronice con omitir todos los archivos eliminados (había muchos de ellos, pero resultaron ser en su mayoría no críticos).
- Todo está listo, el sistema funciona desde un nuevo disco, puedes comprobarlo
: ¡eres solo un diamante!

Luego te pone una estrella en una reseña y escribe cosas desagradables. Las administraciones de cambio no se preocupan por ti y tus argumentos.

Moralidad: si conoce a un cliente que, bajo el disfraz de una tarea, está tratando de cambiar otra (otras), motivándolo a que sea más caro directamente, lo pierde. Porque entonces será más costoso para mí (perdí un montón de posibles pedidos para esa revisión, que se retiró pero ya era demasiado tarde).

La siguiente versión del fraude fue algo similar a la anterior, pero con sus matices domésticos, por así decirlo. Él prosperó en un basurero que dice ser un intercambio independiente con un acuerdo seguro.

Todo comenzó bastante banal: debe actualizar la versión de php, porque uno de los sitios requería una actualización importante sin la cual algunos complementos no funcionarían. Solicité confirmación en el chat de que la actualización global de PHP tendrá un efecto en todos los sitios, y si no tiene soporte para la última versión, dejarán de funcionar.

Recibí confirmación, así como el pago de una manera segura (de hecho, no recibí nada, el dinero se colgó en el intercambio).
— , .
— -, !
— , .
— , ! -!
— , — .
— -, - , !
— ?
— , . !
— — , - .
— ! - php, !
— ???
— php, ! !
— ???!!!
— , . , .
— , , ?
— , ! !!!

Usted: escupe esta insuficiencia insolente, luego escribe en apoyo, comprende que la insuficiencia es la norma para el mercado independiente nacional y cierra este horror para siempre.

La moraleja es no ir a los basureros; allí todavía no hay nada interesante. Si en los intercambios extranjeros, los estafadores son personas con talento para actuar, entonces tenemos tristes inadecuados.

El siguiente fraude ya es algo digno de respeto. Los clientes tienen un proyecto en la nube muy complejo en AWS, la documentación en la que realmente no tienen, a excepción de README.md en la raíz del repositorio.

El archivo en sí es increíblemente largo, en el que los fragmentos de secuencias de acciones en el estilo de Tarantino se escriben en expresiones largas, y de tal manera que debe mantener completamente este enorme archivo en su cabeza:

Para colocar la infraestructura, primero debe ejecutar un script especial que genera una plantilla de CloudFormation, que se divide en partes y se vierte en S3, después de lo cual crea la infraestructura necesaria. Además, en el script en sí hay exactamente un error en un lugar muy poco obvio (la gente no está tan equivocada, ¡maldición!), También hay un error en la plantilla que genera, y esto está lejos de todo.

Debido a que para hospedar la aplicación, debe tomar otro repositorio, crear un millón de variables CI, valores de CloudFormation para ejecutar y ejecutar CI en el segundo repositorio.
Creará una secuencia de comandos de CodeDeploy que no funcionará, porque hay un error y debe demoler la infraestructura y volver a editar la plantilla CloudFormation.

Y luego, en otro repositorio, observa el script de CI, que llama al script de Pitnov, que de hecho contiene solo el comando de shell, que forma la imagen del acoplador, en el que debe haber configuraciones para el despliegue de títeres que olvidó poner, porque ninguno de los dos no se menciona esta instrucción en ninguna parte y todo termina con awsfabric, que se llama en algún lugar entre este caos, toma créditos no del entorno de CI, no de la imagen del acoplador, sino de una configuración separada, que fue hecha por el primer script, pero sobre la cual ninguna mención en absoluto .

¿Sabes qué es lo más chic? El cliente tenía 2 proyectos en esta plataforma milagrosa, y todos los errores se repitieron en número, pero en diferentes lugares. Hablando en términos generales, en una plantilla había una versión incorrecta de RDS que destruía todo el flujo, y en otra, CloudFront estaba conectado al cubo S3 incorrecto.

Por supuesto, el cliente afirmó que no hay nada que hacer allí, y aquellos que lo hicieron todo, realizan una entrega literal de dos horas. Y creo fácilmente en ello:

El estilo mismo de los errores y la documentación, así como la implementación anal-oral, sugiere que los desarrolladores crearon un sistema complejo completo que le permite generar una versión ofuscada del proyecto de tal manera que sea lo más difícil posible para un extraño: las secciones de documentación son mixtas, pero al mismo tiempo son lógicamente correctas. un documento con un millón de notas como "ver sección 2 arriba". El despliegue también se divide en varias partes, en dos de los cuales los errores no son fatales para el despliegue en sí, pero que conducen a un resultado inviable en el final, y la pieza final se ofusca por anidamiento profundo y otra división.

Después de eso, si no tiene información sobre los lugares donde se generaron los errores y un script maestro que vincula automáticamente las tres partes, les pasa toneladas de parámetros: esas mismas dos horas de su flujo de trabajo perfectamente en dos semanas, por lo que puede sentirse genial un verdadero orfebre de TI, después de lo cual el cliente finalmente estará decepcionado con su trabajo.

Moraleja: si alguien realmente quiere vincular a un cliente consigo mismo, entonces con un nivel suficiente de habilidad lo hará con mucha facilidad. Solo sea capaz de reconocerlo a tiempo y decir que no. Tres días fueron suficientes para mí.

Y el último tipo de fraude más descarado e interesante es la iluminación de gas de TI.
Suponga que descifró el método ofuscado descrito anteriormente y pudo configurar la implementación.

Sin embargo, no pasa nada después de la tubería. Todo salió sin errores, el resultado fue exitoso, pero nada ha cambiado. ¿Como es eso?

Y así es cómo: el propio corredor, en el que está vinculado el CI / CD, se encuentra con el desarrollador de todo este proyecto, del que el cliente nunca estaba al tanto.

Y en este corredor al principio hay un mensaje de que no se puede crear el contenedor para la canalización, ya que ya hay un contenedor con el mismo nombre y se usará. Después de lo cual todo comienza sin errores.

Por supuesto, el problema está en el corredor, pero al mismo tiempo, el desarrollador está de acuerdo con todo lo que el cliente le pasa: clavar el contenedor, recrear el corredor ... pero de hecho no hace nada.

Si el cliente es más o menos adecuado, puede mostrárselo cambiando el archivo de implementación para que algún comando se ejecute allí, por ejemplo, haga eco con la fecha actual. Y para demostrar que la secuencia de comandos modificada no se ejecuta allí, ya que la secuencia de comandos en sí misma realmente se encuentra en el contenedor y solo las variables se transfieren allí.

Sin embargo, en este caso también, no podrá hacer nada especial: si crea su propio corredor, entonces ... correctamente, ya no ejecutará la implementación de todos los proyectos de clientes antiguos, y el desarrollador naturalmente no dará acceso al corredor, sino que simplemente descartará la documentación, que es completamente diferente de que está realmente instalado en el corredor: por ejemplo, en la documentación, la imagen base puede ser AWS AMI, mientras que se usa algo de Alpine Linux personalizado y apk en lugar de yum en el script, y así sucesivamente.

E incluso si el cliente acepta que el desarrollador tiene la culpa de todo, entonces no podrá rechazarlo. No hay acceso al corredor y lo que realmente se usa allí es desconocido, ya que ni siquiera puede ejecutar comandos allí. Si crea el suyo por prueba y error, tomará mucho tiempo, y el cliente tradicionalmente lo necesitaba ayer.

Bueno, si el cliente es el más común, entonces usted tendrá la culpa y no creerá ningún argumento.

Moralidad: si crees que todo debería funcionar para ti, pero no funciona, es posible que no seas tú el culpable, sino que originalmente fue el creador del sistema.

¿Es posible que también haya encontrado estafadores similares, o tal vez haya sido víctima de un enfoque fundamentalmente nuevo de un estafador de clientes, que difiere del banal "prometido - no pagó"? Escribe en los comentarios! Las leo con gusto y a menudo las respondo.

Source: https://habr.com/ru/post/undefined/


All Articles