CORTEL
前往频道在 Telegram
Помогаем ИТ-директорам, DevOps и системным инженерам снижать TCO и поднимать SLA. Кейсы, инструменты и гайды. Сайт: https://cortel.cloud Cотрудничество: @ivan_cmo
显示更多4 059
订阅者
-124 小时
-47 天
-1030 天
数据加载中...
相似频道
标签云
进出提及
---
---
---
---
---
---
吸引订阅者
七月 '26
七月 '26
+16
在5个频道中
六月 '26
+18
在1个频道中
Get PRO
五月 '26
+23
在2个频道中
Get PRO
四月 '26
+17
在0个频道中
Get PRO
三月 '26
+55
在4个频道中
Get PRO
二月 '26
+53
在2个频道中
Get PRO
一月 '26
+74
在2个频道中
Get PRO
十二月 '25
+147
在7个频道中
Get PRO
十一月 '25
+72
在4个频道中
Get PRO
十月 '25
+139
在6个频道中
Get PRO
九月 '25
+80
在6个频道中
Get PRO
八月 '25
+87
在7个频道中
Get PRO
七月 '25
+135
在7个频道中
Get PRO
六月 '25
+116
在6个频道中
Get PRO
五月 '25
+160
在3个频道中
Get PRO
四月 '25
+137
在6个频道中
Get PRO
三月 '25
+123
在5个频道中
Get PRO
二月 '25
+203
在6个频道中
Get PRO
一月 '25
+152
在5个频道中
Get PRO
十二月 '24
+314
在8个频道中
Get PRO
十一月 '24
+141
在7个频道中
Get PRO
十月 '24
+192
在5个频道中
Get PRO
九月 '24
+104
在3个频道中
Get PRO
八月 '24
+216
在8个频道中
Get PRO
七月 '24
+219
在7个频道中
Get PRO
六月 '24
+163
在3个频道中
Get PRO
五月 '24
+185
在11个频道中
Get PRO
四月 '24
+82
在2个频道中
Get PRO
三月 '24
+100
在1个频道中
Get PRO
二月 '24
+223
在3个频道中
Get PRO
一月 '24
+130
在4个频道中
Get PRO
十二月 '23
+33
在7个频道中
Get PRO
十一月 '23
+110
在1个频道中
Get PRO
十月 '23
+127
在7个频道中
Get PRO
九月 '23
+146
在0个频道中
Get PRO
八月 '23
+104
在0个频道中
Get PRO
七月 '23
+147
在0个频道中
Get PRO
六月 '23
+229
在0个频道中
Get PRO
五月 '23
+107
在0个频道中
Get PRO
四月 '23
+126
在0个频道中
Get PRO
三月 '23
+156
在0个频道中
Get PRO
二月 '23
+384
在0个频道中
Get PRO
一月 '23
+40
在0个频道中
Get PRO
十二月 '22
+3
在0个频道中
Get PRO
十一月 '22
+2
在0个频道中
Get PRO
十月 '22
+76
在0个频道中
Get PRO
九月 '22
+251
在0个频道中
| 日期 | 订阅者增长 | 提及 | 频道 | |
| 22 七月 | +2 | |||
| 21 七月 | 0 | |||
| 20 七月 | 0 | |||
| 19 七月 | 0 | |||
| 18 七月 | 0 | |||
| 17 七月 | +1 | |||
| 16 七月 | +2 | |||
| 15 七月 | 0 | |||
| 14 七月 | 0 | |||
| 13 七月 | +1 | |||
| 12 七月 | 0 | |||
| 11 七月 | +2 | |||
| 10 七月 | +2 | |||
| 09 七月 | 0 | |||
| 08 七月 | 0 | |||
| 07 七月 | 0 | |||
| 06 七月 | +2 | |||
| 05 七月 | 0 | |||
| 04 七月 | 0 | |||
| 03 七月 | +2 | |||
| 02 七月 | +2 | |||
| 01 七月 | 0 |
频道帖子
📝 Шпаргалка по Logging, Tracing и Metrics.
Помогает понять, как устроен мониторинг в распределённых системах: что измерять, где искать события и как восстанавливать путь запроса между сервисами.
➡️ Три компонента мониторинга
— Metrics (метрики)
Числовые показатели системы во времени: загрузка CPU и памяти, RPS, задержка, процент ошибок, количество запросов, доступность сервисов. Метрики хорошо подходят для дашбордов, алертов и быстрой оценки состояния системы.
— Logging (логирование)
События, которые происходят внутри приложения или инфраструктуры: ошибки, предупреждения, действия пользователя, сбои интеграций, системные сообщения. Логи помогают разбирать конкретные инциденты и понимать, что произошло внутри сервиса.
— Tracing (трассировка запросов)
Путь одного запроса через несколько сервисов. Особенно полезно в микросервисной архитектуре, где один пользовательский запрос может пройти через API, очередь, базу данных и несколько внутренних сервисов.
➡️ Как это обычно собирается
— Метрики сервисов отправляются в базы данных для мониторинга: Prometheus, InfluxDB, VictoriaMetrics
— Логи собираются с хостов и приложений, затем передаются в хранилище и систему анализа: Logstash, Elasticsearch, Kibana.
— Трейсы собираются через OpenTelemetry: SDK, API, auto instrumentation и OTel Collector.
— Дальше данные можно передавать в разные системы анализа и визуализации: Grafana, DataSet, Lightstep, Honeycomb, Jaeger.
➡️ Где что использовать
➡️ метрики — чтобы быстро увидеть состояние системы;
➡️ логи — чтобы разобрать конкретную ошибку;
➡️ трейсы — чтобы проследить путь запроса между сервисами;
➡️ OpenTelemetry — чтобы стандартизировать сбор телеметрии и сохранить свободу выбора инструментов. - вот это лишнее, потому что тоже самое что и трейсы, но по факту это инструмент для трейсов.
В рабочей системе эти три слоя обычно используются вместе: метрики показывают отклонение, логи дают детали, а трейсы помогают найти участок, где запрос начал тормозить или завершился ошибкой.
#полезное
| 2 |  💻 Job и CronJob: разовые и периодические задачи в Kubernetes
Deployment создан для приложений, которые должны работать постоянно: упал под — контроллер тут же поднимет новый. Но не всякая нагрузка такая. Миграция базы, генерация отчёта, очистка старых данных — задачи, которые должны выполниться до конца и завершиться. Для них в Kubernetes есть Job и CronJob.
💬 Job — задача, которая должна завершиться успешно
Job создаёт под (или несколько) и следит не за тем, чтобы он работал, а за тем, чтобы он успешно завершился (exit code 0). Если под упал — Job перезапустит его, пока задача не выполнится или не исчерпается лимит попыток.
apiVersion: batch/v1
kind: Job
metadata:
name: db-migration
spec:
backoffLimit: 3 # максимум 3 повторные попытки
activeDeadlineSeconds: 600 # убить задачу, если не уложилась в 10 минут
ttlSecondsAfterFinished: 3600 # удалить Job через час после завершения
template:
spec:
restartPolicy: Never
containers:
- name: migrate
image: myapp:1.07
command: ["python", "manage.py", "migrate"]
Ключевые параметры:
— backoffLimit — сколько раз перезапускать упавшую задачу (по умолчанию 6, с экспоненциальной задержкой);
— completions и parallelism — сколько успешных выполнений требуется и сколько подов могут работать одновременно. Так реализуется параллельная обработка очереди;
— activeDeadlineSeconds — жёсткий таймаут на всю задачу;
— ttlSecondsAfterFinished — автоочистка завершённых Job. Без него завершённые поды и объекты Job копятся в кластере бесконечно.
💬 CronJob — Job по расписанию
CronJob — это контроллер, который по расписанию (классический cron-синтаксис) создаёт объекты Job. Сам он ничего не выполняет — только штампует Job'ы в нужный момент.
apiVersion: batch/v1
kind: CronJob
metadata:
name: report-generator
spec:
schedule: "0 3 * * *" # каждый день в 03:00
concurrencyPolicy: Forbid # не запускать новый, пока работает старый
startingDeadlineSeconds: 300
successfulJobsHistoryLimit: 3
failedJobsHistoryLimit: 5
jobTemplate:
spec:
backoffLimit: 2
template:
spec:
restartPolicy: Never
containers:
- name: report
image: reports:2.1
➡️ На что обратить внимание:
— concurrencyPolicy — что делать, если предыдущий запуск ещё не завершился: Allow (запускать параллельно), Forbid (пропустить новый), Replace (убить старый и запустить новый). Для долгих задач Allow по умолчанию — частый источник проблем;
— startingDeadlineSeconds — если запуск был пропущен (например, control plane был недоступен), в течение этого окна CronJob ещё попытается его выполнить;
— расписание считается в часовом поясе kube-controller-manager, но можно задать явно через поле timeZone.
Job и CronJob закрывают целый класс задач, для которого Deployment не предназначен: конечные и периодические процессы. Правильно выставленные лимиты попыток, таймауты и политики очистки превращают их в надёжный инструмент автоматизации внутри кластера.
#заметкиИнженера | 564 |
| 3 | 💻 Job и CronJob: разовые и периодические задачи в Kubernetes
Deployment создан для приложений, которые должны работать постоянно: упал под — контроллер тут же поднимет новый. Но не всякая нагрузка такая. Миграция базы, генерация отчёта, очистка старых данных — задачи, которые должны выполниться до конца и завершиться. Для них в Kubernetes есть Job и CronJob.
💬 Job — задача, которая должна завершиться успешно
Job создаёт под (или несколько) и следит не за тем, чтобы он работал, а за тем, чтобы он успешно завершился (exit code 0). Если под упал — Job перезапустит его, пока задача не выполнится или не исчерпается лимит попыток.
apiVersion: batch/v1
kind: Job
metadata:
name: db-migration
spec:
backoffLimit: 3 # максимум 3 повторные попытки
activeDeadlineSeconds: 600 # убить задачу, если не уложилась в 10 минут
ttlSecondsAfterFinished: 3600 # удалить Job через час после завершения
template:
spec:
restartPolicy: Never
containers:
- name: migrate
image: myapp:1.07
command: ["python", "manage.py", "migrate"]
Ключевые параметры:
— backoffLimit — сколько раз перезапускать упавшую задачу (по умолчанию 6, с экспоненциальной задержкой);
— completions и parallelism — сколько успешных выполнений требуется и сколько подов могут работать одновременно. Так реализуется параллельная обработка очереди;
— activeDeadlineSeconds — жёсткий таймаут на всю задачу;
— ttlSecondsAfterFinished — автоочистка завершённых Job. Без него завершённые поды и объекты Job копятся в кластере бесконечно.
💬 CronJob — Job по расписанию
CronJob — это контроллер, который по расписанию (классический cron-синтаксис) создаёт объекты Job. Сам он ничего не выполняет — только штампует Job'ы в нужный момент.
apiVersion: batch/v1
kind: CronJob
metadata:
name: report-generator
spec:
schedule: "0 3 * * *" # каждый день в 03:00
concurrencyPolicy: Forbid # не запускать новый, пока работает старый
startingDeadlineSeconds: 300
successfulJobsHistoryLimit: 3
failedJobsHistoryLimit: 5
jobTemplate:
spec:
backoffLimit: 2
template:
spec:
restartPolicy: Never
containers:
- name: report
image: reports:2.1
➡️ На что обратить внимание:
— concurrencyPolicy — что делать, если предыдущий запуск ещё не завершился: Allow (запускать параллельно), Forbid (пропустить новый), Replace (убить старый и запустить новый). Для долгих задач Allow по умолчанию — частый источник проблем;
— startingDeadlineSeconds — если запуск был пропущен (например, control plane был недоступен), в течение этого окна CronJob ещё попытается его выполнить;
— расписание считается в часовом поясе kube-controller-manager, но можно задать явно через поле timeZone.
Job и CronJob закрывают целый класс задач, для которого Deployment не предназначен: конечные и периодические процессы. Правильно выставленные лимиты попыток, таймауты и политики очистки превращают их в надёжный инструмент автоматизации внутри кластера.
#заметкиИнженера | 1 |
| 4 |  🤑 Как заработать с инфраструктуры больше?
Мы подняли партнёрское вознаграждение до 100% первого платежа клиента и гарантируем регулярный доход до 20% с дальнейших оплат.
Если назрела задача по VPS, облаку, бэкапам, каналам или чувствительным данным — можно дополнительно заработать в CORTEL : ребята подключатся, разберут задачу, подготовят решение, запустят инфраструктуру и будут поддерживать её 24/7, а вы получите регулярный дополнительный доход.
Выплаты не отменяются через год — вы продолжаете зарабатывать, пока клиент с нами. А сумма заработка не ограничена сверху 😊
📣 Полные условия и регистрация тут. | 709 |
| 5 |  🇷🇺 Импортозамещение VMware: куда и как переезжать в 2026 году
Как перестроить виртуальную инфраструктуру так, чтобы она пережила требования регуляторов, отсутствие западного саппорта, смену поколений железа, рост требований к сети и хранению — и при этом не убила эксплуатацию.
Разобрали в новом материале.
#статья | 759 |
| 6 |  🖥 AWK — мощный язык обработки текста, заточенный под построчный разбор данных по колонкам.
Назван по фамилиям создателей (Aho, Weinberger, Kernighan). Незаменим там, где нужно вытащить, отфильтровать или пересчитать данные из таблиц, логов и вывода других утилит.
В отличие от grep (ищет строки) и sed (правит текст потоком), AWK мыслит записями и полями. Каждая строка — это запись, разбитая на колонки. Это превращает обработку структурированного вывода (ps, df, /etc/passwd, CSV, логи) в простые однострочники.
Программа на AWK — это набор правил вида:
awk 'паттерн { действие }' файл
— паттерн — условие, при котором срабатывает действие (можно опустить — тогда срабатывает на каждой строке)
— действие — что сделать с записью (можно опустить — тогда печатается строка целиком)
➡️ Ключевые встроенные переменные:
$0 — вся строка целиком
$1, $2, ... — поля (колонки) по порядку
NF — количество полей в строке (Number of Fields)
NR — номер текущей строки (Number of Records)
FS — разделитель полей на входе (по умолчанию — пробелы/табы)
OFS — разделитель полей на выходе
➡️ Основные параметры
-F — задать разделитель полей (-F: для /etc/passwd, -F, для CSV)
-v — передать переменную внутрь программы (-v threshold=80)
-f — взять программу из файла, а не из строки
🔵Блоки BEGIN и END
BEGIN выполняется до чтения файла, END — после. Удобно для заголовков и итогов.
✅ Примеры
Вывести только нужные колонки (имя пользователя и shell из passwd):
awk -F: '{print $1, $7}' /etc/passwd
root /bin/bash
daemon /usr/sbin/nologin
Найти процессы, потребляющие больше 50% CPU:
ps aux | awk '$3 > 50 {print $2, $11}'
Отфильтровать строки лога по коду ответа nginx и посчитать количество 5xx:
awk '$9 ~ /^5/ {count++} END{print "5xx errors:", count}' access.log
AWK — это полноценный мини-язык.
Для разовых однострочников он экономит десятки строк на grep | cut | sort, а в скриптах закрывает всю обработку табличных данных без выхода в Python.
#линуксятина | 941 |
| 7 |  🤔 Сколько стоит контур по 152-ФЗ ?
Минимальный набор на 50 рабочих мест:
Secret Net Studio — около 303 тыс. ₽
Kaspersky — около 136 тыс. ₽
ViPNet для 20 пользователей — около 237 тыс. ₽
Континент 4 — около 1,2 млн ₽
Аудит соответствия — от 250 тыс. ₽
Итого — примерно 2,1 млн ₽.
С техподдержкой межсетевого экрана — уже больше 2,4 млн ₽.
❗️ И это без серверов, СХД, резервного копирования, второй площадки, аттестации, проектной документации и работы специалистов.
👉 В новом материале разобрали, когда свой контур по 152-ФЗ оправдан, а когда защищённое облако оказывается выгоднее и удобнее.
#статья | 360 |
| 8 |  💸 Как ДИТу говорить с бизнесом на языке денег
TCO, RTO, RPO, SLA, MTTR сами по себе ничего не объясняют.
Как обосновать бюджет на инфраструктуру через влияние на продажи, логистику, клиентский сервис и другие критичные процессы.
Как перевести ИТ-метрики в деньги, узнать цену простоя, какие риски и последствия допустимы и почему бездействие тоже имеет свою цену.
😎 Смотрите в выпуске по ссылке на любой удобной платформе
▶️ Rutube
▶️ YouTube
▶️ VK Видео | 1 093 |
| 9 |  💻 StatefulSet vs Deployment vs DaemonSet: три способа управлять подами
В Kubernetes важно не просто запустить под, а выбрать правильный контроллер.
Не тот контроллер может привести к потерянным данным, лишним подам на нодах или странному поведению БД.
💬 Deployment — для stateless-нагрузок
Управляет ReplicaSet'ом, который поддерживает заданное число одинаковых, взаимозаменяемых подов.
— Поды получают случайные имена (app-7d4b9c8f6-x2k9p)
— При обновлении старые поды удаляются, новые создаются с нуля — история не важна
— Поддерживает RollingUpdate и Recreate — стратегии обновления
— Любой под может заменить любой другой без последствий
Подходит для: API, фронтенд, воркеры без сохраняемого состояния.
💬 StatefulSet — для нагрузок с сохранением состояния
Гарантирует стабильную идентичность каждого пода — то, чего Deployment принципиально не даёт.
— Имена подов предсказуемы и постоянны (db-0, db-1, db-2)
— Каждый под получает свой PersistentVolumeClaim, который сохраняется при пересоздании пода
— Поды создаются и удаляются строго по порядку (0 → 1 → 2 и обратно)
— Требует headless Service для сетевой идентичности — DNS-имя вида db-0.db-service.namespace.svc.cluster.local
Подходит для: БД (PostgreSQL, MongoDB), очереди (Kafka), etcd — всё, где важны порядок запуска, стабильный сетевой адрес и привязка к своему тому.
💬 DaemonSet — для нагрузок на каждой ноде
Гарантирует, что копия пода будет запущена на каждой (или на выбранном подмножестве) ноде кластера — не больше и не меньше.
— Число подов = число подходящих нод, а не заданное значение replicas
— При добавлении новой ноды под создаётся автоматически
— При удалении ноды под удаляется вместе с ней
— Игнорирует обычный scheduler в пользу собственной логики размещения, учитывает nodeSelector и taints/tolerations
Подходит для: агенты мониторинга (node-exporter), сборщики логов, CNI-плагины на каждом хосте.
👀 Выбор контроллера
— Если поды одинаковые и могут спокойно заменять друг друга — это Deployment.
— Если каждому поду нужны своё имя, сетевой адрес и отдельное хранилище — это StatefulSet.
— Если под должен запускаться на каждой подходящей ноде — это DaemonSet.
#заметкиИнженера | 953 |
| 10 |  🛠 Поддержка инфраструктуры
«Поддержка 24/7» — чтобы понять, что это значит на самом деле, нужно заглянуть в договор.
В нём должно быть понятно, что входит в контур сопровождения и какие границы ответственности зафиксированы.
Если этого нет, то круглосуточная поддержка остаётся общей формулировкой, а в момент аварии начинается ручное управление и поиск того, кто должен включаться в работу.
👉 В новом материале разобрали, что должно стоять за поддержкой инфраструктуры 24/7, как отличить зрелую эксплуатацию от формальной техподдержки и какие вопросы задать подрядчику до подписания договора.
#статья | 996 |
| 11 |  💻 kube-controller-manager: компонент, который следит за состоянием кластера
В Kubernetes всё построено вокруг одной идеи: пользователь описывает, каким должен быть кластер, а система сама приводит реальность к этому описанию.
За это отвечает kube-controller-manager — компонент control plane, который запускает встроенные контроллеры и непрерывно сверяет желаемое состояние с фактическим.
Технически это единый бинарник, внутри которого крутятся десятки контроллеров. Они объединены в один процесс ради экономии ресурсов и упрощения эксплуатации, но логически независимы.
🔢 Контроллер — это бесконечный цикл согласования (reconciliation loop).
Его работа сводится к трём шагам:
— Наблюдение — через watch-механизм API-сервера контроллер получает события об изменении ресурсов.
— Сравнение — сопоставляет желаемое состояние (spec) с текущим (status).
— Действие — если есть расхождение, создаёт, удаляет или изменяет объекты, чтобы устранить разницу.
Цикл повторяется бесконечно. Удалили под вручную — контроллер заметит расхождение и создаст новый.
💬 Внутри kube-controller-manager работают:
— Deployment / ReplicaSet controller — поддерживает заданное число реплик. Именно он разворачивает ReplicaSet из Deployment, а тот создаёт поды.
— Node controller — следит за состоянием узлов. Если нода перестаёт слать heartbeat, помечает её NotReady и инициирует выселение подов.
— Job / CronJob controller — управляет жизненным циклом задач и их запуском по расписанию.
— EndpointSlice controller — связывает Service с подами, обновляя списки эндпоинтов при изменении состава подов.
— ServiceAccount & Token controller — создаёт сервис-аккаунты и связанные с ними секреты в новых namespace.
— Namespace controller — корректно удаляет все ресурсы внутри namespace при его удалении.
➡️ Пример: выполнение масштабирования
kubectl scale deployment nginx --replicas=5
Дальше происходит цепочка:
➡️ kubectl отправляет запрос на kube-apiserver, тот записывает новое значение replicas=5 в etcd.
➡️Через watch событие об изменении Deployment получает kube-controller-manager.
➡️Deployment controller обновляет связанный ReplicaSet.
➡️ReplicaSet controller видит: желаемо 5 подов, фактически 3. Создаёт 2 новых пода через API-сервер.
➡️Новые поды попадают в очередь — их подхватывает kube-scheduler и назначает на ноды.
➡️kubelet на этих нодах запускает контейнеры и докладывает о статусе обратно в API.
Сам controller-manager при этом не запускает контейнеры и не назначает поды на ноды — он лишь приводит число объектов к нужному, а грязную работу делают scheduler и kubelet.
kube-controller-manager — это целый цех автономных регуляторов, каждый из которых отвечает за свой кусочек кластера.
Именно он превращает декларативный манифест в живую, самовосстанавливающуюся систему.
#заметкиИнженера | 992 |
| 12 |  ⚠️ SLA на инфраструктуру
В этом договоре важны не общие обещания, а конкретные метрики, границы ответственности и последствия за нарушение.
Здесь важно не смешивать доступность сервиса с RTO, RPO, DR, бэкапами и поддержкой всего подряд.
Подрядчик отвечает за тот слой, который проектирует, контролирует, мониторит и может менять по регламенту.
Всё остальное — гостевые ОС, доступы, приложения, интеграции и изменения внутри контура — нужно отдельно фиксировать в договоре.
👉 В новом материале разобрали, что на самом деле измеряет SLA, чем отличаются модели сопровождения, почему изменения часто становятся причиной конфликтов и какие вопросы стоит задать подрядчику до аварии.
#статья | 980 |
| 13 |  🖥 logrotate — утилита для автоматической ротации, сжатия и удаления логов в Linux.
Она помогает ограничивать рост логов: переносит старые файлы, сжимает их, удаляет устаревшие копии и при необходимости выполняет команды после ротации.
logrotate не работает постоянно в фоне.
Его запускает cron (/etc/cron.daily/logrotate) или systemd-таймер (logrotate.timer), обычно раз в сутки.
При запуске утилита читает конфиги, проверяет условия ротации и выполняет действия, если файл подходит под заданные правила.
➡️ Где лежат конфиги?
— /etc/logrotate.conf — основной файл с глобальными настройками.
— /etc/logrotate.d/ — каталог с отдельными конфигами для каждого сервиса (nginx, postgres и т.д.)
➡️ Пример конфига для приложения:
Допустим, нужно ротировать логи своего приложения в /var/log/myapp/.
Создаётся файл /etc/logrotate.d/myapp:
daily
rotate 14
size 100M
compress
delaycompress
missingok
notifempty
create 0640 myapp myapp
sharedscripts
postrotate
systemctl reload myapp >/dev/null 2>&1 || true
endscript
}
➡️Что задано:
— daily — проверять ротацию каждый день.
— rotate 14 — хранить 14 архивных копий.
— maxsize 100M — ротировать файл при проверке, если он превысил 100 МБ.
— compress — сжимать старые логи.
— delaycompress — сжимать файл на следующем цикле ротации.
— missingok — продолжать работу, если лог-файл отсутствует.
— notifempty — не ротировать пустой файл.
— create 0640 myapp myapp — создать новый лог-файл с нужными правами и владельцем.
— sharedscripts — выполнить postrotate один раз для всей группы файлов.
— postrotate ... endscript — выполнить команду после ротации.
➡️ Полезные команды
➡️ Проверить конфиг без изменений (dry-run):
logrotate -d /etc/logrotate.d/myapp
➡️ Принудительно запустить ротацию, игнорируя расписание:
logrotate -f /etc/logrotate.conf
➡️ Подробный вывод того, что происходит:
logrotate -v /etc/logrotate.conf
👀 Обычно logrotate уже настроен при установке сервисов. Но его правила стоит проверять: от них зависит, как долго хранятся логи, когда они сжимаются и сколько места занимают на диске.
#линуксятина | 967 |
| 14 |  💪 Анатомия высоких нагрузок:
как строится отказоустойчивая инфраструктура
🔍 Обычно всё начинается с симптомов: сервисы проседают в пиковые часы, восстановление после сбоя занимает непредсказуемое время, новый продукт сложно запустить, а текущий контур уже не выдерживает рост.
И на это есть разные причины.
Сервис может тормозить из-за нехватки ресурсов, длинных запросов к базе данных, слабой сетевой схемы, конкуренции бэкапов с рабочей нагрузкой или проблем с балансировкой.
Поэтому архитектуру нельзя считать только по количеству серверов, виртуальных машин и терабайт хранения.
Нужно понимать профиль нагрузки, критичность сервисов, допустимый простой, потери данных, требования к безопасности и уровень эксплуатации после запуска.
👉 В новом материале разобрали, как строится инфраструктура под высокие нагрузки: от первого запроса и инженерного разбора до проектирования, тестирования, запуска и передачи в эксплуатацию.
#статья | 1 001 |
| 15 |  💻 Probes в Kubernetes:
как кластер понимает, что под работает и готов принимать запросы
Kubernetes не может оценить состояние приложения без специальных проверок. Процесс может быть запущен, но при этом висеть в дедлоке или ещё не успеть прогрузить кеш.
Для этого и существуют probes — проверки, по результатам которых kubelet принимает решения о перезапуске и направлении трафика.
➡️ Виды probe
— livenessProbe — контролирует работоспособность контейнера. При провале kubelet перезапускает контейнер. Применяется, когда приложение может «зависнуть» без падения процесса.
— readinessProbe — проверяет, готов ли контейнер принимать трафик. При провале под убирается из конечных точек сервиса, но не перезапускается. Используется для прогрева, ожидания зависимостей (БД, кеш).
— startupProbe — проверяет, успело ли приложение стартовать. Пока она не пройдена, liveness и readiness заморожены. Нужна для медленно стартующих приложений, чтобы их не убивало раньше времени.
➡️ Как работают?
Каждая probe выполняется одним из трёх способов:
— httpGet — HTTP-запрос на путь и порт, успех при коде 200–399
— tcpSocket — проверка, что порт открыт
— exec — выполнение команды внутри контейнера, успех при коде возврата 0
containers:
- name: app
image: my-app
startupProbe:
httpGet:
path: /healthz
port: 8080
failureThreshold: 30
periodSeconds: 10
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 0
periodSeconds: 10
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready
port: 8080
periodSeconds: 5
failureThreshold: 2
🔧 Основные параметры
— initialDelaySeconds — задержка перед первой проверкой
— periodSeconds — как часто выполнять проверку
— timeoutSeconds — таймаут одной проверки
— successThreshold — сколько успехов подряд считать восстановлением (для liveness/startup всегда 1)
— failureThreshold — сколько провалов подряд считать отказом
Пример со startupProbe выше даёт приложению до 30 × 10 = 300 секунд на запуск, после чего управление переходит к liveness.
Probes — это не формальность в манифесте, а контракт между приложением и кластером. Liveness помогает kubelet принять решение о перезапуске контейнера, readiness показывает, можно ли направлять на pod трафик, startup даёт приложению время на корректный запуск. Разделение этих ролей напрямую влияет на стабильность сервиса при деплоях и сбоях.
#заметкиИнженера | 933 |
| 16 |  Приглашаем инженеров на DevOps Lab: ML in Production!
Не планируйте ничего на 26 июня! Открыли регистрацию на закрытую встречу в Новосибирске, где DevOps-инженеры и технические руководители разберут, как выстроить безопасную инфраструктуру для ML-сервисов на практике.
🟡Что вас ждет?
• инфраструктура инференса
• безопасность ML-пайплайнов
• наблюдаемость моделей в производственной среде
• Кофе-брейк и возможность задать неудобные вопросы напрямую
На DevOps Lab мы соберёмся небольшим кругом, чтобы послушать три практических доклада, обсудить кейсы и немного подебажить с коллегами из индустрии. Регистрируйтесь, количество билетов ограничено :)
📌 26 июня, 18:00 | г. Новосибирск, офис Никсис
📌 Регистрация: по ссылке
#девопс #никсис #митап | 891 |
| 17 |  📝 Шпаргалка по проектированию безопасных систем.
Помогает быстро проверить, какие направления защиты нужно учесть при проектировании ИТ-системы: доступы, данные, сеть, API, контейнеры, подрядчики, реагирование на инциденты и восстановление.
🔐 Основные направления защиты
— Authentication
Проверка того, кто входит в систему. Сюда относятся парольная политика, MFA, доступ сотрудников к внутренним сервисам и защита учётных записей.
— Authorization
Управление правами после входа. Роли, уровни доступа, принцип минимальных привилегий и регулярный пересмотр выданных прав.
— Encryption
Защита данных при передаче и хранении. TLS, шифрование чувствительной информации, управление ключами и контроль доступа к ним.
— Vulnerability Management
Работа с уязвимостями. Патчи, регулярное сканирование, мониторинг и проверка критичных обновлений.
— Audit & Compliance
Журналы, проверки и соответствие требованиям. Для российской инфраструктуры сюда можно отнести 152-ФЗ, 187-ФЗ, требования ФСТЭК/ФСБ и внутренние регламенты компании.
— Network Security
Защита сети. Межсетевые экраны, сегментация, IDS/IPS, защищённый DNS и контроль сетевых потоков между системами.
— Endpoint Security
Защита рабочих станций, ноутбуков и других конечных устройств. Антивирус, EDR, управление устройствами и шифрование дисков.
— Incident Response
Реагирование на инциденты. План действий при атаке, утечке, DDoS или компрометации учётной записи, а также регулярные тренировки команды.
— Container Security — безопасность самих контейнеров: доверенные реестры и образы, сканирование на уязвимости, минимальная база, запуск без root, контроль runtime.
— Kubernetes Security — безопасность кластера: RBAC, network policies, Pod Security Standards, защита control plane и etcd, управление секретами.
— API Security
Защита публичных и внутренних API. OAuth 2.0, API-ключи, rate limiting, валидация входных данных и контроль подозрительной активности.
— Third-Party Management
Работа с подрядчиками и внешними сервисами. Оценка поставщиков, безопасный обмен данными, контроль интеграций и внешних доступов.
— Disaster Recovery
Восстановление после сбоя или атаки. DR-план, резервное копирование, резервирование систем и регулярная проверка восстановления.
Такая карта хорошо показывает, что безопасность системы начинается ещё на этапе архитектуры. Чем раньше эти направления учтены в проектировании, тем меньше хаоса будет при эксплуатации, проверках и реальных инцидентах.
#полезное | 796 |
| 18 |  💰 Экономия на архитектуре, которая увеличивает TCO
Самые дорогие ошибки в инфраструктуре часто выглядят как разумная экономия на старте.
Обычно сокращают то, что кажется необязательным прямо сейчас: резервирование сети, запас по СХД, мониторинг, тесты восстановления, документацию и план масштабирования.
А последствия появляются позже:
— Сетевую схему приходится менять уже после запуска.
— СХД не выдерживает реальный профиль нагрузки: растут задержки, проседают сервисы.
— Проблемы с инфраструктурой становятся заметны по жалобам пользователей.
— Бэкапы есть, но восстановление не проверялось — в момент инцидента это превращается в отдельный риск.
Так экономия превращается в рост TCO.
Потому что в стоимость инфраструктуры входят эксплуатация, риски, восстановление, масштабирование и цена будущих переделок.
👉 В новом материале разобрали, где компании чаще всего экономят при построении ИТ-инфраструктуры, как эти решения возвращаются дополнительными расходами и почему иногда «дешевле на старте» означает дороже в три раза.
#статья | 776 |
| 19 |  📖 Как освоить современный Linux
Полный справочник по современной Linux-среде: от базовых принципов работы ОС до ядра, оболочек, файловых систем, сетевого взаимодействия, контейнеров и систем мониторинга.
🔍 Рассматривается:
— что такое современный Linux и где он используется;
— архитектура Linux и устройство ядра;
— процессы, память, системные вызовы и модули ядра;
— работа с терминалом, оболочками и скриптами;
— управление пользователями, правами и доступом;
— файловые системы и виртуальная файловая система;
— приложения, systemd и управление пакетами;
— контейнеры и современные менеджеры пакетов;
— основы сетевого взаимодействия, TCP/IP и DNS;
— журналирование, мониторинг и наблюдаемость;
— виртуальные машины и межпроцессное взаимодействие;
— современные дистрибутивы Linux и перспективные возможности системы.
Автор:
Майкл Хаузенблас
Издательство:
O’Reilly / русское издание, 2026 г.
#книги #полезное | 962 |
| 20 |  🖥 systemd-resolved — компонент systemd, который отвечает за разрешение сетевых имён. По сути — это небольшой кеширующий DNS-сервер, который крутится прямо на вашей машине и работает посредником между приложениями и реальными DNS-серверами.
📍 Зачем он нужен?
Раньше DNS-серверы прописывались в один файл /etc/resolv.conf, и за него дрались все подряд: DHCP, VPN, NetworkManager. Кто последний записал — тот и победил, а остальные настройки терялись. systemd-resolved решает это и даёт сверху:
— Раздельный DNS под каждый интерфейс (per-link) — VPN, Wi-Fi и Ethernet больше не затирают настройки друг друга.
— Кеширование — повторные запросы не уходят в сеть, резолвинг быстрее.
— Современные протоколы — DNSSEC, DNS-over-TLS (DoT), а также LLMNR и mDNS для имён в локальной сети.
📍 Как работает?
Поднимает локальный DNS-сервер на адресе 127.0.0.53:53 — это так называемый stub-резолвер (заглушка). /etc/resolv.conf превращается в симлинк на /run/systemd/resolve/stub-resolv.conf, где прописан единственный nameserver те самые 127.0.0.53.
Все приложения отправляют запросы на этот локальный адрес. Дальше resolved сам решает, на какой реальный upstream-сервер переслать запрос в зависимости от интерфейса, домена и настроек.
📍 Основные команды
Главная утилита — resolvectl
Полный статус с DNS-серверами по каждому интерфейсу:
resolvectl status
Global
Protocols: -LLMNR -mDNS +DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (eth1)
Current Scopes: DNS
Protocols: +DefaultRoute +DNSSEC
Current DNS Server: 77.88.8.8
DNS Servers: 77.88.8.8 77.88.8.1
Резолвинг имени через resolved:
resolvectl query cortel.cloud
cortel.cloud: 95.181.181.7 -- link: eht1
-- Information acquired via protocol DNS in 12.3ms.
-- Data is authenticated: no
Сброс DNS-кеша:
resolvectl flush-caches
systemd-resolved — это локальный кеширующий резолвер, который наводит порядок в DNS: разводит серверы по интерфейсам, кеширует ответы и поддерживает современные протоколы вроде DoT и DNSSEC. На большинстве свежих Ubuntu/Debian он включён по умолчанию.
#линуксятина | 852 |
