Технологический консалтинг и разработка ПО
131,71
рейтинг
12 ноября 2015 в 18:08

Разработка → Почему нельзя пускать программистов на сервера, или Почему девопсы еще не вымерли, хотя об этом много говорили



Привет, Хабр!

Сегодня у нас необычный материал. Мы не будем публиковать туториал или рассматривать новые фреймворки, а просто дадим слово коллеге, которому есть, что сказать.

Мнение автора может не отражать позицию компании и других коллег.

Знакомьтесь — Александр Ефимов, Configuration manager/DevOps

Есть у меня знакомый, который, будучи первоклассным сисадмином, мечтает стать программистом. По его словам, хочет творить, а не использовать уже существующий… не очень хороший софт. В чем-то я его понимаю: «чистое» творчество — безусловно, круто. Но давайте разберемся, что и как происходит на самом деле.

Я уже достаточно долгое время работаю девопсом. Проекты, в которых я имел честь участвовать, неизбежно проходили примерно следующие фазы:
  1. Анархия. Каждый разработчик делает и коммитит все, что хочет (во всяком случае, так это видится стороннему наблюдателю). В конце спринта «самый виноватый» собирает все наработки в некоего кадавра, работающего на его машине и (теоретически) на каком-то из серверов. Потом, проходя круги боли и ада, это внедряется на сервера и как-то там работает.
  2. «На стейджинге работает». Наконец-то заказчик выделил деньги на один сервер стейджинга. Теперь ад со сборкой работающего прототипа повторяется еще и для стейджинга. Пикантность ситуации в том, что вся «обвязка» в виде БД, сервера очередей, кеш-сервера и прочего живет на localhost. Т. е. получаем ту же машину разработчика, только удаленно. Со всеми выводами типа хардкодинга части sensitive параметров соединений.
  3. Нам нужен какой-нибудь админ. На этом этапе все, сотворенное ранее, уже стало неуправляемым, стейджингу плохо, продакшен не обновляется. Тут и приходит кто-то, кого назовут 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).

Поэтому, уважаемые программисты, девелоперы, архитекторы, не обижайтесь, если вам приснится поздно ночью бородатый мужик в свитере с упреком «опять вы формат конфига изменили, а у меня деплой упал».

А вы, уважаемые девопсы и админы, будьте терпимее к разработчикам. Они постоянно ищут новые, лучшие решения. Из-за этого их работа напоминает хаос, но содержит высший порядок.

Но на сервера их все равно не пускайте.
Автор: @deadroot
DataArt
рейтинг 131,71
Технологический консалтинг и разработка ПО

