Это проблема управления.

Прежде чем критический код будет развернут, он должен быть проверен на версию, код должен быть пересмотрен, и, по крайней мере, использование должно быть документировано. Если речь идет о безопасности, выбирайте подходящих рецензентов и защищайте репо и документацию. Нет причин, по которым это не может быть начато немедленно.

Там есть большая проблема, чем безопасность работы.

Любой из этих разработчиков может поместить вредоносный код в компании, либо по ошибке, либо по своим собственным причинам. В худшем случае, они могли активно совершать гнусные действия, используя созданную ими ситуацию (вымогательство, саботаж, промышленный шпионаж и т.д.). В лучшем случае, их непрозрачность подвергает всех опасностям, связанным с безопасностью, и всегда оставляет вопросительный знак по отношению к любым проверкам или отчетности. Если что-то пойдет не так, кто скажет, что они каким-то образом не были вовлечены?

**Напишите короткий документ с описанием точно того, почему текущий подход ведет компанию по опасному пути (например, попадание в сценарий шины). Обрисуйте риски безопасности, может быть, даже процитируйте предостережения из вашей отрасли, со ссылками на статьи и т.д.

Также включите список способов, которыми подход этого парня вредит вашей собственной работе, а также работе ваших коллег.

И последнее, но не менее важное, убедитесь, что список рекомендаций, которые должны быть реализованы немедленно, такие как добавление кода в управление версиями для всех, чтобы увидеть, и запуск сервера на ВМ, к которой каждый имеет доступ. Очеркните, как эти меры никоим образом не должны влиять на работу этого человека, и просто добавят безопасности и прозрачности всему процессу - _чтоб было ясно, что нет разумных возражений против этих мер.**

Возможно, сядьте с вашим боссом, когда вы передадите ему этот отчет, и устно изложите точные опасения, которые вы здесь написали: что этот парень строит себе империю в инфраструктуре компании, и что, в конечном счете, он является потенциально опасным . Если ваши начальники чувствуют, что этот человек может стать неразумным, то вы можете последовать совету @BillLeeper ‘s и захватить контроль над его машиной, чтобы он не смог навредить вашей организации. Это, конечно, будет им решать.

К сожалению, вы не сказали, говорил ли кто-нибудь об этих проблемах со своим коллегой или руководством. Это действительно вредоносно? Или ваш коллега просто слепой? Или, может быть, менеджмент слепой?

Я сам был “тем” парнем.

На моей предыдущей работе у меня иногда были различные побочные задачи, чтобы “сделать этот маленький инструмент” или сделать что-то простое. Оказывается, никогда не бывает ресурсов для внутреннего программного обеспечения… Обычно все сводится к следующему:

– Кто-нибудь может посмотреть на решения, которые я выбрал, если они подходят? – Да ладно, нам просто нужен простой инструмент, который просто делает эту простую операцию, сделайте это, и все будет хорошо.

– Могу ли я создать виртуальный сервер на нашем сервере для этой штуки? – Чувак, он просто для внутреннего пользования. Просто сложите его вместе с другими вещами на этом сломанном физическом ящике. Или поместите его на тот ящик, который делает мы-не-что-функционируем. Или поставьте его на свою рабочую станцию.

Конечно, никогда не было ресурсов времени для написания документов. Если только я не решил сделать это в свободное время. Конечно, все, что я мог сказать, когда у некоторых инструментов были проблемы, это “работать над этим”.

И тогда я решил уволиться. Это был первый момент, когда кто-то из окружающих понял, что “маленькие внутренние” инструменты на самом деле важны, а “простые” вещи - не так уж и просты. Я потратил пару выходных на написание документов, чтобы меньше обманывать своих коллег. Прошел почти год, а я до сих пор каждый месяц получаю несколько звонков о том, как что-то сделать с моими внутренними инструментами.

Редактирование

Некоторые комментарии указывали, что я не должен помогать им бесплатно. В целом это правильно. Я хотел пояснить, что я не трачу часы своего времени на решение их проблем, я просто трачу минуту, чтобы ответить на вопрос. Технически это все еще верно, что я, таким образом, позволяю и поощряю существующую практику Кстати, компания предложила мне должность с частичной или почасовой оплатой для решения проблем, как я делал это раньше, и я отказался от этого.

