Джин Ким - Руководство по DevOps
- Название:Руководство по DevOps
- Автор:
- Жанр:
- Издательство:Манн, Иванов и Фербер
- Год:2018
- Город:Москва
- ISBN:9785001007500
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Джин Ким - Руководство по DevOps краткое содержание
Руководство по DevOps - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Тупиковая ситуация препятствует достижению важных целей организации, что зачастую значительно перевешивает стремление к сокращению расходов [50].
Также функциональную ориентацию можно обнаружить в централизации контроля качества и функций информационной безопасности, работающих хорошо (или по крайней мере достаточно неплохо) и при не очень частых релизах программного обеспечения. Однако по мере того как мы будем увеличивать количество команд разработчиков и частоту выполняемых развертываний и релизов, организации из числа наиболее функционально-ориентированных столкнутся с затруднениями при поддержании удовлетворительных результатов, особенно когда все выполняется вручную. А теперь изучим, как действуют организации, ориентированные на рынок.
Говоря в широком смысле, для достижения результатов DevOps нам требуется уменьшить последствия функциональной ориентации («оптимизация затрат») и перейти к рыночной ориентации («оптимизация скорости»), с тем чтобы мы могли иметь много небольших команд, работающих безопасно и независимо друг от друга, быстро доставляя продукт клиентам.
Суть в том, что команды, ориентированные на рынок, несут ответственность не только за развитие функций, но и за тестирование, безопасность, развертывание и поддержку сервисов в производстве, от рождения идеи до прекращения ее использования. Эти группы созданы кросс-функциональными и независимыми, они имеют возможность разрабатывать и запускать пользовательские эксперименты, разрабатывать и поставлять новые функции, развертывать и запускать службы в производственной среде, устранять любые дефекты без зависимости от других групп, давая им таким образом возможность продвигаться к цели быстрее. Такая модель принята компаниями Amazon и Netflix и до сих пор провозглашается первой из них как одна из основных причин способности организации быстро меняться даже в процессе роста.
Для достижения рыночной ориентации не требуется проводить серьезную реорганизацию компании сверху донизу, часто создающую большое количество сбоев, вызывающую страх и даже парализующую деятельность организации. Вместо этого мы будем внедрять функциональных инженеров с соответствующими навыками (например, эксплуатация, тестирование, информационная безопасность) в каждую сервисную команду или предоставлять эти возможности командам с помощью автоматизированных самообслуживающихся платформ, воспроизводящих приближенную к производственной среду, выполняющих автоматизированное тестирование или производящих развертывание.
Это позволяет каждой сервисной команде независимо доставлять продукт клиентам без необходимости создавать задачи для других групп, например IT-эксплуатации, тестирования или информационной безопасности [51].
Если вы располагаете только рекомендованными ориентированными на рынок командами, то можете создать эффективные и действующие с высокой скоростью организации, имеющие функциональную ориентацию. Кросс-функциональные и ориентированные на рынок команды — один из способов, но не единственный, создать быстрый и надежный поток. Мы можем также достичь желаемых результатов DevOps, используя функциональную ориентацию, пока каждый в потоке создания ценности не начнет рассматривать результаты работы клиентов и самой организации в качестве общей цели, независимо от того, какую роль он исполняет в компании.

Рис. 12. Сравнение функциональной и рыночной ориентаций.
Слева: функциональная ориентация — все рабочие потоки проходят через централизованный отдел IT-эксплуатации; справа: рыночная ориентация — все продуктовые команды могут самостоятельно развертывать в производство свои компоненты, слабо связанные с другими (источник: Humble, Molesky, and O’Reilly, Lean Enterprise, Kindle edition, 4523 & 4592).
Например, высокая производительность с функционально ориентированной и централизованной IT-группой возможна, если сервисные команды гарантированно и быстро получают то, что им необходимо (в идеале — по первому требованию), и наоборот. Многие из наиболее известных организаций, использующих DevOps, в том числе компании Etsy, Google и GitHub, сохраняют функциональную ориентацию отдела эксплуатации.
У этих организаций есть общая черта — культура высокого доверия, позволяющая всем отделам эффективно действовать вместе. Все видят, как распределяются приоритеты. Существует резерв ресурсов для обеспечения быстрого завершения высокоприоритетных задач. Это возможно в том числе благодаря автоматизированным самообслуживающимся платформам, обеспечивающим качество всех разрабатываемых продуктов.
При анализе «бережливого производства» (Lean Manufacturing), зародившегося в 1980-е гг., многие исследователи были озадачены функциональной ориентацией компании Toyota, не совпадавшей с практикой организации кросс-функциональных, ориентированных на рынок групп. Они были удивлены этим, как они говорили, «вторым парадоксом компании Toyota».
Как писал Майк Ротер в уже упоминавшейся книге «Тойота Ката. Лидерство, менеджмент и развитие сотрудников для достижения выдающихся результатов», «как бы соблазнительно это ни казалось, нельзя реорганизовать путь к постоянному совершенствованию и приспосабливаемости. Решающий фактор — не форма организации, а то, как люди действуют и реагируют. Корни успеха компании Toyota лежат не в организационной структуре, но в развивающихся возможностях и особенностях ее работников. Это удивляет многих, обнаруживающих, что компания Toyota в основном организована традиционно — как система функциональных отделов». Развитие привычек и возможностей у отдельных инженеров и у персонала в целом будет рассматриваться в следующих разделах.
В высокопроизводительных организациях каждый член команды разделяет общую цель — качество, доступность и безопасность не область ответственности конкретных отделов, но часть каждого ежедневного задания.
Это означает, что неотложной проблемой текущего дня может быть разработка или развертывание клиентской функции или устранение инцидента на производстве, имеющего первостепенную важность. Или же может потребоваться дать оценку решению, принятому коллегой-инженером, применить срочное исправление системы безопасности на производственных серверах либо сделать усовершенствование, позволяющее коллегам действовать более продуктивно.
Читать дальшеИнтервал:
Закладка: