- Убедитесь, что у сотрудников нет легко распознающихся посторонними логинов. Забудьте про iivanov или vpupkin и другие рекомендации новомодных веяний. Это может позволить сотрудникам чувствовать себя людьми, а не человеческими ресурсами вашей респектабельной компании! Учетные записи в Active Directory должны быть серийными номерами согласно «grid location». Убедитесь, что логины соответствуют расположению — номер здания, этаж, рабочее место. И вообще следуйте четким и удобным правилам именования, принятых в тюрьмах/концентрационных лагерях – ведь там это отлично работает!
- Создайте длинный, скрупулезный и сложный процесс QA, который занимает примерно 5 часов рабочего времени, чтобы пройти все тесты, даже если ошибки не обнаруживаются. Требуйте проверку кода как минимум в трех различных энвайрнментах, прежде чем он будет отправлен на мерж в продакшн ветку. На всякий случай, если работник вдруг начнет чувствовать, что этот процесс действительно полезен и необходим, покажите ему, что продакшен сервер настроен совершенно по-другому. И вообще ни один из тестовых серверов ему не соответствует.
- Кстати, о QA. Не утруждайте себя проверкой 3rd-party кода. Даже если этот код используется для обработки более важных бизнес-данных, чем основной код приложения. В то время как ваши сотрудники тратят время на проверку всех 30-ти пунктов касающихся стиля и качества основного кода, спокойно добавляйте сторонние библиотеки и плагины, которые выполняют критические манипуляции с данными без транзакций или корректного использования рекомендаций UPDLOCK.
Помните: смысл существования QA — это не качество ПО. Основной смысл их существования — чтобы было на кого свалить все шишки, если что-то пойдет не так. - В качестве повышения концентрации исключительно на работе, обеспечьте группе ваших сотрудников бесцветный, безликий кубический опен-спейс. А второй группе, которая выполняет практически идентичные задачи, устройте современные стоячие столы, огромные пустые пространства и окна с прекрасным видом. Удостоверьтесь, что сотрудники первой кубофермы регулярно посещают сотрудников второй группы. Но не предоставляйте никакого комфорта для этих существ — даже бесплатный кофе! Если ваши работники принесут свой кофе, объясните, что это нарушает правила. Никакого кофе и пончиков на ранее утреннее собрание! И неважно, что вторая группа появляется в офисе только к обеду.
- Ни при каких обстоятельствах разработчики приложения не должны разговаривать с администраторами баз данных или иметь доступ к управлению базами, словно они настоящие люди. Все сообщения должны проходить через тикеты в багтрекере. Если тикет заполнен неправильно — ни администратор, ни менеджер не должен иметь возможность исправить его самостоятельно или связаться с тем, кто его создал — они должны просто удалить/закрыть тикет с пометкой «ошибка оформления », чтобы разработчик заполнил правильный тикет с нуля. И даже если это приведет к нарушению дедлайнов — это не имеет никакого значения. Нет ничего важнее, чем правильно оформленные тикеты!
- Раз уж мы заговорили об этом, используйте самый надежный (проверенный десятками лет работы), пусть и громоздкий Desk Manager, который вы найдете. Не важно, что система старая, загроможденная и вообще фундаментально негодится для agile разработки. Во всех полях следует использовать проверенный годами plain text, не допуская создания таблиц или кликабельных элементов. Если сотрудник думает, что можно просто взять и отправить другому сотруднику ссылку на тикет, это значит что он глуп должен быть за это наказан! Естественно, браузер на всех рабочих машинах должен быть залочен на Internet Explorer версии 8.
- И вообще, права на всех рабочих компьютерах должны быть зарезаны самыми надежными и бездушными способами. Групповая политика должна гарантировать, что бесполезные вещи, такие как история браузера или история чатов Office Communicator — всегда будут отключены. Фон рабочего стола должен быть заблокирован от изменения и установлен на логотип компании очень высокого разрешения (возможно это будет единственный яркий и привлекающий элемент всего рабочего места), без возможности его отключить даже для удаленного подключения. Групповая политика должна запрещать пользователю устанавливать любое ПО, и считать его небезопасным. И даже служба IT, не должна иметь возможности устанавливать разрешенное ПО из строго определенного списка, пока не выйдет как минимум три новых версии этого продукта, чтобы считать его достаточно проверенным в деле.
P.S. Практически каждый пункт в том или ином виде был замечен в реальных компаниях. Правда иначе не было бы так
Комментарии (125)
Hellsy22
27.03.2018 03:32Мнемонические логины — это не новомодные веяния, а древность, которую, впрочем, тоже можно бездушно формализовать для творческого унижения сотрудников.
saboteur_kiev Автор
27.03.2018 13:14Ну я могу возразить, что grid location — гораздо более древность, чем мнемонические логины.
Кроме того, знаю пару компаний, где мнемонические логины создаются по настолько дурацким правилам, что просто капец.
Также напомню достаточно известный опус про Дарью Пескову, который говорит, что строгое следование правилам не всегда есть гуд (у кого не открывается оригинал с pynet, попробуйте тут.
cyberly
27.03.2018 05:52ИМХО, эти советы «вредные», если штат компании состоит из адекватных разработчиков. А вот если там «набрали идиотов по объявлению» — то, возможно, методы вполне рабочие.
Idot
27.03.2018 07:18Бывают неадекватные админы, которым плевать разработчик ты или юзер, и они режут права всем.
mammuthus
27.03.2018 09:15Разработчикам нужно давать неограниченные права только на основании того, что они разработчики?
mayorovp
27.03.2018 09:25Как отлаживать процесс установки и запуска службы без прав локального администратора?
Тут одно из трех. Или неограниченные права. Или виртуалка с неограниченными правами. Или готовность предоставить первые два варианта в тот момент, когда возникнет такая потребность.nApoBo3
27.03.2018 16:21-1Тут одно из трех четырех и т.д., отлаживать службу можно и без админа или у вас служба только от админа работает? Разрабатывают службы далеко не все разработчики. А установка службы вообще не вопрос разработчика, это вопрос эксплуатации.
mayorovp
27.03.2018 16:37Служба в винде обычно работает от системной учетной записи. Можно, конечно, запустить ее от имени любого пользователя — но что делать если некоторый баг выплывает только при работе от системной учетки?
Что же до установки службы, то написание инсталятора — вполне себе ответственность разработчика.saboteur_kiev Автор
27.03.2018 16:42Тестировать установку на своей машине — это практически ни о чем. Установка новой службы это копеечное дело, поэтому что там на своей машине отлаживать — непонятно. Другое дело отлаживать на специально созданных виртуалках, на которых можно создать разное окружение, разные версии ОС, проверить конфликты в случае установки по чистой, переустановки, апгрейду и так далее.
Но локальная машина тут совсем не причем.
Кстати, инсталлятор — можно не писать, а взять готовое решение.x67
27.03.2018 21:25, слава богу, я не разработчик под виндой. Я вообще не разработчик, но не могу представить рабочий процесс без sudo. И даже в винде на виртуалке, где из кода только редкие скрипты на vba, представить работу бе полных прав очень сложно. Или рабочий процесс должен быть жутко формализован и составлять одну рутину или это мазохизм.
saboteur_kiev Автор
27.03.2018 22:40А я совершенно не понимаю, зачем нужно sudo при разработке приложений, причем неважно под какой операционкой.
У вас java или tomcat от имени пользователя не запускается?Nalivai
27.03.2018 23:26От проекта зависит. В случае экспериментальных экспериментов постоянно нужно потрогать какие-нибудь либы, попробовать какие-нибудь тулзы и вообще развлекаться.
Или вот например, я вчера узнал про meld, тут-же его поставил себе и перестал мерджить гиткракеном, и жизнь моя улучшилась. Разве ж мог я себе такое позволить без sudo
rPman
28.03.2018 07:07К сожалению, разработка тесно связана с установкой необходимых библиотек, фреймворков и сред разработки.
На windows очень часто для этого требуются права администратора, в очень редких случаях можно это обойти, но усилий будет затрачено на порядок больше.mayorovp
28.03.2018 09:52На самом деле как раз на виндах с установкой библиотек все очень хорошо: большинство библиотек и фреймворков есть в nuget, а те которых там нет — можно положить в корпоративный репозиторий.
А вот как разрабатывать системное ПО без прав рута на линуксе я даже не представляю, там же все библиотеки принято ставить в /usr/lib и /usr/include…saboteur_kiev Автор
28.03.2018 13:22Но ведь системным программированием занимается наверное менее 10% всех программистов в мире. А то и менее 1%.
mayorovp
29.03.2018 06:41Я неточно выразился. Не системное ПО, а ПО на Си или С++.
saboteur_kiev Автор
29.03.2018 12:14И что? Для чего обычному ПО, написанному на Си или С++ нужны права админа?
Например очень много игр написано на С++.
Но если какая-то игрушка начнет требовать права администратора при установке — я очень огорчусь.
Может быть браузер без админских прав не запустится (чтобы было проще майнерам попадать в комп)? Или архиватор?
IMHO админ права нужны исключительно системному ПО, за крайне редким (и аргументативным) исключением.Neikist
29.03.2018 12:53Вообще процесс разработки ПО и процесс его использования — немного разные вещи. Часто нужно например переменные окружения поменять, установить новый инструмент или что то подобное.
nApoBo3
27.03.2018 21:02-1Запускать службу в винде от системной учетной записи не рекомендуется.
На своей практике очень много раз убеждался, огромная часть разработчиков не знает основ информационной безопасности, не знает бест практикс и очень равнодушно к этому относиться. От сюда и плодятся франкенштейны типа софта работающего только под административной учетной записью.
Вопрос прав разработчиков, это не вопрос админов, это общий вопрос эксплуатации. И не следует выделять разработчиков в какой-то мифический класс сотрудников которым без административной учетки ну просто вообще никак. В идеале, в организации вообще не должно быть сотрудников которые работают под административными учетками, в том чисел админов.
Если говорить конкретно про разработчиков, то при наличии у них админских прав системы превращается в не обслуживаемый зоопарк. Так, что тут два выхода, или им таких прав не давать или систему обслуживать за пределами досягаемости их прав. Например выдать им всем личные ноутбуки и по умолчанию считать их не доверенной средой. А ноуты свои они пусть обслуживают самим( единственная роль админов, если надо снести и залить нулевую готовую среду ). Во многих компаниях именно к такой схеме и приходят.mayorovp
27.03.2018 21:15По умолчанию как бы все службы от системных учеток запускаются. Если что, под системной учеткой я понимаю не SYSTEM, а любую не являющуюся пользовательской.
nikolayv81
27.03.2018 21:57Службы не рекомендуется запускать из под пользовательской учкюётки, со стороны пользователя может запускаться обёртка для интерактивного общения с пользователем. Служба же должна работать в т.ч. и на серверной машине, если есть необходи
nikolayv81
27.03.2018 22:03необходимость. При этом в win службы запускаются с разными наборами прав в зависимости от того куда им нужен доступ.
p.s. редактирования в мобильной версии нет :(
nApoBo3
29.03.2018 15:37Для служб не входящих в состав ОС рекомендуется создавать отдельные учетные записи наделенный строго необходимым кол-во привилегий. В частности для это есть такая штука к MSA.
Neikist
27.03.2018 23:26А теперь представьте ситуацию что продажники и консультанты права имеют админские (и ровно те же доступы в сети), а программисты нет. Как вам такая ситуация? Можете рациональное объяснение придумать. Даже чертовы переменные окружения не поменяешь…
nApoBo3
29.03.2018 15:42Вы предлагаете заняться анализом политики безопасности мифической компании или придумать гипотетический сценарий в котором такая ситуация нормальна?
Кол-во пользователей имеющих админские права должно быть минимизировано. Если у определенных пользователей есть админские права это может означать две вещи, в организации бардак с безопасностью или это осознанное необходимое решение, можете самостоятельно выбрать подходящее по вкусу.
Большинству разработчиков или никогда или очень редко необходимо менять переменные окружения. Учитывая, что эти переменные должны отражать продакшен среды их вполне можно установить общей политикой.
Sonikelf
29.03.2018 19:42Если мы говорим про идеалы, то в идеале в организацию набираются люди, способные работать в системе под админом без вреда для системы, либо набираются админы, способные реализовать это так и таким образом, что человек под соответствующей учеткой желает то, что ему нужно по работе, но при этом не может внятно навредить даже по не знанию. Вопрос не к разработчикам, да.
vesper-bot
27.03.2018 09:31Разве кто-то сказал «неограниченные»?
mammuthus
27.03.2018 10:20Если их не обрезать (о чем говорил Idot), то они по определению будут неограниченными.
Neikist
27.03.2018 11:37-1Угу, а потом чтобы службу перезапустить комп перезагружать приходится, или время нельзя поменять, или переменные окружения… В итоге пришел к простому решению: купил свой ноутбук, и то что мне требуется делаю на нем, как часть рабочих вещей, так и всякое разное что мне интересно, в обеденный перерыв например.
djiggalag
27.03.2018 13:04Для таких как ты админы блокируют использование USB на уровне БИОСа, привод для дисков намертво отключают, как и всякий доступ в облако, даже мало известного=)
saboteur_kiev Автор
27.03.2018 13:05За такое, в некоторых компаниях могут уволить с занесением в черный список, а то и с вызовом юристов на дом =)
Neikist
27.03.2018 14:03На всякий случай добавлю, есть консультанты, которые работают в той же сетке, в той же комнате, и имеют те же доступы, так вот, они права локального админа имеют.
MaxEL_UA
28.03.2018 13:25Для перезапуска службы не нужны права админа. Можно предоставить права управлять определенной службой.
gwathedhel
28.03.2018 13:25А время то вам менять зачем понадобилось? За такое в доменной среде по рукам бьют и больно.
Namelles_One
28.03.2018 13:52Мне это надо было целых 1.5 раза сделать — эмулировал ситуацию, когда криптографический сертификат становится невалидным.
gwathedhel
28.03.2018 15:10Обычно для этого просят админов о виртуалке в закрытой среде.
Ибо Domain, Kerberos, NTP
Neikist
28.03.2018 16:16Нужно было проверить и поправить работу приложения когда сервер и один пользователь в одном часовом поясе, а другой пользователь в другом.
saboteur_kiev Автор
27.03.2018 13:16Более чем в половине компаний с опенспейсом, фон рабочего стола глобальными политиками устанавливается в разные логотипы, придуманные в HR. Что и зачем они рекламируют, и почему эти новости нельзя сообщить нормально через корпоративную почту — непонятно.
Особенно радует, если фоновая картинка (уменьшенная до текущего разрешения) в оригинале является high-резолюшен фото для полиграфии, которая ставится на слабые рабочие станции.nikolayv81
27.03.2018 22:13Особый вид — заставка 7 минут (без прпва сменить ни заставку ни время, интересно почему не 3 минуты? может пару костей бросали), когда у тебя не один комп. и монитор на столе это немного достаёт.
maksim_ms
27.03.2018 22:31+1Еще бесить когда домашняя страница браузера закреплена политиками и открывает intranet компании и её нельзя поменять.
saboteur_kiev Автор
27.03.2018 22:40Вот это кстати да, забыл но такое тоже встречалось. Жутко бесило.
Busla
27.03.2018 23:22Достаточно навыков опытного пользователя, чтобы перекрыть домашнюю страницу. Зато неквалифицированные пользователи всегда в курсе куда идти за справкой, поддержкой, объявлениями и прочим.
saboteur_kiev Автор
28.03.2018 01:44недостаточно, если у вас IE и права зарезаны доменными политиками.
maksim_ms
28.03.2018 09:29Я сделал скрипт который меняет настройки в реестре домашней страницы, добавил в autorun. В chrome такой проблемы нет.
Но все равно большинство людей с этим живут, тратят время чтобы перейти на нужную страницу — это ужаснее чем рабочий стол, с нескучным логотипом).
Борюсь с этим в нашей компании.Busla
28.03.2018 16:07Даже интересно стало, что это может быть за единственная на весь интернет нужная страница, которая в качестве домашней сразу бы сэкономила тонну времени? — просто на неё ярлык не перетянуть на рабочий стол, чтобы его тыкать, а не ярлык ie?
halted
27.03.2018 09:29про первый пункт вообще пофигу, главное, чтобы не приходилось вводить с несколькики попытками
saboteur_kiev Автор
27.03.2018 13:16не забывайте, что логин часто привязывается к емайлу =)
EmmGold
27.03.2018 20:37цифровой йемеил гораздо проще по телефону объяснить
velovich
27.03.2018 11:50А мне симпатично рабочее место на фотке
saboteur_kiev Автор
27.03.2018 13:06А я даже знаю название компании, в которой такое рабочее место (точнее много таких рабочих мест) =)
Правда лет 7 назад она была куплена другой компанией, и возможно там все изменилось.
dimkss
27.03.2018 13:19А теперь представьте что этот кубик стоит на проходе к курилке/кухне, и за вашей спиной постоянно ходят сотрудники/клиенты/менеджеры.
tandzan
27.03.2018 15:26Мне не повезло однажды попасть в такую контору, посадили рядом с холодильником, из которого воняло как из скотомогильника. У кого-то за спиной был общий электрочайник, у кого-то кофемашина. Перегородок, кстати, не было, они полагались только молодым незамужним девушкам.
gohan
27.03.2018 21:25+1Перегородок, кстати, не было, они полагались только молодым незамужним девушкам.
То есть, сотрудница вышла замуж, а на следующий день у неё на работе торжественная церемония по сносу перегородок?Estee
28.03.2018 14:41Или она перестала попадать в категорию «молодых» и тогда суровые дядечки в черных комбезах сносят те же перегородки под участливый шопот толпы
amarao
27.03.2018 14:01Создайте длинный, скрупулезный и сложный процесс QA, который занимает примерно 5 часов рабочего времени, чтобы пройти все тесты, даже если ошибки не обнаруживаются. Требуйте проверку кода как минимум в трех различных энвайрнментах, прежде чем он будет отправлен на мерж в продакшн ветку.
Небольшой перегиб, но в целом правильно. Пять часов работы роботов — это не так уж и много. А некоторые продукты могут требовать многомесячного тестирования человеком — и в этом нет ничего странного.
Если вы предложите NASA запускать спутники после «длинный, скрупулезный и сложный процесс QA, который занимает примерно 5 часов рабочего времени», то на вас посмотрят как на идиота.saboteur_kiev Автор
27.03.2018 14:03А затем, после длинного, скрупулезного и сложного процесса QA, запустить спутник в продакшен на другом енвайрменте (с другого космодрома), и получить то, что мы получили? =)
ozonar
28.03.2018 08:18Ну если рассуждать логически, ракету вообще нельзя протестировать в том окружении, в котором она будет находится в момент полёта =)
vconst
28.03.2018 08:54Можно. Тут были статьи про огромные вакуумные камеры.
impetus
28.03.2018 22:48как быть с невесомостью или наоборот — длительными ускорениями под неск «Же»?
Ещё скоростной напор в неск. М тоже очень непросто.
Ну и — в вакуумных камерах работу однокомпонентных гидразиновых движков вряд ли дадут проверить (а с ними куча проблем вообще-то — то примёрзнет что, то отравится), пироболтов всяких
mayorovp
27.03.2018 14:11Но вряд ли многомесячное тестирование требуется перед каждым слиянием ветки…
amarao
27.03.2018 14:28Если эта ветка — продакшен, то может требоваться. Ближайший опенсорс аналог — gerrit/zuul у openstack'а. Коммит в master принимается после:
a) пройдут все тесты (юнит и интеграционные)
б) того как его отревьюют.
в) один из PTL (team leader) одобрит
г) после этого коммит становится в очередь, его ещё раз гоняют по интеграционным тестам (часы!), и только после этого робот мержит в мастер.
Среднее минимальное время на принятие merge request'а — около 48 часов. Это если никаких претензий к коммиту не было.
И это — одна из самых офигенных схем, которую я видел.
Альтернативно — посмотрите, сколько времени уйдёт у вас до принятия merge'а в master у вот этого репозитория: git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git.
Если за пару месяцев управитесь — можете считать себя героем и просить большие деньги.mayorovp
27.03.2018 14:36В «вот этом репозитории» в день бывает и по 200 коммитов. Очевидно, что не каждый коммит тестируется независимо по 2 месяца.
amarao
27.03.2018 14:37Не коммит, а merge-request. Некоторые проходят быстро — некоторые очень долго. Некоторые вообще несколько лет в linux-next живут.
В любом случае, вероятность заслать что-то вне merge window, если это не багфикс, нулевая.mayorovp
27.03.2018 14:48Так негодование переусложненным процессом именно в случаях багфиксов и возникает. Когда на 30 минут отладки приходится 5 минут исправления, 5 минут оформления, 2 месяца тестирования и год бюрократии…
amarao
27.03.2018 16:33… Пока не выясняется, что 5 минут багфикса и теста не учитывает сценария, который жизненно важен для компании.
Тут вопрос же не в том, через какое время в продакшен выкачены изменения, а как быстро их может увидеть программист. А для этого есть ответ — staging.mayorovp
27.03.2018 16:42Тут вопрос же не в том, через какое время в продакшен выкачены изменения, а как быстро их может увидеть программист. А для этого есть ответ — staging.
В том-то и проблема, что в подходе "слияние только после тестирования!" изменения по два месяца не могут попасть даже на staging.
amarao
27.03.2018 16:43А что запрещает программисту сделать merge на локальной машине? Сервер не примет пуш, но локально-то развлекаться можно сколько угодно. Так же как и staging поднять может любой. Не?
saboteur_kiev Автор
27.03.2018 14:45Если эта ветка — продакшен, то может требоваться. Ближайший опенсорс аналог — gerrit/zuul у openstack'а. Коммит в master принимается после:
Простите, но это практически в любой современной CI тулзе (bitbucket/stash, gerrit/zuul) работает — то есть возможность интегрироваться с билд сервером, чтобы разрешаьт мерж только после успешного билда (который может содержать как сборку продукта, так и тестирование, включая различные анализаторы (pvpstudio). Ну и плюс ревью от указанных ревьюверов/групп.
Настроить «в очередь» — можно банально сделать две ветки — pre-master и master, которые ничем не отличаются. Соответственно все делают пулл реквесты в pre-master, на что срабатывает триггер, который запускает дополнительное тестирование, и затем уже автоматом мержит в мастер от имени технического пользователя.
Но мы слишком серьезно увлеклись… Это перевод все-таки юморной заметки.
Ну а в каждой шутке всего лишь доля шутки…
Лучше обсудим залоченный фон в корпоративных рабочих машинах?Marsikus
27.03.2018 15:01+1Лучше обсудим залоченный фон в корпоративных рабочих машинах?
И жестко прибитый таймаут на lock screen в 60 секунд.
amarao
27.03.2018 16:32Я к тому, что стонания офисного плантктона не всегда необоснованы.
Что же касается залоченного фона — а у кого это проблема? Я вот бэкграунд рабочего стола вижу только после ребутов после апдейтов. Дальше у меня на экране есть что-то кроме, картинки. Окна там всякие, приложения. suspend/resume и у машины аптайм с апдейта до апдейта.saboteur_kiev Автор
27.03.2018 16:45Работал с виртуальными машинами, когда локальная машина позволяет запустить только клиент для удаленной машины, и удаленная и является основной рабочей.
При этом неотключаемая фоновая картинка доставляет много удовольствия в процессе логина, где в 2018 году в локалке ты видишь картинку, подгружающуюся как гифка файлэхе ru.pretty.girls по модему.amarao
27.03.2018 17:20У rdp есть опции «не показывать картинку». По-крайней мере такие опции были в 2009, когда я заканчивал с виндами работать.
saboteur_kiev Автор
27.03.2018 17:56не рдп, ну и опции могут быть заблокированы политиками именно вследствие решения со стороны HR, которые хотят активно участвовать в социальной жизни «этих асоциальных, бедных айтишников» и показать им что жизнь прекрасна, весела и полна разных веселых ивентов всем проектом.
amarao
27.03.2018 18:35А как HR может выставить групповые политики админам? Разве не наоборот?
saboteur_kiev Автор
27.03.2018 18:47Ну это не технический вопрос.
HR не только занимается наймом, но различной активностью связанной внутренней корпоративной политикой.
Проактивная позиция в плане психологической поддержки сотрудников часто выливается в странные ивенты, которые могут быть интересны школьникам/студентам…
Решили сделать красивые картинки, отдали задачу админам, внедрили. Админы люди подневольные менеджменту…
jrthwk
28.03.2018 08:35+1Что вы понимаете в извращенных удовольствиях, если не доводилось работать на такой вот удаленной машине, где броузер политиками настроен обязательно показывать при запуске корпоративный видеоролик…
nidalee
28.03.2018 19:26Все такие важные — куда не глянь, разрабатывают вещи не менее серьезные, чем ПО космодромов и ОС…
amarao
29.03.2018 00:08Ну, вообще говоря, ОС — всего лишь кирпичик в современном тулстеке, и бага в userspace библиотеке может оказаться такой же болезненной, как и баг в ядре.
Но на самом деле тут же речь о другом: автоматизация workflow. Тот же опенстек пишется людьми с разными компетенциями и разной квалификацией. Многие из них друг друга в глаза не видели, но им надо работать вместе над очень сложным проектом с большим количеством строк кода и сценариев применения. Один разработчик поправил cloud-init, а другому разработчику в ironic это сломало провиженинг в с metadata-server для бареметалл серверов. Чтобы этого не происходило нужны тесты. Автоматические. И система защиты от дурака, который не позволит случайно сломать workflow.
saboteur_kiev Автор
29.03.2018 12:15Ну да, если заглючит браузер во время оплаты через интернет, или видеоплеер будет глючить при просмотре фильмов — ничего же страшного, все будут продолжать пользоваться этим браузером и этим плеером?
nidalee
29.03.2018 12:34Да, опыт показывает, что именно так. Баги не исправляются годами.
Ежики кололись, но продолжали жрать кактус.
Гики может и озаботятся сменой плеера, обычные же юзеры побегут на трекеры строчить гневные отзывы о том, что у них «фильм не играет».
vanxant
27.03.2018 15:02Поставьте опечатку: ie6
saboteur_kiev Автор
27.03.2018 15:34Вы очень злой…
P.S. А сегодня еще можно официально получить лицензию и поддержку на винду с IE6?
unwrecker
27.03.2018 22:56А как же OpenGL скринсейвер? Он должен обязательно стоять на всех сессиях терминального сервера, без возможности отключения и с таймаутом в минуту (тоже взято из реальной практики)
blackmak
28.03.2018 00:37Оказывается, мне везёт. Из всей описанной здесь боли сталкивался только с креативами HR в качестве фона рабочего стола, задаваемого политикой домена.
robert_ayrapetyan
28.03.2018 07:29Забыли сброс пароля на вход, раз в три месяца минимум, и чтоб не из предыдущих 10! Минимум 15 символов. И что б если раз ошибся при вводе — все залочить. И почта что б не работала при этом, только звонок в ИТ отдел чтоб разлочили. Это не вредный совет, это реальный кейс с прошлого места работы
cyberly
28.03.2018 07:49Ну, насколько я знаю, это все входит в требования для сертификации информационной системы на соответствие определенному классу защиты от несанкционированного доступа.
Нормальные требования, если утечка информации критична.mayorovp
28.03.2018 10:03Нормальные требования — это лочить после трех неверных вводов пароля. А лочить при любой опечатке — это маразм, а не класс защиты.
VIVIM
28.03.2018 10:09Ага. Только вот такие правила довольно сильно снижают уровень безопасности, потому, что при таких правилах минимум 70% сотрудников будут писать пароли на бумажке приклееной к монитору. А сами пароли будут максимально просты, в пределах установленных правил конечно же.
General_Failure
28.03.2018 08:05только звонок в ИТ отдел
Только поход! С объяснением, как так умудрился забыть пароль!
Это, если что, не шутка — тоже реально попадалось на одном заводе.vconst
28.03.2018 08:57Пешком в айти? Хорошо бы… У нас парольная политика довольно мягкая, но забытый пароль к учётной записи, на которую завязана и почта, и доступ к серверам и все вообще, кроме прохода через турникет — можно поменять только через обращение к центральной техподдержке в головном европейском офисе.
DALwick
28.03.2018 13:24Можно еще и объяснительную написать, раз уж такая тема пошла.
Вот это уже шутка, если что.
saboteur_kiev Автор
28.03.2018 13:24Это нормально, за исключением:
И что б если раз ошибся при вводе — все залочить
Еще (славабогу) не встречал, чтобы лочили с первого раза.robert_ayrapetyan
28.03.2018 16:55+1Дело в том, что почтовые клиенты на телефоне и десктопе начинают ломиться со старым паролем (несколько раз пытаются), и уже там исчерпываются все попытки — акк гарантировано лочится (никогда точно не считал сколько, но точно не больше двух попыток).
Я пытался изобрести алгоритм, как правильно все сделать, казалось бы, вот надежный:
1. Выключить телефон и закрыть почтовый клиент на десктопе
2. Поменять пароль на новый
3. Включить телефон (вот тут сразу облом, иногда клиент начинает лезть сразу со старым паролем, на ios там все очень нетривиально, особенно когда корпоративные настройки всякие вручную прописаны)
4. При запуске почтового клиента на десктопе — аналогично, он сразу лезет проверять почту и акк лочится
Поэтому этот алгоритм не подходит. Единственное, что в итоге подошло:
1. Удалить почтовый клиент с телефона и никогда им не пользоваться больше (реально из-за этого снес почту с корп. телефона навсегда, я не смог синхронизировать сброс пароля почты на телефон и в учетной записи, он всегда сам как-то лез проверять со старым паролем, после 5-го звонка в тех. поддержку удалил).
2. Запустить почтовый клиент на дескптое, пойти в настройки сервера, выбрать «смена пароля» и оставить висеть это окно открытым
3. Сбросить пароль учетной записи
4. Вернутся в открытое окно на шаге 2 и ввести туда новый пароль.
5. Если повезло и нигде не ошибся — слава богу! Мы победили. Почта получается по новому протоколу.
6.… до тех пор пока не потребуется ОТПРАВКА письма, забыли на SMTP еще поменять нужно!!! бл*:??*%"№
7. Все лочится — звоните в тех поддержку (почта не работает, залогиниться в комп нельзя)
Я так подозреваю, что всего этого не существовало для обычных пользователей на винде, у них смена пароля в одном месте меняет его и в аутлуке и везде, но для пользователй других ОС, с thunderbird-ом и ios -мартфоном это был адский ад…
stgunholy
28.03.2018 13:24+2Добавьте плиз:
«Установку ПО проводить только с помощью заказа ПО в специально написаной программке которая не обновлялась со времени Win95. (Которую как-раз поддерживает отдел со стоячими раб. местами и бильшими окнами). После этого как минимум 3 менеджера должны согласиться с тем, что вам это ПО нужно для работы (Обсуждение ведется по всем правилам оформления в трекере из п.5)»BubaVV
28.03.2018 13:49Но в связи с новыми веяниями, менеджеры теперь подтверждают права через блокчейн
cross_join
28.03.2018 13:24-1Не утруждайте себя проверкой 3rd-party кода
Допустим, основная система — 1М строк кода, одна из сторонних библиотек — 4М строк.
Автор предлагает проверять эту библиотеку отдельно?
Да, production server по-русски называется рабочий сервер или сервер эксплуатации.
stgunholy
28.03.2018 14:44Естественно своя собственная реализация. И проверка всей цепочки занимает неделю минимум…
PMVyatkin
28.03.2018 17:33Были у нас в компании правила именования учетных записей — «первая_буква_именифамилия» — т.е. iivanov, apetrov, vsidorov, etc. Ну и почта соответственно была vsidorov@companyname.ru
И вот пришел к нам как то молодой человек, по имени Дима, с простой фамилией Ермаков… К сожалению, он над этим не задумывался, а до админов дошло не сразу — в итоге многие клиенты получали почту от его учетки, пока кто то не предложил переименовать…Estee
28.03.2018 17:48В моей предыдущей фирме это называли «феноменом двух Лен». В честь Елены Банько и Лены Головач.
jrthwk
29.03.2018 11:43Неисчерпаемая тема, да.
К нам однажды получив логин из имени+инициалы, дама по имени Алсу пришла жаловаться — «почему вы меня сукой назвали»? Инициалы были К.А.…
Ну и с Анной, которой не повезло иметь инициалы А.Л. тоже несколько неловко получилось…saboteur_kiev Автор
29.03.2018 12:16Вы не знаете, какие сочетания встречаются у индусов просто каждый день =)
Хотя там и без сочетаний бывают случаи…
pyrk2142
Этот пункт встречал в довольно адекватных известных компаниях: свой код проверяется со всем усердием, а код сторонних разработчиков иногда даже не смотрят, хотя он работает с теми же данными и (иногда) на тех же серверах. Объяснений этого, кроме дикого разгильдяйства или того, что ответственность за уязвимости переложена на другую компанию, я пока ее нашёл.