За что мы любим Prometheus? У него есть конфиг — взглянул и всё понятно, программа делает то, что ей сказали. Можно автоматизировать настройку мониторинга, хранить в VCS, ревьюить командой. Смержили твой MR, отработал пайплайн, новый конфиг применился к прометею. В общем, IaC во всей красе.

Кстати, о прометее. А вы используете его для своей железной инфраструктуры? Вот и мы не используем.

Как и многие, кто мониторит давно и у кого есть «голое» железо, мы используем Zabbix, который, кстати, на том железе и располагается. Увы, на данный момент заббикс и IaC — вещи не связанные. Настраивать заббикс можно или вручную, или через API.

Когда говорят об MDM, который Mobile Device Management, все почему-то сразу представляют kill-switch, который дистанционно подрывает утерянный телефон по команде сотрудника ИБ. Нет, в целом это тоже есть, только без пиротехнических эффектов. Но есть ещё куча других рутинных задач, которые с MDM выполняются намного проще и безболезненнее.

Бизнес стремится к оптимизации и унификации процессов. И если раньше новому сотруднику приходилось идти в таинственный подвал с проводами и лампочками, где мудрые красноглазые старцы помогали настроить корпоративную почту на его Blackberry, то теперь MDM вырос до целой экосистемы, которая позволяет выполнять эти задачи в два клика. Будем говорить о безопасности, огуречно-смородиновой «Кока-Коле» и отличиях MDM от MAM, EMM и UEM. А ещё — о том, как удалённо наняться на работу по продаже пирожков.

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

_{Источник изображения:}

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

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

Автоматическая, защищенная, распределенная, с транзистивными связями (т.е. пересылкой сообщений, когда нет прямого доступа между абонентами), без единой точки отказа, равноправная, проверенная временем, с низким потреблением ресурсов, full-mesh VPN сеть c возможностью "пробивки" NAT — это возможно?

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

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

Немного теории и решения интересных и не очень практических задач — под катом.

С каждым годом всё больше компаний в том или ином виде внедряют у себя концепцию BYOD. По данным исследования Global Market Insights к 2022 году объём рынок BYOD превысит 366 млрд долларов, а Cisco сообщает, что 95% организаций в том или ином виде допускает использование личных устройств на рабочих местах, причём такой подход позволяет экономить 350 долларов в год в расчёте на сотрудника. Одновременно BYOD создаёт множество сложностей для ИТ-службы и массу разнообразных рисков для компании.

Возможность выполнять рабочие задачи с помощью собственных гаджетов многие воспринимают как элемент свободы, прогрессивного подхода к взаимоотношениям компания-сотрудник и вообще типичный пример стратегии win-win. В целом нет никаких причин сомневаться: сотрудник с удовольствием использует для решения задач оборудование, которое выбрал сам, а компания получает сотрудника, который всегда на связи и выполняет работу даже в нерабочее время. По данным Frost & Sullivan, BYOD добавляет к рабочему времени сотрудников до 58 минут в день и увеличивает продуктивность на 34%.

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

Отечественное решение видеоконференцсвязи (ВКС) Mind Server давно пользуется популярностью в России и не только. Это профессиональная система для проведения конференций и вебинаров в локальной сети или через открытый интернет. В Mind Server обеспечена поддержка аппаратных терминалов SIP/H.323, WebRTC-подключений и мобильных клиентов, а также реализована запись конференций, демонстрация контента и рабочего стола, интеграция со Skype for Business и многое другое.

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

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

Краткое содержание статьи:

• 10 Ключевых изменений в новой версии Mind Server
• Установка и базовая настройка
• Интерфейсы администратора и пользователя
• Цена решения
• MCU Mind «из коробки»
• Дистрибутив и безлимитный ключик на 1 месяц в подарок

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

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

Очевидные причины

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

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

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

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

Трудно усомниться в очевидном. Солнце вращается вокруг Земли — не нужны доказательства тому, что видно невооруженным взглядом, не так ли? Не так.

В компании «Макснет Системы» в качестве гипервизора долгое время использовалась бесплатная версия VMware — ESXi, начиная с версии 5.0. Платная версия vSphere отпугивала моделью лицензирования, а у бесплатной был ряд недостатков, которые отсутствовали в платной, но с ними можно было смириться. Но когда в новых версиях ESXi новый веб-интерфейс отказался работать со старым, а мониторинг RAID-массивов перестал подавать признаки жизни, компания решила искать более универсальное и открытое решение. В компании уже был неплохой опыт и приятное впечатление от LXC — Linux Containers. Поэтому стало очевидно, что гипервизор мечты будет гибридным и сочетать для разных нагрузок KVM и LXD — эволюционное продолжение LXC. В поисках информации относительно KVM, компания сталкивалась с заблуждениями, граблями и вредными практиками, но тесты и время расставили все по местам.



О том, как справиться с переездом с ESXi на KVM и не проколоть колеса на граблях, расскажет Лев Николаев (maniaque) — администратор и разработчик высоконагруженных систем, тренер по информационным технологиям. Поговорим о Сети, хранилищах, контейнерах, KVM, LXD, LXC, provisioning и удобных виртуалках.

Привет, Хабр! Продолжаем разговор о механиках геймификации. Прошлая статья рассказывала о рейтинге, а в этой поговорим о древе навыков (технологическом древе, 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 ближе к людям, мы разработали простой конструктор, о котором расскажем подробнее в этом посте.