DevOps подход

Встали на этот путь, но пока еще не дошли, куда хотим. Хм, как дошли? А сколько серверов у тебя в проекте? А так же сколько человек в команде?

Используем docker, kubernetes и ansible. Всем этим заведуют полуадмины-полулюди.

Профит: лёгкий скейлинг, легко поднимать тест-енваирмент и деплоить все возможные ветки на стейджинг. Ну и основной профит - понятно как взаимодействуют овермного микросервисов, и каждый из них в своём контейнере, ни с кем не конфликтует.

Хост платформа - амазон.

Ну и у нас не только devops, но и ci с cd =)

используется ли у вас на работе devops?

задрал этот маркетоидный буллшит, одни говорят что это роль чувака который паолуадмин полупрограммер заведующий размертыванием, другие начинают его сипользовать в интимных целях

А если используется, то каким образом к нему дошли?

Жалко денег на нормальную постановку рабочего процесса

А шо це таке?

Когда одни и те же люди занимаются разработкой/поддержкой/кк/пусконаладкой, модно в штартапах где маленький штат.

Т.е. хотят специалиста по всему, платя, как за одного? Хитро придумано.

Да дофига баззвордов придумали чтобы сократить зарплатный фонд. «Full-stack developer», например. Но, кроме шуток, концепция DevOps начинает мне нравиться. Хотя бы потому, что все юниты в группе разработки и поддержки работают над одним проектом.

Чуть меньше 30. DevOps никак не связан с количеством серверов (если только ты локалхост не администрииуешь)

Тестировщикам понадобилось окружение, аналогичное боевому кластеру - так и дошли. Я DevOps, спрашивайте свои ответы.

http://data2.whicdn.com/images/52469300/large.gif

Как у вас построен процесс реагирования на инциденты, как делаете алерты, и т.д.?

Нучны адекватные админы и адекватныа менеджеры конфигураций... Devops обычно больше программер и после его решений порой на продакшен смотреть страшно.

Ну, хз.

В нашем селе девопсом занимаются бывшие опсы, так что ничего вырвтглпзного я не видел.

А можно примеры 'страшных решений на продакшне'?

DevOps подход

очередной баззворд? распиши ка

Я DevOps, спрашивайте свои ответы.

Офигеть, живой девопс. Чем конкретно ты занимаешься?

Хахаха.

ЛОР, а кто такие DevOps?

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

У нас есть дежурный, ответственный за обработку внешних запросов. С технической же стороны есть такие каналы связи как офисная почта, офисный джаббер и slack.com. Инциденты регистрируются в Atlassian Jira, там же можно следить за статусом.

Хотя бы потому, что все юниты в группе разработки и поддержки работают над одним проектом

А если проект чуть подрастает, из-за такого подхода все сразу и разваливается.

http://www.commitstrip.com/en/2012/09/21/question-de-methode/

Автоматизацией в основном. Например сначала поддерживал legacy-приблуду на питоне на основе fabric, которую написали до того как я сюда устроился. Приблуда писалась, чтобы обновлять веб-проекты на продакшене и тестовых и разработческих средах с минимальным даунтаймом. Сейчас переписал верхний уровень для нормальной многопоточной выкладки на go (де-факто стандарт у нас в отделе). Кроме того, собираю пакеты, например.

Фактически отдел отвечает за работоспособность продакшен/тестовой/разработческой сред и несет ответственность за факапы.

В код основного проекта ты не лезешь/тебе не позволяют лезть или наоборот? Где-то я читал, что основное отличие девопсов от просто админов, поддерживающих разработку - в том, что девопсам разрешают править основной код.

DevOps никак не связан с количеством серверов

Наглая ложь. С этим он связан, как и со многим другим.

(если только ты локалхост не администрииуешь)

А если локалхост админю, то напрямую значит зависит? У тебя не получилось мысль донести, давай еще раз )

Что ты подразумеваешь под термином «основной код»? Если тот код, который непосредственно приносит прибыль компании (код веб-проектов), то нет, я в него не лезу, я, при обнаружении проблемы, откатываю проект на предыдущую рабочую версию и создаю на проект задачу в жире.

А при чем здесь девопс до процессных методологий? Бери itsm и будь счастлив.

Нам позволяют, в редких случаях. Иногда до авторов кода просто не дозвониться.

Ты тоже живой девопс?

