Как DevOps поможет всем идеи, инструменты, развитие


Оглавление (нажмите, чтобы открыть):

Из системного администратора – в DevOps-инженера

Кирилл Сергеев два года работает системным инженером. Он уже рассказывал « Клеверу » о том, что такое DevOps и кто такие DevOps-инженеры. Пока мы общались на эти темы, узнали и историю самого Кирилла, которая будет интересна, если вы задумываетесь о выборе DevOps-практики.

Как я выбрал DevOps-практику

Шесть лет я работал системным администратором. Когда принимал решение о смене направления, руководил отделом из трех специалистов. Мы обслуживали офис численностью около 500 человек, это была большая ответственность, интересный челлендж, но я понимал, что теряю технические навыки, больше координирую процессы и развиваю soft skills. А меня всегда привлекала в IT-сфере работа с новыми современными технологиями.

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

С чего начал

Я учился по вечерам в свободное от работы время. Специальных курсов не проходил, пообщавшись с коллегами, просто выяснил, какие технологии и навыки необходимы. Например, уметь автоматизировать рутинные задачи, понимать процесс CI/CD и использовать инструменты для его построения (Jenkins и ему подобных). Также мне нужно было разобраться со спецификой работы Unix и Linux в условиях высокой нагрузки, посмотреть особенности поддержки Java-приложений. Я взял тестовые задания, которые предлагают обычно на собеседованиях, и в интернете начал искать материалы. За месяц я изучил большой объем нужного материала, дальше еще месяц знакомился с технологией ATG, потому что она была нужна на моем будущем проекте.

Начинающим специалистам я рекомендую осваивать что-то более распространенное – CI/CD-инструменты (Jenkins, GitLab), современную виртуализацию, контейнеры и оркестрацию (Kubernetes и Openshift). Также обязательно уделите внимание игрокам большой тройки – облачным провайдерам AWS, Azure, Google – чтобы понимать и знать, какой сервис для чего служит.

Из качеств, важных для DevOps-специалиста, я бы выделил: готовность к постоянному развитию, любовь к автоматизации процессов и умение анализировать работу проекта в целом.

Через два месяца подготовки я прошел собеседование и вышел на проект в сфере E-commerce. Я заранее знал, на какой именно проект хочу попасть, его специфику и особенности. Так я остался работать в той же компании и лишь сменил направление деятельности. На моем проекте уже была сформирована DevOps-культура, и я присоединился к распределенной команде из четырех DevOps-инженеров. Единственная трудность, с которой столкнулся в начале работы: не было понимания и опыта использования принципов разработки ПО (Scrum, Agile, Waterfall). Пришлось быстро знакомиться, искать материалы в интернете.

Что нравится в работе

Для меня важна вовлеченность в процесс разработки, я помогаю всем его участникам и вижу результаты. DevOps-инженер должен прекрасно представлять, у кого какие проблемы, что можно улучшить и автоматизировать на каждом из этапов проекта. DevOps-практика хорошо показала себя бизнесу, есть конкретные цифры, метрики, которые доказывают выгоду. Любимая метрика бизнеса – сокращение time to market. Например, на сайте заказчика планируется установить обновление, которое будет удобнее для покупателей или привлечет новых. С помощью автоматизации CI/CD-процесса, дополнительных метрик, мониторинга, автотестирования можно значительно сократить время выхода обновлений на сайт.

То, что эффективно для бизнеса, всегда начинает быстро развиваться. Поэтому скорость изменений в DevOps-мире, конечно, бешеная, и мне это очень нравится. Все больше IT-специалистов делятся своим опытом и идеями в работе с DevOps, а я в свою очередь стараюсь применять новые практики на проекте. И если раньше DevOps-инженеры присоединялись к уже налаженному процессу, то сейчас проектные менеджеры все чаще приглашают нас на стадии обсуждения архитектурных решений. Я думаю, в будущем все IT-специалисты – разработчики, тестировщики, аналитики – будут применять DevOps-практики.

К чему стремлюсь

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

DevOps Методология

DevOps (от англ. development и operations; по-русски обычно произносится как «дево́пс») — набор практик, нацеленных на активное взаимодействие специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимную интеграцию их рабочих процессов друг в друга. Базируется на идее о тесной взаимозависимости разработки и эксплуатации программного обеспечения и нацелен на то, чтобы помогать организациям быстрее создавать и обновлять программные продукты и услуги.

Содержание

Динамичные изменения, происходящие в мире технологий, предъявляют к современным компаниям более строгие требования к скорости реакции, времени выпуска релизов ИТ-систем и способности специалистов различного профиля открыто общаться и плодотворно сотрудничать. Не составляют исключение и разработчики встроенных систем. Востребованная методология непрерывной поставки решений предъявляет особые условия к организации проектных процессов, причем тестирование перестает быть заключительным и изолированным этапом всего цикла разработки. Однако, внедрение тестирования в качестве непрерывного параллельного разработке и сопровождению процесса порождает массу вопросов к практике такого внедрения.

Основной целью перехода на идеологию DevOps является желание улучшить и ускорить обслуживание клиентов. Сокращение затрат, увеличение автоматизации, улучшение управления конфигурацией, выполнение бизнес-запросов — это лишь сопутствующие задачи. При этом разным типам организаций может потребоваться разная структура команд для эффективного взаимодействия Dev и Ops.

С появлением в 2009 году методологии DevOps, которая должна была ответить на растущее количество вопросов к организации активного, непрерывного и продуктивного взаимодействия ИТ-специалистов в рамках проекта, компании разделились на лидеров и отстающих в зависимости от того, насколько хорошо им удалось адаптировать процесс тестирования к декларируемым принципам.

DevOps – относительно новая концепция, и у нее все еще нет четкого, общепринятого определения. По сути, это набор практик, нацеленных на активное взаимодействие и интеграцию специалистов по разработке, тестированию и сопровождению. Использование DevOps обеспечивает стабильное, быстрое и надежное развертывание ПО, в том числе и благодаря непрерывности тестирования, что позволяет избежать задержек и проблем с качеством, свойственных для классической модели проектной разработки.

Популярность методологии значительно возросла в последние годы. По данным RightScale 2020 State of the Cloud Report: DevOps Trends [1] , принятие DevOps увеличилось с 66% в 2015 году до 74% в 2020 году, а среди крупных организаций принятие методологии еще выше – 81%.

Внедрение DevOps – непростая задача для многих опрошенных нами компаний: ведь новая практика часто требует иного образа мышления и фундаментального сдвига в корпоративной культуре. И все же преимущества, которые DevOps и Agile обещают разработчикам, тестировщикам и всей команде, намного превосходят любые издержки.

  • Разработчики задействуются на проектах более эффективно
  • Проблемы выявляются на ранних этапах, а затраты на их устранение снижаются
  • Ускоряется цикл разработки и развертывания ПО
  • А главное, в итоге повышается удовлетворенность заказчика

Трансформация профессии системного администратора под влиянием DevOps

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

Топология команды DevOps

Какая структура или топология команды DevOps подходит для организации, зависит от многих вопросов, например:

  • Каков набор выпускаемых и поддерживаемых продуктов – чем меньше продуктов, тем больше взаимосвязь Dev и Ops.
  • Степень, сила и эффективность технического руководства — имеет ли Dev и Ops общую цель.
  • Готова ли организация на трансформацию роли ИТ эксплуатации от «принеси-подай» во встроенной в бизнес процесс.
  • Есть ли в организации лидеры, которые готовы указывать на проблемные области и сопровождать изменения.
  • Чаще всего построение «команды мечты» потребует последовательной смены нескольких моделей.

Использование в России

Сбербанк «подсел» на гибкую разработку: вслед за Agile — внедрение DevOps

Сбербанк внедряет практики DevOps в разработку автоматизированных систем. В качестве консультанта для этого банк по итогам конкурса в июле 2020 года привлек компанию McKinsey [2] .

Из опубликованной Сбербанком конкурсной документации следовало, что банк внедряет DevOps в части подпроцессов непрерывной сборки, развертывания и поставки (Continuous Integration, Delivery и Deployment). Автоматизированные системы для внедрения DevOps из числа целевых систем банка должны были быть выбраны совместно с McKinsey. Подробнее здесь.

«Альфа-Банк» ускорил ИТ-разработку в 60 раз за счет DevOps-культуры

«Альфа-Банк» считает внедрение культуры гибкого проектирования одним из главных своих достижений в ИТ в 2020 году. Это следует из годового отчета банка, опубликованного в конце июня 2020 года.

В 2020 году мы совершили большой шаг в сторону DevOps-культуры — культуры гибкого проектирования и интеграции операционных и проектных процедур — и смогли создать в

ИТ-блоке атмосферу, пропитанную идеологией тотальной автоматизации, — говорится в годовом отчете.

10 способов построения эффективной DevOps-команды

