Jose, DevOps Lead в Accenture. Во время учебы Jose был интерном в NASA, в 2014 прошел полный Ironman, на данный момент делится лучшими DevOps практиками в качестве консультанта в датской компании Accenture

https://twitter.com/josequaresma

В чем разница между Dev и Ops?
Полагаю, основной момент в том, что это разные определения для разных людей. Когда пришел в DevOps (около 3-4 лет назад), я видел это в основном как своего рода различные инструменты, которые вы можете установить и настроить, чтобы заставить что-то работать. В частности, как хороший CI / CD пайплайн, который вы могли бы отправлять в продакшн. Однако, сегодня я думаю, что это намного шире понятие. Существуют несколько определений. Начнем с того, что это движение культуры. Которое говорит о том, что DevOps - расширение Agile в операционную сторону. Тем не менее я думаю, что данная специализация, прежде всего, является способом заставить Development & Operations сотрудничать больше и разделять общие цели. DevOps полагается на инструменты и автоматизацию, но дело не только в этом.

«DevOps больше похож на абстрактный класс, а одна из реализаций этого класса - SRE»

Когда системные администраторы стали DevOps?
Не уверен, что все они стали DevOps. В некоторых ситуациях вижу, что мы еще не пришли к этому. В правильном сценарии развития, где вы видите переход от системного администратора в DevOps, присутствует SRE (примечание редактора - Site Reliability Engineer). Согласно Google, SRE — поручение разработчикам программного обеспечения администрирование системы. Где-то слышал, и мне нравится эта идея, что SRE является своего рода средством создания DevOps. DevOps больше похож на абстрактный класс, а одна из реализаций этого класса - SRE. Идея состоит в том, чтобы перейти от этого старого мышления, когда системные администраторы относятся к серверам как к домашним животным (то есть дают им имена, заботятся о них). Переходом мышления от этого к подходам DevOps мира будет, если вы начнете воспринимать инфраструктуру как код, и ваш сервер абстрактно можно считать рогатым скотом. Когда что-то не так, вы просто убиваете его и создаете новый. Так что, это значительный сдвиг. Если кто-то еще не принял этой идеи, думаю, пора адаптироваться.

Как ты стал DevOps-ом?
Следует начать с моего образования. Я изучал компьютерную науку в университете. Итак, мои три года бакалавриата были в Португалии, в Лиссабоне. Потом мне захотелось попробовать что-то другое, и это привело к тому, что степень магистра закончил в Скандинавии. После чего получил Ph.D. по безопасности сети. Где-то на полпути Ph.D. осознал, что хочу войти в индустрию и что хочется видеть свою работу более осязаемой, я бы сказал. Этот момент был пять лет назад, тогда я начал как разработчик, работая с веб сервисами. Через год или около того уже руководил маленькой командой, мы разрабатывали софт для клиента. Принимал участие в архитектурных вопросах повышения уровня обслуживания. К тому моменту, когда перешел на новый проект, оказалось, что было свободно DevOps направление и мой руководитель предложил возглавить его. Можно назвать этот переход комбинацией старта работы над новым проектом, где я был больше сфокусирован на Agile, и стороной DevOps — как возможность возглавить группу DevOps в Дании.

«Ironman - отличный способ научиться не сдаваться»

Как выглядит твой распорядок дня?
Мне нравится заниматься спортом. Это неотъемлемая часть моего распорядка. Около 3-4 лет назад я занимался триатлоном на дистанции. Самая длинная дистанция была на Ironman в Германии, Challenge Roth (https://en.wikipedia.org/wiki/Challenge_Roth). Это был замечательный опыт и действительно жесткий, как и должен быть в таком случае. Во время соревнования я почувствовал, что не могу больше бежать и решил идти оставшиеся 30 километров. Затем встретил одного парня из команды, у которого была такая же проблема, и мы пошли вместе. Мы относились к этой ситуации, как к части игры, испытания и не теряли оптимизм. И последние 10 километров нам даже удалось пробежать. Это был отличный способ научиться не сдаваться.

Расскажи, пожалуйста, о твоем опыте интернатуры в NASA.
Это было в 2012 году и было частью моего Ph.D. Там я работал над системой, которая использовала формальные методы (в основном статический анализ и проверку моделей) для оценки безопасности коммуникационных протоколов. В рамках этого исследования я находился в Mountain View в NASA, где применял эти методы для (на то время новой) системы связи самолетов под названием ADS-B. Изначально она предназначалась для замены радара. Здорово вспоминать свой опыт там в окружении людей из разных компаний и наши труды.

Какие три книги ты бы посоветовал прочесть каждому?
Первую я бы посоветовал «Deep work», написанную Cal Newport (https://www.amazon.com/Deep-Work-Focused-Success-Distracted/dp/1455586692). В этой книге акцентируется внимание на важности фокуса на том, что вы делаете. Сегодня существует все больше вещей, которые нас отвлекают. Эта книга вышла пару лет назад и оказалась очень важной для меня. Следующая называется «Essentialism: The Disciplined Pursuit of Less» от Greg McKeown (https://www.amazon.com/Essentialism-Disciplined-Pursuit-Greg-McKeown/dp/0804137382). И последней я бы мог выделить «Radical candor» от Kim Scott (https://www.amazon.com/Radical-Candor-Kim-Scott/dp/B01KTIEFEE). Эта книга о том, как воспитывать культуру обратной связи. Как привести свою команду к тому, чтобы работать в среде, где люди заботятся друг о друге. И о том, как они могут давать друг другу честные фидбеки.

«Самосовершенствование может быть более эффективным, если уделять время отдыху».

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

«Я сосредотачиваюсь на идее, а не на слайдах с текстом»

Как ты готовишься к конференции?
Если мы возьмем за пример Highload fwdays (https://fwdays.com/en/event/highload-fwdays-2018), начальной фазой было то, что меня спросили, хочу ли поделиться своим опытом с DevOps-ами. Далее мы обсуждали, что именно они хотели бы услышать. Также я старался представить, какой будет аудитория, и кто будет присутствовать на конференции. Когда есть такая информация, легче с идеей и названием для выступления. Потом взял ручку и бумагу и стал работать над основным месседжем, которым хотел бы поделиться. Это помогло сделать мне каркас для презентации, на котором уже можно было составлять слайды. После этого было несколько репетиций, также просил своих коллег дать мне фидбек. Еще несколько репетиций и, думаю, что на этом все. Основная идея в том, что я сосредотачиваюсь на идее, а не на слайдах с текстом.

«Чтобы извлечь максимум пользы из конференции, рекомендую быть активным»

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