Три принципа DevOps

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

• рассматривайте сквозные потоки;
• создавайте обратную связь;
• экспериментируйте и учитесь.

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

Три принципа DevOps

В статье «Три способа: принципы, лежащие в основе DevOps»* Джин Ким рассказал о следующих принципах. Первый принцип — фокусировка на производительности всей системы, в отличие от выполнения конкретной работы отдела или отдельного со трудника (рис .1). Основное внимание надо уделять потоку создания ценности для бизнеса, которое обеспечивает ИТ.nnВторой принцип — создание петли обратной связи, которая необходима для непрерывного совершенствования процесса или системы.nnnnТретий принцип — создание культуры постоянного экспериментирования, безусловно с контролем рисков. Это позволяет проводить постоянные улучшения, даже если некоторые из них окажутся неудачными. Кроме того, повторение и постоянная практика является основой мастерства.nnn

Первый принцип devops: рассматривайте сквозные потоки

Совершенствуя свою деятельность, вы можете сделать локальные улучшения, которые на самом деле приведут к общему отрицательному эффекту. Это происходит, когда вы сосредотачиваетесь на работе, за которую несете ответственность, но не понимаете всего сквозного потока системы, частью которой являетесь. Такую ситуацию называют «локальной оптимизацией».nnПриведу простой пример.nnПредположим, что вашей организации необходимо много ноутбуков. После покупки на каждый следует установить программное обеспечение. Далее оборудование должно быть передано пользователю. В случае оптимизации своих задач отделом закупок скорость поступления ноутбуков будет высокой. Но вы в итоге получите множество ноутбуков, ожидающих установки программного обеспечения, ведь установщики программного обеспечения не смогут справиться с повышенным объемом работ. Пользователи не получат свои ноутбуки быстрее, поэтому улучшение закупок не поможет сквозному процессу. В результате стоимость ваших запасов увеличится. Ввиду скопления ноутбуков из-за задержки в установке повысится риск их кражи, а также увеличится вероятность того, что производитель ноутбуков выпустит новую модель, что сделает ваше оборудование устаревшим, прежде чем вы получите хоть какую-то пользу от него. Таким образом, улучшения, сделанные в закупке, фактически приведут к снижению качества общей сквозной услуги. nnЭтот простой пример иллюстрирует, насколько важно понимать (и оптимизировать) целый сквозной поток. Из этого вытекает еще одна ключевая идея: если вы хотите оптимизировать сквозной поток, в работе необходимо использовать «вытягивающую» модель, а не «проталкивающую» (pull-менеджмент, а не push-менеджмент). Именно установщики программного обеспечения должны задавать скорость, с которой специалистам по закупкам следует заказывать ноутбуки. В этом случае ноутбуки не поступят до тех пор, пока установщики ПО не будут готовы к своей работе.nnОчевидно, в реальной ИТ-структуре все гораздо сложнее, чем описано выше. Существует большое количество взаимосвязанных видов деятельности, но принцип по-прежнему актуален. Убедитесь, что вы рассматриваете сквозные процессы и потоки работы всякий раз, когда проектируете деятельность и процессы.n

Второй принцип девопс: создавайте обратную связь

Многие из нас получают обратную связь о предоставляемых услугах путем измерения удовлетворенности клиентов. Минусом такого подхода является то, что вы узнаете только о том, что что-то пошло не так, когда уже слишком поздно, чтобы предпринять какие-либо действия. Хороший отклик должен приходить достаточно быстро, чтобы гарантировать, что отреагировать получится вовремя, предотвратив влияние неполадки на клиентов. Один из примеров — кнопка остановки, которая является составной частью производственной системы Toyota. Она позволяет любому работнику остановить производственную линию, если он обнаружит, что что-то пошло не так, как положено. Тогда проблема может быть решена до того, как бракованные детали будут переданы на следующий этап процесса.nnВам необходимо создать обратную связь для всех процессов, чтобы выявлять потенциальные проблемы как можно раньше. Один из способов добиться этого — начать тестирование новых релизов на ранней стадии, даже если они еще не полностью готовы. Не стоит ждать до последней минуты, прежде чем приступить к решению проблем. Если вы отложите тестированию до тех пор, пока ваш релиз не будет готов, то существенные сбои, которые можно было обнаружить заранее, приведут к длительным, неудобным и потенциально дорогостоящим задержкам.nnДругая полезная идея — запросить обратную связь от внутренних клиентов так же, как вы ее запрашиваете от внешних. Подумайте о том, как ваши услуги встроены в сквозную цепочку создания ценности для клиентов компании, и кто способен дать самые ранние и наиболее полезные отзывы.n

Третий принцип devops: экспериментируйте и учитесь

Если вы полностью понимаете систему, частью которой вы являетесь, то можно разработать новые виды услуг, процессов или инструментов, сделав это без ошибок с первого раза. Но большинству из нас просто не хватает знаний или понимания для этого, следовательно придется экспериментировать.nnЭкспериментирование не означает перебирание идей в случайном порядке в надежде, что они сработают. Важно понять, что экспериментирование — это хорошая возможность тщательно обдумать проблемы. В результате необходимо выдвинуть хорошую гипотезу с набором действий для решения проблемы. Затем следует сделать конкретные прогнозы относительно итогов и результатов, которые ожидаются на выходе.nnПроверить гипотезу можно, опробовав предложенные действия. Для этого необходимо получить фактические данные о работе после изменения, но при отсутствии хорошей обратной связи сделать это будет весьма затруднительно. Это следует предусмотреть, прежде чем начать эксперименты. Какие данные необходимы для сравнения фактических итогов со спрогнозированными результатами? А как вы будете собирать эти данные? При наличии достоверной обратной связи легко узнать, что произошло в результате эксперимента, а значит будет существенно легче планировать улучшения на следующем витке.nnТретий принцип включает элемент риска. Однако альтернатива угадывания действий и их осуществления без петли обратной связи тоже весьма рискованна. Скорее всего, такой вариант приведет к еще худшим результатам. Если вы хотите построить успешную организацию, в которой люди могут свободно экспериментировать и учиться, нужно развивать культуру, в которой экспериментирование является нормальным поведением, а тщательные измерения результатов — часть процесса проб и усовершенствований.nnВы можете узнать больше об экспериментировании и обучении в разделе 3.2.4.5 документа «ITIL Practitioner Guidance».nnПриницпы DevOps актуальны не только для организаций, которые решили принять методологию DevOps. Любая организация может извлечь выгоду из этих принципов. Подумайте, как вы могли бы применить их в вашей работе?n

Наши опытные сотрудники помогут внедрить практики DevOps, получить консультацию [email protected]