Разница между автоматизацией и расширением возможностей организации
Во многих организациях по всему миру сейчас есть несколько сотрудников с должностью DevOps-инженер в своем ИТ-отделе.
Это открыло множество захватывающих и новых карьерных возможностей для традиционных системных администраторов и инженеров, чтобы они продолжали развивать свои навыки, строить карьеру и повышать свою заработную плату.
Но что такое архитектор DevOps и чем он отличается от инженера DevOps? Вот три ключевых момента, которые отличают их:
- Архитектор понимает полный жизненный цикл разработки программного обеспечения и знает, как интегрировать все его аспекты в конвейер CI / CD с использованием множества инструментов, сред развертывания и технологий. Это верно как для кода приложения, так и для кода инфраструктуры.
- Знание шаблонов развертывания и навыки проектирования надежности сайта жизненно важны для успешного архитектора DevOps. У каждой организации своя среда, которую нужно учитывать, поэтому архитектор должен иметь возможность придумать шаблон автоматического развертывания, который работает, допускает откаты и не приводит к простоям из-за нового изменения.
- Лидер мысли и провидец для организации. DevOps - это путешествие, а не пункт назначения. Архитектор должен уметь направлять организацию через это трансформационное изменение. Это означает налаживание прочных взаимоотношений в организации, завоевание доверия со стороны коллег и предоставление разработчикам, командам по эксплуатации, безопасности и управлению проектами возможности автоматизировать свою работу.
Набор навыков архитектора DevOps
DevOps охватывает весь жизненный цикл разработки программного обеспечения от написания первой строки кода до вывода из эксплуатации унаследованного приложения. Успешный архитектор DevOps может говорить на языке как разработчиков приложений, так и операционных групп.
Опыт разработки
Инженеры DevOps - это традиционно люди с опытом работы
Я не могу не подчеркнуть, насколько важно для тех, кто стремится стать архитектором, получить некоторый опыт разработки. Я перешел от разработки кулинарных книг с Ruby к созданию веб-приложений Ruby on Rails на стороне.
Управление версиями и зависимостями
Вы быстро поймете, что при написании инфраструктуры или конфигурации в виде кода вам понадобится система управления версиями, иначе все быстро станет очень хрупким.
Вы также можете начать загружать другие пакеты / роли / поваренные книги / и т. Д. и испытать «ад зависимости». Это общие проблемы, с которыми сталкиваются разработчики, и которые необходимо решить.
Сборка и тестирование кода
Необходимость писать автоматические тесты и запускать эти тесты в процессе непрерывной интеграции жизненно важна.
Неважно, пишете ли вы Ansible роли, поварские кулинарные книги или что-то еще. Автоматические тесты - единственный способ обеспечить уверенность, необходимую для автоматизированного развертывания.
Давайте также не будем забывать о необходимости привлекать наших экспертов по безопасности на раннем этапе разработки программного обеспечения. Мы не хотим дойти до конца разработки, быть готовыми к развертыванию, а нам нужно только рефакторинг кода, чтобы исправить серьезный недостаток безопасности в дизайне.
Шаблоны развертывания и навыки SRE
Одна из самых больших проблем, с которыми сегодня сталкиваются организации, - это непрерывное развертывание. Есть несколько различных подходов, некоторые из которых:
- Nuke and pave (плохая идея для производственного развертывания)
- Канарейка
- Пометка функции
- Поэтапное / последовательное развертывание
- Цвет морской волны
У каждого из них есть свои плюсы и минусы. Каждому из них требуются разные объективы для написания вашей инфраструктуры как кода или кода приложения.
Например, если я собираюсь пометить функции для введения новых функций, мне нужно написать код моего приложения для поддержки этого.
Однако, если я собираюсь представить новые функции с помощью сине-зеленого развертывания, мне нужно гораздо больше сосредоточиться на том, чтобы моя инфраструктура как код была надежной, а моя сеть / DNS / балансировка нагрузки могли переключаться между развертываниями.
Архитектор DevOps может помочь сориентировать команды разработчиков приложений по этим вариантам и порекомендовать лучший подход, основанный на существующих навыках, технологиях и зрелости команды DevOps.
Лидер мысли и провидец
DevOps - это не отдельная технология, инструмент, процесс или человек. Это трудный и долгий путь для крупных организаций. Нужен кто-то, кто может настойчиво и убедительно вносить изменения в организацию.
Все начинается с малого, в рамках одной команды, с улучшения процессов разработки или просто использования Jira для отслеживания прогресса разработки.
Архитектор DevOps должен взглянуть на организацию, найти ключевых людей, которые могут быть теми агентами изменений, сломать разрозненность и собрать их вместе, чтобы сделать что-то новое.
Самая большая проблема для архитекторов DevOps - руководить без официального разрешения. Это означает, что нужно побуждать людей помогать вам в достижении чего-либо, даже если это может быть не тем, что они традиционно делают или думают, что должны.
Единственный способ добиться этого - стать продавцом. Вы должны убедить людей, что если вы сделаете что-то новое, это сделает жизнь лучше для них и для организации.
Это означает принятие мнений с разных точек зрения, получение поддержки для решения, а затем ответственность за его выполнение и ответственность других.
Заключение - готовы ли вы стать архитектором?
DevOps - это очень обширный термин для разработки программного обеспечения в эту новую эпоху. Он включает в себя так много разных навыков, поскольку охватывает все аспекты развития.
Хорошая новость заключается в том, что для перехода от инженера DevOps к архитектору DevOps необязательно быть экспертом во всем!
Если вы уже моделируете путь своей команды, начните привлекать людей из других команд к тому, что вы делаете. Создайте сообщество DevOps в своей организации.
Познакомьтесь с теми, кто специализируется на вещах, с которыми вы не так хорошо знакомы, например, посидите с разработчиком в течение дня и посмотрите, что они делают, или наоборот.
Роль архитектора DevOps - это огромная ответственность, но она также очень полезна. Самое замечательное в работе в такой роли - оглянуться назад на все трансформационные изменения, на которые вы помогли повлиять в организации.
