SRE CV у 2026: чому DevOps-буллети ріжуть тебе на старті

Знайомий SRE з Києва пише: п'ять років у проді, два роки incident commander, p99 latency на двох сервісах в нього в голові краще за мапу метро. Кидає CV на десять SRE-позицій у Берліні, Амстердамі і Лондоні, отримує два інтерв'ю, обидва на DevOps. Питаю чому, пересилає CV. Перший рядок, Kubernetes, Terraform, AWS, Jenkins, Ansible. Та сама фраза, що у кожного DevOps в LinkedIn у 2026. Жодного слова про SLO, error budget, MTTR. Рекрутерка прочитала перші тридцять слів, поставила тег `devops`, поїхали далі.

Якщо твій день, це тримати продакшн на ногах, твоє CV має проговорити це за перші десять секунд. Інакше рекрутерка, яка цього кварталу побачила 200 однакових Kubernetes-CV, просто не докопається до того, що ти і є та людина, яку вона шукає.

SRE проти DevOps у 2026: межа, яка нарешті стала чіткою

Кілька років SRE і DevOps вживали як синоніми. У 2026, особливо у Європі і США, грань стала жорсткою. DevOps, це про пайплайни і tooling: побудувати CI/CD, налаштувати IaC, дати командам автономію деплоїти. SRE, це про вихід продакшна: чи живий сервіс зараз, скільки error budget лишилось до кінця кварталу, чому MTTR зріс на 8 хвилин після останнього релізу.

Hiring-менеджери у 2026 шукають конкретний словник у першому абзаці CV. Якщо вони не бачать SLO, SLI, error budget, MTTR, blameless postmortem ще до того, як проскролили вниз, ти читаєшся як сильний DevOps зі смузі знизу. Та сама людина, половина оферів.

Буллет про SLO, SLI і error budget, який видає senior

Більшість SRE пишуть у CV щось на кшталт "defined SLOs for the platform team". Це нічого не означає. SLO без числа, це просто слово з SRE-книжки. Сильна форма, це конкретні цифри і конкретне рішення, яке прийняли через них.

Порівняй два рядки. Слабкий: "Налаштував SLO і SLI для продакшн-сервісів". Сильний: "Визначив SLO 99.95% доступності і SLI p99 < 250мс для checkout-сервісу. За Q1 спалили 60% error budget, через що поставили на паузу два неургентні релізи і витягли назовні нестабільну DB-залежність". Другий рядок каже hiring-менеджеру, що ти розумієш навіщо існує error budget, а не просто знаєш, що це слово є у SRE-книжці.

MTTR і доступність: цифри, без яких CV порожнє

Два буллети тримають весь SRE-CV. Один про MTTR, один про availability. Якщо нема обох, рекрутери припускають, що ти володів інструментами, а не продакшном.

• "Скоротив MTTR з 47 до 12 хвилин: переписав runbook-и і викотив Slack-бота для первинної діагностики"
• "Підняв доступність основного сервісу з 99.5% до 99.95% за рік: переробив healthcheck-и і налаштував проактивний HPA у Kubernetes"
• "Мігрував алертинг 80+ сервісів з Nagios на Prometheus + Grafana, фолс-позитиви впали на 65%, on-call пейджі за тиждень з 19 до 6"
• "Провів 14 blameless постмортемів за рік, action items вели у Jira, повторюваність схожих інцидентів впала на 40%"

On-call: перестань писати просто "on-call rotation" і на цьому крапку

Найслабша фраза на SRE-CV у 2026, це окремий рядок "Participated in on-call rotation". Це як написати у CV "мав ноутбук". On-call, це сильна історія, якщо ти показуєш частоту, масштаб і що ти з цього навчився.

Шаблон, який працює: частота + обсяг + один значущий інцидент + що змінилось після. "Тиждень on-call раз на місяць для платформи з 40+ сервісів, у середньому 3-4 пейджі за зміну. Як incident commander закрив сценарій з cascading lock у Postgres, чотири години downtime. Після цього додав query plan review у CI і index advisor у шаблон PR, повторного інциденту цього класу за 18 місяців не було".

Один рядок, але читається як профіль людини, яка знає, що робити о третій ночі. І жодного слова про NDA: ти описав клас інциденту і свою дію, не назвав компанію, продукт чи клієнта.

Історії про інциденти без витоку під NDA

Стандартний страх: "Я не можу писати про той інцидент, бо це під NDA". Правда у тому, що 95% постмортемів можна перекласти на CV без жодного компромату. NDA захищає назви клієнтів, конкретні цифри бізнесу, дані користувачів. Не захищає клас проблеми, твою роль і архітектурний урок.

