👋 make-argocd-fly — генератор ArgoCD Applications.

Превращает шаблоны на базе Helm, Kustomize и Jinja2 в Kubernetes-манифесты, а также автоматически создает ресурсы Argo CD Application, адаптированные для разных окружений (например, dev, stage, prod).

Основной функционал:

✅Рендерит Helm-чарты и Kustomize-оверлеи в детерминированный YAML — видно, что именно будет применено в кластер.

✅Генерирует ресурсы Application для Argo CD на основе ваших шаблонов.

✅Поддерживает шаблоны на Jinja2 (переменные, логика, частичные шаблоны).

✅Работает с несколькими окружениями (dev/stage/prod) и раскладывает вывод по понятной структуре каталогов: output/<env>/<app>/…

✅Упрощает код-ревью: идентичные шаблоны всегда генерируют одинаковые манифесты, поэтому в Pull Request видно только смысловые изменения.

✅Установка:

pip install make-argocd-fly   # требуется Python ≥ 3.11

👉 Git
#полезное

Terraform — инструмент от HashiCorp для декларативного описания инфраструктуры через код (IaC).

Вы описываете желаемое состояние, а Terraform сам понимает, как его достичь.

⏰ Зачем

Упрощает управление инфраструктурой — нет ручных кликов в консолях. Обеспечивает повторяемость, аудит и коллаборацию. Идеально для DevOps: деплоите VPC, EC2 или K8s кластер одним apply.

⏰ Как используется

Пишем конфиг, запускаем terraform init (инициализация), terraform plan (превью изменений), terraform apply (применение). Для разрушения — terraform destroy. Поддерживает state-файлы для отслеживания изменений.

⏰ Модульность

Terraform поддерживает модули — переиспользуемые блоки кода.
Создайте модуль для VPC, и используйте его в разных проектах. Это как Lego: собирайте инфраструктуру из готовых частей, меняя переменные.

⏰ Универсальность языка HCL

HCL (HashiCorp Configuration Language) — декларативный язык Terraform.

Синтаксис одинаковый для всех облаков: ресурсы описываются блоками resource "aws_instance" {} или resource "google_compute_instance" {}. Разница только в провайдерах — плагинах для конкретных облаков (AWS, GCP). Один код — разные среды, легко мигрировать между провайдерами.

🔵 Terraform превращает ручное создание инфраструктуры в предсказуемый и повторяемый процесс. Один раз настроил — используешь везде.

#заметкиИнженера

💎 Terragrunt — тонкая обёртка над Terraform, которая устраняет повторяющийся код и упрощает управление сложной инфраструктурой.

🤔 Основной функционал

— Автоматическое управление зависимостями между модулями (dependencies)
— Поддержка нескольких окружений (dev/stage/prod) с общими настройками
— Интеграция с remote state для хранения состояния Terraform
— Hooks для выполнения скриптов до/после Terraform-операций
— Автоматизация команд Terraform (init, plan, apply) для всей инфраструктуры

🤔 Ключевые особенности

— Универсальность HCL: синтаксис Terraform (HCL) остаётся неизменным, Terragrunt добавляет надстройку для конфигураций
— Провайдер-независимость: работает с любыми облаками, отличия только в провайдерах, а код — единый
— Упрощение CI/CD: легко интегрируется в пайплайны для автоматизированного IaC

Terragrunt делает Terraform масштабируемым и удобным для команд, минимизируя повторения и ошибки.

👉 Git
#полезное

⚙️ Cloud-init — стандартная система инициализации для облачных экземпляров, которая выполняет начальную настройку при первом запуске ВМ. Поддерживается всеми major-облаками и гипервизорами.

✅ Как работает:

1. Образ ОС содержит cloud-init пакет
2. При старте ВМ cloud-init ищет данные конфигурации
3. Выполняет инструкции (пользователи, пакеты, скрипты)
4. Сохраняет логи в /var/log/cloud-init-output.log

