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

It-инфраструктура

Активное внедрение стандарта Интернета RPKI полезно ли?

26.12.2020 10:13:54 | Автор: admin

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

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

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

Суть здесь вот в чём. Внедряемый стандарт подписей рассылок интернет-адресов основывается на иерархической системе сертификатов. То есть это почти та же система, только с дополнениями в виде номеров сетей и анонсов ip-адресов. Данный стандарт предполагает, что ведущие держатели мировых сетевых мощностей будут доверять только анонсам сетевых маршрутов от их непосредственных исполнителей, т.е. тех, кто эти маршруты будет собственно осуществлять, либо их непосредственных начальников. Неформально если - теперь сложно будет ходить "налево".

Проблема вот в чем. Мы, получается, переходим к иерархической схеме управления, к древовидной. И сам протокол, и принципы, на которых он основан, суть древовидные структуры. А это идёт в разрез с философией Интернета, который создавался и, тьфу-тьфу, функционирует в распределённом режиме. Интернет -это структура произвольного графа (за исключением некоторых сервисов типа DNS, уже названной системы сертификатов PKI и той же раздачи адресов), без ориентированности на строгую иерархию, без единственной головы.

Голов у Интернета в этом смысле много - если считать ими точки концентрации трафика. Теперь давайте разберёмся, что же это за "головы" мирового Интернета. Это в первую очередь телеком операторы т.н. бэкбона интернета - самых скоростных и широкополосных каналов связи. (Их принято называть операторами Tier 1, т.е. первого высшего уровня. Эти операторы никому не платят за интернет, поскольку они и являются его основой. К ним подключаются средние операторы Tier 2 и т.д.).

Связность в европе и окрестностяхСвязность в европе и окрестностях

Также в группу голов можно смело заносить крупных поставщиков контента, типа Netflix, Amazon, Vkontakte и Google. А также их крупнейших посредников - точки обмена трафиком, или пиринг-центры, представляющие из себя ассоциации разных интернет- и контент-провайдеров разного уровня. Именно во многом благодаря их существованию Интернет более-менее распределён, а значит устойчив к сбоям и, что немаловажно, к монополиям.

Во многом за счёт последних скорости интернета выше, а цены ниже. Именно они вносят значительный вклад в представление Сети как графовой распределённой структуры, у которой нет основных 3-4 владельцев, в основном американских (хотя надо отдать должное, скандинавская Telia Sonera на первом месте сейчас). Так вот, внедряемый стандарт основан на иерархии подписей маршрутов, аналогично иерархии подписей сертификатов сайтов.

Основа протоколаОснова протокола

И выдача маршрутов (как мне сейчас представляется) соотносится с современным положением вещей примерно так же как сама нынешняя система сертификатов PKI соотносится с распределёнными системами типа блокчейна. Ну или другая аналогия, политическая - как однополярный мир соотносится с многополярным. Программистская аналогия - как централизованный и распределённый контроли версий ПО. Финансовая: как Бреттон-Вудская, ныне Ямайская, система (золотодолларовый стандарт) соотносится с золотым стандартом начала 20-го века.

Вернёмся к Интернету.

Дерево связей протокола RPKIДерево связей протокола RPKI

По принятому протоколу доверие маршрутам обеспечивается только согласно иерархическим лицензиям, выданным от основных их владельцев - крупнейших телекомов бэкбона Интернета. То бишь из тех "голов", что я перечислял, влияние перетекает только к первой немногочисленной группе "владельцев" интернета. А различные региональные игроки остаются в стороне. Существующие ассоциации (пиринговые центры) наподобие российских MSK-IX или DATAIX, пока что довольно влиятельные, потеряют возможность обмениваться трафиком, так как их участники не смогут обмениваться маршрутами, нарушая границы своих иерархий, то есть обмен налево будет затруднён. А это и был основной смысл существования этих точек обмена. В результате контроль над трафиком уйдёт к крупнейшим телекомам. Российские телекомы не глобальны и впадут в зависимость от западных. Точки обмена трафиком просто распадутся. Установится монополия (или если хотите олигополия) в сфере коммуникаций, маршруты будут прокидываться через головы, они станут длиннее, а значит связь будет во многих случаях медленнее. Ну и конечно вырастут цены. За большую цену вы получите худшую связь.

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


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

Удачного всем дня!

Подробнее..

Отличие сервисов аналитики маркетплейсов, подробный анализ

27.12.2020 02:13:31 | Автор: admin

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

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

Я зарегистрировался в 4 таких сервисах и решил провести обзор с описанием своих ощущений.

1. Moneyplace.io - сервис одновременной аналитики Wildberries, Ozon и AliExpress

Анализ продаж маркетплейсов Wildberries, Ozon и AliExpressMoneyplace.io

Первый сервис для аналитики продаж на маркетплейсах - Moneyplace.io. По числу маркетплейсов - он лидирует, кроме популярных Wildberries и Ozon, они анализируют еще и AliExpress, что является большим преимуществом, ведь этот маркетплейс активно выходит на рынок России и уже в 2021 году обещают поставить100 000 постаматовв крупных городах. По всей видимости в России вскоре появится новый лидер в этой сфере.

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

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

Анализ продаж маркетплейсов Wildberries, Ozon и AliExpressMoneyplace.io

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

В примере ниже, например, сразу видно, чтоКрем-спрейпродался за 7 дней на3,6 млн. руб.аПодгузникина2,7 млн. руб.Понравилось, что эти данные видны еще до захода в карточку анализа товара.

Анализ продаж товарах на маркетплейсахMoneyplace.io

В таком же виде можно оценить объем продаж каждой категории и подкатегории на всех маркетплейсах.

Анализ продаж категорий маркетплейсовMoneyplace.io

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

Анализ продавцов на маркетплейсахMoneyplace.io

Выведены для анализа все товары, которые есть у продавца - это полезно с точки зрения конкурентной разведки.

Анализ товаров у продавцов на маркетплейсахMoneyplace.io

Тарифы на сервис варьируются от3 990 рубв месяц до19 900, что на текущий момент в соотношении функционал/цена является самым выгодным вариантом. Так как уже на тарифе Голд вы получаете доступ к анализу сразу 3 маркетплейсов, что позволяет определять тренды на любом маркетплейсе и заводить их на тот маркетплейс, где вы занимаетесь продажами.

Тарифы на сервисы аналитики маркетплейсовMoneyplace.io

Сайт:Moneyplace.io

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

2. mpstats.io - сервис аналитики wildberries и ozon

Данный сервис занимается аналитикой двух маркетплейсов wildberries и ozon

Анализ продаж на маркетплейсахmpstats.io

В сервис вам необходимо загрузить API своего магазина Ozon или WildBerries и он выведет статистику по продажам и состоянию склада в графическом и табличном виде.

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

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

У сервиса есть поиск по Валдберрис, но отсутствует поиск по Озон, чтобы найти какой - либо товар, нужно сначала найти категорию и уже в ней вручную искать интересующий товар.

Аналитика категорий на маркетплейсахmpstats.io

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

Анализ товаров на маркетплейсахmpstats.io

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

Глубокий анализ товаров на маркетплейсахmpstats.io

Расценки сервиса варьируются от4 800до28 000 рублейв зависимости от того, сколько маркетплейсов вы хотите анализировать только валберис или вместе с озон.

Тарифы на сервисы аналитики маркетплейсовmpstats.io

Сайт:mpstats.io

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

3. EggHeads Solutions - сервис аналитики валдберрис

Увеличение продаж на WildberriesEggHeads Solutions

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

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

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

Сайт:eggheads.solutions

4. Pi-Data - сервисы для оптимизации продаж на Wildberries и Ozon

Оптимизация продаж наWildberries и OzonPi-Data

Очень крутой сервис для профессионалов. Такое количество аналитической информации я не встретил ни у кого на рынке. Тут и PnL анализ и АВС и география продаж, и десятки или даже сотни графиков в разных разрезах информации.

Графический анализ продаж на маркетплейсахWildberries и OzonPi-Data

ABC анализ продаж на маркетплейсах Wildberries и OzonPi-Data

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

Контроль поставок на маркетплейсахWildberries и OzonPi-Data

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

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

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

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

Тарифы на сервисы аналитики маркетплейсовPi-Data

Тарифы начинаются от2 999 рубна начальном тарифе до18 999 руб в месяцна профессиональном.

Сайт:Pi-Data.ru

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

В заключение:

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

Чтобы спрогнозировать и увеличить свои продажи, на мой взгляд очень перспективно пользоваться аналитическими сервисами, описанными выше. Благодаря им бизнес становится прозрачным, еще до вложения денег, вы можете на 99% знать, какими будут ваши продажи. Вы можете увидеть тренд (новинки товаров) и быть в самом его зарождении.

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

Подробнее..

Внедрение CICD и DevOps в Enterprise (Ростелеком) часть 3

27.12.2020 16:14:22 | Автор: admin

Всем привет! Это третья, завершающая, часть нашего рассказа о том, как Ростелеком ИТ внедряет CI/CD & DevOps в энтерпрайзовый ИТ-ландшафт и тяжелые монолитные Legacy-системы. Первую часть про внедрение CI/CD в десятки проектных команд очень большой компании можно прочитать на Хабре по ссылке здесь. Вторую часть сугубо инженерную, с описанием прикладных подходов, инструментов и реализаций читайте тут.

Сегодня мы расскажем про процесс внедрения в рамках Karma Framework в круге. Поехали!

Круг DevOps катаем квадратное, таскаем круглое

Фреймворк сетапа команд и дальнейшей работы по внедрению CI/CD & DevOps в проектные команды Ростелеком ИТ

Круг DevOps существует в модели управления Karma Framework Ростелекома. Под кругом мы понимаем объединение специалистов вне иерархии, которые взаимодействуют в формате экспертное сообщество. Родительским для нашего круга является круг Развитие цифровых технологий. Поэтому мы работаем с заказчиками в двух операционных моделях:

  • Партнерская модель (ИТ владеет бизнес-экспертизой и разделяет цели продукта, ИТ самостоятельно планирует развитие исходя из бизнес-задач);

  • Модель Драйвер (ИТ выступает инициатором и драйвером создания высокотехнологичных решений).

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

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

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

  • Лидер круга драйвит тему и организует регулярные встречи в формате онлайн;

  • Фасилитатор и секретарь круга помогают держать встречи в заданной повестке, фиксировать договоренности и планируемые активности;

  • Эксперты круга помогают командам с обсуждением архитектурных вопросов;

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

Существует два типа этой роли: Делегат-тимлид/Руководитель проектов (РП) и Делегат-DevOps-специалист. Делегат-тимлид/РП отвечает за внедрение процессов в команде и имеет полномочия на такие изменения как, например, выделение ресурсов на реализацию Continuous Delivery (CI) или изменение архитектуры решения. Делегат-DevOps-специалист наиболее погружен в технические аспекты и напрямую работает с инструментами.

  • Наблюдатели приходят в Круг посмотреть и поинтересоваться. В формировании повестки встреч не участвуют, обязательства не принимают;

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

