ВЖУХ, управление рисками и ITSM

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

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

"Fail Fast!", подумали ракетостроители и сноровисто, отточенными движениями приварили к конструкции ещё пару твердотопливных ускорителей.

Взглянем на настоящую организацию, в которой мы работаем. С высокой вероятностью мы увидим, что в нашей организации нам потребуется совмещать эти разные способы производства. Если это средний или крупный бизнес, то кроме наших ключевых бизнес-приложений, где мы пусть успешно удовлетворяем требования бизнеса наиболее быстрым способом, у нас есть и более "медленные" подразделения. Это управление кадрами, со системами которых мы интегрируемся, информационная безопасность, требования которой мы не можем игнорировать. Пусть у нас есть ещё защищенная real-time система управления техническими процессами производства, сбои в которой чреваты человеческими жертвами или физическим разрушением производства, релизы в ней редки, но они проходят колоссальную по свой тщательности проверку и тестирование.

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

Нельзя не учитывать существенный риск непрерывности бизнеса в лице колоссальной зависимости бизнеса от команды развивающей продукт и входящих в неё людей. Необходимо защищать себя от риска ухода команды, увольнения ключевых сотрудников, утечки данных или технологий, а это означает сохранение знаний, детальное документирование. То есть именно то, что тратит дорогие ресурсы и уменьшает возможности команды по "delivery" в рамках производственного цикла.

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

Мы здесь надолго, поэтому нам нужно уже сейчас учиться его решать, разделять ресурсы, управлять и продолжать доносить ценность.

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

The Phoenix Project Основы DevOps

Новый учебный курс 2017
 

Проект Феникс — DevOps на практике

Новая деловая игра от GamingWorks
 

DevOps: погружение

Новый корпоративный семинар
 

Комментарии и мнения

  1. Тот-Кого-Нельзя-Называть

    Расскажу как мы гибко оцифровали риски. А дело было так.

    Лето 2015. У активной группы заказчиков появилась идея сделать учет рисков самым что ни на есть автоматизированным. Раньше это делалось в Bitrix и доставалось в Excel по звонку. Удобно работает но ни разу не гибко. Потому пришло решение сделать на той же платформе, что и управление операционными процессами модуль для регистрации, обработки и контроля всех видов рисков которые известны в компании. Проблем было несколько и самая большая – это отсутствие четкого  процесса. Тут очень помогли практики ITSM — мы подумали, что вся эта «рисковая» кухня очень напоминает нам типовой операционный процесс: регистрация, согласования, обработка, контроль и т.п. Но надо делать гибко сказали мы и заказчик всячески этому был рад… Когда все, и заказчики и мы, обоюдно пришли в себя после  серии ДевОпс упражнений, выяснилось, что перебрали план трудозатрат на 120 часов. Зато заказчик был доволен, а так соглашусь. Agile интересен…

  2. Андрей другой

    Вот с этим я принципиально не согласен: "... но всё же управление услугами не о том, как быть бизнесом, а о том как бизнесу помогать, а это "две большие разницы"."

    Я продолжаю настаивать, что ИТ — это такая же область производства, как и все прочие. Производство, в котором ИТ услуги — продукция. ИТ очень похожи на энергетику. Электричество тоже необходимо для обеспечения бизнеса — обспечения технологических процессов. Но что-то я не слышал, чтобы производство и поставка энергии не считались бизнесом. Отношение к ИТ как к бизнесу означает применение бизнес методов управления — затраты, себестоимость, прибыль, эффективность. Бизнесу нужна помощь ИТ, но не любой ценой.

    1. Андрей Труфанов Автор

      Энергетика хороший пример деятельности, которая на все 100% поддерживает или обеспечивает бизнес. Посыл в том, что в ряде случаев ИТ может не только поддерживать «помогая»,  но и существенно преобразовывать и развивать, становясь драйвером бизнеса. Будут наблюдаться существенные различия в том, какие цели будет ставить перед собой ИТ, как их достижение будет измеряться.

      С остальным согласен: производство, экономика, обеспечение техпроцессов, внутренная организация.Да.

    1. Андрей Труфанов Автор

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

      Посыл в том, что «быстрые» разработчики тоже должны все это учитывать. Многие любят подчеркивать блеск своего agile величия, демонстрируя его на сравнительно небольших (и на самом деле не очень сложных) standalone приложениях, но мало кто говорит об успехах применения на действительно сложных, гетерогенных, зарегулированных средах. Возьмем к примеру кредитные конвейеры как продукт. В него включены такие составные части как часть (не целиком) АБС, обеспечивающая транзации, блок подготовки данных внутренней отчетности, экспорт данных для регламентированной отчетности, API для контрагентов, модуль проверки юридической чистоты, модуль выявления подозрительных транзакций и противодействия противоправной деятельности, что-то обепеспечивающее налоговый и бухгалтерский учет продаж, интерфейс для менеджеров кредитных линий. Прекрасная бизнес услуга.

      Кто-то может похвастаться успехами на схожем по сложности объекте? Как решаются вопросы контроля архитектуры, зависимости от конкретных разработчиков, вопросы ресурсного обеспечения? Что про все это думают scrum мастеры и владельцы продуктов?

      Но реальная жизнь ещё сложнее. Пусть там будет ещё один продукт в виде розничных продаж со своей командой бизнес-развития. Сразу начинают играть разделяемые ресурсы в виде той же АБС, и т.д. 

      1. Андрей

        Ясно, было быб интересно послушать, что об этом говорят скрам мастеры. Самомму любопытно, как гибкие технологие используются в сбербанке. Греф постоянно об этом говорит, но у меня в голове не укладывается. Разве что митинги каждое утро...)

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

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

Empty