Здравствуйте, меня зовут Алексей. Я работаю в IT-сфере. Много времени провожу в социальных сетях и мессенджерах по работе. И у меня развились различные аддиктивные сценарии поведения. Я отвлекался от работы и заглядывал в Facebook, чтобы посмотреть, сколько «лайков» накапало на какую-то резонансную публикацию. И вместо того, чтобы дальше работать с новыми текстами, я подвисал на состоянии старого. Я несколько раз за час практически неосознанно брал в руки смартфон — и в какой-то степени меня это успокаивало. Давало контроль над жизнью.

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

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

— Па-ап, мы все на одну фоточку помещаемся? — Не бойся, у меня на смарте широкоугольник.

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

Тем не менее пользователь все еще должен принимать подробные решения о том, как именно разворачивать, настраивать, управлять и масштабировать приложения. На усмотрение пользователя остаются вопросы масштабирования приложения, защиты, прохождения трафика. Этим Kubernetes отличается от обычных "платформ как услуга" (PaaS), к примеру Cloud Foundry и Heroku.

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

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

Другая общая черта — тенденция к минимизации и фокусировании кода, поэтому бессерверные вычисления иногда называют "функция как услуга" (FaaS).

Представлять инфраструктуру в виде кода в повторяемом текстовом формате — простая лучшая практика для систем, с которой не нужно мышевозить. За этой практикой закрепилось название — Infrastructure as Code, и пока что для ее осуществления, особенно в AWS, есть два популярных инструмента: Terraform и CloudFormation.

Сравниваю опыт работы с Terraform и CloudFormation

До прихода в Twitch (он же Amazon Jr.) я трудился в одном стартапе и года три использовал Terraform. На новом месте я тоже вовсю использовал Terraform, а потом компания продавила переход на все а-ля Amazon, включая CloudFormation. Я усердно разрабатывал лучшие практики и для того, и для другого, и оба инструмента использовал в очень сложных рабочих процессах в масштабах организации. Позднее, вдумчиво взвесив последствия перехода с Terraform на CloudFormation, я убедился, что Terraform, наверное, — лучший выбор для организации.

Вначале было слово. И слово это код.

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

А ещё строчки кода управляют ударными беспилотниками, операторы которых не особо выбирают, кто попал под удар — боевики или нонкомбатанты. Формируют механики удержания внимания в социальных сетях, вызывая аддиктивные сценарии поведения, FoMO (Fear of missing out, Синдром упущенной выгоды), дофаминовое выгорание и депрессию. Управляют в DarkNet электронными рынками наркотиков и оружия.

Профессия IT-разработчика подросла и возмужала — вслед за правами и привилегиями пришла пора появиться обязанностям и ограничениям. Так когда-то было с врачами, так когда-то было с военными.

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

Руководителю важно, чтобы в отделе всё крутилось, вертелось, стабильно выдавало результат. А ещё KPI постоянно висят дамокловым мечом. Потому поиск новых технологий и курсов уходит на 5-10 место.

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

Кубернетес меняет жизнь компании. Это факт.

А давайте посмотрим с другой стороны. K8s меняет в первую очередь жизнь самого администратора. Даёт возможность заработать больше денег, избавляет от многих рутинных задач, делает свободнее и значимее как профессионала, Kubernetes делает работу интересней.

Нам стало интересно, как изменилась профессиональная и личная жизнь ребят, которые прошли базовые Слёрмы. Чтобы обосновать потраченное время, мы предложили скидку на Слёрм Мега — и попросили участников дать ответы на несколько коротких вопросов: что им понравилось в Слёрме, что не понравилось, что бы они хотели улучшить.

На выходе из секс-клуба убили криминального блогера Мартина Кока. Компания MPC, один из его клиентов, оказалась далеко не обычным производителем телефонов.

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

Иван Круглов, Principal Developer в Booking.com, выступал на Слёрм DevOps c темой SRE, а после выступления согласился за чашкой кофе поговорить о Kubernetes, Service Mesh, open source и «нестандартных» решениях в Booking.com

Так как тема SRE оказалась намного обширнее, то Иван и его коллега Бен Тайлер, Principal Developer в Booking.com, согласились стать спикерами Слёрм SRE, который пройдёт 3—5 февраля 2020. Там будут рассмотрена теория и практика применения SLI/SLO/error budget, проведение разбора полетов (post-mortem), эффективная ликвидации IT-инцидентов, построение надежных систем (мониторинг и алертинг, graceful degradation, failure-injection, capacity planning, предотвращение cascading failures).

А сейчас слово Ивану.

В IT есть такое суеверие: «Работает, не трогай». Это можно сказать и про нашу систему мониторинга. В Southbridge мы используем Zabbix — когда мы его выбирали, он был очень крут. И, по сути, альтернатив у него не было.

Со временем наша экосистема обросла инструкциями, дополнительными обвязками, появилась интеграция с redmine. У Zabbix появился мощный конкурент, который превосходил во многих аспектах: скорость работы, HA практически из коробки, красивая визуализация, оптимизация работы в kubernethes окружении.

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

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

Зависимости мердж-реквестов

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

Мы понимаем, как важно всем управлять. Вот несколько улучшений в релизе 12.4, с которыми управление станет проще.

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

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

Павел Селиванов, архитектор решений Southbridge и преподаватель Слёрма, выступил с докладом на DevOpsConf 2019. Этот доклад — часть одной из тем углубленного курса по Kubernetes «Слёрм Мега».

Слёрм Базовый: введение в Kubernetes проходит в Москве 18-20 ноября.
Слёрм Мега: заглядываем под капот Kubernetes — Москва, 22-24 ноября.
Слёрм Онлайн: оба курса по Kubernetes доступен всегда.

Под катом — расшифровка доклада.

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

Я посмотрел, как эти компании вычисляют показатели безопасности других компаний. Оказалось, они смотрят на сочетание использования НТТР-заголовка для безопасности и репутации IP-адресов.

Репутация IP-адреса основывается на данных черных списков и списков спамеров в сочетании с данными о владельце общедоступного IP-адреса. Она, в принципе, должна быть чистой, если ваша компания не рассылает спам и в состоянии быстро определить и остановить вредоносное внедрение. Использование заголовка безопасности НТТР вычисляется аналогично тому, как работает Observatory от Mozilla.

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

Классический вариант вебинара — лектор рассказывает теорию и (в лучшем случае) дает немного практики. Мы решили попробовать альтернативный способ.

Павел Селиванов, архитектор решений в Southbridge и преподаватель Слёрма, будет во время вебинара создавать и настраивать кластер Kubernetes в Облаке КРОК, попутно комментируя свои действия.

После вебинара те, кто регистрировался с корпоративной почты, получат ссылку на использованные в вебинаре скрипты и плейбуки, и бесплатный триал Облака КРОК.

Когда мы в подобном формате проводили вебинары по Docker и Ansible, половину времени занимали вопросы участников, причем попадались очень интересные и неожиданные вопросы. Посмотрим, что получится в этот раз.

Регистрация

В предстоящем выпуске Red Hat Ansible Engine 2.9 вас ждут впечатляющие улучшения, и некоторые из них описаны в этой статье. Как обычно, мы разрабатывали улучшения Ansible Network в открытую, при поддержке сообщества. Присоединяйтесь — загляните на доску задач на GitHub и изучите план развития для выпуска Red Hat Ansible Engine 2.9 на странице wiki для Ansible Network.

Как мы недавно объявили, Red Hat Ansible Automation Platform теперь включает Ansible Tower, Ansible Engine и весь контент Ansible Network. Сейчас большинство популярных сетевых платформ реализуется через модули Ansible. Например:

• Arista EOS
• Cisco IOS
• Cisco IOS XR
• Cisco NX-OS
• Juniper Junos
• VyOS

Полный список платформ, которые полностью поддерживаются Red Hat через подписку Ansible Automation, опубликован здесь.

Burn out нечаянно нагрянет, когда его совсем не ждёшь. Когда человек впервые сталкивается с профессиональным выгоранием, у него возникают вопросы:

— Что со мной: осенняя хандра, депрессия или профессиональное выгорание?
— Что с этим делать?
— К кому идти за помощью?

Мы боимся признать, что у нас проблема. Тянем с походом к врачу, откладываем разговор с руководством. Пока синдром не разворачивается в полную силу, и всё летит кувырком — работа, карьера, семья.

Поэтому так важно разобраться в проблеме заранее, понять, что проблема решаема — и решаема разными способами.

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

Я обратился за разъяснениями к психиатру Максиму Малявину. Хобби Максима не раз спасало меня от плохого настроения, а быть может и от начала профессионального выгорания. Его «Психиатрические байки» способны спасти от серости и печали будней не хуже, чем волшебная пилюлька бромдигидрохлорфенилбензодиазепина. А книги Максима «Записки психиатра, или Всем галоперидолу за счёт заведения!» и «Новые записки психиатра, или Барбухайка, на выезд!» давно прописались на моей книжкой полке.

Как наша команда Delivery, используя только собственные ресурсы, переделала нашу систему под CI/CD.

Команды инженеров постоянно испытывают давление: нужно выдавать новые функции в виде достойного продукта и при этом постоянно минимизировать время цикла. Зачастую специалисты не думая хватаются за современный инструментарий. Непрерывная интеграция и поставка (CI/CD) встроены в GitLab, наше единственное приложение для жизненного цикла DevOps, и сейчас мы, чтобы еще больше сократить время цикла, всем составом мигрируем на Kubernetes. Однако к CI/CD — и в конечном итоге Kubernetes — мы шли не совсем обычным путем. Команда Delivery, переводя нас на непрерывную поставку GitLab.com, напрягла старую систему, и только потом мы полностью перешли на Kubernetes.

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

Знакомьтесь, если ещё не встречались. Это синдром профессионального выгорания.

В IT-сфере около 50% специалистов испытали на себе профессиональное выгорание. Этот синдром опасен самому сотруднику, и проекту, над которым он работает, и всей компании. Более 60% выгоревших сотрудников увольняются. А затраты на найм новых, обучение и онбординг чугунной гирей ложатся на бюджет. И время — оно вообще бесценно.

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

На митапе «День Техдира» Даниил Подольский, руководитель разработки MTGroup, сделал доклад по профессиональному выгоранию. Мне его выступление было интересно тем, что это взгляд управленца на проблему, а не просто рассказ рядового сотрудника о своём личном примере выгорания.