Дело в том, что я не хочу заставлять моих бывших коллег “искать лучше” вместо того, чтобы просто спросить меня “На какой машине работает Veeam?”, могу ли я просто сказать имя или IP-адрес, не думая или сказать “Это должно быть написано на […]”. Кроме того, 2-минутный телефонный звонок с бывшей лигой обычно является таким же позитивным и расслабляющим отвлечением, как и посещение stackexchange.

Редактирование конца

Так что я могу предложить? Ваш коллега кажется вполне способным, не так ли? Обсудите это с руководством. Не говорите “он становится незаменимым”. Просто спросите их - что, если он уйдет? Что, если он заболеет надолго? Убедите их, что проблема реальна. Они должны обсудить ее с самим парнем, чтобы найти решение. Может, ему просто не хватает ресурсов? Может быть, ему нужен другой человек в команде “внутреннего программного обеспечения”, чтобы все это было красиво и приятно?

Большинство из этих ответов - ПОЛУЧАТЕЛЬНЫЙ ОБЕСПЕЧЕНИЕ на предположительные вредоносные намерения со стороны рассматриваемого разработчика.

Перед тем, как сделать скрытый образ сервера, а затем преступник-выгуливающий парня из офиса, почему бы просто не перевести дух и не попытаться понять, что происходит?

Это вполне может быть, что человек, о котором идет речь, переутомлен, не имеет достаточно ресурсов и был бы более чем готов поделиться знаниями. Или, может быть, он делает это в течение длительного времени и никогда не получал указаний на то, что ему нужно сделать иначе. Как минимум, особенно если его вещи РАБОТАЮТ, он заслуживает шанса решить проблемы и сотрудничать с коллегами.

Я не вижу никаких доказательств того, что что что-то из этого было предпринято в вопросе ОП. Прежде чем рассматривать драконовские варианты, попробуйте сначала пообщаться. Если у человека не было намерения причинить вред, вы можете ожидать от него сотрудничества.

Есть кое-что, чего я еще не видел в других ответах:

Случайно начинайте искать новую работу

Конечно, это основано на предположении, что вы уже поговорили об этом со своим менеджером. Другие ответы показали причины, почему это не ваша проблема, а проблемы вашего менеджера, и они также дали указания, как подойти к этому разговору с вашим менеджером.

Сейчас я смотрю на ситуацию, когда вы говорили об этом с вашим менеджером, а затем, по прошествии разумного времени, ничего не случилось по этому поводу. У Вас возникает ощущение, что Ваш менеджер не считает эту проблему такой большой проблемой, какой Вы ее знаете.

Это то место, где Вы, возможно, захотите начать искать новую работу. Независимо от того, считает ли ваш менеджер, что это не проблема или он просто не понимает этого достаточно хорошо, чтобы увидеть проблему, здесь что-то не так. (И я говорю не о “личном” коде, а о проблеме того, что менеджер ничего с этим не делает.)

Такая проблема - это то, что вы вряд ли сможете изменить с позиции разработчика. Однако, есть и другие компании, и у них нет таких же проблем, так что, возможно, вы захотите найти другого работодателя.

Смотреть на это с положительной стороны, однако, не так уж и много давления на вас сейчас. У вас есть работа, и вы не ожидаете потерять ее. Вам не придется идти на компромисс, чтобы продолжать платить арендную плату, ипотеку/жизни. Вы можете просто случайно начать осматриваться и не увольняться с текущей работы, пока не найдете ту работу, которая Вам действительно нравится.

Кажется, здесь есть хорошие средства, чтобы предотвратить это в будущем, но не то, что делать сейчас.

1. Защитите компьютер. Либо руководство и IT-специалист проходят через него, когда он разблокирован и не обслуживается, либо требуют, чтобы он разблокировал машину и предоставил доступ. Тогда уберите этого монстра из сети. Сделайте немедленное изображение HD в случае, если у него есть выключатель мертвецов.

2. Немедленно увольте этого человека. Выведите его за дверь. Не волнуйтесь о причине, на его компьютере будет много улик. Если компания беспокоится, пусть их адвокат работает своей магией, вот за что им платят.

