Что учить devops инженеру

Как попасть в DevOps, как учиться и что читать

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

Данила Штань CTO в Яндекс.Вертикалях, пропагандирует DevOps, ценит soft-skills выше профессиональных навыков и любит поговорить. Вот, например, в прошлом году на еще тогда RootConf, Данила рассказывал, как построить самоорганизующуюся сервисную инфраструктуру, обходясь довольно простыми техническими решениями, популярными программными продуктами и соглашениями внутри команды.

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

— Что больше всего может помешать компании в DevOps трансформации?
«Я не буду делать чужую работу». Вообще деление работы на «свою» и «чужую».

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

— Как относишься к поднимающемуся хайпу вокруг SRE?
А он только поднимается? Мне казалось, что он давно тут. SRE — это glorified ops, мне эта концепция не очень нравится.

— Какие инструменты сегодня непременно есть там, где говорят о DevOps?
Клавиатура, экран и наушники 🙂

— Что отличает хорошего инженера от плохого с точки зрения DevOps?
Желание быть самым лучшим в мире специалистом по гайкам на 8.

— Как логичнее всего попасть в профессию? Ты сам вышел из Dev или Ops?
Логичнее всего любить то, что делаешь, а там всё срастётся. Я вообще из проджектов.

— Как учиться и что читать? Где ты чаще всего сам читаешь новости отрасли?
Люблю подборки на highscalability.com, форумы на Reddit и engineering blogs разных больших и маленьких компаний.

Вячеслав Кузнецов возглавляет команду IT Operations в Ecwid с ранних лет жизни проекта. Один из организаторов онлайн встреч сообщества Hangops_ru.

— Каково главное преимущество DevOps подхода, на твой взгляд?
DevOps позволяет значительно ускорить процесс разработки софта от идеи до релиза, избавиться от проблем в процессах разработки и сопровождения.

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

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

— Как интегрировать специалистов по безопасности в процесс поставки ПО?
Безопасник должен быть вовлечен в разработку на как можно более ранних этапах. При этом нужно вести диалог и строить процессы таким образом, чтобы инструменты безопасности были таким же естественным этапом, как linter или code review.

— Как относишься к поднимающемуся хайпу вокруг SRE?
На мой взгляд, SRE — это всего лишь реализация DevOps-практик и немного сверху. SRE book by Google является отличным собранием практик. Их хорошо знать для расширения кругозора, но не все из них нужны в каждой компании.

— Какие инструменты сегодня непременно есть там, где говорят о DevOps?
Чаты, CI/CD, K8S.

— Что отличает хорошего инженера от плохого с точки зрения DevOps?
Хороший инженер действует исходя из потребностей всей команды, а не только из потребностей своей ближайшей группы внутри команды.

— Как логичнее всего попасть в профессию? Ты сам вышел из Dev или Ops?
Важно, чтобы DevOps-подход решал реальные проблемы в твоей работе, тогда ты сможешь продать его команде. Я не выходил из Ops, этого не требуется, чтобы практиковать DevOps 🙂 У нас Ops-команда много пишет и постоянно автоматизирует свою работу. А команда разработки, в свою очередь, вплотную работает с инфраструктурой, также несет on-call дежурства и исследует инциденты.

— Как учиться и что читать? Где ты чаще всего сам читаешь новости отрасли?
Есть несколько хороших книг, которые раскрывают суть DevOps:

Для того, чтобы быть в курсе новостей индустрии есть куча отличных рассылок и каналов в Telegram: Devops Weekly от Gareth Rushgrove, Devops Deflope (подкаст и канал в Telegram), Hangops Ru. Но самые отборные новости индустрии прилетают ко мне в Twitter. Главное — фолловить правильных людей

Дмитрий Зайцев работает SRE в Humaniq, но имеет опыт в самых разных индустриях: Gamedev, AdTech, Big Data, FinTech. Развивал DevOps и SRE-практики тогда, когда это ещё не было модным. Совмещал их с ITIL и Cobit, пока они ещё были в моде. Кроме того, участвует в организации встреч Hangops_ru.

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

— Что больше всего может помешать компании в DevOps трансформации?
Отсутствие необходимости трансформироваться.

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

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

— Какие инструменты сегодня непременно есть там, где говорят о DevOps?

Хороший инженер фокусируется на скорости доставки по всей цепочке создания ценности, плохой — только на своей части цепочки.

— Как логичнее всего попасть в профессию? Ты сам вышел из Dev или Ops?
Устроится работать в компанию, у которой есть цифровой продукт. Я сам начинал офисным админом, потом Linux, Gamedev, разработка и снова эксплуатация.

