Привет, Хабр!
Сегодня у нас необычный материал. Мы не будем публиковать туториал или рассматривать новые фреймворки, а просто дадим слово коллеге, которому есть, что сказать.
Мнение автора может не отражать позицию компании и других коллег.
Знакомьтесь — Александр Ефимов, Configuration manager/DevOps
Есть у меня знакомый, который, будучи первоклассным сисадмином, мечтает стать программистом. По его словам, хочет творить, а не использовать уже существующий… не очень хороший софт. В чем-то я его понимаю: «чистое» творчество — безусловно, круто. Но давайте разберемся, что и как происходит на самом деле.
Я уже достаточно долгое время работаю девопсом. Проекты, в которых я имел честь участвовать, неизбежно проходили примерно следующие фазы:
- Анархия. Каждый разработчик делает и коммитит все, что хочет (во всяком случае, так это видится стороннему наблюдателю). В конце спринта «самый виноватый» собирает все наработки в некоего кадавра, работающего на его машине и (теоретически) на каком-то из серверов. Потом, проходя круги боли и ада, это внедряется на сервера и как-то там работает.
- «На стейджинге работает». Наконец-то заказчик выделил деньги на один сервер стейджинга. Теперь ад со сборкой работающего прототипа повторяется еще и для стейджинга. Пикантность ситуации в том, что вся «обвязка» в виде БД, сервера очередей, кеш-сервера и прочего живет на localhost. Т. е. получаем ту же машину разработчика, только удаленно. Со всеми выводами типа хардкодинга части sensitive параметров соединений.
- Нам нужен какой-нибудь админ. На этом этапе все, сотворенное ранее, уже стало неуправляемым, стейджингу плохо, продакшен не обновляется. Тут и приходит кто-то, кого назовут DevOps, и начинает разгребать бардак и раздавать именные
пенделисредства мотивации. Если вообще приходит.
Вот мы и подошли к самому главному — конфликту Development и Operations. Он уже со всех сторон рассмотрен и обмусолен и вкратце выглядит вот так:
Далее я попытаюсь объяснить, почему для меня решение этого конфликта вынесено в заголовок статьи.
Творчество vs. порядок
Разработка ПО — творческий процесс. Управление творческим процессом предполагает гибкость и умение не мешать. Собственно, методология Agile растет именно из этого: ее цель — управлять хаосом, минимально его упорядочивая. И это, по-моему, действительно хорошо: при правильно сделанном Agile получается неплохой продукт.
Эксплуатация же, напротив, требует абсолютно четкого знания обо всех элементах системы, конфигурациях, потенциальных точках нестабильности и т. п. Здесь властвует ITIL и ему подобные методологии.
Разработчики в принципе не заточены упорядочивать все стратегически — это просто не их профиль. Более того, большинство просто не задумывается о некоторых мелочах, которые потом могут привести к большим последствиям.
Пример из жизни. Допустим, по умолчанию log-файлы лежат в директории приложения. Разработчикам это удобно: всегда знаешь, куда смотреть. Разработчик разворачивает приложение на тестовом сервере. Через три дня диск сервера переполнен, сервер очередей упал, БД орет в свои логи о том, что писать некуда. Ничего не работает, demo через три часа, все в шоке. А причина проста: надо было переложить логи в специальный раздел и/или настроить ротацию. С этим даже начинающий админ/DevOps справился бы на автомате, не особо задумываясь, зачем это надо. Просто «для порядка».
Умение пользоваться существующими решениями
Когда я впервые начал работать в компании, разрабатывающей ПО (в той компании — для внутреннего использования), меня удивила их система мониторинга. Она была самописной и невероятно глючной. В 2009 году. Отделу инфраструктуры пришлось пройти через многое, чтобы убедить начальство, что надо внедрить Zabbix.
С подобными проблемами я сталкивался еще несколько раз в разных компаниях, и везде было одно и то же: «нам проще написать свое, чем разбираться в чужом». Уже позже я понял причину подобного образа мыслей: разработчикам действительно проще разрабатывать. Это админы привыкли копаться в конфигах, «снюхивая» несколько систем в единую. Иногда через параметры, иногда скриптами, иногда — и тем, и другим. А разработчику проще написать 100 строк кода, чем разбираться в документации и конфигах.
Вообще, здесь конфликт подходов очень остро заметен. Админ не полезет в код, пока не припечет, точно так же как девелопер не полезет в конфиги.
Разница компетенций
Отчасти это следует из вышесказанного, но факт остается фактом: сисадмин/DevOps и программист/девелопер имеют абсолютно разные компетенции.
Программист сможет настроить сервер. Наверное. Но он вряд ли станет учитывать неочевидные для него потенциальные проблемы и решать их сразу. То же касается инфраструктуры: девелопер просто не будет в ней разбираться и сделает все «по умолчанию» + по советам со StackOverflow.
Пример из жизни. На одном из предыдущих мест работы, в небольшой софтовой компании, я столкнулся с вопросом начальства «а зачем нам админы/DevOps?». И действительно, они в упор не понимали, что же делает системный администратор. IP-адресация в их локальной сети была из Internet-диапазона (благо, эта подсеть принадлежала какому-то из американских провайдеров домашнего интернет-доступа). Использовались коммутаторы-«мыльницы» и обычный «домашний» маршрутизатор для доступа в Internet. Эти люди разрабатывали весьма серьезную распределенную систему (не скажу чего), пытаясь сделать ее отказоустойчивой. Через примерно полгода разработки осознание, что надо, все же, нанять кого-то, разбирающегося в серверном оборудовании и ОС, победило.
Заключение и выводы
По-моему, разделение сфер влияния — это прекрасно. Можно быть сколь угодно универсальным «сферическим айтишником в вакууме», но всего не успеешь никак. Именно поэтому девелоперы разрабатывают ПО, а админы — создают и управляют инфраструктурой и этим же ПО.
Программистов нельзя пускать на сервера не потому, что они плохие, а потому, что это не их забота. Для этого есть девопс — «чужой среди своих», человек-админ в стане девелоперов, адаптировавшийся к хаосу и создавший в нем странный порядок, называемый кучей словосочетаний с Continuous (Continuous Integration/Deployment/Delivery/Operation).
Поэтому, уважаемые программисты, девелоперы, архитекторы, не обижайтесь, если вам приснится поздно ночью бородатый мужик в свитере с упреком «опять вы формат конфига изменили, а у меня деплой упал».
А вы, уважаемые девопсы и админы, будьте терпимее к разработчикам. Они постоянно ищут новые, лучшие решения. Из-за этого их работа напоминает хаос, но содержит высший порядок.
Но на сервера их все равно не пускайте.
ptQa
Теперь любой админ локалхоста, который осилил ansible считает себя devopsом, окей. Только суть концепции вы так и не уловили.
m0s
Ну вы же знаете почему так происходит :)
stan_jeremy
В очередной раз путают понятия DevOps и админ. DevOps это как Big Data и как подростковый секс — все говорят что этим занимаются, но реально никто не знает что это такое.
romangoward
Те, кто осилил спеку [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
VolCh
А в каких-то админы занимаются сетевой и серверной инфраструктурой, глобальными сторонними приложениями, мониторингом основных характеристик и т. п., а деплоем, конфигурированием и т. д. разработанных в компании продуктов занимаются разработчики. Ручками, самописными скриптами или сторонними тулзами.
deadroot
Здесь я действительно многое писал с позиции скорее админа (operations). Я понимаю, что devops и админ — разные специальности, задачи и даже отчасти мышление. Идея статьи в том, чтобы показать многие конфликтные моменты, возникающие из непонимания того, где заканчивается development и начинается operations. Одна из задач devops — как раз в сглаживании таких «конфликтных» взаимодействий т.к. он должен обладать достаточной компетенцией в обеих сферах. И да, это не единственная и не основная из задач.
ptQa
> Я понимаю, что devops и админ — разные специальности, задачи
Нет, вы не понимаете, поэтому я и написал что вы не поняли суть концепции. Попробуйте в следующий раз хотя бы погуглить ключевые слова прежде чем писать статьи на хабр.
vogre
А почему нельзя просто написать: «админ — это ..., девопс — это...»? Зачем устраивать вот эти советы в стиле «вы не поняли, попробуйте погуглить»?
ptQa
Потому что нет смысла это обсуждать с человеком, который вообще не знаком с темой.
operations — это профессия
devops — это методология взаимодейсвтия в компании
vogre
Ну явно человек под DevOps имеет в виду DevOps Engineer.
Хотите сказать, нет такой профессии?
Достаточно ли в теме вы сами?
m0s
То, что в какой-то момент Site Reliablity Engineer, Systems Engineer и прочие системные администраторы начали называться DevOps Engineer – это просто дань моде и некомпетенция как работодателей, так и самих работников(а на деле просто проблема нейминга)
Но по сколько DevOps это всего лишь одна из методологий, пусть даже и самая модная в наши дни – то DevOps Engineer звучит так же дико, как и Agile Engineer, Kanban Engineer или Waterfall Engineer.
Слушайте, 2015 год заканчивается уже, я думал все эти вопросы уже году так в 2011-2012 обсудили и закрыли этот холивар. Но нет же, с завидной регулярностью появляется кто-то, кто начинает рассказывать про инженеров DevOps.
Ipeacocks
Более того, все вакансии теперь называются «DevOps».
navion
У кого как, а у IBM есть четкое разделение между development и operations в их продукте для configuration management.
ptQa
И разумеется это не единственная проблема статьи. Тяжело процитировать что тут не верно (как с т.з. методологии DevOps так и с т.з. здравого смысла) не цитируя всю статью. Поэтому совет в такой ситуации только 1 — гуглите.
m0s
Вот автор статьи представляет компанию D., по сути обычную аутсорсинговую или аутстафинговую компанию (или как любят говорить в компании E. — «компанию, оказывающую сервисные услуги»).
У компании D. есть клиент — финансовая компания, или может быть какая-то корпорация, которая решила положится на экспертизу компании D. в вопросах разработки и сопровождения проекта, который они решили аутсорсить.
Сейлзы компании D., идя в ногу со временем знают, что в области системного администрирования есть серебряная пуля, DevOps инжинеры, которые продаются клиенту лучше и дороже чем обычные системные администраторы. Клиент тоже где-то слышал что DevOps это очень круто и сейчас в тренде (а если не слышал – заботливые сейлзы/архитекторы/кто-то еще из компании D. — обязательно расскажут что это именно так)
И в итоге на сайте украинского представительства компании D. сейчас висят две вакансии:
heilage
Как программист, бывает, хожу по боевым серверам. Имею навыки администрирования серверов. Никто пока от этого не умер, кроме разве что нескольких багов, проявлявшихся только на бою. И кажется, что при определенном уровне ответственности и понимания того, что ты сейчас делаешь и как это может выйти боком, иметь доступ на бой не грешно, и поэтому не стоит всех девелоперов под одну гребенку :)
magnitudo
Абсолютно согласен, сам такой же ;)
Но если брать в среднем по больнице, то топикстартер скорее прав — у большинства программистов тупо нет достаточного опыта в админстве, а как следствие на боевых серверах они ходят по типовым граблям.
but
Бывает разное, но если в конторе работает админ, то он должен заниматься серверами, а программисты должны программировать. А так если у вас возникают проблемы на боевых серваках, то решение по умолчанию становится проблемой и админов и программистов.
heilage
Безусловно, говоря про поползновения на бой, я имею в виду только сервера приложений, которые пишутся мной и командой, в которой я работаю :) Как правило, туда в случае непредвиденных проблем проще и быстрее залезть самому, чем продираться сквозь бюрократию межкомандного взаимодействия. Но да, определенно не стоит это брать за постоянную практику — это для форс-мажоров.
deadroot
Тут стоит разделять админов офисной инфраструктуры ( часто — просто support по факту) и админов «серверных» так сказать. Не всякий админ сможет корректно настроить инфраструктуру под большой проект, например.
traaance
Это не страшно. Но надо понимать, что это должно быть осознанное решение реально необходимое в конкретной ситуации. Также как летчики или хирурги произносят все свои действия в слух… ;)
TyVik
Для меня выглядит странным то, что программисты не хотят разбираться в чужом коде. Да большинство проектов на 80% из него состоит — фреймворки, библиотеки, копипаст из листов. Не изучая их, работать очень трудно, если вообще возможно, тем более что документация есть далеко не для всего.
Sild
Тут дело в том, что это, оказывается, разный код. При разработке его можно потрогать, поиграть, проверить. А при багфиксах на продакшене такой возможности нет.
И это не говоря о специфике языковых конструкций и не очевидных хаков (которых быть не должно, но разве так бывает?)
Caravus
Библиотеки и фреймворки пишутся как раз для того чтоб конечному пользователю (разработчику) ненужно было в них разбираться, чтоб они могли не тратить время на разработку этого функционала а просто «прикрутили и забыли».
Вот чужой код который уже есть в проекте (например надо чужой проект доделать) — это да. Людям проще переписать всё с нуля чем разбираться :)
TyVik
Ну если функционал и набор ошибок в библиотеке вас устраивает, то я вам завидую. Моё начальство постоянно хочет чего-нибудь в стиле «файловый менеджер с просмотрм raw и воспроизведением midi » — приходится форкать и допиливать уже существующее, каким бы ужасным код не казался. А вообще мне как-то по секрету сказали, что сторонний код пишут тоже не идиоты, и раз они сделали именно так, то на то были веские причины.
Caravus
Я пишу на достаточно высокоуровневом языке… мне форкать не приходится, ООП — наше всё…
deadroot
Здесь имелся в виду не разбор чужого кода (с ним, обычно, все неплохо), а задачи, связаные с конфигурированием уже написаных сервисов/систем. Это просто «непрофильная» задача для тех, кто привык писать код — сконфигурить что-то относительно сложное. Можно, но неудобно/неинтересно для мышления. «Написать свое» психологически проще.
Кстати, из этого во многом растут ноги у систем управления конфигурацией и вообще концепции infrastructure as a code.
musuk
Здесь не рассмотрена довольно сложная проблемма взаимодействия разработчиков с админом.
В определённом смысле, здесь есть конфликт интересов. Если админа всё работает, потому он ничего не хочет менять. А программист постоянно эксперементирует что-то ставит, что-то удаляет.
На практике получается, что внедрить что-то на dev/stage становится сложнее: нужно убеждать админа это сделать, нужно убеждать админа сделать это именно сейчас, а не завтра. Отсюда получается падение производительности падает.
Со стороны это может выглдяеть как перестановка вагонов, на старом видео ( www.youtube.com/watch?v=23fBoqQxSgQ )
Но на самом деле эта «перестановка вагонов» даёт много информации нужной разработчикам.
librarian
Ну дык четыре стадии должно быть: experimental (каждому разработчику свой стек) -> testing (все фишки собираются вместе и тестируются вместе функционально) -> staging (сюда можно пускать небольшой объём прокрашеного трафика с реальными пользователями) -> production
deadroot
Это и есть тот конфликт development vs. operations, о котором было написано в начале статьи. Он рассмотрен огромное количество раз в разных источниках и с разных точек зрения. Здесь скорее рассмотрено его возможное решение в виде devops.
Scf
Админы в этом плане похожи на тестировщиков. В принципе, программисты могут выполнять обязанности и тех, и тех, но нужен особый склад ума, чтобы делать это эффективно. Больше скурпулезности, въедливости и аккуратности.
Oxoron
Скорее, больше опыта работы в соответствующей сфере.
Какая типовая задача админа? Сделать так, чтоб на моем компе работал инет, и чтоб было достаточно прав вот на те машины, и чтоб там блокировщиков порта ***** не было. Да, на стороне админов могут крутиться сервера, настраиваться маршрутизаторы, конфигурироваться файрволлы и еще куча всего, но это скорее способ достижения цели. Функция админа: чтоб все работало.
Функция тестировщика, утрируя: чтоб не было багов, читай, чтоб работало стабильно.
А какие функции у среднего\начинающего программиста в средней\большой конторе, этакого винтика в машине разработки? Чтоб был написан конкретный модуль (модули). Обратите внимание, модуль работал, а не «все». Про все остальное человек может и не знать, отгородившись интерфейсом. В итоге несколько лет человек может работать над конкретными модулями даже не задумываясь, как они связаны в систему.
Отсюда, частично, и возникает разница в складах ума. Скурпулезность, въедливость, аккуратность админов и тестировщиков обуславливается необходимостью выполнять свою админскую\тестерскую функцию; со временем эти качества превращаются в привычку.
У программистов другие функции, отсюда и другой склад ума, другие привычки.
VolCh
Не думаю, что какие-то другие функции. Всем надо, чтобы всё работало, а если не работает, то как можно оперативнее и точнее информировало что и где не работает. Другие не функции, а их «аргументы».
dstarcev
Мне (программисту) приходится администрировать боевые сервера самостоятельно просто потому, что так повелось в нашей организации. Осознаю, что отдельный админ справился бы с этой задачей лучше, но пока всех всё устраивает: организации не надо платить зарплату отдельному человеку, а мне небольшой объем работ по администрированию позволяет делать это в охоточку, не погружаясь с головой.
Mox
Честно говоря, понимаю историю про логи, но все таки — есть инструменты автоматизации выкладки, старта всех нужных сервисов и так далее.
Хорошо написанный конфиг Capistrano снимает всю боль.
Админ нужен когда уж совсем распределенная и большая система
deadroot
Дело в том, что часто народ просто-напросто не задумывается о том, в какой среде и как будет работать софт. При использовании любых средств управления конфигурацией, оркестрации и т.п. все равно в первую очередь надо продумывать, что и как будет работать.
stan_jeremy
deleted
catharsis
Знакомый мечтает стать программистом, потому что это более упорядоченная работа и больше возможностей.
По крайней мере так выглядит с этой стороны :)
deadroot
И поэтому тоже, но главное (с его слов) — больше свободы творчества.
mezastel
Как-то ниочём у вас получилось. Тема девопса не раскрыта.
Tanner
Не реализовать гибкую подсистему сбора логов в готовом продукте ? это некомпетентность проектировщика. Не представлять, в какой среде будет работать программа, как могут распределиться нагрузки ? это некомпетентность проектировщика. Разработать эзотерическую систему деплоя и/или не задокументировать её ? некомпетентность проектировщика. По всему выходит, что девопс ? это такой козёл отпущения, заполняющий дыры в компетентности разработчиков, пока их не накопится критическая масса.
Нет, не поймите меня неправильно ? я думаю, что статьи по девопс очень нужны на Хабре. Но не такие.
VolCh
Гибкая система сбора логов может быть реализована в проекте (хотя бы на уровне стороннего модуля), но сконфигурирована на продакшене как {type: stream, path: app/log/prod.log}, просто потому что разработчик не знает других параметров конфигурации на продакшене, а админ не знает о том, что приложение может писать куда угодно в каком угодно формате. Система может быть спроектирована как горизонтально масштабируемая, способная работать в рид-онли контейнерах с парой точек входа и выхода, но даже выделить под каждый компонент (например, веб-сервер, апп-сервер, субд) отдельной виртуалки не получается.
deadroot
Devops — носитель знания/понимания о двух сторонах: разработке и эксплуатации. Он не затыкает дыры, а, скорее, говорит, как можно их обойти в разработке и снизить влияние «необходимого зла» в эксплуатации. Этакий knowledge bridge. Соседний комментарий как раз про это.
Если же devops стал козлом отпущения — мне жаль, это говорит о неправильно построеной разработке.
antirek
Конфликт есть, и должно быть соглашение как его преодолевать.
Как пример такого соглашения 12factor.net/ru — Двенадцатифакторное приложение.
Т.е. разработчики знают, что от них ожидают. А админы (по сути самые первые потребители продукта разработчиков) предлагают прозрачные и обоснованные ожидания.
deadroot
Да, соглашение должно быть и должно вырабатываться всеми сторонами процесса. Пример мне нравится, кстати: фокус на управляемости и повторяемости всех этапов. Спасибо.
ultral
на некоторых проектах(100-300 серверов) проходил путь описанный в статье, от анархии до все хорошо, что в итоге материала набралось на выступление на конференции местячковой. Стоит отметить, что процесс наведения порядка ооочень не быстрый, и легко может занимать полгода-год, и это в случае, если команда разработчиков готова изменениям.
Основной посыл, сформулировал бы так: если предоставить удобный механизм разработки, то конфликта не будет, а будет эффективный процесс обмена знаниями.
deadroot
Очень часто механизм разработки формируется только разработчиками. А devops или тот, кто выполняет его обязанности, приходит позже. Так что да, зачастую приходится перестраивать процессы очень сильно.
VolCh
Кто бы сказал моему начальству, что меня нельзя пускать на сервера :) В основном наши с админами обязанности по деплою наших приложений распределяются так: «мне нужен сервер с такой-то осью с таким-то виртуальным»железом"" — «на и делай что хочешь, только „железа“ много запросил, я чуть порезал», а проблемы типа переполнения диска или диких тормозов решаем вместе по мере поступления. А сначала выкручиваешься как можешь: подключаешь нестандартные репы, ставишь пакеты, правишь их конфиги, гуглишь бест-практайс, создаешь пользователей, пытаешься хоть как-то автоматизировать если не разворачивание с нуля, то хотя бы обновление однажды развернутого приложения из репозитория.
И да, чаще всего, автоматизируешь своим кодом, например, bash-скриптами, хранящимися лишь в хомяке своей учетки на сервере, и синхронизирующимися между серверами «по требованию» (когда очередной деплой не проходит нормально и вспоминаешь, что на другом сервере эту проблему уже решил). Хотелось бы сделать по уму, использовать всякие капистрано, чифы и докеры. Читаешь обзоры и гет-стартед туториалы — всё красиво. Начинаешь применять к практике — не влезает практика в обзоры и примеры типа «деплоим хелло-ворлд на машине разработчика под обычной учеткой» когда нужно разворачивать приложение минимум на двух голых машинах с использованием рут-привилегий. Наверняка подобные задачи решаются на раз-два, ничего сверхъестественного нет в наших процессах, но при условии обладания знаниями, которых за пару часов даже не нагуглить с нуля.
deadroot
Да, и это — одна из задач devops.
jrip
На самом деле в реальности, в большом сложном проекте, граница либо размыта, либо она на уровне компетенций, возможно, частей проекта.
Создание каких-то искуственных ограничений и разграничений обычно не приводит ни к чему хорошему, конечно это все касается адекватных людей а не «Каждый разработчик делает и коммитит все, что хочет». Инфрастуктура это часть проекта, и временами ее создание часть задачи программиста, т.к. ему близка бизнесовая часть и он знает что для нее нужно.
Вообщем-то программирование от кодерства отличатется тем, что программирование это не только написание некоего кода в IDE, а решение задач самыми подходящими способами, из которых писание кода может быть и не самым основным.
Mixim333
Соглашусь с автором: есть корпоративный софт, написанный мной, который в силу объективных причин выполняет свою работу примерно за 10 часов (работа с железом по всему региону, подготовка данных и т.д.); в начале разработки и тестирования несколько раз прямо в момент работы приложения правил конфиг и понять не мог, почему приложение тут же падает (если мое приложение упало, оно отправляет письмо об этом соответствующим людям) и только позже до меня дошло, что мое приложение открывает конфиг-файл, считывает из него нужные для текущей длительной операции настройки, конфиг-файл не закрывает, а я в этот самый момент его правлю, затем приложению требуются другие данные из конфига… Благо в самом начале разработки предусмотрел возможность возобновления работы программы при исключениях…
ValdikSS
Вы банковский софт пишете?
Mixim333
К счастью, нет.
gydex
Идея здравая: каждый должен заниматься своим делом. По своему опыту программиста могу сказать, что приходилось терять очень много времени на решение сугубо админских задач, например: разбираться с установкой нужных rpm-пакетов на сервере с разрабатываемой системой, настройкой спам-фильтров и т.п., на что у профессионального администратора ушло бы в 10 раз меньше времени. И необходимо построение четкой логики взаимодействия программистов и админов.
xenozauros
Да просто бывают админы, которые живут в каком-то своем идеальном мире. И любое начинание разработичка для них как штык к горлу (или другая крайность — пусть творят что хотят, мое дело апач передернуть).
А бывают те, кто в состоянии говорить с программистами на одном языке, садиться и придумывать вместе какие-то решения.
Вот вторые — по сути и есть devops.
И когда такие люде в команде есть, энтропия проекта уменьшается. )))
VolCh
Девопсы по сути те, кто встаёт между админами и разработчиками, кто говорит и с теми, и с другими на одном языке. В одних случаях эту роль (а это прежде всего роль в процессах) берут на себя админы (характерно для компаний, специализирующихся на разработке), в других — разработчики (характерно для компаний, где ИТ-службы лишь сервис для основного бизнеса, а про R&D вспоминают когда нужна новая фича), где-то она размазывается между ними (как правило на личных неформализованных отношениях), а в последнее время тренд на отдельную специализацию.
xenozauros
В последнее время, ребята, кто на собеседование приходят, почему-то вообще уверены, что devops это программист, который умеет CI делать. Так что черт его знает на что сейчас тренд ;-)
Главное просто понимать, что то, что тебе эксплуатировать — ребята в соседней комнате разрабатывают. И в ваших общих силах сделать жизнь друг-другу проще. Вот и все.