Uncategorized

Обзор 360 ° DevSecOps Evolution от Danske Bank

Ключевые выводы

  • Существует несколько внутренних и внешних компонентов DevSecOps для масштабирования; найдите подходящие для вашего путешествия и свяжите их со своими результатами и выбранным подходом.
  • На протяжении всего пути вы столкнетесь с многомерными проблемами, большинство из которых не зависят от отрасли и контекста. Превратите их в возможности и убедитесь, что вы максимально используете свои фундаментальные возможности, даже если они могут быть несовместимы.
  • Сквозная операционная модель предприятия DevSecOps состоит из множества тактик, возможностей и структур. Создавайте индивидуальные решения с учетом вашего контекста, ожидаемых результатов и амбиций корпоративной стратегии. Не забывайте постоянно согласовывать общую картину и строить вокруг нее коалицию.
  • Существует несколько анти-шаблонов, которые реплицируются в различных реализациях DevOps, не зависящих от отрасли и контекста, в любом масштабе. Избегайте ловушек, обнаруженных нами в Danske Bank. Изучение антипаттернов других может сэкономить ваше время при масштабировании.
  • Ваше масштабное усыновление станет сокровищницей извлеченных уроков, и вы будете учиться буквально каждый день. Вам интересно узнать основные уроки, которые мы извлекли в Danske Bank?

В этой статье представлен обзор происходящего в настоящее время развития DevSecOps в Danske Bank. Во-первых, эволюция DevSecOps позиционируется в рамках более широкой трансформации, которую выполняет фирма. Далее очерчиваются основные факторы, способствующие и мотивирующие эволюцию. Ниже приводится список обнаруженных проблем, дающий яркую картину рассматриваемых областей, а также возможностей. Статья продолжается высокоуровневым обзором нашей новой операционной модели DevSecOps с описанием ее основных столпов. В заключение, мы обсуждаем обнаруженные нами антипаттерны, дополняя их неполным цитированием основных извлеченных уроков.

Важно отметить, что эволюция продолжается и приближается к концу 2022 года. Однако мы понимаем, что никогда не закончим полностью с DevSecOps, поскольку это непрерывный путь!

Это эволюция или преобразование DevSecOps?

По сути, это скорее эволюция, чем трансформация, которую мы проводим. DevOps как концепция исторически была принята в компании, и теперь мы определяем ее будущее развитие, согласовывая его с точки зрения 360 градусов; 360 градусов в том смысле, что мы фокусируемся на людях, операционных моделях, технологиях, процессах, культуре и многом другом. Другими словами, мы придерживаемся всесторонней корпоративной точки зрения.

Вся эволюция является частью более широкой трансформации, которая называется «Лучший банк к 2023 году». Три основные цели этой трансформации: 1) повышение гибкости предприятия, 2) цифровизация цикла взаимодействия с клиентами и 3) индустриализация технологий.

Основные факторы влияния

Фактически, основными факторами, способствующими этой эволюции, являются сочетание внутренних и внешних факторов.

С внутренней точки зрения, во-первых, мы хотели продолжить разработку, а в некоторых случаях перепроектировать наш SDLC. Мы хотели увеличить скорость выпуска и сократить время выхода на рынок, повысить продуктивность разработчиков, улучшить функциональную совместимость возможностей и модернизировать наш технологический ландшафт; Кроме того, найдите прагматическое равновесие между скоростью, надежностью и безопасностью, перенеся последние два как разумные в SDLC.

И последнее, но не менее важное: мы хотели разрушить разрозненные структуры (бизнес к ИТ и ИТ к ИТ) во внутренней экосистеме DevOps за счет улучшения совместной работы, коммуникации и коалиции в рамках нашего видения DevOps.

С внешней точки зрения, конечно, конкуренция является фактором. В эпоху цифровых потрясений время выхода на рынок и надежность услуг и продуктов имеют жизненно важное значение. Практика DevOps способствует улучшению этих аспектов качества.

Кроме того, наш банк строго регулируется несколькими требованиями и руководящими принципами FSA и EBA. DevOps и инженерные практики по обеспечению надежности сайтов могут помочь нам удовлетворить нормативные требования инновационным и спроектированным способом.

Основные проблемы масштабирования DevOps