Инструменты совместной работы круга

  1. Выделенное пространство в корпоративной базе знаний (например, Confluence.

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

  2. Оперативный чат в мессенджере (у нас Телеграм)

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

  3. Встречи в формате онлайн-конференции

    Сейчас у нас Zoom, но мы планируем переехать в корпоративный TrueConf. Выделены 4 типа встреч:

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

    • Техническое обсуждение/обмен опытом (по запросу) - проводятся заинтересованным кругом участников для решения конкретного технического вопроса или презентации какого-либо технического решения;

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

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

  4. Таблица (матрица) соответствия проектов основным стандартам CI/CD опросник, который заполняют команды

    Он позволяет оценить организационную и технологическую зрелость самого процесса разработки по основным направлениям и областям применения того или иного инструментария. Опросник проясняет:

    • Как именно происходит управление задачами и релизами;

    • Как организован обмен знаниями и документирование;

    • Какие инструменты CI/CD применяются;

    • Как контролируется качество кода;

    • Как мониторятся стенды и собираются метрики.

    • карта развития процессов разработки для каждой из команд.

    Каждый пункт опросника имеет вес 1 или 0 (иногда промежуточные 0.5), проект оценивается в баллах по сумме заполненных строк. Таким образом формируется общая оценка зрелости проекта. На основании таблицы формируется дорожная карта развития процессов разработки для каждой из команд.

Обязательства и продукция круга DevOps включают:

  • Формирование и встраивание фреймворка внедрения CI/CD в связке с Agile-фреймворками команд (проектов);

  • Создание, накопление, поддержание лучших практик, технологий, инструментов в области DevOps;

  • Методологическая поддержка проектов и команд в части DevOps и CI/CD;

  • Содействие обмену знаниями в командах;

  • Содействие повышению качества продуктов и сервисов;

  • Содействие повышению скорости поставки продуктов и сервисов;

  • Содействие в оптимизации процессов эксплуатации продуктов и сервисов.

Фреймворк CI/CD мы планируем привносить в команды, которые в рамках общей digital-трансформации переходят на гибкие методики. Как мы уже отмечали, мы не мыслим Agile без современных технологических инструментов управления разработкой и здесь CI/CD является основной конвейера. Но в кровавом энтерпрайзе, где многим legacy-проектам и решениям от 5 до 10 лет, а некоторым и больше, такие переходы даются не сразу и не так легко.

Общая тенденция такова команды сетапятся в Канбан (или SCRUM), в чем нам помогает очень крутой корпоративный тренер, а в качестве Sidecar к гибкой методологии мы проводим аудит состояния DevOps и CI/CD, даем команде рекомендации, делаем совместную дорожную карту и детальные планы изменений в соответствии реальными возможностями команды и архитектурой информационной системы проекта.

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

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

Конечно, DevOps не заканчивается там, где заканчивается Kanban доска. Команды вовлечены как в процесс релиза, так и в процесс эксплуатации продукта.

Фреймворк, разрабатываемый кругом позволяет на всех этапах технологического цикла выстроить эффективные процессы в команде, а также дает необходимые инструменты на каждом шаге. На рисунке ниже отображено соответствие этапов Kanban процесса, DevOps-практик и инструментов CI/CD.

После вступления в круг DevOps и определения текущего уровня зрелости DevOps процессов команда формирует план своего развития, выделяя три блока задач:

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

  2. Что можно сделать в разумный срок, за разумный бюджет (внесение небольших архитектурных изменений или новых практик и методик, приносящих ощутимый эффект) - в рамках имеющегося согласованного бюджета проекта. Примеры: внедрить логирование в Elastic Stack или Graylog, обеспечить покрытие всего кода Unit-тестами на определенный процент, внедрить регистрацию и сбор ошибок с продуктивной среды (например, с помощью Sentry), обеспечить автоматизацию UI-тестирования и т.п.

  3. Что требует дополнительного согласования бюджета из-за значительных изменений в коде или архитектуре решения. Согласование изменений с бизнесом, исходя из прогнозируемой выгоды и улучшений: ускорение цикла разработки, повышение качества, снижение затрат (стоимости владения). Примеры: переход на микросервисную и Cloud Native архитектуру, контейнеризация приложений и размещение в OpenShift-кластере, внедрение инструментария управления версионностью БД (LiquiBase), и т.п.

Новая команда, которая проходит сетап любого из Agile-фреймворков, получает в комплекте фреймворк запуска CI/CD. Команда выбирает из своего числа делегата, который вступает в круг DevOps.

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

На следующем этапе делегат заполняет матрицу соответствия своего проекта стандартам CI/CD, в которую входят показатели уровня текущих процессов и инструментов, используемых в команде. Мы получаем более-менее объективную оценку текущего уровня развития DevOps в команде, выраженную в баллах.

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

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

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

Условия работы в круге

Принципиальными моментами в работе круга DevOps является следующее:

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

  • Задача круга как экспертного сообщества заработать репутацию (карму) таким образом, чтобы командам было интересно туда приходить. Примеры экспертных кругов с репутацией в Ростелекоме есть это Круг аналитиков или Круг тестировщиков. Круг DevOps еще совсем молодой, мы только начинаем формировать и сообщество, и репутацию и хотим, чтобы у нас было интересно и работа приносила реальную пользу проектам;

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

  • У круга нет формальных KPI. Его эффективность измеряется кармой. Карма это прежде всего оценка удовлетворенности работы кругом DevOps со стороны родительского круга Развитие цифровых технологий. Выполняем ли мы свое предназначение? Какой фидбек от бизнеса и команд? Не занимаемся ли ненужной фигней, которая никому не понятна и не приносит пользы?

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

Резюме

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

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

  • UAT-тестирование на тяжелых проектах сокращается в среднем с 5 рабочих дней до 2-3 за счет внедрения автотестов (в масштабе 2-3-недельной итерации).

  • Подготовка релиза в среднем сокращается с 4-5 дней до 1-2 за итерацию.

  • Интеграционное тестирование производится на реальных связях со смежными системами, а не на заглушках, для чего обеспечивается связность с тестовыми и Release Candidate-стендами всех окружающих систем. Это существенно снижает количество сюрпризов на продуктиве.

  • На многих проектах вывод в продуктивную среду сокращается с 3-4 часов до десятков минут, делается автоматически и производится днем, что еще несколько лет назад для Ростелекома было просто немыслимым.

  • Регрессионное тестирование в среднем сокращается с 3-5 дней до 1-2 за итерацию, а количество ошибок и хотфиксов за счет автоматизации цикла сводится к минимуму.

  • Экономия по всему технологическому циклу может достигать 5 рабочих дней всей команды; на месячном релизном цикле это дает +25% производительности команды.

  • Не надо бояться разговаривать об изменениях практики разработки с бизнесом и смежными ИТ-службами.

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

Подробнее..

Перевод Retro Apple цифровая камера Quicktake100

27.12.2020 20:07:49 | Автор: admin
В 1994 году фотография была довольно трудоемким делом. Для начала необходимо было вставить пленку в катушку, либо картридж в камеру, потом только сделать фотографию и только догадываться как получился снимок. Что бы увидеть картинку нужно было достать пленку с фотоаппарата и либо просветить ее самостоятельно в темной комнате, либо отнести в специализированное место.

Компания Apple помогла цифровым камерам становится более популярными с 1994 года, и на картинке ниже мы можем увидеть то, что считается первым цифровым фотоаппаратом для массового использования: Apple QuickTake 100.

QuickTake 100 не была первой камерой для массового использования вышедшей на рынок; Fuji DS-X продавалась в Японии с конца 1989 года, в то время как Dycam Model 1 (продававшаяся как Logitech Fotoman) лежала на полках в магазинах США еще в ноябре 1990 года. Но QuickTake 100 была доступна в версиях как для Mac, так и для Windows и имела преимущество, что продавалась известной компанией.

image
QuickTake 100 ( слева) и iPhone 11 Max (справа)

Стоимость и факты


20 Июня, 1994 года QuickTake 100 была представлена на продажу, первоначальная цена была $749, что равносильно $1300 в 2020.

В то время технические характеристики камеры были революционными. Она имела максимальное разрешение 640 x 480 пикселей с 24-разрядной цветопередачей. На 1 МБ встроенной Flash-памяти c таким разрешением в камере могло хранится всего 8 фотографий. При более низком разрешении 320 x 240 пикселей можно было хранить 32 снимка.

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

У QuickTake 100 был объектив с фиксированным фокусом, что давало ему угол обзора, равносильно 50-миллиметровому объективу на 35-миллиметровой камере. Не было ни зума, ни фокуса, но тем, кто хотел делать фотографии при плохом освещении повезло была встроенная вспышка.

Экспозиция выставлялась камерой. При низкой светочувствительности, эквивалентной ISO 85, выдержка составляла от 1/30 до 1/175 секунды, а диафрагма от f / 2,8 до f / 16. Вот пример фотографии в режиме высокого разрешения 640 x 480.

image
Гмхофманн 14:49 (CEST), 7 июня 2007 г.

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

image
Задняя сторона QuickTake 100 с дисплеем управления справа. Кнопка корзины находится в углублении в правом нижнем углу

Просмотр и хранение


Для просмотра фотографий пользователи подключили камеру к компьютеру Mac или Windows с помощью кабеля. Программа Apple QuickTake импортировала фотографии с камеры на компьютер и разрешила основное редактирование вращение, изменение размера и обрезку. Файлы хранились в фирменном формате QuickTake и могли быть экспортированы как PICT-файлы.

Следущая модель после 100 QuickTake 150 появился примерно 15 месяцев спустя, у новой модели использовали улучшенную технологию сжатия файлов для хранения до 16 самых качественных изображений. Цена QuickTake 150 была около 700 долларов и выглядела идентично своей предшественнице, но предлагала вдвое больше памяти и поддержку большего количества форматов изображений (даже PCX, для тех, кто ее помнит). Он включал в себя объектив для макросъемки, а также поддерживал ПК с Windows. Компания так же не оставили владельцев QT 100 в стороне, Apple выпустила обновление прошивки, которое по сути преобразовало его в QT 150.

В 1996 году Компания Apple выпустила QuickTake 200 со съемной 2-мегабайтной SmartMedia флэш-картой. QuickTake 200 стала больше похожей на настоящую цифровую камеру и даже появились 1,8-дюймовый цветной LCD-экранчик на задней панели для предварительного просмотра фотографий. Стоимость QuickTake 200 стала ниже ($600), но это снова ей не помогло, так как на рынке цифровых камер появлялось все больше продукции от конкурентов, Fujifilm, Nikon, Canon и Kodak.

image
QuickTake 200

image
Питание осуществлялось от трех батареек AA которых хватило ненадолго, даже если вы не использовали вспышку

В 1997-м когда на пост главы Apple был возвращен Стив Джобс, историю QuickTake закончилась.
Так, как на разработку с нуля у компании не было средств и камеры у конкурентов были лучше.

Личные воспоминания о QuickTake 100


Мой первый опыт использования QuickTake 100 был на конференции разработчиков Apple Worldwide Developers Conference в 1994 году. Камера была представлена в Токио на выставке MacWorld в феврале того же года, и во всех журналах Mac того времени она была на обложках. Так как камера не была выпущена для широкой публики в мае в мае, когда проходила Всемирная конференция разработчиков, я был в восторге, увидев её.

Apple и один из журналов того времени (я думаю, это был MacWorld) установили стенд, где они могли сфотографировать вас с помощью QuickTake 100, а затем сделать макет индивидуальной обложки журнала. Отличная идея, но реально это было ужасно. Загрузка изображений с камеры на компьютер Mac по (GeoPort) кабелю была ужасно медленной, поэтому 32 снимка 320 x 240 на компьютер Mac занимало много времени. Затем сотруднику Apple пришлось создавать обложку журнала и распечатывать её на QMS ColorScript Laser 1000 что также было довольно медленно. Думаю будет излишне говорить, что лишь относительно немногие из участников WWDC действительно получили одну из имитационных обложек журналов (мне повезло, что я был одним из первых в очереди).

image
Сдвижная дверца закрывает разъем внешнего питания и разъем для кабеля GeoPort

Я не покупал QuickTake 100, но через много лет камеру мне подарил племянник. Он учился в Массачусетском технологическом институте в качестве аспиранта около десяти лет назад, и ему дали доступ в комнату, полную старого оборудования, которое собирались выбросить. Одним из предметов под утилизацию была камера QuickTake 100, поэтому я попросил прислать мне.
Камера все еще работает, но есть одна проблема невозможно снять с нее фотографии. Полагаю, что я должен найти Mac середины 1990-х годов под управлением System 7 или System 8, найти серийный кабель Apple и программное обеспечение QuickTake, и дать ему ход

Текущие компьютеры Mac не поддерживают старый протокол Apple, и я уверен, что эмулятор Macintosh.js не сможет разговаривать с USB-разъемом.

image
Нижняя часть QuickTake 100 с этикеткой продукта и отверстием для крепления штатива

Есть еще одно приложение для Mac, которое может читать файлы формата PICT, созданные QuickTake 100. GraphicConverter от Lemkesoft существует уже давно и может конвертировать практически любой графический формат в другой.

Хотя в настоящее время это не более чем музейный экспонат, мне все же нравится гладкий дизайн QuickTake 100. Его легко держать двумя руками, а серый внешний вид был похож на Apple PowerBook того времени.

Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Maincubes Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Проблемой широкополосного доступа в сеть займется новая компания США выделят ей 900 млн

27.12.2020 20:07:49 | Автор: admin

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

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

Обсудим, что предлагает SpaceX и как команда Starlink подключилась к решению проблемы.

Unsplash / Forest KatschUnsplash / Forest Katsch

Интернет в деревню

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

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

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

Этим летом Федеральная комиссия по связи США (Federal Communications Commission, FCC) утвердила правила участия в широкомасштабной программе субсидий, составивших в общей сложности шестнадцать миллиардов долларов. Претендовать на свою долю от этой суммы смогли сотни телеком-компаний, желающие обеспечить жителей малочисленных районов высокоскоростными линиями. Однако еще на подготовительном этапе представители комиссии заявили, что спутниковая интернет-связь скорее всего не будет включена в программу.

Что там со SpaceX

Компании удалось опротестовать подход FCC, исключающий для нее возможность участия в программе субсидий. В пояснительной записке представители SpaceX подчеркнули, что главное высокое и стабильное качество услуг, а не способ их доставки потребителю. Комиссия пошла навстречу компании, допустила ее к конкурсу, а по его итогам выделила $885,5 млн.

Еще $8,3 млрд из первой части общего пакета поддержки FCC распределили среди 180 провайдеров. Кстати, некоторые из них выразили сомнения относительно возможностей Starlink, сославшись на потенциальные обрывы связи и сложности с поддержанием соединения, если компания не сможет ввести в строй достаточно число спутников. В качестве своеобразного ответа в начале ноября руководство SpaceX отчиталось об успешном бета-тесте сервиса.


Что еще у нас есть на Хабре:


Пока достаточно сложно сказать, для какой части из нескольких десятков миллионов граждан, сталкивающихся с нехваткой широкополосного доступа в сеть, Starlink сможет предложить достойную альтернативу. Ряд скептиков полагают, что процесс доставки спутниковой интернет-связи в американскую деревню может несколько замедлить необходимость покупки и установки дополнительного оборудования для приема и обработки сигнала. По данным CNBC, стоимость комплекта может составить до $500, а ежемесячные платежи окажутся на уровне $99, что вполне укладывается в верхнюю границу цен на соответствующие услуги в США.

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

Сложности остаются

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

Unsplash / Compare FibreUnsplash / Compare Fibre

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


Что еще почитать у нас в блоге:


Подробнее..

Больше хот-спотов, пожалуйста обсуждаем очередную грандиозную инициативу в Индии

28.12.2020 04:16:31 | Автор: admin

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

Unsplash / Ashish SangaiUnsplash / Ashish Sangai

Контекст вопроса

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

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

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

Что на этот раз

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

Unsplash / Raj RanaUnsplash / Raj Rana

Тогда практически в каждом городе Индии установили будки и открыли специальные центры для тех, кто хотел бы осуществить звонок. Как раз эти локации министерство по информационным технологиям и планирует переоборудовать в так называемые дата-офисы (Public Data Office, PDO). Там будет развернут PM WANI (Prime Minister Wi-Fi Access Network Interface) и другая инфраструктура, в том числе с учетом летнего плана по развитию линий оптоволоконной связи.

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

Минутка критики

Далеко не все согласны с тем, что по-настоящему грандиозное начинание правительства можно называть своевременным. Есть мнение, что делать что-то подобное нужно было еще семь или восемь лет назад. Теперь большую часть задач, которые отводят для PM WANI, решает мобильный интернет. В Индии можно с легкостью найти истории успеха в этой нише например, кейс телекома Jio Platforms, который стал крупнейшим в стране всего за четыре года за счет доступных тарифов. В ноябре правительство дало зеленый свет Google, которая еще летом заявила о намерениях инвестировать 4,5 млрд долларов в акции именно этого провайдера.

Интересно, что в феврале корпорация закрыла Google Station программу, в рамках которой четыре сотни железнодорожных станций и множество общественных мест были оборудованы точками бесплатного доступа к Wi-Fi. Со ссылкой на рост доступности мобильной интернет-связи, хот-споты выключили 30 сентября практически ровно за месяц до аппрува инвестиций в Jio Platforms. Можно ли считать данный случай удачным совпадением или выходом на новый уровень сотрудничества, покажет время.

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

Unsplash / Paul HanaokaUnsplash / Paul Hanaoka

Один только RailTel сегодня обслуживает более 5,5 тысяч железнодорожных станций и продолжает разворачивать бесплатный Wi-Fi на собственном технологическом стэке в новых локациях. Кстати, те самые 400 с лишним точек, которые покинул Google, эти компании обеспечивали хот-спотами вместе. Однако теперь RailTel берет всю нагрузку на себя.

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


Что еще почитать у нас в блоге:


Подробнее..

Увидеть всё. Как и зачем мы создаём цифрового двойника посылки

29.12.2020 16:19:06 | Автор: admin

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

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

Зачем нужен цифровой двойник

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

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

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

  • получать точную информацию о производительности системы;

  • прогнозировать будущее состояние с помощью моделей предиктивной аналитики;

  • управлять объектами и процессами удалённо в режиме онлайн.

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

Как формируется цифровой двойник посылки

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

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

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

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

Service Blueprint первый этап создания двойника

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

Часть процессов уже происходит онлайн, а какие-то пока не оставляют за собой цифрового следа. А ведь чем больше информации мы будем получать о посылке, тем лучше сможем влиять на эффективность. Чтобы свести картину путешествия посылки воедино, мы используем Карту сервиса (Service Blueprint) схематическое изображение всего, что происходит на пути посылки. Карта включает в себя как путь клиента, так и всё закулисье сервиса. Service Blueprint первый этап в создании цифрового пути посылки. Для одной части процессов мы прорисовываем CJM (customer journey map путь клиента), для другой верхнеуровневые схемы взаимодействия процессов и систем.

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

Чтобы решить проблему пользователя или существующего процесса, надо понять, откуда она взялась. Для этого мы составляем Job story описание сценариев возникновения проблем и действий. Это особым образом структурированные гипотезы. Например: Я пришёл в отделение и мне нужно занять очередь, но зачем? Чтобы получить доступ к окну. А как ещё это можно сделать? Заранее записаться через мобильное приложение.

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

Что даёт карта?

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

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

Как работает цифровой двойник посылки

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

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

Информация поступает в основное хранилище всех операций Data Cloud Почты России. Облако не только сопровождает посылку, а ещё и хранит данные о её передвижениях. У нас есть не только оперативная информация о том, что пересылается прямо сейчас, а ещё и исторические данные по уже врученным отправлениям. Их мы используем, чтобы анализировать путь доставленных посылок.

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

Сдача посылки

Для присвоения трек-номера, с которого начинается путь двойника, не обязательно идти в отделение достаточно оформить посылку в мобильном приложении или на сайте. Там же можно получить расчёт стоимости доставки и подготовить ярлык для наклеивания на упаковку. Юридические лица тоже могут передавать данные об отправлениях до сдачи через API. Если не оформлять посылку заранее, то трек-номер ей присвоит оператор в отделении.

Логистика

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

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

Отслеживанием и исправлением проблем в дороге занимается ситуационный центр. Здесь сотрудники следят за отклонениями от контрольных сроков в режиме реального времени, используя данные из DataСloud.

Сортировка

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

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

Приём и выдача

После сортировок и перевозок письмо попадает в отделение. На этом этапе в работу включается сервис приёма входящих отправлений (СОВА). До того, как передать посылку получателю, сотрудникам Почты нужно зафиксировать прибытие машины, подготовить все сопроводительные документы, сверить и вскрыть ёмкости, сверить их содержимое и подготовить извещения. После этого отправления можно выдавать получателю или курьеру.

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

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

Как будет развиваться двойник

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

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

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

Подробнее..

Безопасные города без зоопарка

29.12.2020 18:11:47 | Автор: admin
image

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

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

С чем едят АПК Безопасный город

Аппаратно-программный комплекс Безопасный город это комплекс существующих и перспективных средств автоматизации в области общественного правопорядка, безопасности и комфортной среды в городской инфраструктуре.

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

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

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



По существу

Обратимся к нормативным документам. Единые требования к техническим параметрам сегментов аппаратно-программного комплекса Безопасный город (28.06.2017) лаконично констатируют, что в ядре платформы Безопасный город должно быть 2 ключевые подсистемы: Региональная интеграционная платформа (РИП) и Единый центр оперативного управления (ЕЦОР). Просто, недешево и минимально функционально. Только анализ данных и управление, остальное интеграции.

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

Например, в Курске при в рамках работ по созданию АПК Безопасный город была проведена работа по интеграции с имеющимся сервером видеонаблюдения, причем изначально стоял выбор между 2 вариантами: быстро и дешево интегрироваться по проприетарному протоколу, или доработать ядро системы и реализовать намного более универсальный протокол ONVIF. Осознанным выбором стало развитие системы и реализация ONVIF. Это стало важным шагом в развитии универсального решения.

Внедрение АПК Безопасный город постепенно набирает обороты, однако, есть проблемы. Это и затягивание сроков сдачи, и искажение, увеличение, раздувание в процессе задач по контрактам и банальный недостаток финансирования. С чем связанны эти особенности реализации? Как мы можем влиять на внедрение?

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

Добавим ингредиентов

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

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

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



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

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

Была проведена работа по обеспечению взаимодействия с системами видеоаналитики различных вендоров, включая систему распознавание номеров (ГРЗ), которая работает на обычных камерах видеонаблюдения. Далее ее сработки передаются в АИС регионального подразделения МВД. В целом в систему были заведены потоки всего спектра имеющихся в регионе устройств: от аналоговых камер до рубежей системы фотовидеофиксации. Апогеем данного проекта является интеграция видеопортала и РИП АПК БГ. Это позволило передавать информацию о всех камерах региона, транслировать онлайн-видео, архив, а также передавать события по срабатыванию видеоаналитики в единый центр.

Во-вторых, важным элементом в приготовлении безопасных городов является подсистема мониторинга стационарных и подвижных объектов. Надо и пробки видеть, и доступные транспортные средства, и датчики мониторинга на неподвижных объектах, и про экологию не забывать. Только по камерам оценить резервы и спрогнозировать ситуацию не получится. И все эти данные также приходят из разных подсистем и все их нужно объединять в рамках ядра АПК БГ, и не просто объединять, а где-то и управлять. Вот и получатся, что подсистема мониторинга просто обязана входить в список продуктов, необходимых для приготовления первоклассного АПК БГ.

И третьей ключевой подсистемой АПК БГ, пока не входящей в состав ядра является система оповещения населения. В России она давно создается и РАСЦО, и КСЭОН, но при интеграции с безопасным городом возникают проблемы и с управлением этим хозяйством, и с обратной связью. Сопряжение есть, отправка команды вроде бы идет, но понять, дошло ли сообщение до оператора внешней системы оповещения, и услышали ли его люди, зачастую невозможно.

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



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

Что станет изюминкой?

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

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

Но как можно предсказать будущее и проверить, что подсистема принятия решений работает? Здесь приходят на помощь наработки министерств РФ с многочисленными методикам анализа ситуаций и расчета показателей. Основаны они на реальном опыте и дают разработчикам всю необходимую информацию о формулах и особенностях расчета тех или иных ситуаций.
Интеграция нескольких источников данных в ядре Безопасного города помогает получить актуальные на данный момент величины (объем выбросов, тип вещества, направление ветра, температура) и на основании них выстроить наиболее эффективный план реагирования, алгоритм действий.

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



И на десерт

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

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

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

В какой доменной зоне регистрироваться, и что важно знать до регистрации

31.12.2020 12:04:32 | Автор: admin

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

Чтобы разобраться в доменных зонах, нужно знать, как устроены домены. Доменное имя (адрес сайта) состоит из нескольких уровней, разделенных точками. Чаще всего, из двух:

Нумерация идет справа-налево. Здесь: ru доменная зона (первый, он же верхний или корневой домен), sitename название (второй), которое придумывает администратор, может включать буквы, цифры, дефис.

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

catalog и zakaz поддомены sitename.ru, они же домены третьего и четвертого уровней, соответственно.Можно создать до 127 поддоменов, но итоговый адрес не должен превышать 255 знаков (вы удивитесь, но есть такие длинные доменные имена!).

Источник статистики serpstat.comИсточник статистики serpstat.com

Из статистики видно, что больше всего сайтов имеют адрес длиной около 10-15 символов. Объяснение скачку на позиции 32 я так не нашел. Если кто в курсе, поделитесь.

На практике делают не больше 3-4-х, чтобы он не был слишком длинным. С правой стороны адреса указывается доменная зона. Это комбинация букв, которая состоит из одной или двух частей (то есть, является одно- или двухуровневым доменом).

Виды и обозначения доменных зон

Есть общее деление:

  • ccTLD (country code top-level domain) для стран;

  • gTLD (generic top-level domain) по назначению или общие.

Для удобства объединим ccTLD с кодами регионов и городов, назовем территориальными. К gTLD добавим New gTLD это будет группа тематических доменов.

Почти полный список старых и новых TLD можно посмотреть на Rrpproxy.net. Корневые (одноуровневые) на Iana.org.

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

Территориальные

Выделим из этой категории национальные и региональные.

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

Полный список есть на Wiki

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

Лидируют .tk Токелау, .cn Китай, .de Германия.

Региональные доменные зоны относятся к городам или определенным территориям, объединенным по политическому, языковому или экономическому принципу. Популярные: .eu Евросоюз, .asia Азия, .afrika Африка, .su бывший СССР.

ТОП-10 региональных TLD:

Часть территориальных доменов используют как тематические из-за удачных комбинаций букв, например: .fm (Микронезия) для радио, .tv (Тувалу) для телевидения, .md (Молдавия) для медицинских организаций. С .bar как раз такой случай: принадлежит городу в Черногории, но большую часть сайтов зарегистрировали не местные жители, а представители баров (пабов) в разных странах.

Тематические

Группируются по виду деятельности (услугам) или назначению сайта.

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

Отдельно выделим 6 самых популярных международных зон, доступных без регистрационных ограничений:

Так выглядят ТОП-10 gTLD:

5 главных вопросов, на которые нужно знать ответы до регистрации

    1. Есть ли у вашего сайта специализация по услугам или товарам (назначению)?

    • да лучше тематическая TLD,

    • нет региональная TLD.

    1. Заняты ли все красивые домены с подходящим для вашего сайта названием среди популярных gTLD (.com, .biz) или ccTLD вашей страны (.ru)?

    2. Что для вас важнее: территория ведения бизнеса или вид деятельности?

    • Если территория, то определите: какой страной, областью, городом вы ограничены (или для какой языковой аудитории будете работать), планируете ли вы расширяться в будущем.

    • Если вид деятельности, то решите, какие общие или специализированные TLD для него подходят.

    • Если значимость равнозначна, то проверьте, возможно ли смешение двух для создания территориально-тематической.

    1. Свободен ли домен, подобранный по приоритетам?

    Совет: если нет свободных, что можно искать среди более широких областей (например, проверить не .ru для РФ, а .su, подходящая для стран бывшего СССР), обобщенных или взаимозаменяемых тематик (.pro или .expert, .shop или .store).

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

    1. Есть ли у вашего сайта специализация по услугам или товарам (назначению)?

    • да

    1. Свободен ли домен, подобранный по приоритетам?

    Совет: если нет свободных, что можно искать среди более широких областей (например, проверить не .ru для РФ, а .su, подходящая для стран бывшего СССР), обобщенных или взаимозаменяемых тематик (.pro или .expert, .shop или .store).

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

  1. Есть ли у вашего сайта специализация по услугам или товарам (назначению)?

  • да лучше тематическая TLD,

  • нет региональная TLD.

    2. Заняты ли все красивые домены с подходящим для вашего сайта названием среди популярных gTLD (.com, .biz) или ccTLD вашей страны (.ru)?

    3. Что для вас важнее: территория ведения бизнеса или вид деятельности?

  • Если территория, то определите: какой страной, областью, городом вы ограничены (или для какой языковой аудитории будете работать), планируете ли вы расширяться в будущем.

  • Если вид деятельности, то решите, какие общие или специализированные TLD для него подходят.

  • Если значимость равнозначна, то проверьте, возможно ли смешение двух для создания территориально-тематической.

    4. Свободен ли домен, подобранный по приоритетам?

    Если нет свободных, что можно искать среди более широких областей (например, проверить не .ru для РФ, а .su, подходящая для стран бывшего СССР), обобщенных или взаимозаменяемых тематик (.pro или .expert, .shop или .store).

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

Как выбирать доменную зону

Выбор доменов стал интереснее, но в разы сложнее. Больше всего сайтов зарегистрировано в универсальной международной gTLD .com. Она популярна до сих пор, но красивых легкозапоминаемых имен в ней уже практически не осталось, как и во многих национальных. Приходится выбирать среди менее известных. Для упрощения поиска есть несколько советов:

  • Тематические подходят международному бизнесу, так как не имеют национальной принадлежности.

  • Национальные/региональные предназначены для сайтов с четко определенной географией.

  • Если сайт одновременно соответствует тематике и региону, можно поискать смешанный вариант (они есть не для всех сочетаний ccTLD с gTLD). Например, украинской компании, предоставляющей сетевые услуги, подойдет .net.ua.

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

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

  • Чем длиннее название сайта, тем короче должна быть доменная зона.

  • Уникальное название лучше зарегистрировать сразу в нескольких вариантах, чтобы чтобы такой возможности не было у конкурентов.

ШАГИ

  1. Придумываем название

  2. Определяем тематику, регион

  3. Решаем, что из них важнее

  4. Заходим на сайт регистратора

  5. Проверяем самые интересные варианты (не забывайте про аукцион, возможно, хороший вариант скоро освободится)

  6. Можно сразу выбрать доменную зону и искать в ней

  7. Смотрим доступные варианты, при необходимости расширяем поиск

  8. Оцениваем сочетание названия и TLD, корректируем, если вышло слишком сложно

  9. Регистрируем

Подробнее..

Перевод Создание современных процессов CICD для бессерверных приложений с Red Hat OpenShift Pipelines и Argo CD. Часть 1

04.01.2021 18:18:07 | Автор: admin


В недавней статье выдвинуто предложение использовать Tekton в качестве фреймворка для облачных пайплайнов CI/CD и Argo CD в качестве идеальной пары для GitOps. Методики GitOps поддерживают непрерывное развертывание в гибридных и мультикластерных средах Kubernetes.


В настоящей статье, состоящей из двух частей, мы построим рабочий поток CI/CD, который продемонстрирует возможности совместного использования Tekton и GitOps. Вы также познакомитесь с Red Hat OpenShift Serverless, так как мы будем использовать ресурсы сервисов Knative в нашем CI/CD процессе. Начнем же мы с обзора процесса CI/CD, который мы внедрим для примера.


CI/CD процесс


На схеме ниже изображен CI/CD процесс. Коммит, инициированный в исходном коде приложения, запускает полный CI/CD процесс, который завершается тем, что новая версия бессерверного приложения развертывается в Dev, Stage и Prod средах.



Рисунок 1. Демонстрационный пример CI/CD процесса.


Давайте подробнее рассмотрим каждый шаг этого процесса:


  1. Разработчик отправляет новое изменение в репозиторий исходного кода приложения.
  2. Созданный в репозитории исходного кода вебхук запускает пайплайн Tekton.
  3. Как только пайплайн запустился, первая задача вызывает исходный код из репозитория.
  4. Задача Maven упаковывает код приложения в файл JAR и проводит тесты модулей до того, как построить образ контейнера.
  5. Задача Buildah строит и отправляет образ контейнера в registry. И затем образ отправляется во внутренний registry OpenShift.
  6. Пайплайн обновляет у себя репозиторий, в котором хранится желаемое состояние конфигурации приложения и описание развертывания. В методологии GitOps мы используем репозиторий Git в качестве единственного источника истины о том, что и куда развертывается.
  7. Изначально Git-репозиторий может быть пуст, но это не проблема, и этот шаг, инициализирует репозиторий со всеми манифестами Kubernetes (в данном случае сервисы Knative и ConfigMaps), которые необходимы, чтобы впервые запустить приложение. Последующие коммиты репозитория будут лишь обновлять существующие дескрипторы новыми версиями приложения, настройки канареечного тестирования и связанные конфигурации. Как только все файлы манифеста были созданы или модифицированы, задача отправляет изменения в репозиторий. Этот шаг является связующим звеном между непрерывной интеграцией, производимой пайплайном Tekton, и непрерывным развертыванием, управляемым Argo CD.
  8. Argo CD извлекает из репозитория конфигурации и синхронизирует существующие манифесты Kubernetes, которые заданы файлами Kustomize. Это действие создает последние объекты Kubernetes в неймспейсах development, stagingи production. Синхронизация может производиться автоматически или вручную в зависимости от требований неймспейса.
  9. В финальной части процесса может понадобиться извлечь образы, на которые ссылались в развертывании манифеста Kubernetes из внутреннего registry OpenShift. Команда эксплуатации может также внести изменения в конфигурацию, например, сменив URL целевого микросервиса или определенную информацию, которая известна команде разработчиков. Последний шаг может также создать состояние OutOfSync, что приведет к новому процессу синхронизации (см. шаг 9 на схеме).

Далее мы настроим наш кластер с OpenShift Operators и сервисами, которые нам понадобятся.


Настройка кластера OpenShift


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


$ git clone https://github.com/dsanchor/rh-developers-cicd.git

Затем проверьте, что у вас в системе установлены все инструменты из списка ниже. Они понадобятся при запуске скриптов:


  • Helm: helm version
  • Git: git version
  • oc: oc version
  • kustomize не ниже v3.1.0: customize version
  • envsubst (gettext): envsubst --help
  • tkn (опционально Tekton CLI): tkn version

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


$ oc login -u USERNAME -p PASSWORD https://api.YOUR_CLUSTER_DOMAIN:6443

Операторы, неймспейсы и привязки ролей


Мы сначала установим OpenShift Pipelines и OpenShift Serverless операторов в неймспейс openshift-operators.


Также создадим четыре новых неймспейса: cicd, development, staging и production. Образы помещаются в границы неймспейса cicd, поэтому, чтобы получать новые образы, все остальные неймспейсы требуют привилегий system:image-puller.


Наконец, добавим новую роль view по умолчанию в сервисные аккаунты development, staging и production. Эта роль обеспечивает доступ из наших подов приложения Quarkus к ConfigMaps и Secrets. (Приложение Quarkus я представлю чуть-чуть попозже).


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


$ ./bootstrap.sh---------------Installing openshift-pipelines operatorRelease "openshift-pipelines" does not exist. Installing it now.NAME: openshift-pipelinesLAST DEPLOYED: Thu Sep 10 10:55:14 2020NAMESPACE: defaultSTATUS: deployedREVISION: 1TEST SUITE: NoneInstalling openshift-serverlessRelease "openshift-serverless" does not exist. Installing it now.NAME: openshift-serverlessLAST DEPLOYED: Thu Sep 10 10:55:16 2020NAMESPACE: defaultSTATUS: deployedREVISION: 1TEST SUITE: NoneCreating cicd, development, staging and production namespacesAdded cicd system:image-puller role to default sa in development, staging and production namespacesAdded view role to default sa in development, staging and production namespacesRelease "bootstrap-projects" does not exist. Installing it now.NAME: bootstrap-projectsLAST DEPLOYED: Thu Sep 10 10:55:18 2020NAMESPACE: defaultSTATUS: deployedREVISION: 1TEST SUITE: None

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


Рисунок 2 показывает текущее состояние установки: оба оператора установлены в неймспейсе openshift-operators.



Рис. 2. Операторы OpenShift Serverless и OpenShift Pipelines установлены в неймспейсе openshift-operators.


Проверьте, что OpenShift Pipelines Operator установлен не ниже версии 1.1.1.
Теперь завершим установку компонентов OpenShift Serverless, установив панель управления Knative Serving.


Установка экземпляра Knative Serving


Нам нужно установить экземпляр Knative Serving, который предоставит нашим приложениям набор бессерверных возможностей. Чтобы создать экземпляр Knative Serving и установить панель управления, выполните следующее:


$ ./add-knative-serving.sh------------------------------Creating knative-serving namespacenamespace/knative-serving createdInstalling basic knative serving control planeknativeserving.operator.knative.dev/knative-serving created

Мы запустили набор подов, которые представляют базовую контрольную панель Knative Serving в неймспейс knative-serving, как показано на Рисунке 3.



Рис. 3. Панель управления Knative Serving в неймспейсе knative-serving.


Как показано на Рисунке 4, мы также создали новый неймспейс knative-serving-ingress для установочных входных шлюзов Knative.



Рис. 4. Новый неймспейс knative-serving-ingress.


Мы установили операторов OpenShift и создали неймспейс и экземпляр Knative Serving для управления нашими бессерверными процессами. Теперь мы готовы создать ресурсы Tekton, которые нам понадобятся для запуска пайплайна непрерывной интеграции.


Настройка задач и пайплайна Tekton


OpenShift Pipelines Operator поставляется с набором готовых кластерных задач, которые можно использовать для создания пайплайна. В некоторых ситуациях вам понадобятся другие задачи для получения определенного функционала. Эти задачи можно легко создать в Tekton. Вы также можете найти повторно используемые задачи и готовые пайплайны на Tekton Hub.


Для нашего пайплайна мы будем использовать одну задачу из Tekton Hub и две пользовательские. Чтобы эти задачи были доступны нашему пайплайну, нам нужно создать их в неймспейсе cicd. (Обратите внимание, что вы можете создать ClusterTasks, если считаете, что повторно используете их в разных пайплайнах из разных неймспейсов). Запустите следующий скрипт, чтобы установить необходимые задачи и создать пайплайн в том же неймспейсе.


$ ./add-tekton-customs.sh cicd------------------------------Installing buildah task from https://hub-preview.tekton.dev/task.tekton.dev/buildah createdInstalling custom taskstask.tekton.dev/push-knative-manifest createdtask.tekton.dev/workspace-cleaner createdInstalling knative-pipelinepipeline.tekton.dev/knative-pipeline created

Перейдите в консоль OpenShift и откройте меню Pipelines и проект cicd. Там вы увидите свои новые задачи, как показано на Рисунке 5.



Рис. 5. Новые задачи Tekton в неймспейсе cicd.


На Рисунке 6 представлен ваш новый пайплайн в том же неймспейсе.



Рис. 6. Пайплайн Tekton в неймспейсе cicd.


Рабочие области Tekton


Некоторые наши задачи в пайплайне требуют либо загрузки определенных конфигураций из ConfigMaps, либо сохранения состояния полученного выполнения, чтобы разделить его с другими задачами. Например, задача Maven требует, чтобы мы включили определенный settings.xml в ConfigMap. С другой стороны, первая задача вызывает репозиторий исходного кода приложения. Задаче Maven, которая идет следующей, потребуются эти файлы, чтобы создать приложение JAR. Мы используем OpenShift PersistentVolume, чтобы поделиться этими исходными файлами.


Tekton для этих целей имеет концепцию рабочих областей. Запустите следующий скрипт, чтобы добавить набор ConfigMaps и PersistentVolumeClaim в неймспейс cicd:


$ ./add-tekton-workspaces.sh cicd-----------------------------------Creating knative-kustomize-base ConfigMap with base kustomize files for Knative servicesconfigmap/knative-kustomize-base createdCreating knative-kustomize-environment ConfigMap with environment dependent kustomize filesconfigmap/knative-kustomize-environment createdCreating maven ConfigMap with settings.xmlconfigmap/maven createdCreating PVC using default storage classpersistentvolumeclaim/source-pvc created

Заметьте, этот скрипт создает PersistentVolumeClaim, не определяя StorageClass. Если вы не выберете какой-то определенный, то будет использоваться StorageClass по умолчанию. Без проблем можете раскомментировать любые строки в этом скрипте, чтобы он удовлетворял вашим требованиям.


Демо-приложение


До сих пор я почти ничего не сказал о демо-приложении. Оно основано на Quarkus, который идеально подходит для бессерверных приложений благодаря короткому времени загрузки и низкому потреблению памяти. Само приложение представляет из себя простой REST API Hello, world, который приветствует пользователей при вызове URI /hello.


Приложение использует расширение kubernetes-config для того, чтобы упростить работу с ConfigMaps и Secrets в Kubernetes. Приложение Hello, world! читает список ConfigMaps, что дает нам возможность управлять конфигурацией на разных уровнях, отменяя дублируемые свойства.


Рисунок 7 показывает фрагмент application.yaml, который определяет список ConfigMaps.



Рис. 7. Приложение YAML со списком ConfigMaps.


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


Создание собственного репозитория


На данном этапе вы должны создать репозиторий GitHub, который вы будете использовать для хранения файлов кастомизации, которые необходимы для демонстрации. Мой репозиторий называется quarkus-hello-world-deployment, и я буду использовать это имя для отсылок к данному репозиторию в следующих скриптах. Вы можете взять то же самое имя или придумать репозиторию свое.


GitHub изменил имя по умолчанию на main, что видно на Рисунке 8.



Рис. 8. Main задан веткой по умолчанию.


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


Чтобы пайплайн Tekton мог отправлять изменения в новый репозиторий, вам нужно будет предоставить валидные учетные данные GitHub. Учетные данные вы сохраните в Secret и свяжете их с пайплайном ServiceAccount, который был автоматически создан в неймспейсе cicd.


Запустите следующий скрипт:


$ ./add-github-credentials.sh cicd YOUR_GITHUB_USER YOUR_GITHUB_PASSWORD---------------------------------------------------------------------------Creating secret with github credentials for user dsanchorsecret/github-credentials createdLinking pipeline sa in namespace cicd with your github credentialsserviceaccount/pipeline patched

Ручной запуск пайплайна


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


Я написал два варианта запуска пайплайна вручную:


  • Создать пайплайн из yaml-файла;
  • Запустить пайплайн, используя Tekton CLI: tkn.

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


$ cat tekton/pipelines/knative-pipeline-run.yaml | \  SOURCE_REPO=https://github.com/dsanchor/quarkus-hello-world.git \  COMMIT=9ce90240f96a9906b59225fec16d830ab4f3fe12 \  SHORT_COMMIT=9ce9024 \  DEPLOYMENT_REPO=https://github.com/dsanchor/quarkus-hello-world-deployment.git \  IMAGES_NS=cicd envsubst | \  oc create -f - -n cicd------------------------------------------------------------------------------------------pipelinerun.tekton.dev/knative-pipeline-run-54kpq created

Если вы предпочитаете второй вариант, можно запустить пайплайн через tkn CLI:


$ tkn pipeline start knative-pipeline -p application=quarkus-hello-world \  -p source-repo-url=https://github.com/dsanchor/quarkus-hello-world.git \  -p source-revision=9ce90240f96a9906b59225fec16d830ab4f3fe12 \  -p short-source-revision=9ce9024 \  -p deployment-repo-url=https://github.com/dsanchor/quarkus-hello-world-deployment.git \  -p deployment-revision=master \  -p dockerfile=./src/main/docker/Dockerfile.jvm \  -p image-registry=image-registry.openshift-image-registry.svc.cluster.local:5000 \  -p image-repository=cicd \  -w name=source,claimName=source-pvc \  -w name=maven-settings,config=maven \  -w name=knative-kustomize-base,config=knative-kustomize-base \  -w name=knative-kustomize-environment,config=knative-kustomize-environment \  -n cicd

Еще один вариант запустить пайплайн через консоль OpenShift.


Отслеживание работы пайплайна


Для проверки рабочего прогресса откройте панель Pipeline Runs на консоли OpenShift, как показано на Рисунке 9.



Рис. 9. Использование панели Pipeline Runs для проверки рабочего прогресса.


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



Рис.10. Просмотр логов каждой задачи пайплайна.


Если вдруг вы дважды запустите пайплайн с одними и теми же параметрами (например, используя оба примера, которые я описал), вы увидите, что второй запуск завершится ошибкой при отправке манифестов Kustomization. Ошибка происходит, потому что нет ничего нового для выполнения отлично!


Результаты работы пайплайна


Диаграмма на Рисунке 11 иллюстрирует, чего мы уже достигли:



Рис. 11. Выполнение процесса CI/CD.


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


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


Обзор структуры репозитория развертывания


Сейчас самое время для обзора структуры репозитория развертывания и того, что в итоге станет окончательными манифестами, которые мы создадим с помощью Kustomize. Если вы не знакомы с Kustomize и его возможностями, не стесняйтесь узнать о нем больше. Понимание Kustomize может помочь лучше разбираться в структуре репозитория.
Обновите репозиторий развертывания (git pull), вы должны увидеть похожий результат:


 base    global-ops-configmap.yaml    kservice.yaml    kustomization.yaml development    env-ops-configmap.yaml    kustomization.yaml    r9ce9024       configmap.yaml       revision-patch.yaml       routing-patch.yaml    traffic-routing.yaml production    env-ops-configmap.yaml    kustomization-r9ce9024.yaml    r9ce9024       configmap.yaml       revision-patch.yaml       routing-patch.yaml    traffic-routing.yaml README.md staging env-ops-configmap.yaml kustomization-r9ce9024.yaml r9ce9024    configmap.yaml    revision-patch.yaml    routing-patch.yaml traffic-routing.yaml

Для простоты я пока рассмотрю только папки base и development:


  • Папка base содержит все ресурсы, общие для трех сред. В ней есть базовая структура сервиса Knative и карта глобальной конфигурации.
  • Папка development содержит наложения для завершения генерации манифеста сервиса Knative в данной версии приложения (примером служит папка r9ce9024) и двух ConfigMap, связана с уровнем настроек самого окружения и уровнем настроек разработчика. То, что находится в папке ревизии, было скопировано из исходного кода приложения, что позволяет разработчику самому задавать гибкие настройки.

Мы пользуемся простотой сервисов Knative, чтобы определить независимые маршруты для каждой версии сервиса и распределить трафик между версиями. Таким образом, traffic-routing.yaml и routing-patch.yaml формируют окончательную секцию маршрутизации трафика сервиса Knative.


Каждый раз когда в development появляется новая версия, для нее создается независимый маршрут, чтобы она точно была доступна для тестирования. Основной маршрут остается неизменным (например, направленный на две предыдущие версии). Мы достигаем такого поведения не путем изменения основного traffic-routing.yaml автоматически из пайплайна, а благодаря добавлению нового маршрута (routing-patch.yaml) для новой версии.


Эти детали станет проще понимать, когда мы проведем дополнительные тесты в Части 2. На данный момент просто отметьте для себя существенную разницу между неймспейсами staging и production и средой development. Пайплайн CI не создает файл kustomization.yaml (именно с таким именем) для них. Всегда будет файл с дополнительным префиксом версии: kustomization-r9ce9024.yaml. Эти изменения не будут учитываться в процессе синхронизации, если только в kustomization.yaml нет отсылки на эту новую версию. Чтобы изменения стали видны Kustomize, это надо настроить вручную.


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


Kustomize: соберем все кусочки пазла вместе


Мы рассмотрели наполнение и структуру репозитория развертывания, но у нас до сих пор нет окончательной композиции сервиса Knative и ConfigMaps. Приведенный ниже скрипт использует kustomize для построения окончательных манифестов, чтобы мы смогли увидеть, как они выглядят:


$ kustomize build development------------------------------apiVersion: v1kind: ConfigMapmetadata:  name: env-ops-quarkus-hello-world---apiVersion: v1kind: ConfigMapmetadata:  name: global-ops-quarkus-hello-world---apiVersion: v1data:  application.yaml: |-    message: hola    environment:      name: devkind: ConfigMapmetadata:  name: quarkus-hello-world---apiVersion: serving.knative.dev/v1kind: Servicemetadata:  name: quarkus-hello-worldspec:  template:    metadata:      name: quarkus-hello-world-r9ce9024    spec:      containers:      - image: image-registry.openshift-image-registry.svc.cluster.local:5000/cicd/quarkus-hello-world:9ce90240f96a9906b59225fec16d830ab4f3fe12        livenessProbe:          httpGet:            path: /health/live        readinessProbe:          httpGet:            path: /health/ready  traffic:  - percent: 100    revisionName: quarkus-hello-world-r9ce9024  - revisionName: quarkus-hello-world-r9ce9024    tag: r9ce9024

Заключение


На данном этапе мы могли бы применить наш набор объектов в неймспейсе development, чтобы получить рабочее бессерверное приложение, но мы не хотим вручную запускать развертывание. Во второй части статьи я покажу, как интегрировать Argo CD в пайплайн CI/CD, который мы уже создали.


От редакции: Узнать о внедрении CI/CD и интеграции Gitlab CI с Kubernetes можно с помощью практического видеокурса Слёрма. На уроках курса инженеры компаний Tinkoff и Southbridge делятся лучшими практиками построения пайплайнов.

Подробнее..

Мониторинг с высокой доступностью. Опыт компании СберСервис

05.01.2021 16:09:52 | Автор: admin

СберСервис крупнейшая сервисная компания федерального значения, оказывающая услуги по комплексному техническому обслуживанию широкого спектра информационно-телекоммуникационного оборудования, рабочих мест, офисной техники, серверов и телефонии. Компания является единственным на территории СНГ премиум-партнером компании Zabbix, в ней работает самая крупная команда в России в сфере ИТ-мониторинга, разрабатывая уникальные технические решения в области комплексного внедрения систем мониторинга для организаций с высоконагруженной ИТ-инфраструктурой. Данный факт объясняет, почему в качестве основной платформы для мониторинга СберСервис выбирает Zabbix.

О чем эта статья?

Как следует из названия, в статье предлагается концепция организации мониторинга с высокой доступностью. В роли подопытного выступает Zabbix Server, для организации Active-Active кластера применяется Corosync и Pacemaker, а работает это всё на Linux. Данное ПО является OpenSource, поэтому такое решение доступно каждому.

В процессе эксплуатации Zabbix для мониторинга высоконагруженной ИТ-инфраструктуры (рост количества элементов данных, рост числа узлов сети, большая глубина хранения сырых данных, постоянно растущие потребности пользователей) многие сталкиваются с проблемами производительности сервера Zabbix во время старта или перезапуска. В условиях High Load (>60k NVPS) обычная перезагрузка сервера Zabbix превращается в весьма длительную, хотя и штатную процедуру. Время от запуска службы до появления данных в мониторинге может достигать 15-20 минут.

Столкнувшись с этим, и проанализировав ситуацию, команда мониторинга пришла к решению, что поможет кластеризация по принципу Active-Active. Кроме того, была поставлена цель добиться Disaster Recovery путем переноса на разные ЦОДы.

Задача

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

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

Требования

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

  • управление нодами ZabbixServer без видимого прерывания сервиса мониторинга на время проведения различных технических работ по обновлению, правке конфигураций и т. д., именно поэтому не подойдет виртуализация в чистом виде;

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

Встроенный функционал схемы кластеризации ресурсов в режиме Active-Passive с использованием Pacemaker и Corosync рассматривался уже много раз и в частности на Хабре естьподробная статьядля случая кластеризации БД истатья про кластеризацию Заббикса(вместо Corosync использовался cman, но смысл тот же).

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

Команда смогла придумать схему и реализовать логику работы всех компонентов и модулей системы для воплощения в реальность отказоустойчивого кластера, работающего в режиме Active-Active как с применением в схеме аппаратного балансировщика нагрузки (LoadBalancer), так и без него.

Полученное решение реализует два важных для системы мониторинга свойства:

  • Непрерывность мониторинга

  • Отказоустойчивость мониторинга

Рассмотрим реализацию решения High Available ZabbixServer в режиме Active-Active без LoadBalancerПринципиальная схема взаимодействия компонентов:

Принцип работы

Использование в схеме менеджера управления кластерными ресурсами (Cluster resource) подразумевает развертывание компонентов управления кластером на виртуальном сервере. Таким образом достигается отказоустойчивость управляющего модуля.

В кластере существует 2 ноды. При подготовке нод следует учитывать свойства stonith и quorum их необходимо отключить.
Свойство quorum применяется для схемы кластера от 3х нод и более. Если в схеме кластера, состоящего из 2х нод использовать данное свойство, тогда при падении одной ноды произойдёт выключение всех ресурсов.

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

ocf::heartbeat:ZBX-IPaddressocf::heartbeat:ZBX-Instance

При аварийном выходе из строя основной ноды, кластерные ресурсы перемещаются на резервную ноду. Ресурс ZBX-IPaddress управляет виртуальным ip-адресом и входит в стандартный набор кластерных ресурсов (IPaddr2). ZBX-Instance самописный кластерный ресурс для сервиса zabbix-server и управления подключениями к БД. На каждом Zabbix-сервере в конфигурационном файле прописаны разные пользователи БД, при этом, в любой момент времени пользователь основного Zabbix-сервера имеет права Read/Write, а пользователь резервного права ReadOnly, поэтому на обеих нодах служба zabbix-server может находиться в запущенном состоянии (привет, Active-Active).

Перевод кластерных ресурсов в случае сбоя выглядит следующим образом. Ресурс ZBX-IP-address переводит виртуальный IP-адрес на другую ноду, а ресурс ZBX-Instance переводит пользователя БД резервного zabbix-сервера в режим Read/Write, а пользователя БД основного zabbix-сервера в режим ReadOnly, при этом закрывая имеющиеся к БД старые сессии подключения. Таким образом мониторинг инфраструктуры не прекращается. Непрерывность записи информации достигается за счет буферизации снятых метрик с объектов мониторинга на стороне ZabbixProxy. После того как прокси получает подключение к серверу, он передает накопленные данные.

Важный нюанс применение данной схемы подходит только в случае нахождения master и slave ZabbixServer-нод в одной подсети.

Рассмотрим реализацию решения High Available ZabbixServer в режиме Active-Active с LoadBalancer

Принципиальная схема взаимодействия компонентов:

Принцип работы

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

В Pacemaker создаются кластерные ресурсы:

ocf::heartbeat:ZBX-Cluster-Socketocf::heartbeat:ZBX-Instance

Ресурс ZBX-Cluster-Socket управляет сигнальным портом на ноде нужен для работы LoadBalancer-а.

Ресурс ZBX-Instance управляет процессом zabbix-server-а и правами доступа к БД.

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

Ресурс ZBX-Cluster-Socket создаётся с помощью встроенной в Pacemaker функциональности по созданию ресурсов из системного процесса (службы). Служба сигнального порта обыкновенная самописная служба, которая просто открывает на хосте соответствующий порт, за состоянием которого будет наблюдать LoadBalancer. Осуществлена привязка ресурса ZBX-Cluster-Socket к ресурсу ZBX-Instance посредством ограничения (constraint) для того, чтобы кластерные ресурсы перемещались совместно. Corosync, управляя ресурсом ZBX-Cluster-Socket, поддерживает в открытом состоянии только порт 101 на основной Master-node и в закрытом состоянии порт 201 на резервной Slave-node. Для LoadBalancer сигналом на переключение/отправку трафика являются: открытый порт 101 на первой ноде или открытый порт 201 на второй ноде, если оба порта на обеих нодах открыты, или оба закрыты, трафик никуда не отправляется.

Переключение ресурсов с текущей Master-node на текущую Slave-node происходит следующим образом:

При падении Master-node, порт 101 становится недоступным, тогда сигналом для LoadBalancer на переключение трафика будет являться открытый порт 201 на Slave-node. Corosync, определив, что Master-node недоступна, переключает ресурсы ZBX-Instance и ZBX-Cluster-Socket вместе на Slave-node, а благодаря скрипту resource_movement, на основе которого Pacemaker создал ресурс ZBX-Instance происходит смена прав пользователей User_A и User_B в базе данных, при этом закрываются все старые сессии подключения к БД.

Что произойдет в случае потери связности между нодами кластера при условии полной работоспособности нод?

Схема та же: кластер состоит из 2-х нод Master-node (пользователь User_A) и Slave-node (User_B), на Master-node запущены кластерные ресурсы.

При потере связи каждая из нод определит, что другая нода недоступна, тогда обе запустят у себя кластерные ресурсы. Master-node перезапускать ничего не будет и продолжит работу, определяя свою роль главной. Slave-node тоже посчитает себя главной и запустит у себя кластерные ресурсы. При этом LoadBalancer определит, что на Master-node и Slave-node доступны порты ZabbixServer и управляющий порт, соответственно LoadBalancer прекратит передачу сетевого трафика.

Следует отметить важный момент какими будут права доступа к базе данных соответствующих пользователей? Одна из нод по-прежнему будет иметь доступ к БД с правами Read/Write, а другая с правами ReadOnly, так как:

  • Если связь Slave-node с БД не была потеряна, то Slave-node во время включения у себя кластерных ресурсов произведет смену прав пользователей: для User_A права изменятся на ReadOnly, а для User_B права изменятся на Read/Write.

  • Если связь Slave-node с БД потеряна, следовательно Slave-node не сможет выполнить переключение прав пользователей.

  • После восстановления связности кластерные ресурсы снова переместятся на Master-node, LoadBalancer определит, что управляющий порт доступен только на Master-node и начнёт передавать ей сетевой трафик.

Заключение

Данный кейс иллюстрирует принципиальную идею и концепцию придуманного решения (а точнее 2-х реализаций), и не является прямым руководством к действию. Инфраструктуры и ограничения у всех разные, а инженеры, перед которыми ставятся похожие задачи не нуждаются в How to.

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

Подробнее..

Apache Kafka в вопросах и ответах

06.01.2021 14:15:34 | Автор: admin

Что такое Kafka? Где стоит, а где не стоит применять этот инструмент? Чем Kafka отличается от RabbitMQ и других брокеров сообщений? Как её правильно эксплуатировать? Всё это обсудили на митапе Apache Kafka в вопросах и ответах, который Слёрм провёл в ноябре 2020. В разговоре участвовали спикеры из Авито, Stripe, ITSumma и Confluent. Запись митапа доступна на YouTube, а текстовую версию разговора читайте ниже.



Знакомство со спикерами


МАРСЕЛЬ ИБРАЕВ: Сегодня мы говорим о Kafka, но не про философию, а про приложение. У нас очень крутые спикеры, разрешите мне их представить и сразу задать каждому приветственный вопрос: какой RPS на вашем проекте?


Анатолий Солдатов lead engineer в Avito, много работал с базами данных, Kafka, Zookeeper, ClickHouse и много выступает на митапах и конференциях. Если не секрет, какой RPS на вашем проекте?


АНАТОЛИЙ СОЛДАТОВ: У нас около 600 RPS и порядка 25 Гб/с. Это в сумме все кластера.


МАРСЕЛЬ ИБРАЕВ: Огонь! Также с нами Александр Миронов, Infrastructure Engineer из компании Stripe, занимается развитием системы CI, работал в таких компаниях, как 2ГИС, Lingualeo и 4 года возглавлял инфраструктурную команду разработки сервисов стриминга данных в Booking.com. И это нам о чём-то да должно говорить: стриминг, большие данные, и вот это вот все наверняка как-то связано. Правильно я понимаю, Александр? И какой RPS?


АЛЕКСАНДР МИРОНОВ: Да, ты понимаешь все совершенно правильно, на середину 2020 года в Booking.com RPS получалось около 60 Гб входящего трафика и около 200 Гб исходящего, в миллионах сообщений я, честно говоря, не помню. Но это десятки миллионов сообщений в секунду.


МАРСЕЛЬ ИБРАЕВ: Супер.


АНАТОЛИЙ СОЛДАТОВ: Мы, кстати, у ребят из Booking.com учились. У нас Kafka помоложе, и Саша нам очень сильно помогал затащить всё это. Делились опытом.


МАРСЕЛЬ ИБРАЕВ: Далее у нас Виктор Гамов, Developer Advocate в Confluent. Специализируется на обработке потоковых данных с помощью Kafka. Также спикер российских, международных IT-конференций.


ВИКТОР ГАМОВ: И стример. Стал стримить, вот до чего жизнь довела! На конференции не пускают, приходится стримить. Всем привет! Какой RPS я не знаю, потому что я бездельник, маркетолог, я Kafka только продаю, не замеряю её вес. На самом деле, у нас свой Public Cloud, и у нас есть и большие, и маленькие клиенты. Не могу конкретно о цифрах говорить, но клаудный бизнес растет достаточно хорошо, люди приходят за managed-решениями. Есть SLA до трех девяток, не всегда дело в RPS, а еще иногда и в SLA, и в других вещах, которые связаны с reliability, не только со скоростью.


МАРСЕЛЬ ИБРАЕВ: Не RPS единым.


ВИКТОР ГАМОВ: Да.


МАРСЕЛЬ ИБРАЕВ: Ну и наконец Иван Сидоров, Chief Technology Innovation Officer из компании ITSumma. Самое интересное, что Иван прошел путь от простого разработчика к архитектору и обратно несколько раз, совместив это с менеджментом. Более того, вдохновившись книгой по Kafka, он инициировал создание технического издательства в компании. К Ивану вопрос такой же: как используете Kafka, какие есть максимально нагруженные проекты? Есть ли такие данные и можно ли их озвучить?


ИВАН СИДОРОВ: Отвечу немного уклончиво. По должности я исполнительный директор компании и занимаюсь внедрением различных инноваций, моя работа узнавать про новые технологии, применять их в своей деятельности. Компания у нас сервисная, поэтому своя Kafka нам если и нужна, то только какая-то карманная. Но мы поддерживаем около половины Рунета крупного точно, и Kafka мы видели очень много, в разных конфигурациях, в разных вариантах использования. И RPS тут совершенно неважен. Тут важно, как используется Kafka, для чего она нужна. Конкретные цифры сказать не могу, но очень большие бывают тоже.


МАРСЕЛЬ ИБРАЕВ: Теперь, я думаю, наша уважаемая аудитория понимает, что компетенции участников достаточно высоки. Определенно будет, о чем поговорить.


АНАТОЛИЙ СОЛДАТОВ: Чем больше RPS, тем выше компетенция. Саша выиграл здесь, мне кажется.


АЛЕКСАНДР МИРОНОВ: Не, ну, Public Cloud от Confluent, я думаю, выиграет в любом случае.


АНАТОЛИЙ СОЛДАТОВ: Наверное, да, выиграет.


МАРСЕЛЬ ИБРАЕВ: Сам придумал такую линейку, сам решил.


ВИКТОР ГАМОВ: Вот мы это и делаем. Появилась Kafka, давайте из нее сделаем Kafka для всего, вот. У нас теперь Kafka для всего.


Что такое Kafka


МАРСЕЛЬ ИБРАЕВ: Много раз звучало слово Kafka, и я бы хотел, чтобы наша аудитория вышла на один уровень понимания, что же такое Kafka и чем оно не является. В определениях часто встречается такое слово, как брокер сообщений. И для меня, человека рефлексирующего по 2007 году, это словосочетание вызывает ассоциации с Jabber, ICQ и прочим. Все-таки хочется понять, что же такое на самом деле Kafka и для чего она предназначена.


АНАТОЛИЙ СОЛДАТОВ: Давайте по вариантам, чтобы было интереснее. Это лог, это стриминговая платформа, это база данных, свой вариант?


ВИКТОР ГАМОВ: Свой вариант. В книжке от Бена Стоффеда есть замечательная метафора: слепые встретили слона и начали его ощупывать. И в зависимости от того, что они трогали, у всех складывалось определенное впечатление. Кто-то потрогал за хвост и подумал, что это опоссум. Кто-то потрогал за хобот и подумал, что это удав. Кто-то потрогал за кожу и вообще ничего не понял. Такая же история и с Kafka. Все зависит от того, откуда вы пришли, от вашего изначального опыта и того, как вы ее начали трогать. Толя дал варианты: лог, стриминговая платформа, база данных? Я скажу так это всё. Попробуйте переубедить меня.


С Kafka интересная история. Можно сказать, что пришли маркетологи и заставили нас думать, что Kafka это такая панацея от всего. На самом деле, Kafka появилась из одной простой идеи. Эта идея не нова, но её решили выкатить в первый ряд. Это идея лога, и она всегда присутствовала в любой системе, где есть персистентность, будь то база данных или система обмена сообщениями. Лог это простая идея: у тебя есть файлик, ты в него пишешь просто в конец и читаешь с начала. Эту идею имплементировали сами не раз руками. Поэтому, когда приходит слепой (из той метафоры), эксперт из мира очередей, он смотрит: ну, это же очередь! Мы же пишем в конец и читаем из начала. Это же очередь. Значит, месседжинг, правильно? Правильно.


Дальше приходит человек из мира баз данных и говорит: погодите, но мы же в Kafka данные размазываем по брокерам. Там есть партицирование, там есть consistent hashing, когда мы по какому-то ключу вынимаем, по значению знаем, куда класть. Когда клиенту не надо иметь какого-то внешнего load balancer, чтобы договориться. Это же распределенная база данных, это же NoSQL во все поля. Плюс, потому что там есть persistence, это точно база данных.


Потом приходят люди из мира ESB (enterprise service bus) и говорят: ну, там же есть коннекторы, которые позволяют нам перетаскивать данные отсюда сюда. Это ж ESB! Есть небольшой коннектор, на коннекторе есть какие-то определенные SMT (single message transforms), которые позволяют раутить в минимальном объеме. Точно ESB!


Получается неразбериха. Поэтому решили остановиться на таком определении, как Event Streaming Platform платформа для захвата и обработки стримов, потоков сообщений, потоков событий. Событие это какая-то иммутабельная запись, которая не меняется, и в идеале постоянно лежит в Kafka.


ИВАН СИДОРОВ: Дополню. Ты перечислил много применений, а если у нас замешаны датчики, то это уже IoT интернет вещей. Kafka тоже там! А вообще, это такая же категория, как операционная система. Что делает операционная система? Все что угодно. Kafka это система для работы с данными. Соответственно, в каком контексте её используют, такие возможности она и предоставляет.


АНАТОЛИЙ СОЛДАТОВ: Да, еще забыл вариант труба. И ещё вопрос: встречали ли вы сетапы, где Kafka используется как база данных самостоятельно? Без всяких PostgreSQL, MongoDB и так далее. Вот есть приложение, есть Kafka, и больше ничего нет.


ИВАН СИДОРОВ: Мы да.


АНАТОЛИЙ СОЛДАТОВ: То есть, такие кейсы вполне себе есть?


АЛЕКСАНДР МИРОНОВ: Да, встречали.


АНАТОЛИЙ СОЛДАТОВ: А с ksqlDB что-то такое уже пробовали, чтобы это была полноценная замена реальной базе данных: с индексами, с селективными запросами, которые могут ходить в прошлое?


ИВАН СИДОРОВ: Кейсы, которые видели мы, были чем-то вроде хранилища логов. Сложные запросы не нужны были.


ВИКТОР ГАМОВ: В чате пишут, что я еще забыл самый правильный юзкейс, который Kafka использует RPS строить поверх нее.


ИВАН СИДОРОВ: А чем он отличается от ESB, например?


МАРСЕЛЬ ИБРАЕВ: Все зависли над твоим вопросом.


ВИКТОР ГАМОВ: Накручиваешь, накручиваешь, и получается сборка того, что тебе нужно. Года три назад была статья от The New York Times о том, как они используют Kafka в качестве хранилища. Но у них такое, каноническое хранилище источник информации, из которого все забирают и потом каким-то образом модифицируют. Тут нужна СMS, она все это вычитает и в какие-то форматы обернёт, чтобы отрисовать это всё на экране. Если это система каталогизации, она Kafka берёт как исходник, а поверх строит какой-то индекс.


В чате пишут, что Kafka это винегрет. Kafka это Kafka.


АЛЕКСАНДР МИРОНОВ: Такое количество способов использования системы, в очередной раз подчеркивает, что перед тем как начинать пользоваться Kafka, вам нужно чётко понимать, что именно вы от неё ожидаете, какую пользу для бизнеса вы планируете извлечь. Будь то open source Kafka или managed-решения вроде Confluent, и так далее.


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


ВИКТОР ГАМОВ: Но все ещё возможно, есть способы.


АНАТОЛИЙ СОЛДАТОВ: Возможно-то всё, вопрос здравого смысла.


ВИКТОР ГАМОВ: Это самое главное. Спасибо, что есть Толик, который приходит и говорит правильные мысли. Вопрос не в RPS, а в здравом смысле.


МАРСЕЛЬ ИБРАЕВ: Получается, Kafka это действительно комбайн, который сочетает в себе различную функциональность. Это может быть обработчик сообщений (брокер), база данных


Где стоит, а где не стоит применять


МАРСЕЛЬ ИБРАЕВ: В каких областях Kafka можно применить? Я так понимаю, это анализ данных. Ещё я сталкивался с системой логирования мониторинга. Где помимо этих сфер можно применять Kafka?


АНАТОЛИЙ СОЛДАТОВ: В чатике было дополнение, что Kafka хорошо подходит для обмена сервисов, то есть notification туда отлично ложатся.


Давай я перечислю, для чего Kafka используется в Avito, а то фантазировать много можно. Для аналитики, для всяких кликстримов, для стриминга, для message broker, для того, чтобы вставлять различные буферы перед системами типа Elastic или ClickHouse. У нас это хорошо задружилось с трейсингом, например. Такие в основном паттерны: аналитика, message broker, буфер, база данных.


АЛЕКСАНДР МИРОНОВ: Fanout еще, такой классический кейc.


ИВАН СИДОРОВ: Аналитика в каком плане?


АНАТОЛИЙ СОЛДАТОВ: Самый простой кейс это когда на платформу входит весь входящий трафик кликстримовый, а нашим аналитикам весь трафик не нужен, потому что там очень много ботов. И мы прямо в Kafka берём и фильтруем всё это. У нас появляется отфильтрованный топик, в котором содержится только чистый трафик, и он идёт, например, дальше в ClickHouse.


АЛЕКСАНДР МИРОНОВ: Еще один классический кейс это security-анализ, анализ фишинга. Потому многие фреймворки для реал-тайм анализа из коробки позволяют использовать sliding window пятиминутное, которое автоматически за вас будет пересчитывать счетчики. Это очень удобно.


МАРСЕЛЬ ИБРАЕВ: Огонь! У каждого инструмента есть лучшие/худшие практики: молоток хорошо забивает гвозди, но замешивать им тесто не очень удобно, хотя и возможно. Есть ли области, где Kafka не ложится никак?


ВИКТОР ГАМОВ: High-Frequency-Trading (HFT). Здесь Kafka ни о чём, потому что, где диск привязан, там начинаются проблемы. Плюс, это распределённые системы. Там, где начинаются всякие сетевые вопросы, скорее всего, Kafka не подойдет. Если нужен простой месседжинг с простым раутингом (без внедрения тех вещей, о которых мы уже поговорили вкратце, KSQL, Kafka-streams, флипинг и т.д), здесь Kafka тоже не подходит. Потому что нужен просто message broker. Можно, конечно, использовать Kafka. Но потом люди приходят и говорят: вот, Kafka для нашего HFT не подходит. Ну, естественно не подходит. Для этого есть какой-нибудь Aeron или ZeroMQ, которые были создан для того, чтобы не бежать по распределёнке, а
локально.


АНАТОЛИЙ СОЛДАТОВ: Тут в целом, если тебе нужны и очереди, и супер low latency, и 100% гарантия доставки, и у тебя поток данных небольшой, то лучше не искать огромных инструментов типа Kafka...


ИВАН СИДОРОВ: а использовать хардварные решения.


АНАТОЛИЙ СОЛДАТОВ: Ну, я подводил к RabbitMQ, конечно, но можно и так.


ИВАН СИДОРОВ: Нет, это долго.


ВИКТОР ГАМОВ: Правильное, на самом деле, уточнение по поводу хардварных решений. Я раньше трудился в компании, которая делала небольшой распределенный кэш, назывался Hazelcast. И мы делали такую интеграцию интерпрайзную со всякими балалайками, чтобы делать кросс-датацентерную (как вы по-русски говорите?) Multi-Datacenter Replication.


АЛЕКСАНДР МИРОНОВ: Очень по-русски сказал.


ВИКТОР ГАМОВ: И мы как раз перед тем, как запилить адаптер для Kafka, мы запилили адаптер для Solace, который давал хардварное решение. Люди с большими деньгами покупали платы, которые давали супербыстрый latency. Там вопрос был именно передачи информации между океаном, между Чикагской биржей и Лондонской, поэтому Solace давал какие-то дикие цифры, потому что лежал поверх кастомной сети и кастомного железа. Поэтому шутки шутками, но если хочется скорости, всегда можно опуститься, как Ваня сказал, на уровень железки.


ИВАН СИДОРОВ: Если ты в HFT, у тебя уже есть деньги для того, чтобы сделать кастомную железку.


ВИКТОР ГАМОВ: Или деньги инвесторов.


ИВАН СИДОРОВ: Да, а если нет, то HFT не будет.


АЛЕКСАНДР МИРОНОВ: Ну, и еще одна холиварная тема это использование Kafka в качестве базы данных. Теоретически это возможно и даже практически мы видим какие-то кейсы, но чтобы сделать это правильно, потребуется значительное количество времени, и во многих случаях, возможно, имеет смысл продолжить спокойно использовать PostgreSQL или что-то еще, что позволяет делать простые запросы по любым ключам. Потому что Kafka все-таки да, имеет выборку по офсету ID, но даже эта операция значительно медленнее...


ВИКТОР ГАМОВ: Вот ты правильно говоришь, но для слушателей надо немного пояснить. Почему Kafka ассоциируется с известным докладом Мартина Клеппмана (Martin Kleppmann) Turning the database inside-out (если вы не видели, сходите посмотрите). Отличие Kafka от базы данных в том, что и там, и там есть лог и durable-хранилище, которое обеспечивает хранение данных на долгий срок, но в обычной базе данных для вас в API есть Query Engine, с которым вы взаимодействуете посредством какого-то DSL: SQL, в данном случае, если noSQL, там тоже какой-то свой, JSON, не знаю, что-нибудь в MongoDB. В Kafka всё немного иначе. Там storage, собственно, вот этот лог, и ваш Query language разнесены. Поэтому абсолютно непрактично использовать какой-то стандартный low level кафковский API для того, чтобы бегать по апсету. Это не нужно, неправильно и вообще вредно.


Обычно смысл Kafka в том, что вы можете насадить туда любое приложение, и оно становится вот этим Query Agent, и вы дальше накручиваете. Вы хотите иметь какой-то хитрый язык запроса? Вы можете это сделать. Речь идет о том, что стандарта нет такого, чтобы вот взять и сделать из Kafka k-value какой-то Storage. Вам нужно все равно что-то либо написать, например, взять Kafka Streams, написать там две строчки, и у вас получается из топика сделать материализованный View и отдать его через REST. Это достаточно просто сделать. Такой же процесс использует skim-registry. Вот мы сделали балалаечку, которая позволяет хранить схемы, данные. Skim-registry не нужно ничего, кроме Kafka. Она внутри Kafka хранит все ваши схемы. Она наружу отдаёт REST-интерфейс. Если вы пришли и сказали: вот у меня есть такой тип схемы, вот мой номер ID, отдай мне всю схему, всё это реализовано внутри Kafka. Kafka используется как хранилище.


Kafka Сonnect использует Kafka как базу данных. Там тыща параметров всяких, настроек лежит внутри Kafka. Когда вы стартует, Сonnect голый, он все настройки хранит внутри Kafka. То есть, здесь ничего не надо. Это к вопросу о том, что Марсель сказал про молоток. Можно молотком помешать тесто? Можно. Можно ли на Kafka сделать базу данных? Можно. Можно ли на ней сделать серьезную базу данных? Можно. Вопрос в уровне упоротости. Насколько глубоко вы готовы пойти.


ИВАН СИДОРОВ: Kafka и база данных это звучит дико из-за того, что не сходится с парадигмой обычной базы данных, где язык запросов и база данных неотделимы друг от друга. Но это достаточно просто показывается на примере того же самого Hadoop, который стал уже достаточно расхожей технологией. Что такое Hadoop? Обычно, когда говорят Hadoop, говорят HDFS. Это просто файловая система, а поверх нее можно накручивать схемы, разные движки запросов, Hive, HBase, все что угодно. И в Kafka, как я понимаю, просто пока вот этих Query Engine которые бы уже закрепились в индустрии, пока нет. И поэтому Kafka для базы данных
воспринимается так.


И если вопрос о том, где Kafka применяется неправильно, чуть переиначить и спросить: а где нерационально или слишком дорого применять Kafka это логирование. Можно делать логирование на Kafka и писать вокруг что-то или можно взять готовый ELK, который ты клик и установил. Зачем тут Kafka? Нерационально. Но если нужна система логирования, которая потом обрабатывает кучу микросервисов, отправляется через Сonnect в какой то-то data warehouse и так далее, то тут уже надо подумать, что ELK не принесёт пользы, а принесет
больше вреда, пока будешь ковыряться внутри Elastic.


МАРСЕЛЬ ИБРАЕВ: Супер, с этим вопросом разобрались. Теперь понятно, что за инструмент такой Kafka. Пойдем дальше.


Kafka vs RabbitMQ


МАРСЕЛЬ ИБРАЕВ: На круглый стол зарегистрировались около полутора тысяч человек, они задали порядка 200 вопросов, 90-95% которых были про RabbitMQ.


И первый вопрос: в чем отличие? Как я понял, Kafka это многофункциональный инструмент. RabbitMQ работает с очередями и для этого предназначен. Так ли это?


АНАТОЛИЙ СОЛДАТОВ: По большому счету, наверное, да. RabbitMQ планировался в первую очередь для очередей, и по-другому мы его не использовали. Kafka дизайнилась как бы с другой парадигмы, что ли. Вопервых, там очереди и топики это разная семантика, они не повторяют свои свойства. Во-вторых, у Kafka была изначально цель высокая пропускная способность, реально высокая. RabbitMQ, я и на своем примере знаю, и от разных компаний слышал, что 20-30 K RPS для RabbitMQ это предел. Как очередь он в принципе и не должен выдерживать больше. Наверняка, есть какой-нибудь мастер RabbitMQ, который его так соберёт, что это будет суперскоростной реактивный RabbitMQ, но это тоже вопрос: а зачем он такой, если есть технологии под этот кейс? А для Kafka перемалывать сотни, миллионы RPS это нормально. Она дизайнилась именно для этих целей. Но, с другой стороны, если нужен low latency и вам важно, чтобы одно сообщение быстренько долетело до консюмера, нигде не потерялось, то здесь RabbitMQ может и лучше подойти.


АЛЕКСАНДР МИРОНОВ: Тут нужно уточнить, что Kafka всё равно можно затюнить под low latency, чтобы у вас были миллисекундные задержки. Но для этого нужно постараться.


АНАТОЛИЙ СОЛДАТОВ: Надо потрудиться, да. И это будет, скорее всего, выделенный кластер. Не получится сделать один кластер и под high-throughput и под low latency.


АЛЕКСАНДР МИРОНОВ: Самое главное, действительно, в разной семантике топиков и очередей. Виктор уже назвал десяток технологий подобных очередей. В концепции очереди у вас есть возможность удалить сообщение или пометить его как прочитанное. Вы можете это сделать в любом порядке. Kafka это лог, которому всегда аппендятся записи. Из него ничего удалить нельзя. Соответственно, единственная метка того, где сейчас находится ваш консюмер это текущий upset, который всегда монотонно возрастает (monotonic increasing). Соответственно, вы не можете просто взять и без дополнительных инструментов пропустить какое-то сообщение, чтобы потом к нему вернуться и прочитать. Вам пришло 10 сообщений, вы должны дать Kafka ответ: вы их все обработали или нет.


АНАТОЛИЙ СОЛДАТОВ: Не могу удержаться и не сказать, что так тоже можно


АЛЕКСАНДР МИРОНОВ: Можно, да. У Uber есть большая статья: Dead Letter Queues with Apache Kafka. Про то, как они сделали Dead letter queue.


АНАТОЛИЙ СОЛДАТОВ: Кстати, в чем отличие того же Dead letter queue в RabbitMQ оно встроено в брокер, а в Kafka клиенты или что-то там над брокерами реализует эту всю логику.


АЛЕКСАНДР МИРОНОВ: Вам понадобится ещё дополнительный функционал, чтобы это сделать. И возможно, можно взять просто out of the box инструменты, а уж тем более, если вы находитесь где-то в Public Cloud, в Amazon или в Google, у вас уже есть очереди, которые доступны из коробки.


АНАТОЛИЙ СОЛДАТОВ: Опять же, различия есть. Они тоже из топиков вытекают, как Саша сказал, что есть offset consumer-groups, в RabbitMQ ты не особо почитаешь несколькими консюмерами из одной очереди. Это можно сделать, размножив очередь. А в Kafka ты читаешь один и тот же лог, и у тебя апсеты трекаются независимо для разных consumer-groups. Это вполне себе легко работает.


ВИКТОР ГАМОВ: Вот это, кстати, такой очень интересный момент, который не всегда все до конца понимают. Люди спрашивают: как мне сделать так, чтобы кто-то другой не прочитал мое сообщение? Или наоборот, чтобы смог. Я думаю, это опять все связано с тем, что Kafka не появилась из научного института, где все было сразу продумано, она появилась от сохи: люди решали собственную проблему. Вот эта категория имен, которая пришла из месседжинга, и вызывает определенные вопросы. Топик, брокер это же все месседжинг. И люди накладывают поверх этого какой-то свой предыдущий бэкграунд.


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


Но, как только мы начинаем говорить про вещи, как Event Sourcing, QSRs, вот эти все микросервисы обмена сообщениями, вот тут люди начинают видеть бенефиты. Если они приходят в Kafka из мира обмена сообщениями, какого-то там ивентсорсинга (хотя это тоже не чистая Event Sourcing система, можно накрутить и добавить, есть там определенные решения, которые это все реализуют), люди видят бенефит. И опять же, при добавлении каких-то клевых штук, например, хранилища, которое позволяет хранить всю историю сообщений в системе, которое позволяет в любой момент в любой новой системе перечитать эти данные по новой и получить репорт.


Например, у нас есть система, которая захватывает все заказы, и нам в конце года нужно подвести итоги запустить большую джобу (от англ. job), которая выдаст репорт. Эта джоба запускается один раз в год, но данные нужно откуда-то брать. Чтобы не переливать из одного места в другое, она вычитывает данные из Kafka один раз и получает отчёт.


АНАТОЛИЙ СОЛДАТОВ: Иногда бывают вопросы: у меня в компании RabbitMQ, мы слушали, что Kafka крутая и модная, давайте мы ее поставим на замену, потому что она лучше. Хотя RabbitMQ не хуже в каких-то своих кейсах, и вообще отличная штука для очередей.


ВИКТОР ГАМОВ: Самое лучшее программное обеспечение это то, которым вы умеете пользоваться. Если вы умеете хорошо варить RabbitMQ, и он у вас не падает, по ночам вам не звонят админы, а если вы админ, то не звонят пользователи-разработчики, то вообще нет проблем.


ИВАН СИДОРОВ: Я вот все ждал, когда уровень абстракции поднимется, потому что, вот как я написал про свою должность, от разработчика к архитектору и обратно


В: Ты как Хоббит туда и обратно.


ИВАН СИДОРОВ: Да, и каждый раз с приключениями. Вообще, разница между RabbitMQ и Kafka это то, что одна машина красная, другая синяя. Если в общем говорить. В архитектурном плане. У меня есть теория, откуда начались эти холивары, которые достаточно жестко цепляются за незначительные нюансы. Kafka и RabbitMQ стартовали примерно в одно время. RabbitMQ был написал на Erlang. Тогда был фетиш, все верили, что Erlang это потрясающая система, которая спасёт мир технологий и ускорит всё, а Java это кровавый интерпрайз, мол, чтобы мне запустить на моей VPS-ке с 16-ю мегабайтами памяти Java, придется купить еще 10 таких VPS.


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


АНАТОЛИЙ СОЛДАТОВ: Ты вот подводишь, что Kafka и RabbitMQ это одно и то же, но нет. Напомню, на всякий случай.


ИВАН СИДОРОВ: Я говорил с точки зрения архитектуры.


МАРСЕЛЬ ИБРАЕВ: Итак, мы обсудили, что разница у Kafka и RabbitMQ есть. И всегда нужно идти от продукта, от задачи и от умения пользоваться инструментом. Не стоит слепо верить статьям, где написано, что Kafka это круто, и у вас сайтик на WordPress взлетит после её установки.


АНАТОЛИЙ СОЛДАТОВ: Я добавлю ещё про RabbitMQ. Бывает ещё, что ты просто упираешься в технологию. У нас были случаи, когда RabbitMQ приходилось отключать реплику, чтобы он успевал. И это уже звоночек, что надо что-то другое. Плюс всякие истории с нестабильными сетями. Там тоже RabbitMQ разваливается хорошо, и стоит сразу смотреть другие технологии. Даже если вы сейчас умеете с ним работать, то Multi-DC с нестабильными сетями и высокие нагрузки не очень подходят для RabbitMQ.


Как правильно эксплуатировать Kafka


МАРСЕЛЬ ИБРАЕВ: Предположим, мы решили, что проект подходит для Kafka, мы его поставили. Но поставить и настроить это полдела. Дальше его надо эксплуатировать. Как правильно эксплуатировать Kafka? На что стоит обратить внимание? Какие метрики собирать?


АЛЕКСАНДР МИРОНОВ: Надо начать с вопроса, А на чём вы собираетесь запускать Kafka: на виртуальных машинах, на Kubernetes, на bare metal? И от этого способы развёртки и инсталляции будут кардинально меняться. Multi-DC и прочие сетапы добавляют проблем.
Классическая инсталляция Kafka это некий кластер с минимум тремя нодами, чтобы данные копировались как минимум дважды. То есть у вас будет три брокера. Как вы будете их запускать, это зависит от вас: можете с помощью Puppet, можете попробовать сделать это в Kubernetes, что будет намного сложнее. Kafka это распределённая система, у Kafka есть один небольшой недостаток, который постепенно устраняется, это зависимость от ZooKeeper.


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


АНАТОЛИЙ СОЛДАТОВ: Почему недостаток?


АЛЕКСАНДР МИРОНОВ: Ну не знаю, если ты садомазохист, то тебе может быть прикольно запускать две системы, чтобы какого-то продуктового кейса добиться, но вообще


АНАТОЛИЙ СОЛДАТОВ: Ну слушай, ты этот ZooKeeper один раз описываешь в Puppet, и потом тебе уже не важно будет, Kafka одна или с ZooKeeper.


АЛЕКСАНДР МИРОНОВ: Мы же обсуждаем это с точки зрения DevOps? Для любого DevOps-инженера это ещё одна система, которую нужно знать, алертить, мониторить, которая у вас будет падать.


АНАТОЛИЙ СОЛДАТОВ: С другой стороны, ZooKeeper может не только для Kafka использоваться, он вполне может жить в компании в каких-то других системах.


АЛЕКСАНДР МИРОНОВ: А этого, кстати, лучше не делать. Лучше не использовать ZooKeeper для нескольких систем.


АНАТОЛИЙ СОЛДАТОВ: С этим я согласен, но я про другое. Я про то, что ты где-то в Puppet имеешь описанные модули под ZooKeeper, и сетапишь ты его для Kafka или для ClickHouse не важно. Понятно, конфигурация изменится, нагрузка будет другая, но ты уже умеешь с ним работать и у тебя уже мониторинг настроен (немного что-то другое появится, конечно). Я не разделяю нелюбовь к ZooKeeper.


АЛЕКСАНДР МИРОНОВ: Никакой нелюбви нет, просто нужно отдавать себе отчёт, вот и всё


АНАТОЛИЙ СОЛДАТОВ: Да ладно!


АЛЕКСАНДР МИРОНОВ: К слову сказать, в моей команде в Booking.com за всё время эксплуатации Kafka не было каких-то больших проблем с ZooKeeper. Но, чтобы их не было, нам пришлось его подробно изучить.


АНАТОЛИЙ СОЛДАТОВ: ZooKeeper очень старая система. У нас тоже с ним никогда не было проблем.


АЛЕКСАНДР МИРОНОВ: Но у нас в компании всё же были проблемы с ZooKeeper. Не в моей команде, но в других командах. И когда они случаются, они обычно очень серьёзные.


В чём ещё особенность Kafka для людей, которые приходят из managed-сервисов? Например, когда вы работаете с SQS в Amazon, вы чётко знаете лимиты вашей очереди. Вы не можете записать, условно, больше тысячи сообщений в секунду; не можете записать больше чем 1 Мб сообщений в секунду. И вы можете выстраивать приложение, отталкиваясь от этих очень чётких лимитов. С Kafka такого нет. Это зависит и от того, как зависит ваше приложение и продюсеры, и консюмеры; от того, как настроен ваш кластер. Если придёте к админу и скажете: Заведи мне топик и скажи, сколько я смогу записать сообщений в одну партицию. Скорее всего, он не сможет дать вам простой ответ. Это ещё одна особенность Kafka, с которой мы сталкивались очень часто. Потому что приходят люди с очень разным бэкграундом, особенно из продуктовых команд, и последнее, что им нужно это думать про Кб и Мб в секунду, которые они могут пропустить через одну партицию с какой-то latency. Придётся прописывать какие-то гайдлайны для разработчиков. Нужно будет запускать бенчмарки. Нужно будет понимать, вот на вашем сетапе, на вашем железе, сколько данных за какой интервал времени вы можете пропустить.


Что ещё нужно знать про Kafka? Клиенты на каком языке вы пишете, и чем вы пользуетесь. Kafka изначально написана на Scala, теперь уже больше на Java. Соответственно, последний vanilla-клиент, которые поддерживает это всё, это джавовый клиент. Если вы используете C#, то официальный клиент Confluent, например, сделан поверх C-библиотеки librdkafka, которая тоже поддерживается человеком, который работает в Confluent, но всё равно у вас будет задержка с фичами, они будут приходить позже.


Клиенты C Sharp, Java, Go, Python, Ruby мы в Booking.com ещё Perl любили использовать, как вы знаете, нам пришлось свой клиент поверх librdkafka писать. Это достаточно большая боль, которая может возникнуть в тех компаниях, которые используют разные языковые экосистемы.


АНАТОЛИЙ СОЛДАТОВ: Да, но здесь можно либо пользоваться вот этими клиентами или писать свои, либо второе какие-то прокси комплементить или использовать, там уже нет привязки к языку.


АЛЕКСАНДР МИРОНОВ: Совершенно верно! И мы опять приходим к тому, что это ещё один возможный компонент, который придется внедрить, чтобы эту систему развязать. Это всё подчеркивает то, Kafka, она как брокер сообщений, как бы мы его ни называли, достаточно бесполезна сама по себе. Самый большой бенефит Kafka по сравнению с RabbitMQ или Pulsar это её экосистема. Это количество коннекторов, приложений, проприетарных решений, которые просто из коробки будут работать с Kafka. Я знаю даже кейсы из других компаний, где интегрировали данные из нескольких компаний с помощью Kafka. Просто потому, что у них уже она была, и им было намного проще таким образом запродюссить друг другу сообщения в кластере, прокинуть сетевые доступы условные, чем городить свои собственные проприетарные http-протоколы или ещё что-то. Вот именно эта инфраструктура и её распространенность вот это самая главная мощь Kafka, на мой взгляд.


АНАТОЛИЙ СОЛДАТОВ: Мне тоже так кажется. Более того, есть ребята из разных компаний, в том числе российских, которые из Kafka используют только коннекторы. Всё вот это вот связали, поставили Kafka, и за счет этой экосистемы не пишут вообще никакого кода. На конфигах у них всё взлетает, всё работает. Здесь иногда цена внедрения очень маленькая. Она вся упирается в инфраструктуру, по сути.


Чем глубже Kafka прорастает в компанию, есть у нее такая фишка, кластера начинают плодиться с большой силой после первого, инфраструктура тоже разрастается и порой становится очень сложной. Всё что мы перечислили: коннекторы, Zookeeper, репликаторы, мониторинги, штуки, которые позволяют легче администрировать кластера Kafka (потому что администрирование это довольно большой объём toil work). И очень быстро. Стандартная история когда у нас есть Kafka, а вокруг нее еще 10 инфраструктурных сервисов или технологий вращается.


АЛЕКСАНДР МИРОНОВ: На эту тему еще можете посмотреть как раз в Avito мы в январе этого года делали доклады, я и Толя, и мы подробно обсуждали экосистемы. То, как мы делали это в Booking.com и Толя рассказывал, как ребята делают коннекторы в Avito, и можно посмотреть, какое количество дополнительных компонентов нужно для того, чтобы эффективно ранить эту систему, чтобы ваши девелоперы занимались продуктовой разработкой, а не разработкой для Kafka.


Я еще хотел по-быстрому ответить на вопрос из чата: Лучше Kafka Connect или NiFi? В NiFi нет репликации. Если у вас падает нода в NiFi перед тем, как она прокинула данные ещё куда-то, если вы не поднимите её обратно (не знаю, помолитесь или пойдёте диск собирать руками), то не сможете эти данные восстановить.


ИВАН СИДОРОВ: Хочу всё же про мониторинг резюмировать. С коллегами я полностью согласен. Единственная метрика, которую нужно мониторить на инфраструктуре это теряем мы деньги или не теряем, а дальше уже спускаться до самого нижнего компонента. Если рассматривать Kafka как вещь в себе, то её нужно мониторить как обычное Java-приложение. Побольше памяти поставил, она не вылетает всё хорошо.


АЛЕКСАНДР МИРОНОВ: Это, кстати, плохое решение для Kafka, ну да ладно.


ИВАН СИДОРОВ: Мы же в отрыве от инфраструктуры, нам же не сказали данные. А дальше нужно смотреть, выполняет ли выбранная часть инфраструктуры, реализованная на Kafka, свою бизнес-задачу. Самый простой кейс, когда мы используем Kafka как очередь и кидаем с одной стороны сообщение в другое, то смотрим: они отправляются и принимаются? с какой скоростью принимаются? с какой отправляются? почему так мало или много принимается? есть ли аномалии? Аномалии в том бизнес-процессе, который технологически реализует Kafka.


АНАТОЛИЙ СОЛДАТОВ: Ты говоришь про ISO-мониторинг, насколько я услышал, это штука крутая. Кажется, из неё нужно исходить, и всякие там алёрты на пейджеры присылать, когда начинаются всякие такие проблемы, потому что у Kafka отказ одной, пяти или десяти машин это не проблема, можно спать дальше, если всё остальное выполняется.


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


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


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


АЛЕКСАНДР МИРОНОВ: Сеть, файловые дескрипторы, disk io.


АНАТОЛИЙ СОЛДАТОВ: Файловые дескрипторы можно поставить 1 млн, и не смотреть их. Но у нас они тоже выведены, на самом деле.


АЛЕКСАНДР МИРОНОВ: Ну да, к вам просто придёт 1 млн коннекшенов, вы даже не узнаете об этом.


АНАТОЛИЙ СОЛДАТОВ: Я думаю, мы узнаем об этом быстро. Все пользователи Avito узнают об этом.


И самый низкий уровень это уже когда ты на уровне брокера смотришь специфичные какие-то метрики, сколько там в Q висит это сообщение, как часто меняются shiring expand. Там много всего, что может позволить помочь понять, где проблема (с ДЦ что-то произошло, не вывозят рейды, и их надо увеличить). Такой мониторинг тоже должен быть. Я не вижу кейса, когда вы без него можете понять, что происходит.


ИВАН СИДОРОВ: Есть проблема овермониторинга. Как ты классно рассказал, что вы спускаетесь фактически с SLA-мониторинга на процессы конкретных систем, на конкретный кластер, на конкретную джобу. Если мы спускаемся на конкретную джобу и видим экран из тысячи метрик, и 30 из них горят красными, сделать вывод, что происходит, невозможно. Исчерпывающим мониторингом можно считать тот, который срабатывает в большинстве случаев. А с верхнего уровня у нас стоит все сломалось. И все сломалось запускает ресеч до расширения списков алертов.


АЛЕКСАНДР МИРОНОВ: Мне кажется, что мы просто приходим к топику white box VS black box мониторинг, насколько я знаю у Слёрма есть всякие курсы на эту тему.


АНАТОЛИЙ СОЛДАТОВ: Самый простой путь это взять какой-то проприетарный мониторинг, который работает уже долго (например, от Confluent). Посмотреть, как у них работает, и понять что вам нужно. Там всё довольно-таки красиво, в картинках. Не надо это покупать, но заимплементить через Prometheus, Consul, Grafana, Graphite точно можно.


АЛЕКСАНДР МИРОНОВ: У Kafka в главной документации есть описание критических метрик, за которыми надо следить.


Особенности разработки приложений для работы с Kafka


МАРСЕЛЬ ИБРАЕВ: Есть ли особенности разработки приложения для работы с Kafka? Какие-то подходы?


АЛЕКСАНДР МИРОНОВ: Хочется как-то сформулировать, чтобы опять это не превращать в часовую дискуссию, потому что очень широкие вопросы. Мы уже затронули клиенты. В зависимости от того, какой клиент вы используете, он будет вести себя по-разному. Давайте обсудим Java vanilla клиент, потому что он наверняка самый популярный. В Java vanilla клиенте у вас есть две части этой библиотеки: producers и consumers. Обе эти части тюнятся совершенно по-разному. У каждой свой набор конфигураций, который вы можете настроить в зависимости от того, под какие продуктовые цели используете Kafka. Продюсер вы можете затюнить либо под low latency, чтобы он как можно быстрее отправлял сообщения с высокой гарантией доставки, либо вы можете сказать: мне нужно медленно, но много, или мало, но качественно, либо что-то среднее (in the middle).


По умолчанию, кстати, это касается и настроек брокера тоже, Kafka настроена как система in the middle: она не дает вам супергарантии доставки и не заточена под супер low latency, она где-то посередине, чтобы удовлетворять 80% юзкейсов. Это важно упомянуть, потому что если вы не видите проблем с продюсерами, с консюмерами или брокерами, скорее всего, вам не нужно трогать эти настройки.


Приведу пример. В Booking.com в первые несколько лет мы, может быть, 3 или 4 из сотни top level конфигов меняли. То есть вот этот дефолт действительно очень same в Kafka. Если возвращаться к producer side. Джавовый producer это мультитредное приложение, которое внутри открывает n тредов, коннектится к брокерам, начинает слать сообщения. Лучшая практика его применения это переиспользование одного и того же инстанса в Java. Не нужно открывать тред-сейф, соответственно, вы можете успешно пользоваться одним и тем же инстансом.


С консюмером совершенно другая история, он не тред-сейф. Мало того, что, когда вы делаете какие-то запросы типа poll, если в данный момент в буфере у этого консюмера нет сообщений, которые он вам может отдать напрямую, он заблокирует ваш main trap и начнет делать запросы Kafka. Это уже совершенно два разных поведения вроде как одной и той же библиотеки.
Но я уверен, что в 80-90% вам не надо будет ничего тюнить, вам просто нужно понять, с какой гарантией вы хотите доставить ваше сообщение. Вам, например, без разницы, дойдет оно или нет (поскольку это метрика или log line), или вам важно не потерять его (сообщение о заказе на сайте). Для этого есть одна top level настройка, которая будет фактически контролировать, на какое количество реплик будет записано сообщение, и ответ в ваше приложение вернётся только тогда, когда n реплик подтвердили запись. Соответственно, вы можете сказать, что я просто послал по сети сообщение, и мне даже TCP-акт не нужен, (это акт 0, по-моему).
Про всю эту тему есть отличная статья How to Lose Messages on a Kafka Cluster. И там достаточно большое исследование проведено. Там в Docker чувак поднимал разные конфигурации кластеров, писал в них сообщения, валил эти ноды и смотрел, где какие сообщения теряются. Пойдите почитайте и вы поймёте, что нужно и не нужно делать.


АНАТОЛИЙ СОЛДАТОВ: Я с Сашей полностью согласен. Единственное, добавил бы, что вы, скорее всего, в какой-то момент придёте к коробочкам. У вас будут как раз эти конфиги и вы можете их всех загнать в какой-нибудь фреймворк и использовать всё время одни и те же, чтобы не давать клиентам сильно много ручек, чтобы они не крутили и не портили сами себе жизнь случайно.


АЛЕКСАНДР МИРОНОВ: Согласен. У нас в Booking.com примерно так же и было сделано: ты мог затюнить все конфиги, которые хотел, ничего не ограничивали, но мы давали набор пресетов или коробочек, как ты сказал. У них было human-readable название типа low latency, No AX, high-throughput и мы затюнивали 3-5 параметров в бэкграунд за тебя.


АНАТОЛИЙ СОЛДАТОВ: Да, потому что кажется, что это проблема со всеми системами, где много клиентских настроек, что если у вас сотни сервисов или клиентов, скорее всего, кто-то из них сделает неправильно.


АЛЕКСАНДР МИРОНОВ: Наверное, тут еще про консюмеры нужно упомянуть. Самая главная теория, которую нужно знать про консюмера когда вы отправляете offset, коммитите offset. Гарантия обработки сообщения это: at least once, at most once или exactly once. Это важно для того, чтобы не потерять ваши данные, не потерять результаты обработки ваших данных и, по сути, по большому счету это все сводится к тому, что вот вы считали сообщение, вы получили сообщение из Kafka, после этого вы проводите работу над этим сообщением (неважно, что вы делаете), и перед вами стоит ключевой вопрос: в какой момент вы будете коммитить этот offset обратно в Kafka. Вы будете коммитить его как запроцешенный до того, как вы сделаете процессинг или после? И в зависимости от этого у вас будут разные гарантии доставки и обработки этих сообщений.


АНАТОЛИЙ СОЛДАТОВ: Я бы еще добавил про консюмера то, что он скейлится, их параллелизм зависит напрямую от количества партиций в топике, тоже такая базовая штука. Саша сказал про механику офсетов, есть еще вторая базовая механика: не нужно консюмеров больше делать, чем количество партиций, потому что в Kafka так сделано там больше, чем один консюмер на одну партицию не намапится. Если у вас их будет, условно, 10, а партиций всего три, то никакой пользы вы из этого не извлечете, и вам надо будет сначала партиции увеличить, а потом уже вы получите параллелизм.


АЛЕКСАНДР МИРОНОВ: Совершенно верно, да.


Бэкапы


МАРСЕЛЬ ИБРАЕВ: Последний вопрос из заготовок, который мы успеем рассмотреть: бэкап. Kafka штука распредёленная, и вроде как можно забить и сказать: она сама себя поддерживает, и если что-то упадет, то ну и ладно, она будёт работать. Махнуть рукой и предположить, что никаких проблем не будет. Но при этом что-то такое админское в душе просит все-таки какие-то сохранения состояний, бэкапы на всякий случай. И вопрос такой: нужны ли вообще бэкапы на Kafka, если нужны, то почему или почему не нужны?


АЛЕКСАНДР МИРОНОВ: Я придерживаюсь мнения, что скорее не нужны. Во-первых, в Kafka есть встроенный механизм репликации, который полностью конфигурируется вами, и вы можете контролировать количество реплик от нуля до бесконечности. Помимо этого механизма встроенной серверной репликации у вас есть те самые гарантии доставки, которые мы уже обсудили (тот самый параметр Ex). Вы можете контролировать, на сколько физических или виртуальных машин, контейнеров, подов у вас будет записано сообщение перед тем, как producer получит Всё OK от сервера. Исходя из тех бизнес-кейсов, с которыми работал я, этой гарантии было более чем достаточно.


Тут ещё такой момент, что Kafka имеет замечательный встроенный механизм ретеншена данных. Она может из коробки по времени или по размеру вашего топика удалять старые сегменты. Сегменты данных, которые были записаны, допустим, неделю назад, если вы ее так сконфигурировали. Это даёт вам гарантию, что сейчас внутри вашего кластера будут данные за прошедшую неделю, а более ранние Kafka автоматически из кластера выкинет. Чаще всего Kafka используется именно с таким паттерном, а не как бесконечная база данных.


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


Ещё один интересный момент это поддержка infinite retention, то есть бесконечного ретеншена. Это значит, что вы сможете сконфигурировать Kafka таким образом, что вот те самые старые сегменты, которые выкидываются и просто удаляются с диска, вы можете сказать Kafka, что она должна их сложить в какой-то холодный object store (по большому счёту, это Tiered Storage). Интерпрайзный уже есть, но я им не пользовался, так что не буду говорить (open source должен появиться). Так что холодные сегменты, данные, которые вы уже не будете активно использовать, вы можете сложить в S3 и потом доставать раз в год, когда нужно перечитать весь лог. Так вы будете сохранять место на горячем диске и при этом не понадобиться задумываться о бэкапах и прочих дополнительных настройках.


АНАТОЛИЙ СОЛДАТОВ: Я полностью за, и у меня есть несколько дополнений. Начну с Tiered Storage. Это крутая штука, которая изменит в целом конфигурацию машин по Kafka. Сейчас у нас есть какие-то заряженные железками, дисками машины, а можно будет просто какие-то маленькие (почти in memory) Kafka ставить, а все остальное складывать в Tiered Storage. Это как один из вариантов использования.


По поводу бэкапов у нас такой же подход. Kafka это по умолчанию распределённая отказоустойчивая система, которая не должна терять данные, и она для этого практически всё делает. Угробить можно любую систему, конечно. Один из ключевых конфигов, которые нужно не забыть использовать это rack awareness, на мой взгляд. Даже если вы живете в одном дата-центре, попробуйте, если у вас есть контроль над серверами, хотя бы в разные стойки разнести брокеры, всем брокерам прописать, где они стоят (rack id). И Kafka будет следить, чтобы у вас все лидеры равномерно по этим рэкам распределились. Тогда вероятность проблем минимальная. При этом стоимость бэкапов Kafka высокая. Так что Kafka бэкапить-то можно, но будет это стоить дорого, а реального профита вы наверняка не получите.


И второй момент: у Kafka есть Zookeeper, как мы уже обсуждали, и это та система, которую, бэкапить можно. Она довольно недорогая. Мы бэкапим ее. Просто раз в неделю снимаем бэкапы, валидируем их довольно примитивно. Смотрим, что у брокеров id стоят, в Docker разворачиваем и считаем, что всё OK.


АЛЕКСАНДР МИРОНОВ: Мы тоже бэкапим Zookeeper, это важно.


АНАТОЛИЙ СОЛДАТОВ: Без Zookeeper Kafka теряет информацию о том, какие данные где лежат, как их получить. Даже если вся Kafka работает хорошо, а кластер Zookeeper по каким-то причинам отлетел, вам будет очень сложно восстановить данные. Есть всякие Kafka-дампы, которыми можно вытащить из конкретных топиков, которые вы знаете, где лежат, конкретные данные. Но это будет долго и скорее всего не восстановите весь кластер. Поэтому лучше Zookeeper-мозги где-то хранить.


АЛЕКСАНДР МИРОНОВ: При том что объём этих мозгов измеряется в Мб.


Там еще спрашивают в чате: учитывается ли rack id в min.insync.replicas? Я отвечу нет. Просто смысл rack id, в том, что он используется Kafka в момент создания топика. Когда вы говорите, сколько у вас есть партиций в топике, и для каждой у вас будет n реплик. Вот этот rack id, Kafka вам гарантирует, что эти реплики партиций будут раскиданы по разным рэкам. Что она не положит их все в один рэк. После этого она и никакой rack id в своём рантайме не использует.


АНАТОЛИЙ СОЛДАТОВ: Не Kafka использует, а всякие админ-команды. Это будет влиять только на ребалансировки, когда вы будете партиции двигать по брокерам. Тогда да. Он опять заиграет, и Kafka будет смотреть на них так, чтобы лидеров или партиций перетащить так, чтобы они были во всех стойках были распределены правильно.


АЛЕКСАНДР МИРОНОВ: И если, например, вы зададите, что у вас два рэка, но при этом min.insync.replicas у вас там три, то по умолчанию команда создания топиков скажет вам, что не может создать топик, потому что не может раскидать партиции равномерно.


ИВАН СИДОРОВ: По опыту наших клиентов на поддержке могу сказать, что сейчас данные, хранимые в Kafka, не настолько дороги, чтобы делать бэкапы с них. Пока что в типовых случаях время жизни данных в Kafk довольно короткое. Тут правильная мысль про то, что реплики должны быть в разных дата-центрах. Но реплика это кластер, и даже учитывая, что мастер-ноды там нет, они сами себе выбирают, с кластером что-то может пойти не так. Но сохранять данные очень дорого по соотношению стоимость данных/стоимость хранения данных, и самый эффективный вариант, который мы видели это mirroring кластера. Чем отличается от реплики: поднимается точно такой же кластер и настраивается туда пересылка данных. Он просто работает как резерв и как бэкап.


АНАТОЛИЙ СОЛДАТОВ: Тут сразу два момента интересных если несколько ДЦ, это не синоним того, что у нас несколько кластеров. И всегда, когда про Kafka читаешь, начинается с того, что О! Stretch cluster, ужас какой, не используйте. Это всё неправда. На самом деле, нужно исходить из latency, которую ваша сеть дает, проверить хотя бы это, и скорее всего там stretch cluster заведётся, будет всё работать хорошо. Есть варианты с асинхронными кластерами, которые на основе репликаторов, но здесь тоже не стоит забывать, что это повышает сложность всей системы и то, что появляется еще одна точка отказа, и это не бесплатно. И начинать все-таки стоит с простого stretch cluster, который один, растянутый на несколько дата-центров. И часто он работает.


ИВАН СИДОРОВ: Добавлю ещё не про кластеры, а про mirroring кластера. Читал в вопросах, как разделять контуры безопасности, практический опыт если есть интранет и экстранет, и в интранет пускать нельзя, а потоки данных идут из внешки, можно миррорить часть топиков из внешней Kafka во внутреннюю Kafka. Открыть только одну дырочку.


Для тех, кто хочет узнать больше о настройке и оптимизации Apache Kafka Слёрм готовит новый видеокурс. Спикеры Анатолий Солдатов из Авито и Александр Миронов из Stripe. Доступ к первым урокам будет бесплатным. Оставить заявку на курс можно уже сейчас.

Подробнее..

Как не пережить аварию вредные советы

08.01.2021 10:16:53 | Автор: admin

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

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

И вот о том, как не овеять себя славой самого могучего специалиста во веки веков, мы сегодня и поговорим. Шесть очевидных и не очень поводов задуматься. И да, при чтении не забывайте поднимать табличку "Сарказм" и помните - всё написанное ниже основано на реальных случаях.

Ты админ ты лучше знаешь, чего им надо!

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

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

Этим приложением пользуется всего десять человек? Да это явно ерунда какая-то и не может быть критически важным компонентом производственной цепочки. А вот файловая шара на несколько терабайт всегда была в почёте. Кого ни спросишь, все там что-то хранили, и совершенно очевидно, что после контроллера домена первым делом надо поднимать именно её. Ну и почту, наверное. Остальные подождут, ничего страшного не случится.

Не забивай голову мануалами. Всё знать невозможно

В конце концов вы за что деньги платили? Ладно бы софт был бесплатный, а железо собирал ты сам из подручных компонентов. В таком случае ещё можно как-то оправдать недельное вкуривание мануалов по настройке и оперированию. Но ты сначала купил софт для бекапа по цене чугунного моста, а потом ещё и здоровую СХД для интеграции, которая сожрала под два годовых бюджета. А сверху ещё и сеть отдельную проложил. Поэтому любому дураку понятно, что ничего сложнее Quick Start Guide читать не надо. Все эти толстенные мануалы, конечно, очень важны и полезны, но голова-то не резиновая. Нельзя в неё пихать всё подряд.

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

Также не вздумай вникать в подкапотное пространство тех приложений, которые понаставили на твои горячо любимые сервера. БД админ что-то там говорил о уже настроенных бекапах сторонним приложением? Ай, да не важно. Два бекапа всегда лучше, чем один. Тем более, что тебе надо настроить бекап вашего кластеризованного почтовика. Хотя чего там настраивать? Он же в кластере, и чего ему будет. Достаточно бекапить любую ноду и вся наука. Лучше пойти и переносом инфы на pass-through диски заняться.

Так что ничего сложнее операционки на уровне продвинутого сисадмина в памяти держать не надо. Тебе за это не платят.

Сейчас главное восстановиться, а куда и как - не суть важно

Если авария уже случилась, то первейшая наша цель - это восстановить данные и запустить критичные сервисы. Поэтому наш девиз в это тревожное время: Вижу цель, не вижу препятствий. Сейчас главное - скорость и быстрота реакции. Клик-клик - и вот уже бекап европейского сервера разворачивается где-то под Тверью. Не важно, что там дохлая площадка на полтора сервера, главное - побыстрее бы. Бекапы ведь именно там, значит и восстановится быстрее. Персональные данные европейцев? Ой, ну кому какая разница сейчас до ваших далёких GDPR и прочего. Нам же восстановиться надо. Хостинг в пять раз дороже, чем упавший? Да какая разница, потом мне ещё спасибо скажут за быстроту реакции. Мало места на дисках? Так вот это явно ерунда какая-то, можно и не восстанавливать. Сейчас главное - это восстановить прод!

Один для всех и все для одного!

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

Хорошо, возразят другие, это было про совсем уж критические системы, без которых встанет натурально всё. А что с теми, где действительно можно часик подождать? Например, почтовик или сайт, на который можно быстро выкатить извинительную заглушку? Здесь главное - тоже не поддаваться на уговоры параноиков и не начать городить Active-Passive системы. Там ведь есть гора своих проблем с синхронизацией, например. Можно, конечно, построить систему, которая будет делать снапшоты по расписанию и позволять быстро откатываться с минимальными потерями. Но это опять деньги на лицензии и железо, работающее вхолостую. И по большому счёту это риски теоретические и защищающие от авось.

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

Disaster Recovery Plan Шредингера

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

Вторые бумажной работы не боятся, тщательно всё документируют и в случае аварии шаг за шагом следуют плану. Ибо, как известно: если план подписал генеральный, значит, вся ответственность будет на нём, а сам план должен неукоснительно соблюдаться. Главное, чтобы этот документ напоминал локальную копию википедии: максимально подробные схемы включения абсолютно всего оборудования, схемы зависимости приложений, порядок загрузки машин, через какой порт кто с кем связывается, многочисленные проверки настроек и базовых тестов после включения. Словом, бюрократия 80 уровня. А если с последнего согласования были изменения или в середине отработки сценария всё пошло совсем не так, как описано, то это уже издержки производства. Виноватых найдём и покараем, главное - строго следовать плану. Больше бумаги чище все места.

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

Каждый должен знать своё место

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

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

Вот такие вот шесть вредных советов.

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

А какие вредные советы для коллег добавили бы вы?

Подробнее..

M2M и IoT ключевые технологии для современного бизнеса и потребительского рынка. Тренды М2М в 2021 году

11.01.2021 06:06:36 | Автор: admin
image

Переход от простых межмашинных подключений (M2M) к сложному Интернету вещей (IoT) идет полным ходом, поскольку улучшение LTE IoT и развитие сетей 5G обеспечивают более быстрые соединения и более высокие битрейты. M2M и IoT ключевые технологии для современного бизнеса и потребительского рынка. По мере того, как эти технологии продолжают развиваться, они открывают новые возможности для тех, кто понимает их и может эффективно использовать сильные стороны каждой технологии.

Технология M2M может быть лучшим выбором, если:
  • Ваше приложение требует двухточечной связи между машинами.
  • У вашего приложения есть ограниченный набор конкретных потребностей в машинной связи, которые необходимо выполнять быстро и надежно.
  • Ваше приложение должно работать независимо от того, доступно ли соединение Wi-Fi.
  • Быстрая масштабируемость не главная задача вашей сети
  • Сеть вашего устройства должна быть изолирована по соображениям безопасности.
  • Ваше приложение нужно синхронизировать с множеством разных устройств в сетевом облаке в реальном времени.
  • Ваши устройства имеют доступ к быстрому и надежному Wi-Fi-соединению.
  • Устройствам в вашей сети необходима возможность одновременной связи с несколькими другими устройствами.
  • Ваше приложение должно плавно и просто масштабироваться для большого количества устройств и пользователей.
  • Данные и устройства вашего приложения должны быть совместимыми с несколькими стандартами.

Рост М2М в мире


Интернет вещей (IoT) стал распространенной системой, в которой люди, процессы, данные и вещи подключаются к Интернету и друг к другу. По данным из годового отчета Cisco по Интернету M2M-соединения вырастут с 8,9 млрд (2020 год) и до 14,7 млрд к 2023 году.
image
Рост числа подключений M2M в мире

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

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

3 тренда M2M в 2021 году


Этот год и несколько следующих будут захватывающими для M2M. Аналитическое агентство Json & Partners Consulting отмечает следующие тенденций M2M, на которые стоит обратить внимание в этом году и в будущем:

1) 5G


