Русский
Русский
English
Статистика
Реклама

Devoops

Никаких кликов интервью с Джессикой Дин о командной строке, автоматизации и DevOps

06.07.2020 12:10:38 | Автор: admin


Мне нравятся хоткеи, алиасы, shell-скрипты и другие способы повысить свою продуктивность с помощью клавиатуры. Сам я не очень далеко зашёл на этом пути, но меня всегда впечатляют люди, по-настоящему углубившиеся в это, и хочется их расспрашивать.


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


В трансляции DevOops мы с Михаилом Дружининым (xomyakus) поспрашивали её и об использовании терминала, и о совмещении миров Windows/Linux/Mac, а поскольку дело было на девопс-конференции, к концу разговор свернул ещё и в сторону Kubernetes. А сейчас, прямо перед новым онлайновым DevOops, мне захотелось перевести это интервью на русский, чтобы оно было и в текстовом формате.


Текстовый вариант чуть сокращённый, если предпочитаете посмотреть исходное англоязычное видео, оно вот:



Евгений Трифонов: Я заглянул в твои дотфайлы на GitHub и оказался впечатлён


Джессика Дин: Большое спасибо! Да, это интересный проект, и он продолжает разрастаться, я постоянно добавляю к нему разное. Я фанатка автоматизации, штук, упрощающих любой процесс. Мои дотфайлы так или иначе связаны с этим. Их можно использовать и в Linux, и в Windows Subsystem for Linux (хоть WSL1, хоть WSL2), и на macOS. Они обращаются к 17 разным опенсорсным инструментам. Основная причина, по которой я всем этим занялась упрощение моего рабочего процесса как с точки зрения разработки, так и с точки зрения эксплуатации.


А в последний раз я добавляла туда что-то как спикер, потому что ещё я очень люблю демонстрировать людям реальное демо и код. Я использую VS Code, но зрителям в зале сложно что-то увидеть на тёмном фоне, а у меня обычно включен он, и удобного способа переключаться между профилями не существовало. Поэтому я написала две функции для переключения, чтобы было удобно кодить в тёмном режиме, а потом демонстрировать код со сцены в светлом.


В общем, ура автоматизации, когда пишешь одну функцию вместо того, чтобы руками вбивать 10 команд.


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


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


Если речь о моей собственной системе, то я установлю всё, что мне может понадобиться, со всеми зависимостями. Но если я использую чужую, то мне нужен только удобный CLI с комфортным интерфейсом я использую тему для zsh Powerlevel9k (да, я знаю, что уже появился Powerlevel10k), у меня на экране много полезной информации. И сейчас я подумала, что мне нужна установочная опция, где устанавливаешь только этот интерфейс без всех остальных зависимостей. Сейчас главное бутылочное горлышко здесь это время, которое требуется на установку всего.


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


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


Джессика: Порой бывает! У меня даже есть пост со словами Down the Rabbit Hole в заголовке.


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


Действительно, наступает момент, когда ты понимаешь, что решение заняло у тебя слишком много времени. На macOS это оказалось непросто, а если заняться реализацией ещё и для Linux с Windows, то не закончишь никогда. Есть определённые моменты, когда надо спросить себя: Какую пользу я извлеку из этого? Сколько времени сэкономлю, потратив 48 часов на написание штуки, которая экономит каждый раз по три секунды?.


Но ещё есть любопытство, потому что все мы инженеры: Но я ведь уже начал, я не могу сдаться!


Михаил Дружинин: И как тебе удаётся себя остановить?


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


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


Евгений: У вас там целое сообщество людей, которые смотрят дотфайлы друг друга?


Джессика: Так и есть! Есть треды на Reddit об этом, есть видео в сети.


Ещё меня как-то упомянули в таком треде на Reddit как человека, который работает в Microsoft, пишет дотфайлы под Linux и macOS, выступает о Linux, получал и сертификаты Apple, и звание Windows MVP. Это было собрано в треде под грифом Мы не понимаем. Но я просто люблю работать с другими инженерами и мне неважно, на какой платформе кто работает! Я вношу свой вклад в сообщество dotfiles, до этого делала то же самое с PowerShell (ещё до выхода PowerShell Core, так что это было только для Windows). Сейчас забавно, когда мне приходится снова писать скрипты на PowerShell, столько отличий. Я просто люблю тусоваться в разных сообществах, и dotfiles одно из них.


