Думаю тут над одною штукою і хотів би щоб DevOps відповіли на пару запитань:
1. Чи знаєте ви що таке ITIL v3, SSAE16/SAS70, ISO 27001?
2. Чи використовуєте ви щось із
3. Чи важливо перелічене для DevOps?
4. Чи відповідаєте ви за Availability сервісу? Security?
Who is Mr DevOps?DevOps — это культура взаимодействия разных команд, таких как Dev, Ops, Security и т.д. для эффективного и быстрого достижения бизнес целей. Датальнее расписано в книге «The Phoenix Project»:
www.amazon.com/...
Иногда это даже формализуется созданием отдельной cross-functional команды, в которую входят представители Dev, Ops и Security команд.
Иногда, дествительно, так называют вакансию или title, но, как правило, за ним все равно скрывается либо Operations aware девелопер, либо Systems Engineer, знакомый с Software Development.
Наличие такой вакансии в компании скорее настораживает.
П.С.: Возникновение DevOps как явления связано с переходом от Watefall к Agile и, наверное, должно рассматриваться в этом контексте.
1. нет
2. нет
3. нет
4. да
думаю, чем сильнее культура девопс будет проникать в большой энтерпрайз — тем больше эти базворды будут актуальны. Так же мне довольно часто приходят вакансии гибрида 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 — можно говорить только о следовании реализациям (конкретным политикам, процедурам и инструкциям) некоторых доменов стандарта в процессе работы. При этом ни составление этих реализаций, ни аудит соответствия им в обязанности девопса входить не может по определению.
я думал девопсы это те кто разворачивают инфраструктуруВот хорошо про это написано:
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.
Mykola
Сергей Черепанов
MEga Herz
Ilya Trushchenko
Ярослав Удовенко
Sergii Voloshyn
Ярослав Удовенко
Andrey B
Vyacheslav Voronenko
Vyacheslav Voronenko
mobile mobile
Mykola Gurov
mobile mobile
Tim Tretyak
Mykola
23 комментария
Добавить комментарий Подписаться на комментарииОтписаться от комментариев