DevOps не только для стартапов

keep-calm-and-call-devops-2Редкое ITSM событие проходит сейчас без упоминания концепции DevOps. Считается, что она хорошо подходит для Интернет-компаний, которые изначально использовали DevOps и не имеют унаследованных систем. Для компаний сферы финансов, производства или здравоохранения, где требования безопасности критичны для обеспечения конфиденциальности, целостности и доступности информации такой подход неприменим. Известный эксперт и соавтор книг ITIL, Стюарт Рэнс высказал свою точку зрения по данному вопросу.

Все ИТ-системы организации можно классифицировать по трем уровням (согласно модели Gartner Pace Layered Application Strategy — PLAS):

  • Учётные системы (systems of record), которые поддерживают основные транзакции и критические данные. Такие системы обычно редко меняются и регулируются нормативными требованиями.
  • Дифференцированные системы (systems of differentiation), которые поддерживают уникальные процессы компании или отрасли. Они нуждаются в достаточно частых изменениях для удовлетворения меняющихся потребностей бизнеса и клиентов.
  • Инновационные системы (systems of innovation), которые оперативно создаются и изменяются с учетом новых требований и возможностей.

Один из подходов – ввести DevOps для инновационных систем, защищая изменения остальных систем более традиционным подходом. Это позволит получить некоторые преимущества от DevOps при сохранении безопасности критичных бизнес-систем, однако фактически предполагает  наличие двух внутренних ИТ-организаций с различными способами работы, инструментами, а главное с разным отношением, поведением и культурой (Attitude, Behaviour and Culture – ABC).

ИТ-подразделения постоянно жалуются на то, что команды разработчиков «перебрасывают  ПО через стену», создавая проблемы как для ИТ, так и для клиентов. По мнению Стюарта, в DevOps есть набор идей, которые позволяют раз и навсегда устранить эту стену, и могут применяться даже для критичных бизнес-систем:

  1. Формирование кросс-функциональных команд, в которые входят разработчики, а также поддержка и эксплуатация. Поставьте перед этими командами цели, которые связаны с реальными бизнес-результатами, и мотивируйте на предоставление ценности для заказчика.
  2. Вовлечение сотрудников эксплуатации на ранних этапах разработки. Они должны не просто выдать разработчикам несколько «нефункциональных требований» и ждать, пока дадут протестировать конечный продукт, но принять участие и предоставить необходимую экспертизу, чтобы убедиться, что системой можно управлять, что инциденты и проблемы диагностируются, что производительность измеряется.
  3. Привлечение разработчиков на более поздних стадиях жизненного цикла. Сообщайте им, когда происходит сбой, чтобы они могли принять участие в сборе данных, необходимых для диагностики сложных проблем. Позвольте им испытать на себе, как трудно выполнять регулярные задачи эксплуатации, чтобы они могли улучшить дизайн в следующий раз.
  4. Разработка сквозных процессов. Не создавайте процесс управления изменениями, предназначенный только для защиты эксплуатации, пусть он будет сквозным и объединяет сбор требований, разработку кода, построение релиза, разработку и проведение тестов, подачу запросов на изменение и их согласование, развертывание финального варианта. Если вся эта деятельность спроектирована как единый процесс, то вы сможете его оптимизировать, например, используя Теорию ограничений (Theory of Constraints — TOC), выявите участки, требующие улучшений, и сосредоточьте усилия на том, что имеет значение.   

Даже если для компании не применимы все идеи вместе, вероятно, есть одна или две, которые можно использовать, чтобы улучшить интеграцию между разработкой и эксплуатацией ИТ. А какие методы используются для этого у вас?

ITIL Expert Уверенная дорога до ITIL Expert
 

Экономия на обучении до 30% для тех, кто хочет быстро добраться до высшей ступени в ITIL
 

Узнайте больше!

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

  1. Александр Тараторин

    Последняя мысль ИМХО самая ценная. Возбму на себя наглость скопировать.ее сюда из оригинала целиком: "what I am saying is that even if you don’t think DevOps can be applied to all of your IT, you can adopt the attitudes, behaviour and culture that underpin Devops into your entire IT organization. This will enable you to apply continuous integration and deployment where it is appropriate, but to retain the legacy approach where that makes sense"

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

  2. Андрей

    DevOps культура. 

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

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

НОЯ
26
Учебный курс:
Operational Support and Analysis (ITIL OSA)