Комментарии 23
За более чем 10 лет мне не приходилось программировать. Батники, баш скрипты и powershell не в счет.
Я говорю исключительно про администрирование. Пишется обычно несколько строк для решения конкретной задачи. В большинстве случаев даже не пишется, а гуглится и правится под себя.
Максимум что я делал — обход дерева директорий и удаление файлов по маске старше определенного времени. Строчек 15 вышло.
Я программировал в институте и после сам пытался «войти в айти» с python и php — задачи решаемые программированием в админстве и рядом с этим не стояли.
И вообще, тут коммутатор новый приехал с портами QSFP+ 40Гбит/сек — пойду погоняю на тестах, раньше ничего больше 10 не приходилось в руках держать.
Зачем мне ваше программирование?..
В моём случае много скриптинга на повершелке, потому что:
1. Собрать нужный отчет с систем виртуализации vmware и hyper-v. много систем банально без vcenter'ов и vmm
2. Актуализировать учетные записи в AD на основе данных из учетных кадровых систем. Плюс отчеты по учеткам, группам. Не руками же мне править и данные выписывать.
3. Развернуть виртуальные машины в нужной конфигурации с нужным ПО. собрать с них отчеты о состоянии, ПО, конфигах. разлить специфичную настройку здесь и сейчас.
4. Собрать информацию по почтовым ящиками в Exchange. Почистить их, отключить, выгрузить.
И многие другие вещи по мелочи и нет.
Я скриптовал, даже когда у меня десяток серверов был, видимо по этому я не сильно напрягался когда их стало почти в 50 раз больше.
Но ранее бывало.
И в догонку пара вопросов:
Как много классов в ваших программах на Powershell? В какой IDE разрабатываете, какую CVS используете? Используете MVC? Регулярно проходите code review?
ISE, VSCode.
GIT, GITHub
Нет
Выстроенного процесса нет, но стараюсь смотреть код моих бойцов прежде чем он начнет работать там где это может нанести вред.
Я ж и говорю, не программисты, а мастера-скриптологи. :)
Однако сейчас я делаю тоже самое на повершелке без классов и красивых интерфейсов раз в сутки с автоматическим созданием заявок в сервисдеске, если набору правил что то не нравится.
Почему в первом случае я программист, а во втором нет?
Как много классов в ваших программах на Powershell? В какой IDE разрабатываете, какую CVS используете? Используете MVC? Регулярно проходите code review?
MVC в администрировании, ага
Сначала у них БД прыгали (mysql -> postgresql -> mysql), теперь вот разработчики с админами. Интересно кто будут следующими? Аналитики с тестировщиками? :)
Желание запихнуть внутрь команды разработчиков ещё и саппорт 24/7 понятно. Подходящую риторику и мифологию вместо ITIL для этого тоже придумать не сложно. Не понятно как они на такое ведутся? Вроде ж айтишники умные люди.
Быть докой во всем все равно не хватит жизни. Это у эффективных менеджеров может быть красиво все выходит, что Вася и жнец, и жрец, и на дуде игрец. По факту рабочее время и голова у Васи не резиновые. Прибавил в одном, упустил в другом.
Поэтому, да, можно (и иногда нужно) подтянуть азы смежной области, расширить кругозор (тут, вы нам америку не открыли), но быть в ней наравне с узким специалистом — это популизм чистой воды, который не перестают лить в уши доверчивым гражданам, в том числе руководителям более высокого порядка.
Обратите внимание, я говорил что есть большой пласт системных знаний, которых невозможно набрать за полгода. Естественно, что всегда будут сложные инфраструктурные задачи, которые будут решаться своими командами. А что до обычного сервиса, так тут ведь каждый может почитать логи, посмотреть графики и понять, что не так — особенно его автор, не так ли? Об этом и речь — об ответственности, это ключевой момент. И, судя по комментариям, люди очень сильно не хотят ее брать на себя :)
Про ответственность все понятно, и без скрещивания разработчика с админом, у разработчика есть своя сфера ответственности, те кто этого не понимают всю жизнь сидят на попе ровно (день прошел и черт с ним).
И ваш посыл я тоже понимаю — отвечать в целом за продукт, а не кивать друг на друга (это твой код кривой, нет это твой кривой контейнер виноват). Вопрос в пределе скрещивания и решать стоит для конкретного проекта. У вас — так, у нас — по-другому. Кто вам нужен на поддержке дев-недоадмин, админ-недодев, недодев-недоадмин и тп комбинации. Сколько он будет стоить и сколько будет стоить решение или нерешение им проблем. Это тоже ответственность руководителя, принявшего решение как и кем закрывать вопрос с поддержкой.
Я ваше мнение в статье прочитал, услышал, узнал, что бывает вот так, как вы рассказали. Для себя лишний раз уяснил, что нет универсального решения. Опасения свои привел комментом ранее, потому как сталкивался с печальным опытом — оголтелыми любителями наводнить компанию только универсалами.
Хорошо, что у вас ваше решение работает. Успехов.
Разрабы становятся админами, а админы — разрабами. Интервью с инженером Uber, где разделение исчезло совсем