Привет, Хабр! Продолжаем разговор о механиках геймификации. Прошлая статья рассказывала о рейтинге, а в этой поговорим о древе навыков (технологическом древе, skill tree). Рассмотрим, как древо используется в играх и как эту механику можно применить в геймификации.

Прим. перев.: С Kubernetes-энтузиастами из проекта Garden мы познакомились на недавнем мероприятии KubeCon Europe 2019, где они произвели на нас приятное впечатление. Этот их материал, написанный на актуальную техническую тему и с заметным чувством юмора, — наглядное тому подтверждение, а посему мы решили его перевести.

Он рассказывает о главном (одноименном) продукте компании, идея которого — автоматизация рабочих процессов и упрощение разработки приложений в Kubernetes. Для этого утилита позволяет легко (буквально одной командой) разворачивать в dev-кластере новые изменения, сделанные в коде, а также предоставляет разделяемые ресурсы/кэши для ускорения сборки и тестирования кода командой. Две недели назад у Garden состоялся релиз 0.10.0, в котором стало возможным использовать не только локальный Kubernetes-кластер, но и удаленный: именно этому событию и посвящена данная статья.

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


Фотография со стока в тему для пущего эффекта

Честно говоря, Иван часто посмеивался над тщетными усилиями коллег из отдела мониторинга. Они прилагали огромные усилия для реализации метрик, которые им заказывало руководство компании. Они были настолько заняты, что больше никому ничего не хотели делать.

А руководству всё было мало – оно постоянно заказывало всё новые и новые метрики, очень быстро переставая пользоваться тем, что были сделаны ранее.

Последнее время все только и говорили про LeadTime – время поставки бизнесовых фич. Метрика показала сумасшедшее число – 200 дней на поставку одной задачи. Как же все охали, ахали и воздевали руки к небу!

Через некоторое время шум постепенно затих и от руководства поступил заказ на создание еще одной метрики.

Ивану было совершенно понятно, что и новая метрика точно также тихонько помрёт в тёмном уголке.

Действительно, размышлял Иван, знание числа совершенно никому ни о чём не говорит. 200 дней или 2 дня – нет никакой разницы, потому что по числу невозможно определить причину и понять, хорошо это или плохо.

Это типичная ловушка метрик: кажется, что новая метрика расскажет суть бытия и объяснит какой-то тайный секрет. Все так на это надеются, но ничего почему-то не происходит. Да потому что секрет надо искать вовсе не в метриках!

Для Ивана это был пройденный этап. Он понимал, что метрики – это просто обычная деревянная линейка для измерений, а все секреты надо искать в объекте влияния, т.е. в том, что эту метрику формирует.

Для интернет-магазина объектом влияния будут его клиенты, приносящие деньги, а для DevOps – команды, создающие и раскатывающие дистрибутивы с использованием конвейера.

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

Цель метрик DevOps

Понятно, что всем хочется уменьшить время поставки. 200 дней – это, конечно, никуда не годится.

Но как, вот в чем вопрос?

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

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



Откуда он взялся? Из простой мысли, что иногда люди выходят из офиса поесть что-то снаружи. Ближайший магазин у нас в 10 минутах от офиса (с учётом спуска-подъёма). Гораздо дешевле и практичнее принести сотрудникам бесплатную еду, чем тратить их время на её поиски, пускай и не за счёт компании. Сначала это были только здоровые закуски, но потом по мере роста офиса стали появляться сосиски, а для тех, кто иногда остаётся ждать ночи перед релизом, — пицца. При этом горячая еда тут не хранится постоянно, а приезжает отдельно.

Давайте проанализируем, как такое решение вообще могло быть принято.

Внутренняя кухня разработчика IT-продуктов многогранна и всегда переполнена разными задачами. В каждом проекте находят себе применение люди с разными обязанностями.

На примере одного проекта мы поглубже рассмотрим процесс разработки. Перед этим я опишу все этапы этого процесса и функциональные обязанности сотрудников в нем.

Статья-инструкция по установке и базовой настройке отказоустойчивого сервера Kea DHCP

Kea DHCP – это open-source DHCP сервер, разрабатываемый Internet Systems Consortium(ISC) с поддержкой DHCPv4 и DHCPv6.

ISC – это те же ребята, которые разрабатывают наши любимые bind и dhcpd. Kea – разработана на базе BIND 10.

Kea позволяет запустить dhcp-сервер как для небольших систем, так и для больших телеком/корпоративных компаний. Из нововведений – использование API для управления сервисом, возможность хранения базы lease в СУБД и использование hooks для дополнительных функций.
На момент написания статьи(июнь 2019) – последняя стабильная версия 1.5.0.

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

