Введение

Не смотря на то, что общепринятого определения девопс нет (как и определения облака), его идеи построены вокруг четырех принципов: культура, автоматизация, измерение и обмен знаниями (Culture, Automation, Measurement and Sharing, CAMS). В этой статье мы рассмотрим, как это влияет на традиционные подходы системных администраторов.

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

Проблема

Многие годы, эксплуатация (частью которой, как правило, является системное администрирование) воспринималась как конечная точка процесса поставки программного обеспечения. Разработчики писали новую функциональность в изолированной от эксплуатации среде, а когда они заканчивали очередной большой этап, ПО передавалось отделу эксплуатации, чтобы обеспечить развертывание и запуск в работу.

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

Культура сотрудничества

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

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

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

Не смотря на то, что системные администраторы всегда сотрудничали с разными отделами, это никогда не считалось стратегическим преимуществом. Культура девопс направлена на продвижение постоянного сотрудничества между вертикалями (Здесь и далее, я использовал слово «вертикаль» для перевода английского «silo», поскольку обмен информацией между вертикалями в организациях часто отсутствует. Information silo — это система, неспособная к сотрудничеству с другими, релевантными системами. — Прим. пер.), с целью лучшего удовлетворения потребностей бизнеса. Это ведет к «friction-less» IT («безупречному ИТ») и стимулирует междисциплинарный подход и совместную работу отделов.

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

Культура обмена знаниями

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

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

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

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

Пересмотр автоматизации

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

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

Пересмотр измерений

Эффект от сотрудничества нельзя выразить в количестве проведенных разговоров, ведь много разговоров не значит, что вечеринка будет хорошей. Это похоже на черную дыру: чтобы оценить ее эффект, нужно смотреть на объекты вокруг самой дыры. Так как же понять, что есть улучшения? Как инженер, вы собираете статистику о числе инцидентов, тикетов, неудачных и удачных запусков. Но вместо того, чтобы держать эту информацию в своей вертикали, распространяйте ее среди других частей вашей компании и извлекаете из нее уроки. Празднуйте успехи и неудачи, и делайте выводы из них. Анализируйте причины проблем, вовлекая всех причастных, и улучшайте процессы. Еще раз: нужно менять фокус статистики и мониторинга с быстрого исправления проблемы, на обратную связь со всей организацией. Целью должна быть оптимизация всей системы, а не только лишь вашей части.

Секретный соус

Несколько «молодых» компаний являются лидерами в применении этих подходов. Amazon, с их правилом двух пицц (если команда, работающая над одним проектом, может съесть больше двух пицц, то она слишком большая — Прим. пер.), Flickr, с политикой десяти обновлений в день, были одними из первых лидеров, но теперь всё более традиционные компании, как, например, National Instruments, видят ценность такой культуры сотрудничества. Теперь они называют культуру сотрудничества «секретным соусом», который позволит им оторваться от конкурентов. Почему? Потому что, такой подход позволяет перестать считать людей ресурсом, а начать считать, что это у людей есть ресурс для решения проблем, которые существуют в этом сложном мире, называемом ИТ.