Евгений: Интересно, что ты любишь Linux и работаешь в Microsoft. В этом нет противоречия, но, наверное, люди часто удивляются?


Джессика: Да! Потому что так было не всегда. Я каким-либо образом связана с Microsoft уже более 10 лет. Изначально работала на их подрядчика. И тогда была совсем другая эпоха с совсем другим руководством компании. Когда я пришла в кампус, у меня были iPhone и Mac и кто-то меня окликнул: Ты случайно не из тех, у кого Mac и iPhone? И я такая, пряча свой рюкзак и комп: Кто-нибудь! Срочно дайте мне Windows Phone! Сбегайте в музей! Я не хочу быть белой вороной! Даже в команде, с которой я работала, подшучивали, потому что меня все знали как любительницу Linux и Apple, хотя в то же время у меня был статус Windows MVP и сертификация.


Я тогда по работе занималась примерно тем же, что и сейчас делаю как advocate, но тогда делала это в онлайне мы называли это вовлечением через социальные сети. Моя работа заключалась в том, чтобы взаимодействовать с сообществом на популярных в IT интернет-ресурсах вроде Reddit и Spiceworks, общаться с теми, у кого были технические вопросы. Это было во времена Microsoft Deployment Toolkit и SCCM. Я помогала людям в этих сообществах, а в то же время была инженером интеграции систем Linux и чинила компьютеры Apple. Так что я всегда пересекала границы платформ. Но тогда это было нетипично.


Сейчас я в Microsoft уже почти 4 года и то, как изменилось направление внутреннего и внешнего развития, взрывает мне мозг каждый день. 10 лет назад я была полезна, работая на подрядчика Microsoft, но из меня вышла бы не очень хорошая сотрудница непосредственно для Microsoft, потому что я любила работать на Linux и Mac, и не собиралась от них отказываться. И 4 года назад они наняли меня после моего выступления о линуксовом веб-сервере. Я такая: Вы в курсе, что я только что говорила про Linux, да? Так что конфликта тут больше нет, хотя и есть определённое прошлое. Это уже совсем другой Microsoft!


Евгений: А что для такого человека, как ты, означало появление Windows Subsystem for Linux? Перевернуло ли это всю твою жизнь? :)


Джессика: Ну, моя главная система для разработки это по-прежнему Mac. Но у меня дома есть и Surface Book. И это действительно сказывается особенно теперь, с WSL 2 и опенсорсным Terminal. У меня может быть и PowerShell, и Ubuntu, и Fedora, и любые другие дистрибутивы, и я могу настраивать разные профили. Я работала с командой WSL с момента его появления.


Мой коллега, Скотт Хансельман, шутил, что он провёл нагрузочное тестирование моего блога, ретвитнув один из моих постов пару лет назад, когда у Windows 10 вышло Fall Creators с обновлением WSL. Шутка была в том, что в блог пришло так много читателей, что он упал и мне пришлось его поднимать. Это был пост о том, как можно взять терминал, дотфайлы, о которых мы говорили, и сделать так, чтобы на WSL всё выглядело идентично тому, что я запускаю на Mac и Ubuntu.


Это взорвало людям мозг. И до сих пор взрывает мозг мне! Мне не пришлось вносить никаких изменений. Код, который я использовала на Ubuntu такой же, какой я использовала на WSL. Поэтому у моих дотфайлов сейчас всего две ветки одна из них называется "WSL", но работает и на Linux, а другая для macOS. Я до сих пор влюбляюсь в свою работу, просто глядя на направление, в котором мы двигаемся. Объединение разработчиков всех платформ.


Евгений: Иногда я ввожу поисковые запросы не в браузере, а в терминале с помощью ddgr. Подозреваю, такой человек, как ты, тоже делает в терминале что-то, что обычно делают иначе?


Джессика: Это правда, особенно в отношении CI/CD-пайплайнов я работаю ещё в DevOps-команде, занимаюсь автоматизацией скриптами, и там могу делать проверки вроде открывается ли такой-то URL. И в моём докладе здесь, на DevOops, есть пример использования curl. Чтобы протестировать такие вещи, я сначала выполняю их локально в терминале до того, как помещу в пайплайн. А в итоге я ощущаю, что могу выполнять такие задачи эффективнее, потому что для меня становится естественным выполнять их из командной строки.


