development and operations challenge

Управление Изменениями и Управление Релизами: преодоление барьера

Декабрь 2012

Алексей Ионин

• Проблема

• Разработка против Операций (Dev vs. Ops): Процессные расхождения

• Правильный подход

• Практики непрерывной поставки (Continuous Delivery)

• Поставка с фазами приемки (QA, UAT…)

Содержание

3

Проблема:

Самая важная проблема, которую мы выделяем как профессионалы в разработке ПО, следующая: если у кого-то появилась хорошая идея, как доставить её решение пользователям максимально быстро?Jez Humble; David FarleyContinuous Delivery: Reliable Software Releases through Build, Test, and Deployment AutomationPublisher: Addison-Wesley Professional

4

Dev-Ops дилемма

Ожидания бизнеса от ИТ постоянно растут

Разработка ведется все интенсивнее

Поддержка концентрируется на эффективности и стабильности

Когда эти два мира сталкиваются, начинается

настоящее «веселье»!

InnovationDemand

Agile Development

ReliableServices

Complete Chaos

Бизнес IT Операции Ops

IT Разработка Dev

• Проблема

• Разработка против Операций (Dev vs. Ops): Процессные расхождения

• Правильный подход

• Практики непрерывной поставки (Continuous Delivery)

• Поставка с фазами приемки (QA, UAT…)

Содержание

6

Apps

Разработчики творят в своих средах и на своих инструментах

Бизнес CIOРелизПотребност

ь

РазработкаIT Разработка

Dev

7

Разработчики имеют свои процессы и регламенты

Apps

РелизПотребность

Разработка

V-Model Waterfall Agile ScrumFa

ll

CMMI

CMII

SPICE

26262

DoD

8

В отделе обслуживания свои ITSM системы

Бизнес CIO

Операции

Запрос Исполнение

Услуга

IT ОперацииOps

9

Отдел операций следует своим процессам

SLA’s ITIL ITSM

Операции

Запрос

Услуга

Theory of Constraint

ITIL

Six Sigma

Process and

Operations Manageme

nt

CMM

Исполнение

10

А в результате..?

11

Overly complex processes?

“Слишком много процессов – это

примерно также плохо как и их недостаток.”

Robert Aiello; Leslie Sachs

Configuration Management Best Practices: Practical Methods that Work in the Real World

Publisher: Addison-Wesley Professional

Вывод 1: существенное число инцидентов как результат неудачного внедрения

изменений!

12

Вывод 2: слабый уровень взаимодействия между группами разработки и

сопровождения

13

Операции – тормозят всю разработку75% всех опрошенных определили, что именно в отделе обслуживания происходят все задержки с доставкой приложений бизнесу и не поддерживают Agile инициативы

Разработчики – не помогают в поддержке72% всех опрошенных определили, либо сотрудники сопровождения никак не могут взаимодействовать с разработчиками, либо разработчики только частично помогают в решении задач обслуживания Что в итоге?

91% всех опрошенных считают, что их бизнес спонсоры не считают ИТ полноценным партнером

14

Вывод 3: низкий уровень автоматизации процессов ITSM приводит к…

15

Процент респондентов, оценивших процессы ITSM как ручные или неопределенные

множественным нестыковкам процессов

Процент респондентов, оценивших интеграцию процессов как ручную или неопределенную

Вывод 4: Изменения и Релизы изолированы друг от друга

16

92% респондентов сообщают о наличие проблемы с управлением изменениями и релизами

29% не имеют информации о всех происходящих активностях25% не могут адресовать изменения достаточно оперативно

25% не могут определить статус доставки изменений

Вывод 5: Низкий уровень применения анализа влияния изменений

17

Анализируют влияние изменений в приложениях

Ограниченно либо совсем не используют информацию из CMDB/CMS

Анализируют влияние изменений в инфраструктуре

• Проблема

• Разработка против Операций (Dev vs. Ops): Процессные расхождения

• Правильный подход

• Практики непрерывной поставки (Continuous Delivery)

• Поставка с фазами приемки (QA, UAT…)

Содержание

19

Есть ли выход..?

20

Пока мы не выбросили все это…

“Недостаток процессов значит, что вы, вероятно, будете

постоянно делать одни и те же ошибки. Но вам также несомненно необходимо уверенно достигать

поставленных целей на повторяющейся основе.”

Robert Aiello; Leslie Sachs

Configuration Management Best Practices: Practical Methods that Work in the Real World