Мгновенная связь, надежные сети, молниеносная скорость загрузки и передачи 5G произведет революцию в том, как потребители используют свои смартфоны, и окажет огромное влияние на все отрасли. По данным годового отчета Cisco по Интернету к 2023 году почти 60 процентов мобильных устройств и подключений во всем мире будут иметь поддержку 4G+, что в несколько раз превзойдет устройства и подключения с поддержкой 3G и ниже.

К 2023 году Северная Америка займет первое место по количеству устройств с подключением к сети 4G+, что составит 62%, в то время как Ближний Восток и Африка к этому времени будут иметь самую высокую долю своих устройств и подключений с поддержкой 3G и ниже, что составит 73%.

По прогнозам GSMA Intelligence количество соединений 5G в России достигнет 46 млн. к 2025 году, что составит 20 процентов от общего числа подключений. Исходя из этого, Россия превысит показатели среднемирового уровня, но все-таки не сможет перегнать Китай, США и Южную Корею на рынке 5G.

2) Терминалы оплаты


Согласно исследованию компании Juniper Research к 2022 году глобальное использование мобильных платежей увеличится на 28% из-за растущей популярности мобильных кошельков и онлайн платежей через приложения.
В 2019 году рынок POS-терминалов с поддержкой NFC показывал уверенный рост, где ежегодные мировые поставки достигали 47,8 млн. устройств. Сегодня производители ПО для POS-терминалов привлекают партнеров, для интеграции своих продуктов со сторонними платформами и увеличения базы пользователей.
Еще одна рекомендация специалистов для вендоров интеграция облачных сервисов с платформой электронной коммерции. Благодаря такому решению ритейлеры смогут использовать преимущества этих омникальных решений.

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