Поставили мы как-то заказчику на один объект систему электронного документооборота. А потом на другой объект. И еще на один. И на четвертый, и на пятый. Увлеклись настолько, что дошли до 10 распределенных объектов. Мощно получилось… особенно когда мы дошли до поставки изменений. В рамках поставки на продуктивный контур на 5 сценариев системы тестирования в итоге потребовалось 10 часов и 6-7 сотрудников. Такие затраты вынуждали нас выполнять поставки как можно реже. Через три года эксплуатации мы не выдержали и решили приправить проект щепоткой DevOps.



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

DevOps- и SRE-инженеры уже, наверное, не раз слышали о Prometheus.

Prometheus был создан на SoundCloud в 2012 году и с тех пор стал стандартом для мониторинга систем. У него полностью открытый исходный код, он предоставляет десятки разных экспортеров, с помощью которых можно за считанные минуты настроить мониторинг всей инфраструктуры.

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

Что такое Prometheus?
Зачем он нужен?
Чем он отличается от других систем?

Если вы совсем ничего не знаете о Prometheus или хотите лучше разобраться в нем, в его экосистеме и всех взаимодействиях, эта статья как раз для вас.

Привет! Это очередной традиционый список книг, оказавшихся полезными за год. Сугубо субъективный, конечно. Но я серьёзно рассчитываю, что вы подскажете ещё классных штук почитать.



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

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

Мультиплеер игры Call of Duty получил репутацию «мясорубки». Игрок спаунится, делает один-два убийства, если он достаточно хорош, потом умирает, респаунится, и всё повторяется заново. Я уже очень давно не играл в Call of Duty на консолях, поэтому должен был стать лёгкой мишенью, но на самом деле я тащу.

Я играю в Call of Duty: WWII на Xbox One, и мой kill/death ratio (отношение убийств к смертям) выше среднего. В режимах Team Deathmatch и Kill Confirmed я занимаю второе место с K/D ratio 21/14, первое место с 18/15 и пятое место с 14/11. Я впервые играю в мультиплеер Call of Duty: WWII, то есть не знаю карту, у меня нет мышечной памяти оружия, его темпа стрельбы и отдачи. Но мне с лёгкостью удаётся вести бегущие к укрытиям цели. Когда враг подбирается ко мне, я способен легко направить на него прицел и первым убить его.

Я бы с радостью сказал, что это просто моё мастерство, но правда в том, что я пользуюсь устройством, позволяющим играть вместо стандартного контроллера с мышью и клавиатурой (и другими устройствами ввода, которые официально не поддерживаются). Обычно на консолях такое невозможно. Устройство под названием XIM Apex стоит 100 долларов и выглядит как USB-стик и концентратор, позволяющий подключить к Xbox One (или PlayStation 4) мои мышь и клавиатуру от PC, в то время как мои противники и напарники скорее всего играют обычными контроллерами Xbox One.

Всем привет. Я работаю ведущим системным администратором в ОК и отвечаю за стабильную работу портала. Хочу рассказать о том, как мы выстроили процесс автоматической замены дисков, а затем, как исключили из этого процесса администратора и заменили его ботом.

Эта статья является своего рода транслитерацией выступления на HighLoad+ 2018

Введение

В последнее время стремительно растет популярность Kubernetes — все больше и больше проектов внедряют его у себя. Я же хотел коснуться такого оркестратора, как Nomad: он отлично подойдет проектам, где уже используются другие решения от компании HashiCorp, например, Vault и Consul, а сами проекты не являются сложными в плане инфраструктуры. В данном материале будет инструкция по установке Nomad, объединения двух нод в кластер, а также интеграции Nomad с Gitlab.

В преддверии DevOpsConf Виталий Хабаров взял интервью у Дмитрия Столярова (distol), технического директора и соучредителя компании «Флант». Виталий расспросил Дмитрия про то, чем занимается «Флант», про Kubernetes, развитие экосистемы, поддержку. Обсудили, зачем нужен Kubernetes и нужен ли вообще. А еще про микросервисы, Amazon AWS, подход «Мне повезет» в DevOps, будущее самого Kubernetes, почему, когда и как он захватит мир, перспективы DevOps и к чему готовиться инженерам в светлом и близком будущем с упрощением и нейросетями.

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



Здесь и далее вопросы задает Виталий Хабаров инженер из Express42.

Размышления о том, откуда берется желание сдать сертификацию AWS Solutions Architect Associate.

