Сложность метастабильных состояний отказа на примере Такси

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

https://vk.com/video-17796776_456240927?to=L3ZpZGVvLTE3Nzk2Nzc2XzQ1NjI0MDkyNz8-

#SRE #video #metastable

Kubernetes Monitoring — полное руководство

Это цикл из 10 статей, который объясняет принципы мониторинга кубера по всем канонам наблюдаемости.

Part 1: Architecture

Part 2: Instrumentation, Telemetry, Dashboarding, and Alerting

Part 3: Metrics using the victoria-metrics-k8s-stack

Part 4: Automatically extracting etcd certificates into a secret in Talos with VictoriaMetrics

Part 5: VictoriaMetrics Operator

Part 6: Visualizing with Grafana

Part 7: Alerting

Part 8: Logging with VictoriaLogs

Part 9: Talos Linux System Logs with VictoriaLogs and Vector

Part 10: Kubernetes Event Logging to VictoriaLogs

Сохраняйте в закладки!

❗️Цикл статей опубликован на платформе medium.com

@monitorim_it

#release Собрал и выложил версию 2.3.0

Новые фичи:

- Поддержан новый метод монтирования ядерных блочных устройств - ublk. Самый быстрый по iops, не всегда самый быстрый по МБ/с (vduse иногда быстрее)
- На ядрах, которые это умеют (6.15+), OSD теперь не будут помечаться как поедающие 100% cpu iowait.
- Добавлена возможнось проверки привилегий на стороне VitastorFS NFS-сервера (по умолчанию клиент Linux NFS их не проверяет).
- Добавлена опция qemu_file_mirror_path для обмана Veeam (собрана пока что в версиях для proxmox 8 и 9).
- Ускорен расчёт CRC32C на стороне OSD сначала исправлением многократного вызова cpuid, а потом вообще задействованием версии из ISA-L с поддержкой AVX512. IOPS-ы записи выросли на ~20%. 😊
- Убрана повторная перезапись одних и тех же блоков - без этого, по отчёту с github, происходило повреждение данных на одной специфической модели SSD: Memblaze PBlaze5 910 (#79)
- Добавлена поддержка QEMU 10, Debian 13 Trixie и Proxmox 9.0
- Ликвидирована зависимость от системного liburing, он теперь по умолчанию собирается статически

Исправления тоже прикольные:

- Контрольные суммы, судя по всему, никогда не включались в vitastor-disk, даже когда это запрашивалось явно. Просто не пробрасывалась опция 😊
- Теперь vitastor-nfs использует uid и gid из заголовка NFS AUTH_SYS - до этого при создании файла/каталога под каким-то пользователем он создавался под root и, например, в случае реэкспорта через samba, пользователь не мог его потом поменять
- Исправлена теоретическая возможность повреждения bitmap-ов объектов в редких случаях при использовании EC N+2+ (т.е. N+K где K >= 2)
- Исправлен баг в antietcd, из-за которого при перезапуске всех osd и мониторов в antietcd оставались старые ключи /osd/state (lease не удаляли истекшие ключи корректно)
- Исправлена cookie записи ".." в NFS - она должна быть 1, а не 0
- Снимки не удалялись при удалении ВМ в Proxmox (тоже PR с гитхаба, #85)
- Исправлена некорректная фильтрация OSD для пула по размеру блока монитором

https://git.yourcmc.ru/vitalif/vitastor/releases/tag/v2.3.0

🔓 SystemD Service Hardending - несколько слов о безопасности systemd сервисов.

#systemd #security #hardened

"я колеблюсь между двумя состояниями - положить хер на прод и положить прод нахер" (с)

#humor

https://news.1rj.ru/str/bezumniy_kot_work/10

🚀 Kubernetes The Hard Way — по-настоящему

Почти два года, тысячи перезапусков, багов, а также сотни пересобранных кластеров и море мата (в голове 😅) — и всё это вылилось в одну, но очень насыщенную статью.
Kubernetes вручную, от и до, без kubeadm и прочих поблажек.

Я собрал: — полный пошаговый гайд по сборке Kuberentes.
— удобные alias’ы, функции и обёртки
— десятки скриптов, которые реально работают в бою
— важные моменты, о которых молчат в туториалах

🔥 Всё это оформлено в удобной документации на MDX структуре, с фокусом на читаемость и практику.

Полную статью можно почитать здесь 👉 Ссылка Тут
Фидбек и звездочки Github приветствуется 🙌

Выложили на Хабр статью с результатами тестирования Angie, HAProxy, Envoy, Caddy, Traefik и расшифровкой стрима с Колей Лавлинским: https://habr.com/ru/articles/946294/

SRE in 100 Lessons

100 коротких SRE-уроков, основанных на серии книг Google SRE.

@monitorim_it

#машины_aws

Пожалуй, лучший инцидент, что я когда либо видел.

Если вкратце:
1. Управление DNS записями для DynamoDB отвалилось, в итоге:
2. Эндпоинты DynamoDB (в том числе для внутреннего пользования) отвалились, в итоге:
3. Storage backend, которым выступала DynamoDB, одного из компонентов control plane EC2 отвалился, в итоге:
4. Отвалился NLB, который не мог следить за событиями EC2.

Очень радует, что AWS решил минимальными усилиями решить конкретную проблему, а не сделать отдельный внутренний Kinesis как тогда с инцидентом CloudWatch и Cognito.


Да и не пользуйтесь us-east-1, сколько еще повторять. Новые фичи раньше всех того не стоят.

📌 Git Revert vs Git Reset: В чём разница? 🔄

Когда вы делаете ошибку в Git, важно понимать, как правильно её исправить. Два самых популярных способа — git revert и git reset. Но они работают по-разному!

### 🔹 Git Revert
- Создаёт новый коммит, который отменяет изменения из проблемного коммита.
- История сохраняется полностью — всё видно, даже ошибка.
- Безопасный вариант для публичных веток (например, `main`).
- Не удаляет коммиты — просто "откатывает" их эффект.

> 💡 Пример:
> C1 → C2 → C3 (ошибка) → C4: Revert C3
> Результат: ошибка отменена, но история остаётся полной.

🔹 Git Reset
- Удаляет коммит(ы) из истории.
- Изменяет историю репозитория — может быть опасно, если уже был пуш.
- Подходит только для локальных изменений или ещё не опубликованных коммитов.
- Есть три режима: soft, mixed, hard.

> 💡 Пример:
> C1 → C2 → C3 (ошибка) → C3 убрано
> Результат: история обрезана, как будто коммит никогда не был.

💡 Вывод:
revert — безопасный и прозрачный способ отменить изменения.
reset — мощный инструмент, но требует осторожности.

📌 Понимание этих команд — ключ к уверенной работе с Git!

#Git #DevOps #Programming #SoftwareEngineering

Systemd: полное руководство для админов + примеры

Systemd — скелет современного Linux. Он управляет не только службами, но и таймерами, монтированием, логированием. Понимать его = значительно повысить эффективность администрирования системы. Эта статья — исключительно технические аспекты: архитектура, юниты, cgroups, работа с журналами. Только команды и конфиги.

@usr_bin_linux

В коментах к передыдущему посту напомнили про лонгрид про systemd от автора

https://0pointer.de/blog/projects/systemd.html

#linux #systemd

Cloudflare выложили разбор вчерашнего инцидента

Cloudflare outage on December 5, 2025
https://blog.cloudflare.com/5-december-2025-outage/

Попробую кратко описать чо там у них случилось, если где-то неправильно понял, то поправьте в комментариях

Как и писал CTO (https://news.1rj.ru/str/tech_b0lt_Genona/5926), они катили изменения для того, что бы закрыть свежую и нашумевшую уязвимость React'а (https://news.1rj.ru/str/tech_b0lt_Genona/5918, https://news.1rj.ru/str/tech_b0lt_Genona/5923)

Для этого они провели два действия:

- Они обнаружили что балалайка, котрая тестирует их WAF не поддерживает нужный размер буфера тела HTTP-запроса, поэтому они её отключили (нужен был 1 MB, а умела только 128 KB)

- Выкатили практически моментально на все сервера изменения. Если я понял правильно, то они так настроили/сделали систему конфигурации после прошлого отвала - https://news.1rj.ru/str/tech_b0lt_Genona/5885

Как и в прошлый раз, сейчас тоже упоминаются две реализации их прокси - FL1 (старая, я не помню на чём, но там есть Lua) и FL2 (новая на Rust)

FL1 стало плохо после отключения балалайки, которая тестировала WAF и его правила, и начала "пятисотить". Происходило это из-за того, что поломался кусок, который отвечал за правила (Lua часть)

[lua] Failed to run module rulesets callback late_routing: /usr/local/nginx-fl/lua/modules/init.lua:314: attempt to index field 'execute' (a nil value)

И это объясняет почему у части работало всё нормально, а у части нет. Проблем не было у тех чей трафик шёл через FL2

> Customers that have their web assets served by our older FL1 proxy AND had the Cloudflare Managed Ruleset deployed were impacted

> Customers that did not have the configuration above applied were not impacted. Customer traffic served by our China network was also not impacted.

Когда CF увидели, что всё посыпалось, то вообще должна была отработать система "отката". Но что-то пошло не так 🌝

Правила, когда отрабатывают, то выполняются определённые действия (в том числе и к трафику)

> Typical actions are “block”, “log”, or “skip”. Another type of action is “execute”, which is used to trigger evaluation of another ruleset.

Но как выяснилось они никогда не откатывали аварийно правила с типом execute и при откате сломавшего всё нового правила возникла ошибка в логике

if rule_result.action == "execute" then
  rule_result.execute.results = ruleset_results[tonumber(rule_result.execute.results_index)]
end

> This code expects that, if the ruleset has action=”execute”, the “rule_result.execute” object will exist. However, because the rule had been skipped, the rule_result.execute object did not exist, and Lua returned an error due to attempting to look up a value in a nil value.

В FL2 проблемы не существовало такой, потому что, цитирую

> This is a straightforward error in the code, which had existed undetected for many years. This type of code error is prevented by languages with strong type systems.

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

Короче, растпобеда случилась 🗿