Иногда до авторов кода просто не дозвониться.

В таких случаях и мы сами поправим.

Мне в паре мест говорят, что я девопс, но, честно говоря, так и не понял, что это значит.

Занимаюсь вроде классическим администрированием плюс немного докера и самопальных веб-админок.

devops - это как-то размыто. я вижу у одних devops - это админы с умением писать скрипты, у других это админы, которые используют определенные тулзы, у третьих - это прогеры, которые чуть-чуть умеют админить и потому растопыривают пальцы. Вы про какой devops спрашиваете?

Скажи, чем devops подход отличается от обычного и я скажу, кто ты.

Обьясню, криво выразился.

DevOps пиактики можно внедрять даже при малом количестве серверов.

К тем, кто говорит про кризис: я знаю компании, где помимо чуваков, которые зпнимаются внедрением девопс практик, есть еще и отдел эксплуатации, т.е. обычные админы. Например, Яндекс.

Я просто хотел понять, что публика лора понимает под понятием 'методология девопс' inb4 маркетинговый буллшит

Мы про тот, который у третьих.

ну вы-то понятно%) а ТС-то о чем подумал?)

Как я понимаю про яндекс: у них отдел админов для основных проектов, где сервера считаются тысячами, где много именно административных задач. Они создают средства администрирования для всех. А девопс - для маленьких проектов из 3х человек, где пара сотен серверов. Причем эти девопс уже используют наработки отдела эксплуатации (инфраструктуру администрирования) и допиливают конкретный проект, скажем, на hadoop. Они и поадминить и покодить успевают.

у одних devops - это админы с умением писать скрипты, у других это админы, которые используют определенные тулзы, у третьих - это прогеры, которые чуть-чуть умеют админить

А если в нашем отделе есть всё это?

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

А так девопс очень годный подход.

Так в чем заключается _подход_?

Когда разработчик дает администратор и говорит: 'задеплой, сантехник ит', администратор матерится на этих програмистов, которые вечно пишут какую-то шнягу, которую непонятно как поддерживать, мониторить и тд. К тому же полагается она на костыли, о которых, естественно, только разработчик(и) в курсе.

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

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

В моем понтмании, de ops - набор правил и практик, которые помогают избегать таких случаев, а также повышать качество коммуникации между этими 2 подразделениями.

Схема ответственности, которую вижу я: опсы отвечают за работоспособность ос, сети, и остальных системных вещей

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

Разработчики пишут код.

Буду рад услышать критику/исправления

Извиняюсь за опечатки, с телефона неудобно писать

да все что угодно - начиная от логов - «мы на тесте пробовали - за день 5Mb набежало» - не учитывая что на тесте пасся один QA вручную, и заканчивая непониманием того что например статика может лежать не то что на соседнем сервере, а в географически удаленном датацентре... это то что первое в голову пришло....

Ну, это совсем уж очевидные вещи. Тут только о непрофессионализме можно сказать.

Всё звучит разумно, но вопрос в том, насколько это соответствует общепринятому определению (если оно есть).

Да, три года уже. Правда, я с уклоном в r&d

Я бы добавил, что девопсы предоставляют окружение, аналогичное боевому, разработчикам и тестировщикам.

Из последнего: разрабы при рефакторинге забыли для китайской версии сервиса добавить дополнительный мд5 по паролю, всплыло в 3 ночи на релизе. Правили сами.

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

У нас другая проблема: приложений разных под полторы сотни, в голове удержать нереально, поэтому приходится звонить авторам.

Мы к этому движемся =) Пока основная часть проектов (но уже не все) использует один стек технологий.

того хуже - эрланг

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

Ночные факапы бывают, да. Но не очень часто. Основные косяки отлавливает отдел тестирования и до продакшена они не доходят. Приходят на ум разве что неудачные манипуляции с боевой базой.

У нас бывают факапы на проде из-за интеграции с партнерскими сервисами, которые невозможно или просто очень сложно симулировать. Хотя опять же, это все во время релизов, когда и так даунтайм.

А если в нашем отделе есть всё это?

Ну есть и есть. Я человеку предложил вариант выбора (подсказку, критерии). Мне, если честно, совершенно пофигу, что у вас (тем более, раз ты из нска. как кто тут работает, я и сам знаю). Ты ведь не с вопросом пришел, а как бы уже все знаешь.

Ок.