Было несколько основных проблем; некоторые были настоящими проблемами, в то время как большинство – возможностями. Тем не менее, у нас определенно была прочная основа возможностей, которые были разработаны исторически, и мы могли развивать их, в определенных случаях реинжинируя их.

Основными из них были (и до сих пор в какой-то степени):

  1. Заблуждения DevOps: несколько раз мы обнаруживали, что по-разному понимаем и воспринимаем концепции DevOps. Это несколько раз приводило к тому, что мы терялись в переводе и в основном казались несогласными, в то время как по сути мы соглашались. В конечном итоге нам пришлось создать лексикон DevOps, чтобы убедиться, что мы говорим об одном и том же, говоря о скорости выпуска, самовосстановлении, политике против процесса и непрерывной доставке против непрерывного развертывания, чтобы упомянуть некоторые из них.

  1. Различная зрелость: у нас были значительные различия в уровнях принятия и зрелости DevOps в организации. Области, ориентированные на клиента, ушли довольно далеко с конвейерами CI / CD и облачной нативностью, например, в то время как другие области находились в минимальном минимуме ранних внедрений панели CI / CD. Уловить эти вариации с помощью данных и определить их основу было непросто. Нам нужно было приблизительно знать, как далеко каждая область находится от желаемого состояния, чтобы мы могли структурированно спланировать путь эволюции.

  1. Слабое доверие, но проверяйте: разработка и обеспечение соблюдения наших политик не были унифицированы для всех команд DevOps и технологической экосистемы. Анализ пробелов, согласование и реинжиниринг имели жизненно важное значение, обеспечивая при этом, чтобы «разработка политики» была встроена в нашу технологическую экосистему прямо из коробки. Может случиться так, что вы следуете политике, не осознавая ее, потому что она выходит «из коробки»; Другими словами, соответствие как кодекс.

  1. Фрагментация возможностей: мы были чрезвычайно новаторскими в обеспечении возможностей DevOps, хотя в некоторых случаях аспекты взаимодействия определенно могли быть улучшены. Некоторыми хорошими примерами были включение безупречных возможностей CI / CD, улучшение взаимодействия CI / CD и нашего инструмента ITSM, при одновременном переносе операций и безопасности. Картирование потока создания ценности на 360 градусов было необходимо.

  1. Дублирование возможностей: мы обнаружили несколько возможностей, которые были результатом внутренней разработки нескольких областей по отдельности. Стандартизация и гармонизация в определенных областях обеспечат впечатляющую окупаемость инвестиций. Сбор этих замечательных историй вокруг банка и их преобразование в централизованные возможности «как услуга» – прекрасная возможность, которая может улучшить эффект масштаба, снизить затраты и технический долг, а также повысить операционную эффективность. Это также поможет нам в обеспечении внутренней мобильности рабочих мест, в которую мы инвестируем.

  1. Создайте коалицию DevOps: все прошло просто великолепно! Но действительно, вначале мы потратили значительное количество времени на то, чтобы заинтересованные стороны, с одной стороны, поняли свою роль в материализации модели DevOps, а с другой стороны, пришли к единому мнению: «Да! Давай сделаем это”. Возможно, это был самый важный аспект эволюции.

Операционная модель DevOps на 360 градусов

Операционная модель DevOps на 360 градусов является многомерной, непрерывной, гибкой, автоматизированной и, прежде всего, простой.

Вкратце, это выглядит так же просто, как показано ниже, но по сути немного сложнее, учитывая характер эволюции корпоративного DevOps.

Столп 1 – Видение и WoW: эта часть посвящена целям, которые мы хотим реализовать, тому, как мы согласовываем DevSecOps с общей технологической стратегией (мы называем ее North Star), а также согласованием с нашей моделью Enterprise Agility, которая является Spotify one.

Компонент 2 – Разработка возможностей: это суть модели, которая состоит из простых слов, гарантирующих, что вспомогательные возможности спроектированы, совместимы и согласованы. Эти возможности включают чисто технологические аспекты (конвейер CI / CD) и эксплуатационную эффективность (разработка ITSM), а также соответствие нормативным требованиям (средства управления SDLC). Важно отметить, что мы согласовываем возможности в рамках потока создания ценности экосистемы DevOps.

