Коллеги, есть вопрос по переходу методологии нашей конторы на пресловутые DevOps
вводные:
Имеется софтверная контора, разработка идет по методологии Agile. Имеются все необходимые группы (QA, Release Management, ArchTeam, менеджеры проектов, продуктов и тд).
Регулярные релизы, автоматизированные, деплой обновления идет по расписанию, еженедельно брифинги по релизу (что можно выкатывать, что рано выкатывать и тд).
Инженерная группа (infrastructure) отвечает за сопровождение железа, сетей, ОС, СУБД, серверов приложений и прочие внутренности. Также мы отвечаем за автоматизированный деплой релиза.
Что может измениться при переходе с нашего принципа работы на пресловутый DevOps? Хотелось бы услышать тех, кто на DevOps перешел (и взлетел).
Также карма тому, кто посоветует годные материалы (как на русском, так и на англ) и литературу (кроме проекта феникс).
Нет никаких годных материалов. Точнее они годные только для опытных DevOps. Потому что это культура подхода, а не инструментарий.
Переход на DevOps делается в три этапа:
1) Сначала полностью все автоматизируется. По поводу доставки кода вопросы врядли возникнут - Jenkins и Maven известны даже детям. Ну не обязательно они. У каждого языка свои инструменты. gradle, grunt, waf... Но автоматиризровать надо все, включая деплой SQL (LiquidBase, dbMaintain, sqitch и т.д.). Эта часть освещена очень хорошо в интернетах.
2) Затем убираются все боттл-нэки в работе админов и программистов. Например внедряется Green/Blue-деплоймент. В точках деплоя собственного ПО средства провиженинга (puppet/ansible/chef) заменяются на средства деплоймента (uDeploy например). Устанавливается мониторинг и логирование. На все это тоже есть свои инструменты (Sensu например).
3) Начинается работа с людьми - вовлечение программистов в ответственность за результат на стороне Ops и вовлечение сисадминов(operations) в результат на стороне Dev (подгон под FHS и все такое). Ключевой момент в том, что людям придется понять, что их ответственность приходит эхом оттуда, где они своими руками не трогали (для этого даже автоматически создают новые энвайронменты всякими докерами и вагрантами). Закоммитил кривой код в IDE, не учел зависимость в пропертях, поправил конфиги не для всех энвайронментов - будешь отвечать и за статический анализ кода и за проваленные интеграционные тесты и за неудачный деплоймент. В обратную сторону тоже самое. Тогда люди начнут действовать по стандартам и настанет искомый результат.
Ну и само собой надо найти сильного релиз-инженера. Потому что DevOps - это не "построил и ушел". Кто-то должен все время смотреть за новыми организационными проблемами и чтобы транк не попал на UAT, например, а на SIT ушел тот же тэгированный код, которому на DEV провели smoke-тесты, а не обновленный парой вредных коммитов, набежавших за время смоука.
Сначала скажите, как звучит конечная задача и что из этого уже есть и чего нет. Может чего детальнее посоветую.
"Точнее они годные только для опытных DevOps. Потому что это культура подхода, а не инструментарий. "
То есть девопсами рождаются? :)
По пункту 1: что означает "все"? у нас уже автоматизировано все (изменения кода, бизнес-логики, структуры таблиц, запросов и тд) - для этого используютчя самостоятельно разработанные средства.
Есть уже механизм CI (опять же собственный), который планируем заменить дженкинсом, мавен и ант уже эксплуатируются.
2) Можете привести пример ботлнеков, на вашем опыте? У нас уже есть средства деплоймента (пресловутый скрипт релиза, который ставит нужную версию кода на нужный таргет. Есть мониторинг. Есть логирование.
3) А вот это уже интересно. Поясните на примере, пжл. У нас прогеры несут ответственность за то, что код, попавший в релиз, не убьет систему. Прогеры знают. что нельзя делать никаких коммитов в пятницу (VCS лочится в этот день), чтобы не испортить релиз. По сути прогеры уже несут ответственность за косяки в релизах, но отвечают не перед нами (инженерами), а перед своим начальством.
По последнему абзацу - мы делаем релиз и отвечаем за откат на предыдущую версию (откат всего, как кода, так и изменений БД), если что-то пошло не так. smoke-тесты делаются на head'е, и дополнительные на продакшоне в maintenance window. Мы считаемся релиз-инженерами?
Вопрос не в том, что есть конечная задача или ее нет, а в том, нет ли у нас УЖЕ DevOps подхода? Судя по тому, что я сейчас вижу - изменения коснутся только моей должности (вместо infrastructure engineer станет DevOps engineer)
"То есть девопсами рождаются? :) "
Такова специфика профессии, что в DevOps приходят уже опытные. Опытные открывают книгу, чтобы упорядочить знания, а не чтобы оттолкнуться от берега. Поэтому если задали такой вопрос, значит опыта нет (таково было мое ошибочное предположение). Могу привести пример. Вот простейшая статья: blog.xebialabs.com/2010/12/20/deployment-automatio...
Если вы поняли о чем она и учтете в работе, значит у вас уже многолетний стаж :) Если его нет, вы ничего не поймете.
В любом случае мой совет был универсальным. В частном порядке я могу быть неправ.
===
"По пункту 1: что означает "все"? у нас уже автоматизировано все"
Отличная новость. Значит часть пути уже пройдена :)
"2) Можете привести пример ботлнеков, на вашем опыте?"
Ну я привел выше, упомянув сразу решение -G/B. Распишу подробнее. Разработчике нужно иметь всегда свежий код на DEV-сервере. Изначально планируется разворачивать код раз в три часа. Процесс разворота идет, например, 40 минут. Если вы будете это делать не раз в три часа, а по каждому коммиту или просто чаще, то у вас будет один сплошной даунтайм. И разработчик будет сидеть скрестив ручки и либо жадть пока развернется код и поднимется сервер либо пока вообще начнут выкладывать новый код.
Это аффектит работу девелопера вдвое или втрое снижая его производительность. Боттлнек? Он самый! Внедряете Green/Blue - voila!
Или другой пример: несовпадение релиза базы и релиза кода. Нужно их как-то выравнивать.
Или вот пример: смоук тесты провели и начинаете деплоить ветку, которую ищите.... Решение - автоматизировать создание тэга.
Короче любое систематическое промедление по времени - боттлнэк и его нужно изкоренять.
===
"3) А вот это уже интересно. Поясните на примере, пжл. У нас прогеры несут ответственность за то, что код, попавший в релиз, не убьет систему. Прогеры знают. что нельзя делать никаких коммитов в пятницу (VCS лочится в этот день), чтобы не испортить релиз. По сути прогеры уже несут ответственность за косяки в релизах, но отвечают не перед нами (инженерами), а перед своим начальством."
Я не про commit freeze. Вот пример из моей недавней ситуации. Ребята держат конфиг хибернейта в WEB-INF, если не объявлена директория с конфигом (/etc/[app_name]). Она была объявлена, но почему-то tomcat не подцепил ее. Казалось бы это проблема сисадмина. Но только не в DevOps. Программисты решали проблему почему всегда деплоится, а теперь нет. Причем ничего не меняя на энвайронменте, а только листая логи. Переписали код так, что он начал выплевывать в лог переменное окружение и ошибка стала видна. Код этот был закоммичен и остался навсегда с нами, а значит инструмент по быстрому обнаружению этой ошибки уже у нас в руках. Ключевой момент: программисты написали инструмент для сисадминов, вовлеклись в последнюю цепочку доставки кода. И были вынуждены это сделать. То есть они не имеют право забить по принципу "от нас пуля вылетела, проблема на вашей стороне". Вашей и нашей стороны больше нет как понятий.
===
"Мы считаемся релиз-инженерами?"
Конечно. Вы же релизы релизите)))
===
"Вопрос не в том, что есть конечная задача или ее нет, а в том, нет ли у нас УЖЕ DevOps подхода?"
Я не судить о том, о чем знаю по паре постов от вас :) Но какой-то необходимый минимум у вас точно есть. Полное покрытие автоматикой, если это правда автоматика, уже больше половины дела.
Простой