Я уже говорила про мои дотфайлы, что всегда хочу видеть в терминале определённую информацию, и в том числе хочу знать мои внутренний и внешний IP-адреса. Некоторые люди, чтобы узнать свой IP, идут на сайт вроде https://whatismyipaddress.com/. А у меня это просто часть терминала.


Когда-то я не была таким энтузиастом командной строки, и тогда задавала вопрос Зачем тратить столько времени, набирая что-то на клавиатуре. А потом поняла, что если однажды набрал что-то, и оно осталось в истории или было сохранено как функция, то вызвать это гораздо быстрее, чем кликать! Так что теперь мой личный бренд #noclickyclicky.


Михаил: Как ты к этому пришла? Как долго ты шла к осознанию, что печатать быстрее?


Джессика: Примерно 5-6 лет. Работая одновременно и с Linux, и с технологиями Microsoft, я деплоила приложения и с IIS, где было очень много кликанья, и с Linux, где было сплошное печатание. Каждый раз, когда разворачивала на Linux всё шло без проблем, а на IIS всё было гораздо сложнее. В итоге я начала писать скрипты на PowerShell так я ещё дальше зашла в автоматизацию. В общем, это был долгий путь.


Михаил: Какую часть своего рабочего дня ты проводишь в терминале сейчас?


Джессика: Terminal у меня всегда запущен, он всегда открыт в фоне. Я бы сказала, что непосредственно в нём не меньше 50 времени, возможно, больше. А поскольку я пользуюсь DevOps-инструментами, повсюду код: в Codefresh и Azure DevOps Serviсes YAML, в Jenkins Groovy Поэтому у меня ощущение, что я всё время живу либо в командной строке, либо в VS Code, и терминал всегда открыт.


Михаил: Ещё один вопрос, чтобы закрыть эту тему. Vim или Emacs?


Джессика: Vim.


Я знаю некоторых, кто предпочитает Pico, Emacs, nano Не могу представить, зачем может понадобиться работать в nano Я из тех сумасшедших, кто за Vim. А вы как? Vim или Emacs? И в tmux что используете, Ctrl+A или дефолтное Ctrl+B?


Михаил: Vim, Ctrl+B.


Евгений: Vim. К вопросу о нём: другой спикер Себастиан Дашнер сегодня рассказал нам, использует плагин Vimium в браузере и IdeaVim в IntelliJ IDEA. Ты чем-то подобным пользуешься?


Джессика: Нет. Самое нердовское, что я использую это плагин NERDTree. Он добавляет мне файловый менеджер слева и я могу нажать Ctrl+N, чтобы этот менеджер появлялся и скрывался. Ну и ещё я использую таблицу стилей в Vim. У меня есть моя обычная таблица стилей со шрифтами и цветными штуками для терминала, а в Vim свое цветовое оформление. Вроде бы сейчас использую схему wombat Ну, это всё в открытом доступе, можете сами проверить.


Евгени: Мне хочется делать как можно больше с клавиатуры, но хватает ситуаций, когда всё-таки берусь за мышку/тачпэд. А когда идёшь по жизни с девизом #noclickyclicky, какие сценарии могут вынудить всё-таки оторваться от клавиатуры?


Джессика: Мы же уже говорили про DevOps. Если я демонстрирую Azure DevOps и показываю общую картину того, как он работает (а это, по сути, система запуска задач), я открываю то, что мы называем визуальным редактором. Там список задач без всякого YAML, и я пользуюсь мышкой, чтобы его показать В общем, пользуюсь мышью для навигации в браузере, но когда делаю что-то с кодом, мои руки на клавиатуре.


Михаил: Вчера на BOF-сессии о будущем Kubernetes говорили как раз о том, что происходит переход к кликам в браузере, и больше не надо возиться с YAML, больше не нужно быть YAML-разработчиком, спасибо и на этом


Джессика: Прямо как с табуляцией и пробелами!


Михаил: GitHub также выпустил GitHub Actions он тоже визуальный с кликами. Что ты думаешь об этом направлении? Мне кажется, люди так позабудут о клавиатуре.


Джессика: Возможно, это просто говорит моя страсть к командной строке, но если вспомнить, как всё развивалось в последние 10-15 лет, мне кажется, что она никуда не денется.


