User
Друзья, рад представить вам свою новую статью, посвященную Playwright — мощному инструменту для автоматизации браузера и тестирования. Этот фреймворк уже превзошел Selenium по многим параметрам и продолжает набирать популярность. В статье я подробно рассказываю о его преимуществах и особенностях.
Материал станет первой частью нового цикла. Если тема вам интересна, с удовольствием продолжу делиться своими знаниями о Playwright.
Трейсинг (возможность отслеживания пути запроса между сервисами в микросервисной архитектуре) - критический важное требование функционирования более-менее крупных систем.
У Uber - тысячи микросервисов. А у Netflix - несколько тысяч
В каком сервисе возникла ошибка? Сервис упал или просто ошибка сети? Что за ошибка возникла?
Стоп!
Рим не за один день был построен
Поэтому начнем с малого и подключим трейсинг к обычной микросервисной системе на ASP.NET Core.
Поможет нам в этом OpenTelemetry
Да, эта тема обсуждалась уже не раз, но мы хотим показать именно наш, более комплексный подход. В большинстве статей рассказывается именно о узконаправленных проблемах мониторинга и вариантах их решения, мы же хотим рассказать о пройденном пути, полученных результатах и наших планах.
Мы работаем в большой компании, где требования к производимому ПО очень высоки. Наши сервисы без сомнения можно назвать высоконагруженными системами.
Об элементах инфраструктуры и её производительности коллеги уже рассказали в статьях Как мы мониторим наши сервисы и Как мы переводим наш мониторинг в наблюдаемость, так что сейчас на этих темах останавливаться не будем.
Сборная солянка из существующих best practices по работе с Grafana и немного с Prometheus, проверенных мной лично. Можно просто положить в закладки — когда-нибудь да пригодится.
Компания Hostkey предоставляет серверы в аренду — это накладывает на нас, сотрудников компании, обязательства по контролю качества работы оборудования. Одним из ключевых элементов поддержания большой инфраструктуры является эффективная система мониторинга, позволяющая оперативно выявлять сбои в работе серверов. Мы хотим поделиться нашим опытом внедрения и использования различных инструментов, позволяющих отслеживать работу оборудования.
В этой статье мы кратко рассмотрим варианты установки федерации Prometheus, Alertmanager и Node Exporter, остановимся на некоторых особенностях и конфигурации. Можно использовать установку из docker-compose файла или же развернуть систему в Kubernetes-кластере. Наша задача — собирать метрики серверов и сервисов инфраструктуры компании, хранить их, реагировать на алерты. Для решения этих задач необходима база данных.
Мы выбрали Prometheus по ряду причин:
Это вторая статья из цикла. В первой, вводной, я рассказывал, как устроены метрики для сервисов, чем отличаются от логов, и какую задачу вообще решают. Теперь подробнее про то, как их готовить.
Под катом: формат данных, способы отправки, типы метрик и их применение, кардинальность.
О техдолге говорят довольно давно и часто. Основные тезисы — он похож на денежный долг, накапливается, мешает вести разработку, и, как правило, противопоставляется задачам от бизнеса.
Мне как разработчику не нравится сложившаяся обстановка. Поэтому попытаюсь разобраться, что подразумевают под техдолгом в сообществе, какие типы задач к этому относят, расскажу, что весь техдолг влияет на бизнес и как можно построить процессы без отдельного техдолга. В качестве подготовки я провёл небольшой опрос, на который буду периодически ссылаться.
Привет, Хабр! Меня зовут Александр Меркулов, я занимаюсь разработкой более 20 лет, с 2011 года пишу на Ruby. Сейчас я — backend-техлид в Учи.ру. Наша команда использует большой монолит, который написан на Rails. Также мы создаем и поддерживаем микросервисы, у нас есть нативная мобилка: целых четыре приложения под веб-платформу.
Сегодня расскажу как раз про разработку бэкенда мобильного приложения и про полезные лайфхаки, которые помогут вам ее ускорить, минимизировать ошибки и сделать процесс более прозрачным.
Как мы к этому пришли? Как мы стали вместо решения наших задач, тратить кучи денег на решение проблем, которых у нас нет?
Сегодня мы находимся на третьей волне Agile, которая характеризуется стремлением бизнеса быстро и оптимально адаптироваться к динамичным внешним условиям с использованием гибких подходов и практик. Базовый механизм, гарантирующий создание свойства адаптации, заключается в переосмыслении жесткой иерархической структуры управления в сторону подвижной, ориентированной по направлению доставляемой ценности конечному потребителю.
В данной статье будет сделана попытка ретроспективно описать эмпирический опыт поиска волн для компании, находящейся в данный момент вне гребня.
Меня зовут Василий, и уже больше пяти лет я причиняю DevOps в хранилищах. Последние полтора года руковожу группой автоматизации хранилищ данных в Почтатехе.
В нашем data warehouse 6,5 петабайт активных данных. Вы и сами можете представить масштабы, когда речь идет о Почте России: работа сайта и приложения, логистика, трейсинг посылок и даже строительство сортировочных центров основываются на данных нашего хранилища.
Я расскажу, как мы применяем DevOps-практики на таких объемах DWH и как внедрить подобное у себя.
Задумывались ли вы, почему мы используем отдельную базу данных для каждого сервиса, но при этом один общий брокер для нескольких сервисов? Ведь вполне возможно использовать базу данных в роли брокера сообщений. Однако, если мы попробуем заменить RabbitMQ на Redis, то натолкнемся на проблему общего использования базы данных. Это станет проблемой, потому что общее использование базы данных является антипаттерном.
Второй закон термодинамики гласит: "Невозможен процесс, единственным результатом которого являлась бы передача тепла от более холодного тела к более горячему". Это связано с тем, что вселенная стремится к повышению энтропии или меры неопределенности (равновесия, другими словами). Если, например, не убирать в квартире хотя бы неделю, то поверхности покроются пылью, накопятся разбросанные вещи и прочие результаты жизнедеятельности.
Удивительно, но в исходном коде программ происходят аналогичные процессы. Является ли данная негативная тенденция неизбежной частью жизни любого проекта и программиста? Или, быть может, инженер способен взять ситуацию в свои руки, замедлить устаревание проекта или даже повернуть данный процесс вспять?
Коллеги, в подходящем к финалу 2023г. у меня случилось два инсайта. Первый тревожный и, кажется, весьма очевидный, а второй - ободряющий. Первый заключается в том, что функция архитектора в текущем виде перестает быть востребованной. Второй, в том, что у всех нас есть очень хорошие шансы быть успешными в новой эре - в эре управления архитектурой v2.0.
Всем привет. Среди многих интересных концепций, имеющихся в F#, меня привлекли Discriminated Unions. Я задался вопросом, как их реализовать в C#, ведь в нем отсутствует поддержка (синтаксическая) типов объединений, и я решил найти способ их имитации.
Discriminated Unions - тип данных, представляющий собой размеченные объединения, каждый из которых может состоять из собственных типов данных (также именованных).
Идея в том, что мы имеем ограниченное количество вариантов выбора, и каждый вариант может состоять из своего набора данных, никак не связанных с другими, но все варинанты объединены общим подтипом.
Для создания своих Discriminated Unions будем использовать эту мысль
От переводчика.
У меня накопилось куча всяких там данных, документов, pdf, doc, видосов на ютюбе, которые я бы хотел проиндексировать, и чтобы можно было по этой базе знаний у нейронки что-нибудь спрашивать.
Так же статья может пригодиться, если вы хотите собрать базу знаний по какой-то компании и затем заставить нейронку отвечать на вопросы пользователей. Например, чтобы ИИ прочитала кучу скучной документации, регламентов работы и прочего.
Пока выбираю, на чем это лучше сделать. Вот наткнулся на нижеследующий вариант, который решил попробовать.
Обзор одного из способов передачи информации между управляемым и неуправляемым кодом – почти забытого маршалинга.
Привет, Хабр! Зачем нужна архитектура и какие цели она должна выполнять?
Архитектура должна помогать нам писать максимально гибкий код, который мы сможем расширять с приходом новых функций, а не переписывать с нуля.
