
В этой статье постараюсь описать своё видение планирования спринта с учетом тестирования спринтовых задач и исправления багов по итогам тестирования. Внезапно для меня тема вызвала дискуссию на проекте, в разработке которого я участвую.
Пользователь
В этой статье постараюсь описать своё видение планирования спринта с учетом тестирования спринтовых задач и исправления багов по итогам тестирования. Внезапно для меня тема вызвала дискуссию на проекте, в разработке которого я участвую.
В Prime Video мы предлагаем нашим клиентам тысячи прямых трансляций. Чтобы гарантировать, что клиенты беспрепятственно получают контент, Prime Video создала инструмент для мониторинга каждого потока, просматриваемого клиентами. Этот инструмент позволяет нам автоматически выявлять проблемы с качеством воспринимаемого контента (например, повреждение блока или проблемы с синхронизацией аудио / видео) и запускать процесс их устранения.
У нашей команды анализа качества видео (VQA) в Prime Video уже был инструмент для проверки качества аудио / видео, но мы никогда не планировали и не проектировали его для масштабной работы (нашей целью было отслеживать тысячи одновременных потоков и увеличивать это число со временем). Подключая к сервису больше потоков, мы заметили, что масштабная эксплуатация инфраструктуры обходится очень дорого. Мы также заметили узкие места в масштабировании, которые мешали нам отслеживать тысячи потоков. Итак, мы сделали шаг назад и пересмотрели архитектуру существующего сервиса, сосредоточив внимание на стоимости и узких местах масштабирования...
Привет! Меня зовут Александр Голиков, я работаю в компании Bercut. Наша компания разрабатывает и развивает IT-решения для операторов цифровых услуг и мобильных сервисов. Коротко говоря, мы помогаем цифровизации бизнеса. В компании я занимаюсь виртуализацией, СХД, мониторингом, разработкой и интеграцией продуктов Bercut c операционными системами. Для агрегации данных и анализа мы используем Prometheus.
В этой статье рассмотрю одну из конфигураций Prometheus в отказоустойчивом режиме, познакомлю вас с Karma alert dashboard и продемонстрирую написание алертов. Напишу несколько простых включений Go Template и рассмотрю ситуацию, где такие включения противопоказаны. Продемонстрирую, как на основе меток можно сделать исключения из общих правил и обучу Prometheus самостоятельно чинить поломки.
Компания Hostkey предоставляет серверы в аренду — это накладывает на нас, сотрудников компании, обязательства по контролю качества работы оборудования. Одним из ключевых элементов поддержания большой инфраструктуры является эффективная система мониторинга, позволяющая оперативно выявлять сбои в работе серверов. Мы хотим поделиться нашим опытом внедрения и использования различных инструментов, позволяющих отслеживать работу оборудования.
В этой статье мы кратко рассмотрим варианты установки федерации Prometheus, Alertmanager и Node Exporter, остановимся на некоторых особенностях и конфигурации. Можно использовать установку из docker-compose файла или же развернуть систему в Kubernetes-кластере. Наша задача — собирать метрики серверов и сервисов инфраструктуры компании, хранить их, реагировать на алерты. Для решения этих задач необходима база данных.
Мы выбрали Prometheus по ряду причин:
Привет, Хабр! Я Женя, архитектор интеграционной платформы в Точке, отвечаю за асинхронный обмен сообщениями между внутренними сервисами, за ESB и за брокеры сообщений.
В этой статье я постарался кратко и последовательно изложить основные моменты, о которых полезно помнить при использовании RabbitMQ, если важны стабильность обмена и сохранность данных.
В первую очередь материал рассчитан на разработчиков, которым ещё не приходилось погружаться в тонкости работы с RabbitMQ или использовать его вообще. Более опытным читателям статья может пригодиться в качестве компактной и упорядоченной выжимки из уже знакомых статей, вебинаров и многочисленных страниц документации.
Добрый день. В этой небольшой заметке я хочу рассказать как быстро и просто настроить push-уведомления на вашем сайте. Эта статья ни в коем случае не претендует на звание исчерпывающего руководства, но, я надеюсь, что она даст точку старта для дальнейшего изучения.
Информации по этой теме в интернете полно, но она фрагментирована, разбросана по разным ресурсам и перемешена с уведомлениями для мобильных устройств с примерами на Java, C++ и Python. Нас же, как веб-разработчиков, интересует JavaScript. В этой статье я постараюсь саккумулировать всю необходимую и полезную информацию.
Я думаю, вы уже знаете что такое push-уведомления, но я всё же напишу коротко о главном.
Пользователь, заходя на сайт, вытягивает (pull) с него данные. Это удобно и безопасно, но с развитием интернет ресурсов, появилась необходимость оперативно доставлять информацию пользователям не дожидаясь пока те сами сделают запрос. Так и появилась технология принудительной доставки (push) данных с сервера клиенту.
Недавно я провела в Mastodon опрос о том, насколько мои читатели уверены в том, что они хорошо понимают работу HEAD в Git. Результаты (на основании примерно 1700 голосов) меня немного удивили:
10% — 100%
36% — достаточно сильно уверен
39% — уверен в некоторой степени
15% — представления не имею
Меня удивило, что люди не уверены в своём понимании: я-то считала, что HEAD
— это довольно простая тема.
Обычно, когда остальные, в отличие от меня, считают какую-то тему запутанной, причина заключается в какой-то скрытой сложности, которую я не учитываю. И в дальнейших обсуждениях выяснилось, что HEAD
действительно чуть сложнее, чем я считала!
У многих из нас остается достаточно свободного времени в сутках. А почему бы не монетизировать это время, думает начинающий IT левак? Если работать по три часа в день в будние, брать по 2 тысячи за час, то получится 120 тысяч дополнительного дохода в месяц. Звучит отлично!
Меня зовут Даниил, и я через выгорание, увольнение, споры с заказчиками и успешные проекты научился совмещать карьеру в компании и ведение проектов на стороне.
Мы, разработчики ПО, пользуемся git
каждый день, однако большинство из нас применяет только самые основные команды, например, add
, commit
, push
и pull
, как будто на дворе по-прежнему 2005 год.
С тех пор в Git появилось множество фич, пользование которыми может сильно упросить вашу жизнь. Так давайте исследуем некоторые из недавно добавленных современных команд git
, о которых вам стоит знать.
DDD — одна из моих основных рабочих методологий, я применяю её больше пяти лет. Хотя она довольна сложная, в том числе потому что это верхнеуровневый набор практик. DDD - это не фреймворк, когда нет опыта, его немного сложно применять. Тем не менее мы переводили на DDD работающие проекты, запускали с помощью нее новые — и у нас сложились некоторые практики и подходы.
Хотелось бы рассказать про те, что доказали у нас свою эффективность. Сегодня это будет стратегическое верхнеуровневое проектирование — о том, как разрабатывать программы с точки зрения моделей и требований. А в следующей части я расскажу про практики для работы с кодом и архитектурой, то есть более приближенные к разработке. Надеюсь, что вы сможете ими воспользоваться, а если вы еще не используете DDD у себя в проектах, то попробуете.
Все мы знаем эту историю: компания достигает состояния гиперроста, и все летит к чертям — газиллионы микросервисов, микрофронтендов, баз данных и т.д. Новые команды разработчиков появляются каждый квартал, и мы принимаем на работу больше людей, чем когда-либо прежде.
Многие проекты на Django начинаются просто: есть база данных и к приложению, которое крутится на сервере, идут обращения. Например, так начиналась Dodo IS (информационная система компании Додо Пицца, где работал автор сегодняшней статьи). Но если использовать Django из коробки, можно натворить много бед и встретить пачку антипаттернов. Возможно, вы встречали такое на старых legacy-проектах.
Евгений Пешков развивает сообщество DDD-практиков, рассказывая, какие проблемы решает Domain-Driven Design (предметно-ориентированное проектирование) в современном мире. На конференции Russian Python Week 2020 он выступил с рассказом об этом. Кстати, 19 августа пройдет встреча DDDevotion-сообщества, присоединяйтесь, будем о чем поговорить.
В сегодняшней статье будет его рассказ про то, как устроен Domain-Driven Design и какие инструменты использует, чтобы наиболее точно описать требования бизнеса и сам бизнес.
Как выглядят паттерны DDD (Domain Driven Design) в большом проекте? А самое главное, стоит ли их вообще использовать? Рассмотрим, какими инструментами можно реализовать DDD на Go и оценим, насколько это больно.
Меня зовут Илья Сергунин, я backend-сочинитель в Авито: занимаюсь тем, что передаю смартфоны в хорошие руки. В этой статье попытаюсь объяснить, как можно натянуть DDD на Go без синтаксического сахара и магии Java-подобных языков, и без больших крутых ORM c Data mapper, которые также отсутствуют в Go.
При разработке приложений рано или поздно наступает момент, когда заниматься развёртыванием вручную становится затратно и неудобно. Как следствие на помощь приходит автоматизация этого процесса с помощью специально настроенных пайплайнов непрерывной интеграции и непрерывной доставки (Continuous Integration & Continuous Delivery — CI/CD). Для разных систем управления репозиториями исходного кода существуют свои способы настройки CI/CD.
В этой статье мы рассмотрим, как использовать GitLab для организации автоматической сборки и деплоя приложения в кластер Kubernetes. Сам кластер работает под управлением Deckhouse Kubernetes Platform, а автоматизировать процесс будем с помощью werf — Open Source CLI-утилиты, организующей полный цикл доставки приложения в Kubernetes и использующей Git как единый источник истины для состояния приложения, развёрнутого в кластере.
В предыдущей части были заказаны для клавиатуры платы и все её детальки. Они, конечно же, все приехали и настало время смешать всё вместе и вдохнуть жизнь с помощью свежепротранслированной прошивки. Если вы пропустили о чем речь — загляните в первую часть.
Всем привет!
Меня зовут Петр и я работу в одном из крупных банков, буду рассказывать об управлении ИТ в крупной организации. Сегодня первой темой станет система KPI для управления командами. Расскажу зачем вообще нужны KPI, какой путь прошла наша компания, и в конце открою секрет какой должна быть идеальная система KPI