Антон Косенко: «Работа SRE — это про нежность к инфраструктуре»
2026-02-21 14:33 Diff
https://skillbox.ru/media/code/anton-kosenko-rabota-sre-eto-pro-nezhnost-k-infrastrukture/

#статьи

  • 23 ноя 2021
  • 0

Кто такие SRE‑инженеры и чем они отличаются от системных администраторов или разработчиков? Рассказывает SRE‑инженер Антон Косенко.

Colowgee для Skillbox Media

Журналист, коммерческий автор и редактор. Пишет про IT, цифровой маркетинг и бизнес.
Сайт: darovska.com.

об эксперте

SRE-инженер. Работал системным администратором в Медицинском университете им. И. И. Мечникова. Увлекается медиафилософией, в том числе философией компьютерных игр, Unix и Open Source.

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

Фото: Luxurious Ragdoll / Shutterstock

Я считаю, что профессия «системный администратор» уходит в прошлое. И в этом нет ничего плохого. Просто в России, Европе и даже в Америке не знают, как правильно назвать эту универсальную должность. Поэтому в той же Европе чаще всего ищут специалистов по конкретной технологии: Linux-администратора, cloud-инженера или инженера CI/CD.

В 14 лет я стал увлекаться компьютерами — тогда же поставил себе первый Linux. С тех пор я стремился заставить систему всегда работать так, как мне нужно. И до сих пор радуюсь, когда программа или устройство, которые долго капризничали, запускаются и работают как часы.

Если у вас нет знаний и образования, войти в профессию можно через первую линию техподдержки. Обычно туда берут тех, кто знает, какой стороной нужно подключать память в разъём и чем материнская плата отличается от сетевой карты. Когда освоитесь на первой линии, можно брать более сложные задачи, чтобы получить повышение.

Когда я искал первую работу, то жил в небольшом городе. У нас публиковали вакансии в местной группе во «ВКонтакте». Там я и нашёл сисадминскую должность: парень увольнялся и искал кого-нибудь себе на замену.

Потом переехал в Питер и два года проработал во второй линии — решал пользовательские проблемы, которые требовали личного присутствия инженера. На второй линии работают толковые инженеры, но там сильная текучка: работёнка не пыльная, но и не самая интересная. Тех, кто сумел отличиться, часто забирали на должность системного администратора — там тоже постоянно не хватало рабочих рук.

Последние пять лет я работал сисадмином в Медицинском университете им. И. И. Мечникова. Там я поддерживал инфраструктуру: занимался DNS-именами публичных сайтов, дебажил системы мониторинга, администрировал образовательный портал, построенный на базе Moodle LMS, а также рабочие машины преподавателей, работал с базами данных и развёртывал виртуальные машины VMware.

В серверной часто приходилось работать руками. Например, если вышел из строя blade-сервер, вытаскивал его и заменял модули памяти. Я был настоящим фулстеком и занимался всем: от групповых политик на компьютере пользователя до кондиционеров и других устройств в серверной.

Blade-сервер с двумя процессорными модулями. Фото: Wikimedia Commons

Несмотря на то, что я разбирался в разных системах, расти в профессии было довольно сложно. С одной стороны, я знал очень много, а с другой — мало. При этом в некоторые вещи погружался довольно глубоко. Например, чтобы развернуть Network File System, приходилось подробно читать RFC.

На собеседованиях я столкнулся со стереотипом, что админы в бюджетных организациях — это ребята, которые носят мешковатые свитеры и только меняют картриджи в принтерах. Но это не так. У нас была очень крутая инфраструктура с интересными проектами и задачами. Всё строилось на RFC и best practice: от планировки серверной до настройки софта.

Например, в самом первом проекте я разворачивал систему тонких клиентов на базе Linux для пользователей со слабым железом. Нужно было собрать отказоустойчивое хранилище конфигурации и мониторинга. Для этого я создал веб-кластер и сделал репликацию базы данных. Также я кластеризировал образовательный портал, с помощью NFS, Memcached, HAProxy и написал собственную систему аудита пользовательских рабочих станций на PowerShell, PostgreSQL и стеке ELK.

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

Сейчас для государственных учреждений ввели кучу ограничений по закупке оборудования и технологиям, которые можно использовать. Слышал, что планируют работать через единое «гособлако». Но где государство и где то самое «облако»?

Многие бюджетные организации не могут купить технику Cisco и Huawei. Но не потому, что она дорогая, а потому, что Cisco — это зарубежная компания. А ведь они постоянно совершенствуют технологии и выпускают новые интересные продукты.

Бюджетники обязаны соблюдать требования регулятора и использовать только отечественное оборудование. При этом частные компании, у которых нет таких ограничений, используют современный стек с зарубежными технологиями. А в государственных — железо заметно отстаёт.

Сейчас я работаю в крупной компании на должности SRE-инженера, и там совсем другой стек и масштабы. Это гораздо интереснее, чем работать в маленьком стартапе или бюджетной организации. Пожалуй, пик карьеры для SRE-инженера — спроектировать и собрать с нуля свой проект, придумать структуру, которая работает сама по себе при минимальных усилиях со стороны IT-команды.

Сисадмину и SRE-инженеру приходится много работать с людьми. Поэтому советую развивать мягкие навыки.

Честность — это когда вы не скрываете свои косяки. Надо принять простую истину: все ошибаются. Но если возникла проблема — лучше рассказать о ней тем, кого она может затронуть. Чаще всего крупные факапы случаются, когда люди обманывают и что-то недоговаривают.

Например, в прошлом я администрировал сеть из семи аптек с единой учётной системой. Когда она в первый раз упала, была довольно нервозная атмосфера. Рядом со мной сидел гендиректор и каждые 10 минут повторял, что компания несёт огромные финансовые потери. Я жутко стрессовал — но нужно уметь работать и в такой обстановке.

Нужно быстро осваивать новые технологии, потому что админский стек постоянно меняется. Это как в двух известных шутках года 2013-го: о том, что требуется разработчик с десятилетним опытом работы с Ansible, хотя она появилась только в 2012 году, и о том, что нужны программисты с пятилетним опытом в Kotlin и Rust.

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

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

Сейчас я дополнительно прохожу курсы по DevOps. Там я осваиваю теоретическую и практическую базу, которую дают в некоторых технических университетах. Параллельно изучаю новые технологии и автоматизирую рутину на работе.

На предыдущей работе у меня буквально разрывался телефон — я мог говорить по пять часов в сутки. Ко мне постоянно обращались за доступами, кто-то даже пытался выбить их жалобами и мольбами. Такое лучше сразу пресекать.

Нужно уметь строить коммуникацию с коллегами, в том числе с другими инженерами. Если вы не можете объяснить, что произошло и как лучше решить проблему, работать будет практически невозможно.

Фото: Public Domain / habr.com

Сейчас я работаю SRE-инженером. Разница между сисадмином и SRE в подходе к инфраструктуре.

Админ всегда находится внутри инфраструктуры. Он строит план аварийного восстановления, думает о том, чтобы система работала 24/7, и мыслит в единицах техники.

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

Вот что нужно знать SRE-инженеру:

Unix и Linux. Машины с Linux сейчас распространены — особенно в государственных организациях. Есть и отечественные альтернативы, но так или иначе это линуксовые системы. Они требуют знания Linux и Unix хотя бы на уровне пользователя.

Solaris и FreeBSD. Некоторые компании до сих пор используют Solaris. Хорошая была система, но её эпоха закончилась, когда Oracle купила Sun Microsystems. FreeBSD тоже ещё популярен.

Bash и PowerShell. Если вы сисадмин, то всё равно нуждаетесь в автоматизации, а значит для *nix-систем пригодятся bash-скрипты. Windows и язык PowerShell тоже желательно знать на продвинутом уровне.

Языки программирования. Нужно знать хотя бы Python. А в идеале — ещё и Go, PowerShell и Bash. Но для сисадмина в бюджетной организации достаточно владеть только PowerShell и Bash.

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

Скрин из strace — утилиты для диагностики, отладки и обучения пользователей Linux. Скриншот: Skillbox Media

Коллеги-разработчики часто спрашивают, не хочу ли я уйти в программисты. Я отвечаю «нет», потому что у нас совершенно разные задачи и подходы. Задача SRE-инженера — создать и поддерживать стабильную и отказоустойчивую инфраструктуру. А программисты, даже инфраструктурные, заботятся о ней гораздо меньше — они думают о продукте и его оптимизации. Говорят, многие разработчики испытывают нежность к своему коду. Так вот, SRE-инженеры испытывают её к инфраструктуре.

Научитесь: Профессия DevOps-инженер Узнать больше