Who is Mr DevOps?
Думаю тут над одною штукою і хотів би щоб DevOps відповіли на пару запитань:
1. Чи знаєте ви що таке ITIL v3, SSAE16/SAS70, ISO 27001?
2. Чи використовуєте ви щось із
3. Чи важливо перелічене для DevOps?
4. Чи відповідаєте ви за Availability сервісу? Security?
23 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів1. нет
2. нет
3. нет
4. да
1. Так
2. Так (ITIL)
3. Так
4. Так
думаю, чем сильнее культура девопс будет проникать в большой энтерпрайз — тем больше эти базворды будут актуальны. Так же мне довольно часто приходят вакансии гибрида DevOps/SecOps, но о рынке тяжело судить по такой выборке. Среди обитателей стартаперской тусни в Долине я эти слова слышал намного реже, чем работая SecOps в украинской крупной компании
Дело в том что это далеко не баззворды, а стандарты и фреймворки кот-м ойойой сколько уже лет.
Коментар порушує правила спільноти і видалений модераторами.
-
jobs.dou.ua/...
3 вакансии security спецов. Мне кажется это все что надо знать о потребности в security в Украинской разработке :)
Вот так еще можно искать:
jobs.dou.ua/...
Это по баззвордам в вакансии а не профильной специализации. там и junior QA попадаются. Мне кажется безопасность в проекте не их ответственность.
мммм... Это скорее про аутсорс. Вон мирандагейт показал что безопасники нужны.
> ITIL, SSAE16, ...
Да, знаем. А еще PCI DSS, RFC и другие буквы =)
В подавляющем большинстве, когда девопс произносит «rtfm» — он подразумевает ITIL или RFC.
> Чи використовуєте ви щось із1-го питання в своїй роботі?
А как иначе? Знать и не юзать?
> Чи важливо перелічене для DevOps?
Очень. Как людям, работающим на стыке областей и создающим интеграции — ДевОпсам крайне важно знать стандарты. Без этого — сразу пропадает эта штука странная, которую зовут «maintainability».
> Чи відповідаєте ви за Availability сервісу? Security?
Лично я? Частично. Т.е за сам сервер и каналы редко (т.к все железо «где-то у заказчика»), а за приложение, которое команда пишет — всегда.
Отнюдь. А инфраструктуру и прочее кто контролирует и планирует?
1. Так
2. Залежить від вимог до проекту.
3. Залежить від вимог до проекту.
4. Так (але в командній відповідальності)
У Вас аутсорс?
Якщо можете поділитися — які саме вимоги впливають?Скажемо так, розподілена співпраця з замовником, що також мав команду на своїй стороні.
Але —
подібний проект був єдиний в моєму досвіді, через специфічний предмет бізнесу, і специфічні вимоги до аудиту перед запуском. Та й сам аудит коштував серйозні гроші.
Значно частіше достатньо довести, що архітектура розгортання відповідає, припустимо, STIG рекомендаціям (простіше на порядок), і є вже наробки, інструкції для більшості популярних OS.
+ (IMHO) 95% стартапів взагалі не роблять з того проблему. Оскільки можна розподілити більше грошей на розробку, ніж на розгортання та інфраструктуру. («То ся зробить» :)
Ага, дякую.
Ага... А потім ринок реагує позитивно і в один прекрасний момент на заповнення RFP починає витрачатися купа часу. А потім виясняється що є купа клієнтів з цільового ринку яким потрібні ці всі речі, а архітектура тупо не є сек’юрною. І її треба переробляти. І де питається тоді ДевОпс? Не build and automation engineer а DevOps методологія?В цей момент вони в ідеалі беруть раунд інвестицій, а може і не один і тоді вже буде бюджет, і розширення команди, і рефакторинг, і формалізація процесів :)
А якщо ідея не вистрілила — тоді cut losses :)
я думал девопсы это те кто разворачивают инфраструктуру — типа там поднять сервера на амазоне, поставить на них код, какие то дженкинсы и автобилды прикрутить. А то шо в первом вопросе — то компетенция менеджеров девопса.
Ну вот как раз то что в первом вопросе как раз о том что это НЕ ТОЛЬКО компетенция менеджеров...
Вот вот вот. Об том то и речь. Только собственно пробелма в том что DevOps это не про дженкинс... И не позиция...ну итил и 27001 нельзя просто так силами одного чела вписать в проект, нужно планирование инфраструктуры и софта. а это как правило солюшин архитектор а не девопс, а девопс потом имплементит то что в солюшене и подпирает костылями что бы оно не падало.
Пока что из дискуссии видно, что комментирующие довольно сильно плавают в обоих стандартах даже в части их предназначения, не говоря уже о конкретных доменах.
А по сути — девопс может быть вписан, как роль, например, в релиз менеджмент ИТИЛ + change management, эти роли не сильно конфликтуют (хотя конфликтуют), но разумеется, ни он, ни солюшн архитект не могут исполнять большинство других ролей из стандарта.
Что касается 27001 — можно говорить только о следовании реализациям (конкретным политикам, процедурам и инструкциям) некоторых доменов стандарта в процессе работы. При этом ни составление этих реализаций, ни аудит соответствия им в обязанности девопса входить не может по определению.