3. Соберите команду. Объясните, что произошло. Этот человек действовал опрометчиво и непрофессионально. Он поставил компанию под удар и был за это уволен. Потребуются все ресурсы, чтобы разобраться с этим бардаком.

4. Используйте команду, чтобы перестроить и развернуть эту работу должным образом на защищенных машинах и т.д. Команде придется пройти через app by app и разобраться со всем. Не волнуйтесь сразу о переписывании, просто убедитесь, что нет задних дверей и т.д., затем поднимите услуги на свежем, контролируемом оборудовании.

5. Получить эксперт по безопасности в. Этот парень, вероятно, не пойдет тихо и попытается “взломать” обратно, чтобы саботировать или иным образом получить доступ к своей системе. У него также могут быть глобальные пароли к системам, с которыми он взаимодействовал или получал индивидуальные пароли с течением времени. IT-отдел должен инициировать принудительный сброс пароля для всех пользователей и блокировать любой внешний доступ на некоторое время (например, VPN).

Все текущие ответы и большинство текущих комментариев только констатируют текущую ситуацию или дают предложения для принятия экстремальных мер.

Просто для подведения итогов: Существует две возможные ситуации: Сотрудники делают это намеренно, в этом случае они тем или иным образом вредоносны, и тогда необходима крайняя осторожность. Или же коллеги просто не видят потенциальных и реальных проблем и опасностей, которые они вызывают, тогда они “дружелюбны”, но должны быть осторожны, чтобы сделать лучше.

Таким образом, следующая дорожная карта пытается две вещи одновременно: 1) Попробуйте свести к минимуму потенциальный ущерб, эти коллеги могут сделать, если они злонамеренные, и 2) попытаться держать их в компании (чтобы они могли развиваться до кооперативных коллег в будущем), если они дружелюбны:

(btw: Я знаю, вы не босс, но с информацией, другие предоставили, я думаю, у вас будет все в ваших руках, чтобы убедить вашего босса, чтобы принять эту тему очень серьезно, так что эта дорожная карта адресована то, что вы босс мог бы сделать, а не то, что вы бы сделать. Единственное, что вы можете сделать, это привлечь внимание к вашему боссу. btw2: Если вы босс до сих пор не слушает, искать новую работу и уволиться, как только вы нашли новую. Потому что эти коллеги тикают бомбы замедленного действия, независимо от того, дружелюбны они или вредоносны - это совсем неважно).

1.). Бесшумно делайте резервные копии всего, к чему вы можете получить доступ. Не выключайте системы в процессе работы, выключение систем может привести к каким-то минам-ловушкам.

2.)). Постройте причину, по которой рабочие станции должны отключаться. Если вам нужна идея, свяжитесь со мной наедине.

3)). Извлечь жесткие диски, сделать полное изображение, положить их обратно. Сделайте это за выходные или около того

4).) Если в системах есть средства обнаружения вторжений на уровне BIOS, и вы не можете их обойти, придумайте другую причину, почему эти системы обнаружения вторжений работают.

Эти коллеги создают инструменты для внутренних вещей, верно? То есть им не нужен доступ к системам клиентов и тому подобное?

5).) Если у них есть доступ к системам, им не нужен, меняйте пароли, убедитесь, что нет своего рода открытого ключа для входа, проверьте порты на наличие процессов, позволяющих нестандартный вход. Проверьте задания cron/at, проверьте inetd, проверьте все, что работает в данный момент. За каждый отдельный pid, вы должны быть в состоянии ответить, почему этот процесс работает вообще.

6.). Найдите нового сотрудника (действительно нового, совершенно неизвестного. Он должен быть действительно хорошим специалистом, потому что он должен быть в состоянии, чтобы взять на себя их работу в одиночку в течение некоторого месяца, если это будет необходимо. Вы не можете просто взять какой-то случайный выпускник (даже не один с наивысшей оценкой), вам нужны некоторые из тех парней, которые никогда не посещали университет вообще, но все еще знает все) и вставить его в эту команду, чтобы поддержать их. Тем более, что они вызывают блокировки на других рабочих, это может быть легко оправдано. Его официальная работа заключается в поддержке их, его реальная работа заключается в том, чтобы узнать, как они работают.

