Виртуализация KVM и контейнеризация Podman


KVM (Kernel-based Virtual Machine) — встроенное в ядро Linux решение для виртуализации. Управление через libvirt.

Команды:


 • virsh list --all — список всех ВМ
 • virsh start — запуск
 • virsh shutdown — корректное выключение (ACPI)
 • virsh destroy — принудительное выключение


Графический интерфейс — virt-manager.

Podman — демон-less инструмент для управления контейнерами (безопаснее Docker). Команды совместимы с Docker:


 • podman run — запуск контейнера
 • podman ps — список запущенных
 • Ключи: -it (интерактив), --rm (автоудаление), -d (фон)


Осваивайте виртуализацию с Riqli

Мониторинг и управление процессами


top — динамический мониторинг процессов в реальном времени. Показывает загрузку CPU, памяти и swap.

Клавиши в top:


 • P — сортировка по CPU
 • M — сортировка по памяти
 • k — убить процесс
 • r — изменить приоритет
 • q — выход


Более современная альтернатива — htop.

Управление приоритетами:


 • nice -n 5 command — запуск с приоритетом
 • renice -n 10 -p 1234 — изменение приоритета работающего процесса


Диапазон nice: от -20 (высший приоритет) до 19 (низший). Только root может устанавливать
отрицательные значения.

Сигналы: SIGTERM (15) — вежливое завершение, SIGKILL (9) — принудительное.

Мониторьте системы с Riqli

Управление дисками и LVM


Управление дисками:


 • df -h — свободное место (human-readable)
 • du -sh — размер каталога
 • fdisk -l — список разделов
 • mkfs.ext4 — создание файловой системы
 • mount / umount — монтирование
 • /etc/fstab — автоматическое монтирование при загрузке


LVM (Logical Volume Manager):


 • PV (Physical Volume) — физический диск/раздел
 • VG (Volume Group) — объединение PV
 • LV (Logical Volume) — виртуальный раздел


Команды: pvcreate, vgcreate, lvcreate

Расширение: lvextend + resize2fs (ext4) или xfs_growfs (XFS)

Snapshots — снимки состояния для резервного копирования

Управляйте хранилищем с Riqli

Наблюдаемость в распределенных системах


Современные ИТ-системы — это сложные распределенные системы, где тысячи микросервисов взаимодействуют в облачных средах.

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

Ключевая проблема: данные телеметрии (журналы, метрики, трассировки) исторически собирались изолированно — как «три столпа». Для глубокого понимания распределенных транзакций необходима корреляция этих данных.

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

Внедряйте наблюдаемость с Riqli

Архитектура и компоненты OpenTelemetry


Архитектура OpenTelemetry построена вокруг трёх ключевых компонентов:


 1. API — для инструментирования кода
 2. SDK — для обработки и экспорта данных
 3. OTLP (OpenTelemetry Protocol) — для передачи телеметрии


Отдельно выделяется OpenTelemetry Collector — гибкий агент для приёма, обработки и маршрутизации данных.

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

В основе лежат семантические конвенции — согласованные правила именования атрибутов для ресурсов, HTTP-запросов и баз данных. Это гарантирует одинаковую интерпретацию телеметрии из разных источников.

Строите наблюдаемые системы с Riqli

Инструментирование приложений и библиотек


Инструментирование — процесс добавления кода для генерации трассировок, метрик и журналов.

Два подхода:


 • Автоматическое инструментирование — через агенты (например, Java-агент)
 • Ручное — внедрение вызовов API в бизнес-логику


Ключевой принцип — добавление контекста:


 • Жёсткий (идентификаторы транзакций) — для связывания запросов
 • Мягкий (атрибуты) — для фильтрации и группировки данных


Нативное инструментирование библиотек — важная практика. Внедряя вызовы OpenTelemetry API в код, авторы библиотек обеспечивают работу наблюдаемости «по умолчанию» для всех пользователей. Это исключает необходимость в сторонних плагинах.

Семантические конвенции обеспечивают согласованность и обратную совместимость.

Инструментируйте приложения с Riqli

Наблюдаемость инфраструктуры и конвейеры телеметрии


Наблюдаемость инфраструктуры выходит за рамки сбора метрик хоста и включает интеграцию с данными от облачных провайдеров (AWS, GCP), платформ (Kubernetes) и бессерверных сред.

OpenTelemetry Collector— центральный элемент для сбора этих данных. Он позволяет:


 • Фильтровать — удаление шума (проверок работоспособности)
 • Преобразовывать — очистка персональной информации
 • Обогащать — добавление атрибутов (идентификатор кластера, регион)


