SRE в Казахстане 2026: чем отличается от DevOps и как перейти

🔎 Почему поиск по SRE выдаёт ноль

Заходишь на Taylor, вбиваешь в поиск «SRE» — и получаешь пустую страницу. При этом весь кластер запросов вокруг devops на платформе набирает 68 обращений от 10 человек: интерес к теме есть, а вакансий под запрос нет. Это не баг поиска и не недоработка платформы.

Это симптом того, что происходит на рынке труда Казахстана в целом. Вопрос, который стоит за нулём в поисковой выдаче: SRE — вообще отдельная профессия здесь, или же это просто модное имя для той же работы, что уже делают DevOps-инженеры? Чтобы ответить честно, а не общими словами, разберём базу вакансий Taylor от 31.07.2026 — что в ней реально есть под словом SRE, а чего там нет.

🛠 Что вообще делает SRE руками

Роль SRE выросла из Google примерно на границе 2000-х и 2010-х как попытка ответить на простой вопрос: почему эксплуатация систем — это ручная рутина, а не инженерная дисциплина. Идея в том, чтобы к поддержке продакшена подходить как к разработке софта: писать код, автоматизировать, измерять, а не тушить пожары руками каждую ночь.

Из этой идеи родился конкретный набор артефактов. SLO и SLI — это договорённость о том, какой уровень надёжности сервиса приемлем и как его измерять в цифрах. Error budget — производный от SLO лимит на количество допустимых сбоев, который решает бесконечный спор между «давайте катить фичи быстрее» и «давайте ничего не трогать, а то сломается». On-call — дежурства, когда инженер обязан среагировать на инцидент, и postmortem — разбор случившегося сбоя без поиска виноватого человека, а с фокусом на то, что чинить в системе и процессах.

На бумаге это действительно отдельная дисциплина со своим набором практик, а не косметическое переименование DevOps. Вопрос в том, отражается ли это в реальных вакансиях казахстанского и близкого к нему рынка — и здесь начинается расхождение теории с практикой.

⚖️ DevOps vs SRE в требованиях вакансий: два реальных отличия

Если сравнить формулировки в описаниях вакансий, разница между DevOps и SRE оказывается куда меньше, чем можно было ожидать после раздела про происхождение роли. SLO и error budget упоминаются в 22% SRE-вакансий против 7,8% у DevOps — это заметный разрыв, и именно он ближе всего к сути SRE как дисциплины. Второе отличие — Helm: он встречается в 22% SRE-вакансий против 16% у DevOps, разница уже не такая драматичная.

На этом список настоящих отличий заканчивается. Kubernetes упоминается в 61% SRE-вакансий и в 59% DevOps — практически одинаково. CI/CD, Docker, Terraform, AWS — весь этот стек совпадает почти без зазора между двумя ролями. То есть тулинг один и тот же, различается в основном акцент на измерение надёжности через SLO и чуть более частое использование Helm для управления релизами в Kubernetes.

Дополнительный штрих: почти половина SRE-вакансий, а именно 24 из 49 (49%), в заголовке содержат ещё и слово «DevOps» — это гибридные позиции вида «DevOps/SRE Engineer». Работодатели сами не всегда различают эти роли достаточно чётко, чтобы разносить их по разным вакансиям.

📊 Сколько вакансий SRE есть на рынке и откуда они

Абсолютные цифры расставляют всё по местам. По заголовку в базе Taylor находится 333 вакансии DevOps и всего 49 — SRE. Для сравнения, Platform/Infrastructure Engineer даёт 82 вакансии, то есть занимает промежуточное место между двумя категориями.

Ещё важнее география. Из 34 SRE-вакансий, помеченных как remote, ни одна не содержит указания на казахстанский город. У DevOps ситуация другая: из 246 помеченных remote вакансий 21 всё же привязана к городу в Казахстане. По SRE такого нет вообще — это либо чисто удалённая работа на зарубежную компанию, либо направления, куда локально попасть невозможно физически.

Источники подтверждают эту картину. Казахстанский hh дал по SRE всего 2 вакансии за весь срез базы, тогда как основной поток идёт с careered (15), nofluffjobs (10) и DOU (10). Это зарубежные джоб-борды, ориентированные на другие рынки. Стоит держать в голове и то, что флаг remote в базе не идеален: у hh из вакансий, помеченных как удалённые, слово «удалённо» или «remote» реально встречается только в 67% случаев, остальные — это офис или гибрид с неточной меткой. Поэтому даже цифра в 34 remote-вакансии SRE, вероятно, немного завышена относительно реальности.

🏷 Почему hh путает DevOps с сисадмином

Есть ещё один слой искажения, который стоит понимать перед тем, как делать выводы про рынок DevOps в целом. Внутренний тег stack='devops' в базе Taylor даёт 672 вакансии — вдвое больше, чем 333 вакансии с DevOps непосредственно в заголовке. Разрыв в основном создаёт hh: там 180 вакансий помечены тегом devops, но лишь 32 из них реально содержат «DevOps» в заголовке.

Что же тогда лежит в этих 180 вакансиях hh под ярлыком devops? Первая по размеру группа — 46 вакансий «Системный администратор». Дальше идут «AWS Cloud Architect» (10), «Системный администратор / DevOps инженер» (7), «Старший сисадмин» (4) и позиции DBA (5). Получается, что почти четверть того, что автоматически размечено как devops-рынок на hh, на самом деле рынок системного администрирования с новым названием в теге.

Это важно держать в уме и при чтении цифр про SRE, и вообще при любой оценке размера devops-рынка Казахстана: корпус вакансий Taylor — это скользящее окно, а не накопленный архив. Всего в базе 39 099 вакансий, из них открыто 6 929, а приток за последние 60 дней составил 14 623 записи, из которых 7 997 уже закрылись. Рынок постоянно обновляется, и разные срезы дают разные пропорции, если не смотреть внимательно на то, что стоит за тегами.

💰 Деньги: что известно про SRE и что нет

Здесь придётся признать честно: про зарплату SRE в Казахстане в тенге данных попросту нет. Ни одной строки с KZT среди SRE-вакансий в базе Taylor — это не значит, что таких зарплат не существует, это значит, что источники, доступные Taylor, их не фиксируют.

У DevOps ситуация лучше, но тоже не блестящая: зарплата в KZT встречается всего у 12 вакансий из 333, с разбросом от 83 333 до 2 000 000. Это разброс настолько широкий, что говорить о медиане здесь бессмысленно — воспринимать эти 12 строк можно только как самый общий ориентир, не как репрезентативную картину рынка. Подробный разбор зарплат DevOps в Казахстане — тема отдельной статьи, здесь не будем её повторять.

Что можно сказать про SRE — это данные в USD, где выборка тоже маленькая, но хоть какая-то. Медиана вилки у SRE (n=7) составляет 6 000–10 176 долларов против 3 000–4 100 у DevOps (n=55). Разница выглядит внушительно, но на выборке в 7 вакансий делать далекоидущие выводы для казахстанского рынка нельзя — это, скорее, зарплаты для узкого сегмента зарубежных удалённых позиций. Отдельно стоит игнорировать крайние значения вроде почасовых ставок от 20 долларов — это статистический мусор, который попадает в выборку из вакансий с почасовой оплатой, а не полноценных окладов.

🚪 Есть ли вход для джуна в SRE

Прямой вопрос — можно ли начать карьеру сразу с позиции junior SRE — имеет прямой ответ: практически нет. В базе Taylor всего 1 junior-вакансия SRE из 49, это меньше 2%. Для сравнения, у DevOps на junior приходится 34 вакансии из 333, то есть 10,2% — тоже не гигантский вход, но кардинально другой порядок величины.

Это соответствует историческому смыслу самой роли. SRE изначально задумывался как надстройка над уже существующей экспертизой: либо в эксплуатации сложных систем, либо в разработке с уклоном в надёжность и производительность. Компании нанимают SRE тогда, когда нужен человек, способный сразу проектировать SLO и разбираться в архитектуре инцидентов, а это редко получается без бэкграунда.

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

🧭 Как перейти в SRE из DevOps

Для действующего DevOps-инженера переход в SRE — это, по сути, не смена профессии, а добавление конкретных навыков поверх уже существующего стека. Учитывая, что Kubernetes, CI/CD, Docker и Terraform совпадают почти полностью, основная работа — закрыть именно те два пробела, которые показывают данные.

Первый шаг — научиться формулировать и внедрять SLO и SLI на реальных проектах, а не в теории. Это значит: определить, какие метрики отражают здоровье сервиса, договориться с бизнесом о приемлемом уровне надёжности и превратить это в error budget, который реально влияет на скорость релизов. Второй шаг — подтянуть Helm и практики управления релизами в Kubernetes глубже базового уровня, раз этот инструмент заметно чаще встречается именно в SRE-требованиях.

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

🧭 Как перейти в SRE из бэкенда и системного администрирования

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

Бэкендеру обычно не хватает эксплуатационной стороны: он умеет писать код, но слабо представляет, что происходит с этим кодом в продакшене под нагрузкой. Здесь стоит разобраться в observability — метриках, трейсинге, логировании как единой системе — и научиться читать дашборды не постфактум, а в момент инцидента. Второй пункт — освоить инцидент-менеджмент: как выглядит эскалация, кто принимает решения при аварии и как проходит разбор после.

Системному администратору не хватает обратного: он хорошо знает, как система ведёт себя вживую, но часто привык к ручным операциям. Переход здесь идёт от ручной настройки к программируемой инфраструктуре — Infrastructure as Code через Terraform, автоматизация через CI/CD пайплайны вместо ручного деплоя. Это тот же путь, который проходит классический DevOps-инженер, просто стартовая точка другая.

Общий пункт для обоих маршрутов — портфолио. Недостаточно сказать на собеседовании, что разбираешься в observability или IaC: нужны конкретные примеры автоматизации, которую сделал сам, и хотя бы одного инцидента, который разобрал и задокументировал. Именно это отличает кандидата, который «слышал про SRE», от того, кто реально может занять такую позицию.

🚫 Чего не стоит делать при переходе в SRE

Не рассчитывать на локальные казахстанские вакансии с SRE в заголовке — их практически нет. Из 34 SRE-вакансий, помеченных remote, ни одна не привязана к казахстанскому городу, а из казахстанского hh пришло всего 2 такие вакансии за весь срез базы. Если строить стратегию поиска работы вокруг локальной SRE-позиции, велик риск ждать её месяцами без результата.

Не ориентироваться на зарплатные цифры в тенге — их просто нет в доступных данных. Ноль строк KZT для SRE означает, что любые ожидания по зарплате в этой роли на казахстанском рынке приходится строить на предположениях, а не на фактах.

Не переоценивать разницу в стеке между DevOps и SRE. Она сводится к двум пунктам — упоминанию SLO/error budget и Helm, всё остальное совпадает почти полностью. Не нужно думать, что придётся учить принципиально новый набор технологий с нуля.

Не искать junior-SRE вакансии напрямую. Данные показывают, что таких позиций почти не существует — 1 из 49 в базе. Вход реалистичнее строить через DevOps или бэкенд, накапливая опыт, а не пытаясь запрыгнуть сразу на позицию, которую компании обычно доверяют людям с бэкграундом.

🎯 Итоги: SRE в Казахстане — роль, профессия или ярлык

Для казахстанского рынка на сегодняшний день SRE — это либо чисто удалённая работа на зарубежную компанию, либо направление развития внутри существующей DevOps-карьеры, но не отдельная локальная нанимающая категория. Цифры говорят сами за себя: 49 вакансий SRE против 333 у DevOps, из них почти половина сформулирована как гибрид, и ни одна не привязана к казахстанскому городу.

Хорошая новость в том, что разница в требованиях между двумя ролями минимальна — она сводится к акценту на SLO/error budget и чуть более частому использованию Helm. Это значит, что переход технически не требует смены профессии или переучивания с нуля: большая часть навыков DevOps-инженера, бэкендера или сисадмина уже переносима в сторону SRE.

Практическая стратегия для читателя в Казахстане простая: не ждать появления локальных SRE-вакансий и не строить карьерный план вокруг этого заголовка. Лучше расти как DevOps-инженер, целенаправленно набирая экспертизу в SLO, error budget и практиках надёжности — и оставаться открытым к удалённым позициям, если появится желание работать именно под вывеской SRE.