Во многих статьях даются только общие советы по DevOps: «создайте хорошую команду», «сформируйте благоприятную культуру для командной работы». Мало, кто говорит о том, как именно это делается. В этой статье даются некоторые рекомендации от специалистов по DevOps. Они расскажут, как привлечь талантливых сотрудников и добиться от них максимально эффективной работы. Ниже будут рассмотрены вопросы организации команды и руководства.

Недавно в TechBeacon решили разобраться во всех тонкостях этой темы и побеседовали с несколькими DevOps-менеджерами. Как правильно подобрать людей в команду? Как привлечь хороших кандидатов? Как организовать работу команды? Как надолго сохранить лучших работников? Полученные ответы можно найти в этой статье.

1. Удержание сотрудников не менее важно, чем набор нового персонала

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

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

Технический директор Denim Group Дэн Корнел объясняет это так: «Самые успешные инициативы по DevOps реализуются коллективами, состоящими из старых и новых сотрудников».

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

2. Команда должна иметь кроссфункциональную структуру

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

Директор службы товарного маркетинга компании Chef Джулиан Данн считает, что организация команды важна, но не стоит устанавливать строгую вертикаль управления. Вместо этого, лучше создать кроссфункциональную команду.

«Не столько важна организационная структура коллектива, сколько кроссфункциональное взаимодействие сотрудников при работе над проектами». – утверждает Данн.

«Не путайте руководство и функциональное управление», — Джулиан Данн.

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

3. Создание команд «на две пиццы» с портфельным управлением

Компания Amazon наделала шуму в мире DevOps, предложив концепцию команд «на две пиццы». Самые эффективные команды — это те, которым хватает двух пицц, чтобы накормить всех сотрудников. Использование маленьких коллективов отлично подходят, чтобы организовать слабо связанный процесс поставки программных продуктов по типу микросервисов. Это очень ценится в организациях с DevOps.

Алан Цукер, основатель фирмы Project Management Essentials, считает, что реорганизация IT в маленькие команды сотрудников может показаться непосильной задачей для предприятия. Активизировать и объединить собственные ресурсы не так уж легко.

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

Также Цукер уверен, что на практике у компании может быть вице-президент или директор технологической службы, который занимается портфелем приложений, например финансами. Он наблюдает за несколькими маленькими DevOps-командами, которыми руководят менеджеры и директора.

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

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

Цукер считает, что построить организацию такого типа непросто. «Здесь нужны лидерские качества. Директора и менеджеры должны стремиться построить культуру сотрудничества и доверия для своих подчиненных».

4. Необходимые качества сотрудников

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

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

Корпоративный архитектор Mendix Яспер ван дер Хук отметил, что руководители должны соблюсти в команде баланс опыта и профессионализма. Нужно искать людей, у которых есть и опыт, и знания.

«DevOps делает необходимым построение самодостаточных команд. Нужно избегать ошибки создания миниатюрных IT-организаций с узконаправленной специализацией. Впоследствии это может привести к еще большим проблемам, чем на начальном этапе», — Яспер ван дер Хук.

То есть искать нужно не только специалистов с глубокими познаниями в отдельной области, которые требуются для данной должности (классический I-образный профиль компетенций, когда люди мыслят узконаправленно). Кроме специализации, стоит обращать внимание на широту знаний (более широкий T-образный профиль компетенций, оптимизированный под DevOps). Такие работники будут работать энергичнее и сотрудничать с коллегами во многих вопросах. Если придерживаться T-образного профиля компетенций, то каждый член команды сможет взять ответственность за любой аспект миссии команды.

«Очень много узконаправленных специалистов. Однако каждый человек должен стремиться расширить набор подходящих для него компетенций» — ван дер Хук.

Ван дер Хук приводит пример, что UX-специалист может предлагать оптимальные идеи и процессы, а несколько человек в команде должны суметь воплотить их.

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

Реальность такова, что лучшим кандидатам на попадание в DevOps-команду нравится работать с новыми технологиями «в красивой обертке». Если организация полагается на старые медленные инструментальные средства разработки, привлекать талантливых специалистов и удерживать их намного тяжелее.

Дерек Чой, ИТ-директор в Rainforest QA, полагает, что лучше потратиться на специальные DevOps-инструменты. Это повысит эффективность сотрудников, и они не захотят уходить.

«Чтобы привлечь талантливых специалистов по DevOps в компанию, важно вывести на первый план создание продвинутого и интересного DevOps-инструментария», —Дерек Чой.

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

6. Новым сотрудникам нужны наставники

По словам Дерека Чоя, новичкам нужно не только продвинутое ПО для работы. Кроме этого, они хотят быть уверены, что их коллеги, особенно вышестоящие, – настоящие профессионалы. Дело не только в работе под началом компетентных управленцев. Они хотят работать под руководством тех, кто готов быть их наставниками.


«Сильные руководители команд DevOps – учителя, стоящие в первых рядах сообщества DevOps. Они зарабатывают себе имя, выступая на знаковых конференциях, проводя инновационные исследования и публикуясь в изданиях. Кандидаты часто равняются на таких лидеров. Иногда они присоединяются к команде, как раз надеясь поработать со своими ролевыми моделями», — Дерек Чой.

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

7. Преподавание в университетах

Чтобы стать учителем на работе, стоит попробовать заняться преподавательской деятельностью в учебном заведении. Технический директор и сооснователь южноамериканского сайта oMelhorTrato.com Кристиан Реннелла заверяет, что одна из самых эффективных стратегий поиска лучших специалистов по DevOps – преподавать в местных университетах. По его словам, преподавательская деятельность помогла ему привлечь более 60% от всех новых DevOps-сотрудников его организации. Его компания одобрительно отзывается о результатах работы этих людей.

«Даже не нужно быть учителем, чтобы использовать этот источник новой рабочей силы. Для начала нужно обзавестись знакомствами в местном университете. На начальных этапах можно организовывать и продвигать научно-технические конкурсы, соревнования или мероприятия среди студентов инженерных специальностей», — Кристиан Реннелла.

8. Команды способны сами отвечать за набор персонала

Коллектив компании New Relic, занимающейся аналитикой ПО, пережил период DevOps-трансформации. В ходе комплектования своих команд разработчиков, компания прислушивалась к собственным служащим. Самостоятельный выбор кандидатов облегчает задачу построить команду, в которой между сотрудниками способно возникнуть взаимопонимание на профессиональном и межличностном уровне.
Директор отдела контроля производства в New Relic Джим Гочи утверждает, что менеджерам и руководителям трудно следить за развитием взаимоотношений в коллективе. Когда команды сами набирают персонал, им понятнее, кого они хотят видеть в своих рядах. Люди, которым нравится работать друг с другом, могут работать практически над чем угодно.

«Если специалисты, работающие вместе, хорошо относятся друг к другу, между ними возникает доверие. За счет этого улучшаются результаты работы и производительность. Люди гораздо сильнее переживают за результат», — Джим Гочи.

9. Команды должны работать автономно

По мнению Гочи, в наши дни на рынке труда все вертится вокруг соискателя. Финансовые стимулы, такие как бонусы, высокие зарплаты, различные привилегии – не всегда самый важный фактор привлечения талантливых специалистов. Возможно самый заманчивый бонус, который может предложить кандидату организация — возможность работать автономно.

«Я видел, что происходит, когда команда разработчиков полностью берет ответственность за свою работу. Инженеры больше интересуются, как клиенты используют созданную ими часть системы», — Гочи.

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

Мастер Йода рекомендует:  Использование метода toString() в Java

10. У команды должно быть время на совершенствование процессов

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

«Они могут выбрать себе определенные часы на неделе или во время спринта – 10-20% от всего времени. Это время они посвятят совершенствованию процессов. За свой объем работы они будут получать соответствующее поощрение», — ванн дер Хук.

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

Выводы

Не существует универсального рецепта создания успешной DevOps-команды. Однако в самом процессе нет ничего сложного. Большая часть представленных выше рекомендаций основана на здравом смысле. Многие из них подразумевают тяжелый труд и решение реальных проблем.

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

Как DevOps поможет всем: идеи, инструменты, развитие

Сначала была обычная («каскадная», «водопадная») разработка. Заказчик приносил требования. Требования получали разработчики. Разработчики закрывались на пару месяцев. Заказчику показывали готовое.

Вполне нормальный, рабочий подход. Но почему возникла потребность придумывать что-то еще?

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

Но вот проект усложняется. Заказчик не уверен, что нужно делать именно так. Аналитик, хоть и парень с головой, но тоже не экстрасенс. Кто знает, вдруг продукт вообще не воспримется пользователями? Скетчи, мудборды, прототипы и прочая подстраховка — хорошо, но только реальные пользователи расскажут, как продукт должен работать на самом деле.

Процесс меняется в сторону стирания барьера коммуникации между клиентом и разработчиком. Теперь работает другая схема.