Я думаю, что хотя кликанье проще как точка входа, командная строка является гораздо более мощным инструментом с точки зрения воспроизводимости. Если мы дойдём до такого момента, когда я могу кликами настроить всё, а потом экспортировать и легко использовать это снова, это будет хорошо но ведь это тоже будет в виде некоторого кода, чтобы можно было не делать заново все эти клики. Я не могу запрограммировать свою руку, чтобы совершать одни и те же повторяемые действия, но я могу запрограммировать те же GitHub Actions так, чтобы у меня были одни и те же последовательные шаги.


Михаил: Сделать конфигурацию в UI, потом экспортировать в некий код, а потом продолжить что-то с ним делать.


Джессика: Потому что так я могу его ещё и проверить. Я могу разместить его вместе с моим исходным кодом, с моим приложением...


Михаил: посмотреть diff.


Джессика: Да, особенно. Если я собираюсь обновить мой пайплайн, мне нужно посмотреть разницу, что я изменила, особенно если пайплайн сломается. Мне нужна история. Я не уверена, что мы когда-нибудь отойдём от кода. Да, мы будем улучшать и упрощать его, в этом основная цель того же Kubernetes. Он был создан чтобы упрощать. Helm был создан, чтобы упрощать упрощённое. Есть другие инструменты такие как Draft и Skaffold, которые были сделаны, чтобы упростить и его.


В Microsoft у нас есть Azure Dev Spaces, который, судя по роадмапу, в будущем будет работать даже вне Azure, и он был сделан, чтобы работать с ещё большим уровнем абстракции, когда тебе не нужно беспокоиться про Docker или Kubernetes. У тебя просто может быть изолированная песочница. Как разработчице мне не нужно что-либо настраивать и мне не нужно иметь дело с кодом. Мы постоянно работаем над тем, чтобы упростить простое. Мне кажется, мы продолжим двигаться в этом направлении.


Михаил: Как ты думаешь, каким будет следующий конкретный уровень упрощения Kubernetes? На что бы ты поставила?


Джессика: Предсказательница из меня никакая! Я не знаю. Если мы вернёмся в прошлое, виртуализация уже была первым шагом абстракции. Больше не было нужды в физических машинах, теперь можно виртуализировать окружение. Потом при помощи контейнеров виртуализировали ядро и продвинули виртуализацию ещё дальше. Потом оркестрация стала способом управлять и продолжить абстрагировать. У нас есть Serverless. Теперь нас есть возможность объединить Serverless с оркестрацией.


Мне кажется, что дальнейшее направление просто продолжать выводить эту абстракцию к большему упрощению, и это реально очень просто, потому что чем большей абстракции мы достигаем в Kubernetes, тем сложнее всё становится, правильно? Сейчас у меня есть 10 разных микросервисов для одного приложения, в одном из них баг. Как мне провести отладку? Я могу это сделать, используя определенные инструменты и методы, хотя если мы сможем сделать это доступнее, то это именно то направление, куда нам нужно двигаться. Нам нужно быть уверенными, что чем больше мы абстрагируем, тем более полное у нас понимание того, зачем это делать, а почему это делать не надо.


Не всё нужно разбирать до такого мелкого уровня. Не всё надо запускать в Kubernetes. Люди говорят: Kuberenetes во все поля! Зачем? Келси Хайтауэр как-то твитнул, что лучшая часть понимания контейнеров и будущего направления их развития не в том, чтобы понимать, как ими пользоваться, а в том, чтобы понимать, когда ими пользоваться не надо. Мне кажется, это то направление, в котором нам нужно двигаться дальше.


Михаил: Просто перестаньте использовать лямбды, контейнеры, ВМ


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


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


Евгений: Вот на этом и остановимся, потому что время на интервью закончилось. Спасибо за ответы!


Уже сегодня в 17:00 стартует новая конференция DevOops: в этот раз в онлайне и пятидневная. Там без слова Kubernetes, конечно, тоже не обойдётся! А ещё будут легенда DevOps Джон Уиллис, ряд докладов про DevOps как культуру, любимец публики Барух Садогурский и многое другое смотрите полную программу, чтобы понять, сколько там актуального лично для вас.
Подробнее..

Ламповые стримы этой недели от JUG Ru Group дискуссия с Королем разработки и не только

21.09.2020 20:06:45 | Автор: admin


Виктория Алмазова на одном из прошедших шоу


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


Для затравки: вы наверняка читали пост Объясните, почему мой рокет-саенс бэкенд билдится пару секунд, а четыре формы на фронте полгода. Завтра обсудим с fillpackart в прямом эфире, где он не прав. Под катом ссылки на этот и другие выпуски этой недели.


Вторник, 22 сентября: JS, тестирование и все-все-все


Тяжелое утро с HolyJS


Время: 22 сентября в 10:00 (мск)
Как смотреть: трансляция на YouTube


Евгений Кот (Wrike) и Алексей Золотых (Infobip), конечно же, тоже читали нашумевший хабрапост и решили обсудить его непосредственно с автором fillpackart. Обычно Тяжелое утро с HolyJS рассчитано на JS-разработчиков, но похоже, что в этот раз интересно будет вообще всем!


Heisenbug Show


Время: 22 сентября в 13:30 (мск)
Как смотреть: трансляция на YouTube


Шоу проведет Никита Макаров, руководитель команды автоматизации тестирования в Тинькофф. Вместе со специалистом по тестированию и спикером нескольких предыдущих Heisenbug'ов Андреем Сатариным они пообщаются о тестировании распределенных систем и обсудят особенности QA в таких проектах.




Среда, 23 сентября: Java и .NET


Вторая чашка кофе с Joker


Время: 23 сентября в 14:00 (мск)
Как смотреть: на YouTube-канале


Ведущие Андрей Когунь и Антон Архипов поговорят с Дмитрием Чуйко и Александром Белокрыловым из BellSoft. Речь пойдёт и о Liberica JDK, над которой работают Дмитрий с Александром, и просто о последних Java-новостях.


Барная стойка


Время: 23 сентября в 19:00 (мск)
Как смотреть: трансляция на YouTube


Барная стойка виртуальная замена афтерпати после конференции DotNext с разговорами о технологиях и жизни, шутками и неформальной обстановкой. Шоу ведут Михаил Щербаков и Максим Аршинов. А гость в этот раз Роман Неволин с его разносторонними IT-интересами (от функциональщины до машинного обучения), разнообразным послужным списком (от EPAM до Revolut) и разноцветными волосами.




Четверг, 24 сентября: C++ и Android-разработка


Pure Virtual Cast


Время: 24 сентября в 19:00 (мск)
Как смотреть: трансляция на YouTube


Pure Virtual Cast лайв-шоу от команды C++ Russia. Общаемся с людьми из тусовки C++ о технологиях, разработке и новостях IT.


В новом выпуске ведущие Сергей Платонов и Алексей Веселовский пригласили Александра Бычука, архитектора решений в Лаборатории Касперского. Александр проектирует бэкенд корпоративных систем, очень любит интеграцию и С++ и всегда рад обсудить C++ Enterprise Edition. О чем пойдет речь в выпуске: параллелизм и конкурентность, чем они отличаются и что есть в C++ для этого, какие проблемы. К чему приводит попытка вылечить часть болячек переходом на Go, какие при этом профиты, и какая ждет С++ программиста боль при таком переходе.


GDG live


Время: 24 сентября в 20:00 (мск)
Как смотреть: трансляция на YouTube-канале Mobius


На конференции Mobius 2019 Moscow был отлично принят доклад Степана Гончарова Gradle от А до Я. А теперь на встрече GDG этот доклад будут коллективно разбирать так что можно будет узнать по теме ещё больше и зайти по алфавиту ещё дальше!




Пятница, 25 сентября: DevOps


DevOops в рабочий полдник


Время: 25 сентября в 18:00 (мск)
Как смотреть: трансляция на YouTube


Ведущие Барух Садогурский и Алексей Кирпичников возьмут интервью у Андрея Девяткина: сооснователя консалтинг-агентства FivexL и консультанта, специализирующегося на построении cloud-native платформ доставки приложений в облаке AWS с применением инструментов HashiCorp.




Чтобы не пропускать интересные выпуски и заранее знать их темы, можно подписаться на соответствующую рассылку: Java, C++, тестирование, .NET, JS, DevOps.

Подробнее..

Новая неделя стримов от SvelteJS до Rider

28.09.2020 20:13:28 | Автор: admin


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


Вторник, 29 сентября: JS и тестирование


