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

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

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

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

Разработчик Гуннар Морлинг в 2022 году представил пирамиду ревью кода. По аналогии с ней появилась пирамида отказоустойчивости системы. Она делит отказоустойчивость на уровни и предлагает ответить на ряд важных вопросов по каждому из уровней. Пирамида отказоустойчивости системы помогает лучше понимать и реализовывать эту концепцию. 

Среди применяемых в PostgreSQL методов доступа к данным Index Only Scan стоит особняком, считаясь у многих разработчиков "волшебной пилюлей" для ускорения работы запроса - мол, "Index Scan - плохо, Index Only Scan - хорошо, как только получим его в плане - все станет замечательно".

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

Всем привет! 

Меня зовут Владимир Олохтонов, я руковожу командой разработки в отделе Message Bus, который является частью платформы Ozon. Мы занимаемся разработкой самых разных систем вокруг Kafka, etcd и Vault. В этой статье я расскажу о том, как мы строили линейно масштабируемую gRPC-прокси перед Kafka, способную обслуживать миллионы запросов в секунду, используя Go.

Если вы знаете, что такое Site Reliability Engineering, вам может быть интересно, как эти практики связаны с DevOps. Важно сразу оговориться, что мы не ставим между ними слово «против». Хотя у этих подходов есть некоторые отличия в том, как лучше делать и быстрее доставлять программное обеспечение. В этом посте разберём каждый подход и выясним, чем отличаются DevOps и SRE. Вы заметите, что у подхода SRE есть своё мнение по поводу запуска производственных систем, в то время как DevOps больше фокусируется на людях, процессах и инструментах — именно в этом порядке.

Что такое OAuth 2.0

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

• Улучшаются коммуникации в команде

• Совершенствуется культура

• Уменьшается доля ручного труда

• Клиенты чаще остаются довольны

Алексей Барабанов, IT-директор «Хлебница» и спикер курса «RabbitMQ для админов и разработчиков», подготовил конспект, который поможет научиться запускать и настраивать RabbitMQ в Docker. Вы поймёте, как конфигурировать параметры запуска, а также узнаете о возможностях управления через веб-интерфейс.

Привет, Хабр! Меня зовут Александр Лукьянченко, я тимлид команды, которая занимается платформой в Авито. В этой статье я расскажу о проблемах, которые возникали у нас при построении платформы для инженеров и том, какие технические решения мы использовали, чтобы эти проблемы устранить. Текст охватывает ту часть наших наработок, которые потенциально можно переиспользовать другим компаниям.

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

Людские пробки в метро

На московских улицах присутствуют всем известные автомобильные пробки.

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

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

Занятно то, что если бы все ехали спокойно и равномерно, то поток двигался бы быстрее.

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

Примером того является возникновение толпы людей перед эскалаторами в московском метрополитене.

Каждый ездивший в московском метро в час‑пик наблюдал такую картину, что перед эскалатором собралась большая толпа, но при этом сам эскалатор заполнен едва на половину. Это отлично видно при взгляде из очереди на поднимающий эскалатор (см.рис.1)

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

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

Если интересно, где в России выгоднее всего живется IT-специалистам — заглядывайте под кат.

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

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

Иными словами, попробуем заглянуть в будущее. Однако для этого надо слегка откатиться назад, чтобы посмотреть, как IT-отрасль развивалась. Тогда будет проще оценить, что нас ждёт впереди.

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

1. Видео с доклада
2. Слайды

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

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

Гексагональная архитектура, ни в коем случае не новый подход к разработке с применением фреймворков. Напротив, это всего лишь обобщение «лучших практик» — практик новых и старых. Я обернул эти слова в кавычки, чтобы люди не воспринимали их совсем буквально. Лучшие практики, которые работают для меня, могут не работать для вас — все зависит от задачи и преследуемых целей.

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

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

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

Я составил список своих задач и разбил их на категории. Кстати говоря, добрую половину этих задач я повесил на себя сам.

В своём прошлом посте я рассказал теорию своего подхода к декомпозиции систем на модули. Теперь пришло время проверить её на практике.

Кэмп - реальный проект, который стоил семизначную сумму для заказчика, выполнялся командой из 12 человек (включая двух бакэндеров) и сейчас запущен в промышленную эксплуатацию. Суммарно на выполнение проекта было затрачено 5500 человеко/часов, из которых 950 - на бакенд.