Как поддерживать свыше 2300 кластеров MySQL без заметных простоев? В Uber это решают разделением на плоскости данных, управления и обнаружения и строгим приведением фактического состояния к desired state. В материале — анатомия control plane (Odin, Cadence, контроллер с правилами), как устроены плавные и аварийные переключения primary, замена узлов и онлайн-изменения схемы; как discovery на etcd и реверс-прокси даёт стабильный VIP; как наблюдаемость, CDC (Storagetapper→Kafka→Hive) и бэкапы закрывают эксплуатацию. ФВ фокусе — инженерные решения, которые позволяют удерживать 99,99% доступности без ручной магии.

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

В прошлых статьях я прошелся по фразам:

Часть один: «Этого нет в ТЗ!» и «Этого нет в моей должностной!»
Часть два: «Мы проговаривали!» и «У меня нет ресурсов!»

И сегодня я пройду по оставшимся. Там будут и совсем гиблые и вполне приемлемые, которые просто надо использовать осторожно.

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

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

Например, эта машина потребляет 50% ресурсов CPU, поэтому, вероятно, способна выполнять вдвое больше своих задач.

Однако когда владельцы пытаются реально проецировать эти значения, то оказывается, что процент использования CPU на самом деле растёт не совсем линейно. Но насколько непрямой может быть зависимость?

Чтобы ответить на этот вопрос, я выполнил кучу стресс-тестов, мониторя при этом объём выполняемых ими работы и отображаемый системой уровень использования CPU, а затем по результатам построил графики.

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

Карта стейкхолдеров, карта эмпатии, agile чаще проваливается, мотивация по Герчикову, эффект Черномырдина, цезари, запрещенные фразы и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

Ястолкнулся с такой проблемой: логика между доменами сложнее самих доменов

Если строить систему по DDD: домены, агрегаты, use cases, события - всё красиво.

Потом пришёл сценарий: «Отменить заказ»

Я думал: `Order::cancel()`, вызову `inventory.release()`, `pricing.refund()`, и готово». Но...

• Если доставка уже в пути - нужно создать возвратную накладную

• Если платёж падал дважды - отменить всё, а при первой попытке только заморозить баллы

• Если товара нет - перенести резерв на другой склад, пересчитать доставку, спросить клиента, если дороже

• Если клиент повторил платёж - восстановить резерв и доставку

И я решил:

Самая сложная логика тут не в доменах, а между ними.

А в книжках по DDD, Clean Architecture, Hexagonal об этом не пишут.

Это напомнило проблему в ООП, когда каждый объект отвечает только за свою корректность (инвариант), а логическую зависимость при взаимодействии должен обеспечить ещё один класс "чистая выдумка". Также, у ФП есть более простые и явные способы.

Я напишу на Rust, потому что этот язык удобнее управляет бизнес правилами.

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

Привет, Хабр! Меня зовут Анна Афонина, я — IT-сваха, охотница за C-level и фанатка хардкорного хедхантинга. За 11 лет работы я видела многое: от CTO, которые без проблем продают космические идеи инвесторам, до тех, кто спотыкается о «сетевой кабель» на пути к собственной карьере. На CTO Conf X 2025 меня позвали рассказать про редкие и востребованные скиллы для технических директоров. Но чем глубже я копала, тем яснее становилось: куда опаснее не то, чего вы не умеете, а те самые подножки, которые вы ставите себе сами. Давайте честно разберём, почему даже супергерой в CTO-плаще может оступиться — и как этого избежать.

Сейчас я — Founder рекрутингового агентства HiPoHeads. За спиной у меня больше 11 лет в IT-рекрутинге и карьерном консультировании, я — организатор ProITFest, SPb IT Recruiter, HR Tech Day. По образованию — клинический психолог. До сих пор люблю рекрутинг и работаю руками, нанимаю как клиентам, так и себе. Занимаюсь не только подбором, а часто свожу людей, как для работы, так и для личных отношений. Можно сказать, что я — супер-мэтчинг-система, которая соединяет людей в IT-индустрии.

