Smashing Podcast Episode 42 с Джеффом Смитом: что такое DevOps?

В этом выпуске мы говорим о DevOps. Что это такое, и можно ли добавить его к вашему луку веб-разработки? Дрю Маклеллан разговаривает с экспертом Джеффом Смитом, чтобы выяснить это.

Показать примечания

• Джефф в Твиттере
• Книга Джеффа Operations Anti-Patterns, DevOps Solutions
• Достижимый DevOps

Еженедельное обновление

• Преодоление разрыва между дизайнерами и разработчиками, написанное Мэтью Талеби
• Полезные API-интерфейсы React для создания гибких компонентов с помощью TypeScript, написанные Gaurav Khanna
• Умные CSS-решения для общих задач пользовательского интерфейса, написанные Козимой Мильке.
• Советы и рекомендации по оценке UX/UI дизайнеров, написанные Наталией Самбир.
• Решение проблем CLS на веб-сайте электронной коммерции на базе Next.js, написанном Ариджитом Мондалом

Стенограмма

Дрю Маклеллан: Он практик DevOps, который фокусируется на достижимых уровнях реализации DevOps, независимо от того, на каком этапе пути вы находитесь. Он является директором по производственным операциям на цифровой рекламной платформе Centro, а также выступает с публичными выступлениями, делясь своими знаниями DevOps с аудиторией по всему миру. Он является автором книги Operations Anti-Patterns, DevOps Solutions for Manning Publishing, в которой показано, как применять методы DevOps в несовершенных средах, в которых работает большинство разработчиков. Итак, мы знаем, что он эксперт в DevOps, но знали ли вы Джорджа Клуни считает его лучшим производителем бумажных самолетов поколения? Мои друзья из Smashing, пожалуйста, поприветствуйте Джеффа Смита. Привет Джефф. Как твои дела?

Джефф Смит: Я в восторге, Дрю, как дела?

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

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

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

Джефф: Но также и для улучшения нашей работы. Потому что, опять же, если я пойму вашу точку зрения и приму ее во внимание в своей работе, это будет намного полезнее для каждого из нас. Операторы могут многому научиться у разработчиков с точки зрения автоматизации и того, как мы подходим к вещам, чтобы их можно было легко воспроизвести. Так что это смешение и навыки. И то, что вы видите сейчас, это то, что это относится к различным комбинациям групп, поэтому вы слышите такие вещи, как DevSecOps, DevSecFinOps, DevSecFinHROps. Он просто будет продолжать расти, расти и расти. Так что это действительно урок, который мы можем распространить по всей организации.

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

Джефф: Безусловно, да. И еще один аспект эксплуатации, и вы немного упомянули об этом во вступлении, заключается в том, что мы думаем, что это только для этих более крупных организаций с выделенными командами эксплуатации и тому подобными вещами, но есть одна вещь, о которой следует подумать, это то, что операции происходят в вашей организации, независимо от размера. Это просто вопрос того, делаете ли вы это, или если это делает отдельная команда, но каким-то образом вы развертываете код. Каким-то образом у вас где-то работает сервер. Так что операторы существуют где-то в вашей организации, независимо от их размера. Вопрос в том, кто этим занимается? И если это один человек или одна группа, то DevOps может оказаться для вас еще более важным, поскольку вам нужно понимать, что делает операционная система.

Дрю: Как вы думаете, насколько важно для нас, как для профессиональных разработчиков, иметь хорошее представление о том, что такое DevOps и что означает его внедрение?

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

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

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

Дрю: Когда я думаю о том, что слышу о DevOps, я слышу такие термины, как Kubernetes, Docker, Jenkins, CircleCI. Я слышал о Kubernetes много лет. Я до сих пор понятия не имею, что это такое, но из того, что вы говорите, кажется, что DevOps — это не просто… Мы говорим здесь не только об инструментах, не так ли? Но подробнее о процессах и способах общения по рабочим процессам, верно?

Джефф: Абсолютно. Так что моей мантрой на протяжении последних 20 лет всегда были инструменты для работы с людьми. Вы заставляете людей поверить в видение. Оттуда вы определяете, как будет выглядеть ваш процесс для достижения этого видения. А затем вы используете инструменты, которые будут моделировать любой ваш процесс. Поэтому я всегда ставлю инструменты в конец разговора о DevOps, главным образом потому, что если у вас нет этой заинтересованности, то это не имеет значения. Я мог бы придумать лучший конвейер непрерывного развертывания, но если люди не верят в то, что каждое изменение отправляется прямо в рабочую среду, это не имеет значения, верно? Чем хорош инструмент? Таким образом, эти инструменты, безусловно, являются частью обсуждения, только потому, что они представляют собой стандартизированный способ достижения некоторых общих целей, которые мы определили.

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

