Каким должен быть настоящий DevOps?
DevOps - это культурное движение, которое привнесло так необходимую в разработке программного обеспечения гибкость. Но его часто неверно понимают: действительно ли DevOps подразумевает, что разработчики должны, помимо разработки, быть также великолепны в сложной работе по системному администрированию?
Этот материал – наш взгляд на
статью зарубежных коллег и попытка разобраться, в чем разница в наборах навыков между разработчиками и платформенными инженерами и что на самом деле означает реалистичный подход к DevOps?
DevOps - это методология, в рамках которой разработчики берут на себя функциональную ответственность за свои приложения. Это включает в себя не только разработку кода как раньше, но и оперативные задачи: выпуск новых версий, управление жизненным циклом своего кода (обновления, миграции баз данных и т.д.), а также наблюдение за его поведением во времени с помощью мониторинга и сбора логов.
Такой подход значительно повысил производительность и эффективность. Если разработчики берут на себя полную ответственность за жизненный цикл приложения, это означает, что они замыкают на себе обратную связь по функционированию кода в реальности. А проблемы производительности выявляются теми, кто отвечал за эксплуатацию кода. Информация о приложении доставляется непосредственно разработчикам и дизайнерам, что позволяет оптимизировать пользовательский опыт работы с приложением.
Но DevOps часто понимают неправильно. Потому что разработчиков поощряли «откусывать» гораздо больше, чем они могли «прожевать».
Технологии, способствовавшие развитию движения DevOps, и скрытые герои, которые им управляют
DevOps инициировал организационную эволюцию и культурный сдвиг. Причина, по которой DevOps смог выйти на сцену в том виде, в котором мы его видим, заключается в том, что существует технология, поддерживающая этот способ работы. Возможность работать с инфраструктурой как инструментом кода поддерживается данной технологией. Будь то гипервизоры в среде ВМ, контейнеры в среде Kubernetes или языковые среды исполнения в среде функций как услуги. Без этих технологий мы не смогли бы внедрить DevOps в том виде, в котором мы его знаем. Но кто-то все же должен управлять этой фундаментальной технологией.
В этом материале мы будем называть их платформенными инженерами.
Так чем же платформенный инженер отличается от разработчика?
Разработчики vs платформенные инженеры
Наиболее видимым результатом разработчиков является код. Но это не просто код, потому что разработчик в первую очередь сосредоточен на решении задач из проблемной области на высоком уровне абстракции, моделировании проблемной области и превращении этих моделей и абстракций в код.
В отличие от него платформенный инженер сосредоточен на внутренней работе компьютерных систем и следит за тем, чтобы они работали эффективно, безопасно, правильно и были доступны в любое время.
Навыки, необходимые для разработки программного обеспечения и выполнения задач по эксплуатации платформы, существенно отличаются.
DevOps, в котором разработчики должны также отвечать за управление жизненным циклом своих приложений и наблюдать за ними во время работы означает, что им необходимо изучить набор инструментов и вспомогательных технологий: комплексы наблюдения – системы протоколирования и мониторинга; руководство развертыванием, например, API, и инструментов для работы с облаком, Kubernetes или платформами FaaS (функция как услуга).
Разработчики, как правило, принимают эти инструменты и новые методы работы: с ростом их ответственности приходит большая адаптивность, и они более эффективно выполняют свою работу. Преимущества проявляются сразу и ощущаются во всей организации.
Но суть в том, что некто должен заставить эти новые инструменты и компоненты платформы работать. Не просто установить их единожды, но и поддерживать их, обновлять, устранять неполадки и обеспечивать их безопасность.
Важно отметить следующее: неразумно ожидать, что разработчики будут также управлять базовыми системами.
Но именно этим занимаются платформенные инженеры!
Платформенные инженеры обладают навыками, необходимыми для понимания принципов работы технологии на достаточно глубоком уровне, чтобы устранять неполадки: например, почему не работает сеть, а в операционной системе закончились дескрипторы файлов или почему производительность «ввода-вывода» внезапно снизилась.
Достаточно сложно правильно смоделировать «человеческую реальность» проблемной области и воплотить эту модель в коде. Понять операционные системы на достаточно глубоком уровне, чтобы уверенно устранять неполадки в «компьютерной реальности», - это совсем другое дело.
Безусловно, некоторые проблемы можно решить с помощью подхода
Pets vs Cattle.
В случае с Pets все находится в руках администратора, а неисправность команда старается исправить любой ценой без полной замены сломавшегося компонента. Cattle – это шаг в пользу автоматизации и глобальных изменений в случае, если что-то идет не так. При таком подходе проблемы, из-за которых ошибка будет появляться неоднократно, должны быть действительно устранены.
Даже крупные рогатые животные нуждаются в ветеринарной помощи, если они заболевают. Платформенные инженеры и являются такими ветеринарами.
Вот как разработчиков подталкивали «откусывать» больше, чем они могли «прожевать»: им было сказано заниматься и разработкой и эксплуатацией.
Если человек отлично владеет JavaScript для frontend и backend, это еще не означает, что он может так же круто справляться с работой системного администратора.
Это также не означает, что разработчики эффективно выполняют эти задачи. В большинстве случаев их время лучше потратить на то, в чем они являются эксператми, нежели бросать на задачи по администрированию. Любое время, потраченное на это, означает, что они отвлекаются от разработки новых функций, а вместо этого (возможно недостаточно эффективно) устраняют неполадки в работе платформы.
Краеугольный камень информационной безопасности
Назначение людей без надлежащей подготовки ответственными за соблюдение безопасности компонентов платформы также является серьезным риском .. Эта сфера деятельности движется со скоростью света. у разработчиков никогда не будет хватать времени, чтобы разобраться со всем этим пространством.
Итак, как выглядит реальный DevOps на практике?
Разработчики могут применить на практике способ работы DevOps, взяв на себя обязанности по разработке и эксплуатации приложений. Это позволяет разработчикам быстро выполнять итерации. Они могут отслеживать, анализировать, планировать и выполнять изменения в коде гибким способом. Это позволяет им сосредоточиться и направить все свои усилия на создание ценного для организации продукта путем разработки приложений.
Предоставление им такой возможности на техническом уровне – задача платформенных инженеров. Эта команда работает в фоновом режиме и очень хорошо поддерживает работоспособность платформ и систем. Именно они закладывают фундамент, на котором разработчики могут выполнять свои новые обязанности в рамках DevOps.
Методология DevOps никогда не подразумевала, что разработчики будут заниматься и эксплуатацией кода, и эксплуатацией платформы
Возложение реалистичных ожиданий на разработчиков возвращает им все потерянное время, потраченное на устранение проблем с платформой. Это означает большее время на создание ценного продукта для конечных пользователей, а также более продуктивную и качественную работу, без необходимости мысленно переключаться между разработкой и эксплуатацией платформы.
Команда компании "Онланта"
