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

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

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

Зачастую пользователь хостинга не погружается в детали настроек сервера, а знает только основное — на сервере есть 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-команды сегодня — это внутренние поставщики сервисов: от пайплайнов и окружений до документации и архитектурных решений. В этой статье поговорим о том, как выстроить эту работу так, чтобы было удобно и разработчикам, и самим девопсам. Как выйти из роли «пожарной команды», навести порядок в ожиданиях и инструментах, построить платформу и не сгореть.

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

Рассказываю про еще одну коварную подлость, встроенную в современные технологии беспроводной связи — WiFi. Про это знают все приличные сетевые инженеры, но почему-то не рассказывают простым пользователям.

Мы с тобой, коллега — Системные Администраторы.
Не “инфраструктурные инженеры”, не “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. Аттракцион, прямо скажем, диковатый, но примерно в таком же положении оказывается ваш ИТ-дир, когда видит счета от всех облачных сервисов одновременно. Что не так? Да примерно все. Каждый провайдер считает по своим правилам, выставляет счет в собственном формате, из-за чего объяснить, за что именно платим, оказывается просто супер-сложно. Но ведь не будешь складывать все яйца в одну корзину. Значит, нужно решать этот вопрос как-то по-другому.

Запускаем на ноутбуке учебный кластер ClickHouse — шардированный (sharding) и реплицируемый (replication) — на Docker Compose.
Это не один сервер в контейнере, а стенд из 2 шардов × 2 реплики, с координацией через ZooKeeper и балансировкой HAProxy — поднимается за несколько минут.
Зачем: на практике разобрать репликацию и распределение по шардам, увидеть базовую отказоустойчивость и спокойно экспериментировать — всё в контейнерах, всегда можно снести и развернуть заново.
Кому: новичкам, кто хочет «пощупать» кластер; тем, кто знает базовый синтаксис ClickHouse, но не пробовал шардирование/репликацию; тем, кто готовится к собеседованию или приценивается к архитектуре перед продом.
В комплекте — готовые конфиги и docker-compose.yml в репозитории; всё, что нужно, — Docker и несколько команд.