В новой статье рассмотрим основы CI/CD и познакомимся Jenkins. Вы узнаете, где применяется Jenkins и какие проблемы помогает решить, поймёте логику архитектурных решений и особенности структуры каталогов. А ещё научитесь устанавливать Jenkins и производить базовую конфигурацию.
За основу статьи взят первый урок нашего практического курса «CI/CD с Jenkins».
Привет, Хабр! Меня зовут Денис, и я занимаюсь интеграциями систем ЦОД и учетом оборудования клиентов. Сегодня я хочу рассказать, как мы автоматизировали выдачу пропусков в наши ЦОДы с помощью нейронных сетей. Расскажу немного о самой системе, из чего она состоит и как работает, а также о том, какую выгоду получили наши клиенты.
Миграция базы данных 1С с MS SQL на PostgreSQL – по-прежнему насущная тема, особенно в контексте импортозамещения. На наших вебинарах и в беседах с клиентами мы получаем много вопросов по нюансам миграции. Решили собрать основные рекомендации в одну статью.
Спикер курса «CI/CD на примере Gitlab CI», Lead DevOps в Naviteq (ex. Onesoil and EPAM) Александр Довнар, рассказывает про CI, CD и еще раз CD.
Александр — AWS Community builder и сертифицированный архитектор, соведущий подкаста DevOps Kitchen Talks. 11+ лет работает в IT и сетях, из них 7+ лет — в Devops.
Эта статья — расшифровка вебинара, где Александр рассказывает, что за зверь CI/CD, кому и когда он нужен и зачем применять его в команде, а также обсуждает текущие проблемы индустрии вокруг этой практики.
На хайпе нейронных сетей особую популярность приобрели end-to-end системы распознавания речи. И это неудивительно, ведь можно «просто» взять нейронную сеть известной архитектуры, скормить ей обучающий датасет и ждать результата. Но на практике все оказывается не так просто.
В этой статье мы попробуем рассказать, почему несмотря на эксперименты с нейронными end-to-end сетями, мы продолжаем использовать гибридную архитектуру, состоящую из акустической и лингвистической модели, работающих независимо и в чем заключаются достоинства и недостатки разных архитектур распознавания речи.
Планирование спринта является ключевым элементом работы в Scrum. Тем не менее, это все еще проблематичное и часто поверхностное событие для многих групп. Основываясь на своем опыте, я подготовил пять советов, которые помогут вам лучше спланировать свой следующий спринт.
Давно собирался написать данную статью и представить свое видение в отношении Технологии информационного моделирования (ТИМ). ТИМ имеет бесчисленное множество преимуществ при реализации, и в случае достижения результативности внедрения во все субъекты строительной отрасли можно будет наконец-то поставить жирную точку в вопросе бесконтрольности строительных процессов. Не знаю, когда удастся превратить ТИМ в привычную технологию, но …
… разве я спроста провожу параллель с Апокалипсисом?! Когда грядет тот миг воцарения цифры в стройке, тогда мир не будет прежним! Слишком фанатично. Согласен. Наяву внедрение информационных технологий происходит очень медленно, болезненно и туго, поэтому такой расклад на практике не воодушевляет и не наращивает инициатив в развитии. Но стоит представить, как эти идеи воплощаются в жизнь, сразу хочется взять и сделать чертежи в BIM (хах, нет).
Материал заботливо подготовлен на основе перевода части книги Go With The Domain, а именно — главы 9 «Чистая архитектура» за авторством Miłosz Smółka.
В этой части говорится о том, как из wtf-кода прийти к чистой архитектуре с помощью сочетания двух идей: разделении портов и адаптеров + ограничении того, как структуры кода ссылаются друг на друга.
Любому надёжному конвейеру потоковой обработки данных нужны механизмы обнаружения и обработки ошибок. В этой статье вы узнаете, как реализовать обработку ошибок с помощью очереди недоставленных сообщений (Dead Letter Queue) в инфраструктуре Apache Kafka.
Мы рассмотрим несколько вариантов: кастомная реализация, Kafka Streams, Kafka Connect, Spring Framework и Parallel Consumer. Вы увидите, как Uber, CrowdStrike и Santander Bank реализуют надёжные механизмы обработки ошибок в реальном времени и в огромном масштабе.
В последние годы среди организаций, живущих философией DevOps и SRE, стал популярен подход “всего как кода”. Особенно часто он встречается при управлении инфраструктурой. Направление IaC (infrastructure as a code), где ручная настройка заменяется использованием скриптов, появившись в ответ на растущую виртуализацию данных, превратилось в IT-стандарт и неотъемлемую часть DevOps. Представление инфраструктуры в виде кода обеспечивает её гибкость и масштабируемость, автоматизирует ручные задачи, минимизирует риск человеческого фактора и позволяет эффективнее использовать существующие ресурсы. Но рука об руку с инфраструктурой идёт и её мониторинг, а потому резонным является вопрос о том, как на нём отразилась описанная выше концепция.
В этой статье я расскажу про такой подход как Monitoring as a Code и покажу его реализацию на примере нашей платформы для мониторинга и автоматизации Monq 7.0.
Значение данных для эффективного управления организацией расчет с тех пор как больше ста лет назад Фредериком Уинслоу Тейлором были заложены основы научной организации труда. Появление компьютеров позволило вывести их обработку и использование на принципиально новый уровень. Объем используемых человечеством данных растет по экспоненте. По прогнозам экспертного сообщества их объем уже через три года (в 2025 году) достигнет 180–200 Зеттабайт.
Ручная обработка больших объемов информации практически невозможна и мы вынуждены все больше полагаться на сложные алгоритмы обработки, подготовки и анализа. Агрегация данных становится все более и более высокоуровневой, десятки и сотни миллионов записей в базах данных сводятся машинами в одностраничную табличку, на основе которой принимаются стратегические решения.
Но ошибки в исходных данных вызывают ошибки в расчетах производных, в лучшем случае алгоритмы оказываются неспособны их обработать и процесс аварийно останавливается, а в худшем – менеджер получает результат анализа, не осознавая, что ошибки привели к абсолютно неадекватному результату. Образно говоря, он начинает грызть футбольный мяч, будучи уверен, что это арбуз.
Здесь мы приходим ко вполне предсказуемому, но все еще неочевидному для многих выводу: управление современной организацией невозможно без создания системы управления данными и, в частности, системы управления КАЧЕСТВОМ данных.
Каждая компания, принимающая платежи на своем сайте или в магазине, рано или поздно сталкивается с фродом (fraud) и несет убытки. Есть разные методы борьбы с ними. 80% всех задач обычно решаются скриптами, а потом к ним уже докручивается дата-сайнс. Правда не всегда понятно для чего. Но давайте пока не будем останавливаться на этом, а попробуем решить типичные проблемы. Такие, как сбор данных, долгий этап оценки гипотез и снижение нагрузки на внешние системы.
Меня зовут Александр Сальков. Я разработчик в Sportmaster Lab. Руковожу направлением дата инженерии и больше 10 лет разрабатываю базы данных и все системы, которые так или иначе с ними связаны. Когда я был молод, написал свой вариант Кафки, который делал то же самое, что делает Кафка, только между инстансами Oracle. Участвовал во всяких разных датасаентистских вещах. В частности, делал систему идентификации людей по венам на ладонях. И много всякого интересного.
Привет, Хабр! На связи Михаил Семёнов, лидер дивизиона баз данных в СберТехе, Артём Лаптев, руководитель эксплуатации продукта Platform V Pangolin в SberInfra, и Вячеслав Гавришин, руководитель команды развития Platform V Pangolin в SberInfra.
В этой статье мы поделимся историей импортозамещения систем управления базами данных в Сбере и опытом миграции с MSSQL и Oracle на собственную СУБД Platform V Pangolin. А ещё расскажем, как разрабатываем и кастомизируем отечественную СУБД уровня enterprise. Кроме того, покажем, какие решения помогли нам упростить процесс миграции и использовать продукт в микросервисной архитектуре Банка. Если вам это близко ― просим под кат!
Примечание: Большинство этих событий неспецифичны для Kubernetes и должны быть знакомы пользователю, за исключением проблемы с отсутствием ресурсов на ноде.
Недавно к нам обратился клиент из страны бывшего СССР. Он организовал свободный доступ к Wi-Fi на городском пляже. Были выполнены изыскания, обследована местность, смонтировано оборудование и торжественно перерезана красная ленточка, но качество сервиса оказалось неудовлетворительным: частые обрывы соединения, низкая скорость и недостаточная зона покрытия. В ходе разбирательства выяснилось, что никаких обследований местности ни до развертывания, ни после не производилось, реализация проекта основывалась только на моделировании RSSI, а все работы по факту выполнял подрядчик.