Джефф: Но не выходите в интернет и не узнавайте, чем все занимаются, и не говорите, что если мы собираемся заниматься DevOps, нам нужно переключиться на Docker и Kubernetes, потому что это цепочка инструментов. Нет, это не так. Возможно, вам не нужны эти вещи. Не все являются Google. Не все — Нетфликс. Перестаньте читать сообщения от Netflix и Google. Пожалуйста, просто перестаньте их читать. Потому что это приводит людей в восторг, и они думают: ну, вот что мы должны сделать. И это похоже на то, что они решают совсем другие проблемы, чем те, которые есть у вас.

Дрю: Итак, если я начинаю новый проект, может быть, я начинающий бизнес, создаю программное обеспечение как сервисный продукт. У меня есть три разработчика, у меня есть пустой репозиторий Git, и я мечтаю об IPO. Чтобы полностью использовать подход DevOps к созданию этого продукта, каковы названия строительных блоков, которые я должен иметь с точки зрения людей и процессов, и с чего мне начать?

Джефф: Итак, в вашем конкретном примере первое, с чего я бы начал, это как можно больше использовать большую часть этого и использовать что-то вроде Heroku или что-то в этом роде. Потому что вы так увлечены всем этим AWS, Docker, и на самом деле так сложно просто создать успешный продукт. Идея, что вы фокусируетесь на части DevOps, выглядит так: ну, я бы сказал, отдайте на аутсорсинг столько всего, сколько возможно, пока это не станет проблемой. Но если вы находитесь в той точке, когда вы говорите «хорошо», мы готовы взять этот материал в свои руки и мы готовы вывести его на новый уровень. Я бы сказал, что в первую очередь нужно начать с того, где ваши болевые точки? какие вещи вызывают у вас проблемы?

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

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

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

Дрю: … насколько успешным может быть внедрение DevOps в организации.

Джефф: Культура действительно является основой всего, если подумать. И это важно, потому что культура, и мы углубимся в это в книге, но культура действительно закладывает основу для норм внутри организации. Верно. Вы, вероятно, были в компании, где, если вы представили PR без автоматического тестирования, это не имеет большого значения. Люди принимают это и идут дальше.

Джефф: Но есть и другие организации, где это смертный грех. Верно. Где, если вы сделали это, это похоже на: «Вау, ты с ума сошёл? Что ты делаешь? Здесь нет тестовых случаев». Верно. Хотя это культура. Это культура, которая навязывает эту норму, говорящую: «Это просто не то, чем мы занимаемся».

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

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

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

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

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

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

Дрю: Ага. Наверное, это должен быть образ жизни.

Джефф: Точно.

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

Дрю: Применяя подход DevOps, какие вещи вы хотели бы автоматизировать в своих рабочих процессах? И какие выгоды вы ожидаете от этого по сравнению с ручным выполнением?

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

Джефф: И, возможно, это будет время, когда вы получите запрос, в котором вы скажете: «Знаете что? Это займет две недели. Я знаю, что обычно мы меняем его за пару часов, но это займет две недели, потому что этот запрос обрабатывается автоматически». С точки зрения определения того, что вы автоматизируете. В Central я использую процесс, в котором, по сути, я отбираю все различные типы запросов, которые поступали, скажем, за четырехнедельный период. И я бы классифицировал их как запланированную работу, незапланированную работу, работу с добавленной стоимостью, тяжелую работу. Тяжёлый труд — это бесполезная работа, но по какой-то причине моей организации приходится этим заниматься.

Джефф: А затем определить те вещи, которые говорят: «Хорошо, от чего мы можем просто избавиться, если мы автоматизируем это? Что мы можем сделать, чтобы просто упростить это?» И одним из критериев был риск процесса. Верно. Автоматическое переключение базы данных немного пугает, потому что вы делаете это не так часто. И изменения в инфраструктуре. Верно. Мы спрашиваем: «Как часто мы этим занимаемся?» Если мы делаем это раз в год, возможно, автоматизация не имеет смысла, потому что в этом очень мало ценности. Но если это одна из тех вещей, которые мы получаем два-три раза в месяц, хорошо, давайте посмотрим на это. Отлично.