Заказчик приносит требования. Их разбивают на задачи и упорядочивают по важности для продукта. Разработчики набирают задач на одну-две недели. Закрываются и работают. Показывают первую версию продукта. Запускают на рынок! Далее по кругу, пока все задачи не будут сделаны, а продукт не обрастет всеми плановыми функциями.

  1. Проект становится более гибким, изменениями становится возможно управлять.
  2. Наконец-то появляется возможность апробации проекта на настоящих пользователях (а не моделирование ситуаций).

В чем, собственно, проблема, которую DevOps решает? Даже если команда работает по Scrum, функции разрабатываются «пачками». Потом «пачками» тестируются. И, наконец, внедряются в работающий продукт тоже «пачкой».

Соответственно, изменения на продукте происходят не ровно, а «скачками».

То есть по факту Agile-разработка с заявленным «ровным» темпом изменений становится тем же каскадом.

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

  • Разработчики мотивированы делать больше изменений, за них им платят. ИТ-отдел мотивирован выпускать в свет наиболее стабильный продукт (меньше изменений — меньше рисков, что что-то сломается).
  • Разработчики мыслят «главное — сделать строго по заданию». IT мыслят «главное — сделать оптимально для пользователей».
  • Разработчики делают работу в своей среде, QA зачастую настраивают свою среду для тестирования.
  • Знания разработчиков и ИТ-специалистов неотчуждаемы от них самих, у первых нет знаний вторых и наоборот.
  • Разработчики и отдел эксплуатации мало контактируют друг с другом, у них нет осознания чужих проблем.

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

Что предлагает DevOps? Методология провозглашает три развернутых ключевых тезиса (их еще называют «пути»):

  1. Оценивается производительность системы в целом, а не отделов или конкретных разработчиков, админов, специалистов по качеству. Задача руководителя, внедряющего DevOps — заставить всех участников проекта работать единой командой на достижение глобальной цели: увеличение ценности продукта для пользователей. Обязательное условие — развивать кросс-функциональность, делать сотрудников более универсальными солдатами, заставлять их почувствовать себя в шкуре бойца из «лагеря противника».
  2. Непрерывная обратная связь «справа налево». То есть в продукт постоянно внедряются изменения, отслеживается реакция пользователей, готовится материал для новых задач, они уходят в работу. Такой «конвейер» требует высокого уровня автоматизации процессов тестирования и развертывания, создавать его за счет наращивания персонала не правильно.
  3. Создание внутрикомандной культуры, поощряющей эксперименты. Нельзя понять, как будет оптимально для продукта без тестирования на его конечных потребителях. Соответственно, и каждый член команды, и клиент должны мыслить таким образом: смело внедрять новое, чтобы получать наиболее ценный аналитический материал для будущих этапов разработки.

Из того, что же можно сделать конкретно, информации не так много, как ее хотелось бы.

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

Отличная подборка нужного софта:

Тип инструмента Инструменты
Автоматизация инфраструктуры Bcfg2, CFEngine, Chef, CloudFormation, IBM Tivoli, Puppet
Автоматизации развертывания Capistrano, ControlTier, Func, Glu, RunDeck
Инфраструктура как услуги Amazon Web Services, CloudStack, IBM SmartCloud, OpenStack, Rackspace
Автоматизация сборки Ant, Maven, Rake, Gradle
Автоматизация тестирования JUnit, Selenium, Cucumber, easyb
Управление версиями Subversion, Git, IBM Rational ClearCase
Непрерывная интеграция Jenkins, CruiseControl, IBM Rational BuildForge

Ок, что можно сделать для того, чтобы достичь кросс-функциональности в командах продукта?

  • Самое простое: не разделять команды стенами — так они смогут общаться без помех.
  • Также рекомендуется проводить взаимные обучающие тренинги, чтобы разработчики провели ликбез среди QA и админов, а те посвятили первых в свои боли и печали (мы, например, делаем холивары по технологиям, примерно та же история.).
  • Создавать общую инфраструктуру. Причем всегда поддерживать ее актуальность. Если речь о каких-то программных инструментах — то они общие для всех, строго одинаковых версий. Если это площадка для тестирования продукта — то не нужно вручную настраивать одну среду для разработки, одну для теста и потом трястись над ней. Всё в облако, протестировали, исправили баги, удалили платформу (чтобы ни у кого не было соблазна в следующий раз «случайно» воспроизвести неведомый баг на неактуальной уже платформе).

Одно из самых трудных — создать нужное настроение в команде, общность целей, понимание того, для чего всё делается в конечном счете. Достигается за счет так называемой «коллективной ответственности». Из того, что пробовали на себе — включаем разработчика в процесс деплоя и теста (он, например, готовит среду).

Ответная мера — QA вместе с разработчиками пишут тест-кейсы, по которым потом будут оценивать работоспособность продукта (это делается на этапе планирования).

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

Но, как мы ни крутили методологию, оставался открытым главный вопрос: а есть ли заказчик среди заказной веб-разработки с реальной потребностью в таком крутом и техничном процессе?

Даже тот факт, что в день будет происходить несколько развертываний изменений на сервере, потом их кому-то надо будет постоянно отслеживать, непрерывно корректировать бэклог… То есть фактически клиент должен быть полноценным Product Owner, участвовать в ежедневных митингах, заниматься только проектом и больше ничем.

Допустим, даже если мы как подрядчик готовы допилить свои процессы до такого совершенства… В итоге нет.

Подход адекватен для по-настоящему крупных проектов: вроде Dropbox или Flickr. Когда есть реальная потребность в непрерывном потоке изменений, есть ресурсы для постоянного анализа и, естественно, бюджет для экспериментов.

Или для тех команд, которые пилят собственный продукт, предварительно спланировав все ресурсы.

В общем, если кто-то из IT-компаний вдруг пробовал внедрить DevOps — будем рады послушать ваш опыт.

DevOps-инженер: как обучиться одной из самых прибыльных профессий

IT-индустрия растет и развивается такими темпами, что позавидовать может любая другая сфера деятельности, существующая на данный момент. Каждый день появляются новые проекты, новые методологии управления ими, совершенствуются языки программирования, а приложения и программы начинают работать со все более объемными и сложными данными.

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

На этом моменте становится понятно, что ни один разработчик не сможет уследить за всем этим. Более того — даже целая команда разработки. Но не потому, что не умеют, а потому, что этим должен заниматься специалист. Сейчас эта профессия гордо именуется DevOps-инженер, и мы расскажем, как стать им — тем, кто способен строить сложные, автоматизированные и безопасные системы, понимая, как работает каждая отдельная их часть.

DevOps

DevOps — сокращение от Development Operations. Но изначально это не было профессией. DevOps — это культура, методика, набор практик, задача которых сократить время разработки программного обеспечения, обеспечить правильное функционирование ПО как со стороны железа, так и в программной части.

В задачи DevOps-инженера входит синхронизация и автоматизация всех этапов разработки ПО: написание кода, тестирование кода, продакшен и выпуск обновлений и патчей. Такой специалист является одновременно и админом, и разработчиком, и тестировщиком. Он контролирует отделы разработки и эксплуатации ПО и на глубоком уровне понимает, как устроен весь этот процесс. Если хочешь, то его можно назвать менеджером, управляющим (но только в хорошем смысле).

Как стать DevOps-инженером

Это молодая профессия, и специалисты в ней крайне востребованы. Если ты хотя бы немного умеешь кодить, умеешь в системное администрирование и Linux или хочешь перерасти должность «просто админа» или программиста, перейдя на новый уровень, то тебе стоит записаться на курс DevOps Engineer, который проводит в январе школа IT-образования Level UP .

Продолжительность курса — 2 месяца. За это время ты пройдешь через специально разработанную для современных реалий (и успешного прохождения собеседований) программу, которая включает в себя просто огромный стек технологий и инструментов: Agile, Scrum, Hyper-V, Vmware, базы данных MySql, NoSql, PostgreSql, Git, Docker, Ansible, Jenkins, Kubernetes, Amazon Web Service, Zabbix.

— понимать основные принципы и философию DevOps;
— пользоваться инструментами для автоматизации процессов разработки;
— автоматизировать процессы деплоя с помощью инструментов CI/CD;
— понимать основные этапы и методы разработки ПО;
— четко видеть свою роль в процессах разработки;
— ориентироваться в современных системах хранения и обработки информации, в т. ч. «облачных»;
— лучше контролировать и управлять production, development и тестовыми средами

Это отличная возможность любому человеку, который крутится в IT, кардинально расширить свой кругозор, овладеть современными методиками разработки и продакшена приложений и сервисов. К тому же, как ты можешь догадаться, профессия открывает доступ и к другим, более высоким должностям. Курс от Level UP стоит недорого, поэтому рекомендуем записаться в ближайшее время, так как число мест ограниченно.

Как перейти из системного администрирования в DevOps

