Системное администрирование *

Сегодня я расскажу, как с помощью системы Monq и ее инструмента low-code автоматизации можно эффективно настраивать мониторинг и управление инцидентами на примере интеграции с Zabbix. Будет описание ключевых элементов, включая создание и обработку сигналов, управление состоянием конфигурационных единиц и автоматизации процессов. А еще — полезные ссылки на бесплатную комьюнити версию и ранний доступ к облачной версии. Надеюсь, этот пост будет полезен специалистам, которые хотят оптимизировать мониторинг сложной ИТ-инфраструктуры, заодно улучшив управление инцидентами.

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

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

В современных условиях обеспечение стабильного и безопасного доступа к различным онлайн-сервисам становится всё более актуальной задачей. Хотя существует множество готовых VPN-решений, создание собственного VPN-сервера может предоставить ряд существенных преимуществ.

Всем привет! Сегодня я хочу поделиться с вами простым паттерном использования ansible к которому я пришёл за годы работы с этим инструментом. Несмотря на простоту, в типовой инфраструктуре он покрывает процентов 80 кейсов IaC, т.е. является довольно универсальным.

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

Kubernetes сейчас массово используют в ЦОДах и облачных решениях. Какие заслуги у Кубера, что было до него и почему сейчас он едва ли не стандарт отрасли. А ещё, как понять, что Кубер вам ни к чему.

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

Узнайте о ключевых изменениях в Deckhouse Kubernetes Platform за последние четыре релиза. Внедрение Grafana 10, поддержка Windows для Deckhouse CLI, автоматическая изоляция проблемных узлов с помощью Fencing, отказоустойчивый egress gateway и другие изменения, которые помогут улучшить управление кластерами.

Почему я задался целью обойти время применения политик к локальным компьютерам?

Обычный интерес — как это сделать. Как сказал один комментатор — работа ради работы.

Для чего все это надо — на это вопрос я сам себе не смог ответить. Но охота пуще неволи. Очень хотел найти решение.

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

В итоге нашел все необходимое. Нужное оставил, ненужное отсеял.

Привет, Хабр! Меня зовут Станислав Савостин, в СберТехе я занимаюсь системой мониторинга «Маяк». Это наш внутренний сервис, который основан на Prometheus, но включает много доработок и «тюнинга» под наши условия и стандарты работы.

Основная задача мониторинга — быстро выявить проблему (до того, как что‑то упало) и отреагировать, чтобы пользователи не заметили. Из‑за высокого темпа уведомлений и реакций часто возникает риск пойти по неправильному сценарию. Например, перезагрузка брокера Kafka или Artemis занимает около 30 секунд, поэтому упустить такую ситуацию легко, хотя для нас это критически важная метрика. Ложная тревога или задержка передачи метрик — максимально неприятные события, так что мы постоянно дорабатываем систему и уже научились отслеживать перезагрузки сервисов.

Я расскажу, как мы дорабатывали мониторинг, как реагируем на действительно опасные ситуации и что помогает нам ловить дзен, когда все кричат: «Волк!»

Компании, что используют Jenkins в качестве CI/CD‑инструмента, обычно делают несколько экземпляров, если в разработке участвует множество команд или приходится работать с большим количеством проектов. При этом оркестрация Jenkins»ов в командах — не самая простая работа, а во многом ещё и рутинная. С одной стороны, сложно соблюдать все требования сборки и тестирования и вовремя находить согласующих. С другой, одним скриптом невозможно решить всю задачу от получения доступов до вывода релизов в эксплуатацию.

Есть правило, что если система становится слишком сложной, то люди чаще ищут способы обойти алгоритмы, а не следовать им. Чтобы не усложнять систему, а разложить всё по ролям и этапам, мы пришли к созданию собственного инструмента — Orchestra R. С его помощью мы хотели не только автоматизировать работу конвейера CI/CD, но и упростить жизнь всех DevOps‑инженеров. В этом материале поделимся особенностями работы инструмента и опытом эксплуатации в СберТехе.

В данной статье пойдёт речь об особенностях UEFI на примере переноса Debian Stretch с MBR на UEFI. Опишу так же разницу между MBR и UEFI, так как я её воспринимаю.

Кроме общей части, ключевая часть статьи про формирование GRUB EFI файла grubx64.efi во время grub-install и про то, что этот файл не так прост, как кажется на первый взгляд.

При развертывании пары десятков контейнеров в Podman в rootless-режиме мы внезапно обнаружили, что они не могут одновременно использовать одни и те же порты, как это обычно работает при использовании Docker.

Решений несколько, но в рамках наложенных ограничений стандартные варианты не подходили. В итоге мы обратились к функционалу Podman Kube, который помог нам решить эту проблему. Подробнее о том, как это работает, и чем может быть полезно, ниже.

Привет! Меня зовут Игорь Латкин, я управляющий партнер и системный архитектор в KTS. Сегодня расскажу, как мы в компании выстраивали процессы деплоя приложений так, чтобы разработчики могли делать это самостоятельно. 

Поделюсь, как мы формируем регламенты в KTS и на каких «трёх китах» стоит инфраструктура глазами разработчика. Статья написана по мотивам моего доклада на kuberconf.io.

В статье расскажем о решении класса PAM (Privilege Access Management), а также рассмотрим, кто такие привилегированные пользователи и какую ключевую роль они играют в управлении доступом к критически важным системам и данным. Понимание особенностей этой роли и рисков, связанных с действиями привилегированных пользователей, является основой для разработки эффективных стратегий управления доступом и защиты информации.

Привет! Меня зовут Павел, и я руководитель офисной IT‑инфраструктуры в Яндексе. Не один год своей работы в той или иной степени я посвятил «Макам» и другим Apple‑устройствам. А в компании их сейчас уже больше 20 тысяч, и управлять таким парком — задача нетривиальная.

Надеюсь, что сегодняшняя тема будет интересна системным администраторам и инженерам поддержки пользователей на платформе macOS. Поговорим об Active Directory и альтернативах этому решению, обсудим, имеет ли смысл вводить компьютеры на macOS в домен и как это всё должно работать.

Ansible — система управления конфигурациями, написанная на языке программирования Python. Используется для автоматизации настройки и развертывания программного обеспечения. Обычно используется для управления Linux-узлами, но есть большая коллекция плагинов для подключения к другим устройствам и ОС. Наряду с Chef, Puppet и SaltStack считается одной из наиболее популярных систем управления конфигурациями для Linux. Главное отличие Ansible от аналогов — не нужна установка агента/клиента на целевые системы. С помощью Ansible можно развернуть, удалить или сконфигурировать любое ПО на удаленных серверах.

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

Недавно мы осуществили миграцию системы сбора наших инфраструктурных метрик с StatsD на Prometheus и остались весьма довольны результатами. Это была нелёгкая работа, но мы многому научились в процессе. Эта статья призвана рассказать, почему мы выбрали Prometheus, а также описать некоторые технические сложности, с которыми мы столкнулись.

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