Джефф: Теперь, что мы можем сделать, чтобы ускорить это? И дело в том, что когда мы говорим об автоматизации, мы сразу же перескакиваем к «Я нажму на кнопку, и все будет сделано как по волшебству». Верно. Но есть так много разных шагов, которые вы можете сделать в автоматизации, если вас тошнит. Верно. Например, предположим, что у вас есть 10 шагов с 10 различными командами CLI, которые вы обычно выполняете. Ваш первый шаг автоматизации может быть таким же простым, как запустить эту команду или, по крайней мере, показать эту команду. Верно. Скажите: «Эй, это то, что я собираюсь выполнить. Как вы думаете, это нормально?» "Да." "Хорошо. Это результат, который я получил. Могу ли я продолжить?» "Да." "Хорошо. Вот результат, который я получил». Верно.

Джефф: Таким образом, у вас все еще есть немного контроля. Вы чувствуете себя комфортно. А потом после 20 казней понимаешь, что просто бьешь, да, да, да, да, да, да. Вы говорите: «Хорошо. Давайте соединим все эти вещи вместе и просто соберем все воедино». Это не значит, что вы должны прыгнуть в глубокий конец, щелкнуть по нему и забыть сразу же. Вы можете входить в это, пока не почувствуете себя комфортно.

Джефф: Это те вещи, которые мы сделали в рамках наших усилий по автоматизации, просто, как мы можем ускорить время выполнения этого и уменьшить уровень усилий с нашей стороны? Это может быть не 100% в первый день, но цель всегда состоит в том, чтобы достичь 100%. Мы начнем с небольших фрагментов, которые мы будем автоматизировать в тех частях, с которыми нам будет удобно. да. Мы очень уверены, что это сработает. В этой части мы немного рискованны, так что, может быть, мы просто получим некоторую человеческую проверку, прежде чем мы продолжим.

Джефф: Еще одна вещь, которую мы рассматривали с точки зрения автоматизации, — какую ценность мы добавляем к конкретному процессу? И это особенно заметно для операций. Потому что операторы часто служат посредниками в процессе. Тогда их участие есть не что иное, как некий доступ. Верно. Это похоже на то, что операционист должен это сделать, потому что операционист — единственный человек, у которого есть доступ.

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

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

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

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

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

Джефф: Вам не нужно беспокоиться о том, что я опечатаюсь. Вам не нужно беспокоиться о том, что я возьму не тот билет. Это увеличило время обработки этих билетов примерно в десять раз. Верно. Разработчики разблокированы. Моя команда не занята этим. И все, что действительно потребовалось, это недельные или двухнедельные инвестиции, чтобы фактически разработать автоматизацию и разрешения, необходимые для получения доступа к ней.

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

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

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

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

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

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

Дрю: И тут у тебя две проблемы.

Джефф: Верно. Верно. Точно. Точно. А ты такой: «Я что-то неправильно написал? Или это? Нет, эта штука на самом деле сломалась. Так-

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

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

Дрю: Существуют ли другие способы определения того, что следует автоматизировать, посредством мониторинга ваших систем и измерения? Я имею в виду, что я думаю о DevOps, и я думаю о информационных панелях как об одной из вещей, красивых графиках. И я уверен, что эти информационные панели — это нечто большее, чем просто красивый внешний вид, но всегда приятно иметь красиво выглядящие информационные панели. Существуют ли способы измерения того, чем занимается система, чтобы помочь вам принимать такого рода решения?

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

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

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

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

Drew: So while sort of monitoring and using metrics as a decision-making tool for the businesses is one aspect of it, it sounds like the primary aspect is having the system monitor itself, perhaps, and to respond maybe with some of these automations as the system as a whole gives itself feedback on onto what's happening.

Jeff: Absolutely. Feedback loops are a key part of any real system design, right, and understanding the state of the system at any one time. So while it's easy in the world where everything is working fine, the minute something goes bad, those sorts of dashboards and metrics are invaluable to have, and you'll quickly be able to identify things that you have not instrumented appropriately. Верно. So one of the things that we always talk about in incident management is what questions did you have for the system that couldn't be answered, right. So what is it, or you're like, “Oh man, if we only knew how many queries per second were going on right now.” Верно.