Содержание:

DevOps-инженеров не выпускают вузы и не готовят с нуля специализированные курсы – на новую для IT позицию большинство специалистов приходят из системного администрирования. Такой карьерный маневр позволяет сисадмину повысить профессиональную квалификацию, не переходя в разработку. Если вас заинтересовала эта возможность, то статья поможет вам сформировать представление о концепции DevOps и работе DevOps-инженера .

DevOps как концепция


Как DevOps меняет разработку ПО

Когда-то Agile существенно изменил процесс разработки в IT, а сегодня на индустрию так же сильно влияет DevOps. Первыми применять новую концепцию начали крупные корпорации, вроде Amazon и Facebook, которые стремились внедрять новые сервисы в свои продукты как можно быстрее. Сегодня DevOps практикуют компании по всему миру, что помогает им адаптироваться к современным IT-тенденциям: усложнению IT-инфраструктуры, переходу от физических платформ к виртуализации, необходимости частых обновлений приложений в ответ на запросы пользователей.

Несмотря на популярность DevOps, все еще не существует единой трактовки самого понятия. Чаще всего DevOps описывают как современную IT-методологию, когда фазы разработки и эксплуатации объединяются в один процесс для ускорения доставки ПО.

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

Чтобы ускорить процесс разработки и повысить качество релизов, компания решила следовать концепции DevOps. Вместо четкого разделения обязанностей, когда разработчики, тестировщики и системные администраторы отвечали только за свои этапы работы, не всегда представляя обязанности коллег, все отделы стали одновременно участвовать в релизах. Процесс работы автоматизировали: от сборки и тестирования до развертывания ПО. В результате DevOps-трансформации команда может выпускать обновления на рабочем сервере за считанные дни.

Практики DevOps

Новая концепция – это не ребрендинг широко известного подхода Agile. Гибкие методологии ускоряют процесс разработки продукта, а DevOps позволяет быстрее запускать новые релизы в рабочем окружении. Таким образом, DevOps дополняет Agile, позволяя ускорить процесс создания и обновления программного продукта, обеспечивая при этом его высокое качество. DevOps обозначает не только культуру взаимоотношений между командами разработки, тестирования и эксплуатации, но и конкретные технологические практики.

Непрерывная интеграция (Continuous Integration) – процесс, при котором разработчики ежедневно синхронизируют новую часть кода с основной веткой в системе контроля версий. Как правило, после сборки проекта запускаются автоматизированные тесты. Если будет обнаружена ошибка, то разработчик сразу получит оповещение и сможет приступить к исправлению дефекта.

Непрерывная доставка (Continuous Delivery) – практика, при которой проект после сборки попадает в тестовую среду, где проходит финальное тестирование перед установкой на серверах заказчика. В результате команда получает готовый к развертыванию релиз.

Непрерывное развертывание (Continuous Deployment) – процесс работы с релизом идет так же, как при непрерывной доставке. Но в данном случае изменения в исходном коде, как только проходят через этап QA, автоматически (без участия разработчиков) развертываются на рабочих серверах. В результате заказчик и пользователи получают обновления программы сразу после того, как они будут подготовлены.

DevOps как профессия

Когда менеджмент решает перейти к DevOps, команде IT-проекта нужно освоить конкретные практики и новые инструменты. В таком случае придется нагружать дополнительными задачами либо программистов, либо системных администраторов. Лучше нанять профессионала, который уже понимает суть DevOps и может помочь настроить все необходимые процессы. Так IT-сектору понадобился специалист с новым сочетанием навыков на стыке системного администрирования и программирования – DevOps-инженер. В Беларуси, по данным портала dev.by, DevOps-инженеры зарабатывают в среднем в два раза больше, чем системные администраторы. Такая разница обусловлена тем, что компетентный DevOps-инженер может повысить эффективность всего процесса разработки и зона его ответственности шире, чем у системного администратора.

В начале проекта DevOps-инженер может проектировать необходимую IT-инфраструктуру. Затем он контролирует, чтобы среда разработки и тестирования соответствовали условиям, в которых будет работать готовый программный продукт. Но в основном DevOps-инженер работает над проектом на этапе эксплуатации.

Если спросить DevOps-инженера, чем он занимается, то, скорее всего, он ответит «автоматизацией». Под таким определением скрывается целый спектр задач, которые можно условно разделить на три блока:

  • Автоматизация процессов доставки релизов из производственной среды в эксплуатацию.
  • Управление физическими и виртуальными серверами и их конфигурацией.
  • Мониторинг состояния инфраструктуры и поведения приложений.

Одна из основных задач DevOps-инженера – настроить платформы и инструменты для непрерывной интеграции, доставки или развертывания кода. Для автоматической сборки проекта и развертывания на серверах могут использоваться программы Jenkins, TeamCity, GoCD или Bamboo. DevOps-инженер пишет скрипт с последовательностью команд, которые один из этих инструментов автоматически выполняет на серверах.

Раньше системные администраторы настраивали каждый сервер вручную. Сегодня DevOps-инженер следует подходу «инфраструктура как код» (IaC), когда все скрипты для настройки серверов, как и код разработчиков, сохраняются в системе контроля версий. Удаленно координировать работу всех физических или виртуальных серверов можно через системы Chef, Puppet, Ansible или Kubernetes.

Для мониторинга состояния инфраструктуры DevOps-инженер может использовать системы Zabbix, Nagios или Prometheus. Например, Zabbix позволяет контролировать работу серверов, сетевого оборудования, баз данных и веб-приложений.

Что нужно знать системному администратору, чтобы стать DevOps-инженером

Опыт системного администратора – хорошая отправная точка для карьеры DevOps-инженера. Осталось дополнить этот бэкграунд специфическими для DevOps навыками.

Опыт администрирования ОС

Чтобы практиковаться в работе с операционной системой Linux, можно установить дистрибутивы Fedora или Ubuntu на своем компьютере. Если хотите в целом подтянуть свои знания в администрировании, то можно записаться на курсы. Например, в Минске в образовательном центре ПВТ программа по Linux длится месяц, а на образовательном портале Microsoft есть бесплатный курс по администрированию Windows Server.

Знание программирования

DevOps-инженеру нужно знать скриптовые языки программирования (Bash, Perl), на которых пишутся сценарии для настройки автоматизации. Чтобы повысить квалификацию, можно выучить один из языков общего назначения, например, Java или Python. Это поможет лучше понимать код разработчиков.

Понимание работы с облачными сервисами

Мастер Йода рекомендует:  Запросы к базе данных (команда select)

Сегодня наиболее востребованы облачные платформы от Amazon и Microsoft. Основные сервисы AWS, с которыми работает DevOps-инженер, – EC2, VPC, S3, RDS, ELB, EBS. Дополнительно можно изучить ECS, CloudFormation, OpsWorks, CloudWatch. Если вы еще не работали с AWS, то можете зарегистрироваться на официальном сайте – и получите годовой бесплатный доступ ко многим продуктам компании. Узнать больше об инструментах платформы поможет специализированный портал. Microsoft в конце 2020 года расширила список сервисов для платформы Azure DevOps. Для знакомства с ними можно выбрать бесплатные курсы на образовательном портале Microsoft.

Навыки работы с контейнерами

Контейнеры – это изолированные структуры, в которых можно развертывать приложения независимо от основной операционной системы. По сравнению с виртуальными машинами, контейнеры меньше весят и быстрее запускаются. Самый популярный инструмент для работы с контейнерами – Docker. И разработчик, и DevOps-инженер могут одновременно работать в Docker-контейнере. Пока разработчик пишет код самого приложения, DevOps-специалист создает конфигурационные файлы. Для запуска и управления контейнерами используются системы оркестрации, самая популярная из которых – Kubernetes. Разобраться в основах программы можно с помощью онлайн-курса от Linux Foundation.

Знание английского языка

В IT знание английского языка уже давно стало аксиомой. Но для DevOps-инженера это особенно актуально, ведь этот подход востребован в основном на проектах для зарубежных заказчиков, преимущественно из США. Английский пригодится и для самообразования, чтобы вы могли изучать новые технологии, не дожидаясь пока появится соответствующий курс на русском языке. Если в будущем захотите получить профессиональный сертификат (например, AWS Certified DevOps Engineer), экзамен, скорее всего, тоже нужно будет сдавать на английском.

Когда приступать к поиску работы DevOps-инженером

Обязанности DevOps-инженера на проекте сильно зависят от организации, в которой он работает. Многие белорусские компании только начинают вводить в штат эту должность, поэтому не требуют от кандидатов наличия соответствующего опыта. Начинайте искать работу, пока специальность все еще считается новой для нашего рынка.

Просматривая вакансии, обращайте внимание на другие названия, за которыми может скрываться эта роль: системный инженер, релиз-менеджер, инженер по автоматизации, D evOps-специалист. Чтобы лучше понять ожидания работодателей, сходите на несколько собеседований. После технического интервью обязательно просите фидбэк: каких знаний вам не хватает и какие еще технологии нужно освоить.

