Комментарии 55
Однако разработчик, не имеющий достаточного опыта, не сделает этого. Он пишет код для одиночного компьютера.Тут тёплое с мягким спутали. Он пишет такой код не потому, что он не умеет в админство, а потому что не умеет в масштабирование.
Правильным способом исправить это является использование распределённой файловой системы, которая доступна для всех веб-серверов.CDN.
Сейчас довольно модное словечко есть для всего этого — DevOps. И код напишет, и задиплоит, и на дуде игрец.
P.S. это, к слову, работает в обе стороны. Если админ не знаком со спецификой софта, то тоже проблемы будут, правда, другого уровня.
Разрабатывать сайты на маке с последним Intel Core и Retina-дисплеем для пользователей с IE8 и Pentium 4 (гос.учреждения и некоторый бизнес) или AltLinux 5 (с Firefox 4.0) и Core 2 Duo (школы)
SRE (Site reliability engineering) — давно существует, и крупные компании это активно практикуют. Это админы которые разрабатывают всю инфраструктуру и софт для нее, а также работают с программистами как правильно под всё это писать.
Не нужен опыт, нужны знания о предметной среде.
Подобное этому заявление: каждый разоаботчик космического корабля должен побывать в космосе.
Для развивающегося программиста "побывать в сисадминах" обойдётся слишком дорого. Но есть выход! Говорят, люди научились накапливать знантя, и — не говорите никому — тиражировать их благодаря письменности!
Вывод: программист должен уметь читать и понимать написанное. Не понял — научись спрашивать. Серебряная пуля найдена!
В вебе очень важно понимать как между собой взаимодействуют сервера, в разработке драйверов очень важно понимать как работает железо. Но не наоборот.
В разработке под мобильные устройства что, не относящееся к коду важно? Я не спорю, что необходимо понимание того, почему обновление экрана сто раз в секунду на iPhone плохо да и принцип отправки http запроса тоже требуется, но зачем вам iOS разработчик с навыком настройки апача или сборки системника?
Такой программист должно быть тощий:
Программеры — они толстые. Потому что они сидят. А админы — они тощие. Потому что бегают. Впрочем, бывают тощие программеры. Но не надо думать, что это исключение из правил — это переученные админы. Также встречаются и толстые админы. Это обленившиеся программеры.
И ещё системным аналитиком, т.к. иначе не сможет анализировать потребности бизнеса и выявлять недостатки в полученном им таске.
Потребности бизнеса говорите? Но он же не сможет решить бизнес задачу, не понимая как работает бизнес. Так что ещё много кем надо поработать разработчику.
Жду статью о том, сколько будет стоить компании такой разработчик и где он взял столько лишнего времени, что бы на это тратить.
Разработчику нужно думать головой. Этим, в большинстве случаев, решаются описанные в статье (и многие другие) проблемы.
Вывод один: чем человек больше знает, тем он дороже стоит (если он при этом умеет себя продать).
Т.е. он не может поменять стэк технологий, потому что привязан к 1С. Он не может переметнуться в другую сферу, когда бухгалтерия ему надоест.
Да банально страну дислокации сменить не может, потому что условный 1C нафиг не нужен в условных штатах.
Разбирается и в бухгалтерии, и в бизнес процессах — скорее следствие того, что N времени он работает в этой сфере. А не следствие того, что он до этого бухгалтером работал.
При этом 2к/час — вполне средняя цифра для фриланс разработчика с хорошим стажем. Ничего космического.
Ваш вывод тоже правилен только частично. Всем пофиг, сколько вы знаете. Работодателя интересует только то, как вы решаете его проблемы. Некоторые знания могут сильно помогать вам решать их лучше (например, банальное понимание потребностей бизнеса или платформы). Некоторые же — бесполезны и не несут добавочной стоимости.
Да что блин с вами люди не так?! Что за трешню опять запостили? Зачем здесь это дерьмо, очевидное всем, кто имеет хотябы полгода стажа в 2016 году? Хватит постить на хабр такую херню — у вас для нее есть всякие гиктаймсы — вот туда и сливайте этот бред!!!
Поэтому ни Azure Pack, ни Plesk, ни cPanel, ни другие платные и бесплатные панели управления хостингом, в моём случае, биллинга, как такогового не имеют — слишком большая специфика у каждой компании — хостинг-оператора, внутри.
Снаружи — да, хостинг сайтов, приложений, виртуальных или выделенных серверов, домены там — у всех хостеров плюс минус одинаковы. А внутри — в реалиях СНГ общее между ними только 1с на выходе документов.
Думаю все дело в естественно отборе. Опытный админ с хорошим резюме это один из сотни выживших, поскольку админов наказывают по сути за каждый прокол и их зарпалата напрямую связана со стабильностью и качеством их работы. Программистов, во-первых, на порядок больше, во-вторых, они обычно непосредственно ни за что не отвечают, для этого есть прослойка менеджеров и тимлидов, а в-третьих, вмененые им ключевые показатели имеют очень слабое отношение к эксплуатационным качеством, за это обычно отвечает опять таки, кто-то другой.
И тут природа придумала специализацию, человек ее имплементировал на экономические отношения. Это само по себе хорошо, но породило проблемы при переходе границ специализации. Эти издержки компенсируют крос специалисты или знающие оба предмета поверхностно( но способные быстро вникнуть в проблему ) или знающие оба предмета глубоко, но занесенные в красную книгу и очень дорогие, и плюс целая прослойка менеджмента задача которой координация действий.
не делайте блокираторов запуска приложения в виде создания файла на диске, когда ваше приложение крешнется на терминальном сервере админ будет вынужден вручную удалять этот файл не останавливая сервера
?
Там можно хранить id процесса, например. И удалять из программы если уж нужно, минуя админов.
Соответственно если приложение запускается повторно, то эксклюзивный режим не даст открыть файл и по этой ошибке выходим, если приложение крашнулось — можем открыть не смотря на то, что файл существует.
Типичная ошибка — считать что если файл есть то приложение не крашнулось, продвинутая ошибка — считать что удаление прописано в том месте которое вызовется даже при краше.
Я примерно это и имел ввиду. У автора было просто "не используйте lock-файлы" без уточнений.
И, между прочим, это каноничный пример того, как опыт создания скриптов из костылей, столь характерный для администрирования маленьких предприятий, в этом конкретном случае пошел разработчику во вред.
Ваше «решение» невозможно запустить на бездисковых системах и на системах с read-only носителями. Также потребуется решить проблемы с правами доступа приложения/пользователя на запись. Относительный путь или абсолютный — еще одна проблема. Как и API — не всякий поддерживает UNC-пути, например.
Для бездисковых систем /var/run монтируется на tmpfs и всё работает.
Для винды естественным решением для этого случая является именованный канал, но этот именованный канал всё равно будет лежать в корневой файловой системе. Для вас видимо сюрприз, что в M$ есть корневая ФС, поэтому начните своё знакомство например отсюда https://en.wikipedia.org/wiki/Object_Manager_(Windows).
Принципиальная проблема не в том, что ваше решение не будет работать, а в том, что для решения используются спроектированные для иных целей вещи.
В случае windows куда более логично использовать мьютекс, который по определению специально для таких целей и создан, а не городить костыли, считая любой объект в системе
А linux, на сколько я знаю, для решения таких задач предполагает использование семафора на разделяемой памяти. Тоже не требующего такой сильной зависимости как разрешение на запись на диск.
В линуксе семафор на разделяемой памяти уместен для IPC, для синглрана это жирно т.к. тебе всё равно как -то надо передать в другой процесс идентификатор разделённой области памяти, т.е. вместо того, чтобы просто проверить права доступа к файлу будешь заниматься межпроцессным взаимодействием. И это не «сильная зависимость» — есть https://ru.wikipedia.org/wiki/FHS который определяет что это должно быть доступно любому процессу.
Если один процесс пытается получить информацию о другом (о том что он запущен), то это в любом случе IPC просто по-определению этого термина. Блокируя файл, ты все-равно делаешь IPC, но не напрямую, а через посредника. Критерии «жирности», кстати, раз уж ты их упомянул, тоже дело довольно второстепенное. Хотя я не могу взять в толк, почему писать в шареную память «жирно», а на диск — нормально?
ЗЫ: Ну и по-поводу существования FHS — это тоже не аргумент. Еще в системе TCP-стек должен быть. И что теперь — давай сокет открывать по этому поводу? как альтернативу lock-файлу?:
Никакие девопсы-шмевопсы не смогут понять почему вдруг процесс на жаве стал отъедать внезапно память и не отдавать, они не знают что такое логи, они не понимают что такое обращения на порт при котором плохо написанный софт выделяет память и обратно не отдает. Они тупо не найдут причину.
Никакой программист не сможет вам настроить HA-кластер, это просто не его дело. Его дело написать софт который будет работать.
Пора бы понять, что у тех кто сидит за компьютерами очень разные профессии и прекратить нести чушь.
В тоже время электрик должен знать, как работает выключатель и уметь его починить и знать, что под него дырку нужно штробировать 10 см, а не полметра.
Тоже пример так себе, но лучше.
Это просто разные профессии и люди занимаются разными вещами.
— Я программист и буду хранить терабайты в базе данных. Сеть тормозит? Обращайтесь к сисадмину.
— Я сисдадмин и выделю канал в 1 мб/с. Программа тормозит? Обращайтесь к программисту.
Я писал с телефона, да еще и за рулем. Не до правил русского языка.
У админа навыки программирования, или, скорее, навыки алгоритмизации, тоже должны быть. Скриптописание — это тоже такая себе разновидность программирования (хоть и дико простая, усложения вызваны, разве что, ограниченностью используемых средств). А без него нормальную работу построить тяжело.
Вот что действительно надо от админства программистам — это понимание, что:
— безопасность — это не что-то обстрактное где-то там. Отсюда, зачастую, проблем больше и они жирнее, чем от кривого дизайна ПО;
— понимание, что на серверной стороне оно должно работать без участия человека, или действия можно автоматизировать;
— хорошая документация предотвратит лишнее дерганье разраба админом. Админы, зачастую, сами находят решения проблем, если есть документация.
Скажем так. Админства в три-четыре года, или полтора-два года под руководством хорошего админа должно быть более чем достаточно, чтобы понять, как делать НЕ надо.
Ну или хорошего знакомого админа для консультаций, который готов уделить своё время.
понимание, что на серверной стороне оно должно работать без участия человека, или действия можно автоматизировать;
Это чтобы админов пинать, что задачи провижна и деплоя автоматизировали?
Скажем так. Админства в три-четыре года
Очень много. Не говоря о том, что это админство может быть очень слабо связано с задачами по разработке. Грубо говоря, админил сетку и телефонию, а занимаешься разработкой фронта к веб-приложениям.
Ну или хорошего знакомого админа для консультаций, который готов уделить своё время.
На нормальной работе должен быть такой знакомый, причём готов потому что это его прямые обязанности, потому что он прежде всего отвечает за безопасность сети. Если разработчик где-то открыл какой-то порт для отладки и забыл закрыть перед релизом на прод, а через него взломали, то виноват прежде всего админ, давший миру доступ к неизвестному порту.
Это чтобы админов пинать, что задачи провижна и деплоя автоматизировали?
Ну всё-таки давайте не передергивать. Лично у меня есть в парке приложение, которое для своей работы требует логона в систему. Пинать админа для того чтобы делал автологон на серверах?
Грубо говоря, админил сетку и телефонию
Но мы же говорим, наверно, всё-таки о сисадминстве или, в крайнем случае, крайне (мда, каламбур) приближённом к этому эникею. А сети и телефония — это уже несколько другая профессии. То, что, зачастую, админу сваливают это всё — это специфика небольших контор.
забыл закрыть перед релизом на прод, а через него взломали
Бесконтрольное хождение через периметр сети — это проблема сугубо админов и безопасников. К теме обсуждения отношение имеет опосредованное.
У разработчика программного обеспечения должен быть опыт сисадминства