Релокейт-опрос 2017 (для тех, кто уже уехал). Собрано более 1500 анкет.
×Закрыть

Who is Mr DevOps?

Думаю тут над одною штукою і хотів би щоб DevOps відповіли на пару запитань:
1. Чи знаєте ви що таке ITIL v3, SSAE16/SAS70, ISO 27001?
2. Чи використовуєте ви щось із 1-го питання в своїй роботі?
3. Чи важливо перелічене для DevOps?
4. Чи відповідаєте ви за Availability сервісу? Security?

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Who is Mr DevOps?
DevOps — это культура взаимодействия разных команд, таких как Dev, Ops, Security и т.д. для эффективного и быстрого достижения бизнес целей. Датальнее расписано в книге «The Phoenix Project»:

www.amazon.com/...g-Business/dp/0988262509

Иногда это даже формализуется созданием отдельной cross-functional команды, в которую входят представители Dev, Ops и Security команд.

Иногда, дествительно, так называют вакансию или title, но, как правило, за ним все равно скрывается либо Operations aware девелопер, либо Systems Engineer, знакомый с Software Development.
Наличие такой вакансии в компании скорее настораживает.

П.С.: Возникновение DevOps как явления связано с переходом от Watefall к Agile и, наверное, должно рассматриваться в этом контексте.

1. Так
2. Так (ITIL)
3. Так
4. Так

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

Дело в том что это далеко не баззворды, а стандарты и фреймворки кот-м ойойой сколько уже лет.

jobs.dou.ua/...acancies/?search=security
3 вакансии security спецов. Мне кажется это все что надо знать о потребности в security в Украинской разработке :)

Это по баззвордам в вакансии а не профильной специализации. там и junior QA попадаются. Мне кажется безопасность в проекте не их ответственность.

мммм... Это скорее про аутсорс. Вон мирандагейт показал что безопасники нужны.

> ITIL, SSAE16, ...

Да, знаем. А еще PCI DSS, RFC и другие буквы =)
В подавляющем большинстве, когда девопс произносит «rtfm» — он подразумевает ITIL или RFC.

> Чи використовуєте ви щось із 1-го питання в своїй роботі?

А как иначе? Знать и не юзать?

> Чи важливо перелічене для DevOps?

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

> Чи відповідаєте ви за Availability сервісу? Security?

Лично я? Частично. Т.е за сам сервер и каналы редко (т.к все железо «где-то у заказчика»), а за приложение, которое команда пишет — всегда.

В подавляющем большинстве, когда девопс произносит «rtfm» — он подразумевает ITIL или RFC.
Отнюдь.
> Чи використовуєте ви щось із 1-го питання в своїй роботі?

А как иначе? Знать и не юзать?

Отнюдь.
Т.е за сам сервер и каналы редко (т.к все железо «где-то у заказчика»), а за приложение, которое команда пишет — всегда.
А инфраструктуру и прочее кто контролирует и планирует?

1. Так
2. Залежить від вимог до проекту.
3. Залежить від вимог до проекту.
4. Так (але в командній відповідальності)

У Вас аутсорс?

2. Залежить від вимог до проекту.
3. Залежить від вимог до проекту.
Якщо можете поділитися — які саме вимоги впливають?

Скажемо так, розподілена співпраця з замовником, що також мав команду на своїй стороні.

Але —

подібний проект був єдиний в моєму досвіді, через специфічний предмет бізнесу, і специфічні вимоги до аудиту перед запуском. Та й сам аудит коштував серйозні гроші.

Значно частіше достатньо довести, що архітектура розгортання відповідає, припустимо, STIG рекомендаціям (простіше на порядок), і є вже наробки, інструкції для більшості популярних OS.

+ (IMHO) 95% стартапів взагалі не роблять з того проблему. Оскільки можна розподілити більше грошей на розробку, ніж на розгортання та інфраструктуру. («То ся зробить» :)

Ага, дякую.

+ (IMHO) 95% стартапів взагалі не роблять з того проблему. Оскільки можна розподілити більше грошей на розробку, ніж на розгортання та інфраструктуру. («То ся зробить» :)
Ага... А потім ринок реагує позитивно і в один прекрасний момент на заповнення RFP починає витрачатися купа часу. А потім виясняється що є купа клієнтів з цільового ринку яким потрібні ці всі речі, а архітектура тупо не є сек’юрною. І її треба переробляти. І де питається тоді ДевОпс? Не build and automation engineer а DevOps методологія?

В цей момент вони в ідеалі беруть раунд інвестицій, а може і не один і тоді вже буде бюджет, і розширення команди, і рефакторинг, і формалізація процесів :)

А якщо ідея не вистрілила — тоді cut losses :)

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

Ну вот как раз то что в первом вопросе как раз о том что это НЕ ТОЛЬКО компетенция менеджеров...

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

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

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

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

А по сути — девопс может быть вписан, как роль, например, в релиз менеджмент ИТИЛ + change management, эти роли не сильно конфликтуют (хотя конфликтуют), но разумеется, ни он, ни солюшн архитект не могут исполнять большинство других ролей из стандарта.

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

я думал девопсы это те кто разворачивают инфраструктуру
Вот хорошо про это написано:

newrelic.com/devops/what-is-devops

Born of the need to improve IT service delivery agility, the DevOps movement emphasizes communication, collaboration and integration between software developers and IT operations. Rather than seeing these two groups as silos who pass things along but don’t really work together, DevOps recognizes the interdependence of software development and IT operations and helps an organization produce software and IT services more rapidly, with frequent iterations.

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