Jeff: Well, okay. How do we get that for next time? How do we make sure that that's radiated somewhere? And a lot of times it's hard when you're thinking green field to sit down and think of all the data that you might want at any one time. But when you have an incident, it becomes readily apparent what data you wish you had. So it's important to sort of leverage those incidents and failures and get a better understanding of information that's missing so that you can improve your incident management process and your metrics and dashboarding.

Drew: One of the problems we sometimes face in development is that teammate members, individual team members hold a lot of knowledge about how a system works and if they leave the company or if they're out sick or on vacation, that knowledge isn't accessible to the rest of the team. It seems like the sort of DevOps approach to things is good at capturing a lot of that operational knowledge and building it into systems. So that sort of scenario where an individual has got all the information in their head that doesn't happen so much. Это справедливая оценка?

Jeff: It is. I think we've probably, I think as an industry we might have overstated its efficacy. And the only reason I say that is when our systems are getting so complicated, right? Gone are the days where someone has the entire system in their head and can understand it from beginning to end. Typically, there's two insidious parts of it. One, people typically focus on one specific area and someone doesn't have the whole picture, but what's even more insidious is that we think we understand how the system works. Верно. And it's not until an incident happens that the mental model that we have of the system and the reality of the system come into conflict. And we realize that there's a divergence, right? So I think it's important that we continuously share knowledge in whatever form is efficient for folks, whether it be lunch and learns, documentation, I don't know, presentations, anything like that to sort of share and radiate that knowledge.

Jeff: But we also have to prepare and we have to prepare and define a reality where people may not completely understand how the system works. Верно. And the reason I think it's important that we acknowledge that is because you can make a lot of bad decisions thinking you know how the system behaves and being 100% wrong. Верно. So having the wherewithal to understand, okay, we think this is how the system works. We should take an extra second to verify that somehow. Верно. I think that's super important in these complicated environments in these sprawling complex microservice environments. Whereas it can be very, it's easy to be cavalier if you think, oh yeah, this is definitely how it works. And I'm going to go ahead and shut the service down because everything's going to be fine. And then everything topples over. So just even being aware of the idea that, you know what, we may not know a hundred percent how this thing works.

Jeff: So let's take that into account with every decision that we make. I think that's key. And I think it's important for management to understand the reality of that as well because for management, it's easy for us to sit down and say, “Why didn't we know exactly how this thing was going to fail?” And it's like, because it's complicated, right, because there's 500 touch points, right, where these things are interacting. And if you change one of them, it changes the entire communication pattern. So it's hard and it's not getting any easier because we're getting excited about things like microservices. We're getting excited about things like Kubernetes. We're giving people more autonomy and these are just creating more and more complicated interfaces into these systems that we're managing. And it's becoming harder and harder for anyone to truly understand them in their entirety.

Drew: We've talked a lot about a professional context, big organizations and small organizations too. But I know many of us work on smaller side projects or maybe we volunteer on projects and maybe you're helping out someone in the community or a church or those sorts of things. Can a DevOps approach benefit those smaller projects or is it just really best left to big organizations to implement?

Jeff: I think DevOps can absolutely benefit those smaller projects. And specifically, because I think sort of some of the benefits that we've talked about get amplified in those smaller projects. Верно? So exporting of expertise with automation is a big one, right? If I am… Take your church example, I think is a great one, right? If I can build a bunch of automated tests suites to verify that a change to some HTML doesn't break the entire website, right, I can export that expertise so that I can give it to a content creator who has no technical knowledge whatsoever. Верно. They're a theologian or whatever, and they just want to update a new Bible verse or something, right. But I can export that expertise so that they know that I know when I make this content change, I'm supposed to run this build button.

Jeff: And if it's green, then I'm okay. And if it's red, then I know I screwed something up. Верно. So you could be doing any manner of testing in there that is extremely complicated. Верно. It might even be something as simple as like, hey, there's a new version of this plugin. And when you deploy, it's going to break this thing. Верно. So it has nothing to do with the content, but it's at least a red mark for this content creator to say “Oh, something bad happened. I shouldn't continue. Верно. Let me get Drew on the phone and see what's going on.” Верно. And Drew can say, “Oh right. This plugin is upgraded, but it's not compatible with our current version of WordPress or whatever.” Верно. So that's the sort of value that we can add with some of these DevOps practices, even in a small context, I would say specifically around automation and specifically around some of the cultural aspects too.

