Какой набор навыков желателен для инженера в организации DevOps? Давайте взглянем. Геодезический DevOps сообщения вакансии , вы должны быть хорошо знакомы с десятками технологий вы никогда не использовать в условиях непроизводственных. Читая статьи на devops.com , вы должны уметь писать 1500 слов, ничего не говоря. Посещая конференции DevOpsDays или встречи DevOps , вы должны иметь тонко настроенное чувство сочувствия. Так много вещей, на чем вы должны сосредоточиться?
В этом посте я расскажу о трех лучших навыках DevOps, которые, на мой взгляд, наиболее важны для инженеров, без какого-либо конкретного порядка.
Код
Когда DevOps впервые стал #TrendingTopic, возникли некоторые разногласия, но я думаю, что мы уже решили это: если вы инженер в организации DevOps, вы должны иметь возможность предоставлять решения в виде кода. Неважно, являетесь ли вы разработчиком, оперативным сотрудником, QA, администратором базы данных, безопасностью, аналитикой данных и т. Д. — стабильность, возникающая при моделировании наших систем в коде, намного превышает любую сложность, с которой вы столкнулись.
Обратите внимание, что я сказал «доставлять решения как код», а не просто «писать код». Соблюдение «определения выполненного» является одной из концепций, которым команды платят за слово, но на самом деле не часто реализуют. Смотрите также: посмертные, непрерывная интеграция, принятие решений на основе данных. Определение done для фрагмента кода не «передается на Github», оно «обеспечивает ценность для клиентов». Клиенты включают внутренние заинтересованные стороны.
Веб-сайты, которые учат вас кодированию, часто упускают этот момент. Артефакт, который вы создаете для перехода к следующему уроку, представляет собой класс или функцию, которые проходят тесты, которые они написали. Люди берут курс «Изучай Рубин» и расстраиваются, когда никто не нанимает их для написания поваренных книг для производственных систем. Чтобы было ясно, я не говорю, что вы не можете научиться кодировать онлайн. Просто помните, что, как инженер, написание кода — это часть вашей ценности для организации. Я расскажу об этом подробнее в следующем посте.
сопереживание
Когда мы говорим об эмпатии в DevOps, мы на самом деле говорим об эмпатии, основанной на опыте . Неосведомленное сочувствие может иметь разрушительные последствия. Вы часто видите это, когда инженеры обостряют проблемы. Пример:
Гарри (dev) недоволен обзором кода, который он получил от Кейт (ops). Его код работает отлично, и он думает, что Кейт просто педантична. Итак, Гарри приходит к Уэсу (менеджеру по разработке) по поводу конфликта. Уэс просматривает его и отправляет электронное письмо, в котором говорится, что отныне обзоры кода ops будут выполняться только до полной версии. Ops замедляет процесс разработки.
Непрерывная доставка уничтожена.
Если вы думаете про себя: «Этого никогда не произойдет», это происходит постоянно. Это происходит прямо сейчас в компании рядом с вами. Это локализованная эмпатия. Уэс, конечно, сопереживает, но только для своей команды . Он недостаточно хорошо понимает область ops, чтобы принять правильное решение. Это понятно. Но он не нашел время послушать другую вечеринку (ops). Это небрежность, результат локальной эмпатии.
Вот почему CAMS не CAM. Обмен информацией, который часто просто означает слушание, является ключевой практикой для развития эмпатии, основанной на опыте. Отточите свои активные навыки слушания и голосуйте ногами, если вы находитесь в организации, которая их не ценит.
связь
hard_engineering_problems = [
'naming things',
'cache invalidation'
]
hard_engineering_problems.append('communicating effectively')
Умные люди не застрахованы от самоуверенности. Инженеры умные люди. Но мы планируем наши разговоры? Нет, не совсем. Если мне что-то понадобится, я просто поговорю с ними. Понятно, что мне нужно и зачем это нужно. Они были бы плотными, чтобы не дать мне то, что мне нужно.
<conversation>
So I need...
...Let me explain it another way...
...I didn't know about that...
...Fine, but this is a mistake.
</conversation>
Звучит знакомо? Да уж.
Планирование общения — жизненно важный навык инженера. Независимо от того, планируете ли вы спринт, один на один со своим менеджером или обращаетесь к кому-то из другой команды за помощью, подготовка является ключевым моментом. Это особенно важно для сложных разговоров, которые часто возникают при переходе на DevOps.
Как минимум, вы должны знать, что вы хотите получить от разговора, прежде чем его иметь. Это твои цели. Запишите их. Это особенно полезно для вопросов, ответы на которые вам нужны. Слишком легко отвлечься и выйти на встречу с вашими вопросами без ответа. Подумайте об уступках, на которые вы готовы пойти, и запишите их тоже. Принесите свои заметки на встречу. Используйте ручку и бумагу, ноутбук отвлекает.
Вот в чем дело: если вы этого не делаете, вы ставите себя в невыгодное положение. Скорее всего, вы вступаете в разговор менее подготовленным, чем другая сторона. Если их цели противоречат вашим, у вас очень мало шансов получить то, что вам нужно. Эффективное общение — это подготовка. Подготовка бьет быть умным.
Спасибо за прочтение! Я надеюсь, что это было полезно.
Позже в этом месяце у меня будет гостевой пост на тему эффективного общения Говарда Перлштейна , друга с более чем 20-летним опытом, помогающего организациям улучшить общение и принять изменения.