Компонент 3 – Обеспечение возможностей: предоставление возможностей без принятия бессмысленно, поэтому вспомогательная часть модели имеет жизненно важное значение. В этом столпе мы в первую очередь сосредотачиваемся на двух аспектах. Во-первых, обеспечение согласованности и актуальности развертывания для всей организации. Для этого процесса мы используем модель под названием TIES (Themes-Initiatives-Epics-Stories). Тема – это набор возможностей, которые должны быть включены и приняты в организации, инициатива – это тактическое внедрение в бизнес-сообществах, в то время как эпики и пользовательские истории представляют собой работоспособные элементы невыполненной работы, реализующие различные инициативы. Мы следим за завершением и реализацией наших ежеквартальных обзоров бизнеса. Чтобы ускорить наглядность реализации преимуществ, мы также много инвестируем в аналитику, которая может обеспечить визуализацию прогресса практически «в реальном времени».

Во-вторых, мы фокусируемся на повышении наших инженерных навыков и изменении нашего менталитета и культуры там, где это необходимо. Наем и инкубация людей с инженерными навыками, работа в гильдиях для обеспечения гармоничной операционной эффективности, а также создание агентов изменений для продвижения нашей эволюции – вот некоторые из основных направлений деятельности.

Компонент поддержки играет еще одну жизненно важную роль. Он объясняет различным поставщикам коммунальных услуг и возможностей, какова их роль в головоломке DevOps, и поддерживает поддержку коалиции, а также постоянно проверяет температуру окружающей среды.

Столп 4 – Оставайтесь актуальными: мир DevOps быстро развивается, и мы хотим оставаться на острие. Мы много читаем, мы спорим с нашими избранными поставщиками, мы вместе посещаем конференции, мы делаем все возможное, чтобы оставаться актуальными, вдохновлять и вдохновляться. Посещение DevOpsCon Berlin 2021 – один из способов сделать это.

При масштабировании DevOps существуют антипаттерны

Давайте немного шире рассмотрим отрасль DevOps и сосредоточимся не только на Danske Bank. Я видел бесчисленное множество антипаттернов, повторяющихся на протяжении всей моей карьеры в DevOps. Наиболее очевидные и повторяемые из них – ниже.

Антипаттерн: пусть заблуждения будут

Прежде чем приступить к реализации концепций и, что более важно, в масштабе, убедитесь, что у вас есть твердое и широкое понимание их. Существует несколько заблуждений, которые могут привести к сбоям при включении DevOps и масштабируемости. Вот три примера:

  1. У нас есть конвейер CI / CD. Мы закончили DevOps.
  2. Автоматизируем ручные процессы. Мы делаем SRE.
  3. Моя скорость освобождения – 10 мин. Что еще мне нужно сделать?

Заблуждения будут иметь негативные последствия для вашего прогресса, а простое недопонимание во время встреч может привести к более серьезным последствиям, таким как неспособность коллективно реализовать преимущества, использование неправильного набора навыков или несоблюдение требований.

Антипаттерн 2: подчинение – враг

Хорошо, я понимаю, что в большинстве организаций комплаенс негативно воспринимается. Это может привести к тому, что при внедрении DevOps в некоторых случаях не будут соблюдены требования соответствия, поскольку они рассматриваются как препятствия на пути к производству. Следовательно, вы видите несколько вариантов внедрения DevOps, ориентированных в первую очередь на скорость. На мой взгляд, утверждение, что DevOps и комплаенс – враги, не соответствует действительности. Тем не менее, когда практики «соответствие как код» дополняются легким механизмом «доверяй, но проверяй», DevOps и комплаенс становятся лучшими друзьями.

Anti-Pattern 3: DevOps – это прежде всего работа разработчика.

Да, действительно, разработчик – главный участник внедрения DevOps, но не единственный. Сосредоточение внимания только на разработчиках просто нарушает поток создания ценности; это разбивает поток. DevOps – это прежде всего непрерывные потоки и устранение разрозненности. Есть несколько других заинтересованных сторон, таких как операции, основная инфраструктура, безопасность, корпоративная архитектура и управление процессами, которые в значительной степени заинтересованы в вашей трансформации DevOps. Сопоставьте соответствующие заинтересованные стороны с вашей экосистемой DevOps и потратьте время на объяснения и вовлечение.

