Комментарии 57
Теперь любой админ локалхоста, который осилил ansible считает себя devopsом, окей. Только суть концепции вы так и не уловили.
Ну вы же знаете почему так происходит :)
Recruiter reaction when putting DevOps as a skill in a public CV
В очередной раз путают понятия DevOps и админ. DevOps это как Big Data и как подростковый секс — все говорят что этим занимаются, но реально никто не знает что это такое.
Те, кто осилил спеку [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
в каких-то компаниях граница м/у админами и девопсам уж слишком размыта, а то и вообще отсутствует.
А в каких-то админы занимаются сетевой и серверной инфраструктурой, глобальными сторонними приложениями, мониторингом основных характеристик и т. п., а деплоем, конфигурированием и т. д. разработанных в компании продуктов занимаются разработчики. Ручками, самописными скриптами или сторонними тулзами.
Здесь я действительно многое писал с позиции скорее админа (operations). Я понимаю, что devops и админ — разные специальности, задачи и даже отчасти мышление. Идея статьи в том, чтобы показать многие конфликтные моменты, возникающие из непонимания того, где заканчивается development и начинается operations. Одна из задач devops — как раз в сглаживании таких «конфликтных» взаимодействий т.к. он должен обладать достаточной компетенцией в обеих сферах. И да, это не единственная и не основная из задач.
> Я понимаю, что devops и админ — разные специальности, задачи
Нет, вы не понимаете, поэтому я и написал что вы не поняли суть концепции. Попробуйте в следующий раз хотя бы погуглить ключевые слова прежде чем писать статьи на хабр.
Нет, вы не понимаете, поэтому я и написал что вы не поняли суть концепции. Попробуйте в следующий раз хотя бы погуглить ключевые слова прежде чем писать статьи на хабр.
А почему нельзя просто написать: «админ — это ..., девопс — это...»? Зачем устраивать вот эти советы в стиле «вы не поняли, попробуйте погуглить»?
Потому что нет смысла это обсуждать с человеком, который вообще не знаком с темой.
operations — это профессия
devops — это методология взаимодейсвтия в компании
operations — это профессия
devops — это методология взаимодейсвтия в компании
Ну явно человек под DevOps имеет в виду DevOps Engineer.
Хотите сказать, нет такой профессии?
Достаточно ли в теме вы сами?
Хотите сказать, нет такой профессии?
Достаточно ли в теме вы сами?
То, что в какой-то момент 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.
И разумеется это не единственная проблема статьи. Тяжело процитировать что тут не верно (как с т.з. методологии DevOps так и с т.з. здравого смысла) не цитируя всю статью. Поэтому совет в такой ситуации только 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 по Киеву.
А теперь прочитайте содержимое спойлеров выше и скажите, чем описанные вакансии отличаются от того что делают системные администраторы.
Как программист, бывает, хожу по боевым серверам. Имею навыки администрирования серверов. Никто пока от этого не умер, кроме разве что нескольких багов, проявлявшихся только на бою. И кажется, что при определенном уровне ответственности и понимания того, что ты сейчас делаешь и как это может выйти боком, иметь доступ на бой не грешно, и поэтому не стоит всех девелоперов под одну гребенку :)
Абсолютно согласен, сам такой же ;)
Но если брать в среднем по больнице, то топикстартер скорее прав — у большинства программистов тупо нет достаточного опыта в админстве, а как следствие на боевых серверах они ходят по типовым граблям.
Но если брать в среднем по больнице, то топикстартер скорее прав — у большинства программистов тупо нет достаточного опыта в админстве, а как следствие на боевых серверах они ходят по типовым граблям.
Бывает разное, но если в конторе работает админ, то он должен заниматься серверами, а программисты должны программировать. А так если у вас возникают проблемы на боевых серваках, то решение по умолчанию становится проблемой и админов и программистов.
Безусловно, говоря про поползновения на бой, я имею в виду только сервера приложений, которые пишутся мной и командой, в которой я работаю :) Как правило, туда в случае непредвиденных проблем проще и быстрее залезть самому, чем продираться сквозь бюрократию межкомандного взаимодействия. Но да, определенно не стоит это брать за постоянную практику — это для форс-мажоров.
Тут стоит разделять админов офисной инфраструктуры ( часто — просто support по факту) и админов «серверных» так сказать. Не всякий админ сможет корректно настроить инфраструктуру под большой проект, например.
НЛО прилетело и опубликовало эту надпись здесь
Для меня выглядит странным то, что программисты не хотят разбираться в чужом коде. Да большинство проектов на 80% из него состоит — фреймворки, библиотеки, копипаст из листов. Не изучая их, работать очень трудно, если вообще возможно, тем более что документация есть далеко не для всего.
Тут дело в том, что это, оказывается, разный код. При разработке его можно потрогать, поиграть, проверить. А при багфиксах на продакшене такой возможности нет.
И это не говоря о специфике языковых конструкций и не очевидных хаков (которых быть не должно, но разве так бывает?)
И это не говоря о специфике языковых конструкций и не очевидных хаков (которых быть не должно, но разве так бывает?)
Библиотеки и фреймворки пишутся как раз для того чтоб конечному пользователю (разработчику) ненужно было в них разбираться, чтоб они могли не тратить время на разработку этого функционала а просто «прикрутили и забыли».
Вот чужой код который уже есть в проекте (например надо чужой проект доделать) — это да. Людям проще переписать всё с нуля чем разбираться :)
Вот чужой код который уже есть в проекте (например надо чужой проект доделать) — это да. Людям проще переписать всё с нуля чем разбираться :)
Ну если функционал и набор ошибок в библиотеке вас устраивает, то я вам завидую. Моё начальство постоянно хочет чего-нибудь в стиле «файловый менеджер с просмотрм raw и воспроизведением midi » — приходится форкать и допиливать уже существующее, каким бы ужасным код не казался. А вообще мне как-то по секрету сказали, что сторонний код пишут тоже не идиоты, и раз они сделали именно так, то на то были веские причины.
Здесь имелся в виду не разбор чужого кода (с ним, обычно, все неплохо), а задачи, связаные с конфигурированием уже написаных сервисов/систем. Это просто «непрофильная» задача для тех, кто привык писать код — сконфигурить что-то относительно сложное. Можно, но неудобно/неинтересно для мышления. «Написать свое» психологически проще.
Кстати, из этого во многом растут ноги у систем управления конфигурацией и вообще концепции infrastructure as a code.
Кстати, из этого во многом растут ноги у систем управления конфигурацией и вообще концепции infrastructure as a code.
Здесь не рассмотрена довольно сложная проблемма взаимодействия разработчиков с админом.
В определённом смысле, здесь есть конфликт интересов. Если админа всё работает, потому он ничего не хочет менять. А программист постоянно эксперементирует что-то ставит, что-то удаляет.
На практике получается, что внедрить что-то на dev/stage становится сложнее: нужно убеждать админа это сделать, нужно убеждать админа сделать это именно сейчас, а не завтра. Отсюда получается падение производительности падает.
Со стороны это может выглдяеть как перестановка вагонов, на старом видео ( www.youtube.com/watch?v=23fBoqQxSgQ )
Но на самом деле эта «перестановка вагонов» даёт много информации нужной разработчикам.
В определённом смысле, здесь есть конфликт интересов. Если админа всё работает, потому он ничего не хочет менять. А программист постоянно эксперементирует что-то ставит, что-то удаляет.
На практике получается, что внедрить что-то на dev/stage становится сложнее: нужно убеждать админа это сделать, нужно убеждать админа сделать это именно сейчас, а не завтра. Отсюда получается падение производительности падает.
Со стороны это может выглдяеть как перестановка вагонов, на старом видео ( www.youtube.com/watch?v=23fBoqQxSgQ )
Но на самом деле эта «перестановка вагонов» даёт много информации нужной разработчикам.
Ну дык четыре стадии должно быть: experimental (каждому разработчику свой стек) -> testing (все фишки собираются вместе и тестируются вместе функционально) -> staging (сюда можно пускать небольшой объём прокрашеного трафика с реальными пользователями) -> production
Это и есть тот конфликт development vs. operations, о котором было написано в начале статьи. Он рассмотрен огромное количество раз в разных источниках и с разных точек зрения. Здесь скорее рассмотрено его возможное решение в виде devops.
Админы в этом плане похожи на тестировщиков. В принципе, программисты могут выполнять обязанности и тех, и тех, но нужен особый склад ума, чтобы делать это эффективно. Больше скурпулезности, въедливости и аккуратности.
Скорее, больше опыта работы в соответствующей сфере.
Какая типовая задача админа? Сделать так, чтоб на моем компе работал инет, и чтоб было достаточно прав вот на те машины, и чтоб там блокировщиков порта ***** не было. Да, на стороне админов могут крутиться сервера, настраиваться маршрутизаторы, конфигурироваться файрволлы и еще куча всего, но это скорее способ достижения цели. Функция админа: чтоб все работало.
Функция тестировщика, утрируя: чтоб не было багов, читай, чтоб работало стабильно.
А какие функции у среднего\начинающего программиста в средней\большой конторе, этакого винтика в машине разработки? Чтоб был написан конкретный модуль (модули). Обратите внимание, модуль работал, а не «все». Про все остальное человек может и не знать, отгородившись интерфейсом. В итоге несколько лет человек может работать над конкретными модулями даже не задумываясь, как они связаны в систему.
Отсюда, частично, и возникает разница в складах ума. Скурпулезность, въедливость, аккуратность админов и тестировщиков обуславливается необходимостью выполнять свою админскую\тестерскую функцию; со временем эти качества превращаются в привычку.
У программистов другие функции, отсюда и другой склад ума, другие привычки.
Какая типовая задача админа? Сделать так, чтоб на моем компе работал инет, и чтоб было достаточно прав вот на те машины, и чтоб там блокировщиков порта ***** не было. Да, на стороне админов могут крутиться сервера, настраиваться маршрутизаторы, конфигурироваться файрволлы и еще куча всего, но это скорее способ достижения цели. Функция админа: чтоб все работало.
Функция тестировщика, утрируя: чтоб не было багов, читай, чтоб работало стабильно.
А какие функции у среднего\начинающего программиста в средней\большой конторе, этакого винтика в машине разработки? Чтоб был написан конкретный модуль (модули). Обратите внимание, модуль работал, а не «все». Про все остальное человек может и не знать, отгородившись интерфейсом. В итоге несколько лет человек может работать над конкретными модулями даже не задумываясь, как они связаны в систему.
Отсюда, частично, и возникает разница в складах ума. Скурпулезность, въедливость, аккуратность админов и тестировщиков обуславливается необходимостью выполнять свою админскую\тестерскую функцию; со временем эти качества превращаются в привычку.
С этим даже начинающий админ/DevOps справился бы на автомате, не особо задумываясь, зачем это надо. Просто «для порядка».
У программистов другие функции, отсюда и другой склад ума, другие привычки.
Мне (программисту) приходится администрировать боевые сервера самостоятельно просто потому, что так повелось в нашей организации. Осознаю, что отдельный админ справился бы с этой задачей лучше, но пока всех всё устраивает: организации не надо платить зарплату отдельному человеку, а мне небольшой объем работ по администрированию позволяет делать это в охоточку, не погружаясь с головой.
Честно говоря, понимаю историю про логи, но все таки — есть инструменты автоматизации выкладки, старта всех нужных сервисов и так далее.
Хорошо написанный конфиг Capistrano снимает всю боль.
Админ нужен когда уж совсем распределенная и большая система
Хорошо написанный конфиг Capistrano снимает всю боль.
Админ нужен когда уж совсем распределенная и большая система
deleted
Знакомый мечтает стать программистом, потому что это более упорядоченная работа и больше возможностей.
По крайней мере так выглядит с этой стороны :)
По крайней мере так выглядит с этой стороны :)
Как-то ниочём у вас получилось. Тема девопса не раскрыта.
Не реализовать гибкую подсистему сбора логов в готовом продукте − это некомпетентность проектировщика. Не представлять, в какой среде будет работать программа, как могут распределиться нагрузки − это некомпетентность проектировщика. Разработать эзотерическую систему деплоя и/или не задокументировать её − некомпетентность проектировщика. По всему выходит, что девопс − это такой козёл отпущения, заполняющий дыры в компетентности разработчиков, пока их не накопится критическая масса.
Нет, не поймите меня неправильно − я думаю, что статьи по девопс очень нужны на Хабре. Но не такие.
Нет, не поймите меня неправильно − я думаю, что статьи по девопс очень нужны на Хабре. Но не такие.
Гибкая система сбора логов может быть реализована в проекте (хотя бы на уровне стороннего модуля), но сконфигурирована на продакшене как {type: stream, path: app/log/prod.log}, просто потому что разработчик не знает других параметров конфигурации на продакшене, а админ не знает о том, что приложение может писать куда угодно в каком угодно формате. Система может быть спроектирована как горизонтально масштабируемая, способная работать в рид-онли контейнерах с парой точек входа и выхода, но даже выделить под каждый компонент (например, веб-сервер, апп-сервер, субд) отдельной виртуалки не получается.
Devops — носитель знания/понимания о двух сторонах: разработке и эксплуатации. Он не затыкает дыры, а, скорее, говорит, как можно их обойти в разработке и снизить влияние «необходимого зла» в эксплуатации. Этакий knowledge bridge. Соседний комментарий как раз про это.
Если же devops стал козлом отпущения — мне жаль, это говорит о неправильно построеной разработке.
Если же devops стал козлом отпущения — мне жаль, это говорит о неправильно построеной разработке.
Конфликт есть, и должно быть соглашение как его преодолевать.
Как пример такого соглашения 12factor.net/ru — Двенадцатифакторное приложение.
Т.е. разработчики знают, что от них ожидают. А админы (по сути самые первые потребители продукта разработчиков) предлагают прозрачные и обоснованные ожидания.
Как пример такого соглашения 12factor.net/ru — Двенадцатифакторное приложение.
Т.е. разработчики знают, что от них ожидают. А админы (по сути самые первые потребители продукта разработчиков) предлагают прозрачные и обоснованные ожидания.
на некоторых проектах(100-300 серверов) проходил путь описанный в статье, от анархии до все хорошо, что в итоге материала набралось на выступление на конференции местячковой. Стоит отметить, что процесс наведения порядка ооочень не быстрый, и легко может занимать полгода-год, и это в случае, если команда разработчиков готова изменениям.
Основной посыл, сформулировал бы так: если предоставить удобный механизм разработки, то конфликта не будет, а будет эффективный процесс обмена знаниями.
Основной посыл, сформулировал бы так: если предоставить удобный механизм разработки, то конфликта не будет, а будет эффективный процесс обмена знаниями.
Кто бы сказал моему начальству, что меня нельзя пускать на сервера :) В основном наши с админами обязанности по деплою наших приложений распределяются так: «мне нужен сервер с такой-то осью с таким-то виртуальным»железом"" — «на и делай что хочешь, только „железа“ много запросил, я чуть порезал», а проблемы типа переполнения диска или диких тормозов решаем вместе по мере поступления. А сначала выкручиваешься как можешь: подключаешь нестандартные репы, ставишь пакеты, правишь их конфиги, гуглишь бест-практайс, создаешь пользователей, пытаешься хоть как-то автоматизировать если не разворачивание с нуля, то хотя бы обновление однажды развернутого приложения из репозитория.
И да, чаще всего, автоматизируешь своим кодом, например, bash-скриптами, хранящимися лишь в хомяке своей учетки на сервере, и синхронизирующимися между серверами «по требованию» (когда очередной деплой не проходит нормально и вспоминаешь, что на другом сервере эту проблему уже решил). Хотелось бы сделать по уму, использовать всякие капистрано, чифы и докеры. Читаешь обзоры и гет-стартед туториалы — всё красиво. Начинаешь применять к практике — не влезает практика в обзоры и примеры типа «деплоим хелло-ворлд на машине разработчика под обычной учеткой» когда нужно разворачивать приложение минимум на двух голых машинах с использованием рут-привилегий. Наверняка подобные задачи решаются на раз-два, ничего сверхъестественного нет в наших процессах, но при условии обладания знаниями, которых за пару часов даже не нагуглить с нуля.
И да, чаще всего, автоматизируешь своим кодом, например, bash-скриптами, хранящимися лишь в хомяке своей учетки на сервере, и синхронизирующимися между серверами «по требованию» (когда очередной деплой не проходит нормально и вспоминаешь, что на другом сервере эту проблему уже решил). Хотелось бы сделать по уму, использовать всякие капистрано, чифы и докеры. Читаешь обзоры и гет-стартед туториалы — всё красиво. Начинаешь применять к практике — не влезает практика в обзоры и примеры типа «деплоим хелло-ворлд на машине разработчика под обычной учеткой» когда нужно разворачивать приложение минимум на двух голых машинах с использованием рут-привилегий. Наверняка подобные задачи решаются на раз-два, ничего сверхъестественного нет в наших процессах, но при условии обладания знаниями, которых за пару часов даже не нагуглить с нуля.
Да, и это — одна из задач devops.
На самом деле в реальности, в большом сложном проекте, граница либо размыта, либо она на уровне компетенций, возможно, частей проекта.
Создание каких-то искуственных ограничений и разграничений обычно не приводит ни к чему хорошему, конечно это все касается адекватных людей а не «Каждый разработчик делает и коммитит все, что хочет». Инфрастуктура это часть проекта, и временами ее создание часть задачи программиста, т.к. ему близка бизнесовая часть и он знает что для нее нужно.
Вообщем-то программирование от кодерства отличатется тем, что программирование это не только написание некоего кода в IDE, а решение задач самыми подходящими способами, из которых писание кода может быть и не самым основным.
Создание каких-то искуственных ограничений и разграничений обычно не приводит ни к чему хорошему, конечно это все касается адекватных людей а не «Каждый разработчик делает и коммитит все, что хочет». Инфрастуктура это часть проекта, и временами ее создание часть задачи программиста, т.к. ему близка бизнесовая часть и он знает что для нее нужно.
Вообщем-то программирование от кодерства отличатется тем, что программирование это не только написание некоего кода в IDE, а решение задач самыми подходящими способами, из которых писание кода может быть и не самым основным.
НЛО прилетело и опубликовало эту надпись здесь
Идея здравая: каждый должен заниматься своим делом. По своему опыту программиста могу сказать, что приходилось терять очень много времени на решение сугубо админских задач, например: разбираться с установкой нужных rpm-пакетов на сервере с разрабатываемой системой, настройкой спам-фильтров и т.п., на что у профессионального администратора ушло бы в 10 раз меньше времени. И необходимо построение четкой логики взаимодействия программистов и админов.
Да просто бывают админы, которые живут в каком-то своем идеальном мире. И любое начинание разработичка для них как штык к горлу (или другая крайность — пусть творят что хотят, мое дело апач передернуть).
А бывают те, кто в состоянии говорить с программистами на одном языке, садиться и придумывать вместе какие-то решения.
Вот вторые — по сути и есть devops.
И когда такие люде в команде есть, энтропия проекта уменьшается. )))
А бывают те, кто в состоянии говорить с программистами на одном языке, садиться и придумывать вместе какие-то решения.
Вот вторые — по сути и есть devops.
И когда такие люде в команде есть, энтропия проекта уменьшается. )))
Девопсы по сути те, кто встаёт между админами и разработчиками, кто говорит и с теми, и с другими на одном языке. В одних случаях эту роль (а это прежде всего роль в процессах) берут на себя админы (характерно для компаний, специализирующихся на разработке), в других — разработчики (характерно для компаний, где ИТ-службы лишь сервис для основного бизнеса, а про R&D вспоминают когда нужна новая фича), где-то она размазывается между ними (как правило на личных неформализованных отношениях), а в последнее время тренд на отдельную специализацию.
В последнее время, ребята, кто на собеседование приходят, почему-то вообще уверены, что devops это программист, который умеет CI делать. Так что черт его знает на что сейчас тренд ;-)
Главное просто понимать, что то, что тебе эксплуатировать — ребята в соседней комнате разрабатывают. И в ваших общих силах сделать жизнь друг-другу проще. Вот и все.
Главное просто понимать, что то, что тебе эксплуатировать — ребята в соседней комнате разрабатывают. И в ваших общих силах сделать жизнь друг-другу проще. Вот и все.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему нельзя пускать программистов на сервера, или Почему девопсы еще не вымерли, хотя об этом много говорили