Шаг 6 особенно важен, потому что таким образом, у вас есть шанс, на самом деле выяснить, являются ли эти коллеги вредоносными вообще.

Если новый парень хорошо интегрируется в команду, то вы можете предположить, что они дружелюбны, что новый парень должен быть в состоянии осуществить необходимые изменения без необходимости говорить этим парням, что было любое подозрение против них вообще.

Если новый парень узнает, что они вредоносны, но они интегрируют его, то его работа заключается в том, чтобы подыгрывать. Узнать все, найти это круто, что они делают, и так далее. Заплатите ему в два раза больше денег, потому что он должен работать дважды, потому что как только он вернется домой, он должен записать все, что он узнал, и отправить это какой-нибудь новообразованной команде, которая должна взять на себя работу, как только будет передано достаточно знаний.

Если вредоносные парни не интегрируют его, то ваш единственный шанс - это надеяться, что вы получили достаточно данных для резервного копирования (просто на всякий случай) и уволить эту команду. Тогда вам могут понадобиться два или более дополнительных супер-эксперта, о которых я говорил выше, чтобы новая команда очень быстро вошла в этот код.

Я надеюсь, что эта дорожная карта поможет - по крайней мере, как источник вдохновения о том, как с этим справиться. Может быть, в вашей компании есть какие-то варианты, которые я не могу рассмотреть, может быть, есть какие-то культурные различия, так что вам все равно придется подумать об этом и, может быть, скорректировать план.

Программисту, о котором идет речь, нельзя давать новую работу до тех пор, пока ситуация не будет так или иначе решена. Все новые требования должны поступать к другому разработчику/команде, который должен следовать соответствующим процедурам контроля за исходным кодом и экспертной оценки (новые сотрудники, если необходимо). Программист, о котором идет речь, может быть занят исправлением дефектов или “пожаротушением” своего существующего наследия. Должны быть выделены ресурсы для реинжиниринга существующего наследия и его повторного внедрения соответствующими процессами. Стоимость этого должна быть оправдана существующим риском - сколько это будет стоить бизнесу, если все, что сделал этот программист, внезапно будет потеряно? Или, что еще хуже, какие проприетарные (фирменные) данные могут быть потеряны конкурентами?

Возможно, стоит спросить у этого сотрудника: “Что с нами будет, если вас сбивает автобус или вы решите отправиться в месячный кругосветный кругосвет?” и оценить реакцию, чтобы решить, добровольно ли он сдаст свой код. Если сотрудничать, нет необходимости, чтобы ситуация стала враждебной, если нет никаких признаков беспокойства для компании с его стороны, время, чтобы заняться обеспечением безопасности все, к чему он прикасался.

**Как подойти к руководству по этому поводу?

Скажите, что лучшая практика - не допускать этого по многим причинам.

Профессиональные программисты должны знать, что это не способ ведения бизнеса; а если менеджеры больше ничего не знают, то они должны хотя бы знать это (программисты должны говорить менеджерам и/или менеджеры должны говорить программистам).

Причины, которые, как мы надеемся, настолько известны, что мне не нужно говорить вам. Они включают в себя “запасной вариант”, т.е. вы попали в беду, если потеряли программиста (или если их перевели на что-то другое), или если программист потерял свою машину.

По крайней мере, у вас have “управление версиями компании”, так что вам не нужно бороться в этой битве; просто сделайте это требованием к работе/процессу, чтобы его действительно использовали.

Скорее всего, вам не следует запускать производственное программное обеспечение на машине разработчика. Первым шагом может быть настаивание на том, что:

• Пользователи не делают сетевых соединений с машиной разработчика
• Программное обеспечение запускается на/с рабочего сервера
• Программное обеспечение, запущенное на рабочем сервере, должно быть собрано кем-то другим (или машиной сборки), из контроля исходных текстов

Реализация, требующая проверки исходных текстов, инструкции по сборке, опубликованные. Я бы посоветовал сделать это в качестве полу-чрезвычайной меры. Разрешите разработчику не писать доступ к производственному серверу или сборочной машине (чтобы проверить, что производственный код может быть собран из средств контроля версий).

