Администрирование

Привет, Хабр! C вами сегодня Владимир Кудрявцев, Илья Князев и Иван Пономарев.

Дело было вечером, дебажить было нечего. К нам пришел Анатолий, менеджер продукта ALD Pro, и попросил разобраться, с чего это Linux приходит в такую задумчивость от недоступности первых двух DNS-серверов, в то время как Windows вполне нормально справляется с таким сценарием. «Да, как два байта переслать», – подумали мы. И начался квест длиной в две недели.

Материалы будут полезны, даже если вы все ещё используете обычные Linux-системы с ванильными версиями компонентов.

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

Просто оставлю свой скрипт дампа пакетов composer тут. Адаптируйте под свои нужны.

Применял для резервного копирования пакетов, из-за нестабильной работы интернета при получении данных с зарубежных сервисов из-за кривых фильтров РосКомНадзора (РКН).

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

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

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

Хостинг - это десятки тысяч сайтов и пользователей находящихся под управлением одного сервера.

Зачастую пользователь хостинга не погружается в детали настроек сервера, а знает только основное — на сервере есть PHP, Ruby, Python, MySQL и Apache, чтобы его сайт успешно функционировал . Ему не интересно, как и что настроено на сервере, главное, чтоб все работало и не создавало ему проблем.

В русском переводе вышла книга «Изучаем eBPF» (Learning eBPF) Лиз Райс, главного специалиста по открытым технологиям в компании Isovalent. В ней автор рассказала сисадминам и разработчикам, как можно успешно применять eBPF в своей работе. eBPF (Extended Berkeley Packet Filter) — это технология, позволяющая безопасно и эффективно выполнять свой код в ядре Linux. Хотя у книги небольшой объем (220 стр.), она наверняка будет полезна для сисадминов и ИТ-специалистов по управлению сетями, обеспечению безопасности и мониторингу в сложных системах. 

С момента публикации предыдущей статистики прошел год и пора опять обновить данные, провести анализ по предложениям работы в сфере системного администрирования для планирования индексаций на 2026 год.

У нас уже есть статистика за 2022, 2023 и 2024 года, будем смотреть динамику изменений с ними, пока позволяет ширина таблиц на Habr.

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

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

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

Салют, Хабр! Я думаю, каждый из вас знаком или, по крайней мере, слышал о такой прекрасной утилите как NoDPI написанной на питоне (большое спасибо @Lord_of_Rings!). Сегодня я хочу представить вам (почти) свою разработку, не требующую ни питона ни прокси. Мы будем патчить прямо на диске библиотеку chrome.dll - входяющую в пакет Chrome на Windows и лежащую в директории "C:\Program Files\Google\Chrome\Application\140.0.7339.208\chrome.dll". Цифры могут меняться в зависимости от версии. Данный патч занимает всего 8 байт и после него у нас появится YouTube.

Привет, Хабр! Уверен, многие сталкивались с тормозами сервера, долгой загрузкой страниц. Логи молчат, нужно искать виновника. Системный мониторинг демонстрирует, что CPU вроде не загружен, память не полностью израсходована, а отклик системы оставляет желать лучшего.

В такие моменты стандартных утилит вроде top или htop часто недостаточно, нужен более детальный анализ. С этим мне приходится периодически сталкиваться, из-за чего и были написаны 3 bash-скрипта. Они дают сбор ключевых метрик системы для дальнейшего разбора.

Иногда после запуска VDS/VPS проходит всего несколько минут, как в логах появляются десятки попыток входа или перебора паролей. В этом случае на защиту провайдера надеяться нельзя, потому что он отвечает только за изоляцию гипервизора, а всё, что происходит внутри гостевой ОС, — это ваша зона ответственности. Под катом собрал десять базовых правил по безопасности VDS, но лучше всего они работают в связке. 

В арсенале IT-отдела крупной компании обязательно присутствуют системы мониторинга. Но почему же для глубокого анализа систем, работающих на платформе «1С:Предприятие», универсальных инструментов часто не хватает? Сегодня публикую статью нашего партнера — Андрея Бурмистрова, эксперта в сфере оптимизации производительности 1С. Разработкой на платформе «1С:Предприятие 8» Андрей занимается уже более 10 лет и знает нюансы. В этой статье он делится своими аргументами.

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

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

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

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

Привет, Хабр! В этой статье хочу рассказать об основных модулях нашего приложения для развертывания больших инфраструктур и киберполигонов на основе Ansible. Эти модули мы называем A-services (сокращенно от Ansible services). Они содержат все сценарии подготовки, развертывания и настройки ИТ-инфраструктуры.

Общая архитектура приложения на основе Ansible описана в предыдущей статье. Здесь хочу поделиться особенностями архитектуры модулей А-services.

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

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

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

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

У нас 1С развёрнут на Linux и PostgreSQL. Всё началось с запроса клиента на развёртывание 1С в Linux-среде. Мы создали первый кластер, а затем перевели всю облачную 1С на open source.

В этой статье расскажем о нашем пути, сложностях и результатах. Больше подробностей об особенностях работы облачной 1С вы узнаете на вебинаре — запись эфира открыта по ссылке. 

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

Сетевой уровень: NGFW и IDS как основа защиты

Next-Generation Firewall (NGFW) — это эволюция традиционных фаерволов. В отличие от предшественников, NGFW анализирует трафик на уровне приложений, а не только по портам и протоколам. Например, можно заблокировать передачу данных через мессенджеры или доступ к фишинговым сайтам, даже если они используют стандартные HTTPS-порты.

Системы обнаружения вторжений (IDS) дополняют NGFW, выявляя аномальную активность. Suricata в связке с SecurityOnion позволяет детектировать:

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

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

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