С какими видами мошенничества я сталкивался на фрилансе и аутсорсе
Я знаю, что люди обожают истории, в которых автора облапошили или о событиях на пути становления. Так что надеюсь, вам будет интересно.
С первым видом обмана я столкнулся еще в двухтысячном, когда получил заказ на исправление ошибки принтера. Узнав, что у заказчика стоит Windows 95, я взял стандартный набор дискет для ремонта/восстановления системы и поехал в чертову даль, так как это был завод за чертой города.
Прибыв, я быстро завершил квест с проходной, вахтером и пропуском и попал наконец в кабинет к директору. Который и включил мне допотопного вида компьютер, на котором гордо стояла… Windows 3.11!
Я был полностью ошарашен, так как мы говорили о Windows 95. Да и набор дискет (которые кстати не подходили даже по форм-фактору) у меня был от Windows 95. О чем я и сообщил директору.
На что тот сказал, что в версиях ничего не понимает, возможно что он что-то напутал. И дал коробку с восемью дискетами дистрибутива. Найдя там драйвера принтера и переставив их, что конечно ничего не дало, я предложил попробовать установить Windows 95, где возможно эту проблему решили.
На что директор сообщил, что это невозможно — там 286, в то время как Windows 95 требует 386. Хмм, не странно ли, что человек путающий версии так хорошо знает про системные требования?
В общем, уехал я к вечеру, на служебном автобусе голодным, так как никакое шаманство не помогло то мне ничего и не заплатили, а столовая работала только для сотрудников завода, да и денег я с собой не взял, считая что зачем их брать если мне и так заплатят? (Да, я тогда был юн и глуп).
Вариантов подобного мошенничества была масса, самым эпичным из которого — был поиск сисадмина, который поставит ISP Manager на сервер. Изюминка была в том, что сервер представлял собой виртуалку на IBM System S390. Причем это все скрывалось тщательным образом — вывод /proc/cpuinfo подделывался примонтированным файлом, часть утилит заменялась или просто удалялась. Разумеется, что исполняемый файл для i386 архитектуры не пойдет на s390 системе. Чувак, если ты это читаешь сейчас — напиши, зачем ты это все затеял?
Мораль проста — перед тем как взяться за работу, нужно потратить некоторое время на аудит окружения, чтоб убедиться в том, что оно соответствует заявленному заказчиком.
Второй вид мошенничества не так давно был очень популярен на фриланс-бирже Upwork. Как сейчас — не знаю, эти кретины меня заблокировали, требуя диплом DevOps Engineer государственного образца (лолшто?).
Обычно это был небольшой проект с маленькой разовой оплатой, который решается максимум за пару часов. При этом заказчик очень настырно допытывается о твоем опыте и проектах, которые ты решал, причем совершенно не релевантных данному заказу и мотивируя тем, что исполнителей много, а он хочет выбрать для себя самого лучшего.
Ладно, исполнитель выбран, сама задача — обновить PHP, потому что yum не работает и выдает ошибку (побилась база rpm, ничего страшного). И вот ты такой заходишь по ssh и вдруг чувствуешь, что что-то не так. Как-то все медленно и лагает. Смотришь загрузку системы — и она на 80% wa. А в логах — сообщения о проблемах с диском. И ты такой:
— Эй, чувак, у тебя тут серьезные проблемы на сервере! Твой диск вот-вот готов отбросить коньки. Ошибки на диске привели к тому, что побилась база rpm, которая не дает yum поставить php.
— Оу! Какая жалость. А никак нельзя починить yum, чтоб обновить php? Мне очень нужна новая версия.
— Серьезно? Тебе надо подумать о том, чтоб сохранить свои файлы, так как все в любой момент может сдохнуть.
— Все так плохо? Ну хорошо, у меня чисто случайно (ну да, а ты что, не верил?) рядом есть пустой жесткий диск. Сбрось туда копию всей системы, а потом заодно обнови там php.
— Эмм. Вообще-то в заказе просто надо было обновить php, без переноса системы…
— Ну если ты такой неумеха, что не можешь обновить php без переноса системы, то тогда переноси ее.
Ты — обновляешь версию PHP просто скачав rpm и распаковав их содержимое на систему, выводишь файл phpinfo в браузере на его сайте и делаешь скриншот. И через час:
— Готово, прошу проверить версию php по ссылке!
— Отлично, то что надо! Ты так быстро перенес систему!
— Я не переносил систему.
— ЧТО???
— Я. Не. Переносил. Систему. Я просто обновил тебе php без переноса системы, так как я — не «неумеха». Прошу приступить к расчету.
— Эй! Немедленно переноси мою систему на новый диск!
— Ммм… нет.
— Тогда я отказываюсь платить, так как ты мошенник!
— Тогда я обращусь в поддержку и покажу заказ в котором указана задача по обновлению php и скриншот твоего сайта где показана та самая версия.
— Ааа! Ты мошенник!!! Никогда не буду иметь с тобой дел!!!
Впрочем, на следующий день он вернулся и извинился за вчерашнее, мол это его так шокировала новость о том, что его диск сдыхает. И предложил доплатить за клонирование системы. Я же настаивал что сначала мы должны произвести расчет за уже проделанную работу, так как его проект по факту выполнен. Спустя пол-дня упреков и отговорок, он наконец-то закрыл проект как выполненный и закинул деньги.
— Все, теперь когда мы в расчете, ты можешь наконец перенести систему?
— Да, могу. Только это уже должен быть новый проект о клонировании системы.
— Не понимаю, зачем это надо? У меня деньги есть! Я могу скинуть тебе прямо сейчас на paypal (а потом вернуть все обратно, обратившись в саппорт paypal).
— В моей стране paypal не позволяет принимать платежи (это правда).
— Вот черт! Ну тогда приступай прямо сейчас, а я оформлю тебе перевод через Western Union.
— Я предпочту все-таки оплату через биржу, мне так надежнее.
— Ладно, вот проект, приступай.
— Мне нужен IP-KVM доступ для клонирования.
— Вот черт! И ты туда же!
— ???
— Каждый раз когда доходит до этого дела — вы все хотите эту штуку, который хостер дает по $200/день. Это чертовски дорого для меня!
— Хмм. То есть ты не в первый раз разыгрываешь все это представление, чтоб найти исполнителя, который сможет тебе склонировать систему без IP-KVM?
— Ээээ. Да.
— Почему бы сразу не написать именно так?
— А что, так можно было?
— Да. Я готов перенести тебе это без IP-KVM, не вопрос.
— О, я так счастлив!
— Это будет стоить на $200 дороже, чем указано в заявке.
— Ты чертов мошенник!!!
— Эээ, нет. Именно эту сумму хостер возьмет с тебя за подключение IP-KVM, так что эти деньги ты в любом случае потеряешь, если будешь делать заказ кому-то другому. А в моем случае — это будет дополнительным стимулом сделать все качественно и быстро.
— Звучит логично. Ладно, делай.
Ты — ставишь систему восстановления в бывший swap раздел, перезагружаешься и подмонтировав диски делаешь rsync с пропуском всех битых файлов (их было достаточно много, но они оказались в основном не критичными).
— Все готово, система работает с нового диска, можешь проверять
— Ты просто бриллиант!
После чего он ставит тебе одну звезду в отзыв и пишет гадости. Администрации биржи плевать на тебя и твои доводы.
Мораль — если вам встречается заказчик, который под видом одной задачи пытается переложить еще и другую (другие), мотивируя тем, что напрямую ему так будет дороже — теряйте его. Потому что потом себе дороже выйдет (я потерял кучу потенциальных заказов за тот отзыв, который таки сняли, но было поздно).
Следующий вариант мошенничества был несколько похож на предыдущий, но со своими отечественными, так сказать, нюансами. Он процветал на одной помойке, которая выдает себя за биржу фриланса с безопасной сделкой.
Все началось достаточно банально — нужно обновить версию php, потому что один из сайтов требовал мажорное обновление без которого не работал какой-то там плагин. Я попросил подтверждения в чате о том, что глобальное обновление php окажет эффект на все сайты, и если у него нет поддержки свежей версии — они перестанут работать.
Подтверждение я получил, как и оплату безопасным методом (по факту я ничего не получил, деньги зависли на бирже).
— Вот, готово.
— Ой-ой, мои старые сайты перестали работать!
— Ну, мы об этом говорили.
— Пожалуйста, верни все как было! Я еще доплачу столько-же!
— Хорошо, вот — вернул.
— Ой-ой, ты что-то сломал, мои старые сайты все еще не работают!
— Это как?
— Вот ссылка, вот и вот и еще вот. Посмотри пожалуйста!
— Ты — смотришь содержимое сайтов и понимаешь, что они заражены какой-то малварью и сообщаешь об этом.
— Ааа! Они заражены из-за новой версии php, которую ты поставил!
— ???
— Ты обновил php, но не закрыл его дыры! Через них мои сайты заразили!
— ???!!!
— Давай чини, я тебе скинул деньги и ты должен. А если не сделаешь, то я тебе ничего не заплачу.
— А ничего, что там дата изменения файлов задолго до того, как я зашел на сервер?
— Ничего не знаю, до тебя все работало! Чини!!!
Ты — плюешь на этого наглого неадеквата, потом пишешь в поддержку, понимаешь, что неадекватность — это норма для отечественного рынка фриланса и закрываешь этот ужас навсегда.
Мораль — не ходить по помойкам, там все равно ничего интересного нет. Если на зарубежных биржах мошенники это люди с актерскими талантами, то у нас — унылые неадекватные хамы.
Следующее мошенничество — это уже нечто, достойное уважения. Заказчики имеют очень сложный облачный проект в AWS, документации на которой у них фактически нет, кроме README.md в корне репозитория.
Сам файл невероятно длинный, в котором в пространных выражениях написаны фрагменты последовательностей действий в стиле Тарантино, причем так, что нужно целиком в голове удержать этот огромный файл в голове:
Для размещения инфраструктуры сначала нужно запустить особый скрипт, который генерирует шаблон CloudFormation, который разбивается на части и заливается в S3, после чего создает нужную инфраструктуру. Причем в самом скрипте находится ровно одна ошибка в очень неочевидном месте (люди так не ошибаются, блин!), в шаблоне, который она генерирует тоже есть ошибка — и это далеко не все.
Потому что для размещения приложения надо взять другой репозиторий, создать миллион CI переменных, значения из CloudFormation по выполнению и запустить CI на втором репозитории.
Он создаст сценарий от CodeDeploy, который не будет работать — потому что там ошибка и нужно сносить инфраструктуру и опять править шаблон CloudFormation.
А далее еще в одном репозитории вы смотрите на сценарий CI, который вызывает питновский скрипт, в котором содержаться по факту только команды shell, который формирует докер-образ, в котором должны быть конфиги для puppet деплоя, которые вы забыли положить, потому что ни в одной инструкции нигде нет про это упоминания и это все заканчивается тем, что awsfabric, который вызывается где-то между этим хаосом, берет креды не из CI окружения, не из образа докера, а из отдельного конфига, который сделан еще первым скриптом, но про который вообще нет упоминаний негде.
А знаете что самое шикарное? У заказчика было 2 проекта на этой чудо-юдо платформе, причем все ошибки повторялись по числу —, но в разных местах. Грубо говоря — в одном шаблоне была неправильная версия RDS, которая рушила весь flow, а в другом — CloudFront прикреплялся к неправильному S3-бакету.
Разумеется, заказчик утверждал, что там мол делать нечего и те, кто это все наделали — выполняют деплой буквально за два часа. И я охотно в это верю:
Сам стиль ошибок и документации, а так же анально-орального деплоймента говорит о том, что разработчики сделали целую сложную систему, которая позволяет генерировать обфуцированную версию проекта таким образом, чтоб максимально затруднить всевозможный деплой постороннему: секции документации миксуются, но при этом составляют логически верный документ с миллионом примечаний типа «см секцию 2 выше». Деплоймент также разделяется на несколько частей, в двух из которых делаются не фатальные для самого деплоя ошибки, но которые приводят к неработоспособному результату в финале, а финальный кусок обфуцируется глубокой вложенностью и еще одним разделением.
После этого, если у тебя нет информации о тех местах, где сгенерированы ошибки и мастер-скрипта который автоматизированно сцепляет все три части, передавая им тонны параметров — те самы два часа его работы прекрасно вытекают в две недели, за которые ты можешь отлично почувствовать себя самым настоящим IT-золотарем, после чего заказчик окончательно разочаруется в твоей работе.
Мораль — если кто-то очень захочет привязать к себе заказчика, то при достаточном уровне мастерства он очень легко это сделает. Просто умейте вовремя это распознать и сказать твердое нет. Мне хватило трех дней.
И последний, самый наглый и интересный вид мошенничества — это IT-газлайтинг.
Допустим, ты расшифровал обфуцированный метод, описанные выше и смог настроить деплоймент.
Однако при этом после пайплайна ничего не происходит. Все прошло без ошибок, результат успешен —, но ничего не изменилось. Как так-то?
А вот как — сам раннер, на котором завязан CI/CD находится у разработчика всего этого проекта, о чем заказчик вообще был не разу не в курсе.
И на этом раннере в самом начале идет сообщение о том, что контейнер для пайплайна не может быть создан, так как уже есть контейнер с таким именем и он будет использован. После чего все запускается без ошибок.
Разумеется, что проблема в раннере, но при этом разработчик соглашается со всем, что передает ему заказчик — прибить контейнер, пересоздать раннер…, но по факту ничего не делает.
Если заказчик более-менее адекватный, то можно ему это показать, изменив файл деплоймента, чтоб там выполнялась какая-то команда, например echo с текущей датой. И продемонстрировать, что там не выполняется измененный сценарий, так как сам сценарий фактически лежит в контейнере и туда передаются только переменные.
Однако и в этом случае вы особо ничего сделать не сможете — если создадите свой раннер, то… правильно — на нем перестанет выполняться деплоймент всех старых проектов заказчика, причем разработчик естественно не даст доступа к раннеру, а просто скинет документацию, которая совершенно отличается от того, что по факту установлено на раннере: например в документации базовый образ может быть AWS AMI, в то время как используется некий кастомный Alpine Linux и в сценарии использован apk вместо yum, ну и так далее по мелочам.
И даже если заказчик согласиться с тем, что во всем виноват разработчик — то он не сможет от него отказаться. Доступа на раннер нет и что там на самом деле использовано — неизвестно, так как вы там даже не можете выполнять команды. Если создавать свой методом проб и ошибок, то это займет много времени, а заказчику традиционно нужно было уже вчера.
Ну, а если заказчик самый обыкновенный, то виноваты будете вы и никаким доводам он не поверит.
Мораль — если вы думаете, что у вас должно все работать, а оно не работает — возможно что виноваты не вы, а так было задумано создателем системы изначально.
Возможно, что вы тоже сталкивались с подобными мошенниками, а может стали жертвой принципиально нового подхода от заказчика-мошенника, который отличается от банального «пообещал — не заплатил»? Пишите в комментариях! Я их с удовольствием читаю и зачастую отвечаю на них.