После того, как вы это сделали (после того, как вы знаете, что исходный текст находится в средствах контроля версий и инструкции по сборке опубликованы), тогда другие разработчики могут подумать о том, чтобы проверить исходный текст и помочь в его сопровождении.

Обратите внимание, что * Get Rid Of Indispensable Programmer As Quickly As Possible ** было опубликовано Джеральдом Вайнбергом в 1971 (так что, на самом деле, все должны знать об этом уже сейчас). IIRC оригинальная цитата,

“Если программист незаменим, избавьтесь от него как можно быстрее”.

Это не ваша проблема, это ответственность и роль менеджеров, вы просто коллега и, возможно, не имеете всей необходимой информации. Я бы больше беспокоился о своих собственных задачах, а не о том, чтобы вмешиваться в работу моих коллег. Я не вижу, как что-то позитивное выйдет из шумихи по поводу вашего коллеги.

Вы сделаете из него врага, вы покажете вашего менеджера за некомпетентность и создадите впечатление, что у вас так мало работы, что у вас есть время, чтобы начать внутренние расследования, не спрашивая или не имея полномочий.

Вопрос в том, насколько сильно ты хочешь вырваться из этого порочного круга? Потому что давай не будем милыми, это будет стоить фирме.

1. Фирме придется потратить деньги, чтобы нанять кого-нибудь для написания кода, который контролируется фирмой.

2. Фирма должна будет потребовать код от кодировщика, а обратно, при необходимости, с юридической помощью. Отмечу, что код был заказан фирмой, что шифровальщик при написании кода получал зарплату от компании, так что код принадлежит фирме. Неудача со стороны шифровальщика при написании кода в худшем случае будет считаться воровством, что будет являться уголовным преступлением.

Свобода не свободна. Если фирма не готова тратить ресурсы, чтобы быть свободной от этого человека, то все, что вы делаете, это хлопаете деснами. Вам всем придется столкнуться с ситуацией, потому что если шифровальщик уедет или его переедет грузовик, то фирма SOL.

Рассмотрим причину, по которой они это делают. Вполне возможно, что углы сокращаются в соответствии с временными ограничениями, целями производительности и постоянно растущими требованиями. Это часто приводит к техническому долгу и одному очень напряженному программисту, у которого нет другого выбора, кроме как исправлять каждую проблему.

Этот человек вполне может писать вещи таким образом, что только он может исправить их, потому что у него нет времени, чтобы документировать, верстировать и поддерживать код своевременно. Поверьте мне, когда я говорю, что это оказывает крайне негативное влияние на любого, кто окажется в таком положении. Это не слишком уютная роль, когда кто-то может сидеть сложа руки и расслабляться.

Если, как подсказывает ваше название, они не решают проблемы, то проблем не будет. Вы бы просто выбросили шифратор, со всем их кодом, потому что он бесполезен.

Предотвращение подобных ситуаций является чрезвычайно простой задачей управления. Из этого следует, что менеджмент, который знает о проблеме, не компетентен, а менеджмент, который знает о проблеме, не знает.

К сожалению, разделение таких ситуаций, как эта, является сложной задачей управления. Поэтому, поскольку менеджеры, отвечающие за этого разработчика, даже не смогли предотвратить ситуацию, не рассчитывайте на то, что они смогут исправить ее.

*Способом исправления этой ситуации является переход на более высокий уровень управления. * Если они заинтересованы и способны это исправить, вам даже не нужно ничего объяснять больше, чем вы нам объяснили - просто сделайте это менее личным, сосредоточившись на программах и проблемах с ними, а не на программисте.

Вы должны знать, что это вариант высокого риска - низкое вознаграждение. Если вы сделаете это, даже если это сработает, разработчик и его менеджер (который, вероятно, также является вашим менеджером) пострадают, и знайте, что вы ответственны за это. Единственное преимущество, которое вы получаете, делая это, это то, что вы (возможно) следуете своему собственному кодексу этики и чести, но вы можете потерять свою работу из-за этого. Вот почему некоторые другие ответы рекомендуют отпустить это или просто искать лучшую работу, что является самым умным.

• *

\ * Другой способ исправить это - стать менеджером и исправить это, но здесь есть довольно много подводных камней.