image
Источник: mypos.eu/en/glass

3) М2М в сельском хозяйстве


Технология M2M не только создает умные города будущего, но и производит революцию в сельскохозяйственном секторе. К 2050 году численность населения мира достигнет 9,6 миллиарда и умные методы ведения сельского хозяйства позволят нам прокормить постоянно растущее городское население, а к концу этого года интеллектуальное сельское хозяйство станет отраслью с оборотом 23 миллиона евро.

Технология M2M позволяет фермерам обеспечивать максимальную урожайность при минимальных ресурсах. Как? Датчики могут удаленно контролировать полевые условия, отслеживая данные по освещению, температуре и качеству почвы. А вот еще несколько примеров от компании Sierra Wireless, которые используются уже сегодня:
  • Зеленые дома контролируют микроклиматические условия, для увеличения производства фруктов и овощей.
  • Уход за виноградом мониторинг влажности почвы и диаметра ствола на виноградниках.
  • Для гольф полей выборочный полив засушливых зон для сокращения использования водных ресурсов.
  • Сеть метеорологических станций изучение погодных условий на полях.
  • Компост контроль уровня влажности и температуры в люцерне, сене, соломе.
  • Гидропоника контроль условий выращивания растений в воде
  • Для животноводства обеспечение выживания потомства и его здоровья.
  • Отслеживание животных расположение и идентификация животных, пасущихся на открытых пастбищах
  • Отслеживание уровня токсичных газов.

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