В прошлой статье я уже рассмотрел основные возможности Web App. Cегодня же подведём итоги, расскажем все особенности и нюансы работы с Web App в Telegram и соберём простенькое веб-приложение.

Docker — не магия, а грамотное применение механизмов Linux. Разбираем инструмент, который пугает своей сложностью не меньше блокчейна. Показываем на пальцах как работают: Namespaces, Cgroups, OverlayFS – основные компоненты любого контейнера, и как стандарт OCI объединяет их в единую экосистему. Об этом и не только в статье.

В компаниях часто ищут агента изменений: «сильного менеджера», который возьмёт весь хаос на себя и решит проблемы, накопленные годами. Но когда менеджер выходит на работу, оказывается, что нет ни целей, ни ответственности, ни бюджета. Зато слышит фразу: «Мы тебя наняли — ты и решай». Вместо изменений менеджер тушит пожары, берёт на себя чужие задачи и пытается доказать, что перемены вообще нужны. В итоге его увольняют за то, что тот «не оправдал ожиданий», а ситуация в компании остаётся прежней.

Меня зовут Степан Сорокин, я Delivery-менеджер в Outlines Tech и руководитель проектов с опытом более 10 лет. Запускал процессы в стартапах и корпорациях. Почти в каждом проекте сталкивался с одной и той же проблемой: компания хочет внедрить Agile или другую методологию, но не готова действительно менять процессы и вкладывать в это ресурсы. От менеджера ждут, что он изменит всё сам, без поддержки сверху.

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

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

Идеей было донести простыми словами и примерами механизмов работы барьеров памяти, поэтому в данной статье нет углубления в синтаксис ассемблер команд или архитектур процессоров.

Привет, Хабр!

Если вы ощущаете, что стали частью распределённой системы с бесконечными входящими — поздравляю, вы тимлид. И, скорее всего, вам не весело. Вы не пишете код. Вы не думаете стратегически. Зато вы таскаете ведро с пробоинами по палубе, где вечно течёт.

У большинства тимлидов, особенно в условиях активного роста компании или распределённой разработки, есть общее ощущение перегруженности. Неважно, какая индустрия, стек, удалёнка или офис — ощущение одно: «весь день был занят, но результат размыт».

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

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

Конкурентность — одна из самых мощных возможностей Go, и её освоение критически важно для создания масштабируемых и эффективных приложений. В этой статье мы рассмотрим 7 шаблонов конкурентности в Go, которые помогут вам писать надёжный код.

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

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

С 1 июля 2025 года хранить персональные данные россиян в иностранных сервисах больше нельзя. Назрел вопрос, что же делать, например, с регистрациями на мероприятия, которые так удобно складывались из формочек Tilda напрямую в Google Sheets без СМС и регистрации. В статье расскажу, как я эту задачу решил с помощью бесплатного open-source сервиса Grist, платного, но копеечного Яндекс Облака и сомнительного Go кода.

­­­Какие предметы вам нравились в школе? Я очень любила математику.  Меня завораживали цифры, формулы и логические рассуждения. А самое главное, даже если решать задачу несколькими разными способами – единственно верный ответ всегда будет один. И проверив его, можно быть уверенным, что задача решена правильно.

Сейчас, проектируя программные системы, я тоже решаю задачи, но они принципиально отличаются от математических, где всегда есть единственно верное решение. Если в школе небольшого условия задачи было достаточно, при проектировании это не так. Как говорил итальянский программист Альберто Брандолини: «В прод идут не знания экспертов в предметной области, а предположения разработчиков». Поэтому важно не просто полагаться на своё понимание, а проверять предположения на практике.

Для этого необходимо организовать совместное исследование сложной предметной области бизнеса: собрать команду, построить модель процессов и сверить свои гипотезы с реальными знаниями экспертов. По моему опыту, снизить неопределенность в понимании предметной области и проверить предположения на соответствие действительности помогает — Event Storming. Эта техника выявляет и минимизирует влияние ошибочных предположений на качество конечного продукта.