Антипаттерн 4: Иррациональные КПЭ

Мы все это видели, верно? 100% доступность, автоматизация 50% регрессионных тестов, 10-минутная скорость выпуска, автоматизация до 0, 0 инцидентов P1. Важно установить хороший уровень амбиций; он управляет поведением, ожиданиями, обсуждениями бюджета и согласованием. Тем не менее, использование изолированных KPI, с одной стороны, и ненужных – с другой, является ошибкой. Вместо этого выбирайте KPI, основанные на релевантности в бизнес-контексте, специфике приложения и пути эволюции, а также в направлении полноты, глядя на свой SDLC от начала до конца. Сказав последнее, постарайтесь сбалансировать инновации, надежность, безопасность и соответствие требованиям в том, как вы устанавливаете и измеряете производительность.

Что мы узнали

Мы многому научились и продолжаем учиться каждый день. Ежедневные наблюдения, коридорные разговоры, опросы об удовлетворенности, сравнительный анализ и петли обратной связи помогают нам проверять температуру, обучаться, регулировать и двигаться дальше. Ниже приведены основные выводы.

  1. Сосредоточьтесь на людях!

Вовлекайте, слушайте, объясняйте, инкубируйте. Это люди, которые материализуют вашу трансформацию, и вам нужно ваше участие на разных уровнях; от пропаганды концепций до практического вклада и от принятия решений до простого высказывания мнения. Очень важно создать экосистему заинтересованных сторон, которые в разных формах и формах будут вносить свой вклад в разные области. Просто чтобы дать вам представление, в нашем DevSecOps CoE мы задействуем 15 областей поддержки, помимо наших бизнес-племен.

Кроме того, очень важно обеспечить людей, выполняющих «реальную работу», необходимыми ресурсами для выполнения своей работы. Вы не можете ожидать, что люди, например, начнут эффективно использовать вашу контейнерную платформу, если вы не обучили их работе с контейнерами, не имеете руководств по миграции и адаптации и не объяснили механизм соответствия, применяемый в жизненном цикле вашего контейнера.

  1. Не говорите людям, что именно им делать!

Поступая так, вы увеличиваете разочарование и убиваете инновации. Кроме того, вы не можете указывать каждой команде, как что-то делать; с одной стороны, у вас нет возможностей, а с другой стороны, вы не знаете подробно их контекст. Оставьте людям пространство для инноваций, уделяя больше внимания ожидаемым результатам. Конечно, по-прежнему важно предоставлять им шаблоны, структуры и рецепты, которые они могут применять и строить поверх, а также быть предписывающими, когда речь идет о вопросах соответствия и безопасности.

  1. Вы не Google, Netflix или Amazon

И вам не нужно быть в конце дня. Я хочу сказать, что можно черпать вдохновение из внедрения DevOps в крупных технологических компаниях, но не пытаться копировать их операционные модели, технологии и решения. Скорее всего, вы в конечном итоге будете пытаться добиться большего без решительных результатов. Например, я лично большой поклонник концепции Site Reliability Engineering, но нужно ли нам делать все, что Google делает на SRE? Нужно ли нам копировать принципы SRE? Есть ли у нас глобальные операции в течение 24/7 часов по всему миру? Ответ – нет. Вдохновляйтесь, да! Но принимайте их, исходя из вашего контекста и потребностей, формируя концепции и владея ими по-своему!

об авторе

Спиридон Маниотис имеет более 10 лет опыта работы на различных должностях в ИТ, как в отрасли (Danske Bank и Nordea Bank), так и в сфере консалтинга (Deloitte Consulting). Он хорошо разбирается в DevSecOps, SDLC, Cloud Native, технологической стратегии, управлении и эксплуатации ИТ-услуг, соблюдении нормативных требований, а также в гибких методологиях. В последние годы он сосредоточил внимание на преобразованиях DevSecOps в индустрии финансовых услуг, рассматривая операционные модели, внедрение и внедрение возможностей с точки зрения 360 °. В настоящее время он возглавляет Центр передового опыта DevSecOps в Danske Bank. Для него DevOps – это, прежде всего, философия, которую следует принять по существу и сосредоточить на результатах на уровне предприятия. «DevOps – это то, что вы из этого делаете», – в конце концов.

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button