Ищу SRE-роль (Middle/Middle+), где надёжность — не красивая метрика в отчёте, а измеримый бизнес-результат. Устал от вакансий, где: → Наблюдаемость = «крутой дашборд, а алерт — в никуда» → Автоматизация = «один человек знает, как перезапустить сервис» → SRE = «реакция на пожар, а не профилактика» Хочу туда, где: → Надёжность = измерима (SLI/SLO, error budget в процентах, а не в эмоциях) → Финансы = часть инфраструктуры (FinOps: вижу стоимость кластера, сопоставляю с perf/availability) → Процессы живые (PostMortem без стрельбы по виноватым, runbook’ы — не мемуары) → Git — источник истины, а не бекап (GitOps на ArgoCD, всё — под version control) 🔧 Что умею — не по стеку, а по impact’у: Контролирую K8s как систему, а не как оркестр → диагностирую OOM, probe-ы, лимиты, readiness: знаю, где чинить — в коде, конфиге или политике Ansible, CI/CD, Python/Bash — автоматизирую рутину, проверки, восстановление, интеграцию в observability Наблюдаемость, которая лечит, а не кричит: алерты по RED/USE — не «что-то не так», а «где и на сколько» Linux: dmesg, strace, netstat — знаю, где реально виснет сервис Сеть: TCP handshake, DNS, MTU — не абстракции, а точки диагностики Patroni, pgBouncer — не администрирую, но встраиваю в мониторинг, CI/CD, делюсь метриками с DBA 🚀 Ценность не в инструментах — в подходе: Меряю то, что не меряют: → стоимость инцидента → ROI от оптимизации → risk-бюджет до следующего сбоя Использую FinOps — чтобы сказать: «Да, кластер можно увеличить. Но выгодно ли это при текущем error budget?» Пишу runbook’ы, которые читают и Junior, и Dev — потому что надёжность — не знание одного человека Хочу туда, где SRE — это не реагирование на алерты в 3 ночи, а проактивное управление рисками через SLI, SLO и error budget на бизнес-критичной, высоконагруженной системе.