Тяжелое утро с HolyJS


Время: 29 сентября в 10:00 (мск)
Как смотреть: трансляция на YouTube


На прошлой неделе у Тяжелого утра с HolyJS был жаркий холиварный выпуск с королём разработки. На этой должно быть более мирно: новым гостем будет Павел Малышев, лидер русскоязычного комьюнити Svelte. Он обсудит с ведущими Евгением Котом и Алексеем Золотых практику применения этого фреймворка с наглядными примерами. В последнее время о Svelte слышно всё чаще как ни ругай слово хайп, а похоже, пора запрыгивать в хайптрейн и получать хотя бы общее представление. Вот и повод это сделать!


Heisenbug Show


Время: 29 сентября в 13:30 (мск)
Как смотреть: трансляция на YouTube
Гостем выпуска станет Анастасия Бобелева QA Director в Exness. Ветераны конференции Heisenbug могут помнить доклад Анастасии Семенюк о тестировании ВКонтакте. Теперь Анастасия уже и не работает ВКонтакте, и не носит фамилию Семенюк, но поговорить с ней от этого не менее интересно. Она обсудит с ведущими работу QA в крупных компаниях, рабочие практики, результаты их применения, роль тестирования за пределами SDLC и то, как с помощью своей работы сделать мир лучше.




Среда, 30 сентября: Java и .NET


Вторая чашка кофе с Joker


Время: 30 сентября в 14:00 (мск)
Как смотреть: на YouTube-канале


Ведущие Андрей Когунь и Владимир Ситников поговорят с Дмитрием Александровым про кровавый энтерпрайз, конференции и GPU и поспорят, что лучше Microprofile или Spring.


Барная стойка


Время: 30 сентября в 19:00 (мск)
Как смотреть: на YouTube-канале


Барная стойка виртуальная замена афтепати после конференций с разговорами о технологиях и жизни, шутками и неформальной обстановкой. Михаил Щербаков и Максим Аршинов в этот раз поговорят с Кириллом Скрыганом: руководителем проекта Rider, который активно участвует в разработке и планировании IntelliJ IDEA, в прошлом один из основных разработчиков ReSharper.




Четверг, 1 октября: C++


Pure Virtual Cast


Время: 1 октября в 18:00 (мск)
Как смотреть: трансляция на YouTube


Системы сборки можно назвать одной из вечных тем в мире С++, о ней горазд поговорить любой. Но Александр Воронков забирался в тему глубже многих например, выступит с докладом о современном CMake на C++ Russia в ноябре. Вот с ним об этом и погоморим. Почему плохо (или хорошо?) писать в старом cmake-стиле? Зачем вообще cmake изучать, неужели там недостаточно знаний уровня "hello world" на cmake?




Пятница, 2 октября: DevOps


DevOops в рабочий полдник


Время: 2 октября в 18:00 (мск)
Как смотреть: канал DevOops на YouTube


В мире devops многие слышали имя Марка Смолли он и популярный конференционный спикер, и автор известных текстов. А его стаж в IT-индустрии превышает сорок лет, так что он лично застал многие тектонические сдвиги в ней. В общем, с ним явно есть о чём поговорить. Вот и поговорим!




Чтобы не пропускать интересные выпуски и заранее знать их темы, можно подписаться на соответствующую рассылку: Java, C++, тестирование, .NET, JS, DevOps.

Подробнее..

Путь DevOops-героя

20.11.2020 12:14:59 | Автор: admin

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


Антон Вайс, основатель Otomato Software, сравнил внедрение DevOps со строением мифов разных культур. Звучит фантастично, не правда ли? Но эта схема, как оказалось, отлично ложится на картину того, с чем сталкиваются многие DevOps-специалисты.



Далее текст будет вестись от лица Антона, а вы усаживайтесь удобнее, и добро пожаловать под кат.



Я начал свою карьеру в IT ровно 20 лет назад. Меня, молодого, неопытного, но подающего надежды программиста взяли писать на C в компанию, которая занималась разработкой поисковых механизмов.


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


Что делать? Замок было не открыть, на работе еще никого не знал, и звать на помощь было неудобно. Поэтому я тихонько скреб дверь, и меня услышал сисадмин (благо серверная находилась рядом с туалетом). Он попытался открыть дверь снаружи, но замок застрял изнутри. Тогда админ меня проинструктировал, как разобрать жалюзи, чтобы вылезти через окно. Я был спасен и получил первый урок, как работают вещи в IT: когда программист застревает в туалете, то админы помогают им выбраться.


