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

В этот блоге мы бы хотели рассказать Вам о некоторых самых распространенных мифах и заблуждениях о DevOps:

1. Методология DevOps – всего лишь часть PR: Доля правды в этом есть. В ИТ индустрии встречались команды, которые делали то, что мы сейчас именуем как DevOps.

В то же время приверженцы DevOps стремятся распространить интересующую общественность информацию, сделать доступными блоги, книги и конференции, которые помогут ИТ специалистам разобраться в этом предмете.

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

Сообщества DevOps профессионалов стремятся заполнить пробелы, которые упустили другие источники информации.

В прошлом для того, чтобы превратить ИТ специалиста-новичка в опытного Operations эксперта (DevOps = Development + Operations) с техническими ноу-хау требовалось от 10 до 15 лет. Такой темп развития неприемлем, поэтому возникают 2 альтернативных варианта: приспособиться и развиться более быстрыми темпами или завершить на этой «ноте». Вот как раз тут и играют ключевую роль DevOps сообщества. По нашим убеждениям, они должны создать информационный пул и профессиональные группы, которые будут поддерживать заинтересованных ИТ специалистов.

2. DevOps предполагает передачу всех паролей и доступов разработчикам: Многим могло показаться, что приверженцы DevOps пропагандирует мир, где разработчики и системные администраторы «помешались» на производительности систем. Это вовсе не соответствует действительности. На самом деле мы пропагандируем более тесное взаимодействие между командами. В большинстве компаний до сих пор есть команда разработчиков (development) и команда операционных специалистов (operations). Devops – это специалисты и процессы, которые помогают возводить мосты между этими 2-мя командами для более эффективного сотрудничества.

Некоторые разработчики могут получить доступ в продуктив в целях поддержки ПО. Если же Вы не уверенны в оправданности такого решения, Вам совсем не обязательно предоставлять разработчикам пароли. Вы можете использовать sudoers file – делегировать те или иные привилегированные ресурсы пользователям с ведением протокола работы. Это поможет разработчикам качественно выполнять свою работу, удовлетворяя Ваши потребности: контроль и аудит логов, отслеживание процессов серверов.

Любой компании предстоит найти оптимальный баланс: дать возможность разработчикам делать свою работу, но таким способом, который будет наименее рисковым и разрушительным для всех вовлеченных участников. Такие инструменты как: «sudo» и «friends» – хорошо известны и надежны. Этот инструментарий позволяет определить круг доверенных лиц, которые смогут совершать определенный перечень действий. Например, перезапуск веб-сервера во время развертывания, при этом, не имея прав перезапустить его при других обстоятельствах.

Обе команды: команда разработчиков (Development) + команда системных администраторов (Operations) сообща несут ответственность за конечный результат. Этот факт изменил ситуацию, в которой лишь системные администраторы отвечали за все сбои и простои системы. Методология DevOps гласит, что обе команды являются заинтересованными сторонами, а значит, совместно отвечают за стабильность, доступность и производительность систем.

3. Все системные администраторы пишут код, а все разработчики занимаются стоечными серверами: Многие отождествляют DevOps с взаимозаменяемостью. Они убеждены, что ИТ специалисты из обеих команд могут выполнять работу друг друга, например, можно отправить разработчика в центр обработки данных (ЦОД). Будет ли это работать?

Реальность такова, что не все системные администраторы и разработчики знают в деталях рабочие процессы другой стороны – и это приемлемо. Таким образом, у Вас в компании будут команды специалистов: в области хранения данных, безопасности, построения ЦОД, сетевых процессов. Эти специалисты должны взять разработчиков «в оборот»: объяснить принципы своей работы, почему они занимаются теми или иными вещами и каково их значение, но, в конечном счете, Вы все равно будете нуждаться в вышеупомянутых экспертах.

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

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

В этом блоге мы разрушили 3 мифа, с которыми могут столкнуться ИТ специалисты в связи с тем, что тема DevOps пока еще слишком новая, особенно в Восточной Европе и в Украине в частности.

В следующем блоге мы продолжим эту тему и постараемся преодолеть 4 типичныt заблуждения о методологии DevOps.