Мы уже упоминали некоторые технологии, которые применяются для DevOps-практик. Ниже представлен более полный список инструментов, встречающихся в вакансиях на позицию DevOps-инженера:

  • Система контроля версий (GitHub, SVN и др.).
  • Программа для непрерывной интеграции (Jenkins, TeamCity, Bamboo и др.).
  • Платформа для автоматизации развертывания ПО (например, Chef, Puppet, GoCD, Ansible).
  • Инструмент для мониторинга (Zabbix, Nagios, Prometheus и др.).
  • Облачная инфраструктура (например, AWS, Microsoft Azure).
  • Инструменты для работы с контейнерами (например, Docker, Kubernetes, Helm).

Вы можете устроиться junior DevOps-инженером – часто вакансии на эту позицию требуют лишь опыта в администрировании или начальных знаний необходимых технологий. Совмещая обучение с работой в компании, вы будете расти в профессии гораздо быстрее.

Карьерные перспективы в DevOps

DevOps как концепция будет и дальше развиваться, вбирая в себя современные практики разработки и эксплуатации. И ваша карьера в этом направлении может развиваться также динамично. DevOps-инженер хорошо понимает все процессы работы над проектом, поэтому в перспективе может перейти в менеджмент. Например, в США встречаются вакансии DevOps-менеджера, а вскоре такая позиция может появиться и на нашем рынке.

Мастеру на все руки: 5 лучших инструментов для DevOps

Содержание статьи

Ansible

Задача номер один в любой организации — автоматизация развертывания ПО и приложений, настройка серверов. На сегодня доступно более двадцати систем управления конфигурацией, из них самые известные — Chef, CFEngine, Puppet, но Ansible, появившийся позже всех, в 2012 году, пользуется наибольшей популярностью. Причина — низкий порог входа, максимальная простота работы и безопасность. На удаленных системах для управления не используются агенты, все производится через SSH. Для подключения настраивается беспарольная аутентификация при помощи ключей, также поддерживается LDAP и Kerberos.

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

Кроме Linux, работает и под другими ОС, включая и Win. Поддерживаются Cloud-сервисы — Amazon, Azure, Digital Ocean, сетевое оборудование некоторых производителей. Есть отсылка сообщений и многое другое. Задачи могут выполняться как поочередно на каждом узле, так и синхронно.

В Ansible для работы используется два файла. Один содержит список хостов, разбитых по группам (inventory), второй — список задач, которые нужно выполнить (playbook). Проекты обычно располагаются в отдельных каталогах. В качестве inventory по умолчанию используется /etc/ansible/hosts, хотя его можно указать в строке вызова плейбука, поэтому при работе с несколькими проектами inventory располагают внутри каталога проекта и указывают имя в строке запуска при помощи параметра -i. Группировать узлы можно как удобно, по назначению или расположению.

Есть еще два типа не SSH-подключения: local и docker. Поддерживаются группировка групп и переменные, динамическое создание списка узлов при помощи скрипта. Переменные подключения позволяют указать нестандартный порт, специфическую учетную запись для выполнения команд, ключ для входа и тому подобное:

Вся магия скрыта в плейбуках. В playbook используется формат сериализации данных YAML, который легко читается. Например, установка nginx при помощи модуля apt в Ubuntu/Debian выглядит так:

Оператор when позволяет добавлять в правило любые проверки.

Задачу быстрого старта упрощает хаб, предоставляющий готовые пользовательские решения буквально для всех задач. Достаточно лишь выбрать подходящий, скопировать вручную с GitHub или при помощи ansible-galaxy, и база для работы уже есть.

Каждая роль содержит список задач (task), шаблоны и файлы для копирования. Переменные в шаблонах позволяют подставлять разные параметры внутрь при копировании на узлы. Задачи выполняются последовательно, очередная начинает выполняться после успешного завершения текущей. В случае ошибки на каком-то узле он исключается из списка, на остальных выполнение продолжается. Это защищает от частичного выполнения playbook, но если задача связанная (например, развертывание кластера), то отсутствующий узел делает дальнейшее выполнение бесполезным. Например, проверим доступность всех узлов, описанных в файле inventory.ini, при помощи модуля ping:

Смотрим список узлов и проверяем синтаксис плейбука:

Ansible позволяет полностью реализовать идею Infrastructure as Code и отдать обычно сложные операции неспециалисту, которому после конфигурирования нужно будет выполнить одну команду. Хотя тому, кто создает playbook, все-таки нужно понимать процессы: установка одной-двух простых ролей обычно проходит без проблем, но, если ролей уже десяток, нужно запускать их в правильном порядке. Например, если сервис в кластере использует GlusterFS, то логично вначале ставить GlusterFS, а потом сервис. К тому же не всегда best practices применимы к некоторым приложениям. Например, перезагрузку сервиса рекомендуют делать не напрямую командой, а через handlers, который перезапускает его, когда логично. Но, например, при развертывании мастер — мастер кластера MariaDB лучше контролировать этот процесс вручную, поскольку handlers, как назло, перезапускает сервисы именно в тот момент, когда они синхронизируются.

Документация очень подробная и содержит множество примеров.

На Galaxy можно найти готовые плейбуки под разные задачи

Xakep #246. Учиться, учиться, учиться!

Prometheus + Grafana

Без системы мониторинга любое приложение — это черный ящик. Очень сложно сказать, что там происходит внутри при увеличении нагрузки. Сами приложения уже давно не монолитны, части взаимодействуют между собой по API, а их работу обеспечивает не только LAMP, но и другие сервисы (Elasticsearch, RabbitMQ. ). Метрики позволяют посмотреть работу компонентов в динамике и понять, где узкое место.

Одно из наиболее подходящих решений сбора метрик и мониторинга в современной динамической сети — связка Prometheus и Grafana. В Prometheus используется децентрализованная архитектура, позволяющая легко добавлять сервисы и серверы. На удаленные хосты устанавливаются агенты, которые при помощи заранее подготовленных установок обнаруживают автоматически запущенные на узле приложения, в том числе знают и про виртуализацию. Это все очень упрощает администрирование. Поддерживается оповещение и простые графики для визуального представления собранных данных. В настоящее время доступны агенты для узла (node_exporter), MySQL, Memcached, HAProxy, Consul, Blackbox, SNMP и другие. Также Prometheus может принимать метрики от клиентов сторонних разработчиков. Самый популярный — Telegraf, поддерживающий около 80 плагинов для получения метрик с Apache, nginx, Varnish, СУБД, Docker, Kubernetes, logparser и так далее.

Пакет Prometheus есть в репозиториях основных дистрибутивов, но там далеко не последняя версия, поэтому лучше брать бинарные сборки с сайта проекта. Все источники данных затем прописываются в /etc/prometheus/prometheus.yml, в форме:

В job_name прописываются хосты с одинаковыми настройками, labels позволяют отбирать затем метрики по дополнительным параметрам.

После конфигурирования проверяем отсутствие ошибок при помощи утилиты promtool.

И запускаем первый раз в консоли, чтобы видеть вывод:

Подключившись браузером на localhost:9090, можем увидеть информацию о работе Prometheus, просмотреть собранные метрики в виде данных или графиков, узнать статус агентов.

Метрик Prometheus собирает много, а штатный интерфейс по их визуализации сильно ограничен. Здесь на помощь приходит Grafana, умеющий из коробки выводить метрики, предоставляемые Prometheus, Graphite, InfluxDB, Elasticsearch, AWS и, при помощи плагинов, многими другими. После выбора источников (Data Sources) настраиваются дашборды. Поддерживается несколько вариантов графиков, а встроенный язык запросов позволяет получать любые данные. Причем на сайте проекта уже есть готовые dashboard (в формате JSON), которые легко импортируются и при необходимости редактируются. Для выбора правильных метрик можно воспользоваться поиском Metric lookup, расположенным правее строки Query. Но главное — поддерживаются шаблоны (Manage Dashboard → Templating). Так, указав переменную host (например, $host = label_values(host)), можно затем ее использовать в метриках вместо имени узла или IP:

После чего нужный узел надо просто выбрать в дашборде. Доступны алерты с возможностью отсылать сообщения по электронной почте, HipChat, Slack, Telegram и некоторых других. Для этого потребуется установить критическое значение метрики, введя значение вручную или перемещая сердечко справа от графика, и включить метод отправки предупреждений в Alerting → Notification List. Но в текущей версии 4.2 алерты не поддерживают дашборды с шаблонами. Поэтому необходимо под них создавать отдельный dashboard без шаблонов, в котором прописать только те параметры предупреждения, которые мы хотим получать. Обычно для этого просто копируют готовый график, убирая переменные.