✅ Основные возможности:
— Создание пользователей и настройка SSH-ключей
— Установка пакетов и обновление системы
— Настройка сетевых интерфейсов
— Выполнение custom-скриптов
— Монтирование дисков и настройка swap

🚪 Пример конфигурации:

#cloud-config
# Конфигурация пользователя 
users:
  - name: admin
    passwd: $6$rounds=4096$xyz$...  # хэш пароля
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    shell: /bin/bash

# Обновление пакетов
package_update: true
package_upgrade: true

# Установка сurl, htop, git
packages:
  - curl
  - htop
  - git

🤓 Cистема изначально разрабатывалась для Ubuntu, но стала де-факто стандартом и теперь поддерживается всеми major-дистрибутивами, включая CentOS, Debian и даже FreeBSD.

Cloud-init превращает создание новых серверов из рутины в автоматизированный процесс — один раз настроил конфиг и получаешь готовые к работе ВМ в любом облаке.

#линуксятина

🦎 Terraform: инфраструктура на уровне кода. 3-е межд. изд.

Практическое руководство по проектированию, развёртыванию и сопровождению облачной инфраструктуры с помощью Terraform.

🔎 Рассматривается:

— основы Terraform: синтаксис HCL, state-файлы, провайдеры;
— создание модулей, их тестирование и версионирование;
— управление состоянием в команде, блокировки и бэкенды;
— шаблоны проектирования и лучшие практики для продакшна;
— CI/CD для инфраструктурного кода.

Полезно архитекторам, DevOps- и SRE-инженерам, а также разработчикам, которые хотят уверенно строить и сопровождать надёжные, масштабируемые и управляемые системы в облаках.

Автор:
Yevgeniy Brikman.
Издательство:
O’Reilly, 3-е межд. изд., 2022.

#книги

💊 Кейс: миграция фармацевтической торговой сети в Public Cloud

Цель — повысить доступность ИТ-систем и снизить стоимость владения.

📞 Задача

— Обеспечить непрерывность работы ИТ-систем и устранить периодические недоступности критичных сервисов.

— Масштабировать ресурсы без длительных внутренних проектов.

— Провести миграцию в облако с минимальным влиянием на бизнес.

⭐️ Этапы реализации

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

— Провели тесты и подготовили план миграции.

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

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

— Проверка работоспособности и ввод в эксплуатацию.

— Настройка поддержки и регламентов взаимодействия 24×7.
CORTEL

🚩 Результат

— ТСО ↓ в 12 раз в первый год обслуживания за счёт перехода в облако.

— ROI +32% за трёхлетний период по сравнению с владением своей инфраструктурой.

— SLA 99,95% на облачной инфраструктуре.

— Масштабирование «по запросу» (например, оперативное добавление ядер/диска); CAPEX трансформирован в OPEX.

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

«Сервис позволил сократить операционные затраты и сосредоточиться на развитии бизнеса; миграция ночью прошла по плану с ожидаемым результатом», — Чингис Юндунов,
ИТ-директор «СИБИНТЕРФАРМ».

Подробнее о проекте читайте здесь

Все про Public Cloud — здесь

#изПрактики

🏓 Как добиться 100% SLA более чем на 90 дней

❕ Мы начали с метрик.
Зафиксировали SLI и SLO: аптайм, потери пакетов, конвергенция BGP, MTTR. На каждую метрику — пороги и автоматические действия. Если что-то уходит за границы — система реагирует раньше людей.

🔎 Сеть
Несколько независимых аплинков, приходящих на независимые взаиморезервируемые маршрутизаторы. BGP с community для инженерии трафика и blackhole. Мониторим префиксы, xFlow, задержки на магистралях. Роутинговые «что если» прогоняем заранее.

💻 Кластера
Только HA. Хранилища настроены под сценарий: синхронно для критичных RPO, асинхронно между площадками для DR. Регулярно проверяем репликацию и отработку аварий.

