Автор: Виталий Бутурлин

«Но это же в любом учебнике по сетям написано!» — возмутится нетерпеливый читатель.

Однако, не нужно спешить с выводами. Написано по этому поводу много, но, к сожалению, далеко не всегда понятным языком. Вот и рождаются вредные мифы.

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

И начинает наш герой ломать голову: взять L3, чтобы «на все случаи жизни», но он дорогой или взять подешевле — L2, а вдруг прогадаешь… Да ещё этот L2+ непонятно что за промежуточный уровень...

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

Так случилось, что продукт, который мы разрабатываем работает с несколькими реляционными базами данных. Сейчас это MS SQL, Postgres и Oracle. Были запуски под много чем от MySQL до покойного, наверное, Firebird и экзотических Sybase с DB2, но сказ не об этом.

Если с MS SQL и Postgres все более мене понятное-привычное, то с Oracle каждый раз нас ждут какие-то сюрпризы. Проницательный читатель сразу заметит, что "руки у нас кривые" и мы "попросту не умеем его готовить", но если, уважаемому читателю захочется узнать чем varchar (а точнее varchar2) в Богоподобном Oracle отличается от его собратьев, то прошу под кат.

CREATE TABLE task AS
SELECT
  id
, (random() * 100)::integer person -- всего 100 сотрудников
, least(trunc(-ln(random()) / ln(2)), 10)::integer priority -- каждый следующий приоритет в 2 раза менее вероятен
FROM
  generate_series(1, 1e5) id; -- 100K задач
CREATE INDEX ON task(person, priority);

SELECT
  *
FROM
  generate_series(0, 99) pid
WHERE
  EXISTS(
    SELECT
      NULL
    FROM
      task
    WHERE
      person = pid AND
      priority = 10
  );

Всем привет. Сегодня мы хотели бы поговорить про выявления аномалий в микросервисной среде. Данный пост является краткой выжимкой нашего 40 минутного доклада, который мы делали на онлайн конференции DevOps Live 2020 и, чтобы не писать лонгрид, мы решили сфокусироваться на обзоре инструментов выявления аномалий в распределении значений метрик для автоматизации мониторинга микросервисов, которые возможно быстро начать использовать любой команде.

Тема детектирования аномалий сейчас очень актуальна, так как с переходом на микросервисы для SRE и DevOps приоритет задач, связанных с преобразованием алертов в осмысленный сигнал, снижением MTTD и упрощением настройки алертов в мониторинге распределенных сред значительно повысился.

Добрый день! Меня зовут Кирилл, и я DevOps-инженер. За свою карьеру мне не раз приходилось внедрять DevOps-практики как в существующие, так и в новые команды, поэтому хочу поделиться своим опытом и мыслями по поводу стратегий ветвления. Существует множество различных типов рабочих процессов, и чтобы разобраться что к чему, предлагаю рассмотреть пример создания нового программного продукта.