— Как учиться и что читать? Где ты чаще всего сам читаешь новости отрасли?
Рекомендую прочитать:

Валерия Пилия работает в Deutsche bank на должности Infrastructure Engineer. Занимается автоматизацией деплоев и поддержкой продуктовых команд. До этого работала в Video International, в Мегафоне и OneFactor инженером эксплуатации, поддерживала и развивала платформы на базе Hadoop ecosystem.

— Каково главное преимущество DevOps подхода, на твой взгляд?
Сокращение time to market и бОльшая сопричастность всех к результату.

— Что больше всего может помешать компании в DevOps трансформации?
Инертность.

— Как интегрировать специалистов по безопасности в процесс поставки ПО?
Воспользоваться идеей Security Champions.

— Как относишься к поднимающемуся хайпу вокруг SRE?
Я за любой кипеж без драк, который даёт пищу для размышлений вокруг профессиональных практик и их применения в твоей конкретной компании.

— Какие инструменты сегодня непременно есть там, где говорят о DevOps?

— Как логичнее всего попасть в профессию? Ты вышла из Dev или Ops?
Я из Ops. Мне кажется, что и из тестировщиков можно попасть, было бы желание.

— Как учиться и что читать? Где ты чаще всего сам читаешь новости отрасли?
Классное обсуждение книг было в Hangops_ru, я лучше, чем там, не скажу. Плюс можно посоветовать книги Нассима Талеба и The DevOps Handbook.

Новости отрасли я читаю в канале Devops Deflope.

Михаил Чинков — Infrastructure Engineer в компании AMBOSS. А также евангелист культуры DevOps и участник сообщества Hangops_ru.

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

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

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

— Как интегрировать специалистов по безопасности в процесс поставки ПО?
Переучивать. Объяснять, что мир меняется, и степень профессиональной паранойи нужно постепенно уменьшать. Адекватный специалист быстро приспособится к потребностям бизнеса.

— Как относишься к поднимающемуся хайпу вокруг SRE?
Точно так же, как и к любой штуке, которая попадает в известный Tech Hype Cycle. Скоро люди начнут понимать, что такое SRE на самом деле, заставки/позиции в компаниях будут вымирать и в конечном итоге Site Reliability Engineering останется только в тех компаниях, где это действительно нужно.

На мой взгляд, SRE нужен только в чрезвычайных кейсах, когда масштаб слишком большой, а сил текущих облачных платформ/сервисов недостаточно для покрытия всех потребностей эксплуатации. Таких компаний во всем мире найдется максимум 20–25.

— Какие инструменты сегодня непременно есть там, где говорят о DevOps?
Важно разделять «говорят» и «делают». В большинстве компаний о DevOps говорят на протяжении нескольких лет, а воз и ныне там.

Там, где действительно люди стараются внедрить практики, есть: Public Cloud (чаще всего AWS), Kubernetes и Terraform. Остальные слагаемые меняются в зависимости от ситуации.

— Что отличает хорошего инженера от плохого с точки зрения DevOps?
Готовность к разделению ответственности за продукт, бизнес-центричность (человек не делает то, что не повышает business value), готовность проявить инициативу (например, стремление улучшить техническую сторону продукта вместо того, чтобы смириться с плохим и принимать как данность), интерес к обратной связи со стороны клиентов, как внутренних, так и внешних.

— Как логичнее всего попасть в профессию? Ты сам вышел из Dev или Ops?
Мне кажется, что сейчас профессия драйвить DevOps в компаниях, как бы ее не называли, переросла в отдельную предметную область, и логичнее всего учиться сразу тем вещам, которые требуются в компаниях: облака, мониторинг, delivery pipeline и так далее. Coding skill приходит сам в объеме, ровно необходимом для выживания.

Сам я вышел из админской комнаты родного Пензенского университета, даже не успев вкурить VLAN-ы и особенности поддержки iSCSI-storage, так что мой пример не самый лучший 🙂

— Как учиться и что читать? Где ты чаще всего сам читаешь новости отрасли?
Статьи лучше всего брать из рассылок DevOpsLinks, WebOps Weekly. Corey Quinn делает классную рассылку по AWS.

Из книг must-read это:

Андрей Шорин запускает взаимодействие людей там, где об этом раньше не думали. Везде видит возможности для изменений и любит их осуществлять. Гордится результатами работы в эксплуатации hh.ru (2011-2017).