Комментарии (57)

  • +25
    Теперь любой админ локалхоста, который осилил ansible считает себя devopsом, окей. Только суть концепции вы так и не уловили.
    • +17
      Ну вы же знаете почему так происходит :)
      Recruiter reaction when putting DevOps as a skill in a public CV
      image

    • +18
      В очередной раз путают понятия DevOps и админ. DevOps это как Big Data и как подростковый секс — все говорят что этим занимаются, но реально никто не знает что это такое.
      • +1
        Те, кто осилил спеку [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
        • 0
          в каких-то компаниях граница м/у админами и девопсам уж слишком размыта, а то и вообще отсутствует.

          А в каких-то админы занимаются сетевой и серверной инфраструктурой, глобальными сторонними приложениями, мониторингом основных характеристик и т. п., а деплоем, конфигурированием и т. д. разработанных в компании продуктов занимаются разработчики. Ручками, самописными скриптами или сторонними тулзами.
    • +3
      Здесь я действительно многое писал с позиции скорее админа (operations). Я понимаю, что devops и админ — разные специальности, задачи и даже отчасти мышление. Идея статьи в том, чтобы показать многие конфликтные моменты, возникающие из непонимания того, где заканчивается development и начинается operations. Одна из задач devops — как раз в сглаживании таких «конфликтных» взаимодействий т.к. он должен обладать достаточной компетенцией в обеих сферах. И да, это не единственная и не основная из задач.
      • +1
        > Я понимаю, что devops и админ — разные специальности, задачи

        Нет, вы не понимаете, поэтому я и написал что вы не поняли суть концепции. Попробуйте в следующий раз хотя бы погуглить ключевые слова прежде чем писать статьи на хабр.
        • +4
          А почему нельзя просто написать: «админ — это ..., девопс — это...»? Зачем устраивать вот эти советы в стиле «вы не поняли, попробуйте погуглить»?
          • –2
            Потому что нет смысла это обсуждать с человеком, который вообще не знаком с темой.

            operations — это профессия
            devops — это методология взаимодейсвтия в компании
            • +1
              Ну явно человек под DevOps имеет в виду DevOps Engineer.
              Хотите сказать, нет такой профессии?
              Достаточно ли в теме вы сами?
              • +7
                То, что в какой-то момент Site Reliablity Engineer, Systems Engineer и прочие системные администраторы начали называться DevOps Engineer – это просто дань моде и некомпетенция как работодателей, так и самих работников(а на деле просто проблема нейминга)

                Но по сколько DevOps это всего лишь одна из методологий, пусть даже и самая модная в наши дни – то DevOps Engineer звучит так же дико, как и Agile Engineer, Kanban Engineer или Waterfall Engineer.

                Слушайте, 2015 год заканчивается уже, я думал все эти вопросы уже году так в 2011-2012 обсудили и закрыли этот холивар. Но нет же, с завидной регулярностью появляется кто-то, кто начинает рассказывать про инженеров DevOps.
                • +1
                  Более того, все вакансии теперь называются «DevOps».
                • 0
                  У кого как, а у IBM есть четкое разделение между development и operations в их продукте для configuration management.
            • –1
              И разумеется это не единственная проблема статьи. Тяжело процитировать что тут не верно (как с т.з. методологии DevOps так и с т.з. здравого смысла) не цитируя всю статью. Поэтому совет в такой ситуации только 1 — гуглите.
              • +4
                Вот автор статьи представляет компанию D., по сути обычную аутсорсинговую или аутстафинговую компанию (или как любят говорить в компании E. — «компанию, оказывающую сервисные услуги»).

                У компании 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 по Киеву.



                А теперь прочитайте содержимое спойлеров выше и скажите, чем описанные вакансии отличаются от того что делают системные администраторы.
  • +16
    Как программист, бывает, хожу по боевым серверам. Имею навыки администрирования серверов. Никто пока от этого не умер, кроме разве что нескольких багов, проявлявшихся только на бою. И кажется, что при определенном уровне ответственности и понимания того, что ты сейчас делаешь и как это может выйти боком, иметь доступ на бой не грешно, и поэтому не стоит всех девелоперов под одну гребенку :)
    • +4
      Абсолютно согласен, сам такой же ;)
      Но если брать в среднем по больнице, то топикстартер скорее прав — у большинства программистов тупо нет достаточного опыта в админстве, а как следствие на боевых серверах они ходят по типовым граблям.
    • +1
      Бывает разное, но если в конторе работает админ, то он должен заниматься серверами, а программисты должны программировать. А так если у вас возникают проблемы на боевых серваках, то решение по умолчанию становится проблемой и админов и программистов.
      • 0
        Безусловно, говоря про поползновения на бой, я имею в виду только сервера приложений, которые пишутся мной и командой, в которой я работаю :) Как правило, туда в случае непредвиденных проблем проще и быстрее залезть самому, чем продираться сквозь бюрократию межкомандного взаимодействия. Но да, определенно не стоит это брать за постоянную практику — это для форс-мажоров.
      • +2
        Тут стоит разделять админов офисной инфраструктуры ( часто — просто support по факту) и админов «серверных» так сказать. Не всякий админ сможет корректно настроить инфраструктуру под большой проект, например.
    • 0
      Это не страшно. Но надо понимать, что это должно быть осознанное решение реально необходимое в конкретной ситуации. Также как летчики или хирурги произносят все свои действия в слух… ;)
  • +1
    Для меня выглядит странным то, что программисты не хотят разбираться в чужом коде. Да большинство проектов на 80% из него состоит — фреймворки, библиотеки, копипаст из листов. Не изучая их, работать очень трудно, если вообще возможно, тем более что документация есть далеко не для всего.
    • 0
      Тут дело в том, что это, оказывается, разный код. При разработке его можно потрогать, поиграть, проверить. А при багфиксах на продакшене такой возможности нет.
      И это не говоря о специфике языковых конструкций и не очевидных хаков (которых быть не должно, но разве так бывает?)
    • 0
      Библиотеки и фреймворки пишутся как раз для того чтоб конечному пользователю (разработчику) ненужно было в них разбираться, чтоб они могли не тратить время на разработку этого функционала а просто «прикрутили и забыли».

      Вот чужой код который уже есть в проекте (например надо чужой проект доделать) — это да. Людям проще переписать всё с нуля чем разбираться :)
      • 0
        Ну если функционал и набор ошибок в библиотеке вас устраивает, то я вам завидую. Моё начальство постоянно хочет чего-нибудь в стиле «файловый менеджер с просмотрм raw и воспроизведением midi » — приходится форкать и допиливать уже существующее, каким бы ужасным код не казался. А вообще мне как-то по секрету сказали, что сторонний код пишут тоже не идиоты, и раз они сделали именно так, то на то были веские причины.
        • –7
          Я пишу на достаточно высокоуровневом языке… мне форкать не приходится, ООП — наше всё…
    • +3
      Здесь имелся в виду не разбор чужого кода (с ним, обычно, все неплохо), а задачи, связаные с конфигурированием уже написаных сервисов/систем. Это просто «непрофильная» задача для тех, кто привык писать код — сконфигурить что-то относительно сложное. Можно, но неудобно/неинтересно для мышления. «Написать свое» психологически проще.
      Кстати, из этого во многом растут ноги у систем управления конфигурацией и вообще концепции infrastructure as a code.
  • 0
    Здесь не рассмотрена довольно сложная проблемма взаимодействия разработчиков с админом.
    В определённом смысле, здесь есть конфликт интересов. Если админа всё работает, потому он ничего не хочет менять. А программист постоянно эксперементирует что-то ставит, что-то удаляет.
    На практике получается, что внедрить что-то на dev/stage становится сложнее: нужно убеждать админа это сделать, нужно убеждать админа сделать это именно сейчас, а не завтра. Отсюда получается падение производительности падает.
    Со стороны это может выглдяеть как перестановка вагонов, на старом видео ( www.youtube.com/watch?v=23fBoqQxSgQ )
    Но на самом деле эта «перестановка вагонов» даёт много информации нужной разработчикам.
    • +2
      Ну дык четыре стадии должно быть: experimental (каждому разработчику свой стек) -> testing (все фишки собираются вместе и тестируются вместе функционально) -> staging (сюда можно пускать небольшой объём прокрашеного трафика с реальными пользователями) -> production
    • +2
      Это и есть тот конфликт development vs. operations, о котором было написано в начале статьи. Он рассмотрен огромное количество раз в разных источниках и с разных точек зрения. Здесь скорее рассмотрено его возможное решение в виде devops.
  • +4
    Админы в этом плане похожи на тестировщиков. В принципе, программисты могут выполнять обязанности и тех, и тех, но нужен особый склад ума, чтобы делать это эффективно. Больше скурпулезности, въедливости и аккуратности.
    • –2
      Скорее, больше опыта работы в соответствующей сфере.

      Какая типовая задача админа? Сделать так, чтоб на моем компе работал инет, и чтоб было достаточно прав вот на те машины, и чтоб там блокировщиков порта ***** не было. Да, на стороне админов могут крутиться сервера, настраиваться маршрутизаторы, конфигурироваться файрволлы и еще куча всего, но это скорее способ достижения цели. Функция админа: чтоб все работало.

      Функция тестировщика, утрируя: чтоб не было багов, читай, чтоб работало стабильно.

      А какие функции у среднего\начинающего программиста в средней\большой конторе, этакого винтика в машине разработки? Чтоб был написан конкретный модуль (модули). Обратите внимание, модуль работал, а не «все». Про все остальное человек может и не знать, отгородившись интерфейсом. В итоге несколько лет человек может работать над конкретными модулями даже не задумываясь, как они связаны в систему.

      Отсюда, частично, и возникает разница в складах ума. Скурпулезность, въедливость, аккуратность админов и тестировщиков обуславливается необходимостью выполнять свою админскую\тестерскую функцию; со временем эти качества превращаются в привычку.
      С этим даже начинающий админ/DevOps справился бы на автомате, не особо задумываясь, зачем это надо. Просто «для порядка».

      У программистов другие функции, отсюда и другой склад ума, другие привычки.
      • 0
        Не думаю, что какие-то другие функции. Всем надо, чтобы всё работало, а если не работает, то как можно оперативнее и точнее информировало что и где не работает. Другие не функции, а их «аргументы».
  • 0
    Мне (программисту) приходится администрировать боевые сервера самостоятельно просто потому, что так повелось в нашей организации. Осознаю, что отдельный админ справился бы с этой задачей лучше, но пока всех всё устраивает: организации не надо платить зарплату отдельному человеку, а мне небольшой объем работ по администрированию позволяет делать это в охоточку, не погружаясь с головой.
  • +1
    Честно говоря, понимаю историю про логи, но все таки — есть инструменты автоматизации выкладки, старта всех нужных сервисов и так далее.
    Хорошо написанный конфиг Capistrano снимает всю боль.
    Админ нужен когда уж совсем распределенная и большая система
    • 0
      Дело в том, что часто народ просто-напросто не задумывается о том, в какой среде и как будет работать софт. При использовании любых средств управления конфигурацией, оркестрации и т.п. все равно в первую очередь надо продумывать, что и как будет работать.
  • 0
    deleted
  • 0
    Знакомый мечтает стать программистом, потому что это более упорядоченная работа и больше возможностей.
    По крайней мере так выглядит с этой стороны :)
    • 0
      И поэтому тоже, но главное (с его слов) — больше свободы творчества.
  • +8
    Как-то ниочём у вас получилось. Тема девопса не раскрыта.
  • 0
    Не реализовать гибкую подсистему сбора логов в готовом продукте − это некомпетентность проектировщика. Не представлять, в какой среде будет работать программа, как могут распределиться нагрузки − это некомпетентность проектировщика. Разработать эзотерическую систему деплоя и/или не задокументировать её − некомпетентность проектировщика. По всему выходит, что девопс − это такой козёл отпущения, заполняющий дыры в компетентности разработчиков, пока их не накопится критическая масса.

    Нет, не поймите меня неправильно − я думаю, что статьи по девопс очень нужны на Хабре. Но не такие.
    • +1
      Гибкая система сбора логов может быть реализована в проекте (хотя бы на уровне стороннего модуля), но сконфигурирована на продакшене как {type: stream, path: app/log/prod.log}, просто потому что разработчик не знает других параметров конфигурации на продакшене, а админ не знает о том, что приложение может писать куда угодно в каком угодно формате. Система может быть спроектирована как горизонтально масштабируемая, способная работать в рид-онли контейнерах с парой точек входа и выхода, но даже выделить под каждый компонент (например, веб-сервер, апп-сервер, субд) отдельной виртуалки не получается.
    • +4
      Devops — носитель знания/понимания о двух сторонах: разработке и эксплуатации. Он не затыкает дыры, а, скорее, говорит, как можно их обойти в разработке и снизить влияние «необходимого зла» в эксплуатации. Этакий knowledge bridge. Соседний комментарий как раз про это.
      Если же devops стал козлом отпущения — мне жаль, это говорит о неправильно построеной разработке.
  • +3
    Конфликт есть, и должно быть соглашение как его преодолевать.

    Как пример такого соглашения 12factor.net/ru — Двенадцатифакторное приложение.

    Т.е. разработчики знают, что от них ожидают. А админы (по сути самые первые потребители продукта разработчиков) предлагают прозрачные и обоснованные ожидания.

    • 0
      Да, соглашение должно быть и должно вырабатываться всеми сторонами процесса. Пример мне нравится, кстати: фокус на управляемости и повторяемости всех этапов. Спасибо.
  • 0
    на некоторых проектах(100-300 серверов) проходил путь описанный в статье, от анархии до все хорошо, что в итоге материала набралось на выступление на конференции местячковой. Стоит отметить, что процесс наведения порядка ооочень не быстрый, и легко может занимать полгода-год, и это в случае, если команда разработчиков готова изменениям.

    Основной посыл, сформулировал бы так: если предоставить удобный механизм разработки, то конфликта не будет, а будет эффективный процесс обмена знаниями.
    • 0
      Очень часто механизм разработки формируется только разработчиками. А devops или тот, кто выполняет его обязанности, приходит позже. Так что да, зачастую приходится перестраивать процессы очень сильно.
  • 0
    Кто бы сказал моему начальству, что меня нельзя пускать на сервера :) В основном наши с админами обязанности по деплою наших приложений распределяются так: «мне нужен сервер с такой-то осью с таким-то виртуальным»железом"" — «на и делай что хочешь, только „железа“ много запросил, я чуть порезал», а проблемы типа переполнения диска или диких тормозов решаем вместе по мере поступления. А сначала выкручиваешься как можешь: подключаешь нестандартные репы, ставишь пакеты, правишь их конфиги, гуглишь бест-практайс, создаешь пользователей, пытаешься хоть как-то автоматизировать если не разворачивание с нуля, то хотя бы обновление однажды развернутого приложения из репозитория.

    И да, чаще всего, автоматизируешь своим кодом, например, bash-скриптами, хранящимися лишь в хомяке своей учетки на сервере, и синхронизирующимися между серверами «по требованию» (когда очередной деплой не проходит нормально и вспоминаешь, что на другом сервере эту проблему уже решил). Хотелось бы сделать по уму, использовать всякие капистрано, чифы и докеры. Читаешь обзоры и гет-стартед туториалы — всё красиво. Начинаешь применять к практике — не влезает практика в обзоры и примеры типа «деплоим хелло-ворлд на машине разработчика под обычной учеткой» когда нужно разворачивать приложение минимум на двух голых машинах с использованием рут-привилегий. Наверняка подобные задачи решаются на раз-два, ничего сверхъестественного нет в наших процессах, но при условии обладания знаниями, которых за пару часов даже не нагуглить с нуля.
    • –1
      Да, и это — одна из задач devops.
      • 0
        На самом деле в реальности, в большом сложном проекте, граница либо размыта, либо она на уровне компетенций, возможно, частей проекта.
        Создание каких-то искуственных ограничений и разграничений обычно не приводит ни к чему хорошему, конечно это все касается адекватных людей а не «Каждый разработчик делает и коммитит все, что хочет». Инфрастуктура это часть проекта, и временами ее создание часть задачи программиста, т.к. ему близка бизнесовая часть и он знает что для нее нужно.
        Вообщем-то программирование от кодерства отличатется тем, что программирование это не только написание некоего кода в IDE, а решение задач самыми подходящими способами, из которых писание кода может быть и не самым основным.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Вы банковский софт пишете?
      • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Идея здравая: каждый должен заниматься своим делом. По своему опыту программиста могу сказать, что приходилось терять очень много времени на решение сугубо админских задач, например: разбираться с установкой нужных rpm-пакетов на сервере с разрабатываемой системой, настройкой спам-фильтров и т.п., на что у профессионального администратора ушло бы в 10 раз меньше времени. И необходимо построение четкой логики взаимодействия программистов и админов.
  • +1
    Да просто бывают админы, которые живут в каком-то своем идеальном мире. И любое начинание разработичка для них как штык к горлу (или другая крайность — пусть творят что хотят, мое дело апач передернуть).
    А бывают те, кто в состоянии говорить с программистами на одном языке, садиться и придумывать вместе какие-то решения.
    Вот вторые — по сути и есть devops.
    И когда такие люде в команде есть, энтропия проекта уменьшается. )))
    • 0
      Девопсы по сути те, кто встаёт между админами и разработчиками, кто говорит и с теми, и с другими на одном языке. В одних случаях эту роль (а это прежде всего роль в процессах) берут на себя админы (характерно для компаний, специализирующихся на разработке), в других — разработчики (характерно для компаний, где ИТ-службы лишь сервис для основного бизнеса, а про R&D вспоминают когда нужна новая фича), где-то она размазывается между ними (как правило на личных неформализованных отношениях), а в последнее время тренд на отдельную специализацию.
      • +1
        В последнее время, ребята, кто на собеседование приходят, почему-то вообще уверены, что devops это программист, который умеет CI делать. Так что черт его знает на что сейчас тренд ;-)
        Главное просто понимать, что то, что тебе эксплуатировать — ребята в соседней комнате разрабатывают. И в ваших общих силах сделать жизнь друг-другу проще. Вот и все.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка