Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть

Как я получил сертификацию DevOps: нюансы подготовки и сдачи экзамена

Меня зовут Евгений Ласман. Я — DevOps-инженер в компании Provectus. За 12+ лет попробовал себя в роли системного администратора, инженера технической поддержки, тестировщика и программиста. Мой главный проект сейчас — это работа с Atlassian Platinum Solutions Partner. Кроме этого, я консультирую клиентов компании по направлению DevOps.

Fun facts: последние несколько лет работаю удалённо, до этого много «сидел в офисе», а ещё раньше несколько лет работал «очень удалённо», то есть в море на судне. Женат, две кошки, один ребёнок.

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

Начнем с важного.

Что такое DevOps institute

DevOps Institute (DOI) — это организация, которая помогает компаниям трансформировать IT-услуги в сферах Dev и Ops, а также процессы контроля качества, безопасности и даже продаж.

В разработке программ участвуют гуру DevOps из IBM, ITSM Academy, F5 и прочих. Это и заинтересовало, ведь они делятся опытом и реальными примерами внедрения DevOps-культуры.

Зачем DevOps-у сертификация

Исходя из моего опыта и отзывов участников, сертификация помогает:

  • Упорядочить и закрепить знания. Например, о том, из чего состоят CI и CD в деталях, о компонентах практик Lean и о том, что же такое Muda.
  • Расширить кругозор по теме DevOps. Например, что такое TKI (Thomas Kilmann Conflict Mode Instrument) и при чём тут DevOps; какие метрики успешности можно применять для оценки культурных изменений; какими аргументами можно «продать» DevOps бизнесу и пр. Как вариант, понять, что от тебя хотят Dev, когда ты Ops, и наоборот.
  • Больше работать с клиентами, проводить воркшопы. Мне, как технарю, интересно развиваться в направлении консалтинга. Если у вас такие же интересы — очень советую.

Для компаний, в которых вы работаете, особенно в роли консультанта, сертификация позволяет:

  • Однозначно квалифицировать вас, как DevOps-инженера.
  • Иметь в своем штате сертифицированного специалиста.
  • Развиваться в направлении тренингов, как внутри компании, так и для бизнеса.

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

Как устроен тест

Экзамен построен по принципу таксономии Блума с такой структурой:

  • Первый уровень (знания): в основном о концепциях и терминах DevOps;
  • Второй уровень (понимание): о применении концепций и терминов в контексте.

С некоторыми подходами и ответами даже на этапе подготовки я был не вполне согласен. Например, тенденция «Customer delight is more important than customer satisfaction» мне кажется довольно противоречивой. Это больше связано с моим личным опытом, а «сферический DevOps в вакууме», возможно, работает именно так.

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

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

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

  • введение;
  • общие принципы DevOps;
  • практики, фреймворки, культурные ценности;
  • вопросы по автоматизации, метриками, ролям в DevOps;
  • проблемы восприятия и внедрения DevOps культуры в бизнесе.

Как готовиться

После регистрации и оплаты экзамена DOI присылает подготовительные материалы. В их числе — пример экзаменационных вопросов, краткая шпаргалка по темам и конкретным терминам, которые must know для экзамена. Также есть довольно подробная презентация Learner Manual на несколько сотен слайдов, хотя и не построенная как обучающий материал. Я ее использовал скорее как референс тезисов для поиска нужной информации.

Что интересно, все материалы под NDA, однако они сами пишут, что «этот документ предоставляет ссылки на статьи и видео, связанные с темами экзамена DevOps Foundation, но, конечно же, всё это и гораздо больше вы можете найти в открытых источниках» и «мы приветствуем ваши комментарии и дополнения к этому списку».

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

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

  • DevOps.com;
  • DevOps Institute;
  • «2014 State of DevOps Report», Puppet Labs, IT Revolution Press, ThoughtWorks;
  • «Lean Enterprise: Adopting Continuous Delivery, DevOps, and Lean Startup at Scale», J. Humble, et al., O’Reilly Media, 2014;
  • «The Phoenix Project», G. Kim, et al., IT Revolution Press, 2013;
  • «Continuous Delivery», J. Humble, et al., Addison-Wesley Professional, 2010;
  • «Lean IT: Enabling and Sustaining Your Lean Transformation», S. Bell and M. Orzen. Productivity Press, 2010.

Я считаю, для того чтобы нормально ориентироваться в темах на экзамене, стоит прочесть «The Phoenix Project» или может даже «The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations», как более новую. Не стоит пугаться таких терминов, как SDLC, Agile, Scrum, Lean, Flow, Golden Circle, Three Ways, pipeline, CI, Continuous Delivery и Continuous Deployment и прочих подобных. Также желательно иметь какой-то опыт «продажи» DevOps бизнесу, лучше западному.

Как проходит экзамен

Тест состоит из 40 вопросов с возможностью выбрать несколько вариантов ответов. Примеров привести не получится, почему — чуть ниже.

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

Экзамен может проводиться в офисе компании-экзаменатора или же удаленно. Я выбрал второй вариант. Компания, которая проводит экзамен, — PeopleCert. После регистрации на экзамен на их сайте я выбрал дату и время (слот в 1,5 часа).

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

Звучит недостаточно паршиво? Ок, идём дальше!

После установки софта и его запуска соединяемся с контролирующим «с той стороны». Перед началом экзамена нужно на камеру показать телефон и убрать его подальше от себя, чтобы контролирующий мог видеть этот процесс. Тут я про себя отметил их просчёт и косность мышления — телефонов же может быть больше, чем один! Далее нужно показать камерой всю комнату (она у меня небольшая, так что хватило провернуться с ноутом на 360°).

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

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

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

В принципе всё достаточно логично и понятно, хотя по-честному лазеек, как схитрить, достаточно много, но я ничем не пользовался.

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

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

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


Вот так это происходит. Спасибо всем, кто дочитал до конца :)

Буду рад помочь и ответить на вопросы.

Дерзайте!

LinkedIn

Похожие статьи

70 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Так я не понял, что лучше: глянуть как работают тематические инструменты в azure/aws , а за одно и ясно станет зачем они и почему плохо без них, или поставить диплом ДевОпса рядом с дипломом МБА?

Одно другому не мешает.

Поздравляю!! Ура, товарищи!!
На ряду со «Свидетелями Скрама» у нас теперь будут еще и «Адвентисты ДевОпса», как и предеркалось.

А где самое главное — прибавка к жалованию за сертификат?

А вы с какой целью интересуетесь?

Даже если я скажу что есть, вы поверите?

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

Поверю, называйте цифру

Разве что только относительную — x1,5-2

Может у меня стереотипы какие-то, но эти люди не похожи на DevOps’ов, скорее на сейлзов — devopsinstitute.com/about/board-of-regents

Board of Regents на сайте, например Helen Beal Head of DevOps A Ranger4 с 95’го работала сейлзом...

Shredder не предлагать)

Чудесный скачок: от «devops — это культура[, а не человек]», к «теперь я обвешанный бумажками devops-инженер».

Как по-вашему наличие бумажки ухудшает понимание процесса/культуры?

По-моему, «DevOps engineer», как должность, противоречит той самой культуре.

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

Та не. Все просто. В старые времена, когда в моде были всякие эти ваши PHP, в чуть более продвинутых конторах, наряду со всякими стандартными PHP-девелоперами, и «злюками» QA, присутствовал чуть менее стандартный, но вполне себе стереотипный «бородатый одмин». Роль «бородатого одмина» сводилась к настроить все эти Apache, MySQL, PHP, репликации, «боронить и защищать» прод от этих мерзких девелоперов, и время от времени «рылизить» плоды их творчества. Это как раз тогда зародилась эта славная картинка когда «dev» и «ops» перекидываются какашками через стену.

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

Но не все так просто :) Во-первых, «продавать» кустомерам, если это аутсорс, «бородатых одминов» — сложно, а вот продавать шото модное, типа DevOps — легко. Во-вторых, можно объявить все эти ваши модные тулзы, которые типа «ваша жизнь стала теперь сильно проще», новым «вуду», и опять же продавать-продавать-продавать. В итоге те самые «бородатые одмины» превратились в DevOps-инжинеров, правда бородки теперь более хипстерские. К оригинальной идее, это правда имеет мало отношения.

И какова же оригинальная идея, по-вашему?

Деплоить, мониторить и вот этот вот все остальное, связанное с поддержанием приложения на «проде», должны делать те кто знает как это приложение работает, в идеале — те кто его и разрабатывает или тестирует, а не висящие в космосе опсы. Все просто :)

Ага, очень просто. А разрабатывать когда, если все заняты «Деплоить, мониторить и вот этот вот все остальное»?

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

Тогда зачем Ops если этим всем занимаются Dev?

так и не надо Ops, отдельнных от Dev. DevOps же все-таки :)

В сложных случаях Ops могут заняться платформ инжинирингом.

Стоп, стоп... А как же

должны делать те кто знает как это приложение работает, в идеале — те кто его и разрабатывает или тестирует

Вы уж определитесь.

Я вполне определился. Мы же все еще о культуре, а не о людях :)

У нас есть продукт. У нас есть условные software engineers, которые заниимаются всем: разработкой, тестированием, диплоем, мониторингом и всем-всем-всем. Они пишут это, они знают как оно работает, они это и расхлебывают от начала и до конца. Идеальная Agile-команда, кстати.

Если у нас много «продуктов», можем сделать для них общую платформу, со всякими там платформ инжинерами (ака опс), «продуктом» которых является сама платформа.

И как вы собираетесь уговорить бизнес прививать у себя эту культуру, «бородатыми одминами»?

а собственно зачем мне кого-то уговаривать?

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

Я правильно прочитал: «DevOps — это маркетинговый булщит для того чтобы непонятно шо, непонятно кому, всунуть подороже»? Я на самом деле не против такого определения, просто тогда оказывается что я думаю про это все гораздо позитивней, чем те кто двигает это в массы бизнеса :-D

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

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

это в том числе и умение организовать их совместную работу, наладить коммуникации как между Dev и Ops, так и между теми, кому этот Dev и Ops в итоге нужен, то есть тем самым business owners

DevOps — это культура управления? Чем отличается от других культур? :)

Тем что это не только

культура управления

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

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

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

настроить все эти Apache, MySQL, PHP, репликации

а иногда и вообще что-либо про то, как работает используемая СУБД, потому что «ну я тут просто в окне мышкой по HL-объектам клацаю, а дальше среда сама все делает»
и вот чтобы в таком бардаке прекратить волейбол между разными специалистами (в контексте — на чьей стороне мяч?) соответствующим институтом была предложена методология(!) DevOps — тесного взаимодействия Development+Operations+QA
которая по факту выродилась в fanny tools и лычку только для одной позиции из тройки
вот только ендкастомеру от того, что

релиз занимает не часы, а минуты

по-прежнему ни холодо ни жарко
потому что у него переход на новую версию по-прежнему занимает часы и дни
из-за объемов изменений на стороне СУБД

вот только в реальной жизни большинство девов ничего не знают дальше собственного кусочка кода в этом приложении

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

Тут возникает проблема. Предположим, есть web-based аппликуха. Есть cloud-based инфраструктура на AWS, Jenkins, Kubernetes, Docker, какая-нить собиралка логов ну и т.д. Есть процесс разработки, ориентированный на CI: деплой автоматизирован по крону на дев, on demand на stage и прод, тесты разбиты на группы, которые ранятся по коммиту (Unit tests, API tests, UI smoke tests) и те, что ранятся по релизу (дополнительно UI regression), версии тегируются автоматически. Поддержка этого всего хозяйства и, главное, его развитие — стоит времени. При выборе между сделать новую фичу, которая принесет денег или сделать какойто непонятный технический таск, любой нормальный кастомер (особенно если он слаб технически и не знает, что такое тот ваш дженкинс и нафига он ему нужен вообще) выберет 1-е. Соответственно, вопрос инфраструктуры будет всегда на 2-м месте и будет решаться только тогда, когда деплой станет тупо невозможен. Когда, собссно, решать его уже будет поздно. Таким образом, при данном подходе инфраструктура всегда будет отставать и будет чем-то типа плуга на мерседесе.
С другой стороны, в задачи девопса как раз и входит поддержка и развитие инфраструктуры, без вовлечения в задачи разработки. Таким образом, заказчику не придётся постоянно искать компромисс между тем, на что тратить время разработчиков.

Роль «бородатого одмина» сводилась к настроить все эти Apache, MySQL, PHP, репликации

Эта фраза отлично характеризует Вашу компетентность в данной области.

Возможно я не совсем правильно описал, извините, давно «простыней» на русском языке не писал 🤗
Вероятно правильнее было бы сказать что бумажка даёт понять «Эй, этот парень шарит в теме ДевОпс», а engineer это что-то из серии devopes engineering, в смысле как раз инжиниринга процессов трансформации.

что бумажка даёт понять «Эй, этот парень шарит в теме ДевОпс»

и что?
Тебе повысили зарплату или работодатели уже к тебе в очередь выстраиваются?
Или дай угадаю —
«Это нужно для меня!!!»

И первое и второе. А что?

Да нет, вообще нормально. Инженер — это человек, а который занимается инженерной деятельностью и у которого есть соизмеримые результаты труда. У DevOps инженеров — инфраструктура как код, платформа, описанный мониторинг и процессы, шифтинг культуры. Ответсвенность за всякие там SLA/SLO/SLI, и прочее.
Точно также можно сказать, что должность Scrum Master тоже протеворечит культуре) Но это, понятно, тоже не правда.

Формализация ухудшает любую культуру. Вспомните как давили холсты абстракционистов в СССР

Во всём должна быть мера, что в хаосе что в формализации.

Опять на вентилятор полетело порция)

Если не секрет, вы еще за это и деньги платили ?

Website
www.DevOpsInstitute.com
Headquarters
Boca Raton, FL

Year founded
2015

Company type
Privately Held

Company size
11-50 employees

Да, вас это удивляет?

Меня лично, в данном случае, да. Но каждый распоряжается своими деньгами на свое усмотрение. Если вам удастся продвинуться с этим по часовому рейту, карьере, и т.п. — супер

Так любая сертификация она такая — платная и каждому на своё усмотрение. Это типа как когда соискатель пишет «умею Windows/Linux/AWS etc.», а компания вместо того чтобы его проверять, просто спрашивает бумажку от проверяющей компании. Ну а последние тоже на что-то живут.

Сертификация — сертификации рознь. Как и вес сертификата. Есть признаваемые , обычно они сотрудничают с некой глобальной организацией аля Prometric Test Center. А есть — выдаваемые некими компаниями «с горы» — как в свое время у всех были пачки красивеньких сертификатов от BrainBench.

Формат (через вебкамеру дома) описанный вами существует — , к примеру у MongoDB , Hasso-Plattner-Institut и т.п. Но за ними стоит технология, профессура, имя организации.

Есть к примеру Project Management Institute (PMI) — имя, экзамен (кста у прометрика) . Есть похожее для BA -ев — iiba.org — более свежее, но все равно имя, экзамен (опять же у прометрика)

А что стоит за упомянутым институтом , который на самом деле private company? Сертификат, что вы понимаете концепты в отрасли ? Я с большей вероятностью возьму в команду парня, который имеет пройденным (даже подготовительный) курс AWS, Azure, CompTia. Даже дженкинс (sic!) ( www.cloudbees.com/...​ins/jenkins-certification ) - с удивлением обнаружил только-что :)))

Вы невнимательно читали — DOI не проводят экзамен и не они выписывают сертификат. Они всего лишь создают и курируют материалы курса, как впрочем и другие. И сертификация DOI абсолютно не техническая, для этого есть упомянутые выше.

Прямая речь от вас «Недавно я прошёл сертификацию от DevOps Institute» ; от кого вы получили сертификат в результате ?

И дальше

Компания, которая проводит экзамен, — PeopleCert

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

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

Запросто, и такое встречалось, но никто не совершенен.

попробуйте CCNA сдать без денег) с деньгами же любой дурак может)

CCNA и CCNP крупным заказчикам вендор иногда просто «дарит» через партнеров

Hе дарит, а в такой хитрый способ прикрывает жопу начальству. Типа у нас N сетевиков и половина из них CCNP. Тоже самое для vmware.
Знаю на личном опыте, ето больше для статистики и для циферок менеджера. А на самом деле CCNP сидит на телефоне, так как новенький, а архитектор — дядька с 10 годами без всяких сертификатов. А еще один с тремя CCIE закрылся в серверной и что-то там делает. В итоге 10 сетевиков на проект, 5 CCIE и 5 ССNP выглядид красиво, а по факту ето 3 человека.
Сорри за офтоп.

эндкастомеру дарит, а не интегратору :-)

Junior DevOps = Middle Admin+Developer

Ну ок. Большой разницы это не меняет.

Да. Не меняет. Но тут важны детали для понимания порога входа.

Подписаться на комментарии