Проектирование конвейера предполагает выбор топологии: от локальных экземпляров Collector до масштабируемых пулов.

Хвостовая выборка (tail sampling)сохраняет только проблемные трассировки — эффективная стратегия управления затратами.

Проектируйте конвейеры телеметрии с Riqli

Управление затратами телеметрии


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

Стратегии:


 • Дедупликация журналов — удаление повторяющихся записей
 • Преобразование трассировок в метрики — для долгосрочного хранения
 • Сжатые протоколы (например, OTel Arrow) — снижение объёма передачи
 • Хвостовая выборка — сохранение только проблемных трассировок


Успех внедрения зависит от организационного подхода: выбор между глубоким инструментированием отдельных сервисов и широким внедрением по всей системе.

Баланс между наблюдаемостью и стоимостью — ключевая задача для инженеров.

Оптимизируйте затраты на телеметрию с Riqli

Управление затратами телеметрии


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

Стратегии:


 • Дедупликация журналов — удаление повторяющихся записей
 • Преобразование трассировок в метрики — для долгосрочного хранения
 • Сжатые протоколы (например, OTel Arrow) — снижение объёма передачи
 • Хвостовая выборка — сохранение только проблемных трассировок


Успех внедрения зависит от организационного подхода: выбор между глубоким инструментированием отдельных сервисов и широким внедрением по всей системе.

Баланс между наблюдаемостью и стоимостью — ключевая задача для инженеров.

Оптимизируйте затраты на телеметрию с Riqli

Внедрение OpenTelemetry: техническая и организационная трансформация


Внедрение OpenTelemetry — не только техническая задача, но и организационная трансформация.

Стратегии внедрения:


 • «В глубину» — фокус на критических транзакциях
 • «В ширину» — охват максимального количества сервисов


Успех зависит от:


 • Поддержки руководства
 • Создания базы знаний
 • Бесшовной миграции (без нарушения существующих систем оповещения)


OpenTelemetry становится индустриальным стандартом. Его использование сегодня — инвестиция в будущее, гарантирующая, что система останется понятной и управляемой.

Внедряйте наблюдаемость системно с Riqli

Будущее наблюдаемости: ИИ и «зелёная» наблюдаемость


Будущее наблюдаемости связано с двумя ключевыми направлениями:


 1. Интеграция искусственного интеллекта — для автоматического анализа данных и выявления аномалий. ИИ помогает обнаруживать скрытые зависимости и предсказывать инциденты.
 2. «Зелёная наблюдаемость» (Green Observability) — отслеживание энергопотребления систем. Это важно для устойчивого развития и снижения углеродного следа.


OpenTelemetry продолжает эволюционировать, стремясь к стабильности и расширению. Проект становится стандартом для управления системами.

Использование современных подходов к мониторингу — залог управляемой инфраструктуры.

Строите будущее наблюдаемости с Riqli

Git vs GitHub: в чем разница


Частая путаница у новичков: Git и GitHub — не одно и то же.

Git — распределённая система контроля версий (DVCS). Работает локально, хранит полную историю проекта у каждого разработчика. Создан Линусом Торвальдсом в 2005 году для разработки Linux.

GitHub — веб-сервис для хостинга Git-репозиториев. Добавляет коллаборацию: Pull Requests, code review, Issues, GitHub Actions (CI/CD).

Ключевое преимущество Git как DVCS — независимость: можно работать офлайн, полная история доступна локально. Это критично для больших команд.

Git хранит данные контентно-адресуемо (хеш-суммы SHA-1), что обеспечивает целостность.

Осваивайте версионный контроль с Riqli

Git кроссплатформенный: Windows, Linux, macOS

Установка:


 • Linux: apt install git
 • macOS: brew install git
 • Windows: официальный установщик с git-scm.com


Базовая настройка (обязательно):

bash

git config --global user.name "Ваше Имя"
git config --global user.email "you@example.com"

Без настройки коммиты будут анонимными.

Полезные настройки:


 • core.editor vim — редактор для сообщений
 • init.defaultBranch main — ветка по умолчанию
 • alias.co checkout — алиасы


Для GitHub: настройте SSH-ключи (ssh-keygen, ssh-add) или Personal Access Token.

Проверка: git config --list.

Настраивайте окружение с Riqli

Создание и клонирование репозиториев


Создание репозитория:

bash

mkdir project
cd project
git init

Инициализирует папку .git со всей историей.

Клонирование:

bash

git clone https://github.com/user/repo.git

Создаёт локальную копию с полной историей.

Для экономии места:

bash

git clone --depth 1 https://github.com/user/repo.git

git status — запускайте часто. Показывает:


 • modified — изменённые
 • staged — готовые к коммиту
 • untracked — новые


После изменений: git add file.txt или git add .

Анти-паттерн: git init в корне домашней директории.

Используйте .gitignore для node_modules, .env, *.log.

Управляйте репозиториями с Riqli

Коммит — атомарное сохранение изменений:

bash

git commit -m "Add user authentication"

Сообщения — в повелительном наклонении.

Conventional Commits:
 • feat: — новая функция
 • fix: — исправление
 • docs: — документация


История:
 • git log — полная
 • git log --oneline --graph — визуализация
 • git log --pretty=format:"%h - %an, %ar : %s" — кастом


Различия:
 • git diff — рабочая директория
 • git diff --staged — индекс


Отмена:
 • git checkout -- file.txt — откат файла
 • git reset HEAD~1 — откат коммита
 • git commit --amend — правка последнего (если не запушен)
 • git reflog — восстановление


Работайте с историей с Riqli

Ветвление — ключевая возможность Git: изолирует изменения, позволяет работать параллельно

Создание и переключение:

bash

git branch feature/new-ui    # создать
git switch feature/new-ui    # переключиться
git checkout -b feature/new  # создать + переключиться

Feature branch workflow — стандарт: ветка под задачу, затем merge в main.

Слияние:

bash

git checkout main
git pull
git merge feature/new-ui

Конфликты: маркеры <<<<<<<, =======, >>>>>>>. Правьте вручную, затем git add и git commit.

Rebase— для линейной истории. Осторожно: не в общих ветках, переписывает хеши.

Best practice: короткоживущие ветки, частые merge.

Управляйте ветками с Riqli

Работа с GitHub: Pull Requests и CI/CD


GitHub — центральная платформа для коллаборации.

Связка с удалённым репозиторием:

bash

git remote add origin https://github.com/user/repo.git
git push -u origin main

Pull Requests (PR) — основной механизм code review:


 1. Создайте feature branch
 2. Push на GitHub
 3. Откройте PR
 4. Запросите reviewers
 5. Обсудите изменения
 6. Merge после одобрения


Draft PR для работы в процессе (WIP).

GitHub Actions для CI/CD: автоматический запуск тестов при PR.

Protected branches: требуйте status checks и approvals перед merge в main.

Дополнительно:


 • Issues — для задач
 • Projects — Kanban-доски
 • Releases — версионирование
 • Fork — для contributions в open-source


Безопасность: настройте two-factor auth, используйте SSH или PAT.

Работайте в команде с Riqli

Продвинутые техники: stash, cherry-pick, hooks

git stash — временное сохранение изменений:

bash

git stash        # сохранить
git stash pop    # вернуть

Полезно перед git pull.

git cherry-pick — перенос конкретного коммита в другую ветку:

bash

git cherry-pick abc123

Для bugfix из feature-ветки в main.

Git hooks — автоматические скрипты:


 • pre-commit — linting, тесты
 • post-merge — после слияния
 • pre-push — перед отправкой


Хранятся в .git/hooks. Сделайте исполняемыми: chmod +x.

Для команды — Husky или pre-commit framework.

git gc — оптимизация репозитория.

Tags: git tag v1.0 и git push --tags.

Применяйте техники с Riqli

YAML: основа синтаксиса GitHub Actions


GitHub Actions использует YAML для написания workflow. В отличие от JSON, YAML поддерживает комментарии — код становится читаемее.

Основная структура — единый корневой объект с ключами и значениями.

Типы данных:

— строки
— числа
— булевы значения (true/false)
— массивы
— вложенные объекты

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

Для упрощения работы с синтаксисом устанавливайте плагины для редакторов кода — они подсвечивают ошибки.

Осваивайте GitHub Actions с Riqli

Создание и настройка первого Workflow


Для создания Workflow в корне репозитория создайте каталог .github/workflows и поместите туда файл .yml или .yaml.

Основные элементы:

— name — имя workflow
— on — событие-триггер
— jobs — задачи

Пример: on: push запускает workflow при каждом пуше в репозиторий.

Внутри jobs описываются задачи. Они могут выполняться параллельно или последовательно.
Каждый job выполняется на виртуальной машине (runner), которую определяет параметр runs-on.

Внутри job находятся steps — шаги. Это либо команды оболочки, либо готовые actions.

Настраивайте пайплайны с Riqli