Вряд ли имеет смысл назначать devops-директора либо любого другого человека, ответственного за внедрение devops-практик в организации. По своей сути devops является культурным движением, поэтому идеи и принципы этого движения должны внедряться на всех уровнях организации. Лишь в этом случае devops будет эффективным.
Несмотря на все, что сказано выше, должность «devops-инженер» действительно существует. В соответствии с данными, опубликованными в отчете 2015 DevOps Salary Report от Puppet (https://puppet.com/resources/white-paper/2015-devops-salary-report), у инженеров, в названии должности которых присутствует слово «devops», зарплата выше, чем у обычных системных администраторов. Конечно, эти оценки весьма приблизительны, поскольку в разных организациях devops-инженеры исполняют самые разные роли. Скажите на милость, кто бы отказался от звания devops-инженера за прибавку в 10 тыс. долларов к зарплате?
В отчете 2015 DevOps Salary Report отмечается, что «большинство devops-инженеров работают более 50 часов в неделю, системные инженеры работают от 41 до 50 часов в неделю, а системные администраторы работают менее 40 часов в неделю». Как видите, никто даром деньги не платит. Если вы получаете высокую зарплату, будьте готовы пожертвовать своим личным временем и здоровьем.
Методология devops связана только с веб-стартапами
Основной продукт интернет-компаний – веб-приложения, с которыми имеют дело пользователи при просмотре веб-сайта компании. Эти сайты часто могут быть реализованы без использования информации, которая хранится где-либо между сеансами взаимодействия пользователей с сайтом (то есть сеансы без отслеживания состояния). Обновление сайта можно выполнить либо поэтапно, либо путем переноса «живого» трафика на новую версию сайта. При этом облегчается процесс непрерывного развертывания.
Несложно понять, почему devops-методики имеют такое значение для интернет-компаний. Это движение помогает разрушить барьеры, которые стоят на пути разработки и развертывания программного обеспечения. Если процессы, реализованные в интернет-компании, настолько медленны, что требуется несколько недель на устранение мелкой ошибки, скорее всего, эта компания не сможет конкурировать с организациями, в которых используются новые гибкие подходы к разработке и развертыванию приложений.
Преимущества, обеспечиваемые улучшенным сотрудничеством, близостью и инструментами, проявляются не только в веб-стартапах. Просто повторяющиеся действия (или итерации) с групповыми структурами и процессами проще выполнять в рамках небольших стартапов. Крупные компании сопротивляются быстрым изменениям, а правительственные учреждения активно препятствуют изменениям и ограничивают их с помощью специальных законов. Тем не менее изменения возможны даже в таких учреждениях и организациях. В следующих главах книги будут рассмотрены примеры использования методик devops в крупных корпорациях и правительственных учреждениях.
Devops нужно сертифицировать
Поскольку devops-методики в большой степени связаны с культурой, сертификация в этом случае вряд ли применима. Невозможно провести 60-минутный экзамен и по его результатам сертифицировать эффективность общения с другими людьми, оценить степень налаженности командной работы в вашей организации и сделать выводы о порядке обучения в организации. Сертификацию имеет смысл применять по отношению к высоким технологиям, использование которых потребует серьезного уровня знаний о таких вещах, как специфическое программное обеспечение или оборудование. Благодаря подобной сертификации компании могут получить представление о знаниях отдельных сотрудников в данной области.
При использовании devops-методов не требуется технологическая база либо универсальные решения. На сертификационных экзаменах обычно проверяют уровень знаний, задавая вопросы, на которые существуют четко определенные ответы. Как правило, в devops таких ответов не существует. То, что хорошо работает в одной компании, вовсе не обязательно окажется оптимальным для другой компании. Не существует простого способа разработать набор вопросов, имеющих отношение к devops, которые имели бы однозначные ответы. Сертификация в devops может либо использоваться в качестве средства заработка, либо быть связанной определенным решением поставщика, но называть ее devops-сертификацией некорректно.