🛡 Прод
Любое изменение — через тестовые среды и поэтапный выпуск. Rate limiting и load shedding включаются до того, как пользователи заметят деградацию. Окна обслуживания — только в периоды минимальной активности и так, чтобы клиенты это "не почуствовали".

⚙️ Операции
Runbook’и подробные и точные: кто, что, за сколько минут. Проводим тестовые испытания: искусственные отказы, секундомер, разбор полётов. Ошибочный бюджет не «тратим» — предотвращаем инциденты раньше.

🗂 Прозрачность
Важные метрики — публичны.
За последние 90 дней:
0 инцидентов с влиянием на сервисы
0 минут простоя
100.000% аптайма.

Это видно здесь

Как говорит наш ДИТ:

«В нашем деле хорошо — это когда никто ничего не заметил. И вот уже 90 дней подряд мы ничем не удивляем.
100%. Ровно. Скучно. Красиво»

⚙️ Must-Have Cloud-Native утилиты

⚙️ K9s
— терминальный UI для управления Kubernetes кластерами с возможностью мониторинга ресурсов, диагностики и оперативного управления подами.

⚙️ Lens
— полнофункциональная IDE для Kubernetes с визуализацией кластера, встроенным терминалом и поддержкой расширений.

⚙️ Alertmanager
— компонент экосистемы Prometheus для обработки, группировки и маршрутизации оповещений с поддержкой различных каналов уведомлений.

⚙️ VictoriaMetrics
— высокопроизводительная и экономичная система мониторинга и хранения временных рядов, совместимая с Prometheus.

⚙️ Cert-manager
— автоматическое управление TLS-сертификатами в Kubernetes, включая выпуск, обновление и продление от Let's Encrypt и других CA.

#полезное

💻 Cloud Controller Manager в Kubernetes: интеграция с облаками

Компонент Kubernetes, который абстрагирует работу с API облачных провайдеров.

💬 Как работает

Изначально облачная логика была внутри kube-controller-manager. Начиная с Kubernetes 1.6, CCM выделен в отдельный процесс/Deployment и берёт на себя задачи, связанные с облаком: создание LoadBalancer, управление нодами, маршрутизация и пр.

💬 Из чего состоит

CCM включает контроллеры (node, route, service), которые отслеживают состояние кластера и вызывают облачные API для синхронизации. Например, при создании Service типа LoadBalancer CCM запрашивает у провайдера балансировщик. Это позволяет использовать Kubernetes в мультивендорных средах без «вшивания» логики конкретного облака в ядро.

💬 Что это даёт

✅ Абстракция от вендора. Кластер не привязан к одному облаку: меняете провайдера — меняете реализацию CCM.

✅ Динамическое управление ресурсами. Автоматическое создание и удаление объектов (LB, маршрутов, узлов) по мере необходимости.

✅ Гибкость и масштабирование. Поддержка частных облаков и on-prem через кастомные реализации CCM.

Примечание: для хранилищ сейчас обычно используются CSI-драйверы; исторически облачные диски интегрировались через провайдер в Kubernetes.

💬 Что может CCM

✅ LoadBalancer
Автоматически создаёт облачный балансировщик для Service.

✅ Node Management
Добавляет/удаляет ноды, выставляет providerID и метки (например, зона доступности).

✅ Маршруты/сети
Настраивает маршрутизацию между нодами, если это требуется конкретным провайдером.

✅ Автоскейлинг
CCM предоставляет интерфейс для Cluster Autoscaler, чтобы динамически добавлять/удалять ноды в облаке при изменении нагрузки. Без CCM автоскейлинг ограничен локальными кластерами; с ним — полноценно работает в облаке.

#полезное

☯️CCM: проблема «курица и яйцо» в Kubernetes

В официальном блоге Kubernetes есть статья о классической проблеме инициализации Cloud Controller Manager после выноса cloud-provider из ядра.

💬 Что не так с CCM?

— Зависимость от нод.
При старте kubelet с --cloud-provider=external получают запрещающую метку (taint)
node.cloudprovider.kubernetes.io/uninitialized:NoSchedule.