• Заміни "клієнт X втратив $200k транзакцій" на "фінансовий флоу з високим $/хв впливом"
• Замість назв продуктів пиши роль: "payment gateway", "auth-сервіс", "data ingestion pipeline"
• Зберігай технічну root cause: cascading lock, memory leak, DNS misconfig, queue saturation. Саме це і є справжній сигнал
• Зберігай свою дію і preventive change: "додав query plan review у CI", "впровадив load shedding на edge"
• Цифри зазвичай ок як співвідношення або порядки: "4-годинний outage", "повторюваність впала на 40%", не абсолютна виручка

Kubernetes: він є у всіх, тому це не може бути твоїм заголовком

У 2026 "Kubernetes" у списку скілів дає тобі рівно нуль балів. Це як написати "володію Git". Сильний хід, це не Kubernetes у скілах, а глибина у Kubernetes, прихована у конкретному буллеті.

Приклади, що читаються як глибина, а не як CV-наповнювач: "Дебажив OOMKills на ingest-воркладі з 200 подів: причина, JVM heap sizing всередині контейнерів ігнорив memory limits, пофіксив через коректні cgroup-aware флаги". Або: "Мігрував 40 сервісів з in-cluster Istio на ambient mesh, sidecar memory впав на 4GB на ноду, забрав два класи mTLS edge-кейсів цілком". Обидва рядки тихо доводять, що ти провів реальні години всередині кластера, а не на слайдах про нього.

Що дописати у навички SRE у 2026

• OpenTelemetry по трейсах, метриках, логах (не лише Prometheus)
• eBPF або Cilium для network observability і runtime-секʼюрки
• FinOps-перетин: Kubecost, Vantage, rightsizing як регулярна практика
• Chaos engineering, який ти реально запускав (Litmus, Chaos Mesh, Gremlin), а не лише читав про нього
• Надійність AI-воркладів: LLM-ендпоінти, GPU autoscaling, back-pressure у чергах
• Progressive delivery на ArgoCD або Flux, плюс автоматичний rollback при burn SLO

Як пояснити свою роботу non-tech hiring-менеджеру

Перший раунд інтерв'ю на SRE-позицію у 2026 часто з recruiter або hiring-менеджером, що не з інженерної функції. Технічних термінів вони не зрозуміють. Якщо ти сипатимеш "SLO, percentile latency, ambient mesh, eBPF", вони запишуть "strong technical, weak comms" і кінець.

Перепакуй MTTR і availability у мову грошей і клієнтів. "Скоротив downtime на 75%" перетворюється у "зекономили близько 30 годин клієнтського downtime на квартал, при $20/хв вартості це приблизно $36k". "99.95% availability" перетворюється у "checkout-флоу лежав не більше 22 хвилин на місяць, тобто платячий клієнт майже ніколи не бачив зламану сторінку".

Ще одна формула, що працює на non-tech людях: "sleep math". "Я зменшив кількість нічних пейджів для своєї команди з 19 до 6 на тиждень. Це не лише про комфорт інженерів, це про утримання людей: дві ключові ролі за 18 місяців не звільнились через burnout". Це одразу зрозуміло.

Помилки у SRE-CV, які бачу щотижня

• Job title "DevOps Engineer", бо так HR написав в офері, а буллети чисто SRE. Виправ заголовок: "DevOps Engineer (SRE responsibilities)"
• У скілах 30 логотипів. Скороти до 10-12, з якими ти реально працював за останні 18 місяців
• Жодної згадки про SLO, error budget, MTTR над лінією першого скрола
• "Покращив моніторинг" без жодного числа. Або давай цифру, або викидай рядок
• Перелік усіх CNCF-логотипів, які ти колись інсталював. Рекрутери читають це як padding, не як глибину
• Жодної on-call історії, лише "participated in rotation". Додай частоту, масштаб і один конкретний інцидент

Міні-шаблон, який можна забрати сьогодні

Заголовок плюс перші 4 буллети. Скопіюй, встав, заміни цифри на свої. Якщо ти не можеш заповнити це реальними числами з останніх 18 місяців, ось де реальний gap, ще до того як говорити про текст CV.

• Заголовок: "Site Reliability Engineer, 5 років у проді. Скоротив MTTR на 75%, підняв доступність до 99.95%, incident commander на 30+ Sev-1"
• Буллет 1: число SLO або error budget, що змінило рішення по релізу
• Буллет 2: MTTR до і після, з конкретним важелем, який ти посунув
• Буллет 3: одна історія інциденту, анонімізована, з preventive-змінами після
• Буллет 4: вплив на гроші або години, не на інструменти