— Каково главное преимущество DevOps подхода, на твой взгляд?
Готовность продукта ко вводу в эксплуатацию нас любом, даже самом раннем, этапе разработки.

— Что больше всего может помешать компании в DevOps трансформации?
Назначение виноватых. Разборы полётов с наказанием.

— Как интегрировать специалистов по безопасности в процесс поставки ПО?
Так же, как и DBA. Предложить им давать рекомендации и ставить задачи в backlog, отказавшись от права блокировать релиз. Это не будет просто.

— Как относишься к поднимающемуся хайпу вокруг SRE?
Я хорошо отношусь к идее и практике SRE. Хайп служит тому, чтобы больше людей узнали о её существовании. Люблю, когда команда вникает в суть, и видит за деревьями хайпа лес.

— Какие инструменты сегодня непременно есть там, где говорят о DevOps?

— Как логичнее всего попасть в профессию? Ты сам вышел из Dev или Ops?
Интересоваться не только алгоритмами и кодом, но и содержанием продукта, его значением для пользователя. Я перешёл на сторону DevOps из Operations, потому что через этот подход ИТ-мир становится лучше.

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

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

Виталий Рыбников помогает продуктовым командам внедрять DevOps и SRE подходы и практики. Работает SRE Тинькофф Банк.

— Каково главное преимущество DevOps подхода, на твой взгляд?
Непрерывное улучшение качества продукта.

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

— Как интегрировать специалистов по безопасности в процесс поставки ПО?
Им стоит поднять свои компетенции и интегрироваться в Pipeline, путем добавления и поддержки чекеров. Плюс поможет регулярный аудит инфраструктуры, поддержка и развитие автоматизированного monkey-patching.

— Как относишься к поднимающемуся хайпу вокруг SRE?
Так это ж… я его и поднимаю 🙂 Приходите к нам на митапы DevOps Moscow и на DevOpsConf, обсудим ;-Ъ

— Какие инструменты сегодня непременно есть там, где говорят о DevOps?

— Как логичнее всего попасть в профессию? Ты сам вышел из Dev или Ops?
Я думаю, что логичнее всего попасть из Dev, и сам я тоже вышел из Dev. И разработчиков лучше понимаешь, и уверен, что нет ничего невозможного.

— Как учиться и что читать? Где ты чаще всего сам читаешь новости отрасли?
Учиться хорошо на личном опыте и практике. Стажировка или курсы тоже могут быть полезны.

Читать советую все то же, что и коллеги. А я сам чаще всего читаю заявки на конференции, тематические каналы в Telegram. Офлайн общение на конференциях, чтобы быть в курсе течений и веяний, незаменимо.

DevOpsConf Russia уже 1 и 2 октября. Приходите в Инфопространство, там соберется 500 классных специалистов по интеграции всего и вся, вместе мы решим любые проблемы.

Источник

Кто такой DevOps и как им стать: план обучения

Авторизуйтесь

Кто такой DevOps и как им стать: план обучения

Кто такой DevOps-инженер, чем занимается и как им стать — рассказывает Василий Озёров, руководитель международной команды Fevlake и SVP of Infrastructure в Airpush Inc.

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

С Unix системами я познакомился в далеком 2005 году, ещё будучи учеником лицея. О да, те незабываемые ночи, проведенные за установкой FreeBSD и компиляцией KDE из исходников. К слову, именно благодаря этому я и нашел свою первую работу, где разрабатывал небольшие проекты на QT/C++, занимался настройкой Cisco, а также поднимал почтовые сервера.

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

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

Что такое DevOps?

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

Разработчики считали, что если код запустился у них локально, то нет проблем — можно запускать в продакшен. Если всё же проблемы возникали, то со стороны команды эксплуатации звучало: «Да это проблемы с кодом, пусть разработчики разбираются». Из-за такого подхода релизы продуктов постоянно затягивались и зачастую страдало качество конечного продукта. Сильно накладывало отпечаток ещё и то, что за один релиз выкатывалось очень много изменений и было очень трудно разобраться, что же породило проблемы на продакшене.

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

В целом можно выделить ещё несколько ролей. Например, Security Engineer, который будет отвечать за прогон security-тестов и изучение уязвимостей в используемых компонентах.

В реальном мире все (или почти все) эти роли по отдельности обычно совмещает какой-нибудь другой человек. К примеру, роль билд-инженера можно отдать в руки разработчика. Да и автоматизация настройки серверов обычно отдается системным администраторам. А DevOps-специалисту остаётся проработать и автоматизировать процесс сборки и доставки кода от разработчика в продакшн.