Jeff: Right? So I've been impressed with the number of organizations that are not technical that are using get to make changes to everything. Верно. And they don't really know what they're doing. They just know, well, this is what we do. This is the culture. And I add this really detailed commit message here. And then I push it. They are no better than us developers. They know three get commands, but it's the ones they use over and over and over again. But it's been embedded culturally and that's how things are done. So everyone sort of rallies around that and the people that are technical can take that pattern.

Jeff: … around that and the people that are technical can take that pattern and leverage it into more beneficial things that might even be behind the scenes that they don't necessarily see. So I think there's some value, definitely. It's a matter of how deep you want to go, even with the operations piece, right? Like being able to recreate a WordPress environment locally very easily, with something like Docker. They may not understand the technology or anything, but if they run Docker Compose Up or whatever, and suddenly they're working on their local environment, that's hugely beneficial for them and they don't really need to understand all the stuff behind it. In that case, it's worthwhile, because again, you're exporting that expertise.

Drew: We mentioned right at the beginning, sort of putting off as much sort of DevOps as possible. You mentioned using tools like Heroku. And I guess that sort of approach would really apply here on getting started with, with a small project. What sort things can platforms like Heroku offer? I mean, obviously, I know you're not a Heroku expert or representative or anything, but those sorts of platforms, what sort of tools are they offering that would help in this context?

Jeff: So for one, they're basically taking that operational context for you and they're really boiling it down into a handful of knobs and levers, right? So I think what it offers is one, it offers a very clear set of what we call the yellow brick road path, where it's like, “If you go this route, all of this stuff is going to be handled for you and it's going to make your life easier. If you want to go another route, you can, but then you got to solve for all this stuff yourself.” So following the yellow brick road route helps because one, they're probably identifying a bunch of things that you hadn't even thought of. So if you're using their database container or technology, guess what? You're going to get a bunch of their metrics for free. You're going to get a lot of their alerting for free. You didn't do anything. You didn't think anything. It's just when you need it, it's there. And it's like, “Oh wow, that's super are helpful.”

Jeff: Two, when it comes to performance sizing and flexibility, this becomes very easy to sort of manage because the goal is, you're a startup that's going to become wildly successful. You're going to have hockey stick growth. And the last thing you necessarily really want to be doing is figuring out how to optimize your code for performance, while at the same time delivering new features. So maybe you spend your way out of it. You say, “Well, we're going to go up to the next tier. I could optimize my query code, but it's much more efficient for me to be spending time building this next feature that's going to bring in this new batch of users, so let's just go up to the next tier,” and you click button and you move on.

Jeff: So being able to sort of spend your way out of certain problems, I think it's hugely beneficial because tech debt gets a bad rap, but tech debt is no different than any debt. It's the trade off of acquiring something now and dealing with the pain later. And that's a strategic decision that you have to make in every organization. So unchecked tech debt is bad, right? But tech debt generally, I think, is a business choice and Heroku and platforms like that enable you to make that choice when it comes to infrastructure and performance.

Drew: You've written a book, Operations, Anti-Patterns, DevOps Solutions, for Manning. I can tell it's packed with years of hard-earned experience. The knowledge sort of just leaps out from the page. And I can tell it's been a real labor of love. It's packed full of information. Who's your sort of intended audience for that book? Is it mostly those who are already working in DevOps, or is it got a broader-

Jeff: It's got a broader… So one of the motivations for the book was that there were plenty of books for people that we're already doing DevOps. You know what I mean? So we were kind of talking to ourselves and high-fiving each other, like, “Yeah, we're so advanced. Awesome.” But what I really wanted to write the book for were people that were sort of stuck in these organizations. I don't want to use the term stuck. That's unfair, but are in these organizations that maybe aren't adopting DevOps practices or aren't at the forefront of technology, or aren't necessarily cavalier about blowing up the way they do work today, and changing things.

Джефф: Я хотел написать им, в основном отдельным участникам и менеджерам среднего звена, чтобы сказать что-то вроде: «Вам не нужно быть техническим директором, чтобы иметь возможность вносить такие постепенные изменения, и вам не нужно иметь это. революцию в продажах, чтобы иметь возможность воспользоваться некоторыми преимуществами DevOps». Так что это было своего рода любовным письмом для них, чтобы сказать: «Эй, ты можешь сделать это по частям. Вы можете сделать это самостоятельно. И есть все эти вещи, которые вы, возможно, не считаете связанными с DevOps, потому что думаете об этом как об инструментах и ​​Kubernetes». Не каждая организация… Если бы вы были за этот штат Нью-Йорк, как правительство штата, вы не собираетесь просто прийти и внедрить Kubernetes за одну ночь. Верно? Но вы можете реализовать то, как команды общаются друг с другом, как они работают вместе, как мы понимаем проблемы друг друга и как мы можем решать эти проблемы с помощью автоматизации. Это вещи, находящиеся в сфере вашего влияния, которые могут улучшить вашу повседневную жизнь.

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