Проект предоставляет исходный код и сборки для Linux, Windows, macOS и контейнер Docker. Для Ubuntu есть готовый пакет и репозиторий, поэтому установка сложностей не представляет. По умолчанию для сохранения настроек и данных используется SQLite. При большом количестве узлов имеет смысл использовать MySQL или PostgreSQL.

Графики Grafana наглядны и позволяют буквально увидеть проблемы

Выбор каналов для отсылки алертов в Grafana

Concourse CI

Автоматическая сборка проектов (Continuous Integration) после обновления кода экономит кучу времени, поскольку дает возможность сразу увидеть результат — есть ли прогресс и есть ли ошибки. Docker еще больше упростил задачу: протестировать можно сразу в разных средах. Приложений, позволяющих внедрить CI в процесс, сегодня много, но часто они не бесплатны и достаточно сложны, так что требуют привлечения специалиста. Concourse CI позволяет реализовать непрерывную интеграцию в короткие сроки, он прост в развертывании и не требует длительного изучения. Как строить Docker-образы при изменении кода в Git, можно разобраться буквально за пару часов. Также поддерживается интеграция с AWS S3, отправка уведомлений по email и HipChat, выполнение команд и многое другое.

Базируется Concourse CI на трех понятиях: задачи (tasks), ресурсы (resources) и задания (jobs). Задача в общем случае — это любая команда, используемая при сборке контейнера. Ресурс — это любой объект, состояние и версию которого можно отследить. То есть это именно то, что позволяет все запускать автоматически. Изначально подразумевается Git, хотя это может быть и просто таймер. Полный список официальных и неофициальных ресурсов доступен на сайте. Задание описывает действия, которые будут запущены при изменении отслеживаемых ресурсов или вручную. Сами действия описываются в плане сборки — тесты, выполнение команд и сборка контейнера Docker. Для выполнения нужного действия ресурсы и задания между собой связываются при помощи конвейера (pipelines). Данные о pipelines и журналы работы сохраняются в PostgreSQL, поэтому всегда можно сказать, кто что делал.

Параметры можно задавать как непосредственно в командной строке, так и в конфигурационном файле YAML. На сайте есть множество примеров, позволяющих разобраться в процессе. Для управления и ручного запуска заданий используется утилита Fly, просматривать результаты и запускать задания также можно через веб-интерфейс.

Проект предоставляет бинарники для Linux, macOS и Windows, готовые образы Docker и Vagrant.

Простой pipelines в Concourse CI

Функциональное тестирование


Деплой проекта — это лишь полдела, и без проверки работоспособности приложения он практически бесполезен. Поэтому любой мало-мальски дельный проект включает в себя QA-тестировщика, выполняющего пакет тестов и фиксирующего результат. Если приложение одно, то, наверное, вполне реально на промежуточных сборках провести некоторые базовые действия вручную. Если же результатом должен быть десяток образов для самых разных конфигураций, то без хотя бы простейшей автоматизации здесь не обойтись. Среди решений для тестирования веб-приложений особой популярностью пользуется Selenium, фактически ставший стандартом в этой области. Основой служит библиотека управления браузерами Selenium (ранее Selenium WebDriver), состоящая из клиентских библиотек на разных языках и драйверов браузеров. На сегодня разработаны драйверы для FF, Chrome, IE, Opera, Safari и ряда мобильных устройств. Они находятся на разных этапах разработки и, соответственно, требуют разного внимания. Также проект предоставляет Selenium IDE в виде расширения к FF, которое позволяет записывать, сохранять и воспроизводить сценарии тестирования любых приложений, доступных через браузер. Записанные сценарии сохраняются в формате HTML в виде таблицы, которую можно редактировать. Возможен экспорт в формат, понимаемый другими фреймворками для проведения тестов — NUnit, TestNG, JUnit, хотя, признаться, специалисты редко используют сгенерированные тесты в других средах, а все пишут сами.

Принцип работы прост. После установки Selenium IDE ярлык для запуска находится в меню «Инструменты» (Ctrl + Alt + S). Открываем в браузере сайт и начинаем запись. Затем последовательно выполняем все нужные действия. После записи можем запускать сценарий как вручную, так и по расписанию. Есть возможность устанавливать брейк-пойнты и регулировать скорость выполнения и прочее.

Для небольших проектов этого вполне достаточно, хотя это не вся автоматизация Selenium. Еще один элемент, разрабатываемый проектом, — Selenium Server, который позволяет выполнять в браузере команды, полученные из сценария, запущенного с локальной или удаленной машины. Хотя здесь, конечно, желательно уже познакомиться с фреймворком тестирования Behat, без которого точно не обойтись. Несколько серверов Selenium могут образовывать распределенную сеть (Selenium Grid), позволяющую легко масштабировать стенд автоматизации, запуская параллельно разные тесты на разных удаленных машинах, в итоге время тестирования сокращается. Плюс в этом случае — можно запустить Selenium Server с разными параметрами, а нужный узел будет выбран для теста автоматически. Основные вопросы освещены в документации проекта.

Тестирование в Selenium IDE

Supervisor

На сервере, особенно используемом при разработке, приходится запускать много всяких программ, установленных не при помощи системного менеджера пакетов, которые должны работать постоянно, перезапускаться в случае ошибки и рестарта сервера. Например, приложения Node.js, Selenium, самописные скрипты. В принципе, можно написать init/systemd-скрипты, но обычно это требует больше времени, и не всегда получается нужный контроль. Выходом из ситуации может быть менеджер процессов Supervisor, предлагающий простой и надежный способ управления работой таких приложений. Демон supervisord запускает процессы как дочерние, а поэтому может отслеживать и при необходимости их автоматически перезапускать. Для мониторинга работы и управления настройками на лету используется консольная утилита supervisorctl и веб-интерфейс (включается при помощи inet_http_server). Нужный пакет уже есть в репозиториях дистрибутивов, поэтому с установкой проблем не возникнет:

Конфигурационные файлы располагаются в /etc/supervisor/conf.d, файл должен иметь расширение conf. Традиционно настройки каждого сервиса производятся в одном файле. Хотя, если нужно запустить несколько копий с разными установками, можно для удобства прописывать в одном. Для примера настроим запуск Selenium через Supervisor.

Параметры очевидны. В program:selenium указывается имя, под которым сервис будет доступен в supervisorctl. В command указывается строка запуска программы со всеми параметрами, user — учетная запись, от имени которой будет выполнена программа. Далее каталог, в котором она будет запущена (он должен быть создан). Параметры autostart и autorestart определяют запуск программы при загрузке ОС и перезапуск в случае остановки. При true программа после остановки будет перезапускаться всегда, даже если она нормально отработает свой цикл. Если перезапуск нужен только в случае сбоя, следует использовать параметр unexpected. В документации можно найти еще много параметров на самые разные ситуации. Перечитываем конфигурацию:

Если ошибок нет, применяем настройки:

Если нужно отключить какой-то сервис, то лучше это сделать, используя интерактивный режим:

Появится приглашение, все команды можно узнать, введя help:

Вывод

Это то, что нужно обязательно знать. Но это только верхушка айсберга: DevOps за восемь лет оброс многочисленными инструментами и технологиями, а требования к специалисту разные. Поэтому учиться придется постоянно.

Что такое методология DevOps и кому она нужна

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

Что такое DevOps

DevOps — это методология разработки ПО, задача которой наладить взаимодействие программистов и сисадминов в компании. Если ИТ-специалисты из разных отделов недопонимают суть задач друг друга, выпуск новых приложений и обновлений для них затягивается.

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

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

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

Когда разработчик понимает, с чем сталкивается администратор при настройке сервера, он постарается сгладить возможные «острые углы» в коде. Это сокращает количество багов при развертке приложения — по статистике оно уменьшается примерно в пять раз.

Кому нужна и не нужна методология

Многие ИТ-эксперты считают, что DevOps принесет пользу любой организации, которая занимается разработкой ПО. Это справедливо даже в том случае, если компания является простым потребители ИТ-сервисов и не разрабатывает собственные приложения. В этом случае внедрение DevOps-культуры поможет сконцентрироваться на инновациях.

Исключение составляют стартапы, но и здесь все зависит от масштабов проекта. Если ваша цель — запустить минимально жизнеспособный продукт (minimum viable product, MVP), чтобы протестировать новую идею, то можно обойтись и без DevOps. Например, основатель Groupon в начале работы над сервисом сам вручную размещал все предложения на сайте и собирал заказы. Никаких инструментов автоматизации он не использовал.

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

Как внедрить DevOps

Далее — несколько рекомендаций для перехода на новую методологию.

Выявите проблемы в бизнес-процессах. Перед внедрением методологии выделите цели и проблемы организации. От них будет зависеть стратегия перехода на DevOps. Для этого составьте список вопросов, например:

  • На что уходит больше всего времени при обновлении ПО?
  • Можно ли автоматизировать этот процесс?
  • Влияет ли на это структура организации?

