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

Привет, Хабр! На связи редакция ICL Services. Сегодня, 3 августа, нам исполняется 20 лет, и мы продолжаем триптих статей о людях, которые писали историю компании – своим опытом, проектами, командировками и целым чемоданом локальных шуток, без которых в ИТ-сервисных услугах нельзя.

Эти ребята наблюдали, как компания на протяжении многих лет трансформировалась из аутсорсингового подразделения японской корпорации Fujitsu – Russia GDC – в самостоятельного игрока на российском рынке, и помнят времена, когда мобильный интернет был роскошью, а «печеньки в офисе» были реальным пунктом в вакансиях.

Первым героем цикла стал Петр Сапаркин, прошедший путь от разработчика до руководителя направления за 19 лет – статью о нем, а также краткий экскурс в историю изменений компании за последние два десятилетия, можно прочитать тут.

Сегодня наш собеседник – Дмитрий Игнатьев, руководитель направления инфраструктурных решений и услуг. Его 16-летка — это целое приключение с настоящими пиратскими дисками, командировками в обмен на работу в выходные, индийскими коллегами с рисоварками и малярийными комарами, японским языком и рождением системы по управлению рабочими местами и серверами Колибри-АРМ. Об этом рассказываем ниже.

Надёжная работа любого сервиса опирается на возможности системы журналирования. С помощью логов можно решить широкий спектр задач: решение проблем, аналитика поведения пользователей, расследование инцидентов безопасности, мониторинг состояния системы и другие. В этой статье посмотрим на возможности и практические приёмы для работы с логами сервера Angie.

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

В статье рассматриваются основы работы ЦОДов, серверных шкафов, серверного оборудования, RAID, BIOS, BMC, оптоволоконных и медных кабелей. Отдельные разделы посвящены DNS, Active Directory, групповым политикам, аутентификации и другим базовым службам корпоративной среды. Материал объясняет технические понятия простым языком, дополняется схемами, таблицами и практическими примерами.

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

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

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

В компании есть Kubernetes, GitLab с пайплайнами и стена дашбордов в Grafana. А деплоить всё равно страшно — по пятницам нельзя, релиз согласовывают в личке, о падении прода первым сообщает клиент. Если картинка знакомая, то у меня плохие новости в формате чек-листа. Ниже десять симптомов карго-культа с проверочными вопросами.

До этого момента мы изучали Terraform локально. Теперь пришло время применить эти знания в реальной среде.

В этой статье мы подключим Terraform к облачному провайдеру, создадим первую инфраструктуру, разберём процесс создания сети и виртуальной машины, а также сравним особенности AWS, Microsoft Azure, Google Cloud Platform (GCP) и Yandex Cloud. Несмотря на различия между облачными платформами, вы увидите, что принцип работы Terraform остаётся практически одинаковым.

Хочу поделится с более конкретным примером и подробным описанием настройки плагинов для ArgoCD чем это описано в их офф документации.

Два коммерческих сайта на WordPress, оба на одном VPS. Клиенты в одном городе, я сам в другом.

Начало июня. Клиенты жалуются, что сайт не открывается без VPN.

Мало ли, подумал я — ограничения, белые списки и т.д.

Потом сайт перестал открываться у меня. По проводу. Дома.

Три дня был потный танец с бубном:

Транзакционные письма — подтверждения регистрации, сброс пароля, чеки — кажутся простейшей задачей: подключил SMTP, вызвал send(), готово. Ровно до момента, когда письма начинают тихо улетать в спам Mail.ru и Яндекса, а ты не понимаешь почему: код не менялся, ошибок нет, письма «отправлены».

Дело почти никогда не в коде отправки. Дело в трёх DNS-записях, репутации IP-адреса и криптоподписи, которую надо собрать руками правильно.

Я строю свой сервис транзакционной почты и разобрал всю эту машинерию до винтика. В статье:

— DKIM своими руками: генерация ключа, каноникализация relaxed по RFC 6376, почему порядок подписываемых заголовков важен и где чаще всего ломается подпись; — три DNS-записи (SPF, DKIM, DMARC), которые решают всё, и что каждая делает; — прогрев IP: почему нельзя слать 50 тысяч писем с нового адреса, лестница лимитов 50 → 500 → 5000 → 50000 и пороги репутации; — suppression-лист и DMARC-отчёты как единственное зеркало вашего домена.

И кульминация — реальная грабля, на которой я обжёгся: две абсолютно правильные SPF-записи на одном домене, каждая валидна по отдельности, а вместе ломают доставляемость всего домена в ноль. Разбираю, почему так происходит и как чинится.

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

Привет! Я Даниил, DevOps-инженер в KTS.

Недавно я поработал со Stackland. Концепция облачноподобной платформы с кучей коробочных сервисов на своем железе в закрытом контуре давно была любопытна нам (и нашим заказчикам), так что пройти мимо готового решения от Яндекса было бы преступлением. По горячим следам я решил написать эту статью, чтобы поделиться опытом развертывания Stackland на голом железе. Так что ниже вас ждет скорее не обзор, а туториал.

Коротко о том, как это было: сначала я подготовил L2-сеть, бастион с NAT, DNS и NTP, три сервера, образ Stackland и YAML-конфиги. Затем запустил sladm install и через час получил консоль, готовый мониторинг с визуализацией в Grafana и возможность по кнопке в UI поднять managed PostgreSQL, Kafka, ClickHouse и другие сервисы.

Подробнее о том, как это было, рассказываю ниже.

Grafana показывала, что горит, Mattermost доставлял уведомления, но после смены дежурного приходилось заново выяснять, кто занимается проблемой и когда ждать результат. Рассказываю, как мы собрали поверх них рабочее место с владельцами, ETA, общей историей, группировкой каскадных алертов, инцидентами и postmortem — без отдельной базы данных и без передачи управления состоянием LLM.

10 июля мы выпустили Monq 9.2.0. Если описать релиз одной фразой: пороги получили собственное рабочее пространство, научились учитывать расписание, автоматически находить свою КЕ в CMDB и хранить прогноз собственного состояния. Для работы на больших объёмах хранение порогов перенесено из PostgreSQL в ClickHouse, а связанный конвейер сервисов переработан.

Перед вами обзор обновления отечественной observability платформы зонтичного мониторинга от вендора. Тут не будет обещаний «предсказать любую аварию» и общих слов про AIOps. Разберём точную механику, новые фичи, работу дежурной смены, нюансы обновления и честную границу между тем, что уже работает в 9.2, и адаптивными порогами, которые появятся в 9.3.

В целом статья будет о том, как превратить миллионы состояний в понятную работу дежурной смены, автоматизировать типовые реакции и реже отвлекать владельцев сервисов.

Часто первое, что хочется сделать при неполадках в кластере, — уменьшить его и надеяться, что всё решится само. Получается, большой кластер = куча проблем?

Автор статьи решил зайти максимально далеко: поднять Kubernetes-кластер с миллионом узлов и посмотреть, что будет.

Спойлер: получился вовсе не выстрел в ногу, а серьёзный эксперимент — много подготовки, обход ограничений, графики производительности и, конечно, ценные выводы. И даже инструкция в конце для желающих повторить.

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

Рано или поздно большинство зрелых проектов приходят к необходимости использовать как виртуальные машины, так и выделенные серверы. Это логично, поскольку под разные задачи требуются разные вычислительные ресурсы. Однако затем возникает проблема управления физическим оборудованием.

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

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

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

Но потом всё изменилось. Сначала пришли облака с докерами и кубернетесом. Так появились девопсы. Профессия стала меняться. Следом в продвинутых компаниях появились корпадмины — вроде менеджеров, но с техническим уклоном.

В итоге значительную часть работы теперь можно выполнять вообще на удалёнке!

Я сжёг на Hermes около 500 миллионов токенов. Это примерно $1000 при оплате моделей без подписок. Я дал агенту доступ к своей домашней лаборатории. Он написал несколько полезных скриптов. Настроил GPU passthrough и транскрибацию, но заодно ломал собственный gateway, ронял Caddy и регулярно игнорировал явно прописанные скиллы.

Это разбор реальной эксплуатации. Hermes иногда экономил мне время. Но слишком часто он проигрывал обычным скриптам и n8n. После полумиллиарда токенов Hermes оказался для меня дорогой игрушкой, а не рабочим инструментом.

Система блестит, дашборды красивые, а спросишь её что попроще — врёт. Потому что залили мёртвые данные и сократили углы на справочниках.

Рассказываю, как внедрял, где обжигался и что делаю теперь, чтоб не повторялось.

Что на самом деле защищает наши данные? Снапшоты, которые создаются за секунды и позволяют мгновенно откатиться к предыдущему состоянию? Регулярные резервные копии, которые хранятся на отдельном хранилище? Или репликация, которая обеспечивает непрерывность работы даже при сбое площадки?

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

В этой статье расскажем, почему снапшот — это вообще не бэкап, почему репликация не заменяет резервное копирование, какие требования предъявляются к современной системе защиты данных, и покажем, как эти принципы реализованы в связке VMmanager и RuBackup.

Короткая история про то, как штатная замена ноды оставила quorum-очереди с двумя членами вместо трёх, и почему cluster_status этого не показывает.

Стенд: OpenStack Caracal (2024.1), развёрнут kolla-ansible. RabbitMQ — кластер из трёх нод, quorum-очереди.