Портал №1 по управлению цифровыми
и информационными технологиями

DevOps: «до» Dev и «после» Ops

linkУже знакомый нам Марк Смолли (Mark Smalley) предлагает взглянуть на философию DevOps с позиции всей цепочки создаваемой ИТ ценности. Многим из тех, кто знаком с DevOps не просто на уровне знаю-как-расшифровывается, давно известны три основополагающих принципа, которые описаны в книге, обязательной к прочтению для всех интересующихся данной темой — "The Phoenix Project: a Novel about IT, DevOps and Helping Your Business Win", или "Проект Феникс". На них основаны все модели DevOps. Принципы характеризуют ценности и философию, на базе которых создаются процессы, процедуры, практики. И эти принципы следующие:

1. Системное мышление.
2. Расширенные циклы обратной связи.
3. Культура непрерывного обучения и экспериментирования.

Первый принцип подчёркивает важность работы всей системы, а не только отдельных её частей, будь то функциональное подразделение / департамент (например, Департамент разработки или Департамент эксплуатации) или отдельно взятый специалист (например, разработчик или системный администратор).

Второй принцип говорит о создании информационного обмена для непрерывного внедрения корректировок. Он заключается в понимании и реагировании на запросы любых заказчиков — внешних и внутренних, укорочении и усилении всех циклов обратной связи.

Наконец, третий принцип — про создание культуры, которая благоприятствует постоянному экспериментированию. Это требует принятия рисков "safe-to-fail" (поведение, характеризующееся перекладыванием вины за неудачи и провалы на внешние обстоятельства. "Я не терпел поражений. Я просто нашёл 10 000 способов, которые не работают" — Томас Эдисон), анализа успехов и неудач, а также понимания, что постоянное повторение является ключом к мастерству.

Бесспорно, отмечает Марк, это хорошие принципы и их можно применять во многих областях, но давайте посмотрим, что происходит "до" разработки и "после" среды эксплуатации. Перед тем как начнётся, собственно, сама разработка, кто-то из бизнеса видит возможность делать работу лучше, быстрее, дешевле при помощи ИТ. Так появляются требования. И хотя это ещё стадия пре-разработки, для неё применимы те же самые три принципа. Давайте взглянем на них в этом контексте:

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

После внедрения — ключевого вида деятельности DevOps — решение становится доступным для пользователей. Когда сотрудники используют разработанное решение эффективно, то получается польза для бизнеса. Но, кажется, это самое слабое звено в цепочке создаваемой ИТ ценности. Вспомните свой собственный опыт. Действительно ли ИТ-системы используются так, как было задумано, а пользователи получают досточно поддержки, чтобы правильно и эффективно их использовать? Давайте снова взглянем на три принципа:

7. Для Департамента эксплуатации нужно быть в курсе того, почему и как пользователи используют информационные системы и услуги. Только тогда он может надлежащим образом упредить и реагировать на нарушения работы пользователей.
8. Пользователи, как известно, могут довольно творчески подходить к использованию ИТ-систем. Это может происходить по разным причинам: либо что-то работает с ошибкой, и они находят какой-то свой способ, дабы не обращаться за хлопотным общением с ИТ-поддержкой, либо способ работы не был изначально хорошо продуман, и пользователи, освоившись, работают теперь так, как им привычно. В обоих случаях, если нет обратной связи от пользователей, Департамент эксплуатации пребывает в блаженном неведении о реальности и, следовательно, не в состоянии играть свою роль в совместном создании ценности от инвестиций.
9. Наконец, те же самые замечания, что были отмечены для пред-разработки, относятся и к постоянному совершенствованию сотрудничества между бизнесом и ИТ на операционном уровне.

Таким образом, заключает Марк, 3 основополагающих принципа DevOps превратились в 9 на разных этапах: 3 для пред-разработки (pre-Dev), 3 для DevOps, 3 для пост-эксплуатации (post-Ops).

predev_devops_postops

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • FinOps с помощью Governance-as-Code
      Масштабы и сложность решений, основанных на облачных технологиях, продолжают расти. Слишком часто это расширение также означает, что затраты продолжают выходить из-под контроля. В
    • Применима ли концепция «сдвиг влево» (shift left) для инженеров по надёжности систем (SRE)?
      Концепция «сдвига влево» помогает упростить некоторые аспекты разработки программного обеспечения. Но предназначена эта концепция не только для разработчиков. Она
    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT