IT-задачи о кофе, switch и шумах

Сейчас мы используем Patroni два пулера: PgBouncer и Odyssey. Как и многие другие решения у каждого из них есть свои плюсы и минусы, поэтому мы всё ещё находимся в переходном периоде и выборе конечного решения.

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

Я бы советовал всегда использовать внешний пулер. Создание нового подключения является дорогой операцией для PostgreSQL, поэтому инициировать их каждый раз при скейле/рестарте приложения — не самая хорошая идея. Также вы всегда можете ошибиться в расчётах или забыть про них, и тогда пулер будет той точкой, которая обезопасит вас от проблем. Не знаю, как у вас, но среди моих набитых шишек точно есть кейс, когда скейл приложения из-за нехватки CPU привёл к проблемам с коннектами в базе, потому что я забыл их пересчитать.

Так как мы используем связку Patroni + PgBouncer/Odyssey + Warden (наша система для Service Discovery), то она позволяет приложением практически мгновенно узнавать о любых изменениях в топологии баз: переключении мастера на другую реплику, запуск новой асинхронной реплики и так далее.

Для расчёта потребления кофе требуется инициализировать:

— календарь (есть возможность учесть необходимые праздники);

— настройки калькулятора.

Полное решение можно посмотреть тут.

Ниже приводим часть решения.

			/// 

public decimal CoffeeMachineCapacity { get; set; }

/// 

///  порог остатка, при котором необходимо наполнять кофе-машину

/// 

public decimal RefillThreshold { get; set; }

/// 

/// текущий остаток в кофемашине 

/// 

public decimal CurrentCoffeeAmount { get; set; }

/// 

/// базовый расход кофе

/// 

public decimal BaseRate { get; set; }

/// 

/// коэффициент расхода кофе в день (может меняться, а по дефолту — 1, то есть без отклонений)

/// 

public decimal CoffeeDayRate { get; set; }

/// вместимость кофе-машины

///
		

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

Пример:

			var calendar = new Calendar(holidays);

var calculator = new Calculator(calendar, calculatorSettings);

var sprintsCalendar = calendar.GenerateSprintsCalendar(startDate, 14, 2); 

// 2 спринта по 14 дней;

var calculationResult = calculator.CalculateRefillSchedule(sprintsCalendar);
		

Опционально в CalculateRefillSchedule можно также передать номер дня, который будет влиять на увеличенное потребление кофе (к примеру, с восьмого дня в спринте кофе начинают пить больше чем обычно).

Отчасти, вопрос использования switch или if-else является вкусовщиной, ведь любую конструкцию switch можно представить в виде if-else.

Я выделяю следующие преимущества:

— Использование switch’a позволяет уменьшить вложенность и код выглядит «чище». С ним легче проследить «поток выполнения», что хорошо сказывается на ревью, и при необходимости внести изменения в код.

— Конечно же, в Go не нужно указывать break после каждого случая, а в других языках достаточно часто это становится причиной очень неприятных багов. При необходимости можно использовать fallthrough, но так и не вспомнил, когда последний раз им пользовался. Однако, каждый раз мысленно говорю спасибо команде Go за то, что изменило стандартное поведение.

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

Инженерам QA в Ozon Tech в большей степени приходится сталкиваться с задачами обеспечения качества ПО — чтобы код в продакшене был работоспособен, поэтому задачи, связанные с железными устройствами, довольно от нас далеки, но при этом не менее интересны.

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

1. Шум в приборе мог возникнуть по следующим причинам:

— Исходя из подсказки про материаловедение, основной версией звучит то, что на максимальной мощности никель сработал как дополнительный источник теплового шума в приборе. Это могло случиться из-за попадания никеля в электромагнитное поле, генерируемое блоком питания (система питания — «умная», это могло внести свой вклад).

— Так как корпус сделан из сплава алюминия и никеля, при нагретом никеле мог возникнуть эффект Зеебека (возникает ЭДС), который тоже мог привести к паразитному шуму.

— Свой вклад также могла внести неправильная геометрия проводников при экранировании, которая могла привести к магнитным помехам (паразитный контур заземления).

2. Основные действия здесь:

— Для диагностики — снятие и анализ спектрограммы.

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

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