Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!
Думаю тут над одною штукою і хотів би щоб DevOps відповіли на пару запитань:
1. Чи знаєте ви що таке ITIL v3, SSAE16/SAS70, ISO 27001?
2. Чи використовуєте ви щось із
3. Чи важливо перелічене для DevOps?
4. Чи відповідаєте ви за Availability сервісу? Security?
думаю, чем сильнее культура девопс будет проникать в большой энтерпрайз — тем больше эти базворды будут актуальны. Так же мне довольно часто приходят вакансии гибрида DevOps/SecOps, но о рынке тяжело судить по такой выборке. Среди обитателей стартаперской тусни в Долине я эти слова слышал намного реже, чем работая SecOps в украинской крупной компании
Дело в том что это далеко не баззворды, а стандарты и фреймворки кот-м ойойой сколько уже лет.
Коментар порушує правила спільноти і видалений модераторами.
-
jobs.dou.ua/...
3 вакансии security спецов. Мне кажется это все что надо знать о потребности в security в Украинской разработке :)
Вот так еще можно искать:
jobs.dou.ua/...
Это по баззвордам в вакансии а не профильной специализации. там и junior QA попадаются. Мне кажется безопасность в проекте не их ответственность.
мммм... Это скорее про аутсорс. Вон мирандагейт показал что безопасники нужны.
> ITIL, SSAE16, ...
Да, знаем. А еще PCI DSS, RFC и другие буквы =)
В подавляющем большинстве, когда девопс произносит «rtfm» — он подразумевает ITIL или RFC.
> Чи використовуєте ви щось із
А как иначе? Знать и не юзать?
> Чи важливо перелічене для 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 — можно говорить только о следовании реализациям (конкретным политикам, процедурам и инструкциям) некоторых доменов стандарта в процессе работы. При этом ни составление этих реализаций, ни аудит соответствия им в обязанности девопса входить не может по определению.
anonymous
Serhii Cherepanov
Ilya Trushchenko
Olena Mishakova
Tim Tretyak
Ярослав Удовенко
Sergii Voloshyn
Ярослав Удовенко
Andrey B
Vyacheslav
Vyacheslav
mobile mobile
Mykola Gurov
mobile mobile
anonymous
23 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів