IT-инфраструктура *

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

Если вы работаете с мониторингом в Prometheus или VictoriaMetrics, то наверняка знаете, как алерты из Alertmanager могут быстро накапливаться, требуя ручного трекинга в Jira. А что если автоматизировать это полностью — с назначением исполнителей, метками, компонентами и даже шаблонами для описаний? Знакомьтесь с alertmanager-jira — классным инструментом для обеспечения интеграции Alertmanager (с Prometheus или VictoriaMetrics). Это Alertmanager (webhook) плагин, который создаёт и управляет задачами в Jira на основе алертов, с акцентом на гибкость. Написан на Quarkus, лёгкий и готов к деплою в docker (podman).

В посте разберём, зачем это нужно, почему не подошли альтернативы, как использовать и что под капотом. Давайте по порядку.

Помните свой первый «вау‑эффект» от LLM?

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

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

Её философия проста: дать специалистам по ИБ возможность обмениваться опытом, пользоваться готовыми инструментами и строить эффективную систему безопасности с нуля. И один из свежих примеров того, как это работает на практике, — кейс Пятигорского завода «Импульс». На нём объясним, как работает сообщество.

Ваш AI-агент ведет себя как капризный стажер и доказывает, что 2+2=5? Или вы уже третью неделю пытаетесь дообучить модель, а она делает вид, что не понимает, чего вы от нее хотите? Кажется, пора признать: классические подходы не работают.

Пока одни AI-инженеры кропотливо готовят данные и тестируют их, другие непослушные инженеры открыли простую истину. Они всё делают наоборот: не тестируют агентов, кормят модель мусором и открывают ей полный доступ к конфиденциальным данным. И знаете что? У них получаются самые незабываемые агенты!

Мы в команде Cloud.ru подумали: зачем бороться с этой гениальной стратегией? Гораздо эффективнее ее систематизировать: таким инженерам нужно давать не полезные, а вредные советы. Они все сделают наоборот, и получится как раз правильно. В статье собрали вредные советы для идеального саботажа. Читайте и внедряйте.

Один из специалистов по восстановлению данных покончил с собой. Катастрофа случилась из-за чудовищной халатности.

Привет, друзья! Я Олег Васильев, владелец продукта Dream DE. В этой статье расскажу, как мы научились быстро и эффективно выводить витрины на Hadoop в эксплуатацию, или как мы за один квартал вывели 26 инициатив в рабочую среду силами четырёх инженеров по данным.

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

Де-факто стандартом мониторинга стал Prometheus. В статье мы разберёмся, всегда ли можно доверять информации, которую он предоставляет. Посмотрим, в каких случаях его данные не соответствуют реальности, и погрузимся в тонкости работы Lookback-delta, оконных функций и Federation API. В итоге вы глубже поймёте внутреннее устройство Prometheus и других систем мониторинга на базе TSDB и сможете корректно интерпретировать данные с учётом их особенностей.

Представьте: Один неоптимизированный запрос от неопытного коллеги - и вот уже 40 ТБ SPILL-файлов парализуют систему.

Срабатывает лимит на уровне Greenplum, запрос завершён. Никто ничего не знает.

Создаются заявки, пишутся письма, пользователь недоволен.

Это не какая-то выдуманная история, а обычный будний день в большом Greenplum. Вернее, так было раньше.

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

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

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

Антивирус, EPP, EDR и XDR… Многие слышали эти термины, но далеко не все понимают, чем они различаются и почему одного только антивируса сегодня уже недостаточно. В этой статье эксперты из Positive Technologies — Паша Попов, лидер практики по управлению уязвимостями, Сергей Лебедев, руководитель департамента разработки средств защиты рабочих станций и серверов, и Кирилл Черкинский, руководитель практики защиты конечных устройств, — разбираются с помощью наглядных аналогий в средствах киберзащиты и их роли в управлении уязвимостями.

Сегодня расскажу историю о том, как мы еще в 2017 году решили поменять инфраструктурную платформу. Мы расшифровали мой доклад с DevOpsConf21, много всего уточнили, переписали и дополнили с учетом опыта следующих четырех лет, прошедших после того выступления. 

8 лет назад у нас было 40 сред, 15 разработчиков, 2 монолита, 10 сервисов и свое железо в трех серверных стойках. С такими исходными данными мы решили перейти с Puppet на Ansible. Окружений много, потому что с 2010-го мы поставляли разработчикам и тестировщикам маленькие копии нашего приложения — это делало задачу еще интереснее.

Путь был непростой. О нем расскажу в хронологическом порядке, не забывая о косяках и ошибках. По ходу повествования я выделил инсайты, которые могли бы сильно помочь мне в прошлом. В конце оформил их в виде письма для себя образца 2017-го 🙂.  А если вы решитесь проделать нечто столь же безумное (ну там, не знаю, переехать с микросервисов на монолит, с linux на windows и так далее), надеюсь, мои заметки уберегут вас от сложностей, с которыми мы столкнулись.

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

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

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

Меня зовут Александр Душеин, я технический лидер команды архитекторов Yandex Cloud и занимаюсь направлением клиентской надёжности. В этой статье я расскажу подробнее, что поможет избегать нештатных ситуаций: 

• какая работа по предотвращению серых отказов была проделана на нашей стороне за счёт слаженной работы всей команды;

• какие настройки стоит взять на вооружение пользователям Yandex Cloud и какие рекомендации могут быть полезны всем ответственным за Disaster Recovery;

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

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

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

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

Мы с тобой, коллега — Системные Администраторы.
Не “инфраструктурные инженеры”, не “DevOps-практики”, не “cloud-специалисты”.

Просто — сисадмины.
Это звание не выдают по результатам онлайн-курсов и не прикрепляют в LinkedIn. Его зарабатывают в душных, перегретых серверных, где запах пыли вперемешку с озоном от ИБП становится запахом профессии. Где вместо open-space — кладовка с розеткой на три киловатта и проводами, похожими на гнездо безумного питона.

Наш путь — это не просто карьера. Это живая эволюция техники, прошедшая через наши руки и нервы: от скрежета SCSI-дисков и светящегося экрана CRT-монитора до кластеров Kubernetes, которые даже потрогать нельзя — всё спрятано в облаке.

Мы — свидетели и участники самой стремительной технологической трансформации последних двадцати пяти лет. Когда-то мы тянули первые «витухи» по потолкам советских зданий, пробивая стены перфоратором, потому что «завтра сдавать сеть в бухгалтерии».
Теперь мы нажимаем пару клавиш в Terraform и поднимаем целые дата-центры. А ведь тогда облаком мы называли сигаретный дым в серверной после ночного релиза.

Мы знаем, что такое физическая боль — тащить 4U сервер без тележки, спотыкаясь о кабель-канал, потому что «сейчас, только вот этот один, и домой». И что такое ментальная боль — когда забыл поставить setlocal enabledelayedexpansion, и кривой .bat-файл превратил NT-домен в цифровой ад.

Наш возраст измеряется не годами, а версиями операционных систем.
Мы взрослели вместе с Windows NT 4.0, Windows 2000, XP, Server 2003… потом 2008, 2012, 2016… А где-то между ними — Slackware, Debian Potato и FreeBSD 4.10, которые учили нас терпению, вниманию и вере в консоль.

Попробуйте как-нибудь чисто из спортивного интереса объяснить жене, почему в прошлом месяце ваш интернет стоил не 900 рублей, как обычно, а 90 000. Аттракцион, прямо скажем, диковатый, но примерно в таком же положении оказывается ваш ИТ-дир, когда видит счета от всех облачных сервисов одновременно. Что не так? Да примерно все. Каждый провайдер считает по своим правилам, выставляет счет в собственном формате, из-за чего объяснить, за что именно платим, оказывается просто супер-сложно. Но ведь не будешь складывать все яйца в одну корзину. Значит, нужно решать этот вопрос как-то по-другому.

Представьте: у вас десятки микросервисов, миллионы логов и трассировок, а ваша задача — поддерживать SLA и не дать системе сломаться. Ручная настройка SLO (Service Level Objectives) и мониторинг SLI (Service Level Indicators) превращается в кошмар.

SLO-Scout решает эту проблему с помощью AI, анализа телеметрии и автоматизации, позволяя SRE сосредоточиться на надежности, а не на ручной рутине.

Привет, Хабр! На связи снова Данила Гудынин, DevOps-инженер направления Evolution ML Inference в Cloud.ru.

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

В этой части мы нырнем в практически-технический хар дкор и расскажем, как оптимизировать работу своих графических процессоров с KServe ModelMesh или vLLM Production Stack, подсветим, где разбросаны грабли в этом деле, а еще заглянем под капот к Cloud.ru Shared GPU и объясним, как именно он позволяет нам ставить цены на уровне западных облаков при кратно более дорогом железе в РФ.

ML-инженеры, DevOps и MLOps-архитекторы, можете сразу добавлять в закладки, чтобы возвращаться и списывать нужные конфиги. Наливайте бочку чая или чего покрепче, постарался изложить все сугубо по делу, много кода спрятал в «раскрывашки», так что не пугайтесь обозначенного выше времени чтения.

Привет, постоянные и не очень читатели!

CXL (Compute Express Link) — свежий стандарт интерконнекта, появившийся в 2019 году. Его главная фича — новый подход для работы с памятью и вычислениями: поддержка когерентного кэша и трафика между процессорами и ускорителями, возможность собирать инфраструктуру как конструктор, гибко распределяя ресурсы, и другой функционал.

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

Здесь будет всё, что вы хотели знать про CXL, но лень было искать, так что заваривайте чайничек листового — и приятного чтения! :)