Подробно о выявлении проблем в организации можно почитать в книгах «Проект „Феникс“» и «Руководство по DevOps» от авторов методологии.

Поменяйте культуру в компании. Важно убедить всех сотрудников изменить привычные способы работы и расширить свой спектр компетенций. Например, в Facebook все программисты отвечают за жизненный цикл приложения целиком: от написания кода до внедрения. Также в Facebook нет отдельного отдела тестирования — тесты пишут сами разработчики.

Мастер Йода рекомендует:  Использование мета-боксов WordPress для создания SEO-плагина

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

Эксперты советуют первым делом внедрить инструменты распределенного контроля версий. С ними проще управлять исходниками. Среди таких решений наиболее известны Git, Mercurial, Subversion (SVN) и CVS.

Также стоит обратить внимание на системы непрерывной интеграции, ответственные за сборку и тестирование конечного продукта. Примеры таких инструментов: Jenkins, TeamCity и Bamboo.

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

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

Критика DevOps

Хотя методология помогает организациям быстрее принимать решения, касающиеся разработки приложений, сокращает количество ошибок в ПО и поощряет сотрудников учиться новому, у неё есть и критики.

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

Также считается, что DevOps не работает при плохом менеджменте. Если у команд разработчиков и администраторов нет общих целей, в этом виноваты менеджеры, которые не организуют взаимодействие между командами. Чтобы решить эту проблему, нужна не новая методология, а система оценки менеджеров на основе отзывов от подчиненных. Вот здесь можно почитать, какие вопросы следует включать в формы опросов для сотрудников.

Подведем итог — как внедрить DevOps:

  • Сформулируйте задачи, которые должна решить новая методология.
  • Обсудите решение с командой. Выслушайте мнения сотрудников и определите, какие инструменты автоматизации имеет смысл внедрить.
  • Автоматизируйте часть IT-процессов. Начните с задач, которые наибольшим образом годятся для автоматизации.
  • Анализируйте метрики. Соотносятся ли усилия на внедрение DevOps с пользой, которую приносит методология? Если нет, стоит изменить подход к внедрению или попробовать другую методологию разработки. Если да, продолжайте внедрять и анализировать новые инструменты.

Что еще почитать в выходные:

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Всегда был уверен, что DevOps — не методология, а вполне себе специальность человека, который занимается внедрением ПО вкупе с настройкой CI/CD, контейнеризацией и тд.

Спасибо, что прочитали.

В следующем материале как раз будет рассказ о работе DevOps-инженера: чем занимается такой специалист, какие компании нанимают, как в этой сфере развиваться и так далее.

Комментарий удален по просьбе пользователя

Я бы почитал с удовольствием. По мне так чем разнообразнее статьи на сайте — тем интереснее. Каждый посетитель найдёт что-то для себя.

Да и где писать такое в рунете? Хабр сдувается, к сожалению.

Комментарий удален по просьбе пользователя

На пикабу вам расскажут, что такое автослесарь и как стать кассиром в соседней пятерочке.

Чтобы после того, как вы собрали мвп из говна и палок вы понимали куда двигаться дальше.

Комментарий удален по просьбе пользователя

Руководитель компании должен хотя бы поверхностно понимать что куда развивается и что вообще есть.

Как иначе он наймет нужного инженера.

для этого есть ХРюши

Формирование команды одна из ключевых функций лидера.
И никакой кадровик не скажет вам кого нанимать. Они помогут подобрать человека под ваш запрос. Эйчара тоже кто-то должен нанять.

Мы с вами видимо из разных реальностей

Комментарий удален по просьбе пользователя

Комментарий удален по просьбе пользователя

Ага, у меня в конторе пару лет хотят внедрить DevOPS, даже соответствующие должности появились. Но кажется, за год никто так и не понял, кто такой DevOPS и для чего он нужен. Такое ощущение, что просто хотят ухватиться за ‘моду’.

Хотелось бы рассмотреть более конкретные примеры взаимодействия DevOPS с администраторами и разработчиками.

Комментарий удален по просьбе пользователя

Звучит ожуенно.
Пожалуй добавлю статью в избранное.

«Mercurial, Subversion (SVN) и CVS» — автор из берлоги вышел, где писал 5 лет статью?

«DevOps — это методология разработки ПО, задача которой наладить взаимодействие программистов и сисадминов в компании.»
Написано странно и непонятно.


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

Нужен ли Вам отдел DevOps или нет — зависит, соответственно, от количества серверов, количества и сложности приложений и навыков текущих сисадминов, может они уже по факту и так исполняют DevOps 🙂

Как стать DevOps-инженером за полгода или раньше? Часть 1

Примечание: это первая часть из цикла статей, посвященных DevOps.

Целевая аудитория

Вы разработчик и хотите направить свою карьеру в DevOps русло?

Или вы IT-специалист и хотите получить представление о том, что же такое DevOps?

А может быть вы ни тот, ни другой и просто хотите изменить свою карьеру, но не знаете с чего начать?

Если ответ на все вышеперечисленные вопросы — да, то наш цикл статей призван помочь вам во всем этом разобраться!

Кстати, даже если вы много лет занимаетесь DevOps, то данная статья все равно может стать полезной для вас.

Что же такое DevOps?

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

Что же, для вас я очистил определение от лишнего мусора и вот что получилось:

DevOps- это способ доставки программного обеспечения до конечного потребителя через коллективные боль и ответственность.

Хорошо, но что же это значит на самом деле?

Это значит, что, испокон веков, разработчики (люди, создающие программное обеспечение) имеют совершенно другие мотивы, нежели IT-специалисты (люди, которые запускают программное обеспечение).

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

Однако, как IT-специалист, мне нужно внедрить в продукт как можно меньше функций, так как каждая новая функция — это перемены, а перемены рискованны.

В результате этого разительного контраста и зародился DevOps.

DevOps пытается объединить разработку и обслуживание ПО в один рабочий процесс. Идея заключается в том, что коллектив будет делить между собой как боль, так и ответственность (и, предположительно, вознаграждение) за создание, внедрение и получение дохода от программного обеспечения, ориентированного на клиента.

Пуристы скажут вам, что не существует такого понятия как «DevOps-инженер». «DevOps — это культура, а не должность» — будут они вам говорить.

Да, да мы поняли. Технически они правы, но, как часто бывает, термин в конце концов вышел за рамки своего первоначального смысла.

Теперь, DevOps-инженер — это что-то вроде «Программного инженера версии 2.0»

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

В итоге, DevOps — это, по сути, «цифровые трубопроводы», по которым код из ноутбука разработчика движется вплоть до получения прибыли.

Обратите внимание, что если вы выберете в качестве карьеры DevOps сферу, вы легко сможете найти себе рабочее место, так как сейчас почти все компании поддерживают DevOps. Ну либо утверждают, что поддерживают.

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

ПРИМЕЧАНИЕ: Будьте осторожны с объявлениями, наподобие: «Требуется DevOps-команда» или «DevOps-отдел». Грубо говоря, такие объявления не должны существовать, так как DevOps — это культура и «способ доставки» программного обеспечения, а не специальный отдел или команда.

Дисклеймер

Теперь, отставим стакан газировки в сторону и рассмотрим следующее.

Слышали ли вы когда-нибудь изречение о том, что «в DevOps нет junior-инженеров»?

Если не слышали, то знайте, что это очень популярный троп на таких платформах как Reddit и Stack Overflow. Но что он означает?

Если говорить простым языком, он означает, что в DevOps приходят люди с многолетним опытом работы, в сочетании с четким пониманием своих обязанностей, чтобы в конечном итоге стать настоящим senior DevOps-инженером. К сожалению, на сегодняшний день, не существует короткого пути в DevOps сферу.

Здесь мы не будем говорить о том, как обойти сложившуюся тенденцию и кратчайшим путем попасть в эту сферу, так как я не думаю, что возможно притвориться senior DevOps-инженером, проработав всего несколько месяцев. Твердое понимание стремительно меняющихся инструментов и методологий занимает годы. Освоить такой объем за короткий промежуток времени невозможно.

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

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

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

Достаточно болтовни, с чего мне начать?

Ниже дан план, который приведет вас к желаемой должности.

Если вы пройдете его от начала до конца, то сможете смело называть себя DevOps-инженером! Или Cloud-инженером, если вам не нравится предыдущее название.

План, расположенный ниже, олицетворяет мое мнение(и, вероятно, большинства людей, работающих в этой сфере) о том, что должен знать любой уважающий себя DevOps-инженер. Однако, это всего лишь мнение и, безусловно, найдутся те, кто с ним не согласится. Это абсолютно нормально. Мы здесь не для того, чтобы достичь совершенства — мы здесь для того, чтобы построить прочный фундамент и потом, поверх него, начать строить основной каркас.