Мотив первый: «Топоры»

Один из самых полезных для любого профессионала принципов «Знай свои инструменты» (или в одной из вариаций «точи пилу»).

Мы в облаках уже давно, но до поры до времени это были просто монолитные приложения с базами, развернутые на инстансах EC2 — дёшево и сердито.

Но постепенно нам стало тесно в рамках монолита. Взяли курс на распил в хорошем смысле – на модуляризацию, а затем и модные нынче микросервисы. И очень быстро на этой почве «расцветают сто цветов».

Да что там далеко ходить – проект логирования активности, который я сейчас веду, включает в себя:

• Клиентов в виде разнообразных приложений нашего продукта – от глухих уголков дремучего легаси до ультрамодных микросервисов на .Net Core.
• Очереди Amazon SQS, в которые складываются логи о том, что происходит с клиентами.
• Микросервис на .Net Core, который достает сообщения из очереди и отправляет их в Amazon Kinesis Data Streams (KDS). Имеет также Web API интерфейс и swagger UI как дублирующий канал и для ручного тестирования. Оборачивается в докеровский linux-контейнер и хостится под управлением Amazon ECS. Предусмотрен autoscaling на случай большого потока логов.
• Из KDS данные пожарными шлангами направляются в Amazon Redshift с промежуточными складами в Amazon S3.
• Операционные логи для девелоперов (дебаг-информация, сообщения об ошибках и т.п.) форматируются в приятный глазу JSON и отправляются в Amazon CloudWatch Logs

Работая с таким зоопарком сервисов AWS, хочется знать, что есть в арсенале и как это что-то лучше использовать.

Kubernetes Dashboard — простой в работе инструмент для получения актуальных сведений о работающем кластере и минимального управления им. Начинаешь его ценить ещё больше, когда доступ к этим возможностям нужен не только администраторам/DevOps-инженерам, но и тем, кто меньше привык к консоли и/или не намерен разбираться со всеми тонкостями взаимодействия с kubectl и другими утилитами. Так случилось и у нас: разработчикам захотелось быстрого доступа к веб-интерфейсу Kubernetes, а поскольку мы используем GitLab, решение напросилось само собой.

Введение

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

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

Уже больше 10 лет существуют и появляются разного рода профессиональные системы для подбора персонала. Это естественно. Специализированный софт уже разработан для многих отдельных профессий. Что касается рекрутинга, все понимают какие задачи помогает решить софт, от какой рутины и ошибок избавляет, но никто не понимает как измерить экономический эффект от его использования. Другими словами, компании могут посчитать сколько денег им обойдётся использование софта, но не понимают ROI или сколько денег принесёт или сэкономит софт. Слоганы типа “Закрывайте вакансии в 2 раза быстрее с (таким-то софтом)” — это от фонаря, это просто неправда.

Непонимание что даёт софт для рекрутинга в деньгах приводит к тому, что компании откладывают эту инвестицию на годы и за это время много теряют в результатах.

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

Наша компания с 2008 года занимается преимущественно управлением инфраструктурами и круглосуточной технической поддержкой веб-проектов: у нас более 400 клиентов, это порядка 15% электронной коммерции России. Соответственно, на поддержке очень разнообразная архитектура. Если что-то падает, мы обязаны в течение 15 минут это починить. Но чтобы понять, что авария произошла, нужно мониторить проект и реагировать на инциденты. А как это делать?

Я считаю, что в организации правильной системы мониторинга происходит беда. Если бы беды не было, то мой спич состоял из одного тезиса: «Установите, пожалуйста, Prometheus + Grafana и плагины 1, 2, 3». К сожалению, теперь так не работает. И главная проблема заключается в том, что все продолжают верить во что-то такое, что существовало в 2008 году, с точки зрения программных компонентов.

В отношении организации системы мониторинга я рискну сказать, что… проектов с грамотным мониторингом не существует. И ситуация настолько плохая, если что-то упадёт, есть риск, что это останется незамеченным — все ведь уверены, что «всё мониторится».
Возможно, всё мониторится. Но как?

Все мы сталкивались с историей наподобие следующей: работает некий девопс, некий админ, к ним приходит команда разработчиков и говорит — «мы зарелизились, теперь замониторь». Что замониторь? Как это работает?

Ок. Мониторим по старинке. А оно уже изменяется, и выясняется, что ты мониторил сервис А, который стал сервисом B, который взаимодействует с сервисом C. Но команда разработчиков тебе говорит: «Поставь софт, он же должен все замониторить!»

Так что изменилось? — Всё изменилось!