Этот случай стал для меня отправной точкой. У всех нас есть подобная точка, ведь мы куда-то движемся, а движение инженеры привыкли описывать диаграммами, схемами и алгоритмами.


12 этапов путешествий DevOps-героя


Еще 70 лет назад американский исследователь мифологии Джозеф Кэмпбелл написал книгу Герой с тысячью лицами (к слову, она вдохновила Джорджа Лукаса на создание Звездных войн). Кэмпбелл, сравнив истории Будды, Иисуса, Мухаммеда, Гильгамеша и других божеств, пришел к выводу, что все эти мифы можно представить в виде истории судьбоносных путешествий архетипического героя, которые можно разложить на различные этапы. В первоначальной схеме было 18 этапов, затем голливудские сценаристы упростили схему до 12 этапов. Эти этапы настолько плотно впаяны в наш культурный код, что любую человеческую историю можно разложить на 12 этапов, в том числе DevOps-трансформацию.


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



Схема циклична, потому что конец каждого пути это начало нового витка. Чтобы стать настоящим DevOps-героем, индивиду и организации необходимо провести изменения по всем четырем измерениям:


  • люди;
  • процессы;
  • инструменты:
  • связывающее всех информационное пространство.

Обычный мир


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


Но в этом королевстве что-то прогнило, и мы услышали зов приключений зов DevOps.


Зов DevOps


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


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


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


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


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


Отказ от зова


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


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


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


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


Встреча с наставником


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


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


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


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


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


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


Четвертый вариант хорошо сочетается со всеми остальными книга, например Руководство по DevOps или Проект Феникс. Когда я был начальником интеграции в компании AT&T, на моем столе всегда лежала книга Непрерывное развертывание ПО Хамбла и Фарли, и во всех сложных ситуациях я обращался к первоисточнику за советом.


Мы заручились поддержкой наставника и наконец пересекаем порог.


Пересечение порога


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


Испытания, демоны и союзники


Герой сталкивается с первыми испытаниями, где его поджидают демоны:


  • сомнения;
  • страх ответственности;
  • вложение большого количества денег;
  • недостаток знаний;
  • борьба за власть;
  • нагромождение сложности;
  • бюрократизм.

Поначалу мы говорим, что распилим монолит, построим конвейер от кода до прода или же добавим по ops-у в каждую команду dev-ов. Но в процессе возникают более сложные вопросы:


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

Ответы на них мы получаем неопределенные, ведь нужно подгонять их под конкретные задачи.


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


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


Приближение к сокровенной пещере


Заручившись помощью союзников и прочитав полезную литературу, мы готовимся отвечать на самые важные вопросы:


  • языки программирования и фреймворки;
  • CI-сервер;
  • механизм деплоя;
  • базы данных;
  • очереди сообщений.

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


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


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


Точка смерти


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


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


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


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


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


Подарок силы


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


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

Когда мы получаем подарок силы, мы начинаем дорогу домой.


Дорога домой


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


Сам Кэмпбелл в книге написал:


The trick in returning is to retain the wisdom gained on the quest, to integrate that wisdom into a human life, and then maybe figure out how to share the wisdom with the rest of the world.

Джозеф Кэмпбелл

Возрождение или Обретение мастерства


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


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


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


Возвращение с эликсиром (история силы)


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


В нашей DevOps-истории такой историей является вклад в open source, который показывает направление движения и действительно помогает людям в работе. Мы пишем блоги, в которых рассказываем, что и как мы сделали, как другим людям найти правильный подход к улучшению рабочих процессов и как проверить, почему не работает. Примерами таких историй являются SRE от Google, модель Spotify, Netflix OSS и другие.


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


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


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


Как сказал Антон, помочь DevOps-специалисту пройти путь героя сможет наставник, которым может быть как человек, так и книга или доклад. А со 2 по 5 декабря 2020 года JUG Ru Group проводит онлайн-конференцию DevOops 2020 Piter, где вы сможете перенять опыт коллег и улучшить процессы вокруг себя. Там же Антон представит свой новый доклад От стресса к прогрессу: Обзор непрерывной доставки на Кубер.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru