Comments 55
Однако разработчик, не имеющий достаточного опыта, не сделает этого. Он пишет код для одиночного компьютера.Тут тёплое с мягким спутали. Он пишет такой код не потому, что он не умеет в админство, а потому что не умеет в масштабирование.
Правильным способом исправить это является использование распределённой файловой системы, которая доступна для всех веб-серверов.CDN.
Сейчас довольно модное словечко есть для всего этого — DevOps. И код напишет, и задиплоит, и на дуде игрец.
P.S. это, к слову, работает в обе стороны. Если админ не знаком со спецификой софта, то тоже проблемы будут, правда, другого уровня.
Поздравляю! Вы только что изобрели DevOps
Немного не так. DevOps несомненно обязан понимать в какой то мере код основных современных языков. И админить обязан уметь. А архитектуру проекта знать должен. И в безопасности профаном не быть. И методы тестирования понимать. Только это навыки, но не назначение DevOps-ов. Задача DevOps-ов — инструментально обеспечивать частый выпуск продукта, выстраивать процесс разработки, тестирования и деплоя. Чтобы всем было удобно работать и повышалось качество продукта. Естественно, при этом нет задачи перекрыть роли всех специалистов и отобрать у них работу.
Professor Beekums (автор оригинальной статьи) только что вышел из криокамеры, проведя в ней 10 лет и еще не успел узнать про docker?
Эти ваши контейнеры не решают и 5% проблем, которые возникают, когда разработчик не имеет представления о пльзователях его продукта и среде, в которой он будет работать (притом не о среднем пользователе, а о самом «неудобном»).
Разрабатывать сайты на маке с последним Intel Core и Retina-дисплеем для пользователей с IE8 и Pentium 4 (гос.учреждения и некоторый бизнес) или AltLinux 5 (с Firefox 4.0) и Core 2 Duo (школы)
Разрабатывать сайты на маке с последним Intel Core и Retina-дисплеем для пользователей с IE8 и Pentium 4 (гос.учреждения и некоторый бизнес) или AltLinux 5 (с Firefox 4.0) и Core 2 Duo (школы)
Докер решает проблему зависимостей, рантайма, деплоя, неба, но не решает проблемы промахов в проектировании продукта. Если проблема by design, то всё остальное — это просто лечение симптомов.
По сути докер — это инструмент, облегчающий работу админов. Если вы, как разработчик софта, пишите докер- и докер-композ файлы для своего софта, то вы выполняете работу админа.
Devops — это не человек, это практика — читаем википедию.
SRE (Site reliability engineering) — давно существует, и крупные компании это активно практикуют. Это админы которые разрабатывают всю инфраструктуру и софт для нее, а также работают с программистами как правильно под всё это писать.
SRE (Site reliability engineering) — давно существует, и крупные компании это активно практикуют. Это админы которые разрабатывают всю инфраструктуру и софт для нее, а также работают с программистами как правильно под всё это писать.
Не нужен опыт, нужны знания о предметной среде.
Подобное этому заявление: каждый разоаботчик космического корабля должен побывать в космосе.
Для развивающегося программиста "побывать в сисадминах" обойдётся слишком дорого. Но есть выход! Говорят, люди научились накапливать знантя, и — не говорите никому — тиражировать их благодаря письменности!
Вывод: программист должен уметь читать и понимать написанное. Не понял — научись спрашивать. Серебряная пуля найдена!
Мысль верная, но изложение хромает. Плюс не везде применимая.
В вебе очень важно понимать как между собой взаимодействуют сервера, в разработке драйверов очень важно понимать как работает железо. Но не наоборот.
В разработке под мобильные устройства что, не относящееся к коду важно? Я не спорю, что необходимо понимание того, почему обновление экрана сто раз в секунду на iPhone плохо да и принцип отправки http запроса тоже требуется, но зачем вам iOS разработчик с навыком настройки апача или сборки системника?
В вебе очень важно понимать как между собой взаимодействуют сервера, в разработке драйверов очень важно понимать как работает железо. Но не наоборот.
В разработке под мобильные устройства что, не относящееся к коду важно? Я не спорю, что необходимо понимание того, почему обновление экрана сто раз в секунду на iPhone плохо да и принцип отправки http запроса тоже требуется, но зачем вам iOS разработчик с навыком настройки апача или сборки системника?
UFO just landed and posted this here
Я согласен с Вами и с автором статьи, но не до конца. Могу сказать, что если говорить про масштабирование приложений (или про абстракционный уровень, если хотите) — то разрабы деплоя у меня на серверах свои приложения — и знать не знают (точнее знают, но им это действительно не нужно) про то, что у меня нагрузка распределена на несколько площадок, работают бекапы. Они знают, что у них есть, условно, «Папка, в которой может храниться 60 Тб пользовательскик данных» (читай картинок). То, что оно разъезжается на разные диски, площадки, и т.д. — для них не имеет значения. У них в фс — все это видно как одно пространство, т.е. «один единственный компьютер». И знания о том, что это не так по факту — у них имеются, но это не их зона ответственности. Иначе у меня бы отняли работу.
Такой программист должно быть тощий:
Программеры — они толстые. Потому что они сидят. А админы — они тощие. Потому что бегают. Впрочем, бывают тощие программеры. Но не надо думать, что это исключение из правил — это переученные админы. Также встречаются и толстые админы. Это обленившиеся программеры.
Да, а ещё разработчик должен поработать QA инженером, потому что иначе не сможет поставлять качественный продукт.
И ещё системным аналитиком, т.к. иначе не сможет анализировать потребности бизнеса и выявлять недостатки в полученном им таске.
Потребности бизнеса говорите? Но он же не сможет решить бизнес задачу, не понимая как работает бизнес. Так что ещё много кем надо поработать разработчику.
Жду статью о том, сколько будет стоить компании такой разработчик и где он взял столько лишнего времени, что бы на это тратить.
Разработчику нужно думать головой. Этим, в большинстве случаев, решаются описанные в статье (и многие другие) проблемы.
И ещё системным аналитиком, т.к. иначе не сможет анализировать потребности бизнеса и выявлять недостатки в полученном им таске.
Потребности бизнеса говорите? Но он же не сможет решить бизнес задачу, не понимая как работает бизнес. Так что ещё много кем надо поработать разработчику.
Жду статью о том, сколько будет стоить компании такой разработчик и где он взял столько лишнего времени, что бы на это тратить.
Разработчику нужно думать головой. Этим, в большинстве случаев, решаются описанные в статье (и многие другие) проблемы.
Знаю один пример такого разработчика: фрилансер по 1С-предприятие. Разбирается и в бухгалтерии и в бизнес-процессах. Сам проектирует, сам пишет, сам отлаживает… берёт по 2000 руб./час
Вывод один: чем человек больше знает, тем он дороже стоит (если он при этом умеет себя продать).
Вывод один: чем человек больше знает, тем он дороже стоит (если он при этом умеет себя продать).
Это нормальная практика, но вы же понимаете, что говорите об очень узкоспециализированном специалисте?
Т.е. он не может поменять стэк технологий, потому что привязан к 1С. Он не может переметнуться в другую сферу, когда бухгалтерия ему надоест.
Да банально страну дислокации сменить не может, потому что условный 1C нафиг не нужен в условных штатах.
Разбирается и в бухгалтерии, и в бизнес процессах — скорее следствие того, что N времени он работает в этой сфере. А не следствие того, что он до этого бухгалтером работал.
При этом 2к/час — вполне средняя цифра для фриланс разработчика с хорошим стажем. Ничего космического.
Ваш вывод тоже правилен только частично. Всем пофиг, сколько вы знаете. Работодателя интересует только то, как вы решаете его проблемы. Некоторые знания могут сильно помогать вам решать их лучше (например, банальное понимание потребностей бизнеса или платформы). Некоторые же — бесполезны и не несут добавочной стоимости.
Т.е. он не может поменять стэк технологий, потому что привязан к 1С. Он не может переметнуться в другую сферу, когда бухгалтерия ему надоест.
Да банально страну дислокации сменить не может, потому что условный 1C нафиг не нужен в условных штатах.
Разбирается и в бухгалтерии, и в бизнес процессах — скорее следствие того, что N времени он работает в этой сфере. А не следствие того, что он до этого бухгалтером работал.
При этом 2к/час — вполне средняя цифра для фриланс разработчика с хорошим стажем. Ничего космического.
Ваш вывод тоже правилен только частично. Всем пофиг, сколько вы знаете. Работодателя интересует только то, как вы решаете его проблемы. Некоторые знания могут сильно помогать вам решать их лучше (например, банальное понимание потребностей бизнеса или платформы). Некоторые же — бесполезны и не несут добавочной стоимости.
Да что блин с вами люди не так?! Что за трешню опять запостили? Зачем здесь это дерьмо, очевидное всем, кто имеет хотябы полгода стажа в 2016 году? Хватит постить на хабр такую херню — у вас для нее есть всякие гиктаймсы — вот туда и сливайте этот бред!!!
В своё время сколько перебрал систем биллинга — никто из их программистов даже представления не имел, как и что нужно считать, не говоря уж про железо… Сколько было матов…
Поэтому ни Azure Pack, ни Plesk, ни cPanel, ни другие платные и бесплатные панели управления хостингом, в моём случае, биллинга, как такогового не имеют — слишком большая специфика у каждой компании — хостинг-оператора, внутри.
Снаружи — да, хостинг сайтов, приложений, виртуальных или выделенных серверов, домены там — у всех хостеров плюс минус одинаковы. А внутри — в реалиях СНГ общее между ними только 1с на выходе документов.
Думаю все дело в естественно отборе. Опытный админ с хорошим резюме это один из сотни выживших, поскольку админов наказывают по сути за каждый прокол и их зарпалата напрямую связана со стабильностью и качеством их работы. Программистов, во-первых, на порядок больше, во-вторых, они обычно непосредственно ни за что не отвечают, для этого есть прослойка менеджеров и тимлидов, а в-третьих, вмененые им ключевые показатели имеют очень слабое отношение к эксплуатационным качеством, за это обычно отвечает опять таки, кто-то другой.
Вывод: Широкий кругозор, особенно в смежных областях, повышает эффективность. Спасибо Кэп. Проблем лишь в том, что хорошо знать много крайне сложно, поддерживать навыки на нужном уровне практически невозможно, а знать все невозможно совсем.
И тут природа придумала специализацию, человек ее имплементировал на экономические отношения. Это само по себе хорошо, но породило проблемы при переходе границ специализации. Эти издержки компенсируют крос специалисты или знающие оба предмета поверхностно( но способные быстро вникнуть в проблему ) или знающие оба предмета глубоко, но занесенные в красную книгу и очень дорогие, и плюс целая прослойка менеджмента задача которой координация действий.
И тут природа придумала специализацию, человек ее имплементировал на экономические отношения. Это само по себе хорошо, но породило проблемы при переходе границ специализации. Эти издержки компенсируют крос специалисты или знающие оба предмета поверхностно( но способные быстро вникнуть в проблему ) или знающие оба предмета глубоко, но занесенные в красную книгу и очень дорогие, и плюс целая прослойка менеджмента задача которой координация действий.
UFO just landed and posted this here
Эксплуатационщики точно такие же клиенты софта как и все остальные, только со своими вариантами использования — достаточно учитывать их интересы в рамках возможностей и все буду более менее дружно жить.
А что такого плохого в
?
Там можно хранить id процесса, например. И удалять из программы если уж нужно, минуя админов.
не делайте блокираторов запуска приложения в виде создания файла на диске, когда ваше приложение крешнется на терминальном сервере админ будет вынужден вручную удалять этот файл не останавливая сервера
?
Там можно хранить id процесса, например. И удалять из программы если уж нужно, минуя админов.
UFO just landed and posted this here
Правильно это делать, открывая файл на запись в эксклюзивном режиме и записывая туда PID.
Соответственно если приложение запускается повторно, то эксклюзивный режим не даст открыть файл и по этой ошибке выходим, если приложение крашнулось — можем открыть не смотря на то, что файл существует.
Типичная ошибка — считать что если файл есть то приложение не крашнулось, продвинутая ошибка — считать что удаление прописано в том месте которое вызовется даже при краше.
Соответственно если приложение запускается повторно, то эксклюзивный режим не даст открыть файл и по этой ошибке выходим, если приложение крашнулось — можем открыть не смотря на то, что файл существует.
Типичная ошибка — считать что если файл есть то приложение не крашнулось, продвинутая ошибка — считать что удаление прописано в том месте которое вызовется даже при краше.
Я примерно это и имел ввиду. У автора было просто "не используйте lock-файлы" без уточнений.
Правильно — это не использовать вещи не по назначению и не делать ненужных зависимостей. Я очень сомневаюсь, что цель файловой системы — это отслеживание запусков второго инстанса приложения.
И, между прочим, это каноничный пример того, как опыт создания скриптов из костылей, столь характерный для администрирования маленьких предприятий, в этом конкретном случае пошел разработчику во вред.
Ваше «решение» невозможно запустить на бездисковых системах и на системах с read-only носителями. Также потребуется решить проблемы с правами доступа приложения/пользователя на запись. Относительный путь или абсолютный — еще одна проблема. Как и API — не всякий поддерживает UNC-пути, например.
И, между прочим, это каноничный пример того, как опыт создания скриптов из костылей, столь характерный для администрирования маленьких предприятий, в этом конкретном случае пошел разработчику во вред.
Ваше «решение» невозможно запустить на бездисковых системах и на системах с read-only носителями. Также потребуется решить проблемы с правами доступа приложения/пользователя на запись. Относительный путь или абсолютный — еще одна проблема. Как и API — не всякий поддерживает UNC-пути, например.
Цель файловой системы — обслуживание приложений и обеспечение жизни ОС, а не только хранение пользовательских файлов. Любая современная большая ОС имеет ФС в которой отражена жизнедеятельность всех процессов ОС.
Для бездисковых систем /var/run монтируется на tmpfs и всё работает.
Для винды естественным решением для этого случая является именованный канал, но этот именованный канал всё равно будет лежать в корневой файловой системе. Для вас видимо сюрприз, что в M$ есть корневая ФС, поэтому начните своё знакомство например отсюда https://en.wikipedia.org/wiki/Object_Manager_(Windows).
Для бездисковых систем /var/run монтируется на tmpfs и всё работает.
Для винды естественным решением для этого случая является именованный канал, но этот именованный канал всё равно будет лежать в корневой файловой системе. Для вас видимо сюрприз, что в M$ есть корневая ФС, поэтому начните своё знакомство например отсюда https://en.wikipedia.org/wiki/Object_Manager_(Windows).
А гвозди вы тоже микроскопом забиваете?
Принципиальная проблема не в том, что ваше решение не будет работать, а в том, что для решения используются спроектированные для иных целей вещи.
В случае windows куда более логично использовать мьютекс, который по определению специально для таких целей и создан, а не городить костыли, считая любой объект в системегвоздём файлом.
А linux, на сколько я знаю, для решения таких задач предполагает использование семафора на разделяемой памяти. Тоже не требующего такой сильной зависимости как разрешение на запись на диск.
Принципиальная проблема не в том, что ваше решение не будет работать, а в том, что для решения используются спроектированные для иных целей вещи.
В случае windows куда более логично использовать мьютекс, который по определению специально для таких целей и создан, а не городить костыли, считая любой объект в системе
А linux, на сколько я знаю, для решения таких задач предполагает использование семафора на разделяемой памяти. Тоже не требующего такой сильной зависимости как разрешение на запись на диск.
Я лицо рука, открой Object Manager, иди в ветку \BaseNamedObjects и рассматривай какие мьютексы в системе объявлены. Это всё равно POSIX подход, в корявой M$ реализации конечно.
В линуксе семафор на разделяемой памяти уместен для IPC, для синглрана это жирно т.к. тебе всё равно как -то надо передать в другой процесс идентификатор разделённой области памяти, т.е. вместо того, чтобы просто проверить права доступа к файлу будешь заниматься межпроцессным взаимодействием. И это не «сильная зависимость» — есть https://ru.wikipedia.org/wiki/FHS который определяет что это должно быть доступно любому процессу.
В линуксе семафор на разделяемой памяти уместен для IPC, для синглрана это жирно т.к. тебе всё равно как -то надо передать в другой процесс идентификатор разделённой области памяти, т.е. вместо того, чтобы просто проверить права доступа к файлу будешь заниматься межпроцессным взаимодействием. И это не «сильная зависимость» — есть https://ru.wikipedia.org/wiki/FHS который определяет что это должно быть доступно любому процессу.
Тот факт, что существует некое альтернативно-одаренное, внешне похожее на файловое апи, позволяющего с дикими ограничениями получить доступ к некоторым объектам операционной системы — так это ведь вообще не аргумент. Само его существование (иначе как для получения некоей общей справочной информации о состоянии ОС) — большой архитектурный просчет — вне зависимости от операционной системы, качества реализации и «жирности». Просто обобщать сущности не имеющие друг с другом ничего общего — плохая практика…
Если один процесс пытается получить информацию о другом (о том что он запущен), то это в любом случе IPC просто по-определению этого термина. Блокируя файл, ты все-равно делаешь IPC, но не напрямую, а через посредника. Критерии «жирности», кстати, раз уж ты их упомянул, тоже дело довольно второстепенное. Хотя я не могу взять в толк, почему писать в шареную память «жирно», а на диск — нормально?
ЗЫ: Ну и по-поводу существования FHS — это тоже не аргумент. Еще в системе TCP-стек должен быть. И что теперь — давай сокет открывать по этому поводу? как альтернативу lock-файлу?:
Если один процесс пытается получить информацию о другом (о том что он запущен), то это в любом случе IPC просто по-определению этого термина. Блокируя файл, ты все-равно делаешь IPC, но не напрямую, а через посредника. Критерии «жирности», кстати, раз уж ты их упомянул, тоже дело довольно второстепенное. Хотя я не могу взять в толк, почему писать в шареную память «жирно», а на диск — нормально?
ЗЫ: Ну и по-поводу существования FHS — это тоже не аргумент. Еще в системе TCP-стек должен быть. И что теперь — давай сокет открывать по этому поводу? как альтернативу lock-файлу?:
Системный администратор и программист — разные профессии. Один не должен и не может работать другим. Как сантехник не может и не должен работать электриком. Проблема в том, что люди несущие пургу про «должен поработать» просто не понимают специфики профессий, для них раз человек сидит за компьютером, значит он должен делать и то, и другое, ну все равно же компьютер.
Никакие девопсы-шмевопсы не смогут понять почему вдруг процесс на жаве стал отъедать внезапно память и не отдавать, они не знают что такое логи, они не понимают что такое обращения на порт при котором плохо написанный софт выделяет память и обратно не отдает. Они тупо не найдут причину.
Никакой программист не сможет вам настроить HA-кластер, это просто не его дело. Его дело написать софт который будет работать.
Пора бы понять, что у тех кто сидит за компьютерами очень разные профессии и прекратить нести чушь.
Никакие девопсы-шмевопсы не смогут понять почему вдруг процесс на жаве стал отъедать внезапно память и не отдавать, они не знают что такое логи, они не понимают что такое обращения на порт при котором плохо написанный софт выделяет память и обратно не отдает. Они тупо не найдут причину.
Никакой программист не сможет вам настроить HA-кластер, это просто не его дело. Его дело написать софт который будет работать.
Пора бы понять, что у тех кто сидит за компьютерами очень разные профессии и прекратить нести чушь.
«Сантехник и электрик» — сравнение не очень. Они оба скорее админы, чем программисты. А программисты в данном случае, например, создатели выключателей. А они как раз должны знать какой-то минимуму про проводку: хотя, бы что проводов нужно два.
В тоже время электрик должен знать, как работает выключатель и уметь его починить и знать, что под него дырку нужно штробировать 10 см, а не полметра.
Тоже пример так себе, но лучше.
В тоже время электрик должен знать, как работает выключатель и уметь его починить и знать, что под него дырку нужно штробировать 10 см, а не полметра.
Тоже пример так себе, но лучше.
UFO just landed and posted this here
Сравнение было потому что оба что-то в домах делают, логика объединения такая же.
Это просто разные профессии и люди занимаются разными вещами.
Это просто разные профессии и люди занимаются разными вещами.
Электрика и водопровод по большей части независимы. А между программированием и администрированием связь все таки есть. Возьмем два крайних случая:
— Я программист и буду хранить терабайты в базе данных. Сеть тормозит? Обращайтесь к сисадмину.
— Я сисдадмин и выделю канал в 1 мб/с. Программа тормозит? Обращайтесь к программисту.
— Я программист и буду хранить терабайты в базе данных. Сеть тормозит? Обращайтесь к сисадмину.
— Я сисдадмин и выделю канал в 1 мб/с. Программа тормозит? Обращайтесь к программисту.
Отличный пример, заберу в цитатник
Я писал с телефона, да еще и за рулем. Не до правил русского языка.
Помните были времена когда были веб-мастера.
Название — обоюдо-острый меч, на самом деле.
У админа навыки программирования, или, скорее, навыки алгоритмизации, тоже должны быть. Скриптописание — это тоже такая себе разновидность программирования (хоть и дико простая, усложения вызваны, разве что, ограниченностью используемых средств). А без него нормальную работу построить тяжело.
Вот что действительно надо от админства программистам — это понимание, что:
— безопасность — это не что-то обстрактное где-то там. Отсюда, зачастую, проблем больше и они жирнее, чем от кривого дизайна ПО;
— понимание, что на серверной стороне оно должно работать без участия человека, или действия можно автоматизировать;
— хорошая документация предотвратит лишнее дерганье разраба админом. Админы, зачастую, сами находят решения проблем, если есть документация.
Скажем так. Админства в три-четыре года, или полтора-два года под руководством хорошего админа должно быть более чем достаточно, чтобы понять, как делать НЕ надо.
Ну или хорошего знакомого админа для консультаций, который готов уделить своё время.
У админа навыки программирования, или, скорее, навыки алгоритмизации, тоже должны быть. Скриптописание — это тоже такая себе разновидность программирования (хоть и дико простая, усложения вызваны, разве что, ограниченностью используемых средств). А без него нормальную работу построить тяжело.
Вот что действительно надо от админства программистам — это понимание, что:
— безопасность — это не что-то обстрактное где-то там. Отсюда, зачастую, проблем больше и они жирнее, чем от кривого дизайна ПО;
— понимание, что на серверной стороне оно должно работать без участия человека, или действия можно автоматизировать;
— хорошая документация предотвратит лишнее дерганье разраба админом. Админы, зачастую, сами находят решения проблем, если есть документация.
Скажем так. Админства в три-четыре года, или полтора-два года под руководством хорошего админа должно быть более чем достаточно, чтобы понять, как делать НЕ надо.
Ну или хорошего знакомого админа для консультаций, который готов уделить своё время.
понимание, что на серверной стороне оно должно работать без участия человека, или действия можно автоматизировать;
Это чтобы админов пинать, что задачи провижна и деплоя автоматизировали?
Скажем так. Админства в три-четыре года
Очень много. Не говоря о том, что это админство может быть очень слабо связано с задачами по разработке. Грубо говоря, админил сетку и телефонию, а занимаешься разработкой фронта к веб-приложениям.
Ну или хорошего знакомого админа для консультаций, который готов уделить своё время.
На нормальной работе должен быть такой знакомый, причём готов потому что это его прямые обязанности, потому что он прежде всего отвечает за безопасность сети. Если разработчик где-то открыл какой-то порт для отладки и забыл закрыть перед релизом на прод, а через него взломали, то виноват прежде всего админ, давший миру доступ к неизвестному порту.
Это чтобы админов пинать, что задачи провижна и деплоя автоматизировали?
Ну всё-таки давайте не передергивать. Лично у меня есть в парке приложение, которое для своей работы требует логона в систему. Пинать админа для того чтобы делал автологон на серверах?
Грубо говоря, админил сетку и телефонию
Но мы же говорим, наверно, всё-таки о сисадминстве или, в крайнем случае, крайне (мда, каламбур) приближённом к этому эникею. А сети и телефония — это уже несколько другая профессии. То, что, зачастую, админу сваливают это всё — это специфика небольших контор.
забыл закрыть перед релизом на прод, а через него взломали
Бесконтрольное хождение через периметр сети — это проблема сугубо админов и безопасников. К теме обсуждения отношение имеет опосредованное.
Промахнулся с ответом.
Sign up to leave a comment.
У разработчика программного обеспечения должен быть опыт сисадминства