Comments 57
Теперь любой админ локалхоста, который осилил ansible считает себя devopsом, окей. Только суть концепции вы так и не уловили.
+25
Ну вы же знаете почему так происходит :)
Recruiter reaction when putting DevOps as a skill in a public CV
+17
В очередной раз путают понятия DevOps и админ. DevOps это как Big Data и как подростковый секс — все говорят что этим занимаются, но реально никто не знает что это такое.
+18
Те, кто осилил спеку [1] — всё знают, ибо растут эти понятия из пирамиды Cloud Computing: IaaS <=> PaaS <=> SaaS, где админы «продают» инфраструктуру девопсам, которые в свою очередь «продают» программистам среды и инструменты для разработки и исполнения приложений.
Драма заключается в том, что чем больше и сложнее сервис, тем более явно прослеживаются различия специализаций. Соответственно, чем меньше сервис, тем менее очевидны границы разделения обязанностей. Поэтому нет ничего удивительного в том, что в каких-то компаниях граница м/у админами и девопсам уж слишком размыта, а то и вообще отсутствует.
Под большими и маленькими сервисами не подразумевается количество кода или его сложность. Основной кейс тут один — распределенные вычисления. К слову, ведь именно из-за сложности в обслуживании распределенных софтовых сервисов, состоящих из кучи и тучи микросервисов, гугл и ввёл термин SRE, но многие почему-то неправильно трактуют понятие Site, или вообще его не трактуют.
[1] «The NIST Definition of Cloud Computing», http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
Драма заключается в том, что чем больше и сложнее сервис, тем более явно прослеживаются различия специализаций. Соответственно, чем меньше сервис, тем менее очевидны границы разделения обязанностей. Поэтому нет ничего удивительного в том, что в каких-то компаниях граница м/у админами и девопсам уж слишком размыта, а то и вообще отсутствует.
Под большими и маленькими сервисами не подразумевается количество кода или его сложность. Основной кейс тут один — распределенные вычисления. К слову, ведь именно из-за сложности в обслуживании распределенных софтовых сервисов, состоящих из кучи и тучи микросервисов, гугл и ввёл термин SRE, но многие почему-то неправильно трактуют понятие Site, или вообще его не трактуют.
[1] «The NIST Definition of Cloud Computing», http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
+1
в каких-то компаниях граница м/у админами и девопсам уж слишком размыта, а то и вообще отсутствует.
А в каких-то админы занимаются сетевой и серверной инфраструктурой, глобальными сторонними приложениями, мониторингом основных характеристик и т. п., а деплоем, конфигурированием и т. д. разработанных в компании продуктов занимаются разработчики. Ручками, самописными скриптами или сторонними тулзами.
0
Здесь я действительно многое писал с позиции скорее админа (operations). Я понимаю, что devops и админ — разные специальности, задачи и даже отчасти мышление. Идея статьи в том, чтобы показать многие конфликтные моменты, возникающие из непонимания того, где заканчивается development и начинается operations. Одна из задач devops — как раз в сглаживании таких «конфликтных» взаимодействий т.к. он должен обладать достаточной компетенцией в обеих сферах. И да, это не единственная и не основная из задач.
+3
> Я понимаю, что devops и админ — разные специальности, задачи
Нет, вы не понимаете, поэтому я и написал что вы не поняли суть концепции. Попробуйте в следующий раз хотя бы погуглить ключевые слова прежде чем писать статьи на хабр.
Нет, вы не понимаете, поэтому я и написал что вы не поняли суть концепции. Попробуйте в следующий раз хотя бы погуглить ключевые слова прежде чем писать статьи на хабр.
+1
А почему нельзя просто написать: «админ — это ..., девопс — это...»? Зачем устраивать вот эти советы в стиле «вы не поняли, попробуйте погуглить»?
+4
Потому что нет смысла это обсуждать с человеком, который вообще не знаком с темой.
operations — это профессия
devops — это методология взаимодейсвтия в компании
operations — это профессия
devops — это методология взаимодейсвтия в компании
-2
Ну явно человек под DevOps имеет в виду DevOps Engineer.
Хотите сказать, нет такой профессии?
Достаточно ли в теме вы сами?
Хотите сказать, нет такой профессии?
Достаточно ли в теме вы сами?
+1
То, что в какой-то момент Site Reliablity Engineer, Systems Engineer и прочие системные администраторы начали называться DevOps Engineer – это просто дань моде и некомпетенция как работодателей, так и самих работников(а на деле просто проблема нейминга)
Но по сколько DevOps это всего лишь одна из методологий, пусть даже и самая модная в наши дни – то DevOps Engineer звучит так же дико, как и Agile Engineer, Kanban Engineer или Waterfall Engineer.
Слушайте, 2015 год заканчивается уже, я думал все эти вопросы уже году так в 2011-2012 обсудили и закрыли этот холивар. Но нет же, с завидной регулярностью появляется кто-то, кто начинает рассказывать про инженеров DevOps.
Но по сколько DevOps это всего лишь одна из методологий, пусть даже и самая модная в наши дни – то DevOps Engineer звучит так же дико, как и Agile Engineer, Kanban Engineer или Waterfall Engineer.
Слушайте, 2015 год заканчивается уже, я думал все эти вопросы уже году так в 2011-2012 обсудили и закрыли этот холивар. Но нет же, с завидной регулярностью появляется кто-то, кто начинает рассказывать про инженеров DevOps.
+7
И разумеется это не единственная проблема статьи. Тяжело процитировать что тут не верно (как с т.з. методологии DevOps так и с т.з. здравого смысла) не цитируя всю статью. Поэтому совет в такой ситуации только 1 — гуглите.
-1
Вот автор статьи представляет компанию D., по сути обычную аутсорсинговую или аутстафинговую компанию (или как любят говорить в компании E. — «компанию, оказывающую сервисные услуги»).
У компании D. есть клиент — финансовая компания, или может быть какая-то корпорация, которая решила положится на экспертизу компании D. в вопросах разработки и сопровождения проекта, который они решили аутсорсить.
Сейлзы компании D., идя в ногу со временем знают, что в области системного администрирования есть серебряная пуля, DevOps инжинеры, которые продаются клиенту лучше и дороже чем обычные системные администраторы. Клиент тоже где-то слышал что DevOps это очень круто и сейчас в тренде (а если не слышал – заботливые сейлзы/архитекторы/кто-то еще из компании D. — обязательно расскажут что это именно так)
И в итоге на сайте украинского представительства компании D. сейчас висят две вакансии:
А теперь прочитайте содержимое спойлеров выше и скажите, чем описанные вакансии отличаются от того что делают системные администраторы.
У компании D. есть клиент — финансовая компания, или может быть какая-то корпорация, которая решила положится на экспертизу компании D. в вопросах разработки и сопровождения проекта, который они решили аутсорсить.
Сейлзы компании D., идя в ногу со временем знают, что в области системного администрирования есть серебряная пуля, DevOps инжинеры, которые продаются клиенту лучше и дороже чем обычные системные администраторы. Клиент тоже где-то слышал что DevOps это очень круто и сейчас в тренде (а если не слышал – заботливые сейлзы/архитекторы/кто-то еще из компании D. — обязательно расскажут что это именно так)
И в итоге на сайте украинского представительства компании D. сейчас висят две вакансии:
DEVOPS ENGINEER
Необходимые навыки:
- Конфигурационные инструменты (Chef/Puppet/Docker).
- Знание облачных инфраструктур, предпочтительно Amazon Web Services.
- Unix, Shell Script.
- Опыт работы с Jenkins, Nexus
- Система контроля версий: Git, SVN
- Базовое знание Java, Jboss, Maven.
- Централизированный сбор логов.
- Разговорный английский.
- Хорошие коммуникационные навыки.
CONFIGURATION MANAGER / DEVOPS ENGINEER
Обязанности:
- Устранение сложных технических проблем на всех уровнях технологического стека приложений.
- Восстановление и поддержание файловых систем, включая смены пароля, отключения сокетов приложения и другие внешние воздействия для защиты файлов производства. Способность контролировать процесс восстановления и устранения неполадок.
- Поддержание скриптов приложения, базы данных и среды ОС.
- Написание и запуск скриптов, анализирующих данные по нагрузочному тестированию в различных средах.
- Ответственность за поддержку основных сервисов инфраструктуры (LDAP, NIS, DNS, DHCP и т. д).
- Обратите внимание: позиция предполагает работу с 17 до 1 по Киеву.
А теперь прочитайте содержимое спойлеров выше и скажите, чем описанные вакансии отличаются от того что делают системные администраторы.
+4
Как программист, бывает, хожу по боевым серверам. Имею навыки администрирования серверов. Никто пока от этого не умер, кроме разве что нескольких багов, проявлявшихся только на бою. И кажется, что при определенном уровне ответственности и понимания того, что ты сейчас делаешь и как это может выйти боком, иметь доступ на бой не грешно, и поэтому не стоит всех девелоперов под одну гребенку :)
+16
Абсолютно согласен, сам такой же ;)
Но если брать в среднем по больнице, то топикстартер скорее прав — у большинства программистов тупо нет достаточного опыта в админстве, а как следствие на боевых серверах они ходят по типовым граблям.
Но если брать в среднем по больнице, то топикстартер скорее прав — у большинства программистов тупо нет достаточного опыта в админстве, а как следствие на боевых серверах они ходят по типовым граблям.
+4
Бывает разное, но если в конторе работает админ, то он должен заниматься серверами, а программисты должны программировать. А так если у вас возникают проблемы на боевых серваках, то решение по умолчанию становится проблемой и админов и программистов.
+1
Безусловно, говоря про поползновения на бой, я имею в виду только сервера приложений, которые пишутся мной и командой, в которой я работаю :) Как правило, туда в случае непредвиденных проблем проще и быстрее залезть самому, чем продираться сквозь бюрократию межкомандного взаимодействия. Но да, определенно не стоит это брать за постоянную практику — это для форс-мажоров.
0
Тут стоит разделять админов офисной инфраструктуры ( часто — просто support по факту) и админов «серверных» так сказать. Не всякий админ сможет корректно настроить инфраструктуру под большой проект, например.
+2
UFO just landed and posted this here
Для меня выглядит странным то, что программисты не хотят разбираться в чужом коде. Да большинство проектов на 80% из него состоит — фреймворки, библиотеки, копипаст из листов. Не изучая их, работать очень трудно, если вообще возможно, тем более что документация есть далеко не для всего.
+1
Тут дело в том, что это, оказывается, разный код. При разработке его можно потрогать, поиграть, проверить. А при багфиксах на продакшене такой возможности нет.
И это не говоря о специфике языковых конструкций и не очевидных хаков (которых быть не должно, но разве так бывает?)
И это не говоря о специфике языковых конструкций и не очевидных хаков (которых быть не должно, но разве так бывает?)
0
Библиотеки и фреймворки пишутся как раз для того чтоб конечному пользователю (разработчику) ненужно было в них разбираться, чтоб они могли не тратить время на разработку этого функционала а просто «прикрутили и забыли».
Вот чужой код который уже есть в проекте (например надо чужой проект доделать) — это да. Людям проще переписать всё с нуля чем разбираться :)
Вот чужой код который уже есть в проекте (например надо чужой проект доделать) — это да. Людям проще переписать всё с нуля чем разбираться :)
0
Ну если функционал и набор ошибок в библиотеке вас устраивает, то я вам завидую. Моё начальство постоянно хочет чего-нибудь в стиле «файловый менеджер с просмотрм raw и воспроизведением midi » — приходится форкать и допиливать уже существующее, каким бы ужасным код не казался. А вообще мне как-то по секрету сказали, что сторонний код пишут тоже не идиоты, и раз они сделали именно так, то на то были веские причины.
0
Здесь имелся в виду не разбор чужого кода (с ним, обычно, все неплохо), а задачи, связаные с конфигурированием уже написаных сервисов/систем. Это просто «непрофильная» задача для тех, кто привык писать код — сконфигурить что-то относительно сложное. Можно, но неудобно/неинтересно для мышления. «Написать свое» психологически проще.
Кстати, из этого во многом растут ноги у систем управления конфигурацией и вообще концепции infrastructure as a code.
Кстати, из этого во многом растут ноги у систем управления конфигурацией и вообще концепции infrastructure as a code.
+3
Здесь не рассмотрена довольно сложная проблемма взаимодействия разработчиков с админом.
В определённом смысле, здесь есть конфликт интересов. Если админа всё работает, потому он ничего не хочет менять. А программист постоянно эксперементирует что-то ставит, что-то удаляет.
На практике получается, что внедрить что-то на dev/stage становится сложнее: нужно убеждать админа это сделать, нужно убеждать админа сделать это именно сейчас, а не завтра. Отсюда получается падение производительности падает.
Со стороны это может выглдяеть как перестановка вагонов, на старом видео ( www.youtube.com/watch?v=23fBoqQxSgQ )
Но на самом деле эта «перестановка вагонов» даёт много информации нужной разработчикам.
В определённом смысле, здесь есть конфликт интересов. Если админа всё работает, потому он ничего не хочет менять. А программист постоянно эксперементирует что-то ставит, что-то удаляет.
На практике получается, что внедрить что-то на dev/stage становится сложнее: нужно убеждать админа это сделать, нужно убеждать админа сделать это именно сейчас, а не завтра. Отсюда получается падение производительности падает.
Со стороны это может выглдяеть как перестановка вагонов, на старом видео ( www.youtube.com/watch?v=23fBoqQxSgQ )
Но на самом деле эта «перестановка вагонов» даёт много информации нужной разработчикам.
0
Ну дык четыре стадии должно быть: experimental (каждому разработчику свой стек) -> testing (все фишки собираются вместе и тестируются вместе функционально) -> staging (сюда можно пускать небольшой объём прокрашеного трафика с реальными пользователями) -> production
+2
Это и есть тот конфликт development vs. operations, о котором было написано в начале статьи. Он рассмотрен огромное количество раз в разных источниках и с разных точек зрения. Здесь скорее рассмотрено его возможное решение в виде devops.
+2
Админы в этом плане похожи на тестировщиков. В принципе, программисты могут выполнять обязанности и тех, и тех, но нужен особый склад ума, чтобы делать это эффективно. Больше скурпулезности, въедливости и аккуратности.
+4
Скорее, больше опыта работы в соответствующей сфере.
Какая типовая задача админа? Сделать так, чтоб на моем компе работал инет, и чтоб было достаточно прав вот на те машины, и чтоб там блокировщиков порта ***** не было. Да, на стороне админов могут крутиться сервера, настраиваться маршрутизаторы, конфигурироваться файрволлы и еще куча всего, но это скорее способ достижения цели. Функция админа: чтоб все работало.
Функция тестировщика, утрируя: чтоб не было багов, читай, чтоб работало стабильно.
А какие функции у среднего\начинающего программиста в средней\большой конторе, этакого винтика в машине разработки? Чтоб был написан конкретный модуль (модули). Обратите внимание, модуль работал, а не «все». Про все остальное человек может и не знать, отгородившись интерфейсом. В итоге несколько лет человек может работать над конкретными модулями даже не задумываясь, как они связаны в систему.
Отсюда, частично, и возникает разница в складах ума. Скурпулезность, въедливость, аккуратность админов и тестировщиков обуславливается необходимостью выполнять свою админскую\тестерскую функцию; со временем эти качества превращаются в привычку.
У программистов другие функции, отсюда и другой склад ума, другие привычки.
Какая типовая задача админа? Сделать так, чтоб на моем компе работал инет, и чтоб было достаточно прав вот на те машины, и чтоб там блокировщиков порта ***** не было. Да, на стороне админов могут крутиться сервера, настраиваться маршрутизаторы, конфигурироваться файрволлы и еще куча всего, но это скорее способ достижения цели. Функция админа: чтоб все работало.
Функция тестировщика, утрируя: чтоб не было багов, читай, чтоб работало стабильно.
А какие функции у среднего\начинающего программиста в средней\большой конторе, этакого винтика в машине разработки? Чтоб был написан конкретный модуль (модули). Обратите внимание, модуль работал, а не «все». Про все остальное человек может и не знать, отгородившись интерфейсом. В итоге несколько лет человек может работать над конкретными модулями даже не задумываясь, как они связаны в систему.
Отсюда, частично, и возникает разница в складах ума. Скурпулезность, въедливость, аккуратность админов и тестировщиков обуславливается необходимостью выполнять свою админскую\тестерскую функцию; со временем эти качества превращаются в привычку.
С этим даже начинающий админ/DevOps справился бы на автомате, не особо задумываясь, зачем это надо. Просто «для порядка».
У программистов другие функции, отсюда и другой склад ума, другие привычки.
-2
Мне (программисту) приходится администрировать боевые сервера самостоятельно просто потому, что так повелось в нашей организации. Осознаю, что отдельный админ справился бы с этой задачей лучше, но пока всех всё устраивает: организации не надо платить зарплату отдельному человеку, а мне небольшой объем работ по администрированию позволяет делать это в охоточку, не погружаясь с головой.
0
Честно говоря, понимаю историю про логи, но все таки — есть инструменты автоматизации выкладки, старта всех нужных сервисов и так далее.
Хорошо написанный конфиг Capistrano снимает всю боль.
Админ нужен когда уж совсем распределенная и большая система
Хорошо написанный конфиг Capistrano снимает всю боль.
Админ нужен когда уж совсем распределенная и большая система
+1
deleted
0
Знакомый мечтает стать программистом, потому что это более упорядоченная работа и больше возможностей.
По крайней мере так выглядит с этой стороны :)
По крайней мере так выглядит с этой стороны :)
0
Как-то ниочём у вас получилось. Тема девопса не раскрыта.
+8
Не реализовать гибкую подсистему сбора логов в готовом продукте − это некомпетентность проектировщика. Не представлять, в какой среде будет работать программа, как могут распределиться нагрузки − это некомпетентность проектировщика. Разработать эзотерическую систему деплоя и/или не задокументировать её − некомпетентность проектировщика. По всему выходит, что девопс − это такой козёл отпущения, заполняющий дыры в компетентности разработчиков, пока их не накопится критическая масса.
Нет, не поймите меня неправильно − я думаю, что статьи по девопс очень нужны на Хабре. Но не такие.
Нет, не поймите меня неправильно − я думаю, что статьи по девопс очень нужны на Хабре. Но не такие.
0
Гибкая система сбора логов может быть реализована в проекте (хотя бы на уровне стороннего модуля), но сконфигурирована на продакшене как {type: stream, path: app/log/prod.log}, просто потому что разработчик не знает других параметров конфигурации на продакшене, а админ не знает о том, что приложение может писать куда угодно в каком угодно формате. Система может быть спроектирована как горизонтально масштабируемая, способная работать в рид-онли контейнерах с парой точек входа и выхода, но даже выделить под каждый компонент (например, веб-сервер, апп-сервер, субд) отдельной виртуалки не получается.
+1
Devops — носитель знания/понимания о двух сторонах: разработке и эксплуатации. Он не затыкает дыры, а, скорее, говорит, как можно их обойти в разработке и снизить влияние «необходимого зла» в эксплуатации. Этакий knowledge bridge. Соседний комментарий как раз про это.
Если же devops стал козлом отпущения — мне жаль, это говорит о неправильно построеной разработке.
Если же devops стал козлом отпущения — мне жаль, это говорит о неправильно построеной разработке.
+4
Конфликт есть, и должно быть соглашение как его преодолевать.
Как пример такого соглашения 12factor.net/ru — Двенадцатифакторное приложение.
Т.е. разработчики знают, что от них ожидают. А админы (по сути самые первые потребители продукта разработчиков) предлагают прозрачные и обоснованные ожидания.
Как пример такого соглашения 12factor.net/ru — Двенадцатифакторное приложение.
Т.е. разработчики знают, что от них ожидают. А админы (по сути самые первые потребители продукта разработчиков) предлагают прозрачные и обоснованные ожидания.
+3
на некоторых проектах(100-300 серверов) проходил путь описанный в статье, от анархии до все хорошо, что в итоге материала набралось на выступление на конференции местячковой. Стоит отметить, что процесс наведения порядка ооочень не быстрый, и легко может занимать полгода-год, и это в случае, если команда разработчиков готова изменениям.
Основной посыл, сформулировал бы так: если предоставить удобный механизм разработки, то конфликта не будет, а будет эффективный процесс обмена знаниями.
Основной посыл, сформулировал бы так: если предоставить удобный механизм разработки, то конфликта не будет, а будет эффективный процесс обмена знаниями.
0
Кто бы сказал моему начальству, что меня нельзя пускать на сервера :) В основном наши с админами обязанности по деплою наших приложений распределяются так: «мне нужен сервер с такой-то осью с таким-то виртуальным»железом"" — «на и делай что хочешь, только „железа“ много запросил, я чуть порезал», а проблемы типа переполнения диска или диких тормозов решаем вместе по мере поступления. А сначала выкручиваешься как можешь: подключаешь нестандартные репы, ставишь пакеты, правишь их конфиги, гуглишь бест-практайс, создаешь пользователей, пытаешься хоть как-то автоматизировать если не разворачивание с нуля, то хотя бы обновление однажды развернутого приложения из репозитория.
И да, чаще всего, автоматизируешь своим кодом, например, bash-скриптами, хранящимися лишь в хомяке своей учетки на сервере, и синхронизирующимися между серверами «по требованию» (когда очередной деплой не проходит нормально и вспоминаешь, что на другом сервере эту проблему уже решил). Хотелось бы сделать по уму, использовать всякие капистрано, чифы и докеры. Читаешь обзоры и гет-стартед туториалы — всё красиво. Начинаешь применять к практике — не влезает практика в обзоры и примеры типа «деплоим хелло-ворлд на машине разработчика под обычной учеткой» когда нужно разворачивать приложение минимум на двух голых машинах с использованием рут-привилегий. Наверняка подобные задачи решаются на раз-два, ничего сверхъестественного нет в наших процессах, но при условии обладания знаниями, которых за пару часов даже не нагуглить с нуля.
И да, чаще всего, автоматизируешь своим кодом, например, bash-скриптами, хранящимися лишь в хомяке своей учетки на сервере, и синхронизирующимися между серверами «по требованию» (когда очередной деплой не проходит нормально и вспоминаешь, что на другом сервере эту проблему уже решил). Хотелось бы сделать по уму, использовать всякие капистрано, чифы и докеры. Читаешь обзоры и гет-стартед туториалы — всё красиво. Начинаешь применять к практике — не влезает практика в обзоры и примеры типа «деплоим хелло-ворлд на машине разработчика под обычной учеткой» когда нужно разворачивать приложение минимум на двух голых машинах с использованием рут-привилегий. Наверняка подобные задачи решаются на раз-два, ничего сверхъестественного нет в наших процессах, но при условии обладания знаниями, которых за пару часов даже не нагуглить с нуля.
0
Да, и это — одна из задач devops.
-1
На самом деле в реальности, в большом сложном проекте, граница либо размыта, либо она на уровне компетенций, возможно, частей проекта.
Создание каких-то искуственных ограничений и разграничений обычно не приводит ни к чему хорошему, конечно это все касается адекватных людей а не «Каждый разработчик делает и коммитит все, что хочет». Инфрастуктура это часть проекта, и временами ее создание часть задачи программиста, т.к. ему близка бизнесовая часть и он знает что для нее нужно.
Вообщем-то программирование от кодерства отличатется тем, что программирование это не только написание некоего кода в IDE, а решение задач самыми подходящими способами, из которых писание кода может быть и не самым основным.
Создание каких-то искуственных ограничений и разграничений обычно не приводит ни к чему хорошему, конечно это все касается адекватных людей а не «Каждый разработчик делает и коммитит все, что хочет». Инфрастуктура это часть проекта, и временами ее создание часть задачи программиста, т.к. ему близка бизнесовая часть и он знает что для нее нужно.
Вообщем-то программирование от кодерства отличатется тем, что программирование это не только написание некоего кода в IDE, а решение задач самыми подходящими способами, из которых писание кода может быть и не самым основным.
0
UFO just landed and posted this here
Идея здравая: каждый должен заниматься своим делом. По своему опыту программиста могу сказать, что приходилось терять очень много времени на решение сугубо админских задач, например: разбираться с установкой нужных rpm-пакетов на сервере с разрабатываемой системой, настройкой спам-фильтров и т.п., на что у профессионального администратора ушло бы в 10 раз меньше времени. И необходимо построение четкой логики взаимодействия программистов и админов.
+1
Да просто бывают админы, которые живут в каком-то своем идеальном мире. И любое начинание разработичка для них как штык к горлу (или другая крайность — пусть творят что хотят, мое дело апач передернуть).
А бывают те, кто в состоянии говорить с программистами на одном языке, садиться и придумывать вместе какие-то решения.
Вот вторые — по сути и есть devops.
И когда такие люде в команде есть, энтропия проекта уменьшается. )))
А бывают те, кто в состоянии говорить с программистами на одном языке, садиться и придумывать вместе какие-то решения.
Вот вторые — по сути и есть devops.
И когда такие люде в команде есть, энтропия проекта уменьшается. )))
+1
Девопсы по сути те, кто встаёт между админами и разработчиками, кто говорит и с теми, и с другими на одном языке. В одних случаях эту роль (а это прежде всего роль в процессах) берут на себя админы (характерно для компаний, специализирующихся на разработке), в других — разработчики (характерно для компаний, где ИТ-службы лишь сервис для основного бизнеса, а про R&D вспоминают когда нужна новая фича), где-то она размазывается между ними (как правило на личных неформализованных отношениях), а в последнее время тренд на отдельную специализацию.
0
В последнее время, ребята, кто на собеседование приходят, почему-то вообще уверены, что devops это программист, который умеет CI делать. Так что черт его знает на что сейчас тренд ;-)
Главное просто понимать, что то, что тебе эксплуатировать — ребята в соседней комнате разрабатывают. И в ваших общих силах сделать жизнь друг-другу проще. Вот и все.
Главное просто понимать, что то, что тебе эксплуатировать — ребята в соседней комнате разрабатывают. И в ваших общих силах сделать жизнь друг-другу проще. Вот и все.
+1
Sign up to leave a comment.
Почему нельзя пускать программистов на сервера, или Почему девопсы еще не вымерли, хотя об этом много говорили