Дрю: Похоже, ваша книга — одна из них, но есть ли другие ресурсы, к которым могут обратиться люди, желающие начать работу с DevOps? Есть ли хорошие места, чтобы изучить этот материал?

Джефф: Да. Я думаю, что DevOps для чайников Эмили Фриман — отличное место для начала. Это действительно отличная работа по сортировке некоторых основных концепций и идей, а также того, к чему мы стремимся. Так что это было бы хорошим местом для начала, просто чтобы получить представление о местности. Я думаю, что проект «Феникс» — еще один замечательный источник Джина Кима. И это здорово, так как это готовит почву для типов проблем, которые могут возникнуть вне среды DevOps. И он отлично справляется с выделением тех паттернов и личностей, которые встречаются во всех типах организаций снова и снова. Я думаю, что это отлично помогает выделить их. И если вы прочитаете эту книгу, я думаю, вы закончите тем, что будете кричать на страницы, говоря: «Да, да. Этот. Этот." Итак, это еще одно прекрасное место.

Джефф: И затем оттуда, погрузившись в любое руководство по DevOps. Я собираюсь корить себя за эти слова, но Google SRE Handbook был еще одним замечательным местом для поиска. Поймите, что вы не Google, так что не думайте, что вы обязаны все реализовывать, но я думаю, что многие их идеи и стратегии подходят для любой организации, и это отличные места, где вы можете что-то взять и сказать что-то вроде: «Хорошо, мы собираемся сделать нашу операционную среду немного более эффективной». И это, я думаю, будет особенно заметно для разработчиков, которые играют роль оператора, потому что он действительно фокусируется на программном подходе к решению некоторых из этих проблем.

Дрю: Итак, я узнал все о DevOps. Что ты узнал в последнее время, Джефф?

Джефф: Kubernetes, чувак. Да. Kubernetes был для нас настоящим источником чтения и знаний. Итак, мы пытаемся внедрить это в Centro в настоящее время, чтобы расширить возможности разработчиков. Мы хотим сделать шаг вперед от того, где мы находимся. У нас есть много средств автоматизации, но прямо сейчас, когда дело доходит до внедрения нового сервиса, моя команда все еще активно этим занимается, в зависимости от характера сервиса. И мы не хотим быть в этом направлении работы. Мы хотим, чтобы разработчики могли перенести идею от концепции к коду и развертыванию, и сделать это там, где операционный опыт систематизирован в системе. Итак, пока вы движетесь по системе, система направляет вас. Поэтому мы считаем, что Kubernetes — это инструмент, который поможет нам в этом.

Джефф: Это просто невероятно сложно. И это большой кусок, чтобы откусить. Итак, выяснив, как выглядят развертывания? Как мы можем использовать эти операторы внутри Kubernetes? Как выглядит CICD в этом новом мире? Итак, вы много читали, но в этой области вы постоянно учитесь, верно? Неважно, как долго вы этим занимаетесь, как долго вы этим занимаетесь, где-то в каком-то аспекте этой области вы идиот. Итак, это просто то, к чему вы как бы адаптируетесь.

Дрю: Снимаю шляпу, как я сказал, даже после всех этих лет, хотя я вроде как понимаю, где он находится в стеке, я до сих пор понятия не имею, что делает Kubernetes.

Джефф: Иногда я чувствую себя так же. Такое ощущение, что он делает всего понемногу, верно? Это DNS 21 века.

Дрю: Если вы, как слушатель, хотели бы услышать больше от Джеффа, вы можете найти его в Твиттере, где он темный и занудный, а также найти его книгу и ссылки на прошлые презентации и сообщения в блогах на его сайтеreachabledevops.com. Спасибо, что присоединился к нам сегодня, Джефф. Были ли у вас напутствия?

Джефф: Просто продолжай учиться, просто иди туда, продолжай учиться и общайся со своими коллегами. Говорите, говорите, говорите. Чем больше вы можете разговаривать с людьми, с которыми работаете, тем лучше понимаете, тем лучше сопереживаете, и если в организации есть кто-то, кого вы ненавидите, убедитесь, что вы сначала поговорили с ним.