ПРИМЕЧАНИЕ: Вы должны преодолеть этот путь шаг за шагом. Начните с фундамента, не пропускайте его! Сначала изучите технологии, помеченные синим цветом (Linux|Python|AWS), затем, если позволяет время или этого требует нынешний рынок труда, изучите технологии, помеченные фиолетовым (Golang|Google Cloud).

Повторюсь, синий цвет обязателен, а фиолетовый нужен для углубления уже имеющихся знаний.

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

ПРИМЕЧАНИЕ: В схеме выше намеренно отсутствуют навыки, необходимые для тестирования ПО. Написание блоков кода, интеграция, приемочное тестирование традиционно ложатся на плечи разработчиков. Упущение фазы «тестирования» является преднамеренным действием, так как цель данной статьи — быстрое освоение новых навыков и инструментов. По мнению автора статьи, отсутствие опыта в тестировании — крайне незначительная помеха для трудоустройства.

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

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

Хорошо, копнем немного глубже!

Фундаментальные знания

Вверху статьи есть план под названием «Фундамент» с навыками, которыми должен овладеть любой DevOps-инженер.

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

Давайте разберем эти три столпа шаг за шагом.

Linux

Linux: там, где происходит вся магия. Можно ли быть DevOps-инженером, оставаясь при этом в экосистеме Microsoft? Конечно вы можете! Не существует закона, который бы предписывал работать исключительно в системе Linux.

Однако! Microsoft, безусловно, подходит для работы с DevOps задачами, но процесс работы будет гораздо дольше и болезненнее. На данный момент можно с уверенностью сказать, что нельзя стать настоящим профессионалом в DevOps сфере, не зная Linux. Так что Linux знать обязательно, не пытайтесь убежать от этого.

Как проще всего выучить Linux? Установите на домашний компьютер дистрибутивы Fedora или Ubuntu и используйте их как можно чаще! В процессе использования вам не раз придется ломать и чинить систему, сталкиваться с различными проблемами, благодаря которым, в конце концов, вы познаете Linux.

Для справки, в Северной Америке очень распространен дистрибутив Linux от компании Red Hat. Поэтому имеет смысл начать с Fedora или CentOS. Кстати, если не можете выбрать графическое окружение — KDE или Gnome, ставьте KDE. Его использует Линус Торвальдс.

Python

Python: самый распространенный язык для back-end’а в наши дни. С него легко начать, и он повсеместно используется во многих сферах. Бонус: Python широко распространен в сфере искусственного интеллекта и машинного обучения, поэтому, если решите этим заняться в будущем — вам практически ничего не придется учить.

Amazon Web Services: Без понимания того, как работает открытый облачный сервис невозможно стать DevOps-инженером. Amazon Web Services, пожалуй, лучшее место для изучения всей отрасли, так как он предлагает наиболее богатый набор инструментов для работы.

Вы спросите, можно ли начать с Google Cloud или Azure? Безусловно! Но после серьезного падения доллара, самым безопасным вариантом, по крайней мере, в 2020 году остается AWS.

При регистрации на AWS, вы получаете бесплатный уровень пользования сервисом на 1 месяц.

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

Шучу, это был сарказм. Хорошая новость в том, что вам не нужно знать каждую функцию AWS.

Начните со следующего: VPC, EC2, IAM, S3, CloudWatch, ELB и всех продуктов из меню «Безопасность, идентификация и соответствие требованиям». Этого достаточно для начала работы с облачными сервисами.

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

Я рекомендую вам уделять хотя бы по 30 минут в день на практику Python, Linux и AWS.

ПРИМЕЧАНИЕ: В целом, я считаю, что тратить ежедневно по часу, пять раз в неделю, достаточно для того, чтобы за 6 месяцев или меньше сложилось четкое представление о том, что происходит в DevOps сфере.

Но это касается только фундаментальных знаний!

В следующих статьях нашего цикла мы рассмотрим этапы: Конфигурирования, Версии, Пакеты, Внедрение, Запуск и Мониторинг программного обеспечения полностью автоматизированным способом.

DevOps Методология

DevOps (от англ. development и operations; по-русски обычно произносится как «дево́пс») — набор практик, нацеленных на активное взаимодействие специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимную интеграцию их рабочих процессов друг в друга. Базируется на идее о тесной взаимозависимости разработки и эксплуатации программного обеспечения и нацелен на то, чтобы помогать организациям быстрее создавать и обновлять программные продукты и услуги.

Содержание

Динамичные изменения, происходящие в мире технологий, предъявляют к современным компаниям более строгие требования к скорости реакции, времени выпуска релизов ИТ-систем и способности специалистов различного профиля открыто общаться и плодотворно сотрудничать. Не составляют исключение и разработчики встроенных систем. Востребованная методология непрерывной поставки решений предъявляет особые условия к организации проектных процессов, причем тестирование перестает быть заключительным и изолированным этапом всего цикла разработки. Однако, внедрение тестирования в качестве непрерывного параллельного разработке и сопровождению процесса порождает массу вопросов к практике такого внедрения.

Основной целью перехода на идеологию DevOps является желание улучшить и ускорить обслуживание клиентов. Сокращение затрат, увеличение автоматизации, улучшение управления конфигурацией, выполнение бизнес-запросов — это лишь сопутствующие задачи. При этом разным типам организаций может потребоваться разная структура команд для эффективного взаимодействия Dev и Ops.

С появлением в 2009 году методологии DevOps, которая должна была ответить на растущее количество вопросов к организации активного, непрерывного и продуктивного взаимодействия ИТ-специалистов в рамках проекта, компании разделились на лидеров и отстающих в зависимости от того, насколько хорошо им удалось адаптировать процесс тестирования к декларируемым принципам.

DevOps – относительно новая концепция, и у нее все еще нет четкого, общепринятого определения. По сути, это набор практик, нацеленных на активное взаимодействие и интеграцию специалистов по разработке, тестированию и сопровождению. Использование DevOps обеспечивает стабильное, быстрое и надежное развертывание ПО, в том числе и благодаря непрерывности тестирования, что позволяет избежать задержек и проблем с качеством, свойственных для классической модели проектной разработки.

Популярность методологии значительно возросла в последние годы. По данным RightScale 2020 State of the Cloud Report: DevOps Trends [1] , принятие DevOps увеличилось с 66% в 2015 году до 74% в 2020 году, а среди крупных организаций принятие методологии еще выше – 81%.

Внедрение DevOps – непростая задача для многих опрошенных нами компаний: ведь новая практика часто требует иного образа мышления и фундаментального сдвига в корпоративной культуре. И все же преимущества, которые DevOps и Agile обещают разработчикам, тестировщикам и всей команде, намного превосходят любые издержки.

  • Разработчики задействуются на проектах более эффективно
  • Проблемы выявляются на ранних этапах, а затраты на их устранение снижаются
  • Ускоряется цикл разработки и развертывания ПО
  • А главное, в итоге повышается удовлетворенность заказчика

Трансформация профессии системного администратора под влиянием DevOps

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

Топология команды DevOps

Какая структура или топология команды DevOps подходит для организации, зависит от многих вопросов, например:

  • Каков набор выпускаемых и поддерживаемых продуктов – чем меньше продуктов, тем больше взаимосвязь Dev и Ops.
  • Степень, сила и эффективность технического руководства — имеет ли Dev и Ops общую цель.
  • Готова ли организация на трансформацию роли ИТ эксплуатации от «принеси-подай» во встроенной в бизнес процесс.
  • Есть ли в организации лидеры, которые готовы указывать на проблемные области и сопровождать изменения.
  • Чаще всего построение «команды мечты» потребует последовательной смены нескольких моделей.

Использование в России

Сбербанк «подсел» на гибкую разработку: вслед за Agile — внедрение DevOps

Сбербанк внедряет практики DevOps в разработку автоматизированных систем. В качестве консультанта для этого банк по итогам конкурса в июле 2020 года привлек компанию McKinsey [2] .

Из опубликованной Сбербанком конкурсной документации следовало, что банк внедряет DevOps в части подпроцессов непрерывной сборки, развертывания и поставки (Continuous Integration, Delivery и Deployment). Автоматизированные системы для внедрения DevOps из числа целевых систем банка должны были быть выбраны совместно с McKinsey. Подробнее здесь.

«Альфа-Банк» ускорил ИТ-разработку в 60 раз за счет DevOps-культуры

«Альфа-Банк» считает внедрение культуры гибкого проектирования одним из главных своих достижений в ИТ в 2020 году. Это следует из годового отчета банка, опубликованного в конце июня 2020 года.

В 2020 году мы совершили большой шаг в сторону DevOps-культуры — культуры гибкого проектирования и интеграции операционных и проектных процедур — и смогли создать в

ИТ-блоке атмосферу, пропитанную идеологией тотальной автоматизации, — говорится в годовом отчете.

Добавить комментарий