Что, черт возьми, такое DevOps?

Краткая история времени

Чтобы понять DevOps, нам нужно отправиться в прошлое, в старость, когда не было ничего, кроме программистов.

Как учит нас Дао:

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

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

Программист породил машинный язык. Машинный язык породил ассемблер. Ассемблер породил компилятор. Сейчас существуют тысячи языков. У каждого языка есть свое предназначение, каким бы скромным оно ни было. Каждый язык выражает Инь и Ян программного обеспечения. Каждый язык имеет свое место в программном обеспечении.

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

А потом вмешалась человеческая природа, и мы стали просить большего. Больше скорости, больше возможностей, больше пользователей, больше всего.

Будучи скромными, скромными и миролюбивыми существами, у программистов было очень мало шансов пережить такой наплыв нуждающихся пользователей, всегда просящих большего. Лучшим шансом победить было начать развиваться в разных направлениях и создавать касты. Вскоре программисты вымерли как праотцы новых пород, называемых разработчиками, инженерами-программистами, сетевыми администраторами, разработчиками баз данных, веб-разработчиками, системными архитекторами, инженерами по контролю качества и многими другими. Быстрое развитие и адаптация к вызовам внешнего мира стали частью их ДНК. Новая каста может сформироваться в течение нескольких недель. Веб-разработчики стали бэкенд-разработчиками, фронтенд-разработчиками, PHP-разработчиками, Ruby-разработчиками, Angular-разработчиками… все это катилось к черту.

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

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

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

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

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

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

Программные проекты стали настолько подвержены неудачам, что они были приняты в качестве отраслевого стандарта. Статистика показала, что более 50% проектов терпели неудачу, и, похоже, с этим ничего нельзя было поделать (ZDNet, CNet)

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

Agile Manifesto основан на двенадцати принципах:

1. Удовлетворенность клиентов за счет раннего и непрерывного предоставления ценного программного обеспечения
2. Приветствуйте меняющиеся требования, даже на поздних стадиях разработки
3. Рабочее программное обеспечение доставляется часто (недели, а не месяцы)
4. Тесное, ежедневное сотрудничество между деловыми людьми и разработчиками
5. Проекты строятся вокруг целеустремленных людей, которым стоит доверять
6. Беседа лицом к лицу – лучшая форма общения (совместное размещение)
7. Работающее программное обеспечение — главный показатель прогресса
8. Устойчивое развитие, способное поддерживать постоянный темп
9. Постоянное внимание к техническому совершенству и хорошему дизайну
10. Простота — искусство максимизировать количество невыполненной работы — имеет важное значение
11. Самоорганизующиеся команды
12. Регулярная адаптация к меняющимся обстоятельствам

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

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

Подсели на ЛСД (каламбур) и рисковали быть изгнанными и изгоями, некоторые из потомков искали решения за пределами своей касты и индустрии программного обеспечения. Они нашли спасение в работах крупного автопроизводителя. Производственная система Toyota была удивительной в своей простоте, и было настолько очевидно, что ее бережливое производство может быть легко применено к разработке программного обеспечения.

Существует 7 принципов бережливого производства:

1. Устранение отходов
2. Качество сборки в
3. Создание знаний (усиление обучения)
4. Отложить обязательство (принять решение как можно позже)
5. Доставить как можно быстрее
6. Уважайте людей (расширяйте возможности команды)
7. Оптимизируйте все

Добавленные к Agile принципы Lean поддерживали менталитет и нацеленность на выполнение правильных действий, сохраняя при этом гибкость на протяжении всего процесса.

После того, как Agile и Lean были приняты командами разработчиков программного обеспечения, потребовался всего один шаг, чтобы применить весь набор принципов к ИТ в целом, что, наконец, привело нас к DevOps!

Введите DevOps — трехполосное шоссе

