Переход на DevOps означает изменение вашего взгляда на то, что значит быть инженером

Чем я занимался в последнее время

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

Я не говорю, что никто не хочет пытаться. Наоборот. Все хотят попробовать что-то (прочитать что-нибудь) новое, и попытка перейти от старой школы разработки к работе в качестве команды DevOps кажется привлекательной для тех, с кем я работаю.

Это просто означает, что многим людям нужно изменить свое представление о том, что значит быть участником ИТ-игры. Перепрограммировать себя так, чтобы думать по-новому, труднее всего в жизни, если не сказать больше.

DevOps: определение

Так в чем же дело? Почему людям приходится менять свое мышление, чтобы стать DevOps? Подробнее об этом чуть позже. Начнем с определения DevOps, так что у нас есть с чего начать.

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

DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.

Я лично не останавливаюсь на достигнутом. Я чувствую, что ВСЕ участвует, включая тестировщиков, специалистов по развертыванию, службам безопасности и так далее. Было бы легко придумать для этого раздутую аббревиатуру, например DevTestSecWebPerfDataDeployOps, но мы все погребены достаточно глубоко в модных словах. Я просто использую DevOps как универсальное средство.

Если вы участвуете в создании и жизненном цикле услуги или продукта, вы являетесь DevOps или, по крайней мере, ДОЛЖНЫ им быть.

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

Для меня это DevOps. Так почему же в команде такие трудности с переходом? Большая часть команды пришла из старой ИТ-модели.

Давайте поговорим об ИТ-модели старой школы

Хотя компания, с которой я работаю, имеет свои собственные вкусы и недостатки с точки зрения того, как они проводят разработку, тестирование, безопасность, проектирование, данные, развертывание и т. Д., Они, несомненно, используют старую школьную модель разработки программного обеспечения. Любой, кто занимается ИТ-игрой более 10 лет, сможет понять модель «старой школы».

  • Разработчики. Они пишут код. Код, код, код. Это любой код, в котором есть «бизнес-логика» и который будет размещен на каком-то священном «сервере», который полностью находится вне их контроля.
  • Тестировщики. Они тестируют. Они пишут ручные тесты и запускают их. Они вызывают ошибки. Если повезет, парочка из них напишет автоматические тесты (я слышу вздохи). Они не несут ответственности за такие вещи, как исходный код, окружение или даже то, что находится в коде. Они получают какое-то упакованное программное обеспечение, которое появляется на их ПК или в тестовой среде, помещается туда с помощью волшебной технологии, и они тестируют его. Работа сделана.
  • Инженеры отвечают за инфраструктуру. Они держат серверы на своих местах. Они исправляют указанные серверы. Они следят за тем, чтобы VPN продолжала работать. Они отвечают за мониторинг указанной инфраструктуры, но практически не понимают «бизнес-логику», размещенную на их серверах. Самый младший из них отвечает за ремонт компьютеров людей. Команда инженеров является суперинтендантом серверов.
  • Данные. Есть несколько вариантов этой темы, но если это база данных или данные из указанной базы данных, они отвечают за это. Они применяют исправления по мере необходимости. Они следят за актуальностью индексов, делают резервные копии, следят за тем, чтобы запросы не выполнялись слишком медленно. Они поддерживают работу ETL, чтобы передавать данные из транзакционных систем в витрину данных.

Есть и другие роли, но я думаю, что все понял. По большому счету, в старых инженерных командах обязанности в большей или меньшей степени сегментированы. Люди изолированы от своей зоны ответственности, с четко определенными границами между акцентами.

В такой модели легко выполнить свою работу и перебросить выполненную работу через следующий забор, будучи изолированным и ограниченным своим конкретным положением в машине.

Почему это работало долгое время (и почему не работает сейчас)

Почему это сработало?

Так почему это сработало и почему не работает в наши дни?

Это работало долгое время, потому что, честно говоря, нам больше ничего не нужно. Команда инженеров заставляла серверы гудеть, не понимая, что на них гудит, разработчики создавали свой код, мало понимая, куда он пойдет, тестировщики тестировали, практически не имея никаких технических знаний. Людей, работающих с данными, не заботило, КАК приложение создает / извлекает данные, помимо того, что это является запрещенным способом по их выбору (хранимые процессы против ORM), и мало знали о том, как модель данных получила такой же способ, как и через приложение. . Все, что их волнует, - это все, что им нужно, - получить ли они зелень по всем направлениям при развертывании.

Мы могли бы работать таким образом долгое время, потому что технологических достижений, которые нам требовались, чтобы отойти от этого, просто не было. Серверы в основном были либо физическими, либо виртуализированными с использованием дорогих и сложных в обслуживании систем. Мы были ограничены в ресурсах до x серверов. Серверные технологии все еще были тяжелыми и трудными для инкапсуляции. Создание серверов было трудоемким и подверженным ошибкам. Инструментов для быстрой разработки приложений и оптимизированных конвейеров развертывания просто не было. Старая школьная ИТ-модель работала, потому что она работала десятилетиями. Физические и технологические границы, которые нас окружали, не позволяли нам выйти за рамки ограничений и ролей, которые мы определили.

Предвзятость в ретроспективе может заставить нас поверить в то, что дело просто в том, что люди не знают лучшего. Я считаю это мышление довольно близоруким. Будучи в те дни инженером по программному и аппаратному обеспечению, я могу сказать вам, что мы были со всех сторон связаны ограничениями нашего времени, нашей способности развиваться во что-то другое.

Почему это больше не работает

Все это изменили виртуализация, контейнеризация и облачные платформы. Изменение отношения и последующие технологии, которые развились из движения за открытый исходный код, привели нас в новых и интересных направлениях. Мы обнаружили, что теперь можем рассматривать CI / CD как реальную возможность, а не просто чудесную, но недостижимую конвейерную мечту.

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

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

Новый мир означал, что нам нужен новый способ ведения дел.

Таким образом, DevOps

Почему DevOps - это вопрос отношения

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

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

Что касается меня, я годами стремился донести до своих коллег, что DevOps - это не просто полезная философия, но при этом я продолжаю делать что-то по-старому. DevOps - это радикальное изменение вашей точки зрения. Людей бросает именно изменение точки зрения и отношения, потому что это означает переопределение того, как мы смотрим на наш продукт и наше отношение к нему.

Если раньше ваше беспокойство как разработчика программного обеспечения о том, как был развернут код, было в лучшем случае второстепенным, то теперь оно стало важной частью вашей работы. Вы должны понимать свой конвейер CD, как ваши проверки, запросы на вытягивание, слияния, как все это влияет на вашу стратегию развертывания и чего следует ожидать от любых изменений в приложении.

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

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

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

«Мне нужно начать кодить ?!» один из тестировщиков заметил в начале нашего проекта. Да, конечно. Со временем и преодолев препятствия в освоении новых навыков, тестировщик преуспел, но в первые дни это означало новый подход к своей работе, а это может быть пугающе.

Заключение

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

Я рекомендую это упражнение для изменения мышления всем старшим ИТ-командам. Почему? Что, если мы не собираемся двигаться в направлении CI / CD или быстрой разработки приложений? Я бы все же сказал, что есть заслуга в том, чтобы научиться больше работать с DevOps.

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

Надеюсь это поможет