Системный администратор / Разработчик ПО
Деятельность обоих имеет критическое значение. Программное обеспечение представляет ценность для пользователей само по себе, но оно не может существовать без среды, в которой оно работает.
Многие компании предпочитают держать разработчиков и сисадминов в разных командах. Теоретически это имеет смысл. Два различных набора навыков и умения — две разные профессии. Почему бы не быть двум разным командам?
Самая большая проблема здесь состоит в том, что конкретные обстоятельства имеют, на самом деле, большое значение при создании ПО. Разработчики должны понимать то окружение, в котором будет работать их программа, иначе они не смогут сделать её правильно.
Аналогия — представьте, что вам предложили спроектировать здание, не указав, где оно будет стоять. Вы сделали бы, возможно, вполне достойный проект.
Но потом кто-то возьмёт этот проект и построит дом… на склоне.
Круто!
Если разработчик ПО никогда не выполнял функций системного администратора, то он будет создавать программы, которые работают теоретически. Разработчик делает программу, как правило, на своём единственном компьютере. Основная часть ПО в интернете работает на разных компьютерах. Громадные сайты, такие как Google или Facebook, имеют тысячи компьютеров. Но так же как наш гипотетический дом, прекрасно стоящий на равнине, программа, теоретически прекрасно работающая, может полностью рухнуть, столкнувшись с множеством пользователей. Это может произойти в форме багов или обрушения программы.
Например, рассмотрим сайт, куда вы загружаете изображения, такой как Facebook или Twitter. Facebook и Twitter имеют слишком много пользователей, чтобы эти сервисы работали на одном сервере и/или компьютере. Поэтому у них множество веб-серверов, дающих вам доступ к веб-сайту.
Почему это важно? Вспомните, что разработчик пишет программу, как правило, на одном единственном компьютере. Он мог бы написать код, который сохранит изображение на том же жёстком диске, на котором работает веб-сервер, что для него одно и то же. Но проблемы появляются, когда программа оказывается перед сторонним пользователем, как, например, вы.
Если имеется 3 веб-сервера и изображение сохранено на жёстком диске одного из них, то тогда 2 из 3 человек не смогут увидеть это изображение. Если у вас 300 друзей, то только 100 из них смогут увидеть загруженное вами изображение. Вот это сервис!
If this goes here… — Если ваша картинка попадает сюда
Then users who go here won't see it = то пользователи, приходящие сюда, не увидят её
Правильным способом исправить это является использование распределённой файловой системы, которая доступна для всех веб-серверов.
Поместите все изображения в облачное хранилище!
Однако разработчик, не имеющий достаточного опыта, не сделает этого. Он пишет код для одиночного компьютера. Изображение будет видно все 100% времени при проверке программы на одном компьютере. Проблема обнаружится, только когда пользователи начнут использовать программу на реальных веб-серверах.
Есть десятки, если не сотни, других примеров Кто-то должен объяснить разработчику, как эти вещи работают, но, правильно говорят, понять можно лишь пережитое. Свой собственный опыт даёт более глубокое понимание.
Такое понимание помогает обнаружить ошибки намного раньше в процессе разработки. Разработчик без опыта сисадминовской работы проходит обычный путь:
1. Пишет программу.
2. Отправляет её на просмотр и/или тестирование.
3. Получает программу обратно для исправления ошибок.
И это может быть довольно длительным процессом.
Ситуация может быть хуже, потому что зачастую сисадмины не желают просматривать программу, присланную разработчиком. Это значит, что со всеми багами первым столкнётся пользователь! Этот вид проблем трудно исследовать ещё и потому, что программа может работать безукоризненно на компьютере разработчика. Бывает трудно воспроизвести проблему.
Следует признать, мне не по душе заниматься системным администрированием. Я знаю, что есть люди, которым это очень нравится, но для меня такая деятельность — просто постоянный источник неудовлетворённости. Сисадминство представляет собой набор знаний и опыта, отличный от требуемого для написания программ, но оно нужно мне на моём пути доведения до людей того программного обеспечения, которое я создал.
И я делаю это в любом случае. Я делаю это, потому что знание окружения помогает мне написать программу лучше. Я делаю это, потому что программа, работающая только на моём компьютере, бесполезна. Программа, которая имеет значение, это та, что работает на веб-серверах, которыми пользуются все остальные люди. Просто написать программу означает сделать только половину того, что обязан сделать настоящий разработчик.
Комментарии (55)
crazylh
19.01.2017 22:28+9Поздравляю! Вы только что изобрели DevOps
viiy
20.01.2017 09:25+1Немного не так. DevOps несомненно обязан понимать в какой то мере код основных современных языков. И админить обязан уметь. А архитектуру проекта знать должен. И в безопасности профаном не быть. И методы тестирования понимать. Только это навыки, но не назначение DevOps-ов. Задача DevOps-ов — инструментально обеспечивать частый выпуск продукта, выстраивать процесс разработки, тестирования и деплоя. Чтобы всем было удобно работать и повышалось качество продукта. Естественно, при этом нет задачи перекрыть роли всех специалистов и отобрать у них работу.
Andrey_911
20.01.2017 11:38+3Абсолютно согласен. DevOps- это вовсе НЕ разработчик. Он отвечает за Автоматизацию процесса разработки, тестирования и деплоя. Вот тут как раз спутали «теплое с мягким».
urtow
20.01.2017 12:08+1DevOps — это подход, а не профессия.
Хотя, смотря на вакансии я прихожу к мысли, что понимаю это только я.
yokotoka
20.01.2017 01:35+6Professor Beekums (автор оригинальной статьи) только что вышел из криокамеры, проведя в ней 10 лет и еще не успел узнать про docker?
evocatus
20.01.2017 10:27+2Эти ваши контейнеры не решают и 5% проблем, которые возникают, когда разработчик не имеет представления о пльзователях его продукта и среде, в которой он будет работать (притом не о среднем пользователе, а о самом «неудобном»).
Разрабатывать сайты на маке с последним Intel Core и Retina-дисплеем для пользователей с IE8 и Pentium 4 (гос.учреждения и некоторый бизнес) или AltLinux 5 (с Firefox 4.0) и Core 2 Duo (школы)
khanid
20.01.2017 21:19Докер решает проблему зависимостей, рантайма, деплоя, неба, но не решает проблемы промахов в проектировании продукта. Если проблема by design, то всё остальное — это просто лечение симптомов.
VolCh
21.01.2017 16:02По сути докер — это инструмент, облегчающий работу админов. Если вы, как разработчик софта, пишите докер- и докер-композ файлы для своего софта, то вы выполняете работу админа.
TrueMaker
20.01.2017 01:41+3Devops — это не человек, это практика — читаем википедию.
SRE (Site reliability engineering) — давно существует, и крупные компании это активно практикуют. Это админы которые разрабатывают всю инфраструктуру и софт для нее, а также работают с программистами как правильно под всё это писать.
Danik-ik
20.01.2017 07:46+5Не нужен опыт, нужны знания о предметной среде.
Подобное этому заявление: каждый разоаботчик космического корабля должен побывать в космосе.
Для развивающегося программиста "побывать в сисадминах" обойдётся слишком дорого. Но есть выход! Говорят, люди научились накапливать знантя, и — не говорите никому — тиражировать их благодаря письменности!
Вывод: программист должен уметь читать и понимать написанное. Не понял — научись спрашивать. Серебряная пуля найдена!
Danik-ik
20.01.2017 08:02+1… И всеми силами приобщаться к прочим средствам по передаче опыта — лекции, конференции, митапы и т.п., особенно с обратной связью. Учиться надо! Это уже из почти настоящего золота пуля.
Electrohedgehog
20.01.2017 08:02+2Мысль верная, но изложение хромает. Плюс не везде применимая.
В вебе очень важно понимать как между собой взаимодействуют сервера, в разработке драйверов очень важно понимать как работает железо. Но не наоборот.
В разработке под мобильные устройства что, не относящееся к коду важно? Я не спорю, что необходимо понимание того, почему обновление экрана сто раз в секунду на iPhone плохо да и принцип отправки http запроса тоже требуется, но зачем вам iOS разработчик с навыком настройки апача или сборки системника?
alz72
20.01.2017 09:07+1Как разработчик с сисадминским бэкграундом скажу — да, мои знания иногда сильно помогают и ускоряют процесс ( особенно когда они реально превышают знания текущего админа), но при грамотных админах — эти знания не нужны ( ну разве что админов понимаешь с полуслова).
Crystal_HMR
20.01.2017 11:38Я согласен с Вами и с автором статьи, но не до конца. Могу сказать, что если говорить про масштабирование приложений (или про абстракционный уровень, если хотите) — то разрабы деплоя у меня на серверах свои приложения — и знать не знают (точнее знают, но им это действительно не нужно) про то, что у меня нагрузка распределена на несколько площадок, работают бекапы. Они знают, что у них есть, условно, «Папка, в которой может храниться 60 Тб пользовательскик данных» (читай картинок). То, что оно разъезжается на разные диски, площадки, и т.д. — для них не имеет значения. У них в фс — все это видно как одно пространство, т.е. «один единственный компьютер». И знания о том, что это не так по факту — у них имеются, но это не их зона ответственности. Иначе у меня бы отняли работу.
johnfound
20.01.2017 09:26+3Такой программист должно быть тощий:
Программеры — они толстые. Потому что они сидят. А админы — они тощие. Потому что бегают. Впрочем, бывают тощие программеры. Но не надо думать, что это исключение из правил — это переученные админы. Также встречаются и толстые админы. Это обленившиеся программеры.
azShoo
20.01.2017 11:13+2Да, а ещё разработчик должен поработать QA инженером, потому что иначе не сможет поставлять качественный продукт.
И ещё системным аналитиком, т.к. иначе не сможет анализировать потребности бизнеса и выявлять недостатки в полученном им таске.
Потребности бизнеса говорите? Но он же не сможет решить бизнес задачу, не понимая как работает бизнес. Так что ещё много кем надо поработать разработчику.
Жду статью о том, сколько будет стоить компании такой разработчик и где он взял столько лишнего времени, что бы на это тратить.
Разработчику нужно думать головой. Этим, в большинстве случаев, решаются описанные в статье (и многие другие) проблемы.unit811
20.01.2017 11:38+1Знаю один пример такого разработчика: фрилансер по 1С-предприятие. Разбирается и в бухгалтерии и в бизнес-процессах. Сам проектирует, сам пишет, сам отлаживает… берёт по 2000 руб./час
Вывод один: чем человек больше знает, тем он дороже стоит (если он при этом умеет себя продать).azShoo
20.01.2017 11:49Это нормальная практика, но вы же понимаете, что говорите об очень узкоспециализированном специалисте?
Т.е. он не может поменять стэк технологий, потому что привязан к 1С. Он не может переметнуться в другую сферу, когда бухгалтерия ему надоест.
Да банально страну дислокации сменить не может, потому что условный 1C нафиг не нужен в условных штатах.
Разбирается и в бухгалтерии, и в бизнес процессах — скорее следствие того, что N времени он работает в этой сфере. А не следствие того, что он до этого бухгалтером работал.
При этом 2к/час — вполне средняя цифра для фриланс разработчика с хорошим стажем. Ничего космического.
Ваш вывод тоже правилен только частично. Всем пофиг, сколько вы знаете. Работодателя интересует только то, как вы решаете его проблемы. Некоторые знания могут сильно помогать вам решать их лучше (например, банальное понимание потребностей бизнеса или платформы). Некоторые же — бесполезны и не несут добавочной стоимости.
Toshiro
20.01.2017 11:15+2Да что блин с вами люди не так?! Что за трешню опять запостили? Зачем здесь это дерьмо, очевидное всем, кто имеет хотябы полгода стажа в 2016 году? Хватит постить на хабр такую херню — у вас для нее есть всякие гиктаймсы — вот туда и сливайте этот бред!!!
bigbrotherwatchingyou
20.01.2017 11:38В своё время сколько перебрал систем биллинга — никто из их программистов даже представления не имел, как и что нужно считать, не говоря уж про железо… Сколько было матов…
foxmuldercp
21.01.2017 19:18Поэтому ни Azure Pack, ни Plesk, ни cPanel, ни другие платные и бесплатные панели управления хостингом, в моём случае, биллинга, как такогового не имеют — слишком большая специфика у каждой компании — хостинг-оператора, внутри.
Снаружи — да, хостинг сайтов, приложений, виртуальных или выделенных серверов, домены там — у всех хостеров плюс минус одинаковы. А внутри — в реалиях СНГ общее между ними только 1с на выходе документов.bigbrotherwatchingyou
23.01.2017 07:07Речь не об учете услуг хостинга, а про учет провайдерского траффика
acmnu
20.01.2017 11:57Думаю все дело в естественно отборе. Опытный админ с хорошим резюме это один из сотни выживших, поскольку админов наказывают по сути за каждый прокол и их зарпалата напрямую связана со стабильностью и качеством их работы. Программистов, во-первых, на порядок больше, во-вторых, они обычно непосредственно ни за что не отвечают, для этого есть прослойка менеджеров и тимлидов, а в-третьих, вмененые им ключевые показатели имеют очень слабое отношение к эксплуатационным качеством, за это обычно отвечает опять таки, кто-то другой.
nApoBo3
20.01.2017 12:27Вывод: Широкий кругозор, особенно в смежных областях, повышает эффективность. Спасибо Кэп. Проблем лишь в том, что хорошо знать много крайне сложно, поддерживать навыки на нужном уровне практически невозможно, а знать все невозможно совсем.
И тут природа придумала специализацию, человек ее имплементировал на экономические отношения. Это само по себе хорошо, но породило проблемы при переходе границ специализации. Эти издержки компенсируют крос специалисты или знающие оба предмета поверхностно( но способные быстро вникнуть в проблему ) или знающие оба предмета глубоко, но занесенные в красную книгу и очень дорогие, и плюс целая прослойка менеджмента задача которой координация действий.
pak-nikolai
20.01.2017 13:03+2писал код 4 года, 6 лет системным администратором и все это время писал себе разные тулзы. Что скажу это мое мнение
Прогеру надо поадминить 4-8 месяцев в хорошей фирме чтобы знать психологию юзера, понимать как работает эксплуатационная служба, понимать сложности эксплутационщиков. Они ненавидят вас потому что вы порождаете им работу, пишите код так чтобы:
- небыло левых ненужных окошек, консольных какихто бегающих точек и текстовых выводов пугающих пользователя
- перегруженых форм вызывающих звонки юзеров, при смене сотрудника новый паникует, предусматривайте режим обучения или пишите понятно (особенно убивает какойнибудь самделошный СКУД в котором новенькая девочка оператор пытается записывать в тетрадь последовательность действий чтобы вытащить ежедневный отчет)
- избегайте недружественных уровню пользователей интерфейсов (если это для кладовщика должно быть две кнопки, если это для аналитика то может быть много кнопок)
- если есть операция требующая 5 раз ввести данные СРАЗУ запросите все данные и потом делайте спокойно операцию
- ждать отклика больше 1,5 сек без причины пользователь недолжен
- пользователь вошел в формирование накладной и на вводе каждого товара вы круто оптимизированным запросом делаете запрос к базе? — прибить вас мало. все что связано с интерфейсом кешируйте
- если идет длительная операция пусть пользователь знает что она идет
- думайте как эксплутационщик будет это сопровождать, не ленитесь писать дополнительные тулзы, логи, параметры
- знайте психологию эникея — если чтото будет глючить то он погуглит и приделает костылик, поэтому приделайте законные пути сами (А вы может и не знали что можно посылать нажатия кнопок через VB скрипт? или тыкать мышкой через AutoIt, или вводить данные через Selenium поверьте эникей и не такое еще придумает)
- помните о том что при сбое админ будет делать рестор с бэкапа, не усложняйте эксплуатационщикам жизнь вашими дикими фантазиями, все должно быть просто
- не делайте блокираторов запуска приложения в виде создания файла на диске, когда ваше приложение крешнется на терминальном сервере админ будет вынужден вручную удалять этот файл не останавливая сервера
- нет понятной инструкции приложение не пойдет. хелп пишите с картинками где нужно, юзайте анимахи где есть последовательность действия
- поймите как думает админ — ему надо решить какойто трабл который возникает при исползовании вашего приложения поэтому продумайте сами как пользовательнажимает на кнопку, как он что делает, как он включает, как он выключает, что он будет делать когда отключат электричество. Админ сложное ищет в доках, не бойтесь повторяться в документации, главы и разделы сведите не только по порядку но и по смыслу, пусть будет два раза одно и тоже
- большинство админов может написать скрипт не больше 200 строк, ну максимум 600 поэтому если видите что он не понимает что такое хэндл, стек и версия дот нета то не грузите его учитесь разговаривать с людьми
- помните что админов высокого уровня мало, они заняты постоянно. Поэтому ориентируйтесь на уровень вполовину MCSA
- приделайте чтонить типа автодиагностики
- не валите работу на другой отдел — если вы будете валить на сетевиков, те на БДшников, те на ИБшников, то пострадает по оконцове ваш продукт и эксплуатация
- если разборки дойдут до зубра который может взять IDA и знает код то получите с большой вероятностью вы а не админ, потому что он будет давать оценку вашей работе и вашему отделу перед вышестоящим руководством а это всегда неприятно
- только на админском уровне находятся знания как взаимодействуют сеть, приложения, железные мощности и пользователи конкретной инфраструктуры
- админ не может и не должен все знать и во всем разбираться, т.к. у него много технологий и систем. Он использует то что ему дают
- всего и не расскажешь ...
кароче изучайте свою профессию, повышайте класс — пишите ХОРОШО
vyatsek
20.01.2017 13:38+1Эксплуатационщики точно такие же клиенты софта как и все остальные, только со своими вариантами использования — достаточно учитывать их интересы в рамках возможностей и все буду более менее дружно жить.
leremin
20.01.2017 13:38А что такого плохого в
не делайте блокираторов запуска приложения в виде создания файла на диске, когда ваше приложение крешнется на терминальном сервере админ будет вынужден вручную удалять этот файл не останавливая сервера
?
Там можно хранить id процесса, например. И удалять из программы если уж нужно, минуя админов.pak-nikolai
20.01.2017 14:52всякие остатки на дисках, промежуточные результаты и прочее очищайте при старте, видел пару самописных программ которые оставляют после себя остатки, т.е. у них очистка записана при закрытии приложения, а может ведь быть завис и принудительное завершение
tzlom
20.01.2017 15:58+2Правильно это делать, открывая файл на запись в эксклюзивном режиме и записывая туда PID.
Соответственно если приложение запускается повторно, то эксклюзивный режим не даст открыть файл и по этой ошибке выходим, если приложение крашнулось — можем открыть не смотря на то, что файл существует.
Типичная ошибка — считать что если файл есть то приложение не крашнулось, продвинутая ошибка — считать что удаление прописано в том месте которое вызовется даже при краше.leremin
20.01.2017 16:13Я примерно это и имел ввиду. У автора было просто "не используйте lock-файлы" без уточнений.
fcoder
24.01.2017 23:25Правильно — это не использовать вещи не по назначению и не делать ненужных зависимостей. Я очень сомневаюсь, что цель файловой системы — это отслеживание запусков второго инстанса приложения.
И, между прочим, это каноничный пример того, как опыт создания скриптов из костылей, столь характерный для администрирования маленьких предприятий, в этом конкретном случае пошел разработчику во вред.
Ваше «решение» невозможно запустить на бездисковых системах и на системах с read-only носителями. Также потребуется решить проблемы с правами доступа приложения/пользователя на запись. Относительный путь или абсолютный — еще одна проблема. Как и API — не всякий поддерживает UNC-пути, например.tzlom
25.01.2017 09:37+1Цель файловой системы — обслуживание приложений и обеспечение жизни ОС, а не только хранение пользовательских файлов. Любая современная большая ОС имеет ФС в которой отражена жизнедеятельность всех процессов ОС.
Для бездисковых систем /var/run монтируется на tmpfs и всё работает.
Для винды естественным решением для этого случая является именованный канал, но этот именованный канал всё равно будет лежать в корневой файловой системе. Для вас видимо сюрприз, что в M$ есть корневая ФС, поэтому начните своё знакомство например отсюда https://en.wikipedia.org/wiki/Object_Manager_(Windows).fcoder
25.01.2017 22:31А гвозди вы тоже микроскопом забиваете?
Принципиальная проблема не в том, что ваше решение не будет работать, а в том, что для решения используются спроектированные для иных целей вещи.
В случае windows куда более логично использовать мьютекс, который по определению специально для таких целей и создан, а не городить костыли, считая любой объект в системегвоздёмфайлом.
А linux, на сколько я знаю, для решения таких задач предполагает использование семафора на разделяемой памяти. Тоже не требующего такой сильной зависимости как разрешение на запись на диск.
tzlom
26.01.2017 11:14Я лицо рука, открой Object Manager, иди в ветку \BaseNamedObjects и рассматривай какие мьютексы в системе объявлены. Это всё равно POSIX подход, в корявой M$ реализации конечно.
В линуксе семафор на разделяемой памяти уместен для IPC, для синглрана это жирно т.к. тебе всё равно как -то надо передать в другой процесс идентификатор разделённой области памяти, т.е. вместо того, чтобы просто проверить права доступа к файлу будешь заниматься межпроцессным взаимодействием. И это не «сильная зависимость» — есть https://ru.wikipedia.org/wiki/FHS который определяет что это должно быть доступно любому процессу.fcoder
27.01.2017 10:23+1Тот факт, что существует некое альтернативно-одаренное, внешне похожее на файловое апи, позволяющего с дикими ограничениями получить доступ к некоторым объектам операционной системы — так это ведь вообще не аргумент. Само его существование (иначе как для получения некоей общей справочной информации о состоянии ОС) — большой архитектурный просчет — вне зависимости от операционной системы, качества реализации и «жирности». Просто обобщать сущности не имеющие друг с другом ничего общего — плохая практика…
Если один процесс пытается получить информацию о другом (о том что он запущен), то это в любом случе IPC просто по-определению этого термина. Блокируя файл, ты все-равно делаешь IPC, но не напрямую, а через посредника. Критерии «жирности», кстати, раз уж ты их упомянул, тоже дело довольно второстепенное. Хотя я не могу взять в толк, почему писать в шареную память «жирно», а на диск — нормально?
ЗЫ: Ну и по-поводу существования FHS — это тоже не аргумент. Еще в системе TCP-стек должен быть. И что теперь — давай сокет открывать по этому поводу? как альтернативу lock-файлу?:
Erelecano
20.01.2017 15:23-1Системный администратор и программист — разные профессии. Один не должен и не может работать другим. Как сантехник не может и не должен работать электриком. Проблема в том, что люди несущие пургу про «должен поработать» просто не понимают специфики профессий, для них раз человек сидит за компьютером, значит он должен делать и то, и другое, ну все равно же компьютер.
Никакие девопсы-шмевопсы не смогут понять почему вдруг процесс на жаве стал отъедать внезапно память и не отдавать, они не знают что такое логи, они не понимают что такое обращения на порт при котором плохо написанный софт выделяет память и обратно не отдает. Они тупо не найдут причину.
Никакой программист не сможет вам настроить HA-кластер, это просто не его дело. Его дело написать софт который будет работать.
Пора бы понять, что у тех кто сидит за компьютерами очень разные профессии и прекратить нести чушь.leremin
20.01.2017 15:30+2«Сантехник и электрик» — сравнение не очень. Они оба скорее админы, чем программисты. А программисты в данном случае, например, создатели выключателей. А они как раз должны знать какой-то минимуму про проводку: хотя, бы что проводов нужно два.
В тоже время электрик должен знать, как работает выключатель и уметь его починить и знать, что под него дырку нужно штробировать 10 см, а не полметра.
Тоже пример так себе, но лучше.
Am0ralist
20.01.2017 16:59хотя, бы что проводов нужно два.
и почему после этих слов я сейчас вспомнил статьи про заблуждения о времени или о ФИО?
Правильнее все же: «не менее двух»)
Erelecano
20.01.2017 17:35Сравнение было потому что оба что-то в домах делают, логика объединения такая же.
Это просто разные профессии и люди занимаются разными вещами.leremin
20.01.2017 19:04+1Электрика и водопровод по большей части независимы. А между программированием и администрированием связь все таки есть. Возьмем два крайних случая:
— Я программист и буду хранить терабайты в базе данных. Сеть тормозит? Обращайтесь к сисадмину.
— Я сисдадмин и выделю канал в 1 мб/с. Программа тормозит? Обращайтесь к программисту.
khanid
20.01.2017 21:36Название — обоюдо-острый меч, на самом деле.
У админа навыки программирования, или, скорее, навыки алгоритмизации, тоже должны быть. Скриптописание — это тоже такая себе разновидность программирования (хоть и дико простая, усложения вызваны, разве что, ограниченностью используемых средств). А без него нормальную работу построить тяжело.
Вот что действительно надо от админства программистам — это понимание, что:
— безопасность — это не что-то обстрактное где-то там. Отсюда, зачастую, проблем больше и они жирнее, чем от кривого дизайна ПО;
— понимание, что на серверной стороне оно должно работать без участия человека, или действия можно автоматизировать;
— хорошая документация предотвратит лишнее дерганье разраба админом. Админы, зачастую, сами находят решения проблем, если есть документация.
Скажем так. Админства в три-четыре года, или полтора-два года под руководством хорошего админа должно быть более чем достаточно, чтобы понять, как делать НЕ надо.
Ну или хорошего знакомого админа для консультаций, который готов уделить своё время.VolCh
21.01.2017 20:25понимание, что на серверной стороне оно должно работать без участия человека, или действия можно автоматизировать;
Это чтобы админов пинать, что задачи провижна и деплоя автоматизировали?
Скажем так. Админства в три-четыре года
Очень много. Не говоря о том, что это админство может быть очень слабо связано с задачами по разработке. Грубо говоря, админил сетку и телефонию, а занимаешься разработкой фронта к веб-приложениям.
Ну или хорошего знакомого админа для консультаций, который готов уделить своё время.
На нормальной работе должен быть такой знакомый, причём готов потому что это его прямые обязанности, потому что он прежде всего отвечает за безопасность сети. Если разработчик где-то открыл какой-то порт для отладки и забыл закрыть перед релизом на прод, а через него взломали, то виноват прежде всего админ, давший миру доступ к неизвестному порту.khanid
29.01.2017 00:43Это чтобы админов пинать, что задачи провижна и деплоя автоматизировали?
Ну всё-таки давайте не передергивать. Лично у меня есть в парке приложение, которое для своей работы требует логона в систему. Пинать админа для того чтобы делал автологон на серверах?
Грубо говоря, админил сетку и телефонию
Но мы же говорим, наверно, всё-таки о сисадминстве или, в крайнем случае, крайне (мда, каламбур) приближённом к этому эникею. А сети и телефония — это уже несколько другая профессии. То, что, зачастую, админу сваливают это всё — это специфика небольших контор.
забыл закрыть перед релизом на прод, а через него взломали
Бесконтрольное хождение через периметр сети — это проблема сугубо админов и безопасников. К теме обсуждения отношение имеет опосредованное.
Suvitruf
CDN.
Сейчас довольно модное словечко есть для всего этого — DevOps. И код напишет, и задиплоит, и на дуде игрец.
P.S. это, к слову, работает в обе стороны. Если админ не знаком со спецификой софта, то тоже проблемы будут, правда, другого уровня.
VolCh
Не совсем так. Я пишу код, который хранит где-то хранит состояние приложения. В нормально поставленном взаимодействии с админами я сообщаю к каким средствам хранения и как обращаюсь
VolCh
в рантайме. Скажем, говорю, что к части данных обращаюсь через вызлвы pdo-pgsql, к части через ФС сервера, к части через стандартный механизм сессий PHP. Их же дело это отмасштабировать средствами ОС, системного ПО и т. п., либо предложить мне использовать другие способы хранения состояния.