Что должен знать DevOps-инженер?

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

Senior System Administrator

Или хотя бы Middle. Идея в том, что вы должны на хорошем уровне разбираться в среде, в которой будут работать ваши приложения. Как они стартуют (init, systemd), что делать, если вы видите ошибку too many open files, использовать или не использовать swap. Все это очень сильно пригодится, когда вы будете запускать реальные проекты.

Networking — CCNA

Очень важная вещь, хотя про это забывают многие разработчики. Я считаю, что нельзя писать онлайн-сервисы, не понимая, как работает сеть. Никто не говорит, что надо заучивать семь уровней модели OSI, но точно потребуется знать, как работает IP, TCP/UDP и, конечно, протокол уровня приложения — например, HTTP, HTTP/2. Это сохранит вам кучу нервов выискивая причины ошибки Connection Refused.

Junior Developer

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

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

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

Junior DBA

На самом деле это входит в предыдущий пункт, но я все же решил его вынести отдельно. Поскольку все текущие проекты в любом случае используют базы данных, было бы неплохо уметь писать SQL запросы, использовать explain и понимать, как работают и зачем нужны index‘ы. Ну и до кучи посмотреть на популярные NoSQL решения.

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

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

Вообще DevOps-инженер — это больше про опыт, нежели про знание конкретного софта. Девопс-ребята постоянно учатся, изучают и тестируют новые проекты и технологии. Они должны постоянно задавать себе вопрос: улучшит ли эта технология наш проект? Что лучше выбрать в качестве языка: Ruby, Python, Go или написать на чистых плюсах? А как мы будем доставлять изменения в продакшен, чтобы не поломать работающие системы?

Главное, что надо понимать, — DevOps-специалист обладает действительно хорошим кругозором. Чтобы его расширить необходимо постоянно заниматься самообучением. Ниже я привел примерные шаги, которые помогут вам вырасти из, например, системного администратора в DevOps-инженера. Запомните: список всего лишь указывает направление, оттачивать навыки придётся вам самим.

Главной целью всех этих шагов является получение опыта работы с различными технологиями. Я уже говорил, что самое главное для DevOps-специалиста — это кругозор, так что берем эти же 17 пунктов и в каждом из них меняем технологию на новую. Писали приложение на Go? Теперь пишем на Ruby. Использовали Jenkins? Берём TeamCity. Поднимали Kubernetes? Настраиваем swarm. Таким нехитрым образом через несколько месяцев вы заранее сможете понять, что лучше использовать в конкретной ситуации, а это — самое главное качество грамотного и успешного DevOps.

Заключение

Да, стать DevOps-инженером с нуля не так-то просто, серебряной пули не существует. Не существует её и в любой другой области. Всегда придётся изучать, читать, пробовать. Но после 10-ой итерации вы войдёте во вкус. Вы не будете пропускать ни одной интересной софтинки, станете изучать и пробовать всё новое и неизведанное. А новое и неизведанное — это всегда круто. Кто бы там что ни говорил, дерзайте!

Источник

Гайд по DevOps для начинающих

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

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

Что такое DevOps

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

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

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

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

Вызовы для команды разработчиков

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

Проблемы, с которыми сталкивается операционная группа

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

Как DevOps решает проблемы разработки и операций

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

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

Противостояние DevOps, Agile и традиционного IT

DevOps часто обсуждается в связи с другими ИТ-практиками, в частности, гибкой и водопадной ИТ-инфраструктурой.

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

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

Жизненный цикл DevOps

DevOps подразумевает принятие определенных общепринятых практик.

Непрерывное планирование

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

Совместное развитие

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

Непрерывное тестирование

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

Непрерывные выпуск и развертывание

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

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

Непрерывный мониторинг

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

Постоянная обратная связь и оптимизация

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

Преимущества DevOps

DevOps может способствовать созданию среды, в которой разработчики и операторы работают как одна команда для достижения общих целей. Важной вехой в этом процессе является внедрение непрерывной интеграции и непрерывной доставки (CI/CD). Эти методики позволят командам быстрее выводить программное обеспечение на рынок с меньшим количеством ошибок.

Важными преимуществами DevOps являются:

Принципы DevOps

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

Разрабатывайте и тестируйте в среде, похожей на производственную

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

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

Развертывание с воспроизводимыми, надежными процессами

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

Мониторинг и проверка качества работы

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

Усовершенствование циклов обратной связи

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

В заключение

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

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя платные онлайн-курсы SkillFactory:

Источник