Hot Positions, Cool Company! NeoGames
×Закрыть

Who is Mr DevOps?

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

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Похожие топики

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

1. нет
2. нет
3. нет
4. да

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 — можно говорить только о следовании реализациям (конкретным политикам, процедурам и инструкциям) некоторых доменов стандарта в процессе работы. При этом ни составление этих реализаций, ни аудит соответствия им в обязанности девопса входить не может по определению.

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