Как в MGA в 5 раз быстрее реализуют проекты при помощи GitLab

11.01.2021 12:12:41 | Автор: admin


Как в MGA в 5 раз быстрее реализуют проекты при помощи GitLab


Благодаря переходу на GitLab в MGA внедрили практики CI/CD, повысили качество ПО, создали процесс обмена знаниями и сэкономили средства.


Oбзор

В MGA перешли на GitLab с целью улучшения качества и сокращения сроков разработки с использованием автоматизированных процессов CI/CD.

Трудности

В MGA искали экономичную Continuous Integration платформу, которая позволила бы усовершенствовать рабочий процесс, расширить знания и повысить качество кода.

Pешение

GitLab EE

Преимущества

  • Автоматические сканеры кода в конвейере CI
  • Улучшенные возможности совместной работы
  • Повышение эффективности операционных процессов
  • Улучшение качества продуктов
  • Простота интегрирования

C 80 до 240 Увеличение объема проектов


10 В 10 раз больший коэффициент успешного выполнения, чем при ручном развертывании CD


80% Экономия времени при переходе на CD


Kлиент Разработчик корпоративного логического ПО


MGA разрабатывает, создает и внедряет компьютерные приложения для крупных и средних коммерческих и промышленных предприятий. Компания MGA, основанная в 1993 году, создала логическое программное обеспечение, которое использует преимущества реляционной базы данных (Oracle), работающей на операционной системе Linux. В 1999 году MGA создала подразделение аутсорсинга и начали предоставлять бухгалтерские услуги, кадровую поддержку и услуги по расчету заработной платы более чем 30 компаниям.