Старая школа взглядов на команды разработчиков программного обеспечения включала бизнес-аналитиков, системных архитекторов, фронтенд-разработчиков, бэкенд-разработчиков, тестировщиков и так далее. Оптимизация процесса разработки программного обеспечения, включая принципы Agile и Lean, была в основном сосредоточена на них. После того, как приложение было «готово к производству», оно было отправлено в «Операции», включая системных инженеров, инженеров по выпуску, администраторов баз данных, сетевых инженеров, специалистов по безопасности и т. д. Удаление великой стены между Dev и Ops является основной движущей силой DevOps .

DevOps — это результат внедрения принципов бережливого производства во весь поток создания ценности ИТ. Поток создания ценности ИТ расширяет разработку до производства, объединяя всех «дальних родственников», происходящих от исходного Программиста.

Лучшее объяснение решений DevOps дает Джин Ким, и если вы еще не читали «Проект Феникс» , я предлагаю вам потратить некоторое время и сделать это.

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

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

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

• Вторая полоса — убедитесь, что существует постоянная петля обратной связи, отправляемая вверх по течению и не игнорируемая.

• Третье направление: поощряйте эксперименты, постоянно совершенствуйтесь и быстро терпите неудачу.

Первая дорожка — набираем скорость

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

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

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

Принципам DevOps все равно, к какой команде вы принадлежите, являетесь ли вы системным архитектором, администратором баз данных, QA или сетевым администратором. Одни и те же правила применяются ко всем, и каждый должен следовать двум простым принципам:

• Обеспечьте бесперебойную работу системы
• Увеличивайте и оптимизируйте рабочий процесс в любое время

Вторая дорожка - Готовься

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

Однако DevOps — это не утопия, и если бы была возможна однонаправленная доставка, то водопадного метода было бы достаточно. Оценка результатов и информирование о потоке очень важны для обеспечения качества. Первый «восходящий» канал связи, который необходимо внедрить, — это Ops to Dev.

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

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

Дорожка третья - Деформация 10

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

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

«То, что подходит Мастеру, не подходит новичку. Вы должны понять Дао, прежде чем превзойти структуру».

DevOps Third Way/Fast Lane включает выделение времени для непрерывных экспериментов на ежедневной основе, постоянное вознаграждение команды за принятие рисков и внесение ошибок в систему для повышения устойчивости.

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

Реализация этих мер позволяет вашей организации всегда быть начеку и способна быстро и эффективно реагировать на вызовы.

Резюме — Контрольный список организации DevOps

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

• Между командой разработки и командой эксплуатации нет стены. Оба являются частью одного и того же процесса
• Работа, которую пересылают из одной команды в другую, всегда проверена и качественна.
• Нет «нагромождения» работы, все узкие места обрабатываются
• Команда разработчиков не использует рабочее время для своей деятельности, потому что развертывание и обслуживание являются частью одного и того же временного интервала.
• Команда разработчиков не доставляет код для развертывания в 17:00 по пятницам, оставляя операции для очистки своей работы на выходных.
• Среды разработки стандартизированы, и операции могут быть легко воспроизведены и масштабированы в производство.
• Команда разработчиков может предоставлять новые версии по мере необходимости, а операторы могут легко развернуть их в производстве.
• Между всеми командами существуют четкие линии связи
• У всех членов команды есть время для экспериментов и работы над улучшением системы
• Дефекты вводятся (или моделируются) и обрабатываются в системе на регулярной основе. Уроки, извлеченные из каждого эксперимента, документируются и передаются всем заинтересованным лицам. Обработка инцидентов является рутинной и в основном обрабатывается известным способом.

Заключение

Использование современных инструментов DevOps , таких как Chef, Docker, Ansible, Packer, Troposphere, Consul, Jenkins, SonarQube, AWS и т. д., не означает, что вы применяете принципы DevOps. DevOps — это образ мышления. Мы все являемся частью одного и того же процесса, мы делим одно и то же время и вместе приносим пользу. Каждый человек, участвующий в процессе доставки программного обеспечения, может ускорить или замедлить работу всей системы. Ошибка, созданная во время разработки, может вывести систему из строя, как и неправильная конфигурация брандмауэра.

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