После собственной самооценки он решил, что у него нет шансов на повышение, и единственная причина, по которой компании придется его удержать, это то, что он скрывает код от них.

Не знаю, согласны ли вы с этим, но если согласны, то, возможно, код мог бы сделать кто-то получше. Или если вы не объясните, почему такое поведение гарантирует, что его никогда не повысят.

Я думаю, это сводится к тому, стоит ли исправлять эту ситуацию так же сильно, как и как это исправить.

Это задача руководства. Сначала руководство должно попытаться выяснить, является ли это преднамеренным. Если да, то должен быть составлен план увольнения обидчиков. Если это не преднамеренно, следует разработать план по обучению обидчиков.

Они разрабатывают свои программы … так что их постепенно труднее заменить.

Не будь я боссом!

Здесь две проблемы:

1. Плохой программист.

2. Некомпетентное управление.

Это, конечно, при условии, что вы правильно представляете ситуацию.

Нельзя исправить проблему #1. Есть небольшой шанс, что вы сможете решить проблему №2. Этот небольшой шанс, если босс по каким-то причинам просто не знает, что происходит. Идите к боссу и расскажите ему о проблемах, которые вы видите, и почему они плохо влияют на компанию. Скорее всего, это провалится, потому что босс уже знает о проблеме и не компетентен ее решать, или знает так мало о программах и управлении инженерами программ, что он даже не компетентен понять проблему.

Единственное реальное решение - начать с исправления проблемы #2, в котором вы в лучшем случае можете сыграть второстепенную роль. Некомпетентный менеджер должен быть заменен.

Новый менеджер затем садится с этим программистом, просит его объяснить архитектуру, и говорит ему остановить любую новую разработку и задокументировать все протоколы. Между тем, он получает нового инженера, который “помогает” первому инженеру с документированием протоколов, переводом программного обеспечения под контроль исходных текстов, а также с тем, чтобы убедиться, что сам код хорошо документирован. Этот новый инженер делает любую новую разработку и, надеюсь, исправляет ошибки и вносит незначительные улучшения в существующее программное обеспечение.

Первому инженеру это не понравится. Он может уволиться, бросить истерику, шуметь объектами или, что еще хуже, саботировать вещи. Вот почему делать резервное копирование - это первая задача. Было бы неплохо иметь плавный переход от первого инженера ко второму, но не ждите, что это произойдет. План состоит в том, чтобы в конце концов уволить первого инженера, если он не уйдет или не станет (еще более) разрушительным против компании первым.

Вы просто не можете позволить этой чепухе продолжаться. Чем дольше вы это делаете, тем больнее в конце концов это исправить. Не исправлять, потому что уже будет больно - это абсолютно неправильный способ подумать об этом.

В данном случае я использовал риторическое “ты”. Чтобы ответить на вопрос, что вы лично можете сделать, начните с того, что доведете свои опасения до босса, как я сказал выше. Опять же, это вряд ли приведет к чему-то полезному.

Следующий шаг зависит от того, что вы нам не сказали. Это может быть очень опасно для босса. Если да, то мало что еще можно сделать, кроме как оценить, действительно ли ты хочешь продолжать работать там. Если это достаточно маленькая компания, где можно с комфортом поговорить с высшим руководством, то вперед. Вполне возможно, что у высшего руководства уже есть ощущение, что менеджер программного обеспечения низкого уровня некомпетентен, но, конечно, они не скажут вам об этом. Это может быть дополнительной информацией для них, чтобы предпринять более решительные действия.

Другая отдаленная возможность, если ваша главная цель - исправить этот беспорядок, и вы видите себя более долгосрочным в этом месте, это предложить взять на себя разработку некоторых внутренних инструментов самостоятельно. Это должно дать вам законный повод поговорить с первым инженером, понять, как все работает, где живет код и т.д. В конце концов, вы будете парнем с инструментами, и руководство сможет избавиться от первого инженера. Затем вы можете попросить их нанять кого-нибудь на эту роль, чтобы вы могли вернуться к тому, что вы хотите делать. Опять же, это не то, что я серьезно предлагаю, но это альтернатива, если вы действительно хотите и хотите.