Популярность DevSecOps, философии интеграции методов безопасности в DevOps, в последние годы набирает обороты. И чем больше людей проникается философией DevSecOps, тем больше мифов вырастает вокруг этого направления. Под катом мы разберем некоторые наиболее часто встречающиеся заблуждения.
Чтобы успешно интегрировать DevSecOps в компании, важен системный подход, не допускающий двусмысленных толкований. Если ранее вы краем уха слышали о методологии, однако не имеете фундаментальной базы, некоторые ошибочные суждения могут удерживать вас от внедрения этой, без сомнения, полезной методологии.
Нетрудно догадаться, где скрыты корни этого заблуждения. В сообществе разработчиков нередко можно столкнуться с мнением, что любые меры безопасности продукта (сверх понятных и привычных) являются ничем иным, как препятствием свободе и творчеству. Вместе с тем, тимлидам, руководителям проектов и прочим сотрудникам старшего звена дополнительные меры контроля только на руку. Измеримость работы и темпа ее исполнения — это крайне полезные метрики, как с точки зрения time-to-market, так и с экономической.
Некоторые разработчики переживают, что из-за внедрения DevSecOps и сопутствующих инструментов автоматизации их роль в команде может потерять значимость. Этот страх продиктован тем, что классические, ручные процессы дают (чаще всего ложное) ощущение рабочего процесса и контроля над результатом.
Таким образом получается, что страх потерять контроль из-за внедрения DevSecOps возникает не у руководителей, а преимущественно у исполнителей.
Побороть это заблуждение можно традиционным методом: обучением команды новой методологии, объяснением ее полезности. Не лишней также будет демонстрация успешных кейсов внедрения DevSecOps.
Сотни, если не тысячи многословных маркетинговых публикаций на тему DevSecOps создают информационный шум, в котором легко потерять реальное представление об этой методологии. Некоторым представителям бизнеса кажется, будто DevSecOps — это продукт или услуга, который можно внедрить наподобие PaaS или SaaS.
Разумеется, это представление в корне ошибочно. DevSecOps — это, в первую очередь, описание подхода к разработке, методология. Ее применение может включать использование некоторых специализированных программ и иных инструментов, платных и бесплатных, однако в качестве отдельного продукта DevSecOps нигде не продается.
Чаще всего это заблуждение возникает у руководства, когда ИТ-отделам поручают закупить DevSecOps-решения в целях повышения безопасности процессов разработки и эксплуатации. Побороть эту проблему можно точно так же, как и в случае с предыдущим «мифом»: обучением и квалификацией.
Согласитесь, было бы крайне удобно развернуть комфортную и безопасную среду разработки приложений, которая бы идеально подошла вашей организации, к тому же была бы не требовательна к обслуживанию и могла функционировать неограниченно долгое время. Увы, всё это не про DevSecOps.
Некоторые базовые концепции методологии применимы практически к любым организациям. Однако внедрение DevSecOps следует начинать максимально внимательно и осторожно, чтобы не навредить действующим в компании рабочим процессам. Каждая компания уникальна, обладает собственными корпоративной культурой, миссией и целями.
Определенные риски внедрения можно снять за счет инструментов автоматизации, на которых отчасти базируется DevSecOps. Однако человеческий фактор не менее важен для успешного старта. Ошибочно считать, что привычные процессы продолжат работать так же, как и прежде, без необходимости адаптации.
Из-за тесной связи двух этих методологий может сложиться впечатление, что одна от другой практически ничем не отличается. Фактически, это порождает следующий миф: DevSecOps имеет отношение только к вопросам улучшения процессов разработки, то есть без акцента на кибербезопасность.
Чтобы подходы DevSecOps работали, отделам безопасности, разработки и эксплуатации необходимо найти общий язык и наладить эффективную совместную работу. При этом методология не предусматривает главенство безопасности над всеми остальными процессами. Суть философии DevSecOps состоит в том, чтобы на стыке требований трех подразделений был найден оптимальный и подходящий вариант.
При этом отделам безопасности (здесь разработчики могут быть спокойны) также придется внести коррективы в свои привычные процессы и интегрироваться с другими отделами. Ключом к развенчанию мифа о том, что DevSecOps связан только с разработкой/эксплуатацией, будет превентивная квалификация всех участвующих сторон.
Мы решили объединить два этих мифа под одним заголовком, поскольку они имеют общий корень. Представление о DevSecOps как об исключительно технологической методологии ошибочно, поскольку оно игнорирует людей как факторы рабочего процесса. В чем-то это заблуждение сходно с предыдущим.
Технологии, безусловно, являются ключевым компонентом DevSecOps, но ни в коем случае не единственным. Большое значение имеет то, как люди работают вместе для улучшения процессов.
И напротив, полагать, что DevSecOps рассматривает сугубо вопросы изменения внутренней культуры отделов разработки, также не стоит.
Кстати, теме DevSecOps посвящен отдельный урок нашего бесплатного курса Cloud DevOps. Вести его будут эксперты #CloudMTS, VMware, Microsoft.
На курсе вы сможете:
Ознакомиться с программой Cloud DevOps, экспертами и зарегистрироваться можно на странице курса. Удачи в освоении новых знаний!
Чтобы успешно интегрировать DevSecOps в компании, важен системный подход, не допускающий двусмысленных толкований. Если ранее вы краем уха слышали о методологии, однако не имеете фундаментальной базы, некоторые ошибочные суждения могут удерживать вас от внедрения этой, без сомнения, полезной методологии.
Внедрение DevSecOps приводит бизнес к потере контроля над процессами разработки
Нетрудно догадаться, где скрыты корни этого заблуждения. В сообществе разработчиков нередко можно столкнуться с мнением, что любые меры безопасности продукта (сверх понятных и привычных) являются ничем иным, как препятствием свободе и творчеству. Вместе с тем, тимлидам, руководителям проектов и прочим сотрудникам старшего звена дополнительные меры контроля только на руку. Измеримость работы и темпа ее исполнения — это крайне полезные метрики, как с точки зрения time-to-market, так и с экономической.
Некоторые разработчики переживают, что из-за внедрения DevSecOps и сопутствующих инструментов автоматизации их роль в команде может потерять значимость. Этот страх продиктован тем, что классические, ручные процессы дают (чаще всего ложное) ощущение рабочего процесса и контроля над результатом.
Таким образом получается, что страх потерять контроль из-за внедрения DevSecOps возникает не у руководителей, а преимущественно у исполнителей.
Побороть это заблуждение можно традиционным методом: обучением команды новой методологии, объяснением ее полезности. Не лишней также будет демонстрация успешных кейсов внедрения DevSecOps.
DevSecOps — это некое решение, которое можно купить и развернуть у себя
Сотни, если не тысячи многословных маркетинговых публикаций на тему DevSecOps создают информационный шум, в котором легко потерять реальное представление об этой методологии. Некоторым представителям бизнеса кажется, будто DevSecOps — это продукт или услуга, который можно внедрить наподобие PaaS или SaaS.
Разумеется, это представление в корне ошибочно. DevSecOps — это, в первую очередь, описание подхода к разработке, методология. Ее применение может включать использование некоторых специализированных программ и иных инструментов, платных и бесплатных, однако в качестве отдельного продукта DevSecOps нигде не продается.
Чаще всего это заблуждение возникает у руководства, когда ИТ-отделам поручают закупить DevSecOps-решения в целях повышения безопасности процессов разработки и эксплуатации. Побороть эту проблему можно точно так же, как и в случае с предыдущим «мифом»: обучением и квалификацией.
DevSecOps — это универсальная модель, подходящая всем «из коробки»
Согласитесь, было бы крайне удобно развернуть комфортную и безопасную среду разработки приложений, которая бы идеально подошла вашей организации, к тому же была бы не требовательна к обслуживанию и могла функционировать неограниченно долгое время. Увы, всё это не про DevSecOps.
Некоторые базовые концепции методологии применимы практически к любым организациям. Однако внедрение DevSecOps следует начинать максимально внимательно и осторожно, чтобы не навредить действующим в компании рабочим процессам. Каждая компания уникальна, обладает собственными корпоративной культурой, миссией и целями.
Определенные риски внедрения можно снять за счет инструментов автоматизации, на которых отчасти базируется DevSecOps. Однако человеческий фактор не менее важен для успешного старта. Ошибочно считать, что привычные процессы продолжат работать так же, как и прежде, без необходимости адаптации.
DevSecOps — это брат-близнец DevOps’а
Из-за тесной связи двух этих методологий может сложиться впечатление, что одна от другой практически ничем не отличается. Фактически, это порождает следующий миф: DevSecOps имеет отношение только к вопросам улучшения процессов разработки, то есть без акцента на кибербезопасность.
Чтобы подходы DevSecOps работали, отделам безопасности, разработки и эксплуатации необходимо найти общий язык и наладить эффективную совместную работу. При этом методология не предусматривает главенство безопасности над всеми остальными процессами. Суть философии DevSecOps состоит в том, чтобы на стыке требований трех подразделений был найден оптимальный и подходящий вариант.
При этом отделам безопасности (здесь разработчики могут быть спокойны) также придется внести коррективы в свои привычные процессы и интегрироваться с другими отделами. Ключом к развенчанию мифа о том, что DevSecOps связан только с разработкой/эксплуатацией, будет превентивная квалификация всех участвующих сторон.
2 мифа в одном: DevSecOps — это только про технологии/это только про корпоративную культуру
Мы решили объединить два этих мифа под одним заголовком, поскольку они имеют общий корень. Представление о DevSecOps как об исключительно технологической методологии ошибочно, поскольку оно игнорирует людей как факторы рабочего процесса. В чем-то это заблуждение сходно с предыдущим.
Технологии, безусловно, являются ключевым компонентом DevSecOps, но ни в коем случае не единственным. Большое значение имеет то, как люди работают вместе для улучшения процессов.
И напротив, полагать, что DevSecOps рассматривает сугубо вопросы изменения внутренней культуры отделов разработки, также не стоит.
Кстати, теме DevSecOps посвящен отдельный урок нашего бесплатного курса Cloud DevOps. Вести его будут эксперты #CloudMTS, VMware, Microsoft.
На курсе вы сможете:
- узнать о стратегиях миграции с монолита на микросервисы;
- изучить основы Kubernetes;
- познакомиться с контейнерным подходом;
- разобраться с тонкостями Kubernetes в продуктивной среде;
- освоить инструменты автоматизации процессов, реализации CI/CD;
- оценить возможности MLOps-платформы.
Ознакомиться с программой Cloud DevOps, экспертами и зарегистрироваться можно на странице курса. Удачи в освоении новых знаний!