Tрудности Недостатки в совместной работе, поддержке и качестве кода


В MGA сами писали код и использовали Mercurial. Команда разработчиков протестировала бесплатные инструменты, которые позволяли проверять код и поддерживали CI и CD. Это оказалось сложным процессом, так как у программистов не было опыта в использовании подобных инструментов, а поддержка при их установке и применении не предоставлялась. У MGA возникли серьезные проблемы, поскольку Mercurial был слишком сложным, а у разработчиков не хватало опыта в использовании инструментов CI/CD.

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

Из-за невозможности совместной работы и отсутствия общего доступа к документации снижалось качество кода. Мы начали искать инструменты, которые позволяли бы нам просто осуществлять проверку кода и создавать политику утверждения для управления кодом. Вторым приоритетом было системное использование CI/CD с целью упростить работу и свести к минимуму штат администраторов, рассказывает главный ИТ-администратор Якуб Тадея.

У команд также возникали проблемы с распределением знаний. В MGA справочная информация хранилась на внутренних вики-сайтах, в задачах Redmine, записях от руки и некоторых приложениях. Ресурсы были разрозненны, неорганизованны и их было трудно найти. Новым сотрудникам приходилось самостоятельно разыскивать документацию о внутренних системах. ИТ-специалисты и разработчики MGA теряли время и деньги, не имея подходящих инструментов для решения всех проблем.

Pешение Динамичный инструмент по выгодной цене


В MGA протестировали различные инструменты. Обнаружив простой пользовательский интерфейс GitLab, в компании приняли решение перейти с Mercurial на GitLab. Еще одним аргументом в пользу GitLab был Deviniti официальный партнер GitLab в Польше. Проработав неделю с этим хорошо зарекомендовавшим себя партнером, в MGA окончательно решили продолжить работу с GitLab. Для покупки MGA требовалась польская валюта и польские счета. Большинство польских клиентов ищут местного партнера, который сможет продавать им продукцию, поясняет директор по продажам Deviniti Радослав Косец. Поддержка и знания местных особенностей со стороны Deviniti способствовали быстрому переходу MGA на новую платформу. В MGA до сих пор очень довольны партнерством. Работать с Deviniti одно удовольствие. Рекомендую!, добавляет Тадея.

Тарифный план GitLab подходил MGA больше всего. Это стало важным фактором в принятии окончательного решения. Мы зарабатываем меньше, чем компании на Западе Мы искали решение, которое бы позволило размещать приложения на нашем сервере. Насколько мне известно, GitHub и прочие облачные решения не позволяют этого сделать. Их невозможно использовать локально, поясняет Тадея.

До начала использования GitLab программисты работали в небольших командах над мелкими проектами. Но по мере роста компании увеличивались объемы проектов и численность команд. Внедренные инструменты уже не справлялись с такими масштабами. Благодаря GitLab, создание наших проектов полностью изменилось, утверждает Тадея. Первоначально у нас не было больших ожиданий. Нам просто был нужен новый инструмент, который дает возможность создавать конвейер CI/CD и политику проверку кода. Большего мы не ждали. Однако, как выяснилось, GitLab может предложить намного больше. Постепенно мы начали экспериментировать с функциями, и нам понравилось.

Благодаря GitLab, команды смогли планировать дорожную карту ПО и устанавливать сроки окончания проектов. Мы начали планировать проекты, используя непрерывную интеграцию и развертывание. GitLab полностью изменил архитектуру нашего решения, говорит Тадея.
У CD как минимум в 10 раз больший коэффициент успешного выполнения, чем у развертывания вручную. У нас есть проекты, где ни разу не подвело автоматическое развертывание. Якуб Тадея, Главный ИТ-администратор

Pезультаты Лучшие программы, больше разработчиков и единая база знаний


Успех с самого начала все шло как по маслу. В этом было самое большое преимущество, потому что мы легко установили GitLab и обновили его. Начать работу было очень просто, рассказывает Якуб. Подготовка серверов к переходу на GitLab заняла у MGA примерно неделю. В течение года все проекты перенесли в новый инструмент. Было очень просто начать работу. У нас не возникало никаких проблем, добавил Тадея.

До перехода на GitLab было 3 ИТ-администратора и 30 разработчиков. Теперь у нас более 60 разработчиков, которых легко обслуживают три ИТ-администратора, и много других серверов. Задержки больше не возникают, поскольку большая часть проблем больше не ложится на плечи ИТ-администраторов.

С начала использования GitLab количество проектов увеличилось с 80 до 240. В запущенных проектах все выполняется через CI и CD. По мере необходимости мы просто решаем проблемы и учим разработчиков пользоваться инструментами GitLab, поясняет Тадея. Теперь наша работа более эффективна, и мы можем уделять больше внимания коду, не отвлекаясь на простейшие задачи, которые можно автоматизировать.

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

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

Благодаря поддержке GitLab, MGA быстрее создает более качественные программы, улучшив процессы тестирования и проверки качества кода. ИТ-специалисты и команды разработчиков стали специалистами в области CI/CD и создают оптимизированные системы автоматизации, при этом сводя к минимуму потребности в ИТ-администрировании и повышая эффективность затрат.

Вся информация и лица, упомянутые в приведенном примере, соответствуют действительности на момент публикации.
Подробнее..

Вебинар Создание эффективной инфраструктуры при помощи облачных решений

12.01.2021 04:18:24 | Автор: admin


19 января в 19:00 приглашаем на бесплатный вебинар Создание эффективной инфраструктуры при помощи облачных решений. На вебинаре расскажем об отличиях облачной инфраструктуры от традиционного подхода. Обсудим вопросы:


Как работают облака и какие проблемы они решают?
В чем разница между IaaS, PaaS и SaaS?
Как Netflix обслуживает десятки миллионов подписчиков по всему миру?
Global Presence: ваш ЦОД в любом уголке планеты.
Flexibiltity: от ста серверов до тысячи и обратно за несколько минут, адаптивно к нагрузке.
Модели оплаты Upfront/Pay as you go.


Спикер


Александр Волочнев, Developer Advocate в DataStax Inc.


Certified Professional Cloud Architect
Автор международных курсов для IT-специалистов
Более 8 лет опыта разработки и внедрения облачных решений
Спикер на многочисленных международных конференциях


Записаться на вебинар

Подробнее..

Когда-то я внедрял ClickHouse в стартапе, где даже алерты мониторили индийцы это был Дикий Запад

13.01.2021 20:16:14 | Автор: admin

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

Чтобы мониторить сеть и сервера, можно использовать самый разный софт. Главное быть уверенным: если что-то пойдет не так, то сработает алерт. Вы увидите уведомление и успеете все починить. У них же было свое представление о мониторинге. Представьте, несколько комнат со столами, стульями и огромными плазмами на стенах, внутри сидят почти два десятка человек. На каждый монитор выведены разноцветные графики и рядом приклеены бумажки с номерами телефонов.

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

Покупка компании обошлась недорого, но содержание такой инфраструктуры стоило заоблачных денег. Индусы использовали дорогущую Vertica, где, кроме оплаты железа, нужно было еще отстегивать за лицензию. Мы решили попробовать переезд на ClickHouse. Это практически бесплатный аналог Vertica. Оба продукта работают по схожему принципу: колоночное СУБД с шардированием, с партиционированием данных.

И это было то еще приключение.


Киллер-фича ClickHouse конечно, экономия денег

Как раз то, что нам было нужно. ClickHouse умеет писать миллионы ивентов в секунду и также быстро читать. Если правильно организовать агрегационную таблицу в ClickHouse, она будет выполняться за минуту, когда в классических агрегационных базах (например, PostgreSQL) запрос выполняется час.

Я загорелся ClickHouse на одном кейсе, когда провел тест на сжатие с новенькими кодеками: тот же DoubleDelta ужал наши полуслучайные последовательности в пять раз! И ClickHouse не смущает количество данных, если подобрать правильный ключ сортировки и степень детализации индекса в настройках MergeTree.

В результате увидел, что данные, которые на HDFS занимали гигабайты, в ClickHouse уместились в 700 с хвостиком мегабайт, а скорость запросов по ним была на порядок выше. Особенно, когда получается удачно переписать стандартный хакерский SQL-запрос на тыщу строк во что-то максимально понятное ClickHouse, с использованием корректных встроенных функций, массивов, агрегатов и других подходящих альтернатив.

Но в то время у инструмента был большой минус высокий порог вхождения. Результат комбинации маленького на тот момент комьюнити, не сильно выходящего за пределы СНГ, фундаментальных отличий ClickHouse от обычных СУБД и невнятной документации. Приходилось проводить личные опыты: грузить в него TSBS и экспериментировать с функциями, разными версиями, настройками движков и так далее доходило даже до флагов компиляции. Драйвер существовал для галочки он использовал http-протоколы ненативно, просто обертка над Rest клиентом.

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


Как построить бэкенд так, чтобы ничего не падало, не сжирало тонну денег, могло хранить и обеспечивать доступ к отчетам?

При условии, что есть миллиарды строк данных, терабайты, километры.

Компания занималась монетизацией пираток. Человек пиратил андроид-приложение, не платил за него, но видел рекламу. Для того, чтобы посчитать клиента по биллингу, посмотреть, сколько он накликал рекламы, компания начала собирать статистику. До моего прихода там были написаны собственное SDK и бэкенд. PHP принимал JSON ивент, его парсили и писали в MySQL. Никаких пулов соединений не было, пришел ивент открыли и записали.

Когда нагрузка стала расти (несколько тысяч событий в секунду), эта система перестала вывозить. Бэкенд-разработчик узнал про Hadoop, HDFS и решил его применить. Собрали кластер из нескольких машин. Идея была такой: просто пишем JSON-файлы, запихиваем в Hive. И вот уже все считается и работает.

Когда ребята начали мигрировать биллинг на Hive, поняли, что у них резко вырос чек за кластер. Все хранилось в виде несжатых JSON-файлов. К тому же HDFS и Hadoop не были заточены на риал-тайм вычисления. Приходилось планировать любую джобу заранее. Ставили на всю ночь, утром видели результат в виде огромной кучи неструктурированных данных, которые лежат прямо в тексте. И все это за деньги! Скорость никакая, запрос делать долго, на выходе свалка. Это никого не устраивало.Когда я начал выяснять, как устроена текущая архитектура проекта, то оказалось, что Spark используется в автономном режиме на нескольких узлах, что выглядело подозрительным и специфичным. Разобравшись в скрипте запуска, я понял, что текущие настройки приводили к тому, что узлы грузились на все двести, а RDD все равно читались в один поток.

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

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

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

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

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

Но главная проблема оказалась не в самом ClickHouse а в том, что никто не мог сходу в нем разобраться

Если для того, чтобы научиться эффективно писать в ClickHouse и создать production-ready сервис, достаточно было только моих вложений, то с запросами и, в целом, с полноценным использованием DWH ситуация обстояла несколько иначе.

По опыту получалось, что задачи, которые отдел аналитики и разработчики раньше могли решить с наскока в каком-нибудь Hive или MySQL, в ClickHouse так сходу не решались где-то функцию надо использовать, где-то JOIN из-за дистрибуции данных некорректный и т.д.

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

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

Например, можно вспомнить раннюю поддержку UUID, когда запрос вида:

```SELECT * FROM db PREWHERE uuid != '00000000-0000-0000-0000-000000000000'```

Приводил к segfault.

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


А потом оказалось, что данные из ClickHouse слишком трудно визуализировать

Тот же Hive предлагал инструменты, которые позволяли писать запросы и делать визуализацию. Поначалу мы использовали Tabix. Это довольно примитивный клиент, он ходит напрямую в ClickHouse и отображает в браузере результат в виде таблички и простых графиков. Но в итоге взяли инструмент поинтереснее. Redash как раз выкатил бета-версию поддержки ClickHouse.

Параллельно у нас появилась часть данных на базе Redshift. В какой-то момент компания предложила брать данные из ClickHouse и перекладывать в Redshift (который, по сути, обычный SQL и можно использовать инструменты желанной визуализации). Но идея отпала сама собой я просто посчитал, сколько будет стоить кластер Redshift, который поддержит такой поток данных с ClickHouse. Мы тратили около тысячи долларов, если бы заморочились с Redshift платили бы все 30 тысяч. Поэтому продолжили работать с ClickHouse через Redash.

Но все пошло прахом, когда мы решили прикрутить к ClickHouse Tableau и в итоге влетели на 70 тысяч долларов!

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

Но наш аналитик настаивал. Ему нравился Tableau красивый, понятный, никаких тебе запросов SQL делать не надо, все кнопочками. И нам его все же купили. Потратили около 70 штук и принялись танцевать с бубном вокруг покупки.

Мы даже созвонились с продажниками из Tableau и убеждали их подружить свой продукт с новейшей российской технологией. Уже тогда было понятно, что ClickHouse потихоньку завоюет весь мир. Они лишь вежливо выслушали нас. Что забавно, недавно Tableau сделал кое-какую поддержку драйвера для ClickHouse. Не прошло и двух лет!

Перевести отчеты с Redash на Tableau у нас так и не получилось деньги улетели на ветер. Хорошо, что к тому моменту часть сотрудников освоила ClickHouse я потихоньку всех обучал. Оказалось, что он удобен для андроид-разработчиков и предлагает даже больше возможностей, чем красавчик Tableau.


Самая большая проблема ClickHouse в нем никто не шарит. Там много подводных камней, которые нигде не описаны. Хорошая технология с плохой документацией.

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

Сейчас он стал сильно проще, но это по-прежнему не тот продукт, которым можно пользоваться сразу из коробки. Зато когда он таким станет всяким Vertica и Redshift можно будет сворачивать свой бизнес.

Подробнее..

Рецепт дня готовим сообщество профессионалов, не выходя из своего отдела

14.01.2021 10:07:09 | Автор: admin

Историями о профессиональных сообществах сейчас вряд ли кого-то удивишь. Гильдии образуют по разным причинам: кто-то из интереса, кто-то чтобы быть в тренде, а кто-то из-за недостатка общения на профессиональные темы. Это история о том, как бизнес-направление компании ЦФТ, Денежные Переводы Online, желая производить больше и быстрее, в очень короткий срок утроило штат инженеров, которых не успели нормально заонбордить, и в итоге чуть не уронили качество продукта и не сожгли ключевых членов команды.

Доклад в виде пошагового рецепта QA-лидам, fullstack feature team-лидам, SM и всем тем, кто решает задачу эффективной настройки процессов команд, представила на конференции TeamLead Conf 2020 Head of Android QA одного из флагман-продуктов компании ЦФТ Надежда Потаенко.

Продукт ЦФТ Золотая Корона в 2016 году прочно стояла на позиции самой крупной системы денежных переводов без открытия счета на территории России и СНГ. В момент, о котором пойдет повествование, у пользователей появилась возможность начать отправлять переводы не только офлайн, но и через веб и мобильные фронты.

И команду разработки начало потихонечку взрывать, потому что в эти мобильные фронты резко устремились несколько миллионов активных клиентов.

Стало понятно, что продукт взлетел, и его надо срочно развивать. Именно высокая востребованность продукта заставила ЦФТ очень быстро вырасти. За три года команда разработки продукта Денежные Переводы Online увеличилась с 7 до 200+ человек. В какой-то момент старые производственные процессы просто перестали работать. Сотрудники вынуждены были отправиться на поиски новых конфигураций.

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

Для кого готовим?

Гильдия, о которой мы поговорим это 25 QA Android инженеров. Если вы не имеете отношения к качеству, это не страшно. Рекомендации, которые вы увидите здесь, легко портируются как на команду разработки, так и на команду аналитики. Информация может быть полезна даже agile-гуру и вообще всем людям, которые ищут точку опоры для создания профессионального сообщества, но пока что ее не нашли.

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

Что было в холодильнике?

Шел 2016 год, и в компании стал развиваться продукт, который начал активно зарабатывать деньги. Ранее этот продукт разрабатывала сравнительно небольшая команда из 20 человек (4 компонентные команды: Backend, Web, iOS, Android), все сидели в славном городе Томске и были экспертами в продукте. Казалось, все идет просто идеально!

Но как это часто бывает, заказчик с этим согласен не был. В 2017 году он начал задавать вопросы о том, почему продукт так долго релизят?

Так много и быстро производить не получалось просто не хватало рук. ОК, просили получайте!

Настал 2018, и боги провозгласили год найма и новых рук. Компания начала расти, причем не только в Томске, но параллельно в Новосибирске и в Питере. На графике видно, что в конце 2018 появилось 130 инженеров в 3 локациях, а в 2019 их стало больше 200. Это около 30 команд, которые сейчас совместно пилят один и тот же продукт: Денежные Переводы Online.

От такого роста ожидали увеличение скорости разработки и сокращение TTM, но получили совершенно иную картину.

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

Почему так получилось? Команда разработки росла быстрее, чем в ней адаптировались процессы.

  • Не успевали качественно онбордить

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

  • Разный уровень hard skills в разных локациях

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

Например, в Томске инженеры предпочитали вести тестовую документацию в виде чек-листов и подробно там ничего не расписывать. В Питере считали, что это хаос и вред, и каждое ответвление flow должно быть покрыто стопочкой тест-кейсов.

Другой пример: в Новосибирске инженеры считали, что побегать за аналитиком и дожать из него недостающую информацию это ОК. В Питере ребята сказали: Ну нет! Должен быть четкий Definition of Ready. Мы ни за кем бегать не будем!

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

  • Релизила по-прежнему одна команда

Главная боль всего 2018 и части 2019 года заключалась в том, что несмотря на увеличение количества команд, которые в изоляции друг от друга производили вполне годные фичи, стабилизацией, сборкой, багфиксингом, поставкой в прод занималась по-прежнему одна и та же релиз-команда. Конечно, она не могла качественно пропустить через себя такой объем производства.

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

В какой-то момент Надежда поняла, что надо спасать коллег по цеху.

Шаг 1: Перемешать и поставить на плиту

Первым шагом стало привлечение к процессу регрессионного тестирования и вообще к релиз-производству QA инженеров из фича-команд, которые раньше в этом процессе не участвовали, для того, чтобы:

  • Повысить степень причастности и ответственности;

  • Выровнять уровень понимания бизнес-логики продукта.

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

Шаг 2: Довести до кипения

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

Например, что-то тестили, попали на незнакомый flow, испугались, завели баг, кинули его в чат Android: кто-нибудь потом разберется. А на самом деле просто заехала новая фича, поменялся flow, а тест-кейсы еще не актуализировали.

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

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

Как тушить все это, было непонятно.

Шаг 3: Остудить, еще раз перемешать

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

  • Выработать единый подход к регрессу;

  • Найти способы ускорить регресс;

  • Восстановить качество релизов;

  • Делиться друг с другом экспертизой в продукте.

Все QA в команде Денежных Переводов Online находятся в своих фича-командах. В каждом спринте у них есть собственные sprint goal. Но понимания, зачем QA-инженеры из этих обособленных фиче-команд раз в две недели собираются все вместе в трех локациях, чтобы кому-то помогать, ни у кого не было. Надежда решила начать сначала, и собрать всех очно в одной локации.

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

А еще ей хотелось сформулировать цель совместной работы.

Летом 2019 года все собрались и познакомились, после чего родилась цель: выпускать качественный продукт быстро, чтобы заказчик и пользователи были довольны.

Качественно и быстро это отсылки к желаемому сокращению ТТМ и к восстановлению уровня качества.

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

Мозговой штурм был построен на базе книги 5 пороков команды Патрика Ленсиони. И на него было потрачено около 8 часов.

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

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

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

Шаг 4: Выпекать до готовности

В команде Денежных Переводов Online договорились проводить регулярные встречи гильдии раз в 2 недели.

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

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

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

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

Канал коммуникации очень простой: QA-инженеры раз в две недели встречаются онлайн в Microsoft Teams.

За счет таких встреч им удалось выработать единый подход к регрессу и найти способы ускорить его.

Осторожно! Горячо!

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

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

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

Шаг 5: Сбрызнуть соком лимона

Сообщество - это не всегда только про решение проблем. Это неизбежно история про обучение и QA-сообщество ДП Online не исключение. Например, кто-то хочет научиться пользоваться снифферами, а кто-то мечтает, чтобы ему объяснили, как безболезненно протестировать пуши на интеграции. Такие запросы есть всегда. Самое главное, что по востребованным темам есть эксперты, и нужно лишь решить вопрос формата подачи информации.

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

В команде появился такой wishlist:

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

Но проблемы начались с самого первого митапа.

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

С тех пор в команде договорились, что все на 100% должны четко понимать, что именно будет обсуждаться.

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

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

Шаг 6: Дать отдохнуть

В ДП Online решили отправлять сотрудников в командировки для того, чтобы они начали встречаться не только онлайн, но и лично. Когда появилась страничка графика поездок, очередь туда выстроилась до конца 2020 года. И все, естественно, хотели в Питер, ведь две другие локации находились в Сибири.

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

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

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

Профиты командировок:

  • Для продукта: быстрый шаринг экспертизы;

  • Для инженеров: сменить обстановку, пообщаться с иногородними коллегами.

За счет командировок сотрудникам QA-сообщества ДП Online удалось выработать единый подход к регрессу и найти способы ускорить его, восстановить качество релизов и делиться друг с другом экспертизой в продукте.

Что дальше?

В 2020 году в ЦФТ появились новые цели саморазвития гильдии.

  • Коммуникация с QA-гильдиями других платформ продукта;

Если в 2019 году сотрудники команды притирались и учились друг с другом общаться, то сейчас внутри Android community очень теплая и уютная атмосфера. Но там готовы раздвинуть границы и подсмотреть, что происходит у других сообществ. Уже запланированы встречи кросс-платформенного community.

  • Ежемесячные публикации блога с обзором новостей платформы и сообщества.

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

Есть и продуктовые цели.

Если раньше в ДП Online существовал басфактор в виде единой выпускающей команды, то теперь он исчез. Тем не менее, процесс релиза непрозрачный, очень тяжело онбордить в него людей. Поэтому стоит цель однозначно работать над его упрощением и над снижением порога входа в проект автотестирования. А еще могут потребоваться новые hard skills, ведь продукт компании динамичный.

Выводы в цифрах и фактах

На картинках активности, которые пробовали применять в QA-сообществе ДП Online.

Рост качества, произошедший на почве работы сообщества, напрямую отразился на количестве hot fixов на число выпущенных версий.

И немного статистики релизов продукта за 2018-2019 годы. Внизу красным подсвечены hot fixы. В 2018 году в ДП Online было нормой раз в 3-4 релиза выпустить hot fix. С 2019 года, когда начала собираться гильдия экспертов, hot fixов почти нет. За весь 2019 год выпустили всего 4. Причем речь не о клиентских, а о технических hotfixах, например, когда какое-то событие было потеряно в Google Analytics.

Кроме того, активности, которые были направлены на решение продуктовых проблем, принесли несколько положительных сайд-эффектов:

  • Тюнинг soft skills;

  • Единое информационное поле;

  • Здоровая конкуренция;

  • Новые лиды.

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

Программный комитет Saint TeamLead Conf 2021 ждет ваши доклады.

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

Присоединяйтесь!

Подробнее..

Перевод Сервер Prometheus и TLS

15.01.2021 16:07:39 | Автор: admin


Prometheus теперь поддерживает TLS и базовую аутентификацию для HTTP эндпоинтов.


Скрейпинг таргетов через HTTPS вместо HTTP поддерживается уже давно. Метрики можно собирать с поддержкой HTTPS, аутентификации по клиентским сертификатам и базовой аутентификации.


В прошлом году Node Exporter стал первым официальным экспортером, который нативно предоставляет метрики по HTTPS. Все подробности в предыдущем посте. На этой неделе (прим. переводчика: статья вышла 6 января 2021 года) мы встречаем Prometheus 2.24.0. В последнее время Prometheus радует нас крутыми новшествами это и TLS, и backfilling (обратное заполнение, тоже в версии 2.24) и даже переход на современный пользовательский интерфейс на React.


В этом посте мы расскажем о TLS и базовой аутентификации.


Здесь можно узнать больше о модели безопасности Prometheus и о том, как пожаловаться на уязвимости.


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


API для администрирования и управления жизненным циклом


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


При этом нужно будет защитить порт Prometheus, например, с помощью аутентификации.


Защита доступа к Prometheus


Раньше между клиентами и сервером Prometheus для защиты обычно ставили обратный прокси:



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


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



Как настроить TLS


Посмотрим, как это работает на практике, на примере Prometheus на Linux.


Настройка рабочего каталога


Мы будем работать в отдельном каталоге:


$ mkdir ~/prometheus_tls_example$ cd ~/prometheus_tls_example

Создание TLS-сертификатов


Для начала создадим самоподписанный TLS-сертификат.


$ cd ~/prometheus_tls_example$ openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout prometheus.key -out prometheus.crt -subj "/C=BE/ST=Antwerp/L=Brasschaat/O=Inuits/CN=localhost" -addext "subjectAltName = DNS:localhost"

Здесь localhost это имя хоста для сервера Prometheus.


Создается два файла: prometheus.crt и prometheus.key.


Веб-конфигурация Prometheus


Скачиваем Prometheus v2.24.0, распаковываем, переносим сертификаты, которые создали выше:


$ cd ~/prometheus_tls_example$ wget https://github.com/prometheus/prometheus/releases/download/v2.24.0/prometheus-2.24.0.linux-amd64.tar.gz$ tar xvf prometheus-2.24.0.linux-amd64.tar.gz$ cp prometheus.crt prometheus.key prometheus-2.24.0.linux-amd64$ cd prometheus-2.24.0.linux-amd64

Сейчас нужно создать новый файл конфигурации. Мы не будем настраивать TLS и аутентификацию в основном файле конфигурации prometheus.yml. Это позволит нам перечитывать отдельный файл конфигурации при каждом запросе, чтобы на лету подхватывать новые учетки и сертификаты.


Создадим файл web.yml с конфигурацией TLS:


tls_server_config:  cert_file: prometheus.crt  key_file: prometheus.key

Запускаем сервер Prometheus, указывая --web.config.file в командной строке:


$ ./prometheus --web.config.file=web.yml[...]enabled and it cannot be disabled on the fly." http2=truelevel=info ts=2021-01-05T13:27:53.677Z caller=tls_config.go:223 component=webmsg="TLS is enabled." http2=true

Если мы видим это сообщение, сервер Prometheus запущен с поддержкой TLS.


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


Подробности об этом дополнительном файле конфигурации смотрите в документации.


Проверка конфигурации TLS вручную


В curl проверим конфигурацию TLS. В новом терминале запустим пару команд для теста:


$ cd ~/prometheus_tls_example$ curl localhost:9090/metricsClient sent an HTTP request to an HTTPS server.$ curl --cacert prometheus.crt https://localhost:9090/metrics[...]

Вместо --cacert prometheus.crt можно передать -k, чтобы пропустить проверку
сертификата в curl.


Конфигурация скрейпа


Настроить TLS выборочно не получится если он включен, он распространяется на все эндпоинты. Это значит, что собственные метрики Prometheus тоже будет извлекать через TLS, поэтому настроим использование HTTPS.


Изменим задание prometheus в файле prometheus.yml:


global:  scrape_interval:     15s  evaluation_interval: 15sscrape_configs:  - job_name: 'prometheus'    scheme: https    tls_config:      ca_file: prometheus.crt    static_configs:    - targets: ['localhost:9090']

Для tls_config и scheme установим https. Полный список параметров клиента tls_config см. в конфигурации Prometheus.


Перечитаем конфигурацию Prometheus:


$ killall -HUP prometheus

Откроем https://localhost:9090/targets локально в браузере и увидим https://localhost:9090/metrics в списке таргетов.


Таргет имеет статус UP? Ура! Мы настроили TLS для сервера Prometheus и теперь собираем метрики с шифрованием.


Как настроить базовую аутентификацию


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


Веб-конфигурация


Для начала создадим хэш паролей (с помощью bcrypt). Для этого используем команду htpasswd (пакет apache2-utils или httpd-tools есть в дистрибутиве; если это не продакшен, можно найти генераторы bcrypt онлайн).


$ htpasswd -nBC 10 "" | tr -d ':\n'New password:Re-type new password:$2y$10$EYxs8IOG46m9CtpB/XlPxO1ei7E4BjAen0SUv6di7mD4keR/8JO6m

Для примера возьмем пароль inuitsdemo.


Добавим пользователя в файл веб-конфигурации Prometheus web.yml:


tls_server_config:  cert_file: prometheus.crt  key_file: prometheus.keybasic_auth_users:  prometheus: $2y$10$EYxs8IOG46m9CtpB/XlPxO1ei7E4BjAen0SUv6di7mD4keR/8JO6m

Примечание: В этом файле prometheus это имя пользователя.


Если Prometheus еще запущен, введите пароль для доступа к веб-интерфейсу по адресу https://127.0.0.1:9090, иначе на странице targets для таргета будет отображаться ошибка 401 Unauthorized.



Конфигурация Prometheus


Изменим prometheus.yml, чтобы поскрейпить имя пользователя и пароль.


global:  scrape_interval:     15s  evaluation_interval: 15sscrape_configs:  - job_name: 'prometheus'    scheme: https    basic_auth:      username: prometheus      password: inuitsdemo    tls_config:      ca_file: prometheus.crt    static_configs:    - targets: ['localhost:9090']

Перезагрузим конфигурацию Prometheus сигналом SIGHUP:


$ killall -HUP prometheus

Если все работает, Prometheus снова откроет страницу targets.



Promtool


У Prometheus есть свой инструмент командной строки promtool, которым теперь можно проверять и файлы веб-конфигурации:


$ ./promtool check web-config web.ymlweb.yml SUCCESS

Используйте любой инструмент автоматизации для удобного обновления файлов web.yml.


Grafana


Grafana поддерживает все необходимые функции для подключения к серверу Prometheus. Можно указать CA (наш prometheus.crt) или пропустить проверку сертификатов.



Заключение


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


В следующие несколько месяцев мы планируем развернуть эту поддержку HTTPS по всем официальным экспортерам Prometheus и другим проектам, например, Alertmanager, Pushgateway.


Мы за безопасный мониторинг.


От редакции: Подробнее о работе с Prometheus можно узнать на курсе Слёрма Мониторинг и логирование инфраструктуры в Kubernetes. Сейчас курс находится в разработке и его можно купить по цене предзаказа.


Полезные ссылки


Prometheus 2.24.0
Модель безопасности Prometheus
Документация по конфигурации TLS-сервера (для Prometheus)
Документация по конфигурации TLS-клиента (для сервера Prometheus)

Подробнее..

Категории

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

© 2006-2021, personeltest.ru