Publisher: Addison-Wesley Professional

21

Принцип 1: Договоритесь об Общем регламенте взаимодействия процессов

Потребность

Релиз

Приложения

Операции

Запрос Исполнение

Услуга

Разработка

DEV РЕЛИЗ OPS

CMMI

CMII

SPICE

26262

DoD

Theory of

Constraint

ITIL

Six Sigma

POM

CMM

22

Принцип 2: Процессы должны быть сквозные, интегрированные и единые для всех

TEST

OPS

DEV

Стандартизировать процесс разработки

Стандартизировать процесс тестирования

Стандартизировать процесс доставки

Принцип 3. Важность и ценность централизованного и версионного хранилища релизов (хотя бы)

23

РазработкаОперации

Услуга

Разработка

• Только проверенный код

• Только готовые сборки

• Четкий процесс сдачи

Релиз

• Подготовка структуры сборки для удобного развертывания

• Безопасный, закрытый и проверенный репозиторий

Операции

• Установка только из проверенного источника

• Интеграция с CMDB

24

Infrastructure as Code.

“You need to make it reproducible and programmatic. Hence virtual machines to shield software from configuration issues. Hence Puppet and Chef to automate configuration, so you know every machine has an identical software configuration and is running the right services. Hence Vagrant to ensure that all your virtual machines are constructed identically from the start.”

O'Reilly Radar (http://s.tt/1kHIs)

25

To Gold Image or not to Gold Image…

When you produce a “gold disk” and manufacture thousands (or millions) of copies, the penalties for getting something wrong are huge. If there’s a bug, you can’t fix it until the next release. In this environment, a software release is a huge event.

O'Reilly Radar (http://s.tt/1kHIs)

• Проблема

• Разработка против Операций (Dev vs. Ops): Процессные расхождения

• Правильный подход

• Практики непрерывной поставки (Continuous Delivery)

• Поставка с фазами приемки (QA, UAT…)

Содержание

27

Что на счет непрерывной поставки

PROD

UAT

UAT

UAT

DEV

DEV

DEV

DEV

DEV

28

Подход непрерывной поставки (Continuous Delivery) – в теории

DEV CI CI TEST UAT PROD

Automate• Validate

Deploy• Validate

• Проблема

• Разработка против Операций (Dev vs. Ops): Процессные расхождения

• Правильный подход

• Практики непрерывной поставки (Continuous Delivery)

• Поставка с фазами приемки (QA, UAT…)

Содержание

30

А на практике, непрерывная поставка… прерывается фазами приемки

DEV CI CI TEST GATE UAT GATE PROD

Непрерывная поставка на первых шагах

Фазы контроля приемки Операциями

Поддержка подхода DevOps

Интеграция процессов

31

Мифический метод?

@DEVOPS_BORAT: For understand devops terminology you need of replace 'continuous' with 'half ass automated'.

32

Принцип 4. Ценности DevOps во многом обеспечиваются реализацией принципов непрерывной поставки

Снижение рисков за счет реализации более частых и меньших изменений

Разработчики лучше понимают инфраструктуру, где работают их приложения

Поддержка получает представление о процессе разработки изменений

Простые интегрированные процессы образуют полный замкнутый цикл внедрения изменений

Процессы можно автоматизировать и свести влияние человеческого фактора на сбои в процессах к минимуму

Улучшение взаимодействия между группами Dev and Ops

Операции

QAРазработк

а

DevOps

33

Принцип 5. Постройте процесс. Пробуйте. Измеряйте. Оптимизируйте. Пробуйте. Измеряйте…

2. Просто для пользователейДля быстрой адаптации

5. Готовые отчеты и метрикиДля возможности постоянного совершенствования процессов

3. Наглядность и прозрачность

Для быстрого решения проблем

4. Готовое решение ITIL Для использования лучших практик

1. Гибкость процессного подхода

Для снижения TCO

34

Ответы на ваши вопросы

35

Спасибо

Major Financial Services FirmRealizing The Dev+Ops Vision

36

ITSM / OperationsService

Fulfillment6 Service desk tools to

replace

12+ Lotus Notes DBs

40+ Dev + Ops processes

2000 Global employees

Release

Serena Service Manager

Deployment Management

Production Incident Management

Vendor Management

Business Operations

Application Lifecycle

Management

37

Serena Software: Bridging Dev + Ops

Serena Service Manager +

Serena Release Manager

Integrates Dev + Ops

Process-based approach