CCM должен снять эту запрещающую метку и добавить облачные сведения (адреса, метки). Если CCM развёрнут как Deployment/DaemonSet без необходимых допусков (tolerations), он может не запуститься на таких нодах.

— Каскадный эффект. Неинициализированные узлы блокируют запуск CCM, тот — снятие запрещающей метки. Параллельно CNI может ждать IP от CCM, узлы получают node.kubernetes.io/not-ready, и система зацикливается.

— Задержки.
Новый процесс инициализации добавляет задержки по сравнению с прежним поведением, когда kubelet сразу заполнял данные узла.

💬 Как исправить?

— hostNetwork: true.

Чтобы CCM использовал сетевой стек хоста и имел доступ к конечным точкам (endpoints) и API провайдера.

— Deployment/DaemonSet + механизм leader-election.

Разворачивайте как управляемый ресурс и включайте --leader-elect=true при нескольких репликах, чтобы избежать гонок.

— Размещение на control plane.

Задайте nodeSelector: { node-role.kubernetes.io/control-plane: "" } и добавьте podAntiAffinity, чтобы реплики не оказывались на одном хосте.

— Явные допуски (tolerations).

🟢Для старта на неинициализированных узлах:
node.cloudprovider.kubernetes.io/uninitialized:NoSchedule

🟢Для размещения на control plane:
node-role.kubernetes.io/control-plane:NoSchedule и/или node-role.kubernetes.io/master:NoSchedule

🟢Для устойчивости при инициализации:
node.kubernetes.io/not-ready:NoExecute и node.kubernetes.io/unreachable:NoExecute (иногда может потребоваться и NoSchedule).

Дополнение: автоскейлинг по размеру кластера для CCM не рекомендуется; несколько реплик нужны для отказоустойчивости, а не для ускорения работы.

💬 Если CCM работает вне управляемого им кластера (например, в hosted control plane), применимость советов зависит от конкретной топологии и ограничений среды. Это не «упрощённый» случай — проверяйте требования вашей архитектуры.

#заметкиИнженера

🖥 NFS (Network File System) — протокол для совместного доступа к файлам по сети, разработанный Sun Microsystems в 1984 году.

Позволяет монтировать удалённые директории как локальные, делая их доступными для нескольких хостов. Используется в кластерах, NAS и облаках для общего хранилища.

🟡 Как работает

— Архитектура «клиент-сервер»: сервер экспортирует каталоги, клиенты их монтируют
— RPC-протокол: для управления подключениями (порт 111)
— NFS-демоны: nfsd обрабатывает запросы, mountd управляет монтированием
— Версии протокола: NFSv3 (UDP/TCP), NFSv4 (TCP, встроенная аутентификация)

🟡 Базовая настройка на сервере

# Установка пакета
sudo apt install nfs-kernel-server

# Создаём экспортируемый каталог
sudo mkdir /srv/share
sudo chown nobody:nogroup /srv/share

Конфигурация /etc/exports:

/srv/share 192.168.1.0/24(rw,sync,no_subtree_check)

🟡 Ключевые атрибуты /etc/exports

— rw/ro — чтение-запись или только чтение
— sync/async — синхронная/асинхронная запись
— no_subtree_check — отключение проверки поддеревьев
— no_root_squash — доступ root без преобразования
— all_squash — всех пользователей отображать в nobody
— anonuid/anongid — явное указание UID/GID для анонимных пользователей

🟡 Настройка клиента

# Установка пакета
sudo apt install nfs-common

# Монтирование каталога
sudo mount -t nfs server-ip:/srv/share /local/mount

NFS — классика для общих файловых систем в Linux, идеально для кластеров или бэкапов

#линуксятина

☁️ Путь к Cloud-native: как изменилась разработка

От монолита на «железе» и каскада — к микросервисам в контейнерах, облаку и DevOps.

Четыре составляющие подхода:

— Процесс:
Waterfall сменили Agile и DevOps — короткие итерации, автоматизация, CI/CD.

— Архитектура:
от монолита к микросервисам с независимыми релизами.

— Развёртывание:
от серверов в стойках и ВМ к образам Docker и контейнерам.

— Инфраструктура: вместо своих стоек — облако как базовая среда.

#полезное

Кейс: Гибридное облако и DBaaS для поставщика электроэнергии

📞 Задача

⚪️Обеспечить гарантированную доступность ИТ-сервисов.

⚪️Сформировать целевую гибридную архитектуру с учётом территориальных ограничений и пошагового плана миграции.

⚪️Закрыть дефицит компетенций по администрированию СУБД через модель сервиса (DBaaS).

🖲️ Этапы реализации

⚪️Совместная рабочая группа: аудит текущей инфраструктуры, расчёт TCO и выбор сервисной модели.

⚪️Проектирование целевой гибридной архитектуры с размещением в ЦОД Новосибирска; подготовка ТЗ и требований к SLA.

⚪️План миграции с обходными сценариями под технические ограничения и распределённые площадки.

⚪️Перенос критичных сервисов поэтапно с контролем доступности; ввод в промышленную эксплуатацию.

⚪️Подключение DBaaS: обслуживание >200 БД (в т.ч. InterSystems IRIS и MS SQL) силами команды CORTEL.

⚪️Настройка 24×7 поддержки и регламентов взаимодействия по SLA.


🚩 Результат

⚪️Доступность 99,982% в год на новой гибридной архитектуре (ранее — 96,15%).

⚪️100% клиентов перешли на онлайн-сервисы благодаря модернизации и новому качеству обслуживания БД.

⚪️Выгода сервисной модели: −59% к TCO относительно модернизации собственных ЦОД (по расчёту до старта проекта).

⚪️Гарантированный SLA до 99,99% по критичным сервисам и работа 24×7 без зависимости от отпусков и замен в ИТ-штате.

⚪️Быстрое закрытие дефицита компетенций: DBaaS вместо долгого найма редких DBA под кастомные решения.

«Мы скрупулёзно проработали ТЗ и требования к качеству. На выбранной гибридной архитектуре обеспечили непрерывность работы приложений и предсказуемый SLA; команда CORTEL быстро погрузилась и качественно оказывает сервис».
— директор по ИТ «НовосибирскЭнергоСбыт»

✉️ Подробнее о проекте читайте здесь.

#изПрактики

😎 Дом, офис или гибрид

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

Чтобы не словить минусы удалёнки одиночество и изоляция, размытые границы дня и переработок, расфокус и «залипание» в ленте, а еще проблемы со спиной и лишним весом — нужен режим.

🤷‍♂️ Дисциплина — наше всё.

🥰 Начинать день с одного приоритетного дела.

😠 Развести типы задач по местам: офис — встречи, обсуждения, согласования; дом — письменная, проектная, инженерная работа.

😠 Организовать рабочую точку дома: стол, свет, удобный стул, наушники; фиксированное время начала и завершения; ритуал выхода (закрыт ноутбук — работа окончена).

🤙 Зарезервировать время для созвонов; в остальное время — асинхронные сообщения.

🎧 Поддерживать свой жизненный ресурс: вода под рукой; полноценный обед без встреч и скроллинга ленты.

А еще разминки для тела и глаз 🙃

😄 — дом
👍 — офис
🔥 — гибрид

P.S. Не забудьте закрыть ноутбук на эти два дня, хороших выходных✔️

#MentalDebug

⚠️ Как КИИ соответствовать новым требованиям

С 1 сентября 2025 года внесены изменения: новые сроки, официальный стандарт ПНСТ 1007-2025 и типовые отраслевые объекты.

➡️ Что сделать уже сейчас

🟡 Определить контур: реестр объектов КИИ и уровни значимости.

🟡 Сверить требования: ПНСТ 1007-2025 и типовые объекты/ перечень обязательных мер.

🟡 Составить перечень доработок: что добавить, что заменить, что убрать — с оценкой риска и трудозатрат.

🟡 Составить план до 01.01.2028 и 01.12.2030: приоритеты, сроки, владельцы, бюджет.

🟡 Оформить процессы: регламенты реагирования, журналы, роли, обучение.

🟡 Запустить контроль: метрики, квартальные ревизии, доказательная база для проверок.

👉 Подробнее читайте в новом материале

#статья

💻 Disruption Budget в Kubernetes: как не сломать сервис плановыми работами

PodDisruptionBudget (PDB) - это объект Kubernetes, который ограничивает количество одновременно недоступных подов во время добровольных вытеснений (voluntary disruptions).

🔵 Ключевое отличие:
PDB не защищает от аппаратных сбоев или проблем с нодами. Его задача — сделать плановые работы предсказуемыми и безопасными.

🔵 Зачем это нужно?

Без PDB:
— При drain ноды Kubernetes может одновременно выключить все поды
— Rolling update может убить старые поды до запуска новых
— Обновление кластера = лотерея доступности сервиса

С PDB:
— Гарантируется минимальное количество работающих реплик
— Контролируется максимальное количество одновременно недоступных подов
— Плановые работы перестают влиять на SLO

🔵 Примеры использования

💬 Защищаем критичное приложение

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: payment-service-pdb
spec:
  minAvailable: 2  # Всегда должно быть доступно не менее 2 подов
  selector:
    matchLabels:
      app: payment-service

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

💬 Постепенное обновление stateful-сервиса

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: kafka-pdb
spec:
  maxUnavailable: 1  # Одновременно может быть недоступен только 1 под
  selector:
    matchLabels:
      app: kafka-broker

Можно использовать для stateful-приложений (БД, очереди), где одновременный уход нескольких реплик может нарушить консистентность.

🔵 Как это работает на практике

— При drain ноды kubectl drain node-1 — kubelet проверяет PDB перед каждым вытеснением
— При rolling update — Deployment согласует обновление с ограничениями PDB
— При ручном удалении kubectl delete pod — PDB может заблокировать операцию

PodDisruptionBudget — это не опция, а обязательный инструмент для любого продакшн-сервиса в Kubernetes.

Он превращает потенциально опасные операции в контролируемые процессы и позволяет соблюдать SLO даже во время плановых работ.

#заметкиИнженера

💎 Chaos Mesh — платформа хаос-инжиниринга для Kubernetes.

Позволяет моделировать отказы и оркестровать сценарии через CRD и удобную веб-панель (Chaos Dashboard).

⚙️ Основной функционал:

— Типы экспериментов: PodChaos, NetworkChaos, IOChaos, TimeChaos, DNSChaos, StressChaos, KernelChaos, а также облачные сбои.

— Оркестрация сценариев через Chaos Workflows, в том числе проверки статуса и последовательности шагов.

— Управление через Kubernetes API/kubectl и Web-UI; все сущности оформлены как CRD.

— Безопасность: ограничение пространств имён, аутентификация, admission-webhook и RBAC-контроль.

— Интеграции: GitHub Actions (chaos-mesh-action) для запуска экспериментов в CI.

— Установка через Helm-чарт

Полезно для проверки устойчивости сервисов к сбоям до продакшена и выявления «узких мест» инфраструктуры.

👉 Git
#полезное

📊 Мониторинг системных метрик в Linux

В Linux есть встроенные утилиты для анализа в реальном времени

↗️ Что и чем смотреть

— top / htop: Мониторинг процессов, CPU, памяти в реальном времени.
— iostat: Статистика ввода-вывода (диски, I/O bottlenecks).
— vmstat: Виртуальная память, CPU, процессы (общая нагрузка).
— netstat / ss: Сетевые соединения, порты, статистика трафика.

↗️ Основное использование:

🟡 top: Интерактивный мониторинг процессов.

top # запуск, Shift+P для сортировки по CPU, Shift+M по памяти q для выхода.

🟡 htop: Улучшенный top с цветами, мышью и деревом процессов.

htop # аналогично top, но удобнее;

🟡 iostat: I/O статистика по дискам.

iostat -x 1 5 # расширенный вывод, интервал 1с, 5 итераций

(показывает %util — загрузку дисков, await — время отклика).

🟡 vmstat: Краткий обзор системы.

vmstat 1 5 # интервал 1с, 5 итераций

(показывает r/b — процессы в очереди/блоке, swpd — swap, si/so — swap in/out).

🟡 netstat / ss: Сетевые соединения.

netstat -tuln # TCP/UDP listening порты
ss -tuln # аналог netstat
ss -tp 'state established' # активные TCP-соединения с процессами.

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

#линуксятина

⏰ Site Reliability Engineering — набор инженерных практик для стабильного сервиса, предсказуемых рисков и затрат.

➡️ Функции SRE влияют на ключевые показатели:
SLA/SLO — обещанная и целевая доступность;
MTTR/MTBF — скорость восстановления и частота отказов;
RTO/RPO— время восстановления и допустимые потери данных при аварии;
TCO— совокупная стоимость владения.

Разберём их в виде глоссария:

🟢SLI/SLO/SLA

Фиксирует качество сервиса в числах: доступность, ошибки, время ответа.

*обеспечивает выполнение обязательств, снижает штрафы и споры, задаёт понятные приоритеты.

🟢Incident Response

Стандартизирует действия во время сбоя.

*сокращает MTTR, уменьшает потери выручки и репутации, помогает удерживать SLA/SLO.

🟢 Postmortem

Фиксирует, что произошло, почему это случилось и что нужно изменить, чтобы больше не повторилось.

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

🟢Observability

Диагностирует неизвестные проблемы через исследование метрик, логов и трейсов.

* уменьшает время диагностики, поддерживает достижение SLO, убирает «слепые зоны».

🟢 Progressive Delivery

Проводит поэтапный вывод обновлений с контролем трафика и быстрым откатом при проблемах.

* снижает релиз-инциденты, сокращает MTTR, уменьшает стоимость сбоев.

🟢 HA и DR

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

* предсказуемые RTO/RPO, соблюдение требований, меньше простоев и ниже TCO.

🟢Автоматизация и runbook-и

Стандартизирует и автоматизирует типовые операции: перезапуск, откат, переключение трафика и т.д.

*сокращает MTTR и операционную рутину (toil), обеспечивает предсказуемые результаты.

🟢Chaos Engineering

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

*снижает частоту и длительность сбоёв, помогает удерживать SLA/SLO, уменьшает незапланированные расходы.

🟢 Управление toil

Измеряет повторяющиеся ручные задачи и устраняет их.

*высвобождает время инженеров на улучшения и фичи, уменьшает TCO.

#полезное

😎 Настоящий SRE: инжиниринг надежности для специалистов и организаций

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

🔎 Рассматривается:

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

Полезно начинающим и действующим SR-инженерам, DevOps- и платформенным командам, инженерам эксплуатации, техлидам и руководителям ИТ, которые хотят системно подойти к надежности и выстроить зрелую практику SRE в своей организации.

Автор:
Дэвид Н. Бланк-Эдельман.
Издательство:
O’Reilly / «Спринт Бук», рус. изд., 2025.

#книги

🚂 sl: поезд вместо ls

sl — консольная утилита, которая запускает анимацию паровоза в ASCII-графике, когда вы вместо ls набираете sl .

👍 Это исторический Unix-розыгрыш: его придумали, чтобы «наказывать» вечных опечатывающихся.

Работает как обычная команда:
ввёл sl — поехал поезд, терминал на пару секунд превращается в анимированный скринсейвер.

😈 Можно развлечь своих коллег.

⌨️ Установка

# Debian / Ubuntu
sudo apt install sl

# Fedora
sudo dnf install sl

# Arch / Manjaro
sudo pacman -S sl

P.S. хороших выходных ☺️

#rootoffun