Гибкий офис

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

 Почему Apache Kafka?

 Apache Kafka — это унификация. Десятки поставщиков и потребителей, миллионы сообщений в день и огромные массивы данных — для этого нужна надежная, отказоустойчивая и высокопроизводительная шина данных. Существует множество версий дистрибутивов Apache Kafka, например vanilla kafka, oбразы от confluent, bitnami, wurstmeister и т.д. Мы расскажем про решение на базе сборок от Confluent в виде Docker-образов. Оно самое надежное в плане информационной безопасности. Конфигурирование и запуск контейнеров с Kafka в данном случае происходит с помощью docker-compose.

 За время работы с Kafka мы прошли  путь от «коробочного» решения до тонкой настройки безопасности кластера, применения TLS шифрования и разворачивания по рекомендациям вендора по построению геораспределенного кластера. В конфигурации «из коробки» нет первоначальных настроек безопасности. Для контроля доступов, вносимых изменений и безопасного взаимодействия перед нами встала задача настройки на кластере Apache Kafka TLS шифрования, аутентификации и авторизации средствами встроенного ACL.

 TLS шифрование

Обеспечивает шифрование соединения между брокерами Kafka, серверами Zookeeper, клиентами и брокерами. Вся ключевая информация помещается в хранилища — keystore, которые разделяют на два вида:

• keystore, где хранятся ключи и сертификаты стороны, в отношении которой пройдет процедура аутентификации и установления защищенного соединения, например, приватный ключ и ассоциированный с ним и подписанный со стороны центра сертификации (ЦC) сертификат.

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

В статье пойдёт речь об опыте построения процессов CI/CD в Национальном расчетном депозитарии (НРД) в разработке под ЦФТ-Банк. В качестве введения рекомендую ознакомиться с предысторией того, как мы перевели разработку ЦФТ-Банк на CFT Platform IDE. Новая статья — её логическое продолжение и ориентирована на разработчиков, знакомых с основными возможностями CFT Platform IDE.

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

Мы расскажем про опыт НРД — центрального депозитария РФ. НРД хранит активы на сумму более 60 трлн руб. и аккумулирует практически весь рынок ценных бумаг в России. Основной бизнес сфокусирован на надежности: хранение, проведение расчетов, отчетность.

Если вы тоже задаетесь похожими вопросами или вам знакомы слова финансовый бэк-офис, добро пожаловать под кат.

На днях у меня появилась довольно интересная идея для статьи, основанная на следующей предпосылке: на Хабре ни разу не рассказывали об организации энтерпрайз разработки "от и до". В плане совсем с нуля и хотя бы до комфортного минимума. За отправную точку я буду брать ситуацию полнейшего хаоса, когда какой-то код существует на машине единственного разработчика, нет системы контроля версий, нет тестовых сред, код объектов БД существует только внутри эталонной продуктивной базы данных, нет никаких процессов сборки и установки, контроля качества кода и так далее. Возможно читатель задастся вопросом "Такое бывает в 2020 году? Разве кто-то еще так разрабатывает?" и будете только отчасти правы. Предлагаю обсудить детали под катом.

Финансовые компании находятся в поисках лучших решений, которые оптимизируют внутренние процессы разработки, разовьют IT-инфраструктуру в соответствии с требованиями бизнеса и позволят им выводить на рынок лучшие конкурентные продукты. Так, два года назад мы ступили на путь перевода разработки ЦФТ-банк на платформу CFT Platform IDE. Среди коллег по цеху ходят слухи, что это процесс невероятной сложности, ввиду чего не решаются приступить к делу. На своем примере мы докажем, что это вполне подъемный процесс и для вашей команды.

Интро

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

С другой стороны, есть много статей о решении задач машинного обучения на примере нескольких публичных затертых до дыр датасетов: MNIST, IMDB, ENRON, TITANIC. С ними ситуация обратная — все вершины уже покорены, алгоритмы известны, можно добиться рекордных цифр даже на простеньком ноутбуке. Снова мимо. Гораздо сложнее найти материал о практическим применении МО для решения повседневных задач. Данная статья, как можно догадаться, как раз из этой серии. На подробном практическом примере попробуем выяснить, можно ли собрать личного интеллектуального помощника (пусть и узкоспециализированного), сложно ли